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

From: "Bernie Volz" <[email-masked]>
Date: Tue, 9 Mar 2004 12:10:57 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, February 17, 2004 10:32 AM
To: IETF-Announce:
Cc: [email-masked]
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:
	[email-masked].
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Mar 2004 12:29:20 -0600

> doesn't resolve the issue for those servers that don't.

Just as a reminder, there is no standard saying what servers currently 
are supposed to do with client identifier- there are just a bunch of 
soon-to-expire drafts.   However, your point isn't about standards, but 
about what's deployed.   My point in bringing this up is not to say 
"it's not a problem", but rather to try to suggest that the right 
solution _is_ in fact to say "you have to run servers that conform to 
the standard if you want it to work," not to make the protocol more 
complex to account for non-conforming implementations.  The intention 
when I was asked to write this draft was that it would be a normative 
reference for the DNS update drafts, so no DHCP server that conforms to 
the DNS update drafts will fail to implement this standard.

I'm not sure where the warning you're proposing should go - in this 
draft or in one of the DNS update drafts.

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 9 Mar 2004 15:18:55 -0500

Perhaps something needs to be said in both drafts?

I have no major issue with saying that you need to run servers that conform
to the standard for this work, but I do believe the draft should say
something about the implications of implementing the draft so that vendors
producing clients and servers remember to warn their customers when
deploying updated software. And, there's always the issue of coordinating
client and server updates - if a new client runs on an old server, the
client identifier that needs to be configured for a reservation will differ
significantly from that used by an updated server.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
Lemon
Sent: Tuesday, March 09, 2004 1:29 PM
To: Bernie Volz
Cc: [email-masked]
Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt

---

From: "Richard Barr Hibbs" <[email-masked]>
Date: Mon, 15 Mar 2004 15:09:53 -0800

Ted and Bill--

the proposal to modify the definition of DHCP(v4) 'client
identifiers' to be compatible with RFC3315 'DHCP Unique
Identifiers' (DUIDs) represents a good approach to solving
some of our long-standing issues about the identification
and recognition of DHCP(v4) clients, especially in an
environment where transition between DHCPv4 and DHCPv6 is
planned.

I disagree on a number of points, which I'd like to present
here.

