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: Thursday, May 31, 2012 9:59 AM
> 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/31/2012 9:10 AM, Templin, Fred L wrote:
> > Hi Joe,
> ...
> > 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.
> 
> This document is not intended as a vehicle for all updates to RFC1122.
> 
> from your earlier post:
> 
> > 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 would change things by a factor of 2.

Right, but a 2X performance increase for packetization
layers that allow IPv4 fragmentation is significant.

> My view:
> 
> - reducing reassembly timeout to 60 seconds has negligible impact
> 	certainly insufficient impact on the issues of this doc

A 2X performance increase is not insignificant. And,
there seemed to be some interest for the use of IPv4
fragmentation for IPv4-over-IPv* tunnels.

> - reducing the timeout is not current practice AFAIK
> 	so we'd be adding a new recommendation, rather
> 	than even documenting existing practice
> 
> - my conclusion, based on "keep it simple", is to not include this
> recommendation in this document

Let me ask, do you know of any implementations that have
ever benefitted from keeping the fragments of an incomplete
reassembly for longer than 60sec? (Linux for example only
waits 30sec before discarding fragments.)

> If others disagree, they should speak up.

This has implications for IPv4-over-IPv* tunnels,
which have been discussed on the v6ops list recently.
 
> ...
> >>>> 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.
> 
> Segments aren't datagrams. RFC793 talks about segment lifetimes. RFC1122
> is the only one that talks about datagram lifetimes, relating the
> lifetime described in 791 to 120 seconds.
> 
> I.e., the references are correct, but the term should be "maximum
> datagram lifetime", not "maximum segment lifetime". There is certainly a
> historical note that the 120 seconds in RFC1122 is likely related to
> RFC793, but that's conjecture - 1122 Sec 3.3.2 states that the lifetime
> should be between 60 and 120 seconds, and recommends 120 seconds without
> reference to 793.

That's not how I read the discussion beginning at the
bottom of P. 57 of RFC1122. In my read, that text clearly
points to the 120sec as being derived from the TCP MSL
specification.

Thanks - Fred
[e-mail]
 
> 
> Joe