Support for RFC 6603 (prefix exclude)
-
I don't have anything substantive to add, but I would welcome this feature. I hadn't gotten around to working on IPv6 for a VPN yet, but it would also be helpful for outbound DNS requests without using a similar virtual IP workaround.
-
+1 for this feature for Verizon FIOS and other ISPs who also use this natively with their own routers.
-
@mikev7896
I would also like to see this feature implemented. I would prefer to have a WAN GUA for services running on the router, such as a Wireguard VPN. While it's possible to manually add a Virtual IP, I presume this will cause issues if the prefix changes as the Virtual IP will not track the changed /56. -
@mikev7896 Same - on fios here, waiting for v6. Seems like a no-brainer to support this, what would be the argument against it?
-
This isn't an issue for the pfSense team to solve. It needs to come from upstream/FreeBSD. A redmine would be good to track it, but I would expect something like this to take years to make it to pfSense.
Even if it gets picked up in FreeBSD 14, we're still on 12.3 with 22.05, so I would expect no sooner than 2024-25 (which might be right around the time FIOS finishes their IPv6 rollout, if the megathread is any indication).
-
Verizon has been testing IPv6 for a while in a limited number of areas but they only began a large scale rollout at the end of April. Since that time, APNIC shows IPv6 availability on AS701 increased from 3% to 12% with most areas of VA, MD, and DC seemingly covered.
https://stats.labs.apnic.net/ipv6/AS701
-
@jasonwc Okay so with this "large scale rollout" they are increasing their footprint at the breakneck speed of 3-4% per month. If we're at 12% now, and the pace continues at this rate, that puts us somewhere in 2024-25 for completion.
I'm on FIOS too (since 2009) in NYC and want nothing more than to have native v6 on there. But after waiting for 10 years I have learned not to hold my breath.
-
@luckman212 More like this month... come visit the DSLR forum for more info.
Also from a rep tonight, unsolicited, I got this when I mentioned that I was not in an area that has IPv6 yet...
Anyhow, are we sure that this is really a FreeBSD issue? Looking at the manpages, it's mentioned all over the place: https://www.freebsd.org/cgi/man.cgi?query=dhcpcd.conf&sektion=5&manpath=freebsd-release-ports
-
@sporkme That's great news on both fronts. I naively did a search for the literal string
PD_EXCLUDEthinking it would show up in the docs or sourcecode somewhere, and didn't find it. But yes, reading the manpage it does appear to be supported. So I'm happy to admit to being wrong here. Hopefully an official comment from Netgate here or on Redmine can confirm where we stand. -
Redmine feature request created...
https://redmine.pfsense.org/issues/13296
-
Even if there is something that needs to be done upstream in the dhcp6 port, there's still code that needs to be done to add support for the functionality to pfSense... A checkbox to use such option (if desired) in the GUI, logic to exclude the prefix specified in the option from being able to be selected, or send a notification if it's already selected (i.e. the prefix ID specified by the option changed and the new ID is already in use, or a user changes ISPs and is already using the prefix ID that the new ISP is excluding), updating the WAN address if/when the prefix changes... there might even be other stuff I've not thought of.
Also, I'm a pfSense user. If a change needs to be submitted upstream, a pfSense developer would probably be better to be submitting those requests than me. They likely know a lot more about the ports and whatnot than I do (I know nothing about them). Plus, then they'd receive the notification that a change has been made upstream rather than me, and they'd be able to start working on things on their end once they start including the new version of the port with the change. I'd rather not submit an upstream request, only to be told my submission wasn't done correctly for some reason that I know nothing about.
-
I think to support this all we should need is the ability to use "Track Interface", assign it to the WAN interface, with ::1 so Verizon / Comcast and others who gives us PD, we can take the /56, append the our subnet like on the wan ff then apply our on address.
Track Interface:0-ff:1 would be perfect for both LAN, VLan and WAN interfaces.
-
Another reason to support this would be DDNS. We are unable to provide a IPv6 address to services .
