flow record my-app-traffic match ipv6 source address match ipv6 destination address match ipv6 protocol match ipv6 extension map match transport source-port match transport destination-port collect counter packets flow exporter my-exporter destination 2001:DB8:100:200::1 flow monitor my-monitor exporter my-exporter record my-app-traffic interface GigabitEthernet0/0 ipv6 flow monitor my-monitor input
When trying to use the exported information, there might be scenarios where complicated calculations are necessary to understand the information described in a NetFlow record. For example, if someone wanted to only look into flows that contained non-initial IPv6 fragments in IOS, they would need to filter flows where the exported extension map field matches a regular expression of 0x.......[2-3|6-7]. This paper aims to address some of these types of concerns when performing a data analysis of network traffic. We present the mappings that someone could use to match extension maps and destination ports fields for ICMPv6 packets. These techniques could be used in a NetFlow collector that consumes FNF data or when manually trying to filter through FNF data.
IPv6 uses two distinct types of headers: Main/Regular IPv6 Headers and IPv6 Extension Headers. The main IPv6 header is equivalent to the basic IPv4 header. The IPv6 Extension Headers (EHs), as IETF RFC2460 says, are "optional internet-layer information encoded in separate headers that may be placed between the IPv6 header and the upper-layer (i.e. Protocol) header in a packet." IPv6 EHs can be chained together in an IPv6 packet as shown Figure 1.
Figure 1. Chained IPv6 Extension Headers in IPv6 packet
For more details on IPv6 EHs, refer to the IPv6 Extension Headers Review and Considerations document.
There is no predetermined number or type of EHs that exist in a typical IPv6 packet. There could be any combination of EHs with very minimal limitations posed by the protocol itself. Thus, given that there are no direct FNF fields that correspond to each of the different EHs, the EHs need to be encoded in FNF. In Cisco IOS, an IPv6 packet's EHs are encoded in a 32-bit extension map as shown in Table 1.
Table 1. IPv6 FNF Extension Header Map
|Bit 10||Bit 9||Bit 8||Bit 7||Bit 6||Bit 5||Bit 4||Bit 3||Bit 2||Bit 1||Bit 0|
|FRAx: Fragment header - not first fragment
RH: Routing Header (any type)
FRA0: Fragment header - first fragment
UNK: Unknown Layer 4 header (compressed, encrypted, not supported)
HOP: Hop-by-Hop extension header
DST: Destination Options extension header
PAY: Payload compression header
AH: Authentication Header
ESP: Encapsulating Security Payload header
As we can see in Table 1, if a packet has a single Encapsulating Security Payload (ESP) EH then bit 10 is going to be flipped from 0 to 1. That results in a map value of 0x00000400 in hexadecimal (hex). If the packet had both an ESP EH and a Hop-by-Hop (HOP) EH then bits 10 and 6 would each be flipped from 0 to 1, which would then result in a map hex value of 0x0000440. If someone was looking to match on packets that contain an ESP EH, then they should be able to match on both of the above values in the map (i.e. both 0x00000400 and 0x00000440). All packets that have the third hex digit as 4, 5, 6, 7, C, D, E, or F will have bit 10 flipped and thus will contain an ESP Extension Header. In other words, if someone could match the extension map against regex 0x.....[4-7|C-F].., they would be able to match flows that contained packets with an ESP EH present.
Based on the above analysis, Table 2 contains all the regexes that could be used to match on flows that contain various EHs. Of course, we assume that the extension map is configured to be exported in the flow record.
Table 2. IPv6 Extension Header FNF regexes
|Non-Initial Fragments||0x.......[2-3][6-7]||7 dots|
|Initial Fragments||0x.......[8-9][C-D]||7 dots|
|Any Fragments (initial and non-initial)||0x.......[2-3][6-9][C-D]||7 dots|
|Routing Header (any type)||0x.......[4-7][C-D]||7 dots|
|Unknown||0x......[1|3|5|7|9|B|D|F].||6 dots + 1 dot (at end)|
|Hop-by-Hop||0x......[4-7][C-F].||6 dots + 1 dot (at end)|
|Destination Options||0x......[8-9][A-F].||6 dots + 1 dot (at end)|
|Authentication Header||0x.....[2-3|6-7|A-B|E-F]..||5 dots + 2 dots (at end)|
|Encapsulating Security Payload Header||0x.....[4-7|C-F]..||5 dots + 2 dots (at end)|
The regexes in Table 2 could be used in the configuration of a NetFlow collector in order for the collector to be able to recognize the exported extension header encodings. The regexes could also be used when an administrator is trying to look into flows from the IOS CLI (i.e. the local NetFlow cache of the device). The following command filters for flows that contain ESP EHs (readers should note that filtering and pattern matching on NetFlow flows with CLI could add significant load on a production router, so the command below should be used with special care):
Router# show flow monitor my-monitor cache filter ipv6 extension map regexp 0x.....[4-7|C-F].. format table IPV6 EXTENSION MAP IPV6 SRC ADDR IPV6 DST ADDR TRNS SRC PORT TRNS DST PORT IP PROT pkts ================== ============= ============= ============= ============= ======= ==== 0x00000048 2001:DB8:10:8EF6:EFBA:B4CB:22AD:7809 2001:DB8:10:11:C:15C0:0:1 0 261 58 28 0x00000042 2001:DB8:10:8EF6:EFBA:B4CB:22AD:7809 2001:DB8:10:11:C:15C0:0:1 0 0 58 56 0x0000004C 2319:18C7:C622:5C31:2496:4F46:274F:86AB 2001:DB8:10:11:C:15C0:0:1 53 3978 17 15 0x00000046 2319:18C7:C622:5C31:2496:4F46:274F:86AB 2001:DB8:10:11:C:15C0:0:1 0 0 17 45
For ICMPv6, as with IPv4, the packet does not contain any source and destination ports. Instead, ICMP packets contain type and code fields. For example, ICMPv6 Echo Requests are of type=128 and code=0. Keep in mind that FNF records do not contain type and code information so, when collecting FNF records, there is no direct type and code information that can be viewed for ICMP flows.
Cisco IOS encodes the ICMP type and code fields in the 16-bit transport destination port of an FNF exported record by shifting the type value by eight bits and concatenating it with the code. In other words:
dst_port = (ICMP type << 8) | ICMP code
For example, the destination port for an echo request will be:
dst_port = (128 << 8) | 0 = 32768
Readers should note that for IGMP packets the destination port is set to the IGMP type.
Table 3. ICMPv6 message to Destination Port FNF mappings
|1||0||Destination Unreachable No route to destination||256|
|1||1||Destination Unreachable Communication with destination administratively prohibited||257|
|2||0||Packet Too Big||512|
Hop Limit Exceeded in Transit
|4||0||Parameted Problem Erroneous Header Field Encountered||1024|
The destination port values in Table 3 could be used in the configuration of a NetFlow collector in order for the collector to be able to recognize the exported destination port encodings for ICMPv6. The ports could also be used when an administrator is trying to look into flows from the IOS CLI (i.e. the local NetFlow cache of the device). The following command filters for ICMPv6 Echo Request flows (readers should note that filtering and pattern matching on NetFlow flows with CLI could add significant load on a production router, so the command below should be used with special care):
Router# show flow monitor my-monitor cache filter ipv6 protocol 58 transport destination-port 32768 IPV6 SRC ADDR IPV6 DST ADDR TRNS SRC PORT TRNS DST PORT IP PROT pkts ============== =============== ============= ============= ======= ==== 2001:DB8:10:756:3A9D:3959:252E:7BB4 2001:DB8:10:11:C:15C0:0:1 0 14850 58 24 2001:DB8:10:8EF6:EFBA:B4CB:22AD:7809 2001:DB8:10:11:C:15C0:0:1 0 261 58 28 2001:DB8:10:8EF6:EFBA:B4CB:22AD:7809 2001:DB8:10:11:C:15C0:0:1 0 0 58 56
In this whitepaper we saw that due to the format of IPv6 packets, Flexible NetFlow encodes IPv6 Extension Header information in a 32-bit extension map field. Similarly, it encodes ICMP type and code fields in the transport destination port field. This document presented the regular expressions and port numbers to be matched against NetFlow records in order to match various Extension Headers and ICMPv6 message respectively. We hope that it will save time for network administrators who are trying to digest, query, view, or process NetFlow data of flows that contain IPv6 EHs and ICMPv6 messages.
Panos Kampanakis (firstname.lastname@example.org)
Network Consulting Engineer
Special thanks to John Stuppi and Lou Ronnau for their valuable feedback.
IPv6 Extension Headers Review and Considerations
Flexible NetFlow Configuration Guide, Cisco IOS Release 15M&T
Cisco IOS Flexible NetFlow Command Reference
LTRSEC-3033 - Advanced - IPv6 Network Threat Defense, Countermeasures, and Controls (2014 Milan) - 4 Hours
This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.