The Recommendation for the IP Next Generation Protocol
Extracted elements (30)
16-byte (128-bit) fixed-length addresses were chosen as the best compromise over 8-byte (64-bit), 20-byte OSI NSAP, and variable-length alternatives. The majority view was that 64-bit addresses were insufficient for the hierarchy needed in the future Internet, while 128 bits supports 10^9 networks even with inherent allocation inefficiency.
IPv6 fragmentation is performed only by source nodes, not intermediate routers. This is a deliberate departure from IPv4 that improves router performance by eliminating the need for routers to handle fragment reassembly or fragmentation of in-transit packets.
The high-order two bits of the Option Type field encode the required action on unrecognized options, enabling incremental deployment of new option types into an operational network with minimal disruption risk. This allows new functionality to be introduced without requiring simultaneous network-wide software upgrades.
The Hop-by-Hop Options header is the only extension header that must be examined by every intermediate router; all other extension headers are processed only at the final destination. This design yields a major improvement in router performance for packets containing options compared to IPv4's inline options.
The IPng Area Directors recommended SIPP (128-bit version, 'Simple Internet Protocol Plus') as the basis for IPng after evaluating CATNIP, SIPP, and TUBA. CATNIP was incomplete; TUBA's CLNP ownership was disputed; SIPP's revised 128-bit proposal resolved the prior concerns about 64-bit addressing and the fatally flawed IPAE transition plan.
The IPv6 header is simplified by dropping or making optional a number of IPv4 header fields (including the header checksum), relocating functions to extension headers, and aligning all fields. Although addresses are four times longer, the IPv6 header is only twice the size of the IPv4 header, and header checksum elimination improves router performance.
The SIPP 64-bit address proposal was rejected primarily because reviewers felt it did not provide adequate space for the routing hierarchy required by the future Internet, and because no operational experience existed with the proposed 'extended addressing' mechanism that would have supplemented 64-bit base addresses.
The revised SIPP proposal synthesized elements from multiple IETF efforts: the basic protocol from SIPP, autoconfiguration and transition influenced by TUBA, addressing structure based on CIDR work, and the Routing Header evolving from SDRP deliberations. Implementations must account for this multi-lineage origin of the specification.
Support for the Authentication Header MUST be required in all IPv6 implementations, and support for a specific authentication algorithm must also be required. This is stated as a specific recommendation in the IPng recommendation.
Support for the Privacy Header is required in IPv6; support for a specific privacy algorithm is also required. The Privacy Header is always the last non-encrypted field in a packet when present.
The Hop Limit field is decremented by 1 by each forwarding node; the packet MUST be discarded if Hop Limit is decremented to zero. This replaces IPv4's TTL and limits the impact of routing loops.
The Payload Length field value of 0 indicates that the actual packet length exceeds 64K bytes and the true length MUST be found in a Hop-by-Hop option, enabling 'jumbogram' payloads larger than 65535 octets.
The Privacy Header (predecessor to ESP) provides confidentiality by encrypting data placed in its Protected Data field. The Security Association Identifier (SAID) combined with the originating address is used by the receiver to identify the correct one-way security association; an authenticated session between two hosts normally uses two SAIDs.
A new 'cluster address' type is defined to identify topological regions rather than individual nodes. Used with the IPv6 Routing Header and source routing capability, it allows nodes additional control over traffic paths and supports SDRP-based source-initiated route selection.
A 'scope' field is added to IPv6 multicast addresses to improve the scalability of multicast routing by defining the reach of a multicast group (e.g., link-local, site-local, global).
IPv6 optional internet-layer information is encoded in separate extension headers placed between the IPv6 header and the transport-layer header. Each extension header is identified by a distinct Next Header value and is not examined by intermediate routers unless it is the Hop-by-Hop Options header.
IPv6 supports address autoconfiguration ranging from plug-and-play serverless configuration (using IEEE 802 address as the low-order node ID part of the 128-bit address) to full DHCP-style allocation. A host must be able to acquire an address dynamically when first attaching or when readdressed.
The End-to-End Options header carries optional information examined only by the packet's destination node(s). It uses the same format as the Hop-by-Hop Options header except it lacks the bit controlling exclusion of option data from the authentication integrity assurance computation.
The Flow Label field (28 bits) allows a source host to label packets requesting special handling by routers, such as non-default quality of service or real-time service. It is a new capability not present in IPv4.
The IANA assigned version number 6 to IPng; the protocol is officially named IPv6. This version number occupies the 4-bit Version field of the IPv6 header.
The IPv6 transition plan meets four requirements: incremental upgrade (IPv4 hosts/routers upgraded independently), incremental deployment (new IPv6 nodes deployed without prerequisites), easy addressing (existing IPv4 addresses reusable), and low start-up costs (no preparation work needed for upgrade).
IPv6 includes packet-level authentication via the Authentication Header and confidentiality via the Privacy Header at the internetwork layer. However, both security features rely on the presence of a yet-to-be-defined key management system, which was identified as an open issue at the time of this recommendation.
The Privacy Header supports security gateways, allowing trustworthy network segments to operate without per-host encryption costs while protecting traffic transiting untrusted segments. Either a transport-layer frame or an entire IPv6 datagram may be encrypted depending on security requirements.
IPv6 TLV options use the format: Option Type (8-bit), Opt Data Len (8-bit, length of Option Data in octets), Option Data (variable). The two high-order bits of Option Type encode the action when the option is unrecognized: 00=skip, 01=discard packet, 10=discard and send ICMP Unrecognized Type, 11=undefined.
The Authentication Header (Next Header value 51) contains: Next Header (8-bit), Auth Data Len (8-bit, in 8-octet units), Reserved (16-bit), Security Association ID (32-bit), and variable-length Authentication Data (integer multiple of 8 octets). The Security Assoc. ID combined with the Source Address identifies the pre-established security association.
The Fragment Header (Next Header value 44) contains: Next Header (8-bit), Reserved, Fragment Offset (13-bit, in 8-octet units), M flag (1=more fragments, 0=last), and Identification (32-bit). Unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along the delivery path.
The Hop-by-Hop Options header (Next Header value 0) carries options that must be examined by every node along the delivery path. Format: Next Header (8-bit), Hdr Ext Len (8-bit, in 8-octet units excluding first 8 octets), followed by variable-length TLV-encoded Options padded to a multiple of 8 octets.
The IPv6 fixed header contains: Version (4-bit), Flow Label (28-bit), Payload Length (16-bit unsigned), Next Header (8-bit selector using IPv4 Protocol field values), Hop Limit (8-bit unsigned), Source Address (128-bit), and Destination Address (128-bit). Total header is 40 octets, twice IPv4 despite four-times-longer addresses.
The Privacy Header provides confidentiality via encryption and contains: SAID (32-bit), Initialization Vector (optional, presence/length SAID-dependent), and encrypted fields: Next Header (8-bit), Length (8-bit), Reserved, Protected Data (variable, may contain full encapsulated IPv6 datagram or transport payload), and algorithm-dependent Trailer.
The Routing Header (Type 1, supporting SDRP) contains: Next Header (8-bit), Routing Type=1 (8-bit), MRE flag, F flag, Reserved, SrcRouteLen (8-bit, max 24), NextHopPtr (8-bit), Strict/Loose Bit Mask (24-bit), and Source Route (list of 128-bit IPv6 addresses including unicast and cluster addresses).