Internet-Draft JAMES January 2023
Vyncke, et al. Expires 13 July 2023 [Page]
Workgroup:
IPv6 Operations
Internet-Draft:
draft-vyncke-v6ops-james-03
Published:
Intended Status:
Informational
Expires:
Authors:
É. Vyncke
Cisco
R. Léas
Université de Liège
J. Iurman
Université de Liège

Just Another Measurement of Extension header Survivability (JAMES)

Abstract

In 2016, RFC7872 has measured the drop of packets with IPv6 extension headers. This document presents a slightly different methodology with more recent results. It is still work in progress.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://evyncke.github.io/v6ops-james/draft-vyncke-v6ops-james.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-vyncke-v6ops-james/.

Discussion of this document takes place on the IPv6 Operations Working Group mailing list (mailto:v6ops@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/v6ops/.

Source for this draft and an issue tracker can be found at https://github.com/evyncke/v6ops-james.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 13 July 2023.

1. Introduction

In 2016, [RFC7872] has measured the drop of packets with IPv6 extension headers on their transit over the global Internet. This document presents a slightly different methodology with more recent results. Since then, [I-D.draft-ietf-opsec-ipv6-eh-filtering] has provided some recommendations for filtering transit traffic, so there may be some changes in providers policies. Also, [RFC9098] raises awareness about the operational and security implications of IPv6 extension headers and present reasons why some networks would drop them intentionally.

It is still work in progress, but the authors wanted to present some results at IETF-113 (March 2022). The code is open source and is available at [GITHUB].

2. Methodology

In a first phase, the measurement is done between collaborating IPv6 nodes, a.k.a. vantage points, spread over the Internet and multiple Autonomous Systems (ASs). As seen in Section 3.2, the source/destination/transit ASs include some "tier-1" providers per [TIER1], so, they are probably representative of the global Internet core.

Relying on collaborating nodes has some benefits:

  • propagation can be measured even in the absence of any ICMP message or reply generated by the destination;
  • traffic timing can be measured accurately to answer whether extension headers are slower than plain IPv6 packets;
  • traffic can be captured into .pcap [I-D.draft-ietf-opsawg-pcap] file at the source and at the destination for later analysis.

Future phases will send probes to non-collaborating nodes with a much reduced probing speed. The destination will include [ALEXA] top-n websites, popular CDN, as well as random prefix from the IPv6 global routing table. A revision of this IETF draft will describe those experiments.

3. Measurements

3.1. Vantage Points

Several servers were used worldwide. Table 1 lists all the vantage points together with their AS number and country.

Table 1: All vantage AS
ASN AS Name Country code Location
267 NETHER-NET US Southfield, MI
3764 AFRINIC-Ops ZA Johanesburg
4134 Chine Telecom CN Beijing
7195 Edge Uno AR Buenos Aires
12414 NL-SOLCON SOLCON NL Amsterdam
14061 Digital Ocean CA Toronto, ON
14061 Digital Ocean USA New York City, NY
14601 Digital Ocean DE Francfort
14601 Digital Ocean IN Bangalore
14601 Digital Ocean SG Singapore
14601 Digital Ocean UK London
16276 OVH AU Sydney
16276 OVH PL Warsaw
20473 The Constant Company (Vultr) MX Mexico
20473 The Constant Company (Vultr) SP Madrid
20473 The Constant Company (Vultr) JP Tokyo
37684 Angani KE Nairobi
37708 AfriNIC Corporate Network MU Ebene
44684 Mythic Beasts UK Cambridge
60011 MYTHIC-BEASTS-USA US Fremont, CA
198644 GO6 SI Ljubljana

3.2. Tested Autonomous Systems

During first phase (traffic among fully-meshed collaborative nodes), Table 2 show the ASs for which our probes have collected data.

Table 2: All AS (source/destination/transit)
AS Number AS Description Comment
174 COGENT-174, US Tier-1
267 NETHER-NET, US  
1299 TWELVE99 Arelion, fka Telia Carrier, SE Tier-1
2497 IIJ Internet Initiative Japan Inc., JP  
2828 XO-AS15, US Regional Tier
2914 NTT-LTD-2914, US Tier-1
3257 GTT-BACKBONE GTT, US Tier-1
3320 DTAG Internet service provider operations, DE Tier-1
3356 LEVEL3, US Tier-1
3491 BTN-ASN, US Tier-1
4134 CHINANET-BACKBONE No.31,Jin-rong Street, CN Regional Tier
4637 ASN-TELSTRA-GLOBAL Telstra Global, HK Regional Tier
4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP, IN  
4788 TMNET-AS-AP TM Net, Internet Service Provider, MY  
5511 OPENTRANSIT, FR Tier-1
5603 SIOL-NET Telekom Slovenije d.d., SI  
6453 AS6453, US Tier-1
6461 ZAYO-6461 Tier-1
6762 SEABONE-NET TELECOM ITALIA SPARKLE S.p.A., IT Tier-1
6895 ESPANIX Neutral Interconect Exchange for Spain, ES  
6939 HURRICANE, US Regional Tier
7195 EDGEUNO SAS, CO  
8447 A1TELEKOM-AT A1 Telekom Austria AG, AT  
9498 BBIL-AP BHARTI Airtel Ltd., IN  
12129 123NET, US  
12414 NL-SOLCON SOLCON, NL  
14061 DIGITALOCEAN-ASN, US  
14103 ACDNET-ASN1, US  
16276 OVH, FR  
20473 AS-CHOOPA, US  
21283 A1SI-AS A1 Slovenija, SI  
23889 MauritiusTelecom, MU  
33764 AFRINIC-ZA-JNB-AS, MU  
34779 T-2-AS AS set propagated by T-2 d.o.o., SI  
37100 SEACOM-AS, MU  
37271 Workonline  
37684 ANGANI-AS, KE  
37708 AFRINIC-MAIN, MU  
44684 MYTHIC Mythic Beasts Ltd, GB  
58461 CT-HANGZHOU-IDC No.288,Fu-chun Road, CN  
60011 MYTHIC-BEASTS-USA, GB  
198644 GO6, SI  
211722 Nullroute  
328578 KEMNET-TECHNOLOGIES-AS, KE  

The table attributes some tier qualification to some ASs based on the Wikipedia page [TIER1], but there is no common way to decide who is a tier-1. Based on some CAIDA research, all the above (except GO6, which is a stub network) are transit providers.

While this document lists some operators, the intent is not to build a wall of fame or a wall of shame but more to get an idea about which kind of providers drop packets with extension headers and how widespread the drop policy is enforced and where, i.e., in the access provider or in the core of the Internet.

3.2.1. Drop attribution to AS

Comparing the traceroutes with and without extension headers allows the attribution of a packet drop to one AS. But, this is not an easy task as inter-AS links often use IPv6 address of only one AS (if not using link-local per [RFC7404]). This document uses the following algorithm to attribute the drop to one AS for packet sourced in one AS and then having a path traversing AS#foo just before AS#bar:

  • if the packet drop happens at the first router (i.e., hop limit == 1 does not trigger an ICMP hop-limit exceeded), then the drop is assumed to this AS as it is probably an ingress filter on the first router (i.e., the hosting provider in most of the cases - except if collocated with an IXP).
  • if the packet drop happens in AS#foo after one or more hop(s) in AS#bar, then the drop is assumed to be in AS#foo ingress filter on a router with an interface address in AS#foo
  • if the packet drop happens in AS#bar after one or more hop(s) in AS#bar before going to AS#foo, then the drop is assumed to be in AS#foo ingress filter on a router with an interface address in AS#bar

In several cases, the above algorithm was not possible (e.g., some intermediate routers do not generate an ICMP unreachable hop limit exceeded even in the absence of any extension headers), then the drop is not attributed. Please also note that the goal of this document is not to 'point fingers to operators' but more to evaluate the potential impact. I.e., a tier-1 provider dropping packets with extension headers has a much bigger impact on the Internet traffic than an access provider.

Future revision of this document will use the work of [MLAT_PEERING]. Readers are urged not to rely on the AS attribution in this document version.

3.3. Tested Extension Headers

In the first phase among collaborating vantage points, packets always contained either a UDP payload or a TCP payload, the latter is sent with only the SYN flag set and with data as permitted by section 3.4 of [RFC793] (2nd paragraph). A usual traceroute is done with only the UDP/TCP payload without any extension header with varying hop-limit in order to learn the traversed routers and ASs. Then, several UDP/TCP probes are sent with a set of extension headers:

  • hop-by-hop options header containing:

    • one PadN option for a length of 8 octets
    • one unknown option with the "discard" bits for a length of 8 octets
    • one unknown option (two sets: with "discard" and "skip" bits) for a length of 256 and 512 octets

  • destination options header containing:

    • one PadN option for a length of 8 octets
    • one unknown option with the "discard" bits for a length of 8 octets
    • one unknown option (two sets: with "discard" and "skip" bits) for a length of 16, 32, 64, 128, 256, and 512 octets
    • one unknown option (with "skip" bits) for a length of 24, 40, 48, and 56 octets
  • routing header with routing types from 0 to 6 inclusive

  • fragment header of varying frame length 512, 1280, and 1500 octets:

    • atomic fragment (i.e., M-flag = 0 and offset = 0)
    • non-atomic first fragment (i.e., M-flag = 1 and offset = 0)
  • encapsulation security payload (ESP) header with dummy SPI followed by UDP/TCP header and a 38 octets payload
  • authentication header (AH) with dummy SPI followed by UDP/TCP header and a 38 octets payload

In the above, length is the length of the extension header itself except for the fragmentation header where the length is the IP packet length (i.e., including the IPv6, and TCP/UDP headers + payload). Also, an unknown option means an option with an unassigned code in the IANA registry [IANA_IPV6_PARAMS].

For hop-by-hop and destination options headers, the choice was made to use one unknown option instead of multiple consecutive PadN options in order to avoid packets from being discarded on the destination. Indeed, the Linux kernel does not accept consecutive Pad1 or PadN options if their total size exceeds 7 octets. Not only multiple PadN options violate section 2.1.9.5 of [RFC4942], but it is also considered as suspicious (see section 5.3 of [BCP220]). Nevertheless, for comparative purposes, multiple PadN options were used for experiments of length 256 octets. In that very specific case, drops on the destination are not considered as drops.

In addition to the above extension headers, other probes were sent with next header field of IPv6 header set to:

  • 59, which is "no next header", especially whether extra octets after the no next header as section 4.7 [RFC8200] requires that "those octets must be ignored and passed on unchanged if the packet is forwarded"
  • 143, which is Ethernet payload (see section 10.1 of [RFC8986])

4. Results

This section presents the current results out of phase 1 (collaborating vantage points) testing. Probe packets were sent between all pairs of vantage points with a hop-limit from 1 to the number of hops between the two vantage points and for all the extension headers described in Section 3.3.

4.1. Routing Header

Table 3 lists all routing header types and the percentage of experiments that were successful, i.e., packets with routing header reaching their destination, both for UDP and TCP:

Table 3: Per Routing Header Types Transmission
Routing Header Type UDP TCP
0 74.3% 71.2%
1 88.3% 81.4%
2 97.4% 90.4%
3 97.6% 91.3%
4 78.8% 72.6%
5 97.4% 90.9%
6 97.4% 90.0%

Table 4 and Table 5 respectively list ASs that drop packets with the routing header type 0 (the original source routing header, which is now deprecated) and packets with the routing header type 1 (NIMROD [RFC1753], which is now deprecated).

Table 4: ASs dropping Routing Header Type 0
AS Number AS description
1299 TWELVE99 Arelion, fka Telia Carrier, SE
5511 OPENTRANSIT, FR
6895 ESPANIX Neutral Interconect Exchange for Spain, ES
6939 HURRICANE, US
7195 EDGEUNO (DE-CIX Frankfurt)
9498 BBIL-AP BHARTI Airtel Ltd. (Equinix Hong Kong)
14061 DIGITALOCEAN (DE-CIX Frankfurt)
16276 OVH
37684 ANGANI-AS, KE
58461 CT-HANGZHOU-IDC No.288,Fu-chun Road, CN
328578 KEMNET-TECHNOLOGIES-AS, KE
Table 5: ASs dropping Routing Header Type 1
AS Number AS description
1299 TWELVE99 Arelion, fka Telia Carrier, SE
4134 CHINANET-BACKBONE No.31,Jin-rong Street, CN
5511 OPENTRANSIT, FR
37684 ANGANI-AS, KE
58461 CT-HANGZHOU-IDC No.288,Fu-chun Road, CN
328578 KEMNET-TECHNOLOGIES-AS, KE

Regarding the routing type 0, it is possibly due to a strict implementation of [RFC5095] but it is expected that no packet with such routing type would be transmitted anymore. So, this is not surprising. The same reasoning could be applied to the routing type 1.

Table 6 lists ASs that drop packets with the routing header type 4 (Segment Routing Header [RFC8754]).

Table 6: ASs dropping Routing Header Type 4
AS Number AS description
1299 TWELVE99 Arelion, fka Telia Carrier, SE
4637 ASN-TELSTRA-GLOBAL Telstra Global, HK
5511 OPENTRANSIT, FR
6939 HURRICANE, US
7195 EDGEUNO SAS, CO
14061 DIGITALOCEAN-ASN, US
16276 OVH, FR
37100 SEACOM-AS, MU
58461 CT-HANGZHOU-IDC No.288,Fu-chun Road, CN

This drop of SRH was to be expected as SRv6 is specified to run only in a limited domain.

Other routing header types (2 == mobile IPv6 [RFC6275], 3 == RPL [RFC6554], and even 5 == CRH-16 and 6 == CRH-32[I-D.draft-bonica-6man-comp-rtg-hdr]) can be transmitted over the global Internet without being dropped (assuming that the 2.5% of dropped packets are within the measurement error). At least, this is true for UDP. We still need to investigate the differences for TCP equivalent transmissions.

4.2. Hop-by-Hop Options Header

Table 7 lists all experiments (types and lengths) along with their success percentages, i.e., packets with a hop-by-hop header reaching their destination, both for UDP and TCP:

Table 7: Hop-by-hop Header Transmission
Option Type Length (bytes) UDP TCP
Skip 8 8.6% 9.1%
Discard 8 0.0% 0.0%
Skip 256 2.4% 2.4%
Skip w/ PadN 256 0.5% 0.6%
Discard 256 0.0% 0.0%
Skip 512 1.4% 1.5%
Discard 512 0.0% 0.0%

It appears that hop-by-hop options headers cannot reliably traverse the global Internet; only small headers with 'skipable' options have some chances. If the unknown hop-by-hop option has the 'discard' bits, it is dropped per specification, although we observed in some cases that such packets were not necessarily dropped directly by the very first hop. Globally, there are no notable differences between UDP and TCP.

4.3. Destination Options Header

Table 8 lists all lengths that have been tested along with their success percentages, i.e., packets with a destination header reaching their destination, both for UDP and TCP:

Table 8: Destination Header Transmission
Length (bytes) UDP TCP
8 97.8% 94.3%
16 97.7% 90.5%
24 97.6% 89.8%
32 93.5% 86.2%
40 93.9% 86.2%
48 93.7% 86.1%
56 93.8% 52.7%
64 45.9% 37.8%
128 10.9% 10.9%
256 4.3% 4.3%
256 w/ PadN 4.3% 4.3%
512 3.1% 3.1%

The measurement revealed no difference with the discard bits, which tends to show that routers do not look inside the destination header, as expected.

The size of the destination options header has a major impact on the drop probability. It appears that destination headers larger than 24 octets already cause drops. It may be because the 40 octets of the IPv6 header + the 24 octets of the extension header (total 64 octets) is still in the limits of some router hardware lookup mechanisms while the next measured size (extension header size of 32 octets for a total of 72 octets) is beyond the hardware limit and some ASs have a policy to drop packets where the TCP/UDP ports are unknown. A major drop also occurs once the size reaches 64 bytes for UDP while, surprisingly, it happens at 56 bytes for TCP. In either case, the chances of surviving are approximately halved. We still need to investigate the differences for TCP equivalent transmissions.

4.4. Fragmentation Header

The propagation of two kinds of fragmentation headers was analysed: atomic fragment (offset == 0 and M-flag == 0) and plain first fragment (offset == 0 and M-flag == 1). The Table 9 displays the propagation differences.

Table 9: IPv6 Fragments Transmission
M-flag UDP TCP
0 (atomic) 55.8% 49.8%
1 89.2% 87.6%

The size of the overall IPv6 packets (512, 1280, and 1500 octets) has no major impact on the propagation.

4.5. No extension headers drop at all

Table 10 lists ASs that do not drop transit traffic with extension headers and therefore follow the recommendations of [I-D.draft-ietf-opsec-ipv6-eh-filtering]:

Table 10: ASs not dropping packets with Extension Headers
AS Number AS Description
267 NETHER-NET, US
2497 IIJ Internet Initiative Japan Inc., JP
14103 ACDNET-ASN1, US
21283 A1SI-AS A1 Slovenija, SI
33764 AFRINIC-ZA-JNB-AS, MU
37271 Workonline
37708 AFRINIC-MAIN, MU
60011 MYTHIC-BEASTS-USA, GB
198644 GO6, SI

4.6. Other Next Headers

Measurements also include two protocol numbers that are mainly new use of IPv6 as well as AH and ESP. Table 11 indicates the percentage of packets reaching the destination.

Table 11: Transmission of Special IP Protocols
Next Header Transmission
NoNextHeader (59) 98.2%
Ethernet (143) 98.3%
Authentication (AH) 98.1%
ESP 98.3%

The above indicates that those IP protocols can be transmitted over the global Internet without being dropped (assuming that the 2% of dropped packets are within the measurement error). Globally, there are no notable differences between UDP and TCP, for cases where it applies.

5. Summary of the collaborating parties measurements

While the analysis has areas of improvement (geographical distribution and impact on latency), it appears that:

  • AH, ESP, and non-atomic fragmentation headers (to some extent) can traverse the Internet;
  • only routing headers types 0, 1 and 4 experiment problems over the Internet, other types have no problems;
  • hop-by-hop options headers do not traverse the Internet, whatever the size;
  • destination options headers are not reliable enough when it exceeds 24 octets.

Of course, the next phase of measurement with non-collaborating parties will probably give another view.

6. Security Considerations

While active probing of the Internet may be considered as an attack, this measurement was done among collaborating parties and using the probe attribution technique described in [I-D.draft-vyncke-opsec-probe-attribution] to allow external parties to identify the source of the probes if required.

7. IANA Considerations

This document has no IANA actions.

8. References

8.1. Normative References

[IANA_IPV6_PARAMS]
"Internet Protocol Version 6 (IPv6) Parameters, Destination Options and Hop-by-Hop Options", n.d., <https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2>.
[RFC793]
Postel, J., "Transmission Control Protocol", RFC 793, DOI 10.17487/RFC0793, , <https://doi.org/10.17487/RFC0793>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://doi.org/10.17487/RFC8200>.

8.2. Informative References

[ALEXA]
"The top 500 sites on the web", n.d., <https://www.alexa.com/topsites>.
[BCP220]
Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, .
<https://www.rfc-editor.org/info/bcp220>
[GITHUB]
Léas, R., "james", n.d., <https://gitlab.uliege.be/Benoit.Donnet/james>.
[I-D.draft-bonica-6man-comp-rtg-hdr]
Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. Jalil, "The IPv6 Compact Routing Header (CRH)", Work in Progress, Internet-Draft, draft-bonica-6man-comp-rtg-hdr-29, , <https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr-29>.
[I-D.draft-ietf-opsawg-pcap]
Harris, G. and M. Richardson, "PCAP Capture File Format", Work in Progress, Internet-Draft, draft-ietf-opsawg-pcap-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-pcap-01>.
[I-D.draft-ietf-opsec-ipv6-eh-filtering]
Gont, F. and W. S. LIU, "Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers", Work in Progress, Internet-Draft, draft-ietf-opsec-ipv6-eh-filtering-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-eh-filtering-10>.
[I-D.draft-vyncke-opsec-probe-attribution]
Vyncke, E., Donnet, B., and J. Iurman, "Attribution of Internet Probes", Work in Progress, Internet-Draft, draft-vyncke-opsec-probe-attribution-01, , <https://datatracker.ietf.org/doc/html/draft-vyncke-opsec-probe-attribution-01>.
[MLAT_PEERING]
Giotsas, V., Zhou, S., Luckie, M., and K. Claffy, "Inferring Multilateral Peering", DOI 10.1145/2535372.2535390, , <https://catalog.caida.org/details/paper/2013_inferring_multilateral_peering/>.
[RFC1753]
Chiappa, N., "IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture", RFC 1753, DOI 10.17487/RFC1753, , <https://doi.org/10.17487/RFC1753>.
[RFC4942]
Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", RFC 4942, DOI 10.17487/RFC4942, , <https://doi.org/10.17487/RFC4942>.
[RFC5095]
Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, , <https://doi.org/10.17487/RFC5095>.
[RFC6275]
Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, , <https://doi.org/10.17487/RFC6275>.
[RFC6554]
Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, , <https://doi.org/10.17487/RFC6554>.
[RFC7404]
Behringer, M. and E. Vyncke, "Using Only Link-Local Addressing inside an IPv6 Network", RFC 7404, DOI 10.17487/RFC7404, , <https://doi.org/10.17487/RFC7404>.
[RFC7872]
Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, , <https://doi.org/10.17487/RFC7872>.
[RFC8754]
Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, , <https://doi.org/10.17487/RFC8754>.
[RFC8986]
Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, , <https://doi.org/10.17487/RFC8986>.
[RFC9098]
Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, G., and W. Liu, "Operational Implications of IPv6 Packets with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, , <https://doi.org/10.17487/RFC9098>.
[TIER1]
"Tier 1 network", n.d., <https://en.wikipedia.org/wiki/Tier_1_network>.

Acknowledgments

The authors want to thank AfriNIC, Angani, China Telecom, Jared Mauch, Sander Steffann, XiPeng Xiao, and Jan Zorz for allowing the free use of their labs. Other thanks to Ben Campbell and Fernando Gont who indicated a nice IPv6 hosting provider in Africa and South America.

Special thanks as well to Professor Benoit Donnet for his support and advices. This document would not have existed without his support.

Authors' Addresses

Éric Vyncke
Cisco
De Kleetlaan 64
1831 Diegem
Belgium
Raphaël Léas
Université de Liège
Liege
Belgium
Justin Iurman
Université de Liège
Institut Montefiore B28
Allee de la Decouverte 10
4000 Liege
Belgium