* Owen DeLong
The difference is that only a small number of people will need to deal with the two stacks, in a small number of places. They way I envision it, the networking staff would ideally operate SIIT a logical function on the data centre's access routers, or their in their backbone's core/border routers.
I suppose if you're not moving significant traffic, that might work.
In the data centers I deal with, that's a really expensive approach because it would tie up a lot more router CPU resources that really shouldn't be wasted on things end-hosts can do for themselves.
By having the end-host just do dual-stack, life gets a lot easier if you're moving significant traffic. If you only have a few megabits or even a couple of gigabits, sure. I haven't worked with anything that small in a long time.
For a production deployment, we would obviously not do this in our routers' CPUs, for the same reasons that we wouldn't run regular IP forwarding in their CPUs. If a data centre access router gets a mix of dual-stacked input traffic coming in from the Internet, that same amount of traffic has to go out in the rear towards the data centre. Whether or not it comes out as the same dual stacked mix as what came in, or as only IPv6 does not change the total amount of bandwidth the router has to pass. So the amount of bandwidth is irrelevant, really. I would agree with you if this was question of doing SIIT in software instead of IP forwarding in hardware. But that's no different than when what was a problem a while back - routers that did IPv4 in hardware and IPv6 in software. Under such conditions, you just don't deploy.
A typical data centre operator/content provider has a vastly larger number of servers, applications, systems administrators, and software developers, than they have routers and network administrators. By making IPv4 end-user connectivity a service provided by the network, you make the amount of dual stack-related complexity a fraction of what it would be if you had to run dual stack on every server and in every application.
In a world where you have lots of network/system administrators that fully understand IPv6 and have limited IPv4 knowledge, sure. In the real world, where the situation is reversed, you just confuse everyone and make the complexity of troubleshooting a lot of things that much harder because it is far more likely to require interaction across teams to get things fixed.
With dual stack, they would need to fully understand *both* IPv6 and IPv4. This sounds to me more like an argument for staying IPv4 only. And even if they do know both protocols perfectly, they still have to operate them both, monitor them both, document them both, and so on. That is a non-negligible operational overhead, in my experience.
Right… As soon as you make it stateless, you lose the ability to overload the addresses unless you're using a static mapping of ports, in which case, you've traded dynamic state tables for static tables that, while stateless, are a greater level of complexity and create even more limitations.
I would claim that stateful NAPT44 mapping, which requires a router to dynamically maintain a table of all concurrent flows using a five-tuple identifier based on both L3 and L4 headers, is a vastly more complex and thing than a static configured mapping table with two L3 addresses for each entry.
Without state, how are you overloading the IPv4 addresses?
We're not.
If I don't have a 1:1 mapping between public IPv4 addresses and IPv6 addresses at the SIIT box, what you have described doesn't seem feasible to me.
SIIT is 1:1.
If I have a 1:1 mapping, then, I don't have any address conservation because the SIIT box has an IPv4 address for every IPv6 host that speaks IPv4.
The SIIT box has indeed an IPv4 address for every IPv6 host that speaks IPv4, true. The conservation comes from elsewhere, from the fact that a content provider will often have a large number of servers, but a much smaller number of publicly available IPv4 service addresses. Let's say you have a small customer with a web server and a database server. Using dual stack, you'll need to assign that customer at least a /29. One address for each server, three for network/broadcast/default router, and three more that goes away just because those five gets rounded up to the nearest power of two. With SIIT, that customer would instead get an IPv6 /64 on his LAN, and no IPv4 at all. Instead, a single IPv4 address will gets mapped to the IPv6 address of the customer's web server. You've now just saved 7 out of 8 addresses which you may use for 7 other customers like this one. That's just a small example. For most my customers, the ratio of assigned IPv4 addresses to publicly available services is *at least* one order of magnitude. So I have huge potential for savings here.
Finally, by putting your money into NAT44 for IPv4 conservation, you have accomplished exactly *nothing* when it comes to IPv6 deployment. You'll still have to go down the dual stack route, with the added complexity that will cause. With SIIT, you can kill both birds with one stone.
But I'm not putting more money into NAT44… I'm deploying IPv6 on top of my existing IPv4 environment where the NAT44 is already paid for.
We don't currently use NAT44 and have no desire to invest in it either. I strongly dislike the idea of putting big stateful boxes between our customers and their end users. But if we have to do it anyway, it will certainly eat away from any human resources and budget that could otherwise be used for IPv6 activities. Unfortunately. If you've already bought NAT44 for your IPv4 conservation strategy, the case for SIIT is weaker, I admit. However, there's still the benefits of potentially reducing complexity compared to dual stack, and the fact that it requires no state in your network.
Agreed, and I have no reason to doubt that HE does dual stack really well. That said, I don't think HE is the type of organisation for which SIIT makes the most sense - certainly not for your ISP activities. The type of organisation I picture using SIIT, is one that operates a bunch of servers and application cluster, i.e., they are controlling the entire service stack, and making them available to the internet through a small number of host names. Most internet content providers would fall in this category, including my own employer.
We have a lot of customers and professional services clients that fit exactly what you describe. Not one of them has chosen SIIT over dual stack.
Well, today it's not easy to deploy SIIT, so that's quite understandable. There's not that many implementations available. You can do it on the Cisco ASR1K, although it lacks some features (in particular the static mapping feature) that I find are very desirable in the data centre use case.
Admittedly, they also aren't using NAT44, but that's because everything has a public IPv4 address, as things should be for server clusters.
I'm confused, you said above that you were already using NAT44..? In any case, good for you that you have enough public IPv4 addresses for everything. Very shortly, we won't, and our friendly neighbourhood RIR is fresh out. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/