DS-Lite on 23.7.6+ (23.7.10_1)

[franco]

But the best solution would still be to allow a WAN interface to track itself. This has been requested and discussed before, but turned out to be harder than expected (as far as I remember).

The issue was dhcp6c refusing to do it even if configured. I can look at the code again just to be sure.


Cheers,
Franco

[franco]

Aha, here is the rub-in:

https://github.com/opnsense/dhcp6c/blob/master/prefixconf.c#L204-L210

Code Select Expand

The requesting router MUST NOT assign any delegated
prefixes or subnets from the delegated prefix(es) to
the link through which it received the DHCP message
from the delegating router.
[RFC3633 Section 12.1]

Discuss!

Somehow the logging is off but in foreground mode you get the message...

Apr/26/2024 09:32:24: create a prefix 2003:xxxx:xxxx:xxxx::/61 pltime=3600, vltime=7200
Apr/26/2024 09:32:24: add an address 2003:xxxx:xxxx:xxxx::/64 on igb0
Apr/26/2024 09:32:24: skip igb1 as a prefix interface

[franco]

No response, boring topic? ;)

[Patrick M. Hausen]

"MUST NOT" is unambiguous - discussion over.  ;)

[jbourne]

But if we leave this as is, then (in the extreme) nobody in Japan can use Opnsense directly attached to an ONU device (and if behind an ISP-provided router, then you need to do IPv6 NAT, since only a /64 subnet is assigned to each device), so anything we can do to solve this?

I fixed my issue in the meantime with some really rough hacks (sleep()'ing on boot and bouncing the interface a few times), but this is a really lame hack, not to mention that I make the assumption my subnet won't change, so as soon as it does (and obviously I will happen to be away from my router RIGHT at that moment, lol) it will not come up. Would really love something more reliable as far as a solution goes.

[meyergru]

Aha, here is the rub-in:

https://github.com/opnsense/dhcp6c/blob/master/prefixconf.c#L204-L210

Code Select Expand

The requesting router MUST NOT assign any delegated
prefixes or subnets from the delegated prefix(es) to
the link through which it received the DHCP message
from the delegating router.
[RFC3633 Section 12.1]

Discuss!

Somehow the logging is off but in foreground mode you get the message...

Apr/26/2024 09:32:24: create a prefix 2003:xxxx:xxxx:xxxx::/61 pltime=3600, vltime=7200
Apr/26/2024 09:32:24: add an address 2003:xxxx:xxxx:xxxx::/64 on igb0
Apr/26/2024 09:32:24: skip igb1 as a prefix interface

I remember the attempt to make that work, because I have that type of ISP as well. I just use the LAN GUA to make IPv6 work on the OpnSense itself.

So it seems obvious why dhcpdc could not be convinced to use part of the PD prefix for the WAN interface itself. You cannot argue with an RFC, albeit it would be nice to ignore it like apparently AVM's Fritzboxen do...
;-)

[Patrick M. Hausen]

But if we leave this as is, then (in the extreme) nobody in Japan can use Opnsense directly attached to an ONU device (and if behind an ISP-provided router, then you need to do IPv6 NAT, since only a /64 subnet is assigned to each device), so anything we can do to solve this?

You do not need a GUA on WAN. And you can NAT outbound packets on WAN to e.g. "LAN address" so the firewall itself can use IPv6.

[jbourne]

You do not need a GUA on WAN. And you can NAT outbound packets on WAN to e.g. "LAN address" so the firewall itself can use IPv6.

Sure, but how to set that up? At the moment it does not seem like any way of configuring it makes it work other than manually configure the GIF interface like I posted above - and that doesn't work automatically. Sorry, I might also be a little slow as I'm not used to v6 networking. I miss the old days of plugging a wire into a wall port and just having DHCP give you an IP that never changed, with no ports blocked. sigh.

[meyergru]

But if we leave this as is, then (in the extreme) nobody in Japan can use Opnsense directly attached to an ONU device (and if behind an ISP-provided router, then you need to do IPv6 NAT, since only a /64 subnet is assigned to each device), so anything we can do to solve this?

You do not need a GUA on WAN. And you can NAT outbound packets on WAN to e.g. "LAN address" so the firewall itself can use IPv6.

You do not need NAT for IPv6, just assign and use the LAN GUA. And in firewall rules, you can use "this firewall" or the dynamic IPv6 of the LAN interface. I do it since that discussion long ago. Not sure about GIF interfaces, though.

[franco]

"MUST NOT" is unambiguous - discussion over.  ;)

Yes, in the RFC3633 which got obsoleted by RFC8415 which doesn't have such a restriction as far as I could find.

I did test it without the code and it works... it would be optional anyway.. so I'm merely looking for an expert opinion WRT RFC8415.

Maurice, where are you? ;)


Cheers,
Franco

[Patrick M. Hausen]

You do not need NAT for IPv6, just assign and use the LAN GUA. And in firewall rules, you can use "this firewall" or the dynamic IPv6 of the LAN interface. I do it since that discussion long ago. Not sure about GIF interfaces, though.

How do you make outbound traffic, e.g. NTP, DNS, download of updates ... from the firewall itself use that address? Will that happen automatically, i.e. will the services use the only GUA locally bound if there is only one?

