Updated Specification of the IPv4 ID Field
draft-ietf-intarea-ipv4-id-update-05

Internet-Draft    Updated Spec. of the IPv4 ID Field           May 2012

            DISCUSSION:

            Some Internet protocol experts have maintained that when a
            host sends an identical copy of an earlier datagram, the new
            copy should contain the same Identification value as the
            original.  There are two suggested advantages:  (1) if the
            datagrams are fragmented and some of the fragments are lost,
            the receiver may be able to reconstruct a complete datagram
            from fragments of the original and the copies; (2) a
            congested gateway might use the IP Identification field (and
            Fragment Offset) to discard duplicate datagrams from the
            queue.

   This document changes RFC 1122 as follows:

   o  The IPv4 ID field is no longer permitted to be used for duplicate
      detection. This applies to both atomic and non-atomic datagrams.

   o  Retransmitted non-atomic IPv4 datagrams are no longer permitted to
      reuse the ID value.

8.3. Updates to RFC 2003

   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
   any other IPv4 datagram source. In specific, RFC 2003 states the
   following, where ref. [10] is RFC 791:

         Identification, Flags, Fragment Offset

            These three fields are set as specified in [10]...

   This document changes RFC 2003 as follows:

   o  The IPv4 ID field is set as permitted by this document.

9. Impact on Middleboxes

   Middleboxes include rewriting devices that include network address
   translators (NATs), address/port translators (NAPTs), and other
   address sharing mechanisms (ASMs). They also include devices that
   inspect and filter datagrams that are not routers, such as
   accelerators and firewalls.

Touch                 Expires November 30, 2012               [Page 11]
Internet-Draft    Updated Spec. of the IPv4 ID Field           May 2012

9.1. Rewriting Middleboxes

   NATs and NAPTs rewrite IP fields, and tunnel ingresses (using IPv4
   encapsulation) copy and modify some IPv4 fields, so all are
   considered sources, as do any devices that rewrite any portion of the
   source address, destination address, protocol, and ID tuple for any
   datagrams [RFC3022]. This is also true for other ASMs, including 4rd,
   IVI, and others in the "A+P" (address plus port) family [Bo11] [De11]
   [RFC6219]. It is equally true for any other datagram rewriting
   mechanism. As a result, they are subject to all the requirements of
   any source, as has been noted.

   NATs/ASMs/rewriters present a particularly challenging situation for
   fragmentation. Because they overwrite portions of the reassembly
   tuple in both directions, they can destroy tuple uniqueness and
   result in a reassembly hazard. Whenever IPv4 source address,
   destination address, or protocol fields are modified, a
   NAT/ASM/rewriter needs to ensure that the ID field is generated
   appropriately, rather than simply copied from the incoming datagram.
   In specific:

   >> Address sharing or rewriting devices MUST ensure that the IPv4 ID
   field of datagrams whose address or protocol are translated comply
   with these requirements as if the datagram were sourced by that
   device.

   This compliance means that the IPv4 ID field of non-atomic datagrams
   translated at a NAT/ASM/rewriter needs to obey the uniqueness
   requirements of any 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/ASMs/rewriters
   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 subsequent fragmentation) required for translation, it can
   be used to avoid issues with IPv4 ID uniqueness.

   Note that NATs/ASMs already need to exercise special care when
   emitting datagrams on their public side, because merging datagrams
   from many sources onto a single outgoing source address can result in
   IPv4 ID collisions. This situation precedes this document, and is not
   affected by it. It is exacerbated in large-scale, so-called "carrier
   grade" NATs [Pe11].

Touch                 Expires November 30, 2012               [Page 12]
Internet-Draft    Updated Spec. of the IPv4 ID Field           May 2012

   Tunnel ingresses act as sources for the outermost header, but tunnels
   act as routers for the inner headers (i.e., the datagram as arriving
   at the tunnel ingress). Ingresses can always fragment as originating
   sources of the outer header, because they control the uniqueness of
   that IPv4 ID field and the value of DF on the outer header
   independent of those values on the inner (arriving datagram) header.

9.2. Filtering Middleboxes

   Middleboxes also include devices that filter datagrams, including
   network accelerators and firewalls. Some such devices reportedly
   feature datagram de-duplication, which relies on IP ID uniqueness to
   identify duplicates. Such accelerators already risk dropping non-
   duplicate datagrams because of early ID reuse, and, as a result of
   earlier requirements:

   >> Datagram de-duplication mechanisms MUST ignore the ID values on
   atomic datagrams.

