Re: FYI: DNSOPS presentation

[Philip Homburg <pch-v6ops@u-1.phicoh.com>]

In your letter dated Tue, 20 Apr 2010 11:44:20 +0200 you wrote:
>> The thing that IMHO went wrong here is that the first thing everybody
>> does is disable neighbor discovery, and therefore also neighbor
>> unreachability detection.
>
>Are you talking about ICMPv6 ND here?  If so, that is not end-to-end, it
>only works on a link, similar to IPv4 ARP.  It is end-to-end
>connectivity that is broken, so I fail to understand what you feel could
>be done better here?

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.

>> Eventhough it is perfectly possible to find out that a connection
>> doesn't work, in practice nobody does anything with that option.
>
>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?

>> To some extent that is also due to lack of standards. For example, if
>> source address selection had an option to skip source addresses if
>> the route to the destination is down, then a host with a broken IPv6
>> configuration would fall back to just IPv4.
>
>Actually, this is part of RFC 3484 already:
>
>>    Rule 1:  Avoid unusable destinations.
>>    If DB is known to be unreachable or if Source(DB) is undefined, then
>>    prefer DA.  Similarly, if DA is known to be unreachable or if
>>    Source(DA) is undefined, then prefer DB.
>
>Applications will also fall back to IPv4 if the initial IPv6 connection
>failed.  However for latency-sensitive applications that make use of
>many short-lived connections (HTTP is a good example), this timeout is
>so long that preferring defective IPv6 above working IPv4 will
>essentially render the application useless.

That's the problem. At the moment the host usually doesn't know.

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

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).