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:touch@isi.edu]
>> Sent: Wednesday, May 30, 2012 3:58 PM
>> To: Templin, Fred L
>> Cc: internet-drafts@ietf.org; int-area@ietf.org; i-d-announce@ietf.org
>> 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.

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

JOe

>
> Thanks - Fred
> fred.l.templin@boeing.com
>
>> Joe
>>
>>>
>>> Thanks - Fred
>>> fred.l.templin@boeing.com
>>>
>>>
>>>> -----Original Message-----
>>>> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On
>>>> Behalf Of Joe Touch
>>>> Sent: Wednesday, May 30, 2012 11:59 AM
>>>> To: internet-drafts@ietf.org
>>>> Cc: int-area@ietf.org; i-d-announce@ietf.org
>>>> 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, internet-drafts@ietf.org 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
>>>>> Int-area@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/int-area
>>>> _______________________________________________
>>>> Int-area mailing list
>>>> Int-area@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/int-area