host-identifier with IPv6

[Frank Sweetser]

Ted Lemon wrote:
> On Mar 1, 2009, at 5:34 PM, Eustace, Glen wrote:
>> What should the ????? be
> 
> That I don't know - these days I don't work with the ISC server 
> anymore.   All I'm saying is that there's no protocol restriction 
> preventing you from getting what you want.

Actually, if I'm properly reading RFC 3315, there is.  From section 9, 
regarding DUID:

-----
Clients and servers MUST treat DUIDs as opaque values and MUST only compare 
DUIDs for equality.  Clients and servers MUST NOT in any other way interpret 
DUIDs.
-----

That says to me that if a server attempts to extract the HW address that was 
used to generate a given DUID, it's violating the RFC.

Even so, if the server behavior were the only issue, that would be one thing. 
  However, section 9.2 on the DUID-LLT format further complicates things in 
how it specifies client behavior, and on the wire data:

-----
The choice of network interface can be completely arbitrary, as long as that 
interface provides a globally unique link-layer address for the link type, and 
the same DUID-LLT 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-LLT.
-----

So while in DHCPv4 the client HW address designated the specific interface 
that the request was generated for, in DHCPv6, even if you do extract the HW 
address from the DUID, you have no way of telling if the HW address you found 
is the one you're assigning an IP address to.  With dual port desktops 
becoming less uncommon, and nearly every laptop out there shipping with wired, 
wireless, and optionally WWAN interfaces, this is a situation that will crop 
up fairly frequently.

In addition, at many sites machines get reimaged fairly frequently (some of 
our lab machines get reinstalled from scratch half a dozen times a year, or 
more frequently if needed) which makes the "stable storage" designation less 
useful.

(If I've misread any of this, or it's been superseded by something else, I 
would love to be proven wrong!)

In the end, I guess my concern is that rather than the ???? in Glen's question 
being something that ISC dhcpd is handling strangely or hasn't documented yet, 
it's something that the specification defines to be
   a) unknowable beforehand, even if the HW address is known
   b) forcibly disassociated with the traditional DHCPv4 identifier
   c) variable with software changes, where the DHCPv4 identifier remains fixed

I would also like to point out that this extends to more than just simple IP 
address assignment.  We have many devices, such as thin wireless APs, IP 
phones, network cameras, and thin clients that all need to have host specific 
DHCP options sent out for things like server location.  In DHCPv6, I have no 
way of assigning a set of options to an arbitrary host, meaning that none of 
those devices are compatible with DHCPv6 as it currently stands.

-- 
Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
     GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC