host-identifier with IPv6

[Frank Sweetser]

Ted Lemon wrote:
> On Mar 3, 2009, at 3:18 AM, Simon Hobson wrote:
>> Sorry, but this comes across as "we don't care if the protocol
>> doesn't work for some important real world setups - that's your fault
>> for having the audacity to work around practical issues".
> 
> I think this is really the heart of this discussion.   Ultimately, you  
> feel that the wrong decision was made.   So I'm trying to offer  
> constructive suggestions for how to deal with things as they are, and  
> you're telling me they shouldn't be that way.   This is the wrong time  
> for that.   You were here when the IETF was designing this protocol.    
> I think I was still supporting the ISC server when I wrote the section  
> of the draft you're complaining about.   Maybe I should have tried  
> specifically to include you, but you were not intentionally left out.

By the way, I just wanted to say that I do appreciate your answering as many
emails as you have in this long thread.  Quite a few of them (mine included)
have no doubt come across as somewhat confrontational, due to frustration at
having our workflows broken, and it's good of you to at least try to offer
what advice you have.

> The IETF is an open organization.   Not only do we welcome the  
> participation of network operators, but there are entire working  
> groups dedicated to addressing their concerns, and they are as  
> important as, if not more important than, the protocol extension  
> working groups.   For instance, at the upcoming IETF in San Francisco,  
> DNSOP (the DNS operations working group) is meeting, but DNSEXT (the  
> DNS protocol working group) is not.   Furthermore, the reason I  
> continue to read this mailing list, despite the fact that I no longer  
> work for the ISC nor support ISC products, is that I think it's  
> important in my role as an IETF protocol/operations wonk.
> 
> So now you have the protocol you have.   This protocol is widely  
> implemented - it's included in Vista, ISC has an implementation, Cisco  
> has several implementations, Nominum has an implementation, I have a  
> client I've written.   And I've explained to you how to shoehorn your  
> needs into the protocol you have.   But you keep coming back and  
> telling me that the spec is wrong.  Worse, you're proposing a change  
> that would create a huge interoperability problem.
> 
> So I'm asking you to take a deep breath, stop feeling like you were  
> left out of this process, and deal with the situation as it is  
> today.   I've made some suggestions for how to deal with this that I'm  
> pretty sure will work in practice.   Software is available today that  
> supports what I've suggested.   I think it will work.   If it won't  
> work, fine, come back and let us know.   I'm not sure what we'll do in  
> that case, but at least we won't be speculating about something that  
> *might* be a problem.

I'm certainly not going to try to claim that the change was "wrong", merely
that for those of us with workflows built around using the MAC address as the
primary identifier, the change ranges from inconvenient to a full IPv6
show-stopper.  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.

> Speaking as an author of a client, I've found this conversation  
> instructive, and I will certainly be making code changes to account  
> for what's been discussed here.   I don't know if other client  
> implementors are paying attention to this discussion (I'm sure the ISC  
> guys are!), but hopefully all of this talk hasn't been in vain.   But  
> I don't think we're making progress, so I'm going to propose that we  
> table it now (although if you want to respond with some incisive  
> rejoinders, I won't take it the wrong way).

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.

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.

Does that sound like a reasonable idea to you?  If so, I'd be more than happy
to work on it, in whatever the appropriate forum is.

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