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

Lee Howard <lee@asgard.org> Tue, 19 February 2019 15:29 UTC

Return-Path: <lee@asgard.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 883DE12870E for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 07:29:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 h_l2QdIObe_p for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 07:29:47 -0800 (PST)
Received: from atl4mhob21.registeredsite.com (atl4mhob21.registeredsite.com [209.17.115.115]) by ietfa.amsl.com (Postfix) with ESMTP id B6A73130E0A for <ipv6@ietf.org>; Tue, 19 Feb 2019 07:29:45 -0800 (PST)
Received: from mailpod.hostingplatform.com (atl4qobmail02pod6.registeredsite.com [10.30.71.210]) by atl4mhob21.registeredsite.com (8.14.4/8.14.4) with ESMTP id x1JFThYw004792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <ipv6@ietf.org>; Tue, 19 Feb 2019 10:29:43 -0500
Received: (qmail 20391 invoked by uid 0); 19 Feb 2019 15:29:43 -0000
X-TCPREMOTEIP: 68.100.71.215
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.1.135?) (lee@asgard.org@68.100.71.215) by 0 with ESMTPA; 19 Feb 2019 15:29:42 -0000
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: ipv6@ietf.org
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.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> <9CDF41CA-83B4-4FC4-B995-EF79727C5458@steffann.nl> <CAO42Z2wA+vLmU7+sU6xLK7TO6pWfNQA5shs9zp=PqANCihLmBQ@mail.gmail.com> <BAB3061A-1808-4C0E-AA1B-2D7DD5BA63FC@employees.org>
From: Lee Howard <lee@asgard.org>
Message-ID: <4d19605a-3a6f-2266-dd9c-9d30cb25c813@asgard.org>
Date: Tue, 19 Feb 2019 10:29:42 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <BAB3061A-1808-4C0E-AA1B-2D7DD5BA63FC@employees.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yxs_yc0Q--SykKRe_RqZbYXunx0>
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, 19 Feb 2019 15:29:49 -0000

On 2/19/19 7:22 AM, Ole Troan wrote:
>>>> 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
>>>
>> It's not a hard requirement to aggregate prefixes at the individual
>> BNG level, and most ISPs should be running BGP to carry customer
>> routes. Obviously BGP to scale to 100s of 1000s of routes because the
>> Internet runs with it.
>>
>> The minimum PD stability needed for fixed access customers (e.g. ADSL,
>> FTTH etc.) is within the pool of BNGs they can attach to upon
>> reconnection. So if you need or want to aggregate those routes, you
>> place the BGP route aggregation boundary at the boundary of your BNG
>> pool, rather than at the individual BNG. You then say to your
>> customers that if they physically move their service by e.g. moving
>> house, they may not receive the same stable PD prefix again, because
>> you're not guaranteeing they will reconnect to the same BNG pool.
>>
>> It would however be nice to try to provide the customer with a stable
>> prefix on a greater scale than just within the same BNG pool, so you
>> could pick greater geographic boundaries for your aggregation points,
>> rather than at the boundary of an individual BNG pool. For example,
>> here in Australia, I'd try to aim for that boundary to be at each of
>> the 7 capital city boundaries, even though I may have multiple PoPs
>> within a city, with each PoP containing a number of BNGs in a pool
>> (and possibly multiple BNG pools within a PoP). Smaller aggregation
>> domains e.g. dividing cities into 4 regions might be necessary
>> depending on numbers of subscribers.
>>
>> You can still provide a guaranteed static and persistent PD prefix to
>> customers that want to pay for it, which means that prefix isn't ever
>> aggregated and can follow them regardless of where they geographically
>> because you never aggregate that prefix. They're paying for and
>> getting more value because they're getting a guarantee.
> Indeed. Wonder how these pesky mobile phone operators manage to deliver the same telephone number to a user, for years. Across different providers and contracts.
> I can’t think this argument is anything but a strawman.

You are saying he (maybe others) is either a liar, intentionally 
creating false arguments, or a fool, not understanding the network.

Your insinuation that fixed network operators must be doing something 
fundamentally wrong because mobile voice networks work differently is 
ignorant and insulting.

That's out of line for a working group chair.

>
> There’s nothing a bit of regulation can’t fix. :-)

Because of the smiley I don't know how to interpret this. Either you 
actually think regulation would work, and the question is whether you 
mean governmental or IETF, or you don't, in which case there's no 
argument that 6man should tell network operators they're doing it wrong.

Lee



>
> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------