Subject: RE: "Michael W. Patrick": dhcp agent options draft 12

From: Bernie Volz <[email-masked]>
Date: Thu, 19 Oct 2000 18:16:32 -0400

In RFC 2131, in section 4.1 it states:

   DHCP clients and servers both construct DHCP messages by filling in
   fields in the fixed format section of the message and appending
   tagged data items in the variable length option area.  The options
   area includes first a four-octet 'magic cookie' (which was described
   in section 3), followed by the options.  The last option must always
   be the 'end' option.

And, in RFC 2132, section 3.2 defines the 'end' option:

3.2. End Option

   The end option marks the end of valid information in the vendor
   field.  Subsequent octets should be filled with pad options.

   The code for the end option is 255, and its length is 1 octet.

    Code
   +-----+
   | 255 |
   +-----+

So, I agree with Michael on the change. I haven't gone back to look at the
revised draft (12), but I guess it is best to say:

"MUST insert the option immediately before the end option or after the last
option
 if there is no end option (and in the later case, no end option should be
added)"

Note that RFC 2131 does not use "MUST", just "must": The last option must
always be the 'end' option.

Perhaps this is one to add to the list of corrections? Not also how does
this impact the authentication drafts - since authentication is not to cover
the relay agent option but it might need to cover the end option. The
authentication drafts hopefully just say to remove the relay agent option?

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Wednesday, October 18, 2000 4:44 PM
To: DHCPv4 discussion list
Cc: DHCPv4 discussion list
Subject: Re: "Michael W. Patrick": dhcp agent options draft 12

Mike,

> 1  I added one new paragraph in section 5 Security detailing the
environment
>    restrictions under which DHCP relay agent option enhances
>    security.  This was added at the insistence of the IESG.

Yep, thanks.

> 2  I added text in section 2.1 clarifying how to handle the "End Option"
>    (255).  The previous drafts were not clear when they called
>    for making the relay agent option the "last option". 
>    You could either 
>        1 insert before the End Option 
>        2 replace the End option with the relay agent option
>          (i.e.  overwrite End option and not have one at all)
>        3 put the relay agent option *after* the End option
>    and still make a case for complying with the draft.
>    This draft says do the *insert*, case 1.
>    If there's controversy over this, I'm hesitant to revert back
>    to the WG-approved draft 11 wording, because it really is
>    ambiguous to require the relay agent option to be the "last
>    option".

I'm going to demonstrate my lack of understanding about DHCP by asking
what the "end" option is actually used for. I couldn't quite figure it
out from a quick scan of the rfcs. Who inserts it and when?

I would have thought you want the agent options to be the very last
one. Easy to append, easy to strip off. No need to move options
around. But I've seen no followup, so I guess this isn't really an
issue in practice.

Thomas

---

From: Steve Gonczi <[email-masked]>
Date: Thu, 19 Oct 2000 19:38:54 -0400

>out from a quick scan of the rfcs. Who inserts it and when?

The DHCP server adds it, as the last option.
It merely indicates "there are no more options after this" 
(sort of like a period, closing a sentence). This is a MUST
in RFC 2131.

/sG