| MIF Working Group | T. Reddy |
| Internet-Draft | P. Patil |
| Intended status: Standards Track | D. Wing |
| Expires: April 16, 2013 | Cisco |
| October 15, 2012 |
Relay-Supplied DHCPv6 Precedence Options
draft-reddy-mif-dhcpv6-precedence-ops-02
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.
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, 2013.
Copyright (c) 2012 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.
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. [RFC6724] defines default address selection mechanisms for IPv6 that allow nodes to select appropriate address when faced with multiple source and/or destination addresses to choose between. 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.
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].
The DHCPv6 extension described in this document is useful with IPv6 multihoming and with IP address-based authentication.
_----_
_( )_
( Internet )
(_ _)
'----'
|
:
:
|
.........................................................
| |
+--------+ | +---------------------+
| Local |-| | Operator Value |
|Services| | | Added Services |
+--------+ | | |
| +---------------------+
| |
| _----_ |
+-----+ _( )_ +-----+
[MN]----| MAG |======( IP )======| LMA |-- Internet
+-----+ (_ _) +-----+
'----'
.
.
.
[Access Network] . [Home Network]
..........................................................
MN - Mobile Node
Figure 1: Proxy Mobile IPv6
Some managed networks authenticate hosts with an authentication supplicant or for hosts lacking the supplicant perform 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. In a managed network, this option will ensure that temporary addresses are disabled for hosts without authentication supplicant. This way managed networks can conditionally disable temporary addresses for only a set of hosts.
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 Address Selection 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.
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.
To realize the functions described above, this document defines new DHCPv6 option Relay-Supplied Prefix and updates the Address Selection option defined in [I-D.ietf-6man-addr-select-opt]. 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 |
| Address Selection option to the request) |
| | |
| |----------------------------->|
| | DHCPv6 REQUEST with |
| | Relay-Supplied Prefix and/or |
| | Address Selection Options |
| | |
| |<-----------------------------|
| | DHCPv6 REPLY |
|<-------------------| |
| DHCPv6 REPLY | |
Figure 2: 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 Address Selection option allows prioritizing among a list of prefixes the DHCPv6 relay agent expects the DHCPv6 server to provide to the host.
The layout of the Address Selection option 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_ADDRSEL_TABLE | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved|N|A|P| | +-+-+-+-+-+-+-+-+ POLICY TABLE OPTIONS | | (variable length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Option Type 1 message format
The fields are described below:
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 4: Option Type 2 message format
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 5: Policy flag Values
DHCPv6 relay agents that implement this specification MUST be configurable for sending the Address Selection option and the Relay-Supplied Prefix 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 Address Selection option when there is a need to change the label/precedence value for prefixes in scenario's discussed in Section 3.1 and/or disable IPv6 temporary addresses for the host.
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.
Upon receiving a DHCPv6 request containing the Address Selection option or the Relay-Supplied Prefix Option, the DHCPv6 server processing is described below:
Address Selection option - The DHCPv6 server should send a reply to the host with the prefixes received from DHCPv6 relay agent along with Precedence. The DHCPv6 server will merge the policy received in Address Selection option with it's own policy table as explained in section 4.3 of [I-D.ietf-6man-addr-select-opt].
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.
The Relay-Supplied Prefix Option contains flags that defines the characteristics of the host.
Relay-Supplied Prefix is exchanged only between the DHCPv6 relay agent and DHCPv6 server and Address Selection option can originate either from the server or the relay agent, 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 Address Selection options, 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. .
IANA is requested to assign option code to OPTION_RS_PREFIX from the option-code space as defined in section "DHCPv6 Options" of [RFC3315].
[Note to RFC Editor: Please remove this section prior to publication.]
| [RFC3633] | Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. |