Neighbor Discovery Considerations in IPv6 Deployments
draft-ietf-v6ops-nd-considerations-14

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-v6ops-nd-considerations and RFC 9898, changed IESG state to RFC Published)

[Ballot comment]

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

[Ballot discuss]
This discuss should be relatively straight forward.

References:  The lack of normative references in this draft is surprising.  For example, Neighbor Discovery is not explained, but sends the reader to RFC4861 for the protocol definition.  All 15 issues are explained by reference.  The authors should examine the reference list carefully to see which of them are actually normative.

[Ballot comment]

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

===

[Ballot discuss]
draft-ietf-v6ops-nd-considerations

I have read this for the first time, and I would like to discuss the table and following text in section 3.

The discussion mixes different document statuses without an attempt  separate them for a reader - to me this is really confusing. I think there should be much more clarity on the status of what is being presented. This could be included as an opening sentence after each bullet, added as a column in the table, or some other way. How can this best be resolved?

e.g.,
3.1 RFC 6459 - Informational. & RFC 7066 - Informational. &RFC 7278  - Informational.
So I conclude the discussion in 3.3 need to be provided as informational suggestions?

3.2
This is not IETF specification, but refers to RFC6957 (PS)

3.3 RFC8273 - Informational & RFC9663 - Informational.
So I conclude the discussion in 3.3 need to be provided as informational suggestions?

3.4 RFC6775 (PS) & RFC8505 (PS)

3.5 RFC7586 (EXP - experiment concluded)
So I conclude the discussion in 3.5 is only for historical perspective?

3.6 RFC8302 (PS)

... etc.

[Ballot comment]





draft-ietf-v6ops-nd-considerations

I have read this for the first time, and I have some significant issues with the text of this document.

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. This could be included as an opening sentence after each bullet, added as a column in the table, or some other way. How can this best be resolved?

3.1
RFC 6459 - Informational.
RFC 7066 - Informational.
RFC 7278  - Informational.
So I conclude the discussion in 3.1 is all informational suggestions?

3.2
This is not IETF specification, but refers to RFC6957 (PS)

3.3
RFC8273 - Informational.
RFC9663 - Informational.
So I conclude the discussion in 3.3 is all informational suggestions?

3.4
RFC6775 (PS)
RFC8505 (PS)

3.5
RFC7586 (EXP - experiment concluded)
So I conclude the discussion in 3.5 is only for historical perspective?


3.6
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 …”

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

===

[Ballot comment]
This is a returned document.

Major changes were made to address comments raised in the first round (Thanks Gunter and Éric) + my own review.

[Ballot comment]
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/

[Ballot discuss]
# Internet AD comments for draft-ietf-v6ops-nd-considerations-08
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

### S2.1

* "                    Additionally, three RAs in a row may be lost in
            wireless which depreciates the router on the host."

  First off: depreciates -> deprecates, I suspect?

  Secondly, whether and when a default route or any advertised prefixes
  are deprecated is a function of the advertised timers.  That might
  equate to losing 3 RAs or it might be a very different number, so say
  nothing of the NUD that also happens to verify a router's R flag status.

* In here and in S2.4 where the document reiterates the implications of lower
  reliability of DAD it should also say that IPv6 address formation relies
  on the extremely low probability of collisions (cf. birthday paradox for
  2^64).

### S3

* Why does RFC8273 not show "All issued solved" but with, say, an asterisk
  noting that some issues still depend on how isolated the L2 domain is?

  It's not that it doesn't solve all issues, its that it needs some L2 help
  (like the help MBBv6 inherently has).

  S4.1 hints as at this, but it might be more explicit: 8273 might fall into
  the MBBv6/FBBv6 category iff. the deployment happens to also include L2
  isolation.

* There should be an entry in the table, and a corresponding discussion
  section, for the RFC 9663 and P-flag deployment model.  Either that, or
  figure out some way to lump it together for discussion with 8273.

### S3.4

* This section kind of obfuscates the most important thing about "WiND":
  it is not mandatory to implement for general purpose hosts and so cannot
  be relied upon as a deployment option without further constraints placed
  upon the participating nodes.  I think this could be more clearly stated.

### S3.7

* Should probably note here that EVPN ARP/ND assistance generally cannot
  help with IPv6 anycast addresses (RFC 4291 S2.6, RFC 4861 O flag).

### S3.15.4

* "was not incorporated into the latest specification"

  This is a technically true statement but might give the reader the
  impression that 4429 is deprecated or not implemented, neither of which
  is true (Linux kernel supports optimistic DAD).

[Ballot comment]
# Internet AD comments for draft-ietf-v6ops-nd-considerations-08
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### __general__

* I think a useful perspective from which to approach things might have been
  to look at the similarities and differences between ND and ARP.  Several
  of the concerns listed here are unchanged from ARP, and some readers might
  not be aware of just how much ARP-assistance exists in network equipment
  (after >40 years) and from which they're benefiting.

  No changes necessary here; it would be quite a different doc.

* throughout: [DHCP-PD] can be replaced with [RFC9663]

### S1

* Item 1 and 3 seem to be the same to me, i.e. DAD is DAD regardless of
  GUA vs LLUA (not different "procedures").

* Item 4 and 5 seem to be the same to me, i.e. ND is ND regardless of the
  role of the node (not really different "main procedures"?).

### S1.1

* "each host in a P2P link to the router"

  It might be more correct to say something like "each host in a link with
  only routers (and no other hosts)" or something, since the logical
  isolation doesn't require a P2P link type, strictly speaking.

### S2.3

* "                                                                    In
          a service provider network, subscribers are typically managed
          by their IP addresses. Consequently, if the router does not
          know a host's IP address, the service provider cannot manage
          the subscriber."

  I'm not sure about this "typically" for IPv6; most service provider
  networks I know manage IPv6 subscribers by IPv6 prefix instead, but this
  probably depends on what's meant by "service provider networks".

  How about instead, a rewording along the lines of something like:

  "In service provider networks where subscribers are managed by IPv6
  address and not by IPv6 prefix, if the router does not ..."?

### S2.4

* Again, I would not separate LLA from GUA DAD -- DAD is DAD.

### S3.15.1, S3.15.2

* "It has [very] low market adoption."

  Is there any text or study anywhere showing there is non-zero deployment?

  No change needed here; more out of curiosity (but if something can be
  found then it could be added to the Informational references).

### S4.2.1

* Again, P2P links are one option but another is a link that is "effectively
  P2P" even if the link technology permits multiple nodes (e.g., if some
  IEEE 802. mechanism ensures only the host and the infrastructure
  routers are on the link but the link could still appear to be standard
  802.11/802.3).

## Nits

### Abstract

* "provides a one-stop reference" ->
  "provides a one-stop reference as of the time of writing"

### S1

* "one-stop reference" ->
  "one-stop reference at the time of writing"

### S4.2.1

* "mDNS, will not work" ->
  "mDNS, will not work without additional assistance"

  (since we have a whole working group that does exactly this :-)

[Ballot comment]
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)

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

### Abstract

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

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

### Section 1

Suggest ordering the 8 main procedures by chronological order.

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

Suggest merging host & router neighbour discovery points.

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

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

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

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

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

### Section 1.1

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

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

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

### Section 2.1

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

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

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

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

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

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

### Section 2.2

Thanks for the reference to RFC 9099 ;)

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

Unsure whether forged RAs are a redirect attack though.

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

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

### Section 2.3

Unsure whether the first sentence is useful.

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/

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

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

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.

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

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)

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.

### Section 2.4

I3 is also about ULA.

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

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

### Section 3

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

### Section 3.1

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

### Section 3.2

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

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

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

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

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

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

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/

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

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.

AFAIK, the MAC address can still change though.

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

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

### Section 3.7

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

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.

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.

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

### Section 3.8

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

### Section 3.9

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

### Section 3.11

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

### Section 3.12

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

### Section 3.15

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

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

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

### Section 4.2.4

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

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?

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

### E.g.

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

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-v6ops-nd-considerations-08

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-v6ops-nd-considerations-08.txt

