Re: New Version Notification for draft-herbert-6man-icmp-limits-01.txt

Tom Herbert <tom@herbertland.com> Mon, 22 May 2017 15:44 UTC

Return-Path: <tom@herbertland.com>
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 <ipv6@ietfa.amsl.com>; 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 <ipv6@ietfa.amsl.com>; 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: <BLUPR0501MB205124119EB2B1C66B81CF7EAEF80@BLUPR0501MB2051.namprd05.prod.outlook.com>
References: <149445467475.16592.8251449526718380823.idtracker@ietfa.amsl.com> <CALx6S362u-h8sY2b75JNTM9Q79o4WtuMYjwb_6qCjoKRMT3TJA@mail.gmail.com> <BLUPR0501MB20516F352D73979BADF94CC1AEE10@BLUPR0501MB2051.namprd05.prod.outlook.com> <CALx6S37i6EmG=QLXemjGG=zeRSHRPE_WuFVNaP_w27PkYUUzMQ@mail.gmail.com> <BLUPR0501MB205123058A1945806A149F0AAEE10@BLUPR0501MB2051.namprd05.prod.outlook.com> <CALx6S36zo_aPRxN8ZheOy2JA-iOAhD-6m-SY-jxk5H0+2t_53Q@mail.gmail.com> <BLUPR0501MB205163C6A42CA608D5A9B616AEE60@BLUPR0501MB2051.namprd05.prod.outlook.com> <CALx6S35h-=5tuzA0x27rivKqYegeW=bSAXx9-g005Gb4U07fPg@mail.gmail.com> <BLUPR0501MB20510CD93958FB03CF9B2687AEE40@BLUPR0501MB2051.namprd05.prod.outlook.com> <CALx6S348t=8SFwP4UNi5rQcqeV=LboTo8757KXU0_f0R6-VouA@mail.gmail.com> <BLUPR0501MB2051AE244DAAFC7160EC847EAEFA0@BLUPR0501MB2051.namprd05.prod.outlook.com> <CAO42Z2zZ9Vf53ovSW2BSEixAZeBQ8yAn9XzO4MSEPH6J8gcR9w@mail.gmail.com> <BLUPR0501MB205124119EB2B1C66B81CF7EAEF80@BLUPR0501MB2051.namprd05.prod.outlook.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 22 May 2017 08:44:02 -0700
Message-ID: <CALx6S35SDb8GbvmvQZq8ByB6PTNVr9RXJMKjD55MsLrUmx9soQ@mail.gmail.com>
Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
To: Ron Bonica <rbonica@juniper.net>
Cc: Mark Smith <markzzzsmith@gmail.com>, "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Tgo7fzJGo1wALxloRKhEcrOgvGA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 May 2017 15:44:06 -0000

On Mon, May 22, 2017 at 7:09 AM, Ron Bonica <rbonica@juniper.net> wrote:
> Mark,
>
> Strictly speaking, Destination Unreachable is appropriate whenever a packet 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 could 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. That 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 to PTB. If HTL information hitchhikes on an existing ICMP message, that message 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 <rbonica@juniper.net>
>> Cc: Tom Herbert <tom@herbertland.com>; 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 <rbonica@juniper.net> 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 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
>> 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 <rbonica@juniper.net>
>> >> 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 <rbonica@juniper.net>
>> 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
>> > --------------------------------------------------------------------