From teco@inf-net.nl Fri Apr 1 01:12:39 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FBC83A6C0B for ; Fri, 1 Apr 2011 01:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-MXq-2Oi7Wr for ; Fri, 1 Apr 2011 01:12:38 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 4AB3C3A6C08 for ; Fri, 1 Apr 2011 01:12:38 -0700 (PDT) Received: by bwz13 with SMTP id 13so2539032bwz.31 for ; Fri, 01 Apr 2011 01:14:17 -0700 (PDT) Received: by 10.204.130.16 with SMTP id q16mr3229337bks.192.1301645657689; Fri, 01 Apr 2011 01:14:17 -0700 (PDT) Received: from dhcp-14b8.meeting.ietf.org (dhcp-14b8.meeting.ietf.org [130.129.20.184]) by mx.google.com with ESMTPS id b6sm1208396bkb.22.2011.04.01.01.14.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 01:14:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4D94BDA0.6010402@isi.edu> Date: Fri, 1 Apr 2011 10:14:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D94BDA0.6010402@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) Cc: int-area@ietf.org Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:12:39 -0000 Hi Joe, You made me more optimistic.=20 Op 31 mrt 2011, om 19:45 heeft Joe Touch het volgende geschreven: > Hi, Deco, It is Teco. >=20 > This proposal is a moot point; the FO needs to be zero for a packet to = be ATOMIC. see below: >=20 > On 3/31/2011 4:41 AM, Teco Boot wrote: >> Having a discussion on recycling used IPv4 header bits, I made >> a snapshot on what was in the air at same point in time, somewhere. >> I found out the ID field of atomic packets was filled for almost >> all packets. >>=20 >> IPv4 total: 151081 >> Atomic packets: 105357 (70%) >> On atomic packets: >> ID =3D=3D 0 1557 ( 1,5%) >> ID !=3D 0 103800 ( 98,5%) >> FO =3D=3D 0 105357 (100,0%) >>=20 >> The Fragment Offset was always set on zero, I read this as unused. >=20 > That is incorrect. It is part of what makes a packet atomic, as per = the ipv4-id-update draft: >=20 > (DF=3D=3D1)&&(MF=3D=3D0)&&(frag_offset=3D=3D0) But this is a modification of RFC 791: An internet datagram can be marked "don't fragment." Any internet datagram so marked is not to be internet fragmented under any circumstances. It is reported there were packets around with illegal fragmentation. But since when do we adjust specs because there are bugs or = non-compliant=20 implementations? Update RFC 4963 also, where such behavior is = disapproved? >=20 > Let's look at the cases: >=20 > DF MF FO > 0 x x CAN FRAGMENT > non-atomic packet that can be fragmented downstream; > that fragmentation would overwrite MF and FO This leads towards: ! (DF=3D0) =3D=3D ! ( CAN FRAGMENT) =3D=3D CANNOT FRAGMENT =3D=3D = ATOMIC Or: (DF=3D1) =3D=3D ATOMIC > 1 0 0 ATOMIC =09 > basically this is a lot like saying > "this is the first and last fragment" >=20 > 1 0 nonzero LAST FRAGMENT > packet has already been fragmented and > this is the last fragment >=20 > 1 1 0 FIRST FRAGMENT > packet has already been fragmented, and this is the > first fragment and NOT the last (other fragments > with higher offsets are expected) >=20 > 1 1 nonzero MIDDLE FRAGMENT > packet has already been fragmented, and this is > not the first fragment, and other fragments are > expected This makes me optimistic: packets with DF=3D1 and FO!=3D0 are valid and intermediate nodes MUST NOT drop such packets. When DF=3D1, MF is unused also, so there are 14 bits waiting to be = recycled. > Note that thus: >=20 > ATOMIC packets are *defined* by having all the FO bits as zero. >=20 > > What comes up in my mind: can we recycle the 13 fragment offset = bits? > > Instead of ID field? At least it may be a well defined starting = point. >=20 > When the bits aren't zero, an otherwise ATOMIC packet is really a last = fragment. >=20 > So if you try to use those bits, all you will accomplish is flooding = the reassembly cache. No. RFC 791 compliant nodes receiving such packets SHOULD drop these.=20 Re-usage of the bits for atomic packets needs updated nodes. A = requirement=20 would be a test if the bits can be used. Thanks, Teco >=20 > Joe From touch@isi.edu Fri Apr 1 02:15:05 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E349C3A6774 for ; Fri, 1 Apr 2011 02:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.611 X-Spam-Level: X-Spam-Status: No, score=-103.611 tagged_above=-999 required=5 tests=[AWL=-1.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKx0UcBxygl6 for ; Fri, 1 Apr 2011 02:15:05 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 2E2193A679F for ; Fri, 1 Apr 2011 02:15:05 -0700 (PDT) Received: from [130.129.67.235] (dhcp-43eb.meeting.ietf.org [130.129.67.235]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p319G82u001238 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2011 02:16:22 -0700 (PDT) Message-ID: <4D9597D5.9080604@isi.edu> Date: Fri, 01 Apr 2011 02:16:05 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Teco Boot References: <4D94BDA0.6010402@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p319G82u001238 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: int-area@ietf.org Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:15:06 -0000 On 4/1/2011 1:14 AM, Teco Boot wrote: ... >> On 3/31/2011 4:41 AM, Teco Boot wrote: >>> Having a discussion on recycling used IPv4 header bits, I made >>> a snapshot on what was in the air at same point in time, somewhere. >>> I found out the ID field of atomic packets was filled for almost >>> all packets. >>> >>> IPv4 total: 151081 >>> Atomic packets: 105357 (70%) >>> On atomic packets: >>> ID == 0 1557 ( 1,5%) >>> ID != 0 103800 ( 98,5%) >>> FO == 0 105357 (100,0%) >>> >>> The Fragment Offset was always set on zero, I read this as unused. >> >> That is incorrect. It is part of what makes a packet atomic, as per the ipv4-id-update draft: >> >> (DF==1)&&(MF==0)&&(frag_offset==0) > > But this is a modification of RFC 791: > An internet datagram can be marked "don't fragment." Any internet > datagram so marked is not to be internet fragmented under any > circumstances. > It is reported there were packets around with illegal fragmentation. > But since when do we adjust specs because there are bugs or non-compliant > implementations? Update RFC 4963 also, where such behavior is disapproved? I was never talking about a case where the DF bit is ignored. >> Let's look at the cases: >> >> DF MF FO >> 0 x x CAN FRAGMENT >> non-atomic packet that can be fragmented downstream; >> that fragmentation would overwrite MF and FO > > This leads towards: > ! (DF=0) == ! ( CAN FRAGMENT) == CANNOT FRAGMENT == ATOMIC > Or: > (DF=1) == ATOMIC DF=1 means "don't fragment what I just sent". The source can fragment, though, and THEN set DF on the fragments. That is exactly how an IPv4 host most closely behaves like an IPv6 host - the latter permitting only source fragmentation. This is why ipv4-id-update doesn't use the term "DF=1"; it uses the term ATOMIC because atomic means: - must not fragment from this point forward AND - has not already been fragmented yet DF=1 needs to be preserved to avoid interfering with upstream detection of MTUs along a path, but it can be changed from 0 to 1 by a router. However, even ignoring that case, DF=1 isn't enough to know the difference between packets that have already been fragmented by the source. >> 1 0 0 ATOMIC >> basically this is a lot like saying >> "this is the first and last fragment" >> >> 1 0 nonzero LAST FRAGMENT >> packet has already been fragmented and >> this is the last fragment >> >> 1 1 0 FIRST FRAGMENT >> packet has already been fragmented, and this is the >> first fragment and NOT the last (other fragments >> with higher offsets are expected) >> >> 1 1 nonzero MIDDLE FRAGMENT >> packet has already been fragmented, and this is >> not the first fragment, and other fragments are >> expected > > This makes me optimistic: packets with DF=1 and FO!=0 are valid and > intermediate nodes MUST NOT drop such packets. Absolutely. They're packets that have already been fragmented, e.g., by the source. That also means you can't use the FO field, though. > When DF=1, MF is unused also, so there are 14 bits waiting to be recycled. No; see above. These are valid cases of source fragmentation. >> Note that thus: >> >> ATOMIC packets are *defined* by having all the FO bits as zero. >> >>> What comes up in my mind: can we recycle the 13 fragment offset bits? >>> Instead of ID field? At least it may be a well defined starting point. >> >> When the bits aren't zero, an otherwise ATOMIC packet is really a last fragment. >> >> So if you try to use those bits, all you will accomplish is flooding the reassembly cache. > > No. RFC 791 compliant nodes receiving such packets SHOULD drop these. If you do, you're disabling source fragmentation. RFC 791 definitely does not prohibit that. Joe From touch@isi.edu Fri Apr 1 02:43:37 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55F503A679C for ; Fri, 1 Apr 2011 02:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTiugunXD9qR for ; Fri, 1 Apr 2011 02:43:36 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 905493A6774 for ; Fri, 1 Apr 2011 02:43:36 -0700 (PDT) Received: from [130.129.67.235] (dhcp-43eb.meeting.ietf.org [130.129.67.235]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p319iqgj005925 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2011 02:45:05 -0700 (PDT) Message-ID: <4D959E93.4060803@isi.edu> Date: Fri, 01 Apr 2011 02:44:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Teco Boot References: <4D94BDA0.6010402@isi.edu> <4D9597D5.9080604@isi.edu> In-Reply-To: <4D9597D5.9080604@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p319iqgj005925 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: int-area@ietf.org Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:43:37 -0000 PS - this is discussed indirectly in Sec 3 of the ipv4-id-update doc, but it seems clear from this discussion that further explanation of source vs. downstream fragmentation would be useful to include. I'll update the ID shortly with that info, as well as confirming whether downstream routers can change DF. They clearly MUST NOT change from 1 to 0, but it nothing appears to prohibit them from changing it from 0 to 1 it's not mentioned in RFC 1812 or its updates), and that's dangerous because that router might not be on the return path of the ICMP too-big messages, so they wouldn't be able to react and thus the change has no utility. It may be useful to add a MUST NOT (a SHOULD NOT at least, but I can't think of a safe exception) on setting the DF bit as a result. Joe PS - RFC 4963 is informational; updates apply to standards-track docs only AFAICT. I'll add that to the doc as well, though, since it does include discussions of some of the issues discussed. On 4/1/2011 2:16 AM, Joe Touch wrote: > > > On 4/1/2011 1:14 AM, Teco Boot wrote: > ... >>> On 3/31/2011 4:41 AM, Teco Boot wrote: >>>> Having a discussion on recycling used IPv4 header bits, I made >>>> a snapshot on what was in the air at same point in time, somewhere. >>>> I found out the ID field of atomic packets was filled for almost >>>> all packets. >>>> >>>> IPv4 total: 151081 >>>> Atomic packets: 105357 (70%) >>>> On atomic packets: >>>> ID == 0 1557 ( 1,5%) >>>> ID != 0 103800 ( 98,5%) >>>> FO == 0 105357 (100,0%) >>>> >>>> The Fragment Offset was always set on zero, I read this as unused. >>> >>> That is incorrect. It is part of what makes a packet atomic, as per >>> the ipv4-id-update draft: >>> >>> (DF==1)&&(MF==0)&&(frag_offset==0) >> >> But this is a modification of RFC 791: >> An internet datagram can be marked "don't fragment." Any internet >> datagram so marked is not to be internet fragmented under any >> circumstances. >> It is reported there were packets around with illegal fragmentation. >> But since when do we adjust specs because there are bugs or non-compliant >> implementations? Update RFC 4963 also, where such behavior is >> disapproved? > > I was never talking about a case where the DF bit is ignored. > >>> Let's look at the cases: >>> >>> DF MF FO >>> 0 x x CAN FRAGMENT >>> non-atomic packet that can be fragmented downstream; >>> that fragmentation would overwrite MF and FO >> >> This leads towards: >> ! (DF=0) == ! ( CAN FRAGMENT) == CANNOT FRAGMENT == ATOMIC >> Or: >> (DF=1) == ATOMIC > > DF=1 means "don't fragment what I just sent". > > The source can fragment, though, and THEN set DF on the fragments. That > is exactly how an IPv4 host most closely behaves like an IPv6 host - the > latter permitting only source fragmentation. > > This is why ipv4-id-update doesn't use the term "DF=1"; it uses the term > ATOMIC because atomic means: > - must not fragment from this point forward > AND > - has not already been fragmented yet > > DF=1 needs to be preserved to avoid interfering with upstream detection > of MTUs along a path, but it can be changed from 0 to 1 by a router. > However, even ignoring that case, DF=1 isn't enough to know the > difference between packets that have already been fragmented by the source. > >>> 1 0 0 ATOMIC >>> basically this is a lot like saying >>> "this is the first and last fragment" >>> >>> 1 0 nonzero LAST FRAGMENT >>> packet has already been fragmented and >>> this is the last fragment >>> >>> 1 1 0 FIRST FRAGMENT >>> packet has already been fragmented, and this is the >>> first fragment and NOT the last (other fragments >>> with higher offsets are expected) >>> >>> 1 1 nonzero MIDDLE FRAGMENT >>> packet has already been fragmented, and this is >>> not the first fragment, and other fragments are >>> expected >> >> This makes me optimistic: packets with DF=1 and FO!=0 are valid and >> intermediate nodes MUST NOT drop such packets. > > Absolutely. They're packets that have already been fragmented, e.g., by > the source. That also means you can't use the FO field, though. > >> When DF=1, MF is unused also, so there are 14 bits waiting to be >> recycled. > > No; see above. These are valid cases of source fragmentation. > >>> Note that thus: >>> >>> ATOMIC packets are *defined* by having all the FO bits as zero. >>> >>>> What comes up in my mind: can we recycle the 13 fragment offset bits? >>>> Instead of ID field? At least it may be a well defined starting point. >>> >>> When the bits aren't zero, an otherwise ATOMIC packet is really a >>> last fragment. >>> >>> So if you try to use those bits, all you will accomplish is flooding >>> the reassembly cache. >> >> No. RFC 791 compliant nodes receiving such packets SHOULD drop these. > > If you do, you're disabling source fragmentation. RFC 791 definitely > does not prohibit that. > > Joe From touch@isi.edu Fri Apr 1 02:50:31 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3803A67AE for ; Fri, 1 Apr 2011 02:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.536 X-Spam-Level: X-Spam-Status: No, score=-103.536 tagged_above=-999 required=5 tests=[AWL=-0.937, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prFQ5F2DgQBL for ; Fri, 1 Apr 2011 02:50:31 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 9DA6B3A67AD for ; Fri, 1 Apr 2011 02:50:30 -0700 (PDT) Received: from [130.129.67.235] (dhcp-43eb.meeting.ietf.org [130.129.67.235]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p319pXFU006575 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2011 02:51:50 -0700 (PDT) Message-ID: <4D95A020.6030303@isi.edu> Date: Fri, 01 Apr 2011 02:51:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: int-area@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p319pXFU006575 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [Int-area] ipv4-id-update question on routers setting DF bit X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:50:31 -0000 Hi, all, A separate discussion on possible reuse of the ID and frag_offset fields (the latter which I hope has been put to rest) raised an issue which the current ipv4-id-update doc does not address: * Can intermediate devices (e.g., routers) set the DF bit? It's clear they MUST NOT clear the bit (DF=1 -> 0) as this would interfere with the purpose of setting the bit. However, there doesn't appear to be any explicit advice on setting the bit (DF=0 -> 1). I'm still digging around for that, and if anyone knows more, please post. Regardless, it seems that setting the bit is even more dangerous, because the returning ICMP too-big messages might not arrive at the device at the router which sets it, due to legitimate (and even common) path asymmetries. So I'm wondering whether the doc should also include one of the following: - intermediate devices MUST NOT set the DF bit - intermediate devices SHOULD NOT set the DF bit (this case would require a description of a legitimate case, but there does not appear to be any such case which is safe) Comments would be appreciated. Joe From teco@inf-net.nl Fri Apr 1 02:57:09 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA683A67AE for ; Fri, 1 Apr 2011 02:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtLOAZbtDo-p for ; Fri, 1 Apr 2011 02:57:08 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 659B93A6783 for ; Fri, 1 Apr 2011 02:57:08 -0700 (PDT) Received: by bwz13 with SMTP id 13so2598539bwz.31 for ; Fri, 01 Apr 2011 02:58:48 -0700 (PDT) Received: by 10.204.187.129 with SMTP id cw1mr3349188bkb.138.1301651927975; Fri, 01 Apr 2011 02:58:47 -0700 (PDT) Received: from dhcp-14b8.meeting.ietf.org (dhcp-14b8.meeting.ietf.org [130.129.20.184]) by mx.google.com with ESMTPS id w3sm1281167bkt.5.2011.04.01.02.58.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 02:58:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4D9597D5.9080604@isi.edu> Date: Fri, 1 Apr 2011 11:58:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D94BDA0.6010402@isi.edu> <4D9597D5.9080604@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) Cc: int-area@ietf.org Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:57:09 -0000 Op 1 apr 2011, om 11:16 heeft Joe Touch het volgende geschreven: > On 4/1/2011 1:14 AM, Teco Boot wrote: > ... >>> On 3/31/2011 4:41 AM, Teco Boot wrote: >>>> Having a discussion on recycling used IPv4 header bits, I made >>>> a snapshot on what was in the air at same point in time, somewhere. >>>> I found out the ID field of atomic packets was filled for almost >>>> all packets. >>>>=20 >>>> IPv4 total: 151081 >>>> Atomic packets: 105357 (70%) >>>> On atomic packets: >>>> ID =3D=3D 0 1557 ( 1,5%) >>>> ID !=3D 0 103800 ( 98,5%) >>>> FO =3D=3D 0 105357 (100,0%) >>>>=20 >>>> The Fragment Offset was always set on zero, I read this as unused. >>>=20 >>> That is incorrect. It is part of what makes a packet atomic, as per = the ipv4-id-update draft: >>>=20 >>> (DF=3D=3D1)&&(MF=3D=3D0)&&(frag_offset=3D=3D0) >>=20 >> But this is a modification of RFC 791: >> An internet datagram can be marked "don't fragment." Any = internet >> datagram so marked is not to be internet fragmented under any >> circumstances. >> It is reported there were packets around with illegal fragmentation. >> But since when do we adjust specs because there are bugs or = non-compliant >> implementations? Update RFC 4963 also, where such behavior is = disapproved? >=20 > I was never talking about a case where the DF bit is ignored. >=20 >>> Let's look at the cases: >>>=20 >>> DF MF FO >>> 0 x x CAN FRAGMENT >>> non-atomic packet that can be fragmented downstream; >>> that fragmentation would overwrite MF and FO >>=20 >> This leads towards: >> ! (DF=3D0) =3D=3D ! ( CAN FRAGMENT) =3D=3D CANNOT FRAGMENT =3D=3D = ATOMIC >> Or: >> (DF=3D1) =3D=3D ATOMIC >=20 > DF=3D1 means "don't fragment what I just sent". >=20 > The source can fragment, though, and THEN set DF on the fragments. = That is exactly how an IPv4 host most closely behaves like an IPv6 host = - the latter permitting only source fragmentation. >=20 > This is why ipv4-id-update doesn't use the term "DF=3D1"; it uses the = term ATOMIC because atomic means: > - must not fragment from this point forward > AND > - has not already been fragmented yet >=20 > DF=3D1 needs to be preserved to avoid interfering with upstream = detection of MTUs along a path, but it can be changed from 0 to 1 by a = router. However, even ignoring that case, DF=3D1 isn't enough to know = the difference between packets that have already been fragmented by the = source. The RFC 791 DF example (page 25) describes the use case where DF=3D1 = packets are atomic, and both source and destination are aware. When we = update RFC 791 for reuse FO, source and destination must make sure the = bits are recycled. As you pointed out, nodes in the middle MUST handle = such packets as normal. >>> 1 0 0 ATOMIC =09 >>> basically this is a lot like saying >>> "this is the first and last fragment" >>>=20 >>> 1 0 nonzero LAST FRAGMENT >>> packet has already been fragmented and >>> this is the last fragment >>>=20 >>> 1 1 0 FIRST FRAGMENT >>> packet has already been fragmented, and this is the >>> first fragment and NOT the last (other fragments >>> with higher offsets are expected) >>>=20 >>> 1 1 nonzero MIDDLE FRAGMENT >>> packet has already been fragmented, and this is >>> not the first fragment, and other fragments are >>> expected >>=20 >> This makes me optimistic: packets with DF=3D1 and FO!=3D0 are valid = and >> intermediate nodes MUST NOT drop such packets. >=20 > Absolutely. They're packets that have already been fragmented, e.g., = by the source. That also means you can't use the FO field, though. FO can be reused, if both source and destination choose to do so. >> When DF=3D1, MF is unused also, so there are 14 bits waiting to be = recycled. >=20 > No; see above. These are valid cases of source fragmentation. If hosts follow RFC 791. >>> Note that thus: >>>=20 >>> ATOMIC packets are *defined* by having all the FO bits as zero. >>>=20 >>>> What comes up in my mind: can we recycle the 13 fragment offset = bits? >>>> Instead of ID field? At least it may be a well defined starting = point. >>>=20 >>> When the bits aren't zero, an otherwise ATOMIC packet is really a = last fragment. >>>=20 >>> So if you try to use those bits, all you will accomplish is flooding = the reassembly cache. >>=20 >> No. RFC 791 compliant nodes receiving such packets SHOULD drop these. >=20 > If you do, you're disabling source fragmentation. RFC 791 definitely = does not prohibit that. Nor does describe it. This brings us to recycle, or not. I don't see any technical hindrance = anymore. Teco From touch@isi.edu Fri Apr 1 03:33:24 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4122C3A67ED for ; Fri, 1 Apr 2011 03:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.503 X-Spam-Level: X-Spam-Status: No, score=-103.503 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODzKmnbyoLbr for ; Fri, 1 Apr 2011 03:33:19 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 64F833A67E6 for ; Fri, 1 Apr 2011 03:33:19 -0700 (PDT) Received: from [130.129.67.235] (dhcp-43eb.meeting.ietf.org [130.129.67.235]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p31AYEFt012520 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2011 03:34:30 -0700 (PDT) Message-ID: <4D95AA24.2010502@isi.edu> Date: Fri, 01 Apr 2011 03:34:12 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Teco Boot References: <4D94BDA0.6010402@isi.edu> <4D9597D5.9080604@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p31AYEFt012520 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: int-area@ietf.org Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 10:33:24 -0000 On 4/1/2011 2:58 AM, Teco Boot wrote: ... >> DF=1 means "don't fragment what I just sent". >> >> The source can fragment, though, and THEN set DF on the fragments. >> That is exactly how an IPv4 host most closely behaves like an IPv6 >> host - the latter permitting only source fragmentation. >> >> This is why ipv4-id-update doesn't use the term "DF=1"; it uses >> the term ATOMIC because atomic means: >> - must not fragment from this point forward >> AND >> - has not already been fragmented yet >> >> DF=1 needs to be preserved to avoid interfering with upstream >> detection of MTUs along a path, but it can be changed from 0 to 1 >> by a router. However, even ignoring that case, DF=1 isn't enough to >> know the difference between packets that have already been >> fragmented by the source. > > The RFC 791 DF example (page 25) describes the use case where DF=1 > packets are atomic, and both source and destination are aware. The source knows it's setting DF, but the destination has no way of knowing that. As I noted in a subsequent post, there doesn't appear to be any prohibition on routers changing DF=0 to DF-1, even though it doesn't seem safe. > When we update RFC 791 for reuse FO, source and destination must make > sure the bits are recycled. As you pointed out, nodes in the middle > MUST handle such packets as normal. The ipv4-id-update doc does *not* update RFC791 to reuse FO, just to be clear. If you want to do that, there's much more work to do - e.g., to check whether existing routers set DF. >>>> 1 0 0 ATOMIC >>>> basically this is a lot like saying >>>> "this is the first and last fragment" >>>> >>>> 1 0 nonzero LAST FRAGMENT >>>> packet has already been fragmented and >>>> this is the last fragment >>>> >>>> 1 1 0 FIRST FRAGMENT >>>> packet has already been fragmented, and this is the >>>> first fragment and NOT the last (other fragments >>>> with higher offsets are expected) >>>> >>>> 1 1 nonzero MIDDLE FRAGMENT >>>> packet has already been fragmented, and this is >>>> not the first fragment, and other fragments are >>>> expected >>> >>> This makes me optimistic: packets with DF=1 and FO!=0 are valid and >>> intermediate nodes MUST NOT drop such packets. >> >> Absolutely. They're packets that have already been fragmented, e.g., by the source. That also means you can't use the FO field, though. > > FO can be reused, if both source and destination choose to do so. There are two possibilities: - a source NEVER sets DF=0 - a source sets DF=0 and no routers on the path ever set it ipv4-id-update doesn't prohibit either case per se, and the receiver cannot know either case just from the packets it sees Even if we describe how routers setting DF is dangerous, we can't know when it's happening. >>> When DF=1, MF is unused also, so there are 14 bits waiting to be recycled. >> >> No; see above. These are valid cases of source fragmentation. > > If hosts follow RFC 791. Sure; we're surely not talking about violations of spec. There's no point in discussing that case further. >>>> Note that thus: >>>> >>>> ATOMIC packets are *defined* by having all the FO bits as zero. >>>> >>>>> What comes up in my mind: can we recycle the 13 fragment offset bits? >>>>> Instead of ID field? At least it may be a well defined starting point. >>>> >>>> When the bits aren't zero, an otherwise ATOMIC packet is really a last fragment. >>>> >>>> So if you try to use those bits, all you will accomplish is flooding the reassembly cache. >>> >>> No. RFC 791 compliant nodes receiving such packets SHOULD drop these. >> >> If you do, you're disabling source fragmentation. RFC 791 definitely does not prohibit that. > > Nor does describe it. There are two behaviors not explicitly described by RFC791: A- valid uses of source fragmentation with DF=1 B- dropping source fragmented packets where DF=1, solely for that reason The example reassembly algorithm in sec 3.2 does not examine the DF bit, which permits case A. However, case B is prohibited by RFC1191, since it would disable all of source fragmentation. > This brings us to recycle, or not. I don't see any technical hindrance anymore. There are at least three problems: 1) dropping fragments where DF=1 isn't required by any RFC 2) dropping fragments where DF=1 would break current standards, e.g., PMTUD RFC1191 (draft standard) 3) dropping fragments where DF=1 for IPv4 would prohibit the defining case for fragmentation in IPv6 (which explicitly describes its use of fragmentation in terms of "DF=1 always set, source permitted") Finally, I'd wager that the *bulk* of current fragments have DF=1. Joe From teco@inf-net.nl Fri Apr 1 05:09:16 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8585028C1F6 for ; Fri, 1 Apr 2011 05:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqZ+mZxfxR2w for ; Fri, 1 Apr 2011 05:09:15 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id EAA8228D21C for ; Fri, 1 Apr 2011 05:04:41 -0700 (PDT) Received: by bwz13 with SMTP id 13so2679572bwz.31 for ; Fri, 01 Apr 2011 05:06:21 -0700 (PDT) Received: by 10.204.10.81 with SMTP id o17mr3534516bko.94.1301659581573; Fri, 01 Apr 2011 05:06:21 -0700 (PDT) Received: from dhcp-14b8.meeting.ietf.org (dhcp-14b8.meeting.ietf.org [130.129.20.184]) by mx.google.com with ESMTPS id w3sm1357580bkt.17.2011.04.01.05.06.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 05:06:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4D95AA24.2010502@isi.edu> Date: Fri, 1 Apr 2011 14:06:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> References: <4D94BDA0.6010402@isi.edu> <4D9597D5.9080604@isi.edu> <4D95AA24.2010502@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) Cc: int-area@ietf.org Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 12:09:16 -0000 Op 1 apr 2011, om 12:34 heeft Joe Touch het volgende geschreven: > On 4/1/2011 2:58 AM, Teco Boot wrote: > ... >>> DF=3D1 means "don't fragment what I just sent". >>>=20 >>> The source can fragment, though, and THEN set DF on the fragments. >>> That is exactly how an IPv4 host most closely behaves like an IPv6 >>> host - the latter permitting only source fragmentation. >>>=20 >>> This is why ipv4-id-update doesn't use the term "DF=3D1"; it uses >>> the term ATOMIC because atomic means: >>> - must not fragment from this point forward >>> AND >>> - has not already been fragmented yet >>>=20 >>> DF=3D1 needs to be preserved to avoid interfering with upstream >>> detection of MTUs along a path, but it can be changed from 0 to 1 >>> by a router. However, even ignoring that case, DF=3D1 isn't enough = to >>> know the difference between packets that have already been >>> fragmented by the source. >>=20 >> The RFC 791 DF example (page 25) describes the use case where DF=3D1 >> packets are atomic, and both source and destination are aware. >=20 > The source knows it's setting DF, but the destination has no way of = knowing that. FO re-usage is based on DF=3D1. Coordination is required. > As I noted in a subsequent post, there doesn't appear to be any = prohibition on routers changing DF=3D0 to DF-1, even though it doesn't = seem safe. We discuss DF=3D1. >> When we update RFC 791 for reuse FO, source and destination must make >> sure the bits are recycled. As you pointed out, nodes in the middle >> MUST handle such packets as normal. >=20 > The ipv4-id-update doc does *not* update RFC791 to reuse FO, just to = be > clear. If you want to do that, there's much more work to do - e.g., to = check whether existing routers set DF. FO re-use expects existing routers do not clear DF. This is prohibited, = as you posted today. >>>>> 1 0 0 ATOMIC =09 >>>>> basically this is a lot like saying >>>>> "this is the first and last fragment" >>>>>=20 >>>>> 1 0 nonzero LAST FRAGMENT >>>>> packet has already been fragmented and >>>>> this is the last fragment >>>>>=20 >>>>> 1 1 0 FIRST FRAGMENT >>>>> packet has already been fragmented, and this is the >>>>> first fragment and NOT the last (other fragments >>>>> with higher offsets are expected) >>>>>=20 >>>>> 1 1 nonzero MIDDLE FRAGMENT >>>>> packet has already been fragmented, and this is >>>>> not the first fragment, and other fragments are >>>>> expected >>>>=20 >>>> This makes me optimistic: packets with DF=3D1 and FO!=3D0 are valid = and >>>> intermediate nodes MUST NOT drop such packets. >>>=20 >>> Absolutely. They're packets that have already been fragmented, e.g., = by the source. That also means you can't use the FO field, though. >>=20 >> FO can be reused, if both source and destination choose to do so. >=20 > There are two possibilities: >=20 > - a source NEVER sets DF=3D0 >=20 > - a source sets DF=3D0 and no routers on the path ever set it The conditions are not written down yet. The basics are DF=3D1 and = source and destination do cooperate. Usage is for specific flows. > ipv4-id-update doesn't prohibit either case per se, and the receiver = cannot know either case just from the packets it sees The receiver knows, based on cooperation. > Even if we describe how routers setting DF is dangerous, we can't know = when it's happening. >=20 >>>> When DF=3D1, MF is unused also, so there are 14 bits waiting to be = recycled. >>>=20 >>> No; see above. These are valid cases of source fragmentation. >>=20 >> If hosts follow RFC 791. >=20 > Sure; we're surely not talking about violations of spec. There's no = point in discussing that case further. >=20 >>>>> Note that thus: >>>>>=20 >>>>> ATOMIC packets are *defined* by having all the FO bits as zero. >>>>>=20 >>>>>> What comes up in my mind: can we recycle the 13 fragment offset = bits? >>>>>> Instead of ID field? At least it may be a well defined starting = point. >>>>>=20 >>>>> When the bits aren't zero, an otherwise ATOMIC packet is really a = last fragment. >>>>>=20 >>>>> So if you try to use those bits, all you will accomplish is = flooding the reassembly cache. >>>>=20 >>>> No. RFC 791 compliant nodes receiving such packets SHOULD drop = these. >>>=20 >>> If you do, you're disabling source fragmentation. RFC 791 definitely = does not prohibit that. >>=20 >> Nor does describe it. >=20 > There are two behaviors not explicitly described by RFC791: > A- valid uses of source fragmentation with DF=3D1 > B- dropping source fragmented packets where DF=3D1, solely for that = reason >=20 > The example reassembly algorithm in sec 3.2 does not examine the DF = bit, which permits case A. >=20 > However, case B is prohibited by RFC1191, since it would disable all = of source fragmentation. OK. We don't need to discuss fragmentation and PMTU. >> This brings us to recycle, or not. I don't see any technical = hindrance anymore. >=20 > There are at least three problems: >=20 > 1) dropping fragments where DF=3D1 isn't required by any RFC OK. > 2) dropping fragments where DF=3D1 would break current standards, = e.g., PMTUD RFC1191 (draft standard) OK. > 3) dropping fragments where DF=3D1 for IPv4 would prohibit the = defining case for fragmentation in IPv6 (which explicitly describes its = use of fragmentation in terms of "DF=3D1 always set, source permitted") OK. > Finally, I'd wager that the *bulk* of current fragments have DF=3D1. I did't see one yet. And if such packets fly around, nothing breaks. It = just makes clear that not all bits can be recycled. Teco From Fred.L.Templin@boeing.com Fri Apr 1 05:33:13 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5EA3A6806 for ; Fri, 1 Apr 2011 05:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWs0N8VeSrw2 for ; Fri, 1 Apr 2011 05:33:10 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 846443A6886 for ; Fri, 1 Apr 2011 05:29:55 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p31CVYSu019340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Apr 2011 05:31:34 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p31CVX8t029049; Fri, 1 Apr 2011 05:31:34 -0700 (PDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p31CVX2Q029035 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 1 Apr 2011 05:31:33 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Fri, 1 Apr 2011 05:31:33 -0700 From: "Templin, Fred L" To: Teco Boot , Joe Touch Date: Fri, 1 Apr 2011 05:31:31 -0700 Thread-Topic: [Int-area] Recycle IPv4 bits Thread-Index: AcvwZsHobJLg9OtmQQ6HkTQ/2s1EfQAAEcWw Message-ID: References: <4D94BDA0.60104 02@isi.edu><4D9597D5.90806 04@isi.edu><4D95AA24.2010502@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> In-Reply-To: <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> 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: "int-area@ietf.org" Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 12:33:13 -0000 Teco, I know of at least one RFC that seems to suggest that it is OK to fragment IPv4 packets regardless of the DF setting. I have not personally collected any data, but I have seen suggestions that there is currently-deployed networking gear that ignores the DF setting. As Joe knows, I have tried for many years and have come to the conclusion that trying to code the IP header is a dubious enterprise. Perhaps it can be done to a certain extent within a bounded and controlled network, but not so much out in the wild of the public Internet. Fred =20 > -----Original Message----- > From: int-area-bounces@ietf.org=20 > [mailto:int-area-bounces@ietf.org] On Behalf Of Teco Boot > Sent: Friday, April 01, 2011 5:06 AM > To: Joe Touch > Cc: int-area@ietf.org > Subject: Re: [Int-area] Recycle IPv4 bits >=20 > Op 1 apr 2011, om 12:34 heeft Joe Touch het volgende geschreven: >=20 > > On 4/1/2011 2:58 AM, Teco Boot wrote: > > ... > >>> DF=3D1 means "don't fragment what I just sent". > >>>=20 > >>> The source can fragment, though, and THEN set DF on the fragments. > >>> That is exactly how an IPv4 host most closely behaves like an IPv6 > >>> host - the latter permitting only source fragmentation. > >>>=20 > >>> This is why ipv4-id-update doesn't use the term "DF=3D1"; it uses > >>> the term ATOMIC because atomic means: > >>> - must not fragment from this point forward > >>> AND > >>> - has not already been fragmented yet > >>>=20 > >>> DF=3D1 needs to be preserved to avoid interfering with upstream > >>> detection of MTUs along a path, but it can be changed from 0 to 1 > >>> by a router. However, even ignoring that case, DF=3D1 isn't=20 > enough to > >>> know the difference between packets that have already been > >>> fragmented by the source. > >>=20 > >> The RFC 791 DF example (page 25) describes the use case where DF=3D1 > >> packets are atomic, and both source and destination are aware. > >=20 > > The source knows it's setting DF, but the destination has=20 > no way of knowing that. >=20 > FO re-usage is based on DF=3D1. Coordination is required. >=20 > > As I noted in a subsequent post, there doesn't appear to be=20 > any prohibition on routers changing DF=3D0 to DF-1, even though=20 > it doesn't seem safe. >=20 > We discuss DF=3D1. >=20 > >> When we update RFC 791 for reuse FO, source and=20 > destination must make > >> sure the bits are recycled. As you pointed out, nodes in the middle > >> MUST handle such packets as normal. > >=20 > > The ipv4-id-update doc does *not* update RFC791 to reuse=20 > FO, just to be > > clear. If you want to do that, there's much more work to do=20 > - e.g., to check whether existing routers set DF. >=20 > FO re-use expects existing routers do not clear DF. This is=20 > prohibited, as you posted today. >=20 > >>>>> 1 0 0 ATOMIC =09 > >>>>> basically this is a lot like saying > >>>>> "this is the first and last fragment" > >>>>>=20 > >>>>> 1 0 nonzero LAST FRAGMENT > >>>>> packet has already been fragmented and > >>>>> this is the last fragment > >>>>>=20 > >>>>> 1 1 0 FIRST FRAGMENT > >>>>> packet has already been fragmented, and=20 > this is the > >>>>> first fragment and NOT the last (other fragments > >>>>> with higher offsets are expected) > >>>>>=20 > >>>>> 1 1 nonzero MIDDLE FRAGMENT > >>>>> packet has already been fragmented, and this is > >>>>> not the first fragment, and other fragments are > >>>>> expected > >>>>=20 > >>>> This makes me optimistic: packets with DF=3D1 and FO!=3D0=20 > are valid and > >>>> intermediate nodes MUST NOT drop such packets. > >>>=20 > >>> Absolutely. They're packets that have already been=20 > fragmented, e.g., by the source. That also means you can't=20 > use the FO field, though. > >>=20 > >> FO can be reused, if both source and destination choose to do so. > >=20 > > There are two possibilities: > >=20 > > - a source NEVER sets DF=3D0 > >=20 > > - a source sets DF=3D0 and no routers on the path ever set it >=20 > The conditions are not written down yet. The basics are DF=3D1=20 > and source and destination do cooperate. Usage is for specific flows. >=20 > > ipv4-id-update doesn't prohibit either case per se, and the=20 > receiver cannot know either case just from the packets it sees >=20 > The receiver knows, based on cooperation. >=20 > > Even if we describe how routers setting DF is dangerous, we=20 > can't know when it's happening. > >=20 > >>>> When DF=3D1, MF is unused also, so there are 14 bits=20 > waiting to be recycled. > >>>=20 > >>> No; see above. These are valid cases of source fragmentation. > >>=20 > >> If hosts follow RFC 791. > >=20 > > Sure; we're surely not talking about violations of spec.=20 > There's no point in discussing that case further. > >=20 > >>>>> Note that thus: > >>>>>=20 > >>>>> ATOMIC packets are *defined* by having all the=20 > FO bits as zero. > >>>>>=20 > >>>>>> What comes up in my mind: can we recycle the 13=20 > fragment offset bits? > >>>>>> Instead of ID field? At least it may be a well defined=20 > starting point. > >>>>>=20 > >>>>> When the bits aren't zero, an otherwise ATOMIC packet=20 > is really a last fragment. > >>>>>=20 > >>>>> So if you try to use those bits, all you will=20 > accomplish is flooding the reassembly cache. > >>>>=20 > >>>> No. RFC 791 compliant nodes receiving such packets=20 > SHOULD drop these. > >>>=20 > >>> If you do, you're disabling source fragmentation. RFC 791=20 > definitely does not prohibit that. > >>=20 > >> Nor does describe it. > >=20 > > There are two behaviors not explicitly described by RFC791: > > A- valid uses of source fragmentation with DF=3D1 > > B- dropping source fragmented packets where DF=3D1, solely=20 > for that reason > >=20 > > The example reassembly algorithm in sec 3.2 does not=20 > examine the DF bit, which permits case A. > >=20 > > However, case B is prohibited by RFC1191, since it would=20 > disable all of source fragmentation. >=20 > OK. We don't need to discuss fragmentation and PMTU. >=20 > >> This brings us to recycle, or not. I don't see any=20 > technical hindrance anymore. > >=20 > > There are at least three problems: > >=20 > > 1) dropping fragments where DF=3D1 isn't required by any RFC > OK. >=20 > > 2) dropping fragments where DF=3D1 would break current=20 > standards, e.g., PMTUD RFC1191 (draft standard) > OK. >=20 > > 3) dropping fragments where DF=3D1 for IPv4 would prohibit=20 > the defining case for fragmentation in IPv6 (which explicitly=20 > describes its use of fragmentation in terms of "DF=3D1 always=20 > set, source permitted") > OK. >=20 > > Finally, I'd wager that the *bulk* of current fragments have DF=3D1. >=20 > I did't see one yet. And if such packets fly around, nothing=20 > breaks. It just makes clear that not all bits can be recycled. >=20 > Teco >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > = From teco@inf-net.nl Fri Apr 1 05:54:27 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CFE33A686A for ; Fri, 1 Apr 2011 05:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOr7Faizss2z for ; Fri, 1 Apr 2011 05:54:25 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3924A3A681F for ; Fri, 1 Apr 2011 05:54:24 -0700 (PDT) Received: by bwz13 with SMTP id 13so2714783bwz.31 for ; Fri, 01 Apr 2011 05:56:04 -0700 (PDT) Received: by 10.204.164.2 with SMTP id c2mr3695146bky.85.1301662563682; Fri, 01 Apr 2011 05:56:03 -0700 (PDT) Received: from dhcp-14b8.meeting.ietf.org (dhcp-14b8.meeting.ietf.org [130.129.20.184]) by mx.google.com with ESMTPS id v21sm1387794bkt.11.2011.04.01.05.56.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 05:56:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Fri, 1 Apr 2011 14:56:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7281EED3-361F-4496-9FF4-44CDACE1AA0A@inf-net.nl> References: <4D94BDA0.60104 02@isi.edu><4D9597D5.90806 04@isi.edu><4D95AA24.2010502@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) Cc: "int-area@ietf.org" Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 12:54:27 -0000 Fred, It is april 1st. Has the RFC to do with such date? And again, since when do we respect bugs? Packets in the wild _can_ be manipulated. Especially middleboxes that = provide protection for payload sometimes illegally change headers. Teco Op 1 apr 2011, om 14:31 heeft Templin, Fred L het volgende geschreven: > Teco, >=20 > I know of at least one RFC that seems to suggest that it > is OK to fragment IPv4 packets regardless of the DF setting. > I have not personally collected any data, but I have seen > suggestions that there is currently-deployed networking > gear that ignores the DF setting. >=20 > As Joe knows, I have tried for many years and have come > to the conclusion that trying to code the IP header is a > dubious enterprise. Perhaps it can be done to a certain > extent within a bounded and controlled network, but not > so much out in the wild of the public Internet. >=20 > Fred =20 >=20 >> -----Original Message----- >> From: int-area-bounces@ietf.org=20 >> [mailto:int-area-bounces@ietf.org] On Behalf Of Teco Boot >> Sent: Friday, April 01, 2011 5:06 AM >> To: Joe Touch >> Cc: int-area@ietf.org >> Subject: Re: [Int-area] Recycle IPv4 bits >>=20 >> Op 1 apr 2011, om 12:34 heeft Joe Touch het volgende geschreven: >>=20 >>> On 4/1/2011 2:58 AM, Teco Boot wrote: >>> ... >>>>> DF=3D1 means "don't fragment what I just sent". >>>>>=20 >>>>> The source can fragment, though, and THEN set DF on the fragments. >>>>> That is exactly how an IPv4 host most closely behaves like an IPv6 >>>>> host - the latter permitting only source fragmentation. >>>>>=20 >>>>> This is why ipv4-id-update doesn't use the term "DF=3D1"; it uses >>>>> the term ATOMIC because atomic means: >>>>> - must not fragment from this point forward >>>>> AND >>>>> - has not already been fragmented yet >>>>>=20 >>>>> DF=3D1 needs to be preserved to avoid interfering with upstream >>>>> detection of MTUs along a path, but it can be changed from 0 to 1 >>>>> by a router. However, even ignoring that case, DF=3D1 isn't=20 >> enough to >>>>> know the difference between packets that have already been >>>>> fragmented by the source. >>>>=20 >>>> The RFC 791 DF example (page 25) describes the use case where DF=3D1 >>>> packets are atomic, and both source and destination are aware. >>>=20 >>> The source knows it's setting DF, but the destination has=20 >> no way of knowing that. >>=20 >> FO re-usage is based on DF=3D1. Coordination is required. >>=20 >>> As I noted in a subsequent post, there doesn't appear to be=20 >> any prohibition on routers changing DF=3D0 to DF-1, even though=20 >> it doesn't seem safe. >>=20 >> We discuss DF=3D1. >>=20 >>>> When we update RFC 791 for reuse FO, source and=20 >> destination must make >>>> sure the bits are recycled. As you pointed out, nodes in the middle >>>> MUST handle such packets as normal. >>>=20 >>> The ipv4-id-update doc does *not* update RFC791 to reuse=20 >> FO, just to be >>> clear. If you want to do that, there's much more work to do=20 >> - e.g., to check whether existing routers set DF. >>=20 >> FO re-use expects existing routers do not clear DF. This is=20 >> prohibited, as you posted today. >>=20 >>>>>>> 1 0 0 ATOMIC =09 >>>>>>> basically this is a lot like saying >>>>>>> "this is the first and last fragment" >>>>>>>=20 >>>>>>> 1 0 nonzero LAST FRAGMENT >>>>>>> packet has already been fragmented and >>>>>>> this is the last fragment >>>>>>>=20 >>>>>>> 1 1 0 FIRST FRAGMENT >>>>>>> packet has already been fragmented, and=20 >> this is the >>>>>>> first fragment and NOT the last (other fragments >>>>>>> with higher offsets are expected) >>>>>>>=20 >>>>>>> 1 1 nonzero MIDDLE FRAGMENT >>>>>>> packet has already been fragmented, and this is >>>>>>> not the first fragment, and other fragments are >>>>>>> expected >>>>>>=20 >>>>>> This makes me optimistic: packets with DF=3D1 and FO!=3D0=20 >> are valid and >>>>>> intermediate nodes MUST NOT drop such packets. >>>>>=20 >>>>> Absolutely. They're packets that have already been=20 >> fragmented, e.g., by the source. That also means you can't=20 >> use the FO field, though. >>>>=20 >>>> FO can be reused, if both source and destination choose to do so. >>>=20 >>> There are two possibilities: >>>=20 >>> - a source NEVER sets DF=3D0 >>>=20 >>> - a source sets DF=3D0 and no routers on the path ever set it >>=20 >> The conditions are not written down yet. The basics are DF=3D1=20 >> and source and destination do cooperate. Usage is for specific flows. >>=20 >>> ipv4-id-update doesn't prohibit either case per se, and the=20 >> receiver cannot know either case just from the packets it sees >>=20 >> The receiver knows, based on cooperation. >>=20 >>> Even if we describe how routers setting DF is dangerous, we=20 >> can't know when it's happening. >>>=20 >>>>>> When DF=3D1, MF is unused also, so there are 14 bits=20 >> waiting to be recycled. >>>>>=20 >>>>> No; see above. These are valid cases of source fragmentation. >>>>=20 >>>> If hosts follow RFC 791. >>>=20 >>> Sure; we're surely not talking about violations of spec.=20 >> There's no point in discussing that case further. >>>=20 >>>>>>> Note that thus: >>>>>>>=20 >>>>>>> ATOMIC packets are *defined* by having all the=20 >> FO bits as zero. >>>>>>>=20 >>>>>>>> What comes up in my mind: can we recycle the 13=20 >> fragment offset bits? >>>>>>>> Instead of ID field? At least it may be a well defined=20 >> starting point. >>>>>>>=20 >>>>>>> When the bits aren't zero, an otherwise ATOMIC packet=20 >> is really a last fragment. >>>>>>>=20 >>>>>>> So if you try to use those bits, all you will=20 >> accomplish is flooding the reassembly cache. >>>>>>=20 >>>>>> No. RFC 791 compliant nodes receiving such packets=20 >> SHOULD drop these. >>>>>=20 >>>>> If you do, you're disabling source fragmentation. RFC 791=20 >> definitely does not prohibit that. >>>>=20 >>>> Nor does describe it. >>>=20 >>> There are two behaviors not explicitly described by RFC791: >>> A- valid uses of source fragmentation with DF=3D1 >>> B- dropping source fragmented packets where DF=3D1, solely=20 >> for that reason >>>=20 >>> The example reassembly algorithm in sec 3.2 does not=20 >> examine the DF bit, which permits case A. >>>=20 >>> However, case B is prohibited by RFC1191, since it would=20 >> disable all of source fragmentation. >>=20 >> OK. We don't need to discuss fragmentation and PMTU. >>=20 >>>> This brings us to recycle, or not. I don't see any=20 >> technical hindrance anymore. >>>=20 >>> There are at least three problems: >>>=20 >>> 1) dropping fragments where DF=3D1 isn't required by any RFC >> OK. >>=20 >>> 2) dropping fragments where DF=3D1 would break current=20 >> standards, e.g., PMTUD RFC1191 (draft standard) >> OK. >>=20 >>> 3) dropping fragments where DF=3D1 for IPv4 would prohibit=20 >> the defining case for fragmentation in IPv6 (which explicitly=20 >> describes its use of fragmentation in terms of "DF=3D1 always=20 >> set, source permitted") >> OK. >>=20 >>> Finally, I'd wager that the *bulk* of current fragments have DF=3D1. >>=20 >> I did't see one yet. And if such packets fly around, nothing=20 >> breaks. It just makes clear that not all bits can be recycled. >>=20 >> Teco >>=20 >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >>=20 From Fred.L.Templin@boeing.com Fri Apr 1 06:13:23 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959753A684A for ; Fri, 1 Apr 2011 06:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.333 X-Spam-Level: X-Spam-Status: No, score=-6.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYHVLozrXgOs for ; Fri, 1 Apr 2011 06:13:22 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 0D0A53A6767 for ; Fri, 1 Apr 2011 06:13:21 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p31DEtU9007941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Apr 2011 06:14:56 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p31DEtfj024318; Fri, 1 Apr 2011 08:14:55 -0500 (CDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p31DEsfE024302 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 1 Apr 2011 08:14:55 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 1 Apr 2011 06:14:54 -0700 From: "Templin, Fred L" To: Teco Boot Date: Fri, 1 Apr 2011 06:14:51 -0700 Thread-Topic: [Int-area] Recycle IPv4 bits Thread-Index: AcvwbCrLfPrNTWt6QW6jZucHiCM/DwAAdrVw Message-ID: References: <4D94BDA0.60104 02@isi.edu><4D9597D5.9080 6 04@isi.edu><4D95AA24.20105 02@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> <7281EED3-361F-4496-9FF4-44CDACE1AA0A@inf-net.nl> In-Reply-To: <7281EED3-361F-4496-9FF4-44CDACE1AA0A@inf-net.nl> 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: "int-area@ietf.org" Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 13:13:23 -0000 Teco,=20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: Friday, April 01, 2011 5:56 AM > To: Templin, Fred L > Cc: Joe Touch; int-area@ietf.org > Subject: Re: [Int-area] Recycle IPv4 bits >=20 > Fred, >=20 > It is april 1st. Has the RFC to do with such date? > And again, since when do we respect bugs? Not an April Fools RFC, and I'm sure implementatons don't care so much which specs are violated. > Packets in the wild _can_ be manipulated. Especially=20 > middleboxes that provide protection for payload sometimes=20 > illegally change headers. Sure, but wouldn't that invalidate your desire to code something in the header at the source that you could count on still being there in the same form when the packet reaches the destination? Thanks - Fred > Teco >=20 > Op 1 apr 2011, om 14:31 heeft Templin, Fred L het volgende geschreven: >=20 > > Teco, > >=20 > > I know of at least one RFC that seems to suggest that it > > is OK to fragment IPv4 packets regardless of the DF setting. > > I have not personally collected any data, but I have seen > > suggestions that there is currently-deployed networking > > gear that ignores the DF setting. > >=20 > > As Joe knows, I have tried for many years and have come > > to the conclusion that trying to code the IP header is a > > dubious enterprise. Perhaps it can be done to a certain > > extent within a bounded and controlled network, but not > > so much out in the wild of the public Internet. > >=20 > > Fred =20 > >=20 > >> -----Original Message----- > >> From: int-area-bounces@ietf.org=20 > >> [mailto:int-area-bounces@ietf.org] On Behalf Of Teco Boot > >> Sent: Friday, April 01, 2011 5:06 AM > >> To: Joe Touch > >> Cc: int-area@ietf.org > >> Subject: Re: [Int-area] Recycle IPv4 bits > >>=20 > >> Op 1 apr 2011, om 12:34 heeft Joe Touch het volgende geschreven: > >>=20 > >>> On 4/1/2011 2:58 AM, Teco Boot wrote: > >>> ... > >>>>> DF=3D1 means "don't fragment what I just sent". > >>>>>=20 > >>>>> The source can fragment, though, and THEN set DF on the=20 > fragments. > >>>>> That is exactly how an IPv4 host most closely behaves=20 > like an IPv6 > >>>>> host - the latter permitting only source fragmentation. > >>>>>=20 > >>>>> This is why ipv4-id-update doesn't use the term "DF=3D1"; it uses > >>>>> the term ATOMIC because atomic means: > >>>>> - must not fragment from this point forward > >>>>> AND > >>>>> - has not already been fragmented yet > >>>>>=20 > >>>>> DF=3D1 needs to be preserved to avoid interfering with upstream > >>>>> detection of MTUs along a path, but it can be changed=20 > from 0 to 1 > >>>>> by a router. However, even ignoring that case, DF=3D1 isn't=20 > >> enough to > >>>>> know the difference between packets that have already been > >>>>> fragmented by the source. > >>>>=20 > >>>> The RFC 791 DF example (page 25) describes the use case=20 > where DF=3D1 > >>>> packets are atomic, and both source and destination are aware. > >>>=20 > >>> The source knows it's setting DF, but the destination has=20 > >> no way of knowing that. > >>=20 > >> FO re-usage is based on DF=3D1. Coordination is required. > >>=20 > >>> As I noted in a subsequent post, there doesn't appear to be=20 > >> any prohibition on routers changing DF=3D0 to DF-1, even though=20 > >> it doesn't seem safe. > >>=20 > >> We discuss DF=3D1. > >>=20 > >>>> When we update RFC 791 for reuse FO, source and=20 > >> destination must make > >>>> sure the bits are recycled. As you pointed out, nodes in=20 > the middle > >>>> MUST handle such packets as normal. > >>>=20 > >>> The ipv4-id-update doc does *not* update RFC791 to reuse=20 > >> FO, just to be > >>> clear. If you want to do that, there's much more work to do=20 > >> - e.g., to check whether existing routers set DF. > >>=20 > >> FO re-use expects existing routers do not clear DF. This is=20 > >> prohibited, as you posted today. > >>=20 > >>>>>>> 1 0 0 ATOMIC =09 > >>>>>>> basically this is a lot like saying > >>>>>>> "this is the first and last fragment" > >>>>>>>=20 > >>>>>>> 1 0 nonzero LAST FRAGMENT > >>>>>>> packet has already been fragmented and > >>>>>>> this is the last fragment > >>>>>>>=20 > >>>>>>> 1 1 0 FIRST FRAGMENT > >>>>>>> packet has already been fragmented, and=20 > >> this is the > >>>>>>> first fragment and NOT the last (other fragments > >>>>>>> with higher offsets are expected) > >>>>>>>=20 > >>>>>>> 1 1 nonzero MIDDLE FRAGMENT > >>>>>>> packet has already been fragmented, and this is > >>>>>>> not the first fragment, and other fragments are > >>>>>>> expected > >>>>>>=20 > >>>>>> This makes me optimistic: packets with DF=3D1 and FO!=3D0=20 > >> are valid and > >>>>>> intermediate nodes MUST NOT drop such packets. > >>>>>=20 > >>>>> Absolutely. They're packets that have already been=20 > >> fragmented, e.g., by the source. That also means you can't=20 > >> use the FO field, though. > >>>>=20 > >>>> FO can be reused, if both source and destination choose to do so. > >>>=20 > >>> There are two possibilities: > >>>=20 > >>> - a source NEVER sets DF=3D0 > >>>=20 > >>> - a source sets DF=3D0 and no routers on the path ever set it > >>=20 > >> The conditions are not written down yet. The basics are DF=3D1=20 > >> and source and destination do cooperate. Usage is for=20 > specific flows. > >>=20 > >>> ipv4-id-update doesn't prohibit either case per se, and the=20 > >> receiver cannot know either case just from the packets it sees > >>=20 > >> The receiver knows, based on cooperation. > >>=20 > >>> Even if we describe how routers setting DF is dangerous, we=20 > >> can't know when it's happening. > >>>=20 > >>>>>> When DF=3D1, MF is unused also, so there are 14 bits=20 > >> waiting to be recycled. > >>>>>=20 > >>>>> No; see above. These are valid cases of source fragmentation. > >>>>=20 > >>>> If hosts follow RFC 791. > >>>=20 > >>> Sure; we're surely not talking about violations of spec.=20 > >> There's no point in discussing that case further. > >>>=20 > >>>>>>> Note that thus: > >>>>>>>=20 > >>>>>>> ATOMIC packets are *defined* by having all the=20 > >> FO bits as zero. > >>>>>>>=20 > >>>>>>>> What comes up in my mind: can we recycle the 13=20 > >> fragment offset bits? > >>>>>>>> Instead of ID field? At least it may be a well defined=20 > >> starting point. > >>>>>>>=20 > >>>>>>> When the bits aren't zero, an otherwise ATOMIC packet=20 > >> is really a last fragment. > >>>>>>>=20 > >>>>>>> So if you try to use those bits, all you will=20 > >> accomplish is flooding the reassembly cache. > >>>>>>=20 > >>>>>> No. RFC 791 compliant nodes receiving such packets=20 > >> SHOULD drop these. > >>>>>=20 > >>>>> If you do, you're disabling source fragmentation. RFC 791=20 > >> definitely does not prohibit that. > >>>>=20 > >>>> Nor does describe it. > >>>=20 > >>> There are two behaviors not explicitly described by RFC791: > >>> A- valid uses of source fragmentation with DF=3D1 > >>> B- dropping source fragmented packets where DF=3D1, solely=20 > >> for that reason > >>>=20 > >>> The example reassembly algorithm in sec 3.2 does not=20 > >> examine the DF bit, which permits case A. > >>>=20 > >>> However, case B is prohibited by RFC1191, since it would=20 > >> disable all of source fragmentation. > >>=20 > >> OK. We don't need to discuss fragmentation and PMTU. > >>=20 > >>>> This brings us to recycle, or not. I don't see any=20 > >> technical hindrance anymore. > >>>=20 > >>> There are at least three problems: > >>>=20 > >>> 1) dropping fragments where DF=3D1 isn't required by any RFC > >> OK. > >>=20 > >>> 2) dropping fragments where DF=3D1 would break current=20 > >> standards, e.g., PMTUD RFC1191 (draft standard) > >> OK. > >>=20 > >>> 3) dropping fragments where DF=3D1 for IPv4 would prohibit=20 > >> the defining case for fragmentation in IPv6 (which explicitly=20 > >> describes its use of fragmentation in terms of "DF=3D1 always=20 > >> set, source permitted") > >> OK. > >>=20 > >>> Finally, I'd wager that the *bulk* of current fragments have DF=3D1. > >>=20 > >> I did't see one yet. And if such packets fly around, nothing=20 > >> breaks. It just makes clear that not all bits can be recycled. > >>=20 > >> Teco > >>=20 > >> _______________________________________________ > >> Int-area mailing list > >> Int-area@ietf.org > >> https://www.ietf.org/mailman/listinfo/int-area > >>=20 >=20 > = From teco@inf-net.nl Fri Apr 1 06:38:55 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FCA23A67FA for ; Fri, 1 Apr 2011 06:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F29eHGvVn4Qu for ; Fri, 1 Apr 2011 06:38:54 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3A9AA3A6845 for ; Fri, 1 Apr 2011 06:38:53 -0700 (PDT) Received: by bwz13 with SMTP id 13so2749253bwz.31 for ; Fri, 01 Apr 2011 06:40:34 -0700 (PDT) Received: by 10.204.26.132 with SMTP id e4mr3698176bkc.142.1301665233880; Fri, 01 Apr 2011 06:40:33 -0700 (PDT) Received: from dhcp-14b8.meeting.ietf.org (dhcp-14b8.meeting.ietf.org [130.129.20.184]) by mx.google.com with ESMTPS id q24sm1410578bks.21.2011.04.01.06.40.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 06:40:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Fri, 1 Apr 2011 15:40:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D94BDA0.60104 02@isi.edu><4D9597D5.9080 6 04@isi.edu><4D95AA24.20105 02@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> <7281EED3-361F-4496-9FF4-44CDACE1AA0A@inf-net.nl> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) Cc: "int-area@ietf.org" Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 13:38:55 -0000 Op 1 apr 2011, om 15:14 heeft Templin, Fred L het volgende geschreven: =20 >> It is april 1st. Has the RFC to do with such date? >> And again, since when do we respect bugs? >=20 > Not an April Fools RFC, and I'm sure implementatons > don't care so much which specs are violated. Please provide a pointer. >> Packets in the wild _can_ be manipulated. Especially=20 >> middleboxes that provide protection for payload sometimes=20 >> illegally change headers. >=20 > Sure, but wouldn't that invalidate your desire to code > something in the header at the source that you could > count on still being there in the same form when the > packet reaches the destination? The only guarantee to prevent malformed packets at destination is to = keep them at the source. Teco From touch@isi.edu Fri Apr 1 07:06:14 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F16F3A6835 for ; Fri, 1 Apr 2011 07:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.471 X-Spam-Level: X-Spam-Status: No, score=-103.471 tagged_above=-999 required=5 tests=[AWL=-0.872, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6AmdFc+eAK3 for ; Fri, 1 Apr 2011 07:06:13 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C13323A67FC for ; Fri, 1 Apr 2011 07:06:13 -0700 (PDT) Received: from [130.129.67.235] (dhcp-43eb.meeting.ietf.org [130.129.67.235]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p31E6hh3028861 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2011 07:07:00 -0700 (PDT) Message-ID: <4D95DBF0.4040503@isi.edu> Date: Fri, 01 Apr 2011 07:06:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Templin, Fred L" References: <4D94BDA0.60104 02@isi.edu><4D9597D5.90806 04@isi.edu><4D95AA24.2010502@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> 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] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 14:06:14 -0000 On 4/1/2011 5:31 AM, Templin, Fred L wrote: > Teco, > > I know of at least one RFC that seems to suggest that it > is OK to fragment IPv4 packets regardless of the DF setting. Hi, Fred, Can you forward that so I can cite it specifically? > I have not personally collected any data, but I have seen > suggestions that there is currently-deployed networking > gear that ignores the DF setting. I hope we all know that this is the case ;-) It's also the case that existing sources reuse the ID, either when sending more than 6.4 Mbps on a connection - or, in some cases, for all packets. Ignoring the DF bit ends up creating more errors, which either behaves like a flakey link (if dropped) or a flakey OS. I wouldn't be surprised if some uses that result in phones or PCs acting odd or rebooting is caused by this, FWIW. This is why the ID tries not to *rely* on any proposed changes; it just recognizes existing behavior. Joe From touch@isi.edu Fri Apr 1 07:09:41 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B99B3A6828 for ; Fri, 1 Apr 2011 07:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.442 X-Spam-Level: X-Spam-Status: No, score=-103.442 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4Op32uMpj5J for ; Fri, 1 Apr 2011 07:09:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1D12A3A681C for ; Fri, 1 Apr 2011 07:09:41 -0700 (PDT) Received: from [130.129.67.235] (dhcp-43eb.meeting.ietf.org [130.129.67.235]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p31EAJjZ029716 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2011 07:10:38 -0700 (PDT) Message-ID: <4D95DCC6.7030603@isi.edu> Date: Fri, 01 Apr 2011 07:10:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Teco Boot References: <4D94BDA0.60104 02@isi.edu><4D9597D5.9080 6 04@isi.edu><4D95AA24.20105 02@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> <7281EED3-361F-4496-9FF4-44CDACE1AA0A@inf-net.nl> 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: "Templin, Fred L" , "int-area@ietf.org" Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 14:09:41 -0000 On 4/1/2011 6:40 AM, Teco Boot wrote: ... > The only guarantee to prevent malformed packets at destination is to keep them at the source. The whole point of a protocol is to provide some level of guarantee. Otherwise, we would be able to just send raw data over the wire (e.g., as we do inside a host, in some cases). Joe From touch@isi.edu Fri Apr 1 07:10:42 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F5C63A6828 for ; Fri, 1 Apr 2011 07:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.415 X-Spam-Level: X-Spam-Status: No, score=-103.415 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdxEVk5HpysZ for ; Fri, 1 Apr 2011 07:10:40 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BACE03A6862 for ; Fri, 1 Apr 2011 07:10:40 -0700 (PDT) Received: from [130.129.67.235] (dhcp-43eb.meeting.ietf.org [130.129.67.235]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p31EBMNv000022 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2011 07:11:42 -0700 (PDT) Message-ID: <4D95DD08.3010500@isi.edu> Date: Fri, 01 Apr 2011 07:11:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Teco Boot References: <4D94BDA0.6010402@isi.edu> <4D9597D5.9080604@isi.edu> <4D95AA24.2010502@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> In-Reply-To: <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> 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] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 14:10:42 -0000 Hi, Teco, On 4/1/2011 5:06 AM, Teco Boot wrote: ... >>> The RFC 791 DF example (page 25) describes the use case where DF=1 >>> packets are atomic, and both source and destination are aware. >> >> The source knows it's setting DF, but the destination has no way of knowing that. > > FO re-usage is based on DF=1. Coordination is required. What protocol provides this coordination? >> The ipv4-id-update doc does *not* update RFC791 to reuse FO, just to be >> clear. If you want to do that, there's much more work to do - e.g., to check whether existing routers set DF. > > FO re-use expects existing routers do not clear DF. This is prohibited, as you posted today. FO reuse expects that routers do not clear the DF (which is prohibited), but also expects that routers do not SET the DF (which is not currently prohibited). The second case is the problem. I agree that we now should explain the dangers of setting the DF anywhere except the source, but we cannot simply assume that this is always the case. ... >> There are two behaviors not explicitly described by RFC791: >> A- valid uses of source fragmentation with DF=1 >> B- dropping source fragmented packets where DF=1, solely for that reason >> >> The example reassembly algorithm in sec 3.2 does not examine the DF bit, which permits case A. >> >> However, case B is prohibited by RFC1191, since it would disable all of source fragmentation. > > OK. We don't need to discuss fragmentation and PMTU. If we're talking about fragmentation, we really do. That's the common use for setting DF=1. Joe From jnc@mercury.lcs.mit.edu Fri Apr 1 07:57:43 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEB43A6889 for ; Fri, 1 Apr 2011 07:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRIXJPB-k2+t for ; Fri, 1 Apr 2011 07:57:42 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 995053A6878 for ; Fri, 1 Apr 2011 07:57:42 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7CFF418C144; Fri, 1 Apr 2011 10:59:22 -0400 (EDT) To: int-area@ietf.org Message-Id: <20110401145922.7CFF418C144@mercury.lcs.mit.edu> Date: Fri, 1 Apr 2011 10:59:22 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 14:57:43 -0000 > From: Joe Touch > The source can fragment, though, and THEN set DF on the fragments. > ... > it can be changed from 0 to 1 by a router. FWIW, I don't believe either of these cases was considered when we were finalizing the IPv4 spec. If you read RFC-791, it's clear from the discussion there of DF that it was intended to prevent fragmentation of complete datagrams (e.g. for interacting with a host which could not do reassembly, perhaps because it was a ROM bootloader with limited code space), not further fragmentation of fragments. Before this discussion, I would have considered a packet with DF=1 and Offset!=0 to be in error. Which doesn't mean we _shouldn't_ allow them, but I'm pretty sure it was never contemplated that it could/would be done. Noel From teco@inf-net.nl Sun Apr 3 23:27:27 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E733A6970 for ; Sun, 3 Apr 2011 23:27:27 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv3l-xSwR2QH for ; Sun, 3 Apr 2011 23:27:26 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id AFBA13A67F7 for ; Sun, 3 Apr 2011 23:27:25 -0700 (PDT) Received: by bwz13 with SMTP id 13so4140587bwz.31 for ; Sun, 03 Apr 2011 23:29:06 -0700 (PDT) Received: by 10.204.29.21 with SMTP id o21mr5799753bkc.97.1301898546395; Sun, 03 Apr 2011 23:29:06 -0700 (PDT) Received: from [10.87.13.181] ([88.128.92.208]) by mx.google.com with ESMTPS id c11sm2842078bkc.2.2011.04.03.23.29.01 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 23:29:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Mon, 4 Apr 2011 08:29:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C3B397F-1C21-432D-9353-21FA97413917@inf-net.nl> References: <4D94BDA0.60104 02@isi.edu><4D9597D5.9080 6 04@isi.edu><4D95AA24.20105 02@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> <7281EED3-361F-4496-9FF4-44CDACE1AA0A@inf-net.nl> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) Cc: int-area@ietf.org Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 06:27:28 -0000 Fred, =20 Op 1 apr 2011, om 15:52 heeft Templin, Fred L het volgende geschreven: > Teco, >=20 > I am looking at RFC3931, Section 4.1.4. All it says is > that the LCCE may fragment IPv4 packets I don't read RFC3931 like this. It says ideal solutions work with=20 RFC1191. And RFC2661 is normative reference, which point to RFC791. > - it does not > say that the LCCE must honor the DF bit. It doesn't say the LCCE must not do illegal operations. I do agree=20 that it were better to mention a DF=3D0 condition. Make errata? Old: An LCCE MAY fragment a packet before encapsulating it in L2TP. For example, if an IPv4 packet arrives at an LCCE from a Remote System that, after encapsulation with its associated framing, L2TP, and IP, does not fit in the available path MTU towards its LCCE peer, the local LCCE may perform IPv4 fragmentation on the packet before tunnel encapsulation.=20 New: An LCCE MAY fragment a packet before encapsulating it in L2TP. For example, if an IPv4 packet with DF=3D1 arrives at an LCCE from a = Remote System that, after encapsulation with its associated framing, L2TP, and IP, does not fit in the available path MTU towards its LCCE peer, the local LCCE may perform IPv4 fragmentation on the packet before tunnel encapsulation.=20 Thanks, Teco >=20 > Fred=20 >=20 >> -----Original Message----- >> From: Teco Boot [mailto:teco@inf-net.nl]=20 >> Sent: Friday, April 01, 2011 6:41 AM >> To: Templin, Fred L >> Cc: Joe Touch; int-area@ietf.org >> Subject: Re: [Int-area] Recycle IPv4 bits >>=20 >> Op 1 apr 2011, om 15:14 heeft Templin, Fred L het volgende = geschreven: >>=20 >>>> It is april 1st. Has the RFC to do with such date? >>>> And again, since when do we respect bugs? >>>=20 >>> Not an April Fools RFC, and I'm sure implementatons >>> don't care so much which specs are violated. >>=20 >> Please provide a pointer. >>=20 >>>> Packets in the wild _can_ be manipulated. Especially=20 >>>> middleboxes that provide protection for payload sometimes=20 >>>> illegally change headers. >>>=20 >>> Sure, but wouldn't that invalidate your desire to code >>> something in the header at the source that you could >>> count on still being there in the same form when the >>> packet reaches the destination? >>=20 >> The only guarantee to prevent malformed packets at=20 >> destination is to keep them at the source. >>=20 >> Teco >>=20 >>=20 >>=20 From teco@inf-net.nl Sun Apr 3 23:46:55 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203AD3A69D9 for ; Sun, 3 Apr 2011 23:46:55 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFdi3GMsdiTs for ; Sun, 3 Apr 2011 23:46:54 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 2BF013A693C for ; Sun, 3 Apr 2011 23:46:53 -0700 (PDT) Received: by bwz13 with SMTP id 13so4149475bwz.31 for ; Sun, 03 Apr 2011 23:48:35 -0700 (PDT) Received: by 10.204.141.17 with SMTP id k17mr2048941bku.41.1301899715300; Sun, 03 Apr 2011 23:48:35 -0700 (PDT) Received: from [10.87.13.181] ([88.128.92.208]) by mx.google.com with ESMTPS id z18sm2847818bkf.8.2011.04.03.23.48.29 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 23:48:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4D95DD08.3010500@isi.edu> Date: Mon, 4 Apr 2011 08:48:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <495CBD69-14DB-4426-8B9B-AE3F6D7F385B@inf-net.nl> References: <4D94BDA0.6010402@isi.edu> <4D9597D5.9080604@isi.edu> <4D95AA24.2010502@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> <4D95DD08.3010500@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) Cc: int-area@ietf.org Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 06:46:55 -0000 Hi Joe, Op 1 apr 2011, om 16:11 heeft Joe Touch het volgende geschreven: > Hi, Teco, >=20 > On 4/1/2011 5:06 AM, Teco Boot wrote: > ... >>>> The RFC 791 DF example (page 25) describes the use case where DF=3D1 >>>> packets are atomic, and both source and destination are aware. >>>=20 >>> The source knows it's setting DF, but the destination has no way of = knowing that. >>=20 >> FO re-usage is based on DF=3D1. Coordination is required. >=20 > What protocol provides this coordination? Currently none is specified. One suggested reusing the evil bit as = Recycled Flag. >>> The ipv4-id-update doc does *not* update RFC791 to reuse FO, just to = be >>> clear. If you want to do that, there's much more work to do - e.g., = to check whether existing routers set DF. >>=20 >> FO re-use expects existing routers do not clear DF. This is = prohibited, as you posted today. >=20 > FO reuse expects that routers do not clear the DF (which is = prohibited), but also expects that routers do not SET the DF (which is = not currently prohibited). I don't get this. When FO is reused, DF MUST be set at source. > The second case is the problem. I agree that we now should explain the = dangers of setting the DF anywhere except the source, but we cannot = simply assume that this is always the case. >=20 > ... >>> There are two behaviors not explicitly described by RFC791: >>> A- valid uses of source fragmentation with DF=3D1 >>> B- dropping source fragmented packets where DF=3D1, solely for that = reason >>>=20 >>> The example reassembly algorithm in sec 3.2 does not examine the DF = bit, which permits case A. >>>=20 >>> However, case B is prohibited by RFC1191, since it would disable all = of source fragmentation. >>=20 >> OK. We don't need to discuss fragmentation and PMTU. >=20 > If we're talking about fragmentation, we really do. That's the common = use for setting DF=3D1. If we can't enforce fragmentation to be disabled, we can't reuse FO. Teco From julien.ietf@gmail.com Mon Apr 4 06:19:56 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741EC28C116 for ; Mon, 4 Apr 2011 06:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mvu0EybcyGS9 for ; Mon, 4 Apr 2011 06:19:50 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 41E6B3A69F0 for ; Mon, 4 Apr 2011 06:19:50 -0700 (PDT) Received: by fxm15 with SMTP id 15so4471464fxm.31 for ; Mon, 04 Apr 2011 06:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=1L54EHixnSDdLSsRpoGCUnHs736FqXdTBb6C2SNY0FY=; b=W8SQs96kSLRITgJ0Z8Wtq9NPm3U5TBoAX6hcG187i6o6Qsgom7WR98HPqGb8ZZpOVJ ccRfKKmkdjxplcivPo6i46OyH/cJUpLYS2fjXzYiPRlDlkAndl24QTIFL/uJJZQEvp+n HLXH4MBIPYi3gZCf1iPbNRDrHc8VKFZ+jQZvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=xvsIBbCIaPZ6ni48HjQQZZsEhEee2RI7ozjwD9ZBneJutiXpqoZV7cd7NaqXRJYRY8 jZ+3ZkTy8zfnmBdg+gY5Ij8kb8+utG0SMvX1avaITi5kRPHzarGpGG2TEerXMMiSF3im p09Mhqw8pT60UBby/OR4/q4Osb+4/NbVxEHkA= MIME-Version: 1.0 Received: by 10.223.7.73 with SMTP id c9mr4131440fac.117.1301923292140; Mon, 04 Apr 2011 06:21:32 -0700 (PDT) Received: by 10.223.87.2 with HTTP; Mon, 4 Apr 2011 06:21:32 -0700 (PDT) Date: Mon, 4 Apr 2011 06:21:32 -0700 Message-ID: From: Julien Laganier To: int-area@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: intarea-ads@tools.ietf.org, intarea-chairs@tools.ietf.org Subject: [Int-area] intarea WG DRAFT meeting minutes X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 13:19:56 -0000 Folks, DRAFT meeting minutes based on excellent notes from Dow Street (thanks a lot!) are available at the link below. http://www.ietf.org/proceedings/80/minutes/intarea.txt Please review and provide corrections if necessary. --julien & scott From touch@isi.edu Mon Apr 4 06:34:58 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809793A69F0 for ; Mon, 4 Apr 2011 06:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.76 X-Spam-Level: X-Spam-Status: No, score=-104.76 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3Cex6Yo6-Gb for ; Mon, 4 Apr 2011 06:34:51 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 6175C3A69BA for ; Mon, 4 Apr 2011 06:34:51 -0700 (PDT) Received: from [192.168.1.91] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p34Da7sU014162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Apr 2011 06:36:16 -0700 (PDT) References: <4D94BDA0.60104 02@isi.edu> <4D9597D5.9080 6 04@isi.edu> <4D95AA24.20105 02@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> <7281EED3-361F-4496-9FF4-44CDACE1AA0A@inf-net.nl> <6C3B397F-1C21-432D-9353-21FA97413917@inf-net.nl> In-Reply-To: <6C3B397F-1C21-432D-9353-21FA97413917@inf-net.nl> Mime-Version: 1.0 (iPad Mail 8F190) Content-Type: text/plain; charset=us-ascii Message-Id: <3003C6C2-8BCE-4219-BA22-4C03337B7C40@isi.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8F190) From: Joe Touch Date: Mon, 4 Apr 2011 06:36:18 -0700 To: Teco Boot X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Templin, Fred L" , "int-area@ietf.org" Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 13:34:58 -0000 Hi Teco, et al.,=20 On Apr 3, 2011, at 11:29 PM, Teco Boot wrote: > Fred, >=20 > Op 1 apr 2011, om 15:52 heeft Templin, Fred L het volgende geschreven: >=20 >> Teco, >>=20 >> I am looking at RFC3931, Section 4.1.4. All it says is >> that the LCCE may fragment IPv4 packets >=20 > I don't read RFC3931 like this. It says ideal solutions work with=20 > RFC1191. And RFC2661 is normative reference, which point to RFC791. >=20 >> - it does not >> say that the LCCE must honor the DF bit. >=20 > It doesn't say the LCCE must not do illegal operations. I do agree=20 > that it were better to mention a DF=3D0 condition. Make errata? > Old: > An LCCE MAY fragment a packet before encapsulating it in L2TP. For > example, if an IPv4 packet arrives at an LCCE from a Remote System > that, after encapsulation with its associated framing, L2TP, and IP, > does not fit in the available path MTU towards its LCCE peer, the > local LCCE may perform IPv4 fragmentation on the packet before tunnel > encapsulation.=20 > New: > An LCCE MAY fragment a packet before encapsulating it in L2TP. For > example, if an IPv4 packet with DF=3D1 arrives at an LCCE from a Remote S= ystem If DF=3D0 > that, after encapsulation with its associated framing, L2TP, and IP, > does not fit in the available path MTU towards its LCCE peer, the > local LCCE may perform IPv4 fragmentation on the packet before tunnel > encapsulation.=20 >=20 > Thanks, Teco >=20 >>=20 >> Fred=20 >>=20 >>> -----Original Message----- >>> From: Teco Boot [mailto:teco@inf-net.nl]=20 >>> Sent: Friday, April 01, 2011 6:41 AM >>> To: Templin, Fred L >>> Cc: Joe Touch; int-area@ietf.org >>> Subject: Re: [Int-area] Recycle IPv4 bits >>>=20 >>> Op 1 apr 2011, om 15:14 heeft Templin, Fred L het volgende geschreven: >>>=20 >>>>> It is april 1st. Has the RFC to do with such date? >>>>> And again, since when do we respect bugs? >>>>=20 >>>> Not an April Fools RFC, and I'm sure implementatons >>>> don't care so much which specs are violated. >>>=20 >>> Please provide a pointer. >>>=20 >>>>> Packets in the wild _can_ be manipulated. Especially=20 >>>>> middleboxes that provide protection for payload sometimes=20 >>>>> illegally change headers. >>>>=20 >>>> Sure, but wouldn't that invalidate your desire to code >>>> something in the header at the source that you could >>>> count on still being there in the same form when the >>>> packet reaches the destination? >>>=20 >>> The only guarantee to prevent malformed packets at=20 >>> destination is to keep them at the source. >>>=20 >>> Teco >>>=20 >>>=20 >>>=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From teco@inf-net.nl Mon Apr 4 07:22:49 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0738228C128 for ; Mon, 4 Apr 2011 07:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.29 X-Spam-Level: X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bllN5Ek5EHi for ; Mon, 4 Apr 2011 07:22:42 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 16FC128C126 for ; Mon, 4 Apr 2011 07:22:41 -0700 (PDT) Received: by bwz13 with SMTP id 13so4450883bwz.31 for ; Mon, 04 Apr 2011 07:24:24 -0700 (PDT) Received: by 10.204.82.143 with SMTP id b15mr2642219bkl.118.1301927063870; Mon, 04 Apr 2011 07:24:23 -0700 (PDT) Received: from [10.87.32.245] ([88.128.95.139]) by mx.google.com with ESMTPS id l1sm3127834bkl.13.2011.04.04.07.24.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 07:24:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <3003C6C2-8BCE-4219-BA22-4C03337B7C40@isi.edu> Date: Mon, 4 Apr 2011 16:24:12 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6FEDC5FF-6169-41E8-A0E1-38CA8A39126E@inf-net.nl> References: <4D94BDA0.60104 02@isi.edu> <4D9597D5.9080 6 04@isi.edu> <4D95AA24.20105 02@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> <7281EED3-361F-4496-9FF4-44CDACE1AA0A@inf-net.nl> <6C3B397F-1C21-432D-9353-21FA97413917@inf-net.nl> <3003C6C2-8BCE-4219-BA22-4C03337B7C40@isi.edu> To: Joe Touch , "Templin, Fred L" X-Mailer: Apple Mail (2.1082) Cc: int-area@ietf.org Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 14:22:49 -0000 >>> >>> I am looking at RFC3931, Section 4.1.4. All it says is >>> that the LCCE may fragment IPv4 packets >> >> I don't read RFC3931 like this. It says ideal solutions work with >> RFC1191. And RFC2661 is normative reference, which point to RFC791. ... >> Make errata? Done. http://www.rfc-editor.org/errata_search.php?eid=2766 Teco From touch@isi.edu Mon Apr 4 10:33:02 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A271928C118 for ; Mon, 4 Apr 2011 10:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.483 X-Spam-Level: X-Spam-Status: No, score=-103.483 tagged_above=-999 required=5 tests=[AWL=-0.884, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vss1G9JL2Kt5 for ; Mon, 4 Apr 2011 10:33:02 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 0BCED28C110 for ; Mon, 4 Apr 2011 10:33:02 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p34HYFx5012448 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 4 Apr 2011 10:34:25 -0700 (PDT) Message-ID: <4D9A0119.30708@isi.edu> Date: Mon, 04 Apr 2011 10:34:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Teco Boot References: <4D94BDA0.6010402@isi.edu> <4D9597D5.9080604@isi.edu> <4D95AA24.2010502@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> <4D95DD08.3010500@isi.edu> <495CBD69-14DB-4426-8B9B-AE3F6D7F385B@inf-net.nl> In-Reply-To: <495CBD69-14DB-4426-8B9B-AE3F6D7F385B@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p34HYFx5012448 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: int-area@ietf.org Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 17:33:02 -0000 Hi, Teco (et al.), On 4/3/2011 11:48 PM, Teco Boot wrote: > Hi Joe, > > Op 1 apr 2011, om 16:11 heeft Joe Touch het volgende geschreven: > >> Hi, Teco, >> >> On 4/1/2011 5:06 AM, Teco Boot wrote: >> ... >>>>> The RFC 791 DF example (page 25) describes the use case where DF=1 >>>>> packets are atomic, and both source and destination are aware. >>>> >>>> The source knows it's setting DF, but the destination has no way of knowing that. >>> >>> FO re-usage is based on DF=1. Coordination is required. >> >> What protocol provides this coordination? > > Currently none is specified. One suggested reusing the evil bit as Recycled Flag. The evil bit was an Apr 1 RFC. Presumably you're thinking of the high-order bit of the offset. However... >>>> The ipv4-id-update doc does *not* update RFC791 to reuse FO, just to be >>>> clear. If you want to do that, there's much more work to do - e.g., to check whether existing routers set DF. >>> >>> FO re-use expects existing routers do not clear DF. This is prohibited, as you posted today. >> >> FO reuse expects that routers do not clear the DF (which is prohibited), but also expects that routers do not SET the DF (which is not currently prohibited). > > I don't get this. When FO is reused, DF MUST be set at source. If DF is set at the source, and FO != 0, then all you have described is source fragmentation. That is the desired way to fragment; it most directly corresponds to IPv6 fragmentation. In that case, all bits of FO are used; there is no available 'high' bit. So your mechanism works only if there is no source fragmentation. That's not realistic. > >> The second case is the problem. I agree that we now should explain the dangers of setting the DF anywhere except the source, but we cannot simply assume that this is always the case. >> >> ... >>>> There are two behaviors not explicitly described by RFC791: >>>> A- valid uses of source fragmentation with DF=1 >>>> B- dropping source fragmented packets where DF=1, solely for that reason >>>> >>>> The example reassembly algorithm in sec 3.2 does not examine the DF bit, which permits case A. >>>> >>>> However, case B is prohibited by RFC1191, since it would disable all of source fragmentation. >>> >>> OK. We don't need to discuss fragmentation and PMTU. >> >> If we're talking about fragmentation, we really do. That's the common use for setting DF=1. > > If we can't enforce fragmentation to be disabled, we can't reuse FO. I'm not following you. You are seeking, I presume, to reuse bits from FO when the source has not fragmented the packet AND the DF flag is set so no further fragmentation is possible. However, when DF=1 at the source, and FO != 0, you have a fragment already, and FO is meaningful. Can we put this issue to rest? Joe From iljitsch@muada.com Tue Apr 5 03:22:03 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADA628C0F0 for ; Tue, 5 Apr 2011 03:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx3nLKxQ61VQ for ; Tue, 5 Apr 2011 03:22:02 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id 3EEC428C0F6 for ; Tue, 5 Apr 2011 03:22:02 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p35APKPO075340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 12:25:20 +0200 (CEST) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Apr 2011 12:23:41 +0200 Message-Id: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> To: Internet Area , Joe Touch Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 10:22:03 -0000 I just read draft-ietf-intarea-ipv4-id-update-02.txt. First off, do we really need to UPDATE RFC 791 a quarter century after = the fact when the IPv4 address space is all but exhausted? This work = simply comes too late to be very useful. Another big problem is that it assumes that the DF bit is always = honored. There is no reason to expect that if the source sets DF bit to = 1, this means the packet is never fragmented. Due to massive misuse of = path MTU discovery all over the internet, people are forced to use = unorthodox measures to mitigate the resulting breakage. One way to do = this is to rewrite a 1 DF into a 0 DF so packets can be fragmented. This = is supported on at least some routers. However, such routers don't = necessarily support rewriting the ID value, so it's important that ALL = IPv4 packets have a valid ID, even if the DF bit is set to 1. BTW, does anyone know whether if, say, packet 1 with ID 100 is = fragmented and a fragment is lost, and then packet 65537 with ID 100 is = received, packet 2 will be used to "reassemble" packet 1? If no, then = using a valid ID value in all packets is not harmful in the case where = packets with DF=3D1 is honored. And FYI, from RFC 4302, which is AFAIK the only place where header = fields are explicitly classified as mutable or immutable in transit: 3.3.3.1.1.1. Base Header Fields The IPv4 base header fields are classified as follows: Immutable Version Internet Header Length Total Length Identification Protocol (This should be the value for AH.) Source Address Destination Address (without loose or strict source routing) Mutable but predictable Destination Address (with loose or strict source routing) Mutable (zeroed prior to ICV calculation) Differentiated Services Code Point (DSCP) (6 bits, see RFC 2474 [NBBB98]) Explicit Congestion Notification (ECN) (2 bits, see RFC 3168 [RFB01]) Flags Fragment Offset Time to Live (TTL) Header Checksum From iljitsch@muada.com Tue Apr 5 03:30:18 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3BF3A6915 for ; Tue, 5 Apr 2011 03:30:18 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9Uwnyvz-M-h for ; Tue, 5 Apr 2011 03:30:18 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id CFA9828C0E1 for ; Tue, 5 Apr 2011 03:30:17 -0700 (PDT) Received: from claw.it.uc3m.es ([163.117.139.50]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p35AXYoq075367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 12:33:35 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4D959E93.4060803@isi.edu> Date: Tue, 5 Apr 2011 12:31:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0DA1ADBA-FA8E-4647-B272-77928FACD405@muada.com> References: <4D94BDA0.6010402@isi.edu> <4D9597D5.9080604@isi.edu> <4D959E93.4060803@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: int-area@ietf.org Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 10:30:19 -0000 On 1 apr 2011, at 11:44, Joe Touch wrote: > I'll update the ID shortly with that info, as well as confirming = whether downstream routers can change DF. They clearly MUST NOT change = from 1 to 0, but it nothing appears to prohibit them from changing it = from 0 to 1 it's not mentioned in RFC 1812 or its updates), I assume this is in the spirit of the date of your message. We have enough broken PMTUD as it is without people creating even more. = One of the IP layer's jobs is to adjust to varying MTUs. That can only = happen in two ways: PMTUD and fragmentation in routers. With IPv4, PMTUD = is not mandatory, and people sending packets with DF=3D0 is a good = indication that PMTUD can't be performed. Don't forget that with IPv4, = unlike with IPv6, fragmentation at the source based on too big messages = is not performed, only resegmentation in the case of TCP. And even if it = were, a packet gets lost and only the retransmission is fragmented at = the source, which can be very bad for the performance of protocols such = as DNS. There is really no upside to messing with all this stuff at this point = in time.= From iljitsch@muada.com Tue Apr 5 03:32:38 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD2128C0F6 for ; Tue, 5 Apr 2011 03:32:38 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e704K5ijyegB for ; Tue, 5 Apr 2011 03:32:37 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id A16AE28C0E1 for ; Tue, 5 Apr 2011 03:32:36 -0700 (PDT) Received: from claw.it.uc3m.es ([163.117.139.50]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p35AZp3P075400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 12:35:52 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Tue, 5 Apr 2011 12:33:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <30150C15-0BEB-4681-9EC2-E05EED6BFA72@muada.com> References: <4D94BDA0.60104 02@isi.edu><4D9597D5.90806 04@isi.edu><4D95AA24.2010502@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Cc: "int-area@ietf.org" Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 10:32:38 -0000 On 1 apr 2011, at 14:31, Templin, Fred L wrote: > I know of at least one RFC that seems to suggest that it > is OK to fragment IPv4 packets regardless of the DF setting. > I have not personally collected any data, but I have seen > suggestions that there is currently-deployed networking > gear that ignores the DF setting. I know I brought up the fact that I configured a dial-up concentrator to = do exactly this in the past. The tunnel to the modems would not support = MTUs larger than 576 bytes, causing many PMTUD problems. Most people = "fix" this with TCP MSS rewriting (or "clamping"), though.= From iljitsch@muada.com Tue Apr 5 03:32:51 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30EC28C143 for ; Tue, 5 Apr 2011 03:32:51 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2w1GWQKu82BZ for ; Tue, 5 Apr 2011 03:32:51 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id 9C5FF28C0E1 for ; Tue, 5 Apr 2011 03:32:50 -0700 (PDT) Received: from claw.it.uc3m.es ([163.117.139.50]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p35AZp3Q075400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 12:36:05 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <7281EED3-361F-4496-9FF4-44CDACE1AA0A@inf-net.nl> Date: Tue, 5 Apr 2011 12:34:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A427E92-E45D-4B34-A718-FE798D9618A2@muada.com> References: <4D94BDA0.60104 02@isi.edu><4D9597D5.90806 04@isi.edu><4D95AA24.2010502@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> <7281EED3-361F-4496-9FF4-44CDACE1AA0A@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1084) Cc: "Templin, Fred L" , "int-area@ietf.org" Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 10:32:51 -0000 On 1 apr 2011, at 14:56, Teco Boot wrote: > And again, since when do we respect bugs? Since when do we go out of our way to create new specs that break = existing behavior?= From ajs@crankycanuck.ca Tue Apr 5 04:59:18 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5E03A68BC for ; Tue, 5 Apr 2011 04:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmZQmMrvao+S for ; Tue, 5 Apr 2011 04:59:18 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id F0B9B3A6781 for ; Tue, 5 Apr 2011 04:59:17 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5197F1ECB422 for ; Tue, 5 Apr 2011 12:01:00 +0000 (UTC) Date: Tue, 5 Apr 2011 08:00:58 -0400 From: Andrew Sullivan To: int-area@ietf.org Message-ID: <20110405120058.GH3246@shinkuro.com> References: <4D94BDA0.6010402@isi.edu> <4D9597D5.9080604@isi.edu> <4D95AA24.2010502@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> <7281EED3-361F-4496-9FF4-44CDACE1AA0A@inf-net.nl> <1A427E92-E45D-4B34-A718-FE798D9618A2@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1A427E92-E45D-4B34-A718-FE798D9618A2@muada.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 11:59:19 -0000 On Tue, Apr 05, 2011 at 12:34:26PM +0200, Iljitsch van Beijnum wrote: > On 1 apr 2011, at 14:56, Teco Boot wrote: > > > And again, since when do we respect bugs? > > Since when do we go out of our way to create new specs that break existing behavior? I fully agree. The IETF isn't the Internet Cops. We're supposed to be about interoperability. This proposal so far seems not to talk about its potential interoperability effects, and I therefore think it should not be pursued, at least until there's a pretty good argument that it is unlikely to break things and that whatever gains there are to be had are greater than the costs of whatever breakage it causes. A -- Andrew Sullivan ajs@crankycanuck.ca From touch@isi.edu Tue Apr 5 09:13:26 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02FE328C125 for ; Tue, 5 Apr 2011 09:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.508 X-Spam-Level: X-Spam-Status: No, score=-103.508 tagged_above=-999 required=5 tests=[AWL=-0.909, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHWGbYpI672O for ; Tue, 5 Apr 2011 09:13:25 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 3665A28C11C for ; Tue, 5 Apr 2011 09:13:25 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p35GElv0022733 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 5 Apr 2011 09:14:50 -0700 (PDT) Message-ID: <4D9B4001.7070805@isi.edu> Date: Tue, 05 Apr 2011 09:14:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> In-Reply-To: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p35GElv0022733 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Internet Area Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 16:13:26 -0000 Hi, Iljitsch, On 4/5/2011 3:23 AM, Iljitsch van Beijnum wrote: > I just read draft-ietf-intarea-ipv4-id-update-02.txt. > > First off, do we really need to UPDATE RFC 791 a quarter century > after the fact when the IPv4 address space is all but exhausted? This > work simply comes too late to be very useful. The point of the document is to explain and permit existing behavior, and to clarify where other existing behavior is problematic. > Another big problem is that it assumes that the DF bit is always > honored. The following are already true: - the ID is repeated within 2MSL - the ID is repeated constantly (e.g., sent as "0" in some cellphones) - the DF bit is ignored This document recognizes that repeating the ID should not have consequences when DF is honored, and thus permits it. We don't assume the DF bit is honored; we do explain the dangers of ignoring it. Those dangers are already present. So basically, the choice in this doc is: A- ignore two conflicting violations of the spec B- declare that one violation is acceptable, but remind that the other is not C- declare that both are acceptable The doc selects B because it is safe. We can't declare ignoring the DF safe; there may be cases where it 'works', but it is never safe. > There is no reason to expect that if the source sets DF bit > to 1, this means the packet is never fragmented. Due to massive > misuse of path MTU discovery all over the internet, people are forced > to use unorthodox measures to mitigate the resulting breakage. One > way to do this is to rewrite a 1 DF into a 0 DF so packets can be > fragmented. This is supported on at least some routers. However, such > routers don't necessarily support rewriting the ID value, so it's > important that ALL IPv4 packets have a valid ID, even if the DF bit > is set to 1. Let's assume you are correct. It's equally then important that all IPv4 packets have a valid ID. As you note, *some* routers and other devices ignore the DF bit. However, *most* (if not all) devices with links over 6.4Mbps already violate the "valid ID" assumption you make. This document favors the majority of hosts and their desire to have individual connections not limited by IP ID uniqueness. This is NOT a change in how anyone does things. All this document does is shift from two "violating behaviors" to one. > BTW, does anyone know whether if, say, packet 1 with ID 100 is > fragmented and a fragment is lost, and then packet 65537 with ID 100 > is received, packet 2 will be used to "reassemble" packet 1? If it arrives within the fragmentation reassembly timeout, it definitely will. The end host won't know it's a fragment from packet 65537. > If no, > then using a valid ID value in all packets is not harmful in the case > where packets with DF=1 is honored. > > And FYI, from RFC 4302, which is AFAIK the only place where header > fields are explicitly classified as mutable or immutable in transit: RFC791 talks about only some header fields changing. It goes into detail only for the length of some options. RFC1812 sec 5.2.5 says the unused bits must pass unchanged, 5.3.3.3 says the precedence fields must not be changed, 5.3.13 says unrecognized options must pass unchanged. There may be other places; I did just a quick check. RFC4302 talks about DF being mutable, but that's in the sense of having a static set of fields over which cryptographic operations occur. Note that it also states - in the section below, specifically that DF can be set, but not that it can be reset: -- Flags - This field is excluded because an intermediate router might set the DF bit, even if the source did not select it. -- RFC4302 does not consider the implications of setting the DF bit together with the Internet's path asymmetry, however. Joe > 3.3.3.1.1.1. Base Header Fields > > The IPv4 base header fields are classified as follows: > > Immutable > Version > Internet Header Length > Total Length > Identification > Protocol (This should be the value for AH.) > Source Address > Destination Address (without loose or strict source routing) > > Mutable but predictable > Destination Address (with loose or strict source routing) > > Mutable (zeroed prior to ICV calculation) > Differentiated Services Code Point (DSCP) > (6 bits, see RFC 2474 [NBBB98]) > Explicit Congestion Notification (ECN) > (2 bits, see RFC 3168 [RFB01]) > Flags > Fragment Offset > Time to Live (TTL) > Header Checksum > > From iljitsch@muada.com Tue Apr 5 09:35:24 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 836203A6944 for ; Tue, 5 Apr 2011 09:35:24 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2oL6d92DNfc for ; Tue, 5 Apr 2011 09:35:23 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id BEC013A6845 for ; Tue, 5 Apr 2011 09:35:19 -0700 (PDT) Received: from claw.it.uc3m.es ([163.117.139.50]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p35Gcas3077016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 18:38:37 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4D9B4001.7070805@isi.edu> Date: Tue, 5 Apr 2011 18:36:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: Internet Area Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 16:35:24 -0000 On 5 apr 2011, at 18:14, Joe Touch wrote: > So basically, the choice in this doc is: > A- ignore two conflicting violations of the spec > B- declare that one violation is acceptable, but > remind that the other is not > C- declare that both are acceptable > The doc selects B because it is safe. We can't declare ignoring the DF = safe; there may be cases where it 'works', but it is never safe. I would call this a false trichotomy, if such a thing exists. Whatever we do, we shouldn't let people get away with not using valid ID = values. But the real solution is not to rehash broken implementations of = 25-year-old assumptions, but rather address the real problem, if there = is a problem to be addressed. > However, *most* (if not all) devices with links over 6.4Mbps already = violate the "valid ID" assumption you make. This is the idea that an ID value can't be repeated for 120 (or 240) = seconds for the same 3-tuple. But why 120 seconds? Is there any = reasonable way that a packet gets fragmented, and then one of the = fragments is delayed so long than 65535 other packets are received in = the interim? I can't think of anything. So I would favor a system where = fragments are buffered for reassembly not for some fixed amout of time, = but for the time it takes to receive some X number of packets, where X = can be something like 100, 1000 or 10000 packets. Yes, in a very small number of cases this will lead to an avoidable loss = when the missing fragment is received after all just as the previous = fragments were thrown away, but that's something I can live with, = considering the alternative that is either basically an incorrect = reassembly for EVERY lost fragment (and presumably if fragments happen = they happen for nearly all packets so this happens for EVERY loss) which = translates into an undetected data corruption once every ~ 65535 losses = OR artificially limiting flows to only a few megabit/s. Iljitsch From touch@isi.edu Tue Apr 5 09:50:02 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE4F128C125 for ; Tue, 5 Apr 2011 09:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.477 X-Spam-Level: X-Spam-Status: No, score=-105.477 tagged_above=-999 required=5 tests=[AWL=1.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEdkG1ZMZ28o for ; Tue, 5 Apr 2011 09:50:01 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 4623B28C120 for ; Tue, 5 Apr 2011 09:50:01 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p35GpW5L027570 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 5 Apr 2011 09:51:32 -0700 (PDT) Message-ID: <4D9B4893.8010606@isi.edu> Date: Tue, 05 Apr 2011 09:51:31 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> In-Reply-To: <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.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: Internet Area Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 16:50:02 -0000 On 4/5/2011 9:36 AM, Iljitsch van Beijnum wrote: > On 5 apr 2011, at 18:14, Joe Touch wrote: > >> So basically, the choice in this doc is: > >> A- ignore two conflicting violations of the spec > >> B- declare that one violation is acceptable, but >> remind that the other is not > >> C- declare that both are acceptable > >> The doc selects B because it is safe. We can't declare ignoring the DF safe; there may be cases where it 'works', but it is never safe. > > I would call this a false trichotomy, if such a thing exists. > > Whatever we do, we shouldn't let people get away with not using valid ID values. That ship sailed. Unless you're throttling all your connections to under 6.4Mbps. > But the real solution is not to rehash broken implementations of > 25-year-old assumptions, but rather address the real problem, if there > is a problem to be addressed. That's exactly the purpose of the draft. It also helps inform other IETF areas that IDs do repeat, and *not* to rely on the uniqueness of the ID field, e.g., for duplicate detection and removal (as is currently being proposed in MANET (SMF). >> However, *most* (if not all) devices with links over 6.4Mbps already violate the "valid ID" assumption you make. > > This is the idea that an ID value can't be repeated for 120 (or 240) > seconds for the same 3-tuple. But why 120 seconds? Is there any > reasonable way that a packet gets fragmented, and then one of the > fragments is delayed so long than 65535 other packets are received in > the interim? I can't think of anything. There are plenty of systems with path asymmetries with delays of tens of seconds. E.g., see Jim Getty's presentation this past IETF in TSVAREA. > So I would favor a system where > fragments are buffered for reassembly not for some fixed amout of time, > but for the time it takes to receive some X number of packets, where X > can be something like 100, 1000 or 10000 packets. That's another discussion included in the draft, and another purpose of the draft. As is the note that upper layers should not rely on packets being reassembled correctly - but instead should include upper layer checksums that are robust in the presence of misfragmentation. Overall, the doc is intended to inform, and *relax* existing requirements where possible, and to warn where this is either not possible or stricter behavior (e.g., routers not changing DF=0 to DF=1) is safer. Joe From touch@isi.edu Tue Apr 5 11:46:07 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104C73A6974 for ; Tue, 5 Apr 2011 11:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.514 X-Spam-Level: X-Spam-Status: No, score=-105.514 tagged_above=-999 required=5 tests=[AWL=1.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AULkgqEDAnw9 for ; Tue, 5 Apr 2011 11:46:06 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 696373A63EC for ; Tue, 5 Apr 2011 11:46:06 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p35IlE6P022167 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 5 Apr 2011 11:47:14 -0700 (PDT) Message-ID: <4D9B63B2.5060909@isi.edu> Date: Tue, 05 Apr 2011 11:47:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <4D94BDA0.6010402@isi.edu> <4D9597D5.9080604@isi.edu> <4D959E93.4060803@isi.edu> <0DA1ADBA-FA8E-4647-B272-77928FACD405@muada.com> In-Reply-To: <0DA1ADBA-FA8E-4647-B272-77928FACD405@muada.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 Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 18:46:07 -0000 Hi, Iljitsch, On 4/5/2011 3:31 AM, Iljitsch van Beijnum wrote: > On 1 apr 2011, at 11:44, Joe Touch wrote: > >> I'll update the ID shortly with that info, as well as confirming > whether downstream routers can change DF. They clearly MUST NOT change > from 1 to 0, but it nothing appears to prohibit them from changing it > from 0 to 1 it's not mentioned in RFC 1812 or its updates), > > I assume this is in the spirit of the date of your message. I'll remember to avoid email altogether next Apr 1. > We have enough broken PMTUD as it is without people creating even > more. One of the IP layer's jobs is to adjust to varying MTUs. That can > only happen in two ways: PMTUD and fragmentation in routers. With IPv4, > PMTUD is not mandatory, and people sending packets with DF=0 is a good > indication that PMTUD can't be performed. Don't forget that with IPv4, > unlike with IPv6, fragmentation at the source based on too big messages > is not performed, only resegmentation in the case of TCP. RFC792 says that fragmentation needed ICMPs are sent back to the originating source, and cites RFC791. Note - it does NOT cite RFC793. So I can only conclude that the whole point of the too-big is to get the source to fragment *at the source*. Source fragmentation definitely occurs when the outgoing message is bigger than the interface supports, but I'd have to do some checking on what actually happens when an ICMP too-big is received. I'd be surprised if that isn't handled in some way, though. If that's the case, then DF=0 is the desired behavior, though, because you can't assume that devices on the path ignore DF=1 (i.e., safe source behavior is always better than expecting noncompliant behavior downpath). > And even if it > were, a packet gets lost and only the retransmission is fragmented at > the source, which can be very bad for the performance of protocols such > as DNS. Your message is confusing; I am not suggesting we prohibit packets with DF=0. I'm saying that once a packet is sent with DF=0, changing it to DF=1 en-route is dangerous and serves no useful purpose AFAICT. Joe From iljitsch@muada.com Tue Apr 5 13:31:55 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0634528C12B for ; Tue, 5 Apr 2011 13:31:55 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtmRzceSojbw for ; Tue, 5 Apr 2011 13:31:54 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id 19F4E28C0E9 for ; Tue, 5 Apr 2011 13:31:53 -0700 (PDT) Received: from [192.168.0.140] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p35KZBnX082494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 22:35:13 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4D9B63B2.5060909@isi.edu> Date: Tue, 5 Apr 2011 22:33:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <96D1D2C0-4600-4F21-99DB-50A5B7BF5139@muada.com> References: <4D94BDA0.6010402@isi.edu> <4D9597D5.9080604@isi.edu> <4D959E93.4060803@isi.edu> <0DA1ADBA-FA8E-4647-B272-77928FACD405@muada.com> <4D9B63B2.5060909@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: Internet Area Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 20:31:55 -0000 Hi Joe, On 5 apr 2011, at 20:47, Joe Touch wrote: >> I assume this is in the spirit of the date of your message. > I'll remember to avoid email altogether next Apr 1. :-) >> Don't forget that with IPv4, >> unlike with IPv6, fragmentation at the source based on too big = messages >> is not performed, only resegmentation in the case of TCP. > RFC792 says that fragmentation needed ICMPs are sent back to the = originating source, and cites RFC791. Note - it does NOT cite RFC793. You are reading this with today's notion of PMTUD in mind. For IPv4, = "too big" is a subtype of destination unreachable, which typically = doesn't carry the connotation that a retransmission is useful. (For IPv6 = "too big" is no longer grouped under unreachable.) Because IPv4 never had ICMP feedback related fragmentation at the source = (just "whatever fits in the MTU") de facto IPv4 PMTUD only works with = TCP because unlike most UDP protocols, TCP can arbitrarily adjust its = packet size without any higher layer implications. > I'd have to do some checking on what actually happens when an ICMP = too-big is received. I'd be surprised if that isn't handled in some way, = though. Prepare to be surprised. Perhaps this is brought into line with IPv6 in = newer implementations recently, but I've never seen it happen. > I'm saying that once a packet is sent with DF=3D0, changing it to DF=3D1= en-route is dangerous and serves no useful purpose AFAICT. Ok, then we agree on that part. Iljitsch From iljitsch@muada.com Tue Apr 5 13:43:15 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52BE228B797 for ; Tue, 5 Apr 2011 13:43:15 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9H-aOZG2Vg4d for ; Tue, 5 Apr 2011 13:43:14 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id 23B5A28C113 for ; Tue, 5 Apr 2011 13:43:13 -0700 (PDT) Received: from [192.168.0.140] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p35KkUk6082572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 22:46:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4D9B4893.8010606@isi.edu> Date: Tue, 5 Apr 2011 22:44:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: Internet Area Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 20:43:15 -0000 On 5 apr 2011, at 18:51, Joe Touch wrote: >> This is the idea that an ID value can't be repeated for 120 (or 240) >> seconds for the same 3-tuple. But why 120 seconds? Is there any >> reasonable way that a packet gets fragmented, and then one of the >> fragments is delayed so long than 65535 other packets are received in >> the interim? I can't think of anything. > There are plenty of systems with path asymmetries with delays of tens = of seconds. E.g., see Jim Getty's presentation this past IETF in = TSVAREA. Can't find that real quick. But I'm doing some measurements currently, and what I'm seeing doesn't = support that at all, for two reasons: - reordering (=3D the packets must be sent down different paths) is very = rare for packets that belong to the same session, think single digit = percentages - even if it happens, the timing differences between reordered packets = are counted in microseconds, not even whole milliseconds In addition to that, I don't see multiple second delays AND hundreds or = thousands of packets per second happening at the same time. Slow = networks could potentially do the former, fast networks the latter, but = I can't think of anything that can do both. > As is the note that upper layers should not rely on packets being = reassembled correctly - but instead should include upper layer checksums = that are robust in the presence of misfragmentation. If the ID rollover time is shorter than the reassembly timeout you WILL = get an incorrect reassembly for _every_ lost packet, so a checksum would = have to be very strong to protect against that. The current 16-bit = checksum isn't strong enough for this. But upgrading TCP and UDP to use = larger checksums seems like an uphill struggle. Especially because the = lower layer checksums are typically strong enough to protect against = transmission errors and the weak internet checksum allows us to do stuff = cheap that would otherwise be problematic, such as NAT, which would get = a big performance hit if incremental checksum updates weren't possible. From jnc@mercury.lcs.mit.edu Tue Apr 5 13:59:12 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13C7E3A67D4 for ; Tue, 5 Apr 2011 13:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIQ+AAcj4O+y for ; Tue, 5 Apr 2011 13:59:11 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 698EA3A67D2 for ; Tue, 5 Apr 2011 13:59:11 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D509118C0CD; Tue, 5 Apr 2011 17:00:53 -0400 (EDT) To: int-area@ietf.org Message-Id: <20110405210053.D509118C0CD@mercury.lcs.mit.edu> Date: Tue, 5 Apr 2011 17:00:53 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 20:59:12 -0000 > From: Joe Touch > I can only conclude that the whole point of the too-big is to get > the source to fragment *at the source*. Yes, that was our intention. > Source fragmentation definitely occurs when the outgoing message is > bigger than the interface supports Yes. One of the earlier instances of this I can recall is Dave Clark getting Multics to emit 65Kbyte TCP segments (although I think only other Multices supported reassembling packets that large at that stage) - that caused the TCP process to get woken up 'less often' on bulk data transfers, and so gave him less overhead. But, like I said, I don't think we ever envisaged a source host fragmenting a packet and _then_ setting DF=1 on the fragments. DF was there for packets you didn't wanted fragmented _at all_ - and for the host to pre-fragment, and then set DF on the fragments, makes no sense at all from that point of view. In other words, had we thought of it, we'd probably have disallowed sending packets with DF=1 and (Offset!=0 or MF=1). Noel From jnc@mercury.lcs.mit.edu Tue Apr 5 14:11:21 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8433A67E3 for ; Tue, 5 Apr 2011 14:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E6YZig8JUJU for ; Tue, 5 Apr 2011 14:11:18 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id D2D213A67D9 for ; Tue, 5 Apr 2011 14:11:16 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id AE65118C0CD; Tue, 5 Apr 2011 17:12:59 -0400 (EDT) To: int-area@ietf.org Message-Id: <20110405211259.AE65118C0CD@mercury.lcs.mit.edu> Date: Tue, 5 Apr 2011 17:12:59 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 21:11:22 -0000 > From: jnc@mercury.lcs.mit.edu (Noel Chiappa) >> From: Joe Touch >> I can only conclude that the whole point of the too-big is to get >> the source to fragment *at the source*. > Yes, that was our intention. Oops, minor thinko: now that I think about it, I think our intended response was, for packets with DF set, for the source host to send smaller packets. (And if the application could not do that, tough noogies - it then gets to use fragmentable packets, or nada.) Although I'm not sure that we gave this all that much thought, actually. I suspect what happened is that we thought up every failure mode we could think of, and defined an ICMP error code for it. We didn't think through in detail how each one would be used/handled - case in point being Source Quench! In this case, note that neither RFC 815 nor RFC 816 cover packets with DF set - it just wasn't something we thought much about. Noel From xiaohong.deng@orange-ftgroup.com Wed Apr 6 01:55:40 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C56E3A6849 for ; Wed, 6 Apr 2011 01:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjsPAD9yENao for ; Wed, 6 Apr 2011 01:55:39 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 436443A681D for ; Wed, 6 Apr 2011 01:55:39 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 80904FC4005 for ; Wed, 6 Apr 2011 10:57:29 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 75D7DFC4001 for ; Wed, 6 Apr 2011 10:57:29 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 10:57:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF438.A2960F55" Date: Wed, 6 Apr 2011 16:57:18 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC016850B4@ch-mailsrv.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateless IPv4-in-IPv6 experiments Thread-Index: Acv0OKIfeBKxTZ9OS2q+zt1Psny0lA== From: To: X-OriginalArrivalTime: 06 Apr 2011 08:57:22.0546 (UTC) FILETIME=[A4811520:01CBF438] Subject: [Int-area] Stateless IPv4-in-IPv6 experiments X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 08:55:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF438.A2960F55 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 An I-D about stateless IPv4-in-IPv6 experiments has been submitted. A URL for this Internet-Draft is: http://tools.ietf.org/html/draft-deng-aplusp-experiment-results-00 . =20 A website introducing the detail of experiment results is also accessible via: http://opensourceaplusp.weebly.com/ =20 =20 BR, Xiaohong ------_=_NextPart_001_01CBF438.A2960F55 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear=20 all,
 
An I-D=20 about stateless IPv4-in-IPv6 = experiments=20 has been submitted. A URL for=20 this Internet-Draft is: http://tools.ietf.org/html/draft-deng-aplusp-experiment-r= esults-00.
 
A website introducing=20 the detail of experiment results is also accessible via: http://opensourceaplusp.weebly.com/
 
BR,
Xiaohong
------_=_NextPart_001_01CBF438.A2960F55-- From scott.brim@gmail.com Wed Apr 6 08:32:09 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4AE28B23E for ; Wed, 6 Apr 2011 08:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.592 X-Spam-Level: X-Spam-Status: No, score=-103.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ym37luZdMqA for ; Wed, 6 Apr 2011 08:32:08 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 5026A3A69C2 for ; Wed, 6 Apr 2011 08:32:08 -0700 (PDT) Received: by iwn39 with SMTP id 39so1941864iwn.31 for ; Wed, 06 Apr 2011 08:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=227n/TqmQ/gtXJSjGm3zdoe21jaP+Lfa9TISwIhoIH8=; b=G5VU0t1BMc0bTC70v8toE+abjvUf/ms6zYzkQMz64N/6h+RD0SjyG66mRFjjr8oUXr UvsIChfsP9sXzK8me30vy/lWatjvI8c7UZcWcU+2tYkxsFID4gllgdk1RYsSXACM+V9Y LbZAcZZkBQeuSdXGm7uejGOgjqmFZ38GBcGkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=dMlTP55LlnVhKtGuqAoOOhND63CdFAOoacuop/Bg5JBTmxdrbG7Tk/uJAealVHzAaF VIhsr0aZnZJYsZkDa4C2ycQXztghA3ajFW9Y4/nw+HYfnJUUzchbD/ayi1T5VBrg1UoP AeQnzqSyXrPNqP29BVtOvpHYE2w7lMVGf09bw= Received: by 10.231.62.72 with SMTP id w8mr1127006ibh.80.1302104032200; Wed, 06 Apr 2011 08:33:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.208.14 with HTTP; Wed, 6 Apr 2011 08:33:32 -0700 (PDT) In-Reply-To: <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> From: Scott Brim Date: Wed, 6 Apr 2011 11:33:32 -0400 Message-ID: To: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary=000e0cd56c544cc89804a041b89e Cc: Internet Area Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:32:09 -0000 --000e0cd56c544cc89804a041b89e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 5, 2011 at 16:44, Iljitsch van Beijnum wrote: > On 5 apr 2011, at 18:51, Joe Touch wrote: > > >> This is the idea that an ID value can't be repeated for 120 (or 240) > >> seconds for the same 3-tuple. But why 120 seconds? Is there any > >> reasonable way that a packet gets fragmented, and then one of the > >> fragments is delayed so long than 65535 other packets are received in > >> the interim? I can't think of anything. > > > There are plenty of systems with path asymmetries with delays of tens of > seconds. E.g., see Jim Getty's presentation this past IETF in TSVAREA. > > Can't find that real quick. > You would enjoy a visit to http://www.bufferbloat.net Scott --000e0cd56c544cc89804a041b89e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 5, 2011 at 16:44, Iljitsch van Beijn= um <iljitsch@mua= da.com> wrote:
On 5 apr 2011, at 18:51, Joe Touch wrote:

>> This is the idea that an ID value can't be repeated for 120 (o= r 240)
>> seconds for the same 3-tuple. But why 120 seconds? Is there any >> reasonable way that a packet gets fragmented, and then one of the<= br> >> fragments is delayed so long than 65535 other packets are received= in
>> the interim? I can't think of anything.

> There are plenty of systems with path asymmetries with delays of tens = of seconds. E.g., see Jim Getty's presentation this past IETF in TSVARE= A.

Can't find that real quick.

Y= ou would enjoy a visit to http://www= .bufferbloat.net
=A0
Scott

--000e0cd56c544cc89804a041b89e-- From remi.despres@free.fr Wed Apr 6 09:19:11 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E398E3A67CF for ; Wed, 6 Apr 2011 09:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.893 X-Spam-Level: X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KwWPN9FhiSS for ; Wed, 6 Apr 2011 09:19:04 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by core3.amsl.com (Postfix) with ESMTP id 9BAC53A67AF for ; Wed, 6 Apr 2011 09:19:04 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id CF6C67000093; Wed, 6 Apr 2011 18:20:47 +0200 (CEST) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id 6EE25700008C; Wed, 6 Apr 2011 18:20:47 +0200 (CEST) X-SFR-UUID: 20110406162047454.6EE25700008C@msfrf2108.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-27--470383588 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC016850B4@ch-mailsrv.rd.francetelecom.fr> Date: Wed, 6 Apr 2011 18:20:47 +0200 Message-Id: References: <0962B0BEF842A24191AD9BE41A8DD2FC016850B4@ch-mailsrv.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: int-area@ietf.org Subject: Re: [Int-area] Stateless IPv4-in-IPv6 experiments X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 16:19:12 -0000 --Apple-Mail-27--470383588 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thank you, Xiahong, for sharing this interesting information. In the case of BitComet and uTorrent, I wonder what happens if the host = has both A+P IPv4 and IPv6, as opposed to just A+P IPv4. Did you try that? Regards, RD Le 6 avr. 2011 =E0 10:57, = a =E9crit : > Dear all, > =20 > An I-D about stateless IPv4-in-IPv6 experiments has been submitted. A = URL for this Internet-Draft is: = http://tools.ietf.org/html/draft-deng-aplusp-experiment-results-00. > =20 > A website introducing the detail of experiment results is also = accessible via: http://opensourceaplusp.weebly.com/ > =20 > BR, > Xiaohong > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --Apple-Mail-27--470383588 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank = you, Xiahong, for sharing this interesting = information.

In the case of BitComet and uTorrent, I = wonder what happens if the host has both A+P IPv4 and IPv6, as opposed = to just A+P IPv4.
Did you try = that?

Regards,
RD

Le 6 avr. 2011 =C3=A0 10:57, <xiaohong.deng@orange-ftgr= oup.com> <xiaohong.deng@orange-ftgr= oup.com> a =C3=A9crit :

Dear=20 all,
 
An I-D=20 about stateless IPv4-in-IPv6 = experiments=20 has been submitted. A URL for=20 this Internet-Draft is: http://tools.ietf.org/html/draft-deng-aplusp-experiment-= results-00.
 
A website introducing=20 the detail of experiment results is also accessible via: http://opensourceaplusp.weebly.com/
 
BR,
Xiaohong
_______________________________________________
Int-area mailing = list
Int-area@ietf.org
https://www.iet= f.org/mailman/listinfo/int-area

= --Apple-Mail-27--470383588-- From iljitsch@muada.com Wed Apr 6 09:37:44 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A023A69CC for ; Wed, 6 Apr 2011 09:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g74ibOZCMnpa for ; Wed, 6 Apr 2011 09:37:43 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id CBD723A67AF for ; Wed, 6 Apr 2011 09:37:41 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p36GevUp087882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Apr 2011 18:40:57 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Wed, 6 Apr 2011 18:39:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <221640FE-611C-4885-9BA9-44798F147D85@muada.com> References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> To: Scott Brim X-Mailer: Apple Mail (2.1084) Cc: Internet Area Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 16:37:45 -0000 On 6 apr 2011, at 17:33, Scott Brim wrote: > Jim Getty's presentation this past IETF in TSVAREA. > Can't find that real quick. > You would enjoy a visit to http://www.bufferbloat.net Ah, it starts at 25 minutes in on the recording for wednesday morning on = channel 4, with the slides here: http://mirrors.bufferbloat.net/Talks/PragueIETF/IETFBloat7.pdf BTW, I'm not seeing the disasters he's describing, I only get 6 or 12 ms = extra delay doing 100 Mbps transfers locally. But... none of this has ANYTHING to do with the issue at hand, unless = someone can show me how packet 50 sits in the buffer for 100 or 1000 or = what have you milliseconds and then packet 51 magically flies through = the queue and arrives much earlier than packet 50. From swmike@swm.pp.se Wed Apr 6 09:55:42 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7813A67B0 for ; Wed, 6 Apr 2011 09:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V104L+yvhYXx for ; Wed, 6 Apr 2011 09:55:41 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 2C4273A67AF for ; Wed, 6 Apr 2011 09:55:39 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5AB1E9C; Wed, 6 Apr 2011 18:57:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 554BB9A; Wed, 6 Apr 2011 18:57:21 +0200 (CEST) Date: Wed, 6 Apr 2011 18:57:21 +0200 (CEST) From: Mikael Abrahamsson To: Iljitsch van Beijnum In-Reply-To: <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> Message-ID: References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Internet Area , Joe Touch Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 16:55:42 -0000 On Tue, 5 Apr 2011, Iljitsch van Beijnum wrote: > - even if it happens, the timing differences between reordered packets > are counted in microseconds, not even whole milliseconds I have to disagree with this. I always discourage people from using per-packet loadblanacing, but if done on a 2 meg connection (as an example), just clocking out a 1500 byte packet takes 6 milliseconds, so two packets can easily arrive several milliseconds in wrong order in this use-case. > In addition to that, I don't see multiple second delays AND hundreds or > thousands of packets per second happening at the same time. Slow > networks could potentially do the former, fast networks the latter, but > I can't think of anything that can do both. I have to agree with that, though. -- Mikael Abrahamsson email: swmike@swm.pp.se From iljitsch@muada.com Wed Apr 6 10:17:30 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CB8F3A6967 for ; Wed, 6 Apr 2011 10:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxyyhIQL+D79 for ; Wed, 6 Apr 2011 10:17:30 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id 81B423A6962 for ; Wed, 6 Apr 2011 10:17:28 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p36HKlXf088118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Apr 2011 19:20:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Wed, 6 Apr 2011 19:19:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) Cc: Internet Area , Joe Touch Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:17:30 -0000 On 6 apr 2011, at 18:57, Mikael Abrahamsson wrote: >> - even if it happens, the timing differences between reordered = packets are counted in microseconds, not even whole milliseconds > I have to disagree with this. I always discourage people from using = per-packet loadblanacing, but if done on a 2 meg connection (as an = example), just clocking out a 1500 byte packet takes 6 milliseconds, so = two packets can easily arrive several milliseconds in wrong order in = this use-case. I've been working on 100 Mbps links, obviously this is different if you = run much slower, which can happen at the edge of the network. But not = really in the core, these days, I would say. From touch@isi.edu Wed Apr 6 10:26:45 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D9B3A695C for ; Wed, 6 Apr 2011 10:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.531 X-Spam-Level: X-Spam-Status: No, score=-103.531 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqed1oS5WYyj for ; Wed, 6 Apr 2011 10:26:44 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0729B3A68AB for ; Wed, 6 Apr 2011 10:26:43 -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 p36HRfRu009930 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 6 Apr 2011 10:27:41 -0700 (PDT) Message-ID: <4D9CA28D.3060801@isi.edu> Date: Wed, 06 Apr 2011 10:27:41 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <221640FE-611C-4885-9BA9-44798F147D85@muada.com> In-Reply-To: <221640FE-611C-4885-9BA9-44798F147D85@muada.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: Internet Area , Scott Brim Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:26:45 -0000 Hi, Iljitsch, On 4/6/2011 9:39 AM, Iljitsch van Beijnum wrote: > On 6 apr 2011, at 17:33, Scott Brim wrote: > >> Jim Getty's presentation this past IETF in TSVAREA. > >> Can't find that real quick. > >> You would enjoy a visit to http://www.bufferbloat.net > > Ah, it starts at 25 minutes in on the recording for wednesday morning on channel 4, with the slides here: > > http://mirrors.bufferbloat.net/Talks/PragueIETF/IETFBloat7.pdf > > BTW, I'm not seeing the disasters he's describing, I only get 6 or 12 > ms extra delay doing 100 Mbps transfers locally. Not everyone does. It depends on what OS you do the test from, which local router (DSL box, etc.) you're using, etc. > But... none of this has ANYTHING to do with the issue at hand, > unless someone can show me how packet 50 sits in the buffer for 100 > or 1000 or what have you milliseconds and then packet 51 magically > flies through the queue and arrives much earlier than packet 50. That's basically the point. The Internet is a highly variable place, and getting more so with large delays (buffer bloat, satellite links) and multiple paths (e.g., automatic use of WiFi vs. 3G, etc. links). The draft doesn't change any recommendations when DF=0 *because* this variability persists. There should be no impact when DF=1 (except for misbehaving devices, for which there is already impact for existing devices that reuse IDs). Joe From touch@isi.edu Wed Apr 6 10:32:59 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFCFD3A6957 for ; Wed, 6 Apr 2011 10:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.516 X-Spam-Level: X-Spam-Status: No, score=-103.516 tagged_above=-999 required=5 tests=[AWL=-0.917, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncTV5Cxterm1 for ; Wed, 6 Apr 2011 10:32:59 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 335BD3A69B4 for ; Wed, 6 Apr 2011 10:32:59 -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 p36HXl8w010966 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 6 Apr 2011 10:33:47 -0700 (PDT) Message-ID: <4D9CA3FB.4050300@isi.edu> Date: Wed, 06 Apr 2011 10:33:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> In-Reply-To: <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.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: Internet Area Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:33:00 -0000 On 4/5/2011 1:44 PM, Iljitsch van Beijnum wrote: > On 5 apr 2011, at 18:51, Joe Touch wrote: > >>> This is the idea that an ID value can't be repeated for 120 (or >>> 240) seconds for the same 3-tuple. But why 120 seconds? Is there >>> any reasonable way that a packet gets fragmented, and then one of >>> the fragments is delayed so long than 65535 other packets are >>> received in the interim? I can't think of anything. > >> There are plenty of systems with path asymmetries with delays of >> tens of seconds. E.g., see Jim Getty's presentation this past IETF >> in TSVAREA. > > Can't find that real quick. > > But I'm doing some measurements currently, and what I'm seeing > doesn't support that at all, for two reasons: The Internet is a very big place, and it's intended to work in most places, rather than just in the places any individual currently sees. > - reordering (= the packets must be sent down different paths) is > very rare for packets that belong to the same session, think single > digit percentages As noted in my other post, that could be increasing with multiple disparate connections becoming the norm. > - even if it happens, the timing differences between reordered > packets are counted in microseconds, not even whole milliseconds You should measure 3G, and include a satellite path too. Both have longer latencies even without buffer bloat. > In addition to that, I don't see multiple second delays AND hundreds > or thousands of packets per second happening at the same time. Slow > networks could potentially do the former, fast networks the latter, but > I can't think of anything that can do both. That's common over satellite paths, and also common in the buffer bloat case. >> As is the note that upper layers should not rely on packets being >> reassembled correctly - but instead should include upper layer >> checksums that are robust in the presence of misfragmentation. > > If the ID rollover time is shorter than the reassembly timeout you > WILL get an incorrect reassembly for _every_ lost packet, so a > checksum would have to be very strong to protect against that. The > current 16-bit checksum isn't strong enough for this. But upgrading > TCP and UDP to use larger checksums seems like an uphill struggle. This doc isn't proposing that. It just warns that rolling over the ID in the absence of stronger checksums is dangerous. > Especially because the lower layer checksums are typically strong > enough to protect against transmission errors and the weak internet > checksum allows us to do stuff cheap that would otherwise be > problematic, such as NAT, which would get a big performance hit if > incremental checksum updates weren't possible. Stronger object checksums can also exist at the application layer, as with Bittorrent, and at the session layer, such as with SSL (that's for crypto, but still protects against incorrect reassembly). Joe From swmike@swm.pp.se Wed Apr 6 10:44:46 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7451E3A6962 for ; Wed, 6 Apr 2011 10:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOOqlL-+4zAI for ; Wed, 6 Apr 2011 10:44:45 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id AAFCA3A6941 for ; Wed, 6 Apr 2011 10:44:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 164819C; Wed, 6 Apr 2011 19:46:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 10F5C9A; Wed, 6 Apr 2011 19:46:29 +0200 (CEST) Date: Wed, 6 Apr 2011 19:46:29 +0200 (CEST) From: Mikael Abrahamsson To: Joe Touch In-Reply-To: <4D9CA3FB.4050300@isi.edu> Message-ID: References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <4D9CA3FB.4050300@isi.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Internet Area Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:44:46 -0000 On Wed, 6 Apr 2011, Joe Touch wrote: > You should measure 3G, and include a satellite path too. Both have > longer latencies even without buffer bloat. My personal record is 180 seconds delay over GSM. However, the RAN ensures packet ordering, so to get re-ordering over this, they'd have to be per-packet loadshared between multiple connections. > That's common over satellite paths, and also common in the buffer bloat > case. I dislike the term "buffer bloat". Large buffers have a point, it's just that large FIFO buffers are bad. An example, there is little problem having single TCP session over 100 meg link between proper routers, get 100 ms latency. This is between two linux boxes. Turn on cisco "fair-queue" (which does require to keep flow state, thus uses lots of CPU), and one flow will not give 100ms latency to another flow, instead it will see very little difference to an unloaded link. Anyhow, my point is that re-ordering happens in real life networks (although I'd say they're badly engineered ones). I've seen it in real life, I've talked to application programmers who designed applications which relied on packets being ordered, and who had to re-design with jitter buffers to handle out of order packets (instead of counting skips in sequence numbers as drops). It happens in slow networks, it happens in fast networks. It's not hugely common, but it's out there. -- Mikael Abrahamsson email: swmike@swm.pp.se From Fred.L.Templin@boeing.com Wed Apr 6 10:46:03 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19B763A69DA for ; Wed, 6 Apr 2011 10:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.347 X-Spam-Level: X-Spam-Status: No, score=-6.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX1h5KhKX9rQ for ; Wed, 6 Apr 2011 10:46:02 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 302F43A69D9 for ; Wed, 6 Apr 2011 10:46:02 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p36HlfX9007219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2011 10:47:41 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p36HleS0020685; Wed, 6 Apr 2011 10:47:40 -0700 (PDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p36HleIU020660 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 6 Apr 2011 10:47:40 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Wed, 6 Apr 2011 10:47:40 -0700 From: "Templin, Fred L" To: Iljitsch van Beijnum , Joe Touch Date: Wed, 6 Apr 2011 10:47:38 -0700 Thread-Topic: [Int-area] Recycle IPv4 bits Thread-Index: Acvz0UuvgKjFnicSRlWy+j5eh+ZEKQApsleg Message-ID: References: <4D94BDA0.60104 02@isi.edu><4D9597D5.90806 04@isi.edu> <4D959E93.4060803@isi.edu><0DA1ADBA-FA8E-4647-B272-77928FACD405@muada.com><4D9B63B2.5060909@isi.edu> <96D1D2C0-4600-4F21-99DB-50A5B7BF5139@muada.com> In-Reply-To: <96D1D2C0-4600-4F21-99DB-50A5B7BF5139@muada.com> 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: Internet Area Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:46:03 -0000 Hi Iljitsch,=20 > -----Original Message----- > From: int-area-bounces@ietf.org=20 > [mailto:int-area-bounces@ietf.org] On Behalf Of Iljitsch van Beijnum > Sent: Tuesday, April 05, 2011 1:33 PM > To: Joe Touch > Cc: Internet Area > Subject: Re: [Int-area] Recycle IPv4 bits >=20 > Hi Joe, >=20 > On 5 apr 2011, at 20:47, Joe Touch wrote: >=20 > >> I assume this is in the spirit of the date of your message. >=20 > > I'll remember to avoid email altogether next Apr 1. >=20 > :-) >=20 > >> Don't forget that with IPv4, > >> unlike with IPv6, fragmentation at the source based on too=20 > big messages > >> is not performed, only resegmentation in the case of TCP. >=20 > > RFC792 says that fragmentation needed ICMPs are sent back=20 > to the originating source, and cites RFC791. Note - it does=20 > NOT cite RFC793. >=20 > You are reading this with today's notion of PMTUD in mind.=20 > For IPv4, "too big" is a subtype of destination unreachable,=20 > which typically doesn't carry the connotation that a=20 > retransmission is useful. (For IPv6 "too big" is no longer=20 > grouped under unreachable.) >=20 > Because IPv4 never had ICMP feedback related fragmentation at=20 > the source (just "whatever fits in the MTU") de facto IPv4=20 > PMTUD only works with TCP because unlike most UDP protocols,=20 > TCP can arbitrarily adjust its packet size without any higher=20 > layer implications. While it is true that some UDP applications have no way to reduce the size of packets they send (and therefore set DF=3D0), I don't think it is possible to say that "PMTUD only works with TCP". Do you know of any surveys showing that PMTUD is broken for other than TCP? Thanks - Fred fred.l.templin@boeing.com=20 > > I'd have to do some checking on what actually happens when=20 > an ICMP too-big is received. I'd be surprised if that isn't=20 > handled in some way, though. >=20 > Prepare to be surprised. Perhaps this is brought into line=20 > with IPv6 in newer implementations recently, but I've never=20 > seen it happen. >=20 > > I'm saying that once a packet is sent with DF=3D0, changing=20 > it to DF=3D1 en-route is dangerous and serves no useful purpose AFAICT. >=20 > Ok, then we agree on that part. >=20 > Iljitsch >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > = From iljitsch@muada.com Wed Apr 6 13:01:25 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086A23A6974 for ; Wed, 6 Apr 2011 13:01:25 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FccFUGjOTqXF for ; Wed, 6 Apr 2011 13:01:24 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id EB96F3A67DA for ; Wed, 6 Apr 2011 13:01:23 -0700 (PDT) Received: from [192.168.0.140] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p36K4gWL089146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Apr 2011 22:04:43 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Wed, 6 Apr 2011 22:02:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <475EC498-BE28-496C-B27A-3CFD88FF1935@muada.com> References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <4D9CA3FB.4050300@isi.edu> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) Cc: Internet Area Subject: [Int-area] The virtues of large buffers, was: Re: draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 20:01:25 -0000 On 6 apr 2011, at 19:46, Mikael Abrahamsson wrote: > I dislike the term "buffer bloat". Large buffers have a point, it's = just that large FIFO buffers are bad. An example, there is little = problem having single TCP session over 100 meg link between proper = routers, get 100 ms latency. I really don't understand why people defend large buffers. There is = really no upside to them save for the case where the system is otherwise = too slow to fill up the pipe. In fact, in big routers they cost a lot of money and use significant = energy. And still C and J put a gigabyte of buffering on some of their = interfaces. In theory some buffering will smoothe out bursts, but in practice TCPs = will just build up standing queues using up all the buffering so bursts = tail drop anyway. Of course all of this applies to FIFO, but that's what's used in the = vast majority of cases as there are no cheap set-and-forget = first-do-no-harm AQMs AFAIK. > Anyhow, my point is that re-ordering happens in real life networks Only a few percent of destinations have a non flow conserving (per = packet) load balancer on the path, and even then you only trigger the = reordering if you send fast enough. But even then, the timing differences between the reordered packets = won't add up to 10+ seconds while the bandwidth is 100s or 1000s of = packets per second. For this to happen you'd need load balancing over = links with 120 second jitter. Not sure how jitter and queue length are = related off the top of my head, but that probably means a standing queue = that's even larger than 120 seconds. At the 500 pps that you need to = fill up 6 Mbps at 1500 bytes per packet, that's an average queue length = of 100k packets or 143 MB to reach a queuing delay of say 200 seconds. = That translates into a utilization of 99.999%. From iljitsch@muada.com Wed Apr 6 13:52:32 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C71F3A6956 for ; Wed, 6 Apr 2011 13:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRHGHcb1rK+D for ; Wed, 6 Apr 2011 13:52:31 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id 7F6AA28C0CF for ; Wed, 6 Apr 2011 13:52:30 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2] ([IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p36KtM1p089411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Apr 2011 22:55:23 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Wed, 6 Apr 2011 22:53:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D94BDA0.60104 02@isi.edu><4D9597D5.90806 04@isi.edu> <4D959E93.4060803@isi.edu><0DA1ADBA-FA8E-4647-B272-77928FACD405@muada.com><4D9B63B2.5060909@isi.edu> <96D1D2C0-4600-4F21-99DB-50A5B7BF5139@muada.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Cc: Internet Area Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 20:52:32 -0000 Hi Fred, On 6 apr 2011, at 19:47, Templin, Fred L wrote: >> de facto IPv4=20 >> PMTUD only works with TCP > While it is true that some UDP applications have no way > to reduce the size of packets they send (and therefore > set DF=3D0), I don't think it is possible to say that > "PMTUD only works with TCP". Do you know of any surveys > showing that PMTUD is broken for other than TCP? Only what I've seen myself. You're right of course that there is no reason why IPv4 can't handle = this at the IP layer like IPv6 does, but it just doesn't happen in = practice. Hence the "de facto" above. It's such a shame that we never got this right. Maybe with IPvA... From Fred.L.Templin@boeing.com Wed Apr 6 17:22:09 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDEE3A6996 for ; Wed, 6 Apr 2011 17:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.352 X-Spam-Level: X-Spam-Status: No, score=-6.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QN600D8ThIrg for ; Wed, 6 Apr 2011 17:22:08 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 1B5BB3A6934 for ; Wed, 6 Apr 2011 17:22:07 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p370Ni1i012404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2011 19:23:47 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p370NiNh013171; Wed, 6 Apr 2011 17:23:44 -0700 (PDT) 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 p370Nhn4013168 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 6 Apr 2011 17:23:44 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Wed, 6 Apr 2011 17:23:43 -0700 From: "Templin, Fred L" To: Iljitsch van Beijnum Date: Wed, 6 Apr 2011 17:23:43 -0700 Thread-Topic: [Int-area] Recycle IPv4 bits Thread-Index: Acv0nMyMB5tcZmjeRYWdkWcVij9H8QAHPx0g Message-ID: References: <4D94BDA0.60104 02@isi.edu><4D9597D5.90806 04@isi.edu><4D959E93.4060803@isi.edu><0DA1ADBA-FA8E-4647-B272-77928FACD405@ muada.com><4D9B63B2.5060909@isi.edu><96D1D2C0-4600-4F21-99DB-50A5B7BF5139@m uada.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Internet Area Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 00:22:09 -0000 Hi Iljitsch,=20 > -----Original Message----- > From: int-area-bounces@ietf.org=20 > [mailto:int-area-bounces@ietf.org] On Behalf Of Iljitsch van Beijnum > Sent: Wednesday, April 06, 2011 1:54 PM > To: Templin, Fred L > Cc: Internet Area > Subject: Re: [Int-area] Recycle IPv4 bits >=20 > Hi Fred, >=20 > On 6 apr 2011, at 19:47, Templin, Fred L wrote: >=20 > >> de facto IPv4=20 > >> PMTUD only works with TCP >=20 > > While it is true that some UDP applications have no way > > to reduce the size of packets they send (and therefore > > set DF=3D0), I don't think it is possible to say that > > "PMTUD only works with TCP". Do you know of any surveys > > showing that PMTUD is broken for other than TCP? >=20 > Only what I've seen myself. >=20 > You're right of course that there is no reason why IPv4 can't=20 > handle this at the IP layer like IPv6 does, but it just=20 > doesn't happen in practice. Hence the "de facto" above. >=20 > It's such a shame that we never got this right. Maybe with IPvA... Any ideas on how we are going to get to 9KB jumbograms everywhere then, or are we just going to punt on that? Thanks - Fred fred.l.templin@boeing.com > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > = From joelja@bogus.com Wed Apr 6 18:27:27 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 885D03A6828 for ; Wed, 6 Apr 2011 18:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.903 X-Spam-Level: X-Spam-Status: No, score=-100.903 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPSfctDEQyUw for ; Wed, 6 Apr 2011 18:27:26 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id D88223A69A8 for ; Wed, 6 Apr 2011 18:27:25 -0700 (PDT) Received: from [64.9.233.35] (user-64-9-233-35.googlewifi.com [64.9.233.35]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p371T7WP087353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Apr 2011 01:29:08 GMT (envelope-from joelja@bogus.com) References: <4D94BDA0.60104 02@isi.edu> <4D9597D5.90806 04@isi.edu> <4D959E93.4060803@isi.edu> <0DA1ADBA-FA8E-4647-B272-77928FACD405@ muada.com> <4D9B63B2.5060909@isi.edu> <96D1D2C0-4600-4F21-99DB-50A5B7BF5139@m uada.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8G4) From: Joel Jaeggli Date: Wed, 6 Apr 2011 18:29:29 -0700 To: "Templin, Fred L" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Thu, 07 Apr 2011 01:29:08 +0000 (UTC) Cc: Internet Area Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 01:27:28 -0000 Joel's widget number 2 On Apr 6, 2011, at 17:23, "Templin, Fred L" wrot= e: > Hi Iljitsch,=20 >=20 >> -----Original Message----- >> From: int-area-bounces@ietf.org=20 >> [mailto:int-area-bounces@ietf.org] On Behalf Of Iljitsch van Beijnum >> Sent: Wednesday, April 06, 2011 1:54 PM >> To: Templin, Fred L >> Cc: Internet Area >> Subject: Re: [Int-area] Recycle IPv4 bits >>=20 >> Hi Fred, >>=20 >> On 6 apr 2011, at 19:47, Templin, Fred L wrote: >>=20 >>>> de facto IPv4=20 >>>> PMTUD only works with TCP >>=20 >>> While it is true that some UDP applications have no way >>> to reduce the size of packets they send (and therefore >>> set DF=3D0), I don't think it is possible to say that >>> "PMTUD only works with TCP". Do you know of any surveys >>> showing that PMTUD is broken for other than TCP? >>=20 >> Only what I've seen myself. >>=20 >> You're right of course that there is no reason why IPv4 can't=20 >> handle this at the IP layer like IPv6 does, but it just=20 >> doesn't happen in practice. Hence the "de facto" above. >>=20 >> It's such a shame that we never got this right. Maybe with IPvA... >=20 > Any ideas on how we are going to get to 9KB jumbograms > everywhere then, or are we just going to punt on that? Still need pmtud when you have jumbo frames support because you don't know h= ow many encapsulations there are on the wire.=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >>=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20 From xiaohong.deng@orange-ftgroup.com Wed Apr 6 21:10:30 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9D928C101; Wed, 6 Apr 2011 21:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[AWL=-1.416, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S3u90z+2wRy; Wed, 6 Apr 2011 21:10:29 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 1AE5028B797; Wed, 6 Apr 2011 21:10:28 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 162D96C8003; Thu, 7 Apr 2011 06:12:45 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 018756C0001; Thu, 7 Apr 2011 06:12:44 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 06:12:10 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF4D9.F48D2DE8" Date: Thu, 7 Apr 2011 12:12:05 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC01685247@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Int-area] Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments Thread-Index: Acv0dqpjDSVsZIxJQe6Yllay01rTEgAXyLQg References: <0962B0BEF842A24191AD9BE41A8DD2FC016850B4@ch-mailsrv.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 07 Apr 2011 04:12:10.0454 (UTC) FILETIME=[F750CF60:01CBF4D9] Cc: softwires-request@ietf.org, behave@ietf.org, int-area@ietf.org Subject: Re: [Int-area] Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 04:10:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF4D9.F48D2DE8 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable We have tested how applications behave when it has both DS-Lite IPv4 and = NAT64 IPv6 (but not native IPv6). Firefox, IE, Skype, Google Earth = v5.2.1, Live Messenger, uTorrent, BitComet, were on our test list.=20 =20 Despres,regarding your question ( maybe not answering your question = exactly as we tested NAT64 IPv6 instead of native IPv6 ), uTorrent v2.2 = used IPv6 for login/authentication but IPv4 for the data exchange, for = IPv6 peer was not able to talk to IPv4 peer. Although BitComet v1.23 = issued both A and AAAA quires, it completely ignored AAAA RR and only = used IPv4 for communication. =20 Please also see some of other test results below. DS-Lite/NAT64 = experiments could be documented if it is of interests.=20 =20 Tested Apps IPv4/IPv6 portion Firefox (Non-vedio) v3.6.12 All IPv6 =20 video website Half/ half =20 IE (Non-vedio) v6.0 All IPv6 =20 Skype v5.0 Major IPv6 =20 Google Earth v5.2.1 Major IPv6 =20 Live Messenger 2009 Major IPv4 =20 uTorrent v2.2 Major IPv4 =20 BitComet v1.23 All IPv4 =20 =20 BR, Xiaohong opensource A+P: http://opensourceaplusp.weebly.com/ =20 ________________________________ =B7=A2=BC=FE=C8=CB: R=A8=A6mi Despr=A8=A6s = [mailto:remi.despres@free.fr]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C27=C8=D5 0:21 =CA=D5=BC=FE=C8=CB: DENG Xiaohong ESP/PEK =B3=AD=CB=CD: int-area@ietf.org =D6=F7=CC=E2: Re: [Int-area] Stateless IPv4-in-IPv6 experiments =09 =09 Thank you, Xiahong, for sharing this interesting information.=20 In the case of BitComet and uTorrent, I wonder what happens if the host = has both A+P IPv4 and IPv6, as opposed to just A+P IPv4. Did you try that? Regards, RD Le 6 avr. 2011 =A8=A4 10:57, = a =A8=A6crit : Dear all, =20 An I-D about stateless IPv4-in-IPv6 experiments has been submitted. A = URL for this Internet-Draft is: = http://tools.ietf.org/html/draft-deng-aplusp-experiment-results-00 = . =20 A website introducing the detail of experiment results is also = accessible via: http://opensourceaplusp.weebly.com/ = =20 =20 BR, Xiaohong _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area =09 ------_=_NextPart_001_01CBF4D9.F48D2DE8 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

We=20 have=20 tested=20 how applications behave when it has both DS-Lite=20 IPv4=20 and NAT64 IPv6 (but not native IPv6).=20 Firefox,=20 IE, Skype, Google Earth v5.2.1, Live Messenger, uTorrent, = BitComet,=20 were on our test list. 

 

Despres,regarding your=20 question (=20 maybe not answering your question exactly as we tested NAT64=20 IPv6 instead of native IPv6 ), uTorrent v2.2 used IPv6 for=20 login/authentication but IPv4 for the data exchange, for IPv6 peer was = not able=20 to talk to IPv4 peer. Although BitComet v1.23 issued both A and AAAA = quires, it=20 completely ignored AAAA RR and only used IPv4 for=20 communication.

 

Please also see some of other test results below. DS-Lite/NAT64 experiments could be = documented if it is=20 of interests.

 

Tested Apps                   IPv4/IPv6 = portion

Firefox (Non-vedio) v3.6.12   All IPv6           &nbs= p;            = ;    =20

video website           &nbs= p;    =20 Half/ half          =20  

IE (Non-vedio) v6.0  =20      =    All IPv6           &nbs= p;            = ;   =20

Skype v5.0           =20        =20 Major IPv6          =20             &nbs= p; =20

Google Earth v5.2.1          =20 Major IPv6           &n= bsp; =20      =20

Live Messenger 2009          =20 Major IPv4           =20

uTorrent v2.2           &nbs= p;    =20 Major IPv4    =20

BitComet v1.23           &nbs= p;   =20 All IPv4      =20

 

BR,

Xiaohong

opensource A+P: http://opensourceaplusp.weeb= ly.com/

 

=B7=A2=BC=FE=C8=CB: = R=A8=A6mi Despr=A8=A6s [mailto:remi.despres@free.fr]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C27=C8=D5 = 0:21
=CA=D5=BC=FE=C8=CB: DENG Xiaohong=20 ESP/PEK
=B3=AD=CB=CD: = int-area@ietf.org
=D6=F7=CC=E2: Re: [Int-area] Stateless=20 IPv4-in-IPv6 experiments

Thank you, Xiahong, for sharing this interesting = information.

In the case of BitComet and uTorrent, I wonder what happens if = the host=20 has both A+P IPv4 and IPv6, as opposed to just A+P IPv4.
Did you try that?

Regards,
RD

Le 6 avr. 2011 =A8=A4 10:57, <xiaohong.deng@orange-ftg= roup.com>=20 <xiaohong.deng@orange-ftg= roup.com>=20 a =A8=A6crit :

Dear=20 all,
 
An I-D about stateless = IPv4-in-IPv6 experiments has been submitted.=20 A URL = for this=20 Internet-Draft is: http://tools.ietf.org/html/draft-deng-aplusp-experiment-r= esults-00.
 
A website=20 introducing the detail of experiment results is also accessible = via: http://opensourceaplusp.weebly.com/
 
BR,
Xiaohong
______________________________= _________________
Int-area=20 mailing list
Int-area@ietf.org
https://www.ie= tf.org/mailman/listinfo/int-area

------_=_NextPart_001_01CBF4D9.F48D2DE8-- From swmike@swm.pp.se Wed Apr 6 22:22:21 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8723A6837 for ; Wed, 6 Apr 2011 22:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxLRN5mN5WnV for ; Wed, 6 Apr 2011 22:22:17 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 564793A69AA for ; Wed, 6 Apr 2011 22:22:17 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EB1919E; Thu, 7 Apr 2011 07:24:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E9C129A; Thu, 7 Apr 2011 07:24:00 +0200 (CEST) Date: Thu, 7 Apr 2011 07:24:00 +0200 (CEST) From: Mikael Abrahamsson To: Iljitsch van Beijnum In-Reply-To: <475EC498-BE28-496C-B27A-3CFD88FF1935@muada.com> Message-ID: References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <4D9CA3FB.4050300@isi.edu> <475EC498-BE28-496C-B27A-3CFD88FF1935@muada.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Internet Area Subject: Re: [Int-area] The virtues of large buffers, was: Re: draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 05:22:21 -0000 On Wed, 6 Apr 2011, Iljitsch van Beijnum wrote: > I really don't understand why people defend large buffers. There is > really no upside to them save for the case where the system is otherwise > too slow to fill up the pipe. Yes there is, if you have long fat pipes. It can be argued that it's much less needed now, when core routers have 10G and up, which is what router vendors are responding to, newer routers have 50ms buffer instead of 600ms they had 10 years ago. TCP (file transfer) responds better to delayed packets than to lost packets. > In fact, in big routers they cost a lot of money and use significant > energy. And still C and J put a gigabyte of buffering on some of their > interfaces. At 40G speed, that's 250ms. There are applications that would rather have their packet delayed 100ms but get it delivered, and there are other applications who would rather like packet loss but almost no jitter. The hard part is to make a network that caters well to both without having to keep flow state. > In theory some buffering will smoothe out bursts, but in practice TCPs > will just build up standing queues using up all the buffering so bursts > tail drop anyway. Depends on speed, but you're basically right. > Of course all of this applies to FIFO, but that's what's used in the > vast majority of cases as there are no cheap set-and-forget > first-do-no-harm AQMs AFAIK. I agree. >> Anyhow, my point is that re-ordering happens in real life networks > > Only a few percent of destinations have a non flow conserving (per > packet) load balancer on the path, and even then you only trigger the > reordering if you send fast enough. I've seen it on 5 megabit/s video streams. > But even then, the timing differences between the reordered packets > won't add up to 10+ seconds while the bandwidth is 100s or 1000s of > packets per second. It's definitely a corner case, I agree. -- Mikael Abrahamsson email: swmike@swm.pp.se From remi.despres@free.fr Thu Apr 7 00:09:49 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117C728C0D9; Thu, 7 Apr 2011 00:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0QxDCvKbLO9; Thu, 7 Apr 2011 00:09:47 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by core3.amsl.com (Postfix) with ESMTP id 10B013A688B; Thu, 7 Apr 2011 00:09:47 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id 0C2897000092; Thu, 7 Apr 2011 09:11:31 +0200 (CEST) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id 7DD827000087; Thu, 7 Apr 2011 09:11:30 +0200 (CEST) X-SFR-UUID: 20110407071130515.7DD827000087@msfrf2221.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-28--416943308 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC01685247@ch-mailsrv.rd.francetelecom.fr> Date: Thu, 7 Apr 2011 09:11:27 +0200 Message-Id: References: <0962B0BEF842A24191AD9BE41A8DD2FC016850B4@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC01685247@ch-mailsrv.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: softwires-request@ietf.org, behave@ietf.org, int-area@ietf.org Subject: Re: [Int-area] Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 07:09:49 -0000 --Apple-Mail-28--416943308 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 7 avr. 2011 =C3=A0 06:12, = a =C3=A9crit : > We have tested how applications behave when it has both DS-Lite IPv4 = and NAT64 IPv6 (but not native IPv6). Firefox, IE, Skype, Google Earth = v5.2.1, Live Messenger, uTorrent, BitComet, were on our test list.=20 > =20 > Despres,regarding your question ( maybe not answering your question = exactly as we tested NAT64 IPv6 instead of native IPv6 ), uTorrent v2.2 = used IPv6 for login/authentication but IPv4 for the data exchange, for = IPv6 peer was not able to talk to IPv4 peer. Although BitComet v1.23 = issued both A and AAAA quires, it completely ignored AAAA RR and only = used IPv4 for communication. Thank you. > =20 > Please also see some of other test results below. DS-Lite/NAT64 = experiments could be documented if it is of interests. If you can share your results, that's always useful information. Accordingly, if someone has results concerning native IPv6 (e2e = transparent, i.e. without NAT64) plus statelessly tunneled IPv4, that = would be nice to have. Regards, RD > =20 > Tested Apps IPv4/IPv6 portion > Firefox (Non-vedio) v3.6.12 All IPv6 =20 > video website Half/ half =20 > IE (Non-vedio) v6.0 All IPv6 =20 > Skype v5.0 Major IPv6 =20 > Google Earth v5.2.1 Major IPv6 =20 > Live Messenger 2009 Major IPv4 =20 > uTorrent v2.2 Major IPv4 =20 > BitComet v1.23 All IPv4 =20 > =20 > BR, > Xiaohong > opensource A+P: http://opensourceaplusp.weebly.com/ > =20 >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: R=C3=A9mi Despr=C3=A9s = [mailto:remi.despres@free.fr]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B44=E6=9C=887=E6=97=A5 = 0:21 > =E6=94=B6=E4=BB=B6=E4=BA=BA: DENG Xiaohong ESP/PEK > =E6=8A=84=E9=80=81: int-area@ietf.org > =E4=B8=BB=E9=A2=98: Re: [Int-area] Stateless IPv4-in-IPv6 experiments >=20 > Thank you, Xiahong, for sharing this interesting information. >=20 > In the case of BitComet and uTorrent, I wonder what happens if the = host has both A+P IPv4 and IPv6, as opposed to just A+P IPv4. > Did you try that? >=20 > Regards, > RD >=20 > Le 6 avr. 2011 =C3=A0 10:57, = a =C3=A9crit : >=20 >> Dear all, >> =20 >> An I-D about stateless IPv4-in-IPv6 experiments has been submitted. A = URL for this Internet-Draft is: = http://tools.ietf.org/html/draft-deng-aplusp-experiment-results-00. >> =20 >> A website introducing the detail of experiment results is also = accessible via: http://opensourceaplusp.weebly.com/ >> =20 >> BR, >> Xiaohong >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >=20 --Apple-Mail-28--416943308 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 xiaohong.deng@orange-ftgr= oup.com> <xiaohong.deng@orange-ftgr= oup.com> a =C3=A9crit :
We=20 have=20 tested=20 how applications behave when it has both DS-Lite=20 IPv4=20 and NAT64 IPv6 (but not native IPv6).=20 Firefox,=20 IE, Skype, Google Earth v5.2.1, Live Messenger, uTorrent, = BitComet,=20 were on our test list. 
 
Despres,regarding your=20 question (=20 maybe not answering your question exactly as we tested NAT64=20= IPv6 instead of native IPv6 ), uTorrent v2.2 used IPv6 for=20= login/authentication but IPv4 for the data exchange, for IPv6 peer was = not able=20 to talk to IPv4 peer. Although BitComet v1.23 issued both A and AAAA = quires, it=20 completely ignored AAAA RR and only used IPv4 for=20 = communication.

Thank you.

 
Please also see some of = other test results below. = DS-Lite/NAT64 experiments could be documented if it is=20 of interests. =

If you can share your results, that's always useful = information.
Accordingly, if someone has results concerning = native IPv6 (e2e transparent, i.e. without NAT64) plus statelessly = tunneled IPv4, that would be nice to = have.

Regards,
RD

<= div>
 
Tested Apps                   IPv4/IPv6 = portion
Firefox = (Non-vedio) v3.6.12   = All IPv6            = ;            &= nbsp;   =20
video = website            = ;    =20 Half/ half          =20  
IE = (Non-vedio) v6.0  =20      =    All IPv6            = ;            &= nbsp;  =20
Skype = v5.0           =20        =20 Major IPv6          =20              = ; =20
Google = Earth v5.2.1          =20 Major IPv6           &nb= sp; =20      =20
Live = Messenger 2009          =20 Major IPv4           =20
uTorrent= v2.2            = ;    =20 Major IPv4    =20
BitComet = v1.23            = ;   =20 All IPv4      =20

 

BR,
Xiaohong
 

=E5=8F=91=E4=BB=B6=E4=BA= =BA: R=C3=A9mi Despr=C3=A9s [mailto:remi.despres@free.fr]=20
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B44=E6=9C=88= 7=E6=97=A5 0:21
=E6=94=B6=E4=BB=B6=E4=BA=BA: DENG Xiaohong=20 ESP/PEK
=E6=8A=84=E9=80=81: int-area@ietf.org
=E4=B8=BB=E9= =A2=98: Re: [Int-area] Stateless=20 IPv4-in-IPv6 experiments

Thank you, Xiahong, for sharing this interesting = information.

In the case of BitComet and uTorrent, I wonder what happens if = the host=20 has both A+P IPv4 and IPv6, as opposed to just A+P IPv4.
Did you try that?

Regards,
RD

Le 6 avr. 2011 =C3=A0 10:57, <xiaohong.deng@orange-ftgr= oup.com>=20 <xiaohong.deng@orange-ftgr= oup.com>=20 a =C3=A9crit :

Dear=20 all,
 
An I-D about = stateless IPv4-in-IPv6 = experiments has been submitted.=20 A URL for this=20 Internet-Draft is: http://tools.ietf.org/html/draft-deng-aplusp-experiment-= results-00.
 
A website=20 introducing the detail of experiment results is also accessible = via: http://opensourceaplusp.weebly.com/
 
BR,
Xiaohong
_____________________________= __________________
Int-area=20 mailing list
Int-area@ietf.org
https://www.ietf.o= rg/mailman/listinfo/int-area


= --Apple-Mail-28--416943308-- From iljitsch@muada.com Thu Apr 7 01:12:18 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E7428C11F for ; Thu, 7 Apr 2011 01:12:18 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vY3e73IYmAnr for ; Thu, 7 Apr 2011 01:12:17 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id 7099E28C108 for ; Thu, 7 Apr 2011 01:12:17 -0700 (PDT) Received: from claw.it.uc3m.es ([163.117.139.50]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p378FV4A092390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Apr 2011 10:15:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4D9CA28D.3060801@isi.edu> Date: Thu, 7 Apr 2011 10:13:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2F38F3E4-8049-4EAE-9517-BBC55FE1568E@muada.com> References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <221640FE-611C-4885-9BA9-44798F147D85@muada.com> <4D9CA28D.3060801@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: Internet Area Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 08:12:18 -0000 Hi Joe, On 6 apr 2011, at 19:27, Joe Touch wrote: >> BTW, I'm not seeing the disasters he's describing, I only get 6 or 12 >> ms extra delay doing 100 Mbps transfers locally. > Not everyone does. It depends on what OS you do the test from, which = local router (DSL box, etc.) you're using, etc. I should have mentioned that is between two Macs, one running 10.5 and = one 10.6, with an Apple base station in the middle. From iljitsch@muada.com Thu Apr 7 01:33:37 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12EEB3A69E7 for ; Thu, 7 Apr 2011 01:33:37 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZUiaBjBbcg4 for ; Thu, 7 Apr 2011 01:33:36 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id AF5C23A6961 for ; Thu, 7 Apr 2011 01:33:35 -0700 (PDT) Received: from claw.it.uc3m.es ([163.117.139.50]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p378aqgu092520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Apr 2011 10:36:53 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Thu, 7 Apr 2011 10:34:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8D29AD71-9327-4890-929B-DC7B3AC23438@muada.com> References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <4D9CA3FB.4050300@isi.edu> <475EC498-BE28-496C-B27A-3CFD88FF1935@muada.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) Cc: Internet Area Subject: Re: [Int-area] The virtues of large buffers, was: Re: draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 08:33:37 -0000 On 7 apr 2011, at 7:24, Mikael Abrahamsson wrote: >> I really don't understand why people defend large buffers. There is = really no upside to them save for the case where the system is otherwise = too slow to fill up the pipe. > Yes there is, if you have long fat pipes. They don't need big buffers. Maybe today's TCP implementations can't = 95%+ throughput without them, but if that's the case, then either the = hardware is underpowered or the implementation is suboptimal. Until a few years ago, nobody really used the window scale option = because the default maximum send and receive buffers in widely used OSes = were very limited. In those days, it paid to have so much buffering that = the maximum window size became the bottleneck in a transfer, because = that way there are no drops and TCP uses the maximum bandwidth. But today common OSes will use very large windows as the RTT increases = but the larger the windows the larger the standing queues and hence the = RTT. This hurts traffic that isn't unlimited file transfer competing for = access and even hurts those file transfers themselves because when drops = happen now, they get so severe that normal fast retransmit can't handle = it, timeouts are necessary and a lot of packets have to be = retransmitted. Now compare this with the situation where the buffers are small. Drops = then happen regularly. This probably means you don't get to use 99% of = the bandwidth of a long RTT link/path for a single transfer because of = the TCP sawtoothing, but it works much, much better for a mix of = traffic. And it's still possible to reach that 99% by modifying TCP = implementations so that they tune their window to the bandwidth-delay = product so they avoid overlading links and depend on self clocking = rather than losses to adjust their transmission rate. > It can be argued that it's much less needed now, when core routers = have 10G and up, which is what router vendors are responding to, newer = routers have 50ms buffer instead of 600ms they had 10 years ago. Still way too much. > TCP (file transfer) responds better to delayed packets than to lost = packets. But that's optimizing for that one use case where you send a lot of data = at a rate that saturizes the core of the network. Most people have a = local bottleneck so they don't need buffering in the core (whether they = need it locally is something they should have the opportunity to decide = for themselves) and most applications aren't bulk transfers and most = bulk transfers don't have higher priority than interactive traffic. > There are applications that would rather have their packet delayed = 100ms but get it delivered, and there are other applications who would = rather like packet loss but almost no jitter. > The hard part is to make a network that caters well to both without = having to keep flow state. Like I said, the cases where lots of buffering is helpful are few and = far between, it's a waste of time to even consider that in general = purpose networks. >> But even then, the timing differences between the reordered packets = won't add up to 10+ seconds while the bandwidth is 100s or 1000s of = packets per second. > It's definitely a corner case, I agree. No, it's not. It's not even a loch ness monster case: nobody has even = claims to have observed this, people just think "10 seconds can happen" = and "reordering can happen" so "reordering at 10 second timescales can = happen". Not valid logic. From iljitsch@muada.com Thu Apr 7 01:38:13 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F6C3A67F3 for ; Thu, 7 Apr 2011 01:38:13 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3zRTYyH6xjn for ; Thu, 7 Apr 2011 01:38:10 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id 27F323A6952 for ; Thu, 7 Apr 2011 01:38:09 -0700 (PDT) Received: from claw.it.uc3m.es ([163.117.139.50]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p378fNAV092551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Apr 2011 10:41:24 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Thu, 7 Apr 2011 10:39:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9E649DBD-38EF-4E29-BDCB-B61F794CEF0A@muada.com> References: <4D94BDA0.60104 02@isi.edu><4D9597D5.90806 04@isi.edu><4D959E93.4060803@isi.edu><0DA1ADBA-FA8E-4647-B272-77928FACD405@ muada.com><4D9B63B2.5060909@isi.edu><96D1D2C0-4600-4F21-99DB-50A5B7BF5139@m uada.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Cc: Internet Area Subject: Re: [Int-area] Recycle IPv4 bits X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 08:38:13 -0000 Hi Fred, On 7 apr 2011, at 2:23, Templin, Fred L wrote: >> It's such a shame that we never got this right. Maybe with IPvA... > Any ideas on how we are going to get to 9KB jumbograms > everywhere then, or are we just going to punt on that? Thanks for the setup. Obviously there will be stuff out there that is limited to 1500 or 1280 = bytes for a long, long time. But hopefully there will also be stuff that = can do more than 9k. We shouldn't start an effort to upgrade the whole = internet to 9k because then that will be just as unpleasant a limitation = as 1500 is today, what we need is a way for nodes with different MTUs to = live together on the same subnet. Then, the ones that support 9k or more = can use that packet size between them without leaving the nodes with = lesser capabilities in the cold. My draft has mechanisms to accomplish = that: http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-03 From swmike@swm.pp.se Thu Apr 7 04:11:48 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3EF28C0DF for ; Thu, 7 Apr 2011 04:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vfz-t7tXbwIB for ; Thu, 7 Apr 2011 04:11:47 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 96B353A68FC for ; Thu, 7 Apr 2011 04:11:47 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D7E269C; Thu, 7 Apr 2011 13:13:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D345A9A; Thu, 7 Apr 2011 13:13:27 +0200 (CEST) Date: Thu, 7 Apr 2011 13:13:27 +0200 (CEST) From: Mikael Abrahamsson To: Iljitsch van Beijnum In-Reply-To: <8D29AD71-9327-4890-929B-DC7B3AC23438@muada.com> Message-ID: References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <4D9CA3FB.4050300@isi.edu> <475EC498-BE28-496C-B27A-3CFD88FF1935@muada.com> <8D29AD71-9327-4890-929B-DC7B3AC23438@muada.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Internet Area Subject: Re: [Int-area] The virtues of large buffers, was: Re: draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 11:11:48 -0000 On Thu, 7 Apr 2011, Iljitsch van Beijnum wrote: > Like I said, the cases where lots of buffering is helpful are few and > far between, it's a waste of time to even consider that in general > purpose networks. I have been advocating this to the people in CONEX, but they seem to think ECN is a worthwhile tool. I see little use for ECN without buffering and RED. So "someone" needs to decide how we want the Internet to work. The "bufferbloat" people want small buffers generally. People who learnt about TCP long ago, want long-fat-pipes to work well, thus lots of buffers. So what do we do? Right now we have both, there are seconds worth of FIFO buffering on some links, on other links there are 2-4ms worth of FIFO buffering, on some there are seconds worth of buffering, but it's per-flow (cisco fair-queue). Doing a general recommendation of "never buffer more than 10ms" is a quite strong recommendation that needs to be backed up by, and agreed by quite a lot of people from different parts of the IETF. >>> But even then, the timing differences between the reordered packets >>> won't add up to 10+ seconds while the bandwidth is 100s or 1000s of >>> packets per second. > >> It's definitely a corner case, I agree. > > No, it's not. It's not even a loch ness monster case: nobody has even > claims to have observed this, people just think "10 seconds can happen" > and "reordering can happen" so "reordering at 10 second timescales can > happen". Not valid logic. Well, if I load-share per-packet over two tunnels traversing a radio network, I can make this happen. Would I want to? No. -- Mikael Abrahamsson email: swmike@swm.pp.se From iljitsch@muada.com Thu Apr 7 08:47:01 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEAFB28C0D7 for ; Thu, 7 Apr 2011 08:47:01 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJesOZ-tGOYM for ; Thu, 7 Apr 2011 08:47:01 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id C377A3A69CA for ; Thu, 7 Apr 2011 08:47:00 -0700 (PDT) Received: from claw.it.uc3m.es ([163.117.139.50]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p37FoHQO094568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Apr 2011 17:50:18 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Thu, 7 Apr 2011 17:48:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <4D9CA3FB.4050300@isi.edu> <475EC498-BE28-496C-B27A-3CFD88FF1935@muada.com> <8D29AD71-9327-4890-929B-DC7B3AC23438@muada.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) Cc: Internet Area Subject: Re: [Int-area] The virtues of large buffers, was: Re: draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 15:47:01 -0000 On 7 apr 2011, at 13:13, Mikael Abrahamsson wrote: > I see little use for ECN without buffering and RED. Agree. (Or some other AQM where packets would be dropped while buffer = space is still available.) > So "someone" needs to decide how we want the Internet to work. The = "bufferbloat" people want small buffers generally. People who learnt = about TCP long ago, want long-fat-pipes to work well, thus lots of = buffers. > So what do we do? Right now we have both, We can in fact accommodate both philosophies: by creating two service = classes. The only tricky part there is how to make sure that resources = are evenly split between them, such that it doesn't pay for the long = delay people to select the low delay service class. More service classes could benefit the long fat pipe people a lot, = because even though they are the ones that want / can stand large = buffers, they are not getting their needs met today either, because they = can't ramp up their transmission rate fast enough to get good = utilization without being unfair to other traffic. This could be solved = by moving to a low priority service class with small buffers but with = aggressive transmission that ignores high packet loss. > Doing a general recommendation of "never buffer more than 10ms" is a = quite strong recommendation that needs to be backed up by, and agreed by = quite a lot of people from different parts of the IETF. I'm all for that. But a discussion about this on the HOMEGATE list a = year (or two?) ago didn't go anywhere. > Well, if I load-share per-packet over two tunnels traversing a radio = network, I can make this happen. Would I want to? No. You would need to load balance over multiple links, where one has a 120 = second queue and the other doesn't. Seems to me if you have two links = where one has 120 seconds more queuing delay than the other, you can = probably live without that second link just fine.= From touch@isi.edu Thu Apr 7 09:05:04 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55A828C0DB for ; Thu, 7 Apr 2011 09:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.436 X-Spam-Level: X-Spam-Status: No, score=-103.436 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxANLOuRuf1B for ; Thu, 7 Apr 2011 09:05:02 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 63FFF3A67FB for ; Thu, 7 Apr 2011 09:05:02 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p37G5w8n028712 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 7 Apr 2011 09:06:08 -0700 (PDT) Message-ID: <4D9DE0E6.4080502@isi.edu> Date: Thu, 07 Apr 2011 09:05:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <221640FE-611C-4885-9BA9-44798F147D85@muada.com> <4D9CA28D.3060801@isi.edu> <2F38F3E4-8049-4EAE-9517-BBC55FE1568E@muada.com> In-Reply-To: <2F38F3E4-8049-4EAE-9517-BBC55FE1568E@muada.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: Internet Area Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 16:05:04 -0000 On 4/7/2011 1:13 AM, Iljitsch van Beijnum wrote: > Hi Joe, > > On 6 apr 2011, at 19:27, Joe Touch wrote: > >>> BTW, I'm not seeing the disasters he's describing, I only get 6 or 12 >>> ms extra delay doing 100 Mbps transfers locally. > >> Not everyone does. It depends on what OS you do the test from, which local router (DSL box, etc.) you're using, etc. > > I should have mentioned that is between two Macs, one running 10.5 and one 10.6, with an Apple base station in the middle. That's not the scenario that shows bloat; you need to use a constrained uplink (e.g., DSL or home cable router), and the goal is: - from a home PC, upload a large file to a server upstream of the bottleneck - from another home PC, ping somewhere upstream of the bottleneck The issue doesn't come up if there's no persistent bottleneck. Joe From iljitsch@muada.com Thu Apr 7 10:45:00 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70553A694F for ; Thu, 7 Apr 2011 10:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJTKt-CaH9pd for ; Thu, 7 Apr 2011 10:45:00 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id 83AAF3A68EA for ; Thu, 7 Apr 2011 10:44:59 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2] ([IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p37HmE6h095375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Apr 2011 19:48:15 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4D9DE0E6.4080502@isi.edu> Date: Thu, 7 Apr 2011 18:40:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <221640FE-611C-4885-9BA9-44798F147D85@muada.com> <4D9CA28D.3060801@isi.edu> <2F38F3E4-8049-4EAE-9517-BBC55FE1568E@muada.com> <4D9DE0E6.4080502@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: Internet Area Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:45:01 -0000 On 7 apr 2011, at 18:05, Joe Touch wrote: >> I should have mentioned that is between two Macs, one running 10.5 = and one 10.6, with an Apple base station in the middle. > That's not the scenario that shows bloat; you need to use a = constrained uplink (e.g., DSL or home cable router), > The issue doesn't come up if there's no persistent bottleneck. No, Jim Gettys also talks about 100 Mbps: = http://gettys.wordpress.com/2010/11/29/home-router-puzzle-piece-one-fun-wi= th-your-switch/ Unfortunately conciseness and easy navigation aren't his strong suits so = I can't find the results he got for this test right now, but it was 200 = ms unless I'm mistaken. Of course the difference between this case and the case where the = bottleneck isn't the first hop is very different: here, local buffers = are a problem, which you should be able to tune locally. In the middle = of the network it's a separate device that you presumably have less = control over. From touch@isi.edu Thu Apr 7 10:52:03 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358D93A6959 for ; Thu, 7 Apr 2011 10:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp65YeTRXpXY for ; Thu, 7 Apr 2011 10:51:59 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 2AC123A694F for ; Thu, 7 Apr 2011 10:51:59 -0700 (PDT) Received: from [10.111.18.116] (166-205-138-048.mobile.mymmode.com [166.205.138.48] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p37Hqw3q018829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Apr 2011 10:53:11 -0700 (PDT) References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <221640FE-611C-4885-9BA9-44798F147D85@muada.com> <4D9CA28D.3060801@isi.edu> <2F38F3E4-8049-4EAE-9517-BBC55FE1568E@muada.com> <4D9DE0E6.4080502@isi.edu> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8G4) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8G4) From: Joe Touch Date: Thu, 7 Apr 2011 10:52:52 -0700 To: Iljitsch van Beijnum X-MailScanner-ID: p37Hqw3q018829 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Internet Area Subject: Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:52:03 -0000 On Apr 7, 2011, at 9:40 AM, Iljitsch van Beijnum wrote:= > On 7 apr 2011, at 18:05, Joe Touch wrote: >=20 >>> I should have mentioned that is between two Macs, one running 10.5 and o= ne 10.6, with an Apple base station in the middle. >=20 >> That's not the scenario that shows bloat; you need to use a constrained u= plink (e.g., DSL or home cable router), >=20 >> The issue doesn't come up if there's no persistent bottleneck. >=20 > No, Jim Gettys also talks about 100 Mbps: He has talked about a lot of things :-). If you can, test with a home uplink= .=20 The bufferscan sometes be tuned (on some devices) but you need to tune all d= evices on the path to know upu can avoid the issue, and that's rarely feasib= le.=20 Joe >=20 > http://gettys.wordpress.com/2010/11/29/home-router-puzzle-piece-one-fun-wi= th-your-switch/ >=20 > Unfortunately conciseness and easy navigation aren't his strong suits so I= can't find the results he got for this test right now, but it was 200 ms un= less I'm mistaken. >=20 > Of course the difference between this case and the case where the bottlene= ck isn't the first hop is very different: here, local buffers are a problem,= which you should be able to tune locally. In the middle of the network it's= a separate device that you presumably have less control over. >=20 From roland.bless@kit.edu Fri Apr 8 08:06:02 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C6D3A681F for ; Fri, 8 Apr 2011 08:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.323 X-Spam-Level: X-Spam-Status: No, score=-6.323 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sCnZ9Iu2aqX for ; Fri, 8 Apr 2011 08:06:01 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 817E03A6819 for ; Fri, 8 Apr 2011 08:06:01 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1Q8DHc-0004Zm-JY; Fri, 08 Apr 2011 17:07:43 +0200 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 id 1Q8DHc-0003FY-FX; Fri, 08 Apr 2011 17:07:36 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 568BC78E1; Fri, 8 Apr 2011 17:07:36 +0200 (CEST) Message-ID: <4D9F24B8.7010807@kit.edu> Date: Fri, 08 Apr 2011 17:07:36 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Mikael Abrahamsson References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <4D9CA3FB.4050300@isi.edu> <475EC498-BE28-496C-B27A-3CFD88FF1935@muada.com> <8D29AD71-9327-4890-929B-DC7B3AC23438@muada.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1302275264.075505000 Cc: Internet Area Subject: Re: [Int-area] The virtues of large buffers, was: Re: draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:06:02 -0000 Hi, Am 07.04.2011 13:13, schrieb Mikael Abrahamsson: > So "someone" needs to decide how we want the Internet to work. The > "bufferbloat" people want small buffers generally. People who learnt > about TCP long ago, want long-fat-pipes to work well, thus lots of buffers. I'm not sure what you exactly mean by long-fat-pipes here. Do you mean a path with a large bandwith-delay product? In this case you need lots of buffers, but mainly in the TCP implementation, not in the network. For large bandwidth delay product connections the inflight packets are mainly "stored" on the wire, not in the router buffers, aren't they? The BDP rule-of-thumb for buffer sizes appears strange to me anyways. IMHO, smaller buffers with AQM and ECN are probably a really good thing since dropping fairness can be achieved and flows get once a while packets through to probe for bandwidth and to control their sending speed. Large buffers don't help either if you've got long-term congestion... Regards, Roland From swmike@swm.pp.se Fri Apr 8 13:55:39 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30A4C3A6980 for ; Fri, 8 Apr 2011 13:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48fJ1w9lquSu for ; Fri, 8 Apr 2011 13:55:38 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 70C7B3A69CF for ; Fri, 8 Apr 2011 13:55:38 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3F38E9C; Fri, 8 Apr 2011 22:57:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3CE529A; Fri, 8 Apr 2011 22:57:22 +0200 (CEST) Date: Fri, 8 Apr 2011 22:57:22 +0200 (CEST) From: Mikael Abrahamsson To: Roland Bless In-Reply-To: <4D9F24B8.7010807@kit.edu> Message-ID: References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <4D9CA3FB.4050300@isi.edu> <475EC498-BE28-496C-B27A-3CFD88FF1935@muada.com> <8D29AD71-9327-4890-929B-DC7B3AC23438@muada.com> <4D9F24B8.7010807@kit.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Internet Area Subject: Re: [Int-area] The virtues of large buffers, was: Re: draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 20:55:39 -0000 On Fri, 8 Apr 2011, Roland Bless wrote: > I'm not sure what you exactly mean by long-fat-pipes here. Do you mean > a path with a large bandwith-delay product? In this case you need lots > of buffers, but mainly in the TCP implementation, not in the network. > For large bandwidth delay product connections the inflight packets are > mainly "stored" on the wire, not in the router buffers, aren't they? > The BDP rule-of-thumb for buffer sizes appears strange to me anyways. Well, since retransmits take so long time when you have high latency, you want packets buffered instead of dropped, and you want to smoothe out flows as they're saw-toothing. Having small buffers make this hard. > IMHO, smaller buffers with AQM and ECN are probably a really good thing > since dropping fairness can be achieved and flows get once a while > packets through to probe for bandwidth and to control their sending > speed. Large buffers don't help either if you've got long-term > congestion... Small buffers make AQM and ECN useless, IMHO. ECN with RED makes sense with large buffers, with small buffers you might as well FIFO taildrop. -- Mikael Abrahamsson email: swmike@swm.pp.se From iljitsch@muada.com Fri Apr 8 15:02:06 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C323A6A14 for ; Fri, 8 Apr 2011 15:02:06 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NXlVfsg-4kB for ; Fri, 8 Apr 2011 15:02:06 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id BB97D3A6A0E for ; Fri, 8 Apr 2011 15:02:05 -0700 (PDT) Received: from [192.168.0.140] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p38M5OVY004137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 9 Apr 2011 00:05:25 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Sat, 9 Apr 2011 00:03:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A8EA0B6-4654-4103-9755-E3BECFBE872D@muada.com> References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <4D9CA3FB.4050300@isi.edu> <475EC498-BE28-496C-B27A-3CFD88FF1935@muada.com> <8D29AD71-9327-4890-929B-DC7B3AC23438@muada.com> <4D9F24B8.7010807@kit.edu> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) Cc: Internet Area Subject: Re: [Int-area] The virtues of large buffers, was: Re: draft-ietf-intarea-ipv4-id-update-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 22:02:06 -0000 On 8 apr 2011, at 22:57, Mikael Abrahamsson wrote: > Small buffers make AQM and ECN useless, IMHO. ECN with RED makes sense = with large buffers, with small buffers you might as well FIFO taildrop. Well, we had a guy come in and give a talk about having only a = one-packet buffer last week and then there's having a gigabyte of = buffering. There is middle ground between those. At 1 Gbps you can have 500 buffers which should be more than enough for = AQM and ECN and still only introduce a maximum queuing delay of 6 = milliseconds. But with the AQM the buffer usually won't fill up all the = way and the average packet size is only ~ 500 and not 1500, so in = practice it's going to be more like 1 ms. In the home you can do some AQM with a much smaller buffer because the = number of sessions is much smaller and you can also do AQM variations = that keep per session state and don't depend on having extra buffering = like RED so it's not a straight choice between FIFO and large buffers = there either.= From roland.bless@kit.edu Tue Apr 12 04:19:41 2011 Return-Path: X-Original-To: int-area@ietfc.amsl.com Delivered-To: int-area@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C5D82E0736 for ; Tue, 12 Apr 2011 04:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZKYkpxy+3Yp for ; Tue, 12 Apr 2011 04:19:41 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfc.amsl.com (Postfix) with ESMTP id 01B94E06B6 for ; Tue, 12 Apr 2011 04:19:40 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1Q9bd7-00056F-7j; Tue, 12 Apr 2011 13:19:38 +0200 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 id 1Q9bd7-0005Zy-2w; Tue, 12 Apr 2011 13:19:33 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 0320DAAB8; Tue, 12 Apr 2011 13:19:33 +0200 (CEST) Message-ID: <4DA43544.9040503@kit.edu> Date: Tue, 12 Apr 2011 13:19:32 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Mikael Abrahamsson References: <9F37A1EF-4B7C-48C5-9669-AE4E220768AD@muada.com> <4D9B4001.7070805@isi.edu> <54BE6DFD-0B21-4336-B18F-8943DB23B381@muada.com> <4D9B4893.8010606@isi.edu> <4E5630C4-2D05-4066-B0F1-CC089FCB6C07@muada.com> <4D9CA3FB.4050300@isi.edu> <475EC498-BE28-496C-B27A-3CFD88FF1935@muada.com> <8D29AD71-9327-4890-929B-DC7B3AC23438@muada.com> <4D9F24B8.7010807@kit.edu> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1302607179.041444000 Cc: Internet Area Subject: Re: [Int-area] The virtues of large buffers, was: Re: draft-ietf-intarea-ipv4-id-update-02.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, 12 Apr 2011 11:19:41 -0000 Hi Mikael, On 08.04.2011 22:57, Mikael Abrahamsson wrote: > On Fri, 8 Apr 2011, Roland Bless wrote: > Well, since retransmits take so long time when you have high latency, > you want packets buffered instead of dropped, and you want to smoothe > out flows as they're saw-toothing. Having small buffers make this hard. Yes, but as I said: if the packets are stored on the wire, there is no need to buffer them in the router. Large buffers may reduce packet loss and thus retransmits for TCP connections. The benefit of buffering depends on aggregation effects due to multiplexing, flow characteristics (bursty, synchronized behavior etc.) and so on. >> IMHO, smaller buffers with AQM and ECN are probably a really good >> thing since dropping fairness can be achieved and flows get once a >> while packets through to probe for bandwidth and to control their >> sending speed. Large buffers don't help either if you've got long-term >> congestion... > > Small buffers make AQM and ECN useless, IMHO. ECN with RED makes sense > with large buffers, with small buffers you might as well FIFO taildrop. As Iljitsch also pointed out: there is some middle ground. For AQM, e.g., RED, you probably need a larger buffer compared to small buffer approaches using tail drop: if your threshold is small enough, you get short queues on average while you still can compensate for transient short-time bursts due to multiplexing etc. But even then you probably don't need BDP sized buffers... Regards, Roland From tena@huawei.com Wed Apr 13 16:13:21 2011 Return-Path: X-Original-To: int-area@ietfc.amsl.com Delivered-To: int-area@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 40A36E07EA for ; Wed, 13 Apr 2011 16:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.797 X-Spam-Level: X-Spam-Status: No, score=-104.797 tagged_above=-999 required=5 tests=[AWL=1.801, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3KhR5Uyfqbk for ; Wed, 13 Apr 2011 16:13:18 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfc.amsl.com (Postfix) with ESMTP id 071DAE07F1 for ; Wed, 13 Apr 2011 16:13:18 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM00HI65U46A@usaga02-in.huawei.com> for int-area@ietf.org; Wed, 13 Apr 2011 16:13:17 -0700 (PDT) Received: from TingZousc1 ([10.193.34.188]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJM00ABM5U3OF@usaga02-in.huawei.com> for int-area@ietf.org; Wed, 13 Apr 2011 16:13:16 -0700 (PDT) Date: Wed, 13 Apr 2011 16:13:15 -0700 From: Tina Tsou To: int-area@ietf.org Message-id: <00ef01cbfa30$5eb5ad50$1c2107f0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_h0X3MlDi3ojzRGawOFAr6A)" Content-language: en-us Thread-index: Acv513EEgB0AidJaRV+R6cpHxz5MQgAWIj5w x-cr-hashedpuzzle: BTsg Bg0F CEGB CQ2v DI05 Dw8E EdX1 EioQ Eqz3 FRNU GU7m GhF0 Hpli H9Cr IP0/ J8gd; 1; aQBuAHQALQBhAHIAZQBhAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {7D19ED87-13AD-44D8-9AF8-3A76036A9902}; dABlAG4AYQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Wed, 13 Apr 2011 23:13:13 GMT;UwBvAG0AZQAgAGMAbwBtAG0AZQBuAHQAcwAgAGYAbwByACAANAByAGQA x-cr-puzzleid: {7D19ED87-13AD-44D8-9AF8-3A76036A9902} Subject: [Int-area] Some comments for 4rd 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, 13 Apr 2011 23:13:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_h0X3MlDi3ojzRGawOFAr6A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, I have some comments for 4rd. http://tools.ietf.org/html/draft-despres-intarea-4rd-01 http://tools.ietf.org/html/draft-sun-intarea-4rd-applicability-01 1. In section 4.3.4 of 4rd draft, Figure 4 In section 2.5.1 of RFC3513, it says: " For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." The last 64bits of CE IPv6 address should comply with this requirement, if you do not have any specific reasons to set them to 0. 2. In section 4.5.1 and 4.5.2, (d) of 4rd draft In this case, the packet comes from the internet to the CE/end user, there is no address sharing in this direction, why should the Datagram ID be replaced by a locally generated one? 3. ICMP does not work in 4rd ICMP packet contains no port information, a user can send a ping packet to peer, but when the BR receives the response packet, the BR does not know how to construct the CE's IPv6 address based on just the IPv4 address, without the IPv4 port info. A possible solution is to put the port information into the identification field of an ICMP packet: a) When receiving a ICMP packet from the end user, CE should get a number from its IPv4 port range, and put it into the identification field of the ICMP packet. b) When receiving a response ICMP message from the internet side, BR should derive the CE's IPv6 address based on the IPv4 destination address and the identification(port) info. c) If BR does not replace the identification filed of a packet, then only a) and b) is sufficient; or BR just replace identification of packet when the packet is not ICMP packet; if the BR replace identification of all packets, then BR have to maintain a mapping table of internal identification VS external identification, and when receiving a response ICMP packet from the internet side, BR should replace the identification based on the mapping table before forwarding it to CE. 4. Unable to communicate to users sharing a same IP address Users sharing a same public IPv4 address would not be able to communicate directly, because they have the same IP address; the IP stack would not send out a packet to the network if it thinks the destination is itself, but return the packet to itself, just like you send a packet to 127.0.0.1. Maybe they can communicate to each other via native IPv6; 5. In section 5 of applicability draft "Shared address issues [I-D.ietf-intarea-shared-addressing-issues] describes a method for the random selection of TCP Sequence Number, that reduces the ability of attacker to correctly guess the 5-ruple." Random selection of TCP Sequence Number is to prevent the attacker from guessing the next TCP SN, not the 5-tuple. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html --Boundary_(ID_h0X3MlDi3ojzRGawOFAr6A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = all,

I = have some comments for 4rd.

 

http://t= ools.ietf.org/html/draft-despres-intarea-4rd-01

http://tools.ietf.org/html/draft-sun-intarea-4rd-applicability-01

 

1.       = In section 4.3.4 of 4rd draft, Figure = 4

In section 2.5.1 of RFC3513, = it says:

“ For all unicast addresses, except = those that start with binary value 000, Interface IDs are required to be = 64 bits long and to be constructed in Modified EUI-64 = format.”

 

The last 64bits of CE IPv6 address should = comply with this requirement, if you do not have any specific reasons to = set them to 0.

 

2.       = In section 4.5.1 and 4.5.2, (d) of 4rd = draft

In this case, the packet = comes from the internet to the CE/end user, there is no address sharing = in this direction, why should the Datagram ID be replaced by a locally = generated one?

 

3.       = ICMP does not work in = 4rd

ICMP packet contains no port = information, a user can send a ping packet to peer, but when the BR = receives the response packet, the BR does not know how to construct the = CE’s IPv6 address based on just the IPv4 address, without the IPv4 = port info.

 

A = possible solution is to put the port information into the identification = field of an ICMP packet:

a)       = When receiving a ICMP packet from the end = user, CE should get a number from its IPv4 port range, and put it into = the identification field of the ICMP packet.

b)       = When receiving a response ICMP message = from the internet side, BR should derive the CE’s IPv6 address = based on the IPv4 destination address and the identification(port) = info.

c)       = If BR does not replace the identification = filed of a packet, then only a) and b) is sufficient; or BR just replace = identification of packet when the packet is not ICMP packet; =

if the BR replace = identification of all packets, then BR have to maintain a mapping table = of internal identification VS external identification, and when = receiving a response ICMP packet from the internet side, BR should = replace the identification based on the mapping table before forwarding = it to CE.

 

4.       = Unable to communicate to users sharing a = same IP address

Users sharing a same public = IPv4 address would not be able to communicate directly, because they = have the same IP address; the IP stack would not send out a packet to = the network if it thinks the destination is itself, but return the = packet to itself, just like you send a packet to = 127.0.0.1.

Maybe they can communicate = to each other via native IPv6;

 

5.       = In section 5 of applicability = draft

“Shared address issues = [I-D.ietf-intarea-shared-addressing-issues] describes a method = for

   the random selection = of TCP Sequence Number, that reduces the ability of attacker to = correctly guess the 5-ruple.”

 

   = Random selection of TCP Sequence = Number is to prevent the attacker from guessing the next TCP SN, not the = 5-tuple.

 

 

 

We keep our = promises with one another – no matter = what!

 

Best = Regards,

Tina = TSOU

http://tinatsou.weebly.com/contact.html

 

= --Boundary_(ID_h0X3MlDi3ojzRGawOFAr6A)-- From tetsuya@ipinfusion.com Fri Apr 15 15:17:49 2011 Return-Path: X-Original-To: int-area@ietfc.amsl.com Delivered-To: int-area@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 73ECCE078B for ; Fri, 15 Apr 2011 15:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV0BotmtqS9S for ; Fri, 15 Apr 2011 15:17:47 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfc.amsl.com (Postfix) with ESMTP id 9ADF1E06B1 for ; Fri, 15 Apr 2011 15:17:47 -0700 (PDT) Received: by pvh1 with SMTP id 1so1606813pvh.31 for ; Fri, 15 Apr 2011 15:17:47 -0700 (PDT) Received: by 10.68.66.162 with SMTP id g2mr2604275pbt.391.1302905867091; Fri, 15 Apr 2011 15:17:47 -0700 (PDT) Received: from [10.70.2.84] ([12.248.239.142]) by mx.google.com with ESMTPS id m10sm548111pbn.97.2011.04.15.15.17.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2011 15:17:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4-328634287 From: Tetsuya Murakami In-Reply-To: Date: Fri, 15 Apr 2011 15:17:44 -0700 Message-Id: References: <00ef01cbfa30$5eb5ad50$1c2107f0$@com> To: int-area@ietf.org X-Mailer: Apple Mail (2.1084) Cc: Ole Troan , =?iso-2022-jp?B?GyRCOzM6ahsoQiAbJEJNNTtKGyhC?= , Jiao Jie Subject: Re: [Int-area] Some comments for 4rd 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: Fri, 15 Apr 2011 22:17:49 -0000 --Apple-Mail-4-328634287 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp Hi Tina, Thank you for your comments. Please see my comments in line. On 2011/04/13, at 18:05, Tina Tsou wrote: > From: Tina Tsou > Date: 2011/4/14 > Subject: [Int-area] Some comments for 4rd > To: int-area@ietf.org >=20 > Hi all, >=20 > I have some comments for 4rd. >=20 > http://tools.ietf.org/html/draft-despres-intarea-4rd-01 >=20 > http://tools.ietf.org/html/draft-sun-intarea-4rd-applicability-01 >=20 > 1. In section 4.3.4 of 4rd draft, Figure 4 >=20 > In section 2.5.1 of RFC3513, it says: >=20 > =1B$B!H=1B(B For all unicast addresses, except those that start with = binary value > 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format.=1B$B!I=1B(B >=20 > The last 64bits of CE IPv6 address should comply with this > requirement, if you do not have any specific reasons to set them to 0. Upon receiving an IPv4 packet via IPv4 interface, BR can retrieve the CE = index from both the destination IPv4 address and the destination port = number if using shared IPv4 address and then BR can generate the = destination IPv6 address from the combination of Domain IPv6 prefix and = CE index but BR can not get the interface ID for the receiver. So, we = are setting it to 0. > 2. In section 4.5.1 and 4.5.2, (d) of 4rd draft >=20 > In this case, the packet comes from the internet to the CE/end user, > there is no address sharing in this direction, why should the Datagram > ID be replaced by a locally generated one? If not using IPv4 shared address, I don't think the datagram ID needs to = be replaced by a locally generated one. If using IPv4 shared address, = only BR might need to replace the datagram ID by using a locally = generated one upon forwarding IPv4 packet via IPv4 interface. So, you = are right. The datagram ID does not need to be replaced at CE because = there is no shared address among the clients connected to the CE. We = will update it in the next version of the draft. > 3. ICMP does not work in 4rd >=20 > ICMP packet contains no port information, a user can send a ping > packet to peer, but when the BR receives the response packet, the BR > does not know how to construct the CE=1B$B!G=1B(Bs IPv6 address based = on just the > IPv4 address, without the IPv4 port info. >=20 > A possible solution is to put the port information into the > identification field of an ICMP packet: Yes. Our implementation supports ICMP echo/reply by using the = identification field of ICMP header like the port number. NAT44 changes = the identification field by using the assigned port-range at CE. We will = add some text for this in the next version of the draft. > a) When receiving a ICMP packet from the end user, CE should get > a number from its IPv4 port range, and put it into the identification > field of the ICMP packet. >=20 > b) When receiving a response ICMP message from the internet > side, BR should derive the CE=1B$B!G=1B(Bs IPv6 address based on the = IPv4 > destination address and the identification(port) info. >=20 > c) If BR does not replace the identification filed of a packet, > then only a) and b) is sufficient; or BR just replace identification > of packet when the packet is not ICMP packet; >=20 > if the BR replace identification of all packets, then BR have to > maintain a mapping table of internal identification VS external > identification, and when receiving a response ICMP packet from the > internet side, BR should replace the identification based on the > mapping table before forwarding it to CE. >=20 > 4. Unable to communicate to users sharing a same IP address >=20 > Users sharing a same public IPv4 address would not be able to > communicate directly, because they have the same IP address; the IP > stack would not send out a packet to the network if it thinks the > destination is itself, but return the packet to itself, just like you > send a packet to 127.0.0.1. >=20 > Maybe they can communicate to each other via native IPv6; If using the normal IPv4 stack supported in many operating system, the = direct communication of CEs which share the same IPv4 address can not be = done. But I think this depends on the implementation. For example, if = not assigning shared IPv4 address to any interface and using this shared = IPv4 interface in NAT44 as the replaced IPv4 address, the direct = communication can be done even though multiple CEs share the same IPv4 = address (see "[Softwires] sharing restricted addresses by hosts in 4rd = (draft-despres-intarea-4rd-01)" mail thread). Also, I think there are = any other implementation for achieving the direct communication between = CEs which share the same IPv4 address. Thanks, Tetsuya Murakami= --Apple-Mail-4-328634287 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp Hi = Tina,

