Subject: [dhcwg] WGLC: draft-ietf-dhc-client-id-02

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Apr 2012 12:54:58 +0000

This document corrects a bug in RFC2131 that forbids the DHCP server from returning a DHCP client identifier.   The lack of a DHCP client identifier creates a problem in two cases: where the underlying transport has no link-layer address, and where two clients are running on the same host, supplying different client identifiers so as to present different network identities.   In both of these cases, insufficient information is returned from the DHCP server to clearly identify the client that is the intended recipient of the message.   The only way to fix this is to _require_ the DHCP server to return the client identifier if it receives it.   This is what the proposed document does.

We checked for consensus in the meeting, and four people were in favor of advancing the draft; nobody was against.

I think this is actually pretty important work—it's a lingering bug in the spec which I think will come back to bite us more and more as we start getting deeper into the dual-stack transition.   So if you haven't read the document, please do. 

If you support advancing it, please signify by replying to this message and saying that you support it. If you think it's a bad idea, please signify by replying to this message and explaining why.   If you have comments or changes to propose, please send them along, and also signify whether you are in favor of advancement with the change, without the change, or oppose advancement.

We will determine consensus on April 27, based solely on responses on the mailing list, so please do respond.

Thanks!

---

From: Bud Millwood <[email-masked]>
Date: Mon, 16 Apr 2012 10:53:18 +0200

Hi Ted:

We'll support this. My approach is going to be to make it optional,
but I'm leaning towards having it disabled by default in our software.

Is there any real-world analysis of how various devices will handle
this change? After all, it is explicitly breaking the existing DHCP
protocol.

- Bud

On Sat, Apr 14, 2012 at 2:54 PM, Ted Lemon <[email-masked]> wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Apr 2012 12:33:11 +0000

It is nearly inconceivable to me that some device out in the wild will check for the client identifier and drop the packet if it's there.   Anything's possible, I guess, but I really don't think this is likely.

Still, there is only one way to find out.   I think making it an administratively-configured option is a valid risk-management strategy.

---

From: Andre Kostur <[email-masked]>
Date: Mon, 16 Apr 2012 15:34:03 -0700

I support this draft.

On Mon, Apr 16, 2012 at 05:33, Ted Lemon <[email-masked]> wrote:

> It is nearly inconceivable to me that some device out in the wild will
> check for the client identifier and drop the packet if it's there.
> Anything's possible, I guess, but I really don't think this is likely.
>
> Still, there is only one way to find out.   I think making it an
> administratively-configured option is a valid risk-management strategy.
>

-- 
 *Andre Kostur*

---

From: Prashanth R <[email-masked]>
Date: Tue, 17 Apr 2012 09:40:33 +0530

Hi Ted,

I am in favour of supporting this draft.

I have a couple of suggestions:

1) Can we add a section which would say what SHOULD be the behaviour on the
client when it receives a packet with the client-id set.
2) Can a clarification be added on what the server SHOULD do when it
receives a DHCP packet with 0 mac-addr and no client-id.

Thanks,
Prashanth.

On Sat, Apr 14, 2012 at 6:24 PM, Ted Lemon <[email-masked]> wrote:

> This document corrects a bug in RFC2131 that forbids the DHCP server from
> returning a DHCP client identifier.   The lack of a DHCP client identifier
> creates a problem in two cases: where the underlying transport has no
> link-layer address, and where two clients are running on the same host,
> supplying different client identifiers so as to present different network
> identities.   In both of these cases, insufficient information is returned
> from the DHCP server to clearly identify the client that is the intended
> recipient of the message.   The only way to fix this is to _require_ the
> DHCP server to return the client identifier if it receives it.   This is
> what the proposed document does.
>
> I think this is actually pretty important work—it's a lingering bug in the
> spec which I think will come back to bite us more and more as we start
> getting deeper into the dual-stack transition.   So if you haven't read the
> document, please do.
>
> If you support advancing it, please signify by replying to this message
> and saying that you support it. If you think it's a bad idea, please
> signify by replying to this message and explaining why.   If you have
> comments or changes to propose, please send them along, and also signify
> whether you are in favor of advancement with the change, without the
> change, or oppose advancement.
>

---

From: "Prashant Jhingran (pjhingra)" <[email-masked]>
Date: Thu, 19 Apr 2012 10:39:48 +0530

Hi Prashanth,

Thanks for supporting this draft. 

As mentioned in the draft, "[RFC2131] specifies that a combination of
'client identifier' or 'chaddr' and assigned network address constitute
a unique identifier for the client's lease and are used by both the
client and server to identify a lease referred in any DHCP messages".
How would a server allocate and keep track of clients when both "DHCP
packet with 0 mac-addr and no client-id.". So its implicit that server
would drop such packets.

The client behavior is out of scope of this draft, this draft only
focuses on server behavior. 

-

Regards,

Prashant Jhingran

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Prashanth R
Sent: Tuesday, April 17, 2012 9:41 AM
To: Ted Lemon
Cc: DHC WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02

Hi Ted,

1) Can we add a section which would say what SHOULD be the behaviour on
the client when it receives a packet with the client-id set. 
2) Can a clarification be added on what the server SHOULD do when it
receives a DHCP packet with 0 mac-addr and no client-id. 

Thanks,
Prashanth. 

On Sat, Apr 14, 2012 at 6:24 PM, Ted Lemon <[email-masked]>
wrote:

This document corrects a bug in RFC2131 that forbids the DHCP server
from returning a DHCP client identifier.   The lack of a DHCP client
identifier creates a problem in two cases: where the underlying
transport has no link-layer address, and where two clients are running
on the same host, supplying different client identifiers so as to
present different network identities.   In both of these cases,
insufficient information is returned from the DHCP server to clearly
identify the client that is the intended recipient of the message.   The
only way to fix this is to _require_ the DHCP server to return the
client identifier if it receives it.   This is what the proposed
document does.

We checked for consensus in the meeting, and four people were in favor
of advancing the draft; nobody was against.

I think this is actually pretty important work-it's a lingering bug in
the spec which I think will come back to bite us more and more as we
start getting deeper into the dual-stack transition.   So if you haven't
read the document, please do.

We will determine consensus on April 27, based solely on responses on
the mailing list, so please do respond.

Thanks!

---

From: Peng Wu <[email-masked]>
Date: Thu, 19 Apr 2012 13:46:57 +0800

I also support this draft and would like to see it moving forward.

Cheers~

---

From: shwethab <[email-masked]>
Date: Thu, 19 Apr 2012 12:33:15 +0530

+1
>> recipient of the message.   The only way to fix this is to _require_ the DHCP
>> server to return the client identifier if it receives it.   This is what the
>> proposed document does.
>> 
>> I think this is actually pretty important work‹it's a lingering bug in the
>> If you support advancing it, please signify by replying to this message and
>> saying that you support it. If you think it's a bad idea, please signify by
>> replying to this message and explaining why.   If you have comments or
>> changes to propose, please send them along, and also signify whether you are
>> in favor of advancement with the change, without the change, or oppose
>> advancement.
>>

---

From: Richard Johnson <[email-masked]>
Date: Wed, 25 Apr 2012 12:59:39 -0700

I definitely support this draft, although I think the current description of the problem to be solved could use quite a lot of work to make it more clear.  Your own description is quite clear, but the document is not really.

/raj