idnits 2.17.1 draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 7, 2003) is 7500 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (ref. '1') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (ref. '2') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 2461 (ref. '4') (Obsoleted by RFC 4861) == Outdated reference: A later version (-04) exists of draft-ietf-ipv6-prefix-delegation-requirement-03 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group O. Troan 3 Internet-Draft R. Droms 4 Expires: April 6, 2004 Cisco Systems 5 October 7, 2003 7 IPv6 Prefix Options for DHCPv6 8 draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on April 6, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 The Prefix Delegation options provide a mechanism for automated 39 delegation of IPv6 prefixes using DHCP. This mechanism is intended 40 for delegating a long-lived prefix from a delegating router to a 41 requesting router, across an administrative boundary, where the 42 delegating router does not require knowledge about the topology of 43 the links in the network to which the prefixes will be assigned. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. DHCPv6 specification dependency . . . . . . . . . . . . . . 3 49 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 50 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 51 5. Model and Applicability . . . . . . . . . . . . . . . . . . 4 52 5.1 Example network architecture . . . . . . . . . . . . . . . . 5 53 6. Identity Association for Prefix Delegation . . . . . . . . . 6 54 7. Overview of DHCP with Prefix Delegation . . . . . . . . . . 7 55 8. Interface Selection . . . . . . . . . . . . . . . . . . . . 7 56 9. Identity Association for Prefix Delegation Option . . . . . 8 57 10. IA_PD Prefix option . . . . . . . . . . . . . . . . . . . . 10 58 11. Delegating Router Solicitation . . . . . . . . . . . . . . . 11 59 11.1 Requesting router behaviour . . . . . . . . . . . . . . . . 11 60 11.2 Delegating router behaviour . . . . . . . . . . . . . . . . 12 61 12. Requesting router initiated prefix delegation . . . . . . . 12 62 12.1 Requesting router behaviour . . . . . . . . . . . . . . . . 13 63 12.2 Delegating Router behaviour . . . . . . . . . . . . . . . . 14 64 13. Prefix Delegation reconfiguration . . . . . . . . . . . . . 15 65 13.1 Delegating Router behaviour . . . . . . . . . . . . . . . . 15 66 13.2 Requesting Router behaviour . . . . . . . . . . . . . . . . 16 67 14. Relay agent behaviour . . . . . . . . . . . . . . . . . . . 16 68 15. Security Considerations . . . . . . . . . . . . . . . . . . 16 69 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 70 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 71 Normative References . . . . . . . . . . . . . . . . . . . . 17 72 Informative References . . . . . . . . . . . . . . . . . . . 18 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 74 Intellectual Property and Copyright Statements . . . . . . . 19 76 1. Introduction 78 This document describes new options for DHCP that provide a mechanism 79 for the delegation of IPv6 prefixes [1]. Through these options, a 80 delegating router can delegate prefixes to authorised requesting 81 routers. 83 The prefix delegation mechanism described in this document is 84 intended for simple delegation of prefixes from a delegating router 85 to requesting routers. It is appropriate for situations in which the 86 delegating router does not have knowledge about the topology of the 87 networks to which the requesting router is attached, and the 88 delegating router does not require other information aside from the 89 identity of the requesting router to choose a prefix for delegation. 90 For example, these options would be used by a service provider to 91 assign a prefix to a CPE device acting as a router between the 92 subscriber's internal network and the service provider's core 93 network. 95 Many applications expect stable addresses. Even though this mechanism 96 makes automatic renumbering easier, it is expected that prefixes have 97 a long lifespan. During renumbering it is expected that the old and 98 the new prefix co-exist for some time. 100 The design of this prefix delegation mechanism meets the requirements 101 for prefix delegation in Requirements for IPv6 prefix delegation [6]. 103 Note that this use of DHCP is not bound to the assignment of IP 104 addresses or other configuration information to hosts, and that no 105 mechanism is currently available to communicate delegated prefixes to 106 a DHCP server that serves such a function. This may be an item of 107 future work, should usage warrant. 109 2. DHCPv6 specification dependency 111 This document describes new DHCPv6 options for IPv6 prefix 112 delegation. This document should be read in conjunction with the 113 DHCPv6 specification, RFC 3315 [2], for a complete specification of 114 the Prefix Delegation options and mechanism. Definitions for terms 115 and acronyms not specifically defined in this document are defined in 116 RFC 3315. 118 3. Terminology 120 This document uses the terminology defined in RFC2460 [1] and 121 RFC3315. In addition, this document uses the following terms: 123 requesting router: The router that acts as a DHCP client and is 124 requesting prefix(es) to be assigned. 126 delegating router: The router that acts as a DHCP server, and is 127 responding to the prefix request. 129 Identity Association for Prefix Delegation (IA_PD): A collection of 130 prefixes assigned to the requesting router. Each 131 IA_PD has an associated IAID. A requesting router 132 may have more than one IA_PD assigned to it; for 133 example, one for each of its interfaces. 135 4. Requirements 137 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 138 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 139 document, are to be interpreted as described in RFC 2119 [3]. 141 5. Model and Applicability 143 The model of operation for prefix delegation is as follows. A 144 delegating router is provided IPv6 prefixes to be delegated to 145 requesting routers. Examples of ways in which the delegating router 146 may be provided these prefixes are given in Section 12.2. A 147 requesting router requests prefix(es) from the delegating router, as 148 described in Section 12.1. The delegating router chooses prefix(es) 149 for delegation, and responds with prefix(es) to the requesting 150 router. The requesting router is then responsible for the delegated 151 prefix(es). For example, the requesting router might assign a subnet 152 from a delegated prefix to one of its interfaces, and begin sending 153 router advertisements for the prefix on that link. 155 Each prefix has an associated valid and preferred lifetime, which 156 constitutes an agreement about the length of time over which the 157 requesting router is allowed to use the prefix. A requesting router 158 can request an extension of the lifetimes on a delegated prefix and 159 is required to terminate the use of a delegated prefix if the valid 160 lifetime of the prefix expires. 162 This prefix delegation mechanism would be appropriate for use by an 163 ISP to delegate a prefix to a subscriber, where the delegated prefix 164 would possibly be subnetted and assigned to the links within the 165 subscriber's network. 167 5.1 Example network architecture 169 Figure 1 illustrates a network architecture in which prefix 170 delegation could be used. 172 ______________________ \ 173 / \ \ 174 | ISP core network | \ 175 \__________ ___________/ | 176 | | 177 +-------+-------+ | 178 | Aggregation | | ISP 179 | device | | network 180 | (delegating | | 181 | router) | | 182 +-------+-------+ | 183 | / 184 |DSL to subscriber / 185 |premises / 186 | 187 +------+------+ \ 188 | CPE | \ 189 | (requesting | \ 190 | router) | | 191 +----+---+----+ | 192 | | | Subscriber 193 ---+-------------+-----+- -+-----+-------------+--- | network 194 | | | | | 195 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 196 |Subscriber| |Subscriber| |Subscriber| |Subscriber| / 197 | PC | | PC | | PC | | PC | / 198 +----------+ +----------+ +----------+ +----------+ / 200 Figure 1: An example of prefix delegation. 202 Figure 1 204 In this example the delegating router is configured with a set of 205 prefixes to be used for assignment to customers at the time of each 206 customer's first connection to the ISP service. The prefix delegation 207 process begins when the requesting router requests configuration 208 information through DHCP. The DHCP messages from the requesting 209 router are received by the delegating router in the aggregation 210 device. When the delegating router receives the request, it selects 211 an available prefi or prefixes for delegation to the requesting 212 router. The delegating router then returns the prefix or prefixes to 213 the requesting router. 215 The requesting router subnets the delegated prefix and assigns the 216 longer prefixes to links in the subscriber's network. In a typical 217 scenario based on the network shown in Figure 1, the requesting 218 router subnets a single delegated /48 prefix into /64 prefixes and 219 assigns one /64 prefix to each of the links in the subscriber 220 network. 222 The prefix delegation options can be used in conjunction with other 223 DHCP options carrying other configuration information to the 224 requesting router. The requesting router may, in turn, then provide 225 DHCP service to hosts attached to the internal network. For example, 226 the requesting router may obtain the addresses of DNS and NTP servers 227 from the ISP delegating router, and then pass that configuration 228 information on to the subscriber hosts through a DHCP server in the 229 requesting router. 231 6. Identity Association for Prefix Delegation 233 An IA_PD is a construct through which a delegating router and a 234 requesting router can identify, group and manage a set of related 235 IPv6 prefixes. Each IA_PD consists of an IAID and associated 236 configuration information. An IA_PD for prefixes is the equivalent of 237 an IA (described in RFC 3315) for addresses. 239 An IA_PD is different from an IA, in that it does not need to be 240 associated with exactly one interface. One IA_PD can be associated 241 with the requesting router, with a set of interfaces or with exactly 242 one interface. A requesting router must create at least one distinct 243 IA_PD. It may associate a distinct IA_PD with each of its downstream 244 network interfaces and use that IA_PD to obtain a prefix for that 245 interface from the delegating router. 247 The IAID uniquely identifies the IA_PD and must be chosen to be 248 unique among the IA_PD IAIDs on the requesting router. The IAID is 249 chosen by the requesting router. For any given use of an IA_PD by the 250 requesting router, the IAID for that IA_PD MUST be consistent across 251 restarts of the requesting router. The requesting router may maintain 252 consistency either by storing the IAID in non-volatile storage or by 253 using an algorithm that will consistently produce the same IAID as 254 long as the configuration of the requesting router has not changed. 255 If the requesting router uses only one IAID, it can use a well-known 256 value, e.g zero. 258 The configuration information in an IA_PD consists of one or more 259 IPv6 prefixes along with the times T1 and T2 for the IA_PD. See 260 section Section 9 for the representation of an IA_PD in a DHCP 261 message. 263 7. Overview of DHCP with Prefix Delegation 265 Prefix delegation with DHCP is independent of address assignment with 266 DHCP. A requesting router can use DHCP for just prefix delegation or 267 for prefix delegation along with address assignment and other 268 configuration information. 270 A requesting router first creates an IA_PD and assigns it an IAID. 271 The requesting router then transmits a Solicit message containing an 272 IA_PD option describing the IA_PD. Delegating routers that can 273 delegate prefixes to the IA_PD respond to the requesting router with 274 an Advertise message. 276 The requesting router may include prefixes in the IA_PDs as a hint to 277 the delegating router about specific prefixes for which the 278 requesting router has a preference. 280 When the requesting router has identified a delegating router, the 281 requesting router uses a Request message to populate the IA_PDs with 282 prefixes. The requesting router includes one or more IA_PD options in 283 the Request message. The delegating router returns prefixes and other 284 information about the IA_PDs to the requesting router in IA_PD 285 options in a Reply message. The requesting router records the 286 lifetimes for the delegated prefix(es) and uses the prefix(es) as 287 described in the previous section. 289 Before the valid lifetime on each delegated prefix expires, the 290 requesting router includes the prefix in an IA_PD option sent in a 291 Renew message to the delegating router. The delegating router 292 responds by returning the prefix with updated lifetimes to the 293 requesting router. 295 8. Interface Selection 297 Delegated prefixes are not associated with a particular interface in 298 the same way as addresses are for address assignment, and the rules 299 described in the section "Client Source Address and Interface 300 Selection" of RFC 3315 do not apply. 302 When a requesting router sends a DHCP message, it SHOULD be sent on 303 the interface associated with the upstream router (ISP network). The 304 upstream interface is typically determined by configuration. This 305 rule applies even in the case where a separate IA_PD is used for each 306 downstream interface. 308 When a requesting router sends a DHCP message directly to a 309 delegating router using unicast (after receiving the Server Unicast 310 option from that delegating router), the source address SHOULD be an 311 address from the upstream interface and which is suitable for use by 312 the delegating router in responding to the requesting router. 314 9. Identity Association for Prefix Delegation Option 316 The IA_PD option is used to carry a prefix delegation identity 317 association, the parameters associated with the IA_PD and the 318 prefixes associated with it. 320 The format of the IA_PD option is: 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | OPTION_IA_PD | option-length | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | IAID (4 octets) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | T1 | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | T2 | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 . . 334 . IA_PD-options . 335 . . 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 option-code: OPTION_IA_PD (TBD) 340 option-length: 12 + length of IA_PD-options field. 342 IAID: The unique identifier for this IA_PD; the IAID must 343 be unique among the identifiers for all of this 344 requesting router's IA_PDs. 346 T1: The time at which the requesting router should 347 contact the delegating router from which the 348 prefixes in the IA_PD were obtained to extend the 349 lifetimes of the prefixes delegated to the IA_PD; 350 T1 is a time duration relative to the current time 351 expressed in units of seconds. 353 T2: The time at which the requesting router should 354 contact any available delegating router to extend 355 the lifetimes of the prefixes assigned to the 356 IA_PD; T2 is a time duration relative to the 357 current time expressed in units of seconds. 359 IA_PD-options: Options associated with this IA_PD. 361 The IA_PD-options field encapsulates those options that are specific 362 to this IA_PD. For example, all of the IA_PD Prefix Options carrying 363 the prefixes associated with this IA_PD are in the IA_PD-options 364 field. 366 An IA_PD option may only appear in the options area of a DHCP 367 message. A DHCP message may contain multiple IA_PD options. 369 The status of any operations involving this IA_PD is indicated in a 370 Status Code option in the IA_PD-options field. 372 Note that an IA_PD has no explicit "lifetime" or "lease length" of 373 its own. When the valid lifetimes of all of the prefixes in a IA_PD 374 have expired, the IA_PD can be considered as having expired. T1 and 375 T2 are included to give delegating routers explicit control over when 376 a requesting router should contact the delegating router about a 377 specific IA_PD. 379 In a message sent by a requesting router to a delegating router, 380 values in the T1 and T2 fields indicate the requesting router's 381 preference for those parameters. The requesting router sets T1 and T2 382 to zero if it has no preference for those values. In a message sent 383 by a delegating router to a requesting router, the requesting router 384 MUST use the values in the T1 and T2 fields for the T1 and T2 385 parameters. The values in the T1 and T2 fields are the number of 386 seconds until T1 and T2. 388 The delegating router selects the T1 and T2 times to allow the 389 requesting router to extend the lifetimes of any prefixes in the 390 IA_PD before the lifetimes expire, even if the delegating router is 391 unavailable for some short period of time. Recommended values for T1 392 and T2 are .5 and .8 times the shortest preferred lifetime of the 393 prefixes in the IA_PD that the delegating router is willing to 394 extend, respectively. If the time at which the prefixes in an IA_PD 395 are to be renewed is to be left to the discretion of the requesting 396 router, the delegating router sets T1 and T2 to 0. 398 If a delegating router receives an IA_PD with T1 greater than T2, and 399 both T1 and T2 are greater than 0, the delegating router ignores the 400 invalid values of T1 and T2 and processes the IA_PD as though the 401 delegating router had set T1 and T2 to 0. 403 If a requesting router receives an IA_PD with T1 greater than T2, and 404 both T1 and T2 are greater than 0, the client discards the IA_PD 405 option and processes the remainder of the message as though the 406 delegating router had not included the IA_PD option. 408 10. IA_PD Prefix option 410 The IA_PD Prefix option is used to specify IPv6 address prefixes 411 associated with an IA_PD. The IA_PD Prefix option must be 412 encapsulated in the IA_PD-options field of an IA_PD option. 414 The format of the IA_PD Prefix option is: 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | OPTION_IAPREFIX | option-length | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | preferred-lifetime | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | valid-lifetime | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | prefix-length | | 426 +-+-+-+-+-+-+-+-+ IPv6 prefix | 427 | (16 octets) | 428 | | 429 | | 430 | | 431 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | | . 433 +-+-+-+-+-+-+-+-+ . 434 . IAprefix-options . 435 . . 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 option-code: OPTION_IAPREFIX (TBD) 440 option-length: 25 + length of IAprefix-options field 442 preferred-lifetime: The recommended preferred lifetime for the IPv6 443 prefix in the option, expressed in units of 444 seconds. A value of 0xFFFFFFFF represents infinity. 446 valid-lifetime: The valid lifetime for the IPv6 prefix in the 447 option, expressed in units of seconds. A value of 448 0xFFFFFFFF represents infinity. 450 prefix-length: Length for this prefix in bits 452 IPv6-prefix: An IPv6 prefix 453 IAprefix-options: Options associated with this prefix 455 In a message sent by a requesting router to a delegating router, the 456 values in the fields can be used to indicate the requesting router's 457 preference for those values. The requesting router may send a value 458 of zero to indicate no preference. A requesting router may set the 459 IPv6 prefix field to zero and a given value in the prefix-length 460 field to indicate a preference for the size of the prefix to be 461 delegated. 463 In a message sent by a delegating router the preferred and valid 464 lifetimes should be set to the values of AdvPreferredLifetime and 465 AdvValidLifetime as specified in section "Router Configuration 466 Variables" of RFC2461 [4], unless administratively configured. 468 A requesting router discards any prefixes for which the preferred 469 lifetime is greater than the valid lifetime. A delegating router 470 ignores the lifetimes set by the requesting router if the preferred 471 lifetime is greater than the valid lifetime and ignores the values 472 for T1 and T2 set by the requesting router if those values are 473 greater than the preferred lifetime. 475 The values in the preferred and valid lifetimes are the number of 476 seconds remaining for each lifetime. 478 An IA_PD Prefix option may appear only in an IA_PD option. More than 479 one IA_PD Prefix Option can appear in a single IA_PD option. 481 The status of any operations involving this IA_PD Prefix option is 482 indicated in a Status Code option in the IAprefix-options field. 484 11. Delegating Router Solicitation 486 The requesting router locates and selects a delegating router in the 487 same way as described in section "DHCP Server Solicitation" of RFC 488 3315. The details of the solicitation process are described in this 489 section. 491 11.1 Requesting router behaviour 493 The requesting router creates and transmits a Solicit message as 494 described in sections "Creation of Solicit Messages" and 495 "Transmission of Solicit Messages" of RFC 3315. The requesting router 496 creates an IA_PD and assigns it an IAID. The requesting router MUST 497 include the IA_PD option in the Solicit message. 499 The requesting router processes any received Advertise messages as 500 described in section "Receipt of Advertise Messages" of RFC 3315. The 501 requesting router MAY choose to consider the presence of advertised 502 prefixes in its decision about which delegating router to respond to. 504 The requesting router MUST ignore any Advertise message that includes 505 a Status Code option containing the value NoPrefixAvail, with the 506 exception that the requesting router MAY display the associated 507 status message to the user. 509 11.2 Delegating router behaviour 511 The delegating router processes Solicit messages from requesting 512 routers in the same way as described in section "Receipt of Solicit 513 messages" of RFC 3315. If the message contains an IA_PD option and 514 the delegating router is configured to delegate prefix(es) to the 515 requesting router, the delegating router selects the prefix(es) to be 516 delegated to the requesting router. The mechanism through which the 517 delegating router selects prefix(es) for delegation is not specified 518 in this document. Examples of ways in which the delegating router 519 might select prefix(es) for a requesting router include: static 520 assignment based on subscription to an ISP; dynamic assignment from a 521 pool of available prefixes; selection based on an external authority 522 such as a RADIUS server using the Framed-IPv6-Prefix option as 523 described in RFC 3162 [5]. 525 If the requesting router includes an IA_PD Prefix option in the IA_PD 526 option in its Solicit message, the delegating router MAY choose to 527 use the information in that option to select the prefix(es) or prefix 528 size to be delegated to the requesting router. 530 The delegating router sends an Advertise message to the requesting 531 router in the same way as described in section "Creation and 532 transmission of Advertise messages" of RFC 3315. The delegating 533 router MUST include an IA_PD option, identifying any prefix(es) that 534 the delegating router will delegate to the requesting router. 536 If the delegating router will not assign any prefixes to any IA_PDs 537 in a subsequent Request from the requesting router, the delegating 538 router MUST send an Advertise message to the requesting router that 539 includes the IA_PD with no prefixes in the IA_PD and a Status Code 540 option in the IA_PD containing status code NoPrefixAvail and a status 541 message for the user, a Server Identifier option with the delegating 542 router's DUID and a Client Identifier option with the requesting 543 router's DUID. 545 12. Requesting router initiated prefix delegation 547 A requesting router uses the same message exchanges as described in 548 section "DHCP Client-Initiated Configuration Exchange" of RFC 3315 to 549 obtain or update prefix(es) from a delegating router. The requesting 550 router and the delegating router use the IA_PD Prefix option to 551 exchange information about prefix(es) in much the same way IA Address 552 options are used for assigned addresses. 554 12.1 Requesting router behaviour 556 The requesting router uses a Request message to populate IA_PDs with 557 prefixes. The requesting router includes one or more IA_PD options in 558 the Request message. The delegating router then returns the prefixes 559 for the IA_PDs to the requesting router in IA_PD options in a Reply 560 message. 562 The requesting router includes IA_PD options in any Renew, or Rebind 563 messages sent by the requesting router. The IA_PD option includes all 564 of the prefixes the requesting router currently has associated with 565 that IA_PD. 567 In some circumstances the requesting router may need verification 568 that the delegating router still has a valid binding for the 569 requesting router. Examples of times when a requesting router may ask 570 for such verification include: 572 o The requesting router reboots. 574 o The requesting router's upstream link flaps. 576 o The requesting router is physically disconnected from a wired 577 connection. 579 If such verification is needed the requesting router MUST initiate a 580 Rebind/Reply message exchange as described in the section "Creation 581 and Transmission of Rebind Messages" of RFC 3315, with the exception 582 that the retransmission parameters should be set as for the Confirm 583 message, described in the section "Creation and Transmission of 584 Confirm Messages" of RFC 3315. The requesting router includes any 585 IA_PDs, along with prefixes associated with those IA_PDs in its 586 Rebind message. 588 Each prefix has valid and preferred lifetimes whose durations are 589 specified in the IA_PD Prefix option for that prefix. The requesting 590 router uses Renew and Rebind messages to request the extension of the 591 lifetimes of a delegated prefix. 593 The requesting router uses a Release message to return a delegated 594 prefix to a delegating router. The prefixes to be released MUST be 595 included in the IA_PDs. 597 The Confirm and Decline message types are not used with Prefix 598 Delegation. 600 Upon the receipt of a valid Reply message, for each IA_PD the 601 requesting router assigns a subnet from each of the delegated 602 prefixes to each of the links to which the associated interfaces are 603 attached, with the following exception: the requesting router MUST 604 NOT assign any delegated prefixes or subnets from the delegated 605 prefix(es) to the link through which it received the DHCP message 606 from the delegating router. 608 When a requesting router subnets a delegated prefix, it must assign 609 additional bits to the prefix to generate unique, longer prefixes. 610 For example, if the requesting router in Figure 1 were delegated 611 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and 612 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber 613 network. If the requesting router were delegated 3FFE:FFFF:0::/48 614 and 3FFE:FFFF:5::/48, it might assign 3FFE:FFFF:0:1::/64 and 615 3FFE:FFFF:5:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and 616 3FFE:FFFF:5:2::/64 for assignment to the other link. 618 If the requesting router assigns a delegated prefix to a link to 619 which the router is attached, and begins to send router 620 advertisements for the prefix on the link, the requesting router MUST 621 set the valid lifetime in those advertisements to be no later than 622 the valid lifetime specified in the IA_PD Prefix option. A requesting 623 router MAY use the preferred lifetime specified in the IA_PD Prefix 624 option. 626 Handling of Status Codes options in received Reply messages is 627 described in "Receipt of Reply Messages" of RFC 3315. The 628 NoPrefixAvail Status Code is handled in the same manner as the 629 NoAddrsAvail Status Code. 631 12.2 Delegating Router behaviour 633 When a delegating router receives a Request message from a requesting 634 router that contains an IA_PD option, and the delegating router is 635 authorised to delegate prefix(es) to the requesting router, the 636 delegating router selects the prefix(es) to be delegated to the 637 requesting router. The mechanism through which the delegating router 638 selects prefix(es) for delegation is not specified in this document. 639 Section 11.2 gives examples of ways in which a delegating router 640 might select the prefix(es) to be delegated to a requesting router. 642 A delegating router examines the prefix(es) identified in IA_PD 643 Prefix options (in an IA_PD option) in Renew and Rebind messages and 644 responds according to the current status of the prefix(es). The 645 delegating router returns IA_PD Prefix options (within an IA_PD 646 option) with updated lifetimes for each valid prefix in the message 647 from the requesting router. If the delegating router finds that any 648 of the prefixes are not in the requesting router's binding entry, the 649 delegating router returns the prefix to the requesting router with 650 lifetimes of 0. 652 Behaviour in the case where the delegating router cannot find a 653 binding for the requesting router's IA_PD: 655 Renew message: If the delegating router cannot find a binding 656 for the requesting router's IA_PD the delegating 657 router returns the IA_PD containing no prefixes 658 with a Status Code option set to NoBinding in the 659 Reply message. 661 Rebind message: If the delegating router cannot find a binding 662 for the requesting router's IA_PD and the 663 delegating router determines that the prefixes in 664 the IA_PD are not appropriate for the link to 665 which the requesting router's interface is 666 attached according to the delegating routers 667 explicit configuration, the delegating router MAY 668 send a Reply message to the requesting router 669 containing the IA_PD with the lifetimes of the 670 prefixes in the IA_PD set to zero. This Reply 671 constitutes an explicit notification to the 672 requesting router that the prefixes in the IA_PD 673 are no longer valid. If the delegating router is 674 unable to determine if the prefix is not 675 appropriate for the link, the Rebind message is 676 discarded. 678 A delegating router may mark any prefix(es) in IA_PD Prefix options 679 in a Release message from a requesting router as "available", 680 dependent on the mechanism used to acquire the prefix, e.g in the 681 case of a dynamic pool. 683 The delegating router MUST include an IA_PD Prefix option or options 684 (in an IA_PD option) in Reply messages sent to a requesting router. 686 13. Prefix Delegation reconfiguration 688 This section describes prefix delegation in Reconfigure message 689 exchanges. 691 13.1 Delegating Router behaviour 692 The delegating router initiates a configuration message exchange with 693 a requesting router, as described in the section "DHCP 694 Server-Initiated Configuration Exchange" of RFC 3315. The delegating 695 router specifies the IA_PD option in the Option Request option to 696 cause the requesting router to include an IA_PD option to obtain new 697 information about delegated prefix(es). 699 13.2 Requesting Router behaviour 701 The requesting router responds to a Reconfigure message received from 702 a delegating router as described in RFC 3315. The requesting router 703 MUST include the IA_PD Prefix option(s) (in an IA_PD option) for 704 prefix(es) that have been delegated to the requesting router by the 705 delegating router from which the Reconfigure message was received. 707 14. Relay agent behaviour 709 A relay agent forwards messages containing Prefix Delegation options 710 in the same way as described in section "Relay Behaviour" of RFC 711 3315. 713 If a delegating router communicates with a requesting router through 714 a relay agent, the delegating router may need a protocol or other 715 out-of-band communication to add routing information for delegated 716 prefixes into the provider edge router. 718 15. Security Considerations 720 Security considerations in DHCP are described in the section 721 "Security Considerations" of RFC 3315. 723 A rogue delegating router can issue bogus prefixes to a requesting 724 router. This may cause denial of service due to unreachability. 726 A malicious requesting router may be able to mount a denial of 727 service attack by repeated requests for delegated prefixes that 728 exhaust the delegating router's available prefixes. 730 To guard against attacks through prefix delegation, requesting 731 routers and delegating routers SHOULD use DHCP authentication as 732 described in section "Authentication of DHCP messages" of RFC 3315. 733 For point to point links, where one trusts that there is no man in 734 the middle, or one trusts layer two authentication, DHCP 735 authentication or IPsec may not be necessary. Because a requesting 736 router and delegating routers must each have at least one assigned 737 IPv6 address, the routers may be able to use IPsec for authentication 738 of DHCPv6 messages. The details of using IPsec for DHCPv6 are under 739 development. 741 Networks configured with delegated prefixes should be configured to 742 preclude intentional or inadvertent inappropriate advertisement of 743 these prefixes. 745 16. IANA Considerations 747 IANA is requested to assign option codes to: 749 OPTION_IA_PD 751 OPTION_IAPREFIX 753 from the option-code space as defined in section "DHCPv6 Options" of 754 RFC 3315. 756 IANA is requested to assign a status code: 758 NoPrefixAvail: Delegating router has no prefixes available to 759 assign to the IAPD(s) 761 from the status-code space as defined in section "Status Codes" of 762 RFC 3315. 764 17. Acknowledgements 766 Thanks for the input and review by (in alphabetical order) Steve 767 Deering, Dave Forster, Brian Haberman, Tatuya Jinmei, Shin Miyakawa, 768 Pekka Savola, Bernie Volz, Trevor Warwick and Toshi Yamasaki. 770 Normative References 772 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 773 Specification", RFC 2460, December 1998. 775 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 776 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 777 RFC 3315, July 2003. 779 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 780 Levels", BCP 14, RFC 2119, March 1997. 782 [4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 783 IP Version 6 (IPv6)", RFC 2461, December 1998. 785 [5] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, 786 August 2001. 788 Informative References 790 [6] Miyakawa, S. and R. Droms, "Requirements for IPv6 prefix 791 delegation", draft-ietf-ipv6-prefix-delegation-requirement-03 792 (work in progress), August 2003. 794 Authors' Addresses 796 Ole Troan 797 Cisco Systems 798 250 Longwater Avenue 799 Reading RG2 6GB 800 United Kingdom 802 Phone: +44 20 8824 8666 803 EMail: ot@cisco.com 805 Ralph Droms 806 Cisco Systems 807 1414 Massachusetts Avenue 808 Boxborough, MA 01719 809 USA 811 Phone: +1 978 936-1674 812 EMail: rdroms@cisco.com 814 Intellectual Property Statement 816 The IETF takes no position regarding the validity or scope of any 817 intellectual property or other rights that might be claimed to 818 pertain to the implementation or use of the technology described in 819 this document or the extent to which any license under such rights 820 might or might not be available; neither does it represent that it 821 has made any effort to identify any such rights. Information on the 822 IETF's procedures with respect to rights in standards-track and 823 standards-related documentation can be found in BCP-11. Copies of 824 claims of rights made available for publication and any assurances of 825 licenses to be made available, or the result of an attempt made to 826 obtain a general license or permission for the use of such 827 proprietary rights by implementors or users of this specification can 828 be obtained from the IETF Secretariat. 830 The IETF invites any interested party to bring to its attention any 831 copyrights, patents or patent applications, or other proprietary 832 rights which may cover technology that may be required to practice 833 this standard. Please address the information to the IETF Executive 834 Director. 836 Full Copyright Statement 838 Copyright (C) The Internet Society (2003). All Rights Reserved. 840 This document and translations of it may be copied and furnished to 841 others, and derivative works that comment on or otherwise explain it 842 or assist in its implementation may be prepared, copied, published 843 and distributed, in whole or in part, without restriction of any 844 kind, provided that the above copyright notice and this paragraph are 845 included on all such copies and derivative works. However, this 846 document itself may not be modified in any way, such as by removing 847 the copyright notice or references to the Internet Society or other 848 Internet organizations, except as needed for the purpose of 849 developing Internet standards in which case the procedures for 850 copyrights defined in the Internet Standards process must be 851 followed, or as required to translate it into languages other than 852 English. 854 The limited permissions granted above are perpetual and will not be 855 revoked by the Internet Society or its successors or assignees. 857 This document and the information contained herein is provided on an 858 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 859 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 860 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 861 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 862 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 864 Acknowledgment 866 Funding for the RFC Editor function is currently provided by the 867 Internet Society.