Re: [v6ops] Stability and Resilience (was Re: A common...)

Owen DeLong <owen@delong.com> Fri, 22 February 2019 17:04 UTC

Return-Path: <owen@delong.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 0CA55130F06; Fri, 22 Feb 2019 09:04:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com
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 iC28CaRHPLxE; Fri, 22 Feb 2019 09:04:44 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3D0130EEE; Fri, 22 Feb 2019 09:04:43 -0800 (PST)
Received: from [IPv6:2620::930:0:cd1e:5233:3f23:c8d8] ([IPv6:2620:0:930:0:cd1e:5233:3f23:c8d8]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id x1MH4cMX029861 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Feb 2019 09:04:38 -0800
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com x1MH4cMX029861
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1550855078; bh=UfrKlN71t6uJn1zCbFV4gpxoNRnlCMt8Rd2csgQWMt4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=4Q+s3zexEScOXvn37gLRm7Vmq/LbzpAAxot2WfH4MpU/ErMN5Mgfq3GdG2WCrFkGJ Ojq8jGc5qKw1E2//boU3OGoRW84D6M8wWf5lj47CgOnBc+5wR4wUqRa8qJhy7BeIxW b8k1Y+hitp+G/N4ym2HkWkzUxdIMArioY90f4jY4=
Content-Type: multipart/alternative; boundary="Apple-Mail-3E243873-3335-4E4B-9059-B59F46846C6B"
Mime-Version: 1.0 (1.0)
From: Owen DeLong <owen@delong.com>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org>
Date: Fri, 22 Feb 2019 09:04:38 -0800
Cc: ipv6@ietf.org, IPv6 Ops WG <v6ops@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <DD0A06B0-C704-451C-AA43-CAF420F24B4D@delong.com>
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <B6E2EC33-EEAF-40D0-AFCC-BDAFA9134ACD@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net> <CAO42Z2wmB2W52b4MZ2h9sW5E9cQKm-HRjyf--q8C26jezS7LXQ@mail.gmail.com> <a73818d31db7422b99a524bc431b00ed@boeing.com> <CAO42Z2z9-48Gbb_Exf+oWUqDO=axSLpZBtqeDcxkAoFq5OziGw@mail.gmail.com> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org>
To: Lee Howard <lee@asgard.org>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 22 Feb 2019 09:04:38 -0800 (PST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_otaKlTKnEiAewNrP_V6UNZD-tc>
Subject: Re: [v6ops] Stability and Resilience (was Re: A common...)
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, 22 Feb 2019 17:04:46 -0000

> Networks should, as much as possible, be resilient to prefix changes. Some things networks can do to improve resilience:
> Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew for that prefix on reboot.
> Use dynamic DNS and shorter TTLs.
> Implement something like NETCONF to distribute prefix information to policy devices like firewalls or SD-WAN controllers. I think a separate document describing this application of NETCONF would make sense.

If the prefix is written to nv men, wouldn’t it also be possible for implementers to send rapid deprecation RAs for any prefix not renewed?

In other words, after reboot, try to reacquire same prefix. If that doesn’t work, when you advertise the new prefix, you could also include the old prefix with a very short preferred and valid lifetime (e.g. 1 second) in the first RA, which should be sent to the all nodes on link multicast?

It doesn’t eliminate the problem, but 1 second additional duration would be barley noticeable amid the minute or so it takes most home gateways to reboot. 

Owen