Multiple IPv6 Prefix Delegation over AT&T Residential Gateway for pfSense 2.4.5

JKnott

Are you running pfSense or not? If not, you're not likely to find a lot of support here. As I mentioned, I have never seen your situation on multiple computers, with either pfSense or Linux firewalls over twenty years or so. My sole Unifi experience is with my AC-Lite access point.

With pfSense, the prefix will change if you don't select that setting I mentioned. Also, some ISPs mess things up to. But neither of those would cause the problem you're mentioning where the same prefix moves to another port.

paul_s

@JKnott
As I stated in my first post "I don't have a PFsense router."
As I stated in my last post "thanks for your time"

ttmcmurry

@paul_s

Have no experience with Unifi - my guess would be there's something being incorrectly set on non-wan interfaces. If your ISP is giving you a /60, then you should be specifying on each internal interface the prefix delegate hint so that internal interfaces assign themselves correctly each time.

What I originally posted in post 1 has a step that refers to this process where the prefix delegation is associated "id-assoc" "pd 1" with the correct interface "hn1" (etc).

The only assumption made with AT&T is they reserve a certain number of networks in their /60 for AT&T use, and the rest are available for delegation.

If UniFi doesn't have a way to associate interfaces to prefix delegation, then you'll get the variability that you're experiencing. Even on PFSense, this has to be done by hand, there's nothing in the GUI that allows admins to configure prefix delegation.

The answer to your other question is the documented method in post #1 is using DHCPv6 (no Router Advertisements) to pull the PD.

paul_s

@ttmcmurry

The UniFi router uses the same dhcp6c configuration pfSense uses. My config is below. I have not been able to find out what the "ifid" number is in the id-assoc but the rest of it looks like yours. Perhaps the IPv6 Track Interface Prefix ID you reference is the key. I will try to figure out what that does in pfSense and see if I can translate it to UniFi.

Thanks for the help.

interface eth3 {
send ia-na 0;
request domain-name-servers, domain-name;
send rapid-commit;
send ia-pd 0;
send ia-pd 1;
script "/opt/vyatta/sbin/ubnt-dhcp6c-script";
};

id-assoc na 0 {};

id-assoc pd 0 {
prefix ::/64 infinity;
prefix-interface eth0 {
sla-id 0;
sla-len 0;
ifid 1;
};
};

id-assoc pd 1 {
prefix ::/64 infinity;
prefix-interface eth1 {
sla-id 0;
sla-len 0;
ifid 1;
};
};

ttmcmurry

@paul_s

Far less was needed in pfsense..

id-assoc pd 0 {
prefix-interface hn1 {
sla-id 0;
sla-len 0;
};
};

Pfsense GUI interface configuration allows for a prefix hint, configured on the interface. The hint should correspond to how dhcp6d was configured for that interface.

You're also using ifid of 1 in both your pd associations. Is there a reason why you're overriding the EUI-64 address? I'd imagine this would be left alone so the specified interface (eth1, etc) is considered unless you meant to set the EUI address on two interfaces?

paul_s

@ttmcmurry
I appreciate your help but I think I have to give up on this. UniFi puts too many layers between me and the dhcp6c.conf file. The UniFi GUI creates a vyOS file interpreted by a perl script that generates the dhcp6c.conf file. It appears that since I specified a "host-name" of ::1 in the GUI it created the "ifid" = 1 as a way to set the interface host value to 1 which is what I want.

It would seem that the "sla-id" should append a value to the delegated prefix specifically for the interface but since we have to request /64 from ATT and they are already using 8 of those blocks, I can't figure out how to use the "sla-id" properly. It appears people with Comcast can request a /60, include all the interfaces in PD 0 and tailor the prefix to the interface with "sla-id".

Anyway, I will limp along with almost random prefix assignments until I can replace my UniFi router with pfSense.

Thanks again for the help.

brswattt

Hi guys,

Problem here. Here is my config:

interface re0 {
	send ia-na 0;
	send ia-pd 0;
	send ia-pd 1;
	send ia-pd 2;
	send ia-pd 3;
	send ia-pd 4;
	request domain-name-servers;
	request domain-name;
	script "/var/etc/dhcp6c_wan_script.sh";
};
id-assoc na 0 { };
id-assoc pd 0 {
	prefix-interface re1 {
		sla-id 0;
		sla-len 0;
	};
};
id-assoc pd 1 {
prefix-interface re1.10 {
		sla-id 0;
		sla-len 0;
	};			
 };
id-assoc pd 2 {
prefix-interface re1.20 {
		sla-id 0;
		sla-len 0;
	};		
 };
id-assoc pd 3 {
prefix-interface re1.30 {
		sla-id 0;
		sla-len 0;
	};		
 };
id-assoc pd 4 {
prefix-interface re1.40 {
		sla-id 0;
		sla-len 0;
	};		
 };

re0 is my WAN interface and re1.10,re1.20,re1.30, and re1.40 are my vlans attached to my LAN device (re1)

