idnits 2.17.1 draft-xiao-v6ops-nd-deployment-guidelines-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 16, 2022) is 800 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1884 (Obsoleted by RFC 2373) -- Duplicate reference: RFC8273, mentioned in 'RFC8273', was also mentioned in '8273D'. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Operations (v6ops) Working Group X. Xiao 2 Internet Draft Huawei Technologies 3 Intended status: Informational E. Metz 4 Expires: Aug. 2022 KPN 5 G. Mishra 6 Verizon Inc. 7 February 16, 2022 9 Neighbor Discovery Protocol Deployment Guidelines 10 draft-xiao-v6ops-nd-deployment-guidelines-01 12 Abstract 14 Neighbor Discovery (ND) is an integral part of IPv6 first-hop. Due 15 to limitation of certain L2 media's support to ND, a number of 16 issues can happen in certain scenarios. Solutions for these issues 17 have been designed. These issues and solutions are summarized in 18 RFC3756, RFC6583, RFC9099. However, there is no guideline on how to 19 prevent the issues or how to select the proper solutions. 21 This document analyzes the existing solutions and summarizes their 22 wisdoms into an insight: isolating hosts into different L2 links or 23 different L3 subnets can be effective in preventing ND issues. In 24 deployment scenarios where the ND issues can occur, this prevention 25 approach can be more effective than deploying the corresponding 26 solutions to solve the issues. Based on this insight, a set of 27 guidelines is proposed for future ND deployments. These guidelines 28 describe where to isolate hosts in L2 or in subnet to prevent ND 29 issues, and how to select suitable solutions for the remaining 30 issues. This will likely simplify ND deployment. The impact of such 31 isolation to other components of IPv6 first-hop is also analyzed. 32 The impact appears small. Therefore, the guidelines will likely 33 simplify the overall IPv6 first-hop deployment. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other documents 47 at any time. It is inappropriate to use Internet-Drafts as 48 reference material or to cite them other than as "work in progress." 50 This Internet-Draft will expire on August 2022. 52 Copyright Notice 54 Copyright (c) 2022 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. Code Components extracted from this 63 document must include Simplified BSD License text as described in 64 Section 4.e of the Trust Legal Provisions and are provided without 65 warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction...................................................2 70 1.1. Terminology...............................................3 71 2. Summary of ND Issues and Existing Solutions....................4 72 2.1. Multicast Issues and Solutions............................4 73 2.2. DAD-unreliable Issues and Solutions.......................6 74 2.3. On-demand NCE Installation Issues and Solutions...........6 75 2.4. Security Issues and Solutions.............................7 76 2.5. Observations on the Solutions and an Insight Learned......9 77 3. Isolating Hosts in L2 and in Subnet to Simplify ND Deployment.11 78 3.1. Applicability of L2 Isolation and Subnet Isolation.......11 79 3.2. Deployment Guidelines....................................14 80 4. Impact of L2 Isolation and Subnet Isolation to Other Components 81 of IPv6 First-hop................................................16 82 5. Applying the Guidelines to Real World Scenarios...............18 83 6. Security Considerations.......................................19 84 7. IANA Considerations...........................................19 85 8. References....................................................19 86 8.1. Informative References...................................19 87 9. Acknowledgments...............................................22 89 1. Introduction 91 ND is an integral part of IPv6 first-hop. Due to limitation of 92 certain L2 media's support to the protocol, a number of issues have 93 been discovered, and the corresponding solutions have been designed. 94 These issues and solutions are dispersed in more than 20 RFCs. 95 [RFC6583] summarized the issues and solutions up to 2012. [RFC9099] 96 summarized known IPv6 security issues, including ND issues, up to 97 2021. Wireless ND (WiND) [RFC6775][RFC8505][RFC8928][RFC8929] 98 discussed ND issues and solutions in Low-Power and Lossy Networks 99 (LLNs) [RFC7102]. However, two ND deployment problems still exist: 101 1. None of [RFC6583], [RFC9099] and WiND provides guidelines on 102 how to prevent the issues; 103 2. Some issues have multiple solutions. There is no guideline on 104 how to select the suitable solutions depending on the 105 deployment scenarios. 107 [RFC8273] recommends using "Unique IPv6 Prefix per Host" as a best 108 practice for ND. By doing so, certain ND issues can be prevented. 109 So, it partially solved Problem 1 above. But [RFC8273] cannot be 110 used everywhere. In fact, some concerns about [RFC8273] have been 111 expressed in [8273D]. 113 This document aims to solve both problems by providing deployment 114 guidelines for ND. Depending on the usage scenarios, the guidelines 115 firstly try to prevent the issues as much as possible, then 116 recommend suitable solutions for the remaining issues. This can 117 result in the simplest ND deployment. 119 1.1. Terminology 121 Familiarity with [ND] and [SLAAC] are prerequisite to understand 122 this document. Familiarity with the ND issues and solutions 123 discussed in [RFC6583] and [RFC9099] Section 2.3 are also essential 124 to understand this document. 126 Some frequently used terms are defined in this section. 128 L2 isolation for hosts - One host per link. Consequently, A host 129 cannot send packets via the L2 medium to any other hosts. 130 Router will be the only node reachable in L2. This can be 131 realized on P2P media, or on multi-access media with Private 132 VLAN [PVLAN] or Split Horizon [TR177] or wireless isolation 133 [W-Iso] to prevent hosts from communicating with each other 134 in L2. 136 Subnet isolation for hosts - One host per subnet. This can be done 137 by assigning a unique subnet prefix to each host. Therefore, 138 it is also known as "unique prefix per host" [RFC8273]. 140 NCE - Neighbor Cache Entry, a binding of a neighbor's IPv6 141 address and link layer address. 143 2. Summary of ND Issues and Existing Solutions 145 This section summarizes the main ND issues and solutions. More 146 information can be found in [RFC6583][RFC6775][RFC9099]. 148 2.1. Multicast Issues and Solutions 150 ND uses multicast extensively for Node Solicitations (NSs), Router 151 Solicitations (RSs) and Router Advertisements (RAs). When multicast 152 messages are sent over an L2 medium, they may be mapped into L2 153 broadcast messages. For many wireless media, L2 broadcast may 154 consume more network resources than multiple P2P unicast combined 155 [RFC6775][RFC7668], and have lower probability of delivery. In 156 addition, multicast has no acknowledgement. Consequently, multicast 157 may cause a number of issues: 159 . Multicast-resource-consumption issue: multicast in L3 and the 160 resulted broadcast in L2 may consume many times more resources 161 than unicast; 162 . Multicast-power-consumption issue: multicast consumes more 163 power of the sender; In addition, an L2 broadcast message may 164 reach more nodes than the L3 multicast intended. This may 165 consume some receiving nodes' power unnecessarily. For power 166 constrained nodes, this is an issue; 167 . Multicast-reliability issue: some multicast messages may not 168 reach the destinations. Sleeping nodes may not respond to a 169 multicast message. As a result, protocol procedures that rely 170 on multicast can be unreliable. 172 Existing ND solutions that can prevent or address multicast issues 173 include: 175 . Mobile Broadband IPv6 (MBBv6) and Fixed Broadband IPv6 (FBBv6): 176 MBBv6 is defined in "IPv6 in 3GPP EPS" [RFC6459] and "IPv6 for 177 3GPP Cellular Hosts" [RFC7066]. MBBv6 isolates each host in L2 178 by putting it in a P2P link with the router. FBBv6 is defined 179 in "IPv6 in the context of TR-101" [TR177]. FBBv6 also isolates 180 each host in l2, either by putting it in a P2P link with the 181 router, or by implementing split horizon on Ethernet to prevent 182 direct host communication. Note that a host here is either a 183 mobile User Equipment (UE), or a routed Residential Gateway 184 (RG), or a real host (e.g. a computer) behind a bridged RG. The 185 router here is either the mobile gateway or the Broadband 186 Network Gateway (BNG). MBBv6 and FBBv6 also give each host a 187 unique prefix and thus put it in its own subnet. Consequently, 188 every host can only communicate with the router in both L2 and 189 L3, and there is effectively no multicast. 191 Note 1: because in FBBv6, bridged RG situation is very similar 192 to routed RG situation, except that in the former, the hosts 193 are real hosts (e.g. computers), while in the latter, the hosts 194 are the routed RGs. For description simplicity, bridged RGs 195 will not be further discussed in the document. 197 . Wireless ND (WiND): the solution is defined in a series of RFCs 198 [RFC6775][RFC8505][RFC8928][RFC8929]. WiND changes host and 199 router behaviors to use multicast only for router discovery and 200 not for other protocol procedures. The key points are (1) hosts 201 use unicast to proactively register their addresses at the 202 routers; (2) routers use unicast to communicate with hosts, and 203 become the central address register and arbitrator for the 204 hosts. Router also proactively installs Neighbor Cache Entries 205 (NCEs) for the hosts; (3) each host communicates only with the 206 router. Consequently, multicast is largely eliminated; 208 . Unique IPv6 Prefix per Host (UPPH) [RFC8273]: this solution 209 gives each host a unique prefix, thus puts it in its own 210 subnet. Multicast is greatly reduced, because (1) a host will 211 not use multicast for address resolution for other hosts, 212 because there is no other host in the same subnet; (2) 213 downstream multicast from router to hosts are eliminated and 214 turned into unicast ([RFC8273] Section 4 Paragraph 3). 216 Note 2: the pros and cons of RFC8273 will be briefly reviewed 217 in Section 3.1. An in-depth discussion can be found in [8273D]. 219 . IP Point to Point Ethernet Subnet Model [P2Peth]: if 220 progressed, this draft may provide a solution similar to 221 RFC8273, making use of unique prefix per host to reduce 222 multicast. 224 2.2. DAD-unreliable Issue and Solutions 226 Duplicate Address Detection (DAD) uses absence of response as 227 indication of no duplicate. This can be unreliable for two reasons. 228 Firstly, the Neighbor Solicitation or the Neighbor Advertisement 229 messages may be lost in transmission, especially in wireless 230 environment. Secondly, sleeping nodes may not respond to the DAD 231 messages. 233 Existing ND solutions that can prevent or address DAD-unreliable 234 issue include: 236 . MBBv6 and FBBv6: for MBBv6, the UE's Interface ID (IID) is 237 assigned by the mobile gateway, and is guaranteed to be unique 238 [RFC6459]. There is no need for DAD. For FBBv6, the RG's Global 239 Unicast Address (GUA) prefix is unique. There will be no 240 duplicate for GUA address, and no DAD will be performed. RG 241 will perform DAD for its Link Local Address (LLA), but only to 242 the BNG [TR177]. In such an environment, there is no sleeping 243 node or lossy media. DAD has no reliability issue. 245 . WiND: every host must register its address at the router before 246 using it. The registration will succeed only if the router 247 explicitly approves it, and the router will not approve if it 248 is a duplicate. Therefore, the DAD procedure becomes reliable. 250 . RFC8273: For GUA addresses, since each host is given a 251 different prefix, duplicate address will not exist. For link 252 local address, since each subnet has only one host, there is no 253 possibility of duplication in the subnet. A duplicate link 254 local address may exist in another subnet but that does not 255 matter. Therefore, DAD-unreliable issue is prevented. 257 2.3. On-demand NCE Installation Issue and Solutions 259 ND address resolution is on-demand. It is done only when a packet 260 needs to be sent but the link layer address of the on-link 261 destination is unknown. Consequently, the packet has to be queued 262 until link layer address is determined. This increases delay and may 263 affect application performance. For high performance environment, 264 this can be an issue. 266 Existing ND solutions that can prevent or address on-demand NCE 267 installation issue include: 269 . MBBv6 and FBBv6: MBBv6 and some FBBv6 use IPv6 over PPP 270 [RFC5072]. In this case, there is no need to find out the link 271 layer address before sending a packet on the PPP interface. In 272 other words, there is no NCE installation issue. Some FBBv6 273 implementations use IPoE. There is a need for NCE. But because 274 every host is given a unique prefix by the BNG in FBBv6, the 275 BNG needs to know the host's link layer address which uniquely 276 identify the host in order to do so. Therefore, the BNG can 277 install NCE when assigning a prefix to the host, not waiting 278 until a data packet is to be sent to that host. On-demand NCE 279 installation issue is therefore avoided in this case too. 281 . Wireless ND (WiND): when hosts register their IPv6 addresses, 282 they will also present their link layer address. Therefore, NCE 283 entries can be installed proactively before data packets 284 arrive. 286 . Gratuitous Neighbor Discovery [GRAND]: this solution changes 287 router and host behaviors to allow routers to proactively 288 create an NCE when a new IPv6 address is assigned to a host, 289 and to recommend that hosts send unsolicited Neighbor 290 Advertisements upon having a new IPv6 address. It can be 291 considered as the IPv6 equivalent of Gratuitous ARP in IPv4. 293 2.4. Security Issues and Solutions 295 ND assumes all nodes can be trusted. Otherwise, ND has various 296 security issues. These issues are described in [RFC3756][RFC6583] 297 and [RFC9099]. They are briefly summarized here. 299 The security issues can be classified into two categories: 301 . Redirect attacks, in which a malicious node redirects packets 302 destined for the first-hop router or a legitimate receiver to 303 itself. This is usually done by faking the source IPv6 address 304 to pretend to be another node, or by sending Router 305 Advertisement to pretend to be a router. For example: 307 o an attacker can send out Router Advertisement claiming 308 itself as the first-hop router, and redirect hosts' 309 traffic to itself. 311 o an attacker can send Neighbor Advertisements to the first- 312 hop router, spoofing the IPv6 address of another node 313 while using its own link layer address. This will redirect 314 traffic from the router to the victim to the attacker 315 instead. 317 . Denial-of-Service (DoS) attacks, in which a malicious node 318 prevents communication between the victim node and other nodes. 319 For example: 321 o Whenever a host performs DAD, an attacker can reply to 322 claim that the selected address is in use. The host will 323 not be able to get an address. 325 o /64 scan attack: an attacker sends packets to up to 2**64 326 mostly non-existing hosts, forcing the first-hop router to 327 try to install NCEs for this huge number of non-existing 328 hosts. If unprotected, the router will run out of resource 329 and stop functioning. Note that for other attacks to 330 happen, the attacker must be on-link. But for this /64 331 scan attack, the attacker can be off-link. 333 It is worth noting that redirect attacks are generally considered as 334 more harmful than DoS attacks. Therefore, higher priority is given 335 to protect against redirect attacks. 337 Existing ND solutions that can prevent or address the security 338 issues include: 340 . MBBv6 and FBBv6: because every host is isolated in L2, all on- 341 link security issues are prevented. Because every host has its 342 own prefix, and the mobile gateway or BNG maintains state 343 information for the prefix instead of for individual IPv6 344 address, off-link /64 scan attack will not cause harm - the 345 mobile gateway or BNG will not create an NCE for every IP 346 address in the /64. Such attack messages can simply be dropped. 348 . WiND: normally, every host is isolated in L2 and can only 349 communicate with the first-hop router. Therefore, all on-link 350 security issues are prevented. But if hosts are not isolated in 351 L2, e.g. when there is a bridge between the hosts and the 352 router, then on-link security issue can happen. Off-link /64 353 scan attack will not cause harm because in WiND, NCE 354 installation is proactive. In other words, the router will not 355 create any NCE when receiving such messages. Such attack 356 messages can simply be dropped. 358 . RFC8273: by giving each host a different prefix and keep track 359 of host-prefix binding, an attacker host cannot change the NCE 360 at the router for another host by sending Neighbor 361 Advertisement with a spoofed source IPv6 address of that host. 362 The attacker thus cannot redirect traffic from router to that 363 host to itself. The router will maintain only one NCE entry for 364 each prefix/host. Therefore, off-link /64 scan attack will not 365 cause harm. RFC8273's protection effect against other security 366 issues depends on whether the hosts are also isolated in L2. If 367 yes, all the on-link security issues will be prevented. If not, 368 certain on-link security issues remain. 370 . Source Address Validation Improvement [SAVI], Router 371 Advertisement Guard [RA-Guard][RA-Guard+]: these solutions 372 protect against redirect attacks and some DoS attacks. SAVI 373 binds an address to a port, and rejects claims from other ports 374 for that address. Therefore, a node cannot spoof the IP address 375 of another node. RA-Guard and RA-Guard+ only allow RAs from a 376 port that a router is connected. Therefore, nodes on other 377 ports cannot pretend to be a router. In order to protect 378 against some other DoS attacks, e.g. off-link /64 scan attack, 379 other security measures are needed, e.g. rate limiting on NSs, 380 and filtering on NAs/RAs. 382 . Secure Neighbor Discovery [SeND] and Cryptographically 383 Generated Addresses [CGA]: these solutions have tried to make 384 ND secure, but have not been widely deployed. They will not be 385 further discussed in this document. 387 2.5. Observations on the Solutions and an Insight Learned 389 MBBv6 and FBBv6 prevent or solve all the ND issues. These solutions 390 have two common characteristics that are effective for preventing or 391 solving ND issues: 393 (1) Hosts (i.e. UEs or RGs or real hosts) are isolated in L2 and 394 in different subnets. 395 (2) The first-hop router (i.e. mobile gateway or BNG) maintains 396 some state information across reboots, e.g. prefix to host 397 binding. The router also maintains some controls over the 398 hosts, e.g. which prefix each host gets. 400 WiND prevents or solves all the ND issues in its deployment 401 scenarios, e.g. Low power and Lossy Networks (LLNs) [RFC7102]. WiND 402 also has two characteristics: 404 (1) Hosts are normally isolated in L2 but not in different 405 subnets. In the rare cases where hosts are not isolated in 406 L2, e.g. because there is a bridge between the hosts and the 407 router, then some ND issues like on-link security issues may 408 happen, and additional solutions will be needed to address 409 those issues. 410 (2) The first-hop router maintains some state information across 411 reboots, e.g. host's address registration result including 412 IPv6 address to link layer address binding. The router also 413 uses such state information to maintain some controls over 414 the hosts, e.g. which host wins when there is an address 415 contention. 417 RFC8273 solves certain ND issues but not all. It has two 418 characteristics: 420 (1) Hosts are isolated in different subnets, but RFC8273 does 421 not specify whether hosts should also be isolated in L2. If 422 hosts are also isolated in L2, all ND issues will be 423 prevented. 424 (2) The first-hop router maintains some state information across 425 reboots, e.g. prefix-host binding. The router also maintains 426 some controls over the hosts, e.g. which prefix a host gets. 428 SAVI, RA-Guard, RA-Guard+ and GRAND solve specific ND issues. They 429 have two characteristics: 431 (1) These solutions make no assumptions on L2 isolation or 432 subnet isolation. They just solve the ND issues that they 433 are designed to solve. 434 (2) SAVI maintains some state information at the Ethernet switch 435 between the hosts and the first-hop router(s). Such states 436 are learned dynamically from packet snooping, or configured 437 manually. The Ethernet switch uses such state information to 438 control the hosts, e.g., RAs are not allowed from the hosts. 440 An insight can be learned from these observations. That is, L2 441 isolation and subnet isolation can be effective in preventing ND 442 issues. But L2 isolation and subnet isolation also have their cost. 443 For example, because hosts are isolated and cannot directly 444 coordinate with each other, the router must have new functionality 445 to coordinate the hosts, e.g. to be the arbitrator when there is an 446 address contention. In order to do so, the router must maintain some 447 state information, e.g. the (IP address, link layer address) binding 448 for each host. 450 The next section discusses how to apply this insight to future ND 451 deployments. 453 3. Isolating Hosts in L2 and in Subnet to Simplify ND Deployment 455 3.1. Applicability of L2 Isolation and Subnet Isolation 457 This section describes how to isolate hosts in L2 and in subnet, and 458 the advantages and disadvantages of doing so. 460 Isolating hosts in L2 can be done by: (1) putting a host in a P2P 461 link with the router, or (2) using private VLAN [PVLAN], or split 462 horizon [TR177], or wireless isolation [W-Iso] on multi-access 463 medium to prevent hosts from communicating with each other. These 464 are a matter of device configuration so it can usually be done as 465 long as the devices support these isolating features. 467 Isolating hosts in L2 is different from setting ND Prefix 468 Information Option (PIO) L-bit=0. For example, in the latter, there 469 can be multiple hosts in a link, and a malicious host can launch on- 470 link security attacks at other hosts. 472 When hosts are isolated in L2, DAD messages can only reach the 473 router but no other hosts. Therefore, the router must act to prevent 474 hosts from using duplicate GUA or link local address. This 475 functionality is called DAD Proxy [TR177][RFC6957]. 477 The advantages of isolating hosts in L2 include: 479 o Prevention of on-link security and upstream multicast issues 480 (from hosts), because hosts cannot reach each other directly. 482 The disadvantage of isolating hosts in L2 include: 484 o The router must support additional functionality: DAD Proxy. 486 o Downstream multicast issues, DAD-unreliable issue, On-demand NCE 487 Installation issue and off-link /64 scan issue still remain. 489 o All host communication must go through the router. In a high 490 performance environment, the router may become the bottleneck. 492 o Services relying on multicast, e.g. Multicast DNS [mDNS], will 493 not work, unless the router can provide multicast proxy. 495 o There is additional work (e.g. PVLAN, split horizon or wireless 496 isolation) to isolate hosts in L2 in multi-access media, but this 497 is small amount of work. 499 o Many more interfaces or sub-interfaces are likely needed on the 500 router, for example if point-to-point VLANs are used for L2 501 isolation. 503 From the analysis above, it is clear that L2 isolation alone is not 504 advantageous. The benefits are small while the costs are high. 505 Therefore, L2 isolation is better used with something else, e.g. 506 subnet isolation or some specially designed solutions like WiND. 508 The known solutions supporting host isolation in L2 include WiND, 509 and in more special cases (i.e. with both L2 and subnet isolation), 510 MBBv6 and FBBv6. 512 Host isolation in subnet (i.e. Unique Prefix Per Host, or UPPH) can 513 be done either with [DHCPv6], where the prefix can be of any length 514 supported by DHCPv6, or with SLAAC as specified in RFC8273, where 515 the prefix must be /64 or shorter. If [P2Peth] is progressed, it can 516 provide another solution. 518 In order to isolate hosts in subnet, the router must be able to 519 assign a unique prefix to each host and keep track of the prefix- 520 host link layer address binding. This will be referred to as "UPPH 521 support" later in this document. This may be achieved by some 522 mechanism that RFC8273 alluded to but did not specify, or by some 523 other mechanisms if DHCPv6 is used [TR177]. Note that with 524 SLAAC/RFC8273, such router implementation exists [8273D], while with 525 DHCPv6, FBBv6-capable BNG is one of such implementations. 527 The advantages of isolating hosts in subnet are: 529 o Downstream Multicast, DAD-unreliable, on-demand NCE installation 530 and off-link /64 scan issues are prevented. 532 o It is the only way for the router to do subscriber management for 533 the hosts in a SLAAC environment. Imagine a public Wi-Fi scenario 534 where the mobile UEs only support SLAAC. If the router does not 535 give each UE a unique prefix and keep track of UE-prefix binding, 536 network administrators do not know which IPv6 address corresponds 537 to which UE, because each UE picks its own IID and uses the same 538 prefix. Therefore, network administrators cannot keep track of 539 which UE did what. This would be unacceptable from an operation 540 perspective. 542 The disadvantages of isolating hosts in subnet are: 544 o The routers must support new functionality: "UPPH support". 546 o Upstream multicast and on-link security issues can happen, unless 547 the hosts are also isolated in L2 549 o Many prefixes will be needed instead of just one. But this 550 disadvantage may not be as severe as it appears. After all, 3GPP 551 has given every mobile UE a /64 [RFC6459], and BBF has given 552 every routed RG a /56 with DHCPv6 PD [TR177]. Outside of MBB, FBB 553 and IoT, not many scenarios have a large number of hosts. Giving 554 each host a /64 prefix may not be a problem. 556 o Many more interfaces or sub-interfaces are needed on the router. 558 The known solutions supporting subnet isolation include RFC8273, and 559 in more special cases (i.e. supporting both L2 isolation and subnet 560 isolation), MBBv6 and FBBv6. 562 The above analysis reveals that L2 isolation and subnet isolation 563 are synergetic. When they are done together, the advantages are: 565 o All ND issues are prevented. 567 o It provides a way for the router to do subscriber management for 568 the hosts in a SLAAC environment. 570 o DAD Proxy needed for L2 isolation is no longer needed, because 571 with unique prefix per host, GUA cannot be duplicate. For link 572 local address, since each subnet has only one host, there is no 573 possibility of duplication. A duplicate link local address may 574 exist in another subnet but that does not matter. Therefore, 575 there is no need for DAD Proxy to prevent duplicate GUA/LLA 576 addresses. 578 The disadvantages are: 580 o The routers must support new functionality: "UPPH support". 582 o Many prefixes will be needed, one per host. 584 o All host communication must go through the router. In a high 585 performance environment, the router may become the bottleneck. 587 o Services relying on multicast, e.g. mDNS, will not work, unless 588 the router can provide multicast proxy. 590 o There is additional work (e.g. PVLAN, split horizon or wireless 591 isolation) to isolate hosts in L2 in multi-access media, but this 592 is small amount of work. 594 o Many more interfaces or sub-interfaces are needed on the router. 596 The known solutions supporting host isolation in L2 and in subnet 597 include RFC8273, MBBv6 and FBBv6. 599 3.2. Deployment Guidelines 601 Given the applicability analysis in Section 3.1, network 602 administrators can decide where to use which isolation option. Note 603 that in all the following steps, if DHCPv6 (IA_NA or PD) is 604 supported and desired, use DHCPv6 to assign address prefix, as it 605 may provide prefix length flexibility. Otherwise, use SLAAC as SLAAC 606 is more widely supported. 608 1. If isolating hosts in both L2 and in subnet is desirable and 609 feasible: 611 Based on the applicability discussion in Section 3.1, the 612 scenarios here likely have some or all of the following 613 characteristics: (1) It is a public access environment where 614 subscriber management is needed; (2) Many ND issues can happen and 615 will require solutions. This is why it is desirable to prevent as 616 many issues as possible, to simplify the deployment; (3) Neither 617 high performance communication nor multicast service discovery is 618 applicable here. 620 With suitable "UPPH support", all the ND issues will be prevented. 621 Some possible "UPPH support" solutions are: 623 a) If the deployment scenario is MBB or FBB, then MBBv6 or FBBv6 624 can be used. 626 b) Otherwise, use a RFC8273 implementation (using SLAAC) to 627 realize "UPPH support". Note that this is a special use case 628 of RFC8273 where each host is not only given a unique prefix, 629 but also isolated from other hosts in L2. 631 2. Otherwise, if isolating hosts in L2 but not in subnet is 632 considered appropriate: 634 In this scenario, hosts are in different links but in the same 635 subnet. This architecture is called Multi-Link SubNet (MLSN). MLSN 636 has been a controversial scheme in the IETF. The original IPv6 637 Addressing Architecture [RFC1884] stated that "IPv6 continues the 638 IPv4 model that a subnet is associated with one link. Multiple 639 subnets may be assigned to the same link". This ruled out MLSN in 640 the IPv6 WG (now 6man). However, some other WGs like MANET and 6lo 641 use MLSN in their solutions [RFC7668][RFC8929]. [RFC4903] 642 documented the concerns about MLSN. 644 For solutions related to ND, only WiND supports MLSN. Therefore, 645 the deployment scenario here is most likely one that WiND is 646 suitable for, e.g. Low-power and Lossy Networks (LLNs). WiND has 647 all functionalities needed for this scenario, including proactive 648 address registration. WiND prevents all the ND issues but is a 649 relatively sophisticated protocol that requires changes to both 650 router and host behaviors from normal ND. 652 3. Otherwise, if isolating hosts in subnet but not in L2 is 653 considered appropriate: 655 Based on the applicability discussion in Section 3.1, the 656 scenarios here likely have the following characteristics: (1) 657 Subscriber management is needed. This is likely a public access 658 scenario. (2) Upstream multicast is needed or cannot be avoided 659 (otherwise L2 host isolation would have been selected to prevent 660 more issues), e.g. for service discovery. RFC8273 can be used as 661 the solution here. On-link security is not prevented in this case. 662 Because this is a public access scenario, SAVI/RA-Guard/RA-Guard+ 663 may be needed to address the on-link security issue. 665 4. Otherwise, no isolation in L2 or subnet is desired or feasible. 667 The scenarios here likely have the following characteristics: (1) 668 It is a private environment, because subscriber management is not 669 needed. As such, on-link security is not a big concern. (2) Either 670 multicast service is needed, or this is a high performance 671 scenario, because L2 host isolation is not desired. Either way, 672 multicast and DAD-unreliable are not a concern. Normal ND can be 673 used as the solution. Off-link /64 scan and on-demand NCE 674 installation are the two issues left. Off-link /64 scan issue can 675 be handled by rate limiting or unused-address filtering. If this 676 is indeed a high performance environment, e.g. a DC network, GRAND 677 can be used to enable proactive NCE installation. 679 In short, the guidelines can be summarized as: if many of the ND 680 issues discussed in Section 3 are valid concerns and need to be 681 addressed, then isolate hosts in L2 and in subnet to prevent the 682 issues, and use RFC8273. If the scenario is LLN, use WiND. But if 683 the scenario is a private environment where many ND issues are not 684 real concerns, then just use normal ND, and adds other solutions 685 like GRAND only when needed. Overall, these guidelines will likely 686 result in the simplest ND solution. 688 4. Impact of L2 Isolation and Subnet Isolation to Other Components of 689 IPv6 First-hop 691 The guidelines in section 3 will likely simplify ND deployment. But 692 will they complicate other components of IPv6 first-hop? A 693 preliminary impact analysis is done in this section. 695 IPv6 first-hop consists of: 697 o The routers and the hosts, whose requirements & behaviors are 698 defined in [RFC8504]; 700 o Addressing scheme; 702 o The basic protocol suite: ND, SLAAC, DHCPv6, DNS, ICMPv6, MLD 703 v1/v2; 705 o Other extended protocols: mDNS. 707 The impact of host isolation in L2 and in subnet to other components 708 of IPv6 first-hop comes from five parts: (1) the special topology 709 introduced by L2 isolation; (2) the special addressing scheme 710 introduced by subnet isolation (i.e. unique prefix per host); (3) 711 the new functionalities introduced to the router, i.e. "DAD Proxy" 712 for L2 isolation. (4) The increased number of interfaces on the 713 router (5) When WiND is used, hosts must be changed to support 714 proactive address registration etc. This is a high requirement that 715 can be considered as complicating the IPv6 first-hops. But WiND 716 appears to be the only solution in its applicable scenarios like 717 LLNs. When there is no alternative, there is no need to discuss 718 whether the solution unduly complicates other components of IPv6 719 first-hop. Therefore, WiND will not be further discussed. Because 720 DAD Proxy is only needed in L2 isolation but not in subnet 721 isolation, and this scenario uses WiND which already provides DAD 722 Proxy, DAD Proxy will not be further discussed either. 724 First, regarding the impact from the special topology: 726 Isolating hosts should only affect the protocols that rely on 727 multicast, i.e. ND, SLAAC and mDNS, but not the multicast protocols 728 themselves, i.e. MLD v1/v2. As discussed in Sections 2 and 3, the 729 impact to ND and SLAAC are positive. The impact to mDNS is negative. 730 But the guidelines give network administrators the option not to 731 isolate hosts at all. So if network administrators choose to 732 isolate, the benefit must outweigh the cost, e.g. mDNS may not be 733 needed in the deployment scenario. 735 Second, regarding the impact from the special addressing scheme: 737 IPv6 first-hop should allow any addressing scheme. Other than using 738 more prefixes, it is not envisioned that unique prefix per host 739 complicates addressing scheme in any way. After all, unique prefix 740 per host is already widely in use in MBBv6 and FBBv6 deployments. 742 Third, regarding the impact of new router functionality "UPPH 743 support": 745 The impact of "UPPH support" with RFC8273 using SLAAC has been 746 discussed in [8273D] before RFC8273 became an RFC. The following 747 concerns had been raised: 749 . RFC8273 makes the router stateful; 750 . How to reclaim unused prefix is not specified; 751 . If there are multiple first-hop routers, how the solution works 752 is unspecified: (1) do they assign prefixes to hosts 753 independently? (2) do they need to sync up with each other? 754 . Resiliency of SLAAC may be reduced as a result of the increased 755 state at the router, i.e. the prefix-host binding. 757 Given that RFC8273 became an RFC, the rough consensus has been its 758 benefit outweighs the cost. Because MBBv6 and FBBv6 also support 759 UPPH and are widely deployed, the impact of "UPPH support" appears 760 manageable. 762 Fourth, regarding the impact of increased number of interfaces on 763 the router: for the consumer market where the number of hosts (i.e. 764 subscribers) is large, this may increase the number of routers 765 needed in the first-hop. However, for the consumer market, MBBv6, 766 FBBv6 and some public Wi-Fi deployments are already using L2 767 isolation & subnet isolation before the guidelines are proposed. So 768 the guidelines bring no additional burden. Outside of consumer 769 market, a router can generally provide more interfaces than needed. 770 So this increase should not be a problem either. 772 All things considered, it appears that isolating hosts in L2 and in 773 subnet can simplify ND without unduly complicating other components 774 of IPv6 first-hop. 776 5. Applying the Guidelines to Real World Scenarios 778 The guidelines are intended for future IPv6 first-hop deployments. 779 But if we test the guidelines on well-known IPv6 first-hop scenarios 780 to find the suitable ND solution, the result will be as follows: 782 o MBB and FBB will end at Step 1.a: isolating hosts in L2 and in 783 subnet, with MBBv6 as the solution with SLAAC and FBBv6 as the 784 solution with DHCPv6, respectively; 786 o Public Wi-Fi network will end at Step 1.b: isolating hosts in L2 787 and in subnet, with RFC8273 as the solution with SLAAC, since the 788 hosts here may be mobile UEs that do not support DHCPv6. Note 789 that in Wi-Fi with the Infrastructure Mode [WiFi-inf], each host 790 (i.e. STA) communicates only with the Access Point (AP). With 791 wireless isolation, every host can only communicate with the AP 792 (and the router if the AP is not a router), not directly with 793 other hosts. This is how L2 isolation can be achieved in this 794 scenario. If L2 isolation is not done, then public Wi-Fi will end 795 at Step 3. SAVI/RA-Guard/RA-Guard+ may be needed to address the 796 on-link security issue. 798 o Low-power and Lossy Networks (LLNs) will end at Step 2: isolating 799 hosts in L2 but not in subnet, with WiND as the solution with 800 SLAAC. Note that although WiND did not mandate L2 isolation, WiND 801 works better when hosts are isolated in L2. Otherwise, additional 802 mechanisms may be needed to address on-link security issues. 804 o High speed DC Networks will end at Step 4: using normal ND with 805 GRAND without host isolation in L2 or in subnet. SAVI, RA-Guard 806 and RA-Guard+ may not be needed as high physical access security 807 is likely maintained. 809 o Common enterprise LANs with mixed Ethernet and Wi-Fi (not DC 810 networks) will end at: 812 o If security is a concern to justify host isolations: 814 . Step 1.b: isolating hosts in L2 and in subnet, with 815 RFC8273 as the solution with SLAAC;. 817 o If security is not a concern to justify host isolations: 819 . Step 4: using normal ND with no special host isolation. 820 GRAND and SAVI, RA-Guard and RA-Guard+ may not be 821 needed. 823 o [HomeNet] will end at Step 4: using normal ND with no special 824 host isolation. GRAND and SAVI, RA-Guard and RA-Guard+ are not 825 needed. 827 These results match current practices in reality. This validates the 828 guidelines to some extent. 830 6. Security Considerations 832 This document provides guidelines on where to isolate hosts in L2 833 and in subnet to prevent ND issues, and how to select existing 834 solutions for the remaining issues. When a solution is selected, 835 the security considerations of that solution apply. This document 836 does not introduce any new mechanisms. Therefore, it does not 837 introduce new security issues. 839 7. IANA Considerations 841 This document has no request to IANA. 843 8. References 845 8.1. Informative References 847 [8273D] Discussion on the pros and cons of RFC8273, 848 https://mailarchive.ietf.org/arch/msg/v6ops/M47lN8lyXaWVcx 849 8nitvkxMfbGNA/ 851 [CGA] T. Aura, "Cryptographically Generated Addresses (CGA)" , 852 RFC3972 854 [DHCPv6] T. Mrugalski M. Siodelski B. Volz A. Yourtchenko M. 855 Richardson S. Jiang T. Lemon T. Winters, "Dynamic Host 856 Configuration Protocol for IPv6 (DHCPv6)", RFC 8415. 858 [GRAND] J. Linkova, "Gratuitous Neighbor Discovery: Creating 859 Neighbor Cache Entries on First-Hop Routers", 860 https://datatracker.ietf.org/doc/html/draft-ietf-6man- 861 grand-07 863 [HomeNet] T. Chown, J. Arkko, A. Brandt, O. Troan, J. Weil, "IPv6 864 Home Networking Architecture Principles", RFC 7368, DOI 865 10.17487/RFC7368, October 2014, . 868 [mDNS] S. Cheshire, M. Krochmal, "Multicast DNS", RFC 6762. 870 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 871 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 872 DOI 10.17487/RFC4861, September 2007, . 875 [PVLAN] https://en.wikipedia.org/wiki/Private_VLAN 877 [P2Peth] O. Troan, "IP Point to Point Ethernet Subnet Model", 878 https://datatracker.ietf.org/doc/draft-troan-6man-p2p- 879 ethernet/ 881 [RA-Guard] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. 882 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 883 10.17487/RFC6105, February 2011, . 886 [RA-Guard+] F. Gont, "Implementation Advice for IPv6 Router 887 Advertisement Guard (RA-Guard)", RFC 7113, DOI 888 10.17487/RFC7113, February 2014, . 891 [RFC1884] R. Hinden, S.Deering, "IP Version 6 Addressing 892 Architecture", RFC 1884. 894 [RFC3756] P. Nikander, J. Kempf, E. Nordmark, "IPv6 Neighbor 895 Discovery (ND) Trust Models and Threats", RFC 3756. 897 [RFC4903] D. Thaler, "Multi-Link Subnet Issues", RFC 4903 899 [RFC5072] S. Varada, D. Haskins, E. Allen, "IP Version 6 over PPP", 900 RFC 5072 902 [RFC6459] J. Korhonen, J. Soininen, B. Patil, T. Savolainen, G. 903 Bajko, K. Iisakkila, "IPv6 in 3rd Generation Partnership 904 Project (3GPP) Evolved Packet System (EPS)", RFC 6459. 906 [RFC6583] I. Gashinsky, J. Jaeggli, W. Kumari, "Operational Neighbor 907 Discovery Problems", RFC 6583. 909 [RFC6775] Z. Shelby, S. Chakrabarti, E. Nordmark, C. Bormann, 910 "Neighbor Discovery Optimization for IPv6 over Low-Power 911 Wireless Personal Area Networks (6LoWPANs)", RFC 6775. 913 [RFC6957] F. Costa, J-M. Combes, X. Pougnard, H. Li, "Duplicate 914 Address Detection Proxy", RFC 6957 916 [RFC7066] J. Korhonen, J. Arkko, T. Savolainen, S. Krishnan, "IPv6 917 for Third Generation Partnership Project (3GPP) Cellular 918 Hosts", RFC 7066. 920 [RFC7102] JP. Vasseur, "Terms Used in Routing for Low-Power and 921 Lossy Networks", RFC 7102. 923 [RFC7668] J. Nieminen, T. Savolainen, M. Isomaki, B. Patil, Z. 924 Shelby, C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", 925 RFC7668. 927 [RFC8273] J. Brzozowski, G. Van de Velde, "Unique IPv6 Prefix per 928 Host", RFC 8273. 930 [RFC8504] T. Chown, J. Loughney, T. Winters, "IPv6 Node 931 Requirements", RFC 8504, January 2019, . 934 [RFC8505] P. Thubert, E. Nordmark, S. Chakrabarti, C. Perkins, 935 "Registration Extensions for IPv6 over Low-Power Wireless 936 Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 937 8505. 939 [RFC8928] P. Thubert, B. Sarikaya, M. Sethi, R. Struik, "Address- 940 Protected Neighbor Discovery for Low-Power and Lossy 941 Networks", RFC 8928. 943 [RFC8929] P. Thubert, C.E. Perkins, E. Levy-Abegnoli, "IPv6 Backbone 944 Router", RFC 8929. 946 [RFC9099] E. Vyncke, K. Chittimaneni, M. Kaeo, E. Rey, "Operational 947 Security Considerations for IPv6 Networks", RFC 9099. 949 [RIPE IPv6 security] RIPE NCC, "IPv6 Security Training Course", 950 https://www.ripe.net/support/training/material/ipv6- 951 security/ipv6security-slides.pdf 953 [SAVI] J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt, "Source 954 Address Validation Improvement (SAVI) Framework", RFC 7039 956 [SeND] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor 957 Discovery (SEND)", RFC3971 959 [SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 960 Address Autoconfiguration", RFC 4862, DOI 961 10.17487/RFC4862, September 2007, . 964 [TR177] S. Ooghe, B. Varga, W. Dec, D. Allan, "IPv6 in the context 965 of TR-101", Broadband Forum, TR-177. 967 [WiFi-inf] Wi-Fi Infrastructure Mode, 968 https://www.howtogeek.com/180649/htg-explains-whats-the- 969 difference-between-ad-hoc-and-infrastructure-mode/ 971 [W-Iso] Wireless Isolation, https://www.quora.com/What-is- 972 wireless-isolation 974 9. Acknowledgments 976 The authors would like to thank Eduard Vasilenko, Pascal Thubert, 977 and Ole Troan for the discussion and input. 979 Authors' Addresses 981 XiPeng Xiao 982 Huawei Technologies 983 Hansaallee 205, 40549 Dusseldorf, Germany 985 Email: xipengxiao@huawei.com 987 Eduard Metz 988 KPN N.V. 989 Maanplein 55, 2516CK The Hague, The Netherlands 991 Email: eduard.metz@kpn.com 993 Gyan Mishra 994 Verizon Inc. 996 Email: gyan.s.mishra@verizon.com