Relay-Supplied DHCPv6 Precedence Options
draft-reddy-mif-dhcpv6-precedence-ops-00

MIF Working Group                                               T. Reddy
Internet-Draft                                                  P. Patil
Intended status: Standards Track                                 D. Wing
Expires: April 16, 2012                                            Cisco
                                                        October 14, 2011

                Relay-Supplied DHCPv6 Precedence Options
                draft-reddy-mif-dhcpv6-precedence-ops-00

Abstract

   Network configuration of hosts is currently relatively static with
   little consideration of dynamic network characteristics.  The network
   infrastructure is aware of dynamic network characteristics.  This
   specification extends DHCPv6 so that the DHCPv6 relay agent can
   influence a host's configuration.

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 April 16, 2012.

Copyright Notice

   Copyright (c) 2011 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

Reddy, et al.            Expires April 16, 2012                 [Page 1]
Internet-Draft  Relay-Supplied DHCPv6 Precedence Options    October 2011

   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  IPv6 Multihoming . . . . . . . . . . . . . . . . . . . . .  3
     3.2.  Disabling IPv6 Temporary Addresses . . . . . . . . . . . .  4
       3.2.1.  Avoiding Excessive IP-Based Authentication . . . . . .  5
       3.2.2.  Reducing Management Impact . . . . . . . . . . . . . .  5
   4.  Options  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Relay-Supplied Prefix Option . . . . . . . . . . . . . . .  6
     4.2.  Absolute Precedence Option . . . . . . . . . . . . . . . .  7
   5.  Relay Agent Behaviour  . . . . . . . . . . . . . . . . . . . .  8
   6.  DHCPv6 Server Behaviour  . . . . . . . . . . . . . . . . . . .  9
     6.1.  Relay-Supplied Prefix Option . . . . . . . . . . . . . . .  9
     6.2.  Absolute Precedence Option . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Reddy, et al.            Expires April 16, 2012                 [Page 2]
Internet-Draft  Relay-Supplied DHCPv6 Precedence Options    October 2011

1.  Introduction

   DHCPv6 allows relatively static information to be configured in
   hosts, which is somewhat limiting.  On a dynamic network, the DHCPv6
   relay agent can observe characteristics of a network -- such as IPv6
   multihoming which might be temporarily unavailable or need load
   balancing of traffic towards each upstream ISPs.  By including
   additional information in relayed DHCPv6 messages, the DHCPv6 relay
   agent can influence the DHCPv6 server to provide answers that are
   better suited to the host's configuration on the network.

   In this document we propose new DHCPv6 options to be added by the
   DHCPv6 relay agent when it generates a Relay-Forwarded message.
   These new DHCPv6 options convey information about the host and about
   dynamic network characteristics to influence the DHCPv6 server to
   generate a reply that is appropriate for that host and the current
   network characteristics.

   An initial desire is to influence the DHCPv6 server's responses that
   modify the host's address policy table
   [I-D.ietf-6man-addr-select-opt] based on observed network
   characteristics.

2.  Terminology

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

3.  Usage Scenarios

   The DHCPv6 extension described in this document is useful with IPv6
   multihoming and with IP address-based authentication.

3.1.  IPv6 Multihoming

   There are two multihoming scenarios where the Absolute Precedence
   option is useful.

   The first scenario is in multihoming with provider-aggregatable (PA)
   address space, a host is given an IPv6 address from each ISP.  It is
   often desirable to provide some load balancing between those ISPs.
   This can be accomplished by the relay agent using the Absolute
   Precedence option described in the document.  The relay agent can add
   an Absolute Precedence option to the DHCPv6 request suggesting the
   desired source prefix and prioritized destination prefixes as per the

