Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard
Joe Touch <touch@isi.edu> Wed, 06 June 2012 00:55 UTC
Return-Path: <touch@isi.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C354C11E80AE for <ietf@ietfa.amsl.com>; Tue, 5 Jun 2012 17:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.688
X-Spam-Level:
X-Spam-Status: No, score=-102.688 tagged_above=-999 required=5 tests=[AWL=-0.089, 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 l8JE4lTD87u4 for <ietf@ietfa.amsl.com>; Tue, 5 Jun 2012 17:55:20 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9373D11E80AB for <ietf@ietf.org>; Tue, 5 Jun 2012 17:55:20 -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 q560t7rl000553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Jun 2012 17:55:07 -0700 (PDT)
Message-ID: <4FCEAA6B.20204@isi.edu>
Date: Tue, 05 Jun 2012 17:55:07 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard
References: <20120531143816.30508.66250.idtracker@ietfa.amsl.com> <Pine.LNX.4.64.1205311957420.31608@shell4.bayarea.net> <4FC9585E.6010205@necom830.hpcl.titech.ac.jp> <Pine.LNX.4.64.1206022127550.17026@shell4.bayarea.net> <4FCBB71E.9080209@necom830.hpcl.titech.ac.jp>
In-Reply-To: <4FCBB71E.9080209@necom830.hpcl.titech.ac.jp>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jun 2012 00:55:22 -0000
Hi, On 6/3/2012 12:12 PM, Masataka Ohta wrote: > C. M. Heard wrote: > >>> Existing routers, which was relying on ID uniqueness of atomic >>> packets, are now broken when they fragment the atomic packets. >> >> Such routers were always broken. An atomic packet has DF=0 and any >> router fragmenting such a packet was and is non-compliant with >> the relevant specifications (RFCs 791, 1122, 1812). > > Thank you. I have overlooked that atomic implied DF=1. > > But, then, > > >> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID > values within one MSL for a given source address/destination > address/protocol triple. > > makes most, if not all, IPv4 hosts non compliant if MSL=2min. This is already noted throughout this document, however there is little impact to such non-compliance if datagrams don't persist that long. > Worse, without hard value of MSL, it is a meaningless > requirement. Note that MSL=2min derived from RFC793 breaks > 150Mbps TCP. It breaks at 6.4 Mbps for 1500 byte packets, as is already noted in the doc. > The proper solution, IMHO, to the ID uniqueness is to request > a destination host drop fragments from a source host after > it receives tens (or hundreds) of packets with different IDs > from the same source host. That doesn't help ID uniqueness; it helps avoid fragmentation overload. FWIW, such issues were discussed at length in the INTAREA WG when this doc was developed. > A source host, then, is only required to remember the > previous ID used for each destination. They don't do anywhere near that right now, but even if they did it would still be prohibitive in speed (as per above). Joe
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… C. M. Heard
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… C. M. Heard
- Re: [IETF] Re: Last Call: <draft-ietf-intarea-ipv… Warren Kumari
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: [IETF] Re: Last Call: <draft-ietf-intarea-ipv… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Joe Touch
- Re: Last Call: <draft-ietf-intarea-ipv4-id-update… Masataka Ohta