ipv6: initial dhcpv6 support

1 files changed, 1067 insertions, 0 deletions

diff --git a/rfc/rfc3633.txt b/rfc/rfc3633.txt
new file mode 100644
index 0000000..b262855
--- /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]
+