|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Why some of us are IPv6 holdouts (Was: /8 end user assignment?)
--On August 5, 2005 11:13:13 AM +0200 Iljitsch van Beijnum <[email protected]> wrote: 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 ;)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. 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.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. 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.
|