[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-intarea-ipv4-id-update

Internet Area WG                                               J. Touch
Internet Draft                                                  USC/ISI
Intended status: Updates 791,1122,2003                        M. Mathis
Expires: September 2009                                             PSC
                                                          March 9, 2009



                      IPv4 ID Uniqueness Requirements
                 draft-touch-intarea-ipv4-unique-id-01.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on September 9, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.






Touch, Mathis         Expires September 9, 2009                [Page 1]


Internet-Draft     IPv4 ID Uniqueness Requirements           March 2009


Abstract

   The IPv4 Identification (ID) field enables fragmentation and
   reassembly, but is required and must be unique within the maximum
   segment lifetime on all packets. If implemented as required, this
   uniqueness would limit all connections to 6.4 Mbps; since this is
   ubiquitously not the case, it is clear that existing systems violate
   the current requirement. This document updates the requirements for
   the IP ID field to more closely reflect current practice, and to more
   closely match IPv6, in which the field is defined only when a packet
   is actually fragmented. Even when fragmented, this document
   recommends that the ID field uniqueness consider the reordering
   context, rather than an arbitrary, unenforced upper bound on segment
   lifetime.

Table of Contents


   1. Introduction...................................................2
   2. Conventions used in this document..............................3
   3. Current Requirements...........................................3
   4. Uses of the ID Field in IPv4...................................4
   5. IPv4 ID Exhaustion.............................................4
   6. Current Practice...............................................5
   7. Recommended Practice...........................................5
   8. Updates to Existing Standards..................................7
      8.1. Updates to RFC 791........................................7
      8.2. Updates to RFC 1122.......................................7
      8.3. Updates to RFC 2003.......................................7
   9. Impacts on NATs and Tunnel Ingresses...........................7
   10. Transitioning to These New Requirements.......................7
   11. Security Considerations.......................................8
   12. IANA Considerations...........................................8
   13. References....................................................8
      13.1. Normative References.....................................8
      13.2. Informative References...................................8
   14. Acknowledgments...............................................9

1. Introduction

   In IPv4, the IP Identification (ID) field is a 16-bit value that is
   unique for every packet for a given source address, destination
   address, and protocol, such that it does not repeat within the
   Maximum Segment Lifetime (MSL) [RFC791][RFC1122]. All packets between
   a source and destination of a given protocol must have unique ID
   values over a period of an MSL, which is typically interpreted as two



Touch, Mathis         Expires September 9, 2009                [Page 2]


Internet-Draft     IPv4 ID Uniqueness Requirements           March 2009


   minutes (120 seconds). This uniqueness is currently specified as
   required for all packets, regardless of fragmentation settings.

   The uniqueness of the IP ID is a known problem for high speed
   devices, because it limits the speed of a single protocol between two
   endpoints to 6.4 Mbps for typical MTUs of 1500 bytes [RFC4963]. This
   strongly indicates that the uniqueness of the IPv4 ID is moot.

   This document updates the requirements for the IP ID field to more
   closely reflect current practice, and to more closely match IPv6, in
   which the field is defined only when a packet is actually fragmented.
   It also updates the recommended uniqueness interval to support the
   impact of reordering on reassembly, rather than using an arbitrary
   and unenforceable segment lifetime.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

   In this document, the characters ">>" proceeding an indented line(s)
   indicates a compliance requirement statement using the key words
   listed above. This convention aids reviewers in quickly identifying
   or finding this RFC's explicit compliance requirements.

3. Current Requirements

   IP supports packet fragmentation, where large packets are split into
   smaller components to traverse links with limited maximum
   transmission units (MTUs). Fragments are indicated in different ways
   in IPv4 and IPv6:

   o  In IPv4, the header contains three fields: Identification (ID),
      Offset, a "Don't Fragment" flag (DF), and a "More Fragments" flag
      (MF) [RFC791]

   o  In IPv6, fragments are indicated in an extension header that
      includes an ID, Offset, and MF flag similar to their counterparts
      in IPv4 [RFC2460]

   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
   prevent downstream devices from initiating fragmentation. The IPv6
   fragment header is present only when a packet has been fragmented, so
   the fields - notably the ID field, as will be shown later - are not
   present for non-fragmented packets, and thus are meaningful only for


Touch, Mathis         Expires September 9, 2009                [Page 3]


Internet-Draft     IPv4 ID Uniqueness Requirements           March 2009


   fragments. Finally, the ID field is 32 bits, and unique per
   source/destination address pair for IPv6, whereas for IPv4 it is only
   16 bits and unique per source/destination/protocol triple.

   This document focuses on the IPv4 ID field issues, because in IPv6
   the field is larger and present only in fragments.

4. Uses of the ID Field in IPv4

   The IPv4 ID field was originally intended for fragmentation and
   reassembly. Within a given source address, destination address, and
   protocol, fragments of an original packet are matched based on their
   IP ID. This requires that IDs are unique within the address/protocol
   triple when fragmentation is possible (e.g., DF=0).

   The ID field has been discussed as useful in other ways. It can be
   used to detect and discard duplicate packets, e.g., at congested
   routers (see Sec. 3.2.1.5 of [RFC1122]).

   The ID field may also be useful in tunnels. ICMP along tunnels may
   return only a portion of the information needed by a tunnel ingress
   to relay information back to the packet source. Encapsulators may
   retain copies of recently sent packets, to enable ICMP relaying
   [RFC2003].

   These latter uses require that the IP ID be unique across all
   packets, not only when fragmentation is enabled. This document
   deprecates all such non-fragmentation uses.

5. IPv4 ID Exhaustion

   With the maximum IPv4 packet size of 64KB, a 16-bit ID field that
   does not repeat within 120 seconds means that the sum of all TCP
   connections of a given protocol between two endpoints is limited to
   roughly 286 Mbps; at a more typical MTU of 1500 bytes, this speed
   drops to 6.4 Mbps [RFC4963]. This limit currently applies for all
   IPv4 packets, regardless of whether fragmentation is enabled, used,
   or inhibited.

   Note that IPv6, even at typical MTUs, is capable of 18.7 Tbps when
   fragments are present, due to the larger 32-bit ID field. When
   fragmentation is not used, IPv6 speeds are not limited by the ID
   field uniqueness.

   Note also that 120 seconds is only an estimate on the maximum segment
   lifetime. It is loosely based on half maximum value of the IP TTL
   field, which is represents 0-255 seconds, although it must be


Touch, Mathis         Expires September 9, 2009                [Page 4]


Internet-Draft     IPv4 ID Uniqueness Requirements           March 2009


   decremented by 1 second for each router on a path even when held for
   less than a second [RFC791]. Network delays are incurred in other
   ways, e.g., satellite links, which can add seconds of delay even
   though the TTL is not affected. There is no enforcement mechanism to
   ensure that packets older than 120 seconds are discarded.

6. Current Practice

   Wireless Internet devices are frequently connected at speeds over 54
   Mbps, and wired links of 1 Gbps have been the default for several
   years. Although many end-to-end transport paths are congestion
   limited, these devices easily achieve 100+ Mbps application-layer
   throughput over LANs (e.g., disk-to-disk file transfer rates), and
   numerous throughput demonstrations have been performed with COTS
   systems at these speeds for over a decade. This strongly suggests
   that IPv4 ID uniqueness has been moot for a long time.

7. Recommended Practice

   There are two kinds of packets, defined herein, for which recommended
   practice is described:

   o  Atomic packets: packets not yet having been fragmented (MF=0 and
      offset=0) and for which further fragmentation has been inhibited
      (DF=1), i.e.: ((DF==1)&&(MF==0)&&(offset==0))

   o  Non-atomic packets: packets which have either already been
      fragmented (MF=1 or offset>0 or both), or for which fragmentation
      remains possible (DF=0), i.e.: ((DF==0)||(MF==1)||(offset>0)), or
      (equivalently), ~((DF==1)&&(MF==0)&&(offset==0)).

   Although at least one document suggests the ID field has other uses,
   it useful to confirm here that the ID field is defined only for
   fragmentation:

   o  >> Gateways (i.e., routers) and receiving hosts MUST ignore the
      contents of the IPv4 ID field for atomic packets. The egresses of
      IP encapsulation tunnels act as receiving hosts, and thus MUST
      follow this requirement.

   o  >> The IPv4 ID field MUST NOT be utilized for purposes other than
      fragmentation and reassembly.

   Fragments that repeat the IP ID risk being reassembled incorrectly,
   especially when fragments are reordered or lost [RFC4459]. Although
   such errors may be detected at the transport layer, this results in



Touch, Mathis         Expires September 9, 2009                [Page 5]


Internet-Draft     IPv4 ID Uniqueness Requirements           March 2009


   excessive overall packet loss, as well as wasting network bandwidth.
   As a result, this document notes that:

   o  >> Hosts emitting non-atomic IPv4 packets MUST set the ID field
      uniqely per source IP, destination IP, and protocol tuple,
      sufficient to support reassembly.

   Note that "sufficient to support reassembly" need not require unique
   IDs over a two minute interval. It should be sufficient that:

   o  >> Hosts emitting non-atomic IPv4 packets SHOULD NOT repeat ID
      field values within a given source IP, destination IP, and
      protocol tuple over the period that the receiver is expected to
      experience fragment reordering.

   Note that it is impossible to ensure a "MUST NOT" in this
   requirement, because there is no strict enforcement on segment
   lifetime; as a result the requirement is listed as a "SHOULD NOT"
   only.

   This suggests that the host employ rate limiting on each
   source/estination/protocol triple. The recommendations above are most
   appropriate at the host (or tunnel ingress), and can be difficult to
   enforce at routers. As a result, we recommend that for IPv4, as for
   IPv6:

   o  >> IPv4 fragmentation SHOULD be limited to the originating source,
      e.g., the host or tunnel ingress. IPv4 fragmentation SHOULD NOT be
      performed where the IPv4 ID field is not under direct control,
      e.g., at routers.

   Note, however, that it may not be possible for applications to know
   whether any of the above three requirements are satisfied at a host
   or on tunnels along a path (esp. those employing outer
   fragmentation). As a result, we recommend that:

   o  >> Hosts unable to meet the non-repeating IP ID requirement above
      MUST NOT fragment outgoing IP packets, and MUST also set the DF
      flag to prevent subsequent fragmentation.

   o  >> Applications that cannot ensure safe IPv4 ID generation and
      that allow DF=0 SHOULD employ integrity checks that would detect
      mis-reassembled fragments, e.g, as in SEAL [Te??]0. E.g.,
      applications SHOULD NOT use UDP without checksums [RFC793], and
      SHOULD be very careful in their use of UDP-Lite [RFC3828] in such
      environments, even existing UDP and TCP checksums may not be
      sufficient [RFC4963].


Touch, Mathis         Expires September 9, 2009                [Page 6]


Internet-Draft     IPv4 ID Uniqueness Requirements           March 2009


   o  >> Applications SHOULD set DF=1 for all packets exiting a source
      host, regardless of whether those packets are fragmented at the
      source or not.

   [should this document also deprecate overlapping fragments?]

8. Updates to Existing Standards

   The following sections address the specific changes to existing
   protocols indicated by the requirements in this document.

8.1. Updates to RFC 791

   [to be completed]

8.2. Updates to RFC 1122

   [to be completed]

8.3. Updates to RFC 2003

   [to be completed]

9. Impacts on NATs and Tunnel Ingresses

   Network Address (and port) Translators (NATs) rewrite IP fields, and
   tunnel ingresses (using IP encapsulation) copy and modify some IP
   fields, so both need to follow host requirements. As a result:

   >> NATs MUST NOT ignore the DF bit.

   >> NATs SHOULD NOT fragment, even when allowed by the DF bit.

   >> Tunnel ingresses MUST NOT ignore the DF bit of the interior
   packet.

   >> Tunnels that fragment MUST do so by fragmenting the outer IP
   header; they MUST NOT fragment the inner header even when allowed by
   the DF bit.

   [further discussion would be useful, esp. of carrier-grade NATs]

10. Transitioning to These New Requirements

   During the transition period, there may continue to be tunnel
   ingresses and NATs that fragment even when the DF bit is set. It may
   be useful to use a small ID space to help detect such behavior


Touch, Mathis         Expires September 9, 2009                [Page 7]


Internet-Draft     IPv4 ID Uniqueness Requirements           March 2009


   without causing full disruption, as might occur by using a single
   value when the DF flag is set (e.g., 0).

   As a result, during the transition period, this document recommends
   that:

   >> During the transition period, a small ID space SHOULD be used to
   assist with debugging and detection; such a space SHOULD use the
   lower bits (i.e., lower 4 bits) of the ID field and clear (i.e.,
   zero) the remaining high order bits.

11. Security Considerations

   This document attempts to address the security considerations
   associated with fragmentation in IPv4 [RFC4459].

   When the IPv4 ID is ignored on receipt (e.g., for atomic packets),
   its value becomes unconstrained; that field then more easily be used
   as a covert channel.

   [talk about the impact on steganography - if the ID field is ignored,
   should it be set to zero at any given hop arbitrarily?  Should a
   security gateway set it to zero to prevent a covert channel?]

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.

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

13.2. Informative References

   [RFC793]  Postel, J., "User Datagram Protocol," RFC 793 / STD 6,
             August 1980.

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


Touch, Mathis         Expires September 9, 2009                [Page 8]


Internet-Draft     IPv4 ID Uniqueness Requirements           March 2009


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

   [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification," RFC 2460, December 1998.

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

   [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
             Network Tunneling," RFC 4459, April 2006.

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

   [Te??]    Templin, F., Ed., "The Subnetwork Encapsulation and
             Adaptation Layer (SEAL)," (work in progress), draft-
             templin-seal-22, June 2008.

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.

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

Authors' Addresses

   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, Mathis         Expires September 9, 2009                [Page 9]


Internet-Draft     IPv4 ID Uniqueness Requirements           March 2009


   Matt Mathis
   PSC
   300 South Craig st.
   Pittsburgh PA, 15213
   U.S.A.

   Phone: +1 (412) 268-3319
   Email: mathis@psc.edu









































Touch, Mathis         Expires September 9, 2009               [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/