idnits 2.17.1 draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.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 (March 3, 2003) is 7697 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) == Unused Reference: '4' is defined on line 803, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 806, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2373 (ref. '4') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2462 (ref. '5') (Obsoleted by RFC 4862) == Outdated reference: A later version (-04) exists of draft-ietf-ipv6-prefix-delegation-requirement-00 Summary: 6 errors (**), 0 flaws (~~), 7 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: September 1, 2003 Cisco Systems 5 March 3, 2003 7 IPv6 Prefix Options for DHCPv6 8 draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.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 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 1, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 The Prefix Delegation options provide a mechanism for automated 40 delegation of IPv6 prefixes using DHCP. This mechanism is intended 41 for delegating long-lived prefix from a delegating router to a 42 requesting router, across an administrative boundary, where the 43 delegating router does not require knowledge about the topology of 44 the links in the network to which the prefixes will be assigned. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. DHCPv6 specification dependency . . . . . . . . . . . . . . 3 50 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 51 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 52 5. Model and Applicability . . . . . . . . . . . . . . . . . . 4 53 5.1 Example network architecture . . . . . . . . . . . . . . . . 4 54 6. Identity Association for Prefix Delegation . . . . . . . . . 6 55 7. Overview of DHCP with Prefix Delegation . . . . . . . . . . 7 56 8. Interface Selection . . . . . . . . . . . . . . . . . . . . 7 57 9. Identity Association for Prefix Delegation Option . . . . . 8 58 10. IA_PD Prefix option . . . . . . . . . . . . . . . . . . . . 10 59 11. Delegating Router Solicitation . . . . . . . . . . . . . . . 11 60 11.1 Requesting router behaviour . . . . . . . . . . . . . . . . 11 61 11.2 Delegating router behaviour . . . . . . . . . . . . . . . . 12 62 12. Requesting router initiated prefix delegation . . . . . . . 13 63 12.1 Requesting router behaviour . . . . . . . . . . . . . . . . 13 64 12.2 Delegating Router behaviour . . . . . . . . . . . . . . . . 14 65 13. Prefix Delegation reconfiguration . . . . . . . . . . . . . 16 66 13.1 Delegating Router behaviour . . . . . . . . . . . . . . . . 16 67 13.2 Requesting Router behaviour . . . . . . . . . . . . . . . . 16 68 14. Relay agent behaviour . . . . . . . . . . . . . . . . . . . 16 69 15. Security Considerations . . . . . . . . . . . . . . . . . . 16 70 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 71 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 72 18. Changes in draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03 . 17 73 Normative References . . . . . . . . . . . . . . . . . . . . 18 74 Informative References . . . . . . . . . . . . . . . . . . . 18 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 76 Full Copyright Statement . . . . . . . . . . . . . . . . . . 20 78 1. Introduction 80 This document describes new options for DHCP, which provide a 81 mechanism for the delegation of IPv6 prefixes. Through these 82 options, a delegating router can delegate prefixes to authorised 83 requesting routers. 85 The prefix delegation mechanism described in this document is 86 intended for simple delegation of prefixes from a delegating router 87 to requesting routers. It is appropriate for situations in which the 88 delegating router does not have knowledge about the topology of the 89 networks to which the requesting router is attached, and the 90 delegating router does not require other information aside from the 91 identity of the requesting router to choose a prefix for delegation. 92 For example, these options would be used by a service provider to 93 assign a prefix to a CPE device acting as a router between the 94 subscriber's internal network and the service provider's core 95 network. 97 Many applications expect stable addresses. Even though this 98 mechanism makes automatic renumbering easier, it is expected that 99 prefixes have a long lifespan. During renumbering it is expected 100 that the old and the new prefix co-exist for some time. 102 The design of this prefix delegation mechanism meets the requirements 103 for prefix delegation in Requirements for IPv6 prefix delegation [8]. 105 2. DHCPv6 specification dependency 107 This document describes an extension to the DHCPv6 specification [6]. 108 This document should be read in conjunction with the DHCPv6 109 specification for a complete specification of the Prefix Delegation 110 options and mechanism. Definitions for terms and acronyms not 111 specifically defined in this document are defined in the DHCPv6 112 specification [6]. 114 3. Terminology 116 This document uses the terminology defined in RFC2460 [2] and the 117 DHCP specification [6]. In addition, this document uses the 118 following terms: 120 requesting router The router that acts as a DHCP client and is 121 requesting prefix(es) to be assigned. 123 delegating router The router that acts as a DHCP server, and is 124 responding to the prefix request. 126 Identity Association for Prefix Delegation (IA_PD) A collection of 127 prefixes assigned to the requesting router. Each 128 IA_PD has an associated IAID. A requesting 129 router may have more than one IA_PD assigned to 130 it; for example, one for each of its interfaces. 132 4. Requirements 134 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 135 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 136 document, are to be interpreted as described in RFC 2119 [1]. 138 5. Model and Applicability 140 The model of operation for prefix delegation is as follows. A 141 delegating router is provided IPv6 prefixes to be delegated to 142 requesting routers. Examples of ways in which the delegating router 143 may be provided these prefixes are given in Section 12.2. A 144 requesting router requests prefix(es) from the delegating router, as 145 described in Section 12.1. The delegating router chooses prefix(es) 146 for delegation, and responds with prefix(es) to the requesting 147 router. The requesting router is then responsible for the delegated 148 prefix(es). For example, the requesting router might assign a subnet 149 from a delegated prefix to one of its interfaces, and begin sending 150 router advertisements for the prefix on that link. 152 Each prefix has an associated valid and preferred lifetime, which 153 constitutes an agreement about the length of time over which the 154 requesting router is allowed to use the prefix. A requesting router 155 can request an extension of the lifetimes on a delegated prefix and 156 is required to terminate the use of a delegated prefix if the valid 157 lifetime of the prefix expires. 159 This prefix delegation mechanism would be appropriate for use by an 160 ISP to delegate a prefix to a subscriber, where the delegated prefix 161 would possibly be subnetted and assigned to the links within the 162 subscriber's network. 164 5.1 Example network architecture 165 Figure 1 illustrates a network architecture in which prefix 166 delegation could be used. 168 +--------+ \ 169 | AAA | \ 170 | server | \ 171 +---+----+ | 172 ___|__________________ | 173 / \ | 174 | ISP core network | | 175 \__________ ___________/ | 176 | | ISP 177 +-------+-------+ | network 178 | Aggregation | | 179 | device | | 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 In this example an AAA server is configured with a prefix assigned to 203 the customer at the time of subscription to the ISP service. The 204 prefix delegation process begins when the requesting router requests 205 configuration information through DHCP. The DHCP messages from the 206 requesting router are received by the delegating router in the 207 aggregation device. When the delegating router receives the request, 208 it consults the AAA server to authenticate and authorise the 209 requesting router. The AAA server returns the subscriber's 210 prefix(es) in a Framed-IPv6-Prefix attribute as described in RFC 3162 211 [7], and the delegating router returns them to the requesting router. 213 The requesting router subnets the delegated prefix and assigns the 214 longer prefixes to links in the subscriber's network. In a typical 215 scenario based on the network shown in Figure 1, the requesting 216 router subnets a single delegated /48 prefix into /64 prefixes and 217 assigns one /64 prefix to each of the links in the subscriber 218 network. 220 The prefix delegation options can be used in conjunction with other 221 DHCP options carrying other configuration information to the 222 requesting router. The requesting router may, in turn, then provide 223 DHCP service to hosts attached to the internal network. For example, 224 the requesting router may obtain the addresses of DNS and NTP servers 225 from the ISP delegating router, and then pass that configuration 226 information on to the subscriber hosts through a DHCP server in the 227 requesting router. 229 6. Identity Association for Prefix Delegation 231 An IA_PD is a construct through which a delegating router and a 232 requesting router can identify, group and manage a set of related 233 IPv6 prefixes. Each IA_PD consists of an IAID and associated 234 configuration information. An IA_PD for prefixes is the equivalent 235 of an IA (described in DHCPv6 specification [6]) for addresses. 237 An IA_PD is different from an IA, in that it does not need to be 238 associated with exactly one interface. One IA_PD can be associated 239 with the requesting router, with a set of interfaces or with exactly 240 one interface. A requesting router must create at least one distinct 241 IA_PD. It may associate a distinct IA_PD with each of its downstream 242 network interfaces and use that IA_PD to obtain a prefix for that 243 interface from the delegating router. 245 The IAID uniquely identifies the IA_PD and must be chosen to be 246 unique among the IA_PD IAIDs on the requesting router. The IAID is 247 chosen by the requesting router. For any given use of an IA_PD by 248 the requesting router, the IAID for that IA_PD MUST be consistent 249 across restarts of the requesting router. The requesting router may 250 maintain consistency either by storing the IAID in non-volatile 251 storage or by using an algorithm that will consistently produce the 252 same IAID as long as the configuration of the requesting router has 253 not changed. If the requesting router uses only one IAID, it can use 254 a well-known value, e.g zero. 256 The configuration information in an IA_PD consists of one or more 257 IPv6 prefixes along with the times T1 and T2 for the IA_PD. See 258 section Section 9 for the representation of an IA_PD in a DHCP 259 message. 261 7. Overview of DHCP with Prefix Delegation 263 Prefix delegation with DHCP is independent of address assignment with 264 DHCP. A requesting router can use DHCP for just prefix delegation or 265 for prefix delegation along with address assignment and other 266 configuration information. 268 A requesting router first creates an IA_PD and assigns it an IAID. 269 The requesting router then transmits a Solicit message containing an 270 IA_PD option describing the IA_PD. Delegating routers that can 271 delegate prefixes to the IA_PD respond to the requesting router with 272 an Advertise message. 274 The requesting router may include prefixes in the IA_PDs as a hint to 275 the delegating router about specific prefixes for which the 276 requesting router has a preference. 278 When the requesting router has identified a delegating router, the 279 requesting router uses a Request message to populate the IA_PDs with 280 prefixes. The requesting router includes one or more IA_PD options 281 in the Request message. The delegating router returns prefixes and 282 other information about the IA_PDs to the requesting router in IA_PD 283 options in a Reply message. The requesting router records the 284 lifetimes for the delegated prefix(es) and uses the prefix(es) as 285 described in the previous section. 287 Before the valid lifetime on each delegated prefix expires, the 288 requesting router includes the prefix in an IA_PD option sent in a 289 Renew message to the delegating router. The delegating router 290 responds by returning the prefix with updated lifetimes to the 291 requesting router. 293 8. Interface Selection 295 Delegated prefixes are not associated with a particular interface in 296 the same way as addresses are for address assignment, and the rules 297 described in the section "Client Source Address and Interface 298 Selection" of the DHCP specification [6] do not apply. 300 When a requesting router sends a DHCP message, it SHOULD be sent on 301 the interface associated with the upstream router (ISP network). The 302 upstream interface is typically determined by configuration. This 303 rule applies even in the case where a separate IA_PD is used for each 304 downstream interface. 306 When a requesting router sends a DHCP message directly to a 307 delegating router using unicast (after receiving the Server Unicast 308 option from that delegating router), the source address SHOULD be an 309 address from the upstream interface and which is suitable for use by 310 the delegating router in responding to the requesting router. 312 9. Identity Association for Prefix Delegation Option 314 The IA_PD option is used to carry a prefix delegation identity 315 association, the parameters associated with the IA_PD and the 316 prefixes associated with it. 318 The format of the IA_PD option is: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | OPTION_IA_PD | option-length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | IAID (4 octets) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | T1 | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | T2 | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 . . 332 . IA_PD-options . 333 . . 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 option-code: OPTION_IA_PD (TBD) 338 option-length: 12 + length of IA_PD-options field. 340 IAID The unique identifier for this IA_PD; the IAID must 341 be unique among the identifiers for all of this 342 requesting router's IA_PDs. 344 T1 The time at which the requesting router should 345 contact the delegating router from which the 346 prefixes in the IA_PD were obtained to extend the 347 lifetimes of the prefixes delegated to the IA_PD; 348 T1 is a time duration relative to the current time 349 expressed in units of seconds. 351 T2 The time at which the requesting router should 352 contact any available delegating router to extend 353 the lifetimes of the prefixes assigned to the 354 IA_PD; T2 is a time duration relative to the 355 current time expressed in units of seconds. 357 IA_PD-options Options associated with this IA_PD. 359 The IA_PD-options field encapsulates those options that are specific 360 to this IA_PD. For example, all of the IA_PD Prefix Options carrying 361 the prefixes associated with this IA_PD are in the IA_PD-options 362 field. 364 An IA_PD option may only appear in the options area of a DHCP 365 message. A DHCP message may contain multiple IA_PD options. 367 The status of any operations involving this IA_PD is indicated in a 368 Status Code option in the IA_PD-options field. 370 Note that an IA_PD has no explicit "lifetime" or "lease length" of 371 its own. When the valid lifetimes of all of the prefixes in a IA_PD 372 have expired, the IA_PD can be considered as having expired. T1 and 373 T2 are included to give delegating routers explicit control over when 374 a requesting router should contact the delegating router about a 375 specific IA_PD. 377 In a message sent by a requesting router to a delegating router, 378 values in the T1 and T2 fields indicate the requesting router's 379 preference for those parameters. The requesting router sets T1 and 380 T2 to zero if it has no preference for those values. In a message 381 sent by a delegating router to a requesting router, the requesting 382 router MUST use the values in the T1 and T2 fields for the T1 and T2 383 parameters. The values in the T1 and T2 fields are the number of 384 seconds until T1 and T2. 386 The delegating router selects the T1 and T2 times to allow the 387 requesting router to extend the lifetimes of any prefixes in the 388 IA_PD before the lifetimes expire, even if the delegating router is 389 unavailable for some short period of time. Recommended values for T1 390 and T2 are .5 and .8 times the shortest preferred lifetime of the 391 prefixes in the IA_PD that the delegating router is willing to 392 extend, respectively. If the time at which the prefixes in an IA_PD 393 are to be renewed is to be left to the discretion of the requesting 394 router, the delegating router sets T1 and T2 to 0. 396 If a delegating router receives an IA_PD with T1 greater than T2, and 397 both T1 and T2 are greater than 0, the delegating router ignores the 398 invalid values of T1 and T2 and processes the IA_PD as though the 399 delegating router had set T1 and T2 to 0. 401 If a requesting router receives an IA_PD with T1 greater than T2, and 402 both T1 and T2 are greater than 0, the client discards the IA_PD 403 option and processes the remainder of the message as though the 404 delegating router had not included the IA_PD option. 406 10. IA_PD Prefix option 408 The IA_PD Prefix option is used to specify IPv6 address prefixes 409 associated with an IA_PD. The IA_PD Prefix option must be 410 encapsulated in the IA_PD-options field of an IA_PD option. 412 The format of the IA_PD Prefix option is: 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | OPTION_IAPREFIX | option-length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | preferred-lifetime | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | valid-lifetime | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | prefix-length | | 424 +-+-+-+-+-+-+-+-+ IPv6 prefix | 425 | (16 octets) | 426 | | 427 | | 428 | | 429 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | | . 431 +-+-+-+-+-+-+-+-+ . 432 . IAprefix-options . 433 . . 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 option-code: OPTION_IAPREFIX (TBD) 438 option-length: 25 + length of IAprefix-options field 440 preferred-lifetime: The recommended preferred lifetime for the IPv6 441 prefix in the option, expressed in units of 442 seconds. A value of 0xFFFFFFFF represents 443 infinity. 445 valid-lifetime: The valid lifetime for the IPv6 prefix in the 446 option, expressed in units of seconds. A value of 447 0xFFFFFFFF represents infinity. 449 prefix-length: Length for this prefix in bits 451 IPv6-prefix: An IPv6 prefix 452 IAprefix-options: Options associated with this prefix 454 In a message sent by a requesting router to a delegating router, the 455 values in the fields can be used to indicate the requesting router's 456 preference for those values. The requesting router may send a value 457 of zero to indicate no preference. A requesting router may set the 458 IPv6 prefix field to zero and a given value in the prefix-length 459 field to indicate a preference for the size of the prefix to be 460 delegated. 462 In a message sent by a delegating router the preferred and valid 463 lifetimes should be set to the values of AdvPreferredLifetime and 464 AdvValidLifetime as specified in section "Router Configuration 465 Variables" of RFC2461 [3], unless administratively configured. 467 A requesting router discards any prefixes for which the preferred 468 lifetime is greater than the valid lifetime. A delegating router 469 ignores the lifetimes set by the requesting router if the preferred 470 lifetime is greater than the valid lifetime and ignores the values 471 for T1 and T2 set by the requesting router if those values are 472 greater than the preferred lifetime. 474 The values in the preferred and valid lifetimes are the number of 475 seconds remaining for each lifetime. 477 An IA_PD Prefix option may appear only in an IA_PD option. More than 478 one IA_PD Prefix Option can appear in a single IA_PD option. 480 The status of any operations involving this IA_PD Prefix option is 481 indicated in a Status Code option in the IAprefix-options field. 483 11. Delegating Router Solicitation 485 The requesting router locates and selects a delegating router in the 486 same way as described in section "DHCP Server Solicitation" of the 487 DHCP specification [6]. The details of the solicitation process are 488 described in this section. 490 11.1 Requesting router behaviour 492 The requesting router creates and transmits a Solicit message as 493 described in sections "Creation of Solicit Messages" and 494 "Transmission of Solicit Messages" of the DHCP specification [6]. 495 The requesting router creates an IA_PD and assigns it an IAID. The 496 requesting router MUST include the IA_PD option in the Solicit 497 message. 499 The requesting router processes any received Advertise messages as 500 described in section "Receipt of Advertise Messages" in the DHCP 501 specification [6]. The requesting router MAY choose to consider the 502 presence of advertised prefixes in its decision about which 503 delegating router to respond to. 505 The requesting router MUST ignore any Advertise message that includes 506 a Status Code option containing the value NoPrefixAvail, with the 507 exception that the requesting router MAY display the associated 508 status message to the user. 510 11.2 Delegating router behaviour 512 The delegating router processes Solicit messages from requesting 513 routers in the same way as described in section "Receipt of Solicit 514 messages" of the DHCP specification [6]. If the message contains an 515 IA_PD option and the delegating router is configured to delegate 516 prefix(es) to the requesting router, the delegating router selects 517 the prefix(es) to be delegated to the requesting router. The 518 mechanism through which the delegating router selects prefix(es) for 519 delegation is not specified in this document. Examples of ways in 520 which the delegating router might select prefix(es) for a requesting 521 router include: static assignment based on subscription to an ISP; 522 dynamic assignment from a pool of available prefixes; selection based 523 on an external authority such as a RADIUS server using the Framed- 524 IPv6-Prefix option as described in RFC 3162 [7]. 526 If the delegating router cannot delegate any prefixes to an IA_PD in 527 the message from the requesting router, the delegating router MUST 528 include the IA_PD in the Advertise message with no prefixes in the 529 IA_PD and a Status Code option in the IA_PD containing status code 530 NoPrefixAvail. 532 If the requesting router includes an IA_PD Prefix option in the IA_PD 533 option in its Solicit message, the delegating router MAY choose to 534 use the information in that option to select the prefix(es) or prefix 535 size to be delegated to the requesting router. 537 The delegating router sends an Advertise message to the requesting 538 router in the same way as described in section "Creation and 539 transmission of Advertise messages" in the DHCP specification [6]. 540 The delegating router MUST include an IA_PD option, identifying any 541 prefix(es) that the delegating router will delegate to the requesting 542 router. 544 If the delegating router will not assign any prefixes to any IA_PDs 545 in a subsequent Request from the requesting router, the delegating 546 router MUST send an Advertise message to the requesting router that 547 includes a Status Code option with code NoPrefixAvail and a status 548 message for the user, a Server Identifier option with the delegating 549 router's DUID and a Client Identifier option with the requesting 550 router's DUID. 552 12. Requesting router initiated prefix delegation 554 A requesting router uses the same message exchanges as described in 555 section "DHCP Client-Initiated Configuration Exchange" of the DHCP 556 specification [6] to obtain or update prefix(es) from a delegating 557 router. The requesting router and the delegating router use the 558 IA_PD Prefix option to exchange information about prefix(es) in much 559 the same way IA Address options are used for assigned addresses. 561 12.1 Requesting router behaviour 563 The requesting router uses a Request message to populate IA_PDs with 564 prefixes. The requesting router includes one or more IA_PD options 565 in the Request message. The delegating router then returns the 566 prefixes for the IA_PDs to the requesting router in IA_PD options in 567 a Reply message. 569 The requesting router includes IA_PD options in any Renew, or Rebind 570 messages sent by the requesting router. The IA_PD option include all 571 of the prefixes the requesting router currently has associated with 572 that IA_PD. 574 In some circumstances the requesting router may need verification 575 that the delegating router still has a valid binding for the 576 requesting router. Examples of times when a requesting router may 577 ask for such verification include: 579 o The requesting router reboots. 581 o The requesting router's upstream link flaps. 583 o The requesting router is physically disconnected from a wired 584 connection. 586 If such verification is needed the requesting router MUST initiate a 587 Rebind/Reply message exchange as described in the section "Creation 588 and Transmission of Rebind Messages" of the DHCP specification [6], 589 with the exception that the retransmission parameters should be set 590 as for the Confirm message, described in the section "Creation and 591 Transmission of Confirm Messages" of the DHCP specification [6]. The 592 requesting router includes any IA_PDs, along with prefixes associated 593 with those IA_PDs in its Rebind message. 595 Each prefix has valid and preferred lifetimes whose durations are 596 specified in the IA_PD Prefix option for that prefix. The requesting 597 router uses Renew and Rebind messages to request the extension of the 598 lifetimes of a delegated prefix. 600 The requesting router uses a Release message to return a delegated 601 prefix to a delegating router. The prefixes to be released MUST be 602 included in the IA_PDs. 604 The Confirm and Decline message types are not used with Prefix 605 Delegation. 607 Upon the receipt of a valid Reply message, for each IA_PD the 608 requesting router assigns a subnet from each of the delegated 609 prefixes to each of the links to which the associated interfaces are 610 attached, with the following exception: the requesting router MUST 611 NOT assign any delegated prefixes or subnets from the delegated 612 prefix(es) to the link through which it received the DHCP message 613 from the delegating router. 615 When a requesting router subnets a delegated prefix, it must assign 616 additional bits to the prefix to generate unique, longer prefixes. 617 For example, if the requesting router in Figure 1 were delegated 618 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and 619 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber 620 network. If the requesting router were delegated 3FFE:FFFF:0::/48 621 and 3FFE:FFFF:1::/48, it might assign 3FFE:FFFF:0:1::/64 and 622 3FFE:FFFF:1:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and 623 3FFE:FFFF:1:2::/64 for assignment to the other link. 625 If the requesting router assigns a delegated prefix to a link to 626 which the router is attached, and begins to send router 627 advertisements for the prefix on the link, the requesting router MUST 628 set the valid lifetime in those advertisements to be no later than 629 the valid lifetime specified in the IA_PD Prefix option. A 630 requesting router MAY use the preferred lifetime specified in the 631 IA_PD Prefix option. 633 Handling of Status Codes options in received Reply messages is 634 described in "Receipt of Reply Messages" of the DHCP specification 635 [6]. The NoPrefixAvail Status Code is handled in the same manner as 636 the NoAddrsAvail Status Code. 638 12.2 Delegating Router behaviour 640 When a delegating router receives a Request message from a requesting 641 router that contains an IA_PD option, and the delegating router is 642 authorised to delegate prefix(es) to the requesting router, the 643 delegating router selects the prefix(es) to be delegated to the 644 requesting router. The mechanism through which the delegating router 645 selects prefix(es) for delegation is not specified in this document. 646 Section 11.2 gives examples of ways in which a delegating router 647 might select the prefix(es) to be delegated to a requesting router. 649 A delegating router examines the prefix(es) identified in IA_PD 650 Prefix options (in an IA_PD option) in Renew and Rebind messages and 651 responds according to the current status of the prefix(es). The 652 delegating router returns IA_PD Prefix options (within an IA_PD 653 option) with updated lifetimes for each valid prefix in the message 654 from the requesting router. If the delegating router finds that any 655 of the prefixes are not in the requesting router's binding entry, the 656 delegating router returns the prefix to the requesting router with 657 lifetimes of 0. 659 Behaviour in the case where the delegating router cannot find a 660 binding for the requesting router's IA_PD: 662 Renew message If the delegating router cannot find a binding 663 for the requesting router's IA_PD the delegating 664 router returns the IA_PD containing no prefixes 665 with a Status Code option set to NoBinding in the 666 Reply message. 668 Rebind message If the delegating router cannot find a binding 669 for the requesting router's IA_PD and the 670 delegating router determines that the prefixes in 671 the IA_PD are not appropriate for the link to 672 which the requesting router's interface is 673 attached according to the delegating routers 674 explicit configuration, the delegating router MAY 675 send a Reply message to the requesting router 676 containing the IA_PD with the lifetimes of the 677 prefixes in the IA_PD set to zero. This Reply 678 constitutes an explicit notification to the 679 requesting router that the prefixes in the IA_PD 680 are no longer valid. If the delegating router is 681 unable to determine if the prefix is not 682 appropriate for the link, the Rebind message is 683 discarded. 685 A delegating router may mark any prefix(es) in IA_PD Prefix options 686 in a Release message from a requesting router as "available", 687 dependent on the mechanism used to acquire the prefix, e.g in the 688 case of a dynamic pool. 690 The delegating router MUST include an IA_PD Prefix option or options 691 (in an IA_PD option) in Reply messages sent to a requesting router. 693 13. Prefix Delegation reconfiguration 695 This section describes prefix delegation in Reconfigure message 696 exchanges. 698 13.1 Delegating Router behaviour 700 The delegating router initiates a configuration message exchange with 701 a requesting router, as described in the section "DHCP Server- 702 Initiated Configuration Exchange" of the DHCP specification [6]. The 703 delegating router specifies the IA_PD option in the Option Request 704 option to cause the requesting router to include an IA_PD option to 705 obtain new information about delegated prefix(es). 707 13.2 Requesting Router behaviour 709 The requesting router responds to a Reconfigure message received from 710 a delegating router as described in the DHCP specification [6]. The 711 requesting router MUST include the IA_PD Prefix option(s) (in an 712 IA_PD option) for prefix(es) that have been delegated to the 713 requesting router by the delegating router from which the Reconfigure 714 message was received. 716 14. Relay agent behaviour 718 A relay agent forwards messages containing Prefix Delegation options 719 in the same way as described in section "Relay Behaviour" of the DHCP 720 specification [6]. 722 If a delegating router communicates with a requesting router through 723 a relay agent, the delegating router may need a protocol or other 724 out-of-band communication to add routing information for delegated 725 prefixes into the provider edge router. 727 15. Security Considerations 729 Security considerations in DHCP are described in the section 730 "Security Considerations" of the DHCP specification [6]. 732 A rogue delegating router can issue bogus prefixes to a requesting 733 router. This may cause denial of service due to unreachability. 735 An intruder requesting router may be able to mount a denial of 736 service attack by repeated requests for delegated prefixes that 737 exhaust the delegating router's available prefixes. 739 To guard against attacks through prefix delegation, requesting 740 routers and delegating routers SHOULD use DHCP authentication as 741 described in section "Authentication of DHCP messages" in the DHCP 742 specification [6]. For point to point links, where one trusts that 743 there is no man in the middle, or one trusts layer two 744 authentication, DHCP authentication or IPsec may not be necessary. 745 Because a requesting router and delegating routers must each have at 746 least one assigned IPv6 address, the routers may be able to use IPsec 747 for authentication of DHCPv6 messages. The details of using IPsec 748 for DHCPv6 are under development. 750 16. IANA Considerations 752 IANA is requested to assign option codes to: 754 OPTION_IA_PD 756 OPTION_IAPREFIX 758 from the option-code space as defined in section "DHCPv6 Options" of 759 the DHCPv6 specification [6]. 761 IANA is requested to assign a status code: 763 NoPrefixAvail Delegating router has no prefixes available to 764 assign to the IAPD(s) 766 from the status-code space as defined in section "Status Codes" of 767 the DHCPv6 specification [6]. 769 17. Acknowledgements 771 Thanks for the input and review by (in alphabetical order) Steve 772 Deering, Dave Forster, Brian Haberman, Tatuya Jinmei, Shin Miyakawa, 773 Pekka Savola, Bernie Volz, Trevor Warwick and Toshi Yamasaki. 775 18. Changes in draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03 777 o Clarified that this draft is an extension of the DHCPv6 778 specification and that complete specification and terminology can 779 be found in the DHCPv6 specification. 781 o Updated relevant sections to be consistent with draft-ietf-dhc- 782 dhcpv6-interop-00.txt. This includes T1/T2 times, preferred and 783 valid lifetimes and Rebind/Renew usage. 785 o Clarified the usage of the NoPrefixAvail Status Code 787 o Clarified delegating router behaviour when no binding is found for 788 Renew/Rebind. 790 o Various editorial changes 792 Normative References 794 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 795 Levels", BCP 14, RFC 2119, March 1997. 797 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 798 Specification", RFC 2460, December 1998. 800 [3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 801 IP Version 6 (IPv6)", RFC 2461, December 1998. 803 [4] Hinden, R. and S. Deering, "IP Version 6 Addressing 804 Architecture", RFC 2373, July 1998. 806 [5] Thomson, S. and T. Narten, "IPv6 Stateless Address 807 Autoconfiguration", RFC 2462, December 1998. 809 [6] Droms, R., "Dynamic Host Configuration Protocol for IPv6 810 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), November 811 2002. 813 [7] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, 814 August 2001. 816 Informative References 818 [8] Miyakawa, S., "Requirements for IPv6 prefix delegation", draft- 819 ietf-ipv6-prefix-delegation-requirement-00 (work in progress), 820 November 2002. 822 Authors' Addresses 824 Ole Troan 825 Cisco Systems 826 250 Longwater Avenue 827 Reading RG2 6GB 828 United Kingdom 830 Phone: +44 20 8824 8666 831 EMail: ot@cisco.com 832 Ralph Droms 833 Cisco Systems 834 300 Apollo Drive 835 Chelmsford, MA 01824 836 USA 838 Phone: +1 978 497 4733 839 EMail: rdroms@cisco.com 841 Full Copyright Statement 843 Copyright (C) The Internet Society (2003). All Rights Reserved. 845 This document and translations of it may be copied and furnished to 846 others, and derivative works that comment on or otherwise explain it 847 or assist in its implementation may be prepared, copied, published 848 and distributed, in whole or in part, without restriction of any 849 kind, provided that the above copyright notice and this paragraph are 850 included on all such copies and derivative works. However, this 851 document itself may not be modified in any way, such as by removing 852 the copyright notice or references to the Internet Society or other 853 Internet organizations, except as needed for the purpose of 854 developing Internet standards in which case the procedures for 855 copyrights defined in the Internet Standards process must be 856 followed, or as required to translate it into languages other than 857 English. 859 The limited permissions granted above are perpetual and will not be 860 revoked by the Internet Society or its successors or assigns. 862 This document and the information contained herein is provided on an 863 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 864 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 865 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 866 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 867 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 869 Acknowledgement 871 Funding for the RFC Editor function is currently provided by the 872 Internet Society.