From nobody Wed Mar 2 17:21:14 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8081B3788 for ; Wed, 2 Mar 2016 17:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYE8qwtLdmPv for ; Wed, 2 Mar 2016 17:21:11 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF57E1B3786 for ; Wed, 2 Mar 2016 17:21:11 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id s68so2913161qkh.3 for ; Wed, 02 Mar 2016 17:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=AsbbGPv/PQ7H0D+lghKE5pkXX22T+V/A1aQHEnGeVAA=; b=uYZCsZyjQWy8yP0hkgG0EjRG0hB/nvyxobP8yuNG6vVx0IZGZ4YJIJ1Kp26nhUaqlx SvQduI2c8KUoxowWaKwSyM/y56YMnT4+63Lq09PkU3cGXQTECUBQb+Ok//KH3CmFRToA ovp019Fn7FSSkq+twSZzFp2uvYpT1QSNFy/gBSbGgy9pEG2+0SwXsD4NGXTjxW67GL9d hibEsfvZ/vF6WB464Q/VrxrgCTTwRRc03PJSczZEDJCQ5XMILnfSAxc2jLZBd6ZY23eX QV0hbmik+31SCMVB0kWxX6kJkMcq83ytU/c4EEi81081eQH0c67aOcq9fNbQ6+7OY/vC 50gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=AsbbGPv/PQ7H0D+lghKE5pkXX22T+V/A1aQHEnGeVAA=; b=aFLUO+0cFLf8IHwBOWVWLzhgCfxrFQuh34fV94FWIGOwqGeRN7IweFdz+IvDmb+76Y G45Jb+N3zxARY6LOnnc4Hyp7CQQ+8J/oTeR1qMIlF9K1IcLXIvLvW5jutB1OLoknxa02 rnAcUWnjbCajSR20VuBNRVw3GL5EQJB/w8tS0HJybmGB/hMcv2F/DfvQQEggipDmG1kP X8Onh7u+gof/uUkNZpsJTUGqJPbsXLwx1dH7jMnq6N4a2DxC/7pzskICDBR3VtdlNoZ3 FtXYCKUjoZDywwGBW6IUI6PmPylUbItA8qDv46SQcqDoW+tKqkq56FT1lGTBI5CvddxM axGg== X-Gm-Message-State: AD7BkJJGWX68iIwkxPMab1au2oNvjun6S2kh6C718ZRBmGXBFQm3d6k0DRFwPtQ+f2rx/30f X-Received: by 10.55.78.207 with SMTP id c198mr36901638qkb.34.1456968070839; Wed, 02 Mar 2016 17:21:10 -0800 (PST) Received: from [192.168.2.11] (dsl.dynamic.190-116-74-243.electronicbox.net. [74.116.190.243]) by smtp.gmail.com with ESMTPSA id 123sm15916377qhu.22.2016.03.02.17.21.09 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2016 17:21:09 -0800 (PST) From: Juan Carlos Zuniga Content-Type: multipart/alternative; boundary=Apple-Mail-1A550968-1960-480B-8397-CDBA1F6126B0 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: <5B5ECA6A-9B93-4E84-BCF0-61E0B776C467@ieee.org> Date: Wed, 2 Mar 2016 20:21:08 -0500 To: int-area@ietf.org X-Mailer: iPhone Mail (13D15) Archived-At: Subject: [Int-area] Call for agenda items @ IETF 95 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 01:21:13 -0000 --Apple-Mail-1A550968-1960-480B-8397-CDBA1F6126B0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi all, We have requested a slot for the IntArea WG at IETF 95 in Buenos Aires. Please send along requests for agenda time, and remember that we will give p= riority to WG drafts and drafts that have already received significant discu= ssion. Cheers,=20 Juan Carlos, Suresh & Wassim= --Apple-Mail-1A550968-1960-480B-8397-CDBA1F6126B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi all,

We have requested a slot for the IntArea WG at IETF 95 in Buenos Aires.

Please send along requests for agenda time, and remember that we will give priority to WG drafts and drafts that have already received significant discussion.

Cheers, 

Juan Carlos, Suresh & Wassim

--Apple-Mail-1A550968-1960-480B-8397-CDBA1F6126B0-- From nobody Thu Mar 10 09:41:43 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80CB12DB11; Thu, 10 Mar 2016 09:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1MA-s-qY99D; Thu, 10 Mar 2016 09:41:40 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A3F12DAA4; Thu, 10 Mar 2016 09:41:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.24,316,1455004800"; d="asc'?scan'208,217";a="101880457" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx143-out.netapp.com with ESMTP; 10 Mar 2016 09:36:39 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 10 Mar 2016 09:36:39 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::2562:be45:d6a5:1743%21]) with mapi id 15.00.1156.000; Thu, 10 Mar 2016 09:36:39 -0800 From: "Eggert, Lars" To: "Poscic, Kristian (Nokia - US)" Thread-Topic: UDP zero-checksum in IPv4 Thread-Index: AdF68bLe5SvLau+lRPK5dqDoIJSUhwARMDWA Date: Thu, 10 Mar 2016 17:36:39 +0000 Message-ID: <3F71FEFD-65AC-4158-B923-E11D1924E18F@netapp.com> References: <7921F977B17D5B49B8DCC955A339D2F0BEA21EC5@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F0BEA21EC5@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.34] Content-Type: multipart/signed; boundary="Apple-Mail=_10DCC4CE-F627-450C-BD98-BEF856948BBB"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "softwires@ietf.org" , "int-area@ietf.org" , "tsv-area@ietf.org" , "maprg@irtf.org" Subject: Re: [Int-area] UDP zero-checksum in IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 17:41:41 -0000 --Apple-Mail=_10DCC4CE-F627-450C-BD98-BEF856948BBB Content-Type: multipart/alternative; boundary="Apple-Mail=_6DF29D7E-AA17-4A2F-8ADC-8052037937A0" --Apple-Mail=_6DF29D7E-AA17-4A2F-8ADC-8052037937A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 CC maprg On 2016-03-10, at 18:29, Poscic, Kristian (Nokia - US) = wrote: >=20 > Hi, >=20 > Does anyone have any info on the percentage of UDP packets with = zero-checksum > for IPv4 packets in today=E2=80=99s networks (enterprise, internet, = any network). > Seems like there is not a whole lot of info about this on the WEB. = Anyone has any firsthand/realworld experience with this? Thanks. >=20 > Kris --Apple-Mail=_6DF29D7E-AA17-4A2F-8ADC-8052037937A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
CC maprg

On 2016-03-10, at 18:29, Poscic, Kristian (Nokia - US) = <kristian.poscic@nokia.com> wrote:

Hi,
 
Does = anyone have any info on the percentage of UDP packets with = zero-checksum
for IPv4 packets in today=E2=80=99s networks (enterprise, = internet, any network). 
Seems like there is not a whole lot of = info about this on the WEB. Anyone has any firsthand/realworld = experience with this? Thanks.
 
Kris

