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

Ole Troan <otroan@employees.org> Mon, 28 October 2019 09:22 UTC

Return-Path: <otroan@employees.org>
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 41FF11200DF for <v6ops@ietfa.amsl.com>; Mon, 28 Oct 2019 02:22:03 -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, SPF_HELO_NONE=0.001, SPF_PASS=-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 2iQDQPkKN2Bl for <v6ops@ietfa.amsl.com>; Mon, 28 Oct 2019 02:22:02 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24BFB12003F for <v6ops@ietf.org>; Mon, 28 Oct 2019 02:22:02 -0700 (PDT)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:47d8:1877:7873:cee8:d3ed]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id D2E354E11AEC; Mon, 28 Oct 2019 09:22:00 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 00BB42037220; Mon, 28 Oct 2019 10:21:57 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <m1iP0kt-0000GkC@stereo.hq.phicoh.net>
Date: Mon, 28 Oct 2019 10:21:57 +0100
Cc: v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <21E28E8F-8E91-47D6-8337-9FF0359D67B8@employees.org>
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> <m1iP0kt-0000GkC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/OXYabOEnbPEpsyeZn6KZuOVb58E>
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 09:22:03 -0000

Philip,

I didn't see your answer to:
"I don’t know of a single server which operates that way currently. Can you point to a working example?"

I take it the answer is: "currently none"?

Ole

> On 28 Oct 2019, at 09:52, Philip Homburg <pch-v6ops-9@u-1.phicoh.com> wrote:
> 
>> 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.
> 
>