One document matched: draft-ietf-mif-dhcpv6-route-option-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mif-dhcpv6-route-option-02"
ipr="trust200902">
<front>
<title abbrev="">DHCPv6 Route Options</title>
<author fullname="Wojciech Dec" initials="W" role="editor" surname="Dec">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Haarlerbergweg 13-19</street>
<city>1101 CH Amsterdam</city>
<country>The Netherlands</country>
</postal>
<email>wdec@cisco.com</email>
</address>
</author>
<author fullname="Tomasz Mrugalski" initials="T" surname="Mrugalski">
<organization abbrev="ISC">Internet Systems Consortium, Inc.
</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>USA</country>
</postal>
<phone>+1 650 423 1345</phone>
<email>tomasz.mrugalski@gmail.com</email>
</address>
</author>
<author fullname="Tao Sun" initials="T" surname="Sun">
<organization>China Mobile</organization>
<address>
<postal>
<street>Unit2, 28 Xuanwumenxi Ave</street>
<city>Beijing</city>
<region>Xuanwu District</region>
<code>100053</code>
<country>China</country>
</postal>
<phone></phone>
<email>suntao@chinamobile.com</email>
</address>
</author>
<author fullname="Behcet Sarikaya" initials="B" surname="Sarikaya">
<organization>Huawei USA</organization>
<address>
<postal>
<street>1700 Alma Dr. Suite 500</street>
<city>Plano</city>
<region>TX</region>
<code>75075</code>
<country>United States</country>
</postal>
<phone>+1 972-509-5599</phone>
<facsimile></facsimile>
<email>sarikaya@ieee.org</email>
<uri></uri>
</address>
</author>
<date day="26" month="July" year="2011" />
<abstract>
<t>This document describes DHCPv6 Route Options for provisioning IPv6
routes on DHCPv6 client nodes. This is expected to improve the ability
of an operator to configure and influence a nodes' ability to pick an
appropriate route to a destination when this node is multi-homed and
where other means of route configuration may be impractical.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The Neighbor Discovery (ND) protocol <xref
target="RFC4861"></xref> provides a mechanism for hosts to discover one
or more default routers on a directly connected network segment.
Extensions to the Router Advertisement (RA) protocol defined in <xref
target="RFC4191"></xref> allow hosts to discover the preferences for
multiple default routers on a given link, as well as any specific routes
advertised by these routers. This allows network administrators to
better handle multi-homed host topologies and influence the route
selection by the host. This ND based mechanism however is sub optimal or
impractical in some multi-homing scenarios, where DHCPv6 <xref
target="RFC3315"></xref>is seen to be more viable.</t>
<t>This draft defines the DHCPv6 Route Options for provisioning IPv6
routes on DHCPv6 clients. The proposed option is primarily envisaged for
use by DHCPv6 client nodes that are capable of making basic IP routing
decisions and maintaining an IPv6 routing table, broadly in line with
the capabilities of a generic host as described in <xref
target="RFC4191"></xref>.</t>
<t>Throughout the document the words node and client are used as a
reference to the device with such routing capabilities, hosting the
DHCPv6 client software. The route information is taken to be equivalent
to static routing, and limited in the number of required routes to a
handful.</t>
</section>
<section title="Problem overview">
<t>The solution described in this document applies to multi-homed
scenarios including ones where the client is simultaneously connected to
multiple access network (e.g. WiFi and 3G). The following scenario is
used to illustrate the problem as found in typical multi-homed
residential access networks. It is duly noted that the problem is not
specific to IPv6, occurring also with IPv4, where it is today solved by
means of DHCPv4 classless route information option <xref
target="RFC3442"></xref>, or alternative configuration mechanisms.</t>
<t>In multi-homed networks, a given user's node may be connected to more
than one gateways. Such connectivity may be realized by means of
dedicated physical or logical links that may also be shared with other
users nodes. In such multi-homed networks it is quite common for the
network operator to offer the delivery of a particular type of IP
service via a particular gateway, where the service can be characterised
by means of specific destination IP network prefixes. Thus, from an IP
routing perspective in order for the user node to select the appropriate
gateway for a given destination IP prefix, recourse needs to be made to
classic longest destination match IP routing, with the node acquiring
such prefixes into its routing table. This is typically the remit of
dynamic Internal Gateway Protocols (IGPs), which however are rarely used
by operators in residential access networks. This is primarily due to
operational costs and a desire to contain the complexity of user nodes
and IP Edge devices to a minimum. While, IP Route configuration may be
achieved using the ICMPv6 extensions defined in <xref
target="RFC4191"></xref>, this mechanism does not lend itself to other
operational constraints such as the desire to control the route
information on a per node basis, the ability to determine whether a
given node is actually capable of receiveing/processing such route
information. A preferred mechanism, and one that additionally also lends
itself to centralized management independent of the management of the
gateways, is that of using the DHCP protocol for conveying route
information to the nodes.</t>
</section>
<section anchor="solution" title="DHCPv6 Based Solution">
<t>A DHCPv6 based solution allows an operator an on demand and node
specific means of configuring static routing information. Such a
solution also fits into network environments where the operator prefers
to manage RG configuration information from a centralized DHCP server.
<xref target="I-D.troan-multihoming-without-nat66"></xref> provides
additional background to the need for a DHCPv6 solution to the
problem.</t>
<t>In terms of the high level operation of the solution defined in this
draft, a DHCPv6 client interested in obtaining routing information
request the route option using the DHCPv6 Option Request Option (ORO)
sent to a server. A Server, when configured to do so, provides the
requested route information as part of a nested options structure
covering; the next-hop address; the destination prefix; the route
metric; any additional options applicable to the destination or
next-hop. The overall DHCPv6 design follow a similar approach to that
used in the design of the IA_NA, IA_TA and IA_PD options in <xref
target="RFC3633"></xref>.</t>
</section>
<section anchor="formats" title="DHCPv6 Route Options">
<t>A DHCPv6 client interested in obtaining routing information includes
the OPTION_IA_RT as par of its DHCPv6 Option Request Option (ORO) in
messages directed to a server (as allowed by <xref
target="RFC3315"></xref>, i.e. Solicit, Request, Renew, Rebind, Confirm or
Information-request messages). A Server, when configured to do so,
provides the requested route information using the OPTION_IA_RT option
in messages sent in response (Advertise, and Reply). So as to allow the
route option to be both extensible, as well as conveying detailed info
for routes, use is made of a nested options structure. An IA_RT conveys
one or more OPTION_NEXT_HOP options that specify the IPv6 next hop
addresses. Each OPTION_NEXT_HOP conveys in turn one or more
OPTION_RT_PREFIX options that represents the IPv6 destination prefixes
reachable via the given next hop. The Formats of the OPTION_IA_RT,
OPTION_NEXT_HOP and OPTION_RT_PREFIX are defined in the following
sub-sections</t>
<t>The DHCPv6 Route Option format borrows from the principles of the
Route Information Option defined in <xref target="RFC4191"></xref>. One
notable exception with respect to <xref target="RFC4191"></xref> is
however that a Route Lifetime element is not defined. The information
conveyed by the DHCPv6 Route Option is considered valid until changed or
refreshed by general events that trigger DHCPv6 or route table state
changes on a node, thus not requiring a specific route lifetime. In the
event that it is desired for the client to request a refresh of the
route information (and other stateless DHCPv6 options), use of the
generic DHCPv6 Information Refresh Time Option, as specified in <xref
target="RFC4242"></xref> is envisaged.</t>
<section anchor="ia-rt-format" title="DHCPv6 Route Option Format">
<t>To separate routing information from other options conveyed in a
DHCPv6 message, the DHCPv6 Route Option is defined and is used to
convey to a client one or more IPv6 routes. Each IPv6 route consists
of an IPv6 next hop address, an IPv6 destination prefix (a.k.a. the
destination subnet), and a host preference value for the route.
Elements of such route (e.g. Next hops and prefixes associated with
them) are conveyed in IA_RT's options, rather than in the IA_RT option
itself.</t>
<figure align="center" anchor="ia-rt-option-format"
title="IPv6 Routes Option Format">
<artwork><![CDATA[ 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_IA_RT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA_RT options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list hangIndent="10" style="hanging">
<t hangText="option-code:">OPTION_IA_RT (TBD).</t>
<t hangText="option-len:">Length of the IA_RT options field.</t>
<t hangText="IA_RT options:">Options associated with this IA_RT.
This includes, but is not limited to, OPTION_NEXT_HOP options that
specify next hop addresses.</t>
</list></t>
<t>The Route option MUST NOT appear in the following DHCPv6 messages:
Solicit, Request, Renew, Rebind, Information-Request. The Route Option
MAY appear in ADVERTISE and REPLY messages.</t>
<t>If there is more than one route available via specific next
hop, server MUST send only one OPTION_NEXT_HOP for that next
hop, which contains multiple OPTION_RT_PREFIX options. Server
MUST NOT send more than one identical (i.e. with equal next
hop address field) OPTION_NEXT_HOP option.</t>
<t>Discussion: Traditionally, grouping options (IA_NA, IA_TA and
IA_RD) contain an identifier field (IAID) that must be unique among
identifiers generated by one client. It is used to differentiate
between several options of the same type (e.g. several IA_NA options)
that may be used simultaneously. However, it is assumed that client
will never use more than one IA_RT option therefore such an identifier
is not needed.</t>
</section>
<section anchor="next-hop-format" title="Next Hop Option Format">
<t>The Next Hop Option defines the IPv6 address of the next hop,
usually corresponding to a specific next-hop router. For each next hop
address there can be one or more prefixes reachable via that next
hop.</t>
<figure align="center" anchor="next-hop-option-format"
title="IPv6 Route Option Format">
<artwork><![CDATA[ 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_NEXT_HOP | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Next Hop Address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NEXT_HOP options |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list hangIndent="10" style="hanging">
<t hangText="option-code:">OPTION_NEXT_HOP (TBD).</t>
<t hangText="option-len:">16 + Length of NEXT_HOP options
field.</t>
<t hangText="IPv6 Next Hop Address:">16 octet long field that
specified IPv6 address of the next hop.</t>
<t hangText="NEXT_HOP options:">Options associated with this Next
Hop. This includes, but is not limited to, one or more
OPTION_RT_PREFIX options that specify prefixes reachable through
the given next hop.</t>
</list></t>
</section>
<section anchor="rt-prefix-format" title="Route Prefix Option Format">
<t>The Route Prefix Option is used to convey information about a
single prefix that represents the destination network. The Route
Prefix Option is used as a sub-option in the previously defined Next
Hop Option.</t>
<figure align="center" anchor="rt-prefix-option-format"
title="Route Prefix Option Format">
<artwork><![CDATA[ 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_RT_PREFIX | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Length | Metric | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Prefix |
| (16 octets) |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. RT_PREFIX options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list hangIndent="10" style="hanging">
<t hangText="option-code:">OPTION_RT_PREFIX (TBD).</t>
<t hangText="option-len:">18 + length of RT_PREFIX options.</t>
<t hangText="Prefix Length:">8-bit unsigned integer. The length in
bits of the IP Prefix. The value ranges from 0 to 128. This field
represents the number of valid leading bits in the prefix.</t>
<t hangText="Metric:">Route Metric. 8-bit signed integer. The
Route Metric indicates whether to prefer the next hop associated
with this prefix over others, when multiple identical prefixes
(for different next hops) have been received.</t>
<t hangText="Prefix:">Fixed length 16 octet field containing an
IPv6 prefix.</t>
<t hangText="RT_PREFIX options:">Options specific to this
particular prefix.</t>
</list></t>
</section>
</section>
<!--
<section title="Conveying multiple Routes" />
<t>A single option can be used to covey multiple prefixes for the same
or different next hops. The example below illustrates a route option
with two routes, consisting of Prefix A and Prefix B with the same next
hop addresses Next Hop 1, and a Prefix C with Next Hop 2. Example of
such option is presented in <xref target="option-example" />.</t>
<figure align="center" anchor="option-example"
title="IPv6 Route Option Format Example">
<artwork><![CDATA[ 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_ROUTE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Next Hop Address 1 |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH1-Prefix-Len|Prefix A Length| Reserved |Prf| Prefix A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| (16 octets) |
| |
| |
| +-+-+-+-+-+-+-+-+
| |Prefix B Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Prf| Prefix B |
+-+-+-+-+-+-+-+-+ |
| (16 octets) |
| |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | IPv6 Next Hop Address 2 |
+-+-+-+-+-+-+-+-+ |
| |
| |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NH2-Prefix-Len|Prefix C Length| Reserved |Prf|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix C |
| |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section> -->
<section anchor="server" title="DHCPv6 Server Behavior">
<t>When configured to do so s DHCPv6 server shall provide the Routes
Option in ADVERTISE and REPLY messages sent to a client that requested
the route option. Each Next Hop Option sent by the server must convey at
least one Route Prefix Option.</t>
<t>Servers SHOULD NOT send Route Option to clients that did not
explicitly requested it, using the ORO.</t>
<t>Servers MUST NOT send Route Option in messages other than ADVERTISE
or REPLY.</t>
<t>Servers MAY also include Status Code Option, defined in Section 22.13
of the <xref target="RFC3315"></xref> to indicate the status of the
operation.</t>
<t>Servers MUST include the Status Code Option, if the requested routing
configuration was not successful and SHOULD use status codes as defined
in <xref target="RFC3315"></xref> and <xref
target="RFC3633"></xref>.</t>
<t>The maximum number of routing information in one DHCPv6 message
depend on the maximum DHCPv6 message size defined in <xref
target="RFC3315"></xref></t>
<t>Discussion: How should server indicate that there are no specific
routes for this particular client? The reasonable behavior is to return
empty IA_RT option, possibly with Status Code indicating Success.
Another approach could be to simply not return any IA_RT option.</t>
</section>
<section anchor="client" title="DHCPv6 Client Behavior">
<t>A DHCPv6 client compliant with this specification MUST request the
Route Option (option value TBD) in an Option Request Option (ORO) in the
following messages: Solicit, Request, Renew, Rebind, Information-Request
or Reconfigure. The messages are to be sent as and when specified by
<xref target="RFC3315"></xref>.</t>
<t>When processing a received Route Option a client MUST substitute a
received 0::0 value in the Next Hop Option with the source IPv6 address
of the received DHCPv6 message. It MUST also associate a received Link
Local next hop addresses with the interface on which the client received
the DHCPv6 message containing the route option. Such a substitution
and/or association is useful in cases where the DHCPv6 server operator
does not directly know the IPv6 next-hop address, other than knowing it
is that of a DHCPv6 relay agent on the client LAN segment. DHCPv6
Packets relayed to the client are sourced by the relay using this
relay's IPv6 address, which could be a link local address.</t>
<t>The Client MAY refresh assigned route information periodically. The
generic DHCPv6 Information Refresh Time Option, as specified in <xref
target="RFC4242"></xref>, can be used when it is desired for the client
to periodically refresh of route information.</t>
<t>The routes conveyed by the Route Option should be considered as
complimentary to any other static route learning and maintenance
mechanism used by, or on the client with one modification: The client
MUST flush DHCPv6 installed routes following a link flap event on the
DHCPv6 client interface over which the routes were installed. This
requirement is necessary to automate the flushing of routes for clients
that may move to a different network.</t>
<t>Client MUST confirm that routers announced over DHCPv6 are
reachable, using one of methods suitable for specific network
type. The most common mechanism is Neighbor Unreachability
Detection (NUD), specified in <xref target="RFC4861"/>. Client
SHOULD use NUD to verify that received routers are reachable
before adjusting its routing tables. Client MAY use other
reachibality verification mechanisms specific to used network
technology. To avoid potential long-lived routing black holes,
client MAY periodically confirm that router is still
reachable.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>A DHCPv6 option number of TBD for the introduced Route Option. IANA
is requested to allocate three DHCPv6 option codes referencing this
document: OPTION_IA_RT, OPTION_NEXT_HOP and OPTION_RT_PREFIX.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The overall security considerations discussed in <xref
target="RFC3315"></xref> apply also to this document. The Route option
could be used by malicious parties to misdirect traffic sent by the
client either as part of a denial of service or man-in-the-middle
attack. An alternative denial of service attack could also be realized
by means of using the route option to overflowing any known memory
limitations of the client, or to exceed the client's ability to handle
the number of next hop addresses.</t>
<t>Neither of the above considerations are new and specific to the
proposed route option. The mechanisms identified for securing DHCPv6 as
well as reasonable checks performed by client implementations are deemed
sufficient in addressing these problems.</t>
<t>It is essential that clients verify that announced routers are
indeed reachable, as specified in <xref target="client"/>. Failing to
do so may create black hole routing problem.</t>
</section>
<section anchor="Acknowledgements"
title="Contributors and Acknowledgements">
<t>This document would not have been possible without the significant
contribution provided by: Arifumi Matsumoto, Hui Deng, Richard Johnson,
Zhen Cao.</t>
<t>The authors would also like to thank Alfred Hines, Ralph Droms, Ted
Lemon, Ole Troan, Dave Oran, Dave Ward and Joel Halpern for their
comments and useful suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3315"?>
<?rfc include="reference.RFC.3633"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3442"?>
<?rfc include="reference.RFC.4191"?>
<?rfc include="reference.RFC.4242"?>
<?rfc include="reference.RFC.4861"?>
<?rfc include="reference.I-D.troan-multihoming-without-nat66"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:03:13 |