Client Identifier Option in DHCP
Server RepliesSamsung IndiaBlock-B, Bagmane Lakeview,66/1, Bagmane Tech Park,Byrasandra, C.V. Raman Nagar, Bangalore560093India+91 80 4181 9999nn.swamy@samsung.comCisco SystemsSEZ Unit, Cessna Business ParkSarjapur Marathalli Outer Ring RoadBangalore560103India+91 80 4426 1321ghalwasi@cisco.comCisco SystemsSEZ Unit, Cessna Business ParkSarjapur Marathalli Outer Ring RoadBangalore560103India+91 80 4426 1800pjhingra@cisco.com
Internet Engineering Task Force
DHC Working GroupThis document updates RFC 2131 -- Dynamic Host Configuration Protocol
(DHCP) -- by addressing the issues arising from that document's
specification that the server MUST NOT return the 'client identifier'
option to the client.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 .The Dynamic Host Configuration Protocol (DHCP) defined in [RFC2131]
provides configuration parameters to hosts on an IP based network. DHCP
is built on a client-server model, where designated DHCP servers
allocate network addresses and deliver configuration parameters to
dynamically configured hosts.The changes to [RFC2131] defined in this document clarify the use of
the 'client identifier' option by the DHCP servers. The clarification
addresses the issues (as mentioned in Problem Statement) arising out of
the point specified by [RFC2131] that the server 'MUST NOT' return
'client identifier' option to the client.[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. Furthermore, DHCP relay agents and servers
implementing [RFC2131] "MAY" drop the DHCP packets in the absence of
both 'client identifier' and 'chaddr'.In some cases, a client may not have a valid hardware address to
populate the 'chaddr' field and may set the field to all zeroes. 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.Note that due to above mentioned recommendations in [RFC2131], valid
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.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.Lack of 'client identifier' option in DHCP reply messages also
affects the scenario where multiple DHCP clients may be running on the
same host sharing the same 'chaddr'.This document attempts to address these problems faced by DHCP relay
agent and client by proposing modification to DHCP server behavior. The
solution specified in this document is in line with DHCPv6 [RFC3315]
where the server always includes the Client Identifier option in the
Reply messages.The requirement for DHCP servers not to return the 'client
identifier' option was made purely to conserve the limited space in the
packet. It is possible, though unlikely, that clients will drop packets
that contain this formerly unexpected option. There are no known client
implementations that will drop packets but the benefit provided by this
change outweighs any small risk of such behavior. More harm is being
done by not having the 'client identifier' option present than might be
done by adding it now.If the 'client identifier' option is present in a message received
from a client, the server MUST return the 'client identifier' option,
unaltered, in its response message.Following table is extracted from section 4.3.1 of [RFC2131] and
relevant fields are modified accordingly to overcome the problems
mentioned in this document.When a client receives a DHCP message containing a 'client
identifier' option, the client MUST compare that client identifier to
the one it is configured to send. If the two client identifiers do not
match, the client MUST silently discard the message.This memo asks the IANA for no new parameters.This specification does not add any new security considerations other
than the ones already mentioned in [RFC2131]. It is worth noting that
DHCP clients routinely connect to different IP networks managed by
different network providers. DHCP clients have no a priori knowledge of
which network they are connecting to. Consequently, the client
identifier will, by definition, be routinely shared with network
operators and could be used in ways that violate the user's privacy.
This is a problem that existed in [RFC2131]. This document does nothing
to address this problem.The authors would like to thank Bernie Volz, Ted Lemon, Barr Hibbs,
Richard Johnson, Barry Leiba, Stephen Farrell, Adrian Farrel for
insightful discussions and review.