الخلاصة

  • وثائق Azure تشترط أن تحمل كل واجهة شبكة تكوين IPv4 واحداً على الأقل، وتنص على أن الأجهزة الافتراضية ومجموعات المقاييس التي تعمل بـIPv6 وحده غير مدعومة.
  • عناوين IPv6 العامة في Azure بلا رسوم، وعناوين IPv4 العامة بند مُسعَّر؛ والشرط يُطبَّق عند واجهة الشبكة، أي في الطبقة التي يطلب عندها العميل العناوين من المنصة.

الجملة التي تحسم كل شيء

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

ثم يصل إلى قسم القيود. هناك، بجملة واحدة، تُغلق الفكرة: الأجهزة الافتراضية ومجموعات المقاييس التي تعمل بـIPv6 وحده غير مدعومة، وكل واجهة شبكة يجب أن تتضمن تكوين IPv4 واحداً على الأقل. ليست جملة في مدونة، ولا تعليقاً في منتدى دعم، بل نص منشور في الصفحة التي تشرح الميزة نفسها (نظرة عامة على IPv6 في Azure Virtual Network).

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

ما تقوله الوثائق فعلاً

الوثيقة الأولى هي صفحة IPv6 في Azure Virtual Network. تنص في قسم القيود على أن الأجهزة الافتراضية التي تعمل بـIPv6 وحده غير مدعومة، وكذلك مجموعات المقاييس التي تعمل بـIPv6 وحده، لأن كل واجهة شبكة يجب أن تحمل تكوين IPv4 واحداً على الأقل. والصفحة نفسها تقول إن استعمال عناوين IPv6 العامة وبادئات IPv6 العامة لا يُحتسب له رسم، وإن الموارد المرتبطة والنطاق الترددي تُحتسب بالسعر نفسه المطبَّق على IPv4 (الوثيقة الأولى).

الوثيقة الثانية هي صفحة عناوين IP العامة، وهي تكرر المعنى نفسه من زاوية التسعير: عنوان IPv4 العام له رسم اسمي، وعنوان IPv6 العام بلا رسم، ثم تعود لتقول إن الأجهزة الافتراضية ومجموعات المقاييس التي تعمل بـIPv6 وحده غير مدعومة، لأن كل واجهة شبكة يجب أن تحمل تكوين IPv4 واحداً على الأقل في إعداد مزدوج المكدّس (عناوين IP العامة في Azure).

وليس في هذا خفاء. المنصة تصف IPv6 بأنه اتصال مزدوج المكدّس يتيح للتطبيقات المستضافة في Azure الوصول إلى الإنترنت القائم على IPv4 وإلى أجهزة وشبكات IPv6 الجديدة في الوقت نفسه؛ أي أن الوعد نفسه مصوغ كتعايش مع IPv4 لا كخَلَفٍ له. هذه الصياغة متسقة مع بقية سجل مايكروسوفت المنشور: وثائق الانتقال في Windows Server تصف آليات التعايش والانتقال بين العائلتين، لا التخلي عن IPv4 (تقنيات الانتقال في Windows Server).

فما الذي يبقى من الحكاية؟ يبقى سطر واحد صغير، عملي، قابل للتنفيذ في أي قالب نشر آلي: IPv4 على كل واجهة.

لماذا واجهة الشبكة هي التفصيل الحامل للثقل

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

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

ولهذا فإن العبارة التي تبدو إدارية — "كل واجهة شبكة يجب أن تتضمن تكوين IPv4 واحداً على الأقل" — هي في الحقيقة الجملة المعمارية الوحيدة في الصفحة كلها. فهي تحدد نقطة التماس بين العميل والمنصة، وتجعل IPv4 حاضراً في كل تصميم شبكة مهما كان تطبيقه حديثاً. وما لا تقوله الوثيقة، ويجب ألا يُضاف إليها، هو نوع ذلك التكوين: هل يجب أن يكون عنواناً عاماً، أم خاصاً، أم مشتركاً، أم مُترجَماً؟ النص المصدر لا يحسم ذلك، فلا يصح أن نبني عليه رقماً ولا استنتاجاً عن عدد العناوين العامة التي يستهلكها حمل عمل متأثر.

