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

Mark Andrews <marka@isc.org> Mon, 25 September 2017 22:50 UTC

Return-Path: <marka@isc.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 D4B761345DB for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 15:50:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 gQVwhimME0Tq for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 15:50:35 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 6AAE9124239 for <v6ops@ietf.org>; Mon, 25 Sep 2017 15:50:35 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 5409F34A07F; Mon, 25 Sep 2017 22:50:32 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 165C916007E; Mon, 25 Sep 2017 22:50:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0007116007B; Mon, 25 Sep 2017 22:50:31 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 07Fy1oAHLOp8; Mon, 25 Sep 2017 22:50:31 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 906E7160050; Mon, 25 Sep 2017 22:50:31 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DABE487DE1F6; Tue, 26 Sep 2017 08:50:28 +1000 (AEST)
To: "Heatley,N,Nick,TQB R" <nick.heatley@bt.com>
Cc: IPv6 Ops WG <v6ops@ietf.org>
From: Mark Andrews <marka@isc.org>
References: <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM>
In-reply-to: Your message of "Mon, 25 Sep 2017 11:56:21 +0000." <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM>
Date: Tue, 26 Sep 2017 08:50:28 +1000
Message-Id: <20170925225028.DABE487DE1F6@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/3tK9l4BkedZR9FnypMsNy1XQZ1c>
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: Mon, 25 Sep 2017 22:50:37 -0000

In message <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM>OM>, "Heatley,N,Nick,TQB R" writes:
> 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)

The problem with those requirement is that miss the most important
one.

	Don't do damage.

DNS64 does damage to the DNS.
NAT64 does damage to IPv6.

DNS64/NAT64 and 464XLAT externalise the cost of not upgrading the
billing software to unwrap the encapsulation.

> Thanks to esteemed Android developers putting 464xlat into Android,
> otherwise this wouldnt 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).

Just running the dual stack and a regular CGN rather than a NAT64
also achieves that as IPv6 nodes prefer IPv6 over IPv4 as the
transport.

> 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

AND you are willing to be selfish and ignore the costs you are
externalising on everyone else.

No network DEMANDS translation technology.  You could have spent a
little bit of developer time and upgraded the billing software to
understand about encapsulation.  Its a very simple concept.  Even
the most junior of developers could have done this.

> 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. Id 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org