Skip to main content

Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers
RFC 9131

Note: This ballot was opened for revision 05 and is now closed.

Erik Kline Yes

Warren Kumari Yes

Comment (2021-06-30 for -05)
Yes! Best thing since sliced bread.

(Full disclosure: I was very supportive of this when the issue was raised in V6OPS, and strongly suggested that Jen take it to 6MAN, and offered to help author, etc. I considered balloting Recuse, but seeing as I mainly contributed cheerleading, I figured a Yes would do instead).

Éric Vyncke (was No Objection) Yes

Comment (2021-06-29 for -05)
Thank you for the work put into this document. It is a VERY useful specification! The doc is also easy to read.

Special thanks for the doc shepherd write-up about the WG process / consensus. 

Other thanks to Carles Gomez for the IoT directorate review at:
https://mailarchive.ietf.org/arch/msg/iot-directorate/cKVAO13tZw-AHhOtW4-tJhr6_rM/ and to Jen for addressing Carles' comments. Even, if RFC 8505 could be another solution if widely implemented (section 8.2).

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. PLEASE act on my comment on section 6.1.2 (I was about to raise a trivial-to-address DISCUSS).

I hope that this helps to improve the document,

Regards,

-éric


== COMMENTS ==


-- Section 1 --
Just to be clear s/This document updates the Neighbor Discovery protocol/This document updates the Neighbor Discovery protocol [RFC 4861]/

-- Section 2 --
In the 2. bullet, does the host need to also have the "default router link-local" ? I would assume link-layer would be enough (no need to do NUD at the beginning ?)

In the description, should the "host" rather be a "node" (i.e., possibly having a router role) ?

Should "If the host sends multiple probes in parallel" be more detailed by adding "to multiple destinations" ?

-- Section 4.1 --
The amount of mcast traffic is even reduced in the sense that less nodes are receiving the NA/NS traffic (in this I-D only routers else all nodes).

-- Section 5.2 --
Humm I do not fully agree with the last part of the section "However most likely those packets...address resolution is completed.". The optimistic DAD node will indeed receive the already-queued packets so I do to really understand the part "dropping subsequent packets" as those packets would have been dropped anyway. Nothing dramatic but I wonder whether a rephrase would help here.

-- Section 5.3 --

Should the 1. also includes NC entries that have expired ? Should 'communication' be qualified as on-link or not on-link ?

s/rightful owner/original owner/ because the first owner could actually be an attacker ;-)
 
-- Section 5.3.2 --
s/The router receives the return traffic flows for both the rightful owner of the duplicated address and the new host. /The router receives the return traffic flows for the IPv6 addressed shared by the rightful owner of the duplicated address and the new host. / ?

-- Section 6 --
This section is only about routers but the nodes behavior must also be changed to send unsollicited NA. Where is it specified ?

-- Section 6.1.1 --
What should the router do if not discarding in "SHOULD be silently discarded." (last sentence)

-- Section 6.1.2 --
A trivial DISCUSS level but trusting Jen to fix it: missing the end of the NEW text as a line of dashes ;-)

How can a node execute "A node may also wish to notify its first-hop routers" ?

I wonder why some text is about "new global IPv6 address" in the replaced text about for anycast. I can only guess that it is not applicable to anycast but to all type of addresses. So, strongly suggest to move the part "A node may also...to preferred" *before* the § about anycast.

-- Section 8.3 --
s/default router/first-hop routers/ ?

-- Section 8.6 --
I wonder how many of the enumerated drawbacks also apply to this specification... (except for generating the ICMP echo reply). But, it has the advantage of requiring only host changes.

-- Section 8.9 --
s/When a router receives a transit packet/When a router receives a transit packet sourced by a on-link neighbor node/

-- Section 10 --
About "disclosed via DAD to all nodes anyway", actually DAD is sent to the sollicited-node mcast address and not all nodes/routers.

== NITS ==

