One document matched: draft-ietf-dhc-client-id-07.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-07" ipr="trust200902"
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="5" month="November" year="2012"/>
<area>Internet Engineering Task Force</area>
<workgroup>DHC Working Group</workgroup>
<abstract>
<t>This document updates RFC 2131 -- Dynamic Host Configuration Protocol
(DHCP) -- by addressing the issues arising from that document's
specification that the server MUST NOT return the '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 an IP based network. DHCP
is built on a client-server model, where designated DHCP servers
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 clarify the use of
the '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. Furthermore, DHCP relay agents and servers
implementing [RFC2131] "MAY" drop the DHCP packets in the absence of
both 'client identifier' and 'chaddr'.</t>
<t>In some cases, a client may not have a valid hardware address to
populate the 'chaddr' field and may set the field to all zeroes. 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
solution specified in this document is in line with DHCPv6 [RFC3315]
where the server always includes the Client Identifier option in the
Reply messages.</t>
<t>The requirement for DHCP servers not to return the 'client
identifier' option was made purely to conserve the limited space in the
packet. It is possible, though unlikely, that clients will drop packets
that contain this formerly unexpected option. There are no known client
implementations that will drop packets but the benefit provided by this
change outweighs any small risk of such behavior. More harm is being
done by not having the 'client identifier' option present than might be
done by adding it now.</t>
</section>
<section anchor="section3" title="Modification To [RFC2131]">
<t>If the 'client identifier' option is present 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>This specification does not add any new security considerations other
than the ones already mentioned in [RFC2131]. It is worth noting that
DHCP clients routinely connect to different IP networks managed by
different network providers. DHCP clients have no a priori knowledge of
which network they are connecting to. Consequently, the client
identifier will, by definition, be routinely shared with network
operators and could be used in ways that violate the user's privacy.
This is a problem that existed in [RFC2131]. This document does nothing
to address this problem.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgments">
<t>The authors would like to thank Bernie Volz, Ted Lemon, Barr Hibbs,
Richard Johnson, Barry Leiba, Stephen Farrell, Adrian Farrel for
insightful discussions and review.</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 02:54:46 |