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

From: "David W. Hankins" <[email-masked]>
Date: Tue, 10 Aug 2004 15:41:12 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 11 Aug 2004 17:58:04 -0400

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of David W. Hankins
> Sent: Tuesday, August 10, 2004 6:41 PM
> To: [email-masked]
> 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.
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Aug 2004 15:35:28 -0700

> expired. In particular, in section 2.4/2.5:

Yeah.   I don't have a lot of help to offer with this.   If a PXE 
client can't be configured with a specific client identifier, there's 
not a whole lot to be done about it.   It's definitely a mistake to 
just use the mac address as an identifier and ignore the client 
identifier.   Probably a post-boot client in a PXE environment should 
just use the identifier the PXE client used.   Such a client can't do 
ngtrans anyway, since its boot prom is IPv4-only.   Or if it can do 
ngtrans, the way to do it is to just get a restricted IPv4 address, 
load the O.S. , and then use the O.S. DHCP client to get a proper IP 
address, and throw away the address that PXE got.   You can easily hack 
most DHCP servers to allocate PXE addresses out of a non-routable 
subnet (e.g., 10.x.x.x).

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 11 Aug 2004 15:43:50 -0700

> draft-ietf-dhc-implementation-*.txt, though the (01) draft appears to have

I don't have a copy of that draft, so I can only guess that it
attempts to clarify the server's behaviour in regards to the original
Client Identifier?

How is that the right place for defining the expected behaviour of
the server when it encounters the v6 DUID from v4 clients that
previously were only identified by chaddr?

Sure, if we decide not to go ahead with the v6 DUID (not likely), I
think reviving that draft would be noble, but...I like the v6 DUID.

I think we should just define the sane and rational behaviour we
expect of the server when it encounters the mixed identities, since
we already appear to have a consensus on what that should be.

Sending the draft to RFC knowing full well we're going to have to
submit similar clarifying work on its contents later seems like a
lot more work to me.  We could just avoid all that.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Aug 2004 18:34:13 -0700

> we already appear to have a consensus on what that should be.

David, in the case you are describing, the DHCP client has no stable 
storage.   So there's no benefit to implementing the new client 
identifier type on that client.   The server's behavior towards clients 
that are out of compliance with the draft but do follow RFC2131/2132 is 
clearly stated in the draft.

A host operating system that has been booted by a PXE boot loader that 
does not comply with this draft, along with the PXE boot loader itself, 
together represent a system which can never be in compliance with this 
draft.   The host operating system should use the same identifier that 
the PXE client uses, whatever that is, and not make up its own.

If the host operating does in fact make up its own identifier, then we 
are talking about two different DHCP clients, one of which follows the 
spec, and one of which does not.   The two clients will get two 
different IP addresses.   There is no harm in this, unless you are 
concerned about excessive IP address consumption.   If you are 
concerned about that, there are stopgap solutions to get you over the 
hump until the last of those PXE cards dies a well-deserved death.

While I sympathize with the issue you are raising, before you go any 
further I would suggest that you read the problem statement, and then 
sit down and see if you can write text that resolves the issue you are 
raising in any better way than the current draft does, while at the 
same time not failing to meet the goals of the current draft.   When 
you haven't tried yourself to write the text that addresses a problem 
you're describing in the context of the draft to which you wish to add 
the text, it's easy to imagine that there is some solution that could 
be grafted onto any particular document.   It is by such mistakes that 
documents get delayed, sometimes forever, in their journey through the 
standards process.

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 11 Aug 2004 22:37:18 -0400