# idnits complains about unused references

# Thank you for this document. It contains plenty of information useful for deploying IPv6 and help guide operators through the number of available NDP based drafts and solutions.

# I found the draft challenging to process during my review. I was deliberating between balloting a blocking DISCUSS or allowing the document to proceed with an Abstain. Ultimately, I chose to let the document progress. The reason I did not ballot DISCUSS is that, while the text is not technically incorrect, I believe the writing could be improved for clarity and readability. To assist and to help you get started with this effort, I have provided a few suggestions for idnits corrections and style improvements at various points in the document. I hope these contributions serve as a helpful starting point for enhancing the text. 

#DETAILED COMMENTS
#=================

115   Neighbor Discovery [ND] is specified in RFC 4861. It defines how
116   hosts and routers on the link interact with each other. ND contains
117   eight main procedures:

GV> Looking at RFC4861 there are 9 problems that ND solves.
https://www.rfc-editor.org/rfc/rfc4861.html#section-3
Is there a reason why the text from RFC4861 can be represented in this draft instead of paraphrasing and potentially wrongly representing intent?

127     3. Host's Global Unicast Address (GUA) DAD: hosts form GUA and use
128         multicast NSs for DAD.

GV> Is this including the ULA addresses? https://datatracker.ietf.org/doc/rfc4193/

149     . ND Trust Models and Threats [RFC3756],
150     . Secure ND [SeND],
151     . Cryptographically Generated Addresses [CGA],
152     . ND Proxy [RFC4389],
153     . Optimistic ND [RFC4429],
154     . ND for mobile broadband [RFC6459][RFC7066],
155     . ND for fixed broadband [TR177],
156     . ND Mediation [RFC6575],
157     . Operational ND Problems [RFC6583],
158     . Wireless ND (WiND) [RFC6775][RFC8505][RFC8928][RFC8929][SND],
159     . DAD Proxy [RFC6957],
160     . Source Address Validation Improvement [SAVI],
161     . Router Advertisement Guard [RA-Guard][RA-Guard+],
162     . Enhanced Duplicate Address Detection [RFC7527],
163     . Scalable ARP [RFC7586],
164     . Reducing Router Advertisements [RFC7772],
165     . Unique Prefix Per Host [RFC8273],
166     . ND Optimization for TRILL [RFC8302],
167     . Gratuitous Neighbor Discovery [GRAND],
168     . Proxy ARP/ND for EVPN [RFC9161].

GV> [editorial] What is the reason some references use RFC indication and others use an named reference?

178 1.1. Terminology

GV> Would it be possible to add a reference that some ND terminology is used from RFC4861 section 2 (e.g. node, router, link, on-link, etc) https://www.rfc-editor.org/rfc/rfc4861.html#section-2 . observe that some terminology abbreviations like NS, NA, RS, NCE is not specified in that section. potentially add them in this section or point to a RFC where these are specified to the intent of this document other abbreviations are not mentioned (e.g. MBBv6, 3GPP, FBBv6, LLNs, VPWS, TRILL, SARP )

283     . The packet has to be buffered before the router finds out the
284         MAC address of the host. This delays forwarding, and depending
285         on the router's buffer size, may also cause packet loss. This
286         is called "Router-NCE-on-Demand Forwarding Delay" in this
287         document.
288     . The way ND performs address resolution is the source node will
289         create an NCE entry first and set its state to INCOMPLETE, then
290         the node will multicast NSs to all the nodes and wait for the
291         destination node to reply with its MAC address. This creates a
292         security vulnerability. If an attacker sends a large number of
293         packets destined to non-existing IP addresses, the router will
294         create a large number of NCEs in INCOMPLETE state while trying
295         to resolve the MAC addresses. The router may run out of
296         resources and stop functioning. This is called "NCE Exhaustion"
297         in this document. Note that in this case, the attacker can be
298         off-link.
299     . With SLAAC, a host forms its own IP address. A router does not
300         know the host's IP address until an NCE entry is installed. In
301         a service provider network, subscribers are typically managed
302         by their IP addresses. Consequently, if the router does not
303         know a host's IP address, the service provider cannot manage
304         the subscriber. In other words, there is a lack of address
305         accountability. This is an issue for public access networks. In
306         addition, after the NCE entries are installed on the router,
307         there is no clearly defined method to retrieve them for
308         management purpose [RFC9099, Section 2.6.1.4].

GV> Proposal for a slight editorial rewrite:

"
1. Router-NCE-on-Demand Forwarding Delay: 
  When a packet arrives, the router must buffer it while attempting to determine the host's MAC address. This buffering delays forwarding and, depending on the router's buffer size, may lead to packet loss. This delay is referred to as "Router-NCE-on-Demand Forwarding Delay" in this document.

2. NCE Exhaustion Vulnerability: 
  Neighbor Discovery (ND) resolves addresses by creating a Neighbor Cache Entry (NCE) in the INCOMPLETE state and multicasting Neighbor Solicitations (NS) to discover the destination MAC address. This mechanism introduces a security vulnerability: an attacker can send a high volume of packets targeting non-existent IP addresses, causing the router to create numerous NCEs in the INCOMPLETE state. The resulting resource exhaustion may render the router unable to function. This vulnerability, described as "NCE Exhaustion" in this document, does not require the attacker to be on-link.

3. Lack of Address Accountability with SLAAC: 
  In Stateless Address Autoconfiguration (SLAAC), hosts generate their own IP addresses. The router does not become aware of a host's IP address until an NCE entry is created. In service provider networks, where subscriber management often relies on IP address identification, this lack of address accountability poses a challenge. Without knowledge of the host's IP address, service providers are unable to effectively manage subscribers, which is particularly problematic in public access networks. Additionally, once NCE entries are created on the router, there is no standardized method to retrieve these entries for management purposes, as highlighted in [RFC9099, Section 2.6.1.4].
"

310 2.4. Summary of ND Issue
311
312   The ND issues discussed in Sections 2.1 to 2.3 are summarized below.
313   It is worth noting that these issues originate from three causes:
314   multicast, trusting all hosts, and Router-NCE-on-Demand. If a cause
315   can be eliminated, the corresponding issues will also be eliminated.
316   This points out the directions for preventing ND issues.
317
318     . Performance issues caused by multicast
319           o I1: LLA DAD degrading performance
320           o I2: Unsolicited RA draining hosts' battery
321           o I3: GUA DAD degrading performance
322           o I4: Router address resolution for hosts degrading
323             performance
324           o I5: Host Address resolution for other hosts degrading
325             performance
326     . Reliability issues caused by multicast
327           o I6: LLA DAD not reliable for wireless networks
328           o I7: GUA DAD not reliable for wireless networks
329     . On-link security issues caused by trusting all hosts
330           o I8: Source IP address spoofing
331           o I9: DAD denial
332           o I10: Forged RAs
333           o I11: Forged Redirects
334           o I12: Replay attacks
335     . Router-NCE-on-Demand related issues
336           o I13: Router NCE exhaustion
337           o I14: Router forwarding delay
338           o I15: Lack of address accountability with SLAAC
339
340   It is worth noting that these are just potential issues. Depending
341   on the usage scenarios, they may not actually occur.
342
343   When the above issues can happen, it is advisable to be aware of the
344   mitigation solutions available for them, as described in the next
345   section.

GV> proposal for editorial rewrite:

"
The issues related to ND, as discussed in Sections 2.1 to 2.3, are summarized below. It is important to note that these issues stem from three primary causes: multicast, trusting all hosts, and Router-NCE-on-Demand. Eliminating any of these causes would also mitigate the corresponding issues. These observations provide guidance for addressing and preventing ND-related challenges.

Performance Issues Caused by Multicast
- I1: LLA DAD degrading performance.
- I2: Unsolicited RA draining host battery life.
- I3: GUA DAD degrading performance.
- I4: Router address resolution for hosts degrading performance.
- I5: Host address resolution for other hosts degrading performance.

