Help with DHCPv6 client-identifiers

[Peter Grandi]

[ ... ]

> Of course in many deployments it makes perfect sense for a
> broadcast domain to have no fewer than 64 bits of address
> space. However, in one application we have, there is a virtual
> router port per VM, which results in a /64 per machine if
> SLAAC etc. is used, which is hugely wasteful.

So you have an addressing architecture with a different subnet
per host, for whatever reason. IPv6 is designed to have /64 or
wider subnets. Perhaps you shouldn't be using IPv6, as it is
incompatible with your architecture :-).

[ ... ]

>> * You want to assign IPv6 address prefixes from some unique
>> persistent client identifier.
>> 
>> * You want to control what goes into the suffix of the IPv6
>> address assigned to a client.

> Actually, personally, I don't much care about (1) provided I
> can do (2). I could assign from the virtual equivalent of a
> circuit ID or whatever.

> However, as I already have one persistent client identifier
> (MAC address, assigned be me every time I boot a VM), it seems
> irrational to invent another.

As to rationality/principles (as opposed to expediency) that's
not the client ID, it is just a field in the frame containing
the DHCP packet. The same 48-bit number *happens* to be usable
as a client ID because the the 802.11 people defined a mechanism
to make their lionk layer addresses globally unique. But it is
just a 48-bit number.

> Stuff that "just worked" for IPv4 got needlessly broken. Which
> is particularly silly given autoconfig effectively uses this a
> an identified anyway.

I think that TedL's point, and mine at least, is that IPv4 was
broken that way, and that breakage has been fixed.

>> As to the first issue, it is indeed a bad idea as some have
>> argued in previous replies to continue using an interface link
>> layer address as the client ID, so it should not be enshrined
>> into a revised DHCP protocol.

> I'm not arguing it should have been enshrined. I agree that in
> many use cases, it is a bad idea. However, not having it as a
> standardised option is a quite different matter.

As to this I agree. Arguably, as a matter of convenience, a DHCP
server could have an option to copy by default the source link
address or some other field (for example switch id/port number,
some hash of a 802.1x certificate, ...)  into the client ID if
not already set.

But it should be really put into the *client* side. That is, in
an ideal world, if the DHCPv6 client is not given an explicit
client ID, it should be (optionally) defaulted to the link layer
address.

> Right, but those of us working in environments where we don't
> know the client OS in advance need to know what the identifier
> is that will identify the client machine, and have standard
> behaviour across client OS. Saying the client can "make one
> up" does not help.

You could *give* your customers a client ID and make them set it
up in whatever way ends up in the DHCP packet.

>> But the issue here is really scope creep: DHCP (or rather its
>> ancestors) started as a host address protocol, and then became a
>> host configuration protocol for lots of other things. DHCP for
>> IPv4 regrettably forces using the link address as the client ID,

> This is not true, as I understand it. The client is compelled
> to provide its hardware address, but the server can allocate
> IP addresses based on this or any of the options, or a
> combination thereof.

Well, it can even allocate addresses from a pool without any
particular relationship to any request field, but the client ID
is effectively always assumed to be the original link source
address.

In DHCP for IPv6 instead there the "stateless" option instead
that delivers configuration data without any address allocation,
which is a big conceptual difference.

[ ... ]

> Now consider the number receiving their IPv6 numbering through
> DHCP - somewhere far lower I'm guessing. This would seem to me
> to indicate it has failed as a protocol. That's in part
> because some of the functions are performed by autoconfig

That's a deliberate design feature indeed. In so many cases with
IPv4 what is delivered with DHCP is just host and router address
adn DNS servers, and that for most IPv6 can be done with RA (and
if one uses further service discovery options a lot more can be
autoconfigured), and I guess that "stateless" DHCP for the other
configuration settings is not as widely appreciated as it should
be (just as many useful options of DHCP for IPv4 are not used
either).

> etc., but in part because it has been made deliberately user
> hostile in some cases (omission of gateway lists being another
> example).

Again I think that is a weird decision, probably only motivated
by the desire to push IPv6 deployers into autoconfig as much as
possible, as Bjorn I think seemed to argue in an earlier reply.