Reddy, et al.            Expires April 16, 2012                 [Page 3]
Internet-Draft  Relay-Supplied DHCPv6 Precedence Options    October 2011

   network's load balancing schema.  ISP destination prefixes can be
   prioritized by setting Precedence value in the Absolute Precedence
   option, i.e the prefix with higher precedence will be preferred over
   the prefix with lower precedence.

   The second scenario is when a private link exists between two
   businesses, it can be desirable for certain high-value traffic to use
   that link rather than using the Internet.  To use this link, the host
   needs to prefer the IPv6 prefix that causes its traffic to be routed
   on that link.  Policy may influence which hosts are supposed to use
   that link (e.g., access type, time of day).

   For example consider two sites, A and B, which are connected to the
   Internet and also have a private, high-speed link between them.  Site
   A has prefix 2001:aaaa:aaaa::/48 from the high-performance network
   and prefix 2007:0:aaaa::/48 from its Internet-connected service
   provider.  Site B has prefix 2001:bbbb:bbbb::/48 from the high-
   performance network and prefix 2007:0:bbbb::/48 from its Internet-
   connected service provider.  The high-performance ISP is expensive
   and the two sites wish to use it only for their business-critical
   traffic with each other.  All hosts have two IPv6 addresses and two
   AAAA records in DNS.  Using the new DHCPv6 options described in this
   document, the DHCP relay agent would determine a host should be
   allowed to use the high-performance link, so the DHCPv6 relay agent
   would add the Absolute Precedence Option to the DHCPv6 request from
   that host.  The Absolute Precedence Option would set a higher
   precedence for the high-speed prefix, destination prefix 2001:bbbb:
   bbbb::/48.  This would request the DHCPv6 server return a response
   that influences the host's prefix policy table.

   Discussion: The second scenario seems solvable by grouping hosts into
   separate VLANs.  However, this is undesirable because segregating
   using VLANs becomes cumbersome with a large number of VLANs.  It also
   required to configure static policy tables in the DHCPv6 server for
   each VLAN, which is not commonly done today.  This problem can be
   better solved using the Absolute Precedence option defined in this
   document.  Based on various attributes, the relay agent could add an
   Absolute Precedence option to the DHCPv6 request indicating the
   desired source prefixes to be assigned based on the host
   characteristics and destination prefixes with precedence value set
   accordingly to pick the right link thus providing a cleaner solution
   to the problem.

3.2.  Disabling IPv6 Temporary Addresses

Reddy, et al.            Expires April 16, 2012                 [Page 4]
Internet-Draft  Relay-Supplied DHCPv6 Precedence Options    October 2011

3.2.1.  Avoiding Excessive IP-Based Authentication

   Some managed networks authenticate hosts with an authentication
   supplicant or, for hosts lacking the supplicant, address-based
   authentication.  When Address-based authentication is used, re-
   authentication occurs for each address obtained by the host, which
   can create a lot of authentication transactions.  To reduce this
   chatter, it can be useful to disable IPv6 Privacy Addresses [RFC4941]
   on those hosts using address-based authentication.

   The relay agent may be configured with the external prefixes that
   will be assigned to the host.  In that case, the relay agent would
   use the Absolute Prefecedence option.  In the case where the relay
   agent is unaware of the external prefixes that will be assigned to
   the host, the relay agent uses the Relative Precedence option.
   Details for processing those options are described later in the
   document.

   Whenever either of those options is used, a DHCPv6 server that
   understands those options will ignore the IA_TA options in the DHCPv6
   request, effectively disabling the use of temporary addresses for
   that host.

3.2.2.  Reducing Management Impact

   In addition, there are known issues in managing privacy extensions in
   certain scenarios.  These are described in managing privacy
   extensions [I-D.gont-6man-managing-privacy-extensions].  In such
   scenarios, conditionally disabling temporary addresses allows
   administrators to better manage deployments.

4.  Options

   To realize the functions described above, this document defines two
   new DHCPv6 options, Relay-Supplied Prefix and Absolute Precedence.
   These DHCPv6 options are added by the DHCPv6 relay agent when it
   relays a DHCPv6 message, and both MAY appear together in the same
   DHCPv6 message.

