idnits 2.17.1 draft-pioxfolks-6man-pio-exclusive-bit-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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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. -- The draft header indicates that this document updates RFC6275, 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 (March 27, 2017) is 2580 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 158 -- Looks like a reference, but probably isn't: '2' on line 161 -- Looks like a reference, but probably isn't: '3' on line 179 -- Looks like a reference, but probably isn't: '4' on line 181 -- Looks like a reference, but probably isn't: '5' on line 192 -- Looks like a reference, but probably isn't: '6' on line 192 -- Looks like a reference, but probably isn't: '7' on line 230 -- Looks like a reference, but probably isn't: '8' on line 266 -- Looks like a reference, but probably isn't: '9' on line 266 -- Looks like a reference, but probably isn't: '10' on line 304 -- Looks like a reference, but probably isn't: '11' on line 307 -- Looks like a reference, but probably isn't: '12' on line 344 -- Looks like a reference, but probably isn't: '13' on line 353 -- Looks like a reference, but probably isn't: '14' on line 353 -- Looks like a reference, but probably isn't: '15' on line 363 -- Looks like a reference, but probably isn't: '16' on line 388 -- Looks like a reference, but probably isn't: '17' on line 407 -- Looks like a reference, but probably isn't: '18' on line 415 -- Looks like a reference, but probably isn't: '19' on line 419 -- Looks like a reference, but probably isn't: '20' on line 421 -- Looks like a reference, but probably isn't: '21' on line 464 -- Looks like a reference, but probably isn't: '22' on line 542 -- Looks like a reference, but probably isn't: '23' on line 576 == Unused Reference: 'RFC4862' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'RFC6275' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'RFC4429' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'RFC5452' is defined on line 638, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 28 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,6275 (if approved) M. Abrahamsson 5 Intended status: Experimental T-Systems Nordic 6 Expires: September 28, 2017 March 27, 2017 8 IPv6 Router Advertisement Prefix Information Option eXclusive Flag 9 draft-pioxfolks-6man-pio-exclusive-bit-02 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 flag (or "X flag"), nodes that recognize this 18 can perform some optimizations to save time and traffic (e.g. disable 19 ND and DAD for addresses within this prefix) and more immediately 20 pursue the benefits of being provided multiple addresses (vis. 21 [RFC7934] section 3). Additionally, network infrastructure nodes 22 (routers, switches) can benefit by minimizing the number of {link 23 layer, IP} address pairs required to offer network connectivity (vis. 24 [RFC7934] section 9.3). 26 Use of the X flag 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 September 28, 2017. 46 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Efficiency improvements . . . . . . . . . . . . . . . . . 4 65 2.2. New architectural possibilities . . . . . . . . . . . . . 4 66 3. Applicability statement . . . . . . . . . . . . . . . . . . . 5 67 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 69 4.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 70 4.2.1. PIO-X . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2.2. PIO-X RA . . . . . . . . . . . . . . . . . . . . . . 6 72 4.2.3. Host . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Updated Prefix Information Option . . . . . . . . . . . . . . 6 74 5.1. Updated format description . . . . . . . . . . . . . . . 6 75 5.2. Receiver processing . . . . . . . . . . . . . . . . . . . 7 76 5.2.1. PIO R flag . . . . . . . . . . . . . . . . . . . . . 7 77 5.2.2. (Re)Interpretation of other flags . . . . . . . . . . 7 78 5.2.2.1. PIO L flag . . . . . . . . . . . . . . . . . . . 8 79 5.2.2.2. PIO A flag . . . . . . . . . . . . . . . . . . . 8 80 5.3. Sender requirements . . . . . . . . . . . . . . . . . . . 8 81 5.4. Comparison with DHCPv6 PD . . . . . . . . . . . . . . . . 9 82 6. Host behavior . . . . . . . . . . . . . . . . . . . . . . . . 9 83 6.1. PIO-X processing . . . . . . . . . . . . . . . . . . . . 9 84 6.2. Neighbor Discovery implications . . . . . . . . . . . . . 9 85 6.2.1. Duplicate Address Detection (DAD) . . . . . . . . . . 9 86 6.2.2. Router Solicitations (RSes) . . . . . . . . . . . . . 10 87 6.3. Link-local address behavior . . . . . . . . . . . . . . . 10 88 6.4. Source address selection . . . . . . . . . . . . . . . . 10 89 6.5. Next hop router selection . . . . . . . . . . . . . . . . 11 90 6.6. Implications for Detecting Network Attachment . . . . . . 11 91 6.7. Additional guidance . . . . . . . . . . . . . . . . . . . 11 92 7. Router behavior . . . . . . . . . . . . . . . . . . . . . . . 11 93 7.1. PIO-X RA destination address . . . . . . . . . . . . . . 11 94 7.2. Detecting hosts to send PIO-X RAs to . . . . . . . . . . 12 95 7.3. Binding table requirements . . . . . . . . . . . . . . . 12 96 7.4. Preparations before sending a PIO-X RA . . . . . . . . . 13 97 7.5. Implementation considerations . . . . . . . . . . . . . . 13 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 100 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 103 11.2. Informative References . . . . . . . . . . . . . . . . . 14 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 106 1. Introduction 108 This document defines a new control flag in the Internet Protocol 109 version 6 (IPv6) Router Advertisement (RA) Prefix Information Option 110 (PIO) flags octet that indicates that the node receiving this RA is 111 the exclusive receiver of all traffic destined to any address with 112 that prefix. Subject to the lifetime constraints within the PIO, the 113 receiving node effectively has exclusive use of the prefix, and will 114 be the next hop destination for the sending router, and possibly 115 other routers, for all traffic destined toward the prefix. 117 Termed the eXclusive flag (or "X flag"), nodes that recognize this 118 can perform some optimizations to save time and traffic (e.g. disable 119 Neighbor Discovery (ND) and Duplicate Address Detection (DAD) for 120 addresses within this prefix) and more immediately pursue the 121 benefits of being provided multiple addresses (vis. [RFC7934] 122 section 3). 124 Additionally, network infrastructure nodes (routers, switches) can 125 benefit by minimizing the number of {link layer, IP} address pairs 126 required to offer network connectivity (vis. [RFC7934] section 9.3). 127 A router, for example, need not create any {link layer, IP} address 128 pair entries for IP address within a proffered exclusive-use prefix-- 129 it can reliably forward all traffic to the network node to which it 130 advertised the prefix. This solves one potential link layer state 131 exhaustion problem, i.e excessive number of {link layer, IP address 132 pairs}, using IP layer forwarding. 134 Use of the X flag is backward compatible with existing IPv6 standards 135 compliant implementations. [RFC4861]-compliant nodes that do not 136 understand the X flag are not negatively impacted. They must ignore 137 it, and can process the PIO under existing standards, making use of 138 the information exactly as if the X flag were not set. 140 2. Motivation 141 This work is motivated by the pursuit of two categories of benefits: 142 modest host and network side improvements in efficiency, and support 143 for new deployment architectures and address space use models. 145 2.1. Efficiency improvements 147 If a host knows it has exclusive use of a prefix it can perform some 148 optimizations to save time and traffic. It can avoid ND on the 149 receiving interface for addresses within these prefixes. Network 150 interfaces can even drop Neighbor Solicitations for these addresses 151 on the receiving interface to save power by not waking up more power- 152 hungry CPUs. 154 Additionally, a host can save time by not performing DAD for 155 addresses within an exclusive-use prefix on the receiving interface. 156 A host that wanted, for example, to use 2**64 unique IPv6 source 157 addresses for DNS queries in order to improve resilience against 158 forged answers (as recommended in section 9.2 of [1]), could do so 159 without delaying each query from a newly formed address. A node 160 could in theory implement the same strategy using Optimistic 161 Duplicate Address Detection [2], but it could be very unfriendly to 162 the network infrastructure (in terms of {link-layer, IP address} pair 163 state) to do so without this kind of explicit signal. 165 A host that recognizes the X flag might perform other traffic-saving 166 optimizations, like not attempt Multicast DNS in some cases, or avoid 167 trying to register addresses with sleep proxies. Being the only host 168 on this link these may be of little benefit. 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 ([3]), and 181 o advertising a unique prefix per host via unique RAs. ([4]). 183 Some architectures further isolate the host layers below IPv6, for 184 improved client node security. 186 Regardless of the specific level of isolation, the host can best make 187 choices about its use of a prefix exclusively forwarded to itself if 188 the host can be informed of the exclusivity. (In the case of a 189 DHCPv6 Prefix Delegation the prefix can be assumed to be of exclusive 190 use by the requesting node, in accordance with the model in 191 [RFC3633].) An implementation can, for example, safely "bind to an 192 IPv6 subnet" in the style of [5], or start 64sharing [6] (given a 193 prefix of sufficient size). 195 This memo documents an additional flag in the IPv6 RA PIO that makes 196 this information explicit to receiving node. 198 3. Applicability statement 200 Use of the X flag in PIOs is only applicable to networks where the 201 architecture (i.e. serving infrastructure like routers, link-layer 202 equipment, et cetera) can collectively guarantee the following 203 criteria are met: 205 1. an RA containing a PIO with the X flag set MUST be delivered to 206 one and only target node (host) such that no two nodes can 207 reasonably expect exclusive access to the same prefix at the same 208 time 210 2. any router advertising an RA containing a PIO with the X flag set 211 SHOULD be notified quickly when a node leaves the network 213 The first criterion ensures that the same exclusive use prefix is not 214 advertised to more than one host at a time (and hence no longer 215 "exclusive"). This implies that an allocated exclusive-use prefix 216 must be tracked by the issuing router for at least the minimum of (a) 217 the lifetime of the recipient node's continuous attachment to the 218 network and (b) the lifetime of the prefix itself in the PIO, if not 219 longer. 221 The second criterion aims to help the prefix allocation 222 infrastructure reclaim unused prefixes quickly while also helping 223 routers drop (possibly with appropriate ICMPv6 errors) traffic that 224 can no longer be delivered. 226 It is expected that in practice this primarily describes networks 227 where the IPv6 infrastructure and the link-layer have a tight 228 integration. All point-to-point links meet these criteria (e.g. 229 PPPoE and VPNs), as does the 3GPP architecture [RFC7066] and some 230 IEEE 802.11 deployment architectures ([7]). 232 4. Terminology 234 4.1. Requirements Language 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 238 document are to be interpreted as described in RFC 2119 [RFC2119]. 240 4.2. Abbreviations 242 Throughout this document the following terminology is used purely for 243 the sake of brevity. 245 4.2.1. PIO-X 247 The term "PIO-X" is used to refer to a Prefix Information Option 248 (PIO) that has the X flag set. 250 4.2.2. PIO-X RA 252 The phrase "PIO-X RA" is used to refer to an IPv6 Router 253 Advertisement (RA) that contains one or more PIO-X entries (the same 254 RA may also contain one or more PIOs without the X flag set). 256 4.2.3. Host 258 The term "host" may be used interchangeably throughout this document 259 to mean a network node receiving and processing an RA. The receiving 260 node may itself be a router, or may temporarily become one by routing 261 all or a portion of an exclusive use prefix. 263 5. Updated Prefix Information Option 265 This document updates the Prefix Information Option specification in 266 RFC 4861 [8] section 4.6.2 and RFC 6275 [9] section 7.2 with the 267 definition of a flag from the former Reserved1 field as follows. 269 5.1. Updated format description 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type | Length | Prefix Length |L|A|R|X| Rsrvd1| 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Valid Lifetime | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Preferred Lifetime | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Reserved2 | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 + + 284 | | 285 + Prefix + 286 | | 287 + + 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Fields: 293 X The eXclusive use indicator flag, defined by this document. 294 When set, the receiving node can be assured that all traffic 295 destined to any address within the specified Prefix will be 296 forwarded to itself by, at a minimum, the router from which 297 the encapsulating RA was received, but possibly other routers 298 as well. 300 When not set, the receiving node MUST NOT make any 301 assumptions of exclusive use of the specified Prefix, i.e. 302 processing is unchanged from previous standards behavior. 304 Rsrvd1 Retains the same meaning as Reserved1 from [10] section 305 4.6.2. 307 All Retain their same meaning from [11] section 4.6.2. 308 other 309 fields 311 5.2. Receiver processing 313 Nodes compliant with this specification perform the following 314 additional processing of RAs and PIO-X options when a PIO-X option is 315 present. 317 5.2.1. PIO R flag 319 If the R flag is set then the X flag MUST be ignored. The R flag 320 indicates that the PIO includes an address the router has selected 321 for itself from the prefix. Logically, the prefix cannot exclusively 322 be used by the receiving node if the router has allocated any 323 addresses for itself from the prefix. 325 5.2.2. (Re)Interpretation of other flags 326 Nodes compliant with this specification, i.e. those that understand 327 the X-flag, MUST, when the X-flag is set, ignore the actual values of 328 the L and A flags and instead interpret them as follows: 330 o interpret the L flag as if it were 0 (L=0) 332 o interpret the A flag as it it were 1 (A=1) 334 The rationale for this is as follows. 336 5.2.2.1. PIO L flag 338 Because a PIO-X aware node will know that it has exclusive use of a 339 prefix with non-zero valid lifetime, the prefix itself cannot be 340 considered to be on-link with respect to the link on which the PIO-X 341 RA was received. 343 Note that a given address from within the prefix may be considered 344 on-link according to the definition in [12] section 4, item 1, should 345 the receiving node chose to configure that address on said link, but 346 this is in no way synonymous with the entire prefix being considered 347 on-link. 349 5.2.2.2. PIO A flag 351 Because a PIO-X aware node will know that it has exclusive use of a 352 prefix with non-zero valid lifetime, autoconfiguration of addresses 353 according to any desired scheme, e.g. [13], [14], et cetera, is 354 implicit in the setting of the X flag. 356 Accordingly, the A flag can be interpreted as having been set, should 357 the host choose to apply standard address generation schemes that 358 require the flag to be set. It is free to assign any address formed 359 from an exclusive prefix to any available interface; it is not 360 required to configure the address on the link over which the PIO-X RA 361 was received (i.e. it is under no obligation to form addresses such 362 that they would be classified as on-link (according to the definition 363 in [15] section 4, item 1). 365 5.3. Sender requirements 367 When a router transmits an RA containing one or more PIO-X options it 368 SHOULD unicast the PIO-X RA to its intended recipient at the IPv6 369 layer and, if applicable, at the link-layer. 371 It is RECOMMENDED that a PIO with the X-flag set also have the PIO 372 flags L=0 and A=1 explicitly configured, for backward compatibility 373 (i.e. use by non X-flag aware nodes). 375 A router transmitting a PIO-X RA MUST NOT configure for itself any 376 address from with the PIO-X prefix. (If it did, the prefix would 377 logically no longer be of exclusive use for the receiving node.) 379 5.4. Comparison with DHCPv6 PD 381 There exists a key difference in semantics between PIO-X and DHCPv6 382 PD: with PIO-X the network keeps the client refreshed with its prefix 383 whereas with DHCPv6 PD the client is responsible for refreshing its 384 prefix from the server. This is one reason it is important for the 385 data link layer to be able to quickly inform routers of client 386 detachment. 388 Another difference is that [16] section 12.1 states: 390 ... the requesting router MUST 391 NOT assign any delegated prefixes or subnets from the delegated 392 prefix(es) to the link through which it received the DHCP message 393 from the delegating router. 395 In contrast, a node receiving a PIO-X RA is explicitly free to treat 396 the entire prefix as on-link with respect to the interface via which 397 it was received. 399 6. Host behavior 401 TODO: This section needs some work. 403 6.1. PIO-X processing 405 A receiving node compliant with this document processes an RA with a 406 PIO entry with the X flag set according the requirements in previous 407 standards documents (chiefly [17] section 6.3.4) subject to the 408 additional requirements documented in Section 5.2. 410 6.2. Neighbor Discovery implications 412 6.2.1. Duplicate Address Detection (DAD) 413 Whatever use the host makes of the exclusive prefix during its valid 414 lifetime, it SHOULD NOT perform Duplicate Address Detection ("DAD", 415 [18] section 5.4) on any address it configures from within the prefix 416 if that address is configured on either the interface over which the 417 PIO-X RA was received or on a loopback interface. Note that this 418 does not absolve the host from performing DAD in all scenarios; if, 419 for example, the host uses the prefix for 64sharing [19] it MUST at a 420 minimum defend via DAD any addresses it has configured for itself as 421 documented in Requirement 2 of [20] section 3. 423 6.2.2. Router Solicitations (RSes) 425 Routers announcing PIO-X RAs do so via IPv6 unicast to the intended 426 receiving node and may note the IPv6 unicast destination address of 427 an RS as the next hop for the exclusive prefix. As such, hosts 428 compliant with this SHOULD NOT use the unspecified address (::) when 429 sending RSes; they SHOULD prefer issuing Router Solicitations from a 430 link-local address. 432 It is possible for a node to receive multiple RAs with a mix of 433 exclusive and non-exclusive PIOs and even non-zero and zero default 434 router lifetimes. While it is not possible for a host (receiving 435 node) to be sure it has received all the RA information available to 436 it, hosts compliant with this specification SHOULD implement Packet- 437 Loss Resiliency for Router Solicitations [RFC7559] so that the host 438 continues to transmit Router Solicitations at least until an RA with 439 a non-zero default router lifetime has been seen. 441 6.3. Link-local address behavior 443 Routers announcing PIO-X RAs may record the source (link-local) 444 address of an RS as the next hop for the exclusive prefix. A node 445 compliant with this specification MUST continue to respond to 446 Neighbor Solicitations for the source address used to send RSes 447 (alternatively: the destination address of unicast PIO-X RAs 448 received). Hosts that deprecate or even remove this address may 449 experience a loss of connectivity. 451 6.4. Source address selection 453 No change to existing source address selection behavior is required 454 or specified by this document. 456 6.5. Next hop router selection 458 No change to existing next hop router selection behavior is required 459 or specified by this document. 461 6.6. Implications for Detecting Network Attachment 463 TODO: Describe implications for Detecting Network Attachment in IPv6 464 [21] (DNAv6). Probably the best that can be done is (a) no change to 465 RFC6059 coupled with (b) a host MAY send a test packet (e.g. ICMPv6 466 Echo Request) with a source and destination address from within the 467 PIO-X prefix to the PIO-X RA issuing router and verify the packet is 468 delivered back to itself. Consistent failure to receive such traffic 469 MAY be considered a signal that the exclusive prefix should no longer 470 be used by the host. 472 6.7. Additional guidance 474 The intent of networks that use PIO-X RAs is not to enable 475 sophisticated routing architectures that could be far better handled 476 by an actual routing protocol but rather to propagate a prefix's 477 exclusive use information to enable the receiving node to make better 478 use of the available addresses. As such: 480 A PIO-X receiving node SHOULD NOT issue ICMPv6 Redirects 481 ([RFC4861] section 4.5) for any address within an exclusive use 482 prefix via the link over which the PIO-X RA was received. 483 Redirecting portions of exclusive prefixes to other "upstream" on- 484 link nodes is not a supported configuration. 486 A PIO-X receiving node SHOULD NOT transmit RAs with any subset of 487 its exclusive prefixes via the same interface through which the 488 exclusive prefix was learned. 490 7. Router behavior 492 TODO: This section needs some work. 494 7.1. PIO-X RA destination address 496 Since the host will not perform DAD for addresses within prefix 497 announced via PIO-X, it's very important that only a single host 498 receives the PIO-X RA. Therefore, the router MUST only include PIO-X 499 in RAs that are sent using unicast RAs to destination unicast link- 500 layer address and IPv6 link-local unicast address for a specific 501 host. For point-to-point media without link-layer addresses or where 502 there is guaranteed to only be single host that will receive the 503 PIO-X RA (e.g. as enforced by link layer mechanisms), the router MAY 504 send PIO-X RA with multicast destination IPv6 address. Under all 505 circumstances the router MUST maintain a binding table of state 506 information as discussed in Section 7.3. 508 7.2. Detecting hosts to send PIO-X RAs to 510 When the host starts using a network connection it normally sends out 511 an RS (Router Solicitation) packet. This is one way for the router 512 to detect that a new host is connected to the network and detects its 513 link-local address. If the router is configured to use PIO-X, it can 514 now perform necessary processing/configuration and then send the 515 PIO-X RA. 517 For some networks, the host information regarding link-layer and 518 link-local address might be available through other mechanism(s). 519 Examples of this are PPP, 802.1x and 3GPP mobile networks. In that 520 case this information MAY be used instead of relying on the host to 521 send RS. It is however RECOMMENDED that these networks also provide 522 indication whether the host is no longer connected to the network so 523 that the router can invalidate the prefix binding prior to binding 524 expiration (timeout). 526 7.3. Binding table requirements 528 Routers transmitting PIO-X RAs have state maintenance and operational 529 requirements similar to delegating routers in networks where DHCPv6 530 Prefix Delegation [RFC3633] is used. The state maintained is 531 describe here in terms of a conceptual binding table. 533 R1 The router SHOULD keep track of which PIO-X prefix has been 534 issued to each node. 536 R2 The router SHOULD keep the binding between prefix and link-local 537 address for the advertised valid lifetime, plus some 538 operationally determined delay prior to reissuing a prefix 539 ("grace period"), of the prefix. 541 R3 The router MUST monitor the reachability of each node in the 542 binding table via Neighbor Unreachability Detection ("NUD", [22] 543 section 7.3) or an equivalent link-layer mechanism. 545 R4 The binding SHOULD be considered refreshed every time a periodic 546 PIO-X RA is sent to a node. 548 R5 If the router is informed by some other mechanism (link-layer 549 indication for instance) that a node is no longer connected to 550 the link, it MAY immediately invalidate the prefix binding. 551 (DISCUSS: Is this the correct approach? Do we want to point to 552 some definition somewhere else?) 554 7.4. Preparations before sending a PIO-X RA 556 When the router intends to send a PIO-X RA, it SHOULD before sending 557 the PIO-X RA, complete any and all necessary processing for the host 558 to start using the PIO-X prefix to communicate through the router to 559 other networks. This is so that the host can start using PIO-X based 560 addresses without delay or error after receipt of the PIO-X RA. 562 7.5. Implementation considerations 564 TODO: Out of scope things that are worth careful consideration 565 include... 567 Routers SHOULD NOT announce the same prefix to two different nodes 568 within the valid lifetime of the earlier of the two PIO-X 569 announcements. 571 A link may operate in a mode where routers announce RAs to all nodes, 572 possibly with non-exclusive PIO data, and non-zero default router 573 lifetimes. Separately, one or more other nodes on the link may 574 announce exclusive PIO information to nodes along with zero default 575 router lifetimes. Except in the presence of a non-expired more 576 specific route, e.g. learning from an [23] Route Information Option 577 (RIO), the receiving node should send exclusive use prefix originated 578 or forwarded traffic destined off-link through routers with non-zero 579 default router lifetimes. 581 8. Acknowledgements 583 9. IANA Considerations 585 This memo contains no requests of IANA. 587 10. Security Considerations 589 This document fundamentally introduces no new protocol or behavior 590 substantively different from existing behavior on a link which 591 guarantees a unique /64 prefix to every attached host. It only 592 describes a mechanism to convey that topological reality, allowing 593 the host to make certain optimizations as well as share the exclusive 594 prefix as it sees fit with other nodes according to its capabilities 595 and policies. 597 11. References 599 11.1. Normative References 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, March 1997. 604 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 605 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 606 DOI 10.17487/RFC4861, September 2007, 607 . 609 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 610 Address Autoconfiguration", RFC 4862, DOI 10.17487/ 611 RFC4862, September 2007, 612 . 614 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 615 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 616 2011, . 618 [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss 619 Resiliency for Router Solicitations", RFC 7559, DOI 620 10.17487/RFC7559, May 2015, 621 . 623 11.2. Informative References 625 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 626 Host Configuration Protocol (DHCP) version 6", RFC 3633, 627 DOI 10.17487/RFC3633, December 2003, 628 . 630 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 631 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 632 November 2005, . 634 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 635 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 636 . 638 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 639 Resilient against Forged Answers", RFC 5452, DOI 10.17487/ 640 RFC5452, January 2009, 641 . 643 [RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S. 644 Krishnan, "IPv6 for Third Generation Partnership Project 645 (3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066, 646 November 2013, . 648 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 649 "Host Address Availability Recommendations", BCP 204, RFC 650 7934, DOI 10.17487/RFC7934, July 2016, 651 . 653 Authors' Addresses 655 Erik Kline 656 Google Japan KK 657 6-10-1 Roppongi 658 Mori Tower, 44th floor 659 Minato, Tokyo 106-6126 660 JP 662 Email: ek@google.com 664 Mikael Abrahamsson 665 T-Systems Nordic 666 Kistagangen 26 667 Stockholm 668 SE 670 Email: Mikael.Abrahamsson@t-systems.se