DHC Working Group Ted Lemon
INTERNET DRAFT Nominum
Expires: July 2004 Bill Sommerfeld
Internet Draft Sun Microsystems
Document: <draft-lemon-dhcpv4-to-v6-id-trans-00.txt>
Category: Standards Track January, 2004
Transition from RFC2131-style to RFC3315-style
Client Identifiers for DHCPv4.
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Abstract
This document explores ways for a node that is configured using
DHCP and that has in the past been configured using one of the
client identification schemes described in RFC2131 and RFC2132 to
make the transition to using the identification scheme described in
RFC3315 and in draft-ietf-dhc-3315-id-for-v4.txt.
1. Problem Statement
The DHCPv4 protocol specification [RFC2131, RFC2132] and the
DHCPv6 protocol specification [RFC3315] both describe ways that
DHCP clients can identify themselves to DHCP servers.
Unfortunately, the methods described in these specifications are
incompatible - a node that identifies itself according to the
mechanism specified in RFC3315 will use different identification
information than a node that identifies itself according to
RFC2131/RFC2132, and it's not possible to describe a method for
converting between the two types of identification.
The internet-draft, Node-Specific Client Identifiers for DHCPv4
[NODSPC], defines a new client identifier for DHCPv4 that is
derived identically to the identifier used in DHCPv6. DHCPv4
clients that identify themselves using this method can have
identifiers that are the same as the identifier sent by a DHCPv6
client running on the same node.
Lemon & Sommerfeld Expires July, 2004 [Page 1]
Internet-Draft RFC2131/RFC3315 DHCP Id Transition January 2003
There is a problem with this, however. At the time that this
document is being written, there are no DHCPv4 clients that use
the mechanism described in [NODSPC]. In the case of IPv4-only
nodes that will never run a DHCPv6 client, this is not a
problem.
However, in the case where the node may be updated to run both IPv4
and IPv6, it may be useful for the DHCPv4 client to change client
identifiers so that its client identifier is compatible with the
one used by the DHCPv6 client. When it does this, any state on
the DHCP server that is associated with the old client identifier
will be lost. For example, the IP address formerly assigned to
the client will not continue to be assigned to the client, and if
the client has a domain name registered in the DNS, the client's
association with that name will be lost.
An additional problem is that in administrative domains where long
leases are assigned, when a client changes its client identifier,
the server will wind up allocating it a second lease. If a large
number of clients in a single administrative domain make the
migration to new identifiers at the same time, this could result
in address depletion. A more short-lived version of this problem
can also happen in environments where DHCP servers implement
per-customer lease limiting - because the lease limit per customer
is probably quite small, when a customer attempts to migrate,
there may not be an additional lease to allocate to the new client
identifier until the lease associated with the old identifier is
freed.
2. Applicability
This draft proposes a number of solutions to the stated
problem. The intention of the authors is that once one of these
solutions is chosen, the draft should go to standards track.
3.. Proposed Solutions
3.1. Do Nothing
One answer to this problem is to just switch client identifiers,
but not do anything special to migrate resources associated with
the client identifier. The way this will play out is as follows:
- The client will get a new IP address, if one is available.
- While the old lease is valid, any resources associated with it
(e.g., the client's domain name) will be unavailable to the
client.
- Once the old lease has expired, these resources (particularly the
- client's domain name) will be available for any client to claim.
- If a different client attempts to claim these resources first,
that client will get them.
Lemon & Sommerfeld Expires July, 2004 [Page 2]
Internet-Draft RFC2131/RFC3315 DHCP Id Transition January 2003
- If no other client attempts to claim the resources, the original
client will reclaim them the first time it renews after the old
lease has expired.
On networks where the client's IP address is not precious (for
example, many NATted networks) and where the DHCP server does not
maintain any other resources (e.g., domain names) on behalf of the
client, this method is probably the best one, because it requires
the least effort from the client and server.
3.2. Propose New Identifier in DHCPREQUEST
Another answer to the problem is to require the client to send a
DHCPREQUEST to transfer the resources to a new client identifier.
The DHCPREQUEST message would send the old identifier in the
client identifier option, and would send the proposed new
identifier in a newly-defined option.
If the server supports the transition option, it sends back a
DHCPACK with the new client identifier in the
dhcp-client-identifier option. If it does not support the
transition option, it either does not send back a client
identifier option, or sends back a client identifier option that
contains the old client identifier. RFC2131 specifies the former
behavior, but some existing DHCP server implementations send the
client identifier anyway, so the client should be prepared for
either possibility.
If the response indicates that the server doesn't support the
transition option, the client sends a DHCPRELEASE to release the
lease and the resources associated with it, and then issues a
DHCPDISCOVER using the new identifier to acquire a new lease. It
uses the requested-address option to try to get the server to
assign it the same lease. The DHCPRELEASE attempts to assure that
any resources that are allocated to the client are released before
the new identifier is used.
If, when the client is directed to change to the new identifier,
it does not have a valid lease, it acquires a lease using the old
client identifier and then follows the procedure described above.
Once a client that implements this method has made the transition
one time, it always uses the new identifier in any subsequent DHCP
messages, even if the server with which it is communicating
changes.
This proposal works quite nicely for a DHCP client that is always
in the same administrative domain. Such a client will never have
more than one outstanding lease. This case coincides with the
most likely case where the client is going to care about getting a
consistent IP address. Clients that roam between administrative
domains probably do not benefit very much either from having a
stable IP address or from having the DHCP server maintain the
Lemon & Sommerfeld Expires July, 2004 [Page 3]
Internet-Draft RFC2131/RFC3315 DHCP Id Transition January 2003
client's name in the DNS. So although this solution does not
address all possible cases, it is nevertheless probably good
enough.
3.3. Send Old Client Identifier
Another answer to the problem is for the client to send the new
client identifier in the client-identifier option in any DHCP
messages it sends after the transition has been made. In addition,
it sends the old client identifier in a new option. When a
compliant server looks up the client, it looks both under the old
client identifier and under the new client identifier. If it finds
the lease under the old identifier, it converts it to the new
identifier. If it finds leases under both identifiers, the server
uses the one that's associated with the new identifier and does
nothing to the lease associated with the old identifier.
A client that implements this method needs to keep track of the
last expiry time of a lease that was acquired under the old
client identifier. Until that lease time has expired, it must
continue to send the old client identifier option in every DHCP
message it sends. After that time has expired, it can forget
that it ever used the old identifier.
This solution has the advantage that if a client has more than one
outstanding lease recorded under the old identifier, it will
potentially be able to reclaim all of those leases. One
disadvantage is that leases held by non-compliant servers are
never upgraded. Another disadvantage is that the client has to
keep track of old leases, and it's possible that many existing
clients do not keep track of this information, and thus would not
be able to determine when it would be safe to stop sending the old
client identifier.
3.4. Probe for Leases Under Old Identifier
This is a more elaborate version of the solution described in
section 3.2. In this case, the client remembers all the leases it
had. When it attaches to a new network segment, it sends a
DHCPDISCOVER under the old client identifier, including the new
client identifier option as described in section 3.2. If it gets a
DHCPOFFER listing one of the leases it remembers, it acquires that
lease and then converts it using the method described in section
3.2. It then removes the lease from its list of leases that need
to be converted.
If the client doesn't recognize the lease it gets, it converts it
anyway, as described in section 3.2. Leases that are acquired
during the probing process are never _added_ to the list of leases
needing to be converted.
If the server has a IP address associated with the new identifier,
it sends that IP address to the client. In that case the client
just starts using that lease.
Lemon & Sommerfeld Expires July, 2004 [Page 4]
Internet-Draft RFC2131/RFC3315 DHCP Id Transition January 2003
When any lease on the list of leases to be converted expires, the
client removes that lease from the list. When the list of leases
to be converted is empty, the client no longer attempts to probe -
at that point it is free to use the new client identifier, and need
no longer remember that it made a transition from a different
identifier.
This solution eliminates the problem with the solution proposed in
section 3.2, that only one lease can be converted. Thus, a
roaming client can be sure that it will not run into problems.
The downside to this proposal is that it required a great deal of
the client. The advantage is that it is completely compatible
with the solution proposed in section 3.2, which means that the
implementor has the option of implementing either proposal.
4. Recommendations
The solutions proposed in sections 3.2 and 3.4 are compatible,
and solve the stated problem nicely. So if a solution is to be
implemented, it seems that pursuing one or both of these
solutions would be the right thing to do. However, it's a lot
of trouble to implement this, so it's worth discussing whether or
not there's any advantage to undertaking this work, or whether it
would be better not to try to solve this problem.
5. Security Considerations
This draft introduces a new mechanism by which a malicious DHCP
client could steal resources from an existing client. Currently, a
malicious DHCP client that knows the client identifier of another
client can send a DHCPRELEASE message to release the resources
associated with that lease, and then send a DHCPDISCOVER message
and attempt to acquire that client's lease. Using the mechanism
proposed in sections 3.2 and 3.3, a malicious client could steal a
lease in a single transaction, rather than using two transactions.
It's not clear that this makes any difference - in order to avoid
having this happen, the DHCP protocol needs to be protected with
some kind of authentication scheme, for example the one defined in
the DHCP Authentication specification [RFC3118]. It does not
appear to be the case that that this proposal adds any new
vulnerability.
6. IANA Considerations
This document may define a new DHCP option, and the code for that
option would need to be assigned by the IANA.
Lemon & Sommerfeld Expires July, 2004 [Page 5]
Internet-Draft RFC2131/RFC3315 DHCP Id Transition January 2003
7. Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC2132, March, 1997
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
Carney, M., "Dynamic Host Configuration Protocol for
IPv6 (DHCPV6)", July, 2003
[NODSPC] Lemon, E., Sommerfeld, W., "Node-Specific Client
Identifiers for DHCPv4", draft-ietf-dhc-3315id-for-v4.txt,
January, 2004
8. Informative References
[RFC3118] Droms, R., Arbaugh, W., "Authentication for DHCP
Messages", RFC3118, June, 2001
Author's Addresses
Ted Lemon
Nominum
2385 Bay Road
Redwood City, CA 94063 USA
+1 650 381 6000
mellon@nominum.com
Bill Sommerfeld
Sun Microsystems
1 Network Drive
Burlington, MA 01824
+1 781 442 3458
sommerfeld@sun.com
Full Copyright Statement
"Copyright (C) 2003, 2004 The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
Lemon & Sommerfeld Expires July, 2004 [Page 6]
Internet-Draft RFC2131/RFC3315 DHCP Id Transition January 2003
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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."
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lemon & Sommerfeld Expires July, 2004 [Page 7]