Subject: Éric Vyncke's No Objection on draft-ietf-6man-grand-05: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 29 Jun 2021 08:32:07 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-6man-grand-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-grand/

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

---

From: Jen Linkova <[email-masked]>
Date: Wed, 30 Jun 2021 11:22:41 +1000

Hi Eric,

> about to raise a trivial-to-address DISCUSS).

Wait, was it an option to ignore your comments?!! Nobody has told me that ;))

> I hope that this helps to improve the document,

Absolutely, thank you very much for your review and suggestions!
In my responses below "done" means that the changes will be integrated in -06.

> document updates the Neighbor Discovery protocol [RFC 4861]/

Done.

> link-local" ? I would assume link-layer would be enough (no need to do NUD at

What I mean is that the host usually needs an IPv6 address of its
default router to make a decision where to send a packet, before the
address resolution (IP -> MAC) even starts.

> In the description, should the "host" rather be a "node" (i.e., possibly having

Oh that one is a bit tricky, IMHO.
I was considering replacing 'host' with 'node' almost everywhere in
the document, ex. Section 6.
However I'm not sure it would improve the readability: I kind of find
it useful to distinguish two actors here: a device which receives RAs,
configures addresses via SLAAC and originates traffic ("a host") and
the router, which forwards transit traffic. I've also noticed that
RFC4862 explicitly says that SLAAC applies to hosts, not routers.
Almost any host could be a router nowadays indeed.

Also, Section 2 explicitly talks about "the most typical scenario", so
saying "host" seems to be appropriate in this section, as it's an
example of what happens, not an attempt to give the complete list.

What I might do is to go through the document and replace 'host' with
'node' in most places (Section 6 makes that distinction clear already,
as it's the only place where it's really important). But I'm reluctant
to change Section 2.

> adding "to multiple destinations" ?

We can say 'to one or multiple destinations' but I'm not sure the
number of destinations does matter here.
If the host (the node? ;)) sends 3 DNS requests to the same server or
to 3 different ones, responses could still be lost if they arrive
before the resolution is completed.
Am I missing anything here?

> receiving the NA/NS traffic (in this I-D only routers else all nodes).

The number of IPv6 multicast packets would stay more or less the same.
The total number of packets actually delivered to
all nodes on the link would mostly depend on the MLD configuration. I
think that if the MLD is enabled, then even w/o the proposed changes
the NSes should be only delivered to the target node (as it would be
the only one joined the solicited node mcast address group), while w/o
MLD even 'all routers'. could be delivered to all nodes...
Do you think it's worth clarifying or we shall avoid that sensitive MLD topic?

> been dropped anyway. Nothing dramatic but I wonder whether a rephrase would

Oh. Thank you very much for pointing this out. This section does need
the full rewrite.
So the new text in 06 will be:
---

5.2.  Neighbor Cache Entry is in INCOMPLETE state
   Another corner case is the INCOMPLETE cache entry for the address.
   1.  The router receives a packet for the address.
   2.  The router starts the address resolution process by creating an
       INCOMPLETE entry and sends the multicast NS.
   3.  More packets arrive at the router for the address in question.
   4.  The host configures an Optimistic address and sends an
       unsolicited NA.
   5.  The router creates a STALE entry and sends the buffered packet(s)
       to the host (while those packets are actually intended for the
       rightful owner).
   6.  As the STALE entry was used to send packets, the router changes
       the entry state to DELAY and waits up to DELAY_FIRST_PROBE_TIME
       ([RFC4861], 5 secs) before sending unicast NS.
   7.  The rightful owner responds with a solicited NA with the Override
       flag set.
   8.  The router updates the entry with the TLLAO supplied (the
       rightful owner link-layer address) and sets the entry state to
       REACHABLE (as the NA has the Solicited flag set).

   Therefore, the unsolicited NA causes the following effects:

      - The buffered packets (usually just one packet but routers may
      buffer more) are delivered to the wrong node.  Without the
      unsolicited NA the packet(s) would have been delivered to the
      rightful owner after the address resolution is completed.
      -While all subsequent packets arriving and until Step 8 is
      completed are also delivered to the wrong node, without the
      unsolicited NA those packets would have been dropped anyway.
----

Better?

> 'communication' be qualified as on-link or not on-link ?

Good point, thanks. I meant smth like 'recently or ever' indeed, just
did not make it explicit enough..

The new text:
"The rightful owner of the address has not been using it for off-link
communication recently or has never used it at all."

> s/rightful owner/original owner/ because the first owner could actually be an

I've updated the Section 5:
OLD TEXT:
--
The following sections discuss the address collision scenario when a
node sends an unsolicited NA for an address in the Optimistic state,
while another node has the same address assigned already.
---
NEW TEXT:
---
 The following sections discuss the address collision scenario when a
node sends an unsolicited NA for an address in the Optimistic state,
while another node (the rightful owner) has the same address assigned
already. This document uses the term "the rightful owner" as the same
terminology is used in RFC4429.
---

so we can avoid the whole discussion on 'how to prove your rights for
an IPv6 address and what does it mean'..

> duplicated address and the new host. / ?

Who about:
"The router receives the return traffic for the IPv6 address in
question.  Some flows intended for the rightful owner of the
duplicated address, while some are for the new host.

> to send unsollicited NA. Where is it specified ?

In section 6.1.2, I believe. Or do you mean smth else?

> What should the router do if not discarding in "SHOULD be silently discarded."

Hmm...The text just above defines how to process the NA if it's not
discarded. Then we say 'and if there is no TLLA - discard'. Do you
think we shall repeat 'and if you do not discard - process as above'?
My concern would be that the old text does not specify what to do if
the NA is not discarded. So if we start overspecifying it might led to
changes in the behaviour for nodes which discard it already...

> text as a line of dashes ;-)

The best DISCUSS comment ever. Fixed, thanks!

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

The following sentence was intended to explain:
"In such cases a node SHOULD send up to MAX_NEIGHBOR_ADVERTISEMENT
   Neighbor Advertisement messages."

Do you think it's not clear enough? Would it be better if s/In such
cases/To do this/?

> also...to preferred" *before* the § about anycast.

Please note that the sentence about anycast (the first one in the
OLD/NEW TEXT) is *not* changed at all. It is used for reference to
indicate where to insert the new text.
If I read your suggestion correctly, you propose to move the new text
one paragraph above (so that anycast sentence will be after the
inserted text). However,
the thing is: RFC4861 has a section which talks about using
unsolicited NAs as a notification mechanism in case the link-layer
address changes.
Then the last paragraph of the section is about 'unsolicited NAs are
not really reliable, it's just an optimization'.
So IMHO the proposed place is the best one to insert the text.

The new (inserted) text does not say anything about anycast and is
applicable to any global address. I think the fact that it's a new
paragraph shall give the reader a clear indication that it's not
really related to the previous anycast discussion.

> s/default router/first-hop routers/ ?

I think there is a subtle difference here. The host maintains the
default router list (as per RFC4861) and all the host knows is IPv6
addresses.
So from the host perspective there are default routers.
>From the topology perspective there are first-hop routers (and not all
of them are necessary in the default router list on the host side. For
example, in the case of VRRP).
So the document talks about the default routers when it discusses the
host perspective.

> advantage of requiring only host changes.

Sorry, could you elaborate?
By 'this specification' you mean the proposed GRAND mechanism? So you
are saying that unsolicited NAs can be blocked (inlikely, IMHO) or the
VRRP masters would not get the packet?
Or..?

> packet sourced by a on-link neighbor node/

Fixed.

> sollicited-node mcast address and not all nodes/routers.

Changed to "disclosed via DAD to all nodes anyway if MLD snopping is
not enabled."
> a comma as I learned from RFC Editor ;-)

;) I only omit a comma in 2/3 of the cases. Fixed (at least I think so..)

> s/can not/cannot/

Fixed, thanks!

-- 
SY, Jen Linkova aka Furry