Hi Hemant, Thanks for your comments. Please see responses inline. Hemant Singh (shemant) wrote: > 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.
Will do. > > 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. I agree with you in spirit, but the requirement for ordering is very fuzzy. For example If there is a routing header of type 0 and a routing header of type 2 what is the order in which they should appear. I think the text should read "Extension headers must be processed in the order they appear" This is, I think, a valid paraphrase of the text "Therefore, extension headers must be processed strictly in the order they appear in the packet" that appears in RFC2460. > > 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. I am not sure I understand what you mean. The draft does not recommend anybody to look at the EHs other than the HBH. The draft says that, if someone does (e.g. firewalls and other middleboxes) it makes sense to have a standard header format. Not that I condone it, but this paradigm (of routers being L3 only devices) has been broken long time ago. Every router I know of has the capability to look at and filter at least on the transport layer port. Thanks Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
