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

Lee Howard <lee@asgard.org> Fri, 15 February 2019 19:28 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 E963E130FF6 for <ipv6@ietfa.amsl.com>; Fri, 15 Feb 2019 11:28:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 t4dkKCmS7nGx for <ipv6@ietfa.amsl.com>; Fri, 15 Feb 2019 11:28:19 -0800 (PST)
Received: from atl4mhob11.registeredsite.com (atl4mhob11.registeredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id 38A6B130FE6 for <ipv6@ietf.org>; Fri, 15 Feb 2019 11:28:16 -0800 (PST)
Received: from mailpod.hostingplatform.com (atl4qobmail02pod6.registeredsite.com [10.30.71.210]) by atl4mhob11.registeredsite.com (8.14.4/8.14.4) with ESMTP id x1FJSClJ009723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <ipv6@ietf.org>; Fri, 15 Feb 2019 14:28:14 -0500
Received: (qmail 20301 invoked by uid 0); 15 Feb 2019 19:28:12 -0000
X-TCPREMOTEIP: 174.64.33.182
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 15 Feb 2019 19:28:12 -0000
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: ipv6@ietf.org
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.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> <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>
From: Lee Howard <lee@asgard.org>
Message-ID: <ff649810-7242-7bc2-d36f-3f998f7bdd71@asgard.org>
Date: Fri, 15 Feb 2019 14:28:10 -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: <463f15cf-2754-e2e8-609d-dc0f33448c6c@go6.si>
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/9xTsrWzLNcIOZxGMmJtHtLcfhes>
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: Fri, 15 Feb 2019 19:28:23 -0000

On 2/15/19 4:30 AM, Jan Zorz - Go6 wrote:
> /64 for each device is fine. What I'm questioning is if we really need 
> to make underlying to be something that was never meant to be if L7 
> and above is broken? I think L7 and above needs to be fixed first and 
> then changing of addresses in transport layer can have any effect. 
> Until then - let's transport packets in a way that doesn't break often 
> and make user grumpy.
>
If the problem is above layer 7, it's not in scope for the IETF. You 
might try HRPC.

In another message you said:


Nick Hilliard>> The ietf isn't going to get operator buy-in for 
mandating static v6 prefix assignments.

Jan Zorz> 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?


Seems to me several operators have offered their opinions here. If you 
want more opinions, maybe ask a group of operators?

Lee