Perhaps I'm not understanding the issue fully, but isn't this a
problem if a client first sends NO client identifier (to boot)
and then (once the O/S is running) sends a client identifier?
Agreed that today many client identifiers are generated from
the hardware address and 3315id makes this more problematic
(since we don't want servers to look into the DUID) but this,
IMHO, is a general problem whenever this switch from no-client
identifier to client identifier happens. So, it is a general
DHCP issue not really specific to 3315id.

- Bernie

> Sent: Wednesday, August 11, 2004 6:44 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03
> 
> 
> > draft-ietf-dhc-implementation-*.txt, though the (01) draft 
> appears to 
> > have
> 
> I don't have a copy of that draft, so I can only guess that 
> it attempts to clarify the server's behaviour in regards to 
> the original Client Identifier?
> 
> How is that the right place for defining the expected 
> behaviour of the server when it encounters the v6 DUID from 
> v4 clients that previously were only identified by chaddr?
> 
> Sure, if we decide not to go ahead with the v6 DUID (not 
> likely), I think reviving that draft would be noble, but...I 
> like the v6 DUID.
> 
> 
> I think we should just define the sane and rational behaviour 
> we expect of the server when it encounters the mixed 
> identities, since we already appear to have a consensus on 
> what that should be.
> 
> Sending the draft to RFC knowing full well we're going to 
> have to submit similar clarifying work on its contents later 
> seems like a lot more work to me.  We could just avoid all that.
> 
> --

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 12 Aug 2004 08:51:00 -0700

> concerned about excessive IP address consumption.   If you are 

I'm really confused by this statement, because I thought I documented
the harm.

Go back and read what I said about Win XPe please?  I never answerd
your other mail because your recommendations about alternative actions
equally surprised me...they won't work.  You also seem fixated upon
having the PXE client send 'a different client identifier' when in fact
the problem is that it doesn't send that option at all, and the problem
would be made worse if it ever did.

So there's quite a lot of confusion floating around already.

To briefly restate, an undocumented behaviour which fixes this problem
without user intervention or new PXE clients has arisen in the majority
of DHCP servers.  At least one client has arisen (Win XPe) that relies
upon this behaviour in order to boot...at all.

So it is no longer about over-consumption of addresses.  That issue, and
the way that those servers choose to solve it for their paying customers,
is what has led us now to this impasse.

> hump until the last of those PXE cards dies a well-deserved death.

That will not happen.

I don't think that any iteration of 'dumb bootstrap device' will
ever learn anything more complicated than it absolutely has to, for
darn good reasons.  And I really doubt that Microsoft will ever make
something like a client identifier a user-configurable option (like
Apple does).

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 12 Aug 2004 09:13:50 -0700

> and then (once the O/S is running) sends a client identifier?

Yes, precisely.

> DHCP issue not really specific to 3315id.

I understand now, thanks Bernie.

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 12 Aug 2004 12:16:59 -0400

> And I really doubt that 
> Microsoft will ever make something like a client identifier a 
> user-configurable option (like Apple does).

Well, I don't know about Win XPe, but see
http://support.microsoft.com/default.aspx?scid=kb;en-us;172408.

- Bernie

> Sent: Thursday, August 12, 2004 11:51 AM
> To: [email-masked]
> Cc: [email-masked]
> I'm really confused by this statement, because I thought I 
> documented the harm.
> 
> Go back and read what I said about Win XPe please?  I never 
> answerd your other mail because your recommendations about 
> alternative actions equally surprised me...they won't work.  
> You also seem fixated upon having the PXE client send 'a 
> different client identifier' when in fact the problem is that 
> it doesn't send that option at all, and the problem would be 
> made worse if it ever did.
> 
> To briefly restate, an undocumented behaviour which fixes 
> this problem without user intervention or new PXE clients has 
> arisen in the majority of DHCP servers.  At least one client 
> has arisen (Win XPe) that relies upon this behaviour in order 
> to boot...at all.
> 
> So it is no longer about over-consumption of addresses.  That 
> issue, and the way that those servers choose to solve it for 
> their paying customers, is what has led us now to this impasse.
> 
> I don't think that any iteration of 'dumb bootstrap device' 
> will ever learn anything more complicated than it absolutely 
> has to, for darn good reasons.  And I really doubt that 
> Microsoft will ever make something like a client identifier a 
> user-configurable option (like Apple does).
> 
> --

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 12 Aug 2004 10:14:24 -0700

> http://support.microsoft.com/default.aspx?scid=kb;en-us;172408.

Sorry for not being clear, that's what I meant by "(like Apple does)".

Anything that starts with "run regedit" doesn't count, since that
does not pass the "Can you talk my Mom through doing it?" test.

Faced with that exact problem, of talking people no more computer-savvy
than an average person through doing it (no offence to average people),
ISP's using our server software choose to hack the server code and *remove
client id's entirely from packets they receive* rather than to talk
customers through making their windows boxes stop sending client-id's to
match their PXE instances.

Which, obviously, is very painful to hear, and why I'm keen to see
the more pallateable solution very clearly defined in rfc.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Aug 2004 11:28:34 -0700

> match their PXE instances.

You have ISP customers that do PXE booting on behalf of customers?   I 
am now deeply confused.   As far as talking your mother through it, 
when would you ever want to talk your mother through setting up a 
diskless boot client?

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 12 Aug 2004 15:10:24 -0700

On Thu, Aug 12, 2004 at 11:28:34AM -0700, Ted Lemon wrote:
> am now deeply confused.

I'm sorry, you have every right to be confused, my mind jumped here
halfway through the conversation and I never made mention of this.

I shouldn't have mentioned it, it's not important to this
discussion.

But it's an amusing story nonetheless.

A lone geek at a small ISP trying to horn in on the broadband space.
She has an arrangement with the last-mile supplier so that she gets
DHCP relays installed in every customer-prem.

She limits the number of leases to a fixed number per each relay-agent
id suboption.  Customers pay more for more leases.

Now imagine that one of the two following cases starts happening.

1) A misconfigured boot-order, or a system with an unusual (not IDE,
some kinda add-in card that maybe only gets tried in boot order because
the 'boot other devices' option set to enabled in the bios) arrangement
as a hard drive, results in having 'network' on its boot-order before
the hard drive in question.  PXE will try to boot, fail, then boot the
system on the hard drive.  This might be repeated for multiple network
interfaces, if any, but hopefully the customer doesn't have them all
plugged in.

