Multicast Listener Discovery Version 2 (MLDv2) for IPv6
draft-vida-mld-v2-08

[Ballot discuss]
This discuss is for the IANA considerations section, and as a placeholder for Randy's discuss, which the WG has already seen and agreed to deal with.

From: Thomas Narten
To: Isidor Kouvelas
cc: Jari Arkko , IANA ,
    dbj@cs.rice.edu, charliep@iprg.nokia.com,
    Margaret Wasserman , gab@sun.com,
    proberts@megisto.com, basavaraj.patil@nokia.com,
    Brian Haberman
Date: Tue, 25 Nov 2003 10:08:45 -0500
Subject: Re: IANA code point in RFC-to-be: 

> This is great news. Do you have a specific IANA contact that I could
> also use to get 143 assigned to MLDv2?

My understanding is that the MLDv2 spec is just about finished. I.e,
will be approved by the IESG once another set of revs is
produced. What I would suggest is adding updating the IANA
considerations section to something like:

New:

  IANA has assigned the IPv6 link-local multicast address TBD, called
  "all MLDv2-capable routers", as described in section 5.2.14.
  Version 2 Multicast Listener Reports will be sent to this special
  address.

  In addition, IANA has assigned the ICMPv6 message type value of TBD
  [143 is suggested] for Version 2 Multicast Listener Report
  messages, as specified in section 4.

Thomas 

===========
Randy's original discuss:
From: Randy Bush
To: IESG Secretary
Cc: iesg
Date: Wed, 15 Oct 2003 10:50:13 +0200
Subject: discuss: draft-vida-mld-v2-07.txt

ok, this is my first deep dive into MLDn, so
  o some or all questions are likely silly
  o many will be answered with "MLDv1 compatibility" (except
    routers seem to be explicitly configured to be mldv1 or mldv2,
    see 8.3.1)

but, for the moment, color me discuss

---

in general, this document is unusually well written.  but i will be
picky anyway.

---

  To cover the possibility of a State Change Report being missed by one
  or more multicast routers, the report is retransmitted several times
  by the node.  The number of retransmissions depends on the so-called
  Robustness Variable.

this seems a bit hit and miss, i.e., 'robustness' is not very apt.
perhaps 'improve the odds' would better describe it .

---

in general, the protocol has hacks to deal with unreliability of
exchanges by use of various timers and by issuing queries and
responses multiple times.  the S flag is a particularly 'cute' hack
on this multi-send hack.  it would help if the general reliability
and timing model was explained.

e.g., sympathy for these hacks would be easier if the document
explained the assumptions behind why they are necessary and the
model of how good values of RV can be decided which will make the
transactions sufficiently reliable.

sometimes, the layers of kink get *really* kinky, e.g., in 6.1 when
changes to an interface happen before all the retransmissions of
the SCR for the last change have been completed.

---
                                                  the Querier sends a
  Multicast Address and Source Specific Query to verify whether, for a
  specified multicast address, there are nodes still listening to a
  specific set of sources, or not.  Both queries are only sent in
  response to State Change Reports, never in response to Current State
  Reports.

this seems to assume that a CSR will not surprise the querier,
i.e., not change the querier's knowledge of what the set of
listeners want.  if this was not the case, should not a surprising
CSR cause the querier to send MA or SS queries?  alternatively, if
CSRs can, ob definito, not be surprising, then why have them?

---

  4.2.  Interface State

it would clearer to call it "4.2 Per-Interface State"

---

  5.1.8.  QRV (Querier's Robustness Variable)

  If non-zero, the QRV field contains the [Robustness Variable] value
  used by the Querier.  If the Querier's [Robustness Variable] exceeds
  7 (the maximum value of the QRV field), the QRV field is set to zero. 
 
  Routers adopt the QRV value from the most recently received Query as
  their own [Robustness Variable] value, unless that most recently
  received QRV was zero, in which case they use the default [Robustness
  Variable] value specified in section 9.1, or a statically configured
  value.

what is the meaning of the square brackets in "[Robustness
Variable]?"  the syntax needs to be explained.

same confusion about 5.1.9 "[Query Interval]"

---

in general, are values of MRC and QQIC expected to be so large that
the exponential notation hacks are needed as opposed to just making
the cardinal fields a bit larger?

---

syntax error in 6.1. in following text

  To cover the possibility of the State Change Report being missed by
  one or more multicast routers, [Robustness Variable] û 1
  retransmissions are scheduled, through a Retransmission Timer, at
  intervals chosen at random from the range (0, [Unsolicited Report
  Interval]). 

---

  7.6.2. Querier Election

has an explicit Querier state, but not a non-Querier state, though
all routers but one are probabilistically in non-Querier state.
E.g.,

  When a router receives a query with a lower IPv6 address than its
  own, it sets the Other Querier Present timer to Other Querier Present
  Timeout;  if it was previously in Querier state, it ceases to send
  queries on the link.

could say it has entered non-Querier state

---

randy

[Ballot discuss]
ok, this is my first deep dive into MLDn, so
    o some or all questions are likely silly
    o many will be answered with "MLDv1 compatibility" (except
        routers seem to be explicitly configured to be mldv1 or mldv2,
        see 8.3.1)

but, for the moment, color me discuss

---

in general, this document is unusually well written. but i will be
picky anyway.

