ON THIS PAGE
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 Firewalls. 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 Firewalls.
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.
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. This is the default behavior.
To enable flow-based processing for IPv6 traffic, modify the mode
statement at the [edit security forwarding-options
family inet6
] hierarchy level:
security { forwarding-options { family { inet6 { mode flow-based; } } } }
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 ? Possible completions: drop Disable forwarding flow-based Enable flow-based forwarding packet-based Enable packet-based forwarding [edit] user@host# set security forwarding-options family inet6 mode flow-based user@host# show security forwarding-options family { inet6 { mode flow-based; } }
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.
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 Firewall 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 Virtual Firewall 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.
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 Firewall 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 Series Firewall to packet mode for MPLS, use the set security forwarding-options family mpls mode packet-based
statement.
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:
security { forwarding-options { family { inet6 { mode flow-based; } } } }
To configure forwarding for IPv6 traffic on SRX300 Series or an SRX500M device:
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.
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.
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 ? Possible completions: inet Show IPv4 sessions inet6 Show IPv6/IPv6-NATPT sessions root> show security flow session summary family inet6 Flow Sessions on FPC10 PIC1: Valid sessions: 2 Pending sessions: 0 Invalidated sessions: 0 Sessions in other states: 0 Total sessions: 2 Flow Sessions on FPC10 PIC2: Valid sessions: 1 Pending sessions: 0 Invalidated sessions: 0 Sessions in other states: 0 Total sessions: 1 Flow Sessions on FPC10 PIC3: Valid sessions: 0 Pending sessions: 0 Invalidated sessions: 1 Sessions in other states: 0 Total sessions: 1
Filtered detailed report based on family
root> show security flow session family ? Possible completions: inet Show IPv4 sessions inet6 Show IPv6/IPv6-NATPT sessions root> show security flow session family inet6 Flow Sessions on FPC10 PIC1: Total sessions: 0 Flow Sessions on FPC10 PIC2: Total sessions: 0 Flow Sessions on FPC10 PIC3: Session ID: 430000026, Policy name: default-policy-00/2, Timeout: 1794, Valid In: 2001:db8::10/64712 -> 2001:db8::4/21;tcp If: ge-7/1/0.0, Pkts: 8, Bytes: 562, CP Session ID: 430000025 Out: 2001:db8::4/21 --> 2001:db8::10/64712;tcp, If: ge-7/1/1.0, Pkts: 12, Bytes: 1014, CP Session ID: 430000025 Total sessions: 1
Filtered brief report based on family
root> show security flow session family inet brief Flow Sessions on FPC10 PIC1: Session ID: 410000031, Policy name: default-policy-00/2, Timeout: 48, Valid In: 203.0.113.8/3 --> 198.51.100.11/43053;icmp, If: ge-7/1/0.0, Pkts: 1, Bytes: 84, CP Session ID: 410000039 Out: 198.51.100.11/43053 --> 203.0.113.8/3;icmp, If: ge-7/1/1.0, Pkts: 0, Bytes: 0, CP Session ID: 410000039 Total sessions: 1 Flow Sessions on FPC10 PIC2: Session ID: 420000034, Policy name: default-policy-00/2, Timeout: 48, Valid In: 203.0.113.8/4 --> 198.51.100.11/43053;icmp, If: ge-7/1/0.0, Pkts: 1, Bytes: 84, CP Session ID: 420000041 Out: 198.51.100.11/43053 --> 203.0.113.8/4;icmp, If: ge-7/1/1.0, Pkts: 0, Bytes: 0, CP Session ID: 420000041 Total sessions: 1 Flow Sessions on FPC10 PIC3: Session ID: 430000042, Policy name: default-policy-00/2, Timeout: 44, Valid In: 203.0.113.8/2 --> 198.51.100.11/43053;icmp, If: ge-7/1/0.0, Pkts: 1, Bytes: 84, CP Session ID: 430000041 Out: 198.51.100.11/43053 --> 203.0.113.8/2;icmp, If: ge-7/1/1.0, Pkts: 0, Bytes: 0, CP Session ID: 430000041 Total sessions: 1 2001:dbf8::6:2/32
Filtered detailed report based on an IPv6 source-prefix
root> show security flow session source-prefix 2001:dbf8:: Flow Sessions on FPC10 PIC1: Session ID: 410000066, Policy name: default-policy-00/2, Timeout: 2, Valid In: 2001:dbf8::6:2/3 > 2001:dbf8:5::2/7214;icmp6, If: ge-7/1/0.0, Pkts: 1, Bytes: 104, CP Session ID: 410000076 Out: 2001:dbf8:5::2/7214 --> 2001:dbf8:5::2/323;icmp6, If: .local..0, Pkts: 1, Bytes: 104, CP Session ID: 410000076 Session ID: 410000068, Policy name: default-policy-00/2, Timeout: 2, Valid In: 2001:dbf8::6:2/4 --> 2001:dbf8:5::2/7214;icmp6, If: ge-7/1/0.0, Pkts: 1, Bytes: 104, CP Session ID: 410000077 Out: 2001:dbf8:5::2/7214 --> 2001:dbf8::6:2/4;icmp6, If: .local..0, Pkts: 1, Bytes: 104, CP Session ID: 410000077 Total sessions: 2 Flow Sessions on FPC10 PIC2: Session ID: 420000067, Policy name: default-policy-00/2, Timeout: 28, Valid In: 2001:dbf8::6:2/4 --> 2001:dbf8:5::3/6702;icmp6, If: ge-7/1/0.0, Pkts: 1, Bytes: 104, CP Session ID: 420000080 Out: 2001:dbf8:5::3/6702 --> 2001:dbf8::6:2/4 ;icmp6, If: ge-7/1/1.0, Pkts: 0, Bytes: 0, CP Session ID: 420000080 Total sessions: 1 Flow Sessions on FPC10 PIC3: Session ID: 430000077, Policy name: default-policy-00/2, Timeout: 28, Valid In: 2001:dbf8::6:2/3 --> 2001:dbf8:5::3/6702;icmp6, If: ge-7/1/0.0, Pkts: 1, Bytes: 104, CP Session ID: 430000075 Out: 2001:dbf8:5::3/6702 --> 2001:dbf8::6:2/3;icmp6, If: ge-7/1/1.0, Pkts: 0, Bytes: 0, CP Session ID: 430000075 Session ID: 430000078, Policy name: default-policy-00/2, Timeout: 30, Valid In: 2001:dbf8::6:2/5 --> 2001:dbf8:5::3/6702, If: ge-7/1/0.0, Pkts: 1, Bytes: 104, CP Session ID: 430000076 Out: 2001:dbf8:5::3/6702 --> 2001:dbf8::6:2/5;icmp6, If: ge-7/1/1.0, Pkts: 0, Bytes: 0, CP Session ID: 430000076 Session ID: 430000079, Policy name: default-policy-00/2, Timeout: 2, Valid In: 2001:dbf8::6:2/5 --> 2001:dbf8:5::1/7214;icmp6, If: ge-7/1/0.0, Pkts: 1, Bytes: 104, CP Session ID: 430000077 Out: 2001:dbf8:5::1/7214 --> 2001:dbf8::6:2/5;icmp6, If: .local..0, Pkts: 1, Bytes: 104, CP Session ID: 430000077 Total sessions: 3
Multiple-filtered detailed report based on family, protocol and source-prefix
root> show security flow session family inet protocol icmp source-prefix 2001:db8:: Flow Sessions on FPC10 PIC1: Session ID: 410000074, Policy name: default-policy-00/2, Timeout: 2, Valid In: 2001:dbf8::6:2/1 --> 2001:dbf8:8::2/26935;icmp, If: ge-7/1/0.0, Pkts: 1, Bytes: 84, CP Session ID: 410000195 Out: 2001:dbf8:8::2 --> 2001:dbf8::6:2/1;icmp, If: ge-7/1/1.0, Pkts: 1, Bytes: 84, CP Session ID: 410000195 Total sessions: 1 Flow Sessions on FPC10 PIC2: Session ID: 420000075, Policy name: default-policy-00/2, Timeout: 2, Valid In: 2001:dbf8::6:2/3 --> 2001:dbf8::6:2/26935;icmp, If: ge-7/1/0.0, Pkts: 1, Bytes: 84, CP Session ID: 420000159 Out: 2001:dbf8::6:2/26935 --> 2001:dbf8::6:2/3;icmp, If: ge-7/1/1.0, Pkts: 1, Bytes: 84, CP Session ID: 420000159 Total sessions: 1 Flow Sessions on FPC10 PIC3: Session ID: 430000085, Policy name: default-policy-00/2, Timeout: 2, Valid In: 2001:dbf8::6:2/4 --> 2001:dbf8::6:2/26935;icmp, If: ge-7/1/0.0, Pkts: 1, Bytes: 84, CP Session ID: 430000083 Out: 2001:dbf8::6:2/26935 --> 2001:dbf8::6:2/4;icmp, If: ge-7/1/1.0, Pkts: 1, Bytes: 84, CP Session ID: 430000083 Total sessions: 1
Clearing all sessions, including IPv6 sessions
root> clear security flow session all This command may terminate the current session too. Continue? [yes,no] (no) yes 0 active sessions cleared 1 active sessions cleared 1 active sessions cleared 1 active sessions cleared
Clearing only IPv6 sessions
root> clear security flow session family ? Possible completions: inet Clear IPv4 sessions inet6 Clear IPv6/IPv6-NATPT sessions root> clear security flow session family inet6 0 active sessions cleared 1 active sessions cleared 1 active sessions cleared 1 active sessions cleared
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.