IETF Logo Mail Archive

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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 17 July 2017 09:41 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 9569912EBFA for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 02:41:36 -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 8qvb5cKNuVIg for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 02:41:34 -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 6CD141315FF for <v6ops@ietf.org>; Mon, 17 Jul 2017 02:41:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500284489; x=1500889289; 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=+78Kgd7PnftQsP2LZtUOeCWsW WmP0RZ9Ixw4Av7FBbU=; b=bG75OJHQe31ON4lv4UPKPI4Lts2k9SCqmg1Vy6U2E YOFOv3YU7r28gQ5iP+etjfkkN4hB5P82PwlR+AIbpI8d4EUI3icpT0lqbVXHRPad YJPTNspIAY+e0f6kuuxpUTWWGudXiXFrzo+dRRKdYKsxaXeGm1MADmc86W2br0ub fs=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=S6b8c8S5TfjW0MvTLt416e2CAYrMctucuiMEnzz60YQ+ADGDnfdxiLyybnN7 7TRVOg6mM6AoCtSiT8nYdqC1j9WPxEnxgE50BIZi8RVDxbsnELsGBBWEk 0yln4F29G2bLLdD4n7n+7h4aex+ElTNvOMJJjKc3aJvCJSPFN5isKM=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 11:41:29 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 11:41:27 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478284.msg for <v6ops@ietf.org>; Mon, 17 Jul 2017 11:41:26 +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:md50005478284::/C0iCxdFgex8tdwk:00004GS+
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 11:41:20 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: IPv6 Ops WG <v6ops@ietf.org>
CC: Randy Bush <randy@psg.com>, Russ Housley <housley@vigilsec.com>, Alissa Cooper <alissa@cooperw.in>, Jim Martin <jim@daedelus.com>, Suresh Krishnan <suresh.krishnan@gmail.com>
Message-ID: <D0BB59E5-90DB-4930-92B3-6AC7E0AF7391@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es> <CAEqgTWYOe=jWp=zVZNLx6DjKjNpPTYaq2jmjryudrGZHKZNq6g@mail.gmail.com> <A5D0385C-F755-4B44-86D8-6E618E77193F@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> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com> <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com>
In-Reply-To: <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.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/bgRZTpQi8jAqxncV4QlPWTKWVmk>
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 09:41:37 -0000

I’ve investigated this with OpenVPN right now using the ietf-nat64 SSID.

The remote OpenVPN server is IPv4-only, has a domain name (so not using literals), however, it seems the name is resolved to the IPv4-only address (maybe not using Apple Sierra OS – latest version- all updated- system APIs), so it fails to work with the NAT64.

I’m sure there are many other apps that have the same problem, it is very unfortunate, I wish programmers do it right and use the systems APIs (and no literals) that make it work, but this is not the case in the real world.

The point here is again: Manually asking the participants that get something broken to report it, doesn’t work, while having an automated way to report what is using the CLAT is a much lower effort (actually none for the participants).

The result, if we do this experiment with NAT64, is that everyone requiring “any” app breaking with NAT64, is going to switch to the dual-stack SSID, so we will not get reports for “other” broken apps from those participants.

Is this what we want? Or we prefer to have as many reports of broken things as possible?

I guess many folks use OpenVPN, so it may be the case that many have the same problem. May be it happens the same with other VPN apps.

Regards,
Jordi
 

-----Mensaje original-----
De: <dschinazi@apple.com> en nombre de David Schinazi <dschinazi@apple.com>
Responder a: <dschinazi@apple.com>
Fecha: lunes, 17 de julio de 2017, 11:07
Para: Tore Anderson <tore@fud.no>
CC: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, Randy Bush <randy@psg.com>, IPv6 Ops WG <v6ops@ietf.org>, Russ Housley <housley@vigilsec.com>, Alissa Cooper <alissa@cooperw.in>, Jim Martin <jim@daedelus.com>, Suresh Krishnan <suresh.krishnan@gmail.com>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    
    > On Jul 17, 2017, at 10:59, Tore Anderson <tore@fud.no> wrote:
    > [...]
    > Host operating systems that implements the CLAT component of 464XLAT
    > (e.g., Android or recently updated Windows 10) should be able to simply
    > activate it. While Apple doesn't implement 464XLAT per se they have
    > something similar, so they should be covered too.
    
    Indeed, section 4.2 mentions:
    
       Operating systems SHOULD provide simple
       ways for applications to do so or even connect to IPv4 literals in
       the absence of host names.  Possible solutions include 464XLAT
       [RFC6877], "Bump-in-the-Host" [RFC6535] and Happy Eyeballs v2 [HEv2].
    
    Apple devices support HEv2, and this is massively deployed which
    has proved that it is a viable solution.
    
    David
    



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

v2.23.0 | Report a Bug | By Email