Internet DRAFT - draft-dhankins-dhcpinform-clarify
draft-dhankins-dhcpinform-clarify
Dynamic Host Configuration Working D. Hankins
Group ISC
Internet-Draft August 22, 2008
Updates: 2131 (if approved)
Intended status: Standards Track
Expires: February 23, 2009
Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications
draft-dhankins-dhcpinform-clarify-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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.
This Internet-Draft will expire on February 23, 2009.
Abstract
The DHCPINFORM message within the DHCPv4 protocol has in operation
diverged incompatibly from the previously defined standard, and some
questions about DHCPv4 server behaviour remain unclear.
Hankins Expires February 23, 2009 [Page 1]
Internet-Draft DHCPINFORM Clarify August 2008
Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 4
4. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 4
5. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Hankins Expires February 23, 2009 [Page 2]
Internet-Draft DHCPINFORM Clarify August 2008
1. Requirements Language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119].
2. Introduction
The most recent DHCPv4 Standard [RFC2131] added a new DHCPv4 message:
DHCPINFORM. The intent of the DHCPINFORM message was for clients
that used manually entered fixed IPv4 addresses to still be able to
get some configuration state dynamically. Since that time, however,
we have seen this message used by normal DHCPv4 dynamic addressing
clients; clients that have previously succeeded in receiving
configuration through DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and
finally DHCPACK messages.
These clients are attempting DHCPINFORM messages in order to obtain
additional configuration state that was not present in their lease
binding. The discovery is that DHCPINFORM can be used to reach extra
DHCP servers, other than the one that gave an address, which may have
more configuration options available but isn't in a position to give
addresses.
Some of these DHCPINFORM clients have surfaced which run with
stripped down user priveleges, but still performs some network
related functions. This software does not have the capacity to
determine its IPv4 address(es), nor does it know what interface(s)
are present on the system, or their Hardware (MAC) addresses. But it
can send and receive DHCP packets. Consequently, the 'ciaddr' and
'chaddr' fields have been witnessed to be empty, even though they are
required to be filled by RFC2131.
Another set of DHCP clients set the 'chaddr' field to a fixed magic
value, rather than the client's MAC address, identifying them as part
of a vendor's product. This is resulting from confusion about where
a DHCPv4 server should source the destination MAC address in any
replies it makes; from ARP [RFC0826], from the packet source field,
or from the chaddr contents.
We also wish to clarify the DHCPv4 server's behaviour when it
receives a DHCPINFORM via a relay - when 'giaddr' is set nonzero,
especially when the ciaddr and chaddr fields are zero or garbage.
Hankins Expires February 23, 2009 [Page 3]
Internet-Draft DHCPINFORM Clarify August 2008
3. Client Behaviour
Clients are still required to fulfill DHCPv4 Requirements [RFC2131]
for DHCPINFORM messages. But the following are clarified as in
addition, or to overlay those requirements:
o Clients SHOULD set 'ciaddr' to a working IPv4 address they can
receive replies on. Having done so, the client WILL receive
replies at this address. No other value is valid, but clients MAY
set the field zero if their IPv4 address is unknown.
o Clients SHOULD set 'chaddr', 'htype', and 'hlen' to the actual L2
address of the interface being used, and expect to receive replies
to. No other value is valid, but clients MAY set the fields all
zero if the hardware address is unknown.
o Clients MUST NOT set the 'BROADCAST' flag, unless the client is
not capable of receiving IPv4 unciasts, in which case it MUST set
the 'BROADCAST' flag.
o Clients SHOULD direct their DHCPINFORM via unicast UDP to the IPv4
address contained in the Server Identifier [RFC2132] option, if
they have an active binding.
4. Server Behaviour
DHCPv4 server behaviour in processing DHCPINFORM messages is a more
difficult question to answer, due to inconsistent client behaviour,
and conflicting directions in RFC2131. The following is intended to
be a more complete reference.
First, upon receiving a DHCPINFORM, a DHCPv4 Server MUST determine
the client's "relevant IPv4 address" according to the following in
order of priority:
1. The Subnet Selection Option [RFC3011], if it is present and
supported.
2. The 'ciaddr' field, if it is nonzero.
3. The Relay Agent Link Selection Sub-Option [RFC3046], if it is
present in a Relay Agent Information Option [RFC3046] in the
DHCPINFORM packet (never cached from a previous exchange).
4. The 'giaddr' field, if it is nonzero.
Hankins Expires February 23, 2009 [Page 4]
Internet-Draft DHCPINFORM Clarify August 2008
5. The IPv4 source address field, if it is nonzero.
6. The DHCPv4 Server's address on the interface the packet was
received upon.
The DHCPv4 server checks to see if the "relevant IPv4 address" is
within a range or subnet over which it holds authority, and is
configured to respond. It will manufacture a DHCPACK response with
configuration values appropriate for the "relevant IPv4 address".
In the manufactured response:
o The 'htype', 'hlen', 'chaddr', 'ciaddr', 'xid', 'flags' (with the
excpetion noted below), and 'giaddr' fields MUST be copied from
the client's DHCPINFORM.
o The 'hops' field MUST be zero.
o The 'secs' field MUST be zero.
o The 'yiaddr' field MUST be zero.
o The 'siaddr' field MUST be zero.
o The 'sname' field MUST be all-zeroes.
o The 'file' field MUST be all-zeroes.
o The 'options' field MUST be filled as described in RFC2131 Section
4.3.1.
Next, the DHCPv4 server MUST determine the "reply IPv4 address and
port" according to the following priority list:
1. The 'ciaddr' field and port 68 ('DHCP client'), if it is nonzero.
2. The 'giaddr' field and port 67 ('DHCP server'), if it is nonzero.
3. The IPv4 source address field and port 68 ('DHCP client'), if it
is nonzero.
4. The limited broadcast address (all ones) and port 68 ('DHCP
client').
Note very carefully that a DHCPv4 server will send replies directly
to a DHCPv4 client by way of 'ciaddr' even if the message is relayed.
Note that this means DHCPINFORM processing is intentionally broken in
deployments where the client's address space is unreachable by the
Hankins Expires February 23, 2009 [Page 5]
Internet-Draft DHCPINFORM Clarify August 2008
DHCPv4 server. In such cases, the server should probably be
configured not to reply to DHCPINFORMs.
Now, the server performs an exception to assist in relay agents. If
it selected the 'giaddr' as the destination address and port, then it
MUST set the 'BROADCAST' bit in the flags field true, no matter what
its value was in the client's DHCPINFORM message.
Having selected a destination IPv4 address and port number, the last
step is to select a destination link layer address. Here's where it
gets hard to figure out what order to put things in, the following
are what the author thinks needs to be covered.
The server is going to use a BSD socket probably to send the unicast
reply to any of the 'ciaddr', 'giaddr', or IP source address
versions. But it's advantageous to permit a server to send to the
chaddr contents or source MAC address when the client is directly
attached to avoid ARP broadcasts (and on some IP stacks, the ARP
table would have been filled on packet reception anyway).
Obviously the server is going to use the broadcast (all ones) MAC
address when the BROADCAST bit is set, or the limited broadcast
address is selected.
Under construction.
5. Notes
This section will self-destruct as (if) we near last-call. It is a
list of RFC2131 notations I've used as a guide to navigate this maze.
o Section 4.1: "If the BROADCAST bit is cleared to 0, the message
SHOULD be sent as an IP unicast to the IP address specified in the
'yiaddr' field and the link-layer address specified in the
'chaddr' field." But in other sections we say that 'yiaddr' is
set zero. So any message via a relay has to be broadcast in
response. I don't know if relays check for 'yiaddr' equal zero
and downgrade to broadcast, so I think it's best to set this bit
just to help them out (this is like DHCPNAK replies, where
'yiaddr' is also zero).
o Section 4.4.1, Table 5, uses the same column for both DHCPINFORM
and DHCPDISCOVER. It is clear that both DHCPINFORM and
DHCPDISCOVER make the same use of chaddr/htype/hlen. It is also
clear that 'ciaddr' is zero on DHCPDISCOVER - but very clearly
nonzero ("the client's network address") on DHCPINFORM. Since
this is in the same column, and uses a wording that is similar to
Hankins Expires February 23, 2009 [Page 6]
Internet-Draft DHCPINFORM Clarify August 2008
other columns (which have an "or" in them), it may be overlooked
if you weren't looking closely enough. In any case, 'ciaddr' very
clearly must not be zero as far as RFC2131 is concerned.
o Section 3.4: "Servers receiving a DHCPINFORM message construct a
DHCPACK message with any local configuration parameters
appropriate for the client without: allocating a new address,
checking for an existing binding, filling in 'yiaddr' or including
lease time parameters." ...snip... "The server SHOULD check the
network address in a DHCPINFORM message for consistency, but MUST
NOT check for an existing lease. The server forms a DHCPACK
message containing the configuration parameters for the requesting
client and sends the DHCPACK message directly to the client."
This is kind of problematic. Our DHCP software lets you scope
configuration parameters in a tree hierarchy, and ths includes
right on the lease itself. So the MUST NOT (and the non-normative
language before) that keeps us from checking for an existing lease
(very vague language) also means we may give different answers to
the same client at DORA time versus DHCPINFORM time. The client
actually over-writes its config with the DHCPINFORM values and
becomes broken. I think these two validations in RFC2131 can be
simplified to one validation, which is even simpler: The server
validates that the client's address is one which it is responsible
for configuring.
o Again Section 3.4: "The servers SHOULD unicast the DHCPACK reply
to the address given in the 'ciaddr' field of the DHCPINFORM
message." That 'SHOULD' kind of makes you wonder what /else/ you
would do.
o Section 4.3.5: "The server responds to a DHCPINFORM message by
sending a DHCPACK message directly to the address given in the
'ciaddr' field of the DHCPINFORM message. The server MUST NOT
send a lease expiration time to the client and SHOULD NOT fill in
'yiaddr'." So, a non-normative indication for 'ciaddr', followed
by a normative SHOULD NOT for 'yiaddr' (conflicts with non-
normative language in 3.4 above which makes it sound like yiaddr
is zeroed). Curious. Section 4.3.1 Table 3 seems to indicate
'yiaddr' is always set on DHCPACK to the "IP address assigned to
client", with no reservation for message type (other fields in
this table make distinctions for DHCPINFORM).
o Section 4.3.1 Table 3 lists in the DHCPACK column a lot of strange
values when processing a DHCPINFORM packet. Namely, "'xid' from
client DHCPREQUEST message". That is a strange thing to hang on
to from the previous DORA exchange, and it's supposed that a
client might not even do the DORA exchange (or might do it with a
different server). Obviously this was just overlooked, but it
Hankins Expires February 23, 2009 [Page 7]
Internet-Draft DHCPINFORM Clarify August 2008
brings everything in this table into question. We should remove
those questions.
6. Security Considerations
As with all DHCP messages, DHCPINFORM and DHCPACK replies contain no
capacity for encryption, and all packet contents must be presumed
readable in the clear. In particular, and as outlined above, in some
circumstances the packets may be broadcast and so more easily
intercepted than most other messges.
Authentication for DHCPv4 Messages [RFC3118] does exist, but is not
well deployed. Care should be taken in the degree to which
configuration parameters provided by DHCPv4 are trusted, as the
replies can be easily spoofed by any eavesdropper. Again noting that
packets may be broadcast under some circumstances, the BOOTP header
Transaction Id field ("XID") is insufficient protection from man in
the middle attacks.
A relay agent receives replies via unicast UDP messages from a DHCP
server, and may broadcast these packets on the inside-facing network.
If an outside attacker was aware of this relay agent and its unicast
address, this facility could be used to produce broadcast storms on
the network. Care should be taken to ensure that the relay agent is
not open to this kind of attack, possibly making use of Relay Agent
Authentication [RFC4030] to ensure that a DHCPv4 server can not be
induced to sending bogus replies to the relay.
7. IANA Considerations
This document has no action for IANA.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
Hankins Expires February 23, 2009 [Page 8]
Internet-Draft DHCPINFORM Clarify August 2008
[RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP",
RFC 3011, November 2000.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
8.2. Informative References
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for
the Dynamic Host Configuration Protocol (DHCP) Relay Agent
Option", RFC 4030, March 2005.
Author's Address
David W. Hankins
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
US
Phone: +1 650 423 1307
Email: David_Hankins@isc.org
Hankins Expires February 23, 2009 [Page 9]
Internet-Draft DHCPINFORM Clarify August 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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 FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Hankins Expires February 23, 2009 [Page 10]
