Implications of Oversized IPv6 Header Chains
draft-ietf-6man-oversized-header-chain-09

[Ballot comment]
I trust the responsible AD to handle my DISCUSS

1.
Please engage in the discussion for this one if you disagree.
Abstract

  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.

I was confused by or in "IPv6 header chain or options".
The options are the hop-by-hop and destination header options, right?
So these are part of the Extension Header, so the IPv6 Header Chain already, no?
Proposal:
OLD:
        IPv6 header chain or options
NEW:
      IPv6 header chain (including options)

Same remark for

  This document updates the set of IPv6
  specifications to create an overall limit on the size of the
  combination of IPv6 options and IPv6 Extension Headers that is
  allowed in a single IPv6 packet.


2.
OLD:

  This specification allows nodes that drop the aforementioned packets
  to signal such packet drops with ICMPv6 "Parameter Problem, IPv6
  first-fragment has incomplete IPv6 header chain" (Type 4, Code TBD)
  error messages.

NEW:
  This specification allows nodes or intermediate systems that drop the aforementioned packets
  to signal such packet drops with ICMPv6 "Parameter Problem, IPv6
  first-fragment has incomplete IPv6 header chain" (Type 4, Code TBD)
  error messages.



3.
In section 4, it would nice to add: "not an issue for statefull middleboxes"
For this comment, take it or leave it

[Ballot comment]
This is non-blocking ...

How often does this happen?  I'm asking because I'm curious if there's now going to be huge surge in ICMP error messages indicating discards.

Also, I guess I'd reword this:

Whether a host or intermediate system originates this ICMP
  message, its format is identical.

to

The format for the ICMP message is the same regardles of whether a host or intermediate system originates it.

[Ballot comment]
Whilst I think this is a useful document, I found the security section a little strange. The authors make it clear that they reduce the security risk of the existing protocol. However normally a security section discusses any additional risk of deploying the technology compared to the base protocol, and it is not clear to me as a reader whether or not the author examined this aspect to the problem.

[Ballot discuss]
DISCUSS:

RFC 1981:
  IPv6 nodes SHOULD implement Path MTU Discovery in order to discover
  and take advantage of paths with PMTU greater than the IPv6 minimum
  link MTU [IPv6-SPEC].

draft-ietf-6man-oversized-header-chain:

  Hosts MAY discover the Path MTU, using procedures such
  as those defined in [RFC1981] and [RFC4821].

So bug, or is the intend for this document to update RFC 1981?

[Ballot comment]
1.
Please engage in the discussion for this one if you disagree.
Abstract

  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.

I was confused by or in "IPv6 header chain or options".
The options are the hop-by-hop and destination header options, right?
So these are part of the Extension Header, so the IPv6 Header Chain already, no?
Proposal:
OLD:
        IPv6 header chain or options
NEW:
      IPv6 header chain (including options)

Same remark for

  This document updates the set of IPv6
  specifications to create an overall limit on the size of the
  combination of IPv6 options and IPv6 Extension Headers that is
  allowed in a single IPv6 packet.


2.
OLD:

  This specification allows nodes that drop the aforementioned packets
  to signal such packet drops with ICMPv6 "Parameter Problem, IPv6
  first-fragment has incomplete IPv6 header chain" (Type 4, Code TBD)
  error messages.

NEW:
  This specification allows nodes or intermediate systems that drop the aforementioned packets
  to signal such packet drops with ICMPv6 "Parameter Problem, IPv6
  first-fragment has incomplete IPv6 header chain" (Type 4, Code TBD)
  error messages.



3.
In section 4, it would nice to add: "not an issue for statefull middleboxes"
For this comment, take it or leave it

[Ballot comment]
observation that whatever tool generated this went over the top on page breaks to the point where it would be unreadable as formatted were it broken across pages.

[Ballot comment]
It's probably a good idea to put in an RFC Editor note that asks the RFC Editor to replace "TBD" in Sections 5, 6, and 7 with the value assigned by IANA, to mae sure they get all three occurrences.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-6man-oversized-header-chain-08.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Type 4 - Parameter Problem subregistry of the ICMPv6 "Code" Fields registry in the Internet Control Message Protocol version 6 (ICMPv6) Parameters page at

http://www.iana.org/assignments/icmpv6-parameters/

a single new entry will be added as follows:

Code: [ TBD-at-registration ]
Name: IPv6 first-fragment has incomplete IPv6 header chain

IANA understands that this is the only action required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (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'
  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.

All,
    I have completed my AD evaluation for draft-ietf-6man-oversized-header-chain.  I found the document to be concise and well-written.  Thank you.

    I only have a few things I would like to see addressed prior to starting an IETF Last Call on this document.

1. The 2nd paragraph of Section 4 (Motivation) could be made more clear.  For example, you could indicate if the example first fragment does or does not match the stateless firewall rule.  It is inferred that the first fragment does not match the target TCP port since it was dropped, but I like to err on the explicit side.  As an aside, wouldn't the subsequent fragments be dropped as well or does the IP destination match the forward rule?

2. I would like to get some clarification on the rule in section 5 that says "A host that receives a first-fragment that does not satisfy the above-stated requirement SHOULD discard that packet".  Can you provide some justification for the SHOULD when you made it a MUST for a sending node to ensure the upper-layer header is in the first fragment?  Are you assuming some flexibility to support compatibility with older stacks?  If so, it would be good to have some guidance on what those stack vendors should do.

3. Why is sending an ICMP error message a MAY?

4. It would be better to be explicit that a host sending an ICMP error message is sending the same ICMP error specified for routers/middleboxes.

5. I would suggest adding a reference to 2460 for the 1280 minimum MTU value.

Regards,
Brian