Subject: John Scudder's No Objection on draft-ietf-6man-grand-05: (with COMMENT)

From: John Scudder via Datatracker <[email-masked]>
Date: Wed, 30 Jun 2021 18:32:39 -0700

John Scudder 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:
----------------------------------------------------------------------

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.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 1 Jul 2021 15:12:29 +1000

Hi John,

Thank you for your review and comments!

> packets arriving after the unsolicited NA.

Yeah, that's been pointed out already, -06 has this section
re-written, please take a look:
https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-06#section-5.2

> the analysis would be a little less rosy, right?

You are right. I've updated the text to clarify:

7. As the host has detected the address conflict already it does not
respond to the unicast NSes. (It is unlikely that the host has not
completed the DAD process at this stage, as DELAY_FIRST_PROBE_TIME (5
seconds) is much higher than the DAD duration
(DupAddrDetectTransmits*RetransTimer*1000 + MAX_RTR_SOLICITATION_DELAY
secs, section 5.4 of [RFC4862]). The default value for the DAD process
would be 1*1*1000 + 1 = 2 secs, [RFC4861]. If the host has completed
DAD but did not detect the address conflict then there are two hosts
with the same address in the Preferred state and the disruption is
inevitable anyway.

Also, -06 now has the text explaining that all those scenarios could
be easily avoided if the rightful owner also sends unsolicited NAs.

> Do you mean “are *not* implemented”?

Indeed I do, fixed.

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

Done.

-- 
SY, Jen Linkova aka Furry