GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3633

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3633.txt · Last modified: 2003/12/11 01:27 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki