| Internet-Draft | BGP FSv2 Basic IP | May 2026 |
| Hares, et al. | Expires 10 November 2026 | [Page] |
BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117, describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. During the deployment of BGP FSv1 a number of issues were detected, so version 2 of the BGP flow specification (FSv2) protocol addresses these issues. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2.¶
The IDR WG requires two implementation. Early feedback on implementations of FSv2 indicate that FSv2 has a correct design direction, but that breaking FSv2 into a progression of documents would aid deployment of the draft (basic, adding more filters, and adding more actions). This document specifies the basic FSv2 NLRI with user ordering of filters added to FSv1 IP Filters and FSv2 actions.¶
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 https://datatracker.ietf.org/drafts/current/.¶
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 10 November 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Version 2 of BGP flow specification was original defined in [fsv2] (BGP FSv2).¶
FSv2 is an update to BGP Flow specification version 1 (BGP FSv1). BGP 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).¶
The initial BGP FSv2 specification had the correct direction, but it contained more than the early implementers desired. The implmenters desired a progression of documents with smaller incremental changes: Basic FSv2, adding more filters, and adding more actions.¶
This draft provides the basic FSv2 framework specification for transmitting user-ordered IP filters in the FSV2 NLRI and associating Flow Spec actions by transmitting Flow Spec Extended Communities (FS-EC) with the FSv2 NLRI. If a filter match links to a single FS-EC action, the single action succeeds or fails. If a filter match links to mutiple actions, there is a potential for interactions. Section 4.5.1 discusses how to analyze the interaction by categories and solutions to issues with multiple FSv2-EC actions interacting. A complete solution requires the BGP Community Container Attribute see [I-D.ietf-idr-wide-bgp-communities]) with FSv2 Container defined in the [fsv2-more-ip-filters].¶
This document defines 2 new SAFIs, TBD1 and TBD2, for FSv2 to be used with 5 AFIs: 1, 2, 6, 25, and 31. FSv2 implementations do not require all 10 combinations of FSv2 AFI/SAFIs to be implemented. An implementation is required to implement only one these AFI/SAFIs to be compliant. For example, a compliant implementation might only define the FSv2 NLRI for IPv4 for IP forwarding (AFI=1, SAFI=TBD1).¶
FSv1 and FSv2 use different AFI/SAFIs to send their respective flow specification filters. This permits FSv1 and FSv2 to be coexist with each other in a "ships in the night" deployment.¶
The remainder of Section 1 provides background on why the FSv2 was necessary to fix problems with FSv1. Section 2 contains a primer on FSv2. Section 3 contains the BGP encoding rules for FSv2. Section 5 describes how to validate and order FSv2 NLRI. The remaining sections discuss scalability, optional security additions, security considerations, and IANA considerations.¶
Modern IP routers have the capability to forward traffic and to classify, shape, rate limit, filter, or redirect packets based on administratively defined policies. These traffic policy mechanisms allow the operator to define match rules that operate on multiple fields within header of an IP data packet. The traffic policy allows actions to be taken upon a match to be associated with each match rule. These rules can be more widely defined as "event-condition-action" (ECA) rules where the event is always the reception of a packet.¶
BGP ([RFC4271]) flow specification version 1 (FSv1) as defined by [RFC8955], [RFC8956], and [RFC9117] specifies the distribution of traffic filter policy (traffic filters and actions) via BGP to BGP peers, both IBGP and EBGP. The traffic filter is applied when packets are received on a router with the flow specification function enabled.¶
Multiple deployed applications currently use BGP FSv1 to distribute traffic filters. These applications include:¶
During the deployment of FSv1, the following issues were noted:¶
Networks currently address these issues by constraining deployments or using topology/deployment specific workarounds.¶
FSv1 is a critical component of deployed applications. Therefore, this specification defines how FSv2 will interact with BGP peers that support combinations FSv1 and FSv2. It is expected that a transition to FSv2 will occur over time as new applications require features enabled by FSv2.¶
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.¶
A BGP Flow Specification (v1 or v2) is an n-tuple containing one or more match criteria that can be applied to data-plane traffic. The exact traffic match depends on the FSv2 AFI/SAFI.¶
Flows Specification routes carried in BGP UPDATEs may carry BGP Path Attributes that have additional match or action consequences. This includes, but is not limited to: Extended Communities [RFC4360] and Community Container Path attributes [I-D.ietf-idr-wide-bgp-communities].¶
Flow Specifiation NLRI for a given AFI/SAFI is used as they key for Flow Specification routes in the BGP RIBs. Flow Specification routes that are selected for the Loc-RIB are then associated with a given set of semantics which are application dependent. Standard BGP policy mechanisms for BGP routes are applicable to Flow Specification routes, including AS_PATH and community filtering.¶
This FSv2 for basic IP forwarding specification only requires the use of Extended Communities to associate FS actions with FSv2 filters found in FSv2 NLRI.¶
FSv2 features implementing multiple actions with user ordering of actions or dependencies between actions requires the BGP Community Attribute [I-D.ietf-idr-wide-bgp-communities] with a FSv2 Component as defined in [fsv2-more-ip-filters].¶
Network operators can control the propagation of Flow Specification BGP routes by enabling or disabling the exchange of routes for a particular AFI/SAFI pair on a particular peering session. BGP policy mechanisms, including [RFC1997] scoping communities, can also be used. Thus, Flow Specification routes may be distributed to only a portion of a BGP deployment.¶
The FSv1 NLRI defined in [RFC8955] and [RFC8956] includes 13 match conditions encoded for the following AFI/SAFIs:¶
IPv4 traffic: AFI:1, SAFI:133¶
IPv6 Traffic: AFI:2, SAFI:133¶
BGP/MPLS IPv4 VPN: AFI:1, SAFI: 134¶
BGP/MPLS IPv6 VPN: AFI:2, SAFI: 134¶
FSv1 match conditions are ordered by component type in ascending order. The ordering within a component type is defined by that component's definition.¶
The Flow Specification actions standardized by [RFC8955] and [RFC8956] are:¶
A SFC action [RFC9015] defines a redirection of a data flow to an entry point into a specific SFP (Service Function Path).¶
Other Extended Community actions have been proposed in IDR, but have not completed the standardization process.¶
This specification defines AFI/SAFIs to support Flow Specification version 2 for IPv4, IPv6, Layer 2, IPv4 VPNs, IPv6 VPNs, Layer 2 VPNs (L2VPN), Service Function Chaining (SFC), and SFC VPNs:¶
One question asked by developers is what AFI/SAFI is required for FSv2 IP Basic compliance. BGP negotiates support for each AFI/SAFI, so FSv2 IP Basic support for non-VPN could be as little as FSv2 for IPv4 forwarding (AFI/SAFI: 1/TBD1),¶
The IDR specification for L2 VPN traffic was specified in [I-D.ietf-idr-flowspec-l2vpn]. An IDR specification for tunneled traffic is in [I-D.ietf-idr-flowspec-nvo3]. Both of these drafts were targeted for FSv1, but the WG decided to require these to FSv2 TLV formats.¶
FSv2 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.¶
FSv2 operates in a ships-in-the night model with FSv1. This permits operators to manage the interaction of FSv2 and FSv1 via configuration.¶
The basic principles regarding the ordering and installation of flow specification filter rules are:¶
FSv2 filter rules can carry actions. These actions can be encoded via one or more FSv2 Extended Communities, or within the FSv2 Action Community Container.¶
Some FSv2 Extended Communities may not be understood by every FSv2 implementation. Since they are encoded as [RFC4360] Extended Communities, they are propagated with the BGP routes regardless of whether they are understood based on the particular Extended Community's transitivity.¶
When FSv2 Extended Communities are understood, they have precedence and interaction rules governing the actions they encode. (See XXX JMH TODO)¶
The FSv2 Action Community Container defines its own rules governing FSv2 actions. See that document (XXX JMH TODO) for additional details.¶
FSv2 filter match and action criteria may be considered "optional". For match, the FSv2 NLRI encoding carries a per-component flag set by the operator or implementation that marks that match component as optional or mandatory. For actions, FSv2 Extended Communities will document whether they are considered optional or mandatory as part of their definition. The optionality of FSv2 Action Community Containers is defined in its defining document.¶
If a mandatory match component or action component cannot be locally implemented, the flowspec rule is marked as ineligible to be installed.¶
BGP Flow Specifications are encoded in BGP NLRI as an ordered list of TLVs of "filter families", where each filter family consists of an ordered list of TLVs of "filter components" for that familiy. Filter families are groupings of related filtering functionality, typically at the same network layer. Filter components match specific network elements for a filter family.¶
Each FSv2 NLRI has a default sort order, documented in section TODO. This sort order determines the order of installation for the Flow Specification in the BGP speaker. Operators MAY override this default ordering by causing the FSv2 User Order field to be set to a non-zero value.¶
Sets of FSv2 NLRI might share fate with each other. In the event that a Flow Specification is unable to be installed by the BGP speaker, dependent Flow Specifications MUST NOT also be installed, even if they are otherwise valid. These dependencies are encoded in the Dependent Filters Chain field of a FSv2 Flow Specification.¶
FSv2 is carried in BGP using standard [RFC4760] multiprotocol extensions. FSv2 supports NRLI with formats for following AFIs:¶
These AFIs will be paired with the following SAFIs:¶
A compliant FSv2 implementation only has to implement one AFI/SAFI pair out of the full list of NRLIs. For example, a compliant FSv2 implementation might only implement IPv4 FSv2 (AFI=1, SAFI=TBD1).¶
FSv2 NLRI are encoded in BGP UPDATEs using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes defined in [RFC4760]. When advertising FSv2 NLRI, the length of the Next-Hop Network Address MUST be set to 0. Upon reception, the MP_REACH_NLRI "Network Address of NextHop" field MUST be ignored.¶
FSv2 Flow Specifications are encoded as an ordered list of TLVs of filter families. FSv2 filter famliies are typically associated with match criteria for a given networking layer; for example, 802.2 Layer 2, MPLS, IPv4/IPv6, Segment Routing, etc.¶
The AFI/SAFI NLRI for BGP Flow Specification version 2 (FSv2) has the format:¶
+-------------------------+ | NLRI Length | | (2 octets) | +-------------------------+ | Dependent Filters Chain | | (4 octets) | +-------------------------+ | User Order | | (4 octets) | +-------------------------+ | FSv2 Filter Family TLVs | | (variable) | +-------------------------+
Where:¶
Each each FSv2 Filter Family TLV has the format:¶
+-----------------------------+ | FSv2 Filter Family Type | | (2 octets) | +-----------------------------+ | FSv2 Filter Family Length | | (2 octets) | +-----------------------------+ | FSv2 Filter Components TLVs | | (variable) | +-----------------------------+
Where:¶
Each each FSv2 Filter Component TLV has the Format:¶
+------------------------------+ | FSv2 Filter Component Flags | | (4 bits) | +------------------------------+ | FSv2 Filter Component Type | | (16 bits) | +------------------------------+ | FSv2 Filter Component Length | | (2 octets) | +------------------------------+ | FSv2 Filter Component Value | | (variable) | +------------------------------+
Where:¶
The FSv2 Filter Component Flags are defined as:¶
0 1 2 3 +---+---+---+---+ | O | R | R | R | +---+---+---+---+
The fields of the FSv2 Filter Component Flags are defined as:¶
FSv2 Filter Component Type: A 12-bit unsigned integer in network byte order defining the match component for a given FSv2 filter type. For sorting purposes, lower value FSv2 Filter Component Types have a better precedence than higher values.¶
This document defines the following FSv2 Filter Component Types. The definition of the type-specific filter components may be defined in other documents:¶
FSv2 implementations MUST pass valid filter TLVs even if the implementation does not support these installation of these a particular type of filter rules.¶
This specification only defines operation of the IP Basic Filter Rules that all FSv2 must support.¶
Flow Specifications are implemented using ordered terms. The sorting rules for flow specification routes is intended to, by default, produce a reasonably ordered set of rules for common deployment scenarios.¶
When the FSv2 rule ordering wouldn't accomplish the operator's intent when deploying FSv2, the User Order field can permit the operator to influence the Flow Specification installation order in a deployment.¶
When set of Flow Specifications are required to implement an operator's intent and that set of rules has interdependencies, the failure to install a Flow Specification, or part of that specification's actions, may result in incorrect deployment. An example of such a dependency is two rules covering an IP destination, one with a more-specific and one with a less-specific prefix relaionship. As an example:¶
If an implementation couldn't support the DSCP action and failed to install the first rule, SMTP traffic to the host 10.1.1.1 would fail to be delivered due to the second rule's drop action. In other words, these two entries have a dependency.¶
When an implementation is unable to install a Flow Specification for some reason, that Flow Specification is locally "invalid". In many circumstances, Flow Specifications that do not have dependencies may be installed on a best-effort basis by an implementation. However, in the case of dependent rules, installing some rules selectively but not others can be problematic.¶
FSv2 defines for each FSv2 NLRI a Dependent Filters Chain (DFC). When the value of DFC is zero (0), no special consideration is given for dependencies. When the value of DFC is non-zero, when a rule is locally considered invalid, all rules sharing the same DFC value are also considered invalid, and not installed.¶
For NLRI canonicalization purposes, and also to ease processing, all TLVs within the FSv2 NLRI MUST be ordered in a strictly increasing fashion. FSv2 filter types and FSv2 filter-type-specific component types for a given component MUST NOT occur more than once.¶
See Section 5.1.4 for further details.¶
Partial deployments can occur for two reasons:¶
Only a portion of the nodes in a network with FSv2 support installing new FSv2 Filter types with new FSv2 components. Other nodes (such as RRs), check the syntax, but do not handle the semantic meaning.¶
During upgrades, a portion of the nodes know about a new Filter type with the components, but other nodes do not.¶
Editor: Are there others?¶
FSv2 IP Basic filters provide the same functionality as those specified in FSv1 RFCs [RFC8955] and [RFC8956]. The format of those components has been preserved for ease of implementation.¶
The FSv2 IP Basic filter has been assigned a FSv2 Filter Type value of TBD.¶
FSv2 IP Basic Filter component types are numbered differently from those in FSv1. FSv2 components have been numbered with gaps to permit future FSv2 IP Basic filter components to be added in between currently specified IP Basic components. This permits a natural default sort order for those new components in implementations.¶
Most of the components described below make use of comparison operators. These operators were originally defined in Section 4.2.1 of [RFC8955]. They are repeated here for document clarity.¶
The operators are encoded as a single octet.¶
This operator is encoded as shown in Figure 3-3.¶
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | e | a | len | 0 |lt |gt |eq | +---+---+---+---+---+---+---+---+
The bits lt, gt, and eq can be combined to produce common relational operators, such as "less or equal", "greater or equal", and "not equal to", as shown in Table 3-1.¶
+====+====+====+==================================+ | lt | gt | eq | Resulting operation | +====+====+====+==================================+ | 0 | 0 | 0 | false (independent of the value) | +----+----+----+----------------------------------+ | 0 | 0 | 1 | == (equal) | +----+----+----+----------------------------------+ | 0 | 1 | 0 | > (greater than) | +----+----+----+----------------------------------+ | 0 | 1 | 1 | <= (greater than or equal) | +----+----+----+----------------------------------+ | 1 | 0 | 0 | < (less than) | +----+----+----+----------------------------------+ | 1 | 0 | 1 | <= (less than or equal) | +----+----+----+----------------------------------+ | 1 | 1 | 0 | != (not equal value) | +----+----+----+----------------------------------+ | 1 | 1 | 1 | true (independent of the value) | +----+----+----+----------------------------------+
This operator is encoded as shown in Figure 3-4.¶
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | e | a | len | 0 | 0 |not| m | +---+---+---+---+---+---+---+---+
Where:¶
FSv2 IP Basic Filter Components are encoded in FSv2 Filter Component TLVs as described in Section 3.1.2.¶
The list of valid Basic IP types, covering the functionality defined in [RFC8955] and [RFC8956] are documented below. Additional IP filters are documented in defined in [I-D.hares-idr-fsv2-more-ip-filters].¶
| Type | Definition |
|---|---|
| 0 | Reserved |
| 10 | IP Destination Prefix |
| 20 | IP Source Prefix |
| 30 | IPv4 Protocol / IPv6 Upper Layer Protocol |
| 40 | Port |
| 50 | Destination Port |
| 60 | Source Port |
| 70 | ICMPv4 Type / ICMPv6 Type |
| 80 | ICMPv4 Code / ICPv6 Code |
| 90 | TCP Flags |
| 100 | Packet Length |
| 110 | DSCP |
| 120 | Fragment |
| 130 | Flow Label |
| 4095 | Reserved |
For Flow Specification ordering purposes, IP Basic Filter components are ordered similar the FSv1 comparison rules documented in Section 5.1 of [RFC8955].¶
The relative order of two Flow Specificationss with IP Basic filter family components is determined by comparing their respective family-specific components. The algorithm starts by comparing the lowest component type value of the Flow Specifications. If the types differ, the Flow Specification with lowest numeric type value has higher precedence (and thus will match before) than the Flow Specification that doesn't contain that component type. If the component types are the same, then a type-specific comparison is performed (see below). If the types are equal, the algorithm continues with the next component.¶
For IP prefix values (IP destination or source prefix), if one of the two prefixes to compare is a more specific prefix of the other, the more specific prefix has higher precedence. Otherwise, the one with the lowest IP value has higher precedence.¶
For all other component types, unless otherwise specified, the comparison is performed by comparing the component data as a binary string using the memcmp() function as defined by [ISO_IEC_9899]. For strings with equal lengths, the lowest string (memcmp) has higher precedence. For strings of different lengths, the common prefix is compared. If the common prefix is not equal, the string with the lowest prefix has higher precedence. If the common prefix is equal, the longest string is considered to have higher precedence than the shorter one.¶
Encoding: <prefix length (1 octet), prefix (variable)>¶
Defines the IPv4 destination prefix to match.¶
Encoding: <length (1 octet), offset (1 octet), pattern (variable), padding (variable)>¶
This defines the IPv6 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).¶
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.¶
Encoding: <prefix length (1 octet), prefix (variable)>¶
Defines the IPv4 source prefix to match.¶
Encoding: <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 4.4.1.2.¶
Encoding: <[numeric_op, value]+>¶
Contains a list of {numeric_op, value} pairs that are
used to match the IP protocol value octet in IPv4 packet header
Section 3.1 of [RFC0791].¶
This component uses the Numeric Operator (numeric_op) described in Section 4.1.1. Type 30 component values SHOULD be encoded as single octet (numeric_op len=00).¶
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 [RFC8200] Section 4).¶
This component uses the Numeric Operator (numeric_op) described in Section 4.1.1. Type 30 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 30 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: <[numeric_op, value]+>¶
Defines a list of {numeric_op, value} pairs that match
source OR destination TCP/UDP ports (see Section 3.1 of [RFC0793] and the "Format" section of [RFC0768]). This component matches if either the destination
port OR the source port of an IP packet matches the value.¶
This component uses the Numeric Operator (numeric_op) described in Section 4.1.1. Type 40 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01).¶
In case of the presence of the port (destination-port (Section 4.4.5), source-port (Section 4.4.6) component, only TCP or UDP packets can match the entire Flow Specification. The port component, if present, never matches when the packet's IP protocol value is not 6 (TCP) or 17 (UDP), 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 in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption.¶
Note: This component only matches the first upper layer protocol value in IPv6.¶
Encoding: <[numeric_op, value]+>¶
Defines a list of {numeric_op, value} pairs used to match
the destination port of a TCP or UDP packet (see also
Section 3.1 of [RFC0793] and the "Format" section of
[RFC0768].¶
This component uses the Numeric Operator (numeric_op) described in Section 4.1.1. Type 50 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01).¶
The last paragraph of Section 4.4.4 also applies to this component.¶
Encoding: <[numeric_op, value]+>¶
Defines a list of {numeric_op, value} pairs used to match
the source port of a TCP or UDP packet (see also
Section 3.1 of [RFC0793] and the "Format" section of
[RFC0768].¶
This component uses the Numeric Operator (numeric_op) described in Section 4.1.1. Type 60 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01).¶
The last paragraph of Section 4.4.4 also applies to this component.¶
Encoding: <[numeric_op, value]+>¶
Defines a list of {numeric_op, value} pairs used to match
the type field of an ICMP packet (see also the "Message Formats"
section of [RFC0792]).¶
This component uses the Numeric Operator (numeric_op) described in Section 4.1.1. Type 70 component values SHOULD be encoded as single octet (numeric_op len=00).¶
In case of the presence of the ICMP type component, only ICMP packets can match the entire Flow Specification. The ICMP type component, if present, never matches when the packet's IP protocol value is not 1 (ICMP), 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 in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption.¶
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: <[numeric_op, value]+>¶
Defines a list of {numeric_op, value} pairs used to
match the code field of an ICMP packet (see also the "Message
Formats" section of [RFC0792]).¶
This component uses the Numeric Operator (numeric_op) described in Section 4.1.1. Type 80 component values SHOULD be encoded as single octet (numeric_op len=00).¶
In case of the presence of the ICMP code component, only ICMP packets can match the entire Flow Specification. The ICMP code component, if present, never matches when the packet's IP protocol value is not 1 (ICMP), 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 in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption.¶
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 [RFC4443]).¶
This component uses the Numeric Operator (numeric_op) described in Section 4.1.1. Type 80 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: <[bitmask_op, bitmask]+>¶
Defines a list of {bitmask_op, bitmask} pairs used to
match TCP control bits (see also
Section 3.1 of [RFC0793]).¶
This component uses the Bitmask Operator (bitmask_op) described in Section 4.1.2. Type 90 component bitmasks MUST be encoded as 1- or 2-octet bitmask (bitmask_op len=00 or len=01).¶
When a single octet (bitmask_op len=00) is specified, it matches octet 14 of the TCP header (see also Section 3.1 of [RFC0793]), which contains the TCP control bits. When a 2-octet (bitmask_op len=01) encoding is used, it matches octets 13 and 14 of the TCP header with the data offset (leftmost 4 bits) always treated as 0.¶
In case of the presence of the TCP flags component, only TCP packets can match the entire Flow Specification. The TCP flags component, if present, never matches when the packet's IP protocol value is not 6 (TCP), 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 in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption.¶
Encoding: <[numeric_op, value]+>¶
Defines a list of {numeric_op, value} pairs used to match
on the total IP packet length (excluding Layer 2 but including IP
header).¶
This component uses the Numeric Operator (numeric_op) described in Section 4.1.1. Type 100 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01).¶
Encoding: <[numeric_op, value]+>¶
Defines a list of {numeric_op, value} pairs used to match
the 6-bit DSCP field (see also [RFC2474]).¶
This component uses the Numeric Operator (numeric_op) described in Section 4.1.1. Type 110 component values MUST be encoded as single octet (numeric_op len=00).¶
The six least significant bits contain the DSCP value. All other bits SHOULD be treated as 0.¶
Encoding: <[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 Section 4.1.2. Type 120 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|DF |
+---+---+---+---+---+---+---+---+
Bitmask values:¶
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 |LF |FF |IsF| 0 | +---+---+---+---+---+---+---+---+
Bitmask values:¶
Encoding: <[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 [RFC8200]).¶
This component uses the Numeric Operator (numeric_op) described in Section 4.1.1. Type 130 component values SHOULD be encoded as 4-octet quantities (numeric_op len=10).¶
Traffic matching a flow specification filter may have selected traffic actions applied to it that have various impacts on the matched traffic. FSv2 IP Basic allows flow specification actions to be attached to flow specification routes using BGP Extended Communities (FSv2-EC) encoded using the Extended Community formats [RFC4360] or in the IPv6 Address Specific Extended Community format [RFC5701].¶
Section 4.5.1 describes the interaction between FS-EC action, and categories of actions. Section 4.5.2 describes the existing FS-EC action formats. Section 4.5.5 defines an optional FS-EC to pass information ordering of categories (user/this standard) and failure action (stop or best effort).¶
FSv2-EC actions fall into the following categories:¶
When multiple actions from a given FSv2-EC category are present in a FSv2 route, these actions may conflict. Conflicting actions result in ambiguity as to what traffic action behavior is applied to traffic matching the flow specification.¶
FSv2 actions passed in a BGP Community Container Attribute can provide ordering of actions, dependencies, or signal which actions are valid within a category (see [fsv2-more-ip-filters]). However, these features are beyond the Basic FSv2 for IP forwarding and are out of scope for this specification.¶
FSv2 IP Basic uses FSv1 actions and these are referenced in Section 4.5.2.1 and Section 4.5.2.2.¶
One additional, optional, FSv2 specific FS-EC: the Action Chain Ordering (ACO) Extended Community (ACO-EC), is defined in Section 4.5.5. ACO-EC can carry defaults currently only available by configuration in FSv1.¶
FSv1 defines a set of [RFC4360] encoded extended communities implementing actions also applicable to FSv2 IP Basic match types. They are:¶
| Type/Sub-Type | Description | Short-ID | Reference |
|---|---|---|---|
| 0x01/0x0c | Redirect to IP | RD-IP | [redirect-ip] |
| 0x07/0x02 | Match Interface set | TA-IS | [interface-set] |
| 0x09/0xxx | Redirect to Indirection ID | RD-IID | [path-redirect] |
| 0x0b/0x00 | SFC Reserved | SFC-R | [RFC9015] |
| 0x0b/0x01 | SFVC SFIR POOL Identifier | SFIR-PI | [RFC9015] |
| 0x0b/0x02 | SFC MPLS label stack Swapping or stacking labels | SFC-MPLS | [RFC9015] |
| 0x80/0x06 | Traffic rate limit by bytes | TR-BPS | [RFC8955] |
| 0x80/0x07 | Traffic Action (sample, terminal) | TA | [RFC8955] |
| 0x80/0x08 | Redirection to VRF (2-octet AS form) | RD-VRF-AS2 | [RFC8955] |
| 0x80/0x09 | Traffic mark DSCP | TM-DSCP | [RFC8955] |
| 0x80/0x0C | Traffic rate limit by packets | TR-BPS | [RFC8955] |
| 0x81/0x08 | Redirect to VPN (IPv4 form) | RD-VRF-IPv4 | [RFC8955] |
| 0x81/0x08 | Redirect to VPN (4-octet AS form) | RD-VRF-AS4 | [RFC8955] |
Note the Short ID is simply a quick way for this document to reference a particular action.¶
FSv1 defines a set of [RFC5701] encoded extended communities implementing actions also applicable to FSv2 IP Basic match types. They are:¶
| Type | Description | Short-ID | Reference |
|---|---|---|---|
| 0x000C | FS Redirect to IPv6 | RD-IP6 | [redirect-ip] |
| 0x000D | FS Redirect to VPN by IPv6 route target | RD-VRF-IPv6 | [RFC8956] |
Devices implementing flow specification matching and traffic actions may be unable, for whatever reason, to carry out the signaled actions for the matched traffic. Some examples of this inability include:¶
When FS-EC actions known to the implementation are attached to a flow specification route and an action cannot be executed, there are three potential options:¶
Option 1 and 2 can be signaled by configuration within a Flow Specification implementation.¶
Option 3 requires the encoding dependency lists in ordered filters and ordered actions. The FSv2 NLRI format has a field to carry filter dependency information, but these functions are beyond the FSv2 Basic IP functions and out of scope for this specification.¶
Consider an example where three FSv2-EC actions are present on the route: Set the DSCP value, request sampling of the traffic, redirect to a VRF. If the implementation is unable to set the DSCP value:¶
Currently, for FSv1, local configuration or implementation behavior determines what happens if one of the actions fails within a set of multiple actions attached to a filter rule.¶
One option for FSv2 is to pass another FS-EC indicating what the originator expects will happen upon failure of an action.¶
A flow specification implementation that understands extended communities for a traffic action may not necessarily be able to implement them. Another problematic case for consistent deployment of flow specification within a network is understanding that an implementation may be ignorant of some FSv2-ECs.¶
FSv2-ECs are carried in the general purpose BGP Extended Community features. The expected behavior for an implementation receiving unknown Extended Communities, depending on configuration and policy, will be to ignore the contents of these communities and propagate them according to the transitivity rules in [RFC4360].¶
Newly defined FSv2-ECs may be unknown to the implementation, typically as a result of incremental deployment newer flow specification traffic actions. When a network with older implementations receive such newly defined FSv2-ECs, the older implementations are unable to determine that an action has been requested at all. The default behavior thus becomes "best effort" for executing the known FSv2-ECs.¶
When specifying new FSv2-ECs, operational consideration MUST be given to what the behavior of such ignorant implementations may do to the desired traffic forwarding throughout the FS deployment.¶
The BGP peer originating multiple FSv2 FS-EC actions attached to FSv2 NLRI (filters) may attach the Action Chain Ordering (ACO) FS-EC to inform BGP Peers receiving the FSv2 information how the originating pair expects action interactions and actions failures will be handled. Two fields are encoded in this FS-EC:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type high | Type low |AC-interaction | AC-Failure | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
This field indicates whether the FS-EC category order is the pre-defined order or an implementation specific order.¶
1 octet byte that determines the action on failure. Actions may succeed or fail and an Action chain must deal with it. The default value stored for an action chain that does not have this action chain is "stop on failure". AC-Failure types are:¶
The validation of FSv2 NLRI adheres to the combination of rules for general BGP FSv1 NLRI found in [RFC8955], [RFC8956], [RFC9117]. These FSv1 rules are sufficient for FSv2 for IP traffic.¶
Specific additions have been defined for IP Filters used for guiding IP traffic into Service Function Service Function Pathways SFC NLRI in [RFC9015], or validation of L2VPN FS NLRI (see [I-D.ietf-idr-flowspec-l2vpn]). These additions are not required for the FSv2 for IP Basic functions. Therefore, FSv2 NLRI validation for Basic IP uses the same rules as FSv1.¶
To provide clarity, the full validation process for flow specification routes (FSv1 or FSv2) for all AFI/SAFIs is described below in section x.x rather than simply referring to the relevant portions of these RFCs. Validation only occurs after BGP UPDATE message reception and the FSv2 NLRI and the path attributes relating to FSv2 (Extended community and Wide Community) have been determined to be well-formed. Any MALFORMED FSv2 NRLI is handled as a "session reset" [RFC7606].¶
Flow specifications received from a BGP peer that are accepted in the respective Adj-RIB-In are used as input to the route selection process. Although the forwarding attributes of the two routes for tbe same prefix may be the same, BGP is still required to perform its path selection algorithm in order to select the correct set of attributes to advertise.¶
The first step of the BGP Route selection procedure (section 9.1.2 of [RFC4271] is to exclude from the selection procedure routes that are considered unfeasible. In the context of IP routing information, this is used to validate that the NEXT_HOP Attribute of a given route is resolvable.¶
The concept can be extended in the case of the Flow Specification NLRI to allow other validation procedures.¶
The FSv2 validation process validates the FSv2 NLRI with following unicast routes received over the same AFI (1 or 2) but different SAFIs:¶
In the absence of explicit configuration, a Flow specification NLRI (FSv1 or FSv2) MUST be validated such that it is considered feasible if and only if all of the conditions are true:¶
a) A destination prefix component is embedded in the Flow Specification,¶
b) One of the following conditions holds true:¶
1. The originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification (this is the unicast route with the longest possible prefix length covering the destination prefix embedded in the flow specification).¶
2. The AS_PATH attribute of the flow specification is empty or contains only an AS_CONFED_SEQUENCE segment [RFC5065].¶
c) There are no "more-specific" unicast routes when compared with the flow destination prefix that have been received from a different neighbor AS than the best-match unicast route, which has been determined in rule b.¶
However, part of rule a may be relaxed by explicit configuration, permitting Flow Specifications that include no destination prefix component. If such is the case, rules b and c are moot and MUST be disregarded.¶
By "originator" of a BGP route, we mean either the address of the originator in the ORIGINATOR_ID Attribute [RFC4456] or the source address of the BGP peer, if this path attribute is not present.¶
A BGP implementation MUST enforce that the AS in the left-most position of the AS_PATH attribute of a Flow Specification Route (FSv1 or FSv2) received via the Exterior Border Gateway Protocol (eBGP) matches the AS in the left-most position of the AS_PATH attribute of the best-match unicast route for the destination prefix embedded in the Flow Specification (FSv1 or FSv2) NLRI.¶
The best-match unicast route may change over time independently of the Flow Specification NLRI (FSv1 or FSv2). Therefore, a revalidation of the Flow Specification MUST be performed whenever unicast routes change. Revalidation is defined as retesting rules a to c as described above.¶
A match on a Flow Specification (FS) filters is linked to one or more FS action set by an Extended Communities (FS-EC) for FSv2 for IP Basic functions.¶
Validation of FS-EC action begins with validating the syntax of the Extended Communities attributes attached to FS NLRI in UPDATE packet. Since FSv1 and FSv2 operate on different NLRIs (AFI/SAFI sets), a single FS-EC action can apply to both FSv1 and FSv2 filters. If the FS-EC is not syntactically correct, the FS-EC community causes NLRI and FS-EC to be treated as withdrawal.¶
If the FS-EC is syntacically correct, then the FS-EC check to determine if this node can perform this action. If not, the FS-EC is stored for transmittal to other nodes, but cannot be used in this node.¶
If multiple syntactically correct actions that can be performed on are linked to the filtering rules defined in the NLRI in UPDATE packet, then the list of multiple actions are check for conflicts within a category. If conflicts exist within a multiple action set attached to a FSv2 filter, then the default case is to ignore the action set for installation in the node. Optionally, if the ACO FS-EC may indicate if the BGP peer originating the FSv2 filter + action expects this "ignoring" of the action or specifical local configuration.¶
An example of local configuration might be if rate limiting by byte and by packet are specified, the local configuration might allow both to be enacted in the hardware.¶
If one action in the ordered list fails for a traffic flow, the local node may be able to halt processing of the for. For example, if a DSCP value set and forwarding to VPN is specified AND the DSCP fails, the forwarding logic may allow the forwarding to the VPN to not occur.¶
FSv1-EC current control the failure action by configuration and/or implementation defaults.¶
The optional ACO FSv2-EC can inform the BGP receiving the FSv2 information how the originator expects failures within the multiple actions in an action set will occur. The ACO FSv2-EC is optional.¶
FSv2 Implementations MAY wish to log the action failures encountered by FS actions (FSv1 or FSv2).¶
The following two error handling rules must be followed by all BGP speakers which support FSv2:¶
FSv2 NLRI having TLVs which do not have the correct lengths or syntax must be considered MALFORMED, and "treated-as-withdrawl".¶
FSv2 NLRIs having TLVs which do not follow the above ordering rules described in section 4.1 MUST be considered as MALFORMED by a BGP FSv2 propagator, and treated "treated-as-withdrawl".¶
The above two rules prevent any ambiguity that arises from the multiple copies of the same NLRI from multiple BGP FSv2 propagators.¶
A BGP implementation SHOULD treat such malformed NLRIs as ‘session reset’ [RFC7606]¶
An implementation for a BGP speaker supporting both FSv1 and FSv2 MUST support the error handling for both FSv1 and FSv2.¶
FSv2 allows the user to order flow specification rules and the actions associated with a rule. Each FSv2 rule has one or more match conditions and one or more actions associated with each rule.¶
FSv1 and FSv2 filters are sent as different AFI/SAFI pairs so FSv1 and FSv2 operate as ships-in-the-night. Some BGP peers in an AS may support both FSv1 and FSv2. Other BGP peers may support FSv1 or FSv2. Some BGP will not support FSv1 or FSV2. A coherent flow specification technology must have consistent best practices for ordering the FSv1 and FSv2 filter rules.¶
One simple rule captures the best practice: Order the FSv1 filters after the FSv2 filter by placing the FSv1 filters after the FSv2 filters.¶
To operationally make this work, all flow specification filters should be included the same data base with the FSv1 filters being assigned a user- defined order beyond the normal size of FSv2 user-ordered values. A few examples, may help to illustrate this best practice.¶
Example 1: User ordered numbering - Suppose you might have 1,000 rules for the FSv2 filters. Assign all the FSv1 user defined rules to 1,001 (or better yet 2,000). The FSv1 rules will be ordered by the components and component values.¶
Example 2: Storage of actions - All FSv1 actions are defined ordered actions in FSv2. Translate your FSv1 actions into FSv2 ordered actions for storing in a common FSv1-FSv2 flow specification data base.¶
Operational issues drive the deployment of BGP flow specification as a quick and scalable way to distribute filters. The early operations accepted the fact validation of the distribution of filter needed to be done outside of the BGP distribution mechanism. Other mechanisms (NETCONF/RESTCONF or PCEP) have reply-request protocols.¶
These features within BGP have not changed. BGP still does not have an action-reply feature.¶
NETCONF/RESTCONF latest enhancements provide action/response features which scale. The combination of a quick distribution of filters via BGP and a long-term action in NETCONF/RESTCONF that ask for reporting of the installation of FSv2 filters may provide the best scalability.¶
The combination of NETCONF/RESTCONF network management protocols and BGP focuses each protocol on the strengths of scalability.¶
FSv2 will be deployed in webs of BGP peers which have some BGP peers passing FSv1, some BGP peers passing FSv2, some BGP peers passing FSv1 and FSv2, and some BGP peers not passing any routes.¶
The TLV encoding and deterministic behaviors of FSv2 will not deprecate the need for careful design of the distribution of flow specification filters in this mixed environment. The needs of networks for flow specification are different depending on the network topology and the deployment technology for BGP peers sending flow specification.¶
Suppose we have a centralized RR connected to DDoS processing sending out flow specification to a second tier of RR who distribute the information to targeted nodes. This type of distribution has one set of needs for FSv2 and the transition from FSv1 to FSv2.¶
Suppose we have Data Center with a 3-tier backbone trying to distribute DDoS or other filters from the spine to combinational nodes, to the leaf BGP nodes. The BGP peers may use RR or normal BGP distribution. This deployment has another set of needs for FSv2 and the transition from FSv1 to FSV2.¶
Suppose we have a corporate network with a few AS sending DDoS filters using basic BGP from a variety of sites. Perhaps the corporate network will be satisfied with FSv1 for a long time.¶
These examples are given to indicate that BGP FSv2, like so many BGP protocols, needs to be carefully tuned to aid the mitigation services within the network. This protocol suite starts the migration toward better tools using FSv2, but it does not end it. With FSv2 TLVs and deterministic actions, new operational mechanisms can start to be understood and utilized.¶
This FSv2 specification is merely the start of a revolution of work – not the end.¶
This section discusses the optional BGP Security additions for BGP-FS v2 relating ROA [RFC9582].¶
BGP FSv2 can utilize ROAs in the validation. If BGP FSv2 is used with BGPSEC and ROA, the first thing is to validate the route within BGPSEC and second to utilize BGP ROA to validate the route origin.¶
The BGP-FS peers using both ROA and BGP-FS validation determine that a BGP Flow specification is valid if and only if one of the following cases:¶
If the BGP Flow Specification NLRI has a IPv4 or IPv6 address in destination address match filter and the following is true:¶
If a BGP ROA has not been received that matches the IPv4 or IPv6 destination address in the destination filter, the match filter must abide by the [RFC8955] and [RFC8956] validation rules as follows:¶
The originator match of the flow specification matches the originator of the best-match unicast route for the destination prefix filter embedded in the flow specification", and¶
No more specific unicast routes exist when compared with the flow destination prefix that have been received from a different neighboring AS than the best-match unicast route, which has been determined in step A.¶
The best match is defined to be the longest-match NLRI with the highest preference.¶
This section complies with [RFC7153].¶
IANA is requested to assign two SAFI Values in the registry at https://www.iana.org/assignments/safi-namespace from the Standard Action Range as follows:¶
Table 7-1 SAFIs
Value Description Reference
----- ------------- ---------------
TBD1 BGP FSv2 [this document]
TBD2 BGP FSv2 VPN [this document]
¶
IANA is requested to assign a type value from the "Generic Transitive Extended Community Sub-Types" registry at https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml¶
Table 7-3 - Generic Transitive Extended Community
Value Description Reference Controller
----- -------------------------- --------------- ----------
TBD4 FSv2 Action Chain Ordering [this document] IETF
¶
IANA is requested to create a new "BGP FSv2 IP Basic Component Types" registry and indicate [this draft] as a reference. The following assignments in the FSv2 IP Basic Filters Component Types Registry shold be made.¶
| Type | Definition | Reference |
|---|---|---|
| 0 | Reserved | This document |
| 10 | IP Destination Prefix | This document |
| 20 | IP Source Prefix | This document |
| 30 | IPv4 Protocol / IPv6 Upper Layer Protocol | This document |
| 40 | Port | This document |
| 50 | Destination Port | This document |
| 60 | Source Port | This document |
| 70 | ICMPv4 Type / ICMPv6 Type | This document |
| 80 | ICMPv4 Code / ICPv6 Code | This document |
| 90 | TCP Flags | This document |
| 100 | Packet Length | This document |
| 110 | DSCP | This document |
| 120 | Fragment | This document |
| 130 | Flow Label | This document |
| 4095 | Reserved | This document |
IANA is requested to create the a new registry for "Flow Specification v2 Filter Component Types".¶
Registration Procedures: 0x01-0x3FFF Standards Action.¶
| Type | Description | Reference |
|---|---|---|
| 0 | Reserved | [this document] |
| 1-49 | Unassigned | [this document] |
| 50 | L2 Traffic Rules | [this document] |
| 51-99 | Unassigned | [this document] |
| 100 | MPLS traffic rules | [this document] |
| 101-149 | Unassigned | [this document] |
| 150 | SFC Traffic rules | [this document] |
| 151-199 | Unassigned | [this document] |
| 200 | Tunnel Traffic rules | [this document] |
| 201-255 | Unassigned | [this document] |
| 256 | IP traffic rules | [this document] |
| 257-279 | Unassigned | [this document] |
| 280 | Extended IP Rules | [this document] |
| 281-24575 | Unassigned | [this document] |
| 24576-32767 | Vendor specific | [this document] |
| 32768-65535 | Reserved | [this document] |
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.¶