playing catchup ... Jared Mauch <ja...@puck.nether.net> writes:
> To (re)state the biggest design issue with NDP again, it's outlined > in 7.3 of the v6nd-enhance draft: > -- snip -- > 7.3. NDP Protocol Gratuitous NA > Per RFC 4861, section 7.2.5 and 7.2.6 [RFC4861] requires that > unsolicited neighbor advertisements result in the receiver setting > it's neighbor cache entry to STALE, kicking off the resolution of the > neighbor using neighbor solicitation. > -- snip -- > Forcing an entry to STALE if you see an unsolicited NA (assuming it > matches the existing NA) seems unnecessary and counterproductive as > it can interrupt traffic to existing hosts. It shouldn't. A STALE entry is still usable, but it's a flag that says "verify that this entry is still correct, it may no longer be correct". You then wait a little while, and hope that TCP connections that are flowing through the specific entry get ACKs for the data they are sending, which in turn should get the state changed back to VALID. All without any additional ND traffic. Only if a node is sending traffic to a neighbor in a STALE state, and no TCP "forward progress" indications (i.e. ACKs) are updating the entry, then you send out a a (unicast) NS. Changing the above text in RFC cited above would significantly change the robustness of NUD. One would no longer detect failures where connectivity between neighbors is only unidirectional. I also do not understand how such a change would actually address the problem described in draft-gashinsky-v6nd-enhance-00.txt. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
