]> Tsinghua University

he-lin@tsinghua.edu.cn

Tsinghua University

jzd25@mails.tsinghua.edu.cn

Tsinghua University

gl25@mails.tsinghua.edu.cn

Nankai University

zhangsl@nankai.edu.cn

Tsinghua University

liuying@cernet.edu.cn

Operations and Management IPv6 Operations IPv6 IPv6 Extension Header Reachability Evasion IPv6 Extension Headers (EHs) are designed to provide protocol flexibility and support for emerging features, while maintaining a concise base header and efficient processing. In practice, their reachability is affected by middlebox handling along the path, and their flexibility also introduces security considerations. This document presents observations from a comprehensive, large-scale measurement study of IPv6 Extension Header path traversal across more than 23,000 autonomous systems. Using a feedback-driven measurement framework called 6Travel, the reachability of 11 common IPv6 Extension Headers is measured over ICMPv6, TCP, and UDP. The measurements indicate a change relative to earlier work: contrary to past observations of heavy filtering, specific Extension Headers now achieve reachability comparable to plain traffic. Two distinct forms of policy ossification are observed across industry categories, together with widespread potential Extension-Header-based firewall evasion signatures in nearly 5,000 autonomous systems, particularly under TCP and UDP. These signatures appear consistent with a combination of implementation flaws and security misconfigurations, spanning both on-path and host-side firewalls. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the IPv6 Operations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction IPv6 has been widely deployed around the world as an alternative to IPv4. IPv6 includes Extension Headers (EHs) . Located between the IPv6 base header and the upper-layer protocol header, EHs provide IPv6 with a high degree of flexibility, scalability, and support for new core functions of the protocol, while maintaining the simplicity of the base header and efficient processing. EHs have been widely applied in various aspects, including Mobile IPv6 (MIPv6) , Segment Routing over IPv6 (SRv6) , In-band Operations, Administration, and Maintenance (IOAM) , and IPSec . As EHs are increasingly adopted, characterizing their traversal behavior and reachability is important for operational planning and security assessment. The path traversal capabilities of EHs have been extensively investigated . Collectively, these studies report that IPv6 packets carrying EHs experience higher drop rates compared to plain IPv6 traffic, indicating a fragmented and restrictive deployment landscape across the global Internet. A comprehensive understanding of EH reachability across a broad range of headers and networks is still lacking. The full spectrum of common EHs has not yet been characterized together with extensive Autonomous System (AS) coverage. Approaches based on serial traceroute or end-to-end probing can incur substantial resource overhead and may constrain measurement scope and consistency. EH processing also introduces security challenges . IPv6 requires all EHs to be processed to identify upper-layer protocols, which may allow attackers to evade firewalls and packet filters that improperly handle or overlook inserted EHs during security enforcement . Moreover, specific EH types are associated with known architectural concerns that can be used for targeted attacks, such as amplification , overlapping fragment evasion , processing of atomic fragments , information leakage , and Denial of Service (DoS) attacks . Motivated by these observations, this document reports a comprehensive, large-scale measurement study of EH path traversal conducted with 6Travel , a feedback-driven measurement framework. The measurements cover 6.3 million /48 prefixes across more than 23,000 ASes, evaluating 11 common EHs over ICMPv6, TCP, and UDP. The key findings are summarized as follows:

• EH Path Traversal Capability: Specific EHs, in particular the Destination Options header and the Atomic Fragment header, now achieve reachability comparable to plain traffic under TCP and UDP, contrary to historical observations of heavy filtering. This is consistent with an evolving IPv6 infrastructure that enables practical deployment of EH-based applications but simultaneously expands the attack surface.
• Policy Ossification: Two counter-posed forms of policy ossification are observed across industry categories: (i) Availability-oriented ossification, which prioritizes utility at the expense of an expanded attack surface; and (ii) Security-oriented ossification, which secures the boundary but hinders IPv6 architectural evolution through rigid filtering.
• Potential EH-based Firewall Evasion: Widespread potential firewall evasion signatures are observed in nearly 5,000 ASes, particularly under TCP and UDP. These signatures appear consistent with implementation flaws (e.g., protocol blind spots for less common EHs, over-permissiveness for IPSec) and security misconfigurations (e.g., neglecting to parse EHs), spanning both on-path and host-side firewalls.

This document is organized as follows. provides background on IPv6 Extension Headers. describes the measurement methodology. presents observations on EH path traversal capability. presents observations on EH-based firewall evasion. discusses security considerations. and provide supplementary information on ethical considerations and measurement caveats, respectively.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

IPv6 Extension Headers Extension Headers are optional headers that may appear between the IPv6 base header and the transport layer. They are designed to extend the functionality of IPv6 packets without requiring modifications to the base header. All EHs include a Next Header field, which chains EHs together. Through this chaining mechanism, an IPv6 packet can include zero or more EHs, each serving different functional requirements. and the Internet Assigned Numbers Authority (IANA) have defined the following EHs:

• Hop-by-Hop Options header: Designed to carry optional information that must be examined by every node along a packet's delivery path. Recent updates to its processing procedures are specified in .
• Destination Options header: Designed to carry optional information that need be examined only by a packet's destination node(s). Used for purposes such as collecting measurement data and measuring service performance .
• Routing header: Similar to IPv4's Loose Source and Record Route option, used in scenarios where packets need to visit one or more intermediate nodes. Specific types include the RPL Routing header , the Segment Routing Header (SRH) , and the Mobile IPv6 Routing header (type 2) .
• Fragment header: Used for IPv6 fragmentation when transmitting large packets (e.g., DNS responses).
• Encapsulating Security Payload (ESP) and Authentication Header (AH) : Used in IPSec to provide data confidentiality, data integrity, and data authentication.
• Mobility header: Used for managing mobile node mobility in IPv6 networks .
• Host Identity Protocol (HIP) header and Shim6 Protocol header : Designed for locator/identifier separation and multi-homing support, respectively.

Measurement Methodology This section describes the measurement methodology, including the measurement framework, address dataset, and the selection of EHs and upper-layer protocols.

Measurement Framework The measurements use 6Travel , a feedback-driven measurement framework designed for large-scale EH path traversal measurement. The framework employs a hybrid approach that integrates traceroute-based and end-to-end methods to assess the traversal capability of crafted probe packets. Specifically, 6Travel first attempts end-to-end probing for each target; if no response confirming destination arrival is received, it conducts adaptive probing to locate the last responsive node along the path. All probe types (i.e., packets with different EHs) are measured in parallel using a pipelined scheduling mechanism, ensuring near-simultaneous probing that minimizes temporal lag between different probe types and enables rigorous comparative analysis. The framework incorporates a global and local rate control strategy to mitigate the impact of ICMPv6 rate limiting while maximizing probing efficiency. It also includes a packet marking mechanism to ensure measurement consistency. 6Travel is open-source and publicly available at https://anonymous.4open.science/r/6Travel.

Measurement Setup The EH path traversal measurement was conducted from a single vantage point (VP) in an education network. The network is confirmed to have no enforced access control policies on all EHs. The VP is equipped with a 24-core Intel(R) Xeon(R) CPU E5-2620 v3 and 64 GB of RAM. A timeout of 5 seconds is set for each probe to allow sufficient time for responses. To mitigate the impact of ICMPv6 rate limiting and reduce the probing burden on target networks, the probing address list is randomized before each measurement round. Additionally, to minimize interference with both the local and target networks, the hop limits are set to 8--30. The probing rate is configured to 50,000 packets per second.

Address Dataset To ensure a representative and large-scale perspective, target addresses are aggregated from three complementary sources, as detailed in . Details of three data sources

Source	Description	# /48 Prefixes	# ASes	# Industry Categories
Source 1	IPv6 Hitlist (responsive hosts across diverse networks)	581,098	22,221	17
Source 2	AddrProbe (active target discovery for unseeded ASes)	1,485,873	2,158	17
Source 3	IPv6 Observatory (passive NTP traffic, prefix-level)	5,177,906	13,217	17
Total		6,336,433	23,999	17

Source 1 uses the IPv6 Hitlist as a broad baseline of responsive hosts. Source 2 leverages AddrProbe 's pattern-learning capabilities to discover active targets in ASes lacking known active IPv6 addresses. Source 3 incorporates passive NTP traffic from the IPv6 Observatory to capture hosts typically invisible to active probing. Since access control policies for EHs are typically enforced at the prefix level rather than on individual hosts, prefix-level sampling is adopted by randomly selecting one address within each /48 prefix. The /48 prefix length represents the shortest globally routable prefix length commonly announced in the BGP system. Industry categories are determined using ASdb .

Selection of EHs and Upper-layer Protocols To evaluate the path traversal capability of EHs, the EHs depicted in are selected, covering six application scenarios: data transmission (AFrag, Frag), secure communication (AH, ESP), Mobile IPv6 (RH2, MH), site multi-homing (HIP, Shim6), Routing header types (RH0, RH127), and general function extension (Dst). EHs measured

EH	Alias	Default Size (octets)	Description
Destination Options header	Dst	8	The option is PadN.
Fragment header	Frag	8	The offset and M flag are set to zero and one, respectively.
Atomic Fragment header	AFrag	8	The offset and M flag are both set to zero.
Routing header (type 0)	RH0	8	The segments left field is set to zero.
Routing header (type 2)	RH2	24	The home address is set to the target address.
Routing header (type 127)	RH127	8	The segments left field is set to zero.
Authentication header	AH	24	All IPSec-related fields are filled with zeros.
Encapsulating Security Payload	ESP	-	All IPSec-related fields are filled with zeros.
Mobility header type 0	MH	8	All fields are set according to .
Host Identity Protocol header (type 1)	HIP	48	All fields are set according to .
Shim6 Protocol header	Shim6	8	All fields are set according to .

For each EH, the probe is constructed by adding the EH between the IPv6 base header and the upper-layer protocol header. The upper-layer protocols measured are ICMPv6, TCP/22 (SSH), and UDP/161 (SNMPv3). Although the measurement vantage point does not explicitly block the Hop-by-Hop Options header, packets carrying it were observed to be dropped by default, likely due to default router configurations. Given that previous large-scale studies have consistently reported extremely poor reachability for the Hop-by-Hop Options header , it is excluded from the path traversal measurements as its limited reachability is already well-documented.

Observations on EH Path Traversal A comprehensive path traversal measurement was conducted across all combinations of EHs and upper-layer protocols.

Destination AS Reachability The destination AS reachability rate is defined as the proportion of /48 prefixes for which probes successfully reach their respective destination AS out of the total set of probed prefixes. The baseline represents EH-free probes per protocol. presents the results for each EH across protocols. Destination AS reachability rate for each EH across protocols compared to baseline

EH	ICMPv6 (%)	TCP/22 (%)	UDP/161 (%)
Baseline	80.18	70.55	69.58
Dst	77.49	70.08	68.68
AFrag	77.68	70.28	69.02
Frag	63.00	61.86	61.40
RH0	62.01	59.40	58.29
RH2	65.56	58.80	58.26
RH127	67.32	60.24	58.92
MH	69.84	69.62	68.90
HIP	70.96	70.87	67.80
Shim6	70.18	70.00	69.54
AH	72.27	70.56	69.76
ESP	70.38	70.85	70.29

The results indicate several patterns: Dst and AFrag achieve reachability comparable to the baseline, while Frag exhibits drops of 7.6%--14.8%, which may reduce the utility of fragmentation-dependent services such as DNSSEC. Routing headers (RHs) exhibit consistently low reachability, with RH2 and RH127 being largely suppressed under TCP/UDP despite moderate ICMPv6 reachability. This pattern is consistent with a diagnostic-only tolerance, where network operators may relax filtering for ICMPv6 to preserve basic connectivity, while enforcing stricter policies on TCP/UDP. A protocol-dependent disparity emerges for MH, HIP, Shim6, AH, and ESP. While these headers fall 7.9%--10.4% below the baseline under ICMPv6, they remain consistently within 2% of the baseline under TCP/UDP, with AH and ESP occasionally even exceeding it. This shift is consistent with these headers benefiting from permissive inspection policies or preferential treatment (e.g., whitelisting of encrypted-like traffic). These observations are consistent with a maturing IPv6 infrastructure where specific EHs have transitioned from high drop rates to near-parity with plain traffic. While this enables the practical deployment of EH-based applications (e.g., MIPv6, IPSec), it simultaneously expands the network attack surface for EH-based exploits.

Reachability Across Industry Categories To dissect the security-reachability tradeoff across diverse network environments, the results are categorized by industry category (IC) for each /48 prefix. The following tables display the ratio of destination AS reachability for EH-carrying probes relative to the EH-free baseline within each industry category. The ratio is calculated as R_EH / R_Baseline. Values of 1.0 denote parity with the baseline, while values <1.0 and >1.0 indicate EH-induced filtering and potential evasion, respectively. A /48 prefix is counted multiple times if it belongs to multiple industry categories. Relative destination AS reachability under ICMPv6 by industry category

IC	Dst	AFrag	Frag	RH0	RH2	RH127	MH	HIP	Shim6	AH	ESP
Tech	0.97	0.97	0.78	0.77	0.82	0.84	0.87	0.88	0.87	0.90	0.88
Other	0.99	0.99	0.83	0.88	0.84	0.88	0.94	0.94	0.94	0.95	0.94
Retail	0.98	0.78	0.69	0.82	0.77	0.83	0.75	0.74	0.75	0.92	0.74
Education	0.97	0.93	0.58	0.86	0.78	0.89	0.78	0.82	0.82	0.80	0.76
Agriculture	0.90	0.91	0.45	0.83	0.74	0.87	0.71	0.72	0.72	0.68	0.64
Manufacturing	0.95	0.94	0.61	0.87	0.81	0.90	0.84	0.83	0.83	0.84	0.80
Utilities	0.95	0.95	0.76	0.90	0.89	0.94	0.88	0.88	0.88	0.85	0.84
Nonprofits	0.96	0.95	0.43	0.84	0.69	0.93	0.69	0.69	0.69	0.73	0.67
Service	0.98	0.93	0.89	0.89	0.85	0.89	0.91	0.91	0.91	0.95	0.91
Media	0.69	0.70	0.61	0.29	0.27	0.29	0.62	0.91	0.91	0.93	0.89
Construction	0.97	0.97	0.35	0.89	0.64	0.93	0.62	0.63	0.63	0.62	0.60
Finance	0.96	0.95	0.44	0.84	0.72	0.92	0.70	0.70	0.70	0.73	0.70
Entertainment	0.91	0.93	0.35	0.82	0.67	0.88	0.66	0.67	0.67	0.65	0.56
Shipping	0.95	0.34	0.31	0.93	0.87	0.94	0.34	0.34	0.34	0.88	0.34
Health Care	0.96	0.96	0.42	0.84	0.77	0.91	0.76	0.76	0.76	0.76	0.69
Government	0.98	0.97	0.96	0.98	0.96	0.98	0.96	0.96	0.96	0.96	0.96
Travel	0.96	0.94	0.62	0.83	0.78	0.86	0.80	0.81	0.81	0.77	0.72

Relative destination AS reachability under TCP/22 by industry category

IC	Dst	AFrag	Frag	RH0	RH2	RH127	MH	HIP	Shim6	AH	ESP
Tech	1.00	1.00	0.86	0.87	0.85	0.87	0.98	0.98	0.98	0.98	0.98
Other	0.99	1.00	0.88	0.84	0.83	0.85	0.99	1.01	0.99	1.00	1.01
Retail	1.03	0.87	0.78	0.85	0.68	0.86	0.86	0.86	0.86	0.85	0.86
Education	1.00	0.97	0.70	0.92	0.88	0.94	0.93	1.02	1.02	0.94	0.96
Agriculture	0.79	0.86	0.48	0.75	0.72	0.76	0.74	0.77	0.77	0.72	0.70
Manufacturing	0.99	0.99	0.70	0.96	0.94	0.97	1.01	1.02	1.02	0.98	1.02
Utilities	1.01	1.02	0.85	0.98	0.96	0.99	0.97	0.99	0.99	0.95	0.96
Nonprofits	0.99	0.97	0.51	0.89	0.83	0.97	0.87	0.88	0.88	0.85	0.86
Service	1.00	1.00	0.40	0.97	0.70	0.97	0.71	0.73	0.73	0.69	0.70
Media	1.00	0.98	0.95	0.90	0.86	0.90	0.97	0.97	0.97	0.97	0.97
Construction	0.82	0.82	0.72	0.34	0.34	0.35	0.82	1.15	1.15	1.13	1.12
Finance	0.97	0.97	0.53	0.84	0.82	0.94	0.84	0.85	0.86	0.85	0.85
Entertainment	1.02	1.03	0.51	0.96	0.86	1.00	0.94	0.98	0.98	0.85	0.85
Shipping	1.01	1.01	0.54	0.92	0.88	0.99	0.93	0.96	0.96	0.86	0.89
Health Care	0.99	1.00	1.00	0.99	0.99	0.99	0.99	0.99	0.99	0.99	0.99
Government	1.00	0.44	0.43	0.98	0.44	1.00	0.46	0.46	0.46	0.46	0.46
Travel	1.03	1.03	0.79	0.98	0.98	1.01	1.04	1.07	1.07	0.97	0.98

Relative destination AS reachability under UDP/161 by industry category

IC	Dst	AFrag	Frag	RH0	RH2	RH127	MH	HIP	Shim6	AH	ESP
Tech	0.99	0.99	0.88	0.84	0.84	0.84	0.99	0.97	1.00	1.00	1.01
Other	1.00	1.00	0.87	0.88	0.86	0.88	0.99	0.99	0.99	1.00	0.99
Retail	1.02	0.98	0.69	0.92	0.90	0.95	0.91	1.01	1.01	0.92	0.95
Education	1.00	0.99	0.91	0.80	0.79	0.80	1.00	1.00	1.00	0.99	1.00
Agriculture	0.82	0.82	0.47	0.78	0.79	0.80	0.75	0.77	0.78	0.72	0.70
Manufacturing	1.02	1.01	0.71	0.99	0.95	1.00	1.00	1.12	1.14	0.97	1.12
Utilities	1.01	1.00	0.84	0.97	0.98	0.99	0.97	0.99	0.99	0.94	0.94
Nonprofits	1.00	1.00	0.54	0.96	0.93	0.96	0.95	0.98	0.98	0.93	0.93
Service	0.99	0.99	0.96	0.89	0.87	0.89	0.99	0.99	0.99	0.99	0.99
Media	0.77	0.77	0.65	0.32	0.31	0.32	0.76	1.10	1.10	1.09	1.08
Construction	1.00	0.98	0.54	0.96	0.90	0.98	0.94	0.96	0.96	0.91	0.94
Finance	0.97	0.96	0.57	0.93	0.92	0.94	0.92	0.95	0.95	0.93	0.94
Entertainment	1.04	1.06	0.52	1.00	0.86	1.02	0.96	0.99	1.01	0.86	0.86
Shipping	0.99	0.93	0.91	0.99	0.94	0.99	0.98	0.99	0.98	0.98	0.99
Health Care	0.99	1.00	0.99	0.99	0.99	0.99	0.99	0.99	0.99	0.99	0.99
Government	1.01	1.01	0.53	0.96	0.95	1.00	0.98	1.01	1.02	0.90	0.93
Travel	1.03	1.02	0.67	0.97	0.94	1.00	0.97	1.33	1.33	0.87	1.18

Two distinct forms of policy ossification are observed across industry categories: Availability-oriented ossification: In industry categories such as Travel, Construction, Media, and Manufacturing, reachability for certain EHs (e.g., MH, HIP, AH/ESP) exceeds the baseline under TCP/UDP. This is consistent with a permissive ossification, where inspection policies are fixed to prioritize service availability. While the Media and Construction categories are generally permissive, they consistently suppress Routing headers, which is consistent with a fixed mitigation strategy for Routing header risks. Security-oriented ossification: The Government category exhibits a bifurcated pattern: it maintains reachability comparable to the baseline under ICMPv6 and UDP, yet applies strict filtering for almost all EHs under TCP, consistent with a restrictive and legacy-driven security posture. This approach secures the boundary but hinders IPv6 architectural evolution through rigid filtering. Protocol-neutral posture: The Health Care category maintains reachability consistently near the baseline across both TCP and UDP, consistent with minimal active filtering and limited middlebox interference.

