[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                        A. Petrescu
Internet-Draft                                                 CEA, LIST
Intended status: Experimental                             K. Pentikousis
Expires: March 23, 2013                              Huawei Technologies
                                                            C. Janneteau
                                                               CEA, LIST
                                                               M. Mouton
                                                University of Luxembourg
                                                      September 19, 2012


              Default Router List Option for DHCPv6 (DRLO)
                  draft-mouton-mif-dhcpv6-drlo-02.txt

Abstract

   This document specifies an experimental DHCPv6 default route option
   which provisions static routing information to client nodes.  The
   option facilitates central configuration of a multi-access client
   node's default router list with the IPv6 address, MAC address, and
   lifetime of the route, which is preferred in certain multi-access
   network environments.  In addition, the DHCP option defined in this
   document can provide operational simplicity in network coverage
   extension scenarios using inexpensive (and limited resource)
   consumer-grade equipment.  Finally, the proposed DHCP option has been
   implemented and tested in practice; its experimental use points to
   benefits with respect to reduced signaling and energy consumption
   compared to existing default route configuration mechanisms.

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 March 23, 2013.

Copyright Notice




Petrescu, et al.         Expires March 23, 2013                 [Page 1]


Internet-Draft         Default Router List Option         September 2012


   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
   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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Applicability and Use Cases  . . . . . . . . . . . . . . . . .  4
     3.1.  Large Mobile Network Use Case  . . . . . . . . . . . . . .  4
     3.2.  Mi-Fi Coverage Extension Use Case  . . . . . . . . . . . .  5
     3.3.  M2M Constrained Device Use Case  . . . . . . . . . . . . .  6
   4.  Pertinence to the MIF Working Group  . . . . . . . . . . . . .  8
   5.  Topologies and Message Exchange Diagrams . . . . . . . . . . .  8
     5.1.  Topologies . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Message Exchange . . . . . . . . . . . . . . . . . . . . .  9
   6.  DHCPv6 Default router list option  . . . . . . . . . . . . . . 10
     6.1.  Option format  . . . . . . . . . . . . . . . . . . . . . . 10
       6.1.1.  Client side  . . . . . . . . . . . . . . . . . . . . . 10
       6.1.2.  Server side  . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  Optimization . . . . . . . . . . . . . . . . . . . . . . . 12
     6.3.  Default router lifetime management . . . . . . . . . . . . 13
   7.  Open issues  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     11.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  ChangeLog . . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16










Petrescu, et al.         Expires March 23, 2013                 [Page 2]


Internet-Draft         Default Router List Option         September 2012


1.  Introduction

   The Neighbor Discovery protocol [RFC4861] is currently considered as
   the best way for providing a default route information to a client in
   IPv6 networks.  Hence it was not considered necessary for DHCPv6
   [RFC3315] to have this feature.  But, recently, certain deployment
   scenarios express a need not to use the neighbor discovery
   autoconfiguration mechanism.

   For example, a distinct trend is shaping up towards centralization in
   network configuration and management.  In this trend, contrary to
   Stateless Address Autoconfiguration (SLAAC) [RFC4862], which requires
   provisioning and distributing configuration information at each
   router, certain configuration information can be centralized in a
   server and then distributed when needed through DHCPv6.  This means
   that, for instance, all subnet configurations can be managed via a
   single configuration database containing all IP prefix information,
   DNS server addresses, timers, and others - in an on demand manner.
   As we will see below, in practice, there are several scenarios where
   the administrator of a large, complex network architecture including
   numerous routers and access points may prefer a more centralized,
   stateful autoconfiguration solution which capitalizes on the
   widespread deployment of DHCPv6 to facilitate operation and
   management for multiaccess networks.  Ease of deployment, operation
   and management are key design consideration for future mobile
   networks (e.g., see [Penti2011] and the references therein).

   This draft specifies an experimental DHCPv6 option which can be used
   to populate the ND Neighbor Cache as pointed to by the ND Default
   Router List (this data is colloquially named "a default router list"
   in the remainder of this document).  This option is similar to the
   DHCPv4 option router [RFC2132].  Contrary to DHCPv4, however, this
   option also provides router lifetime (thus enabling mechanisms such
   as automatic renumbering) and optionally the default router's 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 mobile networks and pertinent
   to multihoming nodes for managing several default routers in order to
   address service continuity issues.

   Using DHCPv6 to provide a default route to a client was previously
   advocated 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.  The route-option draft
   describes 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).  But (1) this draft needs a means
   to communicate the MAC address of the default router, and (2) avoids



