IETF Logo Mail Archive

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

Ole Troan <otroan@employees.org> Fri, 25 October 2019 13:25 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 9C1F612004E for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2019 06:25:46 -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 Y-Var0k0eg4s for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2019 06:25:45 -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 111A8120893 for <v6ops@ietf.org>; Fri, 25 Oct 2019 06:25:41 -0700 (PDT)
Received: from astfgl.hanazo.no (246.51-175-81.customer.lyse.net [51.175.81.246]) (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 34AE64E11B83; Fri, 25 Oct 2019 13:25:40 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 661441FEFB9D; Fri, 25 Oct 2019 15:25:36 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <m1iNzQi-0000KmC@stereo.hq.phicoh.net>
Date: Fri, 25 Oct 2019 15:25:36 +0200
Cc: v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C630FEB8-550D-47D1-BEEE-55134DDDEDD9@employees.org>
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> <m1iNzQi-0000KmC@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/GEnuLJq3lhEzuwJXpvSzrjovY_Y>
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:25:47 -0000

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

It can't be fixed in the IPv6 stack.
The only thing you can do is to make the IPv6 network not work significantly worse than a flash renumbered IPv4 + NAT network.

My argument is that if you do that, as in add support for ephemeral addressing / flash renumbering at the network layer, without doing anything at upper layers, then for an end-user, IPv6 will provide no value or more likely negative value compared to IPv4 + NAT.

Cheers,
Ole

v2.23.0 | Report a Bug | By Email