IETF Logo Mail Archive

Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

"Heatley,N,Nick,TQB R" <nick.heatley@bt.com> Wed, 27 September 2017 20:51 UTC

Return-Path: <nick.heatley@bt.com>
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 87F9A134455 for <v6ops@ietfa.amsl.com>; Wed, 27 Sep 2017 13:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btgroupcloud.onmicrosoft.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 kTQfYJlI-oX7 for <v6ops@ietfa.amsl.com>; Wed, 27 Sep 2017 13:51:13 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F701350AC for <v6ops@ietf.org>; Wed, 27 Sep 2017 13:51:12 -0700 (PDT)
Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 27 Sep 2017 21:51:10 +0100
Received: from smtpe1.intersmtp.com (10.187.98.11) by EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 27 Sep 2017 21:51:10 +0100
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (213.199.154.209) by smtpe1.intersmtp.com (62.239.224.235) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 27 Sep 2017 21:51:02 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BTGroupCloud.onmicrosoft.com; s=selector1-bt-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O7yv35AZvuIi/rjF+A8QeVpxDPhoyFGqMebG8+QRWb4=; b=a5kBgHCOPNKdVu1jaYLS8xxSNk0u4/ULtWWsTYUbQLkYR5k9of0sEYV5AtCdtO8rZLcWT7YtsUQBjbTuYj1WK6klIfdflkbT+JO5obD1Q0GbKwxwNZoNQyBELhLh+9c35C0+9M2mO2qr8s+yxhhfCc3VBbcEROhLPb/sTq/bPu4=
Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM (10.167.24.147) by LO1P123MB1090.GBRP123.PROD.OUTLOOK.COM (10.167.27.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 27 Sep 2017 20:51:04 +0000
Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) by LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) with mapi id 15.20.0077.016; Wed, 27 Sep 2017 20:51:04 +0000
From: "Heatley,N,Nick,TQB R" <nick.heatley@bt.com>
To: IPv6 Ops WG <v6ops@ietf.org>, james woodyatt <jhw@google.com>
Thread-Topic: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)
Thread-Index: AdM16ZBiVXxOrrPASdi8hSWu5DH/5gBKSg6AAA4804AAHACmgAAFqakl
Date: Wed, 27 Sep 2017 20:51:03 +0000
Message-ID: <LO1P123MB0116805F9A18932E2D0694FEEA780@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM>
References: <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM> <46045DAA-9096-43BA-A5FD-571232767726@google.com> <CAKD1Yr3vziaHfkR+hQ7QHXaz7QraKH2HLUVXUW63GpnOAj4JoQ@mail.gmail.com>, <E72C3FBE-57A4-4058-B9E5-F7392C9E9101@google.com>
In-Reply-To: <E72C3FBE-57A4-4058-B9E5-F7392C9E9101@google.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nick.heatley@bt.com;
x-originating-ip: [40.68.209.210]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; LO1P123MB1090; 6:zkF7Afwo7KZUpKT/jsaOA6I1MKWaoXSNZb+oDlK/pxejqybTST+gBeJliFjLqhJusEtmegBjn7sH4RQTpfj9byYBa6c0UV6LMnF8cqhNrg5NXvc++J3mHqqJLWc9NgDBVdsfRCmbQpzCF0QTJ3dN1pNn7BZoVFCy+HwR7GbUTTqQkbVPfG97TrkdlPsLrvZ+9iv7Ac43fXqpeHBTs0NxWtR8eZiJj2hwaalkYJwsW6ojDIXaYRPkYJjs+4nLnqCWdGkWcdUnVyp7AAwsdWU9JAUkqjeivKop7ZypKdYS+4rJbdkfdYeVgaKWNXxxxG9Akd8ul59Y8AKcjKoEZHOSTA==; 5:KfEwvw1vSFxIITRsdlBzFACB7h8yc4HTGTd/4WGJ0Oa6BVme3nXqKKEuY6ftpcmhds9oGHSizx1NtQZtqQNBdtLaNaF1/P84Gg3IZgwFrIQ6OtCTno9t0dmA8B29Vv/jstcO3XrLyx5D7YHK+omlKw==; 24:uZguZ99M9cVBd8id7l729NP0snoe+v2m7AoPvx8852tRSV+NS04mQT/m+d5TAeQJtKvIRxgFWpC2SWLv5J9ultNSnNSeS2s6iy/jHRdldoI=; 7:CCqYVYO8k3Pwvt3BEZK3u7mgjM8Wanv2rMurnpt7L4Ofi+WOWr1NSId7WShWxRDcJZMf/83TD4kXEO6ZdjyCXaf2i3BdSb6EahTxbR4vgkUzrlr/73o9cU+F+B//76rjcwzJKSCADinHaWPVdDjfEgYqBvATxngpE42XmxfRlbgpNvdzqJBnl7L015JotKgxZZFwU6tXh42/pE8t+GPA3jHPiESpMe1gQJ5+PZvD1rc=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 329be496-ed9e-4efb-e84a-08d505e977f5
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:LO1P123MB1090;
x-ms-traffictypediagnostic: LO1P123MB1090:
x-antispam-2: 1
x-exchange-antispam-report-test: UriScan:(278428928389397)(211936372134217)(153496737603132);
x-microsoft-antispam-prvs: <LO1P123MB10906B32AB4630DC9BE108CFEA780@LO1P123MB1090.GBRP123.PROD.OUTLOOK.COM>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(920507026)(6041248)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:LO1P123MB1090; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:LO1P123MB1090;
x-forefront-prvs: 04433051BF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39830400002)(346002)(24454002)(377454003)(189002)(199003)(33656002)(478600001)(97736004)(110136005)(53546010)(316002)(7696004)(93886005)(66066001)(45080400002)(2900100001)(5660300001)(86362001)(189998001)(54356999)(6246003)(105586002)(106356001)(102836003)(3846002)(6116002)(50986999)(76176999)(606006)(53936002)(6436002)(3660700001)(14454004)(3280700002)(101416001)(25786009)(55016002)(8936002)(54896002)(68736007)(74316002)(229853002)(236005)(6506006)(77096006)(2950100002)(9686003)(7736002)(8676002)(81166006)(6306002)(81156014)(2906002)(34040400001); DIR:OUT; SFP:1101; SCL:1; SRVR:LO1P123MB1090; H:LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_LO1P123MB0116805F9A18932E2D0694FEEA780LO1P123MB0116GBRP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2017 20:51:03.9041 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO1P123MB1090
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/qghSOnsFEgqwTXVbABAyRlM53xg>
Subject: Re: [v6ops] 464xlat case study (was 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: Wed, 27 Sep 2017 20:51:16 -0000

Stop speculating.

A specific example: certain vpn clients, still in service, fail when tethered to a nat64/dns64 device. Typically, a customer is tethering their work machine to their personal handset. NAT64/DNS64 does not provide what the client needs and neither can the OS. Such client SW may be older but is still in service, they are not yet end of support.

Customers care if this breaks. So do I, this is doing harm. And no, they won't revert to their corp IT dept. They know this relates to their provider.
With 464xlat these usecases simply work.
I have zero calls into customer services concerning devices with 464xlat.

464xlat is the reason why IPv6-only can work where the end OS is unknown.
IPv6-only for the handset mass-market is the way to mitigate exhaustion.


Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: v6ops <v6ops-bounces@ietf.org> on behalf of james woodyatt <jhw@google.com>
Sent: Wednesday, September 27, 2017 7:08:55 PM
To: IPv6 Ops WG
Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

On Sep 26, 2017, at 21:47, Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>> wrote:
On Wed, Sep 27, 2017 at 6:59 AM, james woodyatt <jhw@google.com<mailto:jhw@google.com>> wrote:
c.f. the approach used by Apple, which uses a bump-in-the-stack at a higher layer of the operating system instead of using the CLAT

My understanding is that the approach used by Apple requires that applications be modified. That's feasible given that Apple controls the app store, but it's not feasible for most OSes.

You deleted the key phrase in my earlier message:

...in all the cases anyone really cares about…

Nobody really cares about the apps that can’t (or won’t) be updated.

People pretend to care about those apps, but only because it provides a convenient argument for doing what they were planning to do all along: which is to try to keep IPv4 as viable as possible, for as long as necessary, in the hopes of delaying the transition to IPv6 indefinitely. Furthermore, we pretend to take their pose seriously, because otherwise we’d have to stick our necks out and defend the IPv6 transition on its technical merits: which we long ago debauched when we decided it was perfectly okay for IPv6 to be basically nothing more than IPv4 with bigger address numbers.


--james woodyatt <jhw@google.com<mailto:jhw@google.com>>

v2.23.0 | Report a Bug | By Email