idnits 2.17.1 draft-ietf-intarea-ipv4-id-update-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 : ---------------------------------------------------------------------------- == 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 (September 14, 2011) is 4608 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) == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-12 -- 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 (~~), 3 warnings (==), 8 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 September 14, 2011 4 Intended status: Proposed Standard 5 Expires: March 2012 7 Updated Specification of the IPv4 ID Field 8 draft-ietf-intarea-ipv4-id-update-03.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 March 14, 2012. 45 Copyright Notice 47 Copyright (c) 2011 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 on all datagrams. If enforced, this 65 uniqueness requirement would limit all connections to 6.4 Mbps. 66 Because this is obviously not the case, it is clear that existing 67 systems violate the current specification. This document updates the 68 specification of the IPv4 ID field in RFC791, RFC1122, and RFC2003 to 69 more closely reflect current practice and to more closely match IPv6 70 so that the field is defined only when a datagram is actually 71 fragmented. It also discusses the impact of these changes on how 72 datagrams are used. 74 Table of Contents 76 1. Introduction...................................................3 77 2. Conventions used in this document..............................3 78 3. The IPv4 ID Field..............................................3 79 4. Uses of the IPv4 ID Field......................................4 80 5. Background on IPv4 ID Reassembly Issues........................5 81 6. Updates to the IPv4 ID Specification...........................6 82 6.1. IPv4 ID Used Only for Fragmentation.......................7 83 6.2. Encourage Safe IPv4 ID Use................................8 84 6.3. IPv4 ID Requirements That Persist.........................8 85 7. Impact on Datagram Use.........................................9 86 8. Updates to Existing Standards.................................10 87 8.1. Updates to RFC 791.......................................10 88 8.2. Updates to RFC 1122......................................10 89 8.3. Updates to RFC 2003......................................11 90 9. Impact on NATs/ASMs, Rewriting Devices, and Tunnel Ingresses..11 91 10. Impact on Header Compression.................................13 92 11. Security Considerations......................................13 93 12. IANA Considerations..........................................13 94 13. References...................................................14 95 13.1. Normative References....................................14 96 13.2. Informative References..................................14 97 14. Acknowledgments..............................................15 99 1. Introduction 101 In IPv4, the Identification (ID) field is a 16-bit value that is 102 unique for every datagram for a given source address, destination 103 address, and protocol, such that it does not repeat within the 104 Maximum Segment Lifetime (MSL) [RFC791][RFC1122]. As currently 105 specified, all datagrams between a source and destination of a given 106 protocol must have unique IPv4 ID values over a period of this MSL, 107 which is typically interpreted as two minutes (120 seconds). This 108 uniqueness is currently specified as for all datagrams, regardless of 109 fragmentation settings. 111 The uniqueness of the IPv4 ID is a known problem for high speed 112 devices; if strictly enforced, it would limit the speed of a single 113 protocol between two endpoints to 6.4 Mbps for typical MTUs of 1500 114 bytes [RFC4963]. It is common for a single protocol to operate far in 115 excess of these rates, which strongly indicates that the uniqueness 116 of the IPv4 ID as specified is already moot. 118 This document updates the specification of the IPv4 ID field to more 119 closely reflect current practice, and to include considerations taken 120 into account during the specification of the similar field in IPv6. 122 2. Conventions used in this document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC-2119 [RFC2119]. 128 In this document, the characters ">>" proceeding an indented line(s) 129 indicates a requirement using the key words listed above. This 130 convention aids reviewers in quickly identifying or finding this 131 document's explicit requirements. 133 3. The IPv4 ID Field 135 IP supports datagram fragmentation, where large datagrams are split 136 into smaller components to traverse links with limited maximum 137 transmission units (MTUs). Fragments are indicated in different ways 138 in IPv4 and IPv6: 140 o In IPv4, fragments are indicated using four fields of the basic 141 header: Identification (ID), Fragment Offset, a "Don't Fragment" 142 flag (DF), and a "More Fragments" flag (MF) [RFC791] 144 o In IPv6, fragments are indicated in an extension header that 145 includes an ID, Fragment Offset, and MF flag similar to their 146 counterparts in IPv4 [RFC2460] 148 IPv4 and IPv6 fragmentation differs in a few important ways. IPv6 149 fragmentation occurs only at the source, so a DF bit is not needed to 150 prevent downstream devices from initiating fragmentation (i.e., IPv6 151 always acts as if DF=1). The IPv6 fragment header is present only 152 when a datagram has been fragmented, so the ID field is not present 153 for non-fragmented datagrams, and thus is meaningful only for 154 fragments. Finally, the IPv6 ID field is 32 bits, and required unique 155 per source/destination address pair for IPv6, whereas for IPv4 it is 156 only 16 bits and required unique per source/destination/protocol 157 triple. 159 This document focuses on the IPv4 ID field issues, because in IPv6 160 the field is larger and present only in fragments. 162 4. Uses of the IPv4 ID Field 164 The IPv4 ID field was originally intended for fragmentation and 165 reassembly [RFC791]. Within a given source address, destination 166 address, and protocol, fragments of an original datagram are matched 167 based on their IPv4 ID. This requires that IDs are unique within the 168 address/protocol triple when fragmentation is possible (e.g., DF=0) 169 or when it has already occurred (e.g., frag_offset>0 or MF=1). 171 The IPv4 ID field can be useful for other purposes. The field has 172 been suggested as a way to detect and remove duplicate datagrams, 173 e.g., at congested routers, although this has been noted and no 174 current operational deployments are known (see Sec. 3.2.1.5 of 175 [RFC1122]; it is proposed experimentally in Simplified Multicast 176 Forwarding [Ma11]). It can similarly be used at end hosts to reduce 177 the impact of duplication on higher-layer protocols (e.g., additional 178 processing in TCP, or the need for application-layer duplicate 179 suppression in UDP). 181 The IPv4 ID field can also be used to validate payloads of ICMP 182 responses as matching the originally transmitted datagram at a host. 183 In this case, the ICMP payload - an IP datagram prefix - is matched 184 against a cache of recently transmitted IP headers to check that the 185 received ICMP reflects a transmitted datagram. At a tunnel ingress, 186 the IPv4 ID enables returning ICMP messages to be matched to a cache 187 of recently transmitted datagrams, to support ICMP relaying, with 188 similar challenges. This is a variant of a method described in Sec. 5 189 of RFC 2003 [RFC2003]. 191 Uses of the IPv4 ID field beyond fragmentation and reassembly require 192 that the IPv4 ID be unique across all datagrams, not only when 193 fragmentation is enabled. This document deprecates all such non- 194 fragmentation uses. 196 5. Background on IPv4 ID Reassembly Issues 198 The following is a summary of issues with IPv4 fragment reassembly in 199 high speed environments raised previously [RFC4963]. Readers are 200 encouraged to consult RFC 4963 for a more detailed discussion of 201 these issues. 203 With the maximum IPv4 datagram size of 64KB, a 16-bit ID field that 204 does not repeat within 120 seconds means that the aggregate of all 205 TCP connections of a given protocol between two endpoints is limited 206 to roughly 286 Mbps; at a more typical MTU of 1500 bytes, this speed 207 drops to 6.4 Mbps [RFC4963]. This limit currently applies for all 208 IPv4 datagrams within a single protocol (i.e., the IPv4 protocol 209 field) between two IP addresses, regardless of whether fragmentation 210 is enabled or inhibited, and whether a datagram is fragmented or not. 212 IPv6, even at typical MTUs, is capable of 18.7 Tbps with 213 fragmentation between two endpoints as an aggregate across all 214 protocols, due to the larger 32-bit ID field (and the fact that the 215 IPv6 next-header field, the equivalent of the IPv4 protocol field, is 216 not considered in differentiating fragments). When fragmentation is 217 not used the field is absent, and in that case IPv6 speeds are not 218 limited by the ID field uniqueness. 220 Note also that 120 seconds is only an estimate on the maximum 221 datagram lifetime. It is loosely based on half maximum value of the 222 IP TTL field (255), measured in seconds, because the TTL is 223 decremented not only for each hop, but also for each second a 224 datagram is held at a router (as implied in [RFC791]). Network delays 225 are incurred in other ways, e.g., satellite links, which can add 226 seconds of delay even though the TTL is often not decremented by a 227 corresponding amount. There is thus no enforcement mechanism to 228 ensure that datagrams older than 120 seconds are discarded. 230 Wireless Internet devices are frequently connected at speeds over 54 231 Mbps, and wired links of 1 Gbps have been the default for several 232 years. Although many end-to-end transport paths are congestion 233 limited, these devices easily achieve 100+ Mbps application-layer 234 throughput over LANs (e.g., disk-to-disk file transfer rates), and 235 numerous throughput demonstrations have been performed with COTS 236 systems over wide-area paths at these speeds for over a decade. This 237 strongly suggests that IPv4 ID uniqueness has been moot for a long 238 time. 240 6. Updates to the IPv4 ID Specification 242 This document updates the specification of the IPv4 ID field in three 243 distinct ways, as discussed in subsequent subsections: 245 o Use the IPv4 ID field only for fragmentation 247 o Avoiding a performance impact when the IPv4 ID field is used 249 o Encourage safe operation when the IPv4 ID field is used 251 There are two kinds of datagrams used in the following discussion, 252 named as follows: 254 o Atomic datagrams: datagrams not yet having been fragmented (MF=0 255 and fragment offset=0) and for which further fragmentation has 256 been inhibited (DF=1), i.e., as a C-code expression: 258 (DF==1)&&(MF==0)&&(frag_offset==0) 260 o Non-atomic datagrams: datagrams which have either already been 261 fragmented, i.e.: 263 (MF=1)||(frag_offset>0) 265 or for which fragmentation remains possible: 267 (DF=0) 269 I.e., non-atomic datagrams can be expressed in two equivalent 270 tests: 272 (DF==0)||(MF==1)||(frag_offset>0) 274 which can also be expressed as follows, using DeMorgan's Law and 275 other identities: 277 ~((DF==1)&&(MF==0)&&(frag_offset==0)) 279 Note that this final expression is the same as "not(atomic)". 281 6.1. IPv4 ID Used Only for Fragmentation 283 Although RFC1122 suggests the IPv4 ID field has other uses, and it is 284 currently being considered for the experimental Simplfied Mulitcast 285 Forwarding (SMF) protocol [Ma11], this document asserts that this 286 field is defined only for fragmentation and reassembly: 288 o >> IPv4 ID field MUST NOT be used for purposes other than 289 fragmentation and reassembly. 291 [Note that SMF includes non-ID duplicate packet detection for cases 292 where the ID field is absent (IPv6), and already defines these for 293 IPv4, where it should be preferred to ID-based duplicate detection 294 for atomic datagrams if this document proceeds.] 296 In atomic datagrams, the IPv4 ID field has no meaning, and thus can 297 be set to an arbitrary value, i.e., the requirement for non-repeating 298 IDs within the address/protocol triple is no longer required for 299 atomic datagrams: 301 o >> Originating sources MAY set the IPv4 ID field of atomic 302 datagrams to any value. 304 Second, all network nodes, whether at intermediate routers, 305 destination hosts, or other devices (e.g., NATs and other address 306 sharing mechanisms, firewalls, tunnel egresses), cannot rely on the 307 field: 309 o >> All devices that examine IPv4 headers MUST ignore the IPv4 ID 310 field of atomic datagrams. 312 The IPv4 ID field is thus meaningful only for non-atomic datagrams - 313 datagrams that have either already been fragmented, or those for 314 which fragmentation remains permitted. Atomic datagrams are detected 315 by their DF, MF, and fragmentation offset fields as explained in 316 Section 6, because such a test is completely backward compatible; 317 this document thus does not reserve any IPv4 ID values, including 0, 318 as distinguished. 320 Deprecating the use of the IPv4 ID field for non-reassembly uses 321 should have little - if any - impact. IPv4 IDs are already frequently 322 repeated, e.g., over even moderately fast connections. Duplicate 323 suppression was only suggested [RFC1122], and no impacts of IPv4 ID 324 reuse have been noted. Routers are not required to issue ICMPs on any 325 particular timescale, and so IPv4 ID repetition should not have been 326 used for validation, and again repetition occurs and probably could 327 have been noticed [RFC1812]. ICMP relaying at tunnel ingresses is 328 specified to use soft state rather than a datagram cache, and should 329 have been noted if the latter for similar reasons [RFC2003]. 331 6.2. Encourage Safe IPv4 ID Use 333 This document makes further changes to the specification of the IPv4 334 ID field and its use to encourage its safe use as corollary 335 requirements changes as follows. 337 RFC 1122 discusses that TCP retransmits a segment it may be possible 338 to reuse the IPv4 ID (see Section 8.2). This can make it difficult 339 for a source to avoid IPv4 ID repetition for received fragments. RFC 340 1122 concludes that this behavior "is not useful"; this document 341 formalizes that conclusion as follows: 343 o >> The IPv4 ID of non-atomic datagrams MUST NOT be reused when 344 sending a copy of an earlier non-atomic datagram. 346 RFC 1122 also suggests that fragments can overlap [RFC1122]. Such 347 overlap can occur if successive retransmissions are fragmented in 348 different ways but the same reassembly IPv4 ID. This overlap is noted 349 as the result of reusing IPv4 IDs when retransmitting datagrams, 350 which this document deprecates. However, it is also the result of in- 351 network packet duplication, which can still occur. As a result this 352 document does not change the need to support overlapping fragments. 354 6.3. IPv4 ID Requirements That Persist 356 This document does not relax the IPv4 ID field uniqueness 357 requirements of [RFC791] for non-atomic datagrams, i.e.: 359 o >> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID 360 values within one MSL for a given source address/destination 361 address/protocol triple. 363 Such sources include originating hosts, tunnel ingresses, and NATs 364 (including other address sharing mechanisms) (see Section 9). 366 This document does not relax the requirement that all network devices 367 honor the DF bit, i.e.: 369 o >> IPv4 datagrams whose DF=1 MUST NOT be fragmented. 371 o >> IPv4 datagram transit devices MUST NOT clear the DF bit. 373 In specific, DF=1 prevents fragmenting datagrams that are integral. 374 DF=1 also prevents further fragmenting received fragments. 375 Fragmentation, either of an unfragmented datagram or of fragments, is 376 current permitted only where DF=0 in the original emitted datagram, 377 and this document does not change that requirement. 379 7. Impact on Datagram Use 381 The following is a summary of the recommendations that are the result 382 of the previous changes to the IPv4 ID field specification. 384 Because atomic datagrams can use arbitrary IPv4 ID values, the ID 385 field no longer imposes a performance impact in those cases. However, 386 the performance impact remains for non-atomic datagrams. As a result: 388 o >> Sources of non-atomic IPv4 datagrams MUST rate-limit their 389 output to comply with the ID uniqueness requirements. 391 Such sources include, in particular, DNS over UDP [RFC2671]. 393 Because there is no strict definition of the MSL, reassembly hazards 394 exist regardless of the IPv4 ID reuse interval or the reassembly 395 timeout. As a result: 397 o >> Higher layer protocols SHOULD verify the integrity of IPv4 398 datagrams, e.g., using a checksum or hash that can detect 399 reassembly errors (the UDP checksum is weak in this regard, but 400 better than nothing), as in SEAL [RFC5320]. 402 Additional integrity checks can be employed using tunnels, as in 403 SEAL, IPsec, or SCTP [RFC4301][RFC4960][RFC5320]. Such checks can 404 avoid the reassembly hazards that can occur when using UDP and TCP 405 checksums [RFC4963], or when using partial checksums as in UDP-Lite 406 [RFC3828]. Because such integrity checks can avoid the impact of 407 reassembly errors: 409 o >> Sources of non-atomic IPv4 datagrams using strong integrity 410 checks MAY reuse the ID within MSL values smaller than is typical. 412 Note, however, that such more frequent reuse can still result in 413 corrupted reassembly and poor throughput, although it would not 414 propagate reassembly errors to higher layer protocols. 416 8. Updates to Existing Standards 418 The following sections address the specific changes to existing 419 protocols indicated by this document. 421 8.1. Updates to RFC 791 423 RFC 791 states that: 425 The originating protocol module of an internet datagram sets the 426 identification field to a value that must be unique for that 427 source-destination pair and protocol for the time the datagram 428 will be active in the internet system. 430 And later that: 432 Thus, the sender must choose the Identifier to be unique for this 433 source, destination pair and protocol for the time the datagram 434 (or any fragment of it) could be alive in the internet. 436 It seems then that a sending protocol module needs to keep a table 437 of Identifiers, one entry for each destination it has communicated 438 with in the last maximum datagram lifetime for the internet. 440 However, since the Identifier field allows 65,536 different 441 values, some host may be able to simply use unique identifiers 442 independent of destination. 444 It is appropriate for some higher level protocols to choose the 445 identifier. For example, TCP protocol modules may retransmit an 446 identical TCP segment, and the probability for correct reception 447 would be enhanced if the retransmission carried the same 448 identifier as the original transmission since fragments of either 449 datagram could be used to construct a correct TCP segment. 451 This document changes RFC 791 as follows: 453 o IPv4 ID uniqueness applies to only non-atomic datagrams. 455 o Non-atomic IPv4 datagrams retransmitted by higher level protocols 456 are no longer permitted to reuse the ID value. 458 8.2. Updates to RFC 1122 460 RFC 1122 states that: 462 3.2.1.5 Identification: RFC-791 Section 3.2 463 When sending an identical copy of an earlier datagram, a 464 host MAY optionally retain the same Identification field in 465 the copy. 467 DISCUSSION: 469 Some Internet protocol experts have maintained that when a 470 host sends an identical copy of an earlier datagram, the new 471 copy should contain the same Identification value as the 472 original. There are two suggested advantages: (1) if the 473 datagrams are fragmented and some of the fragments are lost, 474 the receiver may be able to reconstruct a complete datagram 475 from fragments of the original and the copies; (2) a 476 congested gateway might use the IP Identification field (and 477 Fragment Offset) to discard duplicate datagrams from the 478 queue. 480 This document changes RFC 1122 as follows: 482 o The IPv4 ID field is no longer permitted for duplicate detection. 484 o The IPv4 ID field is no longer repeatable for higher level 485 protocol retransmission. 487 o IPv4 datagram fragments no longer are permitted to overlap. 489 8.3. Updates to RFC 2003 491 This document updates how IPv4-in-IPv4 tunnels create IPv4 ID values 492 for the IPv4 outer header [RFC2003], but only in the same way as for 493 any other IPv4 datagram source. 495 9. Impact on NATs/ASMs, Rewriting Devices, and Tunnel Ingresses 497 Network address translators (NATs) and address/port translators 498 (NAPTs) rewrite IP fields, and tunnel ingresses (using IPv4 499 encapsulation) copy and modify some IPv4 fields, so all are 500 considered sources, as do any devices that rewrite any portion of the 501 source address, destination address, protocol, and ID tuple for non- 502 atomic datagrams [RFC3022]. This is also true for other address 503 sharing mechanisms (ASMs), including to include 4rd, IVI, and others 504 in the "A+P" (address plus port) family [Bo11] [De11] [RFC6219]. It 505 is equally true for any other packet rewriting mechanism. As a 506 result, they are subject to all the requirements of any source, as 507 has been noted. 509 NATs/ASMs/rewriters present a particularly challenging situation for 510 fragmentation. Because they overwrite portions of the reassembly 511 tuple in both directions, they can destroy tuple uniqueness and 512 result in a reassembly hazard. Whenever IPv4 source address, 513 destination address, or protocol fields are modified, a 514 NAT/ASM/rewriter needs to ensure that the ID field is generated 515 appropriately, rather than simply copied from the incoming datagram. 516 In specific: 518 o >> Address sharing or rewriting devices MUST ensure that the IPv4 519 ID field of datagrams whose address or protocol are translated 520 comply with requirements as if the datagram were sourced by that 521 device. 523 This compliance means that the IPv4 ID field of non-atomic datagrams 524 translated at a NAT/ASM/rewriter needs to obey the uniqueness 525 requirements of any IPv4 datagram source. Unfortunately, fragments 526 already violate that requirement, as they repeat an IPv4 ID within 527 the MSL for a given source address, destination address, and protocol 528 triple. 530 Such problems with transmitting fragments through NATs/ASMs/rewriters 531 are already known; translation is based on the transport port number, 532 which is present in only the first fragment anyway [RFC3022]. This 533 document underscores the point that not only is reassembly (and 534 possibly subsequent fragmentation) required for translation, it can 535 be used to avoid issues with IPv4 ID uniqueness. 537 Note that NATs/ASMs already need to exercise special care when 538 emitting datagrams on their public side, because merging datagrams 539 from many sources onto a single outgoing source address can result in 540 IPv4 ID collisions. This situation precedes this document, and is not 541 affected by it. It is exacerbated in large-scale, so-called "carrier 542 grade" NATs [Pe11]. 544 Tunnel ingresses act as sources for the outermost header, but tunnels 545 act as routers for the inner headers (i.e., the datagram as arriving 546 at the tunnel ingress). Ingresses can fragment as originating sources 547 of the outer header, because they control the uniqueness of that IPv4 548 ID field. They need to avoid fragmenting the datagram at the inner 549 header, for the same reasons as any intermediate device, as noted 550 elsewhere in this document. 552 10. Impact on Header Compression 554 Header compression algorithms already accommodate various ways in 555 which the IPv4 ID changes between sequential datagrams. Such 556 algorithms currently assume that the IPv4 ID is preserved end-to-end. 558 When compression can assume a nonchanging IPv4 ID, efficiency can be 559 increased. However, when compression assumes a changing ID as a 560 default, having a non-changing ID can make compression less efficient 561 (see footnote 21 of [RFC1144], which is optimized for non-atomic 562 datagrams). This document thus does not recommend whether atomic IPv4 563 datagrams should use nonchanging or changing IDs. 565 11. Security Considerations 567 This document attempts to address the security considerations 568 associated with fragmentation in IPv4 [RFC4459]. 570 When the IPv4 ID is ignored on receipt (e.g., for atomic datagrams), 571 its value becomes unconstrained; that field then can more easily be 572 used as a covert channel. For some atomic datagrams - notably those 573 not protected by IPsec Authentication Header (AH) [RFC4302] - it is 574 now possible, and may be desirable, to rewrite the IPv4 ID field to 575 avoid its use as such a channel. 577 The IPv4 ID also now adds much less entropy of the header of a 578 datagram. The IPv4 ID had previously been unique (for a given 579 source/address pair, and protocol field) within one MSL, although 580 this requirement was not enforced and clearly is typically ignored. 581 IDs of non-atomic datagrams are now required unique only within the 582 expected reordering of fragments, which could substantially reduce 583 the amount of entropy in that field. The IPv4 ID of atomic datagrams 584 is not required unique, and so contributes no entropy to the header. 586 The deprecation of the IPv4 ID field's uniqueness for atomic 587 datagrams can defeat the ability to count devices behind a NAT/ASM 588 [Be02]. This is not intended as a security feature, however. 590 12. IANA Considerations 592 There are no IANA considerations in this document. 594 The RFC Editor should remove this section prior to publication 596 13. References 598 13.1. Normative References 600 [RFC791] Postel, J., "Internet Protocol", RFC 791 / STD 5, September 601 1981. 603 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 604 Communication Layers", RFC 1122 / STD 3, October 1989. 606 [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers", 607 RFC 1812 / STD 4, Jun. 1995. 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", RFC 2119 / BCP 14, March 1997. 612 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 613 October 1996. 615 13.2. Informative References 617 [Be02] Bellovin, S., "A Technique for Counting NATted Hosts", 618 Internet Measurement Conference, Proceedings of the 2nd ACM 619 SIGCOMM Workshop on Internet Measurement, November 2002. 621 [Bo11] Boucadair, M., J. Touch, P. Levis, R. Penno, "Analysis of 622 Solution Candidates to Reveal a Host Identifier in Shared 623 Address Deployments", (work in progress), draft-boucadair- 624 intarea-nat-reveal-analysis, Sept. 2011. 626 [De11] Despres, R. (Ed.), S. Matsushima, T. Murakami, O. Troan, 627 "IPv4 Residual Deployment across IPv6-Service networks 628 (4rd)", (work in progress), draft-despres-intarea-4rd, 629 March 2011. 631 [Ma11] Macker, J. (Ed.), "Simplified Multicast Forwarding," (work 632 in progress), draft-ietf-manet-smf-12, Jul. 2011. 634 [Pe11] Perreault, S., (Ed.), I. Yamagata, S. Miyakawa, A. 635 Nakagawa, H. Ashida, "Common requirements of IP address 636 sharing schemes", (work in progress), draft-ietf-behave- 637 lsn-requirements, March 2011. 639 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, Feb. 640 1990. 642 [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6 643 (IPv6) Specification", RFC 2460, December 1998. 645 [RFC2671] Vixie,P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 646 August 1999. 648 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 649 Address Translator (Traditional NAT)", RFC 3022, January 650 2001. 652 [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson, Ed., G. 653 Fairhurst, Ed., "The Lightweight User Datagram Protocol 654 (UDP-Lite)", RFC 3828, July 2004. 656 [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet 657 Protocol", RFC 4301, Dec. 2005. 659 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, Dec. 2005. 661 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 662 Network Tunneling", RFC 4459, April 2006. 664 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 665 RFC 4960, Sep. 2007. 667 [RFC4963] Heffner, J., M. Mathis, B. Chandler, "IPv4 Reassembly 668 Errors at High Data Rates," RFC 4963, July 2007. 670 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 671 Adaptation Layer (SEAL)", RFC 5320, Feb. 2010. 673 [RFC6219] Li, X., C. Bao, M. Chen, H. Zhang, J. Wu, "The China 674 Education and Research Network (CERNET) IVI Translation 675 Design and Deployment for the IPv4/IPv6 Coexistence and 676 Transition", RFC 6219, May 2011. 678 14. Acknowledgments 680 This document was inspired by of numerous discussions among the 681 authors, Jari Arkko, Lars Eggert, Dino Farinacci, and Fred Templin, 682 as well as members participating in the Internet Area Working Group. 683 Detailed feedback was provided by Carlos Pignataro and Gorry 684 Fairhurst. This document originated as an Independent Stream draft 685 co-authored by Matt Mathis, PSC, and his contributions are greatly 686 appreciated. 688 This document was prepared using 2-Word-v2.0.template.dot. 690 Author's Address 692 Joe Touch 693 USC/ISI 694 4676 Admiralty Way 695 Marina del Rey, CA 90292-6695 696 U.S.A. 698 Phone: +1 (310) 448-9151 699 Email: touch@isi.edu