Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt

[Erik Nordmark <[e-mail]>]

On 5/23/11 1:03 PM, Ray Hunter wrote:
> re: http://tools.ietf.org/html/draft-nordmark-6man-impatient-nud-00
>
> I'm afraid have more questions than answers.
>
> Are there any implications for different nodes having different NUD
> timeout behavior on a link, and this no longer being symmetrical?

No - the reachability state in RFC 4861 is unidirectional. This can 
easily happen today on a host when TCP provides reachability 
confirmations to the IP stack, which just indicates forward reachability 
to the nexthop router. The return traffic might arrive to the host from 
a different router.

> If I can think of two examples......
>
> e.g. 1. Say Node A (router) declares node C (end node) unreachable but
> Node B (alternate back up router) has not yet timed out node C?
>
> I'm guessing this case is just like a split-brain segment, so is not
> significant compared to existing failures.
>
> Now the case of router failover....
>
> e.g. 2. Say Node A (end host) declares node B (router) unreachable
> locally, but node B (router) is still up and running but has not yet
> timed out Node A.
>
> Is that significant? I suspect so. After all if the raison d'etre of
> changing NUD timers is to quicken / slow down router failover, surely
> Node B (the router) also has to time out at the same speed as the end
> host (Node A) otherwise the router will continue to advertise valid
> routes to node A, and packets will black hole/queue anyway until NUD on
> node B also notices the failure.

Are you assuming that the routers inject host routes into the routing 
system based on the ND state? The routers inject a route for the subnet 
prefix which isn't tied to the ND state in any way.

(If you look at 6lowpan plus roll you'll see a different behavior, which 
is part of the reason for having explicit host registration in 
draft-ietf-6lowpan-nd.)

> Vice versa is also true, if the router notices the failure first, but
> the end node does not react to the failure and hangs around retrying
> NUD, packets may queue/black hole in the other direction.
 >
> In the good old days we had things like gratuitous ARP for such events
> to attempt to wake up end nodes to refresh their cache, but if they got
> lost in some layer 2 STP thrashing it didn't help much anyway.
>
> Is there thus a need for any over-ridden NUD parameters to be
> synchronized across all nodes on a link e.g. via RA messages?

No.

> Is there a minimum and maximum timeout needed? To prevent danger of an
> update storm [as specified in RFC2461 that all Neighbor Solicitations
> are rate-limited on a per-neighbor basis] or "stuck in stale".

A rate limit makes sense. RFC 4861 already has this with one per second. 
If ND retransmits more than three times it probably makes sense to 
recommend binary exponential backoff for the timer.

   Erik



> regards,
> RayH
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>