Re: ND NS/NA support required on point-to-point links?

Hi Pascal,

On Thu, 15 Jul 2010 11:33:03 +0200
"Pascal Thubert (pthubert)" <pthubert@cisco.com> wrote:

> 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?

Coincidentally, I bought the 6LoWPAN books last week, and have just
been reading about the ND NR/NC protocol on the train to and from work
in the last day or so. That seems like a good alternative to ND NS/NA.
I think it'd achieve the goal of being able to generate ICMP
destination unreachables, eliminate the ping-pong problem, and preserve
the simplicity of universal /64 assignments to all link types. I
haven't come across whether NUD is still performed in 6LoWPAN, however
since the scenario we're talking about isn't likely to be as low
bandwidth or power sensitive, I think NUD could be used to further
reduce the detection time of failed nodes, in addition to the ND NR
registration expiry time.

That model would also seem to be a good method to significantly mitigate
the off-link source ND cache attack on LAN /64s, preventing that attack
from e.g. Internet sources. Although the default router's neighbor cache
would be vulnerable to malicious onlink devices, which could use ND NR
messages to exhaust the cache, those devices have a far more of a
vested interest in the default router(s) staying available, so they're
much less likely to attempt it compared to Internet origin attackers
who suffer no consequence if successful.

I seem to remember a discussion I had with Erik Nordmark a while back,
after I suggested the idea of using MLD joins for the solicited node
address as a method of validating neighbor cache entries, where he
thought that ultimately a registration protocol would be the best
solution. It'd seem that this 6lowpan ND NR/NC protocol would be a good
candidate for resolving these issues.

Regards,
Mark.

> 
> Pascal
> 
> > -----Original Message-----
> > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf
> Of
> > Mark Smith
> > Sent: Thursday, July 15, 2010 12:03 AM
> > To: sthaug@nethelp.no
> > Cc: ipv6@ietf.org; dthaler@microsoft.com
> > Subject: Re: ND NS/NA support required on point-to-point links?
> > 
> > On Wed, 14 Jul 2010 15:25:54 +0200 (CEST) sthaug@nethelp.no 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, sthaug@nethelp.no
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------