Thanks to Barry Leiba for their secdir review.

My discuss has been resolved.  TYVM.

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

This is my second complete review after -08 as -12 is mostly a welcomed rewrite of the text. But, I am afraid that there are still too many errors (mostly minors but some more important) preventing me to ballot the strong supportive YES that I wished to ballot.

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.

Please find below some non-blocking COMMENT points.

Special thanks to Tim Winters for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status, *but* I wonder whether the shepherd's write-up should have been updated after such a major rewrite (even if the technical content has not really changed).

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)


### Section 1

s/that nodes (hosts and routers) on a link/that IPv6 nodes (hosts and routers) on a link/ ? :-)

More concerning is the 'overall procedure' description:

1) A lot of the steps are used even in the absence of SLAAC (static configuration or DHCPv6) and the leading text should not restrict the list to SLAAC only. 
2) Should the MLD multicast group join be cited ?
3) RA do not always contain PIO for the prefixes

s/A router sends a Redirect to inform a host of a better next-hop for the host's traffic/A router sends *an ICMP Redirect* to inform a *node* of a better next-hop for the *node*'s traffic/

### Section 1.1

In "host isolation", there could be some words about routers as well. Esp with L3 isolation as the 'host' could act as a thethering node for VM or actual downstream nodes.

### Section 2.1

You may consider avoiding to repeat some acronym expansions.

Should the energy consumption be mentioned as an issue with wireless mcast ?

Rather than having 5 different issues noted as "similar" why not simply talk about NA & RA (and when NA/RA are used) ? Should sollicited node mcast addresses be mentioned somewhere (esp for NA) ?

s/Because DAD treats no response as no duplication/Because DAD treats no response as no *duplicate address detected*/

Suggest adding ':' after issue number, e.g., "Issue 1: ".

### Section 2.2

Suggest using the more common "rogue RA" rather than `forged RA`.

### Section 2.3

If 'solicited node mcast' was introduced earlier, then `The router then multicasts Neighbour Solicitations (NS) to all nodes`  would sound less contradicting (multicast <-> all nodes).

A word is probably missing in `completing the NCE`.

Unsure whether issue 14 is a real issue caused by ND, it also exists in any L3 protocol where the L2 address must be discovered.

As RFC 9686 exists this statement is not really correct: `there is no standardized method to retrieve these entries for management purposes`.

Should issue 14 be part of section 2.2  (lack of trust) ?

### Section 3

s/not formally defined/not formally defined by the IETF/ (e.g., TR-101)

### Section 3.2

`Every host, e.g., the Residential Gateway (RG),` unsure whether a RG can really be considered as a 'host' as it will forward packets.

Should `L2 Split Horizon` be defined ? Perhaps in the terminology section ?

In the list following `Since all hosts appear on the same interface from the router's perspective`, I would swap the order of the two bullets.

Suggest first listing & explaining the key aspects of FBBv6-P2MP, then explain what are the security benefits ?

### Section 3.3

There are some layer-2 techniques (Wi-Fi AP in isolation mode or 'private VLAN' in some switches -- using Cisco terminology here but I am sure that all other vendors have the same features) that block all layer-2 frames between hosts. Is it worth mentioning ?

### Section 3.4

`The router sets PIO L-bit to 0` is correct but some explanations on why the following sentence is correct would help the reader.

### Section 3.6

Just a nit, please remove the trailing ':' in the section title.

### Section 3.7

Proxy ND for EVPN is not really something new as it relies on plain ND in the PE. I.e., I think that this section should be removed.

### Sections 3.5, 3.6, 3.7

The conclusions of these sections but the text is different, sometimes it refers to section 2.4 and other times to section 2.1. Should the I-D be consistent ?

### Section 3.9

AFAIK, with GRAND the router will also forward the packet as the NCE is in STALE and not INCOMPLETE, so, also addressing the delay. It is marked 'partly' in the summary table and I wonder why. Some text saying so should appear in this section.

### Section 3.10

`SAVI and RA-Guard address the on-link security issues.` but I do not think that the I-D has described 'on-link security issue' in section 2 but more 'trusting-all-nodes'.

### Section 3.11

What are `irregular packet drops` ? suggest removing 'irregular' and also indicate that the packet drops happen when sent from the router to the local node.

