الخلاصة
- لا يتحول عنوان IPv6 من الاستخدام العادي إلى العدم دفعة واحدة. انتهاء العمر المفضل يجعله مهملاً، لكنه يظل صالحاً حتى ينتهي العمر الصالح.
- تسمح الفترة الفاصلة بأن تختار الاتصالات الجديدة عنواناً بديلاً، بينما تحتفظ الجلسات القائمة بالطرف الذي لا تستطيع تبديله من دون انقطاع.
- تحمي قاعدة الساعتين من إعلان موجّه مزور يمحو العناوين سريعاً. لكن الموجّه الذي ينسى البادئة القديمة بعد إعادة التشغيل قد يعجز أيضاً عن سحبها بصورة صحيحة.
كان للعنوان موعدان للنهاية
عرّف RFC 1971 منذ عام 1996 حالات preferred وdeprecated وvalid وinvalid. ما دام العنوان preferred تستطيع الطبقات العليا استخدامه بلا قيد خاص. عند انتهاء Preferred Lifetime يصبح deprecated: يُنصح بعدم اختياره، لكنه لا يزال مربوطاً بالواجهة. ولا يصبح invalid إلا عند انتهاء Valid Lifetime.
تحمي هذه المرحلة الوسطى حقيقة عملية. اتصال TCP المفتوح لا يبدل عادة عنواني طرفيه في منتصف الجلسة. حذف العنوان القديم فور ظهور بادئة جديدة سيقطع اتصالاً سليماً لمجرد أنه بدأ قبل إعادة الترقيم. لذلك يظل العنوان المهمل يستقبل الرزم، ويمكن أن يبقى مصدراً لاتصال قائم إذا كان تغييره يضر بالنشاط الأعلى.
إذن الإهمال ليس مرادفاً لانعدام الوصول. الساعة الأولى تجيب: هل ينبغي اختيار هذا العنوان لعمل جديد؟ والساعة الثانية تجيب: هل ما زال هذا العنوان تابعاً للواجهة أصلاً؟
حمل إعلان الموجّه ساعتين مستقلتين
يضع RFC 4861 Preferred Lifetime وValid Lifetime في خيار Prefix Information داخل Router Advertisement. الحقلان من 32 بت بالثواني، وتمثل البتات كلها واحداً زمناً لا نهائياً. لا يجوز أن يتجاوز العمر المفضل العمر الصالح؛ ويطلب RFC 4862 تجاهل الخيار إذا انعكس الترتيب.
لا تنشئ الأرقام عنواناً وحدها. يجب أن يسمح علم Autonomous باستخدام البادئة في SLAAC. البادئة والعلم والعمران أجزاء من تصريح واحد، ولكل جزء سلطة مختلفة.
تصل إعلانات الموجّه دورياً فتجدد الحالة. تكرار قيمة ثابتة يدفع النهاية إلى الأمام مع كل وصول، بينما تستطيع قيمة متناقصة أن تتجه إلى موعد محدد. غياب البادئة من إعلان واحد ليس سحباً؛ فقد تُقسم الخيارات على عدة رسائل أو تضيع إحداها. يتصرف المضيف بناء على ما استلمه وعلى انتهاء المؤقت، لا على صمت يحتمل أكثر من تفسير.
الاختيار الافتراضي يغيّر التدفق من دون طرد
حين يصبح العمر المفضل صفراً، ينبغي للاتصال الجديد اختيار مصدراً غير مهمل إن وجد عنوان مناسب. تجعل القاعدة الثالثة في RFC 6724 المصدر غير المهمل أسبق من المصدر المهمل.
هذه أفضلية افتراضية وليست حظراً. يمكن لتطبيق أن يحدد عنواناً صالحاً صراحة، ويمكن للاتصال القائم مواصلة استخدامه. وإذا وصل SYN جديد إلى عنوان مهمل لكنه صالح، قد يجيب المضيف بـSYN-ACK من العنوان نفسه إذا كان الاتصال مسموحاً به. استقبال الوجهة لا يتوقف عندما تتوقف أفضلية المصدر.
خلال الانتقال قد تحمل الواجهة عنوانين من بادئتين. يستقبل الجديد العمل المقبل، ويصرف القديم العمل القائم. وجود القديم في قائمة العناوين لا يثبت فشل الانتقال؛ المطلوب معرفة حالته والوقت المتبقي وأي مصدر اختارته الاتصالات الجديدة فعلاً.
الصفر الأول يبدأ التصريف لا الإزالة
يستطيع المسؤول إعلان البادئة القديمة بعمر مفضل يساوي صفراً وعمر صالح موجب. ينتقل العنوان فوراً إلى deprecated ولا يحذف. بذلك تتوقف جلسات جديدة عن الاعتماد عليه، وتحصل الجلسات القديمة على مهلة للانتهاء.
يصف RFC 5887 إعادة الترقيم المخطط بهذا التداخل: إدخال البادئة الجديدة، تخفيض أفضلية القديمة، ثم إنهاء صلاحيتها بعد انتقال الاعتمادات. لكنه يوضح أيضاً أن العنوان ليس كل النظام.
قد تحتفظ DNS والمسارات والجدران النارية وقوائم السماح والشهادات والتطبيقات بالقيمة القديمة. قد يعد المضيف العنوان صالحاً بعد أن يختفي مسار الرجوع، ولا يمحو deprecated سجلاً في DNS. يوفر العمران ترتيباً للتنسيق، ولا ينفذان تغييراً ذرياً في جميع الطبقات.
الموت السريع يحتاج دليلاً أقوى
قد يكون Router Advertisement غير موثّق. لو استطاع إعلان مزور خفض Valid Lifetime إلى ثوان، لأمكن لمهاجم على الوصلة محو عناوين المضيف. لذلك وضع RFC 4862 حد الساعتين. إذا كان الزمن المتبقي طويلاً، لا تجعل قيمة قصيرة غير موثقة العنوان ينتهي عادة قبل ساعتين. وإذا بقيت ساعتان أو أقل، يتجاهل المضيف التخفيض الإضافي غير الموثق لحساب الصلاحية.
يعامل العمر المفضل بطريقة مختلفة؛ يُضبط على القيمة المستلمة حتى عندما تحمى الصلاحية. السبب هو فرق الضرر. إخراج العنوان من الاختيار الجديد أقل تدميراً من إزالته، كما يحتاج المسؤول الشرعي إلى بدء الانتقال سريعاً.
قد يسمح إعلان موثّق بقرار مختلف. لا تعني القاعدة أن الإعلانات المنشورة موثقة، ولا تجعل ساعتين مدة إلزامية لكل انتقال. إنها سقف للسلطة التي تمنح لدليل ضعيف.
إعادة التشغيل قد تمحو اسم الشيء المراد سحبه
قد يعيد موجّه منزلي التشغيل ويحصل من المزود على بادئة جديدة، لكنه لا يحتفظ بالبادئة القديمة. يستطيع إعلان الجديد ولا يستطيع صياغة خيار يقول إن القديم يجب أن يصبح صفراً. تستمر المضيفات في الاعتماد على آخر مؤقت وصلها.
يحلل RFC 8978 هذه الحالة باسم flash renumbering. يستخدم القيم الافتراضية في RFC 4861 ليبين أن العنوان القديم قد يبقى مفضلاً سبعة أيام وصالحاً ثلاثين يوماً. هذه ليست إحصاءات نشر؛ بل مقياس لطول وعد لم يصل إلغاؤه.
حتى إذا تذكر الموجّه البادئة وأرسل العمرين صفراً، فقد تمنع قاعدة الساعتين الإبطال الفوري إن لم يكن الإعلان موثقاً. مقاومة الموت المزور وسرعة إزالة بادئة ضائعة تتنافسان على نفس السلطة.
السحب الموثوق يحتاج ذاكرة وتكراراً
يوصي RFC 9096 موجّهات حافة العميل بحفظ البادئات المعلنة في تخزين ثابت، وربط أعمار LAN بما تبقى من تفويض المنبع، وإعادة إعلان البادئة القديمة بعمرين صفريين.
لا تكفي رسالة واحدة. قد يفقد مضيف إعلان السحب، لذلك يجب تكراره مدة مرتبطة بالصلاحية التي وُعد بها سابقاً. إنهاء الحالة مسؤولية تمتد عبر فقد الرزم وإعادة التشغيل، لا نجاح إرسال لحظي.
لا يثبت هذا التوجيه أن الأجهزة تطبقه. لكنه يكشف شرطاً أصيلاً: من ينشئ حالة قابلة للتجديد يحتاج سجلاً يتيح له معرفة ما يجب إنهاؤه لاحقاً.
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
