RE: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt

Oh, I forgot to add that perhaps draft-ietf-dnsext-dhcid-rr-07.txt needs to
be updated. The following table will need to be revised:

     0x0000 = htype, chaddr from a DHCPv4 client's
              DHCPREQUEST (RFC 2131)
     0x0001 = The data portion from a DHCPv4 client's Client
              Identifier option (RFC 2132)
     0x0002 = The data portion (i.e., the DUID) from a DHCPv6
              client's Client Identifier option
      	  (draft-ietf-dhc-dhcpv6-*.txt)

To, perhaps:

     0x0000 = htype, chaddr from a DHCPv4 client's
              DHCPREQUEST (RFC 2131)
     0x0001 = The data portion from a DHCPv4 client's Client
              Identifier option (RFC 2132) if not the DUID
              format (see draft-ietf-dhc-3315id-for-v4-*.txt)
     0x0002 = The DUID from a DHCPv6 client's Client
              Identifier option (RFC 3315 or
              draft-ietf-dhc-3315id-for-v4-02.txt)

This still creates an issue for servers that don't fully understand
draft-ietf-dhc-3315id-for-v4-02.txt as they'll use 0x0001 instead of 0x0002.

I wonder whether a way out of this might be to use the DHCPv4 encoding for
both DHCPv4 and DHCPv6 DUIDs:
	0x0001 <255> <DUID>

- Bernie

-----Original Message-----
From: Bernie Volz [mailto:volz@metrocast.net] 
Sent: Tuesday, March 09, 2004 12:11 PM
To: 'dhcwg@ietf.org'; 'Ted.Lemon@nominum.com'
Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt

Ted:

While I was pushing for the addition of the IA in DHCPv4, I'm not yet
certain the technique for doing so is the best way to go. I think it has the
possibility of introducing confusion and perhaps even interoperatability
issues.

The confusion is as to what exactly is the client identifier. Is it the
"full" IA+DUID or just DUID? I assume that the DUID is the part that is
supposed to represent the client - not the IA+DUID. If that is the case,
what happens when there are multiple servers in a network, some that
understand the separation between IA+DUID and those that don't (they just
understand the "client identifier option" and use all the bytes to identify
the client). I'm especially concerned about DDNS updates (using the DHCID RR
draft).

There are two ways to resolve this:

1. Place the IA into a separate option instead of as part of the Client
Identifier.

2. Place appropriate warnings/cautions/directions as to what a server is
supposed to use as the "client identifier". Though, while this resolves the
situation for those servers that are modified to support this work, it
doesn't resolve the issue for those servers that don't.

Using a separate option has the following advantages:
- If a server does not support the IA option, the client can know that since
the server will NOT echo it back in any replies. (Of course, servers MUST be
told to do this.) I'm not sure what the client should do if the server
doesn't support the IA option, but it might, for example, switch back to an
interface specific identifier if it needs multiple addresses?

- The client identifier is the same regardless of whether a server supports
the new DUID based client identifier. Presently, if there are two servers in
a network, one that has full understanding of this draft
(draft-ietf-dhc-3315id-for-v4-02) and one that doesn't, they'll use
different client identifiers (at least as I understand it) when doing DDNS
updates (assuming they implement the DHCID RR).

- Bernie

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of
Internet-Drafts@ietf.org
Sent: Tuesday, February 17, 2004 10:32 AM
To: IETF-Announce:
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt

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		: Node-Specific Client Identifiers for DHCPv4
	Author(s)	: T. Lemon
	Filename	: draft-ietf-dhc-3315id-for-v4-02.txt
	Pages		: 8
	Date		: 2004-2-17

This document specifies the format that is to be used for encoding
DHCPv4 (RFC2131/RFC2132) client identifiers, so that those identifiers
will be interchangeable with identifiers used in the DHCPv6 protocol
(RFC3315).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-3315id-for-v4-02.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-3315id-for-v4-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-3315id-for-v4-02.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.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg