Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Fernando Gont <fgont@si6networks.com> Fri, 25 October 2019 17:52 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC95120A08 for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2019 10:52:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 l2Eh-DArkotk for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2019 10:52:51 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE03E1209DD for <v6ops@ietf.org>; Fri, 25 Oct 2019 10:52:50 -0700 (PDT)
Received: from [IPv6:2804:431:c7f3:bff2:b8b3:4400:3123:ecb7] (unknown [IPv6:2804:431:c7f3:bff2:b8b3:4400:3123:ecb7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 00F0F864E1; Fri, 25 Oct 2019 19:52:47 +0200 (CEST)
To: Ole Troan <otroan@employees.org>
Cc: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, v6ops list <v6ops@ietf.org>
References: <860c946a-c23c-4060-d83c-587302de28f8@si6networks.com> <5A20C8D8-3A42-464D-9D6D-79F1567B6FA4@employees.org>
From: Fernando Gont <fgont@si6networks.com>
Openpgp: preference=signencrypt
Message-ID: <1a07be3c-90bb-5182-1a11-5e94fbbacf44@si6networks.com>
Date: Fri, 25 Oct 2019 14:52:26 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <5A20C8D8-3A42-464D-9D6D-79F1567B6FA4@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ucVtGg_90sNA6bwJwvFA89D2EeQ>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Oct 2019 17:52:55 -0000

On 25/10/19 14:40, Ole Troan wrote:
> 
> 
>> On 25 Oct 2019, at 19:34, Fernando Gont <fgont@si6networks.com> wrote:
>>
>>>> What about a "IPv6 renumbering considered harmful" or "Unstable DHCP-PD prefix considered harmful" ?
>>>
>>> Perhaps, but isn't there a long list of documents the IETF has produced on IPV6 renumbering already?
>>> Would a new document say anything new and more useful?
>>>
>>> And it's not like DHCPv6 PD (RFC3633) isn't clear either. From the abstract:
>>>
>>>   The Prefix Delegation options provide a mechanism for automated
>>>   delegation of IPv6 prefixes using the Dynamic Host Configuration
>>>   Protocol (DHCP).  This mechanism is intended for delegating a long-
>>>   lived prefix from a delegating router to a requesting router, across
>>>   an administrative boundary, where the delegating router does not
>>>   require knowledge about the topology of the links in the network to
>>>   which the prefixes will be assigned.
>>
>> Long-lived != immortal. As long as a prefix eventually changes, that is
>> when the problem may be experienced.
> 
> Not if renumbering of the network is done according to specification. 
> Flash renumbering is not defined so no-one should be surprised that you get undefined behavior. 

The "flash renumbering" could also happen if the CPE was trying to kind
of the right thing, the ISP does not employ stable prefixes, and the CPE
happens to crash and reboot. Some CPEs also reportedly do a "release"
when rebooted.

At the end of the day, what you get is a brittle network. And what we're
trying to do is exactly improving the robustness of the network.

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492