Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
RFC 4361

[Note]: 'On agenda to clear David''s discuss and check that IANA issues are resolved.  David, section 7 was added to address your concerns.  If they have not been fully addressed, can you let us know what issues remain?' added by Margaret Wasserman

[Ballot comment]
I expected to find some words in the Applicability section stating what happens when a client following this spec meets a server that doesn't, or vice versa. Actually, in the Requirements section the new server/old client case is very explicit on page 4. The new client/old server case is hard to disentangle from the page 4/5 text. A very simple sentence can resolve that for the rapid reader. (I'm not concerned about implementers, but rather about operations people planning client or server upgrades; they need to know it's OK to mix and match.)

[Ballot comment]
the new server/old client case is very explicit on
page 4 and I apologise for missing it. The new client/old server
case is hard to disentangle from the page 4/5 text and that is
where I got confused. A very simple sentence can resolve that
for the rapid reader. (I'm not concerned about implementers, but
rather about operations people planning client or server upgrades;
they need to know it's OK to mix and match.)

[Ballot discuss]
I received the following comment from the OPS directorate. I understand from the comment that the issue might have been discussed in the past. I would appreciate if you could reconsider this issue:

How is a server expected to handle the case where a single computer first
chooses to identify itself with a client identifier, and then later chooses
not to supply an identifier at all?  This is never clearly explained in
any section of RFC2131/2132, so there are three possible interpretations:

A) Treat them as two separate, discrete clients.

B) Synthesize a client identifier out of the CHADDR field - thus treating
  clients who identify themselves with their ethernet MAC address as the
  same client which didn't identify themself, on the same MAC address.

C) 'Slide' identities between the two clients.  In essence, the lack of a
  client-identifier is like an "ANY" tag - any lease which was allocated
  to a client using that CHADDR contents is fair game, and vice versa...
  any lease which did not have a client identifier but had the same CHADDR
  is fair game.

It might seem that the worst such different interpretations might cause
is redundant address allocations - something that gets solved by itself
when addresses expire.  It's true that this happens, and it's highly
undesirable by DHCP server administrators, especially in the case where
clients are limited to a certain number of leases (due to contractual
levels of service).

There exists a "Windows for Embedded Devices" whose product name escapes
me right at this moment.  Consider then the following reference case:

1) PXE boots and obtains an IP address and configuration via DHCP - it is
  told to download the Windows boot image.

        - A server now has a lease allocated to this MAC address in its
          database, as allocated to a client that did not supply a client
          identifier.

2) Execution is passed to the Windows boot image - the system already has
  an IP address, configured by PXE, but Windows wants to query the DHCP
  server with more, vendor-specific, options added to the 'Options Request
  List' to get extra configuration state the original PXE client did not
  know it needed to know.

        - The Windows boot image sends a DISCOVER message with the address
          as obtained by PXE in a 'Requested Address' option, and a client
          identifier whose contents match the CHADDR field.

        - A server as implimenting interpretation A (above) allocates a new
          address for the client, since the Windows client did supply a
          client identifier, and this is interpreted as meaning it is a
          seperate, distinct client from the former.

        - The Windows boot image, running within PXE, is unable to alter the
          network configuration, and instead of REQUESTing the lease it was
          just offered, continues to resend DISCOVER messages.

3) The system ultimately times out and reboots itself - goto 1).


This actually represents an insidious compatibility problem, and I
submit it stems from poor definition of the client identifier option
in RFC2131/2132.

