One document matched: draft-ietf-dhc-dhcpv6-stateful-issues-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc3633 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml">
<!ENTITY rfc6204 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6204.xml">
]>
<rfc category="std" docName="draft-ietf-dhc-dhcpv6-stateful-issues-00.txt"
ipr="trust200902">
<front>
<title abbrev="Multiple Stateful Option">
Issues with multiple stateful DHCPv6 options</title>
<author fullname="Ole Troan" initials="O" surname="Troan">
<organization abbrev="">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Philip Pedersens vei 20</street>
<city>N-1324 Lysaker</city>
<region></region>
<code></code>
<country>Norway</country>
</postal>
<email>ot@cisco.com</email>
</address>
</author>
<author fullname="Bernie Volz" initials="B" surname="Volz">
<organization abbrev="">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1414 Massachusetts Ave</street>
<city>Boxborough, MA 01719</city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<email>volz@cisco.com</email>
</address>
</author>
<date year="2012" />
<area>Internet</area>
<workgroup>Network Working Group</workgroup>
<!-- SECTION 0: Abstract -->
<abstract>
<t>Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not
written with the expectation that additional stateful DHCPv6
options would be developed. IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6 shoe-horned the new
options for Prefix Delegation into DHCPv6. Implementation
experience of the CPE model described in has shown multiple
issues with the DHCPv6 protocol in supporting multiple stateful
options.</t>
</abstract>
</front>
<middle>
<!-- SECTION 1: Introduction -->
<section title="Introduction">
<t>DHCPv6 <xref target="RFC3315"/> was not written with the
expectation that additional stateful DHCPv6 options would be
developed. DHCPv6 Prefix Delegation <xref target="RFC3633"/>
shoe-horned the new options for Prefix Delegation into
DHCPv6. Implementation experience of the CPE model described in
<xref target="RFC6204"/> has shown multiple issues with the
DHCPv6 protocol in supporting multiple stateful options.</t>
<t>This document describes a number of problems encountered with
multiple IA option types into DHCP and recommended changes to
the DHCPv6 protocol specifications.</t>
<t>The intention of this work is to modify the DHCP protocol
specification to support multiple IA option types within a
single DHCP session. This problem can also be solved by
implementing a separate DHCP session (separate client state
machine) per IA option type. This latter approach has a number
of issues: additional DHCP protocol traffic, 'collisions'
between stateless options also included with the IA options,
divergence in that each IA option type specification specifies
its 'own' version of the DHCP protocol.</t>
<t>The changes described in this document will be incorporated
in a new revision of the DHCPv6 protocol specification <xref
target="RFC3315"/>.</t>
</section>
<!-- SECTION 2: REQUIREMENTS LANGUAGE -->
<section title="Conventions">
<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 RFC 2119 <xref
target="RFC2119"></xref>.</t>
</section>
<!-- conventions -->
<!-- SECTION 3: DESCRIPTION -->
<section title="Terminology">
<t><list hangIndent="28" style="hanging">
<t hangText="Stateful options">
Options that require dynamic binding state per client on the
server.</t>
<t hangText="Identity association (IA):">
A collection of stateful options assigned to a client. Each
IA has an associated IAID. A client may have more than one
IA assigned to it; for example, one for each of its
interfaces. Each IA holds one type of IA option; for example,
an identity association for temporary addresses (IA_TA)
holds temporary addresses (see "identity association for
temporary addresses"). Throughout this document, "IA" is
used to refer to an identity association without identifying
the type of stateful option in the IA.</t>
</list></t>
</section>
<section title="Handling of multiple IA options types">
<t>DHCPv6 was written with the assumption that the only stateful
options where for assigning addresses. DHCPv6 PD describes how
to extend the DHCPv6 protocol to handle prefix delegation, but
RFC3633 did not consider how DHCP address assignment and prefix
delegation could co-exist.</t>
<section title="Advertisement message">
<t>RFC3315 specifies that a client must ignore an Advertise
message if a server will not assign any addresses to a
client. A client requesting both IA_NA and IA_PD, with a
server that only offers one of them, is not supported in the
current protocol specification.</t>
<t>Proposed solution: a client should accept Advertise messages,
even when not all IA option types are being offered. A client
should ignore an Advertise message when no bindings at all
are being offered.</t>
<t>Replace Section 17.1.3: (existing errata)</t>
<figure><artwork>
The client MUST ignore any Advertise message that includes a Status
Code option containing the value NoAddrsAvail, with the exception
that the client MAY display the associated status message(s) to the
user.
</artwork></figure>
<t>With:</t>
<figure><artwork>
The client MUST ignore any Advertise message that contains no
bindings (if only IA_NA and/or IA_TA options were requested,
this is a message that includes a Status Code option containing the
value NoAddrsAvail), with the exception that the client MAY display
the associated status message(s) to the user.
</artwork></figure>
<t>And, replace:</t>
<figure><artwork>
- The client MAY choose a less-preferred server if that server
has a better set of advertised parameters, such as the
available addresses advertised in IAs.
</artwork></figure>
<t>With:</t>
<figure><artwork>
- The client MAY choose a less-preferred server if that server
has a better set of advertised parameters, such as the
available options advertised in IAs.
</artwork></figure>
<t>It is important to note that the receipt of a Advertisement
without any bindings does not imply that the client should
restart the Solicit retransmissions timers. Doing so would
lead to a Solicit/Advertisement storm.</t>
</section>
<section title="Placement of Status codes">
<t>In Reply messages IA specific status codes (NoAddrsAvail,
NotOnlink, NoBinding) are encapsulated in the IA option. In
Advertisement messages the Status Code option with the
NoAddrsAvail code is in the "global" scope. That makes sense
when the failure case is fatal. With the introduction of
multiple IA option types, there might be a case where a server is
not willing to offer addresses, but might be willing to offer
other stateful option types.</t>
<t>While a Status Code option is implicitly bound to a
specific type of IA, e.g. NoPrefixAvail is only applicable to
IA_PD and NoAddrsAvail is only applicable to IA_NA/IA_TA, it
may be problematic to make this assumption for all status
codes. Ideally the Status Code option should be encapsulated in
the IA option for all DHCP messages. This makes Advertisement
messages equal to Reply messages.</t>
<t>Proposed solution: No change. For backwards compatibility,
the NoAddrsAvail Status Code option when no addresses are
available will be kept in the global scope for Advertise
messages. Other IA option types MUST encapsulate the Status
Code option within the IA option.</t>
</section>
<section title="T1/T2 timers">
<t>The T1 and T2 timers determine when the client will contact
the server to extend lifetimes of information received in an
IA. How should a client handle the case where multiple IA
options have different T1 and T2 timers?</t>
<t>In a multiple IA option types model, the T1/T2 timers are
protocol timers, that should be independent of the IA options
themselves. If we were to redo the DHCP protocol from scratch
the T1/T2 timers should be carried in a separate DHCP
option.</t>
<t>Proposed solution: The server SHOULD set the T1/T2 timers
in all IA options in Reply and Advertise messages to the same
value. To deal with the case where servers have not yet been
updated to do that, clients MUST use the shortest (explicit or
implicit) T1/T2 timer (larger than 0) in any IA options in the
Reply. Longer T1/T2 timers are ignored.</t>
</section>
<section title="Confirm message">
<t>The Confirm message, as described in <xref target="RFC3315"/>,
is specific to address assignment. It lets a server without a
binding to reply to the message, under the assumption that the
server only needs knowledge about the prefix(es) on the link,
to inform the client that the address is likely valid or not.
This message is sent when e.g. the client has moved and needs
to validate its addresses. Not all bindings can be validated by
servers and the Confirm message provides for this by specifying
that a server that is unable to determine the on-link status
MUST NOT send a Reply.</t>
<t>Note: Confirm has a specific meaning and does not overload
Renew/Rebind. It also is lower processing cost as the server
does NOT need to extend lease times or otherwise send back
other configuration options.</t>
<t>Proposed solution: Allow and specify the Confirm message
for other IA option types. A server SHOULD respond to a
Confirm message only if it has definitive knowledge, based on
the network configuration and not the specific client's bindings,
that the client is still on-link or not on-link.</t>
</section>
<section title="Release messages">
<t>A client can release any individual lease at any time. A
client can get "back" a lease by using a Renew message. It MAY
do this at any time, though must avoid creating a Renew
storm. E.g. wait until T1.</t>
</section>
<section title="Unanswered options">
<t>If a client requests multiple IA option types, but the server
is willing to only offer a subset of them, the client could
react in several ways. Reset the state machine and continue to
send Solicit messages, create separate DHCP sessions for each
IA option type and continue to Solicit for the missing options,
or it could continue with the single session, and include the
missing options on subsequent messages to the server.</t>
<t>Proposed solution: the client should keep a single session
with the server. The client should continue with the IA
options received, while continuing to request the other IA
options in subsequent messages to the server. That means to
continue to include the empty unanswered IAs in subsequent
Renew and Rebind messages.</t>
<t>For the IAs that the server will not offer a binding, it must
reply using the same behaviour as for a Request message. That
is not with the currently specified NoBinding status). This
behaviour will not require the server to remember the IAs that
it is not willing to serve. I.e. the change is to allow the
client to include IAs in Renew/Rebind messages for which
it has not received bindings (yet).</t>
<t>A client can only use the Renew (or Rebind) to request
new IA options if it already has one or more bindings. A client
MUST NOT use Renew (or Rebind) if it has no valid bindings it
is renewing.</t>
<t>Replace Section 18.2.3:</t>
<figure><artwork>
If the server cannot find a client entry for the IA the server
returns the IA containing no addresses with a Status Code option set
to NoBinding in the Reply message.
</artwork></figure>
<t>With:</t>
<figure><artwork>
If the server cannot find a client entry for the IA but has one or
more bindings for the client, the server SHOULD treat this like a
Request message for the IA. If the server has no other bindings for
the client, the server SHOULD return the IA containing no bindings
with a Status Code option set to NoBinding in the Reply message.
</artwork></figure>
</section>
<section title="Multiple provisioning domains">
<t>This document has assumed that all DHCP servers on a network are
in a single provisioning domain and thus should be "equal" in the
service that they offer.</t>
<t>One could envision a network where the DHCP servers are in multiple
provisioning domains, and it may be desireable to have the DHCP client
obtain different IA types from different provisioning domains. How a
client detects the multiple provisioning domains and how it would
interact with the multiple servers in these different domains is outside
the scope of this document and an area for future work.</t>
</section>
</section>
<!-- SECTION 4: IANA Considerations -->
<section title="IANA Considerations">
<t>This specification does not require any IANA actions.</t>
</section>
<!-- SECTION 5: Security Considerations -->
<section title="Security Considerations">
<t>There are no new security considerations pertaining to this
document.</t>
</section>
<!-- SECTION 6: Acknowledgements -->
<section title="Acknowledgements">
</section>
</middle>
<back>
<!-- SECTION 8.1: Normative References -->
<references title="Normative References">
&rfc2119;
&rfc3315;
&rfc3633;
&rfc6204;
</references>
<!--
<references title="Informative References">
</references>
-->
<!-- SECTION 8.2: Informative References -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:51:11 |