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

Ole Troan <> Mon, 28 October 2019 09:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41FF11200DF for <>; Mon, 28 Oct 2019 02:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2iQDQPkKN2Bl for <>; Mon, 28 Oct 2019 02:22:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 24BFB12003F for <>; Mon, 28 Oct 2019 02:22:02 -0700 (PDT)
Received: from (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 (Postfix) with ESMTPSA id D2E354E11AEC; Mon, 28 Oct 2019 09:22:00 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (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 <>
In-Reply-To: <>
Date: Mon, 28 Oct 2019 10:21:57 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Philip Homburg <>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Oct 2019 09:22:03 -0000


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"?


> On 28 Oct 2019, at 09:52, Philip Homburg <> 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.