diff options
Diffstat (limited to 'rfc/rfc3633.txt')
| -rw-r--r-- | rfc/rfc3633.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/rfc/rfc3633.txt b/rfc/rfc3633.txt new file mode 100644 index 00000000..b262855e --- /dev/null +++ b/rfc/rfc3633.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group O. Troan +Request for Comments: 3633 R. Droms +Category: Standards Track Cisco Systems + December 2003 + + + IPv6 Prefix Options for + Dynamic Host Configuration Protocol (DHCP) version 6 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + The Prefix Delegation options provide a mechanism for automated + delegation of IPv6 prefixes using the Dynamic Host Configuration + Protocol (DHCP). This mechanism is intended for delegating a long- + lived prefix from a delegating router to a requesting router, across + an administrative boundary, where the delegating router does not + require knowledge about the topology of the links in the network to + which the prefixes will be assigned. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. DHCPv6 specification dependency . . . . . . . . . . . . . . 3 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 + 5. Model and Applicability . . . . . . . . . . . . . . . . . . 3 + 5.1. Example network architecture . . . . . . . . . . . . . 4 + 6. Identity Association for Prefix Delegation . . . . . . . . . 5 + 7. Overview of DHCP with Prefix Delegation . . . . . . . . . . 6 + 8. Interface Selection . . . . . . . . . . . . . . . . . . . . 7 + 9. Identity Association for Prefix Delegation Option . . . . . 7 + 10. IA_PD Prefix option . . . . . . . . . . . . . . . . . . . . 9 + 11. Delegating Router Solicitation . . . . . . . . . . . . . . . 11 + 11.1. Requesting router behavior . . . . . . . . . . . . . . 11 + 11.2. Delegating router behavior . . . . . . . . . . . . . . 11 + 12. Requesting router initiated prefix delegation . . . . . . . 12 + + + +Troan & Droms Standards Track [Page 1] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + + 12.1. Requesting router behavior . . . . . . . . . . . . . . 12 + 12.2. Delegating Router behavior . . . . . . . . . . . . . . 14 + 13. Prefix Delegation reconfiguration . . . . . . . . . . . . . 15 + 13.1. Delegating Router behavior . . . . . . . . . . . . . . 15 + 13.2. Requesting Router behavior . . . . . . . . . . . . . . 15 + 14. Relay agent behavior . . . . . . . . . . . . . . . . . . . . 15 + 15. Security Considerations . . . . . . . . . . . . . . . . . . 16 + 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 + 17. Intellectual Property Statement. . . . . . . . . . . . . . . 17 + 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 18.1. Normative References . . . . . . . . . . . . . . . . . 17 + 18.2. Informative References . . . . . . . . . . . . . . . . 17 + 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 + 20. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 + 21. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 + +1. Introduction + + This document describes new options for Dynamic Host Configuration + Protocol (DHCP) that provide a mechanism for the delegation of IPv6 + prefixes [1]. Through these options, a delegating router can + delegate prefixes to authorized requesting routers. + + The prefix delegation mechanism described in this document is + intended for simple delegation of prefixes from a delegating router + to requesting routers. It is appropriate for situations in which the + delegating router does not have knowledge about the topology of the + networks to which the requesting router is attached, and the + delegating router does not require other information aside from the + identity of the requesting router to choose a prefix for delegation. + For example, these options would be used by a service provider to + assign a prefix to a Customer Premise Equipment (CPE) device acting + as a router between the subscriber's internal network and the service + provider's core network. + + Many applications expect stable addresses. Even though this + mechanism makes automatic renumbering easier, it is expected that + prefixes have a long lifespan. During renumbering it is expected + that the old and the new prefix co-exist for some time. + + The design of this prefix delegation mechanism meets the requirements + for prefix delegation in Requirements for IPv6 prefix delegation [6]. + + Note that this use of DHCP is not bound to the assignment of IP + addresses or other configuration information to hosts, and that no + mechanism is currently available to communicate delegated prefixes to + a DHCP server that serves such a function. This may be an item of + future work, should usage warrant. + + + +Troan & Droms Standards Track [Page 2] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + +2. DHCPv6 specification dependency + + This document describes new DHCPv6 options for IPv6 prefix + delegation. This document should be read in conjunction with the + DHCPv6 specification, RFC 3315 [2], for a complete specification of + the Prefix Delegation options and mechanism. Definitions for terms + and acronyms not specifically defined in this document are defined in + RFC 3315. + +3. Terminology + + This document uses the terminology defined in RFC 2460 [1] and RFC + 3315. In addition, this document uses the following terms: + + requesting router: The router that acts as a DHCP client and is + requesting prefix(es) to be assigned. + + delegating router: The router that acts as a DHCP server, and is + responding to the prefix request. + + Identity Association for Prefix Delegation (IA_PD): A collection of + prefixes assigned to the requesting router. Each + IA_PD has an associated IAID. A requesting + router may have more than one IA_PD assigned to + it; for example, one for each of its interfaces. + +4. Requirements + + The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this + document, are to be interpreted as described in BCP 14, RFC 2119 [3]. + +5. Model and Applicability + + The model of operation for prefix delegation is as follows. A + delegating router is provided IPv6 prefixes to be delegated to + requesting routers. Examples of ways in which the delegating router + may be provided these prefixes are given in Section 12.2. A + requesting router requests prefix(es) from the delegating router, as + described in Section 12.1. The delegating router chooses prefix(es) + for delegation, and responds with prefix(es) to the requesting + router. The requesting router is then responsible for the delegated + prefix(es). For example, the requesting router might assign a subnet + from a delegated prefix to one of its interfaces, and begin sending + router advertisements for the prefix on that link. + + + + + + +Troan & Droms Standards Track [Page 3] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + + Each prefix has an associated valid and preferred lifetime, which + constitutes an agreement about the length of time over which the + requesting router is allowed to use the prefix. A requesting router + can request an extension of the lifetimes on a delegated prefix and + is required to terminate the use of a delegated prefix if the valid + lifetime of the prefix expires. + + This prefix delegation mechanism would be appropriate for use by an + ISP to delegate a prefix to a subscriber, where the delegated prefix + would possibly be subnetted and assigned to the links within the + subscriber's network. + +5.1. Example network architecture + + Figure 1 illustrates a network architecture in which prefix + delegation could be used. + + ______________________ \ + / \ \ + | ISP core network | \ + \__________ ___________/ | + | | + +-------+-------+ | + | Aggregation | | ISP + | device | | network + | (delegating | | + | router) | | + +-------+-------+ | + | / + |DSL to subscriber / + |premises / + | + +------+------+ \ + | CPE | \ + | (requesting | \ + | router) | | + +----+---+----+ | + | | | Subscriber + ---+-------------+-----+- -+-----+-------------+--- | network + | | | | | ++----+-----+ +-----+----+ +----+-----+ +-----+----+ | +|Subscriber| |Subscriber| |Subscriber| |Subscriber| / +| PC | | PC | | PC | | PC | / ++----------+ +----------+ +----------+ +----------+ / + + Figure 1: An example of prefix delegation. + + + + + +Troan & Droms Standards Track [Page 4] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + + In this example, the delegating router is configured with a set of + prefixes to be used for assignment to customers at the time of each + customer's first connection to the ISP service. The prefix + delegation process begins when the requesting router requests + configuration information through DHCP. The DHCP messages from the + requesting router are received by the delegating router in the + aggregation device. When the delegating router receives the request, + it selects an available prefix or prefixes for delegation to the + requesting router. The delegating router then returns the prefix or + prefixes to the requesting router. + + The requesting router subnets the delegated prefix and assigns the + longer prefixes to links in the subscriber's network. In a typical + scenario based on the network shown in Figure 1, the requesting + router subnets a single delegated /48 prefix into /64 prefixes and + assigns one /64 prefix to each of the links in the subscriber + network. + + The prefix delegation options can be used in conjunction with other + DHCP options carrying other configuration information to the + requesting router. The requesting router may, in turn, then provide + DHCP service to hosts attached to the internal network. For example, + the requesting router may obtain the addresses of DNS and NTP servers + from the ISP delegating router, and then pass that configuration + information on to the subscriber hosts through a DHCP server in the + requesting router. + +6. Identity Association for Prefix Delegation + + An IA_PD is a construct through which a delegating router and a + requesting router can identify, group and manage a set of related + IPv6 prefixes. Each IA_PD consists of an IAID and associated + configuration information. An IA_PD for prefixes is the equivalent + of an IA (described in RFC 3315) for addresses. + + An IA_PD is different from an IA, in that it does not need to be + associated with exactly one interface. One IA_PD can be associated + with the requesting router, with a set of interfaces or with exactly + one interface. A requesting router must create at least one distinct + IA_PD. It may associate a distinct IA_PD with each of its downstream + network interfaces and use that IA_PD to obtain a prefix for that + interface from the delegating router. + + The IAID uniquely identifies the IA_PD and must be chosen to be + unique among the IA_PD IAIDs on the requesting router. The IAID is + chosen by the requesting router. For any given use of an IA_PD by + the requesting router, the IAID for that IA_PD MUST be consistent + across restarts of the requesting router. The requesting router may + + + +Troan & Droms Standards Track [Page 5] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + + maintain consistency either by storing the IAID in non-volatile + storage or by using an algorithm that will consistently produce the + same IAID as long as the configuration of the requesting router has + not changed. If the requesting router uses only one IAID, it can use + a well-known value, e.g., zero. + + The configuration information in an IA_PD consists of one or more + IPv6 prefixes along with the times T1 and T2 for the IA_PD. See + section 9 for the representation of an IA_PD in a DHCP message. + +7. Overview of DHCP with Prefix Delegation + + Prefix delegation with DHCP is independent of address assignment with + DHCP. A requesting router can use DHCP for just prefix delegation or + for prefix delegation along with address assignment and other + configuration information. + + A requesting router first creates an IA_PD and assigns it an IAID. + The requesting router then transmits a Solicit message containing an + IA_PD option describing the IA_PD. Delegating routers that can + delegate prefixes to the IA_PD respond to the requesting router with + an Advertise message. + + The requesting router may include prefixes in the IA_PDs as a hint to + the delegating router about specific prefixes for which the + requesting router has a preference. + + When the requesting router has identified a delegating router, the + requesting router uses a Request message to populate the IA_PDs with + prefixes. The requesting router includes one or more IA_PD options + in the Request message. The delegating router returns prefixes and + other information about the IA_PDs to the requesting router in IA_PD + options in a Reply message. The requesting router records the + lifetimes for the delegated prefix(es) and uses the prefix(es) as + described in the previous section. + + Before the valid lifetime on each delegated prefix expires, the + requesting router includes the prefix in an IA_PD option sent in a + Renew message to the delegating router. The delegating router + responds by returning the prefix with updated lifetimes to the + requesting router. + + + + + + + + + + +Troan & Droms Standards Track [Page 6] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + +8. Interface Selection + + Delegated prefixes are not associated with a particular interface in + the same way as addresses are for address assignment, and the rules + described in section 16, "Client Source Address and Interface + Selection" of RFC 3315 do not apply. + + When a requesting router sends a DHCP message, it SHOULD be sent on + the interface associated with the upstream router (ISP network). The + upstream interface is typically determined by configuration. This + rule applies even in the case where a separate IA_PD is used for each + downstream interface. + + When a requesting router sends a DHCP message directly to a + delegating router using unicast (after receiving the Server Unicast + option from that delegating router), the source address SHOULD be an + address from the upstream interface and which is suitable for use by + the delegating router in responding to the requesting router. + +9. Identity Association for Prefix Delegation Option + + The IA_PD option is used to carry a prefix delegation identity + association, the parameters associated with the IA_PD and the + prefixes associated with it. + + The format of the IA_PD option is: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OPTION_IA_PD | option-length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IAID (4 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | T1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | T2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . + . IA_PD-options . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + option-code: OPTION_IA_PD (25) + + option-length: 12 + length of IA_PD-options field. + + + + + +Troan & Droms Standards Track [Page 7] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + + IAID: The unique identifier for this IA_PD; the IAID must + be unique among the identifiers for all of this + requesting router's IA_PDs. + + T1: The time at which the requesting router should + contact the delegating router from which the + prefixes in the IA_PD were obtained to extend the + lifetimes of the prefixes delegated to the IA_PD; + T1 is a time duration relative to the current time + expressed in units of seconds. + + T2: The time at which the requesting router should + contact any available delegating router to extend + the lifetimes of the prefixes assigned to the + IA_PD; T2 is a time duration relative to the + current time expressed in units of seconds. + + IA_PD-options: Options associated with this IA_PD. + + The IA_PD-options field encapsulates those options that are specific + to this IA_PD. For example, all of the IA_PD Prefix Options carrying + the prefixes associated with this IA_PD are in the IA_PD-options + field. + + An IA_PD option may only appear in the options area of a DHCP + message. A DHCP message may contain multiple IA_PD options. + + The status of any operations involving this IA_PD is indicated in a + Status Code option in the IA_PD-options field. + + Note that an IA_PD has no explicit "lifetime" or "lease length" of + its own. When the valid lifetimes of all of the prefixes in a IA_PD + have expired, the IA_PD can be considered as having expired. T1 and + T2 are included to give delegating routers explicit control over when + a requesting router should contact the delegating router about a + specific IA_PD. + + In a message sent by a requesting router to a delegating router, + values in the T1 and T2 fields indicate the requesting router's + preference for those parameters. The requesting router sets T1 and + T2 to zero if it has no preference for those values. In a message + sent by a delegating router to a requesting router, the requesting + router MUST use the values in the T1 and T2 fields for the T1 and T2 + parameters. The values in the T1 and T2 fields are the number of + seconds until T1 and T2. + + The delegating router selects the T1 and T2 times to allow the + requesting router to extend the lifetimes of any prefixes in the + + + +Troan & Droms Standards Track [Page 8] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + + IA_PD before the lifetimes expire, even if the delegating router is + unavailable for some short period of time. Recommended values for T1 + and T2 are .5 and .8 times the shortest preferred lifetime of the + prefixes in the IA_PD that the delegating router is willing to + extend, respectively. If the time at which the prefixes in an IA_PD + are to be renewed is to be left to the discretion of the requesting + router, the delegating router sets T1 and T2 to 0. + + If a delegating router receives an IA_PD with T1 greater than T2, and + both T1 and T2 are greater than 0, the delegating router ignores the + invalid values of T1 and T2 and processes the IA_PD as though the + delegating router had set T1 and T2 to 0. + + If a requesting router receives an IA_PD with T1 greater than T2, and + both T1 and T2 are greater than 0, the client discards the IA_PD + option and processes the remainder of the message as though the + delegating router had not included the IA_PD option. + +10. IA_PD Prefix option + + The IA_PD Prefix option is used to specify IPv6 address prefixes + associated with an IA_PD. The IA_PD Prefix option must be + encapsulated in the IA_PD-options field of an IA_PD option. + + The format of the IA_PD Prefix option is: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OPTION_IAPREFIX | option-length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | preferred-lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | valid-lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | prefix-length | | + +-+-+-+-+-+-+-+-+ IPv6 prefix | + | (16 octets) | + | | + | | + | | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . + +-+-+-+-+-+-+-+-+ . + . IAprefix-options . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Troan & Droms Standards Track [Page 9] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + + option-code: OPTION_IAPREFIX (26) + + option-length: 25 + length of IAprefix-options field + + preferred-lifetime: The recommended preferred lifetime for the IPv6 + prefix in the option, expressed in units of + seconds. A value of 0xFFFFFFFF represents + infinity. + + valid-lifetime: The valid lifetime for the IPv6 prefix in the + option, expressed in units of seconds. A value of + 0xFFFFFFFF represents infinity. + + prefix-length: Length for this prefix in bits + + IPv6-prefix: An IPv6 prefix + + IAprefix-options: Options associated with this prefix + + In a message sent by a requesting router to a delegating router, the + values in the fields can be used to indicate the requesting router's + preference for those values. The requesting router may send a value + of zero to indicate no preference. A requesting router may set the + IPv6 prefix field to zero and a given value in the prefix-length + field to indicate a preference for the size of the prefix to be + delegated. + + In a message sent by a delegating router the preferred and valid + lifetimes should be set to the values of AdvPreferredLifetime and + AdvValidLifetime as specified in section 6.2.1, "Router Configuration + Variables" of RFC 2461 [4], unless administratively configured. + + A requesting router discards any prefixes for which the preferred + lifetime is greater than the valid lifetime. A delegating router + ignores the lifetimes set by the requesting router if the preferred + lifetime is greater than the valid lifetime and ignores the values + for T1 and T2 set by the requesting router if those values are + greater than the preferred lifetime. + + The values in the preferred and valid lifetimes are the number of + seconds remaining for each lifetime. + + An IA_PD Prefix option may appear only in an IA_PD option. More than + one IA_PD Prefix Option can appear in a single IA_PD option. + + The status of any operations involving this IA_PD Prefix option is + indicated in a Status Code option in the IAprefix-options field. + + + + +Troan & Droms Standards Track [Page 10] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + +11. Delegating Router Solicitation + + The requesting router locates and selects a delegating router in the + same way as described in section 17, "DHCP Server Solicitation" of + RFC 3315. The details of the solicitation process are described in + this section. + +11.1. Requesting router behavior + + The requesting router creates and transmits a Solicit message as + described in sections 17.1.1, "Creation of Solicit Messages" and + 17.1.2, "Transmission of Solicit Messages" of RFC 3315. The + requesting router creates an IA_PD and assigns it an IAID. The + requesting router MUST include the IA_PD option in the Solicit + message. + + The requesting router processes any received Advertise messages as + described in section 17.1.3, "Receipt of Advertise Messages" of RFC + 3315. The requesting router MAY choose to consider the presence of + advertised prefixes in its decision about which delegating router to + respond to. + + The requesting router MUST ignore any Advertise message that includes + a Status Code option containing the value NoPrefixAvail, with the + exception that the requesting router MAY display the associated + status message to the user. + +11.2. Delegating router behavior + + The delegating router sends an Advertise message to the requesting + router in the same way as described in section 17.2.2, "Creation and + transmission of Advertise messages" of RFC 3315. If the message + contains an IA_PD option and the delegating router is configured to + delegate prefix(es) to the requesting router, the delegating router + selects the prefix(es) to be delegated to the requesting router. The + mechanism through which the delegating router selects prefix(es) for + delegation is not specified in this document. Examples of ways in + which the delegating router might select prefix(es) for a requesting + router include: static assignment based on subscription to an ISP; + dynamic assignment from a pool of available prefixes; selection based + on an external authority such as a RADIUS server using the Framed- + IPv6-Prefix option as described in RFC 3162 [5]. + + If the requesting router includes an IA_PD Prefix option in the IA_PD + option in its Solicit message, the delegating router MAY choose to + use the information in that option to select the prefix(es) or prefix + size to be delegated to the requesting router. + + + + +Troan & Droms Standards Track [Page 11] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + + The delegating router sends an Advertise message to the requesting + router in the same way as described in section, "Creation and + transmission of Advertise messages" of RFC 3315. The delegating + router MUST include an IA_PD option, identifying any prefix(es) that + the delegating router will delegate to the requesting router. + + If the delegating router will not assign any prefixes to any IA_PDs + in a subsequent Request from the requesting router, the delegating + router MUST send an Advertise message to the requesting router that + includes the IA_PD with no prefixes in the IA_PD and a Status Code + option in the IA_PD containing status code NoPrefixAvail and a status + message for the user, a Server Identifier option with the delegating + router's DUID and a Client Identifier option with the requesting + router's DUID. + +12. Requesting router initiated prefix delegation + + A requesting router uses the same message exchanges as described in + section 18, "DHCP Client-Initiated Configuration Exchange" of RFC + 3315 to obtain or update prefix(es) from a delegating router. The + requesting router and the delegating router use the IA_PD Prefix + option to exchange information about prefix(es) in much the same way + IA Address options are used for assigned addresses. + +12.1. Requesting router behavior + + The requesting router uses a Request message to populate IA_PDs with + prefixes. The requesting router includes one or more IA_PD options + in the Request message. The delegating router then returns the + prefixes for the IA_PDs to the requesting router in IA_PD options in + a Reply message. + + The requesting router includes IA_PD options in any Renew, or Rebind + messages sent by the requesting router. The IA_PD option includes + all of the prefixes the requesting router currently has associated + with that IA_PD. + + In some circumstances the requesting router may need verification + that the delegating router still has a valid binding for the + requesting router. Examples of times when a requesting router may + ask for such verification include: + + o The requesting router reboots. + + o The requesting router's upstream link flaps. + + o The requesting router is physically disconnected from a wired + connection. + + + +Troan & Droms Standards Track [Page 12] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + + If such verification is needed the requesting router MUST initiate a + Rebind/Reply message exchange as described in section 18.1.4, + "Creation and Transmission of Rebind Messages" of RFC 3315, with the + exception that the retransmission parameters should be set as for the + Confirm message, described in section 18.1.2, "Creation and + Transmission of Confirm Messages" of RFC 3315. The requesting router + includes any IA_PDs, along with prefixes associated with those IA_PDs + in its Rebind message. + + Each prefix has valid and preferred lifetimes whose durations are + specified in the IA_PD Prefix option for that prefix. The requesting + router uses Renew and Rebind messages to request the extension of the + lifetimes of a delegated prefix. + + The requesting router uses a Release message to return a delegated + prefix to a delegating router. The prefixes to be released MUST be + included in the IA_PDs. + + The Confirm and Decline message types are not used with Prefix + Delegation. + + Upon the receipt of a valid Reply message, for each IA_PD the + requesting router assigns a subnet from each of the delegated + prefixes to each of the links to which the associated interfaces are + attached, with the following exception: the requesting router MUST + NOT assign any delegated prefixes or subnets from the delegated + prefix(es) to the link through which it received the DHCP message + from the delegating router. + + When a requesting router subnets a delegated prefix, it must assign + additional bits to the prefix to generate unique, longer prefixes. + For example, if the requesting router in Figure 1 were delegated + 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and + 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber + network. If the requesting router were delegated 3FFE:FFFF:0::/48 + and 3FFE:FFFF:5::/48, it might assign 3FFE:FFFF:0:1::/64 and + 3FFE:FFFF:5:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and + 3FFE:FFFF:5:2::/64 for assignment to the other link. + + If the requesting router assigns a delegated prefix to a link to + which the router is attached, and begins to send router + advertisements for the prefix on the link, the requesting router MUST + set the valid lifetime in those advertisements to be no later than + the valid lifetime specified in the IA_PD Prefix option. A + requesting router MAY use the preferred lifetime specified in the + IA_PD Prefix option. + + + + + +Troan & Droms Standards Track [Page 13] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + + Handling of Status Codes options in received Reply messages is + described in section 18.1.8, "Receipt of Reply Messages" of RFC 3315. + The NoPrefixAvail Status Code is handled in the same manner as the + NoAddrsAvail Status Code. + +12.2. Delegating Router behavior + + When a delegating router receives a Request message from a requesting + router that contains an IA_PD option, and the delegating router is + authorized to delegate prefix(es) to the requesting router, the + delegating router selects the prefix(es) to be delegated to the + requesting router. The mechanism through which the delegating router + selects prefix(es) for delegation is not specified in this document. + Section 11.2 gives examples of ways in which a delegating router + might select the prefix(es) to be delegated to a requesting router. + + A delegating router examines the prefix(es) identified in IA_PD + Prefix options (in an IA_PD option) in Renew and Rebind messages and + responds according to the current status of the prefix(es). The + delegating router returns IA_PD Prefix options (within an IA_PD + option) with updated lifetimes for each valid prefix in the message + from the requesting router. If the delegating router finds that any + of the prefixes are not in the requesting router's binding entry, the + delegating router returns the prefix to the requesting router with + lifetimes of 0. + + The delegating router behaves as follows when it cannot find a + binding for the requesting router's IA_PD: + + Renew message: If the delegating router cannot find a binding + for the requesting router's IA_PD the delegating + router returns the IA_PD containing no prefixes + with a Status Code option set to NoBinding in the + Reply message. + + Rebind message: If the delegating router cannot find a binding + for the requesting router's IA_PD and the + delegating router determines that the prefixes in + the IA_PD are not appropriate for the link to + which the requesting router's interface is + attached according to the delegating routers + explicit configuration, the delegating router MAY + send a Reply message to the requesting router + containing the IA_PD with the lifetimes of the + prefixes in the IA_PD set to zero. This Reply + constitutes an explicit notification to the + requesting router that the prefixes in the IA_PD + are no longer valid. If the delegating router is + + + +Troan & Droms Standards Track [Page 14] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + + unable to determine if the prefix is not + appropriate for the link, the Rebind message is + discarded. + + A delegating router may mark any prefix(es) in IA_PD Prefix options + in a Release message from a requesting router as "available", + dependent on the mechanism used to acquire the prefix, e.g., in the + case of a dynamic pool. + + The delegating router MUST include an IA_PD Prefix option or options + (in an IA_PD option) in Reply messages sent to a requesting router. + +13. Prefix Delegation reconfiguration + + This section describes prefix delegation in Reconfigure message + exchanges. + +13.1. Delegating Router behavior + + The delegating router initiates a configuration message exchange with + a requesting router, as described in section 19, "DHCP Server- + Initiated Configuration Exchange" of RFC 3315, by sending a + Reconfigure message (acting as a DHCP server) to the requesting + router, as described in section 19.1, "Server Behavior" of RFC 3315. + The delegating router specifies the IA_PD option in the Option + Request option to cause the requesting router to include an IA_PD + option to obtain new information about delegated prefix(es). + +13.2. Requesting Router behavior + + The requesting router responds to a Reconfigure message, acting as a + DHCP client, received from a delegating router as described in + section 19.4, "Client Behavior" of RFC 3315. The requesting router + MUST include the IA_PD Prefix option(s) (in an IA_PD option) for + prefix(es) that have been delegated to the requesting router by the + delegating router from which the Reconfigure message was received. + +14. Relay agent behavior + + A relay agent forwards messages containing Prefix Delegation options + in the same way as described in section 20, "Relay Agent Behavior" of + RFC 3315. + + If a delegating router communicates with a requesting router through + a relay agent, the delegating router may need a protocol or other + out-of-band communication to add routing information for delegated + prefixes into the provider edge router. + + + + +Troan & Droms Standards Track [Page 15] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + +15. Security Considerations + + Security considerations in DHCP are described in section 23, + "Security Considerations" of RFC 3315. + + A rogue delegating router can issue bogus prefixes to a requesting + router. This may cause denial of service due to unreachability. + + A malicious requesting router may be able to mount a denial of + service attack by repeated requests for delegated prefixes that + exhaust the delegating router's available prefixes. + + To guard against attacks through prefix delegation, requesting + routers and delegating routers SHOULD use DHCP authentication as + described in section 21, "Authentication of DHCP messages" of RFC + 3315. For point to point links, where one trusts that there is no + man in the middle, or one trusts layer two authentication, DHCP + authentication or IPsec may not be necessary. Because a requesting + router and delegating routers must each have at least one assigned + IPv6 address, the routers may be able to use IPsec for authentication + of DHCPv6 messages. The details of using IPsec for DHCPv6 are under + development. + + Networks configured with delegated prefixes should be configured to + preclude intentional or inadvertent inappropriate advertisement of + these prefixes. + +16. IANA Considerations + + IANA has assigned option codes to: + + OPTION_IA_PD (25) + + OPTION_IAPREFIX (26) + + from the option-code space as defined in section 24.3, "DHCP Options" + of RFC 3315. + + IANA has assigned status code 6 to: + + NoPrefixAvail: Delegating router has no prefixes available to + assign to the IAPD(s) + + from the status-code space as defined in section 24.4, "Status Codes" + of RFC 3315. + + + + + + +Troan & Droms Standards Track [Page 16] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + +17. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +18. References + +18.1. Normative References + + [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. + Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", + RFC 3315, July 2003. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for + IP Version 6 (IPv6)", RFC 2461, December 1998. + + [5] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, + August 2001. + +18.2. Informative References + + [6] Miyakawa, S. and R. Droms, "Requirements for IPv6 prefix + delegation", Work in Progress, August 2003. + + + + + +Troan & Droms Standards Track [Page 17] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + +19. Acknowledgements + + Thanks for the input and review by (in alphabetical order) Steve + Deering, Dave Forster, Brian Haberman, Tatuya Jinmei, Shin Miyakawa, + Pekka Savola, Bernie Volz, Trevor Warwick and Toshi Yamasaki. + +20. Authors' Addresses + + Ole Troan + Cisco Systems + 250 Longwater Avenue + Reading RG2 6GB + United Kingdom + + Phone: +44 20 8824 8666 + EMail: ot@cisco.com + + + Ralph Droms + Cisco Systems + 1414 Massachusetts Avenue + Boxborough, MA 01719 + USA + + Phone: +1 978 936 1674 + EMail: rdroms@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + +Troan & Droms Standards Track [Page 18] + +RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003 + + +21. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Troan & Droms Standards Track [Page 19] + |