Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-00.txt

Brian E Carpenter <> Wed, 15 August 2018 23:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EF83130E01 for <>; Wed, 15 Aug 2018 16:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ax29xadzSR_t for <>; Wed, 15 Aug 2018 16:14:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8AFF0130DE0 for <>; Wed, 15 Aug 2018 16:14:09 -0700 (PDT)
Received: by with SMTP id i26-v6so1113013pfo.12 for <>; Wed, 15 Aug 2018 16:14:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LxwIM2AvjHiElqgODzexiTMaveaonUVkcrGaF1Fn9Yc=; b=LT+fwXVxlYLKNcyiJup6jwQWQfOTZoZ2TalxZJyfHhEKsF9gwHV8AZVUBVsZ37Uk3I dVV4ElvlsWpPfntoArL62UrXB93CuVgEpInLDYdz/UyLPAy0j0WJ7w2M/Z/FMGlGua7p V11dRGBEuM/cLErDIBYdV0tSbZuGwS7TeOFMqpyTHAHl/ppNgtrZ9fYYaiI0gBKoX4e0 hEYHjbuiGcE4n47ybuHjk2QxDymKugoqL+GAGhQiUvDE5as+Z6xgiQrfd0yr8oe17cBH OwNv0l2llt1B0nXvM7Y2sF0+Lcnmd7SC1B1vtPVoNB3NAbq2enKNCFDwk9p1qvvgG6B5 GUYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=LxwIM2AvjHiElqgODzexiTMaveaonUVkcrGaF1Fn9Yc=; b=SjVCSL4mE91H8rSM5jouO4ck1mts9b8cSQJNL6w8IgsYZ8JkzF4nuvob4svTyhKpsF v2XmX46k3oBC8eIItnYfPz0ptICN23shy3rf0weg+uzOm81GaAo4kQlRdfYwGBh5wHZR dnVmBwBREFvuh+mTfBOjI7Ov/+4PU4PpUm+RX6ZmdImNIUaI9BCx3YaII9ZlLFfXwKn9 rWu0tWaNSPknVk4a7q66TARI1VeNPDquzHdF+YJanPk2yM/ANj+ZvLzmxLchmLBfjd11 zrD2Lhp4mzuI4Z4n58bx4RKdVd8077OK07w6l+/cgSDsd3IT45CeFLDVEalDbdf/8Tit FKUA==
X-Gm-Message-State: AOUpUlEDt6dlXQglFPRW7OIFkq6hC6nsGkCdVGE4jKrX3CkxjQ9Oh6k/ TV63JFw6oirAR2GTRirldS3Sp8WE
X-Google-Smtp-Source: AA+uWPyZyGrJM+tG+I5Ukfko6iAWLcDF6oISdAl/kYSM3kdxrOhpn/w7AgB9ZDTdeTfR1YW8M4IUQw==
X-Received: by 2002:a65:62d8:: with SMTP id m24-v6mr27113294pgv.307.1534374848789; Wed, 15 Aug 2018 16:14:08 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id k23-v6sm406338pgl.42.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Aug 2018 16:14:07 -0700 (PDT)
References: <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Thu, 16 Aug 2018 11:14:10 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-00.txt
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Aug 2018 23:14:11 -0000


Earlier I said:

>>    Application developers SHOULD NOT develop applications that rely on
>>    IPv6 fragmentation
> It isn't obvious to me that this is an algorithmic requirement. If the application
> runs over TCP, how does the developer ensure that TCP will use an MSS that
> avoids the need for fragmentation? (The UDP situation is a bit clearer, but
> RFC8085 introduces considerable complexity, unless we accept that the
> Internet MTU for UDP is 576 or 1280.)

I've looked into this a bit for the UDP case, which doesn't have
the added complexity of MSS negotiation.

The only surefire way of avoiding fragmentation is to switch it
off. The recipe for doing that varies by operating system and version,
and between IPv4 and IPv6. (I have Python code that I've exercised
on Windows 7, Windows 10 and Linux. Thanks to Tom Herbert, Praveen
Balasubramanian and Nick Grifka for advice.)

Whether that automatically solves the problem depends on whether
PMTUD works, which is unpredictable. Therefore, if you want a protocol
*design* that is universal, it can't depend on PMTUD. Disabling 
fragmentation on its own is not enough. (That isn't news.)

The only universal solution therefore seems to be a fully specified
PLPMTUD solution, either built into the protocol design, or available
as a normative reference. I think that would be a better
recommendation than simply saying "don't rely on fragmentation."

IMHO RFC4821 isn't a sufficient normative reference for this.
Possibly draft-ietf-tsvwg-datagram-plpmtud will do it for UDP-based
protocols. But IMHO we need a solution for each transport protocol,
with widely available libraries.