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

Ole Troan <otroan@employees.org> Thu, 02 August 2018 15:38 UTC

Return-Path: <otroan@employees.org>
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 575A6130DEF; Thu, 2 Aug 2018 08:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 z-u0Gimm0DDc; Thu, 2 Aug 2018 08:38:49 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7BA124C04; Thu, 2 Aug 2018 08:38:49 -0700 (PDT)
Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id A92DF2D4FAA; Thu, 2 Aug 2018 15:38:47 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id C8CE523E713; Thu, 2 Aug 2018 17:38:45 +0200 (CEST)
From: Ole Troan <otroan@employees.org>
Message-Id: <62804AFB-A3A9-45E5-8EEB-EF46CB37AB0D@employees.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_40D15D70-C180-4B5D-BA14-FDE89453E148"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 2 Aug 2018 17:38:45 +0200
In-Reply-To: <1B04E207-08FA-400F-BBED-67379FEFD64E@strayalpha.com>
Cc: Tom Herbert <tom@herbertland.com>, int-area <int-area@ietf.org>, intarea-chairs@ietf.org
To: Joe Touch <touch@strayalpha.com>
References: <F227637E-B12D-45AA-AD69-74C947409012@ericsson.com> <0466770D-C8CA-49BB-AC10-5805CFDFB165@strayalpha.com> <6EDF0F79-C8F3-4F05-8442-FF55576ADDD0@employees.org> <alpine.DEB.2.20.1807271530280.14354@uplift.swm.pp.se> <CALx6S35LthDLRry7k-pF8KSoX4BXBA8kyArOpDUAcJMDCoLQpQ@mail.gmail.com> <alpine.DEB.2.20.1807280811540.14354@uplift.swm.pp.se> <8640DCF6-A525-4CF7-A89D-2DEDBF0FADC8@strayalpha.com> <FFF1C23B-7A24-46BC-929E-DD56C77D69A2@employees.org> <A248CA44-B568-4CB9-B450-067B1845AF9B@strayalpha.com> <CALx6S36w=5J0-=JQqrX0_PR7254V0HrhJct7oomPKdxSOSU43w@mail.gmail.com> <2872BF43-20AA-4179-9269-9C4FE6F5986B@strayalpha.com> <CALx6S35VidDr1uTGCHeb3Dcc0qF3O8Lz0vvV-XKPfbY057n6XA@mail.gmail.com> <cd34a1e8da6ff4bbf5b20875827d2a09@strayalpha.com> <CALx6S348jLsnHG3gp-mh9d4KJ1bROT3OcVz=XjwVgpv1aSsi_w@mail.gmail.com> <c271e9501b381c9be6ac1f3a0095a1d9@strayalpha.com> <CALx6S35DRCEjS5qaVkj2_FJzNumrkSfCZmoSJLueqqZs+pm9gw@mail.gmail.com> <240E40E2-81F9-4FAB-A271-825BD7AC6073@strayalpha.com> <96 EB5285-E0F6-43BB-A6CE-B087A4F8DF62@employees.org> <CALx6S36Ef3t7Axmx9hg994DHpVM=NdW-7ygf89E==gL4XKrkQg@mail.gmail.com> <5E21B3C1-0420-404C-9824-9B7E5A850BC5@employees.org> <CALx6S34qmKngi3hK_PVrJA1DMa5kfaLww3jfqRKN=up5v0Y0Ww@mail.gmail.com> <8D23C8B1-C2DA-4A8B-A2BE-8CCF6233B3A5@strayalpha.com> <D1D5EDCE-7C43-4CD8-947C-AA43CDB18892@employees.org> <1B04E207-08FA-400F-BBED-67379FEFD64E@strayalpha.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/YJfKp3n-F2r8BaQ_9kwY-EhOeeQ>
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.27
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, 02 Aug 2018 15:38:51 -0000

Joe,

> I am not ignoring them; I’m claiming that they all have the same inherent deployment and implementation limitations.
> 
> Just because operators/vendors “want” to do otherwise does not make it possible.

There was IETF consensus behind those documents (A+P). 
In the _new_ IPv4 Internet architecture the IPv4 header looks like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2  3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |.    0x45      |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |      6|17     |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Source Port           |     Destination Port          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If the the ascii art comes through.

In contrast to NAT the address and port fields are not rewritten. Only used for forwarding.
The source port and destination port fields are shared between L3 and L4. With an out-of-band provisioning protocol informing the end system which ports are available for applications.

Ole