The encoding of each of the components begins with a Type field (1 octet) followed by a variable length parameter. The following sections define component types and parameter encodings for IPv6.
Types 4 (Port), 5 (Destination Port), 6 (Source Port), 9 (TCP Flags), 10 (Packet Length), and 11 (DSCP), as defined in [
RFC 8955], also apply to IPv6. Note that IANA has updated the "Flow Spec Component Types" registry in order to contain both IPv4 and IPv6 Flow Specification component type numbers in a single registry (
Section 8).
-
Encoding:
-
<type (1 octet), length (1 octet), offset (1 octet), pattern (variable), padding (variable) >
This defines the destination prefix to match. The offset has been defined to allow for flexible matching to portions of an IPv6 address where one is required to skip over the first N bits of the address. (These bits skipped are often indicated as "don't care" bits.) This can be especially useful where part of the IPv6 address consists of an embedded IPv4 address, and matching needs to happen only on the embedded IPv4 address. The encoded pattern contains enough octets for the bits used in matching (length minus offset bits).
-
length:
-
This indicates the N-th most significant bit in the address where bitwise pattern matching stops.
-
offset:
-
This indicates the number of most significant address bits to skip before bitwise pattern matching starts.
-
pattern:
-
This contains the matching pattern. The length of the pattern is defined by the number of bits needed for pattern matching (length minus offset).
-
padding:
-
This contains the minimum number of bits required to pad the component to an octet boundary. Padding bits MUST be 0 on encoding and MUST be ignored on decoding.
If length = 0 and offset = 0, this component matches every address; otherwise, length
MUST be in the range offset < length < 129 or the component is malformed.
Note: This Flow Specification component can be represented by the notation ipv6address/length if offset is 0 or ipv6address/offset-length. The ipv6address in this notation is the textual IPv6 representation of the pattern shifted to the right by the number of offset bits. See also
Section 3.8.
-
Encoding:
-
<type (1 octet), length (1 octet), offset (1 octet), pattern (variable), padding (variable) >
This defines the source prefix to match. The length, offset, pattern, and padding are the same as in
Section 3.1.
-
Encoding:
-
<type (1 octet), [numeric_op, value]+>
This contains a list of {numeric_op, value} pairs that are used to match the first Next Header value octet in IPv6 packets that is not an extension header and thus indicates that the next item in the packet is the corresponding upper-layer header (see
Section 4 of
RFC 8200).
This component uses the Numeric Operator (numeric_op) described in
Section 4.2.1.1 of
RFC 8955. Type 3 component values
SHOULD be encoded as a single octet (numeric_op len=00).
Note: While IPv6 allows for more than one Next Header field in the packet, the main goal of the Type 3 Flow Specification component is to match on the first upper-layer IP protocol value. Therefore, the definition is limited to match only on this specific Next Header field in the packet.
-
Encoding:
-
<type (1 octet), [numeric_op, value]+>
This defines a list of {numeric_op, value} pairs used to match the Type field of an ICMPv6 packet (see also
Section 2.1 of
RFC 4443).
This component uses the Numeric Operator (numeric_op) described in
Section 4.2.1.1 of
RFC 8955. Type 7 component values
SHOULD be encoded as a single octet (numeric_op len=00).
In case of the presence of the ICMPv6 type component, only ICMPv6 packets can match the entire Flow Specification. The ICMPv6 type component, if present, never matches when the packet's upper-layer IP protocol value is not 58 (ICMPv6), if the packet is fragmented and this is not the first fragment, or if the system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header.
-
Encoding:
-
<type (1 octet), [numeric_op, value]+>
This defines a list of {numeric_op, value} pairs used to match the code field of an ICMPv6 packet (see also
Section 2.1 of
RFC 4443).
This component uses the Numeric Operator (numeric_op) described in
Section 4.2.1.1 of
RFC 8955. Type 8 component values
SHOULD be encoded as a single octet (numeric_op len=00).
In case of the presence of the ICMPv6 code component, only ICMPv6 packets can match the entire Flow Specification. The ICMPv6 code component, if present, never matches when the packet's upper-layer IP protocol value is not 58 (ICMPv6), if the packet is fragmented and this is not the first fragment, or if the system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header.
-
Encoding:
-
<type (1 octet), [bitmask_op, bitmask]+>
This defines a list of {bitmask_op, bitmask} pairs used to match specific IP fragments.
This component uses the Bitmask Operator (bitmask_op) described in
Section 4.2.1.2 of
RFC 8955. The Type 12 component bitmask
MUST be encoded as a single octet bitmask (bitmask_op len=00).
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 |LF |FF |IsF| 0 |
+---+---+---+---+---+---+---+---+
Bitmask values:
-
IsF:
-
Is a fragment other than the first -- match if IPv6 Fragment Header (Section 4.5 of RFC 8200) Fragment Offset is not 0
-
FF:
-
First fragment -- match if IPv6 Fragment Header (Section 4.5 of RFC 8200) Fragment Offset is 0 AND M flag is 1
-
LF:
-
Last fragment -- match if IPv6 Fragment Header (Section 4.5 of RFC 8200) Fragment Offset is not 0 AND M flag is 0
-
0:
-
MUST be set to 0 on NLRI encoding and MUST be ignored during decoding
-
Encoding:
-
<type (1 octet), [numeric_op, value]+>
This contains a list of {numeric_op, value} pairs that are used to match the 20-bit Flow Label IPv6 header field (
Section 3 of
RFC 8200).
This component uses the Numeric Operator (numeric_op) described in
Section 4.2.1.1 of
RFC 8955. Type 13 component values
SHOULD be encoded as 4-octet quantities (numeric_op len=10).
The following example demonstrates the prefix encoding for packets from ::1234:5678:9a00:0/64-104 to 2001:db8::/32 and upper-layer protocol tcp.
len |
destination |
source |
ul-proto |
0x12 |
01 20 00 20 01 0d bb |
02 68 40 12 34 56 78 9a |
03 81 06 |
Table 1
Decoded:
Value |
|
|
0x12 |
length |
18 octets (if len<240, 1 octet) |
0x01 |
type |
Type 1 - Dest. IPv6 Prefix |
0x20 |
length |
32 bits |
0x00 |
offset |
0 bits |
0x20 |
pattern |
|
0x01 |
pattern |
|
0x0d |
pattern |
|
0xb8 |
pattern |
(no padding needed) |
0x02 |
type |
Type 2 - Source IPv6 Prefix |
0x68 |
length |
104 bits |
0x40 |
offset |
64 bits |
0x12 |
pattern |
|
0x34 |
pattern |
|
0x56 |
pattern |
|
0x78 |
pattern |
|
0x9a |
pattern |
(no padding needed) |
0x03 |
type |
Type 3 - Upper-Layer Protocol |
0x81 |
numeric_op |
end-of-list, value size=1, == |
0x06 |
value |
06 |
Table 2
This constitutes an NLRI with an NLRI length of 18 octets.
Padding is not needed either for the destination prefix pattern (length - offset = 32 bits) or for the source prefix pattern (length - offset = 40 bits), as both patterns end on an octet boundary.
The following example demonstrates the prefix encoding for all packets from ::1234:5678:9a00:0/65-104 to 2001:db8::/32.
length |
destination |
source |
0x0f |
01 20 00 20 01 0d b8 |
02 68 41 24 68 ac f1 34 |
Table 3
Decoded:
Value |
|
|
0x0f |
length |
15 octets (if len<240, 1 octet) |
0x01 |
type |
Type 1 - Dest. IPv6 Prefix |
0x20 |
length |
32 bits |
0x00 |
offset |
0 bits |
0x20 |
pattern |
|
0x01 |
pattern |
|
0x0d |
pattern |
|
0xb8 |
pattern |
(no padding needed) |
0x02 |
type |
Type 2 - Source IPv6 Prefix |
0x68 |
length |
104 bits |
0x41 |
offset |
65 bits |
0x24 |
pattern |
|
0x68 |
pattern |
|
0xac |
pattern |
|
0xf1 |
pattern |
|
0x34 |
pattern/pad |
(contains 1 bit of padding) |
Table 4
This constitutes an NLRI with an NLRI length of 15 octets.
The source prefix pattern is 104 - 65 = 39 bits in length. After the pattern, one bit of padding needs to be added so that the component ends on an octet boundary. However, only the first 39 bits are actually used for bitwise pattern matching, starting with a 65-bit offset from the topmost bit of the address.