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

Ole Troan <otroan@employees.org> Tue, 05 November 2013 10:12 UTC

Return-Path: <otroan@employees.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C5511E8196 for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 02:12:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.512
X-Spam-Level:
X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuKFkICPI39q for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 02:12:17 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CA7DB11E8267 for <v6ops@ietf.org>; Tue, 5 Nov 2013 02:12:13 -0800 (PST)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAEnDeFKQ/khM/2dsb2JhbABaw0yBJxZ0giYBBWUUEAsOOFcGiBS+I44PgUoHgyCBDwOqE4MnOw
X-IronPort-AV: E=Sophos; i="4.93,638,1378857600"; d="asc'?scan'208"; a="161402588"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2013 09:59:56 +0000
Received: from dhcp-lys02-vla252-10-147-116-88.cisco.com (dhcp-lys02-vla252-10-147-116-88.cisco.com [10.147.116.88]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA59xpSu004298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 09:59:52 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_F4D4C562-3F9E-4554-B396-2341BD09F8D0"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <52785F34.6020606@si6networks.com>
Date: Tue, 5 Nov 2013 10:59:51 +0100
Message-Id: <A9F99218-AB14-45AA-B29D-7E1D7E4B93FC@employees.org>
References: <5278275C.50206@gont.com.ar> <alpine.DEB.2.02.1311050028410.26054@uplift.swm.pp.se> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <F4AB804C-2C8E-40EF-ACE9-0A901E4F5122@employees.org> <52784DD1.7020106@gont.com.ar> <BD308F06-C9E2-42EB-9D23-CFD3432F1A1D@employees.org> <52785F34.6020606@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.1816)
Cc: "v6ops@ietf.org" <v6ops@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.12
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, 05 Nov 2013 10:12:23 -0000

Fernando,

>>> In any case, the interesting (and unfortunate) data if the
>>> chances of success when you use extension headers or
>>> fragmentation are in the scale of "unlikely". :-(
>> 
>> I'm not sure you can draw that conclusion without knowing where
>> the fragments are dropped.
>> 
>> e.g. you are not saying that fragmented packets will be dropped 
>> anywhere on the link between your home and mine, are you?
> 
> I'm certainly not. All tests were against web servers.
> 
> 
>> I'm for example not concerned about a web server or load balancer 
>> that sets TCP MSS to 1220 and then drop fragments.
> 
> Certainly, there's much more testing to be done (this is even stated in
> the slideware :-) ). That said, you might still be concerned about the
> case you meantion -- at least in theory, that case might arise in a
> NAT64 (?) case.
> 
> Also, one of the main points of this slideware is that its not just
> fragments that are dropped, but extension headers in general.
> 
> In any case, my goal of sharing the results is to trigger discussion
> and encourage further testing, rather than coming up with scary or
> bold statements.

splendid.

it would be very interesting to know where filtering is done.
my assumption is that it isn't done in what I call the Internet infrastructure,
but close to the hosts (edge), or in the hosts themselves.

pretty tricky to measure that from afar though.

cheers,
Ole