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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Mon, 25 September 2017 16:08 UTC

Return-Path: <alexandre.petrescu@gmail.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 D03DC13448E for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 09:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 KQTLutv6fTGi for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 09:08:30 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 1847A1344D0 for <v6ops@ietf.org>; Mon, 25 Sep 2017 09:08:18 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PG8FfL043501 for <v6ops@ietf.org>; Mon, 25 Sep 2017 18:08:15 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 56B972098F2 for <v6ops@ietf.org>; Mon, 25 Sep 2017 18:08:15 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4D542209825 for <v6ops@ietf.org>; Mon, 25 Sep 2017 18:08:15 +0200 (CEST)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PG8E4o019414 for <v6ops@ietf.org>; Mon, 25 Sep 2017 18:08:15 +0200
To: v6ops@ietf.org
References: <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <b0b09e49-ad0a-4693-d4d0-1e398f244b5d@gmail.com>
Date: Mon, 25 Sep 2017 18:08:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/5uAGGB-OFdYVDDsZr08IyLcztD4>
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 16:08:34 -0000

Thanks for the study.

IMHO I agree with some points, and disagree with others.

Le 25/09/2017 à 13:56, Heatley,N,Nick,TQB R a écrit :
> 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

Excuse me, what do you mean by IPv4 private address exhaustion?

I know about IPv4 public address exhaustion.

It may be that a private exhaustion could be solved by a private IPv4 
addressing scheme exclusively, without carving the "64::/" out from 
precious IPv6.

>   * 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)

I dont know what is the 'double control plane signalling'?

In PDP Context setup one just says "type=IPv4IPv6" and it happens very 
fast.  Then there is an IPv4 address and an IPv6 address on the device.

>   * 2 consumer usecases (on the same Internet APN) to consider –
>     on-device apps (smartphone+apps), tethering
>     (smartphone+wifi-tethered device of an unknown OS)

Do you consider cars too?

Because it may be that what you can do for smartphones wont work for cars.

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

I agree, now you can tell customers to use IPv6 in all confidence, 
because IPv4 is there too.

But tell them too that's not true IPv6.  It is IPv6 with some 
INFORMATIONAL tweaks.  That's somehow a surrogate "IPv6-ready" like in 
"HDReady".

> Prefix-share + 464xlat gave the tethering use-case support.

Good, but wont work for cars, and nor for Road-Side Units, or other 
bigger moving networks.

In a car there are multiple IPv6 subnets, whereas 64share does only 1.

A Road-Side Unit connected on IPv6 cellular also uses multiple IPv6 subnets.

> The result has been rapid deployment,

Rapid deployment of a surrogate IPv6.

> meeting all the requirements,

Who set these requirements?  Is there an RFC containing these reqs?

> we 
> currently observe something like 70% of an IPv6-only devices traffic is 
> IPv6-IPv6 based (and NAT-free).

YEt it does not scale beyond that.  The only way to scale it is to sell 
more smartphones.

At the same time, you block all other devices (watches, cars, IoT) from 
connecting.

You want them all to connect to the Internet _through_ smartphones?

> 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,

_Public_ IPv4 addresses are exhausted.  It means new operators wont get 
any more IPv4.  Old big operators already have huge IPv4 space.

If there is some internal-company too many 10.s everywhere, maybe 
re-design the internal-company addressing architecture.

> - AND the provider network demands a translation technology (i.e. 
> incompatible with encaps.)

The provider network should never demand a translation technology. 
Because translation technology (and encap for that matter) is what 
actually _restrains_ the possibilities of growth in the future.

> - AND at the client end,  apps are not purged of IPv4 literals OR 
> tethering to an unknown OS is required

I dont understand?

We do want apps purged of IPv4 literals, right?

"Tethering to an unknown OS is required" - I dont know what you  mean.

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

I agree.

> Maybe it is to keep IETF relevant to the real world requirements and 
> specific usecases.

I agree.

> I’d like to see IETF do more on usecases/solution 
> context, BCPs can set the context, right?

Yes, it would be good to come up with usecases, problem statement, 
before engaging in new work.

> Maybe I can use it to help drive an IPv6-only 5G?

Good intention.  Do they (5G) have a GTP-IPv6-only version?  No 
encapsulation, just IPv6.

Does the 5G connection setup mechanism provide a /63 prefix for 
end-user?  (or is it still the same old 64 SLAAC everywhere).

Alex

> Nick
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>