draft-ietf-intarea-ipv4-id-update-02.txt   draft-ietf-intarea-ipv4-id-update-03.txt 
Internet Area WG J. Touch Internet Area WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Updates: 791,1122,2003 March 14, 2011 Updates: 791,1122,2003 September 14, 2011
Intended status: Proposed Standard Intended status: Proposed Standard
Expires: September 2011 Expires: March 2012
Updated Specification of the IPv4 ID Field Updated Specification of the IPv4 ID Field
draft-ietf-intarea-ipv4-id-update-02.txt draft-ietf-intarea-ipv4-id-update-03.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 14, 2011. This Internet-Draft will expire on March 14, 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 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 IPv4 ID field in RFC 791, RFC 1122, and RFC 2003 specification of the IPv4 ID field in RFC791, RFC1122, and RFC2003 to
to more closely reflect current practice and to more closely match more closely reflect current practice and to more closely match IPv6
IPv6 so that the field is defined only when a datagram is actually so that the field is defined only when a datagram is actually
fragmented. It also discusses the impact of these changes on how fragmented. It also discusses the impact of these changes on how
datagrams are used. 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.........................9 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.................................10
8.1. Updates to RFC 791.......................................10 8.1. Updates to RFC 791.......................................10
8.2. Updates to RFC 1122......................................11 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 and Tunnel Ingresses...........................12 9. Impact on NATs/ASMs, Rewriting Devices, and Tunnel Ingresses..11
10. Impact on Header Compression.................................13 10. Impact on Header Compression.................................13
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
skipping to change at page 4, line 41 skipping to change at page 4, line 41
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 suggested 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, although this has been noted and no
current deployments are known (see Sec. 3.2.1.5 of [RFC1122]). It can current operational deployments are known (see Sec. 3.2.1.5 of
similarly be used at end hosts to reduce the impact of duplication on [RFC1122]; it is proposed experimentally in Simplified Multicast
higher-layer protocols (e.g., additional processing in TCP, or the Forwarding [Ma11]). It can similarly be used at end hosts to reduce
need for application-layer duplicate suppression in UDP). 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 IPv4 ID field can also be used to validate payloads of ICMP The IPv4 ID field can also be used to validate payloads of ICMP
responses as matching the originally transmitted datagram at a host responses as matching the originally transmitted datagram at a host.
[RFC4963]. In this case, the ICMP payload - an IP datagram prefix - In this case, the ICMP payload - an IP datagram prefix - is matched
is matched against a cache of recently transmitted IP headers to against a cache of recently transmitted IP headers to check that the
check that the received ICMP reflects a transmitted datagram. At a received ICMP reflects a transmitted datagram. At a tunnel ingress,
tunnel ingress, the IPv4 ID enables returning ICMP messages to be the IPv4 ID enables returning ICMP messages to be matched to a cache
matched to a cache of recently transmitted datagrams, to support ICMP of recently transmitted datagrams, to support ICMP relaying, with
relaying, with similar challenges [RFC2003]. 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 Uses of the IPv4 ID field beyond fragmentation and reassembly require
that the IPv4 ID be unique across all datagrams, not only when that the IPv4 ID be unique across all datagrams, not only when
fragmentation is enabled. This document deprecates all such non- fragmentation is enabled. This document deprecates all such non-
fragmentation uses. 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
skipping to change at page 7, line 7 skipping to change at page 7, line 11
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, this Although RFC1122 suggests the IPv4 ID field has other uses, and it is
document asserts that this field is defined only for fragmentation currently being considered for the experimental Simplfied Mulitcast
and reassembly. Forwarding (SMF) protocol [Ma11], this document asserts that this
field 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.
This has a few implications. In atomic datagrams, the IPv4 ID field [Note that SMF includes non-ID duplicate packet detection for cases
has no meaning, and thus can be set to an arbitrary value, i.e., the where the ID field is absent (IPv6), and already defines these for
requirement for non-repeating IDs within the address/protocol triple IPv4, where it should be preferred to ID-based duplicate detection
is no longer required for atomic datagrams: for atomic datagrams if this document proceeds.]
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
IDs within the address/protocol triple is no longer required for
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,
destination hosts, or other devices (e.g., NATs, firewalls, tunnel destination hosts, or other devices (e.g., NATs and other address
egresses), cannot rely on the field: sharing mechanisms, firewalls, tunnel egresses), cannot rely on the
field:
o >> All devices that examine IPv4 headers MUST ignore the IPv4 ID o >> All devices that examine IPv4 headers MUST ignore the IPv4 ID
field of atomic datagrams. field of atomic datagrams.
The IPv4 ID field is thus meaningful only for non-atomic datagrams - The IPv4 ID field is thus meaningful only for non-atomic datagrams -
datagrams that have either already been fragmented, or those for datagrams that have either already been fragmented, or those for
which fragmentation remains permitted. Atomic datagrams are detected which fragmentation remains permitted. Atomic datagrams are detected
by their DF, MF, and fragmentation offset fields as explained in by their DF, MF, and fragmentation offset fields as explained in
Section 6, because such a test is completely backward compatible; Section 6, because such a test is completely backward compatible;
this document thus does not reserve any IPv4 ID values, including 0, this document thus does not reserve any IPv4 ID values, including 0,
skipping to change at page 8, line 22 skipping to change at page 8, line 28
to reuse the IPv4 ID (see Section 8.2). This can make it difficult 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 for a source to avoid IPv4 ID repetition for received fragments. RFC
1122 concludes that this behavior "is not useful"; this document 1122 concludes that this behavior "is not useful"; this document
formalizes that conclusion as follows: formalizes that conclusion as follows:
o >> The IPv4 ID of non-atomic datagrams MUST NOT be reused when o >> The IPv4 ID of non-atomic datagrams MUST NOT be reused when
sending a copy of an earlier non-atomic datagram. sending a copy of an earlier non-atomic datagram.
RFC 1122 also suggests that fragments can overlap [RFC1122]. Such RFC 1122 also suggests that fragments can overlap [RFC1122]. Such
overlap can occur if successive retransmissions are fragmented in overlap can occur if successive retransmissions are fragmented in
different ways but the same reassembly IPv4 ID. different ways but the same reassembly IPv4 ID. This overlap is noted
as the result of reusing IPv4 IDs when retransmitting datagrams,
This overlap is noted as the result of reusing IPv4 IDs when which this document deprecates. However, it is also the result of in-
retransmitting datagrams, which this document deprecates. Overlapping network packet duplication, which can still occur. As a result this
fragments are themselves a hazard [RFC4963]. As a result: document does not change the need to support overlapping fragments.
o >> Overlapping datagrams MUST be silently ignored during
reassembly.
The IPv4 ID of non-atomic datagrams also needs to remain stable, to
ensure that existing fragments are not reassembled incorrectly, as
well as to ensure that the uniqueness of the IDs as generated by the
source is not undermined.
For atomic datagrams, because the IPv4 ID field is ignored on
receipt, it can be possible to rewrite the field. Rewriting can be
useful to prevent use of the field as a covert channel, or to enable
more efficient header compression. However, the IPv4 ID field needs
to remain immutable when it is validated by higher layer protocols,
such as IPsec. As a result:
o >> The IPv4 ID field of non-atomic datagrams, or protected atomic
datagrams MUST NOT change in transit; the IPv4 ID field of
unprotected atomic datagrams MAY be changed in transit.
Protected datagrams are defined as those whose header fields are
covered by integrity validation, such as IPsec AH [RFC4302].
6.3. IPv4 ID Requirements That Persist 6.3. IPv4 ID Requirements That Persist
This document does not relax the IPv4 ID field uniqueness This document does not relax the IPv4 ID field uniqueness
requirements of [RFC791] for non-atomic datagrams, i.e.: requirements of [RFC791] for non-atomic datagrams, i.e.:
o >> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID o >> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
values within one MSL for a given source address/destination values within one MSL for a given source address/destination
address/protocol triple. address/protocol triple.
Such sources include originating hosts, tunnel ingresses, and NATs Such sources include originating hosts, tunnel ingresses, and NATs
(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 datagrams that are integral.
DF=1 also prevents further fragmenting received fragments. DF=1 also prevents further fragmenting received fragments.
skipping to change at page 12, line 5 skipping to change at page 11, line 36
protocol retransmission. protocol retransmission.
o IPv4 datagram fragments no longer are permitted to overlap. o IPv4 datagram fragments no longer are permitted to overlap.
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 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 non-
atomic datagrams [RFC3022]. As a result, they are subject to all the atomic datagrams [RFC3022]. This is also true for other address
requirements of any source, as has been noted. sharing mechanisms (ASMs), including to include 4rd, IVI, and others
in the "A+P" (address plus port) family [Bo11] [De11] [RFC6219]. It
is equally true for any other packet rewriting mechanism. As a
result, they are subject to all the requirements of any source, as
has been noted.
NATs present a particularly challenging situation for fragmentation. NATs/ASMs/rewriters present a particularly challenging situation for
Because NATs overwrite portions of the reassembly tuple in both fragmentation. Because they overwrite portions of the reassembly
directions, they can destroy tuple uniqueness and result in a tuple in both directions, they can destroy tuple uniqueness and
reassembly hazard. Whenever IPv4 source address, destination address, result in a reassembly hazard. Whenever IPv4 source address,
or protocol fields are modified, a NAT needs to ensure that the ID destination address, or protocol fields are modified, a
field is generated appropriately, rather than simply copied from the NAT/ASM/rewriter needs to ensure that the ID field is generated
incoming datagram. In specific: appropriately, rather than simply copied from the incoming datagram.
In specific:
o >> NATs MUST ensure that the IPv4 ID field of datagrams whose o >> Address sharing or rewriting devices MUST ensure that the IPv4
address or protocol are translated comply with requirements as if ID field of datagrams whose address or protocol are translated
the datagram were sourced by the NAT. comply with requirements as if the datagram were sourced by that
device.
This compliance means that the IPv4 ID field of non-atomic datagrams This compliance means that the IPv4 ID field of non-atomic datagrams
translated at a NAT need to obey the uniqueness requirements of any translated at a NAT/ASM/rewriter needs to obey the uniqueness
IPv4 datagram source. Unfortunately, fragments already violate that requirements of any IPv4 datagram source. Unfortunately, fragments
requirement, as they repeat an IPv4 ID within the MSL for a given already violate that requirement, as they repeat an IPv4 ID within
source address, destination address, and protocol triple. the MSL for a given source address, destination address, and protocol
triple.
Such problems with transmitting fragments through NATs are already Such problems with transmitting fragments through NATs/ASMs/rewriters
known; translation is based on the transport port number, which is are already known; translation is based on the transport port number,
present in only the first fragment anyway [RFC3022]. This document which is present in only the first fragment anyway [RFC3022]. This
underscores the point that not only is reassembly (and possibly document underscores the point that not only is reassembly (and
subsequent fragmentation) required for translation, it can be used to possibly subsequent fragmentation) required for translation, it can
avoid issues with IPv4 ID uniqueness. be used to avoid issues with IPv4 ID uniqueness.
Note that NATs/NAPTs 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 fragment as originating sources
of the outer header, because they control the uniqueness of that IPv4 of the outer header, because they control the uniqueness of that IPv4
ID field. They need to avoid fragmenting the datagram at the inner ID field. They need to avoid fragmenting the datagram at the inner
header, for the same reasons as any intermediate device, as noted header, for the same reasons as any intermediate device, as noted
elsewhere in this document. 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. Such
algorithms currently need to preserve the IPv4 ID. algorithms currently assume that the IPv4 ID is preserved end-to-end.
When compression can assume a nonchanging IPv4 ID, efficiency can be When compression can assume a nonchanging IPv4 ID, efficiency can be
increased. However, when compression assumes a changing ID as a increased. However, when compression assumes a changing ID as a
default, having a non-changing ID can make compression less efficient default, having a non-changing ID can make compression less efficient
(see footnote 21 of [RFC1144], which is optimized for non-atomic (see footnote 21 of [RFC1144], which is optimized for non-atomic
datagrams). This document thus does not recommend whether atomic IPv4 datagrams). This document thus does not recommend whether atomic IPv4
datagrams should use nonchanging or changing IDs, but rather allows datagrams should use nonchanging or changing IDs.
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 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
skipping to change at page 13, line 44 skipping to change at page 13, line 40
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 IDs of non-atomic datagrams are now required unique only within the
expected reordering of fragments, which could substantially reduce expected reordering of fragments, which could substantially reduce
the amount of entropy in that field. The IPv4 ID of atomic datagrams 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. 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 datagrams can defeat the ability to count devices behind a NAT/ASM
[Be02]. This is not 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
skipping to change at page 14, line 32 skipping to change at page 14, line 30
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996. October 1996.
13.2. Informative References 13.2. Informative References
[Be02] Bellovin, S., "A Technique for Counting NATted Hosts", [Be02] Bellovin, S., "A Technique for Counting NATted Hosts",
Internet Measurement Conference, Proceedings of the 2nd ACM Internet Measurement Conference, Proceedings of the 2nd ACM
SIGCOMM Workshop on Internet Measurement, November 2002. SIGCOMM Workshop on Internet Measurement, November 2002.
[Bo11] Boucadair, M., J. Touch, P. Levis, R. Penno, "Analysis of
Solution Candidates to Reveal a Host Identifier in Shared
Address Deployments", (work in progress), draft-boucadair-
intarea-nat-reveal-analysis, Sept. 2011.
[De11] Despres, R. (Ed.), S. Matsushima, T. Murakami, O. Troan,
"IPv4 Residual Deployment across IPv6-Service networks
(4rd)", (work in progress), draft-despres-intarea-4rd,
March 2011.
[Ma11] Macker, J. (Ed.), "Simplified Multicast Forwarding," (work
in progress), draft-ietf-manet-smf-12, Jul. 2011.
[Pe11] Perreault, S., (Ed.), I. Yamagata, S. Miyakawa, A. [Pe11] Perreault, S., (Ed.), I. Yamagata, S. Miyakawa, A.
Nakagawa, H. Ashida, "Common requirements of IP address Nakagawa, H. Ashida, "Common requirements of IP address
sharing schemes", (work in progress), draft-ietf-behave- sharing schemes", (work in progress), draft-ietf-behave-
lsn-requirements, March 2011. lsn-requirements, 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.
skipping to change at page 15, line 26 skipping to change at page 15, line 36
[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.
[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
Education and Research Network (CERNET) IVI Translation
Design and Deployment for the IPv4/IPv6 Coexistence and
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 Carlos Pignataro and Gorry
Fairhurst. This document originated as an Independent Stream draft Fairhurst. This document originated as an Independent Stream draft
co-authored by Matt Mathis, PSC, and his contributions are greatly co-authored by Matt Mathis, PSC, and his contributions are greatly
appreciated. appreciated.
 End of changes. 27 change blocks. 
87 lines changed or deleted 98 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/