Updated Specification of the IPv4 ID Field
RFC 6864

[Ballot comment]

The authors have addressed my original concerns largely by providing better context for their proposed changes and thus I am clearing my discuss.

There is however one other concern that I am trying to get my head around, but as I am unable to fully articulate it, and as I did not pick this up the first time I only log it is only a comment. I leave it to the Author/AD to decide what action (if any) to take.

Although it is an axiom of IP networking that packets may be misordered, this is, at least in most networks, a very rare event. Routers work hard not to re-order packets, and networks are normally very stable. Thus de facto packets normally arrive strictly in order, and almost  emulate a circuit switch in this regard. Hence the constant ID value is not, in practice, of any great importance. Re-ordering really only arises during a routing (or virtual physical layer) event. When a failure occurs, the normal case is (a) a number of packets are often lost and (b) the outage is normally long compared to the inter-fragment pair delay. Even so the normal case is that the new path is longer than the old path, the application is normally disrupted by packet lost, but if not, order is usually maintained anyway. What is interesting is the case where we shorten the outage time through fast reroute and the new path is shorter, here I would expect to see occasional misordering of fragments. Note that you may also get a misorder when the path is restored because the restored path is usually shorter and less congested than the path in use at that point, but most routing networks handle restoration in much the same way as outage and one may well see packet loss that disrupts the application.

The text is silent on the issue of the interaction between the IP layer and the routing layer and the transport network (virtual physical) layer, but I think it likely that those systems that use constant ID are largely saved by the in-order and reliability properties of modern networks, with reassembly errors that are so rare they are usually passed off as something else.

It is possibly worth some text on this layer interaction since we rarely consider it much, and it might be useful if the reader interested in the IP layer was reminded of the properties of the packet path provided by the network layer process and of the virtual physical layers we now use.

[Ballot comment]
I understand why this document was written, and support the intent of clarifying what is really in the wild. Furthermore, such documentation will facilitate future interoperability and stability.

My concern was that this change in definition of the specification would impact existing deployed implementations that depended on or used other interpretation of the ID. I am persuaded that there is such a significant base of implementations that already act according to what is described in this new document that "old" implementations would already be experiencing interoperability problems.

Thus, I support this work.
(I look forward to the revision that adds clarification of this point)

[Ballot comment]
In section 8.3's update to RFC2003, consider saying "as permitted by RFCXXXX" instead of "as permitted by this document" to avoid any chance that someone would misinterpret "this document" to mean RFC2003.

[Ballot comment]
I understand why this document was written, and support the intent of clarifying what is really in the wild. However, this document worries me for the reasons listed in Stewart's Discuss. Thus, I support Stewart's Discuss.

But my concerns would be satisfied if the authors would consider repositioning the document as an applicability or informational document that describes what some implementations do in order to support faster line speeds?

[Ballot discuss]
1. Throughout this document, "MSL" is confused with "time
the datagram (or any fragment of it) could be alive in the internet"
(from RFC 791) or "typical maximum delay across the Internet" (from
RFC 1122).  While the TCP MSL "sets an upper limit on a reasonable
reassembly timeout value" (from RFC 1122), there is no mention of
"MSL" in RFC 791 and there is no explicit discussion of the uniqueness
properties of the ID field in RFC 1122.

For clarity and correctness, I would like the description of the ID
field in the Introduction to quote the text from RFC 791, with no
mention of "MSL", and the discussion of the speed limits - esp. the
6.4 Mbps number - to be replaced with a simple pointer to RFC 4963,
which has a more complete and accurate discussion of the topic.  I
also think section 5 can simply be omitted.

The details are unimportant in this document (and I consider the
document to be misleading about the details).  All that needs to be
concluded is that high speed interfaces have to violate the uniqueness
requirement, even for maximum delays across the Interent of 1 second.

All other references to "MSL" should be replaced, perhaps with
"maximum datagram lifetime".

2. This requirement in section 6.3 does NOT derive exactly as stated
from RFC 791:

  >> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
  values within one MSL for a given source address/destination
  address/protocol triple.

The actual requirement, quoted elsewhere in the document, makes no
direct reference to "MSL".

[Ballot comment]

1. In this text from section 4:

  The IPv4 ID field can be useful for other purposes. The field has
  been proposed as a way to detect and remove duplicate datagrams,
  e.g., at congested routers (noted in Sec. 3.2.1.5 of [RFC1122]) or in
  network accelerators. It can similarly be used at end hosts to reduce
  the impact of duplication on higher-layer protocols (e.g., additional
  processing in TCP, or the need for application-layer duplicate
  suppression in UDP).

