Zusammenfassung

  • RFC 10030 kapselt NTP-Nachrichten im Client-Server- und symmetrischen Modus in unicast PTP Event Messages, damit PTP-spezifische NIC-Zeitstempel und passende Transparent-Clock-Korrekturen verfügbar werden.
  • Die Transporthilfe übernimmt keine Entscheidungshoheit: Korrekturen sind nicht authentisierbar, negative Ergebnisse werden verworfen, Root Delay bleibt unverändert und NTP wählt seine Quellen weiterhin selbst.

Der Engpass sitzt in der Netzwerkkarte

Viele NICs können nicht jedes empfangene Paket bei voller Leitungsgeschwindigkeit mit einem Hardwarezeitstempel versehen. Ein Filter beschränkt die Funktion deshalb auf PTP, teils sogar auf bestimmte Transporte, Nachrichtentypen oder Ports. Gewöhnliches NTP über UDP 123 erreicht den Zeitstempel dann erst nach Software- und Warteschlangeneinflüssen.

RFC 10030 definiert einen Behälter statt eines Ersatzprotokolls. Die NTP-Nachricht liegt in einem organisationsspezifischen TLV innerhalb einer unicast PTP Event Message. Client-, Server- und symmetrischer Modus sind erfasst; NTP Broadcast nicht. Unter IANAs OUI 00-00-5E steht Subtype 0x1 für Network Time Protocol Message.

Eine über PTP empfangene Anfrage muss über denselben Transport beantwortet werden. Die Antwort darf nicht länger sein als die Anfrage, um Verstärkung zu verhindern. Der Client kann vorsorglich auffüllen. Für Synchronisationsantworten empfiehlt der RFC gleiche Längen, weil unterschiedliche Paketgrößen auf unvollständig PTP-fähigen Pfaden asymmetrische Verzögerungen erzeugen können.

Der RFC Editor kündigte den Proposed Standard am 14. August 2026 an. Autor ist Miroslav Lichvar; Grundlage war Revision 08 der Arbeitsgruppe Network Time Protocols.

Port 319 ist ein Tauschgeschäft

Bei UDP sollen Quell- und Zielport dem PTP Event Port 319 entsprechen. So trifft der Hardwarefilter. Die Kehrseite: Zufällige NTP-Quellports nach RFC 9109 passen nicht mehr zu einem Filter, der ausschließlich 319 erkennt.

Network Time Security bleibt für die innere NTP-Nachricht anwendbar. Es authentisiert jedoch nicht automatisch den äußeren PTP-Header. Der Betreiber gewinnt eine genauere Messstelle und verändert zugleich die Portexposition. Beides gehört in dieselbe Risikobewertung.

PTP 2.1 verlangt außerdem die Prüfung von domainNumber und sdoId. Empfohlen sind zunächst 123 und 0; bei Konflikten ist eine andere Domain möglich. Alle Kommunikationspartner müssen dasselbe Paar verwenden.

Eine passende Domain ordnet ein Paket dem vorgesehenen Geltungsbereich zu. Sie bestätigt weder die Richtigkeit der entfernten Uhr noch deren Vorrang vor anderen NTP-Quellen.

Eine Korrektur ohne Herkunftsnachweis

One-step E2E Transparent Clocks tragen ihre Weiterleitungsverzögerung in das PTP correction field ein. Für die NTP-Berechnung braucht der Client beide Richtungen. Die Antwort enthält ihre Korrektur im PTP-Header; die Korrektur der Anfrage kommt im neuen NTP Network Correction Extension Field vom Typ 0x010A zurück.

Der Server muss einen vom Client gelieferten Korrekturwert ignorieren. Die Anfrage sollte null enthalten. Mit beiden Werten kann der Client Peer Delay und Offset korrigieren und dabei Empfangsdauer sowie eine angenommene Frequenzabweichung der transparenten Taktgeber berücksichtigen.

Die Ablehnungsregeln sind entscheidend. Sind korrigierte Verzögerung, Anfragekorrektur oder Antwortkorrektur negativ, darf das Ergebnis nicht synchronisieren. Root Delay darf nicht angepasst werden; dadurch bleibt Root Distance als maximale angenommene Abweichung unabhängig von Netzkorrekturen.

PTP-Korrekturen lassen sich nicht authentisieren. Ein Angreifer auf dem Pfad kann das Feld verändern. Akzeptiert werden nur Korrekturen unterhalb der gemessenen Verzögerung. Der RFC vergleicht den Restangriff mit dem Verzögern einer unveränderten NTP-Nachricht. Das ist eine Begrenzung, keine Signatur.

Die Quelle wählt weiterhin der Client

NTP vergleicht mehrere Server, filtert Messungen, erkennt ausgefallene Quellen und führt die lokale Uhr. Der PTP-Transport verbessert den Ort mancher Zeitstempel und liefert zusätzliche Pfadinformation. Er verschiebt diese Auswahl nicht in Switches oder NICs.

Ein Host kann in einer Domain direkt per PTP synchronisieren und in einer anderen lediglich NTP transportieren. Weitere PTP-Uhren sind für den Transport nicht zwingend. Gibt es kompatible transparente Taktgeber, können ihre Korrekturen einfließen; andernfalls bleibt der NIC-Zeitstempel als Nutzen.

Das ist eine schmale Anfangsspezifikation: genug gemeinsame Regeln für Interoperabilität, aber kein Zwang, funktionierenden NTP-Code und seine Entscheidungslogik zu ersetzen. Adoption bleibt eine lokale, freiwillige Betriebsentscheidung.

Quellen