On 17 Nov 2010, at 11:39 , Suresh Krishnan wrote:
> If your objection is "We should not be defining any new extension headers",
(That is not a precise statement of the concern,
although that is certainly part of the concern. :-)
> I completely agree with you. But, I guess the sentiment
> has not gone around the IETF.
> The following IPv6 extension headers have been defined since RFC2460
>
> 135 - Mobility header
> 139 - HIP
> 140 - Shim6
> 141 - WESP
Thanks for giving specific examples. :-)
I suspect that mostly shows the challenges of coordination among
various IETF WGs, with different charters, living in various
IETF Areas, each undertaking its own work.
I'm not sure that any IPv6/6MAN WG document will be a 100% solution,
but I do not object to having a document of some kind that clarifies
the undesirability of more extension headers and re-emphasises the
exiting statements from RFC-2460 (possibly making those statements
even stronger).
> Right now the fact remains that the IPv6 spec allows
> for using a separate header as an option.
...but not where a separate end-to-end header is actually
useful in a general way...like being received and used
by the receiving end system.
> " If the desired action is for the destination node to discard
> the packet and, only if the packet's Destination Address is not
> a multicast address, send an ICMP Unrecognized Type message to
> the packet's Source Address, then the information may be
> encoded either as a separate header or as an option in the
> Destination Options header whose Option Type has the value 11
> in its highest-order two bits. The choice may depend on such
> factors as which takes fewer octets, or which yields better
> alignment or more efficient parsing."
Thanks for quoting that.
To paraphrase:
A separate header can be used "if and only if"
... "the desired action is" ... "to discard the packet".
That narrow exception from the general prohibition applies only
to extension headers that are not generally useful, since they
can only trigger an error response.
The bit you didn't quote already says that all other uses
(i.e. something generally useful & with an end-to-end nature)
needs to be done with the IPv6 Destination Options Header,
rather than creating a new extension header with the end-to-end
nature.
Now, there is some evidence that this aspect of RFC-2460
hasn't been fully understood by everyone in the past,
as you pointed out up top.
A clarifying statement might help and can't hurt,
provided it is worded carefully.
> I would be just as happy if such a statement was made
> and could gather consensus in the 6man wg.
That is probably simpler and easier.
Another alternative would be to retain your draft,
but edit it along the lines I suggested earlier,
whereby explicit language prohibiting creation of new
extension headers that have either (a) hop-by-hop
or (b) end-to-end nature is added in.
I really appreciate your open-mindedness on this.
Cheers,
Ran
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
