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

Joel Halpern <> Thu, 05 September 2019 19:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60282120271; Thu, 5 Sep 2019 12:52:16 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HfcL2uBnr47c; Thu, 5 Sep 2019 12:52:13 -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 CF6D3120B1F; Thu, 5 Sep 2019 12:52:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=eMMC0uG0OCW03pU5C7bJ3d33RMUp+KiLz03EQuAzn4qqiqjbdBEoY1Ge8+rBx+1MC5DG92/iONZNuO1niKxaVDFglKm1cgLs81sOk+3FeWF8p7Ff+piMeeipNOTT6gq2ln9V9Xdb+LGWUtH0cuHOC6ZJcJE1CPetaNtQ3Y1I8nsJxcfAQAwocGQsqBabMamgA2dyG3kkcg6EuE44dDJ9OqVeAqdg8xyr6gzKh2oxlrCxTtF5zpEnmS618sGRPbLaP7kgceyaHiAxYy0YBs4wEE+sRnPlO91KI0fGu4+5qORMSyZ6hrRr0qjmBa23Z2okdOy6kAGNz7Rklbvgl/qAEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XCxxQ5LD+sRkqtzdH96Q/6K1c72es+vyDggGQMP+Ozg=; b=mPZo5f/VK8tI3s4Kvn47j5miDuFMCce5mh4lsRrRjqqieJDTDZxab48E6P6tfcTQQz0NgPqCqoGRmt+IT8VUT9bNKrULV9C5dlNMlt9QbXnC7TBeJUeXBPhveTbLAOr2glD2Jcykkt30/ysJWnOzBZNIAA8QIUbvYYxCCMi37EdF7zeANFvLw0sCxp8YsrfOWW1Nn1DfeK9liKgIOg841wG6lFcBEbiNGqeTxaW7Xx/xm75i2tFum0PK2Zh2Qlaft4z3VmWFsgETP8kQfNSi5JeNa3h09aWqK99mDNvrp0ru28J58TohQWsGOFucpIaWaRQ09DhWxPy4WNjsp1M6Lw==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XCxxQ5LD+sRkqtzdH96Q/6K1c72es+vyDggGQMP+Ozg=; b=M9khvTDMdZYanB4DeVN5Wr9tKI7OZcStnaS4ZxYR5cpYB2V43LD2FwupU+Zke5zThDHCQ+jjnAl7ba42ZIdOzcDGjcZF6Q3ry8zImsfIXPA++fv13cBXfN3s9lSN770fKxJGFk1kpK+Db6onjvVeLCZ4/d0oHSGDlrZ27BoD7YE=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.14; Thu, 5 Sep 2019 19:52:10 +0000
Received: from ([fe80::800f:edf:9de0:f599]) by ([fe80::800f:edf:9de0:f599%3]) with mapi id 15.20.2241.014; Thu, 5 Sep 2019 19:52:10 +0000
From: Joel Halpern <>
To: Bob Hinden <>, "Templin (US), Fred L" <>
CC: Suresh Krishnan <>, "" <>, Bob Hinden <>, IESG <>, "" <>, "" <>
Thread-Topic: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
Thread-Index: AQHVZBvKecoGiJzHVk2cUXnQkuG0yKcdeUMAgAAFVDI=
Date: Thu, 5 Sep 2019 19:52:10 +0000
Message-ID: <>
References: <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f13636cb-d4d8-4e8a-2b11-08d7323a8a63
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BN8PR15MB2881;
x-ms-traffictypediagnostic: BN8PR15MB2881:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 015114592F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(366004)(376002)(136003)(346002)(189003)(199004)(13464003)(53546011)(26005)(446003)(2616005)(11346002)(486006)(6506007)(476003)(36756003)(44832011)(8676002)(7736002)(31696002)(561944003)(86362001)(81166006)(81156014)(8936002)(76176011)(102836004)(186003)(91956017)(6116002)(66946007)(76116006)(14444005)(25786009)(71190400001)(99286004)(110136005)(66476007)(66556008)(66066001)(256004)(54906003)(6512007)(31686004)(6246003)(71200400001)(316002)(3846002)(53936002)(66446008)(64756008)(6436002)(2906002)(229853002)(6486002)(4326008)(66574012)(478600001)(5660300002)(54896002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR15MB2881;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: dXenTbl3thNqPIyEhkFjnYwG5iR5SInxui//Kr8G2vGKmUuPp1i8YPClNwvJ8t0Osh9aDXuKLyHT0YOHqJE0uoDxlMozghw1s4n4/rYTfAlwLMgpewtQDDjjXhwQ3bF0jPWs6dJT42VjzrrIAfKPJUeij1tXayiIyErNBya2EjPJ9NXN7BCW7JRq7ruk+Rh9nuwvEHYxqbWz8QkGu7txN5nFaSJOWhErIvyMp3d3szQdhbuVGrgEBSgnAkzdeLM3TfucPU9mJCggBJLhpyw10UhhIBDI5ifeNIdtCXVxo/2i7PVxvEMVkjQVOmf6oOqvuQ12x7M8/+szWAQoiOsTHQzSn/rvRDqn39BptFZK1OfTyHbUiDHy1+I6ujFX6zjwc2fnLubKIpLGgiYC0nBusMH2Aw4oEboFX7JPnWVwlB8=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_d1806bb3a8f744dcace7084485958838ericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f13636cb-d4d8-4e8a-2b11-08d7323a8a63
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2019 19:52:10.4982 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: oSrV5adDZhindbvqtTVULcysfTfhI8voMGP7PjoW+6+sSBXfGmjTQIevuV0SH70lD0TDqAcKAzgCwHFql/wZOPx1CJD1rYKpN3AENc1Da4g=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR15MB2881
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: Thu, 05 Sep 2019 19:52:17 -0000

It seems to me that Fred's proposal takes us into the area that the text says we are not dealing with.

Sent from Workspace ONE Boxer

On Sep 5, 2019 21:33, Bob Hinden <> wrote:


> On Sep 5, 2019, at 11:57 AM, Templin (US), Fred L <> wrote:
> Bob,
> Your effort is appreciated, but IMHO does not quite go far enough. Here is
> a proposed edit:


> OLD:
>   Protocols and applications that rely on IP
>   fragmentation will work less reliably on the Internet unless they
>   also include mechanisms to detect that IP fragmentation isn't working
>   reliably.
> NEW:
>   Protocols and applications that rely on IP
>   fragmentation will work less reliably on the Internet unless they
>   also include mechanisms to detect that IP fragmentation isn't working
>   reliably, or encapsulate their fragments in protocol headers that can
>   traverse fragment-dropping middleboxes.

I am not sure we want or should add specific mechanisms here.  Encapsulation is one approach, but there are others.


> Thanks - Fred
>> -----Original Message-----
>> From: Int-area [] On Behalf Of Bob Hinden
>> Sent: Thursday, September 05, 2019 11:29 AM
>> To:
>> Cc: IESG <>rg>; Joel Halpern <>om>;; Suresh Krishnan
>> <>om>;
>> Subject: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
>> Hi,
>> Based on the discussion, I would like to propose to see if this will resolve the issues raised.   It attempts to cover the issues raised.
>> The full section 6.1 is included below, but only the last sentence in the second paragraph changed.
>> Please review and comment.
>> Thanks,
>> Bob
>> 6.1.  For Application and Protocol Developers
>>   Developers SHOULD NOT develop new protocols or applications that rely
>>   on IP fragmentation.  When a new protocol or application is deployed
>>   in an environment that does not fully support IP fragmentation, it
>>   SHOULD operate correctly, either in its default configuration or in a
>>   specified alternative configuration.
>>   While there may be controlled environments where IP fragmentation
>>   works reliably, this is a deployment issue and can not be known to
>>   someone developing a new protocol or application.  It is not
>>   recommended that new protocols or applications be developed that rely
>>   on IP fragmentation.  Protocols and applications that rely on IP
>>   fragmentation will work less reliably on the Internet unless they
>>   also include mechanisms to detect that IP fragmentation isn't working
>>   reliably.
>>   Legacy protocols that depend upon IP fragmentation SHOULD be updated
>>   to break that dependency.  However, in some cases, there may be no
>>   viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
>>   in-IP encapsulation).  In these cases, the protocol will continue to
>>   rely on IP fragmentation but should only be used in environments
>>   where IP fragmentation is known to be supported.
>>   Protocols may be able to avoid IP fragmentation by using a
>>   sufficiently small MTU (e.g.  The protocol minimum link MTU),
>>   disabling IP fragmentation, and ensuring that the transport protocol
>>   in use adapts its segment size to the MTU.  Other protocols may
>>   deploy a sufficiently reliable PMTU discovery mechanism
>>   (e.g.,PLMPTUD).
>>   UDP applications SHOULD abide by the recommendations stated in
>>   Section 3.2 of [RFC8085].