draft-ietf-intarea-ipv4-id-update-04.txt   draft-ietf-intarea-ipv4-id-update-05.txt 
Internet Area WG J. Touch Internet Area WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Updates: 791,1122,2003 September 16, 2011 Updates: 791,1122,2003 May 30, 2012
Intended status: Proposed Standard Intended status: Proposed Standard
Expires: March 2012 Expires: November 2012
Updated Specification of the IPv4 ID Field Updated Specification of the IPv4 ID Field
draft-ietf-intarea-ipv4-id-update-04.txt draft-ietf-intarea-ipv4-id-update-05.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 March 16, 2012. This Internet-Draft will expire on November 30, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 39 skipping to change at page 2, line 39
updates the specification of the IPv4 ID field in RFC791, RFC1122, updates the specification of the IPv4 ID field in RFC791, RFC1122,
and RFC2003 to more closely reflect current practice and to more and RFC2003 to more closely reflect current practice and to more
closely match IPv6 so that the field's value is defined only when a closely match IPv6 so that the field's value is defined only when a
datagram is actually fragmented. It also discusses the impact of datagram is actually fragmented. It also discusses the impact of
these changes on how datagrams are used. these changes on how datagrams are used.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Conventions used in this document..............................3 2. Conventions used in this document..............................3
3. The IPv4 ID Field..............................................3 3. The IPv4 ID Field..............................................4
4. Uses of the IPv4 ID Field......................................4 4. Uses of the IPv4 ID Field......................................4
5. Background on IPv4 ID Reassembly Issues........................5 5. Background on IPv4 ID Reassembly Issues........................5
6. Updates to the IPv4 ID Specification...........................6 6. Updates to the IPv4 ID Specification...........................6
6.1. IPv4 ID Used Only for Fragmentation.......................7 6.1. IPv4 ID Used Only for Fragmentation.......................7
6.2. Encourage Safe IPv4 ID Use................................8 6.2. Encourage Safe IPv4 ID Use................................8
6.3. IPv4 ID Requirements That Persist.........................8 6.3. IPv4 ID Requirements That Persist.........................8
7. Impact on Datagram Use.........................................9 7. Impact on Datagram Use.........................................9
8. Updates to Existing Standards..................................9 8. Updates to Existing Standards..................................9
8.1. Updates to RFC 791.......................................10 8.1. Updates to RFC 791.......................................10
8.2. Updates to RFC 1122......................................10 8.2. Updates to RFC 1122......................................10
8.3. Updates to RFC 2003......................................11 8.3. Updates to RFC 2003......................................11
9. Impact on NATs/ASMs, Rewriting Devices, and Tunnel Ingresses..11 9. Impact on Middleboxes.........................................11
10. Impact on Header Compression.................................12 9.1. Rewriting Middleboxes....................................12
9.2. Filtering Middleboxes....................................13
10. Impact on Header Compression.................................13
11. Security Considerations......................................13 11. Security Considerations......................................13
12. IANA Considerations..........................................13 12. IANA Considerations..........................................14
13. References...................................................13 13. References...................................................14
13.1. Normative References....................................13 13.1. Normative References....................................14
13.2. Informative References..................................14 13.2. Informative References..................................14
14. Acknowledgments..............................................15 14. Acknowledgments..............................................16
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 Segment Lifetime (MSL) [RFC791][RFC1122]. As currently Maximum Segment Lifetime (MSL) [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 MSL, protocol must have unique IPv4 ID values over a period of this MSL,
which is typically interpreted as two minutes (120 seconds). This which is typically interpreted as two minutes (120 seconds). This
skipping to change at page 4, line 19 skipping to change at page 4, line 24
flag (DF), and a "More Fragments" flag (MF) [RFC791] flag (DF), and a "More Fragments" flag (MF) [RFC791]
o In IPv6, fragments are indicated in an extension header that o In IPv6, fragments are indicated in an extension header that
includes an ID, Fragment Offset, and M (more fragments) flag includes an ID, Fragment Offset, and M (more fragments) flag
similar to their counterparts in IPv4 [RFC2460] similar to their counterparts in IPv4 [RFC2460]
IPv4 and IPv6 fragmentation differs in a few important ways. IPv6 IPv4 and IPv6 fragmentation differs in a few important ways. IPv6
fragmentation occurs only at the source, so a DF bit is not needed to fragmentation occurs only at the source, so a DF bit is not needed to
prevent downstream devices from initiating fragmentation (i.e., IPv6 prevent downstream devices from initiating fragmentation (i.e., IPv6
always acts as if DF=1). The IPv6 fragment header is present only always acts as if DF=1). The IPv6 fragment header is present only
when a datagram has been fragmented, so the ID field is not present when a datagram has been fragmented, or when the source has received
a "packet too big" ICMPv6 error message when the path cannot support
the required minimum 1280-byte IPv6 MTU and is thus subject to
translation [RFC2460][RFC4443]. The latter case is relevant only for
IPv6 datagrams sent to IPv4 destinations to support subsequent
fragmentation after translation to IPv4.
With the exception of these two cases, the ID field is not present
for non-fragmented datagrams, and thus is meaningful only for for non-fragmented datagrams, and thus is meaningful only for
fragments. Finally, the IPv6 ID field is 32 bits, and required unique datagrams that are already fragmented or datagrams intended to be
per source/destination address pair for IPv6, whereas for IPv4 it is fragmented as part of IPv4 translation. Finally, the IPv6 ID field is
only 16 bits and required unique per source/destination/protocol 32 bits, and required unique per source/destination address pair for
triple. IPv6, whereas for IPv4 it is only 16 bits and required unique per
source/destination/protocol triple.
This document focuses on the IPv4 ID field issues, because in IPv6 This document focuses on the IPv4 ID field issues, because in IPv6
the field is larger and present only in fragments. the field is larger and present only in fragments.
4. Uses of the IPv4 ID Field 4. Uses of the IPv4 ID Field
The IPv4 ID field was originally intended for fragmentation and The IPv4 ID field was originally intended for fragmentation and
reassembly [RFC791]. Within a given source address, destination reassembly [RFC791]. Within a given source address, destination
address, and protocol, fragments of an original datagram are matched address, and protocol, fragments of an original datagram are matched
based on their IPv4 ID. This requires that IDs are unique within the based on their IPv4 ID. This requires that IDs are unique within the
address/protocol triple when fragmentation is possible (e.g., DF=0) address/protocol triple when fragmentation is possible (e.g., DF=0)
or when it has already occurred (e.g., frag_offset>0 or MF=1). or when it has already occurred (e.g., frag_offset>0 or MF=1).
The IPv4 ID field can be useful for other purposes. The field has The IPv4 ID field can be useful for other purposes. The field has
been proposed as a way to detect and remove duplicate datagrams, been proposed as a way to detect and remove duplicate datagrams,
e.g., at congested routers (noted in Sec. 3.2.1.5 of [RFC1122], e.g., at congested routers (noted in Sec. 3.2.1.5 of [RFC1122]) or in
proposed experimentally in Simplified Multicast Forwarding [Ma11]). network accelerators. It can similarly be used at end hosts to reduce
It can similarly be used at end hosts to reduce the impact of the impact of duplication on higher-layer protocols (e.g., additional
duplication on higher-layer protocols (e.g., additional processing in processing in TCP, or the need for application-layer duplicate
TCP, or the need for application-layer duplicate suppression in UDP). suppression in UDP).
The IPv4 ID field is also used in some debugging tools to correlate The IPv4 ID field is also used in some debugging tools to correlate
datagrams measured at various locations along a network path. This is datagrams measured at various locations along a network path. This is
already insufficient in IPv6 because unfragmented datagrams lack an already insufficient in IPv6 because unfragmented datagrams lack an
ID, so these tools are already being updated to avoid such reliance ID, so these tools are already being updated to avoid such reliance
on the ID field. on the ID field.
The ID clearly needs to be unique (within MSL, within the The ID clearly needs to be unique (within MSL, within the
src/dst/protocol tuple) to support fragmentation and reassembly, but src/dst/protocol tuple) to support fragmentation and reassembly, but
not all packets are fragmented or allow fragmentation. This document not all datagrams are fragmented or allow fragmentation. This
deprecates non-fragementation uses, allowing the ID to be repeated document deprecates non-fragmentation uses, allowing the ID to be
(within MSL, within the src/dst/protocol tuple) in those cases. repeated (within MSL, within the src/dst/protocol tuple) in those
cases.
5. Background on IPv4 ID Reassembly Issues 5. Background on IPv4 ID Reassembly Issues
The following is a summary of issues with IPv4 fragment reassembly in The following is a summary of issues with IPv4 fragment reassembly in
high speed environments raised previously [RFC4963]. Readers are high speed environments raised previously [RFC4963]. Readers are
encouraged to consult RFC 4963 for a more detailed discussion of encouraged to consult RFC 4963 for a more detailed discussion of
these issues. these issues.
With the maximum IPv4 datagram size of 64KB, a 16-bit ID field that With the maximum IPv4 datagram size of 64KB, a 16-bit ID field that
does not repeat within 120 seconds means that the aggregate of all does not repeat within 120 seconds means that the aggregate of all
TCP connections of a given protocol between two IP endpoints is TCP connections of a given protocol between two IP endpoints is
limited to roughly 286 Mbps; at a more typical MTU of 1500 bytes, limited to roughly 286 Mbps; at a more typical MTU of 1500 bytes,
this speed drops to 6.4 Mbps [RFC4963]. This limit currently applies this speed drops to 6.4 Mbps [RFC791][RFC1122][RFC4963]. This limit
for all IPv4 datagrams within a single protocol (i.e., the IPv4 currently applies for all IPv4 datagrams within a single protocol
protocol field) between two IP addresses, regardless of whether (i.e., the IPv4 protocol field) between two IP addresses, regardless
fragmentation is enabled or inhibited, and whether a datagram is of whether fragmentation is enabled or inhibited, and whether a
fragmented or not. datagram is fragmented or not.
IPv6, even at typical MTUs, is capable of 18.7 Tbps with IPv6, even at typical MTUs, is capable of 18.7 Tbps with
fragmentation between two IP endpoints as an aggregate across all fragmentation between two IP endpoints as an aggregate across all
protocols, due to the larger 32-bit ID field (and the fact that the protocols, due to the larger 32-bit ID field (and the fact that the
IPv6 next-header field, the equivalent of the IPv4 protocol field, is IPv6 next-header field, the equivalent of the IPv4 protocol field, is
not considered in differentiating fragments). When fragmentation is not considered in differentiating fragments). When fragmentation is
not used the field is absent, and in that case IPv6 speeds are not not used the field is absent, and in that case IPv6 speeds are not
limited by the ID field uniqueness. limited by the ID field uniqueness.
Note also that 120 seconds is only an estimate on the maximum Note also that 120 seconds is only an estimate on the maximum
datagram lifetime. It is loosely based on half maximum value of the datagram lifetime. It is loosely based on half maximum value of the
IP TTL field (255), measured in seconds, because the TTL is IP TTL field (255), measured in seconds, because the TTL was
decremented not only for each hop, but also for each second a originally specified as decremented not only for each hop, but also
datagram is held at a router (as implied in [RFC791]). Network delays for each second a datagram is held at a router (as implied in
are incurred in other ways, e.g., satellite links, which can add [RFC791], although this has long since become a hopcount only).
seconds of delay even though the TTL is often not decremented by a Network delays are incurred in other ways, e.g., satellite links,
corresponding amount. There is thus no enforcement mechanism to which can add seconds of delay even though the TTL is not decremented
by a corresponding amount. There is thus no enforcement mechanism to
ensure that datagrams older than 120 seconds are discarded. ensure that datagrams older than 120 seconds are discarded.
Wireless Internet devices are frequently connected at speeds over 54 Wireless Internet devices are frequently connected at speeds over 54
Mbps, and wired links of 1 Gbps have been the default for several Mbps, and wired links of 1 Gbps have been the default for several
years. Although many end-to-end transport paths are congestion years. Although many end-to-end transport paths are congestion
limited, these devices easily achieve 100+ Mbps application-layer limited, these devices easily achieve 100+ Mbps application-layer
throughput over LANs (e.g., disk-to-disk file transfer rates), and throughput over LANs (e.g., disk-to-disk file transfer rates), and
numerous throughput demonstrations have been performed with COTS numerous throughput demonstrations with COTS systems over wide-area
systems over wide-area paths at these speeds for over a decade. This paths exhibit these speeds for over a decade. This strongly suggests
strongly suggests that IPv4 ID uniqueness has been moot for a long that IPv4 ID uniqueness has been moot for a long time.
time.
6. Updates to the IPv4 ID Specification 6. Updates to the IPv4 ID Specification
This document updates the specification of the IPv4 ID field in three This document updates the specification of the IPv4 ID field in three
distinct ways, as discussed in subsequent subsections: distinct ways, as discussed in subsequent subsections:
o Use the IPv4 ID field only for fragmentation o Use the IPv4 ID field only for fragmentation
o Avoiding a performance impact when the IPv4 ID field is used o Avoiding a performance impact when the IPv4 ID field is used
o Encourage safe operation when the IPv4 ID field is used o Encourage safe operation when the IPv4 ID field is used
There are two kinds of datagrams used in the following discussion, There are two kinds of datagrams used in the following discussion,
named as follows: named as follows:
o Atomic datagrams: datagrams not yet fragmented (MF=0 and fragment o Atomic datagrams are datagrams not yet fragmented and for which
offset=0) and for which further fragmentation has been inhibited further fragmentation has been inhibited.
(DF=1), i.e., as a mathematical expression (equals is ==, logical
'and' is &&, logical 'or' is ||, greater than is >, logical 'not'
is ~, and parenthesis function typically):
(DF==1)&&(MF==0)&&(frag_offset==0)
o Non-atomic datagrams: datagrams which have either already been
fragmented, i.e.:
(MF=1)||(frag_offset>0)
or for which fragmentation remains possible:
(DF==0)
I.e., non-atomic datagrams can be expressed in two equivalent
tests:
(DF==0)||(MF==1)||(frag_offset>0) o Non-atomic datagrams are datagrams which either have already been
fragmented or for which fragmentation remains possible.
which can also be expressed as follows, using DeMorgan's Law and This same definition can be expressed in pseudo code as using common
other identities: logical operators (equals is ==, logical 'and' is &&, logical 'or' is
||, greater than is >, and parenthesis function typically) as:
~((DF==1)&&(MF==0)&&(frag_offset==0)) o Atomic datagrams: (DF==1)&&(MF==0)&&(frag_offset==0)
Note that this final expression is the same as "not(atomic)". o Non-atomic datagrams: (DF==0)||(MF==1)||(frag_offset>0)
The test for non-atomic datagrams is the logical negative of the test
for atomic datagrams, thus all possibilities are considered.
6.1. IPv4 ID Used Only for Fragmentation 6.1. IPv4 ID Used Only for Fragmentation
Although RFC1122 suggests the IPv4 ID field has other uses, and it is Although RFC1122 suggests the IPv4 ID field has other uses, including
currently being considered for the experimental Simplfied Mulitcast datagram de-duplication, this document asserts that this field's
Forwarding (SMF) protocol [Ma11], this document asserts that this value is defined only for fragmentation and reassembly:
field's value is defined only for fragmentation and reassembly:
o >> IPv4 ID field MUST NOT be used for purposes other than >> IPv4 ID field MUST NOT be used for purposes other than
fragmentation and reassembly. fragmentation and reassembly.
SMF includes non-ID hash-based duplicate packet detection for cases Datagram de-duplication can be accomplished using hash-based
where the ID field is absent (IPv6), and already defines these for duplicate detection for cases where the ID field is absent.
IPv4, where it should be preferred to ID-based duplicate detection.
In atomic datagrams, the IPv4 ID field has no meaning, and thus can In atomic datagrams, the IPv4 ID field has no meaning, and thus can
be set to an arbitrary value, i.e., the requirement for non-repeating be set to an arbitrary value, i.e., the requirement for non-repeating
IDs within the address/protocol triple is no longer required for IDs within the address/protocol triple is no longer required for
atomic datagrams: atomic datagrams:
o >> Originating sources MAY set the IPv4 ID field of atomic >> Originating sources MAY set the IPv4 ID field of atomic datagrams
datagrams to any value. to any value.
Second, all network nodes, whether at intermediate routers, Second, all network nodes, whether at intermediate routers,
destination hosts, or other devices (e.g., NATs and other address destination hosts, or other devices (e.g., NATs and other address
sharing mechanisms, firewalls, tunnel egresses), cannot rely on the sharing mechanisms, firewalls, tunnel egresses), cannot rely on the
field: field:
o >> All devices that examine IPv4 headers MUST ignore the IPv4 ID >> All devices that examine IPv4 headers MUST ignore the IPv4 ID
field of atomic datagrams. field of atomic datagrams.
The IPv4 ID field is thus meaningful only for non-atomic datagrams - The IPv4 ID field is thus meaningful only for non-atomic datagrams -
datagrams that have either already been fragmented, or those for datagrams that have either already been fragmented, or those for
which fragmentation remains permitted. Atomic datagrams are detected which fragmentation remains permitted. Atomic datagrams are detected
by their DF, MF, and fragmentation offset fields as explained in by their DF, MF, and fragmentation offset fields as explained in
Section 6, because such a test is completely backward compatible; Section 6, because such a test is completely backward compatible;
this document thus does not reserve any IPv4 ID values, including 0, this document thus does not reserve any IPv4 ID values, including 0,
as distinguished. as distinguished.
Deprecating the use of the IPv4 ID field for non-reassembly uses Deprecating the use of the IPv4 ID field for non-reassembly uses
skipping to change at page 8, line 13 skipping to change at page 8, line 13
have been noticed [RFC1812]. ICMP relaying at tunnel ingresses is have been noticed [RFC1812]. ICMP relaying at tunnel ingresses is
specified to use soft state rather than a datagram cache, and should specified to use soft state rather than a datagram cache, and should
have been noted if the latter for similar reasons [RFC2003]. have been noted if the latter for similar reasons [RFC2003].
6.2. Encourage Safe IPv4 ID Use 6.2. Encourage Safe IPv4 ID Use
This document makes further changes to the specification of the IPv4 This document makes further changes to the specification of the IPv4
ID field and its use to encourage its safe use as corollary ID field and its use to encourage its safe use as corollary
requirements changes as follows. requirements changes as follows.
RFC 1122 discusses that TCP retransmits a segment it may be possible RFC 1122 discusses that if TCP retransmits a segment it may be
to reuse the IPv4 ID (see Section 8.2). This can make it difficult possible to reuse the IPv4 ID (see Section 8.2). This can make it
for a source to avoid IPv4 ID repetition for received fragments. RFC difficult for a source to avoid IPv4 ID repetition for received
1122 concludes that this behavior "is not useful"; this document fragments. RFC 1122 concludes that this behavior "is not useful";
formalizes that conclusion as follows: this document formalizes that conclusion as follows:
o >> The IPv4 ID of non-atomic datagrams MUST NOT be reused when >> The IPv4 ID of non-atomic datagrams MUST NOT be reused when
sending a copy of an earlier non-atomic datagram. sending a copy of an earlier non-atomic datagram.
RFC 1122 also suggests that fragments can overlap [RFC1122]. Such RFC 1122 also suggests that fragments can overlap [RFC1122]. Such
overlap can occur if successive retransmissions are fragmented in overlap can occur if successive retransmissions are fragmented in
different ways but the same reassembly IPv4 ID. This overlap is noted different ways but with the same reassembly IPv4 ID. This overlap is
as the result of reusing IPv4 IDs when retransmitting datagrams, noted as the result of reusing IPv4 IDs when retransmitting
which this document deprecates. However, it is also the result of in- datagrams, which this document deprecates. However, it is also the
network packet duplication, which can still occur. As a result this result of in-network datagram duplication, which can still occur. As
document does not change the need to support overlapping fragments. a result this document does not change the need to support
overlapping fragments.
6.3. IPv4 ID Requirements That Persist 6.3. IPv4 ID Requirements That Persist
This document does not relax the IPv4 ID field uniqueness This document does not relax the IPv4 ID field uniqueness
requirements of [RFC791] for non-atomic datagrams, i.e.: requirements of [RFC791] for non-atomic datagrams, i.e.:
o >> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID >> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
values within one MSL for a given source address/destination values within one MSL for a given source address/destination
address/protocol triple. address/protocol triple.
Such sources include originating hosts, tunnel ingresses, and NATs Such sources include originating hosts, tunnel ingresses, and NATs
(including other address sharing mechanisms) (see Section 9). (including other address sharing mechanisms) (see Section 9).
This document does not relax the requirement that all network devices This document does not relax the requirement that all network devices
honor the DF bit, i.e.: honor the DF bit, i.e.:
o >> IPv4 datagrams whose DF=1 MUST NOT be fragmented. >> IPv4 datagrams whose DF=1 MUST NOT be fragmented.
o >> IPv4 datagram transit devices MUST NOT clear the DF bit. >> IPv4 datagram transit devices MUST NOT clear the DF bit.
In specific, DF=1 prevents fragmenting atomic datagrams. DF=1 also In specific, DF=1 prevents fragmenting atomic datagrams. DF=1 also
prevents further fragmenting received fragments. In-network prevents further fragmenting received fragments. In-network
fragmentation is permitted only when DF=0; this document does not fragmentation is permitted only when DF=0; this document does not
change that requirement. change that requirement.
7. Impact on Datagram Use 7. Impact on Datagram Use
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:
o >> Sources of non-atomic IPv4 datagrams MUST rate-limit their >> Sources of non-atomic IPv4 datagrams MUST rate-limit their output
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 MSL, reassembly hazards Because there is no strict definition of the MSL, 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:
o >> 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 datagrams, e.g., using a checksum or hash that can detect reassembly
reassembly errors (the UDP checksum is weak in this regard, but errors (the UDP checksum is weak in this regard, but better than
better than nothing), as in SEAL [RFC5320]. nothing), as in SEAL [RFC5320].
Additional integrity checks can be employed using tunnels, as in Additional integrity checks can be employed using tunnels, as in
SEAL, IPsec, or SCTP [RFC4301][RFC4960][RFC5320]. Such checks can SEAL, IPsec, or SCTP [RFC4301][RFC4960][RFC5320]. Such checks can
avoid the reassembly hazards that can occur when using UDP and TCP avoid the reassembly hazards that can occur when using UDP and TCP
checksums [RFC4963], or when using partial checksums as in UDP-Lite checksums [RFC4963], or when using partial checksums as in UDP-Lite
[RFC3828]. Because such integrity checks can avoid the impact of [RFC3828]. Because such integrity checks can avoid the impact of
reassembly errors: reassembly errors:
o >> Sources of non-atomic IPv4 datagrams using strong integrity >> Sources of non-atomic IPv4 datagrams using strong integrity checks
checks MAY reuse the ID within MSL values smaller than is typical. MAY reuse the ID within MSL values smaller than is typical.
Note, however, that such more frequent reuse can still result in Note, however, that such frequent reuse can still result in corrupted
corrupted reassembly and poor throughput, although it would not reassembly and poor throughput, although it would not propagate
propagate reassembly errors to higher layer protocols. reassembly errors to higher layer protocols.
8. Updates to Existing Standards 8. 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.
8.1. Updates to RFC 791 8.1. Updates to RFC 791
RFC 791 states that: RFC 791 states that:
skipping to change at page 11, line 21 skipping to change at page 11, line 21
datagrams are fragmented and some of the fragments are lost, datagrams are fragmented and some of the fragments are lost,
the receiver may be able to reconstruct a complete datagram the receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field (and congested gateway might use the IP Identification field (and
Fragment Offset) to discard duplicate datagrams from the Fragment Offset) to discard duplicate datagrams from the
queue. queue.
This document changes RFC 1122 as follows: This document changes RFC 1122 as follows:
o The IPv4 ID field is no longer permitted to be used for duplicate o The IPv4 ID field is no longer permitted to be used for duplicate
detection. This applies both atomic and non-atomic datagrams. detection. This applies to both atomic and non-atomic datagrams.
o Retransmitted non-atomic IPv4 datagrams are no longer permitted to o Retransmitted non-atomic IPv4 datagrams are no longer permitted to
reuse the ID value. reuse the ID value.
8.3. Updates to RFC 2003 8.3. Updates to RFC 2003
This document updates how IPv4-in-IPv4 tunnels create IPv4 ID values This document updates how IPv4-in-IPv4 tunnels create IPv4 ID values
for the IPv4 outer header [RFC2003], but only in the same way as for for the IPv4 outer header [RFC2003], but only in the same way as for
any other IPv4 datagram source. any other IPv4 datagram source. In specific, RFC 2003 states the
following, where ref. [10] is RFC 791:
9. Impact on NATs/ASMs, Rewriting Devices, and Tunnel Ingresses Identification, Flags, Fragment Offset
Network address translators (NATs) and address/port translators These three fields are set as specified in [10]...
(NAPTs) rewrite IP fields, and tunnel ingresses (using IPv4
This document changes RFC 2003 as follows:
o The IPv4 ID field is set as permitted by this document.
9. Impact on Middleboxes
Middleboxes include rewriting devices that include network address
translators (NATs), address/port translators (NAPTs), and other
address sharing mechanisms (ASMs). They also include devices that
inspect and filter datagrams that are not routers, such as
accelerators and firewalls.
9.1. Rewriting Middleboxes
NATs and NAPTs rewrite IP fields, and tunnel ingresses (using IPv4
encapsulation) copy and modify some IPv4 fields, so all are encapsulation) copy and modify some IPv4 fields, so all are
considered sources, as do any devices that rewrite any portion of the considered sources, as do any devices that rewrite any portion of the
source address, destination address, protocol, and ID tuple for any source address, destination address, protocol, and ID tuple for any
datagrams [RFC3022]. This is also true for other address sharing datagrams [RFC3022]. This is also true for other ASMs, including 4rd,
mechanisms (ASMs), including to include 4rd, IVI, and others in the IVI, and others in the "A+P" (address plus port) family [Bo11] [De11]
"A+P" (address plus port) family [Bo11] [De11] [RFC6219]. It is [RFC6219]. It is equally true for any other datagram rewriting
equally true for any other packet rewriting mechanism. As a result, mechanism. As a result, they are subject to all the requirements of
they are subject to all the requirements of any source, as has been any source, as has been noted.
noted.
NATs/ASMs/rewriters present a particularly challenging situation for NATs/ASMs/rewriters present a particularly challenging situation for
fragmentation. Because they overwrite portions of the reassembly fragmentation. Because they overwrite portions of the reassembly
tuple in both directions, they can destroy tuple uniqueness and tuple in both directions, they can destroy tuple uniqueness and
result in a reassembly hazard. Whenever IPv4 source address, result in a reassembly hazard. Whenever IPv4 source address,
destination address, or protocol fields are modified, a destination address, or protocol fields are modified, a
NAT/ASM/rewriter needs to ensure that the ID field is generated NAT/ASM/rewriter needs to ensure that the ID field is generated
appropriately, rather than simply copied from the incoming datagram. appropriately, rather than simply copied from the incoming datagram.
In specific: In specific:
o >> Address sharing or rewriting devices MUST ensure that the IPv4 >> Address sharing or rewriting devices MUST ensure that the IPv4 ID
ID field of datagrams whose address or protocol are translated field of datagrams whose address or protocol are translated comply
comply with requirements as if the datagram were sourced by that with these requirements as if the datagram were sourced by that
device. device.
This compliance means that the IPv4 ID field of non-atomic datagrams This compliance means that the IPv4 ID field of non-atomic datagrams
translated at a NAT/ASM/rewriter needs to obey the uniqueness translated at a NAT/ASM/rewriter needs to obey the uniqueness
requirements of any IPv4 datagram source. Unfortunately, fragments requirements of any IPv4 datagram source. Unfortunately, fragments
already violate that requirement, as they repeat an IPv4 ID within already violate that requirement, as they repeat an IPv4 ID within
the MSL for a given source address, destination address, and protocol the MSL for a given source address, destination address, and protocol
triple. triple.
Such problems with transmitting fragments through NATs/ASMs/rewriters Such problems with transmitting fragments through NATs/ASMs/rewriters
are already known; translation is based on the transport port number, are already known; translation is based on the transport port number,
skipping to change at page 12, line 40 skipping to change at page 13, line 12
affected by it. It is exacerbated in large-scale, so-called "carrier affected by it. It is exacerbated in large-scale, so-called "carrier
grade" NATs [Pe11]. grade" NATs [Pe11].
Tunnel ingresses act as sources for the outermost header, but tunnels Tunnel ingresses act as sources for the outermost header, but tunnels
act as routers for the inner headers (i.e., the datagram as arriving act as routers for the inner headers (i.e., the datagram as arriving
at the tunnel ingress). Ingresses can always fragment as originating at the tunnel ingress). Ingresses can always fragment as originating
sources of the outer header, because they control the uniqueness of sources of the outer header, because they control the uniqueness of
that IPv4 ID field and the value of DF on the outer header that IPv4 ID field and the value of DF on the outer header
independent of those values on the inner (arriving datagram) header. independent of those values on the inner (arriving datagram) header.
9.2. Filtering Middleboxes
Middleboxes also include devices that filter datagrams, including
network accelerators and firewalls. Some such devices reportedly
feature datagram de-duplication, which relies on IP ID uniqueness to
identify duplicates. Such accelerators already risk dropping non-
duplicate datagrams because of early ID reuse, and, as a result of
earlier requirements:
>> Datagram de-duplication mechanisms MUST ignore the ID values on
atomic datagrams.
10. Impact on Header Compression 10. Impact on Header Compression
Header compression algorithms already accommodate various ways in Header compression algorithms already accommodate various ways in
which the IPv4 ID changes between sequential datagrams [RFC1144] which the IPv4 ID changes between sequential datagrams [RFC1144]
[RFC2508] [RFC3545] [RFC5225]. Such algorithms currently assume that [RFC2508] [RFC3545] [RFC5225]. Such algorithms currently assume that
the IPv4 ID is preserved end-to-end. Some algorithms already allow the IPv4 ID is preserved end-to-end. Some algorithms already allow
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 nonchanging 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 (see footnote 21 of changing ID can make compression less efficient. Such non-changing
IDs have been described in various RFCs (e.g., footnote 21 of
[RFC1144] or cRTP [RFC2508]). When compression can assume a [RFC1144 and cRTP [RFC2508]). When compression can assume a non-
nonchanging IPv4 ID - as with ROHC and ECRTP - efficiency can be changing IPv4 ID - as with ROHC and ECRTP - efficiency can be
increased. increased.
11. Security Considerations 11. Security Considerations
When the IPv4 ID is ignored on receipt (e.g., for atomic datagrams), When the IPv4 ID is ignored on receipt (e.g., for atomic datagrams),
its value becomes unconstrained; that field then can more easily be its value becomes unconstrained; that field then can more easily be
used as a covert channel. For some atomic datagrams - notably those used as a covert channel. For some atomic datagrams - notably those
not protected by IPsec Authentication Header (AH) [RFC4302] - it is not protected by IPsec Authentication Header (AH) [RFC4302] - it is
now possible, and may be desirable, to rewrite the IPv4 ID field to now possible, and may be desirable, to rewrite the IPv4 ID field to
avoid its use as such a channel. avoid its use as such a channel.
skipping to change at page 14, line 12 skipping to change at page 14, line 42
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119 / BCP 14, March 1997. Requirement Levels", RFC 2119 / BCP 14, March 1997.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996. October 1996.
13.2. Informative References 13.2. Informative References
[Be02] Bellovin, S., "A Technique for Counting NATted Hosts", [Be02] Bellovin, S., "A Technique for Counting NATted Hosts",
Internet Measurement Conference, Proceedings of the 2nd ACM Internet Measurement Conference, Proceedings of the 2nd ACM
SIGCOMM Workshop on Internet Measurement, November 2002. SIGCOMM Workshop on Internet Measurement, Nov. 2002.
[Bo11] Boucadair, M., J. Touch, P. Levis, R. Penno, "Analysis of [Bo11] Boucadair, M., J. Touch, P. Levis, R. Penno, "Analysis of
Solution Candidates to Reveal a Host Identifier in Shared Solution Candidates to Reveal a Host Identifier in Shared
Address Deployments", (work in progress), draft-boucadair- Address Deployments", (work in progress), draft-boucadair-
intarea-nat-reveal-analysis, Sept. 2011. intarea-nat-reveal-analysis, Sept. 2011.
[De11] Despres, R. (Ed.), S. Matsushima, T. Murakami, O. Troan, [De11] Despres, R. (Ed.), S. Matsushima, T. Murakami, O. Troan,
"IPv4 Residual Deployment across IPv6-Service networks "IPv4 Residual Deployment across IPv6-Service networks
(4rd)", (work in progress), draft-despres-intarea-4rd, (4rd)", (work in progress), draft-despres-intarea-4rd, Mar.
March 2011. 2011.
[Ma11] Macker, J. (Ed.), "Simplified Multicast Forwarding," (work
in progress), draft-ietf-manet-smf-12, Jul. 2011.
[Pe11] Perreault, S., (Ed.), I. Yamagata, S. Miyakawa, A. [Pe11] Perreault, S., (Ed.), I. Yamagata, S. Miyakawa, A.
Nakagawa, H. Ashida, "Common requirements of IP address Nakagawa, H. Ashida, "Common requirements of IP address
sharing schemes", (work in progress), draft-ietf-behave- sharing schemes", (work in progress), draft-ietf-behave-
lsn-requirements, March 2011. lsn-requirements, Mar. 2011.
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, Feb. [RFC1144] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, Feb.
1990. 1990.
[RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, Dec. 1998.
[RFC2508] Casner, S., V. Jacobson. "Compressing IP/UDP/RTP Headers [RFC2508] Casner, S., V. Jacobson. "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links", RFC 2508, Feb. 1999. for Low-Speed Serial Links", RFC 2508, Feb. 1999.
[RFC2671] Vixie,P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [RFC2671] Vixie,P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999. Aug. 1999.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January Address Translator (Traditional NAT)", RFC 3022, Jan. 2001.
2001.
[RFC3545] Koren, T., S. Casner, J. Geevarghese, B. Thompson, P. [RFC3545] Koren, T., S. Casner, J. Geevarghese, B. Thompson, P.
Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High
Delay, Packet Loss and Reordering", RFC 3545, July 2003. Delay, Packet Loss and Reordering", RFC 3545, Jul. 2003.
[RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson, Ed., G. [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson, Ed., G.
Fairhurst, Ed., "The Lightweight User Datagram Protocol Fairhurst, Ed., "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004. (UDP-Lite)", RFC 3828, Jul. 2004.
[RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, Dec. 2005. Protocol", RFC 4301, Dec. 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, Dec. 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, Dec. 2005.
[RFC4443] Conta, A., S. Deering, M. Gupta (Ed.), "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Version
6 (IPv6) Specification", RFC 4443, March. 2006.
[RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol",
RFC 4960, Sep. 2007. RFC 4960, Sep. 2007.
[RFC4963] Heffner, J., M. Mathis, B. Chandler, "IPv4 Reassembly [RFC4963] Heffner, J., M. Mathis, B. Chandler, "IPv4 Reassembly
Errors at High Data Rates," RFC 4963, July 2007. Errors at High Data Rates," RFC 4963, Jul. 2007.
[RFC5225] Pelletier, G., K. Sandlund, "RObust Header Compression [RFC5225] Pelletier, G., K. Sandlund, "RObust Header Compression
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP- Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-
Lite", RFC 5225, Apr. 2008. Lite", RFC 5225, Apr. 2008.
[RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and
Adaptation Layer (SEAL)", RFC 5320, Feb. 2010. Adaptation Layer (SEAL)", RFC 5320, Feb. 2010.
[RFC6219] Li, X., C. Bao, M. Chen, H. Zhang, J. Wu, "The China [RFC6219] Li, X., C. Bao, M. Chen, H. Zhang, J. Wu, "The China
Education and Research Network (CERNET) IVI Translation Education and Research Network (CERNET) IVI Translation
Design and Deployment for the IPv4/IPv6 Coexistence and Design and Deployment for the IPv4/IPv6 Coexistence and
Transition", RFC 6219, May 2011. Transition", RFC 6219, May 2011.
14. Acknowledgments 14. Acknowledgments
This document was inspired by of numerous discussions among the This document was inspired by of numerous discussions among the
authors, Jari Arkko, Lars Eggert, Dino Farinacci, and Fred Templin, authors, Jari Arkko, Lars Eggert, Dino Farinacci, and Fred Templin,
as well as members participating in the Internet Area Working Group. as well as members participating in the Internet Area Working Group.
Detailed feedback was provided by Gorry Fairhurst, Mike Heard, Erik Detailed feedback was provided by Gorry Fairhurst, Brian Haberman,
Nordmark, Carlos Pignataro, and Dan Wing. This document originated as Ted Hardie, Mike Heard, Erik Nordmark, Carlos Pignataro, and Dan
an Independent Stream draft co-authored by Matt Mathis, PSC, and his Wing. This document originated as an Independent Stream draft co-
contributions are greatly appreciated. authored by Matt Mathis, PSC, and his contributions are greatly
appreciated.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Author's Address Author's Address
Joe Touch Joe Touch
USC/ISI USC/ISI
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292-6695 Marina del Rey, CA 90292-6695
U.S.A. U.S.A.
 End of changes. 56 change blocks. 
143 lines changed or deleted 168 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/