Observations on Potential EH-based Firewall Evasion Building upon the measurement results presented in , several EHs exhibit destination reachability that exceeds the established baseline. Such discrepancies are consistent with potential firewall evasion. This section presents a threat model, identifies threat scenarios, and quantifies the extent of the potential evasion observed.

Threat Model The threat model considers a remote adversary located outside the victim network, capable of crafting and sending arbitrary IPv6 packets, including those with EHs, from a controlled host. The adversary has no access to the firewall or end hosts and cannot compromise their implementations. Firewalls may be deployed either on-path or at end hosts. In this context, firewall broadly refers to any middlebox or network device that enforces access control based on ACLs, including dedicated firewalls, border routers, and stateful appliances. The model assumes a typical deployment where: (i) end hosts process supported EHs correctly and generate ICMPv6 Parameter Problem messages for unsupported EHs; (ii) the firewall is configured to allow legitimate TCP, UDP, and ICMPv6 traffic while attempting to block reconnaissance and unauthorized access; and (iii) the firewall may enforce access control only on ICMPv6, TCP, and UDP traffic without explicitly considering EHs, or improperly process packets carrying EHs. The adversary's primary goals are to: (i) perform stealthy network reconnaissance to map hidden topologies and live hosts, and (ii) violate access-control policies by accessing internal services protected by firewalls.

Threat Scenarios Building upon related work and validated through local proof-of-concept demonstrations (see ), two primary threat scenarios are identified: Scenario 1: Hidden Network Discovery. For EHs that require specific host-side processing support, an adversary can insert them into standard topology or host discovery probes (e.g., ICMPv6 Echo Request). Such modified probes may evade firewall filtering rules, allowing reconnaissance of otherwise hidden network topologies and hosts. The same technique can be combined with source address spoofing to launch reflection or amplification attacks. Scenario 2: Unauthorized Access. For non-disruptive EHs (e.g., Destination Options header or Atomic Fragment header), an adversary can append them to otherwise legitimate TCP/UDP packets. These EHs are crafted so as not to interfere with the target's transport-layer protocol parsing, yet they may cause firewalls to skip deep packet inspection, potentially enabling unauthorized access to services that would otherwise be protected.

Identifying Potential EH-based Firewall Evasion To identify which EHs may evade firewalls, the results of EH-carrying probes are compared with those of EH-free probes. The design of 6Travel minimizes the time gap between EH-carrying and EH-free probing. The following response types are defined: Response types and their notation

Response Type	Notation
ICMPv6 Destination Unreachable (type 0, 2, 3)	DU_addr
ICMPv6 Destination Unreachable (type 4)	DU_port
ICMPv6 Destination Unreachable (type 1, 5, 6)	DU_deny
ICMPv6 Parameter Problem (from target)	PP_tgt
ICMPv6 Time Exceeded (code 0)	TE
ICMPv6 Echo Reply / TCP SYN-ACK or RST-ACK / SNMPv3 Response	Resp

Four rules are defined to determine whether an EH-carrying probe type exhibits a response pattern consistent with firewall evasion:

• Rule 1: The EH-free probe type receives a DU_addr, whereas the EH-carrying probe type receives a PP_tgt or Resp.
• Rule 2: The EH-free probe type receives a DU_port, whereas the EH-carrying probe type receives a Resp.
• Rule 3: The EH-free probe type is denied access with a DU_deny, while the EH-carrying probe type receives DU_addr, DU_port, PP_tgt, or Resp.
• Rule 4: The EH-free probe type is silently discarded (receives a TE), but the EH-carrying probe type receives DU_addr, DU_port, PP_tgt, or Resp.

For Rules 1--3, the addresses of the firewall devices apparently evaded via EHs can be further identified by extracting information from the returned ICMPv6 Destination Unreachable messages.

Extent of Potential Firewall Evasion The number of /48 prefixes and ASes exhibiting evasion signatures across different industry categories is quantified to evaluate the extent of potential firewall evasion.

Overall Impact Overall extent of EH-based firewall evasion signatures

Protocol	# Affected /48 Prefixes	# Affected ASes
ICMPv6	93,630 (1.6%)	1,154 (4.9%)
TCP/22	218,954 (3.7%)	4,961 (21.1%)
UDP/161	195,175 (3.4%)	4,468 (19.0%)

While 93,630 /48 prefixes (1,154 ASes) exhibit evasion signatures under ICMPv6, the count nearly doubles under TCP/UDP, reaching 218,954 prefixes (4,961 ASes) for TCP and 195,175 prefixes (4,468 ASes) for UDP. This disparity aligns with the diagnostic-only nature of ICMPv6, where stricter, yet evadable, security policies are disproportionately focused on TCP/UDP.

Breakdown by EH Type presents the number of /48 prefixes exhibiting EH-based evasion signatures across different EH types and protocols. Number of /48 prefixes (in thousands) with EH-based firewall evasion signatures across EH types

EH	ICMPv6 (K)	TCP/22 (K)	UDP/161 (K)
Dst	6.0	54.4	37.0
AFrag	7.3	58.6	40.3
RH0	10.5	51.9	35.6
RH2	10.1	46.9	46.9
RH127	10.0	51.6	40.1
MH	8.4	79.3	69.1
HIP	18.6	110.6	91.5
Shim6	8.9	94.5	84.0
AH	71.7	117.7	110.6
ESP	79.3	158.2	150.2

Evasion signatures vary across EH types, which is consistent with diverse underlying causes:

• AH and ESP consistently exhibit the highest evasion-signature rates, which is consistent with lenient inspection of IPSec-related traffic for service continuity.
• MH, HIP, and Shim6 --- which are not defined in --- show higher evasion signatures under TCP/UDP than Dst or RHs, which is consistent with firewalls not accounting for these less common headers, leaving security blind spots.
• The spatial distribution of apparently evaded firewalls further distinguishes these patterns: evasion signatures predominantly occur within intermediate ASes under ICMPv6, while this shifts toward destination ASes for MH, HIP, and Shim6 under TCP/UDP.

Breakdown by Industry Category The following tables provide a breakdown of evasion signatures by industry category for each protocol. A /48 prefix or AS is counted multiple times if it belongs to multiple categories. EH-based firewall evasion signatures under ICMPv6 by industry category

Industry Category	# Affected /48s	# Affected ASes
Agriculture	3 (0.2%)	2 (1.6%)
Nonprofits	18 (0.5%)	14 (2.8%)
Tech	93,005 (1.6%)	985 (5.9%)
Construction	10 (0.1%)	9 (1.5%)
Education	65 (0.7%)	28 (2.6%)
Finance	16 (0.2%)	11 (2.7%)
Shipping	10 (0.0%)	7 (3.3%)
Government	36 (0.0%)	10 (2.1%)
Health Care	3 (0.4%)	2 (1.1%)
Manufacturing	51 (1.2%)	12 (2.2%)
Media	2,293 (2.3%)	42 (3.7%)
Entertainment	5 (0.5%)	4 (2.3%)
Other	394 (0.2%)	103 (2.9%)
Retail	1,398 (0.6%)	39 (3.1%)
Service	241 (0.0%)	50 (2.6%)
Travel	6 (0.9%)	4 (2.7%)
Utilities	7 (0.4%)	5 (3.0%)
Total	93,630 (1.6%)	1,154 (4.9%)

EH-based firewall evasion signatures under TCP/22 by industry category

Industry Category	# Affected /48s	# Affected ASes
Agriculture	79 (4.2%)	17 (14.2%)
Nonprofits	248 (7.0%)	81 (16.5%)
Tech	210,516 (3.7%)	4,046 (24.3%)
Construction	216 (2.5%)	104 (17.5%)
Education	822 (9.1%)	211 (19.5%)
Finance	198 (2.4%)	55 (13.7%)
Shipping	76 (0.1%)	36 (17.0%)
Government	204 (0.1%)	67 (14.3%)
Health Care	85 (10.5%)	25 (13.4%)
Manufacturing	636 (13.9%)	92 (16.9%)
Media	13,690 (14.4%)	254 (22.5%)
Entertainment	66 (6.7%)	21 (12.3%)
Other	7,100 (2.8%)	435 (12.4%)
Retail	5,306 (2.4%)	222 (17.5%)
Service	4,141 (0.8%)	338 (17.7%)
Travel	61 (9.2%)	18 (12.4%)
Utilities	94 (5.7%)	30 (18.2%)
Total	218,954 (3.7%)	4,961 (21.1%)

EH-based firewall evasion signatures under UDP/161 by industry category

Industry Category	# Affected /48s	# Affected ASes
Agriculture	78 (4.1%)	16 (13.3%)
Nonprofits	207 (5.8%)	77 (15.7%)
Tech	187,933 (3.4%)	3,658 (22.0%)
Construction	157 (1.8%)	84 (14.2%)
Education	853 (9.4%)	185 (17.0%)
Finance	131 (1.6%)	47 (11.6%)
Shipping	56 (0.0%)	31 (14.8%)
Government	181 (0.1%)	60 (12.9%)
Health Care	77 (9.6%)	29 (15.9%)
Manufacturing	537 (12.1%)	64 (11.7%)
Media	9,915 (10.5%)	210 (18.7%)
Entertainment	50 (5.1%)	16 (9.2%)
Other	6,014 (2.4%)	385 (10.9%)
Retail	2,037 (0.9%)	170 (13.5%)
Service	929 (0.2%)	277 (14.5%)
Travel	25 (4.2%)	11 (7.6%)
Utilities	75 (4.6%)	19 (11.4%)
Total	195,175 (3.4%)	4,468 (19.0%)

Industry-category-wise, the Tech category accounts for the largest share of evasion signatures, followed by Media and Retail, which also show elevated levels, particularly under TCP/UDP.

On-path vs. Host-side Evasion presents the spatial distribution of apparently evaded firewalls across EH types and protocols. For each combination, the percentage of apparently evaded firewalls located in intermediate ASes versus destination ASes is reported, together with the percentage of on-path versus host-side firewalls. Spatial distribution of apparently evaded firewalls across EH types and protocols

