Re: [sunset4] Closing Sunset4

Lee Howard <lee@asgard.org> Thu, 17 May 2018 21:03 UTC

Return-Path: <lee@asgard.org>
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06602127735 for <sunset4@ietfa.amsl.com>; Thu, 17 May 2018 14:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no 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 gs3BpE4Xu9FP for <sunset4@ietfa.amsl.com>; Thu, 17 May 2018 14:03:11 -0700 (PDT)
Received: from atl4mhob13.registeredsite.com (atl4mhob13.registeredsite.com [209.17.115.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D6C12EB62 for <sunset4@ietf.org>; Thu, 17 May 2018 14:03:11 -0700 (PDT)
Received: from mailpod.hostingplatform.com (atl4qobmail02pod6.registeredsite.com [10.30.71.210]) by atl4mhob13.registeredsite.com (8.14.4/8.14.4) with ESMTP id w4HL39N2021794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <sunset4@ietf.org>; Thu, 17 May 2018 17:03:09 -0400
Received: (qmail 18866 invoked by uid 0); 17 May 2018 21:03:09 -0000
X-TCPREMOTEIP: 68.100.68.25
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.1.135?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 17 May 2018 21:03:09 -0000
To: sunset4@ietf.org
References: <756C7AEB-B6B1-4034-BFFF-AC02D2DE452C@icann.org> <alpine.DEB.2.20.1805150724290.17103@uplift.swm.pp.se> <EC39B83C-CAE1-4C50-AED8-1D8EC0002422@icann.org> <24958_1526473951_5AFC24DE_24958_7465_1_30826.1526473908@dooku.sandelman.ca> <6f557ffb-3a3c-f1b4-c481-8d8e04d123a4@gmail.com> <5cc2c59a-5482-eff5-1854-aee15c28d805@asgard.org> <f508b39f-a4ef-ffa9-0301-2c3d337dfdbe@gaspard.io>
From: Lee Howard <lee@asgard.org>
Message-ID: <06bbe5a4-eb1b-7876-0b20-518949f59c27@asgard.org>
Date: Thu, 17 May 2018 17:03:08 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <f508b39f-a4ef-ffa9-0301-2c3d337dfdbe@gaspard.io>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/sunset4/6uuKJ1EGsvo9YJSHoSs50fzBRBQ>
Subject: Re: [sunset4] Closing Sunset4
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: sunset4 working group discussion list <sunset4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sunset4>, <mailto:sunset4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sunset4/>
List-Post: <mailto:sunset4@ietf.org>
List-Help: <mailto:sunset4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sunset4>, <mailto:sunset4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 May 2018 21:03:13 -0000


On 05/16/2018 08:05 PM, Leo Gaspard wrote:
> On 05/16/2018 09:22 PM, Lee Howard wrote:>> - why new technologies and
> sites get invented yet IPv6 is not on them
>>>    (deployed IoT w/ IPv4, self-driving cars w/ IPv4, new big office
>>>    buildings w/ IPv4, and so on).
>> 1. Shortsightedness
>> 2. Developers hacking together what they barely know
>> 3. Using an OS designed for embedded systems that's based on a very old
>> Linux without IPv6 support.
> (getting ready to be lapidated)
>
> For my end-user (like, a computer and a rental server at a hosting
> company) point of view:
>
>   * Being dual-stack is painful to configure and risky from a security
> point of view (hello iptables and ip6tables getting out-of-sync, IPv6
> privacy extension, etc.)
Can you elaborate on the pain? I may be too close to it to feel it anymore.

>
>   * IPv6-only requires NAT64 to get things to work (just see the issues
> mentioned by the Mythic Beasts presentation from IETF101 you linked to,
> even with NAT64 things don't work out of the box)
Well, it probably requires translation somewhere, but:
1. Not if you're on 4G
2. Not if you control the network
3. There are other transition mechanisms than NAT64.

>
>   * IPv4-only requires nothing, as NAT when required is already handled
> by devices out of my line of sight (eg. routers from where I connect, etc)

As long as device-to-server communication is the only way you would ever 
want to communicate. And as long as 464xlat or DS-Lite or whatever 
transition mechanism the intermediate networks use doesn't bother you.

>
> Also, for my server, setting up a NAT64 is completely useless, as the
> NAT64 would need to run on… the same server, meaning that it needs to be
> dual-stack anyway.
Sure, in that scenario. It's uncommon, I think, to find a server all by 
itself. NAT64 or SIIT-DC make more sense at the edge of a data center. 
Happy to run that for you. :)
>
> So, as an end-user, the easiest solution for me for now is
> `ipv6.disable=1`, and I'll switch to `ipv4.disable=1` when it will exist
> and the rest of the world will be ready for it. Yes, I know this is a
> chicken-and-egg problem.

How will you decide it's time to do that?
How much notice will you have that you can/should/must do it, and how 
long will it take?
Logistic projection shows 50% of the world using IPv6 to reach Google in 
early 2020, and 80-90% in 2022-2023.
Whatever countries your devices are in may have a different growth 
curve, and may adopt transition technologies at a different rate.

>
> This is likely something that should be addressed by this WG (and the
> reason why I subscribed and lurked for a while), but I have absolutely
> no idea how.

Personally, I do not want to force anyone to deploy IPv6 before it makes 
sense for them. I do, however, want to make sure everyone who needs to 
make a decision about when to do it is well-informed about it, and the 
risks and opportunities of deploying or not deploying.

Lee