RFC 7872

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

Okay bestie, here's the whole vibe of this one 🫖✨

• Number and title: RFC 7872, Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World
• Authors: F. Gont (SI6 Networks / UTN-FRH), J. Linkova (Google), T. Chown (Jisc), and W. Liu (Huawei Technologies) 🫶
• Category: Informational, so it's data and observations, not a Standards Track spec 🦋
• Date: June 2016 🌸
• ISSN: 2070-1721
• Obsoletes / Updates: it doesn't obsolete or update any other RFC, so it's totally its own thing 💜

---

Abstract 🎀

So this doc is giving real-world receipts 🧾 about how often packets with IPv6 Extension Headers (EHs) get dropped on the Internet. The measurements were done in August 2014 and then again in June 2015, and the results matched 🔁. It also shows where in the network the drops happen 👀. These results are basically a problem statement, the kind that's expected to kick off operational advice on how to filter IPv6 packets carrying IPv6 EHs, so things get better over time 📈. The doc also explains how the experiment was run, so other folks in the community can reproduce it and keep checking how packets with IPv6 EHs are handled as time goes on 🔍✨

---

Status of This Memo 🌈

This is not an Internet Standards Track spec. It's published for informational purposes, no pressure 🫧

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🤝. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🎉. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for the details 📚

For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc7872 🔗

---

Copyright Notice 💜

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved ©️

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this doc 📜👀. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🧡

---

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Support of IPv6 Extension Headers in the Internet . . . . . .   3
3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
    4.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
    4.2.  Informative References  . . . . . . . . . . . . . . . . .   6
Appendix A.  Reproducing Our Experiment . . . . . . . . . . . . .   8
    A.1.  Obtaining the List of Domain Names  . . . . . . . . . . .   8
    A.2.  Obtaining AAAA Resource Records . . . . . . . . . . . . .   8
    A.3.  Filtering the IPv6 Address Datasets . . . . . . . . . . .   9
    A.4.  Performing Measurements with Each IPv6 Address Dataset  .   9
    A.5.  Obtaining Statistics from Our Measurements  . . . . . . .  10
Appendix B.  Measurements Caveats . . . . . . . . . . . . . . . .  12
    B.1.  Isolating the Dropping Node . . . . . . . . . . . . . . .  12
    B.2.  Obtaining the Responsible Organization for the Packet
          Drops . . . . . . . . . . . . . . . . . . . . . . . . . .  13
Appendix C.  Troubleshooting Packet Drops Due to IPv6 Extension
             Headers  . . . . . . . . . . . . . . . . . . . . . . .  14
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

---

1. Introduction 💖

Okay so IPv6 Extension Headers (EHs) let the IPv6 protocol grow, and they're what carries core stuff like IPv6 fragmentation 🧩. People have long suspected that packets using IPv6 EHs get dropped in some IPv6 deployments, but there wasn't much concrete data on it 🫣. A few preliminary measurements showed up in [PMTUD-Blackholes], [Gont-IEPG88], and [Gont-Chown-IEPG89], and [Linkova-Gont-IEPG90] has the more comprehensive results that this doc is built on 🔥

This doc presents real-world data on how often packets containing IPv6 EHs get dropped on the Internet. The measurements were run in August 2014 and again in June 2015 with similar results, and they're still waiting on operational advice in this area 🙈. In the scenarios where the measurements happened, using IPv6 EHs can lead to packet drops 💀. The big thing to note is that drops happening at transit networks are undesirable, and everyone hopes and expects this will get better over time 🌈✨

2. Support of IPv6 Extension Headers in the Internet 🌐✨

okay so bestie, this section is where the researchers get their hands dirty and actually go poke the public IPv6 servers to see which ones drop packets carrying IPv6 extension headers (EHs) 👀💅. they measured the path toward three kinds of servers: web servers, mail servers, and name servers 🎀. the domain lists came from the "World IPv6 Launch" site <http://www.worldipv6launch.org> and Alexa's Top 1-Million Web Sites <http://www.alexa.com> 🍓.

for each list of domain names, they grabbed three datasets:

• Web servers (AAAA records of the aforementioned list) 🌸
• Mail servers (MX -> AAAA records of the aforementioned list) 💌
• Name servers (NS -> AAAA records of the aforementioned list) 🧚

before getting the results, they removed duplicate addresses and any IPv6 addresses that weren't global unicast addresses 🧹. addresses that were unreachable got tossed too (see Appendix B for the tea ☕).

for each address set, they sent three different types of probes 🦋:

• IPv6 packets with a Destination Options header of 8 bytes;
• IPv6 packets resulting in two IPv6 fragments of 512 bytes each (approximately); and
• IPv6 packets with a Hop-by-Hop Options header of 8 bytes.

for the Destination Options and Hop-by-Hop Options probes, the desired EH size was reached with PadN options [RFC2460] ✨. the upper-layer protocol was always TCP [RFC793] 💖, with the Destination Port set to the service port [IANA-PORT-NUMBERS] of the dataset. so for example, all the web server measurements were TCP segments with the Destination Port set to 80 🌈.

now the spicy part 🔥. they wanted to know whether the Autonomous System (AS) dropping the packets was the same as the AS of the destination address. this matters because it basically reveals whether the drops are under the control of the intended destination 👑. drops by the destination AS are less of a concern, because the device doing the dropping belongs to the same organization the packets were headed to, so it's probably easier to update the filtering policy if needed 🙈. drops by transit ASes are more of a concern, though, since they hurt the deployability and usability of IPv6 EHs (including IPv6 fragmentation) for a third party, the destination AS 😭.

ngl, it's impossible to tell whether a drop of an IPv6 packet with EHs is the result of an explicit, intended policy or just improper device configuration defaults, buggy devices, etc. 💀 so drops at the destination AS might still be problematic too!

because there's some ambiguity about which AS a specific router belongs to (see Appendix B.2) 🧐, every measurement gives two values: a "best-case scenario" and a "worst-case scenario" 💜. in the best case, when in doubt, the drop is assumed to happen at the destination AS. in the worst case, when in doubt, it's assumed to happen at a transit AS (see Appendix B.2 for details) 🫶. in the tables below, the values in parentheses show the chance that, when a packet gets dropped, the drop happened in an AS other than the destination AS (covering both best and worst case) ✨.

+----------+------------------+------------------+------------------+

+----------+------------------+------------------+------------------+

+----------+------------------+------------------+------------------+

+----------+------------------+------------------+------------------+

+----------+------------------+------------------+------------------+

Table 1: WIPv6LD Dataset: Packet Drop Rate for Different Destination Types, and Estimated (Best-Case / Worst-Case) Percentage of Packets That Were Dropped in a Different AS

NOTE: In the tables above and below, "HBH8" stands for "packets with a Hop-By-Hop Options extension header of 8 bytes", "DO8" stands for "packets with a Destination Options extension header of 8 bytes", and "FH512" stands for "IPv6 packets with a Fragment Header of 512 bytes".

NOTE: As an example, we note that the cell describing the support of IPv6 packets with DO8 for web servers (containing the value "11.88% (17.60%/20.80%)") should be read as: "when sending IPv6 packets with DO8 to public web servers, 11.88% of such packets get dropped. Among those packets that get dropped, 17.60%/20.80% (best case / worst case) of them get dropped at an AS other than the destination AS".

+----------+------------------+------------------+------------------+

+----------+------------------+------------------+------------------+

+----------+------------------+------------------+------------------+

+----------+------------------+------------------+------------------+

+----------+------------------+------------------+------------------+

Table 2: Alexa's Top 1M Sites Dataset: Packet Drop Rate for Different Destination Types, and Estimated (Best-Case / Worst-Case) Percentage of Packets That Were Dropped in a Different AS

There are a number of observations to be made based on the results presented above. Firstly, while it has been generally assumed that it is IPv6 fragments that are dropped by operators, our results indicate that it is IPv6 EHs in general that result in packet drops. Secondly, our results indicate that a significant percentage of such packet drops occurs in transit ASes; that is, the packet drops are not under the control of the same organization as the final destination.

3. Security Considerations 🔐😱

okay this one's short but it's SO important bestie 💅. this document presents real-world data about how much IPv6 packets with EHs get dropped on the internet 🌍. because it's just presenting measurements, this document does not introduce any new security issues ✨🫶.

4. References 📚

4.1. Normative References 💖

