Re: I-D Action:draft-ietf-6man-exthdr-01.txt

[Suresh Krishnan <[e-mail]>]

Hi Tony,
   Thanks for your comments. Please see responses inline.

On 10-12-21 01:10 PM, Tony Li wrote:
> On Dec 20, 2010, at 5:48 PM, Tony Li wrote:
> 
>> I do not support this work.  It seems ill conceived and unnecessary.
>>
>> If there are needs for new extension headers, they should be presented.  If the data must be carried as an extension header, then specific new extension headers should be defined for those code points.
> 
> 
> I've gotten multiple requests to expound on my comments.  To wit:
> 
> It does seem helpful and useful to propose that future new extension headers be TLV encoded.  While it seems obvious from 2460 that this was the intent, I cannot find that explicitly stated anywhere.  I would support this draft simply stating that and no more.  This should therefore be a one sentence document (minus the boilerplate ;-).  

And that is exactly what this draft started out as (a standard format 
for new extension headers to follow).

http://tools.ietf.org/html/draft-krishnan-ipv6-exthdr-00

> 
> I have an issue with creating the explicit header without a clear requirement.  As best I can tell, there is an allocation of a code point, which thereby implies that the figures shown in the draft are a literal extension that is being proposed and not just an example.  It seems very wasteful to burn this code point without an explicit and clear clause.  

Since RFC2460 came out, four new extension headers have been defined.

135 - Mobility header
139 - HIP
140 - Shim6
141 - WESP

The idea of burning one protocol number right now was suggested by the 
WG in order to limit further exhaustion of the protocol number space. 
Would it be more acceptable to you, if we do not ask for an IANA 
allocation for a protocol number at this point, and wait till the first 
"Specific Type" request comes up?

> 
> It seems like a generic extension will simply create a security issue, with a new covert channel for IPv6.
> 
> The document seems to mandate the internal format of future extensions, above and beyond TLV encoding.  This seems overly restrictive and insufficiently motivated.

Which fields are you specifically concerned about?

Thanks
Suresh