IPv6 مجاناً وIPv4 مدفوعاً: إشارة سعرية لا تؤدي إلى شيء

هناك إشارة سعرية واضحة في التسعير: عنوان IPv6 العام مجاني، وعنوان IPv4 العام له رسم اسمي. من يقرأ الجدول وحده يستنتج أن المنصة تدفع العملاء نحو IPv6. ومن يقرأ القيد يستنتج العكس تماماً: لا يمكن للعميل أن يبني على IPv6 وحده.

الاثنان لا يتناقضان، لكنهما لا يتعاونان. الإشارة السعرية تقول "خفّف IPv4"، والقاعدة التقنية تقول "أبقِ IPv4". النتيجة أن كل واجهة شبكة تحمل عنصراً مدفوعاً لا يستطيع العميل إسقاطه، بينما تدفع المنصة ثمن جعل العائلة الأخرى مجانية. ولا يعني ذلك أن أحداً يخطط لذلك؛ يعني فقط أن التسعير والقيد يُداران كسياستين منفصلتين، وأن أثرهما المشترك لم يُصمَّم كوحدة واحدة.

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

السجل المنشور ليس الشبكة

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

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

ما يستطيع سجل ARIN قوله وما لا يستطيع

في سجل ARIN، الحساب RDAP الذي يحمل المعرّف MSFT هو نقطة التسجيل الخاصة بتسجيل مؤسسة Microsoft Corporation وموارد الإنترنت المرتبطة بها (سجل RDAP لمؤسسة MSFT). هذا تأكيد هوية، لا جرد. نص السجل الكامل ومجموعة الموارد المرتبطة به لم تُقرأ كنص في هذا العمل، لذلك لا يُنشر هنا إجمالي عناوين، ولا عدد بادئات، ولا قائمة حيازات.

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

إطار النقل نفسه جزء من الصورة: ARIN تدير إطاراً عاماً لنقل عناوين IPv4 وسجلاً يتابع انتقال العناوين المسجّلة بين المؤسسات، بما في ذلك عمليات النقل المسجّلة بعد نفاد المخزون المركزي لعناوين IPv4 (إطار نقل IPv4 لدى ARIN). وجود هذا الإطار دليل على أن العناوين صارت أصلاً قابلاً للتداول، لا على ما تملكه شركة بعينها.

صفقة نورتل 2011، ولماذا ليست التفسير

في أبريل 2011 نقلت BBC News وArs Technica أن مايكروسوفت اشترت 666,624 عنوان IPv4 من نورتل في صفقة قدّرت بنحو 7.5 مليون دولار، داخل تصفية أصول مرتبطة بإفلاس نورتل (BBC News، Ars Technica). الرقمان منقولان عن تغطية صحفية معاصرة، لا عن سجل تسجيل أو حكم قضائي قُرئ في هذا العمل. والقسمة الحسابية عليهما تعطي نحو 11.25 دولاراً للعنوان الواحد؛ هذا حساب على أرقام منشورة، وليس سعراً حددته ARIN.

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

أين يقف الانتقال فعلاً

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

حدود الأدلة هنا واضحة وتُقال مرة واحدة: لا يوجد في المصادر المقروءة تفسير من مايكروسوفت للسبب أو الجدول الزمني أو الحالة النهائية التي تستهدفها القاعدة؛ ولا قياس مستقل عبر BGP أو من نقاط نهاية العملاء لمقارنة ما يُنشر عمّا يعمل فعلاً؛ ولا سجل نقل لدى ARIN يسمّي مايكروسوفت طرفاً في 2024 أو 2025 قُرئ كنص. ما يوجد هو وثيقة منتج تحدد ما يمكن بناؤه، وصفحة تسعير تحدد ما يُحتسب، وسجل تسجيل يحدد من يملك الحساب.

ما الذي يغيّر هذه القراءة

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

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