On 11/06/2013 08:59, Warren Kumari wrote:
> On Jun 10, 2013, at 4:12 PM, Brian E Carpenter <[email protected]>
> 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:
Sure, except that this would add it to a standards track draft
(fwiw).
Brian
>>> 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
>>> <[email protected]> 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
>>>> [email protected]
>>>> 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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
