IETF Logo Mail Archive

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

Jan Zorz - Go6 <jan@go6.si> Tue, 05 February 2019 15:40 UTC

Return-Path: <jan@go6.si>
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 13E551310F9 for <ipv6@ietfa.amsl.com>; Tue, 5 Feb 2019 07:40:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=go6.si
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 0risycFqqvKI for <ipv6@ietfa.amsl.com>; Tue, 5 Feb 2019 07:40:05 -0800 (PST)
Received: from mx.go6lab.si (mx.go6lab.si [91.239.96.23]) (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 980BB1200D7 for <ipv6@ietf.org>; Tue, 5 Feb 2019 07:40:05 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 7F318603E3; Tue, 5 Feb 2019 16:40:01 +0100 (CET)
X-Virus-Scanned: amavisd-new at go6.si
Received: from mx.go6lab.si ([IPv6:::1]) by localhost (mx.go6lab.si [IPv6:::1]) (amavisd-new, port 10024) with LMTP id REiqw0Vp8-cf; Tue, 5 Feb 2019 16:40:00 +0100 (CET)
Received: from mail.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.go6.si", Issuer "Let's Encrypt Authority X3" (not verified)) by mx.go6lab.si (Postfix) with ESMTPS id A5E8560343; Tue, 5 Feb 2019 16:39:59 +0100 (CET)
Received: from ISOC-BMDKQ4.local (unknown [IPv6:2001:67c:27e4:102:182a:e622:682:93c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Jan Zorz", Issuer "COMODO RSA Client Authentication and Secure Email CA" (not verified)) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id 0E17F805A2; Tue, 5 Feb 2019 16:39:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1549381198; bh=3KKhtyBxlLKa0t8fVSIj8zJqcx5UbQzE7xneCRr897k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZA1c/iuiWxwYVIjrqsxY5IWhMls9uRYhnVg0A4rhW0bTcnxpf2O8a5KLhARyrA4pt ja0V6udwvbAenlvED8mKJ2Jx8rxB1bVZh0lE2CQSCrCLEyiGTJ5BRjOn7gYJ+t3yOu ijX9J3gWXCkJM6I15TmL3FglmyafyGhxQssY3LE8=
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Mark Smith <markzzzsmith@gmail.com>
Cc: 6man WG <ipv6@ietf.org>
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> <62b74cf1-9cb0-bba3-b078-cb6f48e90145@foobar.org> <m1gqeb9-0000GCC@stereo.hq.phicoh.net> <bc8c0ef9-2c24-1c2a-9822-8580e6e1858c@go6.si> <CAO42Z2w2FdcumHTY6S2GuUi4pfbHrc6dihKvDtL3mHUykkOPZw@mail.gmail.com>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <6dc0dbea-44fc-96df-c9dd-313d4385d19a@go6.si>
Date: Tue, 05 Feb 2019 16:39:56 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <CAO42Z2w2FdcumHTY6S2GuUi4pfbHrc6dihKvDtL3mHUykkOPZw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/eg3hY1isZhlrKA6Ac7T_cDk9npI>
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, 05 Feb 2019 15:40:12 -0000

On 05/02/2019 12:49, Mark Smith wrote:
>>     That seems to be the core of the problem, me think :) BRAS-es with
>>     defined IPv6 pools assigning PD-s randomly, regardless of anything and
>>     everything.
>> 
> I don't know about other implementations, however Cisco IOS XE can 
> source stable prefix information for the BNG DHCPv6 server from RADIUS 
> per RFC4818.

That is clear and that works quite well. Problem is that this requires 
quite some work for operators to implement (extend the radius database, 
fill in all the prefixes, make all your provisioning and billing systems 
aware of that change and so on...), so many of them cuts the corners and 
simply assigns a big IPv6 prefix to that BNG/BRAS as a "pool" where 
BNG/BRAS allocates prefixes to customers "at it's will". It's fast, it's 
simple and works in a lab environment.

That's the behaviour that needs to stop.

Cheers, Jan

v2.23.0 | Report a Bug | By Email