FWIW, I'm sympathetic to Tony's basic sense that it is unclear that we need to do this work/document.
I'm still not clear on exactly what *real* problem it solves. Suresh Krishnan <suresh.krish...@ericsson.com> writes: > Since RFC2460 came out, four new extension headers have been defined. > 135 - Mobility header > 139 - HIP > 140 - Shim6 > 141 - WESP 2 of the above code points are used by IPv4, so having a generic extension header mechanism for IPv6 would have saved only 2 code points. No need to panic folks... > 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? My general sense is that this work is mostly just good common sense advice to someone who has a need to define a new extension type. But until we see such a concrete proposal, I am not convinced (yet) that we should define anything new that suggests people go change implementations or allocate code points. Both are premature. As one concrete example, RFC 5175 defines extensions for adding future RA flags. But, none have been defined yet, so the work really isn't needed yet and implementations certainly don't need to do anything yet. However, that has not stopped NIST and DoD from citing these documents recommendations to implement. Upleveling a bit, and thinking about routing headers and destination options, my general sense is about such options is: 1) Destination options are the preferred route. Any other kind of option will be extremely hard to deploy, has all kinds of barriers, etc. (This proposal will have no impact on future destination options. Right?) 2) The routing header is essentially deprecated, and we probably won't define any more. We've already deprecated RHO. RH1 was never used, is now deprecated, and arguably shouldn't even count as ever having been defined. RH2 is the MIP routing header. RH2 was originally a regular type 0 option, but was changed because of the fear that firewalls would block packets with such options by default, preventing MIPv6 from being deployed. If we had to do it all over again, MIPv6 arguably should have used a destination option, since by definition RH2 is only processed if the two addresses in the routing header are on the same node, which is much more in line with the intention behind destination options. Which leads me to ask, exactly what kinds of future options do we think will take advantage of this new format? Note, my bias on this general topic is based on experience that unless we have something concrete driving this sort of work, we risk getting it wrong. So, I'm still trying to be convinced we need to do this sort of work *now*. If there was an actual proposal for a new option that solved some sort of real problem, things might be different. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------