الخلاصة

  • أتاحت 6to4 في عام 2001 لموقع يملك عنوان IPv4 فريداً عالمياً أن يشتق بادئة IPv6 ضمن 2002::/16، وأن يعبر شبكة IPv4 من دون التفاوض مسبقاً على كل نفق.
  • جعلت تقنية anycast المرحّل يبدو تلقائياً، لكن مساري الذهاب والعودة كانا قد يعتمدان على مشغّلين مختلفين لا تجمعهما مسؤولية مشتركة. وهكذا حوّلت المرشحات والمسارات الرديئة والتفعيل الافتراضي الراحة إلى أعطال متكررة.
  • أوقفت RFC 7526 التوصية بآلية مرحّلات 6to4 المعتمدة على anycast في 2015. ولم تُلغِ 6to4 أحادية الإرسال الأساسية ولا البادئة 2002::/16، وهو حد لا يزال مهماً عند قراءة السجل اليوم.

عنوان سبق الاتفاق

أكثر أجزاء 6to4 رسوخاً في الذاكرة عملية حسابية. تؤخذ البتات الاثنتان والثلاثون لعنوان IPv4 فريد عالمياً، وتوضع بعد البادئة 2002، فيحصل الموقع على /48. كتبت RFC 3056 النتيجة بالصيغة 2002:V4ADDR::/48. وكان بوسع شبكة لم يصلها IPv6 الأصلي بعد أن توزّع داخلياً عناوين من تلك البادئة. وعند الحافة، كان موجّه 6to4 يغلّف حزمة IPv6 مباشرة داخل حزمة IPv4 باستخدام البروتوكول 41.

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

لكن تلك السهولة كانت محدودة منذ البداية. فعنوان IPv4 الخاص لا ينتج بادئة 6to4 ذات معنى عالمي. وإذا تغيّر عنوان IPv4 تغيّرت معه بادئة 6to4 المشتقة. وفوق ذلك كله، ظل الانتقال بين عالم 6to4 وعالم IPv6 الأصلي يحتاج إلى جهة تحمل الحزم. لقد أُتمت عنونة الموقع تلقائياً؛ أما الوصول الشامل فلم يُنجز تلقائياً.

المرحّل الذي اختفى عن الأنظار

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

قدّمت RFC 3068 جواباً بالغ البساطة: يُمنح عدد من موجّهات الترحيل عنوان IPv4 مشتركاً بتقنية anycast هو 192.88.99.1. يرسل موجّه 6to4 الحركة نحو ذلك العنوان، فتختار مسارات IPv4 العادية مرحّلاً قريباً يعلن الطريق. لم يعد المستخدم مضطراً إلى اكتشاف بوابة بعينها أو إعدادها. وأصبحت آلية كانت تتطلب ترتيباً تشغيلياً تبدو كأنها مفتاح تشغيل.

أخفى هذا المفتاح عدم تماثل مهم. فالمرحّل المختار للحركة الصادرة ليس ملزماً بأن يكون المرحّل نفسه في مسار العودة. وقد تختار شبكة IPv6 أصلية وهي ترسل إلى 2002::/16 مرحّلاً آخر، يديره مشغّل آخر وتصل إليه وفق سياسة توجيه مختلفة. لم يكن على المرحّلين أن يعرف أحدهما الآخر. اعتمد النجاح على منظمات متعددة تقدّم خدمات متوافقة، لكن الآلية لم تنشئ عقداً بينها ولا مالكاً واحداً للرحلة ذهاباً وإياباً.

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

حين أخفى الرجوع الكلفة

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

بحلول 2011، استطاعت RFC 6343 وصف سجل تشغيلي أوسع. فقد أشارت إلى مرشحات تحجب البروتوكول 41، ومرحّلات مفقودة أو يتعذر الوصول إليها، ومسارات تعمل في اتجاه دون الآخر. واستشهدت بتجارب معاصرة تراوحت فيها معدلات فشل اتصال 6to4 تقريباً بين 9 و20 في المئة. لم تكن تلك الأرقام إحصاءً عالمياً، لكنها كانت كبيرة بما يكفي لتحويل أداة انتقال إلى مشكلة موثوقية مرئية.

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

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

إيقاف الاختصار لا محو الماضي

حوّلت RFC 7526 التراجع إلى سياسة رسمية في مايو 2015. فقد أوقفت التوصية بآلية 6to4 المعتمدة على anycast، ونقلت RFC 3068 وRFC 6732 المرتبطة بها إلى الحالة التاريخية، ودعت إلى وقف إعلان مسار anycast وخدمة الترحيل على 192.88.99.1. وكان ينبغي تعطيل 6to4 افتراضياً في التطبيقات. لم يعد الاختصار العام بنية انتقال موصى بها.

ومن السهل طمس نطاق القرار. نصّت RFC 7526 صراحة على أنها لم تُلغِ آلية 6to4 أحادية الإرسال الأساسية في RFC 3056، ولم تُلغِ البادئة 2002::/16. وما زال سجل IANA الحالي لعناوين IPv6 ذات الأغراض الخاصة يدرج هذه الكتلة باعتبارها 6to4. يسجّل وجودها في السجل تخصيصاً معمارياً؛ ولا يَعِد بأن مسار ترحيل عام متاح أو مستحسن.

تفسّر هذه التفرقة لماذا لا ينتهي التاريخ بعملية حذف. استطاع مسار المعايير أن يسحب توصية تشغيلية، وأن يحتفظ في الوقت نفسه بالمفردات اللازمة للتعرّف إلى العناوين القديمة والترتيبات المدارة والأنظمة المتبقية. على مشغّل يرى 2002::/16 اليوم أن يقرأها دليلاً على الآلية، لا دليلاً على أن خدمة anycast بقيت بعد مراجعتها.