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