< draft-vyncke-v6ops-james-00.txt   draft-vyncke-v6ops-james-01.txt >
IPv6 Operations E. Vyncke IPv6 Operations É. Vyncke
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational R. Léas Intended status: Informational R. Léas
Expires: 5 September 2022 J. Iurman Expires: 21 September 2022 J. Iurman
Université de Liège Université de Liège
4 March 2022 20 March 2022
Just Another Measurement of Extension header Survivability (JAMES) Just Another Measurement of Extension header Survivability (JAMES)
draft-vyncke-v6ops-james-00 draft-vyncke-v6ops-james-01
Abstract Abstract
In 2016, [RFC7872] has measured the drop of packets with IPv6 In 2016, RFC7872 has measured the drop of packets with IPv6 extension
extension headers. This document presents a slightly different headers. This document presents a slightly different methodology
methodology with more recent results. It is still work in progress. with more recent results. It is still work in progress.
About This Document About This Document
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at The latest revision of this draft can be found at
https://evyncke.github.io/v6ops-james/draft-vyncke-v6ops-james.html. https://evyncke.github.io/v6ops-james/draft-vyncke-v6ops-james.html.
Status information for this document may be found at Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-vyncke-v6ops-james/. https://datatracker.ietf.org/doc/draft-vyncke-v6ops-james/.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 September 2022. This Internet-Draft will expire on 21 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Vantage Points . . . . . . . . . . . . . . . . . . . . . 3 3.1. Vantage Points . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Tested Autonomous Systems . . . . . . . . . . . . . . 4 3.2. Tested Autonomous Systems . . . . . . . . . . . . . . . . 4
3.1.2. Tested Extension Headers . . . . . . . . . . . . . . 6 3.2.1. Drop attribution to AS . . . . . . . . . . . . . . . 6
3.1.3. Drop attribution to AS . . . . . . . . . . . . . . . 7 3.3. Tested Extension Headers . . . . . . . . . . . . . . . . 7
3.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Routing Header . . . . . . . . . . . . . . . . . . . 8 4.1. Routing Header . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Hop-by-Hop Options Headers . . . . . . . . . . . . . 9 4.2. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 9
3.2.3. Destination Options Headers . . . . . . . . . . . . . 10 4.3. Destination Options Header . . . . . . . . . . . . . . . 10
3.2.4. Fragmentation Header . . . . . . . . . . . . . . . . 11 4.4. Fragmentation Header . . . . . . . . . . . . . . . . . . 11
3.2.5. No drop at all . . . . . . . . . . . . . . . . . . . 11 4.5. No extension headers drop at all . . . . . . . . . . . . 12
3.3. Summary of the collaborating parties measurements . . . . 12 4.6. Special Next Headers . . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Summary of the collaborating parties measurements . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. Normative References . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Informative References . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
In 2016, [RFC7872] has measured the drop of packets with IPv6 In 2016, [RFC7872] has measured the drop of packets with IPv6
extension headers on their transit over the global Internet. This extension headers on their transit over the global Internet. This
document presents a slightly different methodology with more recent document presents a slightly different methodology with more recent
results. Since then, [I-D.draft-ietf-opsec-ipv6-eh-filtering] has results. Since then, [I-D.draft-ietf-opsec-ipv6-eh-filtering] has
provided some recommendations for filtering transit traffic, there provided some recommendations for filtering transit traffic, so there
may be some changes in providers policies. may be some changes in providers policies.
It is still work in progress, but the authors wanted to present some It is still work in progress, but the authors wanted to present some
results at IETF-113 (March 2022). results at IETF-113 (March 2022). The code is open source and is
available at [GITHUB].
2. Methodology 2. Methodology
In a first phase, the measurement is done between collaborating IPv6 In a first phase, the measurement is done between collaborating IPv6
nodes, a.k.a. vantage points, spread over the Internet and multiple nodes, a.k.a. vantage points, spread over the Internet and multiple
Autonomous Systems (ASs). As seen in Section 3.1.1, the Autonomous Systems (ASs). As seen in Section 3.2, the
source/destination/transit ASs include some "tier-1" providers per source/destination/transit ASs include some "tier-1" providers per
[TIER1], so, they are probably representative of the global Internet [TIER1], so, they are probably representative of the global Internet
core. core.
Relying on collaborating nodes has some benefits: Relying on collaborating nodes has some benefits:
* propagation can be measured even in the absence of any ICMP * propagation can be measured even in the absence of any ICMP
message or reply generated by the destination; message or reply generated by the destination;
* traffic timing can be measured accurately to answer whether * traffic timing can be measured accurately to answer whether
skipping to change at page 3, line 39 skipping to change at page 3, line 49
reduced probing speed. The destination will include [ALEXA] top-n reduced probing speed. The destination will include [ALEXA] top-n
websites, popular CDN, as well as random prefix from the IPv6 global websites, popular CDN, as well as random prefix from the IPv6 global
routing table. A revision of this IETF draft will describe those routing table. A revision of this IETF draft will describe those
experiments. experiments.
3. Measurements 3. Measurements
3.1. Vantage Points 3.1. Vantage Points
Several servers were used worldwide (albeit missing Africa and China Several servers were used worldwide (albeit missing Africa and China
as authors were unable to find IPv6 servers in these regions). as the authors were unable to find IPv6 servers in these regions).
Table 1 lists all the vantage points together with their AS number Table 1 lists all the vantage points together with their AS number
and country. and country.
+========+===================+==============+===================+ +========+===================+==============+===================+
| ASN | AS Name | Country code | Location | | ASN | AS Name | Country code | Location |
+========+===================+==============+===================+ +========+===================+==============+===================+
| 7195 | Edge Uno | AG | Buenos Aires | | 7195 | Edge Uno | AG | Buenos Aires |
+--------+-------------------+--------------+-------------------+ +--------+-------------------+--------------+-------------------+
| 12414 | NL-SOLCON SOLCON | NL | Amsterdam | | 12414 | NL-SOLCON SOLCON | NL | Amsterdam |
+--------+-------------------+--------------+-------------------+ +--------+-------------------+--------------+-------------------+
skipping to change at page 4, line 37 skipping to change at page 4, line 37
+--------+-------------------+--------------+-------------------+ +--------+-------------------+--------------+-------------------+
| 47853 | Hostinger | US | Ashville, NC | | 47853 | Hostinger | US | Ashville, NC |
+--------+-------------------+--------------+-------------------+ +--------+-------------------+--------------+-------------------+
| 60011 | MYTHIC-BEASTS-USA | US | Fremont, CA | | 60011 | MYTHIC-BEASTS-USA | US | Fremont, CA |
+--------+-------------------+--------------+-------------------+ +--------+-------------------+--------------+-------------------+
| 198644 | GO6 | SI | Ljubljana | | 198644 | GO6 | SI | Ljubljana |
+--------+-------------------+--------------+-------------------+ +--------+-------------------+--------------+-------------------+
Table 1: All vantage AS Table 1: All vantage AS
3.1.1. Tested Autonomous Systems 3.2. Tested Autonomous Systems
During first phase (traffic among fully meshed collaborative nodes), During first phase (traffic among fully-meshed collaborative nodes),
our probes have collected data on the following ASs: Table 2 show the ASs for which our probes have collected data.
+===========+======================================+==========+ +===========+======================================+==========+
| AS Number | AS Description | Comment | | AS Number | AS Description | Comment |
+===========+======================================+==========+ +===========+======================================+==========+
| 174 | COGENT-174, US | Tier-1 | | 174 | COGENT-174, US | Tier-1 |
+-----------+--------------------------------------+----------+ +-----------+--------------------------------------+----------+
| 1299 | TWELVE99 Twelve99, Telia Carrier, SE | Tier-1 | | 1299 | TWELVE99 Twelve99, Telia Carrier, SE | Tier-1 |
+-----------+--------------------------------------+----------+ +-----------+--------------------------------------+----------+
| 2914 | NTT-COMMUNICATIONS-2914, US | Tier-1 | | 2914 | NTT-COMMUNICATIONS-2914, US | Tier-1 |
+-----------+--------------------------------------+----------+ +-----------+--------------------------------------+----------+
skipping to change at page 6, line 16 skipping to change at page 6, line 16
Wikipedia page [TIER1], but there is no common way to decide who is a 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, tier-1. Based on some CAIDA research, all the above (except GO6,
which is a stub network) are transit providers. which is a stub network) are transit providers.
While this document lists some operators, the intent is not to build 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 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 kind of providers drop packets with extension headers and how
widespread the drop policy is enforced and where, i.e., in the access widespread the drop policy is enforced and where, i.e., in the access
provider or in the core of the Internet. provider or in the core of the Internet.
3.1.2. Tested Extension Headers 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 [RFC7704]). 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].
3.3. Tested Extension Headers
In the first phase among collaborating vantage points, packets always In the first phase among collaborating vantage points, packets always
contained either a UDP payload or a TCP payload, the latter is sent 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 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 of [RFC793] (2nd paragraph). A usual traceroute is done with only
the UDP/TCP payload without any extension header with varying hop- the UDP/TCP payload without any extension header with varying hop-
limit in order to learn the traversed routers and ASs. Then, several limit in order to learn the traversed routers and ASs. Then, several
UDP/TCP probes are sent with a set of extension headers: UDP/TCP probes are sent with a set of extension headers:
* hop-by-hop and destination options header containing: * hop-by-hop and destination options header containing:
- one PadN option for an extension header length of 8 octets, - one PadN option for an extension header length of 8 octets,
- one unknown option with the "discard" bits for an extension - one unknown option with the "discard" bits for an extension
header length of 8 octets, header length of 8 octets,
- several PaDN options for an extension header length of 256 - multiple PadN options for an extension header length of 256
octets, octets,
- one unknown option (two sets with "discard" and "skip" bits) - one unknown option (two sets with "discard" and "skip" bits)
for an extension header length of 256 octets, for the destination options header length of 16, 32, 64, and
128 octets,
- one unknown option (two sets with "discard" and "skip" bits) - one unknown option (two sets with "discard" and "skip" bits)
for an extension header length of 512 octets. for an extension header length of 256 and 512 octets.
* routing header with routing types from 0 to 6 inclusive (except * routing header with routing types from 0 to 6 inclusive;
for type 3);
* atomic fragment header (i.e., M-flag = 0 and offset = 0) of * atomic fragment header (i.e., M-flag = 0 and offset = 0) of
varying frame length 512, 1280, and 1500 octets; varying frame length 512, 1280, and 1500 octets;
* non-atomic first fragment header (i.e., M-flag = 1 and offset = 0) * non-atomic first fragment header (i.e., M-flag = 1 and offset = 0)
of varying frame length 512, 1280, and 1500 octets; of varying frame length 512, 1280, and 1500 octets;
* authentication header with dummy SPI followed by UDP/TCP header * authentication header with dummy SPI followed by UDP/TCP header
and a 38 octets payload. and a 38 octets payload.
In the above, length is the length of the extension header itself In the above, length is the length of the extension header itself
except for the fragmentation header where the length is the IP packet except for the fragmentation header where the length is the IP packet
length (i.e., including the IPv6, and TCP/UDP headers + payload). length (i.e., including the IPv6, and TCP/UDP headers + payload).
For hop-by-hop and destination options headers, when required For hop-by-hop and destination options headers, when required
multiple PadN options were used in order to bypass some Linux kernels multiple PadN options were used in order to bypass some Linux kernels
that consider a PadN larger than 8 bytes is an attack, see section that consider a PadN larger than 8 bytes is an attack, see section
5.3 of [BCP220], even if multiple PadN options violates section 5.3 of [BCP220], even if multiple PadN options violates section
2.1.9.5 of [RFC4942]. 2.1.9.5 of [RFC4942].
Next phases will also include packets without UDP/TCP transport In addition to the above extension headers, other probes were sent
header but with Next-Header being: with next header field of IPv6 header set to:
* 59, "no next header" see section 4.7 of [RFC8200];
* 143, "ethernet" see section 4.9 of [RFC8986].
3.1.3. 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 [RFC7704]). 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 * 59, which is "no next header", especially whether extra octets
intermediate routers do not generate an ICMP unreachable hop limit after the no next header as section 4.7 [RFC8200] requires that
exceeded even in the absence of any extension headers), then the drop "those octets must be ignored and passed on unchanged if the
is not attributed. Please also note that the goal of this document packet is forwarded";
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]. * 143, which is Ethernet payload (see section 10.1 of [RFC8986]).
3.2. Results 4. Results
This section presents the current results out of phase 1 This section presents the current results out of phase 1
(collaborating vantage points) testing. About 4860 experiments were (collaborating vantage points) testing. About 4860 experiments were
run, one experiment being defined by sending packets between 2 run, one experiment being defined by sending packets between 2
vantage points with hop-limit varying from 1 to the number of hops vantage points with hop-limit varying from 1 to the number of hops
between the two vantage points and for all the extension headers between the two vantage points and for all the extension headers
described in Section 3.1.2. described in Section 3.3.
3.2.1. Routing Header 4.1. Routing Header
The following table lists all routing header types and the percentage Table 3 lists all routing header types and the percentage of
of experiments that were successful, i.e., packets with routing experiments that were successful, i.e., packets with routing header
header reaching their destination: reaching their destination:
+=====================+===========================================+ +=====================+=======================================+
| Routing Header Type | %-age of experiments reaching destination | | Routing Header Type | %-age of packets reaching destination |
+=====================+===========================================+ +=====================+=======================================+
| 0 | 80.9% | | 0 | 80.9% |
+---------------------+-------------------------------------------+ +---------------------+---------------------------------------+
| 1 | 99.5% | | 1 | 99.5% |
+---------------------+-------------------------------------------+ +---------------------+---------------------------------------+
| 2 | 99.5% | | 2 | 99.5% |
+---------------------+-------------------------------------------+ +---------------------+---------------------------------------+
| 3 | not tested | | 3 | 99.5% |
+---------------------+-------------------------------------------+ +---------------------+---------------------------------------+
| 4 | 69.0% | | 4 | 69.0% |
+---------------------+-------------------------------------------+ +---------------------+---------------------------------------+
| 5 | 99.5% | | 5 | 99.5% |
+---------------------+-------------------------------------------+ +---------------------+---------------------------------------+
| 6 | 99.3% | | 6 | 99.3% |
+---------------------+-------------------------------------------+ +---------------------+---------------------------------------+
Table 3 Table 3: Per Routing Header Types Transmission
The table below lists the few ASs that drop packets with the routing Table 4 lists the few ASs that drop packets with the routing header
header type 0 (the original source routing header, which is now type 0 (the original source routing header, which is now deprecated).
deprecated).
+===========+================+ +===========+================+
| AS Number | AS description | | AS Number | AS description |
+===========+================+ +===========+================+
| 6939 | HURRICANE, US | | 6939 | HURRICANE, US |
+-----------+----------------+ +-----------+----------------+
Table 4 Table 4: AS Dropping
Routing Header Type 0
It is possibly due to a strict implementation of [RFC5095] but it is It is possibly due to a strict implementation of [RFC5095] but it is
expected that no packet with routing header type 0 would be expected that no packet with routing header type 0 would be
transmitted anymore. So, this is not surprising. transmitted anymore. So, this is not surprising.
The table below lists the few ASs that drop packets with the routing Table 5 lists the few ASs that drop packets with the routing header
header type 4 (Segment Routing Header [RFC8754]). type 4 (Segment Routing Header [RFC8754]).
+===========+================+ +===========+================+
| AS Number | AS description | | AS Number | AS description |
+===========+================+ +===========+================+
| 16276 | OVH, FR | | 16276 | OVH, FR |
+-----------+----------------+ +-----------+----------------+
Table 5 Table 5: AS Dropping
Routing Header Type 0
This drop of SRH was to be expected as SRv6 is specified to run only This drop of SRH was to be expected as SRv6 is specified to run only
in a limited domain. in a limited domain.
Other routing header types (1 == deprecated NIMROD [RFC1753], 2 == Other routing header types (1 == deprecated NIMROD [RFC1753], 2 ==
mobile IPv6 [RFC6275], and even 5 == CRH-16 and 6 == CRH- mobile IPv6 [RFC6275], 3 == RPL [RFC6554], and even 5 == CRH-16 and 6
32[I-D.draft-bonica-6man-comp-rtg-hdr]) can be transmitted over the == CRH-32[I-D.draft-bonica-6man-comp-rtg-hdr]) can be transmitted
global Internet without being dropped (assuming that the 0.5% of over the global Internet without being dropped (assuming that the
dropped packets are within the measurement error). 0.5% of dropped packets are within the measurement error).
3.2.2. Hop-by-Hop Options Headers 4.2. Hop-by-Hop Options Header
Many ASs drop packets containing either hop-by-hop options headers Many ASs drop packets containing either hop-by-hop options headers
per table below: per Table 6 below:
+===============+========+======================+ +===============+========+=======================================+
| Option Type | Length | %-age of experiments | | Option Type | Length | %-age of packets reaching destination |
| | | reaching destination | +===============+========+=======================================+
+===============+========+======================+ | Skip | 8 | 5.8% |
| Skip | 8 | 5.8% | +---------------+--------+---------------------------------------+
+---------------+--------+----------------------+ | Discard | 8 | 0.0% |
| Discard | 8 | 0.0% | +---------------+--------+---------------------------------------+
+---------------+--------+----------------------+ | Skip one | 256 | 1.9% |
| Skip one | 256 | 1.9% | | large PadN | | |
| large PadN | | | +---------------+--------+---------------------------------------+
+---------------+--------+----------------------+ | Skip multiple | 256 | 0.0% |
| Skip multiple | 256 | 0.0% | | PadN | | |
| PadN | | | +---------------+--------+---------------------------------------+
+---------------+--------+----------------------+ | Discard | 256 | 0.0% |
| Discard | 256 | 0.0% | +---------------+--------+---------------------------------------+
+---------------+--------+----------------------+ | Skip | 512 | 1.9% |
| Skip | 512 | 1.9% | +---------------+--------+---------------------------------------+
+---------------+--------+----------------------+ | Discard | 512 | 0.0% |
| Discard | 512 | 0.0% | +---------------+--------+---------------------------------------+
+---------------+--------+----------------------+
Table 6 Table 6: Hop-by-hop Transmission
It appears that hop-by-hop options headers cannot reliably traverse It appears that hop-by-hop options headers cannot reliably traverse
the global Internet; only small headers with 'skippable' options have the global Internet; only small headers with 'skipable' options have
some chances. If the hop-by-hop option has the 'discard' bits, it is some chances. If the unknown hop-by-hop option has the 'discard'
dropped per specification. bits, it is dropped per specification.
3.2.3. Destination Options Headers 4.3. Destination Options Header
Many ASs drop packets containing destination options headers per Many ASs drop packets containing destination options headers per
table below: Table 7:
+========+===============+======================+ +========+===============+=======================================+
| Length | Multiple PadN | %-age of experiments | | Length | Multiple PadN | %-age of packets reaching destination |
| | | reaching destination | +========+===============+=======================================+
+========+===============+======================+ | 8 | No | 99.3% |
| 8 | No | 99.2% | +--------+---------------+---------------------------------------+
+--------+---------------+----------------------+ | 16 | No | 99.3% |
| 256 | No | 2.6% | +--------+---------------+---------------------------------------+
+--------+---------------+----------------------+ | 32 | No | 93.3% |
| 256 | Yes | 2.6% | +--------+---------------+---------------------------------------+
+--------+---------------+----------------------+ | 64 | No | 41.6% |
| 512 | No | 2.6% | +--------+---------------+---------------------------------------+
+--------+---------------+----------------------+ | 128 | No | 4.5% |
+--------+---------------+---------------------------------------+
| 256 | No | 2.6% |
+--------+---------------+---------------------------------------+
| 256 | Yes | 2.6% |
+--------+---------------+---------------------------------------+
| 512 | No | 2.6% |
+--------+---------------+---------------------------------------+
Table 7 Table 7: Hop-by-hop Transmission
The measurement did not find any impact of the discard/skip bits in The measurement did not find any impact of the discard/skip bits in
the destination headers options, probably because the routers do not the destination headers options, probably because the routers do not
look inside the extension headers into the options. The use of a look inside the extension headers into the options. The use of a
single large PadN or multiple 8-octet PadN options does not influence single large PadN or multiple 8-octet PadN options does not influence
the result. the result.
3.2.4. Fragmentation Header The size of the destination options header has a major impact on the
drop probability. It appears that extension header larger than 16
octets already causes major drops. It may be because the 40 octets
of the IPv6 header + the 16 octets of the extension header (total 56
octets) is still below some router hardware lookup mechanisms while
the next measured size (extension header size of 64 octets for a
total of 104 octets) is beyond the hardware limit and some AS has a
policy to drop packets where the TCP/UDP ports are unknown...
4.4. Fragmentation Header
The propagation of two kinds of fragmentation headers was analysed: The propagation of two kinds of fragmentation headers was analysed:
atomic fragment (offset == 0 and M-flag == 0) and plain first atomic fragment (offset == 0 and M-flag == 0) and plain first
fragment (offset == 0 and M-flag == 1). The table below displays the fragment (offset == 0 and M-flag == 1). The Table 8 displays the
propagation differences. propagation differences.
+============+===========================================+ +============+=======================================+
| M-flag | %-age of experiments reaching destination | | M-flag | %-age of packets reaching destination |
+============+===========================================+ +============+=======================================+
| 0 (atomic) | 70.2% | | 0 (atomic) | 70.2% |
+------------+-------------------------------------------+ +------------+---------------------------------------+
| 1 | 99.0% | | 1 | 99.0% |
+------------+-------------------------------------------+ +------------+---------------------------------------+
Table 8 Table 8: IPv6 Fragments Transmission
The size of the overall IP packets (512, 1280, and 1500 octets) does The size of the overall IP packets (512, 1280, and 1500 octets) does
not have any impact on the propagation. not have any impact on the propagation.
3.2.5. No drop at all 4.5. No extension headers drop at all
Finally, some ASs do not drop transit traffic (except for routing Table 9 lists some ASs that do not drop transit traffic (except for
header type 0) and follow the recommendations of routing header type 0) and follow the recommendations of
[I-D.draft-ietf-opsec-ipv6-eh-filtering]. This list includes tier-1 [I-D.draft-ietf-opsec-ipv6-eh-filtering]. This list includes tier-1
transit providers (using the "regional" tag per [TIER1]): transit providers (using the "regional" tag per [TIER1]):
+===========+=======================================+===============+ +===========+=======================================+===============+
| AS Number | AS Description | Comment | | AS Number | AS Description | Comment |
+===========+=======================================+===============+ +===========+=======================================+===============+
| 4637 | ASN-TELSTRA-GLOBAL Telstra Global, HK | Regional | | 4637 | ASN-TELSTRA-GLOBAL Telstra Global, HK | Regional |
| | | Tier | | | | Tier |
+-----------+---------------------------------------+---------------+ +-----------+---------------------------------------+---------------+
| 4755 | TATACOMM-AS TATA Communications | | | 4755 | TATACOMM-AS TATA Communications | |
| | formerly VSNL is Leading ISP, IN | | | | formerly VSNL is Leading ISP, IN | |
+-----------+---------------------------------------+---------------+ +-----------+---------------------------------------+---------------+
| 6762 | SEABONE-NET TELECOM ITALIA SPARKLE | Tier-1 |
| | S.p.A., IT | |
+-----------+---------------------------------------+---------------+
| 14061 | DIGITALOCEAN-ASN, US | |
+-----------+---------------------------------------+---------------+
| 21283 | A1SI-AS A1 Slovenija, SI | | | 21283 | A1SI-AS A1 Slovenija, SI | |
+-----------+---------------------------------------+---------------+ +-----------+---------------------------------------+---------------+
| 60011 | MYTHIC-BEASTS-USA, GB | | | 60011 | MYTHIC-BEASTS-USA, GB | |
+-----------+---------------------------------------+---------------+ +-----------+---------------------------------------+---------------+
Table 9 Table 9: ASs Not Dropping Packets with Extension Headers
3.3. Summary of the collaborating parties measurements Some ASs also drop only large (more than 8 octets) destination
options headers, see Table 10:
+===========+====================+===================+
| AS Number | AS Description | Largest Forwarded |
| | | Dest.Opt. Size |
+===========+====================+===================+
| 6453 | Tata | 8 |
| | Communication | |
+-----------+--------------------+-------------------+
| 1299 | TWELVE99 Twelve99, | 8 |
| | Telia Carrier, SE | |
+-----------+--------------------+-------------------+
| 174 | COGENT-174, US | 8 |
+-----------+--------------------+-------------------+
Table 10: ASs Only Dropping Packets with Large
Destination Options Headers
4.6. Special Next Headers
Measurements also include two protocol numbers that are mainly new
use of IPv6. Table 11 indicates the percentage of packets reaching
the destination.
+===================+=======================================+
| Next Header | %-age of packets reaching destination |
+===================+=======================================+
| NoNextHeader (59) | 99.7% |
+-------------------+---------------------------------------+
| Ethernet (143) | 99.2% |
+-------------------+---------------------------------------+
Table 11: Transmission of Special IP Protocols
The above indicates that those IP protocols can be transmitted over
the global Internet without being dropped (assuming that the 0.3-0.8%
of dropped packets are within the measurement error).
5. Summary of the collaborating parties measurements
While the analysis has areas of improvement (geographical While the analysis has areas of improvement (geographical
distribution and impact on latency), it appears that: distribution and impact on latency), it appears that:
* authentication and non-atomic fragmentation headers can traverse * authentication and non-atomic fragmentation headers can traverse
the Internet; the Internet;
* only routing headers types 0 and 4 experiment problems over the * only routing headers types 0 and 4 experiment problems over the
Internet, other types have no problems; Internet, other types have no problems;
* hop-by-hop options headers do not traverse the Internet; * hop-by-hop options headers do not traverse the Internet;
* destination options headers are not reliable enough when it
* destination options headers are not reliable enough especially exceeds 16 octets.
large size ones.
Of course, the next phase of measurement with non-collaborating Of course, the next phase of measurement with non-collaborating
parties will probably give another view. parties will probably give another view.
4. Security Considerations 6. Security Considerations
While active probing of the Internet may be considered as an attack, While active probing of the Internet may be considered as an attack,
this measurement was done among collaborating parties and using the this measurement was done among collaborating parties and using the
probe attribution technique described in probe attribution technique described in
[I-D.draft-vyncke-opsec-probe-attribution]. [I-D.draft-vyncke-opsec-probe-attribution] to allow external parties
to identify the source of the probes if required.
5. IANA Considerations 7. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
6. References 8. References
6.1. Normative References 8.1. Normative References
[RFC793] 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,
<https://www.rfc-editor.org/rfc/rfc793>. <https://www.rfc-editor.org/rfc/rfc793>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>. <https://www.rfc-editor.org/rfc/rfc8200>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 8.2. Informative References
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>.
6.2. Informative References
[ALEXA] "The top 500 sites on the web", n.d., [ALEXA] "The top 500 sites on the web", n.d.,
<https://www.alexa.com/topsites>. <https://www.alexa.com/topsites>.
[BCP220] Chown, T., Loughney, J., and T. Winters, "IPv6 Node [BCP220] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, January 2019. Requirements", BCP 220, RFC 8504, January 2019.
<https://www.rfc-editor.org/info/bcp220> <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] [I-D.draft-bonica-6man-comp-rtg-hdr]
Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L.
Jalil, "The IPv6 Compact Routing Header (CRH)", Work in Jalil, "The IPv6 Compact Routing Header (CRH)", Work in
Progress, Internet-Draft, draft-bonica-6man-comp-rtg-hdr- Progress, Internet-Draft, draft-bonica-6man-comp-rtg-hdr-
27, 15 November 2021, 27, 15 November 2021,
<https://datatracker.ietf.org/doc/html/draft-bonica-6man- <https://datatracker.ietf.org/doc/html/draft-bonica-6man-
comp-rtg-hdr-27>. comp-rtg-hdr-27>.
[I-D.draft-ietf-opsawg-pcap] [I-D.draft-ietf-opsawg-pcap]
Harris, G. and M. C. Richardson, "PCAP Capture File Harris, G. and M. C. Richardson, "PCAP Capture File
skipping to change at page 14, line 46 skipping to change at page 16, line 9
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007, DOI 10.17487/RFC5095, December 2007,
<https://www.rfc-editor.org/rfc/rfc5095>. <https://www.rfc-editor.org/rfc/rfc5095>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/rfc/rfc6275>. 2011, <https://www.rfc-editor.org/rfc/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, March 2012,
<https://www.rfc-editor.org/rfc/rfc6554>.
[RFC7704] Crocker, D. and N. Clark, "An IETF with Much Diversity and [RFC7704] Crocker, D. and N. Clark, "An IETF with Much Diversity and
Professional Conduct", RFC 7704, DOI 10.17487/RFC7704, Professional Conduct", RFC 7704, DOI 10.17487/RFC7704,
November 2015, <https://www.rfc-editor.org/rfc/rfc7704>. November 2015, <https://www.rfc-editor.org/rfc/rfc7704>.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu,
"Observations on the Dropping of Packets with IPv6 "Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", RFC 7872, Extension Headers in the Real World", RFC 7872,
DOI 10.17487/RFC7872, June 2016, DOI 10.17487/RFC7872, June 2016,
<https://www.rfc-editor.org/rfc/rfc7872>. <https://www.rfc-editor.org/rfc/rfc7872>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/rfc/rfc8754>. <https://www.rfc-editor.org/rfc/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, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>.
[TIER1] "Tier 1 network", n.d., [TIER1] "Tier 1 network", n.d.,
<https://en.wikipedia.org/wiki/Tier_1_network>. <https://en.wikipedia.org/wiki/Tier_1_network>.
Acknowledgments Acknowledgments
The authors want to thank Sander Steffann and Jan Zorz for allowing The authors want to thank Sander Steffann and Jan Zorz for allowing
the free use of their labs. Other thanks to Fernando Gont who the free use of their labs. Other thanks to Fernando Gont who
indicated a nice IPv6 hosting provider in South America. indicated a nice IPv6 hosting provider in South America.
Special thanks as well to Professor Benoit Donnet for his support and Special thanks as well to Professor Benoit Donnet for his support and
skipping to change at page 15, line 29 skipping to change at page 17, line 4
Acknowledgments Acknowledgments
The authors want to thank Sander Steffann and Jan Zorz for allowing The authors want to thank Sander Steffann and Jan Zorz for allowing
the free use of their labs. Other thanks to Fernando Gont who the free use of their labs. Other thanks to Fernando Gont who
indicated a nice IPv6 hosting provider in South America. indicated a nice IPv6 hosting provider in South America.
Special thanks as well to Professor Benoit Donnet for his support and Special thanks as well to Professor Benoit Donnet for his support and
advices. This document would not have existed without his support. advices. This document would not have existed without his support.
Authors' Addresses Authors' Addresses
Éric Vyncke Éric Vyncke
Cisco Cisco
De Kleetlaan 64 De Kleetlaan 64
1831 Diegem 1831 Diegem
Belgium Belgium
Email: evyncke@cisco.com Email: evyncke@cisco.com
Raphaël Léas Raphaël Léas
Université de Liège Université de Liège
Liège Liège
Belgium Belgium
Email: raphael.leas@student.uliege.be Email: raphael.leas@student.uliege.be
Justin Iurman Justin Iurman
Université de Liège Université de Liège
Institut Montefiore B28
Allée de la Découverte 10
4000 Liège
Belgium Belgium
Email: justin.iurman@uliege.be Email: justin.iurman@uliege.be
 End of changes. 63 change blocks. 
190 lines changed or deleted 256 lines changed or added

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