Subject: [dhcwg] I-D Action:draft-ietf-dhc-duid-uuid-01.txt

From: [email-masked]
Date: Wed, 15 Dec 2010 08:45:01 -0800

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           : Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID)
	Author(s)       : T. Narten, J. Johnson
	Filename        : draft-ietf-dhc-duid-uuid-01.txt
	Pages           : 6
	Date            : 2010-12-15

This document defines a new DHCPv6 Unique Identifier (DUID) type,
called DUID-UUID.  DUID-UUIDs are derived from the already
standardized UUID format.  DUID-UUID makes it possible for devices to
use UUIDs to identify themselves to DHC servers and vice versa.
UUIDs are globally unique and readily available on many systems,
making them convenient identifiers to leverage within DHCP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-duid-uuid-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 15 Dec 2010 11:50:31 -0500

DHC Chairs:

I've just resubmitted the DUID document. The only change was putting
in the code point that IANA assigned a few weeks back.

I haven't received any comments and there hasn't been list discussion
on the document in a while. I am not aware of any outstanding issues
with this dcument.

I believe the document is ready for WG LC. If you agree, can you kick
this off?

Thanks!

Thomas

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Dec 2010 11:08:21 -0600

While I'm all for moving this forward, I would like to suggest that the
following text in Section 1 is perhaps a bit misleading:

   In DHCPv4, all clients identify themselves to servers via the MAC
   address of the interface on which the DHCP packet is sent.  The MAC
   address identifier generally remains constant across machine
   restarts, installation of new operating system releases, changes in
   hardware configuration such as addition or removal of storage
   devices, etc.  While the MAC address will change if the network
   interface is replaced, this is a relatively uncommon event.

While it is true that the htype, hlen, chaddr fields are set by clients,
the Client ID option is supposed to be used if provided by the client.
And to make it easier to identify a single dual stack client there is
RFC 4361 (Node-specific Client Identifiers for Dynamic Host
Configuration Protocol Version Four (DHCPv4)) which defines the Client
ID format for the DUID to be used by DHCPv4 clients. (This benefits DNS
Updates and other situations.)

I also find this argument kind of contradicts the paragraph which
follows about the DUID-LL at least - the mac address for the DUID-LL is
just as like (or unlikely) to change as the DHCPv4 MAC address? (Sure,
the DUID-LLT is more likely to change because of loss of storage. And I
guess if the device has multiple interfaces the DUID-LL may change if
any of these interfaces is changed or one is added (or they are
reordered). But, with most of today's devices that is rather unlikely?

Perhaps these are really stupid nits and that I didn't raise them
earlier.

Personally, one might argue for less to be said in the introduction. The
DUID-UUID is simply useful in situations where a UUID exists that it can
be used. (While I argued a while back that the DUID-EN could have been
used to encode the UUID, I'm find with defining this format as we have
plenty of code points and it saves at least 4-bytes.)

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas Narten
Sent: Wednesday, December 15, 2010 11:51 AM
To: Ted Lemon; John Jason Brzozowski
Cc: [email-masked]
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-duid-uuid-01.txt

DHC Chairs:

Thanks!

Thomas
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Thomas Narten <[email-masked]>
Date: Wed, 15 Dec 2010 12:28:42 -0500

Hi Bernie.

Thanks for the quick review.

In fairness, others (David Hankins??) have not fully agreed with my
description of identifiers.

I had forgotten about  RFC  4361 and agree a reference is probably in
order.

Let me mull a bit and propose some alternative text.

One general question I have though. When (in DHCPv4) a client provides
both a client identifier and the MAC address, are *both* used by the
server to determine what to return, or is only the client identifier
used?

For example, suppose I have a client with two interfaces attached to
the same link. The client uses DHCPv4 on both interfaces, providing
the *same* client ID in both cases, but a different MAC address.

Will the server return the same IP address, or different IP addresses?

Thomas

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Dec 2010 12:25:47 -0600

I believe that the server MUST always return the mac address that was in
the request. I also believe that the mac address (chaddr) may be
technically optional when the client-id is passed in (though best to
send in both).

Note that the IAID would be different for each interface.

>the *same* client ID in both cases, but a different MAC address.

The mac address (chaddr) should be set based on the interface on which
the packet was sent. The client identifier option data will be different
because of the different IAID values, but the DUID part of the client
identifier option data will be the same. And thus ...

>Will the server return the same IP address, or different IP addresses?

Different addresses will be returned (because of the difference in
IAID).

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Wednesday, December 15, 2010 12:29 PM
To: Bernie Volz (volz)
Cc: Ted Lemon; John Jason Brzozowski; [email-masked]
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-duid-uuid-01.txt

Hi Bernie.

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Dec 2010 22:00:44 -0800

> technically optional when the client-id is passed in (though best to

chaddr is not used for layer two implementations that don't have link-layer addresses, like Firewire.   However, it is necessary to return chaddr in all other cases; otherwise the relay agent will not be able to unicast the response in cases where the client is not yet configured.

This is also why Bernie's statement about which chaddr to send is important--if the client sends the chaddr from an interface other than the one it is configuring, the response may never arrive.   Chaddr's use as an identifier is an overloading of its other use--as an address.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 16 Dec 2010 11:26:04 -0500

Bernie,

To clarify one point:

> reordered). But, with most of today's devices that is rather

In DHCPv4, the MAC address is required to be the one from the
interface DHCP is being invoked on.

In DHCPv6, the MAC address used in a DUID-LL (and DUID-LLT) is taken
from *any* of the interfaces, not necessarily the one being
configured. The exact wording is:

   9.4. DUID Based on Link-layer Address [DUID-LL]

   This type of DUID consists of two octets containing the DUID type 3,
   a two octet network hardware type code, followed by the link-layer
   address of any one network interface that is permanently connected to
   the client or server device.    9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT]
