<?xml version="1.0" encoding="utf-8"?>
<!-- 
     draft-rfcxml-general-template-annotated-00
  
     This template includes examples of most of the features of RFCXML with comments explaining 
     how to customise them, and examples of how to achieve specific formatting.
     
     Documentation is at https://authors.ietf.org/en/templates-and-schemas
-->
<?xml-model href="rfc7991bis.rnc"?>  <!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including
most browsers -->
<!DOCTYPE rfc [
  <!ENTITY nbsp "&#160;">
  <!ENTITY zwsp "&#8203;">
  <!ENTITY nbhy "&#8209;">
  <!ENTITY wj "&#8288;">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
     Use of an external entity file is not recommended. -->

<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="std"
  docName="draft-daiya-tsvwg-udp-options-protocol-number-00"
  ipr="trust200902"
  obsoletes=""
  updates=""
  submissionType="IETF"
  xml:lang="en"
  version="3"
  consensus="true">
  <!-- 
    * docName should be the name of your draft
    * category should be one of std, bcp, info, exp, historic
    * ipr should be one of trust200902, noModificationTrust200902, noDerivativesTrust200902,
  pre5378Trust200902
    * updates can be an RFC number as NNNN
    * obsoletes can be an RFC number as NNNN 
-->

  <front>
    <title abbrev="Proto Num Opt in UDP Options">Protocol Number Option in UDP Options</title> <!--
    https://authors.ietf.org/en/rfcxml-vocabulary#title-4 -->
    <!--  The abbreviated title is required if the full title is longer than 39 characters -->

    <seriesInfo name="Internet-Draft" value="draft-daiya-tsvwg-udp-options-protocol-number-00" /> <!--
    https://authors.ietf.org/en/rfcxml-vocabulary#seriesinfo -->
    <!-- Set value to the name of the draft  -->

    <author fullname="Daiya Yuyama" surname="Daiya. Y"> <!--
      https://authors.ietf.org/en/rfcxml-vocabulary#author -->
      <!-- initials should not include an initial for the surname -->
      <!-- role="editor" is optional -->
      <!-- Can have more than one author -->

      <!-- all of the following elements are optional -->
      <organization>Keio University / WIDE Project</organization> <!--
      https://authors.ietf.org/en/rfcxml-vocabulary#organization -->
      <address> <!-- https://authors.ietf.org/en/rfcxml-vocabulary#address -->
        <postal>
          <!-- Reorder these if your country does things differently -->
          <extaddr>Endo 5322</extaddr>
          <region>Fujisawa, Kanagawa</region>
          <code>252-0882</code>
          <country>JP</country>
          <!-- Can use two letter country code -->
        </postal>
        <email>daiya@sfc.wide.ad.jp</email>
        <!-- Can have more than one <email> element -->
      </address>
    </author>

    <author fullname="Hirochika Asai" surname="H. Asai"> <!--
      https://authors.ietf.org/en/rfcxml-vocabulary#author -->
      <!-- initials should not include an initial for the surname -->
      <!-- role="editor" is optional -->
      <!-- Can have more than one author -->

      <!-- all of the following elements are optional -->
      <organization>Preferred Networks / WIDE Project</organization> <!--
      https://authors.ietf.org/en/rfcxml-vocabulary#organization -->
      <address> <!-- https://authors.ietf.org/en/rfcxml-vocabulary#address -->
        <postal>
          <!-- Reorder these if your country does things differently -->
          <extaddr>1-6-1 Otemachi</extaddr>
          <region>Chiyoda, Tokyo</region>
          <code>100-0004</code>
          <country>JP</country>
          <!-- Can use two letter country code -->
        </postal>
        <email>panda@wide.ad.jp</email>
        <!-- Can have more than one <email> element -->
      </address>
    </author>

    <date year="2023" month="7" day="10" /> <!-- https://authors.ietf.org/en/rfcxml-vocabulary#date -->
    <!-- On draft subbmission:
         * If only the current year is specified, the current day and month will be used.
         * If the month and year are both specified and are the current ones, the current day will
           be used
         * If the year is not the current one, it is necessary to specify at least a month and day="1" will
    be used.
    -->

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <!-- "Internet Engineering Task Force" is fine for individual submissions.  If this element is 
          not present, the default is "Network Working Group", which is used by the RFC Editor as 
          a nod to the history of the RFC Series. -->

    <keyword>UDP UDP-Options</keyword>
    <!-- Multiple keywords are allowed.  Keywords are incorporated into HTML output files for 
         use by search engines. -->

    <abstract>
      <t>This document defines the protocol number option in UDP options.
        The protocol number option specifies the protocol immediately following the UDP header.</t>
    </abstract>

  </front>

  <middle>

    <section>
      <!-- The default attributes for <section> are numbered="true" and toc="default" -->
      <name>Introduction</name>
      <t>The User Datagram Protocol <xref target="RFC0768" /> provides only a port number and a
        checksum as a minimum functional transport protocol. Because of its simplicity and
        interoperability in the Internet, new transport protocols such as QUIC <xref
          target="RFC9000" /> and SCTP <xref target="RFC6951" /> are implemented over UDP. However,
        UDP has no field in the header that identifies the encapsulated protocol. Typically, the
        IANA port number <xref target="IANA_service_names_port_numbers" /> is used for that purpose,
        but the port number corresponds to the service of the communication. We argue that it is a
        clear misuse of the port number to indicate the protocol on UDP. Currently, it is not
        possible to provide the UDP layer with information that maps UDP to the transport protocols
        implemented on top of UDP.</t>
      <t>Transport Options for UDP <xref target="I-D.ietf-tsvwg-udp-options" /> is a proposal for
        extending UDP to have an options area, using the difference between the total length field
        in the IP header and the length field in the UDP field. It allows options to be added in
        TLV(Type-Length-Value) format.</t>
      <t>This document describes the protocol number option, which allows information
        about the protocol following the UDP header to be provided in the UDP options area.</t>
    </section>

    <section>
      <name>Conventions used in this document</name>

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
        "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
        interpreted as described in BCP 14 <xref target="RFC2119" />
        <xref target="RFC8174" /> when,
        and only when, they appear in all capitals, as shown here.</t>

    </section>

    <section>
      <name>UDP-based Protocol Extensibility</name>
      <section>
        <name>Spread of applications using UDP-based transport protocols</name>

        <t>Frequently, new transport protocols are implemented based on UDP, such as QUIC, and are
          used as transport protocols for existing applications.</t>
        <t>The following are examples of applications that operate using UDP-based transport
          protocols.</t>
        <t>HTTP</t>
        <ul spacing="normal">
          <li>HTTP/3 <xref target="RFC9114" /> - HTTP over QUIC, uses UDP port 443.</li>
        </ul>

        <t>DNS</t>
        <ul spacing="normal">
          <li>DNS over Datagram Transport Layer Security <xref target="RFC8094" /> - uses UDP port
            853.</li>
          <li>DNS over Dedicated QUIC Connections <xref target="RFC9250" /> - uses UDP port 853, same
            as DNS over DTLS.</li>
        </ul>
      </section>
      <section>
        <name>Concerns about limited UDP-based transport extensibility</name>

        <t>The UDP header does not have any information to identify the encapsulated protocol.
          Without this information, problems may arise when there are applications that can
          communicate with multiple transport protocols using the same port number. In the case of
          client-server communication, the server cannot instantly determine which transport
          protocol was used to send the packet sent by the client.</t>
        <t>For instance, when a new transport protocol other than QUIC is developed and used that is
          based on UDP and works as a transport for HTTP, the server will not be able to instantly
          identify whether QUIC is used as the transport protocol or the new one is used.</t>
        <t>Therefore, if the next protocol after the UDP header is a transport protocol, it should
          be possible to have a field in the UDP layer information that identifies the protocol that
          follows the UDP header.</t>

      </section>

    </section>

    <section>
      <name>Protocol Number in UDP Options</name>
      <t>The protocol number is a number to identify the protocol immediately following the UDP
        header.
        In many cases, the port number of the transport layer is available for this number, but a
        new
        protocol number is needed for protocols that do not have a port number, such as QUIC.</t>
    </section>

    <section>
      <name>Option Format</name>
      <t>The UDP option is provided in the form of a TLV. The protocol number is represented by 16
        bits. It is shown in Figure 1.</t>

      <figure>
        <name>Option format</name>
        <artset>  <!-- https://authors.ietf.org/en/rfcxml-vocabulary#artset -->
          <!-- This <artset> includes two <artwork> elements, each of a different type.  Both are not 
             always needed.  See https://authors.ietf.org/e/en/adding-diagrams -->
          <artwork type="ascii-art" name="proto-num-option-format.txt">
<![CDATA[
              +---------+---------+---------+---------+
              | Kind=10 |  Len=4  |  Next Header Num  |
              +---------+---------+---------+---------+
                1 byte    1 byte         2 bytes       
]]>
          </artwork>
        </artset>
      </figure>

    </section>

    <section>
      <name>Recommendation</name>
      <t>TBD</t>
    </section>

    <section anchor="IANA">
      <!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a
      guide.-->
      <name>IANA Considerations</name>
      <t>On publication, request IANA to create a new registry for protocol numbers.
        The details of the number will be described in a later revision.
        Also, request IANA to assign one number from the Safe Options range of the UDP Option Kind
        Number as Protocol Number (PROTONUM).</t>
    </section>

    <section anchor="Security">
      <!-- All drafts are required to have a security considerations section. See RFC 3552 for a
      guide. -->
      <name>Security Considerations</name>
      <t>This document should not affect the security of the Internet.</t>
    </section>

    <!-- NOTE: The Acknowledgements and Contributors sections are at the end of this template -->
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <!-- About RFC -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" />

        <!-- About RFC -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" />

        <!-- UDP -->
        <xi:include
          href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml" />

        <!-- UDP Options -->
        <xi:include
          href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-udp-options.xml" />

      </references>

      <references>
        <name>Informative References</name>

        <!-- IANA -->
        <xi:include
          href="https://bib.ietf.org/public/rfc/bibxml8/reference.IANA.service-names-port-numbers.xml" />

        <!-- QUIC -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml" />

        <!-- SCTP -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6951.xml" />

        <!-- HTTP/3 -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9114.xml" />

        <!-- DNS over DTLS -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml" />

        <!-- DNS over QUIC -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml" />

      </references>
    </references>

    <!--<section>
      <name>Appendix 1</name>
      <t>This becomes an Appendix</t>
    </section>-->

    <section anchor="Acknowledgements" numbered="false">
      <!-- an Acknowledgements section is optional -->
      <name>Acknowledgements</name>
      <t>TBD</t>
    </section>

  </back>
</rfc>