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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 17 July 2017 09:06 UTC

Return-Path: <prvs=13714351ed=jordi.palet@consulintel.es>
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 13C96131771 for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 02:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
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 SGEiOFh4qfXv for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 02:06:39 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C23312EB5F for <v6ops@ietf.org>; Mon, 17 Jul 2017 02:06:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500282397; x=1500887197; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=24I0KE9N5Ah7Tv7CV/nWUYcLG Qxc5LKC+BSNuFgBZKQ=; b=OFhnbd+aUp01m50hf1RnYY3l1zpCQ97xfkMAxgR5L QaZKXQFDNMiUWwWbGVkEkflt4q8zedfILxXOPpeC1BycnUg76C8/sCG1eFMvG2lI hVhKbRuuw9COlqGBqmM/MgzvQGHheAb9AEPFTm2wPUEtMUZHmh8RheRHFUD9Dhnq Rc=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=uShTX1L8GB0gPU0qAqR1qMTSk6ljz3uifV+idKdhRRtxpsCof+bqEZhnbcyp vVimniEWUWScIun6wXEU3MdvyrhuqfDMi5C8PUitBGutHrf5zd8u3TG38 qpd5MPfyrgdBU/bfuUrjuI3KhnSSwoFAOlKZczq6Il++NsyuISJ41g=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 11:06:37 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 11:06:36 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478233.msg for <v6ops@ietf.org>; Mon, 17 Jul 2017 11:06:34 +0200
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:170717:md50005478233::1WyyhOHyWQTaXmNq:00002ulH
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 11:06:27 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: IPv6 Ops WG <v6ops@ietf.org>
CC: 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: <DBA0F1A7-17FE-41E0-8DAC-52FF5D62DECD@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
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> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com>
In-Reply-To: <20170717105929.5a6b7997@echo.ms.redpill-linpro.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/m-P8UMswVkAJclnir-S9WnbK24g>
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 09:06:41 -0000

Yeah, I read the draft and provided inputs.

And I understand what you’re saying however, not all the OSs have CLAT by default, it doesn’t work for us, and even less for end-customers.

I don’t think Apple has anything similar, just they mandated for iOS (smartphones), to have all the apps with IPv6 support, but is not the same for the laptops.

The last IETF I got a /64 prefix delegated by the NOC to my computer and I was running a VM with a CLAT daemon. All worked fine, but it requires the NOC to delegate me a prefix and have the VM running, which is not practical for every participant. Doing the same having the CLAT in a VM in the NOC itself, works for all.

Regards,
Jordi
 

-----Mensaje original-----
De: Tore Anderson <tore@fud.no>
Responder a: <tore@fud.no>
Fecha: lunes, 17 de julio de 2017, 11:00
Para: 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>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    * 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
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.