Re: FYI: DNSOPS presentation

[Tore Anderson <tore.anderson@redpill-linpro.com>]

* Philip Homburg

> In discussion about 6to4, and other automatic tunneling protocols,
> the big problem seems to be the first hop. I think most of the
> problems would be solved if a 6to4 router would verify the
> performance of the tunnel.

I see, just like I think Microsoft is considering doing.  Yes, I think
that would help quite a bit.  However, due to the asymmetric nature of
anycasted 6to4, it could very well be that even if the connectivity test
to destination A succeeds, connectivity will still be broken for
destination B - because A and B does not necessarily use the same return
relay.

In my opinion, anycasted 6to4 is fine as a last-resort option (along
with e.g. Teredo) for a IPv4-only host to access IPv6-only content.
But it is not as reliable as regular IPv4, and should therefore never be
preferred above it.

>> I think Windows XP did some form of reachability testing and would 
>> disable the 6to4 interface entirely if it failed.  They removed it
>> in Vista, but I've heard they're now considering putting back in.
>> But Windows doesn't cause much problems anyway, since it appears
>> their RFC 3484 implementation already implements section 2.7 from 
>> draft-arifumi-6man-rfc3484-revise-02.  (You can argue that the
>> Windows implementation is the reference implementation, as it was
>> Microsoft who authored RFC 3484 to begin with.)
> 
> Does that mean that this policy will prefer a NAT44 IPv4 over a
> configured tunnel?

Yes, that the effect of the change proposed in
draft-arifumi-6man-rfc3484-revise-02, and also how Microsoft's
getaddrinfo() currently behaves.  I strongly support the proposed change.

RFC 3484, however, currently says to prefer 6to4 over IPv4 NAT44 (or
more precisely RFC 1918 IPv4).

> A 6to4 router (like an Airport) could stop advertising the prefix
> when the 6ro4 default router is unreachable, but nobody does that.

Nope.  However, if 6to4 was only used by the end-user operating
system/applications as a last resort connectivity method, this would not
be necessary.  And that is clearly the _intention_ of RFC 3484, which
says to «avoid the use of transitional addresses when native addresses
are available».  I suppose NAT44 wasn't used as widely as now back when
the RFC was written.

> In theory, web browser could configure faster timeout in TCP
> connection setups when destination unreachable ICMPs are received,
> but usually the ICMPs are not there (and the API is probably not
> there either).

Yep, a ICMP dest unreachable (or TCP RST) would cause a rapid fallback.
However, no 6to4 implementation I've seen will transform an outer ICMPv4
dest unreachable to an inner ICMPv6 unreachable that actually will reach
the web browser application.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27