host-identifier with IPv6

[Ted Lemon]

On Mar 3, 2009, at 7:32 PM, Chuck Anderson wrote:
> It may be the case that the DUID was generated using and now refers to
> a hardware address that is no longer present, or indeed is now present
> on a different machine.

Right, and in that case the Mac address will now appear on a machine  
that's not the machine registered in the database for that Mac  
address.   So you have a problem whether you're using DUIDs or not - a  
different problem, to be sure, but there has to be some mechanism for  
dealing with this problem in whichever way it manifests.   So to me,  
this is a wash.

> You had to register that MAC address
> to enable the system to get network access or to associate it with
> certain boot options from the DHCP server.  Later you remove the USB
> network interface because the installed OS supports the internal NIC.
> Then you move the USB NIC to another machine.  Now the netbook's DUID
> has embedded in it the MAC of the USB NIC which is now in a different
> system.

If you are registering Mac addresses, you could just as easily  
register DUIDs.

> I could just as easily apply the same logic to DHCPv6 itself: "DHCPv6
> isn't required for IPv6 to work, so why do we have DHCPv6 at all?  We
> have RA's and SLAAC and static addressing."  I would answer that
> RA/SLAAC doesn't fit everyone's use case, so we have DHCPv6 as another
> option.

You wouldn't be the first to do so - there are many people in the  
v6ops working group who would rejoice if DHCPv6 were eliminated, and  
consider it a very bad thing that the protocol spec ever became an RFC.

> The same thing applies to DUID vs. link-layer address.  Why
> can't we have various options to suit the needs of different user
> bases?

Because you haven't yet stated a /need/ not addressed by the DUID.    
You'd rather not implement the DUID-based solution, but the DUID-based  
solution satisfies the same /need/ you would like to satisfy using a  
Mac-address-based solution.

> 1. Only allowing known-hosts to get an IPv6 address from the DHCPv6
> server via any subnet and ethernet port of your campus, or perhaps
> only certain subnets/pools depending on policy.  Where known =
> identified as belonging to a user you know the identity of.  (Hint:
> 802.1X doesn't count because its support isn't universal.)  It doesn't
> have to be a 100% bullet-proof secure identity, just a mostly stable
> identifier that maps back to a user via a registration process.

This can be done with a DUID.   So this isn't a convincing use case.

> 2. Classifying a physical hardware device as belonging to a specific
> group for the purposes of automated deployment mechanisms.  i.e. read
> MAC address off label and assign it as being a "Computer Science PXE
> boot" vs. "Electrical Engineering PXE boot".  (Hint: recording the
> DUID generated by the Operating System doesn't work if there is no OS
> yet, or if the OS is cloned or otherwise wiped and reinstalled.)

Right, but this one is even easier - just peek into the DUID and get  
the Mac address out of it, and match it to whichever network interface  
was used to generate the DUID, which will be in your database, since  
you're scanning all the Mac addresses on all the devices.   You don't  
need a protocol change to make this work, except perhaps permission to  
peek inside the DUID, if you don't by my argument that it's okay to do  
so in the use case you're presenting.

> Ah, but we have these nice things called "ARP (nee NDP) tables" and

> "Forwarding Databases" that keep track of every MAC address's location
> on the network.  For new, unknown MAC addresses that appear on the
> network, a captive portal captures the MAC address, and the user logs
> in and registers that hardware device as belonging to that user.

> Could the same automatic solution work with DUIDs instead of MAC
> addresses?  I suppose, but that would require re-tooling a lot of
> deployed infrastructure.  For example, changing the workflow to DUID
> instead of MAC/link-layer address, we can no longer find where a user
> is physically on the network without digging into the DHCP lease
> database, cross referencing the DUID there with the IPv6 leases, then
> cross referencing those with NDP tables, then cross referencing those
> with FDB tables, finally getting to a physical location.

This argument doesn't make sense.   You're using the Mac address to  
control what the DHCP server does.   So you're already talking to the  
DHCP server.   The IP address in the NDP table is as good an  
identifier as the Mac address in this situation.

> But perhaps less important than "why" is the fact that we and many
> others *have* chosen this model already for existing IPv4 networks and
> this has worked for them for many years.

No.   "Why" is what's important, and that's why I asked you.   With  
all due respect, "this is how I've always done it, and so you have to  
keep doing it this way" is just not a good reason to change a protocol  
that's already widely implemented.

You raised other issues, but I'm going to answer them in my answer to  
Frank Bulk, because this is getting so long.