Suresh, First, one simple comment.
1. In section 1 of your draft you say [may need to look at the transport layer header fields...] Change "transport layer header" to "upper layer header" because (a) You must use language consistent with RFC 2460. (b) Use of transport layer is incorrect because ICMP is a layer 3 protocol that is also upper layer for IPv6 Extended Header (EH) while the transport layer is layer 4. On to more critical issues. 2. I and Wes don't agree at all with bullet 2 in section 4 (Future work) of this draft that says: [Extension headers must be processed in any order they appear] Hop-by-hop option is processed by every intermediate router and such router's fast path silicon is usually a hardware engine that parses the first x bytes of the Extended header (EH) where x can be say, 64 bytes. I suspect that was the design theme when folks wrote RFC 2460 and made sure hop-by-hop was always the first EH. Also, as reviewers of your draft we still keep in mind that hop-by-hop hasn't been deprecated. Further, section 4.1 of RFC 2460 also defines a specific sequence of EH's. We want your draft to still comply to RFC 2460 in this regard - comply with section 4.1 of RFC 2460 and preserve this section's EH Order. Further this section from RFC 2460 says: [If and when other extension headers are defined, their ordering constraints relative to the above listed headers must be specified]. This constraint cannot be dispensed with without very careful thought. 3. RFC 2460 clearly says in section 4 that EH's are not processed by intermediate nodes unless the EH is a hop-by-hop EH. Since your draft ignores this rule of RFC 2460, it's up to the IPv6 community to first agree to such a change to RFC 2460 before looking at your draft. Hemant & Wes -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
