IETF Logo Mail Archive

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

"Heatley,N,Nick,TQB R" <nick.heatley@bt.com> Mon, 25 September 2017 11:56 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 188411342D0 for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 04:56:30 -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 5CX4bMIiqoNw for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 04:56:27 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D052B1332E3 for <v6ops@ietf.org>; Mon, 25 Sep 2017 04:56:26 -0700 (PDT)
Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 25 Sep 2017 12:56:46 +0100
Received: from smtpe1.intersmtp.com (10.187.98.11) by EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 25 Sep 2017 12:56:23 +0100
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (213.199.154.208) by smtpe1.intersmtp.com (62.239.224.235) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 25 Sep 2017 12:56:23 +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=bBp+RFu5W+KlwyTtKiIBVKEVUGNDsCqrwV1CLndQhGo=; b=Sq0EcXv4TvXxo5F0ExNtLyElEEZWgx9tpaukCQJAsI/cTHldQxj7xOj1f80IOINxTUm5ar9jaEEStc4IYwyDWTdoWsaUyLhLLLQeTaL815QV2P1P4bIvF9qLQCayfR1wfPRZxKi8SalcxrYN35n4w+I7q7QXSOJv5NBHfGnfb3I=
Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM (10.167.24.147) by LO1P123MB0913.GBRP123.PROD.OUTLOOK.COM (10.167.26.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 25 Sep 2017 11:56:21 +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.011; Mon, 25 Sep 2017 11:56:21 +0000
From: "Heatley,N,Nick,TQB R" <nick.heatley@bt.com>
To: IPv6 Ops WG <v6ops@ietf.org>
Thread-Topic: 464xlat case study (was reclassify 464XLAT as standard instead of info)
Thread-Index: AdM16ZBiVXxOrrPASdi8hSWu5DH/5g==
Date: Mon, 25 Sep 2017 11:56:21 +0000
Message-ID: <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PROD.OUTLOOK.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: [77.97.239.204]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; LO1P123MB0913; 6:kf9athaEcGTGfglZgpPo614cUdKAE/Qpr6NQVoFTE2LPH5Vi2osFW4+d8K1/f3xC6G85hX5RLj/uMHYA01wRLzZtZImbvBhAkq5Oz4wKGhaqTJEYwurXnNFn3ZIRACllei9qZnHzYLrxVFWOU1uM7IqWC4VaYvZgK3TL4/4gAFNzHYFs00fnOxujctkE66xiDobO8Pa8UOjzCnGoS5Z5U7sqa1/O/IJ0SfuA70+fZ53IwpD5uSCOjnktlIKdjahoRW7soQqDqR397hgDRZNhw8UZ8FTGefDR3SdZ00qxbeKRpGcB1kaRMLnSZtHH+eMJGlcYWXF9ehwAv8BeoLpXGw==; 5:R5JQPKw3TzQDOBGhfJsAN6ETtvBod/j/Ze0Z09/HyqJ0ftMjwWTCJemkUaiz5sYLLiirlHyAcFmMSHUO423MwxrXGWsYppblkLV2EohP9qRbjlVY8SN1gJZYBSXMP1z7j7mFo9bkuwq2qVpZwATvSw==; 24:cEbS2JjJ7SlxMyzgHlItGgj1oadD5dclEKYGvfReSGljJAiHT+nESLoHAyRih8DAbv1ZyS8NSTnldW7kfUm67JXlOjYN98MWWxZMWMoPTEU=; 7:PBoy/YaKp1z5VltrPoM8Oage8aUjrVz5TEdDoTrs1yeYkrz5q9A2KaOaX1TkD/4yzikLGDQ3sGrCTCQbY8wzQb7w4Xjv+C5cI8S2XifyVsWWuKsb02svDuFfqJRC4Mk6F00HiK7bS8001J7JwtVKEtzT8rNbPP0UEbPPS5s0X2pFVx8m+X7wqxGqrLrrAHj1syklEOq2mqqOmCC6EFj0k7ARkVpxEv5NybhlJr9WBwU=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 307c97dd-1ce0-4efe-62d8-08d5040c70a7
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:LO1P123MB0913;
x-ms-traffictypediagnostic: LO1P123MB0913:
x-antispam-2: 1
x-exchange-antispam-report-test: UriScan:(190756311086443)(21748063052155);
x-microsoft-antispam-prvs: <LO1P123MB09135C6E9784C7AF42106E34EA7A0@LO1P123MB0913.GBRP123.PROD.OUTLOOK.COM>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:LO1P123MB0913; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:LO1P123MB0913;
x-forefront-prvs: 04410E544A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39830400002)(199003)(189002)(3846002)(102836003)(5660300001)(6116002)(74316002)(25786009)(106356001)(105586002)(790700001)(2906002)(6916009)(97736004)(9686003)(2900100001)(54896002)(8936002)(8676002)(55016002)(86362001)(81156014)(6306002)(3280700002)(3660700001)(81166006)(6506006)(189998001)(33656002)(101416001)(6436002)(77096006)(7736002)(316002)(53936002)(7696004)(54356999)(50986999)(68736007)(66066001)(14454004)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:LO1P123MB0913; H:LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_LO1P123MB01168388285206BB7C26F029EA7A0LO1P123MB0116GBRP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2017 11:56:21.7836 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO1P123MB0913
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/3HjN64RkFgBU4c3ChhFtmZ5-vrE>
X-Mailman-Approved-At: Mon, 25 Sep 2017 08:19:37 -0700
Subject: [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: Mon, 25 Sep 2017 11:57:14 -0000

There are no arguments about architecture, there are only arguments about requirements.

Here is my case study on NAT64/DNS64/464xlat.
My requirements:

  *   A solution for multi-million numbers of consumer nodes (smartphones)
  *   Mitigate IPv4 private and public address exhaustion
  *   Encapsulation is not compatible with the core of 3GPP mobile networks – only translation is “Core & Service-LAN friendly”.
  *   Keep the provider network simple – the overhead of two address families per customer in the mobile core is undesirable (as it doubles the control plane signalling)
  *   2 consumer usecases (on the same Internet APN) to consider – on-device apps (smartphone+apps), tethering (smartphone+wifi-tethered device of an unknown OS)

Thanks to esteemed Android developers putting 464xlat into Android, otherwise this wouldn’t have happened.
DNS64/NAT64 did not get put into production until 464xlat appeared on Android.
I had zero IPv6 clients until 464xlat, IPv6 was insufficient without it.
Prefix-share + 464xlat gave the tethering use-case support.

The result has been rapid deployment, meeting all the requirements, we currently observe something like 70% of an IPv6-only devices traffic is IPv6-IPv6 based (and NAT-free).
I have a good amount of internal mobile core traffic that is IPv6-only (the combination of IPv6-only IMS APN for VoWifi and VoLTE, and this internet APN).

So this is my opinion: 464xlat is the currently the adopted approach when:
- IPv4 addresses are (near) exhausted for the mass-market,
- AND the provider network demands a translation technology (i.e. incompatible with encaps.)
- AND at the client end,  apps are not purged of IPv4 literals OR tethering to an unknown OS is required

What is the point of seeking BCP for 464xlat? I am not entirely sure.
It should not be to try to select Apple vs Android approaches, I want to see both approaches successful.
Maybe it is to keep IETF relevant to the real world requirements and specific usecases. I’d like to see IETF do more on usecases/solution context, BCPs can set the context, right?
Maybe I can use it to help drive an IPv6-only 5G?
Nick

v2.23.0 | Report a Bug | By Email