draft-ietf-v6ops-ipv6-ehs-in-real-world-02.txt   rfc7872.txt 
IPv6 Operations Working Group (v6ops) F. Gont Internet Engineering Task Force (IETF) F. Gont
Internet-Draft SI6 Networks / UTN-FRH Request for Comments: 7872 SI6 Networks / UTN-FRH
Intended status: Informational J. Linkova Category: Informational J. Linkova
Expires: June 12, 2016 Google ISSN: 2070-1721 Google
T. Chown T. Chown
University of Southampton Jisc
W. Liu W. Liu
Huawei Technologies Huawei Technologies
December 10, 2015 June 2016
Observations on the Dropping of Packets with IPv6 Extension Headers in Observations on the Dropping of Packets
the Real World with IPv6 Extension Headers in the Real World
draft-ietf-v6ops-ipv6-ehs-in-real-world-02
Abstract Abstract
This document presents real-world data regarding the extent to which This document presents real-world data regarding the extent to which
packets with IPv6 extension headers are dropped in the Internet (as packets with IPv6 Extension Headers (EHs) are dropped in the Internet
originally measured in August 2014 and later in June 2015, with (as originally measured in August 2014 and later in June 2015, with
similar results), and where in the network such dropping occurs. The similar results) and where in the network such dropping occurs. The
aforementioned results serve as a problem statement that is expected aforementioned results serve as a problem statement that is expected
to trigger operational advice on the filtering of IPv6 packets to trigger operational advice on the filtering of IPv6 packets
carrying IPv6 Extension Headers, so that the situation improves over carrying IPv6 EHs so that the situation improves over time. This
time. This document also explains how the aforementioned results document also explains how the results were obtained, such that the
were obtained, such that the corresponding measurements can be corresponding measurements can be reproduced by other members of the
reproduced by other members of the community and repeated over time community and repeated over time to observe changes in the handling
to observe changes in the handling of packets with IPv6 extension of packets with IPv6 EHs.
headers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on June 12, 2016. 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Support of IPv6 Extension Headers in the Internet . . . . . . 3 2. Support of IPv6 Extension Headers in the Internet . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Normative References . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Informative References . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Reproducing Our Experiment . . . . . . . . . . . . . 8 Appendix A. Reproducing Our Experiment . . . . . . . . . . . . . 8
A.1. Obtaining the List of Domain Names . . . . . . . . . . . 8 A.1. Obtaining the List of Domain Names . . . . . . . . . . . 8
A.2. Obtaining AAAA Resource Records . . . . . . . . . . . . . 9 A.2. Obtaining AAAA Resource Records . . . . . . . . . . . . . 8
A.3. Filtering the IPv6 Address Datasets . . . . . . . . . . . 9 A.3. Filtering the IPv6 Address Datasets . . . . . . . . . . . 9
A.4. Performing Measurements with Each IPv6 Address Dataset . 10 A.4. Performing Measurements with Each IPv6 Address Dataset . 9
A.5. Obtaining Statistics from our Measurements . . . . . . . 11 A.5. Obtaining Statistics from Our Measurements . . . . . . . 10
Appendix B. Measurements Caveats . . . . . . . . . . . . . . . . 12 Appendix B. Measurements Caveats . . . . . . . . . . . . . . . . 12
B.1. Isolating the Dropping Node . . . . . . . . . . . . . . . 12 B.1. Isolating the Dropping Node . . . . . . . . . . . . . . . 12
B.2. Obtaining the Responsible Organization for the Packet B.2. Obtaining the Responsible Organization for the Packet
Drops . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Drops . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix C. Troubleshooting Packet Drops due to IPv6 Extension Appendix C. Troubleshooting Packet Drops Due to IPv6 Extension
Headers . . . . . . . . . . . . . . . . . . . . . . 14 Headers . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
IPv6 Extension Headers (EHs) allow for the extension of the IPv6 IPv6 Extension Headers (EHs) allow for the extension of the IPv6
protocol, and provide support for core functionality such as IPv6 protocol and provide support for core functionality such as IPv6
fragmentation. While packets employing IPv6 Extension Headers have fragmentation. While packets employing IPv6 EHs have been suspected
been suspected to be dropped in some IPv6 deployments, there was not to be dropped in some IPv6 deployments, there was not much concrete
much concrete data on the topic. Some preliminary measurements have data on the topic. Some preliminary measurements have been presented
been presented in [PMTUD-Blackholes], [Gont-IEPG88] and in [PMTUD-Blackholes], [Gont-IEPG88], and [Gont-Chown-IEPG89],
whereas [Linkova-Gont-IEPG90] presents more comprehensive results on
[Gont-Chown-IEPG89], whereas [Linkova-Gont-IEPG90] presents more which this document is based.
comprehensive results on which this document is based.
This document presents real-world data regarding the extent to which This document presents real-world data regarding the extent to which
packets containing IPv6 Extension Headers are dropped in the packets containing IPv6 EHs are dropped in the Internet, as measured
Internet, as measured in August 2014 and later in June 2015 with in August 2014 and later in June 2015 with similar results (pending
similar results (pending operational advice in this area). The operational advice in this area). The results presented in this
results presented in this document indicate that in the scenarios document indicate that in the scenarios where the corresponding
where the corresponding measurements were performed, the use of IPv6 measurements were performed, the use of IPv6 EHs can lead to packet
extension headers can lead to packet drops. We note that, in drops. We note that, in particular, packet drops occurring at
particular, packet drops occurring at transit networks are transit networks are undesirable, and it is hoped and expected that
undesirable, and it is hoped and expected that this situation will this situation will improve over time.
improve over time.
2. Support of IPv6 Extension Headers in the Internet 2. Support of IPv6 Extension Headers in the Internet
This section summarizes the results obtained when measuring the This section summarizes the results obtained when measuring the
support of IPv6 Extension Headers on the path towards different types support of IPv6 EHs on the path towards different types of public
of public IPv6 servers. Two sources of information were employed for IPv6 servers. Two sources of information were employed for the list
the list of public IPv6 servers: the "World IPv6 Launch Day" site of public IPv6 servers: the "World IPv6 Launch" site
(http://www.worldipv6launch.org/) and Alexa's top 1M web sites <http://www.worldipv6launch.org> and Alexa's list of the Top
(http://www.alexa.com). For each list of domain names, the following 1-Million Web Sites <http://www.alexa.com>. For each list of domain
datasets were obtained: names, the following datasets were obtained:
o Web servers (AAAA records of the aforementioned list) o Web servers (AAAA records of the aforementioned list)
o Mail servers (MX -> AAAA of the aforementioned list) o Mail servers (MX -> AAAA records of the aforementioned list)
o Name servers (NS -> AAAA of the aforementioned list) o Name servers (NS -> AAAA records of the aforementioned list)
Duplicate addresses and IPv6 addresses other than global unicast Duplicate addresses and IPv6 addresses other than global unicast
addresses were eliminated from each of those lists prior to obtaining addresses were eliminated from each of those lists prior to obtaining
the results included in this document. Additionally, addresses that the results included in this document. Additionally, addresses that
were found to be unreachable were discarded from the dataset (please were found to be unreachable were discarded from the dataset (please
see Appendix B for further details). see Appendix B for further details).
For each of the aforementioned address sets, three different types of For each of the aforementioned address sets, three different types of
probes were employed: probes were employed:
o IPv6 packets with a Destination Options header of 8 bytes o IPv6 packets with a Destination Options header of 8 bytes;
o IPv6 packets resulting in two IPv6 fragments of 512 bytes each o IPv6 packets resulting in two IPv6 fragments of 512 bytes each
(approximately) (approximately); and
o IPv6 packets with a Hop-by-Hop Options header of 8 bytes 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 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 of packets with a Hop-by-Hop Options header, the desired EH size was
achieved by means of PadN options [RFC2460]. The upper-layer achieved by means of PadN options [RFC2460]. The upper-layer
protocol of the probe packets was, in all cases, TCP [RFC0793] protocol of the probe packets was, in all cases, TCP [RFC793] with
segments with the Destination Port set to the service port the Destination Port set to the service port [IANA-PORT-NUMBERS] of
[IANA-PORT-NUMBERS] of the corresponding dataset. For example, the the corresponding dataset. For example, the probe packets for all
probe packets for all the measurements involving web servers were TCP the measurements involving web servers were TCP segments with the
segments with the destination port set to 80. Destination Port set to 80.
Besides obtaining the packet drop rate when employing the Besides obtaining the packet drop rate when employing the
aforementioned IPv6 extension headers, we tried to identify whether aforementioned IPv6 EHs, we tried to identify whether the Autonomous
the Autonomous System (AS) dropping the packets was the same as the System (AS) dropping the packets was the same as the AS of the
Autonomous System of the destination/target address. This is of destination/target address. This is of particular interest since it
particular interest since it essentially reveals whether the packet essentially reveals whether the packet drops are under the control of
drops are under the control of the intended destination of the the intended destination of the packets. Packets dropped by the
packets. Packets dropped by the destination AS are less of a destination AS are less of a concern since the device dropping the
concern, since the device dropping the packets is under the control packets is under the control of the same organization as that to
of the same organization as that to which the packets are destined which the packets are destined (hence, it is probably easier to
(hence, it is probably easier to update the filtering policy if update the filtering policy if deemed necessary). On the other hand,
deemed necessary). On the other hand, packets dropped by transit packets dropped by transit ASes are more of a concern since they
ASes are more of a concern, since they affect the deployability and affect the deployability and usability of IPv6 EHs (including IPv6
usability of IPv6 extension headers (including IPv6 fragmentation) by fragmentation) by a third party (the destination AS). In any case,
a third-party (the destination AS). In any case, we note that it is we note that it is impossible to tell whether, in those cases where
impossible to tell whether, in those cases where IPv6 packets with IPv6 packets with EHs get dropped, the packet drops are the result of
extension headers get dropped, the packet drops are the result of an an explicit and intended policy or the result of improper device
explicit and intended policy, or the result of improper device
configuration defaults, buggy devices, etc. Thus, packet drops that configuration defaults, buggy devices, etc. Thus, packet drops that
occur at the destination AS might still prove to be problematic. occur at the destination AS might still prove to be problematic.
Since there is some ambiguity when identifying the autonomous system Since there is some ambiguity when identifying the AS to which a
to which a specific router belongs (see Appendix B.2), each of our specific router belongs (see Appendix B.2), each of our measurements
measurements results in two different values: one corresponding to results in two different values: one corresponding to the "best-case
the "best-case scenario", and one corresponding to the "worst-case scenario" and one corresponding to the "worst-case scenario". The
scenario". The "best-case scenario" is that in which, when in doubt, "best-case scenario" is that in which, when in doubt, the packets are
the packets are assumed to be dropped by the destination AS, whereas assumed to be dropped by the destination AS, whereas the "worst-case
the "worst-case scenario" is that in which, when in doubt, the scenario" is that in which, when in doubt, the packets are assumed to
packets are assumed to be dropped by a transit AS (please see be dropped by a transit AS (please see Appendix B.2 for details). In
Appendix B.2 for details). In the following tables, the values shown the following tables, the values shown within parentheses represent
within parentheses represent the possibility that, when a packet is the possibility that, when a packet is dropped, the packet drop
dropped, the packet drop occurs in an AS other than the destination occurs in an AS other than the destination AS (considering both the
AS (considering both the best-case scenario and the worst-case best-case scenario and the worst-case scenario).
scenario).
+-------------+-----------------+-----------------+-----------------+ +----------+------------------+------------------+------------------+
| Dataset | DO8 | HBH8 | FH512 | | Dataset | DO8 | HBH8 | FH512 |
+-------------+-----------------+-----------------+-----------------+ +----------+------------------+------------------+------------------+
| Webservers | 11.88% | 40.70% | 30.51% | | Web | 11.88% | 40.70% | 30.51% |
| | (17.60%/20.80%) | (31.43%/40.00%) | (5.08%/6.78%) | | servers | (17.60%/20.80%) | (31.43%/40.00%) | (5.08%/6.78%) |
+-------------+-----------------+-----------------+-----------------+ +----------+------------------+------------------+------------------+
| Mailservers | 17.07% | 48.86% | 39.17% | | Mail | 17.07% | 48.86% | 39.17% |
| | (6.35%/26.98%) | (40.50%/65.42%) | (2.91%/12.73%) | | servers | (6.35%/26.98%) | (40.50%/65.42%) | (2.91%/12.73%) |
+-------------+-----------------+-----------------+-----------------+ +----------+------------------+------------------+------------------+
| Nameservers | 15.37% | 43.25% | 38.55% | | Name | 15.37% | 43.25% | 38.55% |
| | (14.29%/33.46%) | (42.49%/72.07%) | (3.90%/13.96%) | | servers | (14.29%/33.46%) | (42.49%/72.07%) | (3.90%/13.96%) |
+-------------+-----------------+-----------------+-----------------+ +----------+------------------+------------------+------------------+
Table 1: WIPv6LD dataset: Packet drop rate for different destination Table 1: WIPv6LD Dataset: Packet Drop Rate for Different Destination
types, and estimated percentage of dropped packets that were deemed Types, and Estimated (Best-Case / Worst-Case) Percentage of Packets
to be dropped in a different AS (lower, in parentheses) 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 NOTE: As an example, we note that the cell describing the support
of IPv6 packets with DO8 for webservers (containing the value of IPv6 packets with DO8 for web servers (containing the value
"11.88% (17.60%/20.80%)") should be read as: "when sending IPv6 "11.88% (17.60%/20.80%)") should be read as: "when sending IPv6
packets with DO8 to public webservers, 11.88% of such packets get packets with DO8 to public web servers, 11.88% of such packets get
dropped. Among those packets that get dropped, 17.60%/20.80% dropped. Among those packets that get dropped, 17.60%/20.80%
(best case / worst case) of them get dropped at an AS other than (best case / worst case) of them get dropped at an AS other than
the destination AS". the destination AS".
+-------------+-----------------+-----------------+-----------------+ +----------+------------------+------------------+------------------+
| Dataset | DO8 | HBH8 | FH512 | | Dataset | DO8 | HBH8 | FH512 |
+-------------+-----------------+-----------------+-----------------+ +----------+------------------+------------------+------------------+
| Webservers | 10.91% | 39.03% | 28.26% | | Web | 10.91% | 39.03% | 28.26% |
| | (46.52%/53.23%) | (36.90%/46.35%) | (53.64%/61.43%) | | servers | (46.52%/53.23%) | (36.90%/46.35%) | (53.64%/61.43%) |
+-------------+-----------------+-----------------+-----------------+ +----------+------------------+------------------+------------------+
| Mailservers | 11.54% | 45.45% | 35.68% | | Mail | 11.54% | 45.45% | 35.68% |
| | (2.41%/21.08%) | (41.27%/61.13%) | (3.15%/10.92%) | | servers | (2.41%/21.08%) | (41.27%/61.13%) | (3.15%/10.92%) |
+-------------+-----------------+-----------------+-----------------+ +----------+------------------+------------------+------------------+
| Nameservers | 21.33% | 54.12% | 55.23% | | Name | 21.33% | 54.12% | 55.23% |
| | (10.27%/56.80%) | (50.64%/81.00%) | (5.66%/32.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 Table 2: Alexa's Top 1M Sites Dataset: Packet Drop Rate for Different
destination types, and estimated percentage of dropped packets that Destination Types, and Estimated (Best-Case / Worst-Case) Percentage
were deemed to be dropped in a different AS (lower, in parentheses) of Packets That Were Dropped in a Different AS
There are a number of observations to be made based on the results There are a number of observations to be made based on the results
presented above. Firstly, while it has been generally assumed that presented above. Firstly, while it has been generally assumed that
it is IPv6 fragments that are dropped by operators, our results it is IPv6 fragments that are dropped by operators, our results
indicate that it is IPv6 extension headers in general that result in indicate that it is IPv6 EHs in general that result in packet drops.
packet drops. Secondly, our results indicate that a significant Secondly, our results indicate that a significant percentage of such
percentage of such packet drops occurs in transit Autonomous Systems; packet drops occurs in transit ASes; that is, the packet drops are
that is, the packet drops are not under the control of the same not under the control of the same organization as the final
organization as the final destination. destination.
3. IANA Considerations
There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an
RFC.
4. Security Considerations 3. Security Considerations
This document presents real-world data regarding the extent to which This document presents real-world data regarding the extent to which
IPv6 packets employing extension headers are dropped in the Internet. IPv6 packets employing EHs are dropped in the Internet. As such,
As such, this document does not introduce any new security issues. this document does not introduce any new security issues.
5. Acknowledgements
The authors would like 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 providing valuable comments on earlier versions of this
document. Additionally, the authors would like to thank participants
of the v6ops and opsec working groups for their valuable input on the
topics discussed in this document.
The authors would like to thank Fred Baker for his guidance in
improving this document.
Fernando Gont would like to thank Jan Zorz / Go6 Lab
<http://go6lab.si/>, and Jared Mauch / 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.
6. References 4. References
6.1. Normative References 4.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <http://www.rfc-editor.org/info/rfc793>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 4.2. Informative References
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
6.2. Informative References
[blackhole6]
blackhole6, , "blackhole6 tool manual page",
<http://www.si6networks.com/tools/ipv6toolkit>, 2014.
[Gont-Chown-IEPG89] [Gont-Chown-IEPG89]
Gont, F. and T. Chown, "A Small Update on the Use of IPv6 Gont, F. and T. Chown, "A Small Update on the Use of IPv6
Extension Headers", IEPG 89. London, UK. March 2, 2014, Extension Headers", IEPG meeting before IETF 89, March
<http://www.iepg.org/2014-03-02-ietf89/ 2014, <http://www.iepg.org/2014-03-02-ietf89/
fgont-iepg-ietf89-eh-update.pdf>. fgont-iepg-ietf89-eh-update.pdf>.
[Gont-IEPG88] [Gont-IEPG88]
Gont, F., "Fragmentation and Extension header Support in Gont, F., "Fragmentation and Extension Header Support in
the IPv6 Internet", IEPG 88. Vancouver, BC, Canada. the IPv6 Internet", IEPG meeting before IETF 88, November
November 13, 2013, <http://www.iepg.org/2013-11-ietf88/ 2013, <http://www.iepg.org/2013-11-ietf88/
fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>. fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>.
[IANA-PORT-NUMBERS] [IANA-PORT-NUMBERS]
IANA, "Service Name and Transport Protocol Port Number IANA, "Service Name and Transport Protocol Port Number
Registry", <http://www.iana.org/assignments/ Registry", <http://www.iana.org/assignments/
service-names-port-numbers/ service-names-port-numbers>.
service-names-port-numbers.txt>.
[IPv6-Toolkit] [IPv6-Toolkit]
"SI6 Networks' IPv6 Toolkit", SI6 Networks, "SI6 Networks' IPv6 Toolkit v2.0 (Guille)",
<http://www.si6networks.com/tools/ipv6toolkit>. <http://www.si6networks.com/tools/ipv6toolkit>.
[Linkova-Gont-IEPG90] [Linkova-Gont-IEPG90]
Linkova, J. and F. Gont, "IPv6 Extension Headers in the Linkova, J. and F. Gont, "IPv6 Extension Headers in the
Real World v2.0", IEPG 90. Toronto, ON, Canada. July 20, Real World v2.0", IEPG Meeting before IETF 90, July 2014,
2014, <http://www.iepg.org/2014-07-20-ietf90/ <http://www.iepg.org/2014-07-20-ietf90/
iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0.pdf>. iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0.pdf>.
[path6] path6, , "path6 tool manual page",
<http://www.si6networks.com/tools/ipv6toolkit>, 2014.
[PMTUD-Blackholes] [PMTUD-Blackholes]
De Boer, M. and J. Bosma, "Discovering Path MTU black De Boer, M. and J. Bosma, "Discovering Path MTU black
holes on the Internet using RIPE Atlas", July 2012, holes on the Internet using RIPE Atlas", July 2012,
<http://www.nlnetlabs.nl/downloads/publications/ <http://www.nlnetlabs.nl/downloads/publications/
pmtu-black-holes-msc-thesis.pdf>. pmtu-black-holes-msc-thesis.pdf>.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
DOI 10.17487/RFC5927, July 2010,
<http://www.rfc-editor.org/info/rfc5927>.
[RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation
with IPv6 Neighbor Discovery", RFC 6980,
DOI 10.17487/RFC6980, August 2013,
<http://www.rfc-editor.org/info/rfc6980>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013,
<http://www.rfc-editor.org/info/rfc7045>.
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", RFC 7113,
DOI 10.17487/RFC7113, February 2014,
<http://www.rfc-editor.org/info/rfc7113>.
[RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on
IPv4 Networks", RFC 7123, DOI 10.17487/RFC7123, February
2014, <http://www.rfc-editor.org/info/rfc7123>.
Appendix A. Reproducing Our Experiment Appendix A. Reproducing Our Experiment
This section describes, step by step, how to reproduce the experiment This section describes, step by step, how to reproduce the experiment
with which we obtained the results presented in this document. Each with which we obtained the results presented in this document. Each
subsection represents one step in the experiment. The tools employed subsection represents one step in the experiment. The tools employed
for the experiment are traditional UNIX-like tools (such as gunzip), for the experiment are traditional UNIX-like tools (such as gunzip)
and the SI6 Networks' IPv6 Toolkit [IPv6-Toolkit]. and the SI6 Networks' IPv6 Toolkit v2.0 (Guille) [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.
A.1. Obtaining the List of Domain Names A.1. Obtaining the List of Domain Names
The primary data source employed was Alexa's Top 1M web sites, The primary data source employed was Alexa's Top 1M web sites,
available at: <http://s3.amazonaws.com/alexa-static/top-1m.csv.zip>. 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 The file is a zipped file containing the list of the most popular web
sites, in CSV format. The aforementioned file can be extracted with sites, in Comma-Separated Value (CSV) format. The aforementioned
"gunzip < top-1m.csv.zip > top-1m.csv". file can be extracted with
A list of domain names (i.e., other data stripped) can be obtained $ gunzip < top-1m.csv.zip > top-1m.csv
with the following command of [IPv6-Toolkit]: "cat top-1m.csv |
script6 get-alexa-domains > top-1m.txt". This command will create a A list of domain names (i.e., with other data stripped) can be
"top-1m.txt" file, containing one domain name per line. 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 NOTE: The domain names corresponding to the WIPv6LD dataset is
available at: <http://www.si6networks.com/datasets/wipv6day- available at
domains.txt>. Since the corresponding file is a text file <http://www.si6networks.com/datasets/wipv6day-domains.txt>. Since
containing one domain name per line, the steps produced in this the corresponding file is a text file containing one domain name
subsection need not be performed. The WIPv6LD data set should be per line, the steps produced in this subsection need not be
processed in the same way as the Alexa Dataset, starting from performed. The WIPv6LD dataset should be processed in the same
Appendix A.2. way as the Alexa dataset, starting from Appendix A.2.
A.2. Obtaining AAAA Resource Records A.2. Obtaining AAAA Resource Records
The file obtained in the previous subsection contains a list of The file obtained in the previous subsection contains a list of
domain names that correspond to web sites. The AAAA records for such domain names that correspond to web sites. The AAAA records for such
domain names can be obtained with: domain names can be obtained with:
$ cat top-1m.txt | script6 get-aaaa > top-1m-web-aaaa.txt $ cat top-1m.txt | script6 get-aaaa > top-1m-web-aaaa.txt
The AAAA records corresponding to the mail servers of each of the
The AAAA records corresponding to the mailservers of each of the
aforementioned domain names can be obtained with: aforementioned domain names can be obtained with:
$ cat top-1m.txt | script6 get-mx | script6 get-aaaa > top-1m-mail- $ cat top-1m.txt | script6 get-mx | script6 get-aaaa >
aaaa.txt top-1m-mail-aaaa.txt
The AAAA records corresponding to the nameservers of each of the The AAAA records corresponding to the name servers of each of the
aforementioned domain names can be obtained with: aforementioned domain names can be obtained with:
$ cat top-1m.txt | script6 get-ns | script6 get-aaaa > top-1m-dns- $ cat top-1m.txt | script6 get-ns | script6 get-aaaa >
aaaa.txt top-1m-dns-aaaa.txt
A.3. Filtering the IPv6 Address Datasets A.3. Filtering the IPv6 Address Datasets
The lists of IPv6 addresses obtained in the previous step could The lists of IPv6 addresses obtained in the previous step could
possibly contain undesired addresses (i.e., non-global unicast possibly contain undesired addresses (e.g., non-global unicast
addresses) and/or duplicate addresses. In order to remove both addresses) and/or duplicate addresses. In order to remove both
undesired and duplicate addresses, each of the three files from the undesired and duplicate addresses, each of the three files from the
previous section should be filtered accordingly: previous section should be filtered accordingly:
$ cat top-1m-web-aaaa.txt | addr6 -i -q -B multicast -B unspec -k $ cat top-1m-web-aaaa.txt | addr6 -i -q -B multicast -B unspec -k
global > top-1m-web-aaaa-unique.txt global > top-1m-web-aaaa-unique.txt
$ cat top-1m-mail-aaaa.txt | addr6 -i -q -B multicast -B unspec -k $ cat top-1m-mail-aaaa.txt | addr6 -i -q -B multicast -B unspec -k
global > top-1m-mail-aaaa-unique.txt global > top-1m-mail-aaaa-unique.txt
$ cat top-1m-dns-aaaa.txt | addr6 -i -q -B multicast -B unspec -k $ cat top-1m-dns-aaaa.txt | addr6 -i -q -B multicast -B unspec -k
global > top-1m-dns-aaaa-unique.txt global > top-1m-dns-aaaa-unique.txt
A.4. Performing Measurements with Each IPv6 Address Dataset A.4. Performing Measurements with Each IPv6 Address Dataset
A.4.1. Measurements with web servers A.4.1. Measurements with Web Servers
In order to measure DO8 with the list of webservers: In order to measure DO8 with the list of web servers:
# cat top-1m-web-aaaa-unique.txt | script6 trace6 do8 tcp 80 > top- # cat top-1m-web-aaaa-unique.txt | script6 trace6 do8 tcp 80 >
1m-web-aaaa-do8-m.txt top-1m-web-aaaa-do8-m.txt
In order to measure HBH8 with the list of webservers: In order to measure HBH8 with the list of web servers:
# cat top-1m-web-aaaa-unique.txt | script6 trace6 hbh8 tcp 80 > top- # cat top-1m-web-aaaa-unique.txt | script6 trace6 hbh8 tcp 80 >
1m-web-aaaa-hbh8-m.txt top-1m-web-aaaa-hbh8-m.txt
In order to measure FH512 with the list of webservers: In order to measure FH512 with the list of web servers:
# cat top-1m-web-aaaa-unique.txt | script6 trace6 fh512 tcp 80 > top- # cat top-1m-web-aaaa-unique.txt | script6 trace6 fh512 tcp 80 >
1m-web-aaaa-fh512-m.txt top-1m-web-aaaa-fh512-m.txt
A.4.2. Measurements with mail servers A.4.2. Measurements with Mail Servers
In order to measure DO8 with the list of mailservers: In order to measure DO8 with the list of mail servers:
# cat top-1m-mail-aaaa-unique.txt | script6 trace6 do8 tcp 25 > top- # cat top-1m-mail-aaaa-unique.txt | script6 trace6 do8 tcp 25 >
1m-mail-aaaa-do8-m.txt top-1m-mail-aaaa-do8-m.txt
In order to measure HBH8 with the list of webservers: In order to measure HBH8 with the list of mail servers:
# cat top-1m-mail-aaaa-unique.txt | script6 trace6 hbh8 tcp 25 > top- # cat top-1m-mail-aaaa-unique.txt | script6 trace6 hbh8 tcp 25 >
1m-mail-aaaa-hbh8-m.txt top-1m-mail-aaaa-hbh8-m.txt
In order to measure FH512 with the list of webservers: In order to measure FH512 with the list of mail servers:
# cat top-1m-mail-aaaa-unique.txt | script6 trace6 fh512 tcp 25 > # cat top-1m-mail-aaaa-unique.txt | script6 trace6 fh512 tcp 25 >
top-1m-mail-aaaa-fh512-m.txt top-1m-mail-aaaa-fh512-m.txt
A.4.3. Measurements with DNS servers A.4.3. Measurements with Name Servers
In order to measure DO8 with the list of mameservers: In order to measure DO8 with the list of name servers:
# cat top-1m-dns-aaaa-unique.txt | script6 trace6 do8 tcp 53 > top- # cat top-1m-dns-aaaa-unique.txt | script6 trace6 do8 tcp 53 >
1m-dns-aaaa-do8-m.txt top-1m-dns-aaaa-do8-m.txt
In order to measure HBH8 with the list of webservers: In order to measure HBH8 with the list of name servers:
# cat top-1m-dns-aaaa-unique.txt | script6 trace6 hbh8 tcp 53 > top- # cat top-1m-dns-aaaa-unique.txt | script6 trace6 hbh8 tcp 53 >
1m-dns-aaaa-hbh8-m.txt top-1m-dns-aaaa-hbh8-m.txt
In order to measure FH512 with the list of webservers: In order to measure FH512 with the list of name servers:
# cat top-1m-dns-aaaa-unique.txt | script6 trace6 fh512 tcp 53 > top- # cat top-1m-dns-aaaa-unique.txt | script6 trace6 fh512 tcp 53 >
1m-dns-aaaa-fh512-m.txt top-1m-dns-aaaa-fh512-m.txt
A.5. Obtaining Statistics from our Measurements A.5. Obtaining Statistics from Our Measurements
A.5.1. Statistics for Web Servers A.5.1. Statistics for Web Servers
In order to compute the statistics corresponding to our measurements In order to compute the statistics corresponding to our measurements
of DO8 with the list of webservers: of DO8 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
$ cat top-1m-web-aaaa-do8-m.txt | script6 get-trace6-stats >
top-1m-web-aaaa-do8-stats.txt
In order to compute the statistics corresponding to our measurements In order to compute the statistics corresponding to our measurements
of HBH8 with the list of webservers: of HBH8 with the list of web servers:
$ cat top-1m-web-aaaa-hbh8-m.txt | script6 get-trace6-stats > top-1m- $ cat top-1m-web-aaaa-hbh8-m.txt | script6 get-trace6-stats >
web-aaaa-hbh8-stats.txt top-1m-web-aaaa-hbh8-stats.txt
In order to compute the statistics corresponding to our measurements In order to compute the statistics corresponding to our measurements
of FH512 with the list of webservers: of FH512 with the list of web servers:
$ cat top-1m-web-aaaa-fh512-m.txt | script6 get-trace6-stats > top- $ cat top-1m-web-aaaa-fh512-m.txt | script6 get-trace6-stats >
1m-web-aaaa-fh512-stats.txt top-1m-web-aaaa-fh512-stats.txt
A.5.2. Statistics for Mail Servers A.5.2. Statistics for Mail Servers
In order to compute the statistics corresponding to our measurements In order to compute the statistics corresponding to our measurements
of DO8 with the list of mailservers: of DO8 with the list of mail servers:
$ cat top-1m-mail-aaaa-do8-m.txt | script6 get-trace6-stats > top-1m- $ cat top-1m-mail-aaaa-do8-m.txt | script6 get-trace6-stats >
mail-aaaa-do8-stats.txt top-1m-mail-aaaa-do8-stats.txt
In order to compute the statistics corresponding to our measurements In order to compute the statistics corresponding to our measurements
of HBH8 with the list of mailservers: of HBH8 with the list of mail servers:
$ cat top-1m-mail-aaaa-hbh8-m.txt | script6 get-trace6-stats > top- $ cat top-1m-mail-aaaa-hbh8-m.txt | script6 get-trace6-stats >
1m-mail-aaaa-hbh8-stats.txt top-1m-mail-aaaa-hbh8-stats.txt
In order to compute the statistics corresponding to our measurements In order to compute the statistics corresponding to our measurements
of FH512 with the list of mailservers: of FH512 with the list of mail servers:
$ cat top-1m-mail-aaaa-fh512-m.txt | script6 get-trace6-stats > top- $ cat top-1m-mail-aaaa-fh512-m.txt | script6 get-trace6-stats >
1m-mail-aaaa-fh512-stats.txt top-1m-mail-aaaa-fh512-stats.txt
A.5.3. Statistics for Name Servers A.5.3. Statistics for Name Servers
In order to compute the statistics corresponding to our measurements In order to compute the statistics corresponding to our measurements
of DO8 with the list of nameservers: of DO8 with the list of name servers:
$ cat top-1m-dns-aaaa-do8-m.txt | script6 get-trace6-stats > top-1m- $ cat top-1m-dns-aaaa-do8-m.txt | script6 get-trace6-stats >
dns-aaaa-do8-stats.txt top-1m-dns-aaaa-do8-stats.txt
In order to compute the statistics corresponding to our measurements In order to compute the statistics corresponding to our measurements
of HBH8 with the list of mailservers: of HBH8 with the list of mail servers:
$ cat top-1m-dns-aaaa-hbh8-m.txt | script6 get-trace6-stats > top-1m-
dns-aaaa-hbh8-stats.txt
$ cat top-1m-dns-aaaa-hbh8-m.txt | script6 get-trace6-stats >
top-1m-dns-aaaa-hbh8-stats.txt
In order to compute the statistics corresponding to our measurements In order to compute the statistics corresponding to our measurements
of FH512 with the list of mailservers: of FH512 with the list of mail servers:
$ cat top-1m-dns-aaaa-fh512-m.txt | script6 get-trace6-stats > top- $ cat top-1m-dns-aaaa-fh512-m.txt | script6 get-trace6-stats >
1m-dns-aaaa-fh512-stats.txt top-1m-dns-aaaa-fh512-stats.txt
Appendix B. Measurements Caveats Appendix B. Measurements Caveats
A number of issues have needed some consideration when producing the A number of issues have needed some consideration when producing the
results presented in this document. These same issues should be results presented in this document. These same issues should be
considered when troubleshooting connectivity problems resulting from considered when troubleshooting connectivity problems resulting from
the use of IPv6 Extension headers. the use of IPv6 EHs.
B.1. Isolating the Dropping Node B.1. Isolating the Dropping Node
Let us assume that we find that IPv6 packets with EHs are being Let us assume that we find that IPv6 packets with EHs are being
dropped on their way to the destination system 2001:db8:d::1, and dropped on their way to the destination system 2001:db8:d::1 and that
that the output of running traceroute towards such destination is: the output of running traceroute towards such destination is:
1. 2001:db8:1:1000::1 1. 2001:db8:1:1000::1
2. 2001:db8:2:4000::1 2. 2001:db8:2:4000::1
3. 2001:db8:3:4000::1 3. 2001:db8:3:4000::1
4. 2001:db8:3:1000::1 4. 2001:db8:3:1000::1
5. 2001:db8:4:4000::1 5. 2001:db8:4:4000::1
6. 2001:db8:4:1000::1 6. 2001:db8:4:1000::1
7. 2001:db8:5:5000::1 7. 2001:db8:5:5000::1
8. 2001:db8:5:6000::1 8. 2001:db8:5:6000::1
9. 2001:db8:d::1 9. 2001:db8:d::1
skipping to change at page 13, line 14 skipping to change at page 12, line 45
1. 2001:db8:1:1000::1 1. 2001:db8:1:1000::1
2. 2001:db8:2:4000::1 2. 2001:db8:2:4000::1
3. 2001:db8:3:4000::1 3. 2001:db8:3:4000::1
4. 2001:db8:3:1000::1 4. 2001:db8:3:1000::1
5. 2001:db8:4:4000::1 5. 2001:db8:4:4000::1
For the sake of brevity, let us refer to the last-responding node in For the sake of brevity, let us refer to the last-responding node in
the EH-enabled traceroute ("2001:db8:4:4000::1" in this case) as "M". the EH-enabled traceroute ("2001:db8:4:4000::1" in this case) as "M".
Assuming that packets in both traceroutes employ the same path, we'll Assuming that packets in both traceroutes employ the same path, we'll
refer to "the node following the last responding node in the EH- refer to "the node following the last responding node in the
enabled traceroute" ("2001:db8:4:1000::1" in our case), as "M+1", EH-enabled traceroute" ("2001:db8:4:1000::1" in our case), as "M+1",
etc. etc.
Based on traceroute information above, which node is the one actually Based on traceroute information above, which node is the one actually
dropping the EH-enabled packets will depend on whether the dropping dropping the EH-enabled packets will depend on whether the dropping
node filters packets before making the forwarding decision, or after node filters packets before making the forwarding decision or after
making the forwarding decision. If the former, the dropping node making the forwarding decision. If the former, the dropping node
will be M+1. If the latter, the dropping node will be "M". will be M+1. If the latter, the dropping node will be "M".
Throughout this document (and our measurements), we assume that those Throughout this document (and our measurements), we assume that those
nodes dropping packets that carry IPv6 EHs apply their filtering nodes dropping packets that carry IPv6 EHs apply their filtering
policy, and only then, if necessary, forward the packets. Thus, in policy, and only then, if necessary, forward the packets. Thus, in
our example above the last responding node to the EH-enabled our example above, the last responding node to the EH-enabled
traceroute ("M") is "2001:db8:4:4000::1", and therefore we assume the traceroute ("M") is "2001:db8:4:4000::1", and we assume the dropping
dropping node to be "2001:db8:4:1000::1" ("M+1"). node to be "2001:db8:4:1000::1" ("M+1").
Additionally, we note that when isolating the dropping node we assume Additionally, we note that when isolating the dropping node we assume
that both the EH-enabled and the EH-free traceroutes result in the that both the EH-enabled and the EH-free traceroutes result in the
same paths. However, this might not be the case. same paths. However, this might not be the case.
B.2. Obtaining the Responsible Organization for the Packet Drops B.2. Obtaining the Responsible Organization for the Packet Drops
In order to identify the organization operating the dropping node, In order to identify the organization operating the dropping node,
one would be tempted to lookup the ASN corresponding to the dropping one would be tempted to lookup the Autonomous System Numbers (ASNs)
node. However, assuming that M and M+1 are two peering routers, any corresponding to the dropping node. However, assuming that M and M+1
of these two organizations could be providing the address space are two peering routers, any of these two organizations could be
employed for such peering. Or, in the case of an Internet eXchange providing the address space employed for such peering. Or, in the
Point (IXP), the address space could correspond to the IXP AS, rather case of an Internet Exchange Point (IXP), the address space could
than to any of the participating ASes. Thus, the organization correspond to the IXP AS rather than to any of the participating
operating the dropping node (M+1) could be the AS for M+1, but it ASes. Thus, the organization operating the dropping node (M+1) could
might as well be the AS for M+2. Only when the ASN for M+1 is the be the AS for M+1, but it might as well be the AS for M+2. Only when
same as the ASN for M+2 we have certainty about who the responsible the ASN for M+1 is the same as the ASN for M+2 do we have certainty
organization for the packet drops is (see slides 21-23 of about who the responsible organization for the packet drops is (see
[Linkova-Gont-IEPG90]). slides 21-23 of [Linkova-Gont-IEPG90]).
In the measurement results presented in Section 2, the aforementioned In the measurement results presented in Section 2, the aforementioned
ambiguity results in a "best-case" and a "worst-case" scenario ambiguity results in a "best-case" and a "worst-case" scenario
(rather than a single value): the lowest percentage value means that, (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 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 destination; on the other hand, the highest percentage value means
that, when in doubt, we assume the packet drops occur at different AS that, when in doubt, we assume the packet drops occur at a different
than the destination AS. AS than the destination AS.
We note that the aforementioned ambiguity should also be considered We note that the aforementioned ambiguity should also be considered
when troubleshooting and reporting IPv6 packet drops, since when troubleshooting and reporting IPv6 packet drops since
identifying the organization responsible for the packet drops might identifying the organization responsible for the packet drops might
probe to be a non-trivial task. prove to be a non-trivial task.
Finally, we note that a specific organization might be operating more Finally, we note that a specific organization might be operating more
than one Autonomous System. However, our measurements assume that than one AS. However, our measurements assume that different ASNs
different Autonomous System Numbers imply different organizations. imply different organizations.
Appendix C. Troubleshooting Packet Drops due to IPv6 Extension Headers Appendix C. Troubleshooting Packet Drops Due to IPv6 Extension Headers
Isolating IPv6 blackholes essentially involves performing IPv6 Isolating IPv6 blackholes essentially involves performing IPv6
traceroute for a destination system with and without IPv6 extension traceroute for a destination system with and without IPv6 EHs. The
headers. The EH-free traceroute would provide the full working path EH-free traceroute would provide the full working path towards a
towards a destination, while the EH-enabled traceroute would provide destination while the EH-enabled traceroute would provide the address
the address of the last-responding node for EH-enabled packets (say, of the last-responding node for EH-enabled packets (say, "M"). In
"M"). In principle, one could isolate the dropping node by looking- principle, one could isolate the dropping node by looking-up "M" in
up "M" in the EH-free traceroute, with the dropping node being "M+1" the EH-free traceroute with the dropping node being "M+1" (see
(see Appendix B.1 for caveats). Appendix B.1 for caveats).
At the time of this writing, most traceroute implementations do not At the time of this writing, most traceroute implementations do not
support IPv6 extension headers. However, the path6 tool [path6] of support IPv6 EHs. However, the path6 tool of [IPv6-Toolkit] provides
[IPv6-Toolkit] provides such support. Additionally, the blackhole6 such support. Additionally, the blackhole6 tool of [IPv6-Toolkit]
tool [blackhole6] of [IPv6-Toolkit] automates the troubleshooting automates the troubleshooting process and can readily provide
process and can readily provide information such as: dropping node's information such as: dropping node's IPv6 address, dropping node's
IPv6 address, dropping node's Autonomous System, etc. AS, etc.
Acknowledgements
The authors would like 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 providing valuable comments on draft versions of this
document. Additionally, the authors would like to thank participants
of the V6OPS and OPSEC working groups for their valuable input on the
topics discussed in this document.
The authors would like to thank Fred Baker for his guidance in
improving this document.
Fernando Gont would like to thank Jan Zorz of Go6 Lab
<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.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks / UTN-FRH SI6 Networks / UTN-FRH
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
skipping to change at page 15, line 4 skipping to change at page 15, line 16
Fernando Gont Fernando Gont
SI6 Networks / UTN-FRH SI6 Networks / UTN-FRH
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: http://www.si6networks.com URI: http://www.si6networks.com
J. Linkova J. Linkova
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
USA United States
Email: furry@google.com Email: furry@google.com
Tim Chown Tim Chown
University of Southampton Jisc
Highfield Lumen House, Library Avenue
Southampton , Hampshire SO17 1BJ Harwell Oxford, Didcot OX11 0SG
United Kingdom United Kingdom
Email: tjc@ecs.soton.ac.uk Email: tim.chown@jisc.ac.uk
Will(Shucheng) Liu Will (Shucheng) Liu
Huawei Technologies Huawei Technologies
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 Shenzhen 518129
P.R. China China
Email: liushucheng@huawei.com Email: liushucheng@huawei.com
 End of changes. 117 change blocks. 
359 lines changed or deleted 315 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/