Reliability Issues Caused by Multicast
- I6: LLA DAD is unreliable in wireless networks.
- I7: GUA DAD is unreliable in wireless networks.

On-Link Security Issues Caused by Trusting All Hosts
- I8: Source IP address spoofing.
- I9: Denial of DAD.
- I10: Forged RA.
- I11: Forged Redirect messages.
- I12: Replay attacks.

Router-NCE-on-Demand Related Issues
- I13: Router NCE exhaustion.
- I14: Router forwarding delay.
- I15: Lack of address accountability with SLAAC.

It is important to emphasize that these issues are potential vulnerabilities and may not manifest in all usage scenarios.

When these issues are relevant to a specific deployment, it is advisable to consider the mitigation techniques available, which are described in the following section.
"

356   +-----+-------------------+--------+--------+--------+------+-----+
....
420   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

GV> This table is constructed rather odd. Seems to have a blank line between each line?
This make this table hard to process. Adding a reference to the section that discusses the assertions would be helpful. Otherwise a reader of the document has to go a small treasure hunt to find the corresponding section.

443     . Assigning a unique /64 prefix to each host. Together with the
444         P2P link, this puts each host in a separate link and subnet.

GV> This was the original intent of RFC8273 (Unique IPv6 Prefix per Host)

448   Since all the three causes of ND issues are addressed, all the ND
449   issues discussed in Section 2.4 are also addressed.

GV> Which ones are these? Maybe explicit mention with I13, I14 and I15? others?

453   FBBv6 is defined in "IPv6 in the context of TR-101" [TR177]. FBBv6
454   has two flavors:

GV> FBBv6 is nowhere explained

465   The key points of FBBv6-P2MP [TR177] are:
466
467     . Implementing DAD Proxy [RFC6957]: P2MP architecture with Split
468         Horizon breaks normal ND's DAD procedure. Because all hosts are
469         in the same interface from the router's perspective, the router
470         must ensure that the hosts have different LLAs and GUAs.
471         Otherwise, the router will not be able to distinguish them.
472         However, because hosts cannot reach each other, normal DAD will
473         not function as expected. Therefore, the router must
474         participate in the hosts' DAD process and help hosts resolve
475         duplication.  With P2MP link and DAD Proxy:
476           o All host multicast to the router is effectively turned into
477             unicast, as every host can only reach the router.
478           o Trusting-all-host is only relevant to the router. By
479             applying some simple filtering at the router, e.g.
480             dropping RAs from the host, even malicious hosts cannot
481             cause security harm.
482     . Results of assigning a unique /64 prefix to each host:
483           o The router can proactively create (IP prefix, MAC address)
484             binding and use it for forwarding.  There is no Router-
485             NCE-on-Demand.
486           o Since different hosts are in different subnets, hosts will
487             send traffic to other hosts via the router. There is no
488             address resolution for other hosts.
489           o Without address resolution, router multicast to hosts
490             consists only of unsolicited RAs. Because every host is in
491             its subnet, unsolicited RAs will be sent individually to
492             each host with the "host's MAC address replacing the
493             multicast MAC address" approach specified in [RFC6085].
494             Therefore, router multicast is turned into unicast.

GV> Proposed rewrite of this text:

"
Key Points of FBBv6-P2MP [TR177]

The following summarizes the key aspects of the FBBv6-P2MP** architecture as described in [TR177]:

1. Implementation of DAD Proxy [RFC6957]: 
  In a P2MP architecture with Split Horizon, the normal ND DAD procedure is disrupted. Since all hosts appear on the same interface from the router's perspective:
  - The router must ensure that all hosts have unique LLAs and GUAs, as address duplication would prevent the router from distinguishing between hosts.
  - Due to the inability of hosts to reach each other directly, normal DAD cannot function. To address this, the router participates in the DAD process as a DAD Proxy to resolve address duplication.

  Behavior with P2MP Links and DAD Proxy:
  - Multicast traffic from all hosts to the router is effectively converted into unicast, as hosts can only communicate directly with the router.
  - The "trusting-all-hosts" model is limited to the router. By applying simple filtering (e.g., dropping RAs from hosts), the router can mitigate security risks, even from malicious hosts.

2. Assigning a Unique /64 Prefix to Each Host: 
  Assigning each host a unique /64 prefix results in several operational improvements:
  - The router can proactively create bindings of `(IP prefix, MAC address)` for forwarding purposes, eliminating the need for Router-NCE-on-Demand.
  - Since each host resides in a different subnet, traffic between hosts is routed through the router, eliminating the need for hosts to perform address resolution for one another.
  - Without address resolution, multicast from the router to hosts is limited to unsolicited RAs. As each host resides in its own subnet, these RAs are sent as unicast packets to individual hosts. This follows the approach specified in [RFC6085], where the host's MAC address replaces the multicast MAC address in the RA.

These mechanisms significantly reduce the reliance on multicast and improve the efficiency and security of the ND process in P2MP deployments.
"

769 3.15.3. ND Proxy

GV> This section makes an effort to outline what is ND proxy, however similar has been explained already earlier when discussing FBBv6-P2MP. Would be worthwhile to maybe discuss ND proxy first and refer to this explanation in the FBBv6 discussion? (=less duplicate text)

829 4.1. Learning Host Isolation from the Existing Solutions
830
831   Although the various ND solutions look unrelated, dividing them into
832   four groups helps to reveal an important point: isolating hosts can
833   help to prevent ND issues.
834
835   The first group contains MBBv6 and FBBv6. These solutions isolate
836   hosts in both L3 and L2 by putting each host in its subnet and its
837   link. This isolation method is called "L3 & L2 Isolation" or "Subnet
838   & Link Isolation". It prevents ND issues caused by multicast and
839   Trusting-all-hosts as every host is in its subnet and link. Because
840   a router can route packets to a host based on its unique prefix,
841   there is no need for Router-NCE-on-Demand, therefore ND issues
842   caused by Router-NCE-on-Demand are also prevented.
843
844   The second group contains Unique Prefix Per Host (UPPH) [RFC8273].
845   UPPH also isolates hosts into different subnets but may leave all
846   hosts in the same shared medium. This isolation method is called "L3
847   Isolation" or "Subnet Isolation". As discussed in Section 3.3, this
848   isolation method prevents ND issues caused by router multicast and
849   Router-NCE-on-Demand.
850
851   The third group contains WiND, SARP, ND Optimization for TRILL, and
852   Proxy ND in EVPN. They use a proxy device to represent the hosts
853   behind it and effectively isolate such hosts into different
854   multicast domains from other hosts. Multiple hosts are still in a
855   multicast domain and all hosts are still in the same subnet.
856   Therefore, this isolation method is called Partial L2 Isolation" or
857   "Proxy Isolation". This isolation method alleviates ND issues from
858   host multicast for address resolution.
859
860   The fourth group contains the remaining solutions. They do not
861   isolate hosts. They do not prevent any ND issues but focus on
862   solving a specific ND issue.
863
864   The above reveals that the stronger hosts are isolated, the more ND
865   issues can be prevented. This is natural because isolating hosts
866   reduces multicast scope, the number of hosts to trust, and possibly
867   the need for Router-NCE-on-Demand, the three causes of ND issues.

GV> Proposed rewrite to fix idnits and readability:

"
### 4.1. Insights on Host Isolation from Existing Solutions

While various Neighbor Discovery (ND) solutions may initially appear unrelated, categorizing them into four distinct groups highlights an important observation: "host isolation" is an effective strategy for mitigating ND-related issues.

Group 1: L3 and L2 Isolation (Subnet and Link Isolation)
This group includes MBBv6 and FBBv6, which isolate hosts at both Layer 3 (L3) and Layer 2 (L2) by placing each host within its own subnet and link. This approach, referred to as "L3 & L2 Isolation" or "Subnet & Link Isolation", prevents ND issues caused by multicast and the "trusting-all-hosts" model, as each host operates within its own isolated domain. Additionally, since routers can route packets to a host based on its unique prefix, the need for *"outer-NCE-on-Demand" is eliminated, thereby preventing ND issues arising from this mechanism.

