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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
