RFC8200 Internet Protocol, Version 6 (IPv6) Specification¶
July 2017
Obsoletes: 2460(December 1998)
Obsoletes: 1883(December 1995)
Category: Standards Track
Author: Check Point Software
1. Introduction¶
changes from IPv4 to IPv6¶
Expanded Addressing Capabilities:
a. increases the IP address size from 32 bits to 128 bits b. scalability of multicast routing is improved by adding a "scope" field to multicast addresses. c. a new type of address called an "anycast address" is defined
Header Format Simplification:
Some IPv4 header fields have been dropped or made optional, to reduce the common-case processing cost of packet handling and to limit the bandwidth cost of the IPv6 header.
Improved Support for Extensions and Options
Flow Labeling Capability
Authentication and Privacy Capabilities
2. Terminology¶
node: a device that implements IPv6.
router: a node that forwards IPv6 packets not explicitly addressed to itself.
host: any node that is not a router.
upper layer: a protocol layer immediately above IPv6:
a. transport protocols such as TCP and UDP, b. control protocols such as ICMP, c. routing protocols such as OSPF, d. internet-layer or lower-layer protocols being "tunneled" over (i.e., encapsulated in) IPv6 such as: Internetwork Packet Exchange (IPX), AppleTalk, IPv6 itself.
link: a communication facility or medium over which nodes can communicate at the link layer(the layer immediately below IPv6):
a. Ethernets (simple or bridged); b. PPP links; c. X.25, Frame Relay, ATM networks; d. internet-layer or higher-layer "tunnels", such as tunnels over IPv4 or IPv6 itself.
neighbors: nodes attached to the same link.
interface: a node’s attachment to a link.
address: an IPv6-layer identifier for an interface or a set of interfaces.
packet: an IPv6 header plus payload.
link MTU: the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed over a link.
path MTU: the minimum link MTU of all the links in a path between a source node and a destination node.
3. IPv6 Header Format¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
说明:
Version 4-bit
Internet Protocol version number = 6.
Traffic Class 8-bit
Traffic Class field.
See `Section 7`.
Flow Label 20-bit
flow label.
See `Section 6`.
Payload Length 16-bit
unsigned integer.
Length of the IPv6 payload, i.e.,
the rest of the packet following this IPv6 header, in octets.
Note that:
any extension headers (see Section 4) present are considered part of the payload,
i.e., included in the length count.)
Next Header 8-bit
selector.
Identifies the type of header
immediately following the IPv6 header.
Uses the same values as the IPv4 Protocol field [IANA-PN].
Hop Limit 8-bit
unsigned integer.
Decremented by 1 by each node that forwards the packet.
When forwarding, the packet is discarded if Hop Limit was zero when received or is decremented to zero.
A node that is the destination of a packet should not discard a packet with Hop Limit equal to zero;
it should process the packet normally.
Source Address 128-bit
address of the originator of the packet. See [RFC4291].
Destination Address 128-bit
address of the intended recipient of the packet
(possibly not the ultimate recipient, if a Routing header is present).
See [RFC4291] and Section 4.4.
4. IPv6 Extension Headers¶
As illustrated in these examples, an IPv6 packet may carry zero, one, or more extension headers:
+---------------+------------------------
| IPv6 header | TCP header + data
| |
| Next Header = |
| TCP |
+---------------+------------------------
+---------------+----------------+------------------------
| IPv6 header | Routing header | TCP header + data
| | |
| Next Header = | Next Header = |
| Routing | TCP |
+---------------+----------------+------------------------
+---------------+----------------+-----------------+-----------------
| IPv6 header | Routing header | Fragment header | fragment of TCP
| | | | header + data
| Next Header = | Next Header = | Next Header = |
| Routing | Fragment | TCP |
+---------------+----------------+-----------------+-----------------
A full implementation of IPv6 includes implementation of the following extension headers:
1. Hop-by-Hop Options
2. Fragment
3. Destination Options
4. Routing
5. Authentication
6. Encapsulating Security Payload
The first four are specified in this document;
the last two are specified in [`RFC4302`] and [`RFC4303`], respectively
4.1. Extension Header Order¶
Extension Header Order:
1. IPv6 header
2. Hop-by-Hop Options header
3. Destination Options header
4. Routing header
5. Fragment header
6. Authentication header
7. Encapsulating Security Payload header
8. Destination Options header
9. Upper-Layer header
4.2. Options¶
the Hop-by-Hop Options header and the Destination Options header carry a variable number of "options" that are type-length- value (TLV) encoded in the following format:
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type 8-bit identifier of the type of option.
Opt Data Len 8-bit unsigned integer.
Length of the Option Data field of this option, in octets.
Option Data Variable-length field.
Option-Type-specific data.
Option Type:
highest-order 2 bits:
specify the action that must be taken
if the processing IPv6 node does not recognize the Option Type:
00 - skip over this option and continue processing the header.
01 - discard the packet.
10 - discard the packet and,send an ICMP Parameter Problem
11 - discard the packet and,send an ICMP Parameter Problem
if the packet's Destination Address was not a multicast address
third-highest-order bit:
specifies whether or not the Option Data of that option can change
enroute to the packet's final destination.
0 - Option Data does not change en route
1 - Option Data may change en route
4.3. Hop-by-Hop Options Header¶
Hop-by-Hop Options Header has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector.
Identifies the type of header immediately following the Hop-by-Hop Options header.
Uses the same values as the IPv4 Protocol field [IANA-PN].
Hdr Ext Len 8-bit unsigned integer.
Length of the Hop-by-Hop Options header,
Options described in Section 4.2
4.4. Routing Header¶
The
Routing headeris used by an IPv6 source to list one or more intermediate nodes to be “visited” on the way to a packet’s destination.This function is very similar to IPv4’s
Loose SourceandRecord Route option.
format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector.
Identifies the type of header immediately following the Routing header.
Uses the same values as the IPv4 Protocol field [IANA-PN].
Hdr Ext Len 8-bit unsigned integer.
Length of the Routing header in 8-octet units,
not including the first 8 octets.
Routing Type 8-bit identifier of a particular Routing header variant.
Segments Left 8-bit unsigned integer.
Number of route segments remaining, i.e.,
number of explicitly listed intermediate nodes still to be visited
before reaching the final destination.
type-specific data Variable-length field
of format determined by the `Routing Type`, and
of length such that the complete Routing header
node encounters a Routing header with an unrecognized Routing Type value, the required behavior of the node depends on the value of the Segments Left field, as follows:
If Segments Left is zero, the node must ignore the Routing header
and proceed to process the next header in the packet, whose type
is identified by the Next Header field in the Routing header.
If Segments Left is non-zero, the node must discard the packet and
send an ICMP Parameter Problem, Code 0, message to the packet's
Source Address, pointing to the unrecognized Routing Type.
4.5. Fragment Header¶
The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector.
Reserved 8-bit reserved field.
Fragment Offset 13-bit unsigned integer.
The offset, in 8-octet units, of the data following this header,
relative to the start of the Fragmentable Part of the original packet.
Res 2-bit reserved field.
M flag 1 = more fragments; 0 = last fragment.
Identification 32 bits. See description below.
In order to send a packet that is too large to fit in the MTU of the path to its destination, a source node may divide the packet into fragments and send each fragment as a separate packet, to be reassembled at the receiver.
For every packet that is to be fragmented, the source node generates an Identification value.
original packet:
+------------------+-------------------------+---//----------------+
| Per-Fragment | Extension & Upper-Layer | Fragmentable |
| Headers | Headers | Part |
+------------------+-------------------------+---//----------------+
The fragments are transmitted in separate “fragment packets” as illustrated:
original packet:
+-----------------+-----------------+--------+--------+-//-+--------+
| Per-Fragment |Ext & Upper-Layer| first | second | | last |
| Headers | Headers |fragment|fragment|....|fragment|
+-----------------+-----------------+--------+--------+-//-+--------+
fragment packets:
+------------------+---------+-------------------+----------+
| Per-Fragment |Fragment | Ext & Upper-Layer | first |
| Headers | Header | Headers | fragment |
+------------------+---------+-------------------+----------+
+------------------+--------+-------------------------------+
| Per-Fragment |Fragment| second |
| Headers | Header | fragment |
+------------------+--------+-------------------------------+
o
o
o
+------------------+--------+----------+
| Per-Fragment |Fragment| last |
| Headers | Header | fragment |
+------------------+--------+----------+
The same original packet identified by:
1. Source Address,
2. Destination Address,
3. Fragment Identification
4.6. Destination Options Header¶
The
Destination Options headeris used to carry optional information that need be examined only by a packet’s destination node(s).
format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector.
Hdr Ext Len 8-bit unsigned integer.
Length of the Destination Options header in 8-octet units
Options Variable-length field
4.7. No Next Header¶
The value 59 in the Next Header field of an IPv6 header or any extension header indicates that there is nothing following that header.
4.8. Defining New Extension Headers and Options¶
Defining new IPv6 extension headers is not recommended, unless there are no existing IPv6 extension headers that can be used by specifying a new option for that IPv6 extension header.
A proposal to specify a new IPv6 extension header must include a detailed technical explanation of why an existing IPv6 extension header can not be used for the desired new function.
5. Packet Size Issues¶
IPv6 minimum link MTU is 1280 octets
It is strongly recommended that IPv6 nodes implement
Path MTU Discovery [RFC8201], in order to discover and take advantage of path MTUs greater than 1280 octets.In order to send a packet larger than a path’s MTU, a node may use the IPv6 Fragment header to fragment the packet at the source and have it reassembled at the destination(s).
6. Flow Labels¶
The 20-bit Flow Label field in the IPv6 header is used by a source to label sequences of packets to be treated in the network as a single flow
The current definition of the IPv6 Flow Label can be found in
[RFC6437].
7. Traffic Classes¶
The 8-bit Traffic Class field in the IPv6 header is used by the network for traffic management.
The value of the Traffic Class bits in a received packet or fragment might be different from the value sent by the packet’s source.
The current use of the Traffic Class field for Differentiated Services and Explicit Congestion Notification is specified in [
RFC2474] and [RFC3168].
8. Upper-Layer Protocol Issues¶
8.1. Upper-Layer Checksums¶
the following illustration shows the TCP and UDP “pseudo-header” for IPv6:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upper-Layer Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.2. Maximum Packet Lifetime¶
Unlike IPv4, IPv6 nodes are not required to enforce maximum packet lifetime.
That is the reason the IPv4 “
Time-to-Live” field was renamed “Hop Limit” in IPv6.
8.3. Maximum Upper-Layer Payload Size¶
When computing the maximum payload size available for upper-layer data, an upper-layer protocol must take into account the larger size of the IPv6 header relative to the IPv4 header.
example¶
In IPv4, TCP’s
Maximum Segment Size (MSS)option is computed as the maximum packet size minus 40 octets (20 octets for the minimum-length IPv4 header and 20 octets for the minimum-length TCP header).When using TCP over IPv6, the
MSSmust be computed as the maximum packet size minus 60 octets, because the minimum-length IPv6 header is 20 octets longer than a
8.4. Responding to Packets Carrying Routing Headers¶
only the following kinds of packets are permitted in response to a received packet bearing a Routing header:
• Response packets that do not carry Routing headers.
• Response packets that carry Routing headers that were NOT derived
by reversing the Routing header of the received packet
• Response packets that carry Routing headers that were derived
by reversing the Routing header of the received packet
IF AND ONLY IF the integrity and authenticity of the Source Address and Routing header
from the received packet have been verified by the responder.
9. IANA Considerations¶
referenced in a number of IANA registries. These include:
• Internet Protocol Version 6 (IPv6) Parameters [`IANA-6P`]
• Assigned Internet Protocol Numbers [`IANA-PN`]
• ONC RPC Network Identifiers (netids) [`IANA-NI`]
• Network Layer Protocol Identifiers (NLPIDs) of Interest [`IANA-NL`]
• Protocol Registries [`IANA-PR`]
10. Security Considerations¶
same with ipv4¶
security issues include:
• Eavesdropping,
where on-path elements can observe the whole packet of each IPv6 datagram.
• Replay,
where the attacker records a sequence of packets off of the wire
and plays them back to the party that originally received them.
• Packet insertion,
where the attacker forges a packet with some chosen set of properties
and injects it into the network.
• Packet deletion,
where the attacker removes a packet from the wire.
• Packet modification,
where the attacker removes a packet from the wire,
modifies it, and reinjects it into the network.
• Man-in-the-middle (MITM) attacks,
where the attacker subverts the communication stream
in order to pose as the sender to receiver and the receiver to the sender.
• Denial-of-service (DoS) attacks,
where the attacker sends large amounts of legitimate traffic to a destination
to overwhelm it.
IPv6 packets can be protected from
eavesdropping,replay,packet insertion,packet modification, andMITMattacks by use of the"Security Architecture for the Internet Protocol" [RFC4301].In addition, upper-layer protocols such as
Transport Layer Security (TLS)orSecure Shell (SSH)can be used to protect the application- layer traffic running on top of IPv6.There is not any mechanism to protect against DoS attacks.
compare with ipv4¶
IPv6 addresses are significantly larger than IPv4 addresses making it much harder to scan the address space across the Internet and even on a single network link (e.g., Local Area Network). See [
RFC7707] for more information.IPv6 addresses of nodes are expected to be more visible on the Internet as compared with IPv4 since the use of address translation technology is reduced. This creates some additional privacy issues such as making it easier to distinguish endpoints. See [
RFC7721] for more information.The design of IPv6 extension header architecture, while adding a lot of flexibility, also creates new security challenges. See [
RFC7045] for more information.
This version of the IPv6 specification resolves a number of security issues that were found with the previous version [RFC2460] of the IPv6 specification.
11. References¶
11.1. Normative References
11.2. Informative References