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. 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 > > > . > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
