Subject: [v6ops] Working Group Last Call draft-ietf-v6ops-nd-cache-init

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 15:51:13 +0000

Folks,
 
This message initiates a WG Last Call on draft-ietf-v6ops-nd-cache-init.
 
Please submit comments by June 8, 2020.

                                   Fred and Ron

Juniper Business Use Only

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 25 May 2020 18:52:01 +0200 (CEST)

> This message initiates a WG Last Call on draft-ietf-v6ops-nd-cache-init.

I read this draft in it entirety and have some comments.

2.2 typo: "follwing"

"   The proposed solution is discussed in [I-D.linkova-6man-grand].  In
    summary the follwing changes to [RFC4861] are suggested:"

3.4

"o  Some wireless devices are known to fiddle with ND packets and
       perform various non-obvious forms of ND proxy actions.  In some
       cases RSes might not even reach the routers."

"fiddle" might not be a great term to use here, as it seems to have 
multiple meanings according to Merriam Webster?

Then the security consideration section pointed to draft-ietf-6man-grand 
(or actually it didn't, it pointed to linkova-6man-grand which then 
pointed to draft-ietf-6man-grand), so I ended up reading that one as well.

These documents seem to belong together. I tried going back in 6man as 
well and couldn't find much discussion on how these two documents are 
supposed to be handled as a pair somehow? If this nd-cache-init is an 
operational document referencing 6man-grand and talking about this from an 
operational POV, then perhaps this should be stated in the introduction?

Commenting on both of them, I'd like to see some kind of text indicating 
that SAVI (RFC7039) RFCs had been taken into account and if anything 
specified in there might cause problems with the proposed approach in 
nd-cache-init and -grand.

But to sum up, I think the problem space these drafts are tackling is 
worth improving, and I support this work progressing.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Owen DeLong <[email-masked]>
Date: Mon, 25 May 2020 20:13:29 -0700

> On May 25, 2020, at 09:52 , Mikael Abrahamsson <swmike=[email-masked]> wrote:
> 
> "fiddle" might not be a great term to use here, as it seems to have multiple meanings according to Merriam Webster?
> 

Perhaps instead of “fiddle with” we could use the more technical term “alter”

Owen

---

From: Fernando Gont <[email-masked]>
Date: Sun, 31 May 2020 06:04:36 -0300

Jen/wg,

I support publication of this document. Bellow you'll find my review:

** Technical: **

* Section 2.2

You might want to note how the "override" flag in the NA is set, and the 
state in which the NCE should be created.

* Section 3.3

Might want to clarify which destination address to use?

* Section 3.4:
> 
>    o  If the address is in the Optimistic state the RS can not contain
>       SLLAO.  As a result the router would only create a cache entry if
>       the solicited RAs is sent as as a unicast.  Routers sending
>       solicited RAs as multicast would not create a new cache entry as
>       they do not need to send a unicast packet back to the host.

Of the top of my head, I'm not sure if an RA sent to a multicast address 
can be a "solicited RA" (as in "having the 'solicited' flag set). Please 
double-check.

** Editorial: **

* Section 1:
> This approach is perfectly suitable for host2host communications

s/host2host/host-to-host/

* Section 1:
> This approach is perfectly suitable for host2host communications 
> which are in most cases bi-directional and it could be expected that 
> if a host A has an ND cache entry for the host B IPv6 address, the 
> host B also has the corresponding ND entry for the host A address in 
> its cache.

Insert commas after "communications", and "bi-directional".

Remove "the" in "the host B also has"

* Section 1:
> However when a host communicates to off-link destinations
>    via its first-hop router that logic does not apply.

Insert comma after "router".

* Section 1:
> A host joins the network and receives a Router Advertisement

Add "(RA)", since you later use the acronym.
Also expand "RS" later on in the text.

* Section 1:
> Neighbor Cache with the router link-local and link-layer
>        addresses.

s/router/router's/

* Section 1:
> Very common use case is a mobile

Insert missing leading "A" ("A very common...")

* Section 1:
> the Optimistic Duplicate Address Detection [RFC4429] 

s/the//
Add "(DAD)", since you later use the acronym.
Possibly add comma after "[RFC4429]".

* Section 1:
>        (if the device has been performing the ND process for the roiter
>        LLA) but there are no entries for the device GUA.

s/roiter/router/

Maybe s/the ND process/address resolution/

* Section 1:
> Most router implementations buffer only
>        one data packet while performing the neighbor discovery for the
>        packet destination address,

Possibly s/the neighbor discovery/address resolution/ , since "neighbor 
discovery" encompasses many different functions.

* Section 1:
>    4.  If the host sends multiple probes in parallel it would considered
>        all but one of them failed.

s/considered/consider/

* Section 1:
> porbes

s/porbes/probes/

* Section 1:
> router neighbor cache

Maybe s/router/router's/

* Section 1:
>    starts using the new GUA previously unseen by the router, such as a

s/the new GUA/a new GUA/

* Section 1:
> or if the router Neighbor Cache has
>    been flushed.

s/router/router's/

* Section 1:
>    While in dual-stack networks this problem might hidden by Happy
>    Eyeballs [RFC8305] it manifest quite clearly in IPv6-only

s/might/might be/
s/manifest/manifests/

* Section 1.2:

Not sure if this section is needed. Just introduce the acronyms the 
first time you use each term, and that's it.

* Section 2.1:
>    o  In case of duplicate addresses present in the network the proposed
>       solution MUST NOT override the existing entry.

Add missing comma after "network"

* Section 2.2:
>    summary the follwing changes to [RFC4861] are suggested:

Fix typo.

* Section 3.2:
> required 

s/required/requires/

* Section 3:

Thinking out loud: One might move this section (and subsections) to an 
Appendix?

* Section 3.5:
> might be still performing the DAD

s/the//

* Section 3.6:
> 3.6.  Initiating Hosts2Routers Communication

s/Hosts2Routers/Host-to-Routers/

* Section 3.6:
>    The host may trigger the router to start the address resolution by

s/the//

Thanks!

Cheers,
Fernando

On 25/5/20 12:51, Ron Bonica wrote:
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
> 

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1