IETF Logo Mail Archive

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

Jan Zorz - Go6 <jan@go6.si> Tue, 05 February 2019 17:54 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 A57201311EE for <ipv6@ietfa.amsl.com>; Tue, 5 Feb 2019 09:54:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 Q0pGfzaH3ejK for <ipv6@ietfa.amsl.com>; Tue, 5 Feb 2019 09:54:52 -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 4806E1311D6 for <ipv6@ietf.org>; Tue, 5 Feb 2019 09:54:52 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 1F95965FC3; Tue, 5 Feb 2019 18:54:49 +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 RWY-_W4PLhN5; Tue, 5 Feb 2019 18:54:48 +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 0157D603E3; Tue, 5 Feb 2019 18:54:48 +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 B9542805A2; Tue, 5 Feb 2019 18:54:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1549389287; bh=DKNmHOTCHOhJaozZCQocfdkzf1Otn7wWfwrjr3ksttY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=arDETzS7SGqigUhXOmZwV8g6rnnZ8DeskPoDOIGWeBWSzj6LJ1hBW02y9b8Sv6h8i PDhQYL1FX/dTjjWsFzWM9wI0IB9olQ8MSLKiXWzWDZOFi0hj4TQwWJftFtChfcEQm+ OzEL5+Pm6hEImMnQQO3zx7wG4qcUqAGgMlz+pvnI=
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Richard Patterson <richard@helix.net.nz>
Cc: Mark Smith <markzzzsmith@gmail.com>, 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> <6dc0dbea-44fc-96df-c9dd-313d4385d19a@go6.si> <CAHL_VyBxSFXK-t723nFjHLB1GmuZEZzgS6k9oJ4v1qVJn=D1aQ@mail.gmail.com>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <0144bc11-bcfc-5d58-7564-47327a28e14b@go6.si>
Date: Tue, 05 Feb 2019 18:54:47 +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: <CAHL_VyBxSFXK-t723nFjHLB1GmuZEZzgS6k9oJ4v1qVJn=D1aQ@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/aOmXF1rjPGAuDZJvL5MQZEX6P7U>
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 17:54:59 -0000

On 05/02/2019 18:28, Richard Patterson wrote:
> On Tue, 5 Feb 2019 at 15:41, Jan Zorz - Go6 <jan@go6.si> wrote:
> 
>> 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.
> 
> Why?
> 

Here I'll have to repeat what Ole said at the beginning of this 
conversation. If you setup a lifetime of prefix delegation and assign it 
to CPE, then CPE expects to get the same prefix back at least for that 
period of time. That doesn't mean that you can assign prefixes at will 
at any time you want. You are breaking the "contract" to your customer 
(CPE). That's exactly the point where things break.

If you set a lifetime of assigned prefix to 24 hours and then change it 
- well, that's your decision, but you are not suppose to break the 
timers that you set yourself.

Cheers, Jan

v2.23.0 | Report a Bug | By Email