ietf
[Top] [All Lists]

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

2013-10-07 13:14:42
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(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com

-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Templin, Fred L
Sent: Friday, October 04, 2013 1:42 PM
To: ietf(_at_)ietf(_dot_)org; IETF-Announce
Cc: ipv6(_at_)ietf(_dot_)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(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com




-----Original Message-----
From: ipv6-bounces(_at_)ietf(_dot_)org 
[mailto:ipv6-bounces(_at_)ietf(_dot_)org] On Behalf
Of
The IESG
Sent: Wednesday, October 02, 2013 11:55 AM
To: IETF-Announce
Cc: ipv6(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org mailing lists by 2013-10-16. Exceptionally, 
comments
may
be
sent to iesg(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>