host-identifier with IPv6

[Frank Sweetser]

David Farmer wrote:
> 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.

Ah, thank you - I had missed that the EUI-64 address was embedded in the 
packet.  It's *much* clearer now, and sounds like an excellent workaround to me.

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

[...]

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

I can't stress how much I agree with David here.  Every difference in workflow 
and administrative procedure necessitated by switching to IPv6 is another high 
cost, low benefit barrier to entry, especially in the chronically understaffed 
world of educational IT departments.

-- 
Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
     GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC