Why some of us are IPv6 holdouts (Was: /8 end user assignment?)
--On August 5, 2005 11:13:13 AM +0200 Iljitsch van Beijnum <iljitsch@muada.com> wrote:
Is there any particular reason why a service over IPv6 couldn't be load balanced by putting a good number of AAAA records in the DNS? Since most IPv6-capable browsers have decent support for trying multiple addresses, the problem of having a server be unavailable but still be in the DNS wouldn't be as bad as in IPv4.
Two things. First it would be just as bad. The problem isn't whether-or-not browsers try multiple addresses, teh problem is load is not distributed in a predictable manner. The other part of the problem is that it takes many many seconds for a browser to figure out that a server is down. Finally I personally don't want to expose all of my back end web servers to every joe schmoe. Yes our customers if they were inventive enough could figure it out (or just ask if they had a reason to need to know them) but I worry less about them. Security through obscurity? Not really...View it as limiting your exposure. It's like putting a locked door behind a gate, at the back of a building, instead of the front. If you've got the key to use it (port 80 HTTP request) it'll work, but it's easier to just use the open front door. Plus noones liable to lock the front door up from the inside on you ;)
Obviously when people running these services refuse to consider IPv6 because they can't load balance doesn't provide much incentive to load balance vendors to upgrade their stuff.
I'd guess rather the opposite if these same people are mentioning this to their VARs and the equipment manufacturers. Mostly I use LVS based stuff for load balancing which means I'm more or less IPv6 ready. The problem is it's another set of firewall rules and address space I have to maintain, document, account for, filter (for bad guys, or abusers), etc. There's a huge knock-on-effect on all manner of things that you might not expect to need to think about IPv6 offhand. Like log processors. I don't know about you but I don't have humans or chimps reading my logs for suspicious activity and producing summary reports of traffic, I've got automated processes. I'm not willing to wager that every one of those programs is ready yet. As for the 'map inbound ipv6 to ipv4' argument...ok...but depending on the setup, you'll lose a lot of your accounting and tracking features on the end hosts because everything will appear to come from the mapped address. Depending, obviously, on how you're implementing your load balancing. I'm just speaking for the few cases that I've deployed in this manner, not for anyone else, that doesn't mean what I'm saying doesn't apply for anyone else (it probably does). All of that will require some set of workarounds to make sure you know where traffic came from/was going to. Maybe I'm more concerned about what (potentially bad) things happen on my networks. Maybe not. Either way, that issue alone means a LOT of other software than the web server, load balancer, and routers need to understand (or speak) IPv6. There's a huge ecosystem of software here. A lot of it hasn't been written in such a way that it takes into account any other addressing/networking scheme than IPv4.
a good email over all explaining more parts of the pie :) sweet! On Fri, 5 Aug 2005, Michael Loftis wrote:
--On August 5, 2005 11:13:13 AM +0200 Iljitsch van Beijnum <iljitsch@muada.com> wrote:
There's a huge knock-on-effect on all manner of things that you might not expect to need to think about IPv6 offhand. Like log processors. I don't know about you but I don't have humans or chimps reading my logs for suspicious activity and producing summary reports of traffic, I've got automated processes. I'm not willing to wager that every one of those programs is ready yet.
ok, good... now in 5 years when there are 'many more' v6 users are you still in this boat? should some of this work get started also? Would that be facilitated by getting some actual logs?
Maybe I'm more concerned about what (potentially bad) things happen on my networks. Maybe not. Either way, that issue alone means a LOT of other software than the web server, load balancer, and routers need to understand (or speak) IPv6. There's a huge ecosystem of software here. A lot of it hasn't been written in such a way that it takes into account any other addressing/networking scheme than IPv4.
agreed, but that problem doesn't seem to be getting addressed any better than the lb/router/web-server problem doe sit?
--On August 6, 2005 6:56:27 PM +0000 "Christopher L. Morrow" <christopher.morrow@mci.com> wrote:
a good email over all explaining more parts of the pie :) sweet!
Thanks... I try to add something to the threads when I weigh in...
<..>
ok, good... now in 5 years when there are 'many more' v6 users are you still in this boat? should some of this work get started also? Would that be facilitated by getting some actual logs?
The point really, was that there are many packages of software. Open Source, Commercial, in-house, front-end and back room that will need to be looked at and outfitted. It's happening, but it will take a lot of work, and probably time. In 5 years, I don't know. I hope not. I hope by long before then that a majority of my concerns are addressed. It will take my employer/org about six months, to one year to fully light IPv6 for production. Maybe a bit longer. We've internal software to worry about, and that estimate excludes any set-backs from external sources, like Juniper deciding to twist everyone's arms for IPv6 licensing. I can leave that to a separate thread/argument though. I do have about a paragraph or two of venom on that topic if anyone is interested. :)
Maybe I'm more concerned about what (potentially bad) things happen on my networks. Maybe not. Either way, that issue alone means a LOT of other software than the web server, load balancer, and routers need to understand (or speak) IPv6. There's a huge ecosystem of software here. A lot of it hasn't been written in such a way that it takes into account any other addressing/networking scheme than IPv4.
agreed, but that problem doesn't seem to be getting addressed any better than the lb/router/web-server problem doe sit?
No not particularly. The web server software, routers, and load balancers in my networks are all IPv6 capable, aware, and ready. What isn't at this point is management tools, and an unknown number of customer applications. I work primarily in web hosting. This means that there are lots of unrelated applications that may make turning on IPv6 difficult. I'm not saying it's impossible. I'm not saying it won't happen. Heck I want it to happen. I want to go IPv6, get out of the way of the address shortage that will be. I wanted to point out the bigger picture amongst these threads of half answers and single issues. This isn't a one issue thing. Everyone here on NANOG can make it that if they want to, but I doubt that most of us do. The difficulty is in pointing this out to the 'sky is falling migrate today!' drum beaters, most of us are working on it, but we're not the ones that need to be haranged. SW developers need to be educated too, as much as, maybe more so than the ops community. They're the ones that will ultimately make or break this thing. We can build a network however we damn well please. But in the end the network is just a road. We need applications. Cars. And people to drive those cars....use those applications. That's what it comes down to. Multicast has limited traction not necessarily because of limited technical merit or ability, but because there are few applications that make use of it. As apps improve and start to support or require IPv6, more and more will roll it out or be forced to roll it out. Some of us are being held up by applications, hardware, or upsterams lack of v6, but that won't last forever, and it can't last much longer or we could very realistically miss the deadline, whatever it ends up being, for the 'last of the v4 space'. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler
participants (2)
-
Christopher L. Morrow -
Michael Loftis