idnits 2.17.1 draft-ietf-idr-flow-spec-v6-03.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 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 date (April 29, 2012) is 4379 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) == Unused Reference: 'I-D.ietf-6man-flow-3697bis' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 266, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 277, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 280, but no explicit reference was found in the text == Unused Reference: 'RFC5095' is defined on line 289, 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: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: October 31, 2012 D. McPherson 7 Verisign, Inc. 8 April 29, 2012 10 Dissemination of Flow Specification Rules for IPv6 11 draft-ietf-idr-flow-spec-v6-03 13 Abstract 15 Dissemination of Flow Specification Rules [RFC5575] provides a 16 protocol extension for propagation of traffic flow information for 17 the purpose of rate limiting or filtering. The [RFC5575] specifies 18 those extensions for IPv4 protocol data packets. 20 This specification extends the current [RFC5575] and defines changes 21 to the original document in order to make it also usable and 22 applicable to IPv6 data packets. 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 http://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 October 31, 2012. 41 Copyright Notice 43 Copyright (c) 2012 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. IPv6 Flow Specification encoding in BGP . . . . . . . . . . . . 3 60 3. IPv6 Flow Specification types changes . . . . . . . . . . . . . 4 61 4. IPv6 Flow Specification Traffic Filtering Action changes . . . 5 62 5. Security considerations . . . . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 The growing amount of IPv6 traffic in private and public networks 73 requires the extension of tools used in the IPv4 only networks to be 74 also capable of supporting IPv6 data packets. 76 In this document authors analyze the differences of IPv6 [RFC2460] 77 flows description from those of traditional IPv4 packets and propose 78 subset of new encoding formats to enable Dissemination of Flow 79 Specification Rules [RFC5575] for IPv6. 81 This specification should be treated as an extension of base 82 [RFC5575] specification and not its replacement. It only defines the 83 delta changes required to support IPv6 while all other definitions 84 and operation mechanisms of Dissemination of Flow Specification Rules 85 will remain in the main specification and will not be repeated here. 87 2. IPv6 Flow Specification encoding in BGP 89 The [RFC5575] defines a new SAFIs (133 for IPv4) and (134 for VPNv4) 90 applications in order to carry corresponding to each such application 91 flow specification. 93 This document will redefine the [RFC5575] SAFIs in order to make them 94 AFI specific and applicable to both IPv4 and IPv6 applications. 96 The following changes are defined: 98 "SAFI 133 for IPv4 dissemination of flow specification rules" to 99 now be defined as "SAFI 133 for dissemination of unicast flow 100 specification rules" 102 "SAFI 134 for VPNv4 dissemination of flow specification rules" to 103 now be defined as "SAFI 134 for dissemination of L3VPN flow 104 specification rules" 106 For both SAFIs the indication to which address family they are 107 referring to will be recognized by AFI value (AFI=1 for IPv4 or 108 VPNv4, AFI=2 for IPv6 and VPNv6 respectively). Such modification is 109 fully backwards compatible with existing implementation and 110 production deployments. 112 It needs to be observed that such choice of proposed encoding is 113 compatible with filter validation against routing reachability 114 information as described in section 6 of RFC5575. Validation tables 115 will now be performed according to the following rules. 117 Flow specification received over AFI/SAFI=1/133 will be validated 118 against routing reachability received over AFI/SAFI=1/1 120 Flow specification received over AFI/SAFI=1/134 will be validated 121 against routing reachability received over AFI/SAFI=1/128 123 Flow specification received over AFI/SAFI=2/133 will be validated 124 against routing reachability received over AFI/SAFI=2/1 126 Flow specification received over AFI/SAFI=2/134 will be validated 127 against routing reachability received over AFI/SAFI=2/128 129 3. IPv6 Flow Specification types changes 131 The following component types are redefined or added for the purpose 132 of accommodating new IPv6 header encoding. Unless otherwise stated 133 all other types as defined in RFC5575 apply to IPv6 packets as is. 135 Type 1 - Destination IPv6 Prefix 137 Encoding: 140 Defines the destination prefix to match. Prefix offset has been 141 defined to allow for flexible match on the part of the IPv6 142 address where we want to skip (don't care) of N first bits of the 143 address. This can be especially useful where part of the IPv6 144 address consists of embedded IPv4 address and match needs to 145 happen only on the part of embedded IPv4 address. The default 146 value for prefix offset is 0x00 (match on all bits as indicated by 147 prefix length). Otherwise prefixes are encoded as in BGP UPDATE 148 messages, a length in bits is followed by enough octets to contain 149 the prefix information. 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 match on the part of the IPv6 158 address where we want to skip (don't care) of N first bits of the 159 address. This can be especially useful where part of the IPv6 160 address consists of embedded IPv4 address and match needs to 161 happen only on the part of embedded IPv4 address. The default 162 value for prefix offset is 0x00 (match on all bits as indicated by 163 prefix length). Otherwise prefixes are encoded as in BGP UPDATE 164 messages, a length in bits is followed by enough octets to contain 165 the prefix information. 167 Type 3 - Next Header 169 Encoding: 171 Contains a set of {operator, value} pairs that are used to match 172 the last Next Header value octet in IPv6 packets. The operator 173 byte is encoded as specified in component type 3 of [RFC5575]. 175 While IPv6 allows for more then one Next Header field in the 176 packet the main goal of Type 3 flow specification component is to 177 match on the subsequent IP protocol value. Therefor the 178 definition is limited to match only on last Next Header field in 179 the packet. 181 Type 11 - Traffic Class 183 Encoding: 185 Contains a set of {operator, value} pairs that are used to match 186 the Traffic Class 8-bit field [RFC2460] encoded in a single 187 octet.The operator byte is encoded as specified in component type 188 3 of [RFC5575]. 190 Type 12 - Fragment - Not supported for AFI=2 192 This type is not supported for AFI=2 as in IPv6 fragmentation does 193 not happen in the network. 195 Type 13 - Flow Label - New type 197 Encoding: 199 Contains a set of {operator, value} pairs that are used to match 200 the 20-bit Flow Label field [RFC2460].The operator byte is encoded 201 as specified in the component type 3 of [RFC5575]. 203 4. IPv6 Flow Specification Traffic Filtering Action changes 205 One of the traffic filtering actions which can be expressed by BGP 206 extended community is defined in [RFC5575] as traffic-marking. This 207 extended community type is of value: 0x8009. 209 For the purpose of making it compatible with IPv6 header action 210 expressed by presence of this extended community has been modified to 211 read: 213 Traffic Marking: The traffic marking extended community instructs a 214 system to modify first 6 bits of Traffic Class field as (recommended 215 by [RFC2474]) of a transiting IPv6 packet to the corresponding value. 216 This extended community is encoded as a sequence of 42 zero bits 217 followed by the 6 bits overwriting DSCP portion of Traffic Class 218 value. 220 5. Security considerations 222 No new security issues are introduced to the BGP protocol by this 223 specification. 225 6. IANA Considerations 227 IANA is requested to rename currently defined SAFI 133 and SAFI 134 228 per [RFC5575] to read: 230 133 Dissemination of flow specification rules 231 134 L3VPN dissemination of flow specification rules 233 IANA is requested to create and maintain a new registry entitled: 234 "Flow Spec IPv6 Component Types". The following component types have 235 been registered: 237 Type 1 - Destination IPv6 Prefix 238 Type 2 - Source IPv6 Prefix 239 Type 3 - Next Header 240 Type 4 - Port 241 Type 5 - Destination port 242 Type 6 - Source port 243 Type 7 - ICMP type 244 Type 8 - ICMP code 245 Type 9 - TCP flags 246 Type 10 - Packet length 247 Type 11 - Traffic Class 248 Type 12 - Reserved 249 Type 13 - Flow Label 251 7. Acknowledgments 253 Authors would like to thank Pedro Marques, Hannes Gredler and Bruno 254 Rijsman and Brian Carpenter for their valuable input. 256 8. References 258 8.1. Normative References 260 [I-D.ietf-6man-flow-3697bis] 261 Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 262 "IPv6 Flow Label Specification", 263 draft-ietf-6man-flow-3697bis-07 (work in progress), 264 July 2011. 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 270 (IPv6) Specification", RFC 2460, December 1998. 272 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 273 "Definition of the Differentiated Services Field (DS 274 Field) in the IPv4 and IPv6 Headers", RFC 2474, 275 December 1998. 277 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 278 Protocol 4 (BGP-4)", RFC 4271, January 2006. 280 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 281 with BGP-4", RFC 5492, February 2009. 283 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 284 and D. McPherson, "Dissemination of Flow Specification 285 Rules", RFC 5575, August 2009. 287 8.2. Informative References 289 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 290 of Type 0 Routing Headers in IPv6", RFC 5095, 291 December 2007. 293 Authors' Addresses 295 Robert Raszuk (editor) 296 NTT MCL Inc. 297 101 S Ellsworth Avenue Suite 350 298 San Mateo, CA 94401 299 US 301 Email: robert@raszuk.net 303 Burjiz Pithawala 304 Cisco Systems 305 170 West Tasman Drive 306 San Jose, CA 95134 307 US 309 Email: bpithaw@cisco.com 311 Danny McPherson 312 Verisign, Inc. 314 Email: dmcpherson@verisign.com