



Network Working Group                                        A. Maurette
Internet-Draft                                           IUT R&T Béthune
Intended status: Experimental                           16 February 2026
Expires: 20 August 2026


     HMTFTP: HMAC-Derived TFTP with Optional AEAD Protection (v0.4)
                        draft-maurette-hmtftp-04

Abstract

   HMTFTP is a lightweight UDP file transfer protocol derived from TFTP
   that adds TLV-based negotiation and an optional AEAD protection mode
   for DATA payloads.  This version (v0.4) requests IANA actions: a
   service name and UDP port assignment (suggested: 6369/udp) and
   registries for TLV Types, OpCodes, and Ciphersuites.  Until IANA
   assigns a port, this document uses TBD1 as the default port value.

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."

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."




Maurette                 Expires 20 August 2026                 [Page 1]

Internet-Draft                 HMTFTP v0.4                 February 2026


   This Internet-Draft will expire on 20 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  Relationship to TFTP  . . . . . . . . . . . . . . . . . . . .   3
   4.  Transport . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  RRQ and WRQ . . . . . . . . . . . . . . . . . . . . . . .   4
     5.2.  OACK  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.3.  DATA and ACK  . . . . . . . . . . . . . . . . . . . . . .   4
     5.4.  ERROR . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  TLV Encoding and Processing . . . . . . . . . . . . . . . . .   5
   7.  Defined TLVs  . . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Transfer Procedure  . . . . . . . . . . . . . . . . . . . . .   8
   9.  Optional AEAD Security Mode . . . . . . . . . . . . . . . . .   8
     9.1.  Negotiation TLVs  . . . . . . . . . . . . . . . . . . . .   8
     9.2.  Key Derivation  . . . . . . . . . . . . . . . . . . . . .   8
     9.3.  Nonce Construction and AAD  . . . . . . . . . . . . . . .   9
     9.4.  Limits  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   10. Compatibility and TLV Governance  . . . . . . . . . . . . . .   9
     10.1.  Compatibility Profile  . . . . . . . . . . . . . . . . .  10
     10.2.  TLV Code Point Governance  . . . . . . . . . . . . . . .  10
   11. Implementation and Operational Guidance . . . . . . . . . . .  10
     11.1.  Timers and Retransmissions . . . . . . . . . . . . . . .  10
     11.2.  Datagram Sizing and PMTU . . . . . . . . . . . . . . . .  11
     11.3.  Resource Limits and DoS Mitigations  . . . . . . . . . .  11
   12. Port Rationale  . . . . . . . . . . . . . . . . . . . . . . .  11
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   14. Implementation Status . . . . . . . . . . . . . . . . . . . .  12
   15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     15.1.  Service Name and UDP Port  . . . . . . . . . . . . . . .  12
     15.2.  HMTFTP TLV Types Registry  . . . . . . . . . . . . . . .  12
     15.3.  HMTFTP OpCodes Registry  . . . . . . . . . . . . . . . .  13
     15.4.  HMTFTP Ciphersuites Registry . . . . . . . . . . . . . .  14
   16. Normative References  . . . . . . . . . . . . . . . . . . . .  14



Maurette                 Expires 20 August 2026                 [Page 2]

Internet-Draft                 HMTFTP v0.4                 February 2026


   17. Informative References  . . . . . . . . . . . . . . . . . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   The Trivial File Transfer Protocol (TFTP) [RFC1350] is extremely
   simple but provides no built-in security properties.  HMTFTP retains
   the TFTP operational model (UDP, numbered blocks, ACKs) while
   introducing (1) a compact TLV extension mechanism and (2) an optional
   AEAD protection mode for DATA payloads.

   The name "HMTFTP" reflects that cryptographic keys are derived using
   HKDF, a HMAC-based key derivation function [RFC5869].  Version v0.4
   adds IANA considerations for a service name and UDP port assignment
   and establishes registries for TLV Types and ciphersuites.

2.  Conventions and Terminology

   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 BCP 14 ([RFC2119] and
   [RFC8174]) when, and only when, they appear in all capitals.

   This document uses the following terms:

   *PSK*  pre-shared key

   *AEAD*  authenticated encryption with associated data

   *AAD*  additional authenticated data