10. Impact on Header Compression

   Header compression algorithms already accommodate various ways in
   which the IPv4 ID changes between sequential datagrams [RFC1144]
   [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 non-changing IDs via zero deltas (e.g., ECRTP [RFC3545]).

   When compression assumes a changing ID as a default, having a non-
   changing ID can make compression less efficient. Such non-changing
   IDs have been described in various RFCs (e.g., footnote 21 of
   [RFC1144 and cRTP [RFC2508]). When compression can assume a non-
   changing IPv4 ID - as with ROHC and ECRTP - efficiency can be
   increased.

11. Security Considerations

   When the IPv4 ID is ignored on receipt (e.g., for atomic datagrams),
   its value becomes unconstrained; that field then can more easily be
   used as a covert channel. For some atomic datagrams - notably those
   not protected by IPsec Authentication Header (AH) [RFC4302] - it is
   now possible, and may be desirable, to rewrite the IPv4 ID field to
   avoid its use as such a channel.

   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
   source/address pair, and protocol field) within one MSL, although

Touch                 Expires November 30, 2012               [Page 13]
Internet-Draft    Updated Spec. of the IPv4 ID Field           May 2012

   this requirement was not enforced and clearly is typically ignored.
   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
   datagrams can defeat the ability to count devices behind a
   NAT/ASM/rewriter [Be02]. This is not intended as a security feature,
   however.

12. IANA Considerations

   There are no IANA considerations in this document.

   The RFC Editor should remove this section prior to publication

13. References

13.1. Normative References

   [RFC791]  Postel, J., "Internet Protocol", RFC 791 / STD 5, September
             1981.

   [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
             Communication Layers", RFC 1122 / STD 3, October 1989.

   [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers",
             RFC 1812 / STD 4, Jun. 1995.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119 / BCP 14, March 1997.

   [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
             October 1996.

13.2. Informative References

   [Be02]    Bellovin, S., "A Technique for Counting NATted Hosts",
             Internet Measurement Conference, Proceedings of the 2nd ACM
             SIGCOMM Workshop on Internet Measurement, Nov. 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.

Touch                 Expires November 30, 2012               [Page 14]
Internet-Draft    Updated Spec. of the IPv4 ID Field           May 2012

   [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, Mar.
             2011.

   [Pe11]    Perreault, S., (Ed.), I. Yamagata, S. Miyakawa, A.
             Nakagawa, H. Ashida, "Common requirements of IP address
             sharing schemes", (work in progress), draft-ietf-behave-
             lsn-requirements, Mar. 2011.

   [RFC1144] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, Feb.
             1990.

   [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, Dec. 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,
             Aug. 1999.

   [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
             Address Translator (Traditional NAT)", RFC 3022, Jan. 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, Jul. 2003.

   [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson, Ed., G.
             Fairhurst, Ed., "The Lightweight User Datagram Protocol
             (UDP-Lite)", RFC 3828, Jul. 2004.

   [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet
             Protocol", RFC 4301, Dec. 2005.

   [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, Dec. 2005.

   [RFC4443] Conta, A., S. Deering, M. Gupta (Ed.), "Internet Control
             Message Protocol (ICMPv6) for the Internet Protocol Version
             6 (IPv6) Specification", RFC 4443, March. 2006.

   [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol",
             RFC 4960, Sep. 2007.

   [RFC4963] Heffner, J., M. Mathis, B. Chandler, "IPv4 Reassembly
             Errors at High Data Rates," RFC 4963, Jul. 2007.

Touch                 Expires November 30, 2012               [Page 15]
Internet-Draft    Updated Spec. of the IPv4 ID Field           May 2012

   [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
             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

   This document was inspired by of numerous discussions among the
   authors, Jari Arkko, Lars Eggert, Dino Farinacci, and Fred Templin,
   as well as members participating in the Internet Area Working Group.
   Detailed feedback was provided by Gorry Fairhurst, Brian Haberman,
   Ted Hardie, Mike Heard, Erik Nordmark, Carlos Pignataro, and Dan
   Wing. This document originated as an Independent Stream draft co-
   authored by Matt Mathis, PSC, and his contributions are greatly
   appreciated.

   This document was prepared using 2-Word-v2.0.template.dot.

Author's Address

   Joe Touch
   USC/ISI
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695
   U.S.A.

   Phone: +1 (310) 448-9151
   Email: touch@isi.edu

Touch                 Expires November 30, 2012               [Page 16]