[magma] static configuration of version compatibility mode

Hitoshi Asaeda <Hitoshi.Asaeda@sophia.inria.fr> Mon, 03 June 2002 17:19 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24580 for <magma-archive@odin.ietf.org>; Mon, 3 Jun 2002 13:19:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18580; Mon, 3 Jun 2002 13:19:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18559 for <magma@optimus.ietf.org>; Mon, 3 Jun 2002 13:19:15 -0400 (EDT)
Received: from sophia.inria.fr (sophia.inria.fr [138.96.64.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24532 for <magma@ietf.org>; Mon, 3 Jun 2002 13:18:34 -0400 (EDT)
Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.11.6/8.11.6) with ESMTP id g53HITd07362 for <magma@ietf.org>; Mon, 3 Jun 2002 19:18:29 +0200
X-Authentication-Warning: sophia.inria.fr: Host odie.inria.fr [138.96.88.52] claimed to be localhost
Date: Mon, 03 Jun 2002 19:18:29 +0200
Message-Id: <20020603.191829.37988045.Hitoshi.Asaeda@sophia.inria.fr>
To: magma@ietf.org
From: Hitoshi Asaeda <Hitoshi.Asaeda@sophia.inria.fr>
X-Mailer: Mew version 2.2rc1 on Emacs 21.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [magma] static configuration of version compatibility mode
Sender: magma-admin@ietf.org
Errors-To: magma-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
X-BeenThere: magma@ietf.org
Content-Transfer-Encoding: 7bit

I'd like to ask you about "older version's compatibility" for IGMPv3
(maybe for MLDv2, too).

If some bogus node sends, e.g., v2 General Query, all igmpv3 capable
nodes attached on the same LAN start "v2 Host Compatibility Mode
timer".
This timer will be expired, but if the node receives v2 Query again
before it's expired, it restarts the timer.
This indicates it is very easy to make end-nodes stop sending v3
report intentionally or accidentally.

Actually, I think this situation causes easily. In an above statement,
I said "bogus node", but we will encounter the same problem if there
are two or more routers attached on a same LAN speak IGMP Queries
regularly, since although one of routers is selected as a querier,
non-querier also sends periodically Queries after Other Querier
Present timer expires.
Let's see following two values.

--- based on both of igmpv3 and igmpv2 specs. ---
8.5.  Other Querier Present Interval
 
The Other Querier Present Interval is the length of time that must pass
before a multicast router decides that there is no longer another
multicast router which should be the querier.  This value MUST be ((the
Robustness Variable) times (the Query Interval)) plus (one half of one
Query Response Interval).
---

This means that default Other Querier Present Interval becomes 2 * 125
+ 10 / 2 = 255 seconds, and then some router may send igmpv2 query
within this period.

--- based on igmpv3 spec. ---
8.12.  Older Version Querier Present Timeout
 
The Older Version Querier Interval is the time-out for transitioning a
host back to IGMPv3 mode once an older version query is heard.  When an
older version query is received, hosts set their Older Version Querier
Present Timer to Older Version Querier Interval.
 
This value MUST be ((the Robustness Variable) times (the Query Interval
in the last Query received)) plus (one Query Response Interval).
---

This means that default Older Version Querier Present Timeout becomes
2 * 125 + 10 = 260 seconds, and then each node doesn't switch to v3
mode within this period.

Based on above two values, we'd say end-node cannot behave as an
igmpv3 node if there is igmpv2 router on a same LAN, even the router
is not a querier and not a forwarder.

This also would be the case of igmpv3 router, if the router applies
"Older Host Present Interval".

Now, I'd vote following simple solution.

"Host Compatibility Mode can be configured statically. This value is
set to one of off/IGMPv3/v2/v1. If this value is set to IGMPv3, the
host responds only to IGMPv3 Query message. Its default value should
be "off", which means it is dependent on the version of General
Queries heard on that interface."

Comments?
--
Hitoshi Asaeda

_______________________________________________
magma mailing list
magma@ietf.org
https://www1.ietf.org/mailman/listinfo/magma