Sorry - meant to reply to the list...
In-line...
On Fri, Mar 4, 2016 at 11:01 PM, Tore Anderson <tore@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
In-line...
On Fri, Mar 4, 2016 at 11:01 PM, Tore Anderson <tore@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