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

Versions: 00 01 02 03 04 05

Network Working Group                                             W. Dec
Internet-Draft                                                R. Johnson
Intended status: Informational                             Cisco Systems
Expires: August 20, 2009                               February 16, 2009


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

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 August 20, 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
   (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.

Abstract

   This document describes the DHCPv6 Route Option for communicating
   IPv6 routes to a DHCP client.  This improves the ability of an



Dec & Johnson            Expires August 20, 2009                [Page 1]


Internet-Draft             DHCPv6 Route Option             February 2009


   operator to influence the a client host to pick an appropriate route
   to a destination when the client is multi-homed or where other means
   of route configuration may be impractical.

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


























Dec & Johnson            Expires August 20, 2009                [Page 2]


Internet-Draft             DHCPv6 Route Option             February 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 of preferences
   for the multiple default routers as well as more specific routes
   which allows network administrators to better handle multi-homed host
   topologies.

   The above cited mechanisms however fall short in network environments
   where the network administrator needs to dynamically configure
   specific routes on only a subset of clients hosts that are connected
   to a multi-access network segement (e.g. a shared VLAN).  Similarly,
   the mechanisms are also not adequate in situations where
   administrative boundaries between network operational groups inhibit
   or prevent the configuration of routers that are attached to the end
   host network segment.

   In effect the above problems call for a dynamic host configuration
   method by that can be effected without direct manipulation of routers
   attached to the host's segement, in effect thus a DHCPv6 method
   analogous to that defined for DHCPv4 in [RFC3442].  The definition of
   an such a DHCPv6 extension has the added benefit of being able to
   provide operational simplification in networks where the DHCPv4
   method is already in use and DHCPv6 is being deployed.

   This document describes the DHCPv6 Route Option for communicating
   IPv6 routes to a DHCPv6 client.  This improves the ability of an
   operator to influence the client host to pick a route when the client
   is multi-homed or where other means of route discovery or
   configuration are impractical.

   The assumption carried in this document is that the next-hop address
   used in the route description is either an address that is well known
   to the operator (eg by means of static IP address configuration on a
   router) or one that is easily derivable from the DHCP messaging.


2.  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.  No octet
   alignment is done within the contents of the option, however the
   complete option is octet aligned by padding with 0s to the next octet
   boundary




Dec & Johnson            Expires August 20, 2009                [Page 3]


Internet-Draft             DHCPv6 Route Option             February 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.

      Prefix Length
                    8-bit unsigned integer.  The number of leading bits in
                    the IP Prefix that are valid.  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.

2.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
   succesively 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 August 20, 2009                [Page 4]


Internet-Draft             DHCPv6 Route Option             February 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                    |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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

   In case of multiple route options being received in a single DHCP
   transaction, the client MUST NOT allow further occurrences of the
   route option to nullify the effect of previous occurrences of the
   option.  A client receiveing in the same transaction two or more
   routes for the same destination prefix but with different next hop
   addresses should consider both routes valid and depending on the
   client's capability utilize all such routes.

   So as to facilitate the reconfiguration of routes, a client MUST be
   capable treating the reception of Route Options in another DHCP
   transaction as overriding any previous set.

   DHCP clients that support the Route option are expected to use the



Dec & Johnson            Expires August 20, 2009                [Page 5]


Internet-Draft             DHCPv6 Route Option             February 2009


   information in selecting the forwarding route by the host.  The
   client however needs to perform some basic prefix sanity checking
   before using any such route(s).  In particular the following prefixes
   and next-hop field addresses are ones for which the host MUST NOT
   install a route for, and consider them invalid:

      - A prefix or next hop address corresponding to any of the host's
      local node addresses (i.e. when a full /128 route option prefix is
      equal to a local interface address)

      - A destination prefix corresponding to the unspecified address
      (0::0/128)

      - A destination prefix or next hop address corresponding to the
      Loopback Address (::1/128)

      - A destination prefix that falls in the link local address or
      site local address range (FE::/9)

      - A destination prefix or next -hop address that falls in the
      multicast addresses range (FF::/8)

   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.


4.  DHCP Server Behavior

   A server MAY send a client the Route option if the server is
   configured to do so.  The option MAY be sent as part of other DHCP
   options where such a possibility exists.  For example the route
   option may be sent as part of the IA_NA and IA_PD option set, with
   the semantics of the parent option unaffected.

   A server is allowed to use an all 0s (0::0) next-hop address to
   indicate that the next-hop address is to be derived by the client
   from the source IP address of the received DHCP message.


5.  IANA Considerations

   IANA has assigned a DHCPv6 option number of TBD for the "Route
   Option"







Dec & Johnson            Expires August 20, 2009                [Page 6]


Internet-Draft             DHCPv6 Route Option             February 2009


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

   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.


7.  Acknowledgements


8.  References

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

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







Dec & Johnson            Expires August 20, 2009                [Page 7]


Internet-Draft             DHCPv6 Route Option             February 2009


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
   USA

   Phone:
   Fax:
   Email: raj@cisco.com































Dec & Johnson            Expires August 20, 2009                [Page 8]


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