[v6ops] Re: Éric Vyncke's Abstain on draft-ietf-v6ops-nd-considerations-08: (with COMMENT)

[Xipengxiao <[e-mail]>]

Hi Eric,

Thank you very much for your detailed reviews.  They revealed some subtle, and some not so subtle, errors or inconsistencies.  We spent many hours reviewing the comments, checking references and updating the draft.  Now we have a new version: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-considerations/. We believe it's in better quality now.  Please see our response to each one of your comments below.  Thank you.  XiPeng & co-authors

-----Original Message-----
From: Éric Vyncke via Datatracker <[e-mail]>
Sent: Tuesday, December 3, 2024 3:41 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Éric Vyncke's Abstain on draft-ietf-v6ops-nd-considerations-08: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-v6ops-nd-considerations-08: Abstain

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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-considerations/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-v6ops-nd-considerations-08
CC @evyncke

Thank you for the work put into this document. Having a single informational document for all NDP issues and mitigations technique is a good idea.

I would have liked to ballot a strong YES for such a document. Nevertheless, I am balloting ABSTAIN because the current version of the draft is difficult to read (typical from a document written by several authors, ask me about RFC
9099!) and contains too many approximations or minor errors.

Please find below several non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Tim Winters for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks for the 3rd V6OPS WG chair, Ron Bonica, for handling a document co-authored by his 2 other co-chairs ;-)

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Unused references

As indicated by the id-nits tool, please remove the reference entries for RFC
4903 and 4291.

==> Authors: fixed.  Not sure why our id-nits tool didn't find this issue.

### Abstract

s/trusts all hosts/trusts all nodes/ as nodes acting routers are also trusted
(IPv6 has a difference between host and node).

==> Authors: fixed.  

Is `to reveal that` the right English wording ? E.g., "show" looks more appropriate (but I am not an English speaker).

==> Authors: changed.

### Section 1

Suggest ordering the 8 main procedures by chronological order.

==> Authors: we intended to present a host's behaviors in SLAAC in chronological order, but we mixed host procedures and router procedures a bit so it may be unclear.  We've changed the text to make it clear, and also separated router's behaviors from host's behaviors.


`Routers respond with unicast Router Advertisements` is incorrect (even if it is the operationally preferred way) as RFC 4861 writes `the usual case is to multicast the response to the all-nodes group`.

==> Authors: fixed.

Suggest merging host & router neighbour discovery points.

==> Authors: as we said above, we separated router's behaviors from host's behaviors in the new version.

About GUA, isn't this the same for ULA for NDP (procedure 3) ?

==> Authors: yes.  We added a sentence:  For description simplicity, this document will not further distinguish GUA and ULA.

I would not qualify ICMP redirect as part of neighbour discovery, but I am be on the rough on this point ;-)

==> Authors: Redirect is listed as one of the 9 ND procedures in RFC4861 ;-).

Procedure 7 also applies to router, i.e., use "node" rather than "host".

==> Authors: as we said above, we separated router's behaviors from host's behaviors in the new version.

Should the issues be qualified in `ND can have issues`? E.g., "security and operational issues" ?

==> Authors: we think both versions are OK but we accepted yours.

s/for preventing *potential* ND issues and provides a simple guideline for selecting one of them/for preventing potential ND issues and *suggests* a simple guideline for selecting one of them/ ?

==> Authors: accepted.

### Section 1.1

Is there a difference in this draft between "subnet" and "link" ? Should there be a definition of those terms ?

==> Authors: yes.  Subnet is L3 while link is L2.  We added "This document uses the terms defined in [RFC4861]." In the Terminology section.

As "L3 isolation" is used in this document, suggest using this term rather than "Subnet Isolation" (same for the other related terms).

==> Authors: accepted.

Suggest to replace "routing proxy" by "ND proxy".

==> Authors: Pascal emphasized that there are two kinds of ND proxy, routing and bridging, and he wanted us to be explicit.  So we decided to use "L3 ND proxy" in the new version.

### Section 2.1

s/ND uses multicast for/In some cases, ND uses multicast for/ as NA / RA are not always sent over mcast.

==> Authors: accepted.

s/Hosts' LLA, GUA DAD/Nodes' LLA, ULA, GUA DAD/

==> Authors: accepted.

