Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

IPv6 Flow-Based Processing

 

This topic covers information on flow processing for IPv6 traffic and IPv6 sessions.

IPv6 Advanced Flow

IPv6 advanced flow adds IPv6 support for firewall, NAT, NAT-PT, multicast (local link and transit), IPsec, IDP, JSF framework, TCP Proxy, and Session manager on SRX Series devices. MIBs are not used in the IPv6 flow.

In order to avoid the impact on the current IPv4 environment, IPv6 security is used. If IPv6 security is enabled, extended sessions and gates are allocated. The existing address fields and gates are used to store the index of extended sessions or gates. If IPv6 security is disabled, IPv6 security-related resources are not allocated.

New logs are used for IPv6 flow traffic to prevent impact on performance in the existing IPv4 system.

The behavior and implementation of the IPv6 advanced flow are the same as those of IPv4 in most cases.

The implementations of sessions, gates, ip-actions, processing of multithread, distribution, locking, synchronization, serialization, ordering, packet queuing, asynchronous messaging, IKE traffic issues, sanity check, and queues for IPv6 are similar to IPv4 implementations.

Some of the differences are explained below:

  • Header Parse IPv6 advanced flow stops parsing the headers and interprets the packet as the corresponding protocol packet if it encounters the following extension headers:

    • TCP/UDP

    • ESP/AH

    • ICMPv6

    IPv6 advanced flow continues parsing headers if it encounters the following extension headers:

    • Hop-by-Hop

    • Routing and Destination, Fragment

    IPv6 advanced flow interprets the packets as an unknown protocol packet if it encounters the extension header No Next Header

  • Sanity Checks— IPv6 advanced flow supports the following sanity checks:

    • TCP length

    • UDP length

    • Hop-by-hop

    • IP data length error

    • Layer 3 sanity checks (for example, IP version and IP length)

    • ICMPv6 Packets In IPv6 advanced flow, the ICMPv6 packets share the same behavior as normal IPv6 traffic with the following exceptions:

      • Embedded ICMPv6 packet

      • Path MTU message

  • Host Inbound and Outbound Traffic IPv6 advanced flow supports all route and management protocols running on the Routing Engine (RE), including OSPF v3, RIPng, Telnet, and SSH. Note that no flow label is used in the flow.

  • Tunnel Traffic IPv6 advanced flow supports the following tunnel types:

    • IPv4 IP-IP

    • IPv4 GRE

    • IPv4 IPsec

    • Dual-stack lite

  • Events and Logs The following logs are for IPv6-related flow traffic:

    • RT_FLOW_IPVX_SESSION_DENY

    • RT_FLOW_IPVX_SESSION_CREATE

    • RT_FLOW_IPVX_SESSION_CLOSE

Understanding Sessions for IPv6 Flow

This topic gives an overview of flow-based sessions.

Most packet processing occurs in the context of a flow, including management of policies, zones, and most screens. A session is created for the first packet of a flow for the following purposes:

  • To store most of the security measures to be applied to the packets of the flow.

  • To cache information about the state of the flow. For example, logging and counting information for a flow is cached in its session. (Also, some stateful firewall screens rely on threshold values that pertain to individual sessions or across all sessions.)

  • To allocate resources required for features for the flow.

  • To provide a framework for features such as Application Layer Gateways (ALGs).

Understanding IPv6 Flow Processing on SRX5400, SRX5600, and SRX5800 devices

This topic introduces the architecture for the SRX5400, SRX5600, and SRX5800 devices. Flow processing on these devices is similar to that on branch SRX Series devices.

