IETF Logo Mail Archive

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

Erik Nygren <erik+ietf@nygren.org> Mon, 17 July 2017 16:26 UTC

Return-Path: <nygren@gmail.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 2F2CC131CA8 for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 09:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=gmail.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 Dkmp8GFjqVPM for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 09:26:00 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 B6C73128BC8 for <v6ops@ietf.org>; Mon, 17 Jul 2017 09:26:00 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id d136so12132018qkg.3 for <v6ops@ietf.org>; Mon, 17 Jul 2017 09:26:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fwtxUEjq3y5fpkSQEVMk6m5Mth/BiXZCQ9xrhKFgk0c=; b=f3HASZa8pNLGcrcLJjuVLCBWqBnxAGDuhnDvfpAFyEbpABhB/rSCUPybphgVuu0Quy kTkG/gP3+lpFtRS8aN4nWWrMJPMWJD6okcReUW8dlMHMO1vvNXhnl9vtBzik93JRjZgm iYLkmJN3H7AhqPO4p19q4KhlidY7cLZxEUwFNgITl/Eugk2xitwjpt+KFD00goVz53R2 xk1uWfwVSg1pqD4C8Of7k5iC3M3u96pdifJho8BJwBCALkX/3sgz7qsOmeBXe3c4ZeO5 McJn0S9n4vE1avC2JR+zL40pX3XTEC1neKT4WDPKq3xiVb8VjmNlOOCK6eqfbX35Icm6 oGPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=fwtxUEjq3y5fpkSQEVMk6m5Mth/BiXZCQ9xrhKFgk0c=; b=fBnY3xDwApH0L5u6HjpOhJbvZCA2nVa1wy78rR0XQBS3xgKT/m6eAXnlcwZrTV/Cgb +AXgVxD6pM3CxoLBlmmaIGLyfQBqlNZwYc3mMaKQriJ4KF3Toqm5vCpYDIGE5467Qi5W EQVjssGEvDHpfGthYKBbrIuv5J3fAgM0fDsJIzp86s61LX3eIDzB0wkpvByAWblkAuPw KpbewwFFD77HVcxJaL9I9qL/f17F8t+S+IZSRwKzWyMPHS6s1wphbYgR2cybKGHNeoaY XeGHIoCNBLQl49qPffS45A+0UDBdzXiBJ69GVQnGw8ErpQoGYEKJ+RZyBGi6XB7y069k /Cnw==
X-Gm-Message-State: AIVw111PTEcgGnSu+bRMIk5iM9Y5J2zYBGIAzoL1yppgn3zDsc3dfsJ2 /YyymeES7GxGFju7raoPILTk1OkX0A==
X-Received: by 10.55.33.195 with SMTP id f64mr28417705qki.208.1500308759785; Mon, 17 Jul 2017 09:25:59 -0700 (PDT)
MIME-Version: 1.0
Sender: nygren@gmail.com
Received: by 10.12.169.25 with HTTP; Mon, 17 Jul 2017 09:25:58 -0700 (PDT)
Received: by 10.12.169.25 with HTTP; Mon, 17 Jul 2017 09:25:58 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.02.1707171636110.29742@uplift.swm.pp.se>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@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> <CAFU7BARahTfH_Uy_t22EthGuFMJ=q-N1zxismNAVkHWWJA-Obw@mail.gmail.com> <CBA23B1B-C5A3-413C-B399-93F537C99015@consulintel.es> <CAFU7BARz_u92NweYkTizT2=q420sBRh11m9bqWO9+aexCi3ANA@mail.gmail.com> <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es> <CAFU7BASrxoroJVHwxFpwwBxCUC62_VZXsUGgfDOj6y+KVWk6tw@mail.gmail.com> <C510C095-B9AB-432F-A050-FD9CD640A6DE@consulintel.es> <CAFU7BAR413hwY_G2Cw-Ab+J158udPDLSFo==EN4LHjWb_YzD5Q@mail.gmail.com> <10FFC885-81E1-45E6-B87D-5520C35FDE2C@consulintel.es> <alpine.DEB.2.02.1707171636110.29742@uplift.swm.pp.se>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Mon, 17 Jul 2017 12:25:58 -0400
X-Google-Sender-Auth: kCs0ta8y_U-_aJHnCbB72FLAZec
Message-ID: <CAKC-DJg1ZAVDM+npKQQ5yY2raN6DH_HEVssRhhteGZGsMspOfw@mail.gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: IPv6 Ops WG <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="001a11401636ae356d055485da45"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/qsTAJA9NDp3YT5uP19ZyD3jIHYw>
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 16:26:03 -0000

I'll add to the list of problems I run into on the NAT64 network:  VPN with
split tunnelling and DNS sent through the VPN means the DNS64 gets
bypassed. I assume the same would hold true of clients overriding the
advertised DNS servers (eg, using Google DNS).

A local CLAT helps.  Ideally VPNs doing split tunnelling could be made
DNS64/NAT64 aware.  And apps being clever enough to do their own DNS should
ideally also resolve ipv4only.arpa via the system resolver to do their own
DNS64 synthesis.

- Erik.  (Torn on which ietf we start this with...)

     [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]

On Jul 17, 2017 9:42 AM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:

> On Mon, 17 Jul 2017, JORDI PALET MARTINEZ wrote:
>
> So the dogfood that we need to try (now) is the one that can sever the
>> “real” market, not the one that could serve the marked when they are ready
>> to replace (in a big %) all the apps and devices that are IPv4 only. We
>> could try this in a follow up phase (actually there is an SSID for that
>> already).
>>
>
> My android and iOS devices work great on IPv6 only using the proposed
> suggestion. My MacOS and Windows do not (because they don't have the
> 464XLAT or bump-in-the-API that is available on the mobile platforms). I
> already know this. I don't need to prove it to anyone.
>
> It's premature to go IPv6 only on the main wifi before main operating
> systems support the same mechanisms available on the mobile devices.
>
> 1. My "mosh" session only tries the same AF that it initially connected
> to. If I initially connected on an IPv4 network, it will never connect to
> anything on an IPv6 network.
>
> 2. My Windows VM which needs to reach IPv4 only resources have no way to
> do this through the Parallels NAT44. I would need a CLAT for this.
>
> There are lots of desktop OS applications that do not work on IPv6 only
> DNS64+DNS64 without CLAT. I have tried this, it doesn't work, there is no
> need to do wider test. OS vendors need to implement CLAT (or equivalent)
> for it to be viable.
>
> If the main wifi is going IPv6 only, I will run my mobile devices on it,
> but I will immediately swap to the dual stack SSID for my computer.
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

v2.23.0 | Report a Bug | By Email