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! 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 --------------------------------------------------------------------
