idnits 2.17.1 draft-naveen-slaac-prefix-management-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 6, 2018) is 1997 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ADDRCONF' is mentioned on line 291, but not defined == Missing Reference: 'SEND' is mentioned on line 599, but not defined == Unused Reference: 'RFC2629' is defined on line 637, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 666, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-kaiser-nd-pd-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Naveen Kottapalli, Ed. 3 Internet-Draft Benu Networks 4 Intended status: Informational November 6, 2018 5 Expires: May 10, 2019 7 IPv6 Stateless Prefix Management 8 draft-naveen-slaac-prefix-management-00 10 Abstract 12 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a 13 provision for the hosts to request for a specific IPv6 address and 14 manage the same, whereas the StateLess Address AutoConfiguration 15 (SLAAC) doesn't have such a provision. Also, unavailability of 16 DHCPv6 across all OS platforms has limited the IPv6 nodes to not use 17 features like soliciting a prefix of desired length and lifetime, 18 renewing, releasing / declining a prefix, etc. This document 19 proposes IPv6ND extensions for enabling SLAAC devices to solicit 20 prefix information as a hint PIO in RS and other methods like 21 renewing or releasing or declining a prefix without introducing any 22 new ICMPv6 message or option types. 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 May 10, 2019. 41 Copyright Notice 43 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1.1. /64 Prefix . . . . . . . . . . . . . . . . . . . . . 3 62 2.1.2. Non /64 Prefix . . . . . . . . . . . . . . . . . . . 3 63 2.1.3. Requesting Node . . . . . . . . . . . . . . . . . . . 3 64 2.1.4. Delegating Node or Router . . . . . . . . . . . . . . 4 65 2.1.5. Requirements Language . . . . . . . . . . . . . . . . 4 66 3. Related works . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4.1. Host Soliciting a Prefix . . . . . . . . . . . . . . . . 4 69 4.2. CPE or Downstream Router Soliciting a Prefix . . . . . . 5 70 5. Soliciting Prefix . . . . . . . . . . . . . . . . . . . . . . 6 71 5.1. Requesting Node Specification . . . . . . . . . . . . . . 6 72 5.2. Delegating Router Specification . . . . . . . . . . . . . 8 73 6. Renewing Prefix . . . . . . . . . . . . . . . . . . . . . . . 9 74 6.1. Requesting Node Specification . . . . . . . . . . . . . . 10 75 6.2. Delegating Router Specification . . . . . . . . . . . . . 10 76 7. Releasing Prefix . . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. Requesting Node Specification . . . . . . . . . . . . . . 11 78 7.2. Delegating Router Specification . . . . . . . . . . . . . 11 79 8. Declining Prefix . . . . . . . . . . . . . . . . . . . . . . 12 80 8.1. Requesting Node Specification . . . . . . . . . . . . . . 12 81 8.2. Delegating Router Specification . . . . . . . . . . . . . 12 82 9. Processing Router Advertisements . . . . . . . . . . . . . . 12 83 10. Unsolicited Router Advertisements . . . . . . . . . . . . . . 12 84 10.1. Requesting Node Specification . . . . . . . . . . . . . 12 85 10.2. Delegating Router Specification . . . . . . . . . . . . 12 86 11. Backward Compatibility . . . . . . . . . . . . . . . . . . . 13 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 90 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 15.2. Informative References . . . . . . . . . . . . . . . . . 14 93 Appendix A. Comparison with other works . . . . . . . . . . . . 15 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 IPv6 StateLess Address AutoConfiguration (SLAAC) [ADDRCONF] in its 99 current form doesn't offer services like soliciting a prefix of 100 specific length or for a stipulated time forces the nodes to be 101 dictated solely by the routers that assigns the prefixes. Though a 102 SLAAC node uses the prefix received from a router, at times a host 103 might want to make sure that the prefix is still valid with the 104 router and may want to renew the prefix with router. Similarly, 105 since every prefix that the router assigns to a node is a resource 106 that costs the router w.r.t routing and subscriber management, the 107 router also wants to release the prefixes back to free pool those are 108 not being used by the SLAAC nodes. 110 This document presents an IPv6 ND based messaging protocol as an 111 extension for SLAAC nodes that do similar things as does DHCPv6 112 protocol. For example, soliciting or renew or release or decline a 113 prefix using existing standards. 115 2. Terminology 117 2.1. General 119 This document uses the same terminology defined in IPv6 Neighbor 120 Discovery RFC 4861 [RFC4861], IPv6 Stateless Address 121 Autoconfiguration RFC 4862 [RFC4862] 123 2.1.1. /64 Prefix 125 An IPv6 prefix of length 64 bits, which will be used by the end nodes 126 for preparing and using a /128 bit address. 128 2.1.2. Non /64 Prefix 130 An IPv6 prefix of length less than 64 bits, which will be used by 131 nodes as a pool of prefixes for allocating either /64 prefixes or a 132 non /64 prefix (subnet of the prefix pool) to the downstream nodes. 134 2.1.3. Requesting Node 136 A requesting node is a node that can be either a host / CPE / a 137 downstream router etc. that is soliciting a prefix from router. If a 138 host (end device) is soliciting a prefix, the prefix length will 139 always be /64-bit, whereas if a CPE / downstream router is soliciting 140 a prefix it can be a non /64-bit. 142 2.1.4. Delegating Node or Router 144 A delegating node or router is a node that assigns either 64-bit 145 length prefixes or non 64-bit length prefix to requesting nodes. A 146 delegating node or router MAY also do subscriber management along 147 with the routing functionality. 149 2.1.5. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 3. Related works 157 A few drafts regarding prefix negotiation, prefix return were defined 158 as a protocol set earlier. 160 In [NDPD], authors proposed a new PI option with a list of operation 161 types that can be exchanged with the router. 163 In [HPD], authors proposed new ICMPv6 message types that can be 164 exchanged with the router for prefix negotiation. 166 In [PIO-X], authors proposed new flag 'X' to be set in PIO flags 167 field, which indicates that prefix received in a PIO is for host's 168 exclusive use. 170 In [UNIFIED], the author proposes including a PIO option in RS 171 messages. This document uses the same mechanism, but without 172 including any new PIO flag bits. 174 The mechanism described in this document though follows some similar 175 approach of other works, no new ICMPv6 messages or new option types 176 are introduced, and not even new flags to be set in the PIO option. 177 This specification uses the existing messages types and PIO option to 178 achieve the objective. 180 4. Use cases 182 4.1. Host Soliciting a Prefix 184 A host SHALL solicit one or more 64-bit length prefixes [RFC7934] 185 from a router; following can be the cases where a host wants to 186 solicit prefixes from the available routers. 188 o A host wants to use any prefix given by router only for a 189 stipulated period. 191 o A host wants to use a prefix only for a stipulated time period. 193 o A host wants to use the same prefix that was received earlier from 194 router. An example of this can be like when mobility happens the 195 host solicits for the same prefix that was used earlier. 197 o A host wants to assign a specific on-link prefix to the interface 198 (the way how a host gets the prefix information is out of scope of 199 this document). 201 o A host wants to assign a specific off-link prefix to the interface 202 (the way how a host gets the prefix information is out of scope of 203 this document). 205 o A host wants to renew an existing prefix with the same router from 206 where the prefix was received. 208 +--------+ /64 prefix in PIO of RS +--------+ 209 | |------------------------------->| Router | 210 | Host | | / | 211 | |<-------------------------------| CPE | 212 +--------+ /64 prefix in PIO of RA +--------+ 214 Figure 1 216 4.2. CPE or Downstream Router Soliciting a Prefix 218 A CPE or downstream router SHALL solicit one or more non /64-bit 219 length prefixes [RFC7934] from routers and assigns either /64-bit or 220 a subnet from the received prefix to downstream nodes. Following can 221 be the cases where a CPE or downstream router wants to solicit 222 prefixes from the available routers. 224 o A CPE or downstream router wants to use any non /64-bit prefix for 225 a stipulated time period. 227 o A CPE or downstream router wants to use a non /64-bit prefix for a 228 stipulated time period. 230 o A CPE or downstream router wants to use a specific on-link non 231 /64-bit prefix of length 'n' bits, where 'n' is less than 64 bits. 233 o A CPE or downstream router wants to use a specific off-link non 234 /64-bit prefix of length 'n' bits, where 'n' is less than 64 bits. 236 o A CPE or downstream router wants to renew an existing prefix with 237 the same router from where the prefix was received. 239 +----------+ 240 | Host-1 |\ /64 prefix 241 +----------+ \ 242 +----------+ \ 243 | Router |\ \ non /64 prefix 244 +----------+ \ \ 245 \ \ 246 +----------+ non /64 prefix +-----+ non /64 prefix +--------+ 247 | CPE | - - - - - <-->| CPE |<---------------->| Router | 248 +----------+ / / +-----+ non /64 prefix +--------+ 249 / / 250 +----------+ / / 251 | Router |/ / non /64 prefix 252 +----------+ / 253 +----------+ / 254 | Host-n |/ /64 prefix 255 +----------+ 257 Figure 2 259 A CPE or downstream router MAY decide on the length of non /64 prefix 260 based on the number of downstream nodes that a CPE or downstream 261 router has to cater the services. If the CPE or downstream router 262 has a requirement to cater 256 downstream nodes, then the prefix 263 length inside a PIO will be set to 56. The logic of how a CPE or 264 downstream router knows the prefix length is out of scope of this 265 document. 267 5. Soliciting Prefix 269 5.1. Requesting Node Specification 271 Requesting nodes that are compliant with this specification MAY 272 append PIO option(s) in RS [UNIFIED], which can be triggered when one 273 of the events mentioned in IPv6 Neighbor Discovery [RFC4861] occurs. 275 A requesting node MAY set the desired length of prefix it wants to 276 solicit in the length field of each PIO that is included in RS. In 277 the absence of a valid length field i.e., when the prefix length of a 278 PIO is set to 0, by default the router assumes the length to be a 279 64-bit. 281 A requesting node MAY set the following flags of the PIO option when 282 soliciting a prefix. 284 L - 1-bit on-link flag. When set to 1, it means that a requesting 285 node is soliciting a prefix that is considered as on-link. When 286 set to 0, it means that a requesting node is soliciting a prefix 287 that can be considered as off-link. 289 A - 1-bit autonomous auto address configuration flag. When set 290 indicates that this prefix can be used for stateless address 291 configuration as specified in [ADDRCONF]. 293 R - TODO - To be filled with use case. 295 A requesting node MUST set PIO's valid lifetime field to a positive 296 integer value that is intended to be used or 0xffffffff. While 297 soliciting a prefix a requesting node MUST NOT set the valid lifetime 298 field of a PIO with 0. 300 A requesting node MAY set multiple desired prefixes that are intended 301 to be used in each of the PIO option included in RS. In the absence 302 of valid prefix in a PIO i.e. when the requesting node do not have 303 any prefix information to be set in a PIO, value of prefix MUST be 304 set to '::', while the other fields of PIO like prefix length, flags 305 and valid lifetime are set. Since a NULL prefix in a PIO ('::') 306 indicates a router that the requesting node is ready to take any 307 prefix(es) that router assigns, a requesting node MUST NOT include 308 more than one NULL prefix PIOs('::') in a RS. 310 An example of when a requesting node might include prefix in a PIO 311 is, a node already has a prefix and due to mobility event the node 312 triggers another RS. In such a case since the node already has a 313 valid prefix which is under use, the same prefix SHALL be added in a 314 PIO of RS that is being sent towards router. 316 An example of when a requesting node does not include prefix in a PIO 317 is, a requesting node's interface is brought up without any prior 318 prefix information available and the requesting node is looking for 319 any of either /64 bit prefix or non /64 bit prefix for a stipulated 320 time. 322 If the requesting node already has the information about the router 323 from where the prefix was received earlier, RS with PIO included MAY 324 be unicast to that particular router. A requesting node SHOULD 325 transmit up to MAX_RTR_SOLICITATIONS [RFC4861] RS messages, each 326 separated by at least RTR_SOLICITATION_INTERVAL [RFC4861] seconds. 328 In the absence of RA even after maximum attempts or on receipt of RA 329 with the prefixes that requesting node has solicited with 0 life time 330 MUST be treated as the solicited prefixes (if any) are no more 331 available for the requesting node and all such prefixes MUST be 332 discarded. Also, it is highly discouraged to not send another RS 333 with prefixes in PIOs for which there is no RA or RA is received with 334 life time as 0. If a requesting node does not get RA for all the 335 PIOs even after MAX_RTR_SOLICITATIONS times, the requesting node MUST 336 send a RS by excluding the PIO option(s). 338 Requesting nodes while soliciting prefix(es), SHALL use the Nonce 339 option [SEND] in RS message as transaction id to track the request 340 and response messages. 342 5.2. Delegating Router Specification 344 The routers that are compliant with this specification look for the 345 PIO option(s) present in RS and checks if a prefix can be assigned to 346 the requesting node or not. 348 If prefix length in a PIO option is set to non-zero value, router 349 checks its configuration if the desired prefix length can be 350 allocated or not. If the prefix length of a PIO is set to a value 351 less than 64 and if the router configuration doesn't allow prefix 352 allocation of non /64 or the desired prefix length, then the PIO 353 option MUST be ignored. If prefix length in a PIO option is set to 354 zero (0), then router assumes that the requesting node is soliciting 355 a /64 prefix. 357 A router checks for the following flags in the PIO option when 358 present in RS. 360 L - When set to 1, the router checks if the solicited prefix can 361 be assigned to the device or not which considers the prefix as 362 "on-link". If the router's configuration doesn't allow "on-link" 363 prefix allocation, then the PIO option MUST be ignored. When set 364 to 0, the router checks if the solicited prefix can be assigned to 365 the device or not which considers the prefix as "off-link". If 366 the router's configuration doesn't allow "off-link" prefix 367 allocation, then the PIO option MUST be ignored. 369 A - The router checks if the solicited prefix can be assigned to 370 the device or not which uses the prefix for autonomous auto 371 address configuration. If the router's configuration doesn't 372 allow prefix allocation for autonomous auto address configuration, 373 then the PIO option MUST be ignored. 375 R - TODO - To be filled with use case. 377 If valid lifetime inside a PIO is set to 0xffffffff, then routers 378 configured lifetime will be considered. If valid lifetime inside PIO 379 is set to a positive integer value that a requesting node wants to 380 use, router checks its own configuration and if the solicited 381 lifetime is less than or equal to the router's allowed configuration, 382 then the solicited lifetime SHALL be granted to the PIO and will be 383 included in RA. If the router's configured lifetime is less than 384 solicited lifetime, and there is no barring of such PIOs, router 385 SHALL include the router's configured lifetime in RA. If the valid 386 lifetime of a PIO that is chosen based on above logic is less than 387 the router's preferred lifetime configuration, then the valid 388 lifetime value itself SHALL be copied to preferred lifetime of PIO. 390 If the prefix inside a PIO option is non NULL i.e. some valid prefix 391 is received, then router checks if the solicited prefix with the 392 requested length is available or not. If such prefix is available 393 and can be allocated, then the router SHALL assign the prefix and 394 include in the PIO option of RA. If the solicited prefix is not 395 available, then PIO option MUST be ignored. If the prefix inside a 396 PIO option is a NULL prefix ('::'), then router SHALL assign one of 397 the prefixes that are available and include the PIO option in RA. If 398 there are more than one NULL prefix PIOs present in RS, then the 399 router MUST process only one NULL prefix PIO ('::') and rest of NULL 400 prefix PIOs SHALL be ignored. 402 If a router can assign any one of the solicited prefixes with the 403 requested prefix length and lifetime, a RA SHALL be sent back to the 404 requesting node with such PIOs included. For any reason, if a router 405 is not able to assign any of the prefixes from the PIO option(s) 406 received in RS, no RA SHALL be sent by router. This lets the other 407 routers who can assign the prefix to respond and the network will not 408 be choked with unnecessary RAs. 410 A router MUST send a deprecated PIO in RA to the received PIO of RS 411 in the following cases. 413 o RS is unicast to the router and the prefix inside a PIO is non 414 NULL 416 o 418 * PIO cannot be honored because of either prefix length or 419 lifetime or flags 421 * PIO cannot be honored because of unavailability of solicited 422 prefix 424 6. Renewing Prefix 425 6.1. Requesting Node Specification 427 Requesting nodes that are compliant with this specification MAY renew 428 a prefix based on events such as: 430 o Prefix is used for 1/3rd of the prefix lifetime 432 o Any other period that a requesting node wants to renew at 434 Requesting nodes that are compliant with this specification when 435 trying to renew a prefix, shall prepare the RS message the same way 436 as mentioned in the Soliciting section and the RS message is unicast 437 to the router from where the prefixes were received. A requesting 438 node SHOULD transmit up to MAX_RTR_SOLICITATIONS [RFC4861] RS 439 messages, each separated by at least RTR_SOLICITATION_INTERVAL 440 [RFC4861] seconds. In the absence of RA even after maximum attempts, 441 a requesting node MAY continue using the prefix till the prefix 442 lifetime expires. In case when a RA is received with zero lifetime 443 for the prefixes that requesting node had solicited; those prefixes 444 MUST be treated as no more available for the requesting node and all 445 such prefixes MUST be discarded immediately. Also, it is highly 446 discouraged to not send the prefixes in PIOs for which there is no RA 447 or RA is received with life time as 0. If a requesting node does not 448 get RA for all the PIOs even after MAX_RTR_SOLICITATIONS times, the 449 requesting node MUST send a RS by excluding the PIO option(s). 451 Requesting nodes while renewing prefix(es), SHALL use the Nonce 452 option [SEND] in RS message as transaction id to track the request 453 and response messages. 455 6.2. Delegating Router Specification 457 When a router receives a RS message that is unicast and has valid 458 prefix information in PIOs, router checks if the prefix lease context 459 of requesting node is already present in its lease database or not. 460 If the lease context is present; it means that the requesting node is 461 trying to renew the prefix. If the lease context is not present, the 462 RS MUST be treated as solicitation and process the RS as described in 463 Solicitation section. While renewing a prefix of the requesting node 464 routers SHALL just refer the prefix lifetime and ignore the other 465 fields of PIO that were considered during solicitation. 467 If prefix valid lifetime inside a PIO is set to a non-zero value that 468 a requesting node wants to use, router checks its own configuration 469 and if the solicited lifetime + elapsed lifetime is less than or 470 equal to the routers total allowed configuration, then the solicited 471 lifetime SHALL be granted to the PIO and will be included in RA. If 472 the router's configured lifetime is less than solicited lifetime + 473 elapsed lifetime and if the router's configuration restricts barring 474 such PIOs, the PIO option SHALL be ignored. 476 If the valid lifetime of a PIO that is chosen based on above logic is 477 less than the router's preferred lifetime configuration, then the 478 valid lifetime value itself SHALL be copied to preferred lifetime of 479 PIO. 481 7. Releasing Prefix 483 7.1. Requesting Node Specification 485 Requesting nodes that are compliant with this specification MAY 486 release a prefix based on events such as: 488 o Lifetime of the prefix got expired and the requesting node does 489 not want to use the prefix anymore. 491 o Interface to which the prefix got assigned is brought down 493 A requesting node that wants to release prefixes back to router MUST 494 set the lifetime of each prefix to zero (0) in PIO option of RS and 495 MUST unicast to the router from where the prefixes were received. 497 Requesting nodes while releasing prefix(es), SHALL use the Nonce 498 option [SEND] in RS message as transaction id to track the request 499 and response messages. 501 7.2. Delegating Router Specification 503 When a router receives a RS message that is unicast and has valid 504 prefix information in PIOs with valid lifetime as zero (0), router 505 checks if the prefix lease context of requesting node is already 506 present in its lease database or not. If the lease context is 507 present, it means that the requesting node is trying to release the 508 prefix. If the lease context is not present, then the PIO SHALL be 509 ignored. Once the prefix context of the requesting node is released, 510 the prefix SHALL be marked as free and be made available for further 511 prefix allocations. 513 If a router is able to release a prefix with the mentioned prefix 514 length, a RA SHALL be sent back to the node with the same PIO option 515 and the lifetime set to 0. If a router is not able to release any of 516 the prefixes from the PIO option(s) received in RS, no RA SHALL be 517 sent by router. 519 8. Declining Prefix 521 8.1. Requesting Node Specification 523 Requesting nodes that are compliant with this specification MAY 524 decline a prefix based on events such as: 526 o Solicited prefix length is not assigned by a router. 528 o Solicited lifetime of the prefix is not assigned by a router. 530 Above list of events is not an exhaustive list of cases where the 531 requesting nodes decline the prefix and can be for any other reasons 532 as well. Requesting nodes follow the same method described in 533 Releasing section to decline a prefix. 535 8.2. Delegating Router Specification 537 The routers that are compliant with this specification treats a 538 decline as release and follow the same method described in Releasing 539 section. 541 9. Processing Router Advertisements 543 When a requesting node receives a RA from a router with PIO included, 544 the router's address SHALL be stored against each prefix and process 545 the RA using the procedure mentioned in [RFC4861]. The stored 546 router's address can be used while renewing or releasing or declining 547 the prefix. 549 10. Unsolicited Router Advertisements 551 10.1. Requesting Node Specification 553 When a requesting node receives an unsolicited RA from router for 554 which no RS was sent, that RA must be treated as an unsolicited RA 555 and SHALL be processed the same way defined in above sections. If a 556 requesting node doesn't like the prefix lifetime received in 557 unsolicited RA, a RS SHALL be triggered to renew the prefix. 559 10.2. Delegating Router Specification 561 Routers that are compliant with this specification follow the same 562 method defined in [RFC4861] for sending unsolicited router 563 advertisements. 565 11. Backward Compatibility 567 Routers that are compliant with this specification SHALL have the 568 below configuration elements to decide the router behaviour. 570 o Honoring the PIOs in RS - When a router is configured to not honor 571 the PIOs in RS, all the PIOs SHALL be ignored and the RS MUST be 572 processed as defined in [RFC4861]. 574 o Honoring non /64 prefix length PIOs in RS - When a router is 575 configured to not honor the PIOs that request non /64 prefix 576 length in RS, such PIOs SHALL be ignored and and the RS MUST be 577 processed as defined in [RFC4861]. 579 o Supported length of non /64 prefixes - A router can be configured 580 with the non /64 prefix lengths that are supported, so that the 581 PIOs in RS message can be honored. 583 o Ignore PIOs with lifetime greater than configured value - A router 584 can be configured to not honor the PIOs that solicit the prefix 585 lifetime more than the configured router's prefix lifetime. When 586 this flag is disabled, if a PIO in RS requests for a lifetime 587 greater than the configured value, then the router's configured 588 value shall be included in PIO of RA. 590 12. IANA Considerations 592 This memo includes no request to IANA. 594 13. Security Considerations 596 Security considerations for IPv6 Neighbor Discovery [RFC4861] and 597 DHCPv6 [RFC3315][RFC3633] apply to this document. 599 SEcure Neighbor Discovery (SEND) [SEND] can provide authentication 600 for RS/RA exchanges with no need for additional securing mechanisms. 602 14. Acknowledgements 604 This work was motivated by discussions on the 6man and v6ops list. 606 The following individuals contributed to the document: Fred Templin 608 The following individuals provided useful comments that improved the 609 document: Alexandre Petrescu 611 15. References 613 15.1. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, 617 DOI 10.17487/RFC2119, March 1997, 618 . 620 15.2. Informative References 622 [HPD] Byung-Yeob Kim, Kyeong-Jin Lee, Jung-Soo Park, Hyoung-Jun 623 Kim, "Hierarchical Prefix Delegation Protocol for Internet 624 Protocol Version 6 (IPv6)", February 2004, 625 . 627 [NDPD] A. Kaiser, S. Decremps, N. Oualha, A. Petrescu, "Prefix 628 Delegation extension to Neighbor Discovery protocol", 629 February 2013, . 632 [PIO-X] Kline, E. and M. Abrahamsson, "IPv6 Router Advertisement 633 Prefix Information Option eXclusive Flag", March 2017, 634 . 637 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 638 DOI 10.17487/RFC2629, June 1999, 639 . 641 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 642 C., and M. Carney, "Dynamic Host Configuration Protocol 643 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 644 2003, . 646 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 647 Text on Security Considerations", BCP 72, RFC 3552, 648 DOI 10.17487/RFC3552, July 2003, 649 . 651 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 652 Host Configuration Protocol (DHCP) version 6", RFC 3633, 653 DOI 10.17487/RFC3633, December 2003, 654 . 656 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 657 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 658 DOI 10.17487/RFC4861, September 2007, 659 . 661 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 662 Address Autoconfiguration", RFC 4862, 663 DOI 10.17487/RFC4862, September 2007, 664 . 666 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 667 IANA Considerations Section in RFCs", RFC 5226, 668 DOI 10.17487/RFC5226, May 2008, 669 . 671 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 672 "Host Address Availability Recommendations", BCP 204, 673 RFC 7934, DOI 10.17487/RFC7934, July 2016, 674 . 676 [UNIFIED] F. Templin, "A Unified Stateful/Stateless 677 Autoconfiguration Service for IPv6", September 2018, 678 . 681 Appendix A. Comparison with other works 683 TODO: Add the comparison details here. 685 Author's Address 687 Naveen Kottapalli (editor) 688 Benu Networks 689 300 Concord Road 690 Billerica, MA 01821 691 USA 693 Phone: +1 978 223 4700 694 Email: nkottapalli@benu.net