idnits 2.17.1 draft-dreibholz-ipv4-flowlabel-32.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 09, 2020) is 1287 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Dreibholz 3 Internet-Draft SimulaMet 4 Intended status: Standards Track September 09, 2020 5 Expires: March 13, 2021 7 An IPv4 Flowlabel Option 8 draft-dreibholz-ipv4-flowlabel-32 10 Abstract 12 This draft defines an IPv4 option containing a flowlabel that is 13 compatible to IPv6. It is required for simplified usage of IntServ 14 and interoperability with IPv6. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 13, 2021. 33 Copyright Notice 35 Copyright (c) 2020 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 2 53 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. A Flow Label Option for IPv4 . . . . . . . . . . . . . . . . 3 55 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1.1. The Flow Label Field of IPv6 . . . . . . . . . . . . 3 57 2.1.2. The Limitations of IntServ via IPv4 . . . . . . . . . 4 58 2.2. Definition of the Flow Label Option . . . . . . . . . . . 5 59 3. Translation between IPv6 and IPv4 . . . . . . . . . . . . . . 6 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 7.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 1.1. Terminology 72 This document uses the following terms: 74 o IntServ (Integrated Services): Reservation of network resources 75 (bandwidth) on a per-flow basis. See [RFC1633], [RFC2205], 76 [RFC2208], [RFC2209], [RFC2210], [RFC2211] and [RFC2212] for 77 details. 79 o Flow: An IntServ reservation between two endpoints. 81 o Flow Label: The Flow Label field of the IPv6 header and the IPv4 82 option header defined in this draft. It is used for marking a 83 packet to use a specific IntServ reservation. See [RFC6437], 84 [RFC6436] for detailed descriptions. 86 1.2. Abbreviations 88 o RSVP: ReSource Reservation Protocol 90 o SCTP: Stream Control Transmission Protocol 92 o TCP: Transmission Control Protocol 94 o QoS: Quality of Service 95 o UDP: User Datagram Protocol 97 1.3. Conventions 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 2. A Flow Label Option for IPv4 107 2.1. Motivation 109 This section describes the motivation to add a flow label option to 110 the IPv4 protocol. 112 2.1.1. The Flow Label Field of IPv6 114 The Flow Label field (see [RFC6436] and [RFC6437]) of the IPv6 header 115 (see [RFC2460]) is a 20-bit number. All packets from the same source 116 address having the same flow label MUST contain the same destination 117 address. Therefore, the flow label combined with the source address 118 is a network- unique identification for a specific packet flow. The 119 idea behind the flow label is marking specific flows for IntServ. 120 That is, the routers on the path from source to destination keep e.g. 121 reservation states for the flows. The flow label provides easy 122 identification and utilizes efficient lookup, e.g. using a hash 123 function on the 3-tuple (source address, destination address, flow 124 label). 126 Using the IPv6 flow label, packets can be mapped easily to specific 127 flows, with the following features: 129 o Transport Layer Protocol Independence: Since the mapping is 130 directly specified in the IP header, all possible layer 4 131 protocols are supported, even protocols to be specified in a far 132 future. 134 o Support for Network Layer Encryption: The mapping is independent 135 of payload encryption (e.g. by IPsec). 137 o Support for Fragmentation: If fragmentation of a large IP packet 138 is necessary, all fragments contain the same flow label. 139 Therefore, fragmentation does not cause any flow-marking problem. 141 o Flow Sharing: By marking packets with a flow label, it is possible 142 to share a single flow (IntServ reservation) with several 143 communication associations from host A to host B. For example, a 144 video stream via UDP and a HTTP download via TCP could share a 145 single reservation. For the user, flow sharing has the advantage 146 that if one of its communication associations temporarily requires 147 lower bandwidth than expected, other associations sharing the same 148 flow may use the remaining bandwidth. That is, his possibly 149 expensive reservation is fully utilized. Flow sharing also helps 150 keeping the total number of reservations a router has to handle 151 small, reducing their CPU and memory requirements and therefore 152 cost. 154 o Multi-Flow Connections: One communication association can divide 155 up its packets to several flows, simply by marking packets with 156 different flow labels. This technique can be used for layered 157 transmission. That is, a stream (e.g. a video) is divided up into 158 several parts (called layers). For example, the first layer (base 159 layer) of a video contains a low-quality version, the second (1st 160 enhancement layer) the data to generate a higher-quality version, 161 etc.. Now, the first layer can be mapped to a high-quality 162 reservation (guaranteed bandwidth, low loss rate) at higher cost, 163 but the following layers can be mapped to lower-quality 164 reservations (e.g. higher loss rate) or even best effort at lower 165 cost. Research shows that the total transmission cost can be 166 highly reduced using layered transmission (see [Dre2001], 167 [IJMUE2009] for details). 169 2.1.2. The Limitations of IntServ via IPv4 171 Using IntServ with IPv4, there are several problems that can only be 172 solved with high management effort: 174 o No Transport Layer Protocol Independence: It is necessary to mark 175 the packets within the layer 4 protocol header. For example, the 176 TCP, UDP or SCTP port numbers can be used to mark flows (with 177 limitations, see below). But for new protocols (e.g. 178 experimental, new standards, proprietary), software updates for 179 *all* IntServ routers are necessary to recognize the packet flow! 181 o No Support for Network Layer Encryption: Since it is necessary to 182 read fields of the layer 4 protocol header, it may not be 183 encrypted. Therefore, e.g. the usage of IPsec is impossible. 185 o Support for Fragmentation: Only the first fragment of a large 186 packet contains the layer 4 header necessary to map the packet to 187 a flow. Mapping other fragments would require the hops to 188 remember packet identities and try to map fragments to packet 189 identities. Due to the management effort and memory requirements, 190 this is not realistic for high-bandwidth backbone routers; 191 especially when packet reordering must be considered. 192 Furthermore, load sharing or traffic distribution would be 193 impossible. 195 o No Flow Sharing: It is usually impossible for two different 196 communication associations to share the same flow, e.g. if TCP 197 flows are recognized using port numbers. This makes it necessary 198 to reserve an IntServ flow for each communication association. 199 This implies an increased number of flow states for routers to 200 keep and maintain. Furthermore, if one association temporarily 201 uses a lower bandwidth, the free bandwidth of its flow cannot 202 easily be borrowed to another association. 204 o No Multi-Flow Connections: To use layered transmission, e.g. a 205 video via UDP, the transmission of every layer would require own 206 port numbers. In the case of connection-oriented transmission 207 protocols (e.g. TCP, SCTP), every layer would even require its 208 own connection setup and management. Depending on the transport 209 protocol, the number of communication associations and the number 210 of flows, much more work is necessary compared to IPv6 using flow 211 labels. 213 All in all, using IntServ flows with IPv4 requires much more work 214 compared to IPv6, where simply the flow label can be used. It is 215 therefore useful to add such a field to IPv4, too. An appropriate 216 place to add such a field is an IPv4 option header. 218 2.2. Definition of the Flow Label Option 220 IPv4 (see [RFC0791]) already defines an option header for a 16-bit 221 SATNET stream identifier. Since this identifier would be 222 incompatible to the 20-bit IPv6 flow label, reuse of this existing 223 option header is inappropriate. Therefore, a new one is defined as 224 follows. 226 Flow Label Option 228 0 1 2 3 229 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type | Length |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |0 0 0 0 0 0 0 0|0 0 0 0| Flow Label | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 o Type: 143 238 o Length: 8 octets 239 o Flow Label: The 20-bit flow label. All definitions of [RFC6437] 240 and [RFC6436] for the IPv6 flow label are also valid for this 241 field. A value of zero denotes that no flow label is used. In 242 this case, the flow label option is in fact unnecessary. 244 The Flow Label option SHOULD be copied on fragmentation. It MUST be 245 the first option of the IP header and therefore MUST NOT appear more 246 than once per IPv4 packet. The Router Alert option SHOULD NOT be 247 used to mark the necessity for routers to examine the options. 248 Placing the Flow Label option as first option allows for easy 249 processing in hardware. 251 3. Translation between IPv6 and IPv4 253 Since the new IPv4 flow label is fully compatible to the IPv6 flow 254 label, the field MAY be translated in the other protocol's one during 255 protocol translation. That is, a router can translate an IPv6 packet 256 set from an IPv6-only host to an IPv4-mapped address of an IPv4-only 257 host and the flow label may simply be copied. The same may also be 258 applied in the backwards direction. 260 Note, that copying the flow label during protocol translation is not 261 mandatory. There may be IntServ reservation reasons for not copying 262 but setting the flow label to zero. But a router MUST NOT set the 263 flow label to another value than the copy or 0, since the source is 264 responsible to ensure that the source address combined with the flow 265 label is network-unique. 267 4. Security Considerations 269 Security considerations are similar to the IPv6 flow label, see 270 [RFC6437]. 272 5. IANA Considerations 274 This document introduces no additional considerations for IANA. 276 6. Acknowledgments 278 The author would like to thank Brian E. Carpenter, Wes George, Perry 279 Lorier, Christoph Reichert and Michael Tuexen for their comments. 281 7. References 282 7.1. Normative References 284 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 285 DOI 10.17487/RFC0791, September 1981, 286 . 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, 290 DOI 10.17487/RFC2119, March 1997, 291 . 293 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 294 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 295 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 296 September 1997, . 298 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 299 Services", RFC 2210, DOI 10.17487/RFC2210, September 1997, 300 . 302 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 303 Network Element Service", RFC 2211, DOI 10.17487/RFC2211, 304 September 1997, . 306 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 307 of Guaranteed Quality of Service", RFC 2212, 308 DOI 10.17487/RFC2212, September 1997, 309 . 311 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 312 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 313 December 1998, . 315 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 316 "IPv6 Flow Label Specification", RFC 6437, 317 DOI 10.17487/RFC6437, November 2011, 318 . 320 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 321 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 322 May 2017, . 324 7.2. Informative References 326 [Dre2001] Dreibholz, T., "Management of Layered Variable Bitrate 327 Multimedia Streams over DiffServ with Apriori 328 Knowledge", Masters Thesis, February 2001, 329 . 333 [IJMUE2009] 334 Zhu, W., Dreibholz, T., Rathgeb, E., and X. Zhou, "A 335 Scalable QoS Device for Broadband Access to Multimedia 336 Services", SERSC International Journal of Multimedia and 337 Ubiquitous Engineering (IJMUE) Number 2, Volume 4, Pages 338 157-172, ISSN 1975-0080, May 2009, 339 . 342 [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated 343 Services in the Internet Architecture: an Overview", 344 RFC 1633, DOI 10.17487/RFC1633, June 1994, 345 . 347 [RFC2208] Mankin, A., Ed., Baker, F., Braden, B., Bradner, S., 348 O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang, 349 "Resource ReSerVation Protocol (RSVP) -- Version 1 350 Applicability Statement Some Guidelines on Deployment", 351 RFC 2208, DOI 10.17487/RFC2208, September 1997, 352 . 354 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol 355 (RSVP) -- Version 1 Message Processing Rules", RFC 2209, 356 DOI 10.17487/RFC2209, September 1997, 357 . 359 [RFC6436] Amante, S., Carpenter, B., and S. Jiang, "Rationale for 360 Update to the IPv6 Flow Label Specification", RFC 6436, 361 DOI 10.17487/RFC6436, November 2011, 362 . 364 Author's Address 365 Thomas Dreibholz 366 Simula Metropolitan Centre for Digital Engineering 367 Pilestredet 52 368 0167 Oslo, Oslo 369 Norway 371 Phone: +47-6782-8200 372 Fax: +47-6782-8201 373 Email: dreibh@simula.no 374 URI: https://www.simula.no/people/dreibh