DHCPv6 Route OptionsCisco SystemsHaarlerbergweg 13-191101 CH AmsterdamThe Netherlandswdec@cisco.comInternet Systems Consortium, Inc.
950 Charter StreetRedwood CityCA94063USA+1 650 423 1345tomasz.mrugalski@gmail.comChina MobileUnit2, 28 Xuanwumenxi AveBeijingXuanwu District100053Chinasuntao@chinamobile.comHuawei USA1700 Alma Dr. Suite 500PlanoTX75075United States+1 972-509-5599sarikaya@ieee.orgThis 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.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 RFC 2119.The Neighbor Discovery (ND) protocol 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 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 is seen to be more viable.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 .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.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 , or alternative configuration mechanisms.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 , 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.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. provides
additional background to the need for a DHCPv6 solution to the
problem.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.Defined mechanism may be used to configure default
route. Default route may be specified in two ways.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.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.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.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.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.Contrary to Router Adverisement mechanism, defined in that explicitly limits configuration to
hosts, routing configuration over DHCPv6 defined in this
document may be used by both hosts and routers.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.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.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.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.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 . Server transmits RECONFIRGURE message to
each client, thus forcing it to immediately start renewal
process.See also about limitations regarding
dynamic routing.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.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 ).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 , 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.The DHCPv6 Route Options format borrows from the principles of the
Route Information Option defined in .
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.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.OPTION_NEXT_HOP (TBD).16 + Length of NEXT_HOP options
field.16 octet long field that
specified IPv6 address of the next hop.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.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.OPTION_RT_PREFIX (TBD).18 + length of RT_PREFIX options.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.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.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.Fixed length 16 octet field containing an
IPv6 prefix.Options specific to this
particular prefix.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.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.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.Servers SHOULD NOT send Route Option to clients that did not
explicitly requested it, using the ORO.Servers MUST NOT send Route Option in messages other than ADVERTISE
or REPLY.Servers MAY also include Status Code Option, defined in Section 22.13
of the to indicate the status of the
operation.Servers MUST include the Status Code Option, if the requested routing
configuration was not successful and SHOULD use status codes as defined
in and .The maximum number of routing information in one DHCPv6 message
depend on the maximum DHCPv6 message size defined in 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 .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.The Client SHOULD refresh assigned route information periodically. The
generic DHCPv6 Information Refresh Time Option, as specified in , can be used when it is desired for the client
to periodically refresh of route information.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.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 . 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.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.The overall security considerations discussed in 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.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.It is essential that clients verify that announced routers are
indeed reachable, as specified in . Failing to
do so may create black hole routing problem.This mechanism may introduce severe problems if deployed in
networks that use dynamic routing protocols. See for details.Reader is also encouraged to read DHCPv6 security considerations
document .This document would not have been possible without the significant
contribution provided by: Arifumi Matsumoto, Hui Deng, Richard Johnson,
and Zhen Cao.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.