Re: ipv4 and ipv6 Coexistence.

John C Klensin <john-ietf@jck.com> Thu, 20 February 2020 02:18 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 A9120120273 for <ietf@ietfa.amsl.com>; Wed, 19 Feb 2020 18:18:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 csMgUG05CtHM for <ietf@ietfa.amsl.com>; Wed, 19 Feb 2020 18:18:46 -0800 (PST)
Received: from bsa2.jck.com (ns.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 1C05512002E for <ietf@ietf.org>; Wed, 19 Feb 2020 18:18:45 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1j4bQI-000JWN-JZ; Wed, 19 Feb 2020 21:18:42 -0500
Date: Wed, 19 Feb 2020 21:18:36 -0500
From: John C Klensin <john-ietf@jck.com>
To: Mark Andrews <marka@isc.org>, Khaled Omar <eng.khaled.omar@outlook.com>
cc: IETF Rinse Repeat <ietf@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
Subject: Re: ipv4 and ipv6 Coexistence.
Message-ID: <AB27A3D9EB2EA6D6C3A31351@PSB>
In-Reply-To: <D8063303-7DDA-41F8-A63A-C0244E3E9E25@isc.org>
References: <PR3P194MB0843ACAE01F33CEC57266A1AAE100@PR3P194MB0843.EURP194.PROD.OUTLOOK.COM> <EDAE6375-EE0B-4864-9834-C1FBC209D581@sobco.com> <PR3P194MB08431E138262F2A43C1D0621AE100@PR3P194MB0843.EURP194.PROD.OUTLOOK.COM> <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es> <PR3P194MB0843939F3B38426960A66E70AE130@PR3P194MB0843.EURP194.PROD.OUTLOOK.COM> <D8063303-7DDA-41F8-A63A-C0244E3E9E25@isc.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
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/Z8Ca2eN6o7ZOTQnTUOY9q_9XBsk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Feb 2020 02:18:48 -0000


--On Thursday, February 20, 2020 12:26 +1100 Mark Andrews
<marka@isc.org> wrote:

> Really we do not need to be inventing anything new in this
> space. We already have too many mechanisms.  ISPs just need to
> DEPLOY the existing mechanism.
>...
> Do we really need something more at the protocol level?
>...

Mark, I'm with you up to your comment below.  There are days on
which I think that the number of choices of mechanisms and
methods we have available have become part of the problem,
perhaps because they encourage those who are inclined to
procrastinate to wait for a clear winner (whatever that means).
For any proposed new mechanism, I think we should expect to see
economic arguments as to why it will succeed, deploy, and not
create more confusion and interoperability difficulties before
we are expected to analyze the technical details of the proposal.

However...

> We do need Governments to ban the selling of new IPv4-only
> domestic devices (CPE routers, TV's, game boxes, etc.).

We have been there and seen that or variations on it tried.  In
some alternate reality, the last attempts were so successful
that TCP/IP and all other competing solutions died out, leaving
the world running entirely on an updated version of the OSI
stack (either connectionless or connection mode) today.  In the
reality in which we (or most of us) actually live, government
attempts to advance networking by requiring some technologies
and banning others mostly lead to technological paralysis and
increased costs for all concerned.

best,
    john