Help with DHCPv6 client-identifiers
Simon Hobson
dhcp1 at thehobsons.co.uk
Sun Nov 20 10:30:54 UTC 2011
sthaug at nethelp.no wrote:
> > RFC reference please. As far as I'm concerned, IPv6 supports prefix lengths
>> right up to /128. Due to various protocol brokenness, it's difficult to
>> configure hosts with longer prefixes than /64, but that is a different
>> issue.
>
>My guess: The language in RFC 4291 which says that interface identifiers
>are 64 bits:
>
> For all unicast addresses, except those that start with the binary
> value 000, Interface IDs are required to be 64 bits long and to be
> constructed in Modified EUI-64 format.
Hmm, and allocated addresses start with (currently) 0010, so are
required to follow this convention.
Section 2.5 says :
>Except for the knowledge of the subnet boundary discussed in the
>previous paragraphs, nodes should not make any assumptions about the
>structure of an IPv6 address.
So it would seem that 64bit host identifiers are mandated for most
purposes, but the same RFC also specifies that hosts must not make
assumptions about the structure of an address. In fact that very same
section talks about hosts having a variable understanding of the
structure :
>IPv6 nodes may have considerable or little knowledge of the internal
>structure of the IPv6 address, depending on the role the node plays
>(for instance, host versus router). At a minimum, a node may
>consider that unicast addresses (including its own) have no internal
>structure
>...
>A slightly sophisticated host (but still rather simple) may
>additionally be aware of subnet prefix(es) for the link(s) it is
>attached to, where different addresses may have different values for
>n
So it's far from clear !
Personally, it strikes me as short sighted to enforce such a large
subnet size. The answer of course is that it still leaves a vast
number of possible subnets, bt then I suspect the designers of the
IPv4 addressing system probably also considered the address space to
be vast.
Peter Grandi wrote:
>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.
And your suggestion for a unique*, invariant**, deterministic***, and
always available**** identifier is ?
* Yes, some manufacturers have cocked it up, but it's mostly unique.
** The majority of devices where this is being called for don't
change their hardware address frequently (or at all).
*** MAC addresses survive OS re-installs, "reset to factory default"
operations, etc.
**** Any device with an ethernet like interface will have one.
I think everyone complaining that hardware address isn't supplied by
a DHCPv6 client would be happy if the client always supplied a
unique, invariant, and determinable ID. Unfortunately, that was not
included in the IPv6/DHCPv6 specs.
>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.
The problem with any client-side generated identifier that is not
**required** to be in a fixed format (like MAC address) MAC address
for is that it's not actually usable in practice.
If you have uncontrolled clients - you don't have any prior knowledge
of what format it will be.
In the case of some standard options (other than DUID-LL), it will
change if the user boots a different or re-installed OS - so it's not
an identifier for the device, but for the instance of the OS on the
device. Where a device uses DUID-LLT, it may well reset the value if
reset to factory settings.
Ted Lemon wrote:
>But the idea that it's completely inexcusable that we didn't use the
>MAC address as a host identifier is pretty absurd.
I don't think people are saying you need to use the MAC address as a
host identifier. But in the absence of anything better, then not
having it available at all does seem a somewhat retrograde step. The
fact that (according to a previous post) the cable modem guys are
standardising an vendor option for MAC address rather demonstrates
the point - if it's going to end up being used in different options
by different groups, it would have reduced fragmentation to include
it in the standard - once.
Frank Sweetser wrote:
>This old thread should be relevant:
>
>https://lists.isc.org/pipermail/dhcp-users/2009-March/008307.html
Like I said earlier, flogged to death in great depth.
BTW - did anything come of that suggestion to get the standard updated ?
Chris Buxton wrote:
>As an alternative, why not use SLAAC-derived IP addresses, with the
>M flag left off? You can still use DHCPv6 for options (turn on the O
>flag). Just make sure all servers are using EUI-64 addresses -- this
>may require some minor tweaking on Windows systems, to ensure they
>use EUI-64 instead of random addresses.
Ah, so devices won't be allowed to use privacy options.
>This way, the IPv6 address used by each host is:
>
>a) effectively static
>b) based on the MAC address
>...
>Once each host picks its address, you can simply enter it into DNS
>-- possibly the host can do so itself, using DDNS.
You let clients update your DNS !
Given that some of the comments are "you can't trust MAC addresses
because users can change them", I'd say the chances of someone doing
that are probably a bit less than someone being mischievous given
access to update the DNS directly. OK it's a bit different with a
Windows AD setup where the client is already authenticated, but not
in the general case.
In any case, it's a bit more work than just reading the MAC address
off the box, plugging it into your "system", and having the device
just appear on the network in an address range where you want it and
with the DNS entries you want for it.
Again, I don't think people are particularly concerned about using
the MAC address - all they want is a device identifier that's unique,
invariable, and ideally identifiable in advance.
The MAC address is the nearest thing we have to this for the sort of
applications people want to do. It's frequently printed on the
outside of the box and so can be determined even before the unit is
shipped. It's there before the OS is installed, and it's still there
if you boot the system from another OS (such as for diagnostics
purposes).
--
Simon Hobson
Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
More information about the dhcp-users
mailing list