Skip to main content

Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers
draft-ietf-6man-grand-07

Revision differences

Document history

Date Rev. By Action
2024-01-26
07 Gunter Van de Velde Request closed, assignment withdrawn: Tim Wicinski Last Call OPSDIR review
2024-01-26
07 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2021-09-29
07 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-09-15
07 (System) RFC Editor state changed to AUTH48
2021-08-24
07 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-07-20
07 (System) RFC Editor state changed to EDIT
2021-07-20
07 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-07-20
07 (System) Announcement was received by RFC Editor
2021-07-20
07 (System) IANA Action state changed to No IANA Actions from In Progress
2021-07-20
07 (System) IANA Action state changed to In Progress
2021-07-20
07 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-07-20
07 Amy Vezza IESG has approved the document
2021-07-20
07 Amy Vezza Closed "Approve" ballot
2021-07-20
07 Amy Vezza Ballot approval text was generated
2021-07-19
07 Erik Kline IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2021-07-05
07 Jen Linkova This document now replaces draft-linkova-6man-grand, draft-ietf-v6ops-nd-cache-init instead of draft-linkova-6man-grand
2021-07-05
07 (System) Removed all action holders (IESG state changed)
2021-07-05
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-07-05
07 Jen Linkova New version available: draft-ietf-6man-grand-07.txt
2021-07-05
07 (System) New version accepted (logged-in submitter: Jen Linkova)
2021-07-05
07 Jen Linkova Uploaded new revision
2021-07-01
06 (System) Changed action holders to Jen Linkova (IESG state changed)
2021-07-01
06 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2021-07-01
06 Michelle Cotton IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2021-07-01
06 Robert Wilton
[Ballot comment]
Thanks for this document.  I was surprised that ND didn't already have this behavior so its addition is clearly a good thing.

A …
[Ballot comment]
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.
2021-07-01
06 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-06-30
06 Murray Kucherawy
[Ballot comment]
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 …
[Ballot comment]
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/
2021-06-30
06 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-06-30
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-06-30
06 Jen Linkova New version available: draft-ietf-6man-grand-06.txt
2021-06-30
06 (System) New version accepted (logged-in submitter: Jen Linkova)
2021-06-30
06 Jen Linkova Uploaded new revision
2021-06-30
05 John Scudder
[Ballot comment]
Thanks for a clear, readable, well-organized, and well-motivated document. I have just a few questions and comments below.

1. Section 5.2

    …
[Ballot comment]
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.
2021-06-30
05 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2021-06-30
05 Warren Kumari
[Ballot comment]
Yes! Best thing since sliced bread.

(Full disclosure: I was very supportive of this when the issue was raised in V6OPS, and strongly …
[Ballot comment]
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).
2021-06-30
05 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2021-06-30
05 Benjamin Kaduk
[Ballot comment]
Thanks for the comprehensive and systematic analysis of the approach
selected, as well as the discussion of approaches not selected!

Section 1

  …
[Ballot comment]
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.
2021-06-30
05 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2021-06-29
05 Roman Danyliw
[Ballot comment]
Thank you to Scott Kelly for the SECDIR review.

** Section 5.3.  Does the outcome of any of the documented scenarios change if …
[Ballot comment]
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).
2021-06-29
05 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-06-29
05 Zaheduzzaman Sarker
[Ballot comment]
Thanks for the very good document. It was clear about the need and the solution choice.

I have some comments, addressing them  I …
[Ballot comment]
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?
2021-06-29
05 Zaheduzzaman Sarker Ballot comment text updated for Zaheduzzaman Sarker
2021-06-29
05 Zaheduzzaman Sarker
[Ballot comment]
Thanks for the very good document. It was clear about the need and the solution choice.

I have some comments, addressing them  I …
[Ballot comment]
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?
2021-06-29
05 Zaheduzzaman Sarker Ballot comment text updated for Zaheduzzaman Sarker
2021-06-29
05 Zaheduzzaman Sarker
[Ballot comment]
Thanks for the very good document. It was clear about the need and the solution choice.

