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

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Nov 2017 09:40:46 +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