One document matched: draft-ietf-mif-dhcpv6-route-option-03.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-03"
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="10" month="September" 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 gateway. 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 Residential Gateway (RG)
configuration information from a centralized DHCP server. <xref
target="I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat"></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 options 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.</t>
<section anchor="default-route" title="Default route configuration">
<t>Defined mechanism may be used to configure default
route. Default route may be specified in two ways.</t>
<t>In bandwidth constrained networks, server MAY send NEXT_HOP
option without any RT_PREFIX options. NEXT_HOP option that
does not contain any RT_PREFIX options designate default
router. Second way of defining default route is to convey
RT_PREFIX option that specifies ::/0 route, included as
suboption in NEXT_HOP. First approach has the benefit of
consuming less bandwidth, while the second one allows
definition of default route lifetime and metric.</t>
<t>Server MUST NOT define more than one default prefix
(i.e. both defined configuration methods are mutually
exclusive). Unless there are significant bandwidth
restrictions, mechanism that uses ::/0 RT_PREFIX option SHOULD
be used.</t>
</section>
<section anchor="on-link" title="Configuring on-link routes">
<t>Server may also configure on-link routes, i.e. routes that
are available directly over the link, not via routers. To
specify on-link routes, server MAY include RTPREFIX option
directly in Advertise and Reply messages.</t>
</section>
<section anchor="delete" title="Deleting obsolete route">
<t>There are two mechanisms that allow removing a route. Each
defined route has a route lifetime. If specific route
is not refreshed and its timer reaches 0, client MUST remove
corresponding entry from routing table.</t>
<t>In cases, where faster route removal is needed, server
SHOULD return RT_PREFIX option with route lifetime set to
0. Client that receives RT_PREFIX with route lifetime set to 0
MUST remove specified route immediately, even if its previous
lifetime did not expire yet.</t>
</section>
<section anchor="routers" title="Applicability to routers">
<t>Contrary to Router Adverisement mechanism, defined in <xref
target="RFC4861"/> that explicitly limits configuration to
hosts, routing configuration over DHCPv6 defined in this
document may be used by both hosts and routers.</t>
<t>One of the envisaged usages for this solution are
residential gateways (RG) or Customer Premises Equipment
(CPE). Those devices very often perform routing. It may be
useful to configure routing on such devices over DHCPv6. One
example of such use may be a class of premium users that are
allowed to use dedicated router that is not available to
regular users.</t>
</section>
<section anchor="reconfigure" title="Updating Routing Information">
<t>Network configuration occassionally changes, due to failure
of existing hardware, migration to newer equipment or many
other reasons. Therefore there a way to inform clients that
routing information have changed is required.</t>
<t>There are several ways to inform clients about new routing
information. Every client SHOULD periodically refresh its
configuration, according to Information Refresh Time Option,
so server may send updated information the next time client
refreshes its information. New routes may be configured at
that time. As every route has associated lifetime, client is
required to remove its routes when this timer expires. This
method is particularly useful, when migrating to new router is
undergoing, but old router is still available.</t>
<t>Server MAY also announce routes via soon to be removed
router with lifetimes set to 0. This will cause the client to
remove its routes, despite the fact that previously received
lifetime may not yet expire.</t>
<t>Aforementioned methods are useful, when there is no urgent
need to update routing information. Bound by timer set by
value of Information Refresh Time Option, clients may use
outdated routing information until next scheduled
renewal. Depending on configured value this delay may be not
acceptable in some cases. In such scenarios, administrators
are advised to use RECONFIGURE mechanism, defined in <xref
target="RFC3315"/>. Server transmits RECONFIRGURE message to
each client, thus forcing it to immediately start renewal
process.</t>
<t>See also <xref target="limit"/> about limitations regarding
dynamic routing.</t>
</section>
<section anchor="limit" title="Limitations">
<t>Defined mechanism is not intended to be used as a dynamic
routing protocol. It should be noted that proposed mechanism
cannot automatically detect routing changes. In networks that
use dynamic routing and also employ this mechanism, clients
may attempt using routes configured over DHCPv6 even though
routers or specific routes ceased to be available. This may
cause black hole routing problem. Therefore it is not
recommended to use this mechanism in networks that use dynamic
routing protocols. This mechanism SHOULD NOT be used in such
networks, unless network operator can provide a way to update
DHCP server information in case of router availability
changes.</t>
<t>Discussion: It should be noted that DHCPv6 server is not
able to monitor health of existing routers. As there are
currently more than 60 options defined for DHCPv6, it is
infeasible to implement mechanism that would monitor huge set
of services and stop announcing its availability in case of
service outage. Therefore in case of prolonged unavailability
human interverntion is required to change DHCPv6 server
configuration. If that is considered a problem, network
administrators should consider using other alternatives, like
RA and ND mechanisms (see <xref target="RFC4861"></xref>).</t>
</section>
</section>
<section anchor="formats" title="DHCPv6 Route Options">
<t>A DHCPv6 client interested in obtaining routing information
includes the NEXT_HOP and RT_PREFIX options as part of its
Option Request Option (ORO) in messages directed to a server (as
allowed by <xref target="RFC3315"></xref>, i.e. Solicit,
Request, Renew, Rebind or Information-request messages). A
Server, when configured to do so, provides the requested route
information using zero, one or more NEXT_HOP options in messages
sent in response (Advertise, and Reply). So as to allow the
route options to be both extensible, as well as conveying
detailed info for routes, use is made of a nested options
structure. Server sends one or more NEXT_HOP options that
specify the IPv6 next hop addresses. Each NEXT_HOP option
conveys in turn zero, one or more RT_PREFIX options that
represents the IPv6 destination prefixes reachable via the given
next hop. Server includes RT_PREFIX directly in message to
indicate that given prefix is available directly on-link. Server
MAY send a single NEXT_HOP without any RT_PREFIX suboptions or
with RT_PREFIX that contains ::/0 to indicate available default
route. The Formats of the NEXT_HOP and RT_PREFIX options are
defined in the following sub-sections.</t>
<t>The DHCPv6 Route Options 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 Options 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>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>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 NEXT_HOP option that contains RT_PREFIX
suboptions.</t>
<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 zero, one or more prefixes reachable via that next
hop.</t>
<figure align="center" anchor="next-hop-option-format"
title="IPv6 Next Hop 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, zero, one or more
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. It may also be sent directly in
message to indicate that route is available directly
on-link.</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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route lifetime |
+-------------------------------+-------------------------------+
| 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="Route lifetime">32-bit unsigned
integer. Specifies lifetime of the route information,
expressed in seconds. There are 2 special values defined. 0 means
that route is no longer valid and must be removed by clients. 0xffffffff
means infinity.</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, a DHCPv6 server shall provide the
Next Hop and Route Prefix Options 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>Server includes NEXT_HOP option with possible RT_PREFIX
suboptions to designate that specific routes are available via
routers. Server includes RT_PREFIX options directly in Advertise
and Reply messages to inform that specific routes are available
directly on-link.</t>
<t>If there is more than one route available via specific next
hop, server MUST send only one NEXT_HOP for that next hop,
which contains multiple RT_PREFIX options. Server MUST NOT
send more than one identical (i.e. with equal next hop address
field) NEXT_HOP 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>
</section>
<section anchor="client" title="DHCPv6 Client Behavior">
<t>A DHCPv6 client compliant with this specification MUST
request the NEXT_HOP and RT_PREFIX Options in an Option Request
Option (ORO) in the following messages: Solicit, Request, Renew,
Rebind, and Information-Request. The messages are to be sent as
and when specified by <xref target="RFC3315"></xref>.</t>
<t>When processing a received Route Options 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 SHOULD 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 anchor="conflict" title="Conflict resolution">
<t>In misconfigured networks it may be possible that client
receives conflicting route information over DHCPv6 and other
configuration mechanisms, e.g. RA.</t>
<t>In case of conflict, information received over DHCPv6
SHOULD take precedence, unless there are important reasons to
do otherwise. In particular, two facts should be taken into
consideration here. Information received over RA is generic
for all hosts in a network and route information received over
DHCPv6 may be configured on per node basis. Another reason for
favoring DHCPv6 over non-secured mechanisms is the fact that
DHCPv6 information offers security protection. If trust
relationship is established between client and server,
information provided by such a server SHOULD be favored over
other, untrusted route configuration mechanisms.</t>
<t>If security of routing configuration is of particular
importance, strong protection mechanisms should be considered, e.g.
Secure Neighbor Discovery<xref target="RFC3971"/>. See also
<xref target="security"/>.</t>
</section> -->
</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_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>
<t>This mechanism may introduce severe problems if deployed in
networks that use dynamic routing protocols. See <xref
target="limit"/> for details.</t>
<t>Reader is also encouraged to read DHCPv6 security considerations
document <xref target="I-D.ietf-dhc-secure-dhcpv6"/>.</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,
and Zhen Cao.</t>
<t>The authors would also like to thank Alfred Hines, Ralph
Droms, Ted Lemon, Ole Troan, Dave Oran, Dave Ward, Joel Halpern,
Marcin Siodelski and Alexandru Petrescu 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.3971"?> -->
<?rfc include="reference.RFC.4191"?>
<?rfc include="reference.RFC.4242"?>
<?rfc include="reference.RFC.4861"?>
<?rfc include="reference.I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat"?>
<?rfc include="reference.I-D.ietf-dhc-secure-dhcpv6"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 13:07:00 |