Subject: Fwd: New Version Notification for draft-nordmark-6man-impatient-nud-01.txt

From: Erik Nordmark <[email-masked]>
Date: Thu, 07 Jul 2011 13:41:41 -0700

This has some more details based on the mailing list discussion, and 
references draft-gashinsky-v6nd-enhance-00 for further motivation.

    Erik

-------- Original Message --------
Subject: New Version Notification for 
draft-nordmark-6man-impatient-nud-01.txt
Date: Thu, 07 Jul 2011 13:33:06 -0700
From: [email-masked]

A new version of I-D, draft-nordmark-6man-impatient-nud-01.txt has been 
successfully submitted by Erik Nordmark and posted to the IETF repository.

Filename:	 draft-nordmark-6man-impatient-nud
Revision:	 01
Title:		 Neighbor Unreachability Detection is too impatient
Creation date:	 2011-07-07
WG ID:		 Individual Submission
Number of pages: 7

Abstract:
    IPv6 Neighbor Discovery includes Neighbor Unreachability Detection.
    That function is very useful when a host has an alternative, for
    instance multiple default routers, since it allows the host to switch
    to the alternative in short time.  This time is 3 seconds after the
    node starts probing.  However, if there are no alternatives, this is
    far too impatient.  This document proposes an approach where an
    implementation can choose the timeout behavior to be different based
    on whether or not there are alternatives.

The IETF Secretariat

---

From: Philip Homburg <[email-masked]>
Date: Wed, 20 Jul 2011 18:17:13 +0200

>successfully submitted by Erik Nordmark and posted to the IETF repository.

A few remarks about this draft:
1) It must be somewhere in RFC-4861, but it is not easy to find and it's 
   probably best to help implementors here: if a NCE for a router transitions
   to UNREACHABLE state and there are still default routers in REACHABLE,
   STALE, DELAY, or PROBE state then delete all destination Cache entries
   for that router.
2) Similar for redirect. If there is a Destination Cache entry and it resulted
   from a redirect, then delete it. Also update the host state description 
   for the destination cache to include a redirected flag.
3) As long as the the NCE is in UNREACHABLE state, there won't be any 
   Destination Unreachable ICMPs. I think there are two ways of dealing with
   that:
   - delete the NCE entry after some time. This requires the operator to
     balance between keeping the entry longer of getting timely ICMPs.
   - After while, just send ICMPs back while forwarding the packet. I don't
     know if anybody ever did this. This may result in duplicate packets. But
     there is something wrong with the connection anyhow.

In general I think this a good approach.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Jul 2011 10:17:51 -0700

>> successfully submitted by Erik Nordmark and posted to the IETF repository.

Thanks for your review.

>     STALE, DELAY, or PROBE state then delete all destination Cache entries

The RFC in section 5.2 says to redo next-hop selection; it doesn't say 
to delete destination cache entries anywhere AFAIK.
That should be sufficient even with the introduction of the UNREACHABLE 
state.

>     for the destination cache to include a redirected flag.

I don't understand why this draft requires adding a redirect flag in RFC 
4861. While such a flag might be useful in an implementation, it seems 
to be orthogonal to these proposed changes; whether the NCE becomes 
deleted (as in 4861 today) or marked as UNREACHABLE (with these changes) 
the same next-hop selection needs to be triggered. (Perhaps that should 
be stated more explicitly in the draft.)

>     Destination Unreachable ICMPs.

Good point - I didn't realize the exact wording in section 7.2.2.
FWIW it says
    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.

> I think there are two ways of dealing with
>     that:

We could do the latter my augmenting the above text to also say to send 
ICMP destination unreachables (with code 3) when the packet is sent 
using a NCE that is in UNREACHABLE state.

    Erik

---

From: Philip Homburg <[email-masked]>
Date: Wed, 20 Jul 2011 19:58:05 +0200

>That should be sufficient even with the introduction of the UNREACHABLE 

I don't think the algorithm in 5.2 works all that well. In RFC-4861, when
NUD has failed, the NCE is deleted. However, this does not actually
signal anything to Destination Cache entries. There is only some wording
that some things need to be done. Without any specification on how that is
triggered exactly.

Deleting, or otherwise marking as invalid the DCEs that correspond to the 
failing router is the easiest way to get the right result.

>be stated more explicitly in the draft.)

In general, you can't figure out if NCE entry is the result of a redirect.
You would have to examine the DCE to see if the destination is off-link.

The easiest way is to always delete DCEs that refer to the NCE. The
conceptual Destination Cache doesn't have to concept of entries that need
next-hop selection.

Now, this may not be the place to actually update all those parts of RFC-4861.
But giving some hints on how things can be implemented may help.

>using a NCE that is in UNREACHABLE state.

While dropping the packet or also forwarding it using the last known MAC?