Reddy, et al.            Expires April 16, 2012                 [Page 5]
Internet-Draft  Relay-Supplied DHCPv6 Precedence Options    October 2011

      DHCPv6 Client        DHCPv6 Relay Agent           DHCPv6 Server
            |                    |                              |
            |------------------->|                              |
            |  DHCPv6 REQUEST    |                              |
            |                    |                              |
            |      (adds Relay-Supplied Prefix and/or           |
            |   Absolute Precedence Option to the request)      |
            |                    |                              |
            |                    |----------------------------->|
            |                    | DHCPv6 REQUEST with          |
            |                    | Relay-Supplied Prefix and/or |
            |                    | Absolute Precedence Options  |
            |                    |                              |
            |                    |<-----------------------------|
            |                    | DHCPv6 REPLY                 |
            |<-------------------|                              |
            |  DHCPv6 REPLY      |                              |

             Figure 1: Message Flow, Relay Agent adding Option

   Relay-Supplied Prefix option carries host and network information
   observed by the DHCPv6 relay agent such as host does not support
   802.1x supplicant and will be subjected to web-authentication.  The
   Absolute Precedence option allows prioritizing among a list of
   prefixes the DHCPv6 relay agent expects the DHCPv6 server to provide
   to the host, useful for load balancing among multiple IPv6 prefixes.
   Absolute Precedence can also be used to assign different prefixes to
   hosts using the same VLAN ID based on the host characteristics like
   device type, health of the host, access type, etc.

4.1.  Relay-Supplied Prefix Option

   The Relay-Supplied Prefix option is defined below:

      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_RS_PREFIX    |          option-len                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Policy flag   |         Reserved                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Option Type 1 message format

Reddy, et al.            Expires April 16, 2012                 [Page 6]
Internet-Draft  Relay-Supplied DHCPv6 Precedence Options    October 2011

   option-len:  Length of the option.

   Policy flag:   8-bit unsigned integer.

   Reserved:  Must be 0 and ignored by the server.

   The Policy Flag is defined below, and the actions taken by the DHCPv6
   server based on this flag are described in Section 6.

   +------+------------------------------------------------------------+
   |Value | Name               | Description                           |
   +------+------------------------------------------------------------+
   | 0x01 | IPV6_DIS_TEMP_ADDR | Disable IPv6 Temporary Address        |
   +------+------------------------------------------------------------+

                       Figure 3: Policy flag Values

4.2.  Absolute Precedence Option

   The layout of the Absolute Precedence is below:

      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_ABSOLUTE_PRECEDENCE   |          option-len           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Precedence   | Prefix Length |N|        Reserved2            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                          Prefix                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Precedence   | Prefix Length |N|        Reserved2            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                          Prefix                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4: Option Type 2 message format

   The fields are described below:

Reddy, et al.            Expires April 16, 2012                 [Page 7]
Internet-Draft  Relay-Supplied DHCPv6 Precedence Options    October 2011

   option-len:  Option Length

   Precedence:  An 8-bit unsigned integer.  This value is used for
      sorting destination addresses.

   Prefix Length:  8-bit unsigned integer.  The number of leading bits
      in the Prefix that are valid.

   N: A value of 1 indicates that the relay agent wants the DHCPv6
      server to ignore any IA_TA options in the DHCPv6 request, as if
      the IA_TA options were not present.  This effectively disables
      privacy extensions [RFC4941].  A value of 0 indicates the IA_TA
      options, if present in the DHCPv6 request, are processed normally
      by the DHCPv6 server.  This value has no impact on destination
      prefixes.

   Prefix:  A variable-length field containing the prefix of an IPv6
      address.

   Reserved2:  Must be 0 and ignored by the server.

