IETF Logo Mail Archive

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

Fernando Gont <fgont@si6networks.com> Mon, 27 July 2020 10:04 UTC

Return-Path: <fgont@si6networks.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 588333A181A; Mon, 27 Jul 2020 03:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 Dbm4iCa5w7Kz; Mon, 27 Jul 2020 03:04:33 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA7B3A1820; Mon, 27 Jul 2020 03:04:33 -0700 (PDT)
Received: from [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef] (unknown [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef]) (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 E115D283893; Mon, 27 Jul 2020 10:04:29 +0000 (UTC)
To: Vasilenko Eduard <vasilenko.eduard@huawei.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>
References: <678838bf6f0549689268a571498332d1@huawei.com> <9e9bf619-28fe-7238-6d62-53d5a814935a@si6networks.com> <446331e9ebc84c88a9197a27b169710e@huawei.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <62bddb45-a88b-48f1-ff78-ea587e6ef75e@si6networks.com>
Date: Mon, 27 Jul 2020 06:56:07 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <446331e9ebc84c88a9197a27b169710e@huawei.com>
Content-Type: text/plain; charset="koi8-r"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ygqPi5e6ayRHvO7W56ML2_9y1K0>
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:04:35 -0000

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

v2.23.0 | Report a Bug | By Email