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
        
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

真实世界中IPv6扩展头数据包丢弃的观察

Abstract

摘要

This 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.

本文档提供了关于在互联网上丢弃带有IPv6扩展头(EHs)的数据包的程度的真实数据(最初在2014年8月和2015年6月进行了测量,结果类似),以及此类丢弃在网络中发生的位置。上述结果作为一个问题陈述,预计将触发有关过滤承载IPv6 EHs的IPv6数据包的操作建议,以便随着时间的推移情况得到改善。本文档还解释了如何获得结果,以便社区的其他成员可以复制相应的测量结果,并随着时间的推移重复测量,以观察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.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 7841第2节。

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.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问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.

版权所有(c)2016 IETF信托基金和确定为文件作者的人员。版权所有。

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.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

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  . . . . . . . . . . . . . . . . . . . . . . . .   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
1. 介绍

IPv6 Extension Headers (EHs) allow for the extension of the IPv6 protocol and provide support for core functionality such as IPv6 fragmentation. While packets employing IPv6 EHs have been suspected to be dropped in some IPv6 deployments, there was not much concrete data on the topic. Some preliminary measurements have been presented in [PMTUD-Blackholes], [Gont-IEPG88], and [Gont-Chown-IEPG89], whereas [Linkova-Gont-IEPG90] presents more comprehensive results on which this document is based.

IPv6扩展头(EHs)允许扩展IPv6协议,并支持IPv6分段等核心功能。虽然有人怀疑在某些IPv6部署中丢弃了使用IPv6 EHs的数据包,但关于该主题的具体数据并不多。[PMTUD黑洞]、[Gont-IEPG88]和[Gont-Chown-IEPG89]中介绍了一些初步测量结果,而[Linkova-Gont-IEPG90]则介绍了本文件所依据的更全面的结果。

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.

本文档提供了关于包含IPv6 EHs的数据包在互联网上被丢弃的程度的真实数据,2014年8月和2015年6月晚些时候进行了测量,结果类似(该领域的操作建议待定)。本文档中的结果表明,在执行相应测量的场景中,使用IPv6 EHs可能导致数据包丢失。我们特别注意到,在传输网络上发生的数据包丢失是不可取的,希望并期望这种情况会随着时间的推移而改善。

2. Support of IPv6 Extension Headers in the Internet
2. 在Internet上支持IPv6扩展头

This section summarizes the results obtained when measuring the support of IPv6 EHs on the path towards different types of public IPv6 servers. Two sources of information were employed for the list of public IPv6 servers: the "World IPv6 Launch" site <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:

本节总结了在测量通向不同类型公共IPv6服务器的路径上对IPv6 EHs的支持时获得的结果。公共IPv6服务器列表采用了两种信息来源:“世界IPv6发布”站点<http://www.worldipv6launch.org>以及Alexa的前100万网站列表<http://www.alexa.com>. 对于每个域名列表,获得了以下数据集:

o Web servers (AAAA records of the aforementioned list)

o Web服务器(上述列表的AAAA记录)

o Mail servers (MX -> AAAA records of the aforementioned list)

o 邮件服务器(上述列表的MX->AAAA记录)

o Name servers (NS -> AAAA records of the aforementioned list)

o 名称服务器(上述列表的NS->AAAA记录)

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).

在获得本文档中包含的结果之前,已从每个列表中删除重复地址和除全局单播地址以外的IPv6地址。此外,发现无法访问的地址将从数据集中丢弃(有关更多详细信息,请参阅附录B)。

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 目标选项报头为8字节的IPv6数据包;

o IPv6 packets resulting in two IPv6 fragments of 512 bytes each (approximately); and

o IPv6数据包产生两个分别为512字节的IPv6片段(大约);和

o IPv6 packets with a Hop-by-Hop Options header of 8 bytes.

o 具有8字节逐跳选项标头的IPv6数据包。

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.

对于具有目的地选项报头的数据包和具有逐跳选项报头的数据包,通过PadN选项[RFC2460]实现所需的EH大小。在所有情况下,探测数据包的上层协议都是TCP[RFC793],目标端口设置为相应数据集的服务端口[IANA-Port-NUMBERS]。例如,涉及web服务器的所有测量的探测数据包都是目标端口设置为80的TCP段。

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.

除了在使用上述IPv6 EHs时获得丢包率外,我们还试图确定丢包的自治系统(AS)是否与目的地/目标地址的AS相同。这是特别令人感兴趣的,因为它本质上揭示了分组丢弃是否在分组的预定目的地的控制下。由目的地AS丢弃的分组不那么令人担忧,因为丢弃分组的设备在与分组目的地相同的组织的控制下(因此,如果认为必要,更新过滤策略可能更容易)。另一方面,传输ASE丢弃的数据包更令人担忧,因为它们会影响第三方(目的地AS)对IPv6 EHs(包括IPv6碎片)的可部署性和可用性。在任何情况下,我们都注意到,在带有EHs的IPv6数据包被丢弃的情况下,无法判断数据包丢弃是否是明确和预期策略的结果,或者是不正确的设备配置默认值、错误设备等的结果。因此,在目的地发生的数据包丢弃可能仍然存在问题。

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).

由于在识别特定路由器所属的AS时存在一些模糊性(见附录B.2),我们的每个测量结果都有两个不同的值:一个对应于“最佳情况场景”,另一个对应于“最坏情况场景”。“最佳情况场景”是指当存在疑问时,假设目的地AS丢弃数据包,而“最坏情况场景”是指当存在疑问时,假设传输AS丢弃数据包(详情请参见附录B.2)。在下表中,括号内显示的值表示数据包丢弃时,数据包丢弃发生在目的地AS以外的AS中的可能性(考虑到最佳情况和最坏情况)。

   +----------+------------------+------------------+------------------+
   | 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%)  |
   +----------+------------------+------------------+------------------+
        
   +----------+------------------+------------------+------------------+
   | 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

表1:WIPv6LD数据集:不同目的地类型的数据包丢弃率,以及在不同目的地类型中丢弃的数据包的估计(最佳情况/最坏情况)百分比

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".

注:在上下表中,“HBH8”代表“具有8字节逐跳选项扩展头的数据包”,“DO8”代表“具有8字节目标选项扩展头的数据包”,“FH512”代表“具有512字节片段头的IPv6数据包”。

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".

注意:作为一个例子,我们注意到描述对web服务器使用DO8支持IPv6数据包(包含值“11.88%(17.60%/20.80%))的单元格应理解为:“当使用DO8向公共web服务器发送IPv6数据包时,11.88%的数据包被丢弃。在丢弃的数据包中,17.60%/20.80%(最佳情况/最坏情况)他们中的大多数人在目的地以外的其他地方被丢弃。

   +----------+------------------+------------------+------------------+
   | 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%)  |
   +----------+------------------+------------------+------------------+
        
   +----------+------------------+------------------+------------------+
   | 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

表2:Alexa的前1M站点数据集:不同目的地类型的数据包丢弃率,以及在不同目的地类型中丢弃的数据包的估计(最佳情况/最坏情况)百分比

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.

根据上述结果,需要进行一些观察。首先,虽然一般认为是IPv6片段被运营商丢弃,但我们的结果表明,通常是IPv6 EHs导致数据包丢弃。其次,我们的结果表明,这种数据包丢失的很大一部分发生在传输过程中;也就是说,分组丢弃不受与最终目的地相同的组织的控制。

3. Security Considerations
3. 安全考虑

This document presents real-world data regarding the extent to which IPv6 packets employing EHs are dropped in the Internet. As such, this document does not introduce any new security issues.

本文档提供了有关使用EHs的IPv6数据包在Internet上丢弃的程度的真实数据。因此,本文件不会引入任何新的安全问题。

4. References
4. 工具书类
4.1. Normative References
4.1. 规范性引用文件

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

[RFC793]Postel,J.,“传输控制协议”,标准7,RFC 793,DOI 10.17487/RFC0793,1981年9月<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>.

[RFC2460]Deering,S.和R.Hinden,“互联网协议,第6版(IPv6)规范”,RFC 2460,DOI 10.17487/RFC2460,1998年12月<http://www.rfc-editor.org/info/rfc2460>.

4.2. Informative References
4.2. 资料性引用

[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-Chown-IEPG89]Gont,F.和T.Chown,“IPv6扩展头使用的小更新”,IEPG在IETF 89之前的会议,2014年3月<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>.

[Gont-IEPG88]Gont,F.,“IPv6互联网中的碎片和扩展头支持”,IEPG在IETF 88之前的会议,2013年11月<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>.

[IANA-PORT-NUMBERS]IANA,“服务名称和传输协议端口号注册表”<http://www.iana.org/assignments/ 服务名称端口号>。

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

[IPv6工具包]SI6网络,“SI6网络的IPv6工具包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>.

[Linkova-Gont-IEPG90]Linkova,J.和F.Gont,“现实世界中的IPv6扩展头v2.0”,IEPG在IETF 90之前的会议,2014年7月<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>.

[PMTUD黑洞]De Boer,M.和J.Bosma,“使用成熟的Atlas在互联网上发现路径MTU黑洞”,2012年7月<http://www.nlnetlabs.nl/downloads/publications/ pmtu黑洞理学硕士论文.pdf>。

Appendix A. Reproducing Our Experiment
附录A.复制我们的实验

This section describes, step by step, how to reproduce the experiment with which we obtained the results presented in this document. Each subsection represents one step in the experiment. The tools employed for the experiment are traditional UNIX-like tools (such as gunzip) and the SI6 Networks' IPv6 Toolkit v2.0 (Guille) [IPv6-Toolkit].

本节将一步一步地描述如何重现我们获得本文中所述结果的实验。每个小节代表实验中的一个步骤。实验使用的工具是传统的类UNIX工具(如gunzip)和SI6 Networks的IPv6工具包v2.0(Guille)[IPv6工具包]。

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. 获取域名列表
   The primary data source employed 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.  The aforementioned
   file can be extracted with
        
   The primary data source employed 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.  The aforementioned
   file can be extracted with
        

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

$ 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]:

可使用以下命令[IPv6 Toolkit]获取域名列表(即,去除其他数据):

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

$ cat top-1m.csv | script6获取alexa域>top-1m.txt

This command will create a "top-1m.txt" file containing one domain name per line.

此命令将创建一个“top-1m.txt”文件,每行包含一个域名。

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.

注:WIPv6LD数据集对应的域名可在<http://www.si6networks.com/datasets/wipv6day-domains.txt>. 由于相应的文件是每行包含一个域名的文本文件,因此不需要执行本小节中产生的步骤。从附录A.2开始,WIPv6LD数据集的处理方式应与Alexa数据集相同。

A.2. Obtaining AAAA Resource Records
A.2. 获取AAAA资源记录

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 can be obtained with:

在上一小节中获得的文件包含与网站相对应的域名列表。此类域名的AAAA记录可通过以下方式获得:

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

$ cat top-1m.txt |脚本6获取aaaa>top-1m-web-aaaa.txt

The AAAA records corresponding to the mail servers of each of the aforementioned domain names can be obtained with:

上述每个域名的邮件服务器对应的AAAA记录可通过以下方式获得:

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

$ cat top-1m.txt | script6获取mx | script6获取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:

与上述每个域名的名称服务器对应的AAAA记录可以通过以下方式获得:

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

$ cat top-1m.txt |脚本6获取ns |脚本6获取aaaa>top-1m-dns-aaaa.txt

