Subject: [v6ops] would like feedback on behaviour seen in the field

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 6 Mar 2011 13:19:09 +0100 (CET)

Hi.

I just did some testing of IPv6 behaviour of a home routing scenario and 
how units behaved. The units used was a Win7 Home premium SP1, and a Cisco 
7200 router running IOS 15.0(1)M4.

I will call them C1 and W1.

C1 has a IPv6 /48 and an IPv4 /28 routed to itself and has on the local 
interface the IPv4 /28 and DHCP, and for IPv6 it has a /64 with M and O 
bit set, plus DHCPv6 server for handing out addresses. It is configured to 
do DHCPv6-PD with /64 prefix. The Win7 machine is running with (afaik) 
default settings for Teredo and 6to4 and since it has a globally unique 
IPv4 address, both are active.

Internet - C1 - LAN1 - W1 - LAN2 - Linux machine (ubuntu 10.10)

The Win7 machine boots up, does SLAAC with EUI64 address on LAN1, does 
DHCPv6 and gets one address from the Cisco router, and also creates a 
privacy address for itself using SLAAC, for a total of 3 IPv6 addresses. 
It also gets one IPv4 address using DHCP, plus gets DNS servers etc for 
both IPv4 and IPv6. This is all fine and dandy.

Now, I turn on Internet Connection sharing on the Win7 machine. It now 
does DHCPv6-PD on LAN1 and gets a globally unique /64 out of the /56 PD 
pool of /64s I have assigned the cisco router to hand out from the /48 
available. It also creates a 192.168.x.y/24 on LAN2 and starts running a 
DHCP server and hands out these and does v4-NAT.

What happens is that it actually hands out a 6to4 based prefix on LAN2 to 
the linux machine, and all IPv6 traffic (I have to force it to go to an 
AAAA only address) uses 6to4 prefix. This seems weird.

Fine, I disable teredo and 6to4 manually on W1 using "netsh", but the 6to4 
based address is still in the linux machine, so when I turned off 6to4, I 
guess no 0 lifetime RA was sent for the 6to4 prefix on LAN2 (or if it was, 
linux didn't honour it). I clear these addresses manually on the linux 
machine, unplug/replug the LAN2 cable and now IPv6 works properly with the 
globally unique addresses from the /64 PD prefix.

I then try to change the PD pool handout prefix size to /60 on the Cisco. 
This doesn't work, because there are things already handed out from the 
pool, so I have to clear it first and then change to /60 (from the same 
/56). This means the static /64 route pointing to the W1 machine on LAN1 
is now gone and the PD binding is cleared. W1 is unaware of this. Is there 
a mechanism for telling it that should be used?

I then unplug the windows machine LAN1 cable and plug it in again. I see 
the /64 in the routing table, but nothing on the Cisco. I guess W1 doesn't 
do any kind of refresh on the DHCPv6-PD prefix when it brings up the LAN 
interface. I try reboot, same thing. This seems to be the same way for 
stateful DHCPv6 addressing as well, no refresh (I am not 100% sure here 
though). I'm used to DHCPv4 being refreshed upon connect, is this 
different in DHCPv6?

Oki, anyhow, I disable ICS and enable it again to make the /64 go away, 
W1 aquires a /60 from the Cisco router and hands out a different /64 on 
LAN2 within this /60. Fine. The only problem is that it doesn't null route 
the /60 internally, so this causes pingpong routing for the other 15 /64s 
in the /60. This seems undesireable.

I see quite a lot of operational problems in the above text and I'd like 
some input on whether the behaviour seen is actually violating some RFCs 
and if they're doing things not mentioned in RFCs at all, that would be 
good as well because then we can improve the standards.

I did all of this in approximately 45-60 minutes and I had some more 
problems than I described, but those problems are out of scope for v6ops.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Mon, 7 Mar 2011 15:21:09 +0100

Mikael,

> I just did some testing of IPv6 behaviour of a home routing scenario and how units behaved. The units used was a Win7 Home premium SP1, and a Cisco 7200 router running IOS 15.0(1)M4.
> 
> C1 has a IPv6 /48 and an IPv4 /28 routed to itself and has on the local interface the IPv4 /28 and DHCP, and for IPv6 it has a /64 with M and O bit set, plus DHCPv6 server for handing out addresses. It is configured to do DHCPv6-PD with /64 prefix. The Win7 machine is running with (afaik) default settings for Teredo and 6to4 and since it has a globally unique IPv4 address, both are active.
> 
> The Win7 machine boots up, does SLAAC with EUI64 address on LAN1, does DHCPv6 and gets one address from the Cisco router, and also creates a privacy address for itself using SLAAC, for a total of 3 IPv6 addresses. It also gets one IPv4 address using DHCP, plus gets DNS servers etc for both IPv4 and IPv6. This is all fine and dandy.
> 
> Now, I turn on Internet Connection sharing on the Win7 machine. It now does DHCPv6-PD on LAN1 and gets a globally unique /64 out of the /56 PD pool of /64s I have assigned the cisco router to hand out from the /48 available. It also creates a 192.168.x.y/24 on LAN2 and starts running a DHCP server and hands out these and does v4-NAT.
> 
> What happens is that it actually hands out a 6to4 based prefix on LAN2 to the linux machine, and all IPv6 traffic (I have to force it to go to an AAAA only address) uses 6to4 prefix. This seems weird.
> 
> Fine, I disable teredo and 6to4 manually on W1 using "netsh", but the 6to4 based address is still in the linux machine, so when I turned off 6to4, I guess no 0 lifetime RA was sent for the 6to4 prefix on LAN2 (or if it was, linux didn't honour it). I clear these addresses manually on the linux machine, unplug/replug the LAN2 cable and now IPv6 works properly with the globally unique addresses from the /64 PD prefix.
> 
> I then try to change the PD pool handout prefix size to /60 on the Cisco. This doesn't work, because there are things already handed out from the pool, so I have to clear it first and then change to /60 (from the same /56). This means the static /64 route pointing to the W1 machine on LAN1 is now gone and the PD binding is cleared. W1 is unaware of this. Is there a mechanism for telling it that should be used?
> 
> I then unplug the windows machine LAN1 cable and plug it in again. I see the /64 in the routing table, but nothing on the Cisco. I guess W1 doesn't do any kind of refresh on the DHCPv6-PD prefix when it brings up the LAN interface. I try reboot, same thing. This seems to be the same way for stateful DHCPv6 addressing as well, no refresh (I am not 100% sure here though). I'm used to DHCPv4 being refreshed upon connect, is this different in DHCPv6?
> 
> Oki, anyhow, I disable ICS and enable it again to make the /64 go away, W1 aquires a /60 from the Cisco router and hands out a different /64 on LAN2 within this /60. Fine. The only problem is that it doesn't null route the /60 internally, so this causes pingpong routing for the other 15 /64s in the /60. This seems undesireable.
> 
> I see quite a lot of operational problems in the above text and I'd like some input on whether the behaviour seen is actually violating some RFCs and if they're doing things not mentioned in RFCs at all, that would be good as well because then we can improve the standards.
> 
> I did all of this in approximately 45-60 minutes and I had some more problems than I described, but those problems are out of scope for v6ops.

at least it appears to violate RFC3633 and http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09
for the lack of verification that the binding is correct when connecting the cable to the delegating router as well as the lack of a blackhole route.

with regards to the sending of RA with lifetime of 0 on reconfiguration, the default to 6to4 and the lack of a DHCPv6 reconfigure message on changing the pool size. well, that's implementation specific, but it clearly creates operational problems when implemented as you have shown above.

cheers,
Ole