Is the ID field actually used in the ways suggested?

2. In section 9.2:

  Some such devices reportedly
  feature datagram de-duplication, which relies on IP ID uniqueness to
  identify duplicates.

Normally, I wouldn't raise a pedantic fuss about "which" versus
"that".  But, in this case, I think it's important because the
following sentence is, I think, correct while the sentence about is
not:

  Some such devices reportedly
  feature datagram de-duplication that relies on IP ID uniqueness to
  identify duplicates.

[Ballot comment]
I share Stewart's concern about the lack of data to support this document. The document does not have a section on how current implementations actually do this, and that lack is worrying. (The shepherd writeup has *no* information on implementation, and that's a problem. The shepherd should have asked.) All things being equal, I would have silently balloted "No Objection", but I given his comments, I do support Stewart's DISCUSS.

[Ballot discuss]
RFC791 is one of the most fundamental protocols in the Internet that is now 31 years old, and I do not think that it should be changed (or clarified) unless there  is some major issue that jeopardizes the operation of the Internet. The author makes a case for housekeeping, but does not make a case that we have a catastrophic problem that demands addressing. I am therefore concerned that publishing this is an unnecessary risk to the Internet.

My rational for the above is that we have no idea of the behavior of all of the applications and protocols in the wild, and can never be completely sure that there will be no unforeseen consequences of the proposed changes in this draft.

The following are some examples that bare further thought given the fundamental nature of IPv4.

">> IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly."

">> All devices that examine IPv4 headers MUST ignore the IPv4 ID field of atomic datagrams.

We have no idea what this field might be used for in atomic packets and hence we cannot be sure we are making some application non-compliant.

"Deprecating the use of the IPv4 ID field for non-reassembly uses should have little - if any - impact."

For a protocol this fundamental to the Internet, "should" is insufficient.

">> Sources of non-atomic IPv4 datagrams MUST rate-limit their output to comply with the ID uniqueness requirements."

What is the situation today - do all existing, functioning devices comply with this rule?

" o  IPv4 ID uniqueness applies to only non-atomic datagrams."

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

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

Can we be sure that there is no protocol anywhere on the Internet, using atomic datagrams, that is also using the feature being deprecated?

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

Are we certain that no device used this feature for anything?

[Ballot comment]
In IPv4, the Identification (ID) field is a 16-bit value that is
unique for every datagram for a given source address, destination
address, and protocol, such that it does not repeat within the
Maximum Segment Lifetime (MSL) [RFC791][RFC1122]. As currently
specified, all datagrams between a source and destination of a given
protocol must have unique IPv4 ID values over a period of this MSL,
which is typically interpreted as two minutes (120 seconds).

I just could looked at RFC791 and RFC1122, and as far as I can see
RFC791 does not say two mins and RFC1122 is quoting from TCP
which it notes is arbitrary.

[Ballot comment]
As noted in Steve Kent's secdir review, the security considerations section should indicate whether the change proposed in this document may adversely affect availability, if middleboxes are not updated to account for this change.

[Ballot comment]
Minor comments, feel free to take 'em or leave 'em.

