Re: [v6ops] Operational Consensus on deployment

Tore Anderson <tore@fud.no> Tue, 05 August 2014 18:33 UTC

Return-Path: <tore@fud.no>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63FD1A0657 for <v6ops@ietfa.amsl.com>; Tue, 5 Aug 2014 11:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b48PXceauyO4 for <v6ops@ietfa.amsl.com>; Tue, 5 Aug 2014 11:33:16 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF151A03CA for <v6ops@ietf.org>; Tue, 5 Aug 2014 11:33:16 -0700 (PDT)
Received: from cm-84.209.85.233.getinternet.no ([84.209.85.233]:60403 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <tore@fud.no>) id 1XEjXu-00064s-9q; Tue, 05 Aug 2014 20:33:14 +0200
Message-ID: <53E1236A.605@fud.no>
Date: Tue, 05 Aug 2014 20:33:14 +0200
From: Tore Anderson <tore@fud.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Ted Lemon <ted.lemon@nominum.com>, Ca By <cb.list6@gmail.com>
References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <DE860EBC-171E-46E7-A3B6-5E8B79A453CC@cisco.com> <53DFEC6C.3010707@gmail.com> <CAD6AjGRUWxT5XiNxMi_S5VgYtGMLb_FVHXN-ZfGpcY=geix15g@mail.gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <CAD6AjGTBfyT-zNDJtBKCNtRxd=Hi07678Sr_-HgSGYbjAiF3Tg@mail.gmail.com> <C5281716-DC04-42E6-AC82-0D53E5DA0284@nominum.com>
In-Reply-To: <C5281716-DC04-42E6-AC82-0D53E5DA0284@nominum.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sZG7rca3PwsQQXx1cu3CJYPDWxU
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] Operational Consensus on deployment
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Aug 2014 18:33:18 -0000

* Ted Lemon

> On Aug 5, 2014, at 12:00 PM, Ca By <cb.list6@gmail.com> wrote:
>> In summary, the premise of the daul stack transition for the
>> Internet is faulty.  It already failed.
> 
> With all due respect, I don't see how what you have said here
> benefits the discussion.   First of all, there's a great deal of
> evidence that what you've said isn't actually true, and secondly,
> even to the extent that it is true, it's not really actionable.  Of
> course there will be people who will do things the wrong way, and
> either limp along forever or eventually get bulldozed off the cliff.
> So what?

The dual stack transition has indeed already failed. If you're located
in Europe, Asia, or Latin America, chances are that you simply cannot
obtain the IPv4 addresses you need to run dual stack. North America
should be in the same situation shortly.

Any *current* recommendation to use dual stack to needs to come with a
caveat that it is only really applicable to African operators, to
operators who happens to be sitting on a large reserve of IPv4
addresses, or to operators who have no growth.

Geoff saw this coming of course, slides 27 through 29 of
http://www.potaroo.net/presentations/2007-10-23-ipv4-depletion.pdf sums
up how dual stack has failed much better than I ever could.

> There are still mainframes in back offices running SNA, but that
> doesn't mean that IPv4 is irrelevant: quite the opposite--they are
> probably running SNA in IP tunnels, their 370 is probably an
> emulation running on an Intel box, and chances are that people are
> sshing in using a 3270 emulator.   So we don't care that they are
> still running SNA, and we don't care when they get rid of it, because
> it is not an "internet" protocol.   That is the future of IPv4 as
> well.

I agree that once we're there, problem solved, nobody will care. However
we're very far from that that being reality. As Cameron rightly pointed
out, somewhere in the world right now, someone is writing a line of
code, creating a database schema, making an ACL, purchasing a piece of
hardware or service, or whatever, that creates yet another dependency on
IPv4, making it ever more difficult to demote IPv4 to a «not an
"internet protocol» à la SNA.

As Owen points out, I could weed out such dependencies in maintenance
windows. But even if that is true, with dual stack, IPv4-dependent
infrastructure will continue to be created at a much greater rate than I
can retroactively fix it to become IPv4-independent. And there is just
no way that I could possibly audit every line of code written, every
piece of software installed, or every service or piece of hardware
procured, and that way make sure that no new IPv4 dependencies are
introduced.

The way I see it, the only realistic solution to stopping the
infrastructure from acquiring more and more dependencies on IPv4 is to
remove it entirely. Cold turkey.

> The question is, are there people who want to do a transition to IPv6
> (or will want to), whether for altruistic or pragmatic reasons, and
> if so, is there additional help we can offer them, or is what we've
> done thus far sufficient?

I'm transitioning to IPv4 for pragmatic reasons, and dual stack doesn't
cut it for me, for reasons that include:

- I don't have enough IPv4 addresses to do dual stack for much longer.
- Dual stack greatly increases complexity, which in turn increases
  the OpEx and reduces service reliability.
- As mentioned above, the presence of IPv4 will inevitably cause an ever
  increasing dependency on IPv4, because of technological inertia in the
  humans that design, develop, and deploy the application stacks.

As for additional help needed, well, I'm trying to put my money where my
mouth is and coming up with a solution to these problems - you could
help by reviewing my drafts. :-) The solution works, there is already
running open-source code, so rough consensus is all that's missing...

Tore