draft-ietf-dhc-client-id-00.txt   draft-ietf-dhc-client-id-01.txt 
DHC Working Group Narasimha Swamy DHC Working Group N. Swamy
INTERNET DRAFT Nokia Networks Internet-Draft Nokia
Updates: 2131 (if approved) G. Halwasia
Intended status: Standards Track P. Jhingran
Expires: February 17, 2012 Cisco Systems
August 16, 2011
Updates: RFC 2131 January 2004 Client Identifier Option in DHCP Server Replies
Expires July 2004 draft-ietf-dhc-client-id-01
Client Identifier option in server replies Abstract
<draft-ietf-dhc-client-id-00.txt>
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.
Requirements
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 [RFC2119].
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This Internet-Draft is submitted in full conformance with the
all provisions of Section 10 of RFC2026. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on February 17, 2012.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Abstract This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document clarifies the use of 'client identifier' option by the Table of Contents
clients and servers as mentioned in [RFC2131]. The clarification
addresses the issue arising out of the point specified by [RFC2131] 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
that the server 'MUST NOT' return client identifier' option to the 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
client. 3. Proposed Modification To [RFC2131] . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
In some cases, client may not be having valid hardware address value The Dynamic Host Configuration Protocol (DHCP) defined in [RFC2131]
to be filled in 'chaddr' field of the packet (one such example is provides configuration parameters to hosts on a TCP/IP based network.
when DHCP is used to assign IP addresses to Mobile phones). In this DHCP is built on a client-server model, where designated DHCP server
case, client sets 'client identifier' option, and both client and allocate network addresses and deliver configuration parameters to
server use this field to uniquely identify the client with in dynamically configured hosts.
a subnet. But [RFC2131] specifies that server "MUST NOT" return
'client identifier' in DHCPOFFER and DHCPACK messages. In this case,
when a client receives response from server, it can't guarantee that
response is intended for it. Note that even though 'xid' field is
present to map responses with requests, this field alone can't guar-
antee that a particular response is for a particular client, as 'xid'
values generated by multiple clients within a subnet need not be
unique. This draft proposes modification to server behavior to addr-
ess this problem.
2. Terminology The changes to [RFC2131] defined in this document 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 and thus 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 2. Problem Statement
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119].
This document uses the following terms: [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'.
o "DHCP client" 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.
A DHCP client is an Internet host using DHCP to obtain confi- Note that due to above mentioned recommendations in [RFC2131], valid
guration parameters such as a network address. 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.
o "DHCP server" 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.
A DHCP server is an Internet host that returns configuration This document attempts to address these problems faced by DHCP relay
parameters to DHCP clients. 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.
3. Proposed modification to [RFC2131] 3. Proposed Modification To [RFC2131]
If the 'client identifier' option is set in the message received from If the 'client identifier' option is set in a message received from a
client, the server MUST return 'client identifier' value in its client, the server MUST return the 'client identifier' option,
response message. unaltered, in its response message.
Following table is extracted from section 4.3.1 of [RFC2131] and Following table is extracted from section 4.3.1 of [RFC2131] and
relevant fields are modified accordingly. relevant fields are modified accordingly to overcome the problems
mentioned in this document.
Option DHCPOFFER DHCPACK DHCPNAK
Client identifier MAY MAY MAY
Table 1: Options used by DHCP servers
4. Security Considerations
No known security considerations.
5. Acknowledgments
I would like to thank Umesh Kulkarni, Harish Raghuveer and Hari Mallath
for their support and feedback.
6. References 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)
[RFC 951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC 4. IANA Considerations
951, September 1985.
[RFC 1542] Wimer, W., "Clarifications and Extensions for the This memo asks the IANA for no new parameters.
Bootstrap Protocol", RFC 1542, October 1993.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 5. Security Considerations
Requirement Levels", RFC 2119, March 1997.
[RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC No known security considerations.
2131, March 1997.
[RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 6. Acknowledgements
Extensions", RFC 2132, March 1997.
7. Author's information The authors would like to thank Bernie Volz, Ted Lemon, Barr Hibbs
for their insightful discussions on the previous version of this
document.
Narasimha Swamy 7. Normative References
Nokia India Pvt Ltd
#88, Gandhi Bazaar Main Road
Basavanagudi
Bangalore - 560 004
Phone: +91 80 51189628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Email: narasimha.nelakuditi@nokia.com [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
8. Intellectual Property Statement [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
The IETF takes no position regarding the validity or scope of any intel- Authors' Addresses
lectual property or other rights that might be claimed to pertain to
the implementation or use of the technology described in this document
or the extent to which any license under such rights might or might not
be available; neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's procedures with
respect to rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made available for
publication and any assurances of licenses to be made available, or the
result of an attempt made to obtain a general license or permission for
the use of such proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any Narasimha Swamy Nelakuditi
copyrights, patents or patent applications, or other proprietary rights Nokia
which may cover technology that may be required to practice this stan- Visiokatu 3
dard. Please address the information to the IETF Executive Director. Tampere, 33720
Finland
9. Full Copyright Statement Phone: +358 50487 2126
Email: narasimha.nelakuditi@nokia.com
Copyright (C) The Internet Society (2003). All Rights Reserved. Gaurav Halwasia
Cisco Systems
SEZ Unit, Cessna Business Park
Sarjapur Marathalli Outer Ring Road
Bangalore, 560103
India
This document and translations of it may be copied and furnished to oth- Phone: +91 80 4426 1321
ers, and derivative works that comment on or otherwise explain it or Email: ghalwasi@cisco.com
assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet Stan-
dards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be Prashant Jhingran
revoked by the Internet Society or its successors or assigns. Cisco Systems
SEZ Unit, Cessna Business Park
Sarjapur Marathalli Outer Ring Road
Bangalore, 560103
India
This document and the information contained herein is provided on an "AS Phone: +91 80 4426 1800
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK Email: pjhingra@cisco.com
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT-
NESS FOR A PARTICULAR PURPOSE.
 End of changes. 38 change blocks. 
119 lines changed or deleted 143 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/