IETF Logo Mail Archive

Re: [arch-d] ipv4 and ipv6 Coexistence.

Stewart Bryant <stewart.bryant@gmail.com> Wed, 26 February 2020 09:59 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494273A11E9 for <architecture-discuss@ietfa.amsl.com>; Wed, 26 Feb 2020 01:59:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 BwwEGfRO3x3o for <architecture-discuss@ietfa.amsl.com>; Wed, 26 Feb 2020 01:59:15 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727693A11E8 for <architecture-discuss@ietf.org>; Wed, 26 Feb 2020 01:59:15 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id a9so2308489wmj.3 for <architecture-discuss@ietf.org>; Wed, 26 Feb 2020 01:59:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=W2yqQohlNVvYtMsY5cxNvdUPFT41KNTNE+CgdhnsxEw=; b=Q+ZhYyFEwO5HXpptwJiGnp4UXnBrsre6vwF7nDQnITfYAeRrwtYh6g62ZYFmxQOxNc NZCc0ezpT+mcyGOtLA7Egu5mbd0ZwxeGzTJXyVWEl+RS81Oy7t1CMpskSA0qorc98DrT sEkwU/I0Jw4chnkmyMdiJ9mqJUUOOF7QDB7/8RSiJCeglq81o14+UQ2AOe5Gki7NyRpk 4jvGHeNj1biBuLBp2aMQOtUx8qWyMBS5/9Tck/Q1IuAeVysTWbOc1VvmuQ1D8TMPiRay y8VXdLCGi/PBotxL9X3LOqBhSazmEYxWE482vjFFH/mQNIFK6wXXQq4l+vd42TkdSahj Kd8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=W2yqQohlNVvYtMsY5cxNvdUPFT41KNTNE+CgdhnsxEw=; b=cRJs8eMHlwLLp5sLKcYJ4JpKf/Qh45kU8Q6kn4t4W+ytLbD9f82Yl9qqRNaK+nmGki Fn1SRySgYbJYOs4XAFjOhIZVxxwx+YOaag/0fXNk6Ca1iLdvd7Qga4w5ZLQKYFDzxLiJ HCdKH/MEz/UlnoAaU6TQUvbLUtQzb5w5X2TRHf1BTHsxmbfBhPtbZdBUHGUv9FTTY3nq zvYFZofKwqQKXG23aYug3Ja+8ay1/I+0J4zFaq9dqejH+stO6x/ghoXrlJuseABSsOrU W0cJQXrx1hjIuvlQsAewprP3N1Bs/4Gtc1e2Z8XkUxTdBBcSILaGt9krIMbgblarh0Qt Vp3A==
X-Gm-Message-State: APjAAAWM7oHfIsPjQfAWxdI3588uw8H30D0YtMO/oeZ/ZoN0pFwQQMrS 0Tq16QutINB4Cl2saaiahmI=
X-Google-Smtp-Source: APXvYqxhkVk3cZM3w/METuQTyGNkB+NiuO22THqLx6zZN3QZTIurg6UiMqK3KValF1SklgsglOkJXQ==
X-Received: by 2002:a1c:238d:: with SMTP id j135mr4678963wmj.165.1582711153734; Wed, 26 Feb 2020 01:59:13 -0800 (PST)
Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id k16sm2591519wrd.17.2020.02.26.01.59.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 01:59:13 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <5BF40034-E920-484B-AC6A-9071BC1E86B7@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1167D3A8-DB74-4FF5-AD20-B9ADCCFAA715"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Wed, 26 Feb 2020 09:59:12 +0000
In-Reply-To: <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Toerless Eckert <tte@cs.fau.de>, architecture-discuss@ietf.org, Mark Andrews <marka@isc.org>
To: Fred Baker <fredbakersba@gmail.com>
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> <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de> <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/L6jnxWjuIxWo4RZjA39BB21R4aE>
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2020 09:59:17 -0000


> On 25 Feb 2020, at 18:16, Fred Baker <fredbakersba@gmail.com> wrote:
> 
> The same point applies in this case. If a company wants to internally only use <something> as a link layer protocol, that's their choice, but if they step very far away from IPv4 and IPv6, it means that they can't do business with their vendors and their customers - they have to in some way translate or overlay at that boundary. What has been beneficial with Internet technologies since they were invented was that one no longer had to think about global deployments of BBN 1822, X.25, Ethernet, or any of a long list of other things; they became carriers for a common architecture enabling global communications.

I think that we have to distinguish between packet exchange and information exchange.

For the applications that are of commercial significance HTTP(S) seems to be becoming the new waist.

Furthermore for most of those applications the entry point into the commercial domain is moving quite close to the user giving greater scope for migration to an alternative than we have in a model where most traffic transits an IXP.

The trend is towards app to commercial server connected via an encrypted UDP/IP tunnel. Where the app can be a web browser. 

I am sure that we will retain IPv4/6 as a connection of last resort for the foreseeable future, but it is by no means clear that it (or indeed any single replacement) will remain the protocol of first choice.

- Stewart

v2.23.0 | Report a Bug | By Email