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
- [v6ops] Operational Implications of IPv6 Packets … Vasilenko Eduard
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Vasilenko Eduard
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Nick Hilliard
- Re: [v6ops] Operational Implications of IPv6 Pack… Vasilenko Eduard
- Re: [v6ops] Operational Implications of IPv6 Pack… Gert Doering