Internet-Draft FSv2 More IP Filters May 2024
Hares Expires 4 November 2024 [Page]
IDR Working Group
Intended Status:
Standards Track
S. Hares
Hickory Hill Consulting

BGP Flow Specification Version 2 - More IP Filters


The BGP flow specification version 2 (FSv2) for Basic IP defines user ordering of filters along with FSv1 IP Filters and FSv1 actions. This draft suggests additional IP Filters for Flow Specification FSv2.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 4 November 2024.

1. Introduction

Version 2 of BGP flow specification was original defined in [I-D.ietf-idr-flowspec-v2] (denoted FSv2). However, the full FSv2 specification contains more than initial implementers desired. Therefore, this original FSv2 draft remains an WG draft, but the content will be split out into functions that implementers can manage. Section 1.4 contains the list of documents intended to be the split of the original FSv2 documents.

FSv2 specifies new user-ordered filters that will be used with the IPv4 (AFI=1) and IPv6 (AFI=2) 2 new SAFIs (TBD1, TBD2) for FSv2 to be used with 5 AFIs (1, 2, 6, 25, and 31) to allow user-ordered lists of traffic match filters for user-ordered traffic match actions encoded in Communities (Wide or Extended).

This draft specifies defines extensions to the FSv2 Basic IP package [I-D.hares-idr-fsv2-ip-basic]to support additional IP filters for IP packet and payload. The filters are passed in the Extended IP Filters (type 2) of the subTLVs. This filter form contains a filter version number so filters can be added easily.

BGP Flow Specifiction version 1 (FSv1) as defined in [RFC8955], [RFC8956], and [RFC9117] specified 2 SAFIs (133, 134) to be used with IPv4 AFI (AFI = 1) and IPv6 AFI (AFI=2). FSV2 specifies 2 new SAFIs (TBD1, TBD2) for FSv2 to be used with 5 AFIs (1, 2, 6, 25, and 31) to allow user-ordered lists of traffic match filters for user-ordered traffic match actions encoded in Communities (Wide or Extended). The first SAFI (TBD1) will be used for IP forwarding, and the second SAFI (TBD2) will be used with VPNs. The supported AFI/SAFI combinations in FSV2 are:

  • IPV4 (AFI=1, SAFI=TBD1),

  • IPv6 (AFI=2, SAFI=TBD1),

  • L2 (AFI=6, SAFI=TBD1),

  • SFC (AFI=31, SAFI=TBD1),



  • BGP/MPLS L2VPN (AFI=25, SAFI=TBD2), and


FSv2 specifies new IP filter that will be used with the IPv4 (AFI=1) and IPv6 (AFI=2) 2 new SAFIs (TBD1, TBD2) for FSv2 to be used with 5 AFIs (1, 2, 6, 25, and 31) to allow user-ordered lists of traffic match filters for user-ordered traffic match actions encoded in Communities (Wide or Extended). This document specifies IP filters used with IPvr (AFI=1) and IPv6 (AFI=2).

FSv1 and FSv2 use different AFI/SAFIs to send flow specification filters. Since BGP route selection is performed per AFI/SAFI, this approach can be termed “ships in the night” based on AFI/SAFI.

Section 2 contains a description of the format of the FSv2 NLRI for the the Extended IP Filters type (type 2). Section 3 provides three new Filters approved in IDR WG drafts. Section 4 provides potential filters from individual drafts.

1.1. Definitions and Acronyms

  • AFI - Address Family Identifier

  • AS - Autonomous System

  • BGPSEC - secure BGP [RFC8205] updated by [RFC8206]

  • BGP Session ephemeral state - state which does not survive the loss of BGP peer session.

  • Configuration state - state which persist across a reboot of software module within a routing system or a reboot of a hardware routing device.

  • DDOs - Distributed Denial of Service.

  • Ephemeral state - state which does not survive the reboot of a software module, or a hardware reboot. Ephemeral state can be ephemeral configuration state or operational state.

  • FSv1 - Flow Specification version 1 [RFC8955] [RFC8956]

  • FSv2 - Flow Specification version 2 (this document)

  • NETCONF - The Network Configuration Protocol [RFC6241].

  • RESTCONF - The RESTCONF configuration Protocol [RFC8040]

  • RIB - Routing Information Base.

  • ROA - Route Origin Authentication [RFC6482]

  • RR - Route Reflector.

  • SAFI – Subsequent Address Family Identifier

1.2. RFC 2119 language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals as shown here.

1.3. FSv2 Refesher

Note from Editor: This review section is here for the initial drafts to help with interim. It will be deleted as it is in [I-D.hares-idr-fsv2-ip-basic].

A BGP Flow Specification (version 1 or version 2) is an n-tuple containing one or more match criteria that can be applied to IP traffic, traffic encapsulated in IP traffic or traffic associated with IP traffic. The following are examples of such traffic: IP packet or an IP packet inside a L2 packet (Ethernet), an MPLS packet, and SFC flow.

Flow Specification NLRI may be associated with a set of path attributes depending on the particular application to determine what happens upon matching the data flow filter. FSv1 and FSv2 support specifying the Extended Community specify a set of actions with a default order and known interactions. FSv2 also supports the ability to have user ordered actions by using the FSv2 type of Community BGP Path Attribute.

A particular application is identified by a specific AFI/SAFI (Address Family Identifier/Subsequent Address Family Identifier) and corresponds to a distinct set of RIBs. Those RIBs should be treated independently of each other in order to assure noninterference between distinct applications. FSv1 data is sent in a different NLRI than FSv2 NLRI.

BGP processing treats the NLRI as a key to entries in AFI/SAFI BGP databases. Entries that are placed in the Loc-RIB are then associated with a given set of semantics which are application dependent. Standard BGP mechanisms such as update filtering by NLRI or by attributes such as AS_PATH or large communities apply to the BGP Flow Specification defined NLRI-types.

Network operators can control the propagation of BGP routes by enabling or disabling the exchange of routes for a particular AFI/SAFI pair on a particular peering session. As such, the Flow Specification may be distributed to only a portion of the BGP infrastructure.

Flow Specification v2 allows the user to order the flow specification rules and the actions associated with a rule. Each FSv2 rule may have one or more match conditions and one or more associated actions. The IDR WG draft [I-D.ietf-idr-flowspec-v2] contains the complete solution for FSv2. However, this complete solution makes implementation of these features a large task so, please see the next section on how the complete solution is broken into a series of solutions. This section describres the complete solution.

This FSv2 specification supports the components and actions for the following:

  • IPv4 (AFI=1, SAFI=TBD1) [defined in FSv2-DDOS],

  • IPv6 (AFI=2, SAFI=TBD2) [defined in FSv2-DDOS],

  • L2 (AFI=6, SAFI=TDB1) [defined in FSv2-L2],



  • BGP/MPLS L2VPN (AFI=25, SAFI=TDB2) [defined in FSv2-L2],

  • SFC: (AFI=31, SAFI=TBD1) [defined in FSv2-SFC], and

  • SFC VPN (AFI=31, SAFI=TBD2) [defined in FSv2-SFC].

The FSv2 specification for tunnel traffic is outside the scope of this specification. The FSv1 specification for tunneled traffic is in [I-D.ietf-idr-flowspec-nvo3]. The FSv2 tunnel traffic for FSv2 will be added to this list.

FSv2 operates in the ships-in-the night model with FSv1 so network operators can manipulate which the distribution of FSv2 and FSv1 using configuration parameters. Since the lack of deterministic ordering was an FSv1 problem, this specification provides rules and protocol features to keep filters in a deterministic order between FSv1 and FSv2.

The basic principles regarding ordering of flow specification filter rules are:

  • 1) Rule-0 (zero) is defined to be 0/0 with the “permit-all” action.

  • 2) FSv2 rules are ordered based on user-specified order.

    • The user-specified order is carried in the FSv2 NLRI and a numerical lower value takes precedence over a numerically higher value. For rules received with the same order value, the FSv1 rules apply (order by component type and then by value of the components).

  • 3) FSv2 rules are added starting with Rule 1 and FSv1 rules are added after FSv2 rules

    • For example, BGP Peer A has FSv2 data base with 10 FSv2 rules (1-10). FSv1 user number is configured to start at 301 so 10 FSv1 rules are added at 301-310.

  • 4) An FSv2 peer may receive BGP NLRI routes from a FSv1 peer or a BGP peer that does not support FSv1 or FSv2. The capabilities sent by a BGP peer indicate whether the AFI/SAFI can be received (FSv1 NLRI or FSv2 NLRI).

  • 5) Associate a chain of actions to rules based on user-defined action number (1-n). (optional)

    • If no actions are associated with a filter rule, the default is to drop traffic the filter rules match

    • An action chain of 1-n actions can be associated with a set of filter rules can via Extended Communities or Wide Communities. Only Wide Communities can associate a user-defined order for the actions. Extended Community actions occur after actions with a user specified order (see section 5.2 for details).

