Ballot for draft-ietf-v6ops-nd-considerations
Discuss
Yes
No Objection
Abstain
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
# 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).
# 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.<foo> 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 :-)
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)
# 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. "
# É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 ",".