Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt

["Templin, Fred L" <[e-mail]>]

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Wednesday, May 30, 2012 3:58 PM
> To: Templin, Fred L
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-
> 05.txt
> 
> Hi, Fred,
> 
> On 5/30/2012 3:54 PM, Templin, Fred L wrote:
> > Hi Joe,
> >
> > I know this is coming late in the game, but in Section 4.5
> > of RFC2460 there is explicit guidance as to how long an
> > implementation should wait before declaring a reassembly
> > incomplete:
> >
> >    "If insufficient fragments are received to complete reassembly of a
> >    packet within 60 seconds of the reception of the first-arriving
> >    fragment of that packet, reassembly of that packet must be
> >    abandoned and all the fragments that have been received for that
> >    packet must be discarded."
> >
> > I don't see a similar normative statement for IPv4, so
> > shouldn't this document be the place to make the statement?
> 
> This isn't the right doc for that; we don't say anything about how to
> use the ID when it occurs, only about when it's OK to reuse IDs, IMO.

The document does propose to update RFC1122, and looking
more closely at RFC1122, Section 3.3.2 it says:

  "There MUST be a reassembly timeout.  The reassembly timeout
   value SHOULD be a fixed value, not set from the remaining TTL.
   It is recommended that the value lie between 60 seconds and 120
   seconds.  If this timeout expires, the partially-reassembled
   datagram MUST be discarded and an ICMP Time Exceeded message
   sent to the source host (if fragment zero has been received)."

Based on the IPv6 specification of 60 seconds, and based on
23 years of operational experience since the publication of
RFC1122, wouldn't it be reasonable for this draft to update
RFC1122 by saying that the timeout value must be 60 seconds?

> > Asked another way, can we use this document to specify a
> > reassembly timeout value that IPv4 nodes must observe?
> 
> This document relaxes requirements; I suspect that anything that
> constrains requirements for IPv4 is unlikely to move forward.

Also, in the document's introduction, it says:

  "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]."

Isn't the correct reference for MSL actually RFC793?

Thanks - Fred
[e-mail]

> Joe
> 
> >
> > Thanks - Fred
> > [e-mail]
> >
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Joe Touch
> >> Sent: Wednesday, May 30, 2012 11:59 AM
> >> To: [e-mail]
> >> Cc: [e-mail]; [e-mail]
> >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-
> >> 05.txt
> >>
> >> Hi, all,
> >>
> >> This version incorporates feedback from an APPS directorate review by
> >> Ted Hardie and an AD review by Brian Haberman, as discussed in
> exchanges
> >> on this list in early March and early May of this year.
> >>
> >> This version should be ready for publication.
> >>
> >> Joe
> >>
> >> Summary of changes:
> >>
> >> Sec 3 -- additional explanation of use of IPv6 ID for non-fragmented v6
> >> datagrams sent to IPv4 nets that cannot support IPv6's minimum MTU
> >>
> >> Sec 4 -- remove SMF examples because they are no longer suggested
> >>
> >> Sec 6 -- simplified pseudocode and text
> >>
> >> Sec 8.3 -- added specific impact on RFC2003
> >>
> >> Sec 9 -- added network accelerator packet de-duplication
> >>
> >> Fixed typos throughout, including changing the format of directives
> from
> >> "o>>" to just">>" prefix.
> >>
> >> On 5/30/2012 11:46 AM, [e-mail] wrote:
> >>>
> >>> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories. This draft is a work item of the Internet Area Working
> Group
> >> Working Group of the IETF.
> >>>
> >>> 	Title           : Updated Specification of the IPv4 ID Field
> >>> 	Author(s)       : Joe Touch
> >>> 	Filename        : draft-ietf-intarea-ipv4-id-update-05.txt
> >>> 	Pages           : 16
> >>> 	Date            : 2012-05-30
> >>>
> >>>      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.
> >>>
> >>>
> >>> A URL for this Internet-Draft is:
> >>> http://www.ietf.org/internet-drafts/draft-ietf-intarea-ipv4-id-update-
> >> 05.txt
> >>>
> >>> Internet-Drafts are also available by anonymous FTP at:
> >>> ftp://ftp.ietf.org/internet-drafts/
> >>>
> >>> This Internet-Draft can be retrieved at:
> >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-intarea-ipv4-id-update-
> >> 05.txt
> >>>
> >>> The IETF datatracker page for this Internet-Draft is:
> >>> https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/
> >>>
> >>> _______________________________________________
> >>> Int-area mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/int-area
> >> _______________________________________________
> >> Int-area mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/int-area