الخلاصة

  • يغلّف RFC 10030 رسائل NTP في نمطي العميل/الخادم والنمط المتناظر داخل رسائل حدث PTP أحادية الوجهة، ليستفيد NTP من طوابع NIC التي تتعرف على PTP ومن تصحيحات الساعات الشفافة المتوافقة.
  • لا تصبح التصحيحات مصدراً للسلطة: لا يمكن توثيقها، وتُرفض النتائج السالبة، ولا يتغير root delay، فيما يحتفظ NTP باختيار المصادر وNTS وحساب الخطأ.

المشكلة في مرشح العتاد

لا تستطيع بعض بطاقات الشبكة وضع طابع عتادي لكل إطار يصل بسرعة الوصلة. لذلك يختار المرشح حزمة محدودة من رسائل PTP، أحياناً بحسب النقل أو نوع الرسالة أو المنفذ. وقد تمر رسالة NTP العادية على UDP 123 عبر البرمجيات والطوابير قبل تسجيل وقتها.

لا يستبدل RFC 10030 بروتوكولاً بآخر. بل يضع رسالة NTP في TLV خاص بمؤسسة، ثم يحملها داخل رسالة حدث PTP أحادية الوجهة. يشمل ذلك العميل والخادم والنمط المتناظر، ولا يشمل بث NTP. وسجلت IANA النوع الفرعي 0x1 باسم Network Time Protocol Message تحت OUI 00-00-5E.

إذا وصل الطلب عبر هذا النقل، وجب أن يعود الرد عبره أيضاً. ولا يجوز أن يكون الرد أطول من الطلب حتى لا تنشأ مضاعفة لحجم الحركة. يستطيع العميل إضافة padding إذا توقع رداً أكبر. أما ردود المزامنة فيُستحسن أن تساوي الطلب حجماً لتقليل التأخير غير المتناظر على مسار لا يدعم PTP كاملاً.

أعلن RFC Editor الوثيقة في 14 أغسطس 2026 بوصفها Proposed Standard. مؤلفها Miroslav Lichvar، وكان الإصدار 08 هو المسودة الأخيرة لعمل مجموعة Network Time Protocols.

المنفذ 319 مقابل العشوائية

عند استخدام UDP، يوصي النص بأن يكون منفذا المصدر والوجهة هما منفذ أحداث PTP رقم 319. عندئذ يطابق مرشح NIC الرسالة ويولد طابع الاستقبال. لكن عشوائية منفذ المصدر في RFC 9109 لا تنسجم مع مرشح لا يرى إلا 319.

تستمر Network Time Security في حماية رسالة NTP الداخلية، لكنها لا توثق تلقائياً رأس PTP الخارجي. يحصل المشغل على نقطة قياس أدق ويقبل في المقابل تعرضاً مختلفاً للمنفذ؛ ولا يجوز اختزال الصفقة في شعار «أكثر أماناً».

في PTP 2.1 يجب التحقق من domainNumber وsdoId. القيمتان الموصى بهما افتراضياً هما 123 و0، ويمكن تغيير المجال عند التعارض، بشرط أن يشترك جميع المتخاطبين في الزوج نفسه.

يثبت المجال أن الرسالة ضمن النطاق المتوقع، ولا يثبت صحة الساعة البعيدة ولا أولويتها بين مصادر NTP.

تصحيح محدود بلا توقيع

تضيف الساعات الشفافة one-step E2E زمن العبور إلى correction field في رسالة PTP. يحتاج عميل NTP إلى الاتجاهين. يحمل الرد تصحيحه في رأس PTP، ويعيد الخادم تصحيح الطلب في حقل NTP جديد اسمه Network Correction من النوع 0x010A.

يجب أن يتجاهل الخادم أي قيمة تصحيح يضعها الطالب، وينبغي أن يرسل العميل صفراً. بعد جمع القيمتين يمكن تعديل peer delay وoffset مع حساب مدة استقبال الحزمة وهامش خطأ تردد الساعات الشفافة.

لكن قواعد الرفض تحكم النتيجة. إذا كان التأخير المصحح أو تصحيح الطلب أو الرد سالباً، فلا تُستخدم العينة للمزامنة. ولا يجوز تصحيح root delay، ليبقى root distance تقديراً للخطأ الأقصى مستقلاً عن تصحيحات الشبكة.

لا يمكن توثيق تصحيحات PTP. يستطيع مهاجم على المسار تعديل الحقل. يقبل العميل فقط تصحيحاً أصغر من التأخير المقاس، ويقارن RFC الأثر المتبقي بتأخير رسالة NTP لم تُعدّل. هذا حد للقوة، وليس إثباتاً للمصدر.

القرار يبقى عند العميل

يقارن NTP عدة خوادم، ويرشح العينات، ويستبعد المصادر المعطلة، ويضبط الساعة المحلية. يقرّب نقل PTP موضع الطابع من السلك ويضيف دليلاً عن المسار، لكنه لا ينقل اختيار المصدر إلى NIC أو المبدّل.

يمكن للمضيف أن يتزامن مباشرة عبر PTP في مجال، ويستخدم مجالاً آخر لنقل NTP فقط. ولا يشترط وجود ساعات PTP أخرى في الطريق. إن وُجدت ساعات شفافة متوافقة استُخدمت تصحيحاتها، وإلا ظل الطابع العتادي مفيداً.

هذه مواصفة أولية رقيقة: قواعد كافية للتشغيل البيني من دون إعادة كتابة منطق NTP العامل. يتبناها كل مشغل طوعاً حيث يبرر العتاد والمخاطر ذلك، وتبقى أداة القياس أداة لا صاحب قرار.

المصادر