At Thu, 20 Mar 2008 11:14:19 -0400, "Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote: > I agree with you that a receiver may process the EH's in any order > except the HBH EH. Yes, my concern with text from Suresh's draft was > indeed that HBH was not mentioned with > > " o Extension headers must be processed in any order they appear" > > Also, the same bullet above does not mention the EH Order defined in > section 4.1 of RFC 2460. If the order is followed by a sender, a > receiving node will receive the EH's in order.
Of course, but the point is that the receiver cannot (or even must not) assume that ordering. This is a typical example of "Be liberal in what you accept(, and conservative in what you send)". BTW: > I understand receiver vs. sender. I am talking about the fact that RFC > 2460 says no intermediate node may inspect/process any EH besides the > HBH EH. That is the reason for which I quote this para from section 4 of > RFC 2460: I don't understand why you mentioned this in a response to my previous message; I didn't argue about this point. I specifically responded the quoted (below) part of your previous response to Suresh, where I don't see any relevance to the inspection by an intermediate node. --- JINMEI, Tatuya Internet Systems Consortium, Inc. =====================from here ======================================= Suresh, I thought my arguments were clear enough from my original email. But let me give it another shot. Please see in line below between <hs> and </hs> -----Original Message----- From: Suresh Krishnan [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 6:47 PM To: Hemant Singh (shemant) Cc: IETF IPv6 Mailing List Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt Hi Hemant, Thanks for your comments. Please see responses inline. Hemant Singh (shemant) wrote: [snip] > 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 <hs> Your example is not a good one for more reasons than one and the ordering is not fuzzy. First, RH0 has been deprecated. Secondly, RFC 3775, the RFC that defined the RH2 clearly says in section 6.4.1 as follows: [The ordering rules for extension headers in an IPv6 packet are described in Section 4.1 of RFC 2460 [11]. The type 2 routing header defined for Mobile IPv6 follows the same ordering as other routing headers. If both a type 0 and a type 2 routing header are present, the type 2 routing header should follow the other routing header. A packet containing such nested encapsulation should be created as if the inner (type 2) routing header was constructed first and then treated as an original packet by the outer (type 0) routing header construction process.] Further evidence for ordering not being fuzzy is shown in the following text from section 4.1 of RFC 2460. [When more than one extension header is used in the same packet, it is recommended that those headers appear in the following order: IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Fragment header Authentication header (note 2) Encapsulating Security Payload header (note 2) Destination Options header (note 3) upper-layer header] The same section goes on to say, [If and when other extension headers are defined, their ordering constraints relative to the above listed headers must be specified.] </hs> =======================to here ======================================= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
