idnits 2.17.1 draft-ietf-intarea-ipv4-id-update-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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC2003, but the abstract doesn't seem to directly say this. It does mention RFC2003 though, so this could be OK. -- The draft header indicates that this document updates RFC1122, but the abstract doesn't seem to directly say this. It does mention RFC1122 though, so this could be OK. -- The draft header indicates that this document updates RFC791, but the abstract doesn't seem to directly say this. It does mention RFC791 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC791, updated by this document, for RFC5378 checks: 1981-09-01) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 30, 2012) is 4346 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: '10' on line 493 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Area WG J. Touch 2 Internet Draft USC/ISI 3 Updates: 791,1122,2003 May 30, 2012 4 Intended status: Proposed Standard 5 Expires: November 2012 7 Updated Specification of the IPv4 ID Field 8 draft-ietf-intarea-ipv4-id-update-05.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 This document may contain material from IETF Documents or IETF 16 Contributions published or made publicly available before November 17 10, 2008. The person(s) controlling the copyright in some of this 18 material may not have granted the IETF Trust the right to allow 19 modifications of such material outside the IETF Standards Process. 20 Without obtaining an adequate license from the person(s) controlling 21 the copyright in such materials, this document may not be modified 22 outside the IETF Standards Process, and derivative works of it may 23 not be created outside the IETF Standards Process, except to format 24 it for publication as an RFC or to translate it into languages other 25 than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on November 30, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Abstract 62 The IPv4 Identification (ID) field enables fragmentation and 63 reassembly, and as currently specified is required to be unique 64 within the maximum lifetime for all datagrams with a given 65 source/destination/protocol tuple. If enforced, this uniqueness 66 requirement would limit all connections to 6.4 Mbps. Because 67 individual connections commonly exceed this speed, it is clear that 68 existing systems violate the current specification. This document 69 updates the specification of the IPv4 ID field in RFC791, RFC1122, 70 and RFC2003 to more closely reflect current practice and to more 71 closely match IPv6 so that the field's value is defined only when a 72 datagram is actually fragmented. It also discusses the impact of 73 these changes on how datagrams are used. 75 Table of Contents 77 1. Introduction...................................................3 78 2. Conventions used in this document..............................3 79 3. The IPv4 ID Field..............................................4 80 4. Uses of the IPv4 ID Field......................................4 81 5. Background on IPv4 ID Reassembly Issues........................5 82 6. Updates to the IPv4 ID Specification...........................6 83 6.1. IPv4 ID Used Only for Fragmentation.......................7 84 6.2. Encourage Safe IPv4 ID Use................................8 85 6.3. IPv4 ID Requirements That Persist.........................8 86 7. Impact on Datagram Use.........................................9 87 8. Updates to Existing Standards..................................9 88 8.1. Updates to RFC 791.......................................10 89 8.2. Updates to RFC 1122......................................10 90 8.3. Updates to RFC 2003......................................11 92 9. Impact on Middleboxes.........................................11 93 9.1. Rewriting Middleboxes....................................12 94 9.2. Filtering Middleboxes....................................13 95 10. Impact on Header Compression.................................13 96 11. Security Considerations......................................13 97 12. IANA Considerations..........................................14 98 13. References...................................................14 99 13.1. Normative References....................................14 100 13.2. Informative References..................................14 101 14. Acknowledgments..............................................16 103 1. Introduction 105 In IPv4, the Identification (ID) field is a 16-bit value that is 106 unique for every datagram for a given source address, destination 107 address, and protocol, such that it does not repeat within the 108 Maximum Segment Lifetime (MSL) [RFC791][RFC1122]. As currently 109 specified, all datagrams between a source and destination of a given 110 protocol must have unique IPv4 ID values over a period of this MSL, 111 which is typically interpreted as two minutes (120 seconds). This 112 uniqueness is currently specified as for all datagrams, regardless of 113 fragmentation settings. 115 Uniqueness of the IPv4 ID is commonly violated by high speed devices; 116 if strictly enforced, it would limit the speed of a single protocol 117 between two IP endpoints to 6.4 Mbps for typical MTUs of 1500 bytes 118 [RFC4963]. It is common for a single connection to operate far in 119 excess of these rates, which strongly indicates that the uniqueness 120 of the IPv4 ID as specified is already moot. 122 This document updates the specification of the IPv4 ID field to more 123 closely reflect current practice, and to include considerations taken 124 into account during the specification of the similar field in IPv6. 126 2. Conventions used in this document 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC-2119 [RFC2119]. 132 In this document, the characters ">>" proceeding an indented line(s) 133 indicates a requirement using the key words listed above. This 134 convention aids reviewers in quickly identifying or finding this 135 document's explicit requirements. 137 3. The IPv4 ID Field 139 IP supports datagram fragmentation, where large datagrams are split 140 into smaller components to traverse links with limited maximum 141 transmission units (MTUs). Fragments are indicated in different ways 142 in IPv4 and IPv6: 144 o In IPv4, fragments are indicated using four fields of the basic 145 header: Identification (ID), Fragment Offset, a "Don't Fragment" 146 flag (DF), and a "More Fragments" flag (MF) [RFC791] 148 o In IPv6, fragments are indicated in an extension header that 149 includes an ID, Fragment Offset, and M (more fragments) flag 150 similar to their counterparts in IPv4 [RFC2460] 152 IPv4 and IPv6 fragmentation differs in a few important ways. IPv6 153 fragmentation occurs only at the source, so a DF bit is not needed to 154 prevent downstream devices from initiating fragmentation (i.e., IPv6 155 always acts as if DF=1). The IPv6 fragment header is present only 156 when a datagram has been fragmented, or when the source has received 157 a "packet too big" ICMPv6 error message when the path cannot support 158 the required minimum 1280-byte IPv6 MTU and is thus subject to 159 translation [RFC2460][RFC4443]. The latter case is relevant only for 160 IPv6 datagrams sent to IPv4 destinations to support subsequent 161 fragmentation after translation to IPv4. 163 With the exception of these two cases, the ID field is not present 164 for non-fragmented datagrams, and thus is meaningful only for 165 datagrams that are already fragmented or datagrams intended to be 166 fragmented as part of IPv4 translation. Finally, the IPv6 ID field is 167 32 bits, and required unique per source/destination address pair for 168 IPv6, whereas for IPv4 it is only 16 bits and required unique per 169 source/destination/protocol triple. 171 This document focuses on the IPv4 ID field issues, because in IPv6 172 the field is larger and present only in fragments. 174 4. Uses of the IPv4 ID Field 176 The IPv4 ID field was originally intended for fragmentation and 177 reassembly [RFC791]. Within a given source address, destination 178 address, and protocol, fragments of an original datagram are matched 179 based on their IPv4 ID. This requires that IDs are unique within the 180 address/protocol triple when fragmentation is possible (e.g., DF=0) 181 or when it has already occurred (e.g., frag_offset>0 or MF=1). 183 The IPv4 ID field can be useful for other purposes. The field has 184 been proposed as a way to detect and remove duplicate datagrams, 185 e.g., at congested routers (noted in Sec. 3.2.1.5 of [RFC1122]) or in 186 network accelerators. It can similarly be used at end hosts to reduce 187 the impact of duplication on higher-layer protocols (e.g., additional 188 processing in TCP, or the need for application-layer duplicate 189 suppression in UDP). 191 The IPv4 ID field is also used in some debugging tools to correlate 192 datagrams measured at various locations along a network path. This is 193 already insufficient in IPv6 because unfragmented datagrams lack an 194 ID, so these tools are already being updated to avoid such reliance 195 on the ID field. 197 The ID clearly needs to be unique (within MSL, within the 198 src/dst/protocol tuple) to support fragmentation and reassembly, but 199 not all datagrams are fragmented or allow fragmentation. This 200 document deprecates non-fragmentation uses, allowing the ID to be 201 repeated (within MSL, within the src/dst/protocol tuple) in those 202 cases. 204 5. Background on IPv4 ID Reassembly Issues 206 The following is a summary of issues with IPv4 fragment reassembly in 207 high speed environments raised previously [RFC4963]. Readers are 208 encouraged to consult RFC 4963 for a more detailed discussion of 209 these issues. 211 With the maximum IPv4 datagram size of 64KB, a 16-bit ID field that 212 does not repeat within 120 seconds means that the aggregate of all 213 TCP connections of a given protocol between two IP endpoints is 214 limited to roughly 286 Mbps; at a more typical MTU of 1500 bytes, 215 this speed drops to 6.4 Mbps [RFC791][RFC1122][RFC4963]. This limit 216 currently applies for all IPv4 datagrams within a single protocol 217 (i.e., the IPv4 protocol field) between two IP addresses, regardless 218 of whether fragmentation is enabled or inhibited, and whether a 219 datagram is fragmented or not. 221 IPv6, even at typical MTUs, is capable of 18.7 Tbps with 222 fragmentation between two IP endpoints as an aggregate across all 223 protocols, due to the larger 32-bit ID field (and the fact that the 224 IPv6 next-header field, the equivalent of the IPv4 protocol field, is 225 not considered in differentiating fragments). When fragmentation is 226 not used the field is absent, and in that case IPv6 speeds are not 227 limited by the ID field uniqueness. 229 Note also that 120 seconds is only an estimate on the maximum 230 datagram lifetime. It is loosely based on half maximum value of the 231 IP TTL field (255), measured in seconds, because the TTL was 232 originally specified as decremented not only for each hop, but also 233 for each second a datagram is held at a router (as implied in 234 [RFC791], although this has long since become a hopcount only). 235 Network delays are incurred in other ways, e.g., satellite links, 236 which can add seconds of delay even though the TTL is not decremented 237 by a corresponding amount. There is thus no enforcement mechanism to 238 ensure that datagrams older than 120 seconds are discarded. 240 Wireless Internet devices are frequently connected at speeds over 54 241 Mbps, and wired links of 1 Gbps have been the default for several 242 years. Although many end-to-end transport paths are congestion 243 limited, these devices easily achieve 100+ Mbps application-layer 244 throughput over LANs (e.g., disk-to-disk file transfer rates), and 245 numerous throughput demonstrations with COTS systems over wide-area 246 paths exhibit these speeds for over a decade. This strongly suggests 247 that IPv4 ID uniqueness has been moot for a long time. 249 6. Updates to the IPv4 ID Specification 251 This document updates the specification of the IPv4 ID field in three 252 distinct ways, as discussed in subsequent subsections: 254 o Use the IPv4 ID field only for fragmentation 256 o Avoiding a performance impact when the IPv4 ID field is used 258 o Encourage safe operation when the IPv4 ID field is used 260 There are two kinds of datagrams used in the following discussion, 261 named as follows: 263 o Atomic datagrams are datagrams not yet fragmented and for which 264 further fragmentation has been inhibited. 266 o Non-atomic datagrams are datagrams which either have already been 267 fragmented or for which fragmentation remains possible. 269 This same definition can be expressed in pseudo code as using common 270 logical operators (equals is ==, logical 'and' is &&, logical 'or' is 271 ||, greater than is >, and parenthesis function typically) as: 273 o Atomic datagrams: (DF==1)&&(MF==0)&&(frag_offset==0) 275 o Non-atomic datagrams: (DF==0)||(MF==1)||(frag_offset>0) 276 The test for non-atomic datagrams is the logical negative of the test 277 for atomic datagrams, thus all possibilities are considered. 279 6.1. IPv4 ID Used Only for Fragmentation 281 Although RFC1122 suggests the IPv4 ID field has other uses, including 282 datagram de-duplication, this document asserts that this field's 283 value is defined only for fragmentation and reassembly: 285 >> IPv4 ID field MUST NOT be used for purposes other than 286 fragmentation and reassembly. 288 Datagram de-duplication can be accomplished using hash-based 289 duplicate detection for cases where the ID field is absent. 291 In atomic datagrams, the IPv4 ID field has no meaning, and thus can 292 be set to an arbitrary value, i.e., the requirement for non-repeating 293 IDs within the address/protocol triple is no longer required for 294 atomic datagrams: 296 >> Originating sources MAY set the IPv4 ID field of atomic datagrams 297 to any value. 299 Second, all network nodes, whether at intermediate routers, 300 destination hosts, or other devices (e.g., NATs and other address 301 sharing mechanisms, firewalls, tunnel egresses), cannot rely on the 302 field: 304 >> All devices that examine IPv4 headers MUST ignore the IPv4 ID 305 field of atomic datagrams. 307 The IPv4 ID field is thus meaningful only for non-atomic datagrams - 308 datagrams that have either already been fragmented, or those for 309 which fragmentation remains permitted. Atomic datagrams are detected 310 by their DF, MF, and fragmentation offset fields as explained in 311 Section 6, because such a test is completely backward compatible; 312 this document thus does not reserve any IPv4 ID values, including 0, 313 as distinguished. 315 Deprecating the use of the IPv4 ID field for non-reassembly uses 316 should have little - if any - impact. IPv4 IDs are already frequently 317 repeated, e.g., over even moderately fast connections. Duplicate 318 suppression was only suggested [RFC1122], and no impacts of IPv4 ID 319 reuse have been noted. Routers are not required to issue ICMPs on any 320 particular timescale, and so IPv4 ID repetition should not have been 321 used for validation, and again repetition occurs and probably could 322 have been noticed [RFC1812]. ICMP relaying at tunnel ingresses is 323 specified to use soft state rather than a datagram cache, and should 324 have been noted if the latter for similar reasons [RFC2003]. 326 6.2. Encourage Safe IPv4 ID Use 328 This document makes further changes to the specification of the IPv4 329 ID field and its use to encourage its safe use as corollary 330 requirements changes as follows. 332 RFC 1122 discusses that if TCP retransmits a segment it may be 333 possible to reuse the IPv4 ID (see Section 8.2). This can make it 334 difficult for a source to avoid IPv4 ID repetition for received 335 fragments. RFC 1122 concludes that this behavior "is not useful"; 336 this document formalizes that conclusion as follows: 338 >> The IPv4 ID of non-atomic datagrams MUST NOT be reused when 339 sending a copy of an earlier non-atomic datagram. 341 RFC 1122 also suggests that fragments can overlap [RFC1122]. Such 342 overlap can occur if successive retransmissions are fragmented in 343 different ways but with the same reassembly IPv4 ID. This overlap is 344 noted as the result of reusing IPv4 IDs when retransmitting 345 datagrams, which this document deprecates. However, it is also the 346 result of in-network datagram duplication, which can still occur. As 347 a result this document does not change the need to support 348 overlapping fragments. 350 6.3. IPv4 ID Requirements That Persist 352 This document does not relax the IPv4 ID field uniqueness 353 requirements of [RFC791] for non-atomic datagrams, i.e.: 355 >> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID 356 values within one MSL for a given source address/destination 357 address/protocol triple. 359 Such sources include originating hosts, tunnel ingresses, and NATs 360 (including other address sharing mechanisms) (see Section 9). 362 This document does not relax the requirement that all network devices 363 honor the DF bit, i.e.: 365 >> IPv4 datagrams whose DF=1 MUST NOT be fragmented. 367 >> IPv4 datagram transit devices MUST NOT clear the DF bit. 369 In specific, DF=1 prevents fragmenting atomic datagrams. DF=1 also 370 prevents further fragmenting received fragments. In-network 371 fragmentation is permitted only when DF=0; this document does not 372 change that requirement. 374 7. Impact on Datagram Use 376 The following is a summary of the recommendations that are the result 377 of the previous changes to the IPv4 ID field specification. 379 Because atomic datagrams can use arbitrary IPv4 ID values, the ID 380 field no longer imposes a performance impact in those cases. However, 381 the performance impact remains for non-atomic datagrams. As a result: 383 >> Sources of non-atomic IPv4 datagrams MUST rate-limit their output 384 to comply with the ID uniqueness requirements. 386 Such sources include, in particular, DNS over UDP [RFC2671]. 388 Because there is no strict definition of the MSL, reassembly hazards 389 exist regardless of the IPv4 ID reuse interval or the reassembly 390 timeout. As a result: 392 >> Higher layer protocols SHOULD verify the integrity of IPv4 393 datagrams, e.g., using a checksum or hash that can detect reassembly 394 errors (the UDP checksum is weak in this regard, but better than 395 nothing), as in SEAL [RFC5320]. 397 Additional integrity checks can be employed using tunnels, as in 398 SEAL, IPsec, or SCTP [RFC4301][RFC4960][RFC5320]. Such checks can 399 avoid the reassembly hazards that can occur when using UDP and TCP 400 checksums [RFC4963], or when using partial checksums as in UDP-Lite 401 [RFC3828]. Because such integrity checks can avoid the impact of 402 reassembly errors: 404 >> Sources of non-atomic IPv4 datagrams using strong integrity checks 405 MAY reuse the ID within MSL values smaller than is typical. 407 Note, however, that such frequent reuse can still result in corrupted 408 reassembly and poor throughput, although it would not propagate 409 reassembly errors to higher layer protocols. 411 8. Updates to Existing Standards 413 The following sections address the specific changes to existing 414 protocols indicated by this document. 416 8.1. Updates to RFC 791 418 RFC 791 states that: 420 The originating protocol module of an internet datagram sets the 421 identification field to a value that must be unique for that 422 source-destination pair and protocol for the time the datagram 423 will be active in the internet system. 425 And later that: 427 Thus, the sender must choose the Identifier to be unique for this 428 source, destination pair and protocol for the time the datagram 429 (or any fragment of it) could be alive in the internet. 431 It seems then that a sending protocol module needs to keep a table 432 of Identifiers, one entry for each destination it has communicated 433 with in the last maximum datagram lifetime for the internet. 435 However, since the Identifier field allows 65,536 different 436 values, some host may be able to simply use unique identifiers 437 independent of destination. 439 It is appropriate for some higher level protocols to choose the 440 identifier. For example, TCP protocol modules may retransmit an 441 identical TCP segment, and the probability for correct reception 442 would be enhanced if the retransmission carried the same 443 identifier as the original transmission since fragments of either 444 datagram could be used to construct a correct TCP segment. 446 This document changes RFC 791 as follows: 448 o IPv4 ID uniqueness applies to only non-atomic datagrams. 450 o Retransmitted non-atomic IPv4 datagrams are no longer permitted to 451 reuse the ID value. 453 8.2. Updates to RFC 1122 455 RFC 1122 states that: 457 3.2.1.5 Identification: RFC-791 Section 3.2 459 When sending an identical copy of an earlier datagram, a 460 host MAY optionally retain the same Identification field in 461 the copy. 463 DISCUSSION: 465 Some Internet protocol experts have maintained that when a 466 host sends an identical copy of an earlier datagram, the new 467 copy should contain the same Identification value as the 468 original. There are two suggested advantages: (1) if the 469 datagrams are fragmented and some of the fragments are lost, 470 the receiver may be able to reconstruct a complete datagram 471 from fragments of the original and the copies; (2) a 472 congested gateway might use the IP Identification field (and 473 Fragment Offset) to discard duplicate datagrams from the 474 queue. 476 This document changes RFC 1122 as follows: 478 o The IPv4 ID field is no longer permitted to be used for duplicate 479 detection. This applies to both atomic and non-atomic datagrams. 481 o Retransmitted non-atomic IPv4 datagrams are no longer permitted to 482 reuse the ID value. 484 8.3. Updates to RFC 2003 486 This document updates how IPv4-in-IPv4 tunnels create IPv4 ID values 487 for the IPv4 outer header [RFC2003], but only in the same way as for 488 any other IPv4 datagram source. In specific, RFC 2003 states the 489 following, where ref. [10] is RFC 791: 491 Identification, Flags, Fragment Offset 493 These three fields are set as specified in [10]... 495 This document changes RFC 2003 as follows: 497 o The IPv4 ID field is set as permitted by this document. 499 9. Impact on Middleboxes 501 Middleboxes include rewriting devices that include network address 502 translators (NATs), address/port translators (NAPTs), and other 503 address sharing mechanisms (ASMs). They also include devices that 504 inspect and filter datagrams that are not routers, such as 505 accelerators and firewalls. 507 9.1. Rewriting Middleboxes 509 NATs and NAPTs rewrite IP fields, and tunnel ingresses (using IPv4 510 encapsulation) copy and modify some IPv4 fields, so all are 511 considered sources, as do any devices that rewrite any portion of the 512 source address, destination address, protocol, and ID tuple for any 513 datagrams [RFC3022]. This is also true for other ASMs, including 4rd, 514 IVI, and others in the "A+P" (address plus port) family [Bo11] [De11] 515 [RFC6219]. It is equally true for any other datagram rewriting 516 mechanism. As a result, they are subject to all the requirements of 517 any source, as has been noted. 519 NATs/ASMs/rewriters present a particularly challenging situation for 520 fragmentation. Because they overwrite portions of the reassembly 521 tuple in both directions, they can destroy tuple uniqueness and 522 result in a reassembly hazard. Whenever IPv4 source address, 523 destination address, or protocol fields are modified, a 524 NAT/ASM/rewriter needs to ensure that the ID field is generated 525 appropriately, rather than simply copied from the incoming datagram. 526 In specific: 528 >> Address sharing or rewriting devices MUST ensure that the IPv4 ID 529 field of datagrams whose address or protocol are translated comply 530 with these requirements as if the datagram were sourced by that 531 device. 533 This compliance means that the IPv4 ID field of non-atomic datagrams 534 translated at a NAT/ASM/rewriter needs to obey the uniqueness 535 requirements of any IPv4 datagram source. Unfortunately, fragments 536 already violate that requirement, as they repeat an IPv4 ID within 537 the MSL for a given source address, destination address, and protocol 538 triple. 540 Such problems with transmitting fragments through NATs/ASMs/rewriters 541 are already known; translation is based on the transport port number, 542 which is present in only the first fragment anyway [RFC3022]. This 543 document underscores the point that not only is reassembly (and 544 possibly subsequent fragmentation) required for translation, it can 545 be used to avoid issues with IPv4 ID uniqueness. 547 Note that NATs/ASMs already need to exercise special care when 548 emitting datagrams on their public side, because merging datagrams 549 from many sources onto a single outgoing source address can result in 550 IPv4 ID collisions. This situation precedes this document, and is not 551 affected by it. It is exacerbated in large-scale, so-called "carrier 552 grade" NATs [Pe11]. 554 Tunnel ingresses act as sources for the outermost header, but tunnels 555 act as routers for the inner headers (i.e., the datagram as arriving 556 at the tunnel ingress). Ingresses can always fragment as originating 557 sources of the outer header, because they control the uniqueness of 558 that IPv4 ID field and the value of DF on the outer header 559 independent of those values on the inner (arriving datagram) header. 561 9.2. Filtering Middleboxes 563 Middleboxes also include devices that filter datagrams, including 564 network accelerators and firewalls. Some such devices reportedly 565 feature datagram de-duplication, which relies on IP ID uniqueness to 566 identify duplicates. Such accelerators already risk dropping non- 567 duplicate datagrams because of early ID reuse, and, as a result of 568 earlier requirements: 570 >> Datagram de-duplication mechanisms MUST ignore the ID values on 571 atomic datagrams. 573 10. Impact on Header Compression 575 Header compression algorithms already accommodate various ways in 576 which the IPv4 ID changes between sequential datagrams [RFC1144] 577 [RFC2508] [RFC3545] [RFC5225]. Such algorithms currently assume that 578 the IPv4 ID is preserved end-to-end. Some algorithms already allow 579 assuming the ID does not change (e.g., ROHC [RFC5225]), where others 580 include non-changing IDs via zero deltas (e.g., ECRTP [RFC3545]). 582 When compression assumes a changing ID as a default, having a non- 583 changing ID can make compression less efficient. Such non-changing 584 IDs have been described in various RFCs (e.g., footnote 21 of 585 [RFC1144 and cRTP [RFC2508]). When compression can assume a non- 586 changing IPv4 ID - as with ROHC and ECRTP - efficiency can be 587 increased. 589 11. Security Considerations 591 When the IPv4 ID is ignored on receipt (e.g., for atomic datagrams), 592 its value becomes unconstrained; that field then can more easily be 593 used as a covert channel. For some atomic datagrams - notably those 594 not protected by IPsec Authentication Header (AH) [RFC4302] - it is 595 now possible, and may be desirable, to rewrite the IPv4 ID field to 596 avoid its use as such a channel. 598 The IPv4 ID also now adds much less entropy of the header of a 599 datagram. The IPv4 ID had previously been unique (for a given 600 source/address pair, and protocol field) within one MSL, although 601 this requirement was not enforced and clearly is typically ignored. 602 The IPv4 ID of atomic datagrams is not required unique, and so 603 contributes no entropy to the header. 605 The deprecation of the IPv4 ID field's uniqueness for atomic 606 datagrams can defeat the ability to count devices behind a 607 NAT/ASM/rewriter [Be02]. This is not intended as a security feature, 608 however. 610 12. IANA Considerations 612 There are no IANA considerations in this document. 614 The RFC Editor should remove this section prior to publication 616 13. References 618 13.1. Normative References 620 [RFC791] Postel, J., "Internet Protocol", RFC 791 / STD 5, September 621 1981. 623 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 624 Communication Layers", RFC 1122 / STD 3, October 1989. 626 [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers", 627 RFC 1812 / STD 4, Jun. 1995. 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", RFC 2119 / BCP 14, March 1997. 632 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 633 October 1996. 635 13.2. Informative References 637 [Be02] Bellovin, S., "A Technique for Counting NATted Hosts", 638 Internet Measurement Conference, Proceedings of the 2nd ACM 639 SIGCOMM Workshop on Internet Measurement, Nov. 2002. 641 [Bo11] Boucadair, M., J. Touch, P. Levis, R. Penno, "Analysis of 642 Solution Candidates to Reveal a Host Identifier in Shared 643 Address Deployments", (work in progress), draft-boucadair- 644 intarea-nat-reveal-analysis, Sept. 2011. 646 [De11] Despres, R. (Ed.), S. Matsushima, T. Murakami, O. Troan, 647 "IPv4 Residual Deployment across IPv6-Service networks 648 (4rd)", (work in progress), draft-despres-intarea-4rd, Mar. 649 2011. 651 [Pe11] Perreault, S., (Ed.), I. Yamagata, S. Miyakawa, A. 652 Nakagawa, H. Ashida, "Common requirements of IP address 653 sharing schemes", (work in progress), draft-ietf-behave- 654 lsn-requirements, Mar. 2011. 656 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, Feb. 657 1990. 659 [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6 660 (IPv6) Specification", RFC 2460, Dec. 1998. 662 [RFC2508] Casner, S., V. Jacobson. "Compressing IP/UDP/RTP Headers 663 for Low-Speed Serial Links", RFC 2508, Feb. 1999. 665 [RFC2671] Vixie,P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 666 Aug. 1999. 668 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 669 Address Translator (Traditional NAT)", RFC 3022, Jan. 2001. 671 [RFC3545] Koren, T., S. Casner, J. Geevarghese, B. Thompson, P. 672 Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High 673 Delay, Packet Loss and Reordering", RFC 3545, Jul. 2003. 675 [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson, Ed., G. 676 Fairhurst, Ed., "The Lightweight User Datagram Protocol 677 (UDP-Lite)", RFC 3828, Jul. 2004. 679 [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet 680 Protocol", RFC 4301, Dec. 2005. 682 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, Dec. 2005. 684 [RFC4443] Conta, A., S. Deering, M. Gupta (Ed.), "Internet Control 685 Message Protocol (ICMPv6) for the Internet Protocol Version 686 6 (IPv6) Specification", RFC 4443, March. 2006. 688 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 689 RFC 4960, Sep. 2007. 691 [RFC4963] Heffner, J., M. Mathis, B. Chandler, "IPv4 Reassembly 692 Errors at High Data Rates," RFC 4963, Jul. 2007. 694 [RFC5225] Pelletier, G., K. Sandlund, "RObust Header Compression 695 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP- 696 Lite", RFC 5225, Apr. 2008. 698 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 699 Adaptation Layer (SEAL)", RFC 5320, Feb. 2010. 701 [RFC6219] Li, X., C. Bao, M. Chen, H. Zhang, J. Wu, "The China 702 Education and Research Network (CERNET) IVI Translation 703 Design and Deployment for the IPv4/IPv6 Coexistence and 704 Transition", RFC 6219, May 2011. 706 14. Acknowledgments 708 This document was inspired by of numerous discussions among the 709 authors, Jari Arkko, Lars Eggert, Dino Farinacci, and Fred Templin, 710 as well as members participating in the Internet Area Working Group. 711 Detailed feedback was provided by Gorry Fairhurst, Brian Haberman, 712 Ted Hardie, Mike Heard, Erik Nordmark, Carlos Pignataro, and Dan 713 Wing. This document originated as an Independent Stream draft co- 714 authored by Matt Mathis, PSC, and his contributions are greatly 715 appreciated. 717 This document was prepared using 2-Word-v2.0.template.dot. 719 Author's Address 721 Joe Touch 722 USC/ISI 723 4676 Admiralty Way 724 Marina del Rey, CA 90292-6695 725 U.S.A. 727 Phone: +1 (310) 448-9151 728 Email: touch@isi.edu