IPv6 - workaround for RFC6603 issue

[pawlisko80]

Important notices

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

• [x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

This issue was already discussed few times, but it was deprioritized due to root cause is in the FreeBSD issue. Please see: https://github.com/opnsense/core/issues/5630

The problem is deeper as without IPv6 address on WAN/Internet interface IPv6 NAT is not available; hence any VPN NAT solution using IPv6 will not work - it is possible to use NPTv6 but not NAT66.

Describe the solution you like

Adding Virtual IP address to WAN/Internet interface is fixing the issue. Abbility to use scripting as IPv6 prefix is dynamic would automate solution.

I.e. if assigned prefix is 2001:db8:c000::/56 an ability to designate and automate Virtual IP to ::1234/64 which would create IPv6 address of 2001:db8:c000::1234/64 would create workaround to RFC6603, automating this to change Virtual IP if prefix changes to 2001:db8:d000/56 to changing address to 2001:db8:d000::1234/64 would solve issue until it is permanently fixed by FreeBSD developers

[fichtner]

I think the proposal is to snatch an unused /64 from the delegated prefix for the WAN interface, right?

So a couple of things here:

• To my knowledge it's not a FreeBSD issue. The dhcp6c client will not assign an address to the WAN interface from the delegated prefix. It is probably the easiest solution to get this started and put back the code discussed in #5630 but it would require someone dealing with writing the feature for dhcp6c and for the most part that software is stale and unmaintained. We have a fork for related reasons only to add some past contributions in the IPv6 area that help with specific ISP requirements using the "raw" options mode there.
• Virtual address expansion was discussed, but the scope of prefix expansion is to use a REAL address prefix ALREADY assigned to the respective interface. All the tracking requirements deriving addresses from one interface to the next are very hard to implement cleanly without tainting components with unnecessary implementation details of other components. In this case here you suggest the reverse tracking method and making sure there is a prefix available, perhaps in the more explicit fashion it would require what the GUI parts did for #5630.
• Why should the address be pinned to a specific suffix address? To my knowledge the prefix matters only. And not even on the WAN interface but for the full delegated prefix available, which makes NPT the proper way to use even in the situation described given that #6158 is implemented on top of what we have now external prefix auto-detection in 22.7.x. This would avoid the complication of a virtual IP requirement and introduce less risk for breakage in edge cases because VIP handling is known to be a bit fragile around address ordering and the way the kernel uses available addresses.

Cheers, Franco

[pawlisko80]

Yes, your description is "neater."

I reread all the threads you mention, and I understand the problem, but also, life is life, and the ability to use IPv6 as a WAN/Internet interface address is essential, especially since I have to use public dynamic GUA and public non-routable GUA at home due to some of my devices (like Cisco WLC) requiring static IPv6. At some point that creates Bi-NAT issues with few WG instances, I run.

5630 was onto something, especially with pfSense tread: https://forum.netgate.com/topic/174980/fios-getting-56-pd-via-dhcp6-but-no-v6-is-assigned-to-wan and temporary solution: https://github.com/luckman212/assign-gua-from-iapd may be of service here. Any chance it could be adapted to OPNsense temporarily until a proper solution is implemented? Anything which would create an automatic solution as I often travel internationally, and the ability to talk to home or VPN through the home is crucial for me.

6158 - any timeline for GUI implementation?

Best, Pawel

[pawlisko80]

@fichtner

So yet another thing. #6158 is only working if you have a WAN address. Hence with FiOS OPNsense has not default WAN IPv6 address, it is not working. Yet another reason why snatching IPv6 for WAN interface is needed.

Also #6158 - if two computers within two different internal prefixes have the same IP than it fails

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.