host-identifier with IPv6

[Simon Hobson]

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.  Vendors are stuck somewhere in-between -- meeting the
>real (revenue-generating) needs of their customers while stating that they
>support standards (which may fall short of fully serving their customers). 
>
>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.

This is already covered - I think we are all guilty of not taking 
part in the standards setting process, probably for a variety of 
reasons. Myself, a feeling that as a very small user, a (probably 
incorrect) sense that it's not for me to inflict my ideas on the rest 
of the world !

One of the things I've learned in the last few years (in a completely 
different setting) is that to influence things, you have to get in 
there and make comments while ideas are being tossed around. If you 
wait until there's a proposal and comments are asked for, then it's 
often too late.

The answer to the "standards that don't match operational 
requirements" problem is for people with the operational requirements 
to get in there and make their requirements known. Only if you do 
that and the standard still turns out unworkable can you complain.


Ted Lemon wrote:

>>In a v4 context, we only allow booting of known clients.
>
>So then your problem is solved - since both mac addresses are linked 
>to the same machine, whichever one comes in in the DUID will 
>identify the machine on which the client is running.

Except for one minor, teeny, little detail - there is no GUARANTEE 
that a GUID will contain a MAC address. There is already one GUID 
spec that does NOT include a MAC address, and the standard 
specifically allows for other GUIDs to be defined/used.



OK, there is one suggestion that came up "a few" messages ago - and 
that is for the server or relay agent to capture the MAC from the 
clients packet on the wire. Without breaking existing setups, would 
it be possible for the relay agent or server to capture the clients 
MAC off the wire and add a hardware address option to the packet - 
like option-82 in the DHCP4 world ?


-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.