draft-ietf-intarea-ipv4-id-update-01.txt   draft-ietf-intarea-ipv4-id-update-02.txt 
Internet Area WG J. Touch Internet Area WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Updates: 791,1122,2003 October 22, 2010 Updates: 791,1122,2003 March 14, 2011
Intended status: Proposed Standard Intended status: Proposed Standard
Expires: April 2011 Expires: September 2011
Updated Specification of the IPv4 ID Field Updated Specification of the IPv4 ID Field
draft-ietf-intarea-ipv4-id-update-01.txt draft-ietf-intarea-ipv4-id-update-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 22, 2011. This Internet-Draft will expire on September 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 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 to more closely reflect current specification of the IPv4 ID field in RFC 791, RFC 1122, and RFC 2003
practice and to more closely match IPv6 so that the field is defined to more closely reflect current practice and to more closely match
only when a datagram is actually fragmented. It also discusses the IPv6 so that the field is defined only when a datagram is actually
impact of these changes on how datagrams are used. 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
skipping to change at page 12, line 45 skipping to change at page 12, line 45
present in only the first fragment anyway [RFC3022]. This document 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 can be used to subsequent fragmentation) required for translation, it can be used to
avoid issues with IPv4 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 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 [Ni09]. 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
skipping to change at page 14, line 32 skipping to change at page 14, line 32
[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.
[Ni09] Nishitani, T., I. Yamagata, S. Miyakawa, A. Nakagawa, H. [Pe11] Perreault, S., (Ed.), I. Yamagata, S. Miyakawa, A.
Ashida, "Common Functions of Large Scale NAT (LSN) ", (work Nakagawa, H. Ashida, "Common requirements of IP address
in progress), draft-nishitani-cgn-05, July 2010. sharing schemes", (work in progress), draft-ietf-behave-
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.
[RFC2671] Vixie,P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [RFC2671] Vixie,P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999. August 1999.
 End of changes. 8 change blocks. 
13 lines changed or deleted 15 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/