Hi, I have a concern about this document. In the definition of "IPv6 Header Chain", it says: "However, if a second IPv6 header appears in the header chain, as is the case when IPv6 is tunneled over IPv6, the second IPv6 header is considered to be an upper-layer header and terminates the header chain." This means that stateless firewalls are being directed to discontinue extension header parsing when a first encapsulated IPv6 header is encountered - even though there may be many more parsable (inner) headers that follow. As a result, the firewall would either have to drop or forward the packet without examining the true upper layer header. This may result in an incorrect perception that tunneled traffic is either less reliable or more dangerous than non-tunneled traffic. Here are my suggested changes to address this issue: 1) Section 3, under "IPv6 Header Chain", change: "However, if a second IPv6 header appears in the header chain, as is the case when IPv6 is tunneled over IPv6, the second IPv6 header is considered to be an upper-layer header and terminates the header chain." to: "However, if a second IPv6 header appears in the header chain, as is the case when IPv6 is tunneled over IPv6, the second IPv6 header is optionally considered to be either an upper-layer header that terminates the header chain or another extension header that continues the chain." 2) Section 3, under "Upper-layer Header", change: "In the general case, the upper-layer header is the first member of the header chain that is neither an IPv6 header nor an IPv6 extension header." to: "In the general case, the upper-layer header is the first member of the header chain that is not considered to be an extension header." 3) Section 3, under "Upper-layer Header", delete the following sentence: "However, if either an ESP header, or a second IPv6 header occur in the header chain, they are considered to be upper layer headers and they terminate the header chain." 4) Section 5, change the final paragraph to: "As a result of the above mentioned requirements, a packet's header chain length cannot exceed the Path MTU associated with its destination. Hosts MAY discover the Path MTU, using procedures such as those defined in [RFC1981] and [RFC4821]. However, if a host does not discover the Path MTU, it MUST limit the header chain length to 1024 bytes. Limiting the header chain length to 1024 bytes ensures that the header chain length does not exceed the IPv6 minimum MTU [RFC2460] even if additional encapsulation headers are inserted by tunnels on the path." Thanks - Fred Fred.l.templin@xxxxxxxxxx > -----Original Message----- > From: ipv6-bounces@xxxxxxxx [mailto:ipv6-bounces@xxxxxxxx] On Behalf Of > The IESG > Sent: Wednesday, October 02, 2013 11:55 AM > To: IETF-Announce > Cc: ipv6@xxxxxxxx > Subject: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> > (Implications of Oversized IPv6 Header Chains) to Proposed Standard > > > The IESG has received a request from the IPv6 Maintenance WG (6man) to > consider the following document: > - 'Implications of Oversized IPv6 Header Chains' > <draft-ietf-6man-oversized-header-chain-08.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2013-10-16. Exceptionally, comments may > be > sent to iesg@xxxxxxxx instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The IPv6 specification allows IPv6 header chains of an arbitrary > size. The specification also allows options which can in turn > extend > each of the headers. In those scenarios in which the IPv6 header > chain or options are unusually long and packets are fragmented, or > scenarios in which the fragment size is very small, the first > fragment of a packet may fail to include the entire IPv6 header > chain. This document discusses the interoperability and security > problems of such traffic, and updates RFC 2460 such that the first > fragment of a packet is required to contain the entire IPv6 header > chain. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header- > chain/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@xxxxxxxx > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------