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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 17 July 2017 06:27 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 E85D412ECF0 for <v6ops@ietfa.amsl.com>; Sun, 16 Jul 2017 23:27:56 -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 RCQJwiSAYLzr for <v6ops@ietfa.amsl.com>; Sun, 16 Jul 2017 23:27:54 -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 08D7B131562 for <v6ops@ietf.org>; Sun, 16 Jul 2017 23:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500272870; x=1500877670; 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=9uUwczod+1/TXiVY7nyFiETEA 1Y3VxEIdBEJtIA7iyA=; b=rEvQIm+8JgYF7KHBIr3R9+bnvfa6Zdygfnw/7dHwu 2ntpNMZ9m5p/nKo008x12EfMZsS0WLAxnrfJKJFPztCP4Q9U/ZIfrQM3vHhlrPSG WekC1Ghc5NJy1EwVUNTsK1ceqb8V+/ACSrIkoIDaCEqlrc54DrGC8kJnJqqo4iNR qw=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=k3BV+0YuPF+nlkoK2xd6jdQJVY5a8Xi/FgEI/vvL8ioOVjnoECM/kH3ky1oh ox8XKqwXThhGMUf+FvjsULpVARe18gcoZwT4l6x0BsQOMcelhRlNYbkik n78tR++LEsLw3ixaM2ClW3lW1fXLpDAHNypNNNsAvWH/Y1kYij6S4s=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 08:27:50 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 08:27:49 +0200
Received: from [31.133.186.43] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478024.msg for <v6ops@ietf.org>; Mon, 17 Jul 2017 08:27:47 +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:md50005478024::CREkwcIe1jTCLYfZ:00000VXA
X-MDRemoteIP: 31.133.186.43
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 08:27:45 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: IPv6 Ops WG <v6ops@ietf.org>
CC: Randy Bush <randy@psg.com>, Alissa Cooper <alissa@cooperw.in>, Russ Housley <housley@vigilsec.com>, Jim Martin <jim@daedelus.com>, Suresh Krishnan <suresh.krishnan@gmail.com>
Message-ID: <7AEAF016-007D-4A31-A03E-551008E3F7FA@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es> <CAPt1N1kCOVZrFMMGow4nofHW_euEE3RafExQG-FAohau3D-Rkw@mail.gmail.com> <BEBB7757-6F5D-44AC-8E5B-AAAF00B9EEDD@consulintel.es> <CAPt1N1njfAsmAQP-oR0X1TjykgfaN33Qs8uwU3eprn7bZ+ex8Q@mail.gmail.com>
In-Reply-To: <CAPt1N1njfAsmAQP-oR0X1TjykgfaN33Qs8uwU3eprn7bZ+ex8Q@mail.gmail.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/iyAtEtrWe-8h89lRXOTYXLc_aqs>
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 06:27:57 -0000

Not disturbing means allowing them to work transparently, and this is the target of our network. There is no reason to force “breaking” something if the target is to measure something that can be done in another way, right?

As said:
1) If we allow and ID to be experimented in our network (which is against our own rules), then it means that if somebody else tomorrow decides to write down another ID, he has the same right to ask for being experimented at the default SSID.
2) The way I’m suggesting provides even better results for analysis. I agree that is good to understand what apps will fail to survive the NAT64.
3) CLAT is also our own dogfood.

Regards,
Jordi
 

