Hi Suresh, > It is not clear to me what the problem is. Please state the > problem you > are trying to solve and why draft-ietf-6man-exthdr does not meet the > purpose. We can then work together to get the issue(s) fixed. > The draft > is in its current state because it solves the following problems > > *) Need for a standardized format for new extension headers (for > efficient parsing and for middlebox skipping) > *) Need to conserve protocol number space (1 allocation for all new > extension headers vs. 1 allocation per new extension header) > *) Need to differentiate new extension headers from new transport > protocols (non-GIEH next header value==>New transport protocol)
Ok, so this clears one doubt that I had which was that we would use GIEH for all new allocations (even new transport protocols). Patently, this is not the case and it will only be used for new v6 extension headers. This sounds good! My concern with the current format is that it does not help in incrementally introducing new v6 extension headers. I would like to add the following to the list of problems that GIEH currently solves: *) Some Hdr Options that indicates what a processing node MUST do when it does not recognize the extension header its trying to process (drop/pass/etc). We cannot necessarily assume that it will always be the end node that's trying to process an extension header. You could also have some intermediate node processing extension headers and what if it does not understand them? It (or the end node) could either ignore this (indicated in the Hdr Option) or it could raise hell and drop the packet (again indicated in the Hdr Options). Thanks, Manav > > Thanks > Suresh > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
