Using QUIC to traverse NATs
draft-seemann-quic-nat-traversal-03

QUIC                                                          M. Seemann
Internet-Draft                                                          
Intended status: Standards Track                              E. Kinnear
Expires: 11 April 2027                                        Apple Inc.
                                                          8 October 2026

                      Using QUIC to traverse NATs
                  draft-seemann-quic-nat-traversal-03

Abstract

   This document specifies a QUIC extension for traversing Network
   Address Translators (NATs).  Endpoints use an existing proxied QUIC
   connection to coordinate path validation attempts that create the NAT
   bindings needed for a direct path and test its connectivity.
   Application data can be exchanged over the proxied path while NAT
   traversal is in progress.  Once a suitable direct path has been
   validated, the connection can migrate to it.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the QUIC Working Group
   mailing list (quic@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/quic/.

   Source for this draft and an issue tracker can be found at
   https://github.com/marten-seemann/draft-seemann-quic-nat-traversal.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 11 April 2027.

Seemann & Kinnear         Expires 11 April 2027                 [Page 1]
Internet-Draft             QUIC NAT Traversal               October 2026

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Background: NAT Traversal with ICE  . . . . . . . . . . . . .   3
   4.  NAT Traversal Extension Overview  . . . . . . . . . . . . . .   4
   5.  Candidate Discovery and Exchange  . . . . . . . . . . . . . .   4
     5.1.  Gathering Address Candidates  . . . . . . . . . . . . . .   4
     5.2.  Advertising Server Address Candidates . . . . . . . . . .   4
     5.3.  Forming Candidate Pairs . . . . . . . . . . . . . . . . .   5
   6.  Coordinated Path Probing  . . . . . . . . . . . . . . . . . .   5
     6.1.  Grant Limits  . . . . . . . . . . . . . . . . . . . . . .   6
     6.2.  Punching Connection IDs . . . . . . . . . . . . . . . . .   6
       6.2.1.  Use with Multipath  . . . . . . . . . . . . . . . . .   7
     6.3.  Probes Received on a Different Base . . . . . . . . . . .   7
     6.4.  Amplification Attack Mitigation . . . . . . . . . . . . .   7
   7.  Extension Negotiation . . . . . . . . . . . . . . . . . . . .   7
   8.  Frames  . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  PUNCH_GRANT Frame . . . . . . . . . . . . . . . . . . . .   8
     8.2.  MAX_PUNCH_GRANTS Frame  . . . . . . . . . . . . . . . . .   8
     8.3.  PUNCH_REQUEST Frame . . . . . . . . . . . . . . . . . . .   9
     8.4.  PUNCH_DONE Frame  . . . . . . . . . . . . . . . . . . . .  10
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     11.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

Seemann & Kinnear         Expires 11 April 2027                 [Page 2]
Internet-Draft             QUIC NAT Traversal               October 2026

1.  Introduction

   This document specifies an extension to QUIC ([RFC9000]) that enables
   endpoints behind NATs to establish a direct path for an existing
   connection.  The extension uses QUIC's path validation mechanism to
   create NAT bindings and test connectivity, and connection migration
   to move the connection to a suitable direct path.

   The endpoints first establish a QUIC connection over a proxied path.
   This connection carries both application data and the signaling
   needed to coordinate NAT traversal.  The server advertises its
   address candidates, and the client pairs them with its own candidates
   and requests coordinated path validation attempts.  Both endpoints
   send path validation packets toward the selected peer addresses to
   create the necessary NAT bindings.

   Application data can be exchanged over the proxied path while these
   attempts are in progress.  If a suitable direct path is validated,
   the connection can migrate to it.  Otherwise, the endpoints can
   continue using the proxied path.

   The extension borrows address candidate pairing concepts from
   Interactive Connectivity Establishment (ICE; [RFC8445]), but does not
   use the ICE protocol.

2.  Conventions and Definitions

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Sending base:  The local sending context used for an address
      candidate, such as a UDP socket on a particular network interface
      or a tunnel.

3.  Background: NAT Traversal with ICE

   When an external signaling channel is used, the QUIC connection is
   established after the two ICE agents have agreed on a candidate pair.
   This mode doesn't require any modification to existing QUIC stacks.
   In particular, it does not necessitate the negotiation of the
   extension defined in this document.

   For address discovery to work, QUIC and ICE need to use the same UDP
   socket.  Since this requires demultiplexing of QUIC and STUN packets,
   the QUIC bit cannot be greased as described in [RFC9287].

Seemann & Kinnear         Expires 11 April 2027                 [Page 3]
Internet-Draft             QUIC NAT Traversal               October 2026

   Once ICE has completed, the client immediately initiates a normal
   QUIC handshake using the server's address from the nominated address
   pair.  The ICE connectivity checks should have created the necessary
   NAT bindings for the client's first flight to reach the server and
   for the server's first flight to reach the client.

4.  NAT Traversal Extension Overview

   QUIC's path validation mechanism can be used to establish the
   required NAT mappings that allow for a direct connection.  Once the
   NAT mappings are established, QUIC's connection migration can be used
   to migrate the connection to a direct path.  During the path
   validation phase, multiple different paths might be established in
   parallel.  When using QUIC Multipath [MULTIPATH], these paths may be
   used at the same time; however, the mechanism described in this
   document does not require the use of QUIC multipath.

   Although ICE is not directly used, the logic run on the client makes
   use of ICE's candidate pairing logic (see especially Section 6.1.2.2
   of [RFC8445]).  Implementations are free to implement different
   algorithms as they see fit.

   This mode needs to be negotiated during the handshake; see Section 7.

