idnits 2.17.1 draft-swamy-dhc-client-id-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 3) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2131]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2131, but the abstract doesn't seem to directly say this. It does mention RFC2131 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 135 has weird spacing: '...imed to perta...' == Line 164 has weird spacing: '...for the purpo...' (Using the creation date from RFC2131, updated by this document, for RFC5378 checks: 1994-11-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2004) is 7407 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2131' is mentioned on line 85, but not defined == Unused Reference: 'RFC 951' is defined on line 105, but no explicit reference was found in the text == Unused Reference: 'RFC 1542' is defined on line 108, but no explicit reference was found in the text == Unused Reference: 'RFC 2131' is defined on line 114, but no explicit reference was found in the text == Unused Reference: 'RFC 2132' is defined on line 117, but no explicit reference was found in the text Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Narasimha Swamy 3 INTERNET DRAFT Nokia Networks 5 Updates: RFC 2131 July 2003 6 Expires January 2004 8 Client Identifier option in server replies 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document clarifies the use of 'client identifier' option by the 39 clients and servers as mentioned in [RFC2131]. The clarification 40 addresses the issue arising out of the point specified by [RFC2131] 41 that the server 'MUST NOT' return client identifier' option to the 42 client. 44 1. Introduction 46 In some cases, client may not be having valid hardware address value 47 to be filled in 'chaddr' field of the packet (one such example is 48 when DHCP is used to assign IP addresses to Mobile phones). In this 49 case, client sets 'client identifier' option, and both client and 50 server use this field to uniquely identify the client with in 51 a subnet. But [RFC2131] specifies that server "MUST NOT" return 52 'client identifier' in DHCPOFFER and DHCPACK messages. In this case, 53 when a client receives response from server, it can't guarantee that 54 response is intended for it. Note that even though 'xid' field is 55 present to map responses with requests, this field alone can't guar- 56 antee that a particular response is for a particular client, as 'xid' 57 values generated by multiple clients within a subnet need not be 58 unique. This draft proposes modification to server behavior to addr- 59 ess this problem. 61 2. Terminology 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 [RFC 2119]. 67 This document uses the following terms: 69 o "DHCP client" 71 A DHCP client is an Internet host using DHCP to obtain confi- 72 guration parameters such as a network address. 74 o "DHCP server" 76 A DHCP server is an Internet host that returns configuration 77 parameters to DHCP clients. 79 3. Proposed modification to [RFC2131] 81 If the 'client identifier' option is set in the message received from 82 client, the server MUST return 'client identifier' value in its 83 response message. 85 Following table is extracted from section 4.3.1 of [RFC2131] and 86 relevant fields are modified accordingly. 88 Option DHCPOFFER DHCPACK DHCPNAK 89 ------ --------- ------- ------- 90 Client identifier MAY MAY MAY 92 Table 1: Options used by DHCP servers 94 4. Security Considerations 96 No known security considerations. 98 5. Acknowledgments 100 I would like to thank Umesh Kulkarni, Harish Raghuveer and Hari Mallath 101 for their support and feedback. 103 6. References 105 [RFC 951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC 106 951, September 1985. 108 [RFC 1542] Wimer, W., "Clarifications and Extensions for the 109 Bootstrap Protocol", RFC 1542, October 1993. 111 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 112 Requirement Levels", RFC 2119, March 1997. 114 [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 115 2131, March 1997. 117 [RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 118 Extensions", RFC 2132, March 1997. 120 7. Author's information 122 Narasimha Swamy 123 Nokia India Pvt Ltd 124 #50, Vanivilas Rd 125 Basavanagudi 126 Bangalore - 560 004 128 Phone: +91 80 6618100 130 Email: narasimha.nelakuditi@nokia.com 132 8. Intellectual Property Statement 134 The IETF takes no position regarding the validity or scope of any intel- 135 lectual property or other rights that might be claimed to pertain to 136 the implementation or use of the technology described in this document 137 or the extent to which any license under such rights might or might not 138 be available; neither does it represent that it has made any effort to 139 identify any such rights. Information on the IETF's procedures with 140 respect to rights in standards-track and standards-related documentation 141 can be found in BCP-11. Copies of claims of rights made available for 142 publication and any assurances of licenses to be made available, or the 143 result of an attempt made to obtain a general license or permission for 144 the use of such proprietary rights by implementors or users of this 145 specification can be obtained from the IETF Secretariat. 147 The IETF invites any interested party to bring to its attention any 148 copyrights, patents or patent applications, or other proprietary rights 149 which may cover technology that may be required to practice this stan- 150 dard. Please address the information to the IETF Executive Director. 152 9. Full Copyright Statement 154 Copyright (C) The Internet Society (2003). All Rights Reserved. 156 This document and translations of it may be copied and furnished to oth- 157 ers, and derivative works that comment on or otherwise explain it or 158 assist in its implementation may be prepared, copied, published and dis- 159 tributed, in whole or in part, without restriction of any kind, provided 160 that the above copyright notice and this paragraph are included on all 161 such copies and derivative works. However, this document itself may not 162 be modified in any way, such as by removing the copyright notice or 163 references to the Internet Society or other Internet organizations, 164 except as needed for the purpose of developing Internet standards in 165 which case the procedures for copyrights defined in the Internet Stan- 166 dards process must be followed, or as required to translate it into 167 languages other than English. 169 The limited permissions granted above are perpetual and will not be 170 revoked by the Internet Society or its successors or assigns. 172 This document and the information contained herein is provided on an "AS 173 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 174 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 175 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 176 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- 177 NESS FOR A PARTICULAR PURPOSE.