IPv6 Packets Header Overview
This topic identifies the IP version 6 (IPv6) packet header and its extensions and options.
The IPv6 Packet Header and SRX Series Overview
Every IPv6 packet at a minimum has a basic packet header, 40 bytes (320 bits) long. They optionally may have extension headers.
For IPv6 packets, flow processing parses the extension headers and transport layer headers in the following way:
If the software encounters a TCP, a UDP, an ESP, an AH, or an ICMPv6 header, it parses the header and assumes that the packet payload corresponds to the specified protocol type.
If the software encounters a hop-by-hop header, a routing and destination header, or a fragment header, it continues to parse the next extension header.
If it encounters the no-next-header extension header, the software detects that the packet is that of an unknown protocol (protocol equals 0).
For other extension headers, the software parses the header and identifies the packet as belonging to the protocol indicated by the extension header.
Understanding IPv6 Packet Header Extensions
IPv6 extension headers contains supplementary information used by network devices (such as routers, switches, and endpoint hosts) to decide how to direct or process an IPv6 packet. The length of each extension header is an integer multiple of 8 octets. This allows subsequent extension headers to use 8-octet structures.
Any header followed by an extension header contains a Next Header value that identifies the extension header type. Extension headers may be placed between the IPv6 header and the upper-layer header in a packet. Figure 1 shows an IPv6 packet with the hop-by-hop options header. Similarly, an IPv6 header can carry zero, one, or more extension headers, each identified by the Next Header field of the preceding header. Extension headers always follow the basic IPv6 header in the order as shown in Table 1:
Table 1: IPv6 Extension Headers
Next Header Value
Specifies delivery parameters at each hop on the path to the destination host.
A hop-by-hop option can appear only following the IPv6 basic header. If it is used, it should be the first extension header. It cannot appear after another extension header.
Specifies packet delivery parameters for either intermediate destination devices or the final destination host. When a packet uses this header.
Defines strict source routing and loose source routing for the packet. (With strict source routing, each intermediate destination device must be a single hop away. With loose source routing, intermediate destination devices can be one or more hops away)
Specifies how to perform IPv6 fragmentation and reassembly services.
A source node uses the fragment extension header to tell the destination node the size of the packet that was fragmented so that the destination node can reassemble the packet.
Provides authentication, data integrity, and anti-replay protection.
Encapsulating Security Payload
Provides data confidentiality, data authentication, and anti-replay protection for Encapsulated Security Payload (ESP) packets.
Destination IP Address
Identifies the host device, or interface on a node, to which the IPv6 packet is to be sent.
The destination address may appear twice, the first instance after the hop limit following the source IP address and the second instance after the final extension header.
For information on IPv6, refer to RFC 2460.
Understanding How SRX Series Devices Handle ICMPv6 Packets
This topic explains Internet Control Message Protocol (ICMP), ICMP messages, and how Junos OS for SRX Series Services Gateways uses them.
ICMP provides a framework for reporting packet processing errors, for diagnostic purposes, and for implementation-specific functions. ICMP error messages make it possible for one node to inform another node that something has gone wrong during the course of data transfer. When IP version 6 (IPv6) was defined, the differences between IP version 4 (IPv4) and it were significant enough to require a new version of ICMP.
Every ICMPv6 message is preceded by an IPv6 header and zero or more IPv6 extension headers. The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header. This is different from the value used to identify ICMP for IPv4. All ICMPv6 error messages have 32 bits of type-specific data to help the packet recipient locate the embedded invoking packet.
Most ICMPv6 packets have the same characteristics and behavior as normal IPv6 packets, and the Junos OS flow module processes them through first path and fast-path processing in the same way that it does normal IPv6 packets. Table 2 shows the ICMPv6 embedded packet types that the flow module handles differently from normal ICMPv6 packets.
For these packets, the flow module uses a tuple that it creates from the embedded ICMPv6 packet to search for a matching session. It continues to process the packet without modifying the maximum transmission unit (MTU) until it finds a matching session, unless it receives an ICMPv6 Packet Too Big message for the interface. In this case, it modifies the MTU size for that interface. If the flow module does not find a matching session or if it cannot obtain a valid IPv6 header from the embedded payload, it drops the packet.
A Packet Too Big message is the only kind of ICMPv6 packet that will cause the flow module to modify an interface.
Table 2: ICMPv6 Packets That Junos OS Handles Differently from Other ICMPv6 Packets
When a packet cannot be delivered because of a problem with the way it is being sent, it is useful to have a feedback mechanism that can tell the source about the problem, including the reason why delivery of the packet failed. For IPv6, the Destination Unreachable message serves this purpose.
Each message includes a code that indicates the nature of the problem that caused the packet delivery to fail. It also includes all or part of the packet that could not be delivered, to help the source device resolve the problem.
When the flow module encounters a Destination Unreachable ICMP packet whose embedded packet header data matches the 5-tuple data for a session, the software terminates the session.
02-Packet Too Big
When the flow module receives an ICMPv6 Packet Too Big message intended for it, the flow module sends the packet to the ICMP protocol stack on the Routing Engine to engage the path maximum transmission unit (path MTU) discovery process.
If the Packet Too Big message does not pertain to the device but rather is a transit packet, the device attempts to match the embedded 5-tuple data with a session.
Note: A Packet Too Big message is the only kind of ICMPv6 packet that will cause the flow module to modify an interface.
When the flow module receives a packet that cannot be delivered because it has exceeded the hop count specified in the basic header hop-by-hop field, it sends this message to inform the packet’s source node that the packet was discarded for this reason.
When the device finds a problem with a field in the IPv6 header or extension headers that makes it impossible for it to process the packet, the software discards it and sends this ICMPv6 message to the packet’s source node, indicating the type and location of the problem.