الخلاصة

  • تفترض draft-ietf-pim-ipv6-zeroconf-assignment-12 أن العنوان متاح إذا لم يتلق التطبيق دليلاً على استخدامه. قيمة هذا الدليل السلبي لا تتجاوز الواجهات والروابط ومسارات عاكسات mDNS التي كان يمكن أن تحمل اعتراضاً.
  • حفظ معرّف المجموعة يحد من التغيير لكنه لا يلغي الاستطلاع والإعلان والاستعلام المستمر والدفاع. وبعد إصلاح الانقسام، يجب على الطرف الخاسر إيقاف التدفق واختيار معرّف جديد وحفظه بدلاً من القديم.

نُشرت المراجعة 12 في 22 سبتمبر 2026. ويعرض سجل Datatracker المحفوظ مسودة إنترنت نشطة (Internet-Draft) لمجموعة PIM، رُفعت إلى IESG ودخلت مرحلة Last Call حتى 6 أكتوبر، مع استهداف حالة Proposed Standard. لكنها ليست RFC، ولا تخصيصاً مكتملاً من IANA، ولا تقرير تشغيل بيني أو نشر فعلي.

يبدأ الإجراء عندما يختار التطبيق معرّف مجموعة عشوائياً من النطاق المقترح 0x90000000–0x9FFFFFFF عند إنشاء تدفق جديد أو الاستجابة لتصادم. يدمج القيمة مع معرّف واجهة المصدر لينشئ عنوان بث متعدد IPv6 محدوداً بالرابط، ثم يشتق عنوان Ethernet المقابل. وفي مثال المسودة يؤدي 9abc:def0 إلى 33:33:9A:BC:DE:F0.

بعد ذلك تُعكس الخانات السداسية لعنوان Ethernet تحت .eth-addr.arpa. ينشئ التطبيق سجل PTR فريداً، ويستطلع وجود التعارض عبر mDNS، ثم يعلن السجل ويجيب عن الاستعلامات ويبدأ استعلاماً مستمراً ويدافع عنه. الغرض ضيق: تنسيق التفرد المحلي من دون موزع مركزي.

لكن قرار البدء مبني على غياب معلومة. تسمي المراجعة 12 هذا «التوافر الضمني»: إذا لم يصل ما يشير إلى أن العنوان مستخدم، يفترض التطبيق أنه متاح. وتضيف مباشرة أن ترشيح حركة mDNS في المضيف أو الشبكة يمنع التطبيقات من التنسيق وقد يؤدي إلى تصادمات.

لذلك لا يمثل الصمت حقيقة شاملة. إنه يثبت فقط أن سجلاً متعارضاً لم يظهر خلال نافذة زمنية وعبر واجهات ومسارات محددة. لا ينفي وجود مرسل وراء مرشح أو عاكس معطل أو جزء منفصل. كما أن احتمال n / 2^28 الوارد في المسودة يصف الاختيار العشوائي، ولا يثبت اكتمال نطاق الرؤية.

يوضح انقسام الشبكة الخلل. يتعطل مبدل فيفصل جانبين. يستعيد تطبيق في الجانب الأول معرّفاً محفوظاً لتدفق قديم، بينما يختار تطبيق جديد في الجانب الآخر القيمة نفسها. يجري كلاهما الاستطلاع ولا يسمع الآخر، لأن PTR لا يعبر نقطة القطع. فيبدو الادعاءان صحيحين محلياً.

عند عودة المبدل، يصبح الادعاءان داخل نطاق واحد. ولهذا تفرض المسودة استعلام PTR مستمراً لاكتشاف التصادم بعد الإصلاح. وعند ظهوره تُطبق قواعد mDNS، فيوقف الخاسر البث ويختار معرّفاً آخر ويستبدل القيمة المخزنة.

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

خلال تلك الفترة قد تبدو حالتا المرسلين سليمتين. وقد يحمل عنوان Ethernet متعدد واحد وجهتين مختلفتين في IPv6. شاشة تعرض «PTR معلن» فقط لا تميز بين التفرد الحقيقي والعزلة المؤقتة عن الدليل المضاد.

تتيح المراجعة حساساً اختيارياً آخر. يمكن لمكدس الشبكة مراقبة حركة لها عنوان Ethernet متعدد الوجهة نفسه لكن عنوان IPv6 متعدد مختلف. عند اكتشافها يجب إيقاف التدفق وإعادة الاختيار. يكفي أن يتحرك طرف واحد، وقد يتحرك الطرفان؛ ولا تحدد المسودة آلية لتنسيق من يتنازل.

للبنية التحتية سجل veto. إذا اكتشف مكوّن تصادماً لا يستطيع حله، يضيف -veto إلى أول تسمية في هدف PTR. وبذلك يصبح السجل لاحقاً دائماً في الترتيب المعجمي المستخدم لحسم mDNS ويفوز. يُنشر من دون استطلاع ويجبر التطبيق على الانتقال.

غير أن veto مؤقت. إذا اختفى PTR المسبب أو انتهت صلاحيته، يستعلم الناشر خمس ثوانٍ. وإذا لم يتلق رداً، ينتظر زمناً عشوائياً بين 20 و120 ميلي ثانية ثم يرسل goodbye يبطل السجل. لا حاجة إلى حفظ veto لأن التطبيق انتقل وحفظ معرّفه البديل.

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

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

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

كما أن تنسيق العنوان ليس اكتشافاً للخدمة. تستخدم المسودة PTR لتنسيق العنوان لكنها لا تفرض طريقة إعلان عنوان التدفق للمستقبل. DNS-SD بخدمة _udp وسجل TXT مجرد خيار طبيعي. وحتى نجاحه لا يثبت انضمام المستقبل أو بناء حالة التوجيه أو وصول الحزم أو استهلاك التطبيق لها.

عبر شبكات فرعية متعددة، يجب توزيع PTR بينها، مثل استخدام عاكس mDNS، وتصف المسودة ذلك بأنه مجال بحث وتطوير مستمر. التدفق المعاد توجيهه يحتاج عنوان IPv6 متعدد مبنياً على بادئة unicast بدلاً من العنوان محدود الرابط. واعتماد التصميم على مضيفين متعاونين يجعله غير ملائم للإنترنت العالمي.

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

السؤال الصحيح ليس هل كان mDNS يعمل، بل من كان قادراً على الاعتراض. من دون تحديد هذا النطاق، لا يعني «متاح» سوى أن أحداً مرئياً لم يعترض بعد.

المصادر