| Internet-Draft | CPTF | September 2025 |
| Kerigond | Expires 22 March 2026 | [Page] |
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.¶
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 22 March 2026.¶
Copyright (c) 2025 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.¶
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:¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Entries (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node ID (4 bytes, optional) | Timestamp (8 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple entries are appended in arrival order.¶
The CPTF destination option is carried in the IPv6 Destination Options header.¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Data Len | Entries (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node ID (16 bytes, optional) | Timestamp (8 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For UDP extensions, CPTF may be placed in the UDP payload or in an extension header.¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Entry Count | Entries ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node ID (4 or 16 bytes) | Timestamp (8 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
[Sender]---->[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¶