All things related to multicast

[Leonard Giuliano <>]

It's actually not as bad as it sounds.  Indeed, for backwards 
compatability, a v3 router can accept v2 reports and drop to v2 mode, but 
only for *that* particular group.  For ASM, there really isn't much of a 
functional difference beween v2 and v3.  More importantly, 232/8 is 
reserved for SSM and non-source-included (ie, ASM) reports in this range 
are prohibited.  So SSM behavior is protected in this range.  From 
RFC4604, section 4:

   It is important that a router not accept non-source-specific
   reception requests for an SSM destination address.  The rules of
   [IGMPv3] and [MLDv2] require a router, upon receiving such a
   membership report, to revert to earlier version compatibility mode
   for the group in question.  If the router were to revert in this
   situation, it would prevent an IGMPv3-capable host from receiving SSM
   service for that destination address, thus creating a potential for
   an attacker to deny SSM service to other hosts on the same link.


On Thu, 18 Aug 2016, Havard Eidnes wrote:

| Hi,
| 
| while I can certainly sympathise with the goal of simplifying
| multicast by abolishing ASM, RPs, MSDP and all the associated
| complextity, I see practical problems in doing so in the short term.
| 
| In addition to getting SSM and IGMPv3 "everywhere", there's the
| problem of IGMPv2 and IGMPv3 interaction which needs to be dealt with.
| If I've understood correctly (section 7 of RFC 3376, IGMPv3), IGMPv3
| and hence SSM has what I would call a massive deployment bug for
| shared networks: if a single node on a subnet speaks IGMPv2, all the
| IGMPv3 speakers on that subnet are by protocol design mandated to
| downgrade their operation to IGMPv2, which directly translates into
| "No SSM for you!" (or any of your neighbors on that subnet for that
| matter).  Thus, hooking up a single IGMPv2-speaker to a SSM multicast-
| enabled subnet will act as a DoS on all the SSM-users on that subnet.
| I seem to recall seeing various crutches and kludges possible to use
| to work around this, but if the goal was to reduce kludges and
| complexity and improve common standards and interoperability, that's
| exactly the wrong recipe.
| 
| Of course, the IGMPv3 spec can at least in theory be updated so that
| this isn't the specified behaviour anymore, and IGMPv2 (and v1) can be
| relegated to historical status along with ASM, RPs, MSDPs and all the
| associated protocol machinery, but we would then need to go through a
| full re-implementation and subsequent deployment cycle for all the
| IGMPv3 speakers (and IGMP snoopers?) for this to be effective, and
| this is going to take ... quite a while.  Or is this not a viable
| path, e.g. due to protocol reasons (IGMPv2 hosts becoming confused by
| IGMPv3 traffic?)?
| 
| Over in IPv6-land things don't seem to be much better, at least not in
| principle, there we have both MLDv1 and MLDv2 and MLDv2 also has this
| "you need to speak the least common denominator" deployment bug which
| IGMPv3 suffers from.  In that context the blessing that we don't have
| MSDP for IPv6 is meagre consolation.  Or does ~every IPv6
| implementation also do MLDv2?
| 
| Anyone wanting to carry that torch?  Or is Internet Mcast a hopelessly
| lost cause anyway, independent of IPv4 or IPv6?  Or is the answer
| different depending on protocol version?
| 
| At least "plain IPv6 unicast", doesn't suffer from any corresponding
| deployment bug, if that's anything to learn from.  Imagine where we'd
| be with IPv6 unicast deployment today if a single IPv4 host could
| through its mere existence veto IPv6 use on that subnet...
| 
| Regards,
| 
| - H?vard
|