Internet Engineering Task Force (IETF) F. Gont Request for Comments: 7872 SI6 Networks / UTN-FRH Category: Informational J. Linkova ISSN: 2070-1721 Google T. Chown Jisc W. Liu Huawei Technologies June 2016 Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World
AbstractThis document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at 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 document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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
PMTUD-Blackholes], [Gont-IEPG88], and [Gont-Chown-IEPG89], whereas [Linkova-Gont-IEPG90] presents more comprehensive results on which this document is based. This document presents real-world data regarding the extent to which packets containing IPv6 EHs are dropped in the Internet, as measured in August 2014 and later in June 2015 with similar results (pending operational advice in this area). The results presented in this document indicate that in the scenarios where the corresponding measurements were performed, the use of IPv6 EHs can lead to packet drops. We note that, in particular, packet drops occurring at transit networks are undesirable, and it is hoped and expected that this situation will improve over time. http://www.worldipv6launch.org> and Alexa's list of the Top 1-Million Web Sites <http://www.alexa.com>. For each list of domain names, the following datasets were obtained: o Web servers (AAAA records of the aforementioned list) o Mail servers (MX -> AAAA records of the aforementioned list) o Name servers (NS -> AAAA records of the aforementioned list) Duplicate addresses and IPv6 addresses other than global unicast addresses were eliminated from each of those lists prior to obtaining the results included in this document. Additionally, addresses that were found to be unreachable were discarded from the dataset (please see Appendix B for further details). For each of the aforementioned address sets, three different types of probes were employed: o IPv6 packets with a Destination Options header of 8 bytes;
o IPv6 packets resulting in two IPv6 fragments of 512 bytes each (approximately); and o IPv6 packets with a Hop-by-Hop Options header of 8 bytes. In the case of packets with a Destination Options header and the case of packets with a Hop-by-Hop Options header, the desired EH size was achieved by means of PadN options [RFC2460]. The upper-layer protocol of the probe packets was, in all cases, TCP [RFC793] with the Destination Port set to the service port [IANA-PORT-NUMBERS] of the corresponding dataset. For example, the probe packets for all the measurements involving web servers were TCP segments with the Destination Port set to 80. Besides obtaining the packet drop rate when employing the aforementioned IPv6 EHs, we tried to identify whether the Autonomous System (AS) dropping the packets was the same as the AS of the destination/target address. This is of particular interest since it essentially reveals whether the packet drops are under the control of the intended destination of the packets. Packets dropped by the destination AS are less of a concern since the device dropping the packets is under the control of the same organization as that to which the packets are destined (hence, it is probably easier to update the filtering policy if deemed necessary). On the other hand, packets dropped by transit ASes are more of a concern since they affect the deployability and usability of IPv6 EHs (including IPv6 fragmentation) by a third party (the destination AS). In any case, we note that it is impossible to tell whether, in those cases where IPv6 packets with EHs 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. Thus, packet drops that occur at the destination AS might still prove to be problematic. Since there is some ambiguity when identifying the AS to which a specific router belongs (see Appendix B.2), each of our measurements results in two different values: one corresponding to the "best-case scenario" and one corresponding to the "worst-case scenario". The "best-case scenario" is that in which, when in doubt, the packets are assumed to be dropped by the destination AS, whereas the "worst-case scenario" is that in which, when in doubt, the packets are assumed to be dropped by a transit AS (please see Appendix B.2 for details). In the following tables, the values shown within parentheses represent the possibility that, when a packet is dropped, the packet drop occurs in an AS other than the destination AS (considering both the best-case scenario and the worst-case scenario).
+----------+------------------+------------------+------------------+ | Dataset | DO8 | HBH8 | FH512 | +----------+------------------+------------------+------------------+ | Web | 11.88% | 40.70% | 30.51% | | servers | (17.60%/20.80%) | (31.43%/40.00%) | (5.08%/6.78%) | +----------+------------------+------------------+------------------+ | Mail | 17.07% | 48.86% | 39.17% | | servers | (6.35%/26.98%) | (40.50%/65.42%) | (2.91%/12.73%) | +----------+------------------+------------------+------------------+ | Name | 15.37% | 43.25% | 38.55% | | servers | (14.29%/33.46%) | (42.49%/72.07%) | (3.90%/13.96%) | +----------+------------------+------------------+------------------+ 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". +----------+------------------+------------------+------------------+ | Dataset | DO8 | HBH8 | FH512 | +----------+------------------+------------------+------------------+ | Web | 10.91% | 39.03% | 28.26% | | servers | (46.52%/53.23%) | (36.90%/46.35%) | (53.64%/61.43%) | +----------+------------------+------------------+------------------+ | Mail | 11.54% | 45.45% | 35.68% | | servers | (2.41%/21.08%) | (41.27%/61.13%) | (3.15%/10.92%) | +----------+------------------+------------------+------------------+ | Name | 21.33% | 54.12% | 55.23% | | servers | (10.27%/56.80%) | (50.64%/81.00%) | (5.66%/32.23%) | +----------+------------------+------------------+------------------+ 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. [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>. [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>.
IPv6-Toolkit]. Throughout this appendix, "#" denotes the command-line prompt for commands that require superuser privileges, whereas "$" denotes the prompt for commands that do not require superuser privileges. 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. The aforementioned file can be extracted 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 will create a "top-1m.txt" file containing 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.
The AAAA records corresponding to the mail servers of each of the aforementioned domain names can be obtained with: $ cat top-1m.txt | script6 get-mx | script6 get-aaaa > top-1m-mail-aaaa.txt The AAAA records corresponding to the name servers of each of the aforementioned domain names can be obtained with: $ cat top-1m.txt | script6 get-ns | script6 get-aaaa > top-1m-dns-aaaa.txt
In order to compute the statistics corresponding to our measurements of 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 In order to compute the statistics corresponding to our measurements of 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
In order to compute the statistics corresponding to our measurements of FH512 with the list of mail servers: $ cat top-1m-dns-aaaa-fh512-m.txt | script6 get-trace6-stats > top-1m-dns-aaaa-fh512-stats.txt
making the forwarding decision. If the former, the dropping node will be M+1. If the latter, the dropping node will be "M". Throughout this document (and our measurements), we assume that those nodes dropping packets that carry IPv6 EHs apply their filtering policy, and only then, if necessary, forward the packets. Thus, in our example above, the last responding node to the EH-enabled traceroute ("M") is "2001:db8:4:4000::1", and we assume the dropping node to be "2001:db8:4:1000::1" ("M+1"). Additionally, we note that when isolating the dropping node we assume that both the EH-enabled and the EH-free traceroutes result in the same paths. However, this might not be the case. Linkova-Gont-IEPG90]). In the measurement results presented in Section 2, the aforementioned ambiguity results in a "best-case" and a "worst-case" scenario (rather than a single value): the lowest percentage value means that, when in doubt, we assume the packet drops occur in the same AS as the destination; on the other hand, the highest percentage value means that, when in doubt, we assume the packet drops occur at a different AS than the destination AS. We note that the aforementioned ambiguity should also be considered when troubleshooting and reporting IPv6 packet drops since identifying the organization responsible for the packet drops might prove to be a non-trivial task. Finally, we note that a specific organization might be operating more than one AS. However, our measurements assume that different ASNs imply different organizations.
Appendix B.1 for caveats). At the time of this writing, most traceroute implementations do not support IPv6 EHs. However, the path6 tool of [IPv6-Toolkit] provides such support. Additionally, the blackhole6 tool of [IPv6-Toolkit] automates the troubleshooting process and can readily provide information such as: dropping node's IPv6 address, dropping node's AS, etc. http://go6lab.si/> and Jared Mauch of NTT America for providing access to systems and networks that were employed to produce some of the measurement results presented in this document. Additionally, he would 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.
http://www.si6networks.com J. Linkova Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States Email: email@example.com Tim Chown Jisc Lumen House, Library Avenue Harwell Oxford, Didcot OX11 0SG United Kingdom Email: firstname.lastname@example.org Will (Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 China Email: email@example.com