draft-ietf-intarea-ipv4-id-update-03.txt   draft-ietf-intarea-ipv4-id-update-04.txt 
Internet Area WG J. Touch Internet Area WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Updates: 791,1122,2003 September 14, 2011 Updates: 791,1122,2003 September 16, 2011
Intended status: Proposed Standard Intended status: Proposed Standard
Expires: March 2012 Expires: March 2012
Updated Specification of the IPv4 ID Field Updated Specification of the IPv4 ID Field
draft-ietf-intarea-ipv4-id-update-03.txt draft-ietf-intarea-ipv4-id-update-04.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 14, 2012. This Internet-Draft will expire on March 16, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 datagrams. If enforced, this within the maximum lifetime for all datagrams with a given
uniqueness requirement would limit all connections to 6.4 Mbps. source/destination/protocol tuple. If enforced, this uniqueness
Because this is obviously not the case, it is clear that existing requirement would limit all connections to 6.4 Mbps. Because
systems violate the current specification. This document updates the individual connections commonly exceed this speed, it is clear that
specification of the IPv4 ID field in RFC791, RFC1122, and RFC2003 to existing systems violate the current specification. This document
more closely reflect current practice and to more closely match IPv6 updates the specification of the IPv4 ID field in RFC791, RFC1122,
so that the field is defined only when a datagram is actually and RFC2003 to more closely reflect current practice and to more
fragmented. It also discusses the impact of these changes on how closely match IPv6 so that the field's value is defined only when a
datagrams are used. datagram is actually fragmented. It also discusses the impact of
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..............................................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.......................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.................................10 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 NATs/ASMs, Rewriting Devices, and Tunnel Ingresses..11
10. Impact on Header Compression.................................13 10. Impact on Header Compression.................................12
11. Security Considerations......................................13 11. Security Considerations......................................13
12. IANA Considerations..........................................13 12. IANA Considerations..........................................13
13. References...................................................14 13. References...................................................13
13.1. Normative References....................................14 13.1. Normative References....................................13
13.2. Informative References..................................14 13.2. Informative References..................................14
14. Acknowledgments..............................................15 14. Acknowledgments..............................................15
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
uniqueness is currently specified as for all datagrams, regardless of uniqueness is currently specified as for all datagrams, regardless of
fragmentation settings. fragmentation settings.
The uniqueness of the IPv4 ID is a known problem for high speed Uniqueness of the IPv4 ID is commonly violated by high speed devices;
devices; if strictly enforced, it would limit the speed of a single if strictly enforced, it would limit the speed of a single protocol
protocol between two endpoints to 6.4 Mbps for typical MTUs of 1500 between two IP endpoints to 6.4 Mbps for typical MTUs of 1500 bytes
bytes [RFC4963]. It is common for a single protocol to operate far in [RFC4963]. It is common for a single connection to operate far in
excess of these rates, which strongly indicates that the uniqueness excess of these rates, which strongly indicates that the uniqueness
of the IPv4 ID as specified is already moot. of the IPv4 ID as specified is already moot.
This document updates the specification of the IPv4 ID field to more This document updates the specification of the IPv4 ID field to more
closely reflect current practice, and to include considerations taken closely reflect current practice, and to include considerations taken
into account during the specification of the similar field in IPv6. into account during the specification of the similar field in IPv6.
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",
skipping to change at page 4, line 12 skipping to change at page 4, line 12
IP supports datagram fragmentation, where large datagrams are split IP supports datagram fragmentation, where large datagrams are split
into 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, fragments are indicated using four fields of the basic o In IPv4, fragments are indicated using four fields of the basic
header: Identification (ID), Fragment Offset, a "Don't Fragment" header: Identification (ID), Fragment Offset, a "Don't Fragment"
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 MF flag similar to their includes an ID, Fragment Offset, and M (more fragments) flag
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, so 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 fragments. Finally, the IPv6 ID field is 32 bits, and required unique
per source/destination address pair for IPv6, whereas for IPv4 it is per source/destination address pair for IPv6, whereas for IPv4 it is
only 16 bits and required unique per source/destination/protocol only 16 bits and required unique per source/destination/protocol
skipping to change at page 4, line 39 skipping to change at page 4, line 39
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 suggested 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, although this has been noted and no e.g., at congested routers (noted in Sec. 3.2.1.5 of [RFC1122],
current operational deployments are known (see Sec. 3.2.1.5 of proposed experimentally in Simplified Multicast Forwarding [Ma11]).
[RFC1122]; it is proposed experimentally in Simplified Multicast It can similarly be used at end hosts to reduce the impact of
Forwarding [Ma11]). It can similarly be used at end hosts to reduce duplication on higher-layer protocols (e.g., additional processing in
the impact of duplication on higher-layer protocols (e.g., additional TCP, or the need for application-layer duplicate suppression in UDP).
processing in TCP, or the need for application-layer duplicate
suppression in UDP).
The IPv4 ID field can also be used to validate payloads of ICMP The IPv4 ID field is also used in some debugging tools to correlate
responses as matching the originally transmitted datagram at a host. datagrams measured at various locations along a network path. This is
In this case, the ICMP payload - an IP datagram prefix - is matched already insufficient in IPv6 because unfragmented datagrams lack an
against a cache of recently transmitted IP headers to check that the ID, so these tools are already being updated to avoid such reliance
received ICMP reflects a transmitted datagram. At a tunnel ingress, on the ID field.
the IPv4 ID enables returning ICMP messages to be matched to a cache
of recently transmitted datagrams, to support ICMP relaying, with
similar challenges. This is a variant of a method described in Sec. 5
of RFC 2003 [RFC2003].
Uses of the IPv4 ID field beyond fragmentation and reassembly require The ID clearly needs to be unique (within MSL, within the
that the IPv4 ID be unique across all datagrams, not only when src/dst/protocol tuple) to support fragmentation and reassembly, but
fragmentation is enabled. This document deprecates all such non- not all packets are fragmented or allow fragmentation. This document
fragmentation uses. deprecates non-fragementation uses, allowing the ID to be 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 endpoints is limited TCP connections of a given protocol between two IP endpoints is
to roughly 286 Mbps; at a more typical MTU of 1500 bytes, this speed limited to roughly 286 Mbps; at a more typical MTU of 1500 bytes,
drops to 6.4 Mbps [RFC4963]. This limit currently applies for all this speed drops to 6.4 Mbps [RFC4963]. This limit currently applies
IPv4 datagrams within a single protocol (i.e., the IPv4 protocol for all IPv4 datagrams within a single protocol (i.e., the IPv4
field) between two IP addresses, regardless of whether fragmentation protocol field) between two IP addresses, regardless of whether
is enabled or inhibited, and whether a datagram is fragmented or not. fragmentation is enabled or inhibited, and whether a 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 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 is
decremented not only for each hop, but also for each second a decremented not only for each hop, but also for each second a
skipping to change at page 6, line 29 skipping to change at page 6, line 22
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 having been fragmented (MF=0 o Atomic datagrams: datagrams not yet fragmented (MF=0 and fragment
and fragment offset=0) and for which further fragmentation has offset=0) and for which further fragmentation has been inhibited
been inhibited (DF=1), i.e., as a C-code expression: (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) (DF==1)&&(MF==0)&&(frag_offset==0)
o Non-atomic datagrams: datagrams 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: or for which fragmentation remains possible:
(DF=0) (DF==0)
I.e., non-atomic datagrams can be expressed in two equivalent I.e., non-atomic datagrams can be expressed in two equivalent
tests: tests:
(DF==0)||(MF==1)||(frag_offset>0) (DF==0)||(MF==1)||(frag_offset>0)
which can also be expressed as follows, using DeMorgan's Law and which can also be expressed as follows, using DeMorgan's Law and
other identities: 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)". 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 RFC1122 suggests the IPv4 ID field has other uses, and it is Although RFC1122 suggests the IPv4 ID field has other uses, and it is
currently being considered for the experimental Simplfied Mulitcast currently being considered for the experimental Simplfied Mulitcast
Forwarding (SMF) protocol [Ma11], this document asserts that this Forwarding (SMF) protocol [Ma11], this document asserts that this
field 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 o >> IPv4 ID field MUST NOT be used for purposes other than
fragmentation and reassembly. fragmentation and reassembly.
[Note that SMF includes non-ID duplicate packet detection for cases SMF includes non-ID hash-based duplicate packet detection for cases
where the ID field is absent (IPv6), and already defines these for where the ID field is absent (IPv6), and already defines these for
IPv4, where it should be preferred to ID-based duplicate detection IPv4, where it should be preferred to ID-based duplicate detection.
for atomic datagrams if this document proceeds.]
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 o >> Originating sources MAY set the IPv4 ID field of atomic
datagrams to any value. datagrams to any value.
Second, all network nodes, whether at intermediate routers, Second, all network nodes, whether at intermediate routers,
skipping to change at page 9, line 7 skipping to change at page 8, line 49
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. o >> IPv4 datagrams whose DF=1 MUST NOT be fragmented.
o >> IPv4 datagram transit devices MUST NOT clear the DF bit. o >> IPv4 datagram transit devices MUST NOT clear the DF bit.
In specific, DF=1 prevents fragmenting datagrams that are integral. In specific, DF=1 prevents fragmenting atomic datagrams. DF=1 also
DF=1 also prevents further fragmenting received fragments. prevents further fragmenting received fragments. In-network
Fragmentation, either of an unfragmented datagram or of fragments, is fragmentation is permitted only when DF=0; this document does not
current permitted only where DF=0 in the original emitted datagram, change that requirement.
and this document does not 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:
skipping to change at page 10, line 44 skipping to change at page 10, line 39
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 IPv4 ID uniqueness applies to only non-atomic datagrams. o IPv4 ID uniqueness applies to only non-atomic datagrams.
o Non-atomic IPv4 datagrams retransmitted by higher level protocols o Retransmitted non-atomic IPv4 datagrams are no longer permitted to
are no longer permitted to reuse the ID value. reuse the ID value.
8.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:
Some Internet protocol experts have maintained that when a Some Internet protocol experts have maintained that when a
host sends an identical copy of an earlier datagram, the new host sends an identical copy of an earlier datagram, the new
copy should contain the same Identification value as the copy should contain the same Identification value as the
original. There are two suggested advantages: (1) if the original. There are two suggested advantages: (1) if the
skipping to change at page 11, line 23 skipping to change at page 11, line 20
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 IPv4 ID field is no longer permitted for duplicate detection. o The IPv4 ID field is no longer permitted to be used for duplicate
detection. This applies both atomic and non-atomic datagrams.
o The IPv4 ID field is no longer repeatable for higher level
protocol retransmission.
o IPv4 datagram fragments no longer are permitted to overlap. o Retransmitted non-atomic IPv4 datagrams are no longer permitted to
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.
9. Impact on NATs/ASMs, Rewriting Devices, and Tunnel Ingresses 9. Impact on NATs/ASMs, Rewriting Devices, 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 IPv4 (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 non- source address, destination address, protocol, and ID tuple for any
atomic datagrams [RFC3022]. This is also true for other address datagrams [RFC3022]. This is also true for other address sharing
sharing mechanisms (ASMs), including to include 4rd, IVI, and others mechanisms (ASMs), including to include 4rd, IVI, and others in the
in the "A+P" (address plus port) family [Bo11] [De11] [RFC6219]. It "A+P" (address plus port) family [Bo11] [De11] [RFC6219]. It is
is equally true for any other packet rewriting mechanism. As a equally true for any other packet rewriting mechanism. As a result,
result, they are subject to all the requirements of any source, as they are subject to all the requirements of any source, as has been
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:
skipping to change at page 12, line 42 skipping to change at page 12, line 35
Note that NATs/ASMs already need to exercise special care when Note that NATs/ASMs already need to exercise special care when
emitting datagrams on their public side, because merging datagrams emitting datagrams on their public side, because merging datagrams
from many sources onto a single outgoing source address can result in from many sources onto a single outgoing source address can result in
IPv4 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 [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 fragment as originating sources at the tunnel ingress). Ingresses can always fragment as originating
of the outer header, because they control the uniqueness of that IPv4 sources of the outer header, because they control the uniqueness of
ID field. They need to avoid fragmenting the datagram at the inner that IPv4 ID field and the value of DF on the outer header
header, for the same reasons as any intermediate device, as noted independent of those values on the inner (arriving datagram) header.
elsewhere in this document.
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. Such which the IPv4 ID changes between sequential datagrams [RFC1144]
algorithms currently assume that the IPv4 ID is preserved end-to-end. [RFC2508] [RFC3545] [RFC5225]. Such algorithms currently assume that
the IPv4 ID is preserved end-to-end. Some algorithms already allow
assuming the ID does not change (e.g., ROHC [RFC5225]), where others
include nonchanging IDs via zero deltas (e.g., ECRTP [RFC3545]).
When compression can assume a nonchanging IPv4 ID, efficiency can be When compression assumes a changing ID as a default, having a non-
increased. However, when compression assumes a changing ID as a changing ID can make compression less efficient (see footnote 21 of
default, having a non-changing ID can make compression less efficient
(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.
11. Security Considerations [RFC1144] or cRTP [RFC2508]). When compression can assume a
nonchanging IPv4 ID - as with ROHC and ECRTP - efficiency can be
increased.
This document attempts to address the security considerations 11. Security Considerations
associated with fragmentation in IPv4 [RFC4459].
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.
The IPv4 ID also now adds much less entropy of the header of a The IPv4 ID also now adds much less entropy of the header of a
datagram. The IPv4 ID had previously been unique (for a given datagram. The IPv4 ID had previously been unique (for a given
source/address pair, and protocol field) within one MSL, although source/address pair, and protocol field) within one MSL, although
this requirement was not enforced and clearly is typically ignored. this requirement was not enforced and clearly is typically ignored.
IDs of non-atomic datagrams are now required unique only within the The IPv4 ID of atomic datagrams is not required unique, and so
expected reordering of fragments, which could substantially reduce contributes no entropy to the header.
the amount of entropy in that field. The IPv4 ID of atomic datagrams
is not required unique, and so contributes no entropy to the header.
The deprecation of the IPv4 ID field's uniqueness for atomic The deprecation of the IPv4 ID field's uniqueness for atomic
datagrams can defeat the ability to count devices behind a NAT/ASM datagrams can defeat the ability to count devices behind a
[Be02]. This is not intended as a security feature, however. NAT/ASM/rewriter [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 15, line 8 skipping to change at page 14, line 38
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, March 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, December 1998.
[RFC2508] Casner, S., V. Jacobson. "Compressing IP/UDP/RTP Headers
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. 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.
[RFC3545] Koren, T., S. Casner, J. Geevarghese, B. Thompson, P.
Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High
Delay, Packet Loss and Reordering", RFC 3545, July 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, 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.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, Dec. 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, Dec. 2005.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, April 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, July 2007.
[RFC5225] Pelletier, G., K. Sandlund, "RObust Header Compression
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-
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 Carlos Pignataro and Gorry Detailed feedback was provided by Gorry Fairhurst, Mike Heard, Erik
Fairhurst. This document originated as an Independent Stream draft Nordmark, Carlos Pignataro, and Dan Wing. This document originated as
co-authored by Matt Mathis, PSC, and his contributions are greatly an Independent Stream draft co-authored by Matt Mathis, PSC, and his
appreciated. 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. 38 change blocks. 
106 lines changed or deleted 110 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/