1 2 3DHC Working Group O. Troan 4Internet-Draft R. Droms 5Expires: August 11, 2003 Cisco Systems 6 February 10, 2003 7 8 9 IPv6 Prefix Options for DHCPv6 10 draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.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 August 11, 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 August 11, 2003 [Page 1] 56 57Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 58 59 60Table of Contents 61 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Model and Applicability . . . . . . . . . . . . . . . . . . 4 66 5. Identity Association for Prefix Delegation . . . . . . . . . 6 67 6. Overview of DHCP with Prefix Delegation . . . . . . . . . . 7 68 7. Interface Selection . . . . . . . . . . . . . . . . . . . . 7 69 8. Identity Association for Prefix Delegation Option . . . . . 8 70 9. IA_PD Prefix option . . . . . . . . . . . . . . . . . . . . 9 71 10. Delegating Router Solicitation . . . . . . . . . . . . . . . 11 72 10.1 Requesting router behaviour . . . . . . . . . . . . . . . . 11 73 10.2 Delegating router behaviour . . . . . . . . . . . . . . . . 11 74 11. Requesting router initiated prefix delegation . . . . . . . 12 75 11.1 Requesting router behaviour . . . . . . . . . . . . . . . . 13 76 11.2 Delegating Router behaviour . . . . . . . . . . . . . . . . 14 77 12. Prefix Delegation reconfiguration . . . . . . . . . . . . . 15 78 12.1 Delegating Router behaviour . . . . . . . . . . . . . . . . 15 79 12.2 Requesting Router behaviour . . . . . . . . . . . . . . . . 15 80 13. Relay agent behaviour . . . . . . . . . . . . . . . . . . . 15 81 14. Security Considerations . . . . . . . . . . . . . . . . . . 15 82 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 83 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 84 17. Changes since revision-01 . . . . . . . . . . . . . . . . . 16 85 Normative References . . . . . . . . . . . . . . . . . . . . 16 86 Informative References . . . . . . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 88 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Troan & Droms Expires August 11, 2003 [Page 2] 112 113Internet-Draft IPv6 Prefix Options for DHCPv6 February 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 1402. Terminology 141 142 This document uses the terminology defined in RFC2460 [2] and the 143 DHCP specification [6]. In addition, this document uses the 144 following terms: 145 146 requesting router The router that acts as a DHCP client and is 147 requesting prefix(es) to be assigned. 148 149 delegating router The router that acts as a DHCP server, and is 150 responding to the prefix request. 151 152 Identity Association for Prefix Delegation (IA_PD) A collection of 153 prefixes assigned to the requesting router. Each 154 IA_PD has an associated IAID. A requesting 155 router may have more than one IA_PD assigned to 156 it; for example, one for each of its interfaces. 157 158 1593. Requirements 160 161 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 162 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 163 document, are to be interpreted as described in RFC 2119 [1]. 164 165 166 167Troan & Droms Expires August 11, 2003 [Page 3] 168 169Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 170 171 1724. Model and Applicability 173 174 The model of operation for prefix delegation is as follows. A 175 delegating router is provided DHCPv6 prefixes to be delegated to 176 requesting routers. Examples of ways in which the delegating router 177 may be provided these prefixes are given in Section 11.2. A 178 requesting router requests prefix(es) from the delegating router, as 179 described in Section 11.1. The delegating router chooses prefix(es) 180 for delegation, and returns the prefix(es) to the requesting router. 181 The requesting router is then responsible for the delegated 182 prefix(es). For example, the requesting router might assign a subnet 183 from a delegated prefix to one of its interfaces, and begin sending 184 router advertisements for the prefix on that link. 185 186 Each prefix has an associated valid and preferred lifetime, which 187 constitutes an agreement about the length of time over which the 188 requesting router is allowed to use the prefix. A requesting router 189 can request an extension of the lifetimes on a delegated prefix and 190 is required to terminate the use of a delegated prefix if the valid 191 lifetime of the prefix expires. 192 193 This prefix delegation mechanism would be appropriate for use by an 194 ISP to delegate a prefix to a subscriber, where the delegated prefix 195 would possibly be subnetted and assigned to the links within the 196 subscriber's network. 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223Troan & Droms Expires August 11, 2003 [Page 4] 224 225Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 226 227 228 Figure 1 illustrates a network architecture in which prefix 229 delegation would 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 August 11, 2003 [Page 5] 280 281Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 282 283 284 The requesting router assigns longer prefixes from the delegated 285 prefix for assignment to links in the subscriber's network. In a 286 typical scenario based on the network shown in Figure 1, the 287 requesting router subnets a single delegated /48 prefix into /64 288 prefixes and assigns one /64 prefix to each of the links in the 289 subscriber 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 3005. 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 IDs 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 8 for the representation of an IA_PD in a DHCP 330 message. 331 332 333 334 335Troan & Droms Expires August 11, 2003 [Page 6] 336 337Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 338 339 3406. 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 3727. 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 August 11, 2003 [Page 7] 392 393Internet-Draft IPv6 Prefix Options for DHCPv6 February 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 3998. 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 contacts 433 the delegating router from which the prefixes in 434 the IA_PD were obtained to extend the lifetimes of 435 the prefixes delegated to the IA_PD; T1 is a time 436 duration relative to the current time expressed in 437 units of seconds. 438 439 T2 The time at which the requesting router contacts 440 any available delegating router to extend the 441 lifetimes of the prefixes assigned to the IA_PD; T2 442 is a time duration relative to the current time 443 expressed in units of seconds. 444 445 446 447Troan & Droms Expires August 11, 2003 [Page 8] 448 449Internet-Draft IPv6 Prefix Options for DHCPv6 February 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 recontacts the delegating router about a specific 470 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 0 if it has no preference for those values. In a message sent 476 by a delegating router to a requesting router, the requesting router 477 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, respectively. If the time at which the 487 prefixes in an IA_PD are to be renewed is to be left to the 488 discretion of the requesting router, the delegating router sets T1 489 and T2 to 0. 490 4919. IA_PD Prefix option 492 493 The IA_PD Prefix option is used to specify IPv6 address prefixes 494 associated with an IA_PD. The IA_PD Prefix option must be 495 encapsulated in the IA_PD-options field of an IA_PD option. 496 497 498 499 500 501 502 503Troan & Droms Expires August 11, 2003 [Page 9] 504 505Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 506 507 508 The format of the IA_PD Prefix option is: 509 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | OPTION_IAPREFIX | option-length | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | preferred-lifetime | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | valid-lifetime | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | prefix-length | | 520 +-+-+-+-+-+-+-+-+ IPv6 prefix | 521 | (16 octets) | 522 | | 523 | | 524 | | 525 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | | . 527 +-+-+-+-+-+-+-+-+ . 528 . IAprefix-options . 529 . . 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 532 533 option-code: OPTION_IAPREFIX (TBD) 534 535 option-length: 25 + length of IAprefix-options field 536 537 preferred-lifetime: The recommended preferred lifetime for the IPv6 538 prefix in the option, expressed in units of 539 seconds. A value of 0xFFFFFFFF represents 540 infinity. 541 542 valid-lifetime: The valid lifetime for the IPv6 prefix in the 543 option, expressed in units of seconds. A value of 544 0xFFFFFFFF represents infinity. 545 546 prefix-length: Length for this prefix in bits 547 548 IPv6-prefix: An IPv6 prefix 549 550 IAprefix-options: Options associated with this prefix 551 552 In a message sent by a requesting router to a delegating router, the 553 values in the fields can be used to indicate the requesting router's 554 preference for those values. The requesting router may send a value 555 of zero to indicate no preference. A requesting router may set the 556 557 558 559Troan & Droms Expires August 11, 2003 [Page 10] 560 561Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 562 563 564 IPv6 prefix field to zero and a given value in the prefix-length 565 field to indicate a preference for the size of the prefix to be 566 delegated. 567 568 In a message sent by a delegating router the preferred and valid 569 lifetimes should be set to the values of AdvPreferredLifetime and 570 AdvValidLifetime as specified in section "Router Configuration 571 Variables" of RFC2461 [3], unless administratively configured. 572 573 The values in the preferred and valid lifetimes are the number of 574 seconds remaining for each lifetime. 575 576 An IA_PD Prefix option may appear only in an IA_PD option. More than 577 one IA_PD Prefix Option can appear in a single IA_PD option. 578 579 The status of any operations involving this IA_PD Prefix option is 580 indicated in a Status Code option in the IAprefix-options field. 581 58210. Delegating Router Solicitation 583 584 The requesting router locates and selects a delegating router in the 585 same way as described in section "DHCP Server Solicitation" of the 586 DHCP specification [6]. The details of the solicitation process are 587 described in this section. 588 58910.1 Requesting router behaviour 590 591 The requesting router creates and transmits a Solicit message as 592 described in sections "Creation of Solicit Messages" and 593 "Transmission of Solicit Messages" of the DHCP specification [6]. 594 The requesting router creates an IA_PD and assigns it an IAID. The 595 requesting router MUST include the IA_PD option in the Solicit 596 message. 597 598 The requesting router processes any received Advertise messages as 599 described in section "Receipt of Advertise Messages" in the DHCP 600 specification [6]. The requesting router MAY choose to consider the 601 presence of advertised prefixes in its decision about which 602 delegating router to respond to. 603 604 The requesting router MUST ignore any Advertise message that includes 605 a Status Code option containing the value NoPrefixAvail, with the 606 exception that the requesting router MAY display the associated 607 status message to the user. 608 60910.2 Delegating router behaviour 610 611 The delegating router processes Solicit messages from requesting 612 613 614 615Troan & Droms Expires August 11, 2003 [Page 11] 616 617Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 618 619 620 routers in the same way as described in section "Receipt of Solicit 621 messages" of the DHCP specification [6]. If the message contains an 622 IA_PD option and the delegating router is configured to delegate 623 prefix(es) to the requesting router, the delegating router selects 624 the prefix(es) to be delegated to the requesting router. The 625 mechanism through which the delegating router selects prefix(es) for 626 delegation is not specified in this document. Examples of ways in 627 which the delegating router might select prefix(es) for a requesting 628 router include: static assignment based on subscription to an ISP; 629 dynamic assignment from a pool of available prefixes; selection based 630 on an external authority such as a RADIUS server using the Framed- 631 IPv6-Prefix option as described in RFC 3162 [7]. 632 633 If the delegating router cannot delegate any prefixes to an IA_PD in 634 the message from the requesting router, the delegating router MUST 635 include the IA_PD in the Reply message with no prefixes in the IA_PD 636 and a Status Code option in the IA_PD containing status code 637 NoPrefixAvail. 638 639 If the requesting router includes an IA_PD Prefix option in the IA_PD 640 option in its Solicit message, the delegating router MAY choose to 641 use the information in that option to select the prefix(es) or prefix 642 size to be delegated to the requesting router. 643 644 The delegating router sends an Advertise message to the requesting 645 router in the same way as described in section "Creation and 646 transmission of Advertise messages" in the DHCP specification [6]. 647 The delegating router MUST include an IA_PD option, identifying any 648 prefix(es) that the delegating router will delegate to the requesting 649 router. 650 651 If the delegating router will not assign any prefixes to any IA_PDs 652 in a subsequent Request from the requesting router, the delegating 653 router MUST send an Advertise message to the requesting router that 654 includes a Status Code option with code NoPrefixAvail and a status 655 message for the user, a Server Identifier option with the delegating 656 router's DUID and a Client Identifier option with the requesting 657 router's DUID. 658 65911. Requesting router initiated prefix delegation 660 661 A requesting router uses the same message exchanges as described in 662 section "DHCP Client-Initiated Configuration Exchange" of the DHCP 663 specification [6] to obtain or update prefix(es) from a delegating 664 router. The requesting router and the delegating router use the 665 IA_PD Prefix option to exchange information about prefix(es) in much 666 the same way IA Address options are used for assigned addresses. 667 668 669 670 671Troan & Droms Expires August 11, 2003 [Page 12] 672 673Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 674 675 67611.1 Requesting router behaviour 677 678 The requesting router uses a Request message to populate IA_PDs with 679 prefixes. The requesting router includes one or more IA_PD options 680 in the Request message. The delegating router then returns the 681 prefixes for the IA_PDs to the requesting router in IA_PD options in 682 a Reply message. 683 684 The requesting router includes IA_PD options in any Renew, or Rebind 685 messages sent by the requesting router. The IA_PD option include all 686 of the prefixes the requesting router currently has associated with 687 that IA_PD. 688 689 In some circumstances the requesting router may need verification 690 that the delegating router still has a valid binding for the 691 requesting router. Examples of times when a requesting router may 692 ask for such verification include: 693 694 o The requesting router reboots. 695 696 o The requesting router's upstream link flaps. 697 698 o The requesting router is physically disconnected from a wired 699 connection. 700 701 If such verification is needed the requesting router MUST initiate a 702 Rebind/Reply message exchange as described in the section "Creation 703 and Transmission of Rebind Messages" of the DHCP specification [6], 704 with the exception that the retransmission parameters should be set 705 as for the Confirm message, described in the section "Creation and 706 Transmission of Confirm Messages" of the DHCP specification [6]. The 707 requesting router includes any IA_PDs, along with prefixes associated 708 with those IA_PDs in its Rebind message. 709 710 Each prefix has valid and preferred lifetimes whose duration is 711 specified in the IA_PD Prefix option for that prefix. The requesting 712 router uses Renew and Rebind messages to request the extension of the 713 lifetimes of a delegated prefix. 714 715 The requesting router uses a Release message to return a delegated 716 prefix to a delegating router. The prefixes to be released MUST be 717 included in the IA_PDs. 718 719 The Confirm and Decline message types are not used with Prefix 720 Delegation. 721 722 Upon the receipt of a valid Reply message, for each IA_PD the 723 requesting router assigns a subnet from each of the delegated 724 725 726 727Troan & Droms Expires August 11, 2003 [Page 13] 728 729Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 730 731 732 prefixes to each of the links to which the associated interfaces are 733 attached, with the following exception: the requesting router MUST 734 NOT assign any delegated prefixes or subnets from the delegated 735 prefix(es) to the link through which it received the DHCP message 736 from the delegating router. 737 738 When a requesting router subnets a delegated prefix, it must assign 739 additional bits to the prefix to generate unique, longer prefixes. 740 For example, if the requesting router in Figure 1 were delegated 741 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and 742 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber 743 network. If the requesting router were delegated 3FFE:FFFF:0::/48 744 and 3FFE:FFFF:1::/48, it might assign 3FFE:FFFF:0:1::/64 and 745 3FFE:FFFF:1:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and 746 3FFE:FFFF:1:2::/64 for assignment to the other link. 747 748 If the requesting router assigns a delegated prefix to a link to 749 which the router is attached, and begins to send router 750 advertisements for the prefix on the link, the requesting router MUST 751 set the valid lifetime in those advertisements to be no later than 752 the valid lifetime specified in the IA_PD Prefix option. A 753 requesting router MAY use the preferred lifetime specified in the 754 IA_PD Prefix option. 755 75611.2 Delegating Router behaviour 757 758 When a delegating router receives a Request message from a requesting 759 router that contains an IA_PD option, and the delegating router is 760 authorised to delegate prefix(es) to the requesting router, the 761 delegating router selects the prefix(es) to be delegated to the 762 requesting router. The mechanism through which the delegating router 763 selects prefix(es) for delegation is not specified in this document. 764 Section 10.2 gives examples of ways in which a delegating router 765 might select the prefix(es) to be delegated to a requesting router. 766 767 A delegating router examines the prefix(es) identified in IA_PD 768 Prefix options (in an IA_PD option) in Renew and Rebind messages and 769 responds according to the current status of the prefix(es). The 770 delegating router returns IA_PD Prefix options (within an IA_PD 771 option) with updated lifetimes for each valid prefix in the message 772 from the requesting router. If the delegating router cannot find a 773 binding for the requesting router's IA_PD the delegating router 774 returns the IA_PD containing no prefixes with a Status Code option 775 set to NoBinding in the Reply message. If the delegating router 776 finds that any of the prefixes are not in the requesting router's 777 binding entry, the delegating router returns the prefix to the 778 requesting router with lifetimes of 0. 779 780 781 782 783Troan & Droms Expires August 11, 2003 [Page 14] 784 785Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 786 787 788 A delegating router may mark any prefix(es) in IA_PD Prefix options 789 in a Release message from a requesting router as "available", 790 dependent on the mechanism used to acquire the prefix, e.g in the 791 case of a dynamic pool. 792 793 The delegating router MUST include an IA_PD Prefix option or options 794 (in an IA_PD option) in Reply messages sent to a requesting router. 795 79612. Prefix Delegation reconfiguration 797 798 This section describes prefix delegation in Reconfigure message 799 exchanges. 800 80112.1 Delegating Router behaviour 802 803 The delegating router initiates a configuration message exchange with 804 a requesting router, as described in the section "DHCP Server- 805 Initiated Configuration Exchange" of the DHCP specification [6]. The 806 delegating router specifies the IA_PD option in the Option Request 807 option to cause the requesting router to include an IA_PD option to 808 obtain new information about delegated prefix(es). 809 81012.2 Requesting Router behaviour 811 812 The requesting router responds to a Reconfigure message received from 813 a delegating router as described in the DHCP specification [6]. The 814 requesting router MUST include the IA_PD Prefix option(s) (in an 815 IA_PD option) for prefix(es) that have been delegated to the 816 requesting router by the delegating router from which the Reconfigure 817 message was received. 818 81913. Relay agent behaviour 820 821 A relay agent forwards messages containing Prefix Delegation options 822 in the same way as described in section "Relay Behaviour" of the DHCP 823 specification [6]. 824 825 If a delegating router communicates with a requesting router through 826 a relay agent, the delegating router may need a protocol or other 827 out-of-band communication to add routing information for delegated 828 prefixes into the provider edge router. 829 83014. Security Considerations 831 832 Security considerations in DHCP are described in the section 833 "Security Considerations" of the DHCP specification [6]. 834 835 A rogue delegating router can issue bogus prefixes to a requesting 836 837 838 839Troan & Droms Expires August 11, 2003 [Page 15] 840 841Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 842 843 844 router. This may cause denial of service due to unreachability. 845 846 An intruder requesting router may be able to mount a denial of 847 service attack by repeated requests for delegated prefixes that 848 exhaust the delegating router's available prefixes. 849 850 To guard against attacks through prefix delegation, requesting 851 routers and delegating routers SHOULD use DHCP authentication as 852 described in section "Authentication of DHCP messages" in the DHCP 853 specification [6]. For point to point links, where one trusts that 854 there is no man in the middle, or one trusts layer two 855 authentication, DHCP authentication or IPsec may not be necessary. 856 Because a requesting router and delegating routers must each have at 857 least one assigned IPv6 address, the routers may be able to use IPsec 858 for authentication of DHCPv6 messages. The details of using IPsec 859 for DHCPv6 are under development. 860 86115. IANA Considerations 862 863 IANA is requested to assign option codes to these options from the 864 option-code space as defined in section "DHCPv6 Options" of the 865 DHCPv6 specification [6]. 866 867 IANA is requested to assign a status code to the NoPrefixAvail status 868 code from the status-code space as defined in section "Status Codes" 869 of the DHCPv6 specification [6]. 870 87116. Acknowledgements 872 873 Thanks for the input and review by (in alphabetical order) Steve 874 Deering, Dave Forster, Brian Haberman, Tatuya Jinmei, Shin Miyakawa, 875 Pekka Savola, Bernie Volz, Trevor Warwick and Toshi Yamasaki. 876 87717. Changes since revision-01 878 879 o Clarified the usage of how Preferred/Valid lifetimes should be 880 used in Router Advertisements. 881 882 o Clarified the use of NoPrefixAvail in the case were the delegating 883 router cannot delegate any prefixes. 884 885 o Use Rebind/Reply message exchange for binding confirmation rather 886 than Renew/Reply. 887 888Normative References 889 890 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 891 Levels", BCP 14, RFC 2119, March 1997. 892 893 894 895Troan & Droms Expires August 11, 2003 [Page 16] 896 897Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 898 899 900 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 901 Specification", RFC 2460, December 1998. 902 903 [3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 904 IP Version 6 (IPv6)", RFC 2461, December 1998. 905 906 [4] Hinden, R. and S. Deering, "IP Version 6 Addressing 907 Architecture", RFC 2373, July 1998. 908 909 [5] Thomson, S. and T. Narten, "IPv6 Stateless Address 910 Autoconfiguration", RFC 2462, December 1998. 911 912 [6] Droms, R., "Dynamic Host Configuration Protocol for IPv6 913 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), November 914 2002. 915 916 [7] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, 917 August 2001. 918 919Informative References 920 921 [8] Miyakawa, S., "Requirements for IPv6 prefix delegation", draft- 922 ietf-ipv6-prefix-delegation-requirement-00 (work in progress), 923 November 2002. 924 925 926Authors' Addresses 927 928 Ole Troan 929 Cisco Systems 930 250 Longwater Avenue 931 Reading RG2 6GB 932 United Kingdom 933 934 Phone: +44 20 8824 8666 935 EMail: ot@cisco.com 936 937 938 Ralph Droms 939 Cisco Systems 940 300 Apollo Drive 941 Chelmsford, MA 01824 942 USA 943 944 Phone: +1 978 497 4733 945 EMail: rdroms@cisco.com 946 947 948 949 950 951Troan & Droms Expires August 11, 2003 [Page 17] 952 953Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 954 955 956Full Copyright Statement 957 958 Copyright (C) The Internet Society (2003). All Rights Reserved. 959 960 This document and translations of it may be copied and furnished to 961 others, and derivative works that comment on or otherwise explain it 962 or assist in its implementation may be prepared, copied, published 963 and distributed, in whole or in part, without restriction of any 964 kind, provided that the above copyright notice and this paragraph are 965 included on all such copies and derivative works. However, this 966 document itself may not be modified in any way, such as by removing 967 the copyright notice or references to the Internet Society or other 968 Internet organizations, except as needed for the purpose of 969 developing Internet standards in which case the procedures for 970 copyrights defined in the Internet Standards process must be 971 followed, or as required to translate it into languages other than 972 English. 973 974 The limited permissions granted above are perpetual and will not be 975 revoked by the Internet Society or its successors or assigns. 976 977 This document and the information contained herein is provided on an 978 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 979 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 980 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 981 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 982 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 983 984Acknowledgement 985 986 Funding for the RFC Editor function is currently provided by the 987 Internet Society. 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007Troan & Droms Expires August 11, 2003 [Page 18] 1008 1009