Re: [v6ops] Interesting problems with using IPv6

joel jaeggli <joelja@bogus.com> Thu, 11 September 2014 02:41 UTC

Return-Path: <joelja@bogus.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 E37B61A046B for <v6ops@ietfa.amsl.com>; Wed, 10 Sep 2014 19:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.552
X-Spam-Level:
X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 gYMUS9Tk9kgg for <v6ops@ietfa.amsl.com>; Wed, 10 Sep 2014 19:41:39 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C751A0456 for <v6ops@ietf.org>; Wed, 10 Sep 2014 19:41:38 -0700 (PDT)
Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s8B2faL6096550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 11 Sep 2014 02:41:37 GMT (envelope-from joelja@bogus.com)
Message-ID: <54110BDA.9000104@bogus.com>
Date: Wed, 10 Sep 2014 19:41:30 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Thunderbird/32.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Brian Haberman <brian@innovationslab.net>
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> <540F9FA9.3070300@si6networks.com> <540FB46F.2010200@gmail.com> <CAPi140MmfaqG9kFNTdAi=RhH8YJDV2OVXYvi4FgxvkD_mEQx=Q@mail.gmail.com> <5410437E.2070208@innovationslab.net> <5410FBDB.1070507@gmail.com>
In-Reply-To: <5410FBDB.1070507@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0akRQhhO6DVDwIxRJ39JA4jbOgd9KbCLG"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 11 Sep 2014 02:41:37 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ohR_MICsCiRfw8nZJ5i0SQfevWw
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: Thu, 11 Sep 2014 02:41:42 -0000

On 9/10/14 6:33 PM, Brian E Carpenter wrote:
> On 11/09/2014 00:26, Brian Haberman wrote:
>> Hi Andrew,
>>
>> On 9/10/14 6:18 AM, Andrew 👽  Yourtchenko wrote:
>>> On 9/10/14, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>>> On 10/09/2014 12:47, Fernando Gont wrote:
>>>>> On 09/09/2014 05:40 PM, Brian E Carpenter wrote:
>>>>>>>> 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)?
>>>>> .. to avoid them being a special case?  -- i.e., all MLD packets carry a
>>>>> Router Alert option.
>>>> Yes, it would be an exception. But we know that HbH options in general
>>>> and Router Alert in particular are a serious performance issue, and
>>>> that all links carry this particular kind of MLD traffic, so an
>>>> exception seems like something to be discussed.
>>> How does this interact with the case where a "pure L2" switch within
>>> the link would want to snoop MLD ? Presumably, today the L2 switch
>>> would see the "router alert" and know that it needs to process this
>>> traffic.
>>>
>>> If this were to be removed, then it would be much trickier to direct
>>> the traffic to the slow path in that scenario, wouldn't it ?
>>
>> I think that depends.  As I mentioned in an earlier e-mail, some routers
>> simply use the IPv4 Protocol field or the IPv6 Next Header field to see
>> if they need to process the packet.  It is unclear (to me) how many
>> implementations still use the Router Alert to determine if the packet
>> needs local processing.  Maybe some vendors could chime in?
> 
> I have the impression that many boxes will look at *any* ICMPv6
> packet, because in their firewall role they filter ICMPv6.
> In that case the Router Alert is certainly redundant. However,
> we do need vendor feedback, as you say.

Beware equating filtering with with inspection by the control plane,
many asic based forwarding platforms ingress acl matches are never slow
path. they wouldn't be useful for dos protection if they had to hit a cpu.

> 
>    Brian C
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>