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

Philip Homburg <pch-v6ops-7@u-1.phicoh.com> Mon, 17 July 2017 16:03 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 EE88A131C84 for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 09:03:36 -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 Pt0a5nuJaqP3 for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 09:03:35 -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 801F1131C71 for <v6ops@ietf.org>; Mon, 17 Jul 2017 09:03:34 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dX8Uf-0000FkC; Mon, 17 Jul 2017 18:03:33 +0200
Message-Id: <m1dX8Uf-0000FkC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
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>
In-reply-to: Your message of "Mon, 17 Jul 2017 17:23:45 +0200 ." <20170717152345.GV45648@Space.Net>
Date: Mon, 17 Jul 2017 18:03:32 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/fM8prO6vP46DxtpwTSUrP84mH2U>
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 16:03:37 -0000

>"Support unwilling applications" is something else, and their time is
>running out.  If it can be done on the mobile world, why can it not 
>be done in the windows or linux ecosystem?

First, many people have devices they don't want to part with.

Second, some people may run old operating systems that need local network 
connectivity while on the same LAN other devices need full internet connectivity.

So no matter what, lots of wifi or 802.3 will have to have some form of 
'native' IPv4 support.

For an ISP it doesn't make sense to provide CPEs with native IPv4 support
to one group of customers and NAT64 to another.

So most likely ISP will hand out CPEs that provide native IPv4 for the next
couple of decades. There is no way ISPs can affort the supports calls if they
break too many legacy devices or setups.

>> but only if you upgrade each and every device that you expect to use IPv4 on.
>
>So how many (client) devices do you have that have not been upgraded in the
>last 10 years, and do not support IPv6, getaddrinfo(), and friends?

How much code did you write that deals with IPv4 literals?

If the literal is already in binary form, you can use it directly. If you
already know that the literal is an IPv4 literal, then calling inet_pton is
way more convenient than calling getaddrinfo.

Next, if the application uses getaddrinfo but happens to be statically linked
with the getaddrinfo implementation then you are also out of luck.

So for most operating systems, something like 464XLAT makes most sense. You
want a 'socket(PF_INET, ...)' system call to work even if the application 
contains hand written assembly that makes the system call directly.

Operating systems started to include 464XLAT support only recently. And will take
a long time before essentially all operating systems have 464XLAT support. After
that it will take an enormous amount of time before all old devices
are either upgraded or retired.

And then what did we really achieve? Remove a tiny bit of code from CPEs and
related routers? Is it the religious IPv6 purity that demands that IPv4 native
needs to be killed as soon as possible?

>If IPv6 were something new, like "invented last year", that "expect 
>devices to be upgraded" argument would be slightly more relevant than
>for a protocol from last century.

This is an edge case, but 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.