<?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-next-header-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">Next Header 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-next-header-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>5322 Endo</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="10" day="23" /> <!-- 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 next header option in UDP options.
        The next header 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 about 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. This creates an options area behind the UDP payload to
        allow TLV(Type-Length-Value) format options to be added.</t>
      <t>This document describes the next header option. This option allows information
        about the protocol following the UDP header. This option is provided as one of the
        UDP options.</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>Transport Protocols based on UDP</name>

      <t>Using new IP-based transport protocols on the Internet is difficult bacause of ossified
        middle boxes. Therefore, in order to maintain affinity with the Internet, it is often used
        to encapsulate the transport protocol with UDP. 
        The following are transport protocols used for UDP-based.</t>

      <t>Registered in IP Protocol Numbers</t>
      <ul spacing="normal">
        <li>DCCP <xref target="RFC6773" /> - DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal</li>
        <li>SCTP <xref target="RFC6951" /> - UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication</li>
      </ul>

      <t>Not registered in IP Protocol Numbers</t>

      <ul spacing="normal">
        <li>QUIC <xref target="RFC9000" /> - QUIC: A UDP-Based Multiplexed and Secure Transport</li>
      </ul>

    </section>

    <section>
      <name>UDP-based Protocols Extensibility</name>

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

        <t>Transport protocols implemented based on UDP such as QUIC often 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>Value of Next Header Option</name>
      <t>The next header option is a number to identify the protocol immediately following the UDP
        header.
        This number used be the same as IP Protocol Numbers<xref target="IANA_protocol_numbers" />
        In many cases, the protocol number is available, but a
        new protocol number is needed for protocols that do not have a protocol number, such as QUIC.</t>
    </section>

    <section>
      <name>Option Format</name>
      <t>The UDP option is provided in the form of a TLV. The value of next header option is represented by 8
        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="next-header-option-format.txt">
<![CDATA[
              +---------+---------+---------+---------+
              | Kind=10 |  Len=4  | Nxt Hdr | Padding |
              +---------+---------+---------+---------+
                1 byte    1 byte    1 byte    1 byte  
]]>
          </artwork>
        </artset>
      </figure>

    </section>

    <section>
      <name>Recommendation</name>

      <section>
        <name>Next Header Options is for Transport Ends</name>

        <t>The next header option is intended to be interpreted by transport ends. As with the
          original UDP Options, not intended to be interpreted in-transit.</t>
      </section>

      <section>
        <name>TBD</name>

        <t>TBD</t>

      </section>

    </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 assign one number from the Safe Options range of the UDP Option Kind
        Number as Next Header (NXTHDR).</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 Port Numbers -->
        <xi:include
          href="https://bib.ietf.org/public/rfc/bibxml8/reference.IANA.service-names-port-numbers.xml" />

        <!-- IANA Protocol Numbers -->
        <xi:include
          href="https://bib.ietf.org/public/rfc/bibxml8/reference.IANA.protocol-numbers.xml" />

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

        <!-- DCCP -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6773.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>