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

[Brian E Carpenter]

Kurt,

http://tools.ietf.org/html/rfc6343 explains the various 6to4 breakage modes.

It only works outside all IPv4 NATs, so is guaranteed to fail with a CGN in place.

Regards
   Brian


On 06/03/2016 12:52, Kurt Buff wrote:
> Sorry - meant to reply to the list...
> 
> 
> In-line...
> 
> On Fri, Mar 4, 2016 at 11:01 PM, Tore Anderson <tore at fud.no> wrote:
>> Hi Kurt,
>>
>> First of all, +1 to Brian's suggestion to disable 6to4. I'd also disable
>> Teredo.
> 
> OK - I'll try that on my test laptop also, then on hers if that
> doesn't break anything.
> 
> It's beginning to sound as if DirectAccess protocols are narrowing
> down to only ip-https and nat64/dns64.
> 
>>> On my test machine (Also Win8.1), sitting outside of my corporate
>>> firewall on a public IP address, I see the following:
>>>
>>> Tunnel adapter 6TO4 Adapter:
>>>
>>>    Connection-specific DNS Suffix  . :
>>>    Description . . . . . . . . . . . : Microsoft 6to4 Adapter
>>>    Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>>>    DHCP Enabled. . . . . . . . . . . : No
>>>    Autoconfiguration Enabled . . . . : Yes
>>>    IPv6 Address. . . . . . . . . . . : 2002:4332:7632::4332:7632(Preferred)
>>
>> Ok, so this tells us that this machine has the public IPv4 address
>> 67.50.118.50 (0x43.0x32.0x76.0x32). 6ot4 requires public IPv4 addresses
>> to work, so on this machine it has at least a *chance* of working.
>>
>> Note that Windows won't activate 6to4 if the local address is a
>> special-use one, such as RFC1918 ones typically seen behind NAT.
> 
> Ah yes - as stated, my test laptop is on a public IP address, outside
> my firewall.
> 
>>> On her machine, which is on a wireless connection at her home on ATT,
>>> I see this:
>>>
>>> Tunnel adapter 6TO4 Adapter:
>>>
>>>    Connection-specific DNS Suffix  . : attlocal.net
>>>    Description . . . . . . . . . . . : Microsoft 6to4 Adapter
>>>    Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>>>    DHCP Enabled. . . . . . . . . . . : No
>>>    Autoconfiguration Enabled . . . . : Yes
>>>    IPv6 Address. . . . . . . . . . . : 2002:100:69::100:69(Preferred)
>>
>> This tells us that her IPv4 address is 1.0.0.105. That's a completely
>> normal and public IPv4 address, so Windows proceeds to activate 6to4.
>> But I am going to assume that your user does not live in an APNIC lab,
>> which is where this prefix is currently being used...
> 
> You are correct - not in an APNIC lab - her ISP is ATT, and she's at her home.
> 
>> If ATT will allow her 6to4 packets through to the Internet in the first
>> place (they shouldn't), any server replies will not come back to her
>> but instead head straight to Geoff or George's tcpdump session. (With
>> some luck they'll be the topic of an amusing blog post.)
>>
>> The exact same breakage is bound to happen with CGN deployments using
>> 100.64.0.0/10, by the way.
> 
> 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.
> 
> Perhaps I need to start re-reading Understanding IPv6.
> 
> Kurt
>