Group 2: L3 Isolation (Subnet Isolation)
This group includes "Unique Prefix Per Host (UPPH)" [RFC8273], which isolates hosts into separate subnets while potentially leaving them on the same shared medium. This approach, termed "L3 Isolation" or "Subnet Isolation", mitigates ND issues caused by router multicast and eliminates the need for "Router-NCE-on-Demand", as detailed in Section 3.3.

Group 3: Partial L2 Isolation (Proxy Isolation)
This group encompasses solutions such as "WiND", "SARP", "ND Optimization for TRILL", and "Proxy ND in EVPN". These solutions use a proxy device to represent the hosts behind it, effectively isolating those hosts into distinct multicast domains. While hosts are still located within the same subnet, their separation into multicast domains reduces the scope of ND issues related to multicast-based address resolution. This method is referred to as "Partial L2 Isolation" or "Proxy Isolation".

Group 4: Non-Isolating Solutions 
The final group includes remaining solutions that do not implement host isolation. These solutions do not prevent ND issues but instead focus on addressing specific ND problems.

The analysis demonstrates that the stronger the isolation of hosts, the more ND issues can be mitigated. This correlation is intuitive, as isolating hosts reduces the multicast scope, minimizes the number of hosts that must be trusted, and may eliminate the need for "Router-NCE-on-Demand", the three primary causes of ND issues.
"

873 4.2.1. Applicability of L3 & L2 Isolation
874
875   The benefits are:
876
877   o  All ND issues discussed in Section 2.4 can be prevented.
878
879   The constraints or entry requirements are:
880
881   o  The hosts must be able to set up P2P links with the router.
882
883   o  Many prefixes will be needed, one per host.
884
885       o  This is unlikely to be an issue for IPv6. Today, any member
886           of a Regional Internet Registry (RIR) can get a /29
887           [RIPE738]. This contains 32 billion /64 prefixes and should
888           be sufficient for any scenario. MBBv6 assigning /64 prefixes
889           to billions of mobile UEs [RFC6459] and FBBv6 assigning /56
890           prefixes to hundreds of millions of routed RGs [TR177] are
891           evidence that this is doable.
892
893   o  Each host is easily identifiable by its unique prefix. This
894       theoretically reduces privacy. However, hosts can be identified
895       by many other methods, e.g. by using cookies. Therefore, the real
896       impact on privacy may be limited.
897
898   o  The router must support a "Subnet Isolation with P2P Link"
899       solution, e.g. MBBv6, as described in Section 3.1.
900
901   o  Many interfaces will be needed at the router, one per host.
902
903   o  All hosts will communicate through the router, and the router may
904       become a bottleneck.
905
906   o  Services relying on multicast communication among hosts, e.g.
907       mDNS, will not work.

GV> Proposed idnits rewrite:

"
Benefits
- All Neighbor Discovery (ND) issues identified in Section 2.4 can be effectively mitigated.

Constraints and Entry Requirements

1. Point-to-Point Links with the Router: 
  - Hosts must be capable of establishing point-to-point (P2P) links with the router.

2. Prefix Allocation: 
  - A large number of prefixes will be required, with one prefix assigned per host. 
  - This is generally not a limitation for IPv6. For instance, members of a Regional Internet Registry (RIR) can obtain a /29 prefix allocation [RIPE738], which provides 32 billion /64 prefixes—sufficient for any foreseeable deployment scenario. Practical implementations, such as MBBv6 assigning /64 prefixes to billions of mobile UEs [RFC6459] and FBBv6 assigning /56 prefixes to hundreds of millions of routed RGs [TR177], demonstrate the feasibility of this approach.

3. Unique Prefix Identifiability: 
  - Assigning a unique prefix to each host may theoretically reduce privacy, as hosts can be directly identified by their assigned prefix. However, alternative identification methods, such as cookies, are commonly used and may offset this privacy concern. The actual impact on privacy is therefore likely to be limited.

4. Router Support for Subnet Isolation: 
  - The router must implement a "Subnet Isolation with P2P Link" solution, such as MBBv6, as detailed in Section 3.1.

5. Increased Router Interface Requirements: 
  - A large number of interfaces will be required at the router, with one interface dedicated to each host.

6. Router as a Bottleneck: 
  - Since all communication between hosts is routed through the router, the router may become a performance bottleneck in high-traffic scenarios.

7. Incompatibility with Host-Based Multicast Services: 
  - Services that rely on multicast communication among hosts, such as mDNS, will not function under this isolation approach.
"

909 4.2.2. Applicability of L3 Isolation

911   The benefits are:
912
913   o  All ND issues discussed in Section 2.4 are prevented except "LLA
914       DAD multicast degrading performance", "LLA DAD not reliable for
915       wireless networks", and "On-link security" issues. Depending on
916       the shared medium, these remaining issues may not happen. For
917       example, if the shared medium is Ethernet, "LLA DAD multicast
918       degrading performance" and "LLA DAD not reliable for wireless
919       networks" are non-issues. If the hosts can be trusted, e.g. in a
920       private network, "On-link security" is also a non-issue.
921
922   o  There is no new requirement on the hosts. Therefore, this method
923       can be applied in many scenarios. It is practically the most
924       usable host isolation method.
925
926   The constraints are:
927
928   o  Many prefixes will be needed, one per host. However as explained
929       above, this may not be an issue for organizations that can obtain
930       sufficient IPv6 addresses from RIRs.
931
932   o  The router must support a Subnet Isolation solution, e.g.
933       [RFC8273] or [DHCP-PD].
934
935   o  All host-to-host communication with GUA will go through the
936       router, and the router may become a bottleneck.
937
938   o  Each host is identifiable by its unique prefix. This might be a
939       privacy issue as discussed previously.
940
941 4.2.3. Applicability of Partial L2 Isolation
942
943   The benefit is:
944
945   o  Reduced multicast especially for address resolution, as the
946       subnet is divided into multiple multicast domains.
947
948   The constraint is:
949
950   o  The router must support Proxy Isolation.

GV> Rewrite proposal fixing style and idnits

"
4.2.2. Applicability of L3 Isolation

Benefits
- All ND issues identified in Section 2.4 are mitigated, with the exception of:
  - "LLA DAD multicast degrading performance",
  - "LLA DAD not reliable for wireless networks", and
  - "On-link security" issues.

  These remaining issues depend on the characteristics of the shared medium:
  - If the shared medium is Ethernet, the issues related to "LLA DAD multicast" are negligible.
  - If hosts can be trusted, such as in private networks, "on-link security" concerns are not significant.

- No additional requirements are placed on hosts. Consequently, this method can be applied in a wide range of scenarios, making it one of the most practical host isolation methods.

Constraints
1. Prefix Requirements: 
  - Similar to L3 & L2 Isolation, a large number of prefixes (one per host) will be required. However, as previously discussed, organizations with access to sufficient IPv6 address allocations from Regional Internet Registries (RIRs) should not face significant challenges.

2. Router Support for Subnet Isolation: 
  - The router must implement a Subnet Isolation solution, such as those described in [RFC8273] or using DHCP Prefix Delegation ([DHCP-PD]).

3. Router as a Bottleneck: 
  - All communication between hosts using Global Unicast Addresses (GUA) will be routed through the router, which may introduce a performance bottleneck under high traffic loads.

4. Privacy Considerations: 
  - Each host is identifiable by its unique prefix, potentially impacting privacy as discussed earlier.

4.2.3. Applicability of Partial L2 Isolation

Benefit 
- Reduced Multicast Traffic: 
  - This method reduces multicast traffic, particularly for address resolution, by dividing the subnet into multiple multicast domains.

Constraint
- Router Support for Proxy Isolation: 
  - The router must implement Proxy Isolation to support this method effectively.
"

