Hi,
I was reading through the, IMHO overly complex, RFC3810 for MLDv2 making
sure that ecmh will implement it correctly and found a couple of odd
things.
First of all for MLD we set the Hop Limit to 1, while for ND we use 255
so that we are sure that the ND's are on link. Why is this not done for
MLD's too ?
Also 6.2
8<--------
Instead of responding immediately, the node
delays its response by a random amount of time, bounded by the
Maximum Response Delay value derived from the Maximum Response Code
in the received Query message.
-------->8
but also:
8<--------
If it does, a delay for a response is randomly selected in the range (0,
[Maximum Response Delay]), where Maximum Response Delay is derived
from the Maximum Response Code inserted in the received Query
message.
-------->8
6.3 then further notes (repeating again, but a bit more text):
8<--------
This naive algorithm may result in bursts of packets when a node
listens to a large number of multicast addresses. Instead of
using a single Interface Timer, implementations are recommended to
spread transmission of such Report messages over the interval (0,
[Maximum Response Delay]). Note that any such implementation MUST
avoid the "ack-implosion" problem, i.e., MUST NOT send a Report
immediately upon reception of a General Query.
-------->8
Shouldn't the response thus be generated after random(3+,MRC) ?
Another item I couldn't clearly identify from the text, at least it
puzzled me, was the following situation:
Host A wants to receive ff3e:30:2001:db8:300:0:8008:ad10 IN(::)
Host B wants to receive ff3e:30:2001:db8:300:0:8008:ad10 EX(2001:db8::1)
What does the router have to send forward in this case? I assume it
would be to transit it anyway, because at least one node wants it, B can
filter out these packets and not deliver them. Is this assumption
correct?
Btw, anyone counted the number of times 'nevertheless' is in the text ?
:)
Greets,
Jeroen
Attachment:
signature.asc
Description: This is a digitally signed message part
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------