Curious situation - not urgent, but I'd like to know more

[Tore Anderson]

* 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