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: Patrik Fältström <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.
- IPv10 (Temp. name IPmix) (draft-omar-ipv10-00.txt… Khaled Omar
- RE: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Khaled Omar
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Ladislav Lhotka
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Leonir Hoxha
- RE: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Tony Hain
- Re IPv6 adoption (Was Re: IPv10 (Temp. name IPmix… Steve Crocker
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Randy Bush
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… shogunx
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… David Conrad
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Randy Bush
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… shogunx
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Patrik Fältström
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… John C Klensin
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Patrik Fältström
- The demand for IPv4 addresses (was: IPv10) S Moonesamy
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… S Moonesamy
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Lee Howard
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… John C Klensin
- Re: IPv6, was IPv10 John Levine
- Re: multihoming, was IPv10 John Levine
- Re: IPv6, was IPv10 (fwd) John R Levine
- Re: IPv6, was IPv10 Brian E Carpenter
- Re: multihoming, was IPv10 Brian E Carpenter
- Re: IPv6, was IPv10 (fwd) Brian E Carpenter
- Re: IPv6, was IPv10 Mark Andrews
- Re: IPv6, was IPv10 John R Levine
- Re: IPv6, was IPv10 (fwd) Mark Andrews
- Re: IPv6, was IPv10 Mark Andrews
- Re: multihoming, was IPv10 Mark Andrews
- Re: multihoming, was IPv10 John R Levine
- Re: multihoming, was IPv10 Mark Andrews
- Re: multihoming, was IPv10 Randy Bush
- Re: multihoming, was IPv10 Randy Bush
- Re: multihoming, was IPv10 John Levine
- Re: multihoming, was IPv10 Mark Andrews
- Re: multihoming, was IPv10 Brian E Carpenter
- RE: multihoming, was IPv10 Michel Py
- Re: multihoming, was IPv10 John C Klensin
- Re: multihoming, was IPv10 John R Levine
- Re: IPv6, was IPv10 shogunx
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Patrik Fältström
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Randy Bush
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… heasley
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Brian E Carpenter
- Re: multihoming, was IPv10 Brian E Carpenter
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Patrik Fältström
- Re: multihoming, was IPv10 Masataka Ohta
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Brian E Carpenter
- Re: multihoming, was IPv10 Brian E Carpenter
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Randy Bush
- Re: multihoming, was IPv10 Octavio Alvarez
- Re: multihoming, was IPv10 Stewart Bryant
- Re: multihoming, was IPv10 Masataka Ohta
- Re: multihoming, was IPv10 Brian E Carpenter
- Re: multihoming, was IPv10 Brian E Carpenter
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… David Farmer
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Brian E Carpenter
- Re: multihoming, was IPv10 Jeff Tantsura
- Re: why v6 still isn't ready, was IPv10 John Levine
- Re: multihoming, was IPv10 Masataka Ohta
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Randy Bush
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Brian E Carpenter
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Randy Bush
- Re: multihoming, was IPv10 Randy Bush
- Re: why v6 still isn't ready, was IPv10 Randy Bush
- Re: why v6 still isn't ready, was IPv10 Brian E Carpenter
- Re: why v6 still isn't ready, was IPv10 Randy Bush