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

[Erik Nordmark <[e-mail]>]

On 7/20/11 9:17 AM, Philip Homburg wrote:
> In your letter dated Thu, 07 Jul 2011 13:41:41 -0700 you wrote:
>> 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.

Thanks for your review.

> 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.

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.

> 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.

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.)

> 3) As long as the the NCE is in UNREACHABLE state, there won't be any
>     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:
>     - 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.

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

> In general I think this a good approach.
>