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

From: Mark Smith <[email-masked]>
Date: Sun, 11 Jul 2010 12:03:43 +0930

Hi,

I've come across a number of implementations of IPv6 on point-to-point
links which aren't performing ND NS/NA transactions. My interpretation
of the Neighbor Discovery RFC, and, as an example of a link
layer RFC, the IPv6 over PPP RFC, is that they should. I'm looking for
some clarification to determine if my interpretation is correct and
therefore I can report bugs with the implementations I'm working with.

These implementations, instead of performing ND NS/NA, "blindly" forward
IPv6 packets onto directly onto the point-to-point link, regardless of
whether the destination address exists. If both ends of the link don't
perform ND NS/NA transactions, the packet will be looped back and forth
until it's hop count expires - i.e. the ping-pong problem.

RFC4443 (ICMPv6) currently provides a mechanism to deal with this
situation to deal with this situation -

"  One specific case in which a Destination Unreachable message is sent
   with a code 3 is in response to a packet received by a router from a
   point-to-point link, destined to an address within a subnet assigned
   to that same link (other than one of the receiving router's own
   addresses).  In such a case, the packet MUST NOT be forwarded back
   onto the arrival link."

The proposal for supporting /127s on point-to-point links is another
mitigation.

My broad understanding of the goal of moving neighbour discovery into
ICMP in IPv6, instead of having a separate protocol like ARP, was to
try to minimise the required number of layer 2 to layer 3 adaption
protocols required for IPv6. If a link layer could meet or emulate a
basic set of requirements, then standard ICMPv6 neighbor discovery
could operate over the link without any link specific changes.

The ND RFC seems to support this - from the Introduction -

"  Unless specified otherwise (in a document that covers operating IP
   over a particular link type) this document applies to all link types.
   However, because ND uses link-layer multicast for some of its
   services, it is possible that on some link types (e.g., Non-Broadcast
   Multi-Access (NBMA) links), alternative protocols or mechanisms to
   implement those services will be specified (in the appropriate
   document covering the operation of IP over a particular link type)."

Specific to point-to-point links, it says (in 2.2. Link Types) -

"  point-to-point - a link that connects exactly two interfaces.  A
                    point-to-point link is assumed to have multicast
                    capability and a link-local address."

So it seems to me that point-to-point links don't need any special
treatment, and all RFC4861 ND mechanisms should be implemented on them,
including address resolution via NS/ND.

Another thing that I think indirectly supports this is the standardised
64 bit Interface ID, and therefor the /64 prefix length.

When a prefix length is assigned to a link, it is specifying a range of
a addresses assigned to that link. In other words, within the
address space of the network, this link is the final destination for any
traffic directed towards both the assigned prefix and any addresses that
fall within the assigned range.

What a prefix length doesn't say is that the addresses are
specifically assigned to devices attached to the link, and that those
devices are available to send packets to. If a protocol wishes to test
that availability, then it'd need to probe those addresses.
Even a prefix length that only allows for one other address at the
remote end of the link i.e. /127 in IPv6, doesn't make any statements
of assignment of that address and it's availability.

If a protocol chooses to generate Destination Unreachable messages,
then, despite the prefix length assigned to a link, including one that
only allows for "another" address, such as a /127, then it must probe
addresses for availability. The IPv6 ND RFC says it MUST -

"If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT
   solicitations, address resolution has failed.  The sender MUST return
   ICMP destination unreachable indications with code 3 (Address
   Unreachable) for each packet queued awaiting address resolution."

So these implementations that aren't implementing ND NS/NA on
point-to-point links can't generate ICMP destination unreachables,
because they're not probing for individual address assignment and
availability. Allowing a /127 prefix length in IPv6 won't fix that.

I don't think the RFC4443 mitigation would have been necessary if ND
NS/NA had been implemented on point-to-point links in the first place. A
significant drawback of this mitigation is that for every packet
received over a point-to-point link (i.e. one that doesn't implement ND
NS/NA), state has to be maintained to be determine whether the packet is
going to be sent back out the point-to-point interface it entered by,
so that a Destination Unreachable Message can be generated in this
case. This state is likely to have to be maintained in the control
plane of the router, impacting it's forwarding performance.

In summary, it seems to me that IPv6 Neighbor Discovery Address
Resolution is serving two purposes -

o  resolution of layer 3 addresses to layer 2 addresses

o  testing the availability of layer 3 addresses, for the purpose of
generating Destination Unreachable Messages

The first purpose isn't necessary for point-to-point links, however if
IPv6 requires Destination Unreachable Messages to be generated for
addresses that aren't available, then my interpretation is that ND
NS/NA must be implemented on point-to-point links.

