IETF Logo Mail Archive

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

Simon Hobson <linux@thehobsons.co.uk> Fri, 15 February 2019 21:50 UTC

Return-Path: <linux@thehobsons.co.uk>
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 28797130E6F for <ipv6@ietfa.amsl.com>; Fri, 15 Feb 2019 13:50:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vKCEDvhB94ND for <ipv6@ietfa.amsl.com>; Fri, 15 Feb 2019 13:50:04 -0800 (PST)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0479E12F1AB for <ipv6@ietf.org>; Fri, 15 Feb 2019 13:50:04 -0800 (PST)
X-Quarantine-ID: <k2E5VqMQX8ax>
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <60[...]
Received: from simons-macbookpro.thehobsons.co.uk (Simons-MacBookPro.thehobsons.co.uk [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 9992F1BC37 for <ipv6@ietf.org>; Fri, 15 Feb 2019 21:49:59 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <9CDF41CA-83B4-4FC4-B995-EF79727C5458@steffann.nl>
Date: Fri, 15 Feb 2019 21:49:58 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <2839D69E-1AB8-485E-95C4-B2882A355217@thehobsons.co.uk>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <c16e0e1f-1ed2-ad88-80f1-070bdd8bccca@go6.si> <1F2C2AEE-1C7D-481C-BBA7-7E507312C53A@employees.org> <e56a6e5b-648d-200e-c35d-97f15a31fb2a@asgard.org> <CAO42Z2zh7fKAgQJq9aLCTiFoSSsTeGM=pK3gXitg+gcxH=9fhQ@mail.gmail.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> <9CDF4 1CA-83B4-4FC4-B995-EF79727C5458@steffann.nl>
To: 6man WG <ipv6@ietf.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/AK_XYw2OmD6jMgJavD07kNDpgRQ>
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: Fri, 15 Feb 2019 21:50:06 -0000

Sander Steffann <sander@steffann.nl> wrote:

> I think the underlying problem here is that there is no technical solution available that solves stable IPv6 address delegation at residential scale in an acceptable way.
> 
> - For stable address delegation the routing inside the ISP becomes a mess, especially when it can't be guaranteed that a customer consistently ends up at the same BNG.
> - To keep ISP networks scalable, prefixes are aggregated to (roughly) BNG level, making it impossible to keep prefix delegation stable at the customer's end

How is IPv6 different to IPv4 in this ?
Some ISPs seem to have no issue with providing static IPv4 addresses - so one /32 route per static customer. I don't see how one /[48|56|whatever] per customer is any different.

Here in the UK at least, some ISPs clearly have no problem with fixed addresses. Plusnet, for example, allow the end user to set their connection to a fixed address and nothing else changes other than the CPE being allocated the same address all the time. Sadly they ran a couple of IPv6 trials years ago and nothing has happened since :-(

v2.23.0 | Report a Bug | By Email