In your previous mail you wrote: > => good summary: now you have to prove a new extension header is > reallynecessary! ==>There are many measurement methodologies, each has its own information carried on packets. So it is necessary to provide a infrastructure for these methodologies based on ipv6. Using this extended header, we can perform the measurement without modify the packet. So it is a good idea. => I don't understand at all why this argument doesn't apply to options!
==>Yes, if there are only measurement options in destination header, => usually there is no destination header (in fact no extension header at all) so this hypothesis is right (:-). it may same as extended header when processing it. But if there are lots kinds of options, each module should check every option to see whether it should process the option. => be serious please: in all the codes I've seen (including mine) the option processing is vectorized or in a C switch, i.e., the cost is an indirect or direct indexed branch. It may exhaust more time. => for next header it is always vectorized. I think that we have the same idea, but there are some little differences. => the main difference is we are only using options... Regards [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------