All things related to multicast

[Andrew Swan <>]

Marshall Eubanks wrote:
> However, RFC 3376 mandates that
> 
>    In order to be compatible with older version routers, IGMPv3 hosts
>    MUST operate in version 1 and version 2 compatibility modes.  IGMPv3
>    hosts MUST keep state per local interface regarding the compatibility
>    mode of each attached network
> 
> So, old boxes running ASM will cause new boxes running SSM to fail, at 
> least on the
> local LAN.

not necessarily -- the "compatibility state machine" (i forgot
the exact term used in the igmp spec) is maintained per-group so
it is only if an igmpv2-only host joins an ssm group
(i.e., 232.x.x.x) that there is a potential problem.

but, according to draft-ietf-ssm-arch-06:

  A network can concurrently support SSM in the SSM address range and any-
  source multicast in the rest of the multicast address space, and it is
  expected that this will be commonplace.  In such a network, a router may
  receive a non-source-specific, or "(*,G)" in conventional terminology,
  request for delivery of traffic in the SSM range from a neighbor that
  does not implement source-specific multicast in a manner compliant with
  this document.  A router that receives such a non-source-specific
  request for data in the SSM range MUST NOT use the request to establish
  forwarding state and MUST NOT propagate the request to other neighboring
  routers.  A router MAY log an error in such a case.  This applies both
  to any request received from a host, e.g., an IGMPv1 or IGMPv2 host
  report, and to any request received from a routing protocol, e.g., a
  PIM-SM (*,G) join.

i have no idea if the actual implementations out there today
implement this clause but it shouldn't be a show-stopper.

-Andrew