Now, this draft has fine goals - the DHCPv6 Node Identifier that is being
duplicated here is the right way to go about client identifiers, and it will
serve useful purposes.  Not only for the dual-stack purposes of being able
to detect what specific clients (as identified by their DUID's) are using
both ipv4 and ipv6 addresses, but also for things like Dynamic DNS, and for
unusual client configurations (clients having more than one interface - since
the server can peek into the client-identifier it can see that a client has
multiple interfaces active within a given broadcast domain - you may want
to allocate the same address, different addresses, or even different
addresses in different subnets within that broadcast domain).

Since the old identifiers were 'completely opaque', it's also a reverse
compatible approach - servers that treat the client identifier as an
opaque field will work acceptably well under all imaginable circumstances
when clients supply identifiers in this draft's suggested formats.

These are all good things, and we need this draft to reach RFC at some
point.

But I think we have learned from the past that not defining a "MUST"
behaviour for this case - where a client presents itself at different
times with a mixture of identities - produces incompatibilities due to
differing interpretations.
Producing a new format of the client identifier option, and not at least
describing this problem much less addressing it, seems to be "not learning
from our own mistakes."

Understand that the problem is magnified in this draft -

In the old RFC2131/2132 world, we could (as I described above) just
synthesize a client-identiifer out of the ethernet MAC address and address
99.9% of the problematic cases.

But in this draft, we have defined a whole new encoding for the client
identifier that has never appeared elsewhere and cannot be synthesized by
the DHCP server from any other DHCP packet contents.

The only option I believe systems administrators will employ to avoid
deployment problems with products conforming to this draft as delivered
by products that don't (PXE), is to disable their server's implementation
of client identifiers entirely.

Which is not at all what we want.

So it's a good draft, with good contents, features that we need, but also
with what I think is a serious potential problem that I think should be
addressed at least as it applies to this draft, if not in general.

[Ballot comment]
I received the following comment from the OPS directorate. I understand from the comment that the issue might have been discussed in the past. I would appreciate if you could reconsider this issue:

How is a server expected to handle the case where a single computer first
chooses to identify itself with a client identifier, and then later chooses
not to supply an identifier at all?  This is never clearly explained in
any section of RFC2131/2132, so there are three possible interpretations:

A) Treat them as two separate, discrete clients.

B) Synthesize a client identifier out of the CHADDR field - thus treating
  clients who identify themselves with their ethernet MAC address as the
  same client which didn't identify themself, on the same MAC address.

C) 'Slide' identities between the two clients.  In essence, the lack of a
  client-identifier is like an "ANY" tag - any lease which was allocated
  to a client using that CHADDR contents is fair game, and vice versa...
  any lease which did not have a client identifier but had the same CHADDR
  is fair game.

It might seem that the worst such different interpretations might cause
is redundant address allocations - something that gets solved by itself
when addresses expire.  It's true that this happens, and it's highly
undesirable by DHCP server administrators, especially in the case where
clients are limited to a certain number of leases (due to contractual
levels of service).

There exists a "Windows for Embedded Devices" whose product name escapes
me right at this moment.  Consider then the following reference case:

1) PXE boots and obtains an IP address and configuration via DHCP - it is
  told to download the Windows boot image.

        - A server now has a lease allocated to this MAC address in its
          database, as allocated to a client that did not supply a client
          identifier.

2) Execution is passed to the Windows boot image - the system already has
  an IP address, configured by PXE, but Windows wants to query the DHCP
  server with more, vendor-specific, options added to the 'Options Request
  List' to get extra configuration state the original PXE client did not
  know it needed to know.

        - The Windows boot image sends a DISCOVER message with the address
          as obtained by PXE in a 'Requested Address' option, and a client
          identifier whose contents match the CHADDR field.

        - A server as implimenting interpretation A (above) allocates a new
          address for the client, since the Windows client did supply a
          client identifier, and this is interpreted as meaning it is a
          seperate, distinct client from the former.

        - The Windows boot image, running within PXE, is unable to alter the
          network configuration, and instead of REQUESTing the lease it was
          just offered, continues to resend DISCOVER messages.

3) The system ultimately times out and reboots itself - goto 1).


This actually represents an insidious compatibility problem, and I
submit it stems from poor definition of the client identifier option
in RFC2131/2132.

