On Wed, 17 Nov 2010 01:45:27 +0100, Hagen Paul Pfeifer <[email protected]>
wrote:
> * Hing-Kam (Kam) Lam | 2010-11-17 05:23:47 [+0530]:
>
>>The draft does not do that. I dont know which version you have been
>>reading. You should read draft-ietf-6man-exthdr and
>>draft-bhatia-6man-update-ipv6-ext-hdr to get an idea of the problem
>>that this draft is attempting to solve.
>
> Hing is absolute correct - this mechanism is necessary, there are no
> valuable
> alternatives.
>
> Or to quote the Linux Kernel:
>
> int ipv6_ext_hdr(u8 nexthdr)
> {
> /*
> * find out if nexthdr is an extension header or a protocol
> */
> return (nexthdr == NEXTHDR_HOP) ||
> (nexthdr == NEXTHDR_ROUTING) ||
> (nexthdr == NEXTHDR_FRAGMENT) ||
> (nexthdr == NEXTHDR_AUTH) ||
> (nexthdr == NEXTHDR_NONE) ||
> (nexthdr == NEXTHDR_DEST);
> }
>
>
> If the extension header is no well known extension header (see the code)
> the
> network stack must stop processing of the packet! The kernel will drop
the
> packet. Why? Because Transport Protocols on top of IPv6 does not underly
a
> TLV
> coding. If the Kernel does not know the extension header type (e.g.
> NEXTHDR_FRAGMENT) what should he do? The kernel does not know if it is a
> unknown extension header or a unknown transport protocol. And because a
> transport protocol has no TLV coding he cannot skip over a transport
> protocol.
> Think about it, it may take some time but the current mechanism was the
> only
> workable way. The alternative would be to re-define all existing
Transport
> protocols (TCP2, UDP2), this time with a identical TLV encoding.
>
> Another solution where to introduce a white list for transport protocol
> types
> (TCP, UDP, ...) - but this time you would restrict the development of
new
> transport protocols. If the kernel does not know the protocol type he
must
> skip
> this packet. Same problem but this time even worse, because you limit
the
> transport protocol development.
>
> The situation now is that the Kernel must know all Extension Header
Types,
> a
> unknown Extension header will stop the processing chain.
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.
Regards,
// Steve
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
