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

Ted Lemon <mellon@fugue.com> Mon, 17 July 2017 05:33 UTC

Return-Path: <mellon@fugue.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 1EAC212EE45 for <v6ops@ietfa.amsl.com>; Sun, 16 Jul 2017 22:33:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 AU7yVZu9V7kr for <v6ops@ietfa.amsl.com>; Sun, 16 Jul 2017 22:33:31 -0700 (PDT)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 1D63912ECC3 for <v6ops@ietf.org>; Sun, 16 Jul 2017 22:33:31 -0700 (PDT)
Received: by mail-pg0-x22d.google.com with SMTP id 123so751878pgj.1 for <v6ops@ietf.org>; Sun, 16 Jul 2017 22:33:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7gVTvD5t5CgbHu4t7EDoDncngmfdcAoAyAMljAL2/U0=; b=Q62mcBRywWOlww9vaUtnQJyTDKX4PI3J9KcM60nPFVQJyXM3alVzSW1M/fLNRSlnrg O/3919jwo61DCXc7rLRdCSOH8tMcVsAz1Dmj4JkDxm5XZcmn+se6EgmGqEEpojwjGndd t9wsGku3nObfmz/3rrnqcx9/yAcBhjzZNwfZJpfaZ+tdvkg/3UByhRcJCAVUSbP9vtU7 aCni0lYEZDe//Egg4JW+hzFN4gJFWGeeOCtvw01v0xQ43/F82Etb214iygHb+9E7UO3l 6Rs0VqVQKjdb8eXgzIVYxwuEZAwj6WNPc7T0aqQdBm90zgAVj4VG3NZ3P4DzvV9DpfFR Q/fQ==
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=7gVTvD5t5CgbHu4t7EDoDncngmfdcAoAyAMljAL2/U0=; b=Ye+Csw9FszfAHEGyeovRWKojJma+RKsBYkoudtY45KEvGoeU7hyW/nqIV46WZ7AA1/ C3uG1PIOEJaOF+ksD7bgKhgHp+1mtY98OeWD40cUROVo8LcWaqg/FQzN/LvhsHEMYH1k n5WfrkCKTzYcbswClGhslVvCEhwMtSJb55XR/UaYf+Kfvt6mcNAP7uJGKpA2ux1ZdzKy tNoG0Twdo+5fNuzJaGczstR32slsnX+QTzKqxnHw0RpbsyfPbdyV28xfyz9G/zqMuDuh JDkujcids9Yd+u2c4modrm8u1b7Y7e0BEqar8lD+jdvgUpzo2d/0antoAGc6Ib0iQYDm cG6Q==
X-Gm-Message-State: AIVw112SgrqOh0PanQyXOOOSHa2uZsFTFKif6Q5LPqdrbq3/q1RnhqPi 2+B9c5OixclyZl8fLF90mEmJCM48GAEy
X-Received: by 10.84.132.39 with SMTP id 36mr28620168ple.237.1500269610590; Sun, 16 Jul 2017 22:33:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Sun, 16 Jul 2017 22:33:30 -0700 (PDT)
Received: by 10.100.181.42 with HTTP; Sun, 16 Jul 2017 22:33:30 -0700 (PDT)
In-Reply-To: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 17 Jul 2017 07:33:30 +0200
Message-ID: <CAPt1N1kCOVZrFMMGow4nofHW_euEE3RafExQG-FAohau3D-Rkw@mail.gmail.com>
To: 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>
Content-Type: multipart/alternative; boundary="94eb2c12f71434ef0705547cbd34"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/k2m1cgkdbycHXSLliA9wpMjilIE>
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 05:33:35 -0000

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