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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 17 July 2017 08:35 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 9A250131AFC for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 01:35:23 -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 090kdoMlwpWm for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 01:35:21 -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 8D3DB13179D for <v6ops@ietf.org>; Mon, 17 Jul 2017 01:35:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500280518; x=1500885318; 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=dMeLF7kaccQlR5b1O9V6RLtve DGidCXYhJWVkgG7spI=; b=b7R6dBkGMHaRibsENmNGIHBjk1tDr7fP9eLOZ+/Un /4dPnyopk1j9qYZji2w/6nPkQfEK8e0LLInsfSmxhyKoL4Hw7TqEF7rjxZVFaSjf Y21fbFKTMYLZrXOk6lmdBhPWvHNpMN0xftbWlu4m4wBiKrKHlP+l0h7KtTm2Adlu p8=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Rw/PGrDOAYra/uXX6gyBBsH4jChNoV0LbcYsfalak9vLZAhfF02ey/hj5Tjt jP26p/JtP0oWVVJlWZbb4un8WbcGW+dhKGAepSuIMv4DaLez36KSLa7a7 AcnbBeYSkejFVNAgNtpSR7lH1j4bPKIBUN2Qt42UB0TnQZbhBqNItc=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:35:18 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:35:16 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478195.msg for <v6ops@ietf.org>; Mon, 17 Jul 2017 10:35:15 +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:md50005478195::hQRxyuNVGioQu93c:000007fK
X-MDRemoteIP: 31.133.142.45
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 10:35:12 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "v6ops@ietf.org" <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: <5C41328B-0B14-4605-813C-4BEADF6F53A7@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es> <CAFU7BASvuj+JrsSZzUKauBsph4hdr+ZdVjkg0_Q+00Spm5PJoQ@mail.gmail.com>
In-Reply-To: <CAFU7BASvuj+JrsSZzUKauBsph4hdr+ZdVjkg0_Q+00Spm5PJoQ@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/gOBZaeHw0OKe9pBVEGTqIbvx4_c>
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:35:23 -0000

We may need to clarify the goal here:

Is just to experiment this ? Then it has been widely done, no doubt.

Or it is to measure what apps fail? Then CLAT is a better way, as you can measure/log it automatically.
 
Regards,
Jordi
 

-----Mensaje original-----
De: Jen Linkova <furry13@gmail.com>
Responder a: <furry13@gmail.com>
Fecha: lunes, 17 de julio de 2017, 10:30
Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
CC: "v6ops@ietf.org" <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

    On Mon, Jul 17, 2017 at 3:24 PM, 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).
    
    I'm not sure I understand the logic here.
    The I-D is documenting the operational experience and actually I
    believe it would make more sense to run the experiment *before*
    finalizing the text/publish it as RFC to avoid the situation when  we
    publish an RFC on smth we have not even done yet.
    
    > 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?
    
    I believe the draft clearly states the the fallback option needs to be
    available.
    
    > 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.
    
    Actually if the fallback dual-stack network requires an explicit
    configuration on the client side (as the draft recommends) to avoid
    users connecting to it accidentally, the number of clients falling
    back to the dual stack SSID is very good data point to demonstrate
    what % of users are experiencing issues.
    
    > 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.
    >
    >         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
    
    
    
    -- 
    SY, Jen Linkova aka Furry
    



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