Subject: Re: Usability enhancement for IP6
To: Miles Nordin <carton@Ivy.NET>
From: Fernando Gont <email@example.com>
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 192.168.1.114
>telnet: connect to address 192.168.1.114: 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".
e-mail: firstname.lastname@example.org || email@example.com