idnits 2.17.1 draft-ietf-idr-flow-spec-v6-06.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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC5575]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 10, 2014) is 3454 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: '137' on line 211 -- Looks like a reference, but probably isn't: '139' on line 211 == Unused Reference: 'I-D.ietf-6man-flow-3697bis' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 351, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 354, but no explicit reference was found in the text == Unused Reference: 'RFC5095' is defined on line 366, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group R. Raszuk 3 Internet-Draft Mirantis Inc. 4 Updates: RFC5575 (if approved) B. Pithawala 5 Intended status: Standards Track Cisco Systems 6 Expires: May 14, 2015 D. McPherson 7 Verisign, Inc. 8 A. Karch 9 Cisco Systems 10 November 10, 2014 12 Dissemination of Flow Specification Rules for IPv6 13 draft-ietf-idr-flow-spec-v6-06 15 Abstract 17 Dissemination of Flow Specification Rules [RFC5575] provides a 18 protocol extension for propagation of traffic flow information for 19 the purpose of rate limiting or filtering. The [RFC5575] specifies 20 those extensions for IPv4 protocol data packets. 22 This specification extends the current [RFC5575] and defines changes 23 to the original document in order to make it also usable and 24 applicable to IPv6 data packets. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 14, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. IPv6 Flow Specification encoding in BGP . . . . . . . . . . . 2 62 3. IPv6 Flow Specification types changes . . . . . . . . . . . . 3 63 3.1. Order of Traffic Filtering Rules . . . . . . . . . . . . 5 64 4. IPv6 Flow Specification Traffic Filtering Action changes . . 6 65 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 The growing amount of IPv6 traffic in private and public networks 76 requires the extension of tools used in the IPv4 only networks to be 77 also capable of supporting IPv6 data packets. 79 In this document authors analyze the differences of IPv6 [RFC2460] 80 flows description from those of traditional IPv4 packets and propose 81 subset of new encoding formats to enable Dissemination of Flow 82 Specification Rules [RFC5575] for IPv6. 84 This specification should be treated as an extension of base 85 [RFC5575] specification and not its replacement. It only defines the 86 delta changes required to support IPv6 while all other definitions 87 and operation mechanisms of Dissemination of Flow Specification Rules 88 will remain in the main specification and will not be repeated here. 90 2. IPv6 Flow Specification encoding in BGP 92 The [RFC5575] defines a new SAFIs (133 for IPv4) and (134 for VPNv4) 93 applications in order to carry corresponding to each such application 94 flow specification. 96 This document will redefine the [RFC5575] SAFIs in order to make them 97 AFI specific and applicable to both IPv4 and IPv6 applications. 99 The following changes are defined: 101 "SAFI 133 for IPv4 dissemination of flow specification rules" to 102 now be defined as "SAFI 133 for dissemination of unicast flow 103 specification rules" 105 "SAFI 134 for VPNv4 dissemination of flow specification rules" to 106 now be defined as "SAFI 134 for dissemination of L3VPN flow 107 specification rules" 109 For both SAFIs the indication to which address family they are 110 referring to will be recognized by AFI value (AFI=1 for IPv4 or 111 VPNv4, AFI=2 for IPv6 and VPNv6 respectively). Such modification is 112 fully backwards compatible with existing implementation and 113 production deployments. 115 It needs to be observed that such choice of proposed encoding is 116 compatible with filter validation against routing reachability 117 information as described in section 6 of RFC5575. Validation tables 118 will now be performed according to the following rules. 120 Flow specification received over AFI/SAFI=1/133 will be validated 121 against routing reachability received over AFI/SAFI=1/1 123 Flow specification received over AFI/SAFI=1/134 will be validated 124 against routing reachability received over AFI/SAFI=1/128 126 Flow specification received over AFI/SAFI=2/133 will be validated 127 against routing reachability received over AFI/SAFI=2/1 129 Flow specification received over AFI/SAFI=2/134 will be validated 130 against routing reachability received over AFI/SAFI=2/128 132 3. IPv6 Flow Specification types changes 134 The following component types are redefined or added for the purpose 135 of accommodating new IPv6 header encoding. Unless otherwise stated 136 all other types as defined in RFC5575 apply to IPv6 packets as is. 138 Type 1 - Destination IPv6 Prefix 140 Encoding: 142 Defines the destination prefix to match. Prefix offset has been 143 defined to allow for flexible matching on part of the IPv6 address 144 where we want to skip (don't care) of N first bits of the address. 145 This can be especially useful where part of the IPv6 address 146 consists of an embedded IPv4 address and matching needs to happen 147 only on the embedded IPv4 address. The encoded prefix contains 148 enough octets for the bits used in matching (length minus offset 149 bits). 151 Type 2 - Source IPv6 Prefix 153 Encoding: 156 Defines the source prefix to match. Prefix offset has been 157 defined to allow for flexible matching on part of the IPv6 address 158 where we want to skip (don't care) of N first bits of the address. 159 This can be especially useful where part of the IPv6 address 160 consists of an embedded IPv4 address and matching needs to happen 161 only on the embedded IPv4 address. The encoded prefix contains 162 enough octets for the bits used in matching (length minus offset 163 bits). 165 Type 3 - Next Header 167 Encoding: 169 Contains a set of {operator, value} pairs that are used to match 170 the last Next Header value octet in IPv6 packets. The operator 171 byte is encoded as specified in component type 3 of [RFC5575]. 173 While IPv6 allows for more then one Next Header field in the 174 packet the main goal of Type 3 flow specification component is to 175 match on the subsequent IP protocol value. Therefor the 176 definition is limited to match only on last Next Header field in 177 the packet. 179 Type 12 - Fragment 181 Encoding: 183 Uses bitmask operand format defined above. Bit-7 is not used and 184 MUST be 0 to provide backwards-compatibility with the definition 185 in RFC5575. 187 0 1 2 3 4 5 6 7 188 +---+---+---+---+---+---+---+---+ 189 | Reserved |LF |FF |IsF| 0 | 190 +---+---+---+---+---+---+---+---+ 192 Bitmask values: 194 + Bit 6 - Is a fragment (IsF) 196 + Bit 5 - First fragment (FF) 198 + Bit 4 - Last fragment (LF) 200 Type 13 - Flow Label - New type 202 Encoding: 204 Contains a set of {operator, value} pairs that are used to match 205 the 20-bit Flow Label field [RFC2460]. The operator byte is 206 encoded as specified in the component type 3 of [RFC5575]. Values 207 are encoded as 1-, 2-, or 4- byte quantities. 209 The following example demonstrates the new prefix encoding for: "all 210 packets to ::1234:5678:9A00:0/64-104 from 192::/8 and port {range 211 [137, 139] or 8080}". In the destination prefix, "80-" represents 212 the prefix offset of 80 bits. In this exmaple, the 0 offset is 213 omitted from the printed source prefix. 215 +---------------------------+-------------+-------------------------+ 216 | destination | source | port | 217 +---------------------------+-------------+-------------------------+ 218 | 0x01 68 50 12 34 56 78 9A | 02 00 08 c0 | 04 03 89 45 8b 91 1f 90 | 219 +---------------------------+-------------+-------------------------+ 221 3.1. Order of Traffic Filtering Rules 223 The orignal definition for the order of traffic filtering rules can 224 be reused with new consideration for the IPv6 prefix offset. As long 225 as the offsets are equal, the comparison is the same, retaining 226 longest-prefix-match semantics. If the offsets are not equal, the 227 lowest offset has precedence, as this flow matches the most 228 significant bit. 230 Pseudocode: 232 flow_rule_v6_cmp (a, b) 233 { 234 comp1 = next_component(a); 235 comp2 = next_component(b); 236 while (comp1 || comp2) { 237 // component_type returns infinity on end-of-list 238 if (component_type(comp1) < component_type(comp2)) { 239 return A_HAS_PRECEDENCE; 240 } 241 if (component_type(comp1) > component_type(comp2)) { 242 return B_HAS_PRECEDENCE; 243 } 245 if (component_type(comp1) == IPV6_DESTINATION || IPV6_SOURCE) { 246 // offset not equal, lowest offset has precedence 247 // offset equal ... 248 common_len = MIN(prefix_length(comp1), prefix_length(comp2)); 249 cmp = prefix_compare(comp1, comp2, offset, common_len); 250 // not equal, lowest value has precedence 251 // equal, longest match has precedence 252 } else { 253 common = 254 MIN(component_length(comp1), component_length(comp2)); 255 cmp = memcmp(data(comp1), data(comp2), common); 256 // not equal, lowest value has precedence 257 // equal, longest string has precedence 258 } 259 } 261 return EQUAL; 262 } 264 4. IPv6 Flow Specification Traffic Filtering Action changes 266 One of the traffic filtering actions which can be expressed by BGP 267 extended community is defined in [RFC5575] as traffic-marking. This 268 extended community type is of value: 0x8009. 270 For the purpose of making it compatible with IPv6 header action 271 expressed by presence of this extended community has been modified to 272 read: 274 Traffic Marking: The traffic marking extended community instructs a 275 system to modify first 6 bits of Traffic Class field as (recommended 276 by [RFC2474]) of a transiting IPv6 packet to the corresponding value. 277 This extended community is encoded as a sequence of 42 zero bits 278 followed by the 6 bits overwriting DSCP portion of Traffic Class 279 value. 281 Another traffic filtering action defined in [RFC5575] as a BGP 282 extended community is redirect. To allow an IPv6 address specific 283 route-target, a new traffic action IPv6 address specific extended 284 community is provided. The extended community type has the value 285 0x800b. 287 Redirect-IPv6: The redirect IPv6 address specific extended community 288 allows the traffic to be redirected to a VRF routing instance that 289 lists the specified IPv6 address specific route-target in its import 290 policy. If several local instances match this criteria, the choice 291 between them is a local matter (for example, the instance with the 292 lowest Route Distinguisher value can be elected). This extended 293 community uses the same encoding as the IPv6 address specific Route 294 Target extended community [RFC5701]. 296 5. Security considerations 298 No new security issues are introduced to the BGP protocol by this 299 specification. 301 6. IANA Considerations 303 IANA is requested to rename currently defined SAFI 133 and SAFI 134 304 per [RFC5575] to read: 306 133 Dissemination of flow specification rules 307 134 L3VPN dissemination of flow specification rules 309 IANA is requested to create and maintain a new registry entitled: 310 "Flow Spec IPv6 Component Types". The following component types have 311 been registered: 313 Type 1 - Destination IPv6 Prefix 314 Type 2 - Source IPv6 Prefix 315 Type 3 - Next Header 316 Type 4 - Port 317 Type 5 - Destination port 318 Type 6 - Source port 319 Type 7 - ICMP type 320 Type 8 - ICMP code 321 Type 9 - TCP flags 322 Type 10 - Packet length 323 Type 11 - DSCP 324 Type 12 - Fragment 325 Type 13 - Flow Label 327 7. Acknowledgments 328 Authors would like to thank Pedro Marques, Hannes Gredler and Bruno 329 Rijsman, Brian Carpenter, and Thomas Mangin for their valuable input. 331 8. References 333 8.1. Normative References 335 [I-D.ietf-6man-flow-3697bis] 336 Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 337 "IPv6 Flow Label Specification", draft-ietf-6man-flow- 338 3697bis-07 (work in progress), July 2011. 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, March 1997. 343 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 344 (IPv6) Specification", RFC 2460, December 1998. 346 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 347 "Definition of the Differentiated Services Field (DS 348 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 349 1998. 351 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 352 Protocol 4 (BGP-4)", RFC 4271, January 2006. 354 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 355 with BGP-4", RFC 5492, February 2009. 357 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 358 and D. McPherson, "Dissemination of Flow Specification 359 Rules", RFC 5575, August 2009. 361 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 362 Attribute", RFC 5701, November 2009. 364 8.2. Informative References 366 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 367 of Type 0 Routing Headers in IPv6", RFC 5095, December 368 2007. 370 Authors' Addresses 371 Robert Raszuk 372 Mirantis Inc. 373 615 National Ave. #100 374 Mt View, CA 94043 375 USA 377 Email: robert@raszuk.net 379 Burjiz Pithawala 380 Cisco Systems 381 170 West Tasman Drive 382 San Jose, CA 95134 383 US 385 Email: bpithaw@cisco.com 387 Danny McPherson 388 Verisign, Inc. 390 Email: dmcpherson@verisign.com 392 Andy Karch 393 Cisco Systems 394 170 West Tasman Drive 395 San Jose, CA 95134 396 US 398 Email: akarch@cisco.com