Thank you for your = comments.

Please see my comments in = line.

On 2011/04/13, at 18:05, Tina Tsou = wrote:

From: Tina = Tsou <tena@huawei.com>
Date: = 2011/4/14
Subject: [Int-area] Some comments for 4rd
To: int-area@ietf.org

Hi = all,

I have some comments for 4rd.

http://to= ols.ietf.org/html/draft-despres-intarea-4rd-01

http://tools.iet= f.org/html/draft-sun-intarea-4rd-applicability-01

1.  &nb= sp;    In section 4.3.4 of 4rd draft, Figure 4

In = section 2.5.1 of RFC3513, it says:

=1B$B!H=1B(B For all unicast = addresses, except those that start with binary value
000, Interface = IDs are required to be 64 bits long and to be
constructed in Modified = EUI-64 format.=1B$B!I=1B(B

The last 64bits of CE IPv6 address = should comply with this
requirement, if you do not have any specific = reasons to set them to 0.

Upon = receiving an IPv4 packet via IPv4 interface, BR can retrieve the CE = index from both the destination IPv4 address and the destination port = number if using shared IPv4 address and then BR can generate the = destination IPv6 address from the combination of Domain IPv6 prefix and = CE index but BR can not get the interface ID for the receiver. So, we = are setting it to 0.

2.       In section = 4.5.1 and 4.5.2, (d) of 4rd draft

In this case, the packet comes = from the internet to the CE/end user,
there is no address sharing in = this direction, why should the Datagram
ID be replaced by a locally = generated one?

If not using = IPv4 shared address, I don't think the datagram ID needs to be replaced = by a locally generated one. If using IPv4 shared address, only BR might = need to replace the datagram ID by using a locally generated one upon = forwarding IPv4 packet via IPv4 interface. So, you are right. The = datagram ID does not need to be replaced at CE because there is no = shared address among the clients connected to the CE. We will update it = in the next version of the draft.

3.       ICMP does not = work in 4rd

ICMP packet contains no port information, a user can = send a ping
packet to peer, but when the BR receives the response = packet, the BR
does not know how to construct the CE=1B$B!G=1B(Bs = IPv6 address based on just the
IPv4 address, without the IPv4 port = info.

A possible solution is to put the port information into = the
identification field of an ICMP = packet:

Yes. Our = implementation supports ICMP echo/reply by using the identification = field of ICMP header like the port number. NAT44 changes the = identification field by using the assigned port-range at CE. We will add = some text for this in the next version of the = draft.

a)       When receiving = a ICMP packet from the end user, CE should get
a number from its IPv4 = port range, and put it into the identification
field of the ICMP = packet.

b)       When receiving a = response ICMP message from the internet
side, BR should derive the = CE=1B$B!G=1B(Bs IPv6 address based on the IPv4
destination address = and the identification(port) = info.

c)       If BR does not = replace the identification filed of a packet,
then only a) and b) is = sufficient; or BR just replace identification
of packet when the = packet is not ICMP packet;

