idnits 2.17.1 draft-xiao-v6ops-nd-deployment-guidelines-00.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 (July 12, 2021) is 1013 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Duplicate reference: RFC8273, mentioned in 'RFC8273', was also mentioned in '8273D'. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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: Jan. 2022 KPN 5 G. Mishra 6 Verizon Inc. 7 July 12, 2021 9 Isolating Hosts in Layer-2 and Layer-3 to Simplify ND and IPv6 10 First-Hop Deployments 11 draft-xiao-v6ops-nd-deployment-guidelines-00 13 Abstract 15 Neighbor Discovery (ND) is an integral part of IPv6 first-hop. Due 16 to limitation of certain L2 media's support to ND, a number of 17 issues can happen in certain scenarios. The corresponding solutions 18 for these issues have also been designed. These issues and solutions 19 are summarized in RFC3756, RFC6583, OPSECv27. However, there is no 20 guideline on how to avoid the issues or how to select the proper 21 solutions. 23 This document analyzes existing solutions and summarizes the wisdoms 24 embedded in these solutions into an insight: isolating hosts in L2 25 and L3 can be effective in preventing ND issues. In deployment 26 scenarios where the ND issues can occur, this prevention approach 27 can be more effective than deploying various solutions to solve the 28 issues. Based on this insight, a set of guidelines is proposed for 29 future ND deployments. These guidelines describe where and when to 30 isolate hosts in L2 and L3 to prevent ND issues, and how to select 31 suitable solutions for the remaining issues. This will likely 32 simplify ND deployments. The impact of the guidelines to other 33 components of IPv6 first-hop is also analyzed and appears small. 34 Therefore, the guidelines will likely simplify the overall IPv6 35 first-hop deployments. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six 48 months and may be updated, replaced, or obsoleted by other documents 49 at any time. It is inappropriate to use Internet-Drafts as 50 reference material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 2022. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with 64 respect to this document. Code Components extracted from this 65 document must include Simplified BSD License text as described in 66 Section 4.e of the Trust Legal Provisions and are provided without 67 warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction...................................................3 72 1.1. Terminology...............................................3 73 2. Summary of ND Issues and Existing Solutions....................4 74 2.1. Multicast Issues and Solutions............................4 75 2.2. DAD-unreliable Issues and Solutions.......................6 76 2.3. On-demand NCE Installation Issues and Solutions...........6 77 2.4. Security Issues and Solutions.............................7 78 2.5. Observations on the Solutions and the Insight Learned.....9 79 3. Isolating Hosts in L2 and L3 to Simplify ND Deployments.......11 80 3.1. Applicability of Host Isolation in L2 and L3.............11 81 3.2. Deployment Guidelines....................................14 82 4. Impact of L2 and L3 Host Isolation to Other Components of IPv6 83 First-hop........................................................16 84 5. Applying the Guidelines to Real World Scenarios...............17 85 6. Security Considerations.......................................19 86 7. IANA Considerations...........................................19 87 8. References....................................................19 88 8.1. Informative References...................................19 89 9. Acknowledgments...............................................22 91 1. Introduction 93 ND is an integral part of IPv6 first-hop. Due to limitation of 94 certain L2 media's support to the protocol, a number of issues have 95 been discovered, and the corresponding solutions for these issues 96 have also been designed. These issues and solutions are dispersed 97 in more than 20 RFCs. [RFC6583] summarized the issues and solutions 98 up to 2012. [OPSECv27] summarized known IPv6 security issues, 99 including ND issues, up to 2021. Wireless ND (WiND) 100 [RFC6775][RFC8505][RFC8928][RFC8929] discussed ND issues and 101 solutions in Low-Power and Lossy Networks (LLNs) [RFC7102]. However, 102 two ND deployment problems still exist: 104 1. Neither [RFC6583] nor [OPSECv27] or WiND provides guidelines on 105 how to prevent the issues; 106 2. Some issues have multiple solutions. There is no guideline on 107 how to select the suitable solutions depending on the usage 108 scenarios. 110 [RFC8273] recommends using "Unique IPv6 Prefix per Host" as a best 111 practice for ND. By doing so, certain ND issues can be prevented. 112 So it partially solved Problem 1 above. But [RFC8273] cannot be used 113 everywhere. In fact, some concerns about [RFC8273] have been 114 expressed in [8273D]. 116 This document aims to solve both problems by providing deployment 117 guidelines for ND. Depending on the usage scenarios, the guidelines 118 first try to prevent the issues as much as possible, then recommend 119 suitable solutions for the remaining issues. This can result in the 120 simplest ND solution for future usage scenarios. 122 1.1. Terminology 124 Familiarity with [ND] and [SLAAC] are pre-requisite to understand 125 this document. Familiarity with the ND issues and solutions 126 discussed in [RFC6583] and [OPSECv27] Section 2.3 are also essential 127 to understand this document. 129 Some frequently used terms are defined in this section. 131 Host isolation in L2 - A host cannot send packets via the L2 medium 132 to any other hosts. The router will be the only node 133 reachable in L2. This can be realized on P2P media, or on 134 multi-access media with Private VLAN [PVLAN] or Split 135 Horizon [TR177] or wireless isolation [W-Iso] to prevent 136 hosts from communicating with each other in L2. 138 Host isolation in L3 - Separate hosts into different subnets. It is 139 also known as "unique prefix per host" [RFC8273]. 141 NCE - Neighbor Cache Entry, a binding of a neighbor's IPv6 142 address and link layer address. 144 2. Summary of ND Issues and Existing Solutions 146 This section summarizes the main ND issues and solutions. More 147 information can be found in [RFC6583][OPSECv27][RFC6775]. 149 2.1. Multicast Issues and Solutions 151 ND uses multicast (L3) extensively for Node Solicitations (NSs), 152 Router Solicitations (RSs) and Router Advertisements (RAs). When 153 multicast messages are sent over an L2 medium, they are usually 154 mapped into L2 broadcast messages. For many wireless media, L2 155 broadcast may consume more network resources than multiple P2P 156 unicast combined [RFC6775][RFC7668], and have lower probability to 157 be delivered. In addition, multicast has no acknowledgement. 158 Consequently, multicast may cause a number of issues: 160 . Multicast-resource-consumption issue: multicast in L3 and the 161 resulted broadcast in L2 may consume many times more resources 162 than unicast; 163 . Multicast-power-consumption issue: multicast consumes more 164 power of the sender; In addition, an L2 broadcast message may 165 reach more nodes than the L3 multicast intended. This may 166 consume some receiving nodes' power unnecessarily. For power 167 constrained nodes, this is an issue; 168 . Multicast-reliability issue: some multicast messages may not 169 reach the destinations. Sleeping nodes may not respond to a 170 multicast message. As a result, protocol procedures that rely 171 on multicast can be unreliable. 173 Existing ND solutions that can prevent or address multicast issues 174 include: 176 . Mobile Broadband IPv6 (MBBv6) and Fixed Broadband IPv6 (FBBv6): 177 MBBv6 is defined in "IPv6 in 3GPP EPS" [RFC6459] and "IPv6 for 178 3GPP Cellular Hosts" [RFC7066]. MBBv6 isolates each host in L2 179 by putting it in a P2P link with the router. FBBv6 is defined 180 in "IPv6 in the context of TR-101" [TR177]. FBBv6 also isolates 181 each host in l2, either by putting it in a P2P link with the 182 router, or by implementing split horizon on Ethernet to prevent 183 direct host communication. Note that a host here is either a 184 mobile User Equipment (UE), or a routed Residential Gateway 185 (RG), or a real host (e.g. a computer) behind a bridged RG. The 186 router here is either the mobile gateway or the Broadband 187 Network Gateway (BNG). MBBv6 and FBBv6 also isolate each host 188 in L3 by giving it a unique prefix and thus putting it in its 189 own subnet. Consequently, every host can only communicate with 190 the router in both L2 and L3, and there is effectively no 191 multicast. Because in FBBv6, bridged RG situation is very 192 similar to routed RG situation, except that in the former, the 193 hosts are real hosts (e.g. computers), while in the latter, the 194 hosts are the routed RGs. For description simplicity, bridged 195 RGs 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 reduces the number of hosts in each subnet to one, as a subnet 210 is defined by a prefix. Multicast is greatly reduced, because 211 (1) a host will not use multicast for address resolution of 212 other hosts, because the router is the only L3 next-hop; (2) 213 downstream multicast from router to hosts are eliminated and 214 turned into unicast ([RFC8273] Section 4). The pros and cons of 215 RFC8273 will be briefly reviewed in Section 3.1. An in-depth 216 discussion can be found in [8273D]. 218 . IP Point to Point Ethernet Subnet Model [P2Peth]: if 219 progressed, this draft may provide a solution similar to 220 RFC8273, making use of unique prefix per host to reduce 221 multicast. 223 2.2. DAD-unreliable Issues and Solutions 225 Duplicate Address Detection (DAD) uses absence of response as 226 indication of no duplicate. This can be unreliable because either 227 the Neighbor Solicitation or the Neighbor Advertisement messages may 228 be lost in transmission, especially in wireless environment, or the 229 sleeping nodes may not respond. Duplication thus may not be 230 detected. 232 Existing ND solutions that can prevent or address DAD-unreliable 233 issue include: 235 . MBBv6 and FBBv6: for MBBv6, the UE's Interface ID (IID) is 236 assigned by the mobile gateway, and is guaranteed to be unique 237 [RFC6459]. There is no need for DAD. For FBBv6, the RG's Global 238 Unicast Address (GUA) prefix is unique. There will be no 239 duplicate for GUA address, and no DAD will be performed. RG 240 will perform DAD for its Link Local Address (LLA), but only to 241 the BNG [TR177]. In such an environment, there is no sleeping 242 node or lossy media. DAD has no reliability issue. 244 . WiND: every host must register its address at the router before 245 using it. The registration will succeed only if router 246 explicitly approves it, and router will not approve if it is a 247 duplicate. Therefore, the DAD procedure becomes reliable. 249 . RFC8273: For GUA addresses, since each host is given a 250 different prefix, duplicate address will not exist. For link 251 local address, since each subnet has only one host, there is no 252 possibility of duplication in the subnet. A duplicate link 253 local address may exist in another subnet but that does not 254 matter. Therefore, DAD-unreliable issue is prevented. 256 2.3. On-demand NCE Installation Issues and Solutions 258 ND address resolution is on-demand. It is done only when a packet 259 needs to be sent but the link layer address of the on-link 260 destination is unknown. Consequently, the packet has to be queued 261 until link layer address of the destination is determined. This 262 increases delay and may affect application performance. For high 263 performance environment, this can be an issue. 265 Existing ND solutions that can prevent or address on-demand NCE 266 installation issue include: 268 . MBBv6 and FBBv6: MBBv6 and some FBBv6 use IPv6 over PPP 269 [RFC5072]. In this case, there is no need to find out the link 270 layer address before sending a packet on the interface. In 271 other words, there is no NCE installation issue. Some FBBv6 272 implementations use IPoE. There is a need for NCE. But because 273 every host is given a unique prefix by the BNG in FBBv6, the 274 BNG needs to know the host's link layer address which uniquely 275 identify the host in order to do so. Therefore, the BNG can 276 install NCE when assigning a prefix to the host, not waiting 277 until a data packet is to be sent to that host. On-demand NCE 278 installation issue is therefore avoided in this case too. 280 . Wireless ND (WiND): when hosts register their IPv6 addresses, 281 they will also present their link layer address. Therefore, NCE 282 entries can be installed proactively before data packets 283 arrive. 285 . Gratuitous Neighbor Discovery [GRAND]: this solution changes 286 router and host behaviors to allow routers to proactively 287 create an NCE when a new IPv6 address is assigned to a host, 288 and to recommend hosts sending unsolicited Neighbor 289 Advertisements upon assigning a new IPv6 address. It can be 290 considered as the IPv6 equivalent of Gratuitous ARP in IPv4. 292 2.4. Security Issues and Solutions 294 ND assumes all nodes can be trusted. Otherwise, ND has various 295 security issues. These issues are described in [RFC3756][RFC6583] 296 and [OPSECv27]. They are briefly summarized here. 298 The security issues can be classified into two categories: 300 . Redirect attacks, in which a malicious node redirects packets 301 away from the first-hop router or other legitimate receiver to 302 another node on the link. This is usually done by spoofing the 303 source IPv6 address to pretend to be another node, or by faking 304 Router Advertisement to pretend to be a router. For example: 306 o an attacker can send out Router Advertisement claiming 307 itself as the router, and redirect other hosts' traffic to 308 itself. 310 o an attacker can send Neighbor Advertisements to the first- 311 hop router, spoofing the IPv6 address of another node 312 while using its own link layer address. This will redirect 313 traffic from the router to the victim to the attacker 314 instead. 316 . Denial-of-Service (DoS) attacks, in which a malicious node 317 prevents communication between the node under attack and all 318 other nodes or a specific destination address. For example: 320 o Whenever a host performs DAD, an attacker can reply to 321 claim that the selected address is in use. The host will 322 not be able to get an address. 324 o /64 scan attacks: an attacker sends packets to up to 2**64 325 mostly non-existing hosts, forcing the first-hop router to 326 try to install NCEs for this huge number of non-existing 327 hosts. If unprotected, the router will run out of resource 328 and stop functioning. Note that for other attacks to 329 happen, the attacker must be on-link. But for this /64 330 scan attack, the attacker can be off-link. 332 It is worth noting that redirect attacks are generally considered as 333 more harmful than DoS attacks. Therefore, higher priority is given 334 to protect against redirect attacks. 336 Existing ND solutions that can prevent or address the security 337 issues include: 339 . MBBv6 and FBBv6: because every host is isolated in L2, all on- 340 link security issues are prevented. Because every host has its 341 own prefix, and the mobile gateway or BNG maintains state 342 information for the prefixes not for individual IPv6 address, 343 off-link /64 scan attack will not cause harm because the mobile 344 gateway or BNG will not create any NCE when receiving such 345 messages. Such attack messages can simply be dropped. 347 . WiND: normally, every host is isolated in L2 and can only 348 communicate with the first-hop router. Therefore, all on-link 349 security issues are prevented. But if hosts are not isolated in 350 L2, e.g. when there is a bridge between the hosts and the 351 router, then on-link security issue can happen. Off-link /64 352 scan attack will not cause harm because in WiND, NCE 353 installation is proactive not reactive. In other words, the 354 router will not create any NCE when receiving such messages. 355 Such attack messages can simply be dropped. 357 . RFC8273: by giving each host a different prefix and keep track 358 of host-prefix binding, an attacker host cannot change the NCE 359 at the router for another host by sending Neighbor 360 Advertisement with a spoofed source IPv6 address of that host. 361 The attacker thus cannot redirect traffic from router to that 362 host to itself. The router will maintain only one NCE entry for 363 each prefix/host. Therefore, off-link /64 scan attack will not 364 cause harm. RFC8273's protection effect against other security 365 issues depends on whether the hosts are also isolated in L2. If 366 yes, all the on-link security issues will be prevented. If not, 367 certain on-link security issues remain. 369 . Source Address Validation Improvement [SAVI], Router 370 Advertisement Guard [RA-Guard][RA-Guard+]: these solutions 371 protect against redirect attacks and some DoS attacks. SAVI 372 binds an address to a port, and rejects claims from other ports 373 for that address. Therefore, a node cannot spoof the IP address 374 of another node. RA-Guard and RA-Guard+ only allow RAs from a 375 port that a router is connected. Therefore, nodes on other 376 ports cannot pretend to be a router. In order to protect 377 against some other DoS attacks, e.g. off-link /64 scan attack, 378 other security measures are needed, e.g. rate limiting on NSs, 379 and filtering on NAs/RAs. 381 . Secure Neighbor Discovery [SeND] and Cryptographically 382 Generated Addresses [CGA]: these solutions have tried to make 383 ND secure, but have not been widely deployed. They will not be 384 further discussed in this document. 386 2.5. Observations on the Solutions and the Insight Learned 388 MBBv6 and FBBv6 prevent or solve all the ND issues. These solutions 389 have two common characteristics that are effective for preventing or 390 solving ND issues: 392 (1) Hosts (i.e. UEs or RGs or real hosts) are isolated in both 393 L2 and L3. 394 (2) The first-hop router (i.e. mobile gateway or BNG) maintains 395 some state information across reboots, e.g. prefix to host 396 binding. The router also maintains some controls over the 397 hosts, e.g. which prefix each host gets. 399 WiND prevents or solves all the ND issues in its deployment 400 scenarios, e.g. Low power and Lossy Networks (LLNs) [RFC7102]. WiND 401 also has two characteristics: 403 (1) Hosts are normally isolated in L2 but not in L3. In fact, 404 many hosts are in the same subnet. In the rare cases where 405 hosts are not isolated in L2, e.g. because there is an 406 bridge between the hosts and the router, then some ND issues 407 like on-link security issues may happen, and additional 408 solutions will be needed to address those issues. 409 (2) The first-hop router maintains some state information across 410 reboots, e.g. host's address registration result including 411 IPv6 address to link layer address binding. The router also 412 uses such state information to maintain some controls over 413 the hosts, e.g. which host wins when there is an address 414 contention. 416 RFC8273 solves certain ND issues but not all. It has two 417 characteristics: 419 (1) Hosts are isolated in L3 in their own subnet, but RFC8273 420 does not specify whether hosts should also be isolated in 421 L2. If hosts are also isolated in L2, all ND issues will be 422 prevented. 423 (2) The first-hop router maintains some state information across 424 reboots, e.g. prefix-host binding. The router also maintains 425 some controls over the hosts, e.g. which prefix a host gets. 427 SAVI, RA-Guard, RA-Guard+ and GRAND solve specific ND issues. They 428 have two characteristics: 430 (1) These solution make no assumptions on isolation of hosts in 431 L2 or L3. They just solve the ND issues that they are 432 designed to solve. 433 (2) SAVI maintains some state information at the Ethernet switch 434 between the hosts and the first-hop router(s). Such states 435 are learned dynamically from packet snooping, or configured 436 manually. The Ethernet switch uses such state information to 437 control the hosts, e.g., RAs are not allowed from the hosts. 439 An insight can be learned from observing ND practices in these 440 existing IPv6 first-hop deployments. That is, isolating hosts in L2 441 and L3 can be effective in preventing ND issues. But isolating hosts 442 in L2 and L3 also has a price to pay. That is, because hosts are 443 isolated and cannot directly coordinate with each other, the router 444 must have new functionality to coordinate on behalf of the hosts, 445 e.g. to be the arbitrator when there is an address contention. In 446 order to do so, the router will also need to maintain some state 447 information, e.g. IP address-link layer address binding for each 448 host. This insight can be used to guide future ND deployments. 450 3. Isolating Hosts in L2 and L3 to Simplify ND Deployments 452 3.1. Applicability of Host Isolation in L2 and L3 454 This section describes how to isolate hosts in L2 and L3, and the 455 advantages and disadvantages of doing so. 457 Isolating hosts in L2 can be done by: (1) putting a host in a P2P 458 link with the router, or (2) using private VLAN [PVLAN], or split 459 horizon [TR177], or wireless isolation [W-Iso] on multi-access 460 medium to prevent hosts from communicating with each other. These 461 are a matter of device configuration so it can usually be done as 462 long as the devices support these isolating features. 464 Isolating hosts in L2 is different from setting ND Prefix 465 Information Option (PIO) L-bit=0. In the former, multicast messages 466 from a host will not reach other hosts in the same L2 broadcast 467 domain. In the latter, a host will not do address resolution for 468 other hosts with that prefix, but multicast messages from the host 469 will be mapped into L2 broadcast, and will reach other hosts in the 470 same L2 broadcast domain. 472 When hosts are isolated in L2, DAD messages can only reach the 473 router but not other hosts. Therefore, the router must act to 474 prevent 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 From the analysis above, it is clear that L2 isolation alone is not 500 advantageous. The benefits are relatively small while the costs are 501 relatively high. Therefore, L2 isolation is better used with 502 something else, e.g. L3 isolation or some specially designed 503 solutions like WiND. 505 The known solutions supporting host isolation in L2 include WiND, 506 and in more special cases (i.e. with both L2 and L3 isolation), 507 MBBv6 and FBBv6. 509 Host isolation in L3 (i.e. Unique Prefix Per Host, or UPPH) can be 510 done either with [DHCPv6], where the prefix can be of any length 511 supported by DHCPv6, or with SLAAC as specified in RFC8273, where 512 the prefix must be /64 or shorter. If [P2Peth] is progressed, it can 513 provide another solution. 515 In order to isolate hosts in L3, the router must be able to assign a 516 unique prefix to each host and keep track of the prefix-host link 517 layer address binding. This will be referred to as "UPPH support" 518 later in this document. This may be achieved by some mechanism that 519 RFC8273 alluded to but did not specify, or by some other mechanisms 520 if DHCPv6 is used [TR177]. Note that with SLAAC/RFC8273, such router 521 implementation exist [8273D], while with DHCPv6, FBBv6-capable BNG 522 is one of such implementations. 524 The advantages of isolating hosts in L3 are: 526 o Downstream Multicast, DAD-unreliable, on-demand NCE installation 527 and off-link /64 scan issues are prevented. 529 o It is the only way for the router to do subscriber management on 530 the hosts in a SLAAC environment. Imagine a public Wi-Fi scenario 531 where the mobile UEs only support SLAAC. If the router does not 532 give each UE a unique prefix and keep track of UE-prefix binding, 533 network administrators do not know which IPv6 address corresponds 534 to which UE, because each UE picks its own IID and uses the same 535 prefix. Therefore, network administrators cannot keep track of 536 which UE did what. This would be unacceptable from an operation 537 perspective. 539 The disadvantages of isolating hosts in L3 are: 541 o The routers must support new functionality: "UPPH support". 543 o Upstream multicast and on-link security issues can happen, unless 544 the hosts are also isolated in L2 546 o Many prefixes will be needed instead of just one. But this 547 disadvantage may not as severe as it appears. After all, 3GPP has 548 given every mobile UE a /64 [RFC6459], and BBF has given every 549 routed RG a /56 with DHCPv6 PD [TR177]. Outside of MBB, FBB and 550 IoT, not many scenarios have a large number of hosts. Giving each 551 host a /64 prefix may not be as deficient as it appears. 553 The known solutions supporting host isolation in L3 include RFC8273, 554 and in more special cases, MBBv6 and FBBv6. 556 Careful analysis of the advantages and disadvantages of L2 isolation 557 and L3 isolation will reveal that they are synergetic. When they 558 are done together, the advantages are: 560 o All ND issues are prevented. 562 o It provides a way for the router to do subscriber management on 563 the hosts in a SLAAC environment. 565 o DAD Proxy needed for L2 isolation is no longer needed, because 566 with unique prefix per host, GUA cannot be duplicate. For link 567 local address, since each subnet has only one host, there is no 568 possibility of duplication. A duplicate link local address may 569 exist in another subnet but that does not matter. Therefore, 570 there is no need for DAD Proxy to prevent duplicate GUA/LLA 571 addresses. 573 The disadvantages are: 575 o The routers must support new functionality: "UPPH support" . 577 o Many prefixes will be needed instead of just one. 579 o All host communication must go through the router. In a high 580 performance environment, the router may become the bottleneck. 582 o Services relying on multicast, e.g. mDNS, will not work, unless 583 the router can provide multicast proxy. 585 o There is additional work (e.g. PVLAN, split horizon or wireless 586 isolation) to isolate hosts in L2 in multi-access media, but this 587 is small amount of work. 589 The known solutions supporting host isolation in L2 and L3 include 590 RFC8273, MBBv6 and FBBv6. 592 3.2. Deployment Guidelines 594 Given the applicability analysis in Section 3.1, network 595 administrators can decide where to use which isolation option. Note 596 that in all the following steps, if DHCPv6 (IA_NA or PD) is 597 supported and desired, use DHCPv6 to assign address prefix, as it 598 may provide more prefix length flexibility. Otherwise, use SLAAC as 599 SLAAC is more widely supported. 601 1. If isolating hosts in both L2 and L3 is desirable and feasible: 603 Based on the applicability discussion in Section 3.1, the 604 scenarios here likely have some or all of the following 605 characteristics: (1) It is a public access environment where 606 subscriber management is needed; (2) Many ND issues can happen and 607 will require solutions. This is why it is desirable to prevent as 608 many issues as possible, to simplify the deployment; (3) Neither 609 high performance communication nor multicast service discovery is 610 applicable here. 612 With suitable "UPPH support", all the ND issues will be prevented. 613 Some possible "UPPH support" solutions are: 615 a) If the deployment scenario is MBB or FBB, then MBBv6 or FBBv6 616 can be used. 618 b) Otherwise, use a RFC8273 implementation (using SLAAC) to 619 realize "UPPH support". Note that this is a special use case 620 of RFC8273 where each host is not only given a unique prefix, 621 but also isolated from other hosts in L2. 623 2. Otherwise, if isolating hosts in L2 but not in L3 is considered 624 appropriate: 626 In this scenario, hosts are in different links but in the same 627 subnet. This architecture is called Multi-Link SubNet (MLSN). So 628 far only WiND and [OMNI] support MLSN. But OMNI is not widely 629 supported so WiND is the only solution available. Therefore, the 630 scenario here is most likely one that WiND is suitable for, e.g. 632 Low-power and Lossy Networks (LLNs). Because WiND has more 633 functionalities than DAD Proxy (required by L2 host isolation), 634 e.g. proactively address registration, WiND prevents all ND 635 issues. 637 3. Otherwise, if isolating hosts in L3 but not in L2 is considered 638 appropriate: 640 Based on the applicability discussion in Section 3.1, the 641 scenarios here likely have the following characteristics: (1) 642 Subscriber management is needed. This is likely a public access 643 scenario. (2) Upstream multicast is needed or cannot be avoided 644 (otherwise L2 host isolation would have been selected to prevent 645 more issues), e.g. for service discovery. RFC8273 can be used as 646 the solution here. On-link security is not prevented in this case. 647 Because this is a public access scenario, SAVI/RA-Guard/RA-Guard+ 648 may be needed to address the on-link security issue. 650 4. Otherwise, no isolation in L2 or L3 is desired or feasible. 652 The scenarios here likely have the following characteristics: (1) 653 It is a private environment, because subscriber management is not 654 needed. As such, on-link security is not a big concern. (2) Either 655 multicast service is needed, or this is a high performance 656 scenario, because L2 host isolation is not desired. Either way, 657 multicast and DAD-unreliable are not a concern. Normal ND can be 658 used as the solution. Off-link /64 scan and on-demand NCE 659 installation are the two issues left. Off-link /64 scan issue can 660 be handled by rate limiting or unused-address filtering. If this 661 is indeed a high performance environment, e.g. a DC network, GRAND 662 can be used to enable proactive NCE installation. 664 In short, the guidelines can be summarized as: if many of the ND 665 issues discussed in Section 3 are valid concerns and need to be 666 addressed, then isolate hosts in L2 and L3 to prevent the issues, 667 and use RFC8273. If the scenario is LLN, use WiND. But if the 668 scenario is a private environment where many ND issues are not real 669 concerns, then just use normal ND, and adds other solutions like 670 GRAND only when needed. Overall, these guidelines will likely result 671 in the simplest ND solution. 673 4. Impact of L2 and L3 Host Isolation to Other Components of IPv6 674 First-hop 676 The guidelines should simplify ND deployments. But will they 677 complicate other components of IPv6 first-hop? A preliminary impact 678 analysis is done in this section. 680 IPv6 first-hop consists of: 682 o The routers and the hosts, whose requirements & behaviors are 683 defined in [RFC8504]; 685 o Addressing scheme; 687 o The basic protocol suite: ND, SLAAC, DHCPv6, DNS, ICMPv6, MLD 688 v1/v2; 690 o Other extended protocols: mDNS. 692 The impact of host isolation in L2 and L3 to other components of 693 IPv6 first-hop comes from three parts: (1) the special topology 694 introduced by L2 host isolation; (2) the special addressing scheme 695 introduced by L3 host isolation (i.e. unique prefix per host); (3) 696 the new functionalities introduced to the router, i.e. "DAD Proxy" 697 for L2 isolation and "UPPH support" for L3 isolation. (4) When WiND 698 is used, hosts must be changed to support proactive address 699 registration etc. This is a high requirement that can be considered 700 as complicating the IPv6 first-hops. But WiND is the only solution 701 in its applicable scenarios like LLNs. When there is no 702 alternative, there is no need to discuss whether the solution unduly 703 complicates other components of IPv6 first-hop. Therefore, WiND 704 will not be further discussed. Because DAD Proxy is only needed in 705 L2 but not L3 isolation, and this scenario uses WiND which already 706 provides DAD Proxy, DAD Proxy will not be further discussed either. 708 First, regarding the impact from the special topology: 710 Isolating hosts should only affect the protocols that rely on 711 multicast, i.e. ND, SLAAC and mDNS, but not the multicast protocols 712 themselves, i.e. MLD v1/v2. As discussed in Sections 2 and 3, the 713 impact on ND and SLAAC are positive. The impact on mDNS can be 714 negative, if new functionality like "multicast proxy at router" has 715 to be introduced. But the guidelines give network administrators the 716 option not to isolate hosts at all. So if network administrators 717 choose to isolate, the benefit must outweigh the cost. 719 Second, regarding the impact from the special addressing scheme: 721 IPv6 first-hop should allow any addressing scheme. Other than using 722 more prefixes, it is not clear that unique prefix per host 723 complicates addressing scheme in any way. After all, unique prefix 724 per host is already widely in use in MBBv6 and FBBv6 deployments. 726 Third, regarding the impact of new router functionality "UPPH 727 support": 729 The impact of "UPPH support" with RFC8273 using SLAAC has been 730 discussed in [8273D] before RFC8273 became an RFC. The following 731 concerns had been raised: 733 . RFC8273 makes the router stateful; 734 . How to reclaim unused prefix is not specified; 735 . If there are multiple first-hop routers, how the solution works 736 is unspecified: (1) do they assign prefixes to hosts 737 independently? (2) do they need to sync up with each other? 738 . Resiliency of SLAAC may be reduced as a result of the increased 739 state at the router, i.e. the prefix-host binding. 741 Given that RFC8273 became an RFC, the rough consensus may have been 742 its benefit outweighs the cost. Because MBBv6 and FBBv6 also support 743 UPPH and are widely deployed, the impact of "UPPH support" is likely 744 manageable. 746 All things considered, it appears that isolating hosts in L2 and L3 747 can simplify ND without unduly complicating other components of IPv6 748 first-hop. 750 5. Applying the Guidelines to Real World Scenarios 752 The guidelines are intended for future IPv6 first-hop deployments. 753 But if we test the guidelines on well-known IPv6 scenarios to find 754 the solutions, the results will be as follows: 756 o MBB and FBB will end at Step 1.a: isolating hosts in L2 and L3, 757 with MBBv6 as the solution with SLAAC and FBBv6 as the solution 758 with DHCPv6, respectively; 760 o Public Wi-Fi network will end at Step 1.b: isolating hosts in L2 761 and L3, with RFC8273 as the solution with SLAAC, since the hosts 762 here may be mobile UEs that do not support DHCPv6. Note that in 763 Wi-Fi with the Infrastructure Mode [WiFi-inf], each host (i.e. 764 STA) communicates only with the Access Point (AP). With wireless 765 isolation, every host can only communicate with the AP (and the 766 router if the AP is not a router), not directly with other hosts. 767 This is how L2 isolation can be achieved in this scenario. If L2 768 isolation is not done, then public Wi-Fi will end at Step 3. 769 SAVI/RA-Guard/RA-Guard+ may be needed to address the on-link 770 security issue. 772 o Low-power and Lossy Networks (LLNs) will end at Step 2: isolating 773 hosts in L2 but not L3, with WiND as the solution with SLAAC. 774 Note that although WiND did not mandate L2 isolation, WiND works 775 better when hosts are isolated in L2. Otherwise, additional 776 mechanisms may be needed to address on-link security issues. 778 o High speed DC Networks will end at Step 4: using normal ND with 779 GRAND without host isolation in L2 or L3. SAVI, RA-Guard and RA- 780 Guard+ may not be needed as high physical access security is 781 likely maintained. 783 o Common enterprise LANs with mixed Ethernet and Wi-Fi (not DC 784 networks) will end at: 786 o If security is a concern to justify host isolations: 788 . Step 1.b: isolating hosts in L2 and L3, with RFC8273 as 789 the solution with SLAAC;. 791 o If security is not a concern to justify host isolations: 793 . Step 4: using normal ND with no special host isolation. 794 GRAND and SAVI, RA-Guard and RA-Guard+ may not be 795 needed. 797 o [HomeNet] will end at Step 4: using normal ND with no special 798 host isolation. GRAND and SAVI, RA-Guard and RA-Guard+ are not 799 needed. 801 These results match current practices in reality. This validates the 802 guidelines to some extent. 804 6. Security Considerations 806 This document provide guidelines on how and where to isolate hosts 807 in L2 and L3 to prevent ND issues, and how to select existing 808 solutions for the remaining issues. When a solution is selected, 809 the security considerations of that solution apply. This document 810 does not introduce any new mechanisms. Therefore, it does not 811 introduce new security issues. 813 7. IANA Considerations 815 This document has no request to IANA. 817 8. References 819 8.1. Informative References 821 [8273D] Discussion on the pros and cons of RFC8273, 822 https://mailarchive.ietf.org/arch/msg/v6ops/M47lN8lyXaWVcx 823 8nitvkxMfbGNA/ 825 [CGA] T. Aura, "Cryptographically Generated Addresses (CGA)" , 826 RFC3972 828 [DHCPv6] T. Mrugalski M. Siodelski B. Volz A. Yourtchenko M. 829 Richardson S. Jiang T. Lemon T. Winters, "Dynamic Host 830 Configuration Protocol for IPv6 (DHCPv6)", RFC 8415. 832 [GRAND] J. Linkova, "Gratuitous Neighbor Discovery: Creating 833 Neighbor Cache Entries on First-Hop Routers", 834 https://datatracker.ietf.org/doc/html/draft-ietf-6man- 835 grand-07 837 [HomeNet] T. Chown, J. Arkko, A. Brandt, O. Troan, J. Weil, "IPv6 838 Home Networking Architecture Principles", RFC 7368, DOI 839 10.17487/RFC7368, October 2014, . 842 [mDNS] S. Cheshire, M. Krochmal, "Multicast DNS", RFC 6762. 844 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 845 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 846 DOI 10.17487/RFC4861, September 2007, . 849 [OMNI] F. Templin, A. Whyman, "Transmission of IP Packets over 850 Overlay Multilink Network (OMNI) Interfaces", 851 https://www.ietf.org/archive/id/draft-templin-6man-omni- 852 interface-99.txt 854 [OPSECv27] E. Vyncke, K. Chittimaneni, M. Kaeo, E. Rey, "Operational 855 Security Considerations for IPv6 Networks", 856 https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6- 857 27 [PVLAN] https://en.wikipedia.org/wiki/Private_VLAN 859 [P2Peth] O. Troan, "IP Point to Point Ethernet Subnet Model", 860 https://datatracker.ietf.org/doc/draft-troan-6man-p2p- 861 ethernet/ 863 [RA-Guard] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. 864 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 865 10.17487/RFC6105, February 2011, . 868 [RA-Guard+] F. Gont, "Implementation Advice for IPv6 Router 869 Advertisement Guard (RA-Guard)", RFC 7113, DOI 870 10.17487/RFC7113, February 2014, . 873 [RFC3756] P. Nikander, J. Kempf, E. Nordmark, "IPv6 Neighbor 874 Discovery (ND) Trust Models and Threats", RFC 3756. 876 [RFC5072] S. Varada, D. Haskins, E. Allen, "IP Version 6 over PPP", 877 RFC 5072 879 [RFC6459] J. Korhonen, J. Soininen, B. Patil, T. Savolainen, G. 880 Bajko, K. Iisakkila, "IPv6 in 3rd Generation Partnership 881 Project (3GPP) Evolved Packet System (EPS)", RFC 6459. 883 [RFC6583] I. Gashinsky, J. Jaeggli, W. Kumari, "Operational Neighbor 884 Discovery Problems", RFC 6583. 886 [RFC6775] Z. Shelby, S. Chakrabarti, E. Nordmark, C. Bormann, 887 "Neighbor Discovery Optimization for IPv6 over Low-Power 888 Wireless Personal Area Networks (6LoWPANs)", RFC 6775. 890 [RFC6957] F. Costa, J-M. Combes, X. Pougnard, H. Li, "Duplicate 891 Address Detection Proxy", RFC 6957 893 [RFC7066] J. Korhonen, J. Arkko, T. Savolainen, S. Krishnan, "IPv6 894 for Third Generation Partnership Project (3GPP) Cellular 895 Hosts", RFC 7066. 897 [RFC7102] JP. Vasseur, "Terms Used in Routing for Low-Power and 898 Lossy Networks", RFC 7102. 900 [RFC7668] J. Nieminen, T. Savolainen, M. Isomaki, B. Patil, Z. 901 Shelby, C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", 902 RFC7668. 904 [RFC8273] J. Brzozowski, G. Van de Velde, "Unique IPv6 Prefix per 905 Host", RFC 8273. 907 [RFC8504] T. Chown, J. Loughney, T. Winters, "IPv6 Node 908 Requirements", RFC 8504, January 2019, . 911 [RFC8505] P. Thubert, E. Nordmark, S. Chakrabarti, C. Perkins, 912 "Registration Extensions for IPv6 over Low-Power Wireless 913 Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 914 8505. 916 [RFC8928] P. Thubert, B. Sarikaya, M. Sethi, R. Struik, "Address- 917 Protected Neighbor Discovery for Low-Power and Lossy 918 Networks", RFC 8928. 920 [RFC8929] P. Thubert, C.E. Perkins, E. Levy-Abegnoli, "IPv6 Backbone 921 Router", RFC 8929. 923 [RIPE IPv6 security] RIPE NCC, "IPv6 Security Training Course", 924 https://www.ripe.net/support/training/material/ipv6- 925 security/ipv6security-slides.pdf 927 [SAVI] J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt, "Source 928 Address Validation Improvement (SAVI) Framework", RFC 7039 930 [SeND] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor 931 Discovery (SEND)", RFC3971 933 [SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 934 Address Autoconfiguration", RFC 4862, DOI 935 10.17487/RFC4862, September 2007, . 938 [TR177] S. Ooghe, B. Varga, W. Dec, D. Allan, "IPv6 in the context 939 of TR-101", Broadband Forum, TR-177. 941 [WiFi-inf] Wi-Fi Infrastructure Mode, 942 https://www.howtogeek.com/180649/htg-explains-whats-the- 943 difference-between-ad-hoc-and-infrastructure-mode/ 945 [W-Iso] Wireless Isolation, https://www.quora.com/What-is- 946 wireless-isolation 948 9. Acknowledgments 950 The authors would like to thank Eduard Vasilenko, Pascal Thubert, 951 and Ole Troan for the discussion and input. 953 Authors' Addresses 955 XiPeng Xiao 956 Huawei Technologies 957 Hansaallee 205, 40549 Dusseldorf, Germany 959 Email: xipengxiao@huawei.com 961 Eduard Metz 962 KPN N.V. 963 Maanplein 55, 2516CK The Hague, The Netherlands 965 Email: eduard.metz@kpn.com 967 Gyan Mishra 968 Verizon Inc. 970 Email: gyan.s.mishra@verizon.com