Figure 2-2 provides a logical diagram of the FSv2 structure

       |          Rule Group            |
         ^          ^                  ^
         |          |---------         |
         |                   |         ------
         |                   |               |
+--------^-------+   +-------^-----+     +---^-----+
|      Rule1     |   |     Rule2   | ... |  Rule-n |
+----------------+   +-------------+     +---------+
                      :  :   :    :
    :.................:  :   :    :
    :        |...........:   :    :
 +--V--+ +--V-------+        :    :
 |order| |identifie | .......:    :
 +-----+ +----------+ :           :
                      :           :
   +------------------V--+  +-----V----------------+
   |Rule Match condition |  | Rule Action          |
   +---------------------+  +----------------------+
    :      :     :    :       :      :   :   :   |
 +--V--+   :     :    :    +--V---+  :   :   :   V
 | Rule|   :     :    :    |action|  :   :   :  +-----------+
 | name|   :     :    :    |order |  :   :   :  |action name|
 +-----+   :     :    :    +------+  :   :   :  +-----------+
           :     :    :              :   :   :.............
           :     :    :              :   :                :
      .....:     .    :.....       ..:   :......          :
      :          :         :       :           :          :
 +----V---+  +---V----+ +--V---+ +-V------+ +--V-----+ +--V---+
 |  Match |  | match  | |match | | Action | | action | |action|
 |Operator|  |variable| |Value | |Operator| |Variable| | Value|
 +--------+  +--------+ +------+ +--------+ +--------+ +------+

   Figure 2-2: BGP FSv2 Data storage

1.4. FSv2 Series of Specifications

The full FSV2 information is contained in [I-D.ietf-idr-flowspec-v2].

Feedback from the implementers indicate that the Flow Specification v2 needs to broken into drafts based on the use cases the technology supports. These include IPv4/IPv6 IP Basic Filters for DDOS, IPv4/IPv6 filters beyond DDOS, BGP/MPLS IPv4 VPN, BGP/MPLS IPv6 VPN, BGP/MPLS L2VPN, Segment routing (SRMPLS, SRv6), SFC, SFC VPN, L2, L2 VPNs, and tunneled traffic (e.g., nv03 WG tunnels).

The following is the list of planned drafts:

FSv2 IP Basic:

The first draft will support IP filter functions (Type 1) and Extended Community actions supported by [RFC8955] and [RFC8956] with additions to provide the following:

  • user ordering of IP filters

  • no support for user ordering of actions

  • a new FSv2 Actions (FSv2 AO) in an Extended Community that deals with and interaction of other Extended Community Actions for FSv2.

This draft provides the basic functions all other FSv2 drafts will extend.

FSv2 More IP Filters: (draft-ietf-hares-idr-fsv2-more-IP-filters)
This draft is the describes additional IP packet filters for FSv2. Drafts may be proposed to be included in this draft or extend this draft.
FSv2 More IP Actions (draft-ietf-hares-idr-fsv2-more-IP-actions):

This draft is the describes describes how FSv2 actions can be described as either:

FSv2 Extended Community Actions
for generic, IPv4, or IPv6 (v4 and v6) with no user ordering. Each Extended Community actions will be required to provide interactions with other Actions and abide by the Basic ordering. Basic ordering will provide a choice of defined ordering or implementation specific knobs.
FSv2 Wide Community Actions in Type 2 Community Container
This draft provides Wide Community actions in the type 2 format of the Community attribute.

This draft will also define FSv2 Wide community actions for existing Extended Community actions.

FSv2 Non-IP Filters(draft-hares-idr-fsv2-non-IP-Filters):

This draft defines FSv2 non-IP filters in data packets passed by MPLS packets, Segment Routing packets (SR-MPLS or SRv6), SFC, L2, and tunnels. Previous work in this area includes:

FSV2 work on MPLS filters:
MPLS filters to match labels. Original IDR work is found in [I-D.ietf-idr-flowspec-v2] from [I-D.ietf-idr-flowspec-mpls-match]
FSv2 Work for SRv6:
Filters for SRv6 service identifers and functions. Original work was found in [I-D.ietf-idr-flowspec-v2] from [I-D.ietf-idr-flowspec-srv6].
FSV2 actions for SFC direction:
Network Service Header (NSH) is defined in [RFC8300]. Flow specification filters were not defined in [RFC9015], but filters could be defined for this header.
FSv2 L2 filters:
([I-D.ietf-idr-flowspec-l2vpn]) This document provides user ordered filters for L2VPNs. Other drafts have suggested extending this to cover the reduced latency L2 use case (detnet).
Tunnels Defined by nv03 group
FSv2 Non-IP Actions (draft-hares-idr-fsv2-non-IP-Filters):

This draft defines FSv2 non-IP actions in data packets passed by L2, MPLS packets, Segment Routing packets (SR-MPLS or SRv6), SFC and tunnels. The potential work in this area includes:

FSV2 actions on MPLS filters:
MPLS actions to push, pop, swap labels. Original IDR work is found in [I-D.ietf-idr-flowspec-v2] from [I-D.ietf-idr-bgp-flowspec-label]
FSv2 Work for SRv6:
While the original work does not have FSv2 actions, some individual drafts have suggested actions for SRv6 headers. One such action could be compression of SRv6.
FSV2 actions for SFC direction:
SFC classifier actions based on Action with Service Path identifier (SPI), Service Index (SI), and Service function type (SFT). The original description of the action is in [RFC9015] in section 7.4.
([I-D.ietf-idr-flowspec-l2vpn]) The L2 filters for packets in L2 or L2VPN.
Tunnels Defined by nv03 group

2. Extended IP Filters SubTLV

The format of the FSv2 NLRI field for IP Filters is defined in the original FSv2 draft [I-D.ietf-idr-flowspec-v2] and in the first of the FSv2 series drafts [I-D.hares-idr-fsv2-ip-basic]. As a review, the FSv2 NLRI with

The format of the NLRI for Basic IP Filters (type 1) is also defined in [I-D.hares-idr-fsv2-ip-basic]. This document defines the format of NLRI for the FSv2 Extended IP Filter type (type 2). Figure 3-1 provides the general header and Figure 3-2 provides the definition of the "value" portion. Figure 3-3 provides a diagram of the component types.

The key differences is that the extended IP filter types starts with a IP Filters identifier before SubTLVs with the filter components.

 | NLRI length (2 octets)        |
 | TLVs+                         |
 | +===========================+ |
 | | order (4 octets)          | |
 | +---------------------------+ |
 | | identifier (4 octets)     | |
 | +---------------------------+ |
 | + FSv2 Filter type 2        + |
 | +---------------------------+ |
 | + length TLVs (2 octet)     + |
 | + --------------------------+ |
 | + value (variable)          + |
 | +---------------------------+ |

  Figure 3-1 - FSv2 NLRI with Extended IP Filter type.

Where: the IP Filter type has a value field has a series of SubTLV as shown in figure 3-2.

    |  FSv2 filters version         |
    |  +-------------------------+  |
    |  |  SUB-TLVs               |  |
    |  +-------------------------+  |

 Figure 3-2 - FSv2 for Extended IP filters

Where: Fv2 Filter version is 2-octet field specifying the version of the FSV2 IP filters. The Filter version is an IANA registered value.

And SubTLV has the format of

    |  Component Type (1 octet)     |
    |  length (1 octet)             |
    + ------------------------------+
    |  value (variable)             |
     Figure 3-3 – IP header SubTLV format


  • Component type: component values are defined in the “Flow Specification Component types” registry for IPv4 and IPv6 by [RFC8955], [RFC8956], and [I-D.ietf-idr-flowspec-srv6]

  • length: length of SubTLV (varies depending on the component type)>

  • value: dependent on component type. The component types supported are based on the FSv2 filter version.

    • The component types supported are based on the version of FSv2 version. For FSv2 Extended Filter version 1, all the basic FSv1 components are supported plus three additional new filters (TTL, SID, NRP-ID)

    • For descriptions of value portions for components 1-13 see [RFC8955] and [RFC8956]. New Filter types for Potential new filter components are listed in Table 3-3.

Table 3-2 Extended Filter types (Filter v0)
-type     Definition
======    ==========================
   1 -    IP Destination prefix
   2 -    IP Source prefix
   3 –    IPv4 Protocol /
          IPv6 Upper Layer Protocol
   4 –    Port
   5 –    Destination Port
   6 –    Source Port
   7 –    ICMPv4 type / ICMPv6 type
   8 –    ICMPv4 code / ICPv6 code
   9 –    TCP Flags
  10 –    Packet length
  11 –    DSCP
  12 –    Fragment
  13 –    Flow Label
Table 3-2 Extended Filter types (filter v1)
-type     Definition
======    ==========================
   1 -    IP Destination prefix
   2 -    IP Source prefix
   3 –    IPv4 Protocol /
          IPv6 Upper Layer Protocol
   4 –    Port
   5 –    Destination Port
   6 –    Source Port
   7 –    ICMPv4 type / ICMPv6 type
   8 –    ICMPv4 code / ICPv6 code
   9 –    TCP Flags
  10 –    Packet length
  11 –    DSCP
  12 –    Fragment
  13 –    Flow Label
   0 -    TTL [option 2] IPv4/IPv6
  14 -    TTL [option 1] IPv4/IPv6
  15      SID in Routing IPv6 Header
  16      NRP-ID in Hop-by-Hop IPv6 Header
Table 3-3 New Filter types (proposed)
-type     Definition
======    ==========================
  17      APN-ID
  18      CAT-ID in
  19      Group ID

  64-127  Reserved for Non-IP Filters
 128-191  Reserved for Standard Action
 192-249  FCFS
 250-255  Reserved

Ordering within the TLV in FSv2: The transmission of SubTLVs within a flow specification rule MUST be sent ascending order by SubTLV type. If the SubTLV types are the same, then the value fields are compared using mechanisms defined in [RFC8955] and [RFC8956] and MUST be in ascending order. NLRIs having TLVs which do not follow the above ordering rules MUST be considered as malformed by a BGP FSv2 propagator. This rule prevents any ambiguities that arise from the multiple copies of the same NLRI from multiple BGP FSv2 propagators. A BGP implementation SHOULD treat such malformed NLRIs as "Treat-as-withdraw" [RFC7606].

See [RFC8955], [RFC8956], and [I-D.ietf-idr-flowspec-srv6]. for specific details.

3. New Filter Components (IDR approved)

3.1. TTL (type=TTL-Type (TBD) )

TTL: Defines matches for 8-bit TTL field in IP header

Encoding: <[numeric_op, value]+>

where: value is a 1 octet value for TTL.

ordering: by full value of number_op concatenated with value

conflict: none

Note: Two options exist for type:

  • TTL is tested before any IP packet filter (TTL-type = 0)

  • TTL is tested after FSv1 Filters (TTL-type = 14)

reference: draft-bergeon-flowspec-ttl-match-00.txt

3.2. Parts of SID (type = 16 (0x40))

IPv6 Service Identifier (SRv6 SID) Matches ([I-D.ietf-idr-flowspec-srv6] )

What Packet filtering: IPv6

What filtering in IPv6 Packet: Segment Routing Header (SRH) ([RFC8402])

SID in SRH: [RFC8402] defines SRv6 Segment Identifier (SID) as an IPv6 address explicitly associated with the segment. [RFC8986] defines the SID format as: "LOC:FUNCT:ARG" where:

  • locator (LOC) is encoded in the L most significant bits of the SID,

  • followed by F bits of function (FUNCT), and

  • A bits of arguments (ARG).

FSv2 Component: Parts of SID Filter: defines a list of match bit match criteria for some combinations of the LOC (location), FUNCT (function) and ARG (arguments) fields in the SID or or whole SID.

Length: variable

Component Value format: [type, LOC-Len, FUNCT-Len, ARG-Len, [op, value]+]


  • type (1 octet): This indicates the new component type (TBD1, which is to be assigned by IANA).

  • LOC-Len (1 octet): This indicates the length in bits of LOC in SID.

  • FUNCT-Len (1 octet): This indicates the length in bits of FUNCT in SID.

  • ARG-Len (1 octet): This indicates the length in bits of ARG in SID.

  • [op, value]+: This contains a list of {operator, value} pairs that are used to match some parts of SID.

The total of three lengths (i.e., LOC length + FUNCT length + ARG length) MUST NOT be greater than 128. If it is greater than 128, an error occurs and it is treated as a withdrawal [RFC7606] and [RFC4760].

The operator (op) byte is encoded as:

      0   1   2   3   4   5   6   7
    | e | a | field type|lt |gt |eq |
            Figure 3-5


  • where the behavior of each operator bit has clear similarity with that of [RFC8955]'s Numeric Operator field.

  • e (end-of-list bit): Set in the last {op, value} pair in the sequence.

  • a - AND bit: If unset, the previous term is logically ORed with the current one. If set, the operation is a logical AND. It should be unset in the first operator byte of a sequence. The AND operator has higher priority than OR for the purposes of evaluating logical expressions.

  • field type:

    • 000: SID's LOC

    • 001: SID's FUNCT

    • 010: SID's ARG

    • 011: SID's LOC:FUNCT (the concatenation of the LOC and FUNCTION fields)

    • 100: SID's FUNCT:ARG (the concatenation of the FUNCTION and ARG fields)

    • 101: SID's LOC:FUNCT:ARG (the concatenation of the FUNCTION and ARG fields)

  • Note: For an unknown field type, Error Handling is to "treat as withdrawal" [RFC7606] and [RFC4760].

  • lt: less than comparison between data' and value'.

  • gt: greater than comparison between data' and value'.

  • eq: equality between data' and value'.

The data' and value' used in lt, gt and eq are indicated by the field type in an operator and the value field following the operator.

The length of the value field depends on the field type and is the length of the SID parts being matched (see Table 3, Figure 3-6) in bytes, rounded up if that length is not a multiple of 8.

         Table 3 - SID Parts fields

       | Field Type            | Value                        |
       | SID's LOC             | value of LOC bits            |
       | SID's FUNCT           | value of FUNCT bits          |
       | SID's ARG             | value of ARG bits            |
       | SID's LOC:FUNCT       | value of LOC:FUNCT bits      |
       | SID's FUNCT:ARG       | value of FUNCT:ARG bits      |
       | SID's LOC:FUNCT:ARG   | value of LOC:FUNCT:ARG bits  |

        ------------------ SID,  128 bits ----------------
       /                                                  \
      |    LOC    |   FUNCT   |    ARG    |      ...       |
       \         / \         / \         / \              /
          j bits     k bits       m bits    128-j-k-m bits
       \                     /
         LOC:FUNCT, j+k bits
                   \                     /
                     FUNCT:ARG, k+m bits
       \                                 /
         -- LOC:FUNCT:ARG, j+k+m bits –

                              Figure 3-6

Interactions with: TBD

reference: [I-D.ietf-idr-flowspec-srv6]

3.3. NRP ID Filter(type=17) (0x11)

Network Resource Partition ID Component

IP Packet filtering: IPv6

What filtering: IPv6 Hop-by-Hop Options Header ([RFC8402])

Description: Option in Next-Hop-Options header in IPv6 packet ([RFC8402], section 4). A Network Resource Partition (NRP) option carries around the network resource partition information (NRP) in the Hop-by-Hop options header ([I-D.ietf-6man-enhanced-vpn-vtn-id]). This IPv6 Extension head has:

  • Flags (flags): This is a 8 bit flag field in a single octet. One bit, "S" defined in most significant bit. The S stands for strict match of NRP ID field. The NRP Flags field is filtered for by the FSv2 component Flags field.

  • Context type (CT): - 1 octet field indicating the semantics and length of NRP-ID field. The value of CT=0 indicates a 4-octet NRP ID.

  • followed by F bits of function (FUNCT), and

  • A bits of arguments (ARG).

FSv2 NRP ID Component: Defines match for NRP ID in the NRP option of Hop-by-Hop Header. This FSv2 component has following format:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       |  Option Type  |  Opt Data Len |
       |     Flags     | Context Type  |            Reserved           |
       ~                            NRP ID                             ~

                 Figure: NRP FSv2 Component
  • Flags - This field is 2 octets with only the most signficant bit defined as Global Bit (g).

    • Global bit (g): When set, it indicates the NRP ID to be matched with a globally unique NRP ID. Otherwise, the NRP-ID is to be a domain significant NRP ID. The global NRP ID has been coordinated among these domains.

  • Reserved: This a 2-octet field reserved for future use. It SHOULD be set to zero on transmission and MUST be ignored on receipt.

  • NRP ID: This is a 4-octet identifier which is used to identify an NRP

Interactions with: (TBD)

reference: [I-D.ietf-idr-flowspec-network-slice-ts]

4. Proposed Filter components

4.1. IP Payloads Match type=18) (0x12)

IP Payload filter

IP Packet filtering: IPv4 or IPv6

What filtering: data within the payload. Of set is given to

Description: The filter has an offset to filter data from the point specified in the "offset-type field" for using a filter of specific length (content-length) with a specific pattern (content). The type of packet IPv4 or IPv6 is specified in Type of IP packet.

The structure of the cponent is as

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       |  Option Type  |  Opt Data Len |
       | PType | Otype |   offset  (offset-value)     | content length|
       |                        content                                |

                 Figure 3-x: FSv2 IP Payload Match Component

Where the

  • Ptype - 4 bit field indicating the packet type via AFI (IPv4 or IPv6)

    • IPv4 = 1

    • IPv6 = 2

  • Otype - 4 bit field indicating the offset type where

    • 0 = IP header

    • 1 = IP header data

    • 2 = Data within TCP/UDP

  • offset - is number of bytes to the payload from the point defined by Ptype and Otype.

  • content length - length of the content.

  • content - content filter field to match (significant field bit zero).

interacts with: (TBD)

reference: [I-D.cui-idr-content-filter-flowspec]

4.2. Group ID

Filter on Group ID

IP Packet filtering: IPv4 or IPv6

What filtering: Group ID specified sub-type

Description: The filter looks for a specific type of group ID within either the IPv4 or IPv6 packet header.

The structure of the component is the following

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       |  Option Type  |  Opt Data Len |
       | Packet Type   | Offset type   | Group type    | SubGroup type |
           | Offset value                  |  GMask length | SG Mask length|
       |                        Group Mask                             |
       |                        Group ID value                         |
           |                        Sub-Group Mask                         |
       |                        Sub-Group Value                        |
                 Figure 3-x: FSv2 IP Payload Match Component

Where the

  • Packet type - 8 bit field indicating the packet type

    • IPv4 = 1

    • IPv6 = 2

  • Offset type - 4 bit field indicating the offset type where

    • 0 = IP header

    • 1 = IP header data

    • 2 = Data within TCP/UDP

  • offset - is number of bytes to the payload from the point defined by Ptype and Otype.

  • Group type - 1 octet field indicating the type of group ID

    • 0 = Reserved

    • 1 = Interface group

    • 1 = CATS ID

    • 2 = SAV ID

    • 3 = APN ID

  • Sub-Group type - Sub group within filters.

    • 0 = Reserved

    • 1 = data traffic (Inbound/outbound)

    • 1 = data traffic Inbound only

    • 2 = data traffic outbound only

  • Group Mask - (variable) Group field mask

  • Group ID value - (variable) Group ID value to match

  • Sub Group Mask - (variable) Sub-Group Mask

  • Sub-Group Value - (variable) Sub-Group value to match on

interacts with: (TBD)

reference: This document

5. IANA Considerations

This section complies with [RFC7153].

5.1. Filter IP Component types

IANA is requested to indicate [this draft] as a reference on the following assignments in the Flow Specification Component Types Registry:

 ID    Name         Reference
 ----  -----------  -----------------------------------------
 14    TTL          [this document]
 15    Partial SID  [draft-ietf-idr-flowspec-srv6]
                    [this document]
 16    NRP ID       [this document]
 17    payload      [this document]
 18    Group ID     [this document]

5.2. FSV2 Filter versions

IANA is requested to create the following three new egistries on a new "Flow Specification v2 Parameters” web page.

   Name: BGP FSv2 Filter Version types
   Reference: [this document]
   Registration Procedures: 0x01-0x3F Standards Action.
                                                        0x40-0x6F FCFS
                                                        0x70-0xFF reserved

    Type    Use                     Reference
   -----    ---------------         ---------------
    0x00    IP basic only           [this document]
                                    [FSv2 IP basic]
    0x01    Extended IP Filters 1   [This document]

                           Figure 4-1
   Name: BGP Group Types
   Reference: [this document]
   Registration Procedures: 0x01-0x3F Standards Action.
                            0x40-0x6F FCFS
                                                        0x70-0xFF reserved

    Type    Use                     Reference
   -----    ---------------         ---------------
    0x00    reserved                [this document]
    0x01    Interface Group         [this document]
    0x02    CATs group              [this document]
    0x03    SAVNet group            [this document]
    0x04    APN group               [this document]

               Figure 4-2 Groups
   Name: BGP Sub Group Types
   Reference: [this document]
   Registration Procedures: 0x01-0x3F Standards Action.
                            0x40-0x5F FCFS
                                                        0x5F-0xFF reserved

    Type    Use                     Reference
   -----    ---------------         ---------------
    0x00    Inbound/outbound        [this document]
    0x01    Inbound on              [this document]
    0x02    Outbound only           [this document]
    0x03    SubGroup ID based       [this document]

                      figure 4-3 Sub-Group types

6. Security Considerations

The use of ROA improves on [RFC8955] by checking to see of the route origination. This check can improve the validation sequence for a multiple-AS environment.

>The use of BGPSEC [RFC8205] to secure the packet can increase security of BGP flow specification information sent in the packet.

The use of the reduced validation within an AS [RFC9117] can provide adequate validation for distribution of flow specification within a single autonomous system for prevention of DDoS.

Distribution of flow filters may provide insight into traffic being sent within an AS, but this information should be composite information that does not reveal the traffic patterns of individuals.

7. References

7.1. Normative References

Hares, S., Eastlake, D. E., Yadlapalli, C., and S. Maduschke, "BGP Flow Specification Version 2 - for Basic IP", Work in Progress, Internet-Draft, draft-hares-idr-fsv2-ip-basic-01, , <>.
Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra, "Carrying Network Resource Partition (NRP) Information in IPv6 Extension Header", Work in Progress, Internet-Draft, draft-ietf-6man-enhanced-vpn-vtn-id-06, , <>.
liangqiandeng, Hares, S., You, J., Raszuk, R., and D. Ma, "Carrying Label Information for BGP FlowSpec", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-flowspec-label-02, , <>.
Litkowski, S., Simpson, A., Patel, K., Haas, J., and L. Yong, "Applying BGP flowspec rules on a specific interface set", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-interfaceset-05, , <>.
Weiguo, H., Eastlake, D. E., Litkowski, S., and S. Zhuang, "BGP Dissemination of L2 Flow Specification Rules", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-l2vpn-23, , <>.
Yong, L., Hares, S., liangqiandeng, and J. You, "BGP Flow Specification Filter for MPLS Label", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-mpls-match-02, , <>.
Dong, J., Chen, R., Wang, S., and J. Wenying, "BGP Flowspec for IETF Network Slice Traffic Steering", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-network-slice-ts-02, , <>.
Eastlake, D. E., Weiguo, H., Zhuang, S., Li, Z., and R. Gu, "BGP Dissemination of Flow Specification Rules for Tunneled Traffic", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-nvo3-19, , <>.
Van de Velde, G., Patel, K., and Z. Li, "Flowspec Indirection-id Redirect", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-path-redirect-12, , <>.
Li, Z., Li, L., Chen, H., Loibl, C., Mishra, G. S., Fan, Y., Zhu, Y., Liu, L., and X. Liu, "BGP Flow Specification for SRv6", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-srv6-05, , <>.
Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., and P. Jakma, "BGP Community Container Attribute", Work in Progress, Internet-Draft, draft-ietf-idr-wide-bgp-communities-11, , <>.
Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, , <>.
Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, , <>.
Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, , <>.
Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, , <>.
Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, , <>.
Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, DOI 10.17487/RFC5701, , <>.
Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, , <>.
Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, , <>.
Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, , <>.
Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, , <>.
Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Jalil, "BGP Control Plane for the Network Service Header in Service Function Chaining", RFC 9015, DOI 10.17487/RFC9015, , <>.
Uttaro, J., Alcaide, J., Filsfils, C., Smith, D., and P. Mohapatra, "Revised Validation Procedure for BGP Flow Specifications", RFC 9117, DOI 10.17487/RFC9117, , <>.
Loibl, C., "BGP Extended Community Registries Update", RFC 9184, DOI 10.17487/RFC9184, , <>.

7.2. Informative References

Cui, Y. and Y. Gao, "Packet Content Filter for BGP FlowSpec", Work in Progress, Internet-Draft, draft-cui-idr-content-filter-flowspec-00, , <>.
Hares, S., Eastlake, D. E., Yadlapalli, C., and S. Maduschke, "BGP Flow Specification Version 2", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-v2-04, , <>.
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <>.
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <>.
Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, , <>.
George, W. and S. Murphy, "BGPsec Considerations for Autonomous System (AS) Migration", RFC 8206, DOI 10.17487/RFC8206, , <>.
Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, , <>.
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <>.
Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, , <>.

Author's Address

Susan Hares
Hickory Hill Consulting
7453 Hickory Hill
Saline, MI 48176
United States of America