IETF Logo Mail Archive

Re: [v6ops] reclassify 464XLAT as standard instead of info

Lee Howard <lee@asgard.org> Fri, 22 September 2017 14:52 UTC

Return-Path: <lee@asgard.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B2E134479 for <v6ops@ietfa.amsl.com>; Fri, 22 Sep 2017 07:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] 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 f6x8hF0xccTo for <v6ops@ietfa.amsl.com>; Fri, 22 Sep 2017 07:52:23 -0700 (PDT)
Received: from atl4mhob04.registeredsite.com (atl4mhob04.registeredsite.com [209.17.115.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867881342CC for <v6ops@ietf.org>; Fri, 22 Sep 2017 07:52:23 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob04.registeredsite.com (8.14.4/8.14.4) with ESMTP id v8MEqKbg002777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <v6ops@ietf.org>; Fri, 22 Sep 2017 10:52:20 -0400
Received: (qmail 3688 invoked by uid 0); 22 Sep 2017 14:52:20 -0000
X-TCPREMOTEIP: 72.221.14.183
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@72.221.14.183) by 0 with ESMTPA; 22 Sep 2017 14:52:19 -0000
User-Agent: Microsoft-MacOutlook/14.7.2.170228
Date: Fri, 22 Sep 2017 10:52:10 -0400
From: Lee Howard <lee@asgard.org>
To: Ole Troan <otroan@employees.org>, Gert Doering <gert@space.net>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>
Message-ID: <D5EA8233.87034%lee@asgard.org>
Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info
References: <D5E8043B.86B21%lee@asgard.org> <E48DDA04-C058-4992-906E-8C8BC0E102AB@consulintel.es> <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <de6b9aac-a3cc-0915-77c7-9fb880c3a16a@gmail.com> <20170921223305.B72A8878E716@rock.dv.isc.org> <CAKD1Yr13ijKCB_71_2vMyGurc3-kSraLJycGxZwf121tjp8u1Q@mail.gmail.com> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org>
In-Reply-To: <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/MH-ecH_UNfcN8triZcGPz50VvaM>
Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 22 Sep 2017 14:52:25 -0000

Speaking as participant, not as cochair.

On 9/22/17, 8:17 AM, "v6ops on behalf of Ole Troan"
<v6ops-bounces@ietf.org on behalf of otroan@employees.org> wrote:

>Gerd,
>
>> On 22 Sep 2017, at 13:48, Gert Doering <gert@space.net> wrote:
>> 
>> Hi,
>> 
>>> On Fri, Sep 22, 2017 at 05:07:19PM +1000, Mark Andrews wrote:
>>> IPv6 applications need to add code to WORKAROUND breakages caused
>>> by NAT64 the way they need add WORKAROUNDS for the NAT breakages
>>> even if they are not using NAT64 or NAT respectively.  The cancer
>>> that is NAT64 needs to be eradicated.
>> 
>> It will nicely go away if all endpoints are reachable over v6.

How many significant digits in “all”?
90%? 99%? 99.9%? 99.999%?
Somewhere in there the engineering tradeoffs start looking different.


>
>I think that’s the concern. That it will not.
>IPv6 applications will have code to accommodate for NAT64 forever.

How many significant digits in “forever”?

I ask because if an app developer is 99.xx% sure that 99.xx% of users will
be on IPv6-enabled devices and networks, then they can remove any
compensation for IPv4.

Enough years have passed that “forever” isn’t as far off as it used to be.
Following adoption curves:
 The majority of hits on Google US will be IPv6 in six months.
 80% of hits on Google US will be IPv6 in two and a half years.
 90% of hits on Google US will be IPv6 in three and a half years.
 The majority of hits on Google worldwide will be IPv6 in two years.
 80% of hits on Google worldwide will be IPv6 in four years.
 90% of hits on Google worldwide will be IPv6 in five years.
https://www.vyncke.org/ipv6status/project.php?metric=p&timeforward=2000&tim
ebackward=2064&country=ww

In IETF time scales, we are about to be overtaken by events. Predicting
based on a logistic curve is tricky, but 99% IPv6 is within most of our
career lifetimes.

How rare does a case have to be before you can decide not to handle it?


For that matter, how rare does a case have to be before a network operator
decides it’s marginal and can be either outsourced or ignored? Asking for
a friend.

Lee


>
>Ole

v2.23.0 | Report a Bug | By Email