5.  Candidate Discovery and Exchange

5.1.  Gathering Address Candidates

   The gathering of address candidates is out of scope for this
   document.  Endpoints MAY use the logic described in Sections 5.1.1
   and 5.2 of [RFC8445], or they MAY use address candidates provided by
   the application.

5.2.  Advertising Server Address Candidates

   The server advertises its address candidates using
   ALTERNATIVE_ADDRESS frames, as defined in [ALTERNATIVE-ADDRESS].
   Each frame advertises the complete set of alternative addresses and
   replaces the previously advertised set.  The server SHOULD NOT wait
   until address candidate discovery has finished; instead, it SHOULD
   update the advertised set as soon as new candidates become available.
   This speeds up NAT traversal and is similar to Trickle ICE
   ([RFC8838]).

   The server stores the sending bases associated with each advertised
   address.  Candidates with different sending bases MUST be advertised
   as separate entries, even if their advertised addresses are
   identical.

Seemann & Kinnear         Expires 11 April 2027                 [Page 4]
Internet-Draft             QUIC NAT Traversal               October 2026

   Each advertisement of an address MUST retain one entry per base ever
   advertised for it on this connection.  Without an increase in the
   entry count, the client cannot distinguish a replaced base from an
   unchanged one and might not schedule another attempt.

   Across advertisements, entries for the same address MUST retain their
   relative order and associated sending bases.  Entries for new bases
   MUST follow the existing entries for that address.

   The server MAY withdraw an address by omitting all its entries from a
   subsequent address-set update.

   Since address matching is run on the client side, only the server
   advertises address candidates.  The client communicates selected
   address pairs to the server using PUNCH_REQUEST frames.

5.3.  Forming Candidate Pairs

   The client matches the address candidates sent by the server with its
   own address candidates, forming candidate pairs.  Section 5.1 of
   [RFC8445] describes an algorithm for pairing address candidates.
   Since the pairing algorithm is only run on the client side, the
   endpoints do not need to agree on the algorithm used, and the client
   is free to use a different algorithm.

   The client MUST treat local candidates with different sending bases
   and distinct server entries as separate candidates, even if their
   addresses are identical.  It SHOULD request one attempt per
   compatible pair.  Across advertisements, the client identifies a
   server candidate by its address and position among entries for that
   address.

