amogh.kerigond@gmail.com

Internet IETF This document specifies a protocol extension for connectionless packet transmission, enabling forwarding devices such as routers and switches to insert per-hop arrival timestamps directly into packets during transit. The extension allows receivers and monitoring systems to reconstruct the precise timing and location of delays throughout a packet's network path, improving performance diagnostics for protocols such as UDP, ICMP, multicast, and broadcast. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79 and is intended for the IETF standards track.

Connectionless protocols such as UDP, ICMP, multicast, and broadcast are widely used for streaming, diagnostics, IoT, and control-plane functions. These packets traverse multiple network hops without explicit state; existing standards do not provide a means for intermediate devices to record their transit times. Lack of per-hop transit information impedes the ability to pinpoint delays, diagnose jitter, and perform fine-grained network analysis. This document defines a Timestamp Forwarding Option for selected packet types, enabling hop-by-hop timestamp insertion and subsequent analysis.

CPTF: Connectionless Packet Timestamp Forwarding TFO: Timestamp Forwarding Option Node Identifier: The device's unique address (IP or MAC) Timestamp: 64-bit value in milliseconds since Unix epoch

Packet delay is typically only observable at endpoints. Operators cannot precisely identify which network hop induces delay or jitter, especially for connectionless flows. Traceroute and similar active probes require custom traffic and do not reflect normal traffic conditions. IoT and real-time services are particularly affected.

CPTF introduces a header option for eligible packets. Each CPTF-capable forwarding node appends or inserts its timestamp as the packet is received or forwarded. At the destination, these timestamps reveal per-hop transit delays for individual packets.

The CPTF IPv4 Option format:

Multiple entries are appended in arrival order.

The CPTF destination option is carried in the IPv6 Destination Options header.

For UDP extensions, CPTF may be placed in the UDP payload or in an extension header.

Sender MAY initialize CPTF header and insert its timestamp. Each CPTF-capable device SHOULD check for available entry slots and insert its Node ID and current time. If all entry slots are full, no further timestamps are added. Devices MUST NOT overwrite earlier timestamps.

[Router1]---->[Router2]---->[Receiver] | | | | TS0 Insert TS1 Insert TS2 Insert Read all CPTF Option after Receiver: +---------+---------+---------+ | TS0,ID0 | TS1,ID1 | TS2,ID2 | +---------+---------+---------+ ]]>

UDP Video Streaming: Packets from a camera traverse routers, each adding CPTF info. The server can analyze delays per hop for each packet received. ICMP Diagnostics: Echo Request and Reply packets accumulate CPTF data, allowing the initiator to determine where latency/jitter occurred without special probes. IoT Mesh Broadcast: CPTF helps diagnose congested mesh segments by collecting hop timing.

CPTF fields may reveal topology and timing to observers. Usage SHOULD be limited by network policy. Entry limits and rate controls are RECOMMENDED to avoid resource exhaustion. CPTF-enabled devices MAY restrict Node ID exposure.

This memo requests assignment of: CPTF IPv4 Option Number, CPTF IPv6 Destination Option Type, CPTF UDP Extension Option Code, CPTF ICMP Extension Option Code.

RFC791: Internet Protocol RFC792: Internet Control Message Protocol RFC2460: Internet Protocol, Version 6 (IPv6) Specification RFC768: User Datagram Protocol

The author wishes to thank the networking and diagnostics communities for inspiring work that motivated CPTF.

Amoghasidd Kerigond Email: amogh.kerigond@gmail.com