Re: [Int-area] I-D Action: draft-herbert-ipv4-udpencap-eh-00.txt

Tom Herbert <tom@herbertland.com> Tue, 05 March 2019 16:42 UTC

Return-Path: <tom@herbertland.com>
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 912FE1312A1 for <int-area@ietfa.amsl.com>; Tue, 5 Mar 2019 08:42:20 -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=herbertland-com.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 HuvfbgZnHUof for <int-area@ietfa.amsl.com>; Tue, 5 Mar 2019 08:42:18 -0800 (PST)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 1371D131294 for <int-area@ietf.org>; Tue, 5 Mar 2019 08:42:17 -0800 (PST)
Received: by mail-qt1-x82d.google.com with SMTP id p48so9617464qtk.2 for <int-area@ietf.org>; Tue, 05 Mar 2019 08:42:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lwRpfVENI0hnUPKtqFjB3CqtYn2Mlr0zU7nmH7lrO8k=; b=kAI6nzFIjo9LzzkDxe/P92vqOQoPi5dYwH3YTOCaL8g+sYD3W7OkEUN/amJ1PopjVH TUhyneaS2KaK7B4zz2WiTUEz2fJQkIFdAY6yp0WdIZDXYXKecXvlHOR5uHPz+xi0blB7 mFMCa7I5nPyirjU3rOyjXXNSfq7XesrB4R0KrXcNL10KPtQUuWdLt838VKov0FwvHa5U 51HGI7YUW2RyFZJfOe+LVrpoQKGk+kZYFXY38xsqD1Dtg76pTxQ3BOjy9QjYI3BJwkgI 8krleCkBYLbrKunCIYjvRcJBbpojzK+0dnAEzGAIwKfW7Yk2ES4tmI7UxFwJZH++ARnB xypw==
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=lwRpfVENI0hnUPKtqFjB3CqtYn2Mlr0zU7nmH7lrO8k=; b=NhiBcS2qSRIKSHUYXMpifYJ7/BBjHm83w4crOHag1tG8vG7TDvfXT6BHExVrsYtPlI lHWgrLcOoBclrjjxV1r6PZkHAEQu3XKtQ66wkABkw3+fMcFiuiYpCa/Psyvf/WfgGJMv 8rr+w1hxESFk0IeMWIhyusF7ubhsauCbqlya0STVtpT+QKH1ccKXeB4NrWUcn54B4tn8 Tzwz5AlfD0uIoM1i2yR9LnzhzeVjIr32zjh5uiDflIRg/PS/GUd4AaJAe8Jjcs27x++K 9MV5TFFau07j7RX0tWj7fD/FkeUz3iNSfE18jJOoArXKEnNB6rvOlJtSe0qAHDlDsYHx T73Q==
X-Gm-Message-State: APjAAAUyEzS9klzTNZ8sUZRt9sQGWNS/rk2lfRG8QkpXSTPfXk4qNetP CJU5cRlB/BgGQR78ygLykCGe6wiWJB1+b0M5PLbVHg==
X-Google-Smtp-Source: APXvYqwT8XFTK/82IoyYUUJgUZ4/S8KTlSngzsWIWXYa0/4DVLwYKUaOf4g8tTJVy1NzvFxSpGw0u6Au3xK/tWHuvro=
X-Received: by 2002:ac8:1695:: with SMTP id r21mr2171210qtj.226.1551804136693; Tue, 05 Mar 2019 08:42:16 -0800 (PST)
MIME-Version: 1.0
References: <155129875566.13940.2872169346710477964@ietfa.amsl.com> <946a3fea-79e7-893c-3b2c-f54fa634339b@gmail.com>
In-Reply-To: <946a3fea-79e7-893c-3b2c-f54fa634339b@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 05 Mar 2019 08:42:05 -0800
Message-ID: <CALx6S36_2z6X1fJ1=0ZzVw_MqxbJETx-w6aMGbzUcJiTJfpeSQ@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: int-area <int-area@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/VleteaCI_veh6rXiCXnWwiXKb5k>
Subject: Re: [Int-area] I-D Action: 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: Tue, 05 Mar 2019 16:42:21 -0000

Hi Brian,

On Mon, Mar 4, 2019 at 5:37 PM Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
>
> Hi,
>
Hi Brian,

Thanks for the comments!

> This is an interesting draft, but I must say I have serious doubts about
> the IETF working on any significant update to IPv4 at the IP header level,
> or of any such updates ever making it into the operational network.
>

I understand the concern. It's probably true that extension headers in
IPv4 wouldn't be very usable in today's Internet. Undoubtedly, many
middleboxes would block them. But that's not because middleboxes are
concerned about a threat of extension headers in IPv4, it's more
because some middleboxes drop packets with any protocols they don't
understand (pretty much leaving only TCP and UDP as being usable
protocols on the Internet). There are some potential mitigations to be
pointed out:

- IPv4 already supports at least two extension headers, namely ESP and
AH. They might not be called extension headers, but they have the same
format and function as IPv6 cognates.
- There's no concept of HBH options in IPv4 as needing to be processed
by every node in the path, so the relaxed processing requirement of
RFC8200 can be set from the start without legacy issues.
- This doesn't actually change IP header, it is just enabling new
values in the protocol field. In a host implementation this is very
straightforward and in some ways it's a simplification to to be more
like IPv6.
- UDP encapsulation of extension headers could serve to make extension
headers transparent to middleboxes.
- It is conceivable to only allow extension headers in UDP
encapsulation thereby eliminating the problem of making a core update
to IPv4. IPv4 extension headers would be defined as part of an
encapsulation protocol.
- IPv4 extension headers could be another use case for limited domains.

> On the other hand, I think the idea of a UDP encapsulation of extension
> headers is very interesting. I'm not sure I understand all the implications
> yet, and I'm not sure why the format can't be defined simply by a normative
> reference to RFC8200. The idea of having a duplicate format definition
> is a bit scary.

Some implications are described in the document. When encapsulating
transport packets within UDP the IP header for the encapsulated
transport header needs to be deterministic, how to deal with NAT and
encapsulated transport checksum needs a solution. Intermediate nodes
parsing HBH embedded options is tricky since that requires them to
inspect UDP payloads and potential modify the payload. For that, a
magic number is used to minimize the possibility of misinterpretation
of UDP payload type. If you think of other implications please bring
them up.

I'm not sure what the comment on duplicate format definition refers
to. Perhaps this is about the the description of extension headers for
IPv4 in the draft?

Thanks,
Tom




>
> Regards
>    Brian Carpenter
>
> On 28-Feb-19 09:19, internet-drafts@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> >
> >         Title           : IPv4 Extension Headers and UDP Encapsulated Extension Headers
> >         Author          : Tom Herbert
> >       Filename        : draft-herbert-ipv4-udpencap-eh-00.txt
> >       Pages           : 27
> >       Date            : 2019-02-27
> >
> > Abstract:
> >    This specification defines extension headers for IPv4 and a method to
> >    encapsulate extension headers in UDP to facilitate transmission over
> >    the Internet. The goal is to provide a uniform and feasible method of
> >    extensibility that is shared between IPv4 and IPv6.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-herbert-ipv4-udpencap-eh/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-herbert-ipv4-udpencap-eh-00
> > https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-udpencap-eh-00
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-Announce@ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >