idnits 2.17.1 draft-ietf-dhc-client-id-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119], [RFC2131]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (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 (March 12, 2012) is 4418 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group N. Swamy 3 Internet-Draft Nokia 4 Updates: 2131 (if approved) G. Halwasia 5 Intended status: Standards Track P. Jhingran 6 Expires: September 13, 2012 Cisco Systems 7 March 12, 2012 9 Client Identifier Option in DHCP Server Replies 10 draft-ietf-dhc-client-id-02 12 Abstract 14 This document updates RFC2131 [RFC2131]. The changes to [RFC2131] 15 defined in this draft clarifies the use of 'client identifier' option 16 by the DHCP servers. The clarification addresses the issues arising 17 out of the point specified by [RFC2131] that the server 'MUST NOT' 18 return client identifier' option to the client. 20 Requirements 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in [RFC2119]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 13, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Proposed Modification To [RFC2131] . . . . . . . . . . . . . . 4 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 66 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 The Dynamic Host Configuration Protocol (DHCP) defined in [RFC2131] 72 provides configuration parameters to hosts on a TCP/IP based network. 73 DHCP is built on a client-server model, where designated DHCP server 74 allocate network addresses and deliver configuration parameters to 75 dynamically configured hosts. 77 The changes to [RFC2131] defined in this document clarifies the use 78 of 'client identifier' option by the DHCP servers. The clarification 79 addresses the issues arising out of the point specified by [RFC2131] 80 that the server 'MUST NOT' return client identifier' option to the 81 client and thus facilitates DHCP relay agents and hosts to process 82 downstream DHCP messages (DHCPOFFER,DHCPACK and DHCPNAK) when a DHCP 83 client sets the 'chaddr' field as zero in DHCP request messages. 85 2. Problem Statement 87 [RFC2131] specifies that a combination of 'client identifier' or 88 'chaddr' and assigned network address constitute a unique identifier 89 for the client's lease and are used by both the client and server to 90 identify a lease referred in any DHCP messages. [RFC2131] also 91 specifies that the server "MUST NOT" return 'client identifier' in 92 DHCPOFFER and DHCPACK messages. DHCP relay agents and servers, 93 following these recommendations MAY drop the DHCP packets in the 94 absence of both 'client identifier' and 'chaddr'. 96 In some cases, client may not be having valid hardware address value 97 to be filled in 'chaddr' field of the packet and hence may set this 98 field as zero. One such example is when DHCP is used to assign IP 99 address to a mobile phone or a tablet and where the 'chaddr' field is 100 set to zero in DHCP request packets. In such cases, client usually 101 sets the 'client identifier' option field (to a value as permitted in 102 [RFC2131]), and both client and server use this field to uniquely 103 identify the client with in a subnet. 105 Note that due to above mentioned recommendations in [RFC2131], valid 106 downstream DHCP packets (DHCPOFFER, DHCPACK and DHCPNAK) from the 107 server MAY get dropped at the DHCP relay agent in the absence of 108 'client identifier' option when 'chaddr' field is set as zero. 110 The problem may get aggravated when a client receives a response from 111 the server without 'client identifier' and with 'chaddr' value set to 112 zero, as it cannot guarantee that the response is intended for it. 113 This is because even though the 'xid' field is present to map 114 responses with requests, this field alone cannot guarantee that a 115 particular response is for a particular client, as 'xid' values 116 generated by multiple clients within a subnet need not be unique. 118 This document attempts to address these problems faced by DHCP relay 119 agent and client by proposing modification to DHCP server behavior. 120 The proposed solution is in line with DHCPv6 [RFC3315] where the 121 server always includes the Client Identifier option in the Reply 122 messages. 124 3. Proposed Modification To [RFC2131] 126 If the 'client identifier' option is set in a message received from a 127 client, the server MUST return the 'client identifier' option, 128 unaltered, in its response message. 130 Following table is extracted from section 4.3.1 of [RFC2131] and 131 relevant fields are modified accordingly to overcome the problems 132 mentioned in this document. 134 Option DHCPOFFER DHCPACK DHCPNAK 135 ------ --------- ------- ------- 136 Client identifier (if MUST MUST MUST 137 sent by client) 138 Client identifier (if MUST NOT MUST NOT MUST NOT 139 not sent by client) 141 4. IANA Considerations 143 This memo asks the IANA for no new parameters. 145 5. Security Considerations 147 No known security considerations. 149 6. Acknowledgements 151 The authors would like to thank Bernie Volz, Ted Lemon, Barr Hibbs 152 for their insightful discussions on the previous version of this 153 document. 155 7. Normative References 157 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 158 Requirement Levels", BCP 14, RFC 2119, March 1997. 160 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 161 RFC 2131, March 1997. 163 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 164 and M. Carney, "Dynamic Host Configuration Protocol for 165 IPv6 (DHCPv6)", RFC 3315, July 2003. 167 Authors' Addresses 169 Narasimha Swamy Nelakuditi 170 Nokia 171 Visiokatu 3 172 Tampere, 33720 173 Finland 175 Phone: +358 50487 2126 176 Email: narasimha.nelakuditi@nokia.com 178 Gaurav Halwasia 179 Cisco Systems 180 SEZ Unit, Cessna Business Park 181 Sarjapur Marathalli Outer Ring Road 182 Bangalore, 560103 183 India 185 Phone: +91 80 4426 1321 186 Email: ghalwasi@cisco.com 188 Prashant Jhingran 189 Cisco Systems 190 SEZ Unit, Cessna Business Park 191 Sarjapur Marathalli Outer Ring Road 192 Bangalore, 560103 193 India 195 Phone: +91 80 4426 1800 196 Email: pjhingra@cisco.com