All off my LAN/VLAN interfaces get an IPv6 address that is able to be pinged from the internet.
The problem lies with my DHCP clients. They receive an address (That doesn't show up in the DHCPv6 leases) but aren't able to route out to anywhere. (or so it seems). And even though I requested a /60, under WAN interface it still shows a /64 while using the config override. Anything I'm doing wrong? My inside clients can be pinged from the outside, but I can't ping from the inside.....nor access sites by ipv6.

Before I didn't even assign addresses using DHCP, I just used Assisted RA. Looks like the firewall is passing the traffic too. While looking at my gateway, I don't even see what prefix is being handed to it under the status page.

EDIT: looks like I couldn't ping the google IPv6 dns, switched to 2606:4700:4700::1111 and pings work outbound and so do ipv6 test sites. Now all the leases are showing up too, not sure what that was about.

brswattt

Can't edit anymore: Only thing I'm wondering now is if the /64 instead of /60 under the WAN interface is normal. I can't get it to give me a /60, even though all my VLANs successfully got an IP.

JKnott

@brswattt

You should use the prefix size your ISP provides, though a smaller one will work. If they provide a /60, then that's what you want to use.

brswattt

@jknott Oh okay, I must of misunderstood here. I took what was said in the first post to heart, that AT&T DOES provide a /60, but it seems like they only provide me a /64. Why? I don't know. Seems like other people get /60 to work, but this works for me. /64 is plenty of IP addresses, why do people fuss about it?

johnpoz

@brswattt you can not split a /64 - it is designed to be the smallest prefix to use really. There is some special use of /128

But putting a prefix on a interface for say your lan or optX etc would be a /64

In the quick reading I did about the att issue, which might be dated and I don't have att to test with.. Is they will not issue anything other than a /64 vs say a /60 or /56 etc.. that you could break up and use /64s out of that for your different networks/vlans behind pfsense.

So again my quick read of this issue is this script/config allows you to request a delegation for each interface on pfsense. Seems like a horrible setup, why not just let you request a /60??

But which is very typical with many an ISP and IPv6 - they F it up!! ;)

What should/supposed to happen is you request a /60 for example, and then use say prefix 1 of that on lan, prefix 2 on your optX, and prefix 3 on your optY, etc..

brswattt

@johnpoz Yep, god forbid they do it right so we can split it how we want. Also, with managed RA my android devices won't get IPv6 addresses. Can I just set it to Assisted so they can use SLAAC?

johnpoz

@brswattt if you want a dead simple solution to all your isp ipv6 issues.. I have 2 suggestions really, don't use ipv6 at this time. Do you have some actual reason to use IPv6 - other than learning/playing with it? I have yet to have anyone post 1 legit resource that actually requires IPv6..

So the easy thing is just not use it ;)

Yeah sure IPv6 is the future, but that future sure isn't today, nor tomorrow or prob even next few years to be honest. So unless you have some actual need or want for using it, other than learning curve? I have yet to even see or hear of a game that leverages it to be honest.

Other option, is forget your isp stupid deployment method, and just get a free Hurricane electric tunnel. Free - you can get a /48 that doesn't change, you can set your interfaces to use any prefix you want out of your /48.. And guess what you can run slaac all you want ;)

I have had a HE tunnel for like 12 some years.. I use it when I want to test/play with something in IPv6.. Takes all of few minutes to setup. It doesn't change, you can even set your own PTRs for any IP in the /48 etc. Good luck getting your isp to let you do that ;)

My current isp doesn't even offer IPv6, nor have I seen any mention of providing it any time in the near future.

edit:
Click I have ipv6

Click I do not...

paul_s

@ttmcmurry @lilchancep

I have a pfSense CE router now and find your guide to prefix delegation works great. Thank you. I discovered that any Save/Apply to the Interfaces / LAN tab must be followed by a Save on the Router Advertisements tab to correctly define the radvd.conf file. The pfSense system seems to default the radvd.conf file after a Save/Apply on the Interfaces tab ignoring the Router Advertisements configuration until a Save is done on that page. You might want to note that in Step Six of your guide.

marcg

Is this recipe still applicable to 23.01 with recent BGW320 releases (mine is on 4.22.5)?

When I use the recipe, both the BGW and the router say that no prefixes have been delegated, and the router generally refuses to pass IPv4 or v6 traffic to the WAN. The behavior is the same after swapping the dhcp6c_wan_script.sh script into the .conf file and with "Managed" for RA settings.

I'm able to get and use a single prefix when the Configuration Override isn't specified for the WAN interface. Thanks.

lolipoplo

@marcg

Still works for me on the same hardware and firmware. I suggest you pcap your link with the RG for dhcp6 traffic and see if you are sending and receiving PDs

marcg

@lolipoplo Interesting results.

The router solicits three prefixes, which is correct. The BGW advertises them. The router gets them, and then releases all of them ~3 seconds later. You can see that in the screenshot below.

The OP says to uncheck "Do not allow PD/Address release" in the WAN interface DHCP6 setup. I couldn't find that option anywhere. Wonder if it's part of the issue?

Screenshot 2023-05-09 151504.png

marcg

It's working now. This was a new pfSense install, with the WAN interface of my old router (UDM Base) plugged into a dedicated LAN-side interface on the pfSense. I had neglected to turn off prefix solicitation on the UDM. The UDM and pfSense were apparently "fighting" for prefixes from the BGW. Disabling prefix solicitation on the UDM fixed the issue. IPv6 was disabled on the pfSense interface for the UDM throughout; still puzzled as to why the BGW saw the UDM's DHCP6 requests at all.

lolipoplo

@marcg do you feel that your IPv6 connections drop after a few days (>24hrs)

I believe this is caused by the latest firmware. the RG has to be rebooted every few days

marcg

@lolipoplo not yet, but I'll keep an eye on it. My pfSense has only been installed for a ~week.

I did notice an issue with the BGW's NAT table on 4.22.5. NAT table source and destination addresses are reversed for a subset of the entries, i.e., the BGW's NAT table incorrectly shows some traffic being initiated from external->internal when in actuality the flows are initiated internal->external. The pfSense NAT states correctly reflect that. I thought this was a display issue on the BGW only, but it may be deeper. More details here.

Someone responded on that thread saying that their v6 connections were dropping. Maybe the same thing you're observing.