draft-ietf-intarea-ipv4-id-update-06.txt   draft-ietf-intarea-ipv4-id-update-07.txt 
Internet Area WG J. Touch Internet Area WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Updates: 791,1122,2003 October 9, 2012 Updates: 791,1122,2003 November 27, 2012
Intended status: Proposed Standard Intended status: Proposed Standard
Expires: April 2013 Expires: May 2013
Updated Specification of the IPv4 ID Field Updated Specification of the IPv4 ID Field
draft-ietf-intarea-ipv4-id-update-06.txt draft-ietf-intarea-ipv4-id-update-07.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 9, 2013. This Internet-Draft will expire on May 27, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 5 skipping to change at page 3, line 5
4. Updates to the IPv4 ID Specification...........................6 4. Updates to the IPv4 ID Specification...........................6
4.1. IPv4 ID Used Only for Fragmentation.......................7 4.1. IPv4 ID Used Only for Fragmentation.......................7
4.2. Encourage Safe IPv4 ID Use................................8 4.2. Encourage Safe IPv4 ID Use................................8
4.3. IPv4 ID Requirements That Persist.........................8 4.3. IPv4 ID Requirements That Persist.........................8
5. Impact of Proposed Changes.....................................9 5. Impact of Proposed Changes.....................................9
5.1. Impact on Legacy Internet Devices.........................9 5.1. Impact on Legacy Internet Devices.........................9
5.2. Impact on Datagram Generation............................10 5.2. Impact on Datagram Generation............................10
5.3. Impact on Middleboxes....................................11 5.3. Impact on Middleboxes....................................11
5.3.1. Rewriting Middleboxes...............................11 5.3.1. Rewriting Middleboxes...............................11
5.3.2. Filtering Middleboxes...............................12 5.3.2. Filtering Middleboxes...............................12
5.4. Impact on Header Compression.............................13 5.4. Impact on Header Compression.............................12
6. Updates to Existing Standards.................................13 5.5. Impact of Network Reordering and Loss....................13
6.1. Updates to RFC 791.......................................13 5.5.1. Atomic Datagrams Experiencing Reordering or Loss....13
6.2. Updates to RFC 1122......................................14 5.5.2. Non-atomic Datagrams Experiencing Reordering or Loss14
6.3. Updates to RFC 2003......................................15 6. Updates to Existing Standards.................................14
7. Security Considerations.......................................15 6.1. Updates to RFC 791.......................................14
8. IANA Considerations...........................................15 6.2. Updates to RFC 1122......................................15
9. References....................................................16 6.3. Updates to RFC 2003......................................16
9.1. Normative References.....................................16 7. Security Considerations.......................................16
9.2. Informative References...................................16 8. IANA Considerations...........................................17
10. Acknowledgments..............................................18 9. References....................................................17
9.1. Normative References.....................................17
9.2. Informative References...................................17
10. Acknowledgments..............................................19
1. Introduction 1. Introduction
In IPv4, the Identification (ID) field is a 16-bit value that is In IPv4, the Identification (ID) field is a 16-bit value that is
unique for every datagram for a given source address, destination unique for every datagram for a given source address, destination
address, and protocol, such that it does not repeat within the address, and protocol, such that it does not repeat within the
maximum datagram lifetime (MDL) [RFC791][RFC1122]. As currently maximum datagram lifetime (MDL) [RFC791][RFC1122]. As currently
specified, all datagrams between a source and destination of a given specified, all datagrams between a source and destination of a given
protocol must have unique IPv4 ID values over a period of this MDL, protocol must have unique IPv4 ID values over a period of this MDL,
which is typically interpreted as two minutes, and is related to the which is typically interpreted as two minutes, and is related to the
skipping to change at page 10, line 40 skipping to change at page 10, line 40
5.2. Impact on Datagram Generation 5.2. Impact on Datagram Generation
The following is a summary of the recommendations that are the result The following is a summary of the recommendations that are the result
of the previous changes to the IPv4 ID field specification. of the previous changes to the IPv4 ID field specification.
Because atomic datagrams can use arbitrary IPv4 ID values, the ID Because atomic datagrams can use arbitrary IPv4 ID values, the ID
field no longer imposes a performance impact in those cases. However, field no longer imposes a performance impact in those cases. However,
the performance impact remains for non-atomic datagrams. As a result: the performance impact remains for non-atomic datagrams. As a result:
>> Sources of non-atomic IPv4 datagrams MUST rate-limit their output >> Sources of non-atomic IPv4 datagrams MUST rate-limit their output
to comply with the ID uniqueness requirements. to comply with the ID uniqueness requirements. Such sources include,
in particular, DNS over UDP [RFC2671].
Such sources include, in particular, DNS over UDP [RFC2671].
Because there is no strict definition of the MDL, reassembly hazards Because there is no strict definition of the MDL, reassembly hazards
exist regardless of the IPv4 ID reuse interval or the reassembly exist regardless of the IPv4 ID reuse interval or the reassembly
timeout. As a result: timeout. As a result:
>> Higher layer protocols SHOULD verify the integrity of IPv4 >> Higher layer protocols SHOULD verify the integrity of IPv4
datagrams, e.g., using a checksum or hash that can detect reassembly datagrams, e.g., using a checksum or hash that can detect reassembly
errors (the UDP checksum is weak in this regard, but better than errors (the UDP checksum is weak in this regard, but better than
nothing). nothing).
skipping to change at page 13, line 21 skipping to change at page 13, line 14
assuming the ID does not change (e.g., ROHC [RFC5225]), where others assuming the ID does not change (e.g., ROHC [RFC5225]), where others
include non-changing IDs via zero deltas (e.g., ECRTP [RFC3545]). include non-changing IDs via zero deltas (e.g., ECRTP [RFC3545]).
When compression assumes a changing ID as a default, having a non- When compression assumes a changing ID as a default, having a non-
changing ID can make compression less efficient. Such non-changing changing ID can make compression less efficient. Such non-changing
IDs have been described in various RFCs (e.g., footnote 21 of IDs have been described in various RFCs (e.g., footnote 21 of
[RFC1144] and cRTP [RFC2508]). When compression can assume a non- [RFC1144] and cRTP [RFC2508]). When compression can assume a non-
changing IPv4 ID - as with ROHC and ECRTP - efficiency can be changing IPv4 ID - as with ROHC and ECRTP - efficiency can be
increased. increased.
5.5. Impact of Network Reordering and Loss
Tolerance to network reordering and loss is a key feature of the
Internet architecture. Although most current IP networks avoid
gratuitous such events, both reordering and loss can and do occur.
Datagrams are already intended to be reordered or lost, and recovery
from those errors (where supported) already occurs at the transport
or higher protocol layers.
Reordering is typically associated with routing transients or where
multiple alternate paths exist. Loss is typically associated with
path congestion or link failure (partial or complete). The impact of
such events is different for atomic and non-atomic datagrams, and is
discussed below. In summary, the recommendations of this document
make the Internet more robust to reordering and loss by emphasizing
the requirements of ID uniqueness for non-atomic datagrams and by
more clearly indicating the impact of these requirements on both
endpoints and datagram transit devices.
5.5.1. Atomic Datagrams Experiencing Reordering or Loss
Reusing ID values does not affect atomic datagrams when the DF bit is
correctly respected, because order restoration does not depend on the
datagram header. TCP uses a transport header sequence number; in some
other protocols, sequence is indicated and restored at the
application layer.
When DF=1 is ignored, reordering or loss can cause fragments of
different datagrams to be interleaved and thus incorrectly
reassembled and thus discarded. Reuse of ID values in atomic packets,
as permitted by this document, can result in higher datagram loss in
such cases. Such cases already can exist because there are known
devices that use a constant ID for atomic packets (some cellphones),
and there are known devices that ignore DF=1, but high levels of
corresponding loss have not been reported. The lack of such reports
indicates either a lack of reordering or loss in such cases, or a
tolerance to the resulting losses. If such issues are reported, it
would be more productive to address non-compliant devices (that
ignore DF=1), because it is impractical to define Internet
specifications to tolerate devices that ignore those specifications.
This is why this document emphasizes the need to honor DF=1, as well
as that datagram transit devices need to retain the DF bit as
received (i.e., rather than clear it).
5.5.2. Non-atomic Datagrams Experiencing Reordering or Loss
Non-atomic datagrams rely on the uniqueness of the ID value to
tolerate reordering of fragments, notably where fragments of
different datagrams are interleaved as a result of such reordering.
Fragment loss can result in reassembly of fragments from different
origin datagrams, which is why ID reuse in non-atomic datagrams is
based on datagram (fragment) maximum lifetime, not just expected
reordering interleaving.
This document does not change the requirements for uniqueness of IDs
in non-atomic datagrams, and thus does not affect their tolerance to
such reordering or loss. This document emphasizes the need for ID
uniqueness for all datagram sources including rewriting middleboxes,
the need to rate-limit sources to ensure ID uniqueness, the need to
not reuse the ID for retransmitted datagrams, and the need to use
higher-layer integrity checks to prevent reassembly errors - all of
which result in a higher tolerance to reordering or loss events.
6. Updates to Existing Standards 6. Updates to Existing Standards
The following sections address the specific changes to existing The following sections address the specific changes to existing
protocols indicated by this document. protocols indicated by this document.
6.1. Updates to RFC 791 6.1. Updates to RFC 791
RFC 791 states that: RFC 791 states that:
The originating protocol module of an internet datagram sets the The originating protocol module of an internet datagram sets the
 End of changes. 7 change blocks. 
18 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/