Skip to main content

Operational Implications of IPv6 Packets with Extension Headers
RFC 9098


Robert Wilton

No Objection

(Alvaro Retana)


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

Erik Kline
Comment (2021-04-20 for -06) Sent
[[ comments ]]

[ section 7.1 ]

* It seems to me that this also applies to IP fragments of any family,
  particularly if the first fragment is delayed or lost.

  I can't tell from the text whether handling fragments (even in IPv4)
  is considered "process[ing] the packet outside the normal forwarding path"
  or not.

[[ nits ]]

[ section 3 ]

* s/IPv6 IPv6/IPv6/?

[ section 6.1 ]

* "the router on the sending side of the link needs to..."?

  This phrasing seems a little odd to me.  How about just
  "the (or a) forwarding router needs to...", since the rest of the sentence
  does make the described situation clear?
Robert Wilton
Lars Eggert
No Objection
Comment (2021-04-14 for -06) Sent
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:
Martin Duke
No Objection
Comment (2021-04-21 for -06) Sent
Please address the tsvart review comments (thanks, Gorry)
Murray Kucherawy
No Objection
Comment (2021-04-22 for -06) Sent
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.
Roman Danyliw
No Objection
Comment (2021-04-21 for -06) Sent
** 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

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
Éric Vyncke
No Objection
Comment (2021-04-20 for -06) Sent
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:

I hope that this helps to improve the document,




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
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
   <>, Jared Mauch, and Sander Steffann
   <>, 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)"
Warren Kumari
Comment (2021-04-20 for -06) Not sent
Phew, one less document to review :-P
Alvaro Retana Former IESG member
No Objection
No Objection (for -06) Not sent