idnits 2.17.1 draft-dhankins-dhcpinform-clarify-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 405. 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 draft header indicates that this document updates RFC2131, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 (August 22, 2008) is 5725 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration Working D. Hankins 3 Group ISC 4 Internet-Draft August 22, 2008 5 Updates: 2131 (if approved) 6 Intended status: Standards Track 7 Expires: February 23, 2009 9 Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications 10 draft-dhankins-dhcpinform-clarify-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on February 23, 2009. 37 Abstract 39 The DHCPINFORM message within the DHCPv4 protocol has in operation 40 diverged incompatibly from the previously defined standard, and some 41 questions about DHCPv4 server behaviour remain unclear. 43 Table of Contents 45 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 46 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 4 48 4. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 4 49 5. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 50 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 51 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 52 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 53 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 54 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 55 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 Intellectual Property and Copyright Statements . . . . . . . . . . 10 58 1. Requirements Language 60 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 61 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 62 described in BCP 14, RFC 2119 [RFC2119]. 64 2. Introduction 66 The most recent DHCPv4 Standard [RFC2131] added a new DHCPv4 message: 67 DHCPINFORM. The intent of the DHCPINFORM message was for clients 68 that used manually entered fixed IPv4 addresses to still be able to 69 get some configuration state dynamically. Since that time, however, 70 we have seen this message used by normal DHCPv4 dynamic addressing 71 clients; clients that have previously succeeded in receiving 72 configuration through DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and 73 finally DHCPACK messages. 75 These clients are attempting DHCPINFORM messages in order to obtain 76 additional configuration state that was not present in their lease 77 binding. The discovery is that DHCPINFORM can be used to reach extra 78 DHCP servers, other than the one that gave an address, which may have 79 more configuration options available but isn't in a position to give 80 addresses. 82 Some of these DHCPINFORM clients have surfaced which run with 83 stripped down user priveleges, but still performs some network 84 related functions. This software does not have the capacity to 85 determine its IPv4 address(es), nor does it know what interface(s) 86 are present on the system, or their Hardware (MAC) addresses. But it 87 can send and receive DHCP packets. Consequently, the 'ciaddr' and 88 'chaddr' fields have been witnessed to be empty, even though they are 89 required to be filled by RFC2131. 91 Another set of DHCP clients set the 'chaddr' field to a fixed magic 92 value, rather than the client's MAC address, identifying them as part 93 of a vendor's product. This is resulting from confusion about where 94 a DHCPv4 server should source the destination MAC address in any 95 replies it makes; from ARP [RFC0826], from the packet source field, 96 or from the chaddr contents. 98 We also wish to clarify the DHCPv4 server's behaviour when it 99 receives a DHCPINFORM via a relay - when 'giaddr' is set nonzero, 100 especially when the ciaddr and chaddr fields are zero or garbage. 102 3. Client Behaviour 104 Clients are still required to fulfill DHCPv4 Requirements [RFC2131] 105 for DHCPINFORM messages. But the following are clarified as in 106 addition, or to overlay those requirements: 108 o Clients SHOULD set 'ciaddr' to a working IPv4 address they can 109 receive replies on. Having done so, the client WILL receive 110 replies at this address. No other value is valid, but clients MAY 111 set the field zero if their IPv4 address is unknown. 113 o Clients SHOULD set 'chaddr', 'htype', and 'hlen' to the actual L2 114 address of the interface being used, and expect to receive replies 115 to. No other value is valid, but clients MAY set the fields all 116 zero if the hardware address is unknown. 118 o Clients MUST NOT set the 'BROADCAST' flag, unless the client is 119 not capable of receiving IPv4 unciasts, in which case it MUST set 120 the 'BROADCAST' flag. 122 o Clients SHOULD direct their DHCPINFORM via unicast UDP to the IPv4 123 address contained in the Server Identifier [RFC2132] option, if 124 they have an active binding. 126 4. Server Behaviour 128 DHCPv4 server behaviour in processing DHCPINFORM messages is a more 129 difficult question to answer, due to inconsistent client behaviour, 130 and conflicting directions in RFC2131. The following is intended to 131 be a more complete reference. 133 First, upon receiving a DHCPINFORM, a DHCPv4 Server MUST determine 134 the client's "relevant IPv4 address" according to the following in 135 order of priority: 137 1. The Subnet Selection Option [RFC3011], if it is present and 138 supported. 140 2. The 'ciaddr' field, if it is nonzero. 142 3. The Relay Agent Link Selection Sub-Option [RFC3046], if it is 143 present in a Relay Agent Information Option [RFC3046] in the 144 DHCPINFORM packet (never cached from a previous exchange). 146 4. The 'giaddr' field, if it is nonzero. 148 5. The IPv4 source address field, if it is nonzero. 150 6. The DHCPv4 Server's address on the interface the packet was 151 received upon. 153 The DHCPv4 server checks to see if the "relevant IPv4 address" is 154 within a range or subnet over which it holds authority, and is 155 configured to respond. It will manufacture a DHCPACK response with 156 configuration values appropriate for the "relevant IPv4 address". 158 In the manufactured response: 160 o The 'htype', 'hlen', 'chaddr', 'ciaddr', 'xid', 'flags' (with the 161 excpetion noted below), and 'giaddr' fields MUST be copied from 162 the client's DHCPINFORM. 164 o The 'hops' field MUST be zero. 166 o The 'secs' field MUST be zero. 168 o The 'yiaddr' field MUST be zero. 170 o The 'siaddr' field MUST be zero. 172 o The 'sname' field MUST be all-zeroes. 174 o The 'file' field MUST be all-zeroes. 176 o The 'options' field MUST be filled as described in RFC2131 Section 177 4.3.1. 179 Next, the DHCPv4 server MUST determine the "reply IPv4 address and 180 port" according to the following priority list: 182 1. The 'ciaddr' field and port 68 ('DHCP client'), if it is nonzero. 184 2. The 'giaddr' field and port 67 ('DHCP server'), if it is nonzero. 186 3. The IPv4 source address field and port 68 ('DHCP client'), if it 187 is nonzero. 189 4. The limited broadcast address (all ones) and port 68 ('DHCP 190 client'). 192 Note very carefully that a DHCPv4 server will send replies directly 193 to a DHCPv4 client by way of 'ciaddr' even if the message is relayed. 194 Note that this means DHCPINFORM processing is intentionally broken in 195 deployments where the client's address space is unreachable by the 196 DHCPv4 server. In such cases, the server should probably be 197 configured not to reply to DHCPINFORMs. 199 Now, the server performs an exception to assist in relay agents. If 200 it selected the 'giaddr' as the destination address and port, then it 201 MUST set the 'BROADCAST' bit in the flags field true, no matter what 202 its value was in the client's DHCPINFORM message. 204 Having selected a destination IPv4 address and port number, the last 205 step is to select a destination link layer address. Here's where it 206 gets hard to figure out what order to put things in, the following 207 are what the author thinks needs to be covered. 209 The server is going to use a BSD socket probably to send the unicast 210 reply to any of the 'ciaddr', 'giaddr', or IP source address 211 versions. But it's advantageous to permit a server to send to the 212 chaddr contents or source MAC address when the client is directly 213 attached to avoid ARP broadcasts (and on some IP stacks, the ARP 214 table would have been filled on packet reception anyway). 216 Obviously the server is going to use the broadcast (all ones) MAC 217 address when the BROADCAST bit is set, or the limited broadcast 218 address is selected. 220 Under construction. 222 5. Notes 224 This section will self-destruct as (if) we near last-call. It is a 225 list of RFC2131 notations I've used as a guide to navigate this maze. 227 o Section 4.1: "If the BROADCAST bit is cleared to 0, the message 228 SHOULD be sent as an IP unicast to the IP address specified in the 229 'yiaddr' field and the link-layer address specified in the 230 'chaddr' field." But in other sections we say that 'yiaddr' is 231 set zero. So any message via a relay has to be broadcast in 232 response. I don't know if relays check for 'yiaddr' equal zero 233 and downgrade to broadcast, so I think it's best to set this bit 234 just to help them out (this is like DHCPNAK replies, where 235 'yiaddr' is also zero). 237 o Section 4.4.1, Table 5, uses the same column for both DHCPINFORM 238 and DHCPDISCOVER. It is clear that both DHCPINFORM and 239 DHCPDISCOVER make the same use of chaddr/htype/hlen. It is also 240 clear that 'ciaddr' is zero on DHCPDISCOVER - but very clearly 241 nonzero ("the client's network address") on DHCPINFORM. Since 242 this is in the same column, and uses a wording that is similar to 243 other columns (which have an "or" in them), it may be overlooked 244 if you weren't looking closely enough. In any case, 'ciaddr' very 245 clearly must not be zero as far as RFC2131 is concerned. 247 o Section 3.4: "Servers receiving a DHCPINFORM message construct a 248 DHCPACK message with any local configuration parameters 249 appropriate for the client without: allocating a new address, 250 checking for an existing binding, filling in 'yiaddr' or including 251 lease time parameters." ...snip... "The server SHOULD check the 252 network address in a DHCPINFORM message for consistency, but MUST 253 NOT check for an existing lease. The server forms a DHCPACK 254 message containing the configuration parameters for the requesting 255 client and sends the DHCPACK message directly to the client." 256 This is kind of problematic. Our DHCP software lets you scope 257 configuration parameters in a tree hierarchy, and ths includes 258 right on the lease itself. So the MUST NOT (and the non-normative 259 language before) that keeps us from checking for an existing lease 260 (very vague language) also means we may give different answers to 261 the same client at DORA time versus DHCPINFORM time. The client 262 actually over-writes its config with the DHCPINFORM values and 263 becomes broken. I think these two validations in RFC2131 can be 264 simplified to one validation, which is even simpler: The server 265 validates that the client's address is one which it is responsible 266 for configuring. 268 o Again Section 3.4: "The servers SHOULD unicast the DHCPACK reply 269 to the address given in the 'ciaddr' field of the DHCPINFORM 270 message." That 'SHOULD' kind of makes you wonder what /else/ you 271 would do. 273 o Section 4.3.5: "The server responds to a DHCPINFORM message by 274 sending a DHCPACK message directly to the address given in the 275 'ciaddr' field of the DHCPINFORM message. The server MUST NOT 276 send a lease expiration time to the client and SHOULD NOT fill in 277 'yiaddr'." So, a non-normative indication for 'ciaddr', followed 278 by a normative SHOULD NOT for 'yiaddr' (conflicts with non- 279 normative language in 3.4 above which makes it sound like yiaddr 280 is zeroed). Curious. Section 4.3.1 Table 3 seems to indicate 281 'yiaddr' is always set on DHCPACK to the "IP address assigned to 282 client", with no reservation for message type (other fields in 283 this table make distinctions for DHCPINFORM). 285 o Section 4.3.1 Table 3 lists in the DHCPACK column a lot of strange 286 values when processing a DHCPINFORM packet. Namely, "'xid' from 287 client DHCPREQUEST message". That is a strange thing to hang on 288 to from the previous DORA exchange, and it's supposed that a 289 client might not even do the DORA exchange (or might do it with a 290 different server). Obviously this was just overlooked, but it 291 brings everything in this table into question. We should remove 292 those questions. 294 6. Security Considerations 296 As with all DHCP messages, DHCPINFORM and DHCPACK replies contain no 297 capacity for encryption, and all packet contents must be presumed 298 readable in the clear. In particular, and as outlined above, in some 299 circumstances the packets may be broadcast and so more easily 300 intercepted than most other messges. 302 Authentication for DHCPv4 Messages [RFC3118] does exist, but is not 303 well deployed. Care should be taken in the degree to which 304 configuration parameters provided by DHCPv4 are trusted, as the 305 replies can be easily spoofed by any eavesdropper. Again noting that 306 packets may be broadcast under some circumstances, the BOOTP header 307 Transaction Id field ("XID") is insufficient protection from man in 308 the middle attacks. 310 A relay agent receives replies via unicast UDP messages from a DHCP 311 server, and may broadcast these packets on the inside-facing network. 312 If an outside attacker was aware of this relay agent and its unicast 313 address, this facility could be used to produce broadcast storms on 314 the network. Care should be taken to ensure that the relay agent is 315 not open to this kind of attack, possibly making use of Relay Agent 316 Authentication [RFC4030] to ensure that a DHCPv4 server can not be 317 induced to sending bogus replies to the relay. 319 7. IANA Considerations 321 This document has no action for IANA. 323 8. References 325 8.1. Normative References 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 331 RFC 2131, March 1997. 333 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 334 Extensions", RFC 2132, March 1997. 336 [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", 337 RFC 3011, November 2000. 339 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 340 RFC 3046, January 2001. 342 8.2. Informative References 344 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 345 converting network protocol addresses to 48.bit Ethernet 346 address for transmission on Ethernet hardware", STD 37, 347 RFC 826, November 1982. 349 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 350 Messages", RFC 3118, June 2001. 352 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 353 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 354 Option", RFC 4030, March 2005. 356 Author's Address 358 David W. Hankins 359 Internet Systems Consortium, Inc. 360 950 Charter Street 361 Redwood City, CA 94063 362 US 364 Phone: +1 650 423 1307 365 Email: David_Hankins@isc.org 367 Full Copyright Statement 369 Copyright (C) The IETF Trust (2008). 371 This document is subject to the rights, licenses and restrictions 372 contained in BCP 78, and except as set forth therein, the authors 373 retain all their rights. 375 This document and the information contained herein are provided on an 376 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 377 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 378 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 379 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 380 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 381 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 383 Intellectual Property 385 The IETF takes no position regarding the validity or scope of any 386 Intellectual Property Rights or other rights that might be claimed to 387 pertain to the implementation or use of the technology described in 388 this document or the extent to which any license under such rights 389 might or might not be available; nor does it represent that it has 390 made any independent effort to identify any such rights. Information 391 on the procedures with respect to rights in RFC documents can be 392 found in BCP 78 and BCP 79. 394 Copies of IPR disclosures made to the IETF Secretariat and any 395 assurances of licenses to be made available, or the result of an 396 attempt made to obtain a general license or permission for the use of 397 such proprietary rights by implementers or users of this 398 specification can be obtained from the IETF on-line IPR repository at 399 http://www.ietf.org/ipr. 401 The IETF invites any interested party to bring to its attention any 402 copyrights, patents or patent applications, or other proprietary 403 rights that may cover technology that may be required to implement 404 this standard. Please address the information to the IETF at 405 ietf-ipr@ietf.org.