(Updated: I'd forgotten to note the secdir review.)

- A reference for a hash-based de-duplication scheme mentioned
in 6.1 might be useful, even if only as an illustration.

- The reference to SEAL (RFC 5320) is a bit unclear.  You have
a "SHOULD verify integrity" requirement but then say "as in
SEAL." I'm not clear if you're saying that SEAL is a SHOULD,
and if you are, then would that be ok? (SEAL being an
experimental RFC.) I assume that you don't mean SEAL is a
SHOULD-implement though, and since its given as an example in
the next para, I think you could delete the reference from the
SHOULD requirement bullet in section 7.

- The discussion of entropy in section 11 is a little opaque,
you could say why the entropy of a datagram is interesting. (Is
it that people sometimes use datagram fields to seen PRNGs?).
Steve Kent's secdir review [1] also suggested maybe changing
or removing this.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03358.html


- Typo: s/now adds much less entropy of the header/ now adds
much less to the entropy of the header/?

[Ballot comment]
Minor comments, feel free to take 'em or leave 'em.

(Updated: I'd forgottent to note the secdir review.)

- A reference for a hash-based de-duplication scheme mentioned
in 6.1 might be useful, even if only as an illustration.

- The reference to SEAL (RFC 5320) is a bit unclear.  You have
a "SHOULD verify integrity" requirement but then say "as in
SEAL." I'm not clear if you're saying that SEAL is a SHOULD,
and if you are, then would that be ok? (SEAL being an
experimental RFC.) I assume that you don't mean SEAL is a
SHOULD-implement though, and since its given as an example in
the next para, I think you could delete the reference from the
SHOULD requirement bullet in section 7.

- The discussion of entropy in section 11 is a little opaque,
you could say why the entropy of a datagram is interesting. (Is
it that people sometimes use datagram fields to seen PRNGs?).
Steve Kent's secdir review [1] also suggested maybe changing
or removing this.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03358.html


- Typo: s/now adds much less entropy of the header/ now adds
much less to the entropy of the header/?

[Ballot comment]

Minor comments, feel free to take 'em or leave 'em.

- A reference for a hash-based de-duplication scheme mentioned
in 6.1 might be useful, even if only as an illustration.

- The reference to SEAL (RFC 5320) is a bit unclear.  You have
a "SHOULD verify integrity" requirement but then say "as in
SEAL." I'm not clear if you're saying that SEAL is a SHOULD,
and if you are, then would that be ok? (SEAL being an
experimental RFC.) I assume that you don't mean SEAL is a
SHOULD-implement though, and since its given as an example in
the next para, I think you could delete the reference from the
SHOULD requirement bullet in section 7.

- The discussion of entropy in section 11 is a little opaque,
you could say why the entropy of a datagram is interesting. (Is
it that people sometimes use datagram fields to seen PRNGs?).

- Typo: s/now adds much less entropy of the header/ now adds
much less to the entropy of the header/?

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Updated Specification of the IPv4 ID Field) to Proposed Standard


The IESG has received a request from the Internet Area Working Group WG
(intarea) to consider the following document:
- 'Updated Specification of the IPv4 ID Field'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/ballot/


No IPR declarations have been submitted directly on this I-D.

All,
    I have performed the AD review for draft-ietf-intarea-ipv4-id-update-04.txt.  I have a few comments that I would like addressed before this draft proceeds...

* Section 3 states that the IPv6 fragmentation header is only present when a datagram has been fragmented.  Section 5 of RFC 2460 allows atomic fragments to carry a fragmentation header in the scenario where a Packet-Too-Big ICMPv6 message has been received for an MTU smaller than 1280 and the packet is subject to translation.  This means that there are atomic IPv6 packets that carry a fragmentation header.

* Section 4 : I am curious as to what impact you think this document will have with trying to restrict the non-fragmentation use of the ID field.  With many of those types of tools around (and people trying to standardize a persistent ID for IPv6 packets), what impact will this document really have?

* Section 5
- 2nd paragraph : The use of the 120 second MSL value is misleading. First of all, the 120 seconds is specified as the MSL for TCP, not any other transport protocol. Secondly, my understanding is that implementations use RTT computations to determine when a segment has been lost, not a static MSL timer.  The MSL is tunable in a variety of implementations when they are applied to teardown states (e.g., TIME-WIAT).  As noted in the draft, implementations are doing something outside of what is specified in RFC 791 to manage their ID values and that is to be expected given the evolution.

- 4th paragraph : I am not aware of any routers that actually apply any type of time component to the management of a packet's TTL.

* Section 6 presents the classification of atomic and non-atomic packets in a mathematical framework.  That framework is not used anywhere else, so I don't see the benefit of the section.

* Section 6.1
- The discussion of SMF's use of the ID field is obsolete.  The SMF draft (now in the RFC Editor's queue) does not rely on the ID field for any of its packet identification.

- The "o  >>" notation in the lists is clumsy.  I would suggest changing it to strictly ">>" or some other single list icon.

* Section 6.3 tries to state the requirements defined in 791 that were not changed.  I do not understand why they are restated in terms of 2119 keywords.  To me, that is imparting someone's interpretation of the 791 rules.

* Section 8.3 discusses the updates to RFC 2003.  Why does this section not warrant an itemized list of changes to 2003 like the previous two sections that discuss changes to 791 and 1122?

(1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The Document Shepherd is Julien Laganier, INTAREA co-chair. He
        has personally done a thorough review of the document. He
        believe the document is ready for forwarding to IESG for
        publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

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

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

        The Document Shepherd has no such concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

        The Document Shepherd has no such concerns.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

There is WG consensus behind this document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

        No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The document has split its references into normative and
        informative. There are neither normative references in an unclear
        state, nor downward references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

        The document has an IANA considerations sections that correctly
state that the document does not need IANA actions.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

        There are no such sections.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    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.