sommai - Fotolia


Using IPv6 atomic fragments for a denial-of-service attack

IPv6 atomic fragments can be dangerous for enterprises. Expert Fernando Gont explains their relation to a new denial-of-service attack vector and how to mitigate the threat.

 This is part two of a series on how Internet Control Message Protocol version 6 can be used for a new denial-of-service attack vector. Part one examined functions of ICMPv6 and how they can be leveraged by attackers.

There are a number of issues associated with IPv6 atomic fragments, which are packets that contain a Fragment Header, even though the actual packets themselves aren't fragmented. The most relevant issue to the topic of this article is that, since IPv6 fragmentation support is implemented by means of IPv6 Extension Headers, IPv6 atomic fragments represent the only case in which the use of IPv6 Extension Headers can be triggered by a third party.

There are at least two scenarios in which the use of IPv6 Extension Headers (and Fragmentation Headers, in particular) may result in a denial-of-service (DoS) attack. These two scenarios are:

  • communication with systems over the public internet; and
  • communication among systems that drop IPv6 fragments.

Since there is widespread dropping of packets that contain IPv6 Extension Headers in the public internet, the use of IPv6 fragmentation may result in the corresponding packets or atomic fragments being dropped.

On the other hand, some systems for which the use of fragmentation is not expected may be configured to drop fragmented traffic, such that fragmentation-based attacks are eliminated. For example, a network administrator may filter fragmented traffic directed to a Border Gateway Protocol (BGP) router to protect the control plane from fragmentation-based attack vectors. However, if the corresponding BGP peer does not drop the ICMPv6 Packet Too Big (PTB) messages referring to the BGP session, an attacker could trigger the use of fragmentation in one of the BGP peers, such that the other BGP peer discards incoming BGP traffic.

Reproducing the attack

The consequences of reproducing the aforementioned attack against a production BGP session could be severe. However, it is mostly harmless to reproduce this attack against the communication between a local host and a web server. Let us assume that our host's IPv6 address is 2001:db8:2::100, and a web site is being served by 2001:db8:1::1. We can test the attack vector with the following steps:

Test the communication with the server by using telnet, as follows: $ telnet 2001:db8:1:1 80. This connection attempt should succeed.

  1. Launch the attack by employing the icmp6 tool of the SI6 Networks' IPv6 Toolkit as follows: # icmp6 --icmp6-packet-too-big -d 2001:db8:1::1 --peer-addr 2001:db8:2::100 --mtu 1000 -o 80 –v.
  2. Test communication with the web server, as in the first step. This new connection attempt should now timeout.

Once the attack packet has been sent to the target server, the DoS scenario will persist for about 10 minutes. For obvious reasons, in order for the attack to succeed, the following conditions must be met:

  1. The server must receive the ICMPv6 PTB attack packet. That is, ICMPv6 PTB messages must not be blocked on the way to the web server.
  2. The network must drop IPv6 fragments.
  3. The server must be able to generate atomic fragments upon receipt of an ICMPv6 PTB error message that advertises a maximum transfer unit (MTU) smaller than 1,280 bytes.


There are a number of possible mitigations for the attack vector described in this article. For a generic server scenario, the following mitigation approaches are available:

  • update the server operating system so it does not produce atomic fragments; or
  • drop (at the server or close to the server) ICMPv6 PTB error messages directed to the server that advertise an MTU smaller than 1,280 bytes; or
  • artificially set the MTU at the server to 1,280 bytes and block all incoming ICMP PTB error messages.

Note that the upcoming revision of the core IPv6 specification will remove support for IPv6 atomic fragments -- the rationale for this change has been documented in RFC 8021 from the Internet Engineering Task Force. In response to RFC 8021, a number of IPv6 implementations, most notably Linux, have already removed support for IPv6 atomic fragments. Most recently, Juniper Networks issued a vulnerability advisory about this issue. 

Dropping ICMPv6 error messages that advertise an MTU smaller than 1,280 bytes could be performed at the server itself or at some packet filtering device protecting the server. However, this would require that the filtering device be able to filter packets based on the contents of the ICMPv6 error message (the MTU field/value); this functionality may or may not be available, depending on the product and vendor.

Finally, artificially setting the server MTU to 1,280 bytes would relieve the server from having to receive and process ICMPv6 PTB error messages, since the packet size would never need to be reduced further than 1,280 bytes. However, this comes at the expense of increased overhead for the data transmitted by the server.

For scenarios where the two endpoints of the data transfer can be expected to be known by the attacker, as in the BGP Peering scenario, the attack vector should be mitigated for both endpoints. Otherwise, as long as the attacker can perform the DoS attack on one direction of the communication, the end result will be the same.


While both the Path MTU Discovery and the fragmentation mechanisms were already present in the IPv4 world, the subtle, but important, differences between the IPv6 and the IPv4 worlds have resulted in a new attack vector that might be overlooked -- particularly by folks coming from the IPv4 world. Enterprises should explore possible mitigation techniques and assess their effectiveness with the right IPv6 security tools.

Next Steps

Find out how different authorization management models can benefit enterprises

Read more on how DNS reverse mapping can scan IPv6 addresses

Discover what enterprise threat intelligence services can and can't do

This was last published in March 2017

Dig Deeper on Network security