...

   The choice of network interface can be completely arbitrary, as long
   as that interface provides a unique link-layer address and is
   permanently attached to the device on which the DUID-LL is being
   generated.  The same DUID-LL SHOULD be used in configuring all
   network interfaces connected to the device, regardless of which
   interface's link-layer address was used to generate the DUID.

Thus, different stages in the boot strapping process might select a
different LL address.

So with DHCPv6, there is less certainty that the same MAC address will
be used than is the case with DHCPv4.

Right?

Thomas

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Dec 2010 10:45:53 -0600

>be used than is the case with DHCPv4.

Yes, on both accounts that sadly this can be an issue when multiple
pieces of code are involved and there are multiple interfaces. And, it
also applies to the single interface case as these different pieces of
code select different DUID types!

I'm not sure how the IETF could mandate an interface selection algorithm
(i.e., use the 'lowest' mac address?) or that the DUID be stored in some
kind of permanent storage (flash) which all software MUST then use.

The text in RFC 3315 was pretty clear that the device MUST use the same
DUID once it has used one, but how and whether than can be accomplished
is of course an issue. For example:

   Clients and servers using this type of DUID MUST store the DUID-LLT
   in stable storage, and MUST continue to use this DUID-LLT even if the
   network interface used to generate the DUID-LLT is removed.  Clients
   and servers that do not have any stable storage MUST NOT use this
   type of DUID.

Clearly using the UUID, if that is burned into the device, is a good
addition as all software should then use this.

---

Note that my main point here is that the text in the introduction makes
it appear that DUID based identifiers are "less" stable than DHCPv4
mac-addresses. And while the above discussion shows that there might be
a marginal difference, I don't really think there is. The well known
issue in DHCPv4 is that PXE boot uses the mac-address to identify the
client whereas many host operating systems then send the DHCP Client
Identifier option (as well as the mac address in chaddr) which is
usually based on the mac-address but is NOT the same to DHCP servers as
using the mac-address. And hence, two leases result.

The advantage for DHCPv6 of course is that having two leases (unless
they are PD) is likely a non-issue (or a very minor inconvenience) as
there are plenty of addresses available on most IPv6 lans. PD might be a
more limiting issue, but I doubt booting software and early stages of
bring a device up would request a PD?

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Thursday, December 16, 2010 11:26 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-duid-uuid-01.txt

Bernie,

To clarify one point:

   This type of DUID consists of two octets containing the DUID type 3,
   a two octet network hardware type code, followed by the link-layer
   address of any one network interface that is permanently connected to
   the client or server device.    9.2. DUID Based on Link-layer Address
Plus Time [DUID-LLT]
...

Right?

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Dec 2010 15:29:06 -0500

>   and servers that do not have any stable storage MUST NOT use this

Typically devices that do net-booting have some kind of nvram in which they store things like DUIDs.   So it was the intention of this text that that nvram be used as the place where the DUID is stored.   If somebody implements an operating system that doesn't follow that intent, then I would say they are violating the spec.   Sure, it's a problem to solve, but it's easily solved.