OpenWrt looses IPv6 connectivity after upstream outage/reconnect

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi,

I'm using a UBNT-ERX running OpenWrt 18.06.4. It is connected to a AVM Fritz!Box 7430 (Upstream) which is providing the access to VDSL by the german provider DTAG.

<-- DTAG --> Fritz!Box <--> UBNT-ERX <--> Devices

My problem is related to IPv6 which is loosing connectivity after an outage or reconnect of the upstream router. Upstream I'm getting a /56-prefix and the ERX is requesting a /62 from the upstream router. The prefix is dynamic, means with every reconnect of the upstream router, the prefix changes.

I reproduced the problem by clicking "reconnect" in the upstream router's webif.

Before reconnect, everything is running perfectly:

root@erx:~# ip -6 a s dev eth0.2
5: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether fc:ec:da:72:7e:01 brd ff:ff:ff:ff:ff:ff
    inet6 2003:de:8f25:5200:feec:daff:fe72:7e01/64 scope global dynamic 
       valid_lft 7120sec preferred_lft 1663sec
    inet6 fe80::feec:daff:fe72:7e01/64 scope link 
       valid_lft forever preferred_lft forever

root@erx:~# ifstatus wan6
	"ipv6-address": [
		{
			"address": "2003:de:8f25:5200:feec:daff:fe72:7e01",
			"mask": 64,
			"preferred": 1651,
			"valid": 7108
		}
	],
	"ipv6-prefix": [
		{
			"address": "2003:de:8f25:52fc::",
			"mask": 62,
			"preferred": 3509,
			"valid": 7109,
			"class": "wan6",
			"assigned": {
				"lan": {
					"address": "2003:de:8f25:52fc::",
					"mask": 64
				},
				"isolated": {
					"address": "2003:de:8f25:52fd::",
					"mask": 64
				}
			}
		}
	],

After reconnect, OpenWrt is getting an new IPv6 at the WAN interface (eth0.2) by SLAAC, but is not requesting a new prefix by DHCPv6-PD. The older IPv6 is getting deprecated, but the ERX has the old prefix still assigned to the downstream interfaces:

root@erx:~# ip -6 a s dev eth0.2
5: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether fc:ec:da:72:7e:01 brd ff:ff:ff:ff:ff:ff
    inet6 2003:de:8f25:7a00:feec:daff:fe72:7e01/64 scope global dynamic 
       valid_lft 7178sec preferred_lft 1774sec
    inet6 2003:de:8f25:5200:feec:daff:fe72:7e01/64 scope global deprecated dynamic 
       valid_lft 7173sec preferred_lft 0sec
    inet6 fe80::feec:daff:fe72:7e01/64 scope link 
       valid_lft forever preferred_lft forever

	"ipv6-address": [
		{
			"address": "2003:de:8f25:5200:feec:daff:fe72:7e01",
			"mask": 64,
			"preferred": 0,
			"valid": 7155
		},
		{
			"address": "2003:de:8f25:7a00:feec:daff:fe72:7e01",
			"mask": 64,
			"preferred": 1756,
			"valid": 7160
		}
	],
	"ipv6-prefix": [
		{
			"address": "2003:de:8f25:52fc::",
			"mask": 62,
			"preferred": 2921,
			"valid": 6521,
			"class": "wan6",
			"assigned": {
				"lan": {
					"address": "2003:de:8f25:52fc::",
					"mask": 64
				},
				"isolated": {
					"address": "2003:de:8f25:52fd::",
					"mask": 64
				}
			}
		}
	],

I'm helping myself by restarting the wan6 interface which solves the issue.

After ifdown wan6 && ifup wan6, correct IPv6 address and IPv6 prefix:

root@erx:~# ip -6 a s dev eth0.2
5: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2003:de:8f25:7a00:feec:daff:fe72:7e01/64 scope global dynamic 
       valid_lft 7196sec preferred_lft 1693sec
    inet6 fe80::feec:daff:fe72:7e01/64 scope link 
       valid_lft forever preferred_lft forever

	"ipv6-address": [
		{
			"address": "2003:de:8f25:7a00:feec:daff:fe72:7e01",
			"mask": 64,
			"preferred": 1683,
			"valid": 7186
		}
	],
	"ipv6-prefix": [
		{
			"address": "2003:de:8f25:7afc::",
			"mask": 62,
			"preferred": 3589,
			"valid": 7189,
			"class": "wan6",
			"assigned": {
				"lan": {
					"address": "2003:de:8f25:7afc::",
					"mask": 64
				},
				"isolated": {
					"address": "2003:de:8f25:7afd::",
					"mask": 64
				}
			}
		}
	],

Is anyone facing the same issue or has a solution for it?

2

DHCP and, to some extent, IPv6 addressing is on a client-driven basis. There isn't a real push mechanism for "ignore what I told you before, you should use this lease".

Note that an IA_PD has no explicit "lifetime" or "lease length" of
its own. When the valid lifetimes of all of the prefixes in a IA_PD
have expired, the IA_PD can be considered as having expired. T1 and
T2 are included to give delegating routers explicit control over when
a requesting router should contact the delegating router about a
specific IA_PD.

Setting a short time for the leases you provide can help speed the process. I typically use a 600- or 900-second period, so that clients typically "check in" at 5 or 7 minutes, and all should have picked up the new assignment within 10-15 minutes.

Some related threads that might have other suggestions include