A.3. Filtering the IPv6 Address Datasets
A.3. 过滤IPv6地址数据集

The lists of IPv6 addresses obtained in the previous step could possibly contain undesired addresses (e.g., non-global unicast addresses) and/or duplicate addresses. In order to remove both undesired and duplicate addresses, each of the three files from the previous section should be filtered accordingly:

在前一步骤中获得的IPv6地址列表可能包含不需要的地址(例如,非全局单播地址)和/或重复地址。为了删除不需要的和重复的地址,应相应地过滤上一节中的三个文件:

   $ cat top-1m-web-aaaa.txt | addr6 -i -q -B multicast -B unspec -k
   global > top-1m-web-aaaa-unique.txt
        
   $ 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-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
        
   $ 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. 对每个IPv6地址数据集执行测量
A.4.1. Measurements with Web Servers
A.4.1. 使用Web服务器进行测量

In order to measure DO8 with the list of web servers:

要使用web服务器列表测量DO8:

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

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

In order to measure HBH8 with the list of web servers:

为了使用web服务器列表测量HBH8:

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

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

In order to measure FH512 with the list of web servers:

为了使用web服务器列表测量FH512:

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

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

A.4.2. Measurements with Mail Servers
A.4.2. 邮件服务器的测量

In order to measure DO8 with the list of mail servers:

要使用邮件服务器列表测量DO8,请执行以下操作:

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

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

In order to measure HBH8 with the list of mail servers:

要使用邮件服务器列表测量HBH8:

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

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

In order to measure FH512 with the list of mail servers:

为了使用邮件服务器列表测量FH512:

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

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

A.4.3. Measurements with Name Servers
A.4.3. 使用名称服务器进行测量

In order to measure DO8 with the list of name servers:

要使用名称服务器列表测量DO8:

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

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

In order to measure HBH8 with the list of name servers:

要使用名称服务器列表测量HBH8:

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

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

In order to measure FH512 with the list of name servers:

为了使用名称服务器列表测量FH512:

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

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

A.5. Obtaining Statistics from Our Measurements
A.5. 从我们的测量中获得统计数据
A.5.1. Statistics for Web Servers
A.5.1. 网络服务器的统计数据

In order to compute the statistics corresponding to our measurements of DO8 with the list of web servers:

为了使用web服务器列表计算与我们的DO8测量值相对应的统计数据:

$ 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 of HBH8 with the list of web servers:

为了使用web服务器列表计算与我们的HBH8测量值相对应的统计数据:

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

$ 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:

为了使用web服务器列表计算与我们对FH512的测量相对应的统计数据:

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

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

A.5.2. Statistics for Mail Servers
A.5.2. 邮件服务器的统计信息

In order to compute the statistics corresponding to our measurements of DO8 with the list of mail servers:

为了使用邮件服务器列表计算与我们的DO8测量值相对应的统计数据:

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

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

In order to compute the statistics corresponding to our measurements of HBH8 with the list of mail servers:

为了使用邮件服务器列表计算与我们测量的HBH8相对应的统计数据:

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

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

In order to compute the statistics corresponding to our measurements of FH512 with the list of mail servers:

为了使用邮件服务器列表计算与我们对FH512的测量相对应的统计数据:

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

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

A.5.3. Statistics for Name Servers
A.5.3. 名称服务器的统计信息

In order to compute the statistics corresponding to our measurements of DO8 with the list of name servers:

为了使用名称服务器列表计算与我们的DO8测量值相对应的统计数据:

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

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

In order to compute the statistics corresponding to our measurements of HBH8 with the list of mail servers:

为了使用邮件服务器列表计算与我们测量的HBH8相对应的统计数据:

$ 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 of FH512 with the list of mail servers:

为了使用邮件服务器列表计算与我们对FH512的测量相对应的统计数据:

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

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

