idnits 2.17.1 draft-pioxfolks-6man-pio-exclusive-bit-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7934]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- 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 (October 27, 2016) is 2710 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 636 -- Looks like a reference, but probably isn't: '2' on line 638 -- Looks like a reference, but probably isn't: '3' on line 640 -- Looks like a reference, but probably isn't: '4' on line 642 == Unused Reference: 'RFC4862' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'RFC4429' is defined on line 620, but no explicit reference was found in the text == Unused Reference: 'RFC5452' is defined on line 624, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Kline 3 Internet-Draft Google Japan KK 4 Updates: 4861 (if approved) M. Abrahamsson 5 Intended status: Experimental T-Systems Nordic 6 Expires: April 30, 2017 October 27, 2016 8 IPv6 Router Advertisement Prefix Information Option Exclusive Bit 9 draft-pioxfolks-6man-pio-exclusive-bit-01 11 Abstract 13 This document defines a new control bit in the IPv6 RA PIO flags 14 octet that indicates that the node receiving this RA is the exclusive 15 receiver of all traffic destined to any address within that prefix. 17 Termed the eXclusive bit (or "X bit"), nodes that recognize this can 18 perform some optimizations to save time and traffic (e.g. disable ND 19 and DAD for addresses within this prefix) and more immediately pursue 20 the benefits of being provided multiple addresses (vis. [RFC7934] 21 section 3). Additionally, network infrastructure nodes (routers, 22 switches) can benefit by minimizing the number of {link layer, IP} 23 address pairs required to offer network connectivity (vis. [RFC7934] 24 section 9.3). 26 Use of the X bit is backward compatible with existing IPv6 standards 27 compliant implementations. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 30, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Efficiency improvements . . . . . . . . . . . . . . . . . 4 66 2.2. New architectural possibilities . . . . . . . . . . . . . 4 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 69 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2.1. PIO-X . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2.2. PIO-X RA . . . . . . . . . . . . . . . . . . . . . . 5 72 3.2.3. Host . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.3.1. Link layer guarantees . . . . . . . . . . . . . . . . 6 75 3.3.2. Likely sole intended recipient . . . . . . . . . . . 6 76 4. Updated Prefix Information Option . . . . . . . . . . . . . . 6 77 4.1. Updated format description . . . . . . . . . . . . . . . 6 78 4.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 7 79 4.2.1. Verify sole recipient . . . . . . . . . . . . . . . . 7 80 4.2.2. (Re)Interpretation of other flags . . . . . . . . . . 8 81 4.2.2.1. PIO L bit . . . . . . . . . . . . . . . . . . . . 8 82 4.2.2.2. PIO A bit . . . . . . . . . . . . . . . . . . . . 8 83 4.3. Transmitting PIO-X RAs . . . . . . . . . . . . . . . . . 9 84 5. Host behavior . . . . . . . . . . . . . . . . . . . . . . . . 9 85 5.1. PIO-X processing . . . . . . . . . . . . . . . . . . . . 9 86 5.2. Neighbor Discovery implications . . . . . . . . . . . . . 9 87 5.2.1. Duplicate Address Detection (DAD) . . . . . . . . . . 9 88 5.2.2. Router Solicitations (RSes) . . . . . . . . . . . . . 9 89 5.3. Link-local address behavior . . . . . . . . . . . . . . . 10 90 5.4. Source address selection . . . . . . . . . . . . . . . . 10 91 5.5. Next hop router selection . . . . . . . . . . . . . . . . 10 92 5.6. Implications for Detecting Network Attachment . . . . . . 10 93 5.7. Additional guidance . . . . . . . . . . . . . . . . . . . 10 95 6. Router behavior . . . . . . . . . . . . . . . . . . . . . . . 11 96 6.1. PIO-X RA destination address . . . . . . . . . . . . . . 11 97 6.2. Detecting hosts to send PIO-X RAs to . . . . . . . . . . 11 98 6.3. Binding table requirements . . . . . . . . . . . . . . . 11 99 6.4. Preparations before sending a PIO-X RA . . . . . . . . . 12 100 6.5. Implementation considerations . . . . . . . . . . . . . . 12 101 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 105 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 106 10.2. Informative References . . . . . . . . . . . . . . . . . 13 107 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 110 1. Introduction 112 This document defines a new control bit in the Internet Protocol 113 version 6 (IPv6) Router Advertisement (RA) Prefix Information Option 114 (PIO) flags octet that indicates that the node receiving this RA is 115 the exclusive receiver of all traffic destined to any address with 116 that prefix. Subject to the lifetime constraints within the PIO, the 117 receiving node effectively has exclusive use of the prefix, and will 118 be the next hop destination for the sending router, and possibly 119 other routers, for all traffic destined toward the prefix. 121 Termed the eXclusive bit (or "X bit"), nodes that recognize this can 122 perform some optimizations to save time and traffic (e.g. disable 123 Neighbor Discovery (ND) and Duplicate Address Detection (DAD) for 124 addresses within this prefix) and more immediately pursue the 125 benefits of being provided multiple addresses (vis. [RFC7934] 126 section 3). 128 Additionally, network infrastructure nodes (routers, switches) can 129 benefit by minimizing the number of {link layer, IP} address pairs 130 required to offer network connectivity (vis. [RFC7934] section 9.3). 131 A router, for example, need not create any {link layer, IP} address 132 pair entries for IP address within a proffered exclusive-use prefix-- 133 it can reliably forward all traffic to the network node to which it 134 advertised the prefix. This solves one potential link layer state 135 exhaustion problem, i.e excessive number of {link layer, IP address 136 pairs}, using IP layer forwarding. 138 Use of the X bit is backward compatible with existing IPv6 standards 139 compliant implementations. [RFC4861]-compliant nodes that do not 140 understand the X bit are not negatively impacted. They must ignore 141 it, and can process the PIO under existing standards, making use of 142 the information exactly as if the X bit were not set. 144 2. Motivation 146 This work is motivated by the pursuit of two categories of benefits: 147 some host and network side improvements in efficiency, and support 148 for new deployment architectures and address space use models. 150 2.1. Efficiency improvements 152 If a host knows it has exclusive use of a prefix it can perform some 153 optimizations to save time an traffic. It can avoid ND on the 154 receiving interface for addresses within these prefixes. Network 155 interfaces can even drop Neighbor Solicitations for these addresses 156 on the receiving interface to save power by not waking up more power 157 hungry CPUs. 159 Additionally, a host can save time by not performing DAD for 160 addresses within an exclusive-use prefix on the receiving interface. 161 A host that wanted, for example, to use 2**64 unique IPv6 source 162 addresses for DNS queries in order to improve resilience against 163 forged answers (as recommended in section 9.2 of ), could do 164 so without delaying each query from a newly formed address. A node 165 could in theory implement the same strategy using Optimistic 166 Duplicate Address Detection [1], but it could be very unfriendly to 167 the network infrastructure (in terms of {link-layer, IP address} pair 168 state) to do so without some explicit signal. 170 2.2. New architectural possibilities 172 There are several initiatives that propose network side practices 173 that provide customer isolation, enhanced operational scalability, 174 power efficiency, security and other benefits in IPv6 network 175 deployments. Some of these involve isolating a host (or RA accepting 176 client node) so that the host is the only node to receive a specific 177 prefix, including 179 o DHCPv6 Prefix Delegation to hosts (), and 182 o advertising a unique prefix per host via unique RAs. 183 (). 186 Some architectures further isolate the host layers below IPv6, for 187 improved client node security. 189 Regardless of the specific level of isolation, the host can best make 190 choices about its use of a prefix exclusively forwarded to itself if 191 the host can be informed of the exclusivity. (In the case of a 192 DHCPv6 Prefix Delegation the prefix can be assumed to be of exclusive 193 use by the requesting node, in accordance with the model in 194 [RFC3633].) An implementation can, for example, safely "bind to an 195 IPv6 subnet" in the style of , or start 64sharing [2] (given a prefix of a 197 suitable size). 199 This memo documents an additional bit in the IPv6 RA PIO that makes 200 this information explicit to receiving node. 202 3. Terminology 204 3.1. Requirements Language 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in RFC 2119 [RFC2119]. 210 3.2. Abbreviations 212 Throughout this document the following terminology is used purely for 213 the sake of brevity. 215 3.2.1. PIO-X 217 The term "PIO-X" is used to refer to a Prefix Information Option 218 (PIO) that has the X bit set. 220 3.2.2. PIO-X RA 222 The phrase "PIO-X RA" is used to refer to an IPv6 Router 223 Advertisement (RA) that contains one or more PIO-X entries (the same 224 RA may also contain one or more PIOs without the X bit set). 226 3.2.3. Host 228 The term "host" may be used interchangeably throughout this document 229 to mean a network node receiving and processing an RA. The receiving 230 node may itself be a router, or may temporarily become one by routing 231 all or a portion of an exclusive use prefix. 233 3.3. Concepts 235 Critical to correct network operations when employing PIO-X is the 236 concept that both the router transmitting a PIO-X RA and its intended 237 recipient be reasonably assured of the prefix's exclusivity. In 238 support of this, the router must have confidence in the host's 239 presence and reachability, and several constraints are placed on the 240 format of the RA for the host to validate. 242 3.3.1. Link layer guarantees 244 TODO: Add definition of things like "guaranteed point-to-point link" 245 and what it is meant by having certain link-layer guarantees. 247 3.3.2. Likely sole intended recipient 249 TODO: section about "likely sole recipient" which can be referenced 250 from other sections. 252 4. Updated Prefix Information Option 254 This document updates the Prefix Information Option specification in 255 RFC 4861, section 4.6.2 with the definition of a bit from the former 256 Reserved1 field as follows. 258 4.1. Updated format description 260 0 1 2 3 261 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type | Length | Prefix Length |L|A|X| Rsrvd1 | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Valid Lifetime | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Preferred Lifetime | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Reserved2 | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 + + 273 | | 274 + Prefix + 275 | | 276 + + 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Fields: 282 X The eXclusive use indicator flag, defined by this document. 283 When set, the receiving node can be assured that all traffic 284 destined to any address within the specified Prefix will be 285 forwarded to itself by, at a minimum, the router from which 286 the encapsulating RA was received, but possibly other routers 287 as well. 289 When not set, the receiving node MUST NOT make any 290 assumptions of exclusive use of the specified Prefix, i.e. 291 processing is unchanged from previous standards behavior. 293 Rsrvd1 Retains the same meaning as Reserved1 from section 294 4.6.2. 296 All Retain their same meaning from section 4.6.2. 297 other 298 fields 300 4.2. Processing 302 Nodes compliant with this specification perform the following 303 additional processing of RAs and PIO-X options when a PIO-X option is 304 present. 306 4.2.1. Verify sole recipient 308 A node receiving a PIO-X option MUST verify that it is the (likely) 309 sole intended recipient of the PIO-X RA. This done by verifying that 310 the RA is unicast to the node at the IPv6 layer and, if applicable, 311 at the link layer. On links that provide the node with a guarantee 312 that it is the only possible PIO-X RA recipient (e.g. PPP, 3GPP 313 links) this validation step SHOULD NOT be performed. 315 If an address other than :: (the unspecified address) was used as the 316 source address for one or more Router Solicitations (RS) on this 317 link, the node MUST verify that the IPv6 destination address of the 318 PIO-X RA is one of the RS source addresses in use. If the link over 319 which this communication takes place is known to be point-to-point, 320 i.e. the nature of the link ensures that the node is the only 321 possible recipient of an RA this check SHOULD NOT be performed. 323 If the node receives a PIO-X RA over a link-layer medium that 324 supports link-layer addresses, it MUST verify that the link-layer 325 destination address of the PIO-X RA is its own link-layer address. 326 If the node received a PIO-X RA over a point-to-point medium (such as 327 PPP) this step is unnecessary. 329 If any part of this "sole unicast recipient" verification fails, the 330 node MUST ignore the PIO-X bit and continue processing as if it were 331 not set (X=0). 333 4.2.2. (Re)Interpretation of other flags 335 Nodes compliant with this specification, i.e. those that understand 336 the X-bit, MUST, when the X-bit is set, ignore the actual values of 337 the L and A flags and instead interpret them as follows: 339 o interpret the L bit as if it were 0 (L=0) 341 o interpret the A bit as it it were 1 (A=1) 343 The rationale for this is as follows. 345 4.2.2.1. PIO L bit 347 Because a PIO-X aware node will know that it has exclusive use of a 348 prefix with non-zero valid lifetime, the prefix itself cannot be 349 considered to be on-link with respect to the link on which the PIO-X 350 RA was received. 352 Note that a given address from within the prefix may be considered 353 on-link according to the definition in section 4, item 1, 354 should the receiving node chose to configure that address on said 355 link, but this is in no way synonymous with the entire prefix being 356 considered on-link. 358 4.2.2.2. PIO A bit 360 Because a PIO-X aware node will know that it has exclusive use of a 361 prefix with non-zero valid lifetime, autoconfiguration of addresses 362 according to any desired scheme, e.g. , , et 363 cetera, is implicit in the setting of the X bit. 365 Accordingly, the A bit can be interpreted as having been set, should 366 the host choose to apply standard address generation schemes that 367 require the bit to be set. It is free to assign any address formed 368 from an exclusive prefix to any available interface; it is not 369 required to configure the address on the link over which the PIO-X RA 370 was received (i.e. it is under no obligation to form addresses such 371 that they would be classified as on-link (according to the definition 372 in section 4, item 1). 374 4.3. Transmitting PIO-X RAs 376 When a router transmits an RA containing one or more PIO-X options it 377 MUST unicast the PIO-X RA to its intended recipient at the IPv6 layer 378 and, if applicable, at the link-layer. 380 It is RECOMMENDED that a PIO with the X-bit set also have the PIO 381 flags L=0 and A=1 explicitly configured, for backward compatibility 382 (i.e. use by non X-bit aware nodes). 384 5. Host behavior 386 TODO: This section needs some work. 388 5.1. PIO-X processing 390 A receiving node compliant with this document processes an RA with a 391 PIO entry with the X flag set according the requirements in previous 392 standards documents (chiefly section 6.3.4) subject to the 393 additional requirements documented in Section 4.2. 395 5.2. Neighbor Discovery implications 397 5.2.1. Duplicate Address Detection (DAD) 399 Whatever use the host makes of the exclusive prefix during its valid 400 lifetime, it SHOULD NOT perform Duplicate Address Detection ("DAD", 401 section 5.4) on any address it configures from within the 402 prefix if that address is configured on either the interface over 403 which the PIO-X RA was received or on a loopback interface. Note 404 that this does not absolve the host from performing DAD in all 405 scenarios; if, for example, the host uses the prefix for 64sharing 406 [3] it MUST at a minimum defend via DAD any addresses it has 407 configured for itself as documented in Requirement 2 of 408 section 3. 410 5.2.2. Router Solicitations (RSes) 412 Routers announcing PIO-X RAs do so via IPv6 unicast to the intended 413 receiving node and may note the IPv6 unicast destination address of 414 an RS as the next hop for the exclusive prefix. As such, hosts 415 compliant with this SHOULD NOT use the unspecified address (::) when 416 sending RSes; they SHOULD prefer issuing Router Solicitations from a 417 link-local address. 419 It is possible for a node to receive multiple RAs with a mix of 420 exclusive and non-exclusive PIOs and even non-zero and zero default 421 router lifetimes. While it is not possible for a host (receiving 422 node) to be sure it has received all the RA information available to 423 it, hosts compliant with this specification SHOULD implement Packet- 424 Loss Resiliency for Router Solicitations [RFC7559] so that the host 425 continues to transmit Router Solicitations at least until an RA with 426 a non-zero default router lifetime has been seen. 428 5.3. Link-local address behavior 430 Routers announcing PIO-X RAs may record the source (link-local) 431 address of an RS as the next hop for the exclusive prefix. A node 432 compliant with this specification MUST continue to respond to 433 Neighbor Solicitations for the source address used to send RSes 434 (alternatively: the destination address of unicast PIO-X RAs 435 received). Hosts that deprecate or even remove this address may 436 experience a loss of connectivity. 438 5.4. Source address selection 440 No change to existing source address selection behavior is required 441 or specified by this document. 443 5.5. Next hop router selection 445 No change to existing next hop router selection behavior is required 446 or specified by this document. 448 5.6. Implications for Detecting Network Attachment 450 TODO: Describe implications for Detecting Network Attachment in IPv6 451 [4] (DNAv6). Probably the best that can be done is (a) no change to 452 RFC6059 coupled with (b) a host MAY send a test packet (e.g. ICMPv6 453 Echo Request) with a source and destination address from within the 454 PIO-X prefix to the PIO-X RA issuing router and verify the packet is 455 delivered back to itself. Consistent failure to receive such traffic 456 MAY be considered a signal that the exclusive prefix should no longer 457 be used by the host. 459 5.7. Additional guidance 461 The intent of networks that use PIO-X RAs is not to enable 462 sophisticated routing architectures that could be far better handled 463 by an actual routing protocol but rather to propagate a prefix's 464 exclusive use information to enable the receiving node to make better 465 use of the available addresses. As such: 467 A PIO-X receiving node SHOULD NOT issue ICMPv6 Redirects 468 ([RFC4861] section 4.5) for any address within an exclusive use 469 prefix via the link over which the PIO-X RA was received. 471 Redirecting portions of exclusive prefixes to other "upstream" on- 472 link nodes is not a supported configuration. 474 A PIO-X receiving node SHOULD NOT transmit RAs with any subset of 475 its exclusive prefixes via the same interface through which the 476 exclusive prefix was learned. 478 6. Router behavior 480 TODO: This section needs some work. 482 6.1. PIO-X RA destination address 484 Since the host will not perform DAD for addresses within prefix 485 announced via PIO-X, it's very important that only a single host 486 receives the PIO-X RA. Therefore, the router MUST only include PIO-X 487 in RAs that are sent using unicast RAs to destination unicast link- 488 layer address and IPv6 link-local unicast address for a specific 489 host. For point-to-point media without link-layer addresses or where 490 there is guaranteed to only be single host that will receive the 491 PIO-X RA (e.g. as enforced by link layer mechanisms), the router MAY 492 send PIO-X RA with multicast destination IPv6 address. Under all 493 circumstances the router MUST maintain a binding table of state 494 information as discussed in Section 6.3. 496 6.2. Detecting hosts to send PIO-X RAs to 498 When the host starts using a network connection it normally sends out 499 an RS (Router Solicitation) packet. This is one way for the router 500 to detect that a new host is connected to the network and detects its 501 link-local address. If the router is configured to use PIO-X, it can 502 now perform necessary processing/configuration and then send the 503 PIO-X RA. 505 For some networks, the host information regarding link-layer and 506 link-local address might be available through other mechanism(s). 507 Examples of this are PPP, 802.1x and 3GPP mobile networks. In that 508 case this information MAY be used instead of relying on the host to 509 send RS. It is however RECOMMENDED that these networks also provide 510 indication whether the host is no longer connected to the network so 511 that the router can invalidate the prefix binding prior to binding 512 expiration (timeout). 514 6.3. Binding table requirements 516 Routers transmitting PIO-X RAs have state maintenance and operational 517 requirements similar to delegating routers in networks where DHCPv6 518 Prefix Delegation [RFC3633] is used. The state maintained is 519 describe here in terms of a conceptual binding table. 521 R1 The router SHOULD keep track of which PIO-X prefix has been 522 issued to each node. 524 R2 The router SHOULD keep the binding between prefix and link-local 525 address for the advertised valid lifetime, plus some 526 operationally determined delay prior to reissuing a prefix 527 ("grace period"), of the prefix. 529 R3 The router MUST monitor the reachability of each node in the 530 binding table via Neighbor Unreachability Detection ("NUD", 531 section 7.3) or an equivalent link-layer mechanism. 533 R4 The binding SHOULD be considered refreshed every time a periodic 534 PIO-X RA is sent to a node. 536 R5 If the router is informed by some other mechanism (link-layer 537 indication for instance) that a node is no longer connected to 538 the link, it MAY immediately invalidate the prefix binding. 539 (DISCUSS: Is this the correct approach? Do we want to point to 540 some definition somewhere else?) 542 6.4. Preparations before sending a PIO-X RA 544 When the router intends to send a PIO-X RA, it SHOULD before sending 545 the PIO-X RA, complete any and all necessary processing for the host 546 to start using the PIO-X prefix to communicate through the router to 547 other networks. This is so that the host can start using PIO-X based 548 addresses without delay or error after receipt of the PIO-X RA. 550 6.5. Implementation considerations 552 TODO: Out of scope things that are worth careful consideration 553 include... 555 Routers SHOULD NOT announce the same prefix to two different nodes 556 within the valid lifetime of the earlier of the two PIO-X 557 announcements. 559 A link may operate in a mode where routers announce RAs to all nodes, 560 possibly with non-exclusive PIO data, and non-zero default router 561 lifetimes. Separately, one or more other nodes on the link may 562 announce exclusive PIO information to nodes along with zero default 563 router lifetimes. Except in the presence of a non-expired more 564 specific route, e.g. learning from an Route Information 565 Option (RIO), the receiving node should send exclusive use prefix 566 originated or forwarded traffic destined off-link through routers 567 with non-zero default router lifetimes. 569 7. Acknowledgements 571 8. IANA Considerations 573 This memo contains no requests of IANA. 575 9. Security Considerations 577 This document fundamentally introduces no new protocol or behavior 578 substantively different from existing behavior on a link which 579 guarantees a unique /64 prefix to every attached host. It only 580 describes a mechanism to convey that topological reality, allowing 581 the host to make certain optimizations as well as share the exclusive 582 prefix as it sees fit with other nodes according to its capabilities 583 and policies. 585 10. References 587 10.1. Normative References 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, 591 DOI 10.17487/RFC2119, March 1997, 592 . 594 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 595 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 596 DOI 10.17487/RFC4861, September 2007, 597 . 599 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 600 Address Autoconfiguration", RFC 4862, 601 DOI 10.17487/RFC4862, September 2007, 602 . 604 [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss 605 Resiliency for Router Solicitations", RFC 7559, 606 DOI 10.17487/RFC7559, May 2015, 607 . 609 10.2. Informative References 611 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 612 Host Configuration Protocol (DHCP) version 6", RFC 3633, 613 DOI 10.17487/RFC3633, December 2003, 614 . 616 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 617 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 618 November 2005, . 620 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 621 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 622 . 624 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 625 Resilient against Forged Answers", RFC 5452, 626 DOI 10.17487/RFC5452, January 2009, 627 . 629 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 630 "Host Address Availability Recommendations", BCP 204, 631 RFC 7934, DOI 10.17487/RFC7934, July 2016, 632 . 634 10.3. URIs 636 [1] RFC4429 638 [2] RFC7278 640 [3] RFC7278 642 [4] RFC6059 644 Authors' Addresses 646 Erik Kline 647 Google Japan KK 648 6-10-1 Roppongi 649 Mori Tower, 44th floor 650 Minato, Tokyo 106-6126 651 JP 653 Email: ek@google.com 654 Mikael Abrahamsson 655 T-Systems Nordic 656 Kistagangen 26 657 Stockholm 658 SE 660 Email: Mikael.Abrahamsson@t-systems.se