Re: Is Fragmentation at IP layer even needed ?

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 10 February 2016 01:14 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67C31B343D for <ietf@ietfa.amsl.com>; Tue, 9 Feb 2016 17:14:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 YqkNI9RssKXr for <ietf@ietfa.amsl.com>; Tue, 9 Feb 2016 17:14:27 -0800 (PST)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393781B3436 for <ietf@ietf.org>; Tue, 9 Feb 2016 17:14:27 -0800 (PST)
Received: by mail-lb0-x234.google.com with SMTP id bc4so2313137lbc.2 for <ietf@ietf.org>; Tue, 09 Feb 2016 17:14:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=c5vigatrvfMfUY0QlAWM9CUPXu5XI9f/+OClMEjH2UA=; b=TrBu7WHp308NWF1m0QNKiaqpErAiviIprV9UU6ifdfCdS13dzEGtA3JIqaYC0iFRz/ gsf48dg3qD3iD25dp8yukkNrvku2HhfDrsHugthApeLcAhdFdCFWWQ3FBoy3Y/hPCHwO 8lLHHCy98U+lM1r7OcvyklmTd3eC8G0dR+it+I/wVBeGB9ptVl7c4ml47/v/x5xCubVa MuPIFbD6/OGsKHjwNwWM/wPmqXUWJnATsJtNNWskTJVErVQSqnJF4NQ3wxHWl8RsZk7m qTOsF2TkfALsFBAKPXxwkRc298WJQzfZq4EZ/ADqHhnUk1eV1YxGh9ZLFQKS6ohfrLAj DTvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c5vigatrvfMfUY0QlAWM9CUPXu5XI9f/+OClMEjH2UA=; b=H3dA9YNOi2+bjd8J9GFesvS5SGHb2/JkNtcXpqU6JfjSLxgHLuISnGClUeM6FJVP2e 27rHO/R93hPSPzNzf6JMNpuoDE0G7X982Td4DwtnS/Qko5C6Sb8SnNZoK67nwLaj9DfT tZgb8mqxF9Bqj/Dwce//JTC1GilBFr6c7oFq7Jk1aRArE6jeSCeRUAtnCT+8TYwPRa7N J4FiIm5IkKOEpGDjorq2MuRX4+Ury0CTf6tlflP3f9QxPDGAUDHJvePF+u9Qdd1utTym 6v7/1mPRUrKerCOvj1v+kET9yu84jMNp130p5+4IMGr9gBN1SiZkRILfRxebAgkfz8wI iNhg==
X-Gm-Message-State: AG10YOQTKnTpnFOUf0ix4UCk4BGEAV0TReo9m6gREl34IUgly3z/lihqHmjXslWaRoOhmoz5XXjAjwBzv6NyCQ==
MIME-Version: 1.0
X-Received: by 10.112.199.197 with SMTP id jm5mr12153657lbc.109.1455066865273; Tue, 09 Feb 2016 17:14:25 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.49.80 with HTTP; Tue, 9 Feb 2016 17:14:25 -0800 (PST)
In-Reply-To: <56BA739D.7060309@isi.edu>
References: <CAOJ6w=EvzE3dM4Y2mFFR=9YyPBdmFu_jkF4-42LjkdbRd3yz_w@mail.gmail.com> <BLUPR05MB1985F5F2BB3118362C67B921AED50@BLUPR05MB1985.namprd05.prod.outlook.com> <20160208200943.A615941B5B96@rock.dv.isc.org> <CAMm+LwgLoYpQ1TNOTOuJzh+cu+GyRBf9=y_K7K35boQ9WcZKjA@mail.gmail.com> <56B92A96.9050200@si6networks.com> <CAMm+LwifTXvVd1mPZOfcOOR03Fnj-82H9aDVS01=wGezePtnXw@mail.gmail.com> <56BA4BC7.1010002@isi.edu> <CAMm+Lwi-n=be4AWGibs+Zq9egYw5pSDmPGb-4P0LDEcX1E6osA@mail.gmail.com> <56BA68CE.7090304@isi.edu> <CAMm+LwiM2sFUeejgJZe650UQbVHrh7EHrEF2omvPrZJPodgJLA@mail.gmail.com> <56BA739D.7060309@isi.edu>
Date: Tue, 09 Feb 2016 20:14:25 -0500
X-Google-Sender-Auth: ObvQlK5CnZwHGJZvTMMPRG_Iy2E
Message-ID: <CAMm+Lwij1dOkK0b2ZnJiPMtba=wc823WgYjqw0iwAApa3KBYcg@mail.gmail.com>
Subject: Re: Is Fragmentation at IP layer even needed ?
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Cvh14cLnCXacCW7f2eJ0cAaf1_E>
Cc: ietf <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2016 01:14:28 -0000

On Tue, Feb 9, 2016 at 6:17 PM, Joe Touch <touch@isi.edu> wrote:
>
>
> On 2/9/2016 3:09 PM, Phillip Hallam-Baker wrote:

>> Lots of things are already deployed. You presented a corner case. I
>> pointed out that there is no need to handle that corner case in the IP
>> layer.
>
> That's very NIMBY of you.

Not really. A tunneling layer is going to have to deal with
fragmentation under your model.

[Since Joe doesn't seem to be responding to the argument I made, I'll
not flog that horse further]


>>>         - now you want that info even further obscured by another
>>>         layer of encapsulation
>>
>> No, you raised the tunnel in tunnel corner case. I didn't suggest
>> requiring anything of the sort.
>>
>> If your tunnel can't fit the input packet on a 64K clean pipe, then it
>> should have the responsibility to figure out how to fragment.
>
> As long as it doesn't use "your" protocol to do it (IP)? Why?


Because the Internet architecture says to keep the core as simple as
possible. IP fragmentation introduces complexity that should be kept
out of the core. That is why.

We needed that feature in the Inter-network in 1980. We do not need
that feature int the core today. So it SHOULD NOT be an IP feature. It
can be a higher layer feature, it can be a feature that can still be
used at the network level.

Tunneling, encapsulation, VPNs, IP-in-IP are all network activities.
They shouldn't ever occur on the Inter-Network by definition.


> Someone has to support tunneling somewhere. IP is intended to be the
> universal interoperability layer - which means that it ought to be the
> layer to support it.

No, IP is the Inter-network Protocol.

The universal interop layers are UDP and TCP.