الخلاصة

  • يختار التطبيق group ID عشوائياً، ويشتق عنواني IPv6 وEthernet، ثم يعلن حقه في عنوان الطبقة الثانية بسجل PTR عبر mDNS تحت .eth-addr.arpa.
  • يستطيع جهاز الشبكة إضافة -veto إلى أول label للتطبيق؛ فيفوز السجل دائماً في مقارنة mDNS ويجبر الطرف الخاسر على إيقاف البث والاختيار من جديد.
  • النسخة 12 ما زالت Internet-Draft في مرحلة Last Call، وطلبات IANA لم تُعتمد بعد، كما أن رسائل التعارض والنقض لا تحمل إثبات هوية ناشرها.

يفترض mDNS أن المشاركين يتعاونون. هذه الجملة القصيرة هي الحد السياسي والأمني للمقترح كله.

نُشرت النسخة 12 من draft-ietf-pim-ipv6-zeroconf-assignment في 22 سبتمبر 2026، ويستمر Last Call حتى 6 أكتوبر. تطلب الوثيقة من IANA نطاق 0x90000000-0x9FFFFFFF والاسم eth-addr.arpa ونطاق الاستخدام الخاص 9.3.3.3.3.eth-addr.arpa.. لم تصبح هذه الطلبات تخصيصات نافذة، والوثيقة ليست RFC بعد.

يبدأ stream جديد باختيار قيمة عشوائية من 28 بت. يدمجها التطبيق مع interface identifier للمصدر وفق RFC 4489 ليصنع عنوان IPv6 multicast بنطاق الرابط، ثم يشتق عنوان Ethernet وفق RFC 2464.

قد يختلف عنوانا IPv6 بينما ينتهيان إلى عنوان Ethernet واحد. لذلك ينسق المشروع الشيء الذي تراه بطاقة الشبكة والمبدّل فعلاً. تُعكس أنصاف البايتات في اسم DNS؛ فيصبح 33:33:9A:BC:DE:F0 هو 0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa.

الصمت إذن محدود لا ملكية

ينشر التطبيق PTR يشير إلى معرّف فريد للتطبيق ثم hostname. قبل ذلك يجري probe وفق RFC 6762. إذا بدأ منافسان معاً، يعود الخاسر إلى اختيار قيمة أخرى. وإذا لم يظهر تعارض، يعلن التطبيق السجل ويجيب عن الاستعلامات ويبدأ استعلاماً مستمراً، ثم يسمح له بالإرسال.

عدم سماع اعتراض يعني أن العنوان متاح. لكن حجب mDNS قد يجعل تطبيقين يسمعان الصمت نفسه ويعتبرانه إذناً. الصمت يصف مجال الرصد الذي وصلته الرسالة، ولا يثبت أن الجميع سمعها.

يُحفظ group ID في تخزين دائم، إلا أن إعادة التشغيل لا تسمح بتجاوز probe والإعلان والمراقبة. ربما تغيرت الشبكة أو التأم partition في أثناء الغياب. القيمة المحفوظة تفضيل سابق وليست lease.

عند ظهور تعارض لاحق، يوقف الخاسر stream قبل اختيار ID جديد. ويمكن للـ network stack اكتشاف عنواني IPv6 مختلفين تحولا إلى عنوان Ethernet نفسه، لكن المشروع لا يحدد كيف تتفق عدة hosts على من يتراجع.

اللاحقة التي تصنع سلطة حاسمة

إذا رأى مكوّن البنية التحتية تصادماً لا يستطيع حله في جدول أو filter، ينشر PTR للنقض تحت owner name نفسه. يضيف -veto إلى أول label في PTRDNAME الأصلي. طول label يظهر أولاً في مقارنة RDATA، لذلك تكون اللاحقة الأطول لاحقةً في الترتيب المعجمي وتفوز دائماً.

ينشر الجهاز veto بلا probe. يتوقف التطبيق، ويختار ID آخر، ويستبدل القيمة المخزنة. وحين يبطل PTR الأصلي بسبب expiry أو goodbye، يستعلم صاحب veto خمس ثوان؛ فإن لم يتلق رداً، ينتظر عشوائياً من 20 إلى 120 ميلي ثانية ويرسل goodbye يسحب به سجله.

إذن السلطة موزعة: التطبيق يقترح، والـ peers يعترضون، والبنية التحتية تلغي، والمستقبلون يثبتون ما إذا كان البديل يعمل.

الفوز في المقارنة لا يثبت صدق الرسالة

يستطيع طرف خبيث الرد على كل probe أو إنشاء veto مزيف، فيمنع التخصيص أو يفرض سلسلة من الإيقاف وإعادة الاختيار. ويمكن لمن يحجب mDNS أن يعطل اكتشاف التعارض بالعكس.

لا يثبت البروتوكول أن ناشر veto هو switch رأى مشكلة مادية حقيقية. كما لا يثبت الإعلان الناجح هوية المنتج أو صلاحية المحتوى أو انضمام المستقبل أو نتيجة التطبيق.

تحتاج العملية إلى سلسلة أدلة تشمل هوية stream وgroup ID وsource IID وعنواني IPv6 وEthernet وowner وRDATA وprobe والإعلان وجيل الاستعلام المستمر وناشر التعارض وإقرار الإيقاف والعنوان البديل وانتقال المستقبلين وسحب السجل القديم.

بعد إصلاح partition يساعد الاستعلام المستمر على اكتشاف النسخ المكررة، لكن mDNS قليل الحركة قد يتأخر. ترك المشروع آليات إضافية للشبكات التي تنشئ streams أثناء العزل لعمل مستقبلي. العشوائية تخفض الاحتمال ولا تعيد packet محجوباً إلى مجال الرؤية ولا توحد تاريخين منفصلين.

حددت RFC 10019 المشكلة من دون بروتوكول كامل أو قاعدة فوز. تقدم النسخة 12 آلية ملموسة. ووفق أولوية الشيفرة العاملة، يبقى كل دليل في طبقته: PTR ادعاء رمزي، والمقارنة تحكم تنفيذي، وswitch ملاحظة مادية، والتطبيق نتيجة. قيمة التصميم أنه يجعل فعلاً من أفعال السلطة قابلاً للرصد، لا أنه يلغي السلطة.

المصادر