These devices include I/O cards (IOCs) and Services Processing Cards (SPCs) that each contain processing units that process a packet as it traverses the device. These processing units have different responsibilities.

  • A Network Processing Unit (NPU) runs on an IOC. An IOC has one or more NPUs. An NPU processes packets discretely and performs basic flow management functions.

    When an IPv6 packet arrives at an IOC, the packet flow process begins.

    • The NPU performs the following IPv6 sanity checks for the packet:

      • For the IPv6 basic header, it performs the following header checks:

        • Version. It verifies that the header specifies IPv6 for the version.

        • Payload length. It checks the payload length to ensure that the combined length of the IPv6 packet and the Layer 2 header is shorter than the Layer 2 frame length.

        • Hop limit. It checks to ensure that the hop limit does not specify 0 (zero).

        • Address checks. It checks to ensure that the source IP address does not specify ::0 or FF::00 and that the destination IP address does not specify ::0 or ::1.

      • The NPU performs IPv6 extension header checks, including the following:

        • Hop-by-hop options. It verifies that this is the first extension header to follow the IPv6 basic header.

        • Routing extension. It verifies that there is only one routing extension header.

        • Destination options. It verifies that no more than two destination options extension headers are included.

        • Fragment. It verifies that there is only one fragment header.

        Note

        The NPU treats any other extension header as a Layer 4 header.

      • The NPU performs Layer 4 TCP, UDP, and ICMP6 protocol checks, including the following:

        • UDP. It checks to ensure that IP Payload Length packets, other than a first-fragment packet, are at least 8 bytes long.

        • TCP. It checks to ensure that IP Payload Length packets, other than a first-fragment packet, are at least 20 bytes long.

        • ICMPv6. It checks to ensure that IP Payload Length packets, other than a first-fragment packet, are at least 8 bytes long.

    • If the packet specifies a TCP or a UDP protocol, the NPU creates a tuple from the packet header data using the following information:

      • Source IP address

      • Destination IP address

      • Source port

      • Destination port

      • Protocol

      • Virtual router identifier (VRID)

        The device looks up the VRID from a VRID table.

    • For Internet Control Message Protocol version 6 (ICMPv6) packets, the tuple contains the same information as used for the TCP and the UDP search key, except for the source and destination port fields. The source and destination port fields are replaced with the following information extracted from the ICMPv6 packet:

      • For ICMP error packets: The pattern "0x00010001"

      • For ICMP information packets: The type, or code, field identifier

    • For packets with an Authentication Header (AH) or an Encapsulating Security Payload (ESP) header, the search key is the same as that used for the TCP and the UDP tuple, except for the source and destination port fields. In this case, the security parameter index (SPI) field value is used instead of the source and destination ports. For Encapsulating Security Payload (ESP) header and Authentication Header (AH), before enhancements to the cenral point architecture it is hashed by the 3-tuple and the security parameter index (SPI) field, after enhancements to the cenral point architecture it is hashed by an IP pair.

    • If a session exists for the packet’s flow, the NPU sends the packet to the SPU that manages the session.

    • If a matching session does not exist,

      • The NPU sends the packet information to the central point, which creates a pending session.

      • The central point selects an SPU to process the packet and create sessions for it.

      • The SPU then sends session creation messages to the central point and the ingress and egress NPUs, directing them to create a session for the packet flow.

  • A central point, which can run on a dedicated SPU, or share the resources of one if there is only one SPU. A central point takes care of arbitration and allocation of resources, and it distributes sessions in an intelligent way. The central point assigns an SPU to be used for a particular session when the SPU processes the first packet of its flow.

    • For SRX5000 line devices, the central point architecture is divided into two modules—the application central point and the distributed central point (DCP). The App-CP is responsible for global resource management and loading balancing, while DCP is responsible for traffic identification (global session matching). The App-CP functionality runs on the dedicated central point SPU, while the DCP functionality is distributed to the rest of the SPUs.

  • One or more SPUs that run on a Services Processing Card (SPC). All flow-based services for a packet are executed on a single SPU, within the context of a session that is set up for the packet flow.

    The SPC for SRX5000 line devices has two SPUs.

    Several SPCs can be installed in a chassis.

    Primarily, an SPU performs the following tasks:

    • It manages the session and applies security features and other services to the packet.

    • It applies packet-based stateless firewall filters, classifiers, and traffic shapers.

    • If a session does not already exist for a packet, the SPU sends a request message to the NPU that performed the search for the packet’s session, to direct it to add a session for it.

These discrete, cooperating parts of the system store the information identifying whether a session exists for a stream of packets and the information against which a packet is matched to determine if it belongs to an existing session.

Enabling Flow-Based Processing for IPv6 Traffic

You have the following options for handling IPv6 traffic:

  • Drop—Do not forward IPv6 packets. This is the default behavior.

  • Packet-based forwarding—Do not create a session and process according to packet-based features only (includes firewall filters and class of service).

  • Flow-based forwarding—Create a session and process according to packet-based features (including firewall filters and class of service) but also flow-based security features, such as screens and firewall security policy.

To enable flow-based processing for IPv6 traffic, modify the mode statement at the [edit security forwarding-options family inet6] hierarchy level:

The following example shows the CLI commands you use to configure forwarding for IPv6 traffic:

[edit]

user@host# set security forwarding-options family inet6 mode ?
[edit]

user@host# set security forwarding-options family inet6 mode flow-based


user@host# show security forwarding-options

If you change the forwarding option mode for IPv6, you might need to perform a reboot to initialize the configuration change. Table 1 summarizes device status upon configuration change.

Table 1: Device Status Upon Configuration Change

Configuration Change

Commit Warning

Reboot Required

Impact on Existing Traffic Before Reboot

Impact on New Traffic Before Reboot

Drop to flow-based

Yes

Yes

Dropped

Dropped

Drop to packet-based

No

No

Packet-based

Packet-based

