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 > >
- [Int-area] I-D Action: draft-ietf-intarea-gue-04.… internet-drafts
- [Int-area] Is the UDP destination port number res… Xuxiaohu
- Re: [Int-area] Is the UDP destination port number… Tom Herbert
- Re: [Int-area] Is the UDP destination port number… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-gue… Joe Touch
- [Int-area] 答复: Is the UDP destination port number… Xuxiaohu
- Re: [Int-area] 答复: Is the UDP destination port nu… Joe Touch
- [Int-area] 答复: 答复: Is the UDP destination port nu… Xuxiaohu
- Re: [Int-area] 答复: 答复: Is the UDP destination por… Joe Touch
- [Int-area] 答复: 答复: 答复: Is the UDP destination por… Xuxiaohu
- Re: [Int-area] 答复: Is the UDP destination port nu… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: Is the UDP destination… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: Is the UDP destination… Joe Touch
- Re: [Int-area] 答复: 答复: 答复: Is the UDP destination… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: Is the UDP destination… Joe Touch
- [Int-area] 答复: 答复: 答复: 答复: Is the UDP destination… Xuxiaohu
- [Int-area] 答复: 答复: Is the UDP destination port nu… Xuxiaohu
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Joe Touch
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Joe Touch
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Joe Touch
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Joe Touch
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Templin, Fred L
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Joe Touch
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Templin, Fred L
- [Int-area] 答复: 答复: 答复: 答复: 答复: Is the UDP destina… Xuxiaohu
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: 答复: 答复: Is the UDP des… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Joe Touch