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

Joe Touch <> Sat, 20 May 2017 23:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7DC9129601 for <>; Sat, 20 May 2017 16:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eV67FHvG9O9H for <>; Sat, 20 May 2017 16:18:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60DC5128656 for <>; Sat, 20 May 2017 16:18:02 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v4KNGorC013485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 20 May 2017 16:17:13 -0700 (PDT)
To: Xuxiaohu <>, Tom Herbert <>
Cc: "" <>
References: <> <> <> <> <> <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Sat, 20 May 2017 16:16:45 -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: <>
Content-Type: multipart/alternative; boundary="------------3957FB09AE2DB674DF555076"
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06ICDnrZTlpI06IElzIHRo?= =?utf-8?q?e_UDP_destination_port_number_resource_running_out=3F//_re=3A_I?= =?utf-8?q?-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?=
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 20 May 2017 23:18:04 -0000

On 5/19/2017 11:09 PM, Xuxiaohu wrote:
>> GUE is supposed to be both signalling and content (data), where the data are IP
>> packets.
> Since IANA strives to assign one port for a service, IP packet within the UDP tunnel should be assigned a dedicated port. In other words, GUE and IP-in-UDP are distinguished by the different port numbers. 
GUE is one service that includes both encapsulation of IP packets and
Frankly, it seems like it would work anywhere IP works - where IPv0 is
defined as the signalling channel (which is sufficient because IPv0
isn't defined).

In that case, the first field after v0 needs to be a signal channel
version number, to allow for future updates.

>> Take away the IP part and GUE isn't an E anymore.
>>>> Services are expected to have version fields and subtype
>>>> demultiplexing indicators, to so that all message variants of current
>>>> and future versions can use a single port number.
>>> Sure, the version field within the IPvx packet could be used for demultiplexing
>> purpose.
>> That demultiplexes within IPvx. There still needs to be a way to demultiplex
>> non-IPvx packets (control) from IPvx.
> Since GUE and IP-in-UDP have different UDP port numbers, 
They don't and they shouldn't. That would complicate forwarding - a
single service needs to use a single port. Using separate ports
complicates configurations - this is a case where you want "fate
sharing" (either both IP encapsulation and the signal channel work or
neither do).

> I don't know why there is still a need to demultiplex GUE and IP-in-UDP.
The point of GUE is an IP encapsulation channel with in-band signalling.
That is a single service, IMO.

Note - AFAICT, GUE could work anywhere an IP packet works. IP packets
always start with a version number, and v0 isn't really defined.
Defining v0 as the signal channel is the same thing as how GUE is
currently specified.