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

Versions: 00 01 02 03 04 05

Network Working Group                                             W. Dec
Internet-Draft                                                R. Johnson
Intended status: Informational                             Cisco Systems
Expires: September 9, 2010                                 March 8, 2010

                          DHCPv6 Route Option


   This document describes the DHCPv6 Route Option for provisioning IPv6
   routes on a DHCPv6 client.  This is expected to improve the ability
   of an operator to configure and influence a client's ability to pick
   an appropriate route to a destination when this client is multi-homed
   to routers and where other means of route configuration may be
   impractical.  The option is primarily envisaged for configuring a
   broadband Residential Gateway (RG) router, but is generic enough to
   be used by other types of DHCPv6 clients.

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 to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 9, 2010.

Dec & Johnson           Expires September 9, 2010               [Page 1]

Internet-Draft             DHCPv6 Route Option                March 2010

Copyright Notice

   Copyright (c) 2010 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 BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Problem overview  . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.1.  Route Option Format . . . . . . . . . . . . . . . . . . . . 5
     3.2.  Appearance of the route option in DHCP messages . . . . . . 6
   4.  DHCP Client Behavior  . . . . . . . . . . . . . . . . . . . . . 7
   5.  DHCP Server Behavior  . . . . . . . . . . . . . . . . . . . . . 8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

Dec & Johnson           Expires September 9, 2010               [Page 2]

Internet-Draft             DHCPv6 Route Option                March 2010

1.  Introduction

   The Neighbor Discovery 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 the discovery by such hosts of the preferences for multiple
   default routers as well as more 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.
   The mechanism however falls short in a few broadband access network
   and operational scenarios that are in existence today.

   This document presents the operational scenarios for which a DHCP
   based static route provisioning method would be preferred.  It then
   defines the DHCPv6 Route Option for provisioning static IPv6 routes
   on a DHCPv6 client that supports such functionality.  The proposed
   option is primarily envisaged for implementation on a class of IPv6
   router known as a broadband Residential Gateway (RG), found in DSL,
   Cable and FTTH environments, but it is generic enough to be used by
   other types of clients.

   Throughout the document the word client is used to designate the
   device hosting the DHCPv6 client and is intended to be
   interchangeable with the term RG.  It is assumed that such a client
   is capable of making basic IP routing decisions and maintaining a
   simple IPv6 routing table.

2.  Problem overview

   Two scenarios are used to illustrate the problem as found in
   residential broadband access networks.  (It is duly noted that the
   problem is not specific to IPv6).  In general, in such access
   networks a given user's RG may be expected to use a gateway more than
   one Network Access Servers (NAS) when connected by means of an
   Ethernet VLAN that is shared with other users.  Each NAS would
   typically be intended by the operator for the delivery of a
   particular type of service, made accessible to the user of the RG,
   where the service can be characterised by means of IP network
   addresses.  Naturally, the RG can also be connected to each NAS by
   means of two or more links (e.g. using dedicated PPP links).  In such
   networks today, in order for the RG to select the appropriate NAS for
   a given destination IP address, recourse is made to static routing
   (meaning that they are not expected to change), which are actually
   dynamically provisioned upon an RG connecting to the network.  IGPs
   are not commonly used for conveying such route information to RGs due
   to operational reasons and a desire by the operators to maintain RG
   and IP Edge devices complexity to a minimum.

Dec & Johnson           Expires September 9, 2010               [Page 3]