---

      To cover the possibility of a State Change Report being missed by one
      or more multicast routers, the report is retransmitted several times
      by the node. The number of retransmissions depends on the so-called
      Robustness Variable.

this seems a bit hit and miss, i.e., 'robustness' is not very apt.
perhaps 'improve the odds' would better describe it .

---

in general, the protocol has hacks to deal with unreliability of
exchanges by use of various timers and by issuing queries and
responses multiple times. the S flag is a particularly 'cute' hack
on this multi-send hack. it would help if the general reliability
and timing model was explained.

e.g., sympathy for these hacks would be easier if the document
explained the assumptions behind why they are necessary and the
model of how good values of RV can be decided which will make the
transactions sufficiently reliable.

sometimes, the layers of kink get *really* kinky, e.g., in 6.1 when
changes to an interface happen before all the retransmissions of
the SCR for the last change have been completed.

---
                                                                                                      the Querier sends a
      Multicast Address and Source Specific Query to verify whether, for a
      specified multicast address, there are nodes still listening to a
      specific set of sources, or not. Both queries are only sent in
      response to State Change Reports, never in response to Current State
      Reports.

this seems to assume that a CSR will not surprise the querier,
i.e., not change the querier's knowledge of what the set of
listeners want. if this was not the case, should not a surprising
CSR cause the querier to send MA or SS queries? alternatively, if
CSRs can, ob definito, not be surprising, then why have them?

---

      4.2. Interface State

it would clearer to call it "4.2 Per-Interface State"

---

      5.1.8. QRV (Querier's Robustness Variable)

      If non-zero, the QRV field contains the [Robustness Variable] value
      used by the Querier. If the Querier's [Robustness Variable] exceeds
      7 (the maximum value of the QRV field), the QRV field is set to zero.
   
      Routers adopt the QRV value from the most recently received Query as
      their own [Robustness Variable] value, unless that most recently
      received QRV was zero, in which case they use the default [Robustness
      Variable] value specified in section 9.1, or a statically configured
      value.

what is the meaning of the square brackets in "[Robustness
Variable]?" the syntax needs to be explained.

same confusion about 5.1.9 "[Query Interval]"

---

in general, are values of MRC and QQIC expected to be so large that
the exponential notation hacks are needed as opposed to just making
the cardinal fields a bit larger?

---

syntax error in 6.1. in following text

      To cover the possibility of the State Change Report being missed by
      one or more multicast routers, [Robustness Variable] û 1
      retransmissions are scheduled, through a Retransmission Timer, at
      intervals chosen at random from the range (0, [Unsolicited Report
      Interval]).

---

      7.6.2. Querier Election

has an explicit Querier state, but not a non-Querier state, though
all routers but one are probabilistically in non-Querier state.
E.g.,

      When a router receives a query with a lower IPv6 address than its
      own, it sets the Other Querier Present timer to Other Querier Present
      Timeout; if it was previously in Querier state, it ceases to send
      queries on the link.

could say it has entered non-Querier state

---

[Ballot comment]
For the state change request, the draft says:


  Besides this "soft leave" mechanism, there is also a "fast leave"
  scheme in MLDv2;  it is also based on the use of source timers.  When
  a node in INCLUDE mode expresses its desire to stop listening to a
  specific source, all the multicast routers on the link lower their
  timer for that source to a small interval of LLQT milliseconds.  The
  Querier then sends then a Multicast Address and Source Specific
  Query, to verify whether there are other listeners for that source on
  the link, or not.  If a corresponding report is received before the
  timer expires, all the multicast routers on the link update their
  source timer.  If not, the source is deleted from the Include List.
  The handling of the Include List, according to the received reports,
  is detailed in Tables 7.4.1 and 7.4.2.


In the Security Considerations, the draft notes some of the issues with this;

10.3.  State Change Report messages

  A forged State Change Report message will cause the Querier to send
  out Multicast Address Specific or Multicast Address and Source
  Specific Queries for the multicast address in question.  This causes
  extra processing on each router and on each listener of the multicast
  address, but cannot cause loss of desired traffic. 


It seems like the DoS aspects of this risk might be mitigated by allowing the
Querirer not to send out the Multicast Address Specific or Multicast Address
and Source specific queries when the State Change request related to a
multicast address for which the node was not a listener.  It was not entirely
clear to me, however, whether the Querier would always have definitive information
on this when there multiple queriers, but it does seem useful when there is only
one on-link.

[Ballot comment]
I propose a revised Abstract:

    This document updates RFC 2710, and it specifies Version 2 of the
    Multicast Listener Discovery Protocol (MLDv2).  MLD is used by an
    IPv6 router to discover the presence of multicast listeners on
    directly attached links, and to discover which multicast addresses
    are of interest to those neighboring nodes.  MLDv2 is designed to
    be interoperable with MLDv1.  MLDv2 adds the ability for a node to
    report interest in listening to packets with a particular multicast
    address only from specific source addresses or from all sources
    except for specific source addresses. 

In section 5.1.8, the document says:

    If non-zero, the QRV field contains the [Robustness Variable] value
    used by the Querier.  If the Querier's [Robustness Variable] exceeds
    7 (the maximum value of the QRV field), the QRV field is set to zero. 

This is an unusual use of square brackets.  This convention is used elsewhere
too.  It should be explained in a manner similar to the use of asterisk.