Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Philip Homburg <pch-v6ops-9@u-1.phicoh.com> Mon, 28 October 2019 08:52 UTC

Return-Path: <pch-b9D3CB0F5@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 B1BCC1200FF for <v6ops@ietfa.amsl.com>; Mon, 28 Oct 2019 01:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 Z5Q4W5H53v1h for <v6ops@ietfa.amsl.com>; Mon, 28 Oct 2019 01:52:12 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 EDF041200F7 for <v6ops@ietf.org>; Mon, 28 Oct 2019 01:52:10 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1iP0kt-0000GkC; Mon, 28 Oct 2019 09:52:03 +0100
Message-Id: <m1iP0kt-0000GkC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <m1iOinq-0000J3C@stereo.hq.phicoh.net> <44F39DE2-E142-4ED0-853E-2F3AAC6F4ADE@employees.org> <m1iOnqN-0000EpC@stereo.hq.phicoh.net> <ADCF08FD-1366-4CCB-984E-695D8E2AC2F8@employees.org>
In-reply-to: Your message of "Sun, 27 Oct 2019 23:52:15 +0100 ." <ADCF08FD-1366-4CCB-984E-695D8E2AC2F8@employees.org>
Date: Mon, 28 Oct 2019 09:52:02 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/sZnm2anjAUSpfBzVzYPmYE8L0pc>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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, 28 Oct 2019 08:52:15 -0000

> The (only) value (sic) of IPv6 to end-users is retoration of end
> to end connectivity at the network layer.

End users at not really part of the equation at the moment. Many people have
tried to convince their ISPs to provide IPv6 and failed.

For home use, IPv6 is what you get when the ISP has decided that providing 
IP services over IPv6 instead of or next to IPv4 is worth it.

This is not my ideal world. But realistically, we live in a world that still
has to transition away from IPv4. 

> I challenge you to find in the "real world" of end-users many with
> much trust in the ad-based "you are the product" centralised services
> in the current Internet.  IPv6 was meant to allow end-users to run
> decentralized services.

This is a separate issue. The problem started when people paid for
connectivity but assumed they paid for internet services. There are plenty
of providers for mail, messaging, etc. where you are not the product. But
very few customers are willing to pay extra for such services.

At the same time, where an ISP does provide stable addresses,
most people find it hard to run services at home.

> - hidden primary DNS - mail - web - home-automation - video
> conferencing - jabber

Many people have a more or less fixed IPv4 address. Setting up a few port
forwards in a CPE is not that hard (and with IPv6, you have to do the same
for the firewall in the CPE).

Yet very few people run these services at home.

Basically, the market value for those service at a residential home is zero.

> Assuming all the moving parts required were updated to support
> flash renumbering (I have little proof they even support graceful
> renumbering), if the end-user cannot trust the lifetimes in the
> delegated prefix, DNS with TTL=1s is presumably the only choice?

ISPs that do flash renumbering, typically do that after a link down event.
Assuming those events are rare (and ISPs have an incentive to make them
rare because it interferes with watching video), then a TTL of a few
minutes should work.

> If making IPv6 no better than IPv4 + NAT, then stick with IPv4 +
> NAT.  IPv4 NAT scales very well as it turns out.
 
IPv4 NAT doesn't scale very well when law enforcement wakes up and find out
that a single IP address means lots of different people at the same time.

IPv4 NAT also doesn't scale very well when it comes to bandwidth.

For large ISPs, IPv4 NAT is also annoying from a network management point of
view because it is not possible to uniquely number all devices in the 
network.

Plenty of reasons for an ISP to move to IPv6 even if they don't care about
providing end-to-end connectivity.

> We don't need IPv6 to maintain the status quo.

We are out of IPv4 addresses. There is a lot of demand for IPv4 addresses
and the lack of them is a barrier against entry.

> And don't get me wrong, I'm all for making IPv6 addressing / onlink
> behaviour more robust.  But not justified in this way that can be
> seen to allow for practices that removes any benefit of IPv6 over
> IPv4/NAT.

The current internet has moved to lots of short lived flows. If we can
tune systems that new address information propagates quickly, both on the
local network and in DNS, then unstable prefixes could very well something
we can live with.

In fact, we can also use the letsencrypt argument: by having short lived
certificates letencrypt strongly encourages automating the whole process.
Lots of tooling popped up to support that model.

Right now we are stuck in a model where too many files are hand edited with
address and prefix information. At the same time, everybody expects
phones and laptops to seemlessly move between networks, picking up new
addresses and removing stale ones as they move around.