Defining new IPv6 extension headers is not recommended; the Destination Options header should be used instead for optional destination information, as it provides better handling and backward compatibility. New hop-by-hop options are also discouraged because nodes may be configured to ignore or drop packets containing the Hop-by-Hop Options header.

ip

Extension headers (except Hop-by-Hop Options) are not processed by intermediate nodes — only the destination processes them. This design reduces per-hop processing overhead, a key simplification over IPv4's options mechanism.

ip

ICMPv6 includes the IPv6 pseudo-header in its checksum computation (unlike IPv4 ICMP) to protect ICMP from misdelivery or corruption of IPv6 header fields it depends on, which are not covered by an internet-layer checksum as in IPv4.

ip

IPv6 renamed the IPv4 'Time-to-Live' field to 'Hop Limit' because IPv6 nodes are not required to enforce maximum packet lifetime. In practice, very few IPv4 implementations actually limited packet lifetime, so this is not a change in practice.

ip

When computing TCP's Maximum Segment Size (MSS) over IPv6, upper-layer protocols must subtract 60 octets (not 40 as for IPv4) from the maximum packet size, because the minimum-length IPv6 header is 20 octets longer than a minimum-length IPv4 header.

ip, tcp

All headers through the first upper-layer header must be included in the first fragment. If the first fragment does not include all headers through an Upper-Layer header, that fragment should be discarded and an ICMP Parameter Problem, Code 3, message should be sent.

ip

Each extension header must be an integer multiple of 8 octets long to retain 8-octet alignment for subsequent headers. Multi-octet fields within each extension header must be aligned on their natural boundaries.

ip

Every link in the Internet must have an MTU of 1280 octets or greater (the IPv6 minimum link MTU). On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.

ip

Extension headers must be processed strictly in the order they appear in the packet; a receiver must not scan through a packet looking for a particular kind of extension header and process that header prior to processing all preceding ones.

ip

Fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path. A source node may use the Fragment header to fragment packets larger than the path MTU.

ip

If a destination node encounters an unrecognized Next Header value while processing a header, it should discard the packet and send an ICMP Parameter Problem message with Code 1 ('unrecognized Next Header type encountered') and the Pointer field pointing to the unrecognized value.

ip

If a Routing header with an unrecognized Routing Type is encountered: if Segments Left is zero, the node must ignore the header and proceed; if Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message.

ip

If insufficient fragments are received to complete reassembly within 60 seconds of the first-arriving fragment, reassembly must be abandoned and all received fragments must be discarded. An ICMP Time Exceeded message should be sent if the first fragment has been received.

ip

IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header, which is restricted to appear immediately after an IPv6 header only.

ip

IPv6 nodes must not create overlapping fragments. When reassembling, if any constituent fragment is an overlapping fragment, the entire datagram and all constituent fragments must be silently discarded with no ICMP error message sent.

ip, security

IPv6 receivers must discard UDP packets containing a zero checksum and should log the error. An exception exists for protocols using UDP as a tunnel encapsulation that explicitly enable zero-checksum mode per RFC 6936.

ip, udp

It is strongly recommended that IPv6 nodes implement Path MTU Discovery (RFC 8201) to discover path MTUs greater than 1280 octets. A minimal implementation may restrict itself to sending packets no larger than 1280 octets and omit Path MTU Discovery.

ip

The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header.

ip

When an upper-layer protocol sends packets in response to a received packet with a Routing header, the response must not include a Routing header automatically derived by reversing the received Routing header unless the integrity and authenticity of the received Source Address and Routing header have been verified.

ip, security

Whenever originating a UDP packet, an IPv6 node must compute a UDP checksum over the packet and the pseudo-header. Unlike IPv4, the UDP checksum is not optional for IPv6. If the computation yields zero, it must be changed to hex FFFF.

ip, udp

IPv6 addresses of nodes are more visible on the Internet than IPv4 addresses because address translation technology use is reduced. This makes it easier to distinguish endpoints, creating additional privacy issues. See RFC 7721 for security and privacy considerations for IPv6 address generation mechanisms.

ip, privacy

Fragment reassembly is keyed on the tuple (Source Address, Destination Address, Fragment Identification). Per-Fragment headers from the Offset-zero fragment are retained in the reassembled packet; only the Next Header and Payload Length fields are adjusted.

ip

The 'No Next Header' value (59) in a Next Header field indicates nothing follows that header. Octets past the end of the header with Next Header=59, as indicated by Payload Length, must be ignored and passed on unchanged if the packet is forwarded.

ip

The Option Type byte's two highest-order bits specify the action when the processing node does not recognize the option: 00=skip, 01=discard packet, 10=discard and send ICMP Parameter Problem Code 2 regardless of destination, 11=discard and send ICMP Parameter Problem Code 2 only if destination is not multicast.

ip

This document updates multiple IANA registries previously referencing RFC 2460: 'Internet Protocol Version 6 (IPv6) Parameters', 'Assigned Internet Protocol Numbers', 'ONC RPC Network Identifiers (netids)', 'Network Layer Protocol Identifiers (NLPIDs) of Interest', and 'Protocol Registries'.

ip, registry

IPv6 shares IPv4's fundamental security vulnerabilities: eavesdropping, replay, packet insertion, packet deletion, packet modification, MITM attacks, and DoS attacks. IPsec (RFC 4301) can protect against all except DoS; there is no mechanism in IPv6 to protect against DoS attacks.

ip, security

The Fragment extension header architecture has been revised to fix several security issues from RFC 2460: whole-datagram atomic fragments are now handled correctly, overlapping fragments must be silently discarded, all headers through the Upper-Layer header must be in the first fragment, and RH0 (Type 0 Routing Header) has been removed.

ip, security

Options in Hop-by-Hop and Destination Options headers use TLV encoding: Option Type (8 bits, with highest 2 bits encoding unrecognized-option action and bit 3 encoding mutability), Opt Data Len (8 bits), and Option Data (variable). Pad1 (type 0) is a special single-byte option with no length/value fields; PadN (type 1) carries N-2 zero-valued octets for N-byte padding.

ip

The Fragment header is identified by Next Header value 44 and contains: Next Header (8 bits), Reserved (8 bits), Fragment Offset (13-bit unsigned integer in 8-octet units), Res (2 reserved bits), M flag (1 bit: 1=more fragments, 0=last fragment), and Identification (32 bits).

ip

The Hop-by-Hop Options header is identified by Next Header value 0 and contains: Next Header (8 bits), Hdr Ext Len (8-bit unsigned integer, length in 8-octet units not including first 8 octets), and Options (variable-length TLV-encoded options).

ip

The IPv6 fixed header is 40 octets and contains: Version (4 bits), Traffic Class (8 bits), Flow Label (20 bits), Payload Length (16-bit unsigned integer), Next Header (8-bit selector), Hop Limit (8-bit unsigned integer), Source Address (128 bits), and Destination Address (128 bits).

ip

The Routing header is identified by Next Header value 43 and contains: Next Header (8 bits), Hdr Ext Len (8 bits), Routing Type (8 bits), Segments Left (8-bit unsigned integer), and type-specific data (variable length, must be integer multiple of 8 octets).

ip

The TCP/UDP pseudo-header for IPv6 checksum computation includes: Source Address (128 bits), Destination Address (128 bits), Upper-Layer Packet Length (32 bits), zero padding (24 bits), and Next Header (8 bits). The final destination address must be used when a Routing header is present.

ip, tcp, udp