TCP, multiple addresses and soft errors when connecting

[Pekka Savola <pekkas@netcore.fi>]

Hi all (mainly the TCP guys!),

v6ops WG is in the process of documenting issues which are caused or 
made more severe by the introduction of IPv6.  The document is 
draft-ietf-v6ops-v6onbydefault-01.txt

TCP timeouts when connecting to a destination, but when the 
destination is unreachable (e.g., because you don't have global IPv6 
routes, your first-hop router is not operational, the packets are sent 
on-link by default, etc.), TCP does not abort the connectivity (and 
try the next address quicker -- instead of waiting for the TCP 
timeout).

The critical observation to make here is as IPv6 addresses are tried
first (I'm simplifying; it's more complex than that), one must cycle
through all the addresses, before trying with IPv4.  However, IPv4
connections might still work! With TCP timeouts, this takes a lot of
time --- and should be made quicker.

There is going to be a WG last call on the document soon, aimed for 
Informational -- just for documenting the issues.  The actual fixes 
(or not) would have to be done elsewhere (e.g., in TCPM WG ;-).

Please provide feedback especially on the language used for TCP.  
(Below.)

draft-ietf-v6ops-v6onbydefault-01.txt:

==========
2.3.1 TCP Implications

   In the case of a socket application attempting a connection via TCP,
   it would be unreasonable for the application to block even after the
   system has received notification that the destination address is
   unreachable via an ICMPv6 Destination Unreachable message.

   Following are some ways of solving TCP related delays associated with
   destination unreachability when ICMPv6 errors are generated.

2.3.1.1 TCP Connection Termination

   One solution is for TCP to abort connections in SYN-SENT or
   SYN-RECEIVED state when it receives an ICMPv6 Destination Unreachable
   message.

   [HOSTREQS] document, in section 4.2.3.9., states that TCP MUST NOT
   abort connections when receiving ICMP Destination Unreachable
   messages that indicate "soft errors", where soft errors are defined
   as ICMP codes 0 (network unreachable), 1 (host unreachable), and 5 
   (source route failed), and SHOULD abort connections upon receiving 
   the other codes (which are considered "hard errors").  ICMPv6 didn't
   exist when that document was written, but one could extrapolate the 
   concept of soft errors to ICMPv6 Type 1 codes 0 (no route to
   destination) and 3 (address unreachable), and hard errors to the
   other codes. Thus, it could be argued that a TCP implementation that
   behaves as suggested in this section is in conflict with [HOSTREQS].

   When [HOSTREQS] was written, most applications would mostly only try
   one address when establishing communication with a destination.  Not
   aborting a connection was a sane thing to do if re-trying a single
   address was a better alternative over quitting the application
   altogether. With IPv6, and especially on dual stack systems,
   destinations are often assigned multiple addresses (at least one IPv4
   and one IPv6 address), and applications iterate through destination  
   addresses when attempting connections.

   Since soft errors conditions are those that would entice an
   application to continue iterating to another address, TCP shouldn't 
   make the distinction between ICMPv6 soft errors and hard errors when
   in SYN-SENT or SYN-RECEIVED state.  It should abort a connection in
   those states when receiving any ICMPv6 Destination Unreachable
   message.  When in any other state, TCP would behave as described in 
   [HOSTREQS].

   Many TCP implementations already behave this way, but others do not.
   This should be noted as a best current practice in this case.

   A tangential method of handling the problem in this way would be for
   applications to somehow notify the TCP layer of their preference in
   the matter.  An application could notify TCP that it should abort a
   connection upon receipt of particular ICMPv6 errors.  Similarly, it 
   could notify TCP that it should not abort a connection.  This would 
   allow existing TCP implementations to maintain their status quo at 
   the expense of increased application complexity.

2.3.1.2 Asynchronous Application Notification

   In section 4.2.4.1, [HOSTREQS] states that there MUST be a mechanism
   for reporting soft TCP error conditions to the application. Such a  
   mechanism (assuming one is implemented) could be used by applications
   to cycle through destination addresses.
===========

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