6.  Coordinated Path Probing

   The server authorizes attempts using PUNCH_GRANT (Section 8.1).  Each
   grant permits one independent path validation attempt for an address
   pair.  The client uses a grant by sending PUNCH_REQUEST with its
   Grant ID and the selected address pair on an established path.  It
   SHOULD start validation immediately after sending this request; the
   server SHOULD start immediately upon accepting it.  Validation
   follows Section 8.2 of [RFC9000], with additional rate limits
   (Section 6.4).  Each endpoint MUST set its own timeout following
   Section 8.2.4 of [RFC9000].

   Each endpoint MUST send probe packets containing PATH_CHALLENGE
   frames for an attempt from a single sending base to the peer address
   specified in the PUNCH_REQUEST.

Seemann & Kinnear         Expires 11 April 2027                 [Page 5]
Internet-Draft             QUIC NAT Traversal               October 2026

   Each endpoint MUST report success or timeout using PUNCH_DONE
   (Section 8.4); the server MUST also report rejection.  Before sending
   it, the endpoint MUST permanently stop sending probe packets
   containing PATH_CHALLENGE frames for that attempt.

   PUNCH_DONE does not stop the peer's probing or change its validation
   result.

   The client SHOULD request attempts as candidate pairs and unused
   grants become available, but MAY delay requests to prioritize pairs.

6.1.  Grant Limits

   The client's nat_traversal transport parameter (Section 7) sets the
   initial cumulative grant limit.  MAX_PUNCH_GRANTS (Section 8.2) can
   increase it.  The server MUST NOT issue a grant whose Grant ID is
   greater than or equal to the largest limit received.  The client MUST
   treat receipt of a grant at or above its largest advertised limit as
   a connection error of type PROTOCOL_VIOLATION.

   The server decides when to issue grants within the limit; the client
   decides when to increase it.

6.2.  Punching Connection IDs

   This document introduces punching connection IDs, a new type of
   connection ID for coordinated path probing.  They have the same wire
   format in packet headers as ordinary connection IDs and MUST satisfy
   the unlinkability requirements in Section 5.1 of [RFC9000].

   Each endpoint issues two punching connection IDs per grant, using
   PUNCH_GRANT or PUNCH_REQUEST, respectively.  The IDs MUST be distinct
   from all others issued by that endpoint on the connection.

   In most circumstances, only one of the two connection IDs is needed,
   but there are certain network setups where both need to be used
   (Section 6.3).

   The NEW_CONNECTION_ID and RETIRE_CONNECTION_ID mechanisms of
   [RFC9000] and the active_connection_id_limit transport parameter do
   not apply to punching connection IDs.

   Packets containing PATH_CHALLENGE or PATH_RESPONSE frames for an
   attempt MUST use one of the peer's punching connection IDs for that
   grant.  Non-probing packets MUST NOT use these IDs.  If a peer
   receives a non-probing packet that used a punching connection ID, it
   MUST close the connection with an error of type PROTOCOL_VIOLATION.

Seemann & Kinnear         Expires 11 April 2027                 [Page 6]
Internet-Draft             QUIC NAT Traversal               October 2026

   An endpoint retires a grant's punching connection IDs after both
   sending and receiving PUNCH_DONE (Section 8.4) for that attempt.

6.2.1.  Use with Multipath

   When QUIC multipath [MULTIPATH] is negotiated, packets using punching
   connection IDs MUST use the reserved Path ID 0xffffffff for nonce
   calculation and acknowledgments.  All grants share its packet number
   space, which MUST persist for the connection's lifetime without
   resetting packet numbers.  This ID is excluded from ordinary path
   allocation, path limits, and path management.  PATH_ACK frames for
   this ID MUST be sent on a validated path using an ordinary
   destination connection ID.

6.3.  Probes Received on a Different Base

   Under certain network configurations, a probe packet can arrive at a
   different base than the one the receiving endpoint selected for its
   attempt.  This can happen when overlapping address spaces give
   candidates with different bases the same address (Appendix B.2 of
   [RFC8445]).

   Both endpoints follow the path validation rules of [RFC9000] in
   addition to the coordinated probing rules above.  An endpoint sends a
   packet containing the PATH_RESPONSE from the receiving base to the
   probe's source address.  A matching PATH_RESPONSE validates the path
   on which the corresponding probe was sent, regardless of where the
   response arrives.

6.4.  Amplification Attack Mitigation

   TODO describe exactly how to mitigate amplification attacks

7.  Extension Negotiation

   Endpoints advertise their support of the extension by sending the
   nat_traversal (0x3d7e9f0bca12fea6) transport parameter (Section 7.4
   of [RFC9000]).

   The client's value is a single variable-length integer specifying the
   initial cumulative grant limit (Section 6.1).  The server MUST send
   an empty value.  An endpoint that understands this transport
   parameter MUST treat receipt of an invalid value as a connection
   error of type TRANSPORT_PARAMETER_ERROR.

Seemann & Kinnear         Expires 11 April 2027                 [Page 7]
Internet-Draft             QUIC NAT Traversal               October 2026

   The client MUST also send the alternative_address transport parameter
   defined in [ALTERNATIVE-ADDRESS].  A server that understands
   nat_traversal MUST treat receipt of nat_traversal without
   alternative_address as a connection error of type
   TRANSPORT_PARAMETER_ERROR.

   This transport parameter MUST NOT be remembered for use in 0-RTT.
   The frames defined in this document MUST only be sent in 1-RTT
   packets.

8.  Frames

   This extension defines the PUNCH_GRANT, MAX_PUNCH_GRANTS,
   PUNCH_REQUEST, and PUNCH_DONE frames.

8.1.  PUNCH_GRANT Frame

   PUNCH_GRANT Frame {
       Type (i) = 0x3d7e96,
       Grant ID (i),
       Connection ID 1 Length (8),
       Connection ID 1 (8..160),
       Connection ID 2 Length (8),
       Connection ID 2 (8..160),
   }

   PUNCH_GRANT authorizes one attempt and supplies the two server-issued
   punching connection IDs (Section 6.2).  The server MUST number new
   grants consecutively from 0 within each connection, subject to the
   client's grant limit (Section 6.1).

   Both Connection ID Length fields specify a length in bytes from 1 to
   20; other values MUST be treated as FRAME_ENCODING_ERROR.

   PUNCH_GRANT is ack-eliciting and sent on a validated path.  The Grant
   ID SHOULD be retransmitted on loss until acknowledged.

   This frame is only sent from the server to the client.  Servers MUST
   treat receipt of a PUNCH_GRANT frame as a connection error of type
   PROTOCOL_VIOLATION.

8.2.  MAX_PUNCH_GRANTS Frame

   MAX_PUNCH_GRANTS Frame {
       Type (i) = 0x3d7e97,
       Maximum Grants (i),
   }

Seemann & Kinnear         Expires 11 April 2027                 [Page 8]
Internet-Draft             QUIC NAT Traversal               October 2026

   Maximum Grants is the cumulative number of grants the server may
   issue, including grants already used.  Servers MUST ignore values
   that do not increase the limit.

   MAX_PUNCH_GRANTS is ack-eliciting and sent on a validated path.  On
   loss, the client MUST retransmit its current limit unless it has
   already been acknowledged.

   This frame is only sent from the client to the server.  Clients MUST
   treat receipt of a MAX_PUNCH_GRANTS frame as a connection error of
   type PROTOCOL_VIOLATION.

