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 described in the Simplified BSD License.

Table of Contents

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

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

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.

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

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

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

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

The fields are described below:

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.

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 section "DHCPv6 Options" of [RFC3315].

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses