Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World
RFC 7872

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

(Joel Jaeggli) Yes

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Comment (2016-03-15)
No email
send info
While reading the document, I was wondering under which circumstances dropping IPv6 Extension Headers is the right behavior?
Or, if dropping IPv6 Extension Headers is always just wrong?
The only related sentences I found are:

   The
   aforementioned results serve as a problem statement that is expected
   to trigger operational advice on the filtering of IPv6 packets
   carrying IPv6 Extension Headers, so that the situation improves over
   time. 

   ...

   In any case, we note that it is
   impossible to tell whether, in those cases where IPv6 packets with
   extension headers get dropped, the packet drops are the result of an
   explicit and intended policy, or the result of improper device
   configuration defaults, buggy devices, etc. 


What does it mean "so that the situation improves overtime"?
A disclaimer that this study is formulated in a neutral way, as a precursor document for some further advice + a pointer to https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-00 would be a plus IMO.

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2016-03-14)
No email
send info
- The tables in section 2 would be more useful if they said how
many addresses correspond to each row after filtering the 1M.

-  Appendix A: The URL [1] results in a 404 for me after a
re-direct to port 443. I like the 301, but not the 404:-)

   [1] http://www.si6networks.com/datasets/wipv6day-domains.txt

(Martin Stiemerling) No Objection

(Alia Atlas) Abstain

Comment (2016-03-17)
No email
send info
I also agree with Alvaro.

(Brian Haberman) Abstain

Comment (2016-03-16)
No email
send info
I agree with Alvaro that this document is valuable as far as providing data that serves as input to other work, but does not by itself warrant publication as an RFC.

Barry Leiba Abstain

Comment (2016-03-16)
No email
send info
I'm going with Álvaro here: it would be better to merge this into whatever other document the working group is considering, and to have this as a draft or in the working group wiki in the meantime.

Alvaro Retana Abstain

Comment (2016-03-15)
No email
send info
This document provides two pieces of valuable information: the confirmation that IPv6 packets with extension headers are dropped in the Internet, and the description of the methodology used to collect the data.  However, I don't think that either of these have RFC-archival value without offering guidance on what could be done about it, or even raising awareness to operational issues (beyond the obvious drops).  

[The Shepherd write up mentions that "the WG is considering another document" which may make recommendations.  It might have been better to wait and package both together.]

I won't stand in the way of publication, so I'm ABSTAINing.