= --Apple-Mail=_6DF29D7E-AA17-4A2F-8ADC-8052037937A0-- --Apple-Mail=_10DCC4CE-F627-450C-BD98-BEF856948BBB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJW4bCmAAoJEFS1wwm/cMFX2YsP/26uOFWJG0nj+IYxkRNWQHkx 0C3a7MfMFqLtOYdudTE58Gb96l8yoqvKPsm9kY0pFAwnVsmv1PIq1P74Rhyy2Wim MpmB8QHRqoMEa3/qTvbvo5C545t1IZqmkOZQxthouS3BE6czdIpAYkna8iHTMQD4 UHbP/HVYDMUDoBpjEYItYOeDAepNUqmcAu/NReTdeB7LnOV1JF1ybKQJBa+D1thy 1+21rZ5eQv8X9tNd17GrkD3piztGJrZ8pVZGvwdrO2sezfATbfA/69HVkBHaG/NR yreJNxTqpikC+BqBfKpGKUKjOka8s1MKqMWrOWC+NuTXITgJL/U1HCbhHMNf3EF+ h7rM7Hrp3zVcncYqPqtZgRGmuFN2lkNvxvqxPyxOoPOut1mFR07rMs574cXcu4Ng s/GAih57hkrmkiVhHdw2xTfS03TizV6JJmeB7+iCOC7XG8dRzOg38504KLw5lX9C BfFTcAaeNGSk5yEDcc6SxjemtzNQfFQTXQ3Ls9BdlaTto00zdTtmPFJwh+fE/F+w akgZD2XM93RWnbGGzwQ2AQgp1zRxpa8QEV8xPXricGOX6xKHtFk6EUWJgPp9qH5i VArYxvJduLLUOmG2sEbDSa9dbW3hGK5AgGowJg419hJKzrlhVJJcZQFt3A8pr9cw BLeK/PZ8yD2ewDsbeHoS =8SSK -----END PGP SIGNATURE----- --Apple-Mail=_10DCC4CE-F627-450C-BD98-BEF856948BBB-- From nobody Thu Mar 10 13:46:38 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A2F12DDCD; Thu, 10 Mar 2016 13:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.522 X-Spam-Level: X-Spam-Status: No, score=-114.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEKeLYZEaPK3; Thu, 10 Mar 2016 13:46:30 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CBB12DAC3; Thu, 10 Mar 2016 13:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3153; q=dns/txt; s=iport; t=1457646390; x=1458855990; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=68oudN2fAv6Xpj99qPGzqhIVTkbkJ4D2u9Z9HpKgBo0=; b=LJTVCUiWqBcB/B+hAvvFUvNa7MW9zEg2m6MngAICe5vRfv1d7r4begfR Woz7aUPSEmIu+vqHcoSEleZ6te0SPwLPCU6bvTzLl3l+yXw5a4KRqTA/l jNaAaI571ek91L1JrY/P4xNW/e9MOu7TQsguKWAf89a7A2CW3k1EXBPpU w=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DGAgC56uFW/49dJa1egz5SbQa6XQ6Bb?= =?us-ascii?q?R2FcgKBRTgUAQEBAQEBAWQnhEEBAQEDASNWBQsCAQgYKgICMiUCBA4FDogOCA6?= =?us-ascii?q?uJo8bAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQQEiAsIgkeHOiuBDwWXPAGDF4Flb?= =?us-ascii?q?YgOjn+OaQEeAUOCAByBSGqJU34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,317,1454976000"; d="asc'?scan'208";a="247834725" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2016 21:46:29 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u2ALkShA027506 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Mar 2016 21:46:29 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 10 Mar 2016 15:46:27 -0600 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Thu, 10 Mar 2016 15:46:27 -0600 From: "Fred Baker (fred)" To: "Poscic, Kristian (Nokia - US)" Thread-Topic: UDP zero-checksum in IPv4 Thread-Index: AQHRexZMHdNSG0ujtEyQmHm90bfQ6w== Date: Thu, 10 Mar 2016 21:46:27 +0000 Message-ID: <64044A42-0775-4ABC-B7BD-3541316B0E81@cisco.com> References: <7921F977B17D5B49B8DCC955A339D2F0BEA21EC5@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F0BEA21EC5@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_644AC4A5-7C10-481D-86E3-7BB8B33BBB6F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "softwires@ietf.org" , "int-area@ietf.org" , "tsv-area@ietf.org" , "maprg@irtf.org" Subject: Re: [Int-area] UDP zero-checksum in IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 21:46:33 -0000 --Apple-Mail=_644AC4A5-7C10-481D-86E3-7BB8B33BBB6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 10, 2016, at 9:29 AM, Poscic, Kristian (Nokia - US) = wrote: >=20 > Hi, >=20 > Does anyone have any info on the percentage of UDP packets with = zero-checksum > for IPv4 packets in today=E2=80=99s networks (enterprise, internet, = any network). > Seems like there is not a whole lot of info about this on the WEB. = Anyone has any firsthand/realworld experience with this? Thanks. >=20 > Kris A good place to start might be https://tools.ietf.org/html/rfc6936 6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums. G. Fairhurst, M. Westerlund. April 2013. (Format: TXT=3D99557 bytes) (Status: PROPOSED STANDARD) (DOI: = 10.17487/RFC6936) The big consideration there is a middleware device (usually a router, = but potentially something else) that is receiving packets at line rate = one a set of interfaces and funneling them to another interface on which = it is obligated to send them tunneled in UDP packets, or a corollary = device at the other end of the tunnel. It would be theoretically = possible to add hardware that could parse to the correct point and = calculate the checksum while the data being received was stored into = memory. However, practically, that is far more likely to be done as a = second step, to packets it is applicable to. The configuration of a = tunnel that creates or verifies a UDP checksum on a tunneled datagram, = in such a case, is essentially a DOS vector. Any discussion of "percentages of traffic for which X is true in the = Internet" are necessarily vague and hand-wavy. The Internet is the = proverbial elephant, and those that would statistically describe it are = the proverbial philosophers. How one describes it has a lot to do with = what part of it one touches. --Apple-Mail=_644AC4A5-7C10-481D-86E3-7BB8B33BBB6F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVuHrMEayAOS/EQ8MAQIJvg//dUFOezUPGav/tVCUhcWEFx8wBfEMB6xF kN405yj/+EylW3yjlXqIiuGqriewzlzGSOitjDyQ6tF13vyJBJ03fmqDqvC9ABcE tqcGxRCExexPJxe9aLsI7kmedMYF0GS3xt7UEKKdBMWDfAjBdmMJMADkU+JOsxSp jvJ985R0+z1d86nGFv+TVuiNMIuB1Ihtoz65ved2svG3vXALmGP8XWmXpK84kys+ DPKlt36Q1ZOAEEGw7sSu81bvtqQniC2hrz8wpPoB0WYE66zrROgCLY3nTmeBx4vI XuGT17apJ3l+8YPsWrVxCs6o5XDwQLb63k38dTuoa+JF3Wj7o5yYn7CyaKHw3IoY QtqJyGvzqKWFo+Q40SxCbepeQ73CuyXhmXY2UQVTCwbNFFsgRN1w5WuUp+NR76HR tAMxjOwtbufcNj1KykEndcClQyS9sdNWdHlL1t00X150C7Dw1Q5Dc4/oJwynyaoH N9sROBUPDGqcn44I3Zulc2fp47j44uJPUMMP/k0r9DmbG+K4jknRm0opKeBGHGKG KxqyTiFymr8xdVl+YAicQZAEFOYWcFKvmJPI2NPLFMePL66l9TiGkngNslsYLYDI tEY5l2+G8EeIK3NZxe+UqOoVgeYrzJgbu1PHTcq1DsLuCTKM4KyR5AeuHOk4K3bf uHxAObnpLHk= =XBFD -----END PGP SIGNATURE----- --Apple-Mail=_644AC4A5-7C10-481D-86E3-7BB8B33BBB6F-- From nobody Thu Mar 10 15:45:22 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4553812DE07 for ; Thu, 10 Mar 2016 15:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dnLtRlLWTeZ for ; Thu, 10 Mar 2016 15:45:19 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B47A12DDF2 for ; Thu, 10 Mar 2016 15:45:19 -0800 (PST) Received: by mail-ig0-x22c.google.com with SMTP id z8so5526366ige.0 for ; Thu, 10 Mar 2016 15:45:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=74J6scK5AWOEdW/7yXQCQyIDe8ZpIIqb6cm9nlagVpQ=; b=qjmELA1KAXPPr/NyciN7vASk5I0QVk5IRoHssMyNN63VXUx62obsocjpRjfIkKTmrb XG1R1xpVKpsGq3Y+mtK/mkOMotzB9bussmfFV4pOZVuOnC0tBUju84xeFQkz3+3xMH4z FQE0UDvf7wX0ZwJ5fheUSpGuFZKPZ/MIOXlk3uZ5dZmWbEn5Az4SSTyxmdsYzu7gOT37 /Lxnq6h4JSHzHmQST4E1xJAWxYoTPPHEgbEOfQwleEPbyjvFn7zpEZbJ5dHNWD5AZlDi GH8Wjw87bqVIOcH2N0DbSDpYWaLt5BEUt1/owCHEKUryLvEfYR8rHqN7bmOHSKNh3gpS fJ1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=74J6scK5AWOEdW/7yXQCQyIDe8ZpIIqb6cm9nlagVpQ=; b=JZMMI+9yAGzH4bUHAu8ertQ8lGUcfSwHfyiZmXscw/I3mZLnBP403glpeUgYnNpuQR oLMpeSWP1b8p2ENidpdLcd+doJtF0PQMWlTpO/hfxZx47H2PrySaJXoRFQT848c0HwiG SR+NrzFNQSajIcT3xWmoRRiuPycF9ka6bNo6qfvUNRaNJKsQGc0UBNSW3L8oOFrbzrhj 5WrjzokGE6ZoGdq7kwSLWESDgJkkbSm/f/gbqV3RH5jf1rKTZWFVKsRk1HCkTPlWfOXs KfWFCQrU6rmKMnT0msoNnk4A9V0LACDEzB3020wXGm4TGRPMT3PcVSalcRMlPpPetzQX ZSVA== X-Gm-Message-State: AD7BkJImgcnEogzYKmEDmyW0tR/UprOUjvDoL21eZj0DLzNfWClEfvIVxYYOlWwQiB+WMr3/fSj+6P3zuucTBA== MIME-Version: 1.0 X-Received: by 10.50.141.164 with SMTP id rp4mr1059527igb.89.1457653518569; Thu, 10 Mar 2016 15:45:18 -0800 (PST) Received: by 10.107.160.203 with HTTP; Thu, 10 Mar 2016 15:45:18 -0800 (PST) In-Reply-To: <64044A42-0775-4ABC-B7BD-3541316B0E81@cisco.com> References: <7921F977B17D5B49B8DCC955A339D2F0BEA21EC5@US70UWXCHMBA05.zam.alcatel-lucent.com> <64044A42-0775-4ABC-B7BD-3541316B0E81@cisco.com> Date: Thu, 10 Mar 2016 15:45:18 -0800 Message-ID: From: Tom Herbert To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "softwires@ietf.org" , "int-area@ietf.org" , "tsv-area@ietf.org" , "Poscic, Kristian \(Nokia - US\)" , "maprg@irtf.org" Subject: Re: [Int-area] UDP zero-checksum in IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 23:45:21 -0000 On Thu, Mar 10, 2016 at 1:46 PM, Fred Baker (fred) wrote: > >> On Mar 10, 2016, at 9:29 AM, Poscic, Kristian (Nokia - US) wrote: >> >> Hi, >> >> Does anyone have any info on the percentage of UDP packets with zero-che= cksum >> for IPv4 packets in today=E2=80=99s networks (enterprise, internet, any = network). >> Seems like there is not a whole lot of info about this on the WEB. Anyon= e has any firsthand/realworld experience with this? Thanks. >> >> Kris > > A good place to start might be https://tools.ietf.org/html/rfc6936 > 6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero > Checksums. G. Fairhurst, M. Westerlund. April 2013. (Format: > TXT=3D99557 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC693= 6) > > The big consideration there is a middleware device (usually a router, but= potentially something else) that is receiving packets at line rate one a s= et of interfaces and funneling them to another interface on which it is obl= igated to send them tunneled in UDP packets, or a corollary device at the o= ther end of the tunnel. It would be theoretically possible to add hardware = that could parse to the correct point and calculate the checksum while the = data being received was stored into memory. However, practically, that is f= ar more likely to be done as a second step, to packets it is applicable to.= The configuration of a tunnel that creates or verifies a UDP checksum on a= tunneled datagram, in such a case, is essentially a DOS vector. > Note that this problem is mostly specific to switches that lack HW to efficiently perform checksum. On the host side, we have long standing support in NIC HW to to perform checksum offload (whether UDP sends zero checksum in IPv6, checksums are always used in TCP so we need a host solution regardless!). Due to the capabilities of currently deployed NICs, we get much better performance with the UDP checksum enabled for tunnels when sourcing or terminating tunnels on the same host that sends or receive an encapsulated TCP packet-- in fact the default was recently changed in Linux to enable checksum for UDP tunnels (it can still be disabled by per tunnel configuration). Tom > Any discussion of "percentages of traffic for which X is true in the Inte= rnet" are necessarily vague and hand-wavy. The Internet is the proverbial e= lephant, and those that would statistically describe it are the proverbial = philosophers. How one describes it has a lot to do with what part of it one= touches. > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From kristian.poscic@nokia.com Thu Mar 10 09:29:46 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D6512DA7D; Thu, 10 Mar 2016 09:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewVhnVDTButh; Thu, 10 Mar 2016 09:29:43 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767A712D9C0; Thu, 10 Mar 2016 09:29:43 -0800 (PST) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 3D73D4CE65A82; Thu, 10 Mar 2016 17:29:40 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u2AHTgvk016143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Mar 2016 17:29:42 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u2AHTf2J001376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Mar 2016 17:29:42 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.7]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 10 Mar 2016 12:29:41 -0500 From: "Poscic, Kristian (Nokia - US)" To: "tsv-area@ietf.org" , "softwires@ietf.org" , "int-area@ietf.org" Thread-Topic: UDP zero-checksum in IPv4 Thread-Index: AdF68bLe5SvLau+lRPK5dqDoIJSUhw== Date: Thu, 10 Mar 2016 17:29:40 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F0BEA21EC5@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F0BEA21EC5US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 11 Mar 2016 18:26:48 -0800 Subject: [Int-area] UDP zero-checksum in IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 17:31:12 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F0BEA21EC5US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Does anyone have any info on the percentage of UDP packets with zero-checks= um for IPv4 packets in today's networks (enterprise, internet, any network). Seems like there is not a whole lot of info about this on the WEB. Anyone h= as any firsthand/realworld experience with this? Thanks. Kris --_000_7921F977B17D5B49B8DCC955A339D2F0BEA21EC5US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Does anyone have any info on the percentage of UD= P packets with zero-checksum

for IPv4 packets in today’s networks (enter= prise, internet, any network). 

Seems like there is not a whole lot of info about= this on the WEB. Anyone has any firsthand/realworld experience with this? = Thanks.

 

Kris

 

