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

Jared Mauch <jared@puck.nether.net> Tue, 05 November 2013 15:30 UTC

Return-Path: <jared@puck.nether.net>
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 F264311E80E6 for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 07:30:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 zaLXnA3YNEE0 for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 07:30:56 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id A3A0311E80EC for <v6ops@ietf.org>; Tue, 5 Nov 2013 07:30:49 -0800 (PST)
Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id rA5FUhUn028251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 10:30:44 -0500
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
Content-Type: text/plain; charset="us-ascii"
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <52790CE7.6010506@gmail.com>
Date: Tue, 05 Nov 2013 10:31:08 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <F326A8CA-50B4-4206-A98C-FE12E103DB35@puck.nether.net>
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> <5278EDAB.5030601@inex.ie> <52790CE7.6010506@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1816)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.1 (puck.nether.net [204.42.254.5]); Tue, 05 Nov 2013 10:30:44 -0500 (EST)
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 15:30:57 -0000

On Nov 5, 2013, at 10:21 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> On 06/11/2013 02:07, Nick Hilliard wrote:
>> 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.
> 
> I think Homer Simpson has a word for this situation.
> 
> We *really* aren't going to deprecate fragmentation because of one
> model of broken kit, are we?

I think the challenge here is that Cisco doesn't care to fix the problem
inherent in their software/hardware integration issue here.  There is no
structural correction of the defects in the software and nobody there takes
ownership to correct it.

I've sadly seen this play out time and time again without anyone fixing basic
infrastructure items that need correction.  They're unable to as it impacts
too many sub-platforms/internal consumers of the code that don't see the value
as it's not adding revenue.

Many of these headers (eg: hop-by-hop) are comparable to IPv4 features that
are ignored or dropped by firewalls and routers (Eg: source-route, ecn, etc).

Without an explicit standard that says things MUST be supported that we can
cite in RFP/RFI and broad coalition of purchasers it's difficult or impossible
to change things.  Places like Cisco are too big to steer and correct the
bad behavior.  I would love to be proven wrong, but years of experience tell
me it's not going to get better.

- Jared