host-identifier with IPv6

[Frank Sweetser]

Glen R. J. Neff wrote:
> On Fri, 2009-02-27 at 13:15 -0500, Frank Sweetser wrote:
> 
>> I fail to see how simply making the numbers bigger should require any
>> additional complexity, just additional diskspace and memory.
> 
> It's not just making the numbers bigger.  It's going from four small
> value integers delimited by periods to potentially 32 digits of
> hexidecimal values.  If you get hexidecimal, that's great, but the vast
> majority of users and/or system administrators simply do not.  The
> potential for a typo and the complexity in memorizing these addresses is
> significantly greater.  My aim is to have it so no one buy the guy
> setting up the router or the DNS server should never need to plug-in an
> IP address - so that people don't need to think about it.

Ah, I see your point.

Well, in my environment, the majority of my userbase is sufficiently
non-technical that it doesn't matter.  The Pacific Ocean may be substantially
larger than the Atlantic, but if you throw on a swimsuit and try to swim
across either one the end result is going to be the same.

To deal with this, I already have a system in place where, once the MAC
address is captured (in the case of students, who have the least support and
the greatest churn, the capture part is 99% automated) everything else is
allocated and configured with no further user interaction.  Pick a hostname,
tell is what building you're in, and everything else - IP address allocation,
DNS forward/reverse/MX records, DHCP server client statement, RADIUS server
ACL for wireless, and even port security statements on secure ports - all get
configured completely automatically, requiring no further technical skills on
the part of the user, and no further intervention by any admins.

With DHCPv6, though, we would have to perform a configuration update - either
updating the database with the new DUID, or configuring the client back to the
old DUID - every time that the OS is reinstalled.  And for students doing
brute force troubleshooting or experimenting with OS, and for the hundreds of
lab machines that have to be imaged several times a year, that's a lot of
administrative work we don't have to do with our MAC based DHCPv4 setup.

>> Plug-n-play sounds great, except that in this case the "play" tends to end up
>> being "hide and seek" as the hapless admin (network or system, take your pick)
>> tries to go through IP/DUID/which host mappings looking for a misbehaving, or
>> just missing, host.
> 
>> With a pure DUID system, generated randomly at boot time, there's no longer
>> any consistent seed that can start the lookup chain required for a machine to
>> automatically configure itself.  This means that the only choice left is to
>> slowly, manually, and painstakingly pick the machine identity out by hand -
>> not something very nice to any of your administrators.
> 
> "Those who say it cannot be done should not interrupt those who are
> doing it."
>       -- Chinese Proverb

"A witty saying proves nothing." -- Voltaire

If you have some alternate means by which I can:

  - control what v6 IP address a given machine with a currently blank hard
drive will get
  - maintain the same address across different DHCP clients (PXE, WinPE, full
Windows)
  - maintain the same address across reformat and reinstall

then I would honestly love to hear it, as it would save me a lot of work in my
planned v6 rollout.  So far, though, all I've seen are other people on this
list who are in the same boat as I am, so the only option I can see is do as
David suggested and take my suggestions up to the protocol design level.

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