host-identifier with IPv6

[Ted Lemon]

On Mar 3, 2009, at 8:13 PM, Frank Bulk wrote:
> You've just pointed one of the problems of the standards development  
> process
> -- standards are written that don't match operational specifics, and  
> so
> those who actually *do* the work are trying to force-fit the tools  
> they have
> to solve real needs.

One of the motivating factors behind the current DUID language was  
that we do in fact have a serious problem with Mac addresses not being  
unique to machines.   As the maintainer of the ISC server, and as one  
of the authors of the Nominum server, we have encountered real  
customers for whom this need was very real.

And again, we are aware of your problem - the need to tie a unique  
identifier to a specific machine.   The DUID does solve that  
problem.   Depending on your present circumstances, using the DUID may  
require you to write some additional glue code in your business logic,  
but you can make it work.   The debate here is not over whether or not  
you can make it work, but whether you should have to.

> Rather than trying to defend the RFCs (or point to the status quo) and
> minimize the processes that network admins use with IPv4 today,  
> perhaps Ted
> can use his standards process and and software development knowledge  
> to
> write a draft that addresses the problems that network admins in  
> this forum
> are facing.  I'm sure those participating in this thread would be  
> glad to
> add their comments.

I'm really not trying to defend the RFCs.   I understand the  
objections that have been raised.   But what we as a vendor have done  
to address these concerns is to architect a system that allows you to  
do the things you need to do easily.  And as a protocol designer, I  
tried to write this portion of the spec (I didn't write the whole  
spec, BTW - not trying to claim credit for the good parts!) with your  
needs in mind.   And I believe that what I wrote can be used to  
address your needs.

The problem with making a change to the protocol, and the reason why  
I'm arguing against it, is that it won't get you what you want.   The  
way the process works is that I write a draft and submit it to the  
working group, and we debate it.   If it's adopted, we review it and  
fix it until we think it's a good spec, and then we go to working  
group last call.   It's unusual for a spec to go from first  
presentation to WGLC in less than a year.   Not impossible; just  
unusual.

So let's be optimistic and say that in January of 2010, we have an  
RFC.   Windows 7 has already shipped.   So the first version of  
Windows that implements this RFC will be the one following Windows  
7.   Possibly some new devices that come out in 2010 will implement  
the RFC, but possibly they won't, because it's not in the base spec,  
and it's not required for the protocol to work.

So realistically, it's going to be quite a few years before you can  
*assume* that even a majority of devices will send their Mac address,  
much less a substantial majority.   I would guess maybe in 2020, you  
will be able to safely assume that devices send their Mac address, and  
then only *if* vendors decide to implement it, which is not  
guaranteed.   The IETF does not have the power to force anyone to do  
anything.

I should say that this estimate is based on my experience with  
DHCPv4.   Generally speaking, unless some vendor really really needs a  
particular extension, it takes a very long time before they implement  
it.

So in the meantime, unless you are able to put off adopting IPv6 until  
2020, you are going to have to support devices that do not implement  
this extension.   Practically speaking, then, you're going to have to  
implement the solution that you are trying to avoid implementing.    
This means that you are now pushing a protocol extension to solve a  
problem that doesn't need solving.

This is why I don't think there's any point in doing this protocol  
extension.   It's not just because I'm being obstinate, or circling  
the wagons.   If I'd thought of your use case back when I was writing  
this section of the draft, I would have addressed it.   IIRC there  
wasn't even any serious debate over the DUID section of the spec.