One document matched: draft-ietf-dhc-client-id-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-ietf-dhc-client-id-06"
ipr="pre5378Trust200902" updates="2131">
<front>
<title abbrev="Client Identifier Option">Client Identifier Option in DHCP
Server Replies</title>
<author fullname="Narasimha Swamy Nelakuditi" initials="N."
surname="Swamy">
<organization>Samsung India</organization>
<address>
<postal>
<street>Block-B, Bagmane Lakeview,</street>
<street>66/1, Bagmane Tech Park,</street>
<city>Byrasandra, C.V. Raman Nagar, Bangalore</city>
<code>560093</code>
<region/>
<country>India</country>
</postal>
<phone>+91 80 4181 9999</phone>
<email>nn.swamy@samsung.com</email>
</address>
</author>
<author fullname="Gaurav Halwasia" initials="G." surname="Halwasia">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>SEZ Unit, Cessna Business Park</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<code>560103</code>
<region/>
<country>India</country>
</postal>
<phone>+91 80 4426 1321</phone>
<email>ghalwasi@cisco.com</email>
</address>
</author>
<author fullname="Prashant Jhingran" initials="P." surname="Jhingran">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>SEZ Unit, Cessna Business Park</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<code>560103</code>
<region/>
<country>India</country>
</postal>
<phone>+91 80 4426 1800</phone>
<email>pjhingra@cisco.com</email>
</address>
</author>
<date day="2" month="October" year="2012"/>
<area>Internet Engineering Task Force</area>
<workgroup>DHC Working Group</workgroup>
<abstract>
<t>This document updates RFC2131 [RFC2131]. The changes to [RFC2131]
defined in this draft clarifies the use of 'client identifier' option by
the DHCP servers. The clarification addresses the issues arising out of
the point specified by [RFC2131] that the server 'MUST NOT' return
client identifier' option to the client.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<note title="Requirements">
<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"/>.</t>
</note>
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section anchor="section1" title="Introduction">
<t>The Dynamic Host Configuration Protocol (DHCP) defined in [RFC2131]
provides configuration parameters to hosts on a TCP/IP based network.
DHCP is built on a client-server model, where designated DHCP server
allocate network addresses and deliver configuration parameters to
dynamically configured hosts.</t>
<!--
<t>
The changes to [RFC2131] defined in this draft facilitates DHCP relay
agents and hosts to process downstream DHCP messages
(DHCPOFFER,DHCPACK and DHCPNAK) when a DHCP client sets
the 'chaddr' field as zero in DHCP request messages.
</t>
-->
<t>The changes to [RFC2131] defined in this document clarifies the use
of 'client identifier' option by the DHCP servers. The clarification
addresses the issues (as mentioned in Problem Statement) arising out of
the point specified by [RFC2131] that the server 'MUST NOT' return
client identifier' option to the client.</t>
</section>
<section anchor="section2" title="Problem Statement">
<t>[RFC2131] specifies that a combination of 'client identifier' or
'chaddr' and assigned network address constitute a unique identifier for
the client's lease and are used by both the client and server to
identify a lease referred in any DHCP messages. [RFC2131] also specifies
that the server "MUST NOT" return 'client identifier' in DHCPOFFER and
DHCPACK messages. DHCP relay agents and servers, following these
recommendations MAY drop the DHCP packets in the absence of both 'client
identifier' and 'chaddr'.</t>
<t>In some cases, client may not be having valid hardware address value
to be filled in 'chaddr' field of the packet and hence may set this
field as zero. One such example is when DHCP is used to assign IP
address to a mobile phone or a tablet and where the 'chaddr' field is
set to zero in DHCP request packets. In such cases, client usually sets
the 'client identifier' option field (to a value as permitted in
[RFC2131]), and both client and server use this field to uniquely
identify the client with in a subnet.</t>
<t>Note that due to above mentioned recommendations in [RFC2131], valid
downstream DHCP packets (DHCPOFFER, DHCPACK and DHCPNAK) from the server
MAY get dropped at the DHCP relay agent in the absence of 'client
identifier' option when 'chaddr' field is set as zero.</t>
<t>The problem may get aggravated when a client receives a response from
the server without 'client identifier' and with 'chaddr' value set to
zero, as it cannot guarantee that the response is intended for it. This
is because even though the 'xid' field is present to map responses with
requests, this field alone cannot guarantee that a particular response
is for a particular client, as 'xid' values generated by multiple
clients within a subnet need not be unique.</t>
<t>Lack of 'client identifier' option in DHCP reply messages also
affects the scenario where multiple DHCP clients may be running on the
same host sharing the same 'chaddr'.</t>
<t>This document attempts to address these problems faced by DHCP relay
agent and client by proposing modification to DHCP server behavior. The
proposed solution is in line with DHCPv6 [RFC3315] where the server
always includes the Client Identifier option in the Reply messages.</t>
</section>
<section anchor="section3" title="Proposed Modification To [RFC2131]">
<t>If the 'client identifier' option is set in a message received from a
client, the server MUST return the 'client identifier' option,
unaltered, in its response message.</t>
<t>Following table is extracted from section 4.3.1 of [RFC2131] and
relevant fields are modified accordingly to overcome the problems
mentioned in this document.</t>
<figure>
<artwork><![CDATA[
Option DHCPOFFER DHCPACK DHCPNAK
------ --------- ------- -------
Client identifier (if MUST MUST MUST
sent by client)
Client identifier (if MUST NOT MUST NOT MUST NOT
not sent by client)
]]></artwork>
</figure>
<t>When a client receives a DHCP message containing a 'client
identifier' option, the client MUST compare that client identifier to
the one it is configured to send. If the two client identifiers do not
match, the client MUST silently discard the message.</t>
</section>
<!-- possibly a "Contributors" section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>No known security considerations.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Bernie Volz, Ted Lemon, Barr Hibbs,
Richard Johnson for their insightful discussions on the previous version
of this document.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2131"?>
<?rfc include="reference.RFC.3315"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:55:13 |