--_000_7921F977B17D5B49B8DCC955A339D2F0BEA21EC5US70UWXCHMBA05z_-- From nobody Fri Mar 11 18:26:52 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFDB12E0BD; Thu, 10 Mar 2016 22:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q137umBvLCCD; Thu, 10 Mar 2016 22:03:36 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA0012E0B7; Thu, 10 Mar 2016 22:03:36 -0800 (PST) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id A3376F95F7E97; Fri, 11 Mar 2016 06:03:34 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u2B63Zoj013820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Mar 2016 06:03:35 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u2B63XXN006085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Mar 2016 06:03:34 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 11 Mar 2016 01:03:34 -0500 From: "Poscic, Kristian (Nokia - US)" To: EXT Tom Herbert , "Fred Baker (fred)" Thread-Topic: [Int-area] UDP zero-checksum in IPv4 Thread-Index: AdF68bLe5SvLau+lRPK5dqDoIJSUhwAToJGAAAQmmgAAAgwbsA== Date: Fri, 11 Mar 2016 06:03:33 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F0BEA2DF61@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <7921F977B17D5B49B8DCC955A339D2F0BEA21EC5@US70UWXCHMBA05.zam.alcatel-lucent.com> <64044A42-0775-4ABC-B7BD-3541316B0E81@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 11 Mar 2016 18:26:48 -0800 Cc: "softwires@ietf.org" , "tsv-area@ietf.org" , "int-area@ietf.org" , "maprg@irtf.org" Subject: Re: [Int-area] UDP zero-checksum in IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 06:03:39 -0000 VGhhbmtzLCB0aGlzIGlzIGFsbCBoZWxwZnVsLg0KQnV0IGxldCBtZSByZXBocmFzZSB0aGUgcXVl c3Rpb24gaW4gaG9wZSB0byBnZXQgYSBiaXQgbW9yZSBxdWFudGlmaWFibGUgYW5zd2VyOg0KLSBj YW4gc29tZSBzaGFyZSB1c2VyIGV4cGVyaWVuY2UgKGJyb2tlbiBhcHBzKSB3aGVuIHRyYWZmaWMg d2l0aCB6ZXJvIFVEUCBjaGVja3N1bSBpcyBkcm9wcGVkPw0KDQpUaGUgYXZhaWxhYmxlIG9wdGlv bnMgd2hlbiB0cmFuc2xhdGluZyovdHVubmVsaW5nIElQdjQgVURQIHBhY2tldCB3aXRoIHplcm8t Y2hlY2tzdW0gaW50byBJUHY2Og0KMSkgZHJvcCBJUHY0IHBhY2tldHMgd2l0aCB6ZXJvIFVEUCBj aGVja3N1bSwgUkZDIDYxNDUsIHNlY3Rpb24gNC41LCBwb2ludCAxDQoyKSByZWNhbGN1bGF0ZSBV RFAgY2hlY2tzdW0gaW4gSVB2NiBwYWNrZXQgZnJvbSBzY3JhdGNoIFJGQyA2MTQ1LCBzZWN0aW9u IDQuNSwgcG9pbnQgMiAgIChjYWxjdWxhdGluZyBVRFAgY2hlY2tzdW0gZnJvbSBzY3JhdGNoIGlz IGRpZmZlcmVudCB0aGF0IHVwZGF0aW5nIGlzIGFjY29yZGluZyB0byBSRkMgMTYyNCAtIHRoaXMg d291bGQgYmUgdGhlIGNhc2UgaWYgSVB2NCBwYWNrZXQgd291bGQgaGF2ZSBub24temVybyBjaGVj a3N1bSkNCjMpIHBlcmZvcm0gdHJhbnNsYXRpb24gb3IgZW5jYXBzdWxhdGlvbiBpbnRvIElQdjYg YW5kIGxlYXZlIHplcm8tY2hlY2tzdW0gKFVEUCkgIGluIElQdjYgLiBUaGlzIGlzIGluIHZpb2xh dGlvbiBvZiBSRkMgMjQ2MCwgYnV0IFJGQ3MgNjkzNSBhbmQgNjkzNiBhbGxldmlhdGUgdGhlIHJl c3RyaWN0aW9uIGZyb20gUkZDIDI0NjAgLg0KDQpBbnlvbmUgY2FuIHNoYXJlIGV4cGVyaWVuY2Ug aW4gdGVybXMgb2YgYnJva2VuIGFwcHMgaW4gY2FzZXMgMSBhbmQgMz8NCg0KKm9wdGlvbnMgYWJv dmUgYXBwbHkgdG8gdHVubmVscyBidXQgSSBzZWUgbm8gcmVhc29uIHdoeSB3b3VsZCB0aGV5IG5v dCBhcHBseSB0byB0cmFuc2xhdGlvbnMgYXMgd2VsbCAodjQtPnY2KQ0KVGhhbmtzLg0KICANCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEVYVCBUb20gSGVyYmVydCBbbWFpbHRv OnRvbUBoZXJiZXJ0bGFuZC5jb21dIA0KU2VudDogVGh1cnNkYXksIE1hcmNoIDEwLCAyMDE2IDM6 NDUgUE0NClRvOiBGcmVkIEJha2VyIChmcmVkKQ0KQ2M6IFBvc2NpYywgS3Jpc3RpYW4gKE5va2lh IC0gVVMpOyBzb2Z0d2lyZXNAaWV0Zi5vcmc7IGludC1hcmVhQGlldGYub3JnOyB0c3YtYXJlYUBp ZXRmLm9yZzsgbWFwcmdAaXJ0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSW50LWFyZWFdIFVEUCB6ZXJv LWNoZWNrc3VtIGluIElQdjQNCg0KT24gVGh1LCBNYXIgMTAsIDIwMTYgYXQgMTo0NiBQTSwgRnJl ZCBCYWtlciAoZnJlZCkgPGZyZWRAY2lzY28uY29tPiB3cm90ZToNCj4NCj4+IE9uIE1hciAxMCwg MjAxNiwgYXQgOToyOSBBTSwgUG9zY2ljLCBLcmlzdGlhbiAoTm9raWEgLSBVUykgPGtyaXN0aWFu LnBvc2NpY0Bub2tpYS5jb20+IHdyb3RlOg0KPj4NCj4+IEhpLA0KPj4NCj4+IERvZXMgYW55b25l IGhhdmUgYW55IGluZm8gb24gdGhlIHBlcmNlbnRhZ2Ugb2YgVURQIHBhY2tldHMgd2l0aCANCj4+ IHplcm8tY2hlY2tzdW0gZm9yIElQdjQgcGFja2V0cyBpbiB0b2RheeKAmXMgbmV0d29ya3MgKGVu dGVycHJpc2UsIGludGVybmV0LCBhbnkgbmV0d29yaykuDQo+PiBTZWVtcyBsaWtlIHRoZXJlIGlz IG5vdCBhIHdob2xlIGxvdCBvZiBpbmZvIGFib3V0IHRoaXMgb24gdGhlIFdFQi4gQW55b25lIGhh cyBhbnkgZmlyc3RoYW5kL3JlYWx3b3JsZCBleHBlcmllbmNlIHdpdGggdGhpcz8gVGhhbmtzLg0K Pj4NCj4+IEtyaXMNCj4NCj4gQSBnb29kIHBsYWNlIHRvIHN0YXJ0IG1pZ2h0IGJlIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTM2DQo+IDY5MzYgQXBwbGljYWJpbGl0eSBTdGF0ZW1l bnQgZm9yIHRoZSBVc2Ugb2YgSVB2NiBVRFAgRGF0YWdyYW1zIHdpdGggWmVybw0KPiAgICAgIENo ZWNrc3Vtcy4gRy4gRmFpcmh1cnN0LCBNLiBXZXN0ZXJsdW5kLiBBcHJpbCAyMDEzLiAoRm9ybWF0 Og0KPiAgICAgIFRYVD05OTU1NyBieXRlcykgKFN0YXR1czogUFJPUE9TRUQgU1RBTkRBUkQpIChE T0k6IA0KPiAxMC4xNzQ4Ny9SRkM2OTM2KQ0KPg0KPiBUaGUgYmlnIGNvbnNpZGVyYXRpb24gdGhl cmUgaXMgYSBtaWRkbGV3YXJlIGRldmljZSAodXN1YWxseSBhIHJvdXRlciwgYnV0IHBvdGVudGlh bGx5IHNvbWV0aGluZyBlbHNlKSB0aGF0IGlzIHJlY2VpdmluZyBwYWNrZXRzIGF0IGxpbmUgcmF0 ZSBvbmUgYSBzZXQgb2YgaW50ZXJmYWNlcyBhbmQgZnVubmVsaW5nIHRoZW0gdG8gYW5vdGhlciBp bnRlcmZhY2Ugb24gd2hpY2ggaXQgaXMgb2JsaWdhdGVkIHRvIHNlbmQgdGhlbSB0dW5uZWxlZCBp biBVRFAgcGFja2V0cywgb3IgYSBjb3JvbGxhcnkgZGV2aWNlIGF0IHRoZSBvdGhlciBlbmQgb2Yg dGhlIHR1bm5lbC4gSXQgd291bGQgYmUgdGhlb3JldGljYWxseSBwb3NzaWJsZSB0byBhZGQgaGFy ZHdhcmUgdGhhdCBjb3VsZCBwYXJzZSB0byB0aGUgY29ycmVjdCBwb2ludCBhbmQgY2FsY3VsYXRl IHRoZSBjaGVja3N1bSB3aGlsZSB0aGUgZGF0YSBiZWluZyByZWNlaXZlZCB3YXMgc3RvcmVkIGlu dG8gbWVtb3J5LiBIb3dldmVyLCBwcmFjdGljYWxseSwgdGhhdCBpcyBmYXIgbW9yZSBsaWtlbHkg dG8gYmUgZG9uZSBhcyBhIHNlY29uZCBzdGVwLCB0byBwYWNrZXRzIGl0IGlzIGFwcGxpY2FibGUg dG8uIFRoZSBjb25maWd1cmF0aW9uIG9mIGEgdHVubmVsIHRoYXQgY3JlYXRlcyBvciB2ZXJpZmll cyBhIFVEUCBjaGVja3N1bSBvbiBhIHR1bm5lbGVkIGRhdGFncmFtLCBpbiBzdWNoIGEgY2FzZSwg aXMgZXNzZW50aWFsbHkgYSBET1MgdmVjdG9yLg0KPg0KTm90ZSB0aGF0IHRoaXMgcHJvYmxlbSBp cyBtb3N0bHkgc3BlY2lmaWMgdG8gc3dpdGNoZXMgdGhhdCBsYWNrIEhXIHRvIGVmZmljaWVudGx5 IHBlcmZvcm0gY2hlY2tzdW0uIE9uIHRoZSBob3N0IHNpZGUsIHdlIGhhdmUgbG9uZyBzdGFuZGlu ZyBzdXBwb3J0IGluIE5JQyBIVyB0byB0byBwZXJmb3JtIGNoZWNrc3VtIG9mZmxvYWQgKHdoZXRo ZXIgVURQIHNlbmRzIHplcm8gY2hlY2tzdW0gaW4gSVB2NiwgY2hlY2tzdW1zIGFyZSBhbHdheXMg dXNlZCBpbiBUQ1Agc28gd2UgbmVlZCBhIGhvc3Qgc29sdXRpb24gcmVnYXJkbGVzcyEpLiBEdWUg dG8gdGhlIGNhcGFiaWxpdGllcyBvZiBjdXJyZW50bHkgZGVwbG95ZWQgTklDcywgd2UgZ2V0IG11 Y2ggYmV0dGVyIHBlcmZvcm1hbmNlIHdpdGggdGhlIFVEUCBjaGVja3N1bSBlbmFibGVkIGZvciB0 dW5uZWxzIHdoZW4gc291cmNpbmcgb3IgdGVybWluYXRpbmcgdHVubmVscyBvbiB0aGUgc2FtZSBo b3N0IHRoYXQgc2VuZHMgb3IgcmVjZWl2ZSBhbiBlbmNhcHN1bGF0ZWQgVENQIHBhY2tldC0tIGlu IGZhY3QgdGhlIGRlZmF1bHQgd2FzIHJlY2VudGx5IGNoYW5nZWQgaW4gTGludXggdG8gZW5hYmxl IGNoZWNrc3VtIGZvciBVRFAgdHVubmVscyAoaXQgY2FuIHN0aWxsIGJlIGRpc2FibGVkIGJ5IHBl ciB0dW5uZWwgY29uZmlndXJhdGlvbikuDQoNClRvbQ0KDQo+IEFueSBkaXNjdXNzaW9uIG9mICJw ZXJjZW50YWdlcyBvZiB0cmFmZmljIGZvciB3aGljaCBYIGlzIHRydWUgaW4gdGhlIEludGVybmV0 IiBhcmUgbmVjZXNzYXJpbHkgdmFndWUgYW5kIGhhbmQtd2F2eS4gVGhlIEludGVybmV0IGlzIHRo ZSBwcm92ZXJiaWFsIGVsZXBoYW50LCBhbmQgdGhvc2UgdGhhdCB3b3VsZCBzdGF0aXN0aWNhbGx5 IGRlc2NyaWJlIGl0IGFyZSB0aGUgcHJvdmVyYmlhbCBwaGlsb3NvcGhlcnMuIEhvdyBvbmUgZGVz Y3JpYmVzIGl0IGhhcyBhIGxvdCB0byBkbyB3aXRoIHdoYXQgcGFydCBvZiBpdCBvbmUgdG91Y2hl cy4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gSW50LWFyZWEgbWFpbGluZyBsaXN0DQo+IEludC1hcmVhQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW50LWFyZWENCj4NCg== From nobody Fri Mar 11 18:26:53 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BCA12D54E; Thu, 10 Mar 2016 23:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgczN329mWGu; Thu, 10 Mar 2016 23:36:45 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 08C7812D544; Thu, 10 Mar 2016 23:36:45 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 9A5141B001AD; Fri, 11 Mar 2016 07:47:46 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Fri, 11 Mar 2016 07:36:43 -0000 Message-ID: In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F0BEA2DF61@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <7921F977B17D5B49B8DCC955A339D2F0BEA21EC5@US70UWXCHMBA05.zam.alcatel-lucent.com> <64044A42-0775-4ABC-B7BD-3541316B0E81@cisco.com> <7921F977B17D5B49B8DCC955A339D2F0BEA2DF61@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Fri, 11 Mar 2016 07:36:43 -0000 From: gorry@erg.abdn.ac.uk To: "Poscic, Kristian (Nokia - US)" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: X-Mailman-Approved-At: Fri, 11 Mar 2016 18:26:48 -0800 Cc: "maprg@irtf.org" , "int-area@ietf.org" , "tsv-area@ietf.org" , "softwires@ietf.org" Subject: Re: [Int-area] UDP zero-checksum in IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 07:36:55 -0000 Your subject field says v4, and I don't see why you call these apps "broken". Although IPv4 permits an option to disable their use, because there are good reasons why you may want to do that for a particular application (see references in Fred's reply), the default in RFC768 is for applications SHOULD enable UDP checksums. Echoed in RF5405 as a SHOULD. Checksums not only validate the payload and the the UDP header, they offer protection from reassembly errors when packets are fragmented. > Thanks, this is all helpful. > But let me rephrase the question in hope to get a bit more quantifiable > answer: > - can some share user experience (broken apps) when traffic with zero UDP > checksum is dropped? > > The available options when translating*/tunneling IPv4 UDP packet with > zero-checksum into IPv6: > 1) drop IPv4 packets with zero UDP checksum, RFC 6145, section 4.5, point > 1 RFC1122 also contains an option that intentionally discards UDP datagrams received with a zero (Section 4.1.3.4). There are reasons why an application (or host stack) may wish to do this. > 2) recalculate UDP checksum in IPv6 packet from scratch RFC 6145, section > 4.5, point 2 (calculating UDP checksum from scratch is different that > updating is according to RFC 1624 - this would be the case if IPv4 packet > would have non-zero checksum) > 3) perform translation or encapsulation into IPv6 and leave zero-checksum > (UDP) in IPv6 . This is in violation of RFC 2460, but RFCs 6935 and 6936 > alleviate the restriction from RFC 2460 . > True, but this is permitted only for some deployment scenarios, as in the encapsulation of MPLS in UPD within an operator network. > Anyone can share experience in terms of broken apps in cases 1 and 3? > > *options above apply to tunnels but I see no reason why would they not > apply to translations as well (v4->v6) > I think so, when translating IPv6 UDP zero checksum to IPv4, but certainly not intended to be permitted when translating to IPv6, unless this was operating within a controlled environment (such as the case in RFC7510). Gorry > Thanks. > > > -----Original Message----- > From: EXT Tom Herbert [mailto:tom@herbertland.com] > Sent: Thursday, March 10, 2016 3:45 PM > To: Fred Baker (fred) > Cc: Poscic, Kristian (Nokia - US); softwires@ietf.org; int-area@ietf.org; > tsv-area@ietf.org; maprg@irtf.org > Subject: Re: [Int-area] UDP zero-checksum in IPv4 > > On Thu, Mar 10, 2016 at 1:46 PM, Fred Baker (fred) > wrote: >> >>> On Mar 10, 2016, at 9:29 AM, Poscic, Kristian (Nokia - US) >>> wrote: >>> >>> Hi, >>> >>> Does anyone have any info on the percentage of UDP packets with >>> zero-checksum for IPv4 packets in today’s networks (enterprise, >>> internet, any network). >>> Seems like there is not a whole lot of info about this on the WEB. >>> Anyone has any firsthand/realworld experience with this? Thanks. >>> >>> Kris >> >> A good place to start might be https://tools.ietf.org/html/rfc6936 >> 6936 Applicability Statement for the Use of IPv6 UDP Datagrams with >> Zero >> Checksums. G. Fairhurst, M. Westerlund. April 2013. (Format: >> TXT=99557 bytes) (Status: PROPOSED STANDARD) (DOI: >> 10.17487/RFC6936) >> >> The big consideration there is a middleware device (usually a router, >> but potentially something else) that is receiving packets at line rate >> one a set of interfaces and funneling them to another interface on which >> it is obligated to send them tunneled in UDP packets, or a corollary >> device at the other end of the tunnel. It would be theoretically >> possible to add hardware that could parse to the correct point and >> calculate the checksum while the data being received was stored into >> memory. However, practically, that is far more likely to be done as a >> second step, to packets it is applicable to. The configuration of a >> tunnel that creates or verifies a UDP checksum on a tunneled datagram, >> in such a case, is essentially a DOS vector. >> > Note that this problem is mostly specific to switches that lack HW to > efficiently perform checksum. On the host side, we have long standing > support in NIC HW to to perform checksum offload (whether UDP sends zero > checksum in IPv6, checksums are always used in TCP so we need a host > solution regardless!). Due to the capabilities of currently deployed NICs, > we get much better performance with the UDP checksum enabled for tunnels > when sourcing or terminating tunnels on the same host that sends or > receive an encapsulated TCP packet-- in fact the default was recently > changed in Linux to enable checksum for UDP tunnels (it can still be > disabled by per tunnel configuration). > > Tom > >> Any discussion of "percentages of traffic for which X is true in the >> Internet" are necessarily vague and hand-wavy. The Internet is the >> proverbial elephant, and those that would statistically describe it are >> the proverbial philosophers. How one describes it has a lot to do with >> what part of it one touches. >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >> > From nobody Fri Mar 11 18:26:56 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C3712D6AE; Fri, 11 Mar 2016 05:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KtVOwwKsZpi; Fri, 11 Mar 2016 05:32:10 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB62612D6A1; Fri, 11 Mar 2016 05:32:10 -0800 (PST) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id DC7C1E899F8E5; Fri, 11 Mar 2016 13:32:07 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u2BDW8AF029243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Mar 2016 13:32:08 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u2BDW6qe006330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Mar 2016 13:32:07 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 11 Mar 2016 08:31:48 -0500 From: "Poscic, Kristian (Nokia - US)" To: "EXT gorry@erg.abdn.ac.uk" Thread-Topic: [Int-area] UDP zero-checksum in IPv4 Thread-Index: AdF68bLe5SvLau+lRPK5dqDoIJSUhwAToJGAAAQmmgAAAgwbsAAOarCAAABqszA= Date: Fri, 11 Mar 2016 13:31:47 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F0BEA30554@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <7921F977B17D5B49B8DCC955A339D2F0BEA21EC5@US70UWXCHMBA05.zam.alcatel-lucent.com> <64044A42-0775-4ABC-B7BD-3541316B0E81@cisco.com> <7921F977B17D5B49B8DCC955A339D2F0BEA2DF61@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 11 Mar 2016 18:26:48 -0800 Cc: "maprg@irtf.org" , "int-area@ietf.org" , "tsv-area@ietf.org" , "softwires@ietf.org" Subject: Re: [Int-area] UDP zero-checksum in IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 13:32:13 -0000 VGhlIGFwcHMgYXJlIG5vdCBicm9rZW4gaW4gcHVyZSBJUHY0IGVudmlyb25tZW50LiBCdXQgd2hl biBJUHY0IGlzIHR1bm5lbGVkLyh0cmFuc2xhdGVkKSBpbiBJUHY2LCB0aGVuIHRoZXkgbWF5IGJl Y29tZSBicm9rZW4gKGJldHdlZW4gSVB2NCBlbmQtbm9kZXMsIHdpdGggc29tZSB2NiB0cmFuc3Bv cnQgaW4gYmV0d2VlbikgYmVjYXVzZSBvZiBpbmNvbnNpc3RlbmNpZXMgaW4gVURQIGNoZWNrc3Vt IGNhbGN1bGF0aW9uIHJlcXVpcmVtZW50IGJldHdlZW4gdjQgYW5kIHY2ICh2NCBhbGxvd3MgemVy by1jaGVja3N1bSBmb3IgVURQIGJ1dCB2NiBvcmlnaW5hbGx5IGRvZXMgbm90IC0gc28gd2hlbiB2 NCBpcyB0dW5uZWxlZCB3aXRoaW4gdjYsIHRoZSBvdXRjb21lIHdpbGwgZGVwZW5kIG9uIG9uZSBv ZiB0aGUgMyBvcHRpb25zIGJlbG93KS4gU28gSSdtIGp1c3QgdHJ5aW5nIHRvIHNlbnNlIGhvdyBt dWNoIG9mIGEgcmVhbCBwcm9ibGVtIGlzIHRoaXMgdG9kYXkgaW4gcmVhbCBuZXR3b3JrcyBvZiB0 b2RheS4NCiAgDQpTaW1wbGUgZXhhbXBsZSB0byBjbGFyaWZ5Og0KLSB0aGVyZSBhcmUgdHdvIElQ djQgZW5kLW5vZGVzLCBOMSBhbmQgTjIgDQotIHNvbWV3aGVyZSBpbiBiZXR3ZWVuIHRoZXJlIGlz IGEgcGFydCBvZiB0aGUgbmV0d29yayB3aGVyZSBJUHY0IGdldHMgdHVubmVsZWQgd2l0aGluIHY2 DQotIE4xIHNlbmRzIFVEUCB0cmFmZmljIHdpdGggemVybyBVRFAgY2hlY2tzdW0gdG8gTjINCi0g V2hlbiB0aGlzIHRyYWZmaWMgZ2V0cyB0byB0aGUgaGVhZCBvZiB2NiB0dW5uZWwsIHRoZSBub2Rl IHdoaWNoIGlzIHN1cHBvc2VkIHRvIGVuY2Fwc3VsYXRlIGl0IGluIHY2IHNpbXBseSBkcm9wcyBp dCAoc2luY2UgUkZDIDYxNDUgYWxsb3dzIHRoaXMpLg0KDQpIYXZlIGFueW9uZSBydW4gaW50byBp c3N1ZXMgbGlrZSB0aGlzIChjdXN0b21lciBjYWxsaW5nIGFuZCBjb21wbGFpbmluZyB0aGF0IHRo ZWlyIGFwcHMgbm90IHdvcmtpbmcgYmVjYXVzZSBvZiB0aGlzKT8NCg0KT1IgYWx0ZXJuYXRpdmVs eToNCi0gV2hlbiB0aGlzIHRyYWZmaWMgZ2V0cyB0byB0aGUgaGVhZCBvZiB2NiB0dW5uZWwsIHRo ZSBub2RlIHdoaWNoIGlzIHN1cHBvc2VkIHRvIGVuY2Fwc3VsYXRlIGl0IGluIHY2IHNpbXBseSB0 dW5uZWxzIGl0IHdpdGggemVyby1jaGVja3N1bSBpbiB2NiBoZWFkZXIgKHJhdGhlciB0aGFuIGNh bGN1bGF0aW5nIHY2IGNoZWNrc3VtKSAtIG15IG9wdGlvbiAzIGJlbG93Lg0KLSB3aGVuIHRoZSBu b2RlIGF0IHRoZSB0YWlsIG9mIHRoZSB2NiB0dW5uZWwgcmVjZWl2ZXMgc3VjaCB0cmFmZmljLCBp dCBtYXkgZHJvcCBpdCBiZWNhdXNlIFJGQyAyNDYwIHNheXMgdGhhdCBpcyBtdXN0Lg0KDQogU2Ft ZSBxdWVzdGlvbiAtIGhhdmUgYW55b25lIHJ1biBpbnRvIGlzc3VlcyBsaWtlIHRoaXMgKGN1c3Rv bWVyIGNhbGxpbmcgYW5kIGNvbXBsYWluaW5nIHRoYXQgdGhlaXIgYXBwcyBub3Qgd29ya2luZyBi ZWNhdXNlIG9mIHRoaXMpPw0KDQpJIHVuZGVyc3RhbmQgdGhhdCBib3hlcyBzaG91bGQgZG8gdGhp cyBvciB0aGF0IGFuZCB0aGF0IFJGQ3MgaGF2ZSBiZWVuIGFtZW5kZWQuICBCdXQgdGhpcyBpcyBt b3JlIG9mIGEgdXNlciBleHBlcmllbmNlIHF1ZXN0aW9uLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBFWFQgZ29ycnlAZXJnLmFiZG4uYWMudWsgW21haWx0bzpnb3JyeUBl cmcuYWJkbi5hYy51a10gDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMTAsIDIwMTYgMTE6MzcgUE0N ClRvOiBQb3NjaWMsIEtyaXN0aWFuIChOb2tpYSAtIFVTKQ0KQ2M6IEVYVCBUb20gSGVyYmVydDsg RnJlZCBCYWtlciAoZnJlZCk7IHNvZnR3aXJlc0BpZXRmLm9yZzsgdHN2LWFyZWFAaWV0Zi5vcmc7 IGludC1hcmVhQGlldGYub3JnOyBtYXByZ0BpcnRmLm9yZw0KU3ViamVjdDogUkU6IFtJbnQtYXJl YV0gVURQIHplcm8tY2hlY2tzdW0gaW4gSVB2NA0KDQpZb3VyIHN1YmplY3QgZmllbGQgc2F5cyB2 NCwgYW5kIEkgZG9uJ3Qgc2VlIHdoeSB5b3UgY2FsbCB0aGVzZSBhcHBzICJicm9rZW4iLiBBbHRo b3VnaCBJUHY0IHBlcm1pdHMgYW4gb3B0aW9uIHRvIGRpc2FibGUgdGhlaXIgdXNlLCBiZWNhdXNl IHRoZXJlIGFyZSBnb29kIHJlYXNvbnMgd2h5IHlvdSBtYXkgd2FudCB0byBkbyB0aGF0IGZvciBh IHBhcnRpY3VsYXIgYXBwbGljYXRpb24gKHNlZSByZWZlcmVuY2VzIGluIEZyZWQncyByZXBseSks IHRoZSBkZWZhdWx0IGluIFJGQzc2OCBpcyBmb3IgYXBwbGljYXRpb25zIFNIT1VMRCBlbmFibGUg VURQIGNoZWNrc3Vtcy4gRWNob2VkIGluIFJGNTQwNSBhcyBhIFNIT1VMRC4NCkNoZWNrc3VtcyBu b3Qgb25seSB2YWxpZGF0ZSB0aGUgcGF5bG9hZCBhbmQgdGhlIHRoZSBVRFAgaGVhZGVyLCB0aGV5 IG9mZmVyIHByb3RlY3Rpb24gZnJvbSByZWFzc2VtYmx5IGVycm9ycyB3aGVuIHBhY2tldHMgYXJl IGZyYWdtZW50ZWQuDQoNCj4gVGhhbmtzLCB0aGlzIGlzIGFsbCBoZWxwZnVsLg0KPiBCdXQgbGV0 IG1lIHJlcGhyYXNlIHRoZSBxdWVzdGlvbiBpbiBob3BlIHRvIGdldCBhIGJpdCBtb3JlIA0KPiBx dWFudGlmaWFibGUNCj4gYW5zd2VyOg0KPiAtIGNhbiBzb21lIHNoYXJlIHVzZXIgZXhwZXJpZW5j ZSAoYnJva2VuIGFwcHMpIHdoZW4gdHJhZmZpYyB3aXRoIHplcm8gDQo+IFVEUCBjaGVja3N1bSBp cyBkcm9wcGVkPw0KPg0KPiBUaGUgYXZhaWxhYmxlIG9wdGlvbnMgd2hlbiB0cmFuc2xhdGluZyov dHVubmVsaW5nIElQdjQgVURQIHBhY2tldCB3aXRoIA0KPiB6ZXJvLWNoZWNrc3VtIGludG8gSVB2 NjoNCj4gMSkgZHJvcCBJUHY0IHBhY2tldHMgd2l0aCB6ZXJvIFVEUCBjaGVja3N1bSwgUkZDIDYx NDUsIHNlY3Rpb24gNC41LCANCj4gcG9pbnQNCj4gMQ0KUkZDMTEyMiBhbHNvIGNvbnRhaW5zIGFu IG9wdGlvbiB0aGF0IGludGVudGlvbmFsbHkgZGlzY2FyZHMgVURQIGRhdGFncmFtcyByZWNlaXZl ZCB3aXRoIGEgemVybyAoU2VjdGlvbiA0LjEuMy40KS4gVGhlcmUgYXJlIHJlYXNvbnMgd2h5IGFu IGFwcGxpY2F0aW9uIChvciBob3N0IHN0YWNrKSBtYXkgd2lzaCB0byBkbyB0aGlzLg0KDQo+IDIp IHJlY2FsY3VsYXRlIFVEUCBjaGVja3N1bSBpbiBJUHY2IHBhY2tldCBmcm9tIHNjcmF0Y2ggUkZD IDYxNDUsIHNlY3Rpb24NCj4gNC41LCBwb2ludCAyICAgKGNhbGN1bGF0aW5nIFVEUCBjaGVja3N1 bSBmcm9tIHNjcmF0Y2ggaXMgZGlmZmVyZW50IHRoYXQNCj4gdXBkYXRpbmcgaXMgYWNjb3JkaW5n IHRvIFJGQyAxNjI0IC0gdGhpcyB3b3VsZCBiZSB0aGUgY2FzZSBpZiBJUHY0IA0KPiBwYWNrZXQg d291bGQgaGF2ZSBub24temVybyBjaGVja3N1bSkNCg0KPiAzKSBwZXJmb3JtIHRyYW5zbGF0aW9u IG9yIGVuY2Fwc3VsYXRpb24gaW50byBJUHY2IGFuZCBsZWF2ZSANCj4gemVyby1jaGVja3N1bQ0K PiAoVURQKSAgaW4gSVB2NiAuIFRoaXMgaXMgaW4gdmlvbGF0aW9uIG9mIFJGQyAyNDYwLCBidXQg UkZDcyA2OTM1IGFuZCANCj4gNjkzNiBhbGxldmlhdGUgdGhlIHJlc3RyaWN0aW9uIGZyb20gUkZD IDI0NjAgLg0KPg0KVHJ1ZSwgYnV0IHRoaXMgaXMgcGVybWl0dGVkIG9ubHkgZm9yIHNvbWUgZGVw bG95bWVudCBzY2VuYXJpb3MsIGFzIGluIHRoZSBlbmNhcHN1bGF0aW9uIG9mIE1QTFMgaW4gVVBE IHdpdGhpbiBhbiBvcGVyYXRvciBuZXR3b3JrLg0KDQo+IEFueW9uZSBjYW4gc2hhcmUgZXhwZXJp ZW5jZSBpbiB0ZXJtcyBvZiBicm9rZW4gYXBwcyBpbiBjYXNlcyAxIGFuZCAzPw0KPg0KPiAqb3B0 aW9ucyBhYm92ZSBhcHBseSB0byB0dW5uZWxzIGJ1dCBJIHNlZSBubyByZWFzb24gd2h5IHdvdWxk IHRoZXkgbm90IA0KPiBhcHBseSB0byB0cmFuc2xhdGlvbnMgYXMgd2VsbCAodjQtPnY2KQ0KPg0K SSB0aGluayBzbywgd2hlbiB0cmFuc2xhdGluZyBJUHY2IFVEUCB6ZXJvIGNoZWNrc3VtIHRvIElQ djQsIGJ1dCBjZXJ0YWlubHkgbm90IGludGVuZGVkIHRvIGJlIHBlcm1pdHRlZCB3aGVuIHRyYW5z bGF0aW5nIHRvIElQdjYsIHVubGVzcyB0aGlzIHdhcyBvcGVyYXRpbmcgd2l0aGluIGEgY29udHJv bGxlZCBlbnZpcm9ubWVudCAoc3VjaCBhcyB0aGUgY2FzZSBpbiBSRkM3NTEwKS4NCg0KR29ycnkN Cg0KPiBUaGFua3MuDQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IEVYVCBUb20gSGVyYmVydCBbbWFpbHRvOnRvbUBoZXJiZXJ0bGFuZC5jb21dDQo+IFNlbnQ6IFRo dXJzZGF5LCBNYXJjaCAxMCwgMjAxNiAzOjQ1IFBNDQo+IFRvOiBGcmVkIEJha2VyIChmcmVkKQ0K PiBDYzogUG9zY2ljLCBLcmlzdGlhbiAoTm9raWEgLSBVUyk7IHNvZnR3aXJlc0BpZXRmLm9yZzsg DQo+IGludC1hcmVhQGlldGYub3JnOyB0c3YtYXJlYUBpZXRmLm9yZzsgbWFwcmdAaXJ0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFtJbnQtYXJlYV0gVURQIHplcm8tY2hlY2tzdW0gaW4gSVB2NA0KPg0K PiBPbiBUaHUsIE1hciAxMCwgMjAxNiBhdCAxOjQ2IFBNLCBGcmVkIEJha2VyIChmcmVkKSA8ZnJl ZEBjaXNjby5jb20+DQo+IHdyb3RlOg0KPj4NCj4+PiBPbiBNYXIgMTAsIDIwMTYsIGF0IDk6Mjkg QU0sIFBvc2NpYywgS3Jpc3RpYW4gKE5va2lhIC0gVVMpIA0KPj4+IDxrcmlzdGlhbi5wb3NjaWNA bm9raWEuY29tPiB3cm90ZToNCj4+Pg0KPj4+IEhpLA0KPj4+DQo+Pj4gRG9lcyBhbnlvbmUgaGF2 ZSBhbnkgaW5mbyBvbiB0aGUgcGVyY2VudGFnZSBvZiBVRFAgcGFja2V0cyB3aXRoIA0KPj4+IHpl cm8tY2hlY2tzdW0gZm9yIElQdjQgcGFja2V0cyBpbiB0b2RhecOi4oKs4oSicyBuZXR3b3JrcyAo ZW50ZXJwcmlzZSwgDQo+Pj4gaW50ZXJuZXQsIGFueSBuZXR3b3JrKS4NCj4+PiBTZWVtcyBsaWtl IHRoZXJlIGlzIG5vdCBhIHdob2xlIGxvdCBvZiBpbmZvIGFib3V0IHRoaXMgb24gdGhlIFdFQi4N Cj4+PiBBbnlvbmUgaGFzIGFueSBmaXJzdGhhbmQvcmVhbHdvcmxkIGV4cGVyaWVuY2Ugd2l0aCB0 aGlzPyBUaGFua3MuDQo+Pj4NCj4+PiBLcmlzDQo+Pg0KPj4gQSBnb29kIHBsYWNlIHRvIHN0YXJ0 IG1pZ2h0IGJlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTM2DQo+PiA2OTM2IEFw cGxpY2FiaWxpdHkgU3RhdGVtZW50IGZvciB0aGUgVXNlIG9mIElQdjYgVURQIERhdGFncmFtcyB3 aXRoIA0KPj4gWmVybw0KPj4gICAgICBDaGVja3N1bXMuIEcuIEZhaXJodXJzdCwgTS4gV2VzdGVy bHVuZC4gQXByaWwgMjAxMy4gKEZvcm1hdDoNCj4+ICAgICAgVFhUPTk5NTU3IGJ5dGVzKSAoU3Rh dHVzOiBQUk9QT1NFRCBTVEFOREFSRCkgKERPSToNCj4+IDEwLjE3NDg3L1JGQzY5MzYpDQo+Pg0K Pj4gVGhlIGJpZyBjb25zaWRlcmF0aW9uIHRoZXJlIGlzIGEgbWlkZGxld2FyZSBkZXZpY2UgKHVz dWFsbHkgYSByb3V0ZXIsIA0KPj4gYnV0IHBvdGVudGlhbGx5IHNvbWV0aGluZyBlbHNlKSB0aGF0 IGlzIHJlY2VpdmluZyBwYWNrZXRzIGF0IGxpbmUgDQo+PiByYXRlIG9uZSBhIHNldCBvZiBpbnRl cmZhY2VzIGFuZCBmdW5uZWxpbmcgdGhlbSB0byBhbm90aGVyIGludGVyZmFjZSANCj4+IG9uIHdo aWNoIGl0IGlzIG9ibGlnYXRlZCB0byBzZW5kIHRoZW0gdHVubmVsZWQgaW4gVURQIHBhY2tldHMs IG9yIGEgDQo+PiBjb3JvbGxhcnkgZGV2aWNlIGF0IHRoZSBvdGhlciBlbmQgb2YgdGhlIHR1bm5l bC4gSXQgd291bGQgYmUgDQo+PiB0aGVvcmV0aWNhbGx5IHBvc3NpYmxlIHRvIGFkZCBoYXJkd2Fy ZSB0aGF0IGNvdWxkIHBhcnNlIHRvIHRoZSANCj4+IGNvcnJlY3QgcG9pbnQgYW5kIGNhbGN1bGF0 ZSB0aGUgY2hlY2tzdW0gd2hpbGUgdGhlIGRhdGEgYmVpbmcgDQo+PiByZWNlaXZlZCB3YXMgc3Rv cmVkIGludG8gbWVtb3J5LiBIb3dldmVyLCBwcmFjdGljYWxseSwgdGhhdCBpcyBmYXIgDQo+PiBt b3JlIGxpa2VseSB0byBiZSBkb25lIGFzIGEgc2Vjb25kIHN0ZXAsIHRvIHBhY2tldHMgaXQgaXMg YXBwbGljYWJsZSANCj4+IHRvLiBUaGUgY29uZmlndXJhdGlvbiBvZiBhIHR1bm5lbCB0aGF0IGNy ZWF0ZXMgb3IgdmVyaWZpZXMgYSBVRFAgDQo+PiBjaGVja3N1bSBvbiBhIHR1bm5lbGVkIGRhdGFn cmFtLCBpbiBzdWNoIGEgY2FzZSwgaXMgZXNzZW50aWFsbHkgYSBET1MgdmVjdG9yLg0KPj4NCj4g Tm90ZSB0aGF0IHRoaXMgcHJvYmxlbSBpcyBtb3N0bHkgc3BlY2lmaWMgdG8gc3dpdGNoZXMgdGhh dCBsYWNrIEhXIHRvIA0KPiBlZmZpY2llbnRseSBwZXJmb3JtIGNoZWNrc3VtLiBPbiB0aGUgaG9z dCBzaWRlLCB3ZSBoYXZlIGxvbmcgc3RhbmRpbmcgDQo+IHN1cHBvcnQgaW4gTklDIEhXIHRvIHRv IHBlcmZvcm0gY2hlY2tzdW0gb2ZmbG9hZCAod2hldGhlciBVRFAgc2VuZHMgDQo+IHplcm8gY2hl Y2tzdW0gaW4gSVB2NiwgY2hlY2tzdW1zIGFyZSBhbHdheXMgdXNlZCBpbiBUQ1Agc28gd2UgbmVl ZCBhIA0KPiBob3N0IHNvbHV0aW9uIHJlZ2FyZGxlc3MhKS4gRHVlIHRvIHRoZSBjYXBhYmlsaXRp ZXMgb2YgY3VycmVudGx5IA0KPiBkZXBsb3llZCBOSUNzLCB3ZSBnZXQgbXVjaCBiZXR0ZXIgcGVy Zm9ybWFuY2Ugd2l0aCB0aGUgVURQIGNoZWNrc3VtIA0KPiBlbmFibGVkIGZvciB0dW5uZWxzIHdo ZW4gc291cmNpbmcgb3IgdGVybWluYXRpbmcgdHVubmVscyBvbiB0aGUgc2FtZSANCj4gaG9zdCB0 aGF0IHNlbmRzIG9yIHJlY2VpdmUgYW4gZW5jYXBzdWxhdGVkIFRDUCBwYWNrZXQtLSBpbiBmYWN0 IHRoZSANCj4gZGVmYXVsdCB3YXMgcmVjZW50bHkgY2hhbmdlZCBpbiBMaW51eCB0byBlbmFibGUg Y2hlY2tzdW0gZm9yIFVEUCANCj4gdHVubmVscyAoaXQgY2FuIHN0aWxsIGJlIGRpc2FibGVkIGJ5 IHBlciB0dW5uZWwgY29uZmlndXJhdGlvbikuDQo+DQo+IFRvbQ0KPg0KPj4gQW55IGRpc2N1c3Np b24gb2YgInBlcmNlbnRhZ2VzIG9mIHRyYWZmaWMgZm9yIHdoaWNoIFggaXMgdHJ1ZSBpbiB0aGUg DQo+PiBJbnRlcm5ldCIgYXJlIG5lY2Vzc2FyaWx5IHZhZ3VlIGFuZCBoYW5kLXdhdnkuIFRoZSBJ bnRlcm5ldCBpcyB0aGUgDQo+PiBwcm92ZXJiaWFsIGVsZXBoYW50LCBhbmQgdGhvc2UgdGhhdCB3 b3VsZCBzdGF0aXN0aWNhbGx5IGRlc2NyaWJlIGl0IA0KPj4gYXJlIHRoZSBwcm92ZXJiaWFsIHBo aWxvc29waGVycy4gSG93IG9uZSBkZXNjcmliZXMgaXQgaGFzIGEgbG90IHRvIGRvIA0KPj4gd2l0 aCB3aGF0IHBhcnQgb2YgaXQgb25lIHRvdWNoZXMuDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEludC1hcmVhIG1haWxpbmcgbGlzdA0K Pj4gSW50LWFyZWFAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaW50LWFyZWENCj4+DQo+DQoNCg== From nobody Fri Mar 11 18:26:58 2016 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B18512DD86; Fri, 11 Mar 2016 15:05:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230525.15028.9439.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:25 -0800 Archived-At: X-Mailman-Approved-At: Fri, 11 Mar 2016 18:26:48 -0800 Cc: int-area@ietf.org Subject: [Int-area] intarea - Requested session has been scheduled for IETF 95 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:28 -0000 Dear Suresh Krishnan, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. intarea Session 1 (1:00:00) Tuesday, Afternoon Session II 1620-1720 Room Name: Buen Ayre C size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Internet Area Working Group Area Name: Internet Area Session Requester: Suresh Krishnan Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 100 Conflicts to Avoid: First Priority: 6man homenet v6ops irtfopen mif 6lo dhc Second Priority: nvo3 softwire rtgarea sunset4 lisp tsvwg dnsop netconf dmm nfvrg Third Priority: anima maprg tcpinc Special Requests: --------------------------------------------------------- From nobody Thu Mar 17 00:32:45 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDCC12D700 for ; Thu, 17 Mar 2016 00:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5iUY16mCZDH for ; Thu, 17 Mar 2016 00:32:42 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61BE612D6BC for ; Thu, 17 Mar 2016 00:32:42 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 3C0A618042B for ; Thu, 17 Mar 2016 08:32:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 1A2C620057 for ; Thu, 17 Mar 2016 08:32:41 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0279.002; Thu, 17 Mar 2016 08:32:37 +0100 From: To: "int-area@ietf.org" Thread-Topic: draft-boucadair-ip-version-5-8-9-historic Thread-Index: AdGAHyqZrfuGNG7GTdmvnr/Krvmn8w== Date: Thu, 17 Mar 2016 07:32:37 +0000 Message-ID: <455e5075-3291-4f3c-9511-c7a3731c6539@OPEXCLILMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Int-area] draft-boucadair-ip-version-5-8-9-historic X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 07:32:44 -0000 Dear all,=20 We do think it is time to move those specifications to Historic and dealloc= ate the IP version numbers.=20 Comments are welcome. Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: mercredi 16 mars 2016 16:34 > =C0=A0: i-d-announce@ietf.org > Objet=A0: I-D Action: draft-boucadair-ip-version-5-8-9-historic-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Reclassification of ST (IP version 5), PIP (IP > version 8) and TUBA (IP version 9) to Historic > Authors : Mohamed Boucadair > Christian Jacquenet > Filename : draft-boucadair-ip-version-5-8-9-historic-00.txt > Pages : 5 > Date : 2016-03-16 >=20 > Abstract: > This document reclassifies ST (IP version 5), PIP (IP version 8) and > TUBA (IP version 9) to Historic status. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-ip-version-5-8-9- > historic/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-boucadair-ip-version-5-8-9-historic-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Mar 17 05:42:47 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F90912D933 for ; Thu, 17 Mar 2016 05:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofq-YVcBovPa for ; Thu, 17 Mar 2016 05:42:40 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209AB12D560 for ; Thu, 17 Mar 2016 05:42:40 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id E671F88154 for ; Thu, 17 Mar 2016 05:42:39 -0700 (PDT) Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id A0DD2328081A for ; Thu, 17 Mar 2016 05:42:39 -0700 (PDT) To: int-area@ietf.org References: <455e5075-3291-4f3c-9511-c7a3731c6539@OPEXCLILMA2.corporate.adroot.infra.ftgroup> From: Brian Haberman Message-ID: <56EAA63E.80908@innovationslab.net> Date: Thu, 17 Mar 2016 08:42:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <455e5075-3291-4f3c-9511-c7a3731c6539@OPEXCLILMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2JtJDQPkI5v6a82cqprG4XtnsjvBnkOxf" Archived-At: Subject: Re: [Int-area] draft-boucadair-ip-version-5-8-9-historic X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 12:42:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2JtJDQPkI5v6a82cqprG4XtnsjvBnkOxf Content-Type: multipart/mixed; boundary="tK6dtIeBDe3jMBGcX2PrIVuvLNvAiv4B7" From: Brian Haberman To: int-area@ietf.org Message-ID: <56EAA63E.80908@innovationslab.net> Subject: Re: [Int-area] draft-boucadair-ip-version-5-8-9-historic References: <455e5075-3291-4f3c-9511-c7a3731c6539@OPEXCLILMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <455e5075-3291-4f3c-9511-c7a3731c6539@OPEXCLILMA2.corporate.adroot.infra.ftgroup> --tK6dtIeBDe3jMBGcX2PrIVuvLNvAiv4B7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is a fine thing to do, but it does not require an I-D to do it. An AD can create a status-change document that moves the three RFCs mentioned in the draft to Historic status. Any justification for the move can be included in the status-change document. Here is an example of one that was done recently: https://datatracker.ietf.org/doc/status-change-service-mappings-to-histor= ic/ Regards, Brian On 3/17/16 3:32 AM, mohamed.boucadair@orange.com wrote: > Dear all,=20 >=20 > We do think it is time to move those specifications to Historic and dea= llocate the IP version numbers.=20 >=20 > Comments are welcome. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de= >> internet-drafts@ietf.org >> Envoy=E9 : mercredi 16 mars 2016 16:34 >> =C0 : i-d-announce@ietf.org >> Objet : I-D Action: draft-boucadair-ip-version-5-8-9-historic-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Reclassification of ST (IP version 5), PIP (= IP >> version 8) and TUBA (IP version 9) to Historic >> Authors : Mohamed Boucadair >> Christian Jacquenet >> Filename : draft-boucadair-ip-version-5-8-9-historic-00.txt >> Pages : 5 >> Date : 2016-03-16 >> >> Abstract: >> This document reclassifies ST (IP version 5), PIP (IP version 8) an= d >> TUBA (IP version 9) to Historic status. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-boucadair-ip-version-5-8-9- >> historic/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-boucadair-ip-version-5-8-9-historic-= 00 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20 --tK6dtIeBDe3jMBGcX2PrIVuvLNvAiv4B7-- --2JtJDQPkI5v6a82cqprG4XtnsjvBnkOxf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW6qY+AAoJEBOZRqCi7goqYCQH+QEPj72TyeOAUyDD74nxNoMB RpGhyHxB0CwhdFsAsowAETU7ADijTvCq56AdrIbdm3V/KQYPcceRQM95YHlW84Ii Wgwytf4xjEnB/tT/VNBl3NqMitLn6j1Aq5dkDwWwk6DAs/0TEPAaq0ho0w7G6gXy 4/6CaLrexpR4kvhq4nTyx6MFqbf5LZHd/aGUPf8AFuk9YAC1/e0pAKspI9HdfDEv G7uaKkXzaRrLWiDV8cXhnVRhHLRuZr/zhWif9hDFa5q1u9M4t4/VPB35jdau5ldH q5gfp09EQXWKN+1evP1LIENnUBnhzsNAv6JNAdZXqUbOZWXJJsd3AP14lR7UTsc= =gdj7 -----END PGP SIGNATURE----- --2JtJDQPkI5v6a82cqprG4XtnsjvBnkOxf-- From nobody Thu Mar 17 06:15:08 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F99B12D546 for ; Thu, 17 Mar 2016 06:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGbLsmv73f_S for ; Thu, 17 Mar 2016 06:15:05 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6730512D519 for ; Thu, 17 Mar 2016 06:14:55 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 402CA405D9; Thu, 17 Mar 2016 14:14:54 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 190271A006E; Thu, 17 Mar 2016 14:14:54 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0279.002; Thu, 17 Mar 2016 14:14:53 +0100 From: To: Brian Haberman , "int-area@ietf.org" Thread-Topic: [Int-area] draft-boucadair-ip-version-5-8-9-historic Thread-Index: AQHRgEqFHDpOctqs8USm0sOrBPo2Gp9dnA1A Date: Thu, 17 Mar 2016 13:14:53 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D17852@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <455e5075-3291-4f3c-9511-c7a3731c6539@OPEXCLILMA2.corporate.adroot.infra.ftgroup> <56EAA63E.80908@innovationslab.net> In-Reply-To: <56EAA63E.80908@innovationslab.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] draft-boucadair-ip-version-5-8-9-historic X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 13:15:07 -0000 Hi Brian,=20 The purpose is not have this I-D published as an RFC but to follow the proc= edure as per bullet 2 of https://www.ietf.org/iesg/statement/designating-rf= cs-as-historic.html.=20 Can you take care of creating a status-change document for these RFCs? Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Int-area [mailto:int-area-bounces@ietf.org] De la part de Brian > Haberman > Envoy=E9=A0: jeudi 17 mars 2016 13:43 > =C0=A0: int-area@ietf.org > Objet=A0: Re: [Int-area] draft-boucadair-ip-version-5-8-9-historic >=20 > This is a fine thing to do, but it does not require an I-D to do it. An > AD can create a status-change document that moves the three RFCs > mentioned in the draft to Historic status. Any justification for the > move can be included in the status-change document. Here is an example > of one that was done recently: >=20 > https://datatracker.ietf.org/doc/status-change-service-mappings-to- > historic/ >=20 > Regards, > Brian >=20 > On 3/17/16 3:32 AM, mohamed.boucadair@orange.com wrote: > > Dear all, > > > > We do think it is time to move those specifications to Historic and > deallocate the IP version numbers. > > > > Comments are welcome. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > >> internet-drafts@ietf.org > >> Envoy=E9 : mercredi 16 mars 2016 16:34 > >> =C0 : i-d-announce@ietf.org > >> Objet : I-D Action: draft-boucadair-ip-version-5-8-9-historic-00.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> > >> Title : Reclassification of ST (IP version 5), PIP > (IP > >> version 8) and TUBA (IP version 9) to Historic > >> Authors : Mohamed Boucadair > >> Christian Jacquenet > >> Filename : draft-boucadair-ip-version-5-8-9-historic-00.txt > >> Pages : 5 > >> Date : 2016-03-16 > >> > >> Abstract: > >> This document reclassifies ST (IP version 5), PIP (IP version 8) an= d > >> TUBA (IP version 9) to Historic status. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-boucadair-ip-version-5-8-9- > >> historic/ > >> > >> There's also a htmlized version available at: > >> https://tools.ietf.org/html/draft-boucadair-ip-version-5-8-9-historic- > 00 > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > From nobody Thu Mar 17 08:01:52 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B5812D883 for ; Thu, 17 Mar 2016 08:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaMsKdzKMmY9 for ; Thu, 17 Mar 2016 08:01:46 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3582112D765 for ; Thu, 17 Mar 2016 08:01:45 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 09EC1880E2; Thu, 17 Mar 2016 08:01:45 -0700 (PDT) Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 97B88328081A; Thu, 17 Mar 2016 08:01:44 -0700 (PDT) To: mohamed.boucadair@orange.com, "int-area@ietf.org" References: <455e5075-3291-4f3c-9511-c7a3731c6539@OPEXCLILMA2.corporate.adroot.infra.ftgroup> <56EAA63E.80908@innovationslab.net> <787AE7BB302AE849A7480A190F8B933008D17852@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Brian Haberman Message-ID: <56EAC6D2.8000906@innovationslab.net> Date: Thu, 17 Mar 2016 11:01:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D17852@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3o3HqK4oBO7558vLpVoaAu3cJudeKuGCc" Archived-At: Subject: Re: [Int-area] draft-boucadair-ip-version-5-8-9-historic X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 15:01:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3o3HqK4oBO7558vLpVoaAu3cJudeKuGCc Content-Type: multipart/mixed; boundary="xh3U74tGFbIofWSp4OF0pMGD2P49RRPkK" From: Brian Haberman To: mohamed.boucadair@orange.com, "int-area@ietf.org" Message-ID: <56EAC6D2.8000906@innovationslab.net> Subject: Re: [Int-area] draft-boucadair-ip-version-5-8-9-historic References: <455e5075-3291-4f3c-9511-c7a3731c6539@OPEXCLILMA2.corporate.adroot.infra.ftgroup> <56EAA63E.80908@innovationslab.net> <787AE7BB302AE849A7480A190F8B933008D17852@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D17852@OPEXCLILMA3.corporate.adroot.infra.ftgroup> --xh3U74tGFbIofWSp4OF0pMGD2P49RRPkK Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, I will create the status-change document. Brian On 3/17/16 9:14 AM, mohamed.boucadair@orange.com wrote: > Hi Brian, >=20 > The purpose is not have this I-D published as an RFC but to follow > the procedure as per bullet 2 of > https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html. >=20 >=20 > Can you take care of creating a status-change document for these > RFCs? >=20 > Thank you. >=20 > Cheers, Med >=20 >> -----Message d'origine----- De : Int-area >> [mailto:int-area-bounces@ietf.org] De la part de Brian Haberman=20 >> Envoy=E9 : jeudi 17 mars 2016 13:43 =C0 : int-area@ietf.org Objet : Re= : >> [Int-area] draft-boucadair-ip-version-5-8-9-historic >>=20 >> This is a fine thing to do, but it does not require an I-D to do >> it. An AD can create a status-change document that moves the three >> RFCs mentioned in the draft to Historic status. Any justification >> for the move can be included in the status-change document. Here is >> an example of one that was done recently: >>=20 >> https://datatracker.ietf.org/doc/status-change-service-mappings-to- >> >>=20 historic/ >>=20 >> Regards, Brian >>=20 >> On 3/17/16 3:32 AM, mohamed.boucadair@orange.com wrote: >>> Dear all, >>>=20 >>> We do think it is time to move those specifications to Historic >>> and >> deallocate the IP version numbers. >>>=20 >>> Comments are welcome. >>>=20 >>> Cheers, Med >>>=20 >>>> -----Message d'origine----- De : I-D-Announce >>>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>>> internet-drafts@ietf.org Envoy=E9 : mercredi 16 mars 2016 16:34 =C0 >>>> : i-d-announce@ietf.org Objet : I-D Action: >>>> draft-boucadair-ip-version-5-8-9-historic-00.txt >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. >>>>=20 >>>>=20 >>>> Title : Reclassification of ST (IP version 5), PIP >> (IP >>>> version 8) and TUBA (IP version 9) to Historic Authors >>>> : Mohamed Boucadair Christian Jacquenet Filename : >>>> draft-boucadair-ip-version-5-8-9-historic-00.txt Pages >>>> : 5 Date : 2016-03-16 >>>>=20 >>>> Abstract: This document reclassifies ST (IP version 5), PIP (IP >>>> version 8) and TUBA (IP version 9) to Historic status. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is:=20 >>>> https://datatracker.ietf.org/doc/draft-boucadair-ip-version-5-8-9- >>>> >>>>=20 historic/ >>>>=20 >>>> There's also a htmlized version available at:=20 >>>> https://tools.ietf.org/html/draft-boucadair-ip-version-5-8-9-histori= c- >> >>>>=20 00 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time >>>> of submission until the htmlized version and diff are available >>>> at tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at:=20 >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ I-D-Announce >>>> mailing list I-D-Announce@ietf.org=20 >>>> https://www.ietf.org/mailman/listinfo/i-d-announce=20 >>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>=20 >>> _______________________________________________ Int-area mailing >>> list Int-area@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/int-area >>>=20 --xh3U74tGFbIofWSp4OF0pMGD2P49RRPkK-- --3o3HqK4oBO7558vLpVoaAu3cJudeKuGCc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW6sbXAAoJEBOZRqCi7goq6O8H+wY+arCU2qk9F4LIhjP28O/V so5YUC9UikeUw+fGTmMMZNM51sTKQwjnnv3riZ5t+G2QQZT++Wo5BrspH8+/0CGY Rgn8CvUOB0o+6qeg7yvLXZlpH5+Y6PC3MlddqDDpmur0GWvotxzJuPtHN++HdFkv eAjWBFgOY4kRHKe9fn3bHHPlFbAB5oK0cN+8gp0MzujR+6dTPML1+GoepSo70IeM vOx3tthaghoW4g2DxdvPCYdMKntc2wO1Vd6kcvJR6tfOh4or5EBpvHwO6OhP9Im2 SjNeeB7qU5Cy+6pQvw9RJ4DPHUCGpDIVlx8RrO+UNzIU8Fcgv/mLl4RyyG7MiMg= =gMUv -----END PGP SIGNATURE----- --3o3HqK4oBO7558vLpVoaAu3cJudeKuGCc-- From nobody Mon Mar 21 10:37:38 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5898812D61B for ; Mon, 21 Mar 2016 10:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdERs41UprYM for ; Mon, 21 Mar 2016 10:37:36 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B94512D9B1 for ; Mon, 21 Mar 2016 10:36:57 -0700 (PDT) Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u2LHatZp028371 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 21 Mar 2016 10:36:55 -0700 To: Mikael Abrahamsson References: <56253854.40808@acm.org> <562538AE.8010703@sonic.net> From: Erik Nordmark Message-ID: <56F03137.9030708@acm.org> Date: Mon, 21 Mar 2016 10:36:55 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVaFQg5zvTD666zZR3WnUVi6am8wezotjNgXkgf6LWK2Tm03LuhNa0dclRdx968K/hMriuqGmhmKJx97QH75epIe X-Sonic-ID: C;kLMtgYvv5RG79436ZLXa/Q== M;DjZkgYvv5RG79436ZLXa/Q== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Cc: Internet Area Subject: Re: [Int-area] Fwd: New Version Notification for draft-nordmark-intarea-ippl-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 17:37:37 -0000 On 11/5/15 1:28 AM, Mikael Abrahamsson wrote: > On Thu, 5 Nov 2015, Dave Thaler wrote: > >> I notice that currently RFC 4389 is not referenced at all. >> It’s Experimental since there are many ways of proxying and it just >> describes one of them, >> but I still think it bears referencing informatively, especially >> since section 6 of that RFC is >> very relevant to the discussion on loops in the document. > > I have in live networks running spanning tree and HSRP seen issue with > the L2 mac learning timeout being 300 second (cisco default) and arp > timeout being 4 hours (also cisco timeout) where in certain topologies > the L2 switch would not see one of the routers mac address until the > arp timeouted, and flooded all traffic to that router to all switches. > > The problem was "fixed" by turning down the arp timeout to 270 seconds. > > THis is not exactly what your draft describes, but it might still be > worth mentioning? Mikael, FWIW I've seen similar interaction with VXLAN where there is dataplane learning in the underlay and the overlay, both interacting with ARP timers. But I don't see how to fit in a discussion about MAC learning in the draft. Any suggestions on how to fit it in? Thanks, Erik From nobody Mon Mar 21 10:39:30 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEE312D661 for ; Mon, 21 Mar 2016 10:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtGLQwBZN6rX for ; Mon, 21 Mar 2016 10:39:19 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B896812D797 for ; Mon, 21 Mar 2016 10:38:22 -0700 (PDT) Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u2LHcK2d029817 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 21 Mar 2016 10:38:20 -0700 To: Dave Thaler References: <56253854.40808@acm.org> <562538AE.8010703@sonic.net> From: Erik Nordmark Message-ID: <56F0318C.3000502@acm.org> Date: Mon, 21 Mar 2016 10:38:20 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVY3V5Oc3MaoA6Kc6AuMnQbccMqI0i3l91Jpw5SZPxgtycx5DJa6AWaNsgBv65ciDfy8JAOIAbrw+SFygFo7VkQ1 X-Sonic-ID: C;auDQs4vv5RGPm436ZLXa/Q== M;GG3/s4vv5RGPm436ZLXa/Q== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Cc: Internet Area Subject: Re: [Int-area] Fwd: New Version Notification for draft-nordmark-intarea-ippl-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 17:39:21 -0000 [With better from address] On 11/5/15 1:24 AM, Dave Thaler wrote: > > I notice that currently RFC 4389 is not referenced at all. > > It’s Experimental since there are many ways of proxying and it just > describes one of them, > > but I still think it bears referencing informatively, especially since > section 6 of that RFC is > > very relevant to the discussion on loops in the document. > Dave, Sorry for the tardy response. I'll definitely add an explicit reference to RFC4389 in the text that currently reads "Hence a NS/NA proxy MUST NOT be used with private VLANs." I don't know if you want some more analysis in the document (in the form of an appendix) of why packet proxies don't work. The short form is that the assumption in RFC4389 is that there is a notion of upstream and downstream, but in a PVLAN with multiple routers (i.e. promiscuous ports) those ports are peers with no upstream vs. downstream notion. Forcing such a notion, e.g., by building a spanning tree, would remove the rapid failover and load-balancing benefits that motivated having multiple promiscuous ports. AFAICT this applies to what I'd call "packet proxies" in general. Such proxies send a NS (with ttl=255) when receiving a NS. What we could call "state proxies" do not have such an issue; an example of such is DAD proxy (RFC 6957) where a packet received from one host is used to build/maintain state which is then used to respond to a NS from another host. That approach never emits a NS as a result of receiving an NS hence does not have the same looping hazard. I'll add something along the above lines and submit an update to the draft. Thanks, Erik *From:*Int-area [mailto:int-area-bounces@ietf.org] *On Behalf Of *Erik Nordmark *Sent:* Tuesday, October 20, 2015 3:39 AM *To:* Internet Area *Subject:* [Int-area] Fwd: New Version Notification for draft-nordmark-intarea-ippl-01.txt This update adds one more issue about Proxy ARP/ND when there are multiple routers. Erik -------- Forwarded Message -------- *Subject: * New Version Notification for draft-nordmark-intarea-ippl-01.txt *Date: * Mon, 19 Oct 2015 11:34:04 -0700 *From: * internet-drafts@ietf.org *To: * Erik Nordmark A new version of I-D, draft-nordmark-intarea-ippl-01.txt has been successfully submitted by Erik Nordmark and posted to the IETF repository. Name: draft-nordmark-intarea-ippl Revision: 01 Title: IP over Intentionally Partially Partitioned Links Document date: 2015-10-19 Group: intarea Pages: 11 URL:https://www.ietf.org/internet-drafts/draft-nordmark-intarea-ippl-01.txt Status:https://datatracker.ietf.org/doc/draft-nordmark-intarea-ippl/ Htmlized:https://tools.ietf.org/html/draft-nordmark-intarea-ippl-01 Diff:https://www.ietf.org/rfcdiff?url2=draft-nordmark-intarea-ippl-01 Abstract: IP makes certain assumptions about the L2 forwarding behavior of a multi-access IP link. However, there are several forms of intentional partitioning of links ranging from split-horizon to Private VLANs that violate some of those assumptions. This document specifies that link behavior and how IP handles links with those properties. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Mar 21 11:15:33 2016 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B7E12D997; Mon, 21 Mar 2016 11:15:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321181529.31984.96027.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 11:15:29 -0700 Archived-At: Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-nordmark-intarea-ippl-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 18:15:29 -0000 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 of the IETF. Title : IP over Intentionally Partially Partitioned Links Author : Erik Nordmark Filename : draft-nordmark-intarea-ippl-03.txt Pages : 11 Date : 2016-03-21 Abstract: IP makes certain assumptions about the L2 forwarding behavior of a multi-access IP link. However, there are several forms of intentional partitioning of links ranging from split-horizon to Private VLANs that violate some of those assumptions. This document specifies that link behavior and how IP handles links with those properties. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nordmark-intarea-ippl/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-nordmark-intarea-ippl-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-nordmark-intarea-ippl-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 13:21:47 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D60312D972 for ; Mon, 21 Mar 2016 10:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT5os_vxo79z for ; Mon, 21 Mar 2016 10:33:00 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1CF812D97D for ; Mon, 21 Mar 2016 10:33:00 -0700 (PDT) Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u2LHWsg7023970 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 21 Mar 2016 10:32:54 -0700 To: Dave Thaler References: <56253854.40808@acm.org> <562538AE.8010703@sonic.net> From: Erik Nordmark Message-ID: <56F03046.3080207@sonic.net> Date: Mon, 21 Mar 2016 10:32:54 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVYUwS0wjUDhL8bH90EOLBXE3GrqlvkkLEto/rqyXWYk81wdC4KJPKEsj8Rh9+IUiNETlx7Dopco0BELhIBs2rmY X-Sonic-ID: C;fH7A8Yrv5RG6DY36ZLXa/Q== M;dAUA8orv5RG6DY36ZLXa/Q== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: X-Mailman-Approved-At: Mon, 21 Mar 2016 13:21:46 -0700 Cc: Internet Area Subject: Re: [Int-area] Fwd: New Version Notification for draft-nordmark-intarea-ippl-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 17:33:02 -0000 On 11/5/15 1:24 AM, Dave Thaler wrote: > > I notice that currently RFC 4389 is not referenced at all. > > It’s Experimental since there are many ways of proxying and it just > describes one of them, > > but I still think it bears referencing informatively, especially since > section 6 of that RFC is > > very relevant to the discussion on loops in the document. > Dave, Sorry for the tardy response. I'll definitely add an explicit reference to RFC4389 in the text that currently reads "Hence a NS/NA proxy MUST NOT be used with private VLANs." I don't know if you want some more analysis in the document (in the form of an appendix) of why packet proxies don't work. The short form is that the assumption in RFC4389 is that there is a notion of upstream and downstream, but in a PVLAN with multiple routers (i.e. promiscuous ports) those ports are peers with no upstream vs. downstream notion. Forcing such a notion, e.g., by building a spanning tree, would remove the rapid failover and load-balancing benefits that motivated having multiple promiscuous ports. AFAICT this applies to what I'd call "packet proxies" in general. Such proxies send a NS (with ttl=255) when receiving a NS. What we could call "state proxies" do not have such an issue; an example of such is DAD proxy (RFC 6957) where a packet received from one host is used to build/maintain state which is then used to respond to a NS from another host. That approach never emits a NS as a result of receiving an NS hence does not have the same looping hazard. I'll add something along the above lines and submit an update to the draft. Thanks, Erik > Dave > > *From:*Int-area [mailto:int-area-bounces@ietf.org] *On Behalf Of *Erik > Nordmark > *Sent:* Tuesday, October 20, 2015 3:39 AM > *To:* Internet Area > *Subject:* [Int-area] Fwd: New Version Notification for > draft-nordmark-intarea-ippl-01.txt > > This update adds one more issue about Proxy ARP/ND when there are > multiple routers. > > Erik > > > -------- Forwarded Message -------- > > *Subject: * > > > > New Version Notification for draft-nordmark-intarea-ippl-01.txt > > *Date: * > > > > Mon, 19 Oct 2015 11:34:04 -0700 > > *From: * > > > > internet-drafts@ietf.org > > *To: * > > > > Erik Nordmark > > A new version of I-D, draft-nordmark-intarea-ippl-01.txt > has been successfully submitted by Erik Nordmark and posted to the > IETF repository. > Name: draft-nordmark-intarea-ippl > Revision: 01 > Title: IP over Intentionally Partially Partitioned Links > Document date: 2015-10-19 > Group: intarea > Pages: 11 > URL:https://www.ietf.org/internet-drafts/draft-nordmark-intarea-ippl-01.txt > Status:https://datatracker.ietf.org/doc/draft-nordmark-intarea-ippl/ > > Htmlized:https://tools.ietf.org/html/draft-nordmark-intarea-ippl-01 > > Diff:https://www.ietf.org/rfcdiff?url2=draft-nordmark-intarea-ippl-01 > > Abstract: > IP makes certain assumptions about the L2 forwarding behavior of a > multi-access IP link. However, there are several forms of > intentional partitioning of links ranging from split-horizon to > Private VLANs that violate some of those assumptions. This document > specifies that link behavior and how IP handles links with those > properties. > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > The IETF Secretariat > From nobody Mon Mar 21 13:21:49 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D4412DB56 for ; Mon, 21 Mar 2016 13:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB9JKwwgWXOF for ; Mon, 21 Mar 2016 13:16:10 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90D512DB36 for ; Mon, 21 Mar 2016 13:15:59 -0700 (PDT) Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u2LKFvVI018376 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 21 Mar 2016 13:15:57 -0700 References: <56F05568.4030507@acm.org> To: Internet Area From: Erik Nordmark X-Forwarded-Message-Id: <56F05568.4030507@acm.org> Message-ID: <56F0567D.4060808@sonic.net> Date: Mon, 21 Mar 2016 13:15:57 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F05568.4030507@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVanw48m4xSX51NAgFSqXmiPfH6H3Of1aOTlPcX5q+nsrO++NSus5dtRGbvjWQPachVfMT92qLhabjZiOopr++vi X-Sonic-ID: C;7NXKuKHv5RGeU5FDXdaMvg== M;8t0CuaHv5RGeU5FDXdaMvg== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: X-Mailman-Approved-At: Mon, 21 Mar 2016 13:21:46 -0700 Subject: [Int-area] Fwd: New Version Notification for draft-nordmark-intarea-ippl-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 20:16:12 -0000 Updated based on comment from Dave Thaler. Let me know if there are any other open issues; I don't have any. Erik -------- Forwarded Message -------- Subject: New Version Notification for draft-nordmark-intarea-ippl-03.txt Date: Mon, 21 Mar 2016 11:15:29 -0700 From: internet-drafts@ietf.org To: Erik Nordmark A new version of I-D, draft-nordmark-intarea-ippl-03.txt has been successfully submitted by Erik Nordmark and posted to the IETF repository. Name: draft-nordmark-intarea-ippl Revision: 03 Title: IP over Intentionally Partially Partitioned Links Document date: 2016-03-21 Group: intarea Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-nordmark-intarea-ippl-03.txt Status: https://datatracker.ietf.org/doc/draft-nordmark-intarea-ippl/ Htmlized: https://tools.ietf.org/html/draft-nordmark-intarea-ippl-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-nordmark-intarea-ippl-03 Abstract: IP makes certain assumptions about the L2 forwarding behavior of a multi-access IP link. However, there are several forms of intentional partitioning of links ranging from split-horizon to Private VLANs that violate some of those assumptions. This document specifies that link behavior and how IP handles links with those properties. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Mar 21 14:14:00 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7123B12D86D for ; Mon, 21 Mar 2016 14:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwSIDeVHfqXU for ; Mon, 21 Mar 2016 14:13:52 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D557412D90A for ; Mon, 21 Mar 2016 14:13:51 -0700 (PDT) Received: from ipv6.dynamic.ziggo.nl (ipv6.dynamic.ziggo.nl [IPv6:2001:1c00:161d:df00:44c0:7034:5adf:749b] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id u2LLDVQX076776 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2016 22:13:32 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 21 Mar 2016 22:13:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <57365DC4-209F-4BC5-BEB2-4B76F2B3E49D@muada.com> References: To: Pat Thaler X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] Comments on draft-van-beijnum-multi-mtu-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 21:13:54 -0000 Hi Pat, Not sure if you're still reading a year and a half later, but here = goes... On 14 Nov 2014, at 20:56, Pat Thaler wrote: > Abstract and 1 mention sending an Ethernet maximum frame size of 1500 = bytes and the referenced RFC 4321 in 7.2 mentions backing that off to = 1400 bytes to allow for tunnels. RFC 4821, you mean. What this RFC suggests is to start probing with 1400-byte packets. = That's as good a value as any, see the discussions about probing back in = November 2014. > Support for the larger frame size is common so generally 1500 byte = packets plus a reasonable amount of encapsulation should go through. = Wince RFC 4321 was completed around the same time as IEEE 802.3as, it = doesn=E2=80=99t take the envelope maximum frame size into account, but = now 8 years later there generally isn=E2=80=99t a need to back off = transmitted packet size from 1500 bytes to allow for tunnels. > The draft might mention this.=20 I've added an explicit reference to 802.3AS-2006 and frame expansion. However, note that IPv4 and IPv6 over Ethernet do not reference 802.3, = they are based on Ethernet II instead. > 3. Defining Confirmed MTU as the largest packet successfully received = or the largest packet acked assumes that the path is symmetric which it = might not be. Equating MRU to MTU makes the same assumption. While often = the L2 receive path is the same as the transmit path, that is not always = the case. I changed this. > 9.1 There are diminishing returns in efficiency as MTU size increases = and the disadvantage such as head of line blocking and congestion = increase. For example, Taking into account Ethernet overheads (IPG, = preamble, MAC header), IPv6 header and TCP header, throughput is 87.7% = for 1500 byte MTU, 97.8% for 9000 bytes and 98.9% for 18000 bytes. Data overhead is not the main issue, the fact that senders and receivers = as well as routers and switches have to handle millions of packets per = second is the main problem. > 11. Sending of large packets based on a neighbor=E2=80=99s = willingness to accept them may degrade QoS for other traffic including = traffic between other nodes on the subnet. This could be a kind of = denial of service to traffic that depends on low latency. This should be = discussed as a security consideration. Added. > Annex B doesn=E2=80=99t mention that there can be physical layer = limitations for large packets. Many Ethernet PHYs have a clock skew = FIFO to deal with differences in the transmitter=E2=80=99s clock rate = and the receiver=E2=80=99s clock rate. I added a paragraph on clock skew. > B.1 The is no support provided for the assumption in the last = paragraph. There are cases where higher speed links are used to reduce = latency and latencies in the low microseconds are desired. I added some text that addresses this. > B.4, This section is incorrect. The Ethernet CRC has a hamming = distance of 4 for up to the maximum packet size. IEEE 802.3=E2=80=99s = design goal for undetected packet error rate requires a hamming distance = of 4 (i.e. an 3 bit errors in a packet are detected). =20 > According to =E2=80=9C32-Bit Cyclic Redundancy Codes for Internet = Applications=E2=80=9D Philip Koopman, the Ethernet CRC has a hamming = distance of 4 to 91067 bits (11,450 bytes). It seems that I interpreted the old paper incorrectly and used 3 where = it should be 4. I have corrected this. Interesting that the newer paper = comes out with a packet size that's a few bytes smaller. I've kept the = number and reference to the old paper, though. > B.5 There is no substantiation for the statements here. The = disadvantage to small packet users may not be slight. Transmission rate = ramping more quickly with large packet size may cause considerable = congestion for all and take significant time to resolve. For those using = large packets, TCP congestion control may not be able to reduce the rate = enough. Have simulations or tests been conducted? I don't know of any simulations or tests. However, the congestion = control behavior of TCP and its interaction with packet size are clear = in the models that aren't controversial, this should suffice for an = experimental protocol. > B.7 Conclusion =E2=80=93 with my IEEE 802 hat off, I agree that there = are environments such as some data centers where 9000 byte jumbo frames = will function fine, but I don=E2=80=99t think they should be unleashed = on the big I internet and I don=E2=80=99t think that 64K jumbos are wise = anywhere. Much of this draft doesn=E2=80=99t seem consistent with this = conclusion rather it seems to support much larger jumbo frames. Mention = of 9000 bytes and an applicability statement should be placed in the = body of the draft, not left to the end of an annex. I added a paragraph about applicability, warning against MTUs larger = than 11k. Thanks again, Iljitsch= From nobody Mon Mar 21 14:47:09 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E7D12D0A1; Mon, 21 Mar 2016 14:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgGMi-7ET4Gl; Mon, 21 Mar 2016 14:47:03 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD5112D09F; Mon, 21 Mar 2016 14:47:02 -0700 (PDT) Received: from ipv6.dynamic.ziggo.nl (ipv6.dynamic.ziggo.nl [IPv6:2001:1c00:161d:df00:44c0:7034:5adf:749b] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id u2LLkfSZ077154 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2016 22:46:42 +0100 (CET) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Mar 2016 22:46:52 +0100 References: <20160321213322.12239.62052.idtracker@ietfa.amsl.com> To: int-area@ietf.org, 6man Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [Int-area] draft-van-beijnum-multi-mtu-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 21:47:05 -0000 (Please note: crossposted to 6man and intarea, please prune as desired.) I've been working on a specification that allows for hosts on the same = subnet to be configured with different jumboframe MTUs and then use the = largest packet size supported by the sender and the receiver as well as = the switches in the middle. This has been discussed in intarea in the past, but I'm also sending the = announcement of the new version of the draft to 6man because there's a = new ND option and a change to the RA MTU option. Feedback is highly appreciated. Iljitsch > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Date: 21 March 2016 at 22:33:22 +0100 > To: > Subject: I-D Action: draft-van-beijnum-multi-mtu-05.txt > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Extensions for Multi-MTU Subnets > Author : Iljitsch van Beijnum > Filename : draft-van-beijnum-multi-mtu-05.txt > Pages : 24 > Date : 2016-03-21 >=20 > Abstract: > In the early days of the internet, many different link types with > many different maximum packet sizes were in use. For point-to-point > or point-to-multipoint links, there are still some other link types > (PPP, ATM, Packet over SONET), but multipoint subnets are now almost > exclusively implemented as Ethernets. Even though the relevant > standards mandate a 1500 byte maximum packet size for Ethernet, more > and more Ethernet equipment is capable of handling packets bigger > than 1500 bytes. However, since this capability isn't standardized, > it is seldom used today, despite the potential performance benefits > of using larger packets. This document specifies mechanisms to > negotiate per-neighbor maximum packet sizes so that nodes on a > multipoint subnet may use the maximum mutually supported packet size > between them without being limited by nodes with smaller maximum > sizes on the same subnet. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-van-beijnum-multi-mtu/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-van-beijnum-multi-mtu-05 >=20 From nobody Tue Mar 29 03:53:48 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D8F12D0E7 for ; Tue, 29 Mar 2016 03:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gyLLD-LLJ9y for ; Tue, 29 Mar 2016 03:53:45 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA6912D68C for ; Tue, 29 Mar 2016 03:53:39 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id h6so16000108oia.2 for ; Tue, 29 Mar 2016 03:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fHFaNGlgbyuwXPXtzUrfePUKxdyeK3C4svsaqS4LIf4=; b=Uvpzibzz5hbIgrAFM3kSM3GNgI0RIqO2LfDwUX3RyYw6hEsHVFqbEVzV710VYsQg+J VceEY1LrxQDvSb5QOAfD3Yy699OhoWa+cgO+i3pW8nqOh8rNUiDSuv/BckxaN+1MyuWN XgYPJJoIffrQgEJI8phCe9MpXCCEXJwJytHqBasggNuWceBUNbvoS4DPrP4RkE9/+FTM OfAGxaTy3dOWzKoiFnKno95rZPApRpWCVBP0Iv9Hv5fL/NsK7FQNHJa599lolz1TeEDl uYQ/eKq63FME1ZAzJC0VnF2P4CsuilKCgysvJz12ZSYgqAeEyIwm+OnJYjBiuj2UWh1E xgXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fHFaNGlgbyuwXPXtzUrfePUKxdyeK3C4svsaqS4LIf4=; b=m7QunUDxeq52M9QBqPpRrL3rzpG8wTJSWWPl8ekkjnMzgCfAE6yfebbDR5yuonxMO4 Kcs4SrW541HjeJyKWNxmk//8llBXtVfmP9D9Oa90quO14lYbvveMUH3GxevRCjddq3eL 9Cxadcjw60KRjHbeKLpLqF1fF1SIw2RPSR3jklg5rXcyPjlu4RPqcMhG5X7EY3TpICXv e9hXBLXBPJu7bx7kjOptF87SxsjL0dVCAskTML6wriWTzN6bGRug8DMSw5vWHIsXA3nD iWGAds88NbLOQ56Fn413E6habsrlUdv3qc5slc4oFzG4VYdPovsc7xxRAcTr+NTVHW4F X7pg== X-Gm-Message-State: AD7BkJKx0F9+L+T0afZBhvgXdloouyXdgCt7KgqBh4qqaweAYBzWug24Nre483rUtbCL1GWqZdDLRZnNMPNdbQ== MIME-Version: 1.0 X-Received: by 10.202.74.132 with SMTP id x126mr578227oia.45.1459248819140; Tue, 29 Mar 2016 03:53:39 -0700 (PDT) Received: by 10.157.40.114 with HTTP; Tue, 29 Mar 2016 03:53:39 -0700 (PDT) In-Reply-To: <56F0567D.4060808@sonic.net> References: <56F05568.4030507@acm.org> <56F0567D.4060808@sonic.net> Date: Tue, 29 Mar 2016 06:53:39 -0400 Message-ID: From: Sowmini Varadhan To: Erik Nordmark Content-Type: multipart/alternative; boundary=001a113dc710810341052f2dd7f6 Archived-At: Cc: Internet Area Subject: Re: [Int-area] Fwd: New Version Notification for draft-nordmark-intarea-ippl-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 10:53:47 -0000 --001a113dc710810341052f2dd7f6 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 21, 2016 at 4:15 PM, Erik Nordmark wrote: > > URL: > https://www.ietf.org/internet-drafts/draft-nordmark-intarea-ippl-03.txt aiui, the problem statement here is that you can have one IP subnet broken into islands of isolated/community vlans that are not necessarily in the same IP bcast domain, so IP-based protocols have to factor in that consideration. Is DHCP another example of such a protocol that might have similar caveats (e.g., if a node in a community vlan gets some info from the dhcp server, then the info for the default router needs to be on the node's community vlan or a promisc vlan)? There may also be some rules around icmp redirect generation that cannot be based purely on IP subnet mask checks? --Sowmini --001a113dc710810341052f2dd7f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 21, 2016 at 4:15 PM, Erik Nordmark <nordmark@sonic.net> wrote:

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-nordmark-intare= a-ippl-03.txt