"Therefore", ".e.g.", "So", "Otherwise", and "However" are usually followed by a comma as I learned from RFC Editor ;-)

s/can not/cannot/

Alvaro Retana No Objection

Comment (2021-06-28 for -05)
The datatracker should be updated to indicate that this document also replaces draft-ietf-v6ops-nd-cache-init.

Francesca Palombini No Objection

John Scudder No Objection

Comment (2021-06-30 for -05)
Thanks for a clear, readable, well-organized, and well-motivated document. I have just a few questions and comments below.

1. Section 5.2

              The
   only potential impact would be for packets arriving to the router
   after the unsolicited NA from the host but before the rightful owner
   responded with the solicited NA.  Those packets would be sent to the
   host with the optimistic address instead of its rightful owner.
   However most likely those packets would have been dropped anyway:
   creating the INCOMPLETE entry is usually triggered by traffic, so the
   router probably has some packets in the buffer already, dropping
   subsequent packets received before the address resolution is
   completed.

Wouldn’t the buffered packets (received before the unsolicited NA) be misdelivered to the optimistic host? The quoted paragraph restricts itself to packets arriving after the unsolicited NA.

2. Section 5.3.1

Couldn’t step 4 (host detects duplication) complete sometime after step 7 (router sends NS to host)? (This might also apply to 5.3.2.) If that's possible the analysis would be a little less rosy, right?

3. Section 5.3.1

        However the same
   behaviour would be observed if changes proposed in this document are
   implemented

Do you mean “are *not* implemented”?

4. Section 8.4

Please add SLLAO to terminology section or expand on first use.

Martin Duke No Objection

Comment (2021-06-25 for -05)
Thanks to Michael Scharf for the TSVART review.

(5.3.1) " However the same
   behaviour would be observed if changes proposed in this document are
   implemented"

I don't understand this sentence; I thought the above behavior described the result of the changes? Do you mean "are not implemented"?

Moreover, this doesn't sound right. If the changes are not implemented, the effect should be that most of the traffic is dropped in the small buffer rather than delivered to the rightful owner.

(8.4) I gather that SSLAO is "SSLA Option", but you ought to expand that on first use.

Murray Kucherawy No Objection

Comment (2021-06-30 for -06)
I don't see a lot of transport documents that make me think this, but: Kudos for an easy read.

In Sections 6.1.1 and 6.1.2, there are the following uses of BCP 14 language:

* "Routers SHOULD create a new entry ..."

* "In such cases a node SHOULD send up to MAX_NEIGHBOR_ADVERTISEMENT Neighbor Advertisement messages."

* "If the address is preferred then the Override flag SHOULD NOT be set."

* "The destination address SHOULD be set to the all-routers multicast address."

* "The first advertisement SHOULD be sent as soon as one of the following events happens:"

To a transport expert the answer to this may be obvious, but I'm left wondering why these are only SHOULD [NOT]s.  Is there a ever a good reason to deviate from those instructions?  I generally find it helps to, when using SHOULD [NOT], include a sentence or two about why it might be necessary to do something else, to guide novice readers.  It's not strictly necessary, but something to consider here.

Apart from that, I have only a couple of boring nits to offer:

Section 1:

* "It can causes ..." -- s/causes/cause/

Section 5:

* "The section 2.2 of ..." -- s/The section/Section/

Robert Wilton No Objection

Comment (2021-07-01 for -06)
Thanks for this document.  I was surprised that ND didn't already have this behavior so its addition is clearly a good thing.

A couple of minor comments:

(1) I wasn't really familiar with the term "off-link" and I was wondering whether it's definition should be imported here, although I note that ND does define and use this term, so readers familiar with the ND RFC would presumably be familiar with it.

