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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
