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

Abstract

The Prefix Pool option provides an automatic mechanism for the messages 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.

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 September 08, 2011.

Copyright Notice

Copyright (c) 2011 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. Acknowledgements
• 10. Changes Log
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Authors' Addresses

1. Introduction

The DHCPv6 [RFC3315] protocol specifies a mechanism for the assignment of IPv6 address and configuration information to IPv6 nodes. IPv6 Prefix Delegation (PD) of DHCPv6 [RFC3633] specifies a mechanism for the delegation of IPv6 prefixes and configuration information to the Requesting Router (DHCPv6 Client). The DHCPv6 servers (Delegating Router) always maintain authoritative information related to their operations including, but not limited to, binding data of the delegated IPv6 prefixes, lease data of the delegated IPv6 prefixes, and binding data of their prefix pools.

The provider edge (PE) routers can act as a DHCPv6 relay agents when the DHCPv6 Server (Delegating Router) and the DHCPv6 Client (Requesting Router) are not on the same link. 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 messages between DHCPv6 Server (Delegation Router) and Customer router (CPE, DHCPv6 Client, DHCPv6 Requesting Router) relayed by the PE (Section 6.2, [BBF TR-177]).

When the routing protocol is enabled on the network-facing interface of the PE router, all the routes directing to the customer networks are advertised in the ISP core network. This will make the number of entries in the routing table on the ISP core router to be unacceptable huge, 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. The PE router (Relay) here requires a new mean to transfer the information of the prefix pools from the server to the relay agent. This document will address a new Prefix Pool option for this purpose. After the PE got the information of prefix pools, the aggregation route entries (eg. black-hole routes) pointing to each of the prefix pools can be added or withdrawn in the routing table of PE. The aggregation routes will then be advertised to the whole ISP network through the routing protocol enabled on the PE's network-facing interface.

The DHCPv6 Bulk Leasequery [RFC5460] protocol specifies a mechanism for bulk transfer of the binding data of each delegated prefix from the server to the Requestor (DHCPv6 Relay), to support the replacement or reboot event of Relay. In this document, the capability of DHCPv6 Bulk Leasequery will be extended to support the bulk transfer of the binding data of prefix pool for the route aggregation.

2. Terminology and Language

This document describes new DHCPv6 options of prefix pool and the associated mechanism on the relay agent and server. This document should be read in conjunction with the DHCPv6 specification, RFC3315, RFC3633, RFC5007 and RFC5460 for a complete mechanism. Definitions for terms and acronyms not specifically defined in this document are defined in RFC3315, RFC3633, [RFC3769], [RFC5007] and RFC5460.

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, [RFC2119].

3. Scenario and Network architecture

