Why some of us are IPv6 holdouts (Was: /8 end user assignment?)

Fri Aug 5 16:16:26 UTC 2005

--On August 5, 2005 11:13:13 AM +0200 Iljitsch van Beijnum 
<iljitsch at 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.