Support for RFC 6603 (prefix exclude)
-
As mentioned in another topic here, Verizon's been rolling out IPv6 services to more and more of its residential and commercial Fios service areas in the mid-Atlantic and Northeastern US regions. In their implementation, Verizon doesn't provide a WAN address via DHCPv6, like some other ISPs do.
Instead, Verizon has implemented RFC 6603, which allows for excluding a subnet from the prefix that has been delegated to the user's router, and an IP address from that subnet (usually ::1) will be used as the GUA address on the WAN interface. The subnet to be excluded is provided through a DHCPv6 option (OPTION_PD_EXCLUDE).
So in Verizon's case, they delegate a /56 to the router, then (currently) exclude subnet ff through that DHCP option and use that subnet for a WAN address.
Yes, I fully understand that a GUA IPv6 address is not necessary in order for things to function with IPv6. I ran without a GUA WAN address for months before I decided to experiment with my current solution of using a virtual IP from my delegated prefix to put a GUA address on my WAN interface. But if I want to use my router as an endpoint for something like VPN to my network, I'd rather use a GUA WAN Address than my LAN address or an address on one of my other internal networks. Also, if properly implemented, enabling support for this option would automate the process of assigning a GUA WAN address from the excluded prefix, so I don't need to manually update the address and other settings/rules/etc. as a result of a prefix change.
I'm posting this here to collect feedback from others before creating a Redmine feature request for it (though someone else has posted something about this on Reddit, and was simply given a link to Redmine to make such a request, so someone might beat me to that step).
Surely with an RFC being created around this option, there have to be other ISPs in the world that are doing the same thing Verizon is doing.
Reference: RFC 6603
.EDIT TO ADD, a few months later...
It had been believed that Verizon was using RFC 6603 to achieve what they're doing with their own routers, but a packet capture has never been done on the WAN side of a Verizon router to observe what in fact they're actually using, if anything. A user with an OpenWRT router (which has a DHCP6 client supporting RFC 6603) has reported that they're not getting any data from the OPTION_PD_EXCLUDE option. That said, it still wouldn't be a bad idea for this to be supported, even if it's not being used by Verizon. There could be other ISPs out there using this functionality of DHCPv6 (surely someone had a need for it if they invested the time to write an RFC for it).The S in IOT stands for Security
-
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 .