Internet-Draft             DHCPv6 Route Option                March 2010

   Figure 1 illustrates the case of two clients connected to a shared
   Ethernet access VLAN.  Both clients are assumed to have already
   assigned IPv6 addresses of a global scope and obtain their Internet
   connectivity via Router2 by means of a configured or discovered
   default route/router.  In addition to a global IP address Client1 may
   be assigned with another IP address of a provider restricted scope
   (ULA) for the purpose of communicating with specific services such as
   that offered by Server A. Client 1, unlike Client 2, is intended to
   access such a specific service, e.g.  VoIP, hosted on ServerA by
   means of Router1, with Server A being otherwise not reachable from
   the Internet.

                              +---Router1---<IP Cloud>---ServerA
                              +---Router2---<IP Cloud>---Internet

                                          Figure 1

   The problem in the above scenario comes due to the fact that in order
   to reach Server A, Client1 is required to possess a more specific
   route for the address of A as reachable via Router1.  An ICMPv6 based
   mechanism for advertising more specific route information, as defined
   in [RFC4191], disseminates this information via the shared link also
   to Client2 which an operator often wants to avoid.  Furthermore it's
   is also desired to be able to manage per user route information from
   a centralized repository instead of managing such information
   directly on the NAS routers.  The former requirement is driven by the
   desire to provide to each client only the information required for
   their intended role, which may be tied to a specific authorized
   service subscription, as well as to allow the possibility to
   introduce other service-routers into the scenario for load sharing of
   other users.  The requirement for centralized configuration
   management is often due to commercial (e.g.  Layer 3 wholesale) or
   administrative boundaries which make router based configuration
   difficult or impossible.

   Figure 2 illustrates the case of a single client connected via two
   logical or physical links to Router 1 and Router 2 respectively.
   Router 1 is the intended gateway for a specific application on
   ServerA (e.g.  VoIP or NMS) that is otherwise not reachable via

Dec & Johnson           Expires September 9, 2010               [Page 4]

Internet-Draft             DHCPv6 Route Option                March 2010

                                 ----Router1---<IP Cloud>---ServerA
                                 ----Router2---<IP Cloud>---Internet

                                           Figure 2

   Once again, to obtain the desired routing behaviour there is a need
   for Client1 to have a more specific IP route towards the target
   application/server accessible via Router1, leaving Router2 as the
   default gateway for other destinations.  In this set-up the [RFC4191]
   mechanism does indeed provide a solution, but one that is only
   applicable in cases when the operator is willing to maintain the
   necessary per user/RG configuration directly on Routers1 and 2.  As
   per the earlier scenario, this is often either impractical or not
   possible, especially when operators are accustomed to resolving the
   analogous IPv4 routing case by means of DHCPv4 using the classless
   route information option [RFC3442].

   In terms of routing and route installation towards Client1 by Routers
   1 and 2, neither scenario calls for any specific mechanisms other
   than those commonly used in such access scenarios, e.g.  Router 1 may
   have a DHCP PD derived route towards the limited scope IP prefix
   assigned to Client1, while Router2 may have a AAA derived route
   corresponding to the Client1 global IP address prefix.

3.  Solution

   A solution using a DHCPv6 Route-Option can be seen to offer an
   operator to directly configure static routing information on a per
   client basis.  The DHCPv6 solution fits also readily into a network
   environment where the operator has no means of directly configuring
   the first hop NAS routers and/or maintain per user configuration
   therein, preferring to manage such information from a centralized
   DHCP server.  Furthermore, the solution can easily integrate
   operationally alongside similar functionality that may already used
   be for IPv4, namely DHCPv4[RFC3442].

3.1.  Route Option Format

   A DHCPv6 server sends the Route Option to a DHCPv6 client to convey
   one or more IPv6 routes.  Each IPv6 route consists of a 128-bit next
   hop IPv6 address for one or more IPv6 prefixes of a declared bit
   length (a prefix).  Multiple prefixes can be present in a single
   option, when sharing the same next hop address.  The complete option
   is octet aligned by padding with 0s to the last octet boundary.

Dec & Johnson           Expires September 9, 2010               [Page 5]

Internet-Draft             DHCPv6 Route Option                March 2010

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      |         OPTION_ROUTE          |          option-len           |
      |                                                               |
      |                    IPv6 Next Hop Address                      |
      |                                                               |
      |                                                               |
      | Prefix Length |           Prefix (variable length)            |
      +-+-+-+-+-+-+-+-+                                               .
      .                                                               .
      .                                                               .

      option-code   OPTION_ROUTE (TBD).

      option-len    17 + Length of the Prefix field in full octets (includes
                    any padding).

      IPv6 Next Hop Address
                    The 128 bit IPv6 address of the next hop to be
                    used when forwarding towards the IP Prefix(es).

      Prefix Length
                    8-bit unsigned integer. The length in bits of
                    the directly following IP Prefix directly following,
                    which also represents the number of leading bits in the
                    prefix. The value ranges from 0 to 128.

                    Variable-length field containing the IP Prefix.