First, a DHCPv6 DUID is intended to be globally unique,
while a DHCPv4 'client identifier' is not [from section 9
of RFC3315:  "The motivation for having more than one type
of DUID is that the DUID must be globally unique, and must
also be easy to generate."]

A second problem that you point out in section 4.2 of the
draft is, "... some DHCPv4 servers can be configured not to
conform to RFC2131 and RFC2131 [sic], in the sense that they
ignore the 'client identifier' option and use the client's
hardware address instead.  A clarification of the RFCs seems
in order.

I posit another problem that arises from the current
definition of 'client identifier.'  RFC2132 _suggests_ a
method for generating an appropriately [subnet-] unique
identifier, but several known implementations treat
RFC2132's "MAY" as "MUST" and "SHOULD" as "MAY."
[from section 9.14 of RFC2132, "Identifiers SHOULD be
treated as opaque objects by DHCP servers. The client
identifier MAY consist of type-value pairs similar to the
'htype'/'chaddr' fields...."]

Finally, during our conference calls discussing the RFC2131
implementation issues we reached a rough consensus about the
DHCPv4 client identifier, including the following points:

 1. the 'client identifier' is an opaque octet string [not
    null terminated] from which a DHCPv4 server SHOULD NOT
    infer or expect any structure.
 2. all description of how a 'client identifier' MAY be
    generated by a DHCPv4 client will be removed from
    RFC2131 and contained ONLY in RFC2132.
 3. description of alternative methods for generating a
    subnet-unique 'client identifier' will be included in
    RFC2132.
 4. the wording of both RFCs would be carefully checked to
    ensure that both are completely consistent describing
    the generation and use of 'client identifiers' and that
    any wording changes will not alter our consensus on the
    use of 'client identifier' to recognize and identify a
    DHCPv4 client.

So, my proposal for this draft is that it should define a
NEW DHCPv4 option, to be used IN PLACE OF 'client
identifier' option 61 where interoperability with DHCPv6 is
required or anticipated.

Separately, we would update RFC2131 and RFC2132 according to
the consensus we reached earlier.

With this in mind, I offer the following edits to your
draft (proposed changes marked by quotation marks):

Abstract

This document "specifies a new option" for encoding DHCPv4
[RFC2131 and RFC2132] client identifiers, so that those
identifiers will be interchangeable with identifiers used in
the DHCPv6 protocol [RFC3315].

Introduction

This document specifies the way in which DHCPv4 clients
should identify themselves "when operated in an environment
that includes or is anticipated to include DHCPv6 clients,
such as during a transition from DHCPv4 to DHCPv6."  DHCPv4
client implementations that conform to this specification
use a DHCPv6-style DHCP Unique Identifier (DUID) "in a new
DHCPv4 option."  This "updates" the behaviour specified in
RFC2131 and RFC2132.

2.4. RFC2131 does not require the use of a client identifier

RFC2131 allows the DHCP server to identify clients either
by using the client identifier option sent by the client,
or, if the client did not send one, the client's link-layer
address.   Like the client identifier format "suggested" by
RFC2131, this suffers from the problems previously described
in "sections 2.2 and 2.3."

3. Solutions

The solution to problem (2.4) is to deprecate the use of the
contents of the 'chaddr' field in the DHCP packet as a means
of identifying the client.  "For backwards compatibility in
a DHCPv4-only environment, this behavior must remain as a
default, whose use is strongly discouraged."

4.1. DHCP Client behavior

DHCP clients conforming to this specification MUST use
stable DHCP node identifiers in the "new DHCP unique
identifier" option.  DHCP clients MUST NOT use "DHCP unique"
identifiers based solely on layer two addresses that are
hard-wired to the layer two device (e.g., the ethernet MAC
address) as suggested in RFC2131 "and RFC2132 for 'client
identifiers'", except as allowed in section 9.2 of RFC3315.
DHCP clients MUST send a '"DHCP unique" identifier' "option
if interoperation with DHCPv6 clients and servers is
anticipated, or MAY send a 'client identifier' option if
interoperation is not anticipated, but MUST NOT send both."

"If the DHCPv4 client sends a 'DHCP unique identifier'
option it MUST be composed of" an Identity Association
Unique Identifier, as defined in section 10 of RFC3315, and
a DHCP Unique Identifier, as defined in section 9 of
RFC3315.  These together constitute an RFC3315-style binding
identifier.

The general format of the DHCPv4 'client identifier' option
is defined in section 9.14 of RFC2132, "and remains
unchanged by this proposal."

The format of the proposed '"DHCP unique" identifier'
option is as follows:

   Code   Len  /----- IAID ------\ /------ DUID ------- ...
   +-----+----+----+----+----+----+----+----+----+----+----
   | TBD |  n | i1 | i2 | i3 | i4 | d1 | d2 | d3 | d4 | ...
   +-----+----+----+----+----+----+----+----+----+----+----
  octets 1    2    3    4    5    6    7    8    9   10 ...

Any DHCPv4 or DHCPv6 client that conforms to this
specification SHOULD provide a means by which an operator
can learn what DUID the client has chosen.  Such clients
SHOULD also provide a means by which the operator can
configure the DUID.  A device that is normally configured
with both a DHCPv4 and DHCPv6 client SHOULD automatically
use the same DUID for DHCPv4 and DHCPv6 without any operator
intervention.  DHCP clients that support more than one
network interface SHOULD use the same DUID on every
interface.  DHCP clients that support more than one network
interface SHOULD use a different IAID on each interface.

4.3. Changes from RFC2131

In section 2 of RFC2131, on page 9, the text that reads,
"for example, the 'client identifier' may contain a
hardware address, identical to the contents of the
'chaddr' field, or it may contain another type of
identifier, such as a DNS name" is deleted.  [rbh--this is
probably what the RFC2131 implementation issues draft will
eventually propose]

In section 4.2 of RFC2131, the text "The client MAY choose
to explicitly provide the identifier through the 'client
identifier' option.  If the client supplies a 'client
identifier', the client MUST use the same 'client
identifier' in all subsequent messages, and the server MUST
use that identifier to identify the client.  If the client
does not provide a 'client identifier' option, the server
MUST use the contents of the 'chaddr' field to identify the
client" is replaced by the text, "The client MUST
explicitly provide a client identifier through the 'client
identifier' option."  [rbh--while I agree this is desirable,
I think that MUST ought to be SHOULD to allow existing
implementations to remain conformant to RFC2131, and
because I'm proposing that we create a new option, the
wording should reflect this]

