Network Working Group A. Petrescu
Internet-Draft C. Janneteau
Intended status: Informational CEA, LIST
Expires: September 13, 2012 M. Mouton
University of Luxembourg
March 12, 2012
Default Router List Option for DHCPv6 (DRLO)
draft-mouton-mif-dhcpv6-drlo-01.txt
Abstract
Neighbor Discovery protocol is currently considered as the best way
for providing a default router to a client in IPv6 networks,
typically using a Default Router List. Hence it was not considered
necessary for DHCPv6 to have this feature. But, recently, some
deployment scenarios expressed a need not to use Neighbor Discovery
mechanisms. This draft specifies a new DHCPv6 option providing data
necessary for a Client's Default Router List (address, lifetime, MAC
address) (indirectly, through the Neighbour Cache).
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 September 13, 2012.
Copyright Notice
Copyright (c) 2012 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
Petrescu, et al. Expires September 13, 2012 [Page 1]
Internet-Draft Default Router List Option March 2012
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Pertinence to the MIF Working Group . . . . . . . . . . . . . 4
4. Scenario description . . . . . . . . . . . . . . . . . . . . . 4
4.1. Topologies . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Message Exchange . . . . . . . . . . . . . . . . . . . . . 5
5. DHCPv6 Default router list option . . . . . . . . . . . . . . 6
5.1. Option format . . . . . . . . . . . . . . . . . . . . . . 6
5.1.1. Client side . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. Server side . . . . . . . . . . . . . . . . . . . . . 7
5.2. Optimization . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Default router lifetime management . . . . . . . . . . . . 9
6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Petrescu, et al. Expires September 13, 2012 [Page 2]
Internet-Draft Default Router List Option March 2012
1. Introduction
Neighbor Discovery protocol [RFC4861] is currently considered as the
best way for providing a default router to a client in IPv6 networks.
Hence it was not considered necessary for DHCPv6 [RFC3315] to have
this feature. But recently, some deployment scenarios express a need
not to use neighbor discovery autoconfiguration mechanism.
This need is justified by configuration management centralization
reasons. Indeed, contrary to Stateless Address Autoconfiguration
(SLAAC) [RFC4862] which needs to be configured in each router, DHCPv6
configuration is centralized in a server; meaning that all subnets
configurations are managed in one configuration file containing all
prefix information, DNS server addresses, timers, etc. Hence, one
administering a large, complex architecture including numerous
routers may prefer a centralized, stateful autoconfiguration solution
like DHCPv6 rather than using SLAAC on each router which is more
difficult to debug and reconfigure. Other cases like multihoming may
require a centralized autoconfiguration mechanism for traffic
optimization reasons.
This draft specifies a new DHCPv6 option. This option provides data
necessary for the ND Neighbor Cache and pointed to by the ND Default
Router List (this data is coloquially named "a default router list"
from here on). This option is similar to DHCPv4 option router
[RFC2132]. Contrary to DHCPv4, however, this option also provides
router lifetime and optionaly router link layer address. Lifetime
and link-layer address are necessary for a coherent implementation of
DHCP and ND data structures. They are particularly useful in the
context of mobility and multihoming for managing several default
routers in order to solve continuity of service issues.
The perspective of using DHCPv6 to provide a default route to a
client was previously mentioned in
[I-D.droms-dhc-dhcpv6-default-router].
Additionally, [I-D.ietf-mif-dhcpv6-route-option] presents a method to
distribute routes, in a generic manner, to DHCP Clients. This draft
does not explicitly treat the default router case, although it does
exhibit a capability to communicate a default route as a particular
case of a route (use destination prefix "::" with prefix length 0,
and address of the default router).
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Petrescu, et al. Expires September 13, 2012 [Page 3]
Internet-Draft Default Router List Option March 2012
document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses also the terminology defined in [RFC3315],
[RFC3963] and [RFC4862].
3. Pertinence to the MIF Working Group
The Multiple Interfaces WG (MIF) is treating of Hosts which have the
ability to attach to multiple networks simultaneously. The WG is
chartered to produce, among other products, extensions to DHCPv6 to
"provision client nodes with small amount of static routing
information".
The mechanism described in this draft, can be used to communicate
several default routes (triplets gw-mac-lifetime) to a single Host
which can have several interfaces.
The distinction among the default routes (once installed on a Client)
can be realized according to various criteria: (1) use a form of
Preferences, new extensions similar to RFC 4191, (2) use the Lifetime
communicated by the mechanism of this draft to distinguish among
default routes according to new rules, (3) use a random function to
pick a default route, (4) use a new interface name in the ORO and in
the Ack to specify which default route uses which interface, (5) use
a new field containing a source address which the Client must use for
a particular default route, and more.
4. Scenario description
4.1. Topologies
This section describes two simple topologies: one involving a server
and a client and another implying in addition a relay.
Client/Server topology:
+------+ +------+
|DHCPv6|--------|DHCPv6|
|server|ethernet|client|
+------+ +------+
Figure 1: Simple Client-Server topology
In this topology, a client with no IPv6 configuration needs to obtain
Petrescu, et al. Expires September 13, 2012 [Page 4]
Internet-Draft Default Router List Option March 2012
an Internet access and doesn't intend to use SLAAC. It asks the
DHCPv6 Server the three necessary settings: an IPv6 address, a
default router address and a DNS server in a solicit message. The
DHCPv6 Server receives this Solicit message and sends back the
parameters necessary fo IPv6 configuration.
Client/Relay/Server topology:
+------+ +------+ +------+
|DHCPv6|--....--|DHCPv6|--------|DHCPv6|
|server|ethernet|relay |ethernet|client|
+------+ +------+ +------+
Figure 2: Simple Client-Relay-Server topology
Again, a client with no IPv6 configuration tries to obtain an
Internet access and doesn't want to use SLAAC. It asks the DHCPv6
server the same way than in previous figure but the DHCPv6 server is
not in the same link. The DHCPv6 relay takes client DHCPv6 message
and delivers it to the server. The server knows that the message is
relayed and send its responses back to the relay.
4.2. Message Exchange
There are two main message exchange scenarios corresponding to the
using or not of a relay. The message exchange when not using a relay
is the following:
+------+ +------+
|DHCPv6| |DHCPv6|
|client| |server|
+------+ +------+
| |
| DHCPv6 Solicit |
|------------------------->|
| |
| DHCPv6 Advertise |
|<-------------------------|
| |
| DHCPv6 Request |
|------------------------->|
| |
| DHCPv6 Reply |
|<-------------------------|
| |
Petrescu, et al. Expires September 13, 2012 [Page 5]
Internet-Draft Default Router List Option March 2012
Figure 3: Client-Server message exchange
A normal exchange between a new Client and a DHCPv6 Server consists
in four messages: Solicit, Advertise, Request, and Reply. In a
Solicit/Request packet a Client lists wanted options in the Option
Request Option (ORO). This option is composed of a list of option
codes. The DHCPv6 Server answers those packets with Advertise/Reply
packets containing values for the options asked by the Client.
The message exchange when using a Relay is illustrated in the figure
below:
+------+ +------+ +------+
|DHCPv6| |DHCPv6| |DHCPv6|
|client| |relay | |server|
+------+ +------+ +------+
| | |
| DHCPv6 Solicit | DHCPv6 Relay-forw |
|------------------------->|===========================>|
| | |
| DHCPv6 Advertise | DHCPv6 Relay-reply |
|<-------------------------|<===========================|
| | |
| DHCPv6 Request | DHCPv6 Relay-forw |
|------------------------->|===========================>|
| | |
| DHCPv6 Reply | DHCPv6 Relay-reply |
|<-------------------------|<===========================|
| | |
Figure 4: Client-Relay-Server message exchange
The relay receives the message from the client and forwards it to the
server in a Relay-forw message. The server replies to the relay with
an advertise/reply message encapsulated in a Relay-reply message.
The content of this message is extracted by the relay and sent to the
client.
5. DHCPv6 Default router list option
5.1. Option format
5.1.1. Client side
In its DHCPv6 requests, the client sends a list of required options
in the option request option (ORO). The format of this option is the
Petrescu, et al. Expires September 13, 2012 [Page 6]
Internet-Draft Default Router List Option March 2012
following:
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_ORO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DHCPv6 option request option field
The proposed option (to fill in the field requested-option-code in
the diagram above) is named in this draft OPTION_DEFAULT_ROUTER_LIST.
It is possible to concatenate this value with several other existing
requested-option-code's.
The value of this code of this option is TBA.
5.1.2. Server side
The default router list option is described below:
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_DEFAULT_ROUTER_LIST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| router_address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| router_lifetime | lla_len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. router_link_layer_address(opt) .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: DHCPv6 default router list option field
As this option contains a list, the pattern containing
router_address, router_lifetime, lla_len and optionnaly
router_link_layer_address can be repeated.
Petrescu, et al. Expires September 13, 2012 [Page 7]
Internet-Draft Default Router List Option March 2012
option-code
OPTION_DEFAULT_ROUTER_LIST (TBA)
option-len
length of the default router list option in bytes. It has a
value of minimum 23 (decimal representation).
router_address
default router IPv6 address (16 bytes)
router_lifetime
16-bit unsigned integer. Router lifetime in units of
seconds. Limit value is 9000 and 0 SHOULD NOT appear
according to section 6 of [RFC 4861].
lla_len
8-bit unsigned integer. The size of the link layer address
of the router in bytes. Equals to 0 if no link layer address
is given.
router_link_layer_address
link layer address of the router. Its length is not known in
advance and need to be inquired in lla_len field. This field
is optional.
This option contains an optional variable length field
router_link_layer_address. Router_address and router_lifetime
field's size are fixed.
There are two alternative possibilities of using router information
in the list:
o Not using router_link_layer_address: DHCPv6 server communicates
router_address and router_lifetime with lla_len equals to 0.
Default router's information is finished at the end of lla_len.
o Using router_link_layer_address: DHCPv6 server communicates
router_address and router_lifetime with lla_len equals to k, where
k is the size of the link-layer address. After the field lla_len
the default router's information is finished after reading k more
bytes.
5.2. Optimization
An optimization is possible: removing lla_len field for the last
element of a default router list when that is not necessary. Prima
facie, one may consider that removing one byte may not be worth the
effort of the implementation complexity. This is why this draft
Petrescu, et al. Expires September 13, 2012 [Page 8]
Internet-Draft Default Router List Option March 2012
proposes to apply this optimization in only one simple but fairly
frequent case: if the last element (i.e. the triplet address-MAC-
lifetime) of a list (if there are more elements) has no link-layer
address. As a matter of fact it has the advantage of removing 8 zero
bits. This case happens each time an administrator doesn't want to
use router_link_layer_address. This case is frequent enough to
justify an optimization. Moreover this optimization has been
implemented and does not require a huge amount of intellectual effort
(around 10 extra lines of code).
5.3. Default router lifetime management
This draft proposes to use default router lifetime in the same manner
as [RFC4861]. This has the following consequences.
When a default router lifetime is equal to 0 it MUST be deleted from
the Default Router list, Neighbor cahce and other related Fowarding
Information Bases.
Following [RFC4861] section 6, this draft propose to limit the
lifetime to 9000 (decimal) seconds.
6. Open issues
In addition of default router address, lifetime and link-layer
address neighbor discovery mechanism also provide MTU, Hop limit,
reachable time, retransmission timer and textual name of the
interface. This information can be defined in other DHCPv6 options
extending this draft, if needed.
DHCP and Neighbor Discovery protocol manage router lifetime
differently. [RFC3315] specifies lifetimes typically in a 4-byte
field. In the opposite, Neighbor Discovery protocol defines a 2-byte
field for lifetime. In addition, it defines a lifetime limit
equalling 9000 making the use of 4-byte fields unnecessary. Because
of this, this draft proposes a 2-byte field for router lifetime.
Simultaneous use of DHCP and Router Advertisement to communicate
default routes is out of the scope of this draft.
7. Acknowledgements
The authors would like to acknowledge the useful technical
contribution of Mathias Boc and Sofian Imadali.
Authors appreciate the particularly stimulating discussion about
Petrescu, et al. Expires September 13, 2012 [Page 9]
Internet-Draft Default Router List Option March 2012
default route and DHCPv6 in the email lists of DHC, MIF and 6MAN
Working Groups.
Recently, Tomasz Mrugalski offered insight about default routes
potentially used by draft-dec-dhcpv6-route-option-02. Mikael
Abrahamsson suggested communicating a source address when discussing
default route and DHCPv6.
This work has been performed in the framework of the ICT project ICT-
5-258512 EXALTED, which is partly funded by the European Union. The
organisations on the source list [CEA] would like to acknowledge the
contributions of their colleagues to the project, although the views
expressed in this contribution are those of the authors and do not
necessarily represent the project.
8. IANA Considerations
The proper working of this extension to DHCPv6 to support default
routers rely on using a unique number for OPTION_DEFAULT_ROUTER_LIST.
In this sense, and when agreed to take on this path, IANA will be
demanded to assign an option code to OPTION_DEFAULT_ROUTER_LIST, if
deemed necessary.
Currently, the local prototype implementation uses the number 66
(decimal) for this field.
9. Security Considerations
Security considerations referring to DHCPv6 are described in
[RFC3315] and other more recent Internet Drafts. The new option
described here should not add new threats. However, it is worth
mentioning that the high importance of a default route (it must work
when everything else fails) represents also a high risk when
successful attacks - if at all - happen.
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.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
Petrescu, et al. Expires September 13, 2012 [Page 10]
Internet-Draft Default Router List Option March 2012
[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.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
10.2. Informative References
[I-D.droms-dhc-dhcpv6-default-router]
Droms, R. and T. Narten, "Default Router and Prefix
Advertisement Options for DHCPv6",
draft-droms-dhc-dhcpv6-default-router-00 (work in
progress), March 2009.
[I-D.ietf-mif-dhcpv6-route-option]
Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6
Route Options", draft-ietf-mif-dhcpv6-route-option-04
(work in progress), February 2012.
Appendix A. ChangeLog
The changes are listed in reverse chronological order, most recent
changes appearing at the top of the list.
From draft-mouton-mif-dhcpv6-drlo-00.txt to
draft-mouton-mif-dhcpv6-drlo-01.txt:
o Date change, author ordering and affiliation.
Petrescu, et al. Expires September 13, 2012 [Page 11]
Internet-Draft Default Router List Option March 2012
Authors' Addresses
Alexandru Petrescu
CEA, LIST
Communicating Systems Laboratory, Point Courrier 173
Gif-sur-Yvette, F-91191
France
Phone: +33(0)169089223
Email: alexandru.petrescu@cea.fr
Christophe Janneteau
CEA, LIST
Communicating Systems Laboratory, Point Courrier 173
Gif-sur-Yvette, F-91191
France
Phone: +33(0)169089182
Email: christophe.janneteau@cea.fr
Maximilien Mouton
University of Luxembourg
Interdisciplinary Center for Security, Reliability and Trust
Luxembourg,
Luxembourg
Phone:
Email: maximilien.mouton@uni.lu
Petrescu, et al. Expires September 13, 2012 [Page 12]