Erik Kline and I wrote up an experience we had with NUD and a broken IPv6 firewall on my home network.
http://sites.google.com/site/ipv6center/icmpv6-is-non-optional In short, NUD thought that a host which was in the neighbor cache really wasn't available (due to incorrect FW blocking at the host) removed it from the neighbor cache and started dropping packets (and causing timeouts in gmail). In test, it took about 8 pings for the problem to manifest (time for NUD to retry enough to fail), which was followed by the classic IPv6 to IPv4 failover by the host (Windows Vista). On one hand, if NUD had been more patient we may have never noticed. However, tracking down a bug that showed up less often would have clearly been more difficult to diagnose. Double-edged sword. Also, the Broadband Forum's WT-146 (which isn't a public document, but if you are BBF member you can take a look at it) specifies NUD as a monitoring mechanism for "IPv6 sessions" over access links (which ultimately may be tied into billing, alerts, etc.). - Mark On May 23, 2011, at 8:46 PM, Erik Nordmark wrote: > > This draft proposes to change the requirement that NUD can not retransmit > more than three times, so that NUD can be more robust against temporary > network outages. > > Comments? > > Erik > > -------- Original Message -------- > Subject: New Version Notification for draft-nordmark-6man-impatient-nud-00.txt > Date: Mon, 23 May 2011 11:43:16 -0700 > From: internet-dra...@ietf.org > To: nordm...@cisco.com > CC: nordm...@cisco.com > > A new version of I-D, draft-nordmark-6man-impatient-nud-00.txt has been > successfully submitted by Erik Nordmark and posted to the IETF repository. > > Filename: draft-nordmark-6man-impatient-nud > Revision: 00 > Title: Neighbor Unreachability Detection is too impatient > Creation date: 2011-05-23 > WG ID: Individual Submission > Number of pages: 5 > > 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 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