### Section 4.2.1

Unsure whether it is correct to write `A large number of interfaces will be required at the router`

### Section 4.3

I am biased of course but section 2.3 of RFC 9099 had some good recommendations and from what I have seen in actual deployments is mainly a combination of SAVI/RA-guard, mcast optimisation/L2 isolation over Wi-FI, and some user attribution techniques (where 802.1X helps a lot). I have rarely seen L3 isolation in real enterprise network though (only in ISP).

Therefore, I wonder whether recommendations could be split in two parts: enterprise-like networks and ISP-like networks.

(1) One of my issues is the way the document mixes different document statuses without an attempt  separate them for a reader - to me this is really confusing. If the document is to form a valuable reference, I think there should be much more clarity on the status of what is being presented. (Thanks for addressing this issue.)

(2) The following are non-blocking comments, but I do hope the editors take the opportunity to improve this document to make it a valuable RFC. These comments relate to specific text:

“The protocol uses multicast extensively.” I think this ought to read “The protocol uses multicast IPv6 packets.” - It might generate extensive multicast traffic in the writer’s mind, but the important point seems this is multicast.

I don’t think ICMPv6 redirect is a ND problem. It is atrocious best a related problem.

“Neighbor Discovery (ND) [RFC4861] defines the protocol mechanisms that nodes (hosts and routers) on a link interact with each other.”
- This seems confused - I thought this was to discover information about the next-hop?

It would be really helpful to provide a reference to where info about GUA and ULA can be found.

“Given that a unique prefix can be allocated per host on shared media, hosts in different subnets may be in the same link.”
- what does in the same link mean? - is this same layer 2 VLAN, use the same pair of MAC unicast addresses, share the same physical link?
“ L2 Isolation - taking measures to prevent a host from reaching other hosts directly in Layer 2 (L2) so that every host is in a
 different link. “
- what does a different link mean? - is this same layer 2 VLAN, use the same pair of MAC unicast addresses, share the same physical link?

/Routers respond with unicast Router Advertisements/ Is this correct, please check RFC 4861.

/Node Solicitations NSs),/Node Solicitations (NSs),/ - please add an open bracket.

“to a higher probability of interference,” - Is this radio interference - please explain why this is so?

“lower data rate, and lack of acknowledgements. [RFC9119].” - remove extra period before reference.
 
“messages may wake them up and create battery life issues” - what are the issues, does this mean can deplete the battery, or is there some other issue?

Issue 13: “The resulting resource exhaustion may render the router unable to function.“ - why please explain, I understand that the might fill the Neighbor Cache - and that could prevent learning new Neighbor Cache entries, but why would this prevent a router functioning?

/2.4. Summary of ND Issue/ - is there a missing final ’s’?

“All issues solved” is slightly misleading, is this all identified issues solved?

What is: 7772 - is this RFC 7772? please update or cite in the table. 
What is: 6583 - is this RFC 6583? please update or cite in the table

It took me a little while to realise that each subsection of section 3 denoted a case in the table. Could you prefix each following section title please with the abbreviations used in Table 1.

“Scalable Address Resolution Protocol [RFC7586] was an experimental solution that ended in 2017.”
What does ‘ended’ mean in this context? - This is an EXP RFC, whose experiment has concluded. I think the text needs to be clearer about this. Why is this needed to be listed alongside other methods that are current? I think the document would be better without this.

“Prioritizing NDP processing for existing NCEs over creating new NCEs”/“Prioritise …”

References:
* RFC 4291 is not cited, please remove.
* Gratuitous ARP is defined in RFC 5227, not [TCPIP] - Please correct this reference .

===

Many thanks for the hard work and considering the my review feedbacks. I'll clear my Abstain position and set a NoObjection.

For tracking purposes the Abstain comments: 
https://mailarchive.ietf.org/arch/msg/v6ops/PG4IoohFQMXYnI-kOh1RYkdV8Yg/

As a non-routing expert, I found this document a very good read. I do urge the authors to consider the feedback of other ADs to resolve their abstain ballots.

NITS:

The table in section 3 should really be fixed to have no blanc lines

A number of RFC references are broken (missing link)

Thank you to Ines Robles for the GENART review.