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

Ole Troan <otroan@employees.org> Tue, 05 November 2013 12:47 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 8000611E82A8 for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 04:47:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.523
X-Spam-Level:
X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 cV9Rv8Jl4pBP for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 04:47:18 -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 CA42F11E82A7 for <v6ops@ietf.org>; Tue, 5 Nov 2013 04:47:13 -0800 (PST)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAOzneFKQ/khM/2dsb2JhbABZgwfARYEpFnSCJQEBBAF5EAtGVwaIDga+Lo9ZB4MggQ8DkC6ZZYMnOw
X-IronPort-AV: E=Sophos; i="4.93,639,1378857600"; d="asc'?scan'208"; a="161411609"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2013 12:47:12 +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 rA5Cl8pP000399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 12:47:09 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_61B923E4-B73D-49B1-B76A-D78980DB6F31"; 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: <5278E639.3040606@inex.ie>
Date: Tue, 5 Nov 2013 13:47:08 +0100
Message-Id: <C4864CA1-C8F4-45D6-944A-0E8BA073D4A7@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> <A9F99218-AB14-45AA-B29D-7E1D7E4B93FC@employees.org> <5278E639.3040606@inex.ie>
To: Nick Hilliard <nick@inex.ie>
X-Mailer: Apple Mail (2.1816)
Cc: Fernando Gont <fgont@si6networks.com>, "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 12:47:26 -0000

Nick,

>> 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.
> 
> as Mike Abrahamsson said, if you have cisco sup720 (or anything with a
> PFC3) in the path, then you have serious problems with frags.  As an
> operator you need to make a decision between dropping all frags in hardware
> (chassis-wide), passing all frags in hardware (chassis-wide, noting that
> this removes control plane protection for v6 frags), or slow-pathing the
> frags via the RP (thereby opening up the RP to being trashed).  From an
> operational point of view there is really only one option.
> 
> You could say that this is an operator problem and they get what they
> deserve for running equipment of this era, but realistically these devices
> will be running on the internet until the heat death of the universe.

yes, I should have included something about "barring software bugs".
if you use one of these in the Internet core I cannot see any other choice than to
allow forwarding of fragments. 

cheers,
Ole