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

From: Jeroen Massar <[email-masked]>
Date: Mon, 27 Sep 2004 11:43:58 +0200

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Mon, 27 Sep 2004 08:46:37 -0400

Hi Jeroen,

> so that we are sure that the ND's are on link. Why is this not done for

The hop limit of 1 is to keep MLD consistent with IGMP.

> Also 6.2

I am not sure if I am parsing your question correctly.  Any single
response should be delayed over the interval [0,MRD] where MRD
is derived from the received MRC.

> filter out these packets and not deliver them. Is this assumption

On a multi-access network, the router will have to forward all packets
matching the DA=ff3e:30:2001:db8:300:0:8008:ad10 in order to
satisfy Host A.  As you state, Host B will have to filter out the 
unwanted
packets.

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

Greater than 1? :)

Regards,
Brian

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 27 Sep 2004 16:34:04 +0200

> The hop limit of 1 is to keep MLD consistent with IGMP.

You mean IGMPv3, thus actually IPv4? But wouldn't it be better to use
255 here to make it consistent with the "we don't want remote hosts to
set a TTL to 5, let the packet hop 4 routers and tada do ND there' idea?
Even though fe80::/10 sourced stuff should (but then again who does
source filtering?) already been dropped.

<SNIP>
> 6.3 then further notes (repeating again, but a bit more text):

If the rand(0,MRD) results in 0, which is possible, the reply will be
sent directly, which some of the lines mentioned above say must not (in
caps) be done to overcome the ack implosion, then again it might also
become 3 and then the ack-implosion could be there.

> unwanted packets.

Thus a router really only needs to keep a list of
destination+[n*sources], when it then wants to drop a source, because of
a timeout or a in/ex change it should query the link if there are any
others still wanting it and then at timeout time simply drop it.
RFC3810 in a nutshell ;)

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

18 times in a very dense piece of text, when one reads it in one go you
really notice it :)

Greets,
 Jeroen