8.3.  PUNCH_REQUEST Frame

   PUNCH_REQUEST Frame {
       Type (i) = 0x3d7e92,
       Grant ID (i),
       Connection ID Length (8),
       Connection ID (8..160),
       Client Address Type (8),
       Client IP Address (32..128),
       Client Port (16),
       Advertisement Sequence Number (i),
       Entry Index (i),
   }

   The PUNCH_REQUEST frame contains the following fields:

   Grant ID:  The grant used for this attempt (Section 8.1).

   Connection ID Length and Connection ID:  The length in bytes and
      value of a client-issued punching connection ID (Section 6.2).
      Lengths outside 1 to 20 MUST be treated as FRAME_ENCODING_ERROR.

   Client Address Type:  The address family of the Client IP Address
      field.  The values 0x01 and 0x02 indicate IPv4 and IPv6,
      respectively, as in [ALTERNATIVE-ADDRESS].  Receipt of any other
      value MUST be treated as a connection error of type
      FRAME_ENCODING_ERROR.

   Client IP Address:  The client's address candidate.  This field is 32
      bits long for IPv4 and 128 bits long for IPv6, as indicated by
      Client Address Type.

   Client Port:  The port number of the client's address candidate.

   Advertisement Sequence Number:  The Sequence Number of the referenced
      ALTERNATIVE_ADDRESS frame.

Seemann & Kinnear         Expires 11 April 2027                 [Page 9]
Internet-Draft             QUIC NAT Traversal               October 2026

   Entry Index:  The zero-based index of the selected IPv4 or IPv6 entry
      in that frame, counting all entries, including CURRENT_PATH.

   The client MUST use a received, unused grant for each new attempt.
   Sending PUNCH_REQUEST permanently binds that grant to the client
   address and server entry reference, even if rejected.  The client
   MUST send PUNCH_REQUEST:

   *  On an established path, using an ordinary destination connection
      ID and carrying one of its punching connection IDs.  Only this
      copy starts the server's validation.

   *  In every probe packet containing PATH_CHALLENGE for the attempt,
      carrying its other punching connection ID.

   The server MUST process both forms in either arrival order, ignoring
   duplicates of each form, and process the direct copy before answering
   its PATH_CHALLENGE.  Both forms MUST use the same Grant ID, client
   address, Advertisement Sequence Number, and Entry Index;
   retransmissions MUST repeat each form's connection ID.  Unissued
   Grant IDs, mismatched destination connection IDs, and detected
   conflicting values MUST be treated as PROTOCOL_VIOLATION.

   For the first established-path copy, the server MUST send PUNCH_DONE
   with Status STALE_ADVERTISEMENT if the referenced advertisement is
   older than its latest, without starting validation.  Otherwise, an
   unsent advertisement or an index that does not select an IPv4 or IPv6
   entry MUST be treated as PROTOCOL_VIOLATION.

   For accepted attempts, the server MUST use the selected entry's
   sending base.  Later advertisements MUST NOT change the selected
   address or base.

   PUNCH_REQUEST is a probing frame (Section 9.1 of [RFC9000]) and is
   ack-eliciting.  The established-path copy MUST be retransmitted on
   loss until it is acknowledged or the server's PUNCH_DONE is received,
   even after local probing ends.  Direct copies MUST NOT be
   retransmitted independently.

   This frame is only sent from the client to the server.  Clients MUST
   treat receipt of a PUNCH_REQUEST frame as a connection error of type
   PROTOCOL_VIOLATION.

8.4.  PUNCH_DONE Frame

