Subject: I-D ACTION:draft-henry-DHCP-opt61-UUID-type-00.txt

From: [email-masked] (by way of Ralph Droms)
Date: Tue, 24 Nov 1998 16:56:54 -0500 (EST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: DHCP Option 61 UUID Type Definition
	Author(s)	: M. Henry
	Filename	: draft-henry-DHCP-opt61-UUID-type-00.txt
	Pages		: 3
	Date		: 20-Nov-98

   The DHCP [1] mechanism for identifying the client as a unique
   entity is the DHCP client-identifier option (code 61) [2]. This
   draft defines for Option 61 a specific type and type number of a
   client-identifier based on generated UUIDs [3]. These identifiers
   are guaranteed to be, or are very, very likely to be unique across
   time and all clients.

Internet-Drafts are 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-henry-DHCP-opt61-UUID-type-00.txt".
A URL for the Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-henry-DHCP-opt61-UUID-type-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za

	Europe: ftp.nordu.net
		ftp.nic.it

	Pacific Rim: munnari.oz.au

	US East Coast: ftp.ietf.org

	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-henry-DHCP-opt61-UUID-type-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.

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

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]

Content-Type: Message/External-body;
	name="draft-henry-DHCP-opt61-UUID-type-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

[This attachment must be fetched by ftp.
 Open the document below to ask your ftp client to fetch it.]

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

---

From: [email-masked] (by way of Ralph Droms)
Date: Tue, 24 Nov 1998 17:06:03 -0500 (EST)

> this draft changes the meaning of the client-id which could be problematic
> since the client-id is already in use.  i don't perceive a problem with the
> way the client-id is defined today. however, a section that presents the
> motivation for creating a UUID-based client-id would be useful to understand
> the reasons for changing the meaning of the client-id.

The understanding when we discussed this in August was that the
meaning of the client id would only change with the revised protocol
that is being worked on in committee.  I haven't yet read this draft,
so I don't know whether this was left out or not.

> this says the client-id must be unique on the subnet.  in chicago we
> discussed making the client-id unique in the administrative domain.  this
> issue needs to be resolved.

IIRC, we discussed making client identifiers universally unique.

> in glancing the the open group definition of UUID it says the the UUID is 16
> octets.  why must the length be 18?  one type byte plus 16 octets equals 17
> octets, yes?

All options have lengths, which are currently one octet.   (Type + Len
+ Content) == 18.

			       _MelloN_

---

From: "Henry, Mike" <[email-masked]>
Date: Wed, 25 Nov 1998 17:28:58 -0500 (EST)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Tuesday, November 24, 1998 7:25 AM
> To: Multiple recipients of list
> Subject: RE: I-D ACTION:draft-henry-DHCP-opt61-UUID-type-00.txt
> 
> 

The draft does not change the meaning of client-id, it simply defines one
more type of client-id using the type field in the option to indicate this
new type.

> more comments inline below.
> 
> > 2.0 Proposed change to DHCP Vendor Option 61
> >
> >    For correct identification of clients, each client's 
> client-identifier
> >    MUST be unique among the client-identifiers used on the subnet to
> >    which the client is attached, and SHOULD be unique 
> across all domains.
> >    Vendors and system administrators are responsible for choosing
> >    client-identifiers that meet this requirement for uniqueness.
> 

Yes, it does say the client-id must be unique on the subnet. This text
("must be unique on the subnet") is from RFC 2132.  It was not my intention
to change the scope of the existing option client-id types in any way, but
simply to add an option type. That being said, I agree it would be better to
say "MUST be unique among the client-identifiers in the administrative
domain to which the client is attached,...". I have no problem with making
that change if there is consensus for it.
> 
> 
> >    The client identifier MAY be one of several types defined here:
> >
> >    The client identifier MAY be a UUID (Universal Unique 
> ID). In this
> >    case, the Type field MUST be 254 and the length field MUST be 18.
> >    The format and content of the UUID MUST be as specified 
> in the RPC
> >    Specification from the Open Group [3]
> 
Yes, you are correct. From RFC 2132 "The value of the length octet does not
include the two octets specifying the tag and length." I knew this; slip of
the cortex...  Thanks for catching it.
> >
> >    The code for this option is 61, and its minimum length is 2.
> >
> >     Code   Len   Type  Client-Identifier
> >    +-----+-----+-----+-----+-----+-----
> >    |  61 |  n  | t1  | i1  | i2  | ...
> >    +-----+-----+-----+-----+-----+-----
> 
> /gww
> 
/mdh

---

From: Diana Lane <[email-masked]>
Date: Fri, 27 Nov 1998 12:46:02 -0500 (EST)

-----Original Message-----
	From:	Henry, Mike [SMTP:[email-masked]]
	Sent:	Wednesday, November 25, 1998 4:30 PM
	To:	Multiple recipients of list
	Subject:	RE: I-D
ACTION:draft-henry-DHCP-opt61-UUID-type-00.txt

	> issue needs to be resolved.

	Yes, it does say the client-id must be unique on the subnet. This
text
	("must be unique on the subnet") is from RFC 2132.  It was not my
intention
	to change the scope of the existing option client-id types in any
way, but
	simply to add an option type. That being said, I agree it would be
better to
	say "MUST be unique among the client-identifiers in the
administrative
	domain to which the client is attached,...". I have no problem with
making
	that change if there is consensus for it.

I would like to see, "MUST be unique among the client-identifiers in the
administrative domain to which the client is attached."  Clients here
frequently change subnets, often to a subnet whose DHCP IP address range
"lives" on a different DHCP server.  We need to keep the client Ids unique
across all of our network to avoid rampant confusion in our servers.  Our
administrative domain is enterprise-wide... which may be a little bit large.
:-)

Diana Lane ([email-masked])
Sr. Network Engineer
Wal-Mart Stores, Inc.