IETF Logo Mail Archive

Re: [v6ops] Fragments [ULA draft revision #2 Regarding isolated networks]

Philip Homburg <pch-v6ops-3a@u-1.phicoh.com> Wed, 28 May 2014 15:16 UTC

Return-Path: <pch-bBB316E3E@u-1.phicoh.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 90D3E1A09F6 for <v6ops@ietfa.amsl.com>; Wed, 28 May 2014 08:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level:
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 b9P77UQQR9JJ for <v6ops@ietfa.amsl.com>; Wed, 28 May 2014 08:16:38 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 6954B1A09E1 for <v6ops@ietf.org>; Wed, 28 May 2014 08:16:36 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Wpfah-0000DjC; Wed, 28 May 2014 17:16:31 +0200
Message-Id: <m1Wpfah-0000DjC@stereo.hq.phicoh.net>
To: v6ops WG <v6ops@ietf.org>
From: Philip Homburg <pch-v6ops-3a@u-1.phicoh.com>
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <m261ks7xww.wl%randy@psg.com> <53840070.90801@gmail.com> <m2y4xn7wep.wl%randy@psg.com> <53840723.8010606@gmail.com> <CAKD1Yr1O_poMR200sjU=ttRvGaeQRkC1ZfXC0Ok4uQxdq3K=NQ@mail.gmail.com> <m2mwe37tbn.wl%randy@psg.com> <CAKD1Yr2t3-vxuG=iDi4biBNFpJwuzuHgfpB74i_uydWWRV7qZg@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <m2fvjv7q4h.wl%randy@psg.com> <m1WpDcc-0000BMC@stereo.hq.phicoh.net> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> <20140527222313.7B12716B8D59@rock.dv.isc.org> <53851236.8020209@bogus.com> <5385522F.40305@gmail.com> <4BA71D7E-7A38-4327-8C7D-7E49F047CDDB@ecs.soton.ac.uk> <EMEW3|51fc5e85b5e6c2650a1f63c2b27fdf6fq4RARx03tjc|ecs.soton.ac.uk|4BA71D7E-7A38-4327-8C7D-7E49F047CDDB@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D983181B2B5F33@XCH-BLV-! 504.nw. no s.boeing.com> <m1Wpel8-0000BZC@stereo.hq.phicoh.net> <415376E7-9A8F-46CB-ABEA-FD86102DFACF@ecs.soton.ac.uk> <EMEW3|b0e1ff0485d786fb04ada63ec6ebead4q4RFak03tjc|ecs.soton.ac.uk|415376E7-9A8F-46CB-ABEA-FD86102DFACF@ecs.soton.ac.uk>
In-reply-to: Your message of "Wed, 28 May 2014 15:36:47 +0100 ." <EMEW3|b0e1ff0485d786fb04ada63ec6ebead4q4RFak03tjc|ecs.soton.ac.uk|415376E7-9A8F-46CB-ABEA-FD86102DFACF@ecs.soton.ac.uk>
Date: Wed, 28 May 2014 17:16:31 +0200
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nvEcpdsrGKndYO5FQd27bTEQfGY
Subject: Re: [v6ops] Fragments [ULA draft revision #2 Regarding isolated networks]
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, 28 May 2014 15:16:40 -0000

In your letter dated Wed, 28 May 2014 15:36:47 +0100 you wrote:
>> Measurements using RIPE Atlas suggest that most filtering is done near =
>the edges.
>> So if you want a tunnel, make sure that your site and the remote site =
>don't do that
>> kind of filtering.
>>=20
>> In addition, fragmentation involving DNS seems to work way better than =
>sending
>> fragmented packets to the Alexa top 1m sites. So the kind of filtering =
>you encounter
>> may also depend on where you look.
>
>Do you have a pointer to these results?

I'm not aware of any measurements using RIPE Atlas that sent fragmented traffic to
the Alexa top 1m. In general, TCP does not generate that kind of traffic so it 
doesn't seem to be a real world scenario.

The people from NLnetlabs did use Atlas to look at fragmentation in the context 
of DNS. The main publication is 
https://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf

Section 5.4 provides an analysis of where blocks happen.

Other measurements using ICMP get in the same ballpark as the DNS results.
https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters

It is possible to directly run PMTU experiments on Atlas, but as far as I know nobody 
reported on that.

v2.23.0 | Report a Bug | By Email