3.2.  Appearance of the route option in DHCP messages

   The Route option MUST NOT appear in the following DHCP messages:
   Solicit, Request, Renew, Rebind, Information-Request and Reconfigure.

   A single option can be used to covey multiple routes for the same
   next hop by means of successively inserting additional combinations
   prefix-length and prefix fields.  Separate options are to be used for
   routes not sharing the same next-hop.

   The example below illustrates how two routes, consisting of Prefix A
   and Prefix B with the same next hop addresses Next Hop 1 and can be

Dec & Johnson           Expires September 9, 2010               [Page 6]

Internet-Draft             DHCPv6 Route Option                March 2010

   conveyed by a single route-option.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |         OPTION_ROUTE          |          option-len           |
       |                                                               |
       |                    IPv6 Next Hop Address 1                    |
       |                                                               |
       |                                                               |
       |Prefix A Length|           Prefix A (variable length)          |
       +-+-+-+-+-+-+-+-+                                               .
       .                                                               .
       .                                                               .
       |Prefix B Length|           Prefix B (variable length)          |
       +-+-+-+-+-+-+-+-+                                               .
       .                                                               .
       .                                                               .

4.  DHCP Client Behavior

   A DHCPv6 client compliant with this specification SHOULD request the
   Route option (option value TBD) in an Options Request Option (ORO),
   as described in [RFC3315], by including the Route options' code in
   the following messages: Solicit, Request, Renew, Rebind, Information-
   Request and Reconfigure.

   If more than one route option appears in the same DHCPv6 message, the
   client MUST process the options in the same way as if the information
   was received in a single route option.  If the same prefix appears
   more than once but with different values for next- hop, the client
   SHOULD install separate routes in the routing table for that prefix,
   one for each distinct value of next-hop.

   When processing the Route option a client MUST substitute a 0::0 IP
   next hop address with the source IP address of the received DHCP
   message.  This is useful in cases where the DHCP server operator
   would like the client to use as a next hop the source IP address of
   an intermediate DHCP relay agent, whose address is used in packets
   relayed to the client, without the need of identifying this address
   explicitly.  Given that next-hop address is likely to be an IPv6
   Link-local address, the client MUST associate the route with the

Dec & Johnson           Expires September 9, 2010               [Page 7]

Internet-Draft             DHCPv6 Route Option                March 2010

   interface on which the client received the DHCPv6 message containing
   the route option.

   In terms of all other behaviour, such as the behaviour upon the
   failure or re-establishment of a link ,or the failure to communicate
   with a DHCP server, the client is assumed to follow [RFC3315].

5.  DHCP Server Behavior

   A server MAY send one of more Route Options to the client.  The
   server SHOULD support sending the option(s) as part of other DHCP
   options where such a possibility exists, for example when sending the
   route option(s) as part of an IA_NA or IA_PD option set.

6.  IANA Considerations

   A DHCPv6 option number of TBD for the "Route Option" is required to
   be assigned by IANA.

7.  Security Considerations

   The overall security considerations discussed in [RFC3315] apply also
   to this document.  The Route option could be used by malicious
   parties to misdirect traffic sent by the client either as part of a
   denial of service or man-in-the-middle attack.  An alternative denial
   of service attack could also be realized by means of using the route
   option to overflowing any known memory limitations of the client, or
   to exceed the client's ability to handle the number of next hop

   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.

8.  Acknowledgements

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

9.  References

Dec & Johnson           Expires September 9, 2010               [Page 8]

Internet-Draft             DHCPv6 Route Option                March 2010

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

9.2.  Informative References

   [RFC3442]  Lemon, T., Cheshire, S., and B. Volz, "The Classless
              Static Route Option for Dynamic Host Configuration
              Protocol (DHCP) version 4", RFC 3442, December 2002.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, November 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [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
   Cisco Systems
   Haarlerbergweg 13-19
   1101 CH Amsterdam
   The Netherlands

   Email: wdec@cisco.com

   Richard Johnson
   Cisco Systems
   170 W. Tasman Dr.
   San Jose, CA  95134

   Email: raj@cisco.com

Dec & Johnson           Expires September 9, 2010               [Page 9]

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