(2) I actually found the normative text updating RFC4861 in section 6.1.1 to not be that readable, and I had to scan it a couple of times to spot the distinction between router and host.  Possibly laying out the text slightly differently would make the distinction between host and router behaviour more obvious.  E.g.,

   When a valid Neighbor Advertisement is received (either solicited or
   unsolicited), the Neighbor Cache is searched for the target's entry.
   If no entry exists:

       Hosts SHOULD silently discard the advertisement.  There is no
       need to create an entry if none exists, since the recipient has
       apparently not initiated any communication with the target.

       Routers SHOULD create a new entry for the target address with
       the link-layer address set to the Target link-layer address
       option (if supplied).  The entry's reachability state MUST be
       set to STALE.  If the received Neighbor Advertisement does not
       contain the Target link-layer address option the advertisement
       SHOULD be silently discarded.

Roman Danyliw No Objection

Comment (2021-06-29 for -05)
Thank you to Scott Kelly for the SECDIR review.

** Section 5.3.  Does the outcome of any of the documented scenarios change if the host has DAD turned off (per Section 5.3.1, Step #4 and Section 5.3.2, Step #5)

** Section 10.  It would be useful to reiterate with a back reference the unlikely, but possible condition where the duplicated address temporarily gets the traffic from the rightful owner (noted in Section 5.3.2).

Zaheduzzaman Sarker No Objection

Comment (2021-06-29 for -05)
Thanks for the very good document. It was clear about the need and the solution choice.

I have some comments, addressing them  I believe will improve the document even more -

   * Section 3: already a great job done in the terminology section, please add the STALE definition to that list with reference.

   * Section 4.1: 
      * Please provide ref to "onlink routers" or add verbose description of it. Best to add this to section 3, even if this might be very well known term to the active participants.

      * It would be great if there is some text describing what if "multicast traffic should not
   increase" is not true and what precaution should be taken.

   * Section 4.2 : this section might be improved by providing some information about duplicate entries unless there is no chance of duplicate addresses in case of unsolicited NAs. May be a hint is enough that it is covered in section X.X.

And one question - 

   * Section 5.2 : 
       "Those packets would be sent to the
      host with the optimistic address instead of its rightful owner."
   
      Could this problem be amplified to create issues in the network?

(Benjamin Kaduk; former steering group member) No Objection

No Objection (2021-06-30 for -05)
Thanks for the comprehensive and systematic analysis of the approach
selected, as well as the discussion of approaches not selected!

Section 1

   return traffic flow.  While waiting for the resolution to complete
   routers only keep a very small number of packets in the queue, as
   recommended in Section 7.2.2 [RFC4861].  All subsequent packets
   arriving before the resolution process finishes are likely to be
   dropped.  [...]

My reading of RFC 4861 is that it suggests for new packets arriving to
replace the oldest entry in this queue of packets, which doesn't really
seem consistent with "all subsequent packets [...] are likely to be
dropped".  "Any additional packets arriving before the resolution
process finishes are likely to result in dropped packets" might be more
consistent with the RFC 4861 guidance.

Section 2

                                      As per Section 7.2.2 of [RFC4861]
       Routers MUST buffer at least one data packet and MAY buffer more,
       while resolving the packet destination address.  However most
       router implementations limit the buffer size to a few packets
       only, so all subsequent packets for the host global address are
       dropped, until the address resolution process is completed.

[same as above re "subsequent"]

   router's neighbor cache.  However, the same sequence of events happen
   when the host starts using a new global address previously unseen by
   the router, such as a new privacy address [RFC4941] or if the
   router's Neighbor Cache has been flushed.

RFC 4941 has been obsoleted by RFC 8981.

Section 3

   o  If the router does not have a Neighbor Cache entry for the
      address, a STALE entry needs to be created.

(editorial) The lead-in to this list leaves me unclear about when it's
desired for this entry to be created.  The conditional nature of this
statement suggests that creating as a result of receiving the first
packet for that address might be okay, but I don't think that's actually
the intent.

Section 4.1

   To minimize the potential disruption in case of duplicate addresses
   the node should not set the Override flag for a preferred address and
   must not set the Override flag if the address is in Optimistic
   [RFC4429] state.

I suggest adding "preferred address" to the terminology list (with RFC
4862 reference).

   It should be noted that the proposed mechanism does not cause any
   significant increase in multicast traffic.  The additional multicast
   unsolicited NA would proactively create a STALE cache entry on
   routers as discussed below.  When the router receives the return
   traffic flows it does not need to send multicast NSes to the
   solicited node multicast address but would be sending unicast NSes
   instead.  Therefore the total amount of multicast traffic should not
   increase.

Hmm, I might frame this as "this procedure would only produce an
increase in the overall amount of multicast traffic if no return traffic
arrives to the node that sent the unsolicited NA".

Section 4.2

   This document updates [RFC4861] so that routers create a new Neighbor
   Cache entry upon receiving an unsolicited Neighbor Advertisement.

I'd suggest "upon receiving an unsolicited Neighbor Advertisement for an
address that does not already have a Neighbor Cache entry".

Section 5.2

   However most likely those packets would have been dropped anyway:
   creating the INCOMPLETE entry is usually triggered by traffic, so the
   router probably has some packets in the buffer already, dropping
   subsequent packets received before the address resolution is
   completed.

I *think* the packet-dropping scenario here is the same one that I
mentioned previously in the context of "subsequent packets" (not) being
dropped, involving the very small queue on the router of packets to an
address waiting for resolution.  If so, I might suggest a phrasing such
as "the creation of the INCOMPLETE entry is usually triggered by inbound
traffic, and due to the limited queue size on the router for packets
directed to addresses that are waiting for resolution, most packets
arriving prior to the solicited NA would be dropped anyway".

Section 5.3.1

As a thought experiment, I tried comparing this scenario to a similar
one where the host uses optimistic DAD but does not send an unsolicited
NA.  In that case, it seems like the optimistic traffic would go out,
and when the return traffic arrives the router would create a STALE
entry and do full discovery to find the original owner of the address,
so some of the responses to the optimistic (probe) traffic might make it
to the original owner of the address.  That's in contrast to this
scenario where the return traffic goes to the host that triggered it.
IIUC in both cases we rely on the host properly doing DAD to stop using
the optimistic address, and so the scenarios do seem pretty similar
overall.

Section 6.1.1

   NEW TEXT:

   ------------------------------------------------------------------

   When a valid Neighbor Advertisement is received (either solicited or
   unsolicited), the Neighbor Cache is searched for the target's entry.
   If no entry exists, hosts SHOULD silently discard the advertisement.
   There is no need to create an entry if none exists, since the
   recipient has apparently not initiated any communication with the
   target.  Routers SHOULD create a new entry for the target address
   with the link-layer address set to the Target link-layer address
   option (if supplied).  The entry's reachability state MUST also be
   set to STALE.  If the received Neighbor Advertisement does not
   contain the Target link-layer address option the advertisement SHOULD
   be silently discarded.

(nit) I'm not sure why we need the word "also" in "MUST also be set to
STALE".

Section 10

I'd probably reiterate the (small) risk of the 7-second window of loss
of traffic discussed in §5.3.2 as a known+accepted security
consideration.

   A malicious host could attempt to exhaust the neighbor cache on the
   router by creating a large number of STALE entries.  However this
   attack vector is not new and this document does not increase the risk
   of such an attack: the attacker could do it, for example, by sending
   a NS or RS packet with SLLAO included.  All recommendations from
   [RFC6583] still apply.

Would there be any value in having the neighbor cache entries created on
routers by unsolicited NA be placed in a dedicated storage class, such
that the NDP prioritization recommended by RFC 6583 would be expanded to
include "never seen", "unsolicited NA", and "seen before" categories
with corresponding eviction priorities?

Section 12.1

RFC 6775 and 8505 probably don't need to be normative, since the
registration-based approach to ND is the approach not taken by this
document.

We also only cite RFC 8305 once, just as an example, so that may not
need to be normative either.