Thanks for this reply. Am just getting back into things after a bout with a vicious bug that downed my entire family for well over a week - I'm still coughing, in spite of taking meds that are supposed to quell it.
After I catch up, I'll keep working on this. Kurt On Sat, Mar 5, 2016 at 10:40 PM, Tore Anderson <[email protected]> wrote: > * 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
