Usage of the Client ID in RFC 2131

Ted Lemon wrote:
> Andre Kostur wrote:
>   
>> 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).
>>     
>
> 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
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

Andre Kostur wrote:
> 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.

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.

> Perhaps then the implementation issues document should
mention this
> workaround, and specify that new
development/implementations SHOULD use
> 4361?

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.


_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

On Thu, Jul 13, 2006 at 10:53:52AM -0400, Ted Lemon wrote:
> 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.

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.

> 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.

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

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

On Thu, Jul 13, 2006 at 03:15:35PM +0000, David W. Hankins
wrote:
> 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.

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).

-- 
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

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

> -----Original Message-----
> From: Andre Kostur [mailto:akosturincognito.com]
> Sent: Thursday, July 13, 2006 07:19
> Ted Lemon 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?

...[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


_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg