Re: IPv6 Netowrk Device Numbering BP

[Tore Anderson <tore.anderson () redpill-linpro com>]

* 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/