Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

Joe Touch <> Wed, 11 September 2019 04:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17EF912026E; Tue, 10 Sep 2019 21:51:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id na0UosY22egi; Tue, 10 Sep 2019 21:50:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6499A120168; Tue, 10 Sep 2019 21:50:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=J1EDFQFKfkrb+cYH6wnOnyeWVu7ljRO3xGg5FhCdeqs=; b=XnNe6wArWcCLh4Vh9U3CQSwBy 6h/c1iDM7mbXBOSOOYwCI4Bybzcce9SMvmXXOHAz8tIhV/SnUjcTIaL36bODmkrSOCZ+f2eoV3dSC eR3/Bm2EsEsut2q+GSDjKvW6uTOGnvPvRH0R1suBf6tsigtTe1XkQmvj69KnDnubGVZNqxmMqazHt r4imLywwgJk8dffu6EsqVSPatrycOK+EJ5u9GShftxMOXwEBud3/fpIpGPjFzvPuW0+uHZLOWkg/q G77CwqCVtRDmHLj0J3IvTyKapGMOQ7iZAHG0s7nNy0c9B1U83C5shw5XoG8e9UUkv1KAl1sdzJMRS Dz/ueyNqQ==;
Received: from ([]:52379 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1i7uai-001LBI-95; Wed, 11 Sep 2019 00:50:56 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <>
In-Reply-To: <>
Date: Tue, 10 Sep 2019 21:50:51 -0700
Cc: "Templin (US), Fred L" <>, Fernando Gont <>, Bob Hinden <>, "" <>, "" <>, IESG <>, Suresh Krishnan <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Geoff Huston <>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Sep 2019 04:51:00 -0000

First, IPv4’s minimum is 68, not 64. The header can be up to 60 octets and the smallest fragment is 8 bytes.

Second, the problem with the logic that “bigger avoids fragmentation” is that the very specification of ANY minimum MTU, coupled with IP-in-IP tunnels (for their own sake, or as part of IPsec tunnel mode), ends up then requiring fragmentation. There’s no way around that - once there’s a required minimum and once it’s recursive, the game is over.

(BTW, the only thing that bails you out is to then ensure you have fragmentation and that the receiver reassembly minimum is large enough to cover two fragments, one as large as you can fit as a payload and the other that fits a payload at least as large as the rest of the MTU).


> On Sep 10, 2019, at 3:53 PM, Geoff Huston <> wrote:
>>> This would seem to be incorrect. IP has a minimum MTU of 68 bytes, and
>>> IPv6 has a minimum MTU of 1280. Hence if you send packets smaller than
>>> or equal to the minimum MTU, the packets should go through.
>> Even if the original source uses the IPv6 minimum MTU of 1280, a tunnel somewhere
>> further down the path could add encapsulations that would cause the (encapsulated)
>> packet to exceed 1280 bytes. The tunnel therefore has to apply fragmentation.
> I hesitate to venture into this thread but I did a bit of digging around in the mail archives some time ago to figure out “why 1280?” as the IPv6 MTU. The desire was to lift the minimum unfragmented packet from 64 bytes (IPv4) to something that would reflect what was possible that would all but eliminate the need for fragmentation in IPv6. But at the same time there was the awareness of various forms of encapsulation and the possibility of multiple levels. 1500 octets was taken as the stating point and in the end 1280 was proposed. Why 1280? Because its the number you get when you add 1024 and 256. However, it expressed a basic idea that 1480 (IPv6 in IPv4), 1460 (IPv6 in IPv6), or any other number ‘close’ to 1500 could not. It allowed for almost any form of encapsulation of an IPv6 packet that we would be likely to see and the result would still  be within the 1500 ethernet framing limit and hence avoid a path MTU mismatch. From this starting point it is odd odd to see an argument about packet size that _starts_ with 1280 as some lower level media-related packet limit (it isn’t) and then applies encapsulation models on this. If we really are going to go through such an exercise then it would be more realistic to start with the number 1500 and apply encapsulation to that number. 
> Secondly, it is interesting to look at what IPv6 stacks actually do with local MTU values. Do they all use 1280? nope! The most common value is 1430. (see 
> So I personally don't see any practical value in this line of logic that says: "start with a source using a MTU of 1280 and apply encapsulation”
> But I’ve said enough - I’m heading back back to lurking in this rather protracted and messy thread.
> g