Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - MTU

Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 27 July 2020 10:25 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC6C3A184A; Mon, 27 Jul 2020 03:25:47 -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_MSPIKE_H2=-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 h8fxkIGpV3qc; Mon, 27 Jul 2020 03:25:46 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 1DB743A1850; Mon, 27 Jul 2020 03:25:36 -0700 (PDT)
Received: from lhreml714-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B9C35C89FE7EAA2C1A7F; Mon, 27 Jul 2020 11:25:34 +0100 (IST)
Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml714-chm.china.huawei.com (10.201.108.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 11:25:34 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 13:25:33 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 13:25:33 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>
CC: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" <draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org>
Thread-Topic: Operational Implications of IPv6 Packets with Extension Headers - MTU
Thread-Index: AdZj8f/Upo2wn+ELR6mdAuOglYKu+v//13aA///Jm1CAAEDwgP//xhQQ
Date: Mon, 27 Jul 2020 10:25:33 +0000
Message-ID: <f35b0d6182eb4cce88f89681cac28184@huawei.com>
References: <678838bf6f0549689268a571498332d1@huawei.com> <9e9bf619-28fe-7238-6d62-53d5a814935a@si6networks.com> <446331e9ebc84c88a9197a27b169710e@huawei.com> <62bddb45-a88b-48f1-ff78-ea587e6ef75e@si6networks.com>
In-Reply-To: <62bddb45-a88b-48f1-ff78-ea587e6ef75e@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.200.156]
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/U72JdtUHtPRZ1Nu8cHkRLhrjrxA>
Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - MTU
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2020 10:25:48 -0000

If User would lose connectivity
Because additional EH increased packet size
And packet would be dropped.
Then it is the problem of Carrier.

There are a lot of recommendation how to avoid drop that happen as a result of bigger MTU demands.

-----Original Message-----
From: Fernando Gont [mailto:fgont@si6networks.com] 
Sent: 27 июля 2020 г. 12:56
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; IPv6 Operations <v6ops@ietf.org>
Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org
Subject: Re: Operational Implications of IPv6 Packets with Extension Headers - MTU

On 27/7/20 06:39, Vasilenko Eduard wrote:
> Hi Fernando,
> It is more important to have the problem mentioned on the list, then the quality of the section itself.

I fail to understand what's the MTU problem you are referring to.  the Path-MTU being reduced as a consequence of the use of EHs? something else?


> It is definitely a problem if one would like to activate any EH - potential admin should be warned.
> What could be inside:
> - small discussion that fragmentation in the middle of IPv6 path is not possible
> - some IPCMPv6 messages should not be filtered
> - MTU is better to change on networking links

That seems to be unrelated with this particular document.  If anything, 
MTU issues are a problem to the folks at both endpoints of an application.

But this documents is concern with the operational challenges 
represented by EHs. i.e., why operators need to deal with them.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492