BGP Flow Specification Version 2 - More IP Filters

2.1. Dependency Filter Chain in FSv2 NLRI Header

FSv2 filters may be distributed in multiple BGP UPDATE packets. The format of the FSv2 NLRI is shown in Figure 3-1. In FSv2, the user can define the order of the filters by an including an order in the FSV2 NLRI prior to the filter. FSv2 also defines an optional dependency filter chain to allow the filter chains to be identified across all FSV2 Filter chains. This information may be installed from BGP data based into firewalls.¶

 +-------------------------------+
 | NLRI length (2 octets)        |
 +-------------------------------+
 |    TLVs+                      |
 | +===========================+ |
 | | order (4 octets)          | |
 | +---------------------------+ |
 | | Dependent filter chain    | |
 | |(type, chain ID, count,    | |
 | | item) (8 octets)          | |
 | +---------------------------+ |
 | + FSv2 Filter type          + |
 | | (2 octets)                | |
 | +---------------------------+ |
 | + length TLVs (2 octet)     + |
 | + --------------------------+ |
 | + value (variable)          + |
 | +---------------------------+ |
 +-------------------------------+

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

Where:¶

order:

4 octet field for the FSv21 user defined order of the filter with a a value of 1-n. The value of zero is invalid¶

Dependent Filters Chain:

8 octets for identifying a chain of FSv2 filters that must be deployed at the same time. (See figure 2-2 for details.) If the dependency filters chain field is also zero, there is no dependency filter chain defined.¶

FSv2 Filter type:

2 octet field for the FSv2 filter type. The Extended IP Filter type value is 2.¶

length:

2 octet field for the length of the value field.¶

value field:

variable length field defined per FSv2 filter type. The value field for the Extended IP Filter rules has the format shown in Figure 2-3.¶

The dependency filter chain has the following components:¶

    +-------------------------------+
    |  Version  (1 octet)           |
    +-------------------------------+
    |  chain id (3 octets)          |
    +-------------------------------+
    |  Count of items (2 octets)    |
    + ------------------------------+
    |  Item (2 octets)              |
    +-------------------------------+

  Figure 2-2 – IP header SubTLV format

where:¶

Version:

This 1 octet field defines the version of the filter chain. Valid values are 1-0xFF. Value 0 is reserved.¶

Chain ID:

This 3 octet field identifies the filter chain. Valid values include 0x00001 to 0xFFFFFF with the value zero (0x000000) being reserved.¶

Count of items:

This 2 octet field contains the count of item on this filter dependency chains. Valid values are 0x0001 to 0xFFFF with the value of zero being reserved.¶

Item:

This (2 octets): filter sequence number on chain Valid values are 0x0001 to 0xFFFF with the value of zero being reserved.¶

2.2. Extended IP Filters TLV

The Extended IP Filters TLV has a type value of 2 with a variable length. The Extended IP Filters value field has the form shown in Figure 2-3 where:¶

FSv2 Extended Filters Group:

is a 1 octet field indicating the group of components supported. Three groups are defined in this document. Additional groups may be defined by registering the group in the FSv2 Extended IP Filter group registry (see IANA registry policy in section x.x), but those groups are outside the scope of this document.¶

Components+:

This field is a sequence of FSv2 Components with the format shown in figure 2-4.¶

    Extended Filters value field
 +-------------------------------+
 |  +--------------------------+ |
 |  | FSv2 Extended Filters    | |
 |  | group(2 octets)          | |
 |  +--------------------------+ |
 |  |  Components+ (variable)  | |
 |  +--------------------------+ |
 +-------------------------------+

 Figure 2-3 - Extended IP Filters TLV

Each Component is a sequence of TLVs with the format¶

  +-------------------------------+
  |  Component Type (1 octet)     |
  +-------------------------------+
  |  Component length (2 octets)  |
  + ------------------------------+
  |  Component value (variable)   |
  +-------------------------------+

  Figure 2-4 – Component format

Where:¶

Component type:

is a 1 octet specify the component type.¶

Component length:

is a 2 octet value specifying the component length.¶

Component value:

is a variable field defined per component.¶

The valid components for the Extended IP Filters defined by this specification are listed in table 2-X below. These components include the following:¶

IP Basic components:

Components 1-13 are defined in [I-D.ietf-idr-fsv2-ip-basic].¶

TTL

Filter on Time to Live in IPv4 packet or maximum hop limit in IPv6 packets.¶

SID function

SID in segment routing header (SRH) in the IPv6 packet.¶

           Table 2-1

 Components for Extended IP Filters

SubTLV    Extended IP Filters Components
-type     for IP Extended Filters version 2
--------  ----------------------------------
   0 -    TTL
   1 -    IP Destination prefix
   2 -    IP Source prefix
   3 –    IPv4 Protocol od
          IPv6 Upper Layer Protocol
   4 –    Port
   5 –    Destination Port
   6 –    Source Port
   7 –    ICMPv4 type or ICMPv6 type
   8 –    ICMPv4 code or ICMPv6 code
   9 –    TCP Flags
  10 –    Packet length
  11 –    DSCP
  12 –    Fragment
  13 –    Flow Label
  14 -    TTL
  15 -    Reserved
  16 -    SID in Routing IPv6 Header

2.3. Extended IP Filters Component Groups

Three groups are defined for Extended IP Filters:¶

FSv1:

comprised of FSv2 components 1-13 (see Table 3-1)¶

FSv1 with TTL

compromised of FSv2 components 0-14 where TTL has component values 0 and 14 (see Table 3-2).¶

SR (Segment Routing)

comprised of FSv2 components 0-17 were TTL has the component value of 0 and 14 (see Table 3-3).¶

Table 2-2 FSv1 Component Group (0x00)

SubTLV    Extended IP Filters Components
-type     for IP Extended Filters version 1
--------  ----------------------------------
   1 -    IP Destination prefix
   2 -    IP Source prefix
   3 –    IPv4 Protocol or
          IPv6 Upper Layer Protocol
   4 –    Port
   5 –    Destination Port
   6 –    Source Port
   7 –    ICMPv4 type or ICMPv6 type
   8 –    ICMPv4 code or ICMPv6 code
   9 –    TCP Flags
  10 –    Packet length
  11 –    DSCP
  12 –    Fragment
  13 –    Flow Label

Table 2-3 FSv1 + TTL Component Group (0x01)

SubTLV    Extended IP Filters Components
-type     for IP Extended Filters version 1
--------  ----------------------------------
   0 -    TTL
   1 -    IP Destination prefix
   2 -    IP Source prefix
   3 –    IPv4 Protocol or
          IPv6 Upper Layer Protocol
   4 –    Port
   5 –    Destination Port
   6 –    Source Port
   7 –    ICMPv4 type or ICMPv6 type
   8 –    ICMPv4 code or ICMPv6 code
   9 –    TCP Flags
  10 –    Packet length
  11 –    DSCP
  12 –    Fragment
  13 –    Flow Label
  14 -    TTL

 Table 2-4 Segment Routing Group (0x02)

SubTLV    Extended IP Filters Components
-type     for IP Extended Filters version 2
--------  ----------------------------------
   0 -    TTL
   1 -    IP Destination prefix
   2 -    IP Source prefix
   3 –    IPv4 Protocol od
          IPv6 Upper Layer Protocol
   4 –    Port
   5 –    Destination Port
   6 –    Source Port
   7 –    ICMPv4 type or ICMPv6 type
   8 –    ICMPv4 code or ICMPv6 code
   9 –    TCP Flags
  10 –    Packet length
  11 –    DSCP
  12 –    Fragment
  13 –    Flow Label
  14 -    TTL
  15 -    Reserved
  16 -    SID in Routing IPv6 Header

Table 2-5 Extended IP Component Ranges

Sub-TLV range   Definition
-------------  -------------
   1-13        V1 filters
  14-63        IP Extended Filters

2.4. Ordering within FSv2 NLRI in Update Packet

The transmission of TLVs within a FSV2 NLRI SHOULD be sent via ascending user order.¶

Within a single user order, the TLVs should be ordered by FSv2 Filter type. The FSv2 Filter types which MUST be supported for the Extended IP Filter support are Filter Type IP Basic (type = 1) and Filter Type Extended IP Filters (type = 2). Other FSv2 Filter types MAY be supported, but the support of those filter types is outside the scope of this document.¶

