RE: draft-ietf-6man-slaac-renum: Text for the heuristics (Section 4.5)
Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 15 August 2022 10:33 UTC
Return-Path: <vasilenko.eduard@huawei.com>
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 C7814C1522B0 for <ipv6@ietfa.amsl.com>; Mon, 15 Aug 2022 03:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVvwhrBZC2fh for <ipv6@ietfa.amsl.com>; Mon, 15 Aug 2022 03:33:54 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96665C14CE47 for <6man@ietf.org>; Mon, 15 Aug 2022 03:33:54 -0700 (PDT)
Received: from fraeml734-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4M5r9Y1vgDz67bhc for <6man@ietf.org>; Mon, 15 Aug 2022 18:29:05 +0800 (CST)
Received: from mscpeml100001.china.huawei.com (7.188.26.227) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 15 Aug 2022 12:33:52 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml100001.china.huawei.com (7.188.26.227) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 15 Aug 2022 13:33:51 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.024; Mon, 15 Aug 2022 13:33:51 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Fernando Gont <fgont@si6networks.com>, "6man@ietf.org" <6man@ietf.org>
Subject: RE: draft-ietf-6man-slaac-renum: Text for the heuristics (Section 4.5)
Thread-Topic: draft-ietf-6man-slaac-renum: Text for the heuristics (Section 4.5)
Thread-Index: AQHYrnZCnyxkVldvC0yHDPg2Xibn8K2vx3Dg
Date: Mon, 15 Aug 2022 10:33:51 +0000
Message-ID: <9ecf0e7783fa4c72ae63dfd2bb1d795c@huawei.com>
References: <020f2bf2-a381-ed7c-203b-3bfeb02921e2@si6networks.com>
In-Reply-To: <020f2bf2-a381-ed7c-203b-3bfeb02921e2@si6networks.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.202.180]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SSqIhh-GnUW-qlNlrQGUCqAwBAQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 15 Aug 2022 10:33:56 -0000
Hi Fernando, Currently, you have no right to send RS at the time you wish (RFC 4861 prohibits it for you). Hence you need to release this restriction https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-02#section-6.8 Eduard -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Fernando Gont Sent: Friday, August 12, 2022 9:05 PM To: 6man@ietf.org Subject: draft-ietf-6man-slaac-renum: Text for the heuristics (Section 4.5) Folks, As discussed during my presentation at the last 6man wg meeting, this is the text for the heuristics to deprecate stale information: Your input/reviews will be highly appreciated! ---- cut here ---- 4.5. Recovery from Stale Configuration Information without Explicit Signaling This section specifies an algorithm, "Lifetime Avoidance Algorithm" (LTA), that allows hosts to infer when previously-advertised information (such as autoconfiguration prefixes) has become stale, such that the stale configuration information can be deprecated in a timelier manner. Most of the value of this algorithm is in being able to mitigate the problem discussed in [RFC8978] at hosts themselves, without relying on updates of the behavior of local routers. The algorithm consists of two conceptual building-blocks: * Detection of possible configuration change * Validation/Refresh of configuration information Possible configuration changes can be inferred when a SLAAC router (as identified by its link-local address) ceases to advertise a previously-advertised information. In such scenarios, nodes should poll the local router via unicasted Router Solicitations (RS) to verify that the router in question has indeed ceased to advertise the aforementioned information. And, in such cases the associated configuration information may be discarded. Please note that in the context of multi-prefix/multi-router networks [RFC8028] [RFC8504], SLAAC configuration information should be associated with each advertising router. Thus, when a router ceases to advertise some configuration information: * If this was the only router advertising the aforementioned information, the associated information should be discarded. * If other routers were advertising the aforementioned information, this information should simply be dis-associated with the router that ceased to advertise it, and the fate of this information (and configured resources) should depend solely on the routers that continue advertising it. Implementation of this kind of heuristic allows a timelier reaction to network configuration changes even in scenarios where there is no explicit signaling from the network, thus improving robustness. As discussed in Section 4.4, [RFC4861] does not require routers to convey all RA options in the same message. Therefore, the algorithm specified in this section is designed such that it can cope with this corner case that, while not found in the deployed Internet, could still theoretically exist. 4.5.1. Target Neighbor Discovery Options The LTA algorithm SHOULD be applied to the following Neighbor Discovery options: * Prefix Information Option [RFC4861] * Route Information Option (RIO) [RFC4191] * DNS Search Options (RDNSSO) [RFC8106] * DNS Search List Options (DNSSLO) [RFC8106] 4.5.2. Configuration Variables and Local State Information In the context of multi-prefix/multi-router networks [RFC8028] [RFC8504], each option from Section 4.5.1 is associated with each advertising SLAAC router. NOTE: Throughout this specification, each router is identified by its link-local address. Additionally, hosts will augment state information for each option with a timestamp (OPT_LAST variable bellow) that records the time at which the option was last advertised by a particular router. NOTE: While not strictly required, we note that existing implementations may already record the last time an option was advertised by a given router as a possible implementation approach to be able to compute the remaining lifetime of the option. The algorithm employs the following variables: LTA_MODE: A boolean variable associated with each SLAAC advertising router that specifies whether the local host is currently performing the LTA algorithm for that router. It is initialized to FALSE. LTA_LAST: A variable associated with each SLAAC advertising router that stores the time (in seconds) when the local host last entered the LTA algorithm for this router. It is initialized to 0. RS_LAST: A variable associated with each SLAAC advertising router that stores the time (in seconds) when the local host last sent a unicasted Router Solicitation to the router in question. It is initialized to 0. RS_COUNT: A variable associated with each SLAAC advertising router that stores the number of unicasted Router Solicitations that have been set to the associated router since the last time the LTA algorithm was executed. It is initialized to 0. RS_COUNT_MAX: A configuration variable specifying the maximum number of unicasted Router Solicitations that a host will send to a SLAAC advertising router as part of the LTA algorithm. It defaults to 1. RS_RNDTIME: A host-wide variable specifying a random amount of time the host should wait before sending the first unicasted Router Solicitation message to a SLAAC router as part of the LTA algorithm. It should be initialized to a value in the range from 0 to 10 seconds when the system is bootstrapped. RS_TIMEOUT: A host-wide variable specifying the amount of time to wait for a response to a unicasted Router Solicitation sent as part of the LTA algorithm. OPT_LAST: A timestamp associated with each option (from Section 4.5.1) received from each SLAAC advertising router. It is set to the current system time. RA_WIN: A host-wide configuration variable specifying a time window over which a SLAAC advertising router may convey all SLAAC configuration information. It is meant to cope with the theoretical case where a router may spread SLAAC information over several RA messages. It defaults to 3 seconds. LTA_CYCLE: This variable accounts for the maximum time that may elapse for the entire LTA algorithm. It is used as a shortcut throughout the algorithm. Its value is computed as: LTA_CYCLE=RA_WIN+RS_RNDTIME+RS_COUNT_MAX*RS_TIMEOUT. 4.5.3. Algorithm Specification Initialization when a new SLAAC advertising router is learned: LTA_MODE=FALSE LTA_LAST=0 RS_LAST=0 RS_COUNT=0 LTA_CYCLE=RA_WIN+RS_RNDTIME+RS_COUNT_MAX*RS_TIMEOUT Upon receipt of a Router Advertisement message, and after normal processing of the message, perform the following actions: TIME= time() For each option advertised by this router in the received RA: OPT_LAST= time() IF LTA_MODE==FALSE && TIME > (LTA_LAST+LTA_CYCLE) IF the RA is missing any previously-received information: LTA_MODE=TRUE LTA_LAST=TIME Time-driven events: IF LTA_MODE==TRUE: TIME=time() IF TIME > (LTA_LAST + RA_WIN + RS_RNDTIME) && TIME > (RS_LAST + RS_TIMEOUT) && RS_COUNT < RS_COUNT_MAX: SendRS() RS_LAST=TIME RS_COUNT++ IF TIME > (LTA_LAST + LTA_CYCLE) Disaasociate any options for which OPT_LAST < LTA_LAST LTA_MODE= FALSE RS_COUNT=0 NOTES: * time() is a monotonically-increasing counter that is incremented once per second, and is employed to measure time. * SendRS() is a function sends a unicasted Router Solicitation message to the target router (subject to sending rules in [RFC4861]). ---- cut here ---- Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- draft-ietf-6man-slaac-renum: Text for the heurist… Fernando Gont
- RE: draft-ietf-6man-slaac-renum: Text for the heu… Vasilenko Eduard
- Re: draft-ietf-6man-slaac-renum: Text for the heu… Ted Lemon
- Re: draft-ietf-6man-slaac-renum: Text for the heu… Fernando Gont
- Re: draft-ietf-6man-slaac-renum: Text for the heu… Fernando Gont
- RE: draft-ietf-6man-slaac-renum: Text for the heu… Vasilenko Eduard
- RE: draft-ietf-6man-slaac-renum: Text for the heu… Vasilenko Eduard