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

[Thomas Narten <[e-mail]>]

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 <[e-mail]> 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