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 ;-). 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. 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. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
