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

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

Below I'll give an alternative which should make the
MSL issue go away:

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Templin, Fred L
> Sent: Thursday, May 31, 2012 4:02 PM
> To: Julien Laganier
> Cc: [e-mail]
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-
> 05.txt
> 
> Hi Julien,
> 
> > -----Original Message-----
> > From: Julien Laganier [mailto:[e-mail]]
> > Sent: Thursday, May 31, 2012 3:17 PM
> > To: Templin, Fred L
> > Cc: [e-mail]; Joe Touch; Brian Haberman
> > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-
> > 05.txt
> >
> > Hi Fred,
> >
> > With WG Co-chair hat on,
> >
> > Changing MSL to Maximum Datagram Lifetime is a minor and almost
> > editorial change that I recommend we make since the use of MSL and
> > possible reference to RFC793 could implicitly restrict the scope of
> > the document to TCP, which is not the case -- this doc applies to IP
> > irrespective of the transport protocol in use.
> 
> From Section 3.3.2 of RFC1122:
> 
>   "If the reassembly timeout is set too high, buffer
>    resources in the receiving host will be tied up too long,
>    and the MSL (Maximum Segment Lifetime) [TCP:1] will be
>    larger than necessary.  The MSL controls the maximum rate
>    at which fragmented datagrams can be sent using distinct
>    values of the 16-bit Ident field; a larger MSL lowers the
>    maximum rate.  The TCP specification [TCP:1] arbitrarily
>    assumes a value of 2 minutes for MSL.  This sets an upper
>    limit on a reasonable reassembly timeout value."
> 
> This clearly shows that the value 120 for reassembly timeout
> came from the TCP MSL specification, and does not take other
> transport protocols into account. For historical correctness,
> the 'ipv4-id-update' document should therefore continue to
> cite "MSL" but should identify RFC793 (and not RFC791) as
> the reference.

In draft-ietf-intarea-ipv4-id-update Section 1, where 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]."

simply delete the citation of [RFC791] and do not replace
it with anything. The text from RFC1122 (cited above) gives
sufficient explanation of MSL and where it came from.

Replacing MSL with "maximum datagram lifetime" would be
incorrect. Per RFC791, maximum datagram lifetime is told
by the TTL which can be at maximum 255 - not 120.

Fred
[e-mail]

> > As to the other change about the reassembly timeout, I agree with Joe
> > that this is out-of-scope of this document in its current form, and I
> > do not think it is appropriate to use a document as a vehicle for
> > changes that are out-of-scope. Furthermore, this document as been in
> > the hands of the Intarea WG for a fair amount of time during which the
> > consensus has been that no changes should be made to the core IP
> > specifications unless something is broken. Your proposal to include
> > considerations on reassembly timeouts does not seem to fix something
> > that is broken in IP and as such is against the consensus of that WG.
> > With both these in mind I recommend against it.
> 
> Based on recent discussions on the v6ops list regarding
> tunneling protocols that perform IPv4 fragmentation, I had
> an obligation to ask for a more favorable reassembly timeout.
> Others who were involved in those discussions have had fair
> opportunity to comment have not done so. I therefore withdraw
> the request.
> 
> > That being said it is up to our AD and the IESG to consider your IETF
> > Last Call comments as well as my recommendation on a disposition.
> 
> Please forward the above comments for their consideration
> also.
> 
> Thanks - Fred
> [e-mail]
> 
> > Regards,
> >
> > --julien
> >
> > On Thu, May 31, 2012 at 1:34 PM, Joe Touch <[e-mail]> wrote:
> > > Hi, Fred,
> > >
> > >
> > > On 5/31/2012 12:13 PM, Templin, Fred L wrote:
> > >>
> > >> Hi Joe,
> > >
> > > ...
> > >
> > >> As you know, the bar for documents that would update
> > >> bedrock specifications such as RFC791 and RFC1122 is
> > >> set very high indeed. That your document has made it
> > >> to this level of maturation is a tribute to your many
> > >> years of concerted effort, which would best be amortized
> > >> if this useful addition can also be applied.
> > >
> > >
> > > As you note, this doc has taken a lot to get to its current state.
> > >
> > > Nothing should be added that isn't core to its purpose AND agreed by
> the
> > > community. Your proposed change doesn't meet either criteria - your
> only
> > > reason for adding it is to get a "free ride", and I don't think that's
> > an
> > > appropriate suggestion for *any* doc.
> > >
> > >
> > >>>>> - 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.)
> > >>>
> > >>>
> > >>> I don't, but that's a discussion that should happen - as you note
> > below
> > >>> - involving those on a different list as well, for a different
> reason.
> > >>> Linux does a lot of things that are not standard, but that alone is
> > not
> > >>> necessarily a reason to document it as best practice - e.g., why are
> > you
> > >>> not suggesting 30 sec?
> > >>
> > >>
> > >> 60sec is consistent with both RFC1122 and RFC2460.
> > >
> > >
> > > RFC2460 isn't relevant to the reassembly requirements of IPv4; if it
> > were,
> > > it would be 120 seconds, or would have updated RFC1122 itself.
> > >
> > > ...
> > >
> > >> If you want to call it MSL you need to cite RFC793. If
> > >> you want to change all occurrences of MSL to something
> > >> else, then you could get away with citing only RFC1122.
> > >> My preference would be to keep it as MSL and cite RFC793.
> > >
> > >
> > > It's only MSL in that one place in this doc, but it's intended to
> refer
> > to
> > > maximum datagram lifetime since this doc has no other reference to
> > transport
> > > protocols.
> > >
> > > Joe
> > >
> > > _______________________________________________
> > > 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