Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt

Tom Herbert <tom@herbertland.com> Thu, 25 May 2017 18:27 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 CC47C124D85 for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 11:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 S8k4W19Vdgwe for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 11:27:04 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 EAFEF126C3D for <int-area@ietf.org>; Thu, 25 May 2017 11:27:03 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id d127so108433481wmf.0 for <int-area@ietf.org>; Thu, 25 May 2017 11:27:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M1jTFDVAwxqQlU7A0KUDdAznnJqM4O9ieYebwXjnwl4=; b=M98xGzTib6YQE2B4SzpAyuPCCjSCSmjy6KzJ4x+8q9HWBal3fV5VkDct1kjt5N5QVx 9D7SRP0OLnjuXS/KtXAz/9l5ML4/J6P0qo5ywbDEKKCNyswttQ5BZ4gPUSsyBQ4UFx4S px9pj2JllWiNqm+fX1e7mRO86q6FCrbJzcdJPWIWbvI383MlUlMRdMP5HDiDqbPrMYbb Tk0HIDjKw0E/zGxW5cGeniT6bidKG44NBS43QG8iKQlySUDI4woZlL0p1dycLNUmieJv bzkd8M5ILGBgQ7e9T8CdSC/4GvBaszjN6uKo/0V3IqvGKJTQ/hJDbc9dgxTqTg1vBbff urRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M1jTFDVAwxqQlU7A0KUDdAznnJqM4O9ieYebwXjnwl4=; b=UAmKWfdDM69+ULjgkBnsf89g44N9rxt1nTXj51cTFAX0MSTKZRkPpGESwOXl/6H/up xghyi0XRpNVJUZixbs1JXxGYi8ihaj+cRHLSVWH6M6AYLrKzsb/IG6KoGtuk+u4orgct KbHQgjLPItnJGerYiKcfWH4SsVU9tjhkTifaaoMvID+SG6PMeZdEPdP6haJrJwYpvfDz LKkivpAAmErX6gevtrYU0K/DIYcTk2alm0lAqU6P3pJb7pq4syMsByztF4HK02tNE/PU Cyo1Utp+bR8ovASxY6sGhdsdw4nlTIRh3zPLVDwtSpPmHQPpfj5HSUJPAOjLJa/pFbhJ 78Ug==
X-Gm-Message-State: AODbwcAv+dsJMF6XAHcnJfcARyBoBiEkPs12McHddzcm1ZBi4Zmjbwtj CJjVFoumjJEuI/0UCCjATSciMVPbfJIQ
X-Received: by 10.28.56.198 with SMTP id f189mr10101139wma.111.1495736822325; Thu, 25 May 2017 11:27:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.132.195 with HTTP; Thu, 25 May 2017 11:27:01 -0700 (PDT)
In-Reply-To: <d1c22f64-1cab-2946-32a6-4339a197402e@isi.edu>
References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <CALx6S37nrJNGLdRHWx9DYNQyS54YdwLCXcG9Mp3zi4L_wrr6=g@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <a3915b87-f104-51d8-11e3-d9f8196462b5@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <CALx6S350VcJCm4g70jycbXD3FxaGg9eF-dn61_SdVF8xmmkojg@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> <CALx6S34dQX8gGCLvR4OG70FfO7MY8CbOxB_CA-crcTmFE_zX3g@mail.gmail.com> <d1c22f64-1cab-2946-32a6-4339a197402e@isi.edu>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 25 May 2017 11:27:01 -0700
Message-ID: <CALx6S365N44zV=-N3BgA9ATibfqW5G78_4cDD4EnL1muDoA04Q@mail.gmail.com>
To: Joe Touch <touch@isi.edu>
Cc: Xuxiaohu <xuxiaohu@huawei.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/InSFeVxwTruSLgEOU4M_0-isY2s>
Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIOetlA==?= =?utf-8?q?=E5=A4=8D=3A_Is_the_UDP_destination_port_number_resource_runnin?= =?utf-8?q?g_out=3F//_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?=
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
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, 25 May 2017 18:27:06 -0000

