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

Kurt Buff kurt.buff at
Fri Mar 18 19:56:00 CET 2016

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.


On Sat, Mar 5, 2016 at 10:40 PM, Tore Anderson <tore at> 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
> on her LAN (instead of a private IPv4 range such as 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, her initial outbound
> 6to4 packet will look like this:
> | IPv4 outer header: src= dst=
> | IPv6 inner header: src=2002:100:69::100:69
> The packet leaves her LAN (possibly after having the 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
> ( It strips off the IPv4 outer header and injects the
> resulting packets into the IPv6 network:
> | IPv6 header: src=2002:100:69::100:69
> This reaches which responds normally:
> | IPv6 header: dst=2002:100:69::100:69
> 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= dst=
> | IPv6 inner header: dst=2002:100:69::100:69
> This packet then gets injected into the IPv4 network and routed to
> 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 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, 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
> on the public IPv4 Internet, thus return 6to4 traffic
> cannot reach the original sender.
> Tore

More information about the ipv6-ops mailing list