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

Gert Doering <gert@space.net> Mon, 17 July 2017 10:42 UTC

Return-Path: <gert@space.net>
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 D7B30131B06 for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 03:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 rL0HskuL8Nv1 for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 03:42:56 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE7A131B1A for <v6ops@ietf.org>; Mon, 17 Jul 2017 03:42:56 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A9F7741BEC for <v6ops@ietf.org>; Mon, 17 Jul 2017 12:42:53 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 6CBF641B72; Mon, 17 Jul 2017 12:42:53 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 68B759058; Mon, 17 Jul 2017 12:42:53 +0200 (CEST)
Date: Mon, 17 Jul 2017 12:42:53 +0200
From: Gert Doering <gert@space.net>
To: JORDI PALET MARTINEZ <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>
Message-ID: <20170717104253.GM45648@Space.Net>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <D0BB59E5-90DB-4930-92B3-6AC7E0AF7391@consulintel.es>
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/DVVBTIbjUVtV7Y6Sikj0KdOTckg>
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:42:59 -0000

Hi,

On Mon, Jul 17, 2017 at 11:41:20AM +0200, JORDI PALET MARTINEZ 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.

The openvpn client in version 2.3.x is "dual single-stacked" - it will
not ask for a v6 address unless it's told to use ipv6 (in which case it
will not ask for a v4 address).  This obviously stinks, but you need
test setups like this to find out where it stinks.

Since this was found a few years ago at a RIPE meeting in the IPv6-only
network already, OpenVPN 2.4.x has been fixed, and will now do the right
thing ("call getaddrinfo() and use all addresses returned in the order
presented by the host OS").

Please upgrade your client :-)

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

So how would the CLAT know that it's openvpn that is broken, and what
are meeting ops supposed to do with the result?

No, the breakage must be visible on the host that has broken software
installed, otherwise people will continue to just not care.

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

OpenVPN is a good example, because the problem was found due to usage of
IPv6-only networks, fixed, and now just lingers because people continue
to use old versions...

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279