Re: [tsvwg] New Version Notification for draft-daiya-tsvwg-udp-options-protocol-number-00.txt

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 12 July 2023 15:42 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40433C151B0C for <tsvwg@ietfa.amsl.com>; Wed, 12 Jul 2023 08:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTic0BZGeP0e for <tsvwg@ietfa.amsl.com>; Wed, 12 Jul 2023 08:42:44 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 12D5EC1519AC for <tsvwg@ietf.org>; Wed, 12 Jul 2023 08:42:43 -0700 (PDT)
Received: from [IPV6:2001:630:42:110:c955:b580:8f5f:2235] (unknown [IPv6:2001:630:42:110:c955:b580:8f5f:2235]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id E4D8E1B00171; Wed, 12 Jul 2023 16:42:38 +0100 (BST)
Message-ID: <2b1306db-6b12-dcce-0018-eb1a10f22056@erg.abdn.ac.uk>
Date: Wed, 12 Jul 2023 16:42:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.13.0
Content-Language: en-US
To: Daiya Yuyama <daiya=40sfc.wide.ad.jp@dmarc.ietf.org>, tsvwg@ietf.org, Hirochika Asai <panda@wide.ad.jp>
References: <168903260541.49852.5537122429979483346@ietfa.amsl.com> <591bfafb-ff0a-427d-5e14-0de776437fd6@sfc.wide.ad.jp>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
In-Reply-To: <591bfafb-ff0a-427d-5e14-0de776437fd6@sfc.wide.ad.jp>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/jP82qlF55oeU5f8ZQQJcnmqak6k>
Subject: Re: [tsvwg] New Version Notification for draft-daiya-tsvwg-udp-options-protocol-number-00.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jul 2023 15:42:48 -0000

On 11/07/2023 18:47, Daiya Yuyama wrote:
> Dear all
>
> We have submitted a draft that defines the protocol number option in 
> UDP options. The protocol number option specifies the protocol 
> immediately following the UDP header.
>
> https://datatracker.ietf.org/doc/draft-daiya-tsvwg-udp-options-protocol-number/ 
>
>
> Currently, the only information about the packet encapsulated in UDP 
> is the port number corresponding to the service. In addition, 
> UDP-based protocols such as QUIC are increasingly used as transport 
> for applications.
> When using such protocols, it is not possible to provide the UDP layer 
> with information about the transport layer protocol that follows the 
> UDP header. The protocol number option provides this information.
>
> We believe this option would be beneficial for extending the transport 
> protocol with UDP.
>
> If you are interested in it or have any comments, I really appreciate 
> your feedback or comments.
>
> Thank you.
>
> Daiya

Thanks Daiya for this submission. This draft sounds like it could be 
helpful in some cases.

I see from the spec uses unsigned 16 bit values to identify the next 
header, and I wondered what sort of values you thought would be needed?

I see many potential options:

* Would the values simply follow the port registry assignments, which is 
16 bits.

* IANA also has defined an ASCII service name (in the port registry), 
which is not 16 bits.

* In the past, we defined a 4 byte Service Codes for DCCP, to describe 
the application being carried by DCCP, and there seems some parallels 
with the usage:

https://www.iana.org/assignments/service-codes/service-codes.xhtml

* IPv6 defines a NH value - for transport values this uses:

https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

* And, as the draft currently suggests, the IETF could also decide to 
define new IANA registry.

Which is best and why?

Gorry

>
> On 2023/07/11 8:43, internet-drafts@ietf.org wrote:
>>
>> A new version of I-D, 
>> draft-daiya-tsvwg-udp-options-protocol-number-00.txt
>> has been successfully submitted by Daiya Yuyama and posted to the
>> IETF repository.
>>
>> Name:        draft-daiya-tsvwg-udp-options-protocol-number
>> Revision:    00
>> Title:        Protocol Number Option in UDP Options
>> Document date:    2023-07-10
>> Group:        Individual Submission
>> Pages:        6
>> URL: 
>> https://www.ietf.org/archive/id/draft-daiya-tsvwg-udp-options-protocol-number-00.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-daiya-tsvwg-udp-options-protocol-number/
>> Html: 
>> https://www.ietf.org/archive/id/draft-daiya-tsvwg-udp-options-protocol-number-00.html
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-daiya-tsvwg-udp-options-protocol-number
>>
>>
>> Abstract:
>>     This document defines the protocol number option in UDP options.  
>> The
>>     protocol number option specifies the protocol immediately following
>>     the UDP header.
>>
>>
>>
>> The IETF Secretariat
>>
>>