From nobody Mon May 1 00:19:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A8B12945D for ; Mon, 1 May 2017 00:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfmfTTiHsMnv for ; Mon, 1 May 2017 00:19:48 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 271881277BB for ; Mon, 1 May 2017 00:17:18 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id c15so9893312ith.0 for ; Mon, 01 May 2017 00:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XzodA/fMgEbkOBIOz6uS5TuvUfAbF00wCsWxeRjmgMc=; b=YzN65muMmBWZeDzmnHyYWfkwoDrNcyJQ8m9pPmRD4YVzYwxZcVornJRbYGV9V/hZJm ELyvvhGDI0Cjk/aStj6Y6rMoUh9Z+6eVirHpOeipCvaZcuyxtmIpBGM2BKdGVdbdxzJq 8jtaB6/c+G2YZrlxfS8ewPpwdQOYMs5EWhzCKzrHciUxxRne+vCed39H9sa6dF2HhHUc X+61iGAI1UrStcG5WsS3RDiXZfoQ7QNZlwA6U9bJm1Mf/R5Ni3NyImY/HA/tozseFOqN +P5YUOJseNGWuy4Tpc+VLui2JGClrR7E+uQwLv9m6Q75XudNBOpjEAtH1OxXkt47JD4z 3byg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XzodA/fMgEbkOBIOz6uS5TuvUfAbF00wCsWxeRjmgMc=; b=TU7epIwklRLdbvG0izTPAwg/REUVWedHvMlRcqONdsCdBNf5f+rciDKaDoobMUPiMC 2Y7O0e8TMVMPJUFheuZfuKGsEGtL3E19A/NzEqhKuDp5dOBjFdzt3Gz9WqhNHW5XpneY D+FB6L7f+YzzcF4wWnY0cWJv0t0WwUBE+HMBza3EEvYIhYioiKK+ZmmroW79dvRYR/Df W/OA33N/4tlmLuJViHGJVMEFlIhRIg5mwdrRmravB5QgItPALcuxNBg85hLu9NN4s6Vm ZvShCGmcPWpNNnGTRdNBLhMdX4SJTJ3aqecSIz0kwo573GYGF7T1msQcUvmDBmf7TZk4 YOjA== X-Gm-Message-State: AN3rC/43QLIMmaC62mT+4t9I9iMGbdpjqYHIGow1UgrJuKQ/6zrwWOz+ ZVTgA+c8EjCziA+x9O5sO6G+SQXN4Q== X-Received: by 10.36.46.69 with SMTP id i66mr20135462ita.59.1493623037458; Mon, 01 May 2017 00:17:17 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Mon, 1 May 2017 00:17:16 -0700 (PDT) In-Reply-To: References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com> <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com> <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> From: Robert Raszuk Date: Mon, 1 May 2017 03:17:16 -0400 X-Google-Sender-Auth: kG5e-GrFkm0LjMHK7v-9vNx5KKQ Message-ID: Subject: Re: Proposed revised Extension Header text for rfc2460bis To: Mark Smith Cc: "Voyer, Daniel" , 6man WG Content-Type: multipart/alternative; boundary=001a114ab26c9380fb054e7136ac Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 07:19:50 -0000 --001a114ab26c9380fb054e7136ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mark, Were any changes required to the MPLS header or MPLS forwarding > operations to support SR? > =E2=80=8BIf you would follow SR-MPLS you would realize that MPLS label carr= ies an embedded function. Exactly like SID in SRH. Moreover with the overhead of signaling required to established an LSP in MPLS case transit nodes no matter if they are within domain or beyond domain DO NOT NEED to change any single bit in their current forwarding paradigm. SR functions are executed only at the designated nodes which are able to perform the desired forwarding behaviour. This entire discussion that maybe we will bless SRv6 in closed domains just does not get the fundamental point that transit nodes regardless on how many SRH are in the IPv6 packet will work just fine. Of course there is MTU concern ... but this concern is also with MPLS stacking or for that matter with any encapsulation. And we do know today how to effectively solve it when/where needed. It get's even worse if you (like some of this WG members) now require to encapsulate packets in additional v6 header before SRH is inserted - makes zero sense ! Just please kindly observe that if you do the encap the dst address can be anywhere in the Internet .. no encap code mandates that dst must be in your IGP. So packets do escape ASes .. BGP in fact was explicitly created to help/assist them to escape. I think perhaps a dedicated interim meeting should be setup just to discuss it and understand it well before we proceed with any further spec clarifications or extensions. Best, Robert=E2=80=8B =E2=80=8BPS. Leave alone other SRv6 features but does folks on this list do= not care about TI-LFA ?=E2=80=8B > > Another difference between IPv6 and MPLS is that MPLS is not an > end-to-end protocol, so it naturally creates and enforces local > domains. To have MPLS frames successfully leak between two networks > requires active enabling of MPLS on both ends of the links between > them, which won't happen unless the MPLS networks explicitly agree to > trade MPLS traffic, for explicit MPLS reasons, purposes and functions. > > IPv6 is an end-to-end protocol between hosts, that may transit > multiple networks in between those hosts. IPv6 is brought up between > two networks to provide services for any IPv6 applications. So SR > wouldn't likely be the initial reason to enable IPv6 between two > networks. Consequently, the likelihood of "internal" IPv6 SR packets > going further than they should is naturally much higher. RFC1918 and > similar have demonstrated that on the Internet, local or private "IP" > domains aren't. > > Regards, > Mark. > --001a114ab26c9380fb054e7136ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mark,

Were any changes required to the MPLS header or MPLS forwardi= ng
operations to support SR?

=E2=80=8BIf you would follow SR-MPLS you would realize that MPLS labe= l carries an embedded function. Exactly like SID in SRH.=C2=A0

Moreover with the overhead of sign= aling required to established an LSP in MPLS case transit nodes no matter i= f they are within domain or beyond domain DO NOT NEED to change any single = bit in their current forwarding paradigm. SR functions are executed only at= the designated nodes which are able to perform the desired forwarding beha= viour.=C2=A0

This enti= re discussion that maybe we will bless SRv6 in closed domains just does not= get the fundamental point that transit nodes regardless on how many SRH ar= e in the IPv6 packet will work just fine. Of course there is MTU concern ..= . but this concern is also with MPLS stacking or for that matter with any e= ncapsulation. And we do know today how to effectively solve it when/where n= eeded.

It get's ev= en worse if you (like some of this WG members) now require to encapsulate p= ackets in additional v6 header before SRH is inserted - makes zero sense ! = Just please kindly observe that if you do the encap the dst address can be = anywhere in the Internet .. no encap code mandates that dst must be in your= IGP. So packets do escape ASes .. BGP in fact was explicitly created to he= lp/assist them to escape.=C2=A0

I think perhaps a dedicated interim meeting should be setup just = to discuss it and understand it well before we proceed with any further spe= c clarifications or extensions.

Best,
Robert=E2=80=8B

=E2=80=8BPS. Leave alone other SRv6 features but does f= olks on this list do not care about TI-LFA ?=E2=80=8B

<= /div>
=C2=A0

Another difference between IPv6 and MPLS is that MPLS is not an
end-to-end protocol, so it naturally creates and enforces local
domains. To have MPLS frames successfully leak between two networks
requires active enabling of MPLS on both ends of the links between
them, which won't happen unless the MPLS networks explicitly agree to trade MPLS traffic, for explicit MPLS reasons, purposes and functions.

IPv6 is an end-to-end protocol between hosts, that may transit
multiple networks in between those hosts. IPv6 is brought up between
two networks to provide services for any IPv6 applications. So SR
wouldn't likely be the initial reason to enable IPv6 between two
networks. Consequently, the likelihood of "internal" IPv6 SR pack= ets
going further than they should is naturally much higher. RFC1918 and
similar have demonstrated that on the Internet, local or private "IP&q= uot;
domains aren't.

Regards,
Mark.

--001a114ab26c9380fb054e7136ac-- From nobody Mon May 1 05:10:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0EA126E01 for ; Mon, 1 May 2017 05:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, 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 J_6PRsHtFKHo for ; Mon, 1 May 2017 05:10:25 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.168]) (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 DACA5129553 for ; Mon, 1 May 2017 05:07:37 -0700 (PDT) Received: from [85.158.137.35] by server-8.bemta-3.messagelabs.com id 34/EF-02183-A7327095; Mon, 01 May 2017 12:00:58 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgk+JIrShJLcpLzFFi42I5t4YxWbdKmT3 S4NNFPouXZ98zWew8cpTdomlhE7MDs8fOWXfZPZYs+cnksXvjAqYA5ijWzLyk/IoE1owjB5sY C5oFKp60dbA3ML7g72Lk5JAQ8JP4u+oZWxcjF4eQwD5GideLDzNDONcZJdb9ucwE4ZxilLjSc 5Wxi5GDg01AR2LOC3kQU0RAXeJjHyPIIGYBO4kzl36C2cICThK3fyxkAbFFBJwl7vTuB1sgIj CNUeLxqkXsIL0sAioST9pcQGp4BawkJj/8C9YrJLCNU+LaS3sQm1MgUGLt/L+sIDajgJjE91N rmCB2iUvcejKfCeIBAYkle84zQ9iiEi8f/wOrFxXQk7j2YSULRFxH4uz1J4wQtoHE1qX7oOIK Eq/ur2cCOYdZQFNi/S59iPH2EqcmgMIExFaUmNL9kB3iTEGJkzOfQLVKShxccYMF4mRFiXm33 rJAQmo+o8TTc8uh7rGXeHj5K9MERrlZSM6ehbBuFpJ1s5Csm4Vk3QJG1lWM6sWpRWWpRbomek lFmekZJbmJmTm6hgbGermpxcWJ6ak5iUnFesn5uZsYgSmEAQh2MDZ+cTrEKMnBpCTKK/aOLVK ILyk/pTIjsTgjvqg0J7X4EKMMB4eSBK+YEnukkGBRanpqRVpmDjCZwaQlOHiURHijFYHSvMUF ibnFmekQqVOMilLivNYgfQIgiYzSPLg2WAK9xCgrJczLCHSIEE9BalFuZgmq/CtGcQ5GJWHeP yDjeTLzSuCmvwJazAS0uF6NBWRxSSJCSqqBsWyO2KRjF8wcOI6tOjxH3u548zc5JtE3v9NXP0 +wOi92VuDkCk3uI+X7YjNLlzqINAaJKrYL+GuvzPZ8e3U323vrWdt3+gXVxzila3rO+fD+6V5 js7Uz+uarlchavfeIPJL0cqKalvixS56SudeUCg+1HMoOk39Vee6Vw6IpgXbrZz5bU6WYo8RS nJFoqMVcVJwIAB5Ow92bAwAA X-Env-Sender: daniel.voyer@bell.ca X-Msg-Ref: server-12.tower-134.messagelabs.com!1493640055!21068805!4 X-Originating-IP: [206.172.1.99] X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8541 invoked from network); 1 May 2017 12:00:58 -0000 Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (206.172.1.99) by server-12.tower-134.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 1 May 2017 12:00:58 -0000 X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE02-DOR.bell.corp.bce.ca Received: from DG2MBX03-WYN.bell.corp.bce.ca (198.235.121.231) by EX13EDGE02-DOR.bell.corp.bce.ca (198.235.121.55) with Microsoft SMTP Server id 15.0.1210.3; Mon, 1 May 2017 08:00:53 -0400 Received: from DG2MBX03-WYN.bell.corp.bce.ca (2002:8eb6:1215::8eb6:1215) by DG2MBX03-WYN.bell.corp.bce.ca (2002:8eb6:1215::8eb6:1215) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 1 May 2017 08:00:54 -0400 Received: from DG2MBX03-WYN.bell.corp.bce.ca ([fe80::6475:3594:7cbe:fc39]) by DG2MBX03-WYN.bell.corp.bce.ca ([fe80::6475:3594:7cbe:fc39%23]) with mapi id 15.00.1210.000; Mon, 1 May 2017 08:00:54 -0400 From: "Voyer, Daniel" To: Mark Smith CC: Robert Raszuk , 6man WG Subject: Re: Proposed revised Extension Header text for rfc2460bis Thread-Topic: Proposed revised Extension Header text for rfc2460bis Thread-Index: AQHSvU2GLj2bkcaFakK4L3vH7EBFBaHZZUuAgACEfACAAA+WgIABK9yAgAAWV4CAAICQgIAAGHYAgAAFxACAABbmAIAAfcOAgADQ7YD//+0US4AAWSCAgAEaIICAAEw+AIAAfgqA Date: Mon, 1 May 2017 12:00:54 +0000 Message-ID: <75F0B851-AB53-4818-BB6B-CFE8D3E8CAC4@bell.ca> References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com> <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com> <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.24.25.23] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Received-SPF: SoftFail (EX13EDGE02-DOR.bell.corp.bce.ca: domain of transitioning daniel.voyer@bell.ca discourages use of 198.235.121.231 as permitted sender) X-OrganizationHeadersPreserved: EX13EDGE02-DOR.bell.corp.bce.ca Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 12:10:27 -0000 SGkgTWFyaywNCg0KPg0KICAgID4gWW91ciBTUFJJTkcgZ3JvdXAgaXMgb3BlcmF0aW5nIGluIGN1 cnJlbnRseSBhIHZlcnkgc21hbGwgZ3JlZW4gZmllbGQgKGFyZQ0KICAgID4gdGhlcmUgYW55IHBy b2R1Y3Rpb24gZGVwbG95bWVudHMgb2YgU1IgeWV0PyksIG91cnMgaXMgYSB2ZXJ5IGxhcmdlIGJy b3duDQogICAgPiBvbmUuICJUcml2aWFsIiBjaGFuZ2VzIGZvciB5b3UgYXJlIHRyaXZpYWwsIGZv ciB1cyB3ZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGV5DQogICAgPiBkb24ndCBicmVhayB0aGluZ3Mg aW4gdW5leHBlY3RlZCB3YXlzLCBiZWNhdXNlIHJlYWwgYW5kIGV4aXN0aW5nIGVuZC11c2Vycw0K ICAgID4gYW5kIHByb2R1Y3Rpb24gbmV0d29yayBvcGVyYXRvcnMgbWF5IHN1ZmZlciBhIHNpZ25p ZmljYW50IGFuZCBwb3RlbnRpYWxseQ0KICAgID4gZmluYW5jaWFsbHkgY29zdGx5IGNvbnNlcXVl bmNlLg0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4gU2VnbWVudCBSb3V0aW5nIGlzIGluIHBy b2R1Y3Rpb24gaW4gQmVsbCBuZXR3b3JrIChhcyBleHBsYWluIGF0IE1QTFMgUGFyaXMNCiAgICA+ IDIwMTcpIGFzIHdlbGwgYXMgZm9yIG90aGVycyBvcGVyYXRvcnMgZm9yIG9idmlvdXMgcmVhc29u czsgc2ltcGxpY2l0eSBhbmQNCiAgICA+IOKAnG11Y2ggbmVlZGVkIGlubm92YXRpb27igJ0uDQog ICAgPg0KICAgIA0KICAgIFByZXN1bWFibHkgTVBMUyBiYXNlZCBnaXZlbiB0aGUgbmFtZSBvZiB0 aGUgY29uZmVyZW5jZT8NCiAgICANCiAgICBBcmUgdGhlIHNsaWRlcyBhbnl3aGVyZT8NCg0KU2Vn bWVudC1yb3V0aW5nLm5ldCBpcyB5b3VyIG5leHQgZGVzdGluYXRpb247IHVuZGVyIGNvbmZlcmVu Y2VzIGFuZCBJRVRGLg0KICAgIA0KIEkgcmVjb21tZW5kIHdlIGdvIGJhY2sgdG8gdGhlIHB1cnBv c2Ugb2YgdGhpcyB0cmVhZC4NCg0KICAgIA0KICAgIElQdjYgaXMgYW4gZW5kLXRvLWVuZCBwcm90 b2NvbCBiZXR3ZWVuIGhvc3RzLCB0aGF0IG1heSB0cmFuc2l0DQogICAgbXVsdGlwbGUgbmV0d29y a3MgaW4gYmV0d2VlbiB0aG9zZSBob3N0cy4gSVB2NiBpcyBicm91Z2h0IHVwIGJldHdlZW4NCiAg ICB0d28gbmV0d29ya3MgdG8gcHJvdmlkZSBzZXJ2aWNlcyBmb3IgYW55IElQdjYgYXBwbGljYXRp b25zLiBTbyBTUg0KICAgIHdvdWxkbid0IGxpa2VseSBiZSB0aGUgaW5pdGlhbCByZWFzb24gdG8g ZW5hYmxlIElQdjYgYmV0d2VlbiB0d28NCiAgICBuZXR3b3Jrcy4gQ29uc2VxdWVudGx5LCB0aGUg bGlrZWxpaG9vZCBvZiAiaW50ZXJuYWwiIElQdjYgU1IgcGFja2V0cw0KICAgIGdvaW5nIGZ1cnRo ZXIgdGhhbiB0aGV5IHNob3VsZCBpcyBuYXR1cmFsbHkgbXVjaCBoaWdoZXIuIFJGQzE5MTggYW5k DQogICAgc2ltaWxhciBoYXZlIGRlbW9uc3RyYXRlZCB0aGF0IG9uIHRoZSBJbnRlcm5ldCwgbG9j YWwgb3IgcHJpdmF0ZSAiSVAiDQogICAgZG9tYWlucyBhcmVuJ3QuDQogICAgDQogICAgUmVnYXJk cywNCiAgICBNYXJrLg0KIA0KVGhhbmtzDQpkYW4gICANCg0K From nobody Mon May 1 10:43:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CA112E05C for ; Mon, 1 May 2017 10:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6EuAoFXTSaD for ; Mon, 1 May 2017 10:43:13 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE15B12E76A for ; Mon, 1 May 2017 10:40:37 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id c45so94150935qtb.1 for ; Mon, 01 May 2017 10:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nSS2wmbgFttd8Zr5Qob1/K2f/4w44UxSRn9NBJn8obg=; b=lScufJZsIvwsnH77Aibxsq/VmATFL9PZo0Q2PxjK/T2F94uj0W+WvznTij259W4U53 x21XDloECBe7bPprO5D11yguYfXMEQgXOF3jwtUzv/HRS42mu6jNGcWXB1V8HCaD/9n7 +ZdFiOGxxza+TE3uUBfH6pWtPI6KH72aBCFPzd7sGZ8DnL0NBA4Fr/uYqA5pR9DuQdlt w5zG/K7/cVmT5iRBUQJraYRYaKaKKnqA2e3f5yRwluunIz3aP69sdwtsVbqld5geHQWp +RaP4CN1ljdBQBIB6C1/Wf/Sb3/d6QEkdjbdDcfe8EwGmap6dvMVto5J12BNS5FdCV4T LDUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nSS2wmbgFttd8Zr5Qob1/K2f/4w44UxSRn9NBJn8obg=; b=qoF+vJVe5rwHBTiqp4UhHho0k7rwsTG6mSe95+4QyudpG1CuxRsHzkdNsldu0zWzC7 7M8vORppbWFMZvXQ6w0QNO0SuwgcQbQGyX41cjTmnSW4fgHaIV57EZnXrUdoW2TRcm9/ EhielOzgRG/or7rEDyKWfw7A8TVWWT5cQ6hsPF/+VkGHPLBL25VSR4IAM5tnT0wUNBzE 75Vxq/Xtxcy4uj7NPKpA7LXD+B2ujJ4xjPYObcpBDXgRiVQDNJ6+bPt7AwN8itI0sgou QxZWKkEZPyP9PrpqM3HB8x2oYYICyIhsdTAHk0EosBtjJBm2wAXM4VG05qCkBzc9MlX4 Tt1w== X-Gm-Message-State: AN3rC/7LksrdchXrkJgqMoVDGet6S10klR6LJXfTji9A/e9UNsWchxAy HlDeXCnH27KfbWa90qKurK9D6zAprg== X-Received: by 10.200.43.146 with SMTP id m18mr22340614qtm.210.1493660436712; Mon, 01 May 2017 10:40:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Mon, 1 May 2017 10:40:35 -0700 (PDT) In-Reply-To: References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com> <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com> <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> From: Tom Herbert Date: Mon, 1 May 2017 10:40:35 -0700 Message-ID: Subject: Re: Proposed revised Extension Header text for rfc2460bis To: Robert Raszuk Cc: Mark Smith , 6man WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 17:43:15 -0000 On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk wrote: > Hi Mark, > >> Were any changes required to the MPLS header or MPLS forwarding >> operations to support SR? > > > If you would follow SR-MPLS you would realize that MPLS label carries an > embedded function. Exactly like SID in SRH. > > Moreover with the overhead of signaling required to established an LSP in > MPLS case transit nodes no matter if they are within domain or beyond domain > DO NOT NEED to change any single bit in their current forwarding paradigm. > SR functions are executed only at the designated nodes which are able to > perform the desired forwarding behaviour. > > This entire discussion that maybe we will bless SRv6 in closed domains just > does not get the fundamental point that transit nodes regardless on how many > SRH are in the IPv6 packet will work just fine. I don't understand why we'd expect this to "work just fine"... There are still a lot of intermediate nodes that will arbitrarily drop extensions headers. So if one device inserts an extension header in a packet that previously had no extension headers and the packet is dropped down stream by some other device, then the device inserting headers has broken the end to end connectivity. What's worse is that the offending device won't even know packets are being dropped so it's can't do a happy eyeballs like algorithm like a host might be able to do. IMO, there is too much the emphasis here on the needs intermediate nodes and the value add they might provide without regard to the needs end hosts. IPv6 is, after all, a protocol that allow _hosts_ to communicate which may be facilitated intermediate routers. The assumption hosts make is that the IP packet sent from one host is received "as-is" on the other with only specific modifications allowed (options that may be modified in flight). In other words, if I, as a host, send a packet into the network, I expect that same packet to pop out at the receiver pretty much unchanged-- I don't expect the receiver to get some ad hoc re-interpretation of the packet by network nodes. This is implied by the robustness principle, fundamental to security, and needed to maintain connectivity. If network nodes want to modify packets in transit, insert extension headers, or other while in transit that might be reasonable per the requirements as long as 1) the changes are undone before delivering the packet to the receiving host, and 2) there are no other insidious effects like unexplained packet drop. Tom > Of course there is MTU > concern ... but this concern is also with MPLS stacking or for that matter > with any encapsulation. And we do know today how to effectively solve it > when/where needed. > > It get's even worse if you (like some of this WG members) now require to > encapsulate packets in additional v6 header before SRH is inserted - makes > zero sense ! Just please kindly observe that if you do the encap the dst > address can be anywhere in the Internet .. no encap code mandates that dst > must be in your IGP. So packets do escape ASes .. BGP in fact was explicitly > created to help/assist them to escape. > > I think perhaps a dedicated interim meeting should be setup just to discuss > it and understand it well before we proceed with any further spec > clarifications or extensions. > > Best, > Robert > > PS. Leave alone other SRv6 features but does folks on this list do not care > about TI-LFA ? > > >> >> >> Another difference between IPv6 and MPLS is that MPLS is not an >> end-to-end protocol, so it naturally creates and enforces local >> domains. To have MPLS frames successfully leak between two networks >> requires active enabling of MPLS on both ends of the links between >> them, which won't happen unless the MPLS networks explicitly agree to >> trade MPLS traffic, for explicit MPLS reasons, purposes and functions. >> >> IPv6 is an end-to-end protocol between hosts, that may transit >> multiple networks in between those hosts. IPv6 is brought up between >> two networks to provide services for any IPv6 applications. So SR >> wouldn't likely be the initial reason to enable IPv6 between two >> networks. Consequently, the likelihood of "internal" IPv6 SR packets >> going further than they should is naturally much higher. RFC1918 and >> similar have demonstrated that on the Internet, local or private "IP" >> domains aren't. >> >> Regards, >> Mark. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon May 1 10:51:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D32128CD5 for ; Mon, 1 May 2017 10:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 7FWS_VRS9q2f for ; Mon, 1 May 2017 10:51:18 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 987FA12EAC2 for ; Mon, 1 May 2017 10:47:54 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id u75so98417894qka.3 for ; Mon, 01 May 2017 10:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=Hh/UyuhjXsx9j7Em9SdgqSAysTmJNtU+oBL5AKbhIy0=; b=NBXmeBxlxDUtPcoDHXYKFlG5uL4zaoHSmxMqRXbNLs4VCZDC5gLvd6CFLIRZEdwiju qxkz1oM+xv5YrW/tU1zTjGdMmbdHQ+SJzQB8apXibHv5mNCvOynmuQkror/YoB2AgfIm c/qpxEEDS9hQMIz6e4JGHdrqty2bj6OptjQX59km5r9ULmXOt+TURb8yBXoiEFsaoZ+R VP/aHMe4+V47m5/U79mWdhyfzOzDviYI7+3TsLA1TwiKAj45GQ4FuORqfWpsuvVKSaQ6 BCr8Glxv3NX9FyK3U1O53X6trOM7OKpxekOn8PGpP5I8stb6FGQQTR+sd5bZ6xOPXRBx J9Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=Hh/UyuhjXsx9j7Em9SdgqSAysTmJNtU+oBL5AKbhIy0=; b=G2/uKyZbrBKHjELcljuyUcfZrN8W/A6Jh+J0HJDogY4+DSpQTMyP29No+4jl70wxx6 ADdm0i+NtOmTi+lsUPozPr5SjsutlPJQ0Ex2GGPWPEH6xdHLCTXIJFynv6XznuBH7h1g IxMRsCCop27EkaFQ8SjJU+NIomcjkQGa4tbzN3hfu1rXPKOemCMxbxsP/AFDyW9ut0vD utZU6HnL/ywOsRIR5hVzAaFoWenShKqGvkW9oU8Yg8v+Xg/WWTVP06C4wfmLEUA7X5U/ DbthheFVIsUDgkBLnDWXosF0rUt/UrpzKHx4GssIggz+c80fWL4d4lm8W0wV4WBmCj/A J7OQ== X-Gm-Message-State: AN3rC/63phlub7lEUF+Xtx6eo0pC9T9yztj12JtQDf5AvbGTR5m6mbO9 r9YlWBjkJLxhCQ1E+GNR9L3m4JhPBA== X-Received: by 10.55.99.87 with SMTP id x84mr2918016qkb.86.1493660873582; Mon, 01 May 2017 10:47:53 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.208 with HTTP; Mon, 1 May 2017 10:47:52 -0700 (PDT) In-Reply-To: <1CA0E022-B54D-455C-8063-0AE34DD2CCC2@cisco.com> References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com> <59036B64.4010008@cisco.com> <1CA0E022-B54D-455C-8063-0AE34DD2CCC2@cisco.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 1 May 2017 10:47:52 -0700 X-Google-Sender-Auth: 4qnqHTV6irhG1Om1FcY4uK6-4cg Message-ID: Subject: Re: Proposed revised Extension Header text for rfc2460bis To: "Stefano Previdi (sprevidi)" Cc: "Ahmed Bashandy (bashandy)" , Fernando Gont , Brian E Carpenter , Bob Hinden , IPv6 List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 17:51:22 -0000 At Sat, 29 Apr 2017 20:49:56 +0000, "Stefano Previdi (sprevidi)" wrote: > >> I also agree > >> Using the standardized keywords avoids any *language-dependent* > >> misunderstandings > > > > I also wish this document (both the latest bis and its predecessors) > > had been using RFC2119 keywords, but the fact is that it hasn't, and > > my recollection matches Brian's comment: we explicitly discussed it > > before and the decision was not to use RFC2119 keywords for > > rfc2460bis. I don't think it productive to rehash the discussion at > > this point. > > why not ? > isn=E2=80=99t the point of a normative document to use normative language= ? I don't remember the exact key reason that brought us to that decision. That's something I just chose to live with, so I don't care much about it at this stage. If you think it's critical to turn over the decision, I'd suggest you look into the email archive. > >> Going back to the original discussion, I agree with Stefano's "should > >> not" in this place > > > > I don't agree "should not" is an appropriate replacement of "are not=E2= =80=9D, > > but it=E2=80=99s an appropriate replacement text, looking at the reality = of > 2017 and not the one in 1998. > > > just like Brian and Fernando. I also agree with Fernando in that it's > > actually much closer to "must not", if anything. > > despite the various episodes, I still do not agree on the current text. These two points seem to suggest you're essentially rehashing the very original point of the discussion, i.e., whether we should clarify the ambiguity in RFC2460 with the original intent. In that case I'd suggest you rather do so explicitly than pretend to make a minor wording/editorial change. Personally, I think it's more productive if we ship rfc2460bis and focus on updates sooner rather than hold rfc2460bis by rehashing the very original point of the discussion. While in my case I support the current text of rfc2460bis, I made my comment so we can be more productive and get things (including updates to rfc2460bis) done sooner. But apparently I failed in that attempt, so I'= ll shut up here in this thread. -- JINMEI, Tatuya From nobody Mon May 1 11:21:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E51A129BC4 for ; Mon, 1 May 2017 11:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 gcdZHz3Vo41i for ; Mon, 1 May 2017 11:21:08 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 9BB2C129C0C for ; Mon, 1 May 2017 11:17:47 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id e65so28387259ita.1 for ; Mon, 01 May 2017 11:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ubX8KoQ6LgGjJkk5nQrZejy2Bdx7UjAp7TD9U+XH22k=; b=TW7St4jdwg5BIk9NYmrBpolndVCx9WQDZ+4Tmumn98vDYhP03Qm20Up725z6Gtux6m fMqsnJZ91ESTxHJ0BinuEulusQj5yVEZTqi/sjE94DwIimWXh1ovdXcmOCtHtdaMd34u yTRclmAD/HugpHh9UdtNc3P4oroK26cvY/lep21MMRI2R7fioj9c9BpnsVuqL239YG+Y ZxV6kN1KqiMLYWHpyQsIV6aYuJ0I75JNGtaKyVfEjtrgHRxry2YGkCn1UVIAkN6Ez1aq IKvTtMHSwLkWmg2ZGOsme0XzFlVf1iDiNWUsMGX3mRyo0RcwEtDGvyYUjYWHjf5+l8yd QGlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ubX8KoQ6LgGjJkk5nQrZejy2Bdx7UjAp7TD9U+XH22k=; b=UkoU62mBuAAOwcmIxFnQgI6TxC/fXvfST7XIBzaQufAMaYHD30LvfHRa8ynitB4af6 kcpjC7cHVN5GkJC7neGUTbzQxaVXZLXG9vZ7vWDwKN4XuZHLMEE06G89TmYmyLcBz6bd bpKiCsMPKx4Wq376ZYsnl9RKatW2xNBLD/TpOJ8PwAAc5W41lWYnMRIlyfWbN0nwWyJX 8VTZIpspsNLRW4lPNziUEQfsp8diaO/t+dzb/UT5+7Y/S+74TStS18ZP54d34A+2Fy7k pMIMyi7LEPdwpVjeeZ+0M94kA+LbNoeIL4v7rpekS7ceP1hKzUeESgIOUc5dwqbTff9l 8nKA== X-Gm-Message-State: AN3rC/7T53lp3fOu3if2znXBXrDMmF8fhRa76ZCr0AdmAk+cTyGrQKpm gi+DuMZct9tAusAoCJ4dCkOTF5oS/w== X-Received: by 10.36.139.67 with SMTP id g64mr2934897ite.18.1493662666971; Mon, 01 May 2017 11:17:46 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Mon, 1 May 2017 11:17:45 -0700 (PDT) Received: by 10.79.62.24 with HTTP; Mon, 1 May 2017 11:17:45 -0700 (PDT) In-Reply-To: References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com> <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com> <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> From: Robert Raszuk Date: Mon, 1 May 2017 14:17:45 -0400 X-Google-Sender-Auth: Ve6zPDzGEJSgE1TAeMPpOVXTo9Y Message-ID: Subject: Re: Proposed revised Extension Header text for rfc2460bis To: Tom Herbert Cc: 6man WG , Mark Smith Content-Type: multipart/alternative; boundary=94eb2c04b7c0ade061054e7a70ac Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 18:21:12 -0000 --94eb2c04b7c0ade061054e7a70ac Content-Type: text/plain; charset=UTF-8 Ok ... if v6 transit routers drop extension headers in spite of dst address being not themselves to me this sounds like a bug. It is behaviour against base v6 spec which allowed such EH to be inserted into v6 packets by senders. Maybe bis spec should made it very clear and mandate that transit routers MUST NOT alter EH in any way if the dst address is not themselves. Thx R. On May 1, 2017 10:40, "Tom Herbert" wrote: > On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk wrote: > > Hi Mark, > > > >> Were any changes required to the MPLS header or MPLS forwarding > >> operations to support SR? > > > > > > If you would follow SR-MPLS you would realize that MPLS label carries an > > embedded function. Exactly like SID in SRH. > > > > Moreover with the overhead of signaling required to established an LSP in > > MPLS case transit nodes no matter if they are within domain or beyond > domain > > DO NOT NEED to change any single bit in their current forwarding > paradigm. > > SR functions are executed only at the designated nodes which are able to > > perform the desired forwarding behaviour. > > > > This entire discussion that maybe we will bless SRv6 in closed domains > just > > does not get the fundamental point that transit nodes regardless on how > many > > SRH are in the IPv6 packet will work just fine. > > I don't understand why we'd expect this to "work just fine"... There > are still a lot of intermediate nodes that will arbitrarily drop > extensions headers. So if one device inserts an extension header in a > packet that previously had no extension headers and the packet is > dropped down stream by some other device, then the device inserting > headers has broken the end to end connectivity. What's worse is that > the offending device won't even know packets are being dropped so it's > can't do a happy eyeballs like algorithm like a host might be able to > do. > > IMO, there is too much the emphasis here on the needs intermediate > nodes and the value add they might provide without regard to the needs > end hosts. IPv6 is, after all, a protocol that allow _hosts_ to > communicate which may be facilitated intermediate routers. The > assumption hosts make is that the IP packet sent from one host is > received "as-is" on the other with only specific modifications allowed > (options that may be modified in flight). In other words, if I, as a > host, send a packet into the network, I expect that same packet to pop > out at the receiver pretty much unchanged-- I don't expect the > receiver to get some ad hoc re-interpretation of the packet by network > nodes. This is implied by the robustness principle, fundamental to > security, and needed to maintain connectivity. If network nodes want > to modify packets in transit, insert extension headers, or other while > in transit that might be reasonable per the requirements as long as 1) > the changes are undone before delivering the packet to the receiving > host, and 2) there are no other insidious effects like unexplained > packet drop. > > Tom > > > Of course there is MTU > > concern ... but this concern is also with MPLS stacking or for that > matter > > with any encapsulation. And we do know today how to effectively solve it > > when/where needed. > > > > It get's even worse if you (like some of this WG members) now require to > > encapsulate packets in additional v6 header before SRH is inserted - > makes > > zero sense ! Just please kindly observe that if you do the encap the dst > > address can be anywhere in the Internet .. no encap code mandates that > dst > > must be in your IGP. So packets do escape ASes .. BGP in fact was > explicitly > > created to help/assist them to escape. > > > > I think perhaps a dedicated interim meeting should be setup just to > discuss > > it and understand it well before we proceed with any further spec > > clarifications or extensions. > > > > Best, > > Robert > > > > PS. Leave alone other SRv6 features but does folks on this list do not > care > > about TI-LFA ? > > > > > >> > >> > >> Another difference between IPv6 and MPLS is that MPLS is not an > >> end-to-end protocol, so it naturally creates and enforces local > >> domains. To have MPLS frames successfully leak between two networks > >> requires active enabling of MPLS on both ends of the links between > >> them, which won't happen unless the MPLS networks explicitly agree to > >> trade MPLS traffic, for explicit MPLS reasons, purposes and functions. > >> > >> IPv6 is an end-to-end protocol between hosts, that may transit > >> multiple networks in between those hosts. IPv6 is brought up between > >> two networks to provide services for any IPv6 applications. So SR > >> wouldn't likely be the initial reason to enable IPv6 between two > >> networks. Consequently, the likelihood of "internal" IPv6 SR packets > >> going further than they should is naturally much higher. RFC1918 and > >> similar have demonstrated that on the Internet, local or private "IP" > >> domains aren't. > >> > >> Regards, > >> Mark. > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > --94eb2c04b7c0ade061054e7a70ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok ... if v6 transit routers drop extension headers in sp= ite of dst address being not themselves to me this sounds like a bug.

It is behaviour against base v6 spe= c which allowed such EH to be inserted into v6 packets by senders. Maybe bi= s spec should made it very clear and mandate that transit routers MUST NOT = alter EH in any way if the dst address is not themselves.
=
Thx
R.
=

On May 1, 2017 10= :40, "Tom Herbert" <tom= @herbertland.com> wrote:
On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk <robert@raszuk.net> wrote:
> Hi Mark,
>
>> Were any changes required to the MPLS header or MPLS forwarding >> operations to support SR?
>
>
> If you would follow SR-MPLS you would realize that MPLS label carries = an
> embedded function. Exactly like SID in SRH.
>
> Moreover with the overhead of signaling required to established an LSP= in
> MPLS case transit nodes no matter if they are within domain or beyond = domain
> DO NOT NEED to change any single bit in their current forwarding parad= igm.
> SR functions are executed only at the designated nodes which are able = to
> perform the desired forwarding behaviour.
>
> This entire discussion that maybe we will bless SRv6 in closed domains= just
> does not get the fundamental point that transit nodes regardless on ho= w many
> SRH are in the IPv6 packet will work just fine.

I don't understand why we'd expect this to "work just fine&quo= t;... There
are still a lot of intermediate nodes that will arbitrarily drop
extensions headers. So if one device inserts an extension header in a
packet that previously had no extension headers and the packet is
dropped down stream by some other device, then the device inserting
headers has broken the end to end connectivity. What's worse is that the offending device won't even know packets are being dropped so it= 9;s
can't do a happy eyeballs like algorithm like a host might be able to do.

IMO, there is too much the emphasis here on the needs intermediate
nodes and the value add they might provide without regard to the needs
end hosts. IPv6 is, after all, a protocol that allow _hosts_ to
communicate which may be facilitated intermediate routers. The
assumption hosts make is that the IP packet sent from one host is
received "as-is" on the other with only specific modifications al= lowed
(options that may be modified in flight). In other words, if I, as a
host, send a packet into the network, I expect that same packet to pop
out at the receiver pretty much unchanged-- I don't expect the
receiver to get some ad hoc re-interpretation of the packet by network
nodes. This is implied by the robustness principle, fundamental to
security, and needed to maintain connectivity. If network nodes want
to modify packets in transit, insert extension headers, or other while
in transit that might be reasonable per the requirements as long as 1)
the changes are undone before delivering the packet to the receiving
host, and 2) there are no other insidious effects like unexplained
packet drop.

Tom

> Of course there is MTU
> concern ... but this concern is also with MPLS stacking or for that ma= tter
> with any encapsulation. And we do know today how to effectively solve = it
> when/where needed.
>
> It get's even worse if you (like some of this WG members) now requ= ire to
> encapsulate packets in additional v6 header before SRH is inserted - m= akes
> zero sense ! Just please kindly observe that if you do the encap the d= st
> address can be anywhere in the Internet .. no encap code mandates that= dst
> must be in your IGP. So packets do escape ASes .. BGP in fact was expl= icitly
> created to help/assist them to escape.
>
> I think perhaps a dedicated interim meeting should be setup just to di= scuss
> it and understand it well before we proceed with any further spec
> clarifications or extensions.
>
> Best,
> Robert
>
> PS. Leave alone other SRv6 features but does folks on this list do not= care
> about TI-LFA ?
>
>
>>
>>
>> Another difference between IPv6 and MPLS is that MPLS is not an >> end-to-end protocol, so it naturally creates and enforces local >> domains. To have MPLS frames successfully leak between two network= s
>> requires active enabling of MPLS on both ends of the links between=
>> them, which won't happen unless the MPLS networks explicitly a= gree to
>> trade MPLS traffic, for explicit MPLS reasons, purposes and functi= ons.
>>
>> IPv6 is an end-to-end protocol between hosts, that may transit
>> multiple networks in between those hosts. IPv6 is brought up betwe= en
>> two networks to provide services for any IPv6 applications. So SR<= br> >> wouldn't likely be the initial reason to enable IPv6 between t= wo
>> networks. Consequently, the likelihood of "internal" IPv= 6 SR packets
>> going further than they should is naturally much higher. RFC1918 a= nd
>> similar have demonstrated that on the Internet, local or private &= quot;IP"
>> domains aren't.
>>
>> Regards,
>> Mark.
>
>
>
> ------------------------------------------------------------= --------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> ------------------------------------------------------------= --------
>
--94eb2c04b7c0ade061054e7a70ac-- From nobody Mon May 1 11:32:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A817312EAE9 for ; Mon, 1 May 2017 11:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tNBkWvMWzu33 for ; Mon, 1 May 2017 11:32:45 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 B9855129B34 for ; Mon, 1 May 2017 11:29:20 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id v1so48416960pgv.1 for ; Mon, 01 May 2017 11:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lNR2ABQUE1Mpcwqx9vkCjbEuh5+ckfX0Di8cijxnvXE=; b=lJdJoZggKkXt/1bQvHXUZgH9xRT01aanY+FyqH/9yUkaSOtWJWG63RV/1hb68Eh8xn oI0/q2iC5YOpArbCvEpHQw5HuNJ9BtIGvAz/VYUWDDRvqkK8mLKxBDdwLPrrNA1+cnen 07g10sNdIBRsMP47qZnqk6Pz53Fq5+XFIdVs4EW8JAmcc9UPjMMZZ9a/Jy1WeSAAJIIb vGdSvQQCLXpoHq+P8FpC1JS3Ar6FioKtbajOGK9004zFpslAATUo5we5IJ+VIfFOKfGa 8iFwF9TgMVD3lN67Vv9AMvg5UE/BWbVL2BOertkCyCcsDROoIuprpeNvWMx0bMOaFcoW znAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lNR2ABQUE1Mpcwqx9vkCjbEuh5+ckfX0Di8cijxnvXE=; b=fj3McOoU16tpY1WW8HAmboLi1nedyESibQ7hzf0E1yHbxMIHQIawJ278kgx0yLMe+Q 5iKORP7S9CXJzWqxwQrTN7mWtR62ot+vNTuxZT0PVdAWB342cd7nTxFslEBnrKLEbZep Cih5mvuhZK9hPo4CF64KSVP1MV0oDdS4yUeqUZkEN9iqjWTB5CIM30fohCDuV0y7/Req oCFza44wstz8W7H7crmlxG8x6brFINDc6M2XQ5rNDn7PgFLdPpz9QY2NZ+pWA2wooePq ppbY7y7jcXC0oQEIk8eEBiJOi+34C9JnItGjdRyQsqVoEtFex28K1d2PmleowgTM/62y DqzA== X-Gm-Message-State: AN3rC/4Kl2HGlAjZtS/7jOo8aN8YgXAFC8BbcWvJeJ2WJNTq4CEdfASO Y2+/kLSqua4/zqE+lLk= X-Received: by 10.99.100.194 with SMTP id y185mr28835612pgb.140.1493663360261; Mon, 01 May 2017 11:29:20 -0700 (PDT) Received: from [192.168.1.22] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id 184sm8391511pgf.11.2017.05.01.11.29.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2017 11:29:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Proposed revised Extension Header text for rfc2460bis From: Fred Baker In-Reply-To: Date: Mon, 1 May 2017 11:29:17 -0700 Cc: Tom Herbert , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com> <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com> <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> To: Robert Raszuk X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 18:32:48 -0000 Indeed. My understanding of the complaint is that=20 - some routers may be configured with ACLs that enforce rules about = extension headers, precluding any extension headers, specific types of = extension headers, or limiting extension headers to certain types. - some routers may be configured with ACLs that worry about TCP/UDP = port numbers, and drop packets for various reasons relating to the = number of extension headers found, the IPv6 header actually fitting in = working RAM in the chip, or other errors - if ACL handing is punted to another processor, it is often rate = limited - firewalls, in particular, may be configured to worry about the = presence of fragmentation headers Those are indeed contrary to the specification, and if a router or = firewall did it by default it would be in violation. That said, there = are equipment limitations in some cases and operator configurations in = others that can have the effect. > On May 1, 2017, at 11:17 AM, Robert Raszuk wrote: >=20 > Ok ... if v6 transit routers drop extension headers in spite of dst = address being not themselves to me this sounds like a bug. >=20 > It is behaviour against base v6 spec which allowed such EH to be = inserted into v6 packets by senders. Maybe bis spec should made it very = clear and mandate that transit routers MUST NOT alter EH in any way if = the dst address is not themselves. >=20 > Thx > R. >=20 > On May 1, 2017 10:40, "Tom Herbert" wrote: > On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk = wrote: > > Hi Mark, > > > >> Were any changes required to the MPLS header or MPLS forwarding > >> operations to support SR? > > > > > > If you would follow SR-MPLS you would realize that MPLS label = carries an > > embedded function. Exactly like SID in SRH. > > > > Moreover with the overhead of signaling required to established an = LSP in > > MPLS case transit nodes no matter if they are within domain or = beyond domain > > DO NOT NEED to change any single bit in their current forwarding = paradigm. > > SR functions are executed only at the designated nodes which are = able to > > perform the desired forwarding behaviour. > > > > This entire discussion that maybe we will bless SRv6 in closed = domains just > > does not get the fundamental point that transit nodes regardless on = how many > > SRH are in the IPv6 packet will work just fine. >=20 > I don't understand why we'd expect this to "work just fine"... There > are still a lot of intermediate nodes that will arbitrarily drop > extensions headers. So if one device inserts an extension header in a > packet that previously had no extension headers and the packet is > dropped down stream by some other device, then the device inserting > headers has broken the end to end connectivity. What's worse is that > the offending device won't even know packets are being dropped so it's > can't do a happy eyeballs like algorithm like a host might be able to > do. >=20 > IMO, there is too much the emphasis here on the needs intermediate > nodes and the value add they might provide without regard to the needs > end hosts. IPv6 is, after all, a protocol that allow _hosts_ to > communicate which may be facilitated intermediate routers. The > assumption hosts make is that the IP packet sent from one host is > received "as-is" on the other with only specific modifications allowed > (options that may be modified in flight). In other words, if I, as a > host, send a packet into the network, I expect that same packet to pop > out at the receiver pretty much unchanged-- I don't expect the > receiver to get some ad hoc re-interpretation of the packet by network > nodes. This is implied by the robustness principle, fundamental to > security, and needed to maintain connectivity. If network nodes want > to modify packets in transit, insert extension headers, or other while > in transit that might be reasonable per the requirements as long as 1) > the changes are undone before delivering the packet to the receiving > host, and 2) there are no other insidious effects like unexplained > packet drop. >=20 > Tom >=20 > > Of course there is MTU > > concern ... but this concern is also with MPLS stacking or for that = matter > > with any encapsulation. And we do know today how to effectively = solve it > > when/where needed. > > > > It get's even worse if you (like some of this WG members) now = require to > > encapsulate packets in additional v6 header before SRH is inserted - = makes > > zero sense ! Just please kindly observe that if you do the encap the = dst > > address can be anywhere in the Internet .. no encap code mandates = that dst > > must be in your IGP. So packets do escape ASes .. BGP in fact was = explicitly > > created to help/assist them to escape. > > > > I think perhaps a dedicated interim meeting should be setup just to = discuss > > it and understand it well before we proceed with any further spec > > clarifications or extensions. > > > > Best, > > Robert > > > > PS. Leave alone other SRv6 features but does folks on this list do = not care > > about TI-LFA ? > > > > > >> > >> > >> Another difference between IPv6 and MPLS is that MPLS is not an > >> end-to-end protocol, so it naturally creates and enforces local > >> domains. To have MPLS frames successfully leak between two networks > >> requires active enabling of MPLS on both ends of the links between > >> them, which won't happen unless the MPLS networks explicitly agree = to > >> trade MPLS traffic, for explicit MPLS reasons, purposes and = functions. > >> > >> IPv6 is an end-to-end protocol between hosts, that may transit > >> multiple networks in between those hosts. IPv6 is brought up = between > >> two networks to provide services for any IPv6 applications. So SR > >> wouldn't likely be the initial reason to enable IPv6 between two > >> networks. Consequently, the likelihood of "internal" IPv6 SR = packets > >> going further than they should is naturally much higher. RFC1918 = and > >> similar have demonstrated that on the Internet, local or private = "IP" > >> domains aren't. > >> > >> Regards, > >> Mark. > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon May 1 11:40:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD4012EAA6 for ; Mon, 1 May 2017 11:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 Fhj7M8Yrh8uN for ; Mon, 1 May 2017 11:39:57 -0700 (PDT) Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (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 46D0712EAA1 for ; Mon, 1 May 2017 11:36:47 -0700 (PDT) X-AuditID: 60721c4c-b53ff70000006581-d5-5907803dd050 Received: from VAADCEX42.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 20.8E.25985.D3087095; Mon, 1 May 2017 14:36:46 -0400 (EDT) Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX42.cable.comcast.com (147.191.103.219) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 1 May 2017 14:36:43 -0400 Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1263.000; Mon, 1 May 2017 14:36:43 -0400 From: "Leddy, John" To: Fred Baker , Robert Raszuk CC: 6man WG Subject: Re: Proposed revised Extension Header text for rfc2460bis Thread-Topic: Proposed revised Extension Header text for rfc2460bis Thread-Index: AQHSwqliUUgz4sjDdEmU7qwBKZgs4aHfzm+A Date: Mon, 1 May 2017 18:36:43 +0000 Message-ID: <89A73DC4-DF6A-4E96-A5F3-2D207EDEA7BA@cable.comcast.com> References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com> <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com> <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> In-Reply-To: <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.11] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsWSUOxpoWvXwB5pMHk1l8Xtrw2sFi/Pvmey aFrYxOzA7LFz1l12jyVLfjJ57N64gCmAOYrLJiU1J7MstUjfLoErY+eOZraCb0EVG59sYG5g fBLQxcjJISFgInH6ziTGLkYuDiGB7UwSvdMOQzkHGSVut/xggnBOMErc+TqXCaSFTUBHYsa0 a6wgtoiAj0Tn3F3sIDazgLTErSXPwWqEBZwkbv9YyAJR4yxxp3c/G4RtJNH/tBeonoODRUBF 4vwyN5Awr4CLRPuCSVC7znNLPO5cBzaTU8BW4vrj12C9jAJiEt9PrWGC2CUucevJfCaIFwQk luw5zwxhi0q8fPwP7DZRAT2Jax9WskDEdSTOXn/CCGEbSGxduo8F5AYJAXmJjyBvcQCN1JRY v0sfYrqDxIuHi1ghbEWJKd0P2SHOFJQ4OfMJ1ERJiYMrbrBMYJSeheSgWQiTZiGZNAvJpFlI Ji1gZF3FKFeWmJiSnJuRX1piYKSXnJiUk6qXnJ+bnFhcAqI3MYJivkjGZwfjp2kehxgFOBiV eHg/VrBHCrEmlhVX5h5ilOBgVhLhta8FCvGmJFZWpRblxxeV5qQWH2KU5mBREud1ePY9Qkgg PbEkNTs1tSC1CCbLxMEp1cA4nfnPXrHH5WF1Qr+dX92oXvPgdTlT5ySpE6K3DwbF2otMW+i+ 7sP18t8bnsTn7+BOjva3OhG+a0FqnL4Ev76p7dHSgwf/mNq6XbrBsTJ7g87+7PLkT42pdrr7 1cz/OP673XYgMOpwlubkrw4fLk703jsv1yz7bU64lAHPBJaU1l2GR76rM/5QYinOSDTUYi4q TgQAwLJOj/UCAAA= Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 18:40:01 -0000 VGhlIGJveGVzIHlvdSBkZXNjcmliZSBiZWxvdyB3b3VsZCBiZSBjb25zaWRlcmVkIOKAnG1pZGRs ZSBib3hlc+KAnS4NCg0KT24gNS8xLzE3LCAyOjI5IFBNLCAiaXB2NiBvbiBiZWhhbGYgb2YgRnJl ZCBCYWtlciIgPGlwdjYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZnJlZGJha2VyLmll dGZAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIEluZGVlZC4gTXkgdW5kZXJzdGFuZGluZyBvZiB0 aGUgY29tcGxhaW50IGlzIHRoYXQgDQogICAgICAtIHNvbWUgcm91dGVycyBtYXkgYmUgY29uZmln dXJlZCB3aXRoIEFDTHMgdGhhdCBlbmZvcmNlIHJ1bGVzIGFib3V0IGV4dGVuc2lvbiBoZWFkZXJz LCBwcmVjbHVkaW5nIGFueSBleHRlbnNpb24gaGVhZGVycywgc3BlY2lmaWMgdHlwZXMgb2YgZXh0 ZW5zaW9uIGhlYWRlcnMsIG9yIGxpbWl0aW5nIGV4dGVuc2lvbiBoZWFkZXJzIHRvIGNlcnRhaW4g dHlwZXMuDQogICAgICAtIHNvbWUgcm91dGVycyBtYXkgYmUgY29uZmlndXJlZCB3aXRoIEFDTHMg dGhhdCB3b3JyeSBhYm91dCBUQ1AvVURQIHBvcnQgbnVtYmVycywgYW5kIGRyb3AgcGFja2V0cyBm b3IgdmFyaW91cyByZWFzb25zIHJlbGF0aW5nIHRvIHRoZSBudW1iZXIgb2YgZXh0ZW5zaW9uIGhl YWRlcnMgZm91bmQsIHRoZSBJUHY2IGhlYWRlciBhY3R1YWxseSBmaXR0aW5nIGluIHdvcmtpbmcg UkFNIGluIHRoZSBjaGlwLCBvciBvdGhlciBlcnJvcnMNCiAgICAgIC0gaWYgQUNMIGhhbmRpbmcg aXMgcHVudGVkIHRvIGFub3RoZXIgcHJvY2Vzc29yLCBpdCBpcyBvZnRlbiByYXRlIGxpbWl0ZWQN CiAgICAgIC0gZmlyZXdhbGxzLCBpbiBwYXJ0aWN1bGFyLCBtYXkgYmUgY29uZmlndXJlZCB0byB3 b3JyeSBhYm91dCB0aGUgcHJlc2VuY2Ugb2YgZnJhZ21lbnRhdGlvbiBoZWFkZXJzDQogICAgDQog ICAgVGhvc2UgYXJlIGluZGVlZCBjb250cmFyeSB0byB0aGUgc3BlY2lmaWNhdGlvbiwgYW5kIGlm IGEgcm91dGVyIG9yIGZpcmV3YWxsIGRpZCBpdCBieSBkZWZhdWx0IGl0IHdvdWxkIGJlIGluIHZp b2xhdGlvbi4gVGhhdCBzYWlkLCB0aGVyZSBhcmUgZXF1aXBtZW50IGxpbWl0YXRpb25zIGluIHNv bWUgY2FzZXMgYW5kIG9wZXJhdG9yIGNvbmZpZ3VyYXRpb25zIGluIG90aGVycyB0aGF0IGNhbiBo YXZlIHRoZSBlZmZlY3QuDQogICAgDQogICAgPiBPbiBNYXkgMSwgMjAxNywgYXQgMTE6MTcgQU0s IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PiB3cm90ZToNCiAgICA+IA0KICAgID4g T2sgLi4uIGlmIHY2IHRyYW5zaXQgcm91dGVycyBkcm9wIGV4dGVuc2lvbiBoZWFkZXJzIGluIHNw aXRlIG9mIGRzdCBhZGRyZXNzIGJlaW5nIG5vdCB0aGVtc2VsdmVzIHRvIG1lIHRoaXMgc291bmRz IGxpa2UgYSBidWcuDQogICAgPiANCiAgICA+IEl0IGlzIGJlaGF2aW91ciBhZ2FpbnN0IGJhc2Ug djYgc3BlYyB3aGljaCBhbGxvd2VkIHN1Y2ggRUggdG8gYmUgaW5zZXJ0ZWQgaW50byB2NiBwYWNr ZXRzIGJ5IHNlbmRlcnMuIE1heWJlIGJpcyBzcGVjIHNob3VsZCBtYWRlIGl0IHZlcnkgY2xlYXIg YW5kIG1hbmRhdGUgdGhhdCB0cmFuc2l0IHJvdXRlcnMgTVVTVCBOT1QgYWx0ZXIgRUggaW4gYW55 IHdheSBpZiB0aGUgZHN0IGFkZHJlc3MgaXMgbm90IHRoZW1zZWx2ZXMuDQogICAgPiANCiAgICA+ IFRoeA0KICAgID4gUi4NCiAgICA+IA0KICAgID4gT24gTWF5IDEsIDIwMTcgMTA6NDAsICJUb20g SGVyYmVydCIgPHRvbUBoZXJiZXJ0bGFuZC5jb20+IHdyb3RlOg0KICAgID4gT24gTW9uLCBNYXkg MSwgMjAxNyBhdCAxMjoxNyBBTSwgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+IHdy b3RlOg0KICAgID4gPiBIaSBNYXJrLA0KICAgID4gPg0KICAgID4gPj4gV2VyZSBhbnkgY2hhbmdl cyByZXF1aXJlZCB0byB0aGUgTVBMUyBoZWFkZXIgb3IgTVBMUyBmb3J3YXJkaW5nDQogICAgPiA+ PiBvcGVyYXRpb25zIHRvIHN1cHBvcnQgU1I/DQogICAgPiA+DQogICAgPiA+DQogICAgPiA+IElm IHlvdSB3b3VsZCBmb2xsb3cgU1ItTVBMUyB5b3Ugd291bGQgcmVhbGl6ZSB0aGF0IE1QTFMgbGFi ZWwgY2FycmllcyBhbg0KICAgID4gPiBlbWJlZGRlZCBmdW5jdGlvbi4gRXhhY3RseSBsaWtlIFNJ RCBpbiBTUkguDQogICAgPiA+DQogICAgPiA+IE1vcmVvdmVyIHdpdGggdGhlIG92ZXJoZWFkIG9m IHNpZ25hbGluZyByZXF1aXJlZCB0byBlc3RhYmxpc2hlZCBhbiBMU1AgaW4NCiAgICA+ID4gTVBM UyBjYXNlIHRyYW5zaXQgbm9kZXMgbm8gbWF0dGVyIGlmIHRoZXkgYXJlIHdpdGhpbiBkb21haW4g b3IgYmV5b25kIGRvbWFpbg0KICAgID4gPiBETyBOT1QgTkVFRCB0byBjaGFuZ2UgYW55IHNpbmds ZSBiaXQgaW4gdGhlaXIgY3VycmVudCBmb3J3YXJkaW5nIHBhcmFkaWdtLg0KICAgID4gPiBTUiBm dW5jdGlvbnMgYXJlIGV4ZWN1dGVkIG9ubHkgYXQgdGhlIGRlc2lnbmF0ZWQgbm9kZXMgd2hpY2gg YXJlIGFibGUgdG8NCiAgICA+ID4gcGVyZm9ybSB0aGUgZGVzaXJlZCBmb3J3YXJkaW5nIGJlaGF2 aW91ci4NCiAgICA+ID4NCiAgICA+ID4gVGhpcyBlbnRpcmUgZGlzY3Vzc2lvbiB0aGF0IG1heWJl IHdlIHdpbGwgYmxlc3MgU1J2NiBpbiBjbG9zZWQgZG9tYWlucyBqdXN0DQogICAgPiA+IGRvZXMg bm90IGdldCB0aGUgZnVuZGFtZW50YWwgcG9pbnQgdGhhdCB0cmFuc2l0IG5vZGVzIHJlZ2FyZGxl c3Mgb24gaG93IG1hbnkNCiAgICA+ID4gU1JIIGFyZSBpbiB0aGUgSVB2NiBwYWNrZXQgd2lsbCB3 b3JrIGp1c3QgZmluZS4NCiAgICA+IA0KICAgID4gSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB3ZSdk IGV4cGVjdCB0aGlzIHRvICJ3b3JrIGp1c3QgZmluZSIuLi4gVGhlcmUNCiAgICA+IGFyZSBzdGls bCBhIGxvdCBvZiBpbnRlcm1lZGlhdGUgbm9kZXMgdGhhdCB3aWxsIGFyYml0cmFyaWx5IGRyb3AN CiAgICA+IGV4dGVuc2lvbnMgaGVhZGVycy4gU28gaWYgb25lIGRldmljZSBpbnNlcnRzIGFuIGV4 dGVuc2lvbiBoZWFkZXIgaW4gYQ0KICAgID4gcGFja2V0IHRoYXQgcHJldmlvdXNseSBoYWQgbm8g ZXh0ZW5zaW9uIGhlYWRlcnMgYW5kIHRoZSBwYWNrZXQgaXMNCiAgICA+IGRyb3BwZWQgZG93biBz dHJlYW0gYnkgc29tZSBvdGhlciBkZXZpY2UsIHRoZW4gdGhlIGRldmljZSBpbnNlcnRpbmcNCiAg ICA+IGhlYWRlcnMgaGFzIGJyb2tlbiB0aGUgZW5kIHRvIGVuZCBjb25uZWN0aXZpdHkuIFdoYXQn cyB3b3JzZSBpcyB0aGF0DQogICAgPiB0aGUgb2ZmZW5kaW5nIGRldmljZSB3b24ndCBldmVuIGtu b3cgcGFja2V0cyBhcmUgYmVpbmcgZHJvcHBlZCBzbyBpdCdzDQogICAgPiBjYW4ndCBkbyBhIGhh cHB5IGV5ZWJhbGxzIGxpa2UgYWxnb3JpdGhtIGxpa2UgYSBob3N0IG1pZ2h0IGJlIGFibGUgdG8N CiAgICA+IGRvLg0KICAgID4gDQogICAgPiBJTU8sIHRoZXJlIGlzIHRvbyBtdWNoIHRoZSBlbXBo YXNpcyBoZXJlIG9uIHRoZSBuZWVkcyBpbnRlcm1lZGlhdGUNCiAgICA+IG5vZGVzIGFuZCB0aGUg dmFsdWUgYWRkIHRoZXkgbWlnaHQgcHJvdmlkZSB3aXRob3V0IHJlZ2FyZCB0byB0aGUgbmVlZHMN CiAgICA+IGVuZCBob3N0cy4gSVB2NiBpcywgYWZ0ZXIgYWxsLCBhIHByb3RvY29sIHRoYXQgYWxs b3cgX2hvc3RzXyB0bw0KICAgID4gY29tbXVuaWNhdGUgd2hpY2ggbWF5IGJlIGZhY2lsaXRhdGVk IGludGVybWVkaWF0ZSByb3V0ZXJzLiBUaGUNCiAgICA+IGFzc3VtcHRpb24gaG9zdHMgbWFrZSBp cyB0aGF0IHRoZSBJUCBwYWNrZXQgc2VudCBmcm9tIG9uZSBob3N0IGlzDQogICAgPiByZWNlaXZl ZCAiYXMtaXMiIG9uIHRoZSBvdGhlciB3aXRoIG9ubHkgc3BlY2lmaWMgbW9kaWZpY2F0aW9ucyBh bGxvd2VkDQogICAgPiAob3B0aW9ucyB0aGF0IG1heSBiZSBtb2RpZmllZCBpbiBmbGlnaHQpLiBJ biBvdGhlciB3b3JkcywgaWYgSSwgYXMgYQ0KICAgID4gaG9zdCwgc2VuZCBhIHBhY2tldCBpbnRv IHRoZSBuZXR3b3JrLCBJIGV4cGVjdCB0aGF0IHNhbWUgcGFja2V0IHRvIHBvcA0KICAgID4gb3V0 IGF0IHRoZSByZWNlaXZlciBwcmV0dHkgbXVjaCB1bmNoYW5nZWQtLSBJIGRvbid0IGV4cGVjdCB0 aGUNCiAgICA+IHJlY2VpdmVyIHRvIGdldCBzb21lIGFkIGhvYyByZS1pbnRlcnByZXRhdGlvbiBv ZiB0aGUgcGFja2V0IGJ5IG5ldHdvcmsNCiAgICA+IG5vZGVzLiBUaGlzIGlzIGltcGxpZWQgYnkg dGhlIHJvYnVzdG5lc3MgcHJpbmNpcGxlLCBmdW5kYW1lbnRhbCB0bw0KICAgID4gc2VjdXJpdHks IGFuZCBuZWVkZWQgdG8gbWFpbnRhaW4gY29ubmVjdGl2aXR5LiBJZiBuZXR3b3JrIG5vZGVzIHdh bnQNCiAgICA+IHRvIG1vZGlmeSBwYWNrZXRzIGluIHRyYW5zaXQsIGluc2VydCBleHRlbnNpb24g aGVhZGVycywgb3Igb3RoZXIgd2hpbGUNCiAgICA+IGluIHRyYW5zaXQgdGhhdCBtaWdodCBiZSBy ZWFzb25hYmxlIHBlciB0aGUgcmVxdWlyZW1lbnRzIGFzIGxvbmcgYXMgMSkNCiAgICA+IHRoZSBj aGFuZ2VzIGFyZSB1bmRvbmUgYmVmb3JlIGRlbGl2ZXJpbmcgdGhlIHBhY2tldCB0byB0aGUgcmVj ZWl2aW5nDQogICAgPiBob3N0LCBhbmQgMikgdGhlcmUgYXJlIG5vIG90aGVyIGluc2lkaW91cyBl ZmZlY3RzIGxpa2UgdW5leHBsYWluZWQNCiAgICA+IHBhY2tldCBkcm9wLg0KICAgID4gDQogICAg PiBUb20NCiAgICA+IA0KICAgID4gPiBPZiBjb3Vyc2UgdGhlcmUgaXMgTVRVDQogICAgPiA+IGNv bmNlcm4gLi4uIGJ1dCB0aGlzIGNvbmNlcm4gaXMgYWxzbyB3aXRoIE1QTFMgc3RhY2tpbmcgb3Ig Zm9yIHRoYXQgbWF0dGVyDQogICAgPiA+IHdpdGggYW55IGVuY2Fwc3VsYXRpb24uIEFuZCB3ZSBk byBrbm93IHRvZGF5IGhvdyB0byBlZmZlY3RpdmVseSBzb2x2ZSBpdA0KICAgID4gPiB3aGVuL3do ZXJlIG5lZWRlZC4NCiAgICA+ID4NCiAgICA+ID4gSXQgZ2V0J3MgZXZlbiB3b3JzZSBpZiB5b3Ug KGxpa2Ugc29tZSBvZiB0aGlzIFdHIG1lbWJlcnMpIG5vdyByZXF1aXJlIHRvDQogICAgPiA+IGVu Y2Fwc3VsYXRlIHBhY2tldHMgaW4gYWRkaXRpb25hbCB2NiBoZWFkZXIgYmVmb3JlIFNSSCBpcyBp bnNlcnRlZCAtIG1ha2VzDQogICAgPiA+IHplcm8gc2Vuc2UgISBKdXN0IHBsZWFzZSBraW5kbHkg b2JzZXJ2ZSB0aGF0IGlmIHlvdSBkbyB0aGUgZW5jYXAgdGhlIGRzdA0KICAgID4gPiBhZGRyZXNz IGNhbiBiZSBhbnl3aGVyZSBpbiB0aGUgSW50ZXJuZXQgLi4gbm8gZW5jYXAgY29kZSBtYW5kYXRl cyB0aGF0IGRzdA0KICAgID4gPiBtdXN0IGJlIGluIHlvdXIgSUdQLiBTbyBwYWNrZXRzIGRvIGVz Y2FwZSBBU2VzIC4uIEJHUCBpbiBmYWN0IHdhcyBleHBsaWNpdGx5DQogICAgPiA+IGNyZWF0ZWQg dG8gaGVscC9hc3Npc3QgdGhlbSB0byBlc2NhcGUuDQogICAgPiA+DQogICAgPiA+IEkgdGhpbmsg cGVyaGFwcyBhIGRlZGljYXRlZCBpbnRlcmltIG1lZXRpbmcgc2hvdWxkIGJlIHNldHVwIGp1c3Qg dG8gZGlzY3Vzcw0KICAgID4gPiBpdCBhbmQgdW5kZXJzdGFuZCBpdCB3ZWxsIGJlZm9yZSB3ZSBw cm9jZWVkIHdpdGggYW55IGZ1cnRoZXIgc3BlYw0KICAgID4gPiBjbGFyaWZpY2F0aW9ucyBvciBl eHRlbnNpb25zLg0KICAgID4gPg0KICAgID4gPiBCZXN0LA0KICAgID4gPiBSb2JlcnQNCiAgICA+ ID4NCiAgICA+ID4gUFMuIExlYXZlIGFsb25lIG90aGVyIFNSdjYgZmVhdHVyZXMgYnV0IGRvZXMg Zm9sa3Mgb24gdGhpcyBsaXN0IGRvIG5vdCBjYXJlDQogICAgPiA+IGFib3V0IFRJLUxGQSA/DQog ICAgPiA+DQogICAgPiA+DQogICAgPiA+Pg0KICAgID4gPj4NCiAgICA+ID4+IEFub3RoZXIgZGlm ZmVyZW5jZSBiZXR3ZWVuIElQdjYgYW5kIE1QTFMgaXMgdGhhdCBNUExTIGlzIG5vdCBhbg0KICAg ID4gPj4gZW5kLXRvLWVuZCBwcm90b2NvbCwgc28gaXQgbmF0dXJhbGx5IGNyZWF0ZXMgYW5kIGVu Zm9yY2VzIGxvY2FsDQogICAgPiA+PiBkb21haW5zLiBUbyBoYXZlIE1QTFMgZnJhbWVzIHN1Y2Nl c3NmdWxseSBsZWFrIGJldHdlZW4gdHdvIG5ldHdvcmtzDQogICAgPiA+PiByZXF1aXJlcyBhY3Rp dmUgZW5hYmxpbmcgb2YgTVBMUyBvbiBib3RoIGVuZHMgb2YgdGhlIGxpbmtzIGJldHdlZW4NCiAg ICA+ID4+IHRoZW0sIHdoaWNoIHdvbid0IGhhcHBlbiB1bmxlc3MgdGhlIE1QTFMgbmV0d29ya3Mg ZXhwbGljaXRseSBhZ3JlZSB0bw0KICAgID4gPj4gdHJhZGUgTVBMUyB0cmFmZmljLCBmb3IgZXhw bGljaXQgTVBMUyByZWFzb25zLCBwdXJwb3NlcyBhbmQgZnVuY3Rpb25zLg0KICAgID4gPj4NCiAg ICA+ID4+IElQdjYgaXMgYW4gZW5kLXRvLWVuZCBwcm90b2NvbCBiZXR3ZWVuIGhvc3RzLCB0aGF0 IG1heSB0cmFuc2l0DQogICAgPiA+PiBtdWx0aXBsZSBuZXR3b3JrcyBpbiBiZXR3ZWVuIHRob3Nl IGhvc3RzLiBJUHY2IGlzIGJyb3VnaHQgdXAgYmV0d2Vlbg0KICAgID4gPj4gdHdvIG5ldHdvcmtz IHRvIHByb3ZpZGUgc2VydmljZXMgZm9yIGFueSBJUHY2IGFwcGxpY2F0aW9ucy4gU28gU1INCiAg ICA+ID4+IHdvdWxkbid0IGxpa2VseSBiZSB0aGUgaW5pdGlhbCByZWFzb24gdG8gZW5hYmxlIElQ djYgYmV0d2VlbiB0d28NCiAgICA+ID4+IG5ldHdvcmtzLiBDb25zZXF1ZW50bHksIHRoZSBsaWtl bGlob29kIG9mICJpbnRlcm5hbCIgSVB2NiBTUiBwYWNrZXRzDQogICAgPiA+PiBnb2luZyBmdXJ0 aGVyIHRoYW4gdGhleSBzaG91bGQgaXMgbmF0dXJhbGx5IG11Y2ggaGlnaGVyLiBSRkMxOTE4IGFu ZA0KICAgID4gPj4gc2ltaWxhciBoYXZlIGRlbW9uc3RyYXRlZCB0aGF0IG9uIHRoZSBJbnRlcm5l dCwgbG9jYWwgb3IgcHJpdmF0ZSAiSVAiDQogICAgPiA+PiBkb21haW5zIGFyZW4ndC4NCiAgICA+ ID4+DQogICAgPiA+PiBSZWdhcmRzLA0KICAgID4gPj4gTWFyay4NCiAgICA+ID4NCiAgICA+ID4N CiAgICA+ID4NCiAgICA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+ID4gSUVURiBJUHY2IHdvcmtpbmcg Z3JvdXAgbWFpbGluZyBsaXN0DQogICAgPiA+IGlwdjZAaWV0Zi5vcmcNCiAgICA+ID4gQWRtaW5p c3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXB2Ng0KICAgID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgID4gPg0KICAgID4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAg ICA+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KICAgID4gaXB2NkBpZXRm Lm9yZw0KICAgID4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXB2Ng0KICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KICAgIElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KICAgIGlw djZAaWV0Zi5vcmcNCiAgICBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICAN Cg0K From nobody Mon May 1 11:54:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AB512953F for ; Mon, 1 May 2017 11:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2gm-Lfw9riQI for ; Mon, 1 May 2017 11:54:16 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD7012EB06 for ; Mon, 1 May 2017 11:51:30 -0700 (PDT) Received: from mail1.ernw.net (unknown [172.31.1.30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 11EE42732A for ; Mon, 1 May 2017 20:51:22 +0200 (CEST) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id EC89858F95B for ; Mon, 1 May 2017 20:51:27 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 2574B39C02; Mon, 1 May 2017 20:51:28 +0200 (CEST) Date: Mon, 1 May 2017 20:51:28 +0200 From: Enno Rey To: ipv6@ietf.org Subject: Re: Proposed revised Extension Header text for rfc2460bis Message-ID: <20170501185128.GB23490@ernw.de> References: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 18:54:20 -0000 Fred, On Mon, May 01, 2017 at 11:29:17AM -0700, Fred Baker wrote: > Indeed. My understanding of the complaint is that > - some routers may be configured with ACLs that enforce rules about extension headers, precluding any extension headers, specific types of extension headers, or limiting extension headers to certain types. > - some routers may be configured with ACLs that worry about TCP/UDP port numbers, and drop packets for various reasons relating to the number of extension headers found, the IPv6 header actually fitting in working RAM in the chip, or other errors > - if ACL handing is punted to another processor, it is often rate limited > - firewalls, in particular, may be configured to worry about the presence of fragmentation headers > > Those are indeed contrary to the specification, and if a router or firewall did it by default it would be in violation. actually the majority of commercial enterprise firewalls perform some filtering of EHs, at least as for their number or order (which both are not restricted too much in RFC 2460), by default. These are results for some testing we did in 2014 (I doubt much has changed until today. if it has probably things have not become more flexible/liberal): https://www.ernw.de/download/AAtlasis-RISC-project-presentation-%20results.pdf best Enno That said, there are equipment limitations in some cases and operator configurations in others that can have the effect. > > > On May 1, 2017, at 11:17 AM, Robert Raszuk wrote: > > > > Ok ... if v6 transit routers drop extension headers in spite of dst address being not themselves to me this sounds like a bug. > > > > It is behaviour against base v6 spec which allowed such EH to be inserted into v6 packets by senders. Maybe bis spec should made it very clear and mandate that transit routers MUST NOT alter EH in any way if the dst address is not themselves. > > > > Thx > > R. > > > > On May 1, 2017 10:40, "Tom Herbert" wrote: > > On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk wrote: > > > Hi Mark, > > > > > >> Were any changes required to the MPLS header or MPLS forwarding > > >> operations to support SR? > > > > > > > > > If you would follow SR-MPLS you would realize that MPLS label carries an > > > embedded function. Exactly like SID in SRH. > > > > > > Moreover with the overhead of signaling required to established an LSP in > > > MPLS case transit nodes no matter if they are within domain or beyond domain > > > DO NOT NEED to change any single bit in their current forwarding paradigm. > > > SR functions are executed only at the designated nodes which are able to > > > perform the desired forwarding behaviour. > > > > > > This entire discussion that maybe we will bless SRv6 in closed domains just > > > does not get the fundamental point that transit nodes regardless on how many > > > SRH are in the IPv6 packet will work just fine. > > > > I don't understand why we'd expect this to "work just fine"... There > > are still a lot of intermediate nodes that will arbitrarily drop > > extensions headers. So if one device inserts an extension header in a > > packet that previously had no extension headers and the packet is > > dropped down stream by some other device, then the device inserting > > headers has broken the end to end connectivity. What's worse is that > > the offending device won't even know packets are being dropped so it's > > can't do a happy eyeballs like algorithm like a host might be able to > > do. > > > > IMO, there is too much the emphasis here on the needs intermediate > > nodes and the value add they might provide without regard to the needs > > end hosts. IPv6 is, after all, a protocol that allow _hosts_ to > > communicate which may be facilitated intermediate routers. The > > assumption hosts make is that the IP packet sent from one host is > > received "as-is" on the other with only specific modifications allowed > > (options that may be modified in flight). In other words, if I, as a > > host, send a packet into the network, I expect that same packet to pop > > out at the receiver pretty much unchanged-- I don't expect the > > receiver to get some ad hoc re-interpretation of the packet by network > > nodes. This is implied by the robustness principle, fundamental to > > security, and needed to maintain connectivity. If network nodes want > > to modify packets in transit, insert extension headers, or other while > > in transit that might be reasonable per the requirements as long as 1) > > the changes are undone before delivering the packet to the receiving > > host, and 2) there are no other insidious effects like unexplained > > packet drop. > > > > Tom > > > > > Of course there is MTU > > > concern ... but this concern is also with MPLS stacking or for that matter > > > with any encapsulation. And we do know today how to effectively solve it > > > when/where needed. > > > > > > It get's even worse if you (like some of this WG members) now require to > > > encapsulate packets in additional v6 header before SRH is inserted - makes > > > zero sense ! Just please kindly observe that if you do the encap the dst > > > address can be anywhere in the Internet .. no encap code mandates that dst > > > must be in your IGP. So packets do escape ASes .. BGP in fact was explicitly > > > created to help/assist them to escape. > > > > > > I think perhaps a dedicated interim meeting should be setup just to discuss > > > it and understand it well before we proceed with any further spec > > > clarifications or extensions. > > > > > > Best, > > > Robert > > > > > > PS. Leave alone other SRv6 features but does folks on this list do not care > > > about TI-LFA ? > > > > > > > > >> > > >> > > >> Another difference between IPv6 and MPLS is that MPLS is not an > > >> end-to-end protocol, so it naturally creates and enforces local > > >> domains. To have MPLS frames successfully leak between two networks > > >> requires active enabling of MPLS on both ends of the links between > > >> them, which won't happen unless the MPLS networks explicitly agree to > > >> trade MPLS traffic, for explicit MPLS reasons, purposes and functions. > > >> > > >> IPv6 is an end-to-end protocol between hosts, that may transit > > >> multiple networks in between those hosts. IPv6 is brought up between > > >> two networks to provide services for any IPv6 applications. So SR > > >> wouldn't likely be the initial reason to enable IPv6 between two > > >> networks. Consequently, the likelihood of "internal" IPv6 SR packets > > >> going further than they should is naturally much higher. RFC1918 and > > >> similar have demonstrated that on the Internet, local or private "IP" > > >> domains aren't. > > >> > > >> Regards, > > >> Mark. > > > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Mon May 1 12:49:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C2A12EAC5 for ; Mon, 1 May 2017 12:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 TkQ_nbUuOtik for ; Mon, 1 May 2017 12:49:11 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 4021512EB0C for ; Mon, 1 May 2017 12:46:42 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id z71so3643565itc.0 for ; Mon, 01 May 2017 12:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=57fczTZwFHaMolg8Q01n2GGNJXRpGnvfVfitRFJAyjE=; b=mFlLMDtB1Yy7HIK4LLRaQgzuhjv9M9cBCLTy+5znK/AHlKNmOXzHYhi8H4b+8nJnhd 0pjKddsEzeJKttCrNjnR3MpVoHFi2fIo1jeZ0vunOCaOGV+5p4xZd3vKVOgyxkomPnMl nk1UIr5pmaHJtyvtunPMqY8+KhNym1ihM7qJPpia7njMsEYOyqiKopdxAlTKg8Ps6pSO 9yB8Pwa5z7V4omdP177fiwN+nv+znKWXouyE7veUhFoI8l39hrmpxSC3xOD5ni9uJcMo rBosecFpMPd4ZE0Gn4A/m/xbpzW1TR2+iexCXVKLVCZnWAL4icQchREueOdMyofkB6uu SJUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=57fczTZwFHaMolg8Q01n2GGNJXRpGnvfVfitRFJAyjE=; b=YnE7CFgo+sEAdbPHh2EOaRr/y+PkcwOwvMiwS5T+GlKeHGX8BQURAezGXVpvgLRyXM 9YS3vCJljOuc48f0IIvVLNyvcyrxp/NvGxIN7s9VM6bEUrQU1eLbih1HTsEFsKEAvLU6 UNjMkvCWd+VDeGLZf7aXuV4uSl5y7PRtPXv3R17Ce6av0p13awdQZgVq97zcF/dKhCnM cwCCO3LyN46Wjyw3+2mqzKBM9pTeD7BpFLEVPFr4fgykwcTnToQ+uYzcqY83RJOjUpQr mQY4/YsL1aKKGE42fTLjnV5nc5VT2qjDddKoKL/sKuJez4zsfwa4GLhhdmACYa8QykI3 M1jw== X-Gm-Message-State: AN3rC/79vEveavE+QbLnUZZq44K3M4WLkw04nG6RCsgKZEfqmtuAeMbt GVc7v09E8h+m3hbrypiv2ETZrtxM7nNv X-Received: by 10.36.46.69 with SMTP id i66mr193772ita.59.1493668001532; Mon, 01 May 2017 12:46:41 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Mon, 1 May 2017 12:46:39 -0700 (PDT) Received: by 10.79.62.24 with HTTP; Mon, 1 May 2017 12:46:39 -0700 (PDT) In-Reply-To: <20170501185128.GB23490@ernw.de> References: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> <20170501185128.GB23490@ernw.de> From: Robert Raszuk Date: Mon, 1 May 2017 15:46:39 -0400 X-Google-Sender-Auth: JlAqEdsxBHGlVBw6zh24nTzlChQ Message-ID: Subject: Re: Proposed revised Extension Header text for rfc2460bis To: Enno Rey Cc: 6man WG Content-Type: multipart/alternative; boundary=001a114ab26ca4f972054e7bae18 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 19:49:14 -0000 --001a114ab26ca4f972054e7bae18 Content-Type: text/plain; charset=UTF-8 Good thing that no one is putting firewall in global Internet transit DFZ. So how this applies to this concern of transit nodes in the Internet remove EHs ? Cheers R. On May 1, 2017 11:54, "Enno Rey" wrote: > Fred, > > On Mon, May 01, 2017 at 11:29:17AM -0700, Fred Baker wrote: > > Indeed. My understanding of the complaint is that > > - some routers may be configured with ACLs that enforce rules about > extension headers, precluding any extension headers, specific types of > extension headers, or limiting extension headers to certain types. > > - some routers may be configured with ACLs that worry about TCP/UDP > port numbers, and drop packets for various reasons relating to the number > of extension headers found, the IPv6 header actually fitting in working RAM > in the chip, or other errors > > - if ACL handing is punted to another processor, it is often rate > limited > > - firewalls, in particular, may be configured to worry about the > presence of fragmentation headers > > > > Those are indeed contrary to the specification, and if a router or > firewall did it by default it would be in violation. > > actually the majority of commercial enterprise firewalls perform some > filtering of EHs, at least as for their number or order (which both are not > restricted too much in RFC 2460), by default. These are results for some > testing we did in 2014 (I doubt much has changed until today. if it has > probably things have not become more flexible/liberal): > > https://www.ernw.de/download/AAtlasis-RISC-project- > presentation-%20results.pdf > > best > > Enno > > > > > > That said, there are equipment limitations in some cases and operator > configurations in others that can have the effect. > > > > > On May 1, 2017, at 11:17 AM, Robert Raszuk wrote: > > > > > > Ok ... if v6 transit routers drop extension headers in spite of dst > address being not themselves to me this sounds like a bug. > > > > > > It is behaviour against base v6 spec which allowed such EH to be > inserted into v6 packets by senders. Maybe bis spec should made it very > clear and mandate that transit routers MUST NOT alter EH in any way if the > dst address is not themselves. > > > > > > Thx > > > R. > > > > > > On May 1, 2017 10:40, "Tom Herbert" wrote: > > > On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk > wrote: > > > > Hi Mark, > > > > > > > >> Were any changes required to the MPLS header or MPLS forwarding > > > >> operations to support SR? > > > > > > > > > > > > If you would follow SR-MPLS you would realize that MPLS label > carries an > > > > embedded function. Exactly like SID in SRH. > > > > > > > > Moreover with the overhead of signaling required to established an > LSP in > > > > MPLS case transit nodes no matter if they are within domain or > beyond domain > > > > DO NOT NEED to change any single bit in their current forwarding > paradigm. > > > > SR functions are executed only at the designated nodes which are > able to > > > > perform the desired forwarding behaviour. > > > > > > > > This entire discussion that maybe we will bless SRv6 in closed > domains just > > > > does not get the fundamental point that transit nodes regardless on > how many > > > > SRH are in the IPv6 packet will work just fine. > > > > > > I don't understand why we'd expect this to "work just fine"... There > > > are still a lot of intermediate nodes that will arbitrarily drop > > > extensions headers. So if one device inserts an extension header in a > > > packet that previously had no extension headers and the packet is > > > dropped down stream by some other device, then the device inserting > > > headers has broken the end to end connectivity. What's worse is that > > > the offending device won't even know packets are being dropped so it's > > > can't do a happy eyeballs like algorithm like a host might be able to > > > do. > > > > > > IMO, there is too much the emphasis here on the needs intermediate > > > nodes and the value add they might provide without regard to the needs > > > end hosts. IPv6 is, after all, a protocol that allow _hosts_ to > > > communicate which may be facilitated intermediate routers. The > > > assumption hosts make is that the IP packet sent from one host is > > > received "as-is" on the other with only specific modifications allowed > > > (options that may be modified in flight). In other words, if I, as a > > > host, send a packet into the network, I expect that same packet to pop > > > out at the receiver pretty much unchanged-- I don't expect the > > > receiver to get some ad hoc re-interpretation of the packet by network > > > nodes. This is implied by the robustness principle, fundamental to > > > security, and needed to maintain connectivity. If network nodes want > > > to modify packets in transit, insert extension headers, or other while > > > in transit that might be reasonable per the requirements as long as 1) > > > the changes are undone before delivering the packet to the receiving > > > host, and 2) there are no other insidious effects like unexplained > > > packet drop. > > > > > > Tom > > > > > > > Of course there is MTU > > > > concern ... but this concern is also with MPLS stacking or for that > matter > > > > with any encapsulation. And we do know today how to effectively > solve it > > > > when/where needed. > > > > > > > > It get's even worse if you (like some of this WG members) now > require to > > > > encapsulate packets in additional v6 header before SRH is inserted - > makes > > > > zero sense ! Just please kindly observe that if you do the encap the > dst > > > > address can be anywhere in the Internet .. no encap code mandates > that dst > > > > must be in your IGP. So packets do escape ASes .. BGP in fact was > explicitly > > > > created to help/assist them to escape. > > > > > > > > I think perhaps a dedicated interim meeting should be setup just to > discuss > > > > it and understand it well before we proceed with any further spec > > > > clarifications or extensions. > > > > > > > > Best, > > > > Robert > > > > > > > > PS. Leave alone other SRv6 features but does folks on this list do > not care > > > > about TI-LFA ? > > > > > > > > > > > >> > > > >> > > > >> Another difference between IPv6 and MPLS is that MPLS is not an > > > >> end-to-end protocol, so it naturally creates and enforces local > > > >> domains. To have MPLS frames successfully leak between two networks > > > >> requires active enabling of MPLS on both ends of the links between > > > >> them, which won't happen unless the MPLS networks explicitly agree > to > > > >> trade MPLS traffic, for explicit MPLS reasons, purposes and > functions. > > > >> > > > >> IPv6 is an end-to-end protocol between hosts, that may transit > > > >> multiple networks in between those hosts. IPv6 is brought up between > > > >> two networks to provide services for any IPv6 applications. So SR > > > >> wouldn't likely be the initial reason to enable IPv6 between two > > > >> networks. Consequently, the likelihood of "internal" IPv6 SR packets > > > >> going further than they should is naturally much higher. RFC1918 and > > > >> similar have demonstrated that on the Internet, local or private > "IP" > > > >> domains aren't. > > > >> > > > >> Regards, > > > >> Mark. > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -- > Enno Rey > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Enno Rey > > ======================================================= > Blog: www.insinuator.net || Conference: www.troopers.de > Twitter: @Enno_Insinuator > ======================================================= > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a114ab26ca4f972054e7bae18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good thing that no one is putting firewall in global Inte= rnet transit DFZ.

So how this = applies to this concern of transit nodes in the Internet remove EHs ?
=

Cheers
R.

On= May 1, 2017 11:54, "Enno Rey" <erey@ernw.de> wrote:
Fred,

On Mon, May 01, 2017 at 11:29:17AM -0700, Fred Baker wrote:
> Indeed. My understanding of the complaint is that
>=C2=A0 =C2=A0- some routers may be configured with ACLs that enforce ru= les about extension headers, precluding any extension headers, specific typ= es of extension headers, or limiting extension headers to certain types. >=C2=A0 =C2=A0- some routers may be configured with ACLs that worry abou= t TCP/UDP port numbers, and drop packets for various reasons relating to th= e number of extension headers found, the IPv6 header actually fitting in wo= rking RAM in the chip, or other errors
>=C2=A0 =C2=A0- if ACL handing is punted to another processor, it is oft= en rate limited
>=C2=A0 =C2=A0- firewalls, in particular, may be configured to worry abo= ut the presence of fragmentation headers
>
> Those are indeed contrary to the specification, and if a router or fir= ewall did it by default it would be in violation.

actually the majority of commercial enterprise firewalls perform some filte= ring of EHs, at least as for their number or order (which both are not rest= ricted too much in RFC 2460), by default. These are results for some testin= g we did in 2014 (I doubt much has changed until today. if it has probably = things have not become more flexible/liberal):

https://www.ernw.de/do= wnload/AAtlasis-RISC-project-presentation-%20results.pdf

best

Enno





=C2=A0That said, there are equipment limitations in some cases and operator= configurations in others that can have the effect.
>
> > On May 1, 2017, at 11:17 AM, Robert Raszuk <robert@raszuk.net> wrote:
> >
> > Ok ... if v6 transit routers drop extension headers in spite of d= st address being not themselves to me this sounds like a bug.
> >
> > It is behaviour against base v6 spec which allowed such EH to be = inserted into v6 packets by senders. Maybe bis spec should made it very cle= ar and mandate that transit routers MUST NOT alter EH in any way if the dst= address is not themselves.
> >
> > Thx
> > R.
> >
> > On May 1, 2017 10:40, "Tom Herbert" <tom@herbertland.com> wrote:
> > On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk <robert@raszuk.net> wrote:
> > > Hi Mark,
> > >
> > >> Were any changes required to the MPLS header or MPLS for= warding
> > >> operations to support SR?
> > >
> > >
> > > If you would follow SR-MPLS you would realize that MPLS labe= l carries an
> > > embedded function. Exactly like SID in SRH.
> > >
> > > Moreover with the overhead of signaling required to establis= hed an LSP in
> > > MPLS case transit nodes no matter if they are within domain = or beyond domain
> > > DO NOT NEED to change any single bit in their current forwar= ding paradigm.
> > > SR functions are executed only at the designated nodes which= are able to
> > > perform the desired forwarding behaviour.
> > >
> > > This entire discussion that maybe we will bless SRv6 in clos= ed domains just
> > > does not get the fundamental point that transit nodes regard= less on how many
> > > SRH are in the IPv6 packet will work just fine.
> >
> > I don't understand why we'd expect this to "work jus= t fine"... There
> > are still a lot of intermediate nodes that will arbitrarily drop<= br> > > extensions headers. So if one device inserts an extension header = in a
> > packet that previously had no extension headers and the packet is=
> > dropped down stream by some other device, then the device inserti= ng
> > headers has broken the end to end connectivity. What's worse = is that
> > the offending device won't even know packets are being droppe= d so it's
> > can't do a happy eyeballs like algorithm like a host might be= able to
> > do.
> >
> > IMO, there is too much the emphasis here on the needs intermediat= e
> > nodes and the value add they might provide without regard to the = needs
> > end hosts. IPv6 is, after all, a protocol that allow _hosts_ to > > communicate which may be facilitated intermediate routers. The > > assumption hosts make is that the IP packet sent from one host is=
> > received "as-is" on the other with only specific modifi= cations allowed
> > (options that may be modified in flight). In other words, if I, a= s a
> > host, send a packet into the network, I expect that same packet t= o pop
> > out at the receiver pretty much unchanged-- I don't expect th= e
> > receiver to get some ad hoc re-interpretation of the packet by ne= twork
> > nodes. This is implied by the robustness principle, fundamental t= o
> > security, and needed to maintain connectivity. If network nodes w= ant
> > to modify packets in transit, insert extension headers, or other = while
> > in transit that might be reasonable per the requirements as long = as 1)
> > the changes are undone before delivering the packet to the receiv= ing
> > host, and 2) there are no other insidious effects like unexplaine= d
> > packet drop.
> >
> > Tom
> >
> > > Of course there is MTU
> > > concern ... but this concern is also with MPLS stacking or f= or that matter
> > > with any encapsulation. And we do know today how to effectiv= ely solve it
> > > when/where needed.
> > >
> > > It get's even worse if you (like some of this WG members= ) now require to
> > > encapsulate packets in additional v6 header before SRH is in= serted - makes
> > > zero sense ! Just please kindly observe that if you do the e= ncap the dst
> > > address can be anywhere in the Internet .. no encap code man= dates that dst
> > > must be in your IGP. So packets do escape ASes .. BGP in fac= t was explicitly
> > > created to help/assist them to escape.
> > >
> > > I think perhaps a dedicated interim meeting should be setup = just to discuss
> > > it and understand it well before we proceed with any further= spec
> > > clarifications or extensions.
> > >
> > > Best,
> > > Robert
> > >
> > > PS. Leave alone other SRv6 features but does folks on this l= ist do not care
> > > about TI-LFA ?
> > >
> > >
> > >>
> > >>
> > >> Another difference between IPv6 and MPLS is that MPLS is= not an
> > >> end-to-end protocol, so it naturally creates and enforce= s local
> > >> domains. To have MPLS frames successfully leak between t= wo networks
> > >> requires active enabling of MPLS on both ends of the lin= ks between
> > >> them, which won't happen unless the MPLS networks ex= plicitly agree to
> > >> trade MPLS traffic, for explicit MPLS reasons, purposes = and functions.
> > >>
> > >> IPv6 is an end-to-end protocol between hosts, that may t= ransit
> > >> multiple networks in between those hosts. IPv6 is brough= t up between
> > >> two networks to provide services for any IPv6 applicatio= ns. So SR
> > >> wouldn't likely be the initial reason to enable IPv6= between two
> > >> networks. Consequently, the likelihood of "internal= " IPv6 SR packets
> > >> going further than they should is naturally much higher.= RFC1918 and
> > >> similar have demonstrated that on the Internet, local or= private "IP"
> > >> domains aren't.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > >
> > >
> > > -------------------------------------------------------= -------------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.o= rg/mailman/listinfo/ipv6
> > > -------------------------------------------------------= -------------
> > >
> > ------------------------------------------------------------= --------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/ma= ilman/listinfo/ipv6
> > ------------------------------------------------------------= --------
>
> ------------------------------------------------------------= --------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> ------------------------------------------------------------= --------

--
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221= 480390 - Fax 6221 419008 - Cell +49 173 6745902

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

-----------------------------------------------------------------= ---
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-----------------------------------------------------------------= ---
--001a114ab26ca4f972054e7bae18-- From nobody Mon May 1 13:04:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231FB129AEB for ; Mon, 1 May 2017 13:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_5mIbNtNIt4 for ; Mon, 1 May 2017 13:04:44 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 9288A1294D8 for ; Mon, 1 May 2017 13:02:07 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id q1so26697864qkd.2 for ; Mon, 01 May 2017 13:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uS8O00TB36norD2IsmPqZZskyKTKYoWMJT3LksMr0nQ=; b=SxgH1UlBVYyv6POSU1S69TtWVTttxRC2Z4UYha+W3QkOTSqGCunOrM+bbFLVHSH9Fa EmWBKrcQVg8irQMFh8mrPLBDGO+Ll6GnGAaOA6TYeGTxBhcU4KNWoSFKvJ40K+6rRG3p b11ZGt6b5IFqUnDdslFV1mlYhx4oWI02dtWWvZ7WDJPUcwOwNrSQjFIq+K2wp+WQVeZE igxVgPv68hv7kuOhdlqLFMH35qMXMjlbdJKD7AfVUb2kXU4jHV+lplYT2F4DeNecQy+b RdgPZjqRuu7WqAeP2nOx/3/ianXD+wQMCT44/pPQWozAJtt9HUG3gsmt1N9MBivUBAku 1cQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uS8O00TB36norD2IsmPqZZskyKTKYoWMJT3LksMr0nQ=; b=We6a5dRJKeaxf42MLgjlaGFoMEvbZ/Eh8hGN+sL37UGYXgY+v13I3YFT2dyn/fFoUs NTmwmx6ID+6ZRWNE/8+M0JYA7ZD0eTDhWNGPs333+wGBAJfxxTrgnAEDs4yve9+68T6h PU2MdCZWz9kQ/bO5TfPZvI80+B5OAYP6ar9vZndYMmCV6mDygT2bwvQUK3phXjZMrLfW 0EbNc0rqP0JGFHhQF4WXtH5YjLOeKEcRAWIOwLwZeabshUZd98sVt89zJEZvQmk4hJ3J ULwkzw2Z4lgJUjBe4/UrYuZvGtEMBnbbC3N5Qz6GFJXJMxl/SzbGvnH7J85X5IOn8yaB 8zhw== X-Gm-Message-State: AN3rC/4uOEXQrmAnPafj7h8oXIclPMoPguA89UtuZt3iGP1jP3i8gPAY mpELDCb7Ly/tZSJdkFnwvnKKozZfXg== X-Received: by 10.55.154.11 with SMTP id c11mr7277502qke.177.1493668926509; Mon, 01 May 2017 13:02:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Mon, 1 May 2017 13:02:05 -0700 (PDT) In-Reply-To: References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com> <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com> <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> From: Tom Herbert Date: Mon, 1 May 2017 13:02:05 -0700 Message-ID: Subject: Re: Proposed revised Extension Header text for rfc2460bis To: Robert Raszuk Cc: 6man WG , Mark Smith Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 20:04:46 -0000 On Mon, May 1, 2017 at 11:17 AM, Robert Raszuk wrote: > Ok ... if v6 transit routers drop extension headers in spite of dst address > being not themselves to me this sounds like a bug. > > It is behaviour against base v6 spec which allowed such EH to be inserted > into v6 packets by senders. Maybe bis spec should made it very clear and > mandate that transit routers MUST NOT alter EH in any way if the dst address > is not themselves. > That is not a requirement. EHs may be changed enroute per their specification. For instance, HBH options include a flag to indicate rather the option data may change in flight. Tom > Thx > R. > > On May 1, 2017 10:40, "Tom Herbert" wrote: >> >> On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk wrote: >> > Hi Mark, >> > >> >> Were any changes required to the MPLS header or MPLS forwarding >> >> operations to support SR? >> > >> > >> > If you would follow SR-MPLS you would realize that MPLS label carries an >> > embedded function. Exactly like SID in SRH. >> > >> > Moreover with the overhead of signaling required to established an LSP >> > in >> > MPLS case transit nodes no matter if they are within domain or beyond >> > domain >> > DO NOT NEED to change any single bit in their current forwarding >> > paradigm. >> > SR functions are executed only at the designated nodes which are able to >> > perform the desired forwarding behaviour. >> > >> > This entire discussion that maybe we will bless SRv6 in closed domains >> > just >> > does not get the fundamental point that transit nodes regardless on how >> > many >> > SRH are in the IPv6 packet will work just fine. >> >> I don't understand why we'd expect this to "work just fine"... There >> are still a lot of intermediate nodes that will arbitrarily drop >> extensions headers. So if one device inserts an extension header in a >> packet that previously had no extension headers and the packet is >> dropped down stream by some other device, then the device inserting >> headers has broken the end to end connectivity. What's worse is that >> the offending device won't even know packets are being dropped so it's >> can't do a happy eyeballs like algorithm like a host might be able to >> do. >> >> IMO, there is too much the emphasis here on the needs intermediate >> nodes and the value add they might provide without regard to the needs >> end hosts. IPv6 is, after all, a protocol that allow _hosts_ to >> communicate which may be facilitated intermediate routers. The >> assumption hosts make is that the IP packet sent from one host is >> received "as-is" on the other with only specific modifications allowed >> (options that may be modified in flight). In other words, if I, as a >> host, send a packet into the network, I expect that same packet to pop >> out at the receiver pretty much unchanged-- I don't expect the >> receiver to get some ad hoc re-interpretation of the packet by network >> nodes. This is implied by the robustness principle, fundamental to >> security, and needed to maintain connectivity. If network nodes want >> to modify packets in transit, insert extension headers, or other while >> in transit that might be reasonable per the requirements as long as 1) >> the changes are undone before delivering the packet to the receiving >> host, and 2) there are no other insidious effects like unexplained >> packet drop. >> >> Tom >> >> > Of course there is MTU >> > concern ... but this concern is also with MPLS stacking or for that >> > matter >> > with any encapsulation. And we do know today how to effectively solve it >> > when/where needed. >> > >> > It get's even worse if you (like some of this WG members) now require to >> > encapsulate packets in additional v6 header before SRH is inserted - >> > makes >> > zero sense ! Just please kindly observe that if you do the encap the dst >> > address can be anywhere in the Internet .. no encap code mandates that >> > dst >> > must be in your IGP. So packets do escape ASes .. BGP in fact was >> > explicitly >> > created to help/assist them to escape. >> > >> > I think perhaps a dedicated interim meeting should be setup just to >> > discuss >> > it and understand it well before we proceed with any further spec >> > clarifications or extensions. >> > >> > Best, >> > Robert >> > >> > PS. Leave alone other SRv6 features but does folks on this list do not >> > care >> > about TI-LFA ? >> > >> > >> >> >> >> >> >> Another difference between IPv6 and MPLS is that MPLS is not an >> >> end-to-end protocol, so it naturally creates and enforces local >> >> domains. To have MPLS frames successfully leak between two networks >> >> requires active enabling of MPLS on both ends of the links between >> >> them, which won't happen unless the MPLS networks explicitly agree to >> >> trade MPLS traffic, for explicit MPLS reasons, purposes and functions. >> >> >> >> IPv6 is an end-to-end protocol between hosts, that may transit >> >> multiple networks in between those hosts. IPv6 is brought up between >> >> two networks to provide services for any IPv6 applications. So SR >> >> wouldn't likely be the initial reason to enable IPv6 between two >> >> networks. Consequently, the likelihood of "internal" IPv6 SR packets >> >> going further than they should is naturally much higher. RFC1918 and >> >> similar have demonstrated that on the Internet, local or private "IP" >> >> domains aren't. >> >> >> >> Regards, >> >> Mark. >> > >> > >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- >> > From nobody Mon May 1 13:20:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914A712EA94 for ; Mon, 1 May 2017 13:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 WXACrveOmV5i for ; Mon, 1 May 2017 13:20:16 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 D36CB12422F for ; Mon, 1 May 2017 13:17:37 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id o3so44260368pgn.2 for ; Mon, 01 May 2017 13:17:37 -0700 (PDT) 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=gZzNJFwVk8KfepmFWy0FyoSzbw11t1s6RrhtiqwHtTk=; b=Wr8GoR/zn3eyOj2JRv+K5iHGU0WFfUAOhwI+hjpBgH66EmQHL2Hi6jKF/zn1rGIzN4 jQMJpHZCUxMlKVDzLzVQNrs7JRD4g87MX8Zuej1+4rjdkZVDiwtT7iLAMQtbmM9fqWa8 9r9f+ZOR2v58mRJYYJYAPCjg+BN6UQ1Jfo2KmOA6t+ZXuAqme4DCxxVynZoQMIYbH2vb 6wtMy1bWArEwrWQXUWAYtTdfWq6S1V+XBC6ndZO5n5d4zHf7YDgOzwvAGFQUe0iIsSXX KspNd45f96SCKGuJWgZvbGW9jwJ/NGL9kt0Hxt3nfhLdu8Ippiju5fMcCzJYyLGTpAqd 0/ng== 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=gZzNJFwVk8KfepmFWy0FyoSzbw11t1s6RrhtiqwHtTk=; b=okaRpkTifuNStWbW2U2PSlSKarpeEV5TOcK7X4YBl2+gGt7Im/pLdjsxi98IL1R2rR ELmRmytRcu64+qVZH6ECALgNl4V5gEsx3keHbemTa0o9A/zrREexMilyKsY8gQiddXkC 2Jhs/+0ByeQDMQpt/pTOW1B+diePwDVD+sgL3ccWrjZsw+DY4MYzCjiQEOv3egqls/UE VNoB+NYFw4D9XDLt+/5T7y5s/y3p3H7oo9eoouIICzAbwA1rrdmv+VhUo7kzq620OFES YdeFQdx9w03X+7XkIRFf17R7JERaU1yEi9iyqEGYtRLgx/1EvDbsyUmJ3UEZI1KtRViP GP4Q== X-Gm-Message-State: AN3rC/47SUxnWytnCtDCy9M/crpO6oKL4VlG0cTlO5pt3sjHKWFtC3O6 oDD7N3wU6dt0Ug== X-Received: by 10.98.44.198 with SMTP id s189mr28988546pfs.251.1493669857409; Mon, 01 May 2017 13:17:37 -0700 (PDT) Received: from [192.168.178.21] ([118.148.64.29]) by smtp.gmail.com with ESMTPSA id 202sm14193031pge.12.2017.05.01.13.17.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2017 13:17:36 -0700 (PDT) Subject: Re: Proposed revised Extension Header text for rfc2460bis To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , "Stefano Previdi (sprevidi)" References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com> <59036B64.4010008@cisco.com> <1CA0E022-B54D-455C-8063-0AE34DD2CCC2@cisco.com> Cc: "Ahmed Bashandy (bashandy)" , Fernando Gont , Bob Hinden , IPv6 List From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 2 May 2017 08:17:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 20:20:17 -0000 On 02/05/2017 05:47, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: =2E.. >> despite the various episodes, I still do not agree on the current text= =2E The WG Chairs and AD have already declared a rough consensus, though. =20 > These two points seem to suggest you're essentially rehashing the very > original point of the discussion, i.e., whether we should clarify the > ambiguity in RFC2460 with the original intent. In that case I'd > suggest you rather do so explicitly than pretend to make a minor > wording/editorial change. Personally, I think it's more productive if > we ship rfc2460bis and focus on updates sooner rather than hold > rfc2460bis by rehashing the very original point of the discussion. > While in my case I support the current text of rfc2460bis, I made my > comment so we can be more productive and get things (including updates > to rfc2460bis) done sooner. But apparently I failed in that attempt, s= o I'll > shut up here in this thread. +1 Brian From nobody Mon May 1 13:24:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B071200B9 for ; Mon, 1 May 2017 13:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.624 X-Spam-Level: X-Spam-Status: No, score=-12.624 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9yMNdahHfR6 for ; Mon, 1 May 2017 13:24:34 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DE8124D37 for ; Mon, 1 May 2017 13:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1634; q=dns/txt; s=iport; t=1493670082; x=1494879682; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OxmUlM1JafxBlHSf6LSwZx4yblWSDJxmOGOYw9ZDnnE=; b=QBENoNsJN45rTMD88zqzaerd/Apv+YFNp/MPXJJ3wKHdfKty2/t6cRA/ +UL03Vnl7bNws6LRYC+s8ynKJsl4TBRtueGvYyQO6TBRVI5GcgEO/ZHmE Y8wlrSXeMBmGOfWjwaDz6KhVOOJLkW6LcLy8rQ41Wh2VOpBKtciZrDwFT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAwCMlwdZ/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1WBbgeDYZtmiCKNS4IPhiQCGoQhQBcBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBIxFFBQsCAQYCGAICJgICAh8RFRACBA4FigcDDQiQT51hgiaHLA2DWwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2BC4VUggmCcIJUgg8Xgm8ugjEBBIk2iDCLMjs?= =?us-ascii?q?BjkKETpFeix2JDwEgATaBCm8VVgGGXXUBiCuBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,401,1488844800"; d="scan'208";a="417458376" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 May 2017 20:21:21 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v41KLLcl031006 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 May 2017 20:21:21 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 1 May 2017 16:21:20 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 1 May 2017 16:21:20 -0400 From: "Stefano Previdi (sprevidi)" To: Brian E Carpenter CC: =?utf-8?B?56We5piO6YGU5ZOJ?= , "Ahmed Bashandy (bashandy)" , Fernando Gont , "Bob Hinden" , IPv6 List Subject: Re: Proposed revised Extension Header text for rfc2460bis Thread-Topic: Proposed revised Extension Header text for rfc2460bis Thread-Index: AQHSv5CqvG2qal8sOEusPVCxbYji0aHZ9NeAgAFB4oCAAANqAIAAEa6AgAR7L/WAAGzcAIAAAQyA Date: Mon, 1 May 2017 20:21:20 +0000 Message-ID: <8C442C82-D1D5-49E3-858D-B7EDFBEC6817@cisco.com> References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com> <59036B64.4010008@cisco.com> <1CA0E022-B54D-455C-8063-0AE34DD2CCC2@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.204.252] Content-Type: text/plain; charset="utf-8" Content-ID: <42A11B518DF2584E84622FFC5F6A4318@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 20:24:37 -0000 DQo+IE9uIE1heSAxLCAyMDE3LCBhdCAxMDoxNyBQTSwgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwMi8wNS8yMDE3IDA1OjQ3 LCDnpZ7mmI7pgZTlk4kgd3JvdGU6DQo+IA0KPiAuLi4NCj4+PiBkZXNwaXRlIHRoZSB2YXJpb3Vz IGVwaXNvZGVzLCBJIHN0aWxsIGRvIG5vdCBhZ3JlZSBvbiB0aGUgY3VycmVudCB0ZXh0Lg0KPiAN Cj4gVGhlIFdHIENoYWlycw0KDQoNCmhhdmUgZGVjbGFyZWQgcm91Z2ggY29uc2Vuc3VzIG9uIGFu b3RoZXIgdGV4dCwgbGF0ZXIgY2hhbmdlZCBieSB0aGUgQUQuDQoNCnMuDQoNCg0KPiBhbmQgQUQg aGF2ZSBhbHJlYWR5IGRlY2xhcmVkIGEgcm91Z2ggY29uc2Vuc3VzLCB0aG91Z2guDQo+IA0KPj4g VGhlc2UgdHdvIHBvaW50cyBzZWVtIHRvIHN1Z2dlc3QgeW91J3JlIGVzc2VudGlhbGx5IHJlaGFz aGluZyB0aGUgdmVyeQ0KPj4gb3JpZ2luYWwgcG9pbnQgb2YgdGhlIGRpc2N1c3Npb24sIGkuZS4s IHdoZXRoZXIgd2Ugc2hvdWxkIGNsYXJpZnkgdGhlDQo+PiBhbWJpZ3VpdHkgaW4gUkZDMjQ2MCB3 aXRoIHRoZSBvcmlnaW5hbCBpbnRlbnQuICBJbiB0aGF0IGNhc2UgSSdkDQo+PiBzdWdnZXN0IHlv dSByYXRoZXIgZG8gc28gZXhwbGljaXRseSB0aGFuIHByZXRlbmQgdG8gbWFrZSBhIG1pbm9yDQo+ PiB3b3JkaW5nL2VkaXRvcmlhbCBjaGFuZ2UuICBQZXJzb25hbGx5LCBJIHRoaW5rIGl0J3MgbW9y ZSBwcm9kdWN0aXZlIGlmDQo+PiB3ZSBzaGlwIHJmYzI0NjBiaXMgYW5kIGZvY3VzIG9uIHVwZGF0 ZXMgc29vbmVyIHJhdGhlciB0aGFuIGhvbGQNCj4+IHJmYzI0NjBiaXMgYnkgcmVoYXNoaW5nIHRo ZSB2ZXJ5IG9yaWdpbmFsIHBvaW50IG9mIHRoZSBkaXNjdXNzaW9uLg0KPj4gV2hpbGUgaW4gbXkg Y2FzZSBJIHN1cHBvcnQgdGhlIGN1cnJlbnQgdGV4dCBvZiByZmMyNDYwYmlzLCBJIG1hZGUgbXkN Cj4+IGNvbW1lbnQgc28gd2UgY2FuIGJlIG1vcmUgcHJvZHVjdGl2ZSBhbmQgZ2V0IHRoaW5ncyAo aW5jbHVkaW5nIHVwZGF0ZXMNCj4+IHRvIHJmYzI0NjBiaXMpIGRvbmUgc29vbmVyLiAgQnV0IGFw cGFyZW50bHkgSSBmYWlsZWQgaW4gdGhhdCBhdHRlbXB0LCBzbyBJJ2xsDQo+PiBzaHV0IHVwIGhl cmUgaW4gdGhpcyB0aHJlYWQuDQo+IA0KPiArMQ0KPiANCj4gICAgIEJyaWFuDQo+IA0KDQo= From nobody Mon May 1 15:29:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE7412EB19 for ; Mon, 1 May 2017 15:29:52 -0700 (PDT) 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 qLMeio23Zrd4 for ; Mon, 1 May 2017 15:29:50 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 9C51212952D for ; Mon, 1 May 2017 15:27:26 -0700 (PDT) Received: from mb.local ([IPv6:2620:11a:c081:20:b160:696e:29b5:9c76]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v41MRDgd095565 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 1 May 2017 22:27:13 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:b160:696e:29b5:9c76] claimed to be mb.local Subject: Re: Proposed revised Extension Header text for rfc2460bis To: Robert Raszuk , Enno Rey Cc: 6man WG References: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> <20170501185128.GB23490@ernw.de> From: joel jaeggli Message-ID: Date: Mon, 1 May 2017 15:27:06 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Thunderbird/53.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1TVIsQ4XjmcPrXXLTQQ1bHsWKtSUT3oX3" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 22:29:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1TVIsQ4XjmcPrXXLTQQ1bHsWKtSUT3oX3 Content-Type: multipart/mixed; boundary="DR4rb10ovjP4d9567G0sL8RRKNGSEHXWA"; protected-headers="v1" From: joel jaeggli To: Robert Raszuk , Enno Rey Cc: 6man WG Message-ID: Subject: Re: Proposed revised Extension Header text for rfc2460bis References: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> <20170501185128.GB23490@ernw.de> In-Reply-To: --DR4rb10ovjP4d9567G0sL8RRKNGSEHXWA Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/1/17 12:46 PM, Robert Raszuk wrote: > Good thing that no one is putting firewall in global Internet transit D= FZ. >=20 > So how this applies to this concern of transit nodes in the Internet > remove EHs ? It would be rather odd for a device to attempt to remove Extension Headers, it would be somewhat less surprising to see packets where the l4 header cannot be found filtered, which applies to cases other then for example new extension headers as well, for example non-initial fragements. In modern internet protocol routers, there are a number of reasons why recourse to the L4 header might be practically required, these include variously the application of control-plane acls (which may of course include traffic set through rather than to the box), the application of forwarding plane acls (example 5575 bgp flowspec rules, static acls, etc), hashing, needs to perform qos marking and so on. in the cases where an asic's lookup space precludes processing the extension header chain, or where for other reasons the l4 header cannot be identified it is clearly problematic to unconditionally forward the packet. > Cheers > R. >=20 > On May 1, 2017 11:54, "Enno Rey" > w= rote: >=20 > Fred, >=20 > On Mon, May 01, 2017 at 11:29:17AM -0700, Fred Baker wrote: > > Indeed. My understanding of the complaint is that > > - some routers may be configured with ACLs that enforce rules > about extension headers, precluding any extension headers, specific= > types of extension headers, or limiting extension headers to certai= n > types. > > - some routers may be configured with ACLs that worry about > TCP/UDP port numbers, and drop packets for various reasons relating= > to the number of extension headers found, the IPv6 header actually > fitting in working RAM in the chip, or other errors > > - if ACL handing is punted to another processor, it is often > rate limited > > - firewalls, in particular, may be configured to worry about th= e > presence of fragmentation headers > > > > Those are indeed contrary to the specification, and if a router o= r > firewall did it by default it would be in violation. >=20 > actually the majority of commercial enterprise firewalls perform > some filtering of EHs, at least as for their number or order (which= > both are not restricted too much in RFC 2460), by default. These ar= e > results for some testing we did in 2014 (I doubt much has changed > until today. if it has probably things have not become more > flexible/liberal): >=20 > https://www.ernw.de/download/AAtlasis-RISC-project-presentation-%20= results.pdf > >=20 > best >=20 > Enno >=20 >=20 >=20 >=20 >=20 > That said, there are equipment limitations in some cases and > operator configurations in others that can have the effect. > > > > > On May 1, 2017, at 11:17 AM, Robert Raszuk > wrote: > > > > > > Ok ... if v6 transit routers drop extension headers in spite of= > dst address being not themselves to me this sounds like a bug. > > > > > > It is behaviour against base v6 spec which allowed such EH to b= e > inserted into v6 packets by senders. Maybe bis spec should made it > very clear and mandate that transit routers MUST NOT alter EH in an= y > way if the dst address is not themselves. > > > > > > Thx > > > R. > > > > > > On May 1, 2017 10:40, "Tom Herbert" > wrote: > > > On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk > > wrote: > > > > Hi Mark, > > > > > > > >> Were any changes required to the MPLS header or MPLS forward= ing > > > >> operations to support SR? > > > > > > > > > > > > If you would follow SR-MPLS you would realize that MPLS label= > carries an > > > > embedded function. Exactly like SID in SRH. > > > > > > > > Moreover with the overhead of signaling required to > established an LSP in > > > > MPLS case transit nodes no matter if they are within domain o= r > beyond domain > > > > DO NOT NEED to change any single bit in their current > forwarding paradigm. > > > > SR functions are executed only at the designated nodes which > are able to > > > > perform the desired forwarding behaviour. > > > > > > > > This entire discussion that maybe we will bless SRv6 in close= d > domains just > > > > does not get the fundamental point that transit nodes > regardless on how many > > > > SRH are in the IPv6 packet will work just fine. > > > > > > I don't understand why we'd expect this to "work just fine"... = There > > > are still a lot of intermediate nodes that will arbitrarily dro= p > > > extensions headers. So if one device inserts an extension heade= r > in a > > > packet that previously had no extension headers and the packet = is > > > dropped down stream by some other device, then the device inser= ting > > > headers has broken the end to end connectivity. What's worse is= that > > > the offending device won't even know packets are being dropped > so it's > > > can't do a happy eyeballs like algorithm like a host might be > able to > > > do. > > > > > > IMO, there is too much the emphasis here on the needs intermedi= ate > > > nodes and the value add they might provide without regard to th= e > needs > > > end hosts. IPv6 is, after all, a protocol that allow _hosts_ to= > > > communicate which may be facilitated intermediate routers. The > > > assumption hosts make is that the IP packet sent from one host = is > > > received "as-is" on the other with only specific modifications > allowed > > > (options that may be modified in flight). In other words, if I,= as a > > > host, send a packet into the network, I expect that same packet= > to pop > > > out at the receiver pretty much unchanged-- I don't expect the > > > receiver to get some ad hoc re-interpretation of the packet by > network > > > nodes. This is implied by the robustness principle, fundamental= to > > > security, and needed to maintain connectivity. If network nodes= want > > > to modify packets in transit, insert extension headers, or othe= r > while > > > in transit that might be reasonable per the requirements as lon= g > as 1) > > > the changes are undone before delivering the packet to the rece= iving > > > host, and 2) there are no other insidious effects like unexplai= ned > > > packet drop. > > > > > > Tom > > > > > > > Of course there is MTU > > > > concern ... but this concern is also with MPLS stacking or fo= r > that matter > > > > with any encapsulation. And we do know today how to > effectively solve it > > > > when/where needed. > > > > > > > > It get's even worse if you (like some of this WG members) now= > require to > > > > encapsulate packets in additional v6 header before SRH is > inserted - makes > > > > zero sense ! Just please kindly observe that if you do the > encap the dst > > > > address can be anywhere in the Internet .. no encap code > mandates that dst > > > > must be in your IGP. So packets do escape ASes .. BGP in fact= > was explicitly > > > > created to help/assist them to escape. > > > > > > > > I think perhaps a dedicated interim meeting should be setup > just to discuss > > > > it and understand it well before we proceed with any further = spec > > > > clarifications or extensions. > > > > > > > > Best, > > > > Robert > > > > > > > > PS. Leave alone other SRv6 features but does folks on this > list do not care > > > > about TI-LFA ? > > > > > > > > > > > >> > > > >> > > > >> Another difference between IPv6 and MPLS is that MPLS is not= an > > > >> end-to-end protocol, so it naturally creates and enforces lo= cal > > > >> domains. To have MPLS frames successfully leak between two > networks > > > >> requires active enabling of MPLS on both ends of the links > between > > > >> them, which won't happen unless the MPLS networks explicitly= > agree to > > > >> trade MPLS traffic, for explicit MPLS reasons, purposes and > functions. > > > >> > > > >> IPv6 is an end-to-end protocol between hosts, that may trans= it > > > >> multiple networks in between those hosts. IPv6 is brought up= > between > > > >> two networks to provide services for any IPv6 applications. = So SR > > > >> wouldn't likely be the initial reason to enable IPv6 between= two > > > >> networks. Consequently, the likelihood of "internal" IPv6 SR= > packets > > > >> going further than they should is naturally much higher. > RFC1918 and > > > >> similar have demonstrated that on the Internet, local or > private "IP" > > > >> domains aren't. > > > >> > > > >> Regards, > > > >> Mark. > > > > > > > > > > > > > > > > > -------------------------------------------------------------------= - > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > -------------------------------------------------------------------= - > > > > > > > ---------------------------------------------------------------= ----- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > > ---------------------------------------------------------------= ----- > > > > -----------------------------------------------------------------= --- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > -----------------------------------------------------------------= --- >=20 > -- > Enno Rey >=20 > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > > Tel. +49 6221 480390 - Fax 6221 419008 = - > Cell +49 173 6745902 >=20 > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Enno Rey >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Blog: www.insinuator.net || Conference:= > www.troopers.de > Twitter: @Enno_Insinuator > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > -------------------------------------------------------------------= - > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6= > > -------------------------------------------------------------------= - >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --DR4rb10ovjP4d9567G0sL8RRKNGSEHXWA-- --1TVIsQ4XjmcPrXXLTQQ1bHsWKtSUT3oX3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlkHtjsACgkQ8AA1q7Z/VrJ/xQCfXL47VBQM0TSLWYJOOGEVddaQ aG8An3e3sbE6Usj8MnVt+2LRFfTUJs7S =11Sj -----END PGP SIGNATURE----- --1TVIsQ4XjmcPrXXLTQQ1bHsWKtSUT3oX3-- From nobody Mon May 1 15:50:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15A812EAB5 for ; Mon, 1 May 2017 15:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2jZL3hPylU2 for ; Mon, 1 May 2017 15:49:58 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD964129C6A for ; Mon, 1 May 2017 15:48:02 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id c45so99297584qtb.1 for ; Mon, 01 May 2017 15:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HLx1iJC63+FXtqGa6BVHkNM4DB+KDsBF6kj56QA6mkQ=; b=inCGhjeRmA9lUhK3IUmwAZA2MoTRTr5BaE5kN33ewEzj1TfPYfqXhQTN5OZ80LzF02 Q5AwLFpqcCyjNuEBoP95gs3E8FsLLen2C+/HetuQ3EjWDlgyXyxOSicIQ0MmsPnepNez erCEUmJ+pWToR8Lrz2UKaNcbqbeoL27jBaH2KXGsRcGNyEtq5S78aUCZ0mpYbkSGOtc3 dUANCXWloLgeJAdZ63n6mThILgz5Jy6aqWLRMD71JAXbEvVhTIu9MXEWZmVjJI3/7ta5 Gnzi9LQkvEYg1DOXi1eBGKZAcLxGnCyYcTeWqftfn0po9TaqazLeJJzKG78nNrnCCf+k hnzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HLx1iJC63+FXtqGa6BVHkNM4DB+KDsBF6kj56QA6mkQ=; b=BMwh99mRS9kJW0kjgqz0lB+x9OjbEmoWW7wX6zSi+jY1GElxjJQsrygMCymKpZ+azl EmAI2zx4bwvvBui9OGEt3XOk7WU16f9XZRBXj5frk4plLKJG34FIe368JnEQQpQ83GdZ yJ4fO0olHIfZX2mQ1hlJ3suEfYozsLM7K4EHyuRGwj1T4v9NI8q26XPVukNiTGQ39qL+ ngn49k3wZhWXAljLC4O2nRXBK/+US7V47mECPXp2fjPSmvgdURWHeFmf0S7+1VGY6igo JY5IxGm+XNyNkWxUac5XSN6Rf3hfkhNvTyAUbIE985N6AL64W/O4IGEuM3W+LIGK7+ev XlDA== X-Gm-Message-State: AN3rC/5fhs51s/QH5vX9MhkTFX4DUFOG6zAzVhOE0hXNBxQKgIb/xQfD VMUA//98zk2WuBWWjCrKEUR9/cxy/Q== X-Received: by 10.200.49.1 with SMTP id g1mr25181877qtb.200.1493678881659; Mon, 01 May 2017 15:48:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Mon, 1 May 2017 15:48:00 -0700 (PDT) In-Reply-To: References: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> <20170501185128.GB23490@ernw.de> From: Tom Herbert Date: Mon, 1 May 2017 15:48:00 -0700 Message-ID: Subject: Re: Proposed revised Extension Header text for rfc2460bis To: joel jaeggli Cc: Robert Raszuk , Enno Rey , 6man WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 22:50:01 -0000 On Mon, May 1, 2017 at 3:27 PM, joel jaeggli wrote: > On 5/1/17 12:46 PM, Robert Raszuk wrote: >> Good thing that no one is putting firewall in global Internet transit DFZ. >> >> So how this applies to this concern of transit nodes in the Internet >> remove EHs ? > > It would be rather odd for a device to attempt to remove Extension > Headers, it would be somewhat less surprising to see packets where the > l4 header cannot be found filtered, which applies to cases other then > for example new extension headers as well, for example non-initial > fragements. > > In modern internet protocol routers, there are a number of reasons why > recourse to the L4 header might be practically required, these include > variously the application of control-plane acls (which may of course > include traffic set through rather than to the box), the application of > forwarding plane acls (example 5575 bgp flowspec rules, static acls, > etc), hashing, needs to perform qos marking and so on. in the cases > where an asic's lookup space precludes processing the extension header > chain, or where for other reasons the l4 header cannot be identified it > is clearly problematic to unconditionally forward the packet. > It doesn't seem likely that this behavior is going to go away any time soon, if ever. Maybe instead of just dropping packet these devices should send back an ICMP error to inform the sender of which EH caused the drop? Tom > >> Cheers >> R. >> >> On May 1, 2017 11:54, "Enno Rey" > wrote: >> >> Fred, >> >> On Mon, May 01, 2017 at 11:29:17AM -0700, Fred Baker wrote: >> > Indeed. My understanding of the complaint is that >> > - some routers may be configured with ACLs that enforce rules >> about extension headers, precluding any extension headers, specific >> types of extension headers, or limiting extension headers to certain >> types. >> > - some routers may be configured with ACLs that worry about >> TCP/UDP port numbers, and drop packets for various reasons relating >> to the number of extension headers found, the IPv6 header actually >> fitting in working RAM in the chip, or other errors >> > - if ACL handing is punted to another processor, it is often >> rate limited >> > - firewalls, in particular, may be configured to worry about the >> presence of fragmentation headers >> > >> > Those are indeed contrary to the specification, and if a router or >> firewall did it by default it would be in violation. >> >> actually the majority of commercial enterprise firewalls perform >> some filtering of EHs, at least as for their number or order (which >> both are not restricted too much in RFC 2460), by default. These are >> results for some testing we did in 2014 (I doubt much has changed >> until today. if it has probably things have not become more >> flexible/liberal): >> >> https://www.ernw.de/download/AAtlasis-RISC-project-presentation-%20results.pdf >> >> >> best >> >> Enno >> >> >> >> >> >> That said, there are equipment limitations in some cases and >> operator configurations in others that can have the effect. >> > >> > > On May 1, 2017, at 11:17 AM, Robert Raszuk > > wrote: >> > > >> > > Ok ... if v6 transit routers drop extension headers in spite of >> dst address being not themselves to me this sounds like a bug. >> > > >> > > It is behaviour against base v6 spec which allowed such EH to be >> inserted into v6 packets by senders. Maybe bis spec should made it >> very clear and mandate that transit routers MUST NOT alter EH in any >> way if the dst address is not themselves. >> > > >> > > Thx >> > > R. >> > > >> > > On May 1, 2017 10:40, "Tom Herbert" > > wrote: >> > > On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk >> > wrote: >> > > > Hi Mark, >> > > > >> > > >> Were any changes required to the MPLS header or MPLS forwarding >> > > >> operations to support SR? >> > > > >> > > > >> > > > If you would follow SR-MPLS you would realize that MPLS label >> carries an >> > > > embedded function. Exactly like SID in SRH. >> > > > >> > > > Moreover with the overhead of signaling required to >> established an LSP in >> > > > MPLS case transit nodes no matter if they are within domain or >> beyond domain >> > > > DO NOT NEED to change any single bit in their current >> forwarding paradigm. >> > > > SR functions are executed only at the designated nodes which >> are able to >> > > > perform the desired forwarding behaviour. >> > > > >> > > > This entire discussion that maybe we will bless SRv6 in closed >> domains just >> > > > does not get the fundamental point that transit nodes >> regardless on how many >> > > > SRH are in the IPv6 packet will work just fine. >> > > >> > > I don't understand why we'd expect this to "work just fine"... There >> > > are still a lot of intermediate nodes that will arbitrarily drop >> > > extensions headers. So if one device inserts an extension header >> in a >> > > packet that previously had no extension headers and the packet is >> > > dropped down stream by some other device, then the device inserting >> > > headers has broken the end to end connectivity. What's worse is that >> > > the offending device won't even know packets are being dropped >> so it's >> > > can't do a happy eyeballs like algorithm like a host might be >> able to >> > > do. >> > > >> > > IMO, there is too much the emphasis here on the needs intermediate >> > > nodes and the value add they might provide without regard to the >> needs >> > > end hosts. IPv6 is, after all, a protocol that allow _hosts_ to >> > > communicate which may be facilitated intermediate routers. The >> > > assumption hosts make is that the IP packet sent from one host is >> > > received "as-is" on the other with only specific modifications >> allowed >> > > (options that may be modified in flight). In other words, if I, as a >> > > host, send a packet into the network, I expect that same packet >> to pop >> > > out at the receiver pretty much unchanged-- I don't expect the >> > > receiver to get some ad hoc re-interpretation of the packet by >> network >> > > nodes. This is implied by the robustness principle, fundamental to >> > > security, and needed to maintain connectivity. If network nodes want >> > > to modify packets in transit, insert extension headers, or other >> while >> > > in transit that might be reasonable per the requirements as long >> as 1) >> > > the changes are undone before delivering the packet to the receiving >> > > host, and 2) there are no other insidious effects like unexplained >> > > packet drop. >> > > >> > > Tom >> > > >> > > > Of course there is MTU >> > > > concern ... but this concern is also with MPLS stacking or for >> that matter >> > > > with any encapsulation. And we do know today how to >> effectively solve it >> > > > when/where needed. >> > > > >> > > > It get's even worse if you (like some of this WG members) now >> require to >> > > > encapsulate packets in additional v6 header before SRH is >> inserted - makes >> > > > zero sense ! Just please kindly observe that if you do the >> encap the dst >> > > > address can be anywhere in the Internet .. no encap code >> mandates that dst >> > > > must be in your IGP. So packets do escape ASes .. BGP in fact >> was explicitly >> > > > created to help/assist them to escape. >> > > > >> > > > I think perhaps a dedicated interim meeting should be setup >> just to discuss >> > > > it and understand it well before we proceed with any further spec >> > > > clarifications or extensions. >> > > > >> > > > Best, >> > > > Robert >> > > > >> > > > PS. Leave alone other SRv6 features but does folks on this >> list do not care >> > > > about TI-LFA ? >> > > > >> > > > >> > > >> >> > > >> >> > > >> Another difference between IPv6 and MPLS is that MPLS is not an >> > > >> end-to-end protocol, so it naturally creates and enforces local >> > > >> domains. To have MPLS frames successfully leak between two >> networks >> > > >> requires active enabling of MPLS on both ends of the links >> between >> > > >> them, which won't happen unless the MPLS networks explicitly >> agree to >> > > >> trade MPLS traffic, for explicit MPLS reasons, purposes and >> functions. >> > > >> >> > > >> IPv6 is an end-to-end protocol between hosts, that may transit >> > > >> multiple networks in between those hosts. IPv6 is brought up >> between >> > > >> two networks to provide services for any IPv6 applications. So SR >> > > >> wouldn't likely be the initial reason to enable IPv6 between two >> > > >> networks. Consequently, the likelihood of "internal" IPv6 SR >> packets >> > > >> going further than they should is naturally much higher. >> RFC1918 and >> > > >> similar have demonstrated that on the Internet, local or >> private "IP" >> > > >> domains aren't. >> > > >> >> > > >> Regards, >> > > >> Mark. >> > > > >> > > > >> > > > >> > > > >> -------------------------------------------------------------------- >> > > > IETF IPv6 working group mailing list >> > > > ipv6@ietf.org >> > > > Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> >> > > > >> -------------------------------------------------------------------- >> > > > >> > > -------------------------------------------------------------------- >> > > IETF IPv6 working group mailing list >> > > ipv6@ietf.org >> > > Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> >> > > -------------------------------------------------------------------- >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> >> > -------------------------------------------------------------------- >> >> -- >> Enno Rey >> >> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de >> >> Tel. +49 6221 480390 - Fax 6221 419008 - >> Cell +49 173 6745902 >> >> Handelsregister Mannheim: HRB 337135 >> Geschaeftsfuehrer: Enno Rey >> >> ======================================================= >> Blog: www.insinuator.net || Conference: >> www.troopers.de >> Twitter: @Enno_Insinuator >> ======================================================= >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> >> -------------------------------------------------------------------- >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon May 1 15:50:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A450129C6B for ; Mon, 1 May 2017 15:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 y9sep2MgfsXI for ; Mon, 1 May 2017 15:50:51 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 A0EB7129572 for ; Mon, 1 May 2017 15:48:28 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id j59so73654274uad.0 for ; Mon, 01 May 2017 15:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vLZEHvJ+JjeYKSWo4duq4rZigGDeV5TvZ9uG9diiBAA=; b=ffV8WbRVHGsz7wbAUDKUkrKSEAfexjA8t5vfXiaCVEWrXIVvR519HtWgivHwTg6VHO PYRYJ6lwK0iNHw7f2DYWgrZwzM4uCP8XV7NCgf5pcFaHVTPQhjyxS3ISJixnoZVlLZgW yBg4+Ok5XAkkuvysPMWR7wfMJq+nX9TFreQSHa3KfLema03XHIMPIdcHIUP3Vtxta8vu H8XSJchR806wmJzPgoKJqfYm80jIQGHkQ1gVeIFIEnin/QfiRS5PraaTcRA4u6fnhFcd 5/ZH/JapQf5JImFRJeDrlydQZNSlgs2bi0zgyOLeILVR+4a7BA53Ptl91K46CJBlybVw vxqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vLZEHvJ+JjeYKSWo4duq4rZigGDeV5TvZ9uG9diiBAA=; b=S9nrJHqw9R5VcyX77WFZj6bSVAsBNi03yLY5d/5xnolpyNnRg0J1kGuiqqgWw6AEUI N3eLhdUHOAXBD4fCynNJ6y7fDkuQkh9NlUNUlQnDixxeSy7cBLpn8VC4uGPha7bg/G7A QTwY2aSbz674pwdGepnbM/ot1rYUpowq2uT7IEm/m1RsvM3S5WZrMtQGxEOkbX6Z+q9Q W3BL89XWUkuYHszniaxIpwX8CdUh9xQ2gpaQjCsUc8xL2cutFg0xC5nTBj0V9gCeg8X9 9zeKhGCi+EFxT0miOFO3UWgqPygjAwZorPtlC9ghgqmzanxPteiWU7EL7vkL+MiCN/7s o3ng== X-Gm-Message-State: AN3rC/4bPxUBnPEaZgi2DZn8Ryi9CvoBACN80CxNKqbHAsQdtSMkBtku qi1DFDHjfVza2e0SLtTEaxELonnZnpgK X-Received: by 10.159.38.194 with SMTP id 60mr12330200uay.70.1493678907606; Mon, 01 May 2017 15:48:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.130 with HTTP; Mon, 1 May 2017 15:47:56 -0700 (PDT) In-Reply-To: References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com> <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com> <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> From: Mark Smith Date: Tue, 2 May 2017 08:47:56 +1000 Message-ID: Subject: Re: Proposed revised Extension Header text for rfc2460bis To: Robert Raszuk Cc: Tom Herbert , 6man WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 22:50:53 -0000 On 2 May 2017 at 04:17, Robert Raszuk wrote: > Ok ... if v6 transit routers drop extension headers in spite of dst address > being not themselves to me this sounds like a bug. > > It is behaviour against base v6 spec which allowed such EH to be inserted > into v6 packets by senders. Maybe bis spec should made it very clear and > mandate that transit routers MUST NOT alter EH in any way if the dst address > is not themselves. This is what RFC1883 said, which is also the text in RFC2460. It literally says that, just without RFC2119 capitalisation. "With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." I struggle to see how that is ambiguous, unless some people are confused by what the words and terms "are not", "examined" or "processed" mean. That may be possible if English is not somebody's first language, however I'd have thought they'd encountered those words often enough in this field that it would be clear what they mean e.g. the "Processing" in CPU. Their meanings could be clarified, however any clarification would not be changing the meaning of the statement. A simpler version would have been: "With one exception, extension headers are ignored by nodes along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." So the RFC1883/2460 versions are already making clarifications that in terms of English language meaning are unnecessary. Regards, Mark. > Thx > R. > > On May 1, 2017 10:40, "Tom Herbert" wrote: >> >> On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk wrote: >> > Hi Mark, >> > >> >> Were any changes required to the MPLS header or MPLS forwarding >> >> operations to support SR? >> > >> > >> > If you would follow SR-MPLS you would realize that MPLS label carries an >> > embedded function. Exactly like SID in SRH. >> > >> > Moreover with the overhead of signaling required to established an LSP >> > in >> > MPLS case transit nodes no matter if they are within domain or beyond >> > domain >> > DO NOT NEED to change any single bit in their current forwarding >> > paradigm. >> > SR functions are executed only at the designated nodes which are able to >> > perform the desired forwarding behaviour. >> > >> > This entire discussion that maybe we will bless SRv6 in closed domains >> > just >> > does not get the fundamental point that transit nodes regardless on how >> > many >> > SRH are in the IPv6 packet will work just fine. >> >> I don't understand why we'd expect this to "work just fine"... There >> are still a lot of intermediate nodes that will arbitrarily drop >> extensions headers. So if one device inserts an extension header in a >> packet that previously had no extension headers and the packet is >> dropped down stream by some other device, then the device inserting >> headers has broken the end to end connectivity. What's worse is that >> the offending device won't even know packets are being dropped so it's >> can't do a happy eyeballs like algorithm like a host might be able to >> do. >> >> IMO, there is too much the emphasis here on the needs intermediate >> nodes and the value add they might provide without regard to the needs >> end hosts. IPv6 is, after all, a protocol that allow _hosts_ to >> communicate which may be facilitated intermediate routers. The >> assumption hosts make is that the IP packet sent from one host is >> received "as-is" on the other with only specific modifications allowed >> (options that may be modified in flight). In other words, if I, as a >> host, send a packet into the network, I expect that same packet to pop >> out at the receiver pretty much unchanged-- I don't expect the >> receiver to get some ad hoc re-interpretation of the packet by network >> nodes. This is implied by the robustness principle, fundamental to >> security, and needed to maintain connectivity. If network nodes want >> to modify packets in transit, insert extension headers, or other while >> in transit that might be reasonable per the requirements as long as 1) >> the changes are undone before delivering the packet to the receiving >> host, and 2) there are no other insidious effects like unexplained >> packet drop. >> >> Tom >> >> > Of course there is MTU >> > concern ... but this concern is also with MPLS stacking or for that >> > matter >> > with any encapsulation. And we do know today how to effectively solve it >> > when/where needed. >> > >> > It get's even worse if you (like some of this WG members) now require to >> > encapsulate packets in additional v6 header before SRH is inserted - >> > makes >> > zero sense ! Just please kindly observe that if you do the encap the dst >> > address can be anywhere in the Internet .. no encap code mandates that >> > dst >> > must be in your IGP. So packets do escape ASes .. BGP in fact was >> > explicitly >> > created to help/assist them to escape. >> > >> > I think perhaps a dedicated interim meeting should be setup just to >> > discuss >> > it and understand it well before we proceed with any further spec >> > clarifications or extensions. >> > >> > Best, >> > Robert >> > >> > PS. Leave alone other SRv6 features but does folks on this list do not >> > care >> > about TI-LFA ? >> > >> > >> >> >> >> >> >> Another difference between IPv6 and MPLS is that MPLS is not an >> >> end-to-end protocol, so it naturally creates and enforces local >> >> domains. To have MPLS frames successfully leak between two networks >> >> requires active enabling of MPLS on both ends of the links between >> >> them, which won't happen unless the MPLS networks explicitly agree to >> >> trade MPLS traffic, for explicit MPLS reasons, purposes and functions. >> >> >> >> IPv6 is an end-to-end protocol between hosts, that may transit >> >> multiple networks in between those hosts. IPv6 is brought up between >> >> two networks to provide services for any IPv6 applications. So SR >> >> wouldn't likely be the initial reason to enable IPv6 between two >> >> networks. Consequently, the likelihood of "internal" IPv6 SR packets >> >> going further than they should is naturally much higher. RFC1918 and >> >> similar have demonstrated that on the Internet, local or private "IP" >> >> domains aren't. >> >> >> >> Regards, >> >> Mark. >> > >> > >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- >> > From nobody Mon May 1 16:11:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0214C12EB15 for ; Mon, 1 May 2017 16:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sNOkWYErI0jA for ; Mon, 1 May 2017 16:11:06 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8056E12EB27 for ; Mon, 1 May 2017 16:09:02 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id t7so51139625pgt.3 for ; Mon, 01 May 2017 16:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=PEAgNiytgGsx4q8vLhg+BUHzAxEijYHYjhN6dSEW6xU=; b=teE2qYVvZgCpgQSCWDXx30Y5xgu2OCDgx89ORxhtj5CqZCaUtLO3A9E5TtiLf8unEr CslE5QCvTfjjSpHPYxpr7dyKDQZeldIeSBKKs4JD5B/lnKY+U/aRDhVLdNUKpKUzHg6S xenxVllfuwYH7zlguoRTMuePfCCk41bz8LjyZIGjoraAsQB7Isiig2N+5D13ectpNaKY mRkbvYm1mchpQ/aD7DmOYAQ0XwaIlRKUHXc+sx1XD3eiv3xfxoGNN26u5XHs+1Vz2pHy G5j0y2+U2R7tH5kzuZjXOBLrsPzVgw6xbHEAaGoBpVFy2yJjfXjRnvwMbGXxPQ2KFh/E Im0Q== 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:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=PEAgNiytgGsx4q8vLhg+BUHzAxEijYHYjhN6dSEW6xU=; b=p/hWCdYSHHlC8xWY+U0aJt+74hiwHMFh75JxxQBGbuu0DEKa7ZgZsQJM1Q2tLcmI37 WDmdc+M9gGVDOnX7iWPM5CrSZdV9WrZVImK/6aAA+m7NvEGy55LDm3bTa+UN4zYTagmS 8CqZqZRa8zkvYzSw0k0KAV7TtzAja1hYLJ24NR475QHkmcOD2SIajJo8U5ACmCTim47n RvRGHHrOEYY0BYuD9f0oNU3EF20xmWwW9zkTFfh3LkRwuJJyD9zoGdgCacagetyaH1tq mLbRqFC23DH10sUoKCoVBK2jBkR+/+nTimkGYZ1YUJsrG/RkSV8QvzanfGtC5R+toDJC MWbw== X-Gm-Message-State: AN3rC/4R+NYKGqQ+B235NGtKek2n0JwBmsb1u6IK7xaETPg+xkqKHp+O iw7SQZAtwcbr4eyr X-Received: by 10.99.112.66 with SMTP id a2mr10484632pgn.7.1493680141905; Mon, 01 May 2017 16:09:01 -0700 (PDT) Received: from [130.216.38.57] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.57]) by smtp.gmail.com with ESMTPSA id y123sm26186955pfg.52.2017.05.01.16.09.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2017 16:09:01 -0700 (PDT) Subject: Looping [was: Proposed revised Extension Header text for rfc2460bis] To: 6man WG References: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> <20170501185128.GB23490@ernw.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 2 May 2017 11:09:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 23:11:09 -0000 On 02/05/2017 10:48, Tom Herbert wrote: > On Mon, May 1, 2017 at 3:27 PM, joel jaeggli wrote: ... >> In modern internet protocol routers, there are a number of reasons why >> recourse to the L4 header might be practically required, these include >> variously the application of control-plane acls (which may of course >> include traffic set through rather than to the box), the application of >> forwarding plane acls (example 5575 bgp flowspec rules, static acls, >> etc), hashing, needs to perform qos marking and so on. in the cases >> where an asic's lookup space precludes processing the extension header >> chain, or where for other reasons the l4 header cannot be identified it >> is clearly problematic to unconditionally forward the packet. >> > It doesn't seem likely that this behavior is going to go away any time > soon, if ever. Maybe instead of just dropping packet these devices > should send back an ICMP error to inform the sender of which EH caused > the drop? Since unknown ICMPv6 is at high risk of being dropped too, this is unlikely to help. People, we discussed all this while RFC7045 was being drafted, and many other times as well. What has it got to do with the final wordsmithing of the IPv6 Internet Standard, where the technical (rough) consensus is already known? Brian From nobody Mon May 1 16:13:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B77E12EAD2 for ; Mon, 1 May 2017 16:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 kziXeficVHBd for ; Mon, 1 May 2017 16:13:10 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 F054312EAE2 for ; Mon, 1 May 2017 16:10:57 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id a103so133825141ioj.1 for ; Mon, 01 May 2017 16:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Nk9Y6QJakNrYOS3JKF2H9NdOYv17Rj/XoxOuMnosO+w=; b=LjA7eg0gs3lalzo5lOlsUTs6BgUvo6K+zzeTdxy9A1vaqKpbydK0BPSEr3yV7a5hek zzj3xMHpexeIkVklsV/sOfcT4ET/3zBP5SHbyiiDEnBWgOoGLh40QnmZWE/e2aQFW5rl aKSGaOhD6ArrtpWnKx5/x1R2qCi5Ng0O7XZuIBdlCZ3og3p2o3tPmfgR64i/WfkNEDOj 1Fk75nBKYXUQGXxM5JMkGJ/Dm+YQWGAvQ3P7sx7a0fDomJ7PcTSiQvFJvs7fmGo8Zr78 0RBeQR5PtwHweqhf9wy8VEmrcBMIVceJex0CHXOxHY5+P6pltAfWbLKjHaNBloP9mp4n zB4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Nk9Y6QJakNrYOS3JKF2H9NdOYv17Rj/XoxOuMnosO+w=; b=uKPw9LtDmDli8/bVJMj3lV6OsOzCAoKlL7xAzOx8D0PgB1TiOJrZVbu+BNhZQVaixZ NfD5sHVxA78GS3+KxZ/XTQoegAiyQ42ATEBTdwDuCy2bdzprqkSfJ5kvb4cGPQ6XHZeu P1+JQHxtJvQwhimo94mRk4qy4D0gXICiCUy9CNILY8PfRYtDK0xiex+HCUzXuDZO2ZeK WZ4EeKIqlgCtcu4BT4mBURyIMeWBbR3o6GDu0D9jhLekLlZfs7LrosdjB1j/8S3qqyKz B/0/i9AUjrQNKuemKEm6PtjW5bWDM4pYkeenFxvO3DAz+LpRh7bvCX9LxnQUe1FYjQOM y1Gg== X-Gm-Message-State: AN3rC/5TDNnsjrlnk3bXbA8jLrdYzoVt+p+z7kjw4mZltANwDoPBhheX XbEyz/BCYhgSvhpTnxvHtT7YL6zhtQ== X-Received: by 10.107.205.132 with SMTP id d126mr24840184iog.155.1493680257217; Mon, 01 May 2017 16:10:57 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Mon, 1 May 2017 16:10:55 -0700 (PDT) Received: by 10.79.62.24 with HTTP; Mon, 1 May 2017 16:10:55 -0700 (PDT) In-Reply-To: References: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> <20170501185128.GB23490@ernw.de> From: Robert Raszuk Date: Mon, 1 May 2017 19:10:55 -0400 X-Google-Sender-Auth: aJZRZJ7TrNlOqKVyDpQF36hFr9g Message-ID: Subject: Re: Proposed revised Extension Header text for rfc2460bis To: "EXT - joelja@bogus.com" Cc: 6man WG , Enno Rey Content-Type: multipart/alternative; boundary=94eb2c18871823baad054e7e8986 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 23:13:12 -0000 --94eb2c18871823baad054e7e8986 Content-Type: text/plain; charset=UTF-8 Joel, Valid observation especially since you quoted one of my own RFC ;) But this issue may happen when src hosts inserts EHs. Also mandating one more v6 encap to be able to add v6 EHs does not make the problem any easier. ICMP error should be returned to src to report it indeed. Do we have real numbers from deployed boxes in Internet DFZ how deep L4 can be from the start of the packet to still be readable ? Or are we just speculating here that it may happen ? Thx, R. On May 1, 2017 15:27, "joel jaeggli" wrote: On 5/1/17 12:46 PM, Robert Raszuk wrote: > Good thing that no one is putting firewall in global Internet transit DFZ. > > So how this applies to this concern of transit nodes in the Internet > remove EHs ? It would be rather odd for a device to attempt to remove Extension Headers, it would be somewhat less surprising to see packets where the l4 header cannot be found filtered, which applies to cases other then for example new extension headers as well, for example non-initial fragements. In modern internet protocol routers, there are a number of reasons why recourse to the L4 header might be practically required, these include variously the application of control-plane acls (which may of course include traffic set through rather than to the box), the application of forwarding plane acls (example 5575 bgp flowspec rules, static acls, etc), hashing, needs to perform qos marking and so on. in the cases where an asic's lookup space precludes processing the extension header chain, or where for other reasons the l4 header cannot be identified it is clearly problematic to unconditionally forward the packet. > Cheers > R. > > On May 1, 2017 11:54, "Enno Rey" > wrote: > > Fred, > > On Mon, May 01, 2017 at 11:29:17AM -0700, Fred Baker wrote: > > Indeed. My understanding of the complaint is that > > - some routers may be configured with ACLs that enforce rules > about extension headers, precluding any extension headers, specific > types of extension headers, or limiting extension headers to certain > types. > > - some routers may be configured with ACLs that worry about > TCP/UDP port numbers, and drop packets for various reasons relating > to the number of extension headers found, the IPv6 header actually > fitting in working RAM in the chip, or other errors > > - if ACL handing is punted to another processor, it is often > rate limited > > - firewalls, in particular, may be configured to worry about the > presence of fragmentation headers > > > > Those are indeed contrary to the specification, and if a router or > firewall did it by default it would be in violation. > > actually the majority of commercial enterprise firewalls perform > some filtering of EHs, at least as for their number or order (which > both are not restricted too much in RFC 2460), by default. These are > results for some testing we did in 2014 (I doubt much has changed > until today. if it has probably things have not become more > flexible/liberal): > > https://www.ernw.de/download/AAtlasis-RISC-project- presentation-%20results.pdf > > > best > > Enno > > > > > > That said, there are equipment limitations in some cases and > operator configurations in others that can have the effect. > > > > > On May 1, 2017, at 11:17 AM, Robert Raszuk > wrote: > > > > > > Ok ... if v6 transit routers drop extension headers in spite of > dst address being not themselves to me this sounds like a bug. > > > > > > It is behaviour against base v6 spec which allowed such EH to be > inserted into v6 packets by senders. Maybe bis spec should made it > very clear and mandate that transit routers MUST NOT alter EH in any > way if the dst address is not themselves. > > > > > > Thx > > > R. > > > > > > On May 1, 2017 10:40, "Tom Herbert" > wrote: > > > On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk > > wrote: > > > > Hi Mark, > > > > > > > >> Were any changes required to the MPLS header or MPLS forwarding > > > >> operations to support SR? > > > > > > > > > > > > If you would follow SR-MPLS you would realize that MPLS label > carries an > > > > embedded function. Exactly like SID in SRH. > > > > > > > > Moreover with the overhead of signaling required to > established an LSP in > > > > MPLS case transit nodes no matter if they are within domain or > beyond domain > > > > DO NOT NEED to change any single bit in their current > forwarding paradigm. > > > > SR functions are executed only at the designated nodes which > are able to > > > > perform the desired forwarding behaviour. > > > > > > > > This entire discussion that maybe we will bless SRv6 in closed > domains just > > > > does not get the fundamental point that transit nodes > regardless on how many > > > > SRH are in the IPv6 packet will work just fine. > > > > > > I don't understand why we'd expect this to "work just fine"... There > > > are still a lot of intermediate nodes that will arbitrarily drop > > > extensions headers. So if one device inserts an extension header > in a > > > packet that previously had no extension headers and the packet is > > > dropped down stream by some other device, then the device inserting > > > headers has broken the end to end connectivity. What's worse is that > > > the offending device won't even know packets are being dropped > so it's > > > can't do a happy eyeballs like algorithm like a host might be > able to > > > do. > > > > > > IMO, there is too much the emphasis here on the needs intermediate > > > nodes and the value add they might provide without regard to the > needs > > > end hosts. IPv6 is, after all, a protocol that allow _hosts_ to > > > communicate which may be facilitated intermediate routers. The > > > assumption hosts make is that the IP packet sent from one host is > > > received "as-is" on the other with only specific modifications > allowed > > > (options that may be modified in flight). In other words, if I, as a > > > host, send a packet into the network, I expect that same packet > to pop > > > out at the receiver pretty much unchanged-- I don't expect the > > > receiver to get some ad hoc re-interpretation of the packet by > network > > > nodes. This is implied by the robustness principle, fundamental to > > > security, and needed to maintain connectivity. If network nodes want > > > to modify packets in transit, insert extension headers, or other > while > > > in transit that might be reasonable per the requirements as long > as 1) > > > the changes are undone before delivering the packet to the receiving > > > host, and 2) there are no other insidious effects like unexplained > > > packet drop. > > > > > > Tom > > > > > > > Of course there is MTU > > > > concern ... but this concern is also with MPLS stacking or for > that matter > > > > with any encapsulation. And we do know today how to > effectively solve it > > > > when/where needed. > > > > > > > > It get's even worse if you (like some of this WG members) now > require to > > > > encapsulate packets in additional v6 header before SRH is > inserted - makes > > > > zero sense ! Just please kindly observe that if you do the > encap the dst > > > > address can be anywhere in the Internet .. no encap code > mandates that dst > > > > must be in your IGP. So packets do escape ASes .. BGP in fact > was explicitly > > > > created to help/assist them to escape. > > > > > > > > I think perhaps a dedicated interim meeting should be setup > just to discuss > > > > it and understand it well before we proceed with any further spec > > > > clarifications or extensions. > > > > > > > > Best, > > > > Robert > > > > > > > > PS. Leave alone other SRv6 features but does folks on this > list do not care > > > > about TI-LFA ? > > > > > > > > > > > >> > > > >> > > > >> Another difference between IPv6 and MPLS is that MPLS is not an > > > >> end-to-end protocol, so it naturally creates and enforces local > > > >> domains. To have MPLS frames successfully leak between two > networks > > > >> requires active enabling of MPLS on both ends of the links > between > > > >> them, which won't happen unless the MPLS networks explicitly > agree to > > > >> trade MPLS traffic, for explicit MPLS reasons, purposes and > functions. > > > >> > > > >> IPv6 is an end-to-end protocol between hosts, that may transit > > > >> multiple networks in between those hosts. IPv6 is brought up > between > > > >> two networks to provide services for any IPv6 applications. So SR > > > >> wouldn't likely be the initial reason to enable IPv6 between two > > > >> networks. Consequently, the likelihood of "internal" IPv6 SR > packets > > > >> going further than they should is naturally much higher. > RFC1918 and > > > >> similar have demonstrated that on the Internet, local or > private "IP" > > > >> domains aren't. > > > >> > > > >> Regards, > > > >> Mark. > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > -------------------------------------------------------------------- > > > > > > > ------------------------------------------------------------ -------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > > ------------------------------------------------------------ -------- > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > -- > Enno Rey > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > > Tel. +49 6221 480390 - Fax 6221 419008 - > Cell +49 173 6745902 > > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Enno Rey > > ======================================================= > Blog: www.insinuator.net || Conference: > www.troopers.de > Twitter: @Enno_Insinuator > ======================================================= > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --94eb2c18871823baad054e7e8986 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Joel,

Valid observation especially since you quoted one of my own RFC ;)

But this issue may happen w= hen src hosts inserts EHs. Also mandating one more v6 encap to be able to a= dd v6 EHs does not make the problem any easier.

=
ICMP error should be returned to src to report it i= ndeed.

Do we have real n= umbers from deployed boxes in Internet DFZ how deep L4 can be from the star= t of the packet to still be readable ? Or are we just speculating here that= it may happen ?

Thx,
R.

=

= On May 1, 2017 15:27, "joel jaeggli" <joelja@bogus.com> wrote:
On 5/1/17 12:46 PM, Robert Ras= zuk wrote:
> Good thing that no one is putting firewall in global Internet transit = DFZ.
>
> So how this applies to this concern of transit nodes in the Internet > remove EHs ?

It would be rather odd for a device to attempt to remove Extension Headers, it would be somewhat less surprising to see packets where the
l4 header cannot be found filtered, which applies to cases other then
for example new extension headers as well, for example non-initial
fragements.

In modern internet protocol routers, there are a number of reasons why
recourse to the L4 header might be practically required, these include
variously the application of control-plane acls (which may of course
include traffic set through rather than to the box),=C2=A0 the application = of
forwarding plane acls (example 5575 bgp flowspec rules, static acls,
etc), hashing, needs to perform qos marking and so on.=C2=A0 in the cases where an asic's lookup space precludes processing the extension header<= br> chain, or where for other reasons the l4 header cannot be identified it
is clearly problematic to unconditionally forward the packet.


> Cheers
> R.
>
> On May 1, 2017 11:54, "Enno Rey" <erey@ernw.de <mailto:erey@e= rnw.de>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Fred,
>
>=C2=A0 =C2=A0 =C2=A0On Mon, May 01, 2017 at 11:29:17AM -0700, Fred Bake= r wrote:
>=C2=A0 =C2=A0 =C2=A0> Indeed. My understanding of the complaint is t= hat
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0- some routers may be configured w= ith ACLs that enforce rules
>=C2=A0 =C2=A0 =C2=A0about extension headers, precluding any extension h= eaders, specific
>=C2=A0 =C2=A0 =C2=A0types of extension headers, or limiting extension h= eaders to certain
>=C2=A0 =C2=A0 =C2=A0types.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0- some routers may be configured w= ith ACLs that worry about
>=C2=A0 =C2=A0 =C2=A0TCP/UDP port numbers, and drop packets for various = reasons relating
>=C2=A0 =C2=A0 =C2=A0to the number of extension headers found, the IPv6 = header actually
>=C2=A0 =C2=A0 =C2=A0fitting in working RAM in the chip, or other errors=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0- if ACL handing is punted to anot= her processor, it is often
>=C2=A0 =C2=A0 =C2=A0rate limited
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0- firewalls, in particular, may be= configured to worry about the
>=C2=A0 =C2=A0 =C2=A0presence of fragmentation headers
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Those are indeed contrary to the specification= , and if a router or
>=C2=A0 =C2=A0 =C2=A0firewall did it by default it would be in violation= .
>
>=C2=A0 =C2=A0 =C2=A0actually the majority of commercial enterprise fire= walls perform
>=C2=A0 =C2=A0 =C2=A0some filtering of EHs, at least as for their number= or order (which
>=C2=A0 =C2=A0 =C2=A0both are not restricted too much in RFC 2460), by d= efault. These are
>=C2=A0 =C2=A0 =C2=A0results for some testing we did in 2014 (I doubt mu= ch has changed
>=C2=A0 =C2=A0 =C2=A0until today. if it has probably things have not bec= ome more
>=C2=A0 =C2=A0 =C2=A0flexible/liberal):
>
>=C2=A0 =C2=A0 =C2=A0https://www.ernw.de/download/AAtlasis-RISC-project-presentation= -%20results.pdf
>=C2=A0 =C2=A0 =C2=A0<https://www.ernw.de/download/AAtlasis-RISC-project-presenta= tion-%20results.pdf>
>
>=C2=A0 =C2=A0 =C2=A0best
>
>=C2=A0 =C2=A0 =C2=A0Enno
>
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 That said, there are equipment limitations in some= cases and
>=C2=A0 =C2=A0 =C2=A0operator configurations in others that can have the= effect.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> > On May 1, 2017, at 11:17 AM, Robert Raszu= k <robert@raszuk.net
>=C2=A0 =C2=A0 =C2=A0<mailto:robert@raszuk.net>> wrote:
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> > Ok ... if v6 transit routers drop extensi= on headers in spite of
>=C2=A0 =C2=A0 =C2=A0dst address being not themselves to me this sounds = like a bug.
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> > It is behaviour against base v6 spec whic= h allowed such EH to be
>=C2=A0 =C2=A0 =C2=A0inserted into v6 packets by senders. Maybe bis spec= should made it
>=C2=A0 =C2=A0 =C2=A0very clear and mandate that transit routers MUST NO= T alter EH in any
>=C2=A0 =C2=A0 =C2=A0way if the dst address is not themselves.
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> > Thx
>=C2=A0 =C2=A0 =C2=A0> > R.
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> > On May 1, 2017 10:40, "Tom Herbert&q= uot; <tom@herbertland.com
>=C2=A0 =C2=A0 =C2=A0<mailto:tom@herbertland.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0> > On Mon, May 1, 2017 at 12:17 AM, Robert R= aszuk
>=C2=A0 =C2=A0 =C2=A0<robert@raszuk.net <mailto:robert@raszuk.net>> wrote:
>=C2=A0 =C2=A0 =C2=A0> > > Hi Mark,
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > >> Were any changes required to the= MPLS header or MPLS forwarding
>=C2=A0 =C2=A0 =C2=A0> > >> operations to support SR?
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > > If you would follow SR-MPLS you woul= d realize that MPLS label
>=C2=A0 =C2=A0 =C2=A0carries an
>=C2=A0 =C2=A0 =C2=A0> > > embedded function. Exactly like SID = in SRH.
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > > Moreover with the overhead of signal= ing required to
>=C2=A0 =C2=A0 =C2=A0established an LSP in
>=C2=A0 =C2=A0 =C2=A0> > > MPLS case transit nodes no matter if= they are within domain or
>=C2=A0 =C2=A0 =C2=A0beyond domain
>=C2=A0 =C2=A0 =C2=A0> > > DO NOT NEED to change any single bit= in their current
>=C2=A0 =C2=A0 =C2=A0forwarding paradigm.
>=C2=A0 =C2=A0 =C2=A0> > > SR functions are executed only at th= e designated nodes which
>=C2=A0 =C2=A0 =C2=A0are able to
>=C2=A0 =C2=A0 =C2=A0> > > perform the desired forwarding behav= iour.
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > > This entire discussion that maybe we= will bless SRv6 in closed
>=C2=A0 =C2=A0 =C2=A0domains just
>=C2=A0 =C2=A0 =C2=A0> > > does not get the fundamental point t= hat transit nodes
>=C2=A0 =C2=A0 =C2=A0regardless on how many
>=C2=A0 =C2=A0 =C2=A0> > > SRH are in the IPv6 packet will work= just fine.
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> > I don't understand why we'd expec= t this to "work just fine"... There
>=C2=A0 =C2=A0 =C2=A0> > are still a lot of intermediate nodes tha= t will arbitrarily drop
>=C2=A0 =C2=A0 =C2=A0> > extensions headers. So if one device inse= rts an extension header
>=C2=A0 =C2=A0 =C2=A0in a
>=C2=A0 =C2=A0 =C2=A0> > packet that previously had no extension h= eaders and the packet is
>=C2=A0 =C2=A0 =C2=A0> > dropped down stream by some other device,= then the device inserting
>=C2=A0 =C2=A0 =C2=A0> > headers has broken the end to end connect= ivity. What's worse is that
>=C2=A0 =C2=A0 =C2=A0> > the offending device won't even know = packets are being dropped
>=C2=A0 =C2=A0 =C2=A0so it's
>=C2=A0 =C2=A0 =C2=A0> > can't do a happy eyeballs like algori= thm like a host might be
>=C2=A0 =C2=A0 =C2=A0able to
>=C2=A0 =C2=A0 =C2=A0> > do.
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> > IMO, there is too much the emphasis here = on the needs intermediate
>=C2=A0 =C2=A0 =C2=A0> > nodes and the value add they might provid= e without regard to the
>=C2=A0 =C2=A0 =C2=A0needs
>=C2=A0 =C2=A0 =C2=A0> > end hosts. IPv6 is, after all, a protocol= that allow _hosts_ to
>=C2=A0 =C2=A0 =C2=A0> > communicate which may be facilitated inte= rmediate routers. The
>=C2=A0 =C2=A0 =C2=A0> > assumption hosts make is that the IP pack= et sent from one host is
>=C2=A0 =C2=A0 =C2=A0> > received "as-is" on the other w= ith only specific modifications
>=C2=A0 =C2=A0 =C2=A0allowed
>=C2=A0 =C2=A0 =C2=A0> > (options that may be modified in flight).= In other words, if I, as a
>=C2=A0 =C2=A0 =C2=A0> > host, send a packet into the network, I e= xpect that same packet
>=C2=A0 =C2=A0 =C2=A0to pop
>=C2=A0 =C2=A0 =C2=A0> > out at the receiver pretty much unchanged= -- I don't expect the
>=C2=A0 =C2=A0 =C2=A0> > receiver to get some ad hoc re-interpreta= tion of the packet by
>=C2=A0 =C2=A0 =C2=A0network
>=C2=A0 =C2=A0 =C2=A0> > nodes. This is implied by the robustness = principle, fundamental to
>=C2=A0 =C2=A0 =C2=A0> > security, and needed to maintain connecti= vity. If network nodes want
>=C2=A0 =C2=A0 =C2=A0> > to modify packets in transit, insert exte= nsion headers, or other
>=C2=A0 =C2=A0 =C2=A0while
>=C2=A0 =C2=A0 =C2=A0> > in transit that might be reasonable per t= he requirements as long
>=C2=A0 =C2=A0 =C2=A0as 1)
>=C2=A0 =C2=A0 =C2=A0> > the changes are undone before delivering = the packet to the receiving
>=C2=A0 =C2=A0 =C2=A0> > host, and 2) there are no other insidious= effects like unexplained
>=C2=A0 =C2=A0 =C2=A0> > packet drop.
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> > Tom
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> > > Of course there is MTU
>=C2=A0 =C2=A0 =C2=A0> > > concern ... but this concern is also= with MPLS stacking or for
>=C2=A0 =C2=A0 =C2=A0that matter
>=C2=A0 =C2=A0 =C2=A0> > > with any encapsulation. And we do kn= ow today how to
>=C2=A0 =C2=A0 =C2=A0effectively solve it
>=C2=A0 =C2=A0 =C2=A0> > > when/where needed.
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > > It get's even worse if you (like= some of this WG members) now
>=C2=A0 =C2=A0 =C2=A0require to
>=C2=A0 =C2=A0 =C2=A0> > > encapsulate packets in additional v6= header before SRH is
>=C2=A0 =C2=A0 =C2=A0inserted - makes
>=C2=A0 =C2=A0 =C2=A0> > > zero sense ! Just please kindly obse= rve that if you do the
>=C2=A0 =C2=A0 =C2=A0encap the dst
>=C2=A0 =C2=A0 =C2=A0> > > address can be anywhere in the Inter= net .. no encap code
>=C2=A0 =C2=A0 =C2=A0mandates that dst
>=C2=A0 =C2=A0 =C2=A0> > > must be in your IGP. So packets do e= scape ASes .. BGP in fact
>=C2=A0 =C2=A0 =C2=A0was explicitly
>=C2=A0 =C2=A0 =C2=A0> > > created to help/assist them to escap= e.
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > > I think perhaps a dedicated interim = meeting should be setup
>=C2=A0 =C2=A0 =C2=A0just to discuss
>=C2=A0 =C2=A0 =C2=A0> > > it and understand it well before we = proceed with any further spec
>=C2=A0 =C2=A0 =C2=A0> > > clarifications or extensions.
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > > Best,
>=C2=A0 =C2=A0 =C2=A0> > > Robert
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > > PS. Leave alone other SRv6 features = but does folks on this
>=C2=A0 =C2=A0 =C2=A0list do not care
>=C2=A0 =C2=A0 =C2=A0> > > about TI-LFA ?
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > >>
>=C2=A0 =C2=A0 =C2=A0> > >>
>=C2=A0 =C2=A0 =C2=A0> > >> Another difference between IPv6 = and MPLS is that MPLS is not an
>=C2=A0 =C2=A0 =C2=A0> > >> end-to-end protocol, so it natur= ally creates and enforces local
>=C2=A0 =C2=A0 =C2=A0> > >> domains. To have MPLS frames suc= cessfully leak between two
>=C2=A0 =C2=A0 =C2=A0networks
>=C2=A0 =C2=A0 =C2=A0> > >> requires active enabling of MPLS= on both ends of the links
>=C2=A0 =C2=A0 =C2=A0between
>=C2=A0 =C2=A0 =C2=A0> > >> them, which won't happen unl= ess the MPLS networks explicitly
>=C2=A0 =C2=A0 =C2=A0agree to
>=C2=A0 =C2=A0 =C2=A0> > >> trade MPLS traffic, for explicit= MPLS reasons, purposes and
>=C2=A0 =C2=A0 =C2=A0functions.
>=C2=A0 =C2=A0 =C2=A0> > >>
>=C2=A0 =C2=A0 =C2=A0> > >> IPv6 is an end-to-end protocol b= etween hosts, that may transit
>=C2=A0 =C2=A0 =C2=A0> > >> multiple networks in between tho= se hosts. IPv6 is brought up
>=C2=A0 =C2=A0 =C2=A0between
>=C2=A0 =C2=A0 =C2=A0> > >> two networks to provide services= for any IPv6 applications. So SR
>=C2=A0 =C2=A0 =C2=A0> > >> wouldn't likely be the initi= al reason to enable IPv6 between two
>=C2=A0 =C2=A0 =C2=A0> > >> networks. Consequently, the like= lihood of "internal" IPv6 SR
>=C2=A0 =C2=A0 =C2=A0packets
>=C2=A0 =C2=A0 =C2=A0> > >> going further than they should i= s naturally much higher.
>=C2=A0 =C2=A0 =C2=A0RFC1918 and
>=C2=A0 =C2=A0 =C2=A0> > >> similar have demonstrated that o= n the Internet, local or
>=C2=A0 =C2=A0 =C2=A0private "IP"
>=C2=A0 =C2=A0 =C2=A0> > >> domains aren't.
>=C2=A0 =C2=A0 =C2=A0> > >>
>=C2=A0 =C2=A0 =C2=A0> > >> Regards,
>=C2=A0 =C2=A0 =C2=A0> > >> Mark.
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0----------------------------------------------= ----------------------
>=C2=A0 =C2=A0 =C2=A0> > > IETF IPv6 working group mailing list=
>=C2=A0 =C2=A0 =C2=A0> > > ipv6@ietf.org <mailto:ipv6@ietf.= org>
>=C2=A0 =C2=A0 =C2=A0> > > Administr= ative Requests:
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/= listinfo/ipv6
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/<= wbr>listinfo/ipv6>
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0----------------------------------------------= ----------------------
>=C2=A0 =C2=A0 =C2=A0> > >
>=C2=A0 =C2=A0 =C2=A0> > ------------------------------------= --------------------------------
>=C2=A0 =C2=A0 =C2=A0> > IETF IPv6 working group mailing list
>=C2=A0 =C2=A0 =C2=A0> > ip= v6@ietf.org <mailto:ipv6@ietf.org>
>=C2=A0 =C2=A0 =C2=A0> > Administrative= Requests:
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/= listinfo/ipv6
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/<= wbr>listinfo/ipv6>
>=C2=A0 =C2=A0 =C2=A0> > ------------------------------------= --------------------------------
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> -----------------------------------------= ---------------------------
>=C2=A0 =C2=A0 =C2=A0> IETF IPv6 working group mailing list
>=C2=A0 =C2=A0 =C2=A0> ipv6@ie= tf.org <mailto:ipv6@ietf.org>= ;
>=C2=A0 =C2=A0 =C2=A0> Administrative Requests:
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/= listinfo/ipv6
>=C2=A0 =C2=A0 =C2=A0<htt= ps://www.ietf.org/mailman/listinfo/ipv6>
>=C2=A0 =C2=A0 =C2=A0> -----------------------------------------= ---------------------------
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Enno Rey
>
>=C2=A0 =C2=A0 =C2=A0ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - = www.ern= w.de
>=C2=A0 =C2=A0 =C2=A0<http://www.ernw.de>
>=C2=A0 =C2=A0 =C2=A0Tel. +49 6221 480390 <tel:%2B49%206221%20480390> - Fax= 6221 419008 -
>=C2=A0 =C2=A0 =C2=A0Cell +49 173 6745902 <tel:%2B49%20173%206745902>
>
>=C2=A0 =C2=A0 =C2=A0Handelsregister Mannheim: HRB 337135
>=C2=A0 =C2=A0 =C2=A0Geschaeftsfuehrer: Enno Rey
>
>=C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=C2=A0 =C2=A0 =C2=A0Blog: www.insinuator.net <http://www.i= nsinuator.net> || Conference:
>=C2=A0 =C2=A0 =C2=A0www.troopers.de <http://www.troopers.de>
>=C2=A0 =C2=A0 =C2=A0Twitter: @Enno_Insinuato= r
>=C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>=C2=A0 =C2=A0 =C2=A0----------------------------------------------= ----------------------
>=C2=A0 =C2=A0 =C2=A0IETF IPv6 working group mailing list
>=C2=A0 =C2=A0 =C2=A0ipv6@ietf.or= g <mailto:ipv6@ietf.org>
>=C2=A0 =C2=A0 =C2=A0Administrative Requests:= https://www.ietf.org/mailman/listinfo/ipv6
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/<= wbr>listinfo/ipv6>
>=C2=A0 =C2=A0 =C2=A0----------------------------------------------= ----------------------
>
>
>
> ------------------------------------------------------------= --------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> ------------------------------------------------------------= --------
>



--94eb2c18871823baad054e7e8986-- From nobody Mon May 1 16:38:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2F812941C for ; Mon, 1 May 2017 16:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf0u3zEDz3By for ; Mon, 1 May 2017 16:37:57 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5EC12EAA9 for ; Mon, 1 May 2017 16:35:34 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id m36so99765181qtb.0 for ; Mon, 01 May 2017 16:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9WLRt36wHUQlU7koR5Ha17R6/o2s5BGseNGJNs3H8Xc=; b=Xk/wEErXafQI/kHCZj9hzmrcM1cBfJ7FcNoGe9GqED1kD1pz3D5PUT/1WLYZaMjfJ3 kHhWbSwHte38/M3Swd2dLSInEiRhtN0K3pSoXc/UQ7H/Xei8/CA6g6YkhV2uVjO5OrCo qpLlWPdqDKhwxlBh0TzhT4mh9cC51JWlx5GxYoaPsZAHpJrNx1/RgjF6cQ58Z0ZCYwcM 1Gw2yy3VShyl0/XBsHPC5scPmx/CO7FypiRf8OV0Isbkb8VJhFx3IPPozw012CJWcSxb dSOp2pQ9aD/8vJc+ppnQaCe+K0MwHZtlJKqmzvJE2sJJBdBQRZuMm98ROciac6sxEXmC bAWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9WLRt36wHUQlU7koR5Ha17R6/o2s5BGseNGJNs3H8Xc=; b=DOvn5vn4LXpGnyVJaJtWl7yJnk6XjIRSVMD7r7TstjZld9w/2LaDDl6W4TOGfOB0qs hjNekii2drmrmdcHHRSHK0Wb47xVHN+1a5Hl9UGYHWDk6zJairdx3Uq9TfkMFFs4319N dkdJa6jnZqFs1QvwrDUjMC7+4GFUPGZoEgLg9uTeQkaG2xwP+13hHnfBRZoWNFcojUxK FSovZGr793g/zmepUcKjtIWaO5ghli23ZNJCnllmXqE9YRjEkdLKJ/sHb8qVoGJefBuU ffOWJn0Ntt8xkCk0XqvMwUhG1ovs/A7VH7r03H9D7pEK4UCWlr3gKLL7x+u6JFQ7bQjH bxlA== X-Gm-Message-State: AN3rC/52YyVlR1Yc8gkRqetFNfqSMHMk5tISd4ejw/jHAO7EFLCi3l/X qprP/IAwAFeMa30ncsrMyhzGZf8vW78q X-Received: by 10.237.58.103 with SMTP id n94mr25825568qte.42.1493681733494; Mon, 01 May 2017 16:35:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Mon, 1 May 2017 16:35:33 -0700 (PDT) In-Reply-To: References: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> <20170501185128.GB23490@ernw.de> From: Tom Herbert Date: Mon, 1 May 2017 16:35:33 -0700 Message-ID: Subject: Re: Looping [was: Proposed revised Extension Header text for rfc2460bis] To: Brian E Carpenter Cc: 6man WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 23:37:59 -0000 On Mon, May 1, 2017 at 4:09 PM, Brian E Carpenter wrote: > On 02/05/2017 10:48, Tom Herbert wrote: >> On Mon, May 1, 2017 at 3:27 PM, joel jaeggli wrote: > ... >>> In modern internet protocol routers, there are a number of reasons why >>> recourse to the L4 header might be practically required, these include >>> variously the application of control-plane acls (which may of course >>> include traffic set through rather than to the box), the application of >>> forwarding plane acls (example 5575 bgp flowspec rules, static acls, >>> etc), hashing, needs to perform qos marking and so on. in the cases >>> where an asic's lookup space precludes processing the extension header >>> chain, or where for other reasons the l4 header cannot be identified it >>> is clearly problematic to unconditionally forward the packet. >>> >> It doesn't seem likely that this behavior is going to go away any time >> soon, if ever. Maybe instead of just dropping packet these devices >> should send back an ICMP error to inform the sender of which EH caused >> the drop? > > Since unknown ICMPv6 is at high risk of being dropped too, this is > unlikely to help. > > People, we discussed all this while RFC7045 was being drafted, and > many other times as well. What has it got to do with the final > wordsmithing of the IPv6 Internet Standard, where the technical > (rough) consensus is already known? > Brian, The wording in RFC2460bis is: "Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node" Inserted or deleted are not common operations so maybe they can be squashed, but in the Internet extension headers _are_ being processed in modern Internet routers as Joel said, if nothing else to find the transport header. It's hard to rectify the standard against this reality other than to not use an EH at all which is pretty much where hosts are currently. Tom > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon May 1 17:12:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDDF129C6A for ; Mon, 1 May 2017 17:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 sh5evPYy8JqJ for ; Mon, 1 May 2017 17:12:30 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 178781293D6 for ; Mon, 1 May 2017 17:10:15 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id p8so457237uaa.3 for ; Mon, 01 May 2017 17:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zY3GfxD0C9cDmmxfDR6j7e6BL9TzQwo8y4SJ9Az3Sqs=; b=fBb8onCRmDxKeYxgaQ5p+dt/FzMTkTK2ksdA6mml5ZBZ0pDi7v5Sc2dTJjHjoOtQb7 aLUa4CJi8hYtbIlNgBQ7y0cLcNHfYXqsalNZnjA7/tIPw7IJPqjpTJUXh7msEZzNTZ63 OZX0HAvPzHNToz1A3crpEAoiYyLb+boR7byYrZCntQzLGlUcFEtI1NuS9G6diu9hZTI/ Ucx8sIcSDPKPLu46PUdT6AfKa69QQ53zixD1WEewLOaI4dWRRd644HhmP5yancvHbLP+ 8ZvNh/DZkc5FQehXCTAgGgCNNotVKGNgbmIF/b5NvhcWPySKWiH4VXRi0rpVXEM0Q6DI qihg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zY3GfxD0C9cDmmxfDR6j7e6BL9TzQwo8y4SJ9Az3Sqs=; b=K++ZENaUpITXPH0Ig94LGHN1F5kFe+dDof4j4YRUGEeSj9TvJkFRWVmyhBCnjYRHLd 6LDoaSX9kWX/rL5YLD7bBt/w1RcI3zvBQILEetNR2BiWb/onI7G9r5AUaIFTssmp1IcY eiQBqwMPsILIaBdYB17lqRjNNgb+0l8sBppbrRA5OQi598CKOE0Q+a7NwSyc6S/ej2TU OkAbZW66Ov3pB6tFBmXBQQ2RyT0w7lkv545NDcpUSGmL6puSj9CBoAMugcdjXT14jm5o z77/Ip1aYt0zSEWYDijKO1Wu4QoLHIWGXPzWH5nFu71ehf2Nmy4jOGyomNWFK8xE6G5A 9BFQ== X-Gm-Message-State: AN3rC/6r55fd1P/VTzCMJsQrnMYcz/ww95TEqUBtMtfnCjJsO4Ty8KUS DreBLb57+mVtkuq2iWqr3tw23p9ALn+d X-Received: by 10.176.24.85 with SMTP id j21mr14968036uag.125.1493683813962; Mon, 01 May 2017 17:10:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.130 with HTTP; Mon, 1 May 2017 17:09:43 -0700 (PDT) In-Reply-To: References: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> <20170501185128.GB23490@ernw.de> From: Mark Smith Date: Tue, 2 May 2017 10:09:43 +1000 Message-ID: Subject: Re: Proposed revised Extension Header text for rfc2460bis To: Robert Raszuk Cc: "EXT - joelja@bogus.com" , 6man WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 00:12:33 -0000 On 2 May 2017 at 09:10, Robert Raszuk wrote: > Joel, > > Valid observation especially since you quoted one of my own RFC ;) > > But this issue may happen when src hosts inserts EHs. Also mandating one > more v6 encap to be able to add v6 EHs does not make the problem any easier. > > ICMP error should be returned to src to report it indeed. This is one of the issues with EH insertion. The device that inserted the EH is not recorded in the packet. The only source device recorded in the packet is in the Source Address field, but that clearly isn't the source of the inserted the EH. An additional IPv6 encapsulation adds that missing information. If the EH is added via: [New IPv6 HDR][New EH][Original IPv6 packet] then it is clear that the source address in the [New IPv6 HDR] identifies the device that added the [New EH], and if any errors are encountered because of the new EH, then they're correctly sent to the source device identified in the [New IPv6 HDR]. While an inserted EH is present, the Source Address field value is not accurate anymore. If RFC2460 was changed to allow EH insertion, then there also has to be changes made to state that the Source Address field doesn't always accurately record the source device of all of the contents of the packet while in-flight or when the packet arrives at the destination host. Anything else that is making that assumption e.g., PMTUD, ICMP, IPsec AH also would needs to be updated with that change and the consequences evaluated. Regards, Mark. > > Do we have real numbers from deployed boxes in Internet DFZ how deep L4 can > be from the start of the packet to still be readable ? Or are we just > speculating here that it may happen ? > > Thx, > R. > > > > On May 1, 2017 15:27, "joel jaeggli" wrote: > > On 5/1/17 12:46 PM, Robert Raszuk wrote: >> Good thing that no one is putting firewall in global Internet transit DFZ. >> >> So how this applies to this concern of transit nodes in the Internet >> remove EHs ? > > It would be rather odd for a device to attempt to remove Extension > Headers, it would be somewhat less surprising to see packets where the > l4 header cannot be found filtered, which applies to cases other then > for example new extension headers as well, for example non-initial > fragements. > > In modern internet protocol routers, there are a number of reasons why > recourse to the L4 header might be practically required, these include > variously the application of control-plane acls (which may of course > include traffic set through rather than to the box), the application of > forwarding plane acls (example 5575 bgp flowspec rules, static acls, > etc), hashing, needs to perform qos marking and so on. in the cases > where an asic's lookup space precludes processing the extension header > chain, or where for other reasons the l4 header cannot be identified it > is clearly problematic to unconditionally forward the packet. > > >> Cheers >> R. >> >> On May 1, 2017 11:54, "Enno Rey" > >> wrote: >> >> Fred, >> >> On Mon, May 01, 2017 at 11:29:17AM -0700, Fred Baker wrote: >> > Indeed. My understanding of the complaint is that >> > - some routers may be configured with ACLs that enforce rules >> about extension headers, precluding any extension headers, specific >> types of extension headers, or limiting extension headers to certain >> types. >> > - some routers may be configured with ACLs that worry about >> TCP/UDP port numbers, and drop packets for various reasons relating >> to the number of extension headers found, the IPv6 header actually >> fitting in working RAM in the chip, or other errors >> > - if ACL handing is punted to another processor, it is often >> rate limited >> > - firewalls, in particular, may be configured to worry about the >> presence of fragmentation headers >> > >> > Those are indeed contrary to the specification, and if a router or >> firewall did it by default it would be in violation. >> >> actually the majority of commercial enterprise firewalls perform >> some filtering of EHs, at least as for their number or order (which >> both are not restricted too much in RFC 2460), by default. These are >> results for some testing we did in 2014 (I doubt much has changed >> until today. if it has probably things have not become more >> flexible/liberal): >> >> >> https://www.ernw.de/download/AAtlasis-RISC-project-presentation-%20results.pdf >> >> >> >> best >> >> Enno >> >> >> >> >> >> That said, there are equipment limitations in some cases and >> operator configurations in others that can have the effect. >> > >> > > On May 1, 2017, at 11:17 AM, Robert Raszuk > > wrote: >> > > >> > > Ok ... if v6 transit routers drop extension headers in spite of >> dst address being not themselves to me this sounds like a bug. >> > > >> > > It is behaviour against base v6 spec which allowed such EH to be >> inserted into v6 packets by senders. Maybe bis spec should made it >> very clear and mandate that transit routers MUST NOT alter EH in any >> way if the dst address is not themselves. >> > > >> > > Thx >> > > R. >> > > >> > > On May 1, 2017 10:40, "Tom Herbert" > > wrote: >> > > On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk >> > wrote: >> > > > Hi Mark, >> > > > >> > > >> Were any changes required to the MPLS header or MPLS forwarding >> > > >> operations to support SR? >> > > > >> > > > >> > > > If you would follow SR-MPLS you would realize that MPLS label >> carries an >> > > > embedded function. Exactly like SID in SRH. >> > > > >> > > > Moreover with the overhead of signaling required to >> established an LSP in >> > > > MPLS case transit nodes no matter if they are within domain or >> beyond domain >> > > > DO NOT NEED to change any single bit in their current >> forwarding paradigm. >> > > > SR functions are executed only at the designated nodes which >> are able to >> > > > perform the desired forwarding behaviour. >> > > > >> > > > This entire discussion that maybe we will bless SRv6 in closed >> domains just >> > > > does not get the fundamental point that transit nodes >> regardless on how many >> > > > SRH are in the IPv6 packet will work just fine. >> > > >> > > I don't understand why we'd expect this to "work just fine"... >> There >> > > are still a lot of intermediate nodes that will arbitrarily drop >> > > extensions headers. So if one device inserts an extension header >> in a >> > > packet that previously had no extension headers and the packet is >> > > dropped down stream by some other device, then the device >> inserting >> > > headers has broken the end to end connectivity. What's worse is >> that >> > > the offending device won't even know packets are being dropped >> so it's >> > > can't do a happy eyeballs like algorithm like a host might be >> able to >> > > do. >> > > >> > > IMO, there is too much the emphasis here on the needs intermediate >> > > nodes and the value add they might provide without regard to the >> needs >> > > end hosts. IPv6 is, after all, a protocol that allow _hosts_ to >> > > communicate which may be facilitated intermediate routers. The >> > > assumption hosts make is that the IP packet sent from one host is >> > > received "as-is" on the other with only specific modifications >> allowed >> > > (options that may be modified in flight). In other words, if I, as >> a >> > > host, send a packet into the network, I expect that same packet >> to pop >> > > out at the receiver pretty much unchanged-- I don't expect the >> > > receiver to get some ad hoc re-interpretation of the packet by >> network >> > > nodes. This is implied by the robustness principle, fundamental to >> > > security, and needed to maintain connectivity. If network nodes >> want >> > > to modify packets in transit, insert extension headers, or other >> while >> > > in transit that might be reasonable per the requirements as long >> as 1) >> > > the changes are undone before delivering the packet to the >> receiving >> > > host, and 2) there are no other insidious effects like unexplained >> > > packet drop. >> > > >> > > Tom >> > > >> > > > Of course there is MTU >> > > > concern ... but this concern is also with MPLS stacking or for >> that matter >> > > > with any encapsulation. And we do know today how to >> effectively solve it >> > > > when/where needed. >> > > > >> > > > It get's even worse if you (like some of this WG members) now >> require to >> > > > encapsulate packets in additional v6 header before SRH is >> inserted - makes >> > > > zero sense ! Just please kindly observe that if you do the >> encap the dst >> > > > address can be anywhere in the Internet .. no encap code >> mandates that dst >> > > > must be in your IGP. So packets do escape ASes .. BGP in fact >> was explicitly >> > > > created to help/assist them to escape. >> > > > >> > > > I think perhaps a dedicated interim meeting should be setup >> just to discuss >> > > > it and understand it well before we proceed with any further >> spec >> > > > clarifications or extensions. >> > > > >> > > > Best, >> > > > Robert >> > > > >> > > > PS. Leave alone other SRv6 features but does folks on this >> list do not care >> > > > about TI-LFA ? >> > > > >> > > > >> > > >> >> > > >> >> > > >> Another difference between IPv6 and MPLS is that MPLS is not an >> > > >> end-to-end protocol, so it naturally creates and enforces local >> > > >> domains. To have MPLS frames successfully leak between two >> networks >> > > >> requires active enabling of MPLS on both ends of the links >> between >> > > >> them, which won't happen unless the MPLS networks explicitly >> agree to >> > > >> trade MPLS traffic, for explicit MPLS reasons, purposes and >> functions. >> > > >> >> > > >> IPv6 is an end-to-end protocol between hosts, that may transit >> > > >> multiple networks in between those hosts. IPv6 is brought up >> between >> > > >> two networks to provide services for any IPv6 applications. So >> SR >> > > >> wouldn't likely be the initial reason to enable IPv6 between >> two >> > > >> networks. Consequently, the likelihood of "internal" IPv6 SR >> packets >> > > >> going further than they should is naturally much higher. >> RFC1918 and >> > > >> similar have demonstrated that on the Internet, local or >> private "IP" >> > > >> domains aren't. >> > > >> >> > > >> Regards, >> > > >> Mark. >> > > > >> > > > >> > > > >> > > > >> -------------------------------------------------------------------- >> > > > IETF IPv6 working group mailing list >> > > > ipv6@ietf.org >> > > > Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> >> > > > >> -------------------------------------------------------------------- >> > > > >> > > >> -------------------------------------------------------------------- >> > > IETF IPv6 working group mailing list >> > > ipv6@ietf.org >> > > Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> >> > > >> -------------------------------------------------------------------- >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> >> > -------------------------------------------------------------------- >> >> -- >> Enno Rey >> >> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de >> >> Tel. +49 6221 480390 - Fax 6221 419008 - >> Cell +49 173 6745902 >> >> Handelsregister Mannheim: HRB 337135 >> Geschaeftsfuehrer: Enno Rey >> >> ======================================================= >> Blog: www.insinuator.net || Conference: >> www.troopers.de >> Twitter: @Enno_Insinuator >> ======================================================= >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> >> -------------------------------------------------------------------- >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon May 1 17:53:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB2312EB7D for ; Mon, 1 May 2017 17:53:46 -0700 (PDT) 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 5C8axTaYLLQw for ; Mon, 1 May 2017 17:53:43 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 5F44012EB9C for ; Mon, 1 May 2017 17:50:56 -0700 (PDT) Received: from mb.local ([IPv6:2620:11a:c081:20:b160:696e:29b5:9c76]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v420ojFX096252 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 2 May 2017 00:50:45 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:b160:696e:29b5:9c76] claimed to be mb.local Subject: Re: Proposed revised Extension Header text for rfc2460bis To: Robert Raszuk Cc: 6man WG , Enno Rey References: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> <20170501185128.GB23490@ernw.de> From: joel jaeggli Message-ID: <3eff4f68-3a9b-afd9-1c83-3f646ac352f2@bogus.com> Date: Mon, 1 May 2017 17:50:39 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Thunderbird/53.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="luGGDaNuCCmVkXmEXNUDBXlddlXWcCmaj" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 00:53:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --luGGDaNuCCmVkXmEXNUDBXlddlXWcCmaj Content-Type: multipart/mixed; boundary="VwDKur1fdhFF4A94SA4EeqbCrtjEskQJ7"; protected-headers="v1" From: joel jaeggli To: Robert Raszuk Cc: 6man WG , Enno Rey Message-ID: <3eff4f68-3a9b-afd9-1c83-3f646ac352f2@bogus.com> Subject: Re: Proposed revised Extension Header text for rfc2460bis References: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> <20170501185128.GB23490@ernw.de> In-Reply-To: --VwDKur1fdhFF4A94SA4EeqbCrtjEskQJ7 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/1/17 4:10 PM, Robert Raszuk wrote: > Joel, >=20 > Valid observation especially since you quoted one of my own RFC ;) >=20 > But this issue may happen when src hosts inserts EHs. Also mandating on= e > more v6 encap to be able to add v6 EHs does not make the problem any ea= sier. >=20 > ICMP error should be returned to src to report it indeed. >=20 > Do we have real numbers from deployed boxes in Internet DFZ how deep L4= > can be from the start of the packet to still be readable ? Or are we > just speculating here that it may happen ? Juniper Martini (router) ASICs circa 2000 were as shallow as 52 bytes (it's not really surprising where that number came from). A broadcom jericho asic which is modern cell forwarder suitable for a high end (full fib in many cases) layer 3 ethernet switch such as the nexus 9000 or arista 7500 can look in 128 byte, asr9k or mx trio router silicon can do 192 or 384 respectively. typically these devices might potentially have to account for an mpls or l2 header also depending on how they are used. > Thx, > R. >=20 >=20 >=20 > On May 1, 2017 15:27, "joel jaeggli" > wrote: >=20 > On 5/1/17 12:46 PM, Robert Raszuk wrote: > > Good thing that no one is putting firewall in global Internet > transit DFZ. > > > > So how this applies to this concern of transit nodes in the Inter= net > > remove EHs ? >=20 > It would be rather odd for a device to attempt to remove Extension > Headers, it would be somewhat less surprising to see packets where = the > l4 header cannot be found filtered, which applies to cases other th= en > for example new extension headers as well, for example non-initial > fragements. >=20 > In modern internet protocol routers, there are a number of reasons = why > recourse to the L4 header might be practically required, these incl= ude > variously the application of control-plane acls (which may of cours= e > include traffic set through rather than to the box), the applicati= on of > forwarding plane acls (example 5575 bgp flowspec rules, static acls= , > etc), hashing, needs to perform qos marking and so on. in the case= s > where an asic's lookup space precludes processing the extension hea= der > chain, or where for other reasons the l4 header cannot be identifie= d it > is clearly problematic to unconditionally forward the packet. >=20 >=20 > > Cheers > > R. > > > > On May 1, 2017 11:54, "Enno Rey" >> > wrote: > > > > Fred, > > > > On Mon, May 01, 2017 at 11:29:17AM -0700, Fred Baker wrote: > > > Indeed. My understanding of the complaint is that > > > - some routers may be configured with ACLs that enforce r= ules > > about extension headers, precluding any extension headers, > specific > > types of extension headers, or limiting extension headers to > certain > > types. > > > - some routers may be configured with ACLs that worry abo= ut > > TCP/UDP port numbers, and drop packets for various reasons > relating > > to the number of extension headers found, the IPv6 header act= ually > > fitting in working RAM in the chip, or other errors > > > - if ACL handing is punted to another processor, it is of= ten > > rate limited > > > - firewalls, in particular, may be configured to worry > about the > > presence of fragmentation headers > > > > > > Those are indeed contrary to the specification, and if a > router or > > firewall did it by default it would be in violation. > > > > actually the majority of commercial enterprise firewalls perf= orm > > some filtering of EHs, at least as for their number or order > (which > > both are not restricted too much in RFC 2460), by default. > These are > > results for some testing we did in 2014 (I doubt much has cha= nged > > until today. if it has probably things have not become more > > flexible/liberal): > > > > =20 > https://www.ernw.de/download/AAtlasis-RISC-project-presentation-%2= 0results.pdf > > > =20 > > > > > > best > > > > Enno > > > > > > > > > > > > That said, there are equipment limitations in some cases and= > > operator configurations in others that can have the effect. > > > > > > > On May 1, 2017, at 11:17 AM, Robert Raszuk > > > >> wrote:= > > > > > > > > Ok ... if v6 transit routers drop extension headers in > spite of > > dst address being not themselves to me this sounds like a bug= =2E > > > > > > > > It is behaviour against base v6 spec which allowed such E= H > to be > > inserted into v6 packets by senders. Maybe bis spec should ma= de it > > very clear and mandate that transit routers MUST NOT alter EH= > in any > > way if the dst address is not themselves. > > > > > > > > Thx > > > > R. > > > > > > > > On May 1, 2017 10:40, "Tom Herbert" > > >> wr= ote: > > > > On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk > > > >> wrote: > > > > > Hi Mark, > > > > > > > > > >> Were any changes required to the MPLS header or MPLS > forwarding > > > > >> operations to support SR? > > > > > > > > > > > > > > > If you would follow SR-MPLS you would realize that MPLS= > label > > carries an > > > > > embedded function. Exactly like SID in SRH. > > > > > > > > > > Moreover with the overhead of signaling required to > > established an LSP in > > > > > MPLS case transit nodes no matter if they are within > domain or > > beyond domain > > > > > DO NOT NEED to change any single bit in their current > > forwarding paradigm. > > > > > SR functions are executed only at the designated nodes = which > > are able to > > > > > perform the desired forwarding behaviour. > > > > > > > > > > This entire discussion that maybe we will bless SRv6 in= > closed > > domains just > > > > > does not get the fundamental point that transit nodes > > regardless on how many > > > > > SRH are in the IPv6 packet will work just fine. > > > > > > > > I don't understand why we'd expect this to "work just > fine"... There > > > > are still a lot of intermediate nodes that will > arbitrarily drop > > > > extensions headers. So if one device inserts an extension= > header > > in a > > > > packet that previously had no extension headers and the > packet is > > > > dropped down stream by some other device, then the device= > inserting > > > > headers has broken the end to end connectivity. What's > worse is that > > > > the offending device won't even know packets are being dr= opped > > so it's > > > > can't do a happy eyeballs like algorithm like a host migh= t be > > able to > > > > do. > > > > > > > > IMO, there is too much the emphasis here on the needs > intermediate > > > > nodes and the value add they might provide without regard= > to the > > needs > > > > end hosts. IPv6 is, after all, a protocol that allow > _hosts_ to > > > > communicate which may be facilitated intermediate routers= =2E The > > > > assumption hosts make is that the IP packet sent from one= > host is > > > > received "as-is" on the other with only specific modifica= tions > > allowed > > > > (options that may be modified in flight). In other words,= > if I, as a > > > > host, send a packet into the network, I expect that same > packet > > to pop > > > > out at the receiver pretty much unchanged-- I don't expec= t the > > > > receiver to get some ad hoc re-interpretation of the pack= et by > > network > > > > nodes. This is implied by the robustness principle, > fundamental to > > > > security, and needed to maintain connectivity. If network= > nodes want > > > > to modify packets in transit, insert extension headers, o= r > other > > while > > > > in transit that might be reasonable per the requirements > as long > > as 1) > > > > the changes are undone before delivering the packet to th= e > receiving > > > > host, and 2) there are no other insidious effects like > unexplained > > > > packet drop. > > > > > > > > Tom > > > > > > > > > Of course there is MTU > > > > > concern ... but this concern is also with MPLS stacking= > or for > > that matter > > > > > with any encapsulation. And we do know today how to > > effectively solve it > > > > > when/where needed. > > > > > > > > > > It get's even worse if you (like some of this WG > members) now > > require to > > > > > encapsulate packets in additional v6 header before SRH = is > > inserted - makes > > > > > zero sense ! Just please kindly observe that if you do = the > > encap the dst > > > > > address can be anywhere in the Internet .. no encap cod= e > > mandates that dst > > > > > must be in your IGP. So packets do escape ASes .. BGP i= n > fact > > was explicitly > > > > > created to help/assist them to escape. > > > > > > > > > > I think perhaps a dedicated interim meeting should be s= etup > > just to discuss > > > > > it and understand it well before we proceed with any > further spec > > > > > clarifications or extensions. > > > > > > > > > > Best, > > > > > Robert > > > > > > > > > > PS. Leave alone other SRv6 features but does folks on t= his > > list do not care > > > > > about TI-LFA ? > > > > > > > > > > > > > > >> > > > > >> > > > > >> Another difference between IPv6 and MPLS is that MPLS > is not an > > > > >> end-to-end protocol, so it naturally creates and > enforces local > > > > >> domains. To have MPLS frames successfully leak between= two > > networks > > > > >> requires active enabling of MPLS on both ends of the l= inks > > between > > > > >> them, which won't happen unless the MPLS networks > explicitly > > agree to > > > > >> trade MPLS traffic, for explicit MPLS reasons, purpose= s and > > functions. > > > > >> > > > > >> IPv6 is an end-to-end protocol between hosts, that may= > transit > > > > >> multiple networks in between those hosts. IPv6 is > brought up > > between > > > > >> two networks to provide services for any IPv6 > applications. So SR > > > > >> wouldn't likely be the initial reason to enable IPv6 > between two > > > > >> networks. Consequently, the likelihood of "internal" > IPv6 SR > > packets > > > > >> going further than they should is naturally much highe= r. > > RFC1918 and > > > > >> similar have demonstrated that on the Internet, local = or > > private "IP" > > > > >> domains aren't. > > > > >> > > > > >> Regards, > > > > >> Mark. > > > > > > > > > > > > > > > > > > > > > > =20 > ------------------------------------------------------------------= -- > > > > > IETF IPv6 working group mailing list > > > > > ipv6@ietf.org > > > > > > > Administrative Requests: > > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > > > > > > =20 > ------------------------------------------------------------------= -- > > > > > > > > > > -------------------------------------------------------------------= - > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > > Administrative Requests: > > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > > > > -------------------------------------------------------------------= - > > > > > > > -------------------------------------------------------------------= - > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > > Administrative Requests: > > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > > > -------------------------------------------------------------------= - > > > > -- > > Enno Rey > > > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.d= e > > > > > Tel. +49 6221 480390 > - Fax 6221 419008 - > > Cell +49 173 6745902 > > > > > Handelsregister Mannheim: HRB 337135 > > Geschaeftsfuehrer: Enno Rey > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > Blog: www.insinuator.net > || Conference: > > www.troopers.de > > Twitter: @Enno_Insinuator > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =20 > ------------------------------------------------------------------= -- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > =20 > ------------------------------------------------------------------= -- > > > > > > > > -----------------------------------------------------------------= --- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > -----------------------------------------------------------------= --- > > >=20 >=20 >=20 --VwDKur1fdhFF4A94SA4EeqbCrtjEskQJ7-- --luGGDaNuCCmVkXmEXNUDBXlddlXWcCmaj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlkH198ACgkQ8AA1q7Z/VrIxeQCfXxn9Lo6lBbUQ4fHEWYuG9UrV eGUAn1MqHGOTVAdi5aDaz3GmD2ibDM4t =EsT4 -----END PGP SIGNATURE----- --luGGDaNuCCmVkXmEXNUDBXlddlXWcCmaj-- From nobody Mon May 1 18:36:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9790B129AAA for ; Mon, 1 May 2017 18:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_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 Eu0z_TjrWNbE for ; Mon, 1 May 2017 18:36:56 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 D71A71294C9 for ; Mon, 1 May 2017 18:34:47 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id o76so40642760vkc.2 for ; Mon, 01 May 2017 18:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KVOTgA7qOxiwnoIhxBZCySUINoBiiLtODrBgefcHQxw=; b=HN1pzlo4rm8P0r1IRFW7NbwwqpRhZIciUFcXDHsl5YfOUfO9NJeL3EJzgklEmg4yzX 29YSkVQh3DjAOg4saEp3m/cpSCxJMv5t54amswFVRAakIllYnzC7vLgooVpbOdpYk+3J ypKrY/gLAWgQ3s0xGznAk5uYQUmF4uaUWo0Kopa7sYhWm1P/RRndTCSCBDi9/vdramAn 0EBDacA1Kj12+NRW6ZfXpirsu7FYs7e8BPJFzHxxHZOz2T+gK3JU/RhfPxeNr2SYeJ3x 8y3g7gUSIZo7sDbb662bPgH/vc+Koir7Vj8ABhAksU17mQZYFH31uCi9RR4nM1+1FACy gItg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KVOTgA7qOxiwnoIhxBZCySUINoBiiLtODrBgefcHQxw=; b=qKvMSdP4SRykJySI8IJNAwHgVDrldCP82Z6vco+lVGu2kFwYjN1C0R8+MyaQm6F9+8 J7ib6K56DJ0B2U4/XgCBBU4jotPIZDovFZN0QZUSUZuibIMj6VgIVx7RTaHtnTfWPvzj CfehHTdVpSJygkIJ44miz1Lx28/V7OSvde9lqLtz+BBUYj+XaDbWi6i2aqXNIJLjYhlI N+AD/PpWGyDfeXleqE8jgGw+owddVfP8iyfcI35v/rxESKBvVsStM/N9vP8eW8w9IV+X FSj1lh4fg7xyi8hvjRcL7oz0QJdW6xYNaLYlozTY/U1imGrDDImehgfGTLbdMSRrS2Va Wfxw== X-Gm-Message-State: AN3rC/7JQebxjxmJSAU+f8APWcAEOyLRzha1EareLMwfa2VZjCV9i9DY Wbeo16yvNhXhZl6+VSG1mM/5sCiVBw== X-Received: by 10.31.203.70 with SMTP id b67mr13626537vkg.48.1493688886849; Mon, 01 May 2017 18:34:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.130 with HTTP; Mon, 1 May 2017 18:34:16 -0700 (PDT) In-Reply-To: References: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> <20170501185128.GB23490@ernw.de> From: Mark Smith Date: Tue, 2 May 2017 11:34:16 +1000 Message-ID: Subject: Re: Looping [was: Proposed revised Extension Header text for rfc2460bis] To: Tom Herbert Cc: Brian E Carpenter , 6man WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 01:36:57 -0000 Hi Tom, On 2 May 2017 at 09:35, Tom Herbert wrote: > On Mon, May 1, 2017 at 4:09 PM, Brian E Carpenter > wrote: >> On 02/05/2017 10:48, Tom Herbert wrote: >>> On Mon, May 1, 2017 at 3:27 PM, joel jaeggli wrote: >> ... >> > The wording in RFC2460bis is: > > "Extension headers (except for the Hop-by-Hop Options header) are not > processed, inserted, or deleted by any node along a packet's delivery > path, until the packet reaches the node" > > Inserted or deleted are not common operations so maybe they can be > squashed, but in the Internet extension headers _are_ being processed > in modern Internet routers as Joel said, if nothing else to find the > transport header. It's hard to rectify the standard against this > reality other than to not use an EH at all which is pretty much where > hosts are currently. > I think what this comes down to is what the fundamental purpose or purposes of the specification is. I think the fundamental purposes of network layer specifications like RFC2460 are: - to define required and possibly optional protocol parameters and operations for functions/devices in the network and functions/devices that use the network - to specify network user or client function/device (a.k.a. host) expectations of the service provided by the network A router (as a function) doesn't need to be able to look much past the fixed IPv6 header (the one exception being the HBH header) to meet the specification definition of an IPv6 router ("a node that forwards IPv6 packets not explicitly addressed to itself"). A router as a device may do other things that may exceed the specification as a "value add", however the outcomes of those operations, even when they fail, needs to be consistent with the service expectations of the network users/client functions/devices. I don't think we also need to include this "value add" as part of the base specification, as it isn't required for the base specification to achieve its goals. Regards, Mark. From nobody Mon May 1 19:54:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C17112E044 for ; Mon, 1 May 2017 19:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 f52S7G4WEI5M for ; Mon, 1 May 2017 19:54:35 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 9D3B0129B1D for ; Mon, 1 May 2017 19:52:02 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id c45so102142518qtb.1 for ; Mon, 01 May 2017 19:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9O2hR/bZbjjsVhbRuvocU/L4VgOV6CZFqGixmEthjEs=; b=O3ZdV5igOH4W90CjpWlEldeI/3uIHKVl0fJh4FOtvx7mx5UboAucn1YcfG7ww5vJqr fK16BYoAQfA6L4Tl33ImjBwreXZXEwiuACx9/o6pn8jrtzdXT0PpqeSe1VloY0jj+e2z FN+NiYNOJ/akLFjKpKv8DjZUwlAftYh1fdf9piUD+dFjglfAheAM8liw+j35hbtv+s2C PKicyRc+Dl6XbulkQZfjCfC1KXW3J5SMUlqLYFXcqBvcU/SUqDScJ+tckaMr3z9RZpOy elvBLrtCh9oT6rZE/K17CtOCvOIJeaAlAZLuYpRDe62b97G7KWj98QhgommcjCrBsFb2 +Erw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9O2hR/bZbjjsVhbRuvocU/L4VgOV6CZFqGixmEthjEs=; b=K4btrSCBDLr/dyyll7ShhqDUv07CvHH0HBryqOwdhwhxTmhTQsJ/H2yVnP195zZg7w ZcSmpg4WqTGUkIeBWHNZ7AkHOjgpkyBdxST8rFwTcS1eP71B3zPhjia5rBomRrtj0jpp bBDvjzgHGlCN/9XSSLTi74YmutmOD0nsNVVO26LwGT2xieDySjqrVZZcTARvlwr12+T3 +pwgaTnowdOOqrKq2vgvyrFs+jvfhYeRiH3sIy48vWUcHTc3Mg+k3D7+E+BaH2vQ3Gp2 6Cd7Y+7SGVfGJEkU4ssp3hibsp1BxxxKr2A/fE2IyrDm17H5hKWSM1ZEkxxkYieUWfww j1/Q== X-Gm-Message-State: AN3rC/4wDITG8kjoUNttd87P+ltrQ6zyFn1uQTBdpGCxI12NN6vY5TVW RmVh8dDefFE7D77WuVC0indPtZtvBw== X-Received: by 10.200.35.27 with SMTP id a27mr24261084qta.2.1493693521531; Mon, 01 May 2017 19:52:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.81.66 with HTTP; Mon, 1 May 2017 19:52:00 -0700 (PDT) In-Reply-To: <8C442C82-D1D5-49E3-858D-B7EDFBEC6817@cisco.com> References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com> <59036B64.4010008@cisco.com> <1CA0E022-B54D-455C-8063-0AE34DD2CCC2@cisco.com> <8C442C82-D1D5-49E3-858D-B7EDFBEC6817@cisco.com> From: Suresh Krishnan Date: Mon, 1 May 2017 22:52:00 -0400 Message-ID: Subject: Re: Proposed revised Extension Header text for rfc2460bis To: "Stefano Previdi (sprevidi)" Cc: Brian E Carpenter , Fernando Gont , =?UTF-8?B?56We5piO6YGU5ZOJ?= , Bob Hinden , IPv6 List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 02:54:37 -0000 Hi Stefano, On Mon, May 1, 2017 at 4:21 PM, Stefano Previdi (sprevidi) wrote: > >> On May 1, 2017, at 10:17 PM, Brian E Carpenter wrote: >> >> On 02/05/2017 05:47, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >> >> ... >>>> despite the various episodes, I still do not agree on the current text= . >> >> The WG Chairs > > > have declared rough consensus on another text, later changed by the AD. You make it sound like I changed it because I felt like it :-). I instructed the editor to change the text directly as the result of the IETF Last Call consensus. (and to be very frank, the WG consensus was pretty rough to start off with). I got the WG mailing list looped in on the IETF Last Call discussion as soon as this issue came up. I copied the IETF last call conclusion to the WG mailing list. The WG has had a chance to have a say every step of the way. The objection to this new text has always been "We have a proposal that will end up violating this restriction, so let's make it a should not". The header insertion proposal (draft-voyer-6man-extension-header-insertion-00) was not even written up until couple of weeks after the IETF Last Call on RFC2460bis concluded. As I said in my mail below https://www.ietf.org/mail-archive/web/ipv6/current/msg26934.html I am expecting the proponents of header insertion to do exactly what the proponents of zero UDP checksums did and do the groundwork for updating RFC2460bis. I will do my part by sending in my review for that draft (draft-voyer). Thanks Suresh From nobody Mon May 1 20:34:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534251298BA for ; Mon, 1 May 2017 20:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 SEf6wKKsYvnG for ; Mon, 1 May 2017 20:34:27 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A65129B52 for ; Mon, 1 May 2017 20:31:55 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 909228197F for ; Mon, 1 May 2017 23:31:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=Gu9 q/p2Bns3eaKoqBFknV7hfdHU=; b=ZbH3lmzGQyEaSit0B1/9eXSwGnnIGaSyzu0 wIYtPEBgldQ2NPYvRoxBBBJbodNwclhDcJm/0kjbhZDn/Xkh2wqaX+44eXOs0+Bw THz7T92fGfPrh5rY6Ypj9mOT8mTGo4G6eZfAqF8pi2KOOP7YYmtPdQzCPwCvLMF+ zONoFo/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= l41YiJZwDhnRtfuGKiabSd3K75IWfUCgKbzlq4M6Ka9Zbym9mfK+acamFt+8J02V ROrdTJgNU4Vk81OK4VeUJSARERCfJz63Q1yVoKnHsZI6VQUWljBWIo1P6XPQJqS7 xNZrC66l0ZPiucFcBDuiTmsS1j3fxZpRt3DS2HwCdQ4= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 8969B8197E for ; Mon, 1 May 2017 23:31:52 -0400 (EDT) Received: from mail-qk0-f179.google.com (unknown [209.85.220.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 1CEDE8197C for ; Mon, 1 May 2017 23:31:52 -0400 (EDT) Received: by mail-qk0-f179.google.com with SMTP id r189so6815318qkf.1 for ; Mon, 01 May 2017 20:31:52 -0700 (PDT) X-Gm-Message-State: AN3rC/6THJyNxTMdthJ/F594CFX8bxSaiGPxO0gk/aS1KyQNUTUJp7/X 7uMA257nB6V5OcU+w9Xcpaoe5TrhPw== X-Received: by 10.55.20.102 with SMTP id e99mr22666990qkh.191.1493695911783; Mon, 01 May 2017 20:31:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Mon, 1 May 2017 20:31:31 -0700 (PDT) From: "C. M. Heard" Date: Mon, 1 May 2017 20:31:31 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Looping [was: Proposed revised Extension Header text for rfc2460bis] To: Tom Herbert Cc: 6man WG Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: E1F5241E-2EE7-11E7-BE85-C260AE2156B6-06080547!pb-smtp2.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 03:34:28 -0000 On Mon, 1 May 2017 16:35:33 -0700 Tom Herbert wrote: > The wording in RFC2460bis is: > > "Extension headers (except for the Hop-by-Hop Options header) are not > processed, inserted, or deleted by any node along a packet's delivery > path, until the packet reaches the node" > > Inserted or deleted are not common operations so maybe they can be > squashed, but in the Internet extension headers _are_ being processed > in modern Internet routers as Joel said, if nothing else to find the > transport header. It's hard to rectify the standard against this > reality other than to not use an EH at all which is pretty much where > hosts are currently. It would be more accurate to say that they are being _examined_ for various purposes, most notably to find transport headers and to examine them. That is not the same as being _processed_ as would happen in end nodes. Earlier versions said "are not examined" but the editor removed that. //cmh From nobody Mon May 1 20:57:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1450129436 for ; Mon, 1 May 2017 20:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4a_kBz3QiSg for ; Mon, 1 May 2017 20:57:00 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 CF53B12EB18 for ; Mon, 1 May 2017 20:54:22 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id m36so102666288qtb.0 for ; Mon, 01 May 2017 20:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e8XwSivGj+o/cfifXb6QbWe0V55dUdKM6MTLmdXpSqw=; b=ZWfuPnzkaEZFbcvRhDy4vlUnTjYdCrVpaj4eeYtAoyvolgoHWS7Qzly9zRHp29KBut M9L7fIjBmx86KzMuGeDkS8LMYRsFGwoSx3Vxn0F5EySOu3+EF+xal7JzTSW2Q0wuoHvA iCWEHLg6e316X7KB+HVdov6UGooXGGaTJK1GUSqM6WDEZJcadGjxk2yEchDWAwl2peMH CbHcEDFK6utInc4uYNbaNi+CwGMBqTGeEGJTFTKf5wMS9UDBDlVTBjhe5N/JtwD27L/+ +NYF2bHJ1YZnAGUaxtuROp7mT5+yK7mREUZ9UqJNms+U+aqvkaKSFVfIvToGRK1q45AN 0xSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e8XwSivGj+o/cfifXb6QbWe0V55dUdKM6MTLmdXpSqw=; b=m0cVaL8KT1yhHwCM4naVUaoWBsYVSEpQGFDs7YaV6K8SnHtlrxjf8Cof2CoiZ10Csj ZDYrSuE4h91B407KoMvScCehW0zntUeNeQco813BHqLGVMbeGwuKRDIfCx0Q3LmD6doK z1bg6Ms2fOyAO4/gMulpucMjk2CGUuYgM9z1cGZTfbGqw9L9tgcVlmGFZ4aXeLhPRPr7 /HxX47ksbN6o+fAvyej68DLCsjdv/KvBgsaopKCNUmL3B1PAfELMpQeWTspJ+vAuPMRW SVvhoR1HAsQI/rJIbavruPmGePwcdYN1Bz5VpEsfazLY/MNQnm43QGs8xtN6N9dDp3SH 976g== X-Gm-Message-State: AN3rC/75up6r/V/4LzbGOHj00UMLlUhshtWHLpLcx6tkHsx/nVGZAfN5 /axbp2sCJsoLq1zdXsfy69wn31SOtw== X-Received: by 10.237.58.103 with SMTP id n94mr26540352qte.42.1493697261993; Mon, 01 May 2017 20:54:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Mon, 1 May 2017 20:54:21 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Mon, 1 May 2017 20:54:21 -0700 Message-ID: Subject: Re: Looping [was: Proposed revised Extension Header text for rfc2460bis] To: "C. M. Heard" Cc: 6man WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 03:57:04 -0000 On Mon, May 1, 2017 at 8:31 PM, C. M. Heard wrote: > On Mon, 1 May 2017 16:35:33 -0700 Tom Herbert wrote: >> The wording in RFC2460bis is: >> >> "Extension headers (except for the Hop-by-Hop Options header) are not >> processed, inserted, or deleted by any node along a packet's delivery >> path, until the packet reaches the node" >> >> Inserted or deleted are not common operations so maybe they can be >> squashed, but in the Internet extension headers _are_ being processed >> in modern Internet routers as Joel said, if nothing else to find the >> transport header. It's hard to rectify the standard against this >> reality other than to not use an EH at all which is pretty much where >> hosts are currently. > > It would be more accurate to say that they are being _examined_ for > various purposes, most notably to find transport headers and to > examine them. That is not the same as being _processed_ as would > happen in end nodes. > Okay, but what would you call it when an intermediate drops a packet because it encounters an unknown extension header? Or if it drops a packet because a destination options EH makes the headers too big to fit in its parsing buffer so that the transport header cannot be found? It seems like the node is doing more than just examining them in these cases; it's taking definitive action (i.e. dropping packets) based on the presence of EHs other than HBH. Tom > Earlier versions said "are not examined" but the editor removed that. > > //cmh From nobody Mon May 1 21:40:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D11C12EAFB for ; Mon, 1 May 2017 21:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 nDTm2vybqB8u for ; Mon, 1 May 2017 21:40:55 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 55770128E19 for ; Mon, 1 May 2017 21:38:26 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id t7so54479673pgt.3 for ; Mon, 01 May 2017 21:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Zz0XcOxCj6d3mVua3bCsiA9mzM6ZzcFiEEfQnXAKWOc=; b=eHkVVCFUatxHNxhBztjp1wfLBC5WIAfgNRZElO8MoE3IbKWiehUNdq/NBEuAyiUijf y8xsj9txcuu8uIZw4IK9UyTxfYoUw6kiNJbW4ipx7GFPSKDb4AdidyraELwOyKpBlEiX kXA4NwBzSebfeBnoKCeKZCGovY9hdIC0l8rPQrpPcIHNCSXgOATm4+dPlxf1JuwPYmL2 DfX7jzthN0zxch/bSFOZp0VeTNooBmhUaUhqsVrNMQtiLQgdJrAk1l1Clb54UFeW/5Vr 93yqWr+Vls7f+5NYY2QaPmjtwqCK6zY1zFQpV+yGc95bgCfiwBpiiM9iXDIR4AaPwPeG DjHA== 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:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Zz0XcOxCj6d3mVua3bCsiA9mzM6ZzcFiEEfQnXAKWOc=; b=osuWizYFuBWeGq7HWCTvnwauO8qy+WS2PmHA+OvlOmcQW0D0XRe5hi7WoSUDbvNYjV vE47J6eE2u3D7JxA0qxHkV0zR0WUR4D+Twi27T3qb29Gt048FLSl0yKsLfjmJC1FpUxR wbp4QA88xMzxmrmEsUK/nEmv9dG8uF3qMhOdPtaDsImqqzaPmdDYddEmFXEjv1D98DtA 2EsEcLs+nlNiiCrIpVJUILWCSzsO4LQizIEJQ2XtPmrTyIv9AtDkloJB+Z6nz+TRd0X7 W9HkWXdYsUqk2g5oV6LlLqZynHoYTTXJ7YRRoyyxqgKOGmjCj+SmhUXapo/33rvHC9fY jJpA== X-Gm-Message-State: AN3rC/4htnnefx5h8kx3nQMlIJ1EcVpS5ASmlLgB9NvuO6DFe8faaSWz A8Z+o1lZfyYhR7c0 X-Received: by 10.99.44.9 with SMTP id s9mr6717412pgs.132.1493699905782; Mon, 01 May 2017 21:38:25 -0700 (PDT) Received: from [192.168.178.21] ([118.148.64.29]) by smtp.gmail.com with ESMTPSA id a21sm26501243pfc.60.2017.05.01.21.38.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2017 21:38:25 -0700 (PDT) Subject: Re: Looping [was: Proposed revised Extension Header text for rfc2460bis] To: ipv6@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <2506bca8-684d-f03f-955f-7c140bc2dca1@gmail.com> Date: Tue, 2 May 2017 16:38:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 04:40:56 -0000 On 02/05/2017 15:54, Tom Herbert wrote: ... > Okay, but what would you call it when an intermediate drops a packet > because it encounters an unknown extension header? Sabotage. From nobody Tue May 2 05:02:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E026131449 for ; Tue, 2 May 2017 05:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zERATkwD7jU for ; Tue, 2 May 2017 05:02:06 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E7913161A for ; Tue, 2 May 2017 04:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2554; q=dns/txt; s=iport; t=1493726299; x=1494935899; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fzTGz5n7X1L/8vM1s7ZXAooA1CgKPG0z5eY2hfPSr2k=; b=EPUu7Igarq+64Bo7B8focZUi/Iyee2os395SFd+31rzTgjEN4WjtdQOJ JFKvXB8CBtbi0mDLzB7jBFhQpp4KSmmYHC/EQ3Tb76V7qpPmkLs69n9Bm SH+bXJEVJ/Y5QoLAs2YNHtfz6s5Na+sCkbCCf0Ghg/ZFJr7eKDbEktALM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgADcwhZ/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHg2GKGJEsIYgijUuCDyyFeAIahCE/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEjEToLBQsCAQYCGAICJgICAh8RFRACBA4FigYDDQgOkFKdYYImh?= =?us-ascii?q?zINg1sBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhVSCCQuCZYJUgXIBATKCby6?= =?us-ascii?q?CMQEEnRk7AY5ChE6RXosfiREBHziBCm8VRBIBhF4cgWN2AYZagSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,405,1488844800"; d="scan'208";a="238395614" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 May 2017 11:58:18 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v42BwHmo001887 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2017 11:58:18 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 2 May 2017 07:58:17 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 2 May 2017 07:58:17 -0400 From: "Stefano Previdi (sprevidi)" To: Suresh Krishnan CC: Brian E Carpenter , Fernando Gont , =?utf-8?B?56We5piO6YGU5ZOJ?= , Bob Hinden , IPv6 List Subject: Re: Proposed revised Extension Header text for rfc2460bis Thread-Topic: Proposed revised Extension Header text for rfc2460bis Thread-Index: AQHSv5CqvG2qal8sOEusPVCxbYji0aHZ9NeAgAFB4oCAAANqAIAAEa6AgAR7L/WAAGzcAIAAKyuugADbpwA= Date: Tue, 2 May 2017 11:58:17 +0000 Message-ID: <11F1FA4E-0420-4645-B4B7-DBB9F8A18C9B@cisco.com> References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com> <59036B64.4010008@cisco.com> <1CA0E022-B54D-455C-8063-0AE34DD2CCC2@cisco.com> <8C442C82-D1D5-49E3-858D-B7EDFBEC6817@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.88.211] Content-Type: text/plain; charset="utf-8" Content-ID: <660127F00B445247A8285D2E6EC7267C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 12:02:12 -0000 DQo+IE9uIE1heSAyLCAyMDE3LCBhdCA0OjUyIEFNLCBTdXJlc2ggS3Jpc2huYW4gPHN1cmVzaC5r cmlzaG5hbkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGkgU3RlZmFubywNCj4gDQo+IE9uIE1v biwgTWF5IDEsIDIwMTcgYXQgNDoyMSBQTSwgU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkNCj4g PHNwcmV2aWRpQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiANCj4+PiBPbiBNYXkgMSwgMjAxNywgYXQg MTA6MTcgUE0sIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+ IHdyb3RlOg0KPj4+IA0KPj4+IE9uIDAyLzA1LzIwMTcgMDU6NDcsIOelnuaYjumBlOWTiSB3cm90 ZToNCj4+PiANCj4+PiAuLi4NCj4+Pj4+IGRlc3BpdGUgdGhlIHZhcmlvdXMgZXBpc29kZXMsIEkg c3RpbGwgZG8gbm90IGFncmVlIG9uIHRoZSBjdXJyZW50IHRleHQuDQo+Pj4gDQo+Pj4gVGhlIFdH IENoYWlycw0KPj4gDQo+PiANCj4+IGhhdmUgZGVjbGFyZWQgcm91Z2ggY29uc2Vuc3VzIG9uIGFu b3RoZXIgdGV4dCwgbGF0ZXIgY2hhbmdlZCBieSB0aGUgQUQuDQo+IA0KPiBZb3UgbWFrZSBpdCBz b3VuZCBsaWtlIEkgY2hhbmdlZCBpdCBiZWNhdXNlIEkgZmVsdCBsaWtlIGl0IDotKS4NCg0KDQpu byBTdXJlc2gsIEkgZGlkbid0IG1lYW4gdGhhdC4gSSBqdXN0IHJlbGF0ZWQgdGhlIGZhY3QgYW5k IHRoYXQgd2hhdOKAmXMgaGFwcGVuZWQgYWZ0ZXIgYWxsLg0KDQpUaGFua3MuDQpzLg0KDQoNCg0K PiBJDQo+IGluc3RydWN0ZWQgdGhlIGVkaXRvciB0byBjaGFuZ2UgdGhlIHRleHQgZGlyZWN0bHkg YXMgdGhlIHJlc3VsdCBvZiB0aGUNCj4gSUVURiBMYXN0IENhbGwgY29uc2Vuc3VzLiAoYW5kIHRv IGJlIHZlcnkgZnJhbmssIHRoZSBXRyBjb25zZW5zdXMgd2FzDQo+IHByZXR0eSByb3VnaCB0byBz dGFydCBvZmYgd2l0aCkuIEkgZ290IHRoZSBXRyBtYWlsaW5nIGxpc3QgbG9vcGVkIGluDQo+IG9u IHRoZSBJRVRGIExhc3QgQ2FsbCBkaXNjdXNzaW9uIGFzIHNvb24gYXMgdGhpcyBpc3N1ZSBjYW1l IHVwLiBJDQo+IGNvcGllZCB0aGUgSUVURiBsYXN0IGNhbGwgY29uY2x1c2lvbiB0byB0aGUgV0cg bWFpbGluZyBsaXN0LiBUaGUgV0cNCj4gaGFzIGhhZCBhIGNoYW5jZSB0byBoYXZlIGEgc2F5IGV2 ZXJ5IHN0ZXAgb2YgdGhlIHdheS4gVGhlIG9iamVjdGlvbiB0bw0KPiB0aGlzIG5ldyB0ZXh0IGhh cyBhbHdheXMgYmVlbiAiV2UgaGF2ZSBhIHByb3Bvc2FsIHRoYXQgd2lsbCBlbmQgdXANCj4gdmlv bGF0aW5nIHRoaXMgcmVzdHJpY3Rpb24sIHNvIGxldCdzIG1ha2UgaXQgYSBzaG91bGQgbm90Ii4g VGhlIGhlYWRlcg0KPiBpbnNlcnRpb24gcHJvcG9zYWwgKGRyYWZ0LXZveWVyLTZtYW4tZXh0ZW5z aW9uLWhlYWRlci1pbnNlcnRpb24tMDApDQo+IHdhcyBub3QgZXZlbiB3cml0dGVuIHVwIHVudGls IGNvdXBsZSBvZiB3ZWVrcyBhZnRlciB0aGUgSUVURiBMYXN0IENhbGwNCj4gb24gUkZDMjQ2MGJp cyBjb25jbHVkZWQuIEFzIEkgc2FpZCBpbiBteSBtYWlsIGJlbG93DQo+IA0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lwdjYvY3VycmVudC9tc2cyNjkzNC5odG1sDQo+ IA0KPiBJIGFtIGV4cGVjdGluZyB0aGUgcHJvcG9uZW50cyBvZiBoZWFkZXIgaW5zZXJ0aW9uIHRv IGRvIGV4YWN0bHkgd2hhdA0KPiB0aGUgcHJvcG9uZW50cyBvZiB6ZXJvIFVEUCBjaGVja3N1bXMg ZGlkIGFuZCBkbyB0aGUgZ3JvdW5kd29yayBmb3INCj4gdXBkYXRpbmcgUkZDMjQ2MGJpcy4gSSB3 aWxsIGRvIG15IHBhcnQgYnkgc2VuZGluZyBpbiBteSByZXZpZXcgZm9yDQo+IHRoYXQgZHJhZnQg KGRyYWZ0LXZveWVyKS4NCj4gDQo+IFRoYW5rcw0KPiBTdXJlc2gNCg0K From nobody Tue May 2 05:28:38 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 029E31316F5; Tue, 2 May 2017 05:28:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-rfc6434-bis-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149372810995.9943.4693643836237353088@ietfa.amsl.com> Date: Tue, 02 May 2017 05:28:30 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 12:28:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : IPv6 Node Requirements Authors : Tim Chown John Loughney Timothy Winters Filename : draft-ietf-6man-rfc6434-bis-00.txt Pages : 34 Date : 2017-05-02 Abstract: This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 6434, and in turn RFC 4294. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-00 https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6434-bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 2 06:08:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6350E1316FB for ; Tue, 2 May 2017 06:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ecs.soton.ac.uk 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 Pt8JpJWFNahE for ; Tue, 2 May 2017 06:08:23 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4078B131650 for ; Tue, 2 May 2017 06:04:10 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id v42D3IdB010106 for ; Tue, 2 May 2017 14:03:18 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk v42D3IdB010106 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1493730198; bh=LLfdUcbkUak4+ua/Orgkj8riyYg=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=t+fFk+mtRbi8LCKZL2aU/R1wohA9M113MyTKpVl84+dkTWnPgzc5sK5YIv1xyWqha bI+6zK0TvKg2B5b8hda7bLfPVCvKkLKYNttvDYuhnPyuA3P6+ZCJ+FEDIwTM5WMSGu 2HY36Tmhx4dr52RnkI26TmL+F+QFh6AMc1cniTmU= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id y41E3I2263710226KA ret-id none; Tue, 02 May 2017 14:03:18 +0100 Received: from [192.168.0.4] (tchowndsl.claranet.co.uk [212.188.254.49]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id v42D39IR020608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 May 2017 14:03:10 +0100 From: Tim Chown Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-00.txt Date: Tue, 2 May 2017 14:03:08 +0100 References: <149372810995.9943.4693643836237353088@ietfa.amsl.com> To: 6man WG In-Reply-To: <149372810995.9943.4693643836237353088@ietfa.amsl.com> Message-ID: X-Mailer: Apple Mail (2.3273) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=y41E3I226371022600; tid=y41E3I2263710226KA; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: v42D3IdB010106 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 13:08:28 -0000 Hi, Note that this draft version is purely a re-badging of the draft name = after its WG adoption. We=E2=80=99ll be working on an update of the text in the next couple of = weeks, taking on board comments from IETF98 and on the list. All comments are of course welcome at any time. Best wishes, Tim > On 2 May 2017, at 13:28, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Maintenance of the IETF. >=20 > Title : IPv6 Node Requirements > Authors : Tim Chown > John Loughney > Timothy Winters > Filename : draft-ietf-6man-rfc6434-bis-00.txt > Pages : 34 > Date : 2017-05-02 >=20 > Abstract: > This document defines requirements for IPv6 nodes. It is expected > that IPv6 will be deployed in a wide range of devices and = situations. > Specifying the requirements for IPv6 nodes allows IPv6 to function > well and interoperate in a large number of situations and > deployments. >=20 > This document obsoletes RFC 6434, and in turn RFC 4294. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-00 > https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6434-bis-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue May 2 07:26:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404A4131512 for ; Tue, 2 May 2017 07:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 y8Kf3e2pQBiE for ; Tue, 2 May 2017 07:26:47 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6398212940C for ; Tue, 2 May 2017 07:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1493735005; bh=JdfOMjSmCizcJsKY6VRY6hx9do+JLV7YA1vHy/0SvhI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BE7tyU/nPga1hubuGXjxRm9lL8eiAfpwRK1IqfuVVgk6RMgOcEr/XrxYVErXkBwZ4vfUpa3kzaPk/TYjM7zioDxVOZoyZN209hbe/qQln3fJpInfGf1US2P4aw0rf94lYXNSrWTD6GCfZ0zLhenw569an72VltDNkhgaf12VQ6c= Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp0051.outbound.protection.outlook.com [213.199.154.51]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-122-U4st27L2OtaA77-3wSNZow-1; Tue, 02 May 2017 15:23:19 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Tue, 2 May 2017 14:23:18 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a%15]) with mapi id 15.01.1075.010; Tue, 2 May 2017 14:23:17 +0000 From: Tim Chown To: Suresh Krishnan CC: Brian E Carpenter , IPv6 List Subject: Re: Confirmation of consensus to adopt: draft-clw-rfc6434-bis-01 Thread-Topic: Confirmation of consensus to adopt: draft-clw-rfc6434-bis-01 Thread-Index: AQHSv4WvrV5VAUNDyUqIr7iNQR44QKHZvT6AgAA66oCAAJWQgIAAaZqAgAYo6QA= Date: Tue, 2 May 2017 14:23:17 +0000 Message-ID: <69B607A1-6C89-4F9A-80E0-4DCF8AA489E1@jisc.ac.uk> References: <4AC521EA-AA08-4A1C-9C5C-886D0E78FA2A@employees.org> <7144.1493328909@obiwan.sandelman.ca> <7b88b653-5a66-91e3-5ebb-b42150176f4a@gmail.com> <51327F3A-BFF2-42A9-A709-256A84585FB9@jisc.ac.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:1d29:7f6a:25e2:7c09] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:LKzcKnEQTS1AFD3fw3JoDZwPdKl4Ezu8NFktWeKoVXywi6Fe3bTDJ6MPGQa7nG1EiOJDEtcKhc07iA5uclk17qwg3dcuW0fFVIaa2WEFTIG+/kXCrMQY/AQKxorr9J7pf5yVKs9P3LooMdNFYqqOWfkPWHuBHPUnQ7zIfuy8HRkPgox+dkDB2CsH1M8tM7fZFlyqkaCzbtlBOWIiQ1eCCCD2jYLLi8xMnjBjYVs19QpRsdak1UQyDwDMjnxEPAINInX7bdDIquRFU/lv/z/NevJkhjO4uWwm4exgPEOkrwNG3UbDQGBRsfRSSs832g6pHYXzMbnY+nOhnH5v/UYFSg==; 20:fXgKSd2+WR6bsGc3RMXBLJWRjQAtPxSAdKEX1RSGTWh18tdsz+apEzj/ZNaMtKNu4Goeq2LI0kjfpI2rzaRtJDS0nxvVpxMWh0VMsVt4qNqawjMYE09HQkTNQr1KuItfF5sXNQarP7fWOKZ7HVwF8VuY9UmbB5+KbRXtPfYqaOw= x-ms-office365-filtering-correlation-id: 6548450e-34bb-4b9f-8cfd-08d49166c719 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(51444003)(24454002)(377454003)(2906002)(36756003)(3660700001)(8936002)(38730400002)(53546009)(50986999)(110136004)(76176999)(3280700002)(42882006)(6916009)(39060400002)(2950100002)(33656002)(81166006)(305945005)(5660300001)(8676002)(229853002)(5250100002)(4326008)(6512007)(2900100001)(230783001)(50226002)(102836003)(57306001)(93886004)(6116002)(25786009)(6436002)(7736002)(99286003)(74482002)(6246003)(189998001)(6506006)(83716003)(86362001)(54906002)(82746002)(53936002)(6486002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <0F45329235272349BDF373EAB0B10789@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2017 14:23:17.7708 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139 X-MC-Unique: U4st27L2OtaA77-3wSNZow-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 14:26:49 -0000 SGksDQoNCj4gT24gMjggQXByIDIwMTcsIGF0IDE3OjE5LCBTdXJlc2ggS3Jpc2huYW4gPHN1cmVz aC5rcmlzaG5hbkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGkgVGltLCANCj4gDQo+IE9uIEFw ciAyOCwgMjAxNyA2OjA0IEFNLCAiVGltIENob3duIiA8VGltLkNob3duQGppc2MuYWMudWs+IHdy b3RlOg0KPiA+IE9uIDI4IEFwciAyMDE3LCBhdCAwMjowNiwgQnJpYW4gRSBDYXJwZW50ZXIgPGJy aWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSBNaWNoYWVsLA0K PiA+IE9uIDI4LzA0LzIwMTcgMDk6MzUsIE1pY2hhZWwgUmljaGFyZHNvbiB3cm90ZToNCj4gPiAu Li4NCj4gPj4gSSB0aGluayB0aGF0LCBnaXZlbiB0aGUgcHVzaGJhY2sgd2UgaGF2ZSBvbiByZmMy NDYwYmlzLCB0aGF0IEkgd291bGQgbGlrZSB0bw0KPiA+PiBtYWtlIHNvbWUgcHJvZ3Jlc3Mgb24g NjQzNGJpcyBiZWZvcmUgd2UgYXR0ZW1wdCB0byBmaW5hbGl6ZSAyNDYwYmlzLg0KPiA+DQo+ID4g SSBkaXNhZ3JlZSBxdWl0ZSBzdHJvbmdseS4gT24gdGhlIGNvbnRyYXJ5LCB3ZSBzaG91bGQgSU1I TyBnZXQgMjQ2MGJpcw0KPiA+IGZyb3plbiBhbmQgaW4gdGhlIFJGQyBFZGl0b3IgcXVldWUgQVNB UC4gT3RoZXJ3aXNlLCA2NDM0YmlzIHdpbGwgYmUgYnVpbHQgb24NCj4gPiBzaGlmdGluZyBzYW5k cyBhbmQgd2UnbGwgbmV2ZXIgZ2V0IG91dCBvZiB0aGUgbG9vcC4NCj4gDQo+IEkgYWdyZWUgd2l0 aCBCcmlhbi4gIEFuZCA2NDM0YmlzIHdpbGwgb25seSByZWZsZWN0IHdoYXTigJlzIGluIDI0NjBi aXM7IHdlIG5lZWQgdG8gZ2V0IDI0NjBiaXMgZnJvemVuIHNvIHdlIGtub3cgd2hhdCB0byBwdXQg aW4gNjQzNGJpcy4NCj4gDQo+ID4gKEkgcmVhbGx5IHdpc2ggd2UgaGFkIGEgYmV0dGVyIG1lY2hh bmlzbSB0aGFuIGEgcmFyZWx5IHJldmlzZWQgUkZDIGZvciBmb3JtYWxseQ0KPiA+IGRlZmluaW5n IHRoZSBsYXRlc3QgSVB2NiBub2RlIHJlcXVpcmVtZW50cywgYnV0IHRoYXQncyBub3QgcmVhbGx5 IGFuIG9wdGlvbi4NCj4gPiBJTUhPLCBOb2RlIFJlcXVpcmVtZW50cyBzaG91bGQgdXAgZm9yIHJl dmlzaW9uIGV2ZXJ5IHRpbWUgYSByZWxldmFudCBSRkMgaXMNCj4gPiBwdWJsaXNoZWQsIG5vdCBv bmNlIGluIGEgd2hpbGUgd2hlbiBzb21lYm9keSB0aGlua3Mgb2YgaXQuKQ0KPiANCj4gQW4gaW50 ZXJlc3RpbmcgcG9pbnQuIFlvdSBjb3VsZCBmb3IgZXhhbXBsZSBrZWVwIGEgVmVyc2lvbk4tYmlz IGRyYWZ0IHVwZGF0ZWQgYXMgc29vbiBhcyBWZXJzaW9uTiBpcyBwdWJsaXNoZWQsIGFuZCBwdWJs aXNoIFZlcnNpb25OKzEgYXMgYW4gUkZDIGF0IHNvbWUgYWdyZWVkIGludGVydmFsLiBPbiBvdXIg Y3VycmVudCB0cmFjayByZWNvcmQsIHRoYXQgaW50ZXJ2YWwgaXMgZXZlcnkgNiB5ZWFycy4gU3Vj aCBhbiBhcHByb2FjaCB3b3VsZCBtZWFuIHRoZSBtb3N0IHVwLXRvLWRhdGUgZ3VpZGFuY2UgaXMg bm90IGluIHRoZSBtb3N0IHJlY2VudGx5IHB1Ymxpc2hlZCBSRkMsIGJ1dCBpbiB0aGUg4oCcbGl2 aW5n4oCdIEktRC4NCj4gDQo+IFRoYXQgc291bmRzIHJlYXNvbmFibGUgdG8gbWUuIEkgd2FzIGFs c28gdGhpbmtpbmcgaWYgYSB3aWtpIGNvdWxkIHdvcmsgYnV0IGtlZXBpbmcgaXQgdXBkYXRlZCBh cyBhIGRyYWZ0IGdpdmVzIHVzIG1vcmUgb3B0aW9ucy4gRS5nLiBXZSBjb3VsZCBwdWJsaXNoIGFu IFJGQyBldmVyeSB4IHllYXJzIHdpdGggdGhlIGN1cnJlbnQgY29udGVudCBpZiBuZWVkZWQuIA0K DQpXZWxsLCBpdOKAmXMgYSBwb3NzaWJpbGl0eS4gWW91L3dlIGp1c3QgbmVlZCBhIHNtYWxsIGVk aXRvcmlhbCB0ZWFtIHRvIG1haW50YWluIGl0LiBBbmQgd2UgY291bGQgdXNlIEdpdEh1YiB0byB0 cmFjayBwcm9wb3NlZCBjaGFuZ2VzLCBldGMsIGFzIHRoYXQgc2VlbXMgdG8gYmUgZ2V0dGluZyBz b21lIHRyYWN0aW9uIChhbmQgd2XigJlyZSB1c2luZyBpdCBmb3IgdGhpcyAtYmlzIGRvY3VtZW50 KS4gSSBndWVzcyB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB0aGUgV0cgdGhpbmtzIHN1Y2ggYW4g YXBwcm9hY2ggaXMgdXNlZnVsIGFuZCB3b3J0aCB0aGUgZWZmb3J0Lg0KDQpUaW0= From nobody Tue May 2 08:08:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192FA129C4B for ; Tue, 2 May 2017 08:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUu_u3SwwSol for ; Tue, 2 May 2017 08:08:19 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 920BA131701 for ; Tue, 2 May 2017 08:04:58 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id n4so15997619qte.2 for ; Tue, 02 May 2017 08:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nt3WaS+lj54vMatfShAAtS1qiDgOY3USyX5HcOqfrw8=; b=TUsUq4o4RUXAeBLaGZqG7uuz6KJf7asrkGKuFvB+/dWm7ZmxFFuPQaxSSwVRfVg/lP jmIYYteZZAP0ysGEv/GJqiO19+HqFiZsrrYoxcoeMFJamZ3eWkG+FftVpDlVLyLXjK+R PpPzTbmY/xWcb2TdSIKfjs2kxG7GANLfBiD2vEyuqL3+ZQ0E1U6fY0EhNwJe4Ke8IL3Y vZVyWjRShvMr9F4pQLMTQ1JZRcqBcR39wk+DCuEmwdqIRcpnbXc0OptNOzs3a40iOsPA iBxq7vuW9jjkNnryWZQaxAoxOOjZfR2Q9EWUjbzKfibnAhIUcqrCfxLTvQO88fNHuaLU o/xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nt3WaS+lj54vMatfShAAtS1qiDgOY3USyX5HcOqfrw8=; b=VBZ/x6xgzozSuRqKYB4+BwXi+eFOnQRcqtiavuRhKy7WVJhCjPxV/xmrhVqpToifW/ GV4JNYEpYfZ+FYEXK0eRYIpdE7LQtYVBCO35FkZ00F2VFCJ2lcFfdK3ocmkT5O+2QCy8 zSsShZ8tM6i5AhFJPw4oajHHC0Ummyj6cUgNi/fXT4pF/KkQ+EN8jlpvaeqTN7vNCB/+ OYFkl2pFb7HfgMyff8oRpUupu4iRuidO2vR7MVk31HZrjVQ5RvTTp+Ny2EnXuHNVR63a aABiatbuzqZtW244xkXpk/J6tu1qk3YS8OV125f7iZL2OxiAbqeGizpmKcqjXe9qS6Ih IQug== X-Gm-Message-State: AN3rC/7FloY5Dxq0R1yhum6rp2ZfzBifgGlBUDZkjafH1NcRarQ/SRI+ hwRkbU5wb1aoh1OO6otroM1XfPkEzw== X-Received: by 10.200.52.221 with SMTP id x29mr514736qtb.70.1493737497717; Tue, 02 May 2017 08:04:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 2 May 2017 08:04:57 -0700 (PDT) In-Reply-To: <2506bca8-684d-f03f-955f-7c140bc2dca1@gmail.com> References: <2506bca8-684d-f03f-955f-7c140bc2dca1@gmail.com> From: Tom Herbert Date: Tue, 2 May 2017 08:04:57 -0700 Message-ID: Subject: Re: Looping [was: Proposed revised Extension Header text for rfc2460bis] To: Brian E Carpenter Cc: "ipv6@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 15:08:21 -0000 On Mon, May 1, 2017 at 9:38 PM, Brian E Carpenter wrote: > On 02/05/2017 15:54, Tom Herbert wrote: > ... >> Okay, but what would you call it when an intermediate drops a packet >> because it encounters an unknown extension header? > > Sabotage. > Hi Brian, One person's "sabotage" is another person's "value add" :-) Regardless of what it's called and regardless of what the specification says, the net effect is the same: if hosts can't reliably send extension headers then they won't send them at all. This is a straightforward application of the robustness principle, but effectively obsoletes the protocol feature and that should be no surprise to anyone (I have been calling this protocol ossification, but that might not be correct use of that term). Conceptually, if nodes gave a clear reason for why they are dropping a host's packets with EH, then it is possible for the host to modify subsequent packets to be more palatable. While it's true that ICMP is also unreliable, at least if the error messages were defined we could establish the pretense that source hosts and network nodes are working together to achieve end to end connectivity. AFAICT the reason that ICMP is being dropped is different from why EH is being dropped: the ICMP case seems to be more of a security policy decision, whereas EH seems to be more because of operational constraints and processing limitations of devices. If that is the case maybe the ICMP drop case is more easily addressed? Btw, this discussion is not just limited to intermediate nodes. As I mentioned in another thread we intend to add configurable limits to the number of options that are accepted at a destination host. When the destination drops the packet because of such limits it is indistinguishable to the source host from an intermediate node dropping the packet, so any attempted mitigations (like sending an ICMP error) should similar. I don't think the wording in RFC2460bis needs to change, but maybe some guidance could be added to node requirements... Tom Tom > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue May 2 08:45:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B222912751F for ; Tue, 2 May 2017 08:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 5Xe0THritbe7 for ; Tue, 2 May 2017 08:45:08 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E2F129B4C for ; Tue, 2 May 2017 08:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1493739716; bh=ZWYfBrmC+h8Ke3Hv9H6dk3T7YiPnBoOfIBJvuLjjChs=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fObWTkwxl7SMrfty2NDKWwm5/S1xlzlaA5vO/D6qprqFT2zYgkitoCpOPljWggczkoVrM9lLTN9lRIRcIZsJEsyT4/GywphPdtO5JBO/9y0D9ij+gCdJ5rVGVs11IHMj4jd+O/Z2ps54OSOrcqGZc29RYBRIsupijOd+tGoA9ls= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0179.outbound.protection.outlook.com [213.199.154.179]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-66-BRhjERIqPfWFFBFQWJjtcQ-1; Tue, 02 May 2017 16:41:51 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Tue, 2 May 2017 15:41:50 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a%15]) with mapi id 15.01.1075.010; Tue, 2 May 2017 15:41:50 +0000 From: Tim Chown To: Tom Herbert CC: Brian E Carpenter , "ipv6@ietf.org" Subject: Re: node requirements text [was: Proposed revised Extension Header text for rfc2460bis] Thread-Topic: node requirements text [was: Proposed revised Extension Header text for rfc2460bis] Thread-Index: AQHSw1qdcxTUkzviTk2B0QDHhsmEoQ== Date: Tue, 2 May 2017 15:41:49 +0000 Message-ID: <79FBE5B6-41CB-497B-85C0-00714F2FAEAB@jisc.ac.uk> References: <2506bca8-684d-f03f-955f-7c140bc2dca1@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:1d29:7f6a:25e2:7c09] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:pYkInvGpWYIn/Kn5Ucqon6qxxN2K+OUWX8saaqC4vVQWu47WPoeWEDCUCsUNvHElXEfyAzawfdLYnttjVOmMGlFDLWA9a9LkqoWLvIukdGajwQ3ipg1gU6PPen5Q5X0QzTkllSeYe/n8JVCF0TEMt1/cxC/AIgy2fdW4vyX44DanEvosavnvkUzgkt1z7ULg4bMoNuxPlnQIY6i1URodr4fK7JXhDdx02BWketU/YoBrb3MADBwRfukpRdsjvi8gAgc6+4J1JWvGad9/coQaQ+ZQQ5HrF2SGGmyJewISBuY+TV0NfedVNbc3t7RQVzp0HI0SKtJFxaE4qaciRM8uLw==; 20:LRM+6hx4Er+zAV0SZKm08+caUrm0WvDPztl8QucLkGFSw939ogKhRFU8z7f/GcRgxWrj23dI6+iKqtCai1ZNb9kdBX/kH0bRqFtcBMp2zjHNzAj7fyOBTNd/umvXZlPxVvyFoLEnytZPDWkeZHaLLtS+R2NnbcI5LjHkc8Zol0g= x-ms-office365-filtering-correlation-id: a5d1cfaf-a418-41a2-a5b5-08d49171bfc8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(24454002)(6436002)(7736002)(25786009)(6116002)(50226002)(2900100001)(6512007)(93886004)(57306001)(6486002)(53936002)(478600001)(74482002)(6246003)(189998001)(99286003)(82746002)(54906002)(86362001)(83716003)(6506006)(50986999)(53546009)(110136004)(102836003)(38730400002)(39060400002)(3280700002)(76176999)(6916009)(42882006)(2906002)(8936002)(36756003)(3660700001)(8676002)(5660300001)(305945005)(4326008)(229853002)(5250100002)(2950100002)(33656002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <168C92A1C543F2428719A52C4D9E360F@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2017 15:41:49.9918 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139 X-MC-Unique: BRhjERIqPfWFFBFQWJjtcQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 15:45:09 -0000 SGksDQoNCj4gT24gMiBNYXkgMjAxNywgYXQgMTY6MDQsIFRvbSBIZXJiZXJ0IDx0b21AaGVyYmVy dGxhbmQuY29tPiB3cm90ZToNCj4gDQo+IDxzbmlwPg0KPiANCj4gQnR3LCB0aGlzIGRpc2N1c3Np b24gaXMgbm90IGp1c3QgbGltaXRlZCB0byBpbnRlcm1lZGlhdGUgbm9kZXMuIEFzIEkNCj4gbWVu dGlvbmVkIGluIGFub3RoZXIgdGhyZWFkIHdlIGludGVuZCB0byBhZGQgY29uZmlndXJhYmxlIGxp bWl0cyB0bw0KPiB0aGUgbnVtYmVyIG9mIG9wdGlvbnMgdGhhdCBhcmUgYWNjZXB0ZWQgYXQgYSBk ZXN0aW5hdGlvbiBob3N0LiBXaGVuDQo+IHRoZSBkZXN0aW5hdGlvbiBkcm9wcyB0aGUgcGFja2V0 IGJlY2F1c2Ugb2Ygc3VjaCBsaW1pdHMgaXQgaXMNCj4gaW5kaXN0aW5ndWlzaGFibGUgdG8gdGhl IHNvdXJjZSBob3N0IGZyb20gYW4gaW50ZXJtZWRpYXRlIG5vZGUNCj4gZHJvcHBpbmcgdGhlIHBh Y2tldCwgc28gYW55IGF0dGVtcHRlZCBtaXRpZ2F0aW9ucyAobGlrZSBzZW5kaW5nIGFuDQo+IElD TVAgZXJyb3IpIHNob3VsZCBzaW1pbGFyLg0KPiANCj4gSSBkb24ndCB0aGluayB0aGUgd29yZGlu ZyBpbiBSRkMyNDYwYmlzIG5lZWRzIHRvIGNoYW5nZSwgYnV0IG1heWJlDQo+IHNvbWUgZ3VpZGFu Y2UgY291bGQgYmUgYWRkZWQgdG8gbm9kZSByZXF1aXJlbWVudHMuLi4NCg0KSSB0aGluayBJIHNh dyB5b3UgbWVudGlvbiB0aGlzIGJlZm9yZSwgYW5kIGl0IHNvdW5kcyByZWFzb25hYmxlLiBGZWVs IGZyZWUgdG8gcHJvcG9zZSB0ZXh0IGZvciA2NDM0LWJpcyDigKYNCg0KVGlt From nobody Tue May 2 08:46:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C4F1315B8 for ; Tue, 2 May 2017 08:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 8TPPsDohGO_s for ; Tue, 2 May 2017 08:46:47 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14835129C21 for ; Tue, 2 May 2017 08:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1493739800; bh=AmsfprPoCE/0x4zHS+b8zQ6gr4HKmEEDyVHrA0rpzLY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LB7bFbpG62XNEz9hnO309ehE5uEDl2FIefN92cX8W5HM5tM+k97uSl5r1k0j2uwFVRgwOOauf4lEu72FVKnQMjFjh9EIQpH5sbRV1/TSq/jnecLxlsoWBRmCGm5Gn1fRR8++9YmL48f5Vpj2iJ80RQKtbajM6mppchD/DgkF1g8= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0184.outbound.protection.outlook.com [213.199.154.184]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-77-JoPIMCinOEeaMPiN6wKoAA-1; Tue, 02 May 2017 16:43:15 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Tue, 2 May 2017 15:43:13 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a%15]) with mapi id 15.01.1075.010; Tue, 2 May 2017 15:43:13 +0000 From: Tim Chown To: Tom Herbert CC: Brian E Carpenter , 6man WG Subject: Re: Looping [was: Proposed revised Extension Header text for rfc2460bis] Thread-Topic: Looping [was: Proposed revised Extension Header text for rfc2460bis] Thread-Index: AQHSwtBEck07g3KDo0qJbkrN/0OKr6HgIaCAgAEOWwA= Date: Tue, 2 May 2017 15:43:13 +0000 Message-ID: <9067CCCC-5093-4604-94C9-EA64B36DB289@jisc.ac.uk> References: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca> <56D4D8F8-98FC-4F2D-8E0E-C788BF88D70D@gmail.com> <20170501185128.GB23490@ernw.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:1d29:7f6a:25e2:7c09] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:URyKxD+UnW4YvSgskkKoNc2isO19zXqvGHssQcxMs5NlXzmnIVHUbQ5MhNK2gJCuqfT38RxpV9+RXZdnpZKDX4YI5g6iUlhyaUWTjmtcuP9V3zPlhpjmTpJI6HNqTQ8WD6YkHkaYOBLha1yCu9smylyzfruFY4F9xFraYDtRwrLyMjyunI4fMU37sz7ZwxsX7AJVhbeVHDZUTSUVNiFD2v6jz5qYsVJcoggjzCNAQiK3Go0WRNLFuGIpGuznWitgEczJeLl1TRK0EKTk7FAJxTjS/b0SYQZEaYMFzwEPpDlr3odGU9PSWgb0jreMJm1AD8pw/+3ec2x2UdyZvVIoow==; 20:DZMWMqWs0vZGQ+H4eP9Z8ZSYJeYpyA0OaDym1Lvjk1F3hYeL4wsXu4Cyc3gS2aHRwZYUFkiTG5aTo2ZOHeq5nwmnSCztPtn0F5WYBo7ayWLq20+Dg+U3u1lEr7B6rv1ge+PE72a0oagQFw8Bt19p7Q0+7kkhTw/o5RCHyS7RoWM= x-ms-office365-filtering-correlation-id: 9e274eaf-9d71-4f2f-b537-08d49171f1a3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(24454002)(377454003)(6436002)(7736002)(25786009)(6116002)(50226002)(2900100001)(6512007)(93886004)(57306001)(6486002)(53936002)(478600001)(74482002)(6246003)(189998001)(99286003)(82746002)(54906002)(86362001)(83716003)(6506006)(50986999)(53546009)(110136004)(102836003)(38730400002)(39060400002)(3280700002)(76176999)(6916009)(42882006)(2906002)(8936002)(36756003)(3660700001)(8676002)(5660300001)(305945005)(4326008)(229853002)(5250100002)(2950100002)(33656002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2017 15:43:13.6046 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139 X-MC-Unique: JoPIMCinOEeaMPiN6wKoAA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 15:46:49 -0000 SGksDQoNCj4gT24gMiBNYXkgMjAxNywgYXQgMDA6MzUsIFRvbSBIZXJiZXJ0IDx0b21AaGVyYmVy dGxhbmQuY29tPiB3cm90ZToNCj4gDQo+IE9uIE1vbiwgTWF5IDEsIDIwMTcgYXQgNDowOSBQTSwg QnJpYW4gRSBDYXJwZW50ZXINCj4gPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6 DQo+PiBPbiAwMi8wNS8yMDE3IDEwOjQ4LCBUb20gSGVyYmVydCB3cm90ZToNCj4+PiBPbiBNb24s IE1heSAxLCAyMDE3IGF0IDM6MjcgUE0sIGpvZWwgamFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbT4g d3JvdGU6DQo+PiAuLi4NCj4+Pj4gSW4gbW9kZXJuIGludGVybmV0IHByb3RvY29sIHJvdXRlcnMs IHRoZXJlIGFyZSBhIG51bWJlciBvZiByZWFzb25zIHdoeQ0KPj4+PiByZWNvdXJzZSB0byB0aGUg TDQgaGVhZGVyIG1pZ2h0IGJlIHByYWN0aWNhbGx5IHJlcXVpcmVkLCB0aGVzZSBpbmNsdWRlDQo+ Pj4+IHZhcmlvdXNseSB0aGUgYXBwbGljYXRpb24gb2YgY29udHJvbC1wbGFuZSBhY2xzICh3aGlj aCBtYXkgb2YgY291cnNlDQo+Pj4+IGluY2x1ZGUgdHJhZmZpYyBzZXQgdGhyb3VnaCByYXRoZXIg dGhhbiB0byB0aGUgYm94KSwgIHRoZSBhcHBsaWNhdGlvbiBvZg0KPj4+PiBmb3J3YXJkaW5nIHBs YW5lIGFjbHMgKGV4YW1wbGUgNTU3NSBiZ3AgZmxvd3NwZWMgcnVsZXMsIHN0YXRpYyBhY2xzLA0K Pj4+PiBldGMpLCBoYXNoaW5nLCBuZWVkcyB0byBwZXJmb3JtIHFvcyBtYXJraW5nIGFuZCBzbyBv bi4gIGluIHRoZSBjYXNlcw0KPj4+PiB3aGVyZSBhbiBhc2ljJ3MgbG9va3VwIHNwYWNlIHByZWNs dWRlcyBwcm9jZXNzaW5nIHRoZSBleHRlbnNpb24gaGVhZGVyDQo+Pj4+IGNoYWluLCBvciB3aGVy ZSBmb3Igb3RoZXIgcmVhc29ucyB0aGUgbDQgaGVhZGVyIGNhbm5vdCBiZSBpZGVudGlmaWVkIGl0 DQo+Pj4+IGlzIGNsZWFybHkgcHJvYmxlbWF0aWMgdG8gdW5jb25kaXRpb25hbGx5IGZvcndhcmQg dGhlIHBhY2tldC4NCj4+Pj4gDQo+Pj4gSXQgZG9lc24ndCBzZWVtIGxpa2VseSB0aGF0IHRoaXMg YmVoYXZpb3IgaXMgZ29pbmcgdG8gZ28gYXdheSBhbnkgdGltZQ0KPj4+IHNvb24sIGlmIGV2ZXIu IE1heWJlIGluc3RlYWQgb2YganVzdCBkcm9wcGluZyBwYWNrZXQgdGhlc2UgZGV2aWNlcw0KPj4+ IHNob3VsZCBzZW5kIGJhY2sgYW4gSUNNUCBlcnJvciB0byBpbmZvcm0gdGhlIHNlbmRlciBvZiB3 aGljaCBFSCBjYXVzZWQNCj4+PiB0aGUgZHJvcD8NCj4+IA0KPj4gU2luY2UgdW5rbm93biBJQ01Q djYgaXMgYXQgaGlnaCByaXNrIG9mIGJlaW5nIGRyb3BwZWQgdG9vLCB0aGlzIGlzDQo+PiB1bmxp a2VseSB0byBoZWxwLg0KPj4gDQo+PiBQZW9wbGUsIHdlIGRpc2N1c3NlZCBhbGwgdGhpcyB3aGls ZSBSRkM3MDQ1IHdhcyBiZWluZyBkcmFmdGVkLCBhbmQNCj4+IG1hbnkgb3RoZXIgdGltZXMgYXMg d2VsbC4gV2hhdCBoYXMgaXQgZ290IHRvIGRvIHdpdGggdGhlIGZpbmFsDQo+PiB3b3Jkc21pdGhp bmcgb2YgdGhlIElQdjYgSW50ZXJuZXQgU3RhbmRhcmQsIHdoZXJlIHRoZSB0ZWNobmljYWwNCj4+ IChyb3VnaCkgY29uc2Vuc3VzIGlzIGFscmVhZHkga25vd24/DQo+PiANCj4gQnJpYW4sDQo+IA0K PiBUaGUgd29yZGluZyBpbiBSRkMyNDYwYmlzIGlzOg0KPiANCj4gIkV4dGVuc2lvbiBoZWFkZXJz IChleGNlcHQgZm9yIHRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyKSBhcmUgbm90DQo+IHBy b2Nlc3NlZCwgaW5zZXJ0ZWQsIG9yIGRlbGV0ZWQgYnkgYW55IG5vZGUgYWxvbmcgYSBwYWNrZXQn cyBkZWxpdmVyeQ0KPiBwYXRoLCB1bnRpbCB0aGUgcGFja2V0IHJlYWNoZXMgdGhlIG5vZGUiDQo+ IA0KPiBJbnNlcnRlZCBvciBkZWxldGVkIGFyZSBub3QgY29tbW9uIG9wZXJhdGlvbnMgc28gbWF5 YmUgdGhleSBjYW4gYmUNCj4gc3F1YXNoZWQsIGJ1dCBpbiB0aGUgSW50ZXJuZXQgZXh0ZW5zaW9u IGhlYWRlcnMgX2FyZV8gYmVpbmcgcHJvY2Vzc2VkDQo+IGluIG1vZGVybiBJbnRlcm5ldCByb3V0 ZXJzIGFzIEpvZWwgc2FpZCwgaWYgbm90aGluZyBlbHNlIHRvIGZpbmQgdGhlDQo+IHRyYW5zcG9y dCBoZWFkZXIuIEl0J3MgaGFyZCB0byByZWN0aWZ5IHRoZSBzdGFuZGFyZCBhZ2FpbnN0IHRoaXMN Cj4gcmVhbGl0eSBvdGhlciB0aGFuIHRvIG5vdCB1c2UgYW4gRUggYXQgYWxsIHdoaWNoIGlzIHBy ZXR0eSBtdWNoIHdoZXJlDQo+IGhvc3RzIGFyZSBjdXJyZW50bHkuDQoNCkJ1dCB0aGUgd29yZCDi gJxleGFtaW5lZOKAnSB3YXMgcmVtb3ZlZCBmcm9tIHRoZSBhYm92ZSBxdW90ZWQgdGV4dCwgZm9y IHRoYXQgcmVhc29uLg0KDQpUaW0= From nobody Tue May 2 08:50:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0655A129B5A for ; Tue, 2 May 2017 08:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 GTsCqXkGLqnC for ; Tue, 2 May 2017 08:50:28 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37215129C08 for ; Tue, 2 May 2017 08:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1493740005; bh=c5OQ2/+PXRJvs+1fULRXYPvflzpB9xX/cKW4yXUdSZY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=TCXc3ZA+z3dynW8fj3PhCKM5IMA+x/zlKcwHIdzgMBJIHCzTA++7MF6U5UywBHcfqBMwayhomiPkIcBQs3Rj5Z7+2ogBZEAuN1SnAtTj6HoM3/RNKf7txmzGQ9gFBEeoCHkyt6hwMEtSK1Tuu8qyPDlU2CmJ1gV5HdZiSQhLJwU= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0177.outbound.protection.outlook.com [213.199.154.177]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-69-CLO11ZRtMSyzL3uYu9vp9w-1; Tue, 02 May 2017 16:46:41 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Tue, 2 May 2017 15:46:39 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a%15]) with mapi id 15.01.1075.010; Tue, 2 May 2017 15:46:39 +0000 From: Tim Chown To: Suresh Krishnan CC: "Stefano Previdi (sprevidi)" , Fernando Gont , IPv6 List , Bob Hinden , =?utf-8?B?56We5piO6YGU5ZOJ?= Subject: Re: Proposed revised Extension Header text for rfc2460bis Thread-Topic: Proposed revised Extension Header text for rfc2460bis Thread-Index: AQHSvU2RtftRrX/0x02YX67sCFIJ2qHZIj2AgACEfACAAA+WgIABQeKAgAADagCAABGugIABzGwAgALxzACAACnTAIAAAQ0AgABtJwCAANhtgA== Date: Tue, 2 May 2017 15:46:39 +0000 Message-ID: References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com> <59036B64.4010008@cisco.com> <1CA0E022-B54D-455C-8063-0AE34DD2CCC2@cisco.com> <8C442C82-D1D5-49E3-858D-B7EDFBEC6817@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:1d29:7f6a:25e2:7c09] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:F0Fg7PCohCpfo+tY31xsQbiwZuzBRSn7ykWk9RL3MvJRmvNHTqLbkIHk8e96Ar6pnqqHeojNCsh/sRRDvLBEuf4Evhdh3zdF4qj5YDnS+XeRsAIxB8VMIk8TQvrA2sKB8qTEy84Pf80GBt/vUv9kp7lJxNsUGraRuL/tTxY+DOsvDO5Hf8HF4dxsV9IlJJfH1zy/IWlaVqbt7OHJR/ZTFYXhyaUA4NrgkO/eIPK8aENQvSmp2VvgyDQWxn81dlHj4+tUObRKBPLDZzYRnFv2FexwPZmMR4WXbxrkYYA6ReWI40MeDSudk1MeuerS8HLU6C3JzjMlEegXhNCobDvIBg==; 20:JnJsZQ1ZdAhSQvDhGOsrA4jMn3j54EoM69TfoWe12HKzHnFqEAokb41qyj2MH+H0PSBsWJ7+Ay8GInK3S/8s5h8Q92ozunHwlz6R6YSe3+AQuGYjXXdSZanqqfRBfEc8dxBypZ2D9pi2tqd2JZsHeAEi4OgVeZWrEbeX4fhLmFQ= x-ms-office365-filtering-correlation-id: 2aaaa13d-7a12-44b9-3b67-08d491726c75 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1138; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39400400002)(39840400002)(377454003)(24454002)(6486002)(8936002)(50226002)(81166006)(110136004)(2906002)(54906002)(53936002)(99286003)(57306001)(229853002)(6506006)(6306002)(42882006)(2950100002)(36756003)(6436002)(86362001)(561944003)(6246003)(3660700001)(3280700002)(53546009)(5250100002)(5660300001)(6916009)(6512007)(25786009)(33656002)(8676002)(189998001)(76176999)(7736002)(305945005)(50986999)(2900100001)(74482002)(82746002)(38730400002)(39060400002)(102836003)(6116002)(93886004)(83716003)(4326008)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2017 15:46:39.6754 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1138 X-MC-Unique: CLO11ZRtMSyzL3uYu9vp9w-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 15:50:30 -0000 SGksDQoNCj4gT24gMiBNYXkgMjAxNywgYXQgMDM6NTIsIFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNo LmtyaXNobmFuQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBTdGVmYW5vLA0KPiANCj4gT24g TW9uLCBNYXkgMSwgMjAxNyBhdCA0OjIxIFBNLCBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKQ0K PiA8c3ByZXZpZGlAY2lzY28uY29tPiB3cm90ZToNCj4+IA0KPj4+IE9uIE1heSAxLCAyMDE3LCBh dCAxMDoxNyBQTSwgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNv bT4gd3JvdGU6DQo+Pj4gDQo+Pj4gT24gMDIvMDUvMjAxNyAwNTo0Nywg56We5piO6YGU5ZOJIHdy b3RlOg0KPj4+IA0KPj4+IC4uLg0KPj4+Pj4gZGVzcGl0ZSB0aGUgdmFyaW91cyBlcGlzb2Rlcywg SSBzdGlsbCBkbyBub3QgYWdyZWUgb24gdGhlIGN1cnJlbnQgdGV4dC4NCj4+PiANCj4+PiBUaGUg V0cgQ2hhaXJzDQo+PiANCj4+IA0KPj4gaGF2ZSBkZWNsYXJlZCByb3VnaCBjb25zZW5zdXMgb24g YW5vdGhlciB0ZXh0LCBsYXRlciBjaGFuZ2VkIGJ5IHRoZSBBRC4NCj4gDQo+IFlvdSBtYWtlIGl0 IHNvdW5kIGxpa2UgSSBjaGFuZ2VkIGl0IGJlY2F1c2UgSSBmZWx0IGxpa2UgaXQgOi0pLiBJDQo+ IGluc3RydWN0ZWQgdGhlIGVkaXRvciB0byBjaGFuZ2UgdGhlIHRleHQgZGlyZWN0bHkgYXMgdGhl IHJlc3VsdCBvZiB0aGUNCj4gSUVURiBMYXN0IENhbGwgY29uc2Vuc3VzLiAoYW5kIHRvIGJlIHZl cnkgZnJhbmssIHRoZSBXRyBjb25zZW5zdXMgd2FzDQo+IHByZXR0eSByb3VnaCB0byBzdGFydCBv ZmYgd2l0aCkuIEkgZ290IHRoZSBXRyBtYWlsaW5nIGxpc3QgbG9vcGVkIGluDQo+IG9uIHRoZSBJ RVRGIExhc3QgQ2FsbCBkaXNjdXNzaW9uIGFzIHNvb24gYXMgdGhpcyBpc3N1ZSBjYW1lIHVwLiBJ DQo+IGNvcGllZCB0aGUgSUVURiBsYXN0IGNhbGwgY29uY2x1c2lvbiB0byB0aGUgV0cgbWFpbGlu ZyBsaXN0LiBUaGUgV0cNCj4gaGFzIGhhZCBhIGNoYW5jZSB0byBoYXZlIGEgc2F5IGV2ZXJ5IHN0 ZXAgb2YgdGhlIHdheS4gVGhlIG9iamVjdGlvbiB0bw0KPiB0aGlzIG5ldyB0ZXh0IGhhcyBhbHdh eXMgYmVlbiAiV2UgaGF2ZSBhIHByb3Bvc2FsIHRoYXQgd2lsbCBlbmQgdXANCj4gdmlvbGF0aW5n IHRoaXMgcmVzdHJpY3Rpb24sIHNvIGxldCdzIG1ha2UgaXQgYSBzaG91bGQgbm90Ii4gVGhlIGhl YWRlcg0KPiBpbnNlcnRpb24gcHJvcG9zYWwgKGRyYWZ0LXZveWVyLTZtYW4tZXh0ZW5zaW9uLWhl YWRlci1pbnNlcnRpb24tMDApDQo+IHdhcyBub3QgZXZlbiB3cml0dGVuIHVwIHVudGlsIGNvdXBs ZSBvZiB3ZWVrcyBhZnRlciB0aGUgSUVURiBMYXN0IENhbGwNCj4gb24gUkZDMjQ2MGJpcyBjb25j bHVkZWQuIEFzIEkgc2FpZCBpbiBteSBtYWlsIGJlbG93DQo+IA0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lwdjYvY3VycmVudC9tc2cyNjkzNC5odG1sDQo+IA0KPiBJ IGFtIGV4cGVjdGluZyB0aGUgcHJvcG9uZW50cyBvZiBoZWFkZXIgaW5zZXJ0aW9uIHRvIGRvIGV4 YWN0bHkgd2hhdA0KPiB0aGUgcHJvcG9uZW50cyBvZiB6ZXJvIFVEUCBjaGVja3N1bXMgZGlkIGFu ZCBkbyB0aGUgZ3JvdW5kd29yayBmb3INCj4gdXBkYXRpbmcgUkZDMjQ2MGJpcy4gSSB3aWxsIGRv IG15IHBhcnQgYnkgc2VuZGluZyBpbiBteSByZXZpZXcgZm9yDQo+IHRoYXQgZHJhZnQgKGRyYWZ0 LXZveWVyKS4NCg0KSXQgd291bGQgYmUgZ29vZCB0byBzcGVuZCBvdXIgY3ljbGVzIGZvY3VzaW5n IG9uIHRoaXMsIHJhdGhlciB0aGFuIGV4dGVuZGVkIGZpbGlidXN0ZXJpbmcgb24gMjQ2MGJpcy4N Cg0KV2UgaGF2ZSAocm91Z2gpIGNvbnNlbnN1czsgbGV04oCZcyBnZXQgMjQ2MGJpcyBwdWJsaXNo ZWQgYXMgSVMgYW5kIG1vdmUgb24gdG8gcHJvZ3Jlc3NpbmcgZHJhZnQtdm95ZXItNm1hbi1leHRl bnNpb24taGVhZGVyLWluc2VydGlvbi4NCg0KVGlt From nobody Tue May 2 08:59:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF389129A8F for ; Tue, 2 May 2017 08:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM7pRSJPC_jT for ; Tue, 2 May 2017 08:59:46 -0700 (PDT) Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (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 719911295A0 for ; Tue, 2 May 2017 08:56:56 -0700 (PDT) X-AuditID: 60721c4c-b53ff70000006581-4d-5908ac434ac0 Received: from VAADCEX45.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id E3.D7.25985.34CA8095; Tue, 2 May 2017 11:56:53 -0400 (EDT) Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX45.cable.comcast.com (147.191.103.222) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 2 May 2017 11:56:50 -0400 Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1263.000; Tue, 2 May 2017 11:56:50 -0400 From: "Leddy, John" To: Tom Herbert , Brian E Carpenter CC: "ipv6@ietf.org" Subject: Re: Looping [was: Proposed revised Extension Header text for rfc2460bis] Thread-Topic: Looping [was: Proposed revised Extension Header text for rfc2460bis] Thread-Index: AQHSw1X2hprmiNExs0uxrfk97Sne6qHhMr6A Date: Tue, 2 May 2017 15:56:50 +0000 Message-ID: <8A3F0CDC-350F-426B-BEE8-A13EBDC2ED9B@cable.comcast.com> References: <2506bca8-684d-f03f-955f-7c140bc2dca1@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.10] Content-Type: text/plain; charset="utf-8" Content-ID: <06BD5FD5F5F5AF4590CEA08F0E89A1AE@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsWSUOxpoeu6hiPSYN5scYu2i/uYLF6efc9k cfnSI2YHZo+ds+6ye/TOncbqsWTJT6YA5igum5TUnMyy1CJ9uwSujK9rb7MVnDKpuPvwA1MD 4xzjLkZODgkBE4mz+zeydDFycQgJbGeSuHfpAxtIQkjgIKNE/4kgiMQJRon7lx8wgyTYBHQk Zky7xtrFyMEhIhAhcfV6JUiYWUBZ4s79mYwgtrBAsMTs63/ZQWwRgRCJzXNeMELYRhKL1s1j ArFZBFQkmtauBYvzCrhIvFg9gRFi10QmiRnHrrGAzOcUCJQ4sVMbpIZRQEzi+6k1TBC7xCVu PZnPBPGAgMSSPeeZIWxRiZeP/7GC2KICehLXPqxkgYjrSJy9/oQRwjaQ2Lp0H1RcXuLIhH9g q5gFNCXW79KHGO8gsff5ZjYIW1FiSvdDdogzBSVOznwC1SopcXDFDZYJjNKzkFw0C2HSLCST ZiGZNAvJpAWMrKsY5coSE1OSczPyS0sMjPSSE5NyUvWS83OTE4tLQPQmRlDEF8n47GD8NM3j EKMAB6MSD2/cYo5IIdbEsuLK3EOMEhzMSiK8X5cAhXhTEiurUovy44tKc1KLDzFKc7AoifNa TWePFBJITyxJzU5NLUgtgskycXBKNTBabtQp81PIvF0onzst4dI02ROXFdMPbHu94YrjKY+b NcKPDr62rtu2eaa9d53APwOmaTwGohei3HV/XWazeRYytVT5UIz8C2azpsZaJubnQbu2b7Jl mfdsx6ObT7pWiD44bGxl43vwca/Zw6DrgS9/76nnOSK6PHT3wkOFh/5cv/ClRuPgw+J9SizF GYmGWsxFxYkA0AWYGfQCAAA= Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 15:59:49 -0000 QXJlIHdlIGFsbCB0YWxraW5nIGFib3V0IHRoZSBzYW1lIG1lY2hhbmlzbXMgdGhhdCBhcmUgZXhw ZWN0ZWQgaW4gcHJvZHVjdGlvbiBlbnZpcm9ubWVudHM/DQoNCkkgd29u4oCZdCBhZGRyZXNzIHRo ZSBIQkggZXh0ZW5zaW9uIGhlYWRlciwgYnV0IGZvY3VzIG9uIHRoZSBSb3V0aW5nIEVILg0KDQpJ IHdvdWxkIGV4cGVjdCBtb3N0L2FsbCBTUOKAmXMgd291bGQgc3RpbGwgaGF2ZSBiYXNpYyBmaWx0 ZXJpbmcgaW4gcGxhY2UgdG8gcHJvdGVjdCB0aGVpciBpbmZyYXN0cnVjdHVyZS4NCkFueSBwYWNr ZXQgZGVzdGluZWQgdG8gYW4gU1DigJlzIGluZnJhc3RydWN0dXJlIGJsb2NrIGZyb20gYW4gdW50 cnVzdGVkIHNvdXJjZSBzaG91bGQgZXhwZWN0IHRvIGJlIGJsb2NrZWQuDQpSb3V0ZXJzIHRoZW1z ZWx2ZXMgd291bGQgZHJvcCBiYXNlZCBvbiBhIHRydXN0ZWQgU1JDIEFDTCwgYnV0IGVudHJ5IHBv aW50cyB0byB0aGUgbmV0d29yayB3b3VsZCBhbHNvIGxpa2VseSBkcm9wIGJhc2VkIG9uIGEgRFNU IEFDTCBmb3IgdGhlIGluZnJhc3RydWN0dXJlIGFkZHJlc3MgYmxvY2suICBUaGUgRFNUIEFDTCBh Y3RzIGFzIGEgcHJveHkgZm9yIHRoZSBhY3R1YWwgZGVzdGluYXRpb25zLCBidXQgdGhlIHBhY2tl dCB3aWxsIGJlIGRyb3BwZWQgd2l0aCBvciB3aXRob3V0IGFuIEVIIGlmIHRoZSBzcmMgaXMgbm90 IHRydXN0ZWQgdG8gc2VuZCBwYWNrZXRzLiAgSWYgdGhlIHBhY2tldCBoYXMgYSBSb3V0aW5nIEVI LCBidXQgdGhlIGRlc3RpbmF0aW9uIGlzIG5vdCBwYXJ0IG9mIHRoZSBTUOKAmXMgaW5mcmFzdHJ1 Y3R1cmUsIHdoeSB3b3VsZCB5b3UgZXhwbGljaXRseSBkcm9wIGl0PyAgRXZlbiBpZiB5b3Ugdmlv bGF0ZWQgMjQ2MGJpcyBhbmQgcHJvY2Vzc2VkIHRoZSBFSCBvbiBlbnRyeSB0byB0aGUgbmV0d29y ayBhbmQgbG9va2VkIGZvciBhbiBhZGRyZXNzIHRoYXQgYmVsb25nZWQgdG8gdGhlIGluZnJhc3Ry dWN0dXJlIHRvIGRyb3AgdGhlIHBhY2tldCwgdGhlIGVmZmVjdCB3b3VsZCBiZSB0aGUgc2FtZSBi dXQgdGhlcmUgd291bGQgYmUgYSBsb3QgbW9yZSBwZXIgcGFja2V0IHByb2Nlc3NpbmcuICBZb3Ug Y291bGQganVzdCB3YWl0IHVudGlsIHRoZSBFSCBpcyBwcm9jZXNzZWQgdGhlbiBkcm9wIGl0IHdo ZW4gaXQgcmUtZW50ZXJzIHRoZSBuZXR3b3JrIHdpdGggdGhlIGRzdCBwYXJ0IG9mIHRoZSBpbmZy YXN0cnVjdHVyZSBibG9jay4gIChub3QgdGhhdCB3b3JyaWVkIGFib3V0IHBpbmcgcG9uZyBhdHRh Y2tzLCBpdCBjYW4gYmUgZG9uZSBhdCBoaWdoZXIgbGV2ZWxzIGluIHRoZSBzdGFjayBhbnl3YXkp Lg0KDQpBcyBhIGhvc3QgYnVpbGRpbmcgYSBwYWNrZXQgd2l0aCBhIFJvdXRpbmcgRUgsIEkgd291 bGQgbm90IGV4cGVjdCB0aGF0IHBpY2tpbmcgYW55IEludGVybmV0IGFkZHJlc3NlcyB3b3VsZCBq dXN0IHdvcmsgYW5kIGNhbiBiZSBpbnNlcnRlZCBpbnRvIHRoZSBFSC4gIFRoZXJlIG5lZWRzIHRv IGJlIGFub3RoZXIgbWVjaGFuaXNtIHRvIGFsbG93IHRoZSBhcHBsaWNhdGlvbiB0byBrbm93IHdo YXQgY2FuIGJlIHB1dCBpbiB0aGUgRUgsIHRoaXMgbWVjaGFuaXNtIG1heSBiZSBhcHBsaWNhdGlv biBkZXBlbmRlbnQsIGJ1dCBpdCBpc27igJl0IGp1c3QgdG9zcyBhbnkgYWRkcmVzc2VzIGZyb20g YSB0cmFjZXJvdXRlIGludG8gYW4gRUguICBUaGVyZSBtYXkgYmUgY29tcG9uZW50cyB3aXRoaW4g dGhlIGluZnJhc3RydWN0dXJlIHRoYXQgYXJlIG9wZW4gdG8gYmVpbmcgdGhlIGRzdCBvZiBhIHBh Y2tldCB3aXRoIGEgUm91dGluZyBFSCBvciBzZXBhcmF0ZSBhZGRyZXNzZXMgb24gY29yZSBpbmZy YXN0cnVjdHVyZSB0aGF0IGFyZSBvcGVuLCBidXQgaXQgd291bGRu4oCZdCBiZSBldmVyeXRoaW5n Lg0KDQpSaWdodD8NCg0KSm9obg0KDQpPbiA1LzIvMTcsIDExOjA0IEFNLCAiaXB2NiBvbiBiZWhh bGYgb2YgVG9tIEhlcmJlcnQiIDxpcHY2LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHRv bUBoZXJiZXJ0bGFuZC5jb20+IHdyb3RlOg0KDQogICAgT24gTW9uLCBNYXkgMSwgMjAxNyBhdCA5 OjM4IFBNLCBCcmlhbiBFIENhcnBlbnRlcg0KICAgIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5j b20+IHdyb3RlOg0KICAgID4gT24gMDIvMDUvMjAxNyAxNTo1NCwgVG9tIEhlcmJlcnQgd3JvdGU6 DQogICAgPiAuLi4NCiAgICA+PiBPa2F5LCBidXQgd2hhdCB3b3VsZCB5b3UgY2FsbCBpdCB3aGVu IGFuIGludGVybWVkaWF0ZSBkcm9wcyBhIHBhY2tldA0KICAgID4+IGJlY2F1c2UgaXQgZW5jb3Vu dGVycyBhbiB1bmtub3duIGV4dGVuc2lvbiBoZWFkZXI/DQogICAgPg0KICAgID4gU2Fib3RhZ2Uu DQogICAgPg0KICAgIEhpIEJyaWFuLA0KICAgIA0KICAgIE9uZSBwZXJzb24ncyAic2Fib3RhZ2Ui IGlzIGFub3RoZXIgcGVyc29uJ3MgInZhbHVlIGFkZCIgOi0pIFJlZ2FyZGxlc3MNCiAgICBvZiB3 aGF0IGl0J3MgY2FsbGVkIGFuZCByZWdhcmRsZXNzIG9mIHdoYXQgdGhlIHNwZWNpZmljYXRpb24g c2F5cywgdGhlDQogICAgbmV0IGVmZmVjdCBpcyB0aGUgc2FtZTogaWYgaG9zdHMgY2FuJ3QgcmVs aWFibHkgc2VuZCBleHRlbnNpb24gaGVhZGVycw0KICAgIHRoZW4gdGhleSB3b24ndCBzZW5kIHRo ZW0gYXQgYWxsLiBUaGlzIGlzIGEgc3RyYWlnaHRmb3J3YXJkDQogICAgYXBwbGljYXRpb24gb2Yg dGhlIHJvYnVzdG5lc3MgcHJpbmNpcGxlLCBidXQgZWZmZWN0aXZlbHkgb2Jzb2xldGVzIHRoZQ0K ICAgIHByb3RvY29sIGZlYXR1cmUgYW5kIHRoYXQgc2hvdWxkIGJlIG5vIHN1cnByaXNlIHRvIGFu eW9uZSAoSSBoYXZlIGJlZW4NCiAgICBjYWxsaW5nIHRoaXMgcHJvdG9jb2wgb3NzaWZpY2F0aW9u LCBidXQgdGhhdCBtaWdodCBub3QgYmUgY29ycmVjdCB1c2UNCiAgICBvZiB0aGF0IHRlcm0pLg0K ICAgIA0KICAgIENvbmNlcHR1YWxseSwgaWYgbm9kZXMgZ2F2ZSBhIGNsZWFyIHJlYXNvbiBmb3Ig d2h5IHRoZXkgYXJlIGRyb3BwaW5nIGENCiAgICBob3N0J3MgcGFja2V0cyB3aXRoIEVILCB0aGVu IGl0IGlzIHBvc3NpYmxlIGZvciB0aGUgaG9zdCB0byBtb2RpZnkNCiAgICBzdWJzZXF1ZW50IHBh Y2tldHMgdG8gYmUgbW9yZSBwYWxhdGFibGUuIFdoaWxlIGl0J3MgdHJ1ZSB0aGF0IElDTVAgaXMN CiAgICBhbHNvIHVucmVsaWFibGUsIGF0IGxlYXN0IGlmIHRoZSBlcnJvciBtZXNzYWdlcyB3ZXJl IGRlZmluZWQgd2UgY291bGQNCiAgICBlc3RhYmxpc2ggdGhlIHByZXRlbnNlIHRoYXQgc291cmNl IGhvc3RzIGFuZCBuZXR3b3JrIG5vZGVzIGFyZSB3b3JraW5nDQogICAgdG9nZXRoZXIgdG8gYWNo aWV2ZSBlbmQgdG8gZW5kIGNvbm5lY3Rpdml0eS4gQUZBSUNUIHRoZSByZWFzb24gdGhhdA0KICAg IElDTVAgaXMgYmVpbmcgZHJvcHBlZCBpcyBkaWZmZXJlbnQgZnJvbSB3aHkgRUggaXMgYmVpbmcg ZHJvcHBlZDogdGhlDQogICAgSUNNUCBjYXNlIHNlZW1zIHRvIGJlIG1vcmUgb2YgYSBzZWN1cml0 eSBwb2xpY3kgZGVjaXNpb24sIHdoZXJlYXMgRUgNCiAgICBzZWVtcyB0byBiZSBtb3JlIGJlY2F1 c2Ugb2Ygb3BlcmF0aW9uYWwgY29uc3RyYWludHMgYW5kIHByb2Nlc3NpbmcNCiAgICBsaW1pdGF0 aW9ucyBvZiBkZXZpY2VzLiBJZiB0aGF0IGlzIHRoZSBjYXNlIG1heWJlIHRoZSBJQ01QIGRyb3Ag Y2FzZQ0KICAgIGlzIG1vcmUgZWFzaWx5IGFkZHJlc3NlZD8NCiAgICANCiAgICBCdHcsIHRoaXMg ZGlzY3Vzc2lvbiBpcyBub3QganVzdCBsaW1pdGVkIHRvIGludGVybWVkaWF0ZSBub2Rlcy4gQXMg SQ0KICAgIG1lbnRpb25lZCBpbiBhbm90aGVyIHRocmVhZCB3ZSBpbnRlbmQgdG8gYWRkIGNvbmZp Z3VyYWJsZSBsaW1pdHMgdG8NCiAgICB0aGUgbnVtYmVyIG9mIG9wdGlvbnMgdGhhdCBhcmUgYWNj ZXB0ZWQgYXQgYSBkZXN0aW5hdGlvbiBob3N0LiBXaGVuDQogICAgdGhlIGRlc3RpbmF0aW9uIGRy b3BzIHRoZSBwYWNrZXQgYmVjYXVzZSBvZiBzdWNoIGxpbWl0cyBpdCBpcw0KICAgIGluZGlzdGlu Z3Vpc2hhYmxlIHRvIHRoZSBzb3VyY2UgaG9zdCBmcm9tIGFuIGludGVybWVkaWF0ZSBub2RlDQog ICAgZHJvcHBpbmcgdGhlIHBhY2tldCwgc28gYW55IGF0dGVtcHRlZCBtaXRpZ2F0aW9ucyAobGlr ZSBzZW5kaW5nIGFuDQogICAgSUNNUCBlcnJvcikgc2hvdWxkIHNpbWlsYXIuDQogICAgDQogICAg SSBkb24ndCB0aGluayB0aGUgd29yZGluZyBpbiBSRkMyNDYwYmlzIG5lZWRzIHRvIGNoYW5nZSwg YnV0IG1heWJlDQogICAgc29tZSBndWlkYW5jZSBjb3VsZCBiZSBhZGRlZCB0byBub2RlIHJlcXVp cmVtZW50cy4uLg0KICAgIA0KICAgIFRvbQ0KICAgIA0KICAgIFRvbQ0KICAgIA0KICAgID4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiAgICA+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KICAg ID4gaXB2NkBpZXRmLm9yZw0KICAgID4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KICAgID4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAg ICANCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdA0KICAgIGlwdjZAaWV0Zi5vcmcNCiAgICBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQogICAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CiAgICANCiAgICANCg0K From nobody Tue May 2 10:56:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4440F1271FD for ; Tue, 2 May 2017 10:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA_Tu-ngwGTe for ; Tue, 2 May 2017 10:56:15 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2037112E04B for ; Tue, 2 May 2017 10:53:13 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id u75so123698493qka.3 for ; Tue, 02 May 2017 10:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dwmpZegexJ4GzwRocQTqP2aJ24pYWG0/9MJZY97jtd0=; b=2Hk7wgjpKOVuWH/MLPPQ4OWGIS2+7nUb0f3C1zB2dCQfLqkClAyy91fxNYJR5SLNKn 7JT0lQUWm2KjvNCuh693X3Bcr0Wxf1nQ1SLXKjOmzzMTFbe9y2q18Qmf/1LZY1FF3nbp JyWWu/s+cxd6+b/cpUCwkLbuA3w0u12WzuzI+0GWPDgUJ014/ZU0ZIiyUDnddunkcTnL yg+CUhc7G13OpBlpXVzteHOXJvzHvr3tCVAaiyLwtHPMHHezev6DQwamCDNQxSxUgSI1 +Sfd2Ro5LYZz3yp7rKw0BtkjuFebc8+qWub8GdC5E/dxiPeqURBWxvZfxkzFpCSfx+m+ OHPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dwmpZegexJ4GzwRocQTqP2aJ24pYWG0/9MJZY97jtd0=; b=HkVrxKqjjXsBXeqj5KF8JpleeAQda/tqBmBjxhjiOX6yESNk36M+YJnWG0uEz0zCgM xUtsVcsR2gx19qlbmT2GHmInXYsrjlwp83PyCRoNup0Dw6lEWutg6/7ODiBE7I7EVYe+ 9zdhacgWztgjQNCKus/x1xUTn+uT0gJti7Nz0OXo5PrBT+gr8qdBoBav6fVWvwryvYea YbA/Miyy8td3hdktOqIze3o5e8in5mNDP+AWNTs8MDaTWID/l7MbdiisWRQ1lfRx0yq9 JLzZR6+Y1WQBS/I+FIEgErIQp/Ew8ciQt3Y2/6KvSq7ad+YKe/Y3DAwFKtBbRQQvRYJE 8ZGQ== X-Gm-Message-State: AN3rC/6+BJj4vd7T0gwPTVp7IPaZOdCIkQLKoCW5uwF7ou/figJo4qG3 tfEzGk9RE9k4HIcxpSLTczsWH0wJwg== X-Received: by 10.55.140.65 with SMTP id o62mr28677004qkd.270.1493747592188; Tue, 02 May 2017 10:53:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 2 May 2017 10:53:11 -0700 (PDT) In-Reply-To: <79FBE5B6-41CB-497B-85C0-00714F2FAEAB@jisc.ac.uk> References: <2506bca8-684d-f03f-955f-7c140bc2dca1@gmail.com> <79FBE5B6-41CB-497B-85C0-00714F2FAEAB@jisc.ac.uk> From: Tom Herbert Date: Tue, 2 May 2017 10:53:11 -0700 Message-ID: Subject: Re: node requirements text [was: Proposed revised Extension Header text for rfc2460bis] To: Tim Chown Cc: Brian E Carpenter , "ipv6@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 17:56:17 -0000 On Tue, May 2, 2017 at 8:41 AM, Tim Chown wrote: > Hi, > >> On 2 May 2017, at 16:04, Tom Herbert wrote: >> >> >> >> Btw, this discussion is not just limited to intermediate nodes. As I >> mentioned in another thread we intend to add configurable limits to >> the number of options that are accepted at a destination host. When >> the destination drops the packet because of such limits it is >> indistinguishable to the source host from an intermediate node >> dropping the packet, so any attempted mitigations (like sending an >> ICMP error) should similar. >> >> I don't think the wording in RFC2460bis needs to change, but maybe >> some guidance could be added to node requirements... > > I think I saw you mention this before, and it sounds reasonable. Feel fre= e to propose text for 6434-bis =E2=80=A6 > It was Bob Hinden's suggestion to consider modifying node requirements for host side processing of EH. I will propose some text. Tom > Tim From nobody Wed May 3 11:26:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA52129ACD for ; Wed, 3 May 2017 11:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 Vh4Teg2ODC-9 for ; Wed, 3 May 2017 11:26:07 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9501129B70 for <6man@ietf.org>; Wed, 3 May 2017 11:23:47 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 4F36D75E31 for <6man@ietf.org>; Wed, 3 May 2017 14:23:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=VIt hIAxi5+6/rZZkYcbQUEqy23w=; b=uQYVZjlMgi/d4fqwJ/7U38AmyevFLd3SbXn oi4ppU1ZAGaMaQw1v6c30+NChaJMZq+BTqVmKM61WnefSYI8Nn2phijJehyXfDRf vT6Jyw45m50YBHnXC3nPGJOtUCB46tb+cd5BZW5vel958gOiHdY6kvfTX2rwkJYD HSpT3q/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= Jk9h/I5/g7KCor/bBOwW9oH0z/H13XHsRSnr6LFiFxKcM99YvaJEVIwyg0qlL1LG 3JKPt+5k50D7mF/nr3k0cFkNjbX1/Y3VW6B8lOFxpj37A855t38hGB6wPPLtIt0n mbDZI3CEIX/YLA8Z3lyhVzbgu0pjJ7cUshTsKuQOE/g= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 3C03275E2E for <6man@ietf.org>; Wed, 3 May 2017 14:23:46 -0400 (EDT) Received: from mail-qt0-f179.google.com (unknown [209.85.216.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id B3DD575E29 for <6man@ietf.org>; Wed, 3 May 2017 14:23:45 -0400 (EDT) Received: by mail-qt0-f179.google.com with SMTP id m91so11869161qte.3 for <6man@ietf.org>; Wed, 03 May 2017 11:23:45 -0700 (PDT) X-Gm-Message-State: AN3rC/5LETX4uetA1um09Bs4FP88EztUHC6H+3Psl235I+wHQutAvIQq m+OcoaYTh0Zq2IzZ0yYnvORTiztZxg== X-Received: by 10.200.47.91 with SMTP id k27mr31859943qta.11.1493835825098; Wed, 03 May 2017 11:23:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Wed, 3 May 2017 11:23:24 -0700 (PDT) From: "C. M. Heard" Date: Wed, 3 May 2017 11:23:24 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Questions / comments regarding draft-voyer-6man-extension-header-insertion (was: Proposed revised Extension Header text for rfc2460bis) To: Robert Raszuk , "Voyer, Daniel" Cc: 6MAN <6man@ietf.org> Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: A4F8ADAA-302D-11E7-B366-C260AE2156B6-06080547!pb-smtp2.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:26:10 -0000 Gentlemen, Following the cue from our AD, I want to pose some questions and comments regarding draft-voyer-6man-extension-header-insertion that were prompted by some comments in an earlier post, in the hope doing so will help advance a constructive discussion on an eventual update for 2460bis that suits the needs of the segment routing community. On Mon, 1 May 2017 03:17:16 -0400 Robert Raszuk wrote: > If you would follow SR-MPLS you would realize that MPLS label carries an > embedded function. Exactly like SID in SRH. Two points that had escaped me, and possibly others participating in this discussion, are that: - An SRv6 Segment ID (SID) is an IPv6 address assigned to a node, not necessarily one associated with one of its physical interfaces, that identifies an SRV6 segment. - When a packet whose Destination Address (DA) is an SRv6 SID arrives at the node that "owns" that address, it triggers special processing (the "embedded function" that you mention above). That would include forwarding instructions and possibly instructions on how to modify an existing segment routing header in case of fast reroute. That much is now clear to me, but only after looking at https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#section-2.2 https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-3.1.3 Listing these in draft-voyer-6man-extension-header-insertion as required prerequisite reading would, I think, be helpful to the target audience -- which consists primarily of folks from outside the segment routing community. It is less clear to me under what circumstances one would wish to insert a segment routing header at a transit node (aka intermediate node -- i.e., a node other than the one specified in the DA of the packet in question) when one did not previously exist. Thus, as a clarification to draft-voyer-6man-extension-header-insertion: - In Section 2, please specify in the following step o Node 1 originates a packet P1 destined to 9 (SA=1, DA=9). whether or not the packet has a segment routing header; if so, specify the path (which would presumably include node 2); if not, explain how the packet is to be routed, and explain how node 2 decides to insert a segment routing header. - In Section 3, provide the same clarification if not already covered by the change to Section 2. > Moreover with the overhead of signaling required to established an LSP in > MPLS case transit nodes no matter if they are within domain or beyond domain > DO NOT NEED to change any single bit in their current forwarding paradigm. > SR functions are executed only at the designated nodes which are able to > perform the desired forwarding behaviour. If this is also true for the IPv6 data plane, I would not expect a transit node to need to insert a segment routing header, irrespective of whether it is part of the SR domain or not. If this is totally off base, it would be good for draft-voyer-6man-extension-header-insertion to explain why. > This entire discussion that maybe we will bless SRv6 in closed domains just > does not get the fundamental point that transit nodes regardless on how many > SRH are in the IPv6 packet will work just fine. Of course there is MTU > concern ... but this concern is also with MPLS stacking or for that matter > with any encapsulation. And we do know today how to effectively solve it > when/where needed. I totally get that transit nodes (i.e., nodes that are not specified by the DA of the packet during any hop) should not need to change their behavior and all and should work just fine irrespective of whether the segment routing header is present or not. That is what 2460 and the current incarnation of 2460bis mandate. [That is also widely violated -- packets with unknown extension headers are often dropped in practice -- but the hope is that in time adoption of RFC 7045 will help the situation.] But as part of dealing with the MTU problem, one of the prerequisites for correct operation is that the DA of packet that contains a segment routing header MUST point to a node that is able to correctly deal with Packet Too Big ICMPv6 messages. Actually, that is true for any ICMP error message related to the SRH. That is a manageable problem if SRH is added only by the originating node or after encapsulation by a border router, but it is less clear how it is managed of SRH is inserted in flight. So: - Add text to draft-voyer-6man-extension-header-insertion explaining how it is ensured that ICMP messages for a packet containing a segment routing header get back to a node that understands what they mean. If SRH can be inserted (as opposed to modified) by an intermediate note, that is a non-trivial matter > It get's even worse if you (like some of this WG members) now require to > encapsulate packets in additional v6 header before SRH is inserted - makes > zero sense ! Just please kindly observe that if you do the encap the dst > address can be anywhere in the Internet .. no encap code mandates that dst > must be in your IGP. So packets do escape ASes .. BGP in fact was explicitly > created to help/assist them to escape. I think there is a problem here by imprecise use of language. The quoted text a couple of paragraphs above says "regardless on how many SRH are in the IPv6 packet." However, according to https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#section-3.2 the SRH should appear at most once in a packet. Now, the MPLS example in https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-00#section-2.1 discusses adding labels, which would be analogous to adding individual segments to the segment list in the SRH, not to adding another SRH. Is that what is actually being discussed? Based on the existing documentation, I get why there is a desire to modify the segment list of an SRH without adding another layer of encapsulation. Doing so would violate the expectation in RFC 4302 (AH) that the network will not change the length of an extension header, meaning that SRH could not be used in conjunction with AH. That is something else that draft-voyer-6man-extension-header-insertion should mention. What I don't get is why there is a desire for a node to insert an SRH without encapsulation when none was there to begin with. If that is really desired, draft-voyer-6man-extension-header-insertion needs to explain why. > I think perhaps a dedicated interim meeting should be setup just to discuss > it and understand it well before we proceed with any further spec > clarifications or extensions. Sure. But that should not stop 2460bis. It's supposed to be IS. Any new extension to support the SR community's requirements would come in at PS. An enhanced version of draft-voyer-6man-extension-header-insertion will help move that process forward. Thanks & regards, Mike Heard From nobody Wed May 3 17:19:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689931293E4 for ; Wed, 3 May 2017 17:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.303 X-Spam-Level: X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 5Ju_Ja0kZsG9 for ; Wed, 3 May 2017 17:19:00 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC2A1293E1 for <6man@ietf.org>; Wed, 3 May 2017 17:19:00 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 3E48575F1C for <6man@ietf.org>; Wed, 3 May 2017 20:18:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=kLHbFvbHVy/ZMoTuIh3iXrtucYs=; b=pNPL91 ZlACuGqqRB/Sf+7x7UnRHr/bHHdTkH16kRdlkmm2ZM3Y5e/BcjjLvTMcAifnCPH6 EhpGebXUsebojdMcHSQeBK4EDNQP9GjZnNFCiNGk7W/xUeUAoOqNoYy08n3MK9IR Wf67HUsh6DP77pNIIq2h+rugKTQ2gurw6AAbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=Z52L6cqbLc8GpNiXC8BFmqF4XxUjc8xH Efr6E+L4A42AY6G0joUPbyLP/7Qi5+AcLCLA6UWI8Y8T9RNd0/q9g4v2q1oOG1pD eEFJEZx+qDiX7ivrv65o/EChdYdcd6WCEY1r/e2L/BjX/PvcJw2zruQR+Is1YAHU xjusSI6iWtU= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 3631375F1B for <6man@ietf.org>; Wed, 3 May 2017 20:18:58 -0400 (EDT) Received: from mail-qt0-f169.google.com (unknown [209.85.216.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id C178D75F1A for <6man@ietf.org>; Wed, 3 May 2017 20:18:57 -0400 (EDT) Received: by mail-qt0-f169.google.com with SMTP id n4so4314193qte.2 for <6man@ietf.org>; Wed, 03 May 2017 17:18:57 -0700 (PDT) X-Gm-Message-State: AN3rC/5k2yCxGpn4abHHi+jgb3ZILLdwP8CSjHEH4a6vg+oGNx/Icujh d6AevVQMDq6em30Dv+zWOMBBAJKfXQ== X-Received: by 10.200.47.91 with SMTP id k27mr33110953qta.11.1493857137399; Wed, 03 May 2017 17:18:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Wed, 3 May 2017 17:18:37 -0700 (PDT) In-Reply-To: References: From: "C. M. Heard" Date: Wed, 3 May 2017 17:18:37 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Questions / comments regarding draft-voyer-6man-extension-header-insertion (was: Proposed revised Extension Header text for rfc2460bis) To: Robert Raszuk , "Voyer, Daniel" Cc: 6MAN <6man@ietf.org> Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: 43F23A94-305F-11E7-BF6F-E680B56B9B0B-06080547!pb-smtp1.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 00:19:01 -0000 I see an embarrassing typo in my previous message. On Wed, May 3, 2017 at 11:23 AM, C. M. Heard wrote: > But as part of dealing with the MTU problem, one of the prerequisites for > correct operation is that the DA of packet that contains a segment routing > header MUST point to a node that is able to correctly deal with Packet Too > Big ICMPv6 messages. Actually, that is true for any ICMP error message > related to the SRH. That is a manageable problem if SRH is added only by > the originating node or after encapsulation by a border router, but it is > less clear how it is managed of SRH is inserted in flight. So: The above should say SA (source address) where it says DA. Sorry about that. //cmh From nobody Fri May 5 01:31:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED83129401; Fri, 5 May 2017 01:31:17 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 neTnMR-Qh75F; Fri, 5 May 2017 01:31:15 -0700 (PDT) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 6E1D0129447; Fri, 5 May 2017 01:31:14 -0700 (PDT) Received: by mail-wr0-x242.google.com with SMTP id g12so3651196wrg.2; Fri, 05 May 2017 01:31:14 -0700 (PDT) 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=ELmhcFUdD2F50vBVI4sLPKUyBZF1rumlccSeD9oTOgE=; b=sRYoO+wqfFcFuaCtdTRL6AUZ81X6uFSnyJDTfyRXDRhFvZz0lyeMuCeM28gf/d1onp fo10qARwXCDhcJAZBcT8Yt4gl7cGIpxXpuLAevt0jWqbFqOuasehUBNYFaLq8N0MSXh7 o7owxd5tY1Lj0HAwi31v04ZPBh5jM3jnuin3XqBnukEm6q27+9BFK36/mZ6sOxLCzKia g05wsgYO4A7X0n3BVjjY1SA8LZKbmPVIqw1AaAUYlfxOxZKGrxnwNRQIXG5wjxbOZpVP gj5Ui5aZP1GUynjrzaKPe0Z7IWoMTUCYMQ59FIvuQlvBlzgXWizFbPzIdU4PDJRqN8hJ q2MQ== 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=ELmhcFUdD2F50vBVI4sLPKUyBZF1rumlccSeD9oTOgE=; b=MIDRh5gY5e21tZvLYgStedD8Rskgd6EDgmxoYQ/8nerbdYa3bEGzcl5cmZTg1b+Dz4 rrw0LsGRWkHJrKqgUHgv+i/fI5IRZZ44htmaCkNHzS6DrLXkqmh4LQrQpyn/pJqT1xsL z61wyKUefRuTRwoowvR5wVjWEVTitUrKJiJdAaDOVJ/E9xvoZnBcmbJJ7BXPlngTpU9k I/n1L2SNEg/gA2QJRVvry6YVHD/qKnEyDxj5S60UA+44aGvGgytCHwaenC7C387149pv P5st3aFGAOPs3NHnds+hR20aZyB7i6OOdGUD84tyFUiKVWYku+yUR2gKrBF4Qs2S1p4g NmtA== X-Gm-Message-State: AN3rC/6+0mU2vp+A9gUPRaaXGzps9LuMCc3PP+gVDfxgT+fAogpdGwsP 5UiBna0JCqmVlw== X-Received: by 10.223.136.131 with SMTP id f3mr32540527wrf.70.1493973072988; Fri, 05 May 2017 01:31:12 -0700 (PDT) Received: from [192.168.1.33] ([77.125.68.206]) by smtp.gmail.com with ESMTPSA id t124sm1165589wma.10.2017.05.05.01.31.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 01:31:11 -0700 (PDT) From: Bob Hinden Message-Id: <7CFCE1D1-CBBA-4B1A-AC4D-587D1ED8464B@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_6E34E0DB-172F-4225-8403-B5869E2075C8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Rtgdir last call review of draft-ietf-6man-rfc1981bis-06 Date: Fri, 5 May 2017 11:31:08 +0300 In-Reply-To: <149283456181.25913.15133934620501134310@ietfa.amsl.com> Cc: Bob Hinden , rtg-dir@ietf.org, IPv6 List , IETF , draft-ietf-6man-rfc1981bis.all@ietf.org To: Ines Robles References: <149283456181.25913.15133934620501134310@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 08:31:17 -0000 --Apple-Mail=_6E34E0DB-172F-4225-8403-B5869E2075C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ines, Thanks for the review. Comments below. Bob > On Apr 22, 2017, at 7:16 AM, Ines Robles = wrote: >=20 > Reviewer: Ines Robles > Review result: Has Nits >=20 > Document: draft-ietf-6man-rfc1981bis-06.txt >=20 > Reviewer: Ines Robles >=20 > Review Date: April 21, 2017 >=20 > Intended status: Standards Track >=20 >=20 > Summary: >=20 > This document describes Path MTU Discovery for IP version 6 >=20 > I believe the draft is technically good. I have no =E2=80=9CMajor=E2=80=9D= issues > with this I-D. I have some minor comments. >=20 Good, thanks. >=20 > Comments: >=20 > 1- I think that it would be nice to add a graphical example that > describes the process of the Path MTU Discovery (including a Packet > Too Big Message). e.g. Figure 1 of RFC 5927[1]. I will consider it, but sure what it would look like. Suggestions? >=20 > 2- Section 1: >=20 > 2.1- I would add a reference when you mention black hole = connection. > What about section 2.1 of [2] or [3]? >=20 I will add RFC2923. The other is an expired draft that I don=E2=80=99t = think it appropriate to reference. > 3- Section 2: >=20 > 3.1- EMTU_S =3D> When it is defined, it references RFC6691. But = this > term is not mentioned in RFC6691. I would add additionally a reference > to RFC 1122 [4] which defines EMTU_S. >=20 OK > 3.2- I would add also the same references for EMTU_R. OK >=20 > 4.Section 3: >=20 > 4.1- In the first paragraph, I would add a reference to ICMPv6 = the > first time that ICMPv6 Packet Too Big message is mentioned. And I > would add here also "(ICMPv6 PTB)" since it used further in the > document. There is a reference to ICMPv6 the first time it shows up in Section 1. = I don=E2=80=99t think another is needed for ICMPv6 PTB. >=20 > 4.2- In the first paragraph: "...to send smaller fragments or = ..." > --> I think it would be clearer "to send smaller packets or=E2=80=A6" I agree, =E2=80=9Cpackets=E2=80=9D is better here. It=E2=80=99s = consistent with the definition in Section 2. >=20 > 4.3- Second Paragraph: "...process ends when the node's = estimate..." > -> "...process ends when the source node's estimate=E2=80=A6"? OK >=20 > 4.4- Last Paragraph: "can to appear" -> "can appear" . "...but = is in > fact..." -> "...but it is in fact=E2=80=A6" OK >=20 > 5. Section 4: >=20 > 4.1- about this: "The node MUST reduce the size of the packets = it is > sending along the path". I would add an explanation to which size the > packet should be reduced (maybe based in an initial example) This is described in the previous paragraph. >=20 >=20 > 6.Section 5: >=20 > 6.1- I would add a reference to RFC 1122 [4] when MMS_S is = mentioned. OK >=20 >=20 > 6.2- Section 5.5: "Some transport protocols are not allowed to > repacketize when doing a retransmission..." I would add some > examples. I will look into that. >=20 > 7. Section 6: >=20 > 7.1- What about to mention Blind Performance-Degrading Attack = [5]? This is protected against by not allow the MTU to be set below 1280 and = changes in rfc2460bis fragmentation. >=20 >=20 >>=20 > [1] https://tools.ietf.org/html/rfc5927#section-7.3 > [2] https://tools.ietf.org/html/rfc2923 > [3] = https://tools.ietf.org/html/draft-jacquin-opsawg-icmp-blackhole-problem-00= > [4] https://tools.ietf.org/html/rfc1122#page-58 > [5] https://tools.ietf.org/html/rfc5927#section-7 --Apple-Mail=_6E34E0DB-172F-4225-8403-B5869E2075C8 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 iQEcBAEBCgAGBQJZDDhMAAoJEK7rdBF357uotFEH/iBvAO+rLMUDG2lue9f3YbcK eAIte8Hc7uQJaUlkvJtAP5AAIeyOKeEW/h4CiaGyUKGKGEHRM1MLL0HJUIM/lUkX hPCnM0w/FfeMr40CLly7EQvYXf0W8ScyadcEddN5ItyLKAOz6uBBk3q233NhDrtq wHLaXABYkbT9N+2OVWcB0Ob7R1S7colsaoXqBlmW/cDdxfwRHhQyXzdTMUV1Ys9a iYeiM7ArDR5UWH01oPFH1g8XRpnY9FqtpHbCKPZ/YBOdE44hxLdUwLwK3bfA8C/t WsKQjDfMUDi3B2xB/AJEa3rpL+01SHcZWJdQ69JWnPl9bGyFr+KEoL4sJ2YdpoQ= =5dpn -----END PGP SIGNATURE----- --Apple-Mail=_6E34E0DB-172F-4225-8403-B5869E2075C8-- From nobody Fri May 5 05:32:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC93129454; Fri, 5 May 2017 05:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH6gYUAgyIhK; Fri, 5 May 2017 05:32:19 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 006B812922E; Fri, 5 May 2017 05:32:18 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id z129so1075120wmb.1; Fri, 05 May 2017 05:32:18 -0700 (PDT) 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=DUcxZ758Lle09aFYrVG/RGBN4K9Di+SbyXtKju4ibik=; b=SIX1y/ELMSz8pKYRoyxLSE7ETZmEKQQfVlL0MIo3Oa8j0Zb5sg7VUibYQpKFb/6PPK 2W5WHOv3hyNRK13AvOayjMYccysGyRk96h4wv9vbgGGGmCgT3uFwgOGhaknLHIyI5hUE cDtCft8HkagkG8puqFv2PoRc/Wvcd0b+3goTLHjvY3IG9ZGjEMVuQrui+3ACJhkHJcca r0t1iJYSEi+zO793YDo2R9SGrdLZp7LpjzlHdBeyQ5Mko7dZGXn9JMAh5z3p21oxi8DZ gFkK0SYrhbSWmb3tN3fSaWEOI+Ga1JbO0FTPp7PF9utDVG/xA5iE6GK7ge4jRB4RkN6T 1IYA== 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=DUcxZ758Lle09aFYrVG/RGBN4K9Di+SbyXtKju4ibik=; b=al/w6winfUI8SRfVrtcLcOfcgLCSLnA4Ou8LXUoThTKuYzhPQfAuO9dqOqbMAnN+Nm lGqcDgaKhCbzVDV+FrglHyk2TL+vy0SXaa/M1JYtt8Yu+DG7I1aS/F6SheJ6EVql0H5a 5/ZicWjgF5TJdVIJNs9vO8cgTiBxI/SRm/vPFTN5HF1WisybSs8D9mxSG0VJYKgN2GuT T6LY1URrFGLBG/8ErOKeCifDmsbYmBW2Hx+bTy8W1l1vA+6IfIh5a+rUUSgrrDte/svg 0rYYSbgS3wUV2uRfBEqT/GrlSPNuf9KP2w14M2k3W4nlDiyjK/WsGJIRMaU3eh3sbZ0h JIxQ== X-Gm-Message-State: AODbwcC6Z07/pAHAMG9qlOdAlU3uoM4viJGW93cSHkUYXYgVyP9bVPK5 9WXpg5BO+Mf4ShWxR5c= X-Received: by 10.28.212.148 with SMTP id l142mr4872267wmg.37.1493987537525; Fri, 05 May 2017 05:32:17 -0700 (PDT) Received: from [192.168.1.33] (IGLD-84-229-142-252.inter.net.il. [84.229.142.252]) by smtp.gmail.com with ESMTPSA id g21sm6065377wrg.22.2017.05.05.05.32.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 05:32:16 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_51C3213C-2FC5-4844-8F7A-2082C4423B43"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Genart telechat review of draft-ietf-6man-rfc1981bis-06 Date: Fri, 5 May 2017 15:32:12 +0300 In-Reply-To: <497d3868-406a-a38f-56d8-391b0fc16032@isi.edu> Cc: Bob Hinden , Stewart Bryant , gen-art@ietf.org, IPv6 List , IETF , draft-ietf-6man-rfc1981bis.all@ietf.org To: Joe Touch References: <149305392811.25808.15115824976388262628@ietfa.amsl.com> <497d3868-406a-a38f-56d8-391b0fc16032@isi.edu> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 12:32:21 -0000 --Apple-Mail=_51C3213C-2FC5-4844-8F7A-2082C4423B43 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Apr 25, 2017, at 9:26 PM, Joe Touch wrote: > > Hi, Stewart, > > > On 4/24/2017 10:12 AM, Stewart Bryant wrote: >> Minor issues: >> >> A node MUST NOT reduce its estimate of the Path MTU below the IPv6 >> minimum link MTU. >> >> SB> I missed this last time. >> SB> >> SB> Presumably you mean "A node MUST NOT reduce its estimate of the >> SB> Path MTU below the IPv6 minimum link MTU in response to such >> SB> a message." > This seems fine to me, FWIW - i.e., limiting the advice in this doc to > the mechanism in this doc. I will add something, but this sentence follows: If a node receives a Packet Too Big message reporting a next-hop MTU that is less than the IPv6 minimum link MTU, it MUST discard it. so I think the context was clear. Bob > >> SB> >> SB> Otherwise I would have thought that this was entirely a matter >> SB> for the host whether it wanted to use a Path MTU below the IPv6 >> SB> link minimum. Nothing breaks if the host takes a more conservative >> SB> decision. > I don't agree; the host at that point is violating RFC2460. It should > never think that an IPv6 link or path with an MTU below what RFC2460 > requires is valid. > > Joe > --Apple-Mail=_51C3213C-2FC5-4844-8F7A-2082C4423B43 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 iQEcBAEBCgAGBQJZDHDNAAoJEK7rdBF357uoSFQIALuKblyJvhz/ED6AfV0n4bKC 2ZPGlJFe43EqasJ9JEqIJ05AvO41lUm2o4o71RpHA3yagmA2/mNp15wCFSYcmgnM nHqfidzs/4Vjri+JhQchC7cjYcyvnDsEr0xMhH8ndHIuvK/0jlAnf0L8ZxdI1RV1 kICkeLmHYf7eK6Nz61dSMmAog8ExNVhJIKr8gE6N5iqbeErKl+cbRqXMYAZR8yd7 5V2uafBP4KcoliljcapnB33ty6EKwl7vOU2I+2k2J6SbKhJjnFgwC2BCRUw/kfw1 RVVvjNUbsCdgPeJKBvU3/H/qJiWMW9g2mC3JKgNIRvUbUBp6gNKrsIGTZHwDnXo= =636B -----END PGP SIGNATURE----- --Apple-Mail=_51C3213C-2FC5-4844-8F7A-2082C4423B43-- From nobody Fri May 5 10:05:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2C0127863; Fri, 5 May 2017 10:05:19 -0700 (PDT) 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_50=0.8, 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 cI4r5TOTOwqP; Fri, 5 May 2017 10:05:18 -0700 (PDT) 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 C96AD124D37; Fri, 5 May 2017 10:05:18 -0700 (PDT) Received: from [128.9.184.57] ([128.9.184.57]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v45H4iNZ008671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 May 2017 10:04:45 -0700 (PDT) Subject: Re: Genart telechat review of draft-ietf-6man-rfc1981bis-06 To: Bob Hinden Cc: Stewart Bryant , gen-art@ietf.org, IPv6 List , IETF , draft-ietf-6man-rfc1981bis.all@ietf.org References: <149305392811.25808.15115824976388262628@ietfa.amsl.com> <497d3868-406a-a38f-56d8-391b0fc16032@isi.edu> From: Joe Touch Message-ID: Date: Fri, 5 May 2017 10:04:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 17:05:20 -0000 Hi, Bob, AOK. Thanks, Joe On 5/5/2017 5:32 AM, Bob Hinden wrote: >> On Apr 25, 2017, at 9:26 PM, Joe Touch wrote: >> >> Hi, Stewart, >> >> >> On 4/24/2017 10:12 AM, Stewart Bryant wrote: >>> Minor issues: >>> >>> A node MUST NOT reduce its estimate of the Path MTU below the IPv6 >>> minimum link MTU. >>> >>> SB> I missed this last time. >>> SB> >>> SB> Presumably you mean "A node MUST NOT reduce its estimate of the >>> SB> Path MTU below the IPv6 minimum link MTU in response to such >>> SB> a message." >> This seems fine to me, FWIW - i.e., limiting the advice in this doc to >> the mechanism in this doc. > I will add something, but this sentence follows: > > If a node receives a Packet Too Big message reporting a next-hop > MTU that is less than the IPv6 minimum link MTU, it MUST discard it. > > so I think the context was clear. > > Bob > > >>> SB> >>> SB> Otherwise I would have thought that this was entirely a matter >>> SB> for the host whether it wanted to use a Path MTU below the IPv6 >>> SB> link minimum. Nothing breaks if the host takes a more conservative >>> SB> decision. >> I don't agree; the host at that point is violating RFC2460. It should >> never think that an IPv6 link or path with an MTU below what RFC2460 >> requires is valid. >> >> Joe >> From nobody Fri May 5 14:21:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC48C1271FD for ; Fri, 5 May 2017 14:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 CBFAdhr_rJQh for ; Fri, 5 May 2017 14:21:45 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.166]) (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 0C9EE126BF0 for <6man@ietf.org>; Fri, 5 May 2017 14:21:44 -0700 (PDT) Received: from [85.158.137.67] by server-6.bemta-3.messagelabs.com id 71/E0-02189-64BEC095; Fri, 05 May 2017 21:14:46 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnk+JIrShJLcpLzFFi42I5t4YxWdftNU+ kwaapshYrV9xlsrixZw6LRdPCJmYHZo8lS34yeVy8pOyxe+MCpgDmKNbMvKT8igTWjG8rnrMW tGZVzNhs08B4JaOLkZNDQsBP4u+qZ2xdjFwcQgL7GCXOnb3ADuFcZ5T4POkQM4RzilHi4ssJQ GUcHGwCOhJzXsiDdIsIuEnc7d7ECmIzC0hI7Hl1kgWkXlhgGqPEmaPTwMaKCExnlFi5cA0zRI eRxPYtm8FsFgEVieaJFxlBbF4BK4l/85cwgdhCAgES//9sBItzCgRKLPiyH6yeUUBM4vupNUw Q28Qlbj2ZzwTxg4DEkj3nmSFsUYmXj/+BXSQqoCdx7cNKFoi4jsTZ608YIWwDia1L97GAPCMh oCBx7UYkiMksoCmxfpc+hGkv8eqzCsQiRYkp3Q/ZIY4UlDg58wnUQEmJgytusEAcrCgx79ZbF khQzWeU2Db5FDtEkb3Ew8tfmSYwys1CcvQshG2zELbNQrJtFpJtCxhZVzFqFKcWlaUW6Rqa6y UVZaZnlOQmZuboGhoY6+WmFhcnpqfmJCYV6yXn525iBCYQBiDYwfjytOchRkkOJiVR3jRRnkg hvqT8lMqMxOKM+KLSnNTiQ4wyHBxKEryMr4BygkWp6akVaZk5wFQGk5bg4FES4fV9AZTmLS5I zC3OTIdInWJUlBLn9QTpEwBJZJTmwbXB0uclRlkpYV5GoEOEeApSi3IzS1DlXzGKczAqCfNyg kzhycwrgZv+CmgxE9DiaFGwxSWJCCmpBsbls3qzRCO0L2sIqwrMjjiiyad8aMNfiVtLpx3WE3 xy2dG0WWdt+kx/3sUf10+rn1V68INbfuH2h7djsjtdXj34pqFmKqxze88GCamTkSsKlVaKh3R kvM3h75umtTN+/vdzFzsWHIz9xWE8Ve7G8gP21jqX5rJt0rBZH8M7kcnnoUaqZcmTtgIlluKM REMt5qLiRABACcpVmgMAAA== X-Env-Sender: daniel.voyer@bell.ca X-Msg-Ref: server-3.tower-139.messagelabs.com!1494018882!58769891!7 X-Originating-IP: [206.172.1.99] X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1589 invoked from network); 5 May 2017 21:14:46 -0000 Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (206.172.1.99) by server-3.tower-139.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 5 May 2017 21:14:46 -0000 X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE02-DOR.bell.corp.bce.ca Received: from DG2MBX04-WYN.bell.corp.bce.ca (198.235.121.232) by EX13EDGE02-DOR.bell.corp.bce.ca (198.235.121.55) with Microsoft SMTP Server id 15.0.1210.3; Fri, 5 May 2017 17:14:22 -0400 Received: from DG2MBX03-WYN.bell.corp.bce.ca (2002:8eb6:1215::8eb6:1215) by DG2MBX04-WYN.bell.corp.bce.ca (2002:8eb6:1216::8eb6:1216) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 5 May 2017 17:14:33 -0400 Received: from DG2MBX03-WYN.bell.corp.bce.ca ([fe80::6475:3594:7cbe:fc39]) by DG2MBX03-WYN.bell.corp.bce.ca ([fe80::6475:3594:7cbe:fc39%23]) with mapi id 15.00.1210.000; Fri, 5 May 2017 17:14:33 -0400 From: "Voyer, Daniel" To: "C. M. Heard" , Robert Raszuk CC: 6MAN <6man@ietf.org> Subject: Re: Questions / comments regarding draft-voyer-6man-extension-header-insertion (was: Proposed revised Extension Header text for rfc2460bis) Thread-Topic: Questions / comments regarding draft-voyer-6man-extension-header-insertion (was: Proposed revised Extension Header text for rfc2460bis) Thread-Index: AQHSxDpq1ySbmopjTE6EF3jKxAqqj6HmQLeA Date: Fri, 5 May 2017 21:14:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.24.25.28] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Received-SPF: SoftFail (EX13EDGE02-DOR.bell.corp.bce.ca: domain of transitioning daniel.voyer@bell.ca discourages use of 198.235.121.232 as permitted sender) X-OrganizationHeadersPreserved: EX13EDGE02-DOR.bell.corp.bce.ca Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 21:21:48 -0000 SGVsbG8gTWlrZSwNCg0KU2VlIGlubGluZS4NCg0KT24gMjAxNy0wNS0wMywgMjoyMyBQTSwgIkMu IE0uIEhlYXJkIiA8aGVhcmRAcG9ib3guY29tPiB3cm90ZToNCg0KICAgIEdlbnRsZW1lbiwNCiAg ICANCiAgICBGb2xsb3dpbmcgdGhlIGN1ZSBmcm9tIG91ciBBRCwgSSB3YW50IHRvIHBvc2Ugc29t ZSBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzDQogICAgcmVnYXJkaW5nIGRyYWZ0LXZveWVyLTZtYW4t ZXh0ZW5zaW9uLWhlYWRlci1pbnNlcnRpb24gdGhhdCB3ZXJlIHByb21wdGVkDQogICAgYnkgc29t ZSBjb21tZW50cyBpbiBhbiBlYXJsaWVyIHBvc3QsIGluIHRoZSBob3BlIGRvaW5nIHNvIHdpbGwg aGVscCBhZHZhbmNlDQogICAgYSBjb25zdHJ1Y3RpdmUgZGlzY3Vzc2lvbiBvbiBhbiBldmVudHVh bCB1cGRhdGUgZm9yIDI0NjBiaXMgdGhhdCBzdWl0cyB0aGUNCiAgICBuZWVkcyBvZiB0aGUgc2Vn bWVudCByb3V0aW5nIGNvbW11bml0eS4NCiAgICANCiAgICBPbiBNb24sIDEgTWF5IDIwMTcgMDM6 MTc6MTYgLTA0MDAgUm9iZXJ0IFJhc3p1ayB3cm90ZToNCiAgICA+IElmIHlvdSB3b3VsZCBmb2xs b3cgU1ItTVBMUyB5b3Ugd291bGQgcmVhbGl6ZSB0aGF0IE1QTFMgbGFiZWwgY2FycmllcyBhbg0K ICAgID4gZW1iZWRkZWQgZnVuY3Rpb24uIEV4YWN0bHkgbGlrZSBTSUQgaW4gU1JILg0KICAgIA0K ICAgIFR3byBwb2ludHMgdGhhdCBoYWQgZXNjYXBlZCBtZSwgYW5kIHBvc3NpYmx5IG90aGVycyBw YXJ0aWNpcGF0aW5nIGluIHRoaXMNCiAgICBkaXNjdXNzaW9uLCBhcmUgdGhhdDoNCiAgICANCiAg ICAtIEFuIFNSdjYgU2VnbWVudCBJRCAoU0lEKSBpcyBhbiBJUHY2IGFkZHJlc3MgYXNzaWduZWQg dG8gYSBub2RlLCBub3QNCiAgICBuZWNlc3NhcmlseSBvbmUgYXNzb2NpYXRlZCB3aXRoIG9uZSBv ZiBpdHMgcGh5c2ljYWwgaW50ZXJmYWNlcywgdGhhdA0KICAgIGlkZW50aWZpZXMgYW4gU1JWNiBz ZWdtZW50Lg0KIA0KQ29ycmVjdC4NCiAgIA0KICAgIC0gV2hlbiBhIHBhY2tldCB3aG9zZSBEZXN0 aW5hdGlvbiBBZGRyZXNzIChEQSkgaXMgYW4gU1J2NiBTSUQgYXJyaXZlcyBhdA0KICAgIHRoZSBu b2RlIHRoYXQgIm93bnMiIHRoYXQgYWRkcmVzcywgaXQgdHJpZ2dlcnMgc3BlY2lhbCBwcm9jZXNz aW5nICh0aGUNCiAgICAiZW1iZWRkZWQgZnVuY3Rpb24iIHRoYXQgeW91IG1lbnRpb24gYWJvdmUp LiBUaGF0IHdvdWxkIGluY2x1ZGUgZm9yd2FyZGluZw0KICAgIGluc3RydWN0aW9ucyBhbmQgcG9z c2libHkgaW5zdHJ1Y3Rpb25zIG9uIGhvdyB0byBtb2RpZnkgYW4gZXhpc3Rpbmcgc2VnbWVudA0K ICAgIHJvdXRpbmcgaGVhZGVyIGluIGNhc2Ugb2YgZmFzdCByZXJvdXRlLg0KIA0KQ29ycmVjdC4N CiAgIA0KICAgIFRoYXQgbXVjaCBpcyBub3cgY2xlYXIgdG8gbWUsIGJ1dCBvbmx5IGFmdGVyIGxv b2tpbmcgYXQNCiAgICANCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXItMDYjc2VjdGlvbi0yLjINCiAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLTEx I3NlY3Rpb24tMy4xLjMNCg0KQWdyZWUgYW5kIHdpbGwgYWRkIHRleHQgYW5kIHJlZmVyZW5jZXMu DQoNCk5vdGUgdGhhdCBkcmFmdC12b3llci02bWFuLWV4dGVuc2lvbi1oZWFkZXItaW5zZXJ0aW9u IGhhcyBiZWVuIHdyaXR0ZW4gd2l0aCB0aGUgcHVycG9zZSB0byBpbGx1c3RyYXRlIF9vbmVfIGV2 aWRlbnQgdXNlLWNhc2Ugd2hlcmUgaGVhZGVyIGluc2VydGlvbiBpcyB1c2VmdWwsIG5vdCBoYXJt ZnVsIGFuZCB2ZXJ5IGJlbmVmaWNpYWwuIFRoZSBpbnRlbnQgb2YgdGhlIGRyYWZ0IGlzIG5vdCB0 byBjb21lIHdpdGggYSBjb21wbGV0ZSBzZXQgb2Ygc29sdXRpb25zIG9uIGhvdyB5b3UgY2FuIGlu c2VydCBhbmQgdXBkYXRlIGEgc291cmNlIHJvdXRlIHBhdGggZm9yIGEgZ2l2ZW4gcGFja2V0Lg0K DQpUaGUgZmlyc3Qgc3RlcCB0b3dhcmRzIGhlYWRlciBpbnNlcnRpb24sIGlzIHRvIGNsZWFybHkg ZG9jdW1lbnQgdGhlIHByYWN0aWNhbCwgb3BlcmF0aW9uYWwgdXNlLWNhc2Ugd2hlcmUgaXQgaXMg cmVxdWlyZWQgKHVzZWQpIGFuZCBzYWZlLg0KICAgIA0KICAgIEl0IGlzIGxlc3MgY2xlYXIgdG8g bWUgdW5kZXIgd2hhdCBjaXJjdW1zdGFuY2VzIG9uZSB3b3VsZCB3aXNoIHRvDQogICAgaW5zZXJ0 IGEgc2VnbWVudCByb3V0aW5nIGhlYWRlciBhdCBhIHRyYW5zaXQgbm9kZSAoYWthIGludGVybWVk aWF0ZQ0KICAgIG5vZGUgLS0gaS5lLiwgYSBub2RlIG90aGVyIHRoYW4gdGhlIG9uZSBzcGVjaWZp ZWQgaW4gdGhlIERBIG9mIHRoZQ0KICAgIHBhY2tldCBpbiBxdWVzdGlvbikgd2hlbiBvbmUgZGlk IG5vdCBwcmV2aW91c2x5IGV4aXN0LiBUaHVzLCBhcyBhDQogICAgY2xhcmlmaWNhdGlvbiB0byBk cmFmdC12b3llci02bWFuLWV4dGVuc2lvbi1oZWFkZXItaW5zZXJ0aW9uOg0KICAgICAtIEluIFNl Y3Rpb24gMiwgcGxlYXNlIHNwZWNpZnkgaW4gdGhlIGZvbGxvd2luZyBzdGVwDQogICAgICAgbyAg Tm9kZSAxIG9yaWdpbmF0ZXMgYSBwYWNrZXQgUDEgZGVzdGluZWQgdG8gOSAoU0E9MSwgREE9OSku DQogICAgDQogICAgd2hldGhlciBvciBub3QgdGhlIHBhY2tldCBoYXMgYSBzZWdtZW50IHJvdXRp bmcgaGVhZGVyOyBpZiBzbywgc3BlY2lmeQ0KICAgIHRoZSBwYXRoICh3aGljaCB3b3VsZCBwcmVz dW1hYmx5IGluY2x1ZGUgbm9kZSAyKTsgaWYgbm90LCBleHBsYWluIGhvdw0KICAgIHRoZSBwYWNr ZXQgaXMgdG8gYmUgcm91dGVkLCBhbmQgZXhwbGFpbiBob3cgbm9kZSAyIGRlY2lkZXMgdG8gaW5z ZXJ0DQogICAgYSBzZWdtZW50IHJvdXRpbmcgaGVhZGVyLg0KIA0KQXMgaWxsdXN0cmF0ZWQgaW4g dGhlIGRyYWZ0LCB0aGUgc3RhdGVtZW50ICJOb2RlIDEgb3JpZ2luYXRlcyBhIHBhY2tldCBQMSBk ZXN0aW5lZCB0byA5IChTQT0xLCBEQT05KeKAnSByZWZlcnMgdG8gdGhlIGFjdGlvbiB0aGUgaW5n cmVzcyBub2RlIG9mIHRoZSBzb3VyY2UgZG9tYWluIGNvbnNpc3Rpbmcgb2YgZW5jYXBzdWxhdGlu ZyB0aGUgaW5jb21pbmcgcGFja2V0IChpLmUuOiB0aGUgcGFja2V0IGVudGVyaW5nIGluIHRoZSBz b3VyY2UgZG9tYWluKSBpbnRvIGFuIG91dGVyIGhlYWRlciB3aXRoIFNBPWhpbXNlbGYgKGkuZS4s IG5vZGUgMSkgYW5kIERBPWVncmVzcyBub2RlIChpLmUuLCBub2RlLTkpLiBUaGlzIG1lYW5zIHRo YXQgYWxsIHBhY2tldCB0cmFuc2l0aW5nIHRocm91Z2ggdGhlIHNvdXJjZSBkb21haW4gYXJlIGlu IGZhY3QgZW5jYXBzdWxhdGVkL3R1bm5lbGVkIHRocm91Z2ggaXQuDQoNCkluIHRoaXMgY2FzZSwg dGhlIHNoYXBlIG9mIHRoZSBuZXcgcGFja2V0IGlzOg0KCVNBPTEsIERBPTkNCglTQT14LCBEQT15 IChpLmUuLCB0aGUgb3JpZ2luYWwgU0EvREEgYWRkcmVzc2VzKQ0KCXBheWxvYWQNCg0KTm93LCB0 aGUgcGFja2V0IHRyYXZlbHMgZnJvbSBub2RlLTEgdG8gbm9kZS05IGFuZCBhcnJpdmVzIGluIG5v ZGUtMi4gQXNzdW1lIHRoYXQgbm9kZS0yIGFjdGl2YXRlZCBUSS1MRkEgKElQRlJSKSB3aGVyZSBh IGJhY2t1cCBwYXRoIGlzIHByZS1jb21wdXRlZCBhbmQgaW5zdGFsbGVkIGludG8gZmliIHNvIHRo YXQgaW4gY2FzZSBvZiBpbnRlcmZhY2UgMnRvMyBmYWlscywgdGhlIHRyYWZmaWMgZm9sbG93cyB0 aGUgNTBtcyBjb252ZXJnZW5jZSBydWxlcyBvciBiZXR0ZXIoU1JURSkuIFVwb24gZmFpbHVyZSBv ZiBpbnRlcmZhY2UgMnRvMywgdGhlIHBhY2tldCBpcyByZXJvdXRlZCB0byBub2RlLTQgd2l0aCB0 aGUgZm9sbG93aW5nIFNSSCBpbnNlcnRlZDoNCg0KCVNBPTEsIERBPTUgICAgKERBIGlzIG5vdyBz ZXQgYXMgdGhlIGZpcnN0IHNlZ21lbnQpDQoJU1JIPSg1LCA5KQ0KCVNBPXgsIERBPXkgICAgKGku ZS4sIHRoZSBvcmlnaW5hbCBTQS9EQSBhZGRyZXNzZXMpDQoJcGF5bG9hZA0KaS5lLiwgcGFja2V0 IG5vdyBoYXMgYW4gU1JIIGluc2VydGVkIGJ5IG5vZGUtMiAodHJhbnNpdCBub2RlKS4NClJlZi46 IGZldyBwYXBlciBhYm91dCBUSS1MRkE6DQpodHRwOi8vd3d3LnRtY25ldC5jb20vdG1jL3doaXRl cGFwZXJzL2RvY3VtZW50cy93aGl0ZXBhcGVycy8yMDE1LzExNTI0LWZhc3QtcmVyb3V0ZS13aXRo LXNlZ21lbnQtcm91dGluZy1leHRlbmRpbmctZmFzdC1yZXJvdXRlLnBkZg0KaHR0cDovL3d3dy5z ZWdtZW50LXJvdXRpbmcubmV0L3R1dG9yaWFscy8yMDE2LTA5LTI3LXRvcG9sb2d5LWluZGVwZW5k ZW50LWxmYS10aS1sZmEvDQoNCldoZW4gdGhlIHBhY2tldCByZWFjaGVzIG5vZGUtOSwgaXQgaXMg ZGVjYXBzdWxhdGVkIHdoaWNoIG1lYW5zIGJvdGggb3V0ZXIgaGVhZGVyIGFuZCBTUkggYXJlIHJl bW92ZWQuDQogICANCiAgICAtIEluIFNlY3Rpb24gMywgcHJvdmlkZSB0aGUgc2FtZSBjbGFyaWZp Y2F0aW9uIGlmIG5vdCBhbHJlYWR5IGNvdmVyZWQgYnkNCiAgICB0aGUgY2hhbmdlIHRvIFNlY3Rp b24gMi4NCiAgICANCiAgICA+IE1vcmVvdmVyIHdpdGggdGhlIG92ZXJoZWFkIG9mIHNpZ25hbGlu ZyByZXF1aXJlZCB0byBlc3RhYmxpc2hlZCBhbiBMU1AgaW4NCiAgICA+IE1QTFMgY2FzZSB0cmFu c2l0IG5vZGVzIG5vIG1hdHRlciBpZiB0aGV5IGFyZSB3aXRoaW4gZG9tYWluIG9yIGJleW9uZCBk b21haW4NCiAgICA+IERPIE5PVCBORUVEIHRvIGNoYW5nZSBhbnkgc2luZ2xlIGJpdCBpbiB0aGVp ciBjdXJyZW50IGZvcndhcmRpbmcgcGFyYWRpZ20uDQogICAgPiBTUiBmdW5jdGlvbnMgYXJlIGV4 ZWN1dGVkIG9ubHkgYXQgdGhlIGRlc2lnbmF0ZWQgbm9kZXMgd2hpY2ggYXJlIGFibGUgdG8NCiAg ICA+IHBlcmZvcm0gdGhlIGRlc2lyZWQgZm9yd2FyZGluZyBiZWhhdmlvdXIuDQogICAgDQogICAg SWYgdGhpcyBpcyBhbHNvIHRydWUgZm9yIHRoZSBJUHY2IGRhdGEgcGxhbmUsIEkgd291bGQgbm90 IGV4cGVjdCBhIHRyYW5zaXQNCiAgICBub2RlIHRvIG5lZWQgdG8gaW5zZXJ0IGEgc2VnbWVudCBy b3V0aW5nIGhlYWRlciwgaXJyZXNwZWN0aXZlIG9mIHdoZXRoZXINCiAgICBpdCBpcyBwYXJ0IG9m IHRoZSBTUiBkb21haW4gb3Igbm90LiBJZiB0aGlzIGlzIHRvdGFsbHkgb2ZmIGJhc2UsIGl0IHdv dWxkDQogICAgYmUgZ29vZCBmb3IgZHJhZnQtdm95ZXItNm1hbi1leHRlbnNpb24taGVhZGVyLWlu c2VydGlvbiB0byBleHBsYWluIHdoeS4NCiAgICANCiAgICA+IFRoaXMgZW50aXJlIGRpc2N1c3Np b24gdGhhdCBtYXliZSB3ZSB3aWxsIGJsZXNzIFNSdjYgaW4gY2xvc2VkIGRvbWFpbnMganVzdA0K ICAgID4gZG9lcyBub3QgZ2V0IHRoZSBmdW5kYW1lbnRhbCBwb2ludCB0aGF0IHRyYW5zaXQgbm9k ZXMgcmVnYXJkbGVzcyBvbiBob3cgbWFueQ0KICAgID4gU1JIIGFyZSBpbiB0aGUgSVB2NiBwYWNr ZXQgd2lsbCB3b3JrIGp1c3QgZmluZS4gT2YgY291cnNlIHRoZXJlIGlzIE1UVQ0KICAgID4gY29u Y2VybiAuLi4gYnV0IHRoaXMgY29uY2VybiBpcyBhbHNvIHdpdGggTVBMUyBzdGFja2luZyBvciBm b3IgdGhhdCBtYXR0ZXINCiAgICA+IHdpdGggYW55IGVuY2Fwc3VsYXRpb24uIEFuZCB3ZSBkbyBr bm93IHRvZGF5IGhvdyB0byBlZmZlY3RpdmVseSBzb2x2ZSBpdA0KICAgID4gd2hlbi93aGVyZSBu ZWVkZWQuDQogICAgDQogICAgSSB0b3RhbGx5IGdldCB0aGF0IHRyYW5zaXQgbm9kZXMgKGkuZS4s IG5vZGVzIHRoYXQgYXJlIG5vdCBzcGVjaWZpZWQgYnkgdGhlDQogICAgREEgb2YgdGhlIHBhY2tl dCBkdXJpbmcgYW55IGhvcCkgc2hvdWxkIG5vdCBuZWVkIHRvIGNoYW5nZSB0aGVpciBiZWhhdmlv cg0KICAgIGFuZCBhbGwgYW5kICBzaG91bGQgd29yayBqdXN0IGZpbmUgaXJyZXNwZWN0aXZlIG9m IHdoZXRoZXIgdGhlIHNlZ21lbnQNCiAgICByb3V0aW5nIGhlYWRlciBpcyBwcmVzZW50IG9yIG5v dC4gVGhhdCBpcyB3aGF0IDI0NjAgYW5kIHRoZSBjdXJyZW50DQogICAgaW5jYXJuYXRpb24gb2Yg MjQ2MGJpcyBtYW5kYXRlLiBbVGhhdCBpcyBhbHNvIHdpZGVseSB2aW9sYXRlZCAtLSBwYWNrZXRz DQogICAgd2l0aCB1bmtub3duIGV4dGVuc2lvbiBoZWFkZXJzIGFyZSBvZnRlbiBkcm9wcGVkIGlu IHByYWN0aWNlIC0tIGJ1dCB0aGUNCiAgICBob3BlIGlzIHRoYXQgaW4gdGltZSBhZG9wdGlvbiBv ZiBSRkMgNzA0NSB3aWxsIGhlbHAgdGhlIHNpdHVhdGlvbi5dDQoNCnN0aWxsLCBpbiBhIHNvdXJj ZSBkb21haW4gd2hlcmUgeW91IGVuY2FwIHBhY2tldHMgKGFuZCBkZWNhcCBhdCBlZ3Jlc3MpIHlv dSBjYW4gc2FmZWx5IGRvIHByZXR0eSBtdWNoIHdoYXQgeW91IHdhbnQuDQogICAgDQogICAgQnV0 IGFzIHBhcnQgb2YgZGVhbGluZyB3aXRoIHRoZSBNVFUgcHJvYmxlbSwgb25lIG9mIHRoZSBwcmVy ZXF1aXNpdGVzIGZvcg0KICAgIGNvcnJlY3Qgb3BlcmF0aW9uIGlzIHRoYXQgdGhlIERBIG9mIHBh Y2tldCB0aGF0IGNvbnRhaW5zIGEgc2VnbWVudCByb3V0aW5nDQogICAgaGVhZGVyIE1VU1QgcG9p bnQgdG8gYSBub2RlIHRoYXQgaXMgYWJsZSB0byBjb3JyZWN0bHkgZGVhbCB3aXRoIFBhY2tldCBU b28NCiAgICBCaWcgSUNNUHY2IG1lc3NhZ2VzLiBBY3R1YWxseSwgdGhhdCBpcyB0cnVlIGZvciBh bnkgSUNNUCBlcnJvciBtZXNzYWdlDQogICAgcmVsYXRlZCB0byB0aGUgU1JILiBUaGF0IGlzIGEg bWFuYWdlYWJsZSBwcm9ibGVtIGlmIFNSSCBpcyBhZGRlZCBvbmx5IGJ5DQogICAgdGhlIG9yaWdp bmF0aW5nIG5vZGUgb3IgYWZ0ZXIgZW5jYXBzdWxhdGlvbiBieSBhIGJvcmRlciByb3V0ZXIsIGJ1 dCBpdCBpcw0KICAgIGxlc3MgY2xlYXIgaG93IGl0IGlzIG1hbmFnZWQgb2YgU1JIIGlzIGluc2Vy dGVkIGluIGZsaWdodC4gU286ICANCiAgICAtIEFkZCB0ZXh0IHRvIGRyYWZ0LXZveWVyLTZtYW4t ZXh0ZW5zaW9uLWhlYWRlci1pbnNlcnRpb24gZXhwbGFpbmluZw0KICAgIGhvdyBpdCBpcyBlbnN1 cmVkIHRoYXQgSUNNUCBtZXNzYWdlcyBmb3IgYSBwYWNrZXQgY29udGFpbmluZyBhIHNlZ21lbnQN CiAgICByb3V0aW5nIGhlYWRlciBnZXQgYmFjayB0byBhIG5vZGUgdGhhdCB1bmRlcnN0YW5kcyB3 aGF0IHRoZXkgbWVhbi4gDQoNCkFDSzsgVGhlIGFib3ZlIHNob3VsZCBzYXkgU0EgKHNvdXJjZSBh ZGRyZXNzKSB3aGVyZSBpdCBzYXlzIERBLiANCml0IHdpbGwgc2luY2UgcGFja2V0IGlzIHNvdXJj ZWQgYnkgbm9kZS0xIHNvIG5vZGUtMSBpcyB0aGUgbm9kZSByZWNlaXZpbmcgaWNtcCBtZXNzYWdl cy4NCg0KSWYNCiAgICBTUkggY2FuIGJlIGluc2VydGVkIChhcyBvcHBvc2VkIHRvIG1vZGlmaWVk KSBieSBhbiBpbnRlcm1lZGlhdGUgbm90ZSwNCiAgICB0aGF0IGlzIGEgbm9uLXRyaXZpYWwgbWF0 dGVyDQogICAgDQogICAgPiBJdCBnZXQncyBldmVuIHdvcnNlIGlmIHlvdSAobGlrZSBzb21lIG9m IHRoaXMgV0cgbWVtYmVycykgbm93IHJlcXVpcmUgdG8NCiAgICA+IGVuY2Fwc3VsYXRlIHBhY2tl dHMgaW4gYWRkaXRpb25hbCB2NiBoZWFkZXIgYmVmb3JlIFNSSCBpcyBpbnNlcnRlZCAtIG1ha2Vz DQogICAgPiB6ZXJvIHNlbnNlICEgSnVzdCBwbGVhc2Uga2luZGx5IG9ic2VydmUgdGhhdCBpZiB5 b3UgZG8gdGhlIGVuY2FwIHRoZSBkc3QNCiAgICA+IGFkZHJlc3MgY2FuIGJlIGFueXdoZXJlIGlu IHRoZSBJbnRlcm5ldCAuLiBubyBlbmNhcCBjb2RlIG1hbmRhdGVzIHRoYXQgZHN0DQogICAgPiBt dXN0IGJlIGluIHlvdXIgSUdQLiBTbyBwYWNrZXRzIGRvIGVzY2FwZSBBU2VzIC4uIEJHUCBpbiBm YWN0IHdhcyBleHBsaWNpdGx5DQogICAgPiBjcmVhdGVkIHRvIGhlbHAvYXNzaXN0IHRoZW0gdG8g ZXNjYXBlLiANCiAgICBJIHRoaW5rIHRoZXJlIGlzIGEgcHJvYmxlbSBoZXJlIGJ5IGltcHJlY2lz ZSB1c2Ugb2YgbGFuZ3VhZ2UuIFRoZSBxdW90ZWQNCiAgICB0ZXh0IGEgY291cGxlIG9mIHBhcmFn cmFwaHMgYWJvdmUgc2F5cyAicmVnYXJkbGVzcyBvbiBob3cgbWFueSBTUkggYXJlIGluDQogICAg dGhlIElQdjYgcGFja2V0LiIgSG93ZXZlciwgYWNjb3JkaW5nIHRvDQogICAgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyLTA2 I3NlY3Rpb24tMy4yDQogICAgdGhlIFNSSCBzaG91bGQgYXBwZWFyIGF0IG1vc3Qgb25jZSBpbiBh IHBhY2tldC4gTm93LCB0aGUgTVBMUyBleGFtcGxlIGluICANCiAgICBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtdm95ZXItNm1hbi1leHRlbnNpb24taGVhZGVyLWluc2VydGlvbi0w MCNzZWN0aW9uLTIuMQ0KICAgIGRpc2N1c3NlcyBhZGRpbmcgbGFiZWxzLCB3aGljaCB3b3VsZCBi ZSBhbmFsb2dvdXMgdG8gYWRkaW5nIGluZGl2aWR1YWwNCiAgICBzZWdtZW50cyB0byB0aGUgc2Vn bWVudCBsaXN0IGluIHRoZSBTUkgsIG5vdCB0byBhZGRpbmcgYW5vdGhlciBTUkguIElzDQogICAg dGhhdCB3aGF0IGlzIGFjdHVhbGx5IGJlaW5nIGRpc2N1c3NlZD8NCg0KdGhpcyBpcyBvdXQgb2Yg c2NvcGUgb2YgYm90aCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciBhbmQg ZHJhZnQtdm95ZXItNm1hbi1leHRlbnNpb24taGVhZGVyLWluc2VydGlvbi4NCg0KSWYgeW91IG5l ZWQgdG8gYWRkIFNSSOKAmXMgeW91IGNhbiBhbHdheXMgYWRkIGFuIGFkZGl0aW9uYWwgZW5jYXAu DQogICAgDQogICAgQmFzZWQgb24gdGhlIGV4aXN0aW5nIGRvY3VtZW50YXRpb24sIEkgZ2V0IHdo eSB0aGVyZSBpcyBhIGRlc2lyZSB0byBtb2RpZnkNCiAgICB0aGUgc2VnbWVudCBsaXN0IG9mIGFu IFNSSCB3aXRob3V0IGFkZGluZyBhbm90aGVyIGxheWVyIG9mIGVuY2Fwc3VsYXRpb24uDQogICAg RG9pbmcgc28gd291bGQgdmlvbGF0ZSB0aGUgZXhwZWN0YXRpb24gaW4gUkZDIDQzMDIgIChBSCkg dGhhdCB0aGUgbmV0d29yaw0KICAgIHdpbGwgbm90IGNoYW5nZSB0aGUgbGVuZ3RoIG9mIGFuIGV4 dGVuc2lvbiBoZWFkZXIsIG1lYW5pbmcgdGhhdCBTUkggY291bGQNCiAgICBub3QgYmUgdXNlZCBp biBjb25qdW5jdGlvbiB3aXRoIEFILiBUaGF0IGlzIHNvbWV0aGluZyBlbHNlIHRoYXQNCiAgICBk cmFmdC12b3llci02bWFuLWV4dGVuc2lvbi1oZWFkZXItaW5zZXJ0aW9uIHNob3VsZCBtZW50aW9u Lg0KICAgIA0KICAgIFdoYXQgSSBkb24ndCBnZXQgaXMgd2h5IHRoZXJlIGlzIGEgZGVzaXJlIGZv ciBhIG5vZGUgdG8gaW5zZXJ0IGFuIFNSSA0KICAgIHdpdGhvdXQgZW5jYXBzdWxhdGlvbiB3aGVu IG5vbmUgd2FzIHRoZXJlIHRvIGJlZ2luIHdpdGguIElmIHRoYXQgaXMNCiAgICByZWFsbHkgZGVz aXJlZCwgZHJhZnQtdm95ZXItNm1hbi1leHRlbnNpb24taGVhZGVyLWluc2VydGlvbiBuZWVkcyB0 bw0KICAgIGV4cGxhaW4gd2h5Lg0KICAgIA0KICAgID4gSSB0aGluayBwZXJoYXBzIGEgZGVkaWNh dGVkIGludGVyaW0gbWVldGluZyBzaG91bGQgYmUgc2V0dXAganVzdCB0byBkaXNjdXNzDQogICAg PiBpdCBhbmQgdW5kZXJzdGFuZCBpdCB3ZWxsIGJlZm9yZSB3ZSBwcm9jZWVkIHdpdGggYW55IGZ1 cnRoZXIgc3BlYw0KICAgID4gY2xhcmlmaWNhdGlvbnMgb3IgZXh0ZW5zaW9ucy4NCiAgICANCiAg ICBTdXJlLiBCdXQgdGhhdCBzaG91bGQgbm90IHN0b3AgMjQ2MGJpcy4gSXQncyBzdXBwb3NlZCB0 byBiZSBJUy4gQW55IG5ldw0KICAgIGV4dGVuc2lvbiB0byBzdXBwb3J0IHRoZSBTUiBjb21tdW5p dHkncyByZXF1aXJlbWVudHMgd291bGQgY29tZSBpbiBhdCBQUy4NCiAgICBBbiBlbmhhbmNlZCB2 ZXJzaW9uIG9mIGRyYWZ0LXZveWVyLTZtYW4tZXh0ZW5zaW9uLWhlYWRlci1pbnNlcnRpb24gd2ls bA0KICAgIGhlbHAgbW92ZSB0aGF0IHByb2Nlc3MgZm9yd2FyZC4NCiANClN1cmUgdGhpbmcsIHdl 4oCZbGwga2VlcCBhZGRpbmcgdG8gdGhlIGRyYWZ0LiBNZWFud2hpbGUgSSBob3BlIHRoZSBleHBs YW5hdGlvbnMgaGVscGVkIHRoaXMgdGhyZWFkIHByb2dyZXNzaW5nIGluIGEgY29uc3RydWN0aXZl IHdheS4NCiAgIA0KICAgIFRoYW5rcyAmIHJlZ2FyZHMsDQogICAgDQogICAgTWlrZSBIZWFyZA0K ICAgDQpkYW4gDQoNCg== From nobody Fri May 5 17:31:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF23126C7A for ; Fri, 5 May 2017 17:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_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 kITw7IgcHh7Z for ; Fri, 5 May 2017 17:31:50 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 0A8EB124D85 for <6man@ietf.org>; Fri, 5 May 2017 17:31:50 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id q78so7295006vke.3 for <6man@ietf.org>; Fri, 05 May 2017 17:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=aEG2cGS7Xf8IzLVMgakJq9Hsi9gSNQF4NIgxgEBXVVw=; b=uIbrnuHTcRXWdKgCKadIpJDvzX/p0bhJhN4elji1un+YqjOIYWQRX5AwiqlSUYzL05 b2vl5MXDKb6wRI5jxfjBrwjT7j9DLVWBFE1GMZ/2pXWfVbu1Su0lEG44sJKuKfdsTAjn /tCt9VHsEznkJx7p4YEQHRMQZbOyWt230ucTu6PDr9SIJ3aEPnXNwJe++KqOHF3jKF8R liPFrcupHsF7i/WOcYs4pqpi9U30nv5YPxeuUq6jhZ4yuszc2Lt7ormBGRjCUkQBP6cF LBnLcCdEVguk4/K2Ge232U4F6fhmFecemsS26wlsCJikRXsTU5LG35XJjpSrJR9E9WVh pUGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=aEG2cGS7Xf8IzLVMgakJq9Hsi9gSNQF4NIgxgEBXVVw=; b=D231a/S4EbWWKwVP0RvpamtY+myhbMqta4+cgLQTkfD7bRrB71Zas/c4esa0IT+dgW xTMAOfOhD0emqHlc0bMZ0Pf6jDhVzLNTUpkT5MmumRzIZWP324jFCK3RDofJ6P6CCzCP yQsU1eJGJk4FfPJ0yE/qmXh7rZalEHDrj4OC8O1yuNkBZk71TLsUJbvqJDVN0wFPH2GX Vkk0n3I4XPzkHi5/7+NOJG7twWRN1qnVTCvNVQtaTPYxkXkBLvMjINtRMjAsocSYfxfI g9T7iJqKMoB2eh/4nT6ovFIkG83co6qcCzLooANCFcHhZtXj6mLp+/pBl90N3LVTIcIP ztIA== X-Gm-Message-State: AN3rC/7GS9mXvJrK+W5JuUu2M/Oh23+ePzetZffPQ4WnJ0EWdmHo1Ac+ Ht5q92Lz0kewbZuaiGuxyS10UBh/SA== X-Received: by 10.31.248.70 with SMTP id w67mr5972994vkh.112.1494030709090; Fri, 05 May 2017 17:31:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.51 with HTTP; Fri, 5 May 2017 17:31:18 -0700 (PDT) From: Mark Smith Date: Sat, 6 May 2017 10:31:18 +1000 Message-ID: Subject: Ambiguous Terminology (Re: Questions / comments regarding draft-voyer-6man-extension-header-insertion (was: Proposed revised Extension Header text for rfc2460bis)) To: "Voyer, Daniel" Cc: "C. M. Heard" , Robert Raszuk , 6MAN <6man@ietf.org> Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 00:31:51 -0000 Reading through various emails, I think there may be some confusion about terminology in regards to "EH insertion". This definitely needs to be covered in this draft. If there is ambiguity, there is possibility for misunderstanding. My definition of "EH insertion" is the following action, because "insertion" is a variation of "in" or "into" EH Insertion: - Pre-insertion, prefixed with SA to indicate originated by the device in the SA field. [SA. IPv6 Hdr][SA. IPv6 EHs][SA. IPv6 Payload] - Post-insertion, where the SR EH has been inserted into the existing IPv6 packet [SA. IPv6 Hdr][SRH EH][SA. IPv6 EHs][SA. IPv6 Payload] The alternative is to add an EH via IPv6-in-IPv6 encapsulation, so this could be given the term "EH addition" or "EH addition via encapsulation" (the latter probably better because it is even more explicit) EH Addition via Encapsulation: - Pre-addtion [SA. IPv6 Hdr][SA. IPv6 EHs][SA. IPv6 Payload] - Post-addtion, [New IPv6 Hdr][SRH EH]([SA. IPv6 Hdr][SA. IPv6 EHs][SA. IPv6 Payload]) The main key difference between them is in "EH insertion", while the inserted EH is present, the source address field in the [SA. IPv6 Hdr] is wrong - the device recorded is not the source of all of the information in the packet. This is what causes PMTUD, AH, ICMP etc. to fail. This operation of EH insertion is what is not described by RFC2460 and its ancestors and is what receiving IPv6 nodes are not expecting. They expect that if a packet arrives, the SA field identifies the device that originated the whole received packet. "EH Addition via Encapsulation" preserves the semantics of the original SA while the EH was added. The addition of the EH is entirely transparent to the original IPv6 packet and its originating or receiving hosts, as there is no modification of the original IPv6 packet. PMTUD, AH, ICMP won't fail in unexpected ways, because the device that added the EH is identified in the new outer IPv6 packet header's Source Address field. The optional SRH Ingress Node TLV would capture the SRH header source device information, however in addition to being optional, that source device information is not recorded in a place where protocols and methods such as PMTUD can use it. The other point of note is that hosts "inserting EHs" when they originate the IPv6 packet is not a case to support routers doing it while the IPv6 packet is in-flight. The host "inserting" the EH is the one that originates the IPv6 packet, and is the one that is identified in the SA field. It is an operation described by RC2460 and its ancestors, and if it triggers e.g., PMTUD, then the ICMP PTB will be sent back to the correct packet source host. Regards, Mark. From nobody Mon May 8 06:00:45 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE8F120727; Mon, 8 May 2017 06:00:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-6man-rfc1981bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: Eric Rescorla's No Objection on draft-ietf-6man-rfc1981bis-06: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149424843717.31731.1944317631050418426.idtracker@ietfa.amsl.com> Date: Mon, 08 May 2017 06:00:37 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 13:00:37 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-6man-rfc1981bis-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Document: draft-ietf-6man-rfc1981bis-06.txt OVERALL I see in the shepherd's writeup that you have opted not to cite RFC 2119, but that makes the mixed case use of SHOULD/MUST even more confusing. I would suggest that at minimum you go through the document and evaluate whether each should/must should be capitalized, though I would prefer a cite to 2119. For instance: changed. Therefore, attempts to detect increases in a path's PMTU should be done infrequently. Is this normative? I also share the concerns others have raised about whether, given the actual state of PMTU this is something we should be making IS, but I'm willing to bow to the majority here. S 3. Note that Path MTU Discovery must be performed even in cases where a node "thinks" a destination is attached to the same link as itself. I think you need to qualify this must because you just said above that you don't need to if you use the minimum. Perhaps: Note that even when a node "thinks" a destination is attached to the same link as itself, it might have a PMTU lower than the link MTU... S 4. Nodes SHOULD appropriately validate the payload of ICMPv6 PTB messages to ensure these are received in response to transmitted traffic (i.e., a reported error condition that corresponds to an IPv6 packet actually sent by the application) per [ICMPv6]. This seems like it ought to be a MUST. Is there a good reason why it is not? Perhaps also a cite to how one validates. When a node receives a Packet Too Big message, it MUST reduce its a valid Packet Too Big message, I think because in graf 2 you say you should validate. elicit Packet Too Big messages. Since each of these messages (and the dropped packets they respond to) consume network resources, the node MUST force the Path MTU Discovery process to end. It's not clear to me what the requirement is. Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast as possible. Nodes MAY detect increases in PMTU, but because doing Same thing, what are you requiring. How could I be nonconformant to this? S 5. This section discusses a number of issues related to the implementation of Path MTU Discovery. This is not a specification, but rather a set of notes provided as an aid for implementers. However, this section contains a lot of normative language. Is that all non-normative? S 5.3. If the stale PMTU value is too large, this will be discovered almost immediately once a large enough packet is sent on the path. No such mechanism exists for realizing that a stale PMTU value is too small, so an implementation SHOULD "age" cached values. When a PMTU value has not been decreased for a while (on the order of 10 minutes), the PMTU estimate should be set to the MTU of the first-hop link, and the packetization layers should be notified of the change. This will cause the complete Path MTU Discovery process to take place again. Is this really good advice for TCP? It seems like if you have a situation where it required several attempts to get the true PMTU (for instance, if you have successively narrower tunnels), then a PMTU reset could have a pretty material impact on throughput. S 6. 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. I get that this is now not a normative statement but rather a claim about what nodes who follow the MUST NOT in S 4, but it might still be better to make it a MUST to avoid confusion. From nobody Mon May 8 08:43:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B59127275 for ; Mon, 8 May 2017 08:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoTrwG8jkwwO for ; Mon, 8 May 2017 08:43:23 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 1BEDF126B6E for <6man@ietf.org>; Mon, 8 May 2017 08:43:23 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id t26so37560904qtg.0 for <6man@ietf.org>; Mon, 08 May 2017 08:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PQ1won4zGWGbILmSaapkKrk5W+/K2vFA8IdWxn4fnW0=; b=LXiMlMY50Htjr+h5lNHxKXtSiVXnE9CaHx74fy/vqxTpMFmfSrqkutZDUncSn1hRv6 GiA+RCi5PVef86I3gt41699EBiW9ISNih0At++sAYmJGpkfBFSS9UoqJIhNeMc8a2SVh RNHSh0fzwLGo3S5y3SXXofhb/c+geVPhqSPHh/xJRAV1b1QOjHwCvo6TtlVP672l/5JO TxO1vOe2pfYRqWw/2ssXSSqH67sliUhHyl/fzoDHbW+s+YlHscwoOwkb8qfSvJwxeYWZ kNr13DfpjotFgzL0EkwkTFw5QRqK9paJc7PyAA4ioEfybY3GgxkUYR7mMcUBqEUQIA7Q 8X/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PQ1won4zGWGbILmSaapkKrk5W+/K2vFA8IdWxn4fnW0=; b=fLfgn32reZ8WcyVZ2+EZ7ln8BMDQvblrWEd+DkLuNbC2klDLCTdVF+aO/RG7JLxfzf DuSivmWqV15HeJiaWzXruFym66mNzd30ydqyNvFRIiqwAKjnUS2rQI5rdZKrxiSwQ7ki +3VsvDXqpTBMAsiXoVOJTBhNK06UEgOroWNLLy27p3nOfkqboJEs4qCnvrM2eCZQK+oI vmgl778o50zY2mfdyBMcruS9KDbSmTuLF1bhtzN1ftFN+sWrouK+2ozZoD3piFXSEldu LT2952hDii5OxUpRT7mrv8MXbtVFHWcrvmmF0aSKPSK1o6GR7j3EMu6pn7HyJ/DVaunN TzqQ== X-Gm-Message-State: AN3rC/4yyh4hNKKYk1WW3DR+otb+fuRkwkzOv11xSekPwSL7dQQ0Sgbk MUdgmphi7ZIjtJZnIgjBWFf79MQzQA== X-Received: by 10.200.43.146 with SMTP id m18mr53686611qtm.210.1494258201625; Mon, 08 May 2017 08:43:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Mon, 8 May 2017 08:43:21 -0700 (PDT) In-Reply-To: <149425780032.31731.10564902800308275421.idtracker@ietfa.amsl.com> References: <149425780032.31731.10564902800308275421.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Mon, 8 May 2017 08:43:21 -0700 Message-ID: Subject: Fwd: New Version Notification for draft-herbert-6man-icmp-limits-00.txt To: 6man@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 15:43:24 -0000 Hello, This is a proposal for nodes (hosts or intermediate nodes) to send ICMP errors when they drop packets because they're not able to process headers because of processing limits. Thanks, Tom ---------- Forwarded message ---------- From: Date: Mon, May 8, 2017 at 8:36 AM Subject: New Version Notification for draft-herbert-6man-icmp-limits-00.txt To: Tom Herbert A new version of I-D, draft-herbert-6man-icmp-limits-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-6man-icmp-limits Revision: 00 Title: ICMPv6 errors for discarding packets due to processing limits Document date: 2017-05-08 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-herbert-6man-icmp-limits-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-6man-icmp-limits/ Htmlized: https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-6man-icmp-limits-00 Abstract: Network nodes may discards packets if they are unable to process protocol headers of packets due to processing constraints or limits. When such packets are dropped, the sender receives no indication so it cannot take action to address the cause of discarded packets. This document defines ICMP errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A sender that receives such an ICMP error may be able to modify what it sends in future packets to avoid subsequent packet discards. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon May 8 12:08:28 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64926129A90; Mon, 8 May 2017 12:08:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-6man-rfc1981bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6man-rfc1?= =?utf-8?q?981bis-06=3A_=28with_DISCUSS_and_COMMENT=29?= X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149427050740.24107.6062280537375286614.idtracker@ietfa.amsl.com> Date: Mon, 08 May 2017 12:08:27 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 19:08:27 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-6man-rfc1981bis-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I know this is a bis document and my discuss does not address any text that changed in the bis version but given all previous discussion, I would like to discuss the following text parts on statements regarding retransmissions which don't seem to be appropriate for this document and are partly even wrong. In general it does not make a lot of sense to talk about retransmission semantics in this document because this really depends on the upper layer protocol, and I'm really not sure if any implementaiton of a reliable transport does send retransmission based on the receptions of PTB messages (if exposed) rather than only relying on it's own loss detection mechanism. This discuss concerns a few sentence all over the document and most parts of section 5.4. Details proposals below: I propose to either remove this sentence, or at least reword to the following (or something similar): OLD: "Retransmission should be done for only for those packets that are known to be dropped, as indicated by a Packet Too Big message." NEW: "The IP layer may indicate loss to the upper layer protocol of those packets that are known to be dropped, as indicated by a Packet Too Big message." Or MAY or SHOULD or MUST...? Subsequently the following sentence should be removed as well: "An upper layer must not retransmit data in response to an increase in the PMTU estimate, since this increase never comes in response to an indication of a dropped packet." And here is the bigger change in section 5.4: OLD "When a Packet Too Big message is received, it implies that a packet was dropped by the node that sent the ICMPv6 message. It is sufficient to treat this in the same way as any other dropped segment, and will be recovered by normal retransmission methods. If the Path MTU Discovery process requires several steps to find the PMTU of the full path, this could delay the connection by many round- trip times. 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. The packet size used in the retransmission should be no larger than the new PMTU." NEW "When a Packet Too Big message is received, it implies that a packet was dropped by the node that sent the ICMPv6 message. A reliable upper layer protocol will detect the loss of this segment, and recover it by its normal retransmission methods. Depending on the loss detection method that is used by the upper layer protocol, this could delay the connection by many round-trip times. Alternatively, the retransmission could be done in immediate response to a notification that the Path MTU was decreased, but only for the specific connection specified by the Packet Too Big message. The packet size used in the retransmission should be no larger than the new PMTU." I don't understand the following paragraph. Can this be removed? "Note: A packetization layer must not retransmit in response to every Packet Too Big message, since a burst of several oversized segments will give rise to several such messages and hence several retransmissions of the same data. If the new estimated PMTU is still wrong, the process repeats, and there is an exponential growth in the number of superfluous segments sent." The following text is fine but probably is not needed if the whole document is reworded accordingly to ensure that retransmissions are solely the responsibility of the upper layer protocol: "Retransmissions can increase network load in response to congestion, worsening that congestion. Any packetization layer that uses retransmission is responsible for congestion control of its retransmissions. See [RFC8085] for more information." This can also be removed, because a reliable protocol that detected loss and decided to send a retransmission, should and will do the same processing as for all other retransmissions, e.g. reset the retransmission time in TCP. Mentioning this separately is rather confusing. "This means that the TCP layer must be able to recognize when a Packet Too Big notification actually decreases the PMTU that it has already used to send a packet on the given connection, and should ignore any other notifications." And this is even incorrect. Slow start means that you will increase the connection window exponentially. Only sending one segment means setting the congestion/sending window to one. I propose the following change: OLD "Many TCP implementations incorporate "congestion avoidance" and "slow-start" algorithms to improve performance [CONG]. Unlike a retransmission caused by a TCP retransmission timeout, a retransmission caused by a Packet Too Big message should not change the congestion window. It should, however, trigger the slow-start mechanism (i.e., only one segment should be retransmitted until acknowledgements begin to arrive again)." NEW "A loss caused by a PMTU probe indicated by the reception of a Packet Too Big message MUST NOT be considered as a congestion notification and hence the congestion window may not change." And I also don't understand this sentence: "TCP performance can be reduced if the sender's maximum window size is not an exact multiple of the segment size in use (this is not the congestion window size)." ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) I agree with Ekr on this sentence: "Nodes SHOULD appropriately validate the payload of ICMPv6 PTB messages to ensure these are received in response to transmitted traffic (i.e., a reported error condition that corresponds to an IPv6 packet actually sent by the application) per [ICMPv6]." This sounds like it should be a MUST but I guess it depends on the upper layer protocol if such a validation is possible or not, e.g. if information are available that can be used for validation. Maybe you can be more explicit here and even say something like pmtu discovery should/must only be used if the upper layer protocol provides means for validation of the icmp payload (like a sequence number in TCP)…? Further also note that if the upper layer does the validation while the IP layer maintains EMTU_S, there must be an interface from the upper layer to the IP layer to tell if a packet is valid or not before the IP layer updates the MTU estimate. This seems actually more complicated than this one sentences indicates. 2) Also as Ekr says, I also have problems to fully understand this normative text in section 4: "After receiving a Packet Too Big message, a node MUST attempt to avoid eliciting more such messages in the near future. The node MUST reduce the size of the packets it is sending along the path. Using a PMTU estimate larger than the IPv6 minimum link MTU may continue to elicit Packet Too Big messages. Since each of these messages (and the dropped packets they respond to) consume network resources, the node MUST force the Path MTU Discovery process to end. Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast as possible." I especially don't understand the first part, given that a PTB message may still indicate a MTU that is larger than the minimum link MTU which then may cause another PTB message later on the path. This text reads like if you receive one PTB message you should better end discovery and fall back to the minimum link MTU to avoid any further PTB message and not waist any resources. I don't think that's the intention and as such I don't understand when it is recommended to end discovery here...? 3) Section 5.2 seems to be written with only single homed hosts in mind. It might be good to advise that the pmtu information should always be stored on a per interface basis...? 4) Also section 5.2: You only advise to store information per flow ID, however, if the flow label is not used, wouldn't it make really sense to just use the 5-tuple instead? Also note that EMCP is often done based on the 5-tuple or even 6-tuple (with the ToS field). 5) And more in section 5.2: "When a Packet Too Big message is received, the node determines which path the message applies to based on the contents of the Packet Too Big message. " MAYBE: "When a valid Packet Too Big message is received, the node determines which path the message applies to based on the contents of the Packet Too Big message." And further on: "If the tentative PMTU is less than the existing PMTU estimate, the tentative PMTU replaces the existing PMTU as the PMTU value for the path." This doesn't cover the case where a pmtu probe with a larger size was send and the PTB message returns a larger value then stored. Maybe state this explicitly. This applies similar to this sentence in section 6: OLD "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.“ NEW "A node, however, MUST NOT raise its estimate of the PMTU based on a Packet Too Big message that is not a (validated) response to a PMTU probe that was previously send by this node, so should not be vulnerable to this attack." 6) Further section 5.2: Should this statement be maybe upper case MUST: "The packetization layers must be notified about decreases in the PMTU. " 7) Technical comment on section 5.3 in general: There is a difference between aging if a flow is active or not. While I maybe don't want to probe again for this connection because my application already decided to use a mode where it can live with the current pmtu and it's too much effect to switch, I really want to probe at the beginning of the next connection again to check if I can use a different mode now. While the IP layer does not have a notion of connection it can observe if packets are frequently send with the same 5-tuple and reset the cached pmtu after a certain idle time. 8) Section 5.4: should this maybe be normative, at least the last MUST NOT (be fragmented): "A packetization layer (e.g., TCP) must track the PMTU for the path(s) in use by a connection; it should not send segments that would result in packets larger than the PMTU, except to probe during PMTU discovery (this probe packet must not be fragmented to the PMTU). " Nit: The abbreviation PTB is only used once in section 4 (and never expanded). From nobody Mon May 8 12:11:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66319129649 for ; Mon, 8 May 2017 12:11:52 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 sow7C8brjXTQ for ; Mon, 8 May 2017 12:11:51 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 E0C1A129601 for <6man@ietf.org>; Mon, 8 May 2017 12:11:50 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id v14so37532510pfd.2 for <6man@ietf.org>; Mon, 08 May 2017 12:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3Zg8ycNok+9pLpvb+TlspU+BJad71yuVj8aKiKm8RsI=; b=q6dhvvmYmoQ2cW1EGvhs6LjxXBcUHJ1W5p74nXqPHJrAqFkAOkbDMrmEW0/TOT0tCx Fxmf5c5b2K7107vlaSMnJCV89QCPPkm66keCQp5BE8O4jYvmjVqIA1zQ7R6MnILatA1I wDBx/1q0RQiX3cpRB/Ck4mNPm3Us+vn4Ciij5RW0JT8ZgnT7jPopiFrU/bEY7oK4taIb hmyuPXqkRLjyImY0Wc5E7LNim1ANsLy4o1NVKo/A+1RRuaVficSJTmJlkDAOCPfpp+cG dCOxshKlfvtR6m96kvB1mCAnUnvsbu98aRoYm1jBpw3VhGcZQBqw5BIsHag+HUO6vGBT jT9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3Zg8ycNok+9pLpvb+TlspU+BJad71yuVj8aKiKm8RsI=; b=Dkryah07EZc1SENPqLcyYEeQrmf9yi3O4/JPGodyZCexnnVgNzHrOvO3Js+kStDDO6 vJ75+qjCkR4c+A29qmXXEYeh1ODfdsFej/dyP68xKYvPKzQ0wFrtJpvTbDClnycKeYin vJzr9QVd0VRppLCQP4MNeAi2fdpKGHV1iJZH12/KdxJTSvzn5DwkB1thUNH9ZPEgVbNO 1oWOaXpLKg/vkg9LBDSMmRnRsqTjmaNoXUxYZxbQyfamEczrGYfgOtTqVM4mnubIfbUo T7w6AZL3HhApgX/CBGKmRlRJIsjLWwGvfDC+zgdgvsXSAjbUEAaJStVGrBerdmYwvybV MvXA== X-Gm-Message-State: AN3rC/5C1wqHQuXizAvb7jeTZmyrpHUJG/OZ5vnZo5DCe/qhkAdUkawl ca6vcEMwo9f6PA== X-Received: by 10.84.247.9 with SMTP id n9mr84674888pll.119.1494270710556; Mon, 08 May 2017 12:11:50 -0700 (PDT) Received: from [192.168.1.12] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id p13sm6133254pfl.52.2017.05.08.12.11.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 May 2017 12:11:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-00.txt From: Fred Baker In-Reply-To: Date: Mon, 8 May 2017 12:11:48 -0700 Cc: 6man@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E892340-9BD4-4E14-81BB-6FC3361E0BED@gmail.com> References: <149425780032.31731.10564902800308275421.idtracker@ietfa.amsl.com> To: Tom Herbert X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 19:11:52 -0000 Quick comment: The abstract talks about dropping packets due to = "processing constraints", which I took to mean rate limitations (aka = Source Quench), but the codes and body are about issues in extension = header parsing/processing. I wonder if there is a different phrase that = might be appropriate there? > On May 8, 2017, at 8:43 AM, Tom Herbert wrote: >=20 > Hello, >=20 > This is a proposal for nodes (hosts or intermediate nodes) to send > ICMP errors when they drop packets because they're not able to process > headers because of processing limits. >=20 > Thanks, > Tom >=20 > ---------- Forwarded message ---------- > From: > Date: Mon, May 8, 2017 at 8:36 AM > Subject: New Version Notification for = draft-herbert-6man-icmp-limits-00.txt > To: Tom Herbert >=20 >=20 >=20 > A new version of I-D, draft-herbert-6man-icmp-limits-00.txt > has been successfully submitted by Tom Herbert and posted to the > IETF repository. >=20 > Name: draft-herbert-6man-icmp-limits > Revision: 00 > Title: ICMPv6 errors for discarding packets due to processing = limits > Document date: 2017-05-08 > Group: Individual Submission > Pages: 8 > URL: > = https://www.ietf.org/internet-drafts/draft-herbert-6man-icmp-limits-00.txt= > Status: = https://datatracker.ietf.org/doc/draft-herbert-6man-icmp-limits/ > Htmlized: = https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-00 > Htmlized: > = https://datatracker.ietf.org/doc/html/draft-herbert-6man-icmp-limits-00 >=20 >=20 > Abstract: > Network nodes may discards packets if they are unable to process > protocol headers of packets due to processing constraints or limits. > When such packets are dropped, the sender receives no indication so > it cannot take action to address the cause of discarded packets. = This > document defines ICMP errors that can be sent by a node that = discards > packets because it is unable to process the protocol headers. A > sender that receives such an ICMP error may be able to modify what = it > sends in future packets to avoid subsequent packet discards. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon May 8 13:02:05 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D980120721; Mon, 8 May 2017 13:01:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-6man-rfc1981bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: Warren Kumari's No Record on draft-ietf-6man-rfc1981bis-06: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149427371611.7824.6370727830803946449.idtracker@ietfa.amsl.com> Date: Mon, 08 May 2017 13:01:56 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 20:01:56 -0000 Warren Kumari has entered the following ballot position for draft-ietf-6man-rfc1981bis-06: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [ Reminder to myself - I'm leaving this as No Record while looking more... ] I sent email about this to the authors on Feb 23rd - I seem to still have have many of the same questions... Comments: 1: Sec 1: "Path MTU Discovery relies on such messages to determine the MTU of the path." -- it is unclear which "such" refers to. Perhaps s/such/ICMPv6/ (or PTB). 2: Sec 3: "Upon receipt of such a message, the source node reduces its assumed PMTU for the path based on the MTU of the constricting hop as reported in the Packet Too Big message" -- this says that it reduces it *for the path*. But (as somewhat alluded to later in the draft) the nodes doesn't know what the path *is* -- it can decrease for the destination, or flow, or even interface, but (unless it is strict source routing) it doesn't control or really know the path (see also #4) 3: Sec 4: "The recommended setting for this timer is twice its minimum value (10 minutes)." - as above. This was from 1996 - were these metrics discussed at all during the -bis? I suspect that the average flow is much shorter these days (more web traffic, fatter pipes, etc) and so a flow of 10 minutes seems really long (to me at least). 4: Sec 5.2: "The packetization layers must be notified about decreases in the PMTU. Any packetization layer instance (for example, a TCP connection) that is actively using the path must be notified if the PMTU estimate is decreased. Note: even if the Packet Too Big message contains an Original Packet Header that refers to a UDP packet, the TCP layer must be notified if any of its connections use the given path." - this is related to #2 -- I don't know *which* path my packets take - once I launch them into the void, they may be routed purely based upon destination IP address, or they may be hashed based upon some set of header fields to a particular ECMP link or LSP. Once packets hit a load balancer, it is probably even *likely* that the UDP and TCP packets end up on different things. So, if I get a PTB from a router somewhere, I can probably guess that other packets to the same destination address will also follow that path, but I cannot know that for sure. I'm fine to decrease MTU towards that destination IP, but is that what this is suggesting? If so, please say that. If not, please let me know what I should do. The above is even more tricky / fun when I'm using flow id as the flow identifier -- if I get a PTB for flow 0x1234, what do I do? 5: Sec 5.3: "Once a minute, a timer-driven procedure runs through all cached PMTU values, and for each PMTU whose timestamp is not "reserved" and is older than the timeout interval ...". Please consider providing clarifications here. The wording implies that I should set a timer to fire on the minute, and trigger the behavior. If all of the (NTP synced!) machines in my datacenter do this, and all try send bigger packets (on 1/10th of long flows) their first hop router will get many, many over-sized packets and it will severely rate-limit the PTBs. Nits (Some of these are purely academic.) I understand that you are trying to limit the changes, so feel free to ignore these: 1: "A node sending packets much smaller than the Path MTU allows is wasting network resources and probably getting suboptimal throughput." - the "much" confuses me. If I'm using anything less than the MTU I'm wasting network resources and getting suboptimal throughput - I might not care, but if (used MTU) < (path MTU) I'm wasting resources. 2: "Nodes implementing Path MTU Discovery and sending packets larger than the IPv6 minimum link MTU are susceptible to problematic connectivity if ICMPv6 [ICMPv6] messages are blocked or not transmitted." The "implementing Path MTU Discovery and" seems redundant. ALL nodes sending packets larger than minimum MTU are "susceptible to problematic connectivity if ICMPv6 [ICMPv6] messages are blocked or not transmitted.". I get what you are trying to say, but my OCD tendencies would not allow me to ignore this... 3: "In the case of multipath routing (e.g., Equal Cost Multipath Routing, ECMP),"- this is vague / confusing -- (Equal Cost Multipath Routing, ECMP) makes it sound like either ECMP is an acronym for Equal Cost Multipath Routing, or that ECMP is something different to Equal Cost Multipath Routing. I'd suggest just dropping the "ECMP" (or, "Equal Cost Multipath (ECMP) routing", but that seems clumsy) From nobody Mon May 8 13:55:48 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34453124B0A; Mon, 8 May 2017 13:55:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-6man-rfc1981bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, ipv6@ietf.org Subject: Alvaro Retana's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149427694020.22664.10344820301651708437.idtracker@ietfa.amsl.com> Date: Mon, 08 May 2017 13:55:40 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 20:55:40 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-6man-rfc1981bis-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm putting in this point as a DISCUSS because I think that the current text may be confusing and vague. As others have pointed out, this document includes rfc2119-like language, both capitalized and not. I realize that rfc1981 was published before rfc2119 and that no expectation on the language existed then. However, we're at a point in time where not only rfc2119 is in place, but draft-leiba-rfc2119-update (which clarifies that only uppercase language has special meaning) is in AUTH48. I think that this leads to the possibility that the average reader may interpret the requirements in this document in a way that it wasn't intended. While I would prefer that this document be consistent (and either use capitalized rfc2119 language as intended, OR, not used it at all), I understand the intent of not changing some of the original text. I would be happy with a note like this one: "Note: This document is an update to RFC1981 that was published prior to RFC2119 being published. Consequently while it does use "should/must" style language in upper and lower case, the document does not cite the RFC2119 definitions. This update does not change that." [I borrowed this text from the the INTDIR review thread. [1]] I find that including a note in the Shepherd's write-up is not enough because the average reader/implementer will not consult it. [1] https://mailarchive.ietf.org/arch/msg/int-dir/bVH_0ydVdGssOiszJKhQXLYPuXY/?qid=4000f8a954b226266f429842911101f5 From nobody Mon May 8 21:20:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A7F126D46; Mon, 8 May 2017 21:20:29 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wtQvf31OpPJl; Mon, 8 May 2017 21:20:27 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD13120227; Mon, 8 May 2017 21:20:26 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id j29so66513719qtj.1; Mon, 08 May 2017 21:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fCmKcDZpuF3f2rnC9MuuGGMxUkuT+RHJ4vYbkUL3OKY=; b=bMAIkf2AiN+FMBfU8XLgGWhegEHEUQdRrFu9qBfyO+cVqd3qweHa8gBbDK1YAgzNTy NnvQikFePlgdl50/YyB3oE4fsiVddVWMoBx4qVXU1PPVLqYiFSIX6yIrPJ0dwWT89ef1 6SIb1SI5WyLFsx80YngGp2BBVhtuoaJgqKWh+0WLQyxIw12uhtDdG5toxBwClAJinrSu iIcbrMtnCUhKYNl/aXoXKdkXdZyKK+UgiSi2yRv5Wfd150FcfJ7hupSeKWxusf1lu8tD df5gLa7nGECurOg69Y224dj+XyQuctSP8GU4b9dVX59Zjvk5wyabVbT/SI3rYpBZE301 cWpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fCmKcDZpuF3f2rnC9MuuGGMxUkuT+RHJ4vYbkUL3OKY=; b=em6zC5WEhMk46jwIhLCYLxiDCAtx2dzXcxD5KpWMYnyrFz2Rp77QQRZzfjQzDqEkqE U2le39M/bTl4bu/ISvCjfspR1IYLsKRobsFsE9NSYg8YA+VVBhppHAdnv6hCUPdB/RxD cwC7gjCi/AszCyYDQQNq+6Ot6ndb9B0lo7qVcaUhqj4BUhRt9hF3qhMWrRqnocNi4QK+ mYPDldTfIhqZUuUdI+CsD53EatENOA1PHnM0WDb1LCD+M/W1uu52rxAaH9dpQePQGUXG /kKHMMoMrrAPvhLBjkX73EuSJizt858idVCiRMkq+OwhVw/HnUwRa5d3NlDAH/ooJfwD YOAg== X-Gm-Message-State: AN3rC/5XpVhcvCkx2Hj1xCNYb9LZGvYaXyOvpCzK5EZcqFqZkxdtIZZS HDSNGlpeUXfRmdCma+vUpvYUqKVTwg== X-Received: by 10.200.37.16 with SMTP id 16mr62181073qtm.293.1494303625969; Mon, 08 May 2017 21:20:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.81.66 with HTTP; Mon, 8 May 2017 21:20:25 -0700 (PDT) In-Reply-To: <149424843717.31731.1944317631050418426.idtracker@ietfa.amsl.com> References: <149424843717.31731.1944317631050418426.idtracker@ietfa.amsl.com> From: Suresh Krishnan Date: Tue, 9 May 2017 00:20:25 -0400 Message-ID: Subject: Re: Eric Rescorla's No Objection on draft-ietf-6man-rfc1981bis-06: (with COMMENT) To: Eric Rescorla Cc: The IESG , =?UTF-8?Q?Ole_Tr=C3=B8an?= , 6man-chairs@ietf.org, IPv6 List , draft-ietf-6man-rfc1981bis@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 04:20:30 -0000 Hi Ekr, Thanks for your comments. Please find responses inline. On Mon, May 8, 2017 at 9:00 AM, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-6man-rfc1981bis-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Document: draft-ietf-6man-rfc1981bis-06.txt > > OVERALL > I see in the shepherd's writeup that you have opted not to cite RFC > 2119, but that makes the mixed case use of SHOULD/MUST even more > confusing. I would suggest that at minimum you go through the document > and evaluate whether each should/must should be capitalized, though I > would prefer a cite to 2119. > > For instance: > changed. Therefore, attempts to detect increases in a path's PMTU > should be done infrequently. > > Is this normative? > > > I also share the concerns others have raised about whether, given the > actual state of PMTU this is something we should be making IS, but > I'm willing to bow to the majority here. This was certainly one of the things I considered. There is not too much measurement to back the claims that PMTUD is completely broken. The only reasonably sized study that I know of http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf shows about ~1% packet loss in ICMPv6 PTB messages compared to about 4-6% for ICMPv4 PTB messages. > > > S 3. > Note that Path MTU Discovery must be performed even in cases where a > node "thinks" a destination is attached to the same link as itself. > > I think you need to qualify this must because you just said above that > you don't need to if you use the minimum. Perhaps: > > Note that even when a node "thinks" a destination is attached to > the same link as itself, it might have a PMTU lower than the > link MTU... Sounds good. > > > S 4. > > Nodes SHOULD appropriately validate the payload of ICMPv6 PTB > messages to ensure these are received in response to transmitted > traffic (i.e., a reported error condition that corresponds to an > IPv6 > packet actually sent by the application) per [ICMPv6]. > > This seems like it ought to be a MUST. Is there a good reason why > it is not? Perhaps also a cite to how one validates. This is directly derived from Section 5.2 of RFC4443. "It is recommended that the upper layers perform some form of validation of ICMP messages (using the information contained in the payload of the ICMP message) before acting upon them." This was precisely the text that made me worried that this is adding a new requirement. As long as we stick to the requirement level of ICMPv6, we are OK. If we want to change this to a MUST, I think we need to demote this to Proposed Standard. > > > When a node receives a Packet Too Big message, it MUST reduce its > > a valid Packet Too Big message, I think because in graf 2 you say you > should validate. > > > elicit Packet Too Big messages. Since each of these messages (and > the dropped packets they respond to) consume network resources, the > node MUST force the Path MTU Discovery process to end. > > It's not clear to me what the requirement is. > > Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast > as possible. Nodes MAY detect increases in PMTU, but because doing > > Same thing, what are you requiring. How could I be nonconformant to > this? I see this as stating that detecting PMTU increases is optional and detecting PMTU decreases is mandatory. I agree that this text could be clarified > > S 5. > This section discusses a number of issues related to the > implementation of Path MTU Discovery. This is not a specification, > but rather a set of notes provided as an aid for implementers. > > However, this section contains a lot of normative language. Is that all > non-normative? Yes. That is the intention (no normative text here). > > > S 5.3. > If the stale PMTU value is too large, this will be discovered almost > immediately once a large enough packet is sent on the path. No such > mechanism exists for realizing that a stale PMTU value is too small, > so an implementation SHOULD "age" cached values. When a PMTU value > has not been decreased for a while (on the order of 10 minutes), the > PMTU estimate should be set to the MTU of the first-hop link, and > the > packetization layers should be notified of the change. This will > cause the complete Path MTU Discovery process to take place again. > > Is this really good advice for TCP? It seems like if you have a > situation where it required several attempts to get the true PMTU (for > instance, if you have successively narrower tunnels), then a PMTU > reset could have a pretty material impact on throughput. There is some TCP related implementation advice in Section 5.4. Basically, a TCP implementation will not send a packet larger than MSS received from the peer even if the PMTU is larger. > > > S 6. > 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. > > I get that this is now not a normative statement but rather a claim > about what nodes who follow the MUST NOT in S 4, but it might still > be better to make it a MUST to avoid confusion. How about s/should/will/? That leaves it as a statement of what the node does and not a normative statement. Thanks Suresh From nobody Mon May 8 21:54:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD48127B52; Mon, 8 May 2017 21:53:59 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 QS2uuy2QGI0Y; Mon, 8 May 2017 21:53:57 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 E35EF12778E; Mon, 8 May 2017 21:53:56 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id t26so51296680qtg.0; Mon, 08 May 2017 21:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SGvpAAflmqBHBI2yZeS/r+aPS/qzkFHGMP0FaCUAMwA=; b=pQz7f1PVePK6xYi+FWd+XR9n5J9puTZ4OwoixC1NJOxx2zgpvOr78aYwnWgHiCUwy5 tIGsGTiLoTeHtnoHPuLn+ZuZjfmfRe8fwdv2d7/usaFjbVSdjj60AgWUjho2xEoSG1v9 aDiOK5Bkk0YK3tNytzUGbLDb7iVgtSjW6k+zO1qqjTB0P9acmaqopEn/JW9IwxG4DiVF Ju2OIXymHq3N+0jxinK7reJyjeGt6La0UyrHLHMTo8b7zgEycWsvPHGhLfuPF+JPJxAM nKAuPRoe9wKklHRoteJx19VSLQM0hhVZLXwVUH9H57hq6lm/rsivxuSIED/JZmtSfSo6 WSOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SGvpAAflmqBHBI2yZeS/r+aPS/qzkFHGMP0FaCUAMwA=; b=YCBA9Y7eWYes5egR7cyVaqjypoQm4zawBJebGlkojEmUQLXd8gcF4hZGjZAIC9dOL4 I0HciGvHmHTYMir+rCLNIR1xq0i1E/TWLt2xrOrO/S3025yEb0tV9CdvOya1Vroyre0d ARLoMRXDdQY3HBDj7q0OO+v0XO4/N121WHsfJObUr2nmkNlv9xWKYkl4skHYpuwyFDVX +aZhMoxL+ni0yFvvKfQbq/wZAtA8A/VLvWwTdF21Rs2QHEv6nXb5ds7nnGVUyxkMJx0w 8bF1ZYuNdNWSPNnc0lyypoIPlkTvhNVPOhsBUeuYKpYJhvuGSkyXivP0MIzoVfFclZTD W3/Q== X-Gm-Message-State: AN3rC/5QL2k4qbuEXpSyI8APCnqAGbOUhRO3yc35CRavS1a7E5nXHhV8 Ab0mYBYRVCavw99Fcol9SQfpLdJiBg== X-Received: by 10.237.62.200 with SMTP id o8mr26072783qtf.152.1494305635916; Mon, 08 May 2017 21:53:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.81.66 with HTTP; Mon, 8 May 2017 21:53:55 -0700 (PDT) In-Reply-To: <149427050740.24107.6062280537375286614.idtracker@ietfa.amsl.com> References: <149427050740.24107.6062280537375286614.idtracker@ietfa.amsl.com> From: Suresh Krishnan Date: Tue, 9 May 2017 00:53:55 -0400 Message-ID: Subject: =?UTF-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf=2D6man=2Drf?= =?UTF-8?Q?c1981bis=2D06=3A_=28with_DISCUSS_and_COMMENT=29?= To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , =?UTF-8?Q?Ole_Tr=C3=B8an?= , 6man-chairs@ietf.org, IPv6 List , draft-ietf-6man-rfc1981bis@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 04:54:00 -0000 Hi Mirja, Thanks for the comments. I will let Bob comment on the DISCUSS points on the original text from 1981 as he might be able to provide more perspective. I just wanted respond to some of your comment points On Mon, May 8, 2017 at 3:08 PM, Mirja K=C3=BChlewind = wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-6man-rfc1981bis-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1) I agree with Ekr on this sentence: > "Nodes SHOULD appropriately validate the payload of ICMPv6 PTB > messages to ensure these are received in response to transmitted > traffic (i.e., a reported error condition that corresponds to an > IPv6 > packet actually sent by the application) per [ICMPv6]." > This sounds like it should be a MUST but I guess it depends on the upper > layer protocol if such a validation is possible or not, e.g. if > information are available that can be used for validation. Maybe you can > be more explicit here and even say something like pmtu discovery > should/must only be used if the upper layer protocol provides means for > validation of the icmp payload (like a sequence number in TCP)=E2=80=A6? > > Further also note that if the upper layer does the validation while the > IP layer maintains EMTU_S This is not the case. The upper layer maintains the EMTU_S. Also see my response to ekr that explains why this is a SHOULD instead of a MUST. > , there must be an interface from the upper > layer to the IP layer to tell if a packet is valid or not before the IP > layer updates the MTU estimate. This seems actually more complicated than > this one sentences indicates. > > 2) Also as Ekr says, I also have problems to fully understand this > normative text in section 4: > "After receiving a Packet Too Big message, a node MUST attempt to > avoid eliciting more such messages in the near future. The node > MUST > reduce the size of the packets it is sending along the path. Using > a > PMTU estimate larger than the IPv6 minimum link MTU may continue to > elicit Packet Too Big messages. Since each of these messages (and > the dropped packets they respond to) consume network resources, the > node MUST force the Path MTU Discovery process to end. > > Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast > as possible." > I especially don't understand the first part, given that a PTB message > may still indicate a MTU that is larger than the minimum link MTU which > then may cause another PTB message later on the path. This text reads > like if you receive one PTB message you should better end discovery and > fall back to the minimum link MTU to avoid any further PTB message and > not waist any resources. I don't think that's the intention and as such I > don't understand when it is recommended to end discovery here...? This talks about not increasing the size of the probe packet past the MTU received in the PTB message. I think this can be reworded if it is confusing. > > 3) Section 5.2 seems to be written with only single homed hosts in mind. > It might be good to advise that the pmtu information should always be > stored on a per interface basis...? OK. > > 4) Also section 5.2: > You only advise to store information per flow ID, however, if the flow > label is not used, wouldn't it make really sense to just use the 5-tuple > instead? Also note that EMCP is often done based on the 5-tuple or even > 6-tuple (with the ToS field). OK. > > 5) And more in section 5.2: > "When a Packet Too Big message is received, the node determines which > path the message applies to based on the contents of the Packet Too > Big message. " > MAYBE: > "When a valid Packet Too Big message is received, the node determines > which > path the message applies to based on the contents of the Packet Too > Big message." > And further on: > "If the tentative PMTU is less than the existing PMTU estimate, the > tentative PMTU replaces the existing PMTU as the PMTU value for the > path." > This doesn't cover the case where a pmtu probe with a larger size was > send and the PTB message returns a larger value then stored. Maybe state > this explicitly. > > This applies similar to this sentence in section 6: > OLD > "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.=E2=80=9C > NEW > "A node, however, MUST NOT raise its estimate of the > PMTU based on a Packet Too Big message that is not a (validated) > response to a PMTU probe that was previously send by this node, so should > not be > vulnerable to this attack." Sounds good. > > 6) Further section 5.2: > Should this statement be maybe upper case MUST: > "The packetization layers must be notified about decreases in the PMTU. > " As I said in my message to ekr this is not intended to be normative text. There is a general disclaimer in Section 5 that states "This section discusses a number of issues related to the implementation of Path MTU Discovery. This is not a specification, but rather a set of notes provided as an aid for implementers." Is there some text change that can help clarify the intent better? > > 7) Technical comment on section 5.3 in general: > There is a difference between aging if a flow is active or not. While I > maybe don't want to probe again for this connection because my > application already decided to use a mode where it can live with the > current pmtu and it's too much effect to switch, I really want to probe > at the beginning of the next connection again to check if I can use a > different mode now. While the IP layer does not have a notion of > connection it can observe if packets are frequently send with the same > 5-tuple and reset the cached pmtu after a certain idle time. Can you suggest some text? > > 8) Section 5.4: should this maybe be normative, at least the last MUST > NOT (be fragmented): > "A packetization layer (e.g., TCP) must track the PMTU for the path(s) > in use by a connection; it should not send segments that would > result > in packets larger than the PMTU, except to probe during PMTU > discovery (this probe packet must not be fragmented to the PMTU). " Same as #6 above. Section not intended to be normative. > > > Nit: > The abbreviation PTB is only used once in section 4 (and never expanded). Sounds good. This needs to be expanded. Regards Suresh From nobody Mon May 8 21:54:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388AF129AC4; Mon, 8 May 2017 21:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yU5P-4dov4Z; Mon, 8 May 2017 21:54:19 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 BF18C129ABE; Mon, 8 May 2017 21:54:14 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id y201so37167756qka.0; Mon, 08 May 2017 21:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tUoiCLjVJlAGSLurISkfdEJ8jDmAXMTAYPQh9ndB3VE=; b=jVQQOct8KLji6FKi4UGXhCsudX9ZYUWD+7V/0jzE0x30ygWL213GCaEyZXwZIKpgJk +TnkSp2PejweyfUwDGD9oEFEZVAxwEUGOMvZ1m57JI9HAtpVvE+Bcp/Tku2eDBbF8oyc PCtHVAfYJU6iC+z4gQt6S4LWPWgedI6gmA83mzFSSmKC4J9EboENNZrVXHcA8KpV1a3I WtTWoQcpl48BcGnqi1wqos3hK40b/cz9t7ot689XlKk4QGztaAI+5aEejSCLdTkm2s8h /LRQHraJ9cF+J+SaqAD1cMCW88jbNQKQO9rcybPFKdzdoafiFtKzrfJFIoECd0g8/1+7 xK0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tUoiCLjVJlAGSLurISkfdEJ8jDmAXMTAYPQh9ndB3VE=; b=lM0FhL/qo/vIaCzMIFSvOcTwe/LM2k6vYOop+/La+8DdhosCi3Q89rHaR6Jjv8+52M aehw8K+LHGbRavlk9zZd6smGezYfveW3ff9IrdqTeb9c+F5SLtFIZTlHkMpHpPUUoUkC +6OshnJsVagXjyeKVSK+I1iqBMmL08Pbr503wNJj+W8Qo7ZLFIK8yGCjeFxWbPKq1wR6 w4wDthpf8TiS1/nH12V4tPeAF7UKkG5je7fR4Pxc2TdCydJ8mYKqJXdAzKP36ppFZ7bi b7Jo5Q1+nboM0ANzyyc1J0eiBCeXOQvHAdBoa2p3G07luph4LSN1UdQFr82u5VS0dM1V kWNw== X-Gm-Message-State: AODbwcBo0B8QxEgVQ4GLkAiulGpFYm7QBwci+P6/TsPkuq2P8f/Fmfc9 DArcGQ+RxaCEQRtr2IKHFbvcoe0uL2x4 X-Received: by 10.55.104.66 with SMTP id d63mr26873526qkc.260.1494305653838; Mon, 08 May 2017 21:54:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.81.66 with HTTP; Mon, 8 May 2017 21:54:13 -0700 (PDT) In-Reply-To: <149427694020.22664.10344820301651708437.idtracker@ietfa.amsl.com> References: <149427694020.22664.10344820301651708437.idtracker@ietfa.amsl.com> From: Suresh Krishnan Date: Tue, 9 May 2017 00:54:13 -0400 Message-ID: Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS) To: Alvaro Retana Cc: The IESG , Ole Troan , 6man-chairs@ietf.org, IPv6 List , draft-ietf-6man-rfc1981bis@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 04:54:32 -0000 Hi Alvaro, On Mon, May 8, 2017 at 4:55 PM, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-6man-rfc1981bis-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm putting in this point as a DISCUSS because I think that the current > text may be confusing and vague. > > As others have pointed out, this document includes rfc2119-like language, > both capitalized and not. I realize that rfc1981 was published before > rfc2119 and that no expectation on the language existed then. However, > we're at a point in time where not only rfc2119 is in place, but > draft-leiba-rfc2119-update (which clarifies that only uppercase language > has special meaning) is in AUTH48. I think that this leads to the > possibility that the average reader may interpret the requirements in > this document in a way that it wasn't intended. > > While I would prefer that this document be consistent (and either use > capitalized rfc2119 language as intended, OR, not used it at all), I > understand the intent of not changing some of the original text. I would > be happy with a note like this one: "Note: This document is an update to > RFC1981 that was published prior to RFC2119 being published. > Consequently while it does use "should/must" style language in upper and > lower case, the document does not cite the RFC2119 definitions. This > update does not change that." [I borrowed this text from the the INTDIR > review thread. [1]] I am personally fine with including this text in the draft, but I would like the editor, the shepherd and the WG to chime in as well. Thanks Suresh (The editor is traveling on an intercontinental trip today and might take some time to respond) From nobody Mon May 8 21:54:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A9212778E; Mon, 8 May 2017 21:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_TmUbX1oM3K; Mon, 8 May 2017 21:54:48 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 12B38129AB6; Mon, 8 May 2017 21:54:48 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id a72so53493378qkj.2; Mon, 08 May 2017 21:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5RQaoo5DX+Q4QRu2VkyzIi0nDS55B0BKk3Gd//jUJWc=; b=fT4FKGGWyhspF1b4sgfenCiosUlxZtGoXnM5qwtYbiJo6hYlSyWTpPB0Y6/lV75S/v WdBC8bc431PUZeEQgBo5xIDBzt2LgVBBb7aCQTbl8OQh+ENnXGiUhS1kl3Kk9YTe5pLb mnBY7/9Spv1LBvEuD1LBk3n0dSq92/ghfrmLsvFy077qLp75NN/FWBFiCHdjDAhCcYz0 QAjakuDJXSxcTezTVdG+UjBgn9P0w2wZwReJJl+pjaitDtIRIMilj4RMhldM15CdxgN2 pcKY2+pOh2z1XZ3pf5iz18vFfQ9tRdwT5BFwvBGtxLE2lD0lFE2fKmFctuvBLVvffXyl ppgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5RQaoo5DX+Q4QRu2VkyzIi0nDS55B0BKk3Gd//jUJWc=; b=LhrO9x7G4v2uh2NTEh4Z1wufpnQcAp+Glwk8oKpyhQkTly1nhAgpD6Gtmyjnc404k4 /sAYfypLDBYzZnKEy6C126OSJipoX44SPP/vCOXcA5QBfQsLSJO55Y0rdvAauXpEOCpi Zys/M5IMHlsZ4GxezVBcVGvzN+gpwBbmyyGnHTmDc1EoFx9h5J4Hhibebw9Bc98iht4j Z5jkyFUnM/9vnRD3km41wc4M5ligbyHVC+3QXVITLgNcbsLfehL2UwTl5cnwhstiMrE/ OrauyoZfdEn06LfFLV7AHjWkXA6NXn7c/HXgedFmWci0USBm++B/z/FhfObWOn2cAPuv k6Hg== X-Gm-Message-State: AN3rC/6V7UZHVEcpxFEFu3ighuxsQq4qajLFyd++fBkT7VdAE58RWB1m IdoAiKWYrPQfNbECpqmtGQktawAZmQ== X-Received: by 10.55.165.85 with SMTP id o82mr26731240qke.82.1494305687140; Mon, 08 May 2017 21:54:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.81.66 with HTTP; Mon, 8 May 2017 21:54:46 -0700 (PDT) In-Reply-To: <149427371611.7824.6370727830803946449.idtracker@ietfa.amsl.com> References: <149427371611.7824.6370727830803946449.idtracker@ietfa.amsl.com> From: Suresh Krishnan Date: Tue, 9 May 2017 00:54:46 -0400 Message-ID: Subject: Re: Warren Kumari's No Record on draft-ietf-6man-rfc1981bis-06: (with COMMENT) To: Warren Kumari Cc: The IESG , =?UTF-8?Q?Ole_Tr=C3=B8an?= , 6man-chairs@ietf.org, IPv6 List , draft-ietf-6man-rfc1981bis@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 04:54:56 -0000 Hi Warren, Thanks for your comments. Please see responses inline. On Mon, May 8, 2017 at 4:01 PM, Warren Kumari wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-6man-rfc1981bis-06: No Record > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [ Reminder to myself - I'm leaving this as No Record while looking > more... ] > > I sent email about this to the authors on Feb 23rd - I seem to still have > have many of the same questions... > > Comments: > 1: Sec 1: "Path MTU Discovery relies on such messages to determine the > MTU of the path." > -- it is unclear which "such" refers to. Perhaps s/such/ICMPv6/ (or > PTB). This was new text added in the -bis document. In the context of the sentence (regarding ICMPv6 filtering leading to black hole connection) I think ICMPv6 works better than singling out PTB. > > 2: Sec 3: "Upon receipt of such a message, the > source node reduces its assumed PMTU for the path based on the MTU > of > the constricting hop as reported in the Packet Too Big message" -- > this says that it reduces it *for the path*. But (as somewhat alluded to > later in the draft) the nodes doesn't know what the path *is* -- it can > decrease for the destination, or flow, or even interface, but (unless it > is strict source routing) it doesn't control or really know the path (see > also #4) Right. This is explored further in Section 5.2 " However, in most cases a node will not have enough information to completely and accurately identify such a path. Rather, a node must associate a PMTU value with some local representation of a path. It is left to the implementation to select the local representation of a path." Would you like some additional text in this section? > > 3: Sec 4: "The recommended setting for this timer is twice its minimum > value (10 minutes)." - as above. This was from 1996 - were these metrics > discussed at all during the -bis? I suspect that the average flow is much > shorter these days (more web traffic, fatter pipes, etc) and so a flow of > 10 minutes seems really long (to me at least). AFAIK, there was no discussion regarding this number. I have a hard time seeing how this number relates to the (shortened) length of the flow, though. > > 4: Sec 5.2: "The packetization layers must be notified about decreases in > the > PMTU. Any packetization layer instance (for example, a TCP > connection) that is actively using the path must be notified if the > PMTU estimate is decreased. > Note: even if the Packet Too Big message contains an Original > Packet Header that refers to a UDP packet, the TCP layer must be > notified if any of its connections use the given path." > - this is related to #2 -- I don't know *which* path my packets take - > once I launch them into the void, they may be routed purely based upon > destination IP address, or they may be hashed based upon some set of > header fields to a particular ECMP link or LSP. Once packets hit a load > balancer, it is probably even *likely* that the UDP and TCP packets end > up on different things. So, if I get a PTB from a router somewhere, I can > probably guess that other packets to the same destination address will > also follow that path, but I cannot know that for sure. I'm fine to > decrease MTU towards that destination IP, but is that what this is > suggesting? If so, please say that. If not, please let me know what I > should do. The above is even more tricky / fun when I'm using flow id as > the flow identifier -- if I get a PTB for flow 0x1234, what do I do? Yes. You are right. Any out of band mechanism for probing the MTU will likely end up having the same problem if the probe packets are treated differently from the payload packets by the load balancers and other middleboxes. > > 5: Sec 5.3: "Once a minute, a timer-driven procedure runs through all > cached PMTU values, and for each PMTU whose timestamp is not "reserved" > and is older than the timeout interval ...". Please consider providing > clarifications here. The wording implies that I should set a timer to > fire on the minute, and trigger the behavior. If all of the (NTP synced!) > machines in my datacenter do this, and all try send bigger packets (on > 1/10th of long flows) their first hop router will get many, many > over-sized packets and it will severely rate-limit the PTBs. I am not sure why the first hop router will send PTBs. At timer expiry, the PMTU estimate will only be set to the MTU of the first-hop link and hence the first hop router should be able to handle this, no? > > > Nits (Some of these are purely academic.) > I understand that you are trying to limit the changes, so feel free to > ignore these: I will let the editor chime in on these. Thanks Suresh From nobody Tue May 9 00:46:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEE1129B23 for ; Tue, 9 May 2017 00:46:14 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mAm2GIq2gQhW for ; Tue, 9 May 2017 00:46:13 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 C5496129B21 for ; Tue, 9 May 2017 00:46:12 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id l9so62368423wre.1 for ; Tue, 09 May 2017 00:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=sz6GgLeuN6Z13dOqPw4ezvFpl1Q3VegQnAJ7dGKdQQI=; b=kJVdExVZ6+/z0mSpBN3FbUZX+KkaUuRble4ipHxIF9zRVNmFZzhZgaebVnQ5pEzq4g aycIgXdpZTRrDItCT5Omy2OuQpbHS4AFQoXj74dnc6C2+OvGq3Og9oucP3g04RY9dukw JfUacFlOX39N2915IBqfqiVZLsjVGEBuIGOkRMGytbaz979Rixrptu3OpT+a5DDCMiZL l9/CCsLcMSQKq/fSTIvXFbeAj6qD+/fKfT0FFAhKK1djaG8TVit1ePADyjI+8rE7BV+3 ei6w8Ht6lumOVfNHEy7YwshPdp+mTn3/riWz/jEOpTP2p03ShCSmJp0Zn6d1e2lkFWP6 z7rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=sz6GgLeuN6Z13dOqPw4ezvFpl1Q3VegQnAJ7dGKdQQI=; b=teFws4Wh6iF+QiG3bWdZpvunbrI1bulZueI3yHGRcVTi31JidkG1PlPQehFLdanZaq HKGY6tRYncdyRcocYPTARwSGDmkEOY8dVoZxIFUV0cZmLfUTU9NPPsHGFOJ+AApaNVLb +LV6lgc5mm4zPXFx7qLsPWpplDEn3kQlrTNmvB1pJmbCTpx9qqSHD4SUkAnMx3AHRbqm oV2dofh7M7nRZGBIgEVtlYr4zLR4kkCynpsGUT8LkC01BraF4r4ZyjNovPnZo+priIQ+ QEYGt7IA7VVMmoG3OhbT3+0Wa6zQpnNh+OglR/tcqmQ9W4LwCJ/fxoZj6O8rJX+hQX93 KDyw== X-Gm-Message-State: AN3rC/6k32PI+ej6vhXHJP11f2d1WlYalf7z/5UP/xLjnX6yOjP9k+Su CFnBf4YNZT4VpQ== X-Received: by 10.223.161.30 with SMTP id o30mr40199887wro.186.1494315971336; Tue, 09 May 2017 00:46:11 -0700 (PDT) Received: from [172.24.226.96] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id n99sm18026012wrb.62.2017.05.09.00.46.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 00:46:10 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_B27234EC-E656-485D-B8A4-A6655870C63E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Your Discuss on (2017-05-08) on rfc2460bis Message-Id: <26E4EEA9-3556-4BE4-BD4D-69A820866E24@gmail.com> Date: Tue, 9 May 2017 10:46:03 +0300 Cc: Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= , Suresh Krishnan , IPv6 List To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 07:46:14 -0000 --Apple-Mail=_B27234EC-E656-485D-B8A4-A6655870C63E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mirja, > Mirja K=C3=BChlewind >=20 > Discuss (2017-05-08) >=20 > Thanks for addressing my discuss. Text on rfc3168 is fine! I'm also = okay with the text on extension headers, however, I have one remaining = processing question: Now the text uses similar but not the same wording = as RFC6564. RFC6564 says "new IPv6 extension headers MUST NOT be created = or specified, ..." and this draft says "Defining new IPv6 extension = headers is not recommended, ..." in not normative language. Is that on = purpose? Does this draft need to absolete RFC6564 or refer or whatever? Thanks for clearing your other discusses. I assume you are referring to the last paragraph in Section 3 of = RFC6564: Mindful of the need for compatibility with existing IPv6 deployments, new IPv6 extension headers MUST NOT be created or specified, unless no existing IPv6 extension header can be used by specifying a new option for that existing IPv6 extension header. Any proposal to create or specify a new IPv6 extension header MUST include a detailed technical explanation of why no existing IPv6 extension header can be used in the document proposing the new IPv6 extension header. With my editor=E2=80=99s hat on I choose the current language for two = reasons. The text above has MUST NOT followed by an =E2=80=9Cunless=E2=80= =9D clause. More like a should. The use of the word =E2=80=9Crecommends= " matches the style of the document where =E2=80=9Crecommend=E2=80=9D is = used in a number of places in the document. I think the intent of the = text is very clear. The w.g. choose to not obsolete RFC6564 (or the other updating RFCs) = because they provide additional background on why the updates that were = made. This is useful and is not obsoleted. Hope this resolves the issue you are raising. Thanks, Bob --Apple-Mail=_B27234EC-E656-485D-B8A4-A6655870C63E 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 iQEcBAEBCgAGBQJZEXO7AAoJEK7rdBF357uo1wAIAJzTR7r4CfCHRgPbWskVyi0o k5yjA7lEG/AZfCN0YCKAIJD2qAErApXhmvJN8s0QojaDSNiJCQ8Z+cV3nPcnzh+7 6/43hFcC6WVos2Xp4CzlFxpQIzVDfFaH0yhmyTvpj7ln/WSMXUSBh0rNxRLAUoul WWeOvviJaOVwGWZ+aXmz1lAl1fWnHbzId5WUsVY6y+NuMtUeJaLdjMAOkAntCfu2 exX3CHGTx2pw06r+ykZcwf7mmRSI40zH+DaT+dFrTA+wC/B2o99kfbbf7yHkZn8Z OlfofTJvxFO+koIF+bG2DK6PZC6viNHrBsVKj3rXyHpUUAsSzt/ZiJj+mGJqq5A= =aBfg -----END PGP SIGNATURE----- --Apple-Mail=_B27234EC-E656-485D-B8A4-A6655870C63E-- From nobody Tue May 9 01:29:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0345E1252BA; Tue, 9 May 2017 01:29:44 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lYxPCq0R3rbN; Tue, 9 May 2017 01:29:35 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09AE120724; Tue, 9 May 2017 01:29:34 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id z52so63353689wrc.2; Tue, 09 May 2017 01:29:34 -0700 (PDT) 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=i4yEoKpQiIKcwfCmaZPvN44qDWMt3Yh2WdC117h9yg0=; b=aV4XmqEShZSvo/vjFeSu+MpTwQbyPzKfyq58Mt3y+vVPJL5DIJ9ZuxP+WV5CMg7IEJ QwKQFNcgOPvY+CgdwIxSCksqFaHRlFSRQfOIAFxORBNavovGr0r+do90BYs7GDMrZ6c7 wl2EuYykkF/TH+WCfOP769gb5liEpYh6Pqc373xTTBYVA1HACP4i0UJHcjBR2y1CYaDY sBzocfpW9ocwXwk6ZaT/bVWJdH4eCUICgy7wI1hPDGAjyr6aUw59O4RbSQea7iSxVuj3 xBr1GY4A12sNkVHyP/YAg82Yd9djHFASQCof8oACL0kFSECgdHdEvJaCkAEhRmZPxizM JYrw== 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=i4yEoKpQiIKcwfCmaZPvN44qDWMt3Yh2WdC117h9yg0=; b=UXFoRnEIteVTBa09hUkZzbFE0EwxUjnHFLg0fd3UK6/p14Y8qoJ2uEMlf6uwTEqpyU PFdv4pfSL74sHymqkkD8BBFmwt9Sp6kMdfQnEKCl4D59LAMGNI7hX6N+8zD06Gfd5W4P 7X0uT1H+xTScyYHcJG8wBf60RnyFZyoH4aGtnxjVHotC8OVeQlEM19othfmmTeXIlYkH j26xJqLKC+fxCRs2qQN1vMIwtSx0Wi2kIJJ/ui5uFeFQiv+rwFr03fgfFTDxgBYef8+E 1kyPX40gfpjZmo1zzGgFvWDWz3g0IhAuQ2eY9oiZW+5oOczXbGdj7HSNDK08rwhKtGew QfGQ== X-Gm-Message-State: AN3rC/4sWmfOH2Y7iwTMmEWLyrFoD03EiG7WVMdV4U+wbFC9gInfSf1n hI9bOLsBMJKyhQ== X-Received: by 10.223.166.66 with SMTP id k60mr41473059wrc.139.1494318573527; Tue, 09 May 2017 01:29:33 -0700 (PDT) Received: from [172.24.226.96] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id f2sm14759203wmh.27.2017.05.09.01.29.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 01:29:32 -0700 (PDT) From: Bob Hinden Message-Id: <30DE42CC-FFBC-40A7-BE30-4044083B39C7@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_986C8E01-55F7-4C6C-94A9-6C092C402603"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS) Date: Tue, 9 May 2017 11:29:28 +0300 In-Reply-To: Cc: Bob Hinden , Alvaro Retana , IESG , =?utf-8?Q?Ole_Tr=C3=B8an?= , 6man Chairs <6man-chairs@ietf.org>, IPv6 List , draft-ietf-6man-rfc1981bis@ietf.org To: Suresh Krishnan References: <149427694020.22664.10344820301651708437.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 08:29:44 -0000 --Apple-Mail=_986C8E01-55F7-4C6C-94A9-6C092C402603 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Suresh, > On May 9, 2017, at 7:54 AM, Suresh Krishnan = wrote: >=20 > Hi Alvaro, >=20 >=20 > On Mon, May 8, 2017 at 4:55 PM, Alvaro Retana = wrote: >> Alvaro Retana has entered the following ballot position for >> draft-ietf-6man-rfc1981bis-06: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> I'm putting in this point as a DISCUSS because I think that the = current >> text may be confusing and vague. >>=20 >> As others have pointed out, this document includes rfc2119-like = language, >> both capitalized and not. I realize that rfc1981 was published = before >> rfc2119 and that no expectation on the language existed then. = However, >> we're at a point in time where not only rfc2119 is in place, but >> draft-leiba-rfc2119-update (which clarifies that only uppercase = language >> has special meaning) is in AUTH48. I think that this leads to the >> possibility that the average reader may interpret the requirements in >> this document in a way that it wasn't intended. >>=20 >> While I would prefer that this document be consistent (and either use >> capitalized rfc2119 language as intended, OR, not used it at all), I >> understand the intent of not changing some of the original text. I = would >> be happy with a note like this one: "Note: This document is an = update to >> RFC1981 that was published prior to RFC2119 being published. >> Consequently while it does use "should/must" style language in upper = and >> lower case, the document does not cite the RFC2119 definitions. This >> update does not change that." [I borrowed this text from the the = INTDIR >> review thread. [1]] >=20 > I am personally fine with including this text in the draft, but I > would like the editor, the shepherd and the WG to chime in as well. I am fine with including a note like this in this document. Bob >=20 > Thanks > Suresh >=20 > (The editor is traveling on an intercontinental trip today and might > take some time to respond) --Apple-Mail=_986C8E01-55F7-4C6C-94A9-6C092C402603 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 iQEcBAEBCgAGBQJZEX3pAAoJEK7rdBF357uoF1kH/3ZXJNHoszAyGO60z187NvzC FCoD/pZuhMf8AFCZSDbnAQFWVgGlYE2DKsfWyJ7V/hGfs9rlnAwz7PJgSf0dsRw0 LVnGMvCJS2j/Y/6Pz43FAZ3F1rNg8Tyrh7HsNIWER+t7LpzDImP5qKCEtD/xZckZ LxkkVNv3zZaXDoHh1JeTt0YIbeyIltxhE3IuetJbAyiBR19mNJ/QWs8Mnor/om+9 ki83+Um1hmBxBmSVmAK1EokcSGaVJBmRbIuFJzgH3/VI4xvNPaNLfkazMqqldaAx nfjPUf7rfDHVljR94iLtDZFs8bZit69AFDjGPp8VIbSJfnMzcswarzoMHhkabWA= =pG0R -----END PGP SIGNATURE----- --Apple-Mail=_986C8E01-55F7-4C6C-94A9-6C092C402603-- From nobody Tue May 9 02:46:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0708129BAB for ; Tue, 9 May 2017 02:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3V3Qge6QwgE for ; Tue, 9 May 2017 02:46:20 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 3B50D129409 for ; Tue, 9 May 2017 02:46:20 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id g49so69063912uaa.1 for ; Tue, 09 May 2017 02:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1O//fRd+H191gaSMMeuo8XHFE/AfP2B42gNd8EApPew=; b=bEoBxSaeOygFEBjC7DnKoEsRXygoPpHFiNltwDosBEnjyVihxrMsFRqPYPKGGKEmET +UAX3R+Xpr4deNzW82O4VfemcJ8OVUgJKhlP/dxejIDLaorFeYjgatKjZbtK455f6hCI jITqt5azezmBZluFaOuh+nd/YtXmaWAV+zkp7jzf5vRzt6cY/HTL1CDtwnNzDk2H3YrS dUp9/740r2Fg7FZGJKPJnF7kO6OtWjucZD942Biz/jWYRNhBFXYDeO8ntKBJFBLIjO5F yHajZvDODLBm2Vy4qzu/u1iGnomCzhBnpePT3nxXIO00EJFz3vrXtHaNxHhmId1xxKQM dLrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1O//fRd+H191gaSMMeuo8XHFE/AfP2B42gNd8EApPew=; b=ZLuLLDuHH2brtaTgO8JTfoScud+9nPjslESOobpJlId/4AglEB3og65rdqNiQyL8yM id3GlF2BQ/n1nPDRfy4/JQLLl4N2uOb71n9A4WNRLcgUVyAZdyTvay1h3wT9AuySFUOm ABXYLu4dYCIYBzfbjFhvxAUbSCWlyexsX1TPtqgvIwPuiwRrNCqP+hTBy1V35RaUgzst h3Y5lE3CZ45wuCvhrBtYQirRzE5j1CgFuJ+h/1s7lCmexbE94nBOWM4AMGl3IVfek6yb VxRakmTw5NWBSxWDaJ+zlvb6hWCYxOnASjiBXdXFdPXg+hUH+ut3zIrjFtQmnxdBbVYQ mkYQ== X-Gm-Message-State: AN3rC/5HbCoASsJAYvo1+zBurjpZti5iY7vZ6DHTmVbaNfTjoe1hbvBB 5A2ICZwUpgIhrY4ZvaETmVK2k52YN6yj X-Received: by 10.31.154.194 with SMTP id c185mr26984923vke.35.1494323179121; Tue, 09 May 2017 02:46:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.71.83 with HTTP; Tue, 9 May 2017 02:45:38 -0700 (PDT) In-Reply-To: References: <149427371611.7824.6370727830803946449.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Tue, 9 May 2017 05:45:38 -0400 Message-ID: Subject: Re: Warren Kumari's No Record on draft-ietf-6man-rfc1981bis-06: (with COMMENT) To: Suresh Krishnan Cc: The IESG , =?UTF-8?Q?Ole_Tr=C3=B8an?= , 6man-chairs@ietf.org, IPv6 List , draft-ietf-6man-rfc1981bis@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 09:46:22 -0000 On Tue, May 9, 2017 at 12:54 AM, Suresh Krishnan wrote: > Hi Warren, > Thanks for your comments. Please see responses inline. > > On Mon, May 8, 2017 at 4:01 PM, Warren Kumari wrote: >> Warren Kumari has entered the following ballot position for >> draft-ietf-6man-rfc1981bis-06: No Record >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> [ Reminder to myself - I'm leaving this as No Record while looking >> more... ] >> >> I sent email about this to the authors on Feb 23rd - I seem to still hav= e >> have many of the same questions... >> >> Comments: >> 1: Sec 1: "Path MTU Discovery relies on such messages to determine the >> MTU of the path." >> -- it is unclear which "such" refers to. Perhaps s/such/ICMPv6/ (or >> PTB). > > This was new text added in the -bis document. In the context of the > sentence (regarding ICMPv6 filtering leading to black hole connection) > I think ICMPv6 works better than singling out PTB. Yup, WFM. > >> >> 2: Sec 3: "Upon receipt of such a message, the >> source node reduces its assumed PMTU for the path based on the MTU >> of >> the constricting hop as reported in the Packet Too Big message" -- >> this says that it reduces it *for the path*. But (as somewhat alluded to >> later in the draft) the nodes doesn't know what the path *is* -- it can >> decrease for the destination, or flow, or even interface, but (unless it >> is strict source routing) it doesn't control or really know the path (se= e >> also #4) > > Right. This is explored further in Section 5.2 > > " However, in most cases a node will not have enough > information to completely and accurately identify such a path. > Rather, a node must associate a PMTU value with some local > representation of a path. It is left to the implementation to select > the local representation of a path." > > Would you like some additional text in this section? > I don't really know -- I have a weird feeling that the document is explicit about what you must do under certain circumstances, but then handwaves away the fact that you cannot really tell. I think that it would be helpful to point at Sec 5.2 from here. >> >> 3: Sec 4: "The recommended setting for this timer is twice its minimum >> value (10 minutes)." - as above. This was from 1996 - were these metrics >> discussed at all during the -bis? I suspect that the average flow is muc= h >> shorter these days (more web traffic, fatter pipes, etc) and so a flow o= f >> 10 minutes seems really long (to me at least). > > AFAIK, there was no discussion regarding this number. I have a hard > time seeing how this number relates to the (shortened) length of the > flow, though. It's fine if it wasn't discussed (these are just comments), but my thinking goes: In 1996 I beleive that average flows were much longer and so flows would actually hit the 10 minute timer and attempt to increase the increase MTU process, but these days, with much shorted flows, you will hit it much less often. Also, in 1996 a 45Mbps DS3 / T3 was fast. If I started transferring a large file and my first few packets went down a pipe with a 1280byte MTU path, which then changed to a path with 1500bytes, after 10 minutes I would have transferred ~3.3GB, and 2.6million packets., for a "wastage" of 580MB (2.6m * (1500 - 1280)). On a 10GE, in the same situation, after 10 minutes I would have transferred 750GB and 585million packets, for a "wastage" of almost 13GB. (Note: Back of the envelope calculations, may have missed a zero somewhere) > >> >> 4: Sec 5.2: "The packetization layers must be notified about decreases i= n >> the >> PMTU. Any packetization layer instance (for example, a TCP >> connection) that is actively using the path must be notified if the >> PMTU estimate is decreased. >> Note: even if the Packet Too Big message contains an Original >> Packet Header that refers to a UDP packet, the TCP layer must be >> notified if any of its connections use the given path." >> - this is related to #2 -- I don't know *which* path my packets take - >> once I launch them into the void, they may be routed purely based upon >> destination IP address, or they may be hashed based upon some set of >> header fields to a particular ECMP link or LSP. Once packets hit a load >> balancer, it is probably even *likely* that the UDP and TCP packets end >> up on different things. So, if I get a PTB from a router somewhere, I ca= n >> probably guess that other packets to the same destination address will >> also follow that path, but I cannot know that for sure. I'm fine to >> decrease MTU towards that destination IP, but is that what this is >> suggesting? If so, please say that. If not, please let me know what I >> should do. The above is even more tricky / fun when I'm using flow id as >> the flow identifier -- if I get a PTB for flow 0x1234, what do I do? > > Yes. You are right. Any out of band mechanism for probing the MTU will > likely end up having the same problem if the probe packets are treated > differently from the payload packets by the load balancers and other > middleboxes. Yup. This is related to the #2. The definition of "path" is very vague - if I use flow id as my path representation, how do I know what else to notify? I think that this should have some better description of what exactly I adjust if I get the PTB... If this were a new protocol, which wasn't already implemented basically everywhere, I'd say that this needs to be much much clearer and more specific -- but, the fact that there are already implementations which a: work, and b: new implementations can look at means that I'm not too fazed about this... > >> >> 5: Sec 5.3: "Once a minute, a timer-driven procedure runs through all >> cached PMTU values, and for each PMTU whose timestamp is not "reserved" >> and is older than the timeout interval ...". Please consider providing >> clarifications here. The wording implies that I should set a timer to >> fire on the minute, and trigger the behavior. If all of the (NTP synced!= ) >> machines in my datacenter do this, and all try send bigger packets (on >> 1/10th of long flows) their first hop router will get many, many >> over-sized packets and it will severely rate-limit the PTBs. > > I am not sure why the first hop router will send PTBs. At timer > expiry, the PMTU estimate will only be set to the MTU of the first-hop > link and hence the first hop router should be able to handle this, no? Nope - example scenario... =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 .=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80. =E2=94=8C=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 Computer =E2=94=82=E2=94=80=E2=94=80MTU:1500=E2=94=80=E2=94=80= =E2=94=80=E2=96=B6( Router )=E2=94=80=E2=94=80MTU:1400=E2=94=80=E2=94=80= =E2=96=B6 "Internet" =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98 `=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80' =E2=94=94=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=98 The outgoing interface from my router is 1400 bytes. This means that every connection will get back a PTB when it tries to reach the internet - I *should* change the default MTU on my machine, but, well, I'm a user... In many scenarios the lower MTU will be close to the sending machine - if you synchronize the "try redo PMTUd" you run the risk of spikes. Many machines (like my Apple laptop) are now NTP synced - even if the MTU bottleneck is far away, when everyone tries to use 1500byte packets at the same time, whatever device has a smaller MTU will have a bad day... W > >> >> >> Nits (Some of these are purely academic.) >> I understand that you are trying to limit the changes, so feel free to >> ignore these: > > I will let the editor chime in on these. > > Thanks > Suresh --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue May 9 05:07:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A9B128CFF for ; Tue, 9 May 2017 05:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EkjFFQdrklk for ; Tue, 9 May 2017 05:07:36 -0700 (PDT) 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 985CB127868 for ; Tue, 9 May 2017 05:07:36 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 7A7CF1B014E6; Tue, 9 May 2017 15:02:24 +0100 (BST) Message-ID: <5911B0EE.6080802@erg.abdn.ac.uk> Date: Tue, 09 May 2017 13:07:10 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: ipv6@ietfa.amsl.com CC: Gorry Fairhurst , ietf@kuehlewind.net Subject: Fwd: Re: DISCUSS's on rfc1981bis - MK Comments References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 12:07:40 -0000 Thanks for the comments. I helped Bob with some of the new text and so have some comments. See below, my comments are marked "GF". I think we can prepare a new rev. to address most of these. Gorry -------- Original Message -------- > On May 9, 2017, at 12:24 PM, Gorry Fairhurst wrote: > > On 09/05/2017, 09:35, Bob Hinden wrote: >> Joe, Gorry, >> >> There are some new discusses on rfc1981bis. See: >> >> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ballot/ >> >> I think the one from Alvaro is resolved. >> >> I would like your input on the one from Mirja. There are also comments from ekr and Warren. >> >> Thanks, >> Bob >> >> > > I know this is a bis document and my discuss does not address any text that changed in the bis version but given all previous discussion, I would like to discuss the following text parts on statements regarding retransmissions which don't seem to be appropriate for this document and are partly even wrong. > In general it does not make a lot of sense to talk about retransmission semantics in this document because this really depends on the upper layer protocol, and I'm really not sure if any implementaiton of a reliable transport does send retransmission based on the receptions of PTB messages (if exposed) rather than only relying on it's own loss detection mechanism. This discuss concerns a few sentence all over the document and most parts of section 5.4. Details proposals below: > GF: We already removed most of this, and we can remove more. > > I propose to either remove this sentence, or at least reword to the following (or something similar): > OLD: > "Retransmission should be done for only for those packets that are > known to be dropped, as indicated by a Packet Too Big message." > NEW: > "The IP layer may indicate loss to the upper layer protocol of those packets that are > known to be dropped, as indicated by a Packet Too Big message." > Or MAY or SHOULD or MUST...? > GF: I'd prefer to remove, rather than replace. This new text isn't helping me. > ---- > Subsequently the following sentence should be removed as well: > "An upper layer must not retransmit data in response to an increase in > the PMTU estimate, since this increase never comes in response to an > indication of a dropped packet." > GF: I have no problems with this sentence being in the document, but I do not think this is important, and deleting this is also fine with me. > ---- > And here is the bigger change in section 5.4: > OLD > "When a Packet Too Big message is received, it implies that a packet > was dropped by the node that sent the ICMPv6 message. It is > sufficient to treat this in the same way as any other dropped > segment, and will be recovered by normal retransmission methods. If > the Path MTU Discovery process requires several steps to find the > PMTU of the full path, this could delay the connection by many round- > trip times. > > 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. The > packet size used in the retransmission should be no larger than the > new PMTU." > NEW > "When a Packet Too Big message is received, it implies that a packet > was dropped by the node that sent the ICMPv6 message. A reliable > upper layer protocol will detect the loss of this segment, and recover > it by its normal retransmission methods. Depending on the loss > detection method that is used by the upper layer protocol, this > could delay the connection by many round-trip times. > > Alternatively, the retransmission could be done in immediate response > to a notification that the Path MTU was decreased, but only for the > specific connection specified by the Packet Too Big message. The > packet size used in the retransmission should be no larger than the > new PMTU." > GF: I have no problem with the new text, but I regret that this does not also include this - which I think is helpful context: "If the Path MTU Discovery process requires several steps to find the PMTU of the full path, this could delay the connection by many round- trip times." > ---- > I don't understand the following paragraph. Can this be removed? > "Note: A packetization layer must not retransmit in response to > every Packet Too Big message, since a burst of several oversized > segments will give rise to several such messages and hence several > retransmissions of the same data. If the new estimated PMTU is > still wrong, the process repeats, and there is an exponential > growth in the number of superfluous segments sent." > GF: I think the example is important. I'm not sure why that would be removed. > ---- > > The following text is fine but probably is not needed if the whole document is reworded accordingly to ensure that retransmissions are solely the responsibility of the upper layer protocol: > "Retransmissions can increase network load in response to > congestion, worsening that congestion. Any packetization layer > that uses retransmission is responsible for congestion control of > its retransmissions. See [RFC8085] for more information." > GF: I'd prefer not to remove, it can't be assumed that all protocols doing PMTUD are TCP-like. > --- > This can also be removed, because a reliable protocol that detected loss and decided to send a retransmission, should and will do the same processing as for all other retransmissions, e.g. reset the retransmission time in TCP. Mentioning this separately is rather confusing. > "This means that the TCP layer must be able to recognize when a > Packet Too Big notification actually decreases the PMTU that it > has already used to send a packet on the given connection, and > should ignore any other notifications." > GF: Removing that would be fine with me (I think it's assumed, and so we do not need to say). > ---- > And this is even incorrect. Slow start means that you will increase the connection window exponentially. Only sending one segment means setting the congestion/sending window to one. I propose the following change: > OLD > "Many TCP implementations incorporate "congestion avoidance" and > "slow-start" algorithms to improve performance [CONG]. Unlike a > retransmission caused by a TCP retransmission timeout, a > retransmission caused by a Packet Too Big message should not change > the congestion window. It should, however, trigger the slow-start > mechanism (i.e., only one segment should be retransmitted until > acknowledgements begin to arrive again)." > NEW > "A loss caused by a PMTU probe indicated by the reception of a Packet Too Big message MUST NOT be considered as a congestion notification and hence the congestion window may not change." > GF: That would prune the text further, I'd be really happy with this replacement. > --- > > And I also don't understand this sentence: > "TCP performance can be reduced if the sender's maximum window size is > not an exact multiple of the segment size in use (this is not the > congestion window size)." > GF: I think this should be removed, the sentence is implementation-specific and not important here. > > --- > > Comment (2017-05-08) > 1) I agree with Ekr on this sentence: > "Nodes SHOULD appropriately validate the payload of ICMPv6 PTB > messages to ensure these are received in response to transmitted > traffic (i.e., a reported error condition that corresponds to an IPv6 > packet actually sent by the application) per [ICMPv6]." > This sounds like it should be a MUST but I guess it depends on the upper layer protocol if such a validation is possible or not, e.g. if information are available that can be used for validation. Maybe you can be more explicit here and even say something like pmtu discovery should/must only be used if the upper layer protocol provides means for validation of the icmp payload (like a sequence number in TCP)…? > GF: I think this cannot be a MUST - because there are many cases in which full validation is not possible. Mirja's comment assumes that the packet header is visible in the ICMPv6 payload and the endpoint can find this and verify it. if necessary, this needs to explain corner cases where this is not possible. Placing a MUST requirement is a significnat change. Requiring a reliable transport is also a large change - it may be that the risk of bogus PTB messages can be mitigated in some other way. I prefer the current text - but willing to look at more text instead. See comment by Suresh. > > --- > Further also note that if the upper layer does the validation while the IP layer maintains EMTU_S, there must be an interface from the upper layer to the IP layer to tell if a packet is valid or not before the IP layer updates the MTU estimate. This seems actually more complicated than this one sentences indicates. > GF: The need for an "interface" is implementation dependent, I'd prefer to avoid discussing how/where this is implemented. > > --- > > 2) Also as Ekr says, I also have problems to fully understand this normative text in section 4: > "After receiving a Packet Too Big message, a node MUST attempt to > avoid eliciting more such messages in the near future. The node MUST > reduce the size of the packets it is sending along the path. Using a > PMTU estimate larger than the IPv6 minimum link MTU may continue to > elicit Packet Too Big messages. Since each of these messages (and > the dropped packets they respond to) consume network resources, the > node MUST force the Path MTU Discovery process to end. > > Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast > as possible." > I especially don't understand the first part, given that a PTB message may still indicate a MTU that is larger than the minimum link MTU which then may cause another PTB message later on the path. This text reads like if you receive one PTB message you should better end discovery and fall back to the minimum link MTU to avoid any further PTB message and not waist any resources. I don't think that's the intention and as such I don't understand when it is recommended to end discovery here...? > GF: The text seems good to me. I don't understand the comment from Mirja. I wonder if this is in the eyes of the reader, and some rewording would help? (I suggest the last two sentences could be combined: "Since each of these messages (and the dropped packets they respond to) consume network resources, Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast as possible."" > > --- > 3) Section 5.2 seems to be written with only single homed hosts in mind. It might be good to advise that the pmtu information should always be stored on a per interface basis...? > GF: Agree: Path MTU information should be maintained for each Ipv6 interface. This should be clear. > > --- > 4) Also section 5.2: > You only advise to store information per flow ID, however, if the flow label is not used, wouldn't it make really sense to just use the 5-tuple instead? Also note that EMCP is often done based on the 5-tuple or even 6-tuple (with the ToS field). > GF: The TOS field doesn't exist for IPv6 (nor for IPv4 any more). I really don't think we should be considering DSCP as an index for path information. GF: I thought the text reads about "path", it's intentionally not precise. > > --- > 5) And more in section 5.2: > "When a Packet Too Big message is received, the node determines which > path the message applies to based on the contents of the Packet Too > Big message. " > MAYBE: > "When a valid Packet Too Big message is received, the node determines which > path the message applies to based on the contents of the Packet Too > Big message." > GF: That would be OK, but I guess, the way it knows it is valid is because it finds a valid path - so not sure the change makes this clearer. > > --- > > And further on: > "If the tentative PMTU is less than the existing PMTU estimate, the > tentative PMTU replaces the existing PMTU as the PMTU value for the > path." > This doesn't cover the case where a pmtu probe with a larger size was send and the PTB message returns a larger value then stored. Maybe state this explicitly. > GF: This is wrong. We could explicitly say this is **NOT** allowed. > > ---- > This applies similar to this sentence in section 6: > OLD > "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.“ > NEW > "A node, however, MUST NOT raise its estimate of the > PMTU based on a Packet Too Big message that is not a (validated) response to a PMTU probe that was previously send by this node, so should not be > vulnerable to this attack." > GF: This is wrong. The proposed new text is incorrect. The old text was correct in sentimemt, but could be stronger: "A node, however, must not raise its estimate of the PMTU based on a received Packet Too Big message, so it is not be vulnerable to this attack.“ > ---- > 6) Further section 5.2: > Should this statement be maybe upper case MUST: > "The packetization layers must be notified about decreases in the PMTU." > GF: If upper case makes a difference, this is true. > > --- > 7) Technical comment on section 5.3 in general: > There is a difference between aging if a flow is active or not. While I maybe don't want to probe again for this connection because my application already decided to use a mode where it can live with the current pmtu and it's too much effect to switch, I really want to probe at the beginning of the next connection again to check if I can use a different mode now. While the IP layer does not have a notion of connection it can observe if packets are frequently send with the same 5-tuple and reset the cached pmtu after a certain idle time. > GF: There are many ways to do this, agreed. Is extra text really needed? > > --- > 8) Section 5.4: should this maybe be normative, at least the last MUST NOT (be fragmented): > "A packetization layer (e.g., TCP) must track the PMTU for the path(s) > in use by a connection; it should not send segments that would result > in packets larger than the PMTU, except to probe during PMTU > discovery (this probe packet must not be fragmented to the PMTU). " > GF: If upper case makes a difference, this is true - and probably worth highlighting. > > ---- > > Nit: > The abbreviation PTB is only used once in section 4 (and never expanded). > GF: Should be fixed. > From nobody Tue May 9 06:02:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95EF5129C5D for ; Tue, 9 May 2017 06:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLk-POAmNDNe for ; Tue, 9 May 2017 06:02:11 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90843127137 for ; Tue, 9 May 2017 06:02:11 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id l14so22519460ywk.1 for ; Tue, 09 May 2017 06:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dVjkRywPXj90Br5pp2eRm3PVJyuIohf6sUKPFw2Mb+Q=; b=mEKYsbNQPqjxFz+WNslxIEBBXJ8OlIVRJNfcRkz+/KhDZMMn7HwVCM+k0i2jxGVzD7 17Lxja8lhaosFHN2o7zXrCtTytXJHLFHpqHWQxeYrorVThkytzB1PhVsHpx+X6WXGMem cT30qLkbFgx5kw1oo5Z2mhe2auS5mtMSctspg81/1NleONGLxSdQYqV6FEpdgUHkJmVd rlgMZPO5n0Rks4ltQKHcUsr8vhmWW8uwB8bQtCoheETl3dfg6U7NLlPOezt3ApWTx9Gc IqQy1z28UAg9dmgS807fOO7Y07FTnhAVLZvF32qFkU1O1+1h60XNZWcxfGiKDK79RcGP FYqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dVjkRywPXj90Br5pp2eRm3PVJyuIohf6sUKPFw2Mb+Q=; b=VJQyZniv4v2keybgYt4ARboR4HPkmdiK0/TLT435t3JcfzZgrsvOGOrDs+1jtJ961r lDuhhJ222BRHy6LKDSHXuFYotTtkWYwq3Xu6UXU0clQg6rO0/ffLKXMFXe6ho8Eu+tk7 ccn2A00AmG5qB7R3DzxGJF9nn0o7LXHTktItvTOdATPiEyNGB/79TqnQiKKWfdklZDjd lHKwfem8WD2f+6cdhEcbhqwfkvkJLNyYg2Vgh0/cmxx2CTusWfZ8k9EUOKGuw0gcPYKB pDNokL8xpItHTY646gfhaZ5v+IlPbdaVjxpl2ufINZVAQDG/+lOCrDPeue2E8iJ/AfA7 w7UA== X-Gm-Message-State: AN3rC/7Yv7NxzIm1XyOoYO9Eblb0YwOOX3UqP8U9yveOSqTHzRhEvcvz HhfUji3iLqUrjlc9SlNiiB//b3wvqQ== X-Received: by 10.13.245.2 with SMTP id e2mr56629518ywf.270.1494334930726; Tue, 09 May 2017 06:02:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Tue, 9 May 2017 06:01:30 -0700 (PDT) In-Reply-To: References: <149424843717.31731.1944317631050418426.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Tue, 9 May 2017 06:01:30 -0700 Message-ID: Subject: Re: Eric Rescorla's No Objection on draft-ietf-6man-rfc1981bis-06: (with COMMENT) To: Suresh Krishnan Cc: The IESG , =?UTF-8?Q?Ole_Tr=C3=B8an?= , 6man-chairs@ietf.org, IPv6 List , draft-ietf-6man-rfc1981bis@ietf.org Content-Type: multipart/alternative; boundary=94eb2c08763ab8cb8a054f16f642 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 13:02:15 -0000 --94eb2c08763ab8cb8a054f16f642 Content-Type: text/plain; charset=UTF-8 On Mon, May 8, 2017 at 9:20 PM, Suresh Krishnan wrote: > Hi Ekr, > Thanks for your comments. Please find responses inline. > > On Mon, May 8, 2017 at 9:00 AM, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > > draft-ietf-6man-rfc1981bis-06: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Document: draft-ietf-6man-rfc1981bis-06.txt > > > > OVERALL > > I see in the shepherd's writeup that you have opted not to cite RFC > > 2119, but that makes the mixed case use of SHOULD/MUST even more > > confusing. I would suggest that at minimum you go through the document > > and evaluate whether each should/must should be capitalized, though I > > would prefer a cite to 2119. > > > > For instance: > > changed. Therefore, attempts to detect increases in a path's PMTU > > should be done infrequently. > > > > Is this normative? > > > > > > I also share the concerns others have raised about whether, given the > > actual state of PMTU this is something we should be making IS, but > > I'm willing to bow to the majority here. > > This was certainly one of the things I considered. There is not too > much measurement to back the claims that PMTUD is completely broken. > The only reasonably sized study that I know of > > http://www.nlnetlabs.nl/downloads/publications/pmtu- > black-holes-msc-thesis.pdf > > shows about ~1% packet loss in ICMPv6 PTB messages compared to about > 4-6% for ICMPv4 PTB messages. > OK. > > > > S 4. > > > > Nodes SHOULD appropriately validate the payload of ICMPv6 PTB > > messages to ensure these are received in response to transmitted > > traffic (i.e., a reported error condition that corresponds to an > > IPv6 > > packet actually sent by the application) per [ICMPv6]. > > > > This seems like it ought to be a MUST. Is there a good reason why > > it is not? Perhaps also a cite to how one validates. > > This is directly derived from Section 5.2 of RFC4443. > > "It is recommended that the upper layers perform some form of > validation of ICMP messages (using the information contained in the > payload of the ICMP message) before acting upon them." > > This was precisely the text that made me worried that this is adding a > new requirement. As long as we stick to the requirement level of > ICMPv6, we are OK. If we want to change this to a MUST, I think we > need to demote this to Proposed Standard. So, I see your point as a process point, but given that this actually is a security condition, doesn't this suggest that the document does not perhaps meet the "no known technical omissions" requirement for PS, let alone the bar for IS? > > When a node receives a Packet Too Big message, it MUST reduce its > > > > a valid Packet Too Big message, I think because in graf 2 you say you > > should validate. > > > > > > elicit Packet Too Big messages. Since each of these messages (and > > the dropped packets they respond to) consume network resources, the > > node MUST force the Path MTU Discovery process to end. > > > > It's not clear to me what the requirement is. > > > > Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast > > as possible. Nodes MAY detect increases in PMTU, but because doing > > > > Same thing, what are you requiring. How could I be nonconformant to > > this? > > I see this as stating that detecting PMTU increases is optional and > detecting PMTU decreases is mandatory. I agree that this text could be > clarified Sorry, I'm concerned about "force to end" and "as fast as possible". For instance, suppose that I have an implementation of IPv6 which uses message queues to process all incoming packets, and I receive in order an IPv6 datagram and an ICMPv6 Packet Too Big datagram before I can process either. Am I required to have the ICMPv6 datagram jump the queue. That would be consistent with "as fast as possible" > > > > > S 5. > > This section discusses a number of issues related to the > > implementation of Path MTU Discovery. This is not a specification, > > but rather a set of notes provided as an aid for implementers. > > > > However, this section contains a lot of normative language. Is that all > > non-normative? > > Yes. That is the intention (no normative text here). But it's full of things which sound normative. They should perhaps all be rewritten in some way? > > S 5.3. > > If the stale PMTU value is too large, this will be discovered almost > > immediately once a large enough packet is sent on the path. No such > > mechanism exists for realizing that a stale PMTU value is too small, > > so an implementation SHOULD "age" cached values. When a PMTU value > > has not been decreased for a while (on the order of 10 minutes), the > > PMTU estimate should be set to the MTU of the first-hop link, and > > the > > packetization layers should be notified of the change. This will > > cause the complete Path MTU Discovery process to take place again. > > > > Is this really good advice for TCP? It seems like if you have a > > situation where it required several attempts to get the true PMTU (for > > instance, if you have successively narrower tunnels), then a PMTU > > reset could have a pretty material impact on throughput. > > There is some TCP related implementation advice in Section 5.4. > Basically, a TCP implementation will not send a packet larger than MSS > received from the peer even if the PMTU is larger. > Sure, but that doesn't mean you can't exceed the PMTU. > > S 6. > > 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. > > > > I get that this is now not a normative statement but rather a claim > > about what nodes who follow the MUST NOT in S 4, but it might still > > be better to make it a MUST to avoid confusion. > > How about s/should/will/? That leaves it as a statement of what the > node does and not a normative statement. > SGTM. -Ekr > > Thanks > Suresh > --94eb2c08763ab8cb8a054f16f642 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, May 8, 2017 at 9:20 PM, Suresh Krishnan <<= a href=3D"mailto:suresh.krishnan@gmail.com" target=3D"_blank">suresh.krishn= an@gmail.com> wrote:
Hi Ekr= ,
=C2=A0 Thanks for your comments. Please find responses inline.

On Mon, May 8, 2017 at 9:00 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-6man-rfc1981bis-06: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/d= oc/draft-ietf-6man-rfc1981bis/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> Document: draft-ietf-6man-rfc1981bis-06.txt
>
> OVERALL
> I see in the shepherd's writeup that you have opted not to cite RF= C
> 2119, but that makes the mixed case use of SHOULD/MUST even more
> confusing. I would suggest that at minimum you go through the document=
> and evaluate whether each should/must should be capitalized, though I<= br> > would prefer a cite to 2119.
>
> For instance:
>=C2=A0 =C2=A0 changed.=C2=A0 Therefore, attempts to detect increases in= a path's PMTU
>=C2=A0 =C2=A0 should be done infrequently.
>
> Is this normative?
>
>
> I also share the concerns others have raised about whether, given the<= br> > actual state of PMTU this is something we should be making IS, but
> I'm willing to bow to the majority here.

This was certainly one of the things I considered. There is not= too
much measurement to back the claims that PMTUD is completely broken.
The only reasonably sized study that I know of

http://www.nlnetlabs.n= l/downloads/publications/pmtu-black-holes-msc-thesis.pdf

shows about ~1% packet loss in ICMPv6 PTB messages compared to about
4-6% for ICMPv4 PTB messages.

OK.
=

=C2=A0
>
> S 4.
>
>=C2=A0 =C2=A0 Nodes SHOULD appropriately validate the payload of ICMPv6= PTB
>=C2=A0 =C2=A0 messages to ensure these are received in response to tran= smitted
>=C2=A0 =C2=A0 traffic (i.e., a reported error condition that correspond= s to an
> IPv6
>=C2=A0 =C2=A0 packet actually sent by the application) per [ICMPv6]. >
> This seems like it ought to be a MUST. Is there a good reason why
> it is not? Perhaps also a cite to how one validates.

This is directly derived from Section 5.2 of RFC4443.

"It is recommended that the upper layers perform some form of
validation of ICMP messages (using the information contained in the
payload of the ICMP message) before acting upon them."

This was precisely the text that made me worried that this is adding a
new requirement. As long as we stick to the requirement level of
ICMPv6, we are OK. If we want to change this to a MUST, I think we
need to demote this to Proposed Standard.

S= o, I see your point as a process point, but given that this actually
<= div>is a security condition, doesn't this suggest that the document
does not perhaps meet the "no known technical omissions" r= equirement
for PS, let alone the bar for IS?

=
=C2=A0
>=C2=A0 =C2=A0 When a node receives a Packet Too Big message, it MUST re= duce its
>
> a valid Packet Too Big message, I think because in graf 2 you say you<= br> > should validate.
>
>
>=C2=A0 =C2=A0 elicit Packet Too Big messages.=C2=A0 Since each of these= messages (and
>=C2=A0 =C2=A0 the dropped packets they respond to) consume network reso= urces, the
>=C2=A0 =C2=A0 node MUST force the Path MTU Discovery process to end. >
> It's not clear to me what the requirement is.
>
>=C2=A0 =C2=A0 Nodes using Path MTU Discovery MUST detect decreases in P= MTU as fast
>=C2=A0 =C2=A0 as possible.=C2=A0 Nodes MAY detect increases in PMTU, bu= t because doing
>
> Same thing, what are you requiring. How could I be nonconformant to > this?

I see this as stating that detecting PMTU increases is optional and<= br> detecting PMTU decreases is mandatory. I agree that this text could be
clarified

Sorry, I'm concerned about &q= uot;force to end" and "as fast as possible". For
i= nstance, suppose that I have an implementation of IPv6 which uses
message queues to process all incoming packets, and I receive
in= order an IPv6 datagram and an ICMPv6 Packet Too Big datagram
bef= ore I can process either. Am I required to have the ICMPv6 datagram
jump the queue. That would be consistent with "as fast as possible&= quot;

=C2=A0
<= span class=3D"">
>
> S 5.
>=C2=A0 =C2=A0 This section discusses a number of issues related to the<= br> >=C2=A0 =C2=A0 implementation of Path MTU Discovery.=C2=A0 This is not a= specification,
>=C2=A0 =C2=A0 but rather a set of notes provided as an aid for implemen= ters.
>
> However, this section contains a lot of normative language. Is that al= l
> non-normative?

Yes. That is the intention (no normative text here).

But it's full of things which sound normative. They sh= ould perhaps all be
rewritten in some way?


> S 5.3.
>=C2=A0 =C2=A0 If the stale PMTU value is too large, this will be discov= ered almost
>=C2=A0 =C2=A0 immediately once a large enough packet is sent on the pat= h.=C2=A0 No such
>=C2=A0 =C2=A0 mechanism exists for realizing that a stale PMTU value is= too small,
>=C2=A0 =C2=A0 so an implementation SHOULD "age" cached values= .=C2=A0 When a PMTU value
>=C2=A0 =C2=A0 has not been decreased for a while (on the order of 10 mi= nutes), the
>=C2=A0 =C2=A0 PMTU estimate should be set to the MTU of the first-hop l= ink, and
> the
>=C2=A0 =C2=A0 packetization layers should be notified of the change.=C2= =A0 This will
>=C2=A0 =C2=A0 cause the complete Path MTU Discovery process to take pla= ce again.
>
> Is this really good advice for TCP? It seems like if you have a
> situation where it required several attempts to get the true PMTU (for=
> instance, if you have successively narrower tunnels), then a PMTU
> reset could have a pretty material impact on throughput.

There is some TCP related implementation advice in Section 5.4.
Basically, a TCP implementation will not send a packet larger than MSS
received from the peer even if the PMTU is larger.
Sure, but that doesn't mean you can't exceed the PMTU.<= /div>

=C2=A0
> S 6.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0dropped.=C2=A0 A node, however, should never= raise its estimate of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0PMTU based on a Packet Too Big message, so s= hould not be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0vulnerable to this attack.
>
> I get that this is now not a normative statement but rather a claim > about what nodes who follow the MUST NOT in S 4, but it might still > be better to make it a MUST to avoid confusion.

How about s/should/will/? That leaves it as a statement of what the<= br> node does and not a normative statement.

SGTM.

-Ekr
=C2=A0

Thanks
Suresh

--94eb2c08763ab8cb8a054f16f642-- From nobody Tue May 9 06:33:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B262129C60; Tue, 9 May 2017 06:32:50 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 fbZ5DVf6o1Ml; Tue, 9 May 2017 06:32:47 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 537C812945D; Tue, 9 May 2017 06:32:47 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id w50so73365149wrc.0; Tue, 09 May 2017 06:32:47 -0700 (PDT) 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=QV+PME+ccrBZfZ3kSXk+k2GZILTXz4roueOSuNcCLog=; b=enqWDwKg32fK6HwlEBfHAR1IBJ+tPzAw4CGz8lSUF01nAm0IIW/h7lYs8oxNL+Sj+I ZXrO+6ZcrmkrN4FDfIr0AGsIEUjrjPbOy3CvvaYPHQaexG8kPrBTLcPY89E71I8GKji/ D4LbuHZsRmegR5611TDf7J3bFmoKJqQ598WGAbheVtInsNhxXGM4UbyW/21qbAJrM3Kv NYIe7ow/h9BZYcDmZeeQNCBV7y7ZiBmQi/Yl23Rj6jn+T03E7ZqCkSPYwvy1oELUNCzT JfB9ztWaWhOhJz/eSMPuQccZevgLifjiUK828J60yoJBF+b01Ed1L0z5eBixJxjA5vcB 14qw== 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=QV+PME+ccrBZfZ3kSXk+k2GZILTXz4roueOSuNcCLog=; b=aQkbGNzXGuL1IGIWT+TPmrYcqcwnsrZe6j51IqwIEMCsFdL4/zzvjDY0xLe3Rlp6by DTSJ7ubDy6lp9/P+l8C0bnh9m1wrD8sTB4iLCcQg6qh00aQ3Ju4oh9zCo8kqLVASPYKb aMoZgA6CWRCO+IJghmbxdBlzM8c5Q0If4U2HHtu/J1DjP9GvRRhEjPEFAu4oI1ohWKUk /Eb1RfhHCZzMXx45/jskw1c2OaYPaEvL9dH0xa8cVFGgdi2lr87Bmc0QZWSVwhfRlj+C p7ghhKrvAex2bVzhB4udnxfyOQjC+H1zwC9ZKEQa3FcY7gC0SS8yBA1sEs9UQrIiBvXS EvFQ== X-Gm-Message-State: AODbwcARh1ttPxVCVQl/9eQakxb1EriUg23WDdq5arjDFv94+LFm/ew9 BOVZEwIv80TtuQ== X-Received: by 10.28.149.7 with SMTP id x7mr154359wmd.132.1494336765543; Tue, 09 May 2017 06:32:45 -0700 (PDT) Received: from [172.24.226.96] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id e67sm196757wma.9.2017.05.09.06.32.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 06:32:44 -0700 (PDT) From: Bob Hinden Message-Id: <1716BBF1-C9FF-44B7-B0F7-365D6880D6A8@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_6825B9D5-C1B0-4139-832C-C39BA30F6392"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Eric Rescorla's No Objection on draft-ietf-6man-rfc1981bis-06: (with COMMENT) Date: Tue, 9 May 2017 16:32:40 +0300 In-Reply-To: Cc: Bob Hinden , Suresh Krishnan , IESG , =?utf-8?Q?Ole_Tr=C3=B8an?= , 6man Chairs <6man-chairs@ietf.org>, IPv6 List , draft-ietf-6man-rfc1981bis@ietf.org To: Eric Rescorla References: <149424843717.31731.1944317631050418426.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 13:32:50 -0000 --Apple-Mail=_6825B9D5-C1B0-4139-832C-C39BA30F6392 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ekr, Please see Gorry=E2=80=99s email on the list responding to Mirja = Discuss. What he proposes seems fine with me and addresses a lot of = your comments. Thanks, Bob > On May 9, 2017, at 4:01 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Mon, May 8, 2017 at 9:20 PM, Suresh Krishnan = wrote: > Hi Ekr, > Thanks for your comments. Please find responses inline. >=20 > On Mon, May 8, 2017 at 9:00 AM, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > > draft-ietf-6man-rfc1981bis-06: No Objection > > > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut = this > > introductory paragraph, however.) > > > > > > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ > > > > > > > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > > > > Document: draft-ietf-6man-rfc1981bis-06.txt > > > > OVERALL > > I see in the shepherd's writeup that you have opted not to cite RFC > > 2119, but that makes the mixed case use of SHOULD/MUST even more > > confusing. I would suggest that at minimum you go through the = document > > and evaluate whether each should/must should be capitalized, though = I > > would prefer a cite to 2119. > > > > For instance: > > changed. Therefore, attempts to detect increases in a path's = PMTU > > should be done infrequently. > > > > Is this normative? > > > > > > I also share the concerns others have raised about whether, given = the > > actual state of PMTU this is something we should be making IS, but > > I'm willing to bow to the majority here. >=20 > This was certainly one of the things I considered. There is not too > much measurement to back the claims that PMTUD is completely broken. > The only reasonably sized study that I know of >=20 > = http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis= .pdf >=20 > shows about ~1% packet loss in ICMPv6 PTB messages compared to about > 4-6% for ICMPv4 PTB messages. >=20 > OK. >=20 >=20 > > > > S 4. > > > > Nodes SHOULD appropriately validate the payload of ICMPv6 PTB > > messages to ensure these are received in response to transmitted > > traffic (i.e., a reported error condition that corresponds to an > > IPv6 > > packet actually sent by the application) per [ICMPv6]. > > > > This seems like it ought to be a MUST. Is there a good reason why > > it is not? Perhaps also a cite to how one validates. >=20 > This is directly derived from Section 5.2 of RFC4443. >=20 > "It is recommended that the upper layers perform some form of > validation of ICMP messages (using the information contained in the > payload of the ICMP message) before acting upon them." >=20 > This was precisely the text that made me worried that this is adding a > new requirement. As long as we stick to the requirement level of > ICMPv6, we are OK. If we want to change this to a MUST, I think we > need to demote this to Proposed Standard. >=20 > So, I see your point as a process point, but given that this actually > is a security condition, doesn't this suggest that the document > does not perhaps meet the "no known technical omissions" requirement > for PS, let alone the bar for IS? >=20 >=20 > > When a node receives a Packet Too Big message, it MUST reduce its > > > > a valid Packet Too Big message, I think because in graf 2 you say = you > > should validate. > > > > > > elicit Packet Too Big messages. Since each of these messages = (and > > the dropped packets they respond to) consume network resources, = the > > node MUST force the Path MTU Discovery process to end. > > > > It's not clear to me what the requirement is. > > > > Nodes using Path MTU Discovery MUST detect decreases in PMTU as = fast > > as possible. Nodes MAY detect increases in PMTU, but because = doing > > > > Same thing, what are you requiring. How could I be nonconformant to > > this? >=20 > I see this as stating that detecting PMTU increases is optional and > detecting PMTU decreases is mandatory. I agree that this text could be > clarified >=20 > Sorry, I'm concerned about "force to end" and "as fast as possible". = For > instance, suppose that I have an implementation of IPv6 which uses > message queues to process all incoming packets, and I receive > in order an IPv6 datagram and an ICMPv6 Packet Too Big datagram > before I can process either. Am I required to have the ICMPv6 datagram > jump the queue. That would be consistent with "as fast as possible" >=20 >=20 >=20 > > > > S 5. > > This section discusses a number of issues related to the > > implementation of Path MTU Discovery. This is not a = specification, > > but rather a set of notes provided as an aid for implementers. > > > > However, this section contains a lot of normative language. Is that = all > > non-normative? >=20 > Yes. That is the intention (no normative text here). >=20 > But it's full of things which sound normative. They should perhaps all = be > rewritten in some way? >=20 >=20 > > S 5.3. > > If the stale PMTU value is too large, this will be discovered = almost > > immediately once a large enough packet is sent on the path. No = such > > mechanism exists for realizing that a stale PMTU value is too = small, > > so an implementation SHOULD "age" cached values. When a PMTU = value > > has not been decreased for a while (on the order of 10 minutes), = the > > PMTU estimate should be set to the MTU of the first-hop link, and > > the > > packetization layers should be notified of the change. This will > > cause the complete Path MTU Discovery process to take place = again. > > > > Is this really good advice for TCP? It seems like if you have a > > situation where it required several attempts to get the true PMTU = (for > > instance, if you have successively narrower tunnels), then a PMTU > > reset could have a pretty material impact on throughput. >=20 > There is some TCP related implementation advice in Section 5.4. > Basically, a TCP implementation will not send a packet larger than MSS > received from the peer even if the PMTU is larger. >=20 > Sure, but that doesn't mean you can't exceed the PMTU. >=20 >=20 > > S 6. > > 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. > > > > I get that this is now not a normative statement but rather a claim > > about what nodes who follow the MUST NOT in S 4, but it might still > > be better to make it a MUST to avoid confusion. >=20 > How about s/should/will/? That leaves it as a statement of what the > node does and not a normative statement. >=20 > SGTM. >=20 > -Ekr >=20 >=20 > Thanks > Suresh >=20 --Apple-Mail=_6825B9D5-C1B0-4139-832C-C39BA30F6392 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 iQEcBAEBCgAGBQJZEcT4AAoJEK7rdBF357uoJ4UH/icPPeuwQCidUiA31zIgMQ8Y lsxvVIdh5wMZKmFDix21AHKWnYbYpOCrH4T6Wp79j2YbMRdbGzQtV7OVf5gFGdBH wWXeoOTCui1lbPEFQZG2MTyOZ3iniY6TES+sc9PgMUMFspNT57eV5Et6LPhnicmI Su14MSu0EpJnbXXir5S7zpbyMiZeQkXI5rLnRkZzE5icPIStpgpa4JDmVUoAhpFc r/yjMgAhxMyBxbeKG96DEsjNxY5/kFzy52pHQLjqcF8upf9T1SKPq7FsLqwQbaFk QTcs3pQwC8GIF6sJmSNe+cgS6Noxy++JDnL2ZIF/ThQIBqYeGqZ+gj8GybKjMUU= =3n08 -----END PGP SIGNATURE----- --Apple-Mail=_6825B9D5-C1B0-4139-832C-C39BA30F6392-- From nobody Tue May 9 07:11:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7BF129470 for ; Tue, 9 May 2017 07:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgHAJi_sNwce for ; Tue, 9 May 2017 07:11:14 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 53849127B73 for ; Tue, 9 May 2017 07:11:14 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id p143so468194yba.2 for ; Tue, 09 May 2017 07:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Bgc4vErkTYe3DdLMSmPEZz2+6jEvKYPn+0htKPWi7ME=; b=oLNgdjawybR8/xg3tRoBgJLhy4/uXmdHvz2kDle+L9E+kRO5Vr2p1Ppgh2f72Mu5wP Ocv/HEiSNGY2Hx3HVKGvMsDKQfhZEMuqdtiuhTmRFeFE6GwSB6fN/VUlaBwAOySVi7r5 Wk0ISoSFxAjLLxjz3EvcJJ4hDbRVcuKsvujeSuaiU7rIbOSgso8mjivF3YeAd/wol1CU FoVSNKjsxwHbjKjkuS2i/1TbsJ9IFwAn62bBIJgxhdMEJk1dscJj/3egV6tG0YCmaBpz PZb/JuDpn4fXMWC2yp2K/5VelN66jyysfcTjIPP/vYYqgUQ+5PsXh78wpMDScH8Nz2VJ /W9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Bgc4vErkTYe3DdLMSmPEZz2+6jEvKYPn+0htKPWi7ME=; b=lk6pQAX6YK9fXM6HRMszS/y6BP17m30iL8vvGyaQ2ThqTyQ27j4JQ6E4Y2A2q4q1yB 1QQAHuCIJVinUCQ6417he23dwVMSYzM2yIjOabPUmKNMJfneAYDNfkjFyze6gazha803 q9bgj0drZmgvlBr3Dibwg58SfvE1rDEujvv74Ea+aACbGPu9+4wJaYGwib+LP1XLq3QV pVcOjhrTTQw98K7JKwGhk+O/N2XGG0rX8yu88+8fUuwkEyfsoZzLGKki69qQjV6excxx TM80rj0ynpXz2ncgtauneN0yVFW8jI6lObKOzOrEO1Lvpz1KEnuhgoK+p/JsmAPm+/GZ NcdA== X-Gm-Message-State: AODbwcDvAK+VvAlcLcznEPWXxwVk40FKDKHR4CHH8qfGWhZdcMZqPFjg p9lEfqewXAeOm9zvay07UYR/xscuLg== X-Received: by 10.37.41.130 with SMTP id p124mr280918ybp.24.1494339073398; Tue, 09 May 2017 07:11:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.202.146 with HTTP; Tue, 9 May 2017 07:10:32 -0700 (PDT) In-Reply-To: <1716BBF1-C9FF-44B7-B0F7-365D6880D6A8@gmail.com> References: <149424843717.31731.1944317631050418426.idtracker@ietfa.amsl.com> <1716BBF1-C9FF-44B7-B0F7-365D6880D6A8@gmail.com> From: Eric Rescorla Date: Tue, 9 May 2017 07:10:32 -0700 Message-ID: Subject: Re: Eric Rescorla's No Objection on draft-ietf-6man-rfc1981bis-06: (with COMMENT) To: Bob Hinden Cc: Suresh Krishnan , IESG , =?UTF-8?Q?Ole_Tr=C3=B8an?= , 6man Chairs <6man-chairs@ietf.org>, IPv6 List , draft-ietf-6man-rfc1981bis@ietf.org Content-Type: multipart/alternative; boundary=94eb2c14d834a52622054f17ed27 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 14:11:22 -0000 --94eb2c14d834a52622054f17ed27 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bob, I have read Gorry's email but I'm not sure how many of my comments it actually addresses. Hopefully, my response to Suresh clarifies my points? And of course, these aren't DISCUSS points so maybe you should just ignore me :) -Ekr On Tue, May 9, 2017 at 6:32 AM, Bob Hinden wrote: > Ekr, > > Please see Gorry=E2=80=99s email on the list responding to Mirja Discuss.= What he > proposes seems fine with me and addresses a lot of your comments. > > Thanks, > Bob > > > > On May 9, 2017, at 4:01 PM, Eric Rescorla wrote: > > > > > > > > On Mon, May 8, 2017 at 9:20 PM, Suresh Krishnan < > suresh.krishnan@gmail.com> wrote: > > Hi Ekr, > > Thanks for your comments. Please find responses inline. > > > > On Mon, May 8, 2017 at 9:00 AM, Eric Rescorla wrote: > > > Eric Rescorla has entered the following ballot position for > > > draft-ietf-6man-rfc1981bis-06: No Objection > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut th= is > > > introductory paragraph, however.) > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ > > > > > > > > > > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > > > > > Document: draft-ietf-6man-rfc1981bis-06.txt > > > > > > OVERALL > > > I see in the shepherd's writeup that you have opted not to cite RFC > > > 2119, but that makes the mixed case use of SHOULD/MUST even more > > > confusing. I would suggest that at minimum you go through the documen= t > > > and evaluate whether each should/must should be capitalized, though I > > > would prefer a cite to 2119. > > > > > > For instance: > > > changed. Therefore, attempts to detect increases in a path's PMTU > > > should be done infrequently. > > > > > > Is this normative? > > > > > > > > > I also share the concerns others have raised about whether, given the > > > actual state of PMTU this is something we should be making IS, but > > > I'm willing to bow to the majority here. > > > > This was certainly one of the things I considered. There is not too > > much measurement to back the claims that PMTUD is completely broken. > > The only reasonably sized study that I know of > > > > http://www.nlnetlabs.nl/downloads/publications/pmtu- > black-holes-msc-thesis.pdf > > > > shows about ~1% packet loss in ICMPv6 PTB messages compared to about > > 4-6% for ICMPv4 PTB messages. > > > > OK. > > > > > > > > > > S 4. > > > > > > Nodes SHOULD appropriately validate the payload of ICMPv6 PTB > > > messages to ensure these are received in response to transmitted > > > traffic (i.e., a reported error condition that corresponds to an > > > IPv6 > > > packet actually sent by the application) per [ICMPv6]. > > > > > > This seems like it ought to be a MUST. Is there a good reason why > > > it is not? Perhaps also a cite to how one validates. > > > > This is directly derived from Section 5.2 of RFC4443. > > > > "It is recommended that the upper layers perform some form of > > validation of ICMP messages (using the information contained in the > > payload of the ICMP message) before acting upon them." > > > > This was precisely the text that made me worried that this is adding a > > new requirement. As long as we stick to the requirement level of > > ICMPv6, we are OK. If we want to change this to a MUST, I think we > > need to demote this to Proposed Standard. > > > > So, I see your point as a process point, but given that this actually > > is a security condition, doesn't this suggest that the document > > does not perhaps meet the "no known technical omissions" requirement > > for PS, let alone the bar for IS? > > > > > > > When a node receives a Packet Too Big message, it MUST reduce its > > > > > > a valid Packet Too Big message, I think because in graf 2 you say you > > > should validate. > > > > > > > > > elicit Packet Too Big messages. Since each of these messages (and > > > the dropped packets they respond to) consume network resources, th= e > > > node MUST force the Path MTU Discovery process to end. > > > > > > It's not clear to me what the requirement is. > > > > > > Nodes using Path MTU Discovery MUST detect decreases in PMTU as fa= st > > > as possible. Nodes MAY detect increases in PMTU, but because doin= g > > > > > > Same thing, what are you requiring. How could I be nonconformant to > > > this? > > > > I see this as stating that detecting PMTU increases is optional and > > detecting PMTU decreases is mandatory. I agree that this text could be > > clarified > > > > Sorry, I'm concerned about "force to end" and "as fast as possible". Fo= r > > instance, suppose that I have an implementation of IPv6 which uses > > message queues to process all incoming packets, and I receive > > in order an IPv6 datagram and an ICMPv6 Packet Too Big datagram > > before I can process either. Am I required to have the ICMPv6 datagram > > jump the queue. That would be consistent with "as fast as possible" > > > > > > > > > > > > S 5. > > > This section discusses a number of issues related to the > > > implementation of Path MTU Discovery. This is not a specification= , > > > but rather a set of notes provided as an aid for implementers. > > > > > > However, this section contains a lot of normative language. Is that a= ll > > > non-normative? > > > > Yes. That is the intention (no normative text here). > > > > But it's full of things which sound normative. They should perhaps all = be > > rewritten in some way? > > > > > > > S 5.3. > > > If the stale PMTU value is too large, this will be discovered almo= st > > > immediately once a large enough packet is sent on the path. No su= ch > > > mechanism exists for realizing that a stale PMTU value is too smal= l, > > > so an implementation SHOULD "age" cached values. When a PMTU valu= e > > > has not been decreased for a while (on the order of 10 minutes), t= he > > > PMTU estimate should be set to the MTU of the first-hop link, and > > > the > > > packetization layers should be notified of the change. This will > > > cause the complete Path MTU Discovery process to take place again. > > > > > > Is this really good advice for TCP? It seems like if you have a > > > situation where it required several attempts to get the true PMTU (fo= r > > > instance, if you have successively narrower tunnels), then a PMTU > > > reset could have a pretty material impact on throughput. > > > > There is some TCP related implementation advice in Section 5.4. > > Basically, a TCP implementation will not send a packet larger than MSS > > received from the peer even if the PMTU is larger. > > > > Sure, but that doesn't mean you can't exceed the PMTU. > > > > > > > S 6. > > > dropped. A node, however, should never raise its estimate of t= he > > > PMTU based on a Packet Too Big message, so should not be > > > vulnerable to this attack. > > > > > > I get that this is now not a normative statement but rather a claim > > > about what nodes who follow the MUST NOT in S 4, but it might still > > > be better to make it a MUST to avoid confusion. > > > > How about s/should/will/? That leaves it as a statement of what the > > node does and not a normative statement. > > > > SGTM. > > > > -Ekr > > > > > > Thanks > > Suresh > > > > --94eb2c14d834a52622054f17ed27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bob,

I have read Gorry's email b= ut I'm not sure how many of my comments it actually addresses. Hopefull= y, my response to Suresh clarifies my points? And of course, these aren'= ;t DISCUSS points so maybe you should just ignore me :)

-Ekr


On Tue, May 9, 2017 at 6:32 AM, Bob Hinden <bob= .hinden@gmail.com> wrote:
E= kr,

Please see Gorry=E2=80=99s email on the list responding to Mirja Discuss.= =C2=A0 What he proposes seems fine with me and addresses a lot of your comm= ents.

Thanks,
Bob


> On May 9, 2017, at 4:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Mon, May 8, 2017 at 9:20 PM, Suresh Krishnan <suresh.krishnan@gmail.com> wrote:
> Hi Ekr,
>=C2=A0 =C2=A0Thanks for your comments. Please find responses inline. >
> On Mon, May 8, 2017 at 9:00 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-6man-rfc1981bis-06: No Objection
> >
> > When responding, please keep the subject line intact and reply to= all
> > email addresses included in the To and CC lines. (Feel free to cu= t this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.= org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.org/<= wbr>doc/draft-ietf-6man-rfc1981bis/
> >
> >
> >
> > ------------------------------------------------------------= ----------
> > COMMENT:
> > ------------------------------------------------------------= ----------
> >
> > Document: draft-ietf-6man-rfc1981bis-06.txt
> >
> > OVERALL
> > I see in the shepherd's writeup that you have opted not to ci= te RFC
> > 2119, but that makes the mixed case use of SHOULD/MUST even more<= br> > > confusing. I would suggest that at minimum you go through the doc= ument
> > and evaluate whether each should/must should be capitalized, thou= gh I
> > would prefer a cite to 2119.
> >
> > For instance:
> >=C2=A0 =C2=A0 changed.=C2=A0 Therefore, attempts to detect increas= es in a path's PMTU
> >=C2=A0 =C2=A0 should be done infrequently.
> >
> > Is this normative?
> >
> >
> > I also share the concerns others have raised about whether, given= the
> > actual state of PMTU this is something we should be making IS, bu= t
> > I'm willing to bow to the majority here.
>
> This was certainly one of the things I considered. There is not too > much measurement to back the claims that PMTUD is completely broken. > The only reasonably sized study that I know of
>
> http://www.nlnetl= abs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf=
>
> shows about ~1% packet loss in ICMPv6 PTB messages compared to about > 4-6% for ICMPv4 PTB messages.
>
> OK.
>
>
> >
> > S 4.
> >
> >=C2=A0 =C2=A0 Nodes SHOULD appropriately validate the payload of I= CMPv6 PTB
> >=C2=A0 =C2=A0 messages to ensure these are received in response to= transmitted
> >=C2=A0 =C2=A0 traffic (i.e., a reported error condition that corre= sponds to an
> > IPv6
> >=C2=A0 =C2=A0 packet actually sent by the application) per [ICMPv6= ].
> >
> > This seems like it ought to be a MUST. Is there a good reason why=
> > it is not? Perhaps also a cite to how one validates.
>
> This is directly derived from Section 5.2 of RFC4443.
>
> "It is recommended that the upper layers perform some form of
> validation of ICMP messages (using the information contained in the > payload of the ICMP message) before acting upon them."
>
> This was precisely the text that made me worried that this is adding a=
> new requirement. As long as we stick to the requirement level of
> ICMPv6, we are OK. If we want to change this to a MUST, I think we
> need to demote this to Proposed Standard.
>
> So, I see your point as a process point, but given that this actually<= br> > is a security condition, doesn't this suggest that the document > does not perhaps meet the "no known technical omissions" req= uirement
> for PS, let alone the bar for IS?
>
>
> >=C2=A0 =C2=A0 When a node receives a Packet Too Big message, it MU= ST reduce its
> >
> > a valid Packet Too Big message, I think because in graf 2 you say= you
> > should validate.
> >
> >
> >=C2=A0 =C2=A0 elicit Packet Too Big messages.=C2=A0 Since each of = these messages (and
> >=C2=A0 =C2=A0 the dropped packets they respond to) consume network= resources, the
> >=C2=A0 =C2=A0 node MUST force the Path MTU Discovery process to en= d.
> >
> > It's not clear to me what the requirement is.
> >
> >=C2=A0 =C2=A0 Nodes using Path MTU Discovery MUST detect decreases= in PMTU as fast
> >=C2=A0 =C2=A0 as possible.=C2=A0 Nodes MAY detect increases in PMT= U, but because doing
> >
> > Same thing, what are you requiring. How could I be nonconformant = to
> > this?
>
> I see this as stating that detecting PMTU increases is optional and > detecting PMTU decreases is mandatory. I agree that this text could be=
> clarified
>
> Sorry, I'm concerned about "force to end" and "as f= ast as possible". For
> instance, suppose that I have an implementation of IPv6 which uses
> message queues to process all incoming packets, and I receive
> in order an IPv6 datagram and an ICMPv6 Packet Too Big datagram
> before I can process either. Am I required to have the ICMPv6 datagram=
> jump the queue. That would be consistent with "as fast as possibl= e"
>
>
>
> >
> > S 5.
> >=C2=A0 =C2=A0 This section discusses a number of issues related to= the
> >=C2=A0 =C2=A0 implementation of Path MTU Discovery.=C2=A0 This is = not a specification,
> >=C2=A0 =C2=A0 but rather a set of notes provided as an aid for imp= lementers.
> >
> > However, this section contains a lot of normative language. Is th= at all
> > non-normative?
>
> Yes. That is the intention (no normative text here).
>
> But it's full of things which sound normative. They should perhaps= all be
> rewritten in some way?
>
>
> > S 5.3.
> >=C2=A0 =C2=A0 If the stale PMTU value is too large, this will be d= iscovered almost
> >=C2=A0 =C2=A0 immediately once a large enough packet is sent on th= e path.=C2=A0 No such
> >=C2=A0 =C2=A0 mechanism exists for realizing that a stale PMTU val= ue is too small,
> >=C2=A0 =C2=A0 so an implementation SHOULD "age" cached v= alues.=C2=A0 When a PMTU value
> >=C2=A0 =C2=A0 has not been decreased for a while (on the order of = 10 minutes), the
> >=C2=A0 =C2=A0 PMTU estimate should be set to the MTU of the first-= hop link, and
> > the
> >=C2=A0 =C2=A0 packetization layers should be notified of the chang= e.=C2=A0 This will
> >=C2=A0 =C2=A0 cause the complete Path MTU Discovery process to tak= e place again.
> >
> > Is this really good advice for TCP? It seems like if you have a > > situation where it required several attempts to get the true PMTU= (for
> > instance, if you have successively narrower tunnels), then a PMTU=
> > reset could have a pretty material impact on throughput.
>
> There is some TCP related implementation advice in Section 5.4.
> Basically, a TCP implementation will not send a packet larger than MSS=
> received from the peer even if the PMTU is larger.
>
> Sure, but that doesn't mean you can't exceed the PMTU.
>
>
> > S 6.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0dropped.=C2=A0 A node, however, should = never raise its estimate of the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0PMTU based on a Packet Too Big message,= so should not be
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0vulnerable to this attack.
> >
> > I get that this is now not a normative statement but rather a cla= im
> > about what nodes who follow the MUST NOT in S 4, but it might sti= ll
> > be better to make it a MUST to avoid confusion.
>
> How about s/should/will/? That leaves it as a statement of what the > node does and not a normative statement.
>
> SGTM.
>
> -Ekr
>
>
> Thanks
> Suresh
>


--94eb2c14d834a52622054f17ed27-- From nobody Tue May 9 07:25:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8360129481; Tue, 9 May 2017 07:25:32 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bEvTAZRsZloa; Tue, 9 May 2017 07:25:31 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2530129478; Tue, 9 May 2017 07:25:30 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id l9so1331528wre.1; Tue, 09 May 2017 07:25:30 -0700 (PDT) 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=4WsJb49e9qIN2Jk5avtyJW3Tvo2TL7G3wlP4wbYkfzo=; b=XRdfqWZIHRzSpxh9BZSMr9pb2pSXMJoFe6MBqzeLWhhhHg6iDecNx5Osu7HQPzpd1X k+Kw1cLCdVyUe/tpGBYn2UllGXHI2Z8Lv6p9IQ54SBipr9y/nXMajUs52MvcFvPMKHus kYbQqoO5geo+r3KL2D+982Fqqy8YMl9OrYg40ela3H94QhISz6mD4cNCR7he1/JPvuHQ JkJyVrQo6QSA6oAOe4TZYojcfgLo3RXruEIhkPAJ5l90G01Yx4eNne4G0PyJYBJa7G87 pgeuZDENVJT4ZGBF9fS59n0qeCOjfqs0IxAkcOSED8TAYV56WSDWMLXVKKKv02Z5dOV0 zLGQ== 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=4WsJb49e9qIN2Jk5avtyJW3Tvo2TL7G3wlP4wbYkfzo=; b=Sm7cLbL0/WCHfUbRUTWEUqiQ+2Cfqpr0iWXmLEjSGgts3sCdt08xZ2XQdsTLBrQHwa 2Oxo2bTIRHCvqk5HrL4Swo/9nevh84IuMor3YYHUEMiRt0JZmr6ekkqZTTeD82DqZ5RQ RG41JTSw0dosmCfpdjxA6TqV8OlwSDYNQAxm6XRgtOs2bdmKhXQhJ+hNXeA1302w5ziv uK0ebQxPer6lKYHl8S1WasTeSzjy0xjnw25DVhDhtjjdkqYwtaLLQVaDRp0t3NZsM2YG hkqzUcasaIvXyuUeLsZ76/N0W/X1oq7kQY8qs2dtvPIHdh/PN58qtTyINSFigdsDOEin GPfQ== X-Gm-Message-State: AODbwcC9IgZ7TLrr3p5pGlHgSwJWj4r++IZZ1hKI2Y4rHvQRFmUEL3SZ q4DGxHHPkZeTWQ== X-Received: by 10.28.184.215 with SMTP id i206mr475519wmf.130.1494339929552; Tue, 09 May 2017 07:25:29 -0700 (PDT) Received: from [172.24.226.96] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id w17sm1215861wme.13.2017.05.09.07.25.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 07:25:28 -0700 (PDT) From: Bob Hinden Message-Id: <988E7F8B-A126-4722-96A2-ADB6580F1213@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_81611E36-6B72-499D-AE87-DB30FACCB7C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Eric Rescorla's No Objection on draft-ietf-6man-rfc1981bis-06: (with COMMENT) Date: Tue, 9 May 2017 17:25:24 +0300 In-Reply-To: Cc: Bob Hinden , Suresh Krishnan , IESG , =?utf-8?Q?Ole_Tr=C3=B8an?= , 6man Chairs <6man-chairs@ietf.org>, IPv6 List , draft-ietf-6man-rfc1981bis@ietf.org To: Eric Rescorla References: <149424843717.31731.1944317631050418426.idtracker@ietfa.amsl.com> <1716BBF1-C9FF-44B7-B0F7-365D6880D6A8@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 14:25:33 -0000 --Apple-Mail=_81611E36-6B72-499D-AE87-DB30FACCB7C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ekr, > On May 9, 2017, at 5:10 PM, Eric Rescorla wrote: >=20 > Hi Bob, >=20 > I have read Gorry's email but I'm not sure how many of my comments it = actually addresses. Hopefully, my response to Suresh clarifies my = points? And of course, these aren't DISCUSS points so maybe you should = just ignore me :) Would I ever ignore you :-) In this case, I think we should deal with the Discusses first, then = circle back and look at the comments. Otherwise, too many moving parts. Thanks, Bob --Apple-Mail=_81611E36-6B72-499D-AE87-DB30FACCB7C7 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 iQEcBAEBCgAGBQJZEdFUAAoJEK7rdBF357uoubwH/iLywuzUJtNLucgfeX8/Pgou W9pRiUWCwA+sa/CzQupsLygH3mlPFtemy8J/xweQIKJFe0SA4LYqY8C0hvje02XT efYSxh7tEfzqmBVtSAKxgb8RZn2A1rqSqFlxLmijtwnXQYO/gp5wR0KtTaP0YtWw g6IhcLZ/f+b4TZD56QiB4PLZanUEmwzFdcrAwl16xSFaR5uVigvp73tCdM59jAam VKUaIS7i+WoOsRqZs+0XqigFVPf/JklUw52vW1srj/k/SxUz3kJHjTxWTEulQdfR oBcNBNqCcPWuJ0OmKRkcKBkzoAAWLE49c9UcjuLodQerAvczHiO6G32fA97MnME= =nxAk -----END PGP SIGNATURE----- --Apple-Mail=_81611E36-6B72-499D-AE87-DB30FACCB7C7-- From nobody Tue May 9 07:38:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E9B129483; Tue, 9 May 2017 07:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8hsA3qT-12H; Tue, 9 May 2017 07:37:49 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DED129465; Tue, 9 May 2017 07:37:48 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id h4so2365643lfj.3; Tue, 09 May 2017 07:37:48 -0700 (PDT) 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=N9TYcY3rmFB5LBdoS29ocEbjfzkLua7Tj090zZQDAys=; b=gfDBBoKjv+qnAw1GZwShmpaLFeWXyFSeCYK7C3qU4BgLMTSNl3RH78VEX8IrqkxzgR UKqdEfLDu7anmiOrzZETydv815boScF7kegjvosKif44t9GS07zJzzIcYPOuYk7KpbCD ++YHgvntSe15nnITunn60XG/UsrrCNoejvgTTl9juEMVCzV+IrcTfrxDMHoM2aeLIfKa 8eem+zmJHYx66b8ixZ/wjeNTzmM589IQVAZzhKoN9fXn32WiAZ/YJnCAMQQb9AOCvDbY zKlykKsehlUWvKNYQBVUEkm7xJ9Jamcu9G9dF4GAPNPN9UWi8AbncpN/dZ0ufIk8sePR NRhQ== 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=N9TYcY3rmFB5LBdoS29ocEbjfzkLua7Tj090zZQDAys=; b=jLVTLxh75HeSQv1uE4pqcJrRMIF86UfglpWt4QDWWdg+yQ05Ynp/xU3uZ7cIjJxgQG KTy3Gm73w7scex15egNg1gw5dkz8oNHw3nqluwxzPFQMJi3VtB0ev2Ze0Fwe/x4epaLg lJSzGGJuMHcNOfXnjT3niNpwq9eckUKhc+V0y2BWowKNNxyYIYYMyAHO8rPACSftC1R6 v9vxubiYx8FmpyP8wvASozG/bb7WCceZ9lmzslQX5FOBkdVhbp3BgsyMpKTPDGW9sdJK OTZz8+jmfL7lBu54Mv4KzQ3EOH1LKUpFIlvQ3N/Q6AN3DqKZEmwyLpxVhJH/cd8xSy8z ou4w== X-Gm-Message-State: AODbwcDuuX8XpcFsL97iWHnALdbJTU+dVYvlJKENBc+94bslUNkfavNI Tn69P7SRmK86kNEKtU8= X-Received: by 10.28.92.136 with SMTP id q130mr1262258wmb.49.1494340665321; Tue, 09 May 2017 07:37:45 -0700 (PDT) Received: from [172.24.226.96] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id 7sm51490wrs.69.2017.05.09.07.37.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 07:37:44 -0700 (PDT) From: Bob Hinden Message-Id: <5DE424DC-F18D-417B-B547-62F49A04B6C1@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4336B694-1F25-40AF-A739-FAC1BBF4D176"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS) Date: Tue, 9 May 2017 17:37:40 +0300 In-Reply-To: <149427694020.22664.10344820301651708437.idtracker@ietfa.amsl.com> Cc: Bob Hinden , IESG , draft-ietf-6man-rfc1981bis@ietf.org, =?utf-8?Q?Ole_Tr=C3=B8an?= , 6man-chairs@ietf.org, IPv6 List To: Alvaro Retana References: <149427694020.22664.10344820301651708437.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 14:37:51 -0000 --Apple-Mail=_4336B694-1F25-40AF-A739-FAC1BBF4D176 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alvaro, Based on your Discuss, I am planning to add: Note: This document is an update to [RFC1981] that was published prior to [RFC2119] being published. Consequently while it does use "should/must" style language in upper and lower case, the document does not cite the RFC2119 definitions. This update does not change that. To the Introduction of this document. It should appear in the next = published version of this draft. Thanks, Bob > On May 8, 2017, at 11:55 PM, Alvaro Retana wrote: >=20 > Alvaro Retana has entered the following ballot position for > draft-ietf-6man-rfc1981bis-06: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I'm putting in this point as a DISCUSS because I think that the = current > text may be confusing and vague. >=20 > As others have pointed out, this document includes rfc2119-like = language, > both capitalized and not. I realize that rfc1981 was published before > rfc2119 and that no expectation on the language existed then. = However, > we're at a point in time where not only rfc2119 is in place, but > draft-leiba-rfc2119-update (which clarifies that only uppercase = language > has special meaning) is in AUTH48. I think that this leads to the > possibility that the average reader may interpret the requirements in > this document in a way that it wasn't intended. >=20 > While I would prefer that this document be consistent (and either use > capitalized rfc2119 language as intended, OR, not used it at all), I > understand the intent of not changing some of the original text. I = would > be happy with a note like this one: "Note: This document is an update = to > RFC1981 that was published prior to RFC2119 being published. > Consequently while it does use "should/must" style language in upper = and > lower case, the document does not cite the RFC2119 definitions. This > update does not change that." [I borrowed this text from the the = INTDIR > review thread. [1]] >=20 > I find that including a note in the Shepherd's write-up is not enough > because the average reader/implementer will not consult it. >=20 >=20 > [1] > = https://mailarchive.ietf.org/arch/msg/int-dir/bVH_0ydVdGssOiszJKhQXLYPuXY/= ?qid=3D4000f8a954b226266f429842911101f5 >=20 >=20 >=20 >=20 --Apple-Mail=_4336B694-1F25-40AF-A739-FAC1BBF4D176 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 iQEcBAEBCgAGBQJZEdQ0AAoJEK7rdBF357uobGoIALSA6kpitydH5x4h6KWflQ+M 9orXtLvRahwJ7T8Nz3i9bbMNLJH1O/s6xaYVpBZoOJ5Cj6mqC2ej8yzi1xvWfSTv ab1y+InG/kdgUNwBuStKZLQhJFqn6B6eZc0FNomvD4kFiz/HWVKfwXNmWmT2GKPU i9vjv+uWOlin9w/0NeW42pbAdcBmruwRciK5EOKBRoxP+8b0XWUfHzCw52SwecDA SnJP+zqBY7YE/hVtX5rFSyDC83bJgW6tx0LtkE1jakg2xqPxAQxBvUCYUgfBLpj0 R9xrk1LI24WD+9nNZg5VJA4XNb8xMcdFIo4YL/n+gFXgHNREvxkObMJ2INZE+yc= =dpCi -----END PGP SIGNATURE----- --Apple-Mail=_4336B694-1F25-40AF-A739-FAC1BBF4D176-- From nobody Tue May 9 08:19:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01886127241 for ; Tue, 9 May 2017 08:19:03 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FQdpspMAljOn for ; Tue, 9 May 2017 08:19:01 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 EAD8D12AF6E for <6man@ietf.org>; Tue, 9 May 2017 08:18:59 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id w50so3536424wrc.0 for <6man@ietf.org>; Tue, 09 May 2017 08:18:59 -0700 (PDT) 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=6Jwdbi2c+TnSOlWqZ8hieJfn2dniqRWDXi6FVHVXGuc=; b=USzRGh4Z7I3d5RZHXzVkT0jthmWWI1II/2AqVPKxd5bp99jPL2YNxhYBty55MKO2PN /vCWmUBf4C5NjSbih24fM8WnAyHy4kuuHx2JbWwrl8BZp9/vcSEyOK5I7gPc/XCSfVPd 80ksmxvQ1XZQER182WlvWd+WFGHv2xvQSbiOe1xxl1mtHA3x951tB1hbVATZlsXlLn31 fUJaXeY3EqlD8GIK134NNpVJTwVR5Qp9kfVJGAHLqYfMiUEaSdM1L6QzUjQOSn18qBSw cgtn+UGAPl6Na++1vCZZdYxZWds9uZVp05g8nOHlGxPKaf9al9KPIgFHhs5EzI5vqyvB pSIA== 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=6Jwdbi2c+TnSOlWqZ8hieJfn2dniqRWDXi6FVHVXGuc=; b=N9kYgyFti7KDjGeJv4/GzGKialcGSNqT2sjIU8snGDKoZ3wkUbD5X31msRxcrLNJmG auA6TQQc1tPqVNodFYIyeIREwNYsGNoJSDa/ctKJStLSTqopeEuViqq1Du2aB4++qmbw I+Ej7CMy8tZUt+PyOXv/Uz1iUsZ2z1Ea6cQYC1PBNMCn9ugYSrTVxsCbN+AxAs7QhVQB wAUt4yjVEsMPdr2VI5nj6yFkgOD5eJ6DFqiU0D68CAP5MM8bnawlu0zILYPPR7WycM/6 mz3DHhTCQTuSUPS/4+y450WJUfPsdDhV2BVrlKS+84f7/gujKX8PhYE36DjiW6U4nmEV TsQw== X-Gm-Message-State: AODbwcAkrFsiDuhy56xR8siq07BWoaOWEHSqQxNHAiEpOAUJNC62EjO4 L2q0imqa5g9Urg== X-Received: by 10.223.136.43 with SMTP id d40mr391210wrd.168.1494343138457; Tue, 09 May 2017 08:18:58 -0700 (PDT) Received: from [172.24.226.96] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id c128sm1175751wmh.32.2017.05.09.08.18.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 08:18:57 -0700 (PDT) From: Bob Hinden Message-Id: <16BEF435-ACC9-4403-8A94-A866BCB8DD4B@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_3D6949B6-EA56-467C-A8CA-A0BCD2993185"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-00.txt Date: Tue, 9 May 2017 18:18:55 +0300 In-Reply-To: Cc: Bob Hinden , 6man@ietf.org To: Tom Herbert References: <149425780032.31731.10564902800308275421.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 15:19:03 -0000 --Apple-Mail=_3D6949B6-EA56-467C-A8CA-A0BCD2993185 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, I took a quick look at the draft. The biggest question I have have is = how realistic do you think that a source host could do anything useful = with this additional feedback. I found the text unconvincing. I would = like to hear more. Thanks, Bob > On May 8, 2017, at 6:43 PM, Tom Herbert wrote: >=20 > Hello, >=20 > This is a proposal for nodes (hosts or intermediate nodes) to send > ICMP errors when they drop packets because they're not able to process > headers because of processing limits. >=20 > Thanks, > Tom >=20 > ---------- Forwarded message ---------- > From: > Date: Mon, May 8, 2017 at 8:36 AM > Subject: New Version Notification for = draft-herbert-6man-icmp-limits-00.txt > To: Tom Herbert >=20 >=20 >=20 > A new version of I-D, draft-herbert-6man-icmp-limits-00.txt > has been successfully submitted by Tom Herbert and posted to the > IETF repository. >=20 > Name: draft-herbert-6man-icmp-limits > Revision: 00 > Title: ICMPv6 errors for discarding packets due to processing = limits > Document date: 2017-05-08 > Group: Individual Submission > Pages: 8 > URL: > = https://www.ietf.org/internet-drafts/draft-herbert-6man-icmp-limits-00.txt= > Status: = https://datatracker.ietf.org/doc/draft-herbert-6man-icmp-limits/ > Htmlized: = https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-00 > Htmlized: > = https://datatracker.ietf.org/doc/html/draft-herbert-6man-icmp-limits-00 >=20 >=20 > Abstract: > Network nodes may discards packets if they are unable to process > protocol headers of packets due to processing constraints or limits. > When such packets are dropped, the sender receives no indication so > it cannot take action to address the cause of discarded packets. = This > document defines ICMP errors that can be sent by a node that = discards > packets because it is unable to process the protocol headers. A > sender that receives such an ICMP error may be able to modify what = it > sends in future packets to avoid subsequent packet discards. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_3D6949B6-EA56-467C-A8CA-A0BCD2993185 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 iQEcBAEBCgAGBQJZEd3fAAoJEK7rdBF357uorbQH/R2rywadk4anUfCVczDgZlfb YN6TRPoCju1V8bnufEys2qXeHVgdpQa/OreGB8VQV6r/QebseFhjTQ//qkDrt898 3qZaeYlg7ZokluJEUwP4SfZbrkCGFpp1e1/DUw2pMMxhw6oaoOcsssFly8vIereN W02prQ7r8y3TiP7QkILdeCfdHka3A8YLk8Fm5gsbmziL+uEnF1Qw208xqBBaIm+0 LZtXF6XHm5AUnWPEyS8y/7IC37AvRsWusfFRXlkzWYxpJqk3ZJ7EsOLydENPR6CA C0BzIUYVhcEYA4YBuYwsSir+QcGfZCUfJnYE2TaSgO7b/zKe3y5w8dWEwnfrVIk= =IG5H -----END PGP SIGNATURE----- --Apple-Mail=_3D6949B6-EA56-467C-A8CA-A0BCD2993185-- From nobody Tue May 9 10:00:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7C7129BA2 for ; Tue, 9 May 2017 10:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMN9q5gaG6Hq for ; Tue, 9 May 2017 09:59:59 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 79FE21294B5 for <6man@ietf.org>; Tue, 9 May 2017 09:59:59 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id a72so6393247qkj.2 for <6man@ietf.org>; Tue, 09 May 2017 09:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QgMTSIFjGcfswS1G5wv91x6eY1RHzqoabtWXuSh4T8E=; b=ZwX8SUy3m6JatCQ5+KgzAEK5xzex64ejshmOUsozpwufUcOq7UhQvXrGzrYld4e21b mRYTWbm4ia+wmvtDA3xsjMF6/O25qZKX5NdNATT1pOjd6VzBOKZKoNU0kNG73Ueo/fHn ePbKiol48+/JgTxBx7BEa1x3eSajmLySTGS3o8LYeZ6SFGQ9RlOyKeMcaZvO0JIZItcL JygjYWRq8sWzDzCGPi/kEze8FZg8xBnjbIxRGKU0Aap8qBeykitkFOXUpCQhXT0s5WdH v/jL6M1rbYM+HIcx8bLx0sRnOOd40OoUdPhzUflPb5KuRupYx95v6ITrCCdXInYSspvb TQOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QgMTSIFjGcfswS1G5wv91x6eY1RHzqoabtWXuSh4T8E=; b=U2o60fZm6yOowpwJfZrq+Lfr/YghX2xU97nsbF7Iz7L7hCNwIB5I3bggjigLCBpeVn EzAAwT37vU9j83XfV9SeNc5n2cBSGhV3ejz4u3RN23dkwx5OOtxE5h1si8ULMfOa32jR WwjyUITSogpZg7qlhQyKrLt/UdSnApgSM+w4VONaeoLqt96+aX9EIsh1mhPjFleM+1n3 gns1bbmANfkZhIMJFU6WyvHg6kEyjrQVibxsFRH7s6plt/2tOlzXzk2iZBCjOvKLpAF+ dM1V0jBvQ760CGz0krjZRwlX+tmt8L9/dHh3yZmal333Sb8ZUlUM8XDPXj+XjzSGDgnw fWXg== X-Gm-Message-State: AODbwcB6FBZKlDwwM4PCQWxZ1ASH4c0h1FT73itXTrZniLo8UlQCOzSi TfoTrHnRBTEtmy1GWR+Wi+kjiTAGHg== X-Received: by 10.55.197.92 with SMTP id p89mr1153867qki.34.1494349198473; Tue, 09 May 2017 09:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 9 May 2017 09:59:57 -0700 (PDT) In-Reply-To: <16BEF435-ACC9-4403-8A94-A866BCB8DD4B@gmail.com> References: <149425780032.31731.10564902800308275421.idtracker@ietfa.amsl.com> <16BEF435-ACC9-4403-8A94-A866BCB8DD4B@gmail.com> From: Tom Herbert Date: Tue, 9 May 2017 09:59:57 -0700 Message-ID: Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-00.txt To: Bob Hinden Cc: 6man@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 17:00:01 -0000 On Tue, May 9, 2017 at 8:18 AM, Bob Hinden wrote: > Tom, > > I took a quick look at the draft. The biggest question I have have is how realistic do you think that a source host could do anything useful with this additional feedback. I found the text unconvincing. I would like to hear more. > Hi Bob, Thanks for looking at the draft! I think the most likely first response would be to stop using extension headers if we saw that they were causing packet drops. The second level of action is to alert the administrator so that configuration can be changed appropriately. The third level action, would be to try to automatically scale back the extension headers to be more palatable to whatever node is having a problem with them. In any case, I think having more information about why nodes are dropping packets can't be a bad thing even if we're just reporting this to the user to get some visibility into what network nodes are doing. Without this visibility and a significant chance of packets being dropped, it's likely hosts simply won't use extension headers and we'll continue to see alternate solutions that embed network layer information in UDP (like Spud, OAM in encaps) and in TCP (like proposals to write link characteristics into TCP options). I honestly don't know if having these errors will provide enough insight to make EH usable that we could consider it first class solution, but neither to see how maintaining status quo of nodes silently dropping packets with EH can move things forward either. Tom > Thanks, > Bob > >> On May 8, 2017, at 6:43 PM, Tom Herbert wrote: >> >> Hello, >> >> This is a proposal for nodes (hosts or intermediate nodes) to send >> ICMP errors when they drop packets because they're not able to process >> headers because of processing limits. >> >> Thanks, >> Tom >> >> ---------- Forwarded message ---------- >> From: >> Date: Mon, May 8, 2017 at 8:36 AM >> Subject: New Version Notification for draft-herbert-6man-icmp-limits-00.txt >> To: Tom Herbert >> >> >> >> A new version of I-D, draft-herbert-6man-icmp-limits-00.txt >> has been successfully submitted by Tom Herbert and posted to the >> IETF repository. >> >> Name: draft-herbert-6man-icmp-limits >> Revision: 00 >> Title: ICMPv6 errors for discarding packets due to processing limits >> Document date: 2017-05-08 >> Group: Individual Submission >> Pages: 8 >> URL: >> https://www.ietf.org/internet-drafts/draft-herbert-6man-icmp-limits-00.txt >> Status: https://datatracker.ietf.org/doc/draft-herbert-6man-icmp-limits/ >> Htmlized: https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-herbert-6man-icmp-limits-00 >> >> >> Abstract: >> Network nodes may discards packets if they are unable to process >> protocol headers of packets due to processing constraints or limits. >> When such packets are dropped, the sender receives no indication so >> it cannot take action to address the cause of discarded packets. This >> document defines ICMP errors that can be sent by a node that discards >> packets because it is unable to process the protocol headers. A >> sender that receives such an ICMP error may be able to modify what it >> sends in future packets to avoid subsequent packet discards. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Tue May 9 10:13:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66501294EE for ; Tue, 9 May 2017 10:13:15 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 x8OMTRJ321IL for ; Tue, 9 May 2017 10:13:13 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 BB2EF127735 for <6man@ietf.org>; Tue, 9 May 2017 10:13:13 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id u26so737401pfd.2 for <6man@ietf.org>; Tue, 09 May 2017 10:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gaXy2PTMkrl2XG9WqDnFtg45MXYaxDx33rLrldhhB0o=; b=hsiSsySq79prxI9l7K1DlCAQfsmhLdY8kfKvTBRPBhffDS2MwukWj0jlTlUU9wf0yu FvulhsolyPPA+NcZcbYXgsvjBFAwhLf1a0qxrlg6D2e1Os+ZYdz2QCbv+wEYS7T26ZLR OIsl5ofNMLKsNlxeOftyHnnaB6OlEtUk/27+OQ551qb9ZIpmyUD5YAeSV4afU0/N+ZEK Vs9Y5zJZlY4Ilh0d4stRihR5vCrSzkSVUBbG1XxRq0bWZJetJMNTv+wIH9h5z3lB3M1l bsNf4sUtqeHQ2XToyWXPrLN7qGCPzuqHyCe9j/VTqJupvuOF/S1w8xQMyIE8Lv3IcEcc Mg7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gaXy2PTMkrl2XG9WqDnFtg45MXYaxDx33rLrldhhB0o=; b=e2S/9OST9YZj2FNslOMUE5q14poIFWlJwD3qU2WGd4QpSUywfSm71boZoeXiltX0PG DEZIhz4jB7Y58ie9EGenPFwaxF0NYOMEpbPbHYO+F4G5wIR7rvT+ip0wPkbiCVnJqGW2 liet4lEqksUP38XAMvtf3WxM3ERXSYgN/racW+FoGSw0hONM9r/ihA/PDw0XrpCUcGzi +N22mLwm3gM+qUSRw6GEcmJ9q2/7Yr91Nqe+hd9Iyicwarb9Eak7woaPnkMVnmKrkvQV gYlLfj49fT1S52lvs/bW5ULO9IA5YKn/0tTpSZh0ZfPr8p2/zGoT+18HzwAH0Vz5SKKx rixw== X-Gm-Message-State: AODbwcC/pgUFXRWW8Dhi2oFU5UB3z2HxUSZe7Y4kSUocurFHbHrjvWOS PZ61qyASKkbXbw== X-Received: by 10.84.193.3 with SMTP id e3mr1674304pld.21.1494349993250; Tue, 09 May 2017 10:13:13 -0700 (PDT) Received: from [192.168.1.12] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id p62sm811883pfp.48.2017.05.09.10.13.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 10:13:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-00.txt From: Fred Baker In-Reply-To: Date: Tue, 9 May 2017 10:13:10 -0700 Cc: Bob Hinden , 6man@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149425780032.31731.10564902800308275421.idtracker@ietfa.amsl.com> <16BEF435-ACC9-4403-8A94-A866BCB8DD4B@gmail.com> To: Tom Herbert X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 17:13:16 -0000 I had similar questions. My first thought (looking at the abstract) was = that you intended to re-propose Source Quench in some form, and having = read it I'm concerned that this ICMP error would have the same problems. = The issue with Source Quench, as I recall, was that it wasn't = necessarily obvious to the sender what host to send it to (if it's a = router with a VPN tunnel, you want to get back to the host using the = VPN, not the router), it might not be obvious to the receiving host what = application to hand it to, and if it managed to pick the right one, it = might not be obvious what that application might propose to do. If it = has a window, I suppose it can reduce it, and if the issue is extension = headers, it can stop doing whatever it is doing.=20 But that has issues. If it's segment routing, for example, segment = routing operates from the assumption that the packet needs to visit one = or more services en route to wherever it's going. "Stop doing that" = means "don't visit those services". I think that eventually means "shut = down the session". If the question is Nalini's packet sequence number, = then she loses visibility into packet sequencing - and I don't know that = the application would be aware it was happening or how to change it. Oh, = you wanted to shut down IPsec?=20 I think it winds up going back to the operator of the network. = "Something smells out here". Not opposed to the draft, mind you. I think the instrumentation may be = valuable. But I think there are legitimate questions. On May 9, 2017, at 9:59 AM, Tom Herbert wrote: > On Tue, May 9, 2017 at 8:18 AM, Bob Hinden = wrote: >> Tom, >>=20 >> I took a quick look at the draft. The biggest question I have have = is how realistic do you think that a source host could do anything = useful with this additional feedback. I found the text unconvincing. I = would like to hear more. >>=20 > Hi Bob, >=20 > Thanks for looking at the draft! >=20 > I think the most likely first response would be to stop using > extension headers if we saw that they were causing packet drops. The > second level of action is to alert the administrator so that > configuration can be changed appropriately. The third level action, > would be to try to automatically scale back the extension headers to > be more palatable to whatever node is having a problem with them. >=20 > In any case, I think having more information about why nodes are > dropping packets can't be a bad thing even if we're just reporting > this to the user to get some visibility into what network nodes are > doing. Without this visibility and a significant chance of packets > being dropped, it's likely hosts simply won't use extension headers > and we'll continue to see alternate solutions that embed network layer > information in UDP (like Spud, OAM in encaps) and in TCP (like > proposals to write link characteristics into TCP options). I honestly > don't know if having these errors will provide enough insight to make > EH usable that we could consider it first class solution, but neither > to see how maintaining status quo of nodes silently dropping packets > with EH can move things forward either. >=20 > Tom >=20 >> Thanks, >> Bob >>=20 >>> On May 8, 2017, at 6:43 PM, Tom Herbert wrote: >>>=20 >>> Hello, >>>=20 >>> This is a proposal for nodes (hosts or intermediate nodes) to send >>> ICMP errors when they drop packets because they're not able to = process >>> headers because of processing limits. >>>=20 >>> Thanks, >>> Tom >>>=20 >>> ---------- Forwarded message ---------- >>> From: >>> Date: Mon, May 8, 2017 at 8:36 AM >>> Subject: New Version Notification for = draft-herbert-6man-icmp-limits-00.txt >>> To: Tom Herbert >>>=20 >>>=20 >>>=20 >>> A new version of I-D, draft-herbert-6man-icmp-limits-00.txt >>> has been successfully submitted by Tom Herbert and posted to the >>> IETF repository. >>>=20 >>> Name: draft-herbert-6man-icmp-limits >>> Revision: 00 >>> Title: ICMPv6 errors for discarding packets due to = processing limits >>> Document date: 2017-05-08 >>> Group: Individual Submission >>> Pages: 8 >>> URL: >>> = https://www.ietf.org/internet-drafts/draft-herbert-6man-icmp-limits-00.txt= >>> Status: = https://datatracker.ietf.org/doc/draft-herbert-6man-icmp-limits/ >>> Htmlized: = https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-00 >>> Htmlized: >>> = https://datatracker.ietf.org/doc/html/draft-herbert-6man-icmp-limits-00 >>>=20 >>>=20 >>> Abstract: >>> Network nodes may discards packets if they are unable to process >>> protocol headers of packets due to processing constraints or = limits. >>> When such packets are dropped, the sender receives no indication so >>> it cannot take action to address the cause of discarded packets. = This >>> document defines ICMP errors that can be sent by a node that = discards >>> packets because it is unable to process the protocol headers. A >>> sender that receives such an ICMP error may be able to modify what = it >>> sends in future packets to avoid subsequent packet discards. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue May 9 11:22:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4626612EAD2 for ; Tue, 9 May 2017 11:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yiI86xbdZiE for ; Tue, 9 May 2017 11:22:20 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 3B03A12EACC for <6man@ietf.org>; Tue, 9 May 2017 11:22:20 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id j29so8170522qtj.1 for <6man@ietf.org>; Tue, 09 May 2017 11:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8rnQNnuEO/Xkam2kjUqwVnSTS8t/CC2PY4isv1mKaVY=; b=Vl53SVmEO8Yaaffw6iEcgFmfZ/xtqZyPAaRsGSQaxzcPJHlJDhrfCP/lmeB/Yq4+g5 DUa46NrswjLMksiyoXL+jf3Gs6ofxySW65DUOzxbjEJgHpr7a/JRSkF+db77S2vvm9Ma US3cCvrOeLCgwgHB0/utkAskV4NwWE6DKes4QA/AOqmH14gUdybX1/QRUeYFsq0Jg6PU eGZJ5kIufv0FyHGuczsT8qZXBCfBni5LRVietOCzt7edH6xUyuSEhF8d7DjlhBaTy8qZ Dw9qQKTNDn9beARyZH3nFe9a22L8PwXRbSOzTIN25PMESTLBqy+cVAl6zsQB7AZOahSy UpDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8rnQNnuEO/Xkam2kjUqwVnSTS8t/CC2PY4isv1mKaVY=; b=h4t2viA1YmoqXLVvrY8Vkskgs+ccuwxAoO9pqnjZo14RR04Z/FQDDfO6PPv6yF8AOt MwKS1ud3+jXzPE3TU9Bw9E6ycG5t0etakp1HwQNS3R+j/iwCzV/dLHOLla0W6Ls9ev3d 8Aq+nlrNr/XglRlA3XuEyvuaSd+w7CCZsnvhfzk8iQuYrFYH1wKwzvA7ZXC6lq2zhAiU nkd4YofjRHwrzpI/Yqsihuyuz/G8pYFSIB/VJL8aNF0RJy+nLQd3e+JyAxjLiXH8Qb5Q o+gGPEZ8UdJIEEQGAqwRFgE+dmnyAFYSnkJCrg50quzFlcmJeDhkdayLAjviiyAGkxv0 2x9w== X-Gm-Message-State: AODbwcDipRy4AHoP5UCVbhqinfcnq0OsgAh+i63UxlTPrSbYxiJm2ALt jpbZrzIVEeNwnBR36PbtK2qTyNuQbQ== X-Received: by 10.200.43.146 with SMTP id m18mr1584932qtm.210.1494354139110; Tue, 09 May 2017 11:22:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 9 May 2017 11:22:18 -0700 (PDT) In-Reply-To: References: <149425780032.31731.10564902800308275421.idtracker@ietfa.amsl.com> <16BEF435-ACC9-4403-8A94-A866BCB8DD4B@gmail.com> From: Tom Herbert Date: Tue, 9 May 2017 11:22:18 -0700 Message-ID: Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-00.txt To: Fred Baker Cc: Bob Hinden , 6man@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 18:22:22 -0000 On Tue, May 9, 2017 at 10:13 AM, Fred Baker wrot= e: > I had similar questions. My first thought (looking at the abstract) was t= hat you intended to re-propose Source Quench in some form, and having read = it I'm concerned that this ICMP error would have the same problems. The iss= ue with Source Quench, as I recall, was that it wasn't necessarily obvious = to the sender what host to send it to (if it's a router with a VPN tunnel, = you want to get back to the host using the VPN, not the router), it might n= ot be obvious to the receiving host what application to hand it to, and if = it managed to pick the right one, it might not be obvious what that applica= tion might propose to do. If it has a window, I suppose it can reduce it, a= nd if the issue is extension headers, it can stop doing whatever it is doin= g. > Fred, I think if the packet is being dropped because of an extensions header limit then there is no ambiguity who should get the error-- it is source host since that is the one that created the EH chain in the first place (discounting the possibility that the EHs were inserted by an intermediate node). For the "headers too long case" I would agree that it's not immediately obvious who is the culprit for making the header too long in the case of tunneling (a tunnel ingress would get the error but is may have been the encapsulated packet that was loaded up with headers that put the length over the top). I suppose if the pointer is set in some encapsulated then the error could be forwarded to the original sender who might be able to act if the packet they sent contained optional data. > But that has issues. If it's segment routing, for example, segment routin= g operates from the assumption that the packet needs to visit one or more s= ervices en route to wherever it's going. "Stop doing that" means "don't vis= it those services". I think that eventually means "shut down the session". = If the question is Nalini's packet sequence number, then she loses visibili= ty into packet sequencing - and I don't know that the application would be = aware it was happening or how to change it. Oh, you wanted to shut down IPs= ec? > > I think it winds up going back to the operator of the network. "Something= smells out here". I believe that's true to the extent that the network operator would proactively cooperate with hosts and users to address the issue when it detects packet are being dropped, but I suspect in practice that doesn't happen until users start complaining about unexplained packet loss. Tom > > Not opposed to the draft, mind you. I think the instrumentation may be va= luable. But I think there are legitimate questions. > > On May 9, 2017, at 9:59 AM, Tom Herbert wrote: >> On Tue, May 9, 2017 at 8:18 AM, Bob Hinden wrote: >>> Tom, >>> >>> I took a quick look at the draft. The biggest question I have have is = how realistic do you think that a source host could do anything useful with= this additional feedback. I found the text unconvincing. I would like to= hear more. >>> >> Hi Bob, >> >> Thanks for looking at the draft! >> >> I think the most likely first response would be to stop using >> extension headers if we saw that they were causing packet drops. The >> second level of action is to alert the administrator so that >> configuration can be changed appropriately. The third level action, >> would be to try to automatically scale back the extension headers to >> be more palatable to whatever node is having a problem with them. >> >> In any case, I think having more information about why nodes are >> dropping packets can't be a bad thing even if we're just reporting >> this to the user to get some visibility into what network nodes are >> doing. Without this visibility and a significant chance of packets >> being dropped, it's likely hosts simply won't use extension headers >> and we'll continue to see alternate solutions that embed network layer >> information in UDP (like Spud, OAM in encaps) and in TCP (like >> proposals to write link characteristics into TCP options). I honestly >> don't know if having these errors will provide enough insight to make >> EH usable that we could consider it first class solution, but neither >> to see how maintaining status quo of nodes silently dropping packets >> with EH can move things forward either. >> >> Tom >> >>> Thanks, >>> Bob >>> >>>> On May 8, 2017, at 6:43 PM, Tom Herbert wrote: >>>> >>>> Hello, >>>> >>>> This is a proposal for nodes (hosts or intermediate nodes) to send >>>> ICMP errors when they drop packets because they're not able to process >>>> headers because of processing limits. >>>> >>>> Thanks, >>>> Tom >>>> >>>> ---------- Forwarded message ---------- >>>> From: >>>> Date: Mon, May 8, 2017 at 8:36 AM >>>> Subject: New Version Notification for draft-herbert-6man-icmp-limits-0= 0.txt >>>> To: Tom Herbert >>>> >>>> >>>> >>>> A new version of I-D, draft-herbert-6man-icmp-limits-00.txt >>>> has been successfully submitted by Tom Herbert and posted to the >>>> IETF repository. >>>> >>>> Name: draft-herbert-6man-icmp-limits >>>> Revision: 00 >>>> Title: ICMPv6 errors for discarding packets due to processing= limits >>>> Document date: 2017-05-08 >>>> Group: Individual Submission >>>> Pages: 8 >>>> URL: >>>> https://www.ietf.org/internet-drafts/draft-herbert-6man-icmp-limits-00= .txt >>>> Status: https://datatracker.ietf.org/doc/draft-herbert-6man-ic= mp-limits/ >>>> Htmlized: https://tools.ietf.org/html/draft-herbert-6man-icmp-li= mits-00 >>>> Htmlized: >>>> https://datatracker.ietf.org/doc/html/draft-herbert-6man-icmp-limits-0= 0 >>>> >>>> >>>> Abstract: >>>> Network nodes may discards packets if they are unable to process >>>> protocol headers of packets due to processing constraints or limits. >>>> When such packets are dropped, the sender receives no indication so >>>> it cannot take action to address the cause of discarded packets. This >>>> document defines ICMP errors that can be sent by a node that discards >>>> packets because it is unable to process the protocol headers. A >>>> sender that receives such an ICMP error may be able to modify what it >>>> sends in future packets to avoid subsequent packet discards. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of subm= ission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Tue May 9 11:26:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED39D127B31 for ; Tue, 9 May 2017 11:26:57 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 etrmw-Nv3Y1T for ; Tue, 9 May 2017 11:26:56 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 31EFA126FDC for <6man@ietf.org>; Tue, 9 May 2017 11:26:56 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id s62so911936pgc.0 for <6man@ietf.org>; Tue, 09 May 2017 11:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=a95rnG5byGf5WIFfwou4hAOIswJswKXiKdi2be06kMk=; b=s0rsSGiEsoC88+vh3G2CVzSVANa1PEHUejUKqtWHoGbNZo4SucUKCA+FVaD5whpJVh ADhjeQuuwIg/SEYdmEFJBzlqSVZmINXZnSDuXHQv2oK03dseQ/lQ5ybQ88EIQg1oWXNO BbfgURaRdNXUT4krFNuAq6djPEhCgA9T0+pU9WJY/aTC6RqXo5uxGJgpHqAHWFEHWx9B xHMSCEJcpwz8mBIqy3PqG0aDgGwA6l069BysB899Xi4PxO21Mlfuxn/4N+XviAYWqOuk 8utqOR0nY1FhJdFBKqr9U6vd2lF5y1R68N/TiAqGbViFGtZVkBOLZdTGKmnd28IkZteB 4WoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=a95rnG5byGf5WIFfwou4hAOIswJswKXiKdi2be06kMk=; b=kP0DSbK7tj56Lq4+A4NWrG9fsw1beg7qe6sUAzI74Dv5KLPpN4pjoy2qkhUD1G2JQb buZVmyPtiTel19iC9Nbn2KIAmLE+rrwpy+IUr3I/qNUYfC5k8/luKTr5u0xzp8iu0aBQ 57i9NEiLxjR3N5chuTCftHqwVFm/uWQtj0RT4ucN67qtzZWhxnjJ24uForfJZ5/69r+N 0fnVPRlq6+Pzai8jscijOtPvdjDm6EFu7W500jo3KhwLeQf6NJAylI04KdAbCj/j9WAI 6yke1JgbxFJXL5pxAZ+OmYsVkd9vCpaFYfpwVYYZ4neO16tswBw8VrR8p8zQgWyLsNUS MYAg== X-Gm-Message-State: AODbwcDWFV9iEVRhK340udwICedn1XFrGVEQ7/Y3RIvtM6SFKZ4DGGCi sQWs6yLBJo3dTQ== X-Received: by 10.99.130.73 with SMTP id w70mr1640447pgd.119.1494354415714; Tue, 09 May 2017 11:26:55 -0700 (PDT) Received: from [192.168.1.12] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id s186sm946648pfb.98.2017.05.09.11.26.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 11:26:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-00.txt From: Fred Baker In-Reply-To: Date: Tue, 9 May 2017 11:26:53 -0700 Cc: Bob Hinden , 6man@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149425780032.31731.10564902800308275421.idtracker@ietfa.amsl.com> <16BEF435-ACC9-4403-8A94-A866BCB8DD4B@gmail.com> To: Tom Herbert X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 18:26:58 -0000 Now that I think about it, if the router in question has enough = visibility to whine about an IP header, it is processing that header. It = may simply be parsing it (it has an ACL for a port number and is trying = to go find it, perhaps), but we're not talking about an interior header. = It's one the router is parsing. > On May 9, 2017, at 11:22 AM, Tom Herbert wrote: >=20 > On Tue, May 9, 2017 at 10:13 AM, Fred Baker = wrote: >> I had similar questions. My first thought (looking at the abstract) = was that you intended to re-propose Source Quench in some form, and = having read it I'm concerned that this ICMP error would have the same = problems. The issue with Source Quench, as I recall, was that it wasn't = necessarily obvious to the sender what host to send it to (if it's a = router with a VPN tunnel, you want to get back to the host using the = VPN, not the router), it might not be obvious to the receiving host what = application to hand it to, and if it managed to pick the right one, it = might not be obvious what that application might propose to do. If it = has a window, I suppose it can reduce it, and if the issue is extension = headers, it can stop doing whatever it is doing. >>=20 > Fred, >=20 > I think if the packet is being dropped because of an extensions header > limit then there is no ambiguity who should get the error-- it is > source host since that is the one that created the EH chain in the > first place (discounting the possibility that the EHs were inserted by > an intermediate node). >=20 > For the "headers too long case" I would agree that it's not > immediately obvious who is the culprit for making the header too long > in the case of tunneling (a tunnel ingress would get the error but is > may have been the encapsulated packet that was loaded up with headers > that put the length over the top). I suppose if the pointer is set in > some encapsulated then the error could be forwarded to the original > sender who might be able to act if the packet they sent contained > optional data. >=20 >> But that has issues. If it's segment routing, for example, segment = routing operates from the assumption that the packet needs to visit one = or more services en route to wherever it's going. "Stop doing that" = means "don't visit those services". I think that eventually means "shut = down the session". If the question is Nalini's packet sequence number, = then she loses visibility into packet sequencing - and I don't know that = the application would be aware it was happening or how to change it. Oh, = you wanted to shut down IPsec? >>=20 >> I think it winds up going back to the operator of the network. = "Something smells out here". >=20 > I believe that's true to the extent that the network operator would > proactively cooperate with hosts and users to address the issue when > it detects packet are being dropped, but I suspect in practice that > doesn't happen until users start complaining about unexplained packet > loss. >=20 > Tom >=20 >>=20 >> Not opposed to the draft, mind you. I think the instrumentation may = be valuable. But I think there are legitimate questions. >>=20 >> On May 9, 2017, at 9:59 AM, Tom Herbert wrote: >>> On Tue, May 9, 2017 at 8:18 AM, Bob Hinden = wrote: >>>> Tom, >>>>=20 >>>> I took a quick look at the draft. The biggest question I have have = is how realistic do you think that a source host could do anything = useful with this additional feedback. I found the text unconvincing. I = would like to hear more. >>>>=20 >>> Hi Bob, >>>=20 >>> Thanks for looking at the draft! >>>=20 >>> I think the most likely first response would be to stop using >>> extension headers if we saw that they were causing packet drops. The >>> second level of action is to alert the administrator so that >>> configuration can be changed appropriately. The third level action, >>> would be to try to automatically scale back the extension headers to >>> be more palatable to whatever node is having a problem with them. >>>=20 >>> In any case, I think having more information about why nodes are >>> dropping packets can't be a bad thing even if we're just reporting >>> this to the user to get some visibility into what network nodes are >>> doing. Without this visibility and a significant chance of packets >>> being dropped, it's likely hosts simply won't use extension headers >>> and we'll continue to see alternate solutions that embed network = layer >>> information in UDP (like Spud, OAM in encaps) and in TCP (like >>> proposals to write link characteristics into TCP options). I = honestly >>> don't know if having these errors will provide enough insight to = make >>> EH usable that we could consider it first class solution, but = neither >>> to see how maintaining status quo of nodes silently dropping packets >>> with EH can move things forward either. >>>=20 >>> Tom >>>=20 >>>> Thanks, >>>> Bob >>>>=20 >>>>> On May 8, 2017, at 6:43 PM, Tom Herbert = wrote: >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> This is a proposal for nodes (hosts or intermediate nodes) to send >>>>> ICMP errors when they drop packets because they're not able to = process >>>>> headers because of processing limits. >>>>>=20 >>>>> Thanks, >>>>> Tom >>>>>=20 >>>>> ---------- Forwarded message ---------- >>>>> From: >>>>> Date: Mon, May 8, 2017 at 8:36 AM >>>>> Subject: New Version Notification for = draft-herbert-6man-icmp-limits-00.txt >>>>> To: Tom Herbert >>>>>=20 >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-herbert-6man-icmp-limits-00.txt >>>>> has been successfully submitted by Tom Herbert and posted to the >>>>> IETF repository. >>>>>=20 >>>>> Name: draft-herbert-6man-icmp-limits >>>>> Revision: 00 >>>>> Title: ICMPv6 errors for discarding packets due to = processing limits >>>>> Document date: 2017-05-08 >>>>> Group: Individual Submission >>>>> Pages: 8 >>>>> URL: >>>>> = https://www.ietf.org/internet-drafts/draft-herbert-6man-icmp-limits-00.txt= >>>>> Status: = https://datatracker.ietf.org/doc/draft-herbert-6man-icmp-limits/ >>>>> Htmlized: = https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-00 >>>>> Htmlized: >>>>> = https://datatracker.ietf.org/doc/html/draft-herbert-6man-icmp-limits-00 >>>>>=20 >>>>>=20 >>>>> Abstract: >>>>> Network nodes may discards packets if they are unable to process >>>>> protocol headers of packets due to processing constraints or = limits. >>>>> When such packets are dropped, the sender receives no indication = so >>>>> it cannot take action to address the cause of discarded packets. = This >>>>> document defines ICMP errors that can be sent by a node that = discards >>>>> packets because it is unable to process the protocol headers. A >>>>> sender that receives such an ICMP error may be able to modify what = it >>>>> sends in future packets to avoid subsequent packet discards. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of = submission >>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>=20 >>>>> The IETF Secretariat >>>>>=20 >>>>> = -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 >>>>> = -------------------------------------------------------------------- >>>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 From nobody Tue May 9 12:27:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DC312955F for ; Tue, 9 May 2017 12:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmgLa8rj8O0b for ; Tue, 9 May 2017 12:27:34 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 B56551200B9 for <6man@ietf.org>; Tue, 9 May 2017 12:27:34 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id j29so9729287qtj.1 for <6man@ietf.org>; Tue, 09 May 2017 12:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iUKRgCnmNeTzuAmIKHGomjmA+6zr6aqsDx56IQM8ntw=; b=B5o98JM+92on5M252WYvAwiNoXnFQbI4JQO/XGKk1wRZm42bqJEm4N6FZJy0mXYOJ1 konXz5mh+JO1GQ6UYzyxYMwzCnAXuxkbOyKWqbvMDHTLSb8ydulL1/m0CFlHRCDvMkre ZmOnApE3dEKbf8cOqcIqrnzGuvHf2j+hIM1RCmtXLcU18Xix7OeN8SMN7QVPy4u5eMxk VW3jcILrG3mV+Ywl7j9m055QJHUx3d2K7JVYdGbXSvAXCSNQSnFyI5wtLkrP2P2xKLgL 4e9e1SdfECGzXus99BqtVvFn776eSRtIkP2LoHiW404aoBT8ZrKTmhXhT+xnxTFGxcoU YnJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iUKRgCnmNeTzuAmIKHGomjmA+6zr6aqsDx56IQM8ntw=; b=YVgCfgkQD/cRTZA3v3q/X7MnAalYtFhk+1aC3AItynPaTZAWylBacDKJ/Oiab/fVGT pip5o2N2cgjH4ibWJsIORCYHzpkkImmhCOo8G48HuSoATzVbB5xz/XDAoIgx+p8TcHey WqeNtplTPNKW4gLi2zPXRjtO7l7b4FL4c8HfV2xfd6/6b6bimwaYfVjMC7GmdNDXao5I 96GSnVCwDFIynmR5LjBZjKgQ8cngR0X2TITQtlLgv2LySkkV/QUITpI7f5Y8ngOL9sii X1w11fEUfuqyfdKtiNz/95f008vrRsE4lo/RzT/Q64JCKVfzmMSuhgX0DikQ+N1SlyPW rDQQ== X-Gm-Message-State: AODbwcBzcqH1WraYyEXRd7p8SO8TjK1iXjtNo3cBefVzr6ta4KWSnOmC 7jlkiNr1CgiDMW535g2mngsIZb3dQA== X-Received: by 10.237.36.3 with SMTP id r3mr2002839qtc.200.1494358053690; Tue, 09 May 2017 12:27:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 9 May 2017 12:27:33 -0700 (PDT) In-Reply-To: References: <149425780032.31731.10564902800308275421.idtracker@ietfa.amsl.com> <16BEF435-ACC9-4403-8A94-A866BCB8DD4B@gmail.com> From: Tom Herbert Date: Tue, 9 May 2017 12:27:33 -0700 Message-ID: Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-00.txt To: Fred Baker Cc: Bob Hinden , 6man@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 19:27:37 -0000 On Tue, May 9, 2017 at 11:26 AM, Fred Baker wrot= e: > Now that I think about it, if the router in question has enough visibilit= y to whine about an IP header, it is processing that header. It may simply = be parsing it (it has an ACL for a port number and is trying to go find it,= perhaps), but we're not talking about an interior header. It's one the rou= ter is parsing. > Right. If the node does not parse into any encapsulation then any packet loss because of a processing limit should be caused by extension headers (either they're too long or the is an unknown Next Header type). So the "headers too long" code should only be used when a node is parsing into encapsulation protocols and hits a limit (like parsing buffer size). Tom >> On May 9, 2017, at 11:22 AM, Tom Herbert wrote: >> >> On Tue, May 9, 2017 at 10:13 AM, Fred Baker w= rote: >>> I had similar questions. My first thought (looking at the abstract) was= that you intended to re-propose Source Quench in some form, and having rea= d it I'm concerned that this ICMP error would have the same problems. The i= ssue with Source Quench, as I recall, was that it wasn't necessarily obviou= s to the sender what host to send it to (if it's a router with a VPN tunnel= , you want to get back to the host using the VPN, not the router), it might= not be obvious to the receiving host what application to hand it to, and i= f it managed to pick the right one, it might not be obvious what that appli= cation might propose to do. If it has a window, I suppose it can reduce it,= and if the issue is extension headers, it can stop doing whatever it is do= ing. >>> >> Fred, >> >> I think if the packet is being dropped because of an extensions header >> limit then there is no ambiguity who should get the error-- it is >> source host since that is the one that created the EH chain in the >> first place (discounting the possibility that the EHs were inserted by >> an intermediate node). >> >> For the "headers too long case" I would agree that it's not >> immediately obvious who is the culprit for making the header too long >> in the case of tunneling (a tunnel ingress would get the error but is >> may have been the encapsulated packet that was loaded up with headers >> that put the length over the top). I suppose if the pointer is set in >> some encapsulated then the error could be forwarded to the original >> sender who might be able to act if the packet they sent contained >> optional data. >> >>> But that has issues. If it's segment routing, for example, segment rout= ing operates from the assumption that the packet needs to visit one or more= services en route to wherever it's going. "Stop doing that" means "don't v= isit those services". I think that eventually means "shut down the session"= . If the question is Nalini's packet sequence number, then she loses visibi= lity into packet sequencing - and I don't know that the application would b= e aware it was happening or how to change it. Oh, you wanted to shut down I= Psec? >>> >>> I think it winds up going back to the operator of the network. "Somethi= ng smells out here". >> >> I believe that's true to the extent that the network operator would >> proactively cooperate with hosts and users to address the issue when >> it detects packet are being dropped, but I suspect in practice that >> doesn't happen until users start complaining about unexplained packet >> loss. >> >> Tom >> >>> >>> Not opposed to the draft, mind you. I think the instrumentation may be = valuable. But I think there are legitimate questions. >>> >>> On May 9, 2017, at 9:59 AM, Tom Herbert wrote: >>>> On Tue, May 9, 2017 at 8:18 AM, Bob Hinden wrot= e: >>>>> Tom, >>>>> >>>>> I took a quick look at the draft. The biggest question I have have i= s how realistic do you think that a source host could do anything useful wi= th this additional feedback. I found the text unconvincing. I would like = to hear more. >>>>> >>>> Hi Bob, >>>> >>>> Thanks for looking at the draft! >>>> >>>> I think the most likely first response would be to stop using >>>> extension headers if we saw that they were causing packet drops. The >>>> second level of action is to alert the administrator so that >>>> configuration can be changed appropriately. The third level action, >>>> would be to try to automatically scale back the extension headers to >>>> be more palatable to whatever node is having a problem with them. >>>> >>>> In any case, I think having more information about why nodes are >>>> dropping packets can't be a bad thing even if we're just reporting >>>> this to the user to get some visibility into what network nodes are >>>> doing. Without this visibility and a significant chance of packets >>>> being dropped, it's likely hosts simply won't use extension headers >>>> and we'll continue to see alternate solutions that embed network layer >>>> information in UDP (like Spud, OAM in encaps) and in TCP (like >>>> proposals to write link characteristics into TCP options). I honestly >>>> don't know if having these errors will provide enough insight to make >>>> EH usable that we could consider it first class solution, but neither >>>> to see how maintaining status quo of nodes silently dropping packets >>>> with EH can move things forward either. >>>> >>>> Tom >>>> >>>>> Thanks, >>>>> Bob >>>>> >>>>>> On May 8, 2017, at 6:43 PM, Tom Herbert wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> This is a proposal for nodes (hosts or intermediate nodes) to send >>>>>> ICMP errors when they drop packets because they're not able to proce= ss >>>>>> headers because of processing limits. >>>>>> >>>>>> Thanks, >>>>>> Tom >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: >>>>>> Date: Mon, May 8, 2017 at 8:36 AM >>>>>> Subject: New Version Notification for draft-herbert-6man-icmp-limits= -00.txt >>>>>> To: Tom Herbert >>>>>> >>>>>> >>>>>> >>>>>> A new version of I-D, draft-herbert-6man-icmp-limits-00.txt >>>>>> has been successfully submitted by Tom Herbert and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Name: draft-herbert-6man-icmp-limits >>>>>> Revision: 00 >>>>>> Title: ICMPv6 errors for discarding packets due to processi= ng limits >>>>>> Document date: 2017-05-08 >>>>>> Group: Individual Submission >>>>>> Pages: 8 >>>>>> URL: >>>>>> https://www.ietf.org/internet-drafts/draft-herbert-6man-icmp-limits-= 00.txt >>>>>> Status: https://datatracker.ietf.org/doc/draft-herbert-6man-= icmp-limits/ >>>>>> Htmlized: https://tools.ietf.org/html/draft-herbert-6man-icmp-= limits-00 >>>>>> Htmlized: >>>>>> https://datatracker.ietf.org/doc/html/draft-herbert-6man-icmp-limits= -00 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> Network nodes may discards packets if they are unable to process >>>>>> protocol headers of packets due to processing constraints or limits. >>>>>> When such packets are dropped, the sender receives no indication so >>>>>> it cannot take action to address the cause of discarded packets. Thi= s >>>>>> document defines ICMP errors that can be sent by a node that discard= s >>>>>> packets because it is unable to process the protocol headers. A >>>>>> sender that receives such an ICMP error may be able to modify what i= t >>>>>> sends in future packets to avoid subsequent packet discards. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of su= bmission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> -------------------------------------------------------------------- >>>>>> IETF IPv6 working group mailing list >>>>>> ipv6@ietf.org >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> -------------------------------------------------------------------- >>>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> > From nobody Tue May 9 16:35:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693BB129534 for ; Tue, 9 May 2017 16:35:45 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bHmI1BXYzl_X for ; Tue, 9 May 2017 16:35:43 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8156F12869B for <6man@ietf.org>; Tue, 9 May 2017 16:35:43 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id u187so7182692pgb.0 for <6man@ietf.org>; Tue, 09 May 2017 16:35:43 -0700 (PDT) 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=p1/A7O4sOV+9aqH0OD3rEjVubdiTgop9YOBl+c32W6I=; b=KXlhIK/2pd72PTMukbCEpp7sfAcp1asaCobr6Deeg991QWzMQ3i1jBAzEa5jDQyilq E4AlOOzbwzRRptY+fMbkvRd8tALHL58cKHLsD6CaFRJHPrRmOtDlvyMv+EJGW51FwQaF TuFym5AxLBhVrCHv91de9wDVvnUscENLSvL2c7FnQ1K+v0Vod+p+rZdSYSLyb/ZWBfAH lV6KBXkFVQaYIZ/g/czgu6nUqY1HwV5Zvo6I9UIPaQDyvivsobBOIaHd0renhkhfdRV9 z4ovwBuSAZ4ER+R/0e2c8XNyPzMi/BP1QX3Ot0Uo5+1+F9uDDget/OBb966mToaRXxlZ Mtjg== 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=p1/A7O4sOV+9aqH0OD3rEjVubdiTgop9YOBl+c32W6I=; b=dnBgpWyWxoqx7OuC2tCWwGkFp3X2ECfBU39eNPiBXKsuGQHKuTzQU8QhLpnSMOCN3R td42HO5MXyKmzWM2oN4WP7uASOd6+LM8qDKfidUlRRuEjByeLYxqa6toWpXn5P139IXD lqwyeEFAt4ouJ2i994LgsA3Nd1eTiyCvFOvMz1c6jxOgNG0bHxn6IgMwE21WSG50Tii4 e6GPraow5FiuDT6+qTImuYUxP+cL8BDt1bvI6D6m1EaFpMmfdFRnSd1PjNhrDrdONNus NfnOgXY3uu/7FaYNuvB7qbh+p367Ste6b2eM7vLZjhthjAGWUT98x3AmVvwGS2ySv8JO 7Y8A== X-Gm-Message-State: AODbwcDOqS+fc3g+g/5063k7BgfIidpAfpp2f8CL6tr0r9pUGcPdlQmE Saw7Vt5X4+zqzw== X-Received: by 10.99.104.69 with SMTP id d66mr3068364pgc.93.1494372943072; Tue, 09 May 2017 16:35:43 -0700 (PDT) Received: from [130.216.38.30] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.30]) by smtp.gmail.com with ESMTPSA id r69sm1790030pfi.33.2017.05.09.16.35.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 16:35:42 -0700 (PDT) Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-00.txt To: Tom Herbert , Bob Hinden References: <149425780032.31731.10564902800308275421.idtracker@ietfa.amsl.com> <16BEF435-ACC9-4403-8A94-A866BCB8DD4B@gmail.com> Cc: 6man@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <90044e89-c14c-84b9-15d5-7bfe0c75574d@gmail.com> Date: Wed, 10 May 2017 11:35:43 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 23:35:45 -0000 On 10/05/2017 04:59, Tom Herbert wrote: > On Tue, May 9, 2017 at 8:18 AM, Bob Hinden wrote: >> Tom, >> >> I took a quick look at the draft. The biggest question I have have is how realistic do you think that a source host could do anything useful with this additional feedback. I found the text unconvincing. I would like to hear more. >> > Hi Bob, > > Thanks for looking at the draft! > > I think the most likely first response I think the zero'th level is for someone attempting to debug code using a given (possibly new or experimental) extension header. We shouldn't neglect that usage, because a probable scenario is to test a new header in the lab and declare it working, without being aware that it will be dropped on 25% of real-world paths. However, I think the fact that unrecognised ICMP messages are known to be dropped on many paths is a basic challenge for this idea. Unless we also add an ICMP message to report that an ICMP message has been dropped. [Half ;-)] > would be to stop using > extension headers if we saw that they were causing packet drops. The > second level of action is to alert the administrator so that > configuration can be changed appropriately. The third level action, > would be to try to automatically scale back the extension headers to > be more palatable to whatever node is having a problem with them. This sounds like Happy Eyeballs on steroids. I do think that diagnosis is the most important use of this idea. Brian > > In any case, I think having more information about why nodes are > dropping packets can't be a bad thing even if we're just reporting > this to the user to get some visibility into what network nodes are > doing. Without this visibility and a significant chance of packets > being dropped, it's likely hosts simply won't use extension headers > and we'll continue to see alternate solutions that embed network layer > information in UDP (like Spud, OAM in encaps) and in TCP (like > proposals to write link characteristics into TCP options). I honestly > don't know if having these errors will provide enough insight to make > EH usable that we could consider it first class solution, but neither > to see how maintaining status quo of nodes silently dropping packets > with EH can move things forward either. > > Tom > >> Thanks, >> Bob >> >>> On May 8, 2017, at 6:43 PM, Tom Herbert wrote: >>> >>> Hello, >>> >>> This is a proposal for nodes (hosts or intermediate nodes) to send >>> ICMP errors when they drop packets because they're not able to process >>> headers because of processing limits. >>> >>> Thanks, >>> Tom >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: Mon, May 8, 2017 at 8:36 AM >>> Subject: New Version Notification for draft-herbert-6man-icmp-limits-00.txt >>> To: Tom Herbert >>> >>> >>> >>> A new version of I-D, draft-herbert-6man-icmp-limits-00.txt >>> has been successfully submitted by Tom Herbert and posted to the >>> IETF repository. >>> >>> Name: draft-herbert-6man-icmp-limits >>> Revision: 00 >>> Title: ICMPv6 errors for discarding packets due to processing limits >>> Document date: 2017-05-08 >>> Group: Individual Submission >>> Pages: 8 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-herbert-6man-icmp-limits-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-herbert-6man-icmp-limits/ >>> Htmlized: https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-00 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-herbert-6man-icmp-limits-00 >>> >>> >>> Abstract: >>> Network nodes may discards packets if they are unable to process >>> protocol headers of packets due to processing constraints or limits. >>> When such packets are dropped, the sender receives no indication so >>> it cannot take action to address the cause of discarded packets. This >>> document defines ICMP errors that can be sent by a node that discards >>> packets because it is unable to process the protocol headers. A >>> sender that receives such an ICMP error may be able to modify what it >>> sends in future packets to avoid subsequent packet discards. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > . > From nobody Tue May 9 17:16:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A73129B97 for ; Tue, 9 May 2017 17:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIh5XaJTcqUv for ; Tue, 9 May 2017 17:16:27 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 124FD126CC7 for <6man@ietf.org>; Tue, 9 May 2017 17:16:27 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id y201so15448798qka.0 for <6man@ietf.org>; Tue, 09 May 2017 17:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CRO+kpGD9HT3SFp6cPr71nd3jJks52fW1ZRFY8c5KeA=; b=Vypw2umvUFHI+wNzoisBJFCOYXxkFqzV+rcW1V0UCA81H/SQ1wYc2Rgd7J4DV6Umzh OUXJIG2k9itIesac8u/q7Ip9RQu2HSp6vt+/FlDNuVL27AiwgAACE759HeoCJ327yAjC F7ttGwbjBwT3vq+2HP53FxoBx9bYYV8LZHvmcN4j2zpiDCNX4ClVQ+7OUJFyEfoLHSQp Zjvtiqd/cNmY8rpQgG70NZp2Ln1cPoPh5O6ZucE3vUagSlAc3oKaziE8wvnP3oOr3fVW 3nIjJYTufvLicd7JVvtpqJsWsYeAZdDUppjAc7K0X17POIY/8EtJvURuDGsR+umcLEsa PVVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CRO+kpGD9HT3SFp6cPr71nd3jJks52fW1ZRFY8c5KeA=; b=C48x+/rRZxhh11ic5ZNXACUVCTz0NAU2zQ7Hi2ssXtYkx0bvVrHF+bPE6ktBFJf6+k wIRGqicsmGHhlR4WwyNVgbQUB3gPESVcgimfvfKt/fBrO7lps2wE5n40mHRft1WOUb+S TqeDDtDS0G+WG1C+RXK5Qdc4jP9VUOh75yRSUejsb+gIif7gNqWu9MB16rwwkjJ2aTOC EDpIt78ggQUU4BBF9Ht+goL8Pf8nptB78XhID6Q9NMkSJY5Qc56jF7cMg7k6Hlkztizk TWGeYKqrsDex8z9l7GnqdjAJKdIHCYLUA+bBUDN58YCx6rLZzbAr3d2r8868IDnPeKpy gb3w== X-Gm-Message-State: AODbwcBCdzpvNqi+OzAsjqKbHvxZdbsBuZaeDusr3koIyDFQqgrknCja 6RiSQeV8bKVMOsA2sh1Kt6oPxi6cUQ== X-Received: by 10.55.89.196 with SMTP id n187mr2796760qkb.322.1494375386206; Tue, 09 May 2017 17:16:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 9 May 2017 17:16:25 -0700 (PDT) In-Reply-To: <90044e89-c14c-84b9-15d5-7bfe0c75574d@gmail.com> References: <149425780032.31731.10564902800308275421.idtracker@ietfa.amsl.com> <16BEF435-ACC9-4403-8A94-A866BCB8DD4B@gmail.com> <90044e89-c14c-84b9-15d5-7bfe0c75574d@gmail.com> From: Tom Herbert Date: Tue, 9 May 2017 17:16:25 -0700 Message-ID: Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-00.txt To: Brian E Carpenter Cc: Bob Hinden , 6man@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 00:16:28 -0000 On Tue, May 9, 2017 at 4:35 PM, Brian E Carpenter wrote: > On 10/05/2017 04:59, Tom Herbert wrote: >> On Tue, May 9, 2017 at 8:18 AM, Bob Hinden wrote: >>> Tom, >>> >>> I took a quick look at the draft. The biggest question I have have is how realistic do you think that a source host could do anything useful with this additional feedback. I found the text unconvincing. I would like to hear more. >>> >> Hi Bob, >> >> Thanks for looking at the draft! >> >> I think the most likely first response > > I think the zero'th level is for someone attempting to debug > code using a given (possibly new or experimental) extension > header. We shouldn't neglect that usage, because a probable > scenario is to test a new header in the lab and declare it > working, without being aware that it will be dropped on 25% > of real-world paths. > > However, I think the fact that unrecognised ICMP messages > are known to be dropped on many paths is a basic challenge > for this idea. Unless we also add an ICMP message to > report that an ICMP message has been dropped. [Half ;-)] > Are there any good statistics on ICMP being dropped in the Internet? >> would be to stop using >> extension headers if we saw that they were causing packet drops. The >> second level of action is to alert the administrator so that >> configuration can be changed appropriately. The third level action, >> would be to try to automatically scale back the extension headers to >> be more palatable to whatever node is having a problem with them. > > This sounds like Happy Eyeballs on steroids. I do think that > diagnosis is the most important use of this idea. Actually, I think we're trying to avoid having to do Happy Eyeballs for extension headers. The equivalent mechanism right now would be something like applications sending packets with different extensions headers, detecting loss, and so trying to reverse engineer based on packet loss (which requires transport layer input) which extension headers are allowed on the path to a destination and which aren't. I don't think any host implementation would ever actually implement that, it is far easier just to not use extension headers at all. Tom From nobody Tue May 9 17:58:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F2312EB84 for ; Tue, 9 May 2017 17:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 L1ajkAGJIUQS for ; Tue, 9 May 2017 17:58:08 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 8220A12EB7F for <6man@ietf.org>; Tue, 9 May 2017 17:58:08 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id u187so7979456pgb.0 for <6man@ietf.org>; Tue, 09 May 2017 17:58:08 -0700 (PDT) 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=OgkVUJsQxlIgCDiBfcCa0lqT4UojJdXCWUp91proBdA=; b=IcHj1bMC2LuyoVIpYmtHRkcLjOpooOF7aRNDRlDX04ALe5Mzqzxi04NQzaHG9xD/jC xDSXyqXPj5SYWRF83FQXMyFViZixSInw8U6Uzr5oqfUXD1n573IUQ2o/c6jKVBPbFeZo f2HTaMPCibuvGD1cvEghq7FL3RHWfuOvsvHZelS4/zQnpJFMJbbCnW3aVxWLgD/8zDGv AR8uqrRbAynnwOT7/VlVp63QRfylHNhqC4N3gYpvRvCK7AbY4X+M7hnh9YWKQDUy8R7k zuf+TB9UcyFlOXl8PQ4T/jXG0G7ZckkwOET+CsDyHZO9suE6urOoHxrwTmbuZ+ma0Svq tPBw== 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=OgkVUJsQxlIgCDiBfcCa0lqT4UojJdXCWUp91proBdA=; b=U3yTF46UzG+rW28GGYoFLtsSGVndt8rpDFpulbO5pEmWia2hbdVo+8WWZEAriY7PvC gnvL0s+1pY3cIqpE4AVPvW9E7WWRreRi569wlx6yztogXEdtCmmJbh5BRqCZabu4Aiq7 Vbef0GsCE424YCZrcMqwuh+mr5bgFJ522x/fscROy8QW5lJjeAuSr2yHNrKt509XfLgk Zb78xd3TjmUBBJbCz5Jw781I0VEwd8ZH+NQlylW+mTKio990CRGOd5j0n42qzNnDlLLX VUmarEg6HxMbwZJYOKItiWOZiYtivxOF8V4IWR9hm8mTezgpIWv1U9w/FTHDbacbKO27 17SQ== X-Gm-Message-State: AODbwcAuSy0vJvpRhFuPiORr43AxmS99t9to8k9h5bJ9RXUr+xHb8V9M 9a+QmwA/zsHiqQ== X-Received: by 10.84.196.100 with SMTP id k91mr4199315pld.165.1494377888039; Tue, 09 May 2017 17:58:08 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id y2sm2087445pfk.1.2017.05.09.17.58.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 17:58:07 -0700 (PDT) Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-00.txt To: Tom Herbert References: <149425780032.31731.10564902800308275421.idtracker@ietfa.amsl.com> <16BEF435-ACC9-4403-8A94-A866BCB8DD4B@gmail.com> <90044e89-c14c-84b9-15d5-7bfe0c75574d@gmail.com> Cc: Bob Hinden , 6man@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 10 May 2017 12:58:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 00:58:11 -0000 On 10/05/2017 12:16, Tom Herbert wrote: > On Tue, May 9, 2017 at 4:35 PM, Brian E Carpenter > wrote: >> On 10/05/2017 04:59, Tom Herbert wrote: >>> On Tue, May 9, 2017 at 8:18 AM, Bob Hinden wrote: >>>> Tom, >>>> >>>> I took a quick look at the draft. The biggest question I have have is how realistic do you think that a source host could do anything useful with this additional feedback. I found the text unconvincing. I would like to hear more. >>>> >>> Hi Bob, >>> >>> Thanks for looking at the draft! >>> >>> I think the most likely first response >> >> I think the zero'th level is for someone attempting to debug >> code using a given (possibly new or experimental) extension >> header. We shouldn't neglect that usage, because a probable >> scenario is to test a new header in the lab and declare it >> working, without being aware that it will be dropped on 25% >> of real-world paths. >> >> However, I think the fact that unrecognised ICMP messages >> are known to be dropped on many paths is a basic challenge >> for this idea. Unless we also add an ICMP message to >> report that an ICMP message has been dropped. [Half ;-)] >> > Are there any good statistics on ICMP being dropped in the Internet? In a current RFC1981bis thread Suresh Krishnan wrote: > > http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf > > shows about ~1% packet loss in ICMPv6 PTB messages compared to about > 4-6% for ICMPv4 PTB messages. Brian > >>> would be to stop using >>> extension headers if we saw that they were causing packet drops. The >>> second level of action is to alert the administrator so that >>> configuration can be changed appropriately. The third level action, >>> would be to try to automatically scale back the extension headers to >>> be more palatable to whatever node is having a problem with them. >> >> This sounds like Happy Eyeballs on steroids. I do think that >> diagnosis is the most important use of this idea. > > Actually, I think we're trying to avoid having to do Happy Eyeballs > for extension headers. The equivalent mechanism right now would be > something like applications sending packets with different extensions > headers, detecting loss, and so trying to reverse engineer based on > packet loss (which requires transport layer input) which extension > headers are allowed on the path to a destination and which aren't. I > don't think any host implementation would ever actually implement > that, it is far easier just to not use extension headers at all. > > Tom > From nobody Wed May 10 04:17:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE831129410 for ; Wed, 10 May 2017 04:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 H7DsjjDG0Nfo for ; Wed, 10 May 2017 04:17:05 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 6E499129B08 for <6man@ietf.org>; Wed, 10 May 2017 04:17:05 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 10 May 2017 11:17:04 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 2F45ED788A; Wed, 10 May 2017 04:17:04 -0700 (PDT) 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=Z5amthez0g6uTl7tl6zhTnKPJqA=; b= gehuq0TbI7AFRPI0898/TnjlfrbVXx99sjcSBE8Y1JDJoFFBoo6RlzxMvsT1yRj7 LgWzdKSAakfJNSyMVxe9gt8rdP/vDddNzBnUshszdEnFl/qHD9rfDiwb614KBAt2 4hRMYtIk0eUexX60tuZqkCpozitY54AJkgAC5OpaH/A= 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=s04D5RTF/6Ard3fVtZIB02g npzdVH+vYJQN3lpyY8ZRzs6toJ6EsuEJZ0L7QF72XXNd4uK+eh1QyGYf/OFwNlxB 88KaBCSP1VAhD9EEKJGtnWBA6gC3r815jNo0/QmlzTBw6rrppfssdqMxeAAKrNvT 5rvKN57lMWwAzR5uUa6Y= 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 03AD8D788B; Wed, 10 May 2017 04:17:04 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 041F2B9F9D50; Wed, 10 May 2017 13:17:02 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_070D3F9D-4BCE-4E7A-8495-0155064F3080"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-00.txt Date: Wed, 10 May 2017 13:17:01 +0200 In-Reply-To: Cc: Brian E Carpenter , 6man@ietf.org, Bob Hinden To: Tom Herbert References: <149425780032.31731.10564902800308275421.idtracker@ietfa.amsl.com> <16BEF435-ACC9-4403-8A94-A866BCB8DD4B@gmail.com> <90044e89-c14c-84b9-15d5-7bfe0c75574d@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 11:17:07 -0000 --Apple-Mail=_070D3F9D-4BCE-4E7A-8495-0155064F3080 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 >>> would be to stop using >>> extension headers if we saw that they were causing packet drops. The >>> second level of action is to alert the administrator so that >>> configuration can be changed appropriately. The third level action, >>> would be to try to automatically scale back the extension headers to >>> be more palatable to whatever node is having a problem with them. >>=20 >> This sounds like Happy Eyeballs on steroids. I do think that >> diagnosis is the most important use of this idea. >=20 > Actually, I think we're trying to avoid having to do Happy Eyeballs > for extension headers. The equivalent mechanism right now would be > something like applications sending packets with different extensions > headers, detecting loss, and so trying to reverse engineer based on > packet loss (which requires transport layer input) which extension > headers are allowed on the path to a destination and which aren't. I > don't think any host implementation would ever actually implement > that, it is far easier just to not use extension headers at all. Since it would take some time before all routers on all paths = implemented this, wouldn't applications have to deal with the smallest = common denominator anyway? If there is an application class that can chose based on received ICMP = if an extension header should be included or not, why wouldn't it not = send EH ever? I do see the point for troubleshooting though. Cheers, Ole --Apple-Mail=_070D3F9D-4BCE-4E7A-8495-0155064F3080 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 iQIcBAEBCgAGBQJZEvatAAoJEL7aWKiYQt92wjEQALg5KmgjRP57ICLi+49YRYrK LF4zVFc2Ev45qxGQZbCWTVyE7CH3oHuq/+RuYIAUUooCsIKW0HFxvXKOyg8aDR3m OqtlRtTbTJDpUBMeqr8InWCZC4wgkIhxMZYPHqUeeAvxtkm8ceAmwWlpYZevdU0/ w35O4ZokyovLmELNfA5oRtL6z57ButA1hlWVHMlhL1JqO/SSoTGHWkRB5YWbLGgX fVlEMs43cCWPYodfLKvy04xgdNuWriKcACozM21c5ylFwcQKf5+WEfnIvya+mqMv NYBZNDQyujIARl6P1ryoab3B5mnfYdWY63ecChOjUUBt7hQNg3zBvoJgdA0+RR86 31XOGTczD2dUa5uTDoj9iY7PWC14gtfOsMbMaLoZXhFW4PaFSVPQESlW/xcId1lw k2fPHe7uWRIcja2FyCu8TuV2o5wcoqimVUrrx5jd3fcJI7eCiIqQ40FTJDam1AfZ YG+AczGLLDss1Z01w9yA0n3wpBYQ5z6bmI/RqkCLBI+dpsWm6E2Eu5bvymMVn3c7 3N8ZJPeqmgm9feUA8TNr4aoHZiKj/XA+BXD6d7e0iBF0ubQjiTbkk4nZg2SfBeFS xCNhPPoWo4Yr2KnA/RnbsRZapZLw48DejhG7AJmRNVJtEEQ5As92Y9STyzH2AoSh GheB7xPALHVwEbmDpR7V =r/nn -----END PGP SIGNATURE----- --Apple-Mail=_070D3F9D-4BCE-4E7A-8495-0155064F3080-- From nobody Wed May 10 07:52:22 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 244A51294B8; Wed, 10 May 2017 07:52:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-6man-rfc1981bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: Spencer Dawkins' No Objection on draft-ietf-6man-rfc1981bis-06: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149442794014.1801.7413558506578974832.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 07:52:20 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 14:52:20 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-6man-rfc1981bis-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm watching the many e-mail threads on IESG ballot positions for this draft, but don't have anything to add. From nobody Wed May 10 08:53:07 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D53D5129C07; Wed, 10 May 2017 08:53:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-6man-rfc1981bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: Warren Kumari's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149443158586.30086.10156582311718173877.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 08:53:05 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:53:06 -0000 Warren Kumari has entered the following ballot position for draft-ietf-6man-rfc1981bis-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The OpsDir review (https://datatracker.ietf.org/doc/review-ietf-6man-rfc1981bis-04-opsdir-lc-hares-2017-03-04/ ) raises an interesting point, which I had not occurred to me. If the MTU for a path is 1440 bytes, and ND/RA suddenly says that the interface MTU is only 1400 bytes, what should implementations do? I'd expect something like decrease the path MTU (for all paths) to min (new link MTU, current path MTU), but it isn't (AFAICT) specified. It's entirely possible that this is a: already covered and / or b: covered at a different layer / different protocol, happy to be hit with a clue bat... ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please also see the OpsDir review.... I sent email about this to the authors on Feb 23rd - I seem to still have have many of the same questions... Comments: 1: Sec 1: "Path MTU Discovery relies on such messages to determine the MTU of the path." -- it is unclear which "such" refers to. Perhaps s/such/ICMPv6/ (or PTB). 2: Sec 3: "Upon receipt of such a message, the source node reduces its assumed PMTU for the path based on the MTU of the constricting hop as reported in the Packet Too Big message" -- this says that it reduces it *for the path*. But (as somewhat alluded to later in the draft) the nodes doesn't know what the path *is* -- it can decrease for the destination, or flow, or even interface, but (unless it is strict source routing) it doesn't control or really know the path (see also #4) 3: Sec 4: "The recommended setting for this timer is twice its minimum value (10 minutes)." - as above. This was from 1996 - were these metrics discussed at all during the -bis? I suspect that the average flow is much shorter these days (more web traffic, fatter pipes, etc) and so a flow of 10 minutes seems really long (to me at least). 4: Sec 5.2: "The packetization layers must be notified about decreases in the PMTU. Any packetization layer instance (for example, a TCP connection) that is actively using the path must be notified if the PMTU estimate is decreased. Note: even if the Packet Too Big message contains an Original Packet Header that refers to a UDP packet, the TCP layer must be notified if any of its connections use the given path." - this is related to #2 -- I don't know *which* path my packets take - once I launch them into the void, they may be routed purely based upon destination IP address, or they may be hashed based upon some set of header fields to a particular ECMP link or LSP. Once packets hit a load balancer, it is probably even *likely* that the UDP and TCP packets end up on different things. So, if I get a PTB from a router somewhere, I can probably guess that other packets to the same destination address will also follow that path, but I cannot know that for sure. I'm fine to decrease MTU towards that destination IP, but is that what this is suggesting? If so, please say that. If not, please let me know what I should do. The above is even more tricky / fun when I'm using flow id as the flow identifier -- if I get a PTB for flow 0x1234, what do I do? 5: Sec 5.3: "Once a minute, a timer-driven procedure runs through all cached PMTU values, and for each PMTU whose timestamp is not "reserved" and is older than the timeout interval ...". Please consider providing clarifications here. The wording implies that I should set a timer to fire on the minute, and trigger the behavior. If all of the (NTP synced!) machines in my datacenter do this, and all try send bigger packets (on 1/10th of long flows) their first hop router will get many, many over-sized packets and it will severely rate-limit the PTBs. Nits (Some of these are purely academic.) I understand that you are trying to limit the changes, so feel free to ignore these: 1: "A node sending packets much smaller than the Path MTU allows is wasting network resources and probably getting suboptimal throughput." - the "much" confuses me. If I'm using anything less than the MTU I'm wasting network resources and getting suboptimal throughput - I might not care, but if (used MTU) < (path MTU) I'm wasting resources. 2: "Nodes implementing Path MTU Discovery and sending packets larger than the IPv6 minimum link MTU are susceptible to problematic connectivity if ICMPv6 [ICMPv6] messages are blocked or not transmitted." The "implementing Path MTU Discovery and" seems redundant. ALL nodes sending packets larger than minimum MTU are "susceptible to problematic connectivity if ICMPv6 [ICMPv6] messages are blocked or not transmitted.". I get what you are trying to say, but my OCD tendencies would not allow me to ignore this... 3: "In the case of multipath routing (e.g., Equal Cost Multipath Routing, ECMP),"- this is vague / confusing -- (Equal Cost Multipath Routing, ECMP) makes it sound like either ECMP is an acronym for Equal Cost Multipath Routing, or that ECMP is something different to Equal Cost Multipath Routing. I'd suggest just dropping the "ECMP" (or, "Equal Cost Multipath (ECMP) routing", but that seems clumsy) From nobody Wed May 10 09:44:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D8D12E03D; Wed, 10 May 2017 09:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R55I8iBJRopO; Wed, 10 May 2017 09:44:04 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7B512E038; Wed, 10 May 2017 09:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4134; q=dns/txt; s=iport; t=1494434644; x=1495644244; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FRY1AvEh1HxqR7do5QPe7fUE3yY05Ru6rQo8U4slffo=; b=Vwl9ua/dhtkRMmXyJaVpW0UYCUbY16qRDiskaaWVI0MTX5ApxxDx1ld+ iPKu42boWhi6iJsodfFcra7UzMArv6UeW6xX1LUGrPILJXX/CEgPRnTE1 mrQeroGL7KUCqraXfiEZMgFh7khJOCE2ydOmdBAmf7vTU9vOG1532m7Qp Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAQAHQxNZ/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHg2KKGJE3IYgjjU+CDzCFdAIahGY/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEjEUUFCwIBCBgCAiYCAgIfERUQAgQOBYoJAw0IDrJOgiaHMA2DO?= =?us-ascii?q?AEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFVIIJC4JlglRNgRMSARwXgncvgjE?= =?us-ascii?q?FiUSNK4ZgOwGHG4cshFOCBIU7iiyIf4IuiRUBHzh/C3AVWAGEYxyBY3YBBIZmg?= =?us-ascii?q?SGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,320,1491264000"; d="scan'208";a="243639846" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2017 16:43:58 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v4AGhwNh006383 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2017 16:43:58 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 10 May 2017 11:43:57 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 10 May 2017 11:43:57 -0500 From: "Alvaro Retana (aretana)" To: Bob Hinden CC: IESG , "draft-ietf-6man-rfc1981bis@ietf.org" , =?utf-8?B?T2xlIFRyw7hhbg==?= , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "IPv6 List" Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS) Thread-Topic: Alvaro Retana's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS) Thread-Index: AQHSyD13a2qFc/dLUUCwfmCsNV+SLKHsZvUAgAFyj4A= Date: Wed, 10 May 2017 16:43:57 +0000 Message-ID: <2E927CD3-327A-4160-88D9-B901D9D532EA@cisco.com> References: <149427694020.22664.10344820301651708437.idtracker@ietfa.amsl.com> <5DE424DC-F18D-417B-B547-62F49A04B6C1@gmail.com> In-Reply-To: <5DE424DC-F18D-417B-B547-62F49A04B6C1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 16:44:07 -0000 VGhhbmtzIEJvYiwgdGhhdCB3b3JrcyBmb3IgbWUuDQoNCkFsdmFyby4NCg0KT24gNS85LzE3LCAx MDozNyBBTSwgIkJvYiBIaW5kZW4iIDxib2IuaGluZGVuQGdtYWlsLmNvbT4gd3JvdGU6DQoNCkFs dmFybywNCg0KQmFzZWQgb24geW91ciBEaXNjdXNzLCBJIGFtIHBsYW5uaW5nIHRvIGFkZDoNCg0K ICAgTm90ZTogVGhpcyBkb2N1bWVudCBpcyBhbiB1cGRhdGUgdG8gW1JGQzE5ODFdIHRoYXQgd2Fz IHB1Ymxpc2hlZA0KICAgcHJpb3IgdG8gW1JGQzIxMTldIGJlaW5nIHB1Ymxpc2hlZC4gIENvbnNl cXVlbnRseSB3aGlsZSBpdCBkb2VzIHVzZQ0KICAgInNob3VsZC9tdXN0IiBzdHlsZSBsYW5ndWFn ZSBpbiB1cHBlciBhbmQgbG93ZXIgY2FzZSwgdGhlIGRvY3VtZW50DQogICBkb2VzIG5vdCBjaXRl IHRoZSBSRkMyMTE5IGRlZmluaXRpb25zLiAgVGhpcyB1cGRhdGUgZG9lcyBub3QgY2hhbmdlDQog ICB0aGF0Lg0KDQpUbyB0aGUgSW50cm9kdWN0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBJdCBzaG91 bGQgYXBwZWFyIGluIHRoZSBuZXh0IHB1Ymxpc2hlZCB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQuDQoN ClRoYW5rcywNCkJvYg0KDQoNCg0KPiBPbiBNYXkgOCwgMjAxNywgYXQgMTE6NTUgUE0sIEFsdmFy byBSZXRhbmEgPGFyZXRhbmFAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+IEFsdmFybyBSZXRhbmEg aGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWll dGYtNm1hbi1yZmMxOTgxYmlzLTA2OiBEaXNjdXNzDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBs ZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gZW1h aWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUg dG8gY3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiAN Cj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rp c2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJ U0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxv bmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02bWFuLXJmYzE5ODFiaXMv DQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiANCj4gSSdtIHB1dHRpbmcgaW4gdGhpcyBwb2ludCBhcyBhIERJU0NVU1MgYmVjYXVzZSBJ IHRoaW5rIHRoYXQgdGhlIGN1cnJlbnQNCj4gdGV4dCBtYXkgYmUgY29uZnVzaW5nIGFuZCB2YWd1 ZS4NCj4gDQo+IEFzIG90aGVycyBoYXZlIHBvaW50ZWQgb3V0LCB0aGlzIGRvY3VtZW50IGluY2x1 ZGVzIHJmYzIxMTktbGlrZSBsYW5ndWFnZSwNCj4gYm90aCBjYXBpdGFsaXplZCBhbmQgbm90LiAg SSByZWFsaXplIHRoYXQgcmZjMTk4MSB3YXMgcHVibGlzaGVkIGJlZm9yZQ0KPiByZmMyMTE5IGFu ZCB0aGF0IG5vIGV4cGVjdGF0aW9uIG9uIHRoZSBsYW5ndWFnZSBleGlzdGVkIHRoZW4uICBIb3dl dmVyLA0KPiB3ZSdyZSBhdCBhIHBvaW50IGluIHRpbWUgd2hlcmUgbm90IG9ubHkgcmZjMjExOSBp cyBpbiBwbGFjZSwgYnV0DQo+IGRyYWZ0LWxlaWJhLXJmYzIxMTktdXBkYXRlICh3aGljaCBjbGFy aWZpZXMgdGhhdCBvbmx5IHVwcGVyY2FzZSBsYW5ndWFnZQ0KPiBoYXMgc3BlY2lhbCBtZWFuaW5n KSBpcyBpbiBBVVRINDguICBJIHRoaW5rIHRoYXQgdGhpcyBsZWFkcyB0byB0aGUNCj4gcG9zc2li aWxpdHkgdGhhdCB0aGUgYXZlcmFnZSByZWFkZXIgbWF5IGludGVycHJldCB0aGUgcmVxdWlyZW1l bnRzIGluDQo+IHRoaXMgZG9jdW1lbnQgaW4gYSB3YXkgdGhhdCBpdCB3YXNuJ3QgaW50ZW5kZWQu DQo+IA0KPiBXaGlsZSBJIHdvdWxkIHByZWZlciB0aGF0IHRoaXMgZG9jdW1lbnQgYmUgY29uc2lz dGVudCAoYW5kIGVpdGhlciB1c2UNCj4gY2FwaXRhbGl6ZWQgcmZjMjExOSBsYW5ndWFnZSBhcyBp bnRlbmRlZCwgT1IsIG5vdCB1c2VkIGl0IGF0IGFsbCksIEkNCj4gdW5kZXJzdGFuZCB0aGUgaW50 ZW50IG9mIG5vdCBjaGFuZ2luZyBzb21lIG9mIHRoZSBvcmlnaW5hbCB0ZXh0LiAgSSB3b3VsZA0K PiBiZSBoYXBweSB3aXRoIGEgbm90ZSBsaWtlIHRoaXMgb25lOiAiTm90ZTogIFRoaXMgZG9jdW1l bnQgaXMgYW4gdXBkYXRlIHRvDQo+IFJGQzE5ODEgdGhhdCB3YXMgcHVibGlzaGVkIHByaW9yIHRv IFJGQzIxMTkgYmVpbmcgcHVibGlzaGVkLg0KPiBDb25zZXF1ZW50bHkgd2hpbGUgaXQgZG9lcyB1 c2UgInNob3VsZC9tdXN0IiBzdHlsZSBsYW5ndWFnZSBpbiB1cHBlciBhbmQNCj4gbG93ZXIgY2Fz ZSwgdGhlIGRvY3VtZW50IGRvZXMgbm90IGNpdGUgdGhlIFJGQzIxMTkgZGVmaW5pdGlvbnMuICBU aGlzDQo+IHVwZGF0ZSBkb2VzIG5vdCBjaGFuZ2UgdGhhdC4iICAgW0kgYm9ycm93ZWQgdGhpcyB0 ZXh0IGZyb20gdGhlIHRoZSBJTlRESVINCj4gcmV2aWV3IHRocmVhZC4gWzFdXQ0KPiANCj4gSSBm aW5kIHRoYXQgaW5jbHVkaW5nIGEgbm90ZSBpbiB0aGUgU2hlcGhlcmQncyB3cml0ZS11cCBpcyBu b3QgZW5vdWdoDQo+IGJlY2F1c2UgdGhlIGF2ZXJhZ2UgcmVhZGVyL2ltcGxlbWVudGVyIHdpbGwg bm90IGNvbnN1bHQgaXQuDQo+IA0KPiANCj4gWzFdDQo+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvaW50LWRpci9iVkhfMHlkVmRHc3NPaXN6SktoUVhMWVB1WFkvP3FpZD00 MDAwZjhhOTU0YjIyNjI2NmY0Mjk4NDI5MTExMDFmNQ0KPiANCj4gDQo+IA0KPiANCg0KDQoNCg== From nobody Wed May 10 11:06:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8626F129BEE for ; Wed, 10 May 2017 11:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeB_3l1Z3zmP for ; Wed, 10 May 2017 11:06:30 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 3BDBE129473 for <6man@ietf.org>; Wed, 10 May 2017 11:06:30 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id j29so3064042qtj.1 for <6man@ietf.org>; Wed, 10 May 2017 11:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iG9KcvVE0nxFCsyGWkWPb1+lDA9S9a7JksQH3t2KFVs=; b=x2d4Rt1qO2NSbsfxtpSsEknXMnhKkcTY/xH5p48D7PZ2gvNWfLvNRUOJBztfvSjmIH 0VKPgyVQlEzZtPAk0rA1lrfS6o3WQdjXtTFgHPuS+ILQ0eW7d1FyWau1JJRyBKnZCOLW erloTbfe+VWSKPBOZyW0Hi1SDVn++uaTqyG8RmsvH6r/igXMZ2R+UCrcgmC0OUe2sMzb HGTB8m0y+llUdUn7abntRY9nJ0N36zCyf0+FMsFcAMY0feETd230UkKebMk8Oy49IpQT p9J/wMkBDMBCJ7Jkno3CcNlKOqUu+66msOT/P7GHlCXVVEOVIXRYjyXAoltyBIsKzWu8 i6HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iG9KcvVE0nxFCsyGWkWPb1+lDA9S9a7JksQH3t2KFVs=; b=Fr5mgFHsGWwXQf5eyiqGZOeqiHSLSVXJszMkn4LdLMwZEVlnP4dx5+jD3NeOZ4LewJ SVxFUt6lFqCdvosHYQcv8zFl1SCWy+w2ecYkvYgG6uzQRTi2RGUsyWTa+07j4s3weZ9J 5m5ahUjjqp+G6yiOYsl7+pQI9LJPKLjn0yjYwHTd6ps9QuRxL8r/e9mUXzvcDgy/ZP+n TGCp1excDPeR730yliS5UUkSoKTVjjnq6gcNxx2ctX8sH4XzVp1JBYt7zGPraV0hobqW rbZ+SQVUNVb0+FNfV/gtUcRgXWm4xvo6Yg/OLeZBk32bNqrjQ2q6sSUY8f//7IP6qO2k aRLw== X-Gm-Message-State: AODbwcCAIe2lQXLC+ql4JdOR4iwvVnxW1AuzN5N007Ll2R6E7in+b3Lh riyS7EjwaGmsOGYAudhTCK0PuTbPRw== X-Received: by 10.237.61.28 with SMTP id g28mr6782150qtf.279.1494439588768; Wed, 10 May 2017 11:06:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Wed, 10 May 2017 11:06:28 -0700 (PDT) In-Reply-To: References: <149425780032.31731.10564902800308275421.idtracker@ietfa.amsl.com> <16BEF435-ACC9-4403-8A94-A866BCB8DD4B@gmail.com> <90044e89-c14c-84b9-15d5-7bfe0c75574d@gmail.com> From: Tom Herbert Date: Wed, 10 May 2017 11:06:28 -0700 Message-ID: Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-00.txt To: Ole Troan Cc: Brian E Carpenter , 6man@ietf.org, Bob Hinden Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 18:06:31 -0000 On Wed, May 10, 2017 at 4:17 AM, wrote: >> >>>> would be to stop using >>>> extension headers if we saw that they were causing packet drops. The >>>> second level of action is to alert the administrator so that >>>> configuration can be changed appropriately. The third level action, >>>> would be to try to automatically scale back the extension headers to >>>> be more palatable to whatever node is having a problem with them. >>> >>> This sounds like Happy Eyeballs on steroids. I do think that >>> diagnosis is the most important use of this idea. >> >> Actually, I think we're trying to avoid having to do Happy Eyeballs >> for extension headers. The equivalent mechanism right now would be >> something like applications sending packets with different extensions >> headers, detecting loss, and so trying to reverse engineer based on >> packet loss (which requires transport layer input) which extension >> headers are allowed on the path to a destination and which aren't. I >> don't think any host implementation would ever actually implement >> that, it is far easier just to not use extension headers at all. > Hi Ole, > Since it would take some time before all routers on all paths implemented this, wouldn't applications have to deal with the smallest common denominator anyway? > Maybe, but I don't think that we want to wait for all routers to implement it. The path to getting some real usage of extension headers would probably start in local networks (like SR might be used to get packets across a proprietary network). > If there is an application class that can chose based on received ICMP if an extension header should be included or not, why wouldn't it not send EH ever? > Because the EH may be optional information. For instance, if a host can set SR maybe hop by hop options maybe it can get optimized routing or better service, without those maybe packets still flow but in a sub-optimal manner. Tom > I do see the point for troubleshooting though. > > Cheers, > Ole From nobody Wed May 10 12:16:01 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E54F8126B6D; Wed, 10 May 2017 12:15:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-6man-rfc1981bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: Ben Campbell's No Objection on draft-ietf-6man-rfc1981bis-06: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149444375293.16653.8255058613288580161.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 12:15:52 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 19:15:53 -0000 Ben Campbell has entered the following ballot position for draft-ietf-6man-rfc1981bis-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree Alvaro's DISCUSS point about 2119 language. From nobody Wed May 10 14:45:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E88129B66; Wed, 10 May 2017 14:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 drUzGIvmjA4M; Wed, 10 May 2017 14:45:49 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 206AC1294E0; Wed, 10 May 2017 14:45:49 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id w50so6620903wrc.0; Wed, 10 May 2017 14:45:49 -0700 (PDT) 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=/vQzd0IjbpxMKJBKO2Pv7vVT0KxXXP84OAgbEySneBk=; b=UzmOf6/Y65j6FHX6jtun6lmSxaRaNgJsyxgr/cue7dRlndp5FVc+k8R5NnQ841m4ca mjqCpBEa+fHrQDnpqcZPGP1VkfZAr4qxi/HVeyS3Dp2QTHJbSJUO/b/yFBNx0qhLcinC maTh+ni3C4dKvvBVrXD4n32JX35zXjSgXwxSj9Hv5+IwVnHvA0VZGcEwn+0u3jG6+W2y NagN0lBq3osFXK2Yi87CMpujnU4cYHOh7hruwSkq3bW09VLrRj1rdJekp6UOvJrnG2oV hDpLFZk+8Lf1zknHQCwGDDjPsQC+NMQcDT7toVmnJ2hbw2lUCC6zG0zYFBBoIMtGSvet fziw== 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=/vQzd0IjbpxMKJBKO2Pv7vVT0KxXXP84OAgbEySneBk=; b=NbL9FQVKLRJ9mIqgvJhc2Pn+MNxm1G/tdPhG0GkbQwMhlX7Ijtkt3MvxOOceurB4mF Mk3aFUGXYHPwjhuIpCi4bOj/wyUW9YEhg/LMjwCwxl12igjcCXeWfN63n+AiPN4gl7an VTDQeI+4BuWgD02BnqL9kt1zOwe3x1bDlgQx0eiPzNlVdkdwAMeibjBJt8sIrgQ4n6i7 zOhdraCp/aqnNeUxpqMYRYdpL/HixO4rdz21hZesod2UVVqXRILDrZkdClOaffoboXYk GMXv+FVsAwYT/X+REfwlnm2au/5XbBiRIRCPsPEEYEzX4QMcDP6+5of6wg2AHwMx0lUk B8/A== X-Gm-Message-State: AODbwcBqgjHfVKafe5oqCD21XYiE4UoAiRhZv5iTsBtCqD1eAxp2RRjP dB/g8f12n/RhBA== X-Received: by 10.223.135.187 with SMTP id b56mr5175539wrb.170.1494452747660; Wed, 10 May 2017 14:45:47 -0700 (PDT) Received: from [100.73.145.227] ([69.38.167.222]) by smtp.gmail.com with ESMTPSA id w17sm5522914wme.13.2017.05.10.14.45.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 14:45:46 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_36B0DED6-2605-4413-BA3D-663378A5E79E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS) Date: Wed, 10 May 2017 17:45:43 -0400 In-Reply-To: <2E927CD3-327A-4160-88D9-B901D9D532EA@cisco.com> Cc: Bob Hinden , IESG , "draft-ietf-6man-rfc1981bis@ietf.org" , =?utf-8?Q?Ole_Tr=C3=B8an?= , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, IPv6 List To: "Alvaro Retana (aretana)" References: <149427694020.22664.10344820301651708437.idtracker@ietfa.amsl.com> <5DE424DC-F18D-417B-B547-62F49A04B6C1@gmail.com> <2E927CD3-327A-4160-88D9-B901D9D532EA@cisco.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 21:45:51 -0000 --Apple-Mail=_36B0DED6-2605-4413-BA3D-663378A5E79E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alvaro, Thanks! Bob > On May 10, 2017, at 12:43 PM, Alvaro Retana (aretana) = wrote: >=20 > Thanks Bob, that works for me. >=20 > Alvaro. >=20 > On 5/9/17, 10:37 AM, "Bob Hinden" wrote: >=20 > Alvaro, >=20 > Based on your Discuss, I am planning to add: >=20 > Note: This document is an update to [RFC1981] that was published > prior to [RFC2119] being published. Consequently while it does use > "should/must" style language in upper and lower case, the document > does not cite the RFC2119 definitions. This update does not change > that. >=20 > To the Introduction of this document. It should appear in the next = published version of this draft. >=20 > Thanks, > Bob >=20 >=20 >=20 >> On May 8, 2017, at 11:55 PM, Alvaro Retana wrote: >>=20 >> Alvaro Retana has entered the following ballot position for >> draft-ietf-6man-rfc1981bis-06: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> I'm putting in this point as a DISCUSS because I think that the = current >> text may be confusing and vague. >>=20 >> As others have pointed out, this document includes rfc2119-like = language, >> both capitalized and not. I realize that rfc1981 was published = before >> rfc2119 and that no expectation on the language existed then. = However, >> we're at a point in time where not only rfc2119 is in place, but >> draft-leiba-rfc2119-update (which clarifies that only uppercase = language >> has special meaning) is in AUTH48. I think that this leads to the >> possibility that the average reader may interpret the requirements in >> this document in a way that it wasn't intended. >>=20 >> While I would prefer that this document be consistent (and either use >> capitalized rfc2119 language as intended, OR, not used it at all), I >> understand the intent of not changing some of the original text. I = would >> be happy with a note like this one: "Note: This document is an = update to >> RFC1981 that was published prior to RFC2119 being published. >> Consequently while it does use "should/must" style language in upper = and >> lower case, the document does not cite the RFC2119 definitions. This >> update does not change that." [I borrowed this text from the the = INTDIR >> review thread. [1]] >>=20 >> I find that including a note in the Shepherd's write-up is not enough >> because the average reader/implementer will not consult it. >>=20 >>=20 >> [1] >> = https://mailarchive.ietf.org/arch/msg/int-dir/bVH_0ydVdGssOiszJKhQXLYPuXY/= ?qid=3D4000f8a954b226266f429842911101f5 >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_36B0DED6-2605-4413-BA3D-663378A5E79E 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 iQEcBAEBCgAGBQJZE4oHAAoJEK7rdBF357uoLm0IALV1SGkHgSg/3m27+bXsFEIp 79CzJjJTVrV562uo4jVajoXSzOCnu+aQczxTBjKUKheXGKkp7PITL4UMCk+k75UK zEop0WXWGX0eMygE6sdS+NPf1vVuz+3LtKB3wc8f6RNNb/BQBUsuLyQCIabhBa0W vSONw+FoDBsusP86bQJLqAMnbsKXBSk+iNAf9SOs3VBJAI2chYvRkGKkyR7o37Yt +xDjnkouqT1uG1hZf8sm7Bomw4cHjBlOVhLNx27FCK+hbQqvAguXZKVI/2lRz5I2 YnmHbX6TJ+LL2Z/rMWTZLuY4euw86t3298yENd3Nb6X3dTn6NjDb2tITEqlhAcc= =JWI8 -----END PGP SIGNATURE----- --Apple-Mail=_36B0DED6-2605-4413-BA3D-663378A5E79E-- From nobody Wed May 10 15:22:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9A5129A99 for ; Wed, 10 May 2017 15:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4NeckkN-9Hr for ; Wed, 10 May 2017 15:22:11 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 BE1501200C5 for <6man@ietf.org>; Wed, 10 May 2017 15:22:11 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id j29so4213932qtj.1 for <6man@ietf.org>; Wed, 10 May 2017 15:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=/s3QiuGOq/bnkqDr88Yb/4C3yy0KGxdWIkFkoMyhaDk=; b=lPJPysny3htwFWsduaw6IUrfrr9jzKNLBJkCecdztYNzsjxsoWq5y2Do/xooFWzIre O/Uks5oJIT0lwrXABPi7HiC0zQODhLRopxTyZfed2rxlX35b0Gyd1MNkfRSoddrfchfw sw9O1VySs9Juwq4bVMnN4e+CPi5vsHRQKiTRnSzWE+/8al1zHqM8fpXMoGiexkrdObcV /lWqnixvmd0AShPGnfrOiqpo6Bg/l1+RvFfNgJlOTQHoox5/LU3UnvDQA+sYRmaMmntl WK6+peWpc9RO8Hqmk7OPXyyth5Z2w6RcYCtEUvnvx3vg6SkOhG8QWL+8VJUeWjS+LCwh sQBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=/s3QiuGOq/bnkqDr88Yb/4C3yy0KGxdWIkFkoMyhaDk=; b=PSlsy6J9d05/5L1iDFmnOY5IJYh2AAo+vB+xnL1nWAyO2V/6Z1XfxV9PvFZwCb7bhj gYO5sYi7b/RRSV1lbje3n0ZyGTBlRGJOVisXf6HmowSmWmxevnsgdEPkw+oU2u76617G eHW/hevK4nYescw1T0QpaTqsrmfKxhL4ySHCQxOYvitGIvKaWg25Ide1cjKbZ33dwSmq ghrBM6TjA6RAQUNZzQm2xEgXB9DnHxgbZYglpmiMoPQ2/J+4NsVz5ZWWCoTkuda6Vy0I 1P+pumla0EucYj4ukafT9SGfxn89iF43YrqiqoM2G5rGnfSywCThxeIFd2enT+U92JEz cUtQ== X-Gm-Message-State: AODbwcDik0dq7O03iUK/wUU1h2uI8D1sHEC1jQh/4SUCj0tTpKG9X2Pi gU2vG692N5RwFhjymTelJraiQdLkUg== X-Received: by 10.237.61.28 with SMTP id g28mr817398qtf.279.1494454930862; Wed, 10 May 2017 15:22:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Wed, 10 May 2017 15:22:10 -0700 (PDT) In-Reply-To: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com> References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Wed, 10 May 2017 15:22:10 -0700 Message-ID: Subject: Fwd: New Version Notification for draft-herbert-6man-icmp-limits-01.txt To: 6man@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 22:22:13 -0000 Hello, I added a section on host's response to the ICMP errors in this version. Also, I checked how Linux would deal with these errors. Currently, any Parameter Problem ICMP errors are assumed to be hard errors. There are reported to the application and in the case of TCP the connection is terminated. We can modify this behavior to take more appropriate action for the codes described in the draft. Thanks, Tom ---------- Forwarded message ---------- From: Date: Wed, May 10, 2017 at 3:17 PM Subject: New Version Notification for draft-herbert-6man-icmp-limits-01.txt To: Tom Herbert A new version of I-D, draft-herbert-6man-icmp-limits-01.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-6man-icmp-limits Revision: 01 Title: ICMPv6 errors for discarding packets due to processing limits Document date: 2017-05-10 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-herbert-6man-icmp-limits-01.txt Status: https://datatracker.ietf.org/doc/draft-herbert-6man-icmp-limits/ Htmlized: https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-6man-icmp-limits-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-herbert-6man-icmp-limits-01 Abstract: Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits. When such packets are dropped, the sender receives no indication so it cannot take action to address the cause of discarded packets. This document defines ICMP errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A sender that receives such an ICMP error may be able to modify what it sends in future packets to avoid subsequent packet discards. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed May 10 16:43:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6703128DE7; Wed, 10 May 2017 16:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=MZVgqjNQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NKQYc46H 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 kFX9zgZ15PmW; Wed, 10 May 2017 16:43:35 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B151287A7; Wed, 10 May 2017 16:43:34 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2033E20A69; Wed, 10 May 2017 19:43:34 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 10 May 2017 19:43:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=vwtz/PxWfo+Dzy4l2P lLtNSBYWEsONSo+1tatYZL9nY=; b=MZVgqjNQppF2cKrOjF7oU0YeXIzjZyICfB pAOSUy6WzeXdcgwZtpMKklCy1cM9Do8eaC40xEW2RFANxh48wLvVjj7Z67opGNjG 8pIN3aW4TtwUiMhoF22vWILJzR2OOIOwkfu2rsNHyfLNxEjgzJiGWxcT0BBfqXsn p8CgjIA9pxSRee8bKxCIJQlmJlRSLd9MHpidHYE5S6/qRV+kx89SPqBsyd/ZC4M6 Bad9sNklen9O04Ut7ajMAi0TI5bl2cp0/6lZ/vp8K/TJU6QV+/XDBypUHqDtJreO OL4jH4HZvaEBpeiAePMEPmmoFl08t7wKadEMlJSaF7cMJ+y8z+2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=vwtz/PxWfo+Dzy4l2PlLtNSBYWEsONSo+1tatYZL9nY=; b=NKQYc46H C98/d4mabv3rj0UT/TbEJEBun3j0EsJBlDTTxdHZ+f3/58IqGhkTtQVbMddhbnKU tKuDLNagfv1hhPEK1rYTKoAI7iaeBoqIhj0o97FoX8DYiDtCvh+6Uh6qRl7bbUJ6 YF08pT5VdsjPCcuWZ+fq1yCznA9IR1hWeew59XLAcEKF3X98xi2Zq83JkWQyZDJ8 01NHCeqqRnEwZQ/IY1F5Op44DK3/zeVlGosMkiiiaWSvi91jt5XqOMGfbnCubxUk 1EbTv+4/NeZmAr6OxNXChajxANgMwSN/o/NKkPz4Hl+OBJYxwbSkv4iuDF6ClBIn 4XVQHiZ2/6UXdw== X-ME-Sender: X-Sasl-enc: 4hsy43jgEiyEuvImk6Wa7GQAlLdPIEnvQ4LnEPnf6qjk 1494459813 Received: from [172.27.5.25] (unknown [75.104.68.118]) by mail.messagingengine.com (Postfix) with ESMTPA id DCE18240A5; Wed, 10 May 2017 19:43:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [Gen-art] Genart telechat review of draft-ietf-6man-rfc1981bis-06 From: Alissa Cooper In-Reply-To: <149305392811.25808.15115824976388262628@ietfa.amsl.com> Date: Wed, 10 May 2017 16:43:21 -0700 Cc: General Area Review Team , IPv6 List , draft-ietf-6man-rfc1981bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149305392811.25808.15115824976388262628@ietfa.amsl.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 23:43:37 -0000 Stewart, thank you for your review, and thanks all for your engagement = with Stewart. Alvaro has proposed a resolution to the 2119 issue which = seems satisfactory. I have ballotted no-objection. Alissa > On Apr 24, 2017, at 10:12 AM, Stewart Bryant = wrote: >=20 > Reviewer: Stewart Bryant > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-6man-rfc1981bis-?? > Reviewer: Stewart Bryant > Review Date: 2017-04-24 > IETF LC End Date: 2017-03-01 > IESG Telechat date: 2017-05-11 >=20 > Summary: This is can be published as is, but I think could be > improved. >=20 > I thank the authors you for dealing with most of my comments in the > previous round. > There are two unaddressed points that the IETF Chair may wish to > consider, and one > that I missed. >=20 > Major issues: > The text has a lot of RFC2119 language, but no RFC2119 declaration. > and the document seems inconsistent about when it uses RFC2119 > language and > when it does not. This sends a mixed messages to authors if we are not >=20 > consistent on this point throughout the RFC Series. >=20 > =3D=3D=3D=3D=3D=3D=3D >=20 > 5.3. Purging stale PMTU information >=20 > Internetwork topology is dynamic; routes change over time. While > the > local representation of a path may remain constant, the actual > path(s) in use may change. Thus, PMTU information cached by a > node > can become stale. >=20 > If the stale PMTU value is too large, this will be discovered > almost > immediately once a large enough packet is sent on the path. No > such > mechanism exists for realizing that a stale PMTU value is too > small, > so an implementation should "age" cached values. When a PMTU > value > has not been decreased for a while (on the order of 10 minutes), > the > PMTU estimate should be set to the MTU of the first-hop link, and > the > packetization layers should be notified of the change. This will > cause the complete Path MTU Discovery process to take place again. >=20 > SB> I still worry that the impact of this advice is going to be a > disruption to what might > SB> be a critical service every 10 mins, and wonder if there should be > some advice along the=20 > SB> lines of noting the importance of service delivery as part of > deciding whether to > SB> test for bigger PMTU vs improving efficiency? >=20 > Minor issues: >=20 > A node MUST NOT reduce its estimate of the Path MTU below the IPv6 > minimum link MTU. >=20 > SB> I missed this last time. > SB> > SB> Presumably you mean "A node MUST NOT reduce its estimate of the=20 > SB> Path MTU below the IPv6 minimum link MTU in response to such > SB> a message." > SB>=20 > SB> Otherwise I would have thought that this was entirely a matter=20 > SB> for the host whether it wanted to use a Path MTU below the IPv6=20 > SB> link minimum. Nothing breaks if the host takes a more conservative >=20 > SB> decision. > SB>=20 >=20 > Nits/editorial comments: None. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed May 10 21:20:47 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7701294C4; Wed, 10 May 2017 21:20:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-6man-rfc1981bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: Adam Roach's No Objection on draft-ietf-6man-rfc1981bis-06: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149447644575.16637.13354562009055459574.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 21:20:45 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 04:20:46 -0000 Adam Roach has entered the following ballot position for draft-ietf-6man-rfc1981bis-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'd like to add my voice to the concerns expressed regarding RFC2119 language. I understand the desire to only deal with the changed parts of the specification; but the current process as I understand it is that bis versions of document are expected to be "brought up to code" according to modern IETF document practices. Perhaps we should have a conversation about whether that practice is in need of revising, but I'm not sure making piecemeal exceptions is the best way to go about starting that conversation. In any case, I believe that current practice is that new RFCs cite 2119 and adhere to its definitions when using these specific terms in all-caps; and that this will be published as a new RFC. Minor technical comment: Like others, I also had a really hard time with the paragraph in section 4 concluding with "MUST force the Path MTU Discovery process to end." It's difficult to read this as anything *other* than "you get one Path Too Big, and just shut down discovery," but that's clearly not what the rest of the document says. (I'll also note that if we are treating capital "MUST" as normative, then "MUST attempt to" is kind of meaningless). Minor technical comment: Section 5.4 has three paragraphs, starting "Alternatively, the retransmission could be done in immediate response to a notification" that propose a more aggressive means of dealing with packets lost to PMTU issues; most of this text is a warning about how this can go awry and (if you'll excuse a bit of hyperbole) melt the Internet. Given that the first alternative works just fine and appears to be much safer, is this alternative actually something we want to recommend for today's implementations? The remainder of my comments are editorial. The second-to-last paragraph of the introduction uses the phrase "such messages" in a way that makes the antecedant difficult to find. I spent a while trying to figure out how PMTUD used TCP three-way-handshakes or blackholed TCP packets to determine PMTU. Suggest: "..relies on ICMPv6 messages to determine..." The abbreviation "PTB" appears in the second paragraph of section 4. I would ordinarily suggest expanding on first use; but as this is this first and only use, I suggest simply replacing it with the long form used in the rest of the document. Section 5.1 introduces the term MMS_S, and relates it to EMTU_S. I note that the former is not in the terminology section, while the latter is -- I suspect that they should both be present. Section 5.2 uses the acronym "ECMP". I would suggest citing the related document in which ECMP is defined and optionally expanding the acronym. Section 5.2 indicates: Also, the instance that sent the packet that elicited the Packet Too Big message should be notified that its packet has been dropped, even if the PMTU estimate has not changed, so that it may retransmit the dropped data. It is quite nonintuitive how this situation could arise: if the packet is of size X, and the PMTU has not changed, then it follows that X <= PMTU (as the packet would have been reduced in size otherwise). If the PMTU has not changed, it also follows that PMTU <= MTU (from the Packet Too Big message). it follows that X <= MTU (from the Packet Too Big message), and so it really should not have been dropped unless the corresponding router has an implementation flaw of some kind. More importantly, it would seem that an attempt to transmit another packet of size X at this point would run an overwhelmingly high chance of triggering another Packet Too Big for whatever errant reason caused the first one to be sent. I'm sure this naïve explanation overlooks whatever nonintuitive situation is envisioned by this paragraph. It would be quite helpful if such a situation were described: I, as an implementor, would look at this and say "What? No. I'm not doing that. It's extra work for no benefit." I suspect it will be dealt with by the RFC editor, but the first normative reference seems to have some kind of issue with the production of the authors' names. I see several acknowledgements in section B.1 that will be removed prior to publication. The authors may wish to consider moving these names to section 7 for the sake of posterity. From nobody Thu May 11 03:45:40 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0115612EB9B; Thu, 11 May 2017 03:45:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-6man-rfc1981bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: Benoit Claise's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149449953899.16665.14587982174992349533.idtracker@ietfa.amsl.com> Date: Thu, 11 May 2017 03:45:38 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 10:45:39 -0000 Benoit Claise has entered the following ballot position for draft-ietf-6man-rfc1981bis-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Nodes not implementing Path MTU Discovery MUST use the IPv6 minimum link MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet size. I searched for "IPv6 minimum link MTU" in draft-ietf-6man-rfc2460bis-09, and could not find that term. Even unlikely at this point in the IPv6 implementation cycle, we don't want readers to believe that they should look at the minimum of the device IPv6 MTU link(s). Proposal: define "IPv6 minimum link MTU" as 1280 octets in 2460bis, or in both documents. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In this document, I see: IPv6 nodes SHOULD implement Path MTU Discovery in order to discover and take advantage of paths with PMTU greater than the IPv6 minimum link MTU [I-D.ietf-6man-rfc2460bis]. A minimal IPv6 implementation (e.g., in a boot ROM) may choose to omit implementation of Path MTU Discovery. In draft-ietf-6man-rfc2460bis-09: It is strongly recommended that IPv6 nodes implement Path MTU Discovery [RFC1981], in order to discover and take advantage of path MTUs greater than 1280 octets. However, a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of Path MTU Discovery. So a SHOULD in one document versus "strongly recommended" in the other. We should reconcile the two texts. Note: may and may are consistent. ICMPv6 PTB => ICMPv6 Packet to Big (PTB) From nobody Thu May 11 20:34:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B5712EAE0; Thu, 11 May 2017 20:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 NpojgsVIE5hB; Thu, 11 May 2017 20:34:48 -0700 (PDT) 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 E5DC4128959; Thu, 11 May 2017 20:27:47 -0700 (PDT) Received: from [192.168.3.83] (unknown [181.165.123.103]) (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 A583980634; Fri, 12 May 2017 05:28:00 +0200 (CEST) Subject: Re: Benoit Claise's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS and COMMENT) To: Benoit Claise , The IESG References: <149449953899.16665.14587982174992349533.idtracker@ietfa.amsl.com> Cc: 6man-chairs@ietf.org, ipv6@ietf.org, draft-ietf-6man-rfc1981bis@ietf.org From: Fernando Gont Message-ID: <2b7d9b30-89a9-e93f-d884-1a22d7f6f181@si6networks.com> Date: Fri, 12 May 2017 05:26:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149449953899.16665.14587982174992349533.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 03:34:51 -0000 On 05/11/2017 12:45 PM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-6man-rfc1981bis-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Nodes not implementing Path MTU Discovery MUST use the IPv6 minimum > link MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet > size. > > I searched for "IPv6 minimum link MTU" in draft-ietf-6man-rfc2460bis-09, > and could not find that term. > Even unlikely at this point in the IPv6 implementation cycle, we don't > want readers to believe that they should look at the minimum of the > device IPv6 MTU link(s). > Proposal: define "IPv6 minimum link MTU" as 1280 octets in 2460bis, or in > both documents. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In this document, I see: > > IPv6 nodes SHOULD implement Path MTU Discovery in order to discover > and take advantage of paths with PMTU greater than the IPv6 minimum > link MTU [I-D.ietf-6man-rfc2460bis]. A minimal IPv6 implementation > (e.g., in a boot ROM) may choose to omit implementation of Path MTU > Discovery. > > In draft-ietf-6man-rfc2460bis-09: > It is strongly recommended that IPv6 nodes implement Path MTU > Discovery [RFC1981], in order to discover and take advantage of path > MTUs greater than 1280 octets. However, a minimal IPv6 > implementation (e.g., in a boot ROM) may simply restrict itself to > sending packets no larger than 1280 octets, and omit implementation > of Path MTU Discovery. > > So a SHOULD in one document versus "strongly recommended" in the other. Well.. isn't SHOULD == RECOMMENDED in RFC2119-speak? Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri May 12 02:37:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42507124BE8; Fri, 12 May 2017 02:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoDXNZV8Hn1B; Fri, 12 May 2017 02:37:36 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35292128BA2; Fri, 12 May 2017 02:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2622; q=dns/txt; s=iport; t=1494581228; x=1495790828; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=G3CJ4025h/SGFq9hT6IxA/8zSo0g8g5oB3fnh7jv3XM=; b=ZaRZXdC8gFhib7PUVnDpVwW0Nv5VjbVrP2hfe7ftA56vfxneXq94ANvv gYH6umxr/X8066EaxmrbB1oKw4YW7MfUYkaoWI9tzXQ0VA3b/jQ2X9fEM DHlScxfL4eVGWDDWcchkXnekz1qyo0J67mJbvFjrxDZm9b7bitiK6v/Iy s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAADjfhVZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDeBDI4Dc5BHIZV0gg8shXgChVQYAQIBAQEBAQEBayiFFgEFOEE?= =?us-ascii?q?QCw4KLlcGAQwIAQGKHw6xJYpzAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGX4FeK?= =?us-ascii?q?wuCZYQ0EgGGDgEEiUSURoccgzWISoIEhTuDQ4ZpjBSILx84fwsvIAgZFYVxgUw?= =?us-ascii?q?+NgGGPIIuAQEB?= X-IronPort-AV: E=Sophos;i="5.38,329,1491264000"; d="scan'208";a="651806000" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 May 2017 09:27:05 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v4C9R5QM028042; Fri, 12 May 2017 09:27:05 GMT Subject: Re: Benoit Claise's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS and COMMENT) To: Fernando Gont , The IESG Cc: 6man-chairs@ietf.org, ipv6@ietf.org, draft-ietf-6man-rfc1981bis@ietf.org References: <149449953899.16665.14587982174992349533.idtracker@ietfa.amsl.com> <2b7d9b30-89a9-e93f-d884-1a22d7f6f181@si6networks.com> From: Benoit Claise Message-ID: <233a54f9-8854-2674-d9ca-06d3a6aedce3@cisco.com> Date: Fri, 12 May 2017 11:27:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <2b7d9b30-89a9-e93f-d884-1a22d7f6f181@si6networks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 09:37:40 -0000 On 5/12/2017 5:26 AM, Fernando Gont wrote: > On 05/11/2017 12:45 PM, Benoit Claise wrote: >> Benoit Claise has entered the following ballot position for >> draft-ietf-6man-rfc1981bis-06: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Nodes not implementing Path MTU Discovery MUST use the IPv6 minimum >> link MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet >> size. >> >> I searched for "IPv6 minimum link MTU" in draft-ietf-6man-rfc2460bis-09, >> and could not find that term. >> Even unlikely at this point in the IPv6 implementation cycle, we don't >> want readers to believe that they should look at the minimum of the >> device IPv6 MTU link(s). >> Proposal: define "IPv6 minimum link MTU" as 1280 octets in 2460bis, or in >> both documents. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> In this document, I see: >> >> IPv6 nodes SHOULD implement Path MTU Discovery in order to discover >> and take advantage of paths with PMTU greater than the IPv6 minimum >> link MTU [I-D.ietf-6man-rfc2460bis]. A minimal IPv6 implementation >> (e.g., in a boot ROM) may choose to omit implementation of Path MTU >> Discovery. >> >> In draft-ietf-6man-rfc2460bis-09: >> It is strongly recommended that IPv6 nodes implement Path MTU >> Discovery [RFC1981], in order to discover and take advantage of path >> MTUs greater than 1280 octets. However, a minimal IPv6 >> implementation (e.g., in a boot ROM) may simply restrict itself to >> sending packets no larger than 1280 octets, and omit implementation >> of Path MTU Discovery. >> >> So a SHOULD in one document versus "strongly recommended" in the other. > Well.. isn't SHOULD == RECOMMENDED in RFC2119-speak? Yes, but SHOULD <> "strongly recommended" Just be consistent. Regards, Benoit > > Cheers, From nobody Fri May 12 14:21:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFFC12EBC6; Fri, 12 May 2017 14:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 AGF6eE9yiqiD; Fri, 12 May 2017 14:20:58 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B4F12EBC7; Fri, 12 May 2017 14:16:15 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id y201so58170650qka.0; Fri, 12 May 2017 14:16:15 -0700 (PDT) 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=4lIRLyfko8yeIuZXdBajl9KP+uZUX6eQC9zLsj66XnE=; b=dbfRU2QHq4ypwsfBh+hTvUgGslajIkcgNMJ3gtoRuLMEWrip8V+rF7MIJKLMrUQAV2 yNRBc84nexkt0gVe7+i/PkKpa0Y1gK9TN5dSydskipu5DCNv8oHruTZrTaU/S3DBW1q8 W2JEPldaLIEPbf+xfcsU+18Gk6UhGSsecliOdmTDofvMkZ/nxrEaa2aSfLCPAVquSSTA NWs/mCy/bsPN8SmNNWb4CLk1UIzZ19nrOhRqcAnRJSCw1WyY7MU2E6xY9QVdtqytCqVe aXtaiZRLUfKuYWN2oTzLKex1iGgxBP86aJI/7IUOw16AMlRYvfxd2QkAbqVssa7qHc8M 2Idg== 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=4lIRLyfko8yeIuZXdBajl9KP+uZUX6eQC9zLsj66XnE=; b=C9EPW27pF7x6sl03fLBJcR/GSPxA0hm/l2/iJk/ah4o6IXnKIuhXanbApv6hZjHemK 3WdEMrQ3yGdl4UrfKEymOs8MqWAw9b7P4cb4OLdpxZr4CawQx4w7UPHDKST6nis+jZpy 0Twfao2oqNDXB0XcDkGhUhG3SgouG+eQB/Qqzne7ciXiPkDtGzXoQJz6T/LypkP+nBbh nNUX/xxurqpVHI5RMk1QTm2A55ZizQg+1ejgeAzVQbRVWEjRPI4jf0YdbuvYUhB9HQyq 53VobRLdUPngjRUmzusZpQ15+H4+ja1t1jW/sYGwM4F64CFkUuCu6PjwArEh9/J8qPaT ASPw== X-Gm-Message-State: AODbwcCNgHevBd7CLPdKSHwEmzdq0V3DusCv6mEckK9KOF00oQI9k11g DSrSFA6bJdoIVA== X-Received: by 10.55.15.143 with SMTP id 15mr5384052qkp.44.1494623774288; Fri, 12 May 2017 14:16:14 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id 24sm3133630qtx.8.2017.05.12.14.16.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 14:16:13 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0CC50F94-4B6A-4129-95F5-7218B8506ABD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Benoit Claise's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS and COMMENT) Date: Fri, 12 May 2017 14:16:11 -0700 In-Reply-To: <149449953899.16665.14587982174992349533.idtracker@ietfa.amsl.com> Cc: Bob Hinden , IESG , draft-ietf-6man-rfc1981bis@ietf.org, =?utf-8?Q?Ole_Tr=C3=B8an?= , 6man Chairs <6man-chairs@ietf.org>, IPv6 List To: Benoit Claise References: <149449953899.16665.14587982174992349533.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 21:21:01 -0000 --Apple-Mail=_0CC50F94-4B6A-4129-95F5-7218B8506ABD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Benoit, Comments below on your Discuss. Bob > On May 11, 2017, at 3:45 AM, Benoit Claise wrote: >=20 > Benoit Claise has entered the following ballot position for > draft-ietf-6man-rfc1981bis-06: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Nodes not implementing Path MTU Discovery MUST use the IPv6 minimum > link MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet > size. >=20 > I searched for "IPv6 minimum link MTU" in = draft-ietf-6man-rfc2460bis-09, > and could not find that term. The text in rfc2460bis (unchanged from rfc2460) is: 5. Packet Size Issues IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. Links that have a configurable MTU (for example, PPP links [RFC1661]) must be configured to have an MTU of at least 1280 octets; it is recommended that they be configured with an MTU of 1500 octets or greater, to accommodate possible encapsulations (i.e., tunneling) without incurring IPv6-layer fragmentation. rfc1981bis (and rfc1981) doesn=E2=80=99t use "IPv6 minimum link MTU=E2=80=9D= as a defined term (otherwise it would be in Section 2. = =E2=80=9CTerminology=E2=80=9D. It=E2=80=99s just words describing the = concept in Section 5 of rfc2460bis (as shown above). > Even unlikely at this point in the IPv6 implementation cycle, we don't > want readers to believe that they should look at the minimum of the > device IPv6 MTU link(s). > Proposal: define "IPv6 minimum link MTU" as 1280 octets in 2460bis, or = in > both documents. I think rfc1981bis (and rfc1981) are correct about pointing to = rfc2460bis (and rfc2460). Having to change it in two places would make = it much harder to change it in the future. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > In this document, I see: >=20 > IPv6 nodes SHOULD implement Path MTU Discovery in order to discover > and take advantage of paths with PMTU greater than the IPv6 minimum > link MTU [I-D.ietf-6man-rfc2460bis]. A minimal IPv6 implementation > (e.g., in a boot ROM) may choose to omit implementation of Path MTU > Discovery. >=20 > In draft-ietf-6man-rfc2460bis-09: > It is strongly recommended that IPv6 nodes implement Path MTU > Discovery [RFC1981], in order to discover and take advantage of path > MTUs greater than 1280 octets. However, a minimal IPv6 > implementation (e.g., in a boot ROM) may simply restrict itself to > sending packets no larger than 1280 octets, and omit implementation > of Path MTU Discovery. >=20 > So a SHOULD in one document versus "strongly recommended" in the = other. >=20 > We should reconcile the two texts. > Note: may and may are consistent. >=20 >=20 > ICMPv6 PTB =3D> ICMPv6 Packet to Big (PTB) >=20 >=20 --Apple-Mail=_0CC50F94-4B6A-4129-95F5-7218B8506ABD 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 iQEcBAEBCgAGBQJZFiYbAAoJEK7rdBF357uoMGYH/j7+IiTNPvYTcbdyEpWRgr++ PLRtWUVZGmAyVe0z8GvAe9EYqvcGWDXYMHu6FcDf8aZZa9LzapEs8+xFwMJ78vwM HScYry2EOT7K34DnTYqfwacZ6WTNhXo/TEqfUp4U4YuNLP3jzAhjPNaGUgUS43cr kj/dH0VpZF1OaHcC7Yn/9YE+IQMQ5uPuNvrKv8VStNaqvp+ZkwafrCYwSHqevgRe Krrx8vogtGIrNLvUV3n4IBIdD1/xyIsvhwzsVwkeZRUpUqA8EQRWuo+PS1P+afiq jta6WlHa5szK3LtembOZ369fAUqVXnCEfGSYa+E+n7RJ/gwKrO5gmedh5DVvAkk= =kRzl -----END PGP SIGNATURE----- --Apple-Mail=_0CC50F94-4B6A-4129-95F5-7218B8506ABD-- From nobody Sat May 13 12:43:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67430129AFC; Sat, 13 May 2017 12:43:26 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ecLt8nbGyEXs; Sat, 13 May 2017 12:43:24 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 1720412EA8C; Sat, 13 May 2017 12:40:14 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id u65so19668179wmu.3; Sat, 13 May 2017 12:40:14 -0700 (PDT) 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=Xsukos6GYfPj29uexEgqLSVqkJzzuxAuzh/VU/+X7jQ=; b=t83k+ElXizBTCnEpMX1/pgqtbgpoNucIy93FJrtJuANWCraBWkEZBWbu4Qy9NybGPX 8uI5Xk5o4RnA0mGop/W5u8o27oSJGpo8nvZ1drxkeHcg8ZPNpSFyIRlHAN9+QwQmLCZq 6jZngCpYw9fV6nfl14u3aq0upszedDGMrVP7Nujsa3+Ne2wz42379xkYVggD/Ok79UN9 0q0KiolpLM/ICIbUW69bPnSvBpIxWlDl4B3nkICgq7pfbH6RnSmDljvGLaCqggF0EeMp SJ6PeWLfv/xUDsNjOjhR7DN8SNQbbQM7SjCbzaUXKvz2aHbcrJeONgoXM0DQMblss16C 8wlQ== 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=Xsukos6GYfPj29uexEgqLSVqkJzzuxAuzh/VU/+X7jQ=; b=RjZwhit/zAOUlp7AUlNqLimCqEam0RHxe1x5v+qj5ztFBuONORZKOCKJUn9GEh3C/V VOeRXMIDh9FQ5f7O6UK1DcBjdtRBALxFZLeUvd0lYs0onLokzQ+24vz+NF2CbXeZh+SX GaqmjTaNOhuQ6qL9YHCq5n7/HCo6Af1XdoGq+sLHBtUr5P9Flytec/XLJiYKqkUBo3Vr j7T40si0MtbEM4DW4UuYSUXgTJ+fm76d18JXl7HHTMj2hrZ+k2ujWL8dQOzRmTUtE3Im UAGVItEPDrKtIFfN33ySvR9xRUHnX/D6BBtMpnCCr3BhxefAAUG2fXwPLkYKyJy/EVWQ H0Lg== X-Gm-Message-State: AODbwcB4kS3e05Kt7Gwytjjy5Z0P2MTCGwb+VpPh4zLKoH4pekI2I69Z MYdw2UuRDFBlQA== X-Received: by 10.28.45.18 with SMTP id t18mr1732053wmt.6.1494704412445; Sat, 13 May 2017 12:40:12 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:1d51:b039:45a8:3797? ([2601:647:4d01:db10:1d51:b039:45a8:3797]) by smtp.gmail.com with ESMTPSA id o20sm5487688wro.61.2017.05.13.12.40.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 May 2017 12:40:11 -0700 (PDT) From: Bob Hinden Message-Id: <2D89FFFE-1EC7-41FF-A6F0-FEDFFEAFBBE9@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7E6C9D8C-ADFD-4BCE-9C6B-24646FF26272"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Warren Kumari's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS and COMMENT) Date: Sat, 13 May 2017 12:40:03 -0700 In-Reply-To: <149443158586.30086.10156582311718173877.idtracker@ietfa.amsl.com> Cc: Bob Hinden , IESG , draft-ietf-6man-rfc1981bis@ietf.org, =?utf-8?Q?Ole_Tr=C3=B8an?= , 6man-chairs@ietf.org, IPv6 List To: Warren Kumari References: <149443158586.30086.10156582311718173877.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 19:43:26 -0000 --Apple-Mail=_7E6C9D8C-ADFD-4BCE-9C6B-24646FF26272 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Warren, > On May 10, 2017, at 8:53 AM, Warren Kumari wrote: >=20 > Warren Kumari has entered the following ballot position for > draft-ietf-6man-rfc1981bis-06: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > The OpsDir review > = (https://datatracker.ietf.org/doc/review-ietf-6man-rfc1981bis-04-opsdir-lc= -hares-2017-03-04/ > ) raises an interesting point, which I had not occurred to me. If the = MTU > for a path is 1440 bytes, and ND/RA suddenly says that the interface = MTU > is only 1400 bytes, what should implementations do? > I'd expect something like decrease the path MTU (for all paths) to min > (new link MTU, current path MTU), but it isn't (AFAICT) specified. >=20 > It's entirely possible that this is a: already covered and / or b: > covered at a different layer / different protocol, happy to be hit = with a > clue bat=E2=80=A6 I am not sure this is a PMTU question as this is about the first hop = link MTU size not somewhere along the path. Neighbor Discovery RFC4861 = (Section 6.3.4) says to use the new value. Based on this, the node = would change it=E2=80=99s MTU to the new value and start sending smaller = packets, or fragments. The transport layer would pick up the new MTU = and act accordingly. ND also has rules to bound a received MTU. =46rom Section 6.3.4 of ND: If the MTU option is present, hosts SHOULD copy the option's value into LinkMTU so long as the value is greater than or equal to the minimum link MTU [IPv6] and does not exceed the maximum LinkMTU value specified in the link-type-specific document (e.g., [IPv6-ETHER]). Hope this answers your question. Thanks, Bob > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Please also see the OpsDir review.... >=20 >=20 > I sent email about this to the authors on Feb 23rd - I seem to still = have > have many of the same questions... >=20 > Comments: > 1: Sec 1: "Path MTU Discovery relies on such messages to determine the > MTU of the path." > -- it is unclear which "such" refers to. Perhaps s/such/ICMPv6/ (or > PTB). >=20 > 2: Sec 3: "Upon receipt of such a message, the > source node reduces its assumed PMTU for the path based on the MTU > of > the constricting hop as reported in the Packet Too Big message" -- > this says that it reduces it *for the path*. But (as somewhat alluded = to > later in the draft) the nodes doesn't know what the path *is* -- it = can > decrease for the destination, or flow, or even interface, but (unless = it > is strict source routing) it doesn't control or really know the path = (see > also #4) >=20 > 3: Sec 4: "The recommended setting for this timer is twice its minimum > value (10 minutes)." - as above. This was from 1996 - were these = metrics > discussed at all during the -bis? I suspect that the average flow is = much > shorter these days (more web traffic, fatter pipes, etc) and so a flow = of > 10 minutes seems really long (to me at least). >=20 > 4: Sec 5.2: "The packetization layers must be notified about decreases = in > the > PMTU. Any packetization layer instance (for example, a TCP > connection) that is actively using the path must be notified if the > PMTU estimate is decreased. > Note: even if the Packet Too Big message contains an Original > Packet Header that refers to a UDP packet, the TCP layer must be > notified if any of its connections use the given path." > - this is related to #2 -- I don't know *which* path my packets take - > once I launch them into the void, they may be routed purely based upon > destination IP address, or they may be hashed based upon some set of > header fields to a particular ECMP link or LSP. Once packets hit a = load > balancer, it is probably even *likely* that the UDP and TCP packets = end > up on different things. So, if I get a PTB from a router somewhere, I = can > probably guess that other packets to the same destination address will > also follow that path, but I cannot know that for sure. I'm fine to > decrease MTU towards that destination IP, but is that what this is > suggesting? If so, please say that. If not, please let me know what I > should do. The above is even more tricky / fun when I'm using flow id = as > the flow identifier -- if I get a PTB for flow 0x1234, what do I do? >=20 > 5: Sec 5.3: "Once a minute, a timer-driven procedure runs through all > cached PMTU values, and for each PMTU whose timestamp is not = "reserved" > and is older than the timeout interval ...". Please consider providing > clarifications here. The wording implies that I should set a timer to > fire on the minute, and trigger the behavior. If all of the (NTP = synced!) > machines in my datacenter do this, and all try send bigger packets (on > 1/10th of long flows) their first hop router will get many, many > over-sized packets and it will severely rate-limit the PTBs. >=20 >=20 > Nits (Some of these are purely academic.) > I understand that you are trying to limit the changes, so feel free to > ignore these: >=20 > 1: "A node sending packets much smaller than the Path > MTU allows is wasting network resources and probably getting > suboptimal throughput." - the "much" confuses me. If I'm using = anything > less than the MTU I'm wasting network resources and getting suboptimal > throughput - I might not care, but if (used MTU) < (path MTU) I'm = wasting > resources. >=20 > 2: "Nodes implementing Path MTU Discovery and sending packets larger > than > the IPv6 minimum link MTU are susceptible to problematic connectivity > if ICMPv6 [ICMPv6] messages are blocked or not transmitted." The > "implementing Path MTU Discovery and" seems redundant. ALL nodes = sending > packets larger than minimum MTU are "susceptible to problematic > connectivity if ICMPv6 [ICMPv6] messages are blocked or not > transmitted.". I get what you are trying to say, but my OCD tendencies > would not allow me to ignore this... >=20 > 3: "In the case of multipath routing (e.g., Equal Cost Multipath = Routing, > ECMP),"- this is vague / confusing -- (Equal Cost Multipath Routing, > ECMP) makes it sound like either ECMP is an acronym for Equal Cost > Multipath Routing, or that ECMP is something different to Equal Cost > Multipath Routing. > I'd suggest just dropping the "ECMP" (or, "Equal Cost Multipath (ECMP) > routing", but that seems clumsy) >=20 >=20 --Apple-Mail=_7E6C9D8C-ADFD-4BCE-9C6B-24646FF26272 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 iQEcBAEBCgAGBQJZF2EUAAoJEK7rdBF357uobVcIAMAmt18Fw+sMVuqYrYoAl0TD x7YMcyx9drDQzQyWc0UKAGABV2TUmcVQdS+0W8M4qJjc9cnx9tNr7upvXyoQigwk xrpkK1ERHSDllLJw/XqQqpn/8xkAY1+OW3PYRg3auIfE3dXpyZCGWjBEOr0MB1hu nzQy7jGOknJkuuDBFwRckxWUAz9uDCgmd1U06y2nLCQ4SvmOg6LkafF05DbuW36u eNBnsM9ddjDzfYP9gRnLmK2za/HTd/0I5Wz9YUTUu9vBGFHC3UmFcO5T3wC95uMY 4A46pQdnpybDPoX6CB4+RrlWqm9v1xyGMM9O8N0r2rtz49dRxEKF03OQodPV798= =am2M -----END PGP SIGNATURE----- --Apple-Mail=_7E6C9D8C-ADFD-4BCE-9C6B-24646FF26272-- From nobody Mon May 15 07:41:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759F0129B5B for ; Mon, 15 May 2017 07:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.802 X-Spam-Level: X-Spam-Status: No, score=-4.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-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=juniper.net 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 xTkKNWoZ7lRu for ; Mon, 15 May 2017 07:41:22 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0125.outbound.protection.outlook.com [104.47.42.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E70129468 for <6man@ietf.org>; Mon, 15 May 2017 07:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xEUYVQXREij78EYJb9KjnWbzzYA9j2AR2HHguZvOjXU=; b=S/DscjYRLy/eQsNcgFLKKgy31miqnKx/37moWHXPvVTlhHQ88DIoPlWyOXkkPHJp8CVtH0iXfq1VBijxCLQMhNEoNW0+MikqZninDRtTTwvzpHCUxUrak7YLsbkM7ew/5bd2SUGdA/eeU4OB+wWgr1ejmeiCT/+RiWTwbULC1bY= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2049.namprd05.prod.outlook.com (10.164.23.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.8; Mon, 15 May 2017 14:37:03 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1101.011; Mon, 15 May 2017 14:37:03 +0000 From: Ron Bonica To: Tom Herbert , "6man@ietf.org" <6man@ietf.org> Subject: RE: New Version Notification for draft-herbert-6man-icmp-limits-01.txt Thread-Topic: New Version Notification for draft-herbert-6man-icmp-limits-01.txt Thread-Index: AQHSydvj2CNgsdR2N0SNyPfQvMZ6VaH1duKg Date: Mon, 15 May 2017 14:37:03 +0000 Message-ID: References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: herbertland.com; dkim=none (message not signed) header.d=none;herbertland.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2049; 7:eSPUNWL4pY7KfnypZlOFHUb/+hua9ZFx6A42yFhrelH6RWzcQHZq3KMuQufK3AFZc6u4rFhgYfbPjt2NfglghpTPyC8Eh1Ke5vkDCCueUlL1bW7KGJZjZ45n0NraegAAU68KDJhdzkNzgaN73JXwLXyDjMinxYl1gR7Pbt5s//xrJDXpPmqA+/bjIzTFCkCxndUNLnXCJFc44/rBZT563pB9ksVg9TvbU9D+I59wm9epmNBIx/X9ioroot/xTbHgyyTf8X3dhXUIzvskA5ROaZbMk+LvsuMZ7HkMwEOdpAht4NcOv3hWeVYCSpSUGRi+En8SelNLqhvYnWlsZXEWYw== x-ms-traffictypediagnostic: BLUPR0501MB2049: x-ms-office365-filtering-correlation-id: ccf69596-1e41-4b6b-37c1-08d49b9fdac0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BLUPR0501MB2049; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148); SRVR:BLUPR0501MB2049; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2049; x-forefront-prvs: 0308EE423E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39850400002)(39400400002)(39840400002)(39450400003)(39410400002)(13464003)(377454003)(76176999)(2906002)(54356999)(50986999)(3280700002)(3660700001)(2501003)(53546009)(25786009)(102836003)(6116002)(3846002)(15650500001)(38730400002)(230783001)(6246003)(478600001)(5660300001)(66066001)(99286003)(2900100001)(6306002)(9686003)(6436002)(55016002)(53936002)(122556002)(74316002)(305945005)(2950100002)(229853002)(7736002)(7696004)(86362001)(8676002)(6506006)(8936002)(33656002)(189998001)(81166006)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2049; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2017 14:37:03.6977 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2049 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 14:41:24 -0000 Hi Tom, Thanks for doing this work. The following are a few obsessive/compulsive co= mments: 1) When a packet is dropped because an extension header is too large (Secti= on 3.2), it would be great if the ICMP message could indicate the maximum = size for the offending extension header. You could use the pointer to do th= is. Rather than setting the pointer to reference the first byte of the offe= nding header, set the pointer to reference the first offending byte of the = offending header. 2) Same comment for Sections 3.3 and 3.4 3) I'm not sure that I get the difference between Extension Header Chain To= o Long (Section 3.3) and Headers Too Long (Section 3.5). Are you saying tha= t there is a case where 3.5 will be true and 3.3 will be false? 4) What happens when a packet is dropped for more than one of the condition= s listed in 3.1 - 3.5? What is the priority of reporting? = Ron > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert > Sent: Wednesday, May 10, 2017 6:22 PM > To: 6man@ietf.org > Subject: Fwd: New Version Notification for draft-herbert-6man-icmp-limits= - > 01.txt >=20 > Hello, >=20 > I added a section on host's response to the ICMP errors in this version. >=20 > Also, I checked how Linux would deal with these errors. Currently, any > Parameter Problem ICMP errors are assumed to be hard errors. There are > reported to the application and in the case of TCP the connection is > terminated. We can modify this behavior to take more appropriate action f= or > the codes described in the draft. >=20 > Thanks, > Tom >=20 >=20 >=20 > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon May 15 09:15:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3D31294C7 for ; Mon, 15 May 2017 09:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxUi8xDVN56y for ; Mon, 15 May 2017 09:15:52 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BFB1293EE for <6man@ietf.org>; Mon, 15 May 2017 09:10:49 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id f55so50451300qta.3 for <6man@ietf.org>; Mon, 15 May 2017 09:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=J5VSPUMP6ByB3nlvORT/FVBPYk8rLvl947E9TL2IsSc=; b=gSVcxMEFVlAJTzIa+Cy4CcoJK0+jPKeRwxyNHPQbfQoVc38bHFDNa28s2y8AwH64oF hF04hUjZI8m2IpY4BaWO8SCDyyx5SHZt13iPmyWxtFhVSUSEKHF4pe87G6zlJ/Xfz8wY +X+873Bn0xi50GwcHfbeCEEz/h0vfVK0+v92ehCi4y1tF93xxKHGfASdfvlpHXWvxzbD GdxedGDLuXlXYkzcR00jxMhMQboRDNTdEt9AWjiHi+ebhLuWottGUEQOAaQqEJQtrP/F Rc7WFZhlsBjzrbn3GQ/y4pi4UcaNkttidW157bUPTxvPNSlQqJX7D39Ko4ZyxI9xANNI 1S+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=J5VSPUMP6ByB3nlvORT/FVBPYk8rLvl947E9TL2IsSc=; b=I27ubL1qs6Nl4afffxSg4/XcS8LQv4IMNOOOfQT5zxJ79JYX/prqsYl2ZOoHGuEbvf AV799ubzk7I23DTKc9chJ5R+NRIdxTPsjWGoJdctztxEDcAtka9jI4zFYKVc4K6sgUJo z2pMvoKH5oRtXywrCSMi7sXBWL/WW2C2ZnmMUNqfBnQWixp+jwYX46p6QbpQb7KVa1oG SIz/KIr0KuUnLQ4bmmjtzB2M46WDAk6TmGrwHPjUvaL1xdG8SHeeQdIZyV4DYQM4fddP Fphjf7WOp/Mld71LzQn5dlSiUYI4yKSBN/MZcfcfoWQXJf7XP71MUq5vcSPeP61Ex+Kz gjXQ== X-Gm-Message-State: AODbwcD7FKkEc96P8Rl2TNru4CNpe86Buc9VXvvusy1OSVZ7b/KhdHsq tdiTC2aMGL1UFFjKdVo1Bm7Do/c84g== X-Received: by 10.237.36.3 with SMTP id r3mr6399185qtc.200.1494864648673; Mon, 15 May 2017 09:10:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Mon, 15 May 2017 09:10:48 -0700 (PDT) In-Reply-To: References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Mon, 15 May 2017 09:10:48 -0700 Message-ID: Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-01.txt To: Ron Bonica Cc: "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 16:15:54 -0000 On Mon, May 15, 2017 at 7:37 AM, Ron Bonica wrote: > Hi Tom, > > Thanks for doing this work. The following are a few obsessive/compulsive = comments: > Hi Ron, > 1) When a packet is dropped because an extension header is too large (Sec= tion 3.2), it would be great if the ICMP message could indicate the maximu= m size for the offending extension header. You could use the pointer to do = this. Rather than setting the pointer to reference the first byte of the of= fending header, set the pointer to reference the first offending byte of th= e offending header. Yes, that is better. > 2) Same comment for Sections 3.3 and 3.4 > 3) I'm not sure that I get the difference between Extension Header Chain = Too Long (Section 3.3) and Headers Too Long (Section 3.5). Are you saying t= hat there is a case where 3.5 will be true and 3.3 will be false? Headers too long could be caused by and reference encapsulation headers as the culprit, it's not specific to extension headers. > 4) What happens when a packet is dropped for more than one of the conditi= ons listed in 3.1 - 3.5? What is the priority of reporting? Priority for reporting should be specified. May order is (most specific to least specific problem): - Real error (existing codes) - Too many options in EH - Extension header too big - Extension header chain too long - Headers too long Tom > > = Ron > > >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert >> Sent: Wednesday, May 10, 2017 6:22 PM >> To: 6man@ietf.org >> Subject: Fwd: New Version Notification for draft-herbert-6man-icmp-limit= s- >> 01.txt >> >> Hello, >> >> I added a section on host's response to the ICMP errors in this version. >> >> Also, I checked how Linux would deal with these errors. Currently, any >> Parameter Problem ICMP errors are assumed to be hard errors. There are >> reported to the application and in the case of TCP the connection is >> terminated. We can modify this behavior to take more appropriate action = for >> the codes described in the draft. >> >> Thanks, >> Tom >> >> >> >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Mon May 15 10:56:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F70129AFE for ; Mon, 15 May 2017 10:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=juniper.net 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 FIneK3ZmKTb3 for ; Mon, 15 May 2017 10:56:40 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0125.outbound.protection.outlook.com [104.47.41.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B43E1200C5 for <6man@ietf.org>; Mon, 15 May 2017 10:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=x/C5SlVfWbdRHqeBC7MRG6+lxyYKJtpEJWn5qpdamSQ=; b=AK+gjWCEzZp61dvcsAYmiHCmdhQoSQ3Mjg8DTn2VoZ6xKP9mU/BVxjyghsYhE57WBIWSDMO9lLHLNvKEBOBuERJAJD2yyogCHGg9h/8dy69wgo7x+4jz828KOa7XJFvzFdrzaJrtnmvhELTx5tHOCKsIMmQaN4dE/CaUyxi7AVw= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2049.namprd05.prod.outlook.com (10.164.23.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.8; Mon, 15 May 2017 17:53:26 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1101.011; Mon, 15 May 2017 17:53:26 +0000 From: Ron Bonica To: Tom Herbert CC: "6man@ietf.org" <6man@ietf.org> Subject: RE: New Version Notification for draft-herbert-6man-icmp-limits-01.txt Thread-Topic: New Version Notification for draft-herbert-6man-icmp-limits-01.txt Thread-Index: AQHSydvj2CNgsdR2N0SNyPfQvMZ6VaH1duKggAAhBwCAABvukA== Date: Mon, 15 May 2017 17:53:26 +0000 Message-ID: References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: herbertland.com; dkim=none (message not signed) header.d=none;herbertland.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2049; 7:R3kmiBiPatKLEtscy6c6lUn6mY1Ffty4Of97Jewc5mr2I4J41Fb1vRxcD9pYJCJl87yOv70AtJoAR/wT8eCDfZLG6KfBXGTmQyh+N5HNINRf+I4+EkynpxEFSwn90xW8vpLZ5yQz78jHwB0z6tuMOhQE8UZ+soSMcqCgJT/IdzYqh3ZZ3PGrm9E9xH5dPwBLclcF/UctqwJNAylUAeSXCVha6pgYeOpgBxNAaKPR1wvfHpxYca+9GfAIVxY5qGfQltcehtyt/Y3J8mccn4QKzGffuhSFymh+5vfKQG4MB5oTAgmgZ9uLUllt7WXArAvRBrI0KQghQA81z0Zj1HelPA== x-ms-traffictypediagnostic: BLUPR0501MB2049: x-ms-office365-filtering-correlation-id: 37bb1465-e788-4c2d-a556-08d49bbb49ee x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BLUPR0501MB2049; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148); SRVR:BLUPR0501MB2049; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2049; x-forefront-prvs: 0308EE423E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39410400002)(39450400003)(39400400002)(39840400002)(39850400002)(76176999)(2906002)(54356999)(50986999)(3280700002)(3660700001)(230783001)(25786009)(102836003)(4326008)(6116002)(3846002)(38730400002)(6246003)(110136004)(478600001)(66066001)(5660300001)(99286003)(2900100001)(9686003)(55016002)(6436002)(122556002)(53936002)(74316002)(305945005)(2950100002)(6916009)(229853002)(7736002)(7696004)(86362001)(6506006)(8676002)(81166006)(33656002)(8936002)(189998001)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2049; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2017 17:53:26.6555 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2049 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 17:56:42 -0000 VG9tLA0KDQpJIG1heSBiZSBwYXJzaW5nIHlvdXIgcmVzcG9uc2UgaW5jb3JyZWN0bHkuLiBDYW4g eW91IHByb3ZpZGUgYW4gZXhhbXBsZSB3aGVyZSBlbmNhcHN1bGF0aW9ucyBlbGljaXQgYSBIZWFk ZXJzIFRvbyBMb25nIGVycm9yIGNvZGU/DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFJvbg0KDQo+IA0KPiA+IDIpIFNhbWUgY29tbWVudCBmb3IgU2VjdGlv bnMgMy4zIGFuZCAzLjQNCj4gPiAzKSBJJ20gbm90IHN1cmUgdGhhdCBJIGdldCB0aGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIEV4dGVuc2lvbiBIZWFkZXIgQ2hhaW4NCj4gVG9vIExvbmcgKFNlY3Rpb24g My4zKSBhbmQgSGVhZGVycyBUb28gTG9uZyAoU2VjdGlvbiAzLjUpLiBBcmUgeW91IHNheWluZw0K PiB0aGF0IHRoZXJlIGlzIGEgY2FzZSB3aGVyZSAzLjUgd2lsbCBiZSB0cnVlIGFuZCAzLjMgd2ls bCBiZSBmYWxzZT8NCj4gDQo+IEhlYWRlcnMgdG9vIGxvbmcgY291bGQgYmUgY2F1c2VkIGJ5IGFu ZCByZWZlcmVuY2UgZW5jYXBzdWxhdGlvbiBoZWFkZXJzIGFzDQo+IHRoZSBjdWxwcml0LCBpdCdz IG5vdCBzcGVjaWZpYyB0byBleHRlbnNpb24gaGVhZGVycy4NCj4gDQoNCg== From nobody Mon May 15 14:30:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50A3126CF6 for ; Mon, 15 May 2017 14:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqJbyJWoNyP5 for ; Mon, 15 May 2017 14:30:48 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C7D129AFE for <6man@ietf.org>; Mon, 15 May 2017 14:27:48 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id t26so102218285qtg.0 for <6man@ietf.org>; Mon, 15 May 2017 14:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cu0aFPf7yez1u873JaluGVMYxhmOc2cCMMihZg4U03Q=; b=eiGYKhVAsTL11PMwFKJMEbI2+3+/0fdLlp8pvuVv+q9nPH/GYY5LQo3sxmggYMXXfJ NJCCSg7Jzaqi5JF84BSExiigld8ATtqNEiwnfP4IMuPDlH4HF8akoKrQMx1JZtGHil5F ZSccQRx15Dm2rpeqGsGokocgR1FWsGRaxUsMIlY6nNbOrY1HQweun+rFVYEAZIhXMFWD OLUN52fRC0qFSCoJFeeA6ANoZlydlKJpHM/FPPTXaifprOYj5J8wklg/USb2UZZcFgJ+ 5t6jLPO87b3rTt/z5y+2ohgipY6KG6MjroH/vJ802OW37HHjYTf+dLxqXKr7XEUGfCZI zvhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Cu0aFPf7yez1u873JaluGVMYxhmOc2cCMMihZg4U03Q=; b=nsJaOi22l6y4P6GBrsfVM/wFDnUOTmCih/VsxlrwIX5yPHVP2sUupo8ZU8GUShHWO0 aVmmLyb2cmFYQnLiWevaqZTvRMgnn1UxqqjTuVaJbS8TNrLwJjIRjmVYEyAiwLcHiIF/ Hg4RPIbGmjPHuUfZB45FmzWZv1oUe4hfbKucsyLtnA1/smOkN40n2C18Y6wVVTO9nnJQ MgP1lE+mUrWg11x4/HEL2gBcRkRikV6gEzmOhYbKl5nMAt8wu8dT/fBUVWuloWPamtdQ m7kIjoKXYjkGnMdxaNR4TAV3mZAQHX8QB2yYzOC4clTzpdrFIgs4fmIwUlKCgV0yee9X 7agg== X-Gm-Message-State: AODbwcCP9Qm8Judlpgq3MrmWqyYssO/92rOGUgc66FHwL2XbGtSKsNuw KO7+H04dIMz/eNBB3AB7aAVt3G8IqA== X-Received: by 10.237.61.28 with SMTP id g28mr7287931qtf.279.1494883667193; Mon, 15 May 2017 14:27:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Mon, 15 May 2017 14:27:46 -0700 (PDT) In-Reply-To: References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Mon, 15 May 2017 14:27:46 -0700 Message-ID: Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-01.txt To: Ron Bonica Cc: "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 21:30:49 -0000 On Mon, May 15, 2017 at 10:53 AM, Ron Bonica wrote: > Tom, > > I may be parsing your response incorrectly.. Can you provide an example where encapsulations elicit a Headers Too Long error code? It would be the case because of encapsulation a device is unable to parse the headers it wants (typically would be down to transport headers). For instance in Geneve, the maximum header length is 260 bytes. Adding UDP outer header and using it for IPv6/IPv6 encapsulation gets the headers before the inner transport header up to 348 bytes. That in itself may exceed a parsing buffer. A few more extension headers, SFC, or nested encapsulation could push the headers over 512 bytes that would probably exceed the parsing buffer sizes of many devices. So The Headers Too Long could be sent in this case. Implementing a fallback might be hard since there may be multiple sources of the headers, but at least this might give some visibility to packet drops happening. Tom > > Ron > >> >> > 2) Same comment for Sections 3.3 and 3.4 >> > 3) I'm not sure that I get the difference between Extension Header Chain >> Too Long (Section 3.3) and Headers Too Long (Section 3.5). Are you saying >> that there is a case where 3.5 will be true and 3.3 will be false? >> >> Headers too long could be caused by and reference encapsulation headers as >> the culprit, it's not specific to extension headers. >> > From nobody Tue May 16 09:56:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15182129493 for ; Tue, 16 May 2017 09:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=juniper.net 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 XUQeaLmUsWAr for ; Tue, 16 May 2017 09:56:40 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0107.outbound.protection.outlook.com [104.47.42.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35ED5129BB2 for <6man@ietf.org>; Tue, 16 May 2017 09:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qDxFtpQWnQGvyh6n7NOVhHy6n/d3ms7T72hhHVFMs+U=; b=kISGs6Vcbkrd1z9DE3qWInKRh0vLTfxQMI7Swk16Nf8EbFPSL3C7AX05yUnTnBL1h0lSjapqIf4MksdKCbAgZ9KJVkln0Q5yavtORVpzDbqkEzQL70D8lMrbvAsLykh55LJ2ZkGktxyZ2BxrAupAUQ6hiUTbD6uHg89aoqSUV4g= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2050.namprd05.prod.outlook.com (10.164.23.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.8; Tue, 16 May 2017 16:52:13 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1101.011; Tue, 16 May 2017 16:52:13 +0000 From: Ron Bonica To: Tom Herbert CC: "6man@ietf.org" <6man@ietf.org> Subject: RE: New Version Notification for draft-herbert-6man-icmp-limits-01.txt Thread-Topic: New Version Notification for draft-herbert-6man-icmp-limits-01.txt Thread-Index: AQHSydvj2CNgsdR2N0SNyPfQvMZ6VaH1duKggAAhBwCAABvukIAAPKEAgAFC5PA= Date: Tue, 16 May 2017 16:52:13 +0000 Message-ID: References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: herbertland.com; dkim=none (message not signed) header.d=none;herbertland.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2050; 7:W/jKDp6GRf/42tPflP6Wb+3sk/S0x2EKvAI28SRQ1OFMDXxal+DvzUzsO5hUvMpnhwF/s4TcOGOCHIJeFbN+UK4pehrv7ZnE1TG6LMYf/TKxmuR10Awa6FU8m+rA2IJYTkK4tHVXF4lEz3/4HH9cya0gFmTxv4uKn6Ed8FPWcjzpq3+PlVelOSfotPXyt8SPZY3muLTJ7XNAH5j34QLUhAEPt60rvnHdnorvTob9sZ9H9M46RzvSj4B4fvbx27bapraOXZ6s7x6Q66y8vsHrI4jt6No2cMcIWSKVGS0Dftl1sSu3rOYJ5+COtkBlTdGLp6Ro3jB1DsEFif4kvgiTBA== x-ms-traffictypediagnostic: BLUPR0501MB2050: x-ms-office365-filtering-correlation-id: 780d880c-5b45-449e-7939-08d49c7be6c1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BLUPR0501MB2050; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(6072148); SRVR:BLUPR0501MB2050; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2050; x-forefront-prvs: 03094A4065 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39850400002)(39410400002)(39400400002)(39450400003)(377454003)(13464003)(24454002)(5660300001)(66066001)(305945005)(3660700001)(53546009)(74316002)(15650500001)(229853002)(7696004)(33656002)(50986999)(6116002)(102836003)(76176999)(3846002)(2950100002)(122556002)(6916009)(54356999)(81166006)(8676002)(25786009)(6246003)(38730400002)(110136004)(3280700002)(9686003)(4326008)(53936002)(2900100001)(189998001)(93886004)(230783001)(55016002)(99286003)(77096006)(6506006)(6436002)(8936002)(7736002)(2906002)(478600001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2050; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2017 16:52:13.1807 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2050 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 16:56:43 -0000 VG9tLA0KDQpJIHdhcyBjb25mdXNlZCBiZWZvcmUgcmVhZGluZyB5b3VyIHJlc3BvbnNlLiBOb3cg SSBhIHByb2ZvdW5kbHkgY29uZnVzZWQgOi0vDQoNCkluIHlvdXIgZXhhbXBsZSwgSSB0aGluayB0 aGF0IHRoZSBoZWFkZXIgc3RhY2sgbG9va3MgbGlrZSB0aGlzOg0KDQpBKSBwYXlsb2FkDQoJMykg ZGF0YQ0KCTIpIFRDUCBoZWFkZXIgKDggYnl0ZXMpDQoJMSkgSVB2NiBoZWFkZXIgKDQwIGJ5dGVz KQ0KQikgR2VuZXZlDQoJMykgR2VuZXZlIGhlYWRlciAoMjYwIGJ5dGVzKQ0KCTIpIFVEUCBIZWFk ZXIgKDggYnl0ZXMpDQoJMSkgSVB2NiBIZWFkZXIgKDQwIGJ5dGVzKQ0KDQoNCkl0IGRvZXNuJ3Qg Y29udGFpbiBhbnkgSVB2NiBleHRlbnNpb24gaGVhZGVycyBhdCBhbGwuIEEgdHJhbnNpdCByb3V0 ZXIsIGFjdGluZyAgYXMgYSBtaWRkbGVib3gsIG5lZWRzIHRvIHNlZSB0aGUgVENQIGhlYWRlciwg YnV0IGNhbid0IGJlY2F1c2UgdGhlIFRDUCBoZWFkZXIgaXMgMzQwIGJ5dGVzIGludG8gdGhlIHBh Y2tldC4gU28sIHdlIHNlbmQgYW4gSUNNUHY2IFBhcmFtZXRlciBQcm9ibGVtLiANCg0KRG8gSSBo YXZlIHRoYXQgbXVjaCByaWdodD8NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24N Cg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRvbSBIZXJiZXJ0IFtt YWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4gU2VudDogTW9uZGF5LCBNYXkgMTUsIDIwMTcg NToyOCBQTQ0KPiBUbzogUm9uIEJvbmljYSA8cmJvbmljYUBqdW5pcGVyLm5ldD4NCj4gQ2M6IDZt YW5AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtaGVyYmVydC02bWFuLWljbXAtbGltaXRzLQ0KPiAwMS50eHQNCj4gDQo+IE9uIE1vbiwg TWF5IDE1LCAyMDE3IGF0IDEwOjUzIEFNLCBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0 Pg0KPiB3cm90ZToNCj4gPiBUb20sDQo+ID4NCj4gPiBJIG1heSBiZSBwYXJzaW5nIHlvdXIgcmVz cG9uc2UgaW5jb3JyZWN0bHkuLiBDYW4geW91IHByb3ZpZGUgYW4gZXhhbXBsZQ0KPiB3aGVyZSBl bmNhcHN1bGF0aW9ucyBlbGljaXQgYSBIZWFkZXJzIFRvbyBMb25nIGVycm9yIGNvZGU/DQo+IA0K PiBJdCB3b3VsZCBiZSB0aGUgY2FzZSBiZWNhdXNlIG9mIGVuY2Fwc3VsYXRpb24gYSBkZXZpY2Ug aXMgdW5hYmxlIHRvIHBhcnNlIHRoZQ0KPiBoZWFkZXJzIGl0IHdhbnRzICh0eXBpY2FsbHkgd291 bGQgYmUgZG93biB0byB0cmFuc3BvcnQgaGVhZGVycykuIEZvcg0KPiBpbnN0YW5jZSBpbiBHZW5l dmUsIHRoZSBtYXhpbXVtIGhlYWRlciBsZW5ndGggaXMgMjYwIGJ5dGVzLiBBZGRpbmcgVURQDQo+ IG91dGVyIGhlYWRlciBhbmQgdXNpbmcgaXQgZm9yIElQdjYvSVB2NiBlbmNhcHN1bGF0aW9uIGdl dHMgdGhlIGhlYWRlcnMNCj4gYmVmb3JlIHRoZSBpbm5lciB0cmFuc3BvcnQgaGVhZGVyIHVwIHRv DQo+IDM0OCBieXRlcy4gVGhhdCBpbiBpdHNlbGYgbWF5IGV4Y2VlZCBhIHBhcnNpbmcgYnVmZmVy LiBBIGZldyBtb3JlIGV4dGVuc2lvbg0KPiBoZWFkZXJzLCBTRkMsIG9yIG5lc3RlZCBlbmNhcHN1 bGF0aW9uIGNvdWxkIHB1c2ggdGhlIGhlYWRlcnMgb3ZlciA1MTINCj4gYnl0ZXMgdGhhdCB3b3Vs ZCBwcm9iYWJseSBleGNlZWQgdGhlIHBhcnNpbmcgYnVmZmVyIHNpemVzIG9mIG1hbnkgZGV2aWNl cy4NCj4gU28gVGhlIEhlYWRlcnMgVG9vIExvbmcgY291bGQgYmUgc2VudCBpbiB0aGlzIGNhc2Uu DQo+IEltcGxlbWVudGluZyBhIGZhbGxiYWNrIG1pZ2h0IGJlIGhhcmQgc2luY2UgdGhlcmUgbWF5 IGJlIG11bHRpcGxlIHNvdXJjZXMNCj4gb2YgdGhlIGhlYWRlcnMsIGJ1dCBhdCBsZWFzdCB0aGlz IG1pZ2h0IGdpdmUgc29tZSB2aXNpYmlsaXR5IHRvIHBhY2tldCBkcm9wcw0KPiBoYXBwZW5pbmcu DQo+IA0KPiBUb20NCj4gDQo+ID4NCj4gPg0KPiA+IFJvbg0KPiA+DQo+ID4+DQo+ID4+ID4gMikg U2FtZSBjb21tZW50IGZvciBTZWN0aW9ucyAzLjMgYW5kIDMuNA0KPiA+PiA+IDMpIEknbSBub3Qg c3VyZSB0aGF0IEkgZ2V0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gRXh0ZW5zaW9uIEhlYWRlcg0K PiA+PiA+IENoYWluDQo+ID4+IFRvbyBMb25nIChTZWN0aW9uIDMuMykgYW5kIEhlYWRlcnMgVG9v IExvbmcgKFNlY3Rpb24gMy41KS4gQXJlIHlvdQ0KPiA+PiBzYXlpbmcgdGhhdCB0aGVyZSBpcyBh IGNhc2Ugd2hlcmUgMy41IHdpbGwgYmUgdHJ1ZSBhbmQgMy4zIHdpbGwgYmUgZmFsc2U/DQo+ID4+ DQo+ID4+IEhlYWRlcnMgdG9vIGxvbmcgY291bGQgYmUgY2F1c2VkIGJ5IGFuZCByZWZlcmVuY2Ug ZW5jYXBzdWxhdGlvbg0KPiA+PiBoZWFkZXJzIGFzIHRoZSBjdWxwcml0LCBpdCdzIG5vdCBzcGVj aWZpYyB0byBleHRlbnNpb24gaGVhZGVycy4NCj4gPj4NCj4gPg0K From nobody Tue May 16 10:17:29 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B90A8129455; Tue, 16 May 2017 10:17:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-rfc1981bis-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149495504170.6699.7212125958791087540@ietfa.amsl.com> Date: Tue, 16 May 2017 10:17:21 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 17:17:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : Path MTU Discovery for IP version 6 Authors : Jack McCann <> Stephen E. Deering <> Jeffrey Mogul <> Robert M. Hinden Filename : draft-ietf-6man-rfc1981bis-07.txt Pages : 21 Date : 2017-05-16 Abstract: This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC1981. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-07 https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc1981bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc1981bis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 16 10:25:58 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2DE1270A3; Tue, 16 May 2017 10:25:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-rfc2460bis-12.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149495554987.6733.15505140025280892596@ietfa.amsl.com> Date: Tue, 16 May 2017 10:25:49 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 17:25:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : Internet Protocol, Version 6 (IPv6) Specification Authors : Stephen E. Deering <> Robert M. Hinden Filename : draft-ietf-6man-rfc2460bis-12.txt Pages : 45 Date : 2017-05-16 Abstract: This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC2460 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-12 https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 16 10:38:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C8E12EC6D for ; Tue, 16 May 2017 10:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 p91Lkn2aCBzs for ; Tue, 16 May 2017 10:38:35 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 E93501200F3 for ; Tue, 16 May 2017 10:33:57 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id w50so81203099wrc.0 for ; Tue, 16 May 2017 10:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=+wUGeoztMdVKPUr/qOHDNTFshtaa9wNlDNGbOpm+w6o=; b=NbH2bF8wB41lbqSqFVT+TKsqdhz1t9Xa3u5Ghm+rxcVa8AawtAc7Gz7w5lDRp7USgp hg1644rhM6EIXy5pUuu+SEcZSxt/C5n/+WF102QwsWw4os30dSOd7dfY5FlFsrYW95iK tOiIE12SVhtSds8nsqjw0gte3qNZwqu1pZfZ33rX+pt48ob3gNae4SNJiIwx4zfeIH6t 3qFQvUvpIwkeHFS2+B6UOmYzozfbnl5vOaT8iCaVs1LWhtrEZp0AmaWVL9j8/wjOBw2z TaJXnSbKa3DvKsdx04K3WyAAkA5GZSpbKJ2AyqmTgo1RrNWEF8glrkikTzhpFabmFbNX oxaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=+wUGeoztMdVKPUr/qOHDNTFshtaa9wNlDNGbOpm+w6o=; b=bx0VXG0tBLxxmwZ+BcH9Lx+GOpa9+H4gljGf15E4gYt4xBAmxt48O2puQFeR1VDMHM RttC2B4Ui9W8K0WGX4C84x2GRvbY9UznoTHvkUYVjMe17U7BerV5fKxnuBo3c5TBZm5F 4lSPzYssqfxOBR6kqZtdIdRiRE7NtntcALsffEtqxnrL5ZLgdAMxG5PWj5dOvY5KXsXZ 2rASel+RyBRbVrr0iDSo+BMJr2uNG8QjsYSO/TawaBl7Fvxrx+9iSgiXuxVBQUiEf+53 dwN+lbuAXvw5Z+Be5H5wEE8kROOQ6vluS06IKraErGbR8OWNDGyXOx/3Rj5CuKiOazcn RHig== X-Gm-Message-State: AODbwcDxeUJcQhSDeqLKzmreMrlakTDKW/6esSmht0vlQIbsMTrnfDtL tlsQ3m5tE0iLZjLF/2Y= X-Received: by 10.223.130.15 with SMTP id 15mr10174275wrb.59.1494956036024; Tue, 16 May 2017 10:33:56 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:b09a:3081:7602:e4d0? ([2601:647:4d01:db10:b09a:3081:7602:e4d0]) by smtp.gmail.com with ESMTPSA id 2sm16197583wmk.20.2017.05.16.10.33.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 10:33:54 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_51357E46-339E-44D3-8D5F-A266FB4DF4CF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Message-Id: <3623BFCB-D83B-4832-986E-D6DE90B930A5@gmail.com> Date: Tue, 16 May 2017 10:33:47 -0700 Cc: Bob Hinden To: IPv6 List X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 17:38:37 -0000 --Apple-Mail=_51357E46-339E-44D3-8D5F-A266FB4DF4CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published a new version of rfc1981bis (-07). Links to the document = below. The changes from the IESG Discuss comments from IESG reviews. These = include: o Added Note to Introduction that document that this document doesn't cite RFC2119 and only uses lower case "should/must" language. Changed all upper case "should/ must" to lower case. o Added references for EMTU_S and EMTU_R. o Added clarification to Section 4 "Protocol Requirements" that nodes should detect decreases in PMTU as fast as possible. o Added clarification Section 5.2 "Storing PMTU information" that nodes with multiple interface, Path MTU information should be stored for each link. o Removed text in Section 5.2 about Retransmission because it was unneeded. o Removed text in Section 5.3 about Retransmission because it was unneeded. o Rewrote text in Section 5.4 "Packetization Layer actions" regarding reception to make it clearer. o Rewrote the text at the end of Section 5.4 to remove unnecessary details and clarify not change congestion window. o Added references in Section 5.5 for SCTP and added DCCP (and reference) the list of examples. o Added paragraph to Section 5.5 "Security Considerations" about black hole connections if PTB messages are not received, and comparison to PLPMTD. o Editorial changes. A diff from the previous version can be found at: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-07.txt Please review. This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Maintenance of the IETF. >=20 > Title : Path MTU Discovery for IP version 6 > Authors : Jack McCann <> > Stephen E. Deering <> > Jeffrey Mogul <> > Robert M. Hinden > Filename : draft-ietf-6man-rfc1981bis-07.txt > Pages : 21 > Date : 2017-05-16 >=20 > Abstract: > This document describes Path MTU Discovery for IP version 6. It is > largely derived from RFC 1191, which describes Path MTU Discovery = for > IP version 4. It obsoletes RFC1981. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-07 > https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc1981bis-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-07 --Apple-Mail=_51357E46-339E-44D3-8D5F-A266FB4DF4CF 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 iQEcBAEBCgAGBQJZGzf8AAoJEK7rdBF357uom8YH/iejNSC77w2zs804Uju5Y52T 9flWhBPabzokyIKQ7hmV2Pzd2sju+/VxL26sOMxSZNDsITTLeybQjb3qX4Crh9b9 WyUHCe8ZaTDfMhC0hg9iOIbaBy6a01cjLYNdZ5ByxYXCNFN0XV1yHVh6tEXwMt08 gM5uu12edpQXJjnrDGFWoyyWjUxnzKM4X6uLfyMLcEt00zgN653zMIaNLnlMj7kA 9aNi+WJUlg0ncMUX0/RbPZDtrdKYwaftoLKmdq25T8ldlwI+Fq3y54bydL5rZzlV Z6H4KTCoXvG1XM1zSm68KcgcD3Vyj1gLsez4zLJMAwaDK7/Bc2FnHSizOR2W2is= =bvI+ -----END PGP SIGNATURE----- --Apple-Mail=_51357E46-339E-44D3-8D5F-A266FB4DF4CF-- From nobody Tue May 16 10:42:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E714A12E053 for ; Tue, 16 May 2017 10:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ndjnBEzEaqzb for ; Tue, 16 May 2017 10:42:14 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E25126CD6 for ; Tue, 16 May 2017 10:37:23 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id l50so81118364wrc.3 for ; Tue, 16 May 2017 10:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=8DnfCHXBqATFO52kul6RiDtDXX0NyzQjetDTKMOG1Ns=; b=KkHUtJ7Auxep9EHGhTN4IqxV07USGA7hwStsgqwuNkb6kjCg7R+o4oNAxtqEnUqOTB ic55aPYkR12QA8YCGZ/xZhdsBTNBVfD/WVeI6qC715t6AnVs7ukv54VjTkaeaHEnHk1S hY77G1OWDQBt9932DnmIpJC3+fggHDnN7rXTOfSnT/EXN50R3uDCq1hSzAS7QIrhEAzK PevBcqInDzCM/Acs4hwKJRJy1Ufw+Cl8si0HLAkVZyAFA2NLGu2lBC30lNWc6uleQUpj AdPoatQiv59Ianw+028UvEOsoX+KaNnnh9xndQS6YraKEwSTu7DYPrB5Aw7iatN7Acap OGfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=8DnfCHXBqATFO52kul6RiDtDXX0NyzQjetDTKMOG1Ns=; b=ZUEdiffaVocBf7KnJRL1w+MuXnuksi2BP+X2scCqsLSf8Cl3KFPG0FTLSG2hd3tnBe qMK9hz0bSd54MezyT16ff5xHcenD6tECU+gEng0VWz8d2qSmAQozTWsIVpitt7g93/mn 8daEY1a92EaRRKnhJZotHG9ZMr1tNWHMtnhFvZ/FmjmK+cOzjKGw6o3p6cmkGBHWDjot bEUQ1tkabbvTd1DT69KZIqDE6BfyjipHrR0N/ZLQrntpCZDqOiqZE2ePqxMV8ofuPo5J obf360GBdf79crnIMLmU4BjVR4F+2NcCumWDeX7MDKp/EmK+zluVcTje4/Hcm3pzDIbY JdCw== X-Gm-Message-State: AODbwcCQEqiDM/YhRPhyfhrPpbB9iK9T3J022FdKZuxJh2CjdGyEPXP9 3Z5dlJvsGLYWSA== X-Received: by 10.223.134.22 with SMTP id 22mr7782503wrv.182.1494956241764; Tue, 16 May 2017 10:37:21 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:b09a:3081:7602:e4d0? ([2601:647:4d01:db10:b09a:3081:7602:e4d0]) by smtp.gmail.com with ESMTPSA id 17sm3371828wml.32.2017.05.16.10.37.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 10:37:20 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_AF4BBE51-9333-4B94-8682-7A72B88F6E75"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Message-Id: Date: Tue, 16 May 2017 10:37:14 -0700 Cc: Bob Hinden To: IPv6 List X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 17:42:16 -0000 --Apple-Mail=_AF4BBE51-9333-4B94-8682-7A72B88F6E75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published the -12 version of 6man working group draft of rfc2460bis. = Links below. The only changes in this draft was: o Editorial changes (mainly remove old duplicate paragraph). A diff from the -11 version can be found at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-12 Please review the changes. This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Maintenance of the IETF. >=20 > Title : Internet Protocol, Version 6 (IPv6) = Specification > Authors : Stephen E. Deering <> > Robert M. Hinden > Filename : draft-ietf-6man-rfc2460bis-12.txt > Pages : 45 > Date : 2017-05-16 >=20 > Abstract: > This document specifies version 6 of the Internet Protocol (IPv6). > It obsoletes RFC2460 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-12 > https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-12 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-12 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ --Apple-Mail=_AF4BBE51-9333-4B94-8682-7A72B88F6E75 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 iQEcBAEBCgAGBQJZGzjKAAoJEK7rdBF357uoX7cH/iKNFcelx1aKvHIyD2Fvpv2v QdX86Wx2qBDsjgXS/WnylcHVJD9IfngdwgqRYksJtDiAblpkTdmy/8m3C8LE+nUC PNZdma44lwpHER676Nm1A6QT4OJSjWryoqjV7Dh3rj1ldca4LInZlLSOeIRhV+Cw dpT5K4ZTzyS31WgS0RoQ80pgnxePNzuaD6Nsdduu/0EjYr6SaQexVKJKA1PH7n1Z aPNw6bBF1lZcjicuswAX1jkRjxNWMUTn5TNjk/nUqJECiCG35B85wzlq8l9zJEM8 A6r9pkw+E/855o0qfsBWw61SKjxC+eM0hTLsqCkXy/gthUAOsdlbXV/i4xu/6Zk= =vXlj -----END PGP SIGNATURE----- --Apple-Mail=_AF4BBE51-9333-4B94-8682-7A72B88F6E75-- From nobody Tue May 16 12:31:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDE312EBDD for ; Tue, 16 May 2017 12:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=btconnect.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 bnTkDBUdaO9a for ; Tue, 16 May 2017 12:31:04 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0130.outbound.protection.outlook.com [104.47.1.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B363812EBB3 for ; Tue, 16 May 2017 12:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BR8/H1zQ6vDl1H3TfvetZaLfa0qldfQao6cI6dJOfos=; b=fftetQ5LNQY+oebpexnjI/T4iwCznyGBwQR/YBTX+ba0qUHxJ3AMhdos5i4q163rJcLwD+Ra4TVD32tmM6oeRS/r2XcxniOUje1Rva/r8qicjpVALFE15pdjJOal1wRumA+mXFAwLqz5DQZCn6JW0yWpcfCFWv0n2/H/P7FZSkk= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by VI1PR0701MB3006.eurprd07.prod.outlook.com (2603:10a6:800:87::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.8; Tue, 16 May 2017 19:26:13 +0000 Message-ID: <014f01d2ce79$e6094ea0$4001a8c0@gateway.2wire.net> From: t.petch To: Bob Hinden , IPv6 List CC: Bob Hinden References: <3623BFCB-D83B-4832-986E-D6DE90B930A5@gmail.com> Subject: Re: Date: Tue, 16 May 2017 20:23:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: AM5PR04CA0005.eurprd04.prod.outlook.com (2603:10a6:206:1::18) To VI1PR0701MB3006.eurprd07.prod.outlook.com (2603:10a6:800:87::20) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI1PR0701MB3006: X-MS-Office365-Filtering-Correlation-Id: aaa83ddf-acf3-43f5-4bc2-08d49c916d6b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:VI1PR0701MB3006; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 3:92h41YX4M8hOIw1Ssurq1LaTRKulXLIz8IZjvZ0SLOJv6N9Mh+Cxc+VQSBEbORxJO7w7JnWCLZTSY+jHz48c6h1f72AfI5ZfKrAq30WCr/sMxEWfRXRzd/NH3u306JNA6c3Q8eE3Lllaf6bnSNzMLB4+xr9dW3KTctlzIofcmDX0rFnIEgl1tlw2cpkYrFPO2M3V1vQ3FniY8ZX4z9S0EAoRhGpItHxORzkjejpq+ImNXPT36YGLDsyjxNnRngxe9M1MF/uEdtr2AgChxLJGuRaF8QVbkfGenQF+6F0oW2MWV4oexxXbZqnOPpA7g0aakCHxjVqFdxBvZxflkBkVpQ==; 25:eIqn+SkcytgX9iew7B60RBJ0+1NnNcxNvrbmA+fd3nX9iK/vxuSLuhPqngIrhbswXqfpxwvu24IPBkObcRBfbMGHcDupNdG2YT9/dBDDJ7GROwhxZsoTkX5+1FxHvasiP1HRR6fTbx8654PqglvyXNBFoWacco+S4s4Sbl+QmwOMhpEaVGvkXpfuGvm4gg86oKOjiuQNC+52bOcCfAze3qpwceMfziU+78CG6Vds8VOCQTk3myBaEMmc48IflJMrBPvpeJooEF8/PVfY+C/61CktS5kHgyEdN02wpZd2Aks2+AzBUYe+w38qb5ayxl0OJQmieCSghgpbJXf0hgQ9sMAtGFOqICjQYgSCue2YuqmKrKQ3kd/gVUVpqKuFhIIMk8QMN3qvDssnemLLwU6LobsC11MjrK/yTSAVr9pJKfMJVgQH3r4I6R/fYhV6YjpLBDGyR/yHTfne4f/0MQr7em+whCfKQ2Azfihhz5DHIA8= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 31:kAxJcK4bTeYxu1kv2x77RLh9MqIeeU/O2RLQIqP5igoXGydWF6+LqXihZygtmY/7WyFIhQ0P9X2cG3YOVdSP/GolY42JoALKC7lYwMypF1Ypkt06mM3pPAtk1e9PcxiazZSbGmFHVKTtD/HzcK8+JhQ/OPmbwY6ZKlzZLtHjBVMc3dFRlmUGMbxo/PI5N8UuAJgJ5D5GmCaNLrQZh79oVFHqPrCw2iCX/uM67o1W4795u1tKk9PKwp+EKzpInB41AX/FlQzycUjt2AIJRUwwiQ==; 20:qICjhmKLzYIXr9cgUo2ZG2tBGKiJwtubMn2uhBOcPDmwqBucGYHPmHl19nFbc204Gte0dmlAIyWcYL478TEZidhyU4gPuWa4OwO/CgZKgKE23WVRsHYlHPDsZKx7ZYWlu0r9W4onDWSRgcXLIBh88+gSLG/nLyljAPmGL+0liKY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703036)(100105400095)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:VI1PR0701MB3006; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:VI1PR0701MB3006; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB3006; 4:Ytp7rp5TR/pUG5cFsjONr9uNvUOUcExpjsUTnB?= =?iso-8859-1?Q?dEF8AsFQZMUb8J846PMp+SE5IFlpCn5IBZ/ueiPv+R0SWRuGxiN3ONkgsD?= =?iso-8859-1?Q?3Mt+jNyPeGduSuIjDPO7q3JhAovgMQqdNVgZgj3bF8xtqKAbxQEbkQwazG?= =?iso-8859-1?Q?9VnGzltn992iV4ouQX3Vikp5bnP2wrjHHOWDco19FXy4QH18Gh49RnPQmN?= =?iso-8859-1?Q?pb+nwQ55gG9v4iqKPkr0z5GtYANQASwjeDFZfFfbBqST6sqrfl2pNAuQt9?= =?iso-8859-1?Q?gZxIMipINtPDKn0MvENj/8CjQW2noA+j2IrpaX0cdrANtWeniN3gjki1Wj?= =?iso-8859-1?Q?ONAxDMMLCmMnx8v29bWp50gXfEtkBcsSeTK/qMj9kn4ec0b0C8Gq08pur8?= =?iso-8859-1?Q?ffSjuaubslMKRM+FS2zmM5TBHzRpchMXUNMva11S+fqQLB8tldcGll2+5K?= =?iso-8859-1?Q?VGLDEqHQWHfSmI/728hHrtikjcHPLMOt9pEZTw/lgV4PwNlx1L7t/5ltvs?= =?iso-8859-1?Q?zy8+1GJoV6XetC8LL7y4bMSvi+Sw4cKmGdJi/WnGP7I/Q8Pgvn0AEQKcLG?= =?iso-8859-1?Q?88NYayKHf7KnsOtmsuIqK9dweWU0lEYj8S3FKuhGcybzK45L1zElU3sAYc?= =?iso-8859-1?Q?dTWgN/h3Nt348TFMlWaiAr2IeZxp/Wdltfpg3S7V2VFQE9GN9a8qT1iJqd?= =?iso-8859-1?Q?AMKQMZ9wemU0Wr6kjVFotMaxveaTlJ/xNI2RsFQZuPumh6CLWkf++ABqYb?= =?iso-8859-1?Q?M34Ru9og690xhLuCo7lcCJyQAVIOs9zVp3dOa2UFGzulR0i7huhcqMX41B?= =?iso-8859-1?Q?joHG2VRXUxq8fI4RU0ndb3QkANh8c5hh4RRcUsHD9KV1+EoK1LvIN16SU+?= =?iso-8859-1?Q?487uRUbvRbCSx6nYhlW8UwWVyr4R5+Ha9CcmARmvDB/zJTlUpYZ7V/w51F?= =?iso-8859-1?Q?NdX1evz/ndcSEG6MhXrtRRzOnC2VqOFDZP2VRcEKl5Vzj6CFpos1ACoKZ1?= =?iso-8859-1?Q?aosHVa0bzN778hbIHL2AxBupY7YhG2Z83btVlNH0FB7X1nt/4Zzr9N3f2y?= =?iso-8859-1?Q?tFKVPHeKT/Det2GQnLB6IwcZIUOkZEN8fTfq/phbKmBtHAC+LD8fTgaLtC?= =?iso-8859-1?Q?Gy0IApupbDPJFRY5LgDOUWp/elQ4bbMPFInmZgKGJBitfp8LBfNyFdlQgn?= =?iso-8859-1?Q?tmMthQfNpsss?= X-Forefront-PRVS: 03094A4065 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39840400002)(39850400002)(39860400002)(39400400002)(39450400003)(39410400002)(13464003)(377454003)(23756003)(66066001)(230783001)(3846002)(6116002)(6496005)(6486002)(47776003)(81166006)(8676002)(4720700003)(478600001)(6246003)(53936002)(5660300001)(38730400002)(229853002)(230700001)(2906002)(4326008)(84392002)(44736005)(189998001)(966005)(81686999)(33646002)(81816999)(61296003)(50226002)(7736002)(9686003)(6306002)(25786009)(1456003)(44716002)(86362001)(305945005)(62236002)(50466002)(1556002)(50986999)(76176999)(42186005); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3006; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB3006; 23:82S/HCIEVgotdMOE6qZvyYl4Ma3vmj7+uH0jb?= =?iso-8859-1?Q?qKZUiuQ8PrzVmu6W3R4xg/K4NXLQYcJLrpc9Kn61QpBO2iF65dvq2w7Fu8?= =?iso-8859-1?Q?Dorz2TMELAzDYeDSt3engM4BAExijoIoZ+X78VznsQ7mZN01AubgQNQH6w?= =?iso-8859-1?Q?wuban2mEeStIkQmVAZAHLJLyR2ROOfFOSj8aBTyiIGUQKjT3IoSEzBaVzD?= =?iso-8859-1?Q?DtMrE6Y5o4se4BU3E1xMl4xD55IyYGDcaj3/G5+mTNvLtS4Q9CFL75/VaP?= =?iso-8859-1?Q?/DaNThwn6gEMaAkybUj9VTx2i8lZqN/OtVeY03YCz34tm27Jvgfmn7kpTU?= =?iso-8859-1?Q?vCME/ndNcX492mpnyNeF1lpGTIAV4poZe+s/5iCk9Witl1dcLDf2uBjclM?= =?iso-8859-1?Q?WS9zlknZzhP3j0UsQuoHrHRInQnEQYVrlQLmU5i+bKxkJwYE4VBXXvdQTO?= =?iso-8859-1?Q?jZo/8WHpFEOhtzhooYN4Ci1yN6cfkGUip9FmqRvHkGip3rRO21j660FmTO?= =?iso-8859-1?Q?QwDDQb6r2orufH3Nls0sCWq4h5aXuJT6QIkoJAK4bMIeO82WyS+i9XnIZ/?= =?iso-8859-1?Q?rGFAw+9nUJmyuJ8Is5l4U1WMCnGoNTxQ+e+5n+vD1yatt/tuK1OJrW7ULd?= =?iso-8859-1?Q?iMlb3rTLTQC/c4zMKCBX2qGhncRA2TSqj3DbS3Uj5U118peHE3fQnsJ/nK?= =?iso-8859-1?Q?LICIXHOj7REs/Lnj0L9slzAhiT2+/kZOjJPy93ekKbPCDEbHkrAO7dGivJ?= =?iso-8859-1?Q?K0fw8xcEh0FSVtjn1Lj+Wnkr9600AkTqdNxV2hoSt3z3L1xeZNGckDswaX?= =?iso-8859-1?Q?rjmb02v0TBtvqDb02ZHuaqcZKocR1oobMY3yj6Cuh3xEw4seV1TSlneVPy?= =?iso-8859-1?Q?ZU90K/R+2l3N7swY8/j5TKfpmrHi2yNpc3lX7AEF2wMjGHf3lITG/0uOfU?= =?iso-8859-1?Q?gdK3Tx46w77d9YD3a+rhIRE79U5+KWNLnXww9zpjrVjxAFwakW1SWtVqOe?= =?iso-8859-1?Q?rw9oyVsDSy8pBoBsIDMUiZP/xUXjSDOSNYL9wfNrCWhIH/LF6DTu9nudmY?= =?iso-8859-1?Q?caGLWYK2YKEidzuEssrDNgrzGWrwaXmewqd6KPczPu+gTrufme7selVV1g?= =?iso-8859-1?Q?Vq1OiBG3RWcmhTPFNbHPyaSHlrJwTgtvxBKiDLg6pz9sZKd4bZYC8advad?= =?iso-8859-1?Q?otKwIQnHV8mk5JCBBj9d/I6RWtDCzLpZawEO38HwlmGHDCLMBErLGYHAdQ?= =?iso-8859-1?Q?WmBzcL2JbgeKRrvBW8u9O9QBMbOdz8hN6nchAQ+g4o2vlbahdU/wXR5CSK?= =?iso-8859-1?Q?+tPJJ9BovGhO8Sron6VOWFtOeFus2xXeouhUonEQN+WWJsQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 6:NrNr8JCt65MyW0zruwSAcH8leVBXC3HWtIlpmC9X9ayzOz/fuKDn0BhwD3JVuL5QRn9p+f+LWc4esFZ+vC7N7yC/AvUYzRJBmIhpgT+xDhD9mICDidti+vLgXRXNqbndUKEHi+dnuSjPIDYDNgV8PcSd8pnCMrmg0oSqjbuCcnoxkU79ziS6ELrIeUUEy0q+bWr2XYvpj5WxUF/pLcwf/IM3PaS/X75R79lgCnfZ/SzDDod+FjcBgPbYZVTfdmNiedGOP4pLI+bg1YOtWBhb40NndEHAFN3hPfRMC1kCZwMb5tlaH4NQ53X3zMW9ry22ZEBpCEZt87ykXQkU8a/gGMV3fHxMj3qaKDlIMBg/zb5U5ukQo/muGs5IGxhqQstWOOaQAW4K8gqodjFXObrNWUMa6m6UvpMp1NzUo3kpBPdiABmOESsHZMsaiH/VhCpQTiOwH14Phgsiz37E+rFsoLMFtlOGgQlIFYKP1GmyEiXwZmjj8uMlDd+FHNohgM2fjxKM3lmu3Wc5TYSQB3kQ8g== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 5:vb1dE1cLd0hokQS6nUplcNeDULmgdFbCKwiUBdZOeyntfAqadDB58sidkyPbKRQZos0vR51fTPEIyQJnt1H54EosQ9gtlHE/xnB1pfIa42ebx/okFScCCDJK257EA7WCc+Q5eVZRCKxKtnKd0WFdHkMBLGBKIq96Mf6RA0QjakLHFdJjZBuzbOBteoFlchoDsGRNRCoPRyCtzQxva6TKNl/bGLuaVy7YkjWFQK8f+Zxlu/UmFlS4KhgJwnEqh/gXTluK5GrjQiB3kcqXxum4dpgGpDD3MfKE82kJcGAAB5NrzQxbx2eRCawRP2v42zwHRD8pQM0e02qkbLDXPyjCUOX729zFGF/5ge268NjxP+YGAkPPK4WEXKbrcwIe9NSx50Qwa8sIxhEEGsqlJSgQBKjFLVujQyL5RctGq5yYYm8Mfi8UufZwLbrSfRKeNlBZ+xW2WrIkh/ALRv0pKTXgIv0jVuzHzG1pVF9ZNntU68V3wUvSHdoxliQAtnQg3PHe; 24:chYxF8RSYekPK3qHfz56+BqkmCIa9ejttf151bFib9Q7lQiNH4KBorETIQhwvKykljHb+8IctfL0y3UGQhKSE/zprFUsxjT8Ay68vcaI6HI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 7:SsbmoVJvZkuT8z2RX0hGR/e0bzQPnWUG2VdWAfQNYFIKePOeIoHcFmt+x9nG5ZArXnN+HkYT4QBRg3Hf2VaL4PzyCz3Pma2ACdx71B0mqlk6OUPbZzbK9whuW5IgXgghxeziWH96kWSCsT6aqO78PMKBbK9fkCxpwY4Bomt6xJP/zdtgy53T5CCNTKOYx6nRUg3+UdSxzM14Pd+91heOuXr3Ls/z4tS5nMvqywPYPj09nZ2I4TYwm2hHaznk0Koly2tHlu5K4DXDdJSbgXgmVItGRrQnbNUfInQvuATH6O89baIG/kKJOEZOa4rhH6OuCCgJcEJUemQlIuag+ULQhg== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2017 19:26:13.2547 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3006 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 19:31:06 -0000 Bob At the risk of missing the obvious, where has this I-D got to? I am used to DISCUSS' being resolved and the I-D going on to publication. Is this one back with the WG prior to ...? Another IETF Last Call, more Directorate reviews ...? Tom Petch ----- Original Message ----- From: "Bob Hinden" To: "IPv6 List" Cc: "Bob Hinden" Sent: Tuesday, May 16, 2017 6:33 PM > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue May 16 14:09:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D1812F280 for ; Tue, 16 May 2017 14:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8Gwpv466cQj for ; Tue, 16 May 2017 14:09:02 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 287F71294F7 for <6man@ietf.org>; Tue, 16 May 2017 14:04:06 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id a72so140837588qkj.2 for <6man@ietf.org>; Tue, 16 May 2017 14:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Zky+J/Y1gZ5lD1RmIvjm+TV/F/38hbVb0aJVYQovXcE=; b=bVdMizZa/baem/9IyysC8g8GFuQb/e5dCFHSFD5oyyZ0TflNB74Q8wkpW2+1uwd/f7 ksYMGlVx+amiWtYThzNF08CpwYyMvSsYqm+7Pcs3yVjCWEGjlZYpZ1UDoPD+6KtM5rKX Fw617ZgH+fuKNNyvTtsMDS4BU4/dhXozYNcU4482uowCtLC/GZ++sM0y0X1tkGsemnsA TXwKfl8irWyp9HjZZy6JVjCzsE2uoUgUxy3omQ+HAmkHzbQaqHKRipVommqizJyVJhUS UiQAD6PBLoDDTO9CFzY+FcDibEjJKTNARG+1+g1nfs9LUYPrAV02KeGAEM+EaA8FvLNA 9wzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Zky+J/Y1gZ5lD1RmIvjm+TV/F/38hbVb0aJVYQovXcE=; b=UimQ6bo6YyKEIPG512Lo1Eg+ED8q2pUSzqeHPKzKyORCVD3V+DokJlJNZLNNA7LsNd yiZCpDxjCjVBlUkE/lyyyMIwQhEk9JE/kzNY+7csanM/CUSpukgvyt1Sm/LOp/BNWdB7 dlBrx5PHnSv9xMnvh+pxsZCdJtPhWpaWZ3vtBICQQZoPPa/v5qtlEQ8AoVuUSO2HDumd 4ZPlhVwUEmRKNSy5m8T6Vc0UPtVSjmtZGRd/f0L7znxhzB9ib55UVk2bzkm2tPByMcbD kTxAmO3hxwda2dkaQhdoYWV0W5t7EfLLkBx20aMvXscPLN5cXcHYZnC3sRbGm4xown6m a6EA== X-Gm-Message-State: AODbwcCz7Ebn5/FxXvikZ2hQdHSqdCwu/wV+LdyJPFwSuHYfJMeWDg67 cMI52YS/0PpBPNhlJuQpeqlwM4eTHg== X-Received: by 10.55.154.143 with SMTP id c137mr11569055qke.177.1494968645309; Tue, 16 May 2017 14:04:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 16 May 2017 14:04:04 -0700 (PDT) In-Reply-To: References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Tue, 16 May 2017 14:04:04 -0700 Message-ID: Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-01.txt To: Ron Bonica Cc: "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 21:09:04 -0000 On Tue, May 16, 2017 at 9:52 AM, Ron Bonica wrote: > Tom, > > I was confused before reading your response. Now I a profoundly confused :-/ > > In your example, I think that the header stack looks like this: > > A) payload > 3) data > 2) TCP header (8 bytes) > 1) IPv6 header (40 bytes) > B) Geneve > 3) Geneve header (260 bytes) > 2) UDP Header (8 bytes) > 1) IPv6 Header (40 bytes) > > > It doesn't contain any IPv6 extension headers at all. A transit router, acting as a middlebox, needs to see the TCP header, but can't because the TCP header is 340 bytes into the packet. So, we send an ICMPv6 Parameter Problem. > > Do I have that much right? > Yes, that is correct. Looking at the definition of Parameter Problem in RFC1122 it seems the use here is okay even though the problem might not specifically be about IP layer. Tom > Ron > > >> -----Original Message----- >> From: Tom Herbert [mailto:tom@herbertland.com] >> Sent: Monday, May 15, 2017 5:28 PM >> To: Ron Bonica >> Cc: 6man@ietf.org >> Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits- >> 01.txt >> >> On Mon, May 15, 2017 at 10:53 AM, Ron Bonica >> wrote: >> > Tom, >> > >> > I may be parsing your response incorrectly.. Can you provide an example >> where encapsulations elicit a Headers Too Long error code? >> >> It would be the case because of encapsulation a device is unable to parse the >> headers it wants (typically would be down to transport headers). For >> instance in Geneve, the maximum header length is 260 bytes. Adding UDP >> outer header and using it for IPv6/IPv6 encapsulation gets the headers >> before the inner transport header up to >> 348 bytes. That in itself may exceed a parsing buffer. A few more extension >> headers, SFC, or nested encapsulation could push the headers over 512 >> bytes that would probably exceed the parsing buffer sizes of many devices. >> So The Headers Too Long could be sent in this case. >> Implementing a fallback might be hard since there may be multiple sources >> of the headers, but at least this might give some visibility to packet drops >> happening. >> >> Tom >> >> > >> > >> > Ron >> > >> >> >> >> > 2) Same comment for Sections 3.3 and 3.4 >> >> > 3) I'm not sure that I get the difference between Extension Header >> >> > Chain >> >> Too Long (Section 3.3) and Headers Too Long (Section 3.5). Are you >> >> saying that there is a case where 3.5 will be true and 3.3 will be false? >> >> >> >> Headers too long could be caused by and reference encapsulation >> >> headers as the culprit, it's not specific to extension headers. >> >> >> > From nobody Tue May 16 14:45:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DF212EC9F for ; Tue, 16 May 2017 14:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 cGI8kGGQXP5c for ; Tue, 16 May 2017 14:45:47 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::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 3D3AE129BDB for ; Tue, 16 May 2017 14:40:46 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id d68so5770968ita.1 for ; Tue, 16 May 2017 14:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DuD0kKaXoSK7EbIMyQFlONywsXcoLlQSawnaY6gLEYk=; b=aVK2QCqr2TR1/QfWi1mInxgBadqMqcKLtECKvICuJ9f9FxltB6eUG/Z/zyLDUJgjYB y8CkqcMX5CDQ+5lPe1/pGnbj8v7HMIVN/O4RX5sX1DC2itXqlN9c5tX3uqbr+nxMSRBV qgCumROjZTetO9MNiA5qYygf12pIo5w5/fVLt3HVbaypJHSLUFtep92F9F+qNWH6tg7A ti9Q5GSg4+Sblqm/c4L8nGYoLtc7pSryNiuBLNBupfslMtcPvZBYhSpbN3Cuf0A83W9c mobw4qzi1h0n0huIW6EeG+/vjwq76wPjaLJebZrQSTQXjMJSEBfwdbWT2AVnFd/4ZAKZ pz+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DuD0kKaXoSK7EbIMyQFlONywsXcoLlQSawnaY6gLEYk=; b=ZrxiZbGfiffPS5G/ELY6grkIHpWRMyoPVpokPfz6dkyj/NRccE200zH7+jPm4Y/3uw l2z9HzKMuSvvUu6ab5pCjBEqPIk09Vf6eBfr02PZ759PaGEvVi0e1euSyOL4e1gvf2XG FUzkv1zg4xNPLf10+OBQG+fxTyEJVvUXCAB+Tmhibo4bAI6HnhZ4a8ISnI9+yo0c7xyJ +3Hwk+0qxLazvLp2ekxcootrQ0yLGDsThmwr395LPTOycK8Cqeu8D1mWVD5XIu0UuNlb dS93Ro3/n10EGyAHkTbsGRS7/RdbWbmLABPs/s9R9C/Ed+RXvuVl0uxmgbKC2dscn51c V77A== X-Gm-Message-State: AODbwcB8lwLpjuoiJQFLgJ2aPSlNG60wfwy7E7Pep4RzN0jtUbacRyKn EuwrEjsNOHxD+g== X-Received: by 10.36.224.12 with SMTP id c12mr925202ith.100.1494970845566; Tue, 16 May 2017 14:40:45 -0700 (PDT) Received: from [10.96.154.80] ([199.246.153.206]) by smtp.gmail.com with ESMTPSA id h76sm230319ith.24.2017.05.16.14.40.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 14:40:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: From: Suresh Krishnan X-Priority: 3 In-Reply-To: <014f01d2ce79$e6094ea0$4001a8c0@gateway.2wire.net> Date: Tue, 16 May 2017 17:40:42 -0400 Cc: Bob Hinden , IPv6 List Content-Transfer-Encoding: quoted-printable Message-Id: References: <3623BFCB-D83B-4832-986E-D6DE90B930A5@gmail.com> <014f01d2ce79$e6094ea0$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 21:45:55 -0000 Hi Tom, > On May 16, 2017, at 3:23 PM, t.petch wrote: >=20 > Bob >=20 > At the risk of missing the obvious, where has this I-D got to? The draft is still in IESG evaluation. There are 4 ADs holding a DISCUSS = position on this draft. This new revision is aimed at resolving these = DISCUSSes. >=20 > I am used to DISCUSS' being resolved and the I-D going on to > publication. Is this one back with the WG prior to =E2=80=A6? No. This is not back in the WG. It is still with the IESG. Since the = DISCUSSes resulted in a bunch of text changes, the new version is being = announced here to make the WG participants aware of the changes. > Another IETF > Last Call, more Directorate reviews =E2=80=A6? Once the DISCUSSes clear, the document should be on its way towards = publication. Thanks Suresh From nobody Tue May 16 17:36:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDE512943B for ; Tue, 16 May 2017 17:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, 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 j5JhE4RUwBdB for ; Tue, 16 May 2017 17:36:01 -0700 (PDT) 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 B3AFD129534 for ; Tue, 16 May 2017 17:32:25 -0700 (PDT) Received: from [192.168.3.83] (unknown [181.165.123.103]) (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 BF56E80A6B; Wed, 17 May 2017 02:32:39 +0200 (CEST) Subject: Re: To: Bob Hinden , IPv6 List References: From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <51274c5a-7384-ddf3-d44c-f20e8c460097@si6networks.com> Date: Wed, 17 May 2017 02:32:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 00:36:03 -0000 Hello, Bob, On 05/16/2017 07:37 PM, Bob Hinden wrote: > Hi, > > I published the -12 version of 6man working group draft of rfc2460bis. Links below. > > The only changes in this draft was: > > o Editorial changes (mainly remove old duplicate paragraph). > > A diff from the -11 version can be found at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-12 > > Please review the changes. > > This is part of the project to move the core IPv6 specifications to Internet Standard. I just checked the ballot for this document. Mirja has a point here. in that rfc2460bis uses a different language than RFC6564. In retrospective, it would seem to me that rfc2460bis has the correct phrasing, and that RFC6564 is kind of using wrong RFC2119 language: it states a requirement as a MUST, but then gives reasons for not complying with such MUST -- that is, that's actually a SHOULD ;-) Not sure what would be the correct way forward -- maybe noting this in rfc2460bis and formally updating RFC6564? Just continue "as is" and fill an errata for RFC6564? 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 May 16 18:03:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D504131489 for ; Tue, 16 May 2017 18:03:35 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 3RcEpjH_EE_d for ; Tue, 16 May 2017 18:03:32 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 A657312E872 for ; Tue, 16 May 2017 17:59:24 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id w50so85654240wrc.0 for ; Tue, 16 May 2017 17:59:24 -0700 (PDT) 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=QdtFg8Vbu1fkA2Z+haAEeY7PqGphDCrG3ZXPQGIB1kY=; b=Y4URS3IEnPECEKC3heshT1epkfJp6ZrjdGRSGhpsGHImwtup6Cs1gQo3HvtgjyP3ec Ikd7QBzmOgaWK4cV0aFjjxZV+L4dfS1/hOwJ89kAQ0aKl8wGi0b57fHWUlF0/axlkni4 sKfUNzDqV1Xd63qmhgsZWyHf4i3tbJlKSWDyLWwCT6HeOJZIALIoRJUsbN6lMFyjyEtU yB+I5utCe1UYSG6w/CZaI2yHfgtCpKz8ao7ZPmF9ANtNtciHSBEfUWY5Xsr0mWZTmTyP 37E8ZpDzqHhCiBZJ9IaNTfY/hMMLXR2GQp8iAal5AhBpO55qMjFSgG/bQehVoAB1Xzz8 jb4Q== 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=QdtFg8Vbu1fkA2Z+haAEeY7PqGphDCrG3ZXPQGIB1kY=; b=rj2Jy6jszMUYCxGQuhWhQ+H3b/5QhL8C4pBLuyJqrA1dvuOrt/mEb0O8GAWrJIKTAS 2dzTuym92B5yuMb802wNibJBeW442qs8xcBRnsh9qiwNoJUWwCP6dYdtgjJ2xHyNerIw Qw/MVlC8fkt7cexDN8XKHDJj0C0Dbxb1nHpPw2ZR7xnXbLHVmr4ozUOEREllNxCoNrst shjOsNSfh0BbHHyv8UAlOL9GfLZgy2FJuw1fzy3iMnG9JLCG9TN06l15MHQElyk5zBlt iKL0fMMw55lpNZUBWDOHL2WXyJCRdUHyc/KRfXNWKg144Jg2/3txHxvOUVphBMR4qmUP u2BA== X-Gm-Message-State: AODbwcCQmJiU2Xp+I7LSpAOKfodtWEau/zW0Avx5CF/KY3luZJh3mYo5 6JgTH1gn92Zr4oOH/k4= X-Received: by 10.223.139.199 with SMTP id w7mr419639wra.92.1494982763050; Tue, 16 May 2017 17:59:23 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:850b:175c:2914:757c? ([2601:647:4d01:db10:850b:175c:2914:757c]) by smtp.gmail.com with ESMTPSA id 72sm16674014wmx.23.2017.05.16.17.59.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 17:59:22 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_DE931A24-0F02-448F-8678-6366FFD55A86"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Tue, 16 May 2017 17:59:15 -0700 In-Reply-To: <51274c5a-7384-ddf3-d44c-f20e8c460097@si6networks.com> Cc: Bob Hinden , IPv6 List To: Fernando Gont References: <51274c5a-7384-ddf3-d44c-f20e8c460097@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 01:03:35 -0000 --Apple-Mail=_DE931A24-0F02-448F-8678-6366FFD55A86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fernando, > On May 16, 2017, at 5:32 PM, Fernando Gont = wrote: >=20 > Hello, Bob, >=20 > On 05/16/2017 07:37 PM, Bob Hinden wrote: >> Hi, >>=20 >> I published the -12 version of 6man working group draft of = rfc2460bis. Links below. >>=20 >> The only changes in this draft was: >>=20 >> o Editorial changes (mainly remove old duplicate paragraph). >>=20 >> A diff from the -11 version can be found at: >>=20 >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-12 >>=20 >> Please review the changes. >>=20 >> This is part of the project to move the core IPv6 specifications to = Internet Standard. >=20 > I just checked the ballot for this document. Mirja has a point here. = in > that rfc2460bis uses a different language than RFC6564. In > retrospective, it would seem to me that rfc2460bis has the correct > phrasing, and that RFC6564 is kind of using wrong RFC2119 language: it > states a requirement as a MUST, but then gives reasons for not = complying > with such MUST -- that is, that's actually a SHOULD ;-) Right, I explained the situation in my email to Mirja about her Discuss = on May 9. >=20 > Not sure what would be the correct way forward -- maybe noting this in > rfc2460bis and formally updating RFC6564? Just continue "as is" and = fill > an errata for RFC6564? As you point out, rfc2460bis is correct. I don=E2=80=99t see much point in filing an errata on RFC6564. While it = should have said SHOULD, the =E2=80=9Cunless=E2=80=9D clause makes = it=E2=80=99s intent clear. Thanks, Bob >=20 > 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 --Apple-Mail=_DE931A24-0F02-448F-8678-6366FFD55A86 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 iQEcBAEBCgAGBQJZG6BkAAoJEK7rdBF357uoLXUH/3JBOOkH7JNxFhqVGKVBSIwG s9Yq/CkK2N25ivNO0RtzSVuPLgbpbOmc8ES9+umwLCEvGW/qrDsQTDGq4xLQ3ip2 H+dv/a2v8zoCCZ0vhdWCn0CrnW8TXdV/RnaJ/jvZaI6b9v/q2MIbpCqVnI2apz8L gBR4KBeVDqGkSuV3V6Y9b92kQ1CCd1K31Zjgty+bUprcJY4sdW4l8vLW+cOF5LXV gkYOddKe3Sp0yM47NKfp0CUK+O57bjwHh/nEQnAN5gJIYUi6V0n3FeKTUHrVoU2I VjrhlZ/1fMLTPr5zZlJmBTmw/ZJCZleRm+VgVnxfh92lWa5AI8tpdNfEYs3yrjc= =6pVh -----END PGP SIGNATURE----- --Apple-Mail=_DE931A24-0F02-448F-8678-6366FFD55A86-- From nobody Tue May 16 18:26:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9AB126CE8 for ; Tue, 16 May 2017 18:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZDrCgYIM39TP for ; Tue, 16 May 2017 18:26:10 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 E24B4129541 for ; Tue, 16 May 2017 18:22:23 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id u28so84500509pgn.1 for ; Tue, 16 May 2017 18:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=woXq71kSGpPHcsknZCyQsqvtxy9gUIGH4YfvUedH7MQ=; b=Taj4EdFrT6ap+b2xxjdIohO0NBJCaMUpZhwHvQupHkNTcp06REedAuQF/+4ULHOZ65 GrhRXGB8zLbKOAChYsRiZ8cjqojckb2Bb7pPNiLnhh2Y7n+oORza2FdaXDvw4f9t2zbd hxKN1VxFjDXUNmRX4Wc0RzlA12XNEXnz5SY8OFuymSZmI55sIgj6VjmNKfhGvcv2+yzA FADVLlWYiGnMwOJor3Y2v/XYuv8VXrtIHZ7mZgZYd8aWPGhZTg9r94Fsus/3Rppr+OMI h7dX16FdrHRUTvto1pZWXW8yKz95A24lwbrNyVT9qQ3Kwg+ZP4+E3HfJ8SDjjlknxWr2 JKEg== 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:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=woXq71kSGpPHcsknZCyQsqvtxy9gUIGH4YfvUedH7MQ=; b=G847Vhkn7L+rsvtcf2v6H6BjKv04kogGAEtghTFpVN9LHW9LHlwmTeZYjhBz3ax2se lLfiPzn8xgfvgwQ4aNjhMuvY1A5J952pcKmHCQOEXGPCS90viG5+H7cixOU9hrK7uQDJ Y3Y2L9v1idJM8X293bRudNiFo3ifLoNEu4eRnPLH5ON84b72blhRB2cjnzUuM8KSnV3R ipkHOj6nZq87m/y0IRv7b7JyjMdkJZyrjdpXxcztxADP6WEHV+P5qIxUsepbIt/UQorJ 5te+PJ72EsCpf0JI/aZEGAUaoLqo70fIl8fWSdgPv0mDfmXnGOALs3u03XtZ9DiAA9wd xkUA== X-Gm-Message-State: AODbwcC/8wXBW3+pe8v3TnRliO4TP+Qspirv7btSFk/cyTuUdsyPEV3s p6Ix3zJHG/mM6tb3 X-Received: by 10.84.150.101 with SMTP id g92mr1055440plg.149.1494984143253; Tue, 16 May 2017 18:22:23 -0700 (PDT) Received: from [172.24.17.228] ([202.36.244.180]) by smtp.gmail.com with ESMTPSA id i4sm470273pgd.7.2017.05.16.18.22.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 18:22:22 -0700 (PDT) Subject: Re: To: ipv6@ietf.org References: <51274c5a-7384-ddf3-d44c-f20e8c460097@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 17 May 2017 13:22:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 01:26:12 -0000 On 17/05/2017 12:59, Bob Hinden wrote: > Fernando, >=20 >> On May 16, 2017, at 5:32 PM, Fernando Gont wro= te: >> >> Hello, Bob, >> >> On 05/16/2017 07:37 PM, Bob Hinden wrote: >>> Hi, >>> >>> I published the -12 version of 6man working group draft of rfc2460bis= =2E Links below. >>> >>> The only changes in this draft was: >>> >>> o Editorial changes (mainly remove old duplicate paragraph). >>> >>> A diff from the -11 version can be found at: >>> >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-12 >>> >>> Please review the changes. >>> >>> This is part of the project to move the core IPv6 specifications to I= nternet Standard. >> >> I just checked the ballot for this document. Mirja has a point here. i= n >> that rfc2460bis uses a different language than RFC6564. In >> retrospective, it would seem to me that rfc2460bis has the correct >> phrasing, and that RFC6564 is kind of using wrong RFC2119 language: it= >> states a requirement as a MUST, but then gives reasons for not complyi= ng >> with such MUST -- that is, that's actually a SHOULD ;-) >=20 >=20 > Right, I explained the situation in my email to Mirja about her Discuss= on May 9. >=20 >> >> Not sure what would be the correct way forward -- maybe noting this in= >> rfc2460bis and formally updating RFC6564? Just continue "as is" and fi= ll >> an errata for RFC6564? >=20 > As you point out, rfc2460bis is correct. >=20 > I don=E2=80=99t see much point in filing an errata on RFC6564. While i= t should have said SHOULD, the =E2=80=9Cunless=E2=80=9D clause makes it=E2= =80=99s intent clear. Since RFC 2119 does not explicitly forbid the "MUST NOT unless" construct= , I'm not even sure it's an error. It's a great deal clearer than some pr= ohibitions: http://wtop.com/wp-content/uploads/2015/06/idaho_parking_ari_cropped2.jpg= Brian From nobody Wed May 17 01:12:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E43F12EA96 for ; Wed, 17 May 2017 01:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DXqkIeVlZEia for ; Wed, 17 May 2017 01:12:22 -0700 (PDT) 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 4FA7612EA64 for ; Wed, 17 May 2017 01:08:19 -0700 (PDT) Received: from [192.168.3.83] (unknown [181.165.123.103]) (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 67EEB809AB; Wed, 17 May 2017 10:08:34 +0200 (CEST) From: Fernando Gont Subject: Re: To: Brian E Carpenter , ipv6@ietf.org References: <51274c5a-7384-ddf3-d44c-f20e8c460097@si6networks.com> Message-ID: <78ce637f-5bbd-a90b-9617-c70687b86e09@si6networks.com> Date: Wed, 17 May 2017 09:59:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 08:12:24 -0000 On 05/17/2017 03:22 AM, Brian E Carpenter wrote: > On 17/05/2017 12:59, Bob Hinden wrote: >> Fernando, >> >>> On May 16, 2017, at 5:32 PM, Fernando Gont wrote: >>> >>> Hello, Bob, >>> >>> On 05/16/2017 07:37 PM, Bob Hinden wrote: >>>> Hi, >>>> >>>> I published the -12 version of 6man working group draft of rfc2460bis. Links below. >>>> >>>> The only changes in this draft was: >>>> >>>> o Editorial changes (mainly remove old duplicate paragraph). >>>> >>>> A diff from the -11 version can be found at: >>>> >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-12 >>>> >>>> Please review the changes. >>>> >>>> This is part of the project to move the core IPv6 specifications to Internet Standard. >>> >>> I just checked the ballot for this document. Mirja has a point here. in >>> that rfc2460bis uses a different language than RFC6564. In >>> retrospective, it would seem to me that rfc2460bis has the correct >>> phrasing, and that RFC6564 is kind of using wrong RFC2119 language: it >>> states a requirement as a MUST, but then gives reasons for not complying >>> with such MUST -- that is, that's actually a SHOULD ;-) >> >> >> Right, I explained the situation in my email to Mirja about her Discuss on May 9. >> >>> >>> Not sure what would be the correct way forward -- maybe noting this in >>> rfc2460bis and formally updating RFC6564? Just continue "as is" and fill >>> an errata for RFC6564? >> >> As you point out, rfc2460bis is correct. >> >> I don’t see much point in filing an errata on RFC6564. While it should have said SHOULD, the “unless” clause makes it’s intent clear. In normal prose, I'd agree. But with the RFC2119 where "MUST"/"MUST NOT" are employed to specify requirements that, if not met, would cause serious interperability problems.. I'm not sure how one would interpret such statement. For instance, if defining new EHs MUST NOT be done (because of the consequences) then, if you have a good reason to do so, you'd still be paying for the consequences. (if you still break stuff, then it should have been a "MUST" with no "unless". If you don't break stuff, then it should have been a "SHOULD"). > Since RFC 2119 does not explicitly forbid the "MUST NOT unless" construct, I'm not even sure it's an error. Strictly speaking, I might agree. However, my mental model is that only SHOULDs have such conditionals. > It's a great deal clearer than some prohibitions: > http://wtop.com/wp-content/uploads/2015/06/idaho_parking_ari_cropped2.jpg :-)) -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed May 17 03:06:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C77129B7A; Wed, 17 May 2017 03:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZPTgcDc0YR6; Wed, 17 May 2017 03:06:38 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC3B129B3A; Wed, 17 May 2017 03:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10015; q=dns/txt; s=iport; t=1495015274; x=1496224874; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=r2d1D+5jsKx1RaB4WHEdO6sHeUpwvoi991ElDfq7sRU=; b=j5vQLmMNEfWmswFuB17+Rne+zMTRN+e5x5D8irnCs7oZBFlUw4LE5Swy sYFaVsPd6bGYUEeSSBPjvCIIoZ7ZXm5HupTqgENad8W6pDTqMobMCC0tP KEv/pNZwBwa1/yIl3svzb94EWATFjmjRF5NdtmXEq3Yv+0B0a08KMhmwv A=; X-IronPort-AV: E=Sophos; i="5.38,353,1491264000"; d="scan'208,217"; a="28436049" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 May 2017 10:01:13 +0000 Received: from [10.82.217.158] (rtp-vpn3-412.cisco.com [10.82.217.158]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v4HA1CKl015865; Wed, 17 May 2017 10:01:12 GMT Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS) To: Bob Hinden , "Alvaro Retana (aretana)" Cc: IPv6 List , "draft-ietf-6man-rfc1981bis@ietf.org" , =?UTF-8?Q?Ole_Tr=c3=b8an?= , IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> References: <149427694020.22664.10344820301651708437.idtracker@ietfa.amsl.com> <5DE424DC-F18D-417B-B547-62F49A04B6C1@gmail.com> <2E927CD3-327A-4160-88D9-B901D9D532EA@cisco.com> From: Benoit Claise Message-ID: <7726dc86-daf7-6fa1-e956-9238fee39226@cisco.com> Date: Wed, 17 May 2017 06:01:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------ECF233A514031C16C2C90144" Content-Language: en-US Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 10:06:41 -0000 This is a multi-part message in MIME format. --------------ECF233A514031C16C2C90144 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, I've seen the resolution on Alvara's DISCUSS. Looking at https://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc1981bis-07.txt, there are so MUST, SHOULD, MAY modified to their lower case respective names that I wonder... Instead of going this easier path, shouldn't we have use the RFC 2119 keywords all over the place and create a clear spec according to today's "standard", read RFC 2119 keywords. Btw draft-ietf-6man-rfc2460bis doesn't use any RFC2119 keywords (which is weird these days) and doesn't contain a note such as: Note: This document is an update to [RFC1981] that was published prior to [RFC2119] being published. Consequently while it does use "should/must" style language in upper and lower case, the document does not cite the RFC2119 definitions. This update does not change that. At least, we should target consistency. Regards, Benoit > Alvaro, > > Thanks! > > Bob > > >> On May 10, 2017, at 12:43 PM, Alvaro Retana (aretana) wrote: >> >> Thanks Bob, that works for me. >> >> Alvaro. >> >> On 5/9/17, 10:37 AM, "Bob Hinden" wrote: >> >> Alvaro, >> >> Based on your Discuss, I am planning to add: >> >> Note: This document is an update to [RFC1981] that was published >> prior to [RFC2119] being published. Consequently while it does use >> "should/must" style language in upper and lower case, the document >> does not cite the RFC2119 definitions. This update does not change >> that. >> >> To the Introduction of this document. It should appear in the next published version of this draft. >> >> Thanks, >> Bob >> >> >> >>> On May 8, 2017, at 11:55 PM, Alvaro Retana wrote: >>> >>> Alvaro Retana has entered the following ballot position for >>> draft-ietf-6man-rfc1981bis-06: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I'm putting in this point as a DISCUSS because I think that the current >>> text may be confusing and vague. >>> >>> As others have pointed out, this document includes rfc2119-like language, >>> both capitalized and not. I realize that rfc1981 was published before >>> rfc2119 and that no expectation on the language existed then. However, >>> we're at a point in time where not only rfc2119 is in place, but >>> draft-leiba-rfc2119-update (which clarifies that only uppercase language >>> has special meaning) is in AUTH48. I think that this leads to the >>> possibility that the average reader may interpret the requirements in >>> this document in a way that it wasn't intended. >>> >>> While I would prefer that this document be consistent (and either use >>> capitalized rfc2119 language as intended, OR, not used it at all), I >>> understand the intent of not changing some of the original text. I would >>> be happy with a note like this one: "Note: This document is an update to >>> RFC1981 that was published prior to RFC2119 being published. >>> Consequently while it does use "should/must" style language in upper and >>> lower case, the document does not cite the RFC2119 definitions. This >>> update does not change that." [I borrowed this text from the the INTDIR >>> review thread. [1]] >>> >>> I find that including a note in the Shepherd's write-up is not enough >>> because the average reader/implementer will not consult it. >>> >>> >>> [1] >>> https://mailarchive.ietf.org/arch/msg/int-dir/bVH_0ydVdGssOiszJKhQXLYPuXY/?qid=4000f8a954b226266f429842911101f5 >>> >>> >>> >>> >> >> --------------ECF233A514031C16C2C90144 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
Dear all,

I've seen the resolution on Alvara's DISCUSS.
Looking at https://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc1981bis-07.txt, there are so MUST, SHOULD, MAY modified to their lower case respective names that I wonder...
Instead of going this easier path, shouldn't we have use the RFC 2119 keywords all over the place and create a clear spec according to today's "standard", read RFC 2119 keywords.

Btw draft-ietf-6man-rfc2460bis doesn't use any RFC2119 keywords (which is weird these days) and doesn't contain a note such as:
  Note: This document is an update to [RFC1981] that was published
  prior to [RFC2119] being published.  Consequently while it does use
  "should/must" style language in upper and lower case, the document
  does not cite the RFC2119 definitions.  This update does not change
  that.
At least, we should target consistency.

Regards, Benoit
Alvaro,

Thanks!

Bob



On May 10, 2017, at 12:43 PM, Alvaro Retana (aretana) <aretana@cisco.com> wrote:

Thanks Bob, that works for me.

Alvaro.

On 5/9/17, 10:37 AM, "Bob Hinden" <bob.hinden@gmail.com> wrote:

Alvaro,

Based on your Discuss, I am planning to add:

  Note: This document is an update to [RFC1981] that was published
  prior to [RFC2119] being published.  Consequently while it does use
  "should/must" style language in upper and lower case, the document
  does not cite the RFC2119 definitions.  This update does not change
  that.

To the Introduction of this document.  It should appear in the next published version of this draft.

Thanks,
Bob




On May 8, 2017, at 11:55 PM, Alvaro Retana <aretana@cisco.com> wrote:

Alvaro Retana has entered the following ballot position for
draft-ietf-6man-rfc1981bis-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm putting in this point as a DISCUSS because I think that the current
text may be confusing and vague.

As others have pointed out, this document includes rfc2119-like language,
both capitalized and not.  I realize that rfc1981 was published before
rfc2119 and that no expectation on the language existed then.  However,
we're at a point in time where not only rfc2119 is in place, but
draft-leiba-rfc2119-update (which clarifies that only uppercase language
has special meaning) is in AUTH48.  I think that this leads to the
possibility that the average reader may interpret the requirements in
this document in a way that it wasn't intended.

While I would prefer that this document be consistent (and either use
capitalized rfc2119 language as intended, OR, not used it at all), I
understand the intent of not changing some of the original text.  I would
be happy with a note like this one: "Note:  This document is an update to
RFC1981 that was published prior to RFC2119 being published.
Consequently while it does use "should/must" style language in upper and
lower case, the document does not cite the RFC2119 definitions.  This
update does not change that."   [I borrowed this text from the the INTDIR
review thread. [1]]

I find that including a note in the Shepherd's write-up is not enough
because the average reader/implementer will not consult it.


[1]
https://mailarchive.ietf.org/arch/msg/int-dir/bVH_0ydVdGssOiszJKhQXLYPuXY/?qid=4000f8a954b226266f429842911101f5









    

    

  


--------------ECF233A514031C16C2C90144--


From nobody Wed May 17 03:07:12 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F21A12EA57; Wed, 17 May 2017 03:07:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzYNO21zbZEl; Wed, 17 May 2017 03:06:50 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60095126B6D; Wed, 17 May 2017 03:01:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3929; q=dns/txt; s=iport; t=1495015289; x=1496224889; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=mviRCJN3AEwxLpo+64JQ4TaW4l+LokvJMoQmOwrbmFg=; b=E4TRGSZksYkgQYiMDnUIqU4HDRfYySKXqe8rq6LS7H5x//j72gM5JN+H nyexmOH0yC/ygP5eHJw8KhzCT/oADWtw8pRLFT22w4aLkTsnfFBRahUdE 0Lk6l8jjtDWJbi9BC4lRzQjvpLZXBE5K8xJnXx2M50gNNo169hTSj77Do 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAQCsHhxZ/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQyDbYoYkUUhlXWCDyyFeAKFWj8YAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?FIw8BBUEQCxgCAiYCAlcGDQYCAQGKHw6saYImiwYBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGgWBC4VUgV4rC4JlhDQSAYMugmAFiUaUSoccgzWISoIEhTyDQ4ZqjBaIMB8?= =?us-ascii?q?4fwsvIAgZFYVygWYkNgGGOYIuAQEB?=
X-IronPort-AV: E=Sophos;i="5.38,353,1491264000"; d="scan'208";a="244550973"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2017 10:01:28 +0000
Received: from [10.82.217.158] (rtp-vpn3-412.cisco.com [10.82.217.158]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v4HA1ROo000366; Wed, 17 May 2017 10:01:27 GMT
Subject: Re: Benoit Claise's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS and COMMENT)
To: Bob Hinden 
Cc: IESG , draft-ietf-6man-rfc1981bis@ietf.org, =?UTF-8?Q?Ole_Tr=c3=b8an?= , 6man Chairs <6man-chairs@ietf.org>, IPv6 List 
References: <149449953899.16665.14587982174992349533.idtracker@ietfa.amsl.com> 
From: Benoit Claise 
Message-ID: <65f9c678-62ab-c230-2680-ece0a34382e3@cisco.com>
Date: Wed, 17 May 2017 06:01:27 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 10:07:01 -0000

Hi Bob,
> Benoit,
>
> Comments below on your Discuss.
>
> Bob
>
>
>> On May 11, 2017, at 3:45 AM, Benoit Claise  wrote:
>>
>> Benoit Claise has entered the following ballot position for
>> draft-ietf-6man-rfc1981bis-06: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>>   Nodes not implementing Path MTU Discovery MUST use the IPv6 minimum
>>    link MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet
>>    size.
>>
>> I searched for "IPv6 minimum link MTU" in draft-ietf-6man-rfc2460bis-09,
>> and could not find that term.
> The text in rfc2460bis (unchanged from rfc2460) is:
>
> 5.  Packet Size Issues
>
>     IPv6 requires that every link in the internet have an MTU of 1280
>     octets or greater.  On any link that cannot convey a 1280-octet
>     packet in one piece, link-specific fragmentation and reassembly must
>     be provided at a layer below IPv6.
>
>     Links that have a configurable MTU (for example, PPP links [RFC1661])
>     must be configured to have an MTU of at least 1280 octets; it is
>     recommended that they be configured with an MTU of 1500 octets or
>     greater, to accommodate possible encapsulations (i.e., tunneling)
>     without incurring IPv6-layer fragmentation.
>
> rfc1981bis (and rfc1981) doesn’t use "IPv6 minimum link MTU” as a defined term (otherwise it would be in Section 2. “Terminology”.  It’s just words describing the concept in Section 5 of rfc2460bis (as shown above).
>
>
>> Even unlikely at this point in the IPv6 implementation cycle, we don't
>> want readers to believe that they should look at the minimum of the
>> device IPv6 MTU link(s).
>> Proposal: define "IPv6 minimum link MTU" as 1280 octets in 2460bis, or in
>> both documents.
> I think rfc1981bis (and rfc1981) are correct about pointing to rfc2460bis (and rfc2460).  Having to change it in two places would make it much harder to change it in the future.
So the term "IPv6 minimum link MTU" is being added in 
draft-ietf-6man-rfc2460bis, right?
I don't see it in the version posted yesterday.

Regards, B.
>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> In this document, I see:
>>
>>    IPv6 nodes SHOULD implement Path MTU Discovery in order to discover
>>    and take advantage of paths with PMTU greater than the IPv6 minimum
>>    link MTU [I-D.ietf-6man-rfc2460bis].  A minimal IPv6 implementation
>>    (e.g., in a boot ROM) may choose to omit implementation of Path MTU
>>    Discovery.
>>
>> In draft-ietf-6man-rfc2460bis-09:
>>    It is strongly recommended that IPv6 nodes implement Path MTU
>>    Discovery [RFC1981], in order to discover and take advantage of path
>>    MTUs greater than 1280 octets.  However, a minimal IPv6
>>    implementation (e.g., in a boot ROM) may simply restrict itself to
>>    sending packets no larger than 1280 octets, and omit implementation
>>    of Path MTU Discovery.
>>
>> So a SHOULD in one document versus "strongly recommended" in the other.
>>
>> We should reconcile the two texts.
>> Note: may and may are consistent.
>>
>>
>> ICMPv6 PTB => ICMPv6 Packet to Big (PTB)
>>
>>


From nobody Wed May 17 18:03:44 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D52A120724 for ; Wed, 17 May 2017 18:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=juniper.net
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 0P3NclH-yMzn for ; Wed, 17 May 2017 18:03:41 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0091.outbound.protection.outlook.com [104.47.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0132129329 for <6man@ietf.org>; Wed, 17 May 2017 18:03:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ermPjwVthP7SSOgeklVCjgLpq+ypo84MpB86mg+O2xs=; b=Vcm4gMfgMUa2LeOx/g+EZsFlH+zWmN5KGSvrXK4GGMKPG/vheBIXMa61nX/8RbjHh0hwbiqOUzT30WsRr0BnzDAj5pSI8tDVFfBE3dku5sXyDlVBqTl3IQ81xxigtid36/6lemt8BYljrVGHowRPCp/ymrbtkQbrML4I9vQ1AL0=
Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2052.namprd05.prod.outlook.com (10.164.23.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.8; Thu, 18 May 2017 01:03:40 +0000
Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1101.011; Thu, 18 May 2017 01:03:40 +0000
From: Ron Bonica 
To: Tom Herbert 
CC: "6man@ietf.org" <6man@ietf.org>
Subject: RE: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
Thread-Topic: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
Thread-Index: AQHSydvj2CNgsdR2N0SNyPfQvMZ6VaH1duKggAAhBwCAABvukIAAPKEAgAFC5PCAAEjSAIAB0s1w
Date: Thu, 18 May 2017 01:03:40 +0000
Message-ID: 
References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com>       
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: herbertland.com; dkim=none (message not signed) header.d=none;herbertland.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2052; 7:DBkKjMC4nqZRPxpRkdcP1uok7mn99Tn5NXiAOKzi1+w8Jz4NjpkzwPHNINBjMwqXtljlI653B/tNSRz5RsI67WLlJ1w8VO4G0ZLDwrg3xgjd4nLKvU+aSe5bGxbGLg7kboKBHm57ETV5GRfZMpx2kbgl9nLDNHzhTRdBWGdMIPtdlTDsIfWyzzEczVrx9fpe7B41Z+g21QiYQiyBsCeZKpzCjuc3kgtW8ni4AHPOQMhoyik2CU5Po/YAzbDDbDDuX4R/L0VYdk/LEsOBXo31GvfT/R56g+HarmXOwDmWLhEIECLUwtyeI0zm9gpbFOdItCwpmDJ2m4tHjzGAomehiQ==
x-ms-traffictypediagnostic: BLUPR0501MB2052:
x-ms-office365-filtering-correlation-id: cc11ae4a-1a5d-4dc2-baff-08d49d89b8e7
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:BLUPR0501MB2052; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(20161123564025)(20161123560025)(6072148); SRVR:BLUPR0501MB2052; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2052; 
x-forefront-prvs: 0311124FA9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39840400002)(39450400003)(39860400002)(39410400002)(39400400002)(51444003)(24454002)(13464003)(377454003)(8676002)(81166006)(6506006)(99286003)(6116002)(3846002)(77096006)(102836003)(66066001)(9686003)(189998001)(8936002)(55016002)(6436002)(229853002)(15650500001)(86362001)(4326008)(3280700002)(478600001)(33656002)(122556002)(3660700001)(6246003)(25786009)(74316002)(6916009)(76176999)(2900100001)(7736002)(5660300001)(38730400002)(53936002)(2950100002)(50986999)(305945005)(54356999)(110136004)(53546009)(93886004)(7696004)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2052; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2017 01:03:40.3506 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2052
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 01:03:43 -0000

VG9tLA0KDQpUaGUgSUNNUCBQYXJhbWV0ZXIgUHJvYmxlbSBtZXNzYWdlIG5vcm1hbGx5IGluZGlj
YXRlcyB0aGF0IHRoZXJlIGlzIGEgcHJvYmxlbSB3aXRoIGFuIElQIFBhcmFtZXRlci4gSW4gdGhl
IGV4YW1wbGUgYmVsb3csIHlvdSB1c2UgaXQgdG8gaW5kaWNhdGUgdGhhdCBhIG1pZGRsZSBib3gg
aGFzIGEgcHJvYmxlbSB3aXRoIHRoZSBJUCBwYXlsb2FkLiBUaGlzIHNlZW1zIHRvIGJlIG92ZXJs
b2FkaW5nIHRoZSBQYXJhbWV0ZXIgUHJvYmxlbSBtZXNzYWdlLg0KDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFJvbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv
bTogVG9tIEhlcmJlcnQgW21haWx0bzp0b21AaGVyYmVydGxhbmQuY29tXQ0KPiBTZW50OiBUdWVz
ZGF5LCBNYXkgMTYsIDIwMTcgNTowNCBQTQ0KPiBUbzogUm9uIEJvbmljYSA8cmJvbmljYUBqdW5p
cGVyLm5ldD4NCj4gQ2M6IDZtYW5AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IE5ldyBWZXJzaW9u
IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGVyYmVydC02bWFuLWljbXAtbGltaXRzLQ0KPiAwMS50
eHQNCj4gDQo+IE9uIFR1ZSwgTWF5IDE2LCAyMDE3IGF0IDk6NTIgQU0sIFJvbiBCb25pY2EgPHJi
b25pY2FAanVuaXBlci5uZXQ+IHdyb3RlOg0KPiA+IFRvbSwNCj4gPg0KPiA+IEkgd2FzIGNvbmZ1
c2VkIGJlZm9yZSByZWFkaW5nIHlvdXIgcmVzcG9uc2UuIE5vdyBJIGEgcHJvZm91bmRseQ0KPiA+
IGNvbmZ1c2VkIDotLw0KPiA+DQo+ID4gSW4geW91ciBleGFtcGxlLCBJIHRoaW5rIHRoYXQgdGhl
IGhlYWRlciBzdGFjayBsb29rcyBsaWtlIHRoaXM6DQo+ID4NCj4gPiBBKSBwYXlsb2FkDQo+ID4g
ICAgICAgICAzKSBkYXRhDQo+ID4gICAgICAgICAyKSBUQ1AgaGVhZGVyICg4IGJ5dGVzKQ0KPiA+
ICAgICAgICAgMSkgSVB2NiBoZWFkZXIgKDQwIGJ5dGVzKQ0KPiA+IEIpIEdlbmV2ZQ0KPiA+ICAg
ICAgICAgMykgR2VuZXZlIGhlYWRlciAoMjYwIGJ5dGVzKQ0KPiA+ICAgICAgICAgMikgVURQIEhl
YWRlciAoOCBieXRlcykNCj4gPiAgICAgICAgIDEpIElQdjYgSGVhZGVyICg0MCBieXRlcykNCj4g
Pg0KPiA+DQo+ID4gSXQgZG9lc24ndCBjb250YWluIGFueSBJUHY2IGV4dGVuc2lvbiBoZWFkZXJz
IGF0IGFsbC4gQSB0cmFuc2l0IHJvdXRlciwgYWN0aW5nDQo+IGFzIGEgbWlkZGxlYm94LCBuZWVk
cyB0byBzZWUgdGhlIFRDUCBoZWFkZXIsIGJ1dCBjYW4ndCBiZWNhdXNlIHRoZSBUQ1ANCj4gaGVh
ZGVyIGlzIDM0MCBieXRlcyBpbnRvIHRoZSBwYWNrZXQuIFNvLCB3ZSBzZW5kIGFuIElDTVB2NiBQ
YXJhbWV0ZXINCj4gUHJvYmxlbS4NCj4gPg0KPiA+IERvIEkgaGF2ZSB0aGF0IG11Y2ggcmlnaHQ/
DQo+ID4NCj4gWWVzLCB0aGF0IGlzIGNvcnJlY3QuIExvb2tpbmcgYXQgdGhlIGRlZmluaXRpb24g
b2YgUGFyYW1ldGVyIFByb2JsZW0gaW4NCj4gUkZDMTEyMiBpdCBzZWVtcyB0aGUgdXNlIGhlcmUg
aXMgb2theSBldmVuIHRob3VnaCB0aGUgcHJvYmxlbSBtaWdodCBub3QNCj4gc3BlY2lmaWNhbGx5
IGJlIGFib3V0ICBJUCBsYXllci4NCj4gDQo+IFRvbQ0KPiANCj4gPg0KPiA+IFJvbg0KPiA+DQo+
ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogVG9tIEhlcmJl
cnQgW21haWx0bzp0b21AaGVyYmVydGxhbmQuY29tXQ0KPiA+PiBTZW50OiBNb25kYXksIE1heSAx
NSwgMjAxNyA1OjI4IFBNDQo+ID4+IFRvOiBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0
Pg0KPiA+PiBDYzogNm1hbkBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogTmV3IFZlcnNpb24g
Tm90aWZpY2F0aW9uIGZvcg0KPiA+PiBkcmFmdC1oZXJiZXJ0LTZtYW4taWNtcC1saW1pdHMtIDAx
LnR4dA0KPiA+Pg0KPiA+PiBPbiBNb24sIE1heSAxNSwgMjAxNyBhdCAxMDo1MyBBTSwgUm9uIEJv
bmljYSA8cmJvbmljYUBqdW5pcGVyLm5ldD4NCj4gPj4gd3JvdGU6DQo+ID4+ID4gVG9tLA0KPiA+
PiA+DQo+ID4+ID4gSSBtYXkgYmUgcGFyc2luZyB5b3VyIHJlc3BvbnNlIGluY29ycmVjdGx5Li4g
Q2FuIHlvdSBwcm92aWRlIGFuDQo+ID4+ID4gZXhhbXBsZQ0KPiA+PiB3aGVyZSBlbmNhcHN1bGF0
aW9ucyBlbGljaXQgYSBIZWFkZXJzIFRvbyBMb25nIGVycm9yIGNvZGU/DQo+ID4+DQo+ID4+IEl0
IHdvdWxkIGJlIHRoZSBjYXNlIGJlY2F1c2Ugb2YgZW5jYXBzdWxhdGlvbiBhIGRldmljZSBpcyB1
bmFibGUgdG8NCj4gPj4gcGFyc2UgdGhlIGhlYWRlcnMgaXQgd2FudHMgKHR5cGljYWxseSB3b3Vs
ZCBiZSBkb3duIHRvIHRyYW5zcG9ydA0KPiA+PiBoZWFkZXJzKS4gRm9yIGluc3RhbmNlIGluIEdl
bmV2ZSwgdGhlIG1heGltdW0gaGVhZGVyIGxlbmd0aCBpcyAyNjANCj4gPj4gYnl0ZXMuIEFkZGlu
ZyBVRFAgb3V0ZXIgaGVhZGVyIGFuZCB1c2luZyBpdCBmb3IgSVB2Ni9JUHY2DQo+ID4+IGVuY2Fw
c3VsYXRpb24gZ2V0cyB0aGUgaGVhZGVycyBiZWZvcmUgdGhlIGlubmVyIHRyYW5zcG9ydCBoZWFk
ZXIgdXANCj4gPj4gdG8NCj4gPj4gMzQ4IGJ5dGVzLiBUaGF0IGluIGl0c2VsZiBtYXkgZXhjZWVk
IGEgcGFyc2luZyBidWZmZXIuIEEgZmV3IG1vcmUNCj4gPj4gZXh0ZW5zaW9uIGhlYWRlcnMsIFNG
Qywgb3IgbmVzdGVkIGVuY2Fwc3VsYXRpb24gY291bGQgcHVzaCB0aGUNCj4gPj4gaGVhZGVycyBv
dmVyIDUxMiBieXRlcyB0aGF0IHdvdWxkIHByb2JhYmx5IGV4Y2VlZCB0aGUgcGFyc2luZyBidWZm
ZXINCj4gc2l6ZXMgb2YgbWFueSBkZXZpY2VzLg0KPiA+PiBTbyBUaGUgSGVhZGVycyBUb28gTG9u
ZyBjb3VsZCBiZSBzZW50IGluIHRoaXMgY2FzZS4NCj4gPj4gSW1wbGVtZW50aW5nIGEgZmFsbGJh
Y2sgbWlnaHQgYmUgaGFyZCBzaW5jZSB0aGVyZSBtYXkgYmUgbXVsdGlwbGUNCj4gPj4gc291cmNl
cyBvZiB0aGUgaGVhZGVycywgYnV0IGF0IGxlYXN0IHRoaXMgbWlnaHQgZ2l2ZSBzb21lIHZpc2li
aWxpdHkNCj4gPj4gdG8gcGFja2V0IGRyb3BzIGhhcHBlbmluZy4NCj4gPj4NCj4gPj4gVG9tDQo+
ID4+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IFJvbg0KPiA+PiA+DQo+ID4+ID4+DQo+ID4+ID4+
ID4gMikgU2FtZSBjb21tZW50IGZvciBTZWN0aW9ucyAzLjMgYW5kIDMuNA0KPiA+PiA+PiA+IDMp
IEknbSBub3Qgc3VyZSB0aGF0IEkgZ2V0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gRXh0ZW5zaW9u
DQo+ID4+ID4+ID4gSGVhZGVyIENoYWluDQo+ID4+ID4+IFRvbyBMb25nIChTZWN0aW9uIDMuMykg
YW5kIEhlYWRlcnMgVG9vIExvbmcgKFNlY3Rpb24gMy41KS4gQXJlIHlvdQ0KPiA+PiA+PiBzYXlp
bmcgdGhhdCB0aGVyZSBpcyBhIGNhc2Ugd2hlcmUgMy41IHdpbGwgYmUgdHJ1ZSBhbmQgMy4zIHdp
bGwgYmUgZmFsc2U/DQo+ID4+ID4+DQo+ID4+ID4+IEhlYWRlcnMgdG9vIGxvbmcgY291bGQgYmUg
Y2F1c2VkIGJ5IGFuZCByZWZlcmVuY2UgZW5jYXBzdWxhdGlvbg0KPiA+PiA+PiBoZWFkZXJzIGFz
IHRoZSBjdWxwcml0LCBpdCdzIG5vdCBzcGVjaWZpYyB0byBleHRlbnNpb24gaGVhZGVycy4NCj4g
Pj4gPj4NCj4gPj4gPg0K


From nobody Thu May 18 08:19:06 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D34212949A for ; Thu, 18 May 2017 08:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.104
X-Spam-Level: 
X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 q_COSBb9035w for ; Thu, 18 May 2017 08:19:04 -0700 (PDT)
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 327421296C9 for ; Thu, 18 May 2017 08:13:14 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net;  b=IXl7j150U8IVAq0CL46IXnZv3FQR8LLeO/4YYQUNRcM3/ESw9gZN/l+tNJ4G9UpK9SKrYohbOAW5LFls2HuNO8h+ARom7EtyE56WUC2bHSEyl7ke4TS5sKNaowhe/NpMHRqznZiIu9qNqRNh2cPRBQzNMGumiyzlGW6D5eMmZDc=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 15552 invoked from network); 18 May 2017 17:13:12 +0200
Received: from marriott-chateau-champlain-montreal.sites.intello.com (HELO ?172.20.9.28?) (66.171.169.34) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 May 2017 17:13:11 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Your Discuss on (2017-05-08) on rfc2460bis
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: <26E4EEA9-3556-4BE4-BD4D-69A820866E24@gmail.com>
Date: Thu, 18 May 2017 11:13:09 -0400
Cc: =?utf-8?Q?Ole_Tr=C3=B8an?= , Suresh Krishnan , IPv6 List 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B87F5B4-7DD6-477E-B605-9CC9BAC99BD6@kuehlewind.net>
References: <26E4EEA9-3556-4BE4-BD4D-69A820866E24@gmail.com>
To: Bob Hinden 
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20170518151312.15544.40424@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 15:19:05 -0000

Hi Bob,

sorry for my late reply. But I have to say this does not fully resolve =
my issue. For me the text is not completely similar. Also I don=E2=80=99t =
understand why you specify the same thing normatively (using different =
words) in two documents. Usually it=E2=80=99s better to only specify it =
normatively in one document and refer to this in the other. That avoids =
confusion and makes updating in future much easier as it cannot lead to =
consistency problems. Would it be an option to make the text in 2460bis =
not normative (or even remove it) and clearly refer to RFC6564 as the =
normative specification?

Mirja


> Am 09.05.2017 um 03:46 schrieb Bob Hinden :
>=20
> Mirja,
>=20
>> Mirja K=C3=BChlewind
>>=20
>> Discuss (2017-05-08)
>>=20
>> Thanks for addressing my discuss. Text on rfc3168 is fine! I'm also =
okay with the text on extension headers, however, I have one remaining =
processing question: Now the text uses similar but not the same wording =
as RFC6564. RFC6564 says "new IPv6 extension headers MUST NOT be created =
or specified, ..." and this draft says "Defining new IPv6 extension =
headers is not recommended, ..." in not normative language. Is that on =
purpose? Does this draft need to absolete RFC6564 or refer or whatever?
>=20
> Thanks for clearing your other discusses.
>=20
> I assume you are referring to the last paragraph in Section 3 of =
RFC6564:
>=20
>  Mindful of the need for compatibility with existing IPv6 deployments,
>  new IPv6 extension headers MUST NOT be created or specified, unless
>  no existing IPv6 extension header can be used by specifying a new
>  option for that existing IPv6 extension header.  Any proposal to
>  create or specify a new IPv6 extension header MUST include a detailed
>  technical explanation of why no existing IPv6 extension header can be
>  used in the document proposing the new IPv6 extension header.
>=20
> With my editor=E2=80=99s hat on I choose the current language for two =
reasons.  The text above has MUST NOT followed by an =E2=80=9Cunless=E2=80=
=9D clause.  More like a should.   The use of the word =E2=80=9Crecommends=
" matches the style of the document where =E2=80=9Crecommend=E2=80=9D is =
used in a number of places in the document.  I think the intent of the =
text is very clear.
>=20
> The w.g. choose to not obsolete RFC6564 (or the other updating RFCs) =
because they provide additional background on why the updates that were =
made.  This is useful and is not obsoleted.
>=20
> Hope this resolves the issue you are raising.
>=20
> Thanks,
> Bob
>=20


From nobody Thu May 18 13:57:13 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D5112009C for ; Thu, 18 May 2017 13:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQtVTM5kdUeo for ; Thu, 18 May 2017 13:57:09 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 98175129AD0 for <6man@ietf.org>; Thu, 18 May 2017 13:50:48 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id v27so44427875qtg.2 for <6man@ietf.org>; Thu, 18 May 2017 13:50:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CXoteX3BagpR91+cK2qlv18nklKZQD2Jln5sRvbcVRA=; b=y8jAd/iWoI089kl2Ugzoj6oN5h7VHEGhR2HD3zUjcgIGbRXVUPhA4VHGXuOsrYnSmi cXx2qlmsc2CApij0trP9bmXX4iv32F6wu7pRFANQOlKF7IVOP2ZLYWKAiQ7lnn9gmjCn 1CiXkMmoQa7DhlDksI1zT/L77g6dt5WQSwjMWDUBxCI03dX88wFFnIpccGaFz9FmwwWO 3w26szIowCGChhjehyirPux1QCcPfVXlrqBACN+fSvsf3HSB3IEzmKpfQzo73alF4KUS YmQ9B6G6f33SvxXZMCeePZIVcgAJUIuVcSVv8GMBjeAV3PEReYRcT6Qw66ERP4l1sXOf d9HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CXoteX3BagpR91+cK2qlv18nklKZQD2Jln5sRvbcVRA=; b=FCtAQXy0ViurJ8EOzz/hfIzHn5UORQSnqX1bDvaDkEqlimFs8Pehhcw+u0BmrppoFl CK2/rEq0Tc2YlkyXF0C81ADYmyrPVjjfqsn/mzXWtGetOBReUR55Oeu1bcnfBsovhIZD xcqNVrXdNMUXOIEKJyqKTI6m8QzaT6VkHwdEqWgVYlEH2mBBA+66YgMfaVUqfiFzrBrr YyG3fIlp/5VFQnKUoh48eNBHRSowQvliFgTIg/yLdgp5vIUgcXsjK8m1qH/apsBc/9rj AxzOaSINwiUOmtD/qf8g6V/pspvzIJ94Ip/to9is/Uo7AOZyQfdld8PA4+d8ci/uMT3z AEyw==
X-Gm-Message-State: AODbwcAdRaqe3K5vBGnM8ZPGxHs39UxFwwZQV0d4DStxk8OKIqUmGmKU NeVgzOrYRXbRlGvNsTZeg/AQEnbqk4Dd
X-Received: by 10.200.3.79 with SMTP id w15mr5938792qtg.203.1495140647665; Thu, 18 May 2017 13:50:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Thu, 18 May 2017 13:50:47 -0700 (PDT)
In-Reply-To: 
References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com>        
From: Tom Herbert 
Date: Thu, 18 May 2017 13:50:47 -0700
Message-ID: 
Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
To: Ron Bonica 
Cc: "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 20:57:11 -0000

On Wed, May 17, 2017 at 6:03 PM, Ron Bonica  wrote:
> Tom,
>
> The ICMP Parameter Problem message normally indicates that there is a pro=
blem with an IP Parameter. In the example below, you use it to indicate tha=
t a middle box has a problem with the IP payload. This seems to be overload=
ing the Parameter Problem message.
>
Hi Ron,

Would Destination Unreachable message be appropriate then?

Tom

>                                                                          =
             Ron
>
>
>> -----Original Message-----
>> From: Tom Herbert [mailto:tom@herbertland.com]
>> Sent: Tuesday, May 16, 2017 5:04 PM
>> To: Ron Bonica 
>> Cc: 6man@ietf.org
>> Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits=
-
>> 01.txt
>>
>> On Tue, May 16, 2017 at 9:52 AM, Ron Bonica  wrote:
>> > Tom,
>> >
>> > I was confused before reading your response. Now I a profoundly
>> > confused :-/
>> >
>> > In your example, I think that the header stack looks like this:
>> >
>> > A) payload
>> >         3) data
>> >         2) TCP header (8 bytes)
>> >         1) IPv6 header (40 bytes)
>> > B) Geneve
>> >         3) Geneve header (260 bytes)
>> >         2) UDP Header (8 bytes)
>> >         1) IPv6 Header (40 bytes)
>> >
>> >
>> > It doesn't contain any IPv6 extension headers at all. A transit router=
, acting
>> as a middlebox, needs to see the TCP header, but can't because the TCP
>> header is 340 bytes into the packet. So, we send an ICMPv6 Parameter
>> Problem.
>> >
>> > Do I have that much right?
>> >
>> Yes, that is correct. Looking at the definition of Parameter Problem in
>> RFC1122 it seems the use here is okay even though the problem might not
>> specifically be about  IP layer.
>>
>> Tom
>>
>> >
>> > Ron
>> >
>> >
>> >> -----Original Message-----
>> >> From: Tom Herbert [mailto:tom@herbertland.com]
>> >> Sent: Monday, May 15, 2017 5:28 PM
>> >> To: Ron Bonica 
>> >> Cc: 6man@ietf.org
>> >> Subject: Re: New Version Notification for
>> >> draft-herbert-6man-icmp-limits- 01.txt
>> >>
>> >> On Mon, May 15, 2017 at 10:53 AM, Ron Bonica 
>> >> wrote:
>> >> > Tom,
>> >> >
>> >> > I may be parsing your response incorrectly.. Can you provide an
>> >> > example
>> >> where encapsulations elicit a Headers Too Long error code?
>> >>
>> >> It would be the case because of encapsulation a device is unable to
>> >> parse the headers it wants (typically would be down to transport
>> >> headers). For instance in Geneve, the maximum header length is 260
>> >> bytes. Adding UDP outer header and using it for IPv6/IPv6
>> >> encapsulation gets the headers before the inner transport header up
>> >> to
>> >> 348 bytes. That in itself may exceed a parsing buffer. A few more
>> >> extension headers, SFC, or nested encapsulation could push the
>> >> headers over 512 bytes that would probably exceed the parsing buffer
>> sizes of many devices.
>> >> So The Headers Too Long could be sent in this case.
>> >> Implementing a fallback might be hard since there may be multiple
>> >> sources of the headers, but at least this might give some visibility
>> >> to packet drops happening.
>> >>
>> >> Tom
>> >>
>> >> >
>> >> >
>> >> > Ron
>> >> >
>> >> >>
>> >> >> > 2) Same comment for Sections 3.3 and 3.4
>> >> >> > 3) I'm not sure that I get the difference between Extension
>> >> >> > Header Chain
>> >> >> Too Long (Section 3.3) and Headers Too Long (Section 3.5). Are you
>> >> >> saying that there is a case where 3.5 will be true and 3.3 will be=
 false?
>> >> >>
>> >> >> Headers too long could be caused by and reference encapsulation
>> >> >> headers as the culprit, it's not specific to extension headers.
>> >> >>
>> >> >


From nobody Fri May 19 07:51:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BB8128B93 for ; Fri, 19 May 2017 07:51:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.104
X-Spam-Level: 
X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 xUbBN-r9d5e3 for ; Fri, 19 May 2017 07:51:08 -0700 (PDT)
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 1D130128959 for ; Fri, 19 May 2017 07:51:04 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net;  b=V572vT7Fd7xWzLMU647ZaFPDfZbJpaJboq2BL/5UDD2zfVMd8ATUzZJwqO4g4ISzdtQVrudRiS4+qeUsFv1FFtINl2H/9vLSUZkhJiCO1TUJtcjhEyMEDvDFJphsnbKEp87w64ldgheWQrX2CtVLKf9YO7IqmUbLP1iUA5SaMUQ=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 10121 invoked from network); 19 May 2017 16:51:03 +0200
Received: from unknown (HELO ?172.20.31.112?) (66.171.169.35) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 May 2017 16:51:02 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: DISCUSS's on rfc1981bis - MK Comments
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: <5911B0EE.6080802@erg.abdn.ac.uk>
Date: Fri, 19 May 2017 10:51:01 -0400
Cc: ipv6@ietfa.amsl.com
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <5911B0EE.6080802@erg.abdn.ac.uk>
To: gorry@erg.abdn.ac.uk
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20170519145103.10116.20599@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 14:51:09 -0000

Hi Gorry, hi all,

thanks for the work and the update. All comments from Gorry seemed fine =
to me and I will try to review the changes in the updated doc soon. One =
more minor comment on this:

> Am 09.05.2017 um 08:07 schrieb Gorry Fairhurst :
>=20
>> I don't understand the following paragraph. Can this be removed?
>> "Note: A packetization layer must not retransmit in response to
>> every Packet Too Big message, since a burst of several oversized
>> segments will give rise to several such messages and hence several
>> retransmissions of the same data. If the new estimated PMTU is
>> still wrong, the process repeats, and there is an exponential
>> growth in the number of superfluous segments sent."
>>=20
> GF: I think the example is important. I'm not sure why that would be =
removed.

The problem is I don=E2=80=99t understand this example. Is there an =
assumption that all mtu probe packets have been =E2=80=9Agenerated=E2=80=98=
 on the same packet? If so that makes sense but must the spelled out =
somewhere!

Mirja




From nobody Fri May 19 09:06:43 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EEC129484; Fri, 19 May 2017 09:06:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari 
To: "The IESG" 
Cc: draft-ietf-6man-rfc1981bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org
Subject: Warren Kumari's No Objection on draft-ietf-6man-rfc1981bis-07: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149520999434.21403.1006161491568025364.idtracker@ietfa.amsl.com>
Date: Fri, 19 May 2017 09:06:34 -0700
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 16:06:34 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-6man-rfc1981bis-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I sent email about this to the authors on Feb 23rd - I seem to still have
have many of the same questions...

Comments:
1: Sec 1: "Path MTU Discovery relies on such messages to determine the
MTU of the path."
 -- it is unclear which "such" refers to. Perhaps s/such/ICMPv6/ (or
PTB).

2: Sec 3: "Upon receipt of such a message, the
   source node reduces its assumed PMTU for the path based on the MTU
of
   the constricting hop as reported in the Packet Too Big message" --
this says that it reduces it *for the path*. But (as somewhat alluded to
later in the draft) the nodes doesn't know what the path *is* -- it can
decrease for the destination, or flow, or even interface, but (unless it
is strict source routing) it doesn't control or really know the path (see
also #4)

3: Sec 4: "The recommended setting for this timer is twice its minimum
value (10 minutes)." - as above. This was from 1996 - were these metrics
discussed at all during the -bis? I suspect that the average flow is much
shorter these days (more web traffic, fatter pipes, etc) and so a flow of
10 minutes seems really long (to me at least). 

4: Sec 5.2: "The packetization layers must be notified about decreases in
the
   PMTU.  Any packetization layer instance (for example, a TCP
   connection) that is actively using the path must be notified if the
   PMTU estimate is decreased.
      Note: even if the Packet Too Big message contains an Original
      Packet Header that refers to a UDP packet, the TCP layer must be
      notified if any of its connections use the given path."
 - this is related to #2 -- I don't know *which* path my packets take -
once I launch them into the void, they may be routed purely based upon
destination IP address, or they may be hashed based upon some set of
header fields to a particular ECMP link or LSP. Once packets hit a load
balancer, it is probably even *likely* that the UDP and TCP packets end
up on different things. So, if I get a PTB from a router somewhere, I can
probably guess that other packets to the same destination address will
also follow that path, but I cannot know that for sure. I'm fine to
decrease MTU towards that destination IP, but is that what this is
suggesting? If so, please say that. If not, please let me know what I
should do. The above is even more tricky / fun when I'm using flow id as
the flow identifier -- if I get a PTB for flow 0x1234, what do I do? 

 5: Sec 5.3: "Once a minute, a timer-driven procedure runs through all
cached PMTU values, and for each PMTU whose timestamp is not "reserved"
and is older than the timeout interval ...". Please consider providing
clarifications here. The wording implies that I should set a timer to
fire on the minute, and trigger the behavior. If all of the (NTP synced!)
machines in my datacenter do this, and all try send bigger packets (on
1/10th of long flows) their first hop router will get many, many
over-sized packets and it will severely rate-limit the PTBs. 


Nits (Some of these are purely academic.)
I understand that you are trying to limit the changes, so feel free to
ignore these:

1: "A node sending packets much smaller than the Path
MTU allows is wasting network resources and probably getting
suboptimal throughput." - the "much" confuses me. If I'm using anything
less than the MTU I'm wasting network resources and getting suboptimal
throughput - I might not care, but if (used MTU) < (path MTU) I'm wasting
resources.

2: "Nodes implementing Path MTU Discovery and sending packets larger
than
the IPv6 minimum link MTU are susceptible to problematic connectivity
if ICMPv6 [ICMPv6] messages are blocked or not transmitted." The
"implementing Path MTU Discovery and" seems redundant. ALL nodes sending
packets larger than minimum MTU are "susceptible to problematic
connectivity if ICMPv6 [ICMPv6] messages are blocked or not
transmitted.". I get what you are trying to say, but my OCD tendencies
would not allow me to ignore this... 

3: "In the case of multipath routing (e.g., Equal Cost Multipath Routing,
ECMP),"- this is vague / confusing -- (Equal Cost Multipath Routing,
ECMP) makes it sound like either ECMP is an acronym for Equal Cost
Multipath Routing, or that ECMP is something different to Equal Cost
Multipath Routing.
I'd suggest just dropping the "ECMP" (or, "Equal Cost Multipath (ECMP)
routing", but that seems clumsy)



From nobody Fri May 19 12:35:42 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9BA126E01; Fri, 19 May 2017 12:35:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind?= 
To: "The IESG" 
Cc: draft-ietf-6man-rfc2460bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org
Subject: =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ietf-6man?= =?utf-8?q?-rfc2460bis-12=3A_=28with_COMMENT=29?=
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149522254096.8554.4535661660075180410.idtracker@ietfa.amsl.com>
Date: Fri, 19 May 2017 12:35:40 -0700
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 19:35:41 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-6man-rfc2460bis-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my discuss. Please put a reference to RFC6465 in
there to make sure that these RFCs do run out of sync.



From nobody Fri May 19 12:47:23 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70528129AC1; Fri, 19 May 2017 12:47:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: ipv6@ietf.org
Subject: I-D Action: draft-ietf-6man-rfc2460bis-13.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149522324140.21589.1565659173961962992@ietfa.amsl.com>
Date: Fri, 19 May 2017 12:47:21 -0700
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 19:47:21 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance of the IETF.

        Title           : Internet Protocol, Version 6 (IPv6) Specification
        Authors         : Stephen E. Deering <>
                          Robert M. Hinden
	Filename        : draft-ietf-6man-rfc2460bis-13.txt
	Pages           : 45
	Date            : 2017-05-19

Abstract:
   This document specifies version 6 of the Internet Protocol (IPv6).
   It obsoletes RFC2460


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-13
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri May 19 12:52:48 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8C912951C for ; Fri, 19 May 2017 12:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VK4W_NsJSPmO for ; Fri, 19 May 2017 12:52:45 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 6FFE5120046 for ; Fri, 19 May 2017 12:52:45 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id a72so69474773qkj.2 for ; Fri, 19 May 2017 12:52:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:cc:to; bh=9yioSy0YhH/hRVSUvaG5oHzQ1oA8ISHczPB9OpOKi1w=; b=jtll1GmQajn7lRtQeVqqy7YzZkaRVGAXjPsNVAG010XTk9JycDmwLLg+XB22RDFNDZ C7wxtk9GYNHJQbygfsHwx+jK7sZdQ0GrfixvfkCCuHE8oOBR2eGfzVbABAbbA0fbYutd G82NuWokz6iIhIheHI3UF1bS+yCWq906HklS1fvs0GT71/HHtx9CGe77Cb7c0pWcd39j 1HkUQspcFVar/LSPlyClS64y8WlbQJ6eGmLzA7cERXBjgio/hKCJvVg7lJdXFHHnxo4k 6PpB8vwIJKgZgRUPhnWFokrEysAc3oM/Zv8M9FuHs6I1vN+Wt1qa/i+lgtyfNuEXy6fX Lgwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=9yioSy0YhH/hRVSUvaG5oHzQ1oA8ISHczPB9OpOKi1w=; b=dv3nXwSneh6kbayGFxk03RqCAXcBgpzEn50DEPMai0EAws/SV5BNYCLd2DhhYfNQxe VJd/0fiFwD+D6zmZ9uXMpVoype4C63/WoXYQhzB1W4F0MJ7JAfwj1yjxCbkQQrSXei2t 0NwAmoSwsGuHQq6bO13RdUH7mkvKDGdobImToQCLjDba5qjIrAB+HI7mlDktyv0Ko1sV 5EqCv0Zj90NG62EuQaNkF+gjr4HByPZErzqNukrvcCkAeNF2+LemhV5QvBoLuAYnMel4 bKDiUQLojfmeCVdEAcBCxbvO+VtMY/R8O1x6psIs+8KdpUlcmMBs7p3d27jAF2M8VcVo cIOQ==
X-Gm-Message-State: AODbwcDSUKiPbLD4ERDpWEC9wino3LjdbZ0nM0KqW58h5aZQjSThocLf MhaxTmRlMV7HWmivsWs=
X-Received: by 10.55.197.148 with SMTP id k20mr10126339qkl.38.1495223564439; Fri, 19 May 2017 12:52:44 -0700 (PDT)
Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id l47sm6645674qtb.14.2017.05.19.12.52.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 May 2017 12:52:43 -0700 (PDT)
From: Bob Hinden 
Content-Type: multipart/signed; boundary="Apple-Mail=_4B0169B3-0840-4C93-997A-8066A5192A31"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: 
Message-Id: <4B1AF7A4-65D0-42AB-8E09-69C7A94A771D@gmail.com>
Date: Fri, 19 May 2017 12:52:37 -0700
Cc: Bob Hinden 
To: IPv6 List 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 19:52:47 -0000

--Apple-Mail=_4B0169B3-0840-4C93-997A-8066A5192A31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

I published the -13 version of 6man working group draft of rfc2460bis.  =
Links below.

The changes in this draft were:

      Added link to reference to RFC6564 in Section 4.8.

      Added text to Section 5 to define "IPv6 minimum link MTU".

      Editorial changes.

A diff from the -12 version can be found at:

https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-13

Please review the changes.

This is part of the project to move the core IPv6 specifications to =
Internet Standard.

Thanks,
Bob

> A new version of I-D, draft-ietf-6man-rfc2460bis-13.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
>=20
> Name:		draft-ietf-6man-rfc2460bis
> Revision:	13
> Title:		Internet Protocol, Version 6 (IPv6) =
Specification
> Document date:	2017-05-19
> Group:		6man
> Pages:		45
> URL:            =
https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc2460bis-13.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/
> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-13
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-13
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-13
>=20
> Abstract:
>   This document specifies version 6 of the Internet Protocol (IPv6).
>   It obsoletes RFC2460
>=20

--Apple-Mail=_4B0169B3-0840-4C93-997A-8066A5192A31
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

iQEcBAEBCgAGBQJZH00GAAoJEK7rdBF357uoFuUH/Rilg4eUaDc68VGwcPSoJY9b
UL/rTvrVrF9Fv3XYC5NwwzdTo1Rf9ExyUcaqvMaM4NTQAC8weeHeACqG4fvXe9kp
6UXWegTi0rsvD/QMmlgOqYtt+hmo15X1h/NoD+8LliSxgst+mlr41x3xSff2oK/u
kL9bGXofJnChhl/nNHl4sw2UCz2+W7k5R7PYHx93wI99galFYcin+v/KyrXqJ+xX
hK1Ovi10pqXaifruA8meuRcdiGJ3WMdIuTEV9OPqKZ9uWrjjPZiJxYzxLusvVOvw
5wYdCZLF/Pm3NvyXX+plAV+MAEdVjTgPFZMLkJGUdaKOwXPpe/E5cY9TLG/CIMs=
=FYVL
-----END PGP SIGNATURE-----

--Apple-Mail=_4B0169B3-0840-4C93-997A-8066A5192A31--


From nobody Fri May 19 20:50:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4382B129451 for ; Fri, 19 May 2017 20:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.801
X-Spam-Level: 
X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 XvyJqkjvAnCl for ; Fri, 19 May 2017 20:50:05 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A917B1293F4 for ; Fri, 19 May 2017 20:50:05 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id b68so42236631ywe.3 for ; Fri, 19 May 2017 20:50:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=wXp7830XuAyYYfANtZBQ9/7HAmP+WjU5td/GRmeixPo=; b=u8tsPhXZ482yvXxIHNGwSIqVESUGQg5Js3R+VKf1ccollajd8J7dn2jSYu1flpVUlh 18uHo6jVvwo52aWzAKuLfrWlLEKJkU6mZEwEh5sh7pIoH03Y92MwVwzE+sgGy59rdbF/ Kq4ExHl1FQSlB08X+wRH+og4Iu+4cn7mxfos+N/WVcvNex98t07kWvB2oEnfmfTYnyS+ MBqoB/WYDE2mflV9HCN+Wg7Y+zuFhRDzbkCS7LTwCeuM9L8PyU3mi/+qf0eIF1L6k9ZS LfXxDbiWitlVt7u9mWgCXX7sCCOzjaNKEzEZfpsXCe4Fh6B2FTHDvDduHT8hM2j2/3t6 259Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=wXp7830XuAyYYfANtZBQ9/7HAmP+WjU5td/GRmeixPo=; b=A8KhbrmpCnRUZyI8WqEL4gKfb7ndLmy8+YsTx4UkoHCQRMMowOrxIAZWp5dlmNGBTm Jmj6H9lzUZGF+ExME8vzhZl3GifTzuTSCSAPybYXDt+s403hLYUpIqUiR7eskJlLB+d8 Wek1+kOqAhZoxBpz4aTpr7FdnIi93Thv8FzndR807dN2NWm00YTCEMBk+KhPI1bli7lK GWrKrD7iKHLgdhOF54Ub2NhFXPDlWnRZuxh20E7nnoNgx8P4VNHaZHjXE/FngpvTjD8/ locnfflNJzjqbo+GfafSBGYiOGPL7yXPUasJ8VsWNohf2mHlu2NPSzlZ/NaHvGmlTiav wuSQ==
X-Gm-Message-State: AODbwcCjQcX9vHpqMWlYaTlVLnywVXSizKjrHqsprVGE78Xt9AzxnvLd R3vAHBsNAedkAg==
X-Received: by 10.129.84.67 with SMTP id i64mr10932508ywb.293.1495252204934; Fri, 19 May 2017 20:50:04 -0700 (PDT)
Received: from [10.0.0.2] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id q65sm4550938ywg.5.2017.05.19.20.50.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 May 2017 20:50:04 -0700 (PDT)
From: Suresh Krishnan 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Future of header insertion work in 6man
Message-Id: <0819567D-4F46-4320-9F7D-53BF01A86ABF@gmail.com>
Date: Fri, 19 May 2017 23:50:02 -0400
Cc: Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= 
To: IPv6 List 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 03:50:07 -0000

Hi all,
  Now that 2460bis has been approved for publication, I would like to =
take this chance to emphasize something that has been said in multiple =
mails before by different WG participants, but it is worth mentioning in =
a separate mail. I have heard from several persons being concerned about =
the possibility of new text in 2460bis being blindly used to block =
header insertion work in the future. I just want to confirm that header =
insertion work can be considered in the future, and that it should be =
judged on its own merits and not be blocked solely based on the header =
insertion related text in 2460bis.

Thanks
Suresh


From nobody Sat May 20 04:31:44 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 118F0129408; Sat, 20 May 2017 04:31:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benoit Claise 
To: "The IESG" 
Cc: draft-ietf-6man-rfc1981bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org
Subject: Benoit Claise's No Objection on draft-ietf-6man-rfc1981bis-07: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149527989499.30807.4417390399225260349.idtracker@ietfa.amsl.com>
Date: Sat, 20 May 2017 04:31:34 -0700
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 11:31:35 -0000

Benoit Claise has entered the following ballot position for
draft-ietf-6man-rfc1981bis-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In this document, I see:

   IPv6 nodes SHOULD implement Path MTU Discovery in order to discover
   and take advantage of paths with PMTU greater than the IPv6 minimum
   link MTU [I-D.ietf-6man-rfc2460bis].  A minimal IPv6 implementation
   (e.g., in a boot ROM) may choose to omit implementation of Path MTU
   Discovery.

In draft-ietf-6man-rfc2460bis-09:
   It is strongly recommended that IPv6 nodes implement Path MTU
   Discovery [RFC1981], in order to discover and take advantage of path
   MTUs greater than 1280 octets.  However, a minimal IPv6
   implementation (e.g., in a boot ROM) may simply restrict itself to
   sending packets no larger than 1280 octets, and omit implementation
   of Path MTU Discovery.

So a SHOULD in one document versus "strongly recommended" in the other.

We should reconcile the two texts.
Note: may and may are consistent.


ICMPv6 PTB => ICMPv6 Packet to Big (PTB)



From nobody Sat May 20 08:11:45 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A83129B00 for ; Sat, 20 May 2017 08:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  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 q9DIS1Oax__S for ; Sat, 20 May 2017 08:11:40 -0700 (PDT)
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 0C1941275AB for ; Sat, 20 May 2017 08:11:39 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 79FBC1B016C8; Sat, 20 May 2017 18:06:15 +0100 (BST)
Message-ID: <59205C94.30200@erg.abdn.ac.uk>
Date: Sat, 20 May 2017 16:11:16 +0100
From: Gorry Fairhurst 
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Mirja Kuehlewind (IETF)" 
CC: ipv6@ietfa.amsl.com
Subject: Re: DISCUSS's on rfc1981bis - MK Comments
References:  <5911B0EE.6080802@erg.abdn.ac.uk> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 15:11:43 -0000

On 19/05/2017, 15:51, Mirja Kuehlewind (IETF) wrote:
> Hi Gorry, hi all,
>
> thanks for the work and the update. All comments from Gorry seemed fine to me and I will try to review the changes in the updated doc soon. One more minor comment on this:
>
>> Am 09.05.2017 um 08:07 schrieb Gorry Fairhurst:
>>
>>> I don't understand the following paragraph. Can this be removed?
>>> "Note: A packetization layer must not retransmit in response to
>>> every Packet Too Big message, since a burst of several oversized
>>> segments will give rise to several such messages and hence several
>>> retransmissions of the same data. If the new estimated PMTU is
>>> still wrong, the process repeats, and there is an exponential
>>> growth in the number of superfluous segments sent."
>>>
>> GF: I think the example is important. I'm not sure why that would be removed.
> The problem is I don’t understand this example. Is there an assumption that all mtu probe packets have been ‚generated‘ on the same packet? If so that makes sense but must the spelled out somewhere!
>
> Mirja
>
>
I think the wording is maybe jumbled, but the point is OK. Perhaps 
something like this would be clearer?

"Note: A packetization layer ought to avoid retransmitting the data in a probe packet
using the size reported in the last Packet Too Big message.
This is to avoid an exponential growth in the number of superfluous segments
that would be sent when a path encounters several successive smaller PMTU limits.
(Each new estimated PMTU would result in retransmission of the data in a smaller
packet that may itself fail if it encounters a still smaller PMTU in a device further
along the same path)."

Gorry



From nobody Sat May 20 08:49:04 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520401293F2 for ; Sat, 20 May 2017 08:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=juniper.net
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 b3VRQJTnTteJ for ; Sat, 20 May 2017 08:49:01 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0132.outbound.protection.outlook.com [104.47.42.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32EF1293E4 for <6man@ietf.org>; Sat, 20 May 2017 08:49:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SLfMh4X9Xt0eBm5viPTRpQVNjPfiV7kzfX2KZx/rjYM=; b=ZHcGmgDVuSdvDyRTR2/gelLR8/S57mL6wx5uho0kmDiLigJ6Z7Jf/tmkaDOvz+kv48gVdswkQCtSkfyco2n5TL8nqjemoEPrMzzbA5JrqGTatwbg7fAnC17ImNeLr/wQySaGLuWRLVEp3Q64ijeCbmja+r3pE58i9Dmnbls9c0E=
Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Sat, 20 May 2017 15:49:00 +0000
Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1124.007; Sat, 20 May 2017 15:49:00 +0000
From: Ron Bonica 
To: Tom Herbert 
CC: "6man@ietf.org" <6man@ietf.org>
Subject: RE: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
Thread-Topic: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
Thread-Index: AQHSydvj2CNgsdR2N0SNyPfQvMZ6VaH1duKggAAhBwCAABvukIAAPKEAgAFC5PCAAEjSAIAB0s1wgAFOJoCAAs09sA==
Date: Sat, 20 May 2017 15:49:00 +0000
Message-ID: 
References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com>         
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: herbertland.com; dkim=none (message not signed) header.d=none;herbertland.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2051; 7:MBKJg4ECUI6nQFEj9GcMl6DGPyguSKawUrPkytbXzylrBJlA/a3iiMX+PD7o6p6HxIzdnn/KUAV7z/7k5WWL6ZR46onWKQJqc3SFW/bnRPT4Md8o/2DtWFHky7x0Ozjhf3hqiAJd66+XeFK+5eE2oydzpnimEseYrPcwjBSCCdeQBtACpdEgBYAbfU0DbRGx/8eJDSzEU3fD+ytjJjEf30+JdRQlp37+V/Z80AvjQ70qTuFTQjRH+ERmRfGd5ZPLadJjIPFhtOjcq8DxHmshCZ6rNSRJNi7RBUym9zAB8cdoT4PO7TOQig/X0pLwyL8Ld1Doa8CzcOobQ2VWokwZJw==
x-ms-traffictypediagnostic: BLUPR0501MB2051:
x-ms-office365-filtering-correlation-id: afd1f142-825a-4e8b-ff91-08d49f97bb8f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR0501MB2051; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:BLUPR0501MB2051; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2051; 
x-forefront-prvs: 03137AC81E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39850400002)(39410400002)(39840400002)(39450400003)(39860400002)(24454002)(13464003)(377454003)(93886004)(230783001)(8676002)(50986999)(54356999)(81166006)(76176999)(33656002)(8936002)(66066001)(3846002)(6116002)(102836003)(7696004)(2950100002)(6916009)(2900100001)(229853002)(5660300001)(122556002)(7736002)(15650500001)(189998001)(110136004)(38730400002)(6246003)(3280700002)(86362001)(3660700001)(2906002)(6436002)(305945005)(77096006)(74316002)(25786009)(53546009)(4326008)(9686003)(6506006)(53936002)(55016002)(478600001)(99286003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2051; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2017 15:49:00.0330 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2051
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 15:49:03 -0000

SGkgVG9tLA0KDQpEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSBpc24ndCBhcHByb3ByaWF0ZSBiZWNh
dXNlIHRoZSBkZXN0aW5hdGlvbiAqaXMqIHJlYWNoYWJsZS4gVGhlIHByb2JsZW0gaXMgdGhhdCB0
aGUgaGVhZGVyIGlzIHRvbyBsb25nLg0KDQpJdCBzZWVtcyBsaWtlIHdlIGFyZSBpZGVudGlmeWlu
ZyBhbiBuZXcgY29uc3RyYWludCwgdGhlIFBhdGggTWF4aW11bSBIZWFkZXIgTGVuZ3RoIChQTUhM
KS4gSW4gc29tZSByZXNwZWN0cywgUE1ITCBpcyBzaW1pbGFyIHRvIFBNVFUuIFdoZW4gUE1UVSBp
cyB2aW9sYXRlZCwgd2Ugc2VuZCBhbiBJQ01QIFBUQiB0byB0aGUgc291cmNlIElQIHN0YWNrLiBU
aGUgc291cmNlIElQIG1vZGlmaWVzIGl0cyBlc3RpbWF0ZSBvZiB0aGUgUE1UVSwgaW5mb3JtcyB1
cHBlciBsYXllcnMgKGlmIGFwcHJvcHJpYXRlKSBhbmQgZnJhZ21lbnRzIHN1YnNlcXVlbnQgcGFj
a2V0cyAoaWYgYXBwcm9wcmlhdGUpLg0KDQpXaGF0IHNob3VsZCBoYXBwZW4gd2hlbiBQTUhMIGlz
IHZpb2xhdGVkPyBEb2VzIHRoZSBzb3VyY2UgSVAgc3RhY2sgbmVlZCB0byBiZSBpbmZvcm1lZD8g
SWYgc28sIHdoYXQgd2lsbCB0aGUgc291cmNlIElQIHN0YWNrIGRvIHdpdGggdGhlIGluZm9ybWF0
aW9uPyBPciBpcyByZWFsbHkgYW4gdXBwZXIgbGF5ZXIgYXBwbGljYXRpb24gdGhhdCBuZWVkcyB0
byBiZSBpbmZvcm1lZD8NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0KDQoN
Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVG9tIEhlcmJlcnQgW21haWx0
bzp0b21AaGVyYmVydGxhbmQuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDE4LCAyMDE3IDQ6
NTEgUE0NCj4gVG86IFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+DQo+IENjOiA2bWFu
QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy
YWZ0LWhlcmJlcnQtNm1hbi1pY21wLWxpbWl0cy0NCj4gMDEudHh0DQo+IA0KPiBPbiBXZWQsIE1h
eSAxNywgMjAxNyBhdCA2OjAzIFBNLCBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0PiB3
cm90ZToNCj4gPiBUb20sDQo+ID4NCj4gPiBUaGUgSUNNUCBQYXJhbWV0ZXIgUHJvYmxlbSBtZXNz
YWdlIG5vcm1hbGx5IGluZGljYXRlcyB0aGF0IHRoZXJlIGlzIGENCj4gcHJvYmxlbSB3aXRoIGFu
IElQIFBhcmFtZXRlci4gSW4gdGhlIGV4YW1wbGUgYmVsb3csIHlvdSB1c2UgaXQgdG8gaW5kaWNh
dGUNCj4gdGhhdCBhIG1pZGRsZSBib3ggaGFzIGEgcHJvYmxlbSB3aXRoIHRoZSBJUCBwYXlsb2Fk
LiBUaGlzIHNlZW1zIHRvIGJlDQo+IG92ZXJsb2FkaW5nIHRoZSBQYXJhbWV0ZXIgUHJvYmxlbSBt
ZXNzYWdlLg0KPiA+DQo+IEhpIFJvbiwNCj4gDQo+IFdvdWxkIERlc3RpbmF0aW9uIFVucmVhY2hh
YmxlIG1lc3NhZ2UgYmUgYXBwcm9wcmlhdGUgdGhlbj8NCj4gDQo+IFRvbQ0KPiANCj4gPg0KPiA+
IFJvbg0KPiA+DQo+ID4NCg0K


From nobody Sat May 20 21:29:39 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C74127601 for ; Sat, 20 May 2017 21:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level: 
X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 kwi6oXEBWeQR for ; Sat, 20 May 2017 21:29:36 -0700 (PDT)
Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93315124D6C for <6man@ietf.org>; Sat, 20 May 2017 21:29:36 -0700 (PDT)
Received: by mail-ua0-x22d.google.com with SMTP id e28so43972179uah.0 for <6man@ietf.org>; Sat, 20 May 2017 21:29:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JMlpHpd6yxj8tC9L+AHvJkdOfoAywjK5TMVXJGyiTrA=; b=Royx2/tcUu0OPhA1j1PYtc0qQk3317M4wxIgXeZ24lhWrYK9RPw8W1KNzI29oZI2UV Bu/4sXL7keMIKqlgW5dabgyxkuKNz7gksfpZJ7UrBxKy9Ih9JdoRwhMApdaqXTFZ6BfU 6k7yi8+qtNrEfn5Oc+mNYhZGV/L501bSvGc1+Gf3bm6HbGN8rlg5/WsMxV/DHAjAc46B dtV1MOdL9Q5TSymvGXk+nPzeFFNJxLiw24BW4fC2kxMP12suiI4Q8WO+u98RpbMAIiA/ LMGKQnmxg7gKX9yrE9RVek6/bM3D7rH2+n9M0f4n/sFaghkUuWY4XpMSt+h83SSOPu7C If7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JMlpHpd6yxj8tC9L+AHvJkdOfoAywjK5TMVXJGyiTrA=; b=KBwRXeJ/pFT5OntnOarBucCkonUYUlkQ09YZ+AUL/PTIN0+onENNmgTo1bcXRegXgT zrORbD30mH0HcxDno51vRTbEy/WQqalsHjMucWgq8/NhLbzTQJnCHEihwI9dHrrQFxhB 6qRv9LOcQXbyXKNqi3qPdgfDpvr9y6C5zt11XsKZdmsag35fj/g94R7t/EETEOQHDYGE Hs86vYx0tueB/BpVeFXzsR41puUJEJIX8liRnpuN7RVjgFSD/tluqdTP3FmwVUAqNB5a 15BtKHvtMnvXrZe8Nq5al+ckGGfm0EM/KtdOl3Ty9Vw/E+rr0wtoZ5R0ob8vzpN+TNXd 7hlw==
X-Gm-Message-State: AODbwcCOgqhPzk2nn2CSfwDLz8EJmDWNbrSp1VsWVTI7OMhGl9wvdIWq LmYSCVyWdmhUPPU8yu7Ivx/iSIC9W7Yo
X-Received: by 10.176.17.94 with SMTP id g30mr8696056uac.125.1495340975658; Sat, 20 May 2017 21:29:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.38.51 with HTTP; Sat, 20 May 2017 21:29:05 -0700 (PDT)
In-Reply-To: 
References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com>          
From: Mark Smith 
Date: Sun, 21 May 2017 14:29:05 +1000
Message-ID: 
Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
To: Ron Bonica 
Cc: Tom Herbert , "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 May 2017 04:29:38 -0000

On 21 May 2017 at 01:49, Ron Bonica  wrote:
> Hi Tom,
>
> Destination Unreachable isn't appropriate because the destination *is* re=
achable. The problem is that the header is too long.

It seems a DU is appropriate, going by what RFC4443 says, because the
cause of the failure isn't congestion:


"A Destination Unreachable message SHOULD be generated by a router, or
   by the IPv6 layer in the originating node, in response to a packet
   that cannot be delivered to its destination address for reasons other
   than congestion.  (An ICMPv6 message MUST NOT be generated if a
   packet is dropped due to congestion.)"


(I looked it up because this discussion made me curious if a DA -
Admin prohibited was making a positive confirmation of the
destination's existence, and the prohibition was on being able to
reach it. It seems not, which is better for security.)

Regards,
Mark.



>
> It seems like we are identifying an new constraint, the Path Maximum Head=
er Length (PMHL). In some respects, PMHL is similar to PMTU. When PMTU is v=
iolated, we send an ICMP PTB to the source IP stack. The source IP modifies=
 its estimate of the PMTU, informs upper layers (if appropriate) and fragme=
nts subsequent packets (if appropriate).
>
> What should happen when PMHL is violated? Does the source IP stack need t=
o be informed? If so, what will the source IP stack do with the information=
? Or is really an upper layer application that needs to be informed?
>
>                                                                          =
           Ron
>
>
>
>
>> -----Original Message-----
>> From: Tom Herbert [mailto:tom@herbertland.com]
>> Sent: Thursday, May 18, 2017 4:51 PM
>> To: Ron Bonica 
>> Cc: 6man@ietf.org
>> Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits=
-
>> 01.txt
>>
>> On Wed, May 17, 2017 at 6:03 PM, Ron Bonica  wrote:
>> > Tom,
>> >
>> > The ICMP Parameter Problem message normally indicates that there is a
>> problem with an IP Parameter. In the example below, you use it to indica=
te
>> that a middle box has a problem with the IP payload. This seems to be
>> overloading the Parameter Problem message.
>> >
>> Hi Ron,
>>
>> Would Destination Unreachable message be appropriate then?
>>
>> Tom
>>
>> >
>> > Ron
>> >
>> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Mon May 22 02:49:43 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AFB127735 for ; Mon, 22 May 2017 02:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.698
X-Spam-Level: 
X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 AFOKVn18uLMH for ; Mon, 22 May 2017 02:49:40 -0700 (PDT)
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 C8356128D44 for ; Mon, 22 May 2017 02:49:39 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net;  b=j2eb8wez+0E+FepvIfqYQiM20CSlAyFYnUB26Zzv9+rcVkWJjFCh9tDo6o/6U8s8btEGNHTkrLCJoCzI0Ed2DNmH0JVstc0QFxlANvocWPkZdWysX4gndwmU40mvi5RRRsviYO3l/0q4Y7r6Yza76ePqhkygQMdLkl1tOtlHgDk=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 27848 invoked from network); 22 May 2017 11:49:37 +0200
Received: from pd9e110d0.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.16.208) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 May 2017 11:49:37 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: DISCUSS's on rfc1981bis - MK Comments
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: <59205C94.30200@erg.abdn.ac.uk>
Date: Mon, 22 May 2017 11:49:36 +0200
Cc: ipv6@ietfa.amsl.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <52A24ADC-8D1D-47DA-ADC8-21D30C09D49E@kuehlewind.net>
References:  <5911B0EE.6080802@erg.abdn.ac.uk>  <59205C94.30200@erg.abdn.ac.uk>
To: gorry@erg.abdn.ac.uk
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20170522094937.27843.60152@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 09:49:42 -0000

See below.


> Am 20.05.2017 um 17:11 schrieb Gorry Fairhurst :
>=20
> On 19/05/2017, 15:51, Mirja Kuehlewind (IETF) wrote:
>> Hi Gorry, hi all,
>>=20
>> thanks for the work and the update. All comments from Gorry seemed =
fine to me and I will try to review the changes in the updated doc soon. =
One more minor comment on this:
>>=20
>>> Am 09.05.2017 um 08:07 schrieb Gorry =
Fairhurst:
>>>=20
>>>> I don't understand the following paragraph. Can this be removed?
>>>> "Note: A packetization layer must not retransmit in response to
>>>> every Packet Too Big message, since a burst of several oversized
>>>> segments will give rise to several such messages and hence several
>>>> retransmissions of the same data. If the new estimated PMTU is
>>>> still wrong, the process repeats, and there is an exponential
>>>> growth in the number of superfluous segments sent."
>>>>=20
>>> GF: I think the example is important. I'm not sure why that would be =
removed.
>> The problem is I don=E2=80=99t understand this example. Is there an =
assumption that all mtu probe packets have been =E2=80=9Agenerated=E2=80=98=
 on the same packet? If so that makes sense but must the spelled out =
somewhere!
>>=20
>> Mirja
>>=20
>>=20
> I think the wording is maybe jumbled, but the point is OK. Perhaps =
something like this would be clearer?
>=20
> "Note: A packetization layer ought to avoid retransmitting the data in =
a probe packet
> using the size reported in the last Packet Too Big message.
> This is to avoid an exponential growth in the number of superfluous =
segments
> that would be sent when a path encounters several successive smaller =
PMTU limits.
> (Each new estimated PMTU would result in retransmission of the data in =
a smaller
> packet that may itself fail if it encounters a still smaller PMTU in a =
device further
> along the same path)."
>=20
> Gorry
>=20
I still don=E2=80=99t get it. Each time a packet is dropped, you have to =
retransmit it (if your transport is reliable) because otherwise the =
other end will not have it. I also still don=E2=80=99t see how there can =
be an exponential grows. Sorry if I miss something but maybe you can =
explain again this case using different words=E2=80=A6?

Mirja





From nobody Mon May 22 04:17:46 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB44129C12 for ; Mon, 22 May 2017 04:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level: 
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, 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 2W2IT5W2XhVV for ; Mon, 22 May 2017 04:17:41 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 589EE129BF0 for ; Mon, 22 May 2017 04:17:41 -0700 (PDT)
Received: from dhcp-207-152.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:94d8:d84c:881d:e222]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id EFB831B01785; Mon, 22 May 2017 14:12:36 +0100 (BST)
Reply-To: gorry@erg.abdn.ac.uk
Subject: Re: DISCUSS's on rfc1981bis - MK Comments
References:  <5911B0EE.6080802@erg.abdn.ac.uk>  <59205C94.30200@erg.abdn.ac.uk> <52A24ADC-8D1D-47DA-ADC8-21D30C09D49E@kuehlewind.net>
To: "Mirja Kuehlewind (IETF)" 
Cc: ipv6@ietfa.amsl.com
From: Gorry Fairhurst 
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683.
Message-ID: <589a1f5a-8ce8-d484-9083-5eaedee3f5ff@erg.abdn.ac.uk>
Date: Mon, 22 May 2017 12:17:39 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <52A24ADC-8D1D-47DA-ADC8-21D30C09D49E@kuehlewind.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 11:17:44 -0000

On 22/05/2017 10:49, Mirja Kuehlewind (IETF) wrote:
> See below.
>
>
>> Am 20.05.2017 um 17:11 schrieb Gorry Fairhurst :
>>
>> On 19/05/2017, 15:51, Mirja Kuehlewind (IETF) wrote:
>>> Hi Gorry, hi all,
>>>
>>> thanks for the work and the update. All comments from Gorry seemed fine to me and I will try to review the changes in the updated doc soon. One more minor comment on this:
>>>
>>>> Am 09.05.2017 um 08:07 schrieb Gorry Fairhurst:
>>>>
>>>>> I don't understand the following paragraph. Can this be removed?
>>>>> "Note: A packetization layer must not retransmit in response to
>>>>> every Packet Too Big message, since a burst of several oversized
>>>>> segments will give rise to several such messages and hence several
>>>>> retransmissions of the same data. If the new estimated PMTU is
>>>>> still wrong, the process repeats, and there is an exponential
>>>>> growth in the number of superfluous segments sent."
>>>>>
>>>> GF: I think the example is important. I'm not sure why that would be removed.
>>> The problem is I don’t understand this example. Is there an assumption that all mtu probe packets have been ‚generated‘ on the same packet? If so that makes sense but must the spelled out somewhere!
>>>
>>> Mirja
>>>
>>>
>> I think the wording is maybe jumbled, but the point is OK. Perhaps something like this would be clearer?
>>
>> "Note: A packetization layer ought to avoid retransmitting the data in a probe packet
>> using the size reported in the last Packet Too Big message.
>> This is to avoid an exponential growth in the number of superfluous segments
>> that would be sent when a path encounters several successive smaller PMTU limits.
>> (Each new estimated PMTU would result in retransmission of the data in a smaller
>> packet that may itself fail if it encounters a still smaller PMTU in a device further
>> along the same path)."
>>
>> Gorry
>>
> I still don’t get it. Each time a packet is dropped, you have to
> retransmit it (if your transport is reliable)
> because otherwise the other end will not have it.
 >
Sure. this says nothing about how you find out what segments need to
be retransmit, only about the *SIZE* of the packets you use to perform 
that transmission.
>
 >
> I also still don’t see how there can be an exponential grows.
 >
 >
> Sorry if I miss something but maybe you can explain again this case using different words…?
>
> Mirja
>


Before I try different words, we should make sure the topic is understood.

Suppose we wish to send a probe for 8KB, and suppose the path supports
3 router MTU sizes: a hop with 4KB MTU and then a later hop with 2KB 
MTU, and finally one of just 1400B.

Largest probe size = 8KB

The first probe sends 8KB as the Segment Size
->------------------------------X
Dropped by first router along path.
In example case PTB indicates next hop =  4KB.
Data not reliably sent.

Largest probe size = 4KB

Retransmit 2 packet for same segment of data, each size 4KB
------------->------------------------------X
------------->------------------------------X
Dropped by router later along path.
In example case PTB indicates next hop =  2KB.
Data still not reliably sent.

Largest probe size = 2KB

Retransmit 4 packets for same segment of data.
In example case PTB indicates next hop =  1400B.
Data still not reliably sent.
------------->------------------------------>---X
------------->------------------------------>---X
------------->------------------------------>---X
------------->------------------------------>---X

Largest probe size = 1400B

Data finally transmitted in 6 packets all less than PMTU.
------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->

All data delivered. PMTU=1400B is confirmed.

Total sent packets = 13 packets
No of re-transmissions = 7 (6 failed re-transmissions in 3 
re-transmission attempts)

Now let's try a method that heeds the warning in the text and 
re-transmits the probe data using a "safe: MTU:

The first probe sends 8KB as the Segment Size
->------------------------------X

Dropped by first router along path.
In example case PTB indicates next hop =  4KB.
Data not reliably sent.

Largest probe size = 4KB

Sender resends the 8KB segment using a known workable PMTU (in the above 
1500B, if that were cached, or even 1280B.

------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->

Total sent packets = 7 packets
No of re-transmissions = 6 (all successful, 1 re-transmission)

And afterwards separately resend a single probe packet to detect a the 
largest PMTU using the 4KB probe.

Obviously, there are many combinations of paths, and not all cases lead
to exponential growth, but all cases lead to multiple probes, and
multiple re-transmissions.

Gorry


From nobody Mon May 22 07:10:02 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435AB12EAB0 for ; Mon, 22 May 2017 07:10:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=juniper.net
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 kiRHTUTJ7Nc2 for ; Mon, 22 May 2017 07:09:59 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0134.outbound.protection.outlook.com [104.47.42.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650EF12EAA9 for <6man@ietf.org>; Mon, 22 May 2017 07:09:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ta7Z+Qzjl1B2zBs6SU28NxNovCtdmI2qTwdBASz2oSI=; b=NGhoW16VHMO+UkX1+IBMgeCtKlALLfaQ70C0GJh898GVuO3eKZsrK2mwJfDOWNVtI8ANfTcUgW6znv8JQE9jpElHrBk2M4yKr7Jt8HxGkj/+CP4CxQC2diEbnfRamjpG3vpr5SMPlPhEHHYdYURkWK47Dc2IdyxQt7P3jS5cj5U=
Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2052.namprd05.prod.outlook.com (10.164.23.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Mon, 22 May 2017 14:09:56 +0000
Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1124.007; Mon, 22 May 2017 14:09:56 +0000
From: Ron Bonica 
To: Mark Smith 
CC: Tom Herbert , "6man@ietf.org" <6man@ietf.org>
Subject: RE: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
Thread-Topic: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
Thread-Index: AQHSydvj2CNgsdR2N0SNyPfQvMZ6VaH1duKggAAhBwCAABvukIAAPKEAgAFC5PCAAEjSAIAB0s1wgAFOJoCAAs09sIAA13mAgAIxMBA=
Date: Mon, 22 May 2017 14:09:56 +0000
Message-ID: 
References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com>           
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2052; 7:bdLbKyrnjBj27o+yQKBqGi6dCOhIdtX7JGvXOFk4LcKqMB1TeDhSqadx8ywaYlsTMt3qBfESCEeRR/+YsBmxM7a55d/aVdRBiBprFPGHfOiF1oGk5Vk/CBefvKEVcut6xFlOHFiI5FnEUYr5ejd+n5A/R6TpnRNnyhKCut6VNxEbqKOGKhn2gauHvMqvLcrfwtawk8Wm8e/dK1Lhm21H69ohwVO5BdxGuKWIc6iWOEmDfOaZaM2qrHnbl8S6IggV4F8e8TpOHbNQuLofx37JLFGR7XPyctUOzRYHpanucsLPhmKRH9N40bBzCBRNN8swSLVnga2HhrVBjX2+32Gqkw==
x-ms-traffictypediagnostic: BLUPR0501MB2052:
x-ms-office365-filtering-correlation-id: 11c8d807-9891-4083-41ea-08d4a11c39ad
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:BLUPR0501MB2052; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148); SRVR:BLUPR0501MB2052; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2052; 
x-forefront-prvs: 03152A99FF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39840400002)(39400400002)(39450400003)(39860400002)(199003)(377454003)(13464003)(24454002)(189002)(229853002)(2950100002)(50986999)(1411001)(76176999)(54356999)(7696004)(6916009)(53546009)(102836003)(189998001)(74316002)(7736002)(3660700001)(966005)(305945005)(5660300001)(122556002)(230783001)(33656002)(38730400002)(2900100001)(8936002)(8676002)(81166006)(6246003)(110136004)(15650500001)(93886004)(77096006)(86362001)(55016002)(4326008)(66066001)(25786009)(54906002)(9686003)(6306002)(53936002)(3846002)(3280700002)(39060400002)(6436002)(6506006)(99286003)(478600001)(6116002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2052; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2017 14:09:56.4113 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2052
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 14:10:01 -0000

TWFyaywNCg0KU3RyaWN0bHkgc3BlYWtpbmcsIERlc3RpbmF0aW9uIFVucmVhY2hhYmxlIGlzIGFw
cHJvcHJpYXRlIHdoZW5ldmVyIGEgcGFja2V0IGlzIGRpc2NhcmRlZCBmb3IgYW55IHJlYXNvbiBv
dGhlciB0aGFuIGNvbmdlc3Rpb24uIEJ1dCBhY2NvcmRpbmcgdG8gdGhhdCByZWFzb25pbmcsIHlv
dSBkb24ndCBuZWVkIGFuIElDTVAgUGFja2V0IFRvbyBCaWcgbWVzc2FnZS4gVGhlIFBUQiBlcnJv
ciBjb3VsZCBiZSByZXBvcnRlZCAgYnkgRGVzdGluYXRpb24gVW5yZWFjaGFibGUgbWVzc2FnZSB3
aXRoIGEgUFRCIGVycm9yIGNvZGUuDQoNCkluIHJlYWxpdHksIHdlIG5lZWQgdGhlIElDTVAgUFRC
IG1lc3NhZ2UgYmVjYXVzZSBvZiBpdHMgc3BlY2lhbCBzdGF0dXMuIFRoYXQgaXMsIHBlb3BsZSBr
bm93IHRoYXQgdGhleSBNVVNUIE5PVCBmaWx0ZXIgSUNNUCBQVEIncyBiZWNhdXNlIGZpbHRlcmlu
ZyBtYXkgY2F1c2UgYmxhY2staG9saW5nLiBJIGFtIHRoaW5raW5nIHRoYXQgSGVhZGVyIFRvbyBM
b25nIChIVEwpICBpcyBha2luIHRvIFBUQi4gSWYgSFRMIGluZm9ybWF0aW9uIGhpdGNoaGlrZXMg
b24gYW4gZXhpc3RpbmcgSUNNUCBtZXNzYWdlLCB0aGF0IG1lc3NhZ2Ugc2hvdWxkIHByb2JhYmx5
IGJlIFBUQi4NCg0KQnV0IHRoZW4gYWdhaW4sIGEgbmV3IElDTVAgbWVzc2FnZSBtYXkgYmUgcmVx
dWlyZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBSb24NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+IEZyb206IE1hcmsgU21pdGggW21haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tXQ0KPiBT
ZW50OiBTdW5kYXksIE1heSAyMSwgMjAxNyAxMjoyOSBBTQ0KPiBUbzogUm9uIEJvbmljYSA8cmJv
bmljYUBqdW5pcGVyLm5ldD4NCj4gQ2M6IFRvbSBIZXJiZXJ0IDx0b21AaGVyYmVydGxhbmQuY29t
PjsgNm1hbkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u
IGZvciBkcmFmdC1oZXJiZXJ0LTZtYW4taWNtcC1saW1pdHMtDQo+IDAxLnR4dA0KPiANCj4gT24g
MjEgTWF5IDIwMTcgYXQgMDE6NDksIFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+IHdy
b3RlOg0KPiA+IEhpIFRvbSwNCj4gPg0KPiA+IERlc3RpbmF0aW9uIFVucmVhY2hhYmxlIGlzbid0
IGFwcHJvcHJpYXRlIGJlY2F1c2UgdGhlIGRlc3RpbmF0aW9uICppcyoNCj4gcmVhY2hhYmxlLiBU
aGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBoZWFkZXIgaXMgdG9vIGxvbmcuDQo+IA0KPiBJdCBzZWVt
cyBhIERVIGlzIGFwcHJvcHJpYXRlLCBnb2luZyBieSB3aGF0IFJGQzQ0NDMgc2F5cywgYmVjYXVz
ZSB0aGUgY2F1c2UNCj4gb2YgdGhlIGZhaWx1cmUgaXNuJ3QgY29uZ2VzdGlvbjoNCj4gDQo+IA0K
PiAiQSBEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSBtZXNzYWdlIFNIT1VMRCBiZSBnZW5lcmF0ZWQg
YnkgYSByb3V0ZXIsIG9yDQo+ICAgIGJ5IHRoZSBJUHY2IGxheWVyIGluIHRoZSBvcmlnaW5hdGlu
ZyBub2RlLCBpbiByZXNwb25zZSB0byBhIHBhY2tldA0KPiAgICB0aGF0IGNhbm5vdCBiZSBkZWxp
dmVyZWQgdG8gaXRzIGRlc3RpbmF0aW9uIGFkZHJlc3MgZm9yIHJlYXNvbnMgb3RoZXINCj4gICAg
dGhhbiBjb25nZXN0aW9uLiAgKEFuIElDTVB2NiBtZXNzYWdlIE1VU1QgTk9UIGJlIGdlbmVyYXRl
ZCBpZiBhDQo+ICAgIHBhY2tldCBpcyBkcm9wcGVkIGR1ZSB0byBjb25nZXN0aW9uLikiDQo+IA0K
PiANCj4gKEkgbG9va2VkIGl0IHVwIGJlY2F1c2UgdGhpcyBkaXNjdXNzaW9uIG1hZGUgbWUgY3Vy
aW91cyBpZiBhIERBIC0gQWRtaW4NCj4gcHJvaGliaXRlZCB3YXMgbWFraW5nIGEgcG9zaXRpdmUg
Y29uZmlybWF0aW9uIG9mIHRoZSBkZXN0aW5hdGlvbidzIGV4aXN0ZW5jZSwNCj4gYW5kIHRoZSBw
cm9oaWJpdGlvbiB3YXMgb24gYmVpbmcgYWJsZSB0byByZWFjaCBpdC4gSXQgc2VlbXMgbm90LCB3
aGljaCBpcw0KPiBiZXR0ZXIgZm9yIHNlY3VyaXR5LikNCj4gDQo+IFJlZ2FyZHMsDQo+IE1hcmsu
DQo+IA0KPiANCj4gDQo+ID4NCj4gPiBJdCBzZWVtcyBsaWtlIHdlIGFyZSBpZGVudGlmeWluZyBh
biBuZXcgY29uc3RyYWludCwgdGhlIFBhdGggTWF4aW11bQ0KPiBIZWFkZXIgTGVuZ3RoIChQTUhM
KS4gSW4gc29tZSByZXNwZWN0cywgUE1ITCBpcyBzaW1pbGFyIHRvIFBNVFUuIFdoZW4NCj4gUE1U
VSBpcyB2aW9sYXRlZCwgd2Ugc2VuZCBhbiBJQ01QIFBUQiB0byB0aGUgc291cmNlIElQIHN0YWNr
LiBUaGUgc291cmNlIElQDQo+IG1vZGlmaWVzIGl0cyBlc3RpbWF0ZSBvZiB0aGUgUE1UVSwgaW5m
b3JtcyB1cHBlciBsYXllcnMgKGlmIGFwcHJvcHJpYXRlKSBhbmQNCj4gZnJhZ21lbnRzIHN1YnNl
cXVlbnQgcGFja2V0cyAoaWYgYXBwcm9wcmlhdGUpLg0KPiA+DQo+ID4gV2hhdCBzaG91bGQgaGFw
cGVuIHdoZW4gUE1ITCBpcyB2aW9sYXRlZD8gRG9lcyB0aGUgc291cmNlIElQIHN0YWNrDQo+IG5l
ZWQgdG8gYmUgaW5mb3JtZWQ/IElmIHNvLCB3aGF0IHdpbGwgdGhlIHNvdXJjZSBJUCBzdGFjayBk
byB3aXRoIHRoZQ0KPiBpbmZvcm1hdGlvbj8gT3IgaXMgcmVhbGx5IGFuIHVwcGVyIGxheWVyIGFw
cGxpY2F0aW9uIHRoYXQgbmVlZHMgdG8gYmUNCj4gaW5mb3JtZWQ/DQo+ID4NCj4gPg0KPiA+IFJv
bg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+
ID4+IEZyb206IFRvbSBIZXJiZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4gPj4g
U2VudDogVGh1cnNkYXksIE1heSAxOCwgMjAxNyA0OjUxIFBNDQo+ID4+IFRvOiBSb24gQm9uaWNh
IDxyYm9uaWNhQGp1bmlwZXIubmV0Pg0KPiA+PiBDYzogNm1hbkBpZXRmLm9yZw0KPiA+PiBTdWJq
ZWN0OiBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+PiBkcmFmdC1oZXJiZXJ0
LTZtYW4taWNtcC1saW1pdHMtIDAxLnR4dA0KPiA+Pg0KPiA+PiBPbiBXZWQsIE1heSAxNywgMjAx
NyBhdCA2OjAzIFBNLCBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0Pg0KPiB3cm90ZToN
Cj4gPj4gPiBUb20sDQo+ID4+ID4NCj4gPj4gPiBUaGUgSUNNUCBQYXJhbWV0ZXIgUHJvYmxlbSBt
ZXNzYWdlIG5vcm1hbGx5IGluZGljYXRlcyB0aGF0IHRoZXJlIGlzDQo+ID4+ID4gYQ0KPiA+PiBw
cm9ibGVtIHdpdGggYW4gSVAgUGFyYW1ldGVyLiBJbiB0aGUgZXhhbXBsZSBiZWxvdywgeW91IHVz
ZSBpdCB0bw0KPiA+PiBpbmRpY2F0ZSB0aGF0IGEgbWlkZGxlIGJveCBoYXMgYSBwcm9ibGVtIHdp
dGggdGhlIElQIHBheWxvYWQuIFRoaXMNCj4gPj4gc2VlbXMgdG8gYmUgb3ZlcmxvYWRpbmcgdGhl
IFBhcmFtZXRlciBQcm9ibGVtIG1lc3NhZ2UuDQo+ID4+ID4NCj4gPj4gSGkgUm9uLA0KPiA+Pg0K
PiA+PiBXb3VsZCBEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSBtZXNzYWdlIGJlIGFwcHJvcHJpYXRl
IHRoZW4/DQo+ID4+DQo+ID4+IFRvbQ0KPiA+Pg0KPiA+PiA+DQo+ID4+ID4gUm9uDQo+ID4+ID4N
Cj4gPj4gPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBJRVRGIElQdjYgd29ya2luZyBncm91
cCBtYWlsaW5nIGxpc3QNCj4gPiBpcHY2QGlldGYub3JnDQo+ID4gQWRtaW5pc3RyYXRpdmUgUmVx
dWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+IC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQo=


From nobody Mon May 22 07:31:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8CC12EACE for ; Mon, 22 May 2017 07:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 4-kK9O3v2ezq for ; Mon, 22 May 2017 07:31:07 -0700 (PDT)
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 AE9FB12EACC for ; Mon, 22 May 2017 07:31:06 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net;  b=wpAavR8Ft7vg/snueqzkG4ZcRsXmjqw8mPFN0OOSODoqM/kPElmEubrJ1cXxhrZ8Emk9Y4n00gSsAJe/EoCBxR7tNaOq+ykrxyfgwmsv/gWgV1GntxIwI9PR27hQpnHcSwaV6mRVQPAY8P7ck1gGwjC5dWVO9/2Mhy8xN/14E28=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 7651 invoked from network); 22 May 2017 16:31:04 +0200
Received: from pd9e110d0.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.16.208) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 May 2017 16:31:04 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: DISCUSS's on rfc1981bis - MK Comments
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: <589a1f5a-8ce8-d484-9083-5eaedee3f5ff@erg.abdn.ac.uk>
Date: Mon, 22 May 2017 16:31:03 +0200
Cc: ipv6@ietfa.amsl.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <97E22E2E-33E1-45A1-94E3-82FE35D1BDDB@kuehlewind.net>
References:  <5911B0EE.6080802@erg.abdn.ac.uk>  <59205C94.30200@erg.abdn.ac.uk> <52A24ADC-8D1D-47DA-ADC8-21D30C09D49E@kuehlewind.net> <589a1f5a-8ce8-d484-9083-5eaedee3f5ff@erg.abdn.ac.uk>
To: gorry@erg.abdn.ac.uk
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20170522143104.7646.53645@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 14:31:09 -0000

Hi Gorry,

thanks for the example below. Now I understand. My thinking was that you =
could also just retransmit the first segment in response to the packet =
too big message with the new indicated packet size and hold the rest of =
the to-be-retransmitted packet for later when the MTU probing is =
terminated. However, the point here is actually not about =
retransmitting. I guess what you actually need to say is that you should =
only send one MTU probe at a time. So if you want to retransmit all =
segments at once you need to use the confirmed PMTU that was used before =
the probing started, right?

Mirja


> Am 22.05.2017 um 13:17 schrieb Gorry Fairhurst :
>=20
> On 22/05/2017 10:49, Mirja Kuehlewind (IETF) wrote:
>> See below.
>>=20
>>=20
>>> Am 20.05.2017 um 17:11 schrieb Gorry Fairhurst =
:
>>>=20
>>> On 19/05/2017, 15:51, Mirja Kuehlewind (IETF) wrote:
>>>> Hi Gorry, hi all,
>>>>=20
>>>> thanks for the work and the update. All comments from Gorry seemed =
fine to me and I will try to review the changes in the updated doc soon. =
One more minor comment on this:
>>>>=20
>>>>> Am 09.05.2017 um 08:07 schrieb Gorry =
Fairhurst:
>>>>>=20
>>>>>> I don't understand the following paragraph. Can this be removed?
>>>>>> "Note: A packetization layer must not retransmit in response to
>>>>>> every Packet Too Big message, since a burst of several oversized
>>>>>> segments will give rise to several such messages and hence =
several
>>>>>> retransmissions of the same data. If the new estimated PMTU is
>>>>>> still wrong, the process repeats, and there is an exponential
>>>>>> growth in the number of superfluous segments sent."
>>>>>>=20
>>>>> GF: I think the example is important. I'm not sure why that would =
be removed.
>>>> The problem is I don=E2=80=99t understand this example. Is there an =
assumption that all mtu probe packets have been =E2=80=9Agenerated=E2=80=98=
 on the same packet? If so that makes sense but must the spelled out =
somewhere!
>>>>=20
>>>> Mirja
>>>>=20
>>>>=20
>>> I think the wording is maybe jumbled, but the point is OK. Perhaps =
something like this would be clearer?
>>>=20
>>> "Note: A packetization layer ought to avoid retransmitting the data =
in a probe packet
>>> using the size reported in the last Packet Too Big message.
>>> This is to avoid an exponential growth in the number of superfluous =
segments
>>> that would be sent when a path encounters several successive smaller =
PMTU limits.
>>> (Each new estimated PMTU would result in retransmission of the data =
in a smaller
>>> packet that may itself fail if it encounters a still smaller PMTU in =
a device further
>>> along the same path)."
>>>=20
>>> Gorry
>>>=20
>> I still don=E2=80=99t get it. Each time a packet is dropped, you have =
to
>> retransmit it (if your transport is reliable)
>> because otherwise the other end will not have it.
> >
> Sure. this says nothing about how you find out what segments need to
> be retransmit, only about the *SIZE* of the packets you use to perform =
that transmission.
>>=20
> >
>> I also still don=E2=80=99t see how there can be an exponential grows.
> >
> >
>> Sorry if I miss something but maybe you can explain again this case =
using different words=E2=80=A6?
>>=20
>> Mirja
>>=20
>=20
>=20
> Before I try different words, we should make sure the topic is =
understood.
>=20
> Suppose we wish to send a probe for 8KB, and suppose the path supports
> 3 router MTU sizes: a hop with 4KB MTU and then a later hop with 2KB =
MTU, and finally one of just 1400B.
>=20
> Largest probe size =3D 8KB
>=20
> The first probe sends 8KB as the Segment Size
> ->------------------------------X
> Dropped by first router along path.
> In example case PTB indicates next hop =3D  4KB.
> Data not reliably sent.
>=20
> Largest probe size =3D 4KB
>=20
> Retransmit 2 packet for same segment of data, each size 4KB
> ------------->------------------------------X
> ------------->------------------------------X
> Dropped by router later along path.
> In example case PTB indicates next hop =3D  2KB.
> Data still not reliably sent.
>=20
> Largest probe size =3D 2KB
>=20
> Retransmit 4 packets for same segment of data.
> In example case PTB indicates next hop =3D  1400B.
> Data still not reliably sent.
> ------------->------------------------------>---X
> ------------->------------------------------>---X
> ------------->------------------------------>---X
> ------------->------------------------------>---X
>=20
> Largest probe size =3D 1400B
>=20
> Data finally transmitted in 6 packets all less than PMTU.
> ------------->------------------------------>-------------->
> ------------->------------------------------>-------------->
> ------------->------------------------------>-------------->
> ------------->------------------------------>-------------->
> ------------->------------------------------>-------------->
> ------------->------------------------------>-------------->
>=20
> All data delivered. PMTU=3D1400B is confirmed.
>=20
> Total sent packets =3D 13 packets
> No of re-transmissions =3D 7 (6 failed re-transmissions in 3 =
re-transmission attempts)
>=20
> Now let's try a method that heeds the warning in the text and =
re-transmits the probe data using a "safe: MTU:
>=20
> The first probe sends 8KB as the Segment Size
> ->------------------------------X
>=20
> Dropped by first router along path.
> In example case PTB indicates next hop =3D  4KB.
> Data not reliably sent.
>=20
> Largest probe size =3D 4KB
>=20
> Sender resends the 8KB segment using a known workable PMTU (in the =
above 1500B, if that were cached, or even 1280B.
>=20
> ------------->------------------------------>-------------->
> ------------->------------------------------>-------------->
> ------------->------------------------------>-------------->
> ------------->------------------------------>-------------->
> ------------->------------------------------>-------------->
> ------------->------------------------------>-------------->
>=20
> Total sent packets =3D 7 packets
> No of re-transmissions =3D 6 (all successful, 1 re-transmission)
>=20
> And afterwards separately resend a single probe packet to detect a the =
largest PMTU using the 4KB probe.
>=20
> Obviously, there are many combinations of paths, and not all cases =
lead
> to exponential growth, but all cases lead to multiple probes, and
> multiple re-transmissions.
>=20
> Gorry


From nobody Mon May 22 08:01:10 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC9512EADB for ; Mon, 22 May 2017 08:01:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 cqCL2FC0NLQF for ; Mon, 22 May 2017 08:01:06 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4A70A120046 for ; Mon, 22 May 2017 08:01:06 -0700 (PDT)
Received: from dhcp-207-152.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:98a:ef06:ad1d:d6da]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id AFE711B017E4; Mon, 22 May 2017 17:56:01 +0100 (BST)
Reply-To: gorry@erg.abdn.ac.uk
Subject: Re: DISCUSS's on rfc1981bis - MK Comments
References:  <5911B0EE.6080802@erg.abdn.ac.uk>  <59205C94.30200@erg.abdn.ac.uk> <52A24ADC-8D1D-47DA-ADC8-21D30C09D49E@kuehlewind.net> <589a1f5a-8ce8-d484-9083-5eaedee3f5ff@erg.abdn.ac.uk> <97E22E2E-33E1-45A1-94E3-82FE35D1BDDB@kuehlewind.net>
To: "Mirja Kuehlewind (IETF)" 
Cc: ipv6@ietfa.amsl.com
From: Gorry Fairhurst 
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683.
Message-ID: <64a06a7f-3d3e-dde6-7373-e104dfc04272@erg.abdn.ac.uk>
Date: Mon, 22 May 2017 16:01:05 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <97E22E2E-33E1-45A1-94E3-82FE35D1BDDB@kuehlewind.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 15:01:09 -0000

On 22/05/2017 15:31, Mirja Kuehlewind (IETF) wrote:
> Hi Gorry,
>
> thanks for the example below. Now I understand. My thinking was that you could also just retransmit the first segment in response to the packet too big message with the new indicated packet size and hold the rest of the to-be-retransmitted packet for later when the MTU probing is terminated. However, the point here is actually not about retransmitting. I guess what you actually need to say is that you should only send one MTU probe at a time. So if you want to retransmit all segments at once you need to use the confirmed PMTU that was used before the probing started, right?
>
> Mirja
>
OK - I also don't particularly mind if we change the text.

I'd suggest not even retransmitting the probe packet as another probe 
(if this data needs to be sent reliably). If there is more data, that 
later data can be used for the probe, I think there is really no need to 
hurry this procedure be vulnerable to multiple losses and re-transmits.

So, without trying to sketch a definition of a method - which I think is 
outside of the spirit of this update, can we simply identify what is the 
key thing to highlight?

Gorry

>
>> Am 22.05.2017 um 13:17 schrieb Gorry Fairhurst :
>>
>> On 22/05/2017 10:49, Mirja Kuehlewind (IETF) wrote:
>>> See below.
>>>
>>>
>>>> Am 20.05.2017 um 17:11 schrieb Gorry Fairhurst :
>>>>
>>>> On 19/05/2017, 15:51, Mirja Kuehlewind (IETF) wrote:
>>>>> Hi Gorry, hi all,
>>>>>
>>>>> thanks for the work and the update. All comments from Gorry seemed fine to me and I will try to review the changes in the updated doc soon. One more minor comment on this:
>>>>>
>>>>>> Am 09.05.2017 um 08:07 schrieb Gorry Fairhurst:
>>>>>>
>>>>>>> I don't understand the following paragraph. Can this be removed?
>>>>>>> "Note: A packetization layer must not retransmit in response to
>>>>>>> every Packet Too Big message, since a burst of several oversized
>>>>>>> segments will give rise to several such messages and hence several
>>>>>>> retransmissions of the same data. If the new estimated PMTU is
>>>>>>> still wrong, the process repeats, and there is an exponential
>>>>>>> growth in the number of superfluous segments sent."
>>>>>>>
>>>>>> GF: I think the example is important. I'm not sure why that would be removed.
>>>>> The problem is I don’t understand this example. Is there an assumption that all mtu probe packets have been ‚generated‘ on the same packet? If so that makes sense but must the spelled out somewhere!
>>>>>
>>>>> Mirja
>>>>>
>>>>>
>>>> I think the wording is maybe jumbled, but the point is OK. Perhaps something like this would be clearer?
>>>>
>>>> "Note: A packetization layer ought to avoid retransmitting the data in a probe packet
>>>> using the size reported in the last Packet Too Big message.
>>>> This is to avoid an exponential growth in the number of superfluous segments
>>>> that would be sent when a path encounters several successive smaller PMTU limits.
>>>> (Each new estimated PMTU would result in retransmission of the data in a smaller
>>>> packet that may itself fail if it encounters a still smaller PMTU in a device further
>>>> along the same path)."
>>>>
>>>> Gorry
>>>>
>>> I still don’t get it. Each time a packet is dropped, you have to
>>> retransmit it (if your transport is reliable)
>>> because otherwise the other end will not have it.
>>>
>> Sure. this says nothing about how you find out what segments need to
>> be retransmit, only about the *SIZE* of the packets you use to perform that transmission.
>>>
>>>
>>> I also still don’t see how there can be an exponential grows.
>>>
>>>
>>> Sorry if I miss something but maybe you can explain again this case using different words…?
>>>
>>> Mirja
>>>
>>
>>
>> Before I try different words, we should make sure the topic is understood.
>>
>> Suppose we wish to send a probe for 8KB, and suppose the path supports
>> 3 router MTU sizes: a hop with 4KB MTU and then a later hop with 2KB MTU, and finally one of just 1400B.
>>
>> Largest probe size = 8KB
>>
>> The first probe sends 8KB as the Segment Size
>> ->------------------------------X
>> Dropped by first router along path.
>> In example case PTB indicates next hop =  4KB.
>> Data not reliably sent.
>>
>> Largest probe size = 4KB
>>
>> Retransmit 2 packet for same segment of data, each size 4KB
>> ------------->------------------------------X
>> ------------->------------------------------X
>> Dropped by router later along path.
>> In example case PTB indicates next hop =  2KB.
>> Data still not reliably sent.
>>
>> Largest probe size = 2KB
>>
>> Retransmit 4 packets for same segment of data.
>> In example case PTB indicates next hop =  1400B.
>> Data still not reliably sent.
>> ------------->------------------------------>---X
>> ------------->------------------------------>---X
>> ------------->------------------------------>---X
>> ------------->------------------------------>---X
>>
>> Largest probe size = 1400B
>>
>> Data finally transmitted in 6 packets all less than PMTU.
>> ------------->------------------------------>-------------->
>> ------------->------------------------------>-------------->
>> ------------->------------------------------>-------------->
>> ------------->------------------------------>-------------->
>> ------------->------------------------------>-------------->
>> ------------->------------------------------>-------------->
>>
>> All data delivered. PMTU=1400B is confirmed.
>>
>> Total sent packets = 13 packets
>> No of re-transmissions = 7 (6 failed re-transmissions in 3 re-transmission attempts)
>>
>> Now let's try a method that heeds the warning in the text and re-transmits the probe data using a "safe: MTU:
>>
>> The first probe sends 8KB as the Segment Size
>> ->------------------------------X
>>
>> Dropped by first router along path.
>> In example case PTB indicates next hop =  4KB.
>> Data not reliably sent.
>>
>> Largest probe size = 4KB
>>
>> Sender resends the 8KB segment using a known workable PMTU (in the above 1500B, if that were cached, or even 1280B.
>>
>> ------------->------------------------------>-------------->
>> ------------->------------------------------>-------------->
>> ------------->------------------------------>-------------->
>> ------------->------------------------------>-------------->
>> ------------->------------------------------>-------------->
>> ------------->------------------------------>-------------->
>>
>> Total sent packets = 7 packets
>> No of re-transmissions = 6 (all successful, 1 re-transmission)
>>
>> And afterwards separately resend a single probe packet to detect a the largest PMTU using the 4KB probe.
>>
>> Obviously, there are many combinations of paths, and not all cases lead
>> to exponential growth, but all cases lead to multiple probes, and
>> multiple re-transmissions.
>>
>> Gorry
>


From nobody Mon May 22 08:02:50 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977E012EAF4 for ; Mon, 22 May 2017 08:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 X1nEwtuSIkit for ; Mon, 22 May 2017 08:02:46 -0700 (PDT)
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 E195A12EAED for ; Mon, 22 May 2017 08:02:45 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net;  b=dUOQisHmjgCMJ0zOVvJACNXMlL2KV4uo1ilrFaGEsRCbJAK5NerWZt2InmqrmF6NovUr0NZH92GoeXqpxCtnc5Qxn8dGZDVmrNYc7niznIEEvzTRKV/suLgJWclyvZob/kNjOnH70q+kWdVg2FHYZx2+PlFS1IFRDYQ9mmY481U=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 9618 invoked from network); 22 May 2017 17:02:43 +0200
Received: from pd9e110d0.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.16.208) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 May 2017 17:02:43 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: DISCUSS's on rfc1981bis - MK Comments
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: <64a06a7f-3d3e-dde6-7373-e104dfc04272@erg.abdn.ac.uk>
Date: Mon, 22 May 2017 17:02:42 +0200
Cc: ipv6@ietfa.amsl.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <508AA18F-0790-4167-A54F-9F3E8B051229@kuehlewind.net>
References:  <5911B0EE.6080802@erg.abdn.ac.uk>  <59205C94.30200@erg.abdn.ac.uk> <52A24ADC-8D1D-47DA-ADC8-21D30C09D49E@kuehlewind.net> <589a1f5a-8ce8-d484-9083-5eaedee3f5ff@erg.abdn.ac.uk> <97E22E2E-33E1-45A1-94E3-82FE35D1BDDB@kuehlewind.net> <64a06a7f-3d3e-dde6-7373-e104dfc04272@erg.abdn.ac.uk>
To: gorry@erg.abdn.ac.uk
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20170522150243.9613.87612@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 15:02:48 -0000

Yes, please propose new text.

> Am 22.05.2017 um 17:01 schrieb Gorry Fairhurst :
>=20
> On 22/05/2017 15:31, Mirja Kuehlewind (IETF) wrote:
>> Hi Gorry,
>>=20
>> thanks for the example below. Now I understand. My thinking was that =
you could also just retransmit the first segment in response to the =
packet too big message with the new indicated packet size and hold the =
rest of the to-be-retransmitted packet for later when the MTU probing is =
terminated. However, the point here is actually not about =
retransmitting. I guess what you actually need to say is that you should =
only send one MTU probe at a time. So if you want to retransmit all =
segments at once you need to use the confirmed PMTU that was used before =
the probing started, right?
>>=20
>> Mirja
>>=20
> OK - I also don't particularly mind if we change the text.
>=20
> I'd suggest not even retransmitting the probe packet as another probe =
(if this data needs to be sent reliably). If there is more data, that =
later data can be used for the probe, I think there is really no need to =
hurry this procedure be vulnerable to multiple losses and re-transmits.
>=20
> So, without trying to sketch a definition of a method - which I think =
is outside of the spirit of this update, can we simply identify what is =
the key thing to highlight?
>=20
> Gorry
>=20
>>=20
>>> Am 22.05.2017 um 13:17 schrieb Gorry Fairhurst =
:
>>>=20
>>> On 22/05/2017 10:49, Mirja Kuehlewind (IETF) wrote:
>>>> See below.
>>>>=20
>>>>=20
>>>>> Am 20.05.2017 um 17:11 schrieb Gorry Fairhurst =
:
>>>>>=20
>>>>> On 19/05/2017, 15:51, Mirja Kuehlewind (IETF) wrote:
>>>>>> Hi Gorry, hi all,
>>>>>>=20
>>>>>> thanks for the work and the update. All comments from Gorry =
seemed fine to me and I will try to review the changes in the updated =
doc soon. One more minor comment on this:
>>>>>>=20
>>>>>>> Am 09.05.2017 um 08:07 schrieb Gorry =
Fairhurst:
>>>>>>>=20
>>>>>>>> I don't understand the following paragraph. Can this be =
removed?
>>>>>>>> "Note: A packetization layer must not retransmit in response to
>>>>>>>> every Packet Too Big message, since a burst of several =
oversized
>>>>>>>> segments will give rise to several such messages and hence =
several
>>>>>>>> retransmissions of the same data. If the new estimated PMTU is
>>>>>>>> still wrong, the process repeats, and there is an exponential
>>>>>>>> growth in the number of superfluous segments sent."
>>>>>>>>=20
>>>>>>> GF: I think the example is important. I'm not sure why that =
would be removed.
>>>>>> The problem is I don=E2=80=99t understand this example. Is there =
an assumption that all mtu probe packets have been =E2=80=9Agenerated=E2=80=
=98 on the same packet? If so that makes sense but must the spelled out =
somewhere!
>>>>>>=20
>>>>>> Mirja
>>>>>>=20
>>>>>>=20
>>>>> I think the wording is maybe jumbled, but the point is OK. Perhaps =
something like this would be clearer?
>>>>>=20
>>>>> "Note: A packetization layer ought to avoid retransmitting the =
data in a probe packet
>>>>> using the size reported in the last Packet Too Big message.
>>>>> This is to avoid an exponential growth in the number of =
superfluous segments
>>>>> that would be sent when a path encounters several successive =
smaller PMTU limits.
>>>>> (Each new estimated PMTU would result in retransmission of the =
data in a smaller
>>>>> packet that may itself fail if it encounters a still smaller PMTU =
in a device further
>>>>> along the same path)."
>>>>>=20
>>>>> Gorry
>>>>>=20
>>>> I still don=E2=80=99t get it. Each time a packet is dropped, you =
have to
>>>> retransmit it (if your transport is reliable)
>>>> because otherwise the other end will not have it.
>>>>=20
>>> Sure. this says nothing about how you find out what segments need to
>>> be retransmit, only about the *SIZE* of the packets you use to =
perform that transmission.
>>>>=20
>>>>=20
>>>> I also still don=E2=80=99t see how there can be an exponential =
grows.
>>>>=20
>>>>=20
>>>> Sorry if I miss something but maybe you can explain again this case =
using different words=E2=80=A6?
>>>>=20
>>>> Mirja
>>>>=20
>>>=20
>>>=20
>>> Before I try different words, we should make sure the topic is =
understood.
>>>=20
>>> Suppose we wish to send a probe for 8KB, and suppose the path =
supports
>>> 3 router MTU sizes: a hop with 4KB MTU and then a later hop with 2KB =
MTU, and finally one of just 1400B.
>>>=20
>>> Largest probe size =3D 8KB
>>>=20
>>> The first probe sends 8KB as the Segment Size
>>> ->------------------------------X
>>> Dropped by first router along path.
>>> In example case PTB indicates next hop =3D  4KB.
>>> Data not reliably sent.
>>>=20
>>> Largest probe size =3D 4KB
>>>=20
>>> Retransmit 2 packet for same segment of data, each size 4KB
>>> ------------->------------------------------X
>>> ------------->------------------------------X
>>> Dropped by router later along path.
>>> In example case PTB indicates next hop =3D  2KB.
>>> Data still not reliably sent.
>>>=20
>>> Largest probe size =3D 2KB
>>>=20
>>> Retransmit 4 packets for same segment of data.
>>> In example case PTB indicates next hop =3D  1400B.
>>> Data still not reliably sent.
>>> ------------->------------------------------>---X
>>> ------------->------------------------------>---X
>>> ------------->------------------------------>---X
>>> ------------->------------------------------>---X
>>>=20
>>> Largest probe size =3D 1400B
>>>=20
>>> Data finally transmitted in 6 packets all less than PMTU.
>>> ------------->------------------------------>-------------->
>>> ------------->------------------------------>-------------->
>>> ------------->------------------------------>-------------->
>>> ------------->------------------------------>-------------->
>>> ------------->------------------------------>-------------->
>>> ------------->------------------------------>-------------->
>>>=20
>>> All data delivered. PMTU=3D1400B is confirmed.
>>>=20
>>> Total sent packets =3D 13 packets
>>> No of re-transmissions =3D 7 (6 failed re-transmissions in 3 =
re-transmission attempts)
>>>=20
>>> Now let's try a method that heeds the warning in the text and =
re-transmits the probe data using a "safe: MTU:
>>>=20
>>> The first probe sends 8KB as the Segment Size
>>> ->------------------------------X
>>>=20
>>> Dropped by first router along path.
>>> In example case PTB indicates next hop =3D  4KB.
>>> Data not reliably sent.
>>>=20
>>> Largest probe size =3D 4KB
>>>=20
>>> Sender resends the 8KB segment using a known workable PMTU (in the =
above 1500B, if that were cached, or even 1280B.
>>>=20
>>> ------------->------------------------------>-------------->
>>> ------------->------------------------------>-------------->
>>> ------------->------------------------------>-------------->
>>> ------------->------------------------------>-------------->
>>> ------------->------------------------------>-------------->
>>> ------------->------------------------------>-------------->
>>>=20
>>> Total sent packets =3D 7 packets
>>> No of re-transmissions =3D 6 (all successful, 1 re-transmission)
>>>=20
>>> And afterwards separately resend a single probe packet to detect a =
the largest PMTU using the 4KB probe.
>>>=20
>>> Obviously, there are many combinations of paths, and not all cases =
lead
>>> to exponential growth, but all cases lead to multiple probes, and
>>> multiple re-transmissions.
>>>=20
>>> Gorry
>>=20
>=20


From nobody Mon May 22 08:44:07 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B29127775 for ; Mon, 22 May 2017 08:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HipTQDVu06fW for ; Mon, 22 May 2017 08:44:03 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 AC3291200E5 for <6man@ietf.org>; Mon, 22 May 2017 08:44:03 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id u75so109076226qka.3 for <6man@ietf.org>; Mon, 22 May 2017 08:44:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KZrtg++m7xQrhb2/5Uo8LbMdxYaBlMvGEm92DtWLyd0=; b=PBd0k3Ys4LVcYKjKobN6bcMNv5AE9NcR8NjQ1Kg6yUHpkKy/j+FX+ue3xAt5qq1/ci LHFpWchZ9BRSzWnB53pIcCPIYfrwa6cOcjcSllz7OpCAKaETbV/6mLEkFcauwitXDlTt i4K9fon+29MBR2y/mPRgALqjoe6cdzdnCbXzbGU491BHeCN0yNEl++MeX61ZjKPpggGi GlDslkSH02qCSS39Y5lQMCD98Ph7dYf50D9kdS2F7Chw0rfDspznPnu2OZSCVixsCmRW wC3cEorK6zWxjxxBflumXi5xOPLfwePPw61OpyFHug6ZBXNmvgjpfhM7lqYdtFhFFBpF PJnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KZrtg++m7xQrhb2/5Uo8LbMdxYaBlMvGEm92DtWLyd0=; b=k8UvykLI/uGUNYgXf2JPMHDD27fziuuh0oZW8noJNjMG1VqdVHb829gV4y7N+13eiO A2oLLPl7MlICKVplFNVRkWSM/h171ubwh66xPm2DHtsAlyLYIex1PsywIZNFMZTPgDrr gKRhhpJbcazIpbYRCcPZvWCIxyYQg8Zt8T3j1Rt1W1VPx//XFxeEPK9xZRZLsjiovCv9 pHy89vDEJR2oQ3KTEZwqSy65Dtv5pXcPy+L2lrTZDPxlfhdxCxiH9xfgtyuKpLzcKQek scCI2w4pVLhGvG6wyFV4cD3cwhV7d6jcqWn7bZoOzja/Krok/BXAGDo5mVUY0SMjnuxh xr3Q==
X-Gm-Message-State: AODbwcAZQhBziMoS1jE5c3tcMK5CLeK2PBAmQev2A8PuLOri1HmXvMyx 9kELmYdj+ycbVfGzigICEP8y5AxVfnJj
X-Received: by 10.55.154.143 with SMTP id c137mr20611984qke.177.1495467842676;  Mon, 22 May 2017 08:44:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Mon, 22 May 2017 08:44:02 -0700 (PDT)
In-Reply-To: 
References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com>            
From: Tom Herbert 
Date: Mon, 22 May 2017 08:44:02 -0700
Message-ID: 
Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
To: Ron Bonica 
Cc: Mark Smith , "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 15:44:06 -0000

On Mon, May 22, 2017 at 7:09 AM, Ron Bonica  wrote:
> Mark,
>
> Strictly speaking, Destination Unreachable is appropriate whenever a pack=
et is discarded for any reason other than congestion. But according to that=
 reasoning, you don't need an ICMP Packet Too Big message. The PTB error co=
uld be reported  by Destination Unreachable message with a PTB error code.
>
To be completely pedantic then, the RFC4443 description of destination
unreachable isn't entirely correct. PTB, Parameter problem, and time
exceeded are used for discarded packets as opposed to destination
unreachable and are not congestion.

> In reality, we need the ICMP PTB message because of its special status. T=
hat is, people know that they MUST NOT filter ICMP PTB's because filtering =
may cause black-holing. I am thinking that Header Too Long (HTL)  is akin t=
o PTB. If HTL information hitchhikes on an existing ICMP message, that mess=
age should probably be PTB.
>
I don't think HTL should qualify for that special status. The
difference between PTB and HTL is the response the sending host(s)
take. For PTB the response is deterministic, the sending application
should lower its PMTU. But handling of HTL is not deterministic, it
may or may not be feasible to reduce headers to fit. The response to
HTL might be more on the administrative side like other destination
unreachable errors.

> But then again, a new ICMP message may be required.
>
Isn't it more likely a new ICMP type would be filtered more than PTB
or destination unreachable?

Tom

>                                                                    Ron
>
>
>> -----Original Message-----
>> From: Mark Smith [mailto:markzzzsmith@gmail.com]
>> Sent: Sunday, May 21, 2017 12:29 AM
>> To: Ron Bonica 
>> Cc: Tom Herbert ; 6man@ietf.org
>> Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits=
-
>> 01.txt
>>
>> On 21 May 2017 at 01:49, Ron Bonica  wrote:
>> > Hi Tom,
>> >
>> > Destination Unreachable isn't appropriate because the destination *is*
>> reachable. The problem is that the header is too long.
>>
>> It seems a DU is appropriate, going by what RFC4443 says, because the ca=
use
>> of the failure isn't congestion:
>>
>>
>> "A Destination Unreachable message SHOULD be generated by a router, or
>>    by the IPv6 layer in the originating node, in response to a packet
>>    that cannot be delivered to its destination address for reasons other
>>    than congestion.  (An ICMPv6 message MUST NOT be generated if a
>>    packet is dropped due to congestion.)"
>>
>>
>> (I looked it up because this discussion made me curious if a DA - Admin
>> prohibited was making a positive confirmation of the destination's exist=
ence,
>> and the prohibition was on being able to reach it. It seems not, which i=
s
>> better for security.)
>>
>> Regards,
>> Mark.
>>
>>
>>
>> >
>> > It seems like we are identifying an new constraint, the Path Maximum
>> Header Length (PMHL). In some respects, PMHL is similar to PMTU. When
>> PMTU is violated, we send an ICMP PTB to the source IP stack. The source=
 IP
>> modifies its estimate of the PMTU, informs upper layers (if appropriate)=
 and
>> fragments subsequent packets (if appropriate).
>> >
>> > What should happen when PMHL is violated? Does the source IP stack
>> need to be informed? If so, what will the source IP stack do with the
>> information? Or is really an upper layer application that needs to be
>> informed?
>> >
>> >
>> > Ron
>> >
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> From: Tom Herbert [mailto:tom@herbertland.com]
>> >> Sent: Thursday, May 18, 2017 4:51 PM
>> >> To: Ron Bonica 
>> >> Cc: 6man@ietf.org
>> >> Subject: Re: New Version Notification for
>> >> draft-herbert-6man-icmp-limits- 01.txt
>> >>
>> >> On Wed, May 17, 2017 at 6:03 PM, Ron Bonica 
>> wrote:
>> >> > Tom,
>> >> >
>> >> > The ICMP Parameter Problem message normally indicates that there is
>> >> > a
>> >> problem with an IP Parameter. In the example below, you use it to
>> >> indicate that a middle box has a problem with the IP payload. This
>> >> seems to be overloading the Parameter Problem message.
>> >> >
>> >> Hi Ron,
>> >>
>> >> Would Destination Unreachable message be appropriate then?
>> >>
>> >> Tom
>> >>
>> >> >
>> >> > Ron
>> >> >
>> >> >
>> >
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > ipv6@ietf.org
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------


From nobody Mon May 22 11:35:08 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EFA1286D6; Mon, 22 May 2017 11:34:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: The IESG 
To: "IETF-Announce" 
Subject: Protocol Action: 'Internet Protocol, Version 6 (IPv6) Specification' to Internet Standard (draft-ietf-6man-rfc2460bis-13.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: draft-ietf-6man-rfc2460bis@ietf.org, The IESG , ipv6@ietf.org, Ole Troan , otroan@employees.org, suresh.krishnan@gmail.com, rfc-editor@rfc-editor.org, 6man-chairs@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-ID: <149547809408.30287.11558752916330127303.idtracker@ietfa.amsl.com>
Date: Mon, 22 May 2017 11:34:54 -0700
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 18:34:54 -0000

The IESG has approved the following document:
- 'Internet Protocol, Version 6 (IPv6) Specification'
  (draft-ietf-6man-rfc2460bis-13.txt) as Internet Standard

This document is the product of the IPv6 Maintenance Working Group.

The IESG contact persons are Suresh Krishnan and Terry Manderson.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/





Technical Summary

  This document specifies the version of the IPv6 protocol that is being 
  elevated to Internet Standard. This will obsolete RFC2460 that is the
  Draft Standard version of the protocol. This version incorporates fixes
  for Errata as well as updates to RFC2460.

Working Group Summary

   The 6MAN working started working on advancing the IPv6 core
   specifications to Internet Standard at IETF93 July 2015.  See:
   https://www.ietf.org/proceedings/93/slides/slides-93-6man-3.pdf The
   working group identified three RFCs to update (RFC2460, RFC4291, and
   RFC1981) by incorporating updates from other RFCs and Errata, and
   three to advance in place RFC4443, RFC3596, and RFC4941.  After
   further analysis, the w.g. decided to not reclassify RFC4941 at this
   time.

   The working followed the requirements in RFC6410 for advancing a Draft
   Standard to Internet Standard.  While RFC6410 describes how to handle
   Errata, it doesn't say anything about Updated-By RFCs.  The working
   group, with the advice of our AD, incorporated the changes from the
   the Updated-By RFC and verified there was interoperability of the
   updates.

   All of the Updated-By and errata were brought into the new draft in
   small steps to allow thorough review of all of the changes.  A summary
   and link to diff from the previous version was sent to the mailing
   list.  All of the changes to each draft were also discussed in detail
   at IETF94, IETF95, IETF96, and IETF97.  All of the changes from
   RFC2460 are summarized in Appendix B and are ordered by the Internet
   Draft that brought the change in.

   A working group last call for moving this and the other two documents
   to Internet Standard was started on 30 May 2016.  Reviews were also
   requested.  Issues found during the last call and reviews were entered
   into the 6MAN ticket system.  These are now closed.

   The biggest issue raised was how to handle the issue of Extension
   Header insertion in this document.  After many discussion on the
   mailing list and face to face meeting, there wasn’t a clear consensus.
   The chairs conducted an online survey that provided three choices: Ban
   header insertion, describe the problems with header insertion, or say
   nothing.  The result of the survey was to describe the solution.  The
   results and methodology used to evaluate the results can be seen at:

     https://mailarchive.ietf.org/arch/msg/ipv6/_gG2foiugk5B7w3TpnPvBbjHDzs

   This was discussed at the 6MAN session at IETF97 and on the mailing
   list after the meeting.  The chairs believe there is a consensus to go
   forward with the text that is in draft-ietf-6man-rfc2460bis-08.

AD's comment on IETF Last Call:

   The IETF last call discussion for this draft was mainly focused around the text 
   in Section 4 that discusses the handling of extension headers. The biggest concern
   raised was that the current text is ambiguous on whether header insertion is
   allowed on intermediate nodes or not. There were some people arguing that an 
   explicit prohibition is not necessary as the text is already clear, while others believed
   that explicitly listing the prohibitions will minimize any misunderstandings in the
   future. There was also a small number of people who wanted to explicitly allow
   header insertion and describe how to do it, but this was clearly out of scope for this
   draft (but may be in scope for future work in 6man). Overall, no one argued against
   the fact that the intent of the text in RFC2460 was to forbid insertion of extension 
   headers on any other node but the source of the packet.  The only argument made 
   against adding clarifying text was that the text was already clear. Given this, I believe
   there is consensus to add explicit text about header insertion into the draft before it
   progresses further. This change has been done in version -09.

Document Quality

   IPv6 is implemented on most platforms (hosts, routers, servers, etc.),
   including proprietary and open source.  A list of products that have
   received the IPV6 Ready logo can be found at:
   https://www.ipv6ready.org/db/index.php/public/?o=4

   Most major ISP now support IPv6, as well as many mobile
   operators.

   Google’s IPv6 stats at
   https://www.google.com/intl/en/ipv6/statistics.html show they are
   seeing now about 15% of their overall user traffic is IPv6. Country
   adoption is 29% in the US, Germany 27%, Finland 12%, Japan 14%, Brazil
   11%.  IPv6 users per AS can be found at
   http://stats.labs.apnic.net/aspop

   The University of New Hampshire InterOperability Laboratory (UNH)
   analyzed the incorporated updates to insure they were implemented and
   interoperable.  No problems were found.  Their report can be found at:
   https://www.ietf.org/proceedings/95/slides/slides-95-6man-2.pdf

Personnel

  The  document shepherd is Ole Trøan. The responsible AD is Suresh Krishnan.


From nobody Mon May 22 11:47:55 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70362128AB0 for ; Mon, 22 May 2017 11:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level: 
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=juniper.net
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 wRp5go9QWm3n for ; Mon, 22 May 2017 11:47:51 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0112.outbound.protection.outlook.com [104.47.41.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8022E12741D for <6man@ietf.org>; Mon, 22 May 2017 11:47:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TqhHBFLXZwWoIqnLcoZ4jXJ16sSEmNKHOK4Z6lWaZ3w=; b=BEaZVm46Ek5LkcCap4SVRECk1LweJwfBAVqZWm5yoQ88tyomNGh9L8xxjo1MkrTxwAkgsugpsG2nzqu72/lCO41HU9+ES7iP11KAo7JqavJvHdxYWYWgTYOu44seWTd+3wYGuHW6ILiqFdr+3+rJBh++HYs3EEeDIY+/v1YT5Bs=
Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2050.namprd05.prod.outlook.com (10.164.23.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Mon, 22 May 2017 18:47:49 +0000
Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1124.007; Mon, 22 May 2017 18:47:49 +0000
From: Ron Bonica 
To: Tom Herbert 
CC: Mark Smith , "6man@ietf.org" <6man@ietf.org>
Subject: RE: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
Thread-Topic: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
Thread-Index: AQHSydvj2CNgsdR2N0SNyPfQvMZ6VaH1duKggAAhBwCAABvukIAAPKEAgAFC5PCAAEjSAIAB0s1wgAFOJoCAAs09sIAA13mAgAIxMBCAAB25AIAAMY+w
Date: Mon, 22 May 2017 18:47:49 +0000
Message-ID: 
References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com>             
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: herbertland.com; dkim=none (message not signed) header.d=none;herbertland.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2050; 7:+/j+N3veNWHUPKq3EVfdYjUa0XvdO8WDjnxYqp0DhTuxbB7CmA7dVw2dygEU32hFBR5QOjSl0eBCe25N69vBAiG6UVWDtvzvzau+OU1WmpsA6EtTxjHuKoxkoOeteGh88ofp3hLeo/RPWAiwQKpIp6xOJkELvJosoaRTBuWQySQH+F0mtTKubLD8sEj9h2pGiCAAGJfd9s4VeeAilPBY3scqHWMaXGaQV5/Zzh2UidxnoKUkf3+0LuBfxcivsdngLL3sESfuY5/pAWOa/kQgbdk7dmxJqgnbGjTjfU1P2bf/bEtzk2BSGR6fceqtj3+zXN9mZ6S8S7OyFXysZKkeYQ==
x-ms-traffictypediagnostic: BLUPR0501MB2050:
x-ms-office365-filtering-correlation-id: 2f9b6c62-786e-42e5-2494-08d4a1430bb3
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR0501MB2050; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148); SRVR:BLUPR0501MB2050; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2050; 
x-forefront-prvs: 03152A99FF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39850400002)(39400400002)(39410400002)(39860400002)(39840400002)(66066001)(6916009)(7696004)(2950100002)(7736002)(77096006)(5660300001)(305945005)(74316002)(229853002)(478600001)(15650500001)(8676002)(81166006)(53936002)(2900100001)(122556002)(4326008)(9686003)(189998001)(99286003)(6246003)(97736004)(230783001)(93886004)(54906002)(55016002)(38730400002)(2906002)(25786009)(6436002)(3846002)(102836003)(8936002)(6116002)(3660700001)(76176999)(54356999)(86362001)(39060400002)(33656002)(50986999)(3280700002)(110136004)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2050; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2017 18:47:49.6452 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2050
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 18:47:53 -0000

SGkgVG9tLA0KDQpUaGlzIHJhaXNlcyB0aGUgc2FsaWVudCBxdWVzdGlvbi4gV2hlbiB0aGUgc291
cmNlIElQIHN0YWNrIHJlY2VpdmVzIGEgbWVzc2FnZSBpbmZvcm1pbmcgaXQgdGhhdCBIVEwgaGFz
IGJlZW4gZXhjZWVkZWQsIHdoYXQgc2hvdWxkIGl0IGRvPw0KDQpXaGVuIHRoZSBzb3VyY2UgSVAg
c3RhY2sgcmVjZWl2ZXMgYW4gSUNNUCBQVEIgbWVzc2FnZSwgdGhlIHJlcXVpcmVkIGFjdGlvbiBp
cyB3ZWxsLXVuZGVyc3Rvb2QuIEl0IHNob3VsZDoNCg0KLSB1cGRhdGUgaXRzIGVzdGltYXRlIG9m
IHRoZSBQTVRVIGFzc29jaWF0ZWQgd2l0aCB0aGUgZGVzdGluYXRpb24gb2YgdGhlIG9yaWdpbmFs
IHBhY2tldA0KLSBpbmZvcm0gYSBoaWdoZXIgbGF5ZXIgcHJvdG9jb2wgaWYgYXBwcm9wcmlhdGUN
Ci0gcmVmcmFpbiBmcm9tIHNlbmRpbmcgbWVzc2FnZXMgdGhhdCBleGNlZWQgdGhlIFBNVFUgaW4g
dGhlIGZ1dHVyZQ0KDQpXaGVuIHRoZSBzb3VyY2UgSVAgc3RhY2sgcmVjZWl2ZXMgYSBtZXNzYWdl
IGluZm9ybWluZyBpdCBvZiBhIEhUTCB2aW9sYXRpb24sIHdoYXQgc2hvdWxkIGl0IGRvPyANCg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBSb24NCg0KDQo+IEkgZG9uJ3QgdGhpbmsgSFRMIHNob3VsZCBxdWFsaWZ5IGZv
ciB0aGF0IHNwZWNpYWwgc3RhdHVzLiBUaGUgZGlmZmVyZW5jZQ0KPiBiZXR3ZWVuIFBUQiBhbmQg
SFRMIGlzIHRoZSByZXNwb25zZSB0aGUgc2VuZGluZyBob3N0KHMpIHRha2UuIEZvciBQVEIgdGhl
DQo+IHJlc3BvbnNlIGlzIGRldGVybWluaXN0aWMsIHRoZSBzZW5kaW5nIGFwcGxpY2F0aW9uIHNo
b3VsZCBsb3dlciBpdHMgUE1UVS4gQnV0DQo+IGhhbmRsaW5nIG9mIEhUTCBpcyBub3QgZGV0ZXJt
aW5pc3RpYywgaXQgbWF5IG9yIG1heSBub3QgYmUgZmVhc2libGUgdG8gcmVkdWNlDQo+IGhlYWRl
cnMgdG8gZml0LiBUaGUgcmVzcG9uc2UgdG8gSFRMIG1pZ2h0IGJlIG1vcmUgb24gdGhlIGFkbWlu
aXN0cmF0aXZlIHNpZGUNCj4gbGlrZSBvdGhlciBkZXN0aW5hdGlvbiB1bnJlYWNoYWJsZSBlcnJv
cnMuDQo+IA0KDQo=


From nobody Mon May 22 14:19:48 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542A3128D3E for ; Mon, 22 May 2017 14:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAdcPE-eu_Qf for ; Mon, 22 May 2017 14:19:45 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 BE2EE127B60 for <6man@ietf.org>; Mon, 22 May 2017 14:19:45 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id u75so116931502qka.3 for <6man@ietf.org>; Mon, 22 May 2017 14:19:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w7CAUcbHNUlb9vHqNp9A+duUWC5Q6Z8qpVcMw7sprD0=; b=y3GIYGRPED9MZuSBFAQAQwT+1xVnwFExPMaRnRow6AAdegFzoxcrmGlvyG9nNFrbij 2ZPkUfEHbakKrKihW5wqxaYs/zSSjgoyF7f8MhIsNext/9JjGIEuqmMjbc+be0+c/zGF BZWjMue/8rbaaC2YSiTpfJ38LR1YRp/DezI3EiLrkd8OfhgWgejDMWA27YmclW1O7IH2 Au9xKgX6w4PYNfLWbM5OnMcThV11uQvJbGcBh/eSIQVCfT8PL9QnR07rbTC9Ic615Uf1 T2UTAF/4/DCoRDiT6F/KdF747151M8aXalr9FCmsSsqqtLiwx29h3LXwgh8F0imFc8mO Cvnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w7CAUcbHNUlb9vHqNp9A+duUWC5Q6Z8qpVcMw7sprD0=; b=fZdWRWr6ZYo30iVZOQYAwoV5SfGrilAgvCpLgn1x91u7GFOk4eEIIpMZzbfS03OgRu 8ziCMTrFMa0BdQRDk+HhuS85CQgjZOQlQxB7onZWSBj55/J28a18T6VMYqbA8obztnPu k9rCrm/hSMtzh3Es1JU/d+QjVuTbibDzSNKLmTz0D7Elezq58DbJSd3jPIl1LcDH2X1h Ohx2THoAe/5V+pddo7DhAwM3+fhjEHn8b7XzTcyOQs7OlLd9PwlYBWl5T0F6bfBRMy6I A8MAydyX8Prsl8T4wVY7qjWxZiGlFxbpIW0J30ywuksIja3kfRbthyjBmgi8EMwJsVyO Wcjw==
X-Gm-Message-State: AODbwcCEGprwFxoq8ev4HnxEq3VXnVip4xtbF9/4a6uiwze7kAg73Nxx oMNFCUd6lT/b2eiIEb3YA3fKQVsESNXc
X-Received: by 10.55.138.1 with SMTP id m1mr23911713qkd.270.1495487984894; Mon, 22 May 2017 14:19:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Mon, 22 May 2017 14:19:44 -0700 (PDT)
In-Reply-To: 
References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com>              
From: Tom Herbert 
Date: Mon, 22 May 2017 14:19:44 -0700
Message-ID: 
Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
To: Ron Bonica 
Cc: Mark Smith , "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 21:19:47 -0000

On Mon, May 22, 2017 at 11:47 AM, Ron Bonica  wrote:
> Hi Tom,
>
> This raises the salient question. When the source IP stack receives a message informing it that HTL has been exceeded, what should it do?
>
> When the source IP stack receives an ICMP PTB message, the required action is well-understood. It should:
>
> - update its estimate of the PMTU associated with the destination of the original packet
> - inform a higher layer protocol if appropriate
> - refrain from sending messages that exceed the PMTU in the future
>
> When the source IP stack receives a message informing it of a HTL violation, what should it do?
>
I think the response would be similar to that described in section 4.
The error should at least be logged and the higher layer protocol
informed. If possible, the headers can be reduced but there is no
deterministic way to do that. It's possible that it was an
encapsulation header that put things over the edge, so if the ICMP
error is received by the encapsulator it's possible that those headers
could be trimmed (for instance be withhold some unnecessary options in
an extensible encapsulation).

Tom

>                                                                     Ron
>
>
>> I don't think HTL should qualify for that special status. The difference
>> between PTB and HTL is the response the sending host(s) take. For PTB the
>> response is deterministic, the sending application should lower its PMTU. But
>> handling of HTL is not deterministic, it may or may not be feasible to reduce
>> headers to fit. The response to HTL might be more on the administrative side
>> like other destination unreachable errors.
>>
>


From nobody Tue May 23 00:51:37 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E322C12954D for ; Tue, 23 May 2017 00:51:35 -0700 (PDT)
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 3Uat9dzGwolp for ; Tue, 23 May 2017 00:51:32 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id AAF2512953B for ; Tue, 23 May 2017 00:51:32 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 9DF271B0172C; Tue, 23 May 2017 10:45:54 +0100 (BST)
Message-ID: <5923E9E2.8010602@erg.abdn.ac.uk>
Date: Tue, 23 May 2017 08:50:58 +0100
From: Gorry Fairhurst 
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Mirja Kuehlewind (IETF)" 
CC: ipv6@ietfa.amsl.com
Subject: Re: DISCUSS's on rfc1981bis - MK Comments
References:  <5911B0EE.6080802@erg.abdn.ac.uk>  <59205C94.30200@erg.abdn.ac.uk> <52A24ADC-8D1D-47DA-ADC8-21D30C09D49E@kuehlewind.net> <589a1f5a-8ce8-d484-9083-5eaedee3f5ff@erg.abdn.ac.uk> <97E22E2E-33E1-45A1-94E3-82FE35D1BDDB@kuehlewind.net> <64a06a7f-3d3e-dde6-7373-e104dfc04272@erg.abdn.ac.uk> <508AA18F-0790-4167-A54F-9F3E8B051229@kuehlewind.net>
In-Reply-To: <508AA18F-0790-4167-A54F-9F3E8B051229@kuehlewind.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 07:51:36 -0000

Here is my proposed replacement text, it focusses on retransmission, because other clauses deal with otehr aspects of handling PTB:

"Note: A packetization layer that determines a probe packet is lost, needs to avoid retranmission using a packet size that may induce multiple retransmission. This could occur if it retransmitted the data segmented into packets of the size reported in the last Packet Too Big message and there were several successively smaller PMTU limits at the routers along the path. The resulting sequence of probe packets would require multiple retransmissions (with retransmitted probes also dropped by a router later along the path), with unecessary delay of the data and transmission of superfluous packets that contribute to the network load under congestion. Any packetization layer that uses retransmission is therefore also responsible for congestion contol of its retransmissions [RFC8085]."


Gorry

On 22/05/2017, 16:02, Mirja Kuehlewind (IETF) wrote:
> Yes, please propose new text.
>
>> Am 22.05.2017 um 17:01 schrieb Gorry Fairhurst:
>>
>> On 22/05/2017 15:31, Mirja Kuehlewind (IETF) wrote:
>>> Hi Gorry,
>>>
>>> thanks for the example below. Now I understand. My thinking was that you could also just retransmit the first segment in response to the packet too big message with the new indicated packet size and hold the rest of the to-be-retransmitted packet for later when the MTU probing is terminated. However, the point here is actually not about retransmitting. I guess what you actually need to say is that you should only send one MTU probe at a time. So if you want to retransmit all segments at once you need to use the confirmed PMTU that was used before the probing started, right?
>>>
>>> Mirja
>>>
>> OK - I also don't particularly mind if we change the text.
>>
>> I'd suggest not even retransmitting the probe packet as another probe (if this data needs to be sent reliably). If there is more data, that later data can be used for the probe, I think there is really no need to hurry this procedure be vulnerable to multiple losses and re-transmits.
>>
>> So, without trying to sketch a definition of a method - which I think is outside of the spirit of this update, can we simply identify what is the key thing to highlight?
>>
>> Gorry
>>
>>>> Am 22.05.2017 um 13:17 schrieb Gorry Fairhurst:
>>>>
>>>> On 22/05/2017 10:49, Mirja Kuehlewind (IETF) wrote:
>>>>> See below.
>>>>>
>>>>>
>>>>>> Am 20.05.2017 um 17:11 schrieb Gorry Fairhurst:
>>>>>>
>>>>>> On 19/05/2017, 15:51, Mirja Kuehlewind (IETF) wrote:
>>>>>>> Hi Gorry, hi all,
>>>>>>>
>>>>>>> thanks for the work and the update. All comments from Gorry seemed fine to me and I will try to review the changes in the updated doc soon. One more minor comment on this:
>>>>>>>
>>>>>>>> Am 09.05.2017 um 08:07 schrieb Gorry Fairhurst:
>>>>>>>>
>>>>>>>>> I don't understand the following paragraph. Can this be removed?
>>>>>>>>> "Note: A packetization layer must not retransmit in response to
>>>>>>>>> every Packet Too Big message, since a burst of several oversized
>>>>>>>>> segments will give rise to several such messages and hence several
>>>>>>>>> retransmissions of the same data. If the new estimated PMTU is
>>>>>>>>> still wrong, the process repeats, and there is an exponential
>>>>>>>>> growth in the number of superfluous segments sent."
>>>>>>>>>
>>>>>>>> GF: I think the example is important. I'm not sure why that would be removed.
>>>>>>> The problem is I don’t understand this example. Is there an assumption that all mtu probe packets have been ‚generated‘ on the same packet? If so that makes sense but must the spelled out somewhere!
>>>>>>>
>>>>>>> Mirja
>>>>>>>
>>>>>>>
>>>>>> I think the wording is maybe jumbled, but the point is OK. Perhaps something like this would be clearer?
>>>>>>
>>>>>> "Note: A packetization layer ought to avoid retransmitting the data in a probe packet
>>>>>> using the size reported in the last Packet Too Big message.
>>>>>> This is to avoid an exponential growth in the number of superfluous segments
>>>>>> that would be sent when a path encounters several successive smaller PMTU limits.
>>>>>> (Each new estimated PMTU would result in retransmission of the data in a smaller
>>>>>> packet that may itself fail if it encounters a still smaller PMTU in a device further
>>>>>> along the same path)."
>>>>>>
>>>>>> Gorry
>>>>>>
>>>>> I still don’t get it. Each time a packet is dropped, you have to
>>>>> retransmit it (if your transport is reliable)
>>>>> because otherwise the other end will not have it.
>>>>>
>>>> Sure. this says nothing about how you find out what segments need to
>>>> be retransmit, only about the *SIZE* of the packets you use to perform that transmission.
>>>>>
>>>>> I also still don’t see how there can be an exponential grows.
>>>>>
>>>>>
>>>>> Sorry if I miss something but maybe you can explain again this case using different words…?
>>>>>
>>>>> Mirja
>>>>>
>>>>
>>>> Before I try different words, we should make sure the topic is understood.
>>>>
>>>> Suppose we wish to send a probe for 8KB, and suppose the path supports
>>>> 3 router MTU sizes: a hop with 4KB MTU and then a later hop with 2KB MTU, and finally one of just 1400B.
>>>>
>>>> Largest probe size = 8KB
>>>>
>>>> The first probe sends 8KB as the Segment Size
>>>> ->------------------------------X
>>>> Dropped by first router along path.
>>>> In example case PTB indicates next hop =  4KB.
>>>> Data not reliably sent.
>>>>
>>>> Largest probe size = 4KB
>>>>
>>>> Retransmit 2 packet for same segment of data, each size 4KB
>>>> ------------->------------------------------X
>>>> ------------->------------------------------X
>>>> Dropped by router later along path.
>>>> In example case PTB indicates next hop =  2KB.
>>>> Data still not reliably sent.
>>>>
>>>> Largest probe size = 2KB
>>>>
>>>> Retransmit 4 packets for same segment of data.
>>>> In example case PTB indicates next hop =  1400B.
>>>> Data still not reliably sent.
>>>> ------------->------------------------------>---X
>>>> ------------->------------------------------>---X
>>>> ------------->------------------------------>---X
>>>> ------------->------------------------------>---X
>>>>
>>>> Largest probe size = 1400B
>>>>
>>>> Data finally transmitted in 6 packets all less than PMTU.
>>>> ------------->------------------------------>-------------->
>>>> ------------->------------------------------>-------------->
>>>> ------------->------------------------------>-------------->
>>>> ------------->------------------------------>-------------->
>>>> ------------->------------------------------>-------------->
>>>> ------------->------------------------------>-------------->
>>>>
>>>> All data delivered. PMTU=1400B is confirmed.
>>>>
>>>> Total sent packets = 13 packets
>>>> No of re-transmissions = 7 (6 failed re-transmissions in 3 re-transmission attempts)
>>>>
>>>> Now let's try a method that heeds the warning in the text and re-transmits the probe data using a "safe: MTU:
>>>>
>>>> The first probe sends 8KB as the Segment Size
>>>> ->------------------------------X
>>>>
>>>> Dropped by first router along path.
>>>> In example case PTB indicates next hop =  4KB.
>>>> Data not reliably sent.
>>>>
>>>> Largest probe size = 4KB
>>>>
>>>> Sender resends the 8KB segment using a known workable PMTU (in the above 1500B, if that were cached, or even 1280B.
>>>>
>>>> ------------->------------------------------>-------------->
>>>> ------------->------------------------------>-------------->
>>>> ------------->------------------------------>-------------->
>>>> ------------->------------------------------>-------------->
>>>> ------------->------------------------------>-------------->
>>>> ------------->------------------------------>-------------->
>>>>
>>>> Total sent packets = 7 packets
>>>> No of re-transmissions = 6 (all successful, 1 re-transmission)
>>>>
>>>> And afterwards separately resend a single probe packet to detect a the largest PMTU using the 4KB probe.
>>>>
>>>> Obviously, there are many combinations of paths, and not all cases lead
>>>> to exponential growth, but all cases lead to multiple probes, and
>>>> multiple re-transmissions.
>>>>
>>>> Gorry


From nobody Tue May 23 04:20:45 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BB2129ACD for ; Tue, 23 May 2017 04:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 DhyfFnGaX4JM for ; Tue, 23 May 2017 04:20:41 -0700 (PDT)
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 8B29E129AB7 for ; Tue, 23 May 2017 04:20:40 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net;  b=pRVbodmaYhz9O6KKnX/p2lA07Qn7jPJPjmcOhK1N+08sWNC0QFAgockssawTAdRsJhXn2psGW/L65dHqF/2xpNEnpul9SsnPu2a/U7ul037VhEvgcmkto+iVcCJPyJCcIWBqEsR1lvb23M9+IXm8RV3qxqKkNDmtY6xzKeUZUE0=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 13368 invoked from network); 23 May 2017 13:20:38 +0200
Received: from p5dec2002.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.32.2) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 23 May 2017 13:20:38 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: DISCUSS's on rfc1981bis - MK Comments
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: <5923E9E2.8010602@erg.abdn.ac.uk>
Date: Tue, 23 May 2017 13:20:35 +0200
Cc: ipv6@ietfa.amsl.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <848EF662-2CAF-445D-9709-5EFC88251ABD@kuehlewind.net>
References:  <5911B0EE.6080802@erg.abdn.ac.uk>  <59205C94.30200@erg.abdn.ac.uk> <52A24ADC-8D1D-47DA-ADC8-21D30C09D49E@kuehlewind.net> <589a1f5a-8ce8-d484-9083-5eaedee3f5ff@erg.abdn.ac.uk> <97E22E2E-33E1-45A1-94E3-82FE35D1BDDB@kuehlewind.net> <64a06a7f-3d3e-dde6-7373-e104dfc04272@erg.abdn.ac.uk> <508AA18F-0790-4167-A54F-9F3E8B051229@kuehlewind.net> <5923E9E2.8010602@erg.abdn.ac.uk>
To: gorry@erg.abdn.ac.uk
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20170523112038.13363.98590@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 11:20:43 -0000

Hi Gorry,

my thinking was that the IP layer should actually not indicate a new =
PMTU until the probing is completed and as such only probing packets =
should have a larger size than indicated by the current PMTU. However, I =
actually don=E2=80=99t know how this is implemented in reality.

I think the text below from you is better but now that I understand what =
it wants to say, I can understand it but I'm still not sure if it=E2=80=99=
s otherwise clear. Let me give a try:

"A packetization layer that determines a probe packet is lost, needs to =
adapt the segment size of the retransmission. Using the reported size in =
the last Packet Too Big message, however, can lead to further losses as =
there might be smaller PMTU limits at the routers further along the =
path. This would lead to loss of all retransmitted segments and =
therefore cause unnecessary congestion and amplification each time a new =
router announces a smaller MTU. The packetization layer therefore should =
not send any packets with a new PMTU that do not belong to the probing =
itself until the probing is completed and at least one packet with the =
new PMTU was successfully received at the other end. During the probing =
phase the packetization layer should either continue to use the previous =
PMTU or the minimum PMTU for all packet that are not probe packets, =
including retransmissions.=E2=80=9C

I guess we could even use SHOULD and SHOULD NOT=E2=80=A6?

What do you think?

Mirja

> Am 23.05.2017 um 09:50 schrieb Gorry Fairhurst :
>=20
> Here is my proposed replacement text, it focusses on retransmission, =
because other clauses deal with otehr aspects of handling PTB:
>=20
> "Note: A packetization layer that determines a probe packet is lost, =
needs to avoid retranmission using a packet size that may induce =
multiple retransmission. This could occur if it retransmitted the data =
segmented into packets of the size reported in the last Packet Too Big =
message and there were several successively smaller PMTU limits at the =
routers along the path. The resulting sequence of probe packets would =
require multiple retransmissions (with retransmitted probes also dropped =
by a router later along the path), with unecessary delay of the data and =
transmission of superfluous packets that contribute to the network load =
under congestion. Any packetization layer that uses retransmission is =
therefore also responsible for congestion contol of its retransmissions =
[RFC8085]."
>=20
>=20
> Gorry
>=20
> On 22/05/2017, 16:02, Mirja Kuehlewind (IETF) wrote:
>> Yes, please propose new text.
>>=20
>>> Am 22.05.2017 um 17:01 schrieb Gorry =
Fairhurst:
>>>=20
>>> On 22/05/2017 15:31, Mirja Kuehlewind (IETF) wrote:
>>>> Hi Gorry,
>>>>=20
>>>> thanks for the example below. Now I understand. My thinking was =
that you could also just retransmit the first segment in response to the =
packet too big message with the new indicated packet size and hold the =
rest of the to-be-retransmitted packet for later when the MTU probing is =
terminated. However, the point here is actually not about =
retransmitting. I guess what you actually need to say is that you should =
only send one MTU probe at a time. So if you want to retransmit all =
segments at once you need to use the confirmed PMTU that was used before =
the probing started, right?
>>>>=20
>>>> Mirja
>>>>=20
>>> OK - I also don't particularly mind if we change the text.
>>>=20
>>> I'd suggest not even retransmitting the probe packet as another =
probe (if this data needs to be sent reliably). If there is more data, =
that later data can be used for the probe, I think there is really no =
need to hurry this procedure be vulnerable to multiple losses and =
re-transmits.
>>>=20
>>> So, without trying to sketch a definition of a method - which I =
think is outside of the spirit of this update, can we simply identify =
what is the key thing to highlight?
>>>=20
>>> Gorry
>>>=20
>>>>> Am 22.05.2017 um 13:17 schrieb Gorry =
Fairhurst:
>>>>>=20
>>>>> On 22/05/2017 10:49, Mirja Kuehlewind (IETF) wrote:
>>>>>> See below.
>>>>>>=20
>>>>>>=20
>>>>>>> Am 20.05.2017 um 17:11 schrieb Gorry =
Fairhurst:
>>>>>>>=20
>>>>>>> On 19/05/2017, 15:51, Mirja Kuehlewind (IETF) wrote:
>>>>>>>> Hi Gorry, hi all,
>>>>>>>>=20
>>>>>>>> thanks for the work and the update. All comments from Gorry =
seemed fine to me and I will try to review the changes in the updated =
doc soon. One more minor comment on this:
>>>>>>>>=20
>>>>>>>>> Am 09.05.2017 um 08:07 schrieb Gorry =
Fairhurst:
>>>>>>>>>=20
>>>>>>>>>> I don't understand the following paragraph. Can this be =
removed?
>>>>>>>>>> "Note: A packetization layer must not retransmit in response =
to
>>>>>>>>>> every Packet Too Big message, since a burst of several =
oversized
>>>>>>>>>> segments will give rise to several such messages and hence =
several
>>>>>>>>>> retransmissions of the same data. If the new estimated PMTU =
is
>>>>>>>>>> still wrong, the process repeats, and there is an exponential
>>>>>>>>>> growth in the number of superfluous segments sent."
>>>>>>>>>>=20
>>>>>>>>> GF: I think the example is important. I'm not sure why that =
would be removed.
>>>>>>>> The problem is I don=E2=80=99t understand this example. Is =
there an assumption that all mtu probe packets have been =E2=80=9Agenerate=
d=E2=80=98 on the same packet? If so that makes sense but must the =
spelled out somewhere!
>>>>>>>>=20
>>>>>>>> Mirja
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> I think the wording is maybe jumbled, but the point is OK. =
Perhaps something like this would be clearer?
>>>>>>>=20
>>>>>>> "Note: A packetization layer ought to avoid retransmitting the =
data in a probe packet
>>>>>>> using the size reported in the last Packet Too Big message.
>>>>>>> This is to avoid an exponential growth in the number of =
superfluous segments
>>>>>>> that would be sent when a path encounters several successive =
smaller PMTU limits.
>>>>>>> (Each new estimated PMTU would result in retransmission of the =
data in a smaller
>>>>>>> packet that may itself fail if it encounters a still smaller =
PMTU in a device further
>>>>>>> along the same path)."
>>>>>>>=20
>>>>>>> Gorry
>>>>>>>=20
>>>>>> I still don=E2=80=99t get it. Each time a packet is dropped, you =
have to
>>>>>> retransmit it (if your transport is reliable)
>>>>>> because otherwise the other end will not have it.
>>>>>>=20
>>>>> Sure. this says nothing about how you find out what segments need =
to
>>>>> be retransmit, only about the *SIZE* of the packets you use to =
perform that transmission.
>>>>>>=20
>>>>>> I also still don=E2=80=99t see how there can be an exponential =
grows.
>>>>>>=20
>>>>>>=20
>>>>>> Sorry if I miss something but maybe you can explain again this =
case using different words=E2=80=A6?
>>>>>>=20
>>>>>> Mirja
>>>>>>=20
>>>>>=20
>>>>> Before I try different words, we should make sure the topic is =
understood.
>>>>>=20
>>>>> Suppose we wish to send a probe for 8KB, and suppose the path =
supports
>>>>> 3 router MTU sizes: a hop with 4KB MTU and then a later hop with =
2KB MTU, and finally one of just 1400B.
>>>>>=20
>>>>> Largest probe size =3D 8KB
>>>>>=20
>>>>> The first probe sends 8KB as the Segment Size
>>>>> ->------------------------------X
>>>>> Dropped by first router along path.
>>>>> In example case PTB indicates next hop =3D  4KB.
>>>>> Data not reliably sent.
>>>>>=20
>>>>> Largest probe size =3D 4KB
>>>>>=20
>>>>> Retransmit 2 packet for same segment of data, each size 4KB
>>>>> ------------->------------------------------X
>>>>> ------------->------------------------------X
>>>>> Dropped by router later along path.
>>>>> In example case PTB indicates next hop =3D  2KB.
>>>>> Data still not reliably sent.
>>>>>=20
>>>>> Largest probe size =3D 2KB
>>>>>=20
>>>>> Retransmit 4 packets for same segment of data.
>>>>> In example case PTB indicates next hop =3D  1400B.
>>>>> Data still not reliably sent.
>>>>> ------------->------------------------------>---X
>>>>> ------------->------------------------------>---X
>>>>> ------------->------------------------------>---X
>>>>> ------------->------------------------------>---X
>>>>>=20
>>>>> Largest probe size =3D 1400B
>>>>>=20
>>>>> Data finally transmitted in 6 packets all less than PMTU.
>>>>> ------------->------------------------------>-------------->
>>>>> ------------->------------------------------>-------------->
>>>>> ------------->------------------------------>-------------->
>>>>> ------------->------------------------------>-------------->
>>>>> ------------->------------------------------>-------------->
>>>>> ------------->------------------------------>-------------->
>>>>>=20
>>>>> All data delivered. PMTU=3D1400B is confirmed.
>>>>>=20
>>>>> Total sent packets =3D 13 packets
>>>>> No of re-transmissions =3D 7 (6 failed re-transmissions in 3 =
re-transmission attempts)
>>>>>=20
>>>>> Now let's try a method that heeds the warning in the text and =
re-transmits the probe data using a "safe: MTU:
>>>>>=20
>>>>> The first probe sends 8KB as the Segment Size
>>>>> ->------------------------------X
>>>>>=20
>>>>> Dropped by first router along path.
>>>>> In example case PTB indicates next hop =3D  4KB.
>>>>> Data not reliably sent.
>>>>>=20
>>>>> Largest probe size =3D 4KB
>>>>>=20
>>>>> Sender resends the 8KB segment using a known workable PMTU (in the =
above 1500B, if that were cached, or even 1280B.
>>>>>=20
>>>>> ------------->------------------------------>-------------->
>>>>> ------------->------------------------------>-------------->
>>>>> ------------->------------------------------>-------------->
>>>>> ------------->------------------------------>-------------->
>>>>> ------------->------------------------------>-------------->
>>>>> ------------->------------------------------>-------------->
>>>>>=20
>>>>> Total sent packets =3D 7 packets
>>>>> No of re-transmissions =3D 6 (all successful, 1 re-transmission)
>>>>>=20
>>>>> And afterwards separately resend a single probe packet to detect a =
the largest PMTU using the 4KB probe.
>>>>>=20
>>>>> Obviously, there are many combinations of paths, and not all cases =
lead
>>>>> to exponential growth, but all cases lead to multiple probes, and
>>>>> multiple re-transmissions.
>>>>>=20
>>>>> Gorry
>=20


From nobody Tue May 23 06:34:19 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDA7129B48 for ; Tue, 23 May 2017 06:34:17 -0700 (PDT)
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 Hgng5rROAtWf for ; Tue, 23 May 2017 06:34:14 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1516B129B41 for ; Tue, 23 May 2017 06:34:14 -0700 (PDT)
Received: from dhcp-207-152.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:1109:bb5f:dce4:5770]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id E0E0D1B0176D; Tue, 23 May 2017 16:29:07 +0100 (BST)
Reply-To: gorry@erg.abdn.ac.uk
Subject: Re: DISCUSS's on rfc1981bis - MK Comments
References:  <5911B0EE.6080802@erg.abdn.ac.uk>  <59205C94.30200@erg.abdn.ac.uk> <52A24ADC-8D1D-47DA-ADC8-21D30C09D49E@kuehlewind.net> <589a1f5a-8ce8-d484-9083-5eaedee3f5ff@erg.abdn.ac.uk> <97E22E2E-33E1-45A1-94E3-82FE35D1BDDB@kuehlewind.net> <64a06a7f-3d3e-dde6-7373-e104dfc04272@erg.abdn.ac.uk> <508AA18F-0790-4167-A54F-9F3E8B051229@kuehlewind.net> <5923E9E2.8010602@erg.abdn.ac.uk> <848EF662-2CAF-445D-9709-5EFC88251ABD@kuehlewind.net>
To: "Mirja Kuehlewind (IETF)" 
Cc: ipv6@ietfa.amsl.com
From: Gorry Fairhurst 
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683.
Message-ID: <443f9468-a777-884f-90f6-eabc95e11fc6@erg.abdn.ac.uk>
Date: Tue, 23 May 2017 14:34:12 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <848EF662-2CAF-445D-9709-5EFC88251ABD@kuehlewind.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 13:34:18 -0000

See below...

On 23/05/2017 12:20, Mirja Kuehlewind (IETF) wrote:
> Hi Gorry,
>
> my thinking was that the IP layer should actually not indicate a new PMTU until the probing is completed and as such only probing packets should have a larger size than indicated by the current PMTU. However, I actually don’t know how this is implemented in reality.
>
> I think the text below from you is better but now that I understand what it wants to say, I can understand it but I'm still not sure if it’s otherwise clear. Let me give a try:
>
> "A packetization layer that determines a probe packet is lost, needs to adapt the segment size of the retransmission. Using the reported size in the last Packet Too Big message, however, can lead to further losses as there might be smaller PMTU limits at the routers further along the path. This would lead to loss of all retransmitted segments and therefore cause unnecessary congestion and amplification each time a new router announces a smaller MTU. The packetization layer therefore should not send any packets with a new PMTU that do not belong to the probing itself until the probing is completed and at least one packet with the new PMTU was successfully received at the other end. During the probing phase the packetization layer should either continue to use the previous PMTU or the minimum PMTU for all packet that are not probe packets, including retransmissions.“
>
> I guess we could even use SHOULD and SHOULD NOT…?
>
> What do you think?
>
This starts good:

 >"A packetization layer that determines a probe packet is lost,
 >needs to adapt the segment size of the retransmission.
 >Using the reported size in the last Packet Too Big message,
 >however, can lead to further losses as there might be smaller
 >PMTU limits at the routers further along the path.
 >This would lead to loss of all retransmitted segments
 >and therefore cause unnecessary congestion and amplification each time
 > a new router announces a smaller MTU.

- Up to here, I agree, amplification may not be completely clear to a 
reader, could we say something like additional packets (or something?)


Then, the text now starts to prescribe how to do this:

 > The packetization layer therefore should not send any packets
 > with a new PMTU that do not belong to the probing itself
 > until the probing is completed and at least one packet with
 > the new PMTU was successfully received at the other end.

- This sounds rather like an algorithm, possibly
one that is based PLMTUD, and I'd rather not venture into how this is 
implemented.

 > During the probing phase the packetization layer should
 > either continue to use the previous PMTU or the minimum
 > PMTU for all packets that are not probe packets,
 > including retransmissions.“

- I don't really have a concept of a "probing phase"...
and "previous PMTU" is slightly problematic, in that the
cause of the PTB message may have been a path MTU reduction.
My concern is that this starts to explain a new algorithm.

I think it's still worth citing RFC8085, since it's
predominately UDP Apps that need to roll their own
PMTU discovery.

Gorry

> Mirja
>
>> Am 23.05.2017 um 09:50 schrieb Gorry Fairhurst :
>>
>> Here is my proposed replacement text, it focusses on retransmission, because other clauses deal with other aspects of handling PTB:
>>
>> "Note: A packetization layer that determines a probe packet is lost, needs to avoid retranmission using a packet size that may induce multiple retransmission. This could occur if it retransmitted the data segmented into packets of the size reported in the last Packet Too Big message and there were several successively smaller PMTU limits at the routers along the path. The resulting sequence of probe packets would require multiple retransmissions (with retransmitted probes also dropped by a router later along the path), with unecessary delay of the data and transmission of superfluous packets that contribute to the network load under congestion. Any packetization layer that uses retransmission is therefore also responsible for congestion contol of its retransmissions [RFC8085]."
>>
>>
>> Gorry
>>
>> On 22/05/2017, 16:02, Mirja Kuehlewind (IETF) wrote:
>>> Yes, please propose new text.
>>>
>>>> Am 22.05.2017 um 17:01 schrieb Gorry Fairhurst:
>>>>
>>>> On 22/05/2017 15:31, Mirja Kuehlewind (IETF) wrote:
>>>>> Hi Gorry,
>>>>>
>>>>> thanks for the example below. Now I understand. My thinking was that you could also just retransmit the first segment in response to the packet too big message with the new indicated packet size and hold the rest of the to-be-retransmitted packet for later when the MTU probing is terminated. However, the point here is actually not about retransmitting. I guess what you actually need to say is that you should only send one MTU probe at a time. So if you want to retransmit all segments at once you need to use the confirmed PMTU that was used before the probing started, right?
>>>>>
>>>>> Mirja
>>>>>
>>>> OK - I also don't particularly mind if we change the text.
>>>>
>>>> I'd suggest not even retransmitting the probe packet as another probe (if this data needs to be sent reliably). If there is more data, that later data can be used for the probe, I think there is really no need to hurry this procedure be vulnerable to multiple losses and re-transmits.
>>>>
>>>> So, without trying to sketch a definition of a method - which I think is outside of the spirit of this update, can we simply identify what is the key thing to highlight?
>>>>
>>>> Gorry
>>>>
>>>>>> Am 22.05.2017 um 13:17 schrieb Gorry Fairhurst:
>>>>>>
>>>>>> On 22/05/2017 10:49, Mirja Kuehlewind (IETF) wrote:
>>>>>>> See below.
>>>>>>>
>>>>>>>
>>>>>>>> Am 20.05.2017 um 17:11 schrieb Gorry Fairhurst:
>>>>>>>>
>>>>>>>> On 19/05/2017, 15:51, Mirja Kuehlewind (IETF) wrote:
>>>>>>>>> Hi Gorry, hi all,
>>>>>>>>>
>>>>>>>>> thanks for the work and the update. All comments from Gorry seemed fine to me and I will try to review the changes in the updated doc soon. One more minor comment on this:
>>>>>>>>>
>>>>>>>>>> Am 09.05.2017 um 08:07 schrieb Gorry Fairhurst:
>>>>>>>>>>
>>>>>>>>>>> I don't understand the following paragraph. Can this be removed?
>>>>>>>>>>> "Note: A packetization layer must not retransmit in response to
>>>>>>>>>>> every Packet Too Big message, since a burst of several oversized
>>>>>>>>>>> segments will give rise to several such messages and hence several
>>>>>>>>>>> retransmissions of the same data. If the new estimated PMTU is
>>>>>>>>>>> still wrong, the process repeats, and there is an exponential
>>>>>>>>>>> growth in the number of superfluous segments sent."
>>>>>>>>>>>
>>>>>>>>>> GF: I think the example is important. I'm not sure why that would be removed.
>>>>>>>>> The problem is I don’t understand this example. Is there an assumption that all mtu probe packets have been ‚generated‘ on the same packet? If so that makes sense but must the spelled out somewhere!
>>>>>>>>>
>>>>>>>>> Mirja
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I think the wording is maybe jumbled, but the point is OK. Perhaps something like this would be clearer?
>>>>>>>>
>>>>>>>> "Note: A packetization layer ought to avoid retransmitting the data in a probe packet
>>>>>>>> using the size reported in the last Packet Too Big message.
>>>>>>>> This is to avoid an exponential growth in the number of superfluous segments
>>>>>>>> that would be sent when a path encounters several successive smaller PMTU limits.
>>>>>>>> (Each new estimated PMTU would result in retransmission of the data in a smaller
>>>>>>>> packet that may itself fail if it encounters a still smaller PMTU in a device further
>>>>>>>> along the same path)."
>>>>>>>>
>>>>>>>> Gorry
>>>>>>>>
>>>>>>> I still don’t get it. Each time a packet is dropped, you have to
>>>>>>> retransmit it (if your transport is reliable)
>>>>>>> because otherwise the other end will not have it.
>>>>>>>
>>>>>> Sure. this says nothing about how you find out what segments need to
>>>>>> be retransmit, only about the *SIZE* of the packets you use to perform that transmission.
>>>>>>>
>>>>>>> I also still don’t see how there can be an exponential grows.
>>>>>>>
>>>>>>>
>>>>>>> Sorry if I miss something but maybe you can explain again this case using different words…?
>>>>>>>
>>>>>>> Mirja
>>>>>>>
>>>>>>
>>>>>> Before I try different words, we should make sure the topic is understood.
>>>>>>
>>>>>> Suppose we wish to send a probe for 8KB, and suppose the path supports
>>>>>> 3 router MTU sizes: a hop with 4KB MTU and then a later hop with 2KB MTU, and finally one of just 1400B.
>>>>>>
>>>>>> Largest probe size = 8KB
>>>>>>
>>>>>> The first probe sends 8KB as the Segment Size
>>>>>> ->------------------------------X
>>>>>> Dropped by first router along path.
>>>>>> In example case PTB indicates next hop =  4KB.
>>>>>> Data not reliably sent.
>>>>>>
>>>>>> Largest probe size = 4KB
>>>>>>
>>>>>> Retransmit 2 packet for same segment of data, each size 4KB
>>>>>> ------------->------------------------------X
>>>>>> ------------->------------------------------X
>>>>>> Dropped by router later along path.
>>>>>> In example case PTB indicates next hop =  2KB.
>>>>>> Data still not reliably sent.
>>>>>>
>>>>>> Largest probe size = 2KB
>>>>>>
>>>>>> Retransmit 4 packets for same segment of data.
>>>>>> In example case PTB indicates next hop =  1400B.
>>>>>> Data still not reliably sent.
>>>>>> ------------->------------------------------>---X
>>>>>> ------------->------------------------------>---X
>>>>>> ------------->------------------------------>---X
>>>>>> ------------->------------------------------>---X
>>>>>>
>>>>>> Largest probe size = 1400B
>>>>>>
>>>>>> Data finally transmitted in 6 packets all less than PMTU.
>>>>>> ------------->------------------------------>-------------->
>>>>>> ------------->------------------------------>-------------->
>>>>>> ------------->------------------------------>-------------->
>>>>>> ------------->------------------------------>-------------->
>>>>>> ------------->------------------------------>-------------->
>>>>>> ------------->------------------------------>-------------->
>>>>>>
>>>>>> All data delivered. PMTU=1400B is confirmed.
>>>>>>
>>>>>> Total sent packets = 13 packets
>>>>>> No of re-transmissions = 7 (6 failed re-transmissions in 3 re-transmission attempts)
>>>>>>
>>>>>> Now let's try a method that heeds the warning in the text and re-transmits the probe data using a "safe: MTU:
>>>>>>
>>>>>> The first probe sends 8KB as the Segment Size
>>>>>> ->------------------------------X
>>>>>>
>>>>>> Dropped by first router along path.
>>>>>> In example case PTB indicates next hop =  4KB.
>>>>>> Data not reliably sent.
>>>>>>
>>>>>> Largest probe size = 4KB
>>>>>>
>>>>>> Sender resends the 8KB segment using a known workable PMTU (in the above 1500B, if that were cached, or even 1280B.
>>>>>>
>>>>>> ------------->------------------------------>-------------->
>>>>>> ------------->------------------------------>-------------->
>>>>>> ------------->------------------------------>-------------->
>>>>>> ------------->------------------------------>-------------->
>>>>>> ------------->------------------------------>-------------->
>>>>>> ------------->------------------------------>-------------->
>>>>>>
>>>>>> Total sent packets = 7 packets
>>>>>> No of re-transmissions = 6 (all successful, 1 re-transmission)
>>>>>>
>>>>>> And afterwards separately resend a single probe packet to detect a the largest PMTU using the 4KB probe.
>>>>>>
>>>>>> Obviously, there are many combinations of paths, and not all cases lead
>>>>>> to exponential growth, but all cases lead to multiple probes, and
>>>>>> multiple re-transmissions.
>>>>>>
>>>>>> Gorry
>>
>


From nobody Tue May 23 12:26:53 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC0A12EAAF for ; Tue, 23 May 2017 12:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level: 
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=juniper.net
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 je1GhlGhhf-b for ; Tue, 23 May 2017 12:26:49 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0126.outbound.protection.outlook.com [104.47.41.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1880312EAA9 for <6man@ietf.org>; Tue, 23 May 2017 12:26:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JtdlCoYivRJfnGwPnBG2COdXJb2jRJUs0AueBShdtDw=; b=FOzrN0WF963lODUwIXqjCqRqfxFnN3wo91IarBTIzyK1xYvDG1n5d1H8uwKadxVquOTkwhLUf7i7uAnAr6wYKayYkpNBzu231U3D/aV5B7DiRlUaJpfAhw6c9aJqNWLm8RWNwCMDnrw/vkOkLjb07Y7suqZg7AN6FwX/Y8/HFac=
Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2049.namprd05.prod.outlook.com (10.164.23.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Tue, 23 May 2017 19:26:47 +0000
Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1124.007; Tue, 23 May 2017 19:26:46 +0000
From: Ron Bonica 
To: Tom Herbert 
CC: Mark Smith , "6man@ietf.org" <6man@ietf.org>
Subject: RE: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
Thread-Topic: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
Thread-Index: AQHSydvj2CNgsdR2N0SNyPfQvMZ6VaH1duKggAAhBwCAABvukIAAPKEAgAFC5PCAAEjSAIAB0s1wgAFOJoCAAs09sIAA13mAgAIxMBCAAB25AIAAMY+wgAAsPACAAWLH0A==
Date: Tue, 23 May 2017 19:26:46 +0000
Message-ID: 
References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com>               
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: herbertland.com; dkim=none (message not signed) header.d=none;herbertland.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2049; 7:eiMeFWv4kDbjT9Y/sSXDkh2PVvmD9epp1aVRgiazc1KQjsa14D+TWIadXYD1nl0WgM9DS15SL6rvliEfM875wXXCzrJT+HcBShQrO8mMcDQqQWcGKlCMSL/82PItw0u0dAAsg/LUt6Lqtoa5958wr/UZsZsOM0+BIolq2aPJe4P2+ycH+IB5r5MI5n7RhklT37bDdMzf9XLNrFoExNAQH6xJXExuMBcwaioyWU+GL5X5X6wKNR59ybicgTKGmvtFlOYc+2t/ntrOSOr6cOoyxskDpOyRwshRBB/WMVJGcyUzIJ+yZ6Y1/3tw8CncU6oApPbCcXc+5Pm+hvsEQeagyg==
x-ms-traffictypediagnostic: BLUPR0501MB2049:
x-ms-office365-filtering-correlation-id: 83d723e4-6a07-49e1-3f28-08d4a211a72d
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:BLUPR0501MB2049; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(6072148); SRVR:BLUPR0501MB2049; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2049; 
x-forefront-prvs: 0316567485
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39850400002)(39860400002)(39400400002)(39410400002)(13464003)(51444003)(377454003)(7696004)(102836003)(6116002)(305945005)(3846002)(54356999)(76176999)(50986999)(2950100002)(6916009)(551984002)(15650500001)(53546009)(4326008)(39060400002)(25786009)(2900100001)(9686003)(229853002)(77096006)(6436002)(5660300001)(54906002)(8676002)(53936002)(478600001)(81166006)(3280700002)(8936002)(6506006)(55016002)(99286003)(6246003)(38730400002)(110136004)(33656002)(230783001)(74316002)(2906002)(93886004)(3660700001)(7736002)(66066001)(189998001)(122556002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2049; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2017 19:26:46.6774 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2049
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 19:26:51 -0000

SGkgVG9tLA0KDQpJIHRoaW5rIHRoYXQgd2UgYXJlIGNvbnZlcmdpbmcuIFRoZSBQYXJhbWV0ZXIg
UHJvYmxlbSBtZXNzYWdlIGlzIGFwcHJvcHJpYXRlIGZvciB0aGUgZm9sbG93aW5nIGVycm9yIGNv
ZGVzOg0KDQogICAgICBDb2RlIA0KICAgICAgICAgMSAtIFVucmVjb2duaXplZCBOZXh0IEhlYWRl
ciB0eXBlIGVuY291bnRlcmVkDQogICAgICAgICA0IC0gRXh0ZW5zaW9uIGhlYWRlciB0b28gYmln
DQogICAgICAgICA1IC0gRXh0ZW5zaW9uIGhlYWRlciBjaGFpbiB0b28gbG9uZw0KICAgICAgICAg
NiAtIFRvbyBtYW55IG9wdGlvbnMgaW4gZXh0ZW5zaW9uIGhlYWRlcg0KDQpGb3IgZXJyb3IgY29k
ZXMgNCwgNSwgYW5kIDYsIHRoZSBwb2ludGVyIHNob3VsZCByZWZlcmVuY2UgdGhlIGZpcnN0ICpp
bnZhbGlkKiBieXRlLiBUaGlzIHdpbGwgYWxsb3cgdGhlIHNvdXJjZSBub2RlIHRvIGluZmVyOg0K
IA0KICAgICAgQ29kZQ0KICAgICAgICAgNCAtIFRoZSBtYXhpbXVtIGV4dGVuc2lvbiBoZWFkZXIg
bGVuZ3RoDQogICAgICAgICA1IC0gVGhlIG1heGltdW0gZXh0ZW5zaW9uIGhlYWRlciBjaGFpbiBs
ZW5ndGgNCiAgICAgICAgIDYgLSBUaGUgbWF4aW11bSBudW1iZXIgb2Ygb3B0aW9ucyBpbiB0aGUg
ZXh0ZW5zaW9uIGhlYWRlcg0KDQpFdmVuIHdoZW4gbm9uZSBvZiB0aGUgYWJvdmUtbWVudGlvbmVk
IGVycm9ycyBvY2N1ciwgYSBtaWRkbGUgYm94IG1heSBkaXNjYXJkIGEgcGFja2V0IGJlY2F1c2Ug
dGhlIFRvdGFsIEhlYWRlciBMZW5ndGggKFRITCkgaGFzIGJlZW4gZXhjZWVkZWQuIFRoZSB0b3Rh
bCBoZWFkZXIgbGVuZ3RoIGlzIHRoZSBzdW0gb2YgdGhlIElQdjYgaGVhZGVyIGxlbmd0aCwgdGhl
IElQdjYgZXh0ZW5zaW9uIGhlYWRlciBjaGFpbiBsZW5ndGggYW5kIHRoZSBlbmNhcHN1bGF0aW9u
IGhlYWRlci4NCg0KSW4gb3JkZXIgZm9yIHRoZSBtaWRkbGUtYm94IHRvIGluZm9ybSB0aGUgc291
cmNlIG9mIGEgVEhMIHZpb2xhdGlvbiwgaXQgY2FuIHNlbmQgZWl0aGVyOg0KDQotIGEgbmV3IElD
TVAgbWVzc2FnZQ0KLSBhIERlc3RpbmF0aW9uIFVucmVhY2hhYmxlIE1lc3NhZ2UNCg0KSSBoYXZl
IG5vIHByZWZlcmVuY2UuIA0KDQpIb3dldmVyLCBpZiB5b3UgY2hvb3NlLCB0aGUgRGVzdGluYXRp
b24gVW5yZWFjaGFibGUgbWVzc2FnZSwgeW91IHdpbGwgd2FudCB0byBpbmZvcm0gdGhlIHNvdXJj
ZSBvZiB0aGUgTWF4aW11bSBIZWFkZXIgTGVuZ3RoLiBSRkMgNDg4NCBwcm92aWRlcyBhIG1lY2hh
bmlzbSB0aGF0IHlvdSBjYW4gdXNlIHRvIHBpZ2d5YmFjayB0aGlzIGluZm9ybWF0aW9uIG9uIHRo
ZSBEZXN0aW5hdGlvbiB1bnJlYWNoYWJsZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJv
bg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRvbSBIZXJiZXJ0IFtt
YWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4gU2VudDogTW9uZGF5LCBNYXkgMjIsIDIwMTcg
NToyMCBQTQ0KPiBUbzogUm9uIEJvbmljYSA8cmJvbmljYUBqdW5pcGVyLm5ldD4NCj4gQ2M6IE1h
cmsgU21pdGggPG1hcmt6enpzbWl0aEBnbWFpbC5jb20+OyA2bWFuQGlldGYub3JnDQo+IFN1Ympl
Y3Q6IFJlOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhlcmJlcnQtNm1hbi1p
Y21wLWxpbWl0cy0NCj4gMDEudHh0DQo+IA0KDQo=


From nobody Wed May 24 08:49:01 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903561294EE for ; Wed, 24 May 2017 08:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 eKTBOxry_EN4 for ; Wed, 24 May 2017 08:48:56 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 6A7EC124D37 for ; Wed, 24 May 2017 08:48:56 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id z52so57617176wrc.2 for ; Wed, 24 May 2017 08:48:56 -0700 (PDT)
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=96rFa6N3s68cgxK1msnadZSWxFMNWFvql9dbFah2oR8=; b=GKKp5bURB0nvQue0kldp4qBj816hXHkcaYmI1LtvjyZMKEMEPXb+tizv3tyVeDo1Xc 6UD2lI1golHLvgwMF8DYLS9yaAqdEXUJkGMiFLg1Bil5UjPPksXwDeu43sDw0+5RhRmb 6ZLryqHRx05jBM0I9sJbTAY/hNh90tKiVIV+ifqGrrTFnA4IpSls3dA7OjC4fk85JsIZ ypE2NHMxvyhnemEU25D63c5JTij+KRJ/aadpAc+z/QJxzL1JgqICmWhcF6Aqvu7wqGxT uoe1t0FbKT4O4Zj1llZW6JGggBkUehfTiHkn2QZ/cLTHL9o1G4oonNInN6+jrntoQ5P8 lVFA==
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=96rFa6N3s68cgxK1msnadZSWxFMNWFvql9dbFah2oR8=; b=cgr3cM4JFz0i5l2EfkZQOsozONy/OpuJiIeiqPNBxA0pVJl83iGOSW7CAnN98wou95 7OEK9udOHTaQGBNACNrIr9bmMR9sO6mxk+wM3Rd8hQ3R8HeWs6KwyNSNT2wRKetcJ7ZB h7GQKC4mX/km6n9H6Zp41zdP8QB9XqvFQA7Pl0yFt1JxFxdpuOf9iciS0QNtwdaGJV3p Z/x8stHKb53UeFHZUkjp7MML4sEHgFln2rSJ/p767sVs7b2Ix5/V3dcJggPMpQ6OfmdZ v2UZgg4uRR0jX/XWiNbwpn0zDVjb6Q8YWysx4s7aRLuxJwBuKWxLTUazphTqJ14DW4TP hNKg==
X-Gm-Message-State: AODbwcDoDu5JL8tPgGRBgivq9/OIxbGOFCjwxIU/pjEVJxok0weL0eZx GrF3ZkcL1BM4Wg==
X-Received: by 10.223.174.200 with SMTP id y66mr24878774wrc.79.1495640934668;  Wed, 24 May 2017 08:48:54 -0700 (PDT)
Received: from ?IPv6:2601:647:4d01:db10:481f:4904:fd0b:216e? ([2601:647:4d01:db10:481f:4904:fd0b:216e]) by smtp.gmail.com with ESMTPSA id x9sm4276892wmb.21.2017.05.24.08.48.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 08:48:52 -0700 (PDT)
From: Bob Hinden 
Message-Id: <9F23AC7F-83FD-4441-9C94-EDF843670381@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_9182495A-C2E1-4DC2-981C-F01BD03A5867"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: DISCUSS's on rfc1981bis - MK Comments
Date: Wed, 24 May 2017 08:48:44 -0700
In-Reply-To: <443f9468-a777-884f-90f6-eabc95e11fc6@erg.abdn.ac.uk>
Cc: Bob Hinden , IPv6 List 
To: "Gorry (erg)" , "Mirja Kuehlewind (IETF)" 
References:  <5911B0EE.6080802@erg.abdn.ac.uk>  <59205C94.30200@erg.abdn.ac.uk> <52A24ADC-8D1D-47DA-ADC8-21D30C09D49E@kuehlewind.net> <589a1f5a-8ce8-d484-9083-5eaedee3f5ff@erg.abdn.ac.uk> <97E22E2E-33E1-45A1-94E3-82FE35D1BDDB@kuehlewind.net> <64a06a7f-3d3e-dde6-7373-e104dfc04272@erg.abdn.ac.uk> <508AA18F-0790-4167-A54F-9F3E8B051229@kuehlewind.net> <5923E9E2.8010602@erg.abdn.ac.uk> <848EF662-2CAF-445D-9709-5EFC88251ABD@kuehlewind.net> <443f9468-a777-884f-90f6-eabc95e11fc6@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 15:49:00 -0000

--Apple-Mail=_9182495A-C2E1-4DC2-981C-F01BD03A5867
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

> On May 23, 2017, at 6:34 AM, Gorry Fairhurst  =
wrote:
>=20
> See below...
>=20
> On 23/05/2017 12:20, Mirja Kuehlewind (IETF) wrote:
>> Hi Gorry,
>>=20
>> my thinking was that the IP layer should actually not indicate a new =
PMTU until the probing is completed and as such only probing packets =
should have a larger size than indicated by the current PMTU. However, I =
actually don=E2=80=99t know how this is implemented in reality.
>>=20
>> I think the text below from you is better but now that I understand =
what it wants to say, I can understand it but I'm still not sure if =
it=E2=80=99s otherwise clear. Let me give a try:
>>=20
>> "A packetization layer that determines a probe packet is lost, needs =
to adapt the segment size of the retransmission. Using the reported size =
in the last Packet Too Big message, however, can lead to further losses =
as there might be smaller PMTU limits at the routers further along the =
path. This would lead to loss of all retransmitted segments and =
therefore cause unnecessary congestion and amplification each time a new =
router announces a smaller MTU. The packetization layer therefore should =
not send any packets with a new PMTU that do not belong to the probing =
itself until the probing is completed and at least one packet with the =
new PMTU was successfully received at the other end. During the probing =
phase the packetization layer should either continue to use the previous =
PMTU or the minimum PMTU for all packet that are not probe packets, =
including retransmissions.=E2=80=9C
>>=20
>> I guess we could even use SHOULD and SHOULD NOT=E2=80=A6?
>>=20
>> What do you think?
>>=20
> This starts good:
>=20
> >"A packetization layer that determines a probe packet is lost,
> >needs to adapt the segment size of the retransmission.
> >Using the reported size in the last Packet Too Big message,
> >however, can lead to further losses as there might be smaller
> >PMTU limits at the routers further along the path.
> >This would lead to loss of all retransmitted segments
> >and therefore cause unnecessary congestion and amplification each =
time
> > a new router announces a smaller MTU.
>=20
> - Up to here, I agree, amplification may not be completely clear to a =
reader, could we say something like additional packets (or something?)

How about:

A packetization layer that determines a probe packet is lost,
needs to adapt the segment size of the retransmission.
Using the reported size in the last Packet Too Big message,
however, can lead to further losses as there might be smaller
PMTU limits at the routers further along the path.
This would lead to loss of all retransmitted segments
and therefore cause unnecessary congestion as well as additional
packets to be sent each time a new router announces a smaller MTU.


>=20
>=20
> Then, the text now starts to prescribe how to do this:
>=20
> > The packetization layer therefore should not send any packets
> > with a new PMTU that do not belong to the probing itself
> > until the probing is completed and at least one packet with
> > the new PMTU was successfully received at the other end.
>=20
> - This sounds rather like an algorithm, possibly
> one that is based PLMTUD, and I'd rather not venture into how this is =
implemented.
>=20
> > During the probing phase the packetization layer should
> > either continue to use the previous PMTU or the minimum
> > PMTU for all packets that are not probe packets,
> > including retransmissions.=E2=80=9C
>=20
> - I don't really have a concept of a "probing phase"...
> and "previous PMTU" is slightly problematic, in that the
> cause of the PTB message may have been a path MTU reduction.
> My concern is that this starts to explain a new algorithm.
>=20
> I think it's still worth citing RFC8085, since it's
> predominately UDP Apps that need to roll their own
> PMTU discovery.

So we could add (this was in an earlier version):

      Any packetization layer that uses
      retransmission is therefore also responsible for congestion
      control of its retransmissions [RFC8085].

The resulting text in Section 5.4, would be:

      Note: A packetization layer that determines a probe packet is
      lost, needs to adapt the segment size of the retransmission.
      Using the reported size in the last Packet Too Big message,
      however, can lead to further losses as there might be smaller PMTU
      limits at the routers further along the path.  This would lead to
      loss of all retransmitted segments and therefore cause unnecessary
      congestion as well as additional packets to be sent each time a
      new router announces a smaller MTU.  Any packetization layer that
      uses retransmission is therefore also responsible for congestion
      control of its retransmissions [RFC8085].

This would now describe the issue without getting into defining an =
algorithm.

Comments?

Bob


>=20
> Gorry
>=20
>> Mirja
>>=20
>>> Am 23.05.2017 um 09:50 schrieb Gorry Fairhurst =
:
>>>=20
>>> Here is my proposed replacement text, it focusses on retransmission, =
because other clauses deal with other aspects of handling PTB:
>>>=20
>>> "Note: A packetization layer that determines a probe packet is lost, =
needs to avoid retranmission using a packet size that may induce =
multiple retransmission. This could occur if it retransmitted the data =
segmented into packets of the size reported in the last Packet Too Big =
message and there were several successively smaller PMTU limits at the =
routers along the path. The resulting sequence of probe packets would =
require multiple retransmissions (with retransmitted probes also dropped =
by a router later along the path), with unecessary delay of the data and =
transmission of superfluous packets that contribute to the network load =
under congestion. Any packetization layer that uses retransmission is =
therefore also responsible for congestion contol of its retransmissions =
[RFC8085]."
>>>=20
>>>=20
>>> Gorry
>>>=20
>>> On 22/05/2017, 16:02, Mirja Kuehlewind (IETF) wrote:
>>>> Yes, please propose new text.
>>>>=20
>>>>> Am 22.05.2017 um 17:01 schrieb Gorry =
Fairhurst:
>>>>>=20
>>>>> On 22/05/2017 15:31, Mirja Kuehlewind (IETF) wrote:
>>>>>> Hi Gorry,
>>>>>>=20
>>>>>> thanks for the example below. Now I understand. My thinking was =
that you could also just retransmit the first segment in response to the =
packet too big message with the new indicated packet size and hold the =
rest of the to-be-retransmitted packet for later when the MTU probing is =
terminated. However, the point here is actually not about =
retransmitting. I guess what you actually need to say is that you should =
only send one MTU probe at a time. So if you want to retransmit all =
segments at once you need to use the confirmed PMTU that was used before =
the probing started, right?
>>>>>>=20
>>>>>> Mirja
>>>>>>=20
>>>>> OK - I also don't particularly mind if we change the text.
>>>>>=20
>>>>> I'd suggest not even retransmitting the probe packet as another =
probe (if this data needs to be sent reliably). If there is more data, =
that later data can be used for the probe, I think there is really no =
need to hurry this procedure be vulnerable to multiple losses and =
re-transmits.
>>>>>=20
>>>>> So, without trying to sketch a definition of a method - which I =
think is outside of the spirit of this update, can we simply identify =
what is the key thing to highlight?
>>>>>=20
>>>>> Gorry
>>>>>=20
>>>>>>> Am 22.05.2017 um 13:17 schrieb Gorry =
Fairhurst:
>>>>>>>=20
>>>>>>> On 22/05/2017 10:49, Mirja Kuehlewind (IETF) wrote:
>>>>>>>> See below.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> Am 20.05.2017 um 17:11 schrieb Gorry =
Fairhurst:
>>>>>>>>>=20
>>>>>>>>> On 19/05/2017, 15:51, Mirja Kuehlewind (IETF) wrote:
>>>>>>>>>> Hi Gorry, hi all,
>>>>>>>>>>=20
>>>>>>>>>> thanks for the work and the update. All comments from Gorry =
seemed fine to me and I will try to review the changes in the updated =
doc soon. One more minor comment on this:
>>>>>>>>>>=20
>>>>>>>>>>> Am 09.05.2017 um 08:07 schrieb Gorry =
Fairhurst:
>>>>>>>>>>>=20
>>>>>>>>>>>> I don't understand the following paragraph. Can this be =
removed?
>>>>>>>>>>>> "Note: A packetization layer must not retransmit in =
response to
>>>>>>>>>>>> every Packet Too Big message, since a burst of several =
oversized
>>>>>>>>>>>> segments will give rise to several such messages and hence =
several
>>>>>>>>>>>> retransmissions of the same data. If the new estimated PMTU =
is
>>>>>>>>>>>> still wrong, the process repeats, and there is an =
exponential
>>>>>>>>>>>> growth in the number of superfluous segments sent."
>>>>>>>>>>>>=20
>>>>>>>>>>> GF: I think the example is important. I'm not sure why that =
would be removed.
>>>>>>>>>> The problem is I don=E2=80=99t understand this example. Is =
there an assumption that all mtu probe packets have been =E2=80=9Agenerate=
d=E2=80=98 on the same packet? If so that makes sense but must the =
spelled out somewhere!
>>>>>>>>>>=20
>>>>>>>>>> Mirja
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>> I think the wording is maybe jumbled, but the point is OK. =
Perhaps something like this would be clearer?
>>>>>>>>>=20
>>>>>>>>> "Note: A packetization layer ought to avoid retransmitting the =
data in a probe packet
>>>>>>>>> using the size reported in the last Packet Too Big message.
>>>>>>>>> This is to avoid an exponential growth in the number of =
superfluous segments
>>>>>>>>> that would be sent when a path encounters several successive =
smaller PMTU limits.
>>>>>>>>> (Each new estimated PMTU would result in retransmission of the =
data in a smaller
>>>>>>>>> packet that may itself fail if it encounters a still smaller =
PMTU in a device further
>>>>>>>>> along the same path)."
>>>>>>>>>=20
>>>>>>>>> Gorry
>>>>>>>>>=20
>>>>>>>> I still don=E2=80=99t get it. Each time a packet is dropped, =
you have to
>>>>>>>> retransmit it (if your transport is reliable)
>>>>>>>> because otherwise the other end will not have it.
>>>>>>>>=20
>>>>>>> Sure. this says nothing about how you find out what segments =
need to
>>>>>>> be retransmit, only about the *SIZE* of the packets you use to =
perform that transmission.
>>>>>>>>=20
>>>>>>>> I also still don=E2=80=99t see how there can be an exponential =
grows.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Sorry if I miss something but maybe you can explain again this =
case using different words=E2=80=A6?
>>>>>>>>=20
>>>>>>>> Mirja
>>>>>>>>=20
>>>>>>>=20
>>>>>>> Before I try different words, we should make sure the topic is =
understood.
>>>>>>>=20
>>>>>>> Suppose we wish to send a probe for 8KB, and suppose the path =
supports
>>>>>>> 3 router MTU sizes: a hop with 4KB MTU and then a later hop with =
2KB MTU, and finally one of just 1400B.
>>>>>>>=20
>>>>>>> Largest probe size =3D 8KB
>>>>>>>=20
>>>>>>> The first probe sends 8KB as the Segment Size
>>>>>>> ->------------------------------X
>>>>>>> Dropped by first router along path.
>>>>>>> In example case PTB indicates next hop =3D  4KB.
>>>>>>> Data not reliably sent.
>>>>>>>=20
>>>>>>> Largest probe size =3D 4KB
>>>>>>>=20
>>>>>>> Retransmit 2 packet for same segment of data, each size 4KB
>>>>>>> ------------->------------------------------X
>>>>>>> ------------->------------------------------X
>>>>>>> Dropped by router later along path.
>>>>>>> In example case PTB indicates next hop =3D  2KB.
>>>>>>> Data still not reliably sent.
>>>>>>>=20
>>>>>>> Largest probe size =3D 2KB
>>>>>>>=20
>>>>>>> Retransmit 4 packets for same segment of data.
>>>>>>> In example case PTB indicates next hop =3D  1400B.
>>>>>>> Data still not reliably sent.
>>>>>>> ------------->------------------------------>---X
>>>>>>> ------------->------------------------------>---X
>>>>>>> ------------->------------------------------>---X
>>>>>>> ------------->------------------------------>---X
>>>>>>>=20
>>>>>>> Largest probe size =3D 1400B
>>>>>>>=20
>>>>>>> Data finally transmitted in 6 packets all less than PMTU.
>>>>>>> ------------->------------------------------>-------------->
>>>>>>> ------------->------------------------------>-------------->
>>>>>>> ------------->------------------------------>-------------->
>>>>>>> ------------->------------------------------>-------------->
>>>>>>> ------------->------------------------------>-------------->
>>>>>>> ------------->------------------------------>-------------->
>>>>>>>=20
>>>>>>> All data delivered. PMTU=3D1400B is confirmed.
>>>>>>>=20
>>>>>>> Total sent packets =3D 13 packets
>>>>>>> No of re-transmissions =3D 7 (6 failed re-transmissions in 3 =
re-transmission attempts)
>>>>>>>=20
>>>>>>> Now let's try a method that heeds the warning in the text and =
re-transmits the probe data using a "safe: MTU:
>>>>>>>=20
>>>>>>> The first probe sends 8KB as the Segment Size
>>>>>>> ->------------------------------X
>>>>>>>=20
>>>>>>> Dropped by first router along path.
>>>>>>> In example case PTB indicates next hop =3D  4KB.
>>>>>>> Data not reliably sent.
>>>>>>>=20
>>>>>>> Largest probe size =3D 4KB
>>>>>>>=20
>>>>>>> Sender resends the 8KB segment using a known workable PMTU (in =
the above 1500B, if that were cached, or even 1280B.
>>>>>>>=20
>>>>>>> ------------->------------------------------>-------------->
>>>>>>> ------------->------------------------------>-------------->
>>>>>>> ------------->------------------------------>-------------->
>>>>>>> ------------->------------------------------>-------------->
>>>>>>> ------------->------------------------------>-------------->
>>>>>>> ------------->------------------------------>-------------->
>>>>>>>=20
>>>>>>> Total sent packets =3D 7 packets
>>>>>>> No of re-transmissions =3D 6 (all successful, 1 re-transmission)
>>>>>>>=20
>>>>>>> And afterwards separately resend a single probe packet to detect =
a the largest PMTU using the 4KB probe.
>>>>>>>=20
>>>>>>> Obviously, there are many combinations of paths, and not all =
cases lead
>>>>>>> to exponential growth, but all cases lead to multiple probes, =
and
>>>>>>> multiple re-transmissions.
>>>>>>>=20
>>>>>>> Gorry
>>>=20
>>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--Apple-Mail=_9182495A-C2E1-4DC2-981C-F01BD03A5867
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

iQEcBAEBCgAGBQJZJatdAAoJEK7rdBF357uoevcIAI5gYzTltroeGepdW2mMSlmp
rNoHy2lbd2VS9L8sgpizsXMTojOZf5rURPXiDRP4SMydWlX2xUD7ha83F4U7q3RR
4qzjF1Fmdo2QS8x1cBfCx/XhB/qDzuOU+Z0GU7AIiW+vHccyojhkehIHJTRTuhO3
noNikj2TYZsH/V8pxCnS0UW8c4v1+MyxunsNe4p6qY6OtZqXrUzsghD1F98f83Od
AiDIwrZb3YEhHdp+g/FWBeZgzfJcSC+aAjK3RC3QbivrR0iKTqjNrpzJBGJs20eS
ZAoKkI1gfWVEFX+O9GXzJtrr5chMXOnN7EL3GJw+Kd3CgKL5t6Rf5Q0r88KEBZo=
=BCY9
-----END PGP SIGNATURE-----

--Apple-Mail=_9182495A-C2E1-4DC2-981C-F01BD03A5867--


From nobody Wed May 24 09:46:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E90B12EB2F for ; Wed, 24 May 2017 09:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 R1OtJHbwHIGl for ; Wed, 24 May 2017 09:46:26 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCE1D129B9E for <6man@ietf.org>; Wed, 24 May 2017 09:46:25 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id D2B918107A for <6man@ietf.org>; Wed, 24 May 2017 12:46:22 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=Mz1iVOCaAA9Ve24kD8WmGRja7G0=; b=CAGBU4 yTJr3W6dl48HqZ8n0/BtzdIjzeJ1YcT0O6zYkdGmRHuGXQYoS8sF3XB9BdaNFSY8 Fwif1TFicMEGnYVf4Ke/FduOHVcv0mWdxVBQX/hCxSr4EzM8L0QmIQvbfus2Wz9f gEu1qQsg6On49Ju2sZXcvmF3QRcdQEtw0igms=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=RtjMwl5GPhrD2wdj3a2aPY46Htf+iCvW Alnrc/o+Bkkxzo0VTbygTWTepnBHaLpdwn2NABGTsCWT1UAceAfH/dHSQ07LCC75 emUgHEGyN1aohSZbUy9+AaJngttQl1WSKO1rCCwveS4lZa+X/D4RVGGQd3Vfp8r5 1XqQ2toWuRw=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id CBC9A81079 for <6man@ietf.org>; Wed, 24 May 2017 12:46:22 -0400 (EDT)
Received: from mail-qk0-f178.google.com (unknown [209.85.220.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 5482381076 for <6man@ietf.org>; Wed, 24 May 2017 12:46:22 -0400 (EDT)
Received: by mail-qk0-f178.google.com with SMTP id u75so158035779qka.3 for <6man@ietf.org>; Wed, 24 May 2017 09:46:21 -0700 (PDT)
X-Gm-Message-State: AODbwcAMLZcLFxQLFhgK3aV51Z75nz6n9BmXPJTes4o2+Cwy2iCOjnja EZWcI28LCDwhZehOrKsoqBt3ANgSXQ==
X-Received: by 10.55.143.198 with SMTP id r189mr30507131qkd.150.1495644381343;  Wed, 24 May 2017 09:46:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.22.72 with HTTP; Wed, 24 May 2017 09:46:00 -0700 (PDT)
In-Reply-To: 
References:  
From: "C. M. Heard" 
Date: Wed, 24 May 2017 09:46:00 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Questions / comments regarding draft-voyer-6man-extension-header-insertion (was: Proposed revised Extension Header text for rfc2460bis)
To: "Voyer, Daniel" 
Cc: Robert Raszuk , 6MAN <6man@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c081f920f7623055047d89e"
X-Pobox-Relay-ID: 84B647EA-40A0-11E7-A922-61520C78B957-06080547!pb-smtp2.pobox.com
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 16:46:28 -0000

--94eb2c081f920f7623055047d89e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 5, 2017 at 2:14 PM, Voyer, Daniel  wrote:
> Note that draft-voyer-6man-extension-header-insertion has been written
> with the purpose to illustrate _one_ evident use-case where header
> insertion is useful, not harmful and very beneficial. The intent of
> the draft is not to come with a complete set of solutions on how you
> can insert and update a source route path for a given packet.
>
> The first step towards header insertion, is to clearly document the
> practical, operational use-case where it is required (used) and safe.
[ ... ]
> As illustrated in the draft, the statement "Node 1 originates a packet
> P1 destined to 9 (SA=3D1, DA=3D9)=E2=80=9D refers to the action the ingre=
ss node
> of the source domain consisting of encapsulating the incoming packet
> (i.e.: the packet entering in the source domain) into an outer header
> with SA=3Dhimself (i.e., node 1) and DA=3Degress node (i.e., node-9). Thi=
s
> means that all packet transiting through the source domain are in fact
> encapsulated/tunneled through it.
>
> In this case, the shape of the new packet is:
>         SA=3D1, DA=3D9
>         SA=3Dx, DA=3Dy (i.e., the original SA/DA addresses)
>         payload
>
> Now, the packet travels from node-1 to node-9 and arrives in node-2.
> Assume that node-2 activated TI-LFA (IPFRR) where a backup path is
> pre-computed and installed into fib so that in case of interface 2to3
> fails, the traffic follows the 50ms convergence rules or better(SRTE).
> Upon failure of interface 2to3, the packet is rerouted to node-4 with
> the following SRH inserted:
>
>         SA=3D1, DA=3D5    (DA is now set as the first segment)
>         SRH=3D(5, 9)
>         SA=3Dx, DA=3Dy    (i.e., the original SA/DA addresses)
>         payload
> i.e., packet now has an SRH inserted by node-2 (transit node).
> Ref.: few paper about TI-LFA:
>
http://www.tmcnet.com/tmc/whitepapers/documents/whitepapers/2015/11524-fast=
-reroute-with-segment-routing-extending-fast-reroute.pdf
>
http://www.segment-routing.net/tutorials/2016-09-27-topology-independent-lf=
a-ti-lfa/
>
> When the packet reaches node-9, it is decapsulated which means both
> outer header and SRH are removed.

Thank you for providing the explanation and the links to the white papers.
That very much helps to understand the use case that is presented, and in
particular how any ICMP error messages related to the SRH can be confined
to the SR domain. You may wish to consider including part or all of that
information in the next version of the draft. That being said, I still have
some comments and questions.

First, it still is not clear to me why it is considered decisively
advantageous to add the outer IPv6 header at the ingress to the SR domain
(node 1) and then insert the SRH at the intermediate that detects the link
failure (node 2) instead of just doing the encapsulation at the
intermediate node itself. An explanation would help. If it requires
consideration of other use cases to make that case, you may want to conside=
r
adding one or more of those use cases to the draft.

Second, suppose that a second link failure is detected at node 4 (see
https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-00#=
section-3
).
If that triggers SRH insertion because of fast reroute, then there will
be two SRH's in the packet, which would make it malformed. To avoid this
problem, it seems to me that node 4 would need to rebuild the existing SRH,
encapsulate the packet in another outer IPv6 header, or else drop the
packet.
By analogy with how fast protection switching works in transport NEs, I
understand that protecting agains multiple link failures may be out of
scope,
but even so, multiple link failures should not result in malformed packets.

Looking forward to further discussion.

Mike Heard

--94eb2c081f920f7623055047d89e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Fri, May 5, 2017 at 2:14 PM, Voyer, Daniel <daniel.voyer@bell.ca> wrote:
>=
; Note that draft-voyer-6man-extension-header-insertion has been written> with the purpose to illustrate _one_ evident use-case where header> insertion is useful, not harmful and very beneficial. The intent of> the draft is not to come with a complete set of solutions on how you=

> can insert and update a source route path for a given packet.
&=
gt;
> The first step towards header insertion, is to clearly document=
 the
> practical, operational use-case where it is required (used) an=
d safe.
[ ... ]
> As illustrated in the draft, the statement "=
;Node 1 originates a packet
> P1 destined to 9 (SA=3D1, DA=3D9)=E2=80=
=9D refers to the action the ingress node
> of the source domain cons=
isting of encapsulating the incoming packet
> (i.e.: the packet enter=
ing in the source domain) into an outer header
> with SA=3Dhimself (i=
.e., node 1) and DA=3Degress node (i.e., node-9). This
> means that a=
ll packet transiting through the source domain are in fact
> encapsul=
ated/tunneled through it.
>
> In this case, the shape of the ne=
w packet is:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 SA=3D1, DA=3D9
> =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 SA=3Dx, DA=3Dy (i.e., the original SA/DA addresses=
)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 payload
>
> Now, the pack=
et travels from node-1 to node-9 and arrives in node-2.
> Assume that=
 node-2 activated TI-LFA (IPFRR) where a backup path is
> pre-compute=
d and installed into fib so that in case of interface 2to3
> fails, t=
he traffic follows the 50ms convergence rules or better(SRTE).
> Upon=
 failure of interface 2to3, the packet is rerouted to node-4 with
> t=
he following SRH inserted:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 SA=
=3D1, DA=3D5 =C2=A0 =C2=A0(DA is now set as the first segment)
> =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 SRH=3D(5, 9)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 S=
A=3Dx, DA=3Dy =C2=A0 =C2=A0(i.e., the original SA/DA addresses)
> =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 payload
> i.e., packet now has an SRH insert=
ed by node-2 (transit node).
> Ref.: few paper about TI-LFA:
> =
http:/=
/www.tmcnet.com/tmc/whitepapers/documents/whitepapers/2015/11524-fast-rerou=
te-with-segment-routing-extending-fast-reroute.pdf
> http://www.segment-routing.net/tutorials/2016-09-27-topology-inde=
pendent-lfa-ti-lfa/
>
> When the packet reaches node-9, it =
is decapsulated which means both
> outer header and SRH are removed.<=
br>
Thank you for providing the explanation and the links to the white p=
apers.
That very much helps to understand the use case that is presented=
, and in
particular how any ICMP error messages related to the SRH can b=
e confined
to the SR domain. You may wish to consider including part or =
all of that
information in the next version of the draft. That being sai=
d, I still have
some comments and questions.

First, it still is n=
ot clear to me why it is considered decisively
advantageous to add the o=
uter IPv6 header at the ingress to the SR domain
(node 1) and then inser=
t the SRH at the intermediate that detects the link
failure (node 2) ins=
tead of just doing the encapsulation at the
intermediate node itself. An=
 explanation would help. If it requires
consideration of other use cases=
 to make that case, you may want to consider
adding one or more of those=
 use cases to the draft.

Second, suppose that a second link failure =
is detected at node 4 (see
https://tools.ietf.org/=
html/draft-voyer-6man-extension-header-insertion-00#section-3).
If t=
hat triggers SRH insertion because of fast reroute, then there will
be t=
wo SRH's in the packet, which would make it malformed. To avoid thisproblem, it seems to me that node 4 would need to rebuild the existing SRH=
,
encapsulate the packet in another outer IPv6 header, or else drop the =
packet.
By analogy with how fast protection switching works in transport=
 NEs, I
understand that protecting agains multiple link failures may be =
out of scope,
but even so, multiple link failures should not result in m=
alformed packets.

Looking forward to further discussion.

Mike=
 Heard


--94eb2c081f920f7623055047d89e--


From nobody Fri May 26 09:50:57 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075EB126B7F for ; Fri, 26 May 2017 09:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 70jkJyHqo5cK for ; Fri, 26 May 2017 09:50:54 -0700 (PDT)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 75F74129478 for ; Fri, 26 May 2017 09:50:53 -0700 (PDT)
Received: by mail-wr0-x233.google.com with SMTP id l50so5049704wrc.3 for ; Fri, 26 May 2017 09:50:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:date:references:cc:to:message-id;  bh=9npM2/0eTniCrLMJXnobTrwB2hb6mIkfq2qgZmcMjSA=; b=K42BuuDRyKb9nwTKUzyQvbIV4kDy/xmpSNtdpb4FmicIWnsq9z4N8Q227nLOByAYoI ybyCIZtHvJ8zrUC7wdCAet2gtCC8TFlYYEbDnMxnUPeaHiwM5Wg5KtHCTH6fgEEtuA9l +ufH0o8ImfmfE3B8Q5i/o2ME2+MXLJn/gZtftGAUOh9tezwSVBYbpBm3nO7WK5jR7q/0 X0ism6vR8xtoyy2HxkClg+qMQ7fd7BVH6JEMktigAO+9vF9Qs0PyVrDJUi9cnD2yIFA3 txdrkVtGipWHyMaAuQ9PHlzTIZWU0hPtqos0r1YxjVR9XXtzezOVvMqBZ8uPHnDeQlZX dA9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=9npM2/0eTniCrLMJXnobTrwB2hb6mIkfq2qgZmcMjSA=; b=nZ/SkEgWr8+s3Lr0+9ueR4u5rpjvOBLp2f2wcYv5Z07Vk+asLIbBb3lF/lQVaimnN8 zTw7lViy8oCqfvXJpqmDgG37DpvtPTsbs6S1JHO8lx6z3H2qQvUlBvL5O+f3FctSXY74 BsPZfJuBB2LEL5w55l2uBgi4/FyUZnWFoOu9YrRnaSuFm31xvT2aD4m+RUN9etUtqZer qz2+nLbMecmCU/ROxQT1CSxYDwHOZuv29f/J/e5esFnJG8Ix5Z/NhWtvjRnrhrlRpcP/ 5JULwauLwFPGaGeUbR7vQ/4XSJglBb9XHcQtTEY0jxbpwQX3yxouJpVzHECrhye4dclc 1rlg==
X-Gm-Message-State: AODbwcB1P/Uegndp8cScA522JqVGlNIrAQthfDD/vS3tDWOwYx4FDAsr eP9DRXB0AeBnH10Gy+8=
X-Received: by 10.223.135.213 with SMTP id c21mr2730138wrc.10.1495817451720; Fri, 26 May 2017 09:50:51 -0700 (PDT)
Received: from ?IPv6:2601:647:4d01:db10:e1e6:d5d8:3c54:56da? ([2601:647:4d01:db10:e1e6:d5d8:3c54:56da]) by smtp.gmail.com with ESMTPSA id e23sm1736293wre.54.2017.05.26.09.50.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 May 2017 09:50:50 -0700 (PDT)
From: Bob Hinden 
Content-Type: multipart/signed; boundary="Apple-Mail=_A332C420-791C-41D7-8BDA-1D157F726FDE"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Fwd: Protocol Action: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification to Internet Standard
Date: Fri, 26 May 2017 09:50:45 -0700
References: <149581532893.8648.14099315224145198294.idtracker@ietfa.amsl.com>
Cc: Bob Hinden 
To: IPv6 List 
Message-Id: 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 16:50:56 -0000

--Apple-Mail=_A332C420-791C-41D7-8BDA-1D157F726FDE
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B5C99F6E-E79A-4BA4-A66C-3BB040FA0CB7"


--Apple-Mail=_B5C99F6E-E79A-4BA4-A66C-3BB040FA0CB7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

FYI

> Begin forwarded message:
>=20
> From: The IESG 
> Subject: Protocol Action: Internet Control Message Protocol (ICMPv6) =
for the Internet Protocol Version 6 (IPv6) Specification to Internet =
Standard
> Date: May 26, 2017 at 9:15:28 AM PDT
> To: "IETF-Announce" 
> Cc: ipv6-chairs@ietf.org, okolkman@ripe.net, margaret@thingmagic.com, =
draft-ietf-ipngwg-icmp-v3@ietf.org, The IESG , =
dnsext-chairs@ietf.org, draft-ietf-dnsext-rfc1886bis@ietf.org, =
rfc-editor@rfc-editor.org
> Reply-To: ietf@ietf.org
>=20
> The IESG has approved changing the status of the following document:
> - Internet Control Message Protocol (ICMPv6) for the Internet Protocol
> Version 6 (IPv6) Specification
>  (rfc4443) to Internet Standard
>=20
> This protocol action is documented at:
> =
https://datatracker.ietf.org/doc/status-change-icmpv6-dns-ipv6-to-internet=
-standard/
>=20
> A URL of the affected document is:
> https://datatracker.ietf.org/doc/rfc4443/
>=20
> Status Change Details:
>=20
> RFC4443 "Internet Control Message Protocol (ICMPv6) for the Internet
> Protocol Version 6 (IPv6) Specification" currently has an IETF =
standards
> status of Draft Standard, which is now an obsolete status. This status
> change requests reclassifying it to Internet Standard.
>=20
> (1) There are at least two independent interoperating implementations
>       with widespread deployment and successful operational =
experience.
>=20
> RFC4443 has been widely implemented:
>          https://www.ipv6ready.org/db/index.php/public/?o=3D4
>=20
> (2) There are no errata against the specification that would cause a
>       new implementation to fail to interoperate with deployed ones.
> RFC4443 has 4 errata, none of which would cause new interoperability
>      problems.
>=20
> (3) There are no unused features in the specification that greatly
>       increase implementation complexity.
>=20
> There are no unused features.
>=20
> (4) If the technology required to implement the specification
>       requires patented or otherwise controlled technology, then the
>       set of implementations must demonstrate at least two =
independent,
>       separate and successful uses of the licensing process.
>=20
> N/A
>=20
> RFC3596 "DNS Extensions to Support IP Version 6" currently has an IETF
> standards status of Draft Standard, which is now an obsolete status. =
This
> status change requests reclassifying it to Internet Standard.
>=20
> (1) There are at least two independent interoperating implementations
>       with widespread deployment and successful operational =
experience.
>=20
> RFC3596 has been widely implemented:
>          https://www.ipv6ready.org/db/index.php/public/?o=3D4
>=20
> (2) There are no errata against the specification that would cause a
>       new implementation to fail to interoperate with deployed ones.
>=20
> There are no errata filed against RFC3596
>=20
> (3) There are no unused features in the specification that greatly
>       increase implementation complexity.
>=20
> There are no unused features.
>=20
> (4) If the technology required to implement the specification
>       requires patented or otherwise controlled technology, then the
>       set of implementations must demonstrate at least two =
independent,
>       separate and successful uses of the licensing process.
>=20
> N/A
>=20
> Personnel
>=20
>   Suresh Krishnan is the responsible Area Director.
>=20
>=20
>=20


--Apple-Mail=_B5C99F6E-E79A-4BA4-A66C-3BB040FA0CB7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

FYI

Begin forwarded message:

From: =
The IESG <iesg-secretary@ietf.org>
Subject: =
Protocol Action: =
Internet Control Message Protocol (ICMPv6) for the Internet Protocol =
Version 6 (IPv6) Specification to Internet Standard 
Date: =
May 26, 2017 at 9:15:28 AM =
PDT
To: =
"IETF-Announce" <ietf-announce@ietf.org>
Cc: ipv6-chairs@ietf.org, okolkman@ripe.net, margaret@thingmagic.com, draft-ietf-ipngwg-icmp-v3@ietf.org, The IESG <iesg@ietf.org>, dnsext-chairs@ietf.org, draft-ietf-dnsext-rfc1886bis@ietf.org, rfc-editor@rfc-editor.org
Reply-To: =
ietf@ietf.org

The IESG has approved =
changing the status of the following document:
- Internet =
Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification
  (rfc4443) =
to Internet Standard

This protocol action =
is documented at:
https://datatracker.ietf.org/doc/status-change-icmpv6-dns-ipv6-=
to-internet-standard/

A URL of the =
affected document is:
https://datatracker.ietf.org/doc/rfc4443/

Status Change Details:

RFC4443 =
"Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification" currently has an =
IETF standards
status of Draft Standard, which is now an =
obsolete status. This status
change requests reclassifying =
it to Internet Standard.

(1) There are at =
least two independent interoperating implementations
 =
      with widespread deployment and =
successful operational experience.

RFC4443 =
has been widely implemented:
 =
         https://www.ipv6read=
y.org/db/index.php/public/?o=3D4

(2) There =
are no errata against the specification that would cause a
 =
      new implementation to fail to =
interoperate with deployed ones.
RFC4443 has 4 errata, =
none of which would cause new interoperability
 =
     problems. 

(3) =
There are no unused features in the specification that greatly
       increase implementation =
complexity.

There are no unused =
features.

(4) If the technology required to =
implement the specification
 =
      requires patented or otherwise =
controlled technology, then the
 =
      set of implementations must =
demonstrate at least two independent,
 =
      separate and successful uses of the =
licensing process.

N/A

RFC3596 "DNS Extensions to Support IP Version 6" currently =
has an IETF
standards status of Draft Standard, which is =
now an obsolete status. This
status change requests =
reclassifying it to Internet Standard.

(1) =
There are at least two independent interoperating implementations
       with widespread =
deployment and successful operational experience.

RFC3596 has been widely implemented:
 =
         https://www.ipv6read=
y.org/db/index.php/public/?o=3D4

(2) There =
are no errata against the specification that would cause a
 =
      new implementation to fail to =
interoperate with deployed ones.

There are =
no errata filed against RFC3596

(3) There =
are no unused features in the specification that greatly
 =
      increase implementation =
complexity.

There are no unused =
features.

(4) If the technology required to =
implement the specification
 =
      requires patented or otherwise =
controlled technology, then the
 =
      set of implementations must =
demonstrate at least two independent,
 =
      separate and successful uses of the =
licensing process.

N/A

Personnel 

   Suresh =
Krishnan is the responsible Area Director.




=

--Apple-Mail=_B5C99F6E-E79A-4BA4-A66C-3BB040FA0CB7--

--Apple-Mail=_A332C420-791C-41D7-8BDA-1D157F726FDE
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

iQEcBAEBCgAGBQJZKFzmAAoJEK7rdBF357uoBEcIAKUDNeO4eceqJjs1E7xWM0sY
24JGWtF4O0z+xHnftEbMIstX6/KzGz/D9gUSBqgZ9VcNdEPZPKixRzcB0RkyufqM
Yk5POg9EJ7jtpotF0At+Q7X4Vgga1Ql+sD5jsCa5RRMtTI87C828qfWhG22G9pZE
FAD8fnBWrJjsuoyqJupTO5s1fsj3ER9fPqOaTOEulGRqQq2/Ffk8ZZOozoeGwcxR
7JPi+924qXr+7jzTm8JYczVKvz7Sv/fKWYtnpETrj0KMAPtzlqJPuFt8Mrb+hULA
cAY74KpuvCxe+TyEofIDvf0WdlzXwbyvXtmEQ1y7FVBSdjT1C3VFsNwltjCz2dE=
=vk84
-----END PGP SIGNATURE-----

--Apple-Mail=_A332C420-791C-41D7-8BDA-1D157F726FDE--


From nobody Fri May 26 09:51:15 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5CA128DF6 for ; Fri, 26 May 2017 09:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nC_IW6vaTS8f for ; Fri, 26 May 2017 09:51:11 -0700 (PDT)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 BE9B9129576 for ; Fri, 26 May 2017 09:51:09 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id z52so5072065wrc.2 for ; Fri, 26 May 2017 09:51:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:date:references:cc:to:message-id;  bh=2ZXZSAPtRdNb8QouswV1NEjzrdYadXJ2ZsVil5WJVoE=; b=QlrvnUWa31HkiE3GLlJifRmVeBLdNETh2z0cUcj28lMe1i1D+2njCDIBs9hWl9CUoE qHQ8N699KNHRfPQWs7virCr/BtZL12eFWN43F3jkGcc468vRz4XD/vW05PYMuCW9f5NR qmxRmntQz4aM40hiogZbLKHJxDC1fSgSclr2SWX6V9LtjHgIICSJ0buBGC/od04COraV 429m8T0zBjeKqLuk7tWdAnZ9zfoYhxba4HyBsNj3txqsKSvxoQnGd4R4301Hka1AY2o9 BtSDI6xkvXG2d7vriSfpFKUPHhisM38qjN3Q5OfY4LM2NbaD/pW01tHU/0SZkFQ0WqrD KZUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=2ZXZSAPtRdNb8QouswV1NEjzrdYadXJ2ZsVil5WJVoE=; b=bsDq1b/2Nb2AougBAoWxSY0XhfS8nLka/U3/JsOw25qRZwtg8hDwtlfbrTu2CVpMq8 xYa+64AJNdW6I4ZKlEp0OIlaTBueghmlixlEU73N+2eMyK+7XTZ1MR1fiU5B80DNWVGQ cz/lrZh6ix72vpOXCU4+K8QAqJPiJDxiMOV5t+20r67Htg9+nWPwDAnVQni/9BANVark N7dz8upkF2rbBztsAC+DAuy7BWCvgaPTdurqvdpfcj05Z8+suEeWtQ483nJnfDPJeASg QOCtHox06R3Ydzsne+8SaMbOs4Q52ArhnFRAoFus/hVa5OOc6JkyMzIZ49ZXl4lj0FN0 4bOQ==
X-Gm-Message-State: AODbwcCr1qfJeSmM0dDSRm8v1MDb0oLMGo9R/T+HsoWXy1kaj01CRkT6 p3Hs8LQTJM/KMo6JPQ4=
X-Received: by 10.223.157.29 with SMTP id k29mr2392985wre.156.1495817465310; Fri, 26 May 2017 09:51:05 -0700 (PDT)
Received: from ?IPv6:2601:647:4d01:db10:e1e6:d5d8:3c54:56da? ([2601:647:4d01:db10:e1e6:d5d8:3c54:56da]) by smtp.gmail.com with ESMTPSA id e23sm1736293wre.54.2017.05.26.09.51.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 May 2017 09:51:03 -0700 (PDT)
From: Bob Hinden 
Content-Type: multipart/signed; boundary="Apple-Mail=_FC20867C-9302-4012-9788-360E3119B09C"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Fwd: Protocol Action: DNS Extensions to Support IP Version 6 to Internet Standard
Date: Fri, 26 May 2017 09:51:02 -0700
References: <149581532913.8648.1739323272734672777.idtracker@ietfa.amsl.com>
Cc: Bob Hinden 
To: IPv6 List 
Message-Id: 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 16:51:13 -0000

--Apple-Mail=_FC20867C-9302-4012-9788-360E3119B09C
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_33EE602D-6780-47E4-BE00-20478860F472"


--Apple-Mail=_33EE602D-6780-47E4-BE00-20478860F472
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

FYI

> Begin forwarded message:
>=20
> From: The IESG 
> Subject: Protocol Action: DNS Extensions to Support IP Version 6 to =
Internet Standard
> Date: May 26, 2017 at 9:15:29 AM PDT
> To: "IETF-Announce" 
> Cc: ipv6-chairs@ietf.org, okolkman@ripe.net, margaret@thingmagic.com, =
draft-ietf-ipngwg-icmp-v3@ietf.org, The IESG , =
dnsext-chairs@ietf.org, draft-ietf-dnsext-rfc1886bis@ietf.org, =
rfc-editor@rfc-editor.org
> Reply-To: ietf@ietf.org
>=20
> The IESG has approved changing the status of the following document:
> - DNS Extensions to Support IP Version 6
>  (rfc3596) to Internet Standard
>=20
> This protocol action is documented at:
> =
https://datatracker.ietf.org/doc/status-change-icmpv6-dns-ipv6-to-internet=
-standard/
>=20
> A URL of the affected document is:
> https://datatracker.ietf.org/doc/rfc3596/
>=20
> Status Change Details:
>=20
> RFC4443 "Internet Control Message Protocol (ICMPv6) for the Internet
> Protocol Version 6 (IPv6) Specification" currently has an IETF =
standards
> status of Draft Standard, which is now an obsolete status. This status
> change requests reclassifying it to Internet Standard.
>=20
> (1) There are at least two independent interoperating implementations
>       with widespread deployment and successful operational =
experience.
>=20
> RFC4443 has been widely implemented:
>          https://www.ipv6ready.org/db/index.php/public/?o=3D4
>=20
> (2) There are no errata against the specification that would cause a
>       new implementation to fail to interoperate with deployed ones.
> RFC4443 has 4 errata, none of which would cause new interoperability
>      problems.
>=20
> (3) There are no unused features in the specification that greatly
>       increase implementation complexity.
>=20
> There are no unused features.
>=20
> (4) If the technology required to implement the specification
>       requires patented or otherwise controlled technology, then the
>       set of implementations must demonstrate at least two =
independent,
>       separate and successful uses of the licensing process.
>=20
> N/A
>=20
> RFC3596 "DNS Extensions to Support IP Version 6" currently has an IETF
> standards status of Draft Standard, which is now an obsolete status. =
This
> status change requests reclassifying it to Internet Standard.
>=20
> (1) There are at least two independent interoperating implementations
>       with widespread deployment and successful operational =
experience.
>=20
> RFC3596 has been widely implemented:
>          https://www.ipv6ready.org/db/index.php/public/?o=3D4
>=20
> (2) There are no errata against the specification that would cause a
>       new implementation to fail to interoperate with deployed ones.
>=20
> There are no errata filed against RFC3596
>=20
> (3) There are no unused features in the specification that greatly
>       increase implementation complexity.
>=20
> There are no unused features.
>=20
> (4) If the technology required to implement the specification
>       requires patented or otherwise controlled technology, then the
>       set of implementations must demonstrate at least two =
independent,
>       separate and successful uses of the licensing process.
>=20
> N/A
>=20
> Personnel
>=20
>   Suresh Krishnan is the responsible Area Director.
>=20
>=20
>=20


--Apple-Mail=_33EE602D-6780-47E4-BE00-20478860F472
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

FYI

Begin forwarded message:

From: =
The IESG <iesg-secretary@ietf.org>
Subject: =
Protocol Action: =
DNS Extensions to Support IP Version 6 to Internet Standard 
Date: =
May 26, 2017 at 9:15:29 AM =
PDT
To: =
"IETF-Announce" <ietf-announce@ietf.org>
Cc: ipv6-chairs@ietf.org, okolkman@ripe.net, margaret@thingmagic.com, draft-ietf-ipngwg-icmp-v3@ietf.org, The IESG <iesg@ietf.org>, dnsext-chairs@ietf.org, draft-ietf-dnsext-rfc1886bis@ietf.org, rfc-editor@rfc-editor.org
Reply-To: =
ietf@ietf.org

The IESG has approved =
changing the status of the following document:
- DNS =
Extensions to Support IP Version 6
  (rfc3596) to =
Internet Standard

This protocol action is =
documented at:
https://datatracker.ietf.org/doc/status-change-icmpv6-dns-ipv6-=
to-internet-standard/

A URL of the =
affected document is:
https://datatracker.ietf.org/doc/rfc3596/

Status Change Details:

RFC4443 =
"Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification" currently has an =
IETF standards
status of Draft Standard, which is now an =
obsolete status. This status
change requests reclassifying =
it to Internet Standard.

(1) There are at =
least two independent interoperating implementations
 =
      with widespread deployment and =
successful operational experience.

RFC4443 =
has been widely implemented:
 =
         https://www.ipv6read=
y.org/db/index.php/public/?o=3D4

(2) There =
are no errata against the specification that would cause a
 =
      new implementation to fail to =
interoperate with deployed ones.
RFC4443 has 4 errata, =
none of which would cause new interoperability
 =
     problems. 

(3) =
There are no unused features in the specification that greatly
       increase implementation =
complexity.

There are no unused =
features.

(4) If the technology required to =
implement the specification
 =
      requires patented or otherwise =
controlled technology, then the
 =
      set of implementations must =
demonstrate at least two independent,
 =
      separate and successful uses of the =
licensing process.

N/A

RFC3596 "DNS Extensions to Support IP Version 6" currently =
has an IETF
standards status of Draft Standard, which is =
now an obsolete status. This
status change requests =
reclassifying it to Internet Standard.

(1) =
There are at least two independent interoperating implementations
       with widespread =
deployment and successful operational experience.

RFC3596 has been widely implemented:
 =
         https://www.ipv6read=
y.org/db/index.php/public/?o=3D4

(2) There =
are no errata against the specification that would cause a
 =
      new implementation to fail to =
interoperate with deployed ones.

There are =
no errata filed against RFC3596

(3) There =
are no unused features in the specification that greatly
 =
      increase implementation =
complexity.

There are no unused =
features.

(4) If the technology required to =
implement the specification
 =
      requires patented or otherwise =
controlled technology, then the
 =
      set of implementations must =
demonstrate at least two independent,
 =
      separate and successful uses of the =
licensing process.

N/A

Personnel 

   Suresh =
Krishnan is the responsible Area Director.




=

--Apple-Mail=_33EE602D-6780-47E4-BE00-20478860F472--

--Apple-Mail=_FC20867C-9302-4012-9788-360E3119B09C
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

iQEcBAEBCgAGBQJZKFz2AAoJEK7rdBF357uowmAH/1CrLAlDWcK+FGGbiCOH8A5q
4OntiYkxVm/0LgW93PALzpslfYBFSpVMhbuaDgZ4GWDLCnPGWV/BlYsPz4nGVYDG
LisJOBee3MoHwNZLhdIiQgTGXl2dNmKPRVg9nGeGhW832GaMWOK4W1mAAg7Uf8wS
usEiclwEKpmGvCMeWtDoYTRsQICtjw58aJA6XjcXH0JE19KseNvRoHSUAWg6/vz3
lI21TrqnmQWrGuQtOkO405qT1r5vfSOiWqbsbaq2xt/5jMhgCjLF4G929OqUWLJ4
L3CCgWbQh1Sx5APq3V5+WpqODnu/r/YpSkWqu6kBHk7Hd7GyuE19dBlG4fJ1reM=
=3OlK
-----END PGP SIGNATURE-----

--Apple-Mail=_FC20867C-9302-4012-9788-360E3119B09C--


From nobody Sat May 27 08:43:20 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 656DF12947A; Sat, 27 May 2017 08:43:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: ipv6@ietf.org
Subject: I-D Action: draft-ietf-6man-rfc1981bis-08.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149589979238.8641.7029084606069466721@ietfa.amsl.com>
Date: Sat, 27 May 2017 08:43:12 -0700
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 May 2017 15:43:12 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance of the IETF.

        Title           : Path MTU Discovery for IP version 6
        Authors         : Jack McCann <>
                          Stephen E. Deering <>
                          Jeffrey Mogul <>
                          Robert M. Hinden
	Filename        : draft-ietf-6man-rfc1981bis-08.txt
	Pages           : 21
	Date            : 2017-05-27

Abstract:
   This document describes Path MTU Discovery for IP version 6.  It is
   largely derived from RFC 1191, which describes Path MTU Discovery for
   IP version 4.  It obsoletes RFC1981.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-08
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc1981bis-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc1981bis-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sat May 27 08:48:34 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECAC129483 for ; Sat, 27 May 2017 08:48:32 -0700 (PDT)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 A1omDqeenuFW for ; Sat, 27 May 2017 08:48:31 -0700 (PDT)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C2312947F for ; Sat, 27 May 2017 08:48:30 -0700 (PDT)
Received: by mail-wr0-x22c.google.com with SMTP id z52so15385528wrc.2 for ; Sat, 27 May 2017 08:48:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:cc:to; bh=Uc5vCLBhcZqQBcpriBn2E0xtkkXhcZoqbH2wvtBoZis=; b=i911G/3jXSjRlgMECCIxJP/r7Qt+F4OL13PZLkGCWdHuZ2WWQFWc8KiiogCqIxbT/i kND3rFKY7tpnRT6jhOgEU5feWzb5dey4iRZMgLxLeyHD6xTiAMdjf5MZtvduLVRdfyej a+0FT8D68Y38Adoqd+l0h5rhvmh69y3VIgGgFy8xs270/e6e1bY29bMOgOboKqx1nEjJ 3/eRFG0eEYINFrfoB5kenVKX07Qo0J6neKWBeCheLIT+jTiTE+RxDBGWOkS0CVUB28os gwr9dbYLaN7XDoIVqnhKVkER5NKVDSGM84aRch6PKcTi0cP+LjM3mti72xOcrf6Vr2I5 4EKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=Uc5vCLBhcZqQBcpriBn2E0xtkkXhcZoqbH2wvtBoZis=; b=gyrJsaporJzVT53t0Fu5+TF24nLdcLcol898McUJHnodo+n3pq/JqEpQrCQidi76Y3 Of+t/E23hQzGKbZoCfSwybkVhh9HoqPW/aZ8hEHXIoVfntJ5qKeGAEdBRbqBXuVB1Ek7 CLyt9+nLyu+YTIsE1pY647TOp1grl7hv2JDT+YsT3X3E2AJqL2XWYzbJOmSsqHUVqEhZ VCSn/hCi35yhvgGvW7Mk1gC1JqrkrP6bmTZt0af06poOovMU9V5trwbHN1NlFcceepMD 0rOlifqBR/SqX3XQcOeKu39h7r0HmWn1lWhrJ9x2JjUh/jJUsNBgXCm6sVfLmS1yadIn +fJw==
X-Gm-Message-State: AODbwcByxT6ias8SvStFjlVPZnbUUdoRklp+ktn+HMxVHWcqS2XTTfv3 6WCg5tJpn/vDI0GZBZA=
X-Received: by 10.223.136.229 with SMTP id g34mr5776504wrg.42.1495900109280; Sat, 27 May 2017 08:48:29 -0700 (PDT)
Received: from ?IPv6:2601:647:4d01:db10:591e:8ddf:9ba8:7dc3? ([2601:647:4d01:db10:591e:8ddf:9ba8:7dc3]) by smtp.gmail.com with ESMTPSA id b81sm6968997wmf.7.2017.05.27.08.48.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 May 2017 08:48:28 -0700 (PDT)
From: Bob Hinden 
Content-Type: multipart/signed; boundary="Apple-Mail=_54DE721B-D54A-4CC3-AE77-B8D809B7C0DA"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: 
Message-Id: 
Date: Sat, 27 May 2017 08:48:23 -0700
Cc: Bob Hinden 
To: IPv6 List 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 May 2017 15:48:33 -0000

--Apple-Mail=_54DE721B-D54A-4CC3-AE77-B8D809B7C0DA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

I published a new version of rfc1981bis (-08).  Links to the document =
below.

The changes from the IESG Discuss comments from IESG reviews.  These =
include:

     Based on IESG comments, cleaned up text in Section 5.3
     regarding suggested action when PMTU value has not been
     decreased recently.

     Revision of Note in Section 5.4 to make text clearer.

     Updated Section 7 "Acknowledgements".

     Editorial Changes.

A diff from the previous version can be found at:

https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-08.txt

Please review.

This is part of the project to move the core IPv6 specifications to =
Internet Standard.

Thanks,
Bob

> Name:		draft-ietf-6man-rfc1981bis
> Revision:	08
> Title:		Path MTU Discovery for IP version 6
> Document date:	2017-05-27
> Group:		6man
> Pages:		21
> URL:            =
https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc1981bis-08.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/
> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-08
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc1981bis-08
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-08
>=20
> Abstract:
>   This document describes Path MTU Discovery for IP version 6.  It is
>   largely derived from RFC 1191, which describes Path MTU Discovery =
for
>   IP version 4.  It obsoletes RFC1981.



--Apple-Mail=_54DE721B-D54A-4CC3-AE77-B8D809B7C0DA
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

iQEcBAEBCgAGBQJZKZ/IAAoJEK7rdBF357uoUhoIAJ7jbD0ryvLFp0HnRxg81WBV
L0NyVGb3ZZFDXCuylKXdgW95D89HgWhbC58s2S9w5ZahoYwJb2M/uVWRK1e56z7A
DQVoYdSrqSq2u4NMQgZ5xVAvQdk1XxXgIUtwZbDs5L5JST4Jwb1vquDiBI41akzS
yVs5/vMuVkQ8ZIoVtd78N6YG0hGF2UA4/+OWAbxdzSD/EINby7Gpf83yJrzoYxwz
SNiaDW1LskuNqbDoeHC5E7GRIaxkVtbtxaBfrD4IZnU75WNw/qM41/s9T+P9EKnK
NUB1W56BEIof4wKxgjmLfxTqgnprJoJMQdLxaP15u7iY01V6OJbJ/D+Kk1k1cRE=
=/YNj
-----END PGP SIGNATURE-----

--Apple-Mail=_54DE721B-D54A-4CC3-AE77-B8D809B7C0DA--


From nobody Mon May 29 05:38:17 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 262E3129553; Mon, 29 May 2017 05:38:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind?= 
To: "The IESG" 
Cc: draft-ietf-6man-rfc1981bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org
Subject: =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ietf-6man?= =?utf-8?q?-rfc1981bis-08=3A_=28with_COMMENT=29?=
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149606149514.25348.10854422688090284741.idtracker@ietfa.amsl.com>
Date: Mon, 29 May 2017 05:38:15 -0700
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 May 2017 12:38:15 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-6man-rfc1981bis-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my discuss. I believe there is an editing nit in
section 5.4 now:
"Alternatively, the retransmission could be done in immediate response
   to a notification that the Path MTU was decreased, but only for the
   specific connection specified by the Packet Too Big message, but
only
   based on the message and connection. "
Is it on purpose to have twice "but only" here?

I leave my previous comments  below for the record. I don't think all of
them have been addressed but I aldo don't recognize any further
discussion about those points:

1) I agree with Ekr on this sentence:
"Nodes SHOULD appropriately validate the payload of ICMPv6 PTB
   messages to ensure these are received in response to transmitted
   traffic (i.e., a reported error condition that corresponds to an
IPv6
   packet actually sent by the application) per [ICMPv6]."
This sounds like it should be a MUST but I guess it depends on the upper
layer protocol if such a validation is possible or not, e.g. if
information are available that can be used for validation. Maybe you can
be more explicit here and even say something like pmtu discovery
should/must only be used if the upper layer protocol provides means for
validation of the icmp payload (like a sequence number in TCP)…?

Further also note that if the upper layer does the validation while the
IP layer maintains EMTU_S, there must be an interface from the upper
layer to the IP layer to tell if a packet is valid or not before the IP
layer updates the MTU estimate. This seems actually more complicated than
this one sentences indicates.

2) Also as Ekr says, I also have problems to fully understand this
normative text in section 4:
"After receiving a Packet Too Big message, a node MUST attempt to
   avoid eliciting more such messages in the near future.  The node
MUST
   reduce the size of the packets it is sending along the path.  Using
a
   PMTU estimate larger than the IPv6 minimum link MTU may continue to
   elicit Packet Too Big messages.  Since each of these messages (and
   the dropped packets they respond to) consume network resources, the
   node MUST force the Path MTU Discovery process to end.

   Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast
   as possible."
I especially don't understand the first part, given that a PTB message
may still indicate a MTU that is larger than the minimum link MTU which
then may cause another PTB message later on the path. This text reads
like if you receive one PTB message you should better end discovery and
fall back to the minimum link MTU to avoid any further PTB message and
not waist any resources. I don't think that's the intention and as such I
don't understand when it is recommended to end discovery here...?

3) Section 5.2 seems to be written with only single homed hosts in mind.
It might be good to advise that the pmtu information should always be
stored on a per interface basis...?

4) Also section 5.2:
You only advise to store information per flow ID, however, if the flow
label is not used, wouldn't it make really sense to just use the 5-tuple
instead? Also note that EMCP is often done based on the 5-tuple or even
6-tuple (with the ToS field).

5) And more in section 5.2:
"When a Packet Too Big message is received, the node determines which
   path the message applies to based on the contents of the Packet Too
   Big message. "
MAYBE:
"When a valid Packet Too Big message is received, the node determines
which
   path the message applies to based on the contents of the Packet Too
   Big message."
And further on:
"If the tentative PMTU is less than the existing PMTU estimate, the
   tentative PMTU replaces the existing PMTU as the PMTU value for the
   path."
This doesn't cover the case where a pmtu probe with a larger size was
send and the PTB message returns a larger value then stored. Maybe state
this explicitly.

This applies similar to this sentence in section 6:
OLD
"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.“
NEW
"A node, however, MUST NOT raise its estimate of the
      PMTU based on a Packet Too Big message that is not a (validated)
response to a PMTU probe that was previously send by this node, so should
not be
      vulnerable to this attack."

6) Further section 5.2:
Should this statement be maybe upper case MUST:
"The packetization layers must be notified about decreases in the PMTU.
"

7) Technical comment on section 5.3 in general:
There is a difference between aging if a flow is active or not. While I
maybe don't want to probe again for this connection because my
application already decided to use a mode where it can live with the
current pmtu and it's too much effect to switch, I really want to probe
at the beginning of the next connection again to check if I can use a
different mode now. While the IP layer does not have a notion of
connection it can observe if packets are frequently send with the same
5-tuple and reset the cached pmtu after a certain idle time.

8) Section 5.4: should this maybe be normative, at least the last MUST
NOT (be fragmented):
"A packetization layer (e.g., TCP) must track the PMTU for the path(s)
   in use by a connection; it should not send segments that would
result
   in packets larger than the PMTU, except to probe during PMTU
   discovery (this probe packet must not be fragmented to the PMTU). "


Nit:
The abbreviation PTB is only used once in section 4 (and never expanded).



From nobody Tue May 30 12:37:03 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BEC1250B8; Tue, 30 May 2017 12:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level: 
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 AD-wJEvdRu3N; Tue, 30 May 2017 12:37:01 -0700 (PDT)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 207531292FD; Tue, 30 May 2017 12:37:00 -0700 (PDT)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 30 May 2017 19:36:59 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 308D6D788A; Tue, 30 May 2017 12:36:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:mime-version:subject:message-id:date:cc:to; s= selector1; bh=tXrK+Z4b1Ji0lom6YbA3UR+7vXc=; b=DRTCU71NfbsQhavHKu YSvhHjkOKhRr5W2au4NWmpcPDWZxCopcoNH0Omu61ku9Ha7/UxgrjxPWGTUVTUuu cZ+USGtHxEO2NBFsZ7/y2cVhz40qipp0xZnxnZ9VtIz60y7u8tP7MZdMKnum0zUM VEId0a7vagBt0mLa/0CegtFSE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:mime-version:subject:message-id:date:cc:to; q=dns; s=selector1; b=BCoKg2DmJK/dJaCuLtib1nPFI3wYedauogn9plklwFx2+6o4 G9GpzqxZ0kLkDpJQiT9ypPzVTiJzcwrRO5N+x525o7hGXy2c3KhYxl/TKhAwm1gh 2FMz/ier/HZZ1GfT4gfwnN6X/vZRhRj8wezcDqxkEJC5v5sJFxqi49Km2qM=
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 F0F5BD788E; Tue, 30 May 2017 12:36:58 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 0C4F2C9B58F7; Tue, 30 May 2017 21:36:56 +0200 (CEST)
From: otroan@employees.org
Content-Type: multipart/signed; boundary="Apple-Mail=_CAF26CC0-41F5-4E9F-BB4B-EF75F6560BB4"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: 6MAN IETF99 Call for agenda items
Message-Id: <62638EF2-B3A3-4DBC-A9E4-D65C80C1EBB0@employees.org>
Date: Tue, 30 May 2017 21:36:55 +0200
Cc: 6man-chairs@ietf.org
To: 6man WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 19:37:02 -0000

--Apple-Mail=_CAF26CC0-41F5-4E9F-BB4B-EF75F6560BB4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The 6MAN chairs are planning the meeting in Prague at IETF99.

If you have a draft you would like to discuss, please send your request =
for agenda time to the 6man chairs.   Please include in the request, the =
title of the presentation, file name of the draft, the speaker's name =
(and email), and how much time you would like.

We will prioritise drafts that are working group items and drafts that =
have been actively discussed on the list.

We expect at least half of each talk=E2=80=99s presentation time to be =
used for open discussion,
please plan your presentation accordingly.

New drafts not discussed on the mailing list prior to the meeting,
or drafts that do not appear to have support from the working group are =
unlikely to get time at the meeting.

Please have agenda items to us by 2017-07-05.

Regards,

Bob & Ole

--Apple-Mail=_CAF26CC0-41F5-4E9F-BB4B-EF75F6560BB4
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

iQIcBAEBCgAGBQJZLcnXAAoJEL7aWKiYQt92bCoP/Rmp3pi1AK94oLniEeDInFeT
r7N6f7p9NCJ7gx5ez7qDNYIduDOEv26nTggHIbjREldql3KlOgQtHroCYiVgaYlc
joisNo0+GKLyOl6USI81bHt+zAzMb9FXifvScxAgbU9Ff4Yopir1oZtZCf6a7MrJ
8DuD78UHDIGLnsCYFi/eBQl8ijTEBH/q+ZI+vSUsZvKL4CtgKDQzKMjC0BtRLOGv
QgzndjIsGPY7HYvUWGQyuFJpgsJr3R1wiQUWiKmCoxnNfB5HND093/+T4DyG8W1R
PCisg84DaayihC2cg/2NHXYjCWXUGO5dHc+QbF8Fi9iJFhFwwbX1dYQDxBu56WMv
36lK4XYhNDfFjId89q2IgzOxaHQlDRKKyJCQfx7q1/n6IOtMxn9EGE3PQPP9NxvI
hEWMtoXvlgNNSJDSR7OsesahVBHCAmGCni6agNteHcsr4RhpSkjG/8drooMki1dC
rYkSpb1OxRsCueM2UnhTbHXj0pBj3RdB1JnNEepGs55MMb5WC6e+DjtUAdtkLAc+
P+b3gJs27+r6wAsd1DQ8PkxzPcymJljTrnvFKkA5Uah4yAxWqh3vczMJSJ+RWqre
EcwFI2WZxcKVrojQkGkwWXEnUIEG1+nZYJYiG7967OWsgJWDC77CcyGchZmwPX55
JYQCgn2GZLGHxT6bv+hL
=NA9s
-----END PGP SIGNATURE-----

--Apple-Mail=_CAF26CC0-41F5-4E9F-BB4B-EF75F6560BB4--