Skip to main content

Implications of Oversized IPv6 Header Chains
RFC 7112

Yes

(Adrian Farrel)
(Brian Haberman)
(Ted Lemon)

No Objection

(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)
(Stephen Farrell)

Note: This ballot was opened for revision 08 and is now closed.

(Adrian Farrel; former steering group member) Yes

Yes (for -08)

                            

(Brian Haberman; former steering group member) Yes

Yes (for -08)

                            

(Joel Jaeggli; former steering group member) Yes

Yes (2013-11-17 for -08)
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.

(Ted Lemon; former steering group member) Yes

Yes (for -08)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2013-11-15 for -08)
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.

(Benoît Claise; former steering group member) (was Discuss) No Objection

No Objection (2013-11-21 for -08)
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

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (for -08)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -08)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -08)

                            

(Richard Barnes; former steering group member) No Objection

No Objection (for -08)

                            

(Sean Turner; former steering group member) No Objection

No Objection (2013-11-20 for -08)
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.

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -08)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (for -08)

                            

(Stewart Bryant; former steering group member) No Objection

No Objection (2013-11-18 for -08)
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.