يبقى تخصيص IPv4 سارياً، لكن نقطة انطلاقه عبر IPv6 قد تتغير

الخلاصة

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

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

هذا أحد الجوانب التي تنظمها RFC 8539، وهي وثيقة صدرت في مارس 2019 لإعداد الأنفاق ديناميكياً باستخدام DHCPv4 فوق DHCPv6. وما زال السجل الرسمي يصنفها ضمن Proposed Standard. ولم يُظهر الاستعلام عن التصحيحات في 8 سبتمبر 2026 أي سجلات مطابقة. تلك معلومات عن الوثيقة، وليست إثباتاً على استخدام مزوّد بعينه لها أو على جودة تطبيقه.

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

حرية تبدأ بعد توافر الاتصال

لا تنشئ هذه الآلية اتصال IPv6 من الصفر. يجب أن يكون لدى العميل بادئة مناسبة سبق إعدادها، سواء عبر DHCPv6 أو إعلانات الموجّه أو وسيلة أخرى. الحصول على مورد IPv4 لا يوفّر تلقائياً المسار الذي سيحمله عبر IPv6.

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

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

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

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

التخصيص لا يغني عن معرفة الطرف

يحفظ الخادم مصدر IPv6 إلى جانب تخصيص IPv4 ومعرّف العميل. ويظل الارتباط صالحاً مع مدة الإيجار. فإذا تطلبت إعادة ترقيم IPv6 مصدراً جديداً خلال المدة نفسها، يطلب العميل تحديث الارتباط، ولا يفترض أن الخادم سيتبع التغيير تلقائياً.

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

وتوضح بنية Lightweight 4over6 سبب أهمية هذه العلاقة. إذ تنقل ترجمة العناوين والمنافذ إلى جهة العميل، بينما يحتفظ موجّه الانتقال الخفيف لدى المزوّد بربط بين عنوان IPv6 وعنوان IPv4 العام ومجموعة منافذ محدودة. تُستخدم هذه المعلومات لإرسال الحركة الواردة إلى الطرف الصحيح وللتحقق من الحركة المغلفة الصادرة من العميل.

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

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

المزوّد يستطيع تنظيم وتيرة الاختيار

السماح باختيار المصدر لا يساوي السماح بتبديله باستمرار. تتيح RFC 8539 للخادم وضع حد أدنى للفاصل بين تحديثات المصدر. وإذا نُفذت هذه السياسة الاختيارية، فالقيمة الافتراضية المحددة هي 60 ثانية. وقد يُسقط الطلب المبكر بلا رد، أو يتلقى إقراراً لا يزال يحمل المصدر القديم المرتبط.

هذا ليس انتظاراً إلزامياً لكل العملاء، وليس ضماناً عاماً لاستعادة الخدمة خلال دقيقة. يجب التحقق من تفعيل السياسة وقيمتها الفعلية في كل بيئة، ومن توافق إعادة المحاولة وتحرير الموارد لدى العميل معها.

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

لا تقيس المواصفة كلفة الطرفين ولا تحسم أيهما أولى. كما أنها لا تبرر افتراض نية لعرقلة العميل. ما تظهره هو أن المكان والوقت بُعدان مختلفان للحرية التشغيلية.

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

المصدر المتغير ليس هوية مجهولة

تحذر RFC 8539 من أن معرّف واجهة ثابتاً قد يتيح تتبع الجهاز بين الشبكات والجلسات. وتناقش تكويناً يستند إلى عنوان IPv4 ومعرّف مجموعة المنافذ، بالرجوع إلى صيغة MAP-E.

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

وتشرح ملفات إعداد إخفاء الهوية لعملاء DHCP لماذا لا يكفي تبديل عنوان طبقة الوصلة إذا بقيت معرّفات أخرى ثابتة. وتعرض أيضاً آثاراً تشغيلية: قد يظل العنوان السابق مسجلاً على أنه مؤجّر بعد تغيير هوية العميل، بينما يُخصّص له عنوان آخر. وقد تتعارض بعض خيارات تقليل الارتباط مع إعادة منح العميل المعروف عنوانه السابق، أو خدمات الأسماء، أو السماح بالاتصال استناداً إلى معرّفات مسجلة.

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

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

في الملاحظة 36، يدعو Lu Heng إلى وصف البنية الفعلية بدلاً من الترويج للحلول. وبذلك المعيار، تكون النتيجة محددة: الإعداد الديناميكي يوسع خيارات الموضع، لكنه لا يلغي صيانة الارتباط ولا سلطة تنظيم تحديثه ولا أثر المعرّفات على الخصوصية.