الخلاصة

  • تقترح مسودة مجموعة INTAREA النشطة التي كتبها Remco van Mook استخدام 192.0.0.11/32 بوصفه بوابة إشارية؛ فلا يرسل المضيف الداعم ARP، بل يأخذ MAC من موجّه IPv6 الافتراضي الذي اختاره.
  • تبقى الحزمة IPv4 أصلية من دون نفق أو ترجمة، لكن العودة تتطلب إعلان مسار المضيف IPv4 /32 عبر قفزة IPv6 من نوع GUA أو ULA قابلة للتوجيه.
  • تقليل بروتوكول على الوصلة لا يلغي الحالات: DHCP وRA وNUD وتمرير IPv4 ومسار العودة وتوافق الأجهزة القديمة أدلة مستقلة وقد تفشل منفردة.

رقم يحدد سلوكاً لا جهازاً

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

يظل التطبيق يستعمل مقبس IPv4، وينشئ المضيف حزمة IPv4، وتمرر الشبكة IPv4 كما هو. ليست هناك NAT64 ولا تغليف داخل IPv6. التغيير محصور في كيفية العثور على القفزة الأولى.

انتقلت الوثيقة في أغسطس/آب 2026 إلى مسار مجموعة عمل INTAREA. وتذكر أنها جُرّبت من دون تعديل التطبيقات أو إعداد DHCPv4 على Windows 11 وmacOS وAndroid وiOS وLinux وFreeBSD وChromeOS. هذه نتيجة توردها المسودة وليست شهادة مستقلة. كما أن Internet-Draft قابل للتغيير، فلا يصح وصف الإشارة بأنها معيار عالمي مستقر.

وصول الإعداد ليس وصول الخدمة

يثبت عقد DHCP أن القيمة وصلت فقط. قبل أول Router Advertisement لا يوجد موجّه IPv6 يمكن استعارة جواره؛ لذلك يجب أن يكون انتظار الحزم محدوداً. وبعد ظهور أكثر من موجّه، تأتي أفضلية RFC 4191 أولاً ثم حالة الوصول، وقد تحسم قواعد التنفيذ الخاصة التعادل.

تغيير الموجّه المختار يستلزم إعادة تقييم مسار IPv4 وقد يقطع الجلسات القائمة. في IETF 126 سأل Lorenzo Colitti عن متابعة تغيّرات توجيه IPv6، وحذّر من أن تنفيذاً خاطئاً قد يعطل IPv4. أكد Remco van Mook أن المتابعة جزء من الآلية.

أما مخبأ الجيران فهو دليل ثانٍ. حالات reachable وstale وdelay وprobe في RFC 4861 ليست متساوية، وإن أمكن استعمالها في مراحل الفحص. بقاء MAC لا يثبت أن الجهاز لا يزال يمرر IPv4، وقدرة الجهاز على التمرير لا تفيد إن انتهت حالة RA أو ND.

طريق العودة يحتاج عنواناً قابلاً للتوجيه

يكفي عنوان IPv6 من نوع link-local للقفزة الخارجة الأولى. لكنه لا يصلح قفزة تالية بين الموجهات. يجب أن تعلن الشبكة /32 الخاص بالمضيف مع قفزة IPv6 من نوع GUA أو ULA قابلة للوصول. يحدد RFC 8950 طريقة إرفاق قفزة IPv6 بمعلومة وصول IPv4 في BGP، وتعالج مسودة v4-via-v6 جانب الموجهات.

لذلك لا يكفي نجاح اختبار خارج من المضيف. يلزم إثبات قبول العقد، واختيار RA المقصود، ووجود MAC الصحيح، وتمرير IPv4 الأصلي في الموجّه، ووصول مسار /32 إلى نقاط العودة.

القناع /32 يحفظ حدود الفكرة

إذا مُنح المضيف بادئة IPv4 أوسع، فسيعد عناوين أخرى موجودة على الوصلة ويرجع إلى ARP. ليس /32 تفصيلاً في الترقيم، بل شرط يمنع عودة شبكة IPv4 الضمنية.

تذكر المسودة Hetzner وOVH وScaleway أمثلةً على عناوين منفردة وبوابات خارج الوصلة تحتاج اليوم إلى حلول تختلف بين أنظمة التشغيل. يوضح ذلك الحاجة إلى سلوك موحد، لكنه لا يثبت أن تلك الشركات نشرت الإشارة الجديدة؛ الادعاء منسوب إلى المسودة.

يوفر RFC 8925 خياراً آخر يسمح للأجهزة القادرة بتفضيل IPv6-only. أما هذا المقترح فيحافظ على IPv4 الأصلي لأجهزة dual-stack داخل وصلة يغلب عليها IPv6. يمكن الجمع بينهما، لكن لا يصح اعتبار نجاح أحدهما اختباراً للآخر.

التوافق القديم مسار ثانٍ

المضيف غير المعدل سيتعامل مع 192.0.0.11 كبوابة عادية ويرسل ARP. توصي المسودة بأن يجيب الموجّه بعنوان MAC الخاص به، كي تتعايش الأجهزة الجديدة والقديمة.

ينشأ بذلك اختباران. نجاح الجهاز القديم يثبت عمل مجيب ARP ولا يثبت أن جهازاً جديداً اختار الموجّه عبر IPv6. ونجاح الجهاز الجديد لا يضمن خدمة القديم. يجب فصل العدادات والعملاء الاختباريين.

في مناقشة IETF 126 وصف Tobias Fiebig النهج بأنه أنيق مقارنة بنقل DHCPv4 داخل DHCPv6. الأناقة تقلل التبادل الظاهر على السلك، لكنها لا تزيل حالات الاختيار والجوار والتمرير والعودة.

الكود يوضح حدوده بنفسه

يضم مستودع v4-with-v6-nh برنامجاً خدمياً لنظام Linux يكتشف الإشارة، ويختار وفق RFC 4191، ويثبت مسار IPv4 عبر قفزة IPv6، ويتابع التغيير ثم يسحب المسار عند زوال الشرط. يدعم Linux هذا النوع من المسارات منذ النواة 5.2.

لكن البرنامج لا يستطيع تعليق كل حزمة على حدة حتى أول RA، ودعم systemd-networkd ما زال تصحيحاً، وصيغة FreeBSD تحققت من حيث البناء من دون اختبار فعلي، ولم تختبر إعدادات المعدات التجارية على عتاد، ولا يوجد إصدار موسوم. هذه أدلة على قابلية التنفيذ لا على نضج إنتاجي شامل.

الاختبارات المهمة هي الانتقالات: انتهاء DHCP، وتأخر RA الأولى، وسحب الموجّه المفضل، وتقادم NUD، وضياع مسار العودة /32، وتعادل الموجهات، واختلاط الأجهزة الحديثة والقديمة.

تنتقل الثقة من ARP إلى RA وND

يزيل غياب ARP سطحاً قديماً للانتحال والضوضاء. لكنه لا يلغي ثقة القفزة الأولى. قد يحدد إعلان RA خاطئ عنوان MAC الذي يستقبل IPv4، وقد يوقف خلل ND عائلتي العناوين معاً.

تصبح RA Guard والمنافذ الموثوقة وفحص حالة الجيران وأفضلية الموجهات الصريحة عناصر في حماية IPv4. أخطر فشل صامت: يوزع DHCP الإشارة في وصلة تنفذ نصف الآلية فقط. وقد يرفض مدقق DHCP البوابة خارج الوصلة في مرحلة أسبق. قبول الإعداد والقدرة على التمرير حالتان لا مصباح واحد.

المصادر