If ND NS/NA was optional on point-to-point links, I'd also expect to
see some text in, e.g. the IPv6 PPP RFC, clarifying or overriding the
ND NS/NA requirements of the more general IPv6 ND RFC. RFC5072 doesn't
state that ND NS/NA can or must be disabled on PPP point-to-point
links. So it seems to me that IPv6 ND RFC operation applies, and as
mentioned above, it says that point-to-point links are assumed to have
multicast support and can therefore be treated as generic, multicast
interfaces by IPv6 ND.

So, is my interpretation correct, and point-to-point links are required
to perform ND NS/NA? More broadly, if a link supports or can emulate a
link layer multicast capability, are all the IPv6 Neighbor Discovery
operations, including Neighor Solicitation/Neighbor Advertisement,
required to be implemented on that link?

Thanks,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 13 Jul 2010 17:02:24 +0200

>until it's hop count expires - i.e. the ping-pong problem.

The problem is that for some reason access providers tend to disable support
for ND on point-to-point links. Which in turn requires stacks on consumer
machines to disable it as well.

I have 4 point-to-point links and last time I checked, none of them support
ND.

---

From: Mark Smith <[email-masked]>
Date: Wed, 14 Jul 2010 20:26:47 +0930

Hi Dave,

(Is something up with the 6man mailing list? I've had a few replies,
including one from Philip, none of them have CC'd [email-masked], nor
have I seen any replies via the list, and yet below seems show that a
copy of Philip's email made it through. I have received a 3 I-D action
emails via the list since I posted. I'm pretty sure nothing has changed
in my email client to stop it showing or processing CC's. Quite
strange.)

Question at the end.

On Tue, 13 Jul 2010 23:12:17 +0000
Dave Thaler <[email-masked]> wrote:

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Philip Homburg
> > Sent: Tuesday, July 13, 2010 8:02 AM
> > To: Mark Smith
> > Subject: Re: ND NS/NA support required on point-to-point links?
> > 
> > The problem is that for some reason access providers tend to disable support for
> > ND on point-to-point links. Which in turn requires stacks on consumer machines
> > to disable it as well.
> > 
> > I have 4 point-to-point links and last time I checked, none of them support ND.
> 
> From RFC 4861:
> > Unless specified otherwise (in a document that covers operating IP
> > document covering the operation of IP over a particular link type).
> > The services described in this document that are not directly
> > dependent on multicast, such as Redirects, Next-hop determination,
> > Neighbor Unreachability Detection, etc., are expected to be provided
> > as specified in this document.  The details of how one uses ND on
> > NBMA links are addressed in [IPv6-NBMA].  In addition, [IPv6-3GPP]
> > and[IPv6-CELL] discuss the use of this protocol over some cellular
> > links, which are examples of NBMA links.
> 
> That means that Neighbor Discovery using multicast NS need not be
> done on point-to-point links, but Neighbor Unreachability Detection
> still is done.
> 

I'm a bit confused by that. My understanding of NUD was that it's main
function is to ensure that existing entries in the neighbor cache are
valid. If NUD fails, then the entry is removed from the neighbor cache
so that next time that destination IPv6 address is sent to, the absence
of a neighbor cache entry would trigger an NS/NA transaction.

So if ND NS/NA transactions aren't performed on these point-to-point
links, wouldn't that mean there is nothing for NUD to validate? What
would be the target address of the NUD probes if they can take place
without ND NS/NA transactions priming the neighbor cache with entries? 

Thanks,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 14 Jul 2010 12:57:53 +0200

>in my email client to stop it showing or processing CC's. Quite

I certainly made a mistake replying to Mark, and I later redistributed that
mail to the list. So, I think the list is fine.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 14 Jul 2010 13:07:01 +0200

>without ND NS/NA transactions priming the neighbor cache with entries? 

I agree with that. I tried for a while to skip the ND step and only do NUD,
but it doesn't fit within the framework for RFC-4861. The separation could
be useful for 6to4. 

For point-to-point links, which can do multicast trivially, there is no excuse
for not doing full ND (unless it is a link between two routers that actually
use hellos in the routing protocol to determine whether the other side is
alive).

---

From: [email-masked]
Date: Wed, 14 Jul 2010 13:16:24 +0200 (CEST)

> use hellos in the routing protocol to determine whether the other side is

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.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Wed, 14 Jul 2010 13:44:51 +0200

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

So I wonder, with all the IPv6 interoperability testing and certification
going on, how come nobody ever noticed that this is an issue?

---

From: Mark Smith <[email-masked]>
Date: Wed, 14 Jul 2010 22:12:25 +0930

> ND on point-to-point links.

