Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt

Tom Herbert <tom@quantonium.net> Wed, 06 March 2019 17:13 UTC

Return-Path: <tom@quantonium.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 BEC7C1310E0 for <int-area@ietfa.amsl.com>; Wed, 6 Mar 2019 09:13:00 -0800 (PST)
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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com
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 aisJ6qM8kOyS for <int-area@ietfa.amsl.com>; Wed, 6 Mar 2019 09:12:59 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 F06F31310BE for <int-area@ietf.org>; Wed, 6 Mar 2019 09:12:58 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id w17so14278036wrn.12 for <int-area@ietf.org>; Wed, 06 Mar 2019 09:12:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u4AiRNOYteJYqwhF2OvYPgMRSUrXKCa5mrQwd8gZxag=; b=r4tEDwryQUTsBbBwq6KPGC3fRyfZoGwq8OwJBNGRmPUlibPXcS0kTkaZZ5hctlUHb9 1H5wa09f/qw+3kco7dpwITkOc2tJYH1s84vWvxPSjuhNN9cqvzI8MVALNzHM/4EwQ3FV oVN7PtkOe3ahvOCXBTUlSjqKJTK56PCKMAa7+o56rqwoVF9qI6V9l0MO83XOGS9TRfOu aywXdmFQx/yNh5q6CWFK5kvYNgHH7Dp4g6a6Fmj/VxqahtTzLS9LZYSKTSxM7AkIhGyS I/lU4l3K1urzzw2Al/BdKRkY3692aesYMgvIex4M3rSR46TgOo9N3DYm5ol5Bo/w9t8p iaPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u4AiRNOYteJYqwhF2OvYPgMRSUrXKCa5mrQwd8gZxag=; b=k5GAnZfBvTjp9IihiK0C4io3egTu8mXImlqEslDwHc3n+cvx3sxKsogIKOICKOf1Ha BJT85FHy5rs623r7/J/FxJxOzViBrxX8ZNRQeZHQsLTfahht+wfs+I1NSkNGWUV2Crdu fBVj5Vs0C0fYcNSotlFY8hqhn9GmvJa7/cT24SMdRGlWvIV8gLLDTo8AFt6idDdmEtgd qNaNITX/PkYa5KXjHDZjLh7ms1Ml6+2UHwiCHLW70H89dZUsD/mACNcQVMFfgsyVc3Jz axQjzd0ewilfMGio9m+518McUBAKxMe4eV0AjbWovE/fRt14rqLjphp7ZLF+Taf+X6gA h3lQ==
X-Gm-Message-State: APjAAAULnn9ftgyBSHS8G7jvyUDNS5jqNLHQ/DsTWPUv4YtBM4HSfvlr b1cOTFfeKPvTu8oizH2Fv9aESbRIknKWzw+GI1fCFg==
X-Google-Smtp-Source: APXvYqyZF1m/0bZ8s/qekuvRYQLa60JhoyXdDFDbc9GIsx/9tfUVotTV/M2wVKbOOxrMclaWyOYvD5YWC18iEou9NVI=
X-Received: by 2002:adf:8251:: with SMTP id 75mr4009639wrb.112.1551892377204; Wed, 06 Mar 2019 09:12:57 -0800 (PST)
MIME-Version: 1.0
References: <155129875579.13940.18077034152695268824.idtracker@ietfa.amsl.com> <CAPDqMeofwtqye_+55Yc_3rAkQqNLQ9Dw9TohJ7gcYCgUJrs-Jg@mail.gmail.com> <dbcef0c979f24aecb638babded309117@boeing.com> <CAPDqMeryKrE2t47kY1YXcpf80bJ8W3cx9m3UX+vfiYTy_kE6yA@mail.gmail.com> <7e858ddb-5372-b77b-1ebb-e9b0e297b479@strayalpha.com> <CALx6S34sRo1bzYZs3bEE4cWkhZb_vmomYE4F=vrpesNqG8SuXw@mail.gmail.com> <0f185c50-0450-aba7-c2cb-6f047fe08a28@strayalpha.com>
In-Reply-To: <0f185c50-0450-aba7-c2cb-6f047fe08a28@strayalpha.com>
From: Tom Herbert <tom@quantonium.net>
Date: Wed, 06 Mar 2019 09:12:46 -0800
Message-ID: <CAPDqMeqGt7-mdpnnr70Jjg3Zd_fyvva=5qkS1+zAD=XYVF214w@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: Tom Herbert <tom@herbertland.com>, "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, "int-area@ietf.org" <int-area@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/fzqDMWi5B9tac-VohWJal7aU2ew>
Subject: Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt
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: Wed, 06 Mar 2019 17:13:01 -0000

On Wed, Mar 6, 2019 at 9:03 AM Joe Touch <touch@strayalpha.com> wrote:
>
>
> On 3/6/2019 8:22 AM, Tom Herbert wrote:
> > On Tue, Mar 5, 2019 at 10:08 PM Joe Touch <touch@strayalpha.com> wrote:
> >> Isn't the biggest problem with IP fragmentation the inability to NAT
> >> because the transport headers are in the first fragment only (which may
> >> go via another path)?
> >>
> > Joe,
> >
> > The size of the IP identifier is mentioned as one of the problems with
> > IPv4 fragmentation in draft-ietf-intarea-frag-fragile.
>
> That could have been handled by new rules to drop incompletely
> reassembled datagrams based on measured expected reordering, rather than
> max lifetime.
>
> > The fact that
> > intermediate nodes might fragment in IPv4 and not in IPv6 is another
> > discrepancy between the protocols.
>
> Well, strictly the difference is only whether intermediate nodes violate
> IPv4 or IPv6. IPv4 with DF isn't supposed to be on-path fragmented any
> more than IPv6 is; in both cases, nodes that violate the protocols can -
> and will - do whatever they want.
>
> But there's no point in making "laws for the lawless", as I've
> repeatedly noted throughout the IETF.
>
> > The transport layer not in all
> > fragments is a problem for NAT, that might addressed by encapsulating
> > the fragmention in UDP.
>
> That is a problem for NAT and transport-based ECMP.
>
> And yes, we can build an Internet on the Internet - again, as I've noted
> repeatedly throughout the IETF. Or we can use UDP fragmentation - which
> ought to solve all these issues in one shot.
>
> So what's the gain here?

Joe,

Please view the proposal in its entirety. The stated objectives are to
support IPv6 extension headers in IPv4 and to allow encapsulate of
extension headers (both for IPv6 and Ipv4) in UDP to improve
deliverability. Fragmentation header is just one example.

Tom

>
> Joe
>