1 2 3 4 5 6 7Network Working Group O. Troan 8Request for Comments: 3633 R. Droms 9Category: Standards Track Cisco Systems 10 December 2003 11 12 13 IPv6 Prefix Options for 14 Dynamic Host Configuration Protocol (DHCP) version 6 15 16Status of this Memo 17 18 This document specifies an Internet standards track protocol for the 19 Internet community, and requests discussion and suggestions for 20 improvements. Please refer to the current edition of the "Internet 21 Official Protocol Standards" (STD 1) for the standardization state 22 and status of this protocol. Distribution of this memo is unlimited. 23 24Copyright Notice 25 26 Copyright (C) The Internet Society (2003). All Rights Reserved. 27 28Abstract 29 30 The Prefix Delegation options provide a mechanism for automated 31 delegation of IPv6 prefixes using the Dynamic Host Configuration 32 Protocol (DHCP). This mechanism is intended for delegating a long- 33 lived prefix from a delegating router to a requesting router, across 34 an administrative boundary, where the delegating router does not 35 require knowledge about the topology of the links in the network to 36 which the prefixes will be assigned. 37 38Table of Contents 39 40 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 41 2. DHCPv6 specification dependency . . . . . . . . . . . . . . 3 42 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 43 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 44 5. Model and Applicability . . . . . . . . . . . . . . . . . . 3 45 5.1. Example network architecture . . . . . . . . . . . . . 4 46 6. Identity Association for Prefix Delegation . . . . . . . . . 5 47 7. Overview of DHCP with Prefix Delegation . . . . . . . . . . 6 48 8. Interface Selection . . . . . . . . . . . . . . . . . . . . 7 49 9. Identity Association for Prefix Delegation Option . . . . . 7 50 10. IA_PD Prefix option . . . . . . . . . . . . . . . . . . . . 9 51 11. Delegating Router Solicitation . . . . . . . . . . . . . . . 11 52 11.1. Requesting router behavior . . . . . . . . . . . . . . 11 53 11.2. Delegating router behavior . . . . . . . . . . . . . . 11 54 12. Requesting router initiated prefix delegation . . . . . . . 12 55 56 57 58Troan & Droms Standards Track [Page 1] 59 60RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 61 62 63 12.1. Requesting router behavior . . . . . . . . . . . . . . 12 64 12.2. Delegating Router behavior . . . . . . . . . . . . . . 14 65 13. Prefix Delegation reconfiguration . . . . . . . . . . . . . 15 66 13.1. Delegating Router behavior . . . . . . . . . . . . . . 15 67 13.2. Requesting Router behavior . . . . . . . . . . . . . . 15 68 14. Relay agent behavior . . . . . . . . . . . . . . . . . . . . 15 69 15. Security Considerations . . . . . . . . . . . . . . . . . . 16 70 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 71 17. Intellectual Property Statement. . . . . . . . . . . . . . . 17 72 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 18.1. Normative References . . . . . . . . . . . . . . . . . 17 74 18.2. Informative References . . . . . . . . . . . . . . . . 17 75 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 76 20. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 77 21. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 78 791. Introduction 80 81 This document describes new options for Dynamic Host Configuration 82 Protocol (DHCP) that provide a mechanism for the delegation of IPv6 83 prefixes [1]. Through these options, a delegating router can 84 delegate prefixes to authorized requesting routers. 85 86 The prefix delegation mechanism described in this document is 87 intended for simple delegation of prefixes from a delegating router 88 to requesting routers. It is appropriate for situations in which the 89 delegating router does not have knowledge about the topology of the 90 networks to which the requesting router is attached, and the 91 delegating router does not require other information aside from the 92 identity of the requesting router to choose a prefix for delegation. 93 For example, these options would be used by a service provider to 94 assign a prefix to a Customer Premise Equipment (CPE) device acting 95 as a router between the subscriber's internal network and the service 96 provider's core network. 97 98 Many applications expect stable addresses. Even though this 99 mechanism makes automatic renumbering easier, it is expected that 100 prefixes have a long lifespan. During renumbering it is expected 101 that the old and the new prefix co-exist for some time. 102 103 The design of this prefix delegation mechanism meets the requirements 104 for prefix delegation in Requirements for IPv6 prefix delegation [6]. 105 106 Note that this use of DHCP is not bound to the assignment of IP 107 addresses or other configuration information to hosts, and that no 108 mechanism is currently available to communicate delegated prefixes to 109 a DHCP server that serves such a function. This may be an item of 110 future work, should usage warrant. 111 112 113 114Troan & Droms Standards Track [Page 2] 115 116RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 117 118 1192. DHCPv6 specification dependency 120 121 This document describes new DHCPv6 options for IPv6 prefix 122 delegation. This document should be read in conjunction with the 123 DHCPv6 specification, RFC 3315 [2], for a complete specification of 124 the Prefix Delegation options and mechanism. Definitions for terms 125 and acronyms not specifically defined in this document are defined in 126 RFC 3315. 127 1283. Terminology 129 130 This document uses the terminology defined in RFC 2460 [1] and RFC 131 3315. In addition, this document uses the following terms: 132 133 requesting router: The router that acts as a DHCP client and is 134 requesting prefix(es) to be assigned. 135 136 delegating router: The router that acts as a DHCP server, and is 137 responding to the prefix request. 138 139 Identity Association for Prefix Delegation (IA_PD): A collection of 140 prefixes assigned to the requesting router. Each 141 IA_PD has an associated IAID. A requesting 142 router may have more than one IA_PD assigned to 143 it; for example, one for each of its interfaces. 144 1454. Requirements 146 147 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 148 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 149 document, are to be interpreted as described in BCP 14, RFC 2119 [3]. 150 1515. Model and Applicability 152 153 The model of operation for prefix delegation is as follows. A 154 delegating router is provided IPv6 prefixes to be delegated to 155 requesting routers. Examples of ways in which the delegating router 156 may be provided these prefixes are given in Section 12.2. A 157 requesting router requests prefix(es) from the delegating router, as 158 described in Section 12.1. The delegating router chooses prefix(es) 159 for delegation, and responds with prefix(es) to the requesting 160 router. The requesting router is then responsible for the delegated 161 prefix(es). For example, the requesting router might assign a subnet 162 from a delegated prefix to one of its interfaces, and begin sending 163 router advertisements for the prefix on that link. 164 165 166 167 168 169 170Troan & Droms Standards Track [Page 3] 171 172RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 173 174 175 Each prefix has an associated valid and preferred lifetime, which 176 constitutes an agreement about the length of time over which the 177 requesting router is allowed to use the prefix. A requesting router 178 can request an extension of the lifetimes on a delegated prefix and 179 is required to terminate the use of a delegated prefix if the valid 180 lifetime of the prefix expires. 181 182 This prefix delegation mechanism would be appropriate for use by an 183 ISP to delegate a prefix to a subscriber, where the delegated prefix 184 would possibly be subnetted and assigned to the links within the 185 subscriber's network. 186 1875.1. Example network architecture 188 189 Figure 1 illustrates a network architecture in which prefix 190 delegation could be used. 191 192 ______________________ \ 193 / \ \ 194 | ISP core network | \ 195 \__________ ___________/ | 196 | | 197 +-------+-------+ | 198 | Aggregation | | ISP 199 | device | | network 200 | (delegating | | 201 | router) | | 202 +-------+-------+ | 203 | / 204 |DSL to subscriber / 205 |premises / 206 | 207 +------+------+ \ 208 | CPE | \ 209 | (requesting | \ 210 | router) | | 211 +----+---+----+ | 212 | | | Subscriber 213 ---+-------------+-----+- -+-----+-------------+--- | network 214 | | | | | 215+----+-----+ +-----+----+ +----+-----+ +-----+----+ | 216|Subscriber| |Subscriber| |Subscriber| |Subscriber| / 217| PC | | PC | | PC | | PC | / 218+----------+ +----------+ +----------+ +----------+ / 219 220 Figure 1: An example of prefix delegation. 221 222 223 224 225 226Troan & Droms Standards Track [Page 4] 227 228RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 229 230 231 In this example, the delegating router is configured with a set of 232 prefixes to be used for assignment to customers at the time of each 233 customer's first connection to the ISP service. The prefix 234 delegation process begins when the requesting router requests 235 configuration information through DHCP. The DHCP messages from the 236 requesting router are received by the delegating router in the 237 aggregation device. When the delegating router receives the request, 238 it selects an available prefix or prefixes for delegation to the 239 requesting router. The delegating router then returns the prefix or 240 prefixes to the requesting router. 241 242 The requesting router subnets the delegated prefix and assigns the 243 longer prefixes to links in the subscriber's network. In a typical 244 scenario based on the network shown in Figure 1, the requesting 245 router subnets a single delegated /48 prefix into /64 prefixes and 246 assigns one /64 prefix to each of the links in the subscriber 247 network. 248 249 The prefix delegation options can be used in conjunction with other 250 DHCP options carrying other configuration information to the 251 requesting router. The requesting router may, in turn, then provide 252 DHCP service to hosts attached to the internal network. For example, 253 the requesting router may obtain the addresses of DNS and NTP servers 254 from the ISP delegating router, and then pass that configuration 255 information on to the subscriber hosts through a DHCP server in the 256 requesting router. 257 2586. Identity Association for Prefix Delegation 259 260 An IA_PD is a construct through which a delegating router and a 261 requesting router can identify, group and manage a set of related 262 IPv6 prefixes. Each IA_PD consists of an IAID and associated 263 configuration information. An IA_PD for prefixes is the equivalent 264 of an IA (described in RFC 3315) for addresses. 265 266 An IA_PD is different from an IA, in that it does not need to be 267 associated with exactly one interface. One IA_PD can be associated 268 with the requesting router, with a set of interfaces or with exactly 269 one interface. A requesting router must create at least one distinct 270 IA_PD. It may associate a distinct IA_PD with each of its downstream 271 network interfaces and use that IA_PD to obtain a prefix for that 272 interface from the delegating router. 273 274 The IAID uniquely identifies the IA_PD and must be chosen to be 275 unique among the IA_PD IAIDs on the requesting router. The IAID is 276 chosen by the requesting router. For any given use of an IA_PD by 277 the requesting router, the IAID for that IA_PD MUST be consistent 278 across restarts of the requesting router. The requesting router may 279 280 281 282Troan & Droms Standards Track [Page 5] 283 284RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 285 286 287 maintain consistency either by storing the IAID in non-volatile 288 storage or by using an algorithm that will consistently produce the 289 same IAID as long as the configuration of the requesting router has 290 not changed. If the requesting router uses only one IAID, it can use 291 a well-known value, e.g., zero. 292 293 The configuration information in an IA_PD consists of one or more 294 IPv6 prefixes along with the times T1 and T2 for the IA_PD. See 295 section 9 for the representation of an IA_PD in a DHCP message. 296 2977. Overview of DHCP with Prefix Delegation 298 299 Prefix delegation with DHCP is independent of address assignment with 300 DHCP. A requesting router can use DHCP for just prefix delegation or 301 for prefix delegation along with address assignment and other 302 configuration information. 303 304 A requesting router first creates an IA_PD and assigns it an IAID. 305 The requesting router then transmits a Solicit message containing an 306 IA_PD option describing the IA_PD. Delegating routers that can 307 delegate prefixes to the IA_PD respond to the requesting router with 308 an Advertise message. 309 310 The requesting router may include prefixes in the IA_PDs as a hint to 311 the delegating router about specific prefixes for which the 312 requesting router has a preference. 313 314 When the requesting router has identified a delegating router, the 315 requesting router uses a Request message to populate the IA_PDs with 316 prefixes. The requesting router includes one or more IA_PD options 317 in the Request message. The delegating router returns prefixes and 318 other information about the IA_PDs to the requesting router in IA_PD 319 options in a Reply message. The requesting router records the 320 lifetimes for the delegated prefix(es) and uses the prefix(es) as 321 described in the previous section. 322 323 Before the valid lifetime on each delegated prefix expires, the 324 requesting router includes the prefix in an IA_PD option sent in a 325 Renew message to the delegating router. The delegating router 326 responds by returning the prefix with updated lifetimes to the 327 requesting router. 328 329 330 331 332 333 334 335 336 337 338Troan & Droms Standards Track [Page 6] 339 340RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 341 342 3438. Interface Selection 344 345 Delegated prefixes are not associated with a particular interface in 346 the same way as addresses are for address assignment, and the rules 347 described in section 16, "Client Source Address and Interface 348 Selection" of RFC 3315 do not apply. 349 350 When a requesting router sends a DHCP message, it SHOULD be sent on 351 the interface associated with the upstream router (ISP network). The 352 upstream interface is typically determined by configuration. This 353 rule applies even in the case where a separate IA_PD is used for each 354 downstream interface. 355 356 When a requesting router sends a DHCP message directly to a 357 delegating router using unicast (after receiving the Server Unicast 358 option from that delegating router), the source address SHOULD be an 359 address from the upstream interface and which is suitable for use by 360 the delegating router in responding to the requesting router. 361 3629. Identity Association for Prefix Delegation Option 363 364 The IA_PD option is used to carry a prefix delegation identity 365 association, the parameters associated with the IA_PD and the 366 prefixes associated with it. 367 368 The format of the IA_PD option is: 369 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | OPTION_IA_PD | option-length | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | IAID (4 octets) | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | T1 | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | T2 | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 . . 382 . IA_PD-options . 383 . . 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 386 option-code: OPTION_IA_PD (25) 387 388 option-length: 12 + length of IA_PD-options field. 389 390 391 392 393 394Troan & Droms Standards Track [Page 7] 395 396RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 397 398 399 IAID: The unique identifier for this IA_PD; the IAID must 400 be unique among the identifiers for all of this 401 requesting router's IA_PDs. 402 403 T1: The time at which the requesting router should 404 contact the delegating router from which the 405 prefixes in the IA_PD were obtained to extend the 406 lifetimes of the prefixes delegated to the IA_PD; 407 T1 is a time duration relative to the current time 408 expressed in units of seconds. 409 410 T2: The time at which the requesting router should 411 contact any available delegating router to extend 412 the lifetimes of the prefixes assigned to the 413 IA_PD; T2 is a time duration relative to the 414 current time expressed in units of seconds. 415 416 IA_PD-options: Options associated with this IA_PD. 417 418 The IA_PD-options field encapsulates those options that are specific 419 to this IA_PD. For example, all of the IA_PD Prefix Options carrying 420 the prefixes associated with this IA_PD are in the IA_PD-options 421 field. 422 423 An IA_PD option may only appear in the options area of a DHCP 424 message. A DHCP message may contain multiple IA_PD options. 425 426 The status of any operations involving this IA_PD is indicated in a 427 Status Code option in the IA_PD-options field. 428 429 Note that an IA_PD has no explicit "lifetime" or "lease length" of 430 its own. When the valid lifetimes of all of the prefixes in a IA_PD 431 have expired, the IA_PD can be considered as having expired. T1 and 432 T2 are included to give delegating routers explicit control over when 433 a requesting router should contact the delegating router about a 434 specific IA_PD. 435 436 In a message sent by a requesting router to a delegating router, 437 values in the T1 and T2 fields indicate the requesting router's 438 preference for those parameters. The requesting router sets T1 and 439 T2 to zero if it has no preference for those values. In a message 440 sent by a delegating router to a requesting router, the requesting 441 router MUST use the values in the T1 and T2 fields for the T1 and T2 442 parameters. The values in the T1 and T2 fields are the number of 443 seconds until T1 and T2. 444 445 The delegating router selects the T1 and T2 times to allow the 446 requesting router to extend the lifetimes of any prefixes in the 447 448 449 450Troan & Droms Standards Track [Page 8] 451 452RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 453 454 455 IA_PD before the lifetimes expire, even if the delegating router is 456 unavailable for some short period of time. Recommended values for T1 457 and T2 are .5 and .8 times the shortest preferred lifetime of the 458 prefixes in the IA_PD that the delegating router is willing to 459 extend, respectively. If the time at which the prefixes in an IA_PD 460 are to be renewed is to be left to the discretion of the requesting 461 router, the delegating router sets T1 and T2 to 0. 462 463 If a delegating router receives an IA_PD with T1 greater than T2, and 464 both T1 and T2 are greater than 0, the delegating router ignores the 465 invalid values of T1 and T2 and processes the IA_PD as though the 466 delegating router had set T1 and T2 to 0. 467 468 If a requesting router receives an IA_PD with T1 greater than T2, and 469 both T1 and T2 are greater than 0, the client discards the IA_PD 470 option and processes the remainder of the message as though the 471 delegating router had not included the IA_PD option. 472 47310. IA_PD Prefix option 474 475 The IA_PD Prefix option is used to specify IPv6 address prefixes 476 associated with an IA_PD. The IA_PD Prefix option must be 477 encapsulated in the IA_PD-options field of an IA_PD option. 478 479 The format of the IA_PD Prefix option is: 480 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | OPTION_IAPREFIX | option-length | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | preferred-lifetime | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | valid-lifetime | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | prefix-length | | 491 +-+-+-+-+-+-+-+-+ IPv6 prefix | 492 | (16 octets) | 493 | | 494 | | 495 | | 496 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | | . 498 +-+-+-+-+-+-+-+-+ . 499 . IAprefix-options . 500 . . 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 503 504 505 506Troan & Droms Standards Track [Page 9] 507 508RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 509 510 511 option-code: OPTION_IAPREFIX (26) 512 513 option-length: 25 + length of IAprefix-options field 514 515 preferred-lifetime: The recommended preferred lifetime for the IPv6 516 prefix in the option, expressed in units of 517 seconds. A value of 0xFFFFFFFF represents 518 infinity. 519 520 valid-lifetime: The valid lifetime for the IPv6 prefix in the 521 option, expressed in units of seconds. A value of 522 0xFFFFFFFF represents infinity. 523 524 prefix-length: Length for this prefix in bits 525 526 IPv6-prefix: An IPv6 prefix 527 528 IAprefix-options: Options associated with this prefix 529 530 In a message sent by a requesting router to a delegating router, the 531 values in the fields can be used to indicate the requesting router's 532 preference for those values. The requesting router may send a value 533 of zero to indicate no preference. A requesting router may set the 534 IPv6 prefix field to zero and a given value in the prefix-length 535 field to indicate a preference for the size of the prefix to be 536 delegated. 537 538 In a message sent by a delegating router the preferred and valid 539 lifetimes should be set to the values of AdvPreferredLifetime and 540 AdvValidLifetime as specified in section 6.2.1, "Router Configuration 541 Variables" of RFC 2461 [4], unless administratively configured. 542 543 A requesting router discards any prefixes for which the preferred 544 lifetime is greater than the valid lifetime. A delegating router 545 ignores the lifetimes set by the requesting router if the preferred 546 lifetime is greater than the valid lifetime and ignores the values 547 for T1 and T2 set by the requesting router if those values are 548 greater than the preferred lifetime. 549 550 The values in the preferred and valid lifetimes are the number of 551 seconds remaining for each lifetime. 552 553 An IA_PD Prefix option may appear only in an IA_PD option. More than 554 one IA_PD Prefix Option can appear in a single IA_PD option. 555 556 The status of any operations involving this IA_PD Prefix option is 557 indicated in a Status Code option in the IAprefix-options field. 558 559 560 561 562Troan & Droms Standards Track [Page 10] 563 564RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 565 566 56711. Delegating Router Solicitation 568 569 The requesting router locates and selects a delegating router in the 570 same way as described in section 17, "DHCP Server Solicitation" of 571 RFC 3315. The details of the solicitation process are described in 572 this section. 573 57411.1. Requesting router behavior 575 576 The requesting router creates and transmits a Solicit message as 577 described in sections 17.1.1, "Creation of Solicit Messages" and 578 17.1.2, "Transmission of Solicit Messages" of RFC 3315. The 579 requesting router creates an IA_PD and assigns it an IAID. The 580 requesting router MUST include the IA_PD option in the Solicit 581 message. 582 583 The requesting router processes any received Advertise messages as 584 described in section 17.1.3, "Receipt of Advertise Messages" of RFC 585 3315. The requesting router MAY choose to consider the presence of 586 advertised prefixes in its decision about which delegating router to 587 respond to. 588 589 The requesting router MUST ignore any Advertise message that includes 590 a Status Code option containing the value NoPrefixAvail, with the 591 exception that the requesting router MAY display the associated 592 status message to the user. 593 59411.2. Delegating router behavior 595 596 The delegating router sends an Advertise message to the requesting 597 router in the same way as described in section 17.2.2, "Creation and 598 transmission of Advertise messages" of RFC 3315. If the message 599 contains an IA_PD option and the delegating router is configured to 600 delegate prefix(es) to the requesting router, the delegating router 601 selects the prefix(es) to be delegated to the requesting router. The 602 mechanism through which the delegating router selects prefix(es) for 603 delegation is not specified in this document. Examples of ways in 604 which the delegating router might select prefix(es) for a requesting 605 router include: static assignment based on subscription to an ISP; 606 dynamic assignment from a pool of available prefixes; selection based 607 on an external authority such as a RADIUS server using the Framed- 608 IPv6-Prefix option as described in RFC 3162 [5]. 609 610 If the requesting router includes an IA_PD Prefix option in the IA_PD 611 option in its Solicit message, the delegating router MAY choose to 612 use the information in that option to select the prefix(es) or prefix 613 size to be delegated to the requesting router. 614 615 616 617 618Troan & Droms Standards Track [Page 11] 619 620RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 621 622 623 The delegating router sends an Advertise message to the requesting 624 router in the same way as described in section, "Creation and 625 transmission of Advertise messages" of RFC 3315. The delegating 626 router MUST include an IA_PD option, identifying any prefix(es) that 627 the delegating router will delegate to the requesting router. 628 629 If the delegating router will not assign any prefixes to any IA_PDs 630 in a subsequent Request from the requesting router, the delegating 631 router MUST send an Advertise message to the requesting router that 632 includes the IA_PD with no prefixes in the IA_PD and a Status Code 633 option in the IA_PD containing status code NoPrefixAvail and a status 634 message for the user, a Server Identifier option with the delegating 635 router's DUID and a Client Identifier option with the requesting 636 router's DUID. 637 63812. Requesting router initiated prefix delegation 639 640 A requesting router uses the same message exchanges as described in 641 section 18, "DHCP Client-Initiated Configuration Exchange" of RFC 642 3315 to obtain or update prefix(es) from a delegating router. The 643 requesting router and the delegating router use the IA_PD Prefix 644 option to exchange information about prefix(es) in much the same way 645 IA Address options are used for assigned addresses. 646 64712.1. Requesting router behavior 648 649 The requesting router uses a Request message to populate IA_PDs with 650 prefixes. The requesting router includes one or more IA_PD options 651 in the Request message. The delegating router then returns the 652 prefixes for the IA_PDs to the requesting router in IA_PD options in 653 a Reply message. 654 655 The requesting router includes IA_PD options in any Renew, or Rebind 656 messages sent by the requesting router. The IA_PD option includes 657 all of the prefixes the requesting router currently has associated 658 with that IA_PD. 659 660 In some circumstances the requesting router may need verification 661 that the delegating router still has a valid binding for the 662 requesting router. Examples of times when a requesting router may 663 ask for such verification include: 664 665 o The requesting router reboots. 666 667 o The requesting router's upstream link flaps. 668 669 o The requesting router is physically disconnected from a wired 670 connection. 671 672 673 674Troan & Droms Standards Track [Page 12] 675 676RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 677 678 679 If such verification is needed the requesting router MUST initiate a 680 Rebind/Reply message exchange as described in section 18.1.4, 681 "Creation and Transmission of Rebind Messages" of RFC 3315, with the 682 exception that the retransmission parameters should be set as for the 683 Confirm message, described in section 18.1.2, "Creation and 684 Transmission of Confirm Messages" of RFC 3315. The requesting router 685 includes any IA_PDs, along with prefixes associated with those IA_PDs 686 in its Rebind message. 687 688 Each prefix has valid and preferred lifetimes whose durations are 689 specified in the IA_PD Prefix option for that prefix. The requesting 690 router uses Renew and Rebind messages to request the extension of the 691 lifetimes of a delegated prefix. 692 693 The requesting router uses a Release message to return a delegated 694 prefix to a delegating router. The prefixes to be released MUST be 695 included in the IA_PDs. 696 697 The Confirm and Decline message types are not used with Prefix 698 Delegation. 699 700 Upon the receipt of a valid Reply message, for each IA_PD the 701 requesting router assigns a subnet from each of the delegated 702 prefixes to each of the links to which the associated interfaces are 703 attached, with the following exception: the requesting router MUST 704 NOT assign any delegated prefixes or subnets from the delegated 705 prefix(es) to the link through which it received the DHCP message 706 from the delegating router. 707 708 When a requesting router subnets a delegated prefix, it must assign 709 additional bits to the prefix to generate unique, longer prefixes. 710 For example, if the requesting router in Figure 1 were delegated 711 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and 712 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber 713 network. If the requesting router were delegated 3FFE:FFFF:0::/48 714 and 3FFE:FFFF:5::/48, it might assign 3FFE:FFFF:0:1::/64 and 715 3FFE:FFFF:5:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and 716 3FFE:FFFF:5:2::/64 for assignment to the other link. 717 718 If the requesting router assigns a delegated prefix to a link to 719 which the router is attached, and begins to send router 720 advertisements for the prefix on the link, the requesting router MUST 721 set the valid lifetime in those advertisements to be no later than 722 the valid lifetime specified in the IA_PD Prefix option. A 723 requesting router MAY use the preferred lifetime specified in the 724 IA_PD Prefix option. 725 726 727 728 729 730Troan & Droms Standards Track [Page 13] 731 732RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 733 734 735 Handling of Status Codes options in received Reply messages is 736 described in section 18.1.8, "Receipt of Reply Messages" of RFC 3315. 737 The NoPrefixAvail Status Code is handled in the same manner as the 738 NoAddrsAvail Status Code. 739 74012.2. Delegating Router behavior 741 742 When a delegating router receives a Request message from a requesting 743 router that contains an IA_PD option, and the delegating router is 744 authorized to delegate prefix(es) to the requesting router, the 745 delegating router selects the prefix(es) to be delegated to the 746 requesting router. The mechanism through which the delegating router 747 selects prefix(es) for delegation is not specified in this document. 748 Section 11.2 gives examples of ways in which a delegating router 749 might select the prefix(es) to be delegated to a requesting router. 750 751 A delegating router examines the prefix(es) identified in IA_PD 752 Prefix options (in an IA_PD option) in Renew and Rebind messages and 753 responds according to the current status of the prefix(es). The 754 delegating router returns IA_PD Prefix options (within an IA_PD 755 option) with updated lifetimes for each valid prefix in the message 756 from the requesting router. If the delegating router finds that any 757 of the prefixes are not in the requesting router's binding entry, the 758 delegating router returns the prefix to the requesting router with 759 lifetimes of 0. 760 761 The delegating router behaves as follows when it cannot find a 762 binding for the requesting router's IA_PD: 763 764 Renew message: If the delegating router cannot find a binding 765 for the requesting router's IA_PD the delegating 766 router returns the IA_PD containing no prefixes 767 with a Status Code option set to NoBinding in the 768 Reply message. 769 770 Rebind message: If the delegating router cannot find a binding 771 for the requesting router's IA_PD and the 772 delegating router determines that the prefixes in 773 the IA_PD are not appropriate for the link to 774 which the requesting router's interface is 775 attached according to the delegating routers 776 explicit configuration, the delegating router MAY 777 send a Reply message to the requesting router 778 containing the IA_PD with the lifetimes of the 779 prefixes in the IA_PD set to zero. This Reply 780 constitutes an explicit notification to the 781 requesting router that the prefixes in the IA_PD 782 are no longer valid. If the delegating router is 783 784 785 786Troan & Droms Standards Track [Page 14] 787 788RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 789 790 791 unable to determine if the prefix is not 792 appropriate for the link, the Rebind message is 793 discarded. 794 795 A delegating router may mark any prefix(es) in IA_PD Prefix options 796 in a Release message from a requesting router as "available", 797 dependent on the mechanism used to acquire the prefix, e.g., in the 798 case of a dynamic pool. 799 800 The delegating router MUST include an IA_PD Prefix option or options 801 (in an IA_PD option) in Reply messages sent to a requesting router. 802 80313. Prefix Delegation reconfiguration 804 805 This section describes prefix delegation in Reconfigure message 806 exchanges. 807 80813.1. Delegating Router behavior 809 810 The delegating router initiates a configuration message exchange with 811 a requesting router, as described in section 19, "DHCP Server- 812 Initiated Configuration Exchange" of RFC 3315, by sending a 813 Reconfigure message (acting as a DHCP server) to the requesting 814 router, as described in section 19.1, "Server Behavior" of RFC 3315. 815 The delegating router specifies the IA_PD option in the Option 816 Request option to cause the requesting router to include an IA_PD 817 option to obtain new information about delegated prefix(es). 818 81913.2. Requesting Router behavior 820 821 The requesting router responds to a Reconfigure message, acting as a 822 DHCP client, received from a delegating router as described in 823 section 19.4, "Client Behavior" of RFC 3315. The requesting router 824 MUST include the IA_PD Prefix option(s) (in an IA_PD option) for 825 prefix(es) that have been delegated to the requesting router by the 826 delegating router from which the Reconfigure message was received. 827 82814. Relay agent behavior 829 830 A relay agent forwards messages containing Prefix Delegation options 831 in the same way as described in section 20, "Relay Agent Behavior" of 832 RFC 3315. 833 834 If a delegating router communicates with a requesting router through 835 a relay agent, the delegating router may need a protocol or other 836 out-of-band communication to add routing information for delegated 837 prefixes into the provider edge router. 838 839 840 841 842Troan & Droms Standards Track [Page 15] 843 844RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 845 846 84715. Security Considerations 848 849 Security considerations in DHCP are described in section 23, 850 "Security Considerations" of RFC 3315. 851 852 A rogue delegating router can issue bogus prefixes to a requesting 853 router. This may cause denial of service due to unreachability. 854 855 A malicious requesting router may be able to mount a denial of 856 service attack by repeated requests for delegated prefixes that 857 exhaust the delegating router's available prefixes. 858 859 To guard against attacks through prefix delegation, requesting 860 routers and delegating routers SHOULD use DHCP authentication as 861 described in section 21, "Authentication of DHCP messages" of RFC 862 3315. For point to point links, where one trusts that there is no 863 man in the middle, or one trusts layer two authentication, DHCP 864 authentication or IPsec may not be necessary. Because a requesting 865 router and delegating routers must each have at least one assigned 866 IPv6 address, the routers may be able to use IPsec for authentication 867 of DHCPv6 messages. The details of using IPsec for DHCPv6 are under 868 development. 869 870 Networks configured with delegated prefixes should be configured to 871 preclude intentional or inadvertent inappropriate advertisement of 872 these prefixes. 873 87416. IANA Considerations 875 876 IANA has assigned option codes to: 877 878 OPTION_IA_PD (25) 879 880 OPTION_IAPREFIX (26) 881 882 from the option-code space as defined in section 24.3, "DHCP Options" 883 of RFC 3315. 884 885 IANA has assigned status code 6 to: 886 887 NoPrefixAvail: Delegating router has no prefixes available to 888 assign to the IAPD(s) 889 890 from the status-code space as defined in section 24.4, "Status Codes" 891 of RFC 3315. 892 893 894 895 896 897 898Troan & Droms Standards Track [Page 16] 899 900RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 901 902 90317. Intellectual Property Statement 904 905 The IETF takes no position regarding the validity or scope of any 906 intellectual property or other rights that might be claimed to 907 pertain to the implementation or use of the technology described in 908 this document or the extent to which any license under such rights 909 might or might not be available; neither does it represent that it 910 has made any effort to identify any such rights. Information on the 911 IETF's procedures with respect to rights in standards-track and 912 standards-related documentation can be found in BCP-11. Copies of 913 claims of rights made available for publication and any assurances of 914 licenses to be made available, or the result of an attempt made to 915 obtain a general license or permission for the use of such 916 proprietary rights by implementors or users of this specification can 917 be obtained from the IETF Secretariat. 918 919 The IETF invites any interested party to bring to its attention any 920 copyrights, patents or patent applications, or other proprietary 921 rights which may cover technology that may be required to practice 922 this standard. Please address the information to the IETF Executive 923 Director. 924 92518. References 926 92718.1. Normative References 928 929 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 930 Specification", RFC 2460, December 1998. 931 932 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 933 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 934 RFC 3315, July 2003. 935 936 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 937 Levels", BCP 14, RFC 2119, March 1997. 938 939 [4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 940 IP Version 6 (IPv6)", RFC 2461, December 1998. 941 942 [5] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, 943 August 2001. 944 94518.2. Informative References 946 947 [6] Miyakawa, S. and R. Droms, "Requirements for IPv6 prefix 948 delegation", Work in Progress, August 2003. 949 950 951 952 953 954Troan & Droms Standards Track [Page 17] 955 956RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 957 958 95919. Acknowledgements 960 961 Thanks for the input and review by (in alphabetical order) Steve 962 Deering, Dave Forster, Brian Haberman, Tatuya Jinmei, Shin Miyakawa, 963 Pekka Savola, Bernie Volz, Trevor Warwick and Toshi Yamasaki. 964 96520. Authors' Addresses 966 967 Ole Troan 968 Cisco Systems 969 250 Longwater Avenue 970 Reading RG2 6GB 971 United Kingdom 972 973 Phone: +44 20 8824 8666 974 EMail: ot@cisco.com 975 976 977 Ralph Droms 978 Cisco Systems 979 1414 Massachusetts Avenue 980 Boxborough, MA 01719 981 USA 982 983 Phone: +1 978 936 1674 984 EMail: rdroms@cisco.com 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010Troan & Droms Standards Track [Page 18] 1011 1012RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 1013 1014 101521. Full Copyright Statement 1016 1017 Copyright (C) The Internet Society (2003). All Rights Reserved. 1018 1019 This document and translations of it may be copied and furnished to 1020 others, and derivative works that comment on or otherwise explain it 1021 or assist in its implementation may be prepared, copied, published 1022 and distributed, in whole or in part, without restriction of any 1023 kind, provided that the above copyright notice and this paragraph are 1024 included on all such copies and derivative works. However, this 1025 document itself may not be modified in any way, such as by removing 1026 the copyright notice or references to the Internet Society or other 1027 Internet organizations, except as needed for the purpose of 1028 developing Internet standards in which case the procedures for 1029 copyrights defined in the Internet Standards process must be 1030 followed, or as required to translate it into languages other than 1031 English. 1032 1033 The limited permissions granted above are perpetual and will not be 1034 revoked by the Internet Society or its successors or assignees. 1035 1036 This document and the information contained herein is provided on an 1037 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1038 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1039 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1040 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1041 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1042 1043Acknowledgement 1044 1045 Funding for the RFC Editor function is currently provided by the 1046 Internet Society. 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066Troan & Droms Standards Track [Page 19] 1067 1068