Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

[Brian E Carpenter <[e-mail]>]

On 01/11/2012 19:06, Brian E Carpenter wrote:
> Joe,
> 
> On 01/11/2012 18:34, Joe Touch wrote:
>>
>> On 11/1/2012 2:35 AM, Brian E Carpenter wrote:
>>> On 31/10/2012 18:58, Joe Touch wrote:
>>>>
>>>> On 10/31/2012 11:34 AM, Fernando Gont wrote:
>>>>> On 10/31/2012 04:11 PM, Joe Touch wrote:
>>>>>> Yes, but the whole point of the IPv6 option architecture was to avoid
>>>>>> the issues seen with IPv4 options.
>>>>> The only thing in that IPv6 would avoid is requiring routers to parse
>>>>> *all* options, just to find the ones that need to be processed by
>>>>> routers.
>>>> Yes.
>>> No. The only extension header that *needs* to be parsed by intermediate
>>> routers is the hop-by-hop options header, and that is the first one (if
>>> present).
>> The first one could be:
>>
>>     A. a known HBH option
>>         indicating there are HBH options
>>     B. a known E2E option
>>         indicating there are no HBH options
>>     C. an unknown option or a pad option
>>         indicating NOTHING
> 
> Actually there is another unfortunate aspect of RFC 2460 here. It would
> be better if it said that the hbh options extension header MUST be
> first, instead of just recommending it. I think I will add that to my draft.

I was wrong. 2460 does have this as a lower case "must".

   Brian
> 
>> In the case of C, the router needs to keep looking at subsequent options
>> until one of three things happens:
>>
>>     1. a known HBH option is seen
>>         indicating there are HBH options
>>     2. a known E2E option is seen
>>         indicating there are no HBH options
>>     3. there are no more options
>>         indicating there are no HBH options
>>
>> As a result, it's entirely possible that a router could need to parse
>> the entire option chain before it can determine whether there are any
>> HBH options.
> 
> Yes, because of the point I just mentioned. That's a bug IMHO.
> However, the observed problems come from middleboxes that don't
> parse regular extension headers, not hbh option headers.
> 
>      Brian
> 
>>> (You can legitimately argue that the hbh header and the routing header
>>> are effectively useless, but that doesn't break fundamental
>>> connectivity.)
>>>
>>> IPv6 routers should have nothing to do with fragmentation.
>> +1
>>
>>> The problem is due to middleboxes that break the IPv6 spec by inspecting
>>> any part of the packet beyond the hop-by-hop header and discarding what
>>> they don't understand.
>> +1
>>
>> Joe
>>
>