IPv6 Prefix Delegation Issue with BGW320

Internet access discussion, including Fusion, IP Broadband, and Gigabit Fiber!
4 posts Page 1 of 1
by mgoldburg » Wed Aug 03, 2022 12:47 pm
Has anyone else noticed that the ATT BGW320 won't delegate an IPv6 prefix until there's a link state change on its LAN ports? ATT reboots the BGW320 at night every few weeks. That takes my IPv6 connections down until I manually intervene. Unplugging and replugging my home router's WAN interface from the BGW320 is enough to restore prefix announcements from the BGW320, which restores IPv6 functionality for my network.

The WAN interface of my home router (Ubiquiti Dream Machine, "UDM") is connected to a LAN port of the BGW320 in DHCPS-Fixed passthrough mode. The UDM is the only device connected to the BGW320 and the BGW's WiFi is disabled. The BGW320 is currently running 3.18.5, but the issue has been going on for a while.

If the UDM is rebooted, or its WAN port unplugged then replugged, while the BGW320 is up, the UDM gets a delegated /64 prefix from the BGW320. The UDM uses that prefix to assign IPv6 addresses to clients on its LAN side (combination of SLAAC and DHCPv6). IPv6 "works" for my home machines at that point. However, if the BGW320 is rebooted while the UDM is up, the BGW320 does not resume advertising prefixes until the UDM is rebooted or its WAN cable unplugged+replugged. IPv6 is down for my home machines until then.**

I've attached packet captures from the UDM's WAN interface that demonstrate the problem. I started in the state where the UDM had a prefix from the BGW320 (i.e., IPv6 working). Then I rebooted the BGW. The first pcap is taken after the BGW comes back up: the BGW is advertising no available prefixes. After ~5 minutes, I unplugged the UDM's WAN interface, waited 30s and then plugged it back in. The second pcap is taken immediately afterwards and shows the BGW has resumed advertising a prefix (i.e., at which time I again have in-home v6).

Thanks in advance.

** IPv6 "going down" is nuanced. Depending on the client and when the BGW reboots, loss of IPv6 can take up to an hour, which is the lifetime of prefixes delegated by the BGW.
Screenshot 2022-08-03 122536.jpg
Screenshot 2022-08-03 122536.jpg (93.88 KiB) Viewed 1737 times
Screenshot 2022-08-03 122908.jpg
Screenshot 2022-08-03 122908.jpg (99.2 KiB) Viewed 1737 times
by mgoldburg » Tue Aug 30, 2022 8:55 am
TL; DR: Turns out that the issue is a race condition between the UDM's DHCPv6 client and the BGW's DHCPv6 server. If you lose IPv6 following a BGW reboot, you can restore it by unplugging+replugging the connection between the UDM WAN port and the BGW. The link state change causes the UDM to reissue a DHCPv6 Solicit.

When the BGW reboots, the UDM immediately begins issuing DHCPv6 Solicits. The BGW's first Advertise response includes "no available prefixes," likely because the BGW hasn't received a delegateable prefix from the ATT network at that point. The UDM doesn't attempt another Solicit for the prefix after that, at least for the 30 minutes I ran my test. If the UDM's WAN interface is subsequently unplugged+replugged or its DHCPv6 client is restarted (by ssh'ing into the UDM or full reboot), it issues a new Solicit. By that time, the BGW has a prefix to Advertise and IPv6 is restored. I've confirmed this on a BGW320-505 running 3.18.5 and a BGW320-500 running 2.14.7, 3.15.7 and 3.18.5.

Arguably, the BGW shouldn't respond to Solicits until it has a complete set of v6 information. And, arguably, the UDM could be less aggressive in issuing the Solicit or have a retry mechanism. Either would fix the problem. I've reached out to both ATT and Ubiquiti.
by jfa_roy » Tue Aug 30, 2022 9:36 am
Thanks for the report. I have a UDMP and it's good information to know. Despite IPv6 _still_ not being available to Sonic fiber customers like myself.
by mgoldburg » Tue Aug 30, 2022 10:08 am
Native IPv6 support is the (only?) consolation prize for Sonic's fiber not yet reaching my neighborhood and having to buy ATT's service through them instead ...

I have a UDMB. It runs the same Ubiquiti Network Application as the UDMP, so I'd expect the behavior to be identical. I'm running Network 7.2.92 presently and saw similar behavior on previous Network releases.
4 posts Page 1 of 1

Who is online

In total there are 28 users online :: 3 registered, 0 hidden and 25 guests (based on users active over the past 5 minutes)
Most users ever online was 999 on Mon May 10, 2021 1:02 am

Users browsing this forum: Ahrefs [Bot], Google [Bot], Semrush [Bot] and 25 guests