Prefix Pool Option for DHCPv6 Relay Agent
draft-yeh-dhc-dhcpv6-prefix-pool-opt-00

Abstract

The Prefix Pool option provides an automatic mechanism for the information exchange between DHCPv6 server and DHCPv6 Relay Agent. The information about Prefix Pools maintained on DHCPv6 server can be transferred from server to relay agent through this DHCPv6 option to support the necessary route aggregation on the provide edge router, which has a huge number of routes pointing to the customer networks before the aggregation.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on April 16, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Terminology and Language
3.  Scenario and Network architecture
4.  Prefix Pool option
5.  Relay Agent Behavior
6.  Server Behavior
7.  Security Considerations
8.  IANA Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Authors' Addresses

1.  Introduction

DHCPv6 Relay Agents [RFC3315] (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) are deployed to relay messages between clients and servers when they are not on the same link, and are often implemented alongside a routing function in the provider edge (PE) routers [BBF WT‑177] (Broadband Forum, “IPv6 in the context of TR-101, Rev.16, Straw Ballot,” September 2010.). Meanwhile, DHCPv6 Prefix Delegation [RFC3633] (Troan, O. and R. Droms, “IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6,” December 2003.) provides a mechanism for the automated delegation of IPv6 prefix to the customer network.

In order to make the customer network to be reachable in the IPv6 network, the PE routers always need to add or remove the route entry directing to each customer network in its routing table per the relay-forward or relay-reply message between DHCPv6 Server (Delegation Router) and Customer router (CPE, DHCPv6 Client, DHCPv6 Requesting Router) when the PE router acts as DHCPv6 Relay Agent [BBF WT‑177] (Broadband Forum, “IPv6 in the context of TR-101, Rev.16, Straw Ballot,” September 2010.).

When the routing protocol is enabled on the network-facing interface of the PE router, all the routes directing to the customer networks are supposed to advertise in the ISP core network. This will make the number of entries in the routing table on the ISP core router to be an unacceptable huge one, so that it is necessary to aggregate the routes directing to the customer networks on the PE router.

Because the prefixes of the customer networks can not guarantee always to be valid and continuous, the routing protocol on the PE router can not make one aggregation route automatically to cover all the prefixes delegated to the customer networks, which are associated to the same client-facing link of the PE. On the other hand, the information of the prefix pools associated to each client-facing interface of PEs is always maintained on the DHCPv6 server. When the PE router acts as the DHCPv6 Server, the aggregation route can be generated by this information directly, but when the PE router acts as the DHCPv6 Relay Agent, a new mechanism to transfer the information of the prefix pools from the server to the relay agent for each client-facing interface of the PE is requested.

After the PE got the information of the prefix pools associated to its client-facing interfaces, the black-hole route entry pointing to each of these prefix pools can be added in the routing table of PE. When the routing protocol is enabled on PE's network-facing interface, the above black-hole route will be advertised to the whole ISP network as the aggregation route pointing to all of the customer networks attached on the same link of the PE's client-facing interface.

2.  Terminology and Language

This document describes new DHCPv6 options of prefix pool and the associated mechanism for the configuration on the Relay Agent. This document should be read in conjunction with the DHCPv6 specification, RFC 3315 and RFC 3633, for a complete mechanism. Definitions for terms and acronyms not specifically defined in this document are defined in RFC 3315, RFC 3633 and RFC 3769 [RFC3769] (Miyakawa, S. and R. Droms, “Requirements for IPv6 Prefix Delegation,” June 2004.).

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Scenario and Network architecture

The following figure illustrates a typical ISP-Customer network architecture.

              +------+------+
              |    DHCPv6   |  DHCPv6-PD Delegating Router
              |    Server   |
              +------+------+
            _________|_________
           /                   \
          |  ISP Core Network   |
           \___________________/
                     |
                     |  Network-facing interface
              +------+------+
              |      PE     |  Provider Edge Router
              |             |  DHCPv6 Relay Agent
              +------+------+
                     |  Client-facing interface (Interface ID)
            _________|_________
           /                   \
          |   Access Network    |
           \___________________/
                     |
              +------+------+  Customer Router
              |      CPE    |  DHCPv6 Client
              |             |  DHCPv6-PD Requesting Router
              +------+------+
            _________|_________
           /                   \
          |  Customer Network   |
           \___________________/

4.  Prefix Pool option

The format of the Prefix Pool 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_PREFIX_POOL     |           option-length       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  pfx-pool-len |                                               |
+-+-+-+-+-+-+-+-+           IPv6 prefix                         +
|                           (16 octets)                         |
|                                                               |
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |     Status    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code:    OPTION_PREFIX_POOL (TBD)
option-length:  18
pfx-pool-len:   Length for this prefix-pool in bits
IPv6 prefix:    An IPv6 prefix of prefix pool
Status:         Status of the prefix pool

The Status field in the Prefix Pool option indicates the availability of the prefix pool maintained on the Server. The code of the Status is defined in the following table.

Name      Code
Valid     0
Released  1
Reserved  2~255

5.  Relay Agent Behavior

The Relay Agent who needs the information from the Server£¬shall includes Option Request Option (OPTION_ORO, 6) to request Prefix Pool option from the Server, which contains the information about the prefix pool that will be configured on the associated client-facing interface of the Relay agent. The Relay Agent may include this ORO in the relay-forward (12) message of SOLICIT (1), REQUEST (3), RENEW (5) or REBIND (6).

The Relay Agent should includes Interface-ID Option (OPTION_INTERFACE_ID, 18) for the server to identify the associated interface on which the prefix pool is configured, if the Server would not like to use link-address specified in the DHCPv6 message encapsulation of relay-forward message to identify the interface of the link on which the client is located.

The Relay Agent shall advertise the aggregation route based on the information of prefix pool when the routing protocol is enabled on its network-facing interface.

6.  Server Behavior

The Server must include Prefix Pool option in the relay-reply (13) message of REPLY (7) after it receives the relay-forward message, which is included an associated ORO.

The Server shall use the Interface-ID included by the Relay Agent to identify the client-facing interface of the Relay Agent on which the associated prefix pool is configured.

When multiple Prefix Pools are associated to the same client-facing interface of the Relay Agent, the server must include multiple Prefix Pool options in the same relay-reply message.

The Server shall include Prefix Pool option when it initiates the relay-reply message of RECONFIGURE (10). The Status of 'Valid' for the Prefix Pool option can be used to set up the Prefix Pool on the Relay Agent; the Status of 'Released' for the Prefix Pool option can be used to release the configuration of the Prefix Pool on the Relay Agent.

7.  Security Considerations

Security issues related DHCPv6 are described in section 23 of RFC 3315.

8.  IANA Considerations

IANA is requested to assign an option code to Option_Prefix_Pool from the "DHCPv6 and DHCPv6 options" registry (http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml).

9.  References

9.1. Normative References

9.2. Informative References

Authors' Addresses