Hi Woj,
On 10-08-25 04:31 AM, Wojciech Dec wrote:
Hi Suresh,
thanks for looking further into this problem, and publishing an updated
draft 07. Let me however stress that this problem is one very strictly
tied to the (supposed?) usage context of the RS-mark mechanism, and thus
it really needs to be described/addressed in the rs-mark draft, not some
other.
I respectfully disagree. Here's why. The RS-mark mechanism describes how
RSs are marked and how the responding solicited-RAs are sent. It has got
nothing to do with other neighbor discovery messages. e.g. Unsolicited
multicast RAs, Redirects, DAD NS/NAs, Address resolution NS/NAs etc.
which are sent as defined in RFC4861/62. The draft simply does not
mention anything about these other messages. If you can clarify why you
think this is relevant to this draft, I will certainly add it here.
The reason for this is simple: On regular SLAAC networks, RAs get
periodically ad-infinitum multicast to all nodes allowing such nodes to
perform SLAAC, thus the loss/timeout of a client in sending RSes does
not matter much.
In contrast, and in what I currently understand as the RS-mark usage
scenario to be, no such periodic multicast RA is sent until the client
sends an RS.
This is not true. The draft does not modify RFC4861/RFC4862 behavior in
any way for unsolicited multicast RAs.
> Hence, clients that time out from sending RSes have no
> chance of running SLAAC or connecting, other than perhaps through some
> manual intervention.
Draft 07 does not appear to address this issue, while it most definitely
should given its rather serious consequences for regular ICMPv6 clients.
Could you explain to us the mechanism from recovering from this problem
(eg CPE reload?)? On the email thread, there was mention of a) this
being an allowed un-recoverable failuire scenario or b) multicasting RAs
downstream. The text in draft 07 does not reflect either, so which one
is it?
Multicasting an RA is not optional. Period. So b) is a given. The draft
does not have to specify this. It needs to be done in any compliant
network. The question is whether this periodic unsolicited multicast RA
needs to contain a PIO usable for SLAAC. For this, my answer is a NO.
Cheers
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
