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

Nick Hilliard <nick@inex.ie> Tue, 05 November 2013 13:08 UTC

Return-Path: <nick@inex.ie>
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 92A0211E8168 for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 05:08:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6]
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 ZxpgPm7saFw6 for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 05:08:19 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id E248E11E8193 for <v6ops@ietf.org>; Tue, 5 Nov 2013 05:08:05 -0800 (PST)
X-Envelope-To: v6ops@ietf.org
Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rA5D7t6w093154 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Nov 2013 13:07:56 GMT (envelope-from nick@inex.ie)
X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.dyn.netability.ie
Message-ID: <5278EDAB.5030601@inex.ie>
Date: Tue, 05 Nov 2013 13:07:55 +0000
From: Nick Hilliard <nick@inex.ie>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Ole Troan <otroan@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> <C4864CA1-C8F4-45D6-944A-0E8BA073D4A7@employees.org> <5278E986.9050409@inex.ie> <C1BEE5D4-FDC2-4E4B-947D-CEC9E4F05E5D@employees.org>
In-Reply-To: <C1BEE5D4-FDC2-4E4B-947D-CEC9E4F05E5D@employees.org>
X-Enigmail-Version: 1.6
X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804
X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3
X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee
X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24.
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 13:08:19 -0000

On 05/11/2013 12:54, Ole Troan wrote:
> why don't you filter out packets on the edge destined to your router's addresses?
> instead of what's effectively breaking IPv6 service across the network.

you can use infrastructure acls if they are handled carefully and don't
depend on implicit "deny any any" (which has special handling for the
"platform ipv6 acl fragment hardware").  But in order to implement this you
need to protect every single link network connected to your PFC3s.  If your
addressing plan is designed with this in mind, it's feasible.  If you have
a very large network or if you've not handled your link address assignments
very carefully, it's often not practical because it means dynamically
maintaining huge access lists on every single device on the network.

Nick