[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]