idnits 2.17.1 draft-farmer-6man-routing-64-02.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 (Using the creation date from RFC4291, updated by this document, for RFC5378 checks: 2003-10-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 6, 2019) is 1930 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SLAAC' is mentioned on line 304, but not defined == Missing Reference: 'IPv6 ND' is mentioned on line 316, but not defined ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) == Outdated reference: A later version (-10) exists of draft-bourbaki-6man-classless-ipv6-04 -- Obsolete informational reference (is this intentional?): RFC 1884 (Obsoleted by RFC 2373) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group D. Farmer 3 Internet-Draft Univ. of Minnesota 4 Updates: 4291 (if approved) January 6, 2019 5 Intended status: Standards Track 6 Expires: July 10, 2019 8 IPv6 Routing and its Relationship to 9 the 64-bit Boundary in the IPv6 Addressing Architecture 10 draft-farmer-6man-routing-64-02 12 Abstract 14 There is a common misconception that the IPv6 Addressing Architecture 15 requires the use of only /64 subnet prefixes for subnet routing. 16 This document clarifies the characterization of the relationship 17 between IPv6 routing and the 64 bit boundary, which is that of a 18 recommendation for the use of /64 subnet prefixes for subnet routing 19 in most circumstances, not a requirement for such. To further 20 clarify this relationship, the document also provides operational 21 guidance for the configuration of subnet prefixes and updates 22 RFC 4291 accordingly. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 10, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Two Forms of Subnet Prefixes and Interface Identifiers . 3 62 2.2. How the Two Forms are Used . . . . . . . . . . . . . . . 6 63 2.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 8 64 3. Updates to RFC 4291 . . . . . . . . . . . . . . . . . . . . . 9 65 4. Operational Guidance for the Configuration of Subnet Prefixes 9 66 4.1. Subnet Prefixes Other Than /64 . . . . . . . . . . . . . 11 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 70 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 13 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 73 9.2. Informative References . . . . . . . . . . . . . . . . . 15 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 The IPv6 Addressing Architecture [RFC4291] defines the relationship 79 between subnet prefixes and interface identifiers. Furthermore, it 80 effectively defines two forms of subnet prefixes and interface 81 identifiers, a general form and a standard form of each, and an 82 additional third form of interface identifiers, the Modified EUI-64 83 format. 85 In their general form subnet prefixes have any length 0 to 128 bits, 86 inclusive, and interface identifiers are independent of any specific 87 length. IPv6 routing is based on these general forms, including both 88 subnet routing and on-link determination. 90 When the IPv6 Addressing Architecture also defines interface 91 identifiers as being 64 bits in length, and historically constructed 92 in Modified EUI 64 format, it is effectively creating a distinct 93 standard form of interface identifiers. Which also creates a 94 distinct standard form of subnet prefixes that are 64 bits in length 95 as well. Autonomous address-configuration and most other aspects of 96 the IPv6 specifications assume or depend on these standard forms. 98 Additionally, most unicast addresses are intended to be formatted and 99 assigned based on these standard forms. 101 These two forms of subnet prefixes and interface identifiers are 102 currently not sufficiently distinguished in the IPv6 Addressing 103 Architecture allowing them to be confused and conflated, creating the 104 common misconception that it requires the use of only /64 subnet 105 prefixes for subnet routing. This confusion is compounded by a lack 106 of definitive operational guidance for the configuration of subnet 107 prefixes that would further clarify the controversy. 109 Although /64 subnet prefixes are required for autonomous address- 110 configuration and are most often configured for subnet routing, any 111 length subnet prefixes, 0 to 128 bits, inclusive, are valid for IPv6 112 routing, including both subnet routing and on-link determination. 113 Nevertheless, for consistency with the 64 bit boundary and most other 114 aspects of the IPv6 specifications, /64 subnet prefixes are 115 recommended for subnet routing in most circumstances. 117 This document clarifies the characterization of the relationship 118 between IPv6 routing and the 64-bit boundary, which is that of a 119 recommendation for the use of /64 subnet prefixes for subnet routing 120 in most circumstances, not a requirement for such. To further 121 clarify this relationship, the document also provides operational 122 guidance for the configuration of subnet prefixes and updates 123 RFC 4291 accordingly. 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in 130 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 2. Discussion 135 2.1. Two Forms of Subnet Prefixes and Interface Identifiers 137 The IPv6 Addressing Architecture [RFC4291], Section 2.5, paragraph 4, 138 and the diagram following it, define the structure of IPv6 unicast 139 addresses and the relationship between the general form of subnet 140 prefixes and interface identifiers. With the diagram implying at 141 least in this general form, that subnet prefixes have any length 142 between 0 and a 128 bits, inclusive. Further, it implies that the 143 general form of interface identifiers are independent of any specific 144 length and are defined only by the length of their associated subnet 145 prefix. 147 A slightly sophisticated host (but still rather simple) may 148 additionally be aware of subnet prefix(es) for the link(s) it is 149 attached to, where different addresses may have different values 150 for n: 152 | n bits | 128-n bits | 153 +------------------------------+-------------------------------+ 154 | subnet prefix | interface ID | 155 +------------------------------+-------------------------------+ 157 The idea that this paragraph is referring to a general form of subnet 158 prefixes and interface identifiers and they are independent of any 159 specific length is reinforced by the fact this text is unchanged from 160 the text in [RFC1884], Section 2.4. Where in this earlier revision 161 of the IPv6 Addressing Architecture, 48-bit interface identifiers 162 were expected to be common. 164 The IPv6 Addressing Architecture [RFC4291], Section 2.5.1, goes on to 165 further define additional properties of the general form of interface 166 identifiers, that are independent of any specific length. Simply 167 put, in their general form interface identifiers are the right-hand 168 portion of IPv6 unicast addresses that uniquely identifies the 169 interface of a node within a subnet prefix on a link, regardless of 170 the length of the subnet prefix, which in turn are the left-hand 171 portion of IPv6 unicast addresses. 173 Interface identifiers in IPv6 unicast addresses are used to 174 identify interfaces on a link. They are required to be unique 175 within a subnet prefix. It is recommended that the same interface 176 identifier not be assigned to different nodes on a link. They may 177 also be unique over a broader scope. In some cases, an 178 interface's identifier will be derived directly from that 179 interface's link-layer address. The same interface identifier may 180 be used on multiple interfaces on a single node, as long as they 181 are attached to different subnets. 183 Note that the uniqueness of interface identifiers is independent 184 of the uniqueness of IPv6 addresses. For example, a Global 185 Unicast address may be created with a local scope interface 186 identifier and a Link-Local address may be created with a 187 universal scope interface identifier. 189 However, when the IPv6 Addressing Architecture [RFC4291], 190 Section 2.5.1, paragraph 3, defines the length of interface 191 identifiers as 64 bits, it is also effectively creating a distinct 192 standard form of interface identifiers, differentiated from the 193 general form which is independent of any specific length. 195 For all unicast addresses, except those that start with the binary 196 value 000, Interface IDs are required to be 64 bits long and to be 197 constructed in Modified EUI-64 format. 199 [RFC7136] updates and [RFC8064] effectively deprecates the 200 requirement that interface identifiers are constructed in Modified 201 EUI-64 format. However, the original RFC 4291 version of the text is 202 quoted above as it helps to explain and develop the idea that a 203 distinct standard form of interface identifiers is being created as 204 opposed to merely defining additional properties of all interface 205 identifiers in general. 207 Several of the paragraphs following the above, discuss the details of 208 "Modified EUI-64 format-based interface identifiers", seeming to 209 imply that not all interface identifiers are in this format and 210 distinguishing them from not only general form interface identifiers 211 but even from other standard form interface identifiers that are 64 212 bits in length. 214 Furthermore, the IPv6 Addressing Architecture [RFC4291], 215 Section 2.5.4, paragraph 2, itself effectively distinguishes between 216 the standard and general forms of interface identifiers based on if 217 the unicast address starts with the binary value 000. 219 All Global Unicast addresses other than those that start with 220 binary 000 have a 64-bit interface ID field (i.e., n + m = 64), 221 formatted as described in Section 2.5.1. Global Unicast addresses 222 that start with binary 000 have no such constraint on the size or 223 structure of the interface ID field. 225 Based on the above, the idea that a 64-bit length and the Modified 226 EUI-64 format are fundamental properties of all interface identifiers 227 in general, seems like a stretch and a more logical interpretation is 228 that interface identifiers come in multiple forms, most with a 229 standard 64-bit length, many more specifically in Modified EUI-64 230 format, and others are independent of any specific length. This 231 interpretation, at least as it applies to the Modified EUI-64 format, 232 is consistent with the updates in [RFC7136]. 234 Thus, when the IPv6 Addressing Architecture defines interface 235 identifiers as being 64 bits in length, it is effectively creating a 236 distinct standard form of interface identifiers differentiated from 237 the general form of interface identifiers which are independent of 238 any specific length. 240 Finally, as a result of the tightly coupled relationship between 241 subnet prefixes and interface identifiers, creating a standard form 242 of interface identifiers also implies the creation of a standard form 243 of subnet prefixes that are also 64 bits in length. 245 2.2. How the Two Forms are Used 247 Many aspects of the IPv6 specifications are based or assume on these 248 standard form of subnet prefixes and interface identifiers. Most 249 notably, Stateless Address Autoconfiguration (SLAAC) [RFC4862] which 250 autonomously configures IPv6 addresses that are constructed by 251 generating standard form interface identifiers that are combined with 252 standard form subnet prefixes. These subnet prefixes are advertised 253 by routers and are learned by hosts through IPv6 ND RA messages 254 containing PIOs with the autonomous address-configuration (A) flag 255 set. 257 As discussed in SLAAC [RFC4862], Section 5.5.3, bullet d, PIOs with 258 the A flag set are validated against a single interface identifier 259 length. However, SLAAC itself does not define the interface 260 identifier length used or assume it is 64 bits in length. SLAAC 261 utilizes the interface identifier length defined in separate 262 link-type specific documents that are intended to be consistent with 263 the standard form interface identifier specified in the IPv6 264 Addressing Architecture. 266 If the sum of the prefix length and interface identifier length 267 does not equal 128 bits, the Prefix Information option MUST be 268 ignored. An implementation MAY wish to log a system management 269 error in this case. The length of the interface identifier is 270 defined in a separate link-type specific document, which should 271 also be consistent with the address architecture... 273 Furthermore, there are currently no IPv6 link-type specific documents 274 that specify an interface identifier length other than 64 bits. 275 Therefore, SLAAC effectively requires standard form interface 276 identifiers that are 64 bits in length, reinforcing the idea that 277 autonomous address-configuration is based on standard form subnet 278 prefixes and interface identifiers. 280 Beyond SLAAC, [RFC7421], Section 4.1, lists many other aspects of the 281 IPv6 specifications that assume or depend on the standard form of 282 subnet prefixes and interface identifiers. Furthermore, the IPv6 283 Addressing Architecture itself intends that most unicast addresses 284 and all Link-Local addresses are formatted and assigned based on 285 these standard forms of subnet prefixes and interface identifiers. 286 Finally, a rationale for using a single standard form interface 287 identifier length is also provided in RFC 7421, Section 2. 289 However, as discussed in IPv6 ND [RFC4861], Section 5.2, and further 290 clarified in the IPv6 Subnet Model [RFC5942], subnet routing and 291 on-link determination depend on the general form subnet prefixes to 292 determine the addresses that are deliverable using a node's attached 293 interfaces. These subnet prefixes are normally advertised by routers 294 and learned by hosts through ND RA messages containing PIOs but with 295 the on-link (L) flag set, or through the manual configuration of 296 on-link prefixes directly on hosts and routers. 298 Although unlike SLAAC that validates PIOs with the A flag set, as 299 discussed in IPv6 ND [RFC4861], Section 6.3.4, PIOs with the L flag 300 set, or manually configured on-link prefixes, are not validated 301 against any particular subnet prefix length or interface identifier 302 length. 304 ...[SLAAC] may impose certain restrictions on the prefix length 305 for address configuration purposes. Therefore, the prefix might 306 be rejected by [the SLAAC] implementation in the host. However, 307 the prefix length is still valid for on-link determination when 308 combined with other flags in the prefix option. 310 The fact that PIOs with the L flag set are not validated is confirmed 311 by SLAAC [RFC4862], Section 5.5.3, bullet d, where it says; 313 It should be noted, however, that this does not mean the 314 advertised prefix length is meaningless. In fact, the advertised 315 length has non-trivial meaning for on-link determination in 316 [IPv6 ND]... 318 Therefore, these subnet prefixes have any length 0 to 128 bits, 319 inclusive, reinforcing the idea that subnet routing and on-link 320 determination are based on the general form of subnet prefixes. This 321 idea is also discussed in the IPv6 Addressing Architecture [RFC4291], 322 Section 2.5, paragraph 1, itself, which says; 324 IPv6 unicast addresses are aggregatable with prefixes of arbitrary 325 bit-length, similar to IPv4 addresses under Classless Inter-Domain 326 Routing. 328 And, this idea is further reinforced and clarified by BCP 198 329 [RFC7608] which says; 331 Decision-making processes for forwarding MUST NOT restrict the 332 length of IPv6 prefixes by design. In particular, forwarding 333 processes MUST be designed to process prefixes of any length up to 334 /128, by increments of 1. 336 2.3. Conclusion 338 As discussed above in Section 2.2 on-link determination and 339 autonomous address-configuration are logically separate functions in 340 IPv6, that are specified in separate documents, IPv6 ND and SLAAC 341 respectively, each with distinct and seemingly contradictory notions 342 about the length of subnet prefixes. It is tempting to try to 343 resolve this contradiction by applying the IPv6 Addressing 344 Architecture's requirement for the use of 64-bit interface 345 identifiers to subnet routing and on-link determination. However, 346 this requirement as implemented in the IPv6 protocol specifications 347 does not directly apply to IPv6 routing, including subnet routing and 348 on-link determination, and is inconsistent with not only statements 349 in IPv6 ND, but in both SLAAC and the IPv6 Addressing Architecture 350 themselves, as well as BCP 198, all quoted above in Section 2.2. 352 Notwithstanding the above and despite the fact that IPv6 routing, 353 including both subnet routing and on-link determination, is based on 354 the general form of subnet prefixes, with any length 0 to 128 bits, 355 inclusive, being valid, most other aspects of the IPv6 356 specifications, especially SLAAC, assume or depend on the standard 357 form of subnet prefixes and interface identifiers, both 64 bits in 358 length. As a consequence, when standard form subnet prefixes are not 359 also configured for subnet routing, there is a risk some IPv6 360 features will produce unpredictable results and others will not work 361 outright. [RFC7421], Section 4.2, discusses some of these 362 situations. 364 Therefore, for consistency with the 64-bit boundary and most other 365 aspects of the IPv6 specifications, but despite the requirement for 366 64-bit interface identifiers not directly applying, standard form 367 subnet prefixes, that is /64 subnet prefixes, are RECOMMENDED for 368 subnet routing in most circumstances. The formal exceptions to this 369 recommendation are subnet prefixes that begin with the binary value 370 000 and inter-router point-to-point links with 127-bit prefixes 371 [RFC6164]. 373 In conclusion, the proper characterization of the relationship 374 between IPv6 routing and the 64-bit boundary in the IPv6 Addressing 375 Architecture is that of a recommendation for the use of /64 subnet 376 prefixes for subnet routing in most circumstances, not a requirement 377 for such. To further clarify this relationship, the remainder of 378 this document updates RFC 4291 based on this discussion and provides 379 operational guidance for the configuration of subnet prefixes 380 consistent with this recommendation. 382 3. Updates to RFC 4291 384 Based on the discussion in Section 2, the IPv6 Addressing 385 Architecture [RFC4291], Section 2.5.1, paragraph 3, is updated by 386 replacing it with the following; 388 Standard Interface Identifiers are REQUIRED to be 64 bits long 389 except if the first three bits of the unicast address are 000. 390 The rationale for using for a single Standard Interface Identifier 391 length can be found in [RFC7421]. The Standard Interface 392 Identifier length only implies a recommendation as to the subnet 393 prefix lengths that are valid for routing in most circumstances. 395 The term "Interface IDs" has been changed to "Standard Interface 396 Identifiers" to distinguish the standard form of interface 397 identifiers from the general form that is independent of any specific 398 length, per [RFC8064] the requirement that standard form interface 399 identifiers are constructed in Modified EUI-64 format has been 400 removed, and the sentence has also been rearranged. Two additional 401 sentences have been added to the paragraph; the first, referring to 402 RFC 7421 for the rationale for using a single Standard Interface 403 Identifier length, and the second, clarifying the relationship 404 between IPv6 routing and the 64-bit boundary without removing the 405 requirement for other aspects of IPv6, especially SLAAC, to use 406 64-bit interface identifiers. 408 4. Operational Guidance for the Configuration of Subnet Prefixes 410 Unlike IPv4 where there is a single subnet mask parameter configured 411 both on hosts and routers, with the two aspects of a subnet, address 412 assignment and on-link determination, tightly coupled together; in 413 IPv6 these two aspects of a subnet are split into two independent 414 parameters that are configured together or separately and normally 415 only configured on routers. These two parameters are defined and 416 discussed in detail by IPv6 ND [RFC4861] and further clarified in the 417 IPv6 Subnet Model [RFC5942]. Briefly, as discussed in Section 2.2, 418 these two parameters are normally advertised by routers and learned 419 by hosts through IPv6 ND RA messages containing PIOs with, either or 420 both, the autonomous address-configuration (A) flag or the on-link 421 (L) flag set, or through the manual configuration of on-link prefixes 422 directly on hosts. This Section provides operational guidance for 423 the configuration of these parameters by both means. 425 As discussed in the IPv6 Node Requirements [RFC6434], Section 5.9, 426 all hosts are required to support SLAAC for the configuration of IPv6 427 unicast addresses, whereas hosts are not required to support other 428 mechanisms, such as the Dynamic Host Configuration Protocol for IPv6 429 (DHCPv6) [RFC8415] or even manual configuration. As a consequence, 430 unless IPv6 ND RA messages containing a PIO with the A flag set are 431 advertised on a link, it is possible that some hosts will not be able 432 to configure an IPv6 address for that link, other than a Link-Local 433 address, additional consequences for the security and privacy of IPv6 434 users are discussed in Section 6. Further, the most efficient way 435 for two hosts in the same subnet to communicate is directly between 436 each other on the common link between them, or in other words 437 on-link. Finally, as discussed in Section 2.2 and 2.3, /64 subnet 438 prefixes are required for SLAAC and recommended for subnet routing 439 and on-link determination in most circumstances. 441 Therefore, routers SHOULD be configured to send IPv6 ND RA messages 442 containing at least one /64 PIO with both the A and L flags set on 443 each of a router's links. Unless it is known that all host connected 444 to a link support an IPv6 address configuration mechanism other than 445 SLAAC and that mechanism has been configured for each host or direct 446 communication between hosts on the same subnet is not desired. 448 More operationally, when configuring these two parameters on a 449 router, /64 PIOs are REQUIRED for all PIOs with the A flag set. 450 Furthermore, /64 PIOs with both the A and L flags set are 451 RECOMMENDED. Finally, /64 PIOs are RECOMMENDED for all PIOs with the 452 L flag set and /64 on-link prefixes are RECOMMENDED when manually 453 configured on hosts and routers, except for subnet prefixes that 454 begin with the binary value 000 and inter-router point-to-point links 455 with 127-bit prefixes [RFC6164]. 457 Note: Typically when manually configuring an address on a host an 458 on-link prefix length may also be included. If not included, or 459 possibly if the prefix length is /128, this effectively signifies 460 that only an address is being manually configured on the interface 461 and no on-link prefix has been configured for the interface. 463 As recommended above, /64 PIOs with both the A and L flags set are 464 most often configured in practice; this is the default behavior for 465 many routers. However, /64 PIOs with only the A or L flag set, or 466 the manual configuration of /64 on-link prefixes on hosts, are 467 consistent with the IPv6 Addressing Architecture and they simply 468 represent different configuration options for /64 subnet prefixes. 469 While these options are not as frequently used, they are still valid 470 configurations, and their use is considered normal practice under the 471 proper circumstances. If the A flag is not set, this means, SLAAC is 472 not used to configure addresses for hosts on the subnet. If the L 473 flag is not set, this means, none of the addresses for the subnet are 474 on-link from a hosts perspective and traffic is not sent directly to 475 other hosts, but all traffic is sent to a router first. Finally, if 476 hosts are manually configured with on-link prefixes, then a router is 477 not required on the link, at least for configuration purposes. 479 Note: regardless if a router advertises a PIO, with the A or L 480 flags set, the router itself MUST be configured with the on-link 481 prefixes for all subnets on all the links it is connected to, this 482 could be via manual configuration or another mechanism. Two, or 483 more, routers connected to the same link could have the same PIO 484 with different flags set, each PIO is evaluated separately for 485 each function, therefore effectively the sum of the flags across 486 all identical PIOs are used. Finally, a router MAY send an ND 487 Redirect message for an address for which a PIO with the L flag 488 set has not been advertised, any subsequent traffic for that 489 address will be sent directly to that host instead of the router 490 first. 492 4.1. Subnet Prefixes Other Than /64 494 In most circumstances, the use of subnet prefixes other than /64 are 495 inconsistent with the IPv6 Addressing Architecture, are generally 496 considered bad practice, and are NOT RECOMMENDED. Furthermore, 497 subnet prefixes other than /64 MUST NOT be used unless it is known 498 that all nodes on a link do not need any IPv6 features that depend on 499 /64 subnet prefixes or 64-bit Standard Interface Identifiers. 500 [RFC7421], Section 4.1, provides a non-exhaustive list of IPv6 501 features that depend on 64-bit Standard Interface Identifiers. 502 [RFC5375], Appendix B, discusses considerations for the use of subnet 503 prefixes other than /64, although some of the advice has been 504 obsoleted by [RFC6164] and [RFC7136]. 506 Using subnet prefixes other than /64 for links servicing general- 507 purpose end hosts seems like an especially bad idea, it is usually 508 difficult to predict what IPv6 features such hosts will need, 509 especially their future needs. Therefore it seems doubtful the above 510 conditions can be met for such hosts. Whereas more tightly- 511 controlled infrastructure such as routers or special-purpose servers 512 can have their needs better understood, and while still not 513 recommended, it seems plausible that the above conditions could be 514 met in their case. 516 Again more operationally, the configuration of PIOs of any length 517 other than /64, or the manual configuration of on-link prefixes other 518 than /64, are NOT RECOMMENDED except for subnet prefixes that begin 519 with the binary value 000 and inter-router point-to-point links with 520 127-bit prefixes [RFC6164]. Furthermore, PIOs of any length other 521 than /64 with the A flag set are invalid and a configuration error, 522 they will not result in the auto-configuration of an address. PIOs 523 of any length other than /64 with the L flag set, or the manual 524 configuration of on-link prefixes of any length other than /64, while 525 they are NOT RECOMMENDED in most circumstances, they are still valid 526 for routing. 528 Note: the combination a PIO of /65 or longer with the L flag set 529 and a covering /64 PIO with only the A flag set, configures a /64 530 subnet prefix but with only part of the subnet considered on-link 531 and the rest of the subnet not considered on-link. This 532 particular configuration, while technically valid, can be 533 operationally challenging and problematic. With this 534 configuration a host on the same link and subnet could behave 535 differently from another host on the same link and subnet, this 536 can be confusing and difficult to troubleshoot. Therefore in 537 practice, this configuration is best avoided. 539 5. IANA Considerations 541 This document includes no request to IANA. 543 6. Security Considerations 545 This document clarifies the relationship between IPv6 routing and the 546 64-bit boundary in the IPv6 Addressing Architecture. Further, it 547 provides operational guidance for the configuration of subnet 548 prefixes. This guidance and the clarifications provided are not 549 expected to introduce any new security considerations. 551 However, if there are not IPv6 ND RA messages advertised with at 552 least one /64 PIO with the A flag set on each link network, several 553 techniques that are intended to increase the security and privacy of 554 IPv6 users will be impacted negatively, specifically [RFC3972], 555 [RFC4941], and [RFC7217]. These techniques require the use of SLAAC, 556 hence the recommendation to configure /64 PIOs with the A flag set in 557 most circumstance. Further, the use of subnet prefixes longer than 558 /64 effectively creates smaller subnets making it more feasible to 559 perform IPv6 address scans. These and other related security and 560 privacy considerations are discussed in [RFC7707] and [RFC7721]. 562 Nevertheless, the use of smaller subnets can provide effective 563 mitigation for neighbor cache exhaustion issues as discussed in 564 [RFC6164] and [RFC6583]. The relative weights applied in these 565 trade-offs will vary from situation to situation. 567 7. Acknowledgments 569 This document was inspired by a series of discussions on the 6MAN and 570 the V6OPS working group mailing lists over several years, including 571 discussions around the following; [RFC7421], BCP 198 [RFC7608], 572 [I-D.jinmei-6man-prefix-clarify], [I-D.bourbaki-6man-classless-ipv6], 573 [I-D.jaeggli-v6ops-indefensible-nd], and 574 [I-D.farmer-6man-exceptions-64]. All revolving around the discussion 575 of [RFC4291bis] and its advancement to Internet Standard. 577 The author would like to thank Tatuya Jinmei and Ole Troan for 578 particularly useful comments on and discussion of 579 [I-D.farmer-6man-exceptions-64] that directly inspired the creation 580 of this document. 582 The author would like to thank the following, in alphabetical order, 583 for their contributions and comments: 585 Brian Carpenter 587 8. Change log [RFC Editor: Please remove] 589 draft-farmer-6man-routing-64-00, 2018-December-30: 591 *Original version. 593 draft-farmer-6man-routing-64-01, 2018-December-30: 595 *Fixed typos and other editorial changes 596 *Added missing "to" to the Title. 597 *Reduced some wordiness in the Abstract and Intro 598 *Corrected quote of RFC4291, Section 2.5, paragraph 4, the previous 599 was from RFC4291bis. 600 *Further developed the argument for standard form of interface 601 identifiers. 602 *Further clarified the intent of the change to RFC4291. 604 draft-farmer-6man-routing-64-02, 2019-January-6: 606 *Fixed typos, formatting and other editorial changes 607 *Further refined the argument for standard form of interface 608 identifiers. 609 *Added quote of RFC4291, Section 2.5, paragraph 1 in Section 2.2, 610 CIDR, etc... 611 *Further developed the conclusion, providing an argument why a 612 requirement is the incorrect relationship. 614 9. References 616 9.1. Normative References 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, 620 DOI 10.17487/RFC2119, March 1997, 621 . 623 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 624 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 625 2006, . 627 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 628 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 629 DOI 10.17487/RFC4861, September 2007, 630 . 632 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 633 Address Autoconfiguration", RFC 4862, 634 DOI 10.17487/RFC4862, September 2007, 635 . 637 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 638 Model: The Relationship between Links and Subnet 639 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 640 . 642 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 643 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 644 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 645 . 647 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 648 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 649 2011, . 651 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 652 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 653 February 2014, . 655 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 656 Length Recommendation for Forwarding", BCP 198, RFC 7608, 657 DOI 10.17487/RFC7608, July 2015, 658 . 660 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 661 "Recommendation on Stable IPv6 Interface Identifiers", 662 RFC 8064, DOI 10.17487/RFC8064, February 2017, 663 . 665 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 666 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 667 May 2017, . 669 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 670 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 671 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 672 RFC 8415, DOI 10.17487/RFC8415, November 2018, 673 . 675 9.2. Informative References 677 [I-D.bourbaki-6man-classless-ipv6] 678 Bourbaki, N., "IPv6 is Classless", draft-bourbaki-6man- 679 classless-ipv6-04 (work in progress), September 2018. 681 [I-D.farmer-6man-exceptions-64] 682 Farmer, D., "Exceptions to the Standard Subnet Boundary in 683 IPv6 Addressing", draft-farmer-6man-exceptions-64-09 (work 684 in progress), August 2018. 686 [I-D.jaeggli-v6ops-indefensible-nd] 687 Jaeggli, J., "Indefensible Neighbor Discovery", draft- 688 jaeggli-v6ops-indefensible-nd-01 (work in progress), July 689 2018. 691 [I-D.jinmei-6man-prefix-clarify] 692 Jinmei, T., "Clarifications on On-link and Subnet IPv6 693 Prefixes", draft-jinmei-6man-prefix-clarify-00 (work in 694 progress), March 2017. 696 [RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6 697 Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884, 698 December 1995, . 700 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 701 RFC 3972, DOI 10.17487/RFC3972, March 2005, 702 . 704 [RFC4291bis] 705 Hinden, R. and S. Deering, "IP Version 6 Addressing 706 Architecture", draft-ietf-6man-rfc4291bis-09 (work in 707 progress), July 2017, 708 . 710 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 711 Extensions for Stateless Address Autoconfiguration in 712 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 713 . 715 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 716 and C. Hahn, "IPv6 Unicast Address Assignment 717 Considerations", RFC 5375, DOI 10.17487/RFC5375, December 718 2008, . 720 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 721 Neighbor Discovery Problems", RFC 6583, 722 DOI 10.17487/RFC6583, March 2012, 723 . 725 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 726 Interface Identifiers with IPv6 Stateless Address 727 Autoconfiguration (SLAAC)", RFC 7217, 728 DOI 10.17487/RFC7217, April 2014, 729 . 731 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 732 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 733 Boundary in IPv6 Addressing", RFC 7421, 734 DOI 10.17487/RFC7421, January 2015, 735 . 737 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 738 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 739 . 741 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 742 Considerations for IPv6 Address Generation Mechanisms", 743 RFC 7721, DOI 10.17487/RFC7721, March 2016, 744 . 746 Author's Address 748 David Farmer 749 University of Minnesota 750 Office of Information Technology 751 2218 University Ave SE 752 Minneapolis, MN 55414 753 US 755 Phone: +16126260815 756 Email: farmer@umn.edu 757 URI: http://www.umn.edu/