Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt

From: [email-masked]
Date: Mon, 02 Feb 2004 15:55:47 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: Client Identifier option in server replies
	Author(s)	: N. Swamy
	Filename	: draft-ietf-dhc-client-id-00.txt
	Pages		: 4
	Date		: 2004-2-2
	
This document clarifies the use of 'client identifier' option by the
   clients and servers as mentioned in [RFC2131]. The clarification 
   addresses the issue arising out of the point specified by [RFC2131]
   that the server 'MUST NOT' return client identifier' option to the
   client.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-client-id-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-client-id-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-client-id-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Feb 2004 15:08:24 -0600

> 3.  Proposed modification to [RFC2131]
>
>    If the 'client identifier' option is set in the message received 
> from
>    client, the server MUST return 'client identifier' value in its
>    response message.
>
>    Following table is extracted from section 4.3.1 of [RFC2131] and
>    relevant fields are modified accordingly.
>
> Option                    DHCPOFFER    DHCPACK            DHCPNAK
> ------                    ---------    -------            -------
> Client identifier         MAY          MAY                MAY

This is contradictory.  I think if you're going to say MUST in the 
first paragraph, you need to say MUST in the table.   You can put in a 
footnote that explains that if there is no client identifier, the 
server mustn't send one.   :')   I agree that MUST is the right answer 
here, by the way.

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

---

From: "Barr Hibbs" <[email-masked]>
Date: Mon, 2 Feb 2004 17:12:33 -0800

I agree:  if the "client identifier" MUST be returned (as the proposed
modification suggests), then the supporting table also should contain the
word "MUST" or, perhaps better, "MUST if in DHCPDISCOVER"

--Barr

> -----Original Message-----
> >    from client, the server MUST return 'client identifier' value in
> >    its response message.
> >

[Ted Lemon]

> server mustn't send one.

---

From: "Kevin A. Noll" <[email-masked]>
Date: Mon, 02 Feb 2004 20:30:24 -0500

I'm trying to figure out how a client is expected to react if the
server returns an IP address in the DHCPACK than what was offered
in the DHCPOFFER (and requested by the client in the DHCPREQUEST).

Following the general idea of DISCOVER-OFFER, REQUEST-ACK and the
behavior implied for INIT-REBOOT, it seems that the most obvious 
way to handle this would be for the client to use the IP address 
returned in the DHCPACK, even if it is different than what was 
requested. However, there does not seem to be any specific resolution 
to this in RFC2131 or in draft-ietf-dhc-implementation-01.

Can someone tell me if there is a specific answer to this? Is there
a requirement that the server grant the IP address being requested
if it was previously offered?

--kan--
--
Kevin A. Noll, KD4WOZ
CCIE 10948, CCDP
Perfect Order, Inc.		
[email-masked]
717-796-1936

---

From: "Bernie Volz" <[email-masked]>
Date: Mon, 2 Feb 2004 21:48:54 -0500

I agree but it would be nice if the table reflected both cases, such as:

Option                    DHCPOFFER    DHCPACK            DHCPNAK
------                    ---------    -------            -------
Client identifier (if     MUST         MUST               MUST
  sent by client)
Client identifier (if     MUST NOT     MUST NOT           MUST NOT
  not sent by client)

Client identifier
 - if sent by client      MUST         MUST               MUST
 - if not sent by client  MUST NOT     MUST NOT           MUST NOT

A footnote would be OK as well.

Also, in section 3, it might be best to revise the text slightly, as
follows?

   If the 'client identifier' option is set in a message received from
   a client, the server MUST return the 'client identifier' option,
   unaltered, in its response message.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barr
Hibbs
Sent: Monday, February 02, 2004 8:13 PM
To: [email-masked]
Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt

--Barr

[Ted Lemon]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Feb 2004 21:03:54 -0600

> if it was previously offered?

This is a protocol violation on the part of the server.   The client 
should drop the packet like a hot potato - it's probably a denial of 
service attack.

I don't think 2131 is specific about cases like this.   I tend to be in 
favor of interoperability over pickiness, but the server is totally 
forbidden from doing this in RFC2131, and I don't see any reason why 
the client should be forgiving about it.