3.  Relationship to TFTP

   HMTFTP is derived from TFTP [RFC1350] and reuses the core message
   types and semantics (RRQ, WRQ, DATA, ACK, ERROR).  It also reuses the
   concept of an explicit option acknowledgment, OACK, as introduced by
   TFTP option extension [RFC2347].  HMTFTP replaces the key/value
   option encoding of RFC 2347 with a TLV encoding defined in this
   document.

   HMTFTP differs from baseline TFTP primarily by:

   *  using UDP port TBD1 by default (configurable), rather than 69;

   *  allowing TLV extensions in RRQ, WRQ, and OACK;

   *  supporting an optional AEAD security mode for DATA payloads.




Maurette                 Expires 20 August 2026                 [Page 3]

Internet-Draft                 HMTFTP v0.4                 February 2026


4.  Transport

   HMTFTP runs over UDP.  The default server port is TBD1, but
   implementations MUST allow the port to be configured.

   As in TFTP, a transfer is conducted between a client and a server
   transfer address (IP, UDP port).  The server MAY respond from a
   different UDP port than TBD1 for the remainder of the transfer, as
   described in [RFC1350].

5.  Message Formats

   All multi-octet fields are encoded in network byte order (big-
   endian).  HMTFTP reuses the TFTP base message formats, with TLVs
   appended to RRQ, WRQ, and OACK.  TLVs are not used in DATA, ACK, or
   ERROR in this version.

5.1.  RRQ and WRQ

   RRQ and WRQ are defined as in [RFC1350]:

   *RRQ/WRQ* = OpCode (2) || Filename (N) || 0 || Mode (M) || 0 ||
   [TLVs]

   The optional TLV sequence, when present, begins immediately after the
   terminating zero octet of the Mode field and continues to the end of
   the UDP datagram.  The Mode is a NUL-terminated ASCII string (e.g.,
   "octet").

5.2.  OACK

   OACK is used by the server to acknowledge and/or modify the TLVs
   offered in RRQ/WRQ.  OACK is defined by [RFC2347] as OpCode value 6.
   In HMTFTP, OACK contains only a TLV sequence:

   *OACK* = OpCode (2) || TLVs

   An OACK with an empty TLV sequence indicates acceptance with no
   negotiated parameters.

5.3.  DATA and ACK

   DATA and ACK are as defined in [RFC1350]:

   *DATA* = OpCode (2) || Block (2) || Payload (0..n)

   *ACK* = OpCode (2) || Block (2)




Maurette                 Expires 20 August 2026                 [Page 4]

Internet-Draft                 HMTFTP v0.4                 February 2026


   When AEAD protection is negotiated (Section 9), the DATA Payload is
   structured as: Ciphertext || Tag, where Tag is a 16-octet AES-GCM
   authentication tag.  The ciphertext length is the datagram length
   minus 4 octets of header and minus 16 octets of tag.

5.4.  ERROR

   ERROR is as defined in [RFC1350]:

   *ERROR* = OpCode (2) || ErrorCode (2) || ErrMsg (string) || 0

   HMTFTP endpoints SHOULD use an ERROR with ErrorCode 0 ("Not defined")
   for extension processing failures (e.g., unsupported critical TLV).

6.  TLV Encoding and Processing

   HMTFTP TLVs extend RRQ, WRQ, and OACK.  TLVs use a compact binary
   encoding:

        +========+==========+====================================+
        | Field  | Size     | Description                        |
        +========+==========+====================================+
        | Type   | 16 bits  | Type code with Critical bit in MSB |
        +--------+----------+------------------------------------+
        | Length | 16 bits  | Length of Value in octets          |
        +--------+----------+------------------------------------+
        | Value  | variable | Type-specific data                 |
        +--------+----------+------------------------------------+

                           Table 1: TLV Format

   The most significant bit (MSB) of the Type field is the _Critical_
   bit.  Bits 0-14 form the 15-bit TLV code.  The Critical bit is not
   part of the code space recorded by IANA (see Section 15.2).

   Processing rules:

   *  A receiver MUST ignore unknown TLVs with Critical=0.

   *  A receiver that encounters an unknown TLV with Critical=1 MUST
      reject the message by sending an ERROR (and MUST NOT proceed with
      the transfer).

   *  A receiver MAY accept known TLVs in any order.  If a TLV appears
      multiple times, a receiver SHOULD treat this as an error unless
      the TLV definition explicitly allows repetition.





Maurette                 Expires 20 August 2026                 [Page 5]

Internet-Draft                 HMTFTP v0.4                 February 2026


7.  Defined TLVs

   This specification defines the following TLVs.  All multi-octet
   values are encoded in network byte order (big-endian).















































Maurette                 Expires 20 August 2026                 [Page 6]

Internet-Draft                 HMTFTP v0.4                 February 2026


   +========+=========+========+=======================================+
   | Code   | Name    | Length | Description                           |
   +========+=========+========+=======================================+
   | 0x0001 | BLKSIZE | 2      | Requested maximum DATA payload size   |
   |        |         |        | in octets (uint16).  If offered by a  |
   |        |         |        | client, the server MUST respond with  |
   |        |         |        | BLKSIZE in OACK with the selected     |
   |        |         |        | value, which MUST be less than or     |
   |        |         |        | equal to the requested value.         |
   +--------+---------+--------+---------------------------------------+
   | 0x0002 | TIMEOUT | 2      | Requested retransmission timeout in   |
   |        |         |        | seconds (uint16).  If offered by a    |
   |        |         |        | client, the server MUST respond with  |
   |        |         |        | TIMEOUT in OACK with the selected     |
   |        |         |        | value or reject the request.          |
   +--------+---------+--------+---------------------------------------+
   | 0x0003 | TSIZE   | 8      | Transfer size in octets (uint64).     |
   |        |         |        | In RRQ, a client MAY send TSIZE=0 to  |
   |        |         |        | request that the server return the    |
   |        |         |        | size.  In WRQ, a client SHOULD send   |
   |        |         |        | TSIZE with the size if known.         |
   +--------+---------+--------+---------------------------------------+
   | 0x0010 | ENC_REQ | 0      | Request to enable AEAD protection     |
   |        |         |        | for DATA payloads (empty value).      |
   |        |         |        | Clients that require security mode    |
   |        |         |        | MUST set the Critical bit on          |
   |        |         |        | ENC_REQ.  Servers that accept         |
   |        |         |        | security mode MUST echo ENC_REQ in    |
   |        |         |        | OACK.                                 |
   +--------+---------+--------+---------------------------------------+
   | 0x0011 | CIPHER  | 2      | Select ciphersuite (uint16).  If      |
   |        |         |        | omitted, the default ciphersuite is   |
   |        |         |        | 0x0001 (AES-256-GCM).                 |
   +--------+---------+--------+---------------------------------------+
   | 0x0012 | CNONCE  | 16     | Client nonce (16 octets) generated    |
   |        |         |        | by a CSPRNG.  CNONCE MUST be present  |
   |        |         |        | in RRQ/WRQ when ENC_REQ is present.   |
   +--------+---------+--------+---------------------------------------+
   | 0x0013 | SNONCE  | 16     | Server nonce (16 octets) generated    |
   |        |         |        | by a CSPRNG.  SNONCE MUST be present  |
   |        |         |        | in OACK when ENC_REQ is accepted.     |
   +--------+---------+--------+---------------------------------------+

                           Table 2: Defined TLVs

   The ciphersuite value 0x0001 corresponds to AEAD AES-256-GCM.





Maurette                 Expires 20 August 2026                 [Page 7]

Internet-Draft                 HMTFTP v0.4                 February 2026


8.  Transfer Procedure

   HMTFTP uses the following procedure, aligned with TFTP option
   negotiation [RFC2347]:

   1.  The client sends RRQ or WRQ, optionally with TLVs.

   2.  If the server accepts the request and any offered parameters, it
       replies with OACK containing the negotiated TLVs (which MAY be
       empty).  If the server does not support a critical TLV or rejects
       parameters, it replies with ERROR.

   3.  For RRQ: the client sends ACK(0) after receiving OACK, then the
       server starts with DATA(1).

   4.  For WRQ: the client starts with DATA(1) after receiving OACK, and
       the server acknowledges each block with ACK(n).

   Apart from the OACK exchange, block numbering, retransmissions, and
   EOF signaling follow [RFC1350].

9.  Optional AEAD Security Mode

   Security mode is negotiated using TLVs in RRQ/WRQ and OACK.  When
   enabled, each DATA payload is protected with AEAD AES-256-GCM
   [RFC5116].  The AEAD key and IV base are derived using HKDF-SHA-256
   [RFC5869].

9.1.  Negotiation TLVs

   The client requests security mode by including TLV ENC_REQ in RRQ/
   WRQ.  When ENC_REQ is present, the client MUST include CNONCE and MAY
   include CIPHER.  If the server accepts, it includes ENC_REQ and
   SNONCE in OACK and MAY include (or echo) CIPHER.  If the server does
   not support security mode, it MUST reject a Critical ENC_REQ with
   ERROR.

9.2.  Key Derivation

   This document assumes an externally provisioned PSK (32 octets
   RECOMMENDED).  During negotiation, the client and server exchange
   nonces: CNONCE and SNONCE, each 16 octets from a CSPRNG.

   The AEAD key material is derived as follows:

   *  IKM = PSK

   *  salt = CNONCE || SNONCE (32 octets)



Maurette                 Expires 20 August 2026                 [Page 8]

Internet-Draft                 HMTFTP v0.4                 February 2026


   *  info = "hmtftp keys v1"

   *  OKM = HKDF-SHA-256(IKM, salt, info, 44)

   *  key = OKM[0..31] (32 octets)

   *  iv_base = OKM[32..43] (12 octets)

   The HKDF "info" string is a protocol constant.  Implementations MUST
   use the exact value "hmtftp keys v1" to ensure interoperability
   across document revisions.

9.3.  Nonce Construction and AAD

   The AES-GCM nonce (12 octets) for DATA block number _n_ is:

   nonce = iv_base[0..7] || uint32(n)

   where uint32(n) is the 32-bit big-endian encoding of the DATA block
   number (n is the 16-bit Block field widened to 32 bits).

   The AEAD AAD is the 4-octet DATA header (OpCode || Block).  RRQ/WRQ/
   OACK metadata and TLVs are not encrypted and are not included in the
   DATA AAD in v0.4.

   Retransmissions MUST retransmit the exact same ciphertext and tag for
   a given block number (key, nonce).

9.4.  Limits

   To avoid nonce reuse, endpoints MUST NOT allow the 16-bit block
   number to wrap within a security context.  Implementations SHOULD
   terminate a transfer with ERROR well before wrap if it would be
   reached.

10.  Compatibility and TLV Governance

   This section clarifies how HMTFTP remains interoperable with the
   operational model of TFTP while enabling extensions through TLVs.  It
   also specifies governance rules intended to keep extensions safe,
   deterministic, and implementable on constrained devices.










Maurette                 Expires 20 August 2026                 [Page 9]

Internet-Draft                 HMTFTP v0.4                 February 2026


10.1.  Compatibility Profile

   HMTFTP reuses the TFTP message types (RRQ, WRQ, DATA, ACK, ERROR) and
   the OACK concept from the TFTP option extension.  Implementations
   MUST follow the state machine of TFTP for block numbering,
   retransmissions, and EOF detection, except where explicitly modified
   by this document.

   When a peer does not send or accept TLVs, endpoints MUST fall back to
   baseline TFTP behavior as described in [RFC1350] and MUST NOT assume
   that security mode is available.  A client that requires security
   mode MUST mark ENC_REQ as Critical so that servers that do not
   support it reject the request rather than silently downgrading.

10.2.  TLV Code Point Governance

   The TLV Type field is 16 bits on the wire.  The most significant bit
   is the Critical bit; the remaining 15 bits are the TLV Code.  New
   TLVs MUST be specified with clear semantics, encoding, processing
   rules, and interoperability expectations.

   To reduce collision risks, this document reserves the TLV Code range
   0x7F00-0x7FFF for Private Use. Implementations MAY use Private Use
   TLVs in controlled environments, but such TLVs MUST NOT be used as
   inputs to cryptographic processing and MUST be ignored by receivers
   unless explicitly configured.

   Unknown TLVs with Critical=0 MUST be ignored.  Unknown TLVs with
   Critical=1 MUST cause the request to be rejected with ERROR.  This
   rule is the primary downgrade and interoperability safety mechanism
   for this specification.

11.  Implementation and Operational Guidance

   This section provides implementer-oriented guidance intended to make
   independent implementations converge on compatible behavior,
   especially under loss, reordering, and constrained-device conditions.

11.1.  Timers and Retransmissions

   Endpoints SHOULD use a configurable retransmission timeout (RTO) and
   exponential backoff, consistent with TFTP practice.  A TIMEOUT TLV
   (if supported) negotiates the initial RTO.  Implementations SHOULD
   cap the maximum number of retransmissions to bound resource usage.

   When security mode is enabled, retransmissions MUST retransmit the
   exact same ciphertext and tag for a given block number, as required
   to avoid nonce reuse hazards.



Maurette                 Expires 20 August 2026                [Page 10]

Internet-Draft                 HMTFTP v0.4                 February 2026


11.2.  Datagram Sizing and PMTU

   Implementations SHOULD avoid IP fragmentation by selecting BLKSIZE so
   that the resulting UDP datagram fits within the path MTU.  Guidance
   in [RFC8085] applies.  If fragmentation or ICMP Packet Too Big
   indications are observed, senders SHOULD reduce BLKSIZE.

11.3.  Resource Limits and DoS Mitigations

   Servers SHOULD bound work performed before establishing that the
   client is on-path (e.g., avoid large responses to unauthenticated
   requests), apply rate-limiting, and cap concurrent transfers.  In
   untrusted networks, a cookie or address-validation mechanism may be
   needed in a future version.

12.  Port Rationale

   HMTFTP is designed for managed environments where provisioning and
   update traffic is common, but it intentionally avoids using the
   legacy TFTP well-known port (69/udp) to reduce operational ambiguity
   and accidental cross-protocol interactions.

   This document suggests 6369/udp as a candidate default port because
   it is close to the historical TFTP port and is memorable for
   operators.  The port remains configurable and deployments MAY choose
   a different port when required by local policy.

13.  Security Considerations

   Without security mode, HMTFTP provides no confidentiality or
   integrity beyond UDP checksums and is vulnerable to on-path
   modification and spoofing, as with TFTP [RFC1350].

   With security mode enabled, only DATA payloads are encrypted and
   authenticated.  RRQ/WRQ/OACK metadata and TLVs remain in cleartext.
   This means filenames, modes, and negotiated parameters are observable
   on the wire.  Deployments that require metadata confidentiality MUST
   avoid placing sensitive data in RRQ/WRQ/OACK and SHOULD use an
   external secure channel or a future extension that encrypts metadata.

   Nonce reuse with AES-GCM is catastrophic.  Implementations MUST
   enforce nonce uniqueness and MUST follow the nonce construction and
   wrap limits described in Section 9.

   Implementations should also consider UDP robustness guidelines
   ([RFC8085]) and rate-limiting to mitigate amplification and resource-
   exhaustion attacks.




Maurette                 Expires 20 August 2026                [Page 11]

Internet-Draft                 HMTFTP v0.4                 February 2026


14.  Implementation Status

   This section is provided for RFC 7942 compliance ([RFC7942]).

   Implementations, interop notes, and known limitations will be added
   in subsequent versions.

15.  IANA Considerations

15.1.  Service Name and UDP Port

   IANA is requested to assign a service name and UDP port with the
   following values in the "Service Name and Transport Protocol Port
   Number Registry" ([RFC6335]).  This document suggests 6369/udp as the
   requested port number.  Until assignment, this document uses TBD1 as
   the default port value.

    +==============+====================+=============+===============+
    | Service Name | Transport Protocol | Port Number | Reference     |
    +==============+====================+=============+===============+
    | hmtftp       | udp                | TBD1        | This document |
    +--------------+--------------------+-------------+---------------+

                   Table 3: HMTFTP Service Name and Port

15.2.  HMTFTP TLV Types Registry

   IANA is requested to create a registry titled "HMTFTP TLV Types".
   The registry is for 15-bit TLV codes (0x0000-0x7FFF).  The Critical
   bit (MSB of the 16-bit Type field on the wire) is not part of the
   registry.

   The TLV Code range 0x7F00-0x7FFF is reserved for Private Use. Private
   Use TLVs MUST be ignored by receivers unless explicitly configured
   and MUST NOT be used as inputs to cryptographic processing.

   Registration policy: Expert Review ([RFC8126]).

   The registry records: TLV Code, Name, Description, and Reference.












Maurette                 Expires 20 August 2026                [Page 12]

Internet-Draft                 HMTFTP v0.4                 February 2026


   +========+==========+===============================+===============+
   | Code   | Name     | Description                   | Reference     |
   +========+==========+===============================+===============+
   | 0x0000 | Reserved | Reserved for future use       | This document |
   +--------+----------+-------------------------------+---------------+
   | 0x0001 | BLKSIZE  | Block size in octets          | This document |
   |        |          | (uint16)                      |               |
   +--------+----------+-------------------------------+---------------+
   | 0x0002 | TIMEOUT  | Retransmission timeout        | This document |
   |        |          | in seconds (uint16)           |               |
   +--------+----------+-------------------------------+---------------+
   | 0x0003 | TSIZE    | Transfer size in octets       | This document |
   |        |          | (uint64)                      |               |
   +--------+----------+-------------------------------+---------------+
   | 0x0010 | ENC_REQ  | Request AEAD protection       | This document |
   |        |          | (empty value)                 |               |
   +--------+----------+-------------------------------+---------------+
   | 0x0011 | CIPHER   | Select ciphersuite            | This document |
   |        |          | (uint16)                      |               |
   +--------+----------+-------------------------------+---------------+
   | 0x0012 | CNONCE   | Client nonce (16              | This document |
   |        |          | octets)                       |               |
   +--------+----------+-------------------------------+---------------+
   | 0x0013 | SNONCE   | Server nonce (16              | This document |
   |        |          | octets)                       |               |
   +--------+----------+-------------------------------+---------------+

                   Table 4: Initial TLV Registry Entries

   Note: BLKSIZE/TIMEOUT/TSIZE are conceptually similar to the options
   in [RFC2348] and [RFC2349], but use TLV encoding rather than ASCII
   key/value pairs.

15.3.  HMTFTP OpCodes Registry

   IANA is requested to create a registry titled "HMTFTP OpCodes".
   Registration policy: Expert Review ([RFC8126]).  The registry records
   the OpCode value, name, and reference.













Maurette                 Expires 20 August 2026                [Page 13]

Internet-Draft                 HMTFTP v0.4                 February 2026


                       +=======+=======+===========+
                       | Value | Name  | Reference |
                       +=======+=======+===========+
                       | 1     | RRQ   | RFC1350   |
                       +-------+-------+-----------+
                       | 2     | WRQ   | RFC1350   |
                       +-------+-------+-----------+
                       | 3     | DATA  | RFC1350   |
                       +-------+-------+-----------+
                       | 4     | ACK   | RFC1350   |
                       +-------+-------+-----------+
                       | 5     | ERROR | RFC1350   |
                       +-------+-------+-----------+
                       | 6     | OACK  | RFC2347   |
                       +-------+-------+-----------+

                          Table 5: Initial OpCode
                              Registry Entries

15.4.  HMTFTP Ciphersuites Registry

   IANA is requested to create a registry titled "HMTFTP Ciphersuites".
   Registration policy: Expert Review ([RFC8126]).  The registry records
   the ciphersuite value, name, description, and reference.

    +========+=============+=========================+===============+
    | Value  | Name        | Description             | Reference     |
    +========+=============+=========================+===============+
    | 0x0000 | Reserved    | Reserved for future use | This document |
    +--------+-------------+-------------------------+---------------+
    | 0x0001 | AES-256-GCM | AEAD AES-256-GCM        | This document |
    +--------+-------------+-------------------------+---------------+

              Table 6: Initial Ciphersuite Registry Entries

16.  Normative References

   [RFC1350]  Sollins, K., "The TFTP Protocol (Revision 2)", RFC 1350,
              July 1992, <https://www.rfc-editor.org/rfc/rfc1350>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, 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, May 2017,
              <https://www.rfc-editor.org/rfc/rfc8174>.




Maurette                 Expires 20 August 2026                [Page 14]

Internet-Draft                 HMTFTP v0.4                 February 2026


   [RFC2347]  Malkin, G., "TFTP Option Extension", RFC 2347, May 1998,
              <https://www.rfc-editor.org/rfc/rfc2347>.

   [RFC2348]  Malkin, G., "TFTP Blocksize Option", RFC 2348, May 1998,
              <https://www.rfc-editor.org/rfc/rfc2348>.

   [RFC2349]  Malkin, G., "TFTP Timeout Interval and Transfer Size
              Options", RFC 2349, May 1998,
              <https://www.rfc-editor.org/rfc/rfc2349>.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, January 2008,
              <https://www.rfc-editor.org/rfc/rfc5116>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869, May 2010,
              <https://www.rfc-editor.org/rfc/rfc5869>.

   [RFC6335]  Cotton, M., Leiba, B., and T. Narten, "Internet Assigned
              Numbers Authority (IANA) Procedures for the Management of
              the Service Name and Transport Protocol Port Number
              Registry", RFC 6335, August 2011,
              <https://www.rfc-editor.org/rfc/rfc6335>.

   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
              Guidelines", RFC 8085, March 2017,
              <https://www.rfc-editor.org/rfc/rfc8085>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, June 2017,
              <https://www.rfc-editor.org/rfc/rfc8126>.

17.  Informative References

   [RFC7942]  Bormann, C., "Improving Awareness of Running Code: The
              Implementation Status Section", RFC 7942, July 2016,
              <https://www.rfc-editor.org/rfc/rfc7942>.

Author's Address

   A. Maurette
   IUT R&T Béthune
   France
   Email: contact@c4tz.fr






Maurette                 Expires 20 August 2026                [Page 15]
