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