host-identifier with IPv6

Wed Mar 4 02:32:10 UTC 2009

On Tue, Mar 03, 2009 at 05:45:31PM -0700, Ted Lemon wrote:
> On Mar 3, 2009, at 2:25 PM, Frank Sweetser wrote:
>> Between the DUID only including one MAC address of a multi-homed 
>> machine, and the fact that Vista doesn't use the EUI-64 link-local 
>> address when communicating with the DHCPv6 server, it seems 
>> inevitable to me that there are going to be plenty of instances 
>> where the originating MAC address is nowhere to be seen in the 
>> packet once it goes through a relay.
>
> Okay, so can you clarify for me please why it's the case that when you  
> have a multi-homed machine, it's a problem that it only reports one of  
> its mac addresses in the DUID?   Why is one not sufficient?   Why do you 
> need the other?   I'm not telling you you don't need it - I'm just  
> asking why.

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.  For example, maybe you installed a netbook 
using a USB network interface because the installer doesn't support 
the built-in network interface.  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.

>> As a long term solution, how would you feel about a proposal to add 
>> a new DHCPv6 field containing the link-layer address on which the 
>> packet was sent? This could, from the protocol point of view, be 
>> sent as a simple informational attribute, with no guarantee of 
>> uniqueness, while the DUID semantics remain unchanged.  If I've 
>> understood your other comments correctly, this means that the DUID 
>> could still be used as the primary identifier, but the DHCP server 
>> would optionally be able to use the link-layer address, if present, 
>> as an input to administratively configured policy decisions about 
>> which options and values should be handed back to the client.
>
> I think two things.   First, I think that it won't be implemented,  
> because it's not required for the protocol to work.   Second, I don't  
> think the IETF would adopt it, because it's not required for the  
> protocol to work, and I don't think you can come up with a convincing  
> use case (I've been trying to get someone to give me one, and I haven't 
> heard one yet).

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

Can you tell me why these aren't convincing use cases?  What would be 
your recommendations for these:

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.

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

>> This should let those of us with MAC centric workflows (including 
>> many, many EDU networks) migrate to IPv6 with far less pain and 
>> suffering, while still leaving the million client per server ISPs 
>> able to freely ignore the MAC address.
>
> This is going to sound callous.   Please don't take it that way - I'm  
> asking this question sincerely.   I do not understand why you have a  
> "mac-centric workflow."   I do not understand why you think not using  
> the Mac address is going to be a source of such pain.   You call it a  
> "showstopper."   That's *astonishing* to me.

The MAC address has traditionally been and still is the *only* 
globally unique (unique enough in practice) hardware-embedded value 
that can be easily obtained and doesn't change throughout the lifetime 
of the hardware device.  Sure, ethernet hardware is sometimes 
replaced, but that is rare and is a visible change where people have 
come to expect the need to re-register as a known host.

> To me, the idea of tracking every mac address of every device on a  
> network by walking around with a keyboard or a bar-code scanner and  
> entering them all into a database is the very definition of "pain and  
> suffering." DHCP's whole raison-d'être is to save you, the network  
> administrator, the effort of walking around doing a manual process on  
> each machine.

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.  
Sure, that doesn't always work (What, no web browser available on that 
network-attached oscilloscope?  Ok, you have to type the MAC in 
manually from another PC in that case.) but it has proven very 
workable in the common case.

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.

Or perhaps we could abandon using DHCP at all for a host/user 
identification system and use something else, like a real NAC system.  
I already mentioned that 802.1X isn't workable.  Beyond the so-called 
"oscilloscope problem" there is the security issue with users storing 
possibly valuable credentials on their systems so they don't have to 
enter it every time.  If you use a different non-valuable credential, 
then that's another thing for the user to keep track of (and so much 
for single-sign-on). Perhaps we could use a MAC-address based NAC 
system (aka MAC security or RADA: RADIUS Authenticated Device Access), 
but then we are back to tracking every MAC address in a central 
database, except without the possibility of easily capturing this MAC 
address in an automated fashion through a captive portal, at least not 
without extensive re-tooling.

> So why is it that you have chosen this model - what is the value that it 
> adds, and why is it that there is no better solution that involves less 
> work?

Part of it is associating a user's activities on the network with the 
traffic flows on the network for policy enforcement and 
accountability.  We have a need to support any kind of Ethernet or 
WiFi device a user may bring, and 802.1X support isn't available 
everywhere.  Ethernet and WiFi have a good enough identifier that is 
globally unique (unique enough in the practical sense), is always 
there, is easily obtainable from an uninitialized system, can be 
obtained in an automated fashion for the most common case, and never 
changes except in well known, uncommon situations: the MAC address.

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.  Having to re-tool this 
infrastructure to support IPv6 is a large cost and a barrier to IPv6 
adoption, whereas providing an option for existing networks to choose 
to continue to use these mechanisms that are compatible with their 
IPv4 infrastructure would aid in IPv6 adoption.  It's the same reason 
the IETF has done a lot of work on IPv6 tunneling and transition 
mechanisms and IPv4/IPv6 co-existence.