idnits 2.17.1 draft-pioxfolks-6man-pio-exclusive-bit-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (September 16, 2016) is 2751 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 553 == Unused Reference: 'RFC4862' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 542, 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 (~~), 3 warnings (==), 5 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: March 20, 2017 September 16, 2016 8 IPv6 Router Advertisement Prefix Information Option Exclusive Bit 9 draft-pioxfolks-6man-pio-exclusive-bit-00 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 traffic-saving optimizations (e.g. disable ND and DAD 19 for addresses within this prefix) and more immediately pursue the 20 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 March 20, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2.1. PIO-X . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.2.2. PIO-X RA . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2.3. Host . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Updated Prefix Information Option . . . . . . . . . . . . . . 5 72 4.1. Updated format description . . . . . . . . . . . . . . . 5 73 4.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.2.1. Verify sole recipient . . . . . . . . . . . . . . . . 6 75 4.2.2. (Re)Interpretation of other flags . . . . . . . . . . 7 76 4.2.2.1. PIO L bit . . . . . . . . . . . . . . . . . . . . 7 77 4.2.2.2. PIO A bit . . . . . . . . . . . . . . . . . . . . 7 78 4.3. Transmitting PIO-X RAs . . . . . . . . . . . . . . . . . 8 79 5. Host behaviour . . . . . . . . . . . . . . . . . . . . . . . 8 80 5.1. PIO-X processing . . . . . . . . . . . . . . . . . . . . 8 81 5.2. Neighbor Discovery implications . . . . . . . . . . . . . 8 82 5.2.1. Duplicate Address Detection (DAD) . . . . . . . . . . 8 83 5.2.2. Router Solicitations (RSes) . . . . . . . . . . . . . 8 84 5.3. Link-local address behaviour . . . . . . . . . . . . . . 9 85 5.4. Source address selection . . . . . . . . . . . . . . . . 9 86 5.5. Next hop router selection . . . . . . . . . . . . . . . . 9 87 5.6. Additional guidance . . . . . . . . . . . . . . . . . . . 9 88 6. Router behaviour . . . . . . . . . . . . . . . . . . . . . . 10 89 6.1. PIO-X RA destination address . . . . . . . . . . . . . . 10 90 6.2. Detecting hosts to send PIO-X RAs to . . . . . . . . . . 10 91 6.3. Binding table requirements . . . . . . . . . . . . . . . 10 92 6.4. Preparations before sending a PIO-X RA . . . . . . . . . 11 93 6.5. Implementation considerations . . . . . . . . . . . . . . 11 95 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 100 10.2. Informative References . . . . . . . . . . . . . . . . . 12 101 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 104 1. Introduction 106 This document defines a new control bit in the Internet Protocol 107 version 6 (IPv6) Router Advertisement (RA) Prefix Information Option 108 (PIO) flags octet that indicates that the node receiving this RA is 109 the exclusive receiver of all traffic destined to any address with 110 that prefix. Subject to the lifetime constraints within the PIO, the 111 receiving node effectively has exclusive use of the prefix, and will 112 be the next hop destination for the sending router, and possibly 113 other routers, for all traffic destined toward the prefix. 115 Termed the eXclusive bit (or "X bit"), nodes that recognize this can 116 perform some traffic-saving optimizations (e.g. disable Neighbor 117 Discovery (ND) and Duplicate Address Detection (DAD) for addresses 118 within this prefix) and more immediately pursue the benefits of being 119 provided multiple addresses (vis. [RFC7934] section 3). 121 Additionally, network infrastructure nodes (routers, switches) can 122 benefit by minimizing the number of {link layer, IP} address pairs 123 required to offer network connectivity (vis. [RFC7934] section 9.3). 124 A router, for example, need not create any {link layer, IP} address 125 pair entries for IP address within a proffered exclusive-use prefix-- 126 it can reliably forward all traffic to the network node to which it 127 advertised the prefix. This solves a potential link layer state 128 exhaustion problem, i.e excessive number of {link layer, IP address 129 pairs}, using IP layer forwarding. 131 Use of the X bit is backward compatible with existing IPv6 standards 132 compliant implementations. [RFC4861]-compliant nodes that do not 133 understand the X bit are not negatively impacted. They must ignore 134 it, and can process the PIO under existing standards, making use of 135 the information exactly as if the X bit were not set. 137 2. Motivation 139 There are several initiatives that propose network side practices 140 that provide customer isolation, enhanced operational scalability, 141 power efficiency, security and other benefits in IPv6 network 142 deployments. Some of these involve isolating a host (or RA accepting 143 client node) so that the host is the only node to receive a specific 144 prefix, including 146 o DHCPv6 Prefix Delegation to hosts (), and 149 o advertising a unique prefix per host via unique RAs. 150 (). 153 Some architectures further isolate the host layers below IPv6, for 154 improved client node security. Regardless of the specific level of 155 isolation, the host can best make optimizations and choices about its 156 use of a prefix exclusively forwarded to itself if the host can be 157 informed of the exclusivity. In the case of a DHCPv6 Prefix 158 Delegation the prefix can be assumed to be of exclusive use by the 159 requesting node (in accordance with the model in [RFC3633]). 161 This memo documents an additional bit in the IPv6 RA PIO that makes 162 this information explicit to receiving node. 164 3. Terminology 166 3.1. Requirements Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [RFC2119]. 172 3.2. Abbreviations 174 Throughout this document the following terminology is used purely for 175 the sake of brevity. 177 3.2.1. PIO-X 179 The term "PIO-X" is used to refer to a Prefix Information Option 180 (PIO) that has the X bit set. 182 3.2.2. PIO-X RA 184 The phrase "PIO-X RA" is used to refer to an IPv6 Router 185 Advertisement (RA) that contains one or more PIO-X entries (the same 186 RA may also contain one or more PIOs without the X bit set). 188 3.2.3. Host 190 The term "host" may be used interchangeably throughout this document 191 to mean a network node receiving and processing an RA. The receiving 192 node may itself be a router, or may temporarily become one by routing 193 all or a portion of an exclusive use prefix. 195 4. Updated Prefix Information Option 197 This document updates the Prefix Information Option specification in 198 RFC 4861, section 4.6.2 with the definition of a bit from the former 199 Reserved1 field as follows. 201 4.1. Updated format description 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type | Length | Prefix Length |L|A|X| Rsrvd1 | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Valid Lifetime | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Preferred Lifetime | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Reserved2 | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | 215 + + 216 | | 217 + Prefix + 218 | | 219 + + 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Fields: 225 X The eXclusive use indicator flag, defined by this document. 226 When set, the receiving node can be assured that all traffic 227 destined to any address within the specified Prefix will be 228 forwarded to itself by, at a minimum, the router from which 229 the encapsulating RA was received, but possibly other routers 230 as well. 232 When not set, the receiving node MUST NOT make any 233 assumptions of exclusive use of the specified Prefix, i.e. 234 processing is unchanged from previous standards behaviour. 236 Rsrvd1 Retains the same meaning as Reserved1 from section 237 4.6.2. 239 All Retain their same meaning from section 4.6.2. 240 other 241 fields 243 4.2. Processing 245 Nodes compliant with this specification perform the following 246 additional processing of RAs and PIO-X options when a PIO-X option is 247 present. 249 4.2.1. Verify sole recipient 251 A node receiving a PIO-X option MUST verify that it is the (likely) 252 sole intended recipient of the PIO-X RA. This done by verifying that 253 the RA is unicast to the node at the IPv6 layer and, if applicable, 254 at the link layer. On links that provide the node with a guarantee 255 that it is the only possible PIO-X RA recipient (e.g. PPP, 3GPP 256 links) this validation step SHOULD NOT be performed. 258 If an address other than :: (the unspecified address) was used as the 259 source address for one or more Router Solicitations (RS) on this 260 link, the node MUST verify that the IPv6 destination address of the 261 PIO-X RA is one of the RS source addresses in use. If the link over 262 which this communication takes place is known to be point-to-point, 263 i.e. the nature of the link ensures that the node is the only 264 possible recipient of an RA this check SHOULD NOT be performed. 266 If the node receives a PIO-X RA over a link-layer medium that 267 supports link-layer addresses, it MUST verify that the link-layer 268 destination address of the PIO-X RA is its own link-layer address. 269 If the node received a PIO-X RA over a point-to-point medium (such as 270 PPP) this step is unnecessary. 272 If any part of this "sole unicast recipient" verification fails, the 273 node MUST ignore the PIO-X bit and continue processing as if it were 274 not set (X=0). 276 4.2.2. (Re)Interpretation of other flags 278 Nodes compliant with this specification, i.e. those that understand 279 the X-bit, MUST, when the X-bit is set, ignore the actual values of 280 the L and A flags and instead interpret them as follows: 282 o interpret the L bit as if it were 0 (L=0) 284 o interpret the A bit as it it were 1 (A=1) 286 The rationale for this is as follows. 288 4.2.2.1. PIO L bit 290 Because a PIO-X aware node will know that it has exclusive use of a 291 prefix with non-zero valid lifetime, the prefix itself cannot be 292 considered to be on-link with respect to the link on which the PIO-X 293 RA was received. 295 Note that a given address from within the prefix may be considered 296 on-link according to the definition in section 4, item 1, 297 should the receiving node chose to configure that address on said 298 link, but this is in no way synonymous with the entire prefix being 299 considered on-link. 301 4.2.2.2. PIO A bit 303 Because a PIO-X aware node will know that it has exclusive use of a 304 prefix with non-zero valid lifetime, autoconfiguration of addresses 305 according to any desired scheme, e.g. , , et 306 cetera, is implicit in the setting of the X bit. 308 Accordingly, the A bit can be interpreted as having been set, should 309 the host choose to apply standard address generation schemes that 310 require the bit to be set. It is free to assign any address formed 311 from an exclusive prefix to any available interface; it is not 312 required to configure the address on the link over which the PIO-X RA 313 was received (i.e. it is under no obligation to form addresses such 314 that they would be classified as on-link (according to the definition 315 in section 4, item 1). 317 4.3. Transmitting PIO-X RAs 319 When a router transmits an RA containing one or more PIO-X options it 320 MUST unicast the PIO-X RA to its intended recipient at the IPv6 layer 321 and, if applicable, at the link-layer. 323 It is RECOMMENDED that a PIO with the X-bit set also have the PIO 324 flags L=0 and A=1 explicitly configured, for backward compatibility 325 (i.e. use by non X-bit aware nodes). 327 5. Host behaviour 329 TODO: This section needs some work. 331 5.1. PIO-X processing 333 A receiving node compliant with this document processes an RA with a 334 PIO entry with the X flag set according the requirements in previous 335 standards documents (chiefly section 6.3.4) subject to the 336 additional requirements documented in Section 4.2. 338 5.2. Neighbor Discovery implications 340 5.2.1. Duplicate Address Detection (DAD) 342 Whatever use the host makes of the exclusive prefix during its valid 343 lifetime, it SHOULD NOT perform Duplicate Address Detection ("DAD", 344 section 5.4) on any address it configures from within the 345 prefix if that address is configured on either the interface over 346 which the PIO-X RA was received or on a loopback interface. Note 347 that this does not absolve the host from performing DAD in all 348 scenarios; if, for example, the host uses the prefix for 64sharing 349 [1] it MUST at a minimum defend via DAD any addresses it has 350 configured for itself as documented in Requirement 2 of 351 section 3. 353 5.2.2. Router Solicitations (RSes) 355 Routers announcing PIO-X RAs do so via IPv6 unicast to the intended 356 receiving node and may note the IPv6 unicast destination address of 357 an RS as the next hop for the exclusive prefix. As such, hosts 358 compliant with this SHOULD NOT use the unspecified address (::) when 359 sending RSes; they SHOULD prefer issuing Router Solicitations from a 360 link-local address. 362 It is possible for a node to receive multiple RAs with a mix of 363 exclusive and non-exclusive PIOs and even non-zero and zero default 364 router lifetimes. While it is not possible for a host (receiving 365 node) to be sure it has received all the RA information available to 366 it, hosts compliant with this specification SHOULD implement Packet- 367 Loss Resiliency for Router Solicitations [RFC7559] so that the host 368 continues to transmit Router Solicitations at least until an RA with 369 a non-zero default router lifetime has been seen. 371 5.3. Link-local address behaviour 373 Routers announcing PIO-X RAs may record the source (link-local) 374 address of an RS as the next hop for the exclusive prefix. A node 375 compliant with this specification MUST continue to respond to 376 Neighbor Solicitations for the source address used to send RSes 377 (alternatively: the destination address of unicast PIO-X RAs 378 received). Hosts that deprecate or even remove this address may 379 experience a loss of connectivity. 381 5.4. Source address selection 383 No change to existing source address selection behaviour is required 384 or specified by this document. 386 5.5. Next hop router selection 388 No change to existing next hop router selection behaviour is required 389 or specified by this document. 391 5.6. Additional guidance 393 The intent of networks that use PIO-X RAs is not to enable 394 sophisticated routing architectures that could be far better handled 395 by an actual routing protocol but rather to propagate a prefix's 396 exclusive use information to enable the receiving node to make better 397 use of the available addresses. As such: 399 A PIO-X receiving node SHOULD NOT issue ICMPv6 Redirects 400 ([RFC4861] section 4.5) for any address within an exclusive use 401 prefix via the link over which the PIO-X RA was received. 402 Redirecting portions of exclusive prefixes to other "upstream" on- 403 link nodes is not a supported configuration. 405 A PIO-X receiving node SHOULD NOT transmit RAs with any subset of 406 its exclusive prefixes via the same interface through which the 407 exclusive prefix was learned. 409 6. Router behaviour 411 TODO: This section needs some work. 413 6.1. PIO-X RA destination address 415 Since the host will not perform DAD for addresses within prefix 416 announced via PIO-X, it's very important that only a single host 417 receives the PIO-X RA. Therefore, the router MUST only include PIO-X 418 in RAs that are sent using unicast RAs to destination unicast link- 419 layer address and IPv6 link-local unicast address for a specific 420 host. For point-to-point media without link-layer addresses or where 421 there is guaranteed to only be single host that will receive the 422 PIO-X RA (e.g. as enforced by link layer mechanisms), the router MAY 423 send PIO-X RA with multicast destination IPv6 address. Under all 424 circumstances the router MUST maintain a binding table of state 425 information as discussed in Section 6.3. 427 6.2. Detecting hosts to send PIO-X RAs to 429 When the host starts using a network connection it normally sends out 430 an RS (Router Solicitation) packet. This is one way for the router 431 to detect that a new host is connected to the network and detects its 432 link-local address. If the router is configured to use PIO-X, it can 433 now perform necessary processing/configuration and then send the 434 PIO-X RA. 436 For some networks, the host information regarding link-layer and 437 link-local address might be available through other mechanism(s). 438 Examples of this are PPP, 802.1x and 3GPP mobile networks. In that 439 case this information MAY be used instead of relying on the host to 440 send RS. It is however RECOMMENDED that these networks also provide 441 indication whether the host is no longer connected to the network so 442 that the router can invalidate the prefix binding prior to binding 443 expiration (timeout). 445 6.3. Binding table requirements 447 R1 The router SHOULD keep track of which PIO-X prefix has been 448 issued to each node. 450 R2 The router SHOULD keep the binding between prefix and link-local 451 address for the advertised valid lifetime, plus some 452 operationally determined delay prior to reissuing a prefix 453 ("grace period"), of the prefix. 455 R3 The router MUST monitor the reachability of each node in the 456 binding table via Neighbor Unreachability Detection ("NUD", 457 section 7.3) or an equivalent link-layer mechanism. 459 R4 The binding SHOULD be considered refreshed every time a periodic 460 PIO-X RA is sent to a node. 462 R5 If the router is informed by some other mechanism (link-layer 463 indication for instance) that a node is no longer connected to 464 the link, it MAY immediately invalidate the prefix binding. 465 (DISCUSS: Is this the correct approach? Do we want to point to 466 some definition somewhere else?) 468 6.4. Preparations before sending a PIO-X RA 470 When the router intends to send a PIO-X RA, it SHOULD before sending 471 the PIO-X RA, complete all necessary processing needed for the host 472 to start using the PIO-X prefix to communicate through the router to 473 other networks. This is so that the host can start using PIO-X based 474 addresses immediately after reception of the PIO-X RA. 476 6.5. Implementation considerations 478 TODO: Out of scope things that are worth careful consideration 479 include... 481 Routers SHOULD NOT announce the same prefix to two different nodes 482 within the valid lifetime of the earlier of the two PIO-X 483 announcements. 485 A link may operate in a mode where routers announce RAs to all nodes, 486 possibly with non-exclusive PIO data, and non-zero default router 487 lifetimes. Separately, one or more other nodes on the link may 488 announce exclusive PIO information to nodes along with zero default 489 router lifetimes. Except in the presence of a non-expired more 490 specific route, e.g. learning from an Route Information 491 Option (RIO), the receiving node should send exclusive use prefix 492 originated or forwarded traffic destined off-link through routers 493 with non-zero default router lifetimes. 495 7. Acknowledgements 497 8. IANA Considerations 499 This memo contains no requests of IANA. 501 9. Security Considerations 503 This document fundamentally introduces no new protocol or behaviour 504 substantively different from existing behaviour on a link which 505 guarantees a unique /64 prefix to every attached host. It only 506 describes a mechanism to convey that topological reality, allowing 507 the host to make certain optimizations as well as share the exclusive 508 prefix as it sees fit with other nodes according to its capabilities 509 and policies. 511 10. References 513 10.1. Normative References 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, 517 DOI 10.17487/RFC2119, March 1997, 518 . 520 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 521 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 522 DOI 10.17487/RFC4861, September 2007, 523 . 525 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 526 Address Autoconfiguration", RFC 4862, 527 DOI 10.17487/RFC4862, September 2007, 528 . 530 [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss 531 Resiliency for Router Solicitations", RFC 7559, 532 DOI 10.17487/RFC7559, May 2015, 533 . 535 10.2. Informative References 537 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 538 Host Configuration Protocol (DHCP) version 6", RFC 3633, 539 DOI 10.17487/RFC3633, December 2003, 540 . 542 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 543 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 544 November 2005, . 546 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 547 "Host Address Availability Recommendations", BCP 204, 548 RFC 7934, DOI 10.17487/RFC7934, July 2016, 549 . 551 10.3. URIs 553 [1] RFC7278 555 Authors' Addresses 557 Erik Kline 558 Google Japan KK 559 6-10-1 Roppongi 560 Mori Tower, 44th floor 561 Minato, Tokyo 106-6126 562 JP 564 Email: ek@google.com 566 Mikael Abrahamsson 567 T-Systems Nordic 568 Kistagangen 26 569 Stockholm 570 SE 572 Email: Mikael.Abrahamsson@t-systems.se