Re: Ephemeral addressing [was Re: 64share v2]

Philip Homburg <> Thu, 12 November 2020 13:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 220673A0A06 for <>; Thu, 12 Nov 2020 05:33:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mznpmBoIL3cQ for <>; Thu, 12 Nov 2020 05:33:24 -0800 (PST)
Received: from ( [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 240463A0E65 for <>; Thu, 12 Nov 2020 05:33:19 -0800 (PST)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kdCiw-0000ECC; Thu, 12 Nov 2020 14:33:14 +0100
Message-Id: <>
Subject: Re: Ephemeral addressing [was Re: 64share v2]
From: Philip Homburg <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <038A830C-E024-42C6-917E-E6FF57829A1C@employees.or g> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-reply-to: Your message of "Thu, 12 Nov 2020 13:25:53 +0100 ." <>
Date: Thu, 12 Nov 2020 14:33:14 +0100
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Nov 2020 13:33:26 -0000

> > It seems to be that the industry thought that they could make IPv4 work
> > forever. But in reality there was no plan. Life behind a CGN is very limiti
> ng.
> Not too dissimilar to IPv6 with ephemeral addressing (today).  Ref
> 7010 gaps.

There is no way a consumer could get port 443 on an address assigned to a CGN.

In contrast, a consumer with IPv6 has as many 443 ports as desired. We have
DNS protocol support for updates.

So this a completely different world.

> PI. But anyway.  We must ensure IPv6 work better than IPv4.  There
> is something to be said for IPv4's use of private addresses.
> Unfortunately. We can't make the IPv6 user experience worse.

Reality is that our attempts to have stable identifers have failed. What
have is topology dependent locators. Yes, any party that can inject
prefixes in BGP is topology independent. But many consumer devices
constantly connect to different ISPs.

A big issue is that by and large devices detect that they are in a different 
environment by watching link state.

With NAT, devices behind the NAT keep the same address even if the upstream
changes. This is a clear gap that we need to address. 

> There's nothing stopping the address assignment mechanism in p2p
> ethernet to give the same address back to the same user. So p2p
> ethernet even with "dynamic" interfaces can provide stable addressing.

The current trent is that devices randomize all identifers. Or the other
way around, any stable identifier can be used for tracking the device.

How you provide stable prefixes to such devices?

> My point was with regards to Cameron's
> proposal that we cannot deploy a PD mechanism today, that inhernetly
> does ephemeral addressing. There just are too many issues with
> that, and will lead to a bad user experience.

Today, any mobile device already has ephemeral addresses and deals with it.

At the same time (in the context of mobile), nothing stops a mobile provider
from assigning static prefixes to customers (other than the cost of a 
more complex (routing) system).

I.e., a mechanism that provides ephemeral addressing can also be used to 
provide static addressing if stable client identifiers are available.