[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05                                             
Network Working Group                                        W. Dec, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                            T. Mrugalski
Expires: July 14, 2011                   Gdansk University of Technology
                                                                  T. Sun
                                                            China Mobile
                                                             B. Sarikaya
                                                              Huawei USA
                                                        January 10, 2011

                          DHCPv6 Route Option


   This document describes DHCPv6 Route Options for provisioning IPv6
   routes on nodes with DHCPv6 clients.  This is expected to improve the
   ability of an operator to configure and influence a node's ability to
   pick an appropriate route to a destination when this node is multi-
   homed and where other means of route configuration may be

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 July 14, 2011.

Copyright Notice

Dec, et al.               Expires July 14, 2011                 [Page 1]

Internet-Draft             DHCPv6 Route Option              January 2011

   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem overview . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  DHCPv6 Based Solution  . . . . . . . . . . . . . . . . . . . .  4
   4.  DHCPv6 Route Option  . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  DHCPv6 Route Option Format . . . . . . . . . . . . . . . .  5
     4.2.  Next Hop Option Format . . . . . . . . . . . . . . . . . .  6
     4.3.  Route Prefix Option Format . . . . . . . . . . . . . . . .  6
   5.  DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . .  7
   6.  DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  Contributors and .Acknowledgements . . . . . . . . . . . . . .  9
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     10.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Dec, et al.               Expires July 14, 2011                 [Page 2]

Internet-Draft             DHCPv6 Route Option              January 2011

1.  Introduction

   The Neighbor Discovery (ICMPv6) 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 hosts to discover the preferences for
   multiple default routers on a given link, as well as any 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 ND based mechanism
   however is sub optimal or impractical in some multi-homing scenarios,
   where DHCPv6 is seen to be more viable.

   This draft defines the DHCPv6 Route Option for provisioning IPv6
   routes on DHCPv6 clients.  The proposed option is primarily envisaged
   for use by DHCPv6 client nodes that are capable of making basic IP
   routing decisions and maintaining an IPv6 routing table, broadly in
   line with the capabilities of a generic host as described in

   Throughout the document the words node and client are used as a
   reference to the device with such routing capabilities, hosting the
   DHCPv6 client software.  The route information is taken to be
   equivalent to static routing, and limited in the number of required
   routes to a handful.

2.  Problem overview

   The following scenario is used to illustrate the problem as found in
   multi-homed residential access 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 classless route information option
   [RFC3442], or alternative configuration mechanisms.

   In multi-homed networks, a given user's node may be connected to more
   than one gateways.  Such connectivity may be realized by means of
   dedicated physical or logical links that may also be shared with
   other users nodes.  In such multi-homed networks it is quite common
   for the network operator to offer the delivery of a particular type
   of IP service via a particular gateway, where the service can be
   characterised by means of specific destination IP network prefixes.
   Thus, from an IP routing perspective in order for the user node to
   select the appropriate gateway for a given destination IP prefix,
   recourse needs to be made to classic longest destination match IP
   routing, with the node acquiring such prefixes into its routing
   table.  This is typically the remit of dynamic Internal Gateway
   Protocols (IGPs), which however are rarely used by operators in

Dec, et al.               Expires July 14, 2011                 [Page 3]

Internet-Draft             DHCPv6 Route Option              January 2011

   residential access networks.  This is primarily due to operational
   costs and a desire to contain the complexity of user nodes and IP
   Edge devices to a minimum.  While, IP Route configuration may be
   achieved using the ICMPv6 extensions defined in [RFC4191], this
   mechanism does not lend itself to other operational constraints such
   as the desire to control the route information on a per node basis,
   the ability to determine whether a given node is actually capable of
   receiveing/processing such route information.  A preferred mechanism,
   and one that additionally also lends itself to centralized management
   independent of the management of the gateways, is that of using the
   DHCP protocol for conveying route information to the nodes.

3.  DHCPv6 Based Solution

   A DHCPv6 based solution allows an operator an on demand and node
   specific means of configuring static routing information.  Such a
   solution also fits into network environments where the operator
   prefers to manage RG configuration information from a centralized
   DHCP server.  [I-D.troan-multihoming-without-nat66] provides
   additional background to the need for a DHCPv6 solution to the

   In terms of the high level operation of the solution defined in this
   draft, a DHCPv6 client interested in obtaining routing information
   request the route option using the DHCPv6 Option Request Option (ORO)
   sent to a server.  A Server, when configured to do so, provides the
   requested route information as part of a nested options structure
   covering; the next-hop address; the destination prefix; the route
   metric; any additional options applicable to the destination or next-
   hop.  The overall DHCPv6 design follow a similar approach to that
   used in the design of the IA_NA, IA_TA and IA_PD options in [RFC3633]

4.  DHCPv6 Route Option

   A DHCPv6 client interested in obtaining routing information includes
   the OPTION_IA_RT in its DHCPv6 Option Request Option (ORO) sent to a
   server.  A Server, when configured to do so, provides the requested
   route information using the OPTION_IA_RT option.  So as to allow the
   route option to be both extensible, as well as conveying detailed
   info for routes, use is made of a nested options structure.  An IA_RT
   conveys one or more OPTION_NEXT_HOP options that specify the IPv6
   next hop addresses.  Each OPTION_NEXT_HOP conveys in turn one or more
   OPTION_RT_PREFIX options that represents the IPv6 destination
   prefixes reachable via the given next hop.  The Formats of the
   following sub-sections

Dec, et al.               Expires July 14, 2011                 [Page 4]

Internet-Draft             DHCPv6 Route Option              January 2011

   The DHCPv6 Route Option format borrows from the principles of the
   Route Information Option defined in [RFC4191].  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 general events that
   trigger DHCPv6 or route table state changes on a node, 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

4.1.  DHCPv6 Route Option Format

   To separate routing information from other options conveyed in a
   DHCPv6 message, the DHCPv6 Route Option is defined and 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.
      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 1: 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

Dec, et al.               Expires July 14, 2011                 [Page 5]

Internet-Draft             DHCPv6 Route Option              January 2011

   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 the IPv6 address of the next hop, usually
   corresponding to a specific next-hop router.  For each next hop
   address there are one or more prefixes reachable via that next hop.
      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 2: 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

   The Route Prefix Option is used to convey information about a single
   prefix that represents the destination network.  The Route Prefix
   Option is used as a sub-option in the previously defined Next Hop

Dec, et al.               Expires July 14, 2011                 [Page 6]

Internet-Draft             DHCPv6 Route Option              January 2011

      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 |     Metric    |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                            Prefix                             |
     |                          (16 octets)                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     .                                                               .
     .                         RT_PREFIX options                     .
     .                                                               .

                   Figure 3: 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.

   Metric:   Route Metric. 8-bit signed integer.  The Route Metric
             indicates whether to prefer the next hop associated with
             this prefix over others, when multiple identical prefixes
             (for different next hops) have been received.

   Prefix:   Fixed length 16 octet field containing an IPv6 prefix.

   RT_PREFIX options:  Options specific to this particular prefix.

5.  DHCPv6 Server Behavior

   When configured to do so s DHCPv6 server shall provide the Routes
   Option in ADVERTISE and REPLY messages sent to a client that
   requested the route option.  Each Next Hop Option sent by the server
   must convey at least one Route Prefix Option.

   Servers SHOULD NOT send Route Option to clients that did not
   explicitly requested it, using the ORO.

Dec, et al.               Expires July 14, 2011                 [Page 7]

Internet-Draft             DHCPv6 Route Option              January 2011

   Servers MUST NOT send Route Option in messages other than ADVERTISE
   or REPLY.

   Servers MAY also include Status Code Option, defined in Section 22.13
   of the [RFC3315] to indicate the status of the operation.

   Servers MUST include the Status Code Option, if the requested routing
   configuration was not successful and SHOULD use status codes as
   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

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) in
   the following messages: Solicit, Request, Renew, Rebind, Information-
   Request or Reconfigure.  The messages are to be sent as and when
   specified by [RFC3315].

   When processing a received Route Option a client MUST substitute a
   received 0::0 value in the Next Hop Option with the source IPv6
   address of the received DHCPv6 message.  It MUST also associate a
   received 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.  DHCPv6 Packets relayed to the client are sourced
   by the relay using this relay's IPv6 address, which could be a link
   local address.

   The 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 static route learning and maintenance
   mechanism used by, or on the client with one modification: The client
   MUST flush DHCPv6 installed routes following a link flap event on the
   DHCPv6 client interface over which the routes were installed.  This
   requirement is necessary to automate the flushing of routes for