Now, this draft has fine goals - the DHCPv6 Node Identifier that is being
duplicated here is the right way to go about client identifiers, and it will
serve useful purposes.  Not only for the dual-stack purposes of being able
to detect what specific clients (as identified by their DUID's) are using
both ipv4 and ipv6 addresses, but also for things like Dynamic DNS, and for
unusual client configurations (clients having more than one interface - since
the server can peek into the client-identifier it can see that a client has
multiple interfaces active within a given broadcast domain - you may want
to allocate the same address, different addresses, or even different
addresses in different subnets within that broadcast domain).

Since the old identifiers were 'completely opaque', it's also a reverse
compatible approach - servers that treat the client identifier as an
opaque field will work acceptably well under all imaginable circumstances
when clients supply identifiers in this draft's suggested formats.

These are all good things, and we need this draft to reach RFC at some
point.

But I think we have learned from the past that not defining a "MUST"
behaviour for this case - where a client presents itself at different
times with a mixture of identities - produces incompatibilities due to
differing interpretations.
Producing a new format of the client identifier option, and not at least
describing this problem much less addressing it, seems to be "not learning
from our own mistakes."

Understand that the problem is magnified in this draft -

In the old RFC2131/2132 world, we could (as I described above) just
synthesize a client-identiifer out of the ethernet MAC address and address
99.9% of the problematic cases.

But in this draft, we have defined a whole new encoding for the client
identifier that has never appeared elsewhere and cannot be synthesized by
the DHCP server from any other DHCP packet contents.

The only option I believe systems administrators will employ to avoid
deployment problems with products conforming to this draft as delivered
by products that don't (PXE), is to disable their server's implementation
of client identifiers entirely.

Which is not at all what we want.

So it's a good draft, with good contents, features that we need, but also
with what I think is a serious potential problem that I think should be
addressed at least as it applies to this draft, if not in general.

[Ballot comment]
Mmm... I see citations in the abstract. My understanding is that
those are not allowed. Easy to fix, just use perenthesis instead
of square brackets.

[Ballot discuss]
I expected to find some words stating what happens when a client following this spec meets a server that doesn't, or vice versa. Are these failure scenarios or is there implicit backwards compatibility? This really isn't obvious and should probably be added to the applicability section.

IANA Follow-up comments:
Below are the comments from the Author to the IANA Last Call response.
IANA would please like to know which of his suggested options should be followed.

From: Ted Lemon 

> Upon approval of this document the IANA will mark the 'client
> identifier' type codes other than 255 as deprecated.
> It is not clear which client idenifier types these are and in which
> registry they are located in. Clarification is needed.
Argh. A stupid mistake on my part. The relevant section of
RFC2132 is:

The client identifier MAY consist of type-value pairs similar to the
'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist
of a hardware type and hardware address. In this case the type field
SHOULD be one of the ARP hardware types defined in STD2 [22]. A
hardware type of 0 (zero) should be used when the value field
contains an identifier other than a hardware address (e.g. a fully
qualified domain name).

So this is going to be a little bit difficult, since obviously you
can't deprecate all ARP hardware types other than 255. It seems to
me that there are three possible actions to be taken here. One is
to delete this requirement from the draft. The second is to update
the draft to more accurately reflect what RFC2132 says, and put a
note on the IANA document that specifies ARP hardware types (http://
www.iana.org/assignments/arp-parameters) to indicate that while DHCP
has historically used the ARP hardware type to indicate the type of
the client identifier, that usage is now deprecated as of RFC-
whatever-this-turns-out-to-be. The third option is to update the
document to explain the situation in more detail, as in the previous
option, and to not do anything to the IANA page (I don't know if it's
even appropriate to put a note like this on the IANA page).

Personally, I would prefer the second option if it is acceptable to
you, or the third option, if the second is not acceptable.

Sorry for the confusion!

[Ballot comment]
The document's IANA considerations says:

This document deprecates all 'client
  identifier' type codes other than 255, and thus there is no need
  for the IANA to track additional possible values for the type field
  of the 'client identifier' option.

I got a bit confused about whether any values registered in this:
http://www.iana.org/assignments/bootp-dhcp-parameters

are deprecated, or this only deprecates further registration.  A
clarification may be in order.

[Ballot comment]
Section 2.4 says:
  >
  > Like the client identifier format recommended by RFC2131, this
  > suffers from the problems previously described in (2) and (3).
  >
  Section numbers are needed to refer to the previous problems.

[Ballot discuss]
The Introduction says:
  >
  > This supersedes the behaviour specified in RFC2131 and RFC2132.
  >
  The header and the abstract need to indicate that this document
  updates RFC 2131 and RFC 2132.

[Ballot comment]
I didn't find this document particularly clear it seemed harder to
follow than it should be.  I think that's probably because it is a set
of diffs to other behavior and has too many references to stand on its
own.  However I did eventually follow it and I don't think anything I
found should block publication at this stage.

Submission Questionnaire:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes and yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

Yes and no.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

Ralph is a little uncomfortable with changing the format of the
client-identifier so that a server must parse the content, which
represents a change in the definition of the client-identifier from
RFC 2131 and RFC 2132.

The issue has been discussed in the WG and the consensus of the WG is
that the change in usage of the client-identifier is not harmful and
is useful, in particular for resolution of conflicts in doing dynamic
updates on FQDNs used by DHCP clients.

Stig is a little uncomfortable with the requirement that DHCPv4 and
DHCPv6 clients on a dual-stack host must use the same identifier. He
believes this is difficult to satisfy, at least when the DHCPv4 and
DHCPv6 clients are independent, possibly from different vendors, as
is typically the case now. He agrees that this should be done whenever
possible though.

Stig discussed this issue with one of the authors (Ted Lemon), who
disagrees that it is a problem.

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

Several members of the WG are strongly in favor of submitting the
document to the IESG, with no dissent in the remainder of the WG.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.
 
No.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

There are several style and boilerplate nits found by the idnits
tool.  Ted Lemon will publish a revision that is ID-nit-compliant
immediately after IETF 62.

8) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

  This document specifies the way in which DHCPv4 clients should
  identify themselves.  DHCPv4 client implementations that conform to
  this specification use a DHCPv6-style DHCP Unique Identifier (DUID)
  encapsulated in a DHCPv4 client identifier option.  This supersedes
  the behavior specified in RFC2131 and RFC2132.

  The reason for making this change is that as we make the transition
  from IPv4 to IPv6, there will be network devices that must use both
  DHCPv4 and DHCPv6.  Users of these devices will have a smoother
  network experience if the devices identify themselves consistently,
  regardless of the version of DHCP they are using at any given
  moment.  Most obviously, DNS updates made by the DHCP server on
  behalf of the client will not be handled correctly.  This change
  also addresses certain limitations in the functioning of
  RFC2131/2132-style DHCP client identifiers.

  This document first describes the problem to be solved.  It then
  states the new technique that is to be used to solve the problem.
  Finally, it describes the specific changes that one would have to
  make to RFC2131 and RFC2132 in order for those documents not to
  contradict what is described in this document.

  This document updates RFC2131 and RFC2132.  DHCPv4 server
  implementations SHOULD conform to this document.  DHCPv4 clients on
  network devices that are expected to support DHCPv6 in the future
  SHOULD conform to this document.  This document makes no changes to
  the behavior of DHCPv6 clients or servers.

  DHCPv4 clients and servers that are implemented according to this
  document should be implemented as if the changes specified in
  section 4.3 and 4.4 have been made to RFC2131 and RFC2132.

  - Working Group Summary

The WG has given this document careful review,  It has been discussed
extensively at WG meetings and on the WG mailing list.  There was
substantive discussion during the WG last call.

  - Protocol Quality

The WG has given this document careful review.  It extends the
client-identifier option defined in RFC 2131 and RFC 2132 based on the
definition of the DUID in DHCPv6.  The extension is necessary for
interoperability in hosts that use both DHCPv4 and DHCPv6.  The
document includes text changes for RFC 2131 that will be incorporated
into the DHCP specification when it is revised for Full Standard.

IANA Last Call Comments:
Upon approval of this document the IANA will mark the 'client identifier' type codes other than 255 as deprecated.
It is not clear which client idenifier types these are and in which registry they are located in.  Clarification is needed.