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

Nick Hilliard <nick@foobar.org> Mon, 04 February 2019 13:30 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 59D9D128CF3 for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 05:30:27 -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 5E-Z11P7kZf0 for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 05:30:20 -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 7BB8912896A for <ipv6@ietf.org>; Mon, 4 Feb 2019 05:30:20 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x14DUEt3086414 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2019 13:30:14 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Ole Troan <otroan@employees.org>, 6man WG <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>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <62b74cf1-9cb0-bba3-b078-cb6f48e90145@foobar.org>
Date: Mon, 04 Feb 2019 13:30:13 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.9
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1902041330531.23912@uplift.swm.pp.se>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8ZWOG3B4UzvtZ5gY9QnaDizuaZI>
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: Mon, 04 Feb 2019 13:30:27 -0000

Mikael Abrahamsson wrote on 04/02/2019 12:34:
> Trying to demand that ISPs keep the same /56 for the duration of the 
> contract is not going to work because that's not what real life looks 
> like. I'd say we should take the fight about perhaps about lifetimes and 
> definititely about delegation sizes (I still run into people with only 
> /60 or /64), but contract-length stable prefix isn't something I'd 
> advocate to fight for. It's too far out even for me.

I think you and Ole are talking about different meanings of the word 
"contract".

Unless I'm mistaken, Ole is saying that a dhcp6-pd lease for time period 
X is a contract for time period X, during which the ISP should retain 
enough state that if the CPE issues another dhcp request within time 
period X, they will receive the same prefix.  However, when time period 
X elapses, the ISP is fully within their rights to assign a different 
prefix.

Maintaining static leases for the duration of a legal contract with a 
customer involves hassle and pain.

Nick