Aggregate Route Option for Dynamic Host Control Protocol version 6 (DHCPv6)
draft-joshi-dhc-dhcpv6-aggr-route-opt-00

Abstract

The Aggregate Route option provides a mechanism for a requestor to retrieve an aggregate route(s) from a DHCPv6 server using the information-request message. The aggregate route is a single route representing multiple prefixes delegated by a DHCP server using Prefix Delegation, and maybe advertised using routing protocols instead of individual routes learnt from DHCPv6 Prefix Delegation. This document specifies the data contained in aggregate route option as well as the behavior of Requestor and DHCPv6 Server in requesting and processing of this option.

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. Aggregate Route option
• 4. Requestor Behavior
• 4.1. Requesting Aggregate Route Information
• 4.2. Processing Server Reply
• 4.3. Validation of aggregate route bindings
• 5. Server Behavior
• 6. Acknowledgements
• 7. Security Considerations
• 8. IANA Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Author's Address

1. Introduction

In service provider networks intermediate routers between DHCPv6 Server and Consumer Premise Equipment (CPE) equipment implement a DHCPv6 Relay function to learn Prefixes Delegated [RFC3633] by the DHCPv6 server to CPE equipment. The intermediate routers may use routing protocols to advertise themselves as routers for these individual delegated prefixes. With each intermediate router being connected to a large number of CPE equipment the number of routes the intermediate router needs to advertise is substantial, increasing the size of route tables in peer routers.

If the prefixes delegated by the DHCPv6 server are contiguous then a single aggregate route can represent multiple delegated prefixes. While it is possible to configure such an aggregate route either manually or through Simple Network Management Protocol, it would be operationally efficient if the intermediate router can query the DHCPv6 server for aggregate route be be advertised.

The Aggregate Route option provides such a mechanism to the intermediate router to query the DHCPv6 server for aggregate routes to advertise through routing protocols. Even though the mechanism proposed makes it easy to advertise and withdraw aggregate routes, it is expected that aggregate routes will have a long lifespan.

2. Terminology and Language

This document describes new DHCPv6 option for aggregate route. 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].

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

3. Aggregate Route option

The format of the Aggregate Route 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_AGGR_ROUTE     |            option-length       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         IAID (4 octets)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              T1                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              T2                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                     aggr-route-options                        .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code:    OPTION_AGGR_ROUTE (TBD)

option-length:  12 + length of aggr-route-options field

IAID:                The unique identifier for this OPTION_AGGR_ROUTE; 
                     the IAID must be unique among the identifiers for 
		     all of this requesting router's 
		     OPTION_AGGR_ROUTES.

T1:                  The time at which the requestor should
                     contact the delegating router from which the
                     prefixes were obtained to extend the
                     lifetimes of the aggregated route.
                     T1 is a time duration relative to the current time
                     expressed in units of seconds.

T2:                  The time at which the requestor should
                     contact any available delegating router to extend
                     the lifetimes of the prefixes assigned to the
                     requestor; T2 is a time duration relative to the
                     current time expressed in units of seconds.

aggr-route-options: Options associated with this aggregated route.

The aggr-route-options field encapsulates those options that are specific to this aggregate route request.

In a message sent by the requestor the values in these fields can be used to indicate requestors preference for those values. The requestor shall include one or more options e.g. OPTION_INTERFACE_ID necessary for server to select a unique set of prefixes to be selected for this aggregate route request.

A DHCP server includes the OPTION_IAPREFIX to indicate the prefixes associated with this aggregate route request. More than one prefixes can be associated with a OPTION_AGGR_ROUTE. The status of this OPTION_IAPREFIX is indicated in a Status Code option in the aggr-route-options field.

A OPTION_AGGR_ROUTE may only appear in the options area of a DHCP message. A DHCP message may contain multiple Aggregate Route options.

Note that the Aggregate Route option is an container option and does not have a valid lifetime of its own. When the lifetime of all the associated prefixes have expired, the Aggregate Route option can be considered as expired. T1 and T2 are included to give the DHCP server control over when the Requestor should contact the server for a specific prefix.