2) A person with PXE clients at home has failed to segregate the
broadcast domain of their broadband connection's set-top box with
their pxe clients and the DHCP server they rely upon.  The PXE
client boots from the local dhcpd, then later from the ISP's,
but her DHCP server still sends out OFFERs.

Now imagine the lease limitation is full once the all the customer's
systems are online.

But the extra lease OFFERed to the PXE client means they are denied
booting before all their systems are up.

When I said "ISP's using our software", I should have just left it
at "users of", since I don't actually know from where the patches
came.  I just know that they're out there, and people are using it
(and being guided to use it)...it's just that this ISP thing latched
into my memory at that moment and I wasn't exercising enough
restraint at the keyboard.

Sorry about that, common disease for me I'm afraid.

> As far as talking your mother through it,

I was specifically referring to 'setting and unsetting the client
identifier' for reasons that are now hopefully somewhat less muddy.

There are lines in the sand everywhere as to whose burden it is to
bear support costs.  So long as the answer is 'regedit', the burden
of support is too great a cost for people to choose to bear.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Aug 2004 15:42:55 -0700

In the case of a PXE boot like the one you describe, the right answer 
for the ISP is to configure the DHCP server to put PXE clients in a 
special class, and not offer service to clients in that class.   Then 
you don't have to worry about inappropriately responding to PXE clients 
that you can't actually configure.   This is really the same problem as 
the well-known RAS server problem.

One nice side effect of ignoring PXE clients is that since the boot now 
has to time out, the user will probably notice the incorrect boot 
order.   This probably goes unnoticed with the current configuration 
because PXE probably gives up immediately when it gets a response with 
no PXE boot information in it.   An additional advantage of PXE is that 
it gives up quickly, so you don't have to worry about endless 
DHCPDISCOVERs in your log files.

My experience over the years is that when customers feel they need to 
hack the DHCP server sources, it's usually because they aren't aware 
that it's already possible to configure the server to address the 
problem they're having.   I think this is true somewhat independently 
of the server implementation - it's certainly just as true of the 
Nominum DHCP server as it is of the ISC DHCP server, and I think it's 
also true of Cisco's DHCP server.