Within a single user order number and the same IP Basic Filter Type, the components should be ordered by ascending numerical order of the component type.¶

Within a single user order number and the same Extended IP Basic Type, the components should also be ordered by ascending component numbers. The Extended IP Filters version number simply indicates which components are required to be supported per version.¶

Within a single user order and a single component number, the order of the filters is defined by the component. For example, if the component types are the same, then the value fields are compared as defined in [I-D.ietf-idr-fsv2-ip-basic], [RFC8955] and [RFC8956]. The filters MUST be stored with the value fields 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].¶

2.5. Template for Extended IP Components

Summary:

One line title summary¶

Component type:

The numerical value for component type. If the component value has not been assigned by IANA, this value should be in the form TBDx where x is a number (1..N).¶

Description:

Description of what component does.¶

What field component targets in IPv4 packet:

The specific field or fields the compnent filters. If the field filter is in the IPv6 packet, then this field is left (n/a).¶

What field Filter targets in IPv6 packet:

The specific field or fields the compnent filters. If the field filter is in the IPv4 packet, then this field is left (n/a).¶

Length:

Describe the length or possible lengths of this field.¶

Encoding of Component Value field

This is the encoding of the value in FSv2 NLRI. The best descriptions combine a diagram plus a description.¶

Ordering within component:

The mechanism to order if multiple components of the same type occur.¶

conflicts with other filters:

Describe what other filters this component could interfere with.¶

Example encoding:

Provide one simple example of the encoding of a filter for the component.¶

references:

earlier documents which defined this filter.¶

3.1. TTL (type = 0(0x00) or 14(0x0E))

Summary:

Defines matches for 8-bit (1 octet) TTL field in IPv4 header and 8-bit (1 octet) in IPv6 header Hop limit.¶

Component Type:

0 (0x00) and 14 (0x0E). Component type of zero (0x00) places the TTL (IPv4) or Hop limit (IPv6) filter prior to any other component test. Component ID value of 14 (0x0E) places the TTL (IPv4)/Hop limit (IPv6) filter after all IP Basic Filters.¶

Description:

This component filters IPv4 packets on a certain range of values for TTL for IPv4 packets or a range of avalues for Hop Limit for IPv6 packets.¶

What field Filter targets in IPv4 packet:

TTL field¶

What field Filter targets in IPv6 packet:

Hop Limit field¶

Length:

variable with valid values 2-N in increments of 2 octets.¶

Encoding of Component:

TTL Component Value encoding

<[numeric_op, value]+>

   Figure 3-1

where:¶

numeric_op:

1 octet field can express less than, greater than, or equal. The field numeric_op is defined in [I-D.ietf-idr-fsv2-ip-basic]. This is the same format as the numeric-op for FSv1 components.¶

value:

is a 1 octet value for TTL for IPv4 packets and Hop limit for IPv6.¶

ordering of components:

by full value of number_op concatenated with value¶

conflict:

none¶

reference:

draft-bergeon-flowspec-ttl-match-00.txt¶

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

Summary:

IPv6 Service Identifier (SRv6 SID) Filter¶

Component type:

16 (0x10)¶

Description:

Filters the SRv6 SEgment Identifier in an IPv6 address associated the Segment Routing Header (SRH) ([RFC8402]).¶

What field targets in IPv6 Packet:

Segment Routing Header (SRH)¶

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

Length

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

Encoding FSv2 Component Value:

