Introduction

Cisco IOS Flexible NetFlow (FNF) is a flow technology which allows for optimization of the network infrastructure, reduction of operating costs, improved capacity planning, and security incident detection with increased flexibility and scalability. FNF can track a wide range of packet information for IPv6 flow, e.g. MAC addresses, IPv6 addresses, and all fields in the IPv6 Header, including the Flow Label, Option Header, and others.

FNF has many benefits above the Cisco traditional NetFlow functionality, which has been available for years in Cisco hardware and software. Some advantages of FNF are flexibility and scalability of flow data beyond traditional NetFlow. Additional benefits include:

The ability to monitor a wider range of packet information producing new information about network behavior not currently available today
Enhanced network anomaly and security detection
Leveraging user configurable flow information to perform customized traffic identification and the ability to focus and monitor specific network behaviors
Convergence of multiple flow monitoring schemes into one accounting mechanism
The ability to define multiple flow monitoring schemes at different points in the network, based on topological and security needs

The following configuration example exports the number of packets based on an IPv6 source and destination address, protocol, TCP source and destination port, and IPv6 Extension Headers for IPv6 flows on the ingress interface, GigabitEthernet0/0. Information is exported to a NetFlow collector with the address 2001:DB8:100.200: :1.

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-Related Flexible NetFlow Regexes and Mappings

Extension Header

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

Bits 11-31	Bit 10	Bit 9	Bit 8	Bit 7	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0
Res	ESP	AH	PAY	DST	HOP	Res	UNK	FRA0	RH	FRAx	Res
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 Res: Reserved

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

Extension Header	Regex	Comment
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

ICMPv6 Type/Code

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

Type	Code	ICMPv6 Message	Port
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
3	0	Time Exceeded Hop Limit Exceeded in Transit	768
4	0	Parameted Problem Erroneous Header Field Encountered	1024
128	0	Echo Request	32768
129	0	Echo Reply	33024

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

Conclusion

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.

Acknowledgments

Panos Kampanakis (pkampana@cisco.com)
Network Consulting Engineer

Special thanks to John Stuppi and Lou Ronnau for their valuable feedback.

References

IPv6 Extension Headers Review and Considerations
www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html

Flexible NetFlow Configuration Guide, Cisco IOS Release 15M&T
www.cisco.com/c/en/us/td/docs/ios-xml/ios/fNetFlow/configuration/15-mt/fnf-15-mt-book.html

Cisco IOS Flexible NetFlow
www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/flexible-NetFlow/product_data_sheet0900aecd804b590b.html

Cisco IOS Flexible NetFlow Command Reference
http://www.cisco.com/c/en/us/td/docs/ios/fNetFlow/command/reference/fnf_book/fnf_02.html#wp1350687

LTRSEC-3033 - Advanced - IPv6 Network Threat Defense, Countermeasures, and Controls (2014 Milan) - 4 Hours
https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76668

This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.

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.