Old delegated prefix not removed from LAN

[bkraptor]

I have set the LAN interface to track the WAN interface via Prefix Delegation. I am getting a different delegated IPv6 prefix each time the WAN bounces. The problem is that I am seeing is that the old IPv6 address is not removed from the LAN interface and also clients on the LAN are receiving RAs from the old delegated prefix, which makes the clients unroutable via IPv6.

Here's a snip of my IPv6 routing table after such a bounce:

Destination 	Gateway 	Flags 	Refs 	Use 	Mtu 	Netif 	Expire
default 	fe80::1%pppoe1 	UGS 	0 	20 	1492 	pppoe1 	 
::1 	::1 	UH 	0 	0 	16384 	lo0 	 
x:y:1014:124::/64 	link#1 	U 	0 	0 	1500 	em0 	 
x:y:1014:124:222:4dff:fe6b:73fc 	link#1 	UHS 	0 	0 	16384 	lo0 	 
x:y:1014:52c7::/64 	link#1 	U 	0 	3 	1500 	em0 	 
x:y:1014:52c7::1 	link#1 	UHS 	0 	0 	16384 	lo0 	 
x:y:1015:f001::/64 	link#14 	U 	0 	0 	1492 	pppoe1 	 
x:y:1015:f001::bc1a:81fa 	link#14 	UHS 	0 	0 	16384 	lo0 	 

In this case, x:y:1014:52c7::/64 is the old delegated prefix.

This is on:
2.1-BETA0 (amd64)
built on Sat Aug 25 13:20:22 EDT 2012
FreeBSD 8.3-RELEASE-p4

But it was the same a few weeks ago when I was running i386.

I can send a packet capture from a host on the LAN that shows the firewall is sending RAs with the old delegated prefix. Just PM me for the file.

[jimp]

Do you have multiple instances of radvd running when it's in this state? What does /var/etc/radvd.conf look like?

[bkraptor]

# Automatically Generated, do not edit
# Generated for DHCPv6 Server lan
interface em0 {
        AdvSendAdvert on;
        MinRtrAdvInterval 5;
        MaxRtrAdvInterval 20;
        AdvLinkMTU 1280;
        AdvDefaultPreference medium;
        prefix x:y:1014:124:0:0:0:0/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
        route ::/0 {
                RemoveRoute on;
        };
        RDNSS x:y:1014:124::1 { };
        DNSSL localdomain { };
};

[2.1-BETA0]/root(3): ps waux | grep radvd
root   61834  0.0  0.1  5864  1524  ??  Ss   Sun06PM   0:05.32 /usr/local/sbin/radvd -C /var/etc/radvd.conf -m syslog
root   18434  0.0  0.1  9156  1512   1  S+    3:37PM   0:00.00 grep radvd

<edit>I've just had another bounce on the WAN interface. The newly-delegated IPv6 prefix is x:y:1014:408e::/64.

The routing table looks like this:

Destination 	Gateway 	Flags 	Refs 	Use 	Mtu 	Netif 	Expire
default 	fe80::1%pppoe1 	UGS 	0 	207 	1492 	pppoe1 	 
::1 	::1 	UH 	0 	0 	16384 	lo0 	 
x:y:1014:124::/64 	link#1 	U 	0 	0 	1500 	em0 	 
x:y:1014:124::1 	link#1 	UHS 	0 	0 	16384 	lo0 	 
x:y:1014:408e::/64 	link#1 	U 	0 	0 	1500 	em0 	 
x:y:1014:408e:222:4dff:fe6b:73fc 	link#1 	UHS 	0 	0 	16384 	lo0 	 
x:y:1014:52c7::/64 	link#1 	U 	0 	156 	1500 	em0 	 
x:y:1014:52c7::1 	link#1 	UHS 	0 	0 	16384 	lo0 	 
x:y:1015:f005::/64 	link#14 	U 	0 	0 	1492 	pppoe1 	 
x:y:1015:f005::bc1b:b403 	link#14 	UHS 	0 	0 	16384 	lo0 	 

The new radvd.conf looks like:

# Automatically Generated, do not edit
# Generated for DHCPv6 Server lan
interface em0 {
        AdvSendAdvert on;
        MinRtrAdvInterval 5;
        MaxRtrAdvInterval 20;
        AdvLinkMTU 1280;
        AdvDefaultPreference medium;
        prefix x:y:1014:124:0:0:0:0/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
        route ::/0 {
                RemoveRoute on;
        };
        RDNSS x:y:1014:124::1 { };
        DNSSL localdomain { };
};

[2.1-BETA0]/root(3): ps waux | grep radvd
root   61834  0.0  0.1  5864  1524  ??  Ss   Sun06PM   0:05.34 /usr/local/sbin/radvd -C /var/etc/radvd.conf -m syslog
root    9175  0.0  0.1  9156  1512   1  R+    3:54PM   0:00.00 grep radvd
```</edit>

[bkraptor]

Is there a way to work-around this issue? I have frequent disconnects (1-2 a day) that mess up my IPv6 (and most pages, Google included, default to IPv6 nowadays). The only way I have found so far to work-around the incorrect RA is to re-save the WAN interface followed with re-saving the LAN interface. This is traffic-impacting and I would rather avoid doing this 1-2 times a day.

[bkraptor]

Created bug report:
http://redmine.pfsense.org/issues/2627

[databeestje]

hi bkraptor,

i'll have a look this week if time permits. I might be able to do random prefixes with the cisco 1811 I have here.

I'm still quite amazed that ISPs think that handing out random addresses and even more so, random IPv6 prefixes is a good idea. It wrecks so much havoc because the LAn addressing changes as well.

Would you mind contacting your ISP if they are considering handing out "static" IPv6 addresses? I know they want to keep their (old) business model they applied to IPv4 addresses going, but the impact in IPv6 is far worse then in IPv4 where just the router changes addresses.

[bkraptor]

Thank you for looking into this issue.

The response I received from my ISP (which is the largest in my country) is that they have no plans to implement statically assigned prefixes.

[databeestje]

Ok, that response is a bit silly.

I changed out the WIDE dhcp6 client for the ISC client, it appears to work on a VM here including prefix delegation, but it will need more testing.

See if this helps your situation.