[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: April 22, 2010                                 October 19, 2009


                          DHCPv6 Route Option
                    draft-dec-dhcpv6-route-option-02

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

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 22, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document describes the DHCPv6 Route Option for provisioning IPv6
   routes on a DHCPv6 client.  This improves the ability of an operator
   to configure and influence the client to pick an appropriate route to



Dec & Johnson            Expires April 22, 2010                 [Page 1]

Internet-Draft             DHCPv6 Route Option              October 2009


   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) node, 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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Problem overview  . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.1.  Route Option Format . . . . . . . . . . . . . . . . . . . . 5
     3.2.  Appearance of the 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 April 22, 2010                 [Page 2]

Internet-Draft             DHCPv6 Route Option              October 2009


1.  Introduction

   The Neighbor Discover protocol [RFC2461] provides a mechanism
   allowing hosts to discover one or more default routers.  Extensions
   to the protocol defined in [RFC4191] allow the discovery by a host 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.  This mechanism however
   falls short in a few network and operational scenarios that are in
   existence today.

   This document describes the DHCPv6 Route Option for provisioning
   static IPv6 routes by a DHCPv6 client.  It is primarily envisaged for
   use by a broadband Residential Gateway (RG) when connecting to an
   upstream operator's network, 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
   the client is capable of making basic routing decisions and
   maintaining a simple, non-recursive IPv6 routing table.


2.  Problem overview

   Two scenarios are used to illustrate the problem.  (It is also noted
   that the problem is not specific to IPv6).

   Figure 1 illustrates the case of two clients connected to a shared
   link, e.g. an Ethernet VLAN.  Both clients are assumed to have IPv6
   addresses from a global scope and obtain their Internet connectivity
   via Router2 by means of a configured or a discovered default route.
   Client 1 however, unlike Client 2, is intended to run a specific
   application, e.g.  VoIP, that is meant to access ServerA by means of
   Router1 with Server A being otherwise not reachable from the
   Internet.  In addition to the global IP address Client1 may be
   assigned with another IP address of a more restricted scope for the
   purpose of communicating with Server A.

                              +---Router1---<IP Cloud>---ServerA
                              |
                   Client1----+
                              |
                   Client2----+
                              |
                              +---Router2---<IP Cloud>---Internet

                                          Figure 1



Dec & Johnson            Expires April 22, 2010                 [Page 3]

Internet-Draft             DHCPv6 Route Option              October 2009


   The problem in the above scenario comes down to the fact that in
   order to reach Server A, Client1 requires to use a more specific
   route whose next-hop address is Router1.  An ICMPv6 based mechanism
   for disseminating more specific route information, as defined in
   [RFC4191], disseminates this information via the shared link also to
   Client2.  Often the operator wants to avoid this redundant
   dissemination to passing to Client2.  In addition many operators
   prefer to be able to manage specific client route information from a
   centralized repository instead of managing directly such
   configuration on a router, as is required with the ICMPv6 based
   scheme.  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 service, as well as to allow the
   possibility to introduce other routers into the scenario for purposes
   of load sharing.  The requirement for more centralized configuration
   management is often due to administrative boundaries within an
   operator's organization as well as an existing operational practice
   that are in place for IPv4, all of which make router based
   configuration difficult.

   Figure 2 illustrates the case of a single client connected via two
   logical or physical links to Router 1 and Router 2 respectively.
   Once again, Router 1 is the intended gateway for a specific
   application (e.g.  VoIP or NMS), or perhaps access to a private VPN,
   which is otherwise not meant to be reachable via Router2.

                                 ----Router1---<IP Cloud>---ServerA
                                /
                         Client1
                                \
                                 ----Router2---<IP Cloud>---Internet

                                           Figure 2

   To obtain the desired behaviour from the system depicted once again
   there is a need for the client to use a more specific IP route
   towards the target application/server.  Router1 is intended as being
   the gateway for this more specific route, leaving Router2 as the
   default gateway for other destinations.  In this scenario the
   [RFC4191] mechanism provides a solution but one that is only
   applicable in cases when the operator is willing to maintain the
   necessary configuration, which may be on a per subscriber/client
   basis.  As described previously this is often either impractical or
   not possible for operators, especially those that are accustomed to
   resolving the issue for the IPv4 case by means of DHCPv4 and the
   classless route information option as defined in [RFC3442].

   In terms of routing of IPv6 traffic towards the Client by Routers 1



Dec & Johnson            Expires April 22, 2010                 [Page 4]

Internet-Draft             DHCPv6 Route Option              October 2009


   and 2, neither scenario requires any mechanisms for populating their
   routing table other than those commonly used in such access scenarios
   with IPv4, e.g.  Router 1 may have a dynamically configured route
   towards the limited scope address of Client1, while Router2 may only
   have a route corresponding to the Client's global IP address prefix.


3.  Solution

   One possible solution to the presented problem is the introduction of
   dynamic IGP routing protocols between client and Router.  However,
   many network operators deem the use of today's IGPs to incur a
   substantial overhead in terms of equipment and operational costs and
   preference is given towards a simpler, non-topology aware automated
   provisioning solution.  A DHCPv6 Route-Option extension can be seen
   to bring such a capability and supplement the one that already exists
   in 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 an IPv6 prefix
   of a declared bit length (a prefix) and a next hop IPv6 address for
   the prefix.  Multiple prefixes (routes) 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 April 22, 2010                 [Page 5]

Internet-Draft             DHCPv6 Route Option              October 2009


       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.

      Prefix
                    Variable-length field containing the IP Prefix.



3.2.  Appearance of the 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 by means of
   successively inserting additional combinations of the prefix and next
   hop field.  The example below illustrates how two routes, consisting
   of Prefix A and Prefix B with two different next hop addresses Next
   Hop 1 and Next Hop 2 respectively, can be conveyed within a single
   option.




Dec & Johnson            Expires April 22, 2010                 [Page 6]

Internet-Draft             DHCPv6 Route Option              October 2009


        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           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Prefix A Length|           Prefix A (variable length)          |
       +-+-+-+-+-+-+-+-+                                               .
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                    IPv6 Next Hop Address 1                    |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Prefix B Length|           Prefix B (variable length)          |
       +-+-+-+-+-+-+-+-+                                               .
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                    IPv6 Next Hop Address 2                    |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



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



Dec & Johnson            Expires April 22, 2010                 [Page 7]

Internet-Draft             DHCPv6 Route Option              October 2009


   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
   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 a client the Route Option.  The server SHOULD
   support sending the option as part of other DHCP options where such a
   possibility exists, for example when sending the route option as part
   of an IA_NA or IA_PD option set.


6.  IANA Considerations

   IANA would be expected to assigned a DHCPv6 option number of TBD for
   the "Route Option"


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

   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 Ralph Droms, Ted Lemon, Ole Troan,
   Dave Oran and Dave Ward for their comments and useful suggestions.





Dec & Johnson            Expires April 22, 2010                 [Page 8]

Internet-Draft             DHCPv6 Route Option              October 2009


9.  References

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

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

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


Authors' Addresses

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

   Email: wdec@cisco.com














Dec & Johnson            Expires April 22, 2010                 [Page 9]

Internet-Draft             DHCPv6 Route Option              October 2009


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

   Phone:
   Fax:
   Email: raj@cisco.com










































Dec & Johnson            Expires April 22, 2010                [Page 10]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/