[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RC3810: MLD Hop Limit is 1 / random reply time / exclude


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

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
   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. 
but also:
   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
6.3 then further notes (repeating again, but a bit more text):
      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.

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

Btw, anyone counted the number of times 'nevertheless' is in the text ?


Attachment: signature.asc
Description: This is a digitally signed message part

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6