Re: [v6ops] [6MAN] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain)

RJ Atkinson <rja.lists@gmail.com> Tue, 09 July 2013 18:11 UTC

Return-Path: <rja.lists@gmail.com>
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 96B6321F9B8D for <v6ops@ietfa.amsl.com>; Tue, 9 Jul 2013 11:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level:
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599]
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 I+F0QA-drluR for <v6ops@ietfa.amsl.com>; Tue, 9 Jul 2013 11:11:58 -0700 (PDT)
Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4383521F9B38 for <v6ops@ietf.org>; Tue, 9 Jul 2013 11:11:58 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id hu16so6545268qab.15 for <v6ops@ietf.org>; Tue, 09 Jul 2013 11:11:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:resent-from:date :content-transfer-encoding:resent-date:resent-to:message-id:to :x-mailer; bh=4O7fenVCcBoWeCIn0oF+fA7CGWTYztOQ9QqSw+hGSLk=; b=MzOynu5p1M7vgLe8lxCughg48LQIhs31KhQbOuhaAHUOinags5FumiYHKTtzvT5FVr /6db1b1FUpeQ7GTH6FSxiv484rLjf2gUGqRttbDBdlLr+syURnnwCGx9dx6iwAlezGxx C0dnNRslPIfuHeHM9ctkIV++QgwIDIIG07K7aWtOdYQkZ4c4Ar86m3wixIEcfFCwdK7A tMPRjb9hZ2tDWvXqPwZmcPB3dV780J8Xnt1/0mSjtHSKASJU76geGhv41WNcr++1T7Tq wwbDAGScd5EYh48+NsgROOnScEvaSW62Z6cmRSpZth71MtQL7cGy5M/S49+7bk3tlUbv pCjg==
X-Received: by 10.224.115.79 with SMTP id h15mr24203356qaq.41.1373393517668; Tue, 09 Jul 2013 11:11:57 -0700 (PDT)
Received: from [10.30.20.12] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id a8sm20708194qae.11.2013.07.09.11.11.57 for <v6ops@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 11:11:57 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: RJ Atkinson <rja.lists@gmail.com>
Resent-From: RJ Atkinson <rja.lists@gmail.com>
Date: Tue, 09 Jul 2013 14:03:07 -0400
Content-Transfer-Encoding: 7bit
Resent-Date: Tue, 09 Jul 2013 14:11:56 -0400
Resent-To: v6ops@ietf.org
Message-Id: <1C0DCB6D-18F4-4A16-843C-3822921E5CF7@gmail.com>
To: ipv6@ietf.org
X-Mailer: Apple Mail (2.1283)
Resent-Message-Id: <20130709181158.4383521F9B38@ietfa.amsl.com>
Subject: Re: [v6ops] [6MAN] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain)
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, 09 Jul 2013 18:11:58 -0000

All,

I support the ideas expressed in this draft.

In the early part of this century, while working for an
equipment supplier that designed their own packet processing
chips, I was involved with the design of a packet processing 
chipset that could handle (even small IP packets) at line rate
on 10 Gbps Ethernet interfaces, including parsing the IPv6 
header chain and applying L4 filtering ACLs.  Adding that
ability to parse IPv6 header chains & perform L4 filtering at 
line-rate on a 10 GigE interface did NOT increase the ASIC 
gate count enough to change the die size.  So there was no 
recurring manufacturing cost for that feature.  As I recall,
this implementation could at least parse 128 bytes into the 
IPv6 header chain.  I'm pretty confident that the implementation
did not parse any deeper than 255 bytes, and I am certain
that it could not parse more than 255 bytes into the header
chain.

I have heard from several ISPs that a different manufacturer
has for some years now (at least 6 years) deployed backbone
routers that can at least parse past 1 IPv6 extension header
to apply L4 ACLs/filtering -- also at line rate on interfaces
operating at 10 Gbps (possibly higher speed by now).  One
person at that firm has confirmed this ability to me verbally. 
I'm not certain precisely what the depth of their parsing
ability might be.

So there are at least two implementations of ASIC/FPGA-based
packet processors that can parse IPv6 header chains at 10 Gbps
line-rate (possibly higher).

I think long term, this capability will be highly desired 
(and in at least some operational environments, needed).
This capability will tend to help encourage IPv6 deployment,
because it will help IPv6 L4 ACL implementations perform at
a level comparable to IPv4 L4 ACL implementations.

This draft provides a significant help both to implementers
and operators by providing a specification for a minimum
parse depth (i.e. 128 bytes as per Section 4 of this I-D).

I hope that this draft is able to move forward as a BCP.

Yours,

Ran Atkinson