idnits 2.17.1 draft-ietf-idr-flow-spec-v6-15.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 21, 2020) is 1285 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 637 == Unused Reference: 'RFC8126' is defined on line 621, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-idr-rfc5575bis-26 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 Intended status: Standards Track R. Raszuk, Ed. 5 Expires: March 25, 2021 Bloomberg LP 6 S. Hares, Ed. 7 Huawei 8 September 21, 2020 10 Dissemination of Flow Specification Rules for IPv6 11 draft-ietf-idr-flow-spec-v6-15 13 Abstract 15 Dissemination of Flow Specification Rules provides a Border Gateway 16 Protocol extension for the propagation of traffic flow information 17 for the purpose of rate limiting or filtering IPv4 protocol data 18 packets. 20 This specification extends I-D.ietf-idr-rfc5575bis with IPv6 21 functionality. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 25, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Definitions of Terms Used in This Memo . . . . . . . . . 3 59 2. IPv6 Flow Specification encoding in BGP . . . . . . . . . . . 3 60 3. IPv6 Flow Specification components . . . . . . . . . . . . . 3 61 3.1. Type 1 - Destination IPv6 Prefix . . . . . . . . . . . . 4 62 3.2. Type 2 - Source IPv6 Prefix . . . . . . . . . . . . . . . 4 63 3.3. Type 3 - Upper-Layer Protocol . . . . . . . . . . . . . . 4 64 3.4. Type 7 - ICMPv6 Type . . . . . . . . . . . . . . . . . . 5 65 3.5. Type 8 - ICMPv6 Code . . . . . . . . . . . . . . . . . . 5 66 3.6. Type 12 - Fragment . . . . . . . . . . . . . . . . . . . 6 67 3.7. Type 13 - Flow Label (new) . . . . . . . . . . . . . . . 6 68 3.8. Encoding Example . . . . . . . . . . . . . . . . . . . . 7 69 4. Ordering of Flow Specifications . . . . . . . . . . . . . . . 8 70 5. Validation Procedure . . . . . . . . . . . . . . . . . . . . 9 71 6. IPv6 Traffic Filtering Action changes . . . . . . . . . . . . 9 72 6.1. Redirect IPv6 (rt-redirect-ipv6) Type/Sub-Type 0x80/TBD . 9 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 8.1. Flow Spec IPv6 Component Types . . . . . . . . . . . . . 10 76 8.1.1. Registry Template . . . . . . . . . . . . . . . . . . 10 77 8.1.2. Registry Contents . . . . . . . . . . . . . . . . . . 10 78 8.2. Extended Community Flow Spec IPv6 Actions . . . . . . . . 12 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 80 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 Appendix A. Example python code: flow_rule_cmp_v6 . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 87 1. Introduction 89 The growing amount of IPv6 traffic in private and public networks 90 requires the extension of tools used in IPv4-only networks to be also 91 capable of supporting IPv6 data packets. 93 This document analyzes the differences of IPv6 [RFC8200] flows 94 description from those of traditional IPv4 packets and propose a 95 subset of new Border Gateway Protocol [RFC4271] encoding formats to 96 enable Dissemination of Flow Specification Rules 97 [I-D.ietf-idr-rfc5575bis] for IPv6. 99 This specification is an extension of the base 100 [I-D.ietf-idr-rfc5575bis]. It only defines the delta changes 101 required to support IPv6 while all other definitions and operation 102 mechanisms of Dissemination of Flow Specification Rules will remain 103 in the main specification and will not be repeated here. 105 1.1. Definitions of Terms Used in This Memo 107 AFI - Address Family Identifier. 109 AS - Autonomous System. 111 NLRI - Network Layer Reachability Information. 113 SAFI - Subsequent Address Family Identifier. 115 VRF - Virtual Routing and Forwarding instance. 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 2. IPv6 Flow Specification encoding in BGP 125 [I-D.ietf-idr-rfc5575bis] defines SAFIs 133 (Dissemination of Flow 126 Specification) and 134 (L3VPN Dissemination of Flow Specification) in 127 order to carry the corresponding Flow Specification. 129 Implementations wishing to exchange IPv6 Flow Specifications MUST use 130 BGP's Capability Advertisement facility to exchange the Multiprotocol 131 Extension Capability Code (Code 1) as defined in [RFC4760]. The 132 (AFI, SAFI) pair carried in the Multiprotocol Extension Capability 133 MUST be: (AFI=2, SAFI=133) for IPv6 Flow Specification, and (AFI=2, 134 SAFI=134) for VPNv6 Flow Specification. 136 3. IPv6 Flow Specification components 138 The encoding of each of the components begins with a type field (1 139 octet) followed by a variable length parameter. The following 140 sections define component types and parameter encodings for IPv6. 142 Types 4, 5, 6, 9, 10 and 11, as defined in [I-D.ietf-idr-rfc5575bis], 143 also apply to IPv6. Note that even if the definitions are the same 144 (and not repeated here), the number space is managed separately 145 (Section 8). 147 3.1. Type 1 - Destination IPv6 Prefix 149 Encoding: 152 Defines the destination prefix to match. The offset has been defined 153 to allow for flexible matching on part of the IPv6 address where it 154 is required to skip (don't care) of N first bits of the address. 155 This can be especially useful where part of the IPv6 address consists 156 of an embedded IPv4 address and matching needs to happen only on the 157 embedded IPv4 address. The encoded pattern contains enough octets 158 for the bits used in matching (length minus offset bits). 160 length - The length field indicates the N-th leftmost bit in the 161 address where bitwise pattern matching stops. 163 offset - The offset field indicates the number of leftmost address 164 bits to skip before bitwise pattern matching starts. 166 pattern - Contains the matching pattern. The length of the pattern 167 is defined by the number of bits needed for pattern matching 168 (length minus offset). 170 padding - The minimum number of bits required to pad the component 171 to an octet boundary. Padding bits MUST be 0 on encoding and MUST 172 be ignored on decoding. 174 Length minus offset must always be 0 or more, otherwise this 175 component is malformed. 177 3.2. Type 2 - Source IPv6 Prefix 179 Encoding: 182 Defines the source prefix to match. The length, offset, pattern and 183 padding are the same as in Section 3.1 185 3.3. Type 3 - Upper-Layer Protocol 187 Encoding: 189 Contains a list of {numeric_op, value} pairs that are used to match 190 the first Next Header value octet in IPv6 packets that is not an 191 extension header and thus indicates that the next item in the packet 192 is the corresponding upper-layer header (see [RFC8200] Section 4). 194 This component uses the Numeric Operator (numeric_op) described in 195 [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 3 component values 196 SHOULD be encoded as single octet (numeric_op len=00). 198 Note: While IPv6 allows for more than one Next Header field in the 199 packet, the main goal of the Type 3 Flow Specification component is 200 to match on the first upper-layer IP protocol value. Therefore the 201 definition is limited to match only on this specific Next Header 202 field in the packet. 204 3.4. Type 7 - ICMPv6 Type 206 Encoding: 208 Defines a list of {numeric_op, value} pairs used to match the type 209 field of an ICMPv6 packet (see also [RFC4443] Section 2.1). 211 This component uses the Numeric Operator (numeric_op) described in 212 [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 7 component values 213 SHOULD be encoded as single octet (numeric_op len=00). 215 In case of the presence of the ICMPv6 Type component only ICMPv6 216 packets can match the entire Flow Specification. The ICMPv6 Type 217 component, if present, never matches when the packet's upper-layer IP 218 protocol value is not 58 (ICMPv6), if the packet is fragmented and 219 this is not the first fragment, or if the system is unable to locate 220 the transport header. Different implementations may or may not be 221 able to decode the transport header. 223 3.5. Type 8 - ICMPv6 Code 225 Encoding: 227 Defines a list of {numeric_op, value} pairs used to match the code 228 field of an ICMPv6 packet (see also [RFC4443] Section 2.1). 230 This component uses the Numeric Operator (numeric_op) described in 231 [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 8 component values 232 SHOULD be encoded as single octet (numeric_op len=00). 234 In case of the presence of the ICMPv6 Code component only ICMPv6 235 packets can match the entire Flow Specification. The ICMPv6 code 236 component, if present, never matches when the packet's upper-layer IP 237 protocol value is not 58 (ICMPv6), if the packet is fragmented and 238 this is not the first fragment, or if the system is unable to locate 239 the transport header. Different implementations may or may not be 240 able to decode the transport header. 242 3.6. Type 12 - Fragment 244 Encoding: 246 Defines a list of {bitmask_op, bitmask} pairs used to match specific 247 IP fragments. 249 This component uses the Bitmask Operator (bitmask_op) described in 250 [I-D.ietf-idr-rfc5575bis] Section 4.2.1.2. The Type 12 component 251 bitmask MUST be encoded as single octet bitmask (bitmask_op len=00). 253 0 1 2 3 4 5 6 7 254 +---+---+---+---+---+---+---+---+ 255 | 0 | 0 | 0 | 0 |LF |FF |IsF| 0 | 256 +---+---+---+---+---+---+---+---+ 258 Figure 1: Fragment Bitmask Operand 260 Bitmask values: 262 IsF - Is a fragment - match if IPv6 Fragment Header ([RFC8200] 263 Section 4.5) Fragment Offset is not 0 265 FF - First fragment - match if IPv6 Fragment Header ([RFC8200] 266 Section 4.5) Fragment Offset is 0 AND M flag is 1 268 LF - Last fragment - match if IPv6 Fragment Header ([RFC8200] 269 Section 4.5) Fragment Offset is not 0 AND M flag is 0 271 0 - MUST be set to 0 on NLRI encoding, and MUST be ignored during 272 decoding 274 3.7. Type 13 - Flow Label (new) 276 Encoding: 278 Contains a list of {numeric_op, value} pairs that are used to match 279 the 20-bit Flow Label IPv6 header field ([RFC8200] Section 3). 281 This component uses the Numeric Operator (numeric_op) described in 282 [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 13 component values 283 SHOULD be encoded as 1-, 2-, or 4-byte quantities (numeric_op len=00, 284 len=01 or len=10). 286 3.8. Encoding Example 288 3.8.1. Example 1 290 The following example demonstrates the prefix encoding for: "packets 291 from ::1234:5678:9A00:0/64-104 to 2001:DB8::/32 and upper-layer- 292 protocol tcp". 294 +--------+----------------------+-------------------------+----------+ 295 | length | destination | source | ul-proto | 296 +--------+----------------------+-------------------------+----------+ 297 | 0x12 | 01 20 00 20 01 0D B8 | 02 68 40 12 34 56 78 9A | 03 81 06 | 298 +--------+----------------------+-------------------------+----------+ 300 Decoded: 302 +-------+------------+-------------------------------+ 303 | Value | | | 304 +-------+------------+-------------------------------+ 305 | 0x12 | length | 18 octets (len<240 1-octet) | 306 | 0x01 | type | Type 1 - Dest. IPv6 Prefix | 307 | 0x20 | length | 32 bit | 308 | 0x00 | offset | 0 bit | 309 | 0x20 | pattern | | 310 | 0x01 | pattern | | 311 | 0x0D | pattern | | 312 | 0xB8 | pattern | (no padding needed) | 313 | 0x02 | type | Type 2 - Source IPv6 Prefix | 314 | 0x68 | length | 104 bit | 315 | 0x40 | offset | 64 bit | 316 | 0x12 | pattern | | 317 | 0x34 | pattern | | 318 | 0x56 | pattern | | 319 | 0x78 | pattern | | 320 | 0x9A | pattern | (no padding needed) | 321 | 0x03 | type | Type 3 - upper-layer-proto | 322 | 0x81 | numeric_op | end-of-list, value size=1, == | 323 | 0x06 | value | 06 | 324 +-------+------------+-------------------------------+ 326 This constitutes a NLRI with a NLRI length of 18 octets. 328 Neither for the destination prefix pattern (length - offset = 32 bit) 329 nor for the source prefix pattern (length - offset = 40 bit) any 330 padding is needed (both patterns end on a octet boundary). 332 3.8.2. Example 2 334 The following example demonstrates the prefix encoding for: "all 335 packets from ::1234:5678:9A00:0/65-104 to 2001:DB8::/32". 337 +--------+----------------------+-------------------------+ 338 | length | destination | source | 339 +--------+----------------------+-------------------------+ 340 | 0x0f | 01 20 00 20 01 0D B8 | 02 68 41 24 68 ac f1 34 | 341 +--------+----------------------+-------------------------+ 343 Decoded: 345 +-------+-------------+-------------------------------+ 346 | Value | | | 347 +-------+-------------+-------------------------------+ 348 | 0x0f | length | 15 octets (len<240 1-octet) | 349 | 0x01 | type | Type 1 - Dest. IPv6 Prefix | 350 | 0x20 | length | 32 bit | 351 | 0x00 | offset | 0 bit | 352 | 0x20 | pattern | | 353 | 0x01 | pattern | | 354 | 0x0D | pattern | | 355 | 0xB8 | pattern | (no padding needed) | 356 | 0x02 | type | Type 2 - Source IPv6 Prefix | 357 | 0x68 | length | 104 bit | 358 | 0x41 | offset | 65 bit | 359 | 0x24 | pattern | | 360 | 0x68 | pattern | | 361 | 0xac | pattern | | 362 | 0xf1 | pattern | | 363 | 0x34 | pattern/pad | (contains 1 bit padding) | 364 +-------+-------------+-------------------------------+ 366 This constitutes a NLRI with a NLRI length of 15 octets. 368 The source prefix pattern is 104 - 65 = 39 bits in length. After the 369 pattern one bit of padding needs to be added so that the component 370 ends on a octet boundary. However, only the first 39 bits are 371 actually used for bitwise pattern matching starting with a 65 bit 372 offset from the topmost bit of the address. 374 4. Ordering of Flow Specifications 376 The definition for the order of traffic filtering rules from 377 [I-D.ietf-idr-rfc5575bis] Section 5.1 is reused with new 378 consideration for the IPv6 prefix offset. As long as the offsets are 379 equal, the comparison is the same, retaining longest-prefix-match 380 semantics. If the offsets are not equal, the lowest offset has 381 precedence, as this flow matches the most significant bit. 383 The code in Appendix A shows a Python3 implementation of the 384 resulting comparison algorithm. The full code was tested with Python 385 3.7.2 and can be obtained at https://github.com/stoffi92/draft-ietf- 386 idr-flow-spec-v6/tree/master/flowspec-cmp [1]. 388 5. Validation Procedure 390 The validation procedure is the same as specified in 391 [I-D.ietf-idr-rfc5575bis] Section 6 with the exception that item a) 392 of the validation procedure should now read as follows: 394 a) A destination prefix component with offset=0 is embedded in the 395 Flow Specification 397 6. IPv6 Traffic Filtering Action changes 399 Traffic Filtering Actions from [I-D.ietf-idr-rfc5575bis] Section 7 400 can also be applied to IPv6 Flow Specifications. To allow an IPv6 401 address specific route-target, a new Traffic Filtering Action IPv6 402 address specific extended community is specified in Section 6.1 403 below. 405 6.1. Redirect IPv6 (rt-redirect-ipv6) Type/Sub-Type 0x80/TBD 407 The redirect IPv6 address specific extended community allows the 408 traffic to be redirected to a VRF routing instance that lists the 409 specified IPv6 address specific route-target in its import policy. 410 If several local instances match this criteria, the choice between 411 them is a local matter (for example, the instance with the lowest 412 Route Distinguisher value can be elected). 414 This extended community uses the same encoding as the IPv6 address 415 specific Route Target extended community [RFC5701] Section 2 with the 416 high-order octet of the Type always set to 0x80 and the Sub-Type 417 always TBD. 419 Interferes with: All BGP Flow Specification redirect Traffic 420 Filtering Actions (with itself and those specified in 421 [I-D.ietf-idr-rfc5575bis] Section 7.4). 423 7. Security Considerations 425 This document extends the functionality in [I-D.ietf-idr-rfc5575bis] 426 to be applicable to IPv6 data packets. The same Security 427 Considerations from [I-D.ietf-idr-rfc5575bis] now also apply to IPv6 428 networks. Otherwise, no new security issues are added to the BGP 429 protocol. 431 8. IANA Considerations 433 This section complies with [RFC7153]. 435 8.1. Flow Spec IPv6 Component Types 437 IANA has created and maintains a registry entitled "Flow Spec 438 Component Types". IANA is requested to add [this document] to the 439 reference for this registry. Furthermore the registry should be 440 rewritten to also contain the IPv6 Flow Specification Component Types 441 as described below. 443 8.1.1. Registry Template 445 Type Value: 446 Contains the assigned Flow Specification component type value. 448 IPv4 Name: 449 Contains the associated IPv4 Flow Specification component name 450 as specified in [I-D.ietf-idr-rfc5575bis]. 452 IPv6 Name: 453 Contains the associated IPv6 Flow Specification component name 454 as specified in this document. 456 Reference: 457 Contains referenced to the specifications. 459 8.1.2. Registry Contents 461 + Type Value: 0 462 + IPv4 Name: Reserved 463 + IPv6 Name: Reserved 464 + Reference: [I-D.ietf-idr-rfc5575bis] 466 + Type Value: 1 467 + IPv4 Name: Destination Prefix 468 + IPv6 Name: Destination IPv6 Prefix 469 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 471 + Type Value: 2 472 + IPv4 Name: Source Prefix 473 + IPv6 Name: Source IPv6 Prefix 474 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 476 + Type Value: 3 477 + IPv4 Name: IP Protocol 478 + IPv6 Name: Upper-Layer Protocol 479 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 481 + Type Value: 4 482 + IPv4 Name: Port 483 + IPv6 Name: Port 484 + Reference: [I-D.ietf-idr-rfc5575bis] 486 + Type Value: 5 487 + IPv4 Name: Destination Port 488 + IPv6 Name: Destination Port 489 + Reference: [I-D.ietf-idr-rfc5575bis] 491 + Type Value: 6 492 + IPv4 Name: Source Port 493 + IPv6 Name: Source Port 494 + Reference: [I-D.ietf-idr-rfc5575bis] 496 + Type Value: 7 497 + IPv4 Name: ICMP Type 498 + IPv6 Name: ICMPv6 Type 499 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 501 + Type Value: 8 502 + IPv4 Name: ICMP Code 503 + IPv6 Name: ICMPv6 Code 504 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 506 + Type Value: 9 507 + IPv4 Name: TCP flags 508 + IPv6 Name: TCP flags 509 + Reference: [I-D.ietf-idr-rfc5575bis] 511 + Type Value: 10 512 + IPv4 Name: Packet length 513 + IPv6 Name: Packet length 514 + Reference: [I-D.ietf-idr-rfc5575bis] 516 + Type Value: 11 517 + IPv4 Name: DSCP 518 + IPv6 Name: DSCP 519 + Reference: [I-D.ietf-idr-rfc5575bis] 521 + Type Value: 12 522 + IPv4 Name: Fragment 523 + IPv6 Name: Fragment 524 + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 526 + Type Value: 13 527 + IPv4 Name: Unassigned 528 + IPv6 Name: Flow Label 529 + Reference: [this document] 531 + Type Value: 14-254 532 + IPv4 Name: Unassigned 533 + IPv6 Name: Unassigned 534 + Reference: 536 + Type Value: 255 537 + IPv4 Name: Reserved 538 + IPv6 Name: Reserved 539 + Reference: [I-D.ietf-idr-rfc5575bis] 541 8.2. Extended Community Flow Spec IPv6 Actions 543 IANA maintains a registry entitled "Generic Transitive Experimental 544 Use Extended Community Sub-Types". For the purpose of this work, 545 IANA is requested to assign a new value: 547 +----------------+--------------------------------+-----------------+ 548 | Sub-Type Value | Name | Reference | 549 +----------------+--------------------------------+-----------------+ 550 | TBD | Flow spec rt-redirect-ipv6 | [this document] | 551 | | format | | 552 +----------------+--------------------------------+-----------------+ 554 Table 1: Registry: Generic Transitive Experimental Use Extended 555 Community Sub-Types 557 9. Acknowledgements 559 Authors would like to thank Pedro Marques, Hannes Gredler, Bruno 560 Rijsman, Brian Carpenter, and Thomas Mangin for their valuable input. 562 10. Contributors 564 Danny McPherson 565 Verisign, Inc. 567 Email: dmcpherson@verisign.com 569 Burjiz Pithawala 570 Individual 572 Email: burjizp@gmail.com 574 Andy Karch 575 Cisco Systems 576 170 West Tasman Drive 577 San Jose, CA 95134 578 USA 580 Email: akarch@cisco.com 582 11. References 584 11.1. Normative References 586 [I-D.ietf-idr-rfc5575bis] 587 Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 588 Bacher, "Dissemination of Flow Specification Rules", 589 draft-ietf-idr-rfc5575bis-26 (work in progress), August 590 2020. 592 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, 594 DOI 10.17487/RFC2119, March 1997, 595 . 597 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 598 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 599 DOI 10.17487/RFC4271, January 2006, 600 . 602 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 603 Control Message Protocol (ICMPv6) for the Internet 604 Protocol Version 6 (IPv6) Specification", STD 89, 605 RFC 4443, DOI 10.17487/RFC4443, March 2006, 606 . 608 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 609 "Multiprotocol Extensions for BGP-4", RFC 4760, 610 DOI 10.17487/RFC4760, January 2007, 611 . 613 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 614 Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, 615 . 617 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 618 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 619 March 2014, . 621 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 622 Writing an IANA Considerations Section in RFCs", BCP 26, 623 RFC 8126, DOI 10.17487/RFC8126, June 2017, 624 . 626 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 627 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 628 May 2017, . 630 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 631 (IPv6) Specification", STD 86, RFC 8200, 632 DOI 10.17487/RFC8200, July 2017, 633 . 635 11.2. URIs 637 [1] https://github.com/stoffi92/draft-ietf-idr-flow-spec- 638 v6/tree/master/flowspec-cmp 640 Appendix A. Example python code: flow_rule_cmp_v6 642 643 """ 644 Copyright (c) 2020 IETF Trust and the persons identified as authors 645 of draft-ietf-idr-flow-spec-v6. All rights reserved. 647 Redistribution and use in source and binary forms, with or without 648 modification, is permitted pursuant to, and subject to the license 649 terms contained in, the Simplified BSD License set forth in Section 650 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 651 (http://trustee.ietf.org/license-info). 652 """ 654 import itertools 655 import collections 656 import ipaddress 658 EQUAL = 0 659 A_HAS_PRECEDENCE = 1 660 B_HAS_PRECEDENCE = 2 661 IP_DESTINATION = 1 662 IP_SOURCE = 2 664 FS_component = collections.namedtuple('FS_component', 665 'component_type value') 667 class FS_IPv6_prefix_component: 668 def __init__(self, prefix, offset=0, 669 component_type=IP_DESTINATION): 670 self.offset = offset 671 self.component_type = component_type 672 # make sure if offset != 0 that non of the 673 # first offset bits are set in the prefix 674 self.value = prefix 675 if offset != 0: 676 i = ipaddress.IPv6Interface( 677 (self.value.network_address, offset)) 678 if i.network.network_address != \ 679 ipaddress.ip_address('0::0'): 680 raise ValueError('Bits set in the offset') 682 class FS_nlri(object): 683 """ 684 FS_nlri class implementation that allows sorting. 686 By calling .sort() on a array of FS_nlri objects these 687 will be sorted according to the flow_rule_cmp algorithm. 689 Example: 690 nlri = [ FS_nlri(components=[ 691 FS_component(component_type=4, 692 value=bytearray([0,1,2,3,4,5,6])), 693 ]), 694 FS_nlri(components=[ 695 FS_component(component_type=5, 696 value=bytearray([0,1,2,3,4,5,6])), 697 FS_component(component_type=6, 698 value=bytearray([0,1,2,3,4,5,6])), 699 ]), 700 ] 701 nlri.sort() # sorts the array accorinding to the algorithm 702 """ 703 def __init__(self, components = None): 704 """ 705 components: list of type FS_component 706 """ 707 self.components = components 709 def __lt__(self, other): 710 # use the below algorithm for sorting 711 result = flow_rule_cmp_v6(self, other) 712 if result == B_HAS_PRECEDENCE: 713 return True 714 else: 715 return False 717 def flow_rule_cmp_v6(a, b): 718 """ 719 Implementation of the flowspec sorting algorithm in 720 draft-ietf-idr-flow-spec-v6. 721 """ 722 for comp_a, comp_b in itertools.zip_longest(a.components, 723 b.components): 724 # If a component type does not exist in one rule 725 # this rule has lower precedence 726 if not comp_a: 727 return B_HAS_PRECEDENCE 728 if not comp_b: 729 return A_HAS_PRECEDENCE 730 # Higher precedence for lower component type 731 if comp_a.component_type < comp_b.component_type: 732 return A_HAS_PRECEDENCE 733 if comp_a.component_type > comp_b.component_type: 734 return B_HAS_PRECEDENCE 735 # component types are equal -> type specific comparison 736 if comp_a.component_type in (IP_DESTINATION, IP_SOURCE): 737 if comp_a.offset < comp_b.offset: 738 return A_HAS_PRECEDENCE 739 if comp_a.offset < comp_b.offset: 740 return B_HAS_PRECEDENCE 741 # both components have the same offset 742 # assuming comp_a.value, comp_b.value of type 743 # ipaddress.IPv6Network 744 # and the offset bits are reset to 0 (since they are 745 # not represented in the NLRI) 746 if comp_a.value.overlaps(comp_b.value): 747 # longest prefixlen has precedence 748 if comp_a.value.prefixlen > \ 749 comp_b.value.prefixlen: 750 return A_HAS_PRECEDENCE 751 if comp_a.value.prefixlen < \ 752 comp_b.value.prefixlen: 753 return B_HAS_PRECEDENCE 754 # components equal -> continue with next 755 # component 756 elif comp_a.value > comp_b.value: 757 return B_HAS_PRECEDENCE 758 elif comp_a.value < comp_b.value: 759 return A_HAS_PRECEDENCE 760 else: 761 # assuming comp_a.value, comp_b.value of type 762 # bytearray 763 if len(comp_a.value) == len(comp_b.value): 764 if comp_a.value > comp_b.value: 765 return B_HAS_PRECEDENCE 766 if comp_a.value < comp_b.value: 767 return A_HAS_PRECEDENCE 768 # components equal -> continue with next 769 # component 770 else: 771 common = min(len(comp_a.value), 772 len(comp_b.value)) 773 if comp_a.value[:common] > \ 774 comp_b.value[:common]: 775 return B_HAS_PRECEDENCE 776 elif comp_a.value[:common] < \ 777 comp_b.value[:common]: 778 return A_HAS_PRECEDENCE 779 # the first common bytes match 780 elif len(comp_a.value) > len(comp_b.value): 781 return A_HAS_PRECEDENCE 782 else: 783 return B_HAS_PRECEDENCE 784 return EQUAL 785 787 Authors' Addresses 789 Christoph Loibl (editor) 790 next layer Telekom GmbH 791 Mariahilfer Guertel 37/7 792 Vienna 1150 793 AT 795 Phone: +43 664 1176414 796 Email: cl@tix.at 798 Robert Raszuk (editor) 799 Bloomberg LP 800 731 Lexington Ave 801 New York City, NY 10022 802 USA 804 Email: robert@raszuk.net 806 Susan Hares (editor) 807 Huawei 808 7453 Hickory Hill 809 Saline, MI 48176 810 USA 812 Email: shares@ndzh.com