Internet DRAFT - draft-joshi-dhc-dhcpv6-aggr-route-opt
draft-joshi-dhc-dhcpv6-aggr-route-opt
DHC S. Joshi
Internet-Draft Alcatel Lucent
Intended status: Standards Track September 8, 2011
Expires: March 11, 2012
Aggregate Route Option for Dynamic Host Control Protocol version 6
(DHCPv6)
draft-joshi-dhc-dhcpv6-aggr-route-opt-01
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 March 11, 2012.
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
Joshi Expires March 11, 2012 [Page 1]
Internet-Draft Aggregate Route Option September 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Language . . . . . . . . . . . . . . . . . . . 3
3. Aggregate Route option . . . . . . . . . . . . . . . . . . . . 3
4. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Requesting Aggregate Route Information . . . . . . . . . . 6
4.2. Processing Server Reply . . . . . . . . . . . . . . . . . . 6
4.3. Validation of aggregate route bindings . . . . . . . . . . 6
5. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Joshi Expires March 11, 2012 [Page 2]
Internet-Draft Aggregate Route Option September 2011
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:
Joshi Expires March 11, 2012 [Page 3]
Internet-Draft Aggregate Route Option September 2011
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.
Joshi Expires March 11, 2012 [Page 4]
Internet-Draft Aggregate Route Option September 2011
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.
Joshi Expires March 11, 2012 [Page 5]
Internet-Draft Aggregate Route Option September 2011
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
Joshi Expires March 11, 2012 [Page 6]
Internet-Draft Aggregate Route Option September 2011
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
Joshi Expires March 11, 2012 [Page 7]
Internet-Draft Aggregate Route Option September 2011
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, June 2004.
9.2. Informative References
[BBFTR177]
Broadband Forum, "IPv6 in the context of TR-101 Issue: 1",
November 2010.
Author's Address
Shrinivas Joshi
Alcatel Lucent
Email: shrinivas_ashok.joshi@alcatel-lucent.com
Joshi Expires March 11, 2012 [Page 8]
