<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com 
     This can be converted using the Web service at http://xml.resource.org/ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- You want a table of contents -->
<!-- Use symbolic labels for references -->
<!-- This sorts the references -->
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<?rfc sortrefs="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<rfc category="std" docName="draft-li-quic-nat-optimization-00" ipr="trust200902">
  <front>
    <title abbrev="QUIC Group">QUIC NAT</title>

    <author fullname="Zhiqiang Li" initials="Z." surname="Li">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>lizhiqiangyjy@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Wei Cheng" initials="W." surname="Cheng">
      <organization>Centec</organization>

      <address>
        <postal>
          <street/>

          <city>Suzhou</city>

          <code>215000</code>

          <country>China</country>
        </postal>

        <email>chengw@centec.com</email>
      </address>
    </author>

    <author fullname="Junjie Wang" initials="J." surname="Wang">
      <organization>Centec</organization>

      <address>
        <postal>
          <street/>

          <city>Suzhou</city>

          <code>21500</code>

          <country>China</country>
        </postal>

        <email>wangjj@centec.com</email>
      </address>
    </author>

    <!---->

    <date day="03" month="March" year="2025"/>

    <area>Networking</area>

    <workgroup>QUIC Working Group</workgroup>

    <keyword>Quic;NAT</keyword>

    <abstract>
      <t>QUIC uses UDP as its transport layer protocol. Many existing 
      NAT routers rely on observing TCP SYN, ACK, and FIN packets to 
      determine the establishment and termination of connections, 
      thereby precisely maintaining the lifecycle of NAT mapping entries. 
      For QUIC, NAT devices can only manage mapping entries based on 
      ordinary UDP aging mechanisms, which may cause NAT entries for 
      long-lived QUIC connections to be prematurely aged and re-bound, 
      resulting in changes to source ports. This document proposes a 
      solution that extends the IP header options field to identify 
      QUIC connections, facilitating NAT devices that do not recognize 
      QUIC to accurately determine the lifecycle of QUIC connections  and 
      prevent random aging and re-mapping of long-lived QUIC connections.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in .</t>
    </note>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>QUIC (Quick UDP Internet Connections) is a transport layer protocol 
      that uses UDP and aims to provide reliable transmission similar to TCP. 
      However, because QUIC uses UDP, traditional NAT devices cannot manage 
      connection lifecycles by observing TCP connection establishment and 
      termination signals. This leads to the problem that long-lived QUIC 
      connections passing through NAT devices may be interrupted or experience 
      source port changes due to NAT mapping entries being aged out.
      Many existing NAT routers rely on observing TCP SYN, ACK, and FIN 
      packets to determine the establishment and termination of connections, 
      thereby precisely maintaining the lifecycle of NAT mapping entries. 
      For QUIC, NAT devices can only manage mapping entries based on ordinary 
      UDP aging mechanisms, which may cause NAT entries for long-lived QUIC
      connections to be prematurely aged and re-bound, resulting in changes
      to source ports.

      This document proposes a comprehensive solution that extends the IP
      header options field to optimize QUIC NAT traversal. The solution
      addresses four core issues:

      1. Connection Identification: By including a Connection ID, the
          solution allows NAT devices to accurately determine the lifecycle
          of QUIC connections, preventing random aging and re-mapping of
          long-lived QUIC connections.

      2. Dynamic Aging Time: An Aging Time field enables the service side
          to dynamically maintain session aging times, reducing resource
          overhead for NAT devices.

      3. Service Level Classification: A Service Level field allows for
          user-defined end-to-end service quality classifications, enabling
          NAT devices to differentiate service priorities and implement
          fine-grained quality of service in conjunction with IP DSCP.

      4. Security Group Division: A Security Group ID field supports the
          division of different security groups, allowing network devices
          to directly implement security policies based on this ID.      
      </t>
    </section>

    <section title="Problem Statement">
      <t>Traditional NAT routers rely on observing TCP SYN, ACK, and FIN 
      packets to determine the establishment and termination of TCP connections, 
      thereby precisely maintaining the lifecycle of NAT mapping entries.</t>

      <t>For QUIC, which is based on UDP, NAT devices can only manage mapping 
      entries using the standard UDP aging mechanism. UDP aging mechanisms 
      are usually based on fixed timeout intervals and cannot adjust according 
      to the actual state of the connection. This results in the following issues:
      NAT mapping entries for long-lived QUIC connections may be prematurely aged, 
      requiring re-establishment of the mapping.
      Re-establishing mapping relationships may lead to changes in source ports, 
      affecting the continuity and performance of QUIC connections.
      As shown in the figure below (figure to be inserted), the occurrence 
      process of the above problem is depicted.</t>
    </section>

    <section title="Solution">
      <t>This proposal extends the IP header options field to mark QUIC connections, 
      allowing NAT devices that do not natively support QUIC to accurately 
      determine the lifecycle of a QUIC connection. This prevents random aging 
      and re-mapping of long-lived QUIC connections by the NAT device.</t>

      <section title="Analysis of QUIC NAT Packet Format">
        <t>The format of a QUIC packet is shown in the figure below. The 
        Connection ID field in the QUIC header is used to identify a QUIC 
        connection. This field has a variable length, which can be 0, 1, 4, 
        or 8 bytes, depending on the encoding of the preceding Flags field.</t>

          <figure align="center" title="QUIC NAT Packet Format of IP Option">
            <artwork type="ascii-art">    0               1               2               3               4
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Option Type |    Length     |      Connection ID            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Aging Time  | Service Level |      Security Group ID        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
          </figure>
      <t>Connection ID, The Connection ID field is used to identify a QUIC connection,
          allowing NAT devices to accurately recognize and maintain the
          lifecycle of QUIC connections. This prevents random aging and
          re-mapping of long-lived QUIC connections by NAT devices that do not
          natively support QUIC protocol recognition.</t>

      <t>Aging Time, The Aging Time field represents the aging time of each session. 
          It is dynamically maintained by the service side, reducing the resource
          overhead and cost for NAT devices in terms of session state statistics
          and monitoring.</t>

      <t>Service Level, The Service Level field indicates the service quality 
          classification for the connection. This allows users to specify end-to-end 
          service quality classifications. NAT devices can use this field to
          differentiate service priorities and implement fine-grained quality
          of service in conjunction with IP DSCP, enabling hierarchical
          multi-level scheduling.</t>

      <t>Security Group ID, The Security Group ID field is used to divide different 
          security groups. Users can specify different security groups, and network
          devices can directly implement security policies based on the
          Security Group ID. This reduces the resource cost and complexity of
          security matching table entries on devices.</t>
		</section>
  </section>

  <section title="Conclusion">
    <t>This document proposes a QUIC NAT optimization solution based on
      extending the IP header options field. By introducing fields for
      Connection ID, Aging Time, Service Level, and Security Group ID,
      this solution addresses issues related to connection lifecycle
      management, resource optimization, service quality differentiation,
      and security policy implementation in NAT environments for QUIC
      connections. This comprehensive approach ensures connection stability,
      performance, and security while reducing the burden on NAT devices.</t>
  </section>

  <section anchor="Security" title="Security Considerations">
    <t>TBD.</t>
  </section>
    <section anchor="IANA" title="IANA Considerations">
    <t>TBD.</t>
  </section>
  </middle>
  <back/>

</rfc>
