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

Nick Hilliard <nick@foobar.org> Tue, 19 February 2019 16:16 UTC

Return-Path: <nick@foobar.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 8C794130F1A for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 08:16:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 aXRIj9BBWg5d for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 08:16:24 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDD3130F17 for <ipv6@ietf.org>; Tue, 19 Feb 2019 08:16:23 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x1JGGFGp036156 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2019 16:16:16 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Ole Troan <otroan@employees.org>
Cc: Mark Smith <markzzzsmith@gmail.com>, 6man WG <ipv6@ietf.org>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.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> <6F3036C6-50A1-43C6-B554-31293B69E59D@employees.org>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <1f39ddd0-d8e6-399a-b4c0-9dc6f09cf9c3@foobar.org>
Date: Tue, 19 Feb 2019 16:16:14 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.10
MIME-Version: 1.0
In-Reply-To: <6F3036C6-50A1-43C6-B554-31293B69E59D@employees.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tp6aX9WOlKqKfIHzuFuFK4fnOo8>
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 16:16:26 -0000

Ole Troan wrote on 19/02/2019 13:08:
> 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.

dynamic-assignment addressing protocols tend to assign dynamically.  As 
Barbara notes, the stability period may be long but there is no 
guarantee that things won't change, especially in the ipv6 world (the 
caida study refers almost exclusively to ipv4).  Addressing tends to be 
sticky, not static.

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

Not inviting regulation would be a good start in this department.

> But that doesn’t mean the IETF should accommodate “operators cannot
> provide service with fixed addresses”.

We're not talking about that though - all (or nearly all) operators can 
provide static IP addressing and factor this into their design models 
and businesses to one degree or other.  What you seem to be talking 
about is whether operators should default to exclusively using static 
prefix assignments.  This is unrealistic at best.

Nick