One document matched: draft-droms-dhc-dhcpv6-solmaxrt-update-00.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 RFC2461 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2461.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.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-00" 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="Abbreviated Title">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="2011" />
<!-- 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>
<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 RC 3315">
<t>This document changes section 5.5 of RFC 3315 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 RFC
3315. 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>
<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. RFC 3315 was written with the expectation that the
'M' and 'O' flags in <xref target="RFC2461">NDP</xref> would
control the use of DHCPv6 by hosts. However, the current
definition of the 'M' and 'O' flags in <xref
target="RFC4861">RFC 4861</xref> does not explicitly preclude
the use of DHCPv6 by a host. Some devices are specified to
initiate DHCPv6 even if RAs are received with the 'M' and 'O'
bits set to 0. In some circumstances, it is desirable to enable
the assignment of IPv6 addresses through DHCPv6 to some nodes on
a link but not to others, which cannot be implemented through
the 'M' and 'O' bits.</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. 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
any IPv6 addresses.</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>If the DHCPv6 server declines to assign any addresses to a
client in an IA_NA or IA_TA option, it MAY include a SOL_MAX_RT
option in the appropriate options field along with a Status Code
option indicating NoAddrsAvail.</t>
<t>If a DHCPv6 client receives an IA_NA or IA_TA option
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.</t>
</section>
<section title="Security Considerations">
<t>This document introduces one security considerations
beyond those described in RFC 3315. 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 options 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;
&RFC2461;
&RFC3315;
&RFC4861;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:20:26 |