Subject: [magma] draft-holbrook-idmr-igmpv3-ssm-07.txt

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 27 Jul 2004 17:10:11 -0400

Good draft, I think.

On this comment:

-------------------------
2.2.3.  IGMPv1/IGMPv2 and MLDv1 Queries

If an IGMPv1, IGMPv2, or MLDv1 query is received, the SFGMP protocol
specifications require the host to revert to the older (IGMPv1, IGMPv2,
or MLDv1) mode of operation for that destination address.
-------------------------

How does one differentiate between an IGMPv1, v2, or v3 query, e.g. in the case of all hosts (general) queries?

I believe that in the general case, hosts will respond to a general query with the highest version of IGMP or MLD they can, and then determine hear other hosts' reports which version to use? Furthermore, that it's entirely possible for a multicast router to be supporting multicast groups using a mix of IGMPv1, v2, and v3?

For any SSM-specific multicast group address (232/8 for IPv4), the assumption should be that the router will accept only IGMPv3 or MLDv2. As long as there is a differentiation between SSM and ASM, I would think that all SSM groups must be managed only by IGMPv3/MLDv2 or greater. However, I don't know that hosts can necessarily differentiate based on the query.

On this:

--------------------------
2.2.6.  IGMPv3 and MLDv1 Group Specific Query
--------------------------

I believe that should be MLDv2.

On this:

--------------------------
3.  Router Requirements for Source-Specific Multicast

Routers must be aware of the SSM address range in order to provide the
SSM service model.  A router that knows the SSM address range and is
capable of applying SSM semantics to it as described in this section is
described as an "SSM-aware" router.  An SSM-aware router MAY have a
configuration option to apply SSM semantics to addresses other than the
IANA-allocated range, but if such an option exists, it MUST default to
the IANA-allocated range.
--------------------------

By "configuration option," do you mean statically configured option? Seems to me that if any host wants to try to join a group from the non-SSM address range with IGMPv3 or MLDv2, and use SSM semantics, the router should be able to accommodate that as if it were a group within the SSM address range. Unless, of course, there are other group members who are non-SSM-aware.

For example, if all hosts sending reports for groups in the 239/8 IPv4 range use IGMPv3, then go ahead and filter as if this were for group membership in the 232/8 IPv4 block of addresses. If at least one report for a 239/8 group is received that is less than IGMPv3, then the router has to ignore any source filtering and go with the lowest common denominator. Any down side to this? Seems like the easiest way to implement IGMP or MLD, and it permits completely automatic configuration, no?

Bert

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Hugh Holbrook <[email-masked]>
Date: Wed, 28 Jul 2004 01:03:08 -0700 (PDT)

Thanks for the comments, Bert.
My responses are inline.

> On this comment:

The determination is based on the packet length and the MaxRespCode
field (second byte).  v1 general queries are 8 bytes and have a zero
MaxRespCode.-- it was unused in RFC1112 and required to be set to 0.
v2 queries are 8 bytes and have a non-zero MaxRespCode.  v3 queries
are 12 bytes.  This is (sort of) summarized in section 7 of RFC3376
(IGMPv3).

Section 7 of RFC3376 has lots of references to text like "If an IGMPv1
general query is heard...".

> I believe that in the general case, hosts will respond to a general query with
> the highest version of IGMP or MLD they can, and then determine hear other
> hosts' reports which version to use? Furthermore, that it's entirely possible
> for a multicast router to be supporting multicast groups using a mix of IGMPv1,
> v2, and v3?

Not exactly.  IGMPv3-speaking hosts determine the IGMP version to use
on an interface based on the per-interface Host Compatibility Mode
variable A host will fall back to sending only IGMPv1 if it detects
any v1 querier on that interface.  From RFC3376:

   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.  A host's compatibility mode is
   determined from the Host Compatibility Mode variable which can be in
   one of three states:  IGMPv1, IGMPv2 or IGMPv3.  This variable is
   kept per interface and is dependent on the version of General Queries
   heard on that interface as well as the Older Version Querier Present
   timers for the interface.

> For any SSM-specific multicast group address (232/8 for IPv4), the assumption
> should be that the router will accept only IGMPv3 or MLDv2. As long as there is
> a differentiation between SSM and ASM, I would think that all SSM groups must
> be managed only by IGMPv3/MLDv2 or greater. However, I don't know that hosts
> can necessarily differentiate based on the query.

What you say is true -- SSM addresses can only be managed by
IGMPv3/MLDv2, and a host can indeed assume that unless the querier is
sending out IGMPv3 queries, that it won't get SSM semantics for that
address.  In fact the router is supposed to ignore an IGMPv2 report if
it receives one for an SSM address.

Do you think a different behavior would be preferable?

> On this:

You're right; thanks.  I'll fix this in the next revision.  Good
catch.

> By "configuration option," do you mean statically configured option?

Yes, basically statically configured, although future protocol
mechanisms or MIBs or the like to set it are not ruled out.

> Seems to
> me that if any host wants to try to join a group from the non-SSM address range
> with IGMPv3 or MLDv2, and use SSM semantics, the router should be able to
> accommodate that as if it were a group within the SSM address range. Unless, of
> course, there are other group members who are non-SSM-aware.

The intent of this section is not to say that you can't use
IGMPv3/MLDv2 for addresses outside the SSM range and get
source-specific behavior.  Just simply that the router won't have the
SSM-enhanced behavior in that range.  These SSM-specific behaviors
are:

        - ignore exclude mode IGMPv3/MLDv2 reports (3.1)
        - ignore older version reports (3.5)
        - ignore IGMPv2 leave and MLDv1 done (3.7)

This is all.  Does that clarify?  Do you think this needs more text to
clarify this?

> For example, if all hosts sending reports for groups in the 239/8 IPv4 range
> use IGMPv3, then go ahead and filter as if this were for group membership in
> the 232/8 IPv4 block of addresses. If at least one report for a 239/8 group is
> received that is less than IGMPv3, then the router has to ignore any source
> filtering and go with the lowest common denominator. Any down side to this? 
> Seems like the easiest way to implement IGMP or MLD, and it permits completely
> automatic configuration, no?

That is what will happen, and this draft does not change that.

The main downside of not having the configuration option is SSM range
is primarily a security/misconfiguration issue.  The above behaviors
will not be applied and so a misconfigured or malicious host on the
LAN could send an IGMPv1 report and force the router into
backwards-compatibility mode.  This would prevent it from properly
processing IGMPv3 messages and would deny SSM service to other hosts
on the LAN.

Hope this helps.  If you still think the text needs further
clarification, let me know and I will see if I can improve it.

Thanks again for taking the time to do such a careful reading.

-Hugh