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

[Kurt Buff]

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 <tore at fud.no> 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