952 4.2.4. A Simple Guideline
953
954   Given the applicability analysis above, network administrators can
955   decide whether to apply any isolation method.
956
957   A simple guideline is to consider the isolation methods one by one
958   in the order listed in the previous sections, that is, from the
959   strongest isolation to the weakest. With stronger isolation, more ND
960   issues can be prevented but the entry requirements will also be
961   higher. All things considered, L3 Isolation can be a good tradeoff
962   because the benefits are clear while the entry requirements are
963   manageable.
964
965   It is worth noting that, if a network administrator picks an
966   isolation method that is too strong or too weak, there is no serious
967   consequence. Picking an isolation method that is too strong means
968   that the network administrator needs to meet more entry requirements
969   upfront, while picking an isolation method that is too weak means
970   that the network administrator may need to deploy more ND mitigation
971   solutions to deal with ND issues. Either way, the resulting solution
972   can still work.

GV> Proposed idnits and style rewrite

"
4.2.4. Guidelines for Applying Isolation Methods

Based on the applicability analysis provided in the preceding sections, network administrators can determine whether to implement an isolation method and, if so, which method is most appropriate for their specific deployment.

Recommended Approach
- Consider the isolation methods in the order listed in the preceding sections, progressing from the strongest isolation to the weakest.
  - Stronger isolation methods can prevent more ND issues but may also impose higher entry requirements.
  - Weaker isolation methods have fewer entry requirements but may leave some ND issues unmitigated.

- "L3 Isolation" is often a practical tradeoff:
  - It provides significant benefits by addressing most ND issues.
  - Its entry requirements, such as prefix allocation and router support for Subnet Isolation, are generally manageable.

Flexibility in Selection
It is important to note that selecting an isolation method that is either too strong or too weak does not result in catastrophic consequences:
- Choosing an "overly strong isolation method" may require the network administrator to meet higher entry requirements initially, such as additional prefixes or specific router capabilities.
- Choosing a "weaker isolation method" may necessitate deploying supplemental ND mitigation techniques to address any unresolved ND issues.

In either case, the resulting solution can be functional and effective, providing flexibility for administrators to tailor their approach to their network's specific needs.
"

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-v6ops-nd-considerations-08

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-v6ops-nd-considerations-08.txt

# idnits complains about unused references

# Thank you for this document. It contains plenty of information usefull for deploying IPv6 and help guide operators through the number of available NDP based drafts and solutions.

# I found the draft diffucult to process while reviewing. I am sitting between balot a blocking DISCUSS or to let the document slip. I decided to let the document slip. Reason i did not ballot DISCUSS is because the text is not wrong from technical perspective, but the writing does need from my perspective to be improved. To help get started with this exercise i provided at various places a idnits and style rewrite proposal. 


#DETAILED COMMENTS
#=================

115   Neighbor Discovery [ND] is specified in RFC 4861. It defines how
116   hosts and routers on the link interact with each other. ND contains
117   eight main procedures:

GV> Looking at RFC4861 there are 9 problems that ND solves.
https://www.rfc-editor.org/rfc/rfc4861.html#section-3
Is there a reason why the text from RFC4861 can be represented in this draft instead of paraphasing and potentially wrongly representing intent?

127     3. Host's Global Unicast Address (GUA) DAD: hosts form GUA and use
128         multicast NSs for DAD.

GV> Is this including the ULA addresses? https://datatracker.ietf.org/doc/rfc4193/

149     . ND Trust Models and Threats [RFC3756],
150     . Secure ND [SeND],
151     . Cryptographically Generated Addresses [CGA],
152     . ND Proxy [RFC4389],
153     . Optimistic ND [RFC4429],
154     . ND for mobile broadband [RFC6459][RFC7066],
155     . ND for fixed broadband [TR177],
156     . ND Mediation [RFC6575],
157     . Operational ND Problems [RFC6583],
158     . Wireless ND (WiND) [RFC6775][RFC8505][RFC8928][RFC8929][SND],
159     . DAD Proxy [RFC6957],
160     . Source Address Validation Improvement [SAVI],
161     . Router Advertisement Guard [RA-Guard][RA-Guard+],
162     . Enhanced Duplicate Address Detection [RFC7527],
163     . Scalable ARP [RFC7586],
164     . Reducing Router Advertisements [RFC7772],
165     . Unique Prefix Per Host [RFC8273],
166     . ND Optimization for TRILL [RFC8302],
167     . Gratuitous Neighbor Discovery [GRAND],
168     . Proxy ARP/ND for EVPN [RFC9161].

GV> [editorial] What is the reason some references use RFC indication and others use an named reference?

178 1.1. Terminology

GV> Would it be possible to add a reference that some ND terminology is used from RFC4861 section 2 (e.g. node, router, link, on-link, etc) https://www.rfc-editor.org/rfc/rfc4861.html#section-2 . observe that some terminology abreviations like NS, NA, RS, NCE is not specified in that section. potentially add them in this section or point to a RFC where these are speciefied to the intent of this document other abbreviations are not mentioned (e.g. MBBv6, 3GPP, FBBv6, LLNs, VPWS, TRILL, SARP )

283     . The packet has to be buffered before the router finds out the
284         MAC address of the host. This delays forwarding, and depending
285         on the router's buffer size, may also cause packet loss. This
286         is called "Router-NCE-on-Demand Forwarding Delay" in this
287         document.
288     . The way ND performs address resolution is the source node will
289         create an NCE entry first and set its state to INCOMPLETE, then
290         the node will multicast NSs to all the nodes and wait for the
291         destination node to reply with its MAC address. This creates a
292         security vulnerability. If an attacker sends a large number of
293         packets destined to non-existing IP addresses, the router will
294         create a large number of NCEs in INCOMPLETE state while trying
295         to resolve the MAC addresses. The router may run out of
296         resources and stop functioning. This is called "NCE Exhaustion"
297         in this document. Note that in this case, the attacker can be
298         off-link.
299     . With SLAAC, a host forms its own IP address. A router does not
300         know the host's IP address until an NCE entry is installed. In
301         a service provider network, subscribers are typically managed
302         by their IP addresses. Consequently, if the router does not
303         know a host's IP address, the service provider cannot manage
304         the subscriber. In other words, there is a lack of address
305         accountability. This is an issue for public access networks. In
306         addition, after the NCE entries are installed on the router,
307         there is no clearly defined method to retrieve them for
308         management purpose [RFC9099, Section 2.6.1.4].

GV> Proposal for a slight editorial rewrite:

"
1. Router-NCE-on-Demand Forwarding Delay: 
  When a packet arrives, the router must buffer it while attempting to determine the host's MAC address. This buffering delays forwarding and, depending on the router's buffer size, may lead to packet loss. This delay is referred to as "Router-NCE-on-Demand Forwarding Delay" in this document.

2. NCE Exhaustion Vulnerability: 
  Neighbor Discovery (ND) resolves addresses by creating a Neighbor Cache Entry (NCE) in the INCOMPLETE state and multicasting Neighbor Solicitations (NS) to discover the destination MAC address. This mechanism introduces a security vulnerability: an attacker can send a high volume of packets targeting non-existent IP addresses, causing the router to create numerous NCEs in the INCOMPLETE state. The resulting resource exhaustion may render the router unable to function. This vulnerability, described as "NCE Exhaustion" in this document, does not require the attacker to be on-link.

3. Lack of Address Accountability with SLAAC: 
  In Stateless Address Autoconfiguration (SLAAC), hosts generate their own IP addresses. The router does not become aware of a host's IP address until an NCE entry is created. In service provider networks, where subscriber management often relies on IP address identification, this lack of address accountability poses a challenge. Without knowledge of the host's IP address, service providers are unable to effectively manage subscribers, which is particularly problematic in public access networks. Additionally, once NCE entries are created on the router, there is no standardized method to retrieve these entries for management purposes, as highlighted in [RFC9099, Section 2.6.1.4].
"