Petrescu, et al.         Expires March 23, 2013                 [Page 3]


Internet-Draft         Default Router List Option         September 2012


   to communicate multiple default routers to the same Client.


2.  Terminology

   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].


3.  Applicability and Use Cases

   This section describes use cases relevant to the experimental DHCP
   option proposed in this document and explains how its deployment can
   improve network management.  We explore three use cases, although we
   expect that the solution has other applications as well.  First, we
   discuss the use of the proposed option in a large mobile network
   where the administrator/operator prefers to have centralized control
   of the default routes used by different nodes.  Second, we consider
   the Mi-Fi coverage extension case where the need is to control the
   devices connecting to the mobile network in an ad-hoc manner over
   consumer-grade equipment.  Finally, we look into M2M constrained
   router devices where configuration message exchanges need to be as
   few as possible, in the interest of energy and other network resource
   consumption.  Scenarios like these have been long described in the
   research literature; see, for example [Sollner2008] and the
   references therein.

3.1.  Large Mobile Network Use Case

   There is no doubt that most users today access the Internet over a
   wireless network.  This trend is expected to continue unabated for
   the foreseeable future.  The current generation of mobile networks
   features a largely hierarchical structure, in part due the origins of
   the technologies used in wireless telecommunication networks
   [Penti2011].  Another part has to do with the strong push for
   centralized control for technical and business reasons.  While it is
   expected that more distribution, for example, in mobility management
   is to be expected [I-D.ietf-dmm-requirements], other trends point to
   the need for more centralized network control loops [Cori2012].

   The experimental DHCPv6 option specified in this document is
   applicable to both cases.  In a network where more centralization is
   preferred, multi-mode nodes can receive different default route
   configuration (including route lifetime) with the aid of a



Petrescu, et al.         Expires March 23, 2013                 [Page 4]


Internet-Draft         Default Router List Option         September 2012


   centralized database and DHCPv6, as described in Section Section 5.1.
   This may prove particularly useful for enabling the network to select
   the best default route for multihomed nodes depending on monitoring
   information collected from various network elements.  In addition,
   the network can use the option specified in this document to steer
   traffic from newly attached nodes to a different default router due
   to network maintenance operations.  On the other hand, an IP network
   adopting control/data plane separation for certain mechanisms can
   benefit from the use of this option in some subnets depending on
   several factors.  For instance, we expect that this can ease the
   incremental deployment of the aforementioned mechanisms by
   maintaining a tightly controlled centralized view of the network.

3.2.  Mi-Fi Coverage Extension Use Case

   This use case relates to residential access and, in particular, to
   wireless network extension scenarios, including those involving
   personal portable devices connected to cellular or other wide-area
   networks.  Devices like these, popularly referred to as "Mi-Fi",
   enable a user to take advantage of her cellular subscription, for
   example, and connect other devices to the Internet.  Mi-Fi devices
   can be standalone, i.e. provide no other functionality than acting as
   interconnection points, are typically small in size (hence mobile),
   and tend to be inexpensive.

   Mi-Fi devices have gained in popularity in recent years as they allow
   other Wi-Fi-only devices to be connected to the Internet via a
   cellular network in the absence of Wi-Fi coverage.  For example, a
   Mi-Fi device can connect up to five other devices over its Wi-Fi
   interface to a cellular network.  Typical users carry Mi-Fi devices
   around and often use them to connect very different sets of Wi-Fi
   devices even within the same day.  For instance, a mobile network
   subscriber can use the Mi-Fi device to enable Internet connectivity
   to the user's pad and laptop at home, connect a pod to a streaming
   Internet radio service while the user is in the car to work, and
   offer ad-hoc Internet connectivity to friends and colleagues at an
   IETF meeting.  It may be often desirable to configure different
   default routes through the mobile network.  Note that, in practice,
   said device could be dedicated to the role of providing tethered
   access or it can be a typical multiaccess smartphone extending
   network coverage to neighboring nodes.

   From the network perspective, the operation of all connected nodes
   should be still managed efficiently although connectivity is
   maintained through a low-end consumer device.  This includes the
   default routes as well as IP address lease times.  In this use case,
   the Mi-Fi device does not play the role of a router, but it can act
   as a DHCP relay or a server.  In the former case, the Mi-Fi DHCP



