Help with DHCPv6 client-identifiers

Alex Bligh alex at alex.org.uk
Sat Nov 19 15:38:38 UTC 2011


> The use of a /80 per VLAN (independent routable domain) is a bit
> "unconventional", to say the least, and more on this later.
...
> A core decision about IPv6 has been that only /64 is *generally
> routable*. That is, inter-site routers (BPv6) are not required
> to route on any longer prefix. Indeed arguably even intra-site
> routers are not required to route on prefixes longer than /64.

In my config (which is hardly unusual - a cloud platform - hosting had
pretty much the same use cases when IPv6 was being designed), they aren't
independently routable in any real sense. I'm controlling the L3 routing,
and it mostly won't leave the same set of virtual architecture, never mind
go inter site. 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.

> But really you are raising two more significant different
> issues:
>
>   * 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. Stuff that "just worked" for IPv4 got needlessly
broken. Which is particularly silly given autoconfig effectively
uses this a an identified anyway.

> 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.

> Admittedly it is however a very convenient thing to do in many
> situations. But key point here is that it is not a *protocol*
> issue, or a *server* issue. All the protocol and the server
> demand is that the client supply an ID. Which ID is supplied by
> the client, which can well be the MAC address of the interface,
> should be purely a *client-side* matter.

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.

> 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.

Don't get me wrong, having written a DHCP server, I would be the
last person to argue DHCP is a perfect protocol.

However, consider the percentage of hosts which receive their IPv4
numbering through DHCP - somewhere north of 99% I'm guessing.
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 etc., but in
part because it has been made deliberately user hostile in some
cases (omission of gateway lists being another example).

-- 
Alex Bligh



More information about the dhcp-users mailing list