Subject: 2461bis: address resolution failure as a hard error?

From: Pekka Savola <[email-masked]>
Date: Tue, 3 Aug 2004 22:42:46 +0300 (EEST)

Hi,

I'd like for the WG to consider one addition / spelling out for 
2461bis in section 7.2.2 on address resolution:

   If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT
   solicitations, address resolution has failed.  The sender MUST return
   ICMP destination unreachable indications with code 3 (Address
   Unreachable) for each packet queued awaiting address resolution.

Add something like:

   The ICMP indication of local address resolution failure SHOULD be 
   treated as a hard error [RFC1122].

(the language is a bit wishy-washy because I don't want all the
address unreachable ICMP messages to be treated like this, just the
ones which the host in question generated "internally")

.. the justification is that if one tries to establish communications 
on a local link, or if the router has gone down and you can't send the 
packet to anyone, TCP should fail over and try another address (or 
address family); this is important e.g., if you have v4 and v6 on a 
link, and they go through different routers.

This is already done at least by one implementation; I don't know how
common this kind of interpretation is, but it is probably worth
spelling out so that it can be considered in more general as needed.

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 3 Aug 2004 17:05:28 -0700 (PDT)

> link, and they go through different routers.

Two comments:
1. The term "local address resolution" isn't defined so I doubt the 
   above text suggestion clearly communicates what you want to say.
2. I can see this as useful when there is an alternative (which is your 
   motivation), but I'm concerned that treating it as a hard failure when there
   is no alternative is detrimental. 

Another approach would be to attack the more general issue, which I would
state as "when there are alternatives, treat soft errors and an indication
to try an alternative".

   Erik

---

From: Pekka Savola <[email-masked]>
Date: Wed, 4 Aug 2004 03:32:24 +0300 (EEST)

>    above text suggestion clearly communicates what you want to say.

Right.  Maybe just remove "local" then, making it a bit more ambiguous 
but more accurate? :-)

   The ICMP indication of address resolution failure SHOULD be 
   treated as a hard error [RFC1122].

>    is no alternative is detrimental. 

But if ND resulution fails, is it probable that it's going to be fixed
any time soon?  If the app just aborts if net connectivity is down,
the user can try again soon?  At least to me, timely notification of a
serious network error that's blocking my access is a good thing.
 
> state as "when there are alternatives, treat soft errors and an indication

But I fail to see how the code would know if there are actually 
implementations.  Two subsequent ND requests or ND+ARP are independent 
of each other..

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 3 Aug 2004 17:39:06 -0700 (PDT)

> serious network error that's blocking my access is a good thing.

If the (wireless) host is out of range for 9 seconds you'll get a
failure. When the truck moves out of the way things will work again.

So this can recover a lot faster than BGP and I don't think we want to
treat ICMP host unreachable as hard errors.

Making anything a hard error seems to imply that TCP would immediately
give up, whether the connection was already established or in the process
of being established.

> implementations.  Two subsequent ND requests or ND+ARP are independent 

If you have something which is aware of their being alternative destination
addresses (such as SCTP, or TCP with an API that allows multiple IP addresses
to be passed with connect, or some future multi6 solution),
then this can be made to react to an ICMP soft error as a hint to try a
different destination address.

Thus the ND code doesn't need to know; the thing above the IP layer would know.

   Erik

---

From: Pekka Savola <[email-masked]>
Date: Wed, 4 Aug 2004 04:02:59 +0300 (EEST)

[...]
> give up, whether the connection was already established or in the process

Unfortunately, yes.

But that is not such a big problem as I see it.  Remember, for
sessions that are already established, this only happens through the
NUD process.  By default, that's 30 seconds, or until you want to
actually communicate (e.g., quiet SSH sessions would not be reset) if
the implementations conforms to the note:

      Note: An implementation may actually defer changing the state from
      REACHABLE to STALE until a packet is sent to the neighbor, i.e.,
      there need not be an explicit timeout event associated with the
      expiration of ReachableTime.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 3 Aug 2004 18:15:47 -0700 (PDT)

> the implementations conforms to the note:

Not so. See section 5.3 in RFC 2461.

Thus if the SSH session is idle, an implementation might garbage collect
the Neighbor Cache Entry. As a result, when ssh/tcp is sending data again,
ND would need to go through address resolution again.
If there is a 9 second outage at that point in time, treating this is
as a hard error, would result in a failure of the TCP connection.

  Erik