Network Working Group W. Dec
Internet-Draft R. Johnson
Intended status: Standards Track Cisco Systems
Expires: January 13, 2011 T. Mrugalski
Gdansk University of Technology
A. Matsumoto
NTT PF Lab
July 12, 2010
DHCPv6 Route Options
draft-dec-dhcpv6-route-option-04
Abstract
This document describes the DHCPv6 Route Options for provisioning
IPv6 routes on a DHCPv6 client. This is expected to improve the
ability of an operator to configure and influence a client's ability
to pick an appropriate route to a destination when this client is
multi-homed and where other means of route configuration may be
impractical. The options are primarily envisaged for configuring a
broadband Residential Gateway (RG) router, but are generic enough to
be used by other types of DHCPv6 clients that have basic host routing
capabilities.
Requirements Language
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 [RFC2119].
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 January 13, 2011.
Dec, et al. Expires January 13, 2011 [Page 1]
Internet-Draft DHCPv6 Route Options July 2010
Copyright Notice
Copyright (c) 2010 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
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. Problem overview . . . . . . . . . . . . . . . . . . . . . . . 3
3. DHCPv6 Based Solution . . . . . . . . . . . . . . . . . . . . 5
3.1. Options Extensibility . . . . . . . . . . . . . . . . . . 5
3.2. Relation To Other Configuration Methods . . . . . . . . . 6
4. DHCPv6 Options Format . . . . . . . . . . . . . . . . . . . . 6
4.1. DHCPv6 Route Option Format . . . . . . . . . . . . . . . . 6
4.2. Next Hop Option Format . . . . . . . . . . . . . . . . . . 7
4.3. Route Prefix Option Format . . . . . . . . . . . . . . . . 8
5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 10
6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Dec, et al. Expires January 13, 2011 [Page 2]
Internet-Draft DHCPv6 Route Options July 2010
1. Introduction
The Neighbor Discovery protocol [RFC4861] provides a mechanism for
hosts to discover one or more default routers on a directly connected
network segment. Extensions to the protocol defined in [RFC4191]
allow the discovery by such hosts of the preferences for multiple
default routers as well as more 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 mechanism however is sub optimal or impractical in multi-homing
scenarios that are in existence today. These scenarios are broadly
presented in detail in [I-D.troan-multihoming-without-nat66], with
this document focusing on a specific aspect identified therein,
namely the ability to dynamically provision select multi-homed
devices with specific IPv6 routes.
This draft defines the DHCPv6 Route Option for provisioning IPv6
routes on a DHCPv6 client. The proposed option is primarily
envisaged for use by a class of IPv6 routers known as a broadband
Residential Gateway (RG), found in Digital Subscriber Line (DSL),
Cable, and Fibre To The Home (FTTH) environments. It is however
generic enough to be used by other types of advanced DHCPv6 clients
that are have basic IPv6 routing capabilities. It is assumed that
such a client is capable of making basic IP routing decisions and
maintaining a simple IPv6 routing table, in line with the
capabilities of a host, as described in [RFC4191].
Throughout the document the words RG and client are used as a
reference to the device with routing capabilities, hosting the DHCPv6
client software.
2. Problem overview
The following exemplary scenario is used to illustrate the problem as
found in residential broadband 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 or remote configuration
mechanisms.
In residential broadband networks, a given user's routed Residential
Gateway (RG) may be connected to more than one Network Access Servers
(NAS). Such connectivity may be realized by means of dedicated
physical or logical links from the RG to each NAS (e.g. Using
dedicated physical interfaces, or multiple PPP links, or Ethernet
VLANs that may also be shared with the RGs of other users). In
either case a given NAS is intended by the network operator for the
delivery of a particular type of IP service, where the service can be
Dec, et al. Expires January 13, 2011 [Page 3]
Internet-Draft DHCPv6 Route Options July 2010
characterised by means of specific destination IP network prefixes.
Thus, from an IP routing perspective in order for the RG to select
the appropriate NAS router as the gateway for a given destination IP
prefix, recourse needs to be made to classic longest destination
match IP routing, with the RG learning the relevant prefixes. An
issue however is the fact that common dynamic Internal Gateway
Protocols (IGPs) are rarely used by operators for conveying dynamic
route information to RGs. This is due to operational reasons and a
desire to contain the complexity of RGs and IP Edge devices to a
minimum. A preferred mechanism adopted for IPv4 is one of
dynamically provisioning RGs when these connect to the network, which
can be done using the DHCPv4 classless route information option
[RFC3442].
Figure 1 illustrates the case of a single RG connected via two links
to NAS Routers 1 and 2 respectively. NAS Router 1 is the intended
gateway for a specific application served from ServerA (e.g. VoIP or
NMS) whose IP subnet is otherwise not reachable via NAS Router2. The
latter NAS is intended to provide connectivity to an Internet
service, and could belong to a different operator as Router 1.
Regular hosts, such as PCs or other end-user devices, are assumed to
be connected to the Home LAN network fronted by the RG. These hosts
are assumed to have the capacity to perform the correct source and
destination address selection when accessing each of the services.
----Router1---<IP Cloud>---ServerA
/
(Home)----RG-1
\
----Router2---<IP Cloud>---Internet
Figure 1: Example use case.
To obtain the desired routing behaviour RG-1 needs to have a more
specific IP route towards the target service subnet accessible via
Router1, leaving Router2 as the default gateway for all other
destinations. To achieve this the ICMPv6 [RFC4191] mechanism does
provide a solution, however it entails a number of limitations.
Firstly, the operator has no assurance that the RG is actually
capable of correctly interpreting the [RFC4191] route options, since
the RG is unable to signal such capability, nor that each NAS in the
network is capable of generating such messages. Secondly, the
mechanism is applicable only in cases when the operator is willing to
apply and maintain per subscriber/RG configuration directly on NAS
Routers 1 and 2, which is often either administratively difficult or
impossible in cases where the NASes are operated by a 3rd party.
Thirdly, the mechanism presents an operational and troubleshooting
challenge in cases where the IPv6 service is offered alongside IPv4,
Dec, et al. Expires January 13, 2011 [Page 4]
Internet-Draft DHCPv6 Route Options July 2010
given that the analogous IPv4 routing problem may be solved by means
of the DHCPv4 option [RFC3442].
To complete the description of the above scenario it is useful to
note that no new or novel IPv6 routing mechanisms are required by NAS
Routers 1 and 2. E.g. NAS Router 1 and 2 may act as DHCPv6
Delegating Routers and have the home subnet delegated prefix route
installed by means of DHCPv6 Prefix Delegation.
3. DHCPv6 Based Solution
A DHCPv6 based solution is able to address the limitations of the
described ICMPv6 method, by allowing an operator an on demand and RG
specific means of configuring static routing information. Such a
DHCPv6 based solution also fits into network environments where the
operator prefers to manage RG configuration information from a
centralized DHCP server as opposed to doing so on each NAS.
Furthermore, a DHCPv6 based solution can easily co-exist
operationally with the already defined IPv4 solution [RFC3442].
Client interested in obtaining routing information, includes
OPTION_IA_RT in its Option Request Option (ORO). Server provides
requested information using OPTION_IA_RT option.
To convey complex routing information, several nested options are
required. Routing information is conveyed in a single IA_RT option.
It must convey one or more OPTION_NEXT_HOP options that specify next
hop. Each OPTION_NEXT_HOP conveys one or more OPTION_RT_PREFIX
options that represents prefixes reachable via specified next hop.
Formats of OPTION_IA_RT, OPTION_NEXT_HOP and OPTION_RT_PREFIX are
defined in the following sections. Defined options follow similar
approach previously used in IA_NA, IA_TA and IA_PD options
definitions.
Each IPv6 next hop is associated with a one or more prefixes that
share the same next-hop address. This allows the Route Option to
convey both numerous prefixes that map to a common next hop address,
as well as multiple next hop addresses each with their own set of
prefixes.
3.1. Options Extensibility
In previous versions of this draft, informations about routes were
aggregated in a single option. It was determined that such a format
eliminates the ability to add extensions to the routing information
provided. As such, a nested options approach was defined.
Dec, et al. Expires January 13, 2011 [Page 5]
Internet-Draft DHCPv6 Route Options July 2010
The Defined syntax should be treated as a minimal framework necessary
to convey routing related information. There are many possible
parameters that may be defined at a later date. Examples include the
Maximum Transfer Unit (MTU) defined for each prefix and router
preferences.
3.2. Relation To Other Configuration Methods
In terms of all other behaviour, such as the behaviour upon the
failure or re-establishment of a link, or the failure to communicate
with a DHCP server, the client is assumed to follow standard DHCPv6
[RFC3315] behaviour.
4. DHCPv6 Options Format
The Route Option format borrows from that of the Route Information
Option defined in [RFC4191]. The Route Preference field allows a
client to compare the learned prefix to other like prefixes, possibly
learned via other means. Other, host local preference route
mechanisms may also be used. One notable exception with respect to
[RFC4191] 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 events that trigger DHCPv6 state
changes, 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 [RFC4242] is
envisaged.
4.1. DHCPv6 Route Option Format
To separate routing information from other options conveyed in a
DHCPv6 message, DHCPv6 Route Option is defined. Its format is
presented in Figure 2.
The DHCPv6 Route Option 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.
Dec, et al. Expires January 13, 2011 [Page 6]
Internet-Draft DHCPv6 Route Options July 2010
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv6 Routes Option Format
option-code: OPTION_IA_RT (TBD).
option-len: Length of the IA_RT options field.
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.
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.
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.
4.2. Next Hop Option Format
The Next Hop Option defines IPv6 address of the next hop, usually
representing a distinct router. This information is crucial element
of routing information as it defines location of the router. With
each Next Hop address there is associated one or more prefixes
available via that next hop.
Dec, et al. Expires January 13, 2011 [Page 7]
Internet-Draft DHCPv6 Route Options July 2010
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 |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv6 Route Option Format
option-code: OPTION_NEXT_HOP (TBD).
option-len: 16 + Length of NEXT_HOP options field.
IPv6 Next Hop Address: 16 octet long field that specified IPv6
address of the next hop.
NEXT_HOP options: Options associated with this Next Hop. This
includes, but is not limited to, OPTION_RT_PREFIX options
that specify prefixes available via specified next hop.
4.3. Route Prefix Option Format
Route Prefix Option is used to convey information about a single
prefix that represents destination network, reachable via certain
router. Route Prefix Option is used as a sub-option in the
previously defined Next Hop Option.
Dec, et al. Expires January 13, 2011 [Page 8]
Internet-Draft DHCPv6 Route Options July 2010
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 | Reserved |Prf| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Prefix |
| (16 octets) |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. RT_PREFIX options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Route Prefix Option Format
option-code: OPTION_RT_PREFIX (TBD).
option-len: 18 + length of RT_PREFIX options.
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.
Reserved: This 6 bits wide field is currently not used and must be
filled with zeros.
Prf: Route Preference. 2-bit signed integer. The Route
Preference indicates whether to prefer the next hop
associated with this prefix over others, when multiple
identical prefixes (for different next hops) have been
received. The defined preference values are as follows:
01 High
00 Medium (default)
11 Low
Prefix: Fixed length 16 octet field containing an IPv6 prefix.
Dec, et al. Expires January 13, 2011 [Page 9]
Internet-Draft DHCPv6 Route Options July 2010
RT_PREFIX options: Optional options, specific to this particular
prefix. This document does not specify such options.
5. DHCPv6 Server Behavior
If configured to do so, DHCPv6 servers provide Routes Option in
ADVERTISE and REPLY messages to client that requested such option.
During successful operation, server adds at least one Next Hop Option
as suboptions within single Routes Option. Each Next Hop Option must
convey at least one Route Prefix Option.
Servers MUST NOT send Route Option to clients that did not explicitly
requested it, using the ORO.
Server MUST NOT send Route Option in messages other than ADVERTISE or
REPLY.
Server MAY also include Status Code Option, defined in Section 22.13
of the [RFC3315] to indicate status of the operation.
Server MUST include Status Code Option, if routing configuration was
not successful. It SHOULD use status codes defined in [RFC3315] and
[RFC3633].
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.
6. DHCPv6 Client Behavior
A DHCPv6 client compliant with this specification MUST request the
Route Option (option value TBD) in an Option Request Option (ORO), as
described in [RFC3315], by including the Route Option code in the
following messages: Solicit, Request, Renew, Rebind, Information-
Request or Reconfigure.
When processing a received Route Option a client MUST substitute a
0::0 value of the Next Hop Option with the source IPv6 address of the
received DHCPv6 message. It MUST also associate a 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.
Dec, et al. Expires January 13, 2011 [Page 10]
Internet-Draft DHCPv6 Route Options July 2010
DHCPv6 Packets relayed to the client are sourced by the relay using
this relay's IPv6 address, which could be a link local address.
Client SHOULD ask for updated route information every time it sends
REQUEST, RENEW, REBIND, CONFIRM or INFORMATION-REQUEST messages, by
including Route Option code in the ORO it the transmitted message.
Client MAY refresh assigned route information periodically. The
generic DHCPv6 Information Refresh Time Option, as specified in
[RFC4242], 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 route learning mechanism used by or on the
host.
7. IANA Considerations
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.
8. Security Considerations
The overall security considerations discussed in [RFC3315] 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.
9. Acknowledgements
The authors would like to thank Alfred Hines, Ralph Droms, Ted Lemon,
Ole Troan, Dave Oran and Dave Ward for their comments and useful
suggestions.
Dec, et al. Expires January 13, 2011 [Page 11]
Internet-Draft DHCPv6 Route Options July 2010
10. References
10.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.
10.2. Informative References
[I-D.troan-multihoming-without-nat66]
Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D.
Wing, "IPv6 Multihoming without Network Address
Translation", draft-troan-multihoming-without-nat66-00
(work in progress), May 2010.
[RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless
Static Route Option for Dynamic Host Configuration
Protocol (DHCP) version 4", RFC 3442, December 2002.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 4242, November 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
Dec, et al. Expires January 13, 2011 [Page 12]
Internet-Draft DHCPv6 Route Options July 2010
Authors' Addresses
Wojciech Dec
Cisco Systems
Haarlerbergweg 13-19
1101 CH Amsterdam
The Netherlands
Email: wdec@cisco.com
Richard Johnson
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
USA
Email: raj@cisco.com
Tomasz Mrugalski
Gdansk University of Technology
Storczykowa 22B/12
Gdansk 80-177
Poland
Phone: +48 698 088 272
Email: tomasz.mrugalski@eti.pg.gda.pl
Arifumi Matsumoto
NTT PF Lab
Midori-Cho 3-9-11
Musashino-shi, Tokyo, 180-8585
Japan
Phone: +81 422 59 3334
Email: arifumi@nttv6.net
Dec, et al. Expires January 13, 2011 [Page 13]