Tatuya, 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:
[With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.] This text would prohibit a firewall, which is an intermediate node, to inspect/process any EH. I also asked if any RFC exists that changed this behavior from RFC 2460 to allow an intermediate node like a firewall to inspect/process EH's besides the HBH. 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. Thanks. Hemant -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 2:14 PM To: Hemant Singh (shemant) Cc: Suresh Krishnan; IETF IPv6 Mailing List Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt At Wed, 19 Mar 2008 10:34:37 -0400, "Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote: > > 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] [snip] > 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.] This part of RFC2460 talks about the sender side; I'm afraid you're referring to the wrong part of RFC2460. In my understanding, we are talking about the receiver side (whether it's a final e2e destination, or a router that has to see some portion of the packet, or an intermediate node that processes a routing header, or even an evil, layer-violating filtering/inspection device), and RFC2460 is pretty generous on this point: IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header which is restricted to appear immediately after an IPv6 header only. BTW, if your concern is specifically the position of a hop-by-hop header, yes, the RFC states very clearly that it (when it appears) must appear immediately after the IPv6 header. But I didn't think the following bullet of draft-krishnan-ipv6-exthdr-01 o Extension headers must be processed in any order they appear intended to amend the restriction. My interpretation was it meant headers except the hop-by-hop options header. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
