Prefix deprecation for 'draft-templin-6man-rio-redirect'

"Templin, Fred L" <> Tue, 14 November 2017 09:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11627129400 for <>; Tue, 14 Nov 2017 01:40:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gltFDv2DXsie for <>; Tue, 14 Nov 2017 01:40:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 797EF1293EC for <>; Tue, 14 Nov 2017 01:40:52 -0800 (PST)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vAE9epc7056778; Tue, 14 Nov 2017 02:40:51 -0700
Received: from ( []) by (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 (2002:8988:eede::8988:eede) by (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 ([]) by ([]) with mapi id 15.00.1320.000; Tue, 14 Nov 2017 01:40:47 -0800
From: "Templin, Fred L" <>
To: "" <>, Lorenzo Colitti <>
Subject: Prefix deprecation for 'draft-templin-6man-rio-redirect'
Thread-Topic: Prefix deprecation for 'draft-templin-6man-rio-redirect'
Thread-Index: AdNdKIjKGXdvOekgSZqgQSONCPvpkw==
Date: Tue, 14 Nov 2017 09:40:46 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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