idnits 2.17.1 draft-ietf-intarea-ipv4-id-update-00.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 mention this, which it should. -- The draft header indicates that this document updates RFC1122, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC791, but the abstract doesn't seem to mention this, which it should. 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 (March 26, 2010) is 5142 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 (-05) exists of draft-nishitani-cgn-03 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- 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 March 26, 2010 4 Intended status: Proposed Standard 5 Expires: September 2010 7 Updated Specification of the IPv4 ID Field 8 draft-ietf-intarea-ipv4-id-update-00.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 September 26, 2010. 45 Copyright Notice 47 Copyright (c) 2010 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 IP packets. 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 IP ID field to more closely reflect current 69 practice and to more closely match IPv6, so that the field is defined 70 only when a packet is actually fragmented and that fragmentation 71 occurs only at originating hosts or their equivalent. When 72 fragmentation occurs, this document recommends that the ID field be 73 unique within the reordering context, rather than an arbitrary, 74 unenforced upper bound on packet lifetime. 76 Table of Contents 78 1. Introduction...................................................3 79 2. Conventions used in this document..............................3 80 3. The IPv4 ID Field..............................................4 81 4. Uses of the IPv4 ID Field......................................4 82 5. Background on IPv4 ID Reassembly Issues........................5 83 6. Updates to the IPv4 ID Specification...........................6 84 6.1. IPv4 ID Used Only for Fragmentation.......................6 85 6.2. Avoiding IPv4 ID Repetition and Its Impacts...............7 86 6.3. Encourage Safe ID Use.....................................8 87 7. Updates to Existing Standards..................................9 88 7.1. Updates to RFC 791........................................9 89 7.2. Updates to RFC 1122......................................10 90 7.3. Updates to RFC 1812......................................11 91 7.4. Updates to RFC 2003......................................11 92 8. Impacts on NATs and Tunnel Ingresses..........................11 93 9. Impact on Header Compression..................................12 94 10. Transitioning to This Update.................................12 95 11. Security Considerations......................................13 96 12. IANA Considerations..........................................13 97 13. References...................................................14 98 13.1. Normative References....................................14 99 13.2. Informative References..................................14 100 14. Acknowledgments..............................................15 102 1. Introduction 104 In IPv4, the IP Identification (ID) field is a 16-bit value that is 105 unique for every packet for a given source address, destination 106 address, and protocol, such that it does not repeat within the 107 Maximum Segment Lifetime (MSL) [RFC791][RFC1122]. All packets between 108 a source and destination of a given protocol must have unique ID 109 values over a period of an MSL, which is typically interpreted as two 110 minutes (120 seconds). This uniqueness is currently specified as for 111 all packets, regardless of fragmentation settings. 113 The uniqueness of the IP ID is a known problem for high speed 114 devices, because it limits the speed of a single protocol between two 115 endpoints to 6.4 Mbps for typical MTUs of 1500 bytes [RFC4963]. This 116 strongly indicates that the uniqueness of the IPv4 ID is moot, as has 117 already been noted. 119 This document updates the specification of the IP ID field to more 120 closely reflect current practice, and to more closely match IPv6, in 121 which the field is defined only when a packet is actually fragmented 122 and in which fragmentation occurs only at the source. It also updates 123 the recommended uniqueness interval to support the impact of 124 reordering on reassembly, rather than using an arbitrary and 125 unenforceable packet lifetime. 127 2. Conventions used in this document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC-2119 [RFC2119]. 133 In this document, the characters ">>" proceeding an indented line(s) 134 indicates a requirement using the key words listed above. This 135 convention aids reviewers in quickly identifying or finding this 136 document's explicit requirements. 138 3. The IPv4 ID Field 140 IP supports packet fragmentation, where large packets are split into 141 smaller components to traverse links with limited maximum 142 transmission units (MTUs). Fragments are indicated in different ways 143 in IPv4 and IPv6: 145 o In IPv4, the header contains four fields: Identification (ID), 146 Fragment Offset, a "Don't Fragment" flag (DF), and a "More 147 Fragments" flag (MF) [RFC791] 149 o In IPv6, fragments are indicated in an extension header that 150 includes an ID, Fragment Offset, and MF flag similar to their 151 counterparts in IPv4 [RFC2460] 153 IPv4 and IPv6 fragmentation differs in a few important ways. IPv6 154 fragmentation occurs only at the source, so a DF bit is not needed to 155 prevent downstream devices from initiating fragmentation. The IPv6 156 fragment header is present only when a packet has been fragmented, so 157 the ID field is not present for non-fragmented packets, and thus is 158 meaningful only for fragments. Finally, the ID field is 32 bits, and 159 unique per source/destination address pair for IPv6, whereas for IPv4 160 it is only 16 bits and unique per source/destination/protocol triple. 162 This document focuses on the IPv4 ID field issues, because in IPv6 163 the field is larger and present only in fragments. 165 4. Uses of the IPv4 ID Field 167 The IPv4 ID field was originally intended for fragmentation and 168 reassembly [RFC791]. Within a given source address, destination 169 address, and protocol, fragments of an original packet are matched 170 based on their IP ID. This requires that IDs are unique within the 171 address/protocol triple when fragmentation is possible (e.g., DF=0). 173 The ID field has been discussed as useful in other ways. It can be 174 used to detect and discard duplicate packets, e.g., at congested 175 routers (see Sec. 3.2.1.5 of [RFC1122]). 177 The ID field can also be useful for duplicate avoidance and ICMP 178 validation. The field can be used at routers or receiving hosts to 179 remove duplicate packets. The IP ID field can be used to validate 180 payloads of ICMP responses as matching the originally transmitted 181 packet at a host [RFC4963]. At a tunnel ingress, the ID enables 182 returning ICMP messages to be matched to a cache of recently 183 transmitted packets, to support ICMP relaying [RFC2003]. 185 These latter uses require that the IP ID be unique across all 186 packets, not only when fragmentation is enabled. This document 187 deprecates all such non-fragmentation uses. 189 5. Background on IPv4 ID Reassembly Issues 191 The following is a summary of issues with IPv4 fragment reassembly in 192 high speed environments raised previously [RFC4963]. Readers are 193 encouraged to consult RFC 4963 for a more detailed discussion of 194 these issues. 196 With the maximum IPv4 packet size of 64KB, a 16-bit ID field that 197 does not repeat within 120 seconds means that the sum of all TCP 198 connections of a given protocol between two endpoints is limited to 199 roughly 286 Mbps; at a more typical MTU of 1500 bytes, this speed 200 drops to 6.4 Mbps [RFC4963]. This limit currently applies for all 201 IPv4 packets, regardless of whether fragmentation is enabled or 202 inhibited, and whether a packet is fragmented or not. 204 IPv6, even at typical MTUs, is capable of 18.7 Tbps when fragments 205 are present, due to the larger 32-bit ID field. When fragmentation is 206 not used the field is absent, and so IPv6 speeds are not limited by 207 the ID field uniqueness. 209 Note also that 120 seconds is only an estimate on the maximum packet 210 lifetime. It is loosely based on half maximum value of the IP TTL 211 field, which is represents 0-255 seconds, although it must be 212 decremented by 1 second for each router on a path even when held for 213 less than a second [RFC791]. Network delays are incurred in other 214 ways, e.g., satellite links, which can add seconds of delay even 215 though the TTL is not affected. There is no enforcement mechanism to 216 ensure that packets older than 120 seconds are discarded. 218 Wireless Internet devices are frequently connected at speeds over 54 219 Mbps, and wired links of 1 Gbps have been the default for several 220 years. Although many end-to-end transport paths are congestion 221 limited, these devices easily achieve 100+ Mbps application-layer 222 throughput over LANs (e.g., disk-to-disk file transfer rates), and 223 numerous throughput demonstrations have been performed with COTS 224 systems at these speeds for over a decade. This strongly suggests 225 that IPv4 ID uniqueness has been moot for a long time. 227 6. Updates to the IPv4 ID Specification 229 This document updates the specification of the IPv4 ID field in three 230 distinct ways, as discussed in subsequent subsections: 232 o Use the ID field only for fragmentation 234 o Avoid ID repetition and its impacts 236 o Encourage more safe use of the ID field 238 There are two kinds of packets used in the following discussion: 240 Atomic packets: packets not yet having been fragmented (MF=0 and 241 fragment offset=0) and for which further fragmentation has been 242 inhibited (DF=1), i.e., as a C-code expression: 244 (DF==1)&&(MF==0)&&(frag_offset==0) 246 o Non-atomic packets: packets which have either already been 247 fragmented, i.e.: 249 (MF=1)||(frag_offset>0) 251 or for which fragmentation remains possible (DF=0), i.e.: 253 (DF==0)||(MF==1)||(frag_offset>0) 255 or (equivalently): 257 ~((DF==1)&&(MF==0)&&(frag_offset==0)) 259 6.1. IPv4 ID Used Only for Fragmentation 261 Although at least one document suggests the ID field has other uses, 262 we assert here that the ID field is defined only for fragmentation 263 and reassembly. 265 o >> The IPv4 ID field of MUST be ignored except for packet 266 reassembly. 268 Such devices typically include receiving hosts and tunnel egresses, 269 but may include any intermediate device that reassembles a packet, 270 such as a firewall or NAT. The ID field is thus meaningful only for 271 non-atomic packets that have actually been fragmented, either at the 272 source or elsewhere along the path, and have not been reassembled 273 before being examined. In atomic packets, the ID field has no 274 meaning, and thus its values are always to be ignored. Atomic packets 275 are detected by their DF, MF, and fragmentation offset fields as 276 defined in Section 6, because such a test is completely backward 277 compatible; this document thus does not reserve any ID values, 278 including 0, as distinguished. 280 Note that this excludes some current practices that use the ID field 281 and the remainder of the IP header as a unique tag. This tag has been 282 suggested as a way to detect and remove duplicate packets, e.g., at 283 congested routers, although this has been noted and no current 284 deployments are known [RFC1122]. Some hosts use this tag to validate 285 received ICMPs, in which the ICMP payload - an IP packet prefix - is 286 matched against a cache of recently transmitted IP headers. This 287 ensures that the received ICMP reflects a transmitted packet, though 288 it does not prevent spoofing of ICMPs for attackers that can see 289 those packets, and like ID reuse will cause problems at high packet 290 rates. A similar sort of matching can be used in tunnels, to enable 291 ICMP relaying at the tunnel ingress, with similar challenges 292 [RFC2003]. 294 Deprecating the use of the IPv4 ID field for these non-reassembly 295 uses should have little - if any - impact. IPv4 IDs are already 296 frequently repeated, e.g., over even moderately fast connections. 297 Duplicate suppression was only suggested, and no impacts of ID reuse 298 have been noted. Routers are not required to issue ICMPs on any 299 particular timescale, and so ID repetition should not have been used 300 for validation, and again repetition occurs and probably could have 301 been noticed [RFC1812]. ICMP relaying at tunnel ingresses is 302 specified to use soft state rather than a packet cache, and should 303 have been noted if the latter for similar reasons [RFC2003]. 305 6.2. Avoiding IPv4 ID Repetition and Its Impacts 307 This document specifies that IPv4 be modified to more closely match 308 IPv6's fragmentation constraints, to permit fragmentation only at 309 devices that control the uniqueness of the IP ID field, e.g., 310 sources, tunnel ingresses (for the outer header), and packets emitted 311 from a NAT to its public side (see Section 8). 313 o >> Sources SHOULD set DF=1. 315 o >> IPv4 fragmentation SHOULD be limited to the originating source, 316 even when the DF field allows it. 318 Keep in mind that a source is any device that uses one of its 319 assigned IP addresses as a source IP address in emitted packets. This 320 includes hosts, routers when originating packets, packets emitted 321 from NATs (see Section 8), and tunnel ingresses. 323 It may not be possible for sources to know whether all of the above 324 specifications are satisfied. As a result, we recommend that: 326 o >> Sources unable to meet the non-repeating IP ID requirement 327 above MUST NOT emit non-atomic packets. 329 In other words, such sources can emit only non-fragmented packets 330 where DF has been set. Such sources can repeat the ID field for 331 atomic packets, as it is intended to be ignored. 333 Sources emitting non-atomic IPv4 packets need to set the ID field 334 sufficient to support reassembly, and encourages the use of stronger 335 transport layer validation where possible. Uniqueness over a two 336 minute interval may be excessive to support reassembly in some 337 environments, and is clearly already being ignored. 339 o >> Sources emitting non-atomic IPv4 packets SHOULD NOT repeat ID 340 field values within a given source IP, destination IP, and 341 protocol tuple over the period that fragment reordering would 342 affect reassembly. 344 It is impractical to assert "MUST NOT" here, because there is no 345 strict enforcement on packet lifetime and because sources may not be 346 able to determine the reordering period. 348 o >> Sources that cannot ensure safe IPv4 ID generation and that 349 allow DF=0 SHOULD employ integrity checks that would detect mis- 350 reassembled fragments, e.g, as in SEAL [RFC5320]. Applications 351 SHOULD NOT use UDP without checksums [RFC793], and SHOULD be very 352 careful in their use of UDP-Lite [RFC3828] in such environments. 354 Additional integrity checks can be employed using tunnels, as in 355 SEAL, IPsec, or SCTP [RFC4301][RFC4960][RFC5320]. Such checks can 356 avoid the reassembly hazards that can occur when using UDP and TCP 357 checksums [RFC4963]. 359 6.3. Encourage Safe ID Use 361 This document makes further changes to the specification of the IPv4 362 ID field and its use to encourage its safe use as follows. 364 RFC 1122 discusses that TCP retransmits a segment it may be possible 365 to reuse the IP ID (see Section 7.2). This can make it difficult for 366 a source to avoid ID repetition for received fragments. RFC 1122 367 concludes that this behavior "is not useful"; this document 368 formalizes that conclusion as follows: 370 o >> The IP ID MUST NOT be reused when sending a copy of an earlier 371 non-ATOMIC packet. 373 RFC 1122 also suggests that fragments can overlap [RFC1122]. Such 374 overlap can occur if successive retransmissions use different 375 packetizing but the same reassembly Id. 377 This overlap is noted as the result of reusing IDs when 378 retransmitting packets, which this document deprecates. Overlapping 379 fragments are themselves a hazard [RFC4963]. As a result: 381 o >> Overlapping packets MUST be silently ignored during reassembly. 383 7. Updates to Existing Standards 385 The following sections address the specific changes to existing 386 protocols indicated by this document. 388 7.1. Updates to RFC 791 390 RFC 791 states that: 392 The originating protocol module of an internet datagram sets the 393 identification field to a value that must be unique for that 394 source-destination pair and protocol for the time the datagram 395 will be active in the internet system. 397 And later that: 399 Thus, the sender must choose the Identifier to be unique for this 400 source, destination pair and protocol for the time the datagram 401 (or any fragment of it) could be alive in the internet. 403 It seems then that a sending protocol module needs to keep a table 404 of Identifiers, one entry for each destination it has communicated 405 with in the last maximum packet lifetime for the internet. 407 However, since the Identifier field allows 65,536 different 408 values, some host may be able to simply use unique identifiers 409 independent of destination. 411 It is appropriate for some higher level protocols to choose the 412 identifier. For example, TCP protocol modules may retransmit an 413 identical TCP segment, and the probability for correct reception 414 would be enhanced if the retransmission carried the same 415 identifier as the original transmission since fragments of either 416 datagram could be used to construct a correct TCP segment. 418 This document changes RFC 791 as follows: 420 o >> The IP ID is not defined if the packet (datagram) is atomic. IP 421 packet sources MAY use any value as ID; all such values MUST BE 422 ignored on examination at intermediate nodes and destinations. 424 o >> The IP ID of non-atomic packets MUST BE unique for the time 425 where fragments are expected to overlap. 427 o >> Hosts SHOULD emit only atomic packets (i.e., not fragmented at 428 the source, and with DF=1). 430 We do not expect that it will be useful to involve higher-level 431 protocols in determining ID values. 433 7.2. Updates to RFC 1122 435 RFC 1122 states that: 437 3.2.1.5 Identification: RFC-791 Section 3.2 439 When sending an identical copy of an earlier datagram, a 440 host MAY optionally retain the same Identification field in 441 the copy. 443 DISCUSSION: 445 Some Internet protocol experts have maintained that when a 446 host sends an identical copy of an earlier datagram, the new 447 copy should contain the same Identification value as the 448 original. There are two suggested advantages: (1) if the 449 datagrams are fragmented and some of the fragments are lost, 450 the receiver may be able to reconstruct a complete datagram 451 from fragments of the original and the copies; (2) a 452 congested gateway might use the IP Identification field (and 453 Fragment Offset) to discard duplicate datagrams from the 454 queue. 456 This document changes RFC 1122 as follows: 458 o >> The IP ID field MUST NOT be used for duplicate detection or 459 removal. 461 o >> IP ID values MUST NOT be repeated when packets are 462 retransmitted. 464 o >> IP packet fragments MUST NOT overlap. 466 7.3. Updates to RFC 1812 468 There are no updates to RFC1812. 470 7.4. Updates to RFC 2003 472 RFC 2003 states that: 474 Identification, Flags, Fragment Offset 476 These three fields are set as specified in [RFC791]. 477 However, if the "Don't Fragment" bit is set in the inner IP 478 header, it MUST be set in the outer IP header; if the "Don't 479 Fragment" bit is not set in the inner IP header, it MAY be 480 set in the outer IP header, as described in Section 5.1. 482 This document changes RFC 2003 as follows: 484 o >> IP-in-IP tunnels SHOULD emit only atomic packets. 486 Note that this recommendation applies to all tunnels, but the focus 487 of this document is IPv4 requirements, so its explicit requirements 488 focus on IPv4 cases. 490 8. Impacts on NATs and Tunnel Ingresses 492 Network address translators (NATs) and address/port translators 493 (NAPTs) rewrite IP fields, and tunnel ingresses (using IP 494 encapsulation) copy and modify some IP fields, so all are considered 495 sources, as do any devices that rewrite any portion of the IP source, 496 IP destination, IP protocol, and IP ID tuple for non-atomic packets 497 [RFC3022]. As a result, they are subject to all the requirements of 498 any source, as has been noted. 500 NATs present a particularly challenging situation for fragmentation. 501 Because NATs overwrite portions of the reassembly tuple in both 502 directions, they can destroy tuple uniqueness and result in a 503 reassembly hazard. Not only do NATs need to behave as a source for 504 the purposes of this document, but also: 506 o >> NATs MUST either silently drop fragments or reassemble them 507 before translating and emitting them. 509 Problems with transmitting fragments through NATs are already known; 510 translation is based on the transport port number, which is present 511 in only the first fragment anyway [RFC3022]. This document 512 underscores the point that not only is reassembly (and possibly 513 subsequent fragmentation) required for translation, it is required 514 for IP ID uniqueness. 516 Note that NATs/NAPTs already need to exercise special care when 517 emitting packets on their public side, because merging packets from 518 many sources onto a single outgoing source IP address can result in 519 IP ID collisions. This situation precedes this document, and is not 520 affected by it. It is exacerbated in large-scale, so-called "carrier 521 grade" NATs [Ni09]. 523 Tunnel ingresses act as sources for the outermost header, but tunnels 524 act as routers for the inner headers (i.e., the packet as arriving at 525 the tunnel ingress). Ingresses can fragment as originating sources of 526 the outer header, because they control the uniqueness of that IP ID 527 field. They need to avoid fragmenting the packet at the inner header, 528 for the same reasons as any intermediate device, as noted elsewhere 529 in this document. 531 9. Impact on Header Compression 533 Header compression algorithms already accommodate various ways in 534 which the IP ID changes between sequential packets. Such algorithms 535 already need to preserve the IP ID. This document relaxes that 536 constraint, making preservation optional for most atomic packets as a 537 result: 539 >> Header compression MAY preserve the IP ID of atomic packets that 540 are not protected by IPsec AH [RFC4302]. The IP ID of non-atomic 541 packets, and those of packets protected by IPsec AH MUST be 542 preserved. 544 Note that this can impact the efficiency of header compression in 545 various ways. When compression can assume a nonchanging ID, 546 efficiency can be increased. However, when compression assumes a 547 changing ID as a default, having a non-changing ID can make 548 compression less efficient (see footnote 21 of [RFC1144], which is 549 optimized for non-atomic packets). 551 10. Transitioning to This Update 553 ?? Do we need this transition? 555 ?? Do we want to say when to stop the transition? 556 During the transition period, there may continue to be tunnel 557 ingresses and NATs that fragment even when the DF bit is set, or that 558 validate ICMP payloads based on cached packets. It may be useful to 559 use a small ID space to help detect such behaviors without causing 560 full disruption, as might occur by using a single value when the DF 561 flag is set (e.g., ID=0). 563 As a result, during the transition period, this document recommends 564 that: 566 >> During the transition period, a small ID space SHOULD be used to 567 assist with debugging and detection; such a space SHOULD use the 568 lower bits (i.e., lower 4 bits) of the ID field and clear (i.e., 569 zero) the remaining high order bits. 571 11. Security Considerations 573 This document attempts to address the security considerations 574 associated with fragmentation in IPv4 [RFC4459]. 576 When the IPv4 ID is ignored on receipt (e.g., for atomic packets), 577 its value becomes unconstrained; that field then can more easily be 578 used as a covert channel. For some atomic packets - notably those not 579 protected by IPsec Authentication Header (AH) [RFC4302] - it is 580 possible, and may be desirable, to rewrite the ID field to avoid its 581 use as such a channel. 583 The IP ID also now adds much less entropy of the header of an IP 584 packet. The ID had previously been unique (for a given IP 585 source/address pair, and protocol field) within 2MSL, although this 586 requirement was not enforced and clearly is typically ignored. IDs of 587 non-atomic packets are now required unique only within the expected 588 reordering of fragments, which could substantially reduce the amount 589 of entropy in that field. The IP ID of atomic packets is not required 590 unique, and so contributes no entropy to the header. 592 The deprecation of the ID field's uniqueness for atomic packets can 593 defeat the ability to count devices behind a NAT [Be02]. This is not 594 intended as a security feature, however. 596 12. IANA Considerations 598 There are no IANA considerations in this document. 600 The RFC Editor should remove this section prior to publication 602 13. References 604 13.1. Normative References 606 [RFC791] Postel, J., "Internet Protocol", RFC 791 / STD 5, September 607 1981. 609 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 610 Communication Layers", RFC 1122 / STD 3, October 1989. 612 [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers", 613 RFC 1812 / STD 4, Jun. 1995. 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", RFC 2119 / BCP 14, March 1997. 618 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 619 October 1996. 621 13.2. Informative References 623 [Be02] Bellovin, S., "A Technique for Counting NATted Hosts", 624 Internet Measurement Conference, Proceedings of the 2nd ACM 625 SIGCOMM Workshop on Internet Measurement, November 2002. 627 [Ni09] Nishitani, T., I. Yamagata, S. Miyakawa, A. Nakagawa, H. 628 Ashida, "Common Functions of Large Scale NAT (LSN) ", (work 629 in progress), draft-nishitani-cgn-03, Nov. 2009. 631 [RFC793] Postel, J., "User Datagram Protocol", RFC 793 / STD 6, 632 August 1980. 634 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, Feb. 635 1990. 637 [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6 638 (IPv6) Specification", RFC 2460, December 1998. 640 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 641 Address Translator (Traditional NAT)", RFC 3022, January 642 2001. 644 [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson, Ed., G. 645 Fairhurst, Ed., "The Lightweight User Datagram Protocol 646 (UDP-Lite)", RFC 3828, July 2004. 648 [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet 649 Protocol", RFC 4301, Dec. 2005. 651 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, Dec. 2005. 653 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 654 Network Tunneling", RFC 4459, April 2006. 656 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 657 RFC 4960, Sep. 2007. 659 [RFC4963] Heffner, J., M. Mathis, B. Chandler, "IPv4 Reassembly 660 Errors at High Data Rates," RFC 4963, July 2007. 662 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 663 Adaptation Layer (SEAL)", RFC 5320, Feb. 2010. 665 14. Acknowledgments 667 This document was inspired by of numerous discussions among the 668 authors, Jari Arkko, Lars Eggert, Dino Farinacci, and Fred Templin, 669 as well as members participating in the Internet Area Working Group. 670 Detailed feedback was provided by Carlos Pignataro. This document 671 originated as an Independent Stream draft co-authored by Matt Mathis, 672 PSC, and his contributions are greatly appreciated. 674 This document was prepared using 2-Word-v2.0.template.dot. 676 Author's Address 678 Joe Touch 679 USC/ISI 680 4676 Admiralty Way 681 Marina del Rey, CA 90292-6695 682 U.S.A. 684 Phone: +1 (310) 448-9151 685 Email: touch@isi.edu