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

From: Warren Kumari <[email-masked]>
Date: Wed, 3 Jul 2013 19:58:10 -0400

On Jun 14, 2013, at 6:00 PM, Warren Kumari <[email-masked]> wrote:

> 
> On Jun 14, 2013, at 2:56 PM, Doug Barton <[email-masked]> wrote:
> 
>> On 06/14/2013 01:39 AM, t.petch wrote:
>>> ----- Original Message -----
>>> From: "Doug Barton" <[email-masked]>
>>> To: <[email-masked]>
>>> Sent: Thursday, June 13, 2013 9:23 PM
>>>> On 06/13/2013 01:17 AM, Randy Bush wrote:
>>>>>> FWIW, I don't think anyone has proposed "if the chain is larger
>>> than X,
>>>>>> then drop".
>>>>> 
>>>>> i am saying that i am telling my neighbor that, if the header length
>>> is
>>>>> larger than X, it is likely that their packet will not propagate.
>>> it's
>>>>> an ops bcp statement, not a statement of ipv6 protocol definition.
>>>>> 
>>>>> same as telling them that a bgp announcement of a prefix longer than
>>> a
>>>>> /24 likely will not propagete.
>>>>> 
>>>>> today, real routers really do drop packets with headers longer than
>>>>> various limits.  as an op, i am trying to remove the surprise in the
>>>>> 'various'.
>>>> 
>>>> I agree with Randy, providing guidance on this topic will be very
>>>> helpful, and BCP is the right category.
>>>> 
>>>> As for what the number should be, if 256 is in the 80th percentile or
>>>> higher of Warren's survey, that should be fine. A few vendors who are
>>>> examining less than that now may be encouraged to increase up to 256
>>>> knowing that they have a reasonable upper bound to shoot for, as
>>> opposed
>>>> to an arbitrarily large number that varies from implementation to
>>>> implementation.
>>> 
>>> I would like to check with current hardware designers that 256 is a good
>>> number for them, as opposed to 240, say.
>> 
>> Others (more knowledgeable than I) had already made that point, but for the record, yes, we should check with the hardware folks on this.
> 
> I've already mentioned this in one of the N (where is is becoming distressingly large) threads on this, but we are planning on:
> A: adding something like this (you should be able to look N bytes / headers in the packet) to the long headers draft (RSN, promise!) and / or
> B: writing an advice to implementers draft.

RSN finally happened. 

A new version of I-D, draft-wkumari-long-headers-01.txt
has been successfully submitted by Warren Kumari and posted to the
IETF repository.

Filename:	 draft-wkumari-long-headers
Revision:	 01
Title:		 Operational Issues Associated With Long IPv6 Extension Header Chains
Creation date:	 2013-07-04
Group:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-wkumari-long-headers-01.txt
Status:          http://datatracker.ietf.org/doc/draft-wkumari-long-headers
Htmlized:        http://tools.ietf.org/html/draft-wkumari-long-headers-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-wkumari-long-headers-01

Abstract:
  This document explains why IPv6 header chain length affects the cost
  of ASIC-based packet forwarding.  It also explains why some network
  service providers discard packets with exceptionally long header
  chains.  Finally, it identifies a reasonable header chain length.
  While a network service provider can enforce any filtering policy
  that supports its security model, a network service provider should
  not discard IPv6 packets based solely upon header chain length if the
  header chain is not longer than the value specified herein.

Apologies all for how long this took, we kept getting pulled into other things…
W

> 
> One of the co-authors (Ron) of the long-headers draft works for Juniper and has discussed this with their forwarding folk. We are also having discussions with other vendors on the same topic, and will hopefully have another author from at least one of the other large chappies…
> 
> W
> 
>> 
>>> What I mean is that 256 is a nice round number, for us as for them, and
>>> so is a natural choice.  But sometimes that has to include red tape,
>>> control information and such like, so what you get as a nice round
>>> number is a bit less when you pass it on to the next level of
>>> processing.  Of course, with some hardware, that is built in, so that
>>> the hardware gets something greater and passes on a nice round number to
>>> its user (as with memory cards) but I have known occasions in the past
>>> when this was not the case and the choice of a nice round number caused
>>> problems.
>>> 
>>> Apart from that 'detail', I agree with the approach.
>>> 
>>> Tom Petch
>>> 
>>>> Doug
>>>> 
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [email-masked]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>> 
>>> 
>>> 
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 
> 
> --
> Credo quia absurdum est.
> 
> 
> 

---
Schizophrenia beats being alone.

---

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