Petrescu, et al.         Expires March 23, 2013                 [Page 5]


Internet-Draft         Default Router List Option         September 2012


   relay agent forwards the request as per usual, indicating its DUID,
   and the default router assignment occurs at the network side
   explicitly as each Wi-Fi device connects to the Mi-Fi-based local
   wireless network.  Alternatively, the Mi-Fi device makes the default
   router assignment locally, based on the configuration information it
   has received using the proposed option.  In either case, the network
   can configure, on demand, different default routes depending on the
   Mi-Fi location and point of attachment to the mobile network.
   Moreover, the network can provide different route lifetimes depending
   on the operational context.  Note that the often battery-powered
   Mi-Fi device should not broadcast connectivity information in order
   to keep power consumption low and reduce information leakage.  In
   short, from the device perspective, power consumption is reduced and
   the Wi-Fi devices do not need any updates, while, from the network
   perspective, the advantages of centralized management are
   significant.

3.3.  M2M Constrained Device Use Case

   For a constrained M2M Gateway it is advantageous to use solely the
   DHCPv6 protocol to configure a default route, an address and a
   delegated prefix, instead of using both protocols ND and DHCPv6.

   Machine-to-Machine communication (M2M) has recently been employed in
   large-scale deployments in various markets such as cellular
   telecommunications, home networking, smart energy management, eHealth
   and vehicular communications.  A machine device is typically a highly
   constrained computing and communicating platform: for example an
   8-bit processor with a GSM module powered by a button cell.  Other,
   more powerful machine devices, include more than a single means of
   communication.  Without going into detail, it is acknowledged that
   whereas many different classes of machine devices exist, their key
   characteristics are generally the following: simplicity, small
   dimensions, low cost, and unattended operation for extended periods
   of time.

   An M2M Gateway is a machine-class device which has two or more
   interfaces.  One of the interfaces has long range wireless data
   capability (e.g., LTE-M).  This Gateway is in charge of obtaining
   Internet connectivity and offering Internet connectivity to other
   machine-class devices.  Since it ought to run unattended for extended
   periods of time, it must be easily auto-configurable.  In other
   words, the most important IP parameters must be configured
   automatically.

   A basic IPv6 configuration includes IPv6 prefix and a default route
   to global Internet.  Devices with limited CPU and memory capacity can
   benefit from the sole presence of a default route in their routing



Petrescu, et al.         Expires March 23, 2013                 [Page 6]


