Just Another Measurement of Extension header Survivability (JAMES)

3.1. Vantage Points

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

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

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

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

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

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

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

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

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

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