---

From: "Kevin A. Noll" <[email-masked]>
Date: Mon, 02 Feb 2004 22:26:35 -0500

I agree that it is not the correct behavior. 

What I'm looking for is a reference in 2131 that would say (or at
least imply) that this is a violation of the protocol. 

--kan--

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Ted
> Lemon
> Sent: Monday, 02 February, 2004 10:04 PM
> To: Kevin A. Noll
> Cc: [email-masked]
> Subject: Re: [dhcwg] Options differing in OFFER and ACK
> 
>

---

From: Robert Elz <[email-masked]>
Date: Tue, 03 Feb 2004 18:22:17 +0700

Date:        Mon, 2 Feb 2004 21:48:54 -0500
    From:        "Bernie Volz" <[email-masked]>
    Message-ID:  <000001c3ea00$463b0b00$6401a8c0@BVolz>

  | I agree but it would be nice if the table reflected both cases, such as:
  | 
  | Option                    DHCPOFFER    DHCPACK            DHCPNAK
  | ------                    ---------    -------            -------
  | Client identifier (if     MUST         MUST               MUST
  |   sent by client)
  | Client identifier (if     MUST NOT     MUST NOT           MUST NOT
  |   not sent by client)

How about extending the words that can be used in the columns beyond
the standard MAY/SHOULD/MUST (and inverses) set, and include things
like DISCOVER & REQUEST which would be defined like

DISCOVER: the option MUST be included if it was present in the DHCPDISCOVER
packet, and MUST NOT be included if it was not.   The value of the option
MUST be set appropriately, which is not always to simply copy from the
DHCPDISCOVER packet, though may be for particular options.

(and similarly for REQUEST).

Then the table could be

Option                    DHCPOFFER    DHCPACK            DHCPNAK
------                    ---------    -------            -------
Client identifier         DISCOVER     REQUEST            REQUEST

(or whatever is appropriate).   Perhaps some other options have the same
kind of rules?

kre

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Feb 2004 09:51:35 -0600

> I agree but it would be nice if the table reflected both cases, such 

I'm okay with this way of representing it also.   It's probably better 
in the sense that it's gives a first-class representation in the table 
to both scenarios.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Feb 2004 10:03:02 -0600

> like DISCOVER & REQUEST which would be defined like

What we want is that whenever the client sends a client-identifier 
option in a packet, the response from the server contains that client 
identifier.   This is a very simple concept - there's no need for 
anything fancy.   I like Bernie's table entries because they are a 
little clearer for the reader, but from the perspective of verbiage, as 
opposed to tables, this really only needs to be a single sentence, and 
I don't think additional complexity in the table is going to help 
clarify things for the reader - it will either not make a difference, 
or it will confuse the reader.

---

From: "Kevin A. Noll" <[email-masked]>
Date: Tue, 03 Feb 2004 11:32:05 -0500

I suppose this paragraph in item 4 of section 3.1 would imply the protocol
violation...

     If the selected server is unable to satisfy the DHCPREQUEST message
     (e.g., the requested network address has been allocated), the
     server SHOULD respond with a DHCPNAK message.

I suppose my confusion is that 2131 doesn't give any guidance about what
the client is to do in this case.

--kan--

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Kevin A. Noll
> Sent: Monday, 02 February, 2004 10:27 PM
> To: Ted Lemon
> Cc: [email-masked]
> Subject: RE: [dhcwg] Options differing in OFFER and ACK
>
>
>

---

From: Robert Elz <[email-masked]>
Date: Wed, 04 Feb 2004 15:42:18 +0700

Date:        Tue, 3 Feb 2004 10:03:02 -0600
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | What we want is that whenever the client sends a client-identifier 
  | option in a packet, the response from the server contains that client 
  | identifier.   This is a very simple concept - there's no need for 
  | anything fancy.

If this is just for client identifier, and no other option either is,
or ever will be, treated the same, then I agree.   On the other hand, if
there get to be 2, 3, 4 ... options that the server is expected to copy
back into the reply, or to include in the reply (perhaps in modified form)
whenever they appear in a discover/request, then I suspect that creating
a common way to make that clear would be a better idea.

But, whatever works...

kre