Dissemination of Flow Specification Rules for IPv6
updates
- rfc-8955 — Dissemination of Flow Specification Rules
Extracted elements (25)
IPv6 Flow Specification reuses the same SAFIs (133 and 134) as IPv4 Flow Specification from RFC 8955, differentiated only by AFI=2 for IPv6 versus AFI=1 for IPv4. This avoids defining new SAFIs and leverages existing BGP multiprotocol machinery.
The offset field in IPv6 prefix components (Types 1 and 2) was designed to allow flexible matching on portions of an IPv6 address, particularly useful when part of the address contains an embedded IPv4 address and only that embedded portion needs to match.
Type 3 (Upper-Layer Protocol) is intentionally limited to matching only the first upper-layer IP protocol value, even though IPv6 allows more than one Next Header field. This design choice avoids ambiguity and complexity in matching across extension header chains.
Component types 4 (Port), 5 (Destination Port), 6 (Source Port), 9 (TCP Flags), 10 (Packet Length), and 11 (DSCP) as defined in RFC 8955 for IPv4 also apply unchanged to IPv6 Flow Specifications.
ICMPv6 type and code components (Types 7 and 8) never match when the packet is fragmented and is not the first fragment, or when the system is unable to locate the transport header. Implementations may or may not be able to decode the transport header.
The Redirect IPv6 Extended Community (Type 0x000d) interferes with all BGP Flow Specification redirect Traffic Filtering Actions, including itself and those specified in RFC 8955 Section 7.4. Multiple conflicting redirect actions cannot be applied simultaneously.
When the offset is non-zero in prefix components, the ipv6address in prefix notation (ipv6address/offset-length) represents the textual IPv6 representation of the pattern shifted right by the number of offset bits. Bits in the offset region are not represented in the encoded pattern.
For Destination IPv6 Prefix (Type 1), padding bits MUST be set to 0 on NLRI encoding and MUST be ignored during decoding. If length=0 and offset=0 the component matches every address; otherwise length MUST be in the range offset < length < 129 or the component is malformed.
For Type 12 (Fragment), the bitmask MUST be encoded as a single octet (bitmask_op len=00). Reserved bitmask bits (0, 1, 2, 7) MUST be set to 0 on NLRI encoding and MUST be ignored during decoding.
Implementations wishing to exchange IPv6 Flow Specifications MUST use BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code (Code 1). The (AFI, SAFI) pair MUST be (AFI=2, SAFI=133) for IPv6 Flow Specification rules and (AFI=2, SAFI=134) for L3VPN rules.
The validation procedure from RFC 8955 Section 6 applies, with item (a) updated to read: 'A destination prefix component with offset=0 is embedded in the Flow Specification.' This ensures a valid anchor prefix is always present.
The Redirect IPv6 (rt-redirect-ipv6) Traffic Filtering Action (Type 0x000d) is an IPv6-Address-Specific Extended Community that redirects matched traffic to a VRF routing instance importing the specified IPv6-Address-Specific Route-Target. It uses the same encoding as RFC 5701 with Type always 0x000d.
Type 13 (Flow Label) is a new component encoding a list of {numeric_op, value} pairs that match the 20-bit IPv6 Flow Label header field. Values SHOULD be encoded as 4-octet quantities (numeric_op len=10).
Type 3 (Upper-Layer Protocol) encodes as type (1 octet) followed by {numeric_op, value} pairs matching the first Next Header value in IPv6 packets that is not an extension header. Values SHOULD be encoded as a single octet (numeric_op len=00).
Type 7 (ICMPv6 Type) encodes as type (1 octet) followed by {numeric_op, value} pairs matching the Type field of an ICMPv6 packet. If present, only ICMPv6 packets (upper-layer protocol value 58) can match the entire Flow Specification; the component never matches fragmented non-first fragments.
Type 8 (ICMPv6 Code) encodes as type (1 octet) followed by {numeric_op, value} pairs matching the Code field of an ICMPv6 packet. Like Type 7, it never matches when the upper-layer protocol is not 58 (ICMPv6), when the packet is a non-first fragment, or when the transport header cannot be located.
IANA assigned Type Value 0x000d in the 'Transitive IPv6-Address-Specific Extended Community Types' registry with the name 'Flow spec rt-redirect-ipv6 format' as defined by this document.
IANA updated the 'Flow Spec Component Types' registry to contain both IPv4 and IPv6 Flow Specification component type numbers. The registry template now includes IPv4 Name and IPv6 Name columns. Type 13 is newly assigned as 'Flow Label' for IPv6 (previously Unassigned for IPv4).
Hardware limitations in several routers (RFC 8883 Section 1) may make it impossible to enforce policies signaled by Type 3 (Upper-Layer Protocol) components or Flow Specification components matching upper-layer packet properties. Operators must account for potential non-enforcement in hardware-limited environments.
Oversized IPv6 header chains (RFC 7112) can prevent matching on transport headers. RFC 8200 Section 4.5 requires the first fragment to include the upper-layer header, but malformed packets may not comply. Type 3 (Upper-Layer Protocol) Flow Specification components will not be enforced for such illegal packets.
Flow Specification ordering reuses RFC 8955 Section 5.1 rules with added IPv6 offset consideration: if offsets are equal, longest-prefix-match semantics apply; if offsets differ, the lower offset value takes precedence because it matches the most significant bit position.
Each IPv6 Flow Specification component begins with a 1-octet Type field followed by variable-length parameters. For prefix components (Types 1 and 2), the parameters are length (1 octet), offset (1 octet), pattern (variable), and padding (variable). For operator-value components, parameters are {numeric_op, value} or {bitmask_op, bitmask} pairs.
Type 1 (Destination IPv6 Prefix) encodes as: type (1 octet), length (1 octet), offset (1 octet), pattern (variable), padding (variable). The length field indicates the N-th most significant bit where matching stops; offset indicates bits to skip; padding bits MUST be 0 on encoding and MUST be ignored on decoding.
Type 12 (Fragment) uses a single-octet bitmask (bitmask_op len=00) with three defined bits: IsF (bit 4, Fragment Offset != 0), FF (bit 5, Fragment Offset=0 AND M=1), and LF (bit 3, Fragment Offset != 0 AND M=0). Reserved bits MUST be 0 on encoding and MUST be ignored on decoding.
Type 2 (Source IPv6 Prefix) uses the same encoding as Type 1: type (1 octet), length (1 octet), offset (1 octet), pattern (variable), padding (variable). Length, offset, pattern, and padding semantics are identical to the destination prefix component.