Operational Implications of IPv6 Packets with Extension Headers
draft-ietf-v6ops-ipv6-ehs-packet-drops-08

Thanks for an easy read on an interesting topic.

I presume the sponsoring AD has affirmed that exceeding the recommended author limit is appropriate here.

** Section 1.
However, common implementation limitations suggest
   that EHs present a challenge for IPv6 packet routing equipment and
   middle-boxes, and evidence exists that IPv6 packets with EHs are
   intentionally dropped in the public Internet in some network
   deployments.

Can you clarify a “common implementation limitations” -- is that the same as saying vendors aren’t supporting EHs?

** Section 4.  Are there more updated references for the trends identified in[PMTUD-Blackholes], [Linkova-Gont-IEPG90] and [RFC7892] as the freshest of these is 6 year old data?

** Sections 6.1 and 6.2 don’t have clear text like Section 6.4 and 6.5 that explains how layer-4 inspections leads to dropped packets.

** Section 6.4
Use of extension headers can be problematic for NIDS/IPS, since:

   o  Extension headers increase the complexity of resulting traffic,
      and the associated work and system requirements to process it.

   o  Use of unknown extension headers can prevent an NIDS/IPS from
      processing layer-4 information.

   o  Use of IPv6 fragmentation requires a stateful fragment-reassembly
      operation, even for decoy traffic employing forged source
      addresses (see e.g., [nmap]).

-- Per (1), this seems analogous to the argumentation in Section 5 but in that section there were details around the limitation of hardware support.  Is there an analogous reference here?  That is, asserting that computation requirements to process EH is a significant additional load?

-- How is the core issue of (3) different than handling fragments in IPv4 (i.e., operators dropping them at the border and NIPS/NIDS also have to reassembly them to avoid evasion)?

** Section 6.5.  Thanks for including the reference to [Zack-FW-Benchmark].  Due to the age of the benchmark, another sentence explaining how 2013-era firewalls are still quite similar to those used now would be helpful

Thank you for the work put into this document. The authors know my deep interest in this kind of work on the IPv6 extensibility.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and one nit.

Special thanks to Loganaden Velvindron and Tim Winters for the IoT/INT directorates reviews:
https://datatracker.ietf.org/doc/review-ietf-v6ops-ipv6-ehs-packet-drops-06-iotdir-telechat-velvindron-2021-04-19/
https://datatracker.ietf.org/doc/review-ietf-v6ops-ipv6-ehs-packet-drops-06-intdir-telechat-winters-2021-04-20/

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Generic comment: does the word "carrier-grade router" represent the 'core' and/or 'edge' routers ?

-- Section 1 --
  "evidence exists that IPv6 packets with EHs are
   intentionally dropped in the public Internet in some network
   deployments."
The above strong assertion is really generic... Did the authors check about "intentionally" (by the network operator) ? I also fail to understand the mix of "public Internet", which is global, and "in some network deployments", which is quite specific. Should there be a comma ? Or is it about my generic question on whether it is edge / core ?

Also, a fresh reference to "evidence" would be welcome.

In the set of goal, is it on purpose that both bullets 1 and 3 are about "operational ... implications " and "operational issues" ? Should those bullet be merged ?

-- Section 4 --
It appears to me that "Some of the operational implications of IPv6 Extension Headers " is also about security implications.

Does RFC 7112 still apply for RFC 8200 ? As the first fragment MUST contain all header up-to and including the upper-layer one? (in this case the ICMPv6). So, this reference should perhaps be in the second list ?

-- Section 5 --
BTW, I think that NPU have no real problem to parse deep in the EH chain (except for some performance hit) as opposed to ASIC/TCAM/... Please also note that many high speed routers are now VMs with normal generic processors in a data center (of course not in the public Internet).

Please add a reference to the NOTE.

-- Section 5.1 --
Can you add a reference to routers doing recirculation ? Honestly, I have never heard of this for EH parsing. Now, let's hope that this is not my employer ;-)

-- Section 6 --
I like the term "intermediate system" to represent router and middle box. May I suggest to use this term from the beginning of the document through the end and introduce it in the terminology?

-- Section 6.2 --
Suggest to reword "Infrastructure ACLs (iACLs) drop unwanted packets destined to a network's infrastructure IP addresses" since the rest of the section is not limited to 'IP addresses'.

Should "management plane" be added to "against router control planes" ?

-- Sections 6.4 and 6.5 --
If NIDS/NIPS/firewalls are unable to understand EH chain, then they have no excuse and simply are buggy or unfit for their job. Is there a need to cite this kind of buggy devices in an IETF document ?

-- Section 7.2 --
Please add a reference to the statement "many operators currently drop IPv6 packets containing this extension header"

-- Section 7.3 --
Any reason why this section is only about "router" and not the usual "router and middle boxes" or even "intermediate systems".

-- Section 7.4 --
Please consider to promote sub-section 7.4 to its own section or at least add "security" to the section 7 title.

The text repeats some elements, which were previously discussed. Please consider trimming the text :-)

The penultieme paragraph appears to present some 2013 references as fairly recent. Please consider removing this part.

-- Section 10 --
The authors know me deep interest in getting fresh measurements, so, I am puzzled by 
  "thank Jan Zorz / Go6 Lab
   <https://go6lab.si/>, Jared Mauch, and Sander Steffann
   <https://steffann.nl/>, for providing access to systems and networks
   that were employed to perform experiments and measurements involving
   packets with IPv6 Extension Headers."
  
as there is no indication in this document whether those measurements are fresh and interesting when compared to RFC 7872 ? If so, is there a plan to make them public  

== NITS ==

-- Section 5 --
Please expand "NPU" and "CAM" at first use.

-- Section 6.1 --
"ECMP (equal cost multi path) load sharing", the usual way it to use "balancing" rather than sharing ? Also, please use the usual way "equal cost multi-path (ECMP)"

All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

These reference issues exist in the document:
 * Obsolete reference to RFC2460, obsoleted by RFC8200
 * Obsolete reference to RFC5575, obsoleted by RFC8955

These URLs in the document did not return content:
 * https://media.blackhat.com/bh-eu-12/Atlasis/bh-eu-12-Atlasis-Attacking_IPv6-Slides.pdf

Please address the tsvart review comments (thanks, Gorry)