310 2.4. Summary of ND Issue
311
312   The ND issues discussed in Sections 2.1 to 2.3 are summarized below.
313   It is worth noting that these issues originate from three causes:
314   multicast, trusting all hosts, and Router-NCE-on-Demand. If a cause
315   can be eliminated, the corresponding issues will also be eliminated.
316   This points out the directions for preventing ND issues.
317
318     . Performance issues caused by multicast
319           o I1: LLA DAD degrading performance
320           o I2: Unsolicited RA draining hosts' battery
321           o I3: GUA DAD degrading performance
322           o I4: Router address resolution for hosts degrading
323             performance
324           o I5: Host Address resolution for other hosts degrading
325             performance
326     . Reliability issues caused by multicast
327           o I6: LLA DAD not reliable for wireless networks
328           o I7: GUA DAD not reliable for wireless networks
329     . On-link security issues caused by trusting all hosts
330           o I8: Source IP address spoofing
331           o I9: DAD denial
332           o I10: Forged RAs
333           o I11: Forged Redirects
334           o I12: Replay attacks
335     . Router-NCE-on-Demand related issues
336           o I13: Router NCE exhaustion
337           o I14: Router forwarding delay
338           o I15: Lack of address accountability with SLAAC
339
340   It is worth noting that these are just potential issues. Depending
341   on the usage scenarios, they may not actually occur.
342
343   When the above issues can happen, it is advisable to be aware of the
344   mitigation solutions available for them, as described in the next
345   section.

GV> proposal for editorial rewrite:

"
The issues related to ND, as discussed in Sections 2.1 to 2.3, are summarized below. It is important to note that these issues stem from three primary causes: multicast, trusting all hosts, and Router-NCE-on-Demand. Eliminating any of these causes would also mitigate the corresponding issues. These observations provide guidance for addressing and preventing ND-related challenges.

Performance Issues Caused by Multicast
- I1: LLA DAD degrading performance.
- I2: Unsolicited RA draining host battery life.
- I3: GUA DAD degrading performance.
- I4: Router address resolution for hosts degrading performance.
- I5: Host address resolution for other hosts degrading performance.

Reliability Issues Caused by Multicast
- I6: LLA DAD is unreliable in wireless networks.
- I7: GUA DAD is unreliable in wireless networks.

On-Link Security Issues Caused by Trusting All Hosts
- I8: Source IP address spoofing.
- I9: Denial of DAD.
- I10: Forged RA.
- I11: Forged Redirect messages.
- I12: Replay attacks.

Router-NCE-on-Demand Related Issues
- I13: Router NCE exhaustion.
- I14: Router forwarding delay.
- I15: Lack of address accountability with SLAAC.

It is important to emphasize that these issues are potential vulnerabilities and may not manifest in all usage scenarios.

When these issues are relevant to a specific deployment, it is advisable to consider the mitigation techniques available, which are described in the following section.
"

356   +-----+-------------------+--------+--------+--------+------+-----+
....
420   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

GV> This table is constructed rather odd. Seems to have a blank line between each line?
This make this table hard to process. Adding a reference to the section that discusses the assertions would be helpfull. Otherwise a reader of the document has to go a small treasure hunt to find the corresponding section.

443     . Assigning a unique /64 prefix to each host. Together with the
444         P2P link, this puts each host in a separate link and subnet.

GV> This was the original intent of RFC8273 (Unique IPv6 Prefix per Host)

448   Since all the three causes of ND issues are addressed, all the ND
449   issues discussed in Section 2.4 are also addressed.

GV> Which ones are these? Maybe axplicit  mention with I13, I14 and I15? or are thers intended?

453   FBBv6 is defined in "IPv6 in the context of TR-101" [TR177]. FBBv6
454   has two flavors:

GV> FBBv6 is nowhere explained

465   The key points of FBBv6-P2MP [TR177] are:
466
467     . Implementing DAD Proxy [RFC6957]: P2MP architecture with Split
468         Horizon breaks normal ND's DAD procedure. Because all hosts are
469         in the same interface from the router's perspective, the router
470         must ensure that the hosts have different LLAs and GUAs.
471         Otherwise, the router will not be able to distinguish them.
472         However, because hosts cannot reach each other, normal DAD will
473         not function as expected. Therefore, the router must
474         participate in the hosts' DAD process and help hosts resolve
475         duplication.  With P2MP link and DAD Proxy:
476           o All host multicast to the router is effectively turned into
477             unicast, as every host can only reach the router.
478           o Trusting-all-host is only relevant to the router. By
479             applying some simple filtering at the router, e.g.
480             dropping RAs from the host, even malicious hosts cannot
481             cause security harm.
482     . Results of assigning a unique /64 prefix to each host:
483           o The router can proactively create (IP prefix, MAC address)
484             binding and use it for forwarding.  There is no Router-
485             NCE-on-Demand.
486           o Since different hosts are in different subnets, hosts will
487             send traffic to other hosts via the router. There is no
488             address resolution for other hosts.
489           o Without address resolution, router multicast to hosts
490             consists only of unsolicited RAs. Because every host is in
491             its subnet, unsolicited RAs will be sent individually to
492             each host with the "host's MAC address replacing the
493             multicast MAC address" approach specified in [RFC6085].
494             Therefore, router multicast is turned into unicast.

GV> Proposed rewrite of this text:

"
Key Points of FBBv6-P2MP [TR177]

The following summarizes the key aspects of the FBBv6-P2MP** architecture as described in [TR177]:

1. Implementation of DAD Proxy [RFC6957]: 
  In a P2MP architecture with Split Horizon, the normal ND DAD procedure is disrupted. Since all hosts appear on the same interface from the router's perspective:
  - The router must ensure that all hosts have unique LLAs and GUAs, as address duplication would prevent the router from distinguishing between hosts.
  - Due to the inability of hosts to reach each other directly, normal DAD cannot function. To address this, the router participates in the DAD process as a DAD Proxy to resolve address duplication.

  Behavior with P2MP Links and DAD Proxy:
  - Multicast traffic from all hosts to the router is effectively converted into unicast, as hosts can only communicate directly with the router.
  - The "trusting-all-hosts" model is limited to the router. By applying simple filtering (e.g., dropping RAs from hosts), the router can mitigate security risks, even from malicious hosts.

2. Assigning a Unique /64 Prefix to Each Host: 
  Assigning each host a unique /64 prefix results in several operational improvements:
  - The router can proactively create bindings of `(IP prefix, MAC address)` for forwarding purposes, eliminating the need for Router-NCE-on-Demand.
  - Since each host resides in a different subnet, traffic between hosts is routed through the router, eliminating the need for hosts to perform address resolution for one another.
  - Without address resolution, multicast from the router to hosts is limited to unsolicited RAs. As each host resides in its own subnet, these RAs are sent as unicast packets to individual hosts. This follows the approach specified in [RFC6085], where the host's MAC address replaces the multicast MAC address in the RA.

These mechanisms significantly reduce the reliance on multicast and improve the efficiency and security of the ND process in P2MP deployments.
"

769 3.15.3. ND Proxy

GV> This section makes an effort to outline what is ND proxy, however similar has been explained already earlier when discussing FBBv6-P2MP. Would be worthwile to maybe discuss ND proxy first and refere to this explanbation in the FBBv6 discussion? (=less duplicate text)

829 4.1. Learning Host Isolation from the Existing Solutions
830
831   Although the various ND solutions look unrelated, dividing them into
832   four groups helps to reveal an important point: isolating hosts can
833   help to prevent ND issues.
834
835   The first group contains MBBv6 and FBBv6. These solutions isolate
836   hosts in both L3 and L2 by putting each host in its subnet and its
837   link. This isolation method is called "L3 & L2 Isolation" or "Subnet
838   & Link Isolation". It prevents ND issues caused by multicast and
839   Trusting-all-hosts as every host is in its subnet and link. Because
840   a router can route packets to a host based on its unique prefix,
841   there is no need for Router-NCE-on-Demand, therefore ND issues
842   caused by Router-NCE-on-Demand are also prevented.
843
844   The second group contains Unique Prefix Per Host (UPPH) [RFC8273].
845   UPPH also isolates hosts into different subnets but may leave all
846   hosts in the same shared medium. This isolation method is called "L3
847   Isolation" or "Subnet Isolation". As discussed in Section 3.3, this
848   isolation method prevents ND issues caused by router multicast and
849   Router-NCE-on-Demand.
850
851   The third group contains WiND, SARP, ND Optimization for TRILL, and
852   Proxy ND in EVPN. They use a proxy device to represent the hosts
853   behind it and effectively isolate such hosts into different
854   multicast domains from other hosts. Multiple hosts are still in a
855   multicast domain and all hosts are still in the same subnet.
856   Therefore, this isolation method is called Partial L2 Isolation" or
857   "Proxy Isolation". This isolation method alleviates ND issues from
858   host multicast for address resolution.
859
860   The fourth group contains the remaining solutions. They do not
861   isolate hosts. They do not prevent any ND issues but focus on
862   solving a specific ND issue.
863
864   The above reveals that the stronger hosts are isolated, the more ND
865   issues can be prevented. This is natural because isolating hosts
866   reduces multicast scope, the number of hosts to trust, and possibly
867   the need for Router-NCE-on-Demand, the three causes of ND issues.