Internet-Draft         Default Router List Option         September 2012


   tables: it is sufficient to store the default route only in order to
   be able to reach any other node in the Internet.  In this sense, the
   default route is a very strong candidate for implementation in small
   devices as it is possible to avoid storing other routes, while still
   maintaining connectivity to every other device in the Internet.
   Using a default route instead of a large number of specific routes
   helps keeping routing table sizes extremely compact, which is
   essential in the case of machine-class devices.

   For these reason, it is important to have a suitable mechanism for
   assigning default routes to end nodes: M2M Device and M2M Gateway.  A
   Gateway can be considered as an emph(almost)-end node: it is situated
   one or a few IP hops away from the end.

   In addition to the IPv6 prefix (for its own interface(s)) and the
   default route to the global Internet, the M2M Gateway needs to be
   configured with an additional IPv6 prefix, call it P. This prefix P
   is to be used by the devices 'behind' the M2M Gateway - each such
   device needs to auto-configure an address for itself.  This prefix P
   is the delegated prefix.

   The currently defined mechanisms to automatically configure the
   triplet [IPv6 address, default route, delegated prefix] to a node,
   such as as the M2M Gateway in our example, are two: Neighbor
   Discovery and DHCPv6 Prefix Delegation.  Hence, two full protocol
   implementations are needed for an M2M Gateway because, on the one
   hand, Neighbor Discovery (ND) cannot delegate prefixes and, on the
   other, DHCPv6 cannot configure default routes.  Some implementers
   find that using two different protocols for obtaining the
   aforementioned triplet is an unnecessary burden for machine-class
   devices: the needs in terms of memory size are almost two times as
   much, the number and size of exchanged messages are almost doubled,
   and so on.  In short, for a constrained M2M Gateway implementation it
   is advantageous to use solely the DHCPv6 protocol to configure a
   default route, an address and a delegated prefix, instead of using
   both ND and DHCPv6.

   It would thus be advantageous to define options for the DHCPv6
   protocol which can be used to assign the missing parameter from the
   triplet (i.e. a default route) to an M2M Gateway, instead of using
   both ND and DHCPv6 to achieve the same task.

   Experiments with an actual implementation, which uses the DHCPv6
   default route proposed in this draft, have shown a reduction in
   message counts from 6 to 4 (when comparing the combined use of DHCPv6
   and ND, versus solely DHCPv6 with the option proposed herein, to make
   the same configuration).




Petrescu, et al.         Expires March 23, 2013                 [Page 7]


Internet-Draft         Default Router List Option         September 2012


4.  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 static default routes (triplets of the form 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.


5.  Topologies and Message Exchange Diagrams

5.1.  Topologies

   This section describes two simple topologies which abstract the use
   cases described above: one involving a server and a client and
   another implying in addition a relay.

   Client/Server topology:


                          +------+        +------+
                          |DHCPv6|--------|DHCPv6|
                          |server|  link  |client|
                          +------+        +------+


                  Figure 1: Simple Client-Server topology

   In this topology, a client with no IPv6 configuration needs to obtain
   an Internet access and does not 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.



Petrescu, et al.         Expires March 23, 2013                 [Page 8]


Internet-Draft         Default Router List Option         September 2012


   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 as in previous figure but the DHCPv6 server is
   not on 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.

5.2.  Message Exchange

   There are two main message exchange scenarios corresponding to the
   use or not of a relay.  The message exchange when the client is not
   on the same link with the server is the following:


                     +------+                     +------+
                     |DHCPv6|                     |DHCPv6|
                     |client|                     |server|
                     +------+                     +------+
                          |                          |
                          |    DHCPv6 Solicit        |
                          |------------------------->|
                          |                          |
                          |    DHCPv6 Advertise      |
                          |<-------------------------|
                          |                          |
                          |    DHCPv6 Request        |
                          |------------------------->|
                          |                          |
                          |    DHCPv6 Reply          |
                          |<-------------------------|
                          |                          |

                 Figure 3: Client-Server message exchange

   A normal exchange between a new Client and a DHCPv6 Server consists
   of 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



Petrescu, et al.         Expires March 23, 2013                 [Page 9]


Internet-Draft         Default Router List Option         September 2012


   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, because the client and the
   server are not on the same link is illustrated in Figure 4.


       +------+                    +------+                     +------+
       |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.


6.  DHCPv6 Default router list option

6.1.  Option format

6.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
   following:








Petrescu, et al.         Expires March 23, 2013                [Page 10]


Internet-Draft         Default Router List Option         September 2012


      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 TBD (to be defined) and/or
   TBA (to be assigned).

6.1.2.  Server side

   The default router list option is illustrated 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 March 23, 2013                [Page 11]


Internet-Draft         Default Router List Option         September 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, while the value 0 SHOULD NOT
           appear, as explained in 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.

6.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 March 23, 2013                [Page 12]


Internet-Draft         Default Router List Option         September 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 (i.e., if there are more than one elements) has
   no link-layer address.  As a matter of fact it has the advantage of
   removing 8 zero bits.  This case occurs each time a network
   administrator does not want to use the 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).

