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

[Fernando Gont <[e-mail]>]

Hi, Suresh,

I think some of the points/questions that I asked in my e-mail were had
not raised before.

And I think that even if the document were to continue in its current
form, those questions should be answered -- and possibly the answers
should be incorporated in the document.

So I look forward to the aswers...  :-)

Thanks!

Kind regards,
Fernando




On 22/12/2010 02:01 a.m., Suresh Krishnan wrote:
> 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,
> 
> 

-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1