[meyergru]

You do not need NAT for IPv6, just assign and use the LAN GUA. And in firewall rules, you can use "this firewall" or the dynamic IPv6 of the LAN interface. I do it since that discussion long ago. Not sure about GIF interfaces, though.

How do you make outbound traffic, e.g. NTP, DNS, download of updates ... from the firewall itself use that address? Will that happen automatically, i.e. will the services use the only GUA locally bound if there is only one?

Yes, that happens automagically. However, you have no "direct" control over which interface is being used for outbound traffic if you have more than one (V)LAN GUA - it seems just arbitrary. Not that it matters much for outbound traffic, apart from dynamic DNS.

For that, I have my own dyndns service which mixes the received traffic with a configurable suffix and length. Aus such, it would not matter which of the interfaces gets used, since they all share the same (/56) prefix.

[meyergru]

"MUST NOT" is unambiguous - discussion over.  ;)

Yes, in the RFC3633 which got obsoleted by RFC8415 which doesn't have such a restriction as far as I could find.

I did test it without the code and it works... it would be optional anyway.. so I'm merely looking for an expert opinion WRT RFC8415.

Maurice, where are you? ;)


Cheers,
Franco

If the old RFC has been revised in that respect, and thinking about the restriction, I fail to see why it exists in the first place (but I am by no means an expert). As I said, Fritzboxen did not care anyway which it probbaly why some german ISPs did not bother to hand out a IA_NA.

So if it is possible to implement it, you would probably have a checkbox to enable it anyway and you could add a warning in its help text, so I am all for it.

[franco]

> If the old RFC has been revised in that respect, and thinking about the restriction, I fail to see why it exists in the first place (but I am by no means an expert). As I said, Fritzboxen did not care anyway which it probbaly why some german ISPs did not bother to hand out a IA_NA.

The point is probably not why the restriction existed, but rather if something similar or broader or narrower is still in place in the new RFC or if it does not care at all.

> So if it is possible to implement it, you would probably have a checkbox to enable it anyway and you could add a warning in its help text, so I am all for it.

The way the code back then worked is offer a prefix ID input which is optional. So we don't even start tampering with existing setups.


Cheers,
Franco

[meyergru]

I have read RFC8415 and the referenced RFC7084. I understand it as follows...

RFC8415 Section 12.2 explicitely states that:

An IA_PD is different from an IA for address assignment in that it does not need to be associated with exactly one interface.  One IA_PD  can be associated with the client, with a set of interfaces, or with exactly one interface.  A client configured to request delegated prefixes must create at least one distinct IA_PD.

It then talks about downstream interfaces, but never forbids to use IA_PD GUAs for the WAN interface.


But what is way more interesting is this part in RFC7084 (which, according to RFC8415 section 6.4 "describes requirements and network architecture for Customer Edge Routers"):

WAA-6:   If the IPv6 CE router receives a Router Advertisement
               message (described in [RFC4861]) with the M flag set to 1,
               the IPv6 CE router MUST do DHCPv6 address assignment
               (request an IA_NA option).

WAA-7:   If the IPv6 CE router does not acquire a global IPv6
               address(es) from either SLAAC or DHCPv6, then it MUST create
               a global IPv6 address(es) from its delegated prefix(es) and
               configure those on one of its internal virtual network
               interfaces, unless configured to require a global IPv6
               address on the WAN interface.

From my understanding, this not only allows, but requires ("MUST") the customer router to use one of the IA_PD prefixes for its WAN if none is give via IA_NA. This seems logical considering the fact that a combination where a IA_NA is not requested, but a IA_PD is (or if an ISP does not hand out IA_NA GUAs) is possible at all. So it seems, Fritzboxen are correct to use IA_PD instead of IA_NA if the latter is not provided.

That being said, the bit about RFC3633 Section 12.1 being abolished is not explicitely noted in RFC8415 section 25 "Obsoleted mechanisms".

Also, in RFC6603, in section 3, with reference to the now obsolete RFC3633, it says:

DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] has an explicit
limitation described in Section 12.1 of [RFC3633] that a prefix
delegated to a requesting router cannot be used by the delegating
router.  This restriction implies that the delegating router will
have two (non-aggregatable) routes towards a customer: one for the
link between the requesting router and the delegating router, and one
for the customer site behind the requesting router.

There are architectures and link models where a host (e.g., a mobile
router, also acting as a requesting router) always has a single (/64)
prefix configured on its uplink interface and the delegating router
is also the requesting router's first-hop router.  Furthermore, it
may be required that the prefix configured on the uplink interface
has to be aggregatable with the delegated prefixes.  This introduces
a problem in how to use DHCPv6-PD together with stateless [RFC4862]
or stateful [RFC3315] address autoconfiguration on a link where the
/64 advertised is also part of the prefix delegated (e.g., /56) to
the requesting router.

So the limitation seems to originate in the ambiguity of "on-link" connections and "routed" connections sharing the same IPv6 PD prefix, which might cause routing problems with certain providers (however, I thought that only link-local IPs were used for on-link connections). Thus, if at all implemented, I would still not use this as a default.

Maybe someone more knowledgable than me might chime in?