On Wed, 17 Nov 2010 01:45:27 +0100, Hagen Paul Pfeifer <ha...@jauu.net> 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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------