Subject: [dhcwg] Usage of the Client ID in RFC 2131

From: Andre Kostur <[email-masked]>
Date: Thu, 13 Jul 2006 05:53:53 -0700

Another item for consideration in the implemetation issues draft:

RFC 2131 uses the following language:

   If the client uses a 'client identifier' in
   one message, it MUST use that same identifier in all subsequent
   messages, to ensure that all servers correctly identify the client.

This seems to leave open the possibility that the client could start 
their DHCP transactions without specifying a Client ID, and then later 
on start using the Client ID, and expect to be able to continue using 
the same lease.  This leads to the following potential sequence of events:

1) A device does a DISCOVER w/out specifying a Client ID
2) That device receives the OFFER and performs a REQUEST specifying a 
Client ID (using htype/chaddr composition)
3) That device later restarts the sequence (but still within its lease 
time) and sends a DISCOVER w/out specifying a Client ID
4) That device receives the OFFER and performs a REQUEST specifying 
either the same, or different Client ID.

At step 3, should the server assign a new IP, or reuse the existing 
lease?  If it reuses the same lease, what if in the next step it does a 
REQUEST with a different Client ID?  If it assigns the same lease, what 
if it requests with the Client ID used in #2?

Either we have reassigned the lease from one device to another (Client 
ID in 2 isn't the same as the Client ID in 4), or the device gets two 
leases on the same subnet.

Perhaps the wording around Client IDs should be instead:

   If the client wishes to use a 'client identifier', it MUST use that 
same identifier in
   all DHCP messages, to ensure that all servers correctly identify the 
client.

We have experienced clients which don't supply a Client ID in the 
DISCOVER, but do start using it later (I'd have to look back whether the 
REQUEST in the SELECTING state had a Client ID, or did the client wait 
until RENEW before starting to use the Client ID).
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Andre Kostur <[email-masked]>
Date: Thu, 13 Jul 2006 07:19:11 -0700

Ted Lemon wrote:
> Andre Kostur wrote:
> Switching identifiers in the middle of the four-way handshake is just
> stupid.   Changing the language of the RFC probably won't help, because
> the author of the broken client isn't going to read it anyway.
>   

Granted, but since the implementation issues draft is being looked at, 
perhaps there should be more explicit discussions about this topic in 
that document?  I just looked over the implementation issues draft 
again, and it seems to mention 4361 only in passing in the changelog, 
and section 4.5 seems to only discuss the uniqueness of Client IDs (and 
whether Client IDs should be in OFFERs and ACKs), and not about whether 
the Client ID should always be present.

> This brokenness is documented and "fixed" in RFC4361.   So I don't think
> there's a need to do an independent fix.   People who are implementing
> new clients and grok how IETF works will follow RFC4361.   People who
> don't grok how IETF works probably won't notice any draft that updates
> RFC2131/2312.
>
> As for what you should do, probably the reason that this client got out
> with this bug in it is that the Microsoft DHCP server treats, for
> example, an ethernet address of 01:02:03:04:05:06 as being the same as a
> client identifier of 01:01:02:03:04:05:06.   So if the client switches
> in midstream, but the client identifier it adds is based on the hardware
> address, then it will Just Work.   This is a very common situation, so I
> think this is a good workaround for the problem.   But see RFC4361 for
> additional discussion about this problem.

(Note that to work around a broken client, we had to do the same thing 
in our server)

Perhaps then the implementation issues document should mention this 
workaround, and specify that new development/implementations SHOULD use 
4361?
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jul 2006 10:53:52 -0400

> the Client ID should always be present.

The danger here is that if what the implementation issues draft
recommends contradicts RFC4361, that would be bad.   So it's probably
easier to simply refer the reader to RFC4361 than to repeat the text of
RFC4361 in the BCP.

> workaround, and specify that new development/implementations SHOULD use

To be clear, this workaround is incompatible with RFC4361; what RFC4361
does is to make it mandatory that you use a consistent client
identifier.   So future RFC4361-compliant clients won't have the problem
you've described, but RFC4361 doesn't specify the hack I described.

This is why I object to putting the hack into the BCP - if you put the
hack into the BCP, there's going to be a tendency for the reader to not
follow RFC4361, and we want the reader to follow RFC4361.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 13 Jul 2006 15:15:35 +0000

> you've described, but RFC4361 doesn't specify the hack I described.

Strictly speaking, the reality is actually the opposite of Ted's
statement here.

Quite: RFC4361 makes it mandatory that you use a consistent client
identifier.  No argument there.

So: Future RFC4361-compliant clients WILL have the problem Andre has
described, under contrived conditions.  Rather, this is now purposeful
rather than an accident of poor implementation.

RFC4361 even documents this intentional incompatibility, suggesting
that anyone who implements RFC4361 has both thought about this
problem and is operating in an environment that supports it.

> follow RFC4361, and we want the reader to follow RFC4361.

I am unwilling to discount useful work that describes changes that
advance the state of the art of DHCP simply because it does not
advance a preferrential state of the art.

So I agree with Andre on this point.  The workaround treating
client identifers that match chaddr as the same as clients that
supply no client identifier is worth documenting if anyone has
the time and energy to do so.

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

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 13 Jul 2006 15:25:51 +0000

> the time and energy to do so.

And if no one has the time or energy to do so, I will supply
one, eventually, as I am able to (and before ISC DHCP adopts a
similar mechanism).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jul 2006 09:51:24 -0400

---

From: "Barr Hibbs" <[email-masked]>
Date: Fri, 14 Jul 2006 10:28:48 -0700

> -----Original Message-----
> From: Andre Kostur [mailto:[email-masked]]
> Sent: Thursday, July 13, 2006 07:19
> Ted Lemon wrote:

> that document?

...[rbh] I was actually hoping NOT to revisit that somewhat
lengthy discussion, although recapping at least some of it
in the implementation issues draft probably would be a good
thing