Re: [v6ops] Interesting problems with using IPv6

Brian Haberman <brian@innovationslab.net> Wed, 10 September 2014 12:15 UTC

Return-Path: <brian@innovationslab.net>
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 A991F1A002D for <v6ops@ietfa.amsl.com>; Wed, 10 Sep 2014 05:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 OQpJl1FzhhpN for <v6ops@ietfa.amsl.com>; Wed, 10 Sep 2014 05:15:29 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8303F1A0023 for <v6ops@ietf.org>; Wed, 10 Sep 2014 05:15:29 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 66B8E880DB; Wed, 10 Sep 2014 05:15:29 -0700 (PDT)
Received: from 102529956.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 1B1B471B0001; Wed, 10 Sep 2014 05:15:29 -0700 (PDT)
Message-ID: <541040E1.1060701@innovationslab.net>
Date: Wed, 10 Sep 2014 08:15:29 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> <540F65C4.7050503@gmail.com>
In-Reply-To: <540F65C4.7050503@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="95dxQm5qUwaAq2bV05e2OukqEa5nMeOpf"
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/x8-xe9VDMnKm28m2GFiQEM2-qZ0
Cc: v6ops@ietf.org
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: Wed, 10 Sep 2014 12:15:43 -0000

Hi Brian,

On 9/9/14 4:40 PM, Brian E Carpenter wrote:
> On 10/09/2014 05:09, Brian Haberman wrote:
>>
>> On 9/9/14 10:16 AM, Fernando Gont wrote:
>>> On 09/09/2014 04:20 AM, Brian E Carpenter wrote:
>>>>>> OK, but I would also like to understand why we require
>>>>>> MLD messages for a Solicited-Node multicast address to
>>>>>> set Router Alert.
>>>>> Because in theory the multicast router needs to process the MLD message
>>>>> to build its forwarding table....
>>>> Why, for the Solicited-Node group, which is only meaningful on the link
>>>> from which the MLD message arrives?
>>> Then, let me change the question: Why do I need MLD for *this*?
> 
> I think Brian Haberman's reply shows why that is the wrong question.
> You need MLD for every multicast group, including a solicited-node
> group, and if you insist on MLD snooping in the bridges (let's not
> obfuscate by calling them switches) then you need to snoop every
> solicited-node group.
> 
> My question is orthogonal to MLD snooping: why do we require router-alert
> for MLD messages referring to a solicited-node group, since it by
> definition is limited to a single L2 link (even if that link is
> split up by bridges)?
> 
> I tend to think this requirement is an error in the MLD spec.

This is an interesting point.  The use of Router Alert was carried
through the various versions of IGMP/MLD from the original IGMPv1 spec.
 Since IGMPv1, IGMPv2, and MLDv1 sent Reports to the group address, the
Router Alert was meant to signal to routers that they needed to process
the packet.  There are two things that I think have changed.

1) Routers tend to trigger processing based on the Protocol or Next
Header field.  I think it would be worthwhile to verify with router
vendors that they do not use the Router Alert to trigger processing.

2) IGMPv3 and MLDv2 now send Reports are sent to an
all-multicast-routers multicast address.

Regards,
Brian H

> 
>     Brian C
> 
>> The MLD specs say that an MLD Report is sent for every multicast group
>> joined except the All-Nodes multicast address.
>>
>> The use of MLD Reports for essentially all multicast addresses was done
>> to facilitate this very type of snooping functionality.  The use of
>> Router Alerts in MLD messages is due to MLDv1 (and IGMPv2) using the
>> group address as the IP destination rather than the All-Routers
>> multicast address.
>>
>>> We probably use MLD because "If you use multicast, you use MLD". Truth
>>> is that, *unless your switch does MLD snooping* (and hence you *need*
>>> MLD, or else your packets will not flow around), you could completely
>>> kill MLD, and ND would still work just fine.
>>
>> Sure, since NDP is link-local.  The drawback is what happens if your
>> network is using RFC 4541 snooping that relies on seeing those MLD
>> messages to build forwarding/filtering tables?
>>
>>> Not to mention that there are nodes that default t running MLDv2 *for
>>> this* (way overkill, IMO)
>>>
>>
>> Why is MLDv2 overkill?
>>
>> Brian
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops