[magma] About reception of a query
"K.Kawaguchi" <kawaguti@ysknet.co.jp> Fri, 04 June 2010 06:37 UTC
Return-Path: <kawaguti@ysknet.co.jp>
X-Original-To: magma@core3.amsl.com
Delivered-To: magma@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 64D763A6926 for <magma@core3.amsl.com>;
Thu, 3 Jun 2010 23:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.955
X-Spam-Level: ****
X-Spam-Status: No, score=4.955 tagged_above=-999 required=5 tests=[AWL=-0.850,
BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MANGLED_LIST=2.3,
RELAY_IS_203=0.994, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcRvqkIn-aaN for
<magma@core3.amsl.com>; Thu, 3 Jun 2010 23:37:33 -0700 (PDT)
Received: from tkns.tk.ysknet.co.jp (tkmx.tk.ysknet.co.jp [203.180.172.16]) by
core3.amsl.com (Postfix) with SMTP id 025143A6914 for <magma@ietf.org>;
Thu, 3 Jun 2010 23:37:32 -0700 (PDT)
Received: (qmail 10105 invoked from network); 4 Jun 2010 15:37:18 +0900
Received: from (HELO PrecisionM20) (@) by with SMTP;
4 Jun 2010 15:37:18 +0900
To: magma@ietf.org
From: "K.Kawaguchi" <kawaguti@ysknet.co.jp>
Message-Id: <201006041537.GBD64074.BLBXVJHU@ysknet.co.jp>
X-Mailer: Winbiff [Version 2.51 PL2]
X-Accept-Language: ja,en,zh
Date: Fri, 4 Jun 2010 15:37:16 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [magma] About reception of a query
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>,
<mailto:magma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/magma>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>,
<mailto:magma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jun 2010 06:37:34 -0000
Hi all,
# Since this mail is not provided, I have sent this mail several times.
# I am sorry if multiple mails have arrived.
I feel uneasy about implementation of MLDv2 (also MLDv1, IGMPv2/3).
The main one is action on reception of MLDv2 query in MLDv2 router.
Verification is described by Section 7.6 (in RFC 3810). Section 5.1.15
is also related. And, there are Section 5.1.8, Section 5.1.9, Section
7.6.1, Section 7.6.2, etc. as action after reception. Moreover, Section
10.1 has security consideration.
The following tables are created when verification and action which were
described by RFC are mapped simply.
Verification Fields in Query Message Action
--------------------------------------------------------------------- -------------------------------------
Source Hop Router Multicast Destination Querier As Router As Listener
Address Limit Alert Address Address Priority
(5.1.14) (5) (5) (5.1.5) (5.1.15) (7.6.2)
========= ======== ========= ============ =============== =========== ===================== ===============
Valid 1 Present Zero a node MUST High QRV and QQIC Accept. (6.2)
IPv6 in a - General accept and (5.1.8, 5.1.9)
Linkl Hop-by- Query process any Querier Election
Local Hop Query whose IP (7.6.2)
Address Option Destination ----------- ---------------------
Header Address field Low QRV
contains *any* (5.1.8)
------------ of the ----------- ---------------------
Multicast addresses High QRV and QQIC
- Specific (unicast or (5.1.8, 5.1.9)
Query multicast) Timer Updates
assigned to (7.6.1)
the interface Querier Election
on which the (7.6.2)
Query arrives. ----------- ---------------------
This might be Low QRV
useful, e.g., (5.1.8)
for debugging Timer Updates
purposes. (7.6.1)
---------------------- --------------------------- --------------------- ---------------
Others Drop. (7.6) Drop. (6.2)
----------------------------------------------------------
Others
---------------------------------------------------------------------
Others
---------------------------------------------------------------------
However, I imagine that action may be specified in detail by the
destination address, the kind of query, or a priority in real
implementation. I imagine, as shown in the following tables. It is
because the combination which lacks listening information is shown in
the above-mentioned table.
For example, since General Query and Specific Query addressed to a
specific address are insufficient as General Query of Querier in order
that some Listeners may not receive, it is unsuitable to Querier
Election. For example, the Specific Question of a different Destination
Address from Multicast Address is unsuitable to updating (lower) of a
timer of multicast, since some nodes which are interested in listening
may not receive.
A normal router does not usually transmit these Queries. However,
reference is not made in Section 10.1 about security consideration.
Verification Fields in Query Message Action
--------------------------------------------------------------------- -------------------------------------
Source Hop Router Multicast Destination Querier As Router As Listener
Address Limit Alert Address Address Priority
(5.1.14.) (5.) (5.) (5.1.5) (5.1.15) (7.6.2)
========== ======= ========= ============ =============== =========== ===================== ===============
Valid 1 Present Zero All-Nodes High QRV and QQIC Accept. (6.2)
IPv6 in a - General Multicast (5.1.8, 5.1.9)
Linkl Hop-by- Query Address Querier Election
Local Hop (7.6.2.)
Address Option ----------- ---------------------
Header Low Low is dropped.
--------------- ----------- ---------------------
Others Drop. Since reports
cannot be received
from some nodes.
------------ --------------- ----------- ---------------------
Multicast All-Nodes Unrelated Timer Updates
- Specific Multicast (7.6.1)
Query Address
--------------- * Unrelated to
Same Address QRV, QQIC, and
as Multicast Querier Election
--------------------------- ---------------------
Others Drop. Since reports
cannot be received
from some nodes.
---------------------------------------- --------------------- ---------------
Others Drop. Since it is Drop. Since it is
valueless. valueless.
-------------------------------------------------- --------------------- ---------------
Others Drop. (7.6.) Drop. (6.2.)
----------------------------------------------------------
Others
---------------------------------------------------------------------
Others
---------------------------------------------------------------------
"a node MUST" in Section 5.1.15 is imagined "a node (as listener) MUST."
The Query which adopts RV and QI in Section 5.1.8 and Section 5.1.9 is
imagined "General Query addressed to All-nodes multicast address by a
router with a high priority".
The Query related to Querier Election in Section 7.6.2 is also imagined
"General Query addressed to All-nodes multicast address by a router with
a high priority".
The Query related to Timer Updates in Section 7.6.1 is imagined
"Specific Query which has the same multicast address as the multicast
field in a destination address field".
Are these the issues of implementation person dependence?
Is it a matter in which necessity does not have consensus?
Best Regards
--
Kiyoaki Kawaguchi
- [magma] About reception of a query K.Kawaguchi