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

Jan Zorz - Go6 <jan@go6.si> Tue, 05 February 2019 15:44 UTC

Return-Path: <jan@go6.si>
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 40A8D1310D7 for <ipv6@ietfa.amsl.com>; Tue, 5 Feb 2019 07:44:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=go6.si
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 EV1sYJ2QjMNP for <ipv6@ietfa.amsl.com>; Tue, 5 Feb 2019 07:44:11 -0800 (PST)
Received: from mx.go6lab.si (mx.go6lab.si [91.239.96.23]) (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 96A7F130E7D for <ipv6@ietf.org>; Tue, 5 Feb 2019 07:44:10 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 7B1D465FE3 for <ipv6@ietf.org>; Tue, 5 Feb 2019 16:44:08 +0100 (CET)
X-Virus-Scanned: amavisd-new at go6.si
Received: from mx.go6lab.si ([IPv6:::1]) by localhost (mx.go6lab.si [IPv6:::1]) (amavisd-new, port 10024) with LMTP id NkZEpoZGLjrv for <ipv6@ietf.org>; Tue, 5 Feb 2019 16:44:06 +0100 (CET)
Received: from mail.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.go6.si", Issuer "Let's Encrypt Authority X3" (not verified)) by mx.go6lab.si (Postfix) with ESMTPS id B30D4603E3 for <ipv6@ietf.org>; Tue, 5 Feb 2019 16:44:06 +0100 (CET)
Received: from ISOC-BMDKQ4.local (unknown [IPv6:2001:67c:27e4:102:182a:e622:682:93c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Jan Zorz", Issuer "COMODO RSA Client Authentication and Secure Email CA" (not verified)) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id 8DBDD805A2 for <ipv6@ietf.org>; Tue, 5 Feb 2019 16:44:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1549381446; bh=1Xe6TEyXMn6MsPmiFv4TWNyrbh+gO4ZEFq5V8lKo0Go=; h=Subject:To:References:From:Date:In-Reply-To:From; b=RjV05MbcukUmO5dfC6eC9T03H8irjJJt46OG4Y8pQFhQVlHBGHDX7oZA7LlTOEV3B X7yirhvFNt6zEg8DRUvux8trHJApyLNpGgxYD6kN2hghE5TIfV8sRF0gYayy3XdCBc UfAVWx6qtHLJuvQBklJzET0JJsKROsxuX0lP/PTo=
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: ipv6@ietf.org
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <alpine.DEB.2.20.1901311236320.5601@uplift.swm.pp.se> <m1gpCcz-0000FlC@stereo.hq.phicoh.net> <ddd28787-8905-bafd-3546-2ceef436c8b0@si6networks.com> <m1gptWx-0000G3C@stereo.hq.phicoh.net> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <d40b41c3-ff1b-cab4-a8de-16692a78e8fd@go6.si> <D1E45CAD-08D0-43D4-90F7-C4DD44CB32C0@employees.org> <alpine.DEB.2.20.1902041330531.23912@uplift.swm.pp.se> <77ecf321-b46e-4f25-7f68-05b15714a99e@si6networks.com> <CAHL_VyDdHuEAc9UdeiRp9f+c0tdzyoLwPY1rJbZmbWAuq96Uuw@mail.gmail.com> <alpine.DEB.2.20.1902051127510.23912@uplift.swm.pp.se> <m1gqyJC-0000FkC@stereo.hq.phicoh.net> <CAO42Z2wKh-vXmv=dNmr6oEmGnw09ajrr2geYJ=H1DbSYSm=VuQ@mail.gmail.com> <m1gqzYT-0000F5C@stereo.hq.phicoh.net>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <e8eabf0f-191a-a293-8051-35268a62a2bd@go6.si>
Date: Tue, 05 Feb 2019 16:44:04 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <m1gqzYT-0000F5C@stereo.hq.phicoh.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mMJUDELAodi_40xXKhbjHkIj9dY>
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, 05 Feb 2019 15:44:12 -0000

On 05/02/2019 13:10, Philip Homburg wrote:
>> The problem starts when the ISP wants to change prefixes.
>>
>> How often will they really need to do that?
>>
>> I think a lot of this need in IPv4 has come from IPv4 addresses being
>> precious and expensive resources. Consequently, it has been worth the
>> expense and effort of fine grained management of them.
>>
>> In IPv6, that level of management isn't needed. Addresses are plentiful and
>> cheap, so you can throw lots of address space at problems.
> 
> Ideally every customer just gets a static /48. There is no technical reason
> why this can't be made to work.

Agreed 100% :)

> 
> Reality is that ISPs have lots of reasons to do things differently. I don't
> think we are in position to tell ISPs that they are doing it wrong. 

Hmm. We could be in a position to tell them they are doing it wrong - if 
they are doing it wrong :) And clearly - they are doing it wrong, 
otherwise things would work and we would not have this conversation ;)

We need to make sure operators stop cutting corners and dragging bad 
practices from IPv4 into IPv6 world and things will get better.

> Reality
> is also that in lots of markets there is little competition. So if an ISP
> does something weird, customers are stuck with it.

We need to fix this before people start pulling IPv4 out of their 
networks. Today we have another protocol that saves our day if things 
goes wrong, but when IPv4 is out of our backbones and access networks - 
all this little failures will show much more prominently.

Cheers, Jan