-----Mensaje original-----
De: Ted Lemon <mellon@fugue.com>
Responder a: <mellon@fugue.com>
Fecha: lunes, 17 de julio de 2017, 7:59
Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
CC: IPv6 Ops WG <v6ops@ietf.org>, Randy Bush <randy@psg.com>, Alissa Cooper <alissa@cooperw.in>, Russ Housley <housley@vigilsec.com>, Jim Martin <jim@daedelus.com>, Suresh Krishnan <suresh.krishnan@gmail.com>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    "No disturbing the participants" means we aren't dogfooding.   That's what dogfooding means: you try to use the dog food.  If it's not nutritious, then you go back to the cat food, but you start with the dog food.   Even if you are only dogfooding for ten minutes before you run into a problem that requires you to switch to the legacy network, that's a win, at least if you report the problem.
    
    On Mon, Jul 17, 2017 at 7:44 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
    
    What I’m saying is that using CLAT, you also have dogfooding, but no disturbing any participants and allowing then to keep doing the work. Some of us get paid only if we finish our work on time!
    
    I always understood that the IETF network is not for experiments. If we allow this, it means we are changing our policy from now on?
    
    I recall previous occasions where it was clearly said that if an experiment is going to affect other participants, it can’t be done.
    
    As said, do the same with CLAT so participants aren’t affected and at least wait until the document is an RFC.
    
    I’m pro-IPv6, I’m sure nobody doubts that, but work is first, rules as well.
    
    Regards,
    Jordi
    
    
    -----Mensaje original-----
    De: Ted Lemon <mellon@fugue.com>
    Responder a: <mellon@fugue.com>
    Fecha: lunes, 17 de julio de 2017, 7:33
    Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
    CC: Alissa Cooper <alissa@cooperw.in>, Suresh Krishnan <suresh.krishnan@gmail.com>, <v6ops@ietf.org>, Jim Martin <jim@daedelus.com>, Randy Bush <randy@psg.com>, Russ Housley <housley@vigilsec.com>
    Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
    
        Fwiw, I have found and fixed lots of problems as a result of using the ietf-nat64 network. It is probably still try that some participants would have trouble on that network, so there should be a legacy network for them. But the default should be nat64. Dogfooding is really important. If you have broken apps, feeling a little pain is a great way to motivate complaining about it to the vendor.
    
        On Jul 17, 2017 7:26 AM, "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es> wrote:
    
        In my opinion such kind of experiment should be only done once we approve the document as RFC, note before, so by the next IETF meeting (hopefully).
    
        We like it or not, this is not a valid option, unless we make sure that if some participants have troubles, the alternative SSIDs have other 2.4 and 5 GHz radios available. Is that the case?
    
        The unfortunate reason this doesn’t work is that, still there are MANY apps that use literals or old APIs, that don’t work with NAT64.
    
        As I explained before, if the goal is to detect and test them, this can be done by using a “CLAT” network (464XLAT) in the default SSID, and then having an automatic logging of what apps/destination IPs), are using the CLAT.
    
        Those using IPv6 are fine, those using just the PLAT (NAT64+DNS64) are also fine.
    
        The result is the same as you’re proposing but non-intrusive and with the advantage of an automated logging of the failures.
    
        The way you’re proposing, will mean that many folks may switch to alternative SSID, or simply don't report those failures, so at the end you don’t have any results of how much is not working, etc.
    
        Regards,
        Jordi
    
    
        -----Mensaje original-----
        De: v6ops <v6ops-bounces@ietf.org> en nombre de "Brzozowski, John" <John_Brzozowski@comcast.com>
        Responder a: <John_Brzozowski@comcast.com>
        Fecha: lunes, 17 de julio de 2017, 6:23
        Para: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org" <draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org>
        CC: Jim Martin <jim@daedelus.com>, Alissa Cooper <alissa@cooperw.in>, Russ Housley <housley@vigilsec.com>, Randy Bush <randy@psg.com>, Suresh Krishnan <suresh.krishnan@gmail.com>
        Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
    
            Folks,
    
            Apologies in advance for the gratuitous cross posting (v6ops, ietf, ipv6, sunset4, softwires).  I hope, to you all, this is worth the added email.
    
            The draft below was written to provide the necessary documentation to enable the IETF (the NOC, participants, etc.) to migrate to an IPv6 only primary network connection (Wi-Fi and wired) that utilizes NAT64+DNS64 to access IPv4 only content.  The request for IETF 99 has been to have the primary “ietf” SSID adhere to what is documented in the I-D below.  I trust the motivation is understood.  This means that the main “ietf” SSID would be switched to be IPv6 only with NAT64+DNS64 (at layer 3) per the I-D below.  Given the that IETF99 is upon us, this may or may not be entirely possible.
    
            At this stage, the infrastructure preparations for IETF 99 should be in place to ensure that the IETF has the necessary hardware for redundancy and performance.
    
            So, we are all seeking your input.  Given the above, what would all you suggest is tolerable for IETF99 as it pertains to the I-D below?
    
            • IPv6 only per the I-D for the balance of IETF week?
            • IPv6 only per the I-D for one or more days this week?
            • IPv6 only per the I-D for the plenary?
            • IPv6 only per the I-D for the next IETF meeting?
    
            Please send us your feedback.
    
            Regards,
    
            John
            +1-484-962-0060
    
            -----Original Message-----
            From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
            Date: Saturday, July 1, 2017 at 03:04
            To: Marcus Keane <marcus.keane@microsoft.com>, Jen Linkova <furry@google.com>, Lorenzo Colitti <lorenzo@google.com>, John Brzozowski <John_Brzozowski@Cable.Comcast.com>, Erik Kline <ek@google.com>, John Brzozowski <John_Brzozowski@Cable.Comcast.com>, David Schinazi <dschinazi@apple.com>, Stuart Cheshire <cheshire@apple.com>, Jen Linkova <furry@google.com>, Paul Saab <ps@fb.com>, David Schinazi <dschinazi@apple.com>
            Subject: New Version Notification for draft-jjmb-v6ops-ietf-ipv6-only-incremental-00.txt
    
    
                A new version of I-D, draft-jjmb-v6ops-ietf-ipv6-only-incremental-00.txt
                has been successfully submitted by John Jason Brzozowski and posted to the
                IETF repository.
    
                Name:           draft-jjmb-v6ops-ietf-ipv6-only-incremental
                Revision:       00
                Title:          Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
                Document date:  2017-06-30
                Group:          Individual Submission
                Pages:          15
                URL:            https://www.ietf.org/internet-drafts/draft-jjmb-v6ops-ietf-ipv6-only-incremental-00.txt
                Status:         https://datatracker.ietf.org/doc/draft-jjmb-v6ops-ietf-ipv6-only-incremental/
                Htmlized:       https://tools.ietf.org/html/draft-jjmb-v6ops-ietf-ipv6-only-incremental-00
                Htmlized:       https://datatracker.ietf.org/doc/html/draft-jjmb-v6ops-ietf-ipv6-only-incremental-00
    
    
                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.
    
    
    
    
                Please note that it may take a couple of minutes from the time of submission
    
    
                until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> <http://tools.ietf.org>.
    
                The IETF Secretariat
    
    
    
    
            _______________________________________________
            v6ops mailing list
            v6ops@ietf.org
            https://www.ietf.org/mailman/listinfo/v6ops
    
    
    
    
        **********************************************
        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.
    
    
    
        _______________________________________________
        v6ops mailing list
        v6ops@ietf.org
        https://www.ietf.org/mailman/listinfo/v6ops
    
    
    
    
    
    
    
    
    **********************************************
    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.
    
    
    
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
    
    
    
    
    
    
    
    



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