IPv6 RA Prefix Doesn't Match Interface Prefix ID

chewie198

My issue was closed as "Not a Bug," with a request to add more detail to this forum post, so I'm including the relevant sections of my config file here. I also tried adding another VLAN on the LAN interface, and had the same issue - the prefix doesn't match the prefix ID and has a /60 netmask.

I'm attaching my interface and DHCPv6 settings, along with my current radvd.conf. I apologize for the separate file uploads, but the spam filter was preventing me from including these in a code block.

Does anyone have any ideas as to what to try next, or is this indeed a bug? I'm a software developer myself so I don't mind digging deeper into this if necessary, but my usual approach would be to isolate components until I've found the culprit, and unfortunately I don't have an easily accessible lab environment with which to test changes to my config.
2_1537780884297_interfaces.txt 1_1537780884297_dhcpdv6.txt 0_1537780884297_radvd.conf.txt

chewie198

Did a little more digging, and there's definitely something odd going on with the DHCPv6 config file generation. When I changed my WAN v6 prefix hint to /62, my radvdconf was generated with /58 prefixes. When I changed my WAN v6 prefix hint to /61, my radvdconf was showing /59 prefixes. Here's an example with a requested /61 on the WAN link:

# Automatically Generated, do not edit
# Generated for DHCPv6 Server lan
interface igb0 {
	AdvSendAdvert on;
	MinRtrAdvInterval 5;
	MaxRtrAdvInterval 20;
	AdvLinkMTU 1500;
	AdvDefaultPreference medium;
	AdvManagedFlag on;
	AdvOtherConfigFlag on;
	prefix 2607:fcc8:9c8f:8100::/59 {
		DeprecatePrefix on;
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr on;
		AdvValidLifetime 86400;
		AdvPreferredLifetime 14400;
	};
	route ::/0 {
		AdvRoutePreference medium;
		RemoveRoute on;
	};
	RDNSS 2607:fcc8:9c8f:8100:a236:9fff:fe4c:b231 { };
	DNSSL in.allenbalaj.com  { };
};
# Generated for DHCPv6 Server opt1
interface igb0.2 {
	AdvSendAdvert on;
	MinRtrAdvInterval 5;
	MaxRtrAdvInterval 20;
	AdvLinkMTU 1500;
	AdvDefaultPreference medium;
	prefix 2607:fcc8:9c8f:8100::/59 {
		DeprecatePrefix on;
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr on;
		AdvValidLifetime 86400;
		AdvPreferredLifetime 14400;
	};
	route ::/0 {
		AdvRoutePreference medium;
		RemoveRoute on;
	};
	RDNSS 2607:fcc8:9c8f:8102:a236:9fff:fe4c:b231 { };
	DNSSL in.allenbalaj.com  { };
};
# Generated config for dhcp6 delegation from wan on opt2
interface igb0.3 {
	AdvSendAdvert on;
	MinRtrAdvInterval 5;
	MaxRtrAdvInterval 10;
	AdvLinkMTU 1500;
	AdvOtherConfigFlag on;
	prefix 2607:fcc8:9c8f:8100::/59 {
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr on;
	};
	RDNSS 2607:fcc8:9c8f:8103:a236:9fff:fe4c:b231 { };
	DNSSL in.allenbalaj.com { };
};

jimp

Show us screenshots or config.xml that cover your interface config, such as what you see on Interfaces > WAN, Interfaces > LAN, and so on. Specifically what you have set in the DHCPv6 and Track interface options.

I can't make anything happen here like you are seeing, it all operates correctly.

chewie198

I spent a few more hours investigating this and I was able to find a workaround, although there still seems to be some unwanted behavior on the pfSense side.

The issue appears to be that my ISP (Charter Spectrum in northeast Ohio) either grants a /64 or a /56 PD. While I was requesting a /60, my ISP would grant me a /56. However, pfSense doesn't appear to validate the PD. Instead, it would proceed as if it was granted a /60 and assign prefixes to my three LAN subnets. This would work because the /60 is a subset of the delegated /56. Unfortunately, the DCHPv6 auto-generation is then unexpectedly configuring the LAN interfaces for what appears to me to be arbitrary yet deterministic values. As I mentioned in my last post, when I changed my WAN v6 prefix hint to /62, my radvdconf was generated with /58 prefixes. When I changed my WAN v6 prefix hint to /61, my radvdconf was showing /59 prefixes. With a /60 prefix hint, radvdconf is generated with /60 prefixes, and so on. None of these work correctly on the LAN subnets because they aren't the separate /64s.

As you might guess, these problems are resolved when requesting the expected /56 prefix on the WAN interface. To do this, I used the information in this thread to reconfigure the WAN DHCP client to run in debug mode. I then navigated to System / Advanced / Networking / IPv6 Options / DHCP6 DUID, changed the DUID to be GUID based using a newly generated GUID, and rebooted both the firewall and the modem. I was then able to confirm in the System Logs that the firewall received a /56. Once this change was made, the generated radvd.conf included all /64 subnets with the proper prefixes.

chewie198

@jimp, given that this only occurs where the DHCPv6 client receives a different prefix than it requested, do you still want me to provide the files you mentioned, or has this edge case not yet been tested?

Also, I thought that the files I uploaded in my last post include what you're requesting here. Specifically, the file ending in interfaces.txt is the interfaces section of my config.xml. The other two ending in dhcpdv6.txt and radvd.conf.txt also include their respective configuration sections. They appear to include the options you're talking about, but if something is missing or if you would prefer screen shots, let me know and I can upload new files/images as well.

jimp

I don't think we have tested that case much if at all, since it's critical to have your settings match what the ISP sends or it is known to not function properly.

It might be possible to improve that in the future, but if the firewall could properly guess what the delegation size was to check it, there wouldn't be a need for the GUI setting. It's up to the user to get it right there as far as I'm aware.

chewie198

@jimp, OK, in that case, I'll leave the bug report as-is. Hopefully, the information I've provided here will be useful for anyone seeking a solution.

Thanks for your time spent investigating this and for your work on the pfSense project as a whole!

luckman212

There's no way (currently) to see what IA-PD was received from the upstream ISP, correct? The only "official" way is by weeding through dhcp.log? e.g.

clog /var/log/dhcpd.log | grep -Eo 'IA_PD prefix:\ [^\ ]+' | tail -n1

Can dhcp6c be interrogated for this somehow? It would be very useful to add to the GUI somewhere.

Edit: I made this poor man's hack if anyone wants to try!
https://redmine.pfsense.org/issues/8946
https://github.com/pfsense/pfsense/pull/3991
(install via system patches)

Derelict

ISPs could also quit being so nebulous and unsupportive and actually propagate the information to configure an IPv6 router to their customers instead of leaving them guessing.

luckman212

That would be a dream! For now I wouldn't hold my breath. FIOS doesn't even support IPv6 and as far as I know since they've been selling off the business to Frontier I doubt there are even any plans to. Shame.