Re: A common problem with SLAAC in "renumbering" scenarios

Ole Troan <otroan@employees.org> Tue, 19 February 2019 13:09 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 3BB66130EDF for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 05:09:00 -0800 (PST)
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_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 a7eRDiE6pos0 for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 05:08:58 -0800 (PST)
Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B54130ED9 for <ipv6@ietf.org>; Tue, 19 Feb 2019 05:08:58 -0800 (PST)
Received: from [192.168.10.189] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id E3937FECBCCF; Tue, 19 Feb 2019 13:08:56 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (16D39)
In-Reply-To: <bbd8b761-403a-5b3f-3f04-dc3bfdea116e@foobar.org>
Date: Tue, 19 Feb 2019 14:08:54 +0100
Cc: Mark Smith <markzzzsmith@gmail.com>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F3036C6-50A1-43C6-B554-31293B69E59D@employees.org>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <d38857c2-6e92-91d6-bb5d-d3eeeb61276a@gmail.com> <CAO42Z2yb47OyXk__Sz-kO00pfcBJgLAhff5DF=mpAddR0iCnAA@mail.gmail.com> <2612280f-195a-ae7a-b3b1-9022d9282fa7@foobar.org> <56F813F4-C512-40A9-8A68-1090C76A80F6@consulintel.es> <CAHL_VyCN8kU7qnLOphfGR25-xGBe_p6WeGTkKVXwU5uy5aJ8Dg@mail.gmail.com> <65DB4854-97D2-4C31-A691-2CD93812EF93@consulintel.es> <CAHL_VyCMpCcGkEQu+RV1GRf2QLB-HD0+AOOBV0YhfQ5sbydVzQ@mail.gmail.com> <8CE7A0CD-97D9-46A0-814D-CAF8788F9964@consulintel.es> <e3e0bf2273e04f15b792665d0f66dfe5@boeing.com> <4c5fab33-2bff-e5b5-fc1d-8f60a01a146d@go6.si> <b4525832-9151-20bf-7136-31d87ba6c88d@huitema.net> <463f15cf-2754-e2e8-609d-dc0f33448c6c@go6.si> <ff649810-7242-7bc2-d36f-3f998f7bdd71@asgard.org> <9CDF41CA-83B4-4FC4-B995-EF79727C5458@steffann.nl> <CAO42Z2wA+vLmU7+sU6xLK7TO6pWfNQA5shs9zp=PqANCihLmBQ@mail.gmail.com> <BAB3061A-1808-4C0E-AA1B-2D7DD5BA63FC@employees.org> <bbd8b761-403a-5b3f-3f04-dc3bfdea116e@foobar.org>
To: Nick Hilliard <nick@foobar.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-MWtqlS3_PRUH2ingFtGTd6blvw>
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: Tue, 19 Feb 2019 13:09:00 -0000

Nick,

> On 19 Feb 2019, at 13:57, Nick Hilliard <nick@foobar.org> wrote:
> 
> Ole Troan wrote on 19/02/2019 12:22:
>> Indeed. Wonder how these pesky mobile phone operators manage to
>> deliver the same telephone number to a user, for years. Across
>> different providers and contracts.
>> I can’t think this argument is anything but a strawman.
> 
> Ole,
> 
> if recommending static IP addressing is an idea that 6man wants to push, you'll need to reach out to the security and ops areas to get their input on this.  I'm not sure this is an issue that 6man can resolve fully.

It’s been the IPv6 addressing model for at least 20 years, so I think the other areas have had ample time to provide their input.

There has also been quite a lot of work on IPv6 renumbering mechanisms. Which if used does handle the case where a customer needs to be renumbered, without causing significant disruption. 

If we want to do significantly better, (as in handle flash renumbering etc) we need to look towards “session layers”, changing transport protocols. 

> 
>> There’s nothing a bit of regulation can’t fix. :-)
> 
> I'm sure you didn't mean to invite regulatory enforcement :-)

So far the ISP industry has managed to stay largely self-regulated. Let’s hope it can continue that way. But that doesn’t mean the IETF should accommodate “operators cannot provide service with fixed addresses”. 

Ole