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

Gert Doering <gert@space.net> Mon, 27 July 2020 17:14 UTC

Return-Path: <gert@space.net>
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 238923A1AD9 for <v6ops@ietfa.amsl.com>; Mon, 27 Jul 2020 10:14:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.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 EFyFr-ouc9QH for <v6ops@ietfa.amsl.com>; Mon, 27 Jul 2020 10:14:22 -0700 (PDT)
Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 536763A1ADB for <v6ops@ietf.org>; Mon, 27 Jul 2020 10:14:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1595870062; x=1627406062; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=sQKQ9+iJh3+OmZsqU3bnLSq7COuSAOwnHIjbqTUz6GI=; b=Cp5G2l43k1emjwu4BttVTZQdVhk4APt843SfRaC3r7497Scxldp5ARH0 ykzm9K1BEC1ifc5T/VZtK5cl3MN5I23KGc32uoJQZY1Md27nscThuwTN/ yFxhXcfEnZhfyevGiYXHX58So3p6S6giZcHYJQiNVwfndRWdMP2groKJt IxThln0+7PEWYrLU9Zd0QeaN0yaJI09OdX+aN2ecc3HxgfhDhp54rPynd XWE+COW4kNiFgITrJiVgFeAKd1nioaZ4VNtKeU2EgUPmJ6Em+JVxkn0NT rHDX+ATSjwUhRNlEhIn8jNqQEDGvOw6rZNGIvDUD4kpx6GHQxM6xSebYc g==;
IronPort-SDR: v856mOx0b/6mI/+pxq4QTnSe5M0YRcvrrSsBbcwWMlbLjT3EVnW6mYykXbLXF6U/zcGrcWgpHU clvbpYbtg3wfnhAH7VNcAle1RMazT58QIj6P+lnJANuSp9KAO7mTHg8IfznE+8lsb/dI/joqAZ wu0jQnZWNBVEq2lRiVFFOkMkEb4caqEQo3rQo+t6x3gCJJ2s+quuXmvExdpd12ZxoluMQbLRjd ALd+RirH0GP4K/uqiBokg+RHPNdy9UM05R4UCH+Vfra+qbNY04F1ouEWmVI33Tt5OHGJcSoDYi tSY=
X-SpaceNet-SBRS: None
Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jul 2020 19:14:16 +0200
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 04B2941C04 for <v6ops@ietf.org>; Mon, 27 Jul 2020 19:14:16 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id B8F1541B91; Mon, 27 Jul 2020 19:14:15 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id B3F2A151CB; Mon, 27 Jul 2020 19:14:15 +0200 (CEST)
Date: Mon, 27 Jul 2020 19:14:15 +0200
From: Gert Doering <gert@space.net>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" <draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org>
Message-ID: <20200727171415.GJ2485@Space.Net>
References: <678838bf6f0549689268a571498332d1@huawei.com> <9e9bf619-28fe-7238-6d62-53d5a814935a@si6networks.com> <446331e9ebc84c88a9197a27b169710e@huawei.com> <62bddb45-a88b-48f1-ff78-ea587e6ef75e@si6networks.com> <f35b0d6182eb4cce88f89681cac28184@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <f35b0d6182eb4cce88f89681cac28184@huawei.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/nKeg5x8rxQBk7wzUn04nYvFDDp4>
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 17:14:24 -0000

Hi,

On Mon, Jul 27, 2020 at 10:25:33AM +0000, Vasilenko Eduard wrote:
> 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.

MTU issues (and any other sort of IPv6 misconfiguration at the end systems)
are out of scope of this documents.

There are many reasons why an end system would want to send a packet that
is too big, and EH-or-not does not make a material difference to
"application requests too-big UDP packet" (like, DNS).

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279