Extension headers (other than Hop-by-Hop Options) are not examined by routers along the path; only the destination processes them. This design reduces per-hop processing overhead and allows more efficient forwarding compared to IPv4 options.

ip

The IPv4 'Time to Live' field was renamed 'Hop Limit' in IPv6 because IPv6 nodes are not required to enforce maximum packet lifetime based on time, only hop count. IPv4 implementations almost universally decremented TTL only per hop anyway.

ip

The minimum IPv6 MTU was raised from 576 (IPv4) to 1280 octets to avoid excessive fragmentation while still being small enough to pass over most link types without link-layer fragmentation.

ip

The Traffic Class field (8 bits) was designed to mirror IPv4's Type of Service/Precedence bits for differentiated service experiments. Detailed semantics were intentionally deferred to separate documents to allow experimentation before standardization.

ip, diffserv, qos

ICMPv6 includes the IPv6 pseudo-header in its checksum computation, unlike IPv4 ICMP which does not. This change protects ICMPv6 from misdelivery or corruption of IPv6 header fields that are not covered by an internet-layer checksum.

ip

A node must be able to accept a fragmented packet that, after reassembly, is as large as 1500 octets. Upper-layer protocols should not send packets larger than 1500 octets unless assured the destination can reassemble that size.

ip

All packets belonging to the same flow must be sent with the same source address, destination address, and flow label. If any packet includes a Hop-by-Hop Options header, all packets in the flow must carry the same Hop-by-Hop Options header contents.

ip, qos

Every link in the internet must have an MTU of 1280 octets or greater. Links that cannot convey a 1280-octet packet in one piece must provide link-specific fragmentation and reassembly below the IPv6 layer.

ip

Extension headers must be processed strictly in the order they appear in the packet. A receiver must not scan for a particular extension header and process it before processing all preceding ones.

ip

Fragmentation in IPv6 is performed only by source nodes, not by routers along the delivery path. A source node generates a unique Identification value per fragmented packet (same Source Address, Destination Address) maintained as a 32-bit wrap-around counter.

ip

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

ip

If a non-final fragment's length (derived from Payload Length) is not a multiple of 8 octets (M flag=1), the fragment must be discarded and an ICMP Parameter Problem, Code 0, message should be sent pointing to the Payload Length field.

ip

If reassembly is not complete within 60 seconds of the first fragment's arrival, reassembly must be abandoned and all received fragments discarded. If the first fragment (Fragment Offset=0) was received, an ICMP Time Exceeded -- Fragment Reassembly Time Exceeded message should be sent to the source.

ip

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

ip

Multicast addresses must not appear in a Type 0 Routing header or in the IPv6 Destination Address field of a packet carrying a Type 0 Routing header.

ip, multicast

New flow labels must be chosen pseudo-randomly and uniformly from the range 1 to FFFFF hex, to make any bit subset usable as a router hash key. A source must not reuse a flow label for a new flow within the maximum lifetime of any previously established flow state for that label.

ip, qos

The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header and is indicated by Next Header value zero. It must be examined and processed by every node along the delivery path, including source and destination.

ip

Upper-layer protocols that include IP addresses in checksum computation must use 128-bit IPv6 addresses in the IPv6 pseudo-header (Source Address, Destination Address, Upper-Layer Packet Length, zero pad, Next Header). UDP checksums are mandatory in IPv6; a zero-result checksum must be sent as 0xFFFF.

ip, udp, tcp

When an Authentication header is present, any option whose data may change en-route (indicated by the third-highest-order bit of Option Type being 1) must have its entire Option Data treated as zero-valued octets during authenticating value computation.

ip, security

When more than one extension header is used, the recommended order is: IPv6 header, Hop-by-Hop Options, Destination Options (for intermediate nodes), Routing, Fragment, AH, ESP, Destination Options (for final destination), upper-layer header. IPv6 nodes must accept extension headers in any order.

ip

When responding to a received packet that carried 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 (e.g., via Authentication header).

ip, security

Optional internet-layer information is encoded in extension headers placed between the IPv6 header and the upper-layer header. Each extension header is identified by a distinct Next Header value and must be an integer multiple of 8 octets long.

ip

Options in the Hop-by-Hop and Destination Options headers are TLV-encoded: 8-bit Option Type, 8-bit Opt Data Len, variable-length Option Data. The two highest-order bits of the Option Type encode the action to take if the type is unrecognized (skip, discard, discard+ICMP, discard+ICMP if not multicast).

ip

The 20-bit Flow Label field allows a source to label packet sequences requiring special handling (e.g., QoS or real-time service). A flow is uniquely identified by (source address, non-zero flow label); non-flow packets carry a flow label of zero.

ip, qos

The security features of IPv6, including authentication and confidentiality via the Authentication Header (RFC 2402) and Encapsulating Security Payload (RFC 2406), are described in the Security Architecture for the Internet Protocol (RFC 2401). Reversing received Routing headers without authentication verification enables source routing attacks.

ip, security, ipsec

Type 0 Routing header processing: if Segments Left=0, proceed to next header; if Hdr Ext Len is odd, send ICMP Problem and discard; else swap Destination Address with Address[n - SegmentsLeft], decrement Segments Left and Hop Limit, and resubmit for forwarding. Discard if any address is multicast.

ip

The Fragment header (Next Header value 44) contains 8-bit Next Header, 8-bit Reserved, 13-bit Fragment Offset (in 8-octet units), 2-bit Reserved, 1-bit M flag (1=more fragments), and 32-bit Identification.

ip

The Hop-by-Hop Options header contains an 8-bit Next Header, an 8-bit Hdr Ext Len (length in 8-octet units, not including the first 8 octets), and a variable-length Options field containing TLV-encoded options.

ip

The IPv6 fixed header is 40 octets: 4-bit Version=6, 8-bit Traffic Class, 20-bit Flow Label, 16-bit Payload Length, 8-bit Next Header, 8-bit Hop Limit, 128-bit Source Address, 128-bit Destination Address.

ip

The Routing header contains 8-bit Next Header, 8-bit Hdr Ext Len, 8-bit Routing Type, 8-bit Segments Left, and variable-length type-specific data. The Type 0 variant carries a vector of 128-bit intermediate addresses (Address[1..n]).

ip