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

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

On 02/11/2012 13:49, Joe Touch wrote:
> Hi, Brian,
> 
> On 11/2/2012 1:17 AM, Brian E Carpenter wrote:
> ...
>>> Isn't the real bug the fact that the option numbers don't indicate
>>> whether an option is HBH or not?
>>
>> Why is that a problem? The extension header that contains the options
>> tells you that (0 for hbh options, 60 for destination options).
> 
> Except for extension headers that are yet to be defined.

I don't get your point, Joe. It is very clear in 2460 that extension
headers are only interpreted at the destination, except for the HBH
options header. So there's no scope to develop a new header with HBH
semantics. In any case, this is already covered in RFC 6564:
  "New IPv6 extension
   header(s) having hop-by-hop behavior MUST NOT be created or
   specified.  New options for the existing Hop-by-Hop Header SHOULD NOT
   be created or specified unless no alternative solution is feasible."

    Brian

> 
> I.e., while you're fixing the order, another key issue is that:
> 
>     all HBH options MUST occur only in the HBH extension header
> 
> (similarly, 60 isn't strictly the only destination header; see esp. the
> end of Sec. 4.6, but that is much less problematic)
> 
> Frankly, the HBH extension header is misnamed; AFAICT, this is intended
> to be the true forwarding plane options. Other other currently defined
> options (AFAICT), including the routing option, occur only when the
> router is really acting as a host (i.e., where that router owns the
> destination IP address of the packet).
> 
> Joe
>