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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 17 July 2017 10:02 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 767D212EB99 for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 03:02:51 -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 UJjCnYgv92Eb for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 03:02:49 -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 EEBBA1276AF for <v6ops@ietf.org>; Mon, 17 Jul 2017 03:02:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500285766; x=1500890566; 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=Fe6UEax7sUHtrSHlyLQPrv4nd wV/yBuQ59ZGxkVofF0=; b=c1j2zxQF6mGGzFAzMXBp8RQtED2qrEmSr+M6lzW85 bqR4ys+oCJvX9ESBCKvT5Y727su8Bv3OtENeQtlxBtoYEEreuLpqX3smY/P6dE9i QM1HPqWGWoM9J4wxoFJkXUFkV/8kAHgEq8+FG+ZR6vmjEhEttw+K8hOqPoeegtaF Og=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=P5mhBWGqvLPx37Z6oRybTkRNqWUUSSuNSmRhjqqWb8/6Qp3YSz1pm7pTbroh 32iDtP78JV/05q2kUtGp2DkgOuu952VmnJQEt8rqinMs2a25HG7Jj9b1n yA0apLV3pgxMO9gti/wdi6yu0E7qoS71M3GArRE3pGo+D5vO5vNLQ8=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 12:02:46 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 12:02:45 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478306.msg for <v6ops@ietf.org>; Mon, 17 Jul 2017 12:02:44 +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:md50005478306::oQdUVSR1PoF6/TVZ:00003jdm
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 12:02:37 +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>, Suresh Krishnan <suresh.krishnan@gmail.com>, Alissa Cooper <alissa@cooperw.in>, Jim Martin <jim@daedelus.com>
Message-ID: <3FEF5EC2-512C-4080-BA45-78E84585BC4F@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> <4DDD221A-B9AA-4F47-9B15-DD58CEBE6584@consulintel.es> <5CA17A3A-5F25-4C26-BF08-3A9C117CE333@apple.com>
In-Reply-To: <5CA17A3A-5F25-4C26-BF08-3A9C117CE333@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/vrvxFXc-SJMYjBb9FjL2HXEU6cw>
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 10:02:51 -0000

Everything that goes thru the CLAT means is failing to go thru the NAT64, so reporting all by default in the CLAT will make it.

The logs tell us the data that we need to identify the apps, and I think it could be automated with some scripts.

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

    I absolutely agree that automatic issue detection is better.However I fail to see how you automatically go from CLAT logs to
    knowing there is an issue with a specific piece of software.
    This is a problem that we tried to solve in the past and there is no silver bullet.
    
    As such, I think relying on IETF attendees to check whether their own software works has great value.
    
    David
    
    
    
    On Jul 17, 2017, at 11:52, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
    
    
    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 <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
    
    
    
    
    



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