=C2=A0aiui, the problem s= tatement here is that you can have one
IP subnet broken into = islands of isolated/community vlans
that are not necessarily= in the same IP bcast domain, so
IP-based protocols have to f= actor in that consideration.

Is DHCP another example of = such a protocol that might have
similar caveats (e.g., if a n= ode in a community vlan gets
some info from the dhcp server, = then the info for the default
router needs to be on the node&= #39;s community vlan or a
promisc vlan)? There may also be so= me rules around icmp
redirect generation that cannot be based= purely on IP subnet
mask checks?

--Sowmini=



--001a113dc710810341052f2dd7f6-- From nobody Tue Mar 29 15:21:56 2016 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D238C12DA38; Tue, 29 Mar 2016 15:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnXDwLlfm2no; Tue, 29 Mar 2016 15:21:51 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A30E412DA26; Tue, 29 Mar 2016 15:21:51 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 93C5188153; Tue, 29 Mar 2016 15:21:51 -0700 (PDT) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id EA947328081A; Tue, 29 Mar 2016 15:21:50 -0700 (PDT) To: 95attendees@ietf.org, "int-area@ietf.org" From: Brian Haberman Message-ID: <56FAFFFE.6060809@innovationslab.net> Date: Tue, 29 Mar 2016 18:21:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UJkBtxE1rd1LRpg7H3GvfI120NARlJqwW" Archived-At: Subject: [Int-area] INT AD office hours X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 22:21:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UJkBtxE1rd1LRpg7H3GvfI120NARlJqwW Content-Type: multipart/mixed; boundary="Dvv975XER87mXiFVQkmtc6bFujuQbumSr" From: Brian Haberman To: 95attendees@ietf.org, "int-area@ietf.org" Message-ID: <56FAFFFE.6060809@innovationslab.net> Subject: INT AD office hours --Dvv975XER87mXiFVQkmtc6bFujuQbumSr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable All, As per custom, we will be holding Internet AD office hours in Buenos Aires. All three of us will be available on Wednesday from 1600-1700 in the Paraiso Room. Feel free to stop by and chat about Internet Area issues that are of interest to you. Regards, Brian, Terry, & Suresh --Dvv975XER87mXiFVQkmtc6bFujuQbumSr-- --UJkBtxE1rd1LRpg7H3GvfI120NARlJqwW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW+v/+AAoJEBOZRqCi7goqENEH/3Lhdi9N4h7oTCIpb8M6gOD0 Ga+Wj9c9ey5FH/ECg6V7Rn3vp0Y/nZqb6tyJC3KnpnDy0nxxlHNdcUaamv2KIHbz Rd5QbYepiCTpDFetQtjBTLknK0S6o3NEguCceorOx4/lsB3jiY64jtHu/aGaxEwZ 7vqkKQRLH1rAFSPV2n10HyVSx2W4rIMUUjBTVLlZKKQSokvK8IIYZjWxxUGfknuc iMylozhqc7Hbsx/UlgIf/x+JDS/HShi5hgSAAqaPGBvliU/t6Z/Bz6bwAb6XXhDJ D9l5SRtbRlFTLojEChun+Z0LXgSOdqordVqXebvHZyW44JU2GWcu9+1OIdZXXzM= =APXj -----END PGP SIGNATURE----- --UJkBtxE1rd1LRpg7H3GvfI120NARlJqwW--