Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 19 November 2013 19:27 UTC

Return-Path: <brian.e.carpenter@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 7F7B61AE1A9; Tue, 19 Nov 2013 11:27:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 a3zn0G18T3z8; Tue, 19 Nov 2013 11:27:03 -0800 (PST)
Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 057EC1AE1A5; Tue, 19 Nov 2013 11:27:02 -0800 (PST)
Received: by mail-pa0-f41.google.com with SMTP id lf10so1552082pab.0 for <multiple recipients>; Tue, 19 Nov 2013 11:26:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=i7NSRTWRZo0HjtUiNbJ0UUOX1aiK3oypX6cQYoWXVqw=; b=Jy09ZyrZHCW98C8xeNBT2aYn/nzJtbyPd7tOHV6NjSp4A00XIbPRh1ZG9d8iVImFxW sALxv3N2AJH0Md83W/eUTBfhOJfobjJSpVFAdRbM285f6HSct4RtnSFgKx2zS+orgsbq rt99d6B+kPmM+XWIrZASPADtp+YcB8aP1PDdkRlgP+dDEYA8MjusmTCBsWSAT8Nbiq1J dvy+j/FN0wjcRREBasj4cwUDMXwbMH9IbZPVTMxzKwIg0GJL5fPe3wr6Yo8ZD802MteR THhk7ho7MOL3CI1p0LN4aTHECRKfSZyAqa6e2/TRXsNlF/SinKBttrakh2ls1C/s/HvK uQ5A==
X-Received: by 10.68.203.73 with SMTP id ko9mr2641514pbc.170.1384889217015; Tue, 19 Nov 2013 11:26:57 -0800 (PST)
Received: from [192.168.178.20] (240.200.69.111.dynamic.snap.net.nz. [111.69.200.240]) by mx.google.com with ESMTPSA id dq3sm32283058pbc.35.2013.11.19.11.26.53 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 11:26:55 -0800 (PST)
Message-ID: <528BBB80.5010508@gmail.com>
Date: Wed, 20 Nov 2013 08:26:56 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ronald Bonica <rbonica@juniper.net>
References: <5278275C.50206@gont.com.ar> <5a9e4532c4e14bddbd9d824133820157@CO1PR05MB442.namprd05.prod.outlook.com> <528AEA8D.1070804@gmail.com> <26b868a1fe7b45c5a1dd2f688caefc19@CO1PR05MB442.namprd05.prod.outlook.com>
In-Reply-To: <26b868a1fe7b45c5a1dd2f688caefc19@CO1PR05MB442.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Fernando Gont <fernando@gont.com.ar>
Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet
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, 19 Nov 2013 19:27:05 -0000

On 20/11/2013 04:29, Ronald Bonica wrote:
> Brian,
> 
> I see your point. If we fix the problems associated with extension headers, people will configure their middle-boxes to allow them. So, if we repeat Fernando's experiment in a few years, we may see very different results. 
> 
> You say that there are three distinct problems. I am aware of the following:
> 
> - the tiny fragment problem (addressed by draft-ietf-6man-oversized-header chain)
> - the long header chain problem (addressed by draft-kumari-6man-long-headers)
> 
> What is the third problem?

 - middleboxes that don't deal with all header types (addressed by draft-ietf-6man-ext-transmit)

   Brian

> 
>                                               Ron
> 
> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>> Sent: Monday, November 18, 2013 11:35 PM
>> To: Ronald Bonica
>> Cc: Fernando Gont; 6man@ietf.org; IPv6 Operations
>> Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on
>> the Internet
>>
>> On 19/11/2013 10:50, Ronald Bonica wrote:
>>> Folks,
>>>
>>> Fernando presents two studies in <http://www.iepg.org/2013-11-
>> ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>. The second study is
>> more interesting to me, because duplicate addresses are removed.
>>> The following are a few questions regarding Fernando's second study:
>>>
>>> 1) Fernando observes that 41% of sites discard fragmented packets.
>> However, in a similar study
>> (http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-
>> thesis.pdf) only 10% of sites discarded fragmented packets. I wonder
>> why the two studies yield such divergent results.
>>
>> Well, that depends on whether there are significant differences between
>> the observation points and/or the set of target sites for the two
>> studies. There's certainly no law of physics that prevents both
>> measurements being correct.
>>
>>> 2) Fernando observes that 44% of sites discard packets containing an
>> 8 byte destination header, while 89% of sites discard packet containing
>> 1 kilobyte of extension headers. Because the first number (44%) is so
>> high, can I conclude that the second (89%) is insignificant.
>>
>>> Could it be that extension header length is a non-issue, because so
>> many sites filter packets containing extension headers, regardless of
>> their length?
>>
>> I don't think so. We've just agreed on an update to RFC 2460 that, if
>> it is adopted by middleboxes, will fix or at least clarify the issue of
>> what happens to short extension headers. We need to wait a few years to
>> see if that happens, of course. That seems to me to be quite disjoint
>> from the issue of whether boxes that inspect extension headers have big
>> enough buffers, and distinct again from whether they handle fragmented
>> headers. I think there are three problems, needing three solutions.
>>
>>    Brian
>>                                                           Ron
>>>> -----Original Message-----
>>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf
>>>> Of Fernando Gont
>>>> Sent: Monday, November 04, 2013 6:02 PM
>>>> To: 6man@ietf.org; IPv6 Operations
>>>> Subject: Some stats on IPv6 fragments and EH filtering on the
>>>> Internet
>>>>
>>>> Folks,
>>>>
>>>> I did a presentation on the topic at the IEPG meeting earlier this
>>>> week.
>>>> It provides some concrete data regarding IPv6 fragmentation and
>>>> Extension Header filtering on the Internet.
>>>>
>>>> The slideware is available at:
>>>> <http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-
>>>> eh.pdf>
>>>>
>>>> Certainly there's *much* more work to be done in this area, but I
>>>> thought that this could be good food sfor some of the discussions
>>>> that we were having on the topic.
>>>>
>>>> Thanks,
>>>> --
>>>> Fernando Gont
>>>> e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP
>> Fingerprint:
>>>> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>