RFC 2460

RFC 2460
Title	Internet Protocol, Version 6 (IPv6) Specification
Number	2460
Author	Stephen Deering, Robert Hinden
Publication date	December 1998
Status	Proposed Standard
Obsoletes	RFC 1883
Obsoleted by	RFC 8200
Series	RFC
Area	IETF
Stream	IESG
Pages	39

RFC 2460 is a foundational Request for Comments document published by the Internet Engineering Task Force in December 1998. It formally defines the Internet Protocol version 6 (IPv6) specification, establishing the core protocol intended to succeed the aging IPv4. Authored by Stephen Deering and Robert Hinden, it obsoleted the earlier RFC 1883 and was itself superseded by RFC 8200 in 2017. The specification details a new packet header format, a system of extension headers, and mechanisms to support the vastly expanded address space required for the future growth of the Internet.

Overview

RFC 2460 was developed under the auspices of the IETF's IP Next Generation (IPng) working group to address the critical limitations of IPv4, primarily IPv4 address exhaustion. The document provides the complete architectural framework for IPv6, including its fundamental packet structure and operational behaviors. It was designed to restore the original end-to-end principle of the Internet by simplifying packet processing in network routers while enabling new functionality. The protocol introduced by this RFC forms the backbone of modern internetworking, facilitating global connectivity for an ever-expanding array of devices from smartphones to Internet of Things sensors.

IPv6 Header Format

The specification defines a streamlined, fixed-length 40-byte header, a significant simplification compared to the variable-length header of IPv4. Key fields include the 128-bit IPv6 address for both source and destination, which provides the massively expanded address space. The Traffic Class field enables support for Differentiated services and Quality of service (QoS), while the Flow Label field allows for the identification of packets belonging to the same flow. Other essential fields are the Payload Length, which indicates the size of the data following the header, and the Next Header field, which identifies the type of header immediately following the IPv6 header or the protocol of the encapsulated payload, such as TCP or UDP.

Extension Headers

A major innovation in RFC 2460 is the system of extension headers, which are chained together using the Next Header field. This modular approach allows optional internet-layer information to be encoded in separate headers placed between the main IPv6 header and the upper-layer protocol header, like those for ICMPv6. Common extension headers defined include the Hop-by-Hop Options Header for options that must be examined by every node, the Routing Header for source routing, and the Fragment Header for handling packet fragmentation. The Authentication Header and Encapsulating Security Payload header, later detailed in RFC 4302 and RFC 4303, provide the basis for IPsec security, which is a mandatory part of the IPv6 protocol suite.

Packet Size Considerations

The document addresses packet size issues through the concept of Path MTU Discovery, which is strongly recommended over fragmentation. Routers are no longer permitted to fragment packets in transit; instead, they must send an ICMPv6 Packet Too Big message back to the source. Every IPv6 node must be capable of handling a packet of at least 1280 bytes, known as the minimum MTU. For links that cannot transmit a packet of this size, such as some wireless networks, the specification requires link-layer fragmentation and reassembly or the use of an adaptation layer, concepts further explored in documents like RFC 4944 for 6LoWPAN.

Transition from IPv4

While RFC 2460 focuses on the pure IPv6 specification, it acknowledges the long period of coexistence with the existing IPv4 infrastructure. The design inherently supports various transition mechanisms developed by the IETF, such as dual-stack operation where hosts and routers run both protocols simultaneously. Other strategies, including tunneling protocols like 6to4 and Teredo tunneling, and translation mechanisms defined in RFC 6145 and RFC 6146, were created to facilitate interoperability. The global deployment efforts have been coordinated by organizations like the American Registry for Internet Numbers and RIPE NCC.

Security Implications

The architecture described in RFC 2460 integrates security at the internet layer by mandating support for IPsec, a suite defined in the RFC 4301 series. This provides native authentication and encryption for IPv6 packets, offering improvements over the optional, add-on nature of IPsec in IPv4. The use of the Authentication Header and Encapsulating Security Payload extension headers helps protect against threats like packet sniffing and spoofing attacks. Furthermore, features like Neighbor Discovery Protocol, secured through SEcure Neighbor Discovery, and the abandonment of broadcast in favor of multicast can reduce exposure to certain types of Denial-of-service attacks prevalent in IPv4 networks.

Category:Internet Standards Category:Internet protocols Category:Internet architecture Category:Request for Comments