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

Joe Touch <touch@isi.edu> Thu, 25 May 2017 18:34 UTC

Return-Path: <touch@isi.edu>
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 47B6C127B73 for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 11:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 5QKenrDJir2s for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 11:34:52 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 AB297126BFD for <int-area@ietf.org>; Thu, 25 May 2017 11:34:52 -0700 (PDT)
Received: from [128.9.184.77] ([128.9.184.77]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v4PIXndE006223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 11:33:50 -0700 (PDT)
To: Tom Herbert <tom@herbertland.com>
Cc: Xuxiaohu <xuxiaohu@huawei.com>, "int-area@ietf.org" <int-area@ietf.org>
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> <CALx6S365N44zV=-N3BgA9ATibfqW5G78_4cDD4EnL1muDoA04Q@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu>
Date: Thu, 25 May 2017 11:33:49 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CALx6S365N44zV=-N3BgA9ATibfqW5G78_4cDD4EnL1muDoA04Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/7gjnkHhK00cL_jX16NJ8Bxy-F4A>
Subject: Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
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:34:54 -0000


On 5/25/2017 11:27 AM, Tom Herbert wrote:
> 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.

Yes, but there's very little benefit in looking at 2 bits vs 4. That
would matter only for serial processing and saves far too little to be
worthwhile IMO. It also complicates the way the protocol is described (I
personally find it confusing; it's a lot more obvious to just say that
you use IPv0 for control, IPv1 for encapsulation, and other IP versions
are included without overriding headers).

>
>> 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.
You can't put bare Ethernet inside GUE. You need to use EtherIP -
exactly because it has a 16-bit field, of which only the first 4 bits
are (already) defined.

My point is that EtherIP burns 16 bits vs bare Ethernet, but those 16
bits allow it to be mapped to one of the IP versions (you picked IPv5).
The same trick works for UDP and TCP - just pick a different 16 bit
pattern for each one.

The catch is that EtherIP and these corresponding tricks for UDP and TCP
end up burning 16 bits more than the bare packet would, but that's still
less than the GUE encapsulation header burns.

Joe
>
>> 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
>>
>>