[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 4, 2009                                 March 3, 2009


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

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 September 4, 2009.

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
   static IPv6 routes on a DHCPv6 client..This improves the ability of
   an operator to configure and influence the client to pick an



Dec & Johnson           Expires September 4, 2009               [Page 1]


Internet-Draft             DHCPv6 Route Option                March 2009


   appropriate route to a destination when the client is multi-homed to
   routers and where other means of route configuration may be
   impractical.  It is primarily envisaged for implementation on a DHCP
   client stack of a broadband Residential Gateway (RG) node.

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.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Route Option  . . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.1.  Appearance of the option in DHCP messages . . . . . . . . . 5
   4.  DHCP Client Behavior  . . . . . . . . . . . . . . . . . . . . . 6
   5.  DHCP Server Behavior  . . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
























Dec & Johnson           Expires September 4, 2009               [Page 2]


Internet-Draft             DHCPv6 Route Option                March 2009


1.  Introduction

   The Neighbor Discover protocol [RFC2461] provides a mechanism
   allowing hosts to discover one or more default router.  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, which allows network administrators to better handle multi-
   homed host topologies.  This mechanism falls short in a few network
   and operational scenarios that are in existence today and where a
   DHCP approach is seen to be preferable.

   This document describes the DHCPv6 Route Option for provisioning
   static IPv6 routes by a DHCPv6 client.  It is primarily envisaged for
   implementation on a DHCP client stack of a broadband Residential
   Gateway (RG) node.


2.  Motivation

   The first motivational scenario is when the network administrator
   needs to dynamically provision static routes from a centrally managed
   repository and on only a subset of hosts or nodes that are connected
   to a multi-access network segment (e.g. a shared VLAN).  This need is
   often driven by operational necessities, such as moving a small group
   of users or performing maintenance on service routers on this network
   segment while using a centrally managed configuration repository.

   A second scenario is when administrative boundaries between network
   operational groups inhibit or prevent the modification of the
   configuration of routers that are attached to the end host or end-
   node network segment.  This is today often found to be the case in
   Layer 3 wholesale set-ups, or where an operator has multiple
   operational groups whose collaboration is some way inhibited.

   Both of these scenarios apply to residential broadband triple-play
   architectures of today, where the host or end-node is otherwise known
   as a Residential Gateway (RG) The RG may be connected via a shared
   VLAN to more than one Network Access Servers (NASes), each of which
   is intended for the delivery of a particular type of service that is
   distinguished by means of IP addresses.  It sometimes is also the
   case that the RG is connected by means of two or more links, each
   link to a different NAS and where the NASes belong to different
   operators or administrative domains.  The basic dynamic provisioning
   of RGs is often administered centrally and effected by means of DHCP
   and no IGPs are used for affecting the RGs routing decisions.

   The figures below depict two scenarios with one or more RG connected
   to different NASes acting as gateways to services S1 and S2..



Dec & Johnson           Expires September 4, 2009               [Page 3]


Internet-Draft             DHCPv6 Route Option                March 2009


             +---NAS-S1                                   ---------NAS-S1
             |                                           /
      RG1----+                                          RG
             |                                           \
      RG2----+                                            ---------NAS-S2
             |
             +---NAS-S2

           Figure 1                                            Figure 2
 RGs with a shared multi-access                             Multi homed RG
            segment

   In the context of these scenarios and today's IPv4 deployments, the
   problem of selecting a NAS in terms of routing from the RG is solved
   by the provisioning of one or more specific static routes on the RG.
   Each route points to the desired IP service subnet and the
   corresponding NAS as the next hop.  Dynamic IGP routing protocols are
   deemed to incur an substantial overhead in terms of equipment costs
   and operational challenges to the operator, without providing a clear
   benefit given that the route to a service generally is trivial and
   only has one valid next hop.  Hence, in order to assist the automated
   provisioning of such more specific routes on the RGs use is made of a
   DHCPv4 mechanism for disseminating classless route information as
   defined in[RFC3442].  In the context of an IPv6 deployment and where
   the [RFC4191] mechanism may not be put into action due to operational
   challenges described, the scenarios call for an analogous dynamic
   host configuration method by which route configuration can be
   effected on the RGs without direct manipulation of the NAS routers
   attached to the RG's network segment.  This translates into a DHCPv6
   route option equivalent to the one defined for DHCPv4.  The adoption
   of such a DHCPv6 extension by an operator already using the DHCPv4
   equivalent has the added benefit of integrating more efficiently in
   existing operational practices.


3.  Route Option

   The server sends the Route Option to a client to covey one or more
   IPv6 routes.  Each IPv6 route consists of an IPv6 prefix of a
   declared bit length and a next hop IPv6 address for the prefix.
   Multiple routes can be present in a single option.  The complete
   option is octet aligned by padding with 0s to the last octet
   boundary.








Dec & Johnson           Expires September 4, 2009               [Page 4]


Internet-Draft             DHCPv6 Route Option                March 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 Length |           Prefix (variable length)            |
      +-+-+-+-+-+-+-+-+                                               .
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                    IPv6 Next Hop Address                      |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code   OPTION_ROUTE (TBD).

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

      Prefix Length
                    8-bit unsigned integer. The length in bits of
                    the IP Prefix, 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.

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

3.1.  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 September 4, 2009               [Page 5]


Internet-Draft             DHCPv6 Route Option                March 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 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 a message, the client MUST
   process the contents of these options in the same way it would if the
   payload of each option were concatenated together and processed as a
   single option.  The client is free to choose the order in which it
   processes individual route options according to its convenience.  If
   the same prefix appears more than once either in a single route
   option or a series of route options, 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



Dec & Johnson           Expires September 4, 2009               [Page 6]


Internet-Draft             DHCPv6 Route Option                March 2009


   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.

   DHCP clients that support the Route Option are expected to use the
   information in selecting the forwarding path, however the method by
   which the preferred path is selected is not part of this
   specification.

   In terms of all other behaviour, such as the behaviour upon the 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 if the server is
   configured to do so.  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 has 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 host implementations are
   deemed sufficient in addressing these problems.






Dec & Johnson           Expires September 4, 2009               [Page 7]


Internet-Draft             DHCPv6 Route Option                March 2009


8.  Acknowledgements

   The authors would like to thank Ralph Droms, Ted Lemon, Dave Oran and
   Dave Ward for their comments and useful suggestions.


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 September 4, 2009               [Page 8]


Internet-Draft             DHCPv6 Route Option                March 2009


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

   Phone:
   Fax:
   Email: raj@cisco.com










































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


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