Appendix B. Measurements Caveats
附录B.测量注意事项

A number of issues have needed some consideration when producing the results presented in this document. These same issues should be considered when troubleshooting connectivity problems resulting from the use of IPv6 EHs.

在产生本文件中提出的结果时,需要考虑一些问题。在对使用IPv6 EHs导致的连接问题进行故障排除时,应考虑这些问题。

B.1. Isolating the Dropping Node
B.1. 隔离丢弃节点

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 that the output of running traceroute towards such destination is:

假设我们发现带有EHs的IPv6数据包正在被丢弃到目标系统2001:db8:d::1的途中,并且向该目标运行跟踪路由的输出为:

      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
        
      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
        

Additionally, let us assume that the output of EH-enabled traceroute to the same destination is:

此外,我们假设到同一目的地的EH启用跟踪路由的输出为:

      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
        
      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
        

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". Assuming that packets in both traceroutes employ the same path, we'll refer to "the node following the last responding node in the EH-enabled traceroute" ("2001:db8:4:1000::1" in our case), as "M+1", etc.

为了简洁起见,让我们将启用EH的跟踪路由中的最后一个响应节点(本例中为“2001:db8:4:4000::1”)称为“M”。假设两个跟踪路由中的数据包使用相同的路径,我们将“启用EH的跟踪路由中最后一个响应节点后面的节点”(在我们的例子中为“2001:db8:4:1000::1”)称为“M+1”,等等。

Based on traceroute information above, which node is the one actually dropping the EH-enabled packets will depend on whether the dropping node filters packets before making the forwarding decision or after

根据上述跟踪路由信息,哪个节点是实际丢弃启用EH的数据包的节点将取决于丢弃节点是在做出转发决策之前还是之后过滤数据包

making the forwarding decision. If the former, the dropping node will be M+1. If the latter, the dropping node will be "M".

做出转发决定。如果是前者,则丢弃节点为M+1。如果是后者,则丢弃节点将为“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").

在本文档中(以及我们的测量),我们假设那些丢弃带有IPv6 EHs的数据包的节点应用其过滤策略,并且只有在必要时才转发数据包。因此,在上面的示例中,对启用EH的跟踪路由(“M”)的最后一个响应节点是“2001:db8:4:4000::1”,我们假设丢弃节点是“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.

此外,我们注意到,在隔离丢弃节点时,我们假设启用EH和不启用EH的跟踪路由都会产生相同的路径。然而,情况可能并非如此。

B.2. Obtaining the Responsible Organization for the Packet Drops
B.2. 获取数据包丢弃的负责组织

In order to identify the organization operating the dropping node, one would be tempted to lookup the Autonomous System Numbers (ASNs) corresponding to the dropping node. However, assuming that M and M+1 are two peering routers, any of these two organizations could be providing the address space employed for such peering. Or, in the case of an Internet Exchange Point (IXP), the address space could correspond to the IXP AS rather than to any of the participating ASes. Thus, the organization operating the dropping node (M+1) could be the AS for M+1, but it might as well be the AS for M+2. Only when the ASN for M+1 is the same as the ASN for M+2 do we have certainty about who the responsible organization for the packet drops is (see slides 21-23 of [Linkova-Gont-IEPG90]).

为了识别操作丢弃节点的组织,人们可能会查找与丢弃节点对应的自治系统编号(ASN)。然而,假设M和M+1是两个对等路由器,这两个组织中的任何一个都可以提供用于这种对等的地址空间。或者,在因特网交换点(IXP)的情况下,地址空间可以对应于IXP AS而不是任何参与ase。因此,操作丢弃节点(M+1)的组织可以是M+1的AS,但也可以是M+2的AS。只有当M+1的ASN与M+2的ASN相同时,我们才能确定谁是负责丢包的组织(见[Linkova-Gont-IEPG90]的幻灯片21-23)。

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.

