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

From: [email-masked]
Date: Wed, 30 May 2012 11:46:18 -0700

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/

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 May 2012 11:59:06 -0700

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, [email-masked] wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 30 May 2012 15:54:09 -0700

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?
Asked another way, can we use this document to specify a
reassembly timeout value that IPv4 nodes must observe?

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Joe Touch
> Sent: Wednesday, May 30, 2012 11:59 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-
> 05.txt
> 
> Hi, all,
> 
> > 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.
> >

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 May 2012 15:58:10 -0700

Hi, Fred,

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

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

Joe

>> "o>>" to just">>" prefix.
>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 30 May 2012 16:48:10 -0700

Hi Joe,

> From: Joe Touch [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2012 3:58 PM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]; [email-masked]

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?

> 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

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 May 2012 17:21:53 -0700

Hi, Fred,

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

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

JOe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 May 2012 09:10:26 -0700

Hi Joe,

> Sent: Wednesday, May 30, 2012 5:22 PM
> To: Templin, Fred L

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.

> 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

> >>>>>       closely match IPv6 so that the field's value is defined only
> when
> >> a
> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-intarea-ipv4-id-
> update-
> >>>> 05.txt
> >>>>>
> >>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-intarea-ipv4-id-
> update-
> >>>> 05.txt
> >>>>>

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 May 2012 09:58:31 -0700

Hi, Fred,

> Hi Joe,
...
> to RFC1122 which should also be in scope.

This document is not intended as a vehicle for all updates to RFC1122.

> RFC1122 by saying that the timeout value must be 60 seconds?

That would change things by a factor of 2.

My view:

- reducing reassembly timeout to 60 seconds has negligible impact
	certainly insufficient impact on the issues of this 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

If others disagree, they should speak up.

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

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 May 2012 10:47:28 -0700

Hi Joe,

> Sent: Thursday, May 31, 2012 9:59 AM
> To: Templin, Fred L

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

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

> 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.
 
> should be between 60 and 120 seconds, and recommends 120 seconds without

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 May 2012 10:56:56 -0700

...
...
> fragmentation for IPv4-over-IPv* tunnels.

Perhaps for other uses - as you note - but not to the discussions that 
are the focus of this draft. Which is why, IMO, it should be the focus 
of a different doc.

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

> which have been discussed on the v6ops list recently.

Perhaps, but only as a factor of 2 improvement, and you're raising a 
change that is new.

Again, since this is for a different motivation and because it's not 
documenting existing widespread practice, this seems appropriate for a 
separate document.

> points to the 120sec as being derived from the TCP MSL

The top of page 58 refers to TCP MSL (page 57 does not). And even if it 
refers to 793 as one component in the derivation of the recommendation 
in 1122, it is still 1122 that should be cited, not 793, IMO.

JOe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 May 2012 12:13:01 -0700

Hi Joe,

> Sent: Thursday, May 31, 2012 10:57 AM
> To: Templin, Fred L
> Cc: [email-masked]

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.

> necessarily a reason to document it as best practice - e.g., why are you

60sec is consistent with both RFC1122 and RFC2460.

> documenting existing widespread practice, this seems appropriate for a

As above.
 
> The top of page 58 refers to TCP MSL (page 57 does not).

I said: "beginning at the bottom of P.57". "Beginning"
means "start there and read further".

> And even if it

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.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 May 2012 13:34:05 -0700

Hi, Fred,

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

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

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

---

From: Julien Laganier <[email-masked]>
Date: Thu, 31 May 2012 15:16:51 -0700

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.

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.

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.

Regards,

--julien

On Thu, May 31, 2012 at 1:34 PM, Joe Touch <[email-masked]> wrote:
> reason for adding it is to get a "free ride", and I don't think that's an
> appropriate suggestion for *any* doc.
>
>
> RFC2460 isn't relevant to the reassembly requirements of IPv4; if it were,
> it would be 120 seconds, or would have updated RFC1122 itself.
>
> ...
>
> 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
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 May 2012 16:01:37 -0700

Hi Julien,

> From: Julien Laganier [mailto:[email-masked]]
> Sent: Thursday, May 31, 2012 3:17 PM
> To: Templin, Fred L
> Cc: [email-masked]; Joe Touch; Brian Haberman

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

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

> Last Call comments as well as my recommendation on a disposition.

Please forward the above comments for their consideration
also.

Thanks - Fred

> were,
> to