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

From: RJ Atkinson <[email-masked]>
Date: Tue, 9 Jul 2013 14:03:07 -0400

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