IETF Logo Mail Archive

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

Sander Steffann <sander@steffann.nl> Fri, 15 February 2019 21:20 UTC

Return-Path: <sander@steffann.nl>
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 4AD77131028 for <ipv6@ietfa.amsl.com>; Fri, 15 Feb 2019 13:20:34 -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=steffann.nl
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 harC_xaKcWaK for <ipv6@ietfa.amsl.com>; Fri, 15 Feb 2019 13:20:32 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 C98C312426A for <ipv6@ietf.org>; Fri, 15 Feb 2019 13:20:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 3698D4A; Fri, 15 Feb 2019 22:20:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1550265626; bh=4jUXW1+Djxu54qdhmJN iKOZXlZnI30HRtbej4KJq2xE=; b=TRepvJE2SgAaSsly+lnOsfR3eS7zXpX4321 9IDmUSKDKrQLTZGFZ8bQo7oPYAUPqG00xIieWs6wKLK3mrmaVsD3LgduIWGO2X8i mhac6p6/dxNGx0N6nJeVzvpJ/mPKylkfGGWto1EaSov/6rjpNi6c863t6zQKU2sw D5Pqqz+A=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DT8kLfubfaNp; Fri, 15 Feb 2019 22:20:26 +0100 (CET)
Received: from [IPv6:2a02:a213:a300:ce80::10] (unknown [IPv6:2a02:a213:a300:ce80::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id CCF3849; Fri, 15 Feb 2019 22:20:25 +0100 (CET)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Message-Id: <9CDF41CA-83B4-4FC4-B995-EF79727C5458@steffann.nl>
Content-Type: multipart/signed; boundary="Apple-Mail=_607E630C-5350-48EE-8FE4-D3A2CB166AEB"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
Date: Fri, 15 Feb 2019 22:20:24 +0100
In-Reply-To: <ff649810-7242-7bc2-d36f-3f998f7bdd71@asgard.org>
Cc: ipv6@ietf.org
To: Lee Howard <Lee@asgard.org>
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>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6mPP1cKhesKeRSVqOxGCy_OLWqE>
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:20:34 -0000

Hi Lee,

> Seems to me several operators have offered their opinions here. If you want more opinions, maybe ask a group of operators?

Not a very helpful comment... 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

With IPv4 this didn't cause massive problems because NAT disconnected the LAN addresses from the WAN side at the customer's end. With IPv6 this is no longer the case and it does cause problems.

Stability at one end causes instability at the other end, and vice versa.
And as can be seen from this discussion it's still an unsolved problem...

Cheers,
Sander

v2.23.0 | Report a Bug | By Email