[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: Standards Track                           Cisco Systems
Expires: January 13, 2011                                   T. Mrugalski
                                         Gdansk University of Technology
                                                           A. Matsumoto
                                                              NTT PF Lab
                                                           July 12, 2010

                          DHCPv6 Route Options


   This document describes the DHCPv6 Route Options 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 and where other means of route configuration may be
   impractical.  The options are primarily envisaged for configuring a
   broadband Residential Gateway (RG) router, but are generic enough to
   be used by other types of DHCPv6 clients that have basic host routing

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 January 13, 2011.

Dec, et al.             Expires January 13, 2011                [Page 1]

Internet-Draft            DHCPv6 Route Options                 July 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 Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem overview . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  DHCPv6 Based Solution  . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Options Extensibility  . . . . . . . . . . . . . . . . . .  5
     3.2.  Relation To Other Configuration Methods  . . . . . . . . .  6
   4.  DHCPv6 Options Format  . . . . . . . . . . . . . . . . . . . .  6
     4.1.  DHCPv6 Route Option Format . . . . . . . . . . . . . . . .  6
     4.2.  Next Hop Option Format . . . . . . . . . . . . . . . . . .  7
     4.3.  Route Prefix Option Format . . . . . . . . . . . . . . . .  8
   5.  DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 10
   6.  DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

Dec, et al.             Expires January 13, 2011                [Page 2]

Internet-Draft            DHCPv6 Route Options                 July 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.
   This mechanism however is sub optimal or impractical in multi-homing
   scenarios that are in existence today.  These scenarios are broadly
   presented in detail in [I-D.troan-multihoming-without-nat66], with
   this document focusing on a specific aspect identified therein,
   namely the ability to dynamically provision select multi-homed
   devices with specific IPv6 routes.

   This draft defines the DHCPv6 Route Option for provisioning IPv6
   routes on a DHCPv6 client.  The proposed option is primarily
   envisaged for use by a class of IPv6 routers known as a broadband
   Residential Gateway (RG), found in Digital Subscriber Line (DSL),
   Cable, and Fibre To The Home (FTTH) environments.  It is however
   generic enough to be used by other types of advanced DHCPv6 clients
   that are have basic IPv6 routing capabilities.  It is assumed that
   such a client is capable of making basic IP routing decisions and
   maintaining a simple IPv6 routing table, in line with the
   capabilities of a host, as described in [RFC4191].

   Throughout the document the words RG and client are used as a
   reference to the device with routing capabilities, hosting the DHCPv6
   client software.

2.  Problem overview

   The following exemplary scenario is used to illustrate the problem as
   found in residential broadband 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 or remote configuration

   In residential broadband networks, a given user's routed Residential
   Gateway (RG) may be connected to more than one Network Access Servers
   (NAS).  Such connectivity may be realized by means of dedicated
   physical or logical links from the RG to each NAS (e.g.  Using
   dedicated physical interfaces, or multiple PPP links, or Ethernet
   VLANs that may also be shared with the RGs of other users).  In
   either case a given NAS is intended by the network operator for the
   delivery of a particular type of IP service, where the service can be

Dec, et al.             Expires January 13, 2011                [Page 3]

Internet-Draft            DHCPv6 Route Options                 July 2010

   characterised by means of specific destination IP network prefixes.
   Thus, from an IP routing perspective in order for the RG to select
   the appropriate NAS router as the gateway for a given destination IP
   prefix, recourse needs to be made to classic longest destination
   match IP routing, with the RG learning the relevant prefixes.  An
   issue however is the fact that common dynamic Internal Gateway
   Protocols (IGPs) are rarely used by operators for conveying dynamic
   route information to RGs.  This is due to operational reasons and a
   desire to contain the complexity of RGs and IP Edge devices to a
   minimum.  A preferred mechanism adopted for IPv4 is one of
   dynamically provisioning RGs when these connect to the network, which
   can be done using the DHCPv4 classless route information option

   Figure 1 illustrates the case of a single RG connected via two links
   to NAS Routers 1 and 2 respectively.  NAS Router 1 is the intended
   gateway for a specific application served from ServerA (e.g.  VoIP or
   NMS) whose IP subnet is otherwise not reachable via NAS Router2.  The
   latter NAS is intended to provide connectivity to an Internet
   service, and could belong to a different operator as Router 1.
   Regular hosts, such as PCs or other end-user devices, are assumed to
   be connected to the Home LAN network fronted by the RG.  These hosts
   are assumed to have the capacity to perform the correct source and
   destination address selection when accessing each of the services.

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

                        Figure 1: Example use case.

   To obtain the desired routing behaviour RG-1 needs to have a more
   specific IP route towards the target service subnet accessible via
   Router1, leaving Router2 as the default gateway for all other
   destinations.  To achieve this the ICMPv6 [RFC4191] mechanism does
   provide a solution, however it entails a number of limitations.
   Firstly, the operator has no assurance that the RG is actually
   capable of correctly interpreting the [RFC4191] route options, since
   the RG is unable to signal such capability, nor that each NAS in the
   network is capable of generating such messages.  Secondly, the
   mechanism is applicable only in cases when the operator is willing to
   apply and maintain per subscriber/RG configuration directly on NAS
   Routers 1 and 2, which is often either administratively difficult or
   impossible in cases where the NASes are operated by a 3rd party.
   Thirdly, the mechanism presents an operational and troubleshooting
   challenge in cases where the IPv6 service is offered alongside IPv4,

Dec, et al.             Expires January 13, 2011                [Page 4]

Internet-Draft            DHCPv6 Route Options                 July 2010

   given that the analogous IPv4 routing problem may be solved by means
   of the DHCPv4 option [RFC3442].

   To complete the description of the above scenario it is useful to
   note that no new or novel IPv6 routing mechanisms are required by NAS
   Routers 1 and 2.  E.g.  NAS Router 1 and 2 may act as DHCPv6
   Delegating Routers and have the home subnet delegated prefix route
   installed by means of DHCPv6 Prefix Delegation.

3.  DHCPv6 Based Solution

   A DHCPv6 based solution is able to address the limitations of the
   described ICMPv6 method, by allowing an operator an on demand and RG
   specific means of configuring static routing information.  Such a
   DHCPv6 based solution also fits into network environments where the
   operator prefers to manage RG configuration information from a
   centralized DHCP server as opposed to doing so on each NAS.
   Furthermore, a DHCPv6 based solution can easily co-exist
   operationally with the already defined IPv4 solution [RFC3442].

   Client interested in obtaining routing information, includes
   OPTION_IA_RT in its Option Request Option (ORO).  Server provides
   requested information using OPTION_IA_RT option.

   To convey complex routing information, several nested options are
   required.  Routing information is conveyed in a single IA_RT option.
   It must convey one or more OPTION_NEXT_HOP options that specify next
   hop.  Each OPTION_NEXT_HOP conveys one or more OPTION_RT_PREFIX
   options that represents prefixes reachable via specified next hop.
   defined in the following sections.  Defined options follow similar
   approach previously used in IA_NA, IA_TA and IA_PD options

   Each IPv6 next hop is associated with a one or more prefixes that
   share the same next-hop address.  This allows the Route Option to
   convey both numerous prefixes that map to a common next hop address,
   as well as multiple next hop addresses each with their own set of

3.1.  Options Extensibility

   In previous versions of this draft, informations about routes were
   aggregated in a single option.  It was determined that such a format
   eliminates the ability to add extensions to the routing information
   provided.  As such, a nested options approach was defined.

Dec, et al.             Expires January 13, 2011                [Page 5]

Internet-Draft            DHCPv6 Route Options                 July 2010

   The Defined syntax should be treated as a minimal framework necessary
   to convey routing related information.  There are many possible
   parameters that may be defined at a later date.  Examples include the
   Maximum Transfer Unit (MTU) defined for each prefix and router

3.2.  Relation To Other Configuration Methods

   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 standard DHCPv6
   [RFC3315] behaviour.

4.  DHCPv6 Options Format

   The Route Option format borrows from that of the Route Information
   Option defined in [RFC4191].  The Route Preference field allows a
   client to compare the learned prefix to other like prefixes, possibly
   learned via other means.  Other, host local preference route
   mechanisms may also be used.  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 events that trigger DHCPv6 state
   changes, 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, DHCPv6 Route Option is defined.  Its format is
   presented in Figure 2.

   The DHCPv6 Route Option 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.

Dec, et al.             Expires January 13, 2011                [Page 6]

Internet-Draft            DHCPv6 Route Options                 July 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_IA_RT          |          option-len           |
     |                                                               |
     .                           IA_RT options                       .
     .                                                               .

                    Figure 2: 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
   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 IPv6 address of the next hop, usually
   representing a distinct router.  This information is crucial element
   of routing information as it defines location of the router.  With
   each Next Hop address there is associated one or more prefixes
   available via that next hop.

Dec, et al.             Expires January 13, 2011                [Page 7]

Internet-Draft            DHCPv6 Route Options                 July 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_NEXT_HOP        |          option-len           |
     |                                                               |
     |                    IPv6 Next Hop Address                      |
     |                       (16 octets)                             |
     |                                                               |
     |                                                               |
     |                        NEXT_HOP options                       |
     .                                                               .
     .                                                               .

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

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

Dec, et al.             Expires January 13, 2011                [Page 8]

Internet-Draft            DHCPv6 Route Options                 July 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_RT_PREFIX        |          option-len           |
     | Prefix-Length |  Reserved |Prf|                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                            Prefix                             |
     |                          (16 octets)                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     .                                                               .
     .                         RT_PREFIX options                     .
     .                                                               .

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

   Reserved: This 6 bits wide field is currently not used and must be
             filled with zeros.

   Prf:      Route Preference. 2-bit signed integer.  The Route
             Preference indicates whether to prefer the next hop
             associated with this prefix over others, when multiple
             identical prefixes (for different next hops) have been
             received.  The defined preference values are as follows:

                       01 High

                       00 Medium (default)

                       11 Low

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

Dec, et al.             Expires January 13, 2011                [Page 9]

Internet-Draft            DHCPv6 Route Options                 July 2010

   RT_PREFIX options:  Optional options, specific to this particular
             prefix.  This document does not specify such options.

5.  DHCPv6 Server Behavior

   If configured to do so, DHCPv6 servers provide Routes Option in
   ADVERTISE and REPLY messages to client that requested such option.
   During successful operation, server adds at least one Next Hop Option
   as suboptions within single Routes Option.  Each Next Hop Option must
   convey at least one Route Prefix Option.

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

   Server MUST NOT send Route Option in messages other than ADVERTISE or

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

   Server MUST include Status Code Option, if routing configuration was
   not successful.  It SHOULD use status codes defined in [RFC3315] and

   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), as
   described in [RFC3315], by including the Route Option code in the
   following messages: Solicit, Request, Renew, Rebind, Information-
   Request or Reconfigure.

   When processing a received Route Option a client MUST substitute a
   0::0 value of the Next Hop Option with the source IPv6 address of the
   received DHCPv6 message.  It MUST also associate a 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.

Dec, et al.             Expires January 13, 2011               [Page 10]

Internet-Draft            DHCPv6 Route Options                 July 2010

   DHCPv6 Packets relayed to the client are sourced by the relay using
   this relay's IPv6 address, which could be a link local address.

   Client SHOULD ask for updated route information every time it sends
   including Route Option code in the ORO it the transmitted message.

   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 route learning mechanism used by or on the

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

Dec, et al.             Expires January 13, 2011               [Page 11]

Internet-Draft            DHCPv6 Route Options                 July 2010

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.

   [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-00
              (work in progress), May 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.

Dec, et al.             Expires January 13, 2011               [Page 12]

Internet-Draft            DHCPv6 Route Options                 July 2010

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

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

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

   Arifumi Matsumoto
   NTT PF Lab
   Midori-Cho 3-9-11
   Musashino-shi, Tokyo,   180-8585

   Phone: +81 422 59 3334
   Email: arifumi@nttv6.net

Dec, et al.             Expires January 13, 2011               [Page 13]

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