Well, if my understanding of the RFC is correct, and these
implementations (and others I'm aware of) are claiming compliance with
the ND RFC, then they're suffering from implementation bugs. That's
fine, bugs are inevitable. I think a feasible explanation could be that
the model of IPv4's operation over point-to-point links has been copied
when implementing IPv6, even though one of the key differences between
IPv6 and IPv4 is the shifting of address resolution into ICMPv6.

On a PPP link, IPCP conveyed information about complete IPv4 addresses
at the other end of the point-to-point link. That functionality been
removed from IPV6CP - it only negotiates/conveys IIDs. So it also seems
that the IPv6 over PPP authors were assuming that something else would
take over that role, most likely ND NS/NA. Routing protocols would only
partially fill that role, because they won't be operating on PPP links
between e.g. residential ADSL CPE and the upstream customer aggregation
router. That will be an exceedingly common scenario, and one where
the /127 mitigation can't be applied because of it's manual
configuration requirement.

---

From: [email-masked]
Date: Wed, 14 Jul 2010 15:25:54 +0200 (CEST)

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

> 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

    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

---

From: Mark Smith <[email-masked]>
Date: Thu, 15 Jul 2010 07:32:56 +0930

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

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 15 Jul 2010 11:33:03 +0200

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

> Mark Smith
> Sent: Thursday, July 15, 2010 12:03 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> On Wed, 14 Jul 2010 15:25:54 +0200 (CEST) [email-masked] wrote:
> 
> > > >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.
> >
> 
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
> >
> 
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.
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Mon, 19 Jul 2010 20:51:26 +0930

Hi Pascal,

On Thu, 15 Jul 2010 11:33:03 +0200

> the ND registration to P2p in particular and NBMA links at large.

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.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 20 Jul 2010 12:26:22 -0400

Some thoughts on this thread...

One problem with the statement/question: are p2p links required to use
Neighbor Discovery, is defining exactly what ND is. ND is actually a
suite of protocols, including:

 - Router discovery
 - address resolution
 - Neighbor Unreachabilty Detection (NUD)
 - etc.

For a p2p link, I think we all agree that Address Resolution is not
necessary. But what about the other parts?

> until it's hop count expires - i.e. the ping-pong problem.

IMO, this is broken. Implementations should not blindly forward
packets...

> could operate over the link without any link specific changes.

That was the intention. In practice, folk seem to want to make
optimizations to not send packets if they are not strictly required,
resulting in the current situation where running ND over a p2p link
would work just fine, but is actually disabled.

> devices are available to send packets to.

Actually, I think it does. By defintion, assigning an on-link prefix
of /x to an interface by definition means all addresses covered by /x
are on the attached link, and a sender should be able to send directly
to them *WITHOUT* going through a router.

The issue is that by defn, a p2p link has exactly two devices attached
to it. So having a /x assigned to the link, where /x covers many
addresses (e.g., a /64), doens't make sense. We know most of the
addresses are not really on the link.

Conceptually, a sender that sees such an address should conclude that
the destination is on the directly attached link and attempt to send
it. And apparently implementations just "blindly" send such packets
and they end up at the other end of the p2p link, which then does the
same thing causing the packet to loop.

IMO, it is an error for a sender to send a packet on a p2p link, when
the destination is considered "on-link" unless the packet is truly
addressed to the node at the other end of the p2p link.

Architecturally, that is where the implementation flaws
are. Forwarding a packet to the other end of the link, when the sender
should know that the destination is not at the other end of the link
is IMO broken.

Running ND (and address resolution in particular) in this case to
verify that the recipient is actually on the link would solve the
problem. But so would other techniques.

> availability. Allowing a /127 prefix length in IPv6 won't fix that.

This is not entirely true. The above is about how to handle the case
where one attempts address resolution, and that fails. One should then
send an ICMP error.

However, that does not mean that the only time one can send an ICMP
unreachable is after ND fails. It would be perfectly OK to send an
ICMP unreachable upon discovering that one is sending to a destination
covered by the on-link prefix, but does not correspond to addresses at
the other end of the of the p2p link.

> generating Destination Unreachable Messages

See above. ND is also about NUD...

Thomas

---

From: Philip Homburg <[email-masked]>
Date: Tue, 20 Jul 2010 19:04:41 +0200

>necessary. But what about the other parts?

I think that is where it goes wrong. Yes, it is true that on a p2p link you
don't need the neighbors MAC address because there isn't any. But the protocol
works only if you execute it completely, just leaving out the linklayer 
address options.

What address resolution does is not just to provide a MAC address, but also an
indication that the other side is alive.

What is called NUD in only part of the complete protocol, so it doesn't work
on its own.

>would work just fine, but is actually disabled.

Exactly.

>the other end of the of the p2p link.

The problem here is that in general, you don't know what addresses your peer
may respond to. So need a protocol for that. The current ND protocol works,
but has the problem you may have to deal with a DoS issue when attacker
enumerates all addresses covered by a /64 (which may not be a big issue on
router to router links).