Network Working Group W. Dec
Internet-Draft R. Johnson
Intended status: Informational Cisco Systems
Expires: September 4, 2009 March 3, 2009
DHCPv6 Route Option
draft-dec-dhcpv6-route-option-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes the DHCPv6 Route Option for provisioning
static IPv6 routes on a DHCPv6 client..This improves the ability of
an operator to configure and influence the client to pick an
Dec & Johnson Expires September 4, 2009 [Page 1]
Internet-Draft DHCPv6 Route Option March 2009
appropriate route to a destination when the client is multi-homed to
routers and where other means of route configuration may be
impractical. It is primarily envisaged for implementation on a DHCP
client stack of a broadband Residential Gateway (RG) node.
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Route Option . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Appearance of the option in DHCP messages . . . . . . . . . 5
4. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 6
5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Dec & Johnson Expires September 4, 2009 [Page 2]
Internet-Draft DHCPv6 Route Option March 2009
1. Introduction
The Neighbor Discover protocol [RFC2461] provides a mechanism
allowing hosts to discover one or more default router. Extensions to
the protocol defined in [RFC4191]allow the discovery by a host of the
preferences for multiple default routers as well as more specific
routes, which allows network administrators to better handle multi-
homed host topologies. This mechanism falls short in a few network
and operational scenarios that are in existence today and where a
DHCP approach is seen to be preferable.
This document describes the DHCPv6 Route Option for provisioning
static IPv6 routes by a DHCPv6 client. It is primarily envisaged for
implementation on a DHCP client stack of a broadband Residential
Gateway (RG) node.
2. Motivation
The first motivational scenario is when the network administrator
needs to dynamically provision static routes from a centrally managed
repository and on only a subset of hosts or nodes that are connected
to a multi-access network segment (e.g. a shared VLAN). This need is
often driven by operational necessities, such as moving a small group
of users or performing maintenance on service routers on this network
segment while using a centrally managed configuration repository.
A second scenario is when administrative boundaries between network
operational groups inhibit or prevent the modification of the
configuration of routers that are attached to the end host or end-
node network segment. This is today often found to be the case in
Layer 3 wholesale set-ups, or where an operator has multiple
operational groups whose collaboration is some way inhibited.
Both of these scenarios apply to residential broadband triple-play
architectures of today, where the host or end-node is otherwise known
as a Residential Gateway (RG) The RG may be connected via a shared
VLAN to more than one Network Access Servers (NASes), each of which
is intended for the delivery of a particular type of service that is
distinguished by means of IP addresses. It sometimes is also the
case that the RG is connected by means of two or more links, each
link to a different NAS and where the NASes belong to different
operators or administrative domains. The basic dynamic provisioning
of RGs is often administered centrally and effected by means of DHCP
and no IGPs are used for affecting the RGs routing decisions.
The figures below depict two scenarios with one or more RG connected
to different NASes acting as gateways to services S1 and S2..
Dec & Johnson Expires September 4, 2009 [Page 3]
Internet-Draft DHCPv6 Route Option March 2009
+---NAS-S1 ---------NAS-S1
| /
RG1----+ RG
| \
RG2----+ ---------NAS-S2
|
+---NAS-S2
Figure 1 Figure 2
RGs with a shared multi-access Multi homed RG
segment
In the context of these scenarios and today's IPv4 deployments, the
problem of selecting a NAS in terms of routing from the RG is solved
by the provisioning of one or more specific static routes on the RG.
Each route points to the desired IP service subnet and the
corresponding NAS as the next hop. Dynamic IGP routing protocols are
deemed to incur an substantial overhead in terms of equipment costs
and operational challenges to the operator, without providing a clear
benefit given that the route to a service generally is trivial and
only has one valid next hop. Hence, in order to assist the automated
provisioning of such more specific routes on the RGs use is made of a
DHCPv4 mechanism for disseminating classless route information as
defined in[RFC3442]. In the context of an IPv6 deployment and where
the [RFC4191] mechanism may not be put into action due to operational
challenges described, the scenarios call for an analogous dynamic
host configuration method by which route configuration can be
effected on the RGs without direct manipulation of the NAS routers
attached to the RG's network segment. This translates into a DHCPv6
route option equivalent to the one defined for DHCPv4. The adoption
of such a DHCPv6 extension by an operator already using the DHCPv4
equivalent has the added benefit of integrating more efficiently in
existing operational practices.
3. Route Option
The server sends the Route Option to a client to covey one or more
IPv6 routes. Each IPv6 route consists of an IPv6 prefix of a
declared bit length and a next hop IPv6 address for the prefix.
Multiple routes can be present in a single option. The complete
option is octet aligned by padding with 0s to the last octet
boundary.
Dec & Johnson Expires September 4, 2009 [Page 4]
Internet-Draft DHCPv6 Route Option March 2009
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Prefix (variable length) |
+-+-+-+-+-+-+-+-+ .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Next Hop Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_ROUTE (TBD).
option-len 17 + Length of the Prefix field in full octets (includes
any padding).
Prefix Length
8-bit unsigned integer. The length in bits of
the IP Prefix, which also represents the number
of leading bits in the prefix. The value ranges
from 0 to 128.
Prefix
Variable-length field containing the IP Prefix.
IPv6 Next Hop Address
The 128 bit IPv6 address of the next hop to be
used when forwarding towards the IP Prefix.
3.1. Appearance of the option in DHCP messages
The Route option MUST NOT appear in the following DHCP messages:
Solicit, Request, Renew, Rebind, Information-Request and Reconfigure.
A single option can be used to covey multiple routes by means of
successively inserting additional combinations of the prefix and next
hop field. The example below illustrates how two routes, consisting
of Prefix A and Prefix B with two different next hop addresses Next
Hop 1 and Next Hop 2 respectively, can be conveyed within a single
option.
Dec & Johnson Expires September 4, 2009 [Page 5]
Internet-Draft DHCPv6 Route Option March 2009
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix A Length| Prefix A (variable length) |
+-+-+-+-+-+-+-+-+ .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Next Hop Address 1 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix B Length| Prefix B (variable length) |
+-+-+-+-+-+-+-+-+ .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Next Hop Address 2 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. DHCP Client Behavior
A client compliant with this specification SHOULD request the Route
option (option value TBD) in an Options Request Option (ORO) as
described in [RFC3315] by including the Route options' code in the
following messages: Solicit, Request, Renew, Rebind, Information-
Request and Reconfigure.
If more than one route option appears in a message, the client MUST
process the contents of these options in the same way it would if the
payload of each option were concatenated together and processed as a
single option. The client is free to choose the order in which it
processes individual route options according to its convenience. If
the same prefix appears more than once either in a single route
option or a series of route options, with different values for next-
hop, the client SHOULD install separate routes in the routing table
for that prefix, one for each distinct value of next-hop.
When processing the Route option a client MUST substitute a 0::0 IP
next hop address with the source IP address of the received DHCP
message. This is useful in cases where the DHCP server operator
Dec & Johnson Expires September 4, 2009 [Page 6]
Internet-Draft DHCPv6 Route Option March 2009
would like the client to use as a next hop the source IP address of
an intermediate DHCP relay agent, whose address is used in packets
relayed to the client, without the need of identifying this address
explicitly.
DHCP clients that support the Route Option are expected to use the
information in selecting the forwarding path, however the method by
which the preferred path is selected is not part of this
specification.
In terms of all other behaviour, such as the behaviour upon the re-
establishment of a link or the failure to communicate with a DHCP
server, the client is assumed to follow [RFC3315].
5. DHCP Server Behavior
A server MAY send a client the Route Option if the server is
configured to do so. The server SHOULD support sending the option as
part of other DHCP options where such a possibility exists, for
example when sending the route option as part of an IA_NA or IA_PD
option set.
6. IANA Considerations
IANA has assigned a DHCPv6 option number of TBD for the "Route
Option"
7. 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 host implementations are
deemed sufficient in addressing these problems.
Dec & Johnson Expires September 4, 2009 [Page 7]
Internet-Draft DHCPv6 Route Option March 2009
8. Acknowledgements
The authors would like to thank Ralph Droms, Ted Lemon, Dave Oran and
Dave Ward for their comments and useful suggestions.
9. References
9.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.
9.2. Informative References
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[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.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Authors' Addresses
Wojciech Dec
Cisco Systems
Haarlerbergweg 13-19
1101 CH Amsterdam
The Netherlands
Email: wdec@cisco.com
Dec & Johnson Expires September 4, 2009 [Page 8]
Internet-Draft DHCPv6 Route Option March 2009
Richard Johnson
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
USA
Phone:
Fax:
Email: raj@cisco.com
Dec & Johnson Expires September 4, 2009 [Page 9]