[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