idnits 2.17.00 (12 Aug 2021) /tmp/idnits21802/draft-ietf-idr-flow-spec-v6-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 14, 2020) is 516 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 665 == Outdated reference: draft-ietf-idr-rfc5575bis has been published as RFC 8955 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group C. Loibl, Ed. 3 Internet-Draft next layer Telekom GmbH 4 Updates: I-D.ietf-idr-rfc5575bis (if R. Raszuk, Ed. 5 approved) Bloomberg LP 6 Intended status: Standards Track S. Hares, Ed. 7 Expires: June 17, 2021 Huawei 8 December 14, 2020 10 Dissemination of Flow Specification Rules for IPv6 11 draft-ietf-idr-flow-spec-v6-22 13 Abstract 15 Dissemination of Flow Specification Rules I-D.ietf-idr-rfc5575bis 16 provides a Border Gateway Protocol extension for the propagation of 17 traffic flow information for the purpose of rate limiting or 18 filtering IPv4 protocol data packets. 20 This document extends I-D.ietf-idr-rfc5575bis with IPv6 21 functionality. It also updates I-D.ietf-idr-rfc5575bis by changing 22 the IANA Flow Spec Component Types registry. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 17, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Definitions of Terms Used in This Memo . . . . . . . . . 3 60 2. IPv6 Flow Specification encoding in BGP . . . . . . . . . . . 3 61 3. IPv6 Flow Specification components . . . . . . . . . . . . . 3 62 3.1. Type 1 - Destination IPv6 Prefix . . . . . . . . . . . . 4 63 3.2. Type 2 - Source IPv6 Prefix . . . . . . . . . . . . . . . 4 64 3.3. Type 3 - Upper-Layer Protocol . . . . . . . . . . . . . . 5 65 3.4. Type 7 - ICMPv6 Type . . . . . . . . . . . . . . . . . . 5 66 3.5. Type 8 - ICMPv6 Code . . . . . . . . . . . . . . . . . . 5 67 3.6. Type 12 - Fragment . . . . . . . . . . . . . . . . . . . 6 68 3.7. Type 13 - Flow Label (new) . . . . . . . . . . . . . . . 7 69 3.8. Encoding Example . . . . . . . . . . . . . . . . . . . . 7 70 4. Ordering of Flow Specifications . . . . . . . . . . . . . . . 9 71 5. Validation Procedure . . . . . . . . . . . . . . . . . . . . 10 72 6. IPv6 Traffic Filtering Action changes . . . . . . . . . . . . 10 73 6.1. Redirect IPv6 (rt-redirect-ipv6) Type TBD . . . . . . . . 10 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 8.1. Flow Spec IPv6 Component Types . . . . . . . . . . . . . 11 77 8.1.1. Registry Template . . . . . . . . . . . . . . . . . . 11 78 8.1.2. Registry Contents . . . . . . . . . . . . . . . . . . 11 79 8.2. IPv6-Address-Specific Extended Community Flow Spec IPv6 80 Actions . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 82 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 Appendix A. Example python code: flow_rule_cmp_v6 . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 The growing amount of IPv6 traffic in private and public networks 92 requires the extension of tools used in IPv4-only networks to also 93 support IPv6 data packets. 95 This document analyzes the differences between describing IPv6 96 [RFC8200] flows and those of IPv4 packets. It specifies new Border 97 Gateway Protocol [RFC4271] encoding formats to enable Dissemination 98 of Flow Specification Rules [I-D.ietf-idr-rfc5575bis] for IPv6. 100 This specification is an extension of the base 101 [I-D.ietf-idr-rfc5575bis]. It only defines the delta changes 102 required to support IPv6 while all other definitions and operation 103 mechanisms of Dissemination of Flow Specification Rules will remain 104 in the main specification and will not be repeated here. 106 1.1. Definitions of Terms Used in This Memo 108 AFI - Address Family Identifier. 110 AS - Autonomous System. 112 NLRI - Network Layer Reachability Information. 114 SAFI - Subsequent Address Family Identifier. 116 VRF - Virtual Routing and Forwarding instance. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 2. IPv6 Flow Specification encoding in BGP 126 [I-D.ietf-idr-rfc5575bis] defines SAFIs 133 (Dissemination of Flow 127 Specification) and 134 (L3VPN Dissemination of Flow Specification) in 128 order to carry the corresponding Flow Specification. 130 Implementations wishing to exchange IPv6 Flow Specifications MUST use 131 BGP's Capability Advertisement facility to exchange the Multiprotocol 132 Extension Capability Code (Code 1) as defined in [RFC4760]. The 133 (AFI, SAFI) pair carried in the Multiprotocol Extension Capability 134 MUST be: (AFI=2, SAFI=133) for IPv6 Flow Specification, and (AFI=2, 135 SAFI=134) for VPNv6 Flow Specification. 137 3. IPv6 Flow Specification components 139 The encoding of each of the components begins with a type field (1 140 octet) followed by a variable length parameter. The following 141 sections define component types and parameter encodings for IPv6. 143 Types 4 (Port), 5 (Destination Port), 6 (Source Port), 9 (TCP flags), 144 10 (Packet length) and 11 (DSCP), as defined in 146 [I-D.ietf-idr-rfc5575bis], also apply to IPv6. Note that IANA is 147 requested to update the "Flow Spec Component Types" registry in order 148 to contain both IPv4 and IPv6 Flow Specification component type 149 numbers in a single registry (Section 8). 151 3.1. Type 1 - Destination IPv6 Prefix 153 Encoding: 156 Defines the destination prefix to match. The offset has been defined 157 to allow for flexible matching to portions of an IPv6 address where 158 one is required to skip over the first N bits of the address (these 159 bits skipped are often indicated as "don't care" bits). This can be 160 especially useful where part of the IPv6 address consists of an 161 embedded IPv4 address and matching needs to happen only on the 162 embedded IPv4 address. The encoded pattern contains enough octets 163 for the bits used in matching (length minus offset bits). 165 length - The length field indicates the N-th most significant bit in 166 the address where bitwise pattern matching stops. 168 offset - The offset field indicates the number of most significant 169 address bits to skip before bitwise pattern matching starts. 171 pattern - Contains the matching pattern. The length of the pattern 172 is defined by the number of bits needed for pattern matching 173 (length minus offset). 175 padding - The minimum number of bits required to pad the component 176 to an octet boundary. Padding bits MUST be 0 on encoding and MUST 177 be ignored on decoding. 179 length = offset = 0 matches every address, otherwise length MUST be 180 in the range offset < length < 129 or the component is malformed. 182 Note: This Flow Specification component can be represented by the 183 notation ipv6address/length if offset is 0, or ipv6address/offset- 184 length. The ipv6address in this notation is the textual IPv6 185 representation of the pattern shifted to the right by the number of 186 offset bits. See also Section 3.8. 188 3.2. Type 2 - Source IPv6 Prefix 190 Encoding: 192 Defines the source prefix to match. The length, offset, pattern and 193 padding are the same as in Section 3.1. 195 3.3. Type 3 - Upper-Layer Protocol 197 Encoding: 199 Contains a list of {numeric_op, value} pairs that are used to match 200 the first Next Header value octet in IPv6 packets that is not an 201 extension header and thus indicates that the next item in the packet 202 is the corresponding upper-layer header (see [RFC8200] Section 4). 204 This component uses the Numeric Operator (numeric_op) described in 205 [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 3 component values 206 SHOULD be encoded as single octet (numeric_op len=00). 208 Note: While IPv6 allows for more than one Next Header field in the 209 packet, the main goal of the Type 3 Flow Specification component is 210 to match on the first upper-layer IP protocol value. Therefore the 211 definition is limited to match only on this specific Next Header 212 field in the packet. 214 3.4. Type 7 - ICMPv6 Type 216 Encoding: 218 Defines a list of {numeric_op, value} pairs used to match the type 219 field of an ICMPv6 packet (see also [RFC4443] Section 2.1). 221 This component uses the Numeric Operator (numeric_op) described in 222 [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 7 component values 223 SHOULD be encoded as single octet (numeric_op len=00). 225 In case of the presence of the ICMPv6 Type component only ICMPv6 226 packets can match the entire Flow Specification. The ICMPv6 Type 227 component, if present, never matches when the packet's upper-layer IP 228 protocol value is not 58 (ICMPv6), if the packet is fragmented and 229 this is not the first fragment, or if the system is unable to locate 230 the transport header. Different implementations may or may not be 231 able to decode the transport header. 233 3.5. Type 8 - ICMPv6 Code 235 Encoding: 237 Defines a list of {numeric_op, value} pairs used to match the code 238 field of an ICMPv6 packet (see also [RFC4443] Section 2.1). 240 This component uses the Numeric Operator (numeric_op) described in 241 [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 8 component values 242 SHOULD be encoded as single octet (numeric_op len=00). 244 In case of the presence of the ICMPv6 Code component only ICMPv6 245 packets can match the entire Flow Specification. The ICMPv6 code 246 component, if present, never matches when the packet's upper-layer IP 247 protocol value is not 58 (ICMPv6), if the packet is fragmented and 248 this is not the first fragment, or if the system is unable to locate 249 the transport header. Different implementations may or may not be 250 able to decode the transport header. 252 3.6. Type 12 - Fragment 254 Encoding: 256 Defines a list of {bitmask_op, bitmask} pairs used to match specific 257 IP fragments. 259 This component uses the Bitmask Operator (bitmask_op) described in 260 [I-D.ietf-idr-rfc5575bis] Section 4.2.1.2. The Type 12 component 261 bitmask MUST be encoded as single octet bitmask (bitmask_op len=00). 263 0 1 2 3 4 5 6 7 264 +---+---+---+---+---+---+---+---+ 265 | 0 | 0 | 0 | 0 |LF |FF |IsF| 0 | 266 +---+---+---+---+---+---+---+---+ 268 Figure 1: Fragment Bitmask Operand 270 Bitmask values: 272 IsF - Is a fragment other than the first - match if IPv6 Fragment 273 Header ([RFC8200] Section 4.5) Fragment Offset is not 0 275 FF - First fragment - match if IPv6 Fragment Header ([RFC8200] 276 Section 4.5) Fragment Offset is 0 AND M flag is 1 278 LF - Last fragment - match if IPv6 Fragment Header ([RFC8200] 279 Section 4.5) Fragment Offset is not 0 AND M flag is 0 281 0 - MUST be set to 0 on NLRI encoding, and MUST be ignored during 282 decoding 284 3.7. Type 13 - Flow Label (new) 286 Encoding: 288 Contains a list of {numeric_op, value} pairs that are used to match 289 the 20-bit Flow Label IPv6 header field ([RFC8200] Section 3). 291 This component uses the Numeric Operator (numeric_op) described in 292 [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 13 component values 293 SHOULD be encoded as 4-octet quantities (numeric_op len=10). 295 3.8. Encoding Example 297 3.8.1. Example 1 299 The following example demonstrates the prefix encoding for: "packets 300 from ::1234:5678:9a00:0/64-104 to 2001:db8::/32 and upper-layer- 301 protocol tcp". 303 +--------+----------------------+-------------------------+----------+ 304 | length | destination | source | ul-proto | 305 +--------+----------------------+-------------------------+----------+ 306 | 0x12 | 01 20 00 20 01 0D B8 | 02 68 40 12 34 56 78 9A | 03 81 06 | 307 +--------+----------------------+-------------------------+----------+ 309 Decoded: 311 +-------+------------+-------------------------------+ 312 | Value | | | 313 +-------+------------+-------------------------------+ 314 | 0x12 | length | 18 octets (len<240 1-octet) | 315 | 0x01 | type | Type 1 - Dest. IPv6 Prefix | 316 | 0x20 | length | 32 bit | 317 | 0x00 | offset | 0 bit | 318 | 0x20 | pattern | | 319 | 0x01 | pattern | | 320 | 0x0D | pattern | | 321 | 0xB8 | pattern | (no padding needed) | 322 | 0x02 | type | Type 2 - Source IPv6 Prefix | 323 | 0x68 | length | 104 bit | 324 | 0x40 | offset | 64 bit | 325 | 0x12 | pattern | | 326 | 0x34 | pattern | | 327 | 0x56 | pattern | | 328 | 0x78 | pattern | | 329 | 0x9A | pattern | (no padding needed) | 330 | 0x03 | type | Type 3 - upper-layer-proto | 331 | 0x81 | numeric_op | end-of-list, value size=1, == | 332 | 0x06 | value | 06 | 333 +-------+------------+-------------------------------+ 335 This constitutes a NLRI with a NLRI length of 18 octets. 337 Padding is not needed either for the destination prefix pattern 338 (length - offset = 32 bit) or for the source prefix pattern (length - 339 offset = 40 bit), as both patterns end on an octet boundary. 341 3.8.2. Example 2 343 The following example demonstrates the prefix encoding for: "all 344 packets from ::1234:5678:9a00:0/65-104 to 2001:db8::/32". 346 +--------+----------------------+-------------------------+ 347 | length | destination | source | 348 +--------+----------------------+-------------------------+ 349 | 0x0f | 01 20 00 20 01 0D B8 | 02 68 41 24 68 ac f1 34 | 350 +--------+----------------------+-------------------------+ 352 Decoded: 354 +-------+-------------+-------------------------------+ 355 | Value | | | 356 +-------+-------------+-------------------------------+ 357 | 0x0f | length | 15 octets (len<240 1-octet) | 358 | 0x01 | type | Type 1 - Dest. IPv6 Prefix | 359 | 0x20 | length | 32 bit | 360 | 0x00 | offset | 0 bit | 361 | 0x20 | pattern | | 362 | 0x01 | pattern | | 363 | 0x0D | pattern | | 364 | 0xB8 | pattern | (no padding needed) | 365 | 0x02 | type | Type 2 - Source IPv6 Prefix | 366 | 0x68 | length | 104 bit | 367 | 0x41 | offset | 65 bit | 368 | 0x24 | pattern | | 369 | 0x68 | pattern | | 370 | 0xac | pattern | | 371 | 0xf1 | pattern | | 372 | 0x34 | pattern/pad | (contains 1 bit padding) | 373 +-------+-------------+-------------------------------+ 375 This constitutes a NLRI with a NLRI length of 15 octets. 377 The source prefix pattern is 104 - 65 = 39 bits in length. After the 378 pattern one bit of padding needs to be added so that the component 379 ends on a octet boundary. However, only the first 39 bits are 380 actually used for bitwise pattern matching starting with a 65 bit 381 offset from the topmost bit of the address. 383 4. Ordering of Flow Specifications 385 The definition for the order of traffic filtering rules from 386 [I-D.ietf-idr-rfc5575bis] Section 5.1 is reused with new 387 consideration for the IPv6 prefix offset. As long as the offsets are 388 equal, the comparison is the same, retaining longest-prefix-match 389 semantics. If the offsets are not equal, the lowest offset has 390 precedence, as this Flow Specification matches the most significant 391 bit. 393 The code in Appendix A shows a Python3 implementation of the 394 resulting comparison algorithm. The full code was tested with Python 395 3.7.2 and can be obtained at https://github.com/stoffi92/draft-ietf- 396 idr-flow-spec-v6/tree/master/flowspec-cmp [1]. 398 5. Validation Procedure 400 The validation procedure is the same as specified in 401 [I-D.ietf-idr-rfc5575bis] Section 6 with the exception that item a) 402 of the validation procedure should now read as follows: 404 a) A destination prefix component with offset=0 is embedded in the 405 Flow Specification 407 6. IPv6 Traffic Filtering Action changes 409 Traffic Filtering Actions from [I-D.ietf-idr-rfc5575bis] Section 7 410 can also be applied to IPv6 Flow Specifications. To allow an IPv6- 411 Address-Specific Route-Target, a new Traffic Filtering Action IPv6- 412 Address-Specific Extended Community [RFC5701] is specified in 413 Section 6.1 below. 415 6.1. Redirect IPv6 (rt-redirect-ipv6) Type TBD 417 The redirect IPv6-Address-Specific Extended Community allows the 418 traffic to be redirected to a VRF routing instance that lists the 419 specified IPv6-Address-Specific Route-Target in its import policy. 420 If several local instances match this criteria, the choice between 421 them is a local matter (for example, the instance with the lowest 422 Route Distinguisher value can be elected). 424 This IPv6-Address-Specific Extended Community uses the same encoding 425 as the IPv6-Address-Specific Route-Target Extended Community 426 [RFC5701] Section 2 with the Type value always TBD. 428 The Local Administrator sub-field contains a number from a numbering 429 space that is administered by the organization to which the IP 430 address carried in the Global Administrator sub-field has been 431 assigned by an appropriate authority. 433 Interferes with: All BGP Flow Specification redirect Traffic 434 Filtering Actions (with itself and those specified in 435 [I-D.ietf-idr-rfc5575bis] Section 7.4). 437 7. Security Considerations 439 This document extends the functionality in [I-D.ietf-idr-rfc5575bis] 440 to be applicable to IPv6 data packets. The same Security 441 Considerations from [I-D.ietf-idr-rfc5575bis] now also apply to IPv6 442 networks. 444 [RFC7112] describes the impact of oversized IPv6 header chains when 445 trying to match on the transport header; [RFC8200] Section 4.5 also 446 requires that the first fragment must include the upper-layer header 447 but there could be wrongly formatted packets not respecting 448 [RFC8200]. IPv6 Flow Specification component type 3 (Section 3.3) 449 will not be enforced for those illegal packets. Moreover, there are 450 hardware limitations in several routers ([RFC8883] Section 1) that 451 may make it impossible to enforce a policy signaled by a type 3 Flow 452 Specification component or Flow Specification components that match 453 on upper-layer properties of the packet. 455 8. IANA Considerations 457 This section complies with [RFC7153]. 459 8.1. Flow Spec IPv6 Component Types 461 IANA has created and maintains a registry entitled "Flow Spec 462 Component Types". IANA is requested to add [this document] to the 463 reference for this registry. Furthermore the registry should be 464 rewritten to also contain the IPv6 Flow Specification Component Types 465 as described below. The registration procedure should remain 466 unchanged. 468 8.1.1. Registry Template 470 Type Value: 471 Contains the assigned Flow Specification component type value. 473 IPv4 Name: 474 Contains the associated IPv4 Flow Specification component name 475 as specified in [I-D.ietf-idr-rfc5575bis]. 477 IPv6 Name: 478 Contains the associated IPv6 Flow Specification component name 479 as specified in this document. 481 Reference: 482 Contains referenced to the specifications. 484 8.1.2. Registry Contents 486 + Type Value: 0 487 + IPv4 Name: Reserved 488 + IPv6 Name: Reserved 489 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 491 + Type Value: 1 492 + IPv4 Name: Destination Prefix 493 + IPv6 Name: Destination IPv6 Prefix 494 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 496 + Type Value: 2 497 + IPv4 Name: Source Prefix 498 + IPv6 Name: Source IPv6 Prefix 499 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 501 + Type Value: 3 502 + IPv4 Name: IP Protocol 503 + IPv6 Name: Upper-Layer Protocol 504 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 506 + Type Value: 4 507 + IPv4 Name: Port 508 + IPv6 Name: Port 509 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 511 + Type Value: 5 512 + IPv4 Name: Destination Port 513 + IPv6 Name: Destination Port 514 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 516 + Type Value: 6 517 + IPv4 Name: Source Port 518 + IPv6 Name: Source Port 519 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 521 + Type Value: 7 522 + IPv4 Name: ICMP Type 523 + IPv6 Name: ICMPv6 Type 524 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 526 + Type Value: 8 527 + IPv4 Name: ICMP Code 528 + IPv6 Name: ICMPv6 Code 529 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 531 + Type Value: 9 532 + IPv4 Name: TCP Flags 533 + IPv6 Name: TCP Flags 534 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 536 + Type Value: 10 537 + IPv4 Name: Packet Length 538 + IPv6 Name: Packet Length 539 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 541 + Type Value: 11 542 + IPv4 Name: DSCP 543 + IPv6 Name: DSCP 544 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 546 + Type Value: 12 547 + IPv4 Name: Fragment 548 + IPv6 Name: Fragment 549 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 551 + Type Value: 13 552 + IPv4 Name: Unassigned 553 + IPv6 Name: Flow Label 554 + Reference: [this document] 556 + Type Value: 14-254 557 + IPv4 Name: Unassigned 558 + IPv6 Name: Unassigned 559 + Reference: 561 + Type Value: 255 562 + IPv4 Name: Reserved 563 + IPv6 Name: Reserved 564 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 566 8.2. IPv6-Address-Specific Extended Community Flow Spec IPv6 Actions 568 IANA maintains a registry entitled "Transitive IPv6-Address-Specific 569 Extended Community Types". For the purpose of this work, IANA is 570 requested to assign a new value: 572 +------------+-----------------------------------+-----------------+ 573 | Type Value | Name | Reference | 574 +------------+-----------------------------------+-----------------+ 575 | TBD | Flow spec rt-redirect-ipv6 format | [this document] | 576 +------------+-----------------------------------+-----------------+ 578 Table 1: Registry: Transitive IPv6-Address-Specific Extended 579 Community Types 581 9. Acknowledgements 583 Authors would like to thank Pedro Marques, Hannes Gredler, Bruno 584 Rijsman, Brian Carpenter, and Thomas Mangin for their valuable input. 586 10. Contributors 588 Danny McPherson 589 Verisign, Inc. 591 Email: dmcpherson@verisign.com 593 Burjiz Pithawala 594 Individual 596 Email: burjizp@gmail.com 598 Andy Karch 599 Cisco Systems 600 170 West Tasman Drive 601 San Jose, CA 95134 602 USA 604 Email: akarch@cisco.com 606 11. References 608 11.1. Normative References 610 [I-D.ietf-idr-rfc5575bis] 611 Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 612 Bacher, "Dissemination of Flow Specification Rules", 613 draft-ietf-idr-rfc5575bis-27 (work in progress), October 614 2020. 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, 618 DOI 10.17487/RFC2119, March 1997, 619 . 621 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 622 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 623 DOI 10.17487/RFC4271, January 2006, 624 . 626 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 627 Control Message Protocol (ICMPv6) for the Internet 628 Protocol Version 6 (IPv6) Specification", STD 89, 629 RFC 4443, DOI 10.17487/RFC4443, March 2006, 630 . 632 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 633 "Multiprotocol Extensions for BGP-4", RFC 4760, 634 DOI 10.17487/RFC4760, January 2007, 635 . 637 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 638 Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, 639 . 641 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 642 Oversized IPv6 Header Chains", RFC 7112, 643 DOI 10.17487/RFC7112, January 2014, 644 . 646 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 647 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 648 March 2014, . 650 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 651 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 652 May 2017, . 654 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 655 (IPv6) Specification", STD 86, RFC 8200, 656 DOI 10.17487/RFC8200, July 2017, 657 . 659 [RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to 660 Processing Limits", RFC 8883, DOI 10.17487/RFC8883, 661 September 2020, . 663 11.2. URIs 665 [1] https://github.com/stoffi92/draft-ietf-idr-flow-spec- 666 v6/tree/master/flowspec-cmp 668 Appendix A. Example python code: flow_rule_cmp_v6 670 671 """ 672 Copyright (c) 2020 IETF Trust and the persons identified as authors 673 of the code. All rights reserved. 675 Redistribution and use in source and binary forms, with or without 676 modification, is permitted pursuant to, and subject to the license 677 terms contained in, the Simplified BSD License set forth in Section 678 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 679 (https://trustee.ietf.org/license-info). 680 """ 682 import itertools 683 import collections 684 import ipaddress 686 EQUAL = 0 687 A_HAS_PRECEDENCE = 1 688 B_HAS_PRECEDENCE = 2 689 IP_DESTINATION = 1 690 IP_SOURCE = 2 692 FS_component = collections.namedtuple('FS_component', 693 'component_type value') 695 class FS_IPv6_prefix_component: 696 def __init__(self, prefix, offset=0, 697 component_type=IP_DESTINATION): 698 self.offset = offset 699 self.component_type = component_type 700 # make sure if offset != 0 that none of the 701 # first offset bits are set in the prefix 702 self.value = prefix 703 if offset != 0: 704 i = ipaddress.IPv6Interface( 705 (self.value.network_address, offset)) 706 if i.network.network_address != \ 707 ipaddress.ip_address('0::0'): 708 raise ValueError('Bits set in the offset') 710 class FS_nlri(object): 711 """ 712 FS_nlri class implementation that allows sorting. 714 By calling .sort() on an array of FS_nlri objects these 715 will be sorted according to the flow_rule_cmp algorithm. 717 Example: 718 nlri = [ FS_nlri(components=[ 719 FS_component(component_type=4, 720 value=bytearray([0,1,2,3,4,5,6])), 721 ]), 722 FS_nlri(components=[ 723 FS_component(component_type=5, 724 value=bytearray([0,1,2,3,4,5,6])), 725 FS_component(component_type=6, 726 value=bytearray([0,1,2,3,4,5,6])), 727 ]), 728 ] 729 nlri.sort() # sorts the array according to the algorithm 730 """ 731 def __init__(self, components = None): 732 """ 733 components: list of type FS_component 734 """ 735 self.components = components 737 def __lt__(self, other): 738 # use the below algorithm for sorting 739 result = flow_rule_cmp_v6(self, other) 740 if result == B_HAS_PRECEDENCE: 741 return True 742 else: 743 return False 745 def flow_rule_cmp_v6(a, b): 746 """ 747 Implementation of the flowspec sorting algorithm in 748 draft-ietf-idr-flow-spec-v6. 749 """ 750 for comp_a, comp_b in itertools.zip_longest(a.components, 751 b.components): 752 # If a component type does not exist in one rule 753 # this rule has lower precedence 754 if not comp_a: 755 return B_HAS_PRECEDENCE 756 if not comp_b: 758 return A_HAS_PRECEDENCE 759 # Higher precedence for lower component type 760 if comp_a.component_type < comp_b.component_type: 761 return A_HAS_PRECEDENCE 762 if comp_a.component_type > comp_b.component_type: 763 return B_HAS_PRECEDENCE 764 # component types are equal -> type specific comparison 765 if comp_a.component_type in (IP_DESTINATION, IP_SOURCE): 766 if comp_a.offset < comp_b.offset: 767 return A_HAS_PRECEDENCE 768 if comp_a.offset > comp_b.offset: 769 return B_HAS_PRECEDENCE 770 # both components have the same offset 771 # assuming comp_a.value, comp_b.value of type 772 # ipaddress.IPv6Network 773 # and the offset bits are reset to 0 (since they are 774 # not represented in the NLRI) 775 if comp_a.value.overlaps(comp_b.value): 776 # longest prefixlen has precedence 777 if comp_a.value.prefixlen > \ 778 comp_b.value.prefixlen: 779 return A_HAS_PRECEDENCE 780 if comp_a.value.prefixlen < \ 781 comp_b.value.prefixlen: 782 return B_HAS_PRECEDENCE 783 # components equal -> continue with next 784 # component 785 elif comp_a.value > comp_b.value: 786 return B_HAS_PRECEDENCE 787 elif comp_a.value < comp_b.value: 788 return A_HAS_PRECEDENCE 789 else: 790 # assuming comp_a.value, comp_b.value of type 791 # bytearray 792 if len(comp_a.value) == len(comp_b.value): 793 if comp_a.value > comp_b.value: 794 return B_HAS_PRECEDENCE 795 if comp_a.value < comp_b.value: 796 return A_HAS_PRECEDENCE 797 # components equal -> continue with next 798 # component 799 else: 800 common = min(len(comp_a.value), 801 len(comp_b.value)) 802 if comp_a.value[:common] > \ 803 comp_b.value[:common]: 804 return B_HAS_PRECEDENCE 805 elif comp_a.value[:common] < \ 806 comp_b.value[:common]: 807 return A_HAS_PRECEDENCE 808 # the first common bytes match 809 elif len(comp_a.value) > len(comp_b.value): 810 return A_HAS_PRECEDENCE 811 else: 812 return B_HAS_PRECEDENCE 813 return EQUAL 814 816 Authors' Addresses 818 Christoph Loibl (editor) 819 next layer Telekom GmbH 820 Mariahilfer Guertel 37/7 821 Vienna 1150 822 AT 824 Phone: +43 664 1176414 825 Email: cl@tix.at 827 Robert Raszuk (editor) 828 Bloomberg LP 829 731 Lexington Ave 830 New York City, NY 10022 831 USA 833 Email: robert@raszuk.net 835 Susan Hares (editor) 836 Huawei 837 7453 Hickory Hill 838 Saline, MI 48176 839 USA 841 Email: shares@ndzh.com