Protocol	EH	Intermediate AS (%)	Destination AS (%)	On-path (%)	Host-side (%)
ICMPv6	Dst	90.7	9.3	98.7	1.3
ICMPv6	AFrag	90.5	9.5	98.6	1.4
ICMPv6	RH0	86.0	14.0	97.8	2.2
ICMPv6	RH2	77.1	22.9	81.3	18.8
ICMPv6	RH127	88.8	11.3	98.8	1.3
ICMPv6	MH	91.4	8.6	97.5	2.5
ICMPv6	HIP	82.1	17.9	92.6	7.4
ICMPv6	Shim6	85.8	14.2	93.4	6.6
ICMPv6	AH	89.7	10.3	97.1	2.9
ICMPv6	ESP	82.4	17.6	97.3	2.7
TCP/22	Dst	71.8	28.2	92.0	8.0
TCP/22	AFrag	77.1	22.9	84.7	15.3
TCP/22	RH0	87.4	12.6	97.8	2.2
TCP/22	RH2	61.4	38.6	74.9	25.1
TCP/22	RH127	87.6	12.4	98.2	1.8
TCP/22	MH	21.3	78.7	97.2	2.8
TCP/22	HIP	25.1	74.9	90.6	9.4
TCP/22	Shim6	23.4	76.6	92.2	7.8
TCP/22	AH	89.5	10.5	97.7	2.3
TCP/22	ESP	29.2	70.8	97.8	2.2
UDP/161	Dst	87.1	12.9	94.8	5.2
UDP/161	AFrag	70.8	29.2	75.5	24.5
UDP/161	RH0	84.8	15.2	94.2	5.9
UDP/161	RH2	64.2	35.8	72.7	27.3
UDP/161	RH127	86.8	13.2	95.4	4.6
UDP/161	MH	13.4	86.6	98.6	1.4
UDP/161	HIP	29.8	70.2	97.3	2.7
UDP/161	Shim6	29.6	70.4	97.3	2.7
UDP/161	AH	91.7	8.3	94.0	6.0
UDP/161	ESP	59.5	40.5	97.2	2.8

Several patterns emerge from this analysis: Evasion signatures predominantly occur within intermediate ASes under ICMPv6, with most EHs showing over 80% of apparently evaded firewalls in intermediate ASes. This shifts for TCP/UDP: MH, HIP, and Shim6 exhibit 78.7%, 74.9%, and 76.6% destination AS evasion signatures under TCP/22 respectively, which is consistent with a policy to avoid disrupting TCP/UDP EH processing at the edge. Conversely, evasion signatures for Dst and AFrag remain concentrated in intermediate ASes (71.8% and 77.1% under TCP/22 respectively), which may be due to centralized upstream filtering that leaves downstream destination ASes reachable. While most apparently evaded firewalls are on-path, AFrag and RH2 exhibit a larger portion of host-side signatures (15.3% and 25.1% under TCP/22, 24.5% and 27.3% under UDP/161), which is consistent with a combination of network-level and host-level factors.

Real-world Examples A small-scale test within a campus network confirmed firewall evasion on two ingress routers (Juniper MX 960 and H3C CR16K). After consultation with the campus network administrators, it was established that the evasion occurred because the ACLs on these routers are not configured for deep protocol inspection --- they only checked whether the IPv6 next header was TCP or UDP, and allowed all other types to pass. This made it possible to establish connections to protected SSH services within the campus network by adding Dst and AFrag, achieving unauthorized access. Other EHs (e.g., ESP) were also used to discover live hosts and topology. Prior work has measured firewalls on popular operating systems and confirmed that certain versions of FreeBSD firewalls can be evaded via two Atomic Fragment headers. These real-world examples provide additional support for the interpretation of the measurement results.

Security Considerations This section discusses the security implications of the observations presented in this document.

Potential EH-based Firewall Evasion The measurements indicate widespread potential EH-based firewall evasion signatures affecting nearly 5,000 ASes. If confirmed in a given deployment, such evasion could enable:

1. Stealthy reconnaissance: Attackers may use EH-carrying probes to discover hidden network topologies and live hosts that would otherwise be protected by firewalls.
2. Unauthorized access: Attackers may bypass access control policies by appending EHs to TCP/UDP packets, potentially enabling access to internal services.
3. Amplification of existing attacks: EH-based evasion may be combined with other attack techniques, such as source address spoofing for reflection/amplification attacks.

The potential root causes of these signatures include:

• Implementation flaws: Firewalls may have protocol blind spots for EHs not defined in (e.g., MH, HIP, Shim6), or over-permissive handling of IPSec-related EHs (AH, ESP).
• Security misconfigurations: Firewalls may be configured to inspect only the IPv6 next header field without parsing the full EH chain, effectively treating EH-carrying packets as non-TCP/non-UDP and allowing them to pass.

Attack Surface Expansion The improved reachability of certain EHs, while beneficial for protocol evolution and application deployment, inadvertently expands the network attack surface. Coupled with known EH-based exploits , this trend increases the potential for exploitation.

Recommendations Several strategies can mitigate the firewall evasion issues observed with EHs:

