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

otroan@employees.org Thu, 12 November 2020 10:47 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A5D3A15A3 for <ipv6@ietfa.amsl.com>; Thu, 12 Nov 2020 02:47:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1d2vjWGH_AaR for <ipv6@ietfa.amsl.com>; Thu, 12 Nov 2020 02:47:26 -0800 (PST)
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 3F9253A15A1 for <ipv6@ietf.org>; Thu, 12 Nov 2020 02:47:25 -0800 (PST)
Received: from astfgl.hanazo.no (unknown [IPv6:2a02:2121:30d:d874:d0d0:4b7c:2ddf:8ea6]) (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 AB59B4E11B3B; Thu, 12 Nov 2020 10:47:24 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 5B39343DEAB4; Thu, 12 Nov 2020 11:47:19 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: Ephemeral addressing [was Re: 64share v2]
From: otroan@employees.org
In-Reply-To: <m1kd9tw-0000KiC@stereo.hq.phicoh.net>
Date: Thu, 12 Nov 2020 11:47:19 +0100
Cc: 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <165C6F07-F502-43C7-8542-829FEC041DC1@employees.org>
References: <CAD6AjGR-NE_sJ_jp7nAT6OvNkcdE9qoWuGEiiVW7r9YtsQvbbw@mail.gmail.com> <CAKD1Yr0G8PjzE+pULte_AaOi=RHMLyto-YUQerGjQ=iOYnz+iA@mail.gmail.com> <0986B112-2159-4045-87F9-876B58F1D896@employees.org> <CAKD1Yr0h9=7p+n=qnH1o1EHqtPrsaYebgvHciOJpP3=iXgNgKQ@mail.gmail.com> <0C739112-D8EA-42C3-BEFD-88C014D5BCD0@employees.org> <62bc0e56-85b8-42ea-c46b-4f2205dc435f@joelhalpern.com> <28C2E56B-1443-480A-B3D1-82E0F8CC0EC7@employees.org> <aabd41ad-1770-f2ac-77d6-62bfff1992c0@joelhalpern.com> <CC7C2B94-5A05-4682-8367-9072CC201C49@employees.org> <80ed3a3b-6e2c-188f-4c1e-c2ededfbbe0d@joelhalpern.com> <0188AC41-60B0-4BC6-810D-DC59CF9E4FB3@employees.org> <1931a638-64ed-f40e-07a3-67cf1eafb941@joelhalpern.com> <376D6BB0-87E2-42E5-9BC4-F3A2F04FA005@employees.org> <CAD6AjGSr-TPcGo7f9EGgoAahYLQTL68CUSq58LGMgD0=6GmRRg@mail.gmail.com> <8DC674FB-9F90-4C41-A323-62BD62934A12@employees.org> <CAD6AjGTYBs8YbHgCJJG84vgwXK4ZSCm65z6KXvZP9F+LdT_atg@mail.gmail.com> <038A830C-E024-42C6-917E-E6FF57829A1C@employees.org> <CAD6AjGTQVtJBJ3=aZBsF1WcdSK2k9b1hzeZXM6008w_2vpo6_w@mail.gmail.com> <948ACA2B-E45C-4289-A837-9F2536F20F8F@employees.org> <CAKD1Yr0tDTSH2F4=ZsdMJREy1k6equ9mZV0Au1bJPmKuzxeYVA@mail.gmail.com> <43C449AD-D116-4452-A4F2-79AE5A76539F@employees.org> <m1kcoXQ-0000G1C@stereo.hq.phicoh.net> <267D8461-47EC-443A-98DF-4FE990138B5A@employees.org> <m1kcprv-0000GNC@stereo.hq.phicoh.net> <F39272F7-EBCC-4551-BB42-4014DD437302@employees.org> <m1kcr9K-0000GNC@stereo.hq.phicoh.net> <024A7514-57F0-40E0-B445-572DFD007ED4@employees.org> <m1kd9tw-0000KiC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hFrxRbHnWPIGgb2uo6XslCVLaM4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2020 10:47:28 -0000

Philip,


> On 12 Nov 2020, at 11:32, Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> wrote:
> 
>> If you all you have are clients then the IPv4 Internet we have
>> today works perfectly fine.
> 
> That's not correct for quite a few reasons:
> - RIR are by and large out of IPv4 addresses. It is hard to connect a client
>  to an IPv4 internet when you have no addresses.
> - If an ISP has some IPv4 addresses then bandwidth on a CGN box is more
>  expensive than an IPv6 router
> - Servers need addresses, so we now require parties to buy second hand
>  addresses on the open market. 
> - It is perfectly possible to offer service on changing addresses. There is
>  this thing called DNS that can be used to assign a stable name to changing
>  addresses.

You seem to be making an argument for why everyone else should deploy IPv6.
Which isn't my point. My point was that IPv6 with ephemeral addressing gives equal or less benefit to the end-user than existing IPv4.
And no, there is little indication that we cannot make the IPv4 Internet work forever. If we must.

> In any case, good support for ephemeral address doesn't hurt operators who
> deply static addresses. My servers at home get static addresses from
> DHCPv4. Phones, etc. get dynamic addresses. 
> 
> Your own proposal of turning L2 bridges into L3 routers creates a lot more 
> ephemeral addresses. Currently, relative large subnets have a single /64,
> so each device that connects there will have a stable SLAAC address.
> 
> When each link has its own /64 then on wifi each time a device connects it
> will get a different address (unless 802.1X is used with radius to assign a
> static prefix to an account).

Then you didn't understand that proposal.

> So it not clear to me why you are complaining about shortlived addresses.

I'm all in favour of making renumbering work. Even to the extent of ephemeral addressing.
But glossing over the problem and pretending that it is a solved problem, is quite unfair.
Have a look at the existing work on this. E.g. RFC7010.

Best regards,
Ole