RE: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard

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.templin@boeing.com

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
> Templin, Fred L
> Sent: Friday, October 04, 2013 1:42 PM
> To: ietf@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.templin@boeing.com
> 
> 
> 
> 
> > -----Original Message-----
> > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@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
> > ietf@ietf.org mailing lists by 2013-10-16. Exceptionally, comments
> may
> > be
> > sent to iesg@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
> > --------------------------------------------------------------------