* Kurt Buff > Can you expand a bit on the above? I'm quite ignorant of what you're > speaking, and would love to know more. > > Why shouldn't ATT allow her 6to4 packet back, and what is the tcpdump > session to which you refer? And, I've only recently become aware that > CGN has its own address range, but don't understand why breakage would > occur for 6to4.
Ok, so her home router improperly uses the public IPv4 range 1.0.0.0/24 on her LAN (instead of a private IPv4 range such as 10.0.0.0/24). This tricks Windows to starting 6to4 in a situation where it really should not (it should only do so if it has a public IPv4 address). That's what causing the problems in the first place. It would be interesting to know what kind of home gateway she has, where she got it from, and if it came with this broken config out of the box. Another thing, ATT supports IPv6 via 6RD (AFAIK), so I'd look into why this doesn't work and try to get that fixed. ATT's own 6RD IPv6 connectivity is going to be better than 6to4 in every way possible. Anyway, the reason why return traffic won't work is simply the way 6to4 works. The public IPv4 address of the host is embedded in bits 17-48 of the IPv6 address, and this is where the return traffic gets sent. That is, if she wants to talk to ipv6.example.org, her initial outbound 6to4 packet will look like this: | IPv4 outer header: src=1.0.0.105 dst=192.88.99.1 | IPv6 inner header: src=2002:100:69::100:69 dst=ipv6.example.org | TCP SYN The packet leaves her LAN (possibly after having the 10.0.0.105 address be rewritten to her real public address by her home gateway, but this does not really help), and gets routed to the nearest 6to4 relay (192.88.99.1). It strips off the IPv4 outer header and injects the resulting packets into the IPv6 network: | IPv6 header: src=2002:100:69::100:69 dst=ipv6.example.org | TCP SYN This reaches ipv6.example.org which responds normally: | IPv6 header: src=ipv6.example.org dst=2002:100:69::100:69 | TCP SYN+ACK This packet gets routed to the nearest 6to4 relay (since it it's addressed to an address inside 2002::/16), which encapsulates in IPv4. As mentioned before IPv4 destination address is found in bits 17-48 of the IPv6 destination address, thus: | IPv4 outer header: src=192.88.99.1 dst=1.0.0.105 | IPv6 inner header: src=ipv6.example.org dst=2002:100:69::100:69 | TCP SYN+ACK This packet then gets injected into the IPv4 network and routed to 1.0.0.105. But, from the Internet's point of view, that address points to APNIC - not your colleague. Thus it won't ever reach your colleague. The tcpdump session I (jokingly) referred to belongs to Geoff Huston and George Michaelson, APNIC's fine scientists who are listening in on all traffic sent to 1.0.0.0/24 and use the data to give us amusing presentations at the various networking conferences. Mayhaps your colleague will be honoured with a slide next time. The situation is pretty much the same for 100.64.0.0/10, i.e., it is an IPv4 range that is being used behind NAT but that most 6to4 implementations won't recognise as private. There's no route to 100.64.0.0/10 on the public IPv4 Internet, thus return 6to4 traffic cannot reach the original sender. Tore
