draft-ietf-intarea-ipv4-id-update-00.txt   draft-ietf-intarea-ipv4-id-update-01.txt 
Internet Area WG J. Touch Internet Area WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Updates: 791,1122,2003 March 26, 2010 Updates: 791,1122,2003 October 22, 2010
Intended status: Proposed Standard Intended status: Proposed Standard
Expires: September 2010 Expires: April 2011
Updated Specification of the IPv4 ID Field Updated Specification of the IPv4 ID Field
draft-ietf-intarea-ipv4-id-update-00.txt draft-ietf-intarea-ipv4-id-update-01.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 September 26, 2010. This Internet-Draft will expire on April 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
The IPv4 Identification (ID) field enables fragmentation and The IPv4 Identification (ID) field enables fragmentation and
reassembly, and as currently specified is required to be unique reassembly, and as currently specified is required to be unique
within the maximum lifetime on all IP packets. If enforced, this within the maximum lifetime on all datagrams. If enforced, this
uniqueness requirement would limit all connections to 6.4 Mbps. uniqueness requirement would limit all connections to 6.4 Mbps.
Because this is obviously not the case, it is clear that existing Because this is obviously not the case, it is clear that existing
systems violate the current specification. This document updates the systems violate the current specification. This document updates the
specification of the IP ID field to more closely reflect current specification of the IPv4 ID field to more closely reflect current
practice and to more closely match IPv6, so that the field is defined practice and to more closely match IPv6 so that the field is defined
only when a packet is actually fragmented and that fragmentation only when a datagram is actually fragmented. It also discusses the
occurs only at originating hosts or their equivalent. When impact of these changes on how datagrams are used.
fragmentation occurs, this document recommends that the ID field be
unique within the reordering context, rather than an arbitrary,
unenforced upper bound on packet lifetime.
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..............................................4 3. The IPv4 ID Field..............................................3
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.......................6 6.1. IPv4 ID Used Only for Fragmentation.......................7
6.2. Avoiding IPv4 ID Repetition and Its Impacts...............7 6.2. Encourage Safe IPv4 ID Use................................8
6.3. Encourage Safe ID Use.....................................8 6.3. IPv4 ID Requirements That Persist.........................9
7. Updates to Existing Standards..................................9 7. Impact on Datagram Use.........................................9
7.1. Updates to RFC 791........................................9 8. Updates to Existing Standards.................................10
7.2. Updates to RFC 1122......................................10 8.1. Updates to RFC 791.......................................10
7.3. Updates to RFC 1812......................................11 8.2. Updates to RFC 1122......................................11
7.4. Updates to RFC 2003......................................11 8.3. Updates to RFC 2003......................................11
8. Impacts on NATs and Tunnel Ingresses..........................11 9. Impact on NATs and Tunnel Ingresses...........................12
9. Impact on Header Compression..................................12 10. Impact on Header Compression.................................13
10. Transitioning to This Update.................................12
11. Security Considerations......................................13 11. Security Considerations......................................13
12. IANA Considerations..........................................13 12. IANA Considerations..........................................13
13. References...................................................14 13. References...................................................14
13.1. Normative References....................................14 13.1. Normative References....................................14
13.2. Informative References..................................14 13.2. Informative References..................................14
14. Acknowledgments..............................................15 14. Acknowledgments..............................................15
1. Introduction 1. Introduction
In IPv4, the IP 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 packet 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]. All packets between Maximum Segment Lifetime (MSL) [RFC791][RFC1122]. As currently
a source and destination of a given protocol must have unique ID specified, all datagrams between a source and destination of a given
values over a period of an MSL, which is typically interpreted as two protocol must have unique IPv4 ID values over a period of this MSL,
minutes (120 seconds). This uniqueness is currently specified as for which is typically interpreted as two minutes (120 seconds). This
all packets, regardless of fragmentation settings. uniqueness is currently specified as for all datagrams, regardless of
fragmentation settings.
The uniqueness of the IP ID is a known problem for high speed The uniqueness of the IPv4 ID is a known problem for high speed
devices, because it limits the speed of a single protocol between two devices; if strictly enforced, it would limit the speed of a single
endpoints to 6.4 Mbps for typical MTUs of 1500 bytes [RFC4963]. This protocol between two endpoints to 6.4 Mbps for typical MTUs of 1500
strongly indicates that the uniqueness of the IPv4 ID is moot, as has bytes [RFC4963]. It is common for a single protocol to operate far in
already been noted. excess of these rates, which strongly indicates that the uniqueness
of the IPv4 ID as specified is already moot.
This document updates the specification of the IP ID field to more This document updates the specification of the IPv4 ID field to more
closely reflect current practice, and to more closely match IPv6, in closely reflect current practice, and to include considerations taken
which the field is defined only when a packet is actually fragmented into account during the specification of the similar field in IPv6.
and in which fragmentation occurs only at the source. It also updates
the recommended uniqueness interval to support the impact of
reordering on reassembly, rather than using an arbitrary and
unenforceable packet lifetime.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, the characters ">>" proceeding an indented line(s) In this document, the characters ">>" proceeding an indented line(s)
indicates a requirement using the key words listed above. This indicates a requirement using the key words listed above. This
convention aids reviewers in quickly identifying or finding this convention aids reviewers in quickly identifying or finding this
document's explicit requirements. document's explicit requirements.
3. The IPv4 ID Field 3. The IPv4 ID Field
IP supports packet fragmentation, where large packets are split into IP supports datagram fragmentation, where large datagrams are split
smaller components to traverse links with limited maximum into smaller components to traverse links with limited maximum
transmission units (MTUs). Fragments are indicated in different ways transmission units (MTUs). Fragments are indicated in different ways
in IPv4 and IPv6: in IPv4 and IPv6:
o In IPv4, the header contains four fields: Identification (ID), o In IPv4, fragments are indicated using four fields of the basic
Fragment Offset, a "Don't Fragment" flag (DF), and a "More header: Identification (ID), Fragment Offset, a "Don't Fragment"
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 MF flag similar to their includes an ID, Fragment Offset, and MF flag similar to their
counterparts in IPv4 [RFC2460] 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. The IPv6 prevent downstream devices from initiating fragmentation (i.e., IPv6
fragment header is present only when a packet has been fragmented, so always acts as if DF=1). The IPv6 fragment header is present only
the ID field is not present for non-fragmented packets, and thus is when a datagram has been fragmented, so the ID field is not present
meaningful only for fragments. Finally, the ID field is 32 bits, and for non-fragmented datagrams, and thus is meaningful only for
unique per source/destination address pair for IPv6, whereas for IPv4 fragments. Finally, the IPv6 ID field is 32 bits, and required unique
it is only 16 bits and unique per source/destination/protocol triple. per source/destination address pair for 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 packet are matched address, and protocol, fragments of an original datagram are matched
based on their IP 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).
The ID field has been discussed as useful in other ways. It can be The IPv4 ID field can be useful for other purposes. The field has
used to detect and discard duplicate packets, e.g., at congested been suggested as a way to detect and remove duplicate datagrams,
routers (see Sec. 3.2.1.5 of [RFC1122]). e.g., at congested routers, although this has been noted and no
current deployments are known (see Sec. 3.2.1.5 of [RFC1122]). It can
similarly be used at end hosts to reduce the impact of duplication on
higher-layer protocols (e.g., additional processing in TCP, or the
need for application-layer duplicate suppression in UDP).
The ID field can also be useful for duplicate avoidance and ICMP The IPv4 ID field can also be used to validate payloads of ICMP
validation. The field can be used at routers or receiving hosts to responses as matching the originally transmitted datagram at a host
remove duplicate packets. The IP ID field can be used to validate [RFC4963]. In this case, the ICMP payload - an IP datagram prefix -
payloads of ICMP responses as matching the originally transmitted is matched against a cache of recently transmitted IP headers to
packet at a host [RFC4963]. At a tunnel ingress, the ID enables check that the received ICMP reflects a transmitted datagram. At a
returning ICMP messages to be matched to a cache of recently tunnel ingress, the IPv4 ID enables returning ICMP messages to be
transmitted packets, to support ICMP relaying [RFC2003]. matched to a cache of recently transmitted datagrams, to support ICMP
relaying, with similar challenges [RFC2003].
These latter uses require that the IP ID be unique across all Uses of the IPv4 ID field beyond fragmentation and reassembly require
packets, not only when fragmentation is enabled. This document that the IPv4 ID be unique across all datagrams, not only when
deprecates all such non-fragmentation uses. fragmentation is enabled. This document deprecates all such non-
fragmentation uses.
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 packet 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 sum of all TCP does not repeat within 120 seconds means that the aggregate of all
connections of a given protocol between two endpoints is limited to TCP connections of a given protocol between two endpoints is limited
roughly 286 Mbps; at a more typical MTU of 1500 bytes, this speed to roughly 286 Mbps; at a more typical MTU of 1500 bytes, this speed
drops to 6.4 Mbps [RFC4963]. This limit currently applies for all drops to 6.4 Mbps [RFC4963]. This limit currently applies for all
IPv4 packets, regardless of whether fragmentation is enabled or IPv4 datagrams within a single protocol (i.e., the IPv4 protocol
inhibited, and whether a packet is fragmented or not. field) between two IP addresses, regardless of whether fragmentation
is enabled or inhibited, and whether a datagram is fragmented or not.
IPv6, even at typical MTUs, is capable of 18.7 Tbps when fragments IPv6, even at typical MTUs, is capable of 18.7 Tbps with
are present, due to the larger 32-bit ID field. When fragmentation is fragmentation between two endpoints as an aggregate across all
not used the field is absent, and so IPv6 speeds are not limited by protocols, due to the larger 32-bit ID field (and the fact that the
the ID field uniqueness. IPv6 next-header field, the equivalent of the IPv4 protocol field, is
not considered in differentiating fragments). When fragmentation is
not used the field is absent, and in that case IPv6 speeds are not
limited by the ID field uniqueness.
Note also that 120 seconds is only an estimate on the maximum packet Note also that 120 seconds is only an estimate on the maximum
lifetime. It is loosely based on half maximum value of the IP TTL datagram lifetime. It is loosely based on half maximum value of the
field, which is represents 0-255 seconds, although it must be IP TTL field (255), measured in seconds, because the TTL is
decremented by 1 second for each router on a path even when held for decremented not only for each hop, but also for each second a
less than a second [RFC791]. Network delays are incurred in other datagram is held at a router (as implied in [RFC791]). Network delays
ways, e.g., satellite links, which can add seconds of delay even are incurred in other ways, e.g., satellite links, which can add
though the TTL is not affected. There is no enforcement mechanism to seconds of delay even though the TTL is often not decremented by a
ensure that packets older than 120 seconds are discarded. corresponding amount. There is thus no enforcement mechanism to
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 have been performed with COTS
systems at these speeds for over a decade. This strongly suggests systems over wide-area paths at these speeds for over a decade. This
that IPv4 ID uniqueness has been moot for a long time. strongly suggests that IPv4 ID uniqueness has been moot for a long
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 ID field only for fragmentation o Use the IPv4 ID field only for fragmentation
o Avoid ID repetition and its impacts o Avoiding a performance impact when the IPv4 ID field is used
o Encourage more safe use of the ID field o Encourage safe operation when the IPv4 ID field is used
There are two kinds of packets used in the following discussion: There are two kinds of datagrams used in the following discussion,
named as follows:
Atomic packets: packets not yet having been fragmented (MF=0 and o Atomic datagrams: datagrams not yet having been fragmented (MF=0
fragment offset=0) and for which further fragmentation has been and fragment offset=0) and for which further fragmentation has
inhibited (DF=1), i.e., as a C-code expression: been inhibited (DF=1), i.e., as a C-code expression:
(DF==1)&&(MF==0)&&(frag_offset==0) (DF==1)&&(MF==0)&&(frag_offset==0)
o Non-atomic packets: packets which have either already been o Non-atomic datagrams: datagrams which have either already been
fragmented, i.e.: fragmented, i.e.:
(MF=1)||(frag_offset>0) (MF=1)||(frag_offset>0)
or for which fragmentation remains possible (DF=0), i.e.: 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) (DF==0)||(MF==1)||(frag_offset>0)
or (equivalently): which can also be expressed as follows, using DeMorgan's Law and
other identities:
~((DF==1)&&(MF==0)&&(frag_offset==0)) ~((DF==1)&&(MF==0)&&(frag_offset==0))
Note that this final expression is the same as "not(atomic)".
6.1. IPv4 ID Used Only for Fragmentation 6.1. IPv4 ID Used Only for Fragmentation
Although at least one document suggests the ID field has other uses, Although RFC1122 suggests the IPv4 ID field has other uses, this
we assert here that the ID field is defined only for fragmentation document asserts that this field is defined only for fragmentation
and reassembly. and reassembly.
o >> The IPv4 ID field of MUST be ignored except for packet o >> IPv4 ID field MUST NOT be used for purposes other than
reassembly. fragmentation and reassembly.
Such devices typically include receiving hosts and tunnel egresses, This has a few implications. In atomic datagrams, the IPv4 ID field
but may include any intermediate device that reassembles a packet, has no meaning, and thus can be set to an arbitrary value, i.e., the
such as a firewall or NAT. The ID field is thus meaningful only for requirement for non-repeating IDs within the address/protocol triple
non-atomic packets that have actually been fragmented, either at the is no longer required for atomic datagrams:
source or elsewhere along the path, and have not been reassembled
before being examined. In atomic packets, the ID field has no
meaning, and thus its values are always to be ignored. Atomic packets
are detected by their DF, MF, and fragmentation offset fields as
defined in Section 6, because such a test is completely backward
compatible; this document thus does not reserve any ID values,
including 0, as distinguished.
Note that this excludes some current practices that use the ID field o >> Originating sources MAY set the IPv4 ID field of atomic
and the remainder of the IP header as a unique tag. This tag has been datagrams to any value.
suggested as a way to detect and remove duplicate packets, e.g., at
congested routers, although this has been noted and no current
deployments are known [RFC1122]. Some hosts use this tag to validate
received ICMPs, in which the ICMP payload - an IP packet prefix - is
matched against a cache of recently transmitted IP headers. This
ensures that the received ICMP reflects a transmitted packet, though
it does not prevent spoofing of ICMPs for attackers that can see
those packets, and like ID reuse will cause problems at high packet
rates. A similar sort of matching can be used in tunnels, to enable
ICMP relaying at the tunnel ingress, with similar challenges
[RFC2003].
Deprecating the use of the IPv4 ID field for these non-reassembly Second, all network nodes, whether at intermediate routers,
uses should have little - if any - impact. IPv4 IDs are already destination hosts, or other devices (e.g., NATs, firewalls, tunnel
frequently repeated, e.g., over even moderately fast connections. egresses), cannot rely on the field:
Duplicate suppression was only suggested, and no impacts of ID reuse
have been noted. Routers are not required to issue ICMPs on any o >> All devices that examine IPv4 headers MUST ignore the IPv4 ID
particular timescale, and so ID repetition should not have been used field of atomic datagrams.
for validation, and again repetition occurs and probably could have
been noticed [RFC1812]. ICMP relaying at tunnel ingresses is The IPv4 ID field is thus meaningful only for non-atomic datagrams -
specified to use soft state rather than a packet cache, and should datagrams that have either already been fragmented, or those for
which fragmentation remains permitted. Atomic datagrams are detected
by their DF, MF, and fragmentation offset fields as explained in
Section 6, because such a test is completely backward compatible;
this document thus does not reserve any IPv4 ID values, including 0,
as distinguished.
Deprecating the use of the IPv4 ID field for non-reassembly uses
should have little - if any - impact. IPv4 IDs are already frequently
repeated, e.g., over even moderately fast connections. Duplicate
suppression was only suggested [RFC1122], and no impacts of IPv4 ID
reuse have been noted. Routers are not required to issue ICMPs on any
particular timescale, and so IPv4 ID repetition should not have been
used for validation, and again repetition occurs and probably could
have been noticed [RFC1812]. ICMP relaying at tunnel ingresses is
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. Avoiding IPv4 ID Repetition and Its Impacts 6.2. Encourage Safe IPv4 ID Use
This document specifies that IPv4 be modified to more closely match This document makes further changes to the specification of the IPv4
IPv6's fragmentation constraints, to permit fragmentation only at ID field and its use to encourage its safe use as corollary
devices that control the uniqueness of the IP ID field, e.g., requirements changes as follows.
sources, tunnel ingresses (for the outer header), and packets emitted
from a NAT to its public side (see Section 8).
o >> Sources SHOULD set DF=1. RFC 1122 discusses that TCP retransmits a segment it may be possible
to reuse the IPv4 ID (see Section 8.2). This can make it difficult
for a source to avoid IPv4 ID repetition for received fragments. RFC
1122 concludes that this behavior "is not useful"; this document
formalizes that conclusion as follows:
o >> IPv4 fragmentation SHOULD be limited to the originating source, o >> The IPv4 ID of non-atomic datagrams MUST NOT be reused when
even when the DF field allows it. sending a copy of an earlier non-atomic datagram.
Keep in mind that a source is any device that uses one of its RFC 1122 also suggests that fragments can overlap [RFC1122]. Such
assigned IP addresses as a source IP address in emitted packets. This overlap can occur if successive retransmissions are fragmented in
includes hosts, routers when originating packets, packets emitted different ways but the same reassembly IPv4 ID.
from NATs (see Section 8), and tunnel ingresses.
It may not be possible for sources to know whether all of the above This overlap is noted as the result of reusing IPv4 IDs when
specifications are satisfied. As a result, we recommend that: retransmitting datagrams, which this document deprecates. Overlapping
fragments are themselves a hazard [RFC4963]. As a result:
o >> Sources unable to meet the non-repeating IP ID requirement o >> Overlapping datagrams MUST be silently ignored during
above MUST NOT emit non-atomic packets. reassembly.
In other words, such sources can emit only non-fragmented packets The IPv4 ID of non-atomic datagrams also needs to remain stable, to
where DF has been set. Such sources can repeat the ID field for ensure that existing fragments are not reassembled incorrectly, as
atomic packets, as it is intended to be ignored. well as to ensure that the uniqueness of the IDs as generated by the
source is not undermined.
Sources emitting non-atomic IPv4 packets need to set the ID field For atomic datagrams, because the IPv4 ID field is ignored on
sufficient to support reassembly, and encourages the use of stronger receipt, it can be possible to rewrite the field. Rewriting can be
transport layer validation where possible. Uniqueness over a two useful to prevent use of the field as a covert channel, or to enable
minute interval may be excessive to support reassembly in some more efficient header compression. However, the IPv4 ID field needs
environments, and is clearly already being ignored. to remain immutable when it is validated by higher layer protocols,
such as IPsec. As a result:
o >> Sources emitting non-atomic IPv4 packets SHOULD NOT repeat ID o >> The IPv4 ID field of non-atomic datagrams, or protected atomic
field values within a given source IP, destination IP, and datagrams MUST NOT change in transit; the IPv4 ID field of
protocol tuple over the period that fragment reordering would unprotected atomic datagrams MAY be changed in transit.
affect reassembly.
It is impractical to assert "MUST NOT" here, because there is no Protected datagrams are defined as those whose header fields are
strict enforcement on packet lifetime and because sources may not be covered by integrity validation, such as IPsec AH [RFC4302].
able to determine the reordering period.
o >> Sources that cannot ensure safe IPv4 ID generation and that 6.3. IPv4 ID Requirements That Persist
allow DF=0 SHOULD employ integrity checks that would detect mis-
reassembled fragments, e.g, as in SEAL [RFC5320]. Applications
SHOULD NOT use UDP without checksums [RFC793], and SHOULD be very
careful in their use of UDP-Lite [RFC3828] in such environments.
Additional integrity checks can be employed using tunnels, as in This document does not relax the IPv4 ID field uniqueness
SEAL, IPsec, or SCTP [RFC4301][RFC4960][RFC5320]. Such checks can requirements of [RFC791] for non-atomic datagrams, i.e.:
avoid the reassembly hazards that can occur when using UDP and TCP
checksums [RFC4963].
6.3. Encourage Safe ID Use o >> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
values within one MSL for a given source address/destination
address/protocol triple.
This document makes further changes to the specification of the IPv4 Such sources include originating hosts, tunnel ingresses, and NATs
ID field and its use to encourage its safe use as follows. (see Section 9).
RFC 1122 discusses that TCP retransmits a segment it may be possible This document does not relax the requirement that all network devices
to reuse the IP ID (see Section 7.2). This can make it difficult for honor the DF bit, i.e.:
a source to avoid ID repetition for received fragments. RFC 1122
concludes that this behavior "is not useful"; this document
formalizes that conclusion as follows:
o >> The IP ID MUST NOT be reused when sending a copy of an earlier o >> IPv4 datagrams whose DF=1 MUST NOT be fragmented.
non-ATOMIC packet.
RFC 1122 also suggests that fragments can overlap [RFC1122]. Such o >> IPv4 datagram transit devices MUST NOT clear the DF bit.
overlap can occur if successive retransmissions use different
packetizing but the same reassembly Id.
This overlap is noted as the result of reusing IDs when In specific, DF=1 prevents fragmenting datagrams that are integral.
retransmitting packets, which this document deprecates. Overlapping DF=1 also prevents further fragmenting received fragments.
fragments are themselves a hazard [RFC4963]. As a result: Fragmentation, either of an unfragmented datagram or of fragments, is
current permitted only where DF=0 in the original emitted datagram,
and this document does not change that requirement.
o >> Overlapping packets MUST be silently ignored during reassembly. 7. Impact on Datagram Use
7. Updates to Existing Standards The following is a summary of the recommendations that are the result
of the previous changes to the IPv4 ID field specification.
Because atomic datagrams can use arbitrary IPv4 ID values, the ID
field no longer imposes a performance impact in those cases. However,
the performance impact remains for non-atomic datagrams. As a result:
o >> Sources of non-atomic IPv4 datagrams MUST rate-limit their
output to comply with the ID uniqueness requirements.
Such sources include, in particular, DNS over UDP [RFC2671].
Because there is no strict definition of the MSL, reassembly hazards
exist regardless of the IPv4 ID reuse interval or the reassembly
timeout. As a result:
o >> Higher layer protocols SHOULD verify the integrity of IPv4
datagrams, e.g., using a checksum or hash that can detect
reassembly errors (the UDP checksum is weak in this regard, but
better than nothing), as in SEAL [RFC5320].
Additional integrity checks can be employed using tunnels, as in
SEAL, IPsec, or SCTP [RFC4301][RFC4960][RFC5320]. Such checks can
avoid the reassembly hazards that can occur when using UDP and TCP
checksums [RFC4963], or when using partial checksums as in UDP-Lite
[RFC3828]. Because such integrity checks can avoid the impact of
reassembly errors:
o >> Sources of non-atomic IPv4 datagrams using strong integrity
checks MAY reuse the ID within MSL values smaller than is typical.
Note, however, that such more frequent reuse can still result in
corrupted reassembly and poor throughput, although it would not
propagate reassembly errors to higher layer protocols.
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.
7.1. Updates to RFC 791 8.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
identification field to a value that must be unique for that identification field to a value that must be unique for that
source-destination pair and protocol for the time the datagram source-destination pair and protocol for the time the datagram
will be active in the internet system. will be active in the internet system.
And later that: And later that:
Thus, the sender must choose the Identifier to be unique for this Thus, the sender must choose the Identifier to be unique for this
source, destination pair and protocol for the time the datagram source, destination pair and protocol for the time the datagram
(or any fragment of it) could be alive in the internet. (or any fragment of it) could be alive in the internet.
It seems then that a sending protocol module needs to keep a table It seems then that a sending protocol module needs to keep a table
of Identifiers, one entry for each destination it has communicated of Identifiers, one entry for each destination it has communicated
with in the last maximum packet lifetime for the internet. with in the last maximum datagram lifetime for the internet.
However, since the Identifier field allows 65,536 different However, since the Identifier field allows 65,536 different
values, some host may be able to simply use unique identifiers values, some host may be able to simply use unique identifiers
independent of destination. independent of destination.
It is appropriate for some higher level protocols to choose the It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same would be enhanced if the retransmission carried the same
identifier as the original transmission since fragments of either identifier as the original transmission since fragments of either
datagram could be used to construct a correct TCP segment. datagram could be used to construct a correct TCP segment.
This document changes RFC 791 as follows: This document changes RFC 791 as follows:
o >> The IP ID is not defined if the packet (datagram) is atomic. IP o IPv4 ID uniqueness applies to only non-atomic datagrams.
packet sources MAY use any value as ID; all such values MUST BE
ignored on examination at intermediate nodes and destinations.
o >> The IP ID of non-atomic packets MUST BE unique for the time
where fragments are expected to overlap.
o >> Hosts SHOULD emit only atomic packets (i.e., not fragmented at
the source, and with DF=1).
We do not expect that it will be useful to involve higher-level o Non-atomic IPv4 datagrams retransmitted by higher level protocols
protocols in determining ID values. are no longer permitted to reuse the ID value.
7.2. Updates to RFC 1122 8.2. Updates to RFC 1122
RFC 1122 states that: RFC 1122 states that:
3.2.1.5 Identification: RFC-791 Section 3.2 3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in host MAY optionally retain the same Identification field in
the copy. the copy.
DISCUSSION: DISCUSSION:
skipping to change at page 10, line 48 skipping to change at page 11, line 39
original. There are two suggested advantages: (1) if the original. There are two suggested advantages: (1) if the
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 IP ID field MUST NOT be used for duplicate detection or o The IPv4 ID field is no longer permitted for duplicate detection.
removal.
o >> IP ID values MUST NOT be repeated when packets are
retransmitted.
o >> IP packet fragments MUST NOT overlap.
7.3. Updates to RFC 1812
There are no updates to RFC1812.
7.4. Updates to RFC 2003
RFC 2003 states that:
Identification, Flags, Fragment Offset
These three fields are set as specified in [RFC791]. o The IPv4 ID field is no longer repeatable for higher level
However, if the "Don't Fragment" bit is set in the inner IP protocol retransmission.
header, it MUST be set in the outer IP header; if the "Don't
Fragment" bit is not set in the inner IP header, it MAY be
set in the outer IP header, as described in Section 5.1.
This document changes RFC 2003 as follows: o IPv4 datagram fragments no longer are permitted to overlap.
o >> IP-in-IP tunnels SHOULD emit only atomic packets. 8.3. Updates to RFC 2003
Note that this recommendation applies to all tunnels, but the focus This document updates how IPv4-in-IPv4 tunnels create IPv4 ID values
of this document is IPv4 requirements, so its explicit requirements for the IPv4 outer header [RFC2003], but only in the same way as for
focus on IPv4 cases. any other IPv4 datagram source.
8. Impacts on NATs and Tunnel Ingresses 9. Impact on NATs and Tunnel Ingresses
Network address translators (NATs) and address/port translators Network address translators (NATs) and address/port translators
(NAPTs) rewrite IP fields, and tunnel ingresses (using IP (NAPTs) rewrite IP fields, and tunnel ingresses (using IPv4
encapsulation) copy and modify some IP fields, so all are considered encapsulation) copy and modify some IPv4 fields, so all are
sources, as do any devices that rewrite any portion of the IP source, considered sources, as do any devices that rewrite any portion of the
IP destination, IP protocol, and IP ID tuple for non-atomic packets source address, destination address, protocol, and ID tuple for non-
[RFC3022]. As a result, they are subject to all the requirements of atomic datagrams [RFC3022]. As a result, they are subject to all the
any source, as has been noted. requirements of any source, as has been noted.
NATs present a particularly challenging situation for fragmentation. NATs present a particularly challenging situation for fragmentation.
Because NATs overwrite portions of the reassembly tuple in both Because NATs overwrite portions of the reassembly tuple in both
directions, they can destroy tuple uniqueness and result in a directions, they can destroy tuple uniqueness and result in a
reassembly hazard. Not only do NATs need to behave as a source for reassembly hazard. Whenever IPv4 source address, destination address,
the purposes of this document, but also: or protocol fields are modified, a NAT needs to ensure that the ID
field is generated appropriately, rather than simply copied from the
incoming datagram. In specific:
o >> NATs MUST either silently drop fragments or reassemble them o >> NATs MUST ensure that the IPv4 ID field of datagrams whose
before translating and emitting them. address or protocol are translated comply with requirements as if
the datagram were sourced by the NAT.
Problems with transmitting fragments through NATs are already known; This compliance means that the IPv4 ID field of non-atomic datagrams
translation is based on the transport port number, which is present translated at a NAT need to obey the uniqueness requirements of any
in only the first fragment anyway [RFC3022]. This document IPv4 datagram source. Unfortunately, fragments already violate that
requirement, as they repeat an IPv4 ID within the MSL for a given
source address, destination address, and protocol triple.
Such problems with transmitting fragments through NATs are already
known; translation is based on the transport port number, which is
present in only the first fragment anyway [RFC3022]. This document
underscores the point that not only is reassembly (and possibly underscores the point that not only is reassembly (and possibly
subsequent fragmentation) required for translation, it is required subsequent fragmentation) required for translation, it can be used to
for IP ID uniqueness. avoid issues with IPv4 ID uniqueness.
Note that NATs/NAPTs already need to exercise special care when Note that NATs/NAPTs already need to exercise special care when
emitting packets on their public side, because merging packets from emitting datagrams on their public side, because merging datagrams
many sources onto a single outgoing source IP address can result in from many sources onto a single outgoing source address can result in
IP ID collisions. This situation precedes this document, and is not IPv4 ID collisions. This situation precedes this document, and is not
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 [Ni09]. grade" NATs [Ni09].
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 packet as arriving at act as routers for the inner headers (i.e., the datagram as arriving
the tunnel ingress). Ingresses can fragment as originating sources of at the tunnel ingress). Ingresses can fragment as originating sources
the outer header, because they control the uniqueness of that IP ID of the outer header, because they control the uniqueness of that IPv4
field. They need to avoid fragmenting the packet at the inner header, ID field. They need to avoid fragmenting the datagram at the inner
for the same reasons as any intermediate device, as noted elsewhere header, for the same reasons as any intermediate device, as noted
in this document. elsewhere in this document.
9. 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 IP ID changes between sequential packets. Such algorithms which the IPv4 ID changes between sequential datagrams. Such
already need to preserve the IP ID. This document relaxes that algorithms currently need to preserve the IPv4 ID.
constraint, making preservation optional for most atomic packets as a
result:
>> Header compression MAY preserve the IP ID of atomic packets that
are not protected by IPsec AH [RFC4302]. The IP ID of non-atomic
packets, and those of packets protected by IPsec AH MUST be
preserved.
Note that this can impact the efficiency of header compression in
various ways. When compression can assume a nonchanging ID,
efficiency can be increased. However, when compression assumes a
changing ID as a default, having a non-changing ID can make
compression less efficient (see footnote 21 of [RFC1144], which is
optimized for non-atomic packets).
10. Transitioning to This Update
?? Do we need this transition?
?? Do we want to say when to stop the transition?
During the transition period, there may continue to be tunnel
ingresses and NATs that fragment even when the DF bit is set, or that
validate ICMP payloads based on cached packets. It may be useful to
use a small ID space to help detect such behaviors without causing
full disruption, as might occur by using a single value when the DF
flag is set (e.g., ID=0).
As a result, during the transition period, this document recommends
that:
>> During the transition period, a small ID space SHOULD be used to When compression can assume a nonchanging IPv4 ID, efficiency can be
assist with debugging and detection; such a space SHOULD use the increased. However, when compression assumes a changing ID as a
lower bits (i.e., lower 4 bits) of the ID field and clear (i.e., default, having a non-changing ID can make compression less efficient
zero) the remaining high order bits. (see footnote 21 of [RFC1144], which is optimized for non-atomic
datagrams). This document thus does not recommend whether atomic IPv4
datagrams should use nonchanging or changing IDs, but rather allows
those IDs to be modified in transit (as per Sec. 6.2), which can be
used to accommodate more efficient compression as desired.
11. Security Considerations 11. Security Considerations
This document attempts to address the security considerations This document attempts to address the security considerations
associated with fragmentation in IPv4 [RFC4459]. associated with fragmentation in IPv4 [RFC4459].
When the IPv4 ID is ignored on receipt (e.g., for atomic packets), 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 packets - notably those not used as a covert channel. For some atomic datagrams - notably those
protected by IPsec Authentication Header (AH) [RFC4302] - it is not protected by IPsec Authentication Header (AH) [RFC4302] - it is
possible, and may be desirable, to rewrite the ID field to avoid its now possible, and may be desirable, to rewrite the IPv4 ID field to
use as such a channel. avoid its use as such a channel.
The IP ID also now adds much less entropy of the header of an IP The IPv4 ID also now adds much less entropy of the header of a
packet. The ID had previously been unique (for a given IP datagram. The IPv4 ID had previously been unique (for a given
source/address pair, and protocol field) within 2MSL, although this source/address pair, and protocol field) within one MSL, although
requirement was not enforced and clearly is typically ignored. IDs of this requirement was not enforced and clearly is typically ignored.
non-atomic packets are now required unique only within the expected IDs of non-atomic datagrams are now required unique only within the
reordering of fragments, which could substantially reduce the amount expected reordering of fragments, which could substantially reduce
of entropy in that field. The IP ID of atomic packets is not required the amount of entropy in that field. The IPv4 ID of atomic datagrams
unique, and so contributes no entropy to the header. is not required unique, and so contributes no entropy to the header.
The deprecation of the ID field's uniqueness for atomic packets can The deprecation of the IPv4 ID field's uniqueness for atomic
defeat the ability to count devices behind a NAT [Be02]. This is not datagrams can defeat the ability to count devices behind a NAT
intended as a security feature, however. [Be02]. This is not intended as a security feature, however.
12. IANA Considerations 12. IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
The RFC Editor should remove this section prior to publication The RFC Editor should remove this section prior to publication
13. References 13. References
13.1. Normative References 13.1. Normative References
skipping to change at page 14, line 32 skipping to change at page 14, line 34
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, November 2002.
[Ni09] Nishitani, T., I. Yamagata, S. Miyakawa, A. Nakagawa, H. [Ni09] Nishitani, T., I. Yamagata, S. Miyakawa, A. Nakagawa, H.
Ashida, "Common Functions of Large Scale NAT (LSN) ", (work Ashida, "Common Functions of Large Scale NAT (LSN) ", (work
in progress), draft-nishitani-cgn-03, Nov. 2009. in progress), draft-nishitani-cgn-05, July 2010.
[RFC793] Postel, J., "User Datagram Protocol", RFC 793 / STD 6,
August 1980.
[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, December 1998.
[RFC2671] Vixie,P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 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, January
2001. 2001.
[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, July 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.
skipping to change at page 15, line 27 skipping to change at page 15, line 27
Errors at High Data Rates," RFC 4963, July 2007. Errors at High Data Rates," RFC 4963, July 2007.
[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.
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 Carlos Pignataro. This document Detailed feedback was provided by Carlos Pignataro and Gorry
originated as an Independent Stream draft co-authored by Matt Mathis, Fairhurst. This document originated as an Independent Stream draft
PSC, and his contributions are greatly appreciated. co-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. 87 change blocks. 
321 lines changed or deleted 323 lines changed or added

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