One document matched: draft-reddy-mif-dhcpv6-precedence-ops-02.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-02"
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. <xref
target="RFC6724"></xref> 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 <xref
target="I-D.ietf-6man-addr-select-opt"></xref> 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><list style="symbols">
<t>In Proxy Mobile IPv6 <xref target="RFC5213"></xref> 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 Address
Selection option. The relay agent can add an Address Selection
option to the DHCPv6 request suggesting the local access network
address selection policy table overiding the default address
selection parameters and policy table. The DHCPv6 server in the
home network will merge the policy received in Address Selection
option with it's own policy table as explained in section 4.3 of
<xref target="I-D.ietf-6man-addr-select-opt"></xref>. This updated
policy table will be provided to the DHCPv6 client (MN) in Address
Selection option (OPTION_ADDRSEL_TABLE). When the DHCPv6 Server is
co-located with the mobile access gateway, the DHCPv6 Server in
the local access network will receive the policy table from the
DHCPv6 server in the home network using DHCPv6
INFORMATION-REQUEST. The DHCPv6 server in local access network
will merge the received policy table with it's local policy table.
The following figure depicts this scenario. <figure
anchor="Figure1" title="Proxy Mobile IPv6">
<artwork align="center"><![CDATA[ _----_
_( )_
( Internet )
(_ _)
'----'
|
:
:
|
.........................................................
| |
+--------+ | +---------------------+
| Local |-| | Operator Value |
|Services| | | Added Services |
+--------+ | | |
| +---------------------+
| |
| _----_ |
+-----+ _( )_ +-----+
[MN]----| MAG |======( IP )======| LMA |-- Internet
+-----+ (_ _) +-----+
'----'
.
.
.
[Access Network] . [Home Network]
..........................................................
MN - Mobile Node ]]></artwork>
</figure></t>
</list></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 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 <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 addresses 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 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.</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 new
DHCPv6 option Relay-Supplied Prefix and updates the Address Selection
option defined in <xref target="I-D.ietf-6man-addr-select-opt"></xref>.
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 |
| Address Selection option to the request) |
| | |
| |----------------------------->|
| | DHCPv6 REQUEST with |
| | Relay-Supplied Prefix and/or |
| | Address Selection 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 Address
Selection option allows prioritizing among a list of prefixes the DHCPv6
relay agent expects the DHCPv6 server to provide to the host.</t>
<section title="Address Selection option">
<t>The layout of the Address Selection option is below:</t>
<figure anchor="fig_absolute_precedence"
title="Option Type 1 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_ADDRSEL_TABLE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved|N|A|P| |
+-+-+-+-+-+-+-+-+ POLICY TABLE OPTIONS |
| (variable length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The fields are described below:<list style="hanging">
<t hangText="option-code :">OPTION_ADDRSEL_TABLE defined in <xref
target="I-D.ietf-6man-addr-select-opt"></xref></t>
<t hangText="option-len:">Option Length</t>
<t hangText="Reserved:">Must be 0 and ignored by the server.</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"></xref>. 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="A:">This flag MUST be set to 0 and ignored by the
DHCPv6 server</t>
<t hangText="P:">This flag MUST be set to 0 and ignored by the
DHCPv6 server.</t>
<t hangText="Prefix Table Options:">Zero or more Address Selection
Policy Table options defined in <xref
target="I-D.ietf-6man-addr-select-opt"></xref>.</t>
</list></t>
</section>
<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 2 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"></xref>.</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>
<section anchor="relay_agent_beh" title="Relay Agent Behaviour">
<t>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 <xref
target="IPv6_multihoming"></xref> 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"></xref> 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"></xref> to learn the
prefix information from DHCPv6 server.</t>
</list>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.</t>
</section>
<section anchor="dhcp_server_behaviour" title="DHCPv6 Server Behaviour">
<t>Upon receiving a DHCPv6 request containing the Address Selection
option or the Relay-Supplied Prefix Option, the DHCPv6 server processing
is described below:</t>
<section title="Address Selection option">
<t>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 <xref
target="I-D.ietf-6man-addr-select-opt"></xref>.</t>
<t>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 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>
<section anchor="security" title="Security Considerations">
<t>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 <xref
target="RFC3315"></xref> provides details on securing DHCPv6 messages
sent between servers and relay agents. And, section 23 of <xref
target="RFC3315"></xref> provides general DHCPv6 security
considerations.</t>
<t>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. .</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>IANA is requested to assign option code to OPTION_RS_PREFIX from the
option-code space as defined in section "DHCPv6 Options" of <xref
target="RFC3315"></xref>.</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 title="Changes from draft-reddy-mif-dhcpv6-precedence-ops-01 to -02">
<t><list style="symbols">
<t>Updated usecase in section 3.1</t>
<t>Changed Absolute Precedence Option</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.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.RFC.6724"?>
<?rfc include="reference.RFC.4291"?>
<?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:39 |