Warren Kumari ------ Please excuse typing, etc -- This was sent from a device with a tiny keyboard.
On Jun 10, 2013, at 4:59 PM, Warren Kumari <war...@kumari.net> wrote: > > On Jun 10, 2013, at 4:12 PM, Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: > >> Why wouldn't we add a sentence in -oversized-header-chain >> following this: >> >>> 6. Updating RFC 2460 >>> >>> If an IPv6 packet is fragmented, the first fragment of that IPv6 >>> packet (i.e., the fragment having a Fragment Offset of 0) MUST >>> contain the entire IPv6 header chain. >> >> >> The entire IPv6 header including the header chain SHOULD NOT exceed >> 256 octets. >> >> (or whatever magic number we decide on). >> >> We might need some words to justify that, but they can be found >> in this thread. > > You mean like what I said in the below email: >>> We are planning on updating the long-headers draft / publishing another >>> "implementers guide" draft that suggests 128 or 256 bytes (as a straw man). >>> This will hopefully be something that major vendors will sign up for. > > > Fine idea! ... and we are still planning on doing this as well. Never hurts to have the same things repeated.... W > > W > >> >> Regards >> Brian Carpenter >> >> On 11/06/2013 03:03, Warren Kumari wrote: >>> On Jun 10, 2013, at 12:31 AM, Brian E Carpenter >>> <brian.e.carpen...@gmail.com> wrote: >>> >>>> On 10/06/2013 04:49, Tom Taylor wrote: >>>>> On 09/06/2013 9:42 AM, Fernando Gont wrote: >>>> ... >>>>>> I guess having a L4-pointer would have helped quite a lot. >>>>>> >>>>>> Cheers, >>>>> Would it be practical to define a HBH option that has an L4 pointer and >>>>> assign a fixed order to it? >>>> http://tools.ietf.org/html/draft-zhang-6man-offset-option-01 >>>> >>>> It didn't fly in this WG at the time. >>> >>> The issue is that, in order to be able to see header X you need to push all >>> the bits up to header X onto the forwarding engine. Having a header that >>> says "The L4 header is at byte 142" simply pushes the L4 out by another 8 >>> bytes, exacerbating the problem. >>> >>> This issue is: >>> 1: In order to make a decision on header X the forwarding / filtering >>> engine needs to see header X >>> 2: This require pushing at least <number of bytes from start of packet to >>> end of header X> up to the forwarding engine in a "cell". >>> 3: Bandwidth into the forwarding engine is expensive / limited, and storage >>> on the forwarding engine is expensive (this is not DRAM ;-)) >>> 4: As you don't know (until you've looked) how far into the packet header X >>> is, you need to choose some number and ship that many bytes to the >>> forwarding engine. >>> 5: Having a header that points at the L4 info doesn't help -- by the time >>> you can see it you've already sucked the bits onto the engine. >>> 6: Having additional logic that "prescreens" the packets looking for a >>> pointer header *could* possibly work, but that is much of the forwarding >>> engine logic - see #3. >>> >>> Choosing the optimum cell size is the tricky bit. If you increase the cell >>> size you vastly increase cost -- if your competitors don't do the same, >>> you've priced yourself out of the market. >>> >>> We are planning on updating the long-headers draft / publishing another >>> "implementers guide" draft that suggests 128 or 256 bytes (as a straw man). >>> This will hopefully be something that major vendors will sign up for. >>> >>> W >>> >>> >>>> Brian >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>> -- >>> It's a mistake trying to cheer up camels. You might as well drop meringues >>> into a black hole. -- Terry Prachett >>> >>> >>> . > > -- > It is impossible to sharpen a pencil with a blunt axe. It is equally vain > to try to do it with ten blunt axes instead. > -- E.W Dijkstra, 1930-2002 > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
