RE: v6-v4 transition scenarios, take 2

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Hi Nathan, 

>-----Original Message-----
>From: Nathan Ward [mailto:v6ops@daork.net] 
>Sent: Monday, August 04, 2008 8:08 AM
>To: v6ops WG
>Subject: Re: v6-v4 transition scenarios, take 2
>
>On 5/08/2008, at 2:44 AM, Templin, Fred L wrote:
>
>>> The problem here of course is that Vista and some XP service pack 2
>>> machines, should they be given one of these addresses will 
>attempt to
>>> bring up 6to4 as it is a non-RFC1918 address.
>>> There are two work-arounds for this that I can see, and I 
>think it is
>>> a good idea to do both.
>>> 1) Enable IPv6 on the access. If windows has a native IPv6 
>address it
>>> won't attempt to bring up 6to4.
>>>     - If you don't have an IPv6 transit service, still do this, but
>>> simply return ICMPv6 destination unreachable messages.
>>> 2) Direct all IPv4 protocol 41 (IPv6 over IPv4, 6to4) messages to a
>>> 6to4 relay, which returns ICMPv6 destination unreachable messages,
>>> encapsulated in IPv4 as per 6to4. Windows will bring up 6to4,
>>> but will
>>> get error messages back so will fall back to IPv4 without 
>waiting for
>>> a time out.
>>
>> Another possibility is to configure the NAT as an ISATAP
>> router and have the end systems use ISATAP.
>
>
>I considered this, however:
>1) End user PCs seldom have their domain name configured to be 
>that of  
>their ISP.[1]

I'm not sure I see the problem. The end-user PCs will see
a connection-specific DNS suffix, and will have a well-
formed FQDN to use when they concatenate that with the
prefix "isatap".

>2) Any host behind customer NAT will also attempt ISATAP - if this  
>succeeds the end host will use its interface address for the 
>last part  
>of the ISATAP IPv6 address, which if RFC1918 (more than 
>likely!), will  
>not be unique within the SP's ISATAP domain.

There is no requirement that the interface ID be unique as
long as the IPv6 prefixes are distinct. Consider that if you
have a prefix delegation hierarchy, and each level of the
hierarchy is doing ISATAP, you will always have distinct
prefixes and distinct, non-overlapping ISATAP domains.

>3) If the SP doesn't have IPv6 transit, they still have to return  
>ICMPv6 destination unreachable messages.

The idea is that the cusomter NAT becomes an IPv6 router.
It does ISATAP on the customer-facing side and some other
IPv6 capability on the SP-facing side. That could be a
native IPv6 service, 6to4, or it could even be another
ISATAP domain that is distinct and separate from the
customer's ISATAP domain.

If the SP can't provide an IPv6 service of any kind,
then there is always the possibility to use Teredo.

Fred
fred.l.templin@boeing.com

>
>[1] My understanding is that Windows looks for A records for ISATAP. 
>$domain.. Section 9 of RFC4214 suggests that that's the right 
>thing to  
>do. Perhaps looking for ISATAP. before ISATAP.$domain. would 
>have been  
>preferable, but I'm operating under the assumption that we have to  
>allow for the behaviour of anything in the wild as of now, as as we  
>know, not everyone runs their Windows updates every week.
>
>--
>Nathan Ward
>
>
>
>
>
>