Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

Ole Troan <> Mon, 30 July 2018 13:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B9D91310F5; Mon, 30 Jul 2018 06:59:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DJD2tf_aKqha; Mon, 30 Jul 2018 06:59:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DAA4F1310D4; Mon, 30 Jul 2018 06:59:22 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 691242D4F96; Mon, 30 Jul 2018 13:59:21 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 5D3562033EFF36; Mon, 30 Jul 2018 15:58:01 +0200 (CEST)
From: Ole Troan <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_94ABBB93-DEFD-461A-885A-9E5A6C81D567"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Mon, 30 Jul 2018 15:58:00 +0200
In-Reply-To: <>
Cc: Mikael Abrahamsson <>, "" <>, "" <>
To: Joe Touch <>
References: <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <>
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
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: Mon, 30 Jul 2018 13:59:35 -0000


> My model describes the rules under which translation devices can operate correctly and predictably in the Internet model.
> There are only a few alternatives for devices not explained by either model:
> 	1- the Internet and my model are incomplete
> 		in that case, you’re welcome to provide one for the new device
> 	2- the Internet and/or my model are incorrect
> 		in that case, you’re welcome to explain why
> 	3- the device should be considered incorrect and itself corrected
> Un-doing fragmentation at IP is an attempt to jump to a solution for #1 without explaining WHY, other than “we need to do this to fix the Internet to support these new devices”.
> I don’t think we should break known models to adapt to devices whose behavior might never be correctly accommodated.
>> Take A+P (RFC6346), and it's instantiations through e.g. MAP-E (RFC7597). That's essentially normal longest match forwarding on addresses and ports.
> So? Any device that sources packets with addresses it owns IS an endpoint on the Internet. Nothing changes based on how it translates those devices to the private side.

Could you please read those documents and explain how A+P fits in your model?
Note an A+P router does not translate, it forwards based on address and port. And as a normal router those addresses (and ports) are not identifying interfaces on the router, but on some end-system further away.

Best regards,