GV> Proposed rewrite to fix idnits and readability:

"
### 4.1. Insights on Host Isolation from Existing Solutions

While various Neighbor Discovery (ND) solutions may initially appear unrelated, categorizing them into four distinct groups highlights an important observation: "host isolation" is an effective strategy for mitigating ND-related issues.

Group 1: L3 and L2 Isolation (Subnet and Link Isolation)
This group includes MBBv6 and FBBv6, which isolate hosts at both Layer 3 (L3) and Layer 2 (L2) by placing each host within its own subnet and link. This approach, referred to as "L3 & L2 Isolation" or "Subnet & Link Isolation", prevents ND issues caused by multicast and the "trusting-all-hosts" model, as each host operates within its own isolated domain. Additionally, since routers can route packets to a host based on its unique prefix, the need for *"outer-NCE-on-Demand" is eliminated, thereby preventing ND issues arising from this mechanism.

Group 2: L3 Isolation (Subnet Isolation)
This group includes "Unique Prefix Per Host (UPPH)" [RFC8273], which isolates hosts into separate subnets while potentially leaving them on the same shared medium. This approach, termed "L3 Isolation" or "Subnet Isolation", mitigates ND issues caused by router multicast and eliminates the need for "Router-NCE-on-Demand", as detailed in Section 3.3.

Group 3: Partial L2 Isolation (Proxy Isolation)
This group encompasses solutions such as "WiND", "SARP", "ND Optimization for TRILL", and "Proxy ND in EVPN". These solutions use a proxy device to represent the hosts behind it, effectively isolating those hosts into distinct multicast domains. While hosts are still located within the same subnet, their separation into multicast domains reduces the scope of ND issues related to multicast-based address resolution. This method is referred to as "Partial L2 Isolation" or "Proxy Isolation".

Group 4: Non-Isolating Solutions 
The final group includes remaining solutions that do not implement host isolation. These solutions do not prevent ND issues but instead focus on addressing specific ND problems.

The analysis demonstrates that the stronger the isolation of hosts, the more ND issues can be mitigated. This correlation is intuitive, as isolating hosts reduces the multicast scope, minimizes the number of hosts that must be trusted, and may eliminate the need for "Router-NCE-on-Demand", the three primary causes of ND issues.
"

873 4.2.1. Applicability of L3 & L2 Isolation
874
875   The benefits are:
876
877   o  All ND issues discussed in Section 2.4 can be prevented.
878
879   The constraints or entry requirements are:
880
881   o  The hosts must be able to set up P2P links with the router.
882
883   o  Many prefixes will be needed, one per host.
884
885       o  This is unlikely to be an issue for IPv6. Today, any member
886           of a Regional Internet Registry (RIR) can get a /29
887           [RIPE738]. This contains 32 billion /64 prefixes and should
888           be sufficient for any scenario. MBBv6 assigning /64 prefixes
889           to billions of mobile UEs [RFC6459] and FBBv6 assigning /56
890           prefixes to hundreds of millions of routed RGs [TR177] are
891           evidence that this is doable.
892
893   o  Each host is easily identifiable by its unique prefix. This
894       theoretically reduces privacy. However, hosts can be identified
895       by many other methods, e.g. by using cookies. Therefore, the real
896       impact on privacy may be limited.
897
898   o  The router must support a "Subnet Isolation with P2P Link"
899       solution, e.g. MBBv6, as described in Section 3.1.
900
901   o  Many interfaces will be needed at the router, one per host.
902
903   o  All hosts will communicate through the router, and the router may
904       become a bottleneck.
905
906   o  Services relying on multicast communication among hosts, e.g.
907       mDNS, will not work.

GV> Proposed idnits rewrite:

"
Benefits
- All Neighbor Discovery (ND) issues identified in Section 2.4 can be effectively mitigated.

Constraints and Entry Requirements

1. Point-to-Point Links with the Router: 
  - Hosts must be capable of establishing point-to-point (P2P) links with the router.

2. Prefix Allocation: 
  - A large number of prefixes will be required, with one prefix assigned per host. 
  - This is generally not a limitation for IPv6. For instance, members of a Regional Internet Registry (RIR) can obtain a /29 prefix allocation [RIPE738], which provides 32 billion /64 prefixes—sufficient for any foreseeable deployment scenario. Practical implementations, such as MBBv6 assigning /64 prefixes to billions of mobile UEs [RFC6459] and FBBv6 assigning /56 prefixes to hundreds of millions of routed RGs [TR177], demonstrate the feasibility of this approach.

3. Unique Prefix Identifiability: 
  - Assigning a unique prefix to each host may theoretically reduce privacy, as hosts can be directly identified by their assigned prefix. However, alternative identification methods, such as cookies, are commonly used and may offset this privacy concern. The actual impact on privacy is therefore likely to be limited.

4. Router Support for Subnet Isolation: 
  - The router must implement a "Subnet Isolation with P2P Link" solution, such as MBBv6, as detailed in Section 3.1.

5. Increased Router Interface Requirements: 
  - A large number of interfaces will be required at the router, with one interface dedicated to each host.

6. Router as a Bottleneck: 
  - Since all communication between hosts is routed through the router, the router may become a performance bottleneck in high-traffic scenarios.

7. Incompatibility with Host-Based Multicast Services: 
  - Services that rely on multicast communication among hosts, such as mDNS, will not function under this isolation approach.
"

909 4.2.2. Applicability of L3 Isolation

911   The benefits are:
912
913   o  All ND issues discussed in Section 2.4 are prevented except "LLA
914       DAD multicast degrading performance", "LLA DAD not reliable for
915       wireless networks", and "On-link security" issues. Depending on
916       the shared medium, these remaining issues may not happen. For
917       example, if the shared medium is Ethernet, "LLA DAD multicast
918       degrading performance" and "LLA DAD not reliable for wireless
919       networks" are non-issues. If the hosts can be trusted, e.g. in a
920       private network, "On-link security" is also a non-issue.
921
922   o  There is no new requirement on the hosts. Therefore, this method
923       can be applied in many scenarios. It is practically the most
924       usable host isolation method.
925
926   The constraints are:
927
928   o  Many prefixes will be needed, one per host. However as explained
929       above, this may not be an issue for organizations that can obtain
930       sufficient IPv6 addresses from RIRs.
931
932   o  The router must support a Subnet Isolation solution, e.g.
933       [RFC8273] or [DHCP-PD].
934
935   o  All host-to-host communication with GUA will go through the
936       router, and the router may become a bottleneck.
937
938   o  Each host is identifiable by its unique prefix. This might be a
939       privacy issue as discussed previously.
940
941 4.2.3. Applicability of Partial L2 Isolation
942
943   The benefit is:
944
945   o  Reduced multicast especially for address resolution, as the
946       subnet is divided into multiple multicast domains.
947
948   The constraint is:
949
950   o  The router must support Proxy Isolation.

GV> Rewrite proposal fixing style and idnits

"
4.2.2. Applicability of L3 Isolation

