Hi Mark: A new ND registration model is being developed at 6LoWPAN to enable a proactive population of the ND cache - table, really -. Applying the ND registration to the P2P link case, the endpoint routers would need to register to one another prior to delivering packets on that link. Any packet for the subnet on link that does not match an NC Entry would be dropped as opposed to blindly passed to the other end. I tried at some point to modernize RFC 3122 but it seems a better approach to generalize the ND registration to P2p in particular and NBMA links at large.
What do you think? Pascal > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Mark Smith > Sent: Thursday, July 15, 2010 12:03 AM > To: [email protected] > Cc: [email protected]; [email protected] > Subject: Re: ND NS/NA support required on point-to-point links? > > On Wed, 14 Jul 2010 15:25:54 +0200 (CEST) [email protected] wrote: > > > > >However, it would seem that several of the major vendors (e.g. > > > >Cisco, > > > >Juniper) have interpreted this differently, and chosen not to > > > >perform ND on point-to-point links. > > > > > > Do you mean perform, as in issue the NS request or also in not > > > responding to a NS request from the peer? > > > > I have no idea whether an NS request would be answered on a > > point-to-point link for these vendors. When I have tested this in the > > lab, the observed behavior is that an NS request is never issued. > > > > It's also a bit interesting to look at the multicast groups that have been > subscribed to on the interfaces. Some of the implementations subscribe to the > solicited node multicast group(s) for the local addresses. It's as though they're > "half" ND NS/NA enabled. > > > > So I wonder, with all the IPv6 interoperability testing and > > > certification going on, how come nobody ever noticed that this is an issue? > > > > The ping-pong behavior on IPv6 point-to-point links has most certainly > > been noticed, see for instance > > > > It seems the the consequence of not implementing ND NS/NA on point-to-point > links has been noticed, not the root cause. The root cause seems to be an > assumption that any non-local interface addresses on the link within a prefix > must exist and are always available at the other end of the point-to-point link, > so traffic can be forwarded onto that link without validating that assumption. > When implementations at both ends of the link are making that assumption, > the ping pong problem is the result. > > > > > http://tools.ietf.org/html/draft-ietf-ipngwg-p2p-pingpong-00 > > http://tools.ietf.org/html/draft-kohno-ipv6-prefixlen-p2p-00 > > > > http://www.janog.gr.jp/meeting/janog22/program/day2/data/day2-1-e.pdf > > > > Steinar Haug, Nethelp consulting, [email protected] > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