5.  Relay Agent Behaviour

   DHCPv6 relay agents that implement this specification MUST be
   configurable for sending the Relay-Supplied Prefix option and the
   Absolute Precedence option.  Relay agents SHOULD have separate
   configuration for each option to determine if it is to be added to
   DHCPv6 request.  A relay agent will include these options in the
   option payload of a Request message.  DHCPv6 relay agent should set
   Relay-Supplied Prefix option when it receives DHCPv6 request from a
   host with specific characteristics like authenticated using address
   based mechanism.  Relative Precedence option is used when the relay
   agent is unaware of the external prefixes to be assigned to the host.
   DHCPv6 relay agent should set Absolute Precedence when there is a
   need to change the precedence value for prefixes in scenario's
   discussed in Section 3.1 and/or disable IPv6 temporary addresses for
   the host.

      Discussion: To reduce end-user configuration of the DHCPv6 relay
      agent, the DHCPv6 relay agent can use the mechanism specified in
      [RFC3633] to automatically learn the IPv6 prefixes that will be
      delegated to DHCPv6 clients.  DHCPv6 relay agent in future can use
      leasequery-like capability discussed in section 3.2 of RFC
      [RFC5007] to learn the prefix information from DHCPv6 server.

Reddy, et al.            Expires April 16, 2012                 [Page 8]
Internet-Draft  Relay-Supplied DHCPv6 Precedence Options    October 2011

6.  DHCPv6 Server Behaviour

   Upon receiving a DHCPv6 request containing the Relay-Supplied Prefix
   Option or the Absolute Precedence Option, the DHCPv6 server
   processing is described below:

6.1.  Relay-Supplied Prefix Option

   The Relay-Supplied Prefix Option contains flags that defines the
   characteristics of the host.

   1.  IPV6_DIS_TEMP_ADDR - This flag indicates that Temporary IPv6
       address allocation is to be disabled for the host.  The DHCPv6
       server should ignore any IA_TA options in the DHCPv6 request.

6.2.  Absolute Precedence Option

   Absolute Precedence Option - The DHCPv6 server should send a reply to
   the host with the prefixes received from DHCPv6 relay agent along
   with Precedence.  If the option has "N" bit set to 1, the server
   SHOULD ignore the IA_TA options in the DHCPv6 request, effectively
   disabling the use of temporary addresses for that prefix.  The DHCPv6
   server will ignore the "N" bit for destination prefixes.

   Note : If DHCPv6 servers receives both options with conflicting flags
   IPV6_DIS_TEMP_ADDR and "N" bit then it SHOULD treat it as mis-
   configuration on the relay agent and discard these options.

7.  Security Considerations

   Relay-Supplied Prefix and Absolute Precedence options are exchanged
   only between the DHCPv6 relay agent and DHCPv6 server, section 21.1
   of [RFC3315] provides details on securing DHCPv6 messages sent
   between servers and relay agents.  And, section 23 of [RFC3315]
   provides general DHCPv6 security considerations.

   It is possible for a DHCPv6 client to include the Relay-Supplied
   Prefix option or the Absolute Precedence option, which would be
   received by a DHCPv6 server.  This would cause the DHCPv6 client to
   receive a different DHCPv6 response than it would have otherwise
   received.

8.  IANA Considerations

   IANA is requested to assign option codes to OPTION_RS_PREFIX and
   OPTION_ABSOLUTE_PRECEDENCE from the option-code space as defined in

Reddy, et al.            Expires April 16, 2012                 [Page 9]
Internet-Draft  Relay-Supplied DHCPv6 Precedence Options    October 2011

   section "DHCPv6 Options" of [RFC3315].

9.  References

9.1.  Normative References

   [I-D.gont-6man-managing-privacy-extensions]
              Gont, F. and R. Broersma, "Managing the Use of Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", draft-gont-6man-managing-privacy-extensions-01
              (work in progress), March 2011.

   [I-D.ietf-6man-addr-select-opt]
              Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown,
              "Distributing Address Selection Policy using DHCPv6",
              draft-ietf-6man-addr-select-opt-01 (work in progress),
              June 2011.

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

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC5007]  Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
              "DHCPv6 Leasequery", RFC 5007, September 2007.

9.2.  Informative References

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

Reddy, et al.            Expires April 16, 2012                [Page 10]
Internet-Draft  Relay-Supplied DHCPv6 Precedence Options    October 2011

Authors' Addresses

   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com

   Prashanth Patil
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marthalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: praspati@cisco.com

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   Email: dwing@cisco.com

Reddy, et al.            Expires April 16, 2012                [Page 11]