On Thu, May 25, 2017 at 10:44 AM, Joe Touch <touch@isi.edu> wrote:
> Hi, Tom,
>
> On 5/25/2017 9:00 AM, Tom Herbert wrote:
>> IPv4 and IPv6 can be directly encapsulated since they have a protocol
>> number (can be encapsulated by version 0).
>>
>> As I mentioned previously, Ethernet could be directly encapsulated via
>> EtherIP that has a 4 bit version number at the beginning of its
>> header. The way this would work is to set a version 1 pattern to
>> indicate EtherIP. For example, we could specify that 0101  would be
>> EtherIP. When GUE receives such a packet it will notice it's version
>> one and then see that it is EtherIP (differentiated from IPv4 0100 and
>> IPv6 0110 values). The first four bits are then overwritten by 0011 to
>> make it a valid EtherIP header and then the packet is resubmitted to
>> the stack as EtherIP.
> If you use the first 4 bits as the type identifier (which I think you
> should, as noted below), then you could easily support a bunch of
> encapsulations without needing the 4-byte overhead.
>
> E.g.:
>     0000 = GUE control (your "Version 0")
>     0100 = IPv4
>     0101 = IPv6
>
> That leaves 13 other codes you can use for other protocols (including
> MPLS, Ethernet, etc.), as long as you burn at least those 4 bits.
>

Right, although even with 00 for version zero there's still enough for
ten other codes which is a lot.

> EtherIP effectively burns 2 bytes rather than 4 bits, but has the same
> net effect.
>
>> Transport protocols (TCP, UDP, SCTP) might also be nice to support
>> with direct encapsulation in version 1, but unfortunately since they
>> start with a variable port number there's no way to do that.
> That works the same way as EtherIP - burn at least 4 bits indicating the
> transport.

EtherIP begins with a fixed version number, for the transport
protocols we would be overwriting the source port with no way to
recover the bits.

>
> Joe
>
> ------
> From my previous post:
>
> When we look at the first 2 bits of a GUE packet, we see:
>     00 = GUE version 0
>     01 = IPv4 or IPv6
>     10 = undefined
>     11 = undefined
>
> That's nearly the same as looking at the first 4 bits as simply the IP
> version number, and defining some of the unused IP versions as control:
>     0000 (IPv0) = GUE control
>     0001 (IPv1) = GUE control
>     0010 (IPv2) = GUE encapsulation using the GUE header
>     0011 (IPv3) = GUE encapsulation using the GUE header
>     0100 (IPv4) = direct encapsulation of IPv4, with no intervening GUE
> header
>     0101 (IPv5) = direct encapsulation of IPv5 (ST), with no interveni
> GUE header
>     0110 (IPv6) = direct encapsulation of IPv6, with no intervening GUE
> header
>     0111 (IPv7) = direct encapsulation of IPv7 (TP/IX), with no
> intervening GUE header
>     1000 (IPv8) = direct encapsulation of IPv8 (PIP), with no
> intervening GUE header
>     1001 (IPv9) = direct encapsulation of IPv9 (TUBA), with no
> intervening GUE header
>     1010 (IPv10) = direct encapsulation of IPv10, when assigned
>     1010 (IPv11) = direct encapsulation of IPv11, when assigned
>     1010 (IPv12) = direct encapsulation of IPv12, when assigned
>     1010 (IPv13) = direct encapsulation of IPv13, when assigned
>     1010 (IPv14) = direct encapsulation of IPv14, when assigned
>     1010 (IPv15) = direct encapsulation of IPv15, when assigned
>
> I.e., all you're basically doing is defining the first four version
> numbers of IP as your control plane. Unless we come back and assign them
> in the future, any mechanism that encapsulates IP packets (which should,
> IMO, be able to handle ALL IP versions, by definition) should be able to
> include GUE-style signaling.
>
Right, this scheme could work to generally encapsulate different IP
versions. There is a caveat though: AFAIK there is no IP protocol
number to encapsulate any IP protocols other then IPv4 (IPIP 94) and
IPv6 (IPv6 encapsulates 41). GUE encapsulates IP protocols which means
they need a protocol number. Version 1 is header compression for
version 0 so the there must be a way to encapsulate the protocol using
version 0. What would resolve that is a new IP protocol number for
encapsulating a packet of any IP version and use the IP version itself
to differentiate.

Tom

> IMO, it's simpler to explain this all using this fixed-field
> demultiplexer - in which case, you could even use just the IPv0 pattern
> for control and the IPv1 pattern for encapsulation using the GUE header,
> leaving the IPv2 and IPv3 equivalent patterns for future expansion.
>
> Joe
>
>