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] 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. 3) If the SP doesn't have IPv6 transit, they still have to return ICMPv6 destination unreachable messages.
[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