s/which depreciates the router on the host/*,* which *deprecates* the router on the host/

==> Authors: accepted.

`in an L2 network of N hosts, there can be N such multicast messages` is not correct, it is about the number of hosts addresses.

==> Authors: accepted and fixed.

`Hosts address resolution for hosts` should probably be about nodes (as routers to routers traffic exist) + same comment as above.

==> Authors: we distinguish host issue and router issue here, because some mitigation solutions fix one issue but not the other.  But we did change the sentence to "*Host’s* Address Resolution for Hosts "

`Hosts' MAC address change NAs` please note that MAC address changing is coming, see MADINAS documents.

==> Authors: thanks for the tip.  The new text is:
Hosts’ MAC Address Change NAs Degrading Performance: with randomized and changing MAC addresses [MADINAS], there may be many such multicast messages. As [MADINAS] is new, this issue is for further study.


### Section 2.2

Thanks for the reference to RFC 9099 ;)

Once DoS acronym is introduced, then let's use it rather than its expansion.

==> Authors: fixed.

Unsure whether forged RAs are a redirect attack though.

==> Authors: we agree this is in the grey area, but rfc3756 lists multiple Forged RA attacks in the Redirect category (Figure 1) 

Should traffic interception, dropping, and modification be mentioned as a consequence of several attacks ?

==> Authors: we don't want to get too deep into security.  We have RFC9099 after all ;-)

I would qualify "replay attack" as a mean and not really an end (i.e., not at the same level as the other listed issues).

==> Authors: we can see your point, but rfc3756 lists "replay attack" in parallel with other issues (Figure 1) so we just followed suit.  This is not our focus.

### Section 2.3

Unsure whether the first sentence is useful.

==> Authors: we revised and simplified the paragraph.

s/When a router is to forward a packet to a host/When a node is to send a packet to another node and there is no NCE/

==> Authors: we revised the paragraph.

As the document appears to often mix host/node, I will stop reviewing the use of those terms from now on.

==> Authors: we reviewed the whole document and s/host/node when needed.  In certain places, host does mean host because we want to distinguish host and router.

Suggest to change the section title to "Node-NCE-on-demand" or "Untrusted NCE Creation".

==> Authors: in this case, we want to distinguish host and router so it's still "Router-NCE-on-Demand"

Moreover, it is common for nodes to set the Source Link-layer Address option in a NS, i.e., NCE are not always created on demand.

==> Authors: accepted.  We revised the paragraph.

s/a host forms its own IP address/a host forms its own IP address(es)/ ?

==> Authors: we revised the paragraph.

The address accountability is not limited to SP-managed network, but basically to any managed network. Should a reference to draft-ccc-v6ops-address-accountability be added ? (even if not yet adopted)

==> Authors: accepted. We revised the paragraph and added the reference.

Even when using DHCPv6, the router will not know the MAC-IP binding if not snooping the DHCPv6 traffic and being able to map the DUID to a MAC address.

==> Authors: thanks for the tip. We revised the paragraph.

### Section 2.4

I3 is also about ULA.

==> Authors: yes.

I fail to see the big difference between I4 and I5 (see my previous comment).

==> Authors:  Because router's address resolution and host's address resolution can be affected by different factors, e.g., unique prefix per host can cause router not to do address resolution while setting PIO L=0 will cause host not to do address resolution, we decide to separate I4 & I5.

I6 and I7 are also mostly identical and also applies to ULA.

==> Authors:  similarly, RFC8273 fixed I7 but not I6 so we distinguish them.  Yes on ULA.

### Section 3

It is unclear to me whether there is an order in all the subsections.

==> Authors:  we revised the paragraph to explain the order.

### Section 3.1

Suggest to make it clear that in this section router = mobile gateway and host = UE.

==> Authors: done.

### Section 3.2

I had to read twice `all hosts on an access device` to understand that "host" = RG and "access device" = BNG.

==> Authors: we clarified in the draft that "access device" = OLT/DSLAM, router=BNG.

I have in mind that PPPoE is used for fixed broadband, i.e., MAC addresses are used.

==> Authors: yes, but we are not sure what you implied.  If you were saying that FBBv6 is not identical to MBBv6, we agreed.  We did: s/essentially the same/functionally similar/g.

As split horizon is an overloaded term, suggest qualifying it in `implementing Split Horizon` (e.g., adding layer-2 perhaps ?).

==> Authors: we added L2 in front of Split Horizon.

Should `Results of assigning a unique /64 prefix to each host` be stated earlier in this section ?

==> Authors: we revised the text here.

`There is no Router-NCE-on-Demand` AFAIK the RG still has LLA & ULA/GUA on its WAN interface, so, there are still NCE for the RG.

==> Authors: RG is the host here and we are talking about the router as we are discussing "Router-NCE-on-Demand".

### Section 3.3

RFC 8273 is informational, so s/Unique IPv6 Prefix per Host is specified in [RFC8273]/Unique IPv6 Prefix per Host is *described* in [RFC8273]/

==> Authors: accepted.

s/Assigning a unique prefix to each host with SLAAC/Assigning a unique prefix to each host with pre-host Prefix Information Option in the RA/

==> Authors: the paragraph has been revised and this is no longer relevant.

Also, `When a prefix is assigned to the host` is not really correct, rather use "reserved".

==> Authors: we don't quite understand why "assigned" is not correct as it's used in RFC8273, but we changed "assigned" to "allocated" anyway.

I am not sure whether `create (Prefix, MAC address) binding` is really correct as most routers will create a FIB entry towards the LLA, then maps the LLA to a MAC via the NCE.

==> Authors: thanks for the info. We changed the sentence to "The router can proactively install a forwarding entry for that prefix towards the host, eliminating the need for Router-NCE-on-Demand. ".

AFAIK, the MAC address can still change though.

==> Authors: are you talking about MADINAS?  Anyhow, Section 3.3 no longer contains the word "MAC", due to the change above.

s/hosts are in different subnets/hosts are in different prefixes/ ?

==> Authors: we prefer subnets as it contrasts better with link.  

### Section 3.5

Should the note from RFC 7586 appears in this I-D ? ` that experiment will end two years after the RFC is published`, i.e., the experiment is over and has not been followed upon. So unsure whether it is worth mentioning here without the above restriction.

==> Authors: we added such a note:   Scalable Address Resolution Protocol [SARP] was an experimental solution that ended in 2017, two years after the RFC was published in 2015.

### Section 3.7

s/The PEs are interconnected by an overlay network./The PEs are interconnected by an underlay network./

==> Authors: we meant to say that the PEs are connected by tunnels, so we change the text to:  The PEs are interconnected by EVPN tunnels.

In `multiple hosts are connected to a Provider Edge (PE) router acting as a switch`, IMHO it is the set of PE and the underlay that act together as a single layer-2 switch.

==> Authors: we deleted this sentence because "the set of PE and the underlay that act together as a single layer-2 switch" may paint a picture that "all hosts in the subnet are connected by a single L2 switch and therefore in a single L2 broadcast domain".  This is what the solution tries to avoid.

I also think that the EVPN description is incomplete as it does not describe how the handle the broadcast, unknown, multicast. I.e., what to do when a NS is received from an unknown source.

==> Authors: we don't believe this is necessary for our discussion. Or maybe we don't understand you?

About `the number of multicast address resolution messages is significantly reduced`, AFAIK NUD has still to be executed by the destination PE.

==> Authors: we don't believe this NUD is relevant to our discussion.  It's not multicast.

### Section 3.8

Please use 'node' in both bullets to make it clear that they are related to each other.

==> Authors: no, the second bullet is about the router. "node" in the middle of the 2nd bullet relates to "node" in the 1st bullet.

### Section 3.9

Suggest using the full first bullet of section 5.2 of  RFC 7772 to make the text easier to understand.

==> Authors: we revised this section and used part of "the first bullet of section 5.2 of  RFC 7772".

### Section 3.11

Isn't `Implement rate-limiting mechanisms for NDP` rather a vendor/implementor point ?

==> Authors: yes but it's prescribed by the RFC in discussion.

### Section 3.12

What issue does draft-ietf-dhc-addr-notification (soon a RFC BTW) address ? All other solutions were associated with issues.

==> Authors: we made it explicit: [AddrReg] provides a solution for Issue 15 discussed in Section 2.3..

### Section 3.15

Unsure whether this 'historical' section brings a lot of value.

==> Authors: if we don't include them, some readers may think that we are unaware of them, and think that the review is incomplete.

### Section 4.1

Suggest using "L2 isolation" rather than "L2 & L3 isolation" as it is implicit that nodes that are L2 isolated are also L3 isolated.

==> Authors: "L2 isolation" and "L2 & L3 isolation" are different.  Due to the existence of multi-link subnet, L2 isolation does not imply L3 isolation.

Missing a " in `Therefore, this isolation method is called Partial L2 Isolation" or "Proxy Isolation"`

==> Authors: fixed.

### Section 4.2.4

Suggest promoting this sub-sub-section as a new sub-section 4.3

==> Authors: accepted.

Many switch vendors have ad-hoc techniques to do more than SAVI on normal switches and those techniques are often used over Wi-Fi networks. Should this guidelines section also mention that some devices (AP/switches) are addressing the issues by implementing several techniques described in section 3?

==> Authors: accepted. We've made it explicit: picking an isolation method that is too weak means that the network administrator may need to deploy more *ND mitigation solutions reviewed in Section 3*

## NITS (non-blocking / cosmetic)

### Section 7

Suggest using a consistent reference naming rather than sometimes a RFC number and sometimes a short name (e.g., "GRAND").

==> Authors: we believe names are easier to remember than numbers. So if a name is available we use the name, otherwise the RFC number.  There are precedents for doing so.  RFC4861 uses mostly named references, but there is one instance of [RFC3667].

### E.g.

AFAIK, "e.g." is always followed by a ",".

==> Authors: you are right ;-)  All fixed.

Thank you again for the large amount of time/effort from you for improving the draft.  We appreciate it.

XiPeng & co-authors