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

["Bernie Volz" <[e-mail]>]

I believe this really is more appropriate in
draft-ietf-dhc-implementation-*.txt, though the (01) draft appears to have
expired. In particular, in section 2.4/2.5:

          2.4. The Client Hardware Address, "chaddr"......................7 
          2.5. The DHCP Client Identifier.................................7 
            2.5.1. Uniqueness............................................7 
            2.5.2. Prohibition in DHCPOFFER and DHCPACK..................8 

This really has little to do with defining a DHCPv6 DUID for DHCPv4 clients.

Best regards,

Bernie Volz

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of David W. Hankins
> Sent: Tuesday, August 10, 2004 6:41 PM
> To: [e-mail]
> Subject: [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
> 


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg