One of the confusions here is that the same field (next header) is used
to identify extension headers and carried protocols. I am sure that
the authors are not demanding that we change the TCP, UDP, SCTP, DCCP,
or ICMP header formats. I presume that they are not asking that we
constrain the header format of new transport protocols.
As such, tunnel protocols are probably not a good example of the need
for extension headers. They behave as encapsulating headers, hence they
are really a carried protocol, not an extension of the IP header.
Also, I do not see why a new extension header would be noticeably more
efficient than adding an option in the proper option header (with the
option header having the advantage of being clear about who the
information is for.)
On a related note, RFC 2460 actually mandates that new extension headers
be created ONLY for headers which meet specific handling constraints.
Putting handling directives in the extension header means that we are
explicit reversing a statement in RFC 2460.
Yours,
Joel M. Halpern
On 11/17/2010 3:52 AM, Hagen Paul Pfeifer wrote:
On Tue, 16 Nov 2010 20:58:39 -0500, Steven Blake wrote:
This does not address Ran's comment: why would we ever need a new
extension header? Why aren't the Hop-by-Hop Options and Destination
Options extension headers sufficient? Neither of the drafts above
motivate
this need.
Tunnel specific extension header, efficient low overhead extension header,
... whatever.
The current extension header mechanism isn't practical, but why should we
wipe out these extension header at all? Introduce GIEH as a generic
container and everything is fine.
Hagen
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