Seemann & Kinnear         Expires 11 April 2027                [Page 10]
Internet-Draft             QUIC NAT Traversal               October 2026

   PUNCH_DONE Frame {
       Type (i) = 0x3d7e95,
       Grant ID (i),
       Status (i),
   }

   The Grant ID identifies the attempt.  Status reports the sender's
   result:

   *  SUCCEEDED (0x00): The sender's path validation succeeded.

   *  FAILED (0x01): The sender's path validation timed out.

   *  REJECTED (0x02): The server declined to start the attempt.  The
      client SHOULD NOT retry the same candidate pair.

   *  STALE_ADVERTISEMENT (0x03): The referenced advertisement was
      superseded.

   After STALE_ADVERTISEMENT, the client MUST use a newer advertisement
   for any retry.

   Each endpoint's Status MUST remain unchanged for a given Grant ID.
   Endpoints MUST treat detected conflicting statuses from the peer for
   a grant as a connection error of type PROTOCOL_VIOLATION.

   PUNCH_DONE can only be sent in response to a PUNCH_REQUEST.  A client
   that receives a PUNCH_DONE frame with a Grant ID for which it didn't
   send a PUNCH_REQUEST frame MUST close the connection with an error of
   type PROTOCOL_VIOLATION.  Due to packet reordering, a server might
   receive a PUNCH_DONE frame before receiving the corresponding
   PUNCH_REQUEST frame.  Servers MUST treat an unissued Grant ID as a
   connection error of type PROTOCOL_VIOLATION.

   An unknown Status, or REJECTED or STALE_ADVERTISEMENT received by a
   server, MUST be treated as a connection error of type
   FRAME_ENCODING_ERROR.

   If PUNCH_DONE arrives before the request sent on the established
   path, the server MUST retain the Status and process that request
   normally when it arrives.

   PUNCH_DONE is a non-probing, ack-eliciting frame sent on a validated
   path.  It MUST be retransmitted on loss until acknowledged.

Seemann & Kinnear         Expires 11 April 2027                [Page 11]
Internet-Draft             QUIC NAT Traversal               October 2026

9.  Security Considerations

   This document expands QUIC's path validation logic to QUIC servers,
   allowing a QUIC client to request the sending of path validation
   packets on unverified paths.  A malicious client can direct traffic
   to a target IP.  This attack is similar to the IP address spoofing
   attack that address validation during connection establishment (see
   Section 8.1 of [RFC9000]) is designed to prevent.  In practice,
   however, IP address spoofing is often additionally mitigated by
   ingress and egress filtering at the IP layer.  This mitigation is not
   possible when using this extension.  The server therefore needs to
   carefully limit the amount of data it sends on unverified paths.

10.  IANA Considerations

   TODO: fill out registration request for the transport parameter and
   frame types

11.  References

11.1.  Normative References

   [ALTERNATIVE-ADDRESS]
              Munizaga, M. and M. Seemann, "QUIC Alternative Server
              Address Frames", Work in Progress, Internet-Draft, draft-
              munizaga-quic-alternative-server-address-02, 25 September
              2026, <https://datatracker.ietf.org/doc/html/draft-
              munizaga-quic-alternative-server-address-02>.

   [MULTIPATH]
              Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema,
              C., and M. Kühlewind, "Managing multiple paths for a QUIC
              connection", Work in Progress, Internet-Draft, draft-ietf-
              quic-multipath-21, 17 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
              multipath-21>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Seemann & Kinnear         Expires 11 April 2027                [Page 12]
Internet-Draft             QUIC NAT Traversal               October 2026

   [RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
              Connectivity Establishment (ICE): A Protocol for Network
              Address Translator (NAT) Traversal", RFC 8445,
              DOI 10.17487/RFC8445, July 2018,
              <https://www.rfc-editor.org/rfc/rfc8445>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [RFC9287]  Thomson, M., "Greasing the QUIC Bit", RFC 9287,
              DOI 10.17487/RFC9287, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9287>.

11.2.  Informative References

   [RFC8838]  Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE:
              Incremental Provisioning of Candidates for the Interactive
              Connectivity Establishment (ICE) Protocol", RFC 8838,
              DOI 10.17487/RFC8838, January 2021,
              <https://www.rfc-editor.org/rfc/rfc8838>.

Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Marten Seemann
   Email: martenseemann@gmail.com

   Eric Kinnear
   Apple Inc.
   One Apple Park Way
   Cupertino, California 95014,
   United States of America
   Email: ekinnear@apple.com

Seemann & Kinnear         Expires 11 April 2027                [Page 13]