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

Philip Homburg <pch-v6ops-9@u-1.phicoh.com> Fri, 25 October 2019 13:15 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 C2BE9120288 for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2019 06:15:06 -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 q2ta5S3TyK2N for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2019 06:15:06 -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 B02BE12004E for <v6ops@ietf.org>; Fri, 25 Oct 2019 06:15:05 -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 m1iNzQi-0000KmC; Fri, 25 Oct 2019 15:15:00 +0200
Message-Id: <m1iNzQi-0000KmC@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: <m1iNIFE-0000IwC@stereo.hq.phicoh.net> <d1b6855d-bde9-7b53-4809-0846bb9772e4@si6networks.com> <CAO42Z2x7vudujw5t++obry56g=VNjQXXTHFK8pBPk0jmk78Bcg@mail.gmail.com> <CAJoHkZ8pTjszP0vw4BjX0HUhmPa6wJONzdy2JEm5iqAfBUvjRg@mail.gmail.com> <CAO42Z2wCYi4KWTEz1hUSPVr9+hu8GaHRkPuvQQ2P00knvnPaaQ@mail.gmail.com> <848BA3B3-36B4-4C42-86D0-88759BC45D5A@employees.org> <A61279DA-4678-4A10-9117-6CA227AE2FA5@cisco.com> <A90AD47E-00E2-4EAB-8BD8-142CC10A6B6F@employees.org> <m1iNv5U-0000KUC@stereo.hq.phicoh.net> <E273241D-9C35-4E07-9525-DF7FA786F419@employees.org> <m1iNywd-0000KmC@stereo.hq.phicoh.net> <49A6064C-3AA0-4AA6-B78E-ED8404D35B97@employees.org>
In-reply-to: Your message of "Fri, 25 Oct 2019 14:53:43 +0200 ." <49A6064C-3AA0-4AA6-B78E-ED8404D35B97@employees.org>
Date: Fri, 25 Oct 2019 15:14:59 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/mxYWS0qCVXFEECzl5ZLVPemaX20>
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: Fri, 25 Oct 2019 13:15:07 -0000

>how is that an advantage for the end user?
>it might be for the ISP. but that's the entity that cannot give stable 
>addressing in the first place...

If routing IPv6 is cheaper than CGNAT IPv4 then either the ISP can offer
higher bandwidth for the same price or reduce prices.

In any case, very often the user doesn't have a choice. I would like to
have reverse DNS delegated for all my IPv6 prefixes. That is just not going
to happen.

>> In the case of certain banks that support IPv6, the advantage is that
>> there is no risk that multiple households will share a single IPv4 
>address.
>
>that's a solved problem. security is done at a higher layer regardless.

Not for that particular bank. They are very much interested in IP addresses.

>if IPv6 provides no benefit over IPv4 then why?
>32 + 16 > 128.
>or if we allow IPv6 to have no benefit over IPv4 I could rather say.

The benefit of IPv6 is that IPv6 addresses are almost for free, whereas a
single IPv4 address costs a significant chunk of money (compared to other
costs).

>The changes in the transport and application layers are already 
>happening (e.g. QUIC).

If QUIC can deal with this flash renumbering problem then it would be nice
to see a report on that. I'm very curious how to would work.

In any case, there will continue to be a lot of TCP and non-QUIC UDP in
the coming years. Are you saying that it will be cheaper to modify all
transport protocols than to fix it in the IPv6 stack?

>There are already "redesigns" of IPv6. Take ILNP.

As far as I know ILNP never got any traction. Do propose we hold off on 
deplying IPv6 until ILNP is mature?

>I'm not the one proposing an IPv6 redesign. This is a response to the 
>proposals of violating a fundamental expectation of stable addressing in 
>IPv6.

The current reality is that IPv6 addresses are not stable in many deployments.
Yes, that's a pity. I'm personnaly very happy with my stable prefixes.

But we have to adapt IPv6 to the real world. Everybody who has stable
prefixes today benefits from having more IPv6 in the world.

Keeping IPv6 restrict to a small, pure corner of the world provides no
benefits.