Flow-based to packet-based

Yes

Yes

None

Flow sessions created

Flow-based to drop

Yes

Yes

None

Flow sessions created

Packet-based to flow-based

Yes

Yes

Packet-based

Packet-based

Packet-based to drop

No

No

Dropped

Dropped

Flow-Based Processing for IPv6 Traffic on Security Devices

Flow-based processing mode is required for security features such as zones, screens, and firewall policies to function. By default, the SRX Series device is enabled for flow-based forwarding for IPv6 traffic on all devices, apart from the SRX300 Series and SRX550M devices that are set to drop mode. Starting with Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, for the SRX1500 series, SRX4100, SRX4200, SRX5400, SRX5600, SRX5800 and vSRX devices, you do not need to reboot the device when you are switching modes between flow mode, packet mode, and drop mode. For SRX300 Series and SRX550M devices, you must reboot the device when switching between flow mode, packet mode, and drop mode.

SRX300 Series and the SRX550M Devices

When IPv6 is configured on SRX300 Series and the SRX550M devices, the default behavior is set to drop mode because of memory constraints. In this case, you must reboot the device after changing the processing mode from the drop mode default to flow-based processing mode or packet-based processing mode—that is, between modes on these devices.

Note

For drop mode processing, the traffic is dropped directly, it is not forwarded. It differs from packet-mode processing for which the traffic is handled but no security processes are applied.

To process IPv6 traffic on SRX300 Series and the SRX550M devices, you need to configure IPv6 addresses for the transit interfaces that receive and forward the traffic. For information about the inet6 protocol family and procedures for configuring IPv6 addresses for interfaces.

Configuring an SRX Series Device as a Border Router

When an SRX Series device of any type is enabled for flow-based processing or drop mode, to configure the device as a border router you must change the mode to packet-based processing for MPLS. In this case, to configure the SRX device to packet mode for MPLS, use the set security forwarding-options family mpls mode packet-based statement.

Note

As mentioned, for SRX300 Series and the SRX550M devices, whenever you change processing modes, you must reboot the device.

Enabling Flow-Based Processing for IPv6 Traffic on SRX300 Series and SRX550M Devices

To enable flow-based forwarding for IPv6 traffic on SRX300 Series and the SRX550M devices, modify the mode at the [edit security forwarding-options family inet6] hierarchy level:

To configure forwarding for IPv6 traffic on SRX300 Series or an SRX500M device:

  1. Change the forwarding option mode for IPv6 to flow-based.
  2. Review your configuration.
  3. Commit the configuration.
  4. Reboot the device.
Note

For SRX300 Series and SRX500M devices, the device discards IPv6 type 0 Routing Header (RH0) packets.

Using Filters to Display IPv6 Session and Flow Information for SRX Series Services Gateways

Purpose

You can display flow and session information about one or more sessions with the show security flow session command. IPv6 sessions are included in aggregated statistics.

You can use the following filters with the show security flow session command: application, destination-port, destination-prefix, family, idp, interface, nat, protocol, resource-manager, session-identifier, source-port, source-prefix, and tunnel.

Note

Except for the session-identifier filter, the output of all the other filters can be viewed in brief, summary, and extensive mode. Brief mode is the default mode. The output of the session-identifier filter can be viewed only in the brief mode.

You can use the same filter options with the clear security flow session command to terminate sessions.

Action

The following examples show how to use IPv6-related filters to display summaries and details for IPv6 sessions.

Note

Starting in Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, many of these session summaries include CP session IDs.

Filtered summary report based on family

root> show security flow session summary family ?
root> show security flow session summary family inet6

Filtered detailed report based on family

root> show security flow session family ?
root> show security flow session family inet6

Filtered brief report based on family

root> show security flow session family inet brief

Filtered detailed report based on an IPv6 source-prefix

root> show security flow session source-prefix 2001:dbf8::

Multiple-filtered detailed report based on family, protocol and source-prefix

root> show security flow session family inet protocol icmp source-prefix 2001:db8::

Clearing all sessions, including IPv6 sessions

root> clear security flow session all

Clearing only IPv6 sessions

root> clear security flow session family ?
root> clear security flow session family inet6

Related Documentation

Release History Table
Release
Description
By default, the SRX Series device is enabled for flow-based forwarding for IPv6 traffic on all devices, apart from the SRX300 Series and SRX550M devices that are set to drop mode. Starting with Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, for the SRX1500 series, SRX4100, SRX4200, SRX5400, SRX5600, SRX5800 and vSRX devices, you do not need to reboot the device when you are switching modes between flow mode, packet mode, and drop mode. For SRX300 Series and SRX550M devices, you must reboot the device when switching between flow mode, packet mode, and drop mode.
Starting in Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, many of these session summaries include CP session IDs.