Dissemination of Flow Specification Rules for IPv6

3.1. Type 1 - Destination IPv6 Prefix

Encoding: <type (1 octet), length (1 octet), offset (1 octet), pattern (variable), padding(variable) >¶

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 -

The length field indicates the N-th most significant bit in the address where bitwise pattern matching stops.¶

offset -

The offset field indicates the number of most significant address bits to skip before bitwise pattern matching starts.¶

pattern -

Contains the matching pattern. The length of the pattern is defined by the number of bits needed for pattern matching (length minus offset).¶

padding -

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.¶

length = offset = 0 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.¶

3.2. Type 2 - Source IPv6 Prefix

Encoding: <type (1 octet), length (1 octet), offset (1 octet), pattern (variable), padding(variable) >¶

Defines the source prefix to match. The length, offset, pattern and padding are the same as in Section 3.1.¶

3.3. Type 3 - Upper-Layer Protocol

Encoding: <type (1 octet), [numeric_op, value]+>¶

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 [RFC8200] Section 4).¶

This component uses the Numeric Operator (numeric_op) described in [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 3 component values SHOULD be encoded as 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.¶

3.4. Type 7 - ICMPv6 Type

Encoding: <type (1 octet), [numeric_op, value]+>¶

Defines a list of {numeric_op, value} pairs used to match the type field of an ICMPv6 packet (see also [RFC4443] Section 2.1).¶

This component uses the Numeric Operator (numeric_op) described in [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 7 component values SHOULD be encoded as 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.¶

3.5. Type 8 - ICMPv6 Code

Encoding: <type (1 octet), [numeric_op, value]+>¶

Defines a list of {numeric_op, value} pairs used to match the code field of an ICMPv6 packet (see also [RFC4443] Section 2.1).¶

This component uses the Numeric Operator (numeric_op) described in [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 8 component values SHOULD be encoded as 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.¶

3.6. Type 12 - Fragment

Encoding: <type (1 octet), [bitmask_op, bitmask]+>¶

Defines a list of {bitmask_op, bitmask} pairs used to match specific IP fragments.¶

This component uses the Bitmask Operator (bitmask_op) described in [I-D.ietf-idr-rfc5575bis] Section 4.2.1.2. The Type 12 component bitmask MUST be encoded as 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 ([RFC8200] Section 4.5) Fragment Offset is not 0¶

FF -

First fragment - match if IPv6 Fragment Header ([RFC8200] Section 4.5) Fragment Offset is 0 AND M flag is 1¶

LF -

Last fragment - match if IPv6 Fragment Header ([RFC8200] Section 4.5) 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¶

3.7. Type 13 - Flow Label (new)

Encoding: <type (1 octet), [numeric_op, value]+>¶

Contains a list of {numeric_op, value} pairs that are used to match the 20-bit Flow Label IPv6 header field ([RFC8200] Section 3).¶

This component uses the Numeric Operator (numeric_op) described in [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 13 component values SHOULD be encoded as 4-octet quantities (numeric_op len=10).¶

3.8. Encoding Example

+--------+----------------------+-------------------------+----------+
| length | destination          | source                  | ul-proto |
+--------+----------------------+-------------------------+----------+
| 0x12   | 01 20 00 20 01 0D B8 | 02 68 40 12 34 56 78 9A | 03 81 06 |
+--------+----------------------+-------------------------+----------+

    +-------+------------+-------------------------------+
    | Value |            |                               |
    +-------+------------+-------------------------------+
    |  0x12 | length     | 18 octets (len<240 1-octet)   |
    |  0x01 | type       | Type 1 - Dest. IPv6 Prefix    |
    |  0x20 | length     | 32 bit                        |
    |  0x00 | offset     | 0 bit                         |
    |  0x20 | pattern    |                               |
    |  0x01 | pattern    |                               |
    |  0x0D | pattern    |                               |
    |  0xB8 | pattern    | (no padding needed)           |
    |  0x02 | type       | Type 2 - Source IPv6 Prefix   |
    |  0x68 | length     | 104 bit                       |
    |  0x40 | offset     | 64 bit                        |
    |  0x12 | pattern    |                               |
    |  0x34 | pattern    |                               |
    |  0x56 | pattern    |                               |
    |  0x78 | pattern    |                               |
    |  0x9A | pattern    | (no padding needed)           |
    |  0x03 | type       | Type 3 - upper-layer-proto    |
    |  0x81 | numeric_op | end-of-list, value size=1, == |
    |  0x06 | value      | 06                            |
    +-------+------------+-------------------------------+

   +--------+----------------------+-------------------------+
   | length | destination          | source                  |
   +--------+----------------------+-------------------------+
   | 0x0f   | 01 20 00 20 01 0D B8 | 02 68 41 24 68 ac f1 34 |
   +--------+----------------------+-------------------------+

    +-------+-------------+-------------------------------+
    | Value |             |                               |
    +-------+-------------+-------------------------------+
    |  0x0f | length      | 15 octets (len<240 1-octet)   |
    |  0x01 | type        | Type 1 - Dest. IPv6 Prefix    |
    |  0x20 | length      | 32 bit                        |
    |  0x00 | offset      | 0 bit                         |
    |  0x20 | pattern     |                               |
    |  0x01 | pattern     |                               |
    |  0x0D | pattern     |                               |
    |  0xB8 | pattern     | (no padding needed)           |
    |  0x02 | type        | Type 2 - Source IPv6 Prefix   |
    |  0x68 | length      | 104 bit                       |
    |  0x41 | offset      | 65 bit                        |
    |  0x24 | pattern     |                               |
    |  0x68 | pattern     |                               |
    |  0xac | pattern     |                               |
    |  0xf1 | pattern     |                               |
    |  0x34 | pattern/pad | (contains 1 bit padding)      |
    +-------+-------------+-------------------------------+

6.1. Redirect IPv6 (rt-redirect-ipv6) Type/Sub-Type 0x80/TBD

The redirect IPv6 address specific extended community allows the traffic to be redirected to a VRF routing instance that lists the specified IPv6 address specific route-target in its import policy. If several local instances match this criteria, the choice between them is a local matter (for example, the instance with the lowest Route Distinguisher value can be elected).¶

This extended community uses the same encoding as the IPv6 address specific Route Target extended community [RFC5701] Section 2 with the high-order octet of the Type always set to 0x80 and the Sub-Type always TBD.¶

The Local Administrator sub-field contains a number from a numbering space that is administered by the organization to which the IP address carried in the Global Administrator sub-field has been assigned by an appropriate authority.¶

Interferes with: All BGP Flow Specification redirect Traffic Filtering Actions (with itself and those specified in [I-D.ietf-idr-rfc5575bis] Section 7.4).¶