Re: [v6ops] NAT64/DNS64 support in RIPE Atlas

Philip Homburg <pch-v6ops-7@u-1.phicoh.com> Tue, 18 July 2017 07:48 UTC

Return-Path: <pch-b7900FA3D@u-1.phicoh.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 8AECF131DA5 for <v6ops@ietfa.amsl.com>; Tue, 18 Jul 2017 00:48:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jgKnFEtxspqC for <v6ops@ietfa.amsl.com>; Tue, 18 Jul 2017 00:48:15 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 9E206131A4F for <v6ops@ietf.org>; Tue, 18 Jul 2017 00:48:12 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dXNEk-0000EGC; Tue, 18 Jul 2017 09:48:06 +0200
Message-Id: <m1dXNEk-0000EGC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
Cc: Tore Anderson <tore@fud.no>
From: Philip Homburg <pch-v6ops-7@u-1.phicoh.com>
Sender: pch-b7900FA3D@u-1.phicoh.com
References: <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> <m1dX7DB-0000FzC@stereo.hq.phicoh.net> <CAFU7BAQ1ML2ARZKozJLFiEw43jmMObKwOpD4pGt9S3VKOwLE4w@mail.gmail.com> <m1dX7nO-0000GTC@stereo.hq.phicoh.net> <20170717152345.GV45648@Space.Net> <m1dX8Uf-0000FkC@stereo.hq.phicoh.net> <29616c41-49d5-a960-8048-9441284fd171@fud.no>
In-reply-to: Your message of "Mon, 17 Jul 2017 23:23:59 +0200 ." <29616c41-49d5-a960-8048-9441284fd171@fud.no>
Date: Tue, 18 Jul 2017 09:48:06 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/8sI8Nf15bSoQKsih48dYACyhjv8>
Subject: Re: [v6ops] NAT64/DNS64 support in RIPE Atlas
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: Tue, 18 Jul 2017 07:48:21 -0000

>> you don't want to know how much I had to change to the Atlas probes
>> and related infrastructure to get them to support NAT64/DNS64.
>I do want to know, you certainly are tickling my curiosity here. Is this
>about DNSSEC, did you implement a 464XLAT CLAT, or something else
>entirely? If it cannot be summarised in an e-mail, perhaps write a RIPE
>Labs article about the subject?
>
>(I changed the subject, as to the best of my knowledge the Atlas probes
>have their 802.11 radios disabled, and as such are very unlikely to ever
>be connected to a conference wireless network.)

Let me start with the last part. Sometime ago we start working on support
for measuring eduroam. So there now exists firmware that can enable the
wifi radio and connect to a wireless network.

Note that by default, probes have firmware that does not contain any wireless
device drivers, etc.

We are working on a way for a probe host to opt in. At the moment we have
manually allowed wifi firmware  for some probes in educational institutions.
The only SSID we currently envision is eduroam. Though of course the
community can ask for others as well.

With this wifi capability it is easy to play around and connect a 'dev probe'
to the NAT64 network at a RIPE meeting.

So what goes wrong. Currently unsolved is that measurements are either v4
or v6. So if you measure a v4-only target with a v4 measurement then probes
on a NAT64 with never measure anything. You need a v6 measurement for that.

Then there was the problem that the system tries to be helpful. If you create
a v6 measurement and the target doesn't have a v6 address then the measurement
is not scheduled. Fortunately other people needed an override for that check
as well. 

The next thing is that the libraries used by the probe assume that DNS
resolvers are listed in /etc/resolv.conf. This is not entirely correct
if you have both a wired and wireless interface, but by and large it works.

Of course this completely fails when the wired interface is dual stack and
the wireless interface uses NAT64/DNS64.

Finally, traceroute output is extremely confusing and/or broken. I still have
to spend some time with some packets I captured during the RIPE meeting.

The reason is that IPv4 error ICMPs have to be converted to IPv6 error IMCPs.
But of course IPv4 error ICMPs do not adhere to all the requirements of
IPv6 error ICMPs. So this causes a protocol violation. And breaks some
assumptions in the Atlas traceroute code. I have no intent to solve that.