In a message sent by a Requestor to a Server, values in the T1 and T2 fields indicate the Requestors preference for those parameters. The Requestor sets T1 and T2 to zero if it has no preference for those values. In a message sent by a Server to a Requestor, the Requestor 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 Server selects the T1 and T2 times to allow the Requestor to extend the lifetimes of any prefixes in the OPTION_AGGR_ROUTE before the lifetimes expire, even if the Server 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 OPTION_AGGR_ROUTE that the Server is willing to extend, respectively. If the time at which the prefixes in an OPTION_AGGR_ROUTE are to be renewed is to be left to the discretion of the requesting router, the Server sets T1 and T2 to 0.

If a Server receives an OPTION_AGGR_ROUTE with T1 greater than T2, and both T1 and T2 are greater than 0, the Server ignores the invalid values of T1 and T2 and processes the OPTION_AGGR_ROUTE as though the Server had set T1 and T2 to 0.

If a Requestor receives an OPTION_AGGR_ROUTE with T1 greater than T2, and both T1 and T2 are greater than 0, the client discards the OPTION_AGGR_ROUTE option and processes the remainder of the message as though the Server had not included the OPTION_AGGR_ROUTE option.

4. Requestor Behavior

4.1. Requesting Aggregate Route Information

The Requestor requests aggregate route information from the DHCP server by sending an information-request message containing one or more OPTION_AGGR_ROUTE (RFC 3315 Section 18.1.5).

The Requestor MUST include its DUID in the information-request message (for a client this is client ID and for a relay this is relay ID).

The Requestor MUST generate and include a transaction-id in the information-request message.

The Requestor within the aggr-route-options of each OPTION_AGGR_ROUTE includes information necessary for the server to associate a unique set of prefixes. The additional information may include options such as INTERFACE_ID.

The Requestor with multiple interface MAY include individual OPTION_AGGR_ROUTE in a single information-request message, with each OPTION_AGGR_ROUTE containing and INTERFACE_ID in its aggr-route-options.

The requestor MAY be configured to use a list of known DHCP server as destination addresses. The requestor SHOULD unicast the information-request to one or more known DHCPv6 servers. In case no such list is configured the requestor MAY send multicast request to All_DHCP_Servers address.

Requestor transmits the information-request according to Section 18.1.5 of RFC 3315.

4.2. Processing Server Reply

Upon receipt of a valid Reply message for each prefix in the OPTION_AGGR_ROUTE the Requestor MAY based on its local configuration add an aggregate route entry into its routing table. The Requestor MAY also advertise itself as a router for the valid prefixes through routing protocols such as OSPF and BGP. Before expiry of valid lifetime of each prefix, the Requestor sends a Renew message to DHCP Server with OPTION_AGGR_ROUTE containing the prefix.

4.3. Validation of aggregate route bindings

The Requestor may request validation of aggregate route binding from the server through the Rebind/Reply exchange. Events which can trigger the validation MAY include.

• - Requestor Reboots.
• - Requestor detects connectivity loss towards the server.
• - Physical disconnection from network.

5. Server Behavior

Upon receipt of a valid information-request containing OPTION_AGGR_ROUTE, Server uses the information contained in the aggr-route-options to identify the associated Prefixes and populates the OPTION_IAPREFIX in aggr-route-options for each of OPTION_AGGR_ROUTE of the REPLY message.

The Server SHALL copy into the REPLY message all the aggr-route-options received from the Requestor.

When the status of aggregate route is reset by manual configuration, the Server shall initiate the message of RECONFIGURE (10) with the Requestor.

6. Acknowledgements

This document offers an alternate mechanism to solution specified in draft-yeh-dhcp-dhcpv6-prefix-pool-opt, the author would like to thank the authors of draft-yeh-.. for discussion of the problem and solution which has served as an input to this draft.

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_AGGR_ROUTE 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

Author's Address