Re: IPv6 Netowrk Device Numbering BP

[Owen DeLong <owen () delong com>]

On Nov 4, 2012, at 1:55 AM, Tore Anderson <tore.anderson () redpill-linpro com> wrote:

> * Owen DeLong
>
> > What do you get from SIIT that you don't get from dual stack in a
> > datacenter?
>
> In no particular order:
>
> - Single stack is much simpler than dual stack. A single stack to
> configure, a single ACL to write, a single service address to monitor,
> staff needs to know only a single protocol, deveopment staff needs only
> develop and do QA for a single protocol, it's a single topology to
> document, a single IGP to run and monitor, a single protocol to debug
> and troubleshoot, one less attack vector for the bad guys, and so on. I
> have a strong feeling that the reason why dual stack failed so miserably
> as a transition mechanism was precisely because of the fact that it adds
> significant complexity and operational overhead, compared to single stack.

Except that with SIIT, you're still dealing with two stacks, just moving
the place where you deal with them around a bit. Further, you're adding
the complication of NAT into your world (SIIT is a form of NAT whether
you care to admit that to yourself or not).

> - IPv4 address conservation. If you're running out of IPv4 addresses,
> you cannot use dual stack, as dual stack does nothing to reduce your
> dependency on IPv4 compared to single stack IPv4. With dual stack,
> you'll be using (at least) one IPv4 address per server, plus a bit of
> overhead due to the server LAN prefixes needing to be rounded up to the
> nearest power or two (or higher if you want to accommodate for future
> growth), plus overhead due to the network infrastructure. With SIIT, on
> the other hand, you'll be using a single IPv4 address per publicly
> available service - one /32 out of a pool, with nothing going to waste
> due to aggregation, network infrastructure, and so on.

Since you end up dealing with NAT anyway, why not just use NAT for IPv4
conservation. It's what most engineers are already used to dealing with
and you don't lose anything between it and SIIT. Further, for SIIT to
work, you don't really conserve any IPv4 addresses, since address
conservation requires state.

> - Promotes first-class native IPv6 deployment. Not that dual stack isn't
> native IPv6 too, but I do have the impression that often, IPv6 in a dual
> stacked environment is a second class citizen. IPv6 might be only
> partially deployed, not monitored as well as IPv4, or that there are
> architectural dependencies on IPv4 in the application stack, so that you
> cannot just shut off IPv4 and expect it to continue to work fine on IPv6
> only. With SIIT, you get only a single, first-class, citizen - IPv6. And
> it'll be the only IPv6 migration/transition/deployment project you'll
> ever have to do. When the time comes to discontinue support for IPv4,
> you just remove your IN A records and shut down the SIIT gateway(s),
> there will be no need to touch the application stack at all.

Treating IPv6 as a second class citizen is a choice, not an inherent
consequence of dual-stack. IPv6 certainly isn't a second class citizen
on my network or on Hurricane Electric's network.

> As I said earlier, I will submit an IETF draft about the use case
> shortly (it seems that the upload page is closed right now, due to the
> upcoming IETF meeting), and I invite you to participate in the
> discussion - hopefully, we can work together to address your technical
> concerns with the solution.

I'll look forward to reading the draft.

> I did present the use case at RIPE64, by the way - I hope you will find
> these links interesting:
>
> https://ripe64.ripe.net/archives/video/37
> https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf

I'll try to look them over when I get some time.

Owen