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

Jan Zorz - Go6 <jan@go6.si> Thu, 14 February 2019 11:55 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 8702C131163 for <ipv6@ietfa.amsl.com>; Thu, 14 Feb 2019 03:55: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, 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 emIYzDa2WQZG for <ipv6@ietfa.amsl.com>; Thu, 14 Feb 2019 03:55:08 -0800 (PST)
Received: from mx.go6lab.si (mx.go6lab.si [IPv6:2001:67c:27e4::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 99ECD130EB3 for <ipv6@ietf.org>; Thu, 14 Feb 2019 03:55:07 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 568ED660C4 for <ipv6@ietf.org>; Thu, 14 Feb 2019 12:55:04 +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 211dqCXpzOQi for <ipv6@ietf.org>; Thu, 14 Feb 2019 12:55:03 +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 0E79865E78 for <ipv6@ietf.org>; Thu, 14 Feb 2019 12:55:03 +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 62D51805A2 for <ipv6@ietf.org>; Thu, 14 Feb 2019 12:55:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1550145302; bh=N9GZHt+wVLwM1AiQp/PobPIhmjBXLkyH+c2igLryZdU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=VpK5OZ3/u1cEH+elWdvYBKDzm1c0U4x18VXiE5RPe9QTZeHiQD/JuT5h0wU8EfEzk YZmQZdi5LLIehVFzYkl3k/TnNObppJnh3FlEftZJWyQnXYvVn/g3TUjdcIVTMuwq+C lTCJ61xynIheZ+nlAdPtShOspW7egvxVZE8CFsQk=
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: ipv6@ietf.org
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <D1E45CAD-08D0-43D4-90F7-C4DD44CB32C0@employees.org> <alpine.DEB.2.20.1902041330531.23912@uplift.swm.pp.se> <46B8DB92-DC81-4242-9780-0D00FB6BDB7A@employees.org> <1c7ebabb-d6f6-d877-d4aa-d6c0fc7d5c60@go6.si> <6278.1549471453@dooku.sandelman.ca> <CAO42Z2xdKtLJV11KXELBKca6CWn=B6Avz6bO_94kFFXaKiZ-pQ@mail.gmail.com> <4602.1549908472@localhost> <CAO42Z2w1swQNuwnrOyTCEMXt0NSyrBx7Ww3kUN-7dfEV=fvk3A@mail.gmail.com> <c16e0e1f-1ed2-ad88-80f1-070bdd8bccca@go6.si> <1F2C2AEE-1C7D-481C-BBA7-7E507312C53A@employees.org> <e56a6e5b-648d-200e-c35d-97f15a31fb2a@asgard.org> <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> <97249859-2a3d-75f7-6bb8-6b9563c99d08@foobar.org>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <eb64fe1b-132d-b2f5-3511-4dcb557fc94a@go6.si>
Date: Thu, 14 Feb 2019 12:55:01 +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: <97249859-2a3d-75f7-6bb8-6b9563c99d08@foobar.org>
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/rqIrc7uPFZRJqKCoy5DgDdSRMhk>
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: Thu, 14 Feb 2019 11:55:09 -0000

On 14/02/2019 12:07, Nick Hilliard wrote:
> JORDI PALET MARTINEZ wrote on 14/02/2019 10:21:
>> Why not? This is already happening in IPv4. I've got from a major
>> operator in Spain (and other operators in other countries do the
>> same), the same IPv4 address for decades! I'm talking about
>> residential services, with both DSL and GPON. Not to mention business
>> services were you actually pay for that static address a monthly
>> fee.
> 
> The ietf isn't going to get operator buy-in for mandating static v6 
> prefix assignments.

This is clear and understandable. Do you think they would buy-in the 
advice, that they need to honor the lifetime of a prefix to same DUID 
and give the same PD until it expires, unless there is an urgent network 
design change (moving customers to different BNG, emergency re-route 
because of outage, etc...) and at the same time make sure that CPE sends 
out RA packets with decrementing lifetime on LAN side, according to 
lifetime of PD?

Because at it stands now (if you are not the one with home-brew CPE 
where you fixed this with persistent storage of PD across reboots) - the 
only option that actually works on the field is to give users persistent 
prefixes and that's a fact that operators at large agreed about in 
RIPE-690 document.

So, at the end of a day, it may be in operators interest that we somehow 
fix the whole spaghetti chain between ISP and customer and give the 
advice how to make all 3 points in the network more robust and better 
cooperating between each other when it comes to IPv6...

Cheers, Jan