On Wed, Oct 15, 2008 at 07:44:33PM +0300, Pekka Savola wrote: > For example, we don't use any DHCP in server-only LANs. (In 'office' LANs > where laptops, desktops, etc. connect it is used however.) I'm pretty sure > this is a very common way to manage servers, though I admit that usign DHCP > is likely similarly very common.
I appreciate this, but it is not universal, partially due to the varying contexts of 'server'. I know of administrators who are charged with the responsibility of presiding over networks that contain hundreds of Windows servers. These, they configure with DHCP(v4) and DDNS, offering 3-6 month lease times. This automation means the network administrators do not have to be involved for every construction and deconstruction of a Windows server within their network. I would like to intimate that although their HR can put a price tag on this advantage, reduced helpdesk staff, the DHCP and DNS admins would not be so ready to suggest you can place a price on this advantage. I think it is fair and accurate to say that Unix servers are not classically configured using DHCPv4, but there are exceptions in large scale environments (some Beowulfs spring to mind, where often the nodes are PXE booted). On this subject... I firmly believe that automation would be a benefit, if an often unwelcome one, among even small scale unix server deployments, and that unix DHCPv4 client implementations have chosen, unnecessarily, to optimize for laptop environments...requiring to hear from a DHCP server before using a previously recorded valid lease. An operation that is not required per RFC2131, but is optimal in laptop/nomad user contexts. This has created a stigma that DHCP in general is inappropriate for Unix server use, on the basis that the DHCP server must be operational for any other server to run. This is an unfortunate fallacy; it is true of certain DHCPv4 software implementations (ISC's), it is false of the protocols (both DHCPv4 and DHCPv6). When speaking of the "IETF DHCP" and not the "ISC DHCP", it is true, I believe, to say that DHCP automation presents no greater a risk of "dynamic failure" than the use of ethernet link speed and duplex negotiation. No greater downside from involving extra moving parts. DHCPv6 is even better positioned than DHCPv4 to provide automation even in small scale server deployments that does not carry DHCPv4's stigma of unnecessary circular dependency, due to the simplicity and clear definition of the Confirm message. I believe ISC's DHCPv6 client is usable for this purpose today, and that all other DHCPv6 clients are similarly capable (so long as they follow RFC3315). But it is still not universal, as you must also iron out the trust model of accepting granted configuration; some systems are too critical to risk spoof attacks (others are just as critical but reside in a private network), some environments are too weird to provide adequate filtration. Manually configuring a key to perform dynamic configuration diminishes the value of automation. I'm sure even after (if) we iron this out, it will remain non- universal. > You seem to underestimate the usefulness of manual configuration, This is probably true. I also fail to perceive any aesthetic value to manual configuration; to "having all the bits aligned beautifully in the config file." I'm aware these are motivations. > especially when coupled with other configuration management tools that can > help automate it for you. But this is a contradiction; tools that automate manaul configuration are not practices that can be described as 'manual'. It is automated, it is just reusing the manual interface. So, you appear to be arguing over mechanism. "Some other automation mechanisms suck less for some purposes." This, I agree freely; it's not that DHCP(v4/v6) doesn't suck, it's just that they suck less than some alternatives. The extent through which the IETF has progressed the discovery of new (or extended) mechanisms that suck less than their predecessors has been stunted by IPv6. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
pgpubXbe6C3TD.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
