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 5:22 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 4:48 PM, Templin, Fred L wrote:
> > 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?
> 
> That's completely orthogonal to the recommendations of the rest of this
> document, though.

Recommendations for updating RFC791 and RFC1122 seem to be
in scope for this document. What I am suggesting is an update
to RFC1122 which should also be in scope.

> >>> 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?
> 
> Yes; that should read "maximum datagram lifetime" as per RFC 791. I can
> fix that in AUTH48. Thanks,

Maximum datagram lifetime per RFC791 doesn't talk about
the 120sec that your document discusses; Maximum Segment
Lifetime per RFC793 is the one that talks about 120sec.
If you want to talk about 120sec and MSL, you need to
cite RFC793 instead of RFC791.

Thanks - Fred
[e-mail]

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