Help with DHCPv6 client-identifiers

[Peter Grandi]

>>> Autoconfig is quite inflexible in terms of addressing and
>>> netmasks which can be used. [ ... ]

It is a simple minded mechanism to give plug-and-play like
AppleTalk and XNS/IPX had some decades ago. That's why there are
also RA and DHCP and other more explicit remote config systems.

>>> What we'd really like is to be able to allocate a fixed
>>> number of least significant bits (say 24) as "index of IP on
>>> one NIC", then the next (say 24) as "index of NIC on vLAN".

IPv6 leaves the suffix /64 more or less to use as you see fit.
Even if a scheme like you describe above seems amazingly unwise
to me, but it is your right to keep digging :-).

>>> Each vLAN would then get a /80.  We could do have done that
>>> with DHCP or similar if it worked.

The use of a /80 per VLAN (independent routable domain) is a bit
"unconventional", to say the least, and more on this later.

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.

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.

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.

As to the second issue, I agree that whichever /128 is returned
by the DHCP server should be fully manually configurable. After
all if one uses DHCP it is because it is an alternative to SLAAC.

>> Then it is indeed fortunate that DHCPv6 doesn't do what you
>> want. Using prefixes wider than /64 breaks IPv6. That's why
>> SLAAC doesn't do it.

> Of course using prefixes wider than /64 doesn't break IPv6. It
> breaks SLAAC, which is not at all the same thing. [ ... ]

Well, it depends on what one means by "prefixes wider than /64"
and "break IPv6".

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.

This is not because it would not work for technical reasons;
conceivably the routable prefix could be anything up to /128.

It is just a matter of declaring it so as a convention (even if
no doubt motivated by the efficiencies of having routers only
keep track of 64 instead of up to 128 bits).

In practice:

* It is well possible to make many routers, e.g. Linux based
  ones, to route on prefixes longer than /64.

* It is rather unwise to do so, because it may trigger corner
  cases, especially in networks exposed to the Internet.

So it is advisable (but not much) to use host addresses longer
than /64 only within link scope (multiple subnets on the same
broadcast/nonrouted domain/VLAN), and SLAAC indeed takes
advantage of that.

> For our uses, SLAAC simply doesn't cut it - so we end up using
> RA plus DHCPv6. I can bitch and moan about what I think is a
> bad design - making DHCPv6 dependent on RA. But at the end of
> the day I can live with RA and DHCPv6.

Well, configuring addresses and routers are really different
things, so it is quite reasonable that there be two different
system for two different purposes.

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,
but it is still meant to be a general host configuration system,
independent of addressing. In theory DHCP should be usable even
ignoring completely the link/IP address issue (e.g. the IP
address is static, and the client sends a query asking only for
the domain search list, and gets a reply listing only that).

Some of the replies in this thread, notably Bjorn's, seem to
imply that turning DHCP into a general purpose configuration
protocol was a bad idea. I don't agree with that. Sure, we have
RA, but if a DHCP server can deliver lists of DNS suffixes to a
client, it might as well deliver a list of router addresses
etc.; similarly we have other service autodiscovery protocols,
but we can still use DHCP for explicit client configuration.

> However, the decision to make it impossible to get the MAC
> address of the client through DHCPv6,

Well, the question here is that the *client* can very well use
the MAC address as its client ID, so it is really not necessary
to have the server default the link address to be the client ID.

> I think, is completely inexcusable, and needs to be fixed.

This I sort of agree with but not to the extent of "completely
inexusable". I think that tools should be able to be configured
to so "odd" things, for people who do know what they are doing,
as the IP (not Internet!) tradition is to provide low level
features even if it means giving people enough rope to hang
themselves with it.

In part however I sympathize with those who do not want tools to
give end users enough rope to hang themselves with it, because
the latter usually then generate support nightmares. Sometimes
you don't want end users to have too much fleixibility simply to
minimize your support load, and even worse, sometimes that rope
because the new "standard".