IPv6 packet
An IPv6 packet is the fundamental unit of data transmission in the Internet Protocol version 6 (IPv6), serving as the successor to IPv4 to address the exhaustion of 32-bit addresses and enable scalable internet growth; it comprises a fixed 40-octet base header, zero or more extension headers for additional functionality, and a variable-length payload that carries upper-layer protocol data.[1]
Developed by the Internet Engineering Task Force (IETF), IPv6 introduces key enhancements over IPv4, including 128-bit source and destination addresses to support approximately 3.4 × 10^38 unique identifiers, elimination of the header checksum for router efficiency, and simplified header processing to reduce overhead in high-speed networks.[1] The base header fields include a 4-bit Version field set to 6, an 8-bit Traffic Class for quality-of-service marking, a 20-bit Flow Label to enable special handling of packet sequences from a source to a destination, a 16-bit Payload Length indicating the size of the data following the header, an 8-bit Next Header field specifying the type of the next header or upper-layer protocol, and an 8-bit Hop Limit that decrements at each router to prevent infinite loops, replacing IPv4's Time to Live.[1]
Extension headers in IPv6 packets provide modular support for features like hop-by-hop options (processed by every intermediate node), routing headers for source-based path specification, fragmentation (performed only at the source, not routers), and destination options (processed only at the final destination), with the Next Header chain linking them in a specific order to ensure proper processing.[1] Unlike IPv4, IPv6 mandates a minimum link MTU of 1280 octets and supports jumbograms for payloads up to 4 gigabytes, facilitating efficient transmission over diverse network links while promoting end-to-end security through integration with IPsec.[1] These design choices make IPv6 packets more future-proof, with approximately 45% of traffic to Google services using IPv6 as of November 2025, driven by the need for expanded addressing in IoT, mobile, and global internet expansion.[2]
Overview
Definition and Purpose
An IPv6 packet consists of an IPv6 header followed by the payload, which may include optional extension headers and upper-layer protocol data.[3] This structure enables the transmission of data across IPv6 networks, where the header provides essential routing and control information while the payload carries the actual content, such as transport layer segments.[4]
The primary purpose of the IPv6 packet format is to serve as the foundational unit for communication in the next-generation Internet Protocol, addressing key limitations of IPv4, including address space exhaustion and inefficient header processing.[5] By expanding the address length to 128 bits, IPv6 packets support a vastly larger number of unique addresses—approximately 3.4 × 10^38—facilitating global scalability without the need for network address translation (NAT) mechanisms commonly used in IPv4.[5] Additionally, the design simplifies the fixed header to eight fields, reducing router processing overhead and enhancing efficiency for high-speed networks.[4]
IPv6 packets also incorporate mechanisms for extensibility through chained extension headers, allowing flexible insertion of options like routing or fragmentation without bloating the base header, which contrasts with IPv4's more rigid options field.[6] This purposeful architecture promotes better support for emerging technologies, such as mobile IP and quality-of-service flows, ensuring long-term adaptability in internetworking.[5] Overall, the IPv6 packet's design prioritizes simplicity, security integration, and scalability to sustain the internet's growth into the foreseeable future.[5]
Key Differences from IPv4
The IPv6 packet header introduces several fundamental changes compared to the IPv4 header to enhance processing efficiency, scalability, and flexibility in modern networks.[1] The IPv6 header is fixed at 40 octets in length, eliminating the variable-length options field present in IPv4, which could extend the header up to 60 octets and complicate router processing.[1] This fixed structure reduces parsing overhead, as routers no longer need to handle variable offsets or checksum recalculation for fragmented packets.[1]
A primary distinction lies in addressing: IPv6 employs 128-bit source and destination addresses, vastly expanding the address space from IPv4's 32-bit format to support approximately 3.4 × 10^38 unique addresses.[1] IPv6 also introduces a 20-bit Flow Label field in the header, absent in IPv4, which enables routers to associate packets belonging to the same flow for quality-of-service handling without relying on deep packet inspection.[1] Additionally, the Traffic Class field (8 bits) in IPv6 replaces IPv4's Type of Service octet, providing similar prioritization but with enhanced semantics for differentiated services.[1]
Fragmentation handling differs significantly: IPv4 allows both hosts and routers to fragment packets using fields in the base header (Identification, Flags, and Fragment Offset), whereas IPv6 restricts fragmentation to the source host only, implemented via a separate Fragment Header extension.[1] This design prevents intermediate routers from fragmenting packets, reducing latency and enabling path MTU discovery to avoid fragmentation altogether.[1] The IPv6 base header omits the IPv4 Header Checksum field entirely, shifting error detection responsibility to upper-layer protocols like TCP or UDP, as link-layer mechanisms are deemed sufficient for header integrity.[1]
IPv6 replaces IPv4's inline options with a chain of optional Extension Headers, each identified by a Next Header field, allowing modular insertion of features like routing or authentication without bloating the base header.[1] For instance, the Hop Limit field (8 bits) supersedes IPv4's Time to Live, decrementing by one per hop to prevent routing loops, but with semantics emphasizing hop count over time-based expiration.[1] These changes collectively streamline packet forwarding, with IPv6 routers typically processing headers faster due to the simplified format and lack of checksum verification.[1]
| Aspect | IPv4 Packet Header | IPv6 Packet Header |
|---|
| Length | Variable (20–60 octets) | Fixed (40 octets) |
| Addresses | 32 bits each | 128 bits each |
| Fragmentation | Supported in base header (routers/hosts) | Source-only, via Fragment Header |
| Checksum | Included in header | Omitted; handled by upper layers |
| Options | Inline, variable-length | Extension Headers (chained, TLV format) |
| Flow Handling | No dedicated field | 20-bit Flow Label |
| Field | Size (bits) | Position (octets) | Purpose |
|---|
| Version | 4 | 0 (bits 0-3) | Specifies IPv6 (value 6). |
| Traffic Class | 8 | 0 (bits 4-7) to 1 (bits 0-3) | Supports differentiated services and explicit congestion notification. |
| Flow Label | 20 | 1 (bits 4-7) to 3 (all bits) | Identifies packets for the same flow to enable consistent handling. |
| Payload Length | 16 | 4-5 | Length of the payload (including extension headers) in octets. |
| Next Header | 8 | 6 | Indicates the type of the next header or upper-layer protocol. |
| Hop Limit | 8 | 7 | Decremented per hop; discards packet if zero to prevent loops. |
| Source Address | 128 | 8-23 | IPv6 address of the sending node. |
| Destination Address | 128 | 24-39 | IPv6 address of the final recipient. |
Hop-by-Hop Options and Destination Options
In IPv6, the Hop-by-Hop Options header carries optional information that must be examined and potentially processed by every node along the packet's delivery path, including intermediate routers and the final destination.[9] This header immediately follows the IPv6 base header when present and is identified by a Next Header value of 0 in the base header.[9] Its format consists of an 8-bit Next Header field indicating the type of the next header, an 8-bit Header Extension Length field specifying the length in 8-octet units (excluding the first 8 octets), and a variable-length Options field containing one or more type-length-value (TLV) encoded options, padded to a multiple of 8 octets.[9] Options are processed in the order they appear, and the header must preserve this order during forwarding.[9] Nodes are not required to process all options but must forward packets containing the header without dropping them solely due to its presence.
Processing of Hop-by-Hop Options has been refined to address performance and security concerns. Routers should process these options at full forwarding rate to avoid bottlenecks, and they must forward packets even if options are skipped or unprocessed.[10] For unrecognized options, the action depends on the two-bit Action field in the Option Type: options with Action 00 (skip if unknown) are ignored and forwarded, while those with 01, 10, or 11 may trigger packet discard with an ICMP Parameter Problem message, though skipping is preferred for efficiency.[10] Sources are encouraged to limit the number of options or order them by priority to minimize processing overhead.[10] Security measures include rate limiting for options like Router Alert to prevent denial-of-service attacks on the control plane.[10]
Common Hop-by-Hop Options include the Router Alert option (Type 5, Action 00), which signals routers to examine the packet for protocols like RSVP or IGMP that require special handling, and the Jumbo Payload option (Type 194 or 0xC2, Action 11), used to indicate payloads larger than 65,535 octets when the base header's Payload Length field is set to 0.[11] The Tunnel Encapsulation Limit option (Type 4, Action 00) specifies the maximum number of encapsulating IPv6 or IPv4 headers allowed, aiding in preventing infinite encapsulation loops.[11] Pad1 (Type 0) and PadN (Type 1) options provide alignment without data.[12] New options, such as those for In Situ Operations, Administration, and Maintenance (IOAM) in RFC 9486, extend capabilities for network telemetry while adhering to these processing rules.[13]
The Destination Options header, in contrast, carries optional information intended solely for processing by the packet's destination node or nodes listed in a Routing header.[14] It shares the same general format as the Hop-by-Hop Options header: an 8-bit Next Header field (value 60 in the preceding header), an 8-bit Header Extension Length, and TLV-encoded Options.[14] This header can appear up to twice in a packet—once before a Routing header (processed by intermediate destinations) and once before the upper-layer header (processed only by the final destination)—but its options are ignored by intermediate nodes.[14] Like Hop-by-Hop Options, unrecognized options follow Action field rules, with skipping recommended for Action 00 to ensure delivery.[12]
A prominent Destination Option is the Home Address option (Type 201 or 0xC9, Action 11), used in Mobile IPv6 to allow a mobile node to send packets using its home address while appearing from its care-of address, facilitating seamless mobility.[11] Pad1 and PadN options are also standard here for alignment.[12] The Tunnel Encapsulation Limit can apply to Destination Options as well.[11] IOAM options may also use this header for end-to-end data collection.[13] Overall, both headers use a shared Option Type numbering space, with the 8-bit type structured as a 2-bit Action field (00: skip unknown, 01: discard and send ICMP, 10: discard no ICMP, 11: discard and send ICMP if feasible), a 5-bit changing field indicating mutable options, and a 1-bit experimental flag.[12]
| Option Type (Hex) | Name | Action | Applicable Header(s) | Purpose | Reference |
|---|
| 0x00 | Pad1 | 00 | Both | Single-octet padding for alignment | RFC 8200 |
| 0x01 | PadN | 00 | Both | Multi-octet padding for alignment | RFC 8200 |
| 0x04 | Tunnel Encapsulation Limit | 00 | Both | Limits encapsulations to prevent loops | RFC 2473 |
| 0x05 | Router Alert | 00 | Hop-by-Hop | Alerts routers to inspect packet for upper-layer protocols | RFC 2711 |
| 0xC2 | Jumbo Payload | 11 | Hop-by-Hop | Supports payloads >65,535 octets | RFC 2675 |
| 0xC9 | Home Address | 11 | Destination | Enables Mobile IPv6 binding updates | RFC 6275 |
+---------------+---------------+---------------+---------------+
| Next Header | Reserved |Fragment Offset|Res|M| Identification |
+---------------+---------------+---------------+---------------+
| |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| Next Header | Reserved |Fragment Offset|Res|M| Identification |
+---------------+---------------+---------------+---------------+
| |
+---------------+---------------+---------------+---------------+
The fields are defined as:
- Next Header (8 bits): Specifies the type of the next header immediately following the Fragment Header, such as an upper-layer protocol (e.g., TCP or UDP) or another extension header in the Fragmentable Part.[1]
- Reserved (8 bits): Set to zero by the sender and ignored by the receiver to allow for future extensions.[1]
- Fragment Offset (13 bits): Indicates the offset of the data in this fragment from the start of the Fragmentable Part, measured in units of 8 octets (64 bits). This field is zero for the first fragment.[1]
- Res (2 bits): Reserved for future use, set to zero by the sender and ignored by the receiver.[1]
- M flag (1 bit): The More Fragments flag; set to 1 if additional fragments follow this one, and 0 for the last fragment.[1]
- Identification (32 bits): A unique identifier generated by the source for each fragmented packet, ensuring correct reassembly when combined with the source and destination addresses; it must not be reused for packets between the same source-destination pair within the maximum packet lifetime.[1]
When fragmenting a packet, the source node creates the first fragment to include all preceding headers (Fixed Header and any non-fragmentable Extension Headers) plus the initial portion of the Fragmentable Part, ensuring it contains a complete upper-layer header if applicable.[1] Subsequent fragments include only the Fragment Header followed by the remaining data portions, with each fragment's length being an integer multiple of 8 octets except possibly the last one.[1] The total reassembled packet size must not exceed 65,535 octets, aligning with IPv6's addressing and header constraints.[1]
Reassembly at the destination relies on matching the Identification field, source address, and destination address across fragments; any overlapping fragments are discarded without generating an ICMP error, and incomplete sets are dropped after 60 seconds.[1] If the first fragment lacks all headers through the upper-layer header, it is discarded, and an ICMP Parameter Problem message may be sent.[1] This header's design supports efficient fragmentation while enhancing security by limiting reassembly to endpoints.[1]
In IPv6, security is primarily provided through the IPsec protocol suite, which integrates authentication and encryption capabilities directly into the packet structure via dedicated extension headers. These headers enable end-to-end or hop-by-hop security services without requiring modifications to the core IPv6 protocol. The two primary security extension headers are the Authentication Header (AH) and the Encapsulating Security Payload (ESP), both of which are processed only at the endpoints or specified intermediate nodes, not by routers in transit.[1][22][23]
The Authentication Header (AH) is designed to provide connectionless integrity, data origin authentication, and optional protection against replay attacks for IPv6 datagrams. It authenticates the entire packet, excluding certain mutable fields like the Hop Limit, by computing an Integrity Check Value (ICV) over the protected portions. AH does not offer confidentiality, focusing instead on verifying that the packet has not been altered in transit and originates from a trusted source. In IPv6, AH is inserted as an extension header following any hop-by-hop options, routing, and fragment headers, but before destination options or the upper-layer protocol header in transport mode; in tunnel mode, it follows the outer IPv6 header. The AH next header value is 51, and its length is expressed in 32-bit words minus 2, ensuring 64-bit alignment for IPv6 compatibility.[22][1]
The structure of the AH consists of several fixed fields followed by the variable ICV:
| Field | Size (bits) | Description |
|---|
| Next Header | 8 | Identifies the type of header following AH (e.g., 44 for Fragment Header or 6 for TCP). |
| Payload Length | 8 | Length of the AH in 32-bit words, excluding the header itself; must be a multiple of 4 for 64-bit alignment in IPv6. |
| Reserved | 16 | Set to zero; included in ICV computation. |
| Security Parameters Index (SPI) | 32 | Identifies the Security Association (SA) used for this packet. |
| Sequence Number | 32 | Monotonic counter for replay protection; supports an optional 64-bit Extended Sequence Number (ESN) where only the lower 32 bits are transmitted. |
| Integrity Check Value (ICV) | Variable (multiple of 32) | Cryptographic hash for integrity; padded to 64-bit boundary in IPv6, computed over the packet with mutable fields zeroed (e.g., Flow Label). |
| Field | Size (bits) | Description |
|---|
| Security Parameters Index (SPI) | 32 | Identifies the SA for decryption and authentication. |
| Sequence Number | 32 | Counter for anti-replay; uses 64-bit ESN with only lower 32 bits transmitted, managed via a receiver window of up to 2^31 packets. |
| Payload Data | Variable | Encrypted original data, including upper-layer headers in transport mode or entire inner packet in tunnel mode. |
| Padding | 0-255 bytes | Optional bytes for block cipher alignment or traffic flow confidentiality (TFC). |
| Pad Length | 8 | Specifies the number of padding bytes. |
| Next Header | 8 | Type of payload following the ESP trailer (e.g., 41 for IPv6). |
| Integrity Check Value (ICV) | Variable | Optional authentication data, computed over the ESP header and payload (excluding padding in some modes). |
Payload
Standard Payload
The standard payload in an IPv6 packet consists of the data that follows the fixed IPv6 header and any optional extension headers, carrying information from upper-layer protocols such as TCP, UDP, or ICMPv6.[1] The size of the IPv6 payload, consisting of any extension headers and the upper-layer protocol data, is indicated by the 16-bit Payload Length field in the fixed header, which specifies the total length in octets (up to 65,535), excluding the 40-octet fixed header. To determine the length of the upper-layer protocol data, subtract the total lengths of any preceding extension headers (each extension header's length is given by its Hdr Ext Len field, in 8-octet units, plus 8 octets) from the Payload Length value.[1] The field supports payloads up to 65,535 octets, making it suitable for most network traffic on links with a minimum transmission unit (MTU) of 1280 octets or greater, as required by IPv6 specifications.[1][1]
When no extension headers are present, the standard payload directly follows the fixed header and encapsulates the complete datagram of the next higher-layer protocol, identified by the Next Header field in the IPv6 header.[1] For example, in a TCP segment over IPv6, the payload includes the TCP header and data, with the protocol's checksum incorporating a pseudo-header that accounts for the source and destination IPv6 addresses, the payload length, and the upper-layer protocol number.[1] Similarly, UDP datagrams in the standard payload use a 16-bit length field that aligns with the IPv6 Payload Length, ensuring compatibility without additional options.[1]
This structure simplifies processing compared to IPv4 by avoiding fragmentation in the standard case, as IPv6 mandates path MTU discovery to accommodate the payload size end-to-end. The Payload Length field is set to zero if the packet contains a Jumbo Payload option for oversized data, distinguishing standard payloads from jumbograms that exceed 65,535 octets via a 32-bit Hop-by-Hop extension.[1][24] In practice, standard payloads dominate IPv6 traffic, supporting efficient transmission over diverse link types while adhering to the protocol's design for streamlined header parsing.[1]
Jumbograms
In IPv6, a jumbogram refers to a packet whose payload length exceeds the standard 65,535 octets limit imposed by the 16-bit Payload Length field in the IPv6 header.[24] This mechanism allows for the transmission of very large payloads, ranging from 65,536 to 4,294,967,295 octets, specifically on links that support a maximum transmission unit (MTU) greater than 65,575 octets.[24] Jumbograms are enabled through the Jumbo Payload option, which is a hop-by-hop option carried in the IPv6 Hop-by-Hop Options extension header.[24]
The Jumbo Payload option replaces the functionality of the IPv6 header's Payload Length field when larger payloads are needed. In a jumbogram, the IPv6 header's Payload Length field is set to zero to signal the presence of this option.[24] The option itself consists of an 8-bit Option Type field with the value 0xC2 (in hexadecimal), an 8-bit Opt Data Length field set to 4, and a 32-bit Jumbo Payload Length field that specifies the total size in octets of the payload following the fixed header (including the Hop-by-Hop Options extension header and any subsequent extension headers, plus upper-layer data), which must be greater than 65,535.[24] The option requires 8-octet alignment (specifically, 4n + 2 padding) to ensure proper processing by intermediate nodes.[24] Jumbograms cannot include a Fragment Header, as IPv6 fragmentation is not permitted for these oversized packets; any attempt to fragment them at the source would violate the specification.[24]
All IPv6 nodes on the path must support the Jumbo Payload option if the link MTU exceeds 65,575 octets, as intermediate routers are required to process hop-by-hop options.[24] Upon receiving a jumbogram, a node uses the Jumbo Payload Length value to determine the total payload size, including any extension headers and upper-layer data. If the option is malformed—such as when the Jumbo Payload Length is 65,535 or less, or if the Payload Length field is non-zero—an ICMPv6 Parameter Problem message is generated with code 0 (erroneous header field).[24] The Jumbo Payload option introduces no new security issues beyond those of standard IPv6 packets, though the larger size may reduce the accuracy of transport-layer checksums due to increased probability of bit errors over the link.[24]
For transport protocols, UDP jumbograms require the UDP header's 16-bit Length field to be set to zero, with the actual length derived from the Jumbo Payload option; the UDP checksum pseudo-header must use the true payload length rather than zero.[25] In TCP, the Maximum Segment Size (MSS) option is adjusted to 65,535 when the path MTU supports jumbograms, effectively treating it as unlimited, while the Urgent Pointer field is capped at 65,535 or handled by segmenting the data if larger.[25] Path MTU Discovery remains essential to negotiate the effective MSS, ensuring compatibility with legacy networks.[25] Although defined in 1999, jumbograms have seen limited adoption due to the rarity of links supporting such large MTUs and sparse implementation in IPv6 stacks. Recent IETF drafts explore extensions like Advanced Jumbos to address limitations in basic jumbograms, but the original mechanism remains part of the IPv6 specification.[26]
Fragmentation
Source Fragmentation
In IPv6, fragmentation is exclusively performed by the source node when a packet exceeds the path's maximum transmission unit (MTU), unlike IPv4 where intermediate routers can also fragment packets. This design choice shifts the responsibility to the sender, enabling routers to process packets more efficiently without fragmentation overhead. The source node relies on Path MTU Discovery (PMTUD) to determine the effective PMTU before transmission; if the packet size surpasses this value, it divides the packet into fragments that each fit within the PMTU.[27][28]
The IPv6 packet structure consists of an unfragmentable part—comprising the IPv6 header, any extension headers present before the Fragment Header, and the upper-layer header—and a fragmentable part, which includes any remaining extension headers and the payload. The source node fragments only the fragmentable part into pieces that are multiples of 8 octets, ensuring alignment. The first fragment includes the complete unfragmentable part followed by the initial portion of the fragmentable part, while subsequent fragments prepend a Fragment Header to their respective portions of the fragmentable part. All fragments share the same source and destination addresses, along with a unique 32-bit Identification value generated by the source to facilitate reassembly at the destination.[27]
The Fragment Header, identified by a Next Header value of 44, is 8 octets long and contains fields for the next header type (8 bits), a reserved field (8 bits), fragment offset (13 bits indicating the offset in 8-octet units from the start of the fragmentable part), two reserved bits, the More Fragments (M) flag (1 bit, set to 1 for non-final fragments and 0 for the last), and the Identification (32 bits). This header is inserted immediately before the fragmentable part in non-initial fragments, allowing the destination to reconstruct the original packet by ordering fragments based on offsets and matching identifications within a 60-second reassembly timeout. If PMTUD indicates a smaller PMTU during transmission, the source may need to retransmit using smaller fragments or abort if the upper-layer protocol prohibits fragmentation.[27][29]
To initiate PMTUD, the source assumes the PMTU equals the MTU of the first-hop link and sends packets accordingly; upon receiving an ICMPv6 "Packet Too Big" message from a constricting node, it reduces the PMTU to the reported value (never below 1280 octets, the IPv6 minimum link MTU) and fragments future packets if necessary. This process avoids unnecessary fragmentation by allowing the source to adapt proactively, though it requires robust handling of potential ICMP blackholing or misconfiguration issues. Hosts are strongly recommended to implement PMTUD to leverage larger MTUs where available, reducing fragmentation occurrences.[28][30]
Reassembly Process
In IPv6, packet reassembly occurs exclusively at the destination host and is not performed by intermediate routers, unlike in IPv4, to simplify routing and reduce processing overhead.[1] The process begins when the destination receives fragments identified by matching source and destination addresses along with the 32-bit Identification field in the Fragment Header, which ensures fragments from the same original packet are grouped together.[1]
The reassembly algorithm positions each fragment using the 13-bit Fragment Offset field, expressed in units of 8 octets from the start of the Fragmentable Part of the original packet.[1] The first fragment, with an offset of zero, carries the full set of headers up to and including the upper-layer header (such as TCP or UDP), while subsequent fragments contain only the Fragment Header followed by data portions.[1] The More Fragments (M) flag in the Fragment Header is set to 1 for all but the last fragment, signaling the receiver to expect additional pieces; when M is 0, reassembly can proceed once all prior fragments are collected.[1] Overlapping fragments are not permitted; if detected, the entire packet is silently discarded to prevent potential security issues like amplification attacks.[1]
Upon complete collection, the reassembled packet is formed by concatenating the fragments in offset order, excluding all Fragment Headers, and computing the Payload Length as the total length of the Fragmentable Part based on fragment sizes and offsets.[1] The destination must support a minimum reassembly buffer of 1500 octets to handle standard maximum transmission unit (MTU) sizes, though larger buffers may be used for efficiency.[1] If reassembly remains incomplete after 60 seconds from the receipt of the first fragment, the process is aborted, and an ICMPv6 Time Exceeded message (Type 3, Code 1) is sent to the source if the first fragment was received, notifying it of the failure.[1]
This design promotes reliable end-to-end delivery while minimizing state maintenance at routers, with the Identification field often generated using a combination of timestamps, counters, or random values to avoid collisions across multiple fragmented packets.[1]
Security Considerations
IPv6 packets share many security vulnerabilities with IPv4, such as eavesdropping, replay attacks, packet insertion, deletion, modification, man-in-the-middle attacks, and denial-of-service (DoS) RFC 8200, Section 11. However, the IPv6 header structure, particularly its extension headers, introduces additional risks due to mandatory processing requirements that can be exploited for resource exhaustion. Protection typically relies on IPsec as defined in the Security Architecture for the Internet Protocol RFC 4301, or upper-layer security like TLS and SSH, though no built-in mechanisms exist to prevent DoS attacks inherent to the protocol RFC 8200, Section 11.
A primary concern is the processing overhead imposed by extension headers, which route packets through the slow path in hardware-accelerated devices, enabling DoS attacks by overwhelming routers with malformed or excessive headers RFC 9099, Section 2.2. For instance, the Hop-by-Hop Options header requires every intermediate router to parse it, potentially causing amplification if combined with fragmentation, while the deprecated Routing Header Type 0 allowed traffic amplification loops before its disablement RFC 9288, Section 3.1. Fragmentation further exacerbates risks, as non-first fragments lack the upper-layer header, allowing bypass of filters that rely on transport-layer information and enabling attacks such as atomic fragment reordering or those using overlapping fragments RFC 7112. Illegal header chains, such as out-of-order or repeated extension headers, can crash nodes if not properly validated RFC 9099, Section 2.2.1.
The Authentication Header (AH) and Encapsulating Security Payload (ESP) provide integrity and confidentiality but are optional, leaving many deployments vulnerable to spoofing in Neighbor Discovery Protocol (NDP) messages carried in IPv6 packets RFC 8200, Section 11. NDP itself, using ICMPv6, is susceptible to rogue Router Advertisements (RAs) that redirect traffic or install false routes, often without cryptographic protection unless extensions like SEND are used RFC 9099, Section 4.1. Additionally, the larger address space reduces brute-force scanning but increases endpoint visibility without Network Address Translation, heightening privacy risks from packet inspection RFC 7707.
Mitigations emphasize perimeter filtering and validation: transit routers should drop packets with deprecated or risky extension headers (e.g., Routing Types 0, 1, 3) using a deny-list approach, while permitting essential ones like Fragment Header only when necessary RFC 9288, Section 5. Rate-limiting ICMPv6 types critical for path MTU discovery and neighbor discovery, combined with RA-Guard to block unauthorized RAs, helps prevent spoofing and DoS RFC 9099, Section 4.2. Source Address Validation (SAVI) and ingress/egress filtering enforce address ownership, reducing amplification from spoofed packets RFC 9099, Section 3.3. Operators must monitor IANA registries for updates on protocol numbers and options to adapt filters dynamically RFC 9288, Section 6.