Re: Comments on draft-ietf-6man-exthdr-01.txt (was: Some comments questions on draft-krishnan-ipv6-exthdr-08)

[Suresh Krishnan <[e-mail]>]

Hi Fernando,

On 10-12-21 06:53 PM, Fernando Gont wrote:
> Folks,
> 
> FWIW, I never got a response to these comments I sent a while ago....

I understood your comments as agreeing with Ran's (and they have not 
been resolved either). The points you, Ran and Tony raised about the 
scope of the draft being larger than it should be are all valid, but all 
the additional features (other than just the common format) have been 
added due to feedback from the working group (mailing list and face 2 
face meetings). We will discuss with the chairs and see what is an 
acceptable way forward.

Thanks
Suresh

> 
> Thanks!
> 
> Kind regards,
> Fernando
> 
> 
> 
> 
> -------- Original Message --------
> Subject: Some comments questions on draft-krishnan-ipv6-exthdr-08
> Date: Wed, 17 Nov 2010 11:50:40 -0300
> From: Fernando Gont <[e-mail]>
> To: [e-mail] <[e-mail]>,  Suresh Krishnan
> <[e-mail]>, [e-mail], [e-mail],
> [e-mail] <[e-mail]>
> 
> Folks,
> 
> Some comments/questions regarding the aforementioned I-D:
> 
> * Meta:
> As noted by Ran Atkinson, I think you should clearly state what sort of
> options that would not fit in the Hop-by-Hop or the Destination Options
> headers you think could be specified (that would warrant yet another
> extension header)  -- Existence of this would be the motivation (or lack
> of) to pursue the proposal in this document.
> 
> Specific comments:
> 
> * Section 2 states:
> 
>> The intention of the base IPv6 Specification [RFC2460] that
>> destination hosts not be permitted to skip unknown extension headers
>> continues to apply.
> 
> Isn't this I-D all about allowing nodes to skip unknown headers??
> 
> 
> * Section 2 states:
> 
>> Another one is that this generic extension header conserves values in
>> the IPv4 protocol numbers registry.
> 
> Of the top of my head, less than 25% of that space is used. And this is
> not going to change much (at least in the IPv4 world), as it is
> virtually impossible to use such packets across unmanaged NATs.
> 
> 
> * Setion 2 (2.  Generic IPv6 Extension Header (GIEH) format).
> 
> Why not simply enforce a TLV format? (i.e., no "Specific Type" at all)
> 
> 
> 
> * Section 4
> 
>> 4.  Exceptions
>>
>> The the Generic IPv6 extension header is generic enough that it is 
>> suitable to use for most applications.  However, it is possible that 
>> the GIEH does not satisfy the requirements in all cases where new 
>> extension headers are required.  Hence, the existence of this
>> generic header does not necessarily preclude the definition of new 
>> independent IPv6 extension headers.
> 
> If this not going to be enforced for all new headers, is this worth the
> effort?
> 
> 
> * Section 5 (Future work)
> 
>>From the PoV of a firewall, this is simple: either the traffic complies
> with my policy, or I block it.
> 
> Put another way: if the extension header is unknown, this is the reason
> (other than the unknown syntax) for the firewall to block it.
> 
> Thanks!
> 
> Kind regards,