



Network Working Group                                        R. Collette
Internet-Draft                                                  VextCODE
Intended status: Experimental                           13 February 2026
Expires: 17 August 2026


          SIN/IP: Secure In-Network Transport Protocol over IP
                   draft-collette-sinip-transport-00

Abstract

   SIN/IP is a secure, multiplexed transport protocol designed for
   kernel residency and incremental deployment.  It provides
   authenticated encryption (AEAD), multiplexed streams over a single
   connection to avoid head-of-line blocking, connection IDs for NAT
   rebinding and path migration, and pluggable congestion control and
   pacing.  SIN/IP can run as a native IP protocol in controlled
   networks or be encapsulated in UDP for Internet deployment.  This
   document specifies the wire format, packet and frame layout,
   connection establishment, packet protection, loss recovery, flow
   control, congestion control, path management, and connection
   termination.  It also defines IANA registries for SIN/IP parameters
   and codepoints.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This is a contribution to the RFC Series, independently
   of any other RFC stream.  The RFC Editor has chosen to publish this
   document at its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not candidates for any level of Internet Standard;
   see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at https://www.rfc-
   editor.org/info/rfcXXXX (https://www.rfc-editor.org/info/rfcXXXX).

Copyright Notice

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





Collette                 Expires 17 August 2026                 [Page 1]

Internet-Draft              SIN/IP Transport               February 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info (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.

Table of Contents

   {:toc}

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 17 August 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  . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Rationale and Design Principles . . . . . . . . . . . . . . .   6



Collette                 Expires 17 August 2026                 [Page 2]

Internet-Draft              SIN/IP Transport               February 2026


   5.  Protocol Overview (One-Page Summary)  . . . . . . . . . . . .   6
   6.  Conventions and Definitions . . . . . . . . . . . . . . . . .   6
     6.1.  Requirements Language . . . . . . . . . . . . . . . . . .   7
     6.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   7
     6.3.  Notation  . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Architecture and Service Model  . . . . . . . . . . . . . . .   7
     7.1.  Connection Model  . . . . . . . . . . . . . . . . . . . .   7
     7.2.  Streams and Application Semantics . . . . . . . . . . . .   8
     7.3.  Reliability vs Datagram Service (Optional Extension)  . .   8
   8.  Deployment Modes  . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  UDP Encapsulation Mode  . . . . . . . . . . . . . . . . .   8
     8.2.  Native IP Protocol Mode . . . . . . . . . . . . . . . . .   8
     8.3.  Middlebox Traversal Considerations  . . . . . . . . . . .   9
   9.  Packet Format . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Common Packet Structure . . . . . . . . . . . . . . . . .   9
     9.2.  Fixed Header  . . . . . . . . . . . . . . . . . . . . . .   9
     9.3.  Header Field Semantics  . . . . . . . . . . . . . . . . .  10
     9.4.  Connection IDs  . . . . . . . . . . . . . . . . . . . . .  11
     9.5.  Packet Numbers and Spaces . . . . . . . . . . . . . . . .  11
     9.6.  Versioning and Extensibility  . . . . . . . . . . . . . .  11
     9.7.  Ossification Resistance . . . . . . . . . . . . . . . . .  12
   10. Frame Format  . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Frame Encoding . . . . . . . . . . . . . . . . . . . . .  12
     10.2.  Frame Type Registry (Normative Table)  . . . . . . . . .  12
     10.3.  STREAM . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.4.  STREAM_FIN . . . . . . . . . . . . . . . . . . . . . . .  13
     10.5.  ACK  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.6.  PING . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.7.  PATH_CHALLENGE . . . . . . . . . . . . . . . . . . . . .  14
     10.8.  PATH_RESPONSE  . . . . . . . . . . . . . . . . . . . . .  14
     10.9.  TRANSPORT_PARAMS . . . . . . . . . . . . . . . . . . . .  14
     10.10. CONNECTION_CLOSE . . . . . . . . . . . . . . . . . . . .  14
     10.11. NEW_CONNECTION_ID  . . . . . . . . . . . . . . . . . . .  14
     10.12. RETIRE_CONNECTION_ID . . . . . . . . . . . . . . . . . .  14
     10.13. Reserved / GREASE Frames . . . . . . . . . . . . . . . .  14
   11. Transport Parameters  . . . . . . . . . . . . . . . . . . . .  14
     11.1.  Encoding and Negotiation Rules . . . . . . . . . . . . .  14
     11.2.  Defined Transport Parameters . . . . . . . . . . . . . .  15
     11.3.  Defaults and Error Handling  . . . . . . . . . . . . . .  15
   12. Connection Establishment  . . . . . . . . . . . . . . . . . .  15
     12.1.  Handshake Overview . . . . . . . . . . . . . . . . . . .  15
     12.2.  Packet Types . . . . . . . . . . . . . . . . . . . . . .  15
     12.3.  Client State Machine . . . . . . . . . . . . . . . . . .  16
     12.4.  Server State Machine . . . . . . . . . . . . . . . . . .  16
     12.5.  Stateless Retry  . . . . . . . . . . . . . . . . . . . .  16
     12.6.  0-RTT Data . . . . . . . . . . . . . . . . . . . . . . .  16
     12.7.  Address Validation and Anti-Amplification  . . . . . . .  17
   13. Packet Protection . . . . . . . . . . . . . . . . . . . . . .  17



Collette                 Expires 17 August 2026                 [Page 3]

Internet-Draft              SIN/IP Transport               February 2026


     13.1.  Cryptographic Agility  . . . . . . . . . . . . . . . . .  17
     13.2.  Key Exchange . . . . . . . . . . . . . . . . . . . . . .  17
     13.3.  Key Schedule . . . . . . . . . . . . . . . . . . . . . .  17
     13.4.  Nonce Construction . . . . . . . . . . . . . . . . . . .  17
     13.5.  AEAD and Associated Data . . . . . . . . . . . . . . . .  18
     13.6.  Key Update and Epoch Handling  . . . . . . . . . . . . .  18
     13.7.  Replay Protection  . . . . . . . . . . . . . . . . . . .  18
   14. Reliability and Loss Recovery . . . . . . . . . . . . . . . .  18
     14.1.  ACK Generation . . . . . . . . . . . . . . . . . . . . .  18
     14.2.  Retransmission and PTO . . . . . . . . . . . . . . . . .  18
     14.3.  Reordering, Duplicate Detection, and Thresholds  . . . .  18
   15. Flow Control  . . . . . . . . . . . . . . . . . . . . . . . .  19
     15.1.  Connection-Level Flow Control  . . . . . . . . . . . . .  19
     15.2.  Stream-Level Flow Control  . . . . . . . . . . . . . . .  19
     15.3.  Stream Limits  . . . . . . . . . . . . . . . . . . . . .  19
   16. Congestion Control  . . . . . . . . . . . . . . . . . . . . .  19
     16.1.  Requirements . . . . . . . . . . . . . . . . . . . . . .  19
     16.2.  Default Congestion Controller  . . . . . . . . . . . . .  19
     16.3.  Pacing . . . . . . . . . . . . . . . . . . . . . . . . .  19
     16.4.  PLPMTUD (If Supported) . . . . . . . . . . . . . . . . .  20
   17. Path Management and Mobility  . . . . . . . . . . . . . . . .  20
     17.1.  NAT Rebinding  . . . . . . . . . . . . . . . . . . . . .  20
     17.2.  Connection Migration . . . . . . . . . . . . . . . . . .  20
     17.3.  Path Validation Using PATH_CHALLENGE/PATH_RESPONSE . . .  20
   18. Connection Termination  . . . . . . . . . . . . . . . . . . .  20
     18.1.  Graceful Close . . . . . . . . . . . . . . . . . . . . .  20
     18.2.  Stateless Reset  . . . . . . . . . . . . . . . . . . . .  20
     18.3.  TIME_WAIT and Reuse Rules  . . . . . . . . . . . . . . .  21
   19. Middlebox Considerations  . . . . . . . . . . . . . . . . . .  21
   20. Implementation Considerations . . . . . . . . . . . . . . . .  21
     20.1.  Kernel Integration Considerations  . . . . . . . . . . .  21
     20.2.  Resource Limits and DoS Hardening  . . . . . . . . . . .  21
     20.3.  Buffering, Reassembly, and Zero-Copy . . . . . . . . . .  21
   21. Security Considerations . . . . . . . . . . . . . . . . . . .  21
   22. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  22
   23. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   24. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     24.1.  Normative References . . . . . . . . . . . . . . . . . .  24
     24.2.  Informative References . . . . . . . . . . . . . . . . .  24
   25. Appendix A.  Wire Image Examples (Hex + Field Decode) . . . .  24
   26. Appendix B.  State Machines (Full)  . . . . . . . . . . . . .  25
   27. Appendix C.  Test Vectors (Crypto)  . . . . . . . . . . . . .  26
   28. Appendix D.  Design Notes (Non-Normative) . . . . . . . . . .  26
   29. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  26
   30. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . .  26
   31. Building This Draft . . . . . . . . . . . . . . . . . . . . .  26
   32. Normative References (BCP 14) . . . . . . . . . . . . . . . .  27
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  27



Collette                 Expires 17 August 2026                 [Page 4]

Internet-Draft              SIN/IP Transport               February 2026


1.  Introduction

   SIN/IP (Secure In-Network over IP) is a transport protocol that
   provides confidentiality, integrity, multiplexed streams, and
   connection identity decoupled from the network path.  It is designed
   to run in the kernel for consistent policy, zero-copy integration,
   and congestion control, while remaining deployable on the public
   Internet via UDP encapsulation.

2.  Goals

   *  *Secure by default:* All post-handshake data is protected with an
      AEAD.  Key exchange uses X25519; keys are derived with HKDF.
      Replay is prevented by authenticating packet numbers and optional
      token binding.
   *  *Multi-stream within one connection:* Multiple streams share one
      connection; each stream has its own offset space and reassembly.
      Loss on one stream does not block delivery on others (no head-of-
      line blocking).
   *  *Pluggable congestion control and pacing:* The design exposes
      hooks for CC modules (e.g., CUBIC, BBR) and pacing; ACK ranges
      feed loss detection and RTT estimation.
   *  *NAT rebinding support:* Connection IDs decouple the logical
      connection from the 4-tuple; path validation (PATH_CHALLENGE /
      PATH_RESPONSE) confirms reachability before migrating traffic.
   *  *Kernel residency:* The transport is intended to run in the kernel
      to enable zero-copy, stable socket API, policy enforcement, and
      observability.

3.  Non-Goals

   *  *Replacing TLS for application security semantics:* SIN/IP
      provides transport-layer encryption and optional server
      authentication (e.g., Ed25519 signature over the handshake).
      Application-level certificate verification and TLS-specific
      features remain the responsibility of the application or an
      optional TLS layer above SIN/IP.
   *  *Full Internet deployability without encapsulation:* A new IP
      protocol number is often blocked or altered by middleboxes.  SIN/
      IP specifies UDP encapsulation as the primary deployable mode for
      Internet use; native IP protocol is for controlled networks only.
   *  *Perfect compatibility with every existing socket behavior:* The
      API is designed to be familiar (stream, seqpacket, datagram) but
      may not mirror every legacy TCP or UDP quirk.







Collette                 Expires 17 August 2026                 [Page 5]

Internet-Draft              SIN/IP Transport               February 2026


4.  Rationale and Design Principles

   Modern applications need low-latency connection setup, multiple
   logical streams without head-of-line blocking, mobility across NATs,
   and encryption by default.  TCP plus TLS adds RTTs and does not
   multiplex; QUIC meets many of these goals but is typically
   implemented in userland, which complicates kernel policy, zero-copy,
   and observability.  SIN/IP targets environments where kernel control
   and transport evolution matter: datacenters, enterprise edges, and
   embedded or gateway deployments.

   Design principles include: (1) authenticate and encrypt all post-
   handshake traffic; (2) use a single, well-defined wire format for
   interoperability; (3) resist ossification via GREASE and "MUST ignore
   unknown" rules; (4) limit amplification and state allocation until
   the client is validated; (5) support both native IP and UDP
   encapsulation with the same wire format.

5.  Protocol Overview (One-Page Summary)

   A *connection* is identified by connection IDs (dcid, scid) and
   carries one or more *streams*. Each *packet* has a fixed 32-byte
   header and a payload of *frames*. *Packet numbers (PN)* are per space
   (Initial, Handshake, 1-RTT) and drive ACKs and nonce derivation.

   *Lifecycle:* The client sends an INITIAL packet (type 0) with its
   X25519 public key and connection ID.  The server may respond with
   RETRY (type 5) and a token for stateless retry; the client resends
   INITIAL with the token.  The server responds with SIN_ACK (type 1)
   with its public key.  Both derive the shared secret via X25519 and
   HKDF.  The client sends CONFIRM (type 2); once both have sent and
   received 1-RTT packets (type 3), the connection is ESTABLISHED.  Data
   transfer uses 1-RTT packets carrying STREAM, ACK, PING, and other
   frames.  Teardown uses CONNECTION_CLOSE or FIN; STATELESS_RST (type
   6) allows the server to reject unknown connections without state.

   *Deployment:* In *native* mode, SIN/IP is carried directly in IP
   (IPv4 or IPv6) with a dedicated protocol number.  In *UDP-
   encapsulated* mode, each SIN/IP packet is sent inside a UDP datagram.
   UDP encapsulation is the primary deployable mode for Internet use;
   implementations intended for general Internet use MUST support it.

6.  Conventions and Definitions








Collette                 Expires 17 August 2026                 [Page 6]

Internet-Draft              SIN/IP Transport               February 2026


6.1.  Requirements Language

   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.

6.2.  Terminology

   *  *Connection:* The long-lived association between two endpoints,
      keyed by connection IDs.
   *  *Stream:* A unidirectional or bidirectional logical channel within
      a connection, with its own offset space for data.
   *  *Frame:* A typed unit inside the protected payload (STREAM, ACK,
      PING, PATH_CHALLENGE, etc.).
   *  *Packet:* A unit of transmission consisting of a fixed 32-byte
      header plus payload (frames) and, when encrypted, a 16-byte AEAD
      tag.
   *  *Packet number (PN):* A monotonically increasing value per packet
      number space, used for acknowledgments, loss detection, and nonce
      derivation.
   *  *Connection ID (CID):* An opaque identifier used for
      demultiplexing.  The receiver uses the *destination CID (dcid)* to
      identify the connection; the *source CID (scid)* identifies the
      sender.
   *  *Endpoint:* Either peer in a SIN/IP connection (client or server).

6.3.  Notation

   *  All multi-byte integer fields in the wire format are *big-endian*
      unless otherwise specified.
   *  Byte ranges and offsets are 0-based.
   *  "Payload" refers to the protected payload (frames) only; the
      16-byte AEAD tag, when present, is not part of the payload length.

7.  Architecture and Service Model

7.1.  Connection Model

   A SIN/IP connection is identified by connection IDs.  The receiver
   demultiplexes packets by destination connection ID (dcid).  The
   connection persists across path changes (e.g., NAT rebind) as long as
   the peer can be reached and path validation succeeds.  Each
   connection has distinct packet number spaces (Initial, Handshake,
   1-RTT) and keying material per direction.





Collette                 Expires 17 August 2026                 [Page 7]

Internet-Draft              SIN/IP Transport               February 2026


7.2.  Streams and Application Semantics

   Streams are identified by a stream ID.  Each stream has an
   independent send offset and receive offset.  The protocol ensures
   ordered delivery within a stream but not across streams.  Streams can
   be full-duplex.  The receiver reassembles data by stream_id and
   offset; loss on one stream does not block delivery on others.

7.3.  Reliability vs Datagram Service (Optional Extension)

   The default service is reliable, ordered delivery per stream.
   Optional extensions (e.g., capability version 1.1) may define partial
   reliability (deadline-based drop, unordered delivery) with normative
   semantics when enabled.  Such extensions are out of scope for the
   base wire format and are signaled via transport parameters or
   capability negotiation.

8.  Deployment Modes

8.1.  UDP Encapsulation Mode

   In UDP encapsulation mode, each SIN/IP packet is sent as the payload
   of a UDP datagram.  This is the *primary deployable mode* for use on
   the public Internet, because many middleboxes drop or alter non-TCP/
   UDP traffic.  Implementations intended for general Internet use MUST
   support UDP encapsulation.

   The same 32-byte fixed header and frame encoding are used; only the
   outer delivery (UDP/IP) and PMTU handling differ.  Implementations
   MUST support a conservative default MTU (e.g., 1200 bytes for UDP
   payload) or process ICMP Packet Too Big when available.

8.2.  Native IP Protocol Mode

   In native mode, SIN/IP is carried directly in IPv4 or IPv6 with a
   dedicated protocol number (to be assigned by IANA).  This mode is for
   controlled networks (datacenter, enterprise) where the operator
   controls or trusts middleboxes.  The wire format is identical to UDP
   encapsulation; only the outer layer (IP next header / protocol)
   differs.











Collette                 Expires 17 August 2026                 [Page 8]

Internet-Draft              SIN/IP Transport               February 2026


8.3.  Middlebox Traversal Considerations

   Use of a new IP protocol number on the public Internet is NOT
   RECOMMENDED.  SIN/IP specifies UDP encapsulation as the normal mode
   for Internet deployment.  Middleboxes that allow UDP typically allow
   SIN/IP over UDP; those that block or alter non-TCP/UDP traffic will
   not affect UDP-encapsulated SIN/IP.  NAT rebinding is handled by
   connection IDs and path validation; no middlebox changes are
   required.

9.  Packet Format

9.1.  Common Packet Structure

   Every SIN/IP packet has:

   1.  *Fixed header:* 32 bytes (see {{fixed-header}}).
   2.  *Payload:* Zero or more bytes.  For handshake packets (INITIAL,
       SIN_ACK, CONFIRM, RETRY), the payload is unencrypted.  For 1-RTT
       and 0-RTT, the payload is encrypted and authenticated.
   3.  *AEAD tag:* 16 bytes, present only when the payload is encrypted.
       Immediately follows the payload.

   The total length of a packet is 32 + payload_len + (16 if encrypted).
   Implementations MUST reject packets shorter than 32 bytes.  If the
   payload_len field is inconsistent with the actual received length
   (e.g., extends beyond the packet), the packet MUST be discarded.

9.2.  Fixed Header

   The fixed header is exactly 32 bytes.  All multi-byte fields are big-
   endian.

   +========+======+=============+=====================================+
   | Offset | Size | Name        | Description                         |
   +========+======+=============+=====================================+
   | 0      | 1    | ver_type    | High 4 bits: version (see           |
   |        |      |             | {{version-registry}}).              |
   |        |      |             | Low 4 bits: packet type             |
   |        |      |             | (see {{packet-types}}).             |
   +--------+------+-------------+-------------------------------------+
   | 1      | 1    | flags       | Header flags                        |
   |        |      |             | (ACK_ELICITING, FIN,                |
   |        |      |             | KEY_PHASE, etc.).  See              |
   |        |      |             | {{header-flags}}.                   |
   +--------+------+-------------+-------------------------------------+
   | 2      | 1    | hlen_words  | Header length in 4-octet            |
   |        |      |             | units.  For version 1,              |



Collette                 Expires 17 August 2026                 [Page 9]

Internet-Draft              SIN/IP Transport               February 2026


   |        |      |             | this MUST be 8 (32                  |
   |        |      |             | bytes).                             |
   +--------+------+-------------+-------------------------------------+
   | 3      | 1    | reserved    | Reserved.  Senders MUST             |
   |        |      |             | set to 0; receivers MUST            |
   |        |      |             | ignore.                             |
   +--------+------+-------------+-------------------------------------+
   | 4      | 2    | epoch       | Key phase (handshake,               |
   |        |      |             | 0-RTT, 1-RTT).                      |
   +--------+------+-------------+-------------------------------------+
   | 6      | 2    | payload_len | Length in bytes of the              |
   |        |      |             | protected payload only              |
   |        |      |             | (excluding the 16-byte              |
   |        |      |             | AEAD tag when present).             |
   +--------+------+-------------+-------------------------------------+
   | 8      | 1    | stream_id   | Optional default stream             |
   |        |      |             | for this packet (0 means            |
   |        |      |             | no default).                        |
   +--------+------+-------------+-------------------------------------+
   | 9      | 1    | reserved2   | Reserved.  Senders MUST             |
   |        |      |             | set to 0; receivers MUST            |
   |        |      |             | ignore.                             |
   +--------+------+-------------+-------------------------------------+
   | 10     | 4    | pn          | Packet number in the                |
   |        |      |             | space implied by packet             |
   |        |      |             | type.                               |
   +--------+------+-------------+-------------------------------------+
   | 14     | 8    | dcid        | Destination connection ID           |
   |        |      |             | (8 bytes).                          |
   +--------+------+-------------+-------------------------------------+
   | 22     | 8    | scid        | Source connection ID (8             |
   |        |      |             | bytes).  May be zero in             |
   |        |      |             | INITIAL.                            |
   +--------+------+-------------+-------------------------------------+
   | 30     | 2    | hdr_ext     | Extension / reserved.               |
   |        |      |             | Senders MAY set to 0;               |
   |        |      |             | receivers MUST ignore               |
   |        |      |             | unless specified.                   |
   +--------+------+-------------+-------------------------------------+

                                  Table 1

   There is no padding between the header and the payload; the payload
   immediately follows the header.

9.3.  Header Field Semantics





Collette                 Expires 17 August 2026                [Page 10]

Internet-Draft              SIN/IP Transport               February 2026


   *  *ver_type:* The high nibble is the SIN/IP wire version.  The low
      nibble is the packet type.  Unknown versions or types MUST cause
      the packet to be discarded (see {{ossification}}).
   *  *payload_len:* Must not exceed the remaining packet length.  If
      payload_len indicates more data than received, the packet MUST be
      discarded.
   *  *pn:* Monotonically increasing within each packet number space.
      Used for ACKs, loss detection, and nonce derivation (see
      {{nonce}}).
   *  *dcid, scid:* Opaque 8-byte identifiers.  The receiver uses dcid
      to demultiplex to the correct connection.

9.4.  Connection IDs

   Connection IDs are 8 bytes.  The *destination connection ID (dcid)*
   is the identifier of the connection at the receiver; the *source
   connection ID (scid)* identifies the sender.  In an INITIAL packet,
   scid MAY be zero.  The receiver MUST use dcid to look up the
   connection.  CIDs allow the connection to survive address changes
   (NAT rebind, path migration) because the connection identity is not
   tied to the 4-tuple.

9.5.  Packet Numbers and Spaces

   Packet numbers are maintained in separate spaces: *Initial*,
   *Handshake*, and *1-RTT* (and optionally *0-RTT*).  Each space has
   its own keys and PNs.  Within a space, PN is monotonically
   increasing.  Key update MUST be triggered before PN wrap (e.g., at
   2^31 - 1 or by byte/time limits) so that (key, PN) remains unique for
   the lifetime of the key.

9.6.  Versioning and Extensibility

   The wire version (high 4 bits of ver_type) identifies the packet
   format.  Version 1 is defined in this document.  Unknown versions
   MUST be discarded.  Reserved and GREASE values (e.g., 0x0F) MUST be
   handled without fatal error (see {{ossification}}).  New wire-
   incompatible formats require a new version; new optional behaviors
   may be negotiated via transport parameters or capability version
   within the same wire version.











Collette                 Expires 17 August 2026                [Page 11]

Internet-Draft              SIN/IP Transport               February 2026


9.7.  Ossification Resistance

   Implementations MUST ignore *unknown packet types* (ver_type low
   nibble not in the assigned set): such packets MUST be discarded
   without failing the connection.  Implementations MUST ignore *unknown
   frame types*: skip the frame using the length field and continue
   parsing.  Implementations MUST ignore *unknown transport parameter
   IDs* within TRANSPORT_PARAMS.  Reserved and GREASE values (e.g.,
   ver_type 0x0F, packet type 15, frame type 255) MUST be handled
   without causing a fatal error.  Receivers MUST NOT treat unknown or
   reserved values as a reason to abort the connection.  This prevents
   ossification and allows future extensions.

10.  Frame Format

10.1.  Frame Encoding

   Frames are encoded as TLV: 1 byte type, 2 bytes length (big-endian),
   then value. *Frames MUST NOT span packets;* each frame is fully
   contained in a single packet's payload.  If a frame's length field
   indicates a value that extends beyond the remaining payload, the
   packet MUST be discarded. *Unknown frame types* MUST be ignored: the
   implementation skips the frame (using the length field to advance)
   and continues parsing; unknown frames MUST NOT cause the connection
   to fail.  Reserved and GREASE frame type values MUST be handled the
   same way.

10.2.  Frame Type Registry (Normative Table)

     +========+======================+==============================+
     | Type   | Name                 | Description                  |
     +========+======================+==============================+
     | 0      | PADDING              | Padding; may be used for     |
     |        |                      | alignment or GREASE.         |
     +--------+----------------------+------------------------------+
     | 1      | STREAM               | Stream data (stream_id,      |
     |        |                      | offset, length, data).       |
     +--------+----------------------+------------------------------+
     | 2      | STREAM_FIN           | Stream data with end-of-     |
     |        |                      | stream.                      |
     +--------+----------------------+------------------------------+
     | 3      | ACK                  | Acknowledgment with ranges   |
     |        |                      | (largest PN, delay, ranges). |
     +--------+----------------------+------------------------------+
     | 4      | PING                 | Keepalive; ACK-eliciting.    |
     +--------+----------------------+------------------------------+
     | 5      | PATH_CHALLENGE       | Path validation (8 bytes     |
     |        |                      | data).                       |



Collette                 Expires 17 August 2026                [Page 12]

Internet-Draft              SIN/IP Transport               February 2026


     +--------+----------------------+------------------------------+
     | 6      | PATH_RESPONSE        | Path validation response     |
     |        |                      | (echo 8 bytes).              |
     +--------+----------------------+------------------------------+
     | 7      | TRANSPORT_PARAMS     | Transport parameter TLV.     |
     +--------+----------------------+------------------------------+
     | 8      | NEW_CONNECTION_ID    | Issue new connection ID.     |
     +--------+----------------------+------------------------------+
     | 9      | RETIRE_CONNECTION_ID | Retire connection ID.        |
     +--------+----------------------+------------------------------+
     | 10     | CONNECTION_CLOSE     | Close connection with reason |
     |        |                      | code.                        |
     +--------+----------------------+------------------------------+
     | 11-254 | Reserved             | Reserved for future use.     |
     +--------+----------------------+------------------------------+
     | 255    | GREASE               | Reserved for GREASE.         |
     +--------+----------------------+------------------------------+

                                 Table 2

   Allocation policy for new frame types: Specification Required.

10.3.  STREAM

   STREAM carries data for a stream.  Format: type (1) = 1, length (2),
   then stream_id (1), offset (8), data length (2), data (variable).
   The receiver reassembles by stream_id and offset; duplicate data
   (same stream_id and offset) is deduplicated.

10.4.  STREAM_FIN

   Same as STREAM with an end-of-stream indication (e.g., a flag or
   separate type 2).  The receiver delivers data in order and then
   signals end-of-stream to the application.

10.5.  ACK

   ACK carries the largest received PN, an ACK delay, and a list of
   (count, first_pn) ranges indicating which packets were received.
   Format: type (1) = 3, length (2), largest_pn (4), ack_delay (2),
   num_ranges (1), then for each range: count (2), first_pn (4).  This
   provides SACK-like information for loss recovery.

10.6.  PING

   Type 4, length 0 (or minimal).  ACK-eliciting; used for keepalive or
   RTT measurement.




Collette                 Expires 17 August 2026                [Page 13]

Internet-Draft              SIN/IP Transport               February 2026


10.7.  PATH_CHALLENGE

   Type 5, length 8, value = 8 random bytes.  Sent to validate a new
   path; the peer echoes the bytes in PATH_RESPONSE.

10.8.  PATH_RESPONSE

   Type 6, length 8, value = 8 bytes (echo of PATH_CHALLENGE).  Proves
   the peer received the challenge and holds the connection keys.

10.9.  TRANSPORT_PARAMS

   Type 7.  Value is a TLV-encoded set of transport parameters
   (parameter ID, length, value).  Used in handshake for version
   negotiation, flow control limits, max streams, etc.  Unknown
   parameter IDs MUST be ignored.

10.10.  CONNECTION_CLOSE

   Type 10.  Carries a 16-bit reason code (see {{error-codes}}) and
   optional reason phrase.  Signals graceful or error close.

10.11.  NEW_CONNECTION_ID

   Type 8.  Issues a new connection ID to the peer for migration or load
   balancing.  Format and semantics are implementation-defined;
   typically includes sequence number and the new CID.

10.12.  RETIRE_CONNECTION_ID

   Type 9.  Tells the peer to retire a previously issued connection ID.

10.13.  Reserved / GREASE Frames

   Frame type 255 and reserved types (11-254) MUST be ignored.  Senders
   MAY send PADDING or GREASE for ossification resistance.  Receivers
   MUST NOT treat unknown or reserved frame types as fatal.

11.  Transport Parameters

11.1.  Encoding and Negotiation Rules

   Transport parameters are carried in TRANSPORT_PARAMS frames (or in
   the INITIAL/SIN_ACK payload in some implementations).  Each parameter
   has a 16-bit ID, 16-bit length, and value.  Parameters are negotiated
   during the handshake; the server can send its parameters in SIN_ACK,
   the client in CONFIRM or INITIAL.  Unknown parameter IDs MUST be
   ignored.



Collette                 Expires 17 August 2026                [Page 14]

Internet-Draft              SIN/IP Transport               February 2026


11.2.  Defined Transport Parameters

   At minimum, the following are used for interoperability:

   *  *Supported versions / capability version:* List or single value
      indicating supported capability set (e.g., 1.0, 1.1).  The
      selected version is the highest mutually supported.
   *  *Max streams:* Maximum number of streams the endpoint will accept.
   *  *Initial flow control window:* Initial connection-level and/or
      stream-level flow control window in bytes.
   *  *Idle timeout:* Connection idle timeout in milliseconds.

   Additional parameters (ECN support, pacing, etc.) may be defined in
   extension documents.  Allocation policy: Specification Required.

11.3.  Defaults and Error Handling

   If a required parameter is missing, implementations MAY use a safe
   default or close the connection with PROTOCOL_VIOLATION.  Invalid or
   out-of-range values SHOULD result in CONNECTION_CLOSE with an
   appropriate error code.

12.  Connection Establishment

12.1.  Handshake Overview

   The handshake is 1-RTT: INITIAL -> SIN_ACK -> CONFIRM.  Optionally,
   the server sends RETRY before SIN_ACK to enforce address validation
   (stateless retry). 0-RTT data may be sent with CONFIRM if the client
   has a session ticket.

12.2.  Packet Types

      +======+===============+=====================================+
      | Type | Name          | Description                         |
      +======+===============+=====================================+
      | 0    | INITIAL       | Client first flight; carries client |
      |      |               | public key, CID, optional token.    |
      +------+---------------+-------------------------------------+
      | 1    | SIN_ACK       | Server response; carries server     |
      |      |               | public key, selected version.       |
      +------+---------------+-------------------------------------+
      | 2    | CONFIRM       | Client confirmation; may carry      |
      |      |               | early 1-RTT or 0-RTT data.          |
      +------+---------------+-------------------------------------+
      | 3    | 1RTT          | Encrypted 1-RTT data (frames only). |
      +------+---------------+-------------------------------------+
      | 4    | 0RTT          | Encrypted 0-RTT data (with 0-RTT    |



Collette                 Expires 17 August 2026                [Page 15]

Internet-Draft              SIN/IP Transport               February 2026


      |      |               | keys).                              |
      +------+---------------+-------------------------------------+
      | 5    | RETRY         | Stateless retry; server sends       |
      |      |               | token, no state allocated.          |
      +------+---------------+-------------------------------------+
      | 6    | STATELESS_RST | Stateless reset; server rejects     |
      |      |               | unknown connection.                 |
      +------+---------------+-------------------------------------+
      | 7-15 | Reserved      | Reserved / GREASE.                  |
      +------+---------------+-------------------------------------+

                                 Table 3

12.3.  Client State Machine

   CLOSED -> (send INITIAL) -> INITIAL_SENT -> (recv RETRY -> resend
   INITIAL with token) -> (recv SIN_ACK) -> SIN_ACK_RCVD -> (send
   CONFIRM) -> (recv 1RTT) -> ESTABLISHED.  On timeout or invalid
   response, transition to CLOSED.

12.4.  Server State Machine

   LISTEN -> (recv INITIAL) -> INITIAL_RCVD -> (optional: send RETRY) ->
   (send SIN_ACK) -> SIN_ACK_SENT -> (recv CONFIRM) -> ESTABLISHED.  The
   server does not allocate full per-connection state until CONFIRM is
   received (see {{anti-amplification}}).

12.5.  Stateless Retry

   The server MAY respond to an INITIAL with RETRY, sending a token.
   The token MUST be integrity-protected (e.g., HMAC with server secret)
   and SHOULD bind the client address and expire (e.g., 60 seconds).
   The client MUST resend INITIAL including the token.  The server MUST
   NOT allocate full connection state until the client has echoed a
   valid token.  This limits state exhaustion and supports anti-
   amplification.

12.6.  0-RTT Data

   If the server provided a session ticket, the client MAY send 0-RTT
   data with CONFIRM.  The server MUST apply replay protection (e.g.,
   accept 0-RTT only once per ticket or within a time window).  Non-
   idempotent 0-RTT data SHOULD be treated as potentially replayed; the
   server MAY reject or delay it.







Collette                 Expires 17 August 2026                [Page 16]

Internet-Draft              SIN/IP Transport               February 2026


12.7.  Address Validation and Anti-Amplification

   Until the client has been validated (e.g., by echoing a RETRY token
   or completing the handshake), the server MUST NOT send more than *3
   times* the number of bytes it has received from that client.  That
   is, for each unvalidated client address, (bytes sent in response) <=
   3 * (bytes received from that client).  The server allocates full
   per-connection state only after receiving a valid CONFIRM.  Under
   load, the server MAY reject new INITIALs with RETRY or STATELESS_RST.

13.  Packet Protection

13.1.  Cryptographic Agility

   SIN/IP version 1 uses X25519 for key exchange, HKDF-SHA256 for key
   derivation, and either XChaCha20-Poly1305 or AES-256-GCM for AEAD.
   Future versions may define other algorithms via the version or
   transport parameters.

13.2.  Key Exchange

   The client sends its X25519 public key (32 bytes) in the INITIAL
   payload; the server sends its X25519 public key (32 bytes) in
   SIN_ACK.  Both compute the 32-byte ECDH shared secret.  Optional
   server authentication: the server may include an Ed25519 signature
   over (client_pubkey || server_pubkey); the client MUST verify it when
   server identity is required.

13.3.  Key Schedule

   The shared secret is input to HKDF-SHA256.  The info string (e.g.,
   "SINIPv1 Key Material") and output length (e.g., 56 bytes) yield:
   32-byte session key, 12-byte client send IV, 12-byte server send IV.
   The initiator uses client IV for sending and server IV for receiving;
   the responder does the opposite.

13.4.  Nonce Construction

   The nonce is 12 bytes: *nonce = IV XOR (0x00000000 || PN)* where PN
   is 32 bits big-endian in the low four bytes.  This ensures a unique
   nonce per (key, PN).  PN spaces are separate, so keys differ per
   space; key update MUST occur before PN wrap.









Collette                 Expires 17 August 2026                [Page 17]

Internet-Draft              SIN/IP Transport               February 2026


13.5.  AEAD and Associated Data

   The AEAD authenticated data (AD) is the entire 32-byte header.  The
   plaintext is the payload (frames); the ciphertext and 16-byte tag
   replace the plaintext on the wire.  Tampering with the header causes
   verification to fail.

13.6.  Key Update and Epoch Handling

   Rekeying can be triggered by bytes encrypted, time, or packet number
   window.  The KEY_PHASE bit in the header indicates the phase.  New
   keys are derived from the existing key or a new handshake.  The
   endpoint MUST trigger key update before PN wrap in a space.

13.7.  Replay Protection

   Each packet uses a distinct nonce; replay of a ciphertext is detected
   (same PN under same key).  For 0-RTT, the server MUST apply replay
   protection (e.g., one-time use per ticket or time window).

14.  Reliability and Loss Recovery

14.1.  ACK Generation

   The receiver SHOULD send an ACK for every ACK-eliciting packet.  It
   MAY coalesce ACKs within a short delay (e.g., max ack_delay).  ACK
   frames carry the largest received PN and ranges; ACK delay can be
   included for RTT estimation.

14.2.  Retransmission and PTO

   Lost data is retransmitted in *new* packets with new packet numbers.
   The sender declares a packet lost when it has been outstanding for at
   least the PTO (RTO) or when a reorder threshold (e.g., 3 later
   packets acked) is met.  RTO is computed using an RFC 6298-style
   algorithm: SRTT, RTTVAR, RTO = SRTT + 4*RTTVAR, clamped to 1-60
   seconds.  Implementations MUST use a single normative algorithm for a
   given capability version.

14.3.  Reordering, Duplicate Detection, and Thresholds

   The receiver deduplicates by (stream_id, offset) for STREAM data.
   The sender deduplicates ACKs by packet number.  A reorder threshold
   (e.g., 3 packets) avoids declaring loss too early when packets are
   reordered.  The reorder window (in packets or time) MUST be defined
   to minimize spurious retransmits.





Collette                 Expires 17 August 2026                [Page 18]

Internet-Draft              SIN/IP Transport               February 2026


15.  Flow Control

15.1.  Connection-Level Flow Control

   The receiver advertises a connection-level flow control window (total
   bytes in flight across all streams).  The sender MUST NOT send beyond
   this window.  Window updates are sent via transport parameters or
   dedicated frames.

15.2.  Stream-Level Flow Control

   Each stream has an advertised receive window.  The sender MUST NOT
   send stream data beyond the stream's window.  When the advertised
   window is zero, the sender MUST send periodic probes (e.g., PING or
   minimal STREAM) at most every T seconds (e.g., 5) so the receiver can
   send a window update.

15.3.  Stream Limits

   The maximum number of streams and the maximum stream ID are
   negotiated via transport parameters.  Exceeding the limit results in
   connection close or stream rejection.

16.  Congestion Control

16.1.  Requirements

   Implementations MUST implement a congestion controller.  The
   algorithm MUST reduce the send rate in response to loss (and to ECN
   CE when ECN is in use).  The default MAY be NewReno-like, CUBIC, or
   BBR.

16.2.  Default Congestion Controller

   This document does not mandate a single algorithm; implementations
   choose among standard algorithms (e.g., CUBIC {{?RFC8312}}, BBR).
   The choice is configurable (e.g., socket option or sysctl).

16.3.  Pacing

   Sending MUST be paced according to the congestion controller's
   allowed rate to avoid bursts.  Pacing is a normative requirement for
   capability versions that specify it (e.g., v1.1).








Collette                 Expires 17 August 2026                [Page 19]

Internet-Draft              SIN/IP Transport               February 2026


16.4.  PLPMTUD (If Supported)

   Over UDP encapsulation, endpoints MUST implement safe MTU handling:
   process ICMP Packet Too Big and reduce the effective payload size, or
   use a conservative default (e.g., 1200 bytes).  Probe-based PLPMTUD
   (e.g., RFC 4821) may be added in a future version.

17.  Path Management and Mobility

17.1.  NAT Rebinding

   Connection IDs decouple the connection from the 4-tuple.  When the
   client's address changes (e.g., new NAT binding), it continues to use
   the same dcid/scid so the server can route packets to the correct
   connection.  No change to the wire format is required.

17.2.  Connection Migration

   Before using a new path for data, the endpoint MUST complete path
   validation (PATH_CHALLENGE / PATH_RESPONSE).  Until validation
   succeeds, only PATH_CHALLENGE and PATH_RESPONSE frames MAY be sent on
   the new path.  This prevents redirect attacks.

17.3.  Path Validation Using PATH_CHALLENGE/PATH_RESPONSE

   The endpoint sends PATH_CHALLENGE with 8 random bytes.  The peer
   echoes them in PATH_RESPONSE.  Only the holder of the connection
   (with the right keys) can produce a valid response.  After validation
   succeeds, the endpoint may use the new path for 1-RTT data.

18.  Connection Termination

18.1.  Graceful Close

   Either endpoint sends a packet with the FIN flag or a
   CONNECTION_CLOSE frame.  The peer acknowledges and may send its own
   FIN.  The connection enters TIME_WAIT (see {{time-wait}}).  State
   machine: ESTABLISHED -> FIN_WAIT_1 -> FIN_WAIT_2 or CLOSING ->
   TIME_WAIT -> CLOSED.

18.2.  Stateless Reset

   The server may send STATELESS_RST (packet type 6) without looking up
   the connection.  The payload is typically an HMAC of the dcid with a
   server secret, truncated.  Only the server can generate a valid
   reset.  The client treats it as connection closed.





Collette                 Expires 17 August 2026                [Page 20]

Internet-Draft              SIN/IP Transport               February 2026


18.3.  TIME_WAIT and Reuse Rules

   The endpoint in TIME_WAIT MUST retain state for at least 2*MSL or 30
   seconds, whichever is greater.  During this time, the same (4-tuple,
   dcid) MUST NOT be reused for a new connection.  This prevents delayed
   segments from being mistaken for segments of a new connection.

19.  Middlebox Considerations

   Middleboxes that allow UDP typically allow SIN/IP over UDP.  No
   middlebox changes are required.  Use of a new IP protocol number on
   the public Internet is NOT RECOMMENDED; UDP encapsulation is the
   primary deployable mode.  NAT rebinding is handled by connection IDs
   and path validation; the 4-tuple may change without breaking the
   connection.

20.  Implementation Considerations

20.1.  Kernel Integration Considerations

   When SIN/IP is implemented in the kernel: (1) Session keys and keying
   material MUST be zeroized when the connection is destroyed or the key
   phase is retired. (2) Header and frame parsers MUST validate all
   lengths and bounds before use; invalid or truncated data MUST NOT be
   dereferenced. (3) Protocol updates may be decoupled from kernel
   release cadence (e.g., loadable module). (4) The API between kernel
   and user space MUST NOT expose raw keys or unvalidated packet data;
   only decrypted, reassembled data and metadata appropriate to the
   socket abstraction MAY be exposed.

20.2.  Resource Limits and DoS Hardening

   Implementations SHOULD enforce connection limits, rate limiting per
   address, and idle timeouts.  The amplification limit (Section 8.7)
   and state allocation rules (state only after CONFIRM) are normative.
   Under load, the server MAY send RETRY or STATELESS_RST to shed load.

20.3.  Buffering, Reassembly, and Zero-Copy

   The receiver reassembles by stream_id and offset.  Implementations
   may use scatter-gather and zero-copy (e.g., sendfile, splice) when
   the transport is in the kernel; such optimizations are
   implementation-defined.

21.  Security Considerations






Collette                 Expires 17 August 2026                [Page 21]

Internet-Draft              SIN/IP Transport               February 2026


   *  *Confidentiality and integrity:* All post-handshake traffic is
      protected with an AEAD; the header is authenticated as associated
      data.  Passive and active attackers cannot read or modify payloads
      without detection.
   *  *Replay:* Unique nonces (IV XOR PN) prevent replay. 0-RTT requires
      server-side replay protection.
   *  *Downgrade:* Version and capability are in the wire and transport
      params; implementations MUST NOT accept unsupported versions or
      fall back to weaker options.
   *  *DoS:* Amplification is limited to 3*; state is allocated only
      after client validation.  Stateless retry and STATELESS_RST allow
      the server to shed load.
   *  *Key material:* Keys MUST be zeroized when no longer needed.
      Kernel implementations MUST NOT expose keys to user space.

22.  Privacy Considerations

   SIN/IP does not intentionally expose identifiers beyond what is
   necessary for demultiplexing (connection IDs).  Connection IDs are
   opaque and may be changed (NEW_CONNECTION_ID / RETIRE_CONNECTION_ID).
   Packet numbers and timing may leak side-channel information;
   implementations should consider constant-time crypto and traffic
   analysis resistance where applicable.

23.  IANA Considerations

   *IP Protocol Number Allocation:* IANA is requested to assign an IP
   Protocol Number for "SIN/IP" in the "Protocol Numbers" registry, for
   use as IPv4 Protocol and IPv6 Next Header when SIN/IP is used in
   native mode.  The assignment is for experimental use.

   *UDP Port Allocation for Encapsulation:* IANA is requested to assign
   a UDP destination port for SIN/IP encapsulation in the "Service Name
   and Transport Protocol Port Number" registry.  Until assignment,
   implementations MAY use a configurable port (e.g., for testing).
   Suggested service name: sinip.

   *SIN/IP Version Registry:* IANA is requested to create a new registry
   "SIN/IP Versions" under "SIN/IP Parameters".  Initial allocation:












Collette                 Expires 17 August 2026                [Page 22]

Internet-Draft              SIN/IP Transport               February 2026


                  +=========+===========================+
                  | Value   | Description               |
                  +=========+===========================+
                  | 0x0     | Invalid / reserved        |
                  +---------+---------------------------+
                  | 0x1     | Version 1 (this document) |
                  +---------+---------------------------+
                  | 0x2-0xE | Unassigned                |
                  +---------+---------------------------+
                  | 0xF     | GREASE                    |
                  +---------+---------------------------+

                                  Table 4

   Allocation policy: Specification Required.

   *SIN/IP Packet Type Registry:* IANA is requested to create "SIN/IP
   Packet Types" (low 4 bits of ver_type).  Initial values: 0=INITIAL,
   1=SIN_ACK, 2=CONFIRM, 3=1RTT, 4=0RTT, 5=RETRY, 6=STATELESS_RST.
   Values 7-14 reserved; 15 GREASE.  Allocation policy: Specification
   Required.

   *SIN/IP Header Flags Registry:* IANA is requested to create "SIN/IP
   Header Flags" (8-bit bitmap).  Initial: bit 0 = ACK_ELICITING, bit 1
   = FIN, bit 2 = KEY_PHASE.  Remaining bits reserved.  Unknown flags
   MUST be ignored.  Allocation policy: Specification Required.

   *SIN/IP Frame Type Registry:* IANA is requested to create "SIN/IP
   Frame Types" (8-bit).  Initial values as in the table in Section 6.2.
   Allocation policy: Specification Required.

   *SIN/IP Transport Parameter Registry:* IANA is requested to create
   "SIN/IP Transport Parameters" (16-bit IDs).  Allocation policy:
   Specification Required.

   *SIN/IP Error Code Registry:* IANA is requested to create "SIN/IP
   Error Codes" (16-bit).  Initial values: 0x0000=NO_ERROR,
   0x0001=INTERNAL_ERROR, 0x0002=PROTOCOL_VIOLATION,
   0x0003=UNSUPPORTED_VERSION, 0x0004=IDLE_TIMEOUT,
   0x0005=INVALID_TOKEN, 0x0006=CONNECTION_REFUSED,
   0x0007=RESOURCE_EXHAUSTED, 0x0008=CRYPTO_ERROR. 0x0009-0xFFFF
   reserved.  Allocation policy: Specification Required.

24.  References







Collette                 Expires 17 August 2026                [Page 23]

Internet-Draft              SIN/IP Transport               February 2026


24.1.  Normative References

   [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/info/rfc2119 (https://www.rfc-
   editor.org/info/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/info/rfc8174 (https://www.rfc-
   editor.org/info/rfc8174).

   [RFC6298] Paxson, V., et al., "Computing TCP's Retransmission Timer",
   RFC 6298, DOI 10.17487/RFC6298, June 2011, https://www.rfc-
   editor.org/info/rfc6298 (https://www.rfc-editor.org/info/rfc6298).

24.2.  Informative References

   [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/info/rfc9000 (https://www.rfc-
   editor.org/info/rfc9000).

   [RFC3168] Ramakrishnan, K., et al., "The Addition of Explicit
   Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168,
   September 2001, https://www.rfc-editor.org/info/rfc3168
   (https://www.rfc-editor.org/info/rfc3168).

   [RFC4821] Mathis, M. and J.  Heffner, "Packetization Layer Path MTU
   Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
   https://www.rfc-editor.org/info/rfc4821 (https://www.rfc-
   editor.org/info/rfc4821).

   [RFC8312] Rhee, I., et al., "CUBIC for Fast Long-Distance Networks",
   RFC 8312, DOI 10.17487/RFC8312, February 2018, https://www.rfc-
   editor.org/info/rfc8312 (https://www.rfc-editor.org/info/rfc8312).

25.  Appendix A.  Wire Image Examples (Hex + Field Decode)

   Example: minimal INITIAL packet (32-byte header only; payload and tag
   omitted for brevity).  Header layout per Section 5.2 (big-endian).

   *  ver_type = 0x10 (version 1, type INITIAL=0)
   *  flags = 0x00
   *  hlen_words = 8
   *  reserved = 0
   *  epoch = 0x0000




Collette                 Expires 17 August 2026                [Page 24]

Internet-Draft              SIN/IP Transport               February 2026


   *  payload_len = 0x0029 (41 bytes: client pubkey 32 + CID 8 + version
      1)
   *  stream_id = 0
   *  reserved2 = 0
   *  pn = 0x00000000
   *  dcid = 0x0123456789ABCDEF (example client CID)
   *  scid = 0x0000000000000000 (zero in INITIAL)
   *  hdr_ext = 0x0000

   Hex (32 bytes): 10 00 08 00 00 00 00 29 00 00 00 00 00 00 01 23 45 67
   89 AB CD EF 00 00 00 00 00 00 00 00 00 00

   A 1RTT packet carrying encrypted payload would have ver_type = 0x13
   (version 1, type 1RTT=3), non-zero pn, and dcid/scid set to receiver/
   sender CIDs; the payload would contain TLV frames (e.g., type 1
   STREAM, length, value) followed by the 16-byte AEAD tag.

26.  Appendix B.  State Machines (Full)

   Handshake (simplified):

   *  *Client:* CLOSED -> (send INITIAL) -> INITIAL_SENT -> (recv RETRY
      -> resend INITIAL with token) -> (recv SIN_ACK) -> SIN_ACK_RCVD ->
      (send CONFIRM) -> (recv 1RTT) -> ESTABLISHED.
   *  *Server:* LISTEN -> (recv INITIAL) -> INITIAL_RCVD -> (optional:
      send RETRY) -> (send SIN_ACK) -> SIN_ACK_SENT -> (recv CONFIRM) ->
      ESTABLISHED.

   Connection close and TIME_WAIT (normative): The endpoint that
   initiates close sends a packet with the FIN flag (or CONNECTION_CLOSE
   frame) and enters FIN_WAIT_1.  When it receives an ACK for the FIN,
   it enters FIN_WAIT_2 (if it may still receive data) or CLOSING (if
   both sides have sent FIN).  When the peer's FIN is acknowledged, the
   endpoint enters TIME_WAIT.  The TIME_WAIT duration MUST be at least
   2*MSL or 30 seconds, whichever is greater; during this time the
   endpoint MUST NOT allow a new connection to reuse the same (4-tuple,
   dcid).  After TIME_WAIT expires, the connection enters CLOSED.

   Connection-close state diagram:

   ESTABLISHED
        | (application close; send FIN)
        v
   FIN_WAIT_1 ----(recv ACK for FIN)----> FIN_WAIT_2 ----(recv FIN; send ACK)----> TIME_WAIT
        |                                                                              |
        | (recv FIN; send ACK for peer FIN)                                            | (after 2*MSL or 30s)
        v                                                                              v
   CLOSING ----(recv ACK for our FIN)----> TIME_WAIT ------------------------------> CLOSED



Collette                 Expires 17 August 2026                [Page 25]

Internet-Draft              SIN/IP Transport               February 2026


27.  Appendix C.  Test Vectors (Crypto)

   X25519 key exchange, HKDF key derivation, and AEAD (e.g.,
   ChaCha20-Poly1305 or AES-256-GCM) test vectors for SIN/IP v1 are to
   be provided in a companion document or a future revision.
   Implementations should derive keys as specified in Section 9 (Key
   Schedule): shared secret from X25519 -> HKDF-SHA256 with info
   "SINIPv1 Key Material" -> 56 bytes (32-byte key, 12-byte client send
   IV, 12-byte server send IV).  Nonce = IV XOR (0x00000000 || PN) with
   PN in the low 32 bits (big-endian).  AEAD authenticated data is the
   serialized 32-byte header.

28.  Appendix D.  Design Notes (Non-Normative)

   SIN/IP is designed for environments where kernel control and
   transport evolution matter: datacenters, enterprise edges, and
   gateway deployments.  The same wire format is used for native IP and
   UDP encapsulation to simplify implementation and testing.  Connection
   IDs and path validation enable mobility without middlebox changes.
   The Bridge (gateway) component, which terminates SIN/IP and proxies
   to TCP/UDP, is specified separately and allows incremental deployment
   toward existing services.

29.  Acknowledgments

   Thanks to the reviewers and contributors who provided feedback on
   earlier versions of this document.

30.  Authors' Addresses

   {: align="left"} Rick Collette VextCODE Email: rcollet@gmail.com

31.  Building This Draft

   This draft is written in mmark (RFC-style markdown).  To produce the
   canonical .txt and .html for submission:

   *  Install mmark (https://github.com/mmarkdown/mmark
      (https://github.com/mmarkdown/mmark)) and xml2rfc
      (https://pypi.org/project/xml2rfc/ (https://pypi.org/project/
      xml2rfc/)).
   *  Run: mmark draft-collette-sinip-transport-00.md > draft-collette-
      sinip-transport-00.xml
   *  Run: ./fix-idnits-xml.sh draft-collette-sinip-transport-00.xml
      (adds date, BCP 14 refs, and ENTITY declarations so idnits passes)
   *  Run: xml2rfc draft-collette-sinip-transport-00.xml --text --html





Collette                 Expires 17 August 2026                [Page 26]

Internet-Draft              SIN/IP Transport               February 2026


   Alternatively, use the IETF draft submission tool
   (https://datatracker.ietf.org/submit/ (https://datatracker.ietf.org/
   submit/)) to upload the .md or .xml and let it generate the .txt
   output.

32.  Normative References (BCP 14)

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

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

Author's Address

   Rick Collette
   VextCODE
   Email: rcollet@gmail.com































Collette                 Expires 17 August 2026                [Page 27]