1. Enable deep packet inspection on firewalls: Parse the full EH chain to identify the upper-layer protocol before applying access control rules. However, this may introduce a risk of DoS attacks if malicious probes with numerous or large EHs overwhelm processing capacity.
2. Selective EH filtering: Limit the type, length, and number of EHs allowed, filtering out EHs unnecessary for network operations, as recommended in .
3. Layered approach: For EHs that are permitted, apply deep packet inspection to enable transport-layer firewall rule matching. Such fine-grained, customized filtering can reduce evasion risks while preserving legitimate EH functionality.
4. Outright blocking of EHs: While this would prevent evasion, it would also hinder EH deployment and adoption, limiting long-term network evolution.

IANA Considerations This document has no IANA actions.

References Normative References This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References 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. Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780. This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC 8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet. Knowledge and experience on how to operate IPv4 networks securely is available, whether the operator is an Internet Service Provider (ISP) or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices. This document analyzes the operational security issues associated with several types of networks and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise networks, service provider networks, or managed residential networks. This document analyzes the security implications of IPv6 Extension Headers and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary. This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK] The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light of this security concern. [STANDARDS-TRACK] The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. [STANDARDS-TRACK] The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets are typically sent by hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by some implementations as normal "fragmented traffic" (i.e., they are "reassembled" with any other queued fragments that supposedly correspond to the same original packet). Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 "Packet Too Big" error messages, and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications. Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector. IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field that, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host. The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated. This document discusses the security implications of the generation of IPv6 atomic fragments and a number of interoperability issues associated with IPv6 atomic fragments. It concludes that the aforementioned functionality is undesirable and thus documents the motivation for removing this functionality from an upcoming revision of the core IPv6 protocol specification (RFC 2460). The IPv6 specification allows IPv6 Header Chains of an arbitrary size. The specification also allows options that can, in turn, extend each of the headers. In those scenarios in which the IPv6 Header Chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the First Fragment of a packet may fail to include the entire IPv6 Header Chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the First Fragment of a packet is required to contain the entire IPv6 Header Chain. This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK] This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK] This document specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. [STANDARDS-TRACK] Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets. This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table. The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working. [STANDARDS-TRACK] This document specifies procedures for processing IPv6 Hop-by-Hop options in IPv6 routers and hosts. It modifies the procedures specified in the IPv6 Protocol Specification (RFC 8200) to make processing of the IPv6 Hop-by-Hop Options header practical with the goal of making IPv6 Hop-by-Hop options useful to deploy and use at IPv6 routers and hosts. This document updates RFC 8200. In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK] To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header. The field limits, calculations, and usage in measurement of PDM are included in this document. IANA Tsinghua University

Ethical Considerations The measurements strictly adhere to the ethical guidelines of network measurement, with full consideration of measurement impact, benign probing, and anonymity. Measurement Impact: In compliance with the standards outlined in , the number of packets sent to each target address is limited to one per second, and each probe is only sent once per hop. Probes are distributed across multiple addresses by randomizing target addresses, instead of repeatedly targeting a single address. Additionally, an overall rate limit of 50K packets per second is imposed, which reduces the impact on both the vantage point network and the target network. Benign Probing: All probes are constructed using standard-compliant protocols. No vulnerabilities are exploited and no malicious payloads are crafted. The probes do not carry harmful data, and the responses do not contain personally identifiable or sensitive information. For TCP/22, only half-open probing is performed without establishing full connections. For UDP/161, SNMPv3 Get Requests are sent without any follow-up interaction. Opt-out Mechanism: A public web portal provides research identity and contact information, allowing network administrators to opt out of the scanning scope. To date, no complaints or opt-out requests have been received. Anonymity: Raw IPv6 address details are not publicly disclosed. Only aggregated statistics and analysis results are reported. The collected data is used solely for research purposes.

Measurement Caveats The measurements are subject to several potential limitations that should be considered when interpreting the results. Limited Response Visibility: Some destination ASes or hosts may not generate ICMPv6 responses, while others may process EHs without replying. Since this approach relies on responses from destination ASes or hosts, the absence of such responses may lead to underestimation of EH traversal capability. This limitation leads to conservative estimates rather than overestimation. Single Vantage Point: Using a single vantage point may introduce measurement bias. Identifying vantage points with little or no EH filtering is challenging, as some ISPs filter even basic EHs. While absolute values may vary across vantage points, the observed trends and phenomena are unlikely to be artifacts of a specific vantage point. One-Probe Measurement Noise: Each probe is sent only once to minimize impact on both the vantage point network and target networks. Packet loss and transient network fluctuations may affect a subset of the results, but such effects are inherently random and not systematically biased toward specific EH types. Transient Host Dynamics: During parallel probing, some destination hosts may experience short-term changes in availability or port state. Such transient effects are expected to be limited and are not systematically biased toward specific EH types, and therefore do not materially impact the overall conclusions.

Reproducing the Measurements The 6Travel measurement framework is open-source and publicly available at: https://anonymous.4open.science/r/6Travel. The address dataset and measurement results are also available at the same location. Researchers can use 6Travel to reproduce these measurements or conduct similar studies over time to observe changes in the handling of packets with IPv6 Extension Headers.