One Less Reason to Adopt IPv6? 174
alphadogg writes "For a decade, IPv6 proponents have pushed this upgrade to the Internet's main communications protocol because of its three primary benefits: a gargantuan address space, end-to-end security, and easier network administration through automatic device configuration. Now it turns out that one of these IPv6 benefits — autoconfiguration — may not be such a boon for corporate network managers. A growing number of IPv6 experts say that corporations probably will skip autoconfiguration and instead stick with DHCP, which has been updated to support IPv6."
DHCP plain sucks (Score:1, Informative)
Not just corporate (Score:5, Informative)
There have been a number of suggestions to solve it that problem, of course, ranging from adding an extra field for DNS servers in the autoconfig ICMP messages to using well-known unicast addresses for the closest recursive DNS server to using a dedicated protocol just to discover DNS servers. The first and last of those have (rightfully, IMNSHO) been shot down because then one might "just as well" use DHCP, which exists and has a solution ready for the issue at hand. I cannot remember why the unicast suggestions have been rejected, though, and it has been disturbing me, because I think it is the best solution. I really just cannot see the drawbacks to it. I guess there might have been some talk about lack of security in that model, but that's a problem with DNS in general, though. That's why DNSSEC was invented.
Last I looked, the consensus seems to be to use autoconfig for address generation, and then request network information (such as DNS servers) from a link-local DHCPv6 server. When everything comes around, I think that's a rather good solution. Clients can still get whatever non-occupied address they want (which means the privacy extensions will also continue to work), and still get the information they find relevant, and a DHCPv6 server should be easy to implement on a network of any scale.
Re:DHCP in an IPV6 world (Score:5, Informative)
IPv6 Autoconf resembles bootP or inverse-arp more than it does DHCP. Also, DHCP has steadily developed a bunch of knobs over the years so that (for instance) IP phones can be told about which TFTP server to use - that sort of functionality doesn't exist in v6 autoconf today. Not to say that it never will, but v6 autoconf doesn't currently have anywhere near the capabilities that v4 DHCP does.
Re:Missing DNS (Score:5, Informative)
Eh, what?
As far as I could tell, as soon as I started radvd on my gateway all my xen guests autoconfigured their global v6 address. Perhaps you have a VMWare specific issue?
"4) Obviously you wouldn't want to use it for a true server, becuase who wants their server IP to change when a NIC burns out?"
Obviously you dont have a server-hardware ip address to use for a true server service. You dedicate an IP address to the actual service so you can move it around freely decoupled from the hardware and any other services on the box. (And to tie back to your earlier point; if you're virtualizing, there's no connection between the hardware and the MAC address anyway).
When you have a bazillion ip addresses it's not like you have to save them for a rainy day.
Re:Why did everyone completely ignore ISO? (Score:2, Informative)
I guess it boils down to: because the full ISO stack never worked.
First off, it was never "finished", insofar as many features available in other things were/are not available in OSI.... Given the level of "optional" features of OSI, in practice, full systems never did manage to communicate with each other. Given the complexity of the standards, building software, and debugging things, was very, very hard.
I am more then willing to grant that some very specific bits coming out of the OSI process were good, and are still used. Some of x500. Some of WAN routing protocols. Some of a few low level WAN media stuff. Some of ATM. Etc.
The problem - and this is a lesson that the IPv6 people know - is that "actually works" was never a specific requirement of the OSI process. And with the "Internet/RFC" process, "actually works" is about the only firm technical requirement (some legal patent ones, as well).
Re:DHCP in an IPV6 world (Score:4, Informative)
Re:DHCP in an IPV6 world (Score:5, Informative)
DHCP combined with modern network infrastructure allows network administrators complete control over all addressing issues in the network - including preventing non-DHCP hosts from participating in the network (called DHCP snooping) and location-based services ("DHCP option 82"). DHCP is so much more than just a kludge to get an IP address to the host. Scalability of DHCP allows network administrators to append information such as DNS, NTP, TFTP (for IP Telephony/TV) server information and so much more - default gateway, static routes just to name few. All this is pretty much lacking from IPv6 autoconfiguration.
That's why we tend to like DHCP
Marko
CCIE #18427
Re:Um,... it has to be said. (Score:5, Informative)
http://www.networkworld.com/cgi-bin/mailto/x.cgi?pagetosend=/export/home/httpd/htdocs/news/2007/091107-dhcpv6.html [networkworld.com]
Choosing a story title... (Score:5, Informative)
One Less Reason to Adopt IPv6
IPv6 Address Assignment Choices
Some May Forgo IPv6 Autoconf. for DHCP
IPv6 Autoconf. Vs DHCPv6
NetworkWorld chic: Well, I like "33% Pointless" the best, but my editor struck it down. The informative ones are too boring. I'll get more page views with "One Less Reason..."
Re:DHCP in an IPV6 world (Score:5, Informative)
Re:wasn't going to use it anyway..... (Score:5, Informative)
IPv6 Anycast returns the nearest server that supports the capability you want. True, you wouldn't use the router advertisement protocol, but there are major advantages to having lightweight protocols that can be added to as extra needs develop, as opposed to having one monolithic protocol that requires excessive space on the network and heavyweight processes to churn over.
4 years and counting (Score:2, Informative)
Re:address space (Score:3, Informative)
Re:DHCP in an IPV6 world (Score:4, Informative)
Re:DHCP in an IPV6 world (Score:5, Informative)
About once a year I investigate the current state of ipv6 support, and every time so far I have found every major operating system (including linux-based ones) to be inadequate to the task of deploying ipv6. The software support is just not there, on both the system and application levels. Sure, I can configure ipv6 interfaces on hosts and even have some of them set up tunnels and talk to each other, but it is entirely impossible for me to configure a non-trivial network without ipv4 support on every host and still expect it to work, so there's no damned point.
NAT is the solution to the address space problem. Get used to it, because ipv6 has spent the last five years failing to become a solution. When we finally run out of ipv4 addresses, we aren't going to switch to ipv6, we're going to switch to using NAT at the ISPs. You won't get an internet-routeable address for anything other than a server, after that happens - regular DSL lines will be allocated an address from one of the private ranges and NATted onto a smaller pool of routeable addresses as they leave the ISPs network.
It's going to come down to a choice between a technology that has spent years going nowhere and a technology that has spent years being used as the solution to the problem. I know which way the ISPs are all going to jump.