if the BR replace identification of = all packets, then BR have to
maintain a mapping table of internal = identification VS external
identification, and when receiving a = response ICMP packet from the
internet side, BR should replace the = identification based on the
mapping table before forwarding it to = CE.

4.       Unable to communicate = to users sharing a same IP address

Users sharing a same public = IPv4 address would not be able to
communicate directly, because they = have the same IP address; the IP
stack would not send out a packet to = the network if it thinks the
destination is itself, but return the = packet to itself, just like you
send a packet to = 127.0.0.1.

Maybe they can communicate to each other via native = IPv6;

If using the normal IPv4 = stack supported in many operating system, the direct communication of = CEs which share the same IPv4 address can not be done. But I think this = depends on the implementation. For example, if not assigning shared IPv4 = address to any interface and using this shared IPv4 interface in NAT44 = as the replaced IPv4 address, the direct communication can be done even = though multiple CEs share the same IPv4 address (see "[Softwires] = sharing restricted addresses by hosts in 4rd = (draft-despres-intarea-4rd-01)" mail thread). Also, I = think there are any other implementation for achieving the direct = communication between CEs which share the same IPv4 = address.

Thanks,
Tetsuya = Murakami
= --Apple-Mail-4-328634287-- From c-sun@bb.softbank.co.jp Sun Apr 17 21:27:58 2011 Return-Path: X-Original-To: int-area@ietfc.amsl.com Delivered-To: int-area@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0A271E06A9 for ; Sun, 17 Apr 2011 21:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.002 X-Spam-Level: ** X-Spam-Status: No, score=2.002 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qm4nWj+M6cOt for ; Sun, 17 Apr 2011 21:27:57 -0700 (PDT) Received: from bb.softbank.co.jp (m3.bb.softbank.co.jp [210.146.18.152]) by ietfc.amsl.com (Postfix) with ESMTP id 7B71FE0699 for ; Sun, 17 Apr 2011 21:27:56 -0700 (PDT) Received: from CI-EXHB-01.bb.local (10.241.1.2) by m3.bb.softbank.co.jp (210.146.18.152) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 18 Apr 2011 13:27:55 +0900 Received: from CI-EXMB-09V.bb.local ([fe80::15e:dbec:b8a2:731f]) by CI-EXHB-01.bb.local ([::1]) with mapi; Mon, 18 Apr 2011 13:27:54 +0900 From: To: , Date: Mon, 18 Apr 2011 13:27:53 +0900 Thread-Topic: [Int-area] Some comments for 4rd Thread-Index: Acv513EEgB0AidJaRV+R6cpHxz5MQgAWIj5wANQbB6A= Message-ID: <6CADC58598A4D249AD3B5026CE8CC33906D758D5@CI-EXMB-09V.bb.local> References: <00ef01cbfa30$5eb5ad50$1c2107f0$@com> In-Reply-To: <00ef01cbfa30$5eb5ad50$1c2107f0$@com> Accept-Language: zh-CN, ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: zh-CN, ja-JP Content-Type: multipart/alternative; boundary="_000_6CADC58598A4D249AD3B5026CE8CC33906D758D5CIEXMB09Vbbloca_" MIME-Version: 1.0 Subject: Re: [Int-area] Some comments for 4rd 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, 18 Apr 2011 04:27:58 -0000 --_000_6CADC58598A4D249AD3B5026CE8CC33906D758D5CIEXMB09Vbbloca_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Tina Thank you for your comments. >5. In section 5 of applicability draft > =1B$B!H=1B(BShared address issues [I-D.ietf-intarea-shared-addressing= -issues] describes a method for > the random selection of TCP Sequence Number, that reduces the ability of= attacker to correctly guess the 5-ruple.=1B$B!I=1B(B > Random selection of TCP Sequence Number is to prevent the attacker from= guessing the next TCP SN, not the 5-tuple. You are right. I will change it in the next version of draft. Chunfa --_000_6CADC58598A4D249AD3B5026CE8CC33906D758D5CIEXMB09Vbbloca_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Hi Tina
Thank you for your comments.
 

<= SPAN=20 style=3D"mso-list: Ignore">>5.      = =20 In section 5 of applicability draft

>   &nbs= p;=20 =1B$B!H=1B(BShared address issues [I-D.ietf-intarea-shared-addressin= g-issues]=20 describes a method for

>  the random selection of TCP Se= quence=20 Number, that reduces the ability of attacker to correctly guess the=20 5-ruple.=1B$B!I=1B(B

 

>   Random selection of TCP Sequence Number is = to=20 prevent the attacker from guessing the next TCP SN, not the=20 5-tuple.

 
You are right. I will chan= ge it in=20 the next version of draft.
 
Chunfa
 
<= ![if !supportLists]> --_000_6CADC58598A4D249AD3B5026CE8CC33906D758D5CIEXMB09Vbbloca_-- From Internet-Drafts@ietf.org Mon Apr 18 15:30:02 2011 Return-Path: X-Original-To: int-area@ietfc.amsl.com Delivered-To: int-area@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B99E2E0719; Mon, 18 Apr 2011 15:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.779 X-Spam-Level: X-Spam-Status: No, score=-102.779 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHOg5tokjkuz; Mon, 18 Apr 2011 15:30:01 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EC65EE06E2; Mon, 18 Apr 2011 15:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110418223001.25851.27044.idtracker@ietfc.amsl.com> Date: Mon, 18 Apr 2011 15:30:01 -0700 Cc: int-area@ietf.org Subject: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-04.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: Mon, 18 Apr 2011 22:30:02 -0000 --NextPart 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 : Logging recommendations for Internet facing servers Author(s) : A. Durand, et al. Filename : draft-ietf-intarea-server-logging-recommendations-04.txt Pages : 6 Date : 2011-04-18 In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet facing servers log port number and accurate timestamps in addition to the incoming IP address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-intarea-server-logging-recommendations-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-intarea-server-logging-recommendations-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-18152711.I-D@ietf.org> --NextPart-- From dwing@cisco.com Mon Apr 18 16:20:01 2011 Return-Path: X-Original-To: int-area@ietfc.amsl.com Delivered-To: int-area@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D7D01E067C for ; Mon, 18 Apr 2011 16:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjUD-E0WWIsD for ; Mon, 18 Apr 2011 16:20:00 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 62A06E06AB for ; Mon, 18 Apr 2011 16:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1928; q=dns/txt; s=iport; t=1303168800; x=1304378400; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=GeyI8HB+zU8FwEShKnX146C/qzaqiIaJ73eYBgWqb/k=; b=MEhQCrLxaAnH5DhaVq/66mwpiz5fdUi85KMIu4M1Tp/Dc+U8gnnNEeUj 3F3u6Y1e4OZACT1DR5DVvS+ITF1WWuTGEo93oanzR1/fASJcCJnbwmr0E gjzSqgiVYgg4n1J5eBZaA57yM+8sdPRc9t9HG475Foe+3vh8eyBmqoCmf 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIBAMnFrE2rRDoI/2dsb2JhbACXOoFjjCJ3qlCcXIVxBIVi X-IronPort-AV: E=Sophos;i="4.64,236,1301875200"; d="scan'208";a="340070077" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 18 Apr 2011 23:19:59 +0000 Received: from dwingWS (sjc-vpn4-1192.cisco.com [10.21.84.167]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3INJxdW011574; Mon, 18 Apr 2011 23:19:59 GMT From: "Dan Wing" To: , , References: <00ef01cbfa30$5eb5ad50$1c2107f0$@com> <6CADC58598A4D249AD3B5026CE8CC33906D758D5@CI-EXMB-09V.bb.local> In-Reply-To: <6CADC58598A4D249AD3B5026CE8CC33906D758D5@CI-EXMB-09V.bb.local> Date: Mon, 18 Apr 2011 16:19:59 -0700 Message-ID: <0c2301cbfe1f$2344e4f0$69ceaed0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv513EEgB0AidJaRV+R6cpHxz5MQgAWIj5wANQbB6AAJ1Rt4A== Content-Language: en-us Subject: Re: [Int-area] Some comments for 4rd 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, 18 Apr 2011 23:20:02 -0000 > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of c-sun@bb.softbank.co.jp > Sent: Sunday, April 17, 2011 9:28 PM > To: tena@huawei.com; int-area@ietf.org > Subject: Re: [Int-area] Some comments for 4rd > > Hi Tina > Thank you for your comments. > > >5. In section 5 of applicability draft > > "Shared address issues [I-D.ietf-intarea-shared-addressing- > issues] describes a method for > > the random selection of TCP Sequence Number, that reduces the > ability of attacker to correctly guess the 5-ruple." > > > Random selection of TCP Sequence Number is to prevent the attacker > from guessing the next TCP SN, not the 5-tuple. > > You are right. I will change it in the next version of draft. I noticed the existing text in http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05#se ction-5 says the client goes into TIME_WAIT ("It is important to realize that the TCP design makes it undesirable for clients to re-use ports while they remain in the TIME-WAIT state (typically 4 minutes after the connection has concluded).") -- however, that depends on the client doing the active close. I see that http://tools.ietf.org/html/rfc6056#section-2.3 discusses what happens when the server does the active close: the client doesn't go into TIME_WAIT. The recommendation in draft-ietf-intarea-shared-addressing-issues appears to re-enforce the suggestion in the last sentence of http://tools.ietf.org/html/rfc6056#section-2.3, which says: A simple but inefficient approach to minimize the rate of collisions of instance-ids would be, e.g., in the case of TCP, for both endpoints of a TCP connection to keep state about recent connections (e.g., have both endpoints end up in the TIME-WAIT state). perhaps you could cite RFC6056 and reduce the discussion in Section 5? -d From tena@huawei.com Fri Apr 15 15:09:03 2011 Return-Path: X-Original-To: int-area@ietfc.amsl.com Delivered-To: int-area@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5889CE081A for ; Fri, 15 Apr 2011 15:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.397 X-Spam-Level: X-Spam-Status: No, score=-105.397 tagged_above=-999 required=5 tests=[AWL=1.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjEslxbZb-GF for ; Fri, 15 Apr 2011 15:08:59 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfc.amsl.com (Postfix) with ESMTP id BC415E0809 for ; Fri, 15 Apr 2011 15:08:59 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJP0080LS6ZE1@usaga02-in.huawei.com> for int-area@ietf.org; Fri, 15 Apr 2011 15:08:59 -0700 (PDT) Received: from TingZousc1 ([10.212.245.36]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJP006WFS6WZ6@usaga02-in.huawei.com> for int-area@ietf.org; Fri, 15 Apr 2011 15:08:59 -0700 (PDT) Date: Fri, 15 Apr 2011 15:08:52 -0700 From: Tina Tsou In-reply-to: <00ef01cbfa30$5eb5ad50$1c2107f0$@com> To: int-area@ietf.org Message-id: <016401cbfbb9$b80b2210$28216630$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_u6PronNq/0WHTlloLmj6jQ)" Content-language: en-us Thread-index: Acv513EEgB0AidJaRV+R6cpHxz5MQgAWIj5wAGJM1eA= References: <00ef01cbfa30$5eb5ad50$1c2107f0$@com> X-Mailman-Approved-At: Tue, 19 Apr 2011 08:06:58 -0700 Subject: Re: [Int-area] Some comments for 4rd 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: Fri, 15 Apr 2011 22:09:03 -0000 This is a multi-part message in MIME format. --Boundary_(ID_u6PronNq/0WHTlloLmj6jQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, Sorry for making noise. I'm wondering that perhaps http://tools.ietf.org/html/draft-ymbk-aplusp-09#section-5.3.2 has already solve the ICMP issues. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behalf Of Tina Tsou Sent: Wednesday, April 13, 2011 4:13 PM To: int-area@ietf.org Subject: [Int-area] Some comments for 4rd Hi all, I have some comments for 4rd. http://tools.ietf.org/html/draft-despres-intarea-4rd-01 http://tools.ietf.org/html/draft-sun-intarea-4rd-applicability-01 1. In section 4.3.4 of 4rd draft, Figure 4 In section 2.5.1 of RFC3513, it says: " For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." The last 64bits of CE IPv6 address should comply with this requirement, if you do not have any specific reasons to set them to 0. 2. In section 4.5.1 and 4.5.2, (d) of 4rd draft In this case, the packet comes from the internet to the CE/end user, there is no address sharing in this direction, why should the Datagram ID be replaced by a locally generated one? 3. ICMP does not work in 4rd ICMP packet contains no port information, a user can send a ping packet to peer, but when the BR receives the response packet, the BR does not know how to construct the CE's IPv6 address based on just the IPv4 address, without the IPv4 port info. A possible solution is to put the port information into the identification field of an ICMP packet: a) When receiving a ICMP packet from the end user, CE should get a number from its IPv4 port range, and put it into the identification field of the ICMP packet. b) When receiving a response ICMP message from the internet side, BR should derive the CE's IPv6 address based on the IPv4 destination address and the identification(port) info. c) If BR does not replace the identification filed of a packet, then only a) and b) is sufficient; or BR just replace identification of packet when the packet is not ICMP packet; if the BR replace identification of all packets, then BR have to maintain a mapping table of internal identification VS external identification, and when receiving a response ICMP packet from the internet side, BR should replace the identification based on the mapping table before forwarding it to CE. 4. Unable to communicate to users sharing a same IP address Users sharing a same public IPv4 address would not be able to communicate directly, because they have the same IP address; the IP stack would not send out a packet to the network if it thinks the destination is itself, but return the packet to itself, just like you send a packet to 127.0.0.1. Maybe they can communicate to each other via native IPv6; 5. In section 5 of applicability draft "Shared address issues [I-D.ietf-intarea-shared-addressing-issues] describes a method for the random selection of TCP Sequence Number, that reduces the ability of attacker to correctly guess the 5-ruple." Random selection of TCP Sequence Number is to prevent the attacker from guessing the next TCP SN, not the 5-tuple. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html --Boundary_(ID_u6PronNq/0WHTlloLmj6jQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi all,

Sorry for making = noise.

I’m wondering that = perhaps

ht= tp://tools.ietf.org/html/draft-ymbk-aplusp-09#section-5.3.2

has already solve the ICMP = issues.

 

We keep our promises with one = another – no matter what!

 

Best = Regards,

Tina = TSOU

http://tinatsou.weebly.com/contact= .html

 

From: int-area-bounces@ietf.org = [mailto:int-area-bounces@ietf.org] On Behalf Of Tina = Tsou
Sent: Wednesday, April 13, 2011 4:13 PM
To: = int-area@ietf.org
Subject: [Int-area] Some comments for = 4rd

 

Hi = all,

I have some comments for = 4rd.

 

http://t= ools.ietf.org/html/draft-despres-intarea-4rd-01

http://tools.ietf.org/html/draft-sun-intarea-4rd-applicability-01

 

1.       = In section 4.3.4 of 4rd draft, Figure = 4

In section 2.5.1 of RFC3513, = it says:

“ For all unicast addresses, except = those that start with binary value 000, Interface IDs are required to be = 64 bits long and to be constructed in Modified EUI-64 = format.”

 

The last 64bits of CE IPv6 address should = comply with this requirement, if you do not have any specific reasons to = set them to 0.

 

2.       = In section 4.5.1 and 4.5.2, (d) of 4rd = draft

In this case, the packet = comes from the internet to the CE/end user, there is no address sharing = in this direction, why should the Datagram ID be replaced by a locally = generated one?

 

3.       = ICMP does not work in = 4rd

ICMP packet contains no port = information, a user can send a ping packet to peer, but when the BR = receives the response packet, the BR does not know how to construct the = CE’s IPv6 address based on just the IPv4 address, without the IPv4 = port info.

 

A = possible solution is to put the port information into the identification = field of an ICMP packet:

a)       = When receiving a ICMP packet from the end = user, CE should get a number from its IPv4 port range, and put it into = the identification field of the ICMP packet.

b)       = When receiving a response ICMP message = from the internet side, BR should derive the CE’s IPv6 address = based on the IPv4 destination address and the identification(port) = info.

c)       = If BR does not replace the identification = filed of a packet, then only a) and b) is sufficient; or BR just replace = identification of packet when the packet is not ICMP packet; =

