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

joel jaeggli <joelja@bogus.com> Mon, 17 July 2017 05:41 UTC

Return-Path: <joelja@bogus.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 25B05129B2E for <v6ops@ietfa.amsl.com>; Sun, 16 Jul 2017 22:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 SG7MRQXUBK7p for <v6ops@ietfa.amsl.com>; Sun, 16 Jul 2017 22:41:13 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9935F127735 for <v6ops@ietf.org>; Sun, 16 Jul 2017 22:41:13 -0700 (PDT)
Received: from dhcp-8c46.meeting.ietf.org ([IPv6:2001:67c:370:128:74fb:850e:6664:172d]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v6H5f0AT079078 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 17 Jul 2017 05:41:02 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2001:67c:370:128:74fb:850e:6664:172d] claimed to be dhcp-8c46.meeting.ietf.org
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, 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>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <9014511d-81d1-0e89-c00a-866e42ff2fdf@bogus.com>
Date: Mon, 17 Jul 2017 07:41:00 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Thunderbird/55.0
MIME-Version: 1.0
In-Reply-To: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="6s2S6ign0MEubD7apT7j5sMwwjth4Ajug"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/bo-Xh6xBqL8NADX4sGhrDNPmCkc>
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:41:15 -0000

On 7/17/17 07:24, JORDI PALET MARTINEZ 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?

That's not a serious consideration. the RF properties of the ssid are
indepedantly controlled by the access points themselves. All IETF ssids
are provided by the same sets of APs/Radios

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