I have some comments, addressing them  I …
[Ballot comment]
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?
2021-06-29
05 Zaheduzzaman Sarker Ballot comment text updated for Zaheduzzaman Sarker
2021-06-29
05 Zaheduzzaman Sarker
[Ballot comment]
Thanks for the very good document. It was clear about the need and the solution choice.

I have some comments that I believe …
[Ballot comment]
Thanks for the very good document. It was clear about the need and the solution choice.

I have some comments that I believe 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?
2021-06-29
05 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2021-06-29
05 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to Yes from No Objection
2021-06-29
05 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. It is a VERY useful specification! The doc is also easy to read.

Special …
[Ballot comment]
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/
2021-06-29
05 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-06-28
05 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2021-06-28
05 Alvaro Retana [Ballot comment]
The datatracker should be updated to indicate that this document also replaces draft-ietf-v6ops-nd-cache-init.
2021-06-28
05 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-06-25
05 Martin Duke
[Ballot comment]
Thanks to Michael Scharf for the TSVART review.

(5.3.1) " However the same
  behaviour would be observed if changes proposed in this …
[Ballot comment]
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.
2021-06-25
05 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-06-24
05 Jean Mahoney Closed request for Last Call review by GENART with state 'Overtaken by Events'
2021-06-23
05 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2021-06-22
05 Amy Vezza Placed on agenda for telechat - 2021-07-01
2021-06-21
05 Erik Kline Ballot has been issued
2021-06-21
05 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2021-06-21
05 Erik Kline Created "Approve" ballot
2021-06-21
05 Erik Kline IESG state changed to IESG Evaluation from Waiting for Writeup
2021-06-21
05 Erik Kline Ballot writeup was changed
2021-06-21
05 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-06-21
05 Jen Linkova New version available: draft-ietf-6man-grand-05.txt
2021-06-21
05 (System) New version accepted (logged-in submitter: Jen Linkova)
2021-06-21
05 Jen Linkova Uploaded new revision
2021-06-18
04 Carles Gomez Request for Last Call review by IOTDIR Completed: Ready with Nits. Reviewer: Carles Gomez. Sent review to list.
2021-06-18
04 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-06-17
04 Dan Romascanu Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dan Romascanu. Sent review to list.
2021-06-16
04 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2021-06-16
04 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-6man-grand-04, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-6man-grand-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2021-06-12
04 Scott Kelly Request for Last Call review by SECDIR Completed: Ready. Reviewer: Scott Kelly. Sent review to list.
2021-06-10
04 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2021-06-10
04 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2021-06-10
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Scott Kelly
2021-06-10
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Scott Kelly
2021-06-08
04 Michael Scharf Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Michael Scharf. Sent review to list.
2021-06-08
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2021-06-08
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2021-06-07
04 Samita Chakrabarti Request for Last Call review by IOTDIR is assigned to Carles Gomez
2021-06-07
04 Samita Chakrabarti Request for Last Call review by IOTDIR is assigned to Carles Gomez
2021-06-07
04 Éric Vyncke Requested Last Call review by IOTDIR
2021-06-07
04 Magnus Westerlund Request for Last Call review by TSVART is assigned to Michael Scharf
2021-06-07
04 Magnus Westerlund Request for Last Call review by TSVART is assigned to Michael Scharf
2021-06-04
04 Amy Vezza IANA Review state changed to IANA - Review Needed
2021-06-04
04 Amy Vezza
The following Last Call announcement was sent out (ends 2021-06-18):

From: The IESG
To: IETF-Announce
CC: 6man-chairs@ietf.org, Bob Hinden , bob.hinden@gmail.com, draft-ietf-6man-grand@ietf.org, …
The following Last Call announcement was sent out (ends 2021-06-18):

From: The IESG
To: IETF-Announce
CC: 6man-chairs@ietf.org, Bob Hinden , bob.hinden@gmail.com, draft-ietf-6man-grand@ietf.org, ek.ietf@gmail.com, ipv6@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'Gratuitous Neighbor Discovery: Creating
Neighbor Cache Entries on
  First-Hop Routers'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-06-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the
  link-layer addresses of neighboring nodes as well as to discover and
  maintain reachability information.  This document updates RFC4861 to
  allow routers to proactively create a Neighbor Cache entry when a new
  IPv6 address is assigned to a node.  It also updates RFC4861 and
  recommends nodes to send unsolicited Neighbor Advertisements upon
  assigning a new IPv6 address.  The proposed change will minimize the
  delay and packet loss when a node initiates connections to an off-
  link destination from a new IPv6 address.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-grand/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3902/





2021-06-04
04 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-06-04
04 Amy Vezza Last call announcement was changed
2021-06-03
04 Erik Kline Last call was requested
2021-06-03
04 Erik Kline Last call announcement was generated
2021-06-03
04 Erik Kline Ballot approval text was generated
2021-06-03
04 Erik Kline Ballot writeup was generated
2021-06-03
04 (System) Changed action holders to Erik Kline (IESG state changed)
2021-06-03
04 Erik Kline IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-06-03
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-06-03
04 Jen Linkova New version available: draft-ietf-6man-grand-04.txt
2021-06-03
04 (System) New version accepted (logged-in submitter: Jen Linkova)
2021-06-03
04 Jen Linkova Uploaded new revision
2021-03-07
03 Erik Kline
My apologies.  I got hung up trying to sort through all the packet ordering
discussions in section 5 and ended up getting sidetracked.