In the same section, the text "Use of 'chaddr' as the
client's unique identifier may cause unexpected results, as
that identifier may be associated with a hardware interface
that could be moved to a new client.  Some sites may choose
to use a manufacturer's serial number as the 'client
identifier', to avoid unexpected changes in a clients
network address due to transfer of hardware interfaces among
computers.  Sites may also choose to use a DNS name as the
'client identifier', causing address leases to be associated
with the DNS name rather than a specific hardware box." is
replaced by the text "The DHCP client MUST NOT rely on the
'chaddr' field to identify it."  [rbh--I'd like to see the
word "uniquely" inserted here: "... field to uniquely
identify it."]

In section 4.4.1 of RFC2131, the text "The client MAY
include a different unique identifier" is replaced with "The
client MUST include a unique identifier".  [rbh--again,
although I agree this is most desirable, I think SHOULD is
appropriate for backwards compatibility]

In sections 3.1, item 4 and 6, 3.2 item 3 and 4, and 4.3.1,
where RFC2131 says that 'chaddr' may be used instead of the
'client identifier' option, the text that says "or 'chaddr'"
and "'chaddr' or" is deleted.  [rbh--wording should favor
use of 'DUID' option (proposed by this memo, but permits
'client identifier' option]

Note that these changes do not relieve the DHCP server of
the obligation to use 'chaddr' as an identifier if the
client does not send a 'client identifier' option.  Rather,
they oblige clients that conform with this document to send
a "'DHCP unique identifier' option (preferred) or a 'client
identifier' option, and not rely on 'chaddr' for
identification.  DHCP servers MUST use 'chaddr' as an
identifier in cases where "'DHCP unique identifier' or"
'client identifier' is not sent, in order to support old
clients that do not conform with this
document.

4.4. Changes from RFC2132

The text in section 9.14, beginning with "The client
identifier MAY consist of" through "that meet this
requirement for uniqueness." is replaced with "the client
identifier consists of a type field whose value is normally
255, followed by a two-byte type field, followed by the
contents of the identifier.  The two-byte type field and
the format of the contents of the identifier are defined in
RF3315,section 9."  The text "its minimum length is 2" in
the following paragraph is deleted.	 [rbh--the
implementation issues group will hopefully soon decide on a
new definition for option 61, so I'd suggest leaving this
text alone for the moment]

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Mar 2004 20:16:11 -0600

> identifier' option 61 where interoperability with DHCPv6 is

I must respectfully disagree.   This will create huge interoperability 
problems.   Really, what will happen is that nobody will ever implement 
it.

I am sorry to hear that the conference call came to a decision that was 
in conflict with this draft, but it has been the intention in writing 
the draft to fix the DHCP client identifier, not break it.   Adding a 
new DHCP option that serves the same purpose would break it.

> while a DHCPv4 'client identifier' is not [from section 9

The 3315id draft fixes this bug in RFC2131/RFC2132.   This is very much 
one of the intended outcomes of the adoption of this draft.   I don't 
see any benefit to perpetuating this bug.

> hardware address instead.  A clarification of the RFCs seems

The 3315id draft makes such a clarification.

> 'htype'/'chaddr' fields...."]

If you conform to the 3315id specification, the client identifier MUST 
NOT be of this form.

>     infer or expect any structure.

In the abstract, I think this is a fine thing to say.   However, if 
clients conform to the 3315id draft, this definitely isn't correct.   
If the changes specified in the 3315id draft are folded into the 
replacement for RFC2131/2132, I don't see any benefit to retaining this 
old language with respect to conforming client identifier options.   
Backward compatibility is of course still needed, and I don't mind 
saying that for cases where the 3315id-style identifier is not sent by 
the client, the server should treat the identifier as opaque.

I think the other three points are fine - of course the format of the 
option should be specified in only one place, and of course the two 
RFCs should be consistent in their use of the option.