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

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Updated Specification of the IPv4 ID Field' to Proposed Standard (draft-ietf-intarea-ipv4-id-update-07.txt)

The IESG has approved the following document:
- 'Updated Specification of the IPv4 ID Field'
  (draft-ietf-intarea-ipv4-id-update-07.txt) as Proposed Standard

This document is the product of the Internet Area Working Group.

The IESG contact persons are Brian Haberman and Ralph Droms.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/

Ballot Text

Technical Summary

  The IPv4 Identification (ID) field enables fragmentation and
  reassembly, and as currently specified is required to be unique
  within the maximum lifetime for all datagrams with a given
  source/destination/protocol tuple. If enforced, this uniqueness
  requirement would limit all connections to 6.4 Mbps. Because
  individual connections commonly exceed this speed, it is clear that
  existing systems violate the current specification. This document
  updates the specification of the IPv4 ID field in RFC791, RFC1122,
  and RFC2003 to more closely reflect current practice and to more
  closely match IPv6 so that the field's value is defined only when a
  datagram is actually fragmented. It also discusses the impact of
  these changes on how datagrams are used.

Working Group Summary 

  The normal WG process was followed and the document as it stands now
  reflects WG consensus with nothing special worth mentioning.

Document Quality 

  The document was given adequate reviews. The Document Shepherd has
  no concerns about the depth or breadth of these reviews.

Personnel

   The Document Shepherd for this document Julien Laganier. The responsible
   Area Director is Brian Haberman.

RFC Editor Note

OLD:
Reordering is typically associated with routing transients or where multiple
alternate paths exist.

NEW:
Reordering is typically associated with routing transients or where flows are
split across multiple paths.

RFC Editor Note