[[ comments …
My apologies.  I got hung up trying to sort through all the packet ordering
discussions in section 5 and ended up getting sidetracked.

[[ comments and questions ]]

[ section 4.1/4.2 and 6 ]

* Do we want to use the upper case language here? Specifically:

  - "the node can send gratuitous" -> "the node MAY send gratuitous"
  - "node SHOULD NOT set the Override flag for a preferred address"
  - "MUST NOT set the Override flag if the address is in Optimistic"

  - "so that routers create a new Neighbor Cache entry" ->
    "so that routers SHOULD create a new Neighbor Cache entry"?

  Section 4 seems to be a narrative description of the normative text in
  section 6, which a

  It's up to you, but one change to the document flow might be to put
  sections 4 and 6 together, either as one or back to back, and move
  section 5 after it.

  Also, "Proposed Changes to ND" is really going to be "Changes to ND" or
  something, when published.

[ section 5.2 ]

* "those packets would have been dropped anyway"

  I'm not sure this necessarily true.  The document previously states that
  some or all of them might be dropped, but that the first packet -- or the
  first to fill a small queue -- might be delivered.

[ section 8.9 ]

* Functionally the same as the asymmetric routing case, but perhaps worth
  a mention anyway, is the fact that if ingress filtering is not implemented
  on this first hop router traffic with spoofed source addresses would
  be an ND table exhaustion attack vector.

  This is called out in section 10 in the general case, so no need to go
  to any effort to duplicate the text here.  Just a random thought.

[ section 10 ]

* "Therefore it is not possible for the attacker to override
  any existing cache entry."

  Is this true?  There are still other ways to attempt such attacks, and
  the attacker might set the Override bit regardless of SHOULD/MUST.

  I think perhaps this might mean "Therefore there are no new vectors for
  an attacker to override any existing cache entry."?


[[ nits ]]

[ section 1 ]

* "an entry for A address" might perhaps be a little more explicit, perhaps
  "an entry for A's IP and link layer addresses"

* "It might cause user-visible", perhaps "This can cause user-visible", since
  this behaviour has been observed, on IETF conference networks no less.

[ section 1.2 ]

* NC for Neighbor Cache is used without expansion first in section 5.3;
  suggest adding it to the list here.

[ section 2 ]

* "The RA is send" -> "The RA is sent"

* "to link-local destination" -> "to a link-local destination address"

* "link-local the link-layer" -> "link-local and link-layer"

* "no entries for the device global addresses" ->
  "no entries for any of the device's global addresses"

[ section 4.1 ]

* "sent to all-routers multicast address" ->
  "sent to the all-routers multicast address"

* "Therefore total amount" -> "Therefore the total amount"

[ section 4.2 ]

* "to allow routers creating" -> "to allow routers to create"

[ section 5 ]

* "The following sections are discussing" -> "The following sections discuss"

[ section 6.1.1/6.1.2 ]

* "document proposes the following changes" ->
  "document makes the following changes"

[ section 8.7 ]

* "Examples are including" -> "Examples include"

[ section 8.9 ]

* "if the entry does not, exist start" ->
  "if the entry does not exist, start"
2021-03-07
03 (System) Changed action holders to Jen Linkova (IESG state changed)
2021-03-07
03 Erik Kline IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2020-10-07
03 Erik Kline IESG state changed to AD Evaluation::AD Followup from AD Evaluation
2020-10-07
03 Erik Kline IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-10-07
03 Bob Hinden Tag Other - see Comment Log cleared.
2020-10-07
03 Bob Hinden IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2020-10-07
03 Bob Hinden
Document Shepherd writeup for:

  Title:    Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-
            Hop Routers
  …
Document Shepherd writeup for:

  Title:    Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-
            Hop Routers
  Author:  Jen Linkova
  Filename: draft-ietf-6man-grand


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

  Standards Track, Proposed Standard

  This is the correct status, because it is updating RFC4861
  "Neighbor Discovery for IP version 6 (IPv6)".


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections: 

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

  Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the
  link-layer addresses of neighboring nodes as well as to discover and
  maintain reachability information.  This document updates RFC4861 to
  allow routers to proactively create a Neighbor Cache entry when a new
  IPv6 address is assigned to a node.  It also updates RFC4861 and
  recommends nodes to send unsolicited Neighbor Advertisements upon
  assigning a new IPv6 address.  The proposed change will minimize the
  delay and packet loss when a node initiate connections to off-link
  destination from a new IPv6 address.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough? 

  The document had active discussion in the w.g. and there is a strong
  consensus to advance it.

  The discussion spawned a side discussion about security and Neighbor Discovery, but
  that is not related to this document, nor should it hold it up.

  Update:  After submitting to the IESG, the Area Directors requested
  that this draft be combined with .
  This version of the draft does that.  We did a second working group
  call, V6OPS was cc'ed on the last call.


Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, YANG Doctor, Media Type or other expert review, what was its
course (briefly)? In the case of a Media Type review, on what date was
the request posted?

  It was well reviewed by the w.g., and has gone through two w.g. last
  calls as noted above.

  The document is very clear on what changes it is making to RFC4861,
  show old text and new text.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Bob Hinden is Document Shepherd.
  Erik Kline is Responsible Area Director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  I, as Document Shepard and w.g. co-chair, have reviewed the document
  and w.g. discussion.
 
  I think it is ready for publication.
 

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  The document had a lot of discussion.    No concerns with advancing it.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

  The author is not aware of any IPR on this other than what was filed
  against the individual version of the draft.  See:

  https://datatracker.ietf.org/ipr/search/?id=draft-linkova-6man-grand&submit=draft


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  See (7).

  There was a short discussion about this on the list, no objection
  advancing the document was raised.
 

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

  Strong support, lots of comments, they were responded to quickly by
  the author and resolved.
 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough. 

  No IDnits errors.
   

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  N/A

(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All normative references are published RFCs.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

  No.


(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

  This document updated RFC4861, this is shown in the title page header,
  Abstract, and Introduction.
 

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).

  No IANA requests.
 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

  N/A
 

(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the YANG
module comply with the Network Management Datastore Architecture (NMDA)
as specified in RFC8342?

  N/A
2020-09-18
03 Bob Hinden
We are doing a second working group last call because the Area Directors requested that this draft be combined with .  This version of the …
We are doing a second working group last call because the Area Directors requested that this draft be combined with .  This version of the draft does that.  V6ops is being copied on this last call.
2020-09-18
03 Bob Hinden Tag Other - see Comment Log set.
2020-09-18
03 Bob Hinden IETF WG state changed to In WG Last Call from WG Document
2020-09-15
03 Bob Hinden IETF WG state changed to WG Document from Submitted to IESG for Publication
2020-09-15
03 Jen Linkova New version available: draft-ietf-6man-grand-03.txt
2020-09-15
03 (System) New version accepted (logged-in submitter: Jen Linkova)
2020-09-15
03 Jen Linkova Uploaded new revision
2020-09-13
02 Jen Linkova New version available: draft-ietf-6man-grand-02.txt
2020-09-13
02 (System) New version accepted (logged-in submitter: Jen Linkova)
2020-09-13
02 Jen Linkova Uploaded new revision
2020-09-06
01 Erik Kline IESG state changed to AD Evaluation from Publication Requested
2020-08-12
01 Amy Vezza Changed consensus to Yes from Unknown
2020-08-12
01 Amy Vezza Intended Status changed to Proposed Standard from None
2020-08-12
01 Bob Hinden
Document Shepherd writeup for:

  Title:    Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-
            Hop Routers
  …
Document Shepherd writeup for:

  Title:    Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-
            Hop Routers
  Author:  Jen Linkova
  Filename: draft-ietf-6man-grand


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

  Standards Track, Proposed Standard

  This is the correct status, because it is updating RFC4861
  "Neighbor Discovery for IP version 6 (IPv6)".


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections: 

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

  Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the
  link-layer addresses of neighboring nodes as well as to discover and
  maintain reachability information.  This document updates RFC4861 to
  allow routers to proactively create a Neighbor Cache entry when a new
  IPv6 address is assigned to a node.  It also updates RFC4861 and
  recommends nodes to send unsolicited Neighbor Advertisements upon
  assigning a new IPv6 address.  The proposed change will minimize the
  delay and packet loss when a node initiate connections to off-link
  destination from a new IPv6 address.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough? 

  The document had active discussion in the w.g. and there is a strong
  consensus to advance it.

  The discussion spawned a side discussion about security and Neighbor Discovery, but
  that is not related to this document, nor should it hold it up.


Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, YANG Doctor, Media Type or other expert review, what was its
course (briefly)? In the case of a Media Type review, on what date was
the request posted?

  It was well reviewed by the w.g.

  The document is very clear on what changes it is making to RFC4861,
  show old text and new text.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Bob Hinden is Document Shepherd.
  Erik Kline is Responsible Area Director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  I, as Document Shepard and w.g. co-chair, have reviewed the document
  and w.g. discussion.
 
  I think it is ready for publication.
 

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  The document had a lot of discussion.    No concerns with advancing it.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

  The author is not aware of any IPR on this other than what was filed
  against the individual version of the draft.  See:

  https://datatracker.ietf.org/ipr/search/?id=draft-linkova-6man-grand&submit=draft


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  See (7).

  There was a short discussion about this on the list, no objection
  advancing the document was raised.
 

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

  Strong support, lots of comments, they were responded to quickly by
  the author and resolved.
 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough. 

  ID nits is confused about a reference to draft-ietf-v6ops-nd-cache-init

    -- Unexpected draft version: The latest known version of
      draft-ietf-v6ops-nd-cache-init is -01, but you're referring to -03.

  draft-ietf-v6ops-nd-cache-init-03 exists in the datatracker.

    https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-cache-init/
   

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  N/A

(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All normative references are published RFCs.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

  No.


(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

  This document updated RFC4861, this is shown in the title page header,
  Abstract, and Introduction.
 

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).

  No IANA requests.
 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

  N/A
 

(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the YANG
module comply with the Network Management Datastore Architecture (NMDA)
as specified in RFC8342?

  N/A
2020-08-12
01 Bob Hinden Responsible AD changed to Erik Kline
2020-08-12
01 Bob Hinden IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-08-12
01 Bob Hinden IESG state changed to Publication Requested from I-D Exists
2020-08-12
01 Bob Hinden IESG process started in state Publication Requested
2020-08-12
01 Bob Hinden

Internet-Draft            MPVD architecture              September 2014

4.3.  A Home Network and a Network Operator with …

Internet-Draft            MPVD architecture              September 2014

4.3.  A Home Network and a Network Operator with Multiple PvDs

  An operator may use separate PvDs for individual services which they
  offer to their customers.  These may be used so that services can be
  designed and provisioned to be completely independent of each other,
  allowing for complete flexibility in combinations of services which
  are offered to customers.

  From the perspective of the home network and the node, this model is
  functionally very similar to being multihomed to multiple upstream
  operators: Each of the different services offered by the service
  provider is its own PvD with associated PvD information.  In this
  case, the operator may provide a generic / default PvD (explicit or
  implicit), which provides Internet access to the customer.
  Additional services would then be provisioned as explicit PvDs for
  subscribing customers.

  The following diagram illustrates this, using video-on-demand as a
  service-specific PvD:

                <------ Implicit 'Internet' PvD ------>
          +----+    +----+        _  __              _  _
          |    |    |    |        ( `    )            ( `  )_
          | PC +-----+    |--------------------------(        `)
          |    |    |    |      (        )        (_ Internet  _)
          +----+    |    |    (          )        `- __  _) -
                      |Home|    (  Service    )
                      |gate|    (  Provider's  )
                      |-way|    (  Network    -
          +-----+    |    |    `_            )        +---------+
          | Set |    |    |      (          )        |ISP Video|
          | Top +----+    |---------------------------+on Demand|
          | Box |    |    |      (_    __)          | Service |
          +-----+    +----+        `- --            +---------+
                <-- Explicit 'Video-on-Demand' PvD -->

              An example of PvD use within a home network.

  In this case, the number of PvDs that a single operator could
  provision is based on the number of independently provisioned
  services which they offer.  Some examples may include:

  o  Real-time packet voice

  o  Streaming video

  o  Interactive video (n-way video conferencing)

  o  Interactive gaming

  o  Best effort / Internet access

5.  Reference Model for the PvD-aware Node

Anipko                  Expires March 17, 2015                [Page 12]
Internet-Draft            MPVD architecture              September 2014

5.1.  Constructions and Maintenance of Separate PvDs

  It is assumed that normally, the configuration information contained
  in a single PvD shall be sufficient for a node to fulfill a network
  connection request by an application, and hence there should be no
  need to attempt to merge information across different PvDs.

  Nevertheless, even when a PvD lacks some necessary configuration
  information, merging of information associated with different PvD(s)
  shall not be done automatically as this will typically lead to the
  issues described in [RFC6418].

  A node may use other sources, for example: node local policy, user
  input or other mechanisms not defined by the IETF for any of the
  following:

  o  Construction of a PvD in its entirety (analogous to statically
      configuring IP on an interface)

  o  Supplementing some, or all learned PvDs with particular
      configuration elements

  o  Merging of information from different PvDs (if this is explicitly
      allowed by policy)

  As an example, a node administrator could inject a DNS server which
  is not ISP-specific into PvDs for use on any of the networks that the
  node could attach to.  Such creation / augmentation of PvD(s) could
  be static or dynamic.  The specific mechanism(s) for implementing
  this are outside of scope of this document.

5.2.  Consistent use of PvDs for Network Connections

  PvDs enable PvD-aware nodes to consistently use the correct set of
  configuration elements to serve specific network requests from
  beginning to end.  This section provides examples of such use.

5.2.1.  Name Resolution

  When a PvD-aware node needs to resolve the name of the destination
  for use by a connection request, the node could use one, or multiple
  PvDs for a given name lookup.

  The node shall chose a single PvD if, for example, the node policy
  required the use of a particular PvD for a specific purpose (e.g.  to
  download an MMS message using a specific APN over a cellular
  connection). To make this selection, the node could use a match
  between the PvD DNS suffix and an FQDN which is being resolved or
  match of PvD ID, as determined by the node policy.

Anipko                  Expires March 17, 2015                [Page 13]
Internet-Draft            MPVD architecture              September 2014

  The node may pick multiple PvDs, if for example, the PvDs are for
  general purpose Internet connectivity, and the node is attempting to
  maximize the probability of connectivity similar to the Happy
  Eyeballs  [RFC6555] approach.  In this case, the node could perform
  DNS lookups in parallel, or in sequence.  Alternatively, the node may
  use only one PvD for the lookup, based on the PvD connectivity
  properties, user configuration of preferred Internet PvD, etc.

  If an application implements an API that provides a way of explicitly
  specifying the desired interface or PvD, that interface or PvD should
  be used for name resolution (and the subsequent connection attempt),
  provided that the host's configuration permits this.

  In either case, by default a node uses information obtained via a
  name service lookup to establish connections only within the same PvD
  as the lookup results were obtained.

  For clarification, when it is written that the name service lookup
  results were obtained "from a PvD", it should be understood to mean
  that the name service query was issued against a name service which
  is configured for use in a particular PvD.  In that sense, the
  results are "from" that particular PvD.

  Some nodes may support transports and / or APIs which provide an
  abstraction of a single connection, aggregating multiple underlying
  connections.  MPTCP [RFC6182] is an example of such a transport
  protocol.  For connections provided by such transports/APIs, a PvD-
  aware node may use different PvDs for servicing that logical
  connection, provided that all operations on the underlying
  connections are performed consistently within their corresponding
  PvD(s).

5.2.2.  Next-hop and Source Address Selection

  For the purpose of this example, let us assume that the preceding
  name lookup succeeded in a particular PvD.  For each obtained
  destination address, the node shall perform a next-hop lookup among
  routers associated with that PvD. As an example, the node could
  determine such associations via matching the source address prefixes/
  specific routes advertized by the router against known PvDs, or
  receiving an explicit PvD affiliation advertized through a new Router
  Discovery [RFC4861] option.

  For each destination, once the best next-hop is found, the node
  selects the best source address according to rules defined in
  [RFC6724], but with the constraint that the source address must
  belong to a range associated with the used PvD.  If needed, the node
  would use prefix policy from the same PvD for selecting the best
  source address from multiple candidates.

  When destination / source pairs are identified, they are sorted using
  the [RFC6724] destination sorting rules and prefix policy table from
  the used PvD.

Anipko                  Expires March 17, 2015                [Page 14]
Internet-Draft            MPVD architecture              September 2014

5.2.3.  Listening Applications

  Consider a host connected to several PvDs, running an application
  that opens a listening socket / transport API object.  The
  application is authorized by the host policy to use a subset of
  connected PvDs that may or may not be equal to the complete set of
  the connected PvDs.  As an example, in the case where there are
  different PvDs on the Wi-Fi and cellular interfaces, for general
  Internet traffic the host could use only one, preferred PvD at a time
  (and accordingly, advertise to remote peers the host name and
  addresses associated with that PvD), or it could use one PvD as the
  default for outgoing connections, while still allowing use of the
  other PvDs simultaneously.

  Another example is a host with an established VPN connection.  Here,
  security policy could be used to permit or deny application's access
  to the VPN (and other) PvD(s).

  For non-PvD aware applications, the operating system has policies
  that determine the authorized set of PvDs and the preferred outgoing
  PvD. For PvD-aware applications, both the authorized set of PvDs and
  the default outgoing PvD can be determined as the common subset
  produced between the OS policies and the set of PvD IDs or
  characteristics provided by the application.

  Application input could be provided on per-application, per-
  transport-API-object or per-transport-API-call basis.  The API for
  application input may have an option for specifying whether the input
  should be treated as a preference instead of a requirement.

5.2.3.1.  Processing of Incoming Traffic

  Unicast IP packets are received on a specific IP address associated
  with a PvD.  For multicast packets, the host can derive the PvD
  association from other configuration information, such as an explicit
  PvD property or local policy.

  The node OS or middleware may apply more advanced techniques for
  determining the resultant PvD and / or authorization of the incoming
  traffic.  Those techniques are outside of scope of this document.

  If the determined receiving PvD of a packet is not in the allowed
  subset of PvDs for the particular application / transport API object,
  the packet should be handled in the same way as if there were no
  listener.

Anipko                  Expires March 17, 2015                [Page 15]
Internet-Draft            MPVD architecture              September 2014

Document Shepherd writeup for:

  Title:    Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-
            Hop Routers
  Author:  Jen Linkova
  Filename: draft-ietf-6man-grand


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

  Standards Track, Proposed Standard

  This is the correct status, because it is updating RFC4861
  "Neighbor Discovery for IP version 6 (IPv6)".


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections: 

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

  Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the
  link-layer addresses of neighboring nodes as well as to discover and
  maintain reachability information.  This document updates RFC4861 to
  allow routers to proactively create a Neighbor Cache entry when a new
  IPv6 address is assigned to a node.  It also updates RFC4861 and
  recommends nodes to send unsolicited Neighbor Advertisements upon
  assigning a new IPv6 address.  The proposed change will minimize the
  delay and packet loss when a node initiate connections to off-link
  destination from a new IPv6 address.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough? 

  The document had active discussion in the w.g. and there is a strong
  consensus to advance it.

  The discussion spawned a side discussion about security and Neighbor Discovery, but
  that is not related to this document, nor should it hold it up.


Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, YANG Doctor, Media Type or other expert review, what was its
course (briefly)? In the case of a Media Type review, on what date was
the request posted?

  It was well reviewed by the w.g.

  The document is very clear on what changes it is making to RFC4861,
  show old text and new text.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Bob Hinden is Document Shepherd.
  Erik Kline is Responsible Area Director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  I, as Document Shepard and w.g. co-chair, have reviewed the document
  and w.g. discussion.
 
  I think it is ready for publication.
 

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  The document had a lot of discussion.    No concerns with advancing it.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

  The author is not aware of any IPR on this other than what was filed
  against the individual version of the draft.  See:

  https://datatracker.ietf.org/ipr/search/?id=draft-linkova-6man-grand&submit=draft


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  See (7).

  There was a short discussion about this on the list, no objection
  advancing the document was raised.
 

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

  Strong support, lots of comments, they were responded to quickly by
  the author and resolved.
 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough. 

  ID nits is confused about a reference to draft-ietf-v6ops-nd-cache-init

    -- Unexpected draft version: The latest known version of
      draft-ietf-v6ops-nd-cache-init is -01, but you're referring to -03.

  draft-ietf-v6ops-nd-cache-init-03 exists in the datatracker.

    https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-cache-init/
   

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  N/A

(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All normative references are published RFCs.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

  No.


(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

  This document updated RFC4861, this is shown in the title page header,
  Abstract, and Introduction.
 

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).

  No IANA requests.
 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

  N/A
 

(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the YANG
module comply with the Network Management Datastore Architecture (NMDA)
as specified in RFC8342?

  N/A
2020-08-12
01 Bob Hinden Notification list changed to Bob Hinden <bob.hinden@gmail.com>
2020-08-12
01 Bob Hinden Document shepherd changed to Bob Hinden
2020-08-09
01 Bob Hinden IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2020-07-25
01 Jen Linkova New version available: draft-ietf-6man-grand-01.txt
2020-07-25
01 (System) New version accepted (logged-in submitter: Jen Linkova)
2020-07-25
01 Jen Linkova Uploaded new revision
2020-07-15
00 Bob Hinden IETF WG state changed to In WG Last Call from WG Document
2020-03-09
00 Jen Linkova This document now replaces draft-linkova-6man-grand instead of None
2020-03-09
00 Jen Linkova New version available: draft-ietf-6man-grand-00.txt
2020-03-09
00 (System) New version accepted (logged-in submitter: Jen Linkova)
2020-03-09
00 Jen Linkova Uploaded new revision