I do NOT support this draft, for one quite simple reason: ** The assumption of this draft is that there exists some IP option type that is NEITHER (a) hop-by-hop nor (b) end-to-end in nature.
I have never heard of such an option, but if someone can provide a concrete example I'm eager to hear about it. By contrast, I know of equipment deployed today (and for the past few years) from more than 1 router/firewall vendor that already has silicon that can parse (and, significantly, parse PAST) IPv6 Destination Options or IPv6 Hop-by-Hop Options in order to discover the transport-layer protocol and transport-layer protocol header values (e.g. port numbers). A common deployed use for this capability is to make access control decisions based in part upon the transport-layer protocol and transport-layer port numbers, even in the presence of IPv6 optional headers. Standardising this proposal has the effect of breaking this *deployed* capability, which is important to a significant installed base that use this capability today. Now, I happen to be familiar with the internals of at least one of the chips with this capability. Adding that capability did not significantly increase the gate count and did not increase the die-size of a die already pretty full with other stuff. So there are multiple existence proofs that one can design and fabricate silicon with the deployed approach. Whether a particular implementation does this or not is largely a business decision, rather than a technical decision. We do not want to encourage the creation of ANY IPv6 option that is NEITHER a Destination Option NOR a Hop-by-Hop option and consequently are NOT carried inside either of those headers. Yours, Ran Atkinson [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
