Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00.txt).

John C Klensin <john-ietf@jck.com> Thu, 29 December 2016 09:04 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDB3129428 for <ietf@ietfa.amsl.com>; Thu, 29 Dec 2016 01:04:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
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 ELbVqjPeJesw for <ietf@ietfa.amsl.com>; Thu, 29 Dec 2016 01:04:11 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062C9129420 for <ietf@ietf.org>; Thu, 29 Dec 2016 01:04:10 -0800 (PST)
Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1cMWd0-000DBR-RR; Thu, 29 Dec 2016 04:04:02 -0500
Date: Thu, 29 Dec 2016 04:03:56 -0500
From: John C Klensin <john-ietf@jck.com>
To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@frobbit.se>, David Conrad <drc@virtualized.org>
Subject: Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00.txt).
Message-ID: <5FBCC938E3BF3F24CD0B9C42@PSB>
In-Reply-To: <FE7643B1-28CB-4ABA-AF95-1B831D701E25@frobbit.se>
References: <HE1PR04MB14492A6FA01B592B6DD69093BD920@HE1PR04MB1449.eurprd04.prod.outlook.com> <7F96C4EC-B762-4A2C-AF7E-20D92AE7F9CF@nic.cz> <CAEik=Cv0AXRTLKc1azgnKRrMtQxrC19kX5_RqaQNSt9nkDfPFw@mail.gmail.com> <049f01d2613f$c5431ef0$4fc95cd0$@tndh.net> <m2o9zv7bh5.wl-randy@psg.com> <alpine.DEB.2.10.1612282213390.18445@sleekfreak.ath.cx> <B137A15F-A5C1-41BE-84B5-A12DF2D5AFFC@virtualized.org> <FE7643B1-28CB-4ABA-AF95-1B831D701E25@frobbit.se>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.70
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/x7csq47mInbQ6hub-4Km3zSsmHQ>
Cc: shogunx@sleekfreak.ath.cx, IETF Rinse Repeat <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Dec 2016 09:04:12 -0000

Patrik,

I think that view of the world depends on one critical
assumption, i.e., that the end-to-end model actually has
significant value.  To at least some degree, every installed
carrier-grade NAT, every provider who sees the Internet in
content delivery terms, every country that believes it should
control addressing within its national boundaries, every ISP who
has figured out a way to charge close to an order of magnitude
more for a connection that (legally and technically) allows
server functions rather than only client ones, perhaps every
application or mechanism that assumes the web is the Internet
and nothing else counts, etc., pushes us in the other direction.
Each of those decisions/ actions is motivated, at least in part,
by considerations other than IPv4 address space exhaustion
and/or cost.

There is also a chance that the Davies-Baran packet hypothesis
was incorrect and that, at current and future scale, flows and
dedicated or dynamic virtual circuits, even if packets are run
over them, really are a better way to run at least the core of a
network.  In addition to the more obvious cases, almost every
step toward "we should run communications between you and me
over an encrypted tunnel to protect our privacy" pushes us more
toward call setup and virtual circuits. 

In those directions, overlapping address ranges separated by
ALGs work more than well enough and, from some points of view,
have significant advantages of their own.  If we go there, as
some readings of current behavior suggest we may to be going, we
will wait a really long time before your "one day" gets close.
Indeed, it may be receding at several months per month as we get
better at not deploying IPv6.

I hope I'm wrong, but "we" spent many years trying to tell
people that IPv6 was completely ready, that all transition
issues had been sorted out and the needed mechanisms were
well-understood, and that deployment would be easy and painless.
When those stories became ever more clearly false, "we" then
fell back on claims or threats that failure to deploy IPv6
before assorted events occurred would cause some evil demon to
rise up ad devour them and their networks.  Most of those events
have now occurred without demonstrable bad effects; each one
that does reduces our credibility and the credibility and
plausibility of IPv6.  Perhaps had plans like Tony's prevailed
15+ years ago, we'd be in much better shape, perhaps not, but,
to a considerable extent, each year we live without widespread
IPv6 (and no obvious signs of severe damage as a result) makes
it harder to convince people of the necessity of incurring the
costs and disruption of converting.

The big problem with IPv6 deployment is the same as it was
twenty years ago: most of the incentives we have offered as to
why people should convert are not any obvious and significant
advantages of the new protocol/ address model itself but fear of
Bad Things Happening as IPv4 address space becomes depleted.
Without significant positive incentives, the arguments,
especially the economic ones, for putting resources into
mitigating those threatened Bad Things or their consequences are
as strong or stronger than the arguments for deploying a new
protocol, an action that has many technical and non-technical
costs, especially when no one seems to have a realistic theory
that avoids having to operate IPv4 and IPv6 networks in parallel
for an extended period.

I don't particularly dislike IPv6, I just think we've failed to
pay enough attention to incentives and barriers.  I wish it were
otherwise, really I do.

sadly,
    john


--On Thursday, December 29, 2016 08:17 +0100 Patrik Fältström
<paf@frobbit.se>; wrote:

> On 29 Dec 2016, at 5:27, David Conrad wrote:
> 
>> My suspicion (hope?) is that the increased price of IPv4 (and
>> operational challenges dealing with GGNAT) will encourage
>> folks to take IPv6 more seriously.
> 
> ...in combination with the increased a. announcements of
> unannounced (regardless of whether it is allocated or not)
> address space; and ultimately b. announcements of address
> space that is announced (as people will just not care if
> someone on the other side of the planet use the space or not).
> 
> I.e. we can just sit down, do our homework, and people will
> one day see IPv4 is more work for them than IPv6. And with
> homework I mean continue to improve management and use of IPv6
> address space. There is still so much more to be done. Because
> one day people will come and ask for it, and when that happens
> we better have the tools ready.