Subject: I-D ACTION:draft-ietf-dhc-options-cont-01.txt

From: Ralph Droms <[email-masked]>
Date: Wed, 12 Jan 2000 00:22:30 -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		: DHCP Continuation Option Code
	Author(s)	: W. Arbaugh, A. Keromytis
	Filename	: draft-ietf-dhc-options-cont-01.txt
	Pages		: 3
	Date		: 03-Jan-00
	
The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCP/IP network.
Currently options are limited to an information size of 256 bytes
because of the one-octet size of the length field. This document
defines a new option that permits the continuation of the previous
option information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-options-cont-01.txt

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-options-cont-01.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-options-cont-01.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-options-cont-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dhc-options-cont-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jan 2000 08:57:10 -0500

I would suggest that after the second diagram in the continuation
option draft, the following wording be added:

  The continuation option for an option must appear immediately
  following that option.   If the sname and filename buffers in the DHCP
  packet are being used in combination with the Overload option, the
  sname buffer should be considered to immediately follow the main
  option buffer, and the filename buffer should be considered to
  immediately follow the sname buffer.   It is permissible to use
  multiple continuation options with lengths shorter than 255 in order
  to fit a continued option into these buffers.

In addition, I'm worried about what happens if a DHCP client uses a
continuation option when sending a packet to a DHCP server that
doesn't support it, or vice versa.   It seems like this could cause
trouble.   I'm not sure whether the right thing is to specify a
negotiation here, or to simply anticipate that options with payloads
large enough to require the continuation option should not be
implemented at all unless the continuation option is also
implemented.

I also think this option introduces some serious complexity, and I'm
not sure what the benefit is.   If we accept that this should only be
used for options that require its implementation, then why not just
have those options specify that multiple occurrances of the same
option should be concatenated?

			       _MelloN_

---

From: "William A. Arbaugh" <[email-masked]>
Date: Wed, 12 Jan 2000 10:44:33 -0500 (EST)

On Wed, 12 Jan 2000, Ted Lemon wrote:
> ...
>  ... then why not just

This is the behavior that Ted's code uses, and the right approach in my
opinion (rather than the continutation option).  I'm more than willing to
withdraw the option draft in favor of what Ted has proposed.  But, we need
to do something to support large options if we want to support public key
based authentication.

Bill