interfaces: allow tracking the WAN itself in DHCPv6 mode

[meyergru]

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe.
When using dhcp6c over a PPPoE link, if the ISP hands out IPv6 prefixes only, but no IPv6 interface address (i.e. "send ia-na 0" is not honored), the WAN interface gets no IPv6 assignment at all.
Thus, one is limited to the IPv6 addresses of other interfaces that use "track6".

However, without an IPv6 on the WAN interface, FreeBSD does not honor the "highest address" rule of IPv6 in case that several other IPv6 addresses are available for use as a source address. Thus, you basically have no control over which interface's address will get used for outgoing connections from the firewall itself - e.g., assigning a higher IPv6 prefix ID does nothing.

If you register with a dynamic DNS service, you probably want to identify the IPv6 prefix for a specific VLAN interface. The prefix will be arbitrary, though.

Describe the solution you'd like
It would be nice if track6 and dhcp6c were not mutually exclusive. If the interface configuration that originates from "track6" could also be generated for "dhcp6c" via a GUI checkbox, one could hand out an IPv6 prefix to the WAN interface even if the ISP does not offer a separate IPv6 for the interface itself. In that case, the WAN IPv6 would get used unconditionally before any other IPv6 addresses.

Describe alternatives you've considered
I can see no option to assign IPv6 to the WAN interface in this situation.

Additional context
It would also be nice to be able to use IPv6 privacy extensions from the firewall itself. This is not possible with dhcp6c or track6, I believe.

[fichtner]

I think that's what "advanced" is for... check "Identity Association" section of the settings.

[meyergru]

When I use that, the section for "id-assoc pd 0" still does not contain the WAN interface. The content of that section is exactly described by all interfaces that use "track6". I can only modify the sla-len, but not the interfaces listed there.

[fichtner]

Shouldn't you set "Non-Temporary Address Allocation" here for WAN? The prefix (pd) is intended for downstream devices only according to the code.

[meyergru]

Correct. That is my point. My ISP (M-Net) does not honor "send ia-na 0". They give out only a /56 prefix via "send ia-pd 0", but not an additional IPv6 for the PPPoE interface itself. Thus, it would be nice to use part of the prefix range for the PPPoE interface, like I can for all other interfaces. Currently, this is impossible because I cannot use both "track6" and "dhcpc6" for WAN.

[fichtner]

However, without an IPv6 on the WAN interface, FreeBSD does not honor the "highest address" rule of IPv6 in case that several other IPv6 addresses are available for use as a source address.

How is this tested locally on the command line? I'm happy to test.

[meyergru]

I have multiple VLAN interfaces that use track6, like so:

ax0_vlan107: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: IOT
        options=4000300<TSO4,TSO6,NOMAP>
        ether f4:90:ea:00:74:49
        inet 192.168.107.1 netmask 0xffffff00 broadcast 192.168.107.255
        inet6 2001:a62:3bbb:207:f690:eaff:fe00:7449 prefixlen 64
        inet6 fe80::f690:eaff:fe00:7449%ax0_vlan107 prefixlen 64 scopeid 0xc
        groups: vlan RESTRICTED
        vlan: 107 vlanproto: 802.1q vlanpcp: 0 parent interface: ax0
        media: Ethernet autoselect (10GBase-SFI <full-duplex,rxpause,txpause>)
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
ax0_vlan4: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: GAST
        options=4000300<TSO4,TSO6,NOMAP>
        ether f4:90:ea:00:74:49
        inet 192.168.4.1 netmask 0xffffff00 broadcast 192.168.4.255
        inet6 2001:a62:3bbb:204:f690:eaff:fe00:7449 prefixlen 64
        inet6 fe80::f690:eaff:fe00:7449%ax0_vlan4 prefixlen 64 scopeid 0xd
        groups: vlan RESTRICTED
        vlan: 4 vlanproto: 802.1q vlanpcp: 0 parent interface: ax0
        media: Ethernet autoselect (10GBase-SFI <full-duplex,rxpause,txpause>)
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
ax0_vlan5: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: DMZ
        options=4000300<TSO4,TSO6,NOMAP>
        ether f4:90:ea:00:74:49
        inet 192.168.5.1 netmask 0xffffff00 broadcast 192.168.5.255
        inet6 2001:a62:3bbb:205:f690:eaff:fe00:7449 prefixlen 64
        inet6 fe80::f690:eaff:fe00:7449%ax0_vlan5 prefixlen 64 scopeid 0xe
        groups: vlan RESTRICTED
        vlan: 5 vlanproto: 802.1q vlanpcp: 0 parent interface: ax0
        media: Ethernet autoselect (10GBase-SFI <full-duplex,rxpause,txpause>)
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

My WAN interface has no routable IPv6:

pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492
        description: WAN
        inet6 fe80::f690:eaff:fe00:7446%pppoe0 prefixlen 64 scopeid 0xf
        inet 188.174.51.22 --> 82.135.16.28 netmask 0xffffffff
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

When I try: "curl https://api64.ipify.org", I see:

2001:a62:3bbb:205:f690:eaff:fe00:7449

which is clearly ax0_vlan5 instead of ax0_vlan7, which has a higher IPv6 because I chose 0x07 as the IPv6 Prefix ID for that interface. This is considered general IPv6 behaviour, but not in FreeBSD, see 8.1.1.6, case 3, here: https://docs.freebsd.org/de/books/developers-handbook/ipv6/ . In case 2, where WAN interface has an assigned IPv6, that would be preferred.

While the source cited also says that the choice between equal-ranked interfaces is "up to implementation", it clearly should not be:

https://datatracker.ietf.org/doc/html/rfc6724#page-11

The source address selection should be the highest IPv6 - at least that is what I understood. I have not yet found which interface gets selected, probably the last one assigned? At least I have found no way to influence the choice.
This would never be neccessary if PPPoE gets an IPv6 address...

[fichtner]

Looking at https://reviews.freebsd.org/D709 ifconfig supports prefer_source. Have you tried this yet?

Apart from right or wrong I'm still a bit unsure what should be achieved from this. You don't know which interface will take the address / the wrong interfaces takes the address you prefer? If yes, the above could help fix that.

[meyergru]

Yes, I found that one, too. However, it works only if you already know the IPv6, you cannot "prefer_source" an interface by name. So, I cannot do assign the attribute automatically - or this would have to be integrated into OpnSense scripts.

And: yes. I would like to control which address / interface calls out. That way, you could provide to have dyndns for devices behind the firewall (by just changing the prefix part and leaving the hardware part unchanged). OpnSense would do the dyndns updates and devices become addressable over the internet.

This would offer a means to have something like port forwarding, but with IPv6 for ISPs that support only DS-Lite or CGNAT. I guess one could use 72 bits (i.e. 8 Bits Prefix ID plus 64 Bits hardware part) instead as fixed and only modify the /56 Prefix.

[fichtner]

I see your point but it looks like our hands are a bit tied with regard to what the OS is actually offering here. I'm not convinced that tainting the WAN with a PD-subnet is the best course of action.

Another approach would be to add prefix expansion to VIPs (it was discussed a bit last year) which could add the prefer_source flag reliably. Still the prefix merge for a VIP is a little opportunistic since we don't know when a prefix/address appears and when it goes away (indirectly yes but also not 100% reliable).

Cheers,
Franco

[meyergru]

But "tainting the WAN with a PD-subnet" with prefix ID 0x00 is exactly what an AVM Fritzbox does as a fallback (see https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/IPv6_Technical_Note_de.pdf at the end of page 4):

1. An attempt is made to derive the WAN address from the provider's router advertisement.
   If information about DNS servers is available in the router advertisement (RFC 5006), this is adopted.
2. Then, a globally valid prefix (IA_PD) for the home network is requested via DHCPv6.
   If no global WAN address could be determined for the FRITZ!Box in step 1,
   such an address is now requested via DHCPv6 (IA_NA).
   DNS and NTP servers are also requested via DHCPv6 (DNS_SERVERS, NTP_SERVER),
   if none are known from step 1.
3. If still no WAN address is known, the first /64 network from the assigned
   LAN prefix is used for the WAN interface of the FRITZ!Box.

M-Net does neither offer 1 nor honor 2, and OpnSense does not allow 3 - easy as that.

In Germany, there seems to be at least one other ISP like M-Net who does not offer IA_NA: https://forum.openwrt.org/t/solved-how-to-configure-ipv6-pppoe-connectivity/36923

I think a checkbox option to "track6" the dhcp6c interface would be the way to go. That way, the weakness of those providers could be circumvented. AVM does just that, albeit not as an option but automatically. I admit that one still has to go the route of having a fixed 72 Bit wide "prefix id + hardware part" in dynamic DNS in order to make devices on a VLAN with a specific prefix ID available. That in itself is kind of a problem, because limiting access to a specific host can neither be done based upon its IPv6 with dynamic prefixes nor via its MAC, see: https://forum.opnsense.org/index.php?topic=27483.0.

I guess it is difficult to impossible to open an IPv6 port on a host behind OpnSense... or maybe I am trying the wrong way.

[fichtner]

I guess it is difficult to impossible to open an IPv6 port on a host behind OpnSense... or maybe I am trying the wrong way.

For majority of non-business type ISP IPv6 that do not offer fixed IPv6 address/PD... yes.

[meyergru]

Opening up ports via IPv6 would be a nice feature for OpnSense, still (hate to think that AVM has it).

Thank you, Franco!