idnits 2.17.1 draft-herbert-ipv4-eh-01.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 220: '...s, an IPv4 packet MAY carry zero, one,...' RFC 2119 keyword, line 265: '...information that MAY be examined and p...' RFC 2119 keyword, line 275: '...specific to IPv6 MUST NOT be used with...' RFC 2119 keyword, line 295: '... header checksum MUST be set correctly...' RFC 2119 keyword, line 297: '...fragment packets MAY contain different...' (24 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 2, 2019) is 1820 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) == Missing Reference: 'RFC791' is mentioned on line 104, but not defined == Missing Reference: 'SRHV6' is mentioned on line 131, but not defined == Missing Reference: 'ICMP6LIM' is mentioned on line 497, but not defined == Missing Reference: 'EHUDPENCAP' is mentioned on line 588, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 636, but not defined == Unused Reference: 'RFC7605' is defined on line 713, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 == Outdated reference: A later version (-31) exists of draft-bonica-6man-comp-rtg-hdr-03 == Outdated reference: A later version (-02) exists of draft-hinden-6man-mtu-option-00 == Outdated reference: A later version (-07) exists of draft-herbert-fast-03 == Outdated reference: A later version (-05) exists of draft-brockners-ippm-ioam-geneve-01 == Outdated reference: A later version (-08) exists of draft-ietf-6man-icmp-limits-01 == Outdated reference: A later version (-13) exists of draft-carpenter-limited-domains-06 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Proposed Standard Quantonium 4 Expires: November 2019 6 May 2, 2019 8 IPv4 Extension Headers and Flow Label 9 draft-herbert-ipv4-eh-01 11 Abstract 13 This specification defines extension headers for IPv4 and a 14 definition of an IPv4 flow label. The goal is to provide a uniform 15 and feasible method of extensibility that is shared between IPv4 and 16 IPv6. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2 IPv4 extension headers . . . . . . . . . . . . . . . . . . . 4 59 1.3 The IPv4 flow label . . . . . . . . . . . . . . . . . . . . 5 60 2 IPv4 extension headers . . . . . . . . . . . . . . . . . . . . 5 61 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1.1 General requirements . . . . . . . . . . . . . . . . . . 6 63 2.1.2 Fragmentation and reassembly requirements . . . . . . . 7 64 2.2 Interaction with standard IPv4 mechanisms . . . . . . . . . 7 65 2.2.1 IPv4 options and IPv4 extension headers . . . . . . . . 8 66 2.2.2 IPv4 fragmentation and IPv4 extension headers . . . . . 8 67 2.2.3 Atomic datagram recommendation . . . . . . . . . . . . . 8 68 2.3 ICMP errors . . . . . . . . . . . . . . . . . . . . . . . . 9 69 2.3.1 Parameter Problem codes . . . . . . . . . . . . . . . . 9 70 2.3.2 Destination Unreachable codes . . . . . . . . . . . . . 10 71 2.4 Processing limits . . . . . . . . . . . . . . . . . . . . . 11 72 2.5 No Next Header . . . . . . . . . . . . . . . . . . . . . . . 12 73 3 The IPv4 flow label . . . . . . . . . . . . . . . . . . . . . . 12 74 3.1 Sender requirements . . . . . . . . . . . . . . . . . . . . 12 75 3.2 Receiver requirements . . . . . . . . . . . . . . . . . . . 13 76 4 Deployability . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 78 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 79 6.1 Protocol descriptions . . . . . . . . . . . . . . . . . . . 14 80 6.2 Parameter Problem codes . . . . . . . . . . . . . . . . . . 15 81 6.2 Destination Unreachable codes . . . . . . . . . . . . . . . 15 82 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 7.1 Normative References . . . . . . . . . . . . . . . . . . . 16 84 7.2 Informative References . . . . . . . . . . . . . . . . . . 16 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 1 Introduction 89 This specification defines extension headers for IPv4 as well as an 90 IPv4 flow label. The motivation is to provide an extensible mechanism 91 in IPv4 that is unified with IPv6 and thus leverages common protocol 92 and implementation for extensibility between the two versions of the 93 Internet Protocol. 95 The extension headers defined for IPv6 in [RFC8200], specifically 96 Hop-by-Hop Options, Destination Options, Routing Header, and Fragment 97 Header, are permitted for use with IPv4 (note that Authentication 98 Header and Encapsulating Security Payload are already usable with 99 IPv4). Additionally, No Next Header (protocol number 59) is defined 100 to be usable in IPv4 packets. 102 The IPv4 flow label is similarly derived from the definition of the 103 IPv6 flow label. There is no flow label defined in the IPv4 header 104 [RFC791], however under specific circumstances the sixteen bit 105 Identification field may safely be used as a flow label. 107 1.1 Motivation 109 IPv6 is intended to become the standard protocol of the Internet, 110 however it is clear that there is a large segment of users that will 111 be using IPv4 for the foreseeable future. This is particularly true 112 in many enterprises where a business case for transitioning to IPv6 113 hasn't yet emerged [V6STATE]. 115 In lieu of sun-setting IPv4 and expecting all users to move to IPv6 116 in some time frame that is unlikely to be met, this specification 117 suggests an alternative which is to improve IPv4. However the nature 118 of these improvements is very specific, the idea is to "backport" 119 useful features of IPv6 into IPv4. Essentially, this makes IPv4 look 120 more like IPv6. The rationale for this is two fold: 122 1) Users benefit from forward looking features being actively 123 defined and developed for IPv6 without requiring them to 124 transition to IPv6. 126 2) In making IPv4 look more like IPv6, the work required to 127 complete a future transition to IPv6 may be reduced or 128 simplified. 130 Various proposals that would use IPv6 extensions are currently being 131 discussed in IETF. These include Segment Routing [SRHV6], Compressed 132 Routing Header [CRH], Path MTU Option [MTUOPT], In-situ OAM [IOAM], 133 Service-aware IPv6 Network [SAIN], and Firewall and Service Tickets 134 [FAST]. These proposals leverage the extensibility mechanism of 135 extension headers defined for IPv6. All of these proposals, in some 136 form, could be of value for use with IPv4. Unfortunately, IPv4 does 137 not have an extensibility mechanism that meets the requirements for 138 supporting them. IP options are quite limited and have long been 139 considered obsolete. There have been proposals for encoding host to 140 network signaling in UDP (e.g. [SPUD], IOAM over encapsulation like 141 Geneve [IOAMGEN]), however these are shown to neither be generic nor 142 robust especially in the case that encapsulated data must be modified 143 in flight. 145 The proposal contained in this document is to enable IPv4 packets to 146 carry the extension headers in the same manner that IPv6 packets can 147 carry extension headers. In doing so, the various extensions for IPv6 148 can be used with IPv4 to the benefit of the user. In many cases (such 149 as IOAM and Path MTU option), the extension being defined is protocol 150 agnostic and would be applicable and usable with IPv4 with little or 151 no change. In other cases, such as segment routing, the extension 152 might be IPv6 specific, for example the segment routing header 153 contains a list of IPv6 addresses. With some modification to the 154 extension definition, it is also conceivable that these may work with 155 IPv4. For instance, in the case of segment routing, the extension can 156 be adapted for use with IPv4 by defining a routing header format that 157 contains IPv4 addresses instead of IPv6 addresses. 159 1.2 IPv4 extension headers 161 IPv4 options were defined in [RFC0791] as the means of extending the 162 IP protocol. IPv4 options have not been successful. Early router 163 implementations, and even those today, either don't process IPv4 164 options or relegate them to a slow path effectively making them 165 unusable for serious applications. IPv4 options are limited to forty 166 bytes length and, unlike TCP options, no IP options have been defined 167 that are critical to communications. The upshot is that IPv4 options 168 have long not been considered an option for deployment [IPNOOP]. 170 IPv6 took a different approach. Extensibility of IPv6 is provided by 171 extension headers. Optional internet-layer information is encoded in 172 separate headers that may be placed between the IPv6 header and the 173 upper-layer header in a packet [RFC8200]. IPv6 extension headers have 174 had mixed success in deployment in that some intermediate devices 175 have trouble processing them [RFC7872], however there are several 176 active proposals in IETF that would make use of them (e.g. [FAST], 177 [MTUOPT], [IOAM], [SRV6EH]). 179 Using extension headers with IPv4 is logically straightforward. The 180 IPv4 Protocol field is effectively re-designated to be a Next Header 181 field with the same meaning and semantics as the IPv6 Next Header 182 field. In this manner, an IPv4 packet can contain IPv6 extension 183 headers that are recast as IPv4 extension headers. These include Hop- 184 by-Hop Options, Routing Header, Fragment, Destination Options, 185 Authentication, and Encapsulating Security Payload. In cases where an 186 extension header contains IPv6 specific information, the extension 187 header can be adapted for use with IPv4. For instance, a Routing 188 Header carrying IPv6 addresses to visit could be adapted to carry 189 IPv4 addresses. 191 A number of ICMP errors may be sent when an error condition is 192 encountered in processing extension headers. The relevant ICMPv6 193 errors are defined in [RFC4443] and [ICMPLIM]. This specification 194 adapts these ICMPv6 errors for use in IPv4. 196 1.3 The IPv4 flow label 198 IPv6 [RFC8200] introduced the concept of a flow label that has proven 199 quite convenient to perform flow classification, such as that needed 200 by Equal-Cost Multipath (ECMP). The base IPv4 header does not have 201 reserved bits that could be allocated as a flow label, however the 202 sixteen bit Identification field can be used as a flow label in 203 atomic datagrams [RFC6864]. 205 2 IPv4 extension headers 207 IPv4 extension headers are optional internet-layer information 208 encoded in separate headers that may be placed between the IPv4 209 header and the upper-layer header in a packet. IPv4 extension headers 210 are based on IPv6 extension headers and share the same basic 211 properties and semantics [RFC8200]. 213 Extension headers are numbered from IANA IP Protocol Numbers [IANA- 214 PN], the same values are used for IPv4 and IPv6. When processing a 215 sequence of Next Header values in a packet, the first one that is not 216 an extension header [IANA-EH] indicates that the next item in the 217 packet is the corresponding upper-layer header. A special "No Next 218 Header" value is used if there is no upper-layer header. 220 As illustrated in these examples, an IPv4 packet MAY carry zero, one, 221 or more extension headers, each identified by Protocol field of the 222 IPv4 header or the Next Header field of a preceding extension header: 224 +---------------+------------------------ 225 | IPv4 header | TCP header + data 226 | | 227 | Protocol = | 228 | TCP | 229 +---------------+------------------------ 231 +---------------+----------------+------------------------ 232 | IPv4 header | Hop-by-Hop | TCP header + data 233 | | | 234 | Protocol = | Next Header = | 235 | Hop-by-Hop | TCP | 236 +---------------+----------------+------------------------ 238 +---------------+----------------+-----------------+----------------- 239 | IPv4 header | Hop-by-Hop | Fragment header | fragment of TCP 240 | | | | header + data 241 | Protocol = | Next Header = | Next Header = | 242 | Hop-by-Hop | Fragment | TCP | 243 +---------------+----------------+-----------------+----------------- 245 2.1 Requirements 247 2.1.1 General requirements 249 IPv4 extension headers normatively assume the requirements of IPv6 250 extension headers as defined in [RFC8200] section 4, with the 251 following modifications: 253 * References to the IPv6 header are replaced by references to the 254 IPv4 header. 256 * ICMP errors sent in the course of processing extension headers 257 use ICMPv4 instead of ICMPv6. Applicable ICMPv4 errors for 258 extension header processing are specified in section 2.3. 260 * The IPv4 header Protocol field assumes the same role and 261 semantics with respect to extension headers as the IPv6 Next 262 Header field. 264 * The Hop-by-Hop Options header is used to carry optional 265 information that MAY be examined and processed by any node along 266 a packet's delivery path. 268 * If a legacy IPv4 destination node, one that does not support 269 IPv4 extension headers, receives a packet with extension headers 270 then the packet will be processed as having an unknown protocol. 271 It is expected that the packet will be discarded and an ICMP 272 error may be generated. 274 * Extension headers or options that carry IPv6 specific data or 275 are otherwise specific to IPv6 MUST NOT be used with IPv4 276 (Segment Routing [SRV6EH] for example). IPv4 variants of these 277 may be defined if achieving the same functionality in IPv4 is 278 desirable. 280 * References to the Payload Length, for instance in reassembly 281 procedures, are reinterpreted as being the computed IPv4 payload 282 length (i.e. IPv4 Total Length minus the length of the IPv4 283 header). 285 2.1.2 Fragmentation and reassembly requirements 287 The following are modifications to fragmentation and reassembly 288 requirements: 290 * References to setting the Payload Length field in the IPv6 291 header are interpreted to be setting the Total Length in the 292 IPv4 header taking into account the IPv4 header length. 294 * When creating or modifying IPv4 headers in packets, the IPv4 295 header checksum MUST be set correctly. 297 * Different fragment packets MAY contain different IPv4 options. 298 In the reassembled packet, the IP options are taken from the 299 first fragment packet (the one with offset of zero). 301 * Different fragment packets MAY contain different extension 302 headers preceding the fragment header. In the reassembled 303 packet, the extension headers preceding the fragment header are 304 taken from the first fragment packet (the one with offset of 305 zero). 307 * If the length and offset of a fragment are such that the Total 308 Length of the packet reassembled from that fragment would exceed 309 65,535 octets, then that fragment must be discarded and an ICMP 310 Parameter Problem, Code 0, message should be sent to the source 311 of the fragment, pointing to the Fragment Offset field of the 312 fragment packet. 314 2.2 Interaction with standard IPv4 mechanisms 316 IPv4 extension headers may be used concurrently with IPv4 mechanisms 317 such as IPv4 options and IPv4 fragmentation. This section discusses 318 the interactions. 320 2.2.1 IPv4 options and IPv4 extension headers 322 An IPv4 packet MAY contain both IPv4 options and extension headers. 323 IPv4 options are completely independent of IPv4 extension headers. 324 IPv4 options MUST be processed before processing any extension 325 headers per normal requirements of processing the IP header before 326 the IP payload. 328 2.2.2 IPv4 fragmentation and IPv4 extension headers 330 An IPv4 packet MAY be fragmented both by using a Fragment extension 331 header as well as by standard IPv4 fragmentation. The Fragment header 332 can only be set at the source, however intermediate devices can 333 fragment packets using standard IPv4 fragmentation. Standard IPv4 334 fragmentation at a source node MUST be done only after any extension 335 headers are set in a packet or the packet was fragmented using the 336 Fragment header. Specifically, fragmentation using the extension 337 header MUST NOT be done on packet fragments created by standard IPv4 338 fragmentation. However, a packet fragment that contains a Fragment 339 header MAY itself be fragmented by standard IPv4 fragmentation. There 340 is no correlation between standard IPv4 fragmentation and the IPv4 341 Fragment header, the identifier space for each are unrelated and 342 reassembly procedures are independent. 344 At a destination, if a received packet was fragmented by standard 345 IPv4 fragmentation, it MUST be reassembled before processing any IPv4 346 extension headers. This requirement ensures that standard IPv4 347 reassembly is done before reassembly for the Fragment header. 349 If an IPv4 packet containing Hop-by-Hop options is fragmented using 350 standard IPv4 fragmentation, the Hop-by-Hop Options are not set in 351 each of the packet fragments. An intermediate node MAY process the 352 Hop-by-Hop options in the first fragment if the complete Hop-by-Hop 353 extension header is contained within the fragment. If the Fragment 354 header is used with IPv4 then the DF bit (Don't Fragment) bit SHOULD 355 be set and Path MTU discovery mechanisms SHOULD be used. 357 2.2.3 Atomic datagram recommendation 359 It is RECOMMENDED to only use IPv4 extensions in atomic datagrams. 360 Atomic datagrams [RFC6864] are IPv4 packets for which the Don't 361 Fragment bit set, More Fragment bit is not set, and Fragment Offset 362 is zero. In this case the packet will not be subject to IPv4 363 fragmentation, the Fragment header can alternatively be used for 364 fragmentation. 366 2.3 ICMP errors 368 ICMP errors are defined to be sent in response to errors that occur 369 in processing extension headers. Six ICMPv4 Parameter Problem codes 370 are defined and one Destination Unreachable code is defined. These 371 codes are adaptations of ICMPv6 codes defined in [RFC4443] and 372 [ICMPLIM]. 374 2.3.1 Parameter Problem codes 376 The format for ICMP Parameter Problem errors related to extension 377 header employs a multi-part ICMPv4 message format as defined in 378 [RFC4884]. The extended structure contains a pointer to the octet 379 beyond the limit. 381 The format of the ICMPv4 Parameter Problem for extension headers is: 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Type | Code | Checksum | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | unused | Length | unused | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Internet Header + leading octets of original datagram | 391 | | 392 | // | 393 | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Pointer | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 IPv4 Fields: 400 Destination Address 401 Copied from the Source Address field of the invoking packet. 403 ICMPv4 Fields: 405 Type 406 12 (Parameter Problem Message) 408 Code (pertinent to this specification) 410 3 - Erroneous header field encountered 411 4 - Unrecognized Next Header type encountered 412 5 - Unrecognized IPv4 option encountered 413 6 - Extension header too big 414 7 - Extension header chain too long 415 8 - Too many options in extension header 417 Length 418 Length of the padded "original datagram" field, measured in 32- 419 bit words. 421 Pointer 422 Identifies the octet offset within the invoking packet where 423 the error was detected. 425 Codes 3, 4, and 5 are analogues of Parameter Problem codes 0, 1, and 426 2 defined for IPv6 in [RFC4443]. Operation and semantics of these 427 codes are the same as their counterparts in [RFC4443] with the 428 following differences: 430 * The multi-part ICMP format of [RFC4884] is used and its fields 431 are set appropriately. 433 * The pointer to the offending byte in the invoking packet is 434 contained in the 32 bit Pointer field in the extended format. 436 Codes 6, 7, and 8 are analogues of Parameter Problem codes 4, 5, and 437 6 defined for IPv6 in [ICMPLIM]. Operation and semantics of these 438 codes are the same as their counterparts in [RFC4443] with the 439 following differences: 441 * The multi-part ICMP format of [RFC4884] is used and its fields 442 are set appropriately. 444 * The pointer to the offending byte in the invoking packet is 445 contained in the 32 bit Pointer field in the extended format. 447 2.3.2 Destination Unreachable codes 449 This specification defines one IPv4 Destination Unreachable code for 450 aggregate header limits being exceeded as described in [ICMPLIM]. The 451 error for aggregate header limits employs a multi-part ICMPv4 message 452 format as defined in [RFC4884]. The extended structure contains a 453 pointer to the octet beyond the limit. 455 The format of the ICMPv4 message for an aggregate header limit 456 exceeded is: 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Type | Code | Checksum | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | unused | Length | unused | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Internet Header + leading octets of original datagram | 466 | | 467 | // | 468 | | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Pointer | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 IPv4 Fields: 475 Destination Address 476 Copied from the Source Address field of the invoking packet. 478 ICMPv4 Fields: 480 Type 481 3 (Destination Unreachable Message) 483 Code (pertinent to this specification) 485 16 - Headers too long 487 Length 488 Length of the padded "original datagram" field, measured in 32- 489 bit words. 491 Pointer 492 Identifies the octet offset within the invoking packet where 493 the error was detected. 495 Code 16 is an analogue of Destination Unreachable code 8 defined in 496 [ICMP6LIM]. Operation and semantics of the code should be the same as 497 the counterpart in [ICMP6LIM]. 499 2.4 Processing limits 501 Section 5.3 of [RFC8504] describes the use of limits in processing 502 extension headers in order to protect a node from excessive extension 503 header options. These limits are adapted for use with IPv4 extension 504 headers. 506 A node MAY impose limits on processing IPv4 extension headers and 507 Destination and Hop-by-Hop options. This includes limits on length or 508 number of consecutive padding options, disallowing unknown options, 509 and limits on the number of options or length of options. If a limit 510 is exceeded in processing a received packet, the packet is discarded 511 and an appropriate ICMP error defined in Section 2.3 SHOULD be sent. 513 A node MAY allow configuration of different limits for processing 514 IPv4 and IPv6 options. The default limits for IPv4 are assumed to be 515 those defined in [RFC8504]. 517 2.5 No Next Header 519 The value 59 may be set in the Protocol field of the IPv4 header or 520 in Next Header field of an IPv4 extension header. This indicates that 521 there is nothing following that header. The semantics of setting this 522 value are the same as that described in [RFC8200] with adaptation for 523 use with IPv4. If the Total Length field of the IPv4 header indicates 524 the presence of octets past the end of a header whose Next Header 525 field contains 59, those octets must be ignored and passed on 526 unchanged if the packet is forwarded. 528 3 The IPv4 flow label 530 The Identification field of the IPv4 header is re-purposed to be the 531 IPv4 flow label in atomic datagrams. As stated in [RFC6864]: 533 ">> Originating sources MAY set the IPv4 ID field of atomic 534 datagrams to any value." 536 This specification allows the IPv4 ID to be used as a flow label in 537 atomic datagrams where (DF==1)&&(MF==0)&&(frag_offset==0). 539 3.1 Sender requirements 541 An origin host MAY set the IPv4 Identification field as a flow label 542 in atomic datagram packets. The IPv4 flow label is set following the 543 same procedures for setting the IPv6 flow label as described in 544 [RFC6437] with the following modifications: 546 * The Identification field MUST only be used as a flow label in 547 atomic datagrams. That is Don't Fragment (DF) bit MUST be set, 548 More Fragment (MF) bit MUST NOT be set, and Fragment Offset MUST 549 be zero. 551 * If the IPv4 Identification field is not used as a flow label in 552 atomic fragments, the Identification field MUST be set to zero. 554 * Only stateless flow labels can be set. 556 * The value to set, e.g. from a hash computation over packet 557 headers, is truncated to sixteen bits (the size of the 558 Identification field). 560 * Intermediate nodes MUST NOT set the Identification field in 561 atomic datagrams. 563 3.2 Receiver requirements 565 Receivers, including intermediate hosts, MAY process a non-zero 566 Identification field in the IPv4 header of atomic datagrams as being 567 a flow label. The IPv4 flow label for instance can be used as input 568 to ECMP as described in [RFC6438]. 570 If the Identification field is zero or the packet is not an atomic 571 datagram (either the More Fragment bit is set, the Don't Fragment bit 572 is not set, or Fragment Offset is non-zero) then the Identification 573 field MUST NOT be considered as a flow label. 575 4 Deployability 577 If a legacy host device receives an IPv4 packet with IPv4 extension 578 headers, the packet will be treated as having an unknown protocol and 579 should dropped. Intermediate devices might also see packets with a 580 protocol unknown to them and will forward the packet inasmuch as they 581 would forward any packet with an unknown protocol. 583 In the Internet, it is well known that there are some intermediate 584 nodes that will drop packets with protocols that are unknown to them 585 (firewalls would commonly to this for instance). Therefore, it is 586 unlikely that packets with IPv4 extension headers can be ubiquitously 587 deployed over the Internet. A workaround to this might be to 588 encapsulate extension headers in UDP [EHUDPENCAP]. 590 In a limited domain [LIMDOM], an operator would have control over 591 intermediate nodes and could ensure that at a minimum they properly 592 forward packets with IPv4 extension headers. Routers in a limited 593 domain can be updated to process IPv4 Hop-by-Hop Options or Routing 594 headers to provide the functionality of features like IOAM and 595 Segment Routing in IPv4. Similarly, they could be updated to support 596 the IPv4 flow label to provide flow based ECMP in the same manner 597 that the IPv6 flow label is used for ECMP [RFC6438]. 599 5 Security Considerations 601 This specification enables use of IPv6 extension headers in IPv4. 602 Related security mechanisms of IPv6 extension headers can be applied 603 for use with IPv4 extension headers. 605 The IPv4 flow label has similar security properties as the IPv6 flow 606 label. 608 6 IANA Considerations 610 6.1 Protocol descriptions 612 IANA is requested to change the descriptions of IPv6 extension 613 headers and No Next Header protocol numbers to reflect that they are 614 not IPv6 specific. 616 In the Assigned Internet Protocol Numbers Registry, the modified 617 protocols descriptions are: 619 +----------+---------+------------+-----------+--------------------+ 620 | Decimal | Keyword | Protocol | IPv6 | Reference | 621 | | | | Extension | | 622 | | | | header | | 623 +----------+---------+------------+-----------+--------------------+ 624 | 0 | HOPOPT | Hop-by-Hop | | [RFC8200][RFCXXXX] | 625 | | | Option | | [This document] | 626 +----------+---------+------------+-----------+--------------------+ 627 | 43 | Route | Routing | | [Steve_Deering] | 628 | | | Header | | [This document] | 629 +----------+---------+------------+-----------+--------------------+ 630 | 44 | Frag | Fragment | | [Steve_Deering] | 631 | | | Header | | [This document] | 632 +----------+---------+------------+-----------+--------------------+ 633 | 59 | NoNxt | No Next | | [RFC8200][RFCXXXX] | 634 | | | Header | | [This document] | 635 +----------+---------+------------+-----------+--------------------+ 636 | 60 | Opts | Destination| | [RFC8200][RFCXXXX] | 637 | | | Options | | [This document] | 638 +----------+---------+------------+-----------+--------------------+ 640 IANA is requested to update "Internet Protocol Version 4 (IPv4) 641 Parameters" to include sections for "IPv6 Extension Header Types", 642 "Destination Options and "Hop-by-Hop Options", and "Routing Types". 643 These are based on the similarly named sections in "Internet Protocol 644 Version 6 (IPv6) Parameters" with appropriate modifications for IPv4. 646 6.2 Parameter Problem codes 648 IANA is requested to assign the following codes in "ICMP Type 649 Numbers" for type 12 "Parameter Problem": 651 3 - Erroneous header field encountered 653 4 - Unrecognized Next Header type encountered 655 5 - Unrecognized IPv4 option encountered 657 6 - Extension header too big 659 7 - Extension header chain too long 661 8 - Too many options in extension header 663 6.2 Destination Unreachable codes 665 IANA is requested to assign the following codes in "ICMP Type 666 Numbers" for type 3 "Destination Unreachable": 668 16 - Headers too long 670 7 References 672 7.1 Normative References 674 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 675 1981. 677 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 678 (IPv6) Specification", STD 86, RFC 8200, DOI 679 10.17487/RFC8200, July 2017, . 682 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 683 RFC 6864, DOI 10.17487/RFC6864, February 2013, 684 . 686 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for 687 Equal Cost Multipath Routing and Link Aggregation in 688 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 689 . 691 7.2 Informative References 693 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations 694 on the Dropping of Packets with IPv6 Extension Headers in 695 the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, 696 . 698 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 699 Control Message Protocol (ICMPv6) for the Internet Protocol 700 Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 701 10.17487/RFC4443, March 2006, . 704 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 705 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 706 DOI 10.17487/RFC4884, April 2007, . 709 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 710 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 711 January 2019, . 713 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 714 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 715 August 2015, . 717 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 718 "IPv6 Flow Label Specification", RFC 6437, DOI 719 10.17487/RFC6437, November 2011, . 722 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for 723 Equal Cost Multipath Routing and Link Aggregation in 724 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 725 . 727 [V6STATE] B. Kuerbis and M. Mueller, Internet Governance Project, 728 "The Hidden Standards War: Economic Factors Affecting IPv6 729 Deployment", February, 2019. 731 [SRV6EH] C. Filsfils, Ed., S. Previdi, J. Leddy, S. Matsushima, D. 732 Voyer, Ed., "IPv6 Segment Routing Header (SRH)", draft- 733 ietf-6man-segment-routing-header-16 735 [CRH] Bonica, R., So, N., Xu, F., Chen, G., Zhu, Y., Yang, G., 736 Zhou, Y., "The IPv6 Compressed Routing Header (CRH)" draft- 737 bonica-6man-comp-rtg-hdr-03 739 [MTUOPT] Hinden, R. and Fairhurst, G., "IPv6 Minimum Path MTU Hop- 740 by-Hop Option", draft-hinden-6man-mtu-option-00 742 [IOAM] F. Brockners, S. Bhandari, V. Govindan, C. Pignataro, H. 743 Gredler, J. Leddy, S. Youell, T. Mizrahi, D. Mozes, P. 744 Lapukhov, R. Chang, "Encapsulations for In-situ OAM Data" 745 draft-brockners-inband-oam-transport-05 747 [SAIN] Li, Z. and Peng, S., "Service-aware IPv6 Network", draft- 748 li-6man-service-aware-ipv6-network-00 750 [FAST] Herbert, T., "Firewall and Service Tickets", draft-herbert- 751 fast-03 753 [SPUD] Hildebrbrand, J. and Trammell, B., Substrate Protocol for 754 User Datagrams (SPUD) Prototype, draft-hildebrand-spud- 755 prototype-03 757 [IOAMGEN] Brockners, F. et al., "Geneve encapsulation for In-situ OAM 758 Data", draft-brockners-ippm-ioam-geneve-01 760 [IPNOOP] Rodrigo Fonseca, George Manning Porter, Randy H. Katz, 761 Scott Shenker and Ion Stoica, "IP Options are not an 762 option", 763 766 [ICMPLIM] Herbert, T., "ICMPv6 errors for discarding packets due to 767 processing limits", draft-ietf-6man-icmp-limits-01 769 [IANA-PN] IANA, "Protocol Numbers", 770 . 772 [IANA-EH] IANA, "IPv6 Extension Header Types", 773 . 775 [LIMDOM] Carpenter, B., and Liu, B., "Limited Domains and Internet 776 Protocols", draft-carpenter-limited-domains-06 778 Author's Address 780 Tom Herbert 781 Quantonium 782 Santa Clara, CA 784 USA 786 Email: tom@quantonium.net