[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.

4.2. Informative References 🧚

[Gont-Chown-IEPG89] Gont, F. and T. Chown, "A Small Update on the Use of IPv6 Extension Headers", IEPG meeting before IETF 89, March 2014, <http://www.iepg.org/2014-03-02-ietf89/ fgont-iepg-ietf89-eh-update.pdf>.

[Gont-IEPG88] Gont, F., "Fragmentation and Extension Header Support in the IPv6 Internet", IEPG meeting before IETF 88, November 2013, <http://www.iepg.org/2013-11-ietf88/ fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>.

[IANA-PORT-NUMBERS] IANA, "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/ service-names-port-numbers>.

[IPv6-Toolkit] SI6 Networks, "SI6 Networks' IPv6 Toolkit v2.0 (Guille)", <http://www.si6networks.com/tools/ipv6toolkit>.

[Linkova-Gont-IEPG90] Linkova, J. and F. Gont, "IPv6 Extension Headers in the Real World v2.0", IEPG Meeting before IETF 90, July 2014, <http://www.iepg.org/2014-07-20-ietf90/ iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0.pdf>.

[PMTUD-Blackholes] De Boer, M. and J. Bosma, "Discovering Path MTU black holes on the Internet using RIPE Atlas", July 2012, <http://www.nlnetlabs.nl/downloads/publications/ pmtu-black-holes-msc-thesis.pdf>.

Appendix A. Reproducing Our Experiment 🧪🎀

this section walks through, step by step, how to reproduce the experiment that produced the results in this document 🐣. each subsection is one step in the experiment 🪄. the tools are traditional UNIX-like tools (like gunzip) and the SI6 Networks' IPv6 Toolkit v2.0 (Guille) [IPv6-Toolkit] 🛠️.

throughout this appendix, "#" marks a command-line prompt for commands that need superuser privileges, while "$" marks the prompt for commands that don't 💻.

A.1. Obtaining the List of Domain Names 📝

the primary data source was Alexa's Top 1M web sites, available at: <http://s3.amazonaws.com/alexa-static/top-1m.csv.zip> 🌍. the file is a zipped file containing the list of the most popular web sites, in Comma-Separated Value (CSV) format. you can extract it with:

$ gunzip < top-1m.csv.zip > top-1m.csv

a list of domain names (i.e., with other data stripped) can be obtained with the following command [IPv6-Toolkit]:

$ cat top-1m.csv | script6 get-alexa-domains > top-1m.txt

this command creates a "top-1m.txt" file with one domain name per line 💖.

NOTE: The domain names corresponding to the WIPv6LD dataset is available at <http://www.si6networks.com/datasets/wipv6day-domains.txt>. Since the corresponding file is a text file containing one domain name per line, the steps produced in this subsection need not be performed. The WIPv6LD dataset should be processed in the same way as the Alexa dataset, starting from Appendix A.2. 🫶

A.2. Obtaining AAAA Resource Records 🦋

the file from the previous subsection has a list of domain names that correspond to web sites. the AAAA records for those domain names can be obtained with:

$ cat top-1m.txt | script6 get-aaaa > top-1m-web-aaaa.txt

the AAAA records for the mail servers of each of those domain names can be obtained with:

$ cat top-1m.txt | script6 get-mx | script6 get-aaaa >
top-1m-mail-aaaa.txt

the AAAA records for the name servers of each of those domain names can be obtained with:

$ cat top-1m.txt | script6 get-ns | script6 get-aaaa >
top-1m-dns-aaaa.txt

A.3. Filtering the IPv6 Address Datasets 🧹

okay so, the IPv6 address lists from the last step can have some messy stuff in them 😭 like non-global unicast addresses that don't belong, and duplicates. so we gotta clean up BOTH the undesired addresses AND the duplicates. each of the three files from the previous section should be filtered accordingly, bestie 💅

$ cat top-1m-web-aaaa.txt | addr6 -i -q -B multicast -B unspec -k
global > top-1m-web-aaaa-unique.txt

$ cat top-1m-mail-aaaa.txt | addr6 -i -q -B multicast -B unspec -k
global > top-1m-mail-aaaa-unique.txt

$ cat top-1m-dns-aaaa.txt | addr6 -i -q -B multicast -B unspec -k
global > top-1m-dns-aaaa-unique.txt

A.4. Performing Measurements with Each IPv6 Address Dataset 🔬

A.4.1. Measurements with Web Servers 🌐

okay so to measure DO8 with the list of web servers:

# cat top-1m-web-aaaa-unique.txt | script6 trace6 do8 tcp 80 >
top-1m-web-aaaa-do8-m.txt

and to measure HBH8 with the list of web servers:

# cat top-1m-web-aaaa-unique.txt | script6 trace6 hbh8 tcp 80 >
top-1m-web-aaaa-hbh8-m.txt

and last but not least, FH512 with the list of web servers:

# cat top-1m-web-aaaa-unique.txt | script6 trace6 fh512 tcp 80 >
top-1m-web-aaaa-fh512-m.txt

A.4.2. Measurements with Mail Servers 📬

to measure DO8 with the list of mail servers:

# cat top-1m-mail-aaaa-unique.txt | script6 trace6 do8 tcp 25 >
top-1m-mail-aaaa-do8-m.txt

to measure HBH8 with the list of mail servers:

# cat top-1m-mail-aaaa-unique.txt | script6 trace6 hbh8 tcp 25 >
top-1m-mail-aaaa-hbh8-m.txt

to measure FH512 with the list of mail servers:

# cat top-1m-mail-aaaa-unique.txt | script6 trace6 fh512 tcp 25 >
top-1m-mail-aaaa-fh512-m.txt

A.4.3. Measurements with Name Servers 🧚

to measure DO8 with the list of name servers:

# cat top-1m-dns-aaaa-unique.txt | script6 trace6 do8 tcp 53 >
top-1m-dns-aaaa-do8-m.txt

to measure HBH8 with the list of name servers:

# cat top-1m-dns-aaaa-unique.txt | script6 trace6 hbh8 tcp 53 >
top-1m-dns-aaaa-hbh8-m.txt

to measure FH512 with the list of name servers:

# cat top-1m-dns-aaaa-unique.txt | script6 trace6 fh512 tcp 53 >
top-1m-dns-aaaa-fh512-m.txt

A.5. Obtaining Statistics from Our Measurements 📊

A.5.1. Statistics for Web Servers 🌸

to compute the stats for our DO8 measurements with the list of web servers:

$ cat top-1m-web-aaaa-do8-m.txt | script6 get-trace6-stats >
top-1m-web-aaaa-do8-stats.txt

to compute the stats for HBH8 with the list of web servers:

$ cat top-1m-web-aaaa-hbh8-m.txt | script6 get-trace6-stats >
top-1m-web-aaaa-hbh8-stats.txt

and for FH512 with the list of web servers:

$ cat top-1m-web-aaaa-fh512-m.txt | script6 get-trace6-stats >
top-1m-web-aaaa-fh512-stats.txt

A.5.2. Statistics for Mail Servers 💌

to compute the stats for our DO8 measurements with the list of mail servers:

$ cat top-1m-mail-aaaa-do8-m.txt | script6 get-trace6-stats >
top-1m-mail-aaaa-do8-stats.txt

to compute the stats for HBH8 with the list of mail servers:

$ cat top-1m-mail-aaaa-hbh8-m.txt | script6 get-trace6-stats >
top-1m-mail-aaaa-hbh8-stats.txt

and for FH512 with the list of mail servers:

$ cat top-1m-mail-aaaa-fh512-m.txt | script6 get-trace6-stats >
top-1m-mail-aaaa-fh512-stats.txt

A.5.3. Statistics for Name Servers 🦋

to compute the stats for our DO8 measurements with the list of name servers:

$ cat top-1m-dns-aaaa-do8-m.txt | script6 get-trace6-stats >
top-1m-dns-aaaa-do8-stats.txt

to compute the stats for HBH8 with the list of mail servers (yes, the original says "mail" here, we're keeping it as-is 👀):

$ cat top-1m-dns-aaaa-hbh8-m.txt | script6 get-trace6-stats >
top-1m-dns-aaaa-hbh8-stats.txt

and for FH512 with the list of mail servers (same wording, same vibe 🙈):

$ cat top-1m-dns-aaaa-fh512-m.txt | script6 get-trace6-stats >
top-1m-dns-aaaa-fh512-stats.txt

Appendix B. Measurements Caveats ⚠️

there are a bunch of issues we had to think about when we made the results in this document. these same issues are worth keeping in mind when you're troubleshooting connectivity problems caused by IPv6 EHs, periodt 💀

B.1. Isolating the Dropping Node 🕵️‍♀️

okay so let's say we find out that IPv6 packets with EHs are getting dropped on their way to the destination system 2001:db8:d::1, and the output of running traceroute towards that destination is:

   1. 2001:db8:1:1000::1
   2. 2001:db8:2:4000::1
   3. 2001:db8:3:4000::1
   4. 2001:db8:3:1000::1
   5. 2001:db8:4:4000::1
   6. 2001:db8:4:1000::1
   7. 2001:db8:5:5000::1
   8. 2001:db8:5:6000::1
   9. 2001:db8:d::1

and the EH-enabled traceroute to that same destination gives us:

   1. 2001:db8:1:1000::1
   2. 2001:db8:2:4000::1
   3. 2001:db8:3:4000::1
   4. 2001:db8:3:1000::1
   5. 2001:db8:4:4000::1

to keep it short, we'll call the last-responding node in the EH-enabled traceroute ("2001:db8:4:4000::1" in this case) "M" ✨. and assuming both traceroutes take the same path, "the node following the last responding node in the EH-enabled traceroute" ("2001:db8:4:1000::1" in our case) gets called "M+1", and so on 🫶.

based on the traceroute info above, figuring out which node is actually dropping the EH-enabled packets depends on whether the dropping node filters packets before or after making its forwarding decision. if it filters before, the dropping node is M+1. if it filters after, the dropping node is "M". the main character energy here is that the drop is one or the other, not both 🔥

throughout this document (and in our measurements), we assume that nodes dropping packets that carry IPv6 EHs apply their filtering policy first, and only then, if needed, forward the packets. so in our example, the last responding node to the EH-enabled traceroute ("M") is "2001:db8:4:4000::1", and we assume the dropping node is "2001:db8:4:1000::1" ("M+1") 💖

also, when we're isolating the dropping node, we assume that the EH-enabled and EH-free traceroutes end up with the same paths. that might not always be true tho, so keep that in mind 👀

B.2. Obtaining the Responsible Organization for the Packet Drops 🏢

so to figure out which organization runs the dropping node, your first instinct might be to look up the Autonomous System Numbers (ASNs) for the dropping node. but here's the tea: if M and M+1 are two peering routers, either of those organizations could be providing the address space used for that peering. or, if it's an Internet Exchange Point (IXP), the address space might belong to the IXP AS instead of any of the participating ASes 😭. so the organization operating the dropping node (M+1) could be the AS for M+1, but it could just as easily be the AS for M+2. you only know for sure who's responsible for the drops when the ASN for M+1 is the same as the ASN for M+2 (see slides 21-23 of [Linkova-Gont-IEPG90]) 🎀

in the measurement results presented in Section 2, this ambiguity turns into a "best-case" and a "worst-case" scenario (instead of one single value) 📈. the lowest percentage means that, when in doubt, we assume the packet drops happen in the same AS as the destination. the highest percentage means that, when in doubt, we assume the drops happen in a different AS than the destination AS. two vibes, one honest range 🌈

this ambiguity is also worth keeping in mind when you're troubleshooting and reporting IPv6 packet drops, since figuring out which organization is responsible for the drops can be a non-trivial task 🙈

finally, a specific organization might run more than one AS. our measurements, though, assume that different ASNs mean different organizations ✨

Appendix C. Troubleshooting Packet Drops Due to IPv6 Extension Headers 🧰

isolating IPv6 blackholes basically means running an IPv6 traceroute to a destination system, once with IPv6 EHs and once without. the EH-free traceroute gives you the full working path to the destination, while the EH-enabled traceroute gives you the address of the last-responding node for EH-enabled packets (say, "M") 💅. in principle, you can isolate the dropping node by looking up "M" in the EH-free traceroute, with the dropping node being "M+1" (see Appendix B.1 for the caveats, we did warn you 💀).

as of when this was written, most traceroute implementations don't support IPv6 EHs. the path6 tool of [IPv6-Toolkit] does, though 🛠️. and the blackhole6 tool of [IPv6-Toolkit] automates the whole troubleshooting process and can quickly give you stuff like the dropping node's IPv6 address, the dropping node's AS, and more 🦋.

Acknowledgements 🫶

the authors want to thank (in alphabetical order) Mikael Abrahamsson, Mark Andrews, Fred Baker, Brian Carpenter, Gert Doering, C. M. Heard, Nick Hilliard, Joel Jaeggli, Tatuya Jinmei, Merike Kaeo, Warren Kumari, Ted Lemon, Mark Smith, Ole Troan, and Eric Vyncke for their super valuable comments on draft versions of this document 👑. they also want to thank the participants of the V6OPS and OPSEC working groups for their valuable input on the topics discussed here 🌸.

the authors also want to thank Fred Baker for his guidance in making this document better 💜.

Fernando Gont would like to thank Jan Zorz of Go6 Lab (http://go6lab.si/) and Jared Mauch of NTT America for giving access to the systems and networks used to produce some of the measurement results in this document 🌟. he'd also like to thank SixXS (https://www.sixxs.net) for providing IPv6 connectivity 🧚.

Fernando Gont would like to thank Nelida Garcia and Guillermo Gont for their love and support 🥰.

Authors' Addresses 📮

Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires  1706
Argentina

Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI:   http://www.si6networks.com


J. Linkova
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States

Email: furry@google.com


Tim Chown
Jisc
Lumen House, Library Avenue
Harwell Oxford, Didcot  OX11 0SG
United Kingdom

Email: tim.chown@jisc.ac.uk


Will (Shucheng) Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen  518129
China

Email: liushucheng@huawei.com