From brian@innovationslab.net Mon May 7 13:00:32 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F3B21F86C5 for ; Mon, 7 May 2012 13:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pbubiMsF3ZA for ; Mon, 7 May 2012 13:00:32 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id D43C721F86BB for ; Mon, 7 May 2012 13:00:31 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 7C77788120; Mon, 7 May 2012 13:00:31 -0700 (PDT) Received: from clemson.local (c-68-33-164-105.hsd1.dc.comcast.net [68.33.164.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 0CAA114003A; Mon, 7 May 2012 13:00:30 -0700 (PDT) Message-ID: <4FA829DD.201@innovationslab.net> Date: Mon, 07 May 2012 16:00:29 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: draft-ietf-intarea-ipv4-id-update.notify@tools.ietf.org, "intarea-chairs@tools.ietf.org" , int-area@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Int-area] AD Review: draft-ietf-intarea-ipv4-id-update X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 20:00:32 -0000 All, I have performed the AD review for draft-ietf-intarea-ipv4-id-update-04.txt. I have a few comments that I would like addressed before this draft proceeds... * Section 3 states that the IPv6 fragmentation header is only present when a datagram has been fragmented. Section 5 of RFC 2460 allows atomic fragments to carry a fragmentation header in the scenario where a Packet-Too-Big ICMPv6 message has been received for an MTU smaller than 1280 and the packet is subject to translation. This means that there are atomic IPv6 packets that carry a fragmentation header. * Section 4 : I am curious as to what impact you think this document will have with trying to restrict the non-fragmentation use of the ID field. With many of those types of tools around (and people trying to standardize a persistent ID for IPv6 packets), what impact will this document really have? * Section 5 - 2nd paragraph : The use of the 120 second MSL value is misleading. First of all, the 120 seconds is specified as the MSL for TCP, not any other transport protocol. Secondly, my understanding is that implementations use RTT computations to determine when a segment has been lost, not a static MSL timer. The MSL is tunable in a variety of implementations when they are applied to teardown states (e.g., TIME-WIAT). As noted in the draft, implementations are doing something outside of what is specified in RFC 791 to manage their ID values and that is to be expected given the evolution. - 4th paragraph : I am not aware of any routers that actually apply any type of time component to the management of a packet's TTL. * Section 6 presents the classification of atomic and non-atomic packets in a mathematical framework. That framework is not used anywhere else, so I don't see the benefit of the section. * Section 6.1 - The discussion of SMF's use of the ID field is obsolete. The SMF draft (now in the RFC Editor's queue) does not rely on the ID field for any of its packet identification. - The "o >>" notation in the lists is clumsy. I would suggest changing it to strictly ">>" or some other single list icon. * Section 6.3 tries to state the requirements defined in 791 that were not changed. I do not understand why they are restated in terms of 2119 keywords. To me, that is imparting someone's interpretation of the 791 rules. * Section 8.3 discusses the updates to RFC 2003. Why does this section not warrant an itemized list of changes to 2003 like the previous two sections that discuss changes to 791 and 1122? Regards, Brian From touch@isi.edu Mon May 7 13:35:39 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2C421F86B0 for ; Mon, 7 May 2012 13:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.568 X-Spam-Level: X-Spam-Status: No, score=-103.568 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhZeWU+5Tphb for ; Mon, 7 May 2012 13:35:38 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 17B4A21F86AF for ; Mon, 7 May 2012 13:35:38 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q47KZIqs027207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 May 2012 13:35:18 -0700 (PDT) Message-ID: <4FA83204.4000000@isi.edu> Date: Mon, 07 May 2012 13:35:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian Haberman References: <4FA829DD.201@innovationslab.net> In-Reply-To: <4FA829DD.201@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-ietf-intarea-ipv4-id-update.notify@tools.ietf.org, int-area@ietf.org, "intarea-chairs@tools.ietf.org" Subject: Re: [Int-area] AD Review: draft-ietf-intarea-ipv4-id-update X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 20:35:39 -0000 Hi, Brian, Thanks for the feedback. Responses below. On 5/7/2012 1:00 PM, Brian Haberman wrote: > All, > I have performed the AD review for > draft-ietf-intarea-ipv4-id-update-04.txt. I have a few comments that I > would like addressed before this draft proceeds... > > * Section 3 states that the IPv6 fragmentation header is only present > when a datagram has been fragmented. Section 5 of RFC 2460 allows atomic > fragments to carry a fragmentation header in the scenario where a > Packet-Too-Big ICMPv6 message has been received for an MTU smaller than > 1280 and the packet is subject to translation. This means that there are > atomic IPv6 packets that carry a fragmentation header. OK - we will include a note regarding this. > * Section 4 : I am curious as to what impact you think this document > will have with trying to restrict the non-fragmentation use of the ID > field. With many of those types of tools around (and people trying to > standardize a persistent ID for IPv6 packets), what impact will this > document really have? Tools that currently rely on the ID value's uniqueness are already in error in many cases, since the ID is not unique within the required period, and in some cases doesn't change at all (some mobile nets). Part of the document's purpose, IMO, is to inform implementers - both of tools and stacks - on both the assumptions they should make about IDs, how strictly to implement ID uniqueness, and the implications of not doing so correctly. This document makes no statement about the impact of IPv6 ID use, since it is sufficiently large that keeping it unique can require much less effort. > * Section 5 > - 2nd paragraph : The use of the 120 second MSL value is misleading. > First of all, the 120 seconds is specified as the MSL for TCP, not any > other transport protocol. Secondly, my understanding is that > implementations use RTT computations to determine when a segment has > been lost, not a static MSL timer. The MSL is tunable in a variety of > implementations when they are applied to teardown states (e.g., > TIME-WIAT). As noted in the draft, implementations are doing something > outside of what is specified in RFC 791 to manage their ID values and > that is to be expected given the evolution. RFC1122 defines an MSL regarding IP reassembly. It cites RFC793 (TCP) for the upper bound on this value, but its discussion is not limited to TCP (Sec 3.3.2). This is noted the first time we cite 120 seconds, in the first section of the Intro (Sec 1). I can add a reference to RFC1122 here as well if useful. > - 4th paragraph : I am not aware of any routers that actually apply any > type of time component to the management of a packet's TTL. That paragraph already implies this; it cites RFC791 as implying the time component, but notes that this isn't how it's done now. Should that be more explicit? > * Section 6 presents the classification of atomic and non-atomic packets > in a mathematical framework. That framework is not used anywhere else, > so I don't see the benefit of the section. The sole point is to explain how these cases are tested, with an implication that these tests can be used in running code. There is a pending update to clean this up and not give multiple versions of the same test, FWIW. > * Section 6.1 > - The discussion of SMF's use of the ID field is obsolete. The SMF draft > (now in the RFC Editor's queue) does not rely on the ID field for any of > its packet identification. OK; that will be corrected. > - The "o >>" notation in the lists is clumsy. I would suggest changing > it to strictly ">>" or some other single list icon. The list icon is "o". The ">>" notation is used to highlight requirements where RFC2119 words are used (MUST/MAY/SHOULD/etc.), as explained in Sec 2. > * Section 6.3 tries to state the requirements defined in 791 that were > not changed. I do not understand why they are restated in terms of 2119 > keywords. To me, that is imparting someone's interpretation of the 791 > rules. This was vetted by the WG, and is exactly intended to restate the relevant parts of RFC791 regarding the ID using RFC2119 keywords. That is a key part of this document. > * Section 8.3 discusses the updates to RFC 2003. Why does this section > not warrant an itemized list of changes to 2003 like the previous two > sections that discuss changes to 791 and 1122? That was an oversight; we should probably include those as well. Joe > > Regards, > Brian > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From brian.e.carpenter@gmail.com Tue May 8 02:36:47 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC9721F853C for ; Tue, 8 May 2012 02:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwwMnkh7-f5P for ; Tue, 8 May 2012 02:36:47 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C936521F857F for ; Tue, 8 May 2012 02:36:46 -0700 (PDT) Received: by eabd1 with SMTP id d1so1279235eab.31 for ; Tue, 08 May 2012 02:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HKARc5pbTlBWhM1PwPg/EmjcExQm2cC3fQdlDtZO7HI=; b=yFXlvOuFO8YJ57iRe/pzGH2oBwCYNHDMbGa7BXhZFUxbMRiO/awO4MMLv3zj7Qd7Ng KgnCNObmOYxY+FtkJfdtay+lej0bKkkM0GEUsLejrRSZuzATZnOSnx5tInoxIQncXWzB 8LKEIUxUtprKyzXlwb+COSQ7GX/LkLMEkxKCSoPQ6gnPtoml0Mo9qOvZfCwpzNjejOtT Qq/GOgKRQFmzSK1SDJd9yC6++vG+IrKf0JNl0a+v9wlhXV1CN7SxAdYe9ybLvfxMlZMY md/sEOePgA/WweVgyzjno0Lis8nGyOoXQ0tryL25RTc1mPi9mS3zoWFhrSHMCdJVZnSE WEqA== Received: by 10.213.16.204 with SMTP id p12mr1972811eba.26.1336469805486; Tue, 08 May 2012 02:36:45 -0700 (PDT) Received: from [128.232.110.88] (c088.al.cl.cam.ac.uk. [128.232.110.88]) by mx.google.com with ESMTPS id f16sm68868120eec.2.2012.05.08.02.36.44 (version=SSLv3 cipher=OTHER); Tue, 08 May 2012 02:36:44 -0700 (PDT) Message-ID: <4FA8E928.9000103@gmail.com> Date: Tue, 08 May 2012 10:36:40 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: int-area@ietf.org References: <20120426080437.8203.15934.idtracker@ietfa.amsl.com> In-Reply-To: <20120426080437.8203.15934.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Int-area] I-D Action: draft-gont-intarea-obsolete-eid-option-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 09:36:47 -0000 I'm not sure we should do this. The base format defined by draft-ietf-nimrod-eid-00 is generic, with only an initial variant defined for Nimrod, so it could be used for pretty much any future type of EID. I see no harm in leaving the option defined but sleeping. If the draft does proceed, there is a significant issue with it. The Abstract says: "possibly serving as a basis for providing advice about the filtering of packets containing this option." However, the body of the draft doesn't expand on this point; indeed it says: > 2. Security Considerations > > This document has no security implications. > > RFC Editor: Please remove this section before publication. The last sentence is wrong since Security Considerations are mandatory. I think the first sentence is wrong too - if we do decide to obsolete the option, paranoid firewalls will tend to discard packets containing it, and that needs to be noted. All other implementations that skip extension headers will need to continue to skip this one, even if it's officially obsolete, for backwards compatibility. (I have no idea whether current implementations actually do skip this option correctly, but theoretically they ought to.) Regards Brian Carpenter On 2012-04-26 09:04, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Obsoleting the Endpoint Identifier (EID) Option > Author(s) : Fernando Gont > Filename : draft-gont-intarea-obsolete-eid-option-00.txt > Pages : 8 > Date : 2012-04-26 > > This document formally obsoletes the IPv6 Endpoint Identification > (EID) option (hex value 0x8a), thus cleaning up the corresponding > IANA registry, and possibly serving as a basis for providing advice > about the filtering of packets containing this option. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-gont-intarea-obsolete-eid-option-00.txt From brian@innovationslab.net Tue May 8 05:49:42 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB0621F848B for ; Tue, 8 May 2012 05:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7G14arwxkRcc for ; Tue, 8 May 2012 05:49:41 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id BF1E221F848A for ; Tue, 8 May 2012 05:49:41 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id AA6F488124; Tue, 8 May 2012 05:49:41 -0700 (PDT) Received: from Littlejohn.local (c-68-33-164-105.hsd1.dc.comcast.net [68.33.164.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id DF7D213680A1; Tue, 8 May 2012 05:49:40 -0700 (PDT) Message-ID: <4FA91663.30008@innovationslab.net> Date: Tue, 08 May 2012 08:49:39 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Joe Touch References: <4FA829DD.201@innovationslab.net> <4FA83204.4000000@isi.edu> In-Reply-To: <4FA83204.4000000@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-intarea-ipv4-id-update.notify@tools.ietf.org, int-area@ietf.org, "intarea-chairs@tools.ietf.org" Subject: Re: [Int-area] AD Review: draft-ietf-intarea-ipv4-id-update X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 12:49:42 -0000 Hi Joe, I have snipped the portions where no further discussion is needed... On 5/7/12 4:35 PM, Joe Touch wrote: >> * Section 4 : I am curious as to what impact you think this document >> will have with trying to restrict the non-fragmentation use of the ID >> field. With many of those types of tools around (and people trying to >> standardize a persistent ID for IPv6 packets), what impact will this >> document really have? > > Tools that currently rely on the ID value's uniqueness are already in > error in many cases, since the ID is not unique within the required > period, and in some cases doesn't change at all (some mobile nets). Right. I agree that there have been tools developed assuming certain characteristics of the ID field. My question is whether this document will have *any* impact on those tools. > > Part of the document's purpose, IMO, is to inform implementers - both of > tools and stacks - on both the assumptions they should make about IDs, > how strictly to implement ID uniqueness, and the implications of not > doing so correctly. How many new IPv4 stacks do you expect to be implemented from this point forth? How much effort do you see maintainers of current stacks putting into making these proposed changes? Given the opinion expressed in draft-george-ipv6-support, there is some belief that this type of work isn't necessary. I spent a few minutes perusing the bug reports for the Linux kernel and did not come across any mention of issues arising from failed fragmentation re-assembly, which would indicate issues with ID management. > > This document makes no statement about the impact of IPv6 ID use, since > it is sufficiently large that keeping it unique can require much less > effort. I understand that the draft does not change the IPv6 ID. My point was to make sure people realize that there is a community of people who *want* to change the IPv6 ID semantics so that it is in every packet and their IPv4 tools can be re-used for IPv6 traffic. Nothing to add in this document, just a heads-up that some people like the current characteristics of the IPv4 ID field. > >> * Section 5 >> - 2nd paragraph : The use of the 120 second MSL value is misleading. >> First of all, the 120 seconds is specified as the MSL for TCP, not any >> other transport protocol. Secondly, my understanding is that >> implementations use RTT computations to determine when a segment has >> been lost, not a static MSL timer. The MSL is tunable in a variety of >> implementations when they are applied to teardown states (e.g., >> TIME-WIAT). As noted in the draft, implementations are doing something >> outside of what is specified in RFC 791 to manage their ID values and >> that is to be expected given the evolution. > > RFC1122 defines an MSL regarding IP reassembly. It cites RFC793 (TCP) > for the upper bound on this value, but its discussion is not limited to > TCP (Sec 3.3.2). This is noted the first time we cite 120 seconds, in > the first section of the Intro (Sec 1). > > I can add a reference to RFC1122 here as well if useful. That would be useful to ensure consistency. > >> - 4th paragraph : I am not aware of any routers that actually apply any >> type of time component to the management of a packet's TTL. > > That paragraph already implies this; it cites RFC791 as implying the > time component, but notes that this isn't how it's done now. Should that > be more explicit? Yes. In my reading, I could not discern that implication. > >> * Section 6 presents the classification of atomic and non-atomic packets >> in a mathematical framework. That framework is not used anywhere else, >> so I don't see the benefit of the section. > > The sole point is to explain how these cases are tested, with an > implication that these tests can be used in running code. > > There is a pending update to clean this up and not give multiple > versions of the same test, FWIW. Ok. >> - The "o >>" notation in the lists is clumsy. I would suggest changing >> it to strictly ">>" or some other single list icon. > > The list icon is "o". The ">>" notation is used to highlight > requirements where RFC2119 words are used (MUST/MAY/SHOULD/etc.), as > explained in Sec 2. Actually, the added list icon contradicts what is stated in Section 2 (...the characters ">>" proceeding an indented line...). For those items indicating requirements using 2119 keywords, why not just use ">>" as the list icon? > >> * Section 6.3 tries to state the requirements defined in 791 that were >> not changed. I do not understand why they are restated in terms of 2119 >> keywords. To me, that is imparting someone's interpretation of the 791 >> rules. > > This was vetted by the WG, and is exactly intended to restate the > relevant parts of RFC791 regarding the ID using RFC2119 keywords. That > is a key part of this document. Ok. > >> * Section 8.3 discusses the updates to RFC 2003. Why does this section >> not warrant an itemized list of changes to 2003 like the previous two >> sections that discuss changes to 791 and 1122? > > That was an oversight; we should probably include those as well. Ok. I also came across a few editorial issues... - Section 6.2 : s/discusses that TCP retransmits a segment it/discusses that if TCP retransmits a segment, it/ - Section 6.2 : s/in different ways but the same/in different ways but with the same/ - Section 7 : s/that such more frequent reuse/that such frequent reuse/ - Section 8.2 : s/This applies both atomic and/This applies to both atomic and/ - Section 9 : s/including to include 4rd/including 4rd/ - Section 9 : s/comply with requirements as/comply with the requirements as/ Regards, Brian From touch@isi.edu Tue May 8 08:35:22 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3193421F85FB for ; Tue, 8 May 2012 08:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.478 X-Spam-Level: X-Spam-Status: No, score=-103.478 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmPkSLFSonnn for ; Tue, 8 May 2012 08:35:21 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6490421F84C5 for ; Tue, 8 May 2012 08:35:21 -0700 (PDT) Received: from [192.168.1.95] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q48FZ0sn023864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 May 2012 08:35:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: <4FA91663.30008@innovationslab.net> Date: Tue, 8 May 2012 08:35:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <747027CB-68F5-49D5-8D8D-EAA9D4B0A091@isi.edu> References: <4FA829DD.201@innovationslab.net> <4FA83204.4000000@isi.edu> <4FA91663.30008@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1257) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-ietf-intarea-ipv4-id-update.notify@tools.ietf.org, int-area@ietf.org, "intarea-chairs@tools.ietf.org" Subject: Re: [Int-area] AD Review: draft-ietf-intarea-ipv4-id-update X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:35:22 -0000 Hi, Brian, On May 8, 2012, at 5:49 AM, Brian Haberman wrote: > Hi Joe, > I have snipped the portions where no further discussion is = needed... Same here. > On 5/7/12 4:35 PM, Joe Touch wrote: >>> * Section 4 : I am curious as to what impact you think this document >>> will have with trying to restrict the non-fragmentation use of the = ID >>> field. With many of those types of tools around (and people trying = to >>> standardize a persistent ID for IPv6 packets), what impact will this >>> document really have? >>=20 >> Tools that currently rely on the ID value's uniqueness are already in >> error in many cases, since the ID is not unique within the required >> period, and in some cases doesn't change at all (some mobile nets). >=20 > Right. I agree that there have been tools developed assuming certain = characteristics of the ID field. My question is whether this document = will have *any* impact on those tools. We cannot know that in advance. Again, that's not the only reason for = the doc. >> Part of the document's purpose, IMO, is to inform implementers - both = of >> tools and stacks - on both the assumptions they should make about = IDs, >> how strictly to implement ID uniqueness, and the implications of not >> doing so correctly. >=20 > How many new IPv4 stacks do you expect to be implemented from this = point forth? How much effort do you see maintainers of current stacks = putting into making these proposed changes? Given the opinion expressed = in draft-george-ipv6-support, there is some belief that this type of = work isn't necessary. That draft is relevant for IPv6; this document doesn't make statements = about IPv6. > I spent a few minutes perusing the bug reports for the Linux kernel = and did not come across any mention of issues arising from failed = fragmentation re-assembly, which would indicate issues with ID = management. Linux isn't the only OS on the planet, and some of the fragmentation = reassembly errors might never be detected as such. They might result in = more corrupt packets discarded at higher layers, or - esp. for = no-checksum UDP - could result in erroneous data at the application = layer. Reuse of the ID too frequently also can result in false = diagnostic reports. >> This document makes no statement about the impact of IPv6 ID use, = since >> it is sufficiently large that keeping it unique can require much less >> effort. >=20 > I understand that the draft does not change the IPv6 ID. My point was = to make sure people realize that there is a community of people who = *want* to change the IPv6 ID semantics so that it is in every packet and = their IPv4 tools can be re-used for IPv6 traffic. Nothing to add in = this document, just a heads-up that some people like the current = characteristics of the IPv4 ID field. That would be useful to discuss in Intarea further. Forcing unique IDs = can have a very high overhead if implemented correctly, although the = IPv6 ID field is much larger than IPv4 and gives some latitude for now. >>> * Section 5 >>> - 2nd paragraph : The use of the 120 second MSL value is misleading. >>> First of all, the 120 seconds is specified as the MSL for TCP, not = any >>> other transport protocol. Secondly, my understanding is that >>> implementations use RTT computations to determine when a segment has >>> been lost, not a static MSL timer. The MSL is tunable in a variety = of >>> implementations when they are applied to teardown states (e.g., >>> TIME-WIAT). As noted in the draft, implementations are doing = something >>> outside of what is specified in RFC 791 to manage their ID values = and >>> that is to be expected given the evolution. >>=20 >> RFC1122 defines an MSL regarding IP reassembly. It cites RFC793 (TCP) >> for the upper bound on this value, but its discussion is not limited = to >> TCP (Sec 3.3.2). This is noted the first time we cite 120 seconds, in >> the first section of the Intro (Sec 1). >>=20 >> I can add a reference to RFC1122 here as well if useful. >=20 > That would be useful to ensure consistency. Will do. >>> - 4th paragraph : I am not aware of any routers that actually apply = any >>> type of time component to the management of a packet's TTL. >>=20 >> That paragraph already implies this; it cites RFC791 as implying the >> time component, but notes that this isn't how it's done now. Should = that >> be more explicit? >=20 > Yes. In my reading, I could not discern that implication. Will fix. >>> * Section 6 presents the classification of atomic and non-atomic = packets >>> in a mathematical framework. That framework is not used anywhere = else, >>> so I don't see the benefit of the section. >>=20 >> The sole point is to explain how these cases are tested, with an >> implication that these tests can be used in running code. >>=20 >> There is a pending update to clean this up and not give multiple >> versions of the same test, FWIW. >=20 > Ok. >=20 >>> - The "o >>" notation in the lists is clumsy. I would suggest = changing >>> it to strictly ">>" or some other single list icon. >>=20 >> The list icon is "o". The ">>" notation is used to highlight >> requirements where RFC2119 words are used (MUST/MAY/SHOULD/etc.), as >> explained in Sec 2. >=20 > Actually, the added list icon contradicts what is stated in Section 2 = (...the characters ">>" proceeding an indented line...). For those = items indicating requirements using 2119 keywords, why not just use ">>" = as the list icon? Such statements were written first - using the appropriate style - and = the indenting added later. That's why some are just use >> and some = include the list bullet. I can re-check to see if the list bullet can be = removed in some cases where confusion would arise, such as this. >>> * Section 6.3 tries to state the requirements defined in 791 that = were >>> not changed. I do not understand why they are restated in terms of = 2119 >>> keywords. To me, that is imparting someone's interpretation of the = 791 >>> rules. >>=20 >> This was vetted by the WG, and is exactly intended to restate the >> relevant parts of RFC791 regarding the ID using RFC2119 keywords. = That >> is a key part of this document. >=20 > Ok. >=20 >>=20 >>> * Section 8.3 discusses the updates to RFC 2003. Why does this = section >>> not warrant an itemized list of changes to 2003 like the previous = two >>> sections that discuss changes to 791 and 1122? >>=20 >> That was an oversight; we should probably include those as well. >=20 > Ok. >=20 > I also came across a few editorial issues... >=20 > - Section 6.2 : s/discusses that TCP retransmits a segment = it/discusses that if TCP retransmits a segment, it/ >=20 > - Section 6.2 : s/in different ways but the same/in different ways but = with the same/ >=20 > - Section 7 : s/that such more frequent reuse/that such frequent = reuse/ >=20 > - Section 8.2 : s/This applies both atomic and/This applies to both = atomic and/ >=20 > - Section 9 : s/including to include 4rd/including 4rd/ >=20 > - Section 9 : s/comply with requirements as/comply with the = requirements as/ AOK. I'll get an update out with the two pending updates - this and the = one from an area review - shortly so we can proceed. Joe= From wesley.george@twcable.com Wed May 9 10:44:12 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76ADA21F8542 for ; Wed, 9 May 2012 10:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eg9hHxoinAfk for ; Wed, 9 May 2012 10:44:12 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D66D321F8527 for ; Wed, 9 May 2012 10:44:11 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,559,1330923600"; d="scan'208";a="362114163" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 09 May 2012 13:42:46 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 9 May 2012 13:44:10 -0400 From: "George, Wes" To: Joe Touch , Brian Haberman Date: Wed, 9 May 2012 13:44:08 -0400 Thread-Topic: [Int-area] AD Review: draft-ietf-intarea-ipv4-id-update Thread-Index: Ac0tMFVMBlf3BzG3TQK49Mac+PBf+AAz/OKQ Message-ID: References: <4FA829DD.201@innovationslab.net> <4FA83204.4000000@isi.edu> <4FA91663.30008@innovationslab.net> <747027CB-68F5-49D5-8D8D-EAA9D4B0A091@isi.edu> In-Reply-To: <747027CB-68F5-49D5-8D8D-EAA9D4B0A091@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-intarea-ipv4-id-update.notify@tools.ietf.org" , "int-area@ietf.org" , "intarea-chairs@tools.ietf.org" Subject: Re: [Int-area] AD Review: draft-ietf-intarea-ipv4-id-update X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 17:44:12 -0000 > > How many new IPv4 stacks do you expect to be implemented from this > point forth? How much effort do you see maintainers of current stacks > putting into making these proposed changes? Given the opinion expressed > in draft-george-ipv6-support, there is some belief that this type of work= isn't > necessary. > > That draft is relevant for IPv6; this document doesn't make statements ab= out > IPv6. > [WEG] I disagree, and encourage you to re-read the referenced draft, along = with the new charter for v4-sunset. The draft (and to some extent, charter)= is asserting that IPv4 is "done" and that additional IPv4-specfic work nee= ds to address vital operational or security issues. While I agree that a st= rict interpretation of ID uniqueness would be a problem, it's clear that im= plementers long-ago figured out that this was something to be ignored, and = I'm not sure I see the utility of something that simply updates the documen= tation to acknowledge what everyone already knows. I can't point to other s= pecific examples, but I'd bet that's not the only place where some of the o= riginal RFCs are being violated by best common practice and updates were ne= ver completed to correct the guidance. That said, this work predates both d= raft-george and v4-sunset, and I'm not making a recommendation one way or a= nother regarding grandfathering/completing in-flight work. I just wanted t= o clarify the interpretation as it relates to your draft. > > I spent a few minutes perusing the bug reports for the Linux kernel and= did > not come across any mention of issues arising from failed fragmentation r= e- > assembly, which would indicate issues with ID management. > > Linux isn't the only OS on the planet, and some of the fragmentation > reassembly errors might never be detected as such. They might result in > more corrupt packets discarded at higher layers, or - esp. for no-checksu= m > UDP - could result in erroneous data at the application layer. Reuse of t= he ID > too frequently also can result in false diagnostic reports. > [WEG] I think that the point here is that you should be identifying places = where this is a real problem, and not merely a theoretical one. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From touch@isi.edu Wed May 9 13:59:22 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AEE21F8474 for ; Wed, 9 May 2012 13:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGWP3Xm8V+D0 for ; Wed, 9 May 2012 13:59:22 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4C66021F8472 for ; Wed, 9 May 2012 13:59:22 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q49Kwv7L007495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 May 2012 13:58:57 -0700 (PDT) Message-ID: <4FAADA90.8080804@isi.edu> Date: Wed, 09 May 2012 13:58:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "George, Wes" References: <4FA829DD.201@innovationslab.net> <4FA83204.4000000@isi.edu> <4FA91663.30008@innovationslab.net> <747027CB-68F5-49D5-8D8D-EAA9D4B0A091@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "int-area@ietf.org" , "draft-ietf-intarea-ipv4-id-update.notify@tools.ietf.org" , "intarea-chairs@tools.ietf.org" Subject: Re: [Int-area] AD Review: draft-ietf-intarea-ipv4-id-update X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 20:59:23 -0000 On 5/9/2012 10:44 AM, George, Wes wrote: >>> How many new IPv4 stacks do you expect to be implemented from this >> point forth? How much effort do you see maintainers of current stacks >> putting into making these proposed changes? Given the opinion expressed >> in draft-george-ipv6-support, there is some belief that this type of work isn't >> necessary. >> >> That draft is relevant for IPv6; this document doesn't make statements about >> IPv6. >> > [WEG] I disagree, and encourage you to re-read the referenced draft, > along with the new charter for v4-sunset. The draft (and to some extent, > charter) is asserting that IPv4 is "done" and that additional > IPv4-specfic work needs to address vital operational or security issues. Sorry - I focused on the intro - which should include the IPv4 part too, in a future version, FWIW. I agree with what I consider the primary focus of your draft - that V6 issues should be required in new work (which I thought had been agreed a long time ago at least informally). IMO, the IPv4 sunsetting part is poorly justified. Work in IPv6 doesn't come at the expense of work in IPv4, and we typically don't abandon protocol work unless a protocol is deemed historic (and not even then, AFAICT) or *harmful*. The INTAREA WG hasn't come to this conclusion, as you note below. > While I agree that a strict interpretation of ID uniqueness would be a > problem, it's clear that implementers long-ago figured out that this was > something to be ignored, and I'm not sure I see the utility of something > that simply updates the documentation to acknowledge what everyone > already knows. I can't point to other specific examples, but I'd bet > that's not the only place where some of the original RFCs are being > violated by best common practice and updates were never completed to > correct the guidance. That said, this work predates both draft-george > and v4-sunset, and I'm not making a recommendation one way or another > regarding grandfathering/completing in-flight work. I just wanted to > clarify the interpretation as it relates to your draft. > >>> I spent a few minutes perusing the bug reports for the Linux kernel and did >> not come across any mention of issues arising from failed fragmentation re- >> assembly, which would indicate issues with ID management. >> >> Linux isn't the only OS on the planet, and some of the fragmentation >> reassembly errors might never be detected as such. They might result in >> more corrupt packets discarded at higher layers, or - esp. for no-checksum >> UDP - could result in erroneous data at the application layer. Reuse of the ID >> too frequently also can result in false diagnostic reports. >> > [WEG] I think that the point here is that you should be identifying > places where this is a real problem, and not merely a theoretical one. The "problem" is having a requirement that most don't follow, that both unnecessarily constrains compliant implementations and gives a false sense of 'security' for both using the ID as a seed and in analysis equipment. Again, this was discussed in the INTAREA WG meetings before. Joe From internet-drafts@ietf.org Wed May 30 11:46:19 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA21411E80F8; Wed, 30 May 2012 11:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.122 X-Spam-Level: X-Spam-Status: No, score=-102.122 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AoJ6aZ8Uysw; Wed, 30 May 2012 11:46:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D38D11E8079; Wed, 30 May 2012 11:46:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> Date: Wed, 30 May 2012 11:46:18 -0700 Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 18:46:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Area Working Group Working G= roup 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 touch@isi.edu Wed May 30 12:07:50 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8751C11E8189; Wed, 30 May 2012 12:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRVbEW8rbtv2; Wed, 30 May 2012 12:07:49 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id C28E111E80F1; Wed, 30 May 2012 12:07:49 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q4UIx6iO011631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 May 2012 11:59:07 -0700 (PDT) Message-ID: <4FC66DFA.3010300@isi.edu> Date: Wed, 30 May 2012 11:59:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: internet-drafts@ietf.org References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> In-Reply-To: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu 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 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 19:07:50 -0000 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 From Fred.L.Templin@boeing.com Wed May 30 15:54:17 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE31411E80F7; Wed, 30 May 2012 15:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgW2hemSBH-x; Wed, 30 May 2012 15:54:15 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 6887911E80E2; Wed, 30 May 2012 15:54:15 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4UMsBpk023531; Wed, 30 May 2012 15:54:11 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4UMsAEe023528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 May 2012 15:54:10 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4UMsAZi010686; Wed, 30 May 2012 15:54:10 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4UMsAaG010683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 30 May 2012 15:54:10 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Wed, 30 May 2012 15:54:10 -0700 From: "Templin, Fred L" To: Joe Touch , "internet-drafts@ietf.org" Date: Wed, 30 May 2012 15:54:09 -0700 Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt Thread-Index: Ac0+l4QqI5v7DyzwRry5EYSm6i2E6wAHr93A Message-ID: References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> <4FC66DFA.3010300@isi.edu> In-Reply-To: <4FC66DFA.3010300@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No 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 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 22:54:17 -0000 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 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 >=20 > Hi, all, >=20 > 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. >=20 > This version should be ready for publication. >=20 > Joe >=20 > Summary of changes: >=20 > 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 >=20 > Sec 4 -- remove SMF examples because they are no longer suggested >=20 > Sec 6 -- simplified pseudocode and text >=20 > Sec 8.3 -- added specific impact on RFC2003 >=20 > Sec 9 -- added network accelerator packet de-duplication >=20 > Fixed typos throughout, including changing the format of directives from > "o >>" to just ">>" prefix. >=20 > 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 From touch@isi.edu Wed May 30 15:58:44 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C95D11E80EC; Wed, 30 May 2012 15:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agJxaGRPPNHz; Wed, 30 May 2012 15:58:43 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id BA0E211E80F7; Wed, 30 May 2012 15:58:43 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q4UMwAbq003844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 May 2012 15:58:10 -0700 (PDT) Message-ID: <4FC6A602.4050507@isi.edu> Date: Wed, 30 May 2012 15:58:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> <4FC66DFA.3010300@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "int-area@ietf.org" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 22:58:44 -0000 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. > 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. 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 From Fred.L.Templin@boeing.com Wed May 30 16:48:13 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB2B11E80AD; Wed, 30 May 2012 16:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQ9eC5ZV6tNq; Wed, 30 May 2012 16:48:13 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF3B11E8087; Wed, 30 May 2012 16:48:13 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4UNmC9Z004070; Wed, 30 May 2012 16:48:12 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4UNmCTH004067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 May 2012 16:48:12 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4UNmC7a023916; Wed, 30 May 2012 16:48:12 -0700 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4UNmBMB023901 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 30 May 2012 16:48:12 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Wed, 30 May 2012 16:48:11 -0700 From: "Templin, Fred L" To: Joe Touch Date: Wed, 30 May 2012 16:48:10 -0700 Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt Thread-Index: Ac0+t8TDL+AsEAdQRt2O2Q7d8bdssQAAx9nA Message-ID: References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> <4FC66DFA.3010300@isi.edu> <4FC6A602.4050507@isi.edu> In-Reply-To: <4FC6A602.4050507@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "int-area@ietf.org" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 23:48:13 -0000 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 >=20 > Hi, Fred, >=20 > 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? >=20 > 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? > > Asked another way, can we use this document to specify a > > reassembly timeout value that IPv4 nodes must observe? >=20 > 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? Thanks - Fred fred.l.templin@boeing.com > Joe >=20 > > > > 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 v= 6 > >> 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 documen= t > >>> 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 whe= n > 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 From touch@isi.edu Wed May 30 17:22:21 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B7911E8136; Wed, 30 May 2012 17:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4BCAsI1DrCc; Wed, 30 May 2012 17:22:21 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 1100D11E80D5; Wed, 30 May 2012 17:22:21 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q4V0Lrnb004646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 May 2012 17:21:54 -0700 (PDT) Message-ID: <4FC6B9A1.4060409@isi.edu> Date: Wed, 30 May 2012 17:21:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> <4FC66DFA.3010300@isi.edu> <4FC6A602.4050507@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "int-area@ietf.org" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 00:22:21 -0000 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 From iesg-secretary@ietf.org Thu May 31 07:38:17 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4646921F86DA; Thu, 31 May 2012 07:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ebmldwv2j80z; Thu, 31 May 2012 07:38:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F0E21F8644; Thu, 31 May 2012 07:38:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120531143816.30508.66250.idtracker@ietfa.amsl.com> Date: Thu, 31 May 2012 07:38:16 -0700 Cc: int-area@ietf.org Subject: [Int-area] Last Call: (Updated Specification of the IPv4 ID Field) to Proposed Standard X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:38:17 -0000 The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Updated Specification of the IPv4 ID Field' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-06-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/ballot/ No IPR declarations have been submitted directly on this I-D. From Fred.L.Templin@boeing.com Thu May 31 09:10:31 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC1E11E80C8; Thu, 31 May 2012 09:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2qpHA1jR+sG; Thu, 31 May 2012 09:10:30 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 460FF11E8091; Thu, 31 May 2012 09:10:30 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4VGAlWL012464; Thu, 31 May 2012 09:10:47 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4VGAjRw012446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 31 May 2012 09:10:46 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4VGAScB032052; Thu, 31 May 2012 11:10:28 -0500 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4VGARlT031999 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 31 May 2012 11:10:28 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Thu, 31 May 2012 09:10:27 -0700 From: "Templin, Fred L" To: Joe Touch Date: Thu, 31 May 2012 09:10:26 -0700 Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt Thread-Index: Ac0+w3J/++DBXd7YRxWL3Y0qCyCbnAAgnZLA Message-ID: References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> <4FC66DFA.3010300@isi.edu> <4FC6A602.4050507@isi.edu> <4FC6B9A1.4060409@isi.edu> In-Reply-To: <4FC6B9A1.4060409@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "int-area@ietf.org" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 16:10:31 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Wednesday, May 30, 2012 5:22 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 >=20 > Hi, Fred, >=20 > 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? >=20 > 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? >=20 > 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 fred.l.templin@boeing.com > JOe >=20 >=20 > > > > 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] O= n > >>>> 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 b= y > >>>> 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 clea= r > >> 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 From touch@isi.edu Thu May 31 09:59:08 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBB311E8149; Thu, 31 May 2012 09:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HsJEMURv5h5; Thu, 31 May 2012 09:59:07 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 822E611E8147; Thu, 31 May 2012 09:59:07 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q4VGwVid025743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 May 2012 09:58:34 -0700 (PDT) Message-ID: <4FC7A337.70406@isi.edu> Date: Thu, 31 May 2012 09:58:31 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> <4FC66DFA.3010300@isi.edu> <4FC6A602.4050507@isi.edu> <4FC6B9A1.4060409@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "int-area@ietf.org" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 16:59:08 -0000 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. 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. ... >>>> 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. Joe From Fred.L.Templin@boeing.com Thu May 31 10:47:31 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E648011E80C5 for ; Thu, 31 May 2012 10:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+30WbXnMtIu for ; Thu, 31 May 2012 10:47:31 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 59B7111E8096 for ; Thu, 31 May 2012 10:47:31 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4VHlUnw027726 for ; Thu, 31 May 2012 10:47:30 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4VHlUbR027718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 31 May 2012 10:47:30 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4VHlUc9015772; Thu, 31 May 2012 10:47:30 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4VHlTwO015767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 31 May 2012 10:47:29 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Thu, 31 May 2012 10:47:30 -0700 From: "Templin, Fred L" To: Joe Touch Date: Thu, 31 May 2012 10:47:28 -0700 Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt Thread-Index: Ac0/TrKdcEV9zOwIRnWCXmDBcT9k/AABVIOA Message-ID: References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> <4FC66DFA.3010300@isi.edu> <4FC6A602.4050507@isi.edu> <4FC6B9A1.4060409@isi.edu> <4FC7A337.70406@isi.edu> In-Reply-To: <4FC7A337.70406@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 17:47:32 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Thursday, May 31, 2012 9:59 AM > 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 >=20 > Hi, Fred, >=20 > 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. >=20 > This document is not intended as a vehicle for all updates to RFC1122. >=20 > from your earlier post: >=20 > > 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? >=20 > 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: >=20 > - 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 >=20 > - 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. =20 > ... > >>>> 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 ca= n > >> 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. >=20 > 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. >=20 > 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 fred.l.templin@boeing.com =20 >=20 > Joe From touch@isi.edu Thu May 31 10:57:28 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9045B21F8633 for ; Thu, 31 May 2012 10:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IDrg72mL6r2 for ; Thu, 31 May 2012 10:57:28 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id EE49121F8631 for ; Thu, 31 May 2012 10:57:27 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q4VHuu7E017637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 May 2012 10:56:56 -0700 (PDT) Message-ID: <4FC7B0E8.5020306@isi.edu> Date: Thu, 31 May 2012 10:56:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> <4FC66DFA.3010300@isi.edu> <4FC6A602.4050507@isi.edu> <4FC6B9A1.4060409@isi.edu> <4FC7A337.70406@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 17:57:28 -0000 On 5/31/2012 10:47 AM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Thursday, May 31, 2012 9:59 AM >> 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 ... >> That would change things by a factor of 2. ... > 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. 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. >> - 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? >> If others disagree, they should speak up. > > This has implications for IPv4-over-IPv* tunnels, > 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. >> ... >>>>>> 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. 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 Fred.L.Templin@boeing.com Thu May 31 12:13:04 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58AD11E808D for ; Thu, 31 May 2012 12:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9BWuPfz0Qsv for ; Thu, 31 May 2012 12:13:04 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1674011E808C for ; Thu, 31 May 2012 12:13:04 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4VJD3gO012029 for ; Thu, 31 May 2012 12:13:03 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4VJD2hY012013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 31 May 2012 12:13:03 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4VJD2GW022335; Thu, 31 May 2012 12:13:02 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4VJD1K9022302 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 31 May 2012 12:13:02 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Thu, 31 May 2012 12:13:02 -0700 From: "Templin, Fred L" To: Joe Touch Date: Thu, 31 May 2012 12:13:01 -0700 Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt Thread-Index: Ac0/Vt3IWP9YGI7QRVWtoxLau4+8DAAAFKBg Message-ID: References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> <4FC66DFA.3010300@isi.edu> <4FC6A602.4050507@isi.edu> <4FC6B9A1.4060409@isi.edu> <4FC7A337.70406@isi.edu> <4FC7B0E8.5020306@isi.edu> In-Reply-To: <4FC7B0E8.5020306@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 19:13:05 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Thursday, May 31, 2012 10:57 AM > To: Templin, Fred L > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update- > 05.txt >=20 >=20 >=20 > On 5/31/2012 10:47 AM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Thursday, May 31, 2012 9:59 AM > >> 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 > ... > >> That would change things by a factor of 2. > ... > > 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. >=20 > 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. 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. > >> - 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.) >=20 > 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. > >> If others disagree, they should speak up. > > > > This has implications for IPv4-over-IPv* tunnels, > > which have been discussed on the v6ops list recently. >=20 > Perhaps, but only as a factor of 2 improvement, and you're raising a > change that is new. >=20 > Again, since this is for a different motivation and because it's not > documenting existing widespread practice, this seems appropriate for a > separate document. As above. =20 > >> ... > >>>>>> 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 lifetim= e > >> 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. >=20 > 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 > 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. 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 fred.l.templin@boeing.com >=20 > JOe From touch@isi.edu Thu May 31 13:34:29 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EF821F86D0 for ; Thu, 31 May 2012 13:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45R7O6-cgiSY for ; Thu, 31 May 2012 13:34:29 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id EF67221F869C for ; Thu, 31 May 2012 13:34:28 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q4VKY5Lu020325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 May 2012 13:34:05 -0700 (PDT) Message-ID: <4FC7D5BD.4010001@isi.edu> Date: Thu, 31 May 2012 13:34:05 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> <4FC66DFA.3010300@isi.edu> <4FC6A602.4050507@isi.edu> <4FC6B9A1.4060409@isi.edu> <4FC7A337.70406@isi.edu> <4FC7B0E8.5020306@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 20:34:29 -0000 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 From julien.ietf@gmail.com Thu May 31 15:16:54 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EA121F85A2 for ; Thu, 31 May 2012 15:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmPI74lKQXTK for ; Thu, 31 May 2012 15:16:53 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B37F21F863D for ; Thu, 31 May 2012 15:16:52 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2045579pbc.31 for ; Thu, 31 May 2012 15:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PfuBTmjG75uf7KiICXxnIY40uv8BC6f+P/koDDqAsD4=; b=eZDiebK/qKJpFNkuXwfb/7EmruW+xSmPrapm1VjjbmZNehEvU4SFNAlRGvmDBad+qQ a/KATpauCKfIh/T2RaByHBVuIrrAJDUdmU3VIcBKcDryz5zL24fEdnMU73TkfyOIh8qW 8K1DU9xu1Gn3cVnRlN+oe+RKG2HkzlDvk03wZyv/k08+NylRWGuxBjvJm1Kopy9GCr35 aXb0H739YYHsLv862y7U9SBL0DgHIJAdtSiE8U71YG2SOt7hW+RdAwVFYcF+9pPivWY1 hLr1yqihdR73yLqdZ/rOHxBlWUqzS0LrJZmpyEvoxBushofZPgPhhsQH74qGIXbTePuE YXrw== MIME-Version: 1.0 Received: by 10.68.217.138 with SMTP id oy10mr3968422pbc.30.1338502612051; Thu, 31 May 2012 15:16:52 -0700 (PDT) Received: by 10.68.42.230 with HTTP; Thu, 31 May 2012 15:16:51 -0700 (PDT) In-Reply-To: <4FC7D5BD.4010001@isi.edu> References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> <4FC66DFA.3010300@isi.edu> <4FC6A602.4050507@isi.edu> <4FC6B9A1.4060409@isi.edu> <4FC7A337.70406@isi.edu> <4FC7B0E8.5020306@isi.edu> <4FC7D5BD.4010001@isi.edu> Date: Thu, 31 May 2012 15:16:51 -0700 Message-ID: From: Julien Laganier To: "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 22:16:54 -0000 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 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 >>>>> =A0 =A0 =A0 =A0so we'd be adding a new recommendation, rather >>>>> =A0 =A0 =A0 =A0than 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 yo= u >>> 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 t= o > maximum datagram lifetime since this doc has no other reference to transp= ort > protocols. > > Joe > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From Fred.L.Templin@boeing.com Thu May 31 16:01:42 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3353721F8630 for ; Thu, 31 May 2012 16:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG-3+zFG7VK0 for ; Thu, 31 May 2012 16:01:41 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id D799121F8620 for ; Thu, 31 May 2012 16:01:40 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4VN1T8f005060 for ; Thu, 31 May 2012 18:01:30 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4VN1Se5005041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 31 May 2012 18:01:29 -0500 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4VN1c9q030117; Thu, 31 May 2012 16:01:38 -0700 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4VN1clI030114 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 31 May 2012 16:01:38 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Thu, 31 May 2012 16:01:38 -0700 From: "Templin, Fred L" To: Julien Laganier Date: Thu, 31 May 2012 16:01:37 -0700 Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt Thread-Index: Ac0/eyBLbGcWspGyS4mjEF3Dup24/wABDDvw Message-ID: References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> <4FC66DFA.3010300@isi.edu> <4FC6A602.4050507@isi.edu> <4FC6B9A1.4060409@isi.edu> <4FC7A337.70406@isi.edu> <4FC7B0E8.5020306@isi.edu> <4FC7D5BD.4010001@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 23:01:42 -0000 Hi Julien, > -----Original Message----- > From: Julien Laganier [mailto:julien.ietf@gmail.com] > Sent: Thursday, May 31, 2012 3:17 PM > To: Templin, Fred L > Cc: int-area@ietf.org; Joe Touch; Brian Haberman > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update- > 05.txt >=20 > Hi Fred, >=20 > With WG Co-chair hat on, >=20 > 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. > 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.=20 > 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 fred.l.templin@boeing.com > Regards, >=20 > --julien >=20 > On Thu, May 31, 2012 at 1:34 PM, Joe Touch 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 th= e > > community. Your proposed change doesn't meet either criteria - your onl= y > > 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 > >>>>> =A0 =A0 =A0 =A0so we'd be adding a new recommendation, rather > >>>>> =A0 =A0 =A0 =A0than 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 > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area