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

Ron Bonica <rbonica@juniper.net> Thu, 05 September 2019 23:46 UTC

Return-Path: <rbonica@juniper.net>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E8D120043; Thu, 5 Sep 2019 16:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.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 wynnl_vsoyYy; Thu, 5 Sep 2019 16:46:13 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 2679612002E; Thu, 5 Sep 2019 16:46:13 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x85NirOL025403; Thu, 5 Sep 2019 16:46:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=AzUa+XgoS9ZSaE3dCPiAPWv5KHP/ZfyfH5E9300bs60=; b=AmkLRbhUTBsJrt8fq4piV/YHKQW6ygz96SkMDuexA6QH/7iKMFb9YQDRR/ejrUM/tBey GNL3ec279Xc73D4mZgZm2JtSbdIJtlQOgYjioo4yHu1PTdAQ1K4oplzaDU9RAHYAYtPi c8zjyN+A06aAFO4sWmcWLV8IOKLiyFrjLE3CD4uLSX1UwNdGT17LKlbGOhrubVQ+nux1 BMv77EW8ChFFbfevd3YXr7XNvFI8wTbSg0H9JP4nuBK/uLDwBJuLjCkKAbfTMa3PUvXH eZ27HzAz872gQZ0BiwJF9kvAi//E2iJiXhYll8RV6jvEgKAN8O4LqktbHHr7BRQelqyt 5g==
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp2053.outbound.protection.outlook.com [104.47.42.53]) by mx0b-00273201.pphosted.com with ESMTP id 2usmf7p4vv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Sep 2019 16:46:00 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MYMEiY8HGtQoD2qvkqL6vPwUrpWqaonOyDcNEW+cq87vr2fqCBgDdnU6GibtB5Ae0bj0ltuXQSp74LECMO0RfgO7mFCEslshUwEhx0QylfnsaxKWUF3Ik/a+Lm12gBNUVJhjO9zw0AwGlQ3JFJ9tCs8dYhspsY6x4J1os64goO3cYMKJ2rqHu/N8fuoayQNFvHS/SdCksZImngjY5JXf17p9EH77ZqzwQAGpihoIKWiO8B/7bVkld3CFt8xbQLROU/3MLFDz2TROaRiMq3AUil9ZYvsgb0wigqRRfaZKW8p6Q2ao22mBV83PbqJGEciV/XjnIL22XagXyoxP66PJvA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AzUa+XgoS9ZSaE3dCPiAPWv5KHP/ZfyfH5E9300bs60=; b=gneL0wyehtg1gKsUV+ebnxQ/G9OpMfmgaDDPWavVOE4ug5aFsNndiTavrnDQyYe9avxhSCobiUqnS9hqy2GVgz/eivBGF25uX5UFKEkcDoyl04KxMedUIKkehfwmODvQce8BzX0zJZRw0uLaWzzOsS9jDfl1AlMH4PTR9MdAL/KCQpV3L7IRUUW07F41ud+sa8kXGhhFa4XyDDtaNlR+qfHYD4RDcNHuegFK/d0BUYEri/YVjO+11H67/QPnDdZ3qGFhO+L48i39fZ24eolWncl11gkR2RZdaw6TmxfZFmb1m/DomnXj3RRzutRHrE6XW5RWfCU0PHKqDvrzePyLAw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
Received: from BYAPR05MB5463.namprd05.prod.outlook.com (20.177.185.144) by BYAPR05MB6502.namprd05.prod.outlook.com (20.178.233.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.6; Thu, 5 Sep 2019 23:45:58 +0000
Received: from BYAPR05MB5463.namprd05.prod.outlook.com ([fe80::f4f2:f284:d49a:890a]) by BYAPR05MB5463.namprd05.prod.outlook.com ([fe80::f4f2:f284:d49a:890a%4]) with mapi id 15.20.2263.005; Thu, 5 Sep 2019 23:45:58 +0000
From: Ron Bonica <rbonica@juniper.net>
To: Bob Hinden <bob.hinden@gmail.com>, "int-area@ietf.org" <int-area@ietf.org>
CC: Alissa Cooper <alissa@cooperw.in>, IESG <iesg@ietf.org>, Joel Halpern <joel.halpern@ericsson.com>, "draft-ietf-intarea-frag-fragile@ietf.org" <draft-ietf-intarea-frag-fragile@ietf.org>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>, Suresh Krishnan <suresh@kaloom.com>
Thread-Topic: Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
Thread-Index: AQHVZBfP88d2niPRWE2hHwQI6BMW6Kcdvzeg
Content-Class:
Date: Thu, 5 Sep 2019 23:45:58 +0000
Message-ID: <BYAPR05MB5463F112A3FFA8CE6378F3D3AEBB0@BYAPR05MB5463.namprd05.prod.outlook.com>
References: <efabc7c9f72c4cd9a31f56de24669640@boeing.com> <2EB90A57-9BBD-417C-AEDB-AFBFBB906956@gmail.com> <CAHw9_iKozCAC+8TGS0fSxVZ_3pJW7rnhoKy=Y3AxLqWEXvemcA@mail.gmail.com> <4C8FE1C4-0054-4DA1-BC6E-EBBE78695F1B@gmail.com>
In-Reply-To: <4C8FE1C4-0054-4DA1-BC6E-EBBE78695F1B@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-09-05T23:45:55.8930257Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=ad7ad570-01d7-46aa-929c-6d1fbcb46d3a; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
dlp-product: dlpe-windows
dlp-version: 11.2.0.14
dlp-reaction: no-action
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3f73550d-8904-4a03-ae2d-08d7325b3364
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB6502;
x-ms-traffictypediagnostic: BYAPR05MB6502:
x-microsoft-antispam-prvs: <BYAPR05MB65029E29A00F7B96926C97DBAEBB0@BYAPR05MB6502.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 015114592F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(376002)(39860400002)(346002)(366004)(396003)(51444003)(189003)(13464003)(199004)(5660300002)(8676002)(229853002)(81156014)(81166006)(8936002)(2501003)(186003)(55016002)(76176011)(6506007)(53546011)(25786009)(4326008)(476003)(11346002)(9686003)(53936002)(486006)(446003)(6116002)(33656002)(3846002)(102836004)(305945005)(6436002)(74316002)(6246003)(52536014)(66066001)(7736002)(26005)(66446008)(316002)(14444005)(14454004)(99286004)(54906003)(7696005)(2906002)(86362001)(256004)(110136005)(66574012)(66946007)(71200400001)(71190400001)(478600001)(66476007)(76116006)(66556008)(64756008); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB6502; H:BYAPR05MB5463.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: lqI9M3V4Fs7agqpaNQlA5rmuB3aVimnsZUmh0nLA9Op5UaKeN06WH2+azGzcYYnlMlMhA9ozwaySCPl6DIuotMZ6zxjPfSwnK9G/AfV20WfX/Cb7Hr4Jnbq5d7Coh6h9jAHrZ27O0L+ez4iwgijWTYF9aHhXqsXu96xIzGi2mXXf/xX5SR+jrUBoeUtS3DXqWq66vp4nSo7k6OHZoFD/Ck7pCLj0+pw3vlnpHWgPvXYmFfkfXrGvQR6tYynjv/1zVFMNIP0oj69av+ZnzDn45E4K+xEJ1lix9++osUUXUkblvR2LHrS/uZWoMVZRT/f/wtX2gGHbjSVOQ34PsS4MDgYdNiXU8980Nf+ogjnV8upXmAL0O2mnxUANqPEJ1yQs68J46DgYHooMDq/w6f5Gj8xrOmjDyUx1LhU59Ta4ZP8=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 3f73550d-8904-4a03-ae2d-08d7325b3364
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2019 23:45:58.0494 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yyDSSAzPox4VdD2VPTqZPnGrJR6lvuSJxkbPg0UHkAUe6H/D/pdxhaXoQ/zkYpnWPjNjvZXdyx4L5cZ3HhjlNg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6502
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-05_10:2019-09-04,2019-09-05 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 malwarescore=0 adultscore=0 clxscore=1015 spamscore=0 priorityscore=1501 mlxlogscore=999 phishscore=0 bulkscore=0 mlxscore=0 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1909050221
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/VW1FE5-3g4Xz5PO36mPcxGe02x4>
Subject: Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Sep 2019 23:46:15 -0000

Bob,

I think that this is a close to consensus as we are going to get.

                                           Ron


Juniper Business Use Only

-----Original Message-----
From: Bob Hinden <bob.hinden@gmail.com> 
Sent: Thursday, September 5, 2019 2:29 PM
To: int-area@ietf.org
Cc: Bob Hinden <bob.hinden@gmail.com>om>; Alissa Cooper <alissa@cooperw.in>in>; IESG <iesg@ietf.org>rg>; Joel Halpern <joel.halpern@ericsson.com>om>; draft-ietf-intarea-frag-fragile@ietf.org; intarea-chairs@ietf.org; Suresh Krishnan <suresh@kaloom.com>
Subject: 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].