| Network Working Group | M. Mouton |
| Internet-Draft | A. Petrescu |
| Intended status: Informational | C. Janneteau |
| Expires: February 03, 2012 | CEA, LIST |
| August 02, 2011 |
Default Router List Option for DHCPv6 (DRLO)
draft-mouton-mif-dhcpv6-drlo-00.txt
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).
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 February 03, 2012.
Copyright (c) 2011 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.
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).
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].
This document uses also the terminology defined in [RFC3315], [RFC3963] and [RFC4862].
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.
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| +------+ +------+
In this topology, a client with no IPv6 configuration needs to obtain 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| +------+ +------+ +------+
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.
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 |
|<-------------------------|
| |
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 |
|<-------------------------|<===========================|
| | |
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.
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 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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) . . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As this option contains a list, the pattern containing router_address, router_lifetime, lla_len and optionnaly router_link_layer_address can be repeated.
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:
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 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).
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.
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.
The authors would like to acknowledge the useful technical contribution of Mathias Boc and Sofian Imadali.
Authors appreciate the particularly stimulating discussion about 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.
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.
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.
| [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. |
| [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. |
| [I-D.droms-dhc-dhcpv6-default-router] | Droms, R and T Narten, "Default Router and Prefix Advertisement Options for DHCPv6", Internet-Draft draft-droms-dhc-dhcpv6-default-router-00, March 2009. |
| [I-D.ietf-mif-dhcpv6-route-option] | Dec, W, Mrugalski, T, Sun, T and B Sarikaya, "DHCPv6 Route Options", Internet-Draft draft-ietf-mif-dhcpv6-route-option-03, September 2011. |
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: