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

Lee Howard <lee@asgard.org> Tue, 19 February 2019 15:20 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 382221310CD for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 07:20:53 -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 q8qevEstapnf for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 07:20:49 -0800 (PST)
Received: from atl4mhob08.registeredsite.com (atl4mhob08.registeredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id 70393130F6C for <ipv6@ietf.org>; Tue, 19 Feb 2019 07:20:48 -0800 (PST)
Received: from mailpod.hostingplatform.com (atl4qobmail01pod6.registeredsite.com [10.30.71.209]) by atl4mhob08.registeredsite.com (8.14.4/8.14.4) with ESMTP id x1JFKiaj008555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <ipv6@ietf.org>; Tue, 19 Feb 2019 10:20:44 -0500
Received: (qmail 29812 invoked by uid 0); 19 Feb 2019 15:20:44 -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:20:44 -0000
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Mark Smith <markzzzsmith@gmail.com>, Sander Steffann <sander@steffann.nl>
Cc: 6man WG <ipv6@ietf.org>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <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> <9CDF41CA-83B4-4FC4-B995-EF79727C5458@steffann.nl> <CAO42Z2wA+vLmU7+sU6xLK7TO6pWfNQA5shs9zp=PqANCihLmBQ@mail.gmail.com>
From: Lee Howard <lee@asgard.org>
Message-ID: <e894def8-ee0d-16a6-691c-5e41c56578e8@asgard.org>
Date: Tue, 19 Feb 2019 10:20: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: <CAO42Z2wA+vLmU7+sU6xLK7TO6pWfNQA5shs9zp=PqANCihLmBQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/TdC4u-1Lkmz8KJVqhi1Fd07CUSw>
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:20:54 -0000

On 2/19/19 7:14 AM, Mark Smith wrote:
> On Sat, 16 Feb 2019 at 08:20, Sander Steffann <sander@steffann.nl> wrote:
>> 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
>>
> 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.
Thank you for telling me what protocol I should be using in a specific 
part of my network.
>
> 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.

You seem to be arguing that the network engineers and architects at very 
large ISPs do not understand their network or routing or equipment. You 
are telling people how to design and build their networks.

>
> 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.
Cool. Go ahead and build your network your way.
>
> 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.

You can do whatever you like on your network.

Lee

>
>
>
>> 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
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------