Benefits
- All ND issues identified in Section 2.4 are mitigated, with the exception of:
  - "LLA DAD multicast degrading performance",
  - "LLA DAD not reliable for wireless networks", and
  - "On-link security" issues.

  These remaining issues depend on the characteristics of the shared medium:
  - If the shared medium is Ethernet, the issues related to "LLA DAD multicast" are negligible.
  - If hosts can be trusted, such as in private networks, "on-link security" concerns are not significant.

- No additional requirements are placed on hosts. Consequently, this method can be applied in a wide range of scenarios, making it one of the most practical host isolation methods.

Constraints
1. Prefix Requirements: 
  - Similar to L3 & L2 Isolation, a large number of prefixes (one per host) will be required. However, as previously discussed, organizations with access to sufficient IPv6 address allocations from Regional Internet Registries (RIRs) should not face significant challenges.

2. Router Support for Subnet Isolation: 
  - The router must implement a Subnet Isolation solution, such as those described in [RFC8273] or using DHCP Prefix Delegation ([DHCP-PD]).

3. Router as a Bottleneck: 
  - All communication between hosts using Global Unicast Addresses (GUA) will be routed through the router, which may introduce a performance bottleneck under high traffic loads.

4. Privacy Considerations: 
  - Each host is identifiable by its unique prefix, potentially impacting privacy as discussed earlier.

4.2.3. Applicability of Partial L2 Isolation

Benefit 
- Reduced Multicast Traffic: 
  - This method reduces multicast traffic, particularly for address resolution, by dividing the subnet into multiple multicast domains.

Constraint
- Router Support for Proxy Isolation: 
  - The router must implement Proxy Isolation to support this method effectively.
"

952 4.2.4. A Simple Guideline
953
954   Given the applicability analysis above, network administrators can
955   decide whether to apply any isolation method.
956
957   A simple guideline is to consider the isolation methods one by one
958   in the order listed in the previous sections, that is, from the
959   strongest isolation to the weakest. With stronger isolation, more ND
960   issues can be prevented but the entry requirements will also be
961   higher. All things considered, L3 Isolation can be a good tradeoff
962   because the benefits are clear while the entry requirements are
963   manageable.
964
965   It is worth noting that, if a network administrator picks an
966   isolation method that is too strong or too weak, there is no serious
967   consequence. Picking an isolation method that is too strong means
968   that the network administrator needs to meet more entry requirements
969   upfront, while picking an isolation method that is too weak means
970   that the network administrator may need to deploy more ND mitigation
971   solutions to deal with ND issues. Either way, the resulting solution
972   can still work.

GV> Proposed idnits and style rewrite

"
4.2.4. Guidelines for Applying Isolation Methods

Based on the applicability analysis provided in the preceding sections, network administrators can determine whether to implement an isolation method and, if so, which method is most appropriate for their specific deployment.

Recommended Approach
- Consider the isolation methods in the order listed in the preceding sections, progressing from the strongest isolation to the weakest.
  - Stronger isolation methods can prevent more ND issues but may also impose higher entry requirements.
  - Weaker isolation methods have fewer entry requirements but may leave some ND issues unmitigated.

- "L3 Isolation" is often a practical tradeoff:
  - It provides significant benefits by addressing most ND issues.
  - Its entry requirements, such as prefix allocation and router support for Subnet Isolation, are generally manageable.

Flexibility in Selection
It is important to note that selecting an isolation method that is either too strong or too weak does not result in catastrophic consequences:
- Choosing an "overly strong isolation method" may require the network administrator to meet higher entry requirements initially, such as additional prefixes or specific router capabilities.
- Choosing a "weaker isolation method" may necessitate deploying supplemental ND mitigation techniques to address any unresolved ND issues.

In either case, the resulting solution can be functional and effective, providing flexibility for administrators to tailor their approach to their network's specific needs.
"

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-v6ops-nd-considerations-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-10-18):

From: The IESG
To: IETF-Announce
CC: draft-ietf-v6ops-nd-considerations@ietf.org, tim@qacafe.com, v6ops-chairs@ietf.org, v6ops@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Neighbor Discovery Considerations in IPv6 Deployments) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document: - 'Neighbor Discovery Considerations in IPv6
Deployments'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-10-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Neighbor Discovery (ND) is a critical part of IPv6. ND uses
  multicast extensively and trusts all hosts. In some scenarios, such
  as wireless networks, multicast can be inefficient. In other
  scenarios, such as public access networks, hosts may not be
  trustworthy. Consequently, ND can have issues in some scenarios. The
  issues and mitigation solutions are documented in more than 20 RFCs,
  making it challenging to track all these issues and solutions.
  Therefore, an overview document is helpful.

  This document first summarizes the published ND issues and the
  solutions. This provides a one-stop reference. This document then
  analyzes these mitigation solutions to reveal that isolating hosts
  into different subnets or links can help prevent ND issues. Three
  isolation methods and their applicability are described. A simple
  guideline is provided for selecting a suitable isolation method to
  prevent potential ND issues.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-considerations/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document seemed to represent a consensus of the working group, during the lifecycle
it received comments and was revised accordingly.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There is little controversy with the document with good discussion between working group
members.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

There seems to be no extreme discontent so I would not expect an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A.  This is a document for IPv6 Neighbor Discovery and known limitations and
optimized solutions.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document covers IPv6 Neighbor Discovery which is a document from the 6MAN
working group.  Many documents overlap in IPv6 knowledge between the members of
these working groups.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There were no additional required reviews.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  As document shepherd, I reviewed this document to assure that it is following
  the WG consensus and discussions and is of good quality. In my opinion, the
  document is ready for publication.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

This mets all the requirements of ops area reviews.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The RFC requested is Informational. And, this is appropriate for this
document as it describes the limitations of Neighbor Discovery.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

I reached out to authors about IPR and they responded they aren’t aware of any.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, all the authors have expressed interest in being listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

I was not able to find any additional nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All the references seemed to be valid and correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are publicly available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Yes, every reference that I located had a valid reference.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No, this document is stand alone.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document requires no action from IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document seemed to represent a consensus of the working group, during the lifecycle
it received comments and was revised accordingly.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There is little controversy with the document with good discussion between working group
members.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

There seems to be no extreme discontent so I would not expect an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A.  This is a document for IPv6 Neighbor Discovery and known limitations and
optimized solutions.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document covers IPv6 Neighbor Discovery which is a document from the 6MAN
working group.  Many documents overlap in IPv6 knowledge between the members of
these working groups.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There were no additional required reviews.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  As document shepherd, I reviewed this document to assure that it is following
  the WG consensus and discussions and is of good quality. In my opinion, the
  document is ready for publication.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

This mets all the requirements of ops area reviews.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The RFC requested is Informational. And, this is appropriate for this
document as it describes the limitations of Neighbor Discovery.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

I reached out to authors about IPR and they responded they aren’t aware of any.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, all the authors have expressed interest in being listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

I was not able to find any additional nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All the references seemed to be valid and correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are publicly available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Yes, every reference that I located had a valid reference.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No, this document is stand alone.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document requires no action from IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document seemed to represent a consensus of the working group, during the lifecycle
it received comments and was revised accordingly.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There is little controversy with the document with good discussion between working group
members.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

There seems to be no extreme discontent so I would not expect an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A.  This is a document for IPv6 Neighbor Discovery and known limitations and
optimized solutions.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document covers IPv6 Neighbor Discovery which is a document from the 6MAN
working group.  Many documents overlap in IPv6 knowledge between the members of
these working groups.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There were no additional required reviews.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  As document shepherd, I reviewed this document to assure that it is following
  the WG consensus and discussions and is of good quality. In my opinion, the
  document is ready for publication.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

This mets all the requirements of ops area reviews.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The RFC requested is Informational. And, this is appropriate for this
document as it describes the limitations of Neighbor Discovery.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

I reached out to authors about IPR and they responded they aren’t aware of any.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, all the authors have expressed interest in being listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

I was not able to find any additional nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All the references seemed to be valid and correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are publicly available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Yes, every reference that I located had a valid reference.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No, this document is stand alone.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document requires no action from IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/