Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

Tore Anderson <tore@fud.no> Mon, 17 July 2017 08:59 UTC

Return-Path: <tore@fud.no>
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 1C54512EA7C for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 01:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 aJRB_9KvOliw for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 01:59:33 -0700 (PDT)
Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 BCE8D126E3A for <v6ops@ietf.org>; Mon, 17 Jul 2017 01:59:32 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=50650 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <tore@fud.no>) id 1dX1sH-0000wg-T6; Mon, 17 Jul 2017 10:59:29 +0200
Date: Mon, 17 Jul 2017 10:59:29 +0200
From: Tore Anderson <tore@fud.no>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
Cc: IPv6 Ops WG <v6ops@ietf.org>, Jim Martin <jim@daedelus.com>, Russ Housley <housley@vigilsec.com>, Suresh Krishnan <suresh.krishnan@gmail.com>, Alissa Cooper <alissa@cooperw.in>, Randy Bush <randy@psg.com>
Message-ID: <20170717105929.5a6b7997@echo.ms.redpill-linpro.com>
In-Reply-To: <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es> <CAEqgTWYOe=jWp=zVZNLx6DjKjNpPTYaq2jmjryudrGZHKZNq6g@mail.gmail.com> <A5D0385C-F755-4B44-86D8-6E618E77193F@consulintel.es> <CAPt1N1kroh2cPkTr8HRfNjLTdG0hkC1oQsUZdhQzQA5tA9-xug@mail.gmail.com> <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es> <CAPt1N1kU4cpVCsp7W3XNAZupYqjTWVH+BNp9bwtznnWD_uP2oQ@mail.gmail.com> <CAEqgTWZzZW0wKggDXjY=-aMfDxzd5-GoRqju1829XwY3aHQuYg@mail.gmail.com> <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/WW3q_sZ8IpQ7KXOPHtMPLLX7Xo8>
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
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, 17 Jul 2017 08:59:34 -0000

* JORDI PALET MARTINEZ <jordi.palet@consulintel.es>

> However, we have different ways for doing the same, and we should go
> for the one that has less impact and it is more realistic.
> 
> In the real world, you will not disable IPv4 in the LANs of end-users
> or enterprise customers (at least not now, may be in 3-5 years from
> now). 

Jordi,

Did you even read the draft? It is quite clear in its recommendation to
provide IPv4 Internet connectivity to be provided through a NAT64/DNS64
service. Quoting from the abstract:

   The purpose of this document is to provide a blueprint and guidance
   for deploying IPv6-only Wi-Fi at IETF meetings.  This document
   outlines infrastructure and operational guidance that operators
   should consider when deploying IPv6-only networks **using NAT64 and
   DNS64 to support communication to legacy IPv4-only services**.

(Emphasis mine.)

> This is what IETF need to test now. IPv6 only with IPv4 as a service
> (which is 464XLAT).

Precisely. The existence of NAT64/DNS64 should in turn automatically
facilitate usage of 464XLAT.

Host operating systems that implements the CLAT component of 464XLAT
(e.g., Android or recently updated Windows 10) should be able to simply
activate it. While Apple doesn't implement 464XLAT per se they have
something similar, so they should be covered too.

There is more discussion about IPv4 backwards compatibility, including
a mention of 464XLAT, in section 4.2 of the draft.

Tore