One document matched: draft-reddy-mif-dhcpv6-precedence-ops-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-reddy-mif-dhcpv6-precedence-ops-01"
ipr="trust200902">
<front>
<title abbrev="">Relay-Supplied DHCPv6 Precedence Options</title>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<author fullname="Prashanth Patil" initials="P." surname="Patil">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marthalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>praspati@cisco.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<date/>
<workgroup>MIF Working Group</workgroup>
<abstract>
<t>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.</t>
<!--
<t>The network infrastructure is often aware of network characteristics
such as IPv6 multihoming, security policies obtained as a consequence of
authentication. Based on that information, better connectivity can be
achieved by configuring hosts differently.</t>
<t>This document defines new DHCPv6 Relay Options so that the network
infrastructure can communicate network characteristics to the DHCPv6
server, allowing the DHCPv6 server to configure the host using this
additional information.</t>
-->
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>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.</t>
<t>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.</t>
<t>An initial desire is to influence the DHCPv6 server's responses that
modify the host's address policy table <xref
target="I-D.ietf-6man-addr-select-opt"/> based on observed network
characteristics.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>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 <xref target="RFC2119">
</xref>.</t>
</section>
<section anchor="usage_scenarios" title="Usage Scenarios">
<t>The DHCPv6 extension described in this document is useful with IPv6
multihoming and with IP address-based authentication.</t>
<section anchor="IPv6_multihoming" title="IPv6 Multihoming">
<t>There are three multihoming scenarios where the Absolute Precedence
option is useful.</t>
<t>The first scenario is in Proxy Mobile IPv6 <xref target="RFC5213"/>
where Mobile Node is assigned prefixes from both local access network
and home network. This will allow selected traffic to go through the
Mobile Packet Core and the rest through the Local access Network. When
DHCPv6 Relay Agent is co-located with the mobile access gateway, the
proposal is for the relay agent to influence the DHCPv6 Server in the
home network by adding the Absolute Precedence option. The relay agent
can add an Absolute Precedence option to the DHCPv6 request suggesting
the desired label for prefix assigned by the local access network and
labels for destination prefixes reachable from the local access
network without going through the home network. The following figure
depicts this scenario.</t>
<t><figure>
<artwork><![CDATA[ _----_
_( )_
( Internet )
(_ _)
'----'
|
:
(IPv6 Traffic Offload Point)
:
|
.........................................................
| |
+--------+ | +---------------------+
| Local |-| | Services requiring |
|Services| | | mobility, or service|
+--------+ | | treatment |
| +---------------------+
| |
| _----_ |
+-----+ _( )_ +-----+
[MN]----| MAG |======( IP )======| LMA |-- Internet
+-----+ (_ _) +-----+
Assigned IPv6 addresses '----'
(Home Address Prefix, .
(Access Network Prefix) .
.
[Access Network] . [Home Network]
..........................................................]]></artwork>
</figure></t>
<t>The second 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.</t>
<t>The third 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).</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="temp_address"
title="Disabling IPv6 Temporary Addresses">
<section title="Avoiding Excessive IP-Based Authentication">
<t>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 <xref
target="RFC4941">IPv6 Privacy Addresses</xref> 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 addressess for only a set of
hosts.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Reducing Management Impact">
<t>In addition, there are known issues in managing privacy
extensions in certain scenarios. These are described in <xref
target="I-D.gont-6man-managing-privacy-extensions">managing privacy
extensions</xref>. In such scenarios, conditionally disabling
temporary addresses allows administrators to better manage
deployments.</t>
</section>
</section>
</section>
<section title="Options">
<t>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.</t>
<figure anchor="fig_message_flow"
title="Message Flow, Relay Agent adding Option">
<artwork align="center"><![CDATA[
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 | |
]]></artwork>
</figure>
<t>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.</t>
<section title="Relay-Supplied Prefix Option">
<t>The Relay-Supplied Prefix option is defined below:</t>
<figure anchor="fig_Relay_supplied_Prefix"
title="Option Type 1 message format">
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="option-len:">Length of the option.</t>
<t hangText="Policy flag: ">8-bit unsigned integer.</t>
<t hangText="Reserved:">Must be 0 and ignored by the server.</t>
</list></t>
<t>The Policy Flag is defined below, and the actions taken by the
DHCPv6 server based on this flag are described in <xref
target="dhcp_server_behaviour"/>.</t>
<figure anchor="fig_values" title="Policy flag Values">
<artwork align="center"><![CDATA[
+------+------------------------------------------------------------+
|Value | Name | Description |
+------+------------------------------------------------------------+
| 0x01 | IPV6_DIS_TEMP_ADDR | Disable IPv6 Temporary Address |
+------+------------------------------------------------------------+
]]></artwork>
</figure>
</section>
<section title="Absolute Precedence Option">
<t>The layout of the Absolute Precedence is below:</t>
<figure anchor="fig_absolute_precedence"
title="Option Type 2 message format">
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Precedence | Prefix Length |N| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Precedence | Prefix Length |N| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The fields are described below:<list style="hanging">
<t hangText="option-len:">Option Length</t>
<t hangText="Label:">An 8-bit unsigned integer. An 8-bit unsigned
integer; this value is used to make a combination of source
address prefixes and destination address prefixes..</t>
<t hangText="Precedence:">An 8-bit unsigned integer. This value is
used for sorting destination addresses.</t>
<t hangText="Prefix Length:">8-bit unsigned integer. The number of
leading bits in the Prefix that are valid.</t>
<t hangText="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 <xref target="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.</t>
<t hangText="Prefix:">A variable-length field containing the
prefix of an IPv6 address.</t>
<t hangText="Reserved2:">Must be 0 and ignored by the server.</t>
</list></t>
</section>
</section>
<section anchor="relay_agent_beh" title="Relay Agent Behaviour">
<t>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
<xref target="IPv6_multihoming"/> and/or disable IPv6 temporary
addresses for the host. <list style="empty">
<t>Discussion: To reduce end-user configuration of the DHCPv6 relay
agent, the DHCPv6 relay agent can use the mechanism specified in
<xref target="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 <xref target="RFC5007"/> to learn the prefix information from
DHCPv6 server.</t>
</list></t>
</section>
<section anchor="dhcp_server_behaviour" title="DHCPv6 Server Behaviour">
<t>Upon receiving a DHCPv6 request containing the Relay-Supplied Prefix
Option or the Absolute Precedence Option, the DHCPv6 server processing
is described below:</t>
<section title="Relay-Supplied Prefix Option">
<t>The Relay-Supplied Prefix Option contains flags that defines the
characteristics of the host. <list style="numbers">
<t>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.</t>
</list></t>
</section>
<section title="Absolute Precedence Option">
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>Relay-Supplied Prefix and Absolute Precedence options are exchanged
only between the DHCPv6 relay agent and DHCPv6 server, section 21.1 of
<xref target="RFC3315"/> provides details on securing DHCPv6 messages
sent between servers and relay agents. And, section 23 of <xref
target="RFC3315"/> provides general DHCPv6 security considerations.</t>
<t>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.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>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 <xref target="RFC3315"/>.</t>
</section>
<section title="Change History">
<t> [Note to RFC Editor: Please remove this section prior to
publication.]</t>
<section title="Changes from draft-reddy-mif-dhcpv6-precedence-ops-00 to -01">
<t><list style="symbols">
<t>Added Proxy Mobile IPv6 with traffic offload use-case in
Section 3.1.</t>
<t>Updated Section 3.2.1 to highlight the ability to disable
temporary addresses selectively.</t>
</list></t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3315"?>
<!-- <?rfc include="reference.RFC.3484"?> -->
<!-- <?rfc include="reference.I-D.ietf-6man-rfc3484-revise" ?> -->
<!-- <?rfc include="reference.RFC.3775"?> -->
<!-- <?rfc include="reference.RFC.4862"?> -->
<!-- <?rfc include="reference.RFC.4649"?> -->
<?rfc include="reference.RFC.4941"?>
<?rfc include="reference.RFC.5007"?>
<?rfc include="reference.RFC.5213"?>
<?rfc include='reference.I-D.ietf-6man-addr-select-opt'?>
<?rfc include='reference.I-D.gont-6man-managing-privacy-extensions'?>
<!-- <?rfc include="reference.I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat" ?> -->
<!-- <?rfc include="reference.I-D.droms-dhc-dhcpv6-agentopt-delegate" ?> -->
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3633'?>
<!-- <?rfc include='reference.RFC.4861'?>
<?rfc include='reference.RFC.5220'?>
<?rfc include='reference.RFC.5221'?>
<?rfc include='reference.RFC.3587'?>
<?rfc include='reference.I-D.draft-ietf-6man-addr-select-considerations-03'?>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:40:14 |