From nobody Thu Feb 2 01:38:36 2017 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 5A0AB127078; Thu, 2 Feb 2017 01:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.12 X-Spam-Level: X-Spam-Status: No, score=-10.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.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 fLhWNrXIt3RV; Thu, 2 Feb 2017 01:38:25 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F6F1293E4; Thu, 2 Feb 2017 01:38:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,323,1477983600"; d="asc'?scan'208";a="168855953" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx142-out.netapp.com with ESMTP; 02 Feb 2017 01:30:35 -0800 Received: from VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Feb 2017 01:37:14 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 2 Feb 2017 01:37:14 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fdruvhxcodu8xWw4CLJ7ZCjR1NTNXXUfuxgankvsGxA=; b=RRfctlqeI+KmYtitoNEDXusk+PaZGpoNvT01wFwy0BEBBFzLxF3P+Wrrc7EVZRibeCEuu5qgFWSkLfJSuAkpmzDUn670L/OcLBKqCDu1qmI8OD1Dyyuue6E25drVM6IjOzvAWAW3J7LGt4u+oxXx4mJESOAyuK4ks9yITe7Al88= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1154.namprd06.prod.outlook.com (10.160.157.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Thu, 2 Feb 2017 09:37:16 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0874.024; Thu, 2 Feb 2017 09:37:16 +0000 From: "Eggert, Lars" To: "ietf@ietf.org" Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Topic: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Index: AQHSfOZWQnyqff8qTkSuzK39n1gXQaFVdhOA Date: Thu, 2 Feb 2017 09:37:16 +0000 Message-ID: <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> In-Reply-To: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: 97d642a3-4512-49d7-3fe6-08d44b4f1370 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1154; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1154; 7:iFbZ4Tp5PXs9FB6A41n297PsdJ9Jlhlnpypfgqm3q+4F4etS+EqJzvWMX5LYKX1c/xAu+mthzBIPAKcAGoyJ0X1+pjTBxu99gIQqbhybaq+iwXFag/WvcCBSr/heS53yDo2cV71qJkgwgrpZcubpN8kmPtMMFtCxsQcSROfcApDvvDxJg16cVcFD+T95boCurqdYlg+7zsr97wO2+aYnQHLi4ZfNA5IsrvLjst8g8bw7nZXlsjcSuQXrIvefLs/mkAgWqhoQFUjaca7JsmPbunCgHCKBRRKcdeViWcp9G4zosJNl1Lmmf6y52O+dhQNREafkw1Wm3NHrMvFNnsZC35rC24jSOzDALAfV1vb3nSig1ckk4/T3UxxhkYnwj6+yNiYFlUWdZRCnHUtUAl7fxKFRb/L1LMj5EosdEENAz8RU+cFX5pYYGDFLk0iczIZosmM5r8Iixd/W3mBQnI0gAlMfJZ/0/Zf+kM/OO5otQ/CT1w3xsZvOvZ3TN1dIf9kTc11y/pvyNEZUlCHogT2DYeaNuXiZ9bRDrjGX9TeMOysOYSX4uXb0YyZsnlpPjVS4 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR0601MB1154; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1154; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(99936001)(305945005)(5660300001)(50986999)(229853002)(7736002)(76176999)(2906002)(6436002)(106116001)(106356001)(105586002)(6506006)(77096006)(189998001)(5640700003)(25786008)(33656002)(230783001)(122556002)(54906002)(3280700002)(101416001)(2351001)(97736004)(6486002)(6512007)(86362001)(99286003)(81166006)(81156014)(1730700003)(8676002)(68736007)(8936002)(2501003)(82746002)(38730400001)(57306001)(83716003)(92566002)(66066001)(50226002)(36756003)(3846002)(102836003)(6116002)(110136003)(2950100002)(3660700001)(4326007)(6916009)(53936002)(2900100001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1154; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_5B28CAC1-2224-438D-B823-71DDFFAF63CA"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 09:37:16.5768 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1154 X-OriginatorOrg: netapp.com Archived-At: Cc: "tsv-area@ietf.org" , "otroan@employees.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "ipv6@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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: Thu, 02 Feb 2017 09:38:26 -0000 --Apple-Mail=_5B28CAC1-2224-438D-B823-71DDFFAF63CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, the last paragraph of the introduction reads: An extension to Path MTU Discovery defined in this document can be found in [RFC4821]. It defines a method for Packetization Layer Path MTU Discovery (PLPMTUD) designed for use over paths where delivery of ICMP messages to a host is not assured. Given that ICMP delivery cannot be assured over the vast majority of = paths in the current Internet, should this document make a = recommendation to implement RFC4821? Also, even if ICMP delivery is assured, there are additional = complications for UDP, which has been seeing a lot of interest both as a = tunneling encapsulation and for applications (e.g., QUIC). Many = platforms do not provide UDP-sending applications any information about = arriving ICMP messages that were triggered by their transmissions. So = even if the path delivers ICMP, the OS makes ICMP-based PMTUD for UDP = often impossible. Another reason to recommend 4821? Lars --Apple-Mail=_5B28CAC1-2224-438D-B823-71DDFFAF63CA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYkv3LAAoJEFS1wwm/cMFXRvAQALQU/vJswPUs46lxSUVrr43m 9Wfu/sctgqGJcvKDM3k5/EMspqc7md7meBavbmMqwz9DwQuSsPO4iZHrBF6246ZD gk6nQ3eM4XBIcpaCuiUpkxLFyB9aBHjApO+u6FID/dDJLhG2WIvNA7e5NyMjo94v KTqWpQXVCBhLAHxlgvB/4v0C7K8GTpfhgWB9m02aX+sd7HvxdCGNhDtGuJ9H8sAt G+PnCtWPj1NI9lyZ9G8iemYhQPcP6+qRF3YcXF3i24n+qYNteYCPCZWlWaAiguMc bZqJ4wQPhHP0p/FrixV1HP+5cxZWRLQRrO78s4K6isUFC4ETOsIQKv7w7ltm0k7R 6mv/6BYnZhokBr7NhXAzfAI6gOE4ZnHrEvc/fZdbWpVvtWpxCf16Dvt6wKgIaywP 6DnrfORu4mzaNxJRAsMstcbYKztohcoKt9536/ItOYX7V6cQI4m+OO5L+FF0BPZV af5Sk30vaSYOu47Dr7tnZ4yVEBzODvJsFOax42QycCq91BJQimKrDAkvdsDAjVN6 Gtpt6reM7UTexR1xDo5bsqY9d0NXYenc1biu1ydEMI59sveQFVD0it1FaLgxx3H7 qJXVxRl4flvYChXYnym+OujorTMbnnsbBc1ZAu7w3Xrh8JaCYJ0X4os3T5EaingD Y1m41HnEevq5/eWuSB4n =BgGh -----END PGP SIGNATURE----- --Apple-Mail=_5B28CAC1-2224-438D-B823-71DDFFAF63CA-- From nobody Thu Feb 2 02:17:06 2017 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 B698B129437; Thu, 2 Feb 2017 02:16:57 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Gbk0VQYzUp0t; Thu, 2 Feb 2017 02:16:53 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB784129422; Thu, 2 Feb 2017 02:16:52 -0800 (PST) Received: from [IPv6:2001:1291:200:42e::2] (cl-1071.udi-01.br.sixxs.net [IPv6:2001:1291:200:42e::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id EAA2782BA4; Thu, 2 Feb 2017 11:16:46 +0100 (CET) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: "Eggert, Lars" , "ietf@ietf.org" References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 2 Feb 2017 06:54:16 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "ipv6@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "tsv-area@ietf.org" , "draft-ietf-6man-rfc1981bis@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: Thu, 02 Feb 2017 10:16:58 -0000 Hi, Lars, On 02/02/2017 06:37 AM, Eggert, Lars wrote: > Hi, > > the last paragraph of the introduction reads: > > An extension to Path MTU Discovery defined in this document can be > found in [RFC4821]. It defines a method for Packetization Layer > Path MTU Discovery (PLPMTUD) designed for use over paths where > delivery of ICMP messages to a host is not assured. > > Given that ICMP delivery cannot be assured over the vast majority of > paths in the current Internet, should this document make a > recommendation to implement RFC4821? I think that RFC4821 should be recommended, at least for dealing with ICMP blackholes (i.e., use ICMP if you can, but be able to deal with scenarios in which you don't receive them). > Also, even if ICMP delivery is assured, there are additional > complications for UDP, which has been seeing a lot of interest both > as a tunneling encapsulation and for applications (e.g., QUIC). Many > platforms do not provide UDP-sending applications any information > about arriving ICMP messages that were triggered by their > transmissions. So even if the path delivers ICMP, the OS makes > ICMP-based PMTUD for UDP often impossible. Another reason to > recommend 4821? Agreed... although in this case this would be more of an app-layer implementation than one at the transport layer? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 2 02:22:47 2017 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 317C1129404; Thu, 2 Feb 2017 02:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.12 X-Spam-Level: X-Spam-Status: No, score=-10.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.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 9kSepwes-_K1; Thu, 2 Feb 2017 02:22:40 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFA8127076; Thu, 2 Feb 2017 02:22:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,323,1477983600"; d="asc'?scan'208";a="168860564" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx142-out.netapp.com with ESMTP; 02 Feb 2017 02:14:54 -0800 Received: from VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Feb 2017 02:21:33 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 2 Feb 2017 02:21:33 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xX9VijNbEq73c6GysNBXq/mYueK82/S/jHicfwutXK8=; b=RBF2OxuOsoHDTmxMRuc8D7pFIaxS6sfTskKqYpqk8VCIurQm9wTvcdDWR33ZaazPpE2Jjo3qYbZzbKauR7IhOs62ZIpzV1BM5I5/pFGz2XkXHOVJWYSGJTQpZK0DbOAZPUSLVhk7P+blvAA4v2xpxeRnDMl+rmJaz53Ud9nvxRA= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1154.namprd06.prod.outlook.com (10.160.157.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Thu, 2 Feb 2017 10:21:35 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0874.024; Thu, 2 Feb 2017 10:21:35 +0000 From: "Eggert, Lars" To: Fernando Gont Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Topic: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Index: AQHSfOZWQnyqff8qTkSuzK39n1gXQaFVdhOAgAAEwQCAAAefgA== Date: Thu, 2 Feb 2017 10:21:35 +0000 Message-ID: <5C876EB6-F2B6-4F2C-9A6B-2AC63D0115D3@netapp.com> References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: cbd9d015-3a34-4d58-65b4-08d44b55440c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1154; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1154; 7:sUdlk7cI2jQ2ysThsmfR/M89SeVLgfQIA6pdwLwWHC7oAS9GIzpfZx46z+bydLMSvMVkDWyqNlbGWzI6imjD5apQloCrKHjzpJYIqddCfHAXF1USOwGU4h9qEAGOJtqS6qV4O5n6YGgn0pGbBynIMiAxSdjEtQToRZVdfWbJ8xNmEMBksSlAOwlFwcKWaDlVyFH/CcKJiCU4ehf6vRoFraaAfRioNBernDZvndNLUFrudd0sCrVZ46qFO+2d0/qB6EWik/jy46w07mdWinieF4Tj9TFS8gRgk3jgb+2RJrkWKgFyknMAjtJiujUJv4XPZTtBgsGQY/olccwwlkUrB9QqxKZEaa1bdT02oHK3O83vZmZvspjXbyHTUDNWZPxIY5MHQcW+Lr1uXPE2Z7rOzDA+6VnKwsv//qTkprgnB7hrGMEHJWIMwhcqHNW1Fj/k58umN9Hgv2U4PxQncjkgTbSSJYC8NmUDEVtWtCmOsLstrp0gZhCiJ/Ec2cvD8wvjqxRKEnDr0IhDfzcb2PUSPA2zw5COdyQ+1KqeMhsM/jPvfIgz+oY6lw0Ako4w+k5Z x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR0601MB1154; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1154; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(199003)(377454003)(189002)(377424004)(38730400001)(57306001)(82746002)(8936002)(92566002)(83716003)(86362001)(99286003)(6512007)(8676002)(68736007)(81156014)(81166006)(6116002)(3846002)(102836003)(110136003)(2900100001)(53936002)(6916009)(3660700001)(2950100002)(4326007)(36756003)(66066001)(50226002)(106116001)(106356001)(2906002)(6436002)(77096006)(105586002)(6506006)(7736002)(99936001)(305945005)(229853002)(76176999)(5660300001)(50986999)(4001150100001)(97736004)(6486002)(101416001)(54906002)(3280700002)(33656002)(230783001)(25786008)(189998001)(122556002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1154; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_5A7DAAE9-D80A-4DE8-BA93-D9F8DA7F2946"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 10:21:35.0642 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1154 X-OriginatorOrg: netapp.com Archived-At: Cc: "ipv6@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "tsv-area@ietf.org" , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@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: Thu, 02 Feb 2017 10:22:42 -0000 --Apple-Mail=_5A7DAAE9-D80A-4DE8-BA93-D9F8DA7F2946 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-2-2, at 10:54, Fernando Gont wrote: > On 02/02/2017 06:37 AM, Eggert, Lars wrote: >> Also, even if ICMP delivery is assured, there are additional >> complications for UDP, which has been seeing a lot of interest both >> as a tunneling encapsulation and for applications (e.g., QUIC). Many >> platforms do not provide UDP-sending applications any information >> about arriving ICMP messages that were triggered by their >> transmissions. So even if the path delivers ICMP, the OS makes >> ICMP-based PMTUD for UDP often impossible. Another reason to >> recommend 4821? >=20 > Agreed... although in this case this would be more of an app-layer > implementation than one at the transport layer? There are two dimensions here, one is in kernel vs. in userspace, the = other which "layer" something is at. It used to be that "transport = layer" (or "network layer" always implied "in kernel", but those days = are past. Lars --Apple-Mail=_5A7DAAE9-D80A-4DE8-BA93-D9F8DA7F2946 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYkwgtAAoJEFS1wwm/cMFXXQAQANdGo7nbA9Cpl4jLeRtvUvPd 0vsQKxl8Co18GL6q2QvMWoNtOHatIyZ3d5/aO8b8N5FTfL1HeOSYM0SPUamp6sqh /f4ANGI6hywY0kK1DIE7QtC/oDhVQecQ9MA0J3sxWLhGqIGW2tEjgI7mHK1gAAgo SoPkBYDZ1H/IgJN27v40adV/UFVjpLcxuRFXx/7UUaZqI9QImF4g7VWpl8yDWgLu sx8JujYa7v7VfcIirewsHBWAjoj9DAY+7eZc0NHudnluyXtvEUlbk/gAqCQuxisW ZAtQBDXMAzgIDWRFTAM+2maqHoONwQtNa9KTT55M3O/uqsp6XE6/fGrmlaDKOIjo sjKo7bBoMnhBYsdzwsDom84m87B1iSrWFYeLXX4kT9I5l/cop7x0nmY8fnDUjU48 SWVvcjV8MQGXfY3v2OG7ZjuHMVMmUF1L6/ARJ5SLVT+x5YwEEMLq02n2OYtYdaHX 7kcJur56yKN3+bGf9VpRUcEDBGnJeGci/Um0GPOcnDl+pFH9sG1o6AYs056LqjQE soq3TNNonv2tCUmc18jrzdbwJoWwsDBWLWmiDKKPR2kKAUsI0b4/1cU0PiAG2aAs uIrh1XwXGMTZfGXD7t975KWjnHDGwmOlK7d+M/NcxaGozBzkDPm93Z0L6EODMXwW TGEFF/opzfmwu5VXUNFX =IHzK -----END PGP SIGNATURE----- --Apple-Mail=_5A7DAAE9-D80A-4DE8-BA93-D9F8DA7F2946-- From nobody Thu Feb 2 03:08:29 2017 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 92CBC129437; Thu, 2 Feb 2017 03:08:20 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 561yEwHHc7Wt; Thu, 2 Feb 2017 03:08:14 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4E7127076; Thu, 2 Feb 2017 03:08:14 -0800 (PST) Received: from [IPv6:2001:1291:200:42e::2] (cl-1071.udi-01.br.sixxs.net [IPv6:2001:1291:200:42e::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 36D8380A93; Thu, 2 Feb 2017 12:08:09 +0100 (CET) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: "Eggert, Lars" References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <5C876EB6-F2B6-4F2C-9A6B-2AC63D0115D3@netapp.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <4de97844-6f79-058c-e284-2b9ae79147fe@si6networks.com> Date: Thu, 2 Feb 2017 07:58:17 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <5C876EB6-F2B6-4F2C-9A6B-2AC63D0115D3@netapp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "ipv6@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "tsv-area@ietf.org" , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@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: Thu, 02 Feb 2017 11:08:20 -0000 On 02/02/2017 07:21 AM, Eggert, Lars wrote: > On 2017-2-2, at 10:54, Fernando Gont wrote: >> On 02/02/2017 06:37 AM, Eggert, Lars wrote: >>> Also, even if ICMP delivery is assured, there are additional >>> complications for UDP, which has been seeing a lot of interest >>> both as a tunneling encapsulation and for applications (e.g., >>> QUIC). Many platforms do not provide UDP-sending applications any >>> information about arriving ICMP messages that were triggered by >>> their transmissions. So even if the path delivers ICMP, the OS >>> makes ICMP-based PMTUD for UDP often impossible. Another reason >>> to recommend 4821? >> >> Agreed... although in this case this would be more of an app-layer >> implementation than one at the transport layer? > > There are two dimensions here, one is in kernel vs. in userspace, the > other which "layer" something is at. It used to be that "transport > layer" (or "network layer" always implied "in kernel", but those days > are past. I was refering to "layer" as in a reference model. i.e., PMTU assumes that you can repacketize your data. For TCP, that can be done at the transport layer, since it's byte-stream oriented. OTOH, UDP is essentially record-based... so any "re-packetization" must be done at the upper (app) layer. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 2 16:18:28 2017 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 DB5B41299DC; Thu, 2 Feb 2017 16:18:26 -0800 (PST) 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 MyQ7SYhwKxGT; Thu, 2 Feb 2017 16:18:25 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 A2EFD129A2A; Thu, 2 Feb 2017 16:18:24 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id e4so267740pfg.0; Thu, 02 Feb 2017 16:18:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=deEYrmpBvg11+JzjNRtxwV1Tsp8gPqKR4oNoJgnXoEA=; b=QYspm/+IdJmfnewoCYU3yPRcVN6etvbqMQd3yqmU6QjdJOdcS68S6fHBYgHI/f+EFF T5FAoYqFHNV0TWyhOyPYqEYX7U4XtfD4GcuT7ZaAC1U4oaO0V/Y5QSkEsDfjJ1rbg3YM qttkm8a7QLAQnEHC/qwGzs3EHJP7tMe0S8+BpQGvy1B31IsTSFw90JBy/isAWFlmZ+kg eeiSD36uPz4Yv6YL+SFTWofseuH1M8P2KjDB1MG2KRYGrjulJvJ58pwIS5D0cOPBGTv/ YVN0K/LcRGwoR5En0Tn+ZT+lp8nIBAMhONPXTViD2j8JGu+zOuqkbqYsRsT9OWZZdSbF G4Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=deEYrmpBvg11+JzjNRtxwV1Tsp8gPqKR4oNoJgnXoEA=; b=OPk7eWVaYwnsBDYoofn3GfzemG9aMG1oF89SngmCYTQBK3QHNWcKY7cCHpbmPx37XF UpwsEnQFOQVfHQ8c+t/XvVi0BH5QOG91uBBbB+wghhrtxDiAgJnBSntG3EejBLzH0MVo sCAGtLLkf50vVJ8JW0yhYZpH2ziall3UjI/byPDKwkQbND3qyBoD4AFdzZ4Py0QsdyJ+ bC/lfrzBED28n3ndghB7+cx4E8b0IQR9W/Oq5BI+JiNXhfX66aNoU7mfU+wb3gsTI6lf bHh67g2/bbMGxm90ufaXTojkEHnX5TpE8bh1CsHWUrXb6fdmoIhzuBvfQP1L7P+l/Rsw fXdg== X-Gm-Message-State: AIkVDXIyOlk57oSEBbBVCxcTESvvEhZvyARlyi7oXEjXzffH0sUwbXdEuyTxXksVjjjZDw== X-Received: by 10.99.127.71 with SMTP id p7mr14096551pgn.125.1486081104103; Thu, 02 Feb 2017 16:18:24 -0800 (PST) Received: from ?IPv6:2406:e007:7909:1:28cc:dc4c:9703:6781? ([2406:e007:7909:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p6sm61393109pfg.6.2017.02.02.16.18.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 16:18:23 -0800 (PST) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: Fernando Gont , "Eggert, Lars" , "ietf@ietf.org" References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> Date: Fri, 3 Feb 2017 13:18:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsv-area@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "ipv6@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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, 03 Feb 2017 00:18:27 -0000 On 02/02/2017 22:54, Fernando Gont wrote: > Hi, Lars, > > On 02/02/2017 06:37 AM, Eggert, Lars wrote: >> Hi, >> >> the last paragraph of the introduction reads: >> >> An extension to Path MTU Discovery defined in this document can be >> found in [RFC4821]. It defines a method for Packetization Layer >> Path MTU Discovery (PLPMTUD) designed for use over paths where >> delivery of ICMP messages to a host is not assured. >> >> Given that ICMP delivery cannot be assured over the vast majority of >> paths in the current Internet, should this document make a >> recommendation to implement RFC4821? > > I think that RFC4821 should be recommended, at least for dealing with > ICMP blackholes (i.e., use ICMP if you can, but be able to deal with > scenarios in which you don't receive them). Many people think that, but this draft is constrained by the rules in RFC6410 about "high degree of technical maturity" and "widespread deployment" in the move from PS to Standard. Adding new stuff is not supposed to happen. If I recall correctly, the WG tuned the language to its present state for that reason. Brian From nobody Fri Feb 3 00:15:35 2017 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 BA93E12951F; Fri, 3 Feb 2017 00:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.12 X-Spam-Level: X-Spam-Status: No, score=-10.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.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 PUfTHXHKEL4H; Fri, 3 Feb 2017 00:15:23 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C65129BCA; Fri, 3 Feb 2017 00:15:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,328,1477983600"; d="asc'?scan'208";a="174621007" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx144-out.netapp.com with ESMTP; 03 Feb 2017 00:06:38 -0800 Received: from VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Feb 2017 00:14:09 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Fri, 3 Feb 2017 00:14:09 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+Pyb76B1ZcbLhc8hMAqGA8FyaL35bgZ40dKO/rW3HNo=; b=gcjkSQDp02y2zliwgG1zEqJcMPLE0X5WvYYbr0CfdFSlPew6puR4P4UYk6Lg1PKd6NAs8Sc6EFRQEmOh80DNLjraMADvFFjG07an/127QCm2t1yVLub0Mzm+dgNGCRUNHfhnm3XMcf2HqeIh9GSYnN3FfwQqsfpydklSL83Kgvg= Received: from BY1PR0601MB1158.namprd06.prod.outlook.com (10.160.196.21) by BY1PR0601MB1158.namprd06.prod.outlook.com (10.160.196.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Fri, 3 Feb 2017 08:14:07 +0000 Received: from BY1PR0601MB1158.namprd06.prod.outlook.com ([10.160.196.21]) by BY1PR0601MB1158.namprd06.prod.outlook.com ([10.160.196.21]) with mapi id 15.01.0803.024; Fri, 3 Feb 2017 08:14:07 +0000 From: "Eggert, Lars" To: Brian E Carpenter Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Topic: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Index: AQHSfOZWQnyqff8qTkSuzK39n1gXQaFVdhOAgAAEwQCAAPFzgIAAhOSA Date: Fri, 3 Feb 2017 08:14:06 +0000 Message-ID: References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> In-Reply-To: <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: 9a568e16-a1ef-4fd7-5a66-08d44c0c9fee x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY1PR0601MB1158; x-microsoft-exchange-diagnostics: 1; BY1PR0601MB1158; 7:oD6OfqHldt4waZmxFAqYvq0EjP1P9IvRA/qNGIy/BEbYuxCSdgzKedIL1YWigDSl1PKMzYZNuBhAcJ106poMKl321M2a4vEmX7DZdaZr7uOkZ6ixf/ZoSontGr8EULBjrtgWWme6DYneQ+uuEpyk6UnDIdemVYZsSiwWs4QHq11kf/DvAdCMynO7SPgu8NMYQhvIHk4Fd7yrnxUIVnkQgnbgKf+jLQ/wUKA902DGMrqkxaoy3OIV/QZ8uHxcb7DNX/A3VyNL0ZPT28YgT+NZVxaxd/ORBal53SLuLJe1Jm+/U1U1T+mzGO927woplK01EbGzy0Hstn9Hu3MZg7rGu35C8SWkshVazuIIencMYHSUmPQ0uP46Cstmy+l1e0mKmy6QMPcpx2msDSiwXhRSwbDs02HVnfb+Hn2vdi1EwI9obvfIo3Tnu/NGsWwEc3oe x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:BY1PR0601MB1158; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0601MB1158; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(377454003)(51444003)(377424004)(189002)(24454002)(2906002)(93886004)(68736007)(39060400001)(81156014)(83716003)(3280700002)(230783001)(102836003)(3846002)(99286003)(2950100002)(54906002)(6116002)(4326007)(6916009)(3660700001)(189998001)(122556002)(6512007)(106356001)(82746002)(2900100001)(33656002)(8936002)(76176999)(50226002)(5660300001)(97736004)(53936002)(8676002)(110136003)(305945005)(106116001)(53546003)(105586002)(6506006)(4001150100001)(57306001)(77096006)(38730400001)(6436002)(25786008)(6486002)(50986999)(6246003)(86362001)(7736002)(36756003)(101416001)(66066001)(92566002)(229853002)(81166006)(99936001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0601MB1158; H:BY1PR0601MB1158.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_5514083F-9D93-4A1A-98AB-F9B33976BD89"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 08:14:06.9942 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0601MB1158 X-OriginatorOrg: netapp.com Archived-At: Cc: "ipv6@ietf.org" , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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, 03 Feb 2017 08:15:25 -0000 --Apple-Mail=_5514083F-9D93-4A1A-98AB-F9B33976BD89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-2-3, at 1:18, Brian E Carpenter = wrote: > On 02/02/2017 22:54, Fernando Gont wrote: >> On 02/02/2017 06:37 AM, Eggert, Lars wrote: >>> Given that ICMP delivery cannot be assured over the vast majority of >>> paths in the current Internet, should this document make a >>> recommendation to implement RFC4821? >>=20 >> I think that RFC4821 should be recommended, at least for dealing with >> ICMP blackholes (i.e., use ICMP if you can, but be able to deal with >> scenarios in which you don't receive them). >=20 > Many people think that, but this draft is constrained by the rules in > RFC6410 about "high degree of technical maturity" and "widespread > deployment" in the move from PS to Standard. Adding new stuff is not > supposed to happen. If I recall correctly, the WG tuned the language > to its present state for that reason. So in that case IMO the WG has made the wrong decision by trying to take = this to Standard. A rev at PS that had brought the content up-to-date = with regards to Internet reality would have been the better choice. Lars --Apple-Mail=_5514083F-9D93-4A1A-98AB-F9B33976BD89 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYlDvNAAoJEFS1wwm/cMFXFzUP/idvOMoAA5yAbjNqQzbfzLCD txIs/qhNvQbTgioiQFLTIj9Hggu3o/oxiVEbcx6YK54iv7BJDPVz8IzfGV7qWzo8 gQmPhj2kh/5fL68mE32HkcUUhpduSmYkQIFcJNv2DZWuepWAMjP/nylnwY7cTkxR lshHKl8iHal2vYFKmXsb2ZeivPuP/aTPSFxoE3VUX8Ui7Dp0AuJYot+fV6/LUqgG S+8mrELdUkb+xqXx6MDYhZxsBgQnlwLfnH4LhZ8LvX5oQYNOKCx2N8q6c50kD8Hl 6cgRy8jyQhZc/FiGw60RE5Zhz1ISvFflbrrNc9NhHHwGPwFAgTn960rK0YUy4sSr 8+eh67sbxJQOviW3wwh33sTTKKOYaw5ACLFPOV8n1D7f74VGUTvd1UV67BKSCWHB Adhqf6f0B0mZ7MMgqKDG1Y9rR+SBWbAKM7AnIaHfTlF5LPe2qVFGMXmIT6CJjxu2 kQOXnvwPqSRA7+sossl63ApisUqLzVl233d6onrI0XkzxkARO5kSTiT2jET8/XAd kJfBxJptZEG2qy7UvMn9Bc19bSIhelAGUIOwkyQeOck1Hen3CnBO3M/7VzxtL36k vZp9cyJSusffP/o7tMksm0gd9OEOLV9kPraxI5mDnN/85lpjP94NbAg/kkit67dv /ut9mIUX0JyYyzJ/SVy6 =Rs4m -----END PGP SIGNATURE----- --Apple-Mail=_5514083F-9D93-4A1A-98AB-F9B33976BD89-- From nobody Fri Feb 3 00:38:40 2017 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 77235129BC7; Fri, 3 Feb 2017 00:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 GTb_jWvSSAAw; Fri, 3 Feb 2017 00:38:33 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1BF129614; Fri, 3 Feb 2017 00:38:32 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 03 Feb 2017 08:38:31 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id D111ED788B; Fri, 3 Feb 2017 00:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=6hnT1XCnzUhWYmVCYMLIX9AdQqs=; b= Tuu954lgKMXR9uEx6JwNUEw1x4G/nbGupietXI5MeNraeHKjvKZSJLeyWM34JUOM tfeD61p5oFNN+rKf1QzhLTmvOgwcYFBx8Us8THm0zhOkjIfbK6YkUx9Desu4pzZs 9gbvkAkss39cbQmkeqlVF98oPbiM7dYJwdFGAHAkvZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=nvtjr1OlaQAFXcR4DQMQHXW whQLYLdFlLyxYLYwXW+XP3r0Q3EtRsrGfynHuUsJ40bIaGQaeauAOAreMe19cq+P 1ExOATajSFFtzCmsemH9sOFuaYI4woDGd//4r3TCnqIEQ1ia/oinXgfJkCQjWgeG gWOiMvt1rxL5lsNjEupE= Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 9719CD788A; Fri, 3 Feb 2017 00:38:30 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id B3D42835CCD3; Fri, 3 Feb 2017 09:38:28 +0100 (CET) From: otroan@employees.org Message-Id: <014D8A7C-449E-4849-9F49-990FF8B39DEF@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_EF4ACE04-CDB3-4D4A-92A5-DCA87BE891AC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Date: Fri, 3 Feb 2017 09:38:28 +0100 In-Reply-To: <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> To: "Eggert, Lars" References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "tsv-area@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , 6man WG , "ietf@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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, 03 Feb 2017 08:38:34 -0000 --Apple-Mail=_EF4ACE04-CDB3-4D4A-92A5-DCA87BE891AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Lars, > the last paragraph of the introduction reads: >=20 > An extension to Path MTU Discovery defined in this document can be > found in [RFC4821]. It defines a method for Packetization Layer = Path > MTU Discovery (PLPMTUD) designed for use over paths where delivery = of > ICMP messages to a host is not assured. >=20 > Given that ICMP delivery cannot be assured over the vast majority of = paths in the current Internet, should this document make a = recommendation to implement RFC4821? Could you please substantiate that assertion? Best regards, Ole --Apple-Mail=_EF4ACE04-CDB3-4D4A-92A5-DCA87BE891AC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYlEGEAAoJEL7aWKiYQt92HzMP/iJveKUbRBcw+AcC2fvG9odD Mimh5vMjNTV+9+ffwK+kx2QBPbsByUtaQ8W5tp5Eiogc/ZiJUeFCW5JHIL+23b55 xfZP4YGBgiU1UD2clNw3CRGk+W8bDpe/Ip12mvMiYLc7vBrzZD/0Fe/G3LivLv8M jDmbFKL1pzq6MXhdz5l3h8MLN1ARJrSro3U/SNvpA7CXr5KwmaKDx3/m8ClyTH5E E1QUyHQslsZ0XhV7m98E34UDaAtLvL80FyX7yaBrmhP19J3ycbwS9KxIFMLUc0DT 8zZgTCHvCWWok95IWmbpRPgRJEeso9JdDTv6DwOLTXWHZoFso5vmODcuU12sGlQU W8chUcrPpsTZH6D4PM6X/XhvYCAi5Lb67js08lznNfyHru8S33JnGqp9eP1QjAem 5OuLFjqGoJ6YpgXQ5nFAZnrbefqvPd3ANLgDyoNs6nB5S16wDfnRoRwIflunP8Gl B9ehrFA1uDyUSdRAenLZseBnMCOeL42+Ha78lZBGDnzeXlHU96qWL4fFvMGcBwPd 9yyB0m8QAwZFbPe25MZacP4tF0nDnyTCtX83Y7KfAbzhnS+7OGEtoa8/9y1Ln5WA C8bknOGfUGBSYmCsXuFMudHYuQDGz/B95Jx/DKZ4Slg6Z0NnXTCH95q4pEjmLRfU lLVvryLXe4V7yVbPIbuv =CpOC -----END PGP SIGNATURE----- --Apple-Mail=_EF4ACE04-CDB3-4D4A-92A5-DCA87BE891AC-- From nobody Fri Feb 3 02:23:04 2017 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 5A563129B8A; Fri, 3 Feb 2017 02:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.119 X-Spam-Level: X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.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 TJpY0cRuWuue; Fri, 3 Feb 2017 02:22:52 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23693129A82; Fri, 3 Feb 2017 02:22:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,328,1477983600"; d="asc'?scan'208";a="169079977" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx142-out.netapp.com with ESMTP; 03 Feb 2017 02:15:00 -0800 Received: from VMWEXCCAS09-PRD.hq.netapp.com (10.122.105.27) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Feb 2017 02:21:47 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS09-PRD.hq.netapp.com (10.122.105.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Fri, 3 Feb 2017 02:21:47 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DXl8b6Gck+R+sbZRn+o3X1bIPoogSTz1S9nZvbrqjNU=; b=HrzuxIlwxiaVhNYtbS5FYBTJXevhp7sY4oFogv342HdlUD1qYmc9WO5T9GawDfwNyWUh0VFzL7e+3ttwH5tp5DXH7MKaojXC1lMDlAu0nnraIvsscbIIG00dslDe00ayxeOy+qX9V8qHqKyCMIvjl7LYNl44LcpAIrzipc7eAxc= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Fri, 3 Feb 2017 10:21:47 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0874.025; Fri, 3 Feb 2017 10:21:47 +0000 From: "Eggert, Lars" To: "otroan@employees.org" Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Topic: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Index: AQHSfOZWQnyqff8qTkSuzK39n1gXQaFVdhOAgAGB6ACAABzbgA== Date: Fri, 3 Feb 2017 10:21:47 +0000 Message-ID: <88A7C2AD-8D33-4AFF-8AF4-A1B8718C47BD@netapp.com> References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <014D8A7C-449E-4849-9F49-990FF8B39DEF@employees.org> In-Reply-To: <014D8A7C-449E-4849-9F49-990FF8B39DEF@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: 5486baec-7d8c-4d15-767e-08d44c1e75a9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1153; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1153; 7:d5ywUeIGYbov9lCXABrLXiUdUbjpoWxSP57m7RNmfxL0IUghZZvgxSAnTB6jCDaJZrDDwj+oPo9/rvknLdI9kMaG0tum33pNMgK1DUM3K3xLYAT1bErB2WGQQrFJUyiCbR+/l06cM7Isj/7+1bMCk1QJD52L07/Gj8zYNsSMUXwsNTs2S/Yj2wwSTvLKK8FghN7vGdDFe6oGAlFBfA8hIMuYx+PP+hHpDLSPJMQ0Ce7X0mvBnJhA72tzcNh9jZuvnoOC085audKT+XH7FyHd0JFFwafMByJZ0D04/RI1yCNJWAXWZ9HPE8L0Gh5g6XxsLj3Mw1SCt/LHLBKNde/jyeTm241pLWKXuyqPuGiVOL0WQhmwLxT0scMbxHAsoU8Cq/uqRii9N2fF7zzUsDuxTMflohYR0GFWrmBM2YOxSFEucr8t3wZIuY1B6wCOfZZzFoSC0rwUIL2PXnLj3GLPWfnGAqgFvTSo9xcRJMcZVybWgd5rgv9qRzxXLfhLTpIGMnOoZYdnF5FfwN654DI1JA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(76576733993138)(165104125076784); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0601MB1153; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1153; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377424004)(199003)(24454002)(189002)(83716003)(53936002)(6512007)(92566002)(3660700001)(6506006)(229853002)(99286003)(2351001)(4326007)(6246003)(3846002)(106116001)(105586002)(6306002)(106356001)(82746002)(2501003)(66066001)(122556002)(54906002)(53546003)(86362001)(102836003)(6116002)(230783001)(33656002)(57306001)(5660300001)(110136003)(99936001)(38730400001)(2900100001)(2906002)(68736007)(8676002)(6916009)(2950100002)(5640700003)(81156014)(81166006)(1730700003)(6436002)(50986999)(76176999)(25786008)(4001150100001)(8936002)(305945005)(7736002)(77096006)(101416001)(6486002)(97736004)(36756003)(50226002)(3280700002)(189998001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1153; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_86CC7C58-C35D-42AF-9A24-173113CEEEE6"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 10:21:47.0352 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1153 X-OriginatorOrg: netapp.com Archived-At: Cc: "tsv-area@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , 6man WG , "ietf@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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, 03 Feb 2017 10:22:53 -0000 --Apple-Mail=_86CC7C58-C35D-42AF-9A24-173113CEEEE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-2-3, at 9:38, otroan@employees.org wrote: >> Given that ICMP delivery cannot be assured over the vast majority of = paths in the current Internet, should this document make a = recommendation to implement RFC4821? >=20 > Could you please substantiate that assertion? Matthew Luckie and Ben Stasiewicz. 2010. Measuring path MTU discovery = behaviour. In Proceedings of the 10th ACM SIGCOMM conference on Internet = measurement (IMC '10). ACM, New York, NY, USA, 102-108. = DOI=3Dhttp://dx.doi.org/10.1145/1879141.1879155 PDF here: https://www.caida.org/~mjl/pubs/measuring-pmtud.pdf "This paper measures PMTUD behaviour for 50,000 popular websites and finds the failure rate in IPv4 is much less than previous studies. We measure the overall failure rate between 5% and 18%, depending on the MTU of the constraining link." 5-18% is pretty bad. I would expect that the widespread deployment of = CGNs since this was published in 2010 to not have improved things. Lars --Apple-Mail=_86CC7C58-C35D-42AF-9A24-173113CEEEE6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYlFm5AAoJEFS1wwm/cMFXyYgP/0dugje7dbWNU6VoN2PgVpA2 Jhb9P03D2xNwoyzg/KAzLeIzqIE4nn5JyTLUCRV+tD2vmF9TnqD4VKlmt7yZNg5r yIXMrJn8D/nPa10rw2mSdEjvWMok1hGo55TyDWtpByGMFuCnM95aXDih3F+4M2Pn YEH4CE9Lqpj9a8zmxu3b7noQeeDYbFXrv8uLT8hphOJWVAX2Mmm7KKaR0CZtyO/V N1upn6/TOwPjlu49zkyfpEpLUlBdwwzb8wqmsLSvKdLKDIZTicIwkjL5Vu+1Uqbx uDcMXHrSQSgss9psitk1435DiG01nUXNnsEnne4c/kAMDWdj5Ihtc2R2uROst4C9 krMSSqJymCgRVVHdp2f32IEIddJw5vHdVwMWIXEb7l/8AVaGpzQW7QYHTSaz63Gl oZ1rvQcmoO3mRZDpyUhwEaSyez93Hddt3WhkILncOePAl9n9uksk0p3wklSiFuhC mewa7bu7PzDMIhTSWFfHi+6IsIL/UfHhohCb93ZrvHtywNtAt4o+Zu0kWRC0qZU6 owTaHj6CNCn5YR4t71BJlNHYu5d1mIiLxY3SNLrZKpcL2U+SzRWIhc+tJfPLT2uF /CQ40iyKuVprbuZNSkZjBgiT4/D12FbxUQcvaIhcXrxN38MW8XQbDyV+Qg2dWBaH 4v4ohI2mDam4yhjQULYW =QGz6 -----END PGP SIGNATURE----- --Apple-Mail=_86CC7C58-C35D-42AF-9A24-173113CEEEE6-- From nobody Fri Feb 3 02:23:18 2017 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 34C01129BEE; Fri, 3 Feb 2017 02:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.119 X-Spam-Level: X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.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 fw3zO6OLsBbg; Fri, 3 Feb 2017 02:23:04 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B190129BE7; Fri, 3 Feb 2017 02:23:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,328,1477983600"; d="asc'?scan'208";a="174636846" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx144-out.netapp.com with ESMTP; 03 Feb 2017 02:15:12 -0800 Received: from VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Feb 2017 02:22:44 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Fri, 3 Feb 2017 02:22:44 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hs5BSrAlhJ1Fh6YOCA8j/L9Dn+ivCDgf8ng05DgAa3o=; b=ayl9F46HfjiemYc4LOozdUbGRhIBIXu0rk1s5uYmfSKtIPR3REdLeCoUxSr4T3DlsRIAf6qBM/9pE5JLrQoDhXD+5ianOPdaQOZr65pSsHrm/IyVgM1tz70fUjtAT3gvbHEqEOjXh3VaTez/OHUDT/uk+MbkWAunv7mV0a+gzLw= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Fri, 3 Feb 2017 10:22:43 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0874.025; Fri, 3 Feb 2017 10:22:43 +0000 From: "Eggert, Lars" To: "otroan@employees.org" Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Topic: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Index: AQHSfOZWQnyqff8qTkSuzK39n1gXQaFVdhOAgAGB6ACAABzbgIAAAEOA Date: Fri, 3 Feb 2017 10:22:42 +0000 Message-ID: <1C5B54BD-1D6D-46F6-81A7-89ADF9A72792@netapp.com> References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <014D8A7C-449E-4849-9F49-990FF8B39DEF@employees.org> <88A7C2AD-8D33-4AFF-8AF4-A1B8718C47BD@netapp.com> In-Reply-To: <88A7C2AD-8D33-4AFF-8AF4-A1B8718C47BD@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: 630f737f-5cee-4cb5-684a-08d44c1e96e4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1153; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1153; 7:ex6Vqx5hfuTo4bJ8ThiAyXdFiMe9grT0wZz6VUQWfSozWdMBWKgWjNvnBeBN4xRWCFqA7dbiE3vRfWXZGTWOSygBMwH8KAvOwWWBGXa4c+JQMjtwZme3k7DuyAIAJC4tDsNC+pYyMPof0xQbBqdZ25ZEL7+6ZhCQ8zq3jJ089MeGN970fMoSAr/a6J1d1wNWKpThHwfTk2jAny20k/gcPVaLkGkzffraNTwTKt0mQcrQ/F2csCPXN/ilCnojk6++nPCYoPxkHia+q5nlP54mInrP5lrJZNovTB/XwQjML5SjIUSLipFuvaqRJfpc9B+cOuZKW1a70xEi2w1xcZXW0MjSpqW1XgeyagHzW+LJiLih3Zf0oQEHjy44eggyCm9Mki8w4pFrhXsDIbIHJhGCim34EcJU473dXC4DnzPBoKdahncy27jwebEWU9hbSz/YF54bL4qq6ZmWW1vCuF5e2Cw0wECVMuAAvdj64DdlCe3U7wssFbkrdQYeYPIkY+o3imlgbfNCWLrhVVDNTu3jIA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0601MB1153; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1153; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377424004)(199003)(24454002)(189002)(83716003)(53936002)(6512007)(92566002)(3660700001)(6506006)(229853002)(99286003)(2351001)(4326007)(6246003)(3846002)(106116001)(105586002)(6306002)(106356001)(82746002)(2501003)(66066001)(122556002)(54906002)(53546003)(86362001)(102836003)(6116002)(230783001)(33656002)(57306001)(5660300001)(110136003)(99936001)(38730400001)(2900100001)(2906002)(93886004)(68736007)(8676002)(6916009)(2950100002)(5640700003)(81156014)(81166006)(1730700003)(6436002)(50986999)(76176999)(25786008)(4001150100001)(8936002)(305945005)(7736002)(77096006)(101416001)(6486002)(97736004)(36756003)(50226002)(3280700002)(189998001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1153; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_0F11CB5B-7BFC-405D-9EC7-C492084588F2"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 10:22:42.7551 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1153 X-OriginatorOrg: netapp.com Archived-At: Cc: "tsv-area@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , 6man WG , "ietf@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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, 03 Feb 2017 10:23:08 -0000 --Apple-Mail=_0F11CB5B-7BFC-405D-9EC7-C492084588F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-2-3, at 11:21, Lars Eggert wrote: > PDF here: https://www.caida.org/~mjl/pubs/measuring-pmtud.pdf >=20 > "This paper measures PMTUD behaviour for > 50,000 popular websites and finds the failure rate in IPv4 > is much less than previous studies. We measure the overall > failure rate between 5% and 18%, depending on the MTU of > the constraining link." >=20 > 5-18% is pretty bad. I would expect that the widespread deployment of = CGNs since this was published in 2010 to not have improved things. And yeah, this is for v4. I'm not aware of v6 measurements in this = space. Lars --Apple-Mail=_0F11CB5B-7BFC-405D-9EC7-C492084588F2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYlFnxAAoJEFS1wwm/cMFXz+cP/3ebOct1xO/ceSGPEaCdrMov 1H3IUW85gZuTuTL4k3vxQ77eP28lIqsoVYKuXfZBqaASnh0OW3D5MJVn86WAMg68 0oHs2wvn5A2Cmgjjvk2QllcFHcNHhEv0/k5ALTJS12OGGTFprKuCEDc7Eisr2T1q GCDDssTKE3DXRvY4fSArFFP/ZzjeD/oqmMHpzQQyzTXHNbXnLEQ1K+DsZVpE5noE D3UikxsKbgf6Ak9y4GFGFcWL5//Fxo+wg9vvdcfxLiC5s5LgvkvpmSYtY5Y7C5Ja XurjuZhkJlrKNPQanuxY5WTopw1rTbggRxTcdDsLMI4b2eMgjeZDz8K1RZu4/FAn 1d/FCq/GWFDXJ3/oWW86TzFXqrFEevTecobdA961F6bhmoexObk7ezjmLWl7zxXG FqAgIwRRN5P9DlD5pv9FCEWXgLFvHAF5x7Ne4NZKR1BOXD+gv6eE8mrqvvAMpCjJ 7a3Pt/8mEiAxcx5npWLMtZvwZ8X7SvNYIXMC+KVFBL1pS0Yw22oDzFfnLYQJmXEa k40FIbE2vYuJRsZ0hI48nvrjEi254t7xtqC5U02XZm81vdx3/udw421x5HxgAQiq 1gwh8alTI3jzLfGJHyBPj3G0tRTxqfRLQtuybgU+kk/SQWoyuSw0Juc7Tx3wH9aY jY085og/lP/QQ90/0iYu =BElZ -----END PGP SIGNATURE----- --Apple-Mail=_0F11CB5B-7BFC-405D-9EC7-C492084588F2-- From nobody Fri Feb 3 02:28:47 2017 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 A1215129BCB; Fri, 3 Feb 2017 02:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.119 X-Spam-Level: X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.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 uAOPZMXSXVkd; Fri, 3 Feb 2017 02:28:37 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454A1129B4E; Fri, 3 Feb 2017 02:28:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,328,1477983600"; d="asc'?scan'208";a="174637276" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx144-out.netapp.com with ESMTP; 03 Feb 2017 02:20:45 -0800 Received: from VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Feb 2017 02:28:17 -0800 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Fri, 3 Feb 2017 02:28:17 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=acII5BzO/Bhc0B5v3+8ZXL4+rLVdT+JLIj1VCcGeN5w=; b=a6xHUUXQUU6X+9nwra4vBx1W0pN74j9XQwkh/ZvI7In/VNOwOF2Un4SB2fYuTh///O92nkwsPpWtfhxpIa9nFYvmXfnSvXCR1GdVRJGypPPyFra/UFoi7YFr8xTZi5R63rd+TiAvDGMpkRIuGqLyGGctHVMXNLSkfTt+4Er0Z4g= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Fri, 3 Feb 2017 10:28:16 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0874.025; Fri, 3 Feb 2017 10:28:16 +0000 From: "Eggert, Lars" To: "otroan@employees.org" Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Topic: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Index: AQHSfOZWQnyqff8qTkSuzK39n1gXQaFVdhOAgAGB6ACAABzbgIAAAEOAgAABjoA= Date: Fri, 3 Feb 2017 10:28:16 +0000 Message-ID: <4D3921DF-F2E3-4021-8F0F-B389B5DA0371@netapp.com> References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <014D8A7C-449E-4849-9F49-990FF8B39DEF@employees.org> <88A7C2AD-8D33-4AFF-8AF4-A1B8718C47BD@netapp.com> <1C5B54BD-1D6D-46F6-81A7-89ADF9A72792@netapp.com> In-Reply-To: <1C5B54BD-1D6D-46F6-81A7-89ADF9A72792@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: ece50729-4dd1-4eb0-de78-08d44c1f5daf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1153; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1153; 7:97f67ZdM71+oYz9h9L+ZYWi/ayBYKTCR1JPKOxD3KOuEo8V2Kxkg7vdf4r5WHpYp3yQGmHR01IqAz4UMVhEnTNdUFg5sHD6pFAJzBIU1VmGiGhku61bgvE8YDXCaL1UTxhVNhhjux5aRcaMXat33rG9c2GADxpa8gbpj/zwK2AhZcOhdflPSqw3Zngz/GMUmdXJTi395TX88HsGYKcC9vmrRxssI9wjC20+nm23H7YQ3j/i1Ki2wXEj63y51cjQtswEknJiOd3rxIueMWHdA0xzFGOYa6U8JdqBEF6DbYAGxt2O6FGOv6cFmjKXje5MiRVotmdD+nNpKoEWmXbIL/GCUKzfwDdBHC/ONIbigMjGEk/8jcRW9Hsdcn4ZlQFsTPk8lsmTbfacUt9BtLz4ow2D+TyhVhAiAukORN/7fkBdyU4Wds7lvXHXp9QPUmrl2Ts2mTGjFQwLcqQTsmCdz23rKiU02blgedqqd+Rc/GfsZpVj0gfsPd0iQ7kjv5F1PbdmWKR+F3MIQNl4m3hjP5A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0601MB1153; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1153; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(377424004)(199003)(24454002)(2950100002)(6916009)(8676002)(5640700003)(93886004)(68736007)(6436002)(50986999)(76176999)(25786008)(81156014)(81166006)(1730700003)(5660300001)(110136003)(99936001)(558084003)(230783001)(57306001)(33656002)(2906002)(38730400001)(2900100001)(97736004)(50226002)(36756003)(3280700002)(189998001)(4001150100001)(8936002)(77096006)(6486002)(101416001)(305945005)(7736002)(92566002)(93376004)(6506006)(229853002)(3660700001)(83716003)(6512007)(53936002)(122556002)(966004)(66066001)(102836003)(6116002)(86362001)(54906002)(53546003)(6246003)(3846002)(2351001)(99286003)(4326007)(2501003)(105586002)(6306002)(106116001)(106356001)(82746002)(104396002)(15302535012); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1153; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_4898182E-AFB2-4AB7-99E3-2021193162C3"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 10:28:16.2930 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1153 X-OriginatorOrg: netapp.com Archived-At: Cc: 6man WG , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "tsv-area@ietf.org" , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@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, 03 Feb 2017 10:28:38 -0000 --Apple-Mail=_4898182E-AFB2-4AB7-99E3-2021193162C3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2017-2-3, at 11:22, Eggert, Lars wrote: > I'm not aware of v6 measurements in this space. But Google is: http://tma.ifip.org/2016/papers/tma2016-final51.pdf Lars --Apple-Mail=_4898182E-AFB2-4AB7-99E3-2021193162C3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYlFs/AAoJEFS1wwm/cMFXoLUP/3Hzy8bx3z3pKTduuV0eLZCS OnHQqFoh5B3JySgdwiep/B/2Q1kFi06WNjdpOo0BeAeVNUZHtWfi8Z2nkzISvuJq Z8mrZtpNd16HJs2I90dmxwC4mvpKel4PoOC/Frz3EVeRppltU1yQZku0ymfl51Eg AkevDGCakiz9/PHjn6YzD61BN62dHuWdsj40spw4x6VfNoi8CGCLfMrWbfzZKn0T SwziwEUSY0YB404dALt0t8JZ2MkKE3do7ippsYrK94DBjfvxZLun7x3EQbTgJD+l 2vGFHTOIIM8Xv7nZxPph8i7Uc4s41GDhUrtely6BEQ8hA5IuNxBwRL0E3zJYFoTC izqmV+SxWBPHmikVmjvvKQbu0KwaJ3i3nk4KzIsiKpFhf7z1DBOZzftySRuEgXy5 hst1YRc1tuKmaP2Uuw2PgR1ddpCGojLY8YhMxPqltmT7Pw3IniRIeQMyW5aYdOtO +R1TKmSHQSVdl8jGCtec0iXfyegPuD1cO/3wGMqVku5GMfYUxFgrMSuKGK/GZN4d 7PwtwRFWXI42sncVA08dGN2PSB4QlSBjTSwAk5KItfWFFLYLMunyTSwe1yBNKHnB igXcVUoxUffqCPt3CQleXiEjj8eEzmuMVvKMy7iteWpRRgQbCDVDwdMk8HJLKg1G ZaXAc0p2hO1YIpF/igFl =3T6c -----END PGP SIGNATURE----- --Apple-Mail=_4898182E-AFB2-4AB7-99E3-2021193162C3-- From nobody Fri Feb 3 02:52:30 2017 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 6A321129BCD; Fri, 3 Feb 2017 02:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 0dvGlmsEynT6; Fri, 3 Feb 2017 02:52:20 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id D65B4127078; Fri, 3 Feb 2017 02:52:20 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 03 Feb 2017 10:52:20 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id BCFD6D788B; Fri, 3 Feb 2017 02:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=WLVTZzl/UkBVNerehzLjeLcHc7o=; b= DbbN4pv/PAvLVFY2CjteBhREqnGIV66LrVvyE5Rce4BguVsJmlj5mCq0sqsG9mh3 VB94YDmYpg2DS+sslf44KW6oWCRag9PIegYYWnh79nBqiUX35tNuJu3wr9PLokZs Bvve6mkmwHCM9yeqA5OXggWtbAHbzBsax3tLz6BaRT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=RRykAQr/3+d/+k5Q8+jIpIn 75I5fGGuIsaYkBaAOE1j4EWNWnbGCw7WdUqXnWj62Z1NlaVrSlyWOnAW28DAk/a0 M3ONQCemQBdgzjXEPG6TGiejq9UhjkUtzyAUNFxvcLC89NVyJ1Iw6H5xGMeNBDhk B+qryWfiygFAdHgxvcqI= Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 3DE44D788A; Fri, 3 Feb 2017 02:52:19 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8CC538384171; Fri, 3 Feb 2017 11:52:15 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_094FAC1C-73B5-4845-A68C-D88D0438C1AD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Date: Fri, 3 Feb 2017 11:52:14 +0100 In-Reply-To: <88A7C2AD-8D33-4AFF-8AF4-A1B8718C47BD@netapp.com> To: "Eggert, Lars" References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <014D8A7C-449E-4849-9F49-990FF8B39DEF@employees.org> <88A7C2AD-8D33-4AFF-8AF4-A1B8718C47BD@netapp.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "tsv-area@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , 6man WG , "ietf@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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, 03 Feb 2017 10:52:22 -0000 --Apple-Mail=_094FAC1C-73B5-4845-A68C-D88D0438C1AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Lars, > Matthew Luckie and Ben Stasiewicz. 2010. Measuring path MTU discovery = behaviour. In Proceedings of the 10th ACM SIGCOMM conference on Internet = measurement (IMC '10). ACM, New York, NY, USA, 102-108. = DOI=3Dhttp://dx.doi.org/10.1145/1879141.1879155 >=20 > PDF here: https://www.caida.org/~mjl/pubs/measuring-pmtud.pdf >=20 > "This paper measures PMTUD behaviour for > 50,000 popular websites and finds the failure rate in IPv4 > is much less than previous studies. We measure the overall > failure rate between 5% and 18%, depending on the MTU of > the constraining link." >=20 > 5-18% is pretty bad. I would expect that the widespread deployment of = CGNs since this was published in 2010 to not have improved things. Emilie also did some work on this: https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters If you took this argument to it's extreme logical conclusion, wouldn't = you then just state that the only thing that works in the Internet is = TCP port 443 and UDP port 53? I'm not sure how much sense it makes to let broken middlebox behaviour = steer standardisation. 1981 is proven to work well. If a network operator has chosen to pull = the plug on ICMP then there really isn't much IETF can do about that. PLMTUD is better, and it is even better combined with PMTUD. But PLMTUD = isn't deployed everywhere, nor used for UDP etc.. I don't see how that has any bearing on making 1981 an Internet = standard. I would really encourage more work on the Path MTU discovery problem = though. Possibly combined with removing fragmentation from the IP layer. = But that's far outside of the context of taking 1981 to Internet = standard. Best regards, Ole --Apple-Mail=_094FAC1C-73B5-4845-A68C-D88D0438C1AD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYlGDfAAoJEL7aWKiYQt925lQP/0CAD4kVfR4yefFZ54jQrtuY 0U7tN1Gyo3HW2V1djQHFhpynv8vEWEsu43lIlq+nPcmwl+6SzYcAMzg8G8mla90a dz1avA8bsrNErRc8OATg6gm+pmzEuK7ahILQhAQWBSUqQ9WQtoTv5Mr0KQdh0sIE QURTzqvfFiTCGrsBNQtKvgdeh8hFJ1BaTTp9dIC8/ccUmgHA+UuhlfmGQPyp2LMJ laMw6YhKB1m5zSM1Hl81c7CxaCBbzoewmglDC9rumGG9L7jzyrlAUk0BnHaKKhE+ H4WFDbyiKVBLbBjXI3ylOwoDauLEMGc+ZqfNpwZnQedcLKdrrEwz5g0GhrMAj2Eb f76EWbhXEAwErSu28j0rZgNftRj/NbD973avq2ma1huXNjO+5CvWkJnpwnGjIsIg WSGFEfnVLIGq4XHs4GuwGeOITBLGL3nSQrgTvRVkB9CPcWy7H6e8C9PwJVte3UV6 XGwF+v7bajoXeUSH3DunTNRNd7ZsfIyLHpZ73orcWEJPM1aKyLXC8bRsDM24NmCT 50aT/WkNGc0Xgp7MfpGMQz72Zs9lB2zcwRS/V/q8z5wJE/L24ero0AoIZzURei9J aERIFAmr4/NwMHp063o6Fj5YWk7q5olrKtOeuIWNVVWo4OQ2Jx3WMRmRW34bj4sF o2mneZzG/WNJfoPNZsno =U0hG -----END PGP SIGNATURE----- --Apple-Mail=_094FAC1C-73B5-4845-A68C-D88D0438C1AD-- From nobody Fri Feb 3 11:06:05 2017 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 2B47C1294D5; Fri, 3 Feb 2017 11:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ZuRCYLoEHChk; Fri, 3 Feb 2017 11:05:57 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD401296AD; Fri, 3 Feb 2017 11:05:57 -0800 (PST) Received: from [IPv6:2001:1291:200:42e::2] (cl-1071.udi-01.br.sixxs.net [IPv6:2001:1291:200:42e::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1F1288362C; Fri, 3 Feb 2017 20:05:51 +0100 (CET) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: Brian E Carpenter , "Eggert, Lars" , "ietf@ietf.org" References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> Date: Thu, 2 Feb 2017 23:00:27 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsv-area@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "ipv6@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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, 03 Feb 2017 19:06:00 -0000 On 02/02/2017 09:18 PM, Brian E Carpenter wrote: > On 02/02/2017 22:54, Fernando Gont wrote: >> Hi, Lars, >> >> On 02/02/2017 06:37 AM, Eggert, Lars wrote: >>> Hi, >>> >>> the last paragraph of the introduction reads: >>> >>> An extension to Path MTU Discovery defined in this document can be >>> found in [RFC4821]. It defines a method for Packetization Layer >>> Path MTU Discovery (PLPMTUD) designed for use over paths where >>> delivery of ICMP messages to a host is not assured. >>> >>> Given that ICMP delivery cannot be assured over the vast majority of >>> paths in the current Internet, should this document make a >>> recommendation to implement RFC4821? >> >> I think that RFC4821 should be recommended, at least for dealing with >> ICMP blackholes (i.e., use ICMP if you can, but be able to deal with >> scenarios in which you don't receive them). > > Many people think that, but this draft is constrained by the rules in > RFC6410 about "high degree of technical maturity" and "widespread > deployment" in the move from PS to Standard. Adding new stuff is not > supposed to happen. If I recall correctly, the WG tuned the language > to its present state for that reason. My apologies: my comments were probably misleading. Certainly, this document is simply RFC1981 to Std, and hence recommending RFC4821 would be kind of ou of scope, here. That say, one might wonder to what extent, and for the general Internet, RFC1981 can be considered succesful (given the filtering of ICMP messages). -- i.e., at this point in time you wouldn't rely on RFC1981 (icmp-based pmtud) for path-mtu discovery. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Feb 4 03:05:08 2017 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 DC94212706D; Sat, 4 Feb 2017 03:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.022 X-Spam-Level: X-Spam-Status: No, score=-5.022 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.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 6UedtKOjVjeB; Sat, 4 Feb 2017 03:05:05 -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 DDEF51296B0; Sat, 4 Feb 2017 03:05:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,333,1477983600"; d="asc'?scan'208";a="173811165" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx143-out.netapp.com with ESMTP; 04 Feb 2017 02:52:58 -0800 Received: from VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 4 Feb 2017 02:59:57 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Sat, 4 Feb 2017 02:59:57 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zsElXndgq2uJdJPcp72zUgjY1ZxEU8VDVFglYA8BHWY=; b=aSCBK8vej1fSipX5FdeDWNmhf6c7otNUy7qGGVV/svqMaW3cuPEwNDIfZ3+uaIYO2wkpIuytCtfVU+3p92QzrL8slhq9ymrO6Qp8pNXCy8kiPtaP39G7h5zdXNqxu4y5m08XSQ5Eq+VQaChj9v0a9kf/UTmEHBeZIdSGC48/ft8= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Sat, 4 Feb 2017 10:59:56 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0874.025; Sat, 4 Feb 2017 10:59:56 +0000 From: "Eggert, Lars" To: Fernando Gont Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Topic: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Index: AQHSfOZWQnyqff8qTkSuzK39n1gXQaFVdhOAgAAEwQCAAPFzgIAAHICAgAIpDQA= Date: Sat, 4 Feb 2017 10:59:56 +0000 Message-ID: References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> In-Reply-To: <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a61:31e0:2601:d5e4:7bac:a4b7:a8c5] x-ms-office365-filtering-correlation-id: 34afb560-ba11-41f8-0581-08d44cecf463 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1153; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1153; 7:0sPFousmR2jl1iHirrbrU4onP+w8RuSilx2E4Q4S4TRIoU6NGslSw5VUFxFFFGA6hq1kGb3+8YO8Z0j7lZM6B90M01kqmwQjqQlptrdOLVOiCofQmoddB00bKVpSPIHxYZQN4ZAhVYkxDpdG7+/DOq/8a92bdbOn6+lYMViq2IyTvuy9zjdx4iaJ+75y8QyTRhDtQiqx+kezjyljAVfpBE8/knbCQWl+INeVy+uj4er4WAaTKaT4kc3eOk/dZf7CkTqMwTx5WaU0l+knjHhdQ2n2FbYHBT+tRqfbPOv6afwYNDT8Feh61lZrh6BoOS0uMUg79UuKSA1P+if+fWV4/H0GsUFNOoYKA1c2/271of5moMA8CSqqyQUZaRsVVnRywgVfr6gRZqEKtVAnOVR9CmOtEbQyy1buZaOsXdvhXk4Ol+5H8cBO/fCHnQA9jXHyexvzLMkzBwk70wye2sCVkvUs2l5b4upaXfe+JJcQybg/h01KL31D9Lq1dMNmbgjxHdPGIVjZz1hii9wj0KvRdA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR0601MB1153; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1153; x-forefront-prvs: 020877E0CB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(377424004)(199003)(24454002)(8676002)(2950100002)(93886004)(68736007)(81156014)(25786008)(6436002)(81166006)(76176999)(6916009)(33656002)(99936001)(110136003)(57306001)(230783001)(38730400001)(5660300001)(2900100001)(2906002)(3280700002)(36756003)(50226002)(50986999)(305945005)(189998001)(77096006)(4001150100001)(8936002)(97736004)(101416001)(6486002)(7736002)(92566002)(3660700001)(6506006)(229853002)(99286003)(39060400001)(105586002)(83716003)(6512007)(86362001)(102836003)(54906002)(6116002)(122556002)(106116001)(53546003)(53936002)(6246003)(106356001)(82746002)(4326007)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1153; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_A4D80AFE-E61D-4602-A53B-6FA376969F5F"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2017 10:59:56.0643 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1153 X-OriginatorOrg: netapp.com Archived-At: Cc: "ipv6@ietf.org" , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , Brian E Carpenter , "6man-chairs@ietf.org" <6man-chairs@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: Sat, 04 Feb 2017 11:05:07 -0000 --Apple-Mail=_A4D80AFE-E61D-4602-A53B-6FA376969F5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-2-3, at 3:00, Fernando Gont wrote: > My apologies: my comments were probably misleading. Certainly, this > document is simply RFC1981 to Std, and hence recommending RFC4821 = would > be kind of ou of scope, here. >=20 > That say, one might wonder to what extent, and for the general = Internet, > RFC1981 can be considered succesful (given the filtering of ICMP > messages). -- i.e., at this point in time you wouldn't rely on RFC1981 > (icmp-based pmtud) for path-mtu discovery. What Fernando said: I'm certainly not opposed to lifting this to = Standard, but it is painting an incorrect picture - PLPMTUD is de facto = mandatory these days, and has been for years. Lars --Apple-Mail=_A4D80AFE-E61D-4602-A53B-6FA376969F5F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYlbQqAAoJEFS1wwm/cMFXMnEQAM6tw7omVmxQFiqHNSQLa5Wc 9K+aWN2UjaVpneWUX+Fx4HiRFuAvj5CHiMdTq9Pt0aSekS8iy4FBWUZSC0shJJsc gLzD9EmCANfNbjwLFsLtPtZSO4PPf0YaU+cLJv5cWD+9FECvubwEVVFZUof1pO9b jvUG7f9f4WqqOyMRr5wEXVQrcvffmW3ovR9BAHdnh7HL47oFEBsmQ8KnlktjTAkJ mXsIb81RrKX7tAfxi3n/vFPOLW1xmDd47nDHDa6y/Uj4gwcv7MKR+bN491eD0ffG 6P9JPH/VVTEQXCB/OueIDRh/cvNSknArIC7uGRPXB5MoRit426vie0OF3pbcTpGq C3Zz8VeKeBnTrDVllVashBFCgCOLjtBz1Yxnh1xc5ZsDJWiURF+9S6eddi6NPbDT BV92H7G2+tmF3NrPdrF8v1hrbJZ6hKcmDj5zlWCnVN1Vj0FSLG7HV0zPdmS2n+HM xl5RgAfxuwrU/Ys/vepWWWC8mggMPgJMKtDDN24rvCdMROmqWnIRv8Xc0xHezIE4 6VxgjVHwV0iYFcANif/+0SESA8fc6eA2wxHzzAFYSXxhdW0vBRvfxIA7s1IiMPy2 1vz9/STeYWYPrr7VYMIaR3yoyoFX2zXwL1Pm61+XhBjNaqJbecP8y3DHavGwCQX/ QkUhM5XS1MZ8gkFV+92R =mh9S -----END PGP SIGNATURE----- --Apple-Mail=_A4D80AFE-E61D-4602-A53B-6FA376969F5F-- From nobody Sat Feb 4 10:40:47 2017 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 00F4612950B; Sat, 4 Feb 2017 10:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 500VxY8EfptD; Sat, 4 Feb 2017 10:40:40 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id A2AEF1294BA; Sat, 4 Feb 2017 10:40:39 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 04 Feb 2017 18:40:39 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 3379DD788B; Sat, 4 Feb 2017 10:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=+nAUwmE2HDzkl7YJ2+pb6FB3QpA=; b= Ylmy9+UCTP6dgRPgtWieNw/+Ud1fYq8fCoyeoqXl5w+sa9yXEmPZ8Ho+7xm1R1k1 +ZXXsAE76RtSR8HVTpNBJoPsepHgoKrrXcBWMcVsCCE60FYsdLAFqa8DqbYKTEFU /9Volp09jDInXbOz5zVhwzHhcAonlnq7CC6An6q3ucc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=lln2//4v/pzbCrq2E1ER9qI lgT3/+HgNxrfiyUot+SFwv8zkXJbig06R1uvYGRex/mejWQFpO4X6v3JPRP3oNcS O3tbedYI3rEybWLjbJkEeJhSohlzZmtl8GsILp7/W99zI+LlKEF7L8SbWMhgFPfx F7Up+/BtJxYPSopEnspg= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 073CBD788A; Sat, 4 Feb 2017 10:40:39 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A1D8E841116F; Sat, 4 Feb 2017 19:40:36 +0100 (CET) From: otroan@employees.org Message-Id: <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_DD8FD33D-FE8D-4C53-B8E5-620BE77F2552"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Date: Sat, 4 Feb 2017 19:40:36 +0100 In-Reply-To: To: "Eggert, Lars" References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , Brian E Carpenter , "6man-chairs@ietf.org" <6man-chairs@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: Sat, 04 Feb 2017 18:40:42 -0000 --Apple-Mail=_DD8FD33D-FE8D-4C53-B8E5-620BE77F2552 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Lars, >> My apologies: my comments were probably misleading. Certainly, this >> document is simply RFC1981 to Std, and hence recommending RFC4821 = would >> be kind of ou of scope, here. >>=20 >> That say, one might wonder to what extent, and for the general = Internet, >> RFC1981 can be considered succesful (given the filtering of ICMP >> messages). -- i.e., at this point in time you wouldn't rely on = RFC1981 >> (icmp-based pmtud) for path-mtu discovery. >=20 > What Fernando said: I'm certainly not opposed to lifting this to = Standard, but it is painting an incorrect picture - PLPMTUD is de facto = mandatory these days, and has been for years. While I'm all in favour of PLMTUD. It doesn't seem like a complete = solution. PMTUD on the other hand supports all protocols on top of IP. Looking just at our specifications, we cannot state that PLMTUD can = replace PMTUD. Take RFC2473 (IPv6 tunnelling) for example. O. --Apple-Mail=_DD8FD33D-FE8D-4C53-B8E5-620BE77F2552 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYliAkAAoJEL7aWKiYQt92X3YP/1VUq1O0wQ7ingkwU3B/NwvG wIN2OnXLUEN/ffQqIg+fM4VZu45fS45PVbELeiXu7fnts4GUb5osnpfwDeNRROrs /+yhmvG0YzmJVDlFjcwRG66WyIEtgJjLpQsryeTgQk1rD3nRdzfg1ZA+ysznK2h2 g22DvlnPnbPIAIsjBaVBWwQIqz1JHhzATBQ6e1d0uHcYiNuBWFUz+6tAnL3Q3Giv bHtgImeydxvpFzle1hVQ7IoPo7WFrHYpPIciTitT05AGQZEs41SnWCxJPgGRBydO su3g7U7nGCThN341laq6G6CU50KtCTfuFIFZTG/xp5f48hNkXa7m08tmIe6VgCT+ yUOwys010OTVU19wrzVuTsrS1J6Ka+RgUrCP+bCREsupDdXg/hFaRZzZC68HPBTr WALx8lRhcWBdtSkWe/78P3BJjgQAB7BRzaRE1IfJpmMZ119zKmRqtzal/6fQ8g6f 6OOEN2n3LGAPbBgfBsbsF0BxKDWC6hcnRxJCI/LlOwJrFmewHghCQACsfUs6vCEv aq0Vt/uRA+VVKRVVpd/OFboO6v8uV8WRL/z4OuH50/qjfaKc2n3l33m805tlA3O5 GjifuZTOb8vISRxSXtVE1SADqxGbpQ92jYBi52qXsHwvmWI1IIHRrIsvidZI4gG0 0JtC3EyHRnK7vY5Vq8Rc =vYbV -----END PGP SIGNATURE----- --Apple-Mail=_DD8FD33D-FE8D-4C53-B8E5-620BE77F2552-- From nobody Sat Feb 4 10:50:17 2017 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 55BB7129448; Sat, 4 Feb 2017 10:50:15 -0800 (PST) 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 O_qqbTtIBBBd; Sat, 4 Feb 2017 10:50:14 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 A523D1293FE; Sat, 4 Feb 2017 10:50:13 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id v77so73981617wmv.0; Sat, 04 Feb 2017 10:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YbVdLTWPozJiLnXSmDSJDBTCcjv73Zt//r73E9xeSw0=; b=FXbLCLwSP+0RPdZ53QYZ1cJ3ve0rE6+rAyIt8+a2kSWuIR3ktz57FwBW1JHwgphn59 ObPuPt7/AYvVUQdpsYsMAvwyz5QTy29yqbHQIjz7UB6cVgJ31O9JJOmm1Jn+CVIbsFug qBIY7lJEAtKsqg/kUYAyHVgWX6R3BI/D/5A3GRNjiYWZo0po4XHm3mPCOYI26dNHYHwN 25R4VOn+rkKy25xwzWyKhCQwZl3pbtInTgAldsJRvTZNk3V8x22EYd5RmHDrZKyUFVIy oV9WJp6qDAOsxvITZUGfdrg4vYT0Qv63tu4RJ+sUmBIFh+h9YSyt/QSu3k43lLTpJ55A HSSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YbVdLTWPozJiLnXSmDSJDBTCcjv73Zt//r73E9xeSw0=; b=oY/s+ljQShoMIO7VBzkZLgxgYqd8pDM0OMpwSnHoaaPu6JP/Y71t0+4BQmyJO+qQMm IITEJI2VBDfVU4KEymw2gtnap7tfqvDlQp9xgsr0h2r1XZgfNA3JA+0hT0nmYfjCNcPU twi063Qg8DwhGWRS4KTgV7WNO5iHjBAOkBPy9TCRh9eEah5KKEiIa5fzuDETvODubZqy z5mjJubHM/YWJXXIc2LvbGOKh46//5ABwy2Qf2Vij1i0EIsdshRR3i9GGSgn4Fmv0OM+ bQV5Axuq1iAR4uP5ewTi8b5kgsgdN5qVtbxUSb3RFf1S5wvv3fOwkyW2cBMTe6RYPk9e u6Dg== X-Gm-Message-State: AMke39mt+CHz0CuzDAHLTgNtHKTpByAHhZ18FSj8rNSc3Gq842OqY3edyKMZFnZmVeQg8Q== X-Received: by 10.28.129.147 with SMTP id c141mr2988413wmd.12.1486234212151; Sat, 04 Feb 2017 10:50:12 -0800 (PST) Received: from ?IPv6:2601:647:4d01:db10:9541:744d:33b2:2904? ([2601:647:4d01:db10:9541:744d:33b2:2904]) by smtp.gmail.com with ESMTPSA id k4sm3783889wmf.22.2017.02.04.10.50.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Feb 2017 10:50:11 -0800 (PST) From: Bob Hinden Message-Id: <3BF2F820-65B7-4151-BD35-F07B132C9F1E@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_78F5415F-3BD7-4F43-92C3-919784D39E49"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Date: Sat, 4 Feb 2017 10:50:04 -0800 In-Reply-To: <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> To: "Eggert, Lars" References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 List , IETF , Bob Hinden , "draft-ietf-6man-rfc1981bis@ietf.org" , =?utf-8?Q?Ole_Tr=C3=B8an?= , "tsv-area@ietf.org" , Brian Carpenter , "6man-chairs@ietf.org" <6man-chairs@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: Sat, 04 Feb 2017 18:50:15 -0000 --Apple-Mail=_78F5415F-3BD7-4F43-92C3-919784D39E49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Lars, > On Feb 4, 2017, at 10:40 AM, otroan@employees.org wrote: >=20 > Lars, >=20 >>> My apologies: my comments were probably misleading. Certainly, this >>> document is simply RFC1981 to Std, and hence recommending RFC4821 = would >>> be kind of ou of scope, here. >>>=20 >>> That say, one might wonder to what extent, and for the general = Internet, >>> RFC1981 can be considered succesful (given the filtering of ICMP >>> messages). -- i.e., at this point in time you wouldn't rely on = RFC1981 >>> (icmp-based pmtud) for path-mtu discovery. >>=20 >> What Fernando said: I'm certainly not opposed to lifting this to = Standard, but it is painting an incorrect picture - PLPMTUD is de facto = mandatory these days, and has been for years. >=20 > While I'm all in favour of PLMTUD. It doesn't seem like a complete = solution. > PMTUD on the other hand supports all protocols on top of IP. >=20 > Looking just at our specifications, we cannot state that PLMTUD can = replace PMTUD. Take RFC2473 (IPv6 tunnelling) for example. In addition to what Ole says here, I don=E2=80=99t think rfc1981bis is = the right place to describe this. 6MAN is working on an update to IPv6 = Node Requirements ( https://tools.ietf.org/html/draft-clw-rfc6434-bis-00 = ). I think is a better place to describe the relationship between PMTUD = and PLMTUD, where they work and don=E2=80=99t, and what the current = recommendations are. I hope you will contribute to that work. Thanks, Bob --Apple-Mail=_78F5415F-3BD7-4F43-92C3-919784D39E49 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYliJdAAoJEK7rdBF357uofEMH+gKcMDoL4qp+S+xGDcc+4Fhh WZsLSxMbvJ6XkA0g/WYwrjEgp35fk1oQ6SUU7c9Z7ukGf8J6xRAYNoIb1tP1UUo6 YkRRsnriCUcHGMKdwKBoY+8mLxVBj/5+nW1IJ98S5swiFAvf3/tmu+l9rI2EYjkF 2143r2xlzNbi2UCTFGTiWbPNCmAG3PN9mpQaTsOgpvSa6wWBm9ZRVpn+xMTb60xM GqH86irKZ20b98XghDSrT3isZkxeLPoePH9RECz35Er6bL5nGdnhAcTK0HjfKSE4 ZcGP+eG9P27AViOv6Cz0f9ggrByuz62LlMpWVCz8ZPC1QGhKDuJPvu3pE+wNaxg= =XwZ0 -----END PGP SIGNATURE----- --Apple-Mail=_78F5415F-3BD7-4F43-92C3-919784D39E49-- From nobody Tue Feb 7 10:26:18 2017 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 6E242129480; Tue, 7 Feb 2017 10:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 VtyVZrQkRt8G; Tue, 7 Feb 2017 10:26:15 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 419951293D8; Tue, 7 Feb 2017 10:26:15 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v17IPW9J027257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Feb 2017 10:25:32 -0800 (PST) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: otroan@employees.org, "Eggert, Lars" References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> From: Joe Touch Message-ID: <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> Date: Tue, 7 Feb 2017 10:25:33 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@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: Tue, 07 Feb 2017 18:26:16 -0000 On 2/4/2017 10:40 AM, otroan@employees.org wrote: > Lars, > >>> My apologies: my comments were probably misleading. Certainly, this >>> document is simply RFC1981 to Std, and hence recommending RFC4821 would >>> be kind of ou of scope, here. >>> >>> That say, one might wonder to what extent, and for the general Internet, >>> RFC1981 can be considered succesful (given the filtering of ICMP >>> messages). -- i.e., at this point in time you wouldn't rely on RFC1981 >>> (icmp-based pmtud) for path-mtu discovery. >> What Fernando said: I'm certainly not opposed to lifting this to Standard, but it is painting an incorrect picture - PLPMTUD is de facto mandatory these days, and has been for years. > While I'm all in favour of PLMTUD. It doesn't seem like a complete solution. > PMTUD on the other hand supports all protocols on top of IP. If by "supports" you mean "doesn't work", then yes. That's why we now have PLPMTUD. > Looking just at our specifications, we cannot state that PLMTUD can replace PMTUD. Take RFC2473 (IPv6 tunnelling) for example. See draft-ietf-intarea-tunnels, esp. v03 Section 5.5.2 (yes, that doc has expired while we're preparing the 04 update, which should be issued shortly) Joe From nobody Tue Feb 7 11:20:39 2017 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 7F9D61295A0; Tue, 7 Feb 2017 11:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 MG6WYa_oQfI9; Tue, 7 Feb 2017 11:20:32 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id CA2C6129461; Tue, 7 Feb 2017 11:20:31 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 07 Feb 2017 19:20:31 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 115CCD788B; Tue, 7 Feb 2017 11:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=Ul8b8AlinbEJb/sx2BP5BdhvN1A=; b= kGRNfq7EeTTCOlITv1IiCUjMXj4Q7uai4bKUj2oendjSgY2N4CBQOfP9cXNe/eFx QWHj+5RyIrmZ/AhshqLfw6W8C/2hcdkb+5mzAOZOjuFkJNSxa4UoFeHJxS2hIofY lZKBfCxweJj1p/9fr0O1vyVqJjlTzqGyM0NPjfim7r4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=pdFNFoCFLwj1ADaakUyWe1o /8YeR8NABkKyN7+Ohv3cleaMwZfVHopLhMZSmv2pW2D8EGFCRZzvbcojXbqGrWU/ rlJU8ngm+KRADEOfmJTgPKG98lKA+EdHT7DFEISL5aK3dH9R3V6cgdSN1sQd8wNI 1f84XS0HL51t6v3p9N1M= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 986F3D788E; Tue, 7 Feb 2017 11:20:30 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 68C47865E62B; Tue, 7 Feb 2017 20:20:27 +0100 (CET) From: otroan@employees.org Message-Id: <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_80CF1CA3-844D-451D-8AC2-B679B5C2B9DA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Date: Tue, 7 Feb 2017 20:20:26 +0100 In-Reply-To: <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> To: Joe Touch References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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: Tue, 07 Feb 2017 19:20:33 -0000 --Apple-Mail=_80CF1CA3-844D-451D-8AC2-B679B5C2B9DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Joe, >>>> My apologies: my comments were probably misleading. Certainly, this >>>> document is simply RFC1981 to Std, and hence recommending RFC4821 = would >>>> be kind of ou of scope, here. >>>>=20 >>>> That say, one might wonder to what extent, and for the general = Internet, >>>> RFC1981 can be considered succesful (given the filtering of ICMP >>>> messages). -- i.e., at this point in time you wouldn't rely on = RFC1981 >>>> (icmp-based pmtud) for path-mtu discovery. >>> What Fernando said: I'm certainly not opposed to lifting this to = Standard, but it is painting an incorrect picture - PLPMTUD is de facto = mandatory these days, and has been for years. >> While I'm all in favour of PLMTUD. It doesn't seem like a complete = solution. >> PMTUD on the other hand supports all protocols on top of IP. > If by "supports" you mean "doesn't work", then yes. That's why we now > have PLPMTUD. PLMTUD is unfortunately not a (complete) replacement of PMTUD. >> Looking just at our specifications, we cannot state that PLMTUD can = replace PMTUD. Take RFC2473 (IPv6 tunnelling) for example. > See draft-ietf-intarea-tunnels, esp. v03 Section 5.5.2 >=20 > (yes, that doc has expired while we're preparing the 04 update, which > should be issued shortly) Is this the paragraph you are referring to? PLPMTUD requires a separate, direct control channel from the egress to the ingress that provides positive feedback; the direct channel is not blocked by policy filters and the positive feedback ensures fail-safe operation if feedback messages are lost [RFC4821]. I'm very much in favour of working on better ways of doing Path MTU = discovery. A blanket statement of "use "PLMTUD" seems very premature though. RFC1981 has 70 citations: http://www.arkko.com/tools/allstats/citations-rfc1981.html Could you expand on your view of how this pertains to advancing RFC1981? Best regards, Ole --Apple-Mail=_80CF1CA3-844D-451D-8AC2-B679B5C2B9DA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYmh37AAoJEL7aWKiYQt92ZSUQAKYRtwt9j3ovfkplaMKzAcud HZmDJ+Yb9t/empELhf1rGNoQve5aOA9p58ICUITqeGnsSYZtPDFfIjZG50WZTBt0 qcdDmQ7wejiVVjeB/7Gf7lFGB45gdcpWpyDt2mCV0wD8B3D8vvTsYIxpSyuip6kA fjRjG7ZDtfPYkBfrPljA5Xe9laqzFJs9aoyj9xOn9qvv7WzMitn7D9nmQCynP486 4gEMMeb+C2CosT4m3HTSXMFB2jnmoN29Nee/MaQYSpUKYzkbdaGdvbUwu3HQIUKg +6Y/tDZm0Z6uFXrrEdFedMQ9I3PWe/uVB5GPkYyJU69X7UoMX08RJNkNKyLzkhIP MJmywfijlfkPace9WhWTFbFc4VWdTHOxe1CsI5jHsyPWPq2RAnwh2iRoSzPSbsp6 5UQUGcpr31br7T48fpHygGYlwC0QH08apexsvkLEzSJBxwvFXsu+UqIA3IlHL3PS XB6dz/Z0m6UdDtpaRvY7hiGcU5JNsBS8GgPsybHLSm5AZthCcr089OdSrZ2gRRZP EUdVFsqQzojKrZye2FW28F7YSQfwNSgfBWTrscNPavN5n6jC65jkebIRIKBLhC/K yLLyo2CeiWr3GpUhLjPzoysYU78pg1LvojRlyTgnJ7eYS/gsQw3y0bJeEJnqKl4B GXBNdz6tI+Yhok2NyMeq =wuwT -----END PGP SIGNATURE----- --Apple-Mail=_80CF1CA3-844D-451D-8AC2-B679B5C2B9DA-- From nobody Tue Feb 7 11:42:50 2017 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 7C54B129E62; Tue, 7 Feb 2017 11:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 KxKkV7ncjxCd; Tue, 7 Feb 2017 11:42:47 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 EEB4F129E5B; Tue, 7 Feb 2017 11:42:46 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v17JgVpO008880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Feb 2017 11:42:32 -0800 (PST) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: otroan@employees.org References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> From: Joe Touch Message-ID: <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> Date: Tue, 7 Feb 2017 11:42:29 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> Content-Type: multipart/alternative; boundary="------------07D681C8AAE849D500F6504E" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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: Tue, 07 Feb 2017 19:42:48 -0000 This is a multi-part message in MIME format. --------------07D681C8AAE849D500F6504E Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 2/7/2017 11:20 AM, otroan@employees.org wrote: > Joe, > >>>>> My apologies: my comments were probably misleading. Certainly, this >>>>> document is simply RFC1981 to Std, and hence recommending RFC4821 would >>>>> be kind of ou of scope, here. >>>>> >>>>> That say, one might wonder to what extent, and for the general Internet, >>>>> RFC1981 can be considered succesful (given the filtering of ICMP >>>>> messages). -- i.e., at this point in time you wouldn't rely on RFC1981 >>>>> (icmp-based pmtud) for path-mtu discovery. >>>> What Fernando said: I'm certainly not opposed to lifting this to Standard, but it is painting an incorrect picture - PLPMTUD is de facto mandatory these days, and has been for years. >>> While I'm all in favour of PLMTUD. It doesn't seem like a complete solution. >>> PMTUD on the other hand supports all protocols on top of IP. >> If by "supports" you mean "doesn't work", then yes. That's why we now >> have PLPMTUD. > PLMTUD is unfortunately not a (complete) replacement of PMTUD. PLMTUD is a directive to protocols above the IP layer; it isn't a single protocol, so it wouldn't replace anything. > >>> Looking just at our specifications, we cannot state that PLMTUD can replace PMTUD. Take RFC2473 (IPv6 tunnelling) for example. >> See draft-ietf-intarea-tunnels, esp. v03 Section 5.5.2 >> >> (yes, that doc has expired while we're preparing the 04 update, which >> should be issued shortly) > Is this the paragraph you are referring to? > > PLPMTUD requires a separate, > direct control channel from the egress to the ingress that provides > positive feedback; the direct channel is not blocked by policy > filters and the positive feedback ensures fail-safe operation if > feedback messages are lost [RFC4821]. That is nowhere near section 5.5.2. 5.5.2 indicates places where RFC2473 has errors, esp. in how it interprets the MTU of the tunnel as being defined by the MTU of the path within the tunnel, rather than by the tunnel egress reassembly limit. > I'm very much in favour of working on better ways of doing Path MTU discovery. > A blanket statement of "use "PLMTUD" seems very premature though. The point is that this document fails to indicate the current state of PMTUD. It correctly notes that: An extension to Path MTU Discovery defined in this document can be found in [RFC4821 ]. It defines a method for Packetization Layer Path MTU Discovery (PLPMTUD) designed for use over paths where delivery of ICMP messages to a host is not assured. IMO, it fails to note that this case - where ICMP messages are assured along a path - is effectively a unicorn except within systems maintained by a single entity. > RFC1981 has 70 citations: > http://www.arkko.com/tools/allstats/citations-rfc1981.html > > Could you expand on your view of how this pertains to advancing RFC1981? It's called last call input. My input is that this document needs to be more realistic in noting that, for all intents, ICMP-based MTU discovery isn't viable and that other methods need to be *expected*, not just that they're available. Joe --------------07D681C8AAE849D500F6504E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit



On 2/7/2017 11:20 AM, otroan@employees.org wrote:
Joe,


My apologies: my comments were probably misleading. Certainly, this
document is simply RFC1981 to Std, and hence recommending RFC4821 would
be kind of ou of scope, here.

That say, one might wonder to what extent, and for the general Internet,
RFC1981 can be considered succesful (given the filtering of ICMP
messages). -- i.e., at this point in time you wouldn't rely on RFC1981
(icmp-based pmtud) for path-mtu discovery.

What Fernando said: I'm certainly not opposed to lifting this to Standard, but it is painting an incorrect picture - PLPMTUD is de facto mandatory these days, and has been for years.

While I'm all in favour of PLMTUD. It doesn't seem like a complete solution.
PMTUD on the other hand supports all protocols on top of IP.

If by "supports" you mean "doesn't work", then yes. That's why we now
have PLPMTUD.

PLMTUD is unfortunately not a (complete) replacement of PMTUD.

PLMTUD is a directive to protocols above the IP layer; it isn't a single protocol, so it wouldn't replace anything.


Looking just at our specifications, we cannot state that PLMTUD can replace PMTUD. Take RFC2473 (IPv6 tunnelling) for example.

See draft-ietf-intarea-tunnels, esp. v03 Section 5.5.2

(yes, that doc has expired while we're preparing the 04 update, which
should be issued shortly)

Is this the paragraph you are referring to?

   PLPMTUD requires a separate,
   direct control channel from the egress to the ingress that provides
   positive feedback; the direct channel is not blocked by policy
   filters and the positive feedback ensures fail-safe operation if
   feedback messages are lost [RFC4821].
That is nowhere near section 5.5.2.

5.5.2 indicates places where RFC2473 has errors, esp. in how it interprets the MTU of the tunnel as being defined by the MTU of the path within the tunnel, rather than by the tunnel egress reassembly limit.

I'm very much in favour of working on better ways of doing Path MTU discovery.
A blanket statement of "use "PLMTUD" seems very premature though.
The point is that this document fails to indicate the current state of PMTUD. It correctly notes that:
   An extension to Path MTU Discovery defined in this document can be
   found in [RFC4821].  It defines a method for Packetization Layer Path
   MTU Discovery (PLPMTUD) designed for use over paths where delivery of
   ICMP messages to a host is not assured.
IMO, it fails to note that this case - where ICMP messages are assured along a path - is effectively a unicorn except within systems maintained by a single entity.

RFC1981 has 70 citations:
http://www.arkko.com/tools/allstats/citations-rfc1981.html

Could you expand on your view of how this pertains to advancing RFC1981?
It's called last call input. My input is that this document needs to be more realistic in noting that, for all intents, ICMP-based MTU discovery isn't viable and that other methods need to be *expected*, not just that they're available.

Joe
--------------07D681C8AAE849D500F6504E-- From nobody Tue Feb 7 11:48:03 2017 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 5273E129E76; Tue, 7 Feb 2017 11:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 GmhbMOdCJmKP; Tue, 7 Feb 2017 11:47:51 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 C31B2129E5E; Tue, 7 Feb 2017 11:47:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v17JlpDp040223; Tue, 7 Feb 2017 12:47:51 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v17Jjv7j036982 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 7 Feb 2017 12:45:57 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 7 Feb 2017 11:45:55 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1178.000; Tue, 7 Feb 2017 11:45:56 -0800 From: "Templin, Fred L" To: Joe Touch , "otroan@employees.org" , "Eggert, Lars" Subject: RE: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Topic: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Index: AQHSgW+yaUQDcUzHwUaWWd7FFympqaFd8O5w Date: Tue, 7 Feb 2017 19:45:56 +0000 Message-ID: References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> In-Reply-To: <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: 6man WG , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , "ietf@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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: Tue, 07 Feb 2017 19:47:53 -0000 Hi Joe, In my understanding, RFC4821 does not adequately address scenarios where th= e probe packets may (for legitimate reasons) take a different path than the d= ata packets, e.g., when Equal-Cost Multi Path (ECMP) is present. This is not on= ly a consideration for tunnels, but also for path MTU sharing between transport = layer sessions where an MTU learned by a first session is shared with a second se= ssion bound for the same destination. In that case, the probes of the first sessi= on may take a different path than the data packets of the second session, and a bl= ack hole is possible. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Tuesday, February 07, 2017 10:26 AM > To: otroan@employees.org; Eggert, Lars > Cc: tsv-area@ietf.org; 6man-chairs@ietf.org; 6man WG ; iet= f@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org > Subject: Re: Last Call: (Path MTU Dis= covery for IP version 6) to Internet Standard >=20 >=20 >=20 > On 2/4/2017 10:40 AM, otroan@employees.org wrote: > > Lars, > > > >>> My apologies: my comments were probably misleading. Certainly, this > >>> document is simply RFC1981 to Std, and hence recommending RFC4821 wou= ld > >>> be kind of ou of scope, here. > >>> > >>> That say, one might wonder to what extent, and for the general Intern= et, > >>> RFC1981 can be considered succesful (given the filtering of ICMP > >>> messages). -- i.e., at this point in time you wouldn't rely on RFC198= 1 > >>> (icmp-based pmtud) for path-mtu discovery. > >> What Fernando said: I'm certainly not opposed to lifting this to Stand= ard, but it is painting an incorrect picture - PLPMTUD is de facto > mandatory these days, and has been for years. > > While I'm all in favour of PLMTUD. It doesn't seem like a complete solu= tion. > > PMTUD on the other hand supports all protocols on top of IP. > If by "supports" you mean "doesn't work", then yes. That's why we now > have PLPMTUD. >=20 > > Looking just at our specifications, we cannot state that PLMTUD can rep= lace PMTUD. Take RFC2473 (IPv6 tunnelling) for example. > See draft-ietf-intarea-tunnels, esp. v03 Section 5.5.2 >=20 > (yes, that doc has expired while we're preparing the 04 update, which > should be issued shortly) >=20 > Joe >=20 From nobody Tue Feb 7 11:53:29 2017 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 554FC12947F; Tue, 7 Feb 2017 11:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 bWP9F8RG3rNQ; Tue, 7 Feb 2017 11:53:22 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 ED6F2129E5E; Tue, 7 Feb 2017 11:53:21 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v17JqW93010479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Feb 2017 11:52:34 -0800 (PST) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: "Templin, Fred L" , "otroan@employees.org" , "Eggert, Lars" References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> From: Joe Touch Message-ID: <9836c58c-e533-a69f-a1b7-ed20ce4801e6@isi.edu> Date: Tue, 7 Feb 2017 11:52:33 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: 6man WG , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , "ietf@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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: Tue, 07 Feb 2017 19:53:23 -0000 Hi, Fred, This is a separate issue with RFC4821, though. My point for 1981bis is that it needs to be more clear that ICMP blocking renders this technique ineffective for the most part. I'm not saying that PLPMTUD is perfect or the only alternative, but this doc should be more clear about its own viability. Joe On 2/7/2017 11:45 AM, Templin, Fred L wrote: > Hi Joe, > > In my understanding, RFC4821 does not adequately address scenarios where the > probe packets may (for legitimate reasons) take a different path than the data > packets, e.g., when Equal-Cost Multi Path (ECMP) is present. This is not only a > consideration for tunnels, but also for path MTU sharing between transport layer > sessions where an MTU learned by a first session is shared with a second session > bound for the same destination. In that case, the probes of the first session may > take a different path than the data packets of the second session, and a black > hole is possible. > > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Joe Touch >> Sent: Tuesday, February 07, 2017 10:26 AM >> To: otroan@employees.org; Eggert, Lars >> Cc: tsv-area@ietf.org; 6man-chairs@ietf.org; 6man WG ; ietf@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org >> Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard >> >> >> >> On 2/4/2017 10:40 AM, otroan@employees.org wrote: >>> Lars, >>> >>>>> My apologies: my comments were probably misleading. Certainly, this >>>>> document is simply RFC1981 to Std, and hence recommending RFC4821 would >>>>> be kind of ou of scope, here. >>>>> >>>>> That say, one might wonder to what extent, and for the general Internet, >>>>> RFC1981 can be considered succesful (given the filtering of ICMP >>>>> messages). -- i.e., at this point in time you wouldn't rely on RFC1981 >>>>> (icmp-based pmtud) for path-mtu discovery. >>>> What Fernando said: I'm certainly not opposed to lifting this to Standard, but it is painting an incorrect picture - PLPMTUD is de facto >> mandatory these days, and has been for years. >>> While I'm all in favour of PLMTUD. It doesn't seem like a complete solution. >>> PMTUD on the other hand supports all protocols on top of IP. >> If by "supports" you mean "doesn't work", then yes. That's why we now >> have PLPMTUD. >> >>> Looking just at our specifications, we cannot state that PLMTUD can replace PMTUD. Take RFC2473 (IPv6 tunnelling) for example. >> See draft-ietf-intarea-tunnels, esp. v03 Section 5.5.2 >> >> (yes, that doc has expired while we're preparing the 04 update, which >> should be issued shortly) >> >> Joe >> > From nobody Tue Feb 7 11:58:03 2017 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 E1B3B1295E9; Tue, 7 Feb 2017 11:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 zziAo3g2q6Ai; Tue, 7 Feb 2017 11:57:59 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 9464F1295EB; Tue, 7 Feb 2017 11:57:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v17JvwHo030810; Tue, 7 Feb 2017 12:57:59 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v17JvrZE030728 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 7 Feb 2017 12:57:54 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 7 Feb 2017 11:57:53 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1178.000; Tue, 7 Feb 2017 11:57:53 -0800 From: "Templin, Fred L" To: Joe Touch , "otroan@employees.org" , "Eggert, Lars" Subject: RE: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Topic: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Index: AQHSgW+yaUQDcUzHwUaWWd7FFympqaFd8O5wgACJwID//3pYkA== Date: Tue, 7 Feb 2017 19:57:53 +0000 Message-ID: <0343dd6744e24beb9c6ea4ace333d239@XCH15-06-08.nw.nos.boeing.com> References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <9836c58c-e533-a69f-a1b7-ed20ce4801e6@isi.edu> In-Reply-To: <9836c58c-e533-a69f-a1b7-ed20ce4801e6@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: 6man WG , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , "ietf@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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: Tue, 07 Feb 2017 19:58:02 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, February 07, 2017 11:53 AM > To: Templin, Fred L ; otroan@employees.org; Eg= gert, Lars > Cc: tsv-area@ietf.org; 6man-chairs@ietf.org; 6man WG ; iet= f@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org > Subject: Re: Last Call: (Path MTU Dis= covery for IP version 6) to Internet Standard >=20 > Hi, Fred, >=20 > This is a separate issue with RFC4821, though. Agreed. Fred Baker and I were discussing about whether an erratum should be filed. > My point for 1981bis is that it needs to be more clear that ICMP > blocking renders this technique ineffective for the most part. I'm not > saying that PLPMTUD is perfect or the only alternative, but this doc > should be more clear about its own viability. I could agree if suitable language could be adopted. Thanks - Fred > Joe >=20 >=20 > On 2/7/2017 11:45 AM, Templin, Fred L wrote: > > Hi Joe, > > > > In my understanding, RFC4821 does not adequately address scenarios wher= e the > > probe packets may (for legitimate reasons) take a different path than t= he data > > packets, e.g., when Equal-Cost Multi Path (ECMP) is present. This is no= t only a > > consideration for tunnels, but also for path MTU sharing between transp= ort layer > > sessions where an MTU learned by a first session is shared with a secon= d session > > bound for the same destination. In that case, the probes of the first s= ession may > > take a different path than the data packets of the second session, and = a black > > hole is possible. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Joe Tou= ch > >> Sent: Tuesday, February 07, 2017 10:26 AM > >> To: otroan@employees.org; Eggert, Lars > >> Cc: tsv-area@ietf.org; 6man-chairs@ietf.org; 6man WG ; = ietf@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org > >> Subject: Re: Last Call: (Path MTU = Discovery for IP version 6) to Internet Standard > >> > >> > >> > >> On 2/4/2017 10:40 AM, otroan@employees.org wrote: > >>> Lars, > >>> > >>>>> My apologies: my comments were probably misleading. Certainly, this > >>>>> document is simply RFC1981 to Std, and hence recommending RFC4821 w= ould > >>>>> be kind of ou of scope, here. > >>>>> > >>>>> That say, one might wonder to what extent, and for the general Inte= rnet, > >>>>> RFC1981 can be considered succesful (given the filtering of ICMP > >>>>> messages). -- i.e., at this point in time you wouldn't rely on RFC1= 981 > >>>>> (icmp-based pmtud) for path-mtu discovery. > >>>> What Fernando said: I'm certainly not opposed to lifting this to Sta= ndard, but it is painting an incorrect picture - PLPMTUD is de > facto > >> mandatory these days, and has been for years. > >>> While I'm all in favour of PLMTUD. It doesn't seem like a complete so= lution. > >>> PMTUD on the other hand supports all protocols on top of IP. > >> If by "supports" you mean "doesn't work", then yes. That's why we now > >> have PLPMTUD. > >> > >>> Looking just at our specifications, we cannot state that PLMTUD can r= eplace PMTUD. Take RFC2473 (IPv6 tunnelling) for example. > >> See draft-ietf-intarea-tunnels, esp. v03 Section 5.5.2 > >> > >> (yes, that doc has expired while we're preparing the 04 update, which > >> should be issued shortly) > >> > >> Joe > >> > > >=20 From nobody Tue Feb 7 12:07:09 2017 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 8BC53129479; Tue, 7 Feb 2017 12:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 5w2zLhM_smVV; Tue, 7 Feb 2017 12:06:56 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id ED6A3129469; Tue, 7 Feb 2017 12:06:55 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 07 Feb 2017 20:06:55 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id BCE0DD788B; Tue, 7 Feb 2017 12:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=jOU8v6ZBAvPbtl+xZiGNGsoCG4s=; b= id8bWcgjCeedR41fu2d0c8Inq+V3XePcaJJCJHX94JbiWqurVopCAoQ4+uha+M/7 ITV8X7YLUSI77BlxzY4BXGRAAXaNq6sn06u1I7bc22CROJwW2E2FdIegs+Gc6pfM D0KgoF9JEXO/q/sqkBmjDlx0YhowllTB9LKzml46WYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=OqLXn/wzV+DhONXHo/wG+dn B1HalaZxtELShFeSmpkZ/PmZsE/JgIg77/KqV/9SCNYV+smyH61lbFYbPjoJ1f7+ B7FDd8d9ssOidLENTyzLPrYx8MVor8U4XBPg9ffRPPj6XzRsW1LAYacuk6w76ck/ TlhR6Y+lGJkvYEV08XvY= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 5C3DED788A; Tue, 7 Feb 2017 12:06:54 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5AE32865EDDD; Tue, 7 Feb 2017 21:06:52 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8956E3FC-51F0-4D13-B11D-5926009E0DE7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Date: Tue, 7 Feb 2017 21:06:51 +0100 In-Reply-To: <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> To: Joe Touch References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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: Tue, 07 Feb 2017 20:06:57 -0000 --Apple-Mail=_8956E3FC-51F0-4D13-B11D-5926009E0DE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Joe, [...] >>> If by "supports" you mean "doesn't work", then yes. That's why we = now >>> have PLPMTUD. >>>=20 >> PLMTUD is unfortunately not a (complete) replacement of PMTUD. >=20 > PLMTUD is a directive to protocols above the IP layer; it isn't a = single protocol, so it wouldn't replace anything. >=20 >>=20 >>>> Looking just at our specifications, we cannot state that PLMTUD can = replace PMTUD. Take RFC2473 (IPv6 tunnelling) for example. >>>>=20 >>> See draft-ietf-intarea-tunnels, esp. v03 Section 5.5.2 >>>=20 >>> (yes, that doc has expired while we're preparing the 04 update, = which >>> should be issued shortly) >>>=20 >> Is this the paragraph you are referring to? >>=20 >> PLPMTUD requires a separate, >> direct control channel from the egress to the ingress that = provides >> positive feedback; the direct channel is not blocked by policy >> filters and the positive feedback ensures fail-safe operation if >> feedback messages are lost [RFC4821]. >>=20 > That is nowhere near section 5.5.2. No, but it was unfortunately all that was written about how to use = PLMTUD for tunnels. > 5.5.2 indicates places where RFC2473 has errors, esp. in how it = interprets the MTU of the tunnel as being defined by the MTU of the path = within the tunnel, rather than by the tunnel egress reassembly limit. >=20 >> I'm very much in favour of working on better ways of doing Path MTU = discovery. >> A blanket statement of "use "PLMTUD" seems very premature though. >>=20 > The point is that this document fails to indicate the current state of = PMTUD. It correctly notes that: > An extension to Path MTU Discovery defined in this document can be > found in [ > RFC4821 > ]. It defines a method for Packetization Layer Path > MTU Discovery (PLPMTUD) designed for use over paths where delivery = of > ICMP messages to a host is not assured. >=20 >=20 >=20 > IMO, it fails to note that this case - where ICMP messages are assured = along a path - is effectively a unicorn except within systems maintained = by a single entity. >=20 >> RFC1981 has 70 citations: >>=20 >> http://www.arkko.com/tools/allstats/citations-rfc1981.html >>=20 >>=20 >> Could you expand on your view of how this pertains to advancing = RFC1981? >>=20 > It's called last call input. My input is that this document needs to = be more realistic in noting that, for all intents, ICMP-based MTU = discovery isn't viable and that other methods need to be *expected*, not = just that they're available. Right, but if you are correct that ICMP-based MTU discovery is not = viable then this document should not be advanced. At the same time for many protocols we have nothing else. An operator = can break any protocol if that's their policy. And that's the breakage = we're talking about here, not any issues with the protocol = specification. There is a philosophical aspect of this. (Which I'm not the best person = to represent as I skipped my University studies in philosophy and used = the student loan to buy a motorcycle... (and only read the art of = motorcycle maintenance years later) ) This is a tussle. The IETF specifies protocols under the assumption that = operators treat those protocols largely as specified. The 5-10% failure = of PMTUD messages may be caused by misconfiguration, misunderstanding or = mis-intent... Many of our protocols are suffering from the same fate. = Should the IETF adjust all its protocols to be as middlebox friendly as = possible? You can make this argument about IPv6 fragments, any packet = with IPv6 extension headers, IPv4 fragments. Or anything but TCP port = 443/80 and UDP port 53 for that matter. Are we as the IETF going to = continue standardising protocols to work as best as they possible can, = ignoring protocol abuse, or are we going to bend over and do whatever it = takes to make it work for those 5-10% who've actively broken the = protocol? What about the 90-90% where the protocols work as expected? Best regards, Ole --Apple-Mail=_8956E3FC-51F0-4D13-B11D-5926009E0DE7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYmijcAAoJEL7aWKiYQt92ZF0P+weSw/8C4j+v9IfLeQ6GKlWB QEJzVdY3VWWF+Wim2pLnshyYpkyiaZXG3uEh8aCAUQ5MX6nTbDE667XM4UOwl/5H KBIM/JjLKXs+Sa5b4y7cb60ogpRR0QNKo3ov1rsI+fhtOf3of8owSfZ9CeN8RlWT 8E8KHrJFodWmDKSyoODXO/MUriLqqb/tDGt00S436TTEzZvkQb/YZZmdzRALeajv WalhMXWvCfGkydWf0qYRzV60weH/xYhSOUCFbk+E1FlCObQqPf9eCL0ZbbqYfw1c PTal39THaLxNfAVAKMlHHknXqnaIigGB6eW7tifCukcrD0m8z7gNKt8mi3sKYjRK eNtQ3EjhcD7WFOa7BL1Xg+15D4B77boU8sxKTQJGDZP1L1qCg2FcIC3lfdcTfjL+ 4d+ppfj/Id4XRot8XI2kZPfZjNCHMIVAwvdgTvGbqgBjciO8wwFqzmkWSwdSSNdN oLp/svu3R6P/lzqojRo1xlnHMvXbS4stP/WfOWut/A6XpbOQ19IdPAS0LlFkIDhe 9eXi/vnVy0fFnQ9uyzGn0+vMqtRTS8IiaCT9KPN2Oy4eJr7mvigSbhitn2U8ygOD T1KFnURLt6EA2x0hw48iE1ArGKfTFGC2pOFHr3FkylcgTpUkjyvRjKUdzneQXMFF 7ROIZXRCkavFXLb6YTP6 =8K/j -----END PGP SIGNATURE----- --Apple-Mail=_8956E3FC-51F0-4D13-B11D-5926009E0DE7-- From nobody Tue Feb 7 12:15:01 2017 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 121C41294C7; Tue, 7 Feb 2017 12:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 NbOFWVzHs_w0; Tue, 7 Feb 2017 12:14:49 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 0EAE6129471; Tue, 7 Feb 2017 12:14:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v17KEmD7021247; Tue, 7 Feb 2017 13:14:48 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v17KEemE021141 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 7 Feb 2017 13:14:40 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 7 Feb 2017 12:14:39 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1178.000; Tue, 7 Feb 2017 12:14:39 -0800 From: "Templin, Fred L" To: "otroan@employees.org" , Joe Touch Subject: RE: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Topic: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Index: AQHSgX24aUQDcUzHwUaWWd7FFympqaFd+j3Q Date: Tue, 7 Feb 2017 20:14:39 +0000 Message-ID: <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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: Tue, 07 Feb 2017 20:14:51 -0000 Hi Ole and Joe, Also not to be lost in this discussion is the potential for spoofed ICMP me= ssages that would report a size that is either too large or too small. Thanks - Fred > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of otroan@employees.o= rg > Sent: Tuesday, February 07, 2017 12:07 PM > To: Joe Touch > Cc: 6man WG ; ietf@ietf.org; draft-ietf-6man-rfc1981bis@ie= tf.org; tsv-area@ietf.org; Eggert, Lars > ; 6man-chairs@ietf.org > Subject: Re: Last Call: (Path MTU Dis= covery for IP version 6) to Internet Standard >=20 > Joe, >=20 > [...] >=20 > >>> If by "supports" you mean "doesn't work", then yes. That's why we now > >>> have PLPMTUD. > >>> > >> PLMTUD is unfortunately not a (complete) replacement of PMTUD. > > > > PLMTUD is a directive to protocols above the IP layer; it isn't a singl= e protocol, so it wouldn't replace anything. > > > >> > >>>> Looking just at our specifications, we cannot state that PLMTUD can = replace PMTUD. Take RFC2473 (IPv6 tunnelling) for > example. > >>>> > >>> See draft-ietf-intarea-tunnels, esp. v03 Section 5.5.2 > >>> > >>> (yes, that doc has expired while we're preparing the 04 update, which > >>> should be issued shortly) > >>> > >> Is this the paragraph you are referring to? > >> > >> PLPMTUD requires a separate, > >> direct control channel from the egress to the ingress that provides > >> positive feedback; the direct channel is not blocked by policy > >> filters and the positive feedback ensures fail-safe operation if > >> feedback messages are lost [RFC4821]. > >> > > That is nowhere near section 5.5.2. >=20 > No, but it was unfortunately all that was written about how to use PLMTUD= for tunnels. >=20 > > 5.5.2 indicates places where RFC2473 has errors, esp. in how it interpr= ets the MTU of the tunnel as being defined by the MTU of the > path within the tunnel, rather than by the tunnel egress reassembly limit= . > > > >> I'm very much in favour of working on better ways of doing Path MTU di= scovery. > >> A blanket statement of "use "PLMTUD" seems very premature though. > >> > > The point is that this document fails to indicate the current state of = PMTUD. It correctly notes that: > > An extension to Path MTU Discovery defined in this document can be > > found in [ > > RFC4821 > > ]. It defines a method for Packetization Layer Path > > MTU Discovery (PLPMTUD) designed for use over paths where delivery o= f > > ICMP messages to a host is not assured. > > > > > > > > IMO, it fails to note that this case - where ICMP messages are assured = along a path - is effectively a unicorn except within systems > maintained by a single entity. > > > >> RFC1981 has 70 citations: > >> > >> http://www.arkko.com/tools/allstats/citations-rfc1981.html > >> > >> > >> Could you expand on your view of how this pertains to advancing RFC198= 1? > >> > > It's called last call input. My input is that this document needs to be= more realistic in noting that, for all intents, ICMP-based MTU > discovery isn't viable and that other methods need to be *expected*, not = just that they're available. >=20 > Right, but if you are correct that ICMP-based MTU discovery is not viable= then this document should not be advanced. > At the same time for many protocols we have nothing else. An operator can= break any protocol if that's their policy. And that's the > breakage we're talking about here, not any issues with the protocol speci= fication. >=20 > There is a philosophical aspect of this. (Which I'm not the best person t= o represent as I skipped my University studies in philosophy > and used the student loan to buy a motorcycle... (and only read the art o= f motorcycle maintenance years later) ) > This is a tussle. The IETF specifies protocols under the assumption that = operators treat those protocols largely as specified. The 5-10% > failure of PMTUD messages may be caused by misconfiguration, misunderstan= ding or mis-intent... Many of our protocols are suffering > from the same fate. Should the IETF adjust all its protocols to be as mid= dlebox friendly as possible? You can make this argument about > IPv6 fragments, any packet with IPv6 extension headers, IPv4 fragments. O= r anything but TCP port 443/80 and UDP port 53 for that > matter. Are we as the IETF going to continue standardising protocols to w= ork as best as they possible can, ignoring protocol abuse, or > are we going to bend over and do whatever it takes to make it work for th= ose 5-10% who've actively broken the protocol? What about > the 90-90% where the protocols work as expected? >=20 > Best regards, > Ole >=20 From nobody Tue Feb 7 12:19:10 2017 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 B37A6129E9B; Tue, 7 Feb 2017 12:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 DlnGh4kQ3RFE; Tue, 7 Feb 2017 12:19:03 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 30A39129579; Tue, 7 Feb 2017 12:19:03 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v17KIEFX013871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Feb 2017 12:18:15 -0800 (PST) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: otroan@employees.org References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> From: Joe Touch Message-ID: Date: Tue, 7 Feb 2017 12:18:16 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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: Tue, 07 Feb 2017 20:19:05 -0000 On 2/7/2017 12:06 PM, otroan@employees.org wrote: > Joe, ... >>> I'm very much in favour of working on better ways of doing Path MTU discovery. >>> A blanket statement of "use "PLMTUD" seems very premature though. >>> >> The point is that this document fails to indicate the current state of PMTUD. It correctly notes that: >> An extension to Path MTU Discovery defined in this document can be >> found in [ >> RFC4821 >> ]. It defines a method for Packetization Layer Path >> MTU Discovery (PLPMTUD) designed for use over paths where delivery of >> ICMP messages to a host is not assured. >> >> >> >> IMO, it fails to note that this case - where ICMP messages are assured along a path - is effectively a unicorn except within systems maintained by a single entity. >> >>> RFC1981 has 70 citations: >>> >>> http://www.arkko.com/tools/allstats/citations-rfc1981.html >>> >>> >>> Could you expand on your view of how this pertains to advancing RFC1981? >>> >> It's called last call input. My input is that this document needs to be more realistic in noting that, for all intents, ICMP-based MTU discovery isn't viable and that other methods need to be *expected*, not just that they're available. > Right, but if you are correct that ICMP-based MTU discovery is not viable then this document should not be advanced. Not necessarily. It's fine to update a protocol that works inside an enterprise or other controlled environment. > At the same time for many protocols we have nothing else. An operator can break any protocol if that's their policy. And that's the breakage we're talking about here, not any issues with the protocol specification. Well, it's a problem with the protocol spec that it's susceptible to operator interference. > There is a philosophical aspect of this. (Which I'm not the best person to represent as I skipped my University studies in philosophy and used the student loan to buy a motorcycle... (and only read the art of motorcycle maintenance years later) ) > This is a tussle. The IETF specifies protocols under the assumption that operators treat those protocols largely as specified. The 5-10% failure of PMTUD messages may be caused by misconfiguration, misunderstanding or mis-intent... Many of our protocols are suffering from the same fate. Should the IETF adjust all its protocols to be as middlebox friendly as possible? You can make this argument about IPv6 fragments, any packet with IPv6 extension headers, IPv4 fragments. Or anything but TCP port 443/80 and UDP port 53 for that matter. Are we as the IETF going to continue standardising protocols to work as best as they possible can, ignoring protocol abuse, or are we going to bend over and do whatever it takes to make it work for those 5-10% who've actively broken the protocol? What about the 90-90% where the protocols work as expected? What I'm suggesting is a lot simpler - just text that makes it clear what the current state of deployment of support (or interference) for this protocol is. I appreciate that you want to not point at PLPMTUD because it's not widely supported, but **for the same reason** this doc should not hold up this solution without pointing out very clearly that it basically isn't going to be work. Joe From nobody Tue Feb 7 12:32:47 2017 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 CB82B129EC6; Tue, 7 Feb 2017 12:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 k4BFpy0xdoEt; Tue, 7 Feb 2017 12:32:36 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 68CBF129EC5; Tue, 7 Feb 2017 12:32:36 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 07 Feb 2017 20:32:36 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 0B2ECD788B; Tue, 7 Feb 2017 12:32:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=D/LEo8f7CoVmbcDEvo5/bqRlz3g=; b= agphqJRgFLQaiXi5HXAMDMVt6DtNZwKUN6o5FMk8Ej3C9H0odFWWkV0W9WrcXBW9 glSBHfOLKGndPj0nGE8cOabnRy+rMJqQr6c9zJeCWVUFf6crkkuOVvBc092QvgaQ 262Mp9T6WJE35AFTLMfpvvxK+96lVPG3KQVULXGUhSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=CCsqhv+DU4LKOWSjOkdyYll h9FPMBOKi6QArpwBmvxALODee8ud3DWmkd6i0vZRxZ/K8XkKv3AR/aIElaeLmoTR ItxskdkaILykSElHBiGz/pEvqBXGArVQ5A6lfH6Eg9YZsHV0iW/qWpMzvNDezHjB MKmujOby5DvqdK4gaMTI= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id CAC03D788A; Tue, 7 Feb 2017 12:32:35 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id DFC6C865F294; Tue, 7 Feb 2017 21:32:33 +0100 (CET) From: otroan@employees.org Message-Id: <4118C6CE-7649-436B-9598-78A034AFFE50@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_1D7F7009-AABF-47BD-9E9B-7082F79C9295"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Date: Tue, 7 Feb 2017 21:32:33 +0100 In-Reply-To: To: Joe Touch References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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: Tue, 07 Feb 2017 20:32:38 -0000 --Apple-Mail=_1D7F7009-AABF-47BD-9E9B-7082F79C9295 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Joe, Thanks! > I appreciate that you want to not point at PLPMTUD because it's not > widely supported, but **for the same reason** this doc should not hold > up this solution without pointing out very clearly that it basically > isn't going to be work. Would something like this help? (borrowed from https://en.wikipedia.org/wiki/Path_MTU_Discovery) "Many network security devices block all ICMP messages for perceived security benefits, including the errors that are necessary for the proper operation of PMTUD. This can result in connections that complete the TCP three-way handshake correctly, but then hang when data is transferred. This state is referred to as a black hole connection." Best regards, Ole --Apple-Mail=_1D7F7009-AABF-47BD-9E9B-7082F79C9295 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYmi7hAAoJEL7aWKiYQt92x8IP/A3kfnv47podTO7Zrm/Kb7Su 1X6XK32mzxnhLRGFz71LcTnZDy1LOade9oEADD0GJufcgRyAPkv2LuacW7ALFhwf P20aL262tXPySDS2k7rZFFIGmMxNqy9AVNvDrRfQxRnpAbi5nPtuKGUTzFP9AXOj 0AWHzNyU84ItR2rNTGnVQqfazLa/trNbgruFk9KLxuhDC6GuZIWadJFhr6cC2p/S zd9/+k7iF3sz/zO2JwVcbm0TMjrNORYQ3aCjztz3hmH26innZ6lQOuT5tTBllP3B irk+FHM8LrLeQfhciFi/8N4kWOPdlqObzz3M/S/SF2vo0Hmdk5dQ8P71WzmgjQIY MahDzHTfwc173+jda/me1hgFieIBM+ztd4gN9m5P4LL7mO4j5Gdz47urbIfrS2/Z Mg3P77+NZz2QvT/BusEOAwVvfcspoSjjhR2tKCBrIn132mtnuyXp3X84XlXDlOoq swqs6TPCnPh/wUvksN0JWJdSSblQ/N3uQinWdHIAWRxwei9gyKQnTH+HrPVTV5jf 3sHu41ui5UlDS7W8PqgXn6J9Hm7m9lTbrgFZC3wyyRiz+Ylyclyj45zoeZ7IvYm/ rstjguXIHjbhDILQ4rDsGL29AmWVRU1nK07e+Iz1GtfIx5gcu3Gc8psq77Ofs7eS dYCs+1J0d1xWHl5Vkxya =Xw+/ -----END PGP SIGNATURE----- --Apple-Mail=_1D7F7009-AABF-47BD-9E9B-7082F79C9295-- From nobody Tue Feb 7 13:25:01 2017 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 BA669129499; Tue, 7 Feb 2017 13:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 aVChaKyucpBN; Tue, 7 Feb 2017 13:24:51 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 702EA128874; Tue, 7 Feb 2017 13:24:51 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v17LOMfc024098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Feb 2017 13:24:23 -0800 (PST) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: otroan@employees.org References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <4118C6CE-7649-436B-9598-78A034AFFE50@employees.org> From: Joe Touch Message-ID: <1d3c4a88-8c50-a0e2-f852-798d671c8750@isi.edu> Date: Tue, 7 Feb 2017 13:24:23 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <4118C6CE-7649-436B-9598-78A034AFFE50@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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: Tue, 07 Feb 2017 21:24:53 -0000 I'd add one sentence about Fred's observation too: In addition, spoofed ICMP messages can also affect the correct operation of PMTUD. That'd do it... Joe On 2/7/2017 12:32 PM, otroan@employees.org wrote: > Joe, > > Thanks! > >> I appreciate that you want to not point at PLPMTUD because it's not >> widely supported, but **for the same reason** this doc should not hold >> up this solution without pointing out very clearly that it basically >> isn't going to be work. > Would something like this help? > (borrowed from https://en.wikipedia.org/wiki/Path_MTU_Discovery) > > "Many network security devices block all ICMP messages for perceived > security benefits, including the errors that are necessary for the proper > operation of PMTUD. This can result in connections that complete the > TCP three-way handshake correctly, but then hang when data is transferred. > This state is referred to as a black hole connection." > > > Best regards, > Ole From nobody Tue Feb 7 13:32:03 2017 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 418091293FB; Tue, 7 Feb 2017 13:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 sDgrZf4mKko1; Tue, 7 Feb 2017 13:32:00 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id CB9641288B8; Tue, 7 Feb 2017 13:32:00 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 07 Feb 2017 21:32:00 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 6CE45D788B; Tue, 7 Feb 2017 13:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=y0h/ZAObWEk7n7caOQxPMGUOjRM=; b= PyaC00YtHZIQabGP53V5drCgx9NFjQ9Ef9yE9Dek/9a/s32QVWYSM6ppVsgd6tvl /RmwB305g1qvccAYA9tk8ga06tRaVrucYeUHk+7u3Df4RM9io4pn1uMIaOkPRLzG AsL8E+xziUxwj5hcINok8Yf8VEfuXGuoWyBmnbgc72Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=bKKoZ45I4rRDG+DShY8C36/ 82XNQ79UhQi9hdzZruBvaivK9IZ/L+HazRYgynWY166R4QvbSnU4nF6sMZ/GjIHZ rTb7jYkGkx1WLj9FxU1smxN0ZXA8C6UtvUtkUCvHY2r0j6KrBAtlNUuEiXKNccAR tQjxKLyt0OeFVAVgJL/g= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id EAE0BD788A; Tue, 7 Feb 2017 13:31:59 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id CF2148662B88; Tue, 7 Feb 2017 22:31:57 +0100 (CET) From: otroan@employees.org Message-Id: <931F16A4-BF00-4695-857E-F90703A09D32@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_B28B8140-75C7-4779-B2FF-EC5A0E59E649"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Date: Tue, 7 Feb 2017 22:31:57 +0100 In-Reply-To: <1d3c4a88-8c50-a0e2-f852-798d671c8750@isi.edu> To: Joe Touch References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <4118C6CE-7649-436B-9598-78A034AFFE50@employees.org> <1d3c4a88-8c50-a0e2-f852-798d671c8750@isi.edu> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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: Tue, 07 Feb 2017 21:32:02 -0000 --Apple-Mail=_B28B8140-75C7-4779-B2FF-EC5A0E59E649 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Thanks Joe. > I'd add one sentence about Fred's observation too: > > In addition, spoofed ICMP messages can also affect the correct operation > of PMTUD. You don't think that's covered by the existing security considerations: This Path MTU Discovery mechanism makes possible two denial-of- service attacks, both based on a malicious party sending false Packet Too Big messages to a node. In the first attack, the false message indicates a PMTU much smaller than reality. This should not entirely stop data flow, since the victim node should never set its PMTU estimate below the IPv6 minimum link MTU. It will, however, result in suboptimal performance. In the second attack, the false message indicates a PMTU larger than reality. If believed, this could cause temporary blockage as the victim sends packets that will be dropped by some router. Within one round-trip time, the node would discover its mistake (receiving Packet Too Big messages from that router), but frequent repetition of this attack could cause lots of packets to be dropped. A node, however, should never raise its estimate of the PMTU based on a Packet Too Big message, so should not be vulnerable to this attack. Best regards, Ole --Apple-Mail=_B28B8140-75C7-4779-B2FF-EC5A0E59E649 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYmjzNAAoJEL7aWKiYQt927zwP/1gxyQ01UAmpJwhw8CVunvgs YH9ZLQLvty44pjEcgWmSrnTXDFvAkjLFYfAaFRMg+bQTW5peD7eUZzU10p4dhekW j+XlbUurRzwDFixudIcRCXOCU2Ntm9DsqSIz22pvseSdykNHUiZKFAz+zbq2QZry dciIHoo0xOvHkjKdJ9miQ4/hou/B4ovhXs3JIa2e2m2jKDPdY4wfY7r44BxUgVPC ImOtNZS9J7J2rw305uCQBlpu6m9SWn88CRjuJfCmD4n7OvrqyKjM4BxFFAKY5LXC Y1a6AtANk7uCLc6y7VISRPdBkzG4KQDSpgWoEdd1ZjNgud05Lnh3/i3NkVM+jFmj i3G87b9mwPQ3HjJfiyYhGx37LEIUHPdX1y4afQyaATTzquF75uVx0F6oL0SmUqef rN0euHdZRNGgMMfzteVd9wAp/rPSooP9Q502cUEvHSBYjbErtcE/O1HkeZwk5hsk 5aaaYcY7rif7apv7eV7dF0pqCeKIAVpY/Xfc6SNb78t0CQO/LlmnQfmhjkaeF8jA 6k4+BDQSbi6K1VIMxazxBbnzBO0jKxQmfiXm11RoYc5raxl5t+LBvBsC3xmyDZiA lBo5dJgBxTrufDgbGKyaY3ToK6yIBI1awqp1EkZmqOkXVZgpbdEihmciChScRpQt 7PTj55tS6I8ObK+c4aH8 =hwP4 -----END PGP SIGNATURE----- --Apple-Mail=_B28B8140-75C7-4779-B2FF-EC5A0E59E649-- From nobody Tue Feb 7 13:36:53 2017 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 E61851294A4; Tue, 7 Feb 2017 13:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 VyLeFauxzLVD; Tue, 7 Feb 2017 13:36:42 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 2630212955E; Tue, 7 Feb 2017 13:36:42 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v17LZpE1025700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Feb 2017 13:35:52 -0800 (PST) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: otroan@employees.org References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <4118C6CE-7649-436B-9598-78A034AFFE50@employees.org> <1d3c4a88-8c50-a0e2-f852-798d671c8750@isi.edu> <931F16A4-BF00-4695-857E-F90703A09D32@employees.org> From: Joe Touch Message-ID: <4673f71e-11d9-699e-7a15-1d1fd095a6e8@isi.edu> Date: Tue, 7 Feb 2017 13:35:50 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <931F16A4-BF00-4695-857E-F90703A09D32@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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: Tue, 07 Feb 2017 21:36:44 -0000 IMO it's worth including a sentence that highlights these things elsewhere in the doc. But if others disagree, the existing text is sufficient. Joe On 2/7/2017 1:31 PM, otroan@employees.org wrote: > Thanks Joe. > >> I'd add one sentence about Fred's observation too: >> >> In addition, spoofed ICMP messages can also affect the correct operation >> of PMTUD. > You don't think that's covered by the existing security considerations: > > This Path MTU Discovery mechanism makes possible two denial-of- > service attacks, both based on a malicious party sending false Packet > Too Big messages to a node. > > In the first attack, the false message indicates a PMTU much smaller > than reality. This should not entirely stop data flow, since the > victim node should never set its PMTU estimate below the IPv6 minimum > link MTU. It will, however, result in suboptimal performance. > > In the second attack, the false message indicates a PMTU larger than > reality. If believed, this could cause temporary blockage as the > victim sends packets that will be dropped by some router. Within one > round-trip time, the node would discover its mistake (receiving > Packet Too Big messages from that router), but frequent repetition of > this attack could cause lots of packets to be dropped. A node, > however, should never raise its estimate of the PMTU based on a > Packet Too Big message, so should not be vulnerable to this attack. > > Best regards, > Ole > From nobody Tue Feb 7 16:56:29 2017 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 ACEC81296F3; Tue, 7 Feb 2017 16:56:27 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ySTkG-tXHUFN; Tue, 7 Feb 2017 16:56:26 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9831296F0; Tue, 7 Feb 2017 16:56:25 -0800 (PST) Received: from [192.168.3.83] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B394A80371; Wed, 8 Feb 2017 01:56:20 +0100 (CET) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: "Templin, Fred L" , "otroan@employees.org" , Joe Touch References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> From: Fernando Gont Message-ID: Date: Tue, 7 Feb 2017 21:45:55 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@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: Wed, 08 Feb 2017 00:56:28 -0000 On 02/07/2017 05:14 PM, Templin, Fred L wrote: > Hi Ole and Joe, > > Also not to be lost in this discussion is the potential for spoofed ICMP messages > that would report a size that is either too large or too small. RFC5927 is all about this. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 7 16:56:50 2017 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 AA3241296F0; Tue, 7 Feb 2017 16:56:41 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 nX10ZA7xyeG8; Tue, 7 Feb 2017 16:56:40 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C7C12971E; Tue, 7 Feb 2017 16:56:38 -0800 (PST) Received: from [192.168.3.83] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id EDD39828F9; Wed, 8 Feb 2017 01:56:33 +0100 (CET) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: Joe Touch , otroan@employees.org References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <4118C6CE-7649-436B-9598-78A034AFFE50@employees.org> <1d3c4a88-8c50-a0e2-f852-798d671c8750@isi.edu> <931F16A4-BF00-4695-857E-F90703A09D32@employees.org> <4673f71e-11d9-699e-7a15-1d1fd095a6e8@isi.edu> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 7 Feb 2017 21:52:32 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <4673f71e-11d9-699e-7a15-1d1fd095a6e8@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@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: Wed, 08 Feb 2017 00:56:42 -0000 Hi, Joe, On 02/07/2017 06:35 PM, Joe Touch wrote: > IMO it's worth including a sentence that highlights these things > elsewhere in the doc. > > But if others disagree, the existing text is sufficient. The text is actually incorrect (see below). >>> I'd add one sentence about Fred's observation too: >>> >>> In addition, spoofed ICMP messages can also affect the correct operation >>> of PMTUD. >> You don't think that's covered by the existing security considerations: >> >> This Path MTU Discovery mechanism makes possible two denial-of- >> service attacks, both based on a malicious party sending false Packet >> Too Big messages to a node. >> >> In the first attack, the false message indicates a PMTU much smaller >> than reality. This should not entirely stop data flow, since the >> victim node should never set its PMTU estimate below the IPv6 minimum >> link MTU. It will, however, result in suboptimal performance. If you are employing EHs this could indeed stop the data flow. >> In the second attack, the false message indicates a PMTU larger than >> reality. If believed, this could cause temporary blockage as the >> victim sends packets that will be dropped by some router. Within one >> round-trip time, the node would discover its mistake (receiving >> Packet Too Big messages from that router), but frequent repetition of >> this attack could cause lots of packets to be dropped. A node, >> however, should never raise its estimate of the PMTU based on a >> Packet Too Big message, so should not be vulnerable to this attack. This one is probably not worth elaborating: at the end of the day, it doesn't work. There are many other things to note here, e.g.: * many stacks don't even check that the ICMPv6 PTB referes to e.g. an ongoing TCP connection * Some stacks cache the PMTU for all packets sent to the target IPv6 address (i.e., the attack might affect multiple flows) etc. Much of this is covered in RFC5927. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Feb 8 05:36:40 2017 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 6715D129A4F; Wed, 8 Feb 2017 05:36:31 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 tBLFKVG927mS; Wed, 8 Feb 2017 05:36:28 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FA9129536; Wed, 8 Feb 2017 05:36:28 -0800 (PST) Received: from [192.168.3.83] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 949CC80F86; Wed, 8 Feb 2017 14:36:21 +0100 (CET) From: Fernando Gont Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: otroan@employees.org, Joe Touch References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> X-Enigmail-Draft-Status: N1110 Message-ID: Date: Wed, 8 Feb 2017 10:07:02 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" , Randy Bush , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@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: Wed, 08 Feb 2017 13:36:31 -0000 On 02/07/2017 05:06 PM, otroan@employees.org wrote: > >>> Could you expand on your view of how this pertains to advancing >>> RFC1981? >>> >> It's called last call input. My input is that this document needs >> to be more realistic in noting that, for all intents, ICMP-based >> MTU discovery isn't viable and that other methods need to be >> *expected*, not just that they're available. > > Right, but if you are correct that ICMP-based MTU discovery is not > viable then this document should not be advanced. At the same time > for many protocols we have nothing else. An operator can break any > protocol if that's their policy. And that's the breakage we're > talking about here, not any issues with the protocol specification. > > There is a philosophical aspect of this. (Which I'm not the best > person to represent as I skipped my University studies in philosophy > and used the student loan to buy a motorcycle... (and only read the > art of motorcycle maintenance years later) ) This is a tussle. The > IETF specifies protocols under the assumption that operators treat > those protocols largely as specified. The 5-10% failure of PMTUD > messages may be caused by misconfiguration, misunderstanding or > mis-intent... Many of our protocols are suffering from the same fate. > Should the IETF adjust all its protocols to be as middlebox friendly > as possible? You can make this argument about IPv6 fragments, any > packet with IPv6 extension headers, IPv4 fragments. Or anything but > TCP port 443/80 and UDP port 53 for that matter. Are we as the IETF > going to continue standardising protocols to work as best as they > possible can, ignoring protocol abuse, or are we going to bend over > and do whatever it takes to make it work for those 5-10% who've > actively broken the protocol? What about the 90-90% where the > protocols work as expected? There are two things to note here: 1) the folk breaking PMTUD is probably not the guy suffering from that breakage. So the had that "bad-hevaed" nodes hurt the "well behaved" nodes (i.e., you cannot claim "you're shooting your own foot). 2) Being an engineering group I would expect our protocols to work in the real world -- that's the point of engineering: solving problems. At the end of the day, you can build stuff that works, or complain that way too many people are doing dumb things (for some meaning of "dumb"). -- But the later will not make protocols work, nor solve problems. In that sense, I agree with Joe, and Randy Bush here. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Feb 8 08:36:11 2017 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 6E846129C59; Wed, 8 Feb 2017 08:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-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 FQmjFAujUIl5; Wed, 8 Feb 2017 08:36:05 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 3B9D8129C58; Wed, 8 Feb 2017 08:36:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v18Ga4GR019862; Wed, 8 Feb 2017 09:36:04 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v18GZxLE019407 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 8 Feb 2017 09:35:59 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 8 Feb 2017 08:35:58 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1178.000; Wed, 8 Feb 2017 08:35:58 -0800 From: "Templin, Fred L" To: Fernando Gont , "otroan@employees.org" , Joe Touch Subject: RE: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Topic: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Thread-Index: AQHSgX24aUQDcUzHwUaWWd7FFympqaFd+j3QgADSTICAAIH0gA== Date: Wed, 8 Feb 2017 16:35:58 +0000 Message-ID: <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@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: Wed, 08 Feb 2017 16:36:06 -0000 Hi Fernando, > -----Original Message----- > From: Fernando Gont [mailto:fgont@si6networks.com] > Sent: Tuesday, February 07, 2017 4:46 PM > To: Templin, Fred L ; otroan@employees.org; Jo= e Touch > Cc: 6man WG ; ietf@ietf.org; draft-ietf-6man-rfc1981bis@ie= tf.org; tsv-area@ietf.org; 6man-chairs@ietf.org > Subject: Re: Last Call: (Path MTU Dis= covery for IP version 6) to Internet Standard >=20 > On 02/07/2017 05:14 PM, Templin, Fred L wrote: > > Hi Ole and Joe, > > > > Also not to be lost in this discussion is the potential for spoofed ICM= P messages > > that would report a size that is either too large or too small. >=20 > RFC5927 is all about this. Right. The point is that these data points would seem to indicate that stan= dard PMTUD per rfc1981bis is not reliable nor secure enough for operation on ope= n internetworks such as the global public Internet. Maybe the security sectio= n should say that? Thanks - Fred fred.l.templin@boeing.com > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From nobody Thu Feb 9 13:09:40 2017 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 741F5126D74; Thu, 9 Feb 2017 13:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 e3-kY8sjw7ym; Thu, 9 Feb 2017 13:09:32 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060471295BF; Thu, 9 Feb 2017 13:09:32 -0800 (PST) Received: from [192.168.3.83] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 05B9B80F4F; Thu, 9 Feb 2017 22:09:24 +0100 (CET) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: "Templin, Fred L" , "otroan@employees.org" , Joe Touch References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Wed, 8 Feb 2017 19:35:50 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@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: Thu, 09 Feb 2017 21:09:33 -0000 Hi, Fred, On 02/08/2017 01:35 PM, Templin, Fred L wrote: >>> >>> Also not to be lost in this discussion is the potential for spoofed ICMP messages >>> that would report a size that is either too large or too small. >> >> RFC5927 is all about this. > > Right. The point is that these data points would seem to indicate that standard > PMTUD per rfc1981bis is not reliable nor secure enough for operation on open > internetworks such as the global public Internet. Maybe the security section > should say that? PMTUD as per rfc1981bis is certainly not reliable, since ICMPv6 messages are not reliable (actually, ICMP itself is obviously unreliable, but the widespread filtering of ICMPv6 messages results in more deterministic failures) "security"-wise, you can improve things to a decent level. e.g., for TCP based traffic all IPv6 implentations check the TCP sequence number (and por numbers) in the embedded packet. Besides, if you look at RFC5927, there a PMTUD-specific mitigation which essentially means that during the life of a connection, upon receipt of an ICMP PTB, you save the message, but only honor the message if there's not progress on the connection. -- somehow mimicking RFC4821. So I'd say that the issue with PMTUD is mostly reliability than security. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Feb 15 00:22:48 2017 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 7BF481294CD; Wed, 15 Feb 2017 00:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, 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 f41AFD9NQ-zU; Wed, 15 Feb 2017 00:22:33 -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 602F5129446; Wed, 15 Feb 2017 00:22:33 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 2939D1B001C9; Wed, 15 Feb 2017 10:19:51 +0000 (GMT) Message-ID: <58A33D08.4090505@erg.abdn.ac.uk> Date: Tue, 14 Feb 2017 18:23:20 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG , "draft-ietf-6man-rfc1981bis@ietf.org" , "tsv-area@ietf.org" , "ietf@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org> X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 08:22:36 -0000 I have some late transport comments on this ID. The update seems to retain a lot of thinking that is really historical and I'd really encourage people to look again to making the document uptodate. Detailed comments follow. Best wishes, Gorry ---- The following text strikes me as a little odd in an update: " Moreover, TCP implementations that follow the "slow- start" congestion-avoidance algorithm [CONG] typically calculate and cache several other values derived from the PMTU. It may be simpler to receive asynchronous notification when the PMTU changes, so that these variables may be updated.” - A modern TCP caches at least some path information in the TCB, why start with this clause at all: "Moreover, TCP implementations that follow the "slow start" congestion-avoidance algorithm [CONG] typically calculate and” and simply replace this with something like: "TCP implementations”? —--- The following text also seems to not reflect a modern TCP stack: " It is sufficient to treat this as any other dropped segment, and wait until the retransmission timer expires to cause retransmission of the segment.” (and following 3 paras). Could this be replaced by text that does not exclude modern retransmission methods: " It is sufficient to treat this in the same way as any other dropped segment, and will be recovered by normal retransmission methods." — There is a block of text that describes retransmission triggered by ICMPv6. Has this code been implemented in modern releases of TCP?: " Alternatively, the retransmission could be done in immediate response to a notification that the Path MTU has changed, but only for the specific connection specified by the Packet Too Big message.” - It seems to expose a number of attack vectors that really should not be exposed!! --- The discussion of NFS may still be a reasonable historic example, but to be current it should really refer also to NFSv4/TCP as utlising the MTU discovery provided by TCP, since UDP-based NFS is no longer a key application. --- There is no mention that paths including tunnels can eat ICMPv6 PTB messages on the tunnel segment, blackholing them, which prevents reaching the destination. --- I think the security consideration is naive! This statement in particular seems to open DOS vulnerability: " When a node receives a Packet Too Big message, it MUST reduce its estimate of the PMTU for the relevant path, based on the value of the MTU field in the message." - Introdueces a significant vulnerability. A rogue PTB message that reduces the PMTU to a minimum, can result in a path too small to carry an encapsulated packet. (Recently noted by Fernando Gont). Moreover, other layers view ICMP messages with suspicion and have long noted the need to check ICMP payload and match only packets that relate to actual 5-tuples in use (effectively reducing vulnerability to off-path attacks). For example, the Guidelines for UDP, rfc5405bis, state: " Applications SHOULD appropriately validate the payload of ICMP messages to ensure these are received in response to transmitted traffic (i.e., a reported error condition that corresponds to a UDP datagram actually sent by the application). …“ - clearly handling this in IP-layer tunnels can be troublesome, but that's a problem that should be described, not obscured. —— I’d finally like to add my concerns about the understatement of the value of PLPMTUD, which seems to not reflect the recommendations to use this method: “ It defines a method for Packetization Layer Path MTU Discovery (PLPMTUD) designed for use over paths where delivery of ICMP messages to a host is not assured.” This seems under-stating the value and recommendations to deploy PLMTUD, compared with current transport-area recommendations, for instance, the UDP Guidelines provide much more on this important design consideration: " Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not rely upon network support for ICMP messages and is therefore considered more robust than standard PMTUD. It is not susceptible to "black holing" of ICMP message. To operate, PLPMTUD requires changes to the way the transport is used, both to transmit probe packets, and to account for the loss or success of these probes. This updates not only the PMTU algorithm, it also impacts loss recovery, congestion control, etc. These updated mechanisms can be implemented within a connection-oriented transport (e.g., TCP, SCTP, DCCP), but are not a part of UDP, but this type of feedback is not typically present for unidirectional applications." ---- The examples used in the definition of "upper layer" and "link" also makes this document appear as historic, rather than a new RFC! From nobody Wed Feb 15 13:26:39 2017 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 0DC0D129556; Wed, 15 Feb 2017 13:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 crYJjuRxfOya; Wed, 15 Feb 2017 13:26:27 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 2BCEF129849; Wed, 15 Feb 2017 13:26:27 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1FLP4gL012163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Feb 2017 13:25:05 -0800 (PST) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: gorry@erg.abdn.ac.uk References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> From: Joe Touch Message-ID: <196e8c39-784a-3a25-b6ab-d7eaa664f0fa@isi.edu> Date: Wed, 15 Feb 2017 13:25:03 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <58A33D08.4090505@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@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: Wed, 15 Feb 2017 21:26:28 -0000 Hi, Gorry (et al.), On 2/14/2017 9:23 AM, Gorry Fairhurst wrote: > There is no mention that paths including tunnels can eat ICMPv6 PTB > messages on the tunnel segment, blackholing them, which prevents > reaching the destination. Nor should there be, IMO. A tunnel is a link layer to the network whose packets it transits. ICMPs generated inside a tunnel aren't "eaten", so much as they operate at a different layer for a different reason (e.g., to tune ingress-egress source fragmentation of encapsulated packets). PTB messages inside a tunnel are (IMO) most correctly interpreted by the ingress (which is an *interface* on a router or host, most correctly IMO) as changing the MTU of the tunnel as a link. If that MTU change affects packets that arrive later, then it would be the router where the ingress is attached that would generate the ICMP, never the (ingress) interface whose MTU is insufficient. Again, I'm in the process of updating draft-ietf-intarea-tunnels to be much more clear on this point (the update should be issued in a day or two). Joe From nobody Wed Feb 15 13:27:19 2017 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 9905B129BA5; Wed, 15 Feb 2017 13:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 r2EkeM5iOPLs; Wed, 15 Feb 2017 13:27:08 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 D2602129BA8; Wed, 15 Feb 2017 13:27:02 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1FLQOct012415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Feb 2017 13:26:24 -0800 (PST) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: gorry@erg.abdn.ac.uk References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> From: Joe Touch Message-ID: Date: Wed, 15 Feb 2017 13:26:22 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <58A33D08.4090505@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@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: Wed, 15 Feb 2017 21:27:09 -0000 Hi, Gorry (et al.), Again, the following text should not drift into discussing how tunnels are handled IMO. That should be addressed in a different document (and I don't think it's troublesome at all if viewed correctly). Joe On 2/14/2017 9:23 AM, Gorry Fairhurst wrote: > - Introdueces a significant vulnerability. A rogue PTB message that > reduces the PMTU to a minimum, can result in a path too small to carry > an encapsulated packet. (Recently noted by Fernando Gont). > > Moreover, other layers view ICMP messages with suspicion and have long > noted the need to check ICMP payload and match only packets that > relate to actual 5-tuples in use (effectively reducing vulnerability > to off-path attacks). For example, the Guidelines for UDP, rfc5405bis, > state: > > " Applications SHOULD appropriately validate the payload of ICMP > messages to ensure these are received in response to transmitted > traffic (i.e., a reported error condition that corresponds to a UDP > datagram actually sent by the application). …“ > - clearly handling this in IP-layer tunnels can be troublesome, but > that's a problem that should be described, not obscured. From nobody Thu Feb 16 06:04:39 2017 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 DCD161295F9; Thu, 16 Feb 2017 06:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 iZZZls4XwHuD; Thu, 16 Feb 2017 06:04:32 -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 056501295E3; Thu, 16 Feb 2017 06:04:32 -0800 (PST) Received: from dhcp-207-155.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:b82b:6073:afb4:ddb0]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 701411B00055; Thu, 16 Feb 2017 16:02:18 +0000 (GMT) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> <196e8c39-784a-3a25-b6ab-d7eaa664f0fa@isi.edu> To: Joe Touch From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <8fbc3cbd-ff2d-f2c6-ccd7-13a20c6aa5ca@erg.abdn.ac.uk> Date: Thu, 16 Feb 2017 14:04:28 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <196e8c39-784a-3a25-b6ab-d7eaa664f0fa@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:04:34 -0000 On 15/02/2017 21:25, Joe Touch wrote: > Hi, Gorry (et al.), > > On 2/14/2017 9:23 AM, Gorry Fairhurst wrote: >> There is no mention that paths including tunnels can eat ICMPv6 PTB >> messages on the tunnel segment, blackholing them, which prevents >> reaching the destination. > > Nor should there be, IMO. > > A tunnel is a link layer to the network whose packets it transits. > > ICMPs generated inside a tunnel aren't "eaten", so much as they operate > at a different layer for a different reason (e.g., to tune > ingress-egress source fragmentation of encapsulated packets). > > PTB messages inside a tunnel are (IMO) most correctly interpreted by the > ingress (which is an *interface* on a router or host, most correctly > IMO) as changing the MTU of the tunnel as a link. If that MTU change > affects packets that arrive later, then it would be the router where the > ingress is attached that would generate the ICMP, never the (ingress) > interface whose MTU is insufficient. > > Again, I'm in the process of updating draft-ietf-intarea-tunnels to be > much more clear on this point (the update should be issued in a day or two). > > Joe > I really disagree Joe - not in what you say about how things need to be, nor the relevance of draft-ietf-intarea-tunnels. The point of disagreement, is that I think the text needs to explain enough that people do NOT blindly believe this always works. the current text mentions tunnels in more than one place, as if they are just another usage of PMTUD. Tunnels can make path MTU diiscovery unreliable, because many deployed tunnel ingresses do not propagate ICMPv6 PTB messages upstream to reflect the limits of the Tunnel MTU. draft-ietf-intarea-tunnels discusses how a tunnel should be implemented to effectively work with a Tunnel MTU. Gorry From nobody Thu Feb 16 06:08:50 2017 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 BC3431299D7; Thu, 16 Feb 2017 06:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 nmP7_RlAtJoB; Thu, 16 Feb 2017 06:08:38 -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 BD0B81299BB; Thu, 16 Feb 2017 06:08:38 -0800 (PST) Received: from dhcp-207-155.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:b82b:6073:afb4:ddb0]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 05FDF1B00055; Thu, 16 Feb 2017 16:06:28 +0000 (GMT) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> To: Joe Touch From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <2fc3beb1-86d1-2436-71e1-a90c525cb0d6@erg.abdn.ac.uk> Date: Thu, 16 Feb 2017 14:08:37 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:08:40 -0000 The text below is not about tunnels - this is about the operation of transport, and the quoted text is from the new UDP Guidelines ID. On 15/02/2017 21:26, Joe Touch wrote: > Hi, Gorry (et al.), > > Again, the following text should not drift into discussing how tunnels > are handled IMO. That should be addressed in a different document (and I > don't think it's troublesome at all if viewed correctly). > > Joe > > > On 2/14/2017 9:23 AM, Gorry Fairhurst wrote: >> - Introduces a significant vulnerability. A rogue PTB message that >> reduces the PMTU to a minimum, can result in a path too small to carry >> an encapsulated packet. (Recently noted by Fernando Gont). >> >> Moreover, other layers view ICMP messages with suspicion and have long >> noted the need to check ICMP payload and match only packets that >> relate to actual 5-tuples in use (effectively reducing vulnerability >> to off-path attacks). For example, the Guidelines for UDP, rfc5405bis, >> state: >> >> " Applications SHOULD appropriately validate the payload of ICMP >> messages to ensure these are received in response to transmitted >> traffic (i.e., a reported error condition that corresponds to a UDP >> datagram actually sent by the application). …“ The comment below could easily be handled by something that clearly indicates the problem and points to the tunnel draft for guidance, I agree no need to go into algorithms/methods here. >> - clearly handling this in IP-layer tunnels can be troublesome, but >> that's a problem that should be described, not obscured. > Gorry From nobody Thu Feb 16 08:00:38 2017 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 18B011295F3; Thu, 16 Feb 2017 08:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 2z_PEEV2yxMq; Thu, 16 Feb 2017 08:00:34 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 6892B12962E; Thu, 16 Feb 2017 08:00:28 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1GFxSao006367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Feb 2017 07:59:30 -0800 (PST) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: gorry@erg.abdn.ac.uk References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> <2fc3beb1-86d1-2436-71e1-a90c525cb0d6@erg.abdn.ac.uk> From: Joe Touch Message-ID: <2eb7f087-571e-d2be-2c57-1d287f443ad7@isi.edu> Date: Thu, 16 Feb 2017 07:59:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <2fc3beb1-86d1-2436-71e1-a90c525cb0d6@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@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: Thu, 16 Feb 2017 16:00:36 -0000 Hi, Gorry, On 2/16/2017 6:08 AM, Gorry Fairhurst wrote: > > The text below is not about tunnels - this is about the operation of > transport, and the quoted text is from the new UDP Guidelines ID. Oh - I was distracted by some of the text then - see below... > > On 15/02/2017 21:26, Joe Touch wrote: >> Hi, Gorry (et al.), >> >> Again, the following text should not drift into discussing how tunnels >> are handled IMO. That should be addressed in a different document (and I >> don't think it's troublesome at all if viewed correctly). >> >> Joe >> >> >> On 2/14/2017 9:23 AM, Gorry Fairhurst wrote: >>> - Introduces a significant vulnerability. A rogue PTB message that >>> reduces the PMTU to a minimum, can result in a path too small to carry >>> an encapsulated packet. (Recently noted by Fernando Gont). . The issue is the IPv6 limit. Issues of "encapsulated packets" not fitting in this limit are already handled by transport protocols using IPv6 (if this is about layering encapsulation) and tunneling (if this is about tunneling, which is how I inferred "encapsulated packets"). >>> >>> Moreover, other layers view ICMP messages with suspicion and have long >>> noted the need to check ICMP payload and match only packets that >>> relate to actual 5-tuples in use (effectively reducing vulnerability >>> to off-path attacks). For example, the Guidelines for UDP, rfc5405bis, >>> state: >>> >>> " Applications SHOULD appropriately validate the payload of ICMP >>> messages to ensure these are received in response to transmitted >>> traffic (i.e., a reported error condition that corresponds to a UDP >>> datagram actually sent by the application). …“ > > The comment below could easily be handled by something that clearly > indicates the problem and points to the tunnel draft for guidance, I > agree no need to go into algorithms/methods here. The problem isn't unique to tunnels - it happens on any link whose MTU can vary, and IMO the solution is the same. React to the change in subsequent traffic, rather than attempting to rely in ICMP relaying from signaling inside the link layer -- regardless of that link layer. Joe > >>> - clearly handling this in IP-layer tunnels can be troublesome, but >>> that's a problem that should be described, not obscured. >> > > Gorry From nobody Thu Feb 16 08:47:53 2017 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 994E0129D81; Thu, 16 Feb 2017 08:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Rxd_WhPCTjIo; Thu, 16 Feb 2017 08:47:43 -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 5CECA129DBC; Thu, 16 Feb 2017 08:47:28 -0800 (PST) Received: from dhcp-207-155.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:b82b:6073:afb4:ddb0]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 91ED01B00055; Thu, 16 Feb 2017 18:45:12 +0000 (GMT) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> <2fc3beb1-86d1-2436-71e1-a90c525cb0d6@erg.abdn.ac.uk> <2eb7f087-571e-d2be-2c57-1d287f443ad7@isi.edu> To: Joe Touch From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: Date: Thu, 16 Feb 2017 16:47:17 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <2eb7f087-571e-d2be-2c57-1d287f443ad7@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:47:46 -0000 On 16/02/2017 15:59, Joe Touch wrote: > Hi, Gorry, > > > On 2/16/2017 6:08 AM, Gorry Fairhurst wrote: >> >> The text below is not about tunnels - this is about the operation of >> transport, and the quoted text is from the new UDP Guidelines ID. > Oh - I was distracted by some of the text then - see below... > >> >> On 15/02/2017 21:26, Joe Touch wrote: >>> Hi, Gorry (et al.), >>> >>> Again, the following text should not drift into discussing how tunnels >>> are handled IMO. That should be addressed in a different document (and I >>> don't think it's troublesome at all if viewed correctly). >>> >>> Joe >>> >>> >>> On 2/14/2017 9:23 AM, Gorry Fairhurst wrote: >>>> - Introduces a significant vulnerability. A rogue PTB message that >>>> reduces the PMTU to a minimum, can result in a path too small to carry >>>> an encapsulated packet. (Recently noted by Fernando Gont). . > > The issue is the IPv6 limit. Issues of "encapsulated packets" not > fitting in this limit are already handled by transport protocols using > IPv6 (if this is about layering encapsulation) and tunneling (if this is > about tunneling, which is how I inferred "encapsulated packets"). > The point was that according to this spec (as currently written), an off-path attacker can trivially inject an ICMPv6 message into the traffic, which then causes a host to accept a different PathMTU. Normally a transport design would expect ICMP messages to be at least checked against the list of known connections, so that successfully mounting this attack required the packet to correspond to ports that are in use. (Usually unknown to an off-path attacker). >>>> >>>> Moreover, other layers view ICMP messages with suspicion and have long >>>> noted the need to check ICMP payload and match only packets that >>>> relate to actual 5-tuples in use (effectively reducing vulnerability >>>> to off-path attacks). For example, the Guidelines for UDP, rfc5405bis, >>>> state: >>>> >>>> " Applications SHOULD appropriately validate the payload of ICMP >>>> messages to ensure these are received in response to transmitted >>>> traffic (i.e., a reported error condition that corresponds to a UDP >>>> datagram actually sent by the application). …“ >> >> The comment below could easily be handled by something that clearly >> indicates the problem and points to the tunnel draft for guidance, I >> agree no need to go into algorithms/methods here. > > The problem isn't unique to tunnels - it happens on any link whose MTU > can vary, and IMO the solution is the same. React to the change in > subsequent traffic, rather than attempting to rely in ICMP relaying from > signaling inside the link layer -- regardless of that link layer. > > Joe > I'd be fine with recommending that way of working - but if the host reacts to ICMP, it is important to try to verify ICMPv6 messages before accepting them. >> >>>> - clearly handling this in IP-layer tunnels can be troublesome, but >>>> that's a problem that should be described, not obscured. >>> >> >> Gorry > Gorry From nobody Thu Feb 16 09:06:54 2017 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 5DFCC129660; Thu, 16 Feb 2017 09:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 V5-U7WdArfPf; Thu, 16 Feb 2017 09:06:41 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 91832129633; Thu, 16 Feb 2017 09:06:41 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1GH5e5V027851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Feb 2017 09:05:42 -0800 (PST) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: gorry@erg.abdn.ac.uk References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> <2fc3beb1-86d1-2436-71e1-a90c525cb0d6@erg.abdn.ac.uk> <2eb7f087-571e-d2be-2c57-1d287f443ad7@isi.edu> From: Joe Touch Message-ID: <68d2bffb-825a-5eee-e6c8-2c4241c98ae9@isi.edu> Date: Thu, 16 Feb 2017 09:05:39 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------62D4C9D76F496C70E419C0C7" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@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: Thu, 16 Feb 2017 17:06:44 -0000 This is a multi-part message in MIME format. --------------62D4C9D76F496C70E419C0C7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi, Gorry, On 2/16/2017 8:47 AM, Gorry Fairhurst wrote: >> > The point was that according to this spec (as currently written), an > off-path attacker can trivially inject an ICMPv6 message into the > traffic, which then causes a host to accept a different PathMTU. > Normally a transport design would expect ICMP messages to be at least > checked against the list of known connections, so that successfully > mounting this attack required the packet to correspond to ports that > are in use. (Usually unknown to an off-path attacker). Agreed - but IMO this has nothing to do with "encapsulation" or tunneling, AFAICT. > >>>>> >>>>> Moreover, other layers view ICMP messages with suspicion and have >>>>> long >>>>> noted the need to check ICMP payload and match only packets that >>>>> relate to actual 5-tuples in use (effectively reducing vulnerability >>>>> to off-path attacks). For example, the Guidelines for UDP, >>>>> rfc5405bis, >>>>> state: >>>>> >>>>> " Applications SHOULD appropriately validate the payload of ICMP >>>>> messages to ensure these are received in response to transmitted >>>>> traffic (i.e., a reported error condition that corresponds to a >>>>> UDP >>>>> datagram actually sent by the application). …“ >>> >>> The comment below could easily be handled by something that clearly >>> indicates the problem and points to the tunnel draft for guidance, I >>> agree no need to go into algorithms/methods here. >> >> The problem isn't unique to tunnels - it happens on any link whose MTU >> can vary, and IMO the solution is the same. React to the change in >> subsequent traffic, rather than attempting to rely in ICMP relaying from >> signaling inside the link layer -- regardless of that link layer. >> >> Joe >> > I'd be fine with recommending that way of working - but if the host > reacts to ICMP, it is important to try to verify ICMPv6 messages > before accepting them. I think that's a fine punchline. The key is what "verification" means - as you note, a transport connection might not want to react to conflicting information and no entity (transport, OS, etc.) ought to react to nonsensical info (attempts to push MTU below required minimums). Joe --------------62D4C9D76F496C70E419C0C7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi, Gorry,


On 2/16/2017 8:47 AM, Gorry Fairhurst wrote:

The point was that according to this spec (as currently written), an off-path attacker can trivially inject an ICMPv6 message into the traffic, which then causes a host to accept a different PathMTU. Normally a transport design would expect ICMP messages to be at least checked against the list of known connections, so that successfully mounting this attack required the  packet to correspond to ports that are in use. (Usually unknown to an off-path attacker).

Agreed - but IMO this has nothing to do with "encapsulation" or tunneling, AFAICT.



Moreover, other layers view ICMP messages with suspicion and have long
noted the need to check ICMP payload and match only packets that
relate to actual 5-tuples in use (effectively reducing vulnerability
to off-path attacks). For example, the Guidelines for UDP, rfc5405bis,
state:

" Applications SHOULD appropriately validate the payload of ICMP
   messages to ensure these are received in response to transmitted
   traffic (i.e., a reported error condition that corresponds to a UDP
   datagram actually sent by the application). …“

The comment below could easily be handled by something that clearly
indicates the problem and points to the tunnel draft for guidance, I
agree no need to go into algorithms/methods here.

The problem isn't unique to tunnels - it happens on any link whose MTU
can vary, and IMO the solution is the same. React to the change in
subsequent traffic, rather than attempting to rely in ICMP relaying from
signaling inside the link layer -- regardless of that link layer.

Joe

I'd be fine with recommending that way of working - but if the host reacts to ICMP, it is important to try to verify ICMPv6 messages before accepting them.

I think that's a fine punchline. The key is what "verification" means - as you note, a transport connection might not want to react to conflicting information and no entity (transport, OS, etc.) ought to react to nonsensical info (attempts to push MTU below required minimums).

Joe

--------------62D4C9D76F496C70E419C0C7-- From nobody Thu Feb 16 09:13:17 2017 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 3675A12967A; Thu, 16 Feb 2017 09:13:07 -0800 (PST) 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 K_ImCBmo-kuN; Thu, 16 Feb 2017 09:13:06 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEED129680; Thu, 16 Feb 2017 09:13:06 -0800 (PST) Received: from dhcp-207-155.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:b82b:6073:afb4:ddb0]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 794E11B00055; Thu, 16 Feb 2017 19:10:55 +0000 (GMT) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> <2fc3beb1-86d1-2436-71e1-a90c525cb0d6@erg.abdn.ac.uk> <2eb7f087-571e-d2be-2c57-1d287f443ad7@isi.edu> <68d2bffb-825a-5eee-e6c8-2c4241c98ae9@isi.edu> To: Joe Touch From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <68cef79a-7b7e-bd4d-9f08-2768ec6576a0@erg.abdn.ac.uk> Date: Thu, 16 Feb 2017 17:13:05 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <68d2bffb-825a-5eee-e6c8-2c4241c98ae9@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:13:07 -0000 I think we agreed. Gorry On 16/02/2017 17:05, Joe Touch wrote: > Hi, Gorry, > > > On 2/16/2017 8:47 AM, Gorry Fairhurst wrote: >>> >> The point was that according to this spec (as currently written), an >> off-path attacker can trivially inject an ICMPv6 message into the >> traffic, which then causes a host to accept a different PathMTU. >> Normally a transport design would expect ICMP messages to be at least >> checked against the list of known connections, so that successfully >> mounting this attack required the packet to correspond to ports that >> are in use. (Usually unknown to an off-path attacker). > > Agreed - but IMO this has nothing to do with "encapsulation" or > tunneling, AFAICT. > Yes. This simply to do wth input processing by the PMTUD routine. >> >>>>>> >>>>>> Moreover, other layers view ICMP messages with suspicion and have >>>>>> long >>>>>> noted the need to check ICMP payload and match only packets that >>>>>> relate to actual 5-tuples in use (effectively reducing vulnerability >>>>>> to off-path attacks). For example, the Guidelines for UDP, >>>>>> rfc5405bis, >>>>>> state: >>>>>> >>>>>> " Applications SHOULD appropriately validate the payload of ICMP >>>>>> messages to ensure these are received in response to transmitted >>>>>> traffic (i.e., a reported error condition that corresponds to a >>>>>> UDP >>>>>> datagram actually sent by the application). …“ >>>> >>>> The comment below could easily be handled by something that clearly >>>> indicates the problem and points to the tunnel draft for guidance, I >>>> agree no need to go into algorithms/methods here. >>> >>> The problem isn't unique to tunnels - it happens on any link whose MTU >>> can vary, and IMO the solution is the same. React to the change in >>> subsequent traffic, rather than attempting to rely in ICMP relaying from >>> signaling inside the link layer -- regardless of that link layer. >>> >>> Joe >>> >> I'd be fine with recommending that way of working - but if the host >> reacts to ICMP, it is important to try to verify ICMPv6 messages >> before accepting them. > > I think that's a fine punchline. The key is what "verification" means - > as you note, a transport connection might not want to react to > conflicting information and no entity (transport, OS, etc.) ought to > react to nonsensical info (attempts to push MTU below required minimums). > > Joe > Gorry From nobody Thu Feb 16 10:47:41 2017 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 1ADC1129615; Thu, 16 Feb 2017 10:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 gtceYG7Phd1o; Thu, 16 Feb 2017 10:47:33 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 6067E12953E; Thu, 16 Feb 2017 10:47:33 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1GIkr89013536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Feb 2017 10:46:54 -0800 (PST) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard To: gorry@erg.abdn.ac.uk References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> <196e8c39-784a-3a25-b6ab-d7eaa664f0fa@isi.edu> <8fbc3cbd-ff2d-f2c6-ccd7-13a20c6aa5ca@erg.abdn.ac.uk> From: Joe Touch Message-ID: <935cf01c-a0f2-af0c-b60b-89ff04091eb2@isi.edu> Date: Thu, 16 Feb 2017 10:46:52 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <8fbc3cbd-ff2d-f2c6-ccd7-13a20c6aa5ca@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , "ietf@ietf.org" , "draft-ietf-6man-rfc1981bis@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: Thu, 16 Feb 2017 18:47:35 -0000 Hi, Gorry (et al.), On 2/16/2017 6:04 AM, Gorry Fairhurst wrote: > On 15/02/2017 21:25, Joe Touch wrote: >> Hi, Gorry (et al.), >> >> On 2/14/2017 9:23 AM, Gorry Fairhurst wrote: >>> There is no mention that paths including tunnels can eat ICMPv6 PTB >>> messages on the tunnel segment, blackholing them, which prevents >>> reaching the destination. >> >> Nor should there be, IMO. >> >> A tunnel is a link layer to the network whose packets it transits. >> >> ICMPs generated inside a tunnel aren't "eaten", so much as they operate >> at a different layer for a different reason (e.g., to tune >> ingress-egress source fragmentation of encapsulated packets). >> >> PTB messages inside a tunnel are (IMO) most correctly interpreted by the >> ingress (which is an *interface* on a router or host, most correctly >> IMO) as changing the MTU of the tunnel as a link. If that MTU change >> affects packets that arrive later, then it would be the router where the >> ingress is attached that would generate the ICMP, never the (ingress) >> interface whose MTU is insufficient. >> >> Again, I'm in the process of updating draft-ietf-intarea-tunnels to be >> much more clear on this point (the update should be issued in a day >> or two). >> >> Joe >> > > I really disagree Joe - not in what you say about how things need to > be, nor the relevance of draft-ietf-intarea-tunnels. > > The point of disagreement, is that I think the text needs to explain > enough that people do NOT blindly believe this always works. the > current text mentions tunnels in more than one place, as if they are > just another usage of PMTUD. > > Tunnels can make path MTU diiscovery unreliable, because many deployed > tunnel ingresses do not propagate ICMPv6 PTB messages upstream to > reflect the limits of the Tunnel MTU. I'll send you a preview of the updated tunnel text privately (it will be posted in a few days). Even the last version, however, explains why individual PTB messages should not be relayed directly upstream. The solution is as follows: PTB messages should update the ingress's link MTU (where the tunnel is a link and the ingress is a network interface). Subsequent messages at a router where the ingress is attached would already generate the correct ICMP errors when they receive later packets that are larger than that updated MTU. > draft-ietf-intarea-tunnels discusses how a tunnel should be > implemented to effectively work with a Tunnel MTU. The above is a brief summary of what it discusses. This document doesn't need to do much on this matter at all, except NOT provide contradictory advise or imply otherwise. IMO, whether a tunnel works correctly or not is a tunnel issue, not an issue for a network protocol, just as this doc shouldn't enumerate other link layer issues, such as problems with the need for broadcast on NBMA links, etc. Joe From nobody Tue Feb 28 10:29:50 2017 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 19430129672 for ; Tue, 28 Feb 2017 10:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 s3jcOKpia6UR for ; Tue, 28 Feb 2017 10:29:47 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14EAD129675 for ; Tue, 28 Feb 2017 10:29:46 -0800 (PST) Received: (qmail 10182 invoked from network); 28 Feb 2017 19:29:44 +0100 Received: from p5dec2bb4.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.43.180) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 28 Feb 2017 19:29:44 +0100 From: "Mirja Kuehlewind (IETF)" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 28 Feb 2017 19:29:42 +0100 Subject: Draft agenda uploaded To: tsv-area@ietf.org Message-Id: <41397ABC-92F8-41B4-867A-60835DB3D38B@kuehlewind.net> X-Mailer: Apple Mail (2.3259) 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: Tue, 28 Feb 2017 18:29:49 -0000 Hi all, we are happy to announce that we just uploaded the draft agenda for the = tsv-area meeting and we have a number of very interesting talks this = time! See https://www.ietf.org/proceedings/98/agenda/agenda-98-tsvarea-00 =E2=80=94=E2=80=94 TSVAREA @ IETF-98 (Chicago) Monday, March 27, 2017 Afternoon session I 13:00-15:00 Room: Vevey 1/2 * Administrativa - TSV ADs - Note Well, Blue Sheets, Jabber Scribes, Agenda Bashing - TSV Overview and status 10 minutes * Beneficial Functions of Middleboxes = (draft-dolson-plus-middlebox-benefits) - Dave Dolson 10 minutes + 15 minutes Q&A * Transport-Independent Path Layer State Management = (draft-trammell-plus-statefulness) - Brian Trammell, remote 10 minutes + 15 minutes Q&A * Tackling privacy and confidentiality of communications: EU's ePrivacy = Regulation - Diego Naranjo (European Digital Rights - https://edri.org), = remote 15 minutes + 15 minutes Q&A * Tor's Perspective on Privacy and Traffic Analysis Resistance for = Encrypted Protocols - Mike Perry=20 15 minutes + 15 minutes Q&A =E2=80=94=E2=80=94 As always both the scheduled slot as well as your agenda are only = preliminary. Especially we are still considering a way to add another = agenda item which might lead to some changes in the timing. See you all in Chicago! Your friendly transport ADs