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

[Brian E Carpenter]

Just an update: I eyeballed the "PrefixPolicies-Vista78.cmd" script from
https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies, concluded
that it was safe, and ran it. It apparently works, but I don't have a
ULA setup to test it with.

jrey42 deserves kudos.

Regards
   Brian

On 21/12/2015 07:57, Brian E Carpenter wrote:
> On 21/12/2015 03:28, Marc Luethi wrote:
>> Hi all
>>
>> I suggest to investigate source address selection on the client side,
>> while closely following name resolution (assuming this is similar to
>> Windows 2012R2's DA implementation, DNS64 is supposed to be at work, here)
>> and keeping an eye on the IPv6 routing table.
>>
>> In your situation, I would presume that the end system ends up with an RFC
>> 4193 address (from the /48 that was initially chosen when DA was set up) on
>> its *IP-over-HTTPS* tunneling interface (courtesy of the DA implementation)
>> and a global unicast address  the (W)LAN interface, based on the CPE's RAs.
>>
>> While things *should* be neat, my experience with Windows 7's way of
>> picking source addresses was so bad ("longest match" seemed entirely
>> unheard-of), I eventually gave up using RFC 4193 addresses for my internal
>> network altogether.
>>
>> I repeateadely observed Win7 using its global unicast address(es) to access
>> internal ressources, while stubbornly sticking to te RFC4193 source address
>> when attempting to talk to addresses on the global IPv6 internet.
> 
> Yes. Apparently Win8 is up to date in that respect (i.e. follows RFC6724 not
> RFC3484). It would be possible to make Win8 misbehave by changing the default
> preferences (https://tools.ietf.org/html/rfc6724#section-10.6).
> 
> Conversely, it's possible to make Win7 behave correctly by changing its default
> policies to conform to RFC6724. I just found the following site that offers a
> script (YMMV, I haven't checked it):
> https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies
> 
> But if that is the cause of the original issue, maybe switching off the
> ULA prefix would be easier, and nicer than switching off IPv6.
> 
>     Brian Carpenter
> 
> 
>>
>> cheers
>> Marc
>>
>>
>>
>>
>> On 19 December 2015 at 22:37, Kurt Buff <kurt.buff at gmail.com> wrote:
>>
>>> All,
>>>
>>> I ran into an interesting situation some months ago which still
>>> baffles me, and though I was able to work around it, I expect it will
>>> happen again.
>>>
>>> We implemented MSFT DirectAcess at our company quite some time ago
>>> (using 2008R2 and Forefront 2010), and it works extremely well.
>>>
>>> At least it worked well for everyone until one of the employees got
>>> his Comcast connection upgraded, and then DirectAccess didn't work for
>>> that employee any more.
>>>
>>> We proved that if he tethered to his cell phone, that would work, and
>>> if he used an SSL VPN client while on his Comcast connect that would
>>> work, but DirectAccess would not work at home.
>>>
>>> Finally, I discovered that his Comcast-installed router was handing
>>> our IPv6 addresses on his home LAN. Turning that off enabled
>>> DirectAccess to work again.
>>>
>>> We do not have an assigned IPv6 block from our ISP, though of course
>>> MSFT OSes use it, and auto-assign themselves addresses, but for now
>>> we're ignoring it.
>>>
>>> Has anyone run into this problem and solved it - not by turning off
>>> iIPv6 address assignment for the home LAN, but really solved it? If
>>> so, how did you do that?
>>>
>>> Would getting and implementing an IPv6 assignment from our ISP cure
>>> the problem, or make it worse?
>>>
>>> I've found little guidance from MSFT about DirectAccess in an IPv6
>>> environment, though I admit I haven't been terribly diligent in my
>>> searches.
>>>
>>> Kurt
>>>
>>
>>
>>