The following figures illustrates some typical cases of ISP-Customer network architectures.

          +------+------+
          |    DHCPv6   |  DHCPv6-PD Delegating Router
          |    Server   |  (eg. binding entry: 
          +------+------+       pe#1 - 3ffe:ffff:1200::/40 
        _________|_________     extract pe_id=pe#1
       /                   \    from the interface_id=pe#1_cfi#2)
      |  ISP Core Network   |
       \___________________/
                 |
                 |  Network-facing interface
          +------+------+
          |             |  Provider Edge Router
          |     PE      |  DHCPv6 Relay Agent
          |             |  (eg. pe_id=pe#1;
          +------+------+       prefix pool=3ffe:ffff:1200::/40)
                 |  Client-facing interface (Interface ID)  
                 |  (eg. interface_id=pe#1_cfi#2)
                 |
          +------+------+  Customer Router
          |     CPE     |  DHCPv6 Client
          |             |  DHCPv6-PD Requesting Router
          +------+------+  (eg. customer network
                 |              =3ffe:ffff:1234:5600:/56)
        _________|_________
       /                   \
      |  Customer Network   |
       \___________________/	  	  
	  

          +------+------+
          |    DHCPv6   |  DHCPv6-PD Delegating Router
          |    Server   |  (eg. binding entry: 
          +------+------+       pe#1_cfi#2 - 3ffe:ffff:1200::/40)
        _________|_________
       /                   \
      |  ISP Core Network   |
       \___________________/
                 |
                 |  Network-facing interface
          +------+------+
          |      PE     |  Provider Edge Router
          |             |  DHCPv6 Relay Agent
          +------+------+
                 |  Client-facing interface (Interface ID)
                 |  (eg. interface_id=pe#1_cfi#2; 
                 |       prefix pool=3ffe:ffff:1200::/40)
        _________|_________
       /                   \
      |   Access Network    |
       \___________________/
                 |
          +------+------+  Customer Router
          |     CPE     |  DHCPv6 Client
          |             |  DHCPv6-PD Requesting Router
          +------+------+  (eg. customer network
                 |              =3ffe:ffff:1234:5600::/56)
        _________|_________
       /                   \
      |  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 the prefix pool in bits
ipv6-prefix:    IPv6 prefix of the 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

The status of 'Valid' in the Prefix Pool option can be used to add the prefix pool and the associated aggregation route on the relay agent; while the status of 'Released' in the Prefix Pool option can be used to withdraw the prefix pool and the associated aggregation route on the relay agent.

If the administrative policy on the server permit and support the route aggregation on the relay agent, the status of prefix pool can be determined by the delegated prefixes within the associated prefix pool. If there is one delegated prefix within the pool that has valid lease, the status of prefix pool will be 'Valid'. Otherwise, the status of prefix pool is 'Released'. If the administrative policy on the server don't permit or support the route aggregation on the relay agent, the status of prefix pool will always be 'Released'.

5. Relay Agent Behavior

The relay agent who needs the information of prefix pools, must includes Option Request option (OPTION_ORO, 6) to request Prefix Pool option from the server, who maintains the status of the prefix pools associated to the relay agent itself (Figure 1) or its particular client-facing interface (Figure 2) where receiving the DHCPv6-PD message from clients. The relay agent can include this ORO for Prefix Pool option in the relay-forward (12) message of SOLICIT (1), REQUEST (3), RENEW(5), REBIND (6) and RELEASE (8). The relay agent may also include Prefix Pool option with the field values of pfx-pool-len and IPv6-prefix as its preference which the relay agent would like the server return.

The relay agent should include Interface ID option (OPTION_INTERFACE_ID, 18) for the server to identify the relay agent itself or its particular client-facing interface where the prefix pool is associated, 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 clients are located.

After received the Prefix Pool option for the relay agent itself or its particular client-facing interface in the relay-reply message (13) of REPLY (7) from the server, the relay agent shall add or remove the aggregation route entry per the status of the prefix pool. If the status of the prefix pool got from the server is 'Valid', the relay agent shall add an aggregation route entry in its routing table, if the same entry has not been added in. If the status of the prefix pool got from the server is 'Released', the relay agent shall withdraw the associated aggregation route entry in its routing table, if the same entry has not been removed. If there is no route entry directing to the customer network within the associated aggragation route, the relay agent can automatically withdraw the aggregation route.

The relay agent advertises its routing table including the entries of the aggregation routes based on the information of prefix pools when the routing protocol is enabled on its network-facing interface.

The Relay Agent (Requestor) can use DHCPv6 Bulk Leasequery [RFC5460] protocol to query the binding data of prefix pools in the 'Valid' status from the server. After established a TCP connection with the DHCPv6 server, the relay agent must include Query option (OPTION_LQ_QUERY, 44) and set the proper query-type (QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, QUERY_BY_REMOTE_ID), link-address and query-options in the LEASEQUERY (14) message. The query options must include Option Request option (OPTION_ORO, 6) to request Prefix Pool option from the server.

6. Server Behavior

Per RFC3633, if the prefix of the customer network requested in relay-forward message of SOLICIT , REQUEST, RENEW, REBIND by the Client (requesting router) has valid lease, the Server (delegating router) will delegate the prefix with the relevant parameters in the relay-reply message of REPLY. In order to give a meaningful reply, the server has to be able to maintains the binding data of the delegated IPv6 prefixes with the identification of the client. When Interface ID (OPTION_INTERFACE_ID, 18) included or nested in the relay-forward message is used to identify the client, it can support both of the typical use cases (Figure 1 and Figure 2) discussed in section 3.

After received the ORO (OPTION_ORO, 6) to request Prefix Pool option in the relay-forward message of PD, the server must include Prefix Pool option with the status indicated for the associated relay agent itself (Figure 1) or its client-facing interface (Figure 2) in the relay-reply message of PD if the relay-forward message of PD received is valid per RFC3633.

The server may use the link-address specified in relay-forward message to identify the relay agent itself or its particular client-facing interface where the prefix pool is associated, but the server has to maintain the binding data of prefix pools in association with these link-addresses. To be more readable, the server can alternatively use the Interface ID (OPTION_INTERFACE_ID, 18) included in the relay-forward message by the relay agent, to identify the relay agent itself (Figure 1) or its particular client-facing interface (Figure 2) where the prefix pool is associated. In order to give a meaningful reply, the server has to maintain the binding data of prefix pools in association with the Interface ID.

Per RFC3315, the server shall copy the same Interface ID option got from the relay-forward message into the relay-reply message.

If the server is set to support the route aggregation on the relay agent for the particular prefix pool, the status of this prefix pool can be determined by the delegated prefixes within the associated prefix pool. If at least one of delegated prefix in the associated prefix pool has valid lease, the server shall turn the status of the prefix pool to be 'Valid'. If the lease of each delegated prefix within the associated prefix pool got expired, or if the delegated prefix in the relay-forward message of RELEASE is the last prefix releasing in the associated prefix pool, the server shall turn the status of the associated prefix pool to be 'Released'. If the server is set to not support the route aggregation on the relay agent for the particular prefix pool, the status of prefix pool will always be 'Released'.

Once received the ORO to request Prefix Pool option in the relay-forward message, the server must include Prefix Pool option with its status in the relay-reply message of REPLY.

When the administrator of the server changes the setting to support the route aggregation on the relay agent for the particular prefix pool or not, the server may initiates the relay-reply message of RECONFIGURE (10) including Prefix Pool option to add or withdraw the prefix pool and the associated aggregation route on the relay agent if at least one delegated prefix within the prefix pool still has the valid lease. .

Note that multiple prefix pools may associate with the same PE router implementing relay agent (Figure 1) or its client-facing interface (Figure 2) in the binding table on the server, and one delegated prefix is only from one prefix pool.

After received the LEASEQUERY (14) message from the relay agent with the Query option (OPTION_LQ_QUERY, 44) including Option Request option (OPTION_ORO, 6) to request Prefix Pool option, the server must include the Client Data options (OPTION_CLIENT_DATA, 45) in the LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (16) message to convey the binding data of the associated prefix pools with the 'Valid' status through the established TCP connection per RFC5460. Each Client Data option shall contain Prefix Pool option, and might contain the Interface ID option. In order to be able to give the meaningful replies to different type of query, the server has to be able to maintain the relevant association of prefix pools with the RELAY_ID, link addresses or Remote_ID of the relay agent in its binding database.

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. Acknowledgements

Thanks to the DHC working group members, Bernie Volz, Eliot Lear, Ole Troan, Roberta Maglione, Ted Lemon, for the discussion in the mailing list. Thanks to Christian Jacquenet for pointing out the draft should cover one more use case of ISP-Customer network where CE is connected to PE through access network. Thanks to Sven Ooghe and Shrinivas Ashok Joshi for the discussion during IETF79, and pointing out the mechanism introduced in this draft should cover the case of reboot.

10. Changes Log

If this document is accepted for publication as an RFC, this change log is to be removed before publication.

Rev. -03

1. Revisions on the behavior of Relay Agent about the automatic withdrawal against the aggregation route.
2. Corrections on the behavior of Server about the Interface ID option.

Rev. -02

1. Add one more use case of ISP network architecture where CE is directly connected to PE.
2. Revisions on the usage of the 'status' field in Prefix Pool option.
3. Extend DHCPv6 Bulk Leasequery (RFC5460) for the new usage.

11. References

11.1. Normative References

11.2. Informative References

Authors' Addresses