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

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

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