IPv6 Flow-Based Processing Overview

Every IPv6 packet has a minimum 40 bytes (320 bits) long basic packet header. The IPv6 packet header optionally have extension headers, which contains the supplementary information about the network devices.

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.

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:

Figure 1: IPv6 Extension Header

For information on IPv6, refer to RFC2460.

This topic explains Internet Control Message Protocol (ICMP), ICMP messages, and how Junos OS for SRX Series Firewalls 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.