6.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 cache and other related Forwarding
   Information Bases.

   Following [RFC4861] Section 6, this document proposes to limit the
   lifetime to 9000 (decimal) seconds.


7.  Open issues

   In addition to the default router address, lifetime and link-layer
   address, the neighbor discovery mechanism also provides 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.

   The DHCP and Neighbor Discovery protocols manage router lifetime
   differently.  DHCPv6 [RFC3315] specifies lifetimes typically in a
   4-byte field.  On the other hand, the Neighbor Discovery protocol
   defines a 2-byte field for lifetime.  In addition, it defines a
   lifetime limit equaling 9000 making the use of 4-byte fields
   unnecessary.  Because of this, this draft proposes adopts the ND
   approach and includes a 2-byte field for router lifetime.

   The simultaneous use of DHCP and Router Advertisement mechanisms to
   communicate default routes is out of the scope of this specification.


8.  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



Petrescu, et al.         Expires March 23, 2013                [Page 13]


Internet-Draft         Default Router List Option         September 2012


   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.


9.  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.


10.  Acknowledgements

   The authors would like to acknowledge the useful technical
   contribution of Mathias Boc, Sofian Imadali and Arnaud Kaiser.

   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.


11.  References

11.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



Petrescu, et al.         Expires March 23, 2013                [Page 14]


Internet-Draft         Default Router List Option         September 2012


              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.

11.2.  Informative References

   [Cori2012]
              Corici, M I., Hasse, P., Kappler, C., Pentikousis, K.,
              Roth, R., and M. Schramm, "Cost-controlled monitoring
              information collection in heterogeneous mobile network
              infrastructures", Proceedings of the IEEE International
              Conference on Communications Workshops
              (Telecommunications: From Research to Standards), Ottawa,
              Canada , June 2012.

   [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-dmm-requirements]
              Chan, A., "Requirements for Distributed Mobility
              Management", draft-ietf-dmm-requirements-02 (work in
              progress), September 2012.

   [I-D.ietf-mif-dhcpv6-route-option]
              Dec, W., Mrugalski, T., Sun, T., Sarikaya, B., and A.
              Matsumoto, "DHCPv6 Route Options",
              draft-ietf-mif-dhcpv6-route-option-05 (work in progress),
              August 2012.

   [Penti2011]
              Pentikousis, K., "Design considerations for mobility
              management in future infrastructure networks", ITU Telecom



Petrescu, et al.         Expires March 23, 2013                [Page 15]


Internet-Draft         Default Router List Option         September 2012


              World 2011 Technical Symposium, Geneva, Switzerland ,
              October 2011.

   [Sollner2008]
              Sollner, M., Gorg, C., Pentikousis, K., Cabero-Lopez, J
              M., Ponce de Leon, M., and P. Bertin, "Mobility scenarios
              for the Future Internet: The 4WARD approach", Proceedings
              of the 11th International Symposium on Wireless Personal
              Multimedia Communications (WPMC), Saariselk, Finland ,
              September 2008.


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-01.txt to
   draft-mouton-mif-dhcpv6-drlo-02.txt:

   o  New author entry.

   o  Extended and detailed the use cases where this DHCPv6 option may
      be used to communicate a default route.

   o  Explained that this is experimental, an implementation exists and
      a gain in number of messages exchanged has been demonstrated.

   o  Rephrased completely the abstract.

   From draft-mouton-mif-dhcpv6-drlo-00.txt to
   draft-mouton-mif-dhcpv6-drlo-01.txt:

   o  Date change, author ordering and affiliation.


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





Petrescu, et al.         Expires March 23, 2013                [Page 16]


Internet-Draft         Default Router List Option         September 2012


   Kostas Pentikousis
   Huawei Technologies
   Carnotstr. 4
   Berlin,   D-10585
   Germany

   Phone:
   Email: k.pentikousis@huawei.com


   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 March 23, 2013                [Page 17]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/