[v6ops] Re: [tangential] Re: Re: [DNSOP] Re: draft-hinden-v6ops-dns

Nick Hilliard <nick@foobar.org> Fri, 21 June 2024 11:33 UTC

Return-Path: <nick@foobar.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BB1B3C14F6EA for <v6ops@ietfa.amsl.com>; Fri, 21 Jun 2024 04:33:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.26
X-Spam-Status: No, score=-7.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.355, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kRf4GdIP902s for <v6ops@ietfa.amsl.com>; Fri, 21 Jun 2024 04:33:18 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4F7C14F749 for <v6ops@ietf.org>; Fri, 21 Jun 2024 04:33:17 -0700 (PDT)
Received: from cupcake.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netability.ie (Postfix) with ESMTPSA id DB17CB0614; Fri, 21 Jun 2024 12:33:12 +0100 (IST)
To: Daryll Swer <contact@daryllswer.com>
References: <fd1d0d11-3030-d2e2-c5b1-a218ed82e1c4@redbarn.org> <428ecc78-b18f-a0e9-8a44-58d63e269afb@foobar.org> <CACyFTPHLYWxdR+VqzXAy4hs1PXjAON-+_CwFWUmCYceBH53xUQ@mail.gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <8c45b8a8-4650-08c8-4db9-baef3ad69b32@foobar.org>
Date: Fri, 21 Jun 2024 12:33:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.60
MIME-Version: 1.0
In-Reply-To: <CACyFTPHLYWxdR+VqzXAy4hs1PXjAON-+_CwFWUmCYceBH53xUQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------9726C2C8F9C9CD660EA8C5B0"
Content-Language: en-US
X-MailFrom: nick@foobar.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Paul Vixie <paul@redbarn.org>, v6ops@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: [tangential] Re: Re: [DNSOP] Re: draft-hinden-v6ops-dns
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/l6nqA2ee8gP7H2IAMY9szQUF_nI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>

Daryll Swer wrote on 21/06/2024 12:10:
> Just to clarify, transport MTU == L2 MTU, protocol MTU == layer 3? And 
> Path MTU == layer 3 MTU across the path from A to B?

yep correct.
> For transport (L2 MTU), it's far in excess of 1518 bytes as default 
> config on a lot of networking equipment already, though the default is 
> typically not big enough to auto-magically accommodate 9k L3 MTU end 
> to end (sadly).

If you want some eye-opener real-world cases:


i.e. maximum configurable MTU differs both by platform and according to 
the interface on the platform, and if you say: "well don't use that kit 
then", I wouldn't argue the point except to say that there's a lot of 
kit installed out there in the world, by lots of different 
manufacturers, which does really weird and unexpected stuff.  Many major 
manufacturers still default to 1500, even if the underlying silicon 
supports something larger.

> As Paul Vixie said below (and more), I don't see how exactly is it 
> wise for the process of digging a hole for this 1280 magic number, 
> instead perhaps, we should have serious discussions about increasing 
> the general L3 MTU (from 1500 to something significantly larger, 9k 
> being ideal), and of course that would involve non-IETF territory of 
> layer 2 MTU (IEEE).

Again, I don't disagree that magic numbers are a poor idea, but this is 
a problem that needs to be addressed at several different levels. 
Assuming that we had good quality proposals on the table, would take 
several generations of kit to fix.

The thing that makes fixing the MTU problem so difficult is that the 
failure mode is both terrible and usually irrecoverable except by 
operator intervention. Any proposed fix needs to take this into account, 
because the only thing worse than MTU=1500b is packets and higher layer 
sessions being silently black-holed.