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