Slashdot Mirror
One Less Reason to Adopt IPv6?
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."
But puppies don't have a "gargantuan address space" or end-to-end security. Trust me, puppies leak all the time.
I don't have a microwave. I do, however, have a clock that occasionally cooks shit.
DHCP in an IPV6 world is a buggy whip. It's not necessary. An IPV6 device can discover its own IP address and gateway router and subnet mask (if necessary) without the help of any servers because it's built into the protocol stack.
DHCP doesn't give a network admin any more control over a network, either. That's just a silly statement. How does having a server doling out IP addresses make it any easier to control a network? It's not a like a device *must* be set to use DHCP. It's not difficult to figure out what IP address ranges a DHCP server is not doling out and use that, even on IPV4.
My blog
IPv6 Autoconfiguration is close but no cigar in a couple of signignificant ways:
/64 addresses for hosts, the address size gain, while large, isn't anywhere near the original promise, and encoding the MAC address into a globally-visable IP address does release information about hosts which was formerly private (NIC vendor, for one, as well as the more theoretical complaint about the layering violation).
1) DNS server information wasn't baked in from the beginning (there are now some drafts to fix this, but I haven't yet seen the working code) - all this time, and we managed to recreate BootP...
2) Because autoconfiguration uses
3) Just try it with VMWare or other virtualization software. Ouch. There's a whole lot of borked there.
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?
All that said, in a dual-stack environment it works reasonably well: but it doesn't honestly look like anyone gave much thought to a time when IPv4 wouldn't be present on the LAN or on the hosts...
Need Geek Rock? Try The Franchise!
Autoconfig is nice for home networks and such. For the corporate world, DHCPv6 is far more useful.
Most people think of DHCP as just giving an IP address, mask, gateway, and DNS. DHCP can do SO much more. We're talking HUNDREDS of pieces of data, including custom strings. Want to tell your IP phone where the call manager is? DHCP. Want to tell your Netware clients where the nearest replica server is? DHCP. Still using WINS for some strange reason? DHCP.
Autoconfig is nice for the lazy admin, but for folks who want to keep track of where their IPs are going and want to deploy additional features, DHCP is the better option.
There is no reasonable defense against an idiot with an agenda
:wq
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.
Autoconfig is a nice default for something that "just works" without much need for an admin to plan out the network, and DHCP is great for tighter control where needed. What's wrong with having both options available?
init 11 - for when you need that edge.
IPv6 isn't that good because DHCP has been updated to support IPv6?
O.O *blink blink* O.O
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).
IPv6 may offer a range of new features over IPv4, but realistically, people will move to IPv6 for one of two reasons
1. They have run out of IP addresses ( remember the 10.0.0.0 private network is pretty big! )
2. Everyone else is doing it.
Option 1 is only really going to be a problem for the really big firms, and they will be really careful. All those Corporate apps need retesting with the new IP addresses, and that is a non trivial exercise ( think Y2K all over again!, except you could do it piecemeal ). It's a hard sell to the business : Mr PHB, we'd like to spend a large amount of money retesting all the applications in Globocorp to use a new IP numbering scheme. Nope, you won't get any business benefit.
ISPs may force people of IPv6 at some point, but that's only been an issue in South Korea so far. Everyone else still has enough IP addresses right now.
And until we get a critical mass of people going for Option 1, option 2 is a no go.
Printer Friendly:
http://www.networkworld.com/cgi-bin/mailto/x.cgi?pagetosend=/export/home/httpd/htdocs/news/2007/091107-dhcpv6.html
[Fuck Beta]
o0t!
IPv6 33% Pointless
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..."
Thank you. I had been wondering how to get DNS to Just Work [TM] over an autoconfigured v6 interface for a while. I had been falling back to using the dhclient-enter-hooks file to stop a rewrite of resolv.conf on v4 lease acceptance and manually applying my nameservers' v6 addresses. This is the problem with any "new" technology that replaces something ubiquitous; the accepted ways of doing things sometimes no longer apply. It doesn't help that OpenBSD's dhclient dropped support for many options that I successfully used with the old ISC client in dhclient.conf. Like you, I will be glad to see the back of DHCP.
/home). It might even be a problem with ipfw2. More testing needed before I start pointing fingers in a PR just in case I've screwed my configuration up in some brain-dead manner.
I'll be trying it on FreeBSD and, according to the Wiki and a few other links the search "FreeBSD mDNS" returned, it looks like it is going to work. This is the final piece of the puzzle for me, apart from a suspected bug that fragments UDP NFS packets [1] when used over v6 - which is nothing to do with the v6 specification at all, just FBSD's implementation of it in either KAME or NFS.
[1] Lots of "kernel: ipfw: pullup failed" messages on the server after a while [2] of working fine. The client hangs dead once this starts (NFS mounted
[2] FSVO "a while".
Resistance is futile. Reactance buggers it up.
I'm deploying an IPv6 VPN at my company, and I've avoided the use of DHCPv6, as they have avoided DHCPv4 to make it less easy for people to attach to our networks. By using stateless autoconfig and not having DHCPv6, I can still restrict use of company nameservers to systems with our loadsets that have the DNS setup statically defined.
Life is irony, and nothing ever goes as planned.
Look, if we don't switch to IPv6 one of these days, then in 100 years from now an angry IT network sys admin is going to go insane with the mess we left him and invent a time machine and come back to blow us all up.
It is going to have to happen and the longer we put it off the more expensive it is going to get over time to replace all the equipment. Yes, NAT works but its like trying to keep an old system road infrastructure in place that will be more costly to maintain at a certain point than to replace.
"I am the king of the Romans, and am superior to rules of grammar!"
-Sigismund, Holy Roman Emperor (1368-1437)
a gargantuan address space,
Methinks one reason IPv6 hasn't been adopted is because those who have chunks of the IPv4 space are quite happy having what is essentially an artificially precious resource.
Most people think the IP address space is "nearly full", but a handful of companies are sitting on prime real estate (nevermind there is a huge amount of "reserved" space which is not in use.) For example, why do the following companies have entire class A's to themselves?
Please help metamoderate.
> Why are we waiting until it's a crisis to deal with it?
:-)
Because that's just human nature -- we're all procrastinators -- some of us admit it -- others are putting that admission off.
History is replete with situations where timely action would have saved piles of money and/or lives -- have we ever acted at the right time? No -- we wait until something like http://www.historyplace.com/worldwar2/timeline/dday.htm is necessary.
So I think we can all safely predict that it will be a crisis before we do anything about it.
And remember -- never put off until tomorrow that which can be put off until the day after.
Ian Ameline
It all seems a little premature to me. Both sides have benefits and pains.
But IPv6 (while i remember it being chosen as "the standard" we'll go with moving forward back in 1994 or 5?) is seriously at a point where IPv4 was when the internet was nothing more than a research network used by universities.
DHCPv6 has a number of advantages for a corporation, where it exists in the network and where it doesn't will still remain the same.
Cisco IOS's many integrations into dhcp v6 are interesting, but so much of it is way too idealistic at this point. IMHO, autoconfig will be pushed out to those routers for home networks where people dont want to know squat about their network and dhcp will probably be used in corporations for the extra functionality it gives.
Now, claiming dhcpv6 gives you control over your network space (even given cisco's embedded features) any more than dhcpv4 did for ipv4 is perhaps a little bit of a stretch. What i would say about dhcp vs autoconfig is that dhcp allows you to pass alot more info to your clients that does autoconfig. Using it for anything more than passing info to your clients and passing out ip addresses is just asking for a management nightmare at this point in time though.
I've started my open DHCPv6 implementation over 4 years ago. Once in a while, someone reports a bug or says that it works fine, so people are using it. The rate of adoption is not that great, but I've got feedback from 28 countries. Anyway, that's hardy a news. Basic DHCPv6 spec has been published in 2003. By the way: there's a small misunderstanding. Formally, the whole autoconf process in IPv6 is split into stateless and stateful (DHCPv6) parts.
Why are we waiting until it's a crisis to deal with it?
Because until it's a crisis, you can't get the money to upgrade. If current addressing is going to work for another week, then it costs nothing to stick with it. Call me when the crisis is imminent.
Those are my principles. If you don't like them I have others. -Groucho Marx
Because people learned the WRONG lesson from y2k.
Nothing happened.
So the accepted wisdom became that the whole thing was just an alarmist fiasco that chewed up a bunch of money unnecessarily. They don't realize that y2k was no problem precisely because of all the noise. A LOT of people did a lot of planning and a lot of work, and that all paid off in how few problems there really were.
But the common man, and unfortunately the common leaders don't understand that. So now y2k was a so-called crisis, wasn't a problem, and we can approach our next so-called crisis without the extensive preparation we "wasted" on y2k. Oh boy!
The living have better things to do than to continue hating the dead.
I'm not sure if autoconf and IPv6 addresses in general have too much or too little magic. Admittedly, these are in part Linux implementation bugs, but the kitchen sink nature of v6 sure isn't helping. If I can't reach anything by v6, I don't really care that I can secure my connection to nowhere with crypto.
On the too much magic side, I announced 5001::/64 on my LAN at home as a test. Yet, when I try to go to a v6 enabled site, firefox tries to use v6 even though 5001::0/64 in no way impleis that I can reach 2001:: from here.
On the too little magic side, some sites have more than one router (It's called a private network, some people don't care to splatter their private business all over the world). I tried setting that up with both overlapping and non-overlapping prefixes. Neither worked at all. The machines bounced from one to another so that they didn't even keep a consistant address. Good thing I had v4 so I could fix it without hopping from machine to machine. Possible good behaviours might have been:
The success or failure of v6 will be in client support. Nobody is going to accept a v6 only web server if clients can't reach it. Many of those clients have v4 only ISPs with dynamic IPs. They will not want their entire lan to renumber every time they get a new dynamic assignment. So, they will want a non-routable prefix for local to local traffic. Too bad the silly machines will try to use that for non-local traffic!
Admins are often busy people. They don't want to devote their professional life to a v6 rollout, especially when practically nothing out there is reachable by v6 yet. If it's not dead simple it won't happen at all. I tried dead simple and as a result some sites became unreachable. I killed it again and they came back (falling back to their v4 addresses).
Link local addresses don't seem to work AT ALL. I see the route but I get EINVAL if I try to ping.
I suppose my next attempt will be to rip all the autoconfig stuff out of the kernel and implement a userspace daemon. It doesn't really belong in the kernel anyway. That's what initramfs is for.
In general, this business of having to add one of 6, -6, -A inet6 or other junk to the command line or appending a 6 to the name of the utility has got to go. It's one thing to need a software update to handle v6, I can understand that older software might not even know v6 exists, but the v6 version has no excuse for not knowing v4 exists. ping6 192.168.2.1: unknown host.
All of this tells me that v6 still has the status of a toy to play around with, not a supported standard ready for worldwide use. That's fine as far as it goes, but it's not exactly making people anxious to get on with the upgrade.
It's been over a decade now. Let's quit pretending it's just inertia and try to address the real adoption barriers while there are still v4 addresses left.
My advice:
Just forget about scope. Prefix lengths are more than adequate for making routing decisions.
Quit appending a 6 to everything (this is not marketing!). That includes structs and function calls in the library. For the most part, a v6 address as ASCII is distinguishable from v4. Likewise, in binary 4 octets followed by nulls or nulls followed by 4 octets is a v4 address. An app that won't run when the size of sockaddr_in changes was wrong to begin with. If you must, make -DV4ONLY use the old v4 only structs etc so broken source will compile and run. Done right, a number of old but well written programs could support v6 just by recompiling.
Allow multiple router announcements and behave gracefully. Use the prefix that best matches the destination.
Simpler handling of 6to4 and 4to6 translations. With so many people using APs and other routers for a broadband connection now, automatic en/de-capsulation in IPv4 can go a long way with very little configuration and a few simple rules.
What's up with the OSI protocols? NIH I guess. Lets all re-invent the wheel instead.
That's not the problem that I saw, 15 or 20 years back, when I was involved in a number of OSI implementation projects. We were in fact looking at several competing protocols, with the idea of implementing them all and developing test suites to determine their good and bad points.
But something interesting happened on all the OSI projects: We'd need the specs, of course, and you couldn't download them. You had to order the hard copy. This meant going through the usual corporate red tape for ordering stuff. You'd fill out a requirement doc, get it ok'd. You'd fill out a purchase req, figure out whose signatures you needed, and have the secretaries work on collecting the signatures. You'd mail off the order, and wait.
Meanwhile, since there was a lot of waiting to do, we'd work on the IP version. We'd download the RFCs, spend an hour or so reading and a few hourse discussing, and then we'd sit down at a terminal and start coding. We'd be at the testing stage within a day, and have usable results in a few days. By the time the OSI specs showed up on our desks, we'd have had the IP version up and running for weeks. While we were reading the OSI specs (always much larger than the IP specs), we'd have users getting experience with the IP version, and sending in bug reports and/or change/feature requests. By the time we finally got an OSI version to the alpha stage, the IP version would be ready to send to the first customers.
If the OSI gang had had the sense to make their docs available free on the Internet, they might not have lost so badly. But by trying to make the specs a profit center, and by using a different competing delivery network (the postal system), they put a major time blockade in the way of developers. So they lost out big time to IP.
I've never been all that convinced that IP was any better than OSI, especially now with the big migration to IPv6 peering over the horizon. But I never really got a good chance to test them and compare their capabilities. The OSI version of our code was always so far behind the IP version that the whole issue was moot. IP won every race, because OSI was so slow out of the starting box. And that was because we developers couldn't get out hands on the specs in a timely manner.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Because M$ does not currently support DHCP static lease address assignment in their IPv6 implementation. Many large enterprises like to have their primary servers at a certain known address, e.g. "10.1.2.3" for proxy "10.1.2.5" fopr file server, etc. Sorry no can do in a windoze IPv6 environment. MS isn't the only culprit. Don't get me started on the debacle they called "site-local". Every place says its deprecated but precious few will inform you what to use as a replacement and best practice of that use.
Much as I would like to use it, I am afraid that until a DHCP IPv6 environment does everything (correctly) a DHCPv4 environment does on both the client and server side, it wont make much headway outside trivial or lab environments.
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
"Why are we waiting until it's a crisis to deal with it?"
/. fix.
Ironically, the longer you wait to deal with it, the cheaper it may be!
There are some obvious reasons why waiting longer makes it cost more, but there are quite a few subtle reasons why it's cheaper to wait. For example:
1) If your current hardware is not IPv6 capable and you buy new IPv6-capable hardware now, it may reach end-of-life before you need the IPv6 capability.
2) IPv6 routes take more memory than IPv4 routes. The longer you wait, the cheaper it will be to add this memory. (Note that we're not just talking cheap main memory, we're talking expensive CAM and custom chip memory.)
3) Research and development are constantly progressing. The longer you wait, the better researched the solution you ultimately deploy may be. (To a limit, of course. You also lose the chance to gain experience.)
On balance, I think we're progressing at a sensible pace, perhaps a bit slower than perfect. People are continuing to do test deployments to see how IPv6 will work and make sure they'll be able to implement it for real when the demand comes. But they're not wasting money replacing working hardware or increasing network instability on the real, live Internet we all depend on for our daily (hourly? half-hourly?)
No, IPv4 does not support anycast except as a userspace layer on top of multicast, which - in the case of IPv4 - is usually disabled and is not even implemented as standard on all kernels. There is no kernelspace anycasting in IPv4 and there are no anycast-aware applications in IPv4 that I am aware of. Multicast, yes, but even that is grossly underused and underutilized. Network programmers and ISPs should feel utterly ashamed with themselves at the pathetic, tardy and haphazard use of one of the most elegant networking tools available to software engineers.
You are also incorrect about the hardcoding. Anycasting doesn't require a hardcoded address for the service. The anycast request is sent on the anycast broadcast channel and is labeled. If the device recognizes the label and no other response has been given, the device responds.
You are also incorrect about the security risk. Multicasts (and therefore anycasts) have a scope. So long as anything outside of your local scope exceeds the anycast scope, the transmissing can never reach a device outside of the boundary you have defined.
Let us say you have a hundred IP phones, all in factory default state. You pneous DHCP hits is going to more than inconvenience most servers. You'd damn-near melt them.
Of course, this isn't limited to DHCP. Traditional PXE is unicast, hard-coded and doesn't scale to more than a dozen or so nodes on a LAN for truly simultaneous connections. Anycast PXE scales as far as you like, provided you have the servers to support the clients.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I have an insightful response to this. I'll type it up tomorrow.
So a big reason why OSI lost is because it wasn't a standard, it was a smorgasbord of of implementation options.
Think about that for a second and I think you'll find it as funny as I did. If the Internet existed for the docs to be available on, what then is the point of developing OSI? (Yes, I agree that the cost of specifications is an issue, and that the ISO charged way too much for OSI specs.)