Internet Protocol, Version 6 (IPv6) Specification
obsoleted by
- rfc-2460 — Internet Protocol, Version 6 (IPv6) Specification
Extracted elements (31)
Flow labels are allocated pseudo-randomly so that any set of bits within the 24-bit Flow Label field is suitable for use as a hash key by routers when looking up flow-handling state, enabling efficient per-flow processing without dedicated key negotiation.
ICMPv6 includes the IPv6 pseudo-header in its checksum computation, unlike IPv4 ICMP. This change protects ICMP from misdelivery or corruption of IPv6 header fields on which it depends, which are not covered by an internet-layer checksum in IPv6.
IPv6 packets have an implicit 'Don't Fragment' attribute; there is no explicit DF flag as in IPv4. The ICMPv6 Packet Too Big message always identifies the exact MTU to be used, eliminating the need for the MTU plateau table from RFC-1191.
IPv6 performs fragmentation only at source nodes, not at intermediate routers. This simplifies router processing, reduces per-packet overhead in the network core, and places path MTU responsibility on end systems using Path MTU Discovery (RFC-1191).
The IPv4 'Time to Live' field was renamed 'Hop Limit' in IPv6 because IPv6 nodes are not required to enforce maximum packet lifetime. In practice, very few IPv4 implementations conformed to the lifetime enforcement requirement anyway.
When computing TCP MSS over IPv6, the MSS must be calculated as the maximum packet size minus 60 octets (not 40 as in IPv4), because the minimum-length IPv6 header is 20 octets longer than a minimum-length IPv4 header.
A node must not send fragments that reassemble to a size greater than 1500 octets unless it has explicit knowledge that the destination(s) can reassemble a packet of that size. A node must be able to accept a fragmented packet that, after reassembly, is as large as 1500 octets including the IPv6 header.
All packets belonging to the same flow must be sent with the same source address, destination address, priority, and flow label. If any packet in the flow includes a Hop-by-Hop Options or Routing header, all packets must be originated with the same header contents (excluding the Next Header field) up through and including the Routing header.
Every link in the internet must have an MTU of 576 octets or greater. Links with a configurable MTU must be configured to have an MTU of at least 576 octets; a larger MTU is recommended to accommodate encapsulations without incurring fragmentation.
Extension headers must be processed strictly in the order they appear in the packet. A receiver must not scan for a particular kind of extension header and process it prior to processing all preceding ones.
If a node encounters a Routing header with an unrecognized Routing Type and Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, pointing to the unrecognized Routing Type. If Segments Left is zero, the node must ignore the Routing header and proceed to the next header.
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. If the offset-zero fragment has arrived, an ICMP Time Exceeded -- Fragment Reassembly Time Exceeded message should be sent to the source.
If the length of a non-final fragment (M flag = 1), as derived from the fragment packet's Payload Length, is not a multiple of 8 octets, that fragment must be discarded and an ICMP Parameter Problem, Code 0, should be sent to the source pointing to the Payload Length field.
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.
Multicast addresses must not appear in a Routing header of Type 0, or in the IPv6 Destination Address field of a packet carrying a Routing header of Type 0.
New flow labels must be chosen pseudo-randomly and uniformly from the range 1 to FFFFFF hex. A source must not re-use a flow label for a new flow within the lifetime of any flow-handling state established for the prior use; the minimum interval between flows sharing a label is 6 seconds.
Opportunistically cached flow-handling state must be discarded no more than 6 seconds after it is established, regardless of whether or not packets of the same flow continue to arrive.
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. Every node along the delivery path must examine and process it.
The value 59 in the Next Header field indicates that nothing follows that header. If the IPv6 Payload Length field indicates octets past the end of a header whose Next Header field contains 59, those octets must be ignored and passed on unchanged if the packet is forwarded.
Unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path. Sources use the Fragment header to fragment packets that exceed the path MTU.
Unlike IPv4, the UDP checksum is not optional in IPv6. An IPv6 node must compute a UDP checksum over the packet and the pseudo-header; if the result is zero, it must be changed to hex FFFF. IPv6 receivers must discard UDP packets containing a zero checksum.
Upper-layer protocols that include IP addresses in checksum computation must be modified for IPv6 to use a pseudo-header containing 128-bit source and destination addresses, a 32-bit Payload Length, and Next Header identifying the upper-layer protocol. When a Routing header is present, the final destination address is used.
When an Authentication header is present in the packet, for any option whose data may change en-route (Option Type third-highest-order bit = 1), its entire Option Data field must be treated as zero-valued octets when computing or verifying the packet's authenticating value.
IPv6 uses a linked chain of extension headers, each identified by a Next Header value in the preceding header. A full IPv6 implementation must include: Hop-by-Hop Options (0), Routing Type 0 (43), Fragment (44), Destination Options (60), Authentication (RFC-1826), and Encapsulating Security Payload (RFC-1827).
IPv6 mandates use of the IP Authentication Header (RFC-1826) and IP Encapsulating Security Payload (RFC-1827) in conformance with the Security Architecture for the Internet Protocol (RFC-1825), providing authentication, data integrity, and optional data confidentiality at the network layer.
Type 0 Routing header processing: if Segments Left=0, proceed to next header; if Hdr Ext Len is odd or >46, send ICMP Parameter Problem and discard; if Segments Left > n (address count), send ICMP and discard; otherwise decrement Segments Left, swap Destination Address with Address[i], enforce strict-neighbor constraint (ICMP Destination Unreachable if violated), enforce Hop Limit >1 (ICMP Time Exceeded if not), decrement Hop Limit, and resubmit packet.
The Fragment header (Next Header value 44) encodes: Next Header (8-bit), Reserved (8-bit), Fragment Offset (13-bit unsigned, in 8-octet units relative to Fragmentable Part), Res (2-bit reserved), M flag (1-bit: 1=more fragments, 0=last), and Identification (32-bit).
The IPv6 fixed header is 40 octets: Version (4-bit, value 6), Prio (4-bit priority), Flow Label (24-bit), Payload Length (16-bit unsigned, length of payload excluding IPv6 header; zero if Jumbo Payload option is used), Next Header (8-bit), Hop Limit (8-bit unsigned), Source Address (128-bit), and Destination Address (128-bit).
The Jumbo Payload option (type 194, alignment requirement 4n+2, Opt Data Len=4) carries a 32-bit Jumbo Payload Length encoding the packet length (excluding the IPv6 header) for payloads exceeding 65,535 octets; the IPv6 Payload Length field must be set to zero when this option is present.
The Type 0 Routing header (Next Header value 43) contains: Next Header (8-bit), Hdr Ext Len (8-bit, equals twice the address count, max 46), Routing Type=0 (8-bit), Segments Left (8-bit, max 23), Reserved (8-bit), Strict/Loose Bit Map (24-bit, bit i=1 means strict neighbor hop), and Address[1..n] (each 128-bit).
TLV-encoded options in Hop-by-Hop and Destination Options headers have three fields: Option Type (8-bit; highest two bits encode unrecognized-action, third-highest bit indicates mutability en-route), Opt Data Len (8-bit, length of Option Data in octets), and Option Data (variable-length). Pad1 (type 0) is a special single-octet exception with no length or value fields.