idnits 2.17.1 draft-ietf-idr-flow-spec-v6-04.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 (January 28, 2014) is 3739 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 219 -- Looks like a reference, but probably isn't: '139' on line 219 == Unused Reference: 'I-D.ietf-6man-flow-3697bis' is defined on line 343, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 348, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC5095' is defined on line 374, 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, Ed. 3 Internet-Draft NTT MCL Inc. 4 Updates: RFC5575 (if approved) B. Pithawala 5 Intended status: Standards Track Cisco Systems 6 Expires: August 1, 2014 D. McPherson 7 Verisign, Inc. 8 A. Karch 9 Cisco Systems 10 January 28, 2014 12 Dissemination of Flow Specification Rules for IPv6 13 draft-ietf-idr-flow-spec-v6-04 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 August 1, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . 8 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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]. 208 Type 14 - Traffic Class - New type 210 Encoding: 212 Contains a set of {operator, value} pairs that are used to match 213 the full Traffic Class 8-bit field [RFC2460] encoded in a single 214 octet. The operator byte is encoded as specified in component 215 type 3 of [RFC5575]. 217 The following example demonstrates the new prefix encoding for: "all 218 packets to ::1234:5678:9A00:0/80-104 from 192::/8 and port {range 219 [137, 139] or 8080}". 221 +---------------------------+-------------+-------------------------+ 222 | destination | source | port | 223 +---------------------------+-------------+-------------------------+ 224 | 0x01 40 68 12 34 56 78 9A | 02 00 08 c0 | 04 03 89 45 8b 91 1f 90 | 225 +---------------------------+-------------+-------------------------+ 227 3.1. Order of Traffic Filtering Rules 229 The orignal definition for the order of traffic filtering rules can 230 be reused with new consideration for the IPv6 prefix offset. As long 231 as the offsets are equal, the comparison is the same, retaining 232 longest-prefix-match semantics. If the offsets are not equal, the 233 lowest offset has precedence, as this flow matches the most 234 significant bit. 236 Pseudocode: 238 flow_rule_v6_cmp (a, b) 239 { 240 comp1 = next_component(a); 241 comp2 = next_component(b); 242 while (comp1 || comp2) { 243 // component_type returns infinity on end-of-list 244 if (component_type(comp1) < component_type(comp2)) { 245 return A_HAS_PRECEDENCE; 246 } 247 if (component_type(comp1) > component_type(comp2)) { 248 return B_HAS_PRECEDENCE; 249 } 251 if (component_type(comp1) == IPV6_DESTINATION || IPV6_SOURCE) { 252 // offset not equal, lowest offset has precedence 253 // offset equal ... 254 common_len = MIN(prefix_length(comp1), prefix_length(comp2)); 255 cmp = prefix_compare(comp1, comp2, offset, common_len); 256 // not equal, lowest value has precedence 257 // equal, longest match has precedence 258 } else { 259 common = 260 MIN(component_length(comp1), component_length(comp2)); 261 cmp = memcmp(data(comp1), data(comp2), common); 262 // not equal, lowest value has precedence 263 // equal, longest string has precedence 264 } 265 } 267 return EQUAL; 268 } 270 4. IPv6 Flow Specification Traffic Filtering Action changes 272 One of the traffic filtering actions which can be expressed by BGP 273 extended community is defined in [RFC5575] as traffic-marking. This 274 extended community type is of value: 0x8009. 276 For the purpose of making it compatible with IPv6 header action 277 expressed by presence of this extended community has been modified to 278 read: 280 Traffic Marking: The traffic marking extended community instructs a 281 system to modify first 6 bits of Traffic Class field as (recommended 282 by [RFC2474]) of a transiting IPv6 packet to the corresponding value. 283 This extended community is encoded as a sequence of 42 zero bits 284 followed by the 6 bits overwriting DSCP portion of Traffic Class 285 value. 287 Another traffic filtering action defined in [RFC5575] as a BGP 288 extended community is redirect. To allow an IPv6 address specific 289 route-target, a new traffic action IPv6 address specific extended 290 community is provided. The extended community type has the value 291 0x800b. 293 Redirect-IPv6: The redirect IPv6 address specific extended community 294 allows the traffic to be redirected to a VRF routing instance that 295 lists the specified IPv6 address specific route-target in its import 296 policy. If several local instances match this criteria, the choice 297 between them is a local matter (for example, the instance with the 298 lowest Route Distinguisher value can be elected). This extended 299 community uses the same encoding as the IPv6 address specific Route 300 Target extended community [RFC5701]. 302 5. Security considerations 304 No new security issues are introduced to the BGP protocol by this 305 specification. 307 6. IANA Considerations 309 IANA is requested to rename currently defined SAFI 133 and SAFI 134 310 per [RFC5575] to read: 312 133 Dissemination of flow specification rules 313 134 L3VPN dissemination of flow specification rules 315 IANA is requested to create and maintain a new registry entitled: 316 "Flow Spec IPv6 Component Types". The following component types have 317 been registered: 319 Type 1 - Destination IPv6 Prefix 320 Type 2 - Source IPv6 Prefix 321 Type 3 - Next Header 322 Type 4 - Port 323 Type 5 - Destination port 324 Type 6 - Source port 325 Type 7 - ICMP type 326 Type 8 - ICMP code 327 Type 9 - TCP flags 328 Type 10 - Packet length 329 Type 11 - DSCP 330 Type 12 - Fragment 331 Type 13 - Flow Label 332 Type 14 - Traffic Class 334 7. Acknowledgments 336 Authors would like to thank Pedro Marques, Hannes Gredler and Bruno 337 Rijsman, Brian Carpenter, and Thomas Mangin for their valuable input. 339 8. References 341 8.1. Normative References 343 [I-D.ietf-6man-flow-3697bis] 344 Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 345 "IPv6 Flow Label Specification", draft-ietf-6man-flow- 346 3697bis-07 (work in progress), July 2011. 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 352 (IPv6) Specification", RFC 2460, December 1998. 354 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 355 "Definition of the Differentiated Services Field (DS 356 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 357 1998. 359 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 360 Protocol 4 (BGP-4)", RFC 4271, January 2006. 362 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 363 with BGP-4", RFC 5492, February 2009. 365 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 366 and D. McPherson, "Dissemination of Flow Specification 367 Rules", RFC 5575, August 2009. 369 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 370 Attribute", RFC 5701, November 2009. 372 8.2. Informative References 374 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 375 of Type 0 Routing Headers in IPv6", RFC 5095, December 376 2007. 378 Authors' Addresses 380 Robert Raszuk (editor) 381 NTT MCL Inc. 382 101 S Ellsworth Avenue Suite 350 383 San Mateo, CA 94401 384 US 386 Email: robert@raszuk.net 388 Burjiz Pithawala 389 Cisco Systems 390 170 West Tasman Drive 391 San Jose, CA 95134 392 US 394 Email: bpithaw@cisco.com 396 Danny McPherson 397 Verisign, Inc. 399 Email: dmcpherson@verisign.com 401 Andy Karch 402 Cisco Systems 403 170 West Tasman Drive 404 San Jose, CA 95134 405 US 407 Email: akarch@cisco.com