Subject: Re: Usability enhancement for IP6
To: Miles Nordin <carton@Ivy.NET>
From: Fernando Gont <>
List: tech-net
Date: 02/06/2005 07:37:50
At 00:39 06/02/2005 -0500, Miles Nordin wrote:

>     bp> configurable via sysctl (or make it dependent on
>     bp> net.inet6.ip6.v6only) would be better.
>my vote would be to make good decisions, and not punting too much to
>sysctl.  It's not appropriate to expect sysadmins to be intimately
>familiar with all these minute details, and I don't want to see magic
>sysctl.conf files that the user doesn't know what they do passed about
>like modem init strings in the BBS days.

The proposal I submitted to the IETF suggests that the default behaviour 
should be to abort connection attempts upon recepit of an ICMP unreachable 
(any of them), but that a system-wide toggle could be provided for those 
*rare* cases in which this could make harm.

>I think an ICMP unreachable should kill a TCP connection attempt
>immediately.  It's not just IPv6---it's also a problem with firewalls.
>Linux responds to PF's ``administratively unreachable'' message

Of course I agree. A typical example is a domain name that maps to several 
IP addresses. If the first ones are unreachable, then why would one spend 
several *minutes* trying to connect to them, instead of skipping them and 
trying the next ones in the list?

This is extensively discussed in the draft.

>sakima:~$ telnet
>telnet: connect to address No route to host
>while NetBSD just sits there.  With the new behavior, nothing stops
>you from retrying at the application layer, and most applications
>where it makes sense already do that.

Completely agree. For non-interactive applications, application-layer 
retranmissions are already implemented. For example, think about MTAa.
For interactive applications, there's no real success if the connection 
attempt succeeds after several minutes or dozen of seconds. Studies in this 
field suggest the user won't wait that much.
If there's only one IP address to try, and this new behaviour makes 
connect() fail, the user himself will likely trigger a retransmission. For 
a web browser, think about the user clicking "Refresh" or "Reload".

Best regards,

Fernando Gont
e-mail: ||