Dec, et al.               Expires July 14, 2011                 [Page 8]

Internet-Draft             DHCPv6 Route Option              January 2011

   clients that may move to a different network.

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

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

   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.  Contributors and .Acknowledgements

   This document would not have been possible without the significant
   support and contribution to its development provided by: Arifumi
   Matsumoto, Hui Deng, Richard Johnson, Zhen Cao.

   The authors would like to thank Alfred Hines, Ralph Droms, Ted Lemon,
   Ole Troan, Dave Oran and Dave Ward for their comments and useful

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.

Dec, et al.               Expires July 14, 2011                 [Page 9]

Internet-Draft             DHCPv6 Route Option              January 2011

   [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

              Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D.
              Wing, "IPv6 Multihoming without Network Address
              Translation", draft-troan-multihoming-without-nat66-01
              (work in progress), July 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.

Authors' Addresses

   Wojciech Dec (editor)
   Cisco Systems
   Haarlerbergweg 13-19
   1101 CH Amsterdam
   The Netherlands

   Email: wdec@cisco.com

   Tomasz Mrugalski
   Gdansk University of Technology
   Storczykowa 22B/12
   Gdansk  80-177

   Phone: +48 698 088 272
   Email: tomasz.mrugalski@eti.pg.gda.pl

Dec, et al.               Expires July 14, 2011                [Page 10]

Internet-Draft             DHCPv6 Route Option              January 2011

   Tao Sun
   China Mobile
   Unit2, 28 Xuanwumenxi Ave
   Beijing, Xuanwu District  100053

   Email: suntao@chinamobile.com

   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075
   United States

   Phone: +1 972-509-5599
   Email: sarikaya@ieee.org

Dec, et al.               Expires July 14, 2011                [Page 11]