idnits 2.17.1 draft-briscoe-intarea-ipv4-id-reuse-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The 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 RFC2780, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4301, 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. -- The draft header indicates that this document updates RFC4727, 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 == Line 851 has weird spacing: '...ificant bit: ...' (Using the creation date from RFC791, updated by this document, for RFC5378 checks: 1981-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 20, 2012) is 4206 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) == Unused Reference: 'Fransson04' is defined on line 978, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area Working Group B. Briscoe 3 Internet-Draft BT 4 Updates: 791, 2003, 2780, 4301, 4727, October 20, 2012 5 ietf-intarea-ipv4-id-update 6 (if approved) 7 Intended status: Standards Track 8 Expires: April 23, 2013 10 Reusing the IPv4 Identification Field in Atomic Packets 11 draft-briscoe-intarea-ipv4-id-reuse-02 13 Abstract 15 This specification takes a new approach to extensibility that is both 16 principled and a hack. It builds on recent moves to formalise the 17 increasingly common practice where fragmentation in IPv4 more closely 18 matches that of IPv6. The large majority of IPv4 packets are now 19 'atomic', meaning indivisible. In such packets, the 16 bits of the 20 IPv4 Identification (IPv4 ID) field are redundant and could be freed 21 up for the Internet community to put to other uses, at least within 22 the constraints imposed by their original use for reassembly. This 23 specification defines the process for redefining the semantics of 24 these bits. It uses the previously reserved control flag in the IPv4 25 header to indicate that these 16 bits have new semantics. Great care 26 is taken throughout to ease incremental deployment, even in the 27 presence of middleboxes that incorrectly discard or normalise packets 28 that have the reserved control flag set. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 23, 2013. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. IPv4 Wire Protocol Semantics for Reusing the 66 Identification Field . . . . . . . . . . . . . . . . . . . . . 5 67 4. Behaviour of Intermediate Nodes . . . . . . . . . . . . . . . 8 68 4.1. End-to-End Preservation of ID-Reuse Semantics . . . . . . 8 69 4.2. Tunnel Behaviour . . . . . . . . . . . . . . . . . . . . . 8 70 5. Process for Defining Subdivisions of the ID-Reuse Field . . . 9 71 5.1. Constraints on Uses of the ID-Reuse Field . . . . . . . . 10 72 5.2. Process Example . . . . . . . . . . . . . . . . . . . . . 11 73 6. Incremental Deployment of New Uses of the IPv4 ID Field . . . 13 74 6.2. Process for Using the ID-Reuse Field Without Requiring 75 RC=1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 7. Updates to Existing RFCs . . . . . . . . . . . . . . . . . . . 17 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 79 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 81 12. Outstanding Issues (to be removed when all resolved) . . . . . 21 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 84 13.2. Informative References . . . . . . . . . . . . . . . . . . 21 85 Appendix A. Why More Bits Cannot be Freed (To be Removed by 86 RFC Editor) . . . . . . . . . . . . . . . . . . . . . 22 87 Appendix B. Experimental or Standards Track? (To Be Removed 88 Before Publication) . . . . . . . . . . . . . . . . . 23 89 Appendix C. Changes in This Version (to be removed by RFC 90 Editor) . . . . . . . . . . . . . . . . . . . . . . . 24 92 Intended status: Standards Track? (to be removed before publication) 94 This draft defines a process and a protocol for enabling new 95 protocols, including their progression from experimental track to 96 standards track. A process specification cannot have lesser status 97 than the protocols it enables. So if this specification were to 98 start on the experimental track, it would not initially have 99 sufficient status to enable standards track protocols. 101 In order for the IETF to consider whether this draft itself should be 102 experimental or standards track, it has been written as if it is 103 intended for the standards track. Otherwise the parts of the process 104 for enabling standards track protocols would have had to have been 105 written hypothetically, which would have been highly confusing. If 106 the IETF decides this specification ought to start out on the 107 experimental track, the standards track parts of the process will 108 have to be edited out. 110 Appendix B discusses whether this draft itself would be better to 111 start as experimental or standards track. 113 1. Introduction 115 The Problem: The extensibility provisions in IP (v4 and v6) have 116 turned out not to be usable in practice. Hardware has been optimised 117 for the common case, so packets using extensibility mechanisms (e.g. 118 IPv4 options or IPv6 hop-by-hop options) are very likely to be punted 119 to the software slow-path and consequently likely to be dropped 120 whenever the software processor is busy [Fransson04, Cisco.IPv6Ext]. 122 This specification takes a different approach to extensibility. 123 Rather than flagging protocol extensions as 'extensions', it places 124 extension headers where they will be ignored by pre-existing 125 hardware. As code is added to routers to handle newly added 126 extensions, the code can tell the machine where to look for the 127 relevant header. 129 This approach recognises that extensions added after a protocol suite 130 was first defined are different to options defined as a coherent part 131 of the original protocol suite. Machines that have no code to 132 understand a protocol extension that was added later do not need to 133 punt a packet to the software processor merely to scan through chains 134 of headers that it will not know how to process. 136 Having only settled on this approach long after the TCP/IP suite has 137 been defined, it becomes necessary to find places in the existing 138 protocol headers that are already ignored by existing machines. In 139 an 'atomic' IPv4 packet, the Identification (IPv4 ID) field is one 140 such place that is redundant. This specification defines the process 141 through which the 16 bits in this field can be returned to the IETF 142 for use in future standards actions, at least within the constraints 143 imposed by their original use for reassembly. 145 Background: [ipv4-id-update] proposes to update IPv4 to more closely 146 match the approach taken to fragmentation in IPv6. It specifies that 147 the IPv4 ID field is only defined for 'atomic' packets. An atomic 148 packet is one that has not yet been fragmented (MF=0 and fragment 149 offset=0) and for which further fragmentation is inhibited (DF=1) 150 [ipv4-id-update]. 152 In practical scenarios, the IPv4 ID field is too small to guarantee 153 uniqueness during the lifetime of a packet anyway [RFC4963]. 154 Therefore it has become safer to disable fragmentation altogether and 155 instead use an approach such as packetization layer path MTU 156 discovery [RFC4821]. The large majority of IPv4 packets are now 157 atomic. 159 Approach: This specification defines the IPv4 control flag that was 160 previously reserved [RFC0791] as the Recycled flag (RC). An 161 implementation can set RC=1 in an atomic packet to unambiguously flag 162 that the IPv4 ID field is not to be interpreted as IP Identification, 163 but instead it has the alternative semantics of an ID-Reuse field. 164 By setting RC=1, IPv4 implementations can distinguish a value 165 deliberately written into the ID-Reuse field from the same value that 166 just happened to be written into the IP ID field of an atomic packet 167 by a pre-existing implementation. 169 Thus, this specification effectively uses up the last bit in the IPv4 170 header in order to free up 16 other bits. However, there are some 171 constraints on the use of these 16 bits due to their original use as 172 the IP ID field (enumerated in Section 5.1). Of course the main 173 constraint is that the bits are not available in non-atomic packets. 174 But fragmentation is now used only rarely anyway, so it makes sense 175 to see if the the Internet community can invent ways to use the 16 176 bits in the IPv4 ID field despite the constraints. 178 Frequently Asked Questions: 180 1. There are many cases where a non-compliant machine ignores Don't 181 Fragment (DF=1) and fragments a packet anyway. 183 One answer is that we cannot allow non-complaint behaviour to 184 always block progress. Another answer is that we may be able to 185 detect and circumvent such non-compliant behaviour. For 186 instance, if a non-compliant router fragments packets with DF=1, 187 it may be possible to enhance path maximum transmission unit 188 discovery (PMTUD) to find a lower segment size small enough to 189 prevent the offending box from fragmenting packets. 191 2. Shouldn't we be focusing on IPv6, not continuing to update IPv4? 193 The simple answer is that, where additions are made to IPv6, 194 sometimes it will be necessary to make a parallel addition to 195 IPv4, to ensure continued interoperability between the IETF's two 196 main protocols. 198 Document Roadmap: Section 3 defines the semantics of the updated IPv4 199 wire protocol and Section 4 defines intermediate node behaviour. 200 Section 5 defines the process to be used for reassigning sub-fields 201 of the IPv4 ID-Reuse field. Then Section 6 describes a way to 202 circumvent problems likely to arise when deploying this new protocol. 203 Finally, Section 7 enumerates the updates to pre-existing RFCs, 204 before the tailpiece sections considering IANA, Security and draw 205 conclusions. 207 2. Terminology 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in RFC 2119 [RFC2119]. 213 Further terminology used within this document: 215 Atomic packet: A packet not yet having been fragmented (MF=0 and 216 fragment offset=0) and for which further fragmentation has been 217 inhibited (DF=1), or in the syntax of the C programming language 218 ((DF==1) && (MF==0) && (Offset==0)) [ipv4-id-update]. 220 Recycled (RC) flag: The control flag that was 'reserved' in 221 [RFC0791] (Figure 1). The flag positioned at bit 48 of the IPv4 222 header (counting from 0). Alternatively, some would call this bit 223 0 (counting from 0) of octet 7 (counting from 1) of the IPv4 224 header. 226 ID-Reuse field: Octets 5 and 6 (counting from 1) of the IPv4 header 227 of an atomic packet (Figure 3). The field that would have been 228 the IP Identification field if the packet were not atomic. 230 3. IPv4 Wire Protocol Semantics for Reusing the Identification Field 232 This specification defines the control flag that was defined as 233 'reserved' in [RFC0791] as the Recycled (RC) flag (Figure 1). 235 0 1 2 236 +---+---+---+ 237 | R | D | M | 238 | C | F | F | 239 +---+---+---+ 241 The Recycled (RC) Flag was previously reserved. 243 Figure 1: The Control Flags at the Start of Byte 7 of the IPv4 Header 245 Figure 2 recaps the definitions of octets 5 to 8 (counting from 1) of 246 the IPv4 header [RFC0791]. 247 0 1 2 3 248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Identification |Flags| Fragment Offset | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 2: Recap of RFC791 Definition of Octets 5 to 8 of the IPv4 254 Header. 256 If an IPv4 implementation sets RC=1 on an atomic packet, octets 5 & 6 257 of the IPv4 header MUST be interpreted with the semantics of the ID- 258 Reuse field, and MUST NOT be interpreted as the Identification field. 259 Figure 3 shows how octets 5 & 6 are redefined as the ID-Reuse field 260 when the packet is atomic, in the case where RC=1. 261 0 1 2 3 262 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | ID-Reuse |1 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0| 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 The Identification Field is redefined as the ID-Reuse Field when the 268 Packet is Atomic and specifically when RC=1 270 Figure 3: Octets 5 to 8 of the IPv4 Header. 272 If the Recycled flag is cleared to RC=0 on an atomic packet, some 273 sub-fields of octets 5 & 6 of the IPv4 header MAY be interpreted with 274 the semantics of the ID-Reuse field, but only in the highly 275 constrained circumstances defined in Section 6.2. 277 For the avoidance of doubt, the Recycled flag alone MUST NOT be 278 assumed to indicate that the packet is atomic. Only the combination 279 of ((DF==1) && (MF==0) && (Offset==0)) indicates that a packet is 280 atomic. Then if the Recycled flag is also set, the ID field 281 unambiguously has the semantics of the ID-Reuse field. If the 282 Recycled flag of an atomic packet is cleared, its ID field only has 283 the semantics of the ID-Reuse field in specific limited 284 circumstances. 286 It is expected that proposals to use the ID-Reuse field will each 287 need a few bits, not the whole 16 bit field. Therefore this 288 specification establishes a new IANA registry (Section 8) to record 289 assignments of sub-divisions of the ID-Reuse field. In this way, it 290 will be possible for new uses of different sub-divisions to be 291 orthogonal to each other. The process for incrementally defining new 292 sub-divisions is specified in Section 5. 294 If an IPv4 packet header has RC=1 but it is not atomic ((DF==0) || 295 (MF==1) || (Offset !=0)), then all the fields of the IPv4 header are 296 undefined and reserved for future use. If an implementation receives 297 such a packet, it could imply: 299 o that some currently unknown attack is being attempted 301 o or that some future standards action has defined a meaning for 302 this reserved combination of header values 304 Therefore, if an implementation receives a non-atomic packets with 305 RC=1, it MUST treat the packet as if the Recycled flag were cleared 306 to 0, but it MUST NOT change the Recycled flag to zero. It MAY log 307 the arrival of such packets and/or raise an alarm. It MUST NOT 308 always drop such packets, but it MAY drop them under a policy that 309 can be revoked if it is established that the appearance of such 310 packets is the result of a future standards action. 312 For convenience only, the above rules are summarised in Table 1. The 313 semantics of octets 5 & 6 of the IPv4 header are tabulated for each 314 value of the RC flag (rows) and for whether the packet is atomic or 315 not (columns). 317 +---------+----------------+--------------------+ 318 | RC flag | Non-Atomic | Atomic | 319 +---------+----------------+--------------------+ 320 | 0 | Identification | ID-Reuse (Limited) | 321 | 1 | Undefined | ID-Reuse | 322 +---------+----------------+--------------------+ 324 Table 1: The Dependence of the Semantics of Octets 5 & 6 of the IPv4 325 Header on whether the Packet is Atomic and on the RC Flag 327 4. Behaviour of Intermediate Nodes 329 4.1. End-to-End Preservation of ID-Reuse Semantics 331 If the source sets the RC flag to 1 on an atomic packet, another node 332 MUST NOT clear the RC flag to zero. Otherwise the semantics of the 333 ID-Reuse field would change (see the Security Considerations in 334 Section 9 for discussion of the integrity of the ID-Reuse field). 335 Note that intermediate nodes are already not expected to change an 336 atomic packet to non-atomic, which otherwise would also risk changing 337 the semantics of the ID-Reuse field. 339 If the source zeros the RC flag on an atomic packet, an intermediate 340 node MAY change the RC flag to 1. At this time, no case is envisaged 341 where an intermediate node would need to do this. However, as this 342 behaviour preserves ID-Reuse semantics safely, it is not precluded in 343 case it will prove useful (e.g. for sender proxies). 345 4.2. Tunnel Behaviour 347 This specification does not need to change the following aspects of 348 IPv4-in-IPv4 tunnelling, which already provide the most useful 349 semantics for the ID-Reuse field: 351 o For some time, it has been mandated that an atomic packet "MUST" 352 be encapsulated by an atomic outer header [RFC2003] (although some 353 implementations are broken in this respect). 355 o On decapsulation the outgoing header will naturally propagate the 356 ID-Reuse field of the inner header. 358 However, compliant IPv4 encapsulation implementations SHOULD copy the 359 ID-Reuse field when encapsulating an atomic IPv4 packet in another 360 atomic IPv4 header, irrespective of the setting of the Recycled flag. 361 It would be ideal but impractical to assert 'MUST' in this last 362 clause, given it cannot be assumed that pre-existing IPv4-in-IPv4 363 encapsulators will propagate the ID-Reuse field to the outer header 364 (see Section 5.1). 366 IPv6 packets without a fragmentation extension header are inherently 367 atomic. Therefore, if an IPv4 header encapsulates an IPv6 packet, 368 the encapsulator is already required to set the outer as atomic. 370 There is no direct mapping between the IPv4 ID-Reuse field as a whole 371 and any IPv6 header field (main or extension), because the ID-Reuse 372 field is merely a container for yet-to-be-defined sub-fields. 373 However, sub-fields of the ID-Reuse field might be defined to provide 374 a mapping for IPv6 extension headers that need to be visible in the 375 outer IPv4 header of a tunnel. The present specification cannot say 376 anything in general about any such mappings or any associated tunnel 377 behaviour. Any such behaviour will have to be defined when 378 individual ID-Reuse sub-fields are specified. 380 5. Process for Defining Subdivisions of the ID-Reuse Field 382 When IPv4 was designed, then later IPv6, all the fields in the main 383 IP header were initially defined together in a coordinated fashion. 384 In contrast, the only practical way to define new uses for the bits 385 in the ID-Reuse field will be to adopt a gradual addition approach, 386 in which subsets of the bits or codepoints will have to be assigned 387 on the merits of each request at the time. 389 Each new scheme will need to submit an RFC that requests a 390 subdivision of the ID-Reuse field and assigns behaviours to the 391 codepoints within this subdivision. A specification defining a new 392 use of a subdivision of the ID-Reuse field MUST register this use 393 with the IANA, which will maintain a registry for this purpose 394 (Section 8). 396 Proposals to reuse the IP ID field could relate to other parts of the 397 IPv4 header in the following different ways {ToDo: this list is not 398 exhaustive}: 400 Orthogonal: Some new protocol proposals will need to apply whatever 401 is in the rest of the packet, e.g. whether unicast or multicast, 402 whatever the Diffserv codepoint and whatever else might have been 403 added in the rest of the IP-Reuse field. Schemes that need to be 404 orthogonal to other elements of the IPv4 protocol will require 405 assignment of a number of bits as a dedicated sub-field of the ID- 406 Reuse field. 408 Mutually exclusive: It might be impossible for two uses of the ID- 409 Reuse field to both apply to the same packet. Such mutually 410 exclusive schemes will only each require a range of codepoints 411 within a sub-field. 413 Conditional: Some protocol proposals might only apply when other 414 parts of the header satisfy certain conditions, e.g. only for 415 multicast packets. The IANA will need to register these 416 conditions so that the bits can still be assigned for other uses 417 when the conditions do not apply. 419 To allow interworking between sub-fields that are being defined 420 incrementally, every new protocol MUST assign the all-zeros codepoint 421 of its sub-field to mean the new protocol is 'turned off'. This 422 means that implementations of the new protocol will treat such 423 packets as they would have been treated before the new protocol was 424 defined. 426 Implementations MUST also clear to zero any bits in the ID-Reuse 427 field that are not defined at the time the implementation is coded. 429 Proposals to use sub-fields of ID-Reuse will have to be assessed in 430 the order they arrive without knowing what future proposals they 431 might preclude. To judge each proposal, at least the following 432 criteria will be used: 434 Constraint satisfaction: Each proposal MUST either satisfy all the 435 constraints in Section 5.1 below, or include measures to 436 circumvent them. 438 General usefulness: Proposals that are not applicable to a broad set 439 of services that can be built over the internetwork protocol 440 SHOULD NOT warrant consuming the newly freed up IPv4 header space. 442 Parsimony: Burning up a large proportion of the remaining bits will 443 count against a proposal. 445 Backward compatibility with prior uses of ID-Reuse: As more sub- 446 fields of the ID-Reuse field become defined, each new proposal 447 SHOULD ensure that it takes into account potential interactions 448 with earlier standards actions or experiments defining other sub- 449 fields. 451 Forward compatibility with potential uses of ID-Reuse: In addition, 452 proposals that demonstrate sensitivity to potential future uses of 453 the remaining sub-fields of the ID-Reuse field will be more likely 454 to progress through the IETF's approval process. 456 Do no harm: Proposals that do no harm to existing uses of the 457 Internet will be favoured over those that do more harm. 459 5.1. Constraints on Uses of the ID-Reuse Field 461 Atomic packets: The IPv4 ID field cannot be reused if the packet is 462 not atomic, because then the IP ID field will need to be used for 463 its original purpose: fragment reassembly. 465 IPsec interaction: The IP Authentication Header (AH) [RFC4302] 466 assumes and requires the IPv4 ID field to be immutable, otherwise 467 verification of authentication and integrity checks will fail. 468 Any new use of bits in the ID-Reuse field MUST ensure the bits are 469 immutable, at least between IPsec endpoints (whether transport or 470 tunnel mode). It cannot be assumed that pre-existing IPsec 471 implementations will check the setting of the Recycled flag. 473 Note that the Recycled flag itself is considered mutable and 474 masked out before calculating an authentication header [RFC4302] 475 (see Section 9). 477 Tunnelling: Any new use of the ID-Reuse field in atomic packets 478 cannot reliably assume that the ID-Reuse field will propagate 479 unchanged into the outer header of an IPv4-in-IPv4 tunnel 480 [RFC2003, RFC4301]. It is likely that an IPv4 tunnel ingress will 481 encapsulate an atomic packet with another atomic outer header, as 482 this behaviour was mandated in [RFC2003]. However it is known 483 that some implementations are broken in this respect. It is 484 possible that an IPv4 encapsulator might copy the IP ID field of 485 an arriving atomic packet into the outer header. However this 486 behaviour has never been required and therefore cannot be 487 guaranteed for pre-existing tunnels. 489 Nonetheless, it can be assumed that the IPv4 ID field will be 490 preserved through the inner header into the outgoing packet at the 491 other end of the tunnel (even though this behaviour would not 492 strictly have been necessary for an atomic packet). 494 Incremental deployment: Each new proposal will need to consider any 495 detrimental effects from pre-existing IPv4 implementations, 496 assuming that they are likely to act on atomic packets without 497 first checking on the setting of the Recycled flag. 499 5.2. Process Example 501 For illustration purposes, imagine two RFCs have been published: an 502 experimental track RFC called Experiment A (ExA) and a standards 503 track RFC called Standard B (StB) and . Imagine they define 504 respectively a use for bits bits 14 to 15 and 11 to 13 of the ID- 505 Reuse field. Figure 4 shows example IANA registry entries for these 506 imaginary sub-fields. 508 Protocol name: StB 509 RFC: BBBB 510 Leftmost bit: 11 511 No. of bits allocated: 3 512 Sub-field defined if: Atomic packet and RC=1 514 Protocol name: ExA 515 RFC: AAAA 516 Leftmost bit: 14 517 No. of bits allocated: 2 518 Sub-field defined if: Atomic packet and RC=1 520 Figure 4: Example IANA Registry of Sub-fields of the ID-Reuse Field 522 Figure 5 shows an example of how incremental specification of 523 subdivisions of ID-Reuse would work. 524 0 1 2 3 525 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | ID-Reuse _____ ___|1 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0| 528 |0 0 0 0 0 0 0 0 0 0 0| StB |ExA| | | 529 | |1 0 1|0 1| | | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Figure 5: Example of Reuse of Octets 5 & 6 using RC=1 534 The bits shown in each row of Figure 5 define the semantics of the 535 bits shown in the next row down, as follows: 537 o The top row identifies that the packet is atomic and the RC flag 538 is 1. Therefore octets 5 & 6 of the IPv4 header are redefined as 539 the ID-Reuse field. 541 o The middle row shows the bits assigned to Standard B and 542 Experiment A by IANA. An implementer has to ensure that all the 543 bits of the ID-Reuse field that are yet to be defined (bits 0-10) 544 are cleared to zero. 546 o The bottom row shows that an implementation of ExA has set its 547 2-bit sub-field to codepoint 01 and an implementation of StB has 548 set its 3-bit sub-field to codepoint 101. The meaning of each 549 would be defined in the RFCs for ExA and StB respectively. 551 Imagine now that Experiment C (ExC) is defined later to use bits 0-7 552 of the ID-Reuse field. If the packet in Figure 5 is received by an 553 implementation of ExC, then it will see only zeros in the ExC sub- 554 field. Therefore the implementation of ExC will treat the packet as 555 if ExC is turned off (as mandated in Section 5). 557 Similarly, the implementation of protocol StB can rely on being able 558 to turn off Experiment A by setting bits 14 & 15 to zero. 560 6. Incremental Deployment of New Uses of the IPv4 ID Field 562 When implementations first set the Recycled flag to 1, they are 563 likely to be blocked by certain middleboxes, either deliberately 564 (e.g. firewalls that assume anomalies are attacks) or erroneously 565 (e.g. having misunderstood the phrase "reserved, must be zero" in 566 RFC791). It is also possible that broken 'normalisers' might clear 567 RC to zero if it is 1, although so far no tests have found such 568 broken behaviour. 570 To address this problem, Section 6.2 introduces a way to use a sub- 571 field of ID-Reuse without having to set RC=1. In this approach, 572 packet headers using the new protocol will be indistinguishable from 573 an IPv4 header not using the new protocol. Therefore it will be 574 possible to guarantee that middleboxes will not treat packets using 575 the new protocol any differently from other IPv4 packets. 577 Many pre-existing IPv4 hosts cycle through all the values in the IP 578 ID field even when sending atomic packets in which the IP ID field 579 has no function. Therefore, these pre-existing IPv4 hosts will 580 occasionally issue a packet that happens to look as if it is using a 581 codepoint of a new protocol using the IP ID field. Without RC=1, 582 there will be no way to distinguish the two. 584 +------+---------------------+--------------------------+ 585 | | middlebox traversal | new protocol recognition | 586 +------+---------------------+--------------------------+ 587 | RC=0 | Assured | Uncertain | 588 | RC=1 | Uncertain | Assured | 589 +------+---------------------+--------------------------+ 591 Table 2: Tradeoff between deterministic middlebox traversal and 592 deterministic protocol recognition 594 Table 2 shows the tradeoff between using RC=0 or RC=1: 596 RC=0: If an implementation of a new protocol uses RC=0, its packets 597 will traverse middleboxes, but it will suffer a small fraction of 598 false positives when recognising which packets using the new 599 protocol -- occasionally it will mistakenly assume a packet is 600 using the new protocol when it is actually just random noise in 601 the IP ID field from a pre-existing implementation. 603 RC=1: If an implementation of a new protocol uses RC=1, its packets 604 may be black-holed by some middleboxes, but it will be certain 605 which packets use the new protocol and which don't. 607 Nonetheless, a probabilistic protocol that can be deployed may be 608 more useful than a deterministic protocol that cannot. 610 6.1. Process Example with RC=0 612 Figure 6 shows an example of how this approach would work with RC=0. 613 For illustration purposes imagine, as in the previous example in 614 Section 5.2, that an experimental track RFC has been published called 615 Experiment A (ExA) that defines bits 14 to 15 of the ID-Reuse field 616 for atomic packets with RC=1. Now imagine another experimental track 617 RFC has been published called Experiment B (ExB) that defines a use 618 for bits 11 to 13 of the ID-Reuse field, but does not require RC=1. 619 In fact a packet is defined as complying with ExB whether RC=1 or 620 RC=0 (i.e., RC=X, where 'X' means don't care). Figure 7 shows the 621 IANA registry entries for these imaginary sub-fields. 622 0 1 2 3 623 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | ID-Reuse _____ |X 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0| 626 |0 0 0 0 0 0 0 0 0 0 0| ExB |0 0|0 | | 627 | |1 0 1| | | | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Figure 6: Example of Experimental Reuse of Octets 5 & 6 Without 631 Requiring RC=1 633 The bits shown in each row of Figure 6 define the semantics of the 634 bits shown in the next row down, as follows: 636 o The top row identifies that the packet is atomic. The RC flag is 637 don't care ('X'), so RC does not have to be 1. Implementations 638 can clear RC to 0 to traverse awkward middleboxes, but RC can be 639 set to 1 otherwise. 641 o The middle row shows that an implementation of Experiment B (ExB) 642 has set RC=0. It is also using the ID-Reuse field, so it clears 643 all the bits to zero except those in its own sub-field (bits 644 11-13). It will have registered this experimental use with the 645 IANA as shown in the top example of Figure 7. 647 o The bottom row shows that an implementation of ExB has set its 648 3-bit sub-field to codepoint 101, the meaning of which will have 649 been defined in the RFC specifying the ExB protocol. 651 Note that, the process for using protocol ExB without RC=1 652 (Section 6.2) precludes an implementation from using the ExA protocol 653 in the same packet -- any one packet can only be part of one RC=0 654 protocol at a time. 656 6.2. Process for Using the ID-Reuse Field Without Requiring RC=1 658 This approach SHOULD NOT be used unless the preferred approach 659 (Section 5) is impractical due to middleboxes blocking packets with 660 RC set to 1. 662 To follow this non-preferred approach, the registration with the IANA 663 MUST specify that the sub-field of ID-Reuse is defined for 'RC=X', 664 meaning "don't care", that is RC may be either set or cleared (for an 665 example, see the final bullet of the imaginary registration details 666 in Section 8). The RFC defining the relevant ID-Reuse sub-field MUST 667 also make it clear that the sub-field is defined for either value of 668 the Recycled flag (RC=X) in an atomic IPv4 packet. 670 This approach will not be feasible for all protocols; only those that 671 satisfy the severe constraints laid down below. Otherwise, for 672 protocols that cannot satisfy these prerequisite constraints, the 673 preferred approach in Section 5 wth RC=1 will be the only option. 675 Once a sub-field of the ID-Reuse field has been registered with the 676 IANA, implementations of the protocol can use any of the available 677 codepoints within that sub-field in atomic packets without having to 678 set RC=1, if and only if the following constraints can be satisfied: 680 1. New protocol implementations MUST NOT use RC=0 unless the 681 treatments associated with all the new codepoints are generally 682 benign to packets not taking part in the protocol. 'Benign' 683 means the new protocol SHOULD do no more harm to other packets 684 than previous implementations did. Using the term 'SHOULD' 685 rather than 'MUST' does not completely rule out new protocol 686 proposals that might sometimes introduce slightly more harm, but 687 such proposals will need to give strong justifications 689 2. Implementations MUST clear all the other bits of the ID-Reuse 690 field (except those in the new protocol's sub-field) to zero. 691 Note that this is different to the approach with RC=1, where more 692 than one sub-field at once can be non-zero 694 3. In addition the constraints in Section 5.1 must also be 695 satisfied. 697 Constraint #1 is severe but necessary in order to ensure that a new 698 protocol (e.g. ExB) does not harm atomic packets from pre-existing 699 IPv4 implementations. For example, a receiving implementation of ExB 700 can assume that most packets with all zeros in bits 0-10 and 14-15 701 were deliberately set by another implementation of ExB. But many 702 pre-existing implementations of IPv4 will be cycling (sequentially or 703 randomly) through all the IPID values as they send out packets. 704 Occasionally they will send out a packet that happens to look like it 705 complies with protocol ExB. For the case of ExB with a 3-bit sub- 706 field, such false positives will occur with probability 1 in 2^13 707 (~0.01%). We term this the misrecognition probability. 709 If the new protocol were designed to do harm (e.g. to deprioritise 710 certain packets against others) that would be fine for those packets 711 intended to take part in the new protocol. But it would not be 712 acceptable to harm even a small proportion of packets misrecognised 713 as using the new protocol. This is why the RC=0 approach can only be 714 allowed for a new protocol that is generally benign. 716 Constraint #2 is necessary in order to ensure the misrecognition 717 probability remains low. If only one sub-field is allowed at one 718 time, all the other bits in the ID-Reuse field will have to be zero. 719 This ensures that a pre-existing IPv4 implementation cycling through 720 all the IP ID values will collide less frequently with values used 721 for each new protocol. 723 As already stated (Section 5), each new protocol MUST define the all- 724 zeros codepoint of its sub-field to mean that the new protocol is 725 'turned off'. 727 This arrangement ensures that packets with an IPv4 ID of zero will 728 never collide with a codepoint used by any ID-Reuse scheme, whether 729 RC=0 or RC=1. All zeros was deliberately chosen as the common 730 'turned off' codepoint because some pre-existing implementations have 731 used zero as the default IP ID for atomic packets. 733 In either case, whether the Recycled flag is set or not, a sub-field 734 of the ID-Reuse field MUST be registered with the IANA, initially for 735 experimental use, by referencing the relevant experimental track RFC. 736 This will ensure that experiments with different sub-fields of the 737 ID-Reuse field can proceed in parallel on the public Internet without 738 colliding with each other. The referenced RFC MUST define a coherent 739 process for returning the bits for other uses if the experimental 740 approach does not progress to the standards track. 742 The same sub-field can be used with the same semantics as the 743 experiment progresses, initially with the Recycled flag cleared to 0 744 and later set to 1. And the same protocol semantics can be used 745 whether the proposal is experimental or standards track. Thus, the 746 whole process is designed to: 748 1. allow initial experiments to use RC=0 to traverse non-compliant 749 middleboxes (Section 6); 751 2. then, once sufficient middleboxes forward RC=1 packets, the 752 experiment can either be continued with RC=1 (Section 5); 754 3. or the experiment can progress cleanly to the standards track, 755 while still using the same sub-field but with RC=1; 757 4. or the experiment can be terminated without having wasted any 758 header bits. 760 (Step 1 is only feasible if the extra constraints in Section 6.2 can 761 be satisfied. If not, Step 2 will be the only feasible first step.) 763 For the avoidance of doubt, any use of ID-Reuse, whether experimental 764 or not, is also subject to the general constraints already enumerated 765 in Section 5.1. 767 7. Updates to Existing RFCs 769 Great care has been taken to ensure all the updates defined in this 770 specifications are incrementally deployable. 772 The definition of the RC flag in Section 3 updates the status of this 773 flag that was "reserved, must be zero" in [RFC0791]. The 774 redefinition of the IP Identification field as the ID-Reuse field 775 when an IPv4 packet is atomic also updates RFC791. 777 Updates to existing RFC791 implementations are only REQUIRED if they 778 discard IPv4 packets with RC=1, or change RC from 1 to 0, both of 779 which are misinterpretations of RFC791 anyway. Otherwise, there will 780 be no need to update an RFC791-compliant IPv4 stack until new use(s) 781 for the ID-Reuse field are also specified. 783 The recommendation in Section 4.2 to copy the ID-Reuse field when 784 encapsulating an atomic IPv4 packet with another atomic IPv4 header 785 updates IPv4-in-IPv4 encapsulation specifications [RFC2003] 786 [RFC4301]. These updates to tunnels are likely to be recommended 787 rather than essential for interworking, so they can be implemented as 788 part of routine code maintenance. 790 The ability to redefine the IPv4 ID field of an atomic packet updates 791 [ipv4-id-update], specifically the following two statements no longer 792 apply: "the field's value is defined only when a datagram is actually 793 fragmented" and "IPv4 ID field MUST NOT be used for purposes other 794 than fragmentation and reassembly." Nonetheless, octets 5 & 6 of an 795 atomic packet still MUST NOT be interpreted with the semantics of the 796 Identification field. 798 [RFC2780] provides the IANA with guidelines on allocating values in 799 IP and related headers. The process defined in Section 5 and 800 Section 6 update RFC2780, given ID-Reuse is effectively a new field 801 in the IPv4 header. 803 [RFC4727] defines the processes for experimental use of values in 804 fields in the IP header that are managed by the IANA. The processes 805 defined in Section 5 and Section 6 update RFC4727 to include the new 806 alternative use of the IPv4 ID field as an ID-Reuse field. 808 8. IANA Considerations 810 The IANA is requested to establish a new registry to record 811 allocation of sub-divisions of the ID-Reuse field and to avoid 812 duplicate allocations. The ID-Reuse field is an alternative use of 813 the Identification field of the IPv4 header in atomic packets 814 (Section 3). All 16 bits are available for assignment, either as 815 sub-fields of bits or as sets of codepoints within a sub-field of 816 bits. Each sub-division of the ID-Reuse field MUST be allocated 817 through an IETF Consensus action. The registry MUST then record: 819 Protocol name: the name for the protocol, as used in the RFC 820 defining it 822 RFC: the RFC that defines the semantics of the codepoints used by 823 the protocol 825 Leftmost bit: the leftmost bit allocated, counting from bit 0 at the 826 most significant bit (which is bit 32 of the IPv4 header, counting 827 from 0) 829 No. of bits allocated: the width in bits of the allocated sub-field 831 Codepoint range (optional): The range of codepoints within the 832 assigned sub-field of bits that the protocol uses 834 Sub-field defined if: the precondition for the sub-field to be 835 defined (Section 5). Valid entries MUST include the condition 836 that the packet is atomic and MUST specifiy valid values of the 837 Recycled (RC) flag, either 'RC=1' or 'RC=X', where 'X' means don't 838 care (Section 6). 840 Two example registrations are shown in Figure 7. 842 Protocol name: ExB 843 RFC: BBBB 844 Most significant bit: 11 845 No. of bits allocated: 3 846 Codepoint range: all 847 Sub-field defined if: Atomic packet and RC=X 849 Protocol name: ExA 850 RFC: AAAA 851 Most significant bit: 14 852 No. of bits allocated: 2 853 Codepoint range: all 854 Sub-field defined if: Atomic packet and RC=1 856 Figure 7: Example IANA Registry of Sub-fields of the ID-Reuse Field 858 9. Security Considerations 860 Integrity Checking: This specification make the semantics of octets 861 5 & 6 of the IPv4 header (IP ID or ID-Reuse) depend on the setting 862 of octets 7 & 8 (all the Control Flags and the Fragment Offset 863 field). The IP Authentication Header (AH) [RFC4302] covers octets 864 5 & 6 but not octets 7 & 8. Therefore AH can assure the integrity 865 of the bits in the ID-Reuse field, but it cannot verify whether or 866 not the sender intended those bits to have the semantics of an ID- 867 Reuse field. 869 Any security-sensitive application of the ID-Reuse field will 870 therefore need to provide its own integrity checking of the status 871 of the Control Flags and Fragment Offset. Such a facility would 872 need to take into account that the present specification allows an 873 intermediate node to set the Recycled flag, but not to clear it 874 (Section 4.1). 876 Covert channels: It has always been possible to use bit 48 of the 877 IPv4 header for a 1 bit per packet covert channel, for instance 878 between a network protected by IPsec and an unprotected network. 879 Bit 48 could be covertly toggled to pass messages because it had 880 no function (so no-one would notice any affect on the main 881 communication channel) and it was not covered by IPsec 882 authentication. On the other hand, once alerted to the 883 vulnerability, it has always been easy for an IPsec gateway to 884 spot bit 48 being used as a covert channel, given bit 48 was meant 885 to always be zero. 887 Now that bit 48 has been given a function, it will often no longer 888 be possible for an attacker to toggle it without affecting the 889 main data communication. However, whenever the main communication 890 does not depend on bit 48, it will be easier to for an attacker to 891 toggle it covertly given it will no longer stand out as anomalous 892 behaviour. 894 10. Conclusions 896 This specification builds on recent moves to make the approach to 897 fragmentation in IPv4 more closely match that of IPv6. Already the 898 fields that support fragmentation in the IPv4 header are usually 899 redundant, but unfortunately they are non-optional. 901 This specification makes it possible to reuse the 16 bits of the IPv4 902 ID field when they are not needed for reassembly. The last unused 903 bit in the IPv4 header is used in order to unambiguously flag that 904 the IP ID field has new semantics. The bit is called the Recycled 905 flag, because it allows the IP ID field to be recycled for new 906 purposes when it would otherwise be redundant. Whenever the IP ID 907 field has new semantics, it is termed the ID-Reuse field. 909 The process for redefining the semantics of sub-fields of this ID- 910 Reuse field has been laid down, both for experimental and standards 911 actions. Great care has been taken throughout to ease incremental 912 deployment. The same sub-field can be used with the same semantics 913 as an experiment evolves into a standards action. Initially it is 914 even possible for certain experiments to leave the Recycled flag 915 cleared to zero, in order to traverse any awkward middleboxes that 916 incorrectly discard or normalise packets if the Recycled flag is set. 918 11. Acknowledgements 920 Rob Hancock originally pointed out that code to handle new protocols 921 can tell the machine where to look for the relevant header. Dan Wing 922 pointed out that codepoints, not just whole bits, could be assigned 923 for protocols that are mutually exclusive. 925 Bob Briscoe is partly funded by Trilogy, a research project (ICT- 926 216372) supported by the European Community under its Seventh 927 Framework Programme. 929 Comments Solicited (to be removed by the RFC Editor): 931 Comments and questions are encouraged and very welcome. They can be 932 addressed to the IETF Internet Area working group mailing list 933 , and/or to the author(s). 935 12. Outstanding Issues (to be removed when all resolved) 937 1. ... 939 13. References 941 13.1. Normative References 943 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 944 September 1981. 946 [RFC2003] Perkins, C., "IP Encapsulation within IP", 947 RFC 2003, October 1996. 949 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 950 Requirement Levels", BCP 14, RFC 2119, March 1997. 952 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation 953 Guidelines For Values In the Internet Protocol and 954 Related Headers", BCP 37, RFC 2780, March 2000. 956 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 957 Internet Protocol", RFC 4301, December 2005. 959 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 960 December 2005. 962 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, 963 ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, 964 November 2006. 966 [ipv4-id-update] Touch, J., "Updated Specification of the IPv4 ID 967 Field", draft-ietf-intarea-ipv4-id-update-06 (work 968 in progress), October 2012. 970 13.2. Informative References 972 [Cisco.IPv6Ext] Cisco, "IPv6 Extension Headers Review and 973 Considerations", Cisco Technology White Paper , 974 October 2006, . 978 [Fransson04] Fransson, P. and A. Jonsson, "End-to-end 979 measurements on performance penalties of IPv4 980 options", Luleae University of Technology, 981 Technical Report 2004:03, 2004, . 985 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer 986 Path MTU Discovery", RFC 4821, March 2007. 988 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 989 Reassembly Errors at High Data Rates", RFC 4963, 990 July 2007. 992 Appendix A. Why More Bits Cannot be Freed (To be Removed by RFC Editor) 994 Given this specification uses the last unassigned bit in the IPv4 995 header, it is worth checking whether it can be used to flag a new use 996 for more than the 16 bits in the IP ID field of atomic packets. 998 IHL: Ideally, the Internet header length field (4 bits) could be 999 made redundant if the length of those IPv4 headers with bit 48 set 1000 were redefined to be fixed at 20 octets. Then a similar approach 1001 to IPv6 could be taken with the Protocol field redefined as a Next 1002 Header field and each extension header specifying its own length. 1004 Unfortunately, although IPv4 options are rarely used and generally 1005 ignored, this idea would not be incrementally deployable. There 1006 are probably billions of pre-existing implementations of the IPv4 1007 stack that will use the IHL field to find the transport protocol 1008 header, without ever looking at bit 48. If the IHL field were 1009 given any other semantics conditional on bit 48 being set, all 1010 these pre-existing stacks would break. 1012 Header Checksum: Ideally, the Header Checksum (16 bits) could be 1013 made redundant in those IPv4 headers with bit 48 set. Then a 1014 similar approach to IPv6 could be taken where the integrity of the 1015 IP header relies on the end-to-end checksum of the transport 1016 protocol, which includes the main fields in the IP header. 1018 Unfortunately, again, this idea would not be incrementally 1019 deployable. Pre-existing implementations of the IPv4 stack might 1020 verify the header checksum without ever looking at bit 48. And 1021 anyway IPv4 stacks on probably every pre-existing router 1022 implementation would update the checksum field without knowing to 1023 check whether bit 48 was set. Therefore if the field were used 1024 for any other purpose than a checksum, it would be impossible to 1025 predict how its value might be changed by a combination of pre- 1026 existing and new stacks. 1028 It is clear that reusing fields other than the IPv4 ID would be 1029 fraught with incremental deployment problems. The reason the IPv4 ID 1030 field can be reused, is that an atomic packet already does not need 1031 an Identification field, whether bit 48 is set or not. Setting bit 1032 48 merely allows new implementations that understand ID-Reuse 1033 semantics to be certain the value in the ID-Reuse field was not 1034 written by an implementation that intended it to have Identification 1035 semantics. 1037 Appendix B. Experimental or Standards Track? (To Be Removed Before 1038 Publication) 1040 This document defines a protocol (using the Recycled flag) to enable 1041 other protocols (using the ID-Reuse field). The Recycled flag 1042 protocol is currently written as if it is on the IETF standards 1043 track. Nonetheless it might be feasible to write it for the 1044 experimental track. This appendix discusses the pros and cons of 1045 each. 1047 The Recycled flag uses up the last unused bit in the IPv4 header. 1048 The present specification defines a use for this last bit in the 1049 expectation that the Internet community will find ingeneous new 1050 use(s) for sub-fields of the ID-Reuse field, because then the 1051 Recycled flag will be needed to unambiguously indicate the new 1052 semantics. However, there is a risk that the last IPv4 header bit 1053 could be wasted, if no new uses for the IP ID field can be found 1054 within the constraints of its previous use for fragment reassembly, 1055 or if new experimental uses are proposed but none successfully 1056 proceed through to standards actions. 1058 The risk of wasting the last bit would be mitigated if the definition 1059 of the Recycled flag itself was initially on the experimental track. 1060 Then, if some experimental use(s) of the ID-Reuse field did see 1061 widespread adoption, the RC flag protocol could progress to the 1062 standards track. On the other hand, if no ID-Reuse experiments 1063 happened, the RC flag could possibly be reclaimed for another use in 1064 the future. This would require all experiments with the RC flag to 1065 be confined in time, so that stray implementations of old experiments 1066 would not conflict with future uses of the flag. 1068 Eventually, each specification for each sub-field of ID-Reuse might 1069 either progress on the experimental track or standards track. 1070 However, an enabler for standards track specifications cannot itself 1071 only be experimental. Therefore the RC flag protocol would have to 1072 be on the standards track, to enable standards track protocols as 1073 well as experimental. Figure 8 illustrates this need for the RC flag 1074 protocol to have sufficient rank for any protocols it enables. 1076 +---------+---------------------------+ 1077 | RC flag | ID-Reuse sub-field track | 1078 | track +-------------+-------------+ 1079 | | Expt | Stds | 1080 +---------+-------------+-------------+ 1081 | Expt | Expt | INVALID | 1082 | Stds | Expt | Stds | 1083 +---------+-------------+-------------+ 1085 The IETF track of the RC flag protocol in the present document (rows) 1086 and of any particular RFC specifying a sub-field of the ID-Reuse 1087 field (columns). The combination determines the status of any 1088 particular sub-field as shown at the intersection of the relevant row 1089 and column. 1091 Figure 8: Validity of Combinations of IETF tracks for the RC flag and 1092 an ID-Reuse Subfield 1094 One purpose of the present draft is to outline how new uses of ID- 1095 Reuse sub-fields can progress seamlessly from experimental track to 1096 standards track. Therefore, this draft is written as if it were on 1097 the standards track. Otherwise the processes for enabling standards 1098 track documents would have had to be written hypothetically, which 1099 would have been highly confusing. Nonetheless, no intent to prejudge 1100 that this document should be or will be on the standards track is 1101 implied. 1103 If it were decided that the present draft should start on the 1104 experimental track, all the text about enabling standards track 1105 protocols would have to be edited out, or perhaps moved to a non- 1106 normative appendix. 1108 Alternatively, the IETF might see some obvious new uses for sub- 1109 fields of the ID-Reuse field that would make it reasonable to fast- 1110 track the RC flag straight onto the standards track. 1112 Appendix C. Changes in This Version (to be removed by RFC Editor) 1114 From briscoe-01 to 02: 1116 * Altered summary of [ipv4-id-update] to reflect recent changes 1117 to that draft 1119 * Added FAQ2 explaining why it will still sometimes be necessary 1120 to update IPv4 even though the focus of the new features will 1121 be IPv6 1123 * Updated references 1125 From briscoe-00 to 01: 1127 * Updated to preserve liveness. 1129 * No changes other than updates to refs and minor corrections. 1131 Author's Address 1133 Bob Briscoe 1134 BT 1135 B54/77, Adastral Park 1136 Martlesham Heath 1137 Ipswich IP5 3RE 1138 UK 1140 Phone: +44 1473 645196 1141 EMail: bob.briscoe@bt.com 1142 URI: http://bobbriscoe.net/