From kristian.poscic@nokia.com Thu Mar 10 09:29:46 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-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" Subject: UDP zero-checksum in IPv4 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-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 17:30:49 -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 Thu Mar 10 09:41:44 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-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)" Subject: Re: UDP zero-checksum in IPv4 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" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 17:41:42 -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:36 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-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)" Subject: Re: UDP zero-checksum in IPv4 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" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services 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 22:03:40 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-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)" Subject: RE: [Int-area] UDP zero-checksum in IPv4 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: Cc: "softwires@ietf.org" , "tsv-area@ietf.org" , "int-area@ietf.org" , "maprg@irtf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services 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 Thu Mar 10 23:36:57 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-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 Subject: RE: [Int-area] UDP zero-checksum in IPv4 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: Cc: "maprg@irtf.org" , "int-area@ietf.org" , EXT Tom Herbert , "tsv-area@ietf.org" , "softwires@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services 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 05:32:17 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-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" Subject: RE: [Int-area] UDP zero-checksum in IPv4 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: Cc: "maprg@irtf.org" , "int-area@ietf.org" , EXT Tom Herbert , "tsv-area@ietf.org" , "softwires@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services 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 Sun Mar 20 22:37:55 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9956D12D603; Sun, 20 Mar 2016 22:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 BqeVkEUTxLZt; Sun, 20 Mar 2016 22:37:52 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 2D21912D5DF; Sun, 20 Mar 2016 22:37:52 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id l68so108074117wml.1; Sun, 20 Mar 2016 22:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:reply-to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=pOAtDTTqQPqkYCvGS95j0wEeW72oheFlnmf1WNg/4SA=; b=hHbZZG+Q2zEZ0sbocZXkKltgBVo9tcdy3awhX73vfaD9VSpPqT/6sH/U6nyR1D0ysk pH4QeUx+ZrH8+kPQf2vSP331UlSKDWdWL/bFaTMPSE1s+aJ6S+xzmklkvSpDSiqHxKcL j8p8dshbjlkPtXplM6tvYKoDSYS97BOPvtS4laQgdEqHJlzvc6dSa4bHMgg1pQnhz3HQ JCvBjEcyFBnsxAa4NtmRHh+kpVTg40KJD1iNsy7QtAnclGq28KDcmcMOQ+3s16h7jAxe TulzPFbougJFMPHXlAMsGgtgdC6mD/UyskUhG3f4fEJBMUH4thDdueB+hGYPlKJXL6mp czBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:reply-to:from:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=pOAtDTTqQPqkYCvGS95j0wEeW72oheFlnmf1WNg/4SA=; b=MAbVQ5CCQ20wd8gNEmMIJ5CEkg7uZ4h5k2lw0gwMlt0k58JIFdXhbVWZHLaWyQfCuc 3XgjNhP8BAIutOO4ArivgAtpZbYOKBhZqzqt+HuJLbL4CpvCnqcMPYOHFBGezY2FKRqc oiV9VJbRI1PO5j9nQvCbqlydWNvl/ATR7+M1ez3+b6fHZ4yJIuzCy4lDmSzfcM/BIAXc A6kRyfr6g3YccRpVdI5DcvmsI49mVYGmwIi+rFgkAW0dsnaIqU0FKzIB2S+B8UpHGmbY x6ae3YnmWhbpf4ZtduPRu5/f3fqxkjccV9OoVVU0eSAjATv/umKtlgP590ne93pAHdXF W6lw== X-Gm-Message-State: AD7BkJJdCACVSaZuNn2M4EhDoK5bdFSO7yRyY2nkkavqJ4W0SgVhYwNiHLKkHSXQeDXEvQ== X-Received: by 10.28.53.134 with SMTP id c128mr11880206wma.10.1458538670704; Sun, 20 Mar 2016 22:37:50 -0700 (PDT) Received: from ?IPv6:2003:74:cf6f:1931:1023:4109:c:c026? (p200300061749353110234109000CC026.dip0.t-ipconnect.de. [2003:6:1749:3531:1023:4109:c:c026]) by smtp.googlemail.com with ESMTPSA id gt7sm23602658wjc.1.2016.03.20.22.37.49 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Mar 2016 22:37:50 -0700 (PDT) To: "tsv-area@ietf.org" From: Martin Stiemerling Subject: Meet your Area Directors: TSV AD "office hours" at IETF-95 Message-ID: <56EF88AC.70905@gmail.com> Date: Mon, 21 Mar 2016 06:37:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "tsv-ads@tools.ietf.org" List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 05:37:53 -0000 Dear all, This is the announcement of the TSV AD "office hours" at the IETF-95 meeting. The office hours are for the case there are things that you need to discuss with the Transport Area Directors in person and aren't able to pin us down any other time. The time slot reserved for the office hours is Tuesday, April 5, 2016 16:20-17:20 Tuesday Afternoon session II Room is to be announced. Please let us know in advance if you are planning to meet us, so that we can plan a bit ahead, if possible. Thanks, Mirja, Spencer & Martin