On Jun 14, 2013, at 6:00 PM, Warren Kumari <[email protected]> wrote:
> > On Jun 14, 2013, at 2:56 PM, Doug Barton <[email protected]> wrote: > >> On 06/14/2013 01:39 AM, t.petch wrote: >>> ----- Original Message ----- >>> From: "Doug Barton" <[email protected]> >>> To: <[email protected]> >>> 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 protected] >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> >>> >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -- > Credo quia absurdum est. > > > --- Schizophrenia beats being alone. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
