Subject: TCP and ICMP soft-errors in IPv4/6 environments

From: Pekka Savola <[email-masked]>
Date: Thu, 30 Oct 2003 22:14:24 +0200 (EET)

Hi,

(Targeted at Transport area, v6ops is there just to keep v6ops in the
loop, this has already been discussed there at some length..)

With dual-stack IPv4/6 deployments, when a TCP connection is tried to both
an IPv6 and IPv4 address, these are done in serial w/ a getaddrinfo loop
(in the typical case).  If the first destination is unreachable (e.g.
resulting in a host unreachable ICMPv6 message).  

The old host requirements document states that TCP MUST NOT abort
connections on such soft errors. However, this poses some problems in
current deployments where multiple addresses are tried sequentially, as
summarized above.

This is discussed more in section 2.3 of:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6onbydefault-00.txt

Has this been discussed in the transport area?  Is there something to be 
done about this, e.g. a BCP document discussing this practice and 
suggesting ICMP DU's are OK when establishing connections -- or something 
else?

Pekka
 Writing as v6ops co-chair

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 30 Oct 2003 16:22:44 -0500

> suggesting ICMP DU's are OK when establishing connections -- or something 

Maybe the right answer here is a "slewed parallel" connection
establishment; start with one address, and if you get a soft error or
a RTO-sized timeout, try a second, third, fourth, etc., connection,
but leave the prior ones open in the event they complete successfully.

Soft errors wouldn't kill the first connection -- they'd just be a a
hint to try another connection in parallel.

This should probably be buried in a library routine so that
applications don't have to reinvent this wheel.

					- Bill

---

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Oct 2003 13:29:36 +0200 (EET)

> applications don't have to reinvent this wheel.

This is probably an obvious first thought, as what would be the desirable
behaviour.  But what would that imply in practice?  That at least some
parts of the basic API functions like connect() be augmented by a set of
new functions for managing connectivity?  That could be a forever-project,
while what we'd like is to get a fix that'd be usable in this decade :-).

I'm not saying that's not a probably relevant option to consider, but I 
think folks have been thinking about replacing APIs before and not much 
has come out of it.. so I'm a bit reluctant to start on that particular 
path...