Hi, I would like to make a small amendment to what I said in my previous message as follows:
4) Section 5, change the final paragraph to: "As a result of the above mentioned requirements, a packet's header chain length MUST fit within 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 assume the IPv6 minumum MTU of 1280 bytes [RFC2460]. The host MUST then limit each packet's header chain length to the Path MTU minus 256 bytes in case additional encapsulation headers are inserted by tunnels on the path." Thanks - Fred fred.l.temp...@boeing.com > -----Original Message----- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of > Templin, Fred L > Sent: Friday, October 04, 2013 1:42 PM > To: i...@ietf.org; IETF-Announce > Cc: ipv6@ietf.org > Subject: RE: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> > (Implications of Oversized IPv6 Header Chains) to Proposed Standard > > 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.temp...@boeing.com > > > > > > -----Original Message----- > > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf > Of > > The IESG > > Sent: Wednesday, October 02, 2013 11:55 AM > > To: IETF-Announce > > Cc: ipv6@ietf.org > > 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 > > i...@ietf.org mailing lists by 2013-10-16. Exceptionally, comments > may > > be > > sent to i...@ietf.org 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@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
