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:53 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 3A16A129417 for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 02:53:08 -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 e-xtKFCARGRs for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 02:53:07 -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 73DA91276AF for <v6ops@ietf.org>; Mon, 17 Jul 2017 02:53:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500285182; x=1500889982; 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=U0YBGqvzyQhspdik/CuLqM7/m gSwvEkw4QGxW/XOBjI=; b=W1WBLIgiydYXzr05vLqJklo/jNoHCcrZaPngJ3ecq C/suyLjB9n4idvkvCzIyA8H1MGR/0nuvEqe2dsT/KXoN/GgUhPRKKvJvB724cTeg sZ1kHHKho5UMoQgda4zKGj1pZT0CWQxuITBzcxshpWfvL1T37HDUtPYSMbF6uIL2 tA=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=nBheW/No0Mfb4CVsfNYlvvGTd/VTPM4FZyTW5qF7l4D3pQ+9QrZvVAp5f55D OujKyLTNn3tqYjUSsS+BzfKmhj6r4ydPwXRitf3Z5m2L+fmIGtgGH7jO2 VRQ2zZNua21eI3ggWmPLPBrz0nKsu48AIsbpgZbV6Nx5AHJCaruKhY=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 11:53:02 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 11:53:01 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478297.msg for <v6ops@ietf.org>; Mon, 17 Jul 2017 11:53:01 +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:md50005478297::QWUUtBKAqBO7uZLN:00002Cyd
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:52:53 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: IPv6 Ops WG <v6ops@ietf.org>
CC: Randy Bush <randy@psg.com>, Alissa Cooper <alissa@cooperw.in>, Suresh Krishnan <suresh.krishnan@gmail.com>, Russ Housley <housley@vigilsec.com>, Jim Martin <jim@daedelus.com>
Message-ID: <4DDD221A-B9AA-4F47-9B15-DD58CEBE6584@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> <D0BB59E5-90DB-4930-92B3-6AC7E0AF7391@consulintel.es> <38B8160E-1DFC-423E-AB9E-2CDD64BF50AD@apple.com>
In-Reply-To: <38B8160E-1DFC-423E-AB9E-2CDD64BF50AD@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/feOAdvRoNWd1EFH1SYMSzcyyDsg>
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:53:08 -0000

Definitively get them fixed, and towards that we need to identify them. We want to identify them “manually” or “automatically”? I think automatically will work much better. Manually means people may report the first failure, then switch to the fall back network …

CLAT can be run in a VM (for example using Jool). I’ve done it.

I’m not a software developer, but Jool provides some logging tools, it is just a matter to get our hands on it.

There may be other CLAT implementations that can be used. I think Jool is very powerful, take advantage of multiple cores, etc.

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:48
Para: <jordi.palet@consulintel.es>
CC: IPv6 Ops WG <v6ops@ietf.org>, Randy Bush <randy@psg.com>, Alissa Cooper <alissa@cooperw.in>, Suresh Krishnan <suresh.krishnan@gmail.com>, Russ Housley <housley@vigilsec.com>, Jim Martin <jim@daedelus.com>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    
    
    > On Jul 17, 2017, at 11:41, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
    > 
    > 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.
    
    Should we then give up on IPv6 or try to get these fixed?
    
    > 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).
    
    Which "automated way to report what is [broken] using the CLAT" software are you referring to?



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