Prefix deprecation for 'draft-templin-6man-rio-redirect'
"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 14 November 2017 09:40 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11627129400 for <email@example.com>; Tue, 14 Nov 2017 01:40:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([188.8.131.52]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gltFDv2DXsie for <firstname.lastname@example.org>; Tue, 14 Nov 2017 01:40:52 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [184.108.40.206]) (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 797EF1293EC for <email@example.com>; Tue, 14 Nov 2017 01:40:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vAE9epc7056778; Tue, 14 Nov 2017 02:40:51 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [220.127.116.11]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vAE9elZl056766 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 14 Nov 2017 02:40:47 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 14 Nov 2017 01:40:47 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([18.104.22.168]) by XCH15-06-08.nw.nos.boeing.com ([22.214.171.124]) with mapi id 15.00.1320.000; Tue, 14 Nov 2017 01:40:47 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "firstname.lastname@example.org" <email@example.com>, Lorenzo Colitti <firstname.lastname@example.org>
Subject: Prefix deprecation for 'draft-templin-6man-rio-redirect'
Thread-Topic: Prefix deprecation for 'draft-templin-6man-rio-redirect'
Date: Tue, 14 Nov 2017 09:40:46 +0000
Content-Type: text/plain; charset="utf-8"
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2017 09:40:55 -0000
Hi Lorenzo, I'm not sure if I fully answered your question, but let me see if I can talk through it here. I am assuming a large link with many nodes - as many as you like. The Source node sends a packet via a Router which forwards the packet to a Target node on the link. At the same time, the Router returns a Redirect message to the source with an RIO option that contains the prefix that matches the destination address of the packet and that has been delegated to the Target. When the Source gets the Redirect, it sends an NS to the Target with an RIO that includes the prefix learned from the Router and with the "S" bit set to 1 to SOLICIT the prefix. When the Target receives the NS message, it returns an NA message with the RIO with a correct route lifetime value and with the "S" bit set to 0 to ASSERT the prefix. The Source now has the prefix and prefix lifetime for the Target. Your question is what happens when the Target's prefix is invalidated; perhaps as part of a site renumbering event. In that case, the Target remembers all of the Sources that it has previously sent solicited NA messages to, and sends them an unsolicited NA with the prefix and with its lifetime set to 0. In the use cases I am considering, I am expecting that even though there may be arbitrarily many nodes on the link each node is likely to have only a few active correspondents. So, it would not be the case that the node would have to send huge numbers of unsolicited NAs. It could also send the unsolicited NAs as multicast so that a single NA is received by many correspondents, but that might not be scalable for really large links. Another factor would be for the Target to set short route lifetimes; maybe something like 100sec as opposed to hours/days/weeks. In that way, routes will time out if a neighbor somehow misses getting the unsolicited NA. Also, the Target can send Destination Unreachable if its former prefix becomes invalidated. So, there are several factors that would mitigate the situation you were concerned with. There is already some text along these lines in Sections 4.4.3 and 4.7 in the draft. Do you think there should be any changes there? Thanks - Fred
- Prefix deprecation for 'draft-templin-6man-rio-re… Templin, Fred L