Hi Tony,
On 10-12-21 06:30 PM, Tony Li wrote:
Hi Suresh,
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
That's not _exactly_ true. See section 3 of that document. I think that that
section would create issues.
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?
The typical approach to code point exhaustion is to reserve one code point
value within the space for future expansion. Fortunately, that has already
been done. Value 255 has already been reserved. This is both necessary and
sufficient.
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?
I'm referring to the Specific Type and Header Options fields.
We will come back with a proposal to resolve the issues that you, Ran
and Fernando raised.
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
