One document matched: draft-droms-dhc-dhcpv6-solmaxrt-update-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC3633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="no"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-droms-dhc-dhcpv6-solmaxrt-update-02" ipr='trust200902'>
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="DHCPv6 SOL_MAX_RT Option">Modification to Default Value of
SOL_MAX_RT</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Ralph Droms" initials="R." surname="Droms">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>1414 Massachusetts Avenue</street>
<!-- Reorder these if your country does things differently -->
<city>Boxborough</city>
<region>MA</region>
<code>01719</code>
<country>USA</country>
</postal>
<phone>+1 978 936 1674</phone>
<email>rdroms@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2012" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<!-- <workgroup>dhc</workgroup> -->
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<!--
<keyword>template</keyword>
-->
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document updates RFC 3315 by redefining the default
value for SOL_MAX_RT and defining an option through which a
DHCPv6 server can override the client's default value for
SOL_MAX_RT with a new value.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Section 5.5 of the <xref target="RFC3315">DHCPv6
specification</xref> defines the default value of SOL_MAX_RT to
be 120 seconds. In some circumstances, this default will lead
to an unacceptably high volume of aggregated traffic at a DHCPv6
server.</t>
<t>The change to SOL_MAX_RT is in response to DHCPv6 message
rates observed at a DHCPv6 server in a deployment in which many
DHCPv6 clients are sending Solicit messages but the DHCPv6
server has been configured not to respond to those Solicit
messages.</t>
<section title="Requirements Language">
<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">RFC 2119</xref>.</t>
</section>
</section>
<section title="Update to RFC 3315">
<t>This document changes section 5.5 of <xref
target="RFC3315">RFC 3315</xref> as follows:
<figure>
<artwork><![CDATA[
OLD:
SOL_MAX_RT 120 secs Max Solicit timeout value
NEW:
SOL_MAX_RT 3600 secs Max Solicit timeout value
]]></artwork>
</figure>
</t>
<t>With this change, a DHCPv6 client that does not receive a
satisfactory response will send Solicit messages with the same
initial frequency and exponential backoff as specified in
section 17.1.2 of <xref target='RFC3315'>RFC 3315</xref>.
However, the long term behavior of these DHCPv6 clients will be
to send a Solicit message every 3600 seconds rather than every
120 seconds, significantly reducing the aggregated traffic at
the DHCPv6 server.</t>
</section>
<section title="SOL_MAX_RT option">
<t>A DHCPv6 server sends the SOL_MAX_RT option to a client to
override the default value of SOL_MAX_RT. The value of
SOL_MAX_RT in the option replaces the default value defined in
<xref target='RFC3315'>RFC 3315</xref>. One use for the
SOL_MAX_RT option is to set a longer value for SOL_MAX_RT, which
reduces the Solicit traffic from a client that has not received
a response to its Solicit messages.</t>
<t>The format of the SOL_MAX_RT option is:
<figure anchor="option_format">
<artwork>
<![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-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOL_MAX_RT value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_SOL_MAX_RT (TBD).
option-len 4.
SOL_MAX_RT value Overriding value for SOL_MAX_RT in seconds.
]]>
</artwork>
</figure>
</t>
<t>A DHCPv6 client MUST include the SOL_MAX_RT option code in an
<xref target='RFC3315'>Option Request option</xref> in any
message it sends.</t>
<t>The DHCPv6 server MAY include the SOL_MAX_RT option in any
response it sends to a client that has included the SOL_MAX_RT
option code in an Option Request option. The SOL_MAX_RT option
is sent in the main body of the message to client, not as a
sub-option in, e.g., an <xref target="RFC3315">IA_NA, IA_TA</xref>
or <xref target="RFC3633">IA_PD</xref> option.</t>
<t>If a DHCPv6 client receives a message containing a SOL_MAX_RT
option, the client MUST set its internal SOL_MAX_RT parameter to
the value contained in the SOL_MAX_RT option. As a result of
receiving this option, the DHCPv6 client MUST NOT send any
Solicit messages more frequently than allowed by the
retransmission mechanism defined in sections 17.1.2 and 14 of
<xref target='RFC3315'>RFC 3315</xref>.</t>
</section>
<section title="Updates to RFC 3315">
<t><xref target="RFC3315">RFC 3315</xref>, section 17.1.3:
<figure anchor="sec17-1-3">
<artwork>
<![CDATA[
OLD:
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 to the
user.
NEW:
The client MUST ignore any Advertise message that includes a Status
Code option containing the value NoAddrsAvail, with the exception
that the client MUST process an included SOL_MAX_RT option and MAY
display the associated status message to the user.
]]>
</artwork>
</figure>
</t>
<t><xref target="RFC3315">RFC 3315</xref>, section 17.2.2:
<figure anchor="sec17-2-2">
<artwork>
<![CDATA[
OLD:
If the server will not assign any addresses to any IAs in a
subsequent Request from the client, the server MUST send an
Advertise message to the client that includes only a Status Code
option with code NoAddrsAvail and a status message for the user, a
Server Identifier option with the server's DUID, and a Client
Identifier option with the client's DUID.
NEW:
If the server will not assign any addresses to any IAs in a
subsequent Request from the client, the server MUST send an
Advertise message to the client that includes only a Status Code
option with code NoAddrsAvail and a status message for the user, a
Server Identifier option with the server's DUID, a Client
Identifier option with the client's DUID and (optionally) a
SOL_MAX_RT option.
]]>
</artwork>
</figure>
</t>
</section>
<section title="Security Considerations">
<t>This document introduces one security consideration beyond
those described in <xref target='RFC3315'>RFC 3315</xref>. A
malicious DHCPv6 server might cause a client to set its
SOL_MAX_RT parameter to an arbitrarily high value with the
SOL_MAX_RT option. Assuming the client also receives a response
from a valid DHCPv6 server, the large value for SOL_MAX_RT will
not have any effect.</t>
</section>
<section title="IANA Considerations">
<t>IANA is requested to assign an option code from the "DHCP
Option Codes" Registry for OPTION_SOL_MAX_RT.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC3315;
&RFC3633;
&RFC4861;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:10:10 |