if the BR replace = identification of all packets, then BR have to maintain a mapping table = of internal identification VS external identification, and when = receiving a response ICMP packet from the internet side, BR should = replace the identification based on the mapping table before forwarding = it to CE.

 

4.       = Unable to communicate to users sharing a = same IP address

Users sharing a same public = IPv4 address would not be able to communicate directly, because they = have the same IP address; the IP stack would not send out a packet to = the network if it thinks the destination is itself, but return the = packet to itself, just like you send a packet to = 127.0.0.1.

Maybe they can communicate = to each other via native IPv6;

 

5.       = In section 5 of applicability = draft

“Shared address issues = [I-D.ietf-intarea-shared-addressing-issues] describes a method = for

   the random selection = of TCP Sequence Number, that reduces the ability of attacker to = correctly guess the 5-ruple.”

 

   = Random selection of TCP Sequence = Number is to prevent the attacker from guessing the next TCP SN, not the = 5-tuple.

 

 

 

We keep our promises = with one another – no matter what!

 

Best = Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 

= --Boundary_(ID_u6PronNq/0WHTlloLmj6jQ)-- From c-sun@bb.softbank.co.jp Thu Apr 21 19:49:15 2011 Return-Path: X-Original-To: int-area@ietfc.amsl.com Delivered-To: int-area@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F1F2FE077C for ; Thu, 21 Apr 2011 19:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[AWL=1.046, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txd5WIiU5CiA for ; Thu, 21 Apr 2011 19:49:15 -0700 (PDT) Received: from bb.softbank.co.jp (m1.bb.softbank.co.jp [210.146.18.150]) by ietfc.amsl.com (Postfix) with ESMTP id 23852E077B for ; Thu, 21 Apr 2011 19:49:14 -0700 (PDT) Received: from CI-EXHB-04.bb.local (10.241.1.5) by m1.bb.softbank.co.jp (210.146.18.150) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 22 Apr 2011 11:49:13 +0900 Received: from CI-EXMB-09V.bb.local ([fe80::15e:dbec:b8a2:731f]) by CI-EXHB-04.bb.local ([::1]) with mapi; Fri, 22 Apr 2011 11:49:13 +0900 From: To: , , Date: Fri, 22 Apr 2011 11:49:12 +0900 Thread-Topic: [Int-area] Some comments for 4rd Thread-Index: Acv513EEgB0AidJaRV+R6cpHxz5MQgAWIj5wANQbB6AAJ1Rt4ACeRjQQ Message-ID: <6CADC58598A4D249AD3B5026CE8CC33906D758ED@CI-EXMB-09V.bb.local> References: <00ef01cbfa30$5eb5ad50$1c2107f0$@com> <6CADC58598A4D249AD3B5026CE8CC33906D758D5@CI-EXMB-09V.bb.local> <0c2301cbfe1f$2344e4f0$69ceaed0$@com> In-Reply-To: <0c2301cbfe1f$2344e4f0$69ceaed0$@com> Accept-Language: zh-CN, ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: zh-CN, ja-JP Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Int-area] Some comments for 4rd 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: Fri, 22 Apr 2011 02:49:16 -0000 =20 Hi, Dan Thank you for your comments. I will cite RFC6056 and try to reduce the discussion in section 5. Chunfa=20 > >5. In section 5 of applicability draft > > "Shared address issues [I-D.ietf-intarea-shared-addressing- > issues] describes a method for > > the random selection of TCP Sequence Number, that reduces the > ability of attacker to correctly guess the 5-ruple." >=20 > > Random selection of TCP Sequence Number is to prevent the attacker > from guessing the next TCP SN, not the 5-tuple. >=20 > You are right. I will change it in the next version of draft. I noticed the existing text in http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05#s= e ction-5 says the client goes into TIME_WAIT ("It is important to realize th= at the TCP design makes it undesirable for clients to re-use ports while th= ey remain in the TIME-WAIT state (typically 4 minutes after the connection = has concluded).") -- however, that depends on the client doing the active c= lose. I see that http://tools.ietf.org/html/rfc6056#section-2.3 discusses = what happens when the server does the active close: the client doesn't go = into TIME_WAIT. The recommendation in draft-ietf-intarea-shared-addressing= -issues appears to re-enforce the suggestion in the last sentence of http:/= /tools.ietf.org/html/rfc6056#section-2.3, which says: A simple but inefficient approach to minimize the rate of collisions of instance-ids would be, e.g., in the case of TCP, for both endpoints of a TCP connection to keep state about recent connections (e.g., have both endpoints end up in the TIME-WAIT state). perhaps you could cite RFC6056 and reduce the discussion in Section 5? From cpignata@cisco.com Thu Apr 21 21:08:23 2011 Return-Path: X-Original-To: int-area@ietfc.amsl.com Delivered-To: int-area@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 83F70E07C3 for ; Thu, 21 Apr 2011 21:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lYgHt-+3AaX for ; Thu, 21 Apr 2011 21:08:22 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfc.amsl.com (Postfix) with ESMTP id C0D23E07C0 for ; Thu, 21 Apr 2011 21:08:22 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3M48L0b023991 for ; Fri, 22 Apr 2011 00:08:21 -0400 (EDT) Received: from [10.117.115.50] (rtp-cpignata-8911.cisco.com [10.117.115.50]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3M48LrQ017762 for ; Fri, 22 Apr 2011 00:08:21 -0400 (EDT) Message-ID: <4DB0FF34.30005@cisco.com> Date: Fri, 22 Apr 2011 00:08:20 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: int-area@ietf.org References: <4D94BDA0.6010402@isi.edu> In-Reply-To: <4D94BDA0.6010402@isi.edu> X-Enigmail-Version: 1.1.1 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Int-area] Recycle IPv4 bits 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: Fri, 22 Apr 2011 04:08:23 -0000 Joe, Please find one comment inline, which may have been discussed already in the thread, apologies if I missed it. On 3/31/2011 1:45 PM, Joe Touch wrote: > Hi, Deco, > > This proposal is a moot point; the FO needs to be zero for a packet to > be ATOMIC. see below: > > On 3/31/2011 4:41 AM, Teco Boot wrote: >> Having a discussion on recycling used IPv4 header bits, I made >> a snapshot on what was in the air at same point in time, somewhere. >> I found out the ID field of atomic packets was filled for almost >> all packets. >> >> IPv4 total: 151081 >> Atomic packets: 105357 (70%) >> On atomic packets: >> ID == 0 1557 ( 1,5%) >> ID != 0 103800 ( 98,5%) >> FO == 0 105357 (100,0%) >> >> The Fragment Offset was always set on zero, I read this as unused. > > That is incorrect. It is part of what makes a packet atomic, as per the > ipv4-id-update draft: > > (DF==1)&&(MF==0)&&(frag_offset==0) > > Let's look at the cases: > > DF MF FO > 0 x x CAN FRAGMENT > non-atomic packet that can be fragmented downstream; > that fragmentation would overwrite MF and FO > > 1 0 0 ATOMIC > basically this is a lot like saying > "this is the first and last fragment" > > 1 0 nonzero LAST FRAGMENT > packet has already been fragmented and > this is the last fragment > > 1 1 0 FIRST FRAGMENT > packet has already been fragmented, and this is the > first fragment and NOT the last (other fragments > with higher offsets are expected) > > 1 1 nonzero MIDDLE FRAGMENT > packet has already been fragmented, and this is > not the first fragment, and other fragments are > expected In these last 3 cases you include fragments (first, middle, last) with the DF bit set. This mimics IPv6's source-only fragmentation, but it is not clear to me how common that is. But if this is a spec exercise, RFC791 says 'An internet datagram can be marked "don't fragment."' Agreed that perhaps such datagram can be a complete datagram or a fragment (although I read the intention as meaning a complete packet), but the use case is that so that the receiver does not reassemble (hence meaning that it makes sense only in a complete datagram). The examples of fragmentation procedures in RFC791 do not set the DF bit. I know of systems that source-fragment without setting the DF bit, and a fragment can in turn be fragmented in flight. If the source is setting DF for fragments, is not following the procedure in RFC 791? Thanks, -- Carlos. > > Note that thus: > > ATOMIC packets are *defined* by having all the FO bits as zero. > > > What comes up in my mind: can we recycle the 13 fragment offset bits? > > Instead of ID field? At least it may be a well defined starting point. > > When the bits aren't zero, an otherwise ATOMIC packet is really a last > fragment. > > So if you try to use those bits, all you will accomplish is flooding the > reassembly cache. > > Joe > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From cpignata@cisco.com Thu Apr 21 21:08:25 2011 Return-Path: X-Original-To: int-area@ietfc.amsl.com Delivered-To: int-area@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4DB19E07CA for ; Thu, 21 Apr 2011 21:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLDqFiluhdKl for ; Thu, 21 Apr 2011 21:08:24 -0700 (PDT) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfc.amsl.com (Postfix) with ESMTP id 2EACDE07C0 for ; Thu, 21 Apr 2011 21:08:24 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3M48Mrc026258 for ; Thu, 21 Apr 2011 21:08:23 -0700 (PDT) Received: from [10.117.115.50] (rtp-cpignata-8911.cisco.com [10.117.115.50]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3M48Hcq017678 for ; Fri, 22 Apr 2011 00:08:17 -0400 (EDT) Message-ID: <4DB0FF31.3040707@cisco.com> Date: Fri, 22 Apr 2011 00:08:17 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: int-area@ietf.org References: <4D94BDA0.60104 02@isi.edu><4D9597D5.9080 6 04@isi.edu><4D95AA24.20105 02@isi.edu> <32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> <7281EED3-361F-4496-9FF4-44CDACE1AA0A@inf-net.nl> <6C3B397F-1C21-432D-9353-21FA97413917@inf-net.nl> In-Reply-To: <6C3B397F-1C21-432D-9353-21FA97413917@inf-net.nl> X-Enigmail-Version: 1.1.1 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Int-area] Recycle IPv4 bits 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: Fri, 22 Apr 2011 04:08:25 -0000 Teco, Fred, Joe, Apologies for jumping in late. Please see inline. On 4/4/2011 2:29 AM, Teco Boot wrote: > Fred, > > Op 1 apr 2011, om 15:52 heeft Templin, Fred L het volgende geschreven: > >> Teco, >> >> I am looking at RFC3931, Section 4.1.4. All it says is >> that the LCCE may fragment IPv4 packets > I do not agree with this interpretation and I have a different read of the second para of S4.1.4 of RFC 3931. This text says: For example, if an IPv4 packet arrives at an LCCE from a Remote System that, after encapsulation with its associated framing, L2TP, and IP, does not fit in the available path MTU towards its LCCE peer, the local LCCE may perform IPv4 fragmentation on the packet before tunnel encapsulation. And the key here is "the local LCCE may perform IPv4 fragmentation". Performing IPv4 fragmentation does not imply that the result is fragmenting a datagram (or a fragment). The result of the fragmentation procedure can just be check the DF and discard. When RFC 791 describes the fragmentation procedures, the first step is to compare the TL with the MTU, and if the TL > MTU then check the DF, and discard the datagram if DF is set. That is, check DF and discard is part of the "fragmentation procedure". This means that "perform IPv4 fragmentation" can be: if the datagram is too big for the tunnel, then check DF and if set then drop and send an ICMP3/4 to the source (with a Next-Hop MTU that accounts for the tunnel encap). I am aware of implementations that work like this. And this allows for PMTUD to work as if the tunnel is just another link. Excerpts of RFC 791 that support this are: An Example Fragmentation Procedure Procedure: IF TL =< MTU THEN Submit this datagram to the next step in datagram processing ELSE IF DF = 1 THEN discard the datagram ELSE To produce the first fragment: The paragraph of RFC3931 describes pre-fragmentation (i.e., fragmentation before encapsulation). This is further covered in the later S3.4 of RFC 4459: http://tools.ietf.org/html/rfc4459#section-3.4 3.4. Fragmentation of the Inner Packet A final possibility is fragmenting the inner packet, before encapsulation, in such a manner that the encapsulated packet fits in the tunnel's path MTU (discovered using PMTUD). However, one should note that only IPv4 supports this "in-flight" fragmentation; furthermore, it isn't allowed for packets where the Don't Fragment bit has been set. Even if one could ignore IPv6 completely, so many IPv4 host stacks send packets with the DF bit set that this would seem unfeasible. > I don't read RFC3931 like this. It says ideal solutions work with > RFC1191. And RFC2661 is normative reference, which point to RFC791. > >> - it does not >> say that the LCCE must honor the DF bit. > > It doesn't say the LCCE must not do illegal operations. I do agree > that it were better to mention a DF=0 condition. Make errata? I will provide my 2¢ to this errata on the l2tpext list. Thanks, -- Carlos. > Old: > An LCCE MAY fragment a packet before encapsulating it in L2TP. For > example, if an IPv4 packet arrives at an LCCE from a Remote System > that, after encapsulation with its associated framing, L2TP, and IP, > does not fit in the available path MTU towards its LCCE peer, the > local LCCE may perform IPv4 fragmentation on the packet before tunnel > encapsulation. > New: > An LCCE MAY fragment a packet before encapsulating it in L2TP. For > example, if an IPv4 packet with DF=1 arrives at an LCCE from a Remote System > that, after encapsulation with its associated framing, L2TP, and IP, > does not fit in the available path MTU towards its LCCE peer, the > local LCCE may perform IPv4 fragmentation on the packet before tunnel > encapsulation. > > Thanks, Teco > >> >> Fred >> >>> -----Original Message----- >>> From: Teco Boot [mailto:teco@inf-net.nl] >>> Sent: Friday, April 01, 2011 6:41 AM >>> To: Templin, Fred L >>> Cc: Joe Touch; int-area@ietf.org >>> Subject: Re: [Int-area] Recycle IPv4 bits >>> >>> Op 1 apr 2011, om 15:14 heeft Templin, Fred L het volgende geschreven: >>> >>>>> It is april 1st. Has the RFC to do with such date? >>>>> And again, since when do we respect bugs? >>>> >>>> Not an April Fools RFC, and I'm sure implementatons >>>> don't care so much which specs are violated. >>> >>> Please provide a pointer. >>> >>>>> Packets in the wild _can_ be manipulated. Especially >>>>> middleboxes that provide protection for payload sometimes >>>>> illegally change headers. >>>> >>>> Sure, but wouldn't that invalidate your desire to code >>>> something in the header at the source that you could >>>> count on still being there in the same form when the >>>> packet reaches the destination? >>> >>> The only guarantee to prevent malformed packets at >>> destination is to keep them at the source. >>> >>> Teco >>> >>> >>> > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From Fred.L.Templin@boeing.com Fri Apr 22 09:54:51 2011 Return-Path: X-Original-To: int-area@ietfc.amsl.com Delivered-To: int-area@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 13DE1E079A for ; Fri, 22 Apr 2011 09:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnz2uyyd1bDZ for ; Fri, 22 Apr 2011 09:54:50 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfc.amsl.com (Postfix) with ESMTP id E368DE0655 for ; Fri, 22 Apr 2011 09:54:49 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p3MGsjKN029759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Apr 2011 09:54:46 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p3MGsifD016423; Fri, 22 Apr 2011 11:54:45 -0500 (CDT) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p3MGsiGQ016400 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 22 Apr 2011 11:54:44 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Fri, 22 Apr 2011 09:54:44 -0700 From: "Templin, Fred L" To: Carlos Pignataro , "int-area@ietf.org" Date: Fri, 22 Apr 2011 09:54:43 -0700 Thread-Topic: [Int-area] Recycle IPv4 bits Thread-Index: AcwAyrOAurTn5oGtQJuEaRJ5ijDiywAQr8Ug Message-ID: References: <4D94BDA0.6010402@isi.edu> <4DB0FF34.30005@cisco.com> In-Reply-To: <4DB0FF34.30005@cisco.com> 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 Subject: Re: [Int-area] Recycle IPv4 bits 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: Fri, 22 Apr 2011 16:54:51 -0000 Section 8 of RFC4821 discusses host fragmentation using the same technique Joe is describing. Thanks - Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: int-area-bounces@ietf.org=20 > [mailto:int-area-bounces@ietf.org] On Behalf Of Carlos Pignataro > Sent: Thursday, April 21, 2011 9:08 PM > To: int-area@ietf.org > Subject: Re: [Int-area] Recycle IPv4 bits >=20 > Joe, >=20 > Please find one comment inline, which may have been discussed=20 > already in > the thread, apologies if I missed it. >=20 > On 3/31/2011 1:45 PM, Joe Touch wrote: > > Hi, Deco, > >=20 > > This proposal is a moot point; the FO needs to be zero for=20 > a packet to=20 > > be ATOMIC. see below: > >=20 > > On 3/31/2011 4:41 AM, Teco Boot wrote: > >> Having a discussion on recycling used IPv4 header bits, I made > >> a snapshot on what was in the air at same point in time, somewhere. > >> I found out the ID field of atomic packets was filled for almost > >> all packets. > >> > >> IPv4 total: 151081 > >> Atomic packets: 105357 (70%) > >> On atomic packets: > >> ID =3D=3D 0 1557 ( 1,5%) > >> ID !=3D 0 103800 ( 98,5%) > >> FO =3D=3D 0 105357 (100,0%) > >> > >> The Fragment Offset was always set on zero, I read this as unused. > >=20 > > That is incorrect. It is part of what makes a packet=20 > atomic, as per the=20 > > ipv4-id-update draft: > >=20 > > (DF=3D=3D1)&&(MF=3D=3D0)&&(frag_offset=3D=3D0) > >=20 > > Let's look at the cases: > >=20 > > DF MF FO > > 0 x x CAN FRAGMENT > > non-atomic packet that can be fragmented downstream; > > that fragmentation would overwrite MF and FO > >=20 > > 1 0 0 ATOMIC =09 > > basically this is a lot like saying > > "this is the first and last fragment" > >=20 > > 1 0 nonzero LAST FRAGMENT > > packet has already been fragmented and > > this is the last fragment > >=20 > > 1 1 0 FIRST FRAGMENT > > packet has already been fragmented, and this is the > > first fragment and NOT the last (other fragments > > with higher offsets are expected) > >=20 > > 1 1 nonzero MIDDLE FRAGMENT > > packet has already been fragmented, and this is > > not the first fragment, and other fragments are > > expected >=20 > In these last 3 cases you include fragments (first, middle, last) with > the DF bit set. This mimics IPv6's source-only fragmentation,=20 > but it is > not clear to me how common that is. >=20 > But if this is a spec exercise, RFC791 says 'An internet=20 > datagram can be > marked "don't fragment."' Agreed that perhaps such datagram can be a > complete datagram or a fragment (although I read the intention as > meaning a complete packet), but the use case is that so that the > receiver does not reassemble (hence meaning that it makes=20 > sense only in > a complete datagram). The examples of fragmentation=20 > procedures in RFC791 > do not set the DF bit. I know of systems that source-fragment without > setting the DF bit, and a fragment can in turn be fragmented=20 > in flight. > If the source is setting DF for fragments, is not following the > procedure in RFC 791? >=20 > Thanks, >=20 > -- Carlos. >=20 > >=20 > > Note that thus: > >=20 > > ATOMIC packets are *defined* by having all the FO bits as zero. > >=20 > > > What comes up in my mind: can we recycle the 13 fragment=20 > offset bits? > > > Instead of ID field? At least it may be a well defined=20 > starting point. > >=20 > > When the bits aren't zero, an otherwise ATOMIC packet is=20 > really a last=20 > > fragment. > >=20 > > So if you try to use those bits, all you will accomplish is=20 > flooding the=20 > > reassembly cache. > >=20 > > Joe > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > = From Fred.L.Templin@boeing.com Fri Apr 22 10:06:40 2011 Return-Path: X-Original-To: int-area@ietfc.amsl.com Delivered-To: int-area@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 09D8EE07C2 for ; Fri, 22 Apr 2011 10:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teMyDYEbu0nS for ; Fri, 22 Apr 2011 10:06:39 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfc.amsl.com (Postfix) with ESMTP id D6200E07BF for ; Fri, 22 Apr 2011 10:06:38 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p3MH6bZg007078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Apr 2011 10:06:37 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p3MH2CTa024327; Fri, 22 Apr 2011 10:02:12 -0700 (PDT) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p3MH2BmV024273 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 22 Apr 2011 10:02:12 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Fri, 22 Apr 2011 10:06:36 -0700 From: "Templin, Fred L" To: Carlos Pignataro , "int-area@ietf.org" Date: Fri, 22 Apr 2011 10:06:35 -0700 Thread-Topic: [Int-area] Recycle IPv4 bits Thread-Index: AcwAy15pLctltmybT3Cbdt+OnYTV7wAQq39Q Message-ID: References: <4D94BDA0.60104 02@isi.edu><4D9597D5.9080 6 04@isi.edu><4D95AA24.20 105 02@isi.edu><32AD7134-1900-40FA-9053-A649693FABBF@inf-net.nl> <7281EED3-3 61F-4496-9FF4-44CDACE1AA0A@inf-net.nl> <6C3B397F-1C21-432D-9353-21FA97413917@inf-net.nl> <4DB0FF31.3040707@cisco.com> In-Reply-To: <4DB0FF31.3040707@cisco.com> 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 Subject: Re: [Int-area] Recycle IPv4 bits 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: Fri, 22 Apr 2011 17:06:40 -0000 Carlos, It has been suggested in the past that "various types of VPN/tunneling equipment have resorted to ignoring the DF bit under some circumstances" (see Section 9.3 of 'draft=3Dietf-pmtud-method-04.txt'). Also, some documents have taken it upon themselves to be more explicit in their specifications of inner fragmentation relating to tunneling (see Section 5.4.1 of 'draft-ietf-lisp-11.txt').=20 Note that I never posted anything regarding RFC3931 to the list nor agreed that any errata should be written. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: int-area-bounces@ietf.org=20 > [mailto:int-area-bounces@ietf.org] On Behalf Of Carlos Pignataro > Sent: Thursday, April 21, 2011 9:08 PM > To: int-area@ietf.org > Subject: Re: [Int-area] Recycle IPv4 bits >=20 > Teco, Fred, Joe, >=20 > Apologies for jumping in late. Please see inline. >=20 > On 4/4/2011 2:29 AM, Teco Boot wrote: > > Fred, > > =20 > > Op 1 apr 2011, om 15:52 heeft Templin, Fred L het volgende=20 > geschreven: > >=20 > >> Teco, > >> > >> I am looking at RFC3931, Section 4.1.4. All it says is > >> that the LCCE may fragment IPv4 packets > >=20 >=20 > I do not agree with this interpretation and I have a different read of > the second para of S4.1.4 of RFC 3931. This text says: >=20 > For > example, if an IPv4 packet arrives at an LCCE from a Remote System > that, after encapsulation with its associated framing,=20 > L2TP, and IP, > does not fit in the available path MTU towards its LCCE peer, the > local LCCE may perform IPv4 fragmentation on the packet=20 > before tunnel > encapsulation. >=20 > And the key here is "the local LCCE may perform IPv4 fragmentation". > Performing IPv4 fragmentation does not imply that the result is > fragmenting a datagram (or a fragment). The result of the=20 > fragmentation > procedure can just be check the DF and discard. >=20 > When RFC 791 describes the fragmentation procedures, the first step is > to compare the TL with the MTU, and if the TL > MTU then check the DF, > and discard the datagram if DF is set. That is, check DF and=20 > discard is > part of the "fragmentation procedure". This means that "perform IPv4 > fragmentation" can be: if the datagram is too big for the tunnel, then > check DF and if set then drop and send an ICMP3/4 to the=20 > source (with a > Next-Hop MTU that accounts for the tunnel encap). I am aware of > implementations that work like this. And this allows for PMTUD to work > as if the tunnel is just another link. >=20 > Excerpts of RFC 791 that support this are: >=20 > An Example Fragmentation Procedure >=20 > Procedure: >=20 > IF TL =3D< MTU THEN Submit this datagram to the next step > in datagram processing ELSE IF DF =3D 1 THEN discard the > datagram ELSE > To produce the first fragment: >=20 >=20 > The paragraph of RFC3931 describes pre-fragmentation (i.e., > fragmentation before encapsulation). This is further covered in the > later S3.4 of RFC 4459: >=20 > http://tools.ietf.org/html/rfc4459#section-3.4 >=20 > 3.4. Fragmentation of the Inner Packet >=20 > A final possibility is fragmenting the inner packet, before > encapsulation, in such a manner that the encapsulated=20 > packet fits in > the tunnel's path MTU (discovered using PMTUD). However,=20 > one should > note that only IPv4 supports this "in-flight" fragmentation; > furthermore, it isn't allowed for packets where the Don't Fragment > bit has been set. Even if one could ignore IPv6=20 > completely, so many > IPv4 host stacks send packets with the DF bit set that this would > seem unfeasible. >=20 >=20 > > I don't read RFC3931 like this. It says ideal solutions work with=20 > > RFC1191. And RFC2661 is normative reference, which point to RFC791. > >=20 > >> - it does not > >> say that the LCCE must honor the DF bit. > >=20 > > It doesn't say the LCCE must not do illegal operations. I do agree=20 > > that it were better to mention a DF=3D0 condition. Make errata? >=20 > I will provide my 2=A2 to this errata on the l2tpext list. >=20 > Thanks, >=20 > -- Carlos. >=20 > > Old: > > An LCCE MAY fragment a packet before encapsulating it in=20 > L2TP. For > > example, if an IPv4 packet arrives at an LCCE from a=20 > Remote System > > that, after encapsulation with its associated framing,=20 > L2TP, and IP, > > does not fit in the available path MTU towards its LCCE peer, the > > local LCCE may perform IPv4 fragmentation on the packet=20 > before tunnel > > encapsulation.=20 > > New: > > An LCCE MAY fragment a packet before encapsulating it in=20 > L2TP. For > > example, if an IPv4 packet with DF=3D1 arrives at an LCCE=20 > from a Remote System > > that, after encapsulation with its associated framing,=20 > L2TP, and IP, > > does not fit in the available path MTU towards its LCCE peer, the > > local LCCE may perform IPv4 fragmentation on the packet=20 > before tunnel > > encapsulation.=20 > >=20 > > Thanks, Teco > >=20 > >> > >> Fred=20 > >> > >>> -----Original Message----- > >>> From: Teco Boot [mailto:teco@inf-net.nl]=20 > >>> Sent: Friday, April 01, 2011 6:41 AM > >>> To: Templin, Fred L > >>> Cc: Joe Touch; int-area@ietf.org > >>> Subject: Re: [Int-area] Recycle IPv4 bits > >>> > >>> Op 1 apr 2011, om 15:14 heeft Templin, Fred L het=20 > volgende geschreven: > >>> > >>>>> It is april 1st. Has the RFC to do with such date? > >>>>> And again, since when do we respect bugs? > >>>> > >>>> Not an April Fools RFC, and I'm sure implementatons > >>>> don't care so much which specs are violated. > >>> > >>> Please provide a pointer. > >>> > >>>>> Packets in the wild _can_ be manipulated. Especially=20 > >>>>> middleboxes that provide protection for payload sometimes=20 > >>>>> illegally change headers. > >>>> > >>>> Sure, but wouldn't that invalidate your desire to code > >>>> something in the header at the source that you could > >>>> count on still being there in the same form when the > >>>> packet reaches the destination? > >>> > >>> The only guarantee to prevent malformed packets at=20 > >>> destination is to keep them at the source. > >>> > >>> Teco > >>> > >>> > >>> > >=20 > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > = From cpignata@cisco.com Fri Apr 22 17:48:43 2011 Return-Path: X-Original-To: int-area@ietfc.amsl.com Delivered-To: int-area@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 96052E0694 for ; Fri, 22 Apr 2011 17:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.335 X-Spam-Level: X-Spam-Status: No, score=-107.335 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsTGAtBjWDU1 for ; Fri, 22 Apr 2011 17:48:42 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 5660FE066B for ; Fri, 22 Apr 2011 17:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=4742; q=dns/txt; s=iport; t=1303519722; x=1304729322; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=93OLB1GOul8hIvol11cF2LV2o3LUioUsTMsCtPk/H98=; b=b3y2Ez08DKqMpSG6pAmeQ4OFCfKcEWRjiCEAkqPkGlJJsofQy6WgPe+7 EOYasud+PSVQPLTcmeq0TvrNkMp2QxM4bRKyfw3VR+sM8Ur0pD2uR7CxX c8W5d0mEXzu96sKnrBIk6w6eqOhWSJLH1+pXTL25a0PBAq4qqBO7rNsU9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQBALEhsk2tJXG+/2dsb2JhbACXXY0KfwJ3iHCfV5xIhXYEjjWEDg X-IronPort-AV: E=Sophos;i="4.64,256,1301875200"; d="scan'208";a="435141396" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-1.cisco.com with ESMTP; 23 Apr 2011 00:48:41 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3N0mfkk012878; Sat, 23 Apr 2011 00:48:41 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 19:48:40 -0500 Received: from 72.163.63.13 ([72.163.63.13]) by XMB-RCD-206.cisco.com ([72.163.62.213]) with Microsoft Exchange Server HTTP-DAV ; Sat, 23 Apr 2011 00:48:40 +0000 References: <4D94BDA0.6010402@isi.edu> <4DB0FF34.30005@cisco.com> Content-Transfer-Encoding: quoted-printable From: "Carlos Pignataro (cpignata)" Thread-Topic: [Int-area] Recycle IPv4 bits Thread-Index: AcwBUDAcO6Cu9j6LRxWfE0MJ8hrAYg== Content-Type: text/plain; charset="us-ascii" In-Reply-To: Message-ID: <6BB92446-28DF-4ECA-9E96-7D1AA736FEDA@cisco.com> Date: Fri, 22 Apr 2011 20:43:47 -0400 To: "Templin, Fred L" MIME-Version: 1.0 (iPhone Mail 8H7) X-OriginalArrivalTime: 23 Apr 2011 00:48:40.0432 (UTC) FILETIME=[302F4F00:01CC0150] Cc: int-area@ietf.org Subject: Re: [Int-area] Recycle IPv4 bits 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: Sat, 23 Apr 2011 00:48:43 -0000 Sure, but this technique is not in RFC 791 which is what I understand the ip= v4-id I-D cites and is based on. For the purposes of the ident field, for a f= ragment (first, middle, or last) the DF value is a don't care. Thanks, Thumb typed by Carlos Pignataro. On Apr 22, 2011, at 12:55 PM, "Templin, Fred L" w= rote: > Section 8 of RFC4821 discusses host fragmentation using > the same technique Joe is describing. >=20 > Thanks - Fred > fred.l.templin@boeing.com=20 >=20 >> -----Original Message----- >> From: int-area-bounces@ietf.org=20 >> [mailto:int-area-bounces@ietf.org] On Behalf Of Carlos Pignataro >> Sent: Thursday, April 21, 2011 9:08 PM >> To: int-area@ietf.org >> Subject: Re: [Int-area] Recycle IPv4 bits >>=20 >> Joe, >>=20 >> Please find one comment inline, which may have been discussed=20 >> already in >> the thread, apologies if I missed it. >>=20 >> On 3/31/2011 1:45 PM, Joe Touch wrote: >>> Hi, Deco, >>>=20 >>> This proposal is a moot point; the FO needs to be zero for=20 >> a packet to=20 >>> be ATOMIC. see below: >>>=20 >>> On 3/31/2011 4:41 AM, Teco Boot wrote: >>>> Having a discussion on recycling used IPv4 header bits, I made >>>> a snapshot on what was in the air at same point in time, somewhere. >>>> I found out the ID field of atomic packets was filled for almost >>>> all packets. >>>>=20 >>>> IPv4 total: 151081 >>>> Atomic packets: 105357 (70%) >>>> On atomic packets: >>>> ID =3D=3D 0 1557 ( 1,5%) >>>> ID !=3D 0 103800 ( 98,5%) >>>> FO =3D=3D 0 105357 (100,0%) >>>>=20 >>>> The Fragment Offset was always set on zero, I read this as unused. >>>=20 >>> That is incorrect. It is part of what makes a packet=20 >> atomic, as per the=20 >>> ipv4-id-update draft: >>>=20 >>> (DF=3D=3D1)&&(MF=3D=3D0)&&(frag_offset=3D=3D0) >>>=20 >>> Let's look at the cases: >>>=20 >>> DF MF FO >>> 0 x x CAN FRAGMENT >>> non-atomic packet that can be fragmented downstream; >>> that fragmentation would overwrite MF and FO >>>=20 >>> 1 0 0 ATOMIC =20 >>> basically this is a lot like saying >>> "this is the first and last fragment" >>>=20 >>> 1 0 nonzero LAST FRAGMENT >>> packet has already been fragmented and >>> this is the last fragment >>>=20 >>> 1 1 0 FIRST FRAGMENT >>> packet has already been fragmented, and this is the >>> first fragment and NOT the last (other fragments >>> with higher offsets are expected) >>>=20 >>> 1 1 nonzero MIDDLE FRAGMENT >>> packet has already been fragmented, and this is >>> not the first fragment, and other fragments are >>> expected >>=20 >> In these last 3 cases you include fragments (first, middle, last) with >> the DF bit set. This mimics IPv6's source-only fragmentation,=20 >> but it is >> not clear to me how common that is. >>=20 >> But if this is a spec exercise, RFC791 says 'An internet=20 >> datagram can be >> marked "don't fragment."' Agreed that perhaps such datagram can be a >> complete datagram or a fragment (although I read the intention as >> meaning a complete packet), but the use case is that so that the >> receiver does not reassemble (hence meaning that it makes=20 >> sense only in >> a complete datagram). The examples of fragmentation=20 >> procedures in RFC791 >> do not set the DF bit. I know of systems that source-fragment without >> setting the DF bit, and a fragment can in turn be fragmented=20 >> in flight. >> If the source is setting DF for fragments, is not following the >> procedure in RFC 791? >>=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >>>=20 >>> Note that thus: >>>=20 >>> ATOMIC packets are *defined* by having all the FO bits as zero. >>>=20 >>>> What comes up in my mind: can we recycle the 13 fragment=20 >> offset bits? >>>> Instead of ID field? At least it may be a well defined=20 >> starting point. >>>=20 >>> When the bits aren't zero, an otherwise ATOMIC packet is=20 >> really a last=20 >>> fragment. >>>=20 >>> So if you try to use those bits, all you will accomplish is=20 >> flooding the=20 >>> reassembly cache. >>>=20 >>> Joe >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >>>=20 >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >>=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20