IETF Logo Mail Archive

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

Erik Kline <ek@google.com> Wed, 20 September 2017 06:03 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 4D5CD1331FF for <v6ops@ietfa.amsl.com>; Tue, 19 Sep 2017 23:03:49 -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 9qguQ1DLAMBn for <v6ops@ietfa.amsl.com>; Tue, 19 Sep 2017 23:03:47 -0700 (PDT)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 606AF1331F5 for <v6ops@ietf.org>; Tue, 19 Sep 2017 23:03:47 -0700 (PDT)
Received: by mail-wr0-x22c.google.com with SMTP id g29so1184450wrg.11 for <v6ops@ietf.org>; Tue, 19 Sep 2017 23:03:47 -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=zWJf0CeTGzuf8k44n5RYEocVmFv8hf4DlVXPI225b7E=; b=CBr+CZ7VzyurOrDRYJyjtVtsYlGhMK4EOaHOgSRzmg5Bq2wAb0d6Ep6eGWetmKm+/L jG2KmIA0sMabzmOaZMRpB2h1GFrg9ui07NlW4P/Y8AUvQbEAWYLhKqMl2gvbOWsbW7fb j1bDC4V+seYzXw8fbf40dg0dEuD5kZjsiHWSTz4jwcibDGejxi9tsa6uPenpSx5TVpfi rlSOSjAvB9IeRBWH1yVw8r7nlaOzGL94nYZKhQJ7XCdmFk5Gq6Gn3MYhAVKyWWApzb3q dxIqTJJ+spBIqMG+8LGfXP/Cfj8aFXT/01nJv5AxuM9OyPrLLuoKVWPb4w3/8NiBcWcF Ne9A==
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=zWJf0CeTGzuf8k44n5RYEocVmFv8hf4DlVXPI225b7E=; b=mCIUm6ICXWFFWmLz8fMSQV/36d+A74dPRyctViAg0tAxyK+sSNQHQA14l1PLTfTaR1 JEvCmMY8VsywYHh+9KX59eo6p6nlZOAIjCAnM/Kqq7VKeAG0EU/TsmxHkMy2v4+R/EBs wkBmxhYG/JFPT9w7XHrUGtMyYJdpMXwD6PxbbAOSzkewiQjRjURm4dQ9sYYpVnj58Hnv AreGa943865a5ilVCNkrYnzDOI5iGC32Wh96KoK1y1ltXLBwLcUomeoREuk0bilFdpCE 0jAA+acTAHdCCl766/Q4+TUY+5DZ+51gnCJUrZtZyP8zs4TmnVm+2U3k9KO4yBeNOULN Qjwg==
X-Gm-Message-State: AHPjjUild1cRfeh/wpRNW83gLOLderHYHZeRBXjmyNUZPhvGpD3a5RaK bqpvv+x8Btlh/fK/4deb/Ey/+nwHiykUqUkU7beEwA==
X-Google-Smtp-Source: AOwi7QD0WgDpdaogod/ipA6Y4/aRBUU7uGZCzSROPUbbhWyaBRLx1optcK+7m8+QdFyHSBiEflUwY+lmpHZXakKbbCs=
X-Received: by 10.223.176.46 with SMTP id f43mr3594312wra.206.1505887425665; Tue, 19 Sep 2017 23:03:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.213.9 with HTTP; Tue, 19 Sep 2017 23:03:24 -0700 (PDT)
In-Reply-To: <58bb7a08-4595-f9b8-0be4-25bb471ca2db@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>
From: Erik Kline <ek@google.com>
Date: Wed, 20 Sep 2017 15:03:24 +0900
Message-ID: <CAAedzxrMk10P8g0p5=1m8rANFy6+GvkA7+SrnWLKp3Do7sY5aw@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="001a11438d5a1a3d42055998bdb7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Qs7jolpRdPSkH8TuRSpn2E2ojNc>
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 06:03:49 -0000

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

v2.23.0 | Report a Bug | By Email