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

["Bernie Volz" <[e-mail]>]

Barr:

I don't think a new option is such a good idea. If a new option is used,
how does a client know when to send it or the 'old' client identifier
option? This forces 'new' clients to send both - at least in the
DISCOVER (older servers would not echo back the new option in the OFFER
and new servers would could send back just the new option). This goes
against your proposed text for 4.1, "but MUST NOT send both."

Barr, Ted & Bill:

I'm also not completely happy with encoding the IAID and DUID in a
single option.

The main reason I don't like this is that it forces the server to do
something that we don't really want it to do - pull apart the data in
the client identifier option - the option data is no longer 'opaque'.
Note that it will be important for the DHCP server to do this for:
1. Dynamic DNS updates since the client identifier is only the DUID
portion (see section 3.3 of draft-ietf-dnsext-dhcid-rr-07.txt).
2. Client based policies (ie, reservations) or limits, since these will
want to look just at the DUID portion.

But, there is an advantage to encoding the IAID and DUID in the option
as it supports current DHCP server implementations. Without this, a
client that has multiple interfaces (either connected to the same link
or not) that are serviced by a single DHCP server might not get multiple
addresses.

I guess given the lessor of the two evils, I'm inclined to go along with
the option as you've proposed it in the draft.

So, I support this document moving forward.

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Richard Barr Hibbs
Sent: Monday, March 15, 2004 6:10 PM
To: Dhcwg
Subject: 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg