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

[Jen Linkova <[e-mail]>]

Hi Eric,

On Wed, Jun 30, 2021 at 1:32 AM Éric Vyncke via Datatracker
<[e-mail]> wrote:
> 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).

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.

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

Done.

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

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
> a router role) ?

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.

> Should "If the host sends multiple probes in parallel" be more detailed by
> 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?

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

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?

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

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?

>
> -- Section 5.3 --
>
> Should the 1. also includes NC entries that have expired ?
>Should
> '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
> attacker ;-)

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

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

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.

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

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

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

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

>
> -- 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 ;-)

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

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

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.

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

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

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

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

Fixed.

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

Changed to "disclosed via DAD to all nodes anyway if MLD snopping is
not enabled."
>
> == NITS ==
>
> "Therefore", ".e.g.", "So", "Otherwise", and "However" are usually followed by
> 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