All,
I have very strong sympathy with the thoughts expressed by
Thomas Narten in this note,
<http://www.ietf.org/mail-archive/web/ipv6/current/msg13209.html>
especially:
(A) the root question (not yet clearly answered, although it has been
asked more than once) of what problem this I-D is trying to solve
&&
(B) the observation about how RFC-5175 has been handled by various
"IPv6 Profile" organisations:
I also agree with Brian Carpenter's observation:
% So the one thing this proposal will *not* do is allow
% new extension headers to cross the Internet transparently.
Indeed, the BEST chance for a new IPv6-specific extension to be
deployable is to be specified to be carried within an IPv6
Destination Options header. Further, I believe that if a
future proposal could be carried in an IPv6 Destination Option,
then it ought to be REQUIRED to be carried in an IPv6 Destination
Option. This maximises backwards compatibility, and is consistent
with the clear intent of RFC-2460.
Existing deployed silicon (think Verilog & logic gates,
not NP or CPU) from multiple vendors know how to parse past
such an IPv6 Destination Options header in order to locate
the actual transport-layer protocol and transport-layer
port-numbers (e.g. to apply QoS or ACLs). This proposed new
IPv6 Extension Header will *break* this *deployed* capability.
I know that it is deployed today in multiple large multi-
continent ISPs to parse past an optional headers. There are
also site-border-router/firewall boxes that have this capability,
used to allow certain applications (based upon examining the
transport-layer protocol and transport-layer port numbers
that are located *after* the optional header) and/or
to permit authorised traffic even when an optional header
is present between the IPv6 header and the transport-layer
protocol.
I have a strong desire to avoid breaking this deployed and
important operational capability.
I also support these 2 specific comments from Joel Halpern,
particularly these 2 ideas:
I) removing "the hook for new extension headers that was left in RFC-2460"
(extension headers are only allowed in narrow circumstances at present)
&&
II) "to say that all end-to-end IP information" MUST "be in the
destination options".
His precise words that I agree with are:
> (If we want that prohibition to be the case, we should say so,
> and remove the hook for new extension headers that was left in 2460.)
and separately:
> My own preference would probably be to say that all end-to-end
> IP information should be in the destination options.
I believe there would be broad support within the IPv6 WG to have
a small clarification to RFC-2460 that required the use of
Destination Options in all cases where they can be made to work
(in essence, this is Joel's I and II above).
However, that could be done in a 1-page (plus boilerplate) draft.
Since Suresh has been driving this issue, perhaps Suresh could create
such a 1-page (plus boilerplate) draft for the IPv6 WG to review ? (:-)
Yours,
Ran
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
