IETF Logo Mail Archive

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

Mikael Abrahamsson <swmike@swm.pp.se> Mon, 04 February 2019 13:43 UTC

Return-Path: <swmike@swm.pp.se>
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 17812130DE4 for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 05:43:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 klN1Rcso9Z0Z for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 05:43:04 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 8F4CB128CF3 for <ipv6@ietf.org>; Mon, 4 Feb 2019 05:43:04 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 29F59B0; Mon, 4 Feb 2019 14:43:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1549287782; bh=dqVHjTfOHh0bVd7yOhXCagXYKDFYP1Y55j2IilWyy/M=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oXBkN1NnxXFfXH63cUXNdnudSlz5UYRNx7MIlu13GEeZD21YGelUk9rx3kSKWdfUt MI9WwEtjytrHJg38QYfrCw0oRFP6rgxTlx2pM//nZGbnfNAE0pgZTbpx1P/v30jNYB Q+Yt/sbTfX592AXOpFM+r5L0Kmh+GWnfZghzuERE=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 27F27AF; Mon, 4 Feb 2019 14:43:02 +0100 (CET)
Date: Mon, 04 Feb 2019 14:43:02 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Ole Troan <otroan@employees.org>
cc: Jan Zorz - Go6 <jan@go6.si>, 6man WG <ipv6@ietf.org>
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
In-Reply-To: <46B8DB92-DC81-4242-9780-0D00FB6BDB7A@employees.org>
Message-ID: <alpine.DEB.2.20.1902041439590.23912@uplift.swm.pp.se>
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> <46B8DB92-DC81-4242-9780-0D00FB6BDB7A@employees.org>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="-137064504-1240311535-1549287782=:23912"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8en4ziJc_a9pHrEeZhroxJwtM5s>
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:43:07 -0000

On Mon, 4 Feb 2019, Ole Troan wrote:

> “real life looks like”…
> Why wouldn’t it? If the ISP has a routed interface directly towards the customer, then having a fixed /56 PD configured on that customer facing interface, that sure looks like real life to me.
> Or a fixed mapping of remote-id to a /56 in a DHCP PD database…

So while I have actually designed services that look like that (individual 
single /56 pool per interface) most people do not do that. Some don't want 
to for commercial reasons, to differentiate betwee this and other 
services.. or some other reason. Same thing some don't give customers /56.

We're not the protocol police and we've not been successful in getting /56 
PD sizes to everybody, so I don't see how we're going to mandate this that 
is even more commercial angle on things.

> Sure, there are ISPs that use DHCP PD servers that allocate from pools. 
> But I have a hard time seeing why that should be easier, cheaper, more 
> managable than a static mapping table.

Just because you and me think something makes sense doesn't mean it make 
sense to others.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email