host-identifier with IPv6

Ted Lemon Ted.Lemon at nominum.com
Wed Mar 4 00:45:31 UTC 2009


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.

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

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

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.

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?




More information about the dhcp-users mailing list