This component is expressed as as a list of filter match conditions where a match is expressed as a bit match for some parts of SID (LOC, FUNCT, ARG) or the whole SID.¶

  +------------------+-------------------+
  | type (1 octet)   | Loc-Len (1 octet) |
  +------------------+-------------------+
  | FUNCT-len (octet)| ARG -len (1 octet)}
  +------------------+-------------------+
  sequence of
  +--------------------------------------+
  | op (1 octet)     |   value (variable |
  +------------------+-------------------+
 [type, LOC-Len, FUNCT-Len, ARG-Len, [op, value]+]

       Figure 3-2

¶

where:¶

• type (1 octet): one type octet determining type of match. The only valid value is 0x00 for Parts of SID.¶

• 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 operator (op) byte:

is encoded as:¶

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

¶

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:

3 bits with the following meanings:¶

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

use of lt,gt, and eq:

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

         Table 3-1  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-4

¶

Dependency between components:

TBD¶

conflicts between components:

TBD¶

Examples in:

TBD¶

reference:

[I-D.ietf-idr-flowspec-srv6]¶

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

Summary:

Network Resource Partition ID Component¶

Description:

This filters an Option in the 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, F bits of function (FUNCT), and A bits of arguments (ARG).¶

What filtering in IPv6 Packet:

IPv6 Hop-by-Hop Options Header ([RFC8402])¶

FSv2 NRP ID Component value field:

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                     |            Reserved           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           NRP ID                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 4-1:  NRP FSv2 Component

¶

where:¶

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:

None¶

reference:

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

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

Summary:

IP Payload filter¶

Description:

Flexible Deep packet filters¶

IP Packet filtering:

IPv4 and/or IPv6¶

What filtering in packet:

Data in header or within the payload.¶

Encoding:

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 component is:¶

        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  | component Len |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | PType | Otype |   offset  (offset-value)      | content length|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        content                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 4-2: 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).¶

Ordering within component:

(TBD)¶

Interacts with components:

(TBD)¶

reference:

[I-D.cui-idr-content-filter-flowspec]¶

4.3. Group ID (type=19 (0x13))

Summary:

Filter on Group ID¶

Description:

Flexible filters on group identifiers¶

IP Packet filtering:

IPv4 or IPv6¶

What filtering:

Group ID specified sub-type¶

What Filtering in Packet:

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

Encoding of component:

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 4-3: 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 = Indirection ID¶

  • 2 = Interface group¶

  • 3 = CATS ID¶

  • 4 = SAV ID¶

  • 5 = 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¶

Ordering within component:

TBD¶

Dependency between components:

TBD¶

Donflicts with other components:

(TBD)¶

Reference:

TBD (just a sample)¶

Note:

In addition, the Group will need to define a registries for Group types and sub-group types.¶

4.4. Proposed Filter Groups

Three new Extended IP filter groups could be created from these filters for SRv6, SRv6+Payload, SRv6 + groups. Tables 3-x, 3-x, and 3-y show these grouping. These groups are simply suggests for the proposed individual drafts to consider.¶

 Table 4-1 SR + Payload Filters

SubTLV    Extended IP Filters Components
-type     for IP Extended Filters version 2
--------  ----------------------------------
   0 -    TTL
   1 -    IP Destination prefix
   2 -    IP Source prefix
   3 –    IPv4 Protocol od
          IPv6 Upper Layer Protocol
   4 –    Port
   5 –    Destination Port
   6 –    Source Port
   7 –    ICMPv4 type or ICMPv6 type
   8 –    ICMPv4 code or ICMPv6 code
   9 –    TCP Flags
  10 –    Packet length
  11 –    DSCP
  12 –    Fragment
  13 –    Flow Label
  14 -    TTL
  15 -    Reserved
  16 -    SID in Routing IPv6 Header
  17 -    NRP-ID in Hop-by-Hop IPv6 Header
  18 -    Payload

 Table 4-2 SR + Payloads + Group Filters

SubTLV    Extended IP Filters Components
-type     for IP Extended Filters version 2
--------  ----------------------------------
   0 -    TTL
   1 -    IP Destination prefix
   2 -    IP Source prefix
   3 –    IPv4 Protocol od
          IPv6 Upper Layer Protocol
   4 –    Port
   5 –    Destination Port
   6 –    Source Port
   7 –    ICMPv4 type or ICMPv6 type
   8 –    ICMPv4 code or ICMPv6 code
   9 –    TCP Flags
  10 –    Packet length
  11 –    DSCP
  12 –    Fragment
  13 –    Flow Label
  14 -    TTL
  15 -    Reserved
  16 -    SID in Routing IPv6 Header
  17 -    NRP-ID in Hop-by-Hop IPv6 Header
  18 -    Payload
  19 -    Group filters

9.1. Normative References

[I-D.hares-idr-bgp-community-attribute]

Hares, S., "BGP Community Container Attribute", Work in Progress, Internet-Draft, draft-hares-idr-bgp-community-attribute-01, 14 October 2024, <https://datatracker.ietf.org/api/v1/doc/document/draft-hares-idr-bgp-community-attribute/>.

[I-D.ietf-6man-enhanced-vpn-vtn-id]

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-07, 8 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-6man-enhanced-vpn-vtn-id-07>.

[I-D.ietf-idr-bgp-flowspec-label]

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, 20 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-flowspec-label-02>.

[I-D.ietf-idr-flowspec-interfaceset]

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, 18 November 2019, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-interfaceset-05>.

[I-D.ietf-idr-flowspec-l2vpn]

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-24, 6 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-24>.

[I-D.ietf-idr-flowspec-mpls-match]

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, 20 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-mpls-match-02>.

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

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, 4 March 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-network-slice-ts-02>.

[I-D.ietf-idr-flowspec-nvo3]

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-20, 16 June 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-nvo3-20>.

[I-D.ietf-idr-flowspec-path-redirect]

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, 24 November 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-path-redirect-12>.

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

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, 29 March 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-srv6-05>.

[I-D.ietf-idr-fsv2-ip-basic]

Hares, S., Eastlake, D. E., Dong, J., Yadlapalli, C., and S. Maduschke, "BGP Flow Specification Version 2 - for Basic IP", Work in Progress, Internet-Draft, draft-ietf-idr-fsv2-ip-basic-01, 3 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-fsv2-ip-basic-01>.

[RFC0791]

Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3032]

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, January 2001, <https://www.rfc-editor.org/info/rfc3032>.

[RFC4271]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4360]

Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <https://www.rfc-editor.org/info/rfc4360>.

[RFC4760]

Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.

[RFC5065]

Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, <https://www.rfc-editor.org/info/rfc5065>.

[RFC5701]

Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, <https://www.rfc-editor.org/info/rfc5701>.

[RFC6482]

Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.

[RFC7153]

Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, <https://www.rfc-editor.org/info/rfc7153>.

[RFC7606]

Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8955]

Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/info/rfc8955>.

[RFC8956]

Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, December 2020, <https://www.rfc-editor.org/info/rfc8956>.

[RFC9015]

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, June 2021, <https://www.rfc-editor.org/info/rfc9015>.

[RFC9117]

Uttaro, J., Alcaide, J., Filsfils, C., Smith, D., and P. Mohapatra, "Revised Validation Procedure for BGP Flow Specifications", RFC 9117, DOI 10.17487/RFC9117, August 2021, <https://www.rfc-editor.org/info/rfc9117>.

[RFC9184]

Loibl, C., "BGP Extended Community Registries Update", RFC 9184, DOI 10.17487/RFC9184, January 2022, <https://www.rfc-editor.org/info/rfc9184>.

[RFC9582]

Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S. Kent, "A Profile for Route Origin Authorizations (ROAs)", RFC 9582, DOI 10.17487/RFC9582, May 2024, <https://www.rfc-editor.org/info/rfc9582>.

9.2. Informative References

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

Cui, Y., Gao, Y., and S. Hares, "Packet Content Filter for BGP FlowSpec", Work in Progress, Internet-Draft, draft-cui-idr-content-filter-flowspec-03, 14 August 2024, <https://datatracker.ietf.org/doc/html/draft-cui-idr-content-filter-flowspec-03>.

[I-D.hares-idr-fsv2-more-ip-actions]

Hares, S., "BGP Flow Specification Version 2 - More IP Actions", Work in Progress, Internet-Draft, draft-hares-idr-fsv2-more-ip-actions-01, 3 June 2024, <https://datatracker.ietf.org/doc/html/draft-hares-idr-fsv2-more-ip-actions-01>.

[I-D.ietf-idr-flowspec-v2]

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, 28 April 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-v2-04>.

[RFC6241]

Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC8040]

Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8205]

Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.

[RFC8206]

George, W. and S. Murphy, "BGPsec Considerations for Autonomous System (AS) Migration", RFC 8206, DOI 10.17487/RFC8206, September 2017, <https://www.rfc-editor.org/info/rfc8206>.

[RFC8300]

Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.

[RFC8402]

Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8986]

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, February 2021, <https://www.rfc-editor.org/info/rfc8986>.