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

Jan Zorz - Go6 <jan@go6.si> Tue, 05 February 2019 20:09 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 0B360131210 for <ipv6@ietfa.amsl.com>; Tue, 5 Feb 2019 12:09:04 -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 9u658zvgafEI for <ipv6@ietfa.amsl.com>; Tue, 5 Feb 2019 12:09:01 -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 51E9F13120B for <ipv6@ietf.org>; Tue, 5 Feb 2019 12:09:01 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 4DE246601A; Tue, 5 Feb 2019 21:08:57 +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 JfMUAdnFyhQ4; Tue, 5 Feb 2019 21:08:55 +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 3857A603E3; Tue, 5 Feb 2019 21:08:55 +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 8CD55813D6; Tue, 5 Feb 2019 21:08:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1549397334; bh=ZZdZJzh6mYSDcRdOsDfRZj7F4HgjmqjaF3oVtOQi03I=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=MeLKFLphS2iJh4rsvZIZFFowPhE7wj/HyPE/opmC/v4v38oDjOq4cXVlKVyHcJMK8 LE/3xYS8w25BURJ1ptOfZc0iPX/bvrQ3LDUfqqoGEDdL/smlZisAVbiWKnDgMKFUuT 7Tj9u6VMbOx/umquF5ZpborLVJ++NVdBFrj0BMLs=
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> <0144bc11-bcfc-5d58-7564-47327a28e14b@go6.si> <CAHL_VyCOp5j-WJ02Q09FAv4sn=z4+_jUiRX5WKRRTPGpRB_uWQ@mail.gmail.com>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <04cbd1d7-25e8-81b3-783d-2b8f2462d335@go6.si>
Date: Tue, 05 Feb 2019 21:08:53 +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_VyCOp5j-WJ02Q09FAv4sn=z4+_jUiRX5WKRRTPGpRB_uWQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Bxuf2fu86zpAMBp4ZkVPrOtfUOg>
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 20:09:04 -0000

Richard,

On 05/02/2019 20:00, Richard Patterson wrote:
>      > 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.
> 
> 
> That's fine, except it doesn't really have anything to do with your 
> previous statement.  I can (and do) assign a single large prefix to each 
> BNG for the DHCPv6 server to assign dynamic PDs from, and still respect 
> the above assertions.

I said "where BNG/BRAS allocates prefixes to customers "at it's will"". 
I didn't say "after the lifetime has expired". But, nevertheless, I 
think you and I already had this conversation, didn't we?

You deeply understand what you are doing, you fixed your home-brew CPE 
(or vendors CPE for your use, it doesn't matter), implemented 
across-reboot PD memory and things work. Well done, congratulations!

But you are one operator on a big planet, where many other operators 
doesn't get nowhere near to your understanding of how to build that 
stuff and implement IPv6 in a proper way.

BTW, on a side note, hopefully you can come to SINOG this year and 
explain to our operators how you did exactly things that we are 
discussing here ;) (let's talk offline...)

> 
> We use 1 hour lease times.  If a CPE hasn't sent a Release, has the same 
> MAC address and DUID, it will continue to get the same PD after a 
> [hard|soft]-reboot.  In fact it can return anytime up to an arbitrary 
> value (7 days in my network), and still receive the same PD, if the 
> BNG/DHCPv6 server is configured to keep state for longer.
> 
> As just mentioned by Lee, we should be making sure that these protocols 
> are resilient to change, not dictating rigid network designs.

I'm with you. If we manage to fix CPE and host to be able to follow that 
dynamic topology changes - that would be a good thing to do anyway. I'm 
not at all encouraging operators to deploy dynamic PDs from many 
reasons, but if topology changes then CPE and hosts needs to be able to 
follow that change.

Cheers, Jan