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

Erik Kline <ek@google.com> Wed, 20 September 2017 13:17 UTC

Return-Path: <ek@google.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 042AA13214D for <v6ops@ietfa.amsl.com>; Wed, 20 Sep 2017 06:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.504
X-Spam-Level:
X-Spam-Status: No, score=0.504 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_MILLION=2.505, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 wxnlr3SCq7Pv for <v6ops@ietfa.amsl.com>; Wed, 20 Sep 2017 06:17:52 -0700 (PDT)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512D51331E7 for <v6ops@ietf.org>; Wed, 20 Sep 2017 06:17:52 -0700 (PDT)
Received: by mail-wr0-x230.google.com with SMTP id l22so2154598wrc.10 for <v6ops@ietf.org>; Wed, 20 Sep 2017 06:17:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vx0OhNEFlBUmYR3wUHBZoiUYgGD/BeOkXSsuZm7AVvA=; b=tVOY5rz0LIAUAHOyO3QyVFJbbtJWOOQzw32qH2vBBfgX1fxOQlinxttSpWcwAuvZVj NrJTndyaHQU1MHi5KGBvMWll0/bpdRIoETAVu2NeQRMjBXKfmPo1p7nRLPNZBG8JUjEw Bu86gtXBuLJg3NKARNK7ZdIwtAY4Ml8Kcqi6DQDCHmvONpeLSImL0FhQoxGtJxEJYHSq xfwVAEgsJI7KJSV7nXyQRSeDgU/FD2Rsjkl7LflrJJ1kikELQiI3I+RYc46uwMfCh6ay W651ozGrlac04sZcx6gMCzoCOzNz3hYaKipjUUfLGk7ocFJnvK6nkzQlLjKjFT9swVpf dsEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vx0OhNEFlBUmYR3wUHBZoiUYgGD/BeOkXSsuZm7AVvA=; b=MD2UI+jGatGy1xUQD0QIeFMq9afsOIpBChAebcnzshQRgC93qY+x0p6PX2ip1X4bFN p6JCSe08n0k8B1LJOVZqusvLfYT/JbrylQ4CeIxh1XRSnHEFdvCDo1QVhBk0MfmJOaTx iduzpnpwYpIyGHgckXwPndbsiMmeKHXfxEs35oCxyk7oIVl2Ggyt/AvSZDj97rbCx58m 1Rrk2xaYM/Mq2z9Y6Yj0nfY2Q397a/6ieshNeyHep6Rrltaw5E7pu6zeAM17E8MmCWfz U6n6XcQM3VptVT5bQFttKIVCegPER/lyisjlrWWNSWpfsI9BAGMddooJoL9PH/90qGk4 g04w==
X-Gm-Message-State: AHPjjUhFWoqjPkAaKAAB0h3Be9I8x51B+1Nzw5zAOKIkQ7VdgjaHKqvG vicf+4IgJwavZ3/J73gsYjh+1uXsmczRylxn0zkmiA==
X-Google-Smtp-Source: AOwi7QB2225gAUG0En0KV0pT/+cMpwsdnN04+bUWqUSH673b+E+/F2jhi+rU09jrPfiaOrFx3BCQyi3e7s1KsXiyOIE=
X-Received: by 10.223.176.46 with SMTP id f43mr4847113wra.206.1505913470401; Wed, 20 Sep 2017 06:17:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.213.9 with HTTP; Wed, 20 Sep 2017 06:17:29 -0700 (PDT)
In-Reply-To: <d441f1cd-7b22-f94f-1fe2-4b12ab47ae21@gmail.com>
References: <C1017FAF-91C3-4CA3-89C2-B64FF5100E41@consulintel.es> <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <C33DB89E-C005-4A32-9066-C8EE710F3255@consulintel.es> <b16c4ca2-da97-9a5a-0f88-6388ebbda80e@gmail.com> <B9C2822F-56EE-47D8-AAB5-C041A3D22F41@gmail.com> <f23854dd-0952-eedb-802b-8506dc111da7@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <CAAedzxrMk10P8g0p5=1m8rANFy6+GvkA7+SrnWLKp3Do7sY5aw@mail.gmail.com> <d441f1cd-7b22-f94f-1fe2-4b12ab47ae21@gmail.com>
From: Erik Kline <ek@google.com>
Date: Wed, 20 Sep 2017 22:17:29 +0900
Message-ID: <CAAedzxpT3iTTGOs+xp7=auxREYNKBEdRuqkpK6RzuJxwTO_SOQ@mail.gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: Fred Baker <fredbaker.ietf@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="001a11438d5a80407705599ecdb6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/OFTwkei1y6lHKmmrIli40RdiQkI>
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: Wed, 20 Sep 2017 13:17:54 -0000

https://android.googlesource.com/platform/external/android-clat/

On 20 September 2017 at 21:54, Alexandre Petrescu
<alexandre.petrescu@gmail.com> wrote:
> No need to stress terms like billions; that's what modem manufacturers put
> on the market too routinely.  Maybe we can talk trillions of IoT devices.
> Maybe we can use the SI prefixes, like exa, or peta.
>
> That aside, I would like to ask you whether the CLAT src on Android is
> something I could look at?
>
> Alex
>
>
> Le 20/09/2017 à 08:03, Erik Kline a écrit :
>>
>> There seem to be some misconceptions flying around here.
>>
>>> Well, I dont think 464XLAT is deployed anywhere else than on cellular.
>>> These
>>> are the big numbers that the Original Poster talked about: miliions of
>>> users
>>> - they are on cellular.
>>
>>
>> 464xlat is a client-side bit of code (the NAT64+DNS64 in the network
>> is the "other half").  It is primarily implemented in mobile devices,
>> and primarily in Android, to be more specific.
>>
>> As such, the number of 464xlat capable nodes is numbered in the
>> /billions/.
>>
>> There are also some wifi (and wired) networks that are IPv6-only with
>> NAT64+DNS64; mobile networks aren't the only ones.
>>
>> NAT64+DNS64 is easily the single most successful IPv6 transition
>> technology on the planet ([a] if one excludes "dualstack", [b] queue
>> the Sean Spicer jokes).  464xlat can help ease things on the client
>> side, but it's not the only way to do it (cf. iOS).
>>
>