North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Why some of us are IPv6 holdouts (Was: /8 end user assignment?)
- From: Michael Loftis
- Date: Fri Aug 05 12:20:41 2005
--On August 5, 2005 11:13:13 AM +0200 Iljitsch van Beijnum
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.