One document matched: draft-joshi-dhc-dhcpv6-aggr-route-opt-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC3633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml">
<!ENTITY RFC3769 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3769.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-joshi-dhc-dhcpv6-aggr-route-opt-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902, or pre5378Trust200902 you can add the attributes updates="NNNN" and obsoletes="NNNN" they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters -->
<title abbrev="Aggregate Route Option">Aggregate Route Option for Dynamic Host Control Protocol version 6 (DHCPv6)</title>
<author fullname="Shrinivas Joshi" initials="S." surname="Joshi">
<organization>Alcatel Lucent</organization>
<address>
<email>shrinivas_ashok.joshi@alcatel-lucent.com</email>
</address>
</author>
<date year="2011" />
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>DHC</workgroup>
<keyword>DHCPv6</keyword>
<keyword>Aggregation Route Option</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<!-- ***** MIDDLE MATTER ***** -->
<middle>
<section anchor="s1" title="Introduction">
<t>
In service provider networks intermediate routers between DHCPv6 Server and Consumer Premise Equipment (CPE) equipment implement a DHCPv6 Relay function to learn Prefixes Delegated <xref target="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.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
<section anchor="s2" title="Terminology and Language">
<t>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 <xref target="RFC3769"/>.</t>
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section anchor="s4" title="Aggregate Route option">
<t>The format of the Aggregate Route option is:</t>
<figure>
<artwork>
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.
</artwork>
</figure>
<t>The aggr-route-options field encapsulates those options that are specific to this aggregate route request.</t>
<t>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.
</t>
<t>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.</t>
<t>A OPTION_AGGR_ROUTE may only appear in the options area of a DHCP message. A DHCP message may contain multiple Aggregate Route options.</t>
<t>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. </t>
<t>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.</t>
<t>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. </t>
<t>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. </t>
<t>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. </t>
</section>
<section anchor="s5" title="Requestor Behavior">
<section anchor="RequestingAggregateRoute" title="Requesting Aggregate Route Information">
<t>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).</t>
<t>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). </t>
<t>The Requestor MUST generate and include a transaction-id in the information-request message.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>Requestor transmits the information-request according to Section 18.1.5 of RFC 3315. </t>
</section>
<section anchor="ProcessingServerReply" title="Processing Server Reply">
<t>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. </t>
</section>
<section anchor="AggregateRouteBindingValidation" title="Validation of aggregate route bindings">
<t>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.
<list style="empty">
<t> - Requestor Reboots.</t>
<t> - Requestor detects connectivity loss towards the server.</t>
<t> - Physical disconnection from network.</t>
</list>
</t>
</section>
</section>
<section anchor="s6" title="Server Behavior">
<t>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.</t>
<t>The Server SHALL copy into the REPLY message all the aggr-route-options received from the Requestor.</t>
<t>When the status of aggregate route is reset by manual configuration, the Server shall initiate the message of RECONFIGURE (10) with the Requestor.</t>
</section>
<section anchor="a1" title="Acknowledgements">
<t>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.</t>
</section>
<section anchor="s7" title="Security Considerations">
<t>Security issues related DHCPv6 are described in section 23 of RFC 3315.</t>
</section>
<section anchor="s8" title="IANA Considerations">
<t>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).</t>
</section>
</middle>
<!-- ***** BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC3315;
&RFC3633;
&RFC3769;
&RFC2119;
</references>
<references title="Informative References">
<reference anchor='BBFTR177'>
<front>
<title>IPv6 in the context of TR-101 Issue: 1</title>
<author initials='' surname='Broadband Forum' fullname='' />
<date year='2010' month='November' />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 15:48:44 |