[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
- [magma] static configuration of version compatibi… Hitoshi Asaeda