Re: [v6ops] Interesting problems with using IPv6

神明達哉 <jinmei@wide.ad.jp> Tue, 09 September 2014 18:57 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19861A0013 for <v6ops@ietfa.amsl.com>; Tue, 9 Sep 2014 11:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqZgucmp1tSN for <v6ops@ietfa.amsl.com>; Tue, 9 Sep 2014 11:57:54 -0700 (PDT)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5411A00E0 for <v6ops@ietf.org>; Tue, 9 Sep 2014 11:57:46 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id u56so3440838wes.4 for <v6ops@ietf.org>; Tue, 09 Sep 2014 11:57:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=w7WxwDt4PW9xIDLY24noFLzJuRJEtkeKxXhdceCRddA=; b=G7GvvCVZoJd3RUfHKsAapuL4RnzCxV0kE2geK3GIGTftXKQ8CjMvcD6J5QjMD7ug/s q2XKvejicEUHPSOYM/05KME7cLmx+EMZH+MoQpNZC+gF0SkJ0Pqbfadpa9WEJX3FFcYn jMsHYXI78l+vuanqV7L9OzGAp++pZMC5AKeNn6ZXU/Bo8FCIxZ7AjO9vlWFiRQbrgPtp 8/+ehPNG0/2TWXE+Qnd1vyBSSO6Bev+lSc3R+advzcZjq4CGMmwVqoikQiPChGnZarMh L4J8o3+MjdcsNECjGEyg1lSabmK1AyrFTEA5Lkb1+vHbgH/0t2orP+UkntUwzYusssjM Vxbg==
MIME-Version: 1.0
X-Received: by 10.194.172.137 with SMTP id bc9mr45812516wjc.72.1410289064886; Tue, 09 Sep 2014 11:57:44 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.123.164 with HTTP; Tue, 9 Sep 2014 11:57:44 -0700 (PDT)
In-Reply-To: <540E26D9.3070907@gmail.com>
References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com>
Date: Tue, 9 Sep 2014 11:57:44 -0700
X-Google-Sender-Auth: g4psTm-zyzBXVnU5dN5qTRHw14c
Message-ID: <CAJE_bqeP4t-ofVHSeEsmqOfLqqe9DS01YDrMHQ_iCAWvJsNp1A@mail.gmail.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sWXO9Z8ZajP1A6MNKPbAjrQ3BMQ
Cc: IPv6 Operations <v6ops@ietf.org>, l.wood@surrey.ac.uk
Subject: Re: [v6ops] Interesting problems with using IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 18:57:55 -0000

At Tue, 09 Sep 2014 09:59:53 +1200,
Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> > Implementing MLD snooping for Solicited-Node multicast addresses
> > is probably a bad idea.
> >
> > See: draft-pashby-magma-simplify-mld-snooping-01
>
> OK, but I would also like to understand why we require
> MLD messages for a Solicited-Node multicast address to
> set Router Alert.

I don't know the answer, but my guess is that when the original MLD
was designed in RFC 2710 they simply didn't have that question.  In
fact, we were not aware of various implications with MLD messages for
solicited-node multicast addresses for quite some time, which made us
include some specific discussion on this topic in RFC 4862 (Section
5.4.2).

--
JINMEI, Tatuya