host-identifier with IPv6

David Farmer farmer at umn.edu
Tue Mar 3 08:19:33 UTC 2009


On 3 Mar 2009 Frank Sweetser wrote:

> David W. Hankins wrote:
> > An alternative interim solution in that area would be to use the
> > client's link local address as it was perceived by the relay agent
> > (or by the server directly).  Relays and servers already record this
> > so they know where to direct the replies.
> 
> There's obviously some subtlety I'm missing, because that's about what
> I thought I was proposing =)  But anyway, yes, that certainly sounds
> like an acceptable solution to me.
> 
> It sounds like one minor downside would be that, at least at first,
> this workaround would be specific to the ISC relay agent, so it
> wouldn't be available in existing router based relay agents, requiring
> that a server be installed on each IPv6 VLAN.  Our current core
> routers don't have a v6 relay agent, though, so not only would we
> already have to do that, but we'd also be in a good position to
> request that vendor implement the same interim solution that the ISC
> one does.
>
> Even for people who already have v6 relay agents they wouldn't be able
> to use this scheme with, it would still be far, far less work than
> attempting to manage any kind of client based solution.
 
Actually all relay agents have to include the IPv6 link local address in the 
relayed request so when the DHCP Server returns the response to the relay 
agent, it can know the client to return to response to.

The following is my IPv6 link local address, fe80::208:74ff:fe24:ac0a, my 
mac address is 0008:7424:ac0a, this is the simple transformation defined in 
RFC 2464.  Therefore a DHCP server can be assured to get the EUI-64 
version of the MAC address.  Transforming that back to a 48-bit MAC and 
allowing operations in the DHCP server based on the MAC address should 
be possible without modification of DHCPv6 clients or DHCPv6 relay agents.

I would like to see MAC address as a standard field, but we really need the 
above work-around implemented ASAP.  This would facilitate IPv6 
deployment without completely reworking current business and network 
management processes.  We need to eliminate as many barriers to the 
deployment of IPv6 as quick as we can.  Requiring network and system 
admins to change from managing things based on MAC address and going 
to DUID will only slow adoption of IPv6.  Even worse, you actually need to 
use both MAC, for IPv4, and DUID, for IPv6, this is crazy.  Also, waiting for 
all clients to implement the MAC address as a standard field will take to long.

Another feature request I have related to the DHCPv6 using the MAC 
address; I would like a DHCPv6 server that can force a client to use its EUI-
64 address rather than leaving it up to the client through SLAAC to use its 
EUI-64 or a privacy address. 

Why?  You might ask.  Well on our campus we have tools to determine 
where a host on our network is based on IPv4 address or MAC address.  We 
will eventually add IPv6 address to these tools.  But if we can force a host to 
use a EUI-64 IPv6 address, in the short run, then we can find any IPv6 host 
without actually modifying our current tools.  You simply translate the EUI-64 
portion of the IPv6 address to a MAC address an look to up that way.

Like I said Longer term, I want to support IPv6 privacy addresses and track 
IPv6 addresses in our network management database just like we do IPv4, 
but that will all take time.  Allowing the management short cuts I describe 
above, in the short run should allow deployment of IPv6 without losing at 
least basic MAC address based management controls.  

Finally I'll repeat, we need solution for deploying IPv6 without completely 
reworking current network management processes and tools that are based 
on assumptions from the IPv4 world.  Yes, this means IPv4 broken 
assumptions will be moved into IPv6, but that what is going to happen.  Most 
people are looking to implement dual stack v4 and v6, there is no way that 
will happen if you have to implement twice the network management, twice 
the business processes, twice the assumptions on how every thing works.  In 
the short-run we need solutions that easily add IPv6 on to our IPv4 networks. 



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================




More information about the dhcp-users mailing list