[dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03

I'm surprised this hasn't been discussed...if it has, and I just missed
it, please forgive me.

Today, there exists a corner case in rfc2131 Client Identifiers that
is not clearly defined:

In the case where a unique client, probably during its bootstrap [1],
should first contact the DHCP server without providing a Client
Identifier, and then later contacts the DHCP server again this time
using a Client Identifier.  The chaddr remains the same between each.

In reading rfc2131, it is my estimation that the two are to be
treated as unique clients, and each should therefore be offered a
unique address.  But this is never spelled out.

ISC's DHCP server conforms with this interpretation [2].  But, the
userbase does not agree in practice.  By and large, users expect these
two instances of the same client to be granted the same lease.

Several (I think "all but ISC's") DHCP server implementations have taken
this alternate path, and will give the same address to both clients.
The specifics are split into two camps, or so I perceive:

The first camp simply ignores any client identifier which adheres to the
'chaddr' convention.  This means that both instances of the client are
identified by 'chaddr' only.

The other camp searches for a lease for a client first by client-id, if
the client supplied it, and then by chaddr.  If the lease that was found
was given to a client with an id, it will still be offered to client
without an id based solely on chaddr.  If the lease that was found was
given to a client without an id, it will still be offered to a client
that provides one so long as chaddr matches.

Also, at least one client implentation [3] has surfaced to my attention
which also depends upon this behaviour.

This draft, since it is editing the Client-Identifier definition,
could speak to what the server should do in the case where one client
identifier is the 'chaddr' convention (it sounds perfectly reasonable
to simply ignore all of these, and make them a synonym for chaddr).

It could also speak to what the server should do in our brave new future,
when the PXE clients that exist still today and don't send client-ids are
mixed with new host operating systems that will send the new id this
draft defines.  The upgrade path for PXE is not as easy as the host
operating systems, and no doubt will lag several years behind adoption
by operating systems.

It does neither, and obviously I think it should at least do one of
those.

I'm willing to recommend verbage after discussion.

[1] Intel PXE clients do not send a Client Identifier, but many host
    operating systems which they pass execution to are infected with
    the 'send chaddr as Client Identifier' disease.  The result is
    that such boxes burn two IP addresses.

[2] Make no mistake, I did not write this code, I merely agree with
    its interpretation of the RFC's.

[3] A Microsoft Windows product (XPe I think it is called) designed
    for Embedded Systems not only expects to be booted within a PXE
    environment, and provides chaddr as its client-identifier...but
    gets its initial address from the PXE environment and will not
    act upon any OFFER that does not provide the same address (it
    seems it can read state from PXE, but it cannot over-ride what
    it has learned from same, as if the network device is no longer
    under its control).  So if it were to speak to a DHCP server that
    intended a new address for it, it would never escape INIT state
    (it sits there sending a DISCOVER every few seconds with a
    requested-address option set).

-- 
David W. Hankins		"If you don't do it right the first time,
Operations Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins