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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