在第2节中给出的测量结果中,上述模糊性导致“最佳情况”和“最坏情况”场景(而不是单个值):最低百分比值意味着,当有疑问时,我们假设数据包丢弃与目的地发生在同一位置;另一方面,最大的百分比值意味着,当有疑问时,我们假设数据包丢弃发生在与目的地AS不同的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.

我们注意到,在对IPv6数据包丢失进行故障排除和报告时,还应考虑上述模糊性,因为确定负责数据包丢失的组织可能是一项非常重要的任务。

Finally, we note that a specific organization might be operating more than one AS. However, our measurements assume that different ASNs imply different organizations.

最后,我们注意到,一个特定的组织可能作为一个或多个成员运行。然而,我们的测量假设不同的ASN意味着不同的组织。

Appendix C. Troubleshooting Packet Drops Due to IPv6 Extension Headers
附录C.IPv6扩展头导致数据包丢失的故障排除

Isolating IPv6 blackholes essentially involves performing IPv6 traceroute for a destination system with and without IPv6 EHs. The EH-free traceroute would provide the full working path towards a destination while the EH-enabled traceroute would provide the address of the last-responding node for EH-enabled packets (say, "M"). In principle, one could 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 caveats).

隔离IPv6黑洞本质上涉及到为有IPv6 EHs和无IPv6 EHs的目标系统执行IPv6跟踪路由。EH-free跟踪路由将提供通向目的地的完整工作路径,而EH-enabled跟踪路由将为EH-enabled数据包(例如,“M”)提供最后一个响应节点的地址。原则上,可以通过查找无EH追踪路由中的“M”来隔离掉站节点,掉站节点为“M+1”(注意事项见附录B.1)。

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.

在撰写本文时,大多数跟踪路由实现都不支持IPv6 EHs。然而,[IPv6 Toolkit]的path6工具提供了这种支持。此外,[IPv6 Toolkit]的blackhole6工具自动化了故障排除过程,并可随时提供诸如:删除节点的IPv6地址、删除节点的as等信息。

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.

作者要感谢(按字母顺序排列)米凯尔·亚伯拉罕·安德森、马克·安德鲁斯、弗雷德·贝克、布赖恩·卡彭特、格特·多林、C.M.赫德、尼克·希利亚德、乔尔·杰格利、塔图亚·金美、梅里克·卡奥、沃伦·库马里、特德·莱蒙、马克·史密斯、奥勒·特隆和埃里克·温克,感谢他们对本文件草案提出了宝贵的意见。此外,作者还要感谢V6OPS和OPSEC工作组的参与者就本文件中讨论的主题提供了宝贵的意见。

The authors would like to thank Fred Baker for his guidance in improving this document.

作者要感谢Fred Baker在改进本文件方面的指导。

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.

费尔南多·冈特要感谢Go6实验室的扬·佐尔兹<http://go6lab.si/>以及美国NTT公司的Jared Mauch,以提供对用于产生本文所述一些测量结果的系统和网络的访问。此外,他还要感谢SixXS<https://www.sixxs.net>用于提供IPv6连接。

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

Fernando Gont SI6 Networks/UTN-FRH Evaristo Carriego 2644 Haedo,布宜诺斯艾利斯省1706阿根廷

   Phone: +54 11 4650 8472
   Email: fgont@si6networks.com
   URI:   http://www.si6networks.com
        
   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

J.林科娃谷歌1600圆形剧场公园道山景,加利福尼亚州94043

   Email: furry@google.com
        
   Email: furry@google.com
        

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

Tim Chown Jisc Lumen House,牛津哈维尔图书馆大道,英国迪科特OX11 0SG

   Email: tim.chown@jisc.ac.uk
        
   Email: tim.chown@jisc.ac.uk
        

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

威尔(舒城)刘华威科技有限公司深圳市龙岗区坂田518129

   Email: liushucheng@huawei.com
        
   Email: liushucheng@huawei.com