بروتوكول الإنترنت الإصدار 6
هناك أجزاء من هذه المقالة (تلك المتعلقة بـ RFC 8200 وRFC 8201) بحاجة إلى التحديث . ( يوليو 2017 ) |
| مجموعة البروتوكولات | |
رأس IPv6 | |
| اختصار | بروتوكول الإنترنت الإصدار 6 |
|---|---|
| غاية | بروتوكول الشبكات |
| المطور(ون) | فريق عمل هندسة الإنترنت |
| مقدمة | ديسمبر 1995 |
| مرتكز على | بروتوكول الإنترنت الإصدار الرابع |
| طبقة OSI | طبقة الشبكة |
| طلبات التعليقات | 2460، 8200 |
| الجدول الزمني لتاريخ الإنترنت |
|
البحث والتطوير المبكر:
دمج الشبكات وإنشاء الإنترنت:
التسويق والخصخصة وتوسيع نطاق الوصول يؤدي إلى الإنترنت الحديث:
أمثلة على خدمات الإنترنت:
|
بروتوكول الإنترنت الإصدار 6 ( IPv6 ) هو أحدث إصدار من بروتوكول الإنترنت (IP)، وهو بروتوكول الاتصالات الذي يوفر نظام تعريف وموقع لأجهزة الكمبيوتر على الشبكات ويوجه حركة المرور عبر الإنترنت . تم تطوير IPv6 بواسطة فريق هندسة الإنترنت (IETF) للتعامل مع مشكلة استنفاد عناوين IPv4 التي طال انتظارها ، وكان من المفترض أن يحل محل IPv4 . [1] في ديسمبر 1998، أصبح IPv6 مسودة معيار لـ IETF، [2] والتي صدقت عليه لاحقًا كمعيار للإنترنت في 14 يوليو 2017. [3] [4]
يتم تخصيص عنوان IP فريد للأجهزة الموجودة على الإنترنت لتحديد الهوية وتحديد الموقع. مع النمو السريع للإنترنت بعد التسويق في التسعينيات، أصبح من الواضح أن هناك حاجة إلى عناوين أكثر بكثير لتوصيل الأجهزة مما كان متاحًا في مساحة عناوين IPv4. بحلول عام 1998، قامت IETF بإضفاء الطابع الرسمي على البروتوكول الخليفة. يستخدم IPv6 عناوين 128 بت ، مما يسمح نظريًا بـ 2 128 ، أو ما يقرب من3.4 × 10 38 عنوانًا إجماليًا. العدد الفعلي أصغر قليلاً، حيث يتم حجز نطاقات متعددة للاستخدام الخاص أو استبعادها تمامًا من الاستخدام العام. لم يتم تصميم البروتوكولين ليكونا متوافقين ، وبالتالي فإن الاتصال المباشر بينهما مستحيل، مما يعقد الانتقال إلى IPv6. ومع ذلك، تم ابتكار العديد من آليات الانتقال لتصحيح هذا.
يوفر IPv6 فوائد تقنية أخرى بالإضافة إلى مساحة أكبر للعنونة. وبشكل خاص، يسمح بأساليب تخصيص العناوين الهرمية التي تسهل تجميع المسارات عبر الإنترنت، وبالتالي تحد من توسع جداول التوجيه . كما تم توسيع وتبسيط استخدام العنونة متعددة البث، كما يوفر تحسينًا إضافيًا لتقديم الخدمات. وقد تم النظر في جوانب تنقل الأجهزة والأمان والتكوين في تصميم البروتوكول.
يتم تمثيل عناوين IPv6 على هيئة ثماني مجموعات تتكون كل منها من أربعة أرقام سداسية عشرية ، مفصولة بعلامات النقطتين. ويمكن اختصار التمثيل الكامل؛ على سبيل المثال، يصبح 2001:0db8:0000:0000:0000:8a2e:0370:7334 هو 2001:db8::8a2e:370:7334 .
المميزات الرئيسية

IPv6 هو بروتوكول طبقة الإنترنت للشبكات المترابطة بالتبديل بالحزم ويوفر نقل البيانات من البداية إلى النهاية عبر شبكات IP متعددة، مع الالتزام الوثيق بمبادئ التصميم التي تم تطويرها في الإصدار السابق من البروتوكول، بروتوكول الإنترنت الإصدار 4 (IPv4).
بالإضافة إلى تقديم المزيد من العناوين، ينفذ IPv6 أيضًا ميزات غير موجودة في IPv4. فهو يبسط جوانب تكوين العناوين وإعادة ترقيم الشبكة وإعلانات جهاز التوجيه عند تغيير موفري الاتصال بالشبكة. كما يبسط معالجة الحزم في أجهزة التوجيه من خلال وضع مسؤولية تجزئة الحزم في نقاط النهاية. يتم توحيد حجم الشبكة الفرعية IPv6 من خلال تثبيت حجم جزء معرف المضيف من العنوان إلى 64 بت.
تم تعريف بنية العنونة الخاصة بـ IPv6 في RFC 4291 وتسمح بثلاثة أنواع مختلفة من الإرسال: أحادي البث ، وأي بث ، ومتعدد البث . [5] : 210
الدافع والأصل
استنفاد عنوان IPv4

كان بروتوكول الإنترنت الإصدار الرابع (IPv4) أول إصدار يستخدمه الجمهور من بروتوكول الإنترنت . تم تطوير IPv4 كمشروع بحثي من قبل وكالة مشاريع الأبحاث الدفاعية المتقدمة (DARPA)، وهي وكالة تابعة لوزارة الدفاع الأمريكية ، قبل أن يصبح الأساس للإنترنت والويب العالمي . يتضمن IPv4 نظام عنونة يستخدم معرفات رقمية تتكون من 32 بت. يتم عرض هذه العناوين عادةً في تدوين النقاط العشرية كقيم عشرية من أربعة أوكتات، كل منها في النطاق من 0 إلى 255، أو 8 بتات لكل رقم. وبالتالي، يوفر IPv4 إمكانية عنونة تبلغ 2 32 أو ما يقرب من 4.3 مليار عنوان. لم يكن استنفاد العناوين مصدر قلق في البداية في IPv4 حيث كان من المفترض في الأصل أن يكون هذا الإصدار بمثابة اختبار لمفاهيم الشبكات الخاصة بوكالة مشاريع الأبحاث الدفاعية المتقدمة. [6] خلال العقد الأول من تشغيل الإنترنت، أصبح من الواضح أنه يجب تطوير أساليب للحفاظ على مساحة العناوين. في أوائل تسعينيات القرن العشرين، وحتى بعد إعادة تصميم نظام العناوين باستخدام نموذج الشبكة بلا فئات ، أصبح من الواضح أن هذا لن يكون كافياً لمنع استنفاد عنوان IPv4 ، وأن هناك حاجة إلى مزيد من التغييرات في البنية التحتية للإنترنت. [7]
تم تخصيص آخر كتل عناوين المستوى الأعلى غير المخصصة والتي يبلغ عددها 16 مليون عنوان IPv4 في فبراير 2011 من قبل هيئة أرقام الإنترنت المخصصة (IANA) لسجلات الإنترنت الإقليمية الخمسة (RIRs). [8] ومع ذلك، لا يزال لدى كل RIR مجموعات عناوين متاحة ومن المتوقع أن يستمر في سياسات تخصيص العناوين القياسية حتى تبقى كتلة توجيه بين المجالات بدون فئات (CIDR) واحدة /8 . بعد ذلك، سيتم توفير كتل فقط من 1024 عنوانًا (/22) من سجلات الإنترنت المحلية (LIR) من سجلات الإنترنت المحلية (LIR). اعتبارًا من سبتمبر 2015، وصل مركز معلومات شبكة آسيا والمحيط الهادئ (APNIC) ومركز تنسيق شبكة Réseaux IP Européens (RIPE NCC) ومركز معلومات شبكة أمريكا اللاتينية ومنطقة البحر الكاريبي (LACNIC) والسجل الأمريكي لأرقام الإنترنت (ARIN) إلى هذه المرحلة. [9] [10] [11] وهذا يجعل مركز معلومات الشبكة الأفريقية (AFRINIC) هو سجل الإنترنت الإقليمي الوحيد الذي لا يزال يستخدم البروتوكول العادي لتوزيع عناوين IPv4. اعتبارًا من نوفمبر 2018، فإن الحد الأدنى لتخصيص AFRINIC هو /22 أو 1024 عنوان IPv4. قد يتلقى مركز معلومات الشبكة الأفريقية تخصيصًا إضافيًا عندما يتم استخدام حوالي 80٪ من إجمالي مساحة العنوان. [12]
أعلنت RIPE NCC أنها نفدت عناوين IPv4 بالكامل في 25 نوفمبر 2019، [13] ودعت إلى إحراز تقدم أكبر في اعتماد IPv6.
مقارنة مع IPv4
على الإنترنت، يتم نقل البيانات في شكل حزم شبكة . يحدد IPv6 تنسيق حزمة جديد ، مصمم لتقليل معالجة رأس الحزمة بواسطة أجهزة التوجيه. [2] [14] نظرًا لأن رؤوس حزم IPv4 وحزم IPv6 مختلفة بشكل كبير، فإن البروتوكولين غير متوافقين. ومع ذلك، فإن معظم بروتوكولات طبقة النقل والتطبيق تحتاج إلى القليل من التغيير أو لا تحتاج إلى أي تغيير للعمل عبر IPv6؛ الاستثناءات هي بروتوكولات التطبيق التي تدمج عناوين طبقة الإنترنت، مثل بروتوكول نقل الملفات (FTP) وبروتوكول وقت الشبكة (NTP)، حيث قد يتسبب تنسيق العنوان الجديد في حدوث تعارضات مع بناء جملة البروتوكول الحالي.
مساحة عنوان أكبر
الميزة الرئيسية لـ IPv6 على IPv4 هي مساحة العنوان الأكبر. يبلغ حجم عنوان IPv6 128 بت، مقارنة بـ 32 بت في IPv4. [2] وبالتالي فإن مساحة العنوان تحتوي على 2 128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 عنوانًا (340 أونديسيليون ، تقريبًا3.4 × 10 38 ). يتم حجز بعض كتل هذه المساحة وبعض العناوين المحددة لاستخدامات خاصة .
في حين أن مساحة العنوان هذه كبيرة جدًا، لم يكن من نية مصممي IPv6 ضمان التشبع الجغرافي بالعناوين القابلة للاستخدام. بدلاً من ذلك، تعمل العناوين الأطول على تبسيط تخصيص العناوين وتمكين تجميع المسارات بكفاءة والسماح بتنفيذ ميزات عناوين خاصة. في IPv4، تم تطوير طرق توجيه بين المجالات بدون فئات (CIDR) معقدة لتحقيق أفضل استخدام لمساحة العنوان الصغيرة. الحجم القياسي للشبكة الفرعية في IPv6 هو 2 64 عنوانًا، أي حوالي أربعة مليارات ضعف حجم مساحة عنوان IPv4 بالكامل. وبالتالي، سيكون استخدام مساحة العنوان الفعلية صغيرًا في IPv6، ولكن يتم تحسين إدارة الشبكة وكفاءة التوجيه من خلال مساحة الشبكة الفرعية الكبيرة وتجميع المسارات الهرمية.
البث المتعدد

يعد الإرسال المتعدد ، وهو إرسال حزمة إلى وجهات متعددة في عملية إرسال واحدة، جزءًا من المواصفات الأساسية في IPv6. في IPv4، تعد هذه ميزة اختيارية (على الرغم من تنفيذها بشكل شائع). [15] تحتوي عناوين الإرسال المتعدد IPv6 على ميزات وبروتوكولات مشتركة مع الإرسال المتعدد IPv4، ولكنها توفر أيضًا تغييرات وتحسينات من خلال التخلص من الحاجة إلى بروتوكولات معينة. لا ينفذ IPv6 البث IP التقليدي ، أي إرسال حزمة إلى جميع المضيفين على الرابط المرفق باستخدام عنوان بث خاص ، وبالتالي لا يحدد عناوين البث. في IPv6، يتم تحقيق نفس النتيجة عن طريق إرسال حزمة إلى مجموعة الإرسال المتعدد المحلية لجميع العقد على العنوان ff02::1، وهو ما يشبه الإرسال المتعدد IPv4 إلى العنوان 224.0.0.1. يوفر IPv6 أيضًا تنفيذات إرسال متعدد جديدة، بما في ذلك تضمين عناوين نقاط الالتقاء في عنوان مجموعة الإرسال المتعدد IPv6، مما يبسط نشر حلول بين النطاقات. [16]
في IPv4، من الصعب جدًا على أي منظمة الحصول على تعيين واحد لمجموعة متعددة البث قابلة للتوجيه عالميًا، وتنفيذ حلول بين المجالات أمر غامض. [17] تحتوي تعيينات عناوين أحادية البث بواسطة سجل إنترنت محلي لـ IPv6 على بادئة توجيه 64 بت على الأقل، مما ينتج عنه أصغر حجم شبكة فرعية متاح في IPv6 (64 بت أيضًا). مع مثل هذا التعيين، من الممكن تضمين بادئة عنوان أحادي البث في تنسيق عنوان متعدد البث IPv6، مع الاستمرار في توفير كتلة 32 بت، أو أقل بتات العنوان أهمية، أو ما يقرب من 4.2 مليار معرف لمجموعة متعددة البث. وبالتالي، يتوفر لكل مستخدم لشبكة فرعية IPv6 تلقائيًا مجموعة من مجموعات متعددة البث قابلة للتوجيه عالميًا ومحددة المصدر لتطبيقات متعددة البث. [18]
تكوين تلقائي لعنوان بدون جنسية (SLAAC)
يقوم مضيفو IPv6 بتكوين أنفسهم تلقائيًا. تحتوي كل واجهة على عنوان ارتباط محلي تم إنشاؤه ذاتيًا، وعند الاتصال بشبكة، يتم تنفيذ حل التعارض وتوفر أجهزة التوجيه بادئات الشبكة عبر إعلانات جهاز التوجيه. [19] يمكن تحقيق تكوين بدون جنسية لأجهزة التوجيه باستخدام بروتوكول إعادة ترقيم جهاز توجيه خاص. [20] عند الضرورة، قد يقوم المضيفون بتكوين عناوين حالة إضافية عبر بروتوكول تكوين المضيف الديناميكي الإصدار 6 (DHCPv6) أو عناوين ثابتة يدويًا.
مثل IPv4، يدعم IPv6 عناوين IP فريدة عالميًا . كان تصميم IPv6 يهدف إلى إعادة التأكيد على مبدأ النهاية إلى النهاية لتصميم الشبكة الذي تم تصوره في الأصل أثناء إنشاء الإنترنت المبكر من خلال جعل ترجمة عناوين الشبكة قديمة. وبالتالي، يمكن توجيه كل جهاز على الشبكة عالميًا مباشرةً من أي جهاز آخر.
إن وجود عنوان IP ثابت وفريد وقابل للتوجيه عالميًا من شأنه أن يسهل تتبع الجهاز عبر الشبكات. لذلك، تشكل مثل هذه العناوين مصدر قلق خاص فيما يتعلق بالخصوصية للأجهزة المحمولة، مثل أجهزة الكمبيوتر المحمولة والهواتف الخلوية. [21] لمعالجة مخاوف الخصوصية هذه، يتضمن بروتوكول SLAAC ما يسمى عادةً "عناوين الخصوصية" أو بشكل أكثر دقة "العناوين المؤقتة". [22] العناوين المؤقتة عشوائية وغير مستقرة. يولد جهاز المستهلك النموذجي عنوانًا مؤقتًا جديدًا يوميًا ويتجاهل حركة المرور الموجهة إلى عنوان قديم بعد أسبوع واحد. يتم استخدام العناوين المؤقتة افتراضيًا بواسطة Windows منذ XP SP1، [23] وmacOS منذ (Mac OS X) 10.7، وAndroid منذ 4.0، وiOS منذ الإصدار 4.3. يختلف استخدام العناوين المؤقتة بواسطة توزيعات Linux. [24]
إن إعادة ترقيم شبكة موجودة لمزود اتصال جديد باستخدام بادئات توجيه مختلفة يعد جهدًا كبيرًا مع IPv4. [25] [26] [27] ومع IPv6، فإن تغيير البادئة المعلن عنها بواسطة عدد قليل من أجهزة التوجيه يمكن أن يؤدي من حيث المبدأ إلى إعادة ترقيم شبكة بأكملها، حيث يمكن تكوين معرفات المضيف (أقل 64 بت أهمية في العنوان) بشكل مستقل بواسطة المضيف. [19]
تعتمد طريقة توليد عنوان SLAAC على التنفيذ. توصي IETF بأن تكون العناوين حتمية ولكن غير شفافة دلاليًا. [28]
بروتوكول الإنترنت الآمن
تم تطوير أمان بروتوكول الإنترنت (IPsec) في الأصل لـ IPv6، ولكن تم نشره على نطاق واسع أولاً في IPv4، والذي تمت إعادة تصميمه من أجله. كان IPsec جزءًا إلزاميًا من جميع تطبيقات بروتوكول IPv6، [2] وتم التوصية بتبادل مفاتيح الإنترنت (IKE)، ولكن مع RFC 6434 تم تخفيض إدراج IPsec في تطبيقات IPv6 إلى توصية لأنه كان من غير العملي طلب تنفيذ IPsec الكامل لجميع أنواع الأجهزة التي قد تستخدم IPv6. ومع ذلك، اعتبارًا من RFC 4301، تحتاج تطبيقات بروتوكول IPv6 التي تنفذ IPsec إلى تنفيذ IKEv2 وتحتاج إلى دعم مجموعة دنيا من خوارزميات التشفير . سيساعد هذا المطلب في جعل تطبيقات IPsec أكثر قابلية للتشغيل المتبادل بين الأجهزة من بائعين مختلفين. يتم تنفيذ رأس مصادقة IPsec (AH) ورأس الحمولة الأمنية المغلفة (ESP) كرؤوس تمديد IPv6. [29]
معالجة مبسطة بواسطة أجهزة التوجيه
رأس الحزمة في IPv6 أبسط من رأس IPv4. تم نقل العديد من الحقول النادرة الاستخدام إلى ملحقات رأس اختيارية. لقد عمل رأس حزمة IPv6 على تبسيط عملية إعادة توجيه الحزمة بواسطة أجهزة التوجيه . على الرغم من أن رؤوس حزم IPv6 أكبر مرتين على الأقل من رؤوس حزم IPv4، إلا أن معالجة الحزم التي تحتوي فقط على رأس IPv6 الأساسي بواسطة أجهزة التوجيه قد تكون أكثر كفاءة في بعض الحالات، لأن المعالجة المطلوبة في أجهزة التوجيه أقل بسبب محاذاة الرؤوس لتتناسب مع أحجام الكلمات الشائعة . [2] [14] ومع ذلك، فإن العديد من الأجهزة تنفذ دعم IPv6 في البرامج (على عكس الأجهزة)، مما يؤدي إلى أداء معالجة حزم سيئ للغاية. [30] بالإضافة إلى ذلك، بالنسبة للعديد من التطبيقات، يتسبب استخدام رؤوس الامتداد في معالجة الحزم بواسطة وحدة المعالجة المركزية لجهاز التوجيه، مما يؤدي إلى ضعف الأداء أو حتى مشكلات الأمان. [31]
علاوة على ذلك، لا يتضمن رأس IPv6 مجموع اختباري. يتم حساب مجموع اختبار رأس IPv4 لرأس IPv4، ويجب إعادة حسابه بواسطة أجهزة التوجيه في كل مرة يتم فيها تقليل وقت البقاء (يُسمى حد القفزة في بروتوكول IPv6) بمقدار واحد. إن غياب مجموع اختباري في رأس IPv6 يعزز مبدأ النهاية إلى النهاية لتصميم الإنترنت، والذي تصور أن معظم المعالجة في الشبكة تحدث في العقد الورقية. يُفترض أن حماية سلامة البيانات المغلفة في حزمة IPv6 مضمونة من خلال كل من طبقة الارتباط أو اكتشاف الأخطاء في بروتوكولات الطبقة الأعلى، وهي بروتوكول التحكم في الإرسال (TCP) وبروتوكول بيانات المستخدم (UDP) على طبقة النقل . وبالتالي، بينما يسمح IPv4 لرؤوس بيانات UDP بعدم وجود مجموع اختباري (يشار إليه بالرقم 0 في حقل الرأس)، فإن IPv6 يتطلب مجموع اختباري في رؤوس UDP.
لا تقوم أجهزة توجيه IPv6 بتجزئة IP . يتعين على مضيفات IPv6 القيام بأحد الإجراءات التالية: إجراء اكتشاف Path MTU ، أو إجراء تجزئة من البداية إلى النهاية، أو إرسال حزم لا يزيد حجمها عن وحدة الإرسال القصوى الافتراضية (MTU)، والتي تبلغ 1280 أوكتيت .
الحركة
على عكس IPv4 المحمول، يتجنب IPv6 المحمول التوجيه المثلثي وبالتالي فهو بنفس كفاءة IPv6 الأصلي. قد تسمح أجهزة توجيه IPv6 أيضًا لشبكات فرعية كاملة بالانتقال إلى نقطة اتصال جهاز توجيه جديدة دون إعادة الترقيم. [32]
عناوين الامتداد

يبلغ الحد الأدنى لحجم رأس حزمة IPv6 40 أوكتيت (320 بت). يتم تنفيذ الخيارات كامتدادات. يوفر هذا الفرصة لتوسيع البروتوكول في المستقبل دون التأثير على بنية الحزمة الأساسية. [2] ومع ذلك، يلاحظ RFC 7872 أن بعض مشغلي الشبكة يسقطون حزم IPv6 ذات رؤوس الامتداد عندما يعبرون أنظمة النقل المستقلة .
جامبوجرام
يحدد IPv4 الحزم بـ 65,535 (2 16 −1) أوكتيت من الحمولة. يمكن لعقدة IPv6 التعامل بشكل اختياري مع الحزم التي تتجاوز هذا الحد، والتي يشار إليها باسم jumbograms ، والتي يمكن أن يصل حجمها إلى 4,294,967,295 (2 32 −1) أوكتيت. قد يؤدي استخدام jumbograms إلى تحسين الأداء عبر الروابط ذات MTU العالية . يُشار إلى استخدام jumbograms بواسطة رأس امتداد خيار Jumbo Payload. [33]
حزم IPv6

تحتوي حزمة IPv6 على جزأين : الرأس والحمولة .
يتكون الرأس من جزء ثابت مع الحد الأدنى من الوظائف المطلوبة لجميع الحزم ويمكن أن يتبعه ملحقات اختيارية لتنفيذ ميزات خاصة.
يشغل الرأس الثابت أول 40 أوكتيت (320 بت) من حزمة IPv6. ويحتوي على عناوين المصدر والوجهة وفئة حركة المرور وعدد القفزات ونوع الامتداد الاختياري أو الحمولة التي تتبع الرأس. يخبر حقل الرأس التالي المتلقي بكيفية تفسير البيانات التي تتبع الرأس. إذا كانت الحزمة تحتوي على خيارات، فإن هذا الحقل يحتوي على نوع الخيار للخيار التالي. يشير حقل "الرأس التالي" للخيار الأخير إلى بروتوكول الطبقة العليا الذي يتم حمله في حمولة الحزمة .
يقسم الاستخدام الحالي لحقل فئة حركة مرور IPv6 هذا بين نقطة رمز الخدمات المميزة المكونة من 6 بتات [34] وحقل إشعار الازدحام الصريح المكون من 2 بت . [35]
تحمل رؤوس الامتداد خيارات تُستخدم في المعالجة الخاصة للحزمة في الشبكة، على سبيل المثال، للتوجيه، والتجزئة، وللأمان باستخدام إطار عمل IPsec .
بدون خيارات خاصة، يجب أن يكون حجم الحمولة أقل من 64 كيلو بايت . مع خيار الحمولة الضخمة (في رأس امتداد خيارات Hop-By-Hop )، يجب أن يكون حجم الحمولة أقل من 4 جيجابايت.
على عكس IPv4، لا تقوم أجهزة التوجيه بتجزئة الحزمة مطلقًا. ومن المتوقع أن يستخدم المضيفون Path MTU Discovery لجعل حزمهم صغيرة بما يكفي للوصول إلى الوجهة دون الحاجة إلى تجزئة الحزمة. راجع تجزئة حزمة IPv6 .
معالجة

تحتوي عناوين IPv6 على 128 بت. ينفذ تصميم مساحة عنوان IPv6 فلسفة تصميم مختلفة عن تلك الموجودة في IPv4، حيث تم استخدام تقسيم الشبكات الفرعية لتحسين كفاءة استخدام مساحة العنوان الصغيرة. في IPv6، تعتبر مساحة العنوان كبيرة بما يكفي للمستقبل المنظور، وتستخدم الشبكة الفرعية للمنطقة المحلية دائمًا 64 بتًا لجزء المضيف من العنوان، والذي يتم تعيينه كمعرف للواجهة، بينما يتم استخدام 64 بت الأكثر أهمية كبادئة للتوجيه. [36] : 9 بينما كانت الأسطورة موجودة فيما يتعلق باستحالة مسح شبكات IPv6 الفرعية، يلاحظ RFC 7707 أن الأنماط الناتجة عن بعض تقنيات وخوارزميات تكوين عنوان IPv6 تسمح بمسح العناوين في العديد من السيناريوهات الواقعية.
تمثيل العنوان
يتم تمثيل 128 بتًا من عنوان IPv6 في 8 مجموعات كل منها 16 بتًا. تتم كتابة كل مجموعة على هيئة أربعة أرقام سداسية عشرية (تسمى أحيانًا سداسية عشرية [37] [38] أو رسميًا سداسية عشرية [39] وبشكل غير رسمي quibble أو quad-nibble [39] ) ويتم فصل المجموعات بعلامات النقطتين (:). ومن الأمثلة على هذا التمثيل 2001:0db8:0000:0000:0000:ff00:0042:8329 .
من أجل الراحة والوضوح، من الممكن اختصار تمثيل عنوان IPv6 بالقواعد التالية:
- يتم إزالة واحد أو أكثر من الأصفار الأولية من أي مجموعة من الأرقام السداسية عشرية، وهو ما يتم عادةً لجميع الأصفار الأولية. على سبيل المثال، يتم تحويل المجموعة 0042 إلى 42. يتم تحويل المجموعة 0000 إلى 0 .
- يتم استبدال الأقسام المتتالية من الأصفار بعلامتي نقطتين (::). لا يجوز استخدام هذا إلا مرة واحدة في العنوان، حيث أن الاستخدام المتكرر من شأنه أن يجعل العنوان غير محدد. لا ينبغي استخدام علامتي نقطتين للإشارة إلى قسم واحد محذوف من الأصفار. [40] : §4.2.2
مثال على تطبيق هذه القواعد:
- العنوان الأولي: 2001:0db8:0000:0000:0000:ff00:0042:8329 .
- بعد إزالة جميع الأصفار الأولية في كل مجموعة: 2001:db8:0:0:0:ff00:42:8329 .
- بعد حذف الأقسام المتتالية من الأصفار: 2001:db8::ff00:42:8329 .
يتم تعريف عنوان الحلقة الراجعة على أنه 0000:0000:0000:0000:0000:0000:0001 [41] ويتم اختصاره إلى ::1 باستخدام كلتا القاعدتين.
نظرًا لأن عنوان IPv6 قد يكون له أكثر من تمثيل، فقد أصدرت IETF معيارًا مقترحًا لتمثيلها في النص . [40]
نظرًا لأن عناوين IPv6 تحتوي على نقطتين، وتستخدم عناوين URL نقطتين لفصل المضيف عن رقم المنفذ، فيجب وضع عنوان IPv6 المستخدم كجزء مضيف من عنوان URL بين قوسين مربعين، [42] على سبيل المثال http://[2001:db8:4006:812::200e] أو http://[2001:db8:4006:812::200e]:8080/path/page.html.
عنوان الرابط المحلي

تتطلب جميع واجهات مضيفات IPv6 عنوان ارتباط محلي ، والذي يحتوي على البادئة fe80:: / 10. يتبع هذه البادئة 54 بتًا يمكن استخدامها للتقسيم إلى شبكات فرعية، على الرغم من أنها عادةً ما تكون مضبوطة على الأصفار، ومعرف واجهة مكون من 64 بتًا. يمكن للمضيف حساب وتعيين معرف الواجهة بنفسه دون وجود أو تعاون مكون شبكة خارجي مثل خادم DHCP، في عملية تسمى التكوين التلقائي لعنوان الارتباط المحلي . [ بحاجة لمصدر ]
تم اشتقاق البتات الـ 64 السفلية من عنوان الرابط المحلي (اللاحقة) في الأصل من عنوان MAC لبطاقة واجهة الشبكة الأساسية. ونظرًا لأن طريقة تعيين العناوين هذه قد تتسبب في حدوث تغييرات غير مرغوب فيها في العناوين عند استبدال بطاقات الشبكة المعيبة، ونظرًا لأنها عانت أيضًا من عدد من مشكلات الأمان والخصوصية، فقد استبدلت RFC 8064 الطريقة الأصلية القائمة على MAC بالطريقة القائمة على التجزئة المحددة في RFC 7217. [ بحاجة لمصدر ]
تفرد العنوان وطلب جهاز التوجيه
يستخدم IPv6 آلية جديدة لتعيين عناوين IP إلى عناوين طبقة الارتباط (على سبيل المثال عناوين MAC )، لأنه لا يدعم طريقة عنونة البث ، والتي تعتمد عليها وظيفة بروتوكول حل العناوين (ARP) في IPv4. ينفذ IPv6 بروتوكول اكتشاف الجيران (NDP، ND) في طبقة الارتباط ، والذي يعتمد على ICMPv6 ونقل البث المتعدد . [5] : 210 تتحقق مضيفات IPv6 من تفرد عناوين IPv6 الخاصة بها في شبكة المنطقة المحلية (LAN) عن طريق إرسال رسالة طلب جيران تطلب عنوان طبقة الارتباط لعنوان IP. إذا كان أي مضيف آخر في شبكة المنطقة المحلية يستخدم هذا العنوان، فإنه يستجيب. [43]
يقوم المضيف الذي يقوم بتشغيل واجهة IPv6 جديدة أولاً بإنشاء عنوان محلي فريد للارتباط باستخدام إحدى الآليات العديدة المصممة لإنشاء عنوان فريد. في حالة اكتشاف عنوان غير فريد، يمكن للمضيف المحاولة مرة أخرى باستخدام عنوان تم إنشاؤه حديثًا. بمجرد إنشاء عنوان محلي فريد للارتباط، يحدد مضيف IPv6 ما إذا كانت شبكة LAN متصلة على هذا الارتباط بأي واجهة موجه تدعم IPv6. يفعل ذلك عن طريق إرسال رسالة طلب موجه ICMPv6 إلى مجموعة البث المتعدد لجميع الموجهات [44] مع عنوان الرابط المحلي الخاص بها كمصدر. إذا لم يكن هناك إجابة بعد عدد محدد مسبقًا من المحاولات، يستنتج المضيف أنه لا توجد أجهزة توجيه متصلة. إذا حصل على استجابة، تُعرف باسم إعلان الموجه، من الموجه، تتضمن الاستجابة معلومات تكوين الشبكة للسماح بإنشاء عنوان فريد عالميًا مع بادئة شبكة أحادية البث مناسبة. [45] هناك أيضًا بتان علم تخبران المضيف ما إذا كان يجب عليه استخدام DHCP للحصول على مزيد من المعلومات والعناوين:
- بت الإدارة، الذي يشير إلى ما إذا كان ينبغي على المضيف استخدام DHCP للحصول على عناوين إضافية أم لا بدلاً من الاعتماد على عنوان تم تكوينه تلقائيًا من إعلان جهاز التوجيه.
- البت الآخر، الذي يشير إلى ما إذا كان ينبغي للمضيف الحصول على معلومات أخرى عبر DHCP أم لا. تتكون المعلومات الأخرى من خيار واحد أو أكثر من خيارات معلومات البادئة للشبكات الفرعية التي يرتبط بها المضيف، ومدة حياة البادئة، وعلمين: [43]
- على الرابط: إذا تم تعيين هذا العلم، فسوف يعامل المضيف جميع العناوين على الشبكة الفرعية المحددة على أنها على رابط ويرسل الحزم مباشرة إليها بدلاً من إرسالها إلى جهاز توجيه طوال مدة العمر المحدد.
- العنوان: يخبر هذا العلم المضيف بإنشاء عنوان عالمي فعليًا.
العنونة العالمية

إن إجراء التعيين للعناوين العالمية يشبه إنشاء العناوين المحلية. يتم توفير البادئة من إعلانات جهاز التوجيه على الشبكة. تتسبب إعلانات البادئة المتعددة في تكوين عناوين متعددة. [43]
يتطلب تكوين عنوان عديم الجنسية تلقائيًا (SLAAC) كتلة عنوان / 64. [36] يتم تعيين سجلات الإنترنت المحلية على الأقل / 32 كتلة، والتي تقسمها بين الشبكات التابعة. [46] ذكرت التوصية الأولية لشهر سبتمبر 2001 تعيين شبكة فرعية / 48 لمواقع المستهلك النهائي. [47] في مارس 2011 تم تحسين هذه التوصية: [48] توصي IETF " بإعطاء المواقع الرئيسية أكثر بكثير من / 64 واحدة ، لكنها لا توصي بإعطاء كل موقع رئيسي / 48 أيضًا". يتم النظر في كتل / 56 ثانية على وجه التحديد. يبقى أن نرى ما إذا كان مزودو خدمة الإنترنت سيحترمون هذه التوصية. على سبيل المثال، أثناء التجارب الأولية، تم منح عملاء Comcast شبكة / 64 واحدة . [49]
IPv6 في نظام اسم النطاق
في نظام اسم المجال (DNS)، يتم تعيين أسماء المضيفين إلى عناوين IPv6 بواسطة سجلات موارد AAAA ("quad-A"). بالنسبة للحل العكسي ، خصصت IETF المجال ip6.arpa ، حيث يتم تقسيم مساحة الاسم بشكل هرمي بواسطة التمثيل السداسي عشر المكون من رقم واحد لوحدات nibble (4 بتات) لعنوان IPv6. تم تعريف هذا المخطط في RFC 3596.
عندما يستفسر مضيف ثنائي المكدس من خادم DNS لحل اسم المجال المؤهل بالكامل (FQDN)، يرسل عميل DNS للمضيف طلبين DNS، أحدهما يستفسر عن سجلات A والآخر يستفسر عن سجلات AAAA. يمكن تكوين نظام تشغيل المضيف مع تفضيل لقواعد اختيار العنوان RFC 6724. [50]
تم استخدام نوع سجل بديل في تطبيقات DNS المبكرة لـ IPv6، والذي تم تصميمه لتسهيل إعادة ترقيم الشبكة، وسجلات A6 للبحث الأمامي وعدد من الابتكارات الأخرى مثل تسميات سلسلة البتات وسجلات DNAME . تم تعريفه في RFC 2874 ومراجعه (مع مناقشة إضافية لمزايا وعيوب كلا المخططين في RFC 3364)، ولكن تم إيقافه إلى حالة تجريبية ( RFC 3363).
آليات الانتقال
لا يُتوقع أن يحل IPv6 محل IPv4 على الفور. سيستمر كلا البروتوكولين في العمل في وقت واحد لبعض الوقت. لذلك، هناك حاجة إلى آليات انتقال IPv6 لتمكين مضيفات IPv6 من الوصول إلى خدمات IPv4 والسماح لمضيفات وشبكات IPv6 المعزولة بالوصول إلى بعضها البعض عبر البنية الأساسية لـ IPv4. [51]
وفقًا لسيلفيا هاجن ، فإن التنفيذ المزدوج لبروتوكول IPv4 وبروتوكول IPv6 على الأجهزة هو أسهل طريقة للانتقال إلى IPv6. [52] تستخدم العديد من آليات الانتقال الأخرى النفق لتغليف حركة مرور IPv6 داخل شبكات IPv4 والعكس صحيح. هذا حل غير مثالي، يقلل من وحدة الإرسال القصوى (MTU) للرابط وبالتالي يعقد اكتشاف Path MTU ، وقد يزيد من زمن الوصول . [53] [54]
تنفيذ بروتوكول الإنترنت ثنائي المكدس
توفر تطبيقات IP ثنائية المكدس مجموعات كاملة من بروتوكولات IPv4 وIPv6 في نظام التشغيل الخاص بجهاز الكمبيوتر أو جهاز الشبكة فوق تطبيق الطبقة المادية المشترك ، مثل Ethernet . وهذا يسمح للمضيفين ثنائي المكدس بالمشاركة في شبكات IPv6 وIPv4 في وقت واحد. [55]
يحتوي الجهاز الذي يعمل بنظام التشغيل ثنائي المكدس على عنوان IPv4 وIPv6، ويمكنه التواصل مع العقد الأخرى في شبكة LAN أو الإنترنت باستخدام IPv4 أو IPv6. يستخدم بروتوكول DNS من قبل بروتوكولي IP لحل أسماء النطاقات المؤهلة بالكامل وعناوين IP، لكن المكدس المزدوج يتطلب أن يكون خادم DNS الذي يحل كلا النوعين من العناوين قادرًا على حلها. يحتفظ خادم DNS ثنائي المكدس بعناوين IPv4 في سجلات A وعناوين IPv6 في سجلات AAAA. اعتمادًا على الوجهة المراد حلها، قد يعيد خادم اسم DNS عنوان IP من نوع IPv4 أو IPv6، أو كليهما. يجب تكوين آلية اختيار عنوان افتراضي، أو بروتوكول مفضل، إما على المضيفين أو خادم DNS. نشر IETF Happy Eyeballs لمساعدة تطبيقات المكدس المزدوج، بحيث يمكنها الاتصال باستخدام كل من IPv4 وIPv6، لكنها تفضل اتصال IPv6 إذا كان متاحًا. ومع ذلك، يلزم أيضًا تنفيذ المكدس المزدوج على جميع أجهزة التوجيه بين المضيف والخدمة التي أعاد لها خادم DNS عنوان IPv6. يجب تكوين عملاء المكدس المزدوج لتفضيل IPv6 فقط إذا كانت الشبكة قادرة على إعادة توجيه حزم IPv6 باستخدام إصدارات IPv6 من بروتوكولات التوجيه . عندما تكون بروتوكولات الشبكة ذات المكدس المزدوج جاهزة، يمكن ترحيل طبقة التطبيق إلى IPv6. [56]
في حين أن أنظمة التشغيل الرئيسية وبائعي أجهزة الشبكة يدعمون المكدس المزدوج ، فإن أجهزة الشبكات والخوادم القديمة لا تدعم IPv6.
عملاء مزودي خدمة الإنترنت الذين يستخدمون IPv6 الموجه للجمهور

يقدم مزودو خدمة الإنترنت (ISPs) بشكل متزايد لعملائهم من الشركات والأفراد عناوين IPv6 أحادية البث العالمية الموجهة للجمهور. ومع ذلك، إذا كان IPv4 لا يزال مستخدمًا في شبكة المنطقة المحلية (LAN)، وكان مزود خدمة الإنترنت قادرًا فقط على توفير عنوان IPv6 واحد موجه للجمهور، يتم ترجمة عناوين LAN IPv4 إلى عنوان IPv6 الموجه للجمهور باستخدام NAT64 ، وهي آلية ترجمة عناوين الشبكة (NAT). لا يمكن لبعض مزودي خدمة الإنترنت تزويد عملائهم بعناوين IPv4 وIPv6 الموجهة للجمهور، وبالتالي دعم الشبكات ثنائية المكدس، لأن بعض مزودي خدمة الإنترنت استنفدوا مجموعة عناوين IPv4 القابلة للتوجيه عالميًا. وفي الوقت نفسه، لا يزال عملاء مزودي خدمة الإنترنت يحاولون الوصول إلى خوادم الويب IPv4 والوجهات الأخرى. [57]
حصلت نسبة كبيرة من مزودي خدمة الإنترنت في جميع مناطق تسجيل الإنترنت الإقليمية (RIR) على مساحة عناوين IPv6. ويشمل ذلك العديد من مزودي خدمة الإنترنت الرئيسيين ومشغلي شبكات الهاتف المحمول في العالم ، مثل Verizon Wireless و StarHub Cable و Chubu Telecommunications و Kabel Deutschland و Swisscom و T-Mobile و Internode و Telefónica . [58]
في حين لا يزال بعض مزودي خدمة الإنترنت يخصصون للعملاء عناوين IPv4 فقط، فإن العديد من مزودي خدمة الإنترنت يخصصون لعملائهم IPv6 أو IPv4 ثنائي المكدس وIPv6 فقط. أفاد مزودو خدمة الإنترنت أن حصة حركة مرور IPv6 من العملاء عبر شبكتهم تتراوح بين 20٪ و 40٪، ولكن بحلول منتصف عام 2017، لا تزال حركة مرور IPv6 تمثل جزءًا ضئيلًا فقط من إجمالي حركة المرور في العديد من نقاط تبادل الإنترنت الكبيرة (IXPs). أفادت AMS-IX أنها 2٪ وأفادت SeattleIX أنها 7٪. وجد استطلاع عام 2017 أن العديد من عملاء DSL الذين خدمهم مزود خدمة إنترنت ثنائي المكدس لم يطلبوا من خوادم DNS حل أسماء النطاقات المؤهلة بالكامل إلى عناوين IPv6. وجد الاستطلاع أيضًا أن غالبية حركة المرور من موارد خادم الويب الجاهزة لـ IPv6 لا تزال مطلوبة ومقدمة عبر IPv4، ويرجع ذلك في الغالب إلى عملاء مزودي خدمة الإنترنت الذين لم يستخدموا مرفق المكدس المزدوج الذي يوفره مزود خدمة الإنترنت الخاص بهم وإلى حد أقل بسبب عملاء مزودي خدمة الإنترنت IPv4 فقط. [59]
حفر الأنفاق
تم توضيح الأساس الفني للنفق، أو تغليف حزم IPv6 في حزم IPv4، في RFC 4213. عندما كان العمود الفقري للإنترنت IPv4 فقط، كان أحد بروتوكولات الأنفاق المستخدمة بشكل متكرر هو 6to4 . [60] كما تم استخدام نفق Teredo بشكل متكرر لدمج شبكات LAN IPv6 مع العمود الفقري للإنترنت IPv4. تم توضيح Teredo في RFC 4380 ويسمح لشبكات المنطقة المحلية IPv6 بالنفق عبر شبكات IPv4، من خلال تغليف حزم IPv6 داخل UDP. يعد مرحل Teredo جهاز توجيه IPv6 يتوسط بين خادم Teredo وشبكة IPv6 الأصلية. كان من المتوقع أن يتم نشر 6to4 و Teredo على نطاق واسع حتى تتحول شبكات مزود خدمة الإنترنت إلى IPv6 الأصلي، ولكن بحلول عام 2014 أظهرت إحصائيات Google أن استخدام كلتا الآليتين انخفض إلى ما يقرب من 0. [61]
عناوين IPv6 المتوافقة مع IPv4


تتعرف تطبيقات IPv6/IPv4 الهجينة ثنائية المكدس على فئة خاصة من العناوين، عناوين IPv6 المخصصة لـ IPv4. [62] : §2.2.3 [36] تُكتب هذه العناوين عادةً ببادئة مكونة من 96 بت بتنسيق IPv6 القياسي، وتُكتب البتات الـ 32 المتبقية بنظام النقاط العشري المعتاد لـ IPv4.
تتكون العناوين في هذه المجموعة من بادئة مكونة من 80 بتًا من الأصفار، والبتات الستة عشر التالية هي الواحدات، والبتات الـ 32 المتبقية الأقل أهمية تحتوي على عنوان IPv4. على سبيل المثال، يمثل ::ffff:192.0.2.128 عنوان IPv4 192.0.2.128 . كان التنسيق السابق، المسمى "عنوان IPv4-compatible IPv6"، هو ::192.0.2.128 ؛ ومع ذلك، فإن هذه الطريقة أصبحت قديمة. [36]
نظرًا للاختلافات الداخلية الكبيرة بين مكدسات بروتوكول IPv4 و IPv6، فإن بعض الوظائف ذات المستوى الأدنى المتاحة للمبرمجين في مكدس IPv6 لا تعمل بنفس الطريقة عند استخدامها مع عناوين IPv4 المخصصة. لا تنفذ بعض مكدسات IPv6 الشائعة ميزة عنوان IPv4 المخصص، إما لأن مكدسات IPv6 و IPv4 عبارة عن تنفيذات منفصلة (على سبيل المثال، Microsoft Windows 2000 و XP و Server 2003)، أو بسبب مخاوف أمنية ( OpenBSD ). [63] في أنظمة التشغيل هذه، يجب على البرنامج فتح مقبس منفصل لكل بروتوكول IP يستخدمه. في بعض الأنظمة، مثل نواة Linux و NetBSD و FreeBSD ، يتم التحكم في هذه الميزة بواسطة خيار المقبس IPV6_V6ONLY. [64] : 22
بادئة العنوان 64:ff9b::/96 هي فئة من عناوين IPv6 المضمنة في IPv4 للاستخدام في طرق انتقال NAT64 . [65] على سبيل المثال، يمثل 64:ff9b::192.0.2.128 عنوان IPv4 192.0.2.128 .
حماية
قد ينشأ عدد من التداعيات الأمنية من استخدام IPv6. وقد تكون بعضها مرتبطة ببروتوكولات IPv6 نفسها، في حين قد تكون بعضها الآخر مرتبطة بعيوب التنفيذ. [66] [67]
شبكات الظل
قد يؤدي إضافة العقد التي تم تمكين IPv6 فيها افتراضيًا بواسطة الشركة المصنعة للبرنامج إلى إنشاء شبكات ظل عن غير قصد ، مما يتسبب في تدفق حركة مرور IPv6 إلى الشبكات التي تحتوي فقط على إدارة أمان IPv4. قد يحدث هذا أيضًا مع ترقيات نظام التشغيل، عندما يقوم نظام التشغيل الأحدث بتمكين IPv6 افتراضيًا، بينما لم يفعل النظام الأقدم ذلك. قد يؤدي الفشل في تحديث البنية الأساسية للأمان لاستيعاب IPv6 إلى تجاوز حركة مرور IPv6 لها. [68] لقد حدثت شبكات ظل على شبكات الأعمال حيث تقوم الشركات باستبدال أنظمة Windows XP التي لا تحتوي على مكدس IPv6 ممكّن افتراضيًا، بأنظمة Windows 7 التي تحتوي على مكدس IPv6. [69] لذلك أوصى بعض منفذي مكدس IPv6 بتعطيل عناوين IPv4 المرسومة واستخدام شبكة مكدسة مزدوجة بدلاً من ذلك حيث يكون دعم كل من IPv4 و IPv6 ضروريًا. [70]
تجزئة حزمة IPv6
أظهرت الأبحاث أن استخدام التجزئة يمكن الاستفادة منه للتهرب من ضوابط أمان الشبكة، على غرار IPv4. ونتيجة لذلك، يتطلب RFC 7112 أن يحتوي الجزء الأول من حزمة IPv6 على سلسلة رأس IPv6 بالكامل، بحيث يتم حظر بعض حالات التجزئة المرضية للغاية. بالإضافة إلى ذلك، نتيجة للبحث حول التهرب من RA-Guard في RFC 7113، أوقف RFC 6980 استخدام التجزئة مع Neighbor Discovery، وثبط استخدام التجزئة مع Secure Neighbor Discovery (SEND).
التوحيد القياسي من خلال RFCs
مقترحات مجموعة العمل

بسبب النمو العالمي المتوقع للإنترنت ، بدأت فرقة عمل هندسة الإنترنت (IETF) في أوائل التسعينيات جهودًا لتطوير بروتوكول IP من الجيل التالي. [5] : 209 بحلول بداية عام 1992، ظهرت العديد من المقترحات لنظام عناوين الإنترنت الموسع وبحلول نهاية عام 1992 أعلنت فرقة عمل هندسة الإنترنت عن دعوة لتقديم أوراق بيضاء. [71] في سبتمبر 1993، أنشأت فرقة عمل هندسة الإنترنت منطقة IP الجيل التالي المؤقتة (IPng) للتعامل على وجه التحديد مع مثل هذه القضايا. كانت المنطقة الجديدة بقيادة أليسون مانكين وسكوت برادنر ، وكان بها مديرية تضم 15 مهندسًا من خلفيات متنوعة لتحديد الاتجاه والمراجعة الأولية للوثائق: [7] [72] وكان أعضاء مجموعة العمل هم جيه ألارد (مايكروسوفت)، وستيف بيلوفين (إيه تي آند تي)، وجيم باوند (شركة ديجيتال إكويبمنت)، وروس كالون (ويلفليت)، وبريان كاربنتر (سيرن)، وديف كلارك ( معهد ماساتشوستس للتكنولوجيا)، وجون كوران (نيرنت)، وستيف ديرينج (زيروكس)، ودينو فاريناتشي (سيسكو)، وبول فرانسيس (إن تي تي)، وإريك فليشمان (بوينج)، ومارك نوبر (أميريتك)، وجريج مينشال (نوفيل)، وروبرت أولمان (لوتس)، وليكسيا تشانج (زيروكس). [73]
تبنت مجموعة مهام هندسة الإنترنت نموذج IPng في 25 يوليو 1994، مع تشكيل العديد من مجموعات عمل IPng. [7] بحلول عام 1996، تم إصدار سلسلة من RFCs التي تحدد بروتوكول الإنترنت الإصدار 6 (IPv6)، بدءًا من RFC 1883. (تم استخدام الإصدار 5 بواسطة بروتوكول تدفق الإنترنت التجريبي .)
معايير RFC
كان أول RFC لتوحيد IPv6 هو RFC 1883 في عام 1995، [74] والذي أصبح عتيقًا بواسطة RFC 2460 في عام 1998. [5] : 209 في يوليو 2017، تم استبدال هذا RFC بواسطة RFC 8200، والذي رفع IPv6 إلى "معيار الإنترنت" (أعلى مستوى نضج لبروتوكولات IETF). [3]
النشر

لقد أدى تقديم التوجيه بين المجالات بدون فئات (CIDR) في عام 1993 في التوجيه وتخصيص عنوان IP للإنترنت، والاستخدام المكثف لترجمة عنوان الشبكة (NAT)، إلى تأخير استنفاد عنوان IPv4 للسماح بنشر IPv6، والذي بدأ في منتصف العقد الأول من القرن الحادي والعشرين.
كانت الجامعات من بين أوائل من تبنوا IPv6. نشرت جامعة فرجينيا للتكنولوجيا IPv6 في موقع تجريبي في عام 2004 ثم وسعت لاحقًا نشر IPv6 عبر شبكة الحرم الجامعي . بحلول عام 2016، استخدم 82٪ من حركة المرور على شبكتها IPv6. بدأت إمبريال كوليدج لندن نشر IPv6 التجريبي في عام 2003 وبحلول عام 2016 بلغ متوسط حركة مرور IPv6 على شبكاتها بين 20٪ و 40٪. تم إنشاء جزء كبير من حركة مرور IPv6 هذه من خلال تعاونهم في مجال الفيزياء عالية الطاقة مع سيرن ، والتي تعتمد بالكامل على IPv6. [75]
يدعم نظام اسم النطاق (DNS) بروتوكول IPv6 منذ عام 2008. وفي نفس العام، تم استخدام بروتوكول IPv6 لأول مرة في حدث عالمي كبير أثناء دورة الألعاب الأوليمبية الصيفية في بكين عام 2008. [ 76 ] [77]
بحلول عام 2011، كانت جميع أنظمة التشغيل الرئيسية المستخدمة على أجهزة الكمبيوتر الشخصية وأنظمة الخوادم تحتوي على تطبيقات IPv6 عالية الجودة. قدمت أنظمة الهاتف الخلوي مجال نشر كبير لأجهزة بروتوكول الإنترنت حيث انتقلت خدمة الهاتف المحمول من تقنيات 3G إلى 4G ، حيث يتم توفير الصوت كخدمة صوت عبر IP (VoIP) من شأنها الاستفادة من تحسينات IPv6. في عام 2009، أصدرت شركة Verizon الأمريكية للاتصالات الخلوية المواصفات الفنية للأجهزة للعمل على شبكات "الجيل التالي". [78] فرضت المواصفات تشغيل IPv6 وفقًا لمواصفات 3GPP Release 8 (مارس 2009) ، وألغت IPv4 كإمكانية اختيارية. [78]
استمر نشر IPv6 في العمود الفقري للإنترنت . في عام 2018، أعلن 25.3٪ فقط من حوالي 54000 نظام مستقل عن كل من بادئات IPv4 و IPv6 في قاعدة بيانات توجيه بروتوكول البوابة الحدودية (BGP) العالمية. وأعلنت 243 شبكة أخرى عن بادئة IPv6 فقط. توجد شبكات عبور العمود الفقري للإنترنت التي تقدم دعم IPv6 في كل دولة على مستوى العالم، باستثناء أجزاء من إفريقيا والشرق الأوسط والصين. [79] : 6 بحلول منتصف عام 2018، نشر بعض مزودي خدمة الإنترنت الأوروبيين الرئيسيين IPv6 لغالبية عملائهم. قدمت Sky UK أكثر من 86٪ من عملائها IPv6، ونشرت Deutsche Telekom 56٪ من IPv6، ونشرت XS4ALL في هولندا 73٪ وفي بلجيكا نشر مزودو خدمة الإنترنت للنطاق العريض VOO و Telenet 73٪ و 63٪ IPv6 على التوالي. [79] : 7 في الولايات المتحدة، كان لدى مزود خدمة الإنترنت عريض النطاق Xfinity نشر IPv6 بنسبة 66% تقريبًا. في عام 2018، أبلغت Xfinity عن ما يقدر بنحو 36.1 مليون مستخدم IPv6، بينما أبلغت AT&T عن 22.3 مليون مستخدم IPv6. [79] : 7–8
قضايا الترابط
هناك نزاع بين شركتي Hurricane Electric و Cogent Communications على IPv6، حيث يرفض مزودا الشبكة تبادل البيانات. [80]
انظر أيضا
- الإنترنت في الصين من الجيل القادم
- مقارنة دعم IPv6 في أنظمة التشغيل
- مقارنة دعم IPv6 في التطبيقات الشائعة
- شهادة المنتج IPv6 من وزارة الدفاع
- أوكيد
- مختبر التشغيل البيني بجامعة نيو هامبشاير
مراجع
- ^ "الأسئلة الشائعة". فريق عمل IPv6 في نيوزيلندا. مؤرشف من الأصل في 29 يناير 2019. تم الاسترجاع في 26 أكتوبر 2015 .
- ^ abcdef S. Deering ; R. Hinden (ديسمبر 1998)، مواصفات بروتوكول الإنترنت، الإصدار 6 (IPv6) ، فريق عمل هندسة الإنترنت (IETF)، RFC 2460 يُلغي RFC 1883.
- ^ ab S. Deering ; R. Hinden (يوليو 2017)، "مواصفات بروتوكول الإنترنت، الإصدار 6 (IPv6)"، صفحات طلب التعليقات (RFC) من IETF – اختبار ، فريق عمل هندسة الإنترنت (IETF)، ISSN 2070-1721، RFC 8200 يصبح RFC 2460 قديمًا.
- ^ Siddiqui, Aftab (17 July 2017). "RFC 8200 – IPv6 Has Been Standardized". Internet Society . مؤرشف من الأصل في 23 أكتوبر 2023 . تم الاسترجاع 25 فبراير 2018 .
- ^ abcd Rosen, Rami (2014). Linux Kernel Networking: Implementation and Theory . نيويورك: Apress. ISBN 9781430261971. OCLC 869747983.
- ^ مؤتمر Google IPv6 لعام 2008: كيف سيبدو شكل الإنترنت IPv6؟. حدث في الساعة 13:35. مؤرشف من الأصل في 11 ديسمبر 2021.
- ^ abc Bradner, S.; Mankin, A. (يناير 1995). التوصية الخاصة ببروتوكول IP من الجيل التالي. IETF . doi : 10.17487/RFC1752 . RFC 1752.
- ^ "استنفاد مساحة عناوين IPv4 المجانية". NRO.net . مونتيفيديو : منظمة موارد الأرقام. 3 فبراير 2011. مؤرشف من الأصل في 18 يناير 2024. تم الاسترجاع في 19 يناير 2022 .
- ^ راشد، فهميدة (1 فبراير 2011). "استنفاذ عنوان IPv4 ليس سببًا فوريًا للقلق بشأن IPv6 في Wings". eWeek. مؤرشف من الأصل في 20 يناير 2024. تم الاسترجاع 23 يونيو 2012 .
- ^ وارد، مارك (14 سبتمبر 2012). "أوروبا تتخطى حدود عناوين الإنترنت القديمة". بي بي سي نيوز . مؤرشف من الأصل في 5 نوفمبر 2023. استرجاع 15 سبتمبر 2012 .
- ^ هيوستن، جيف. "تقرير عنوان IPV4". مؤرشف من الأصل في 10 يناير 2024.
- ^ "الأسئلة الشائعة". my.afrinic.net . AFRINIC . مؤرشف من الأصل في 23 أكتوبر 2023 . تم الاسترجاع 28 نوفمبر 2018 .
- ^ "نفد مخزون عناوين IPv4 من مركز RIPE NCC" (بيان صحفي). RIPE NCC . 25 نوفمبر 2019. مؤرشف من الأصل في 19 يناير 2024 . تم الاسترجاع في 26 نوفمبر 2019 .
- ^ ab Partridge, C.; Kastenholz, F. (ديسمبر 1994). "المعايير الفنية لاختيار IP الجيل التالي (IPng)". RFC 1726 .
- ^ RFC 1112، ملحقات المضيف للبث المتعدد عبر IP ، S. Deering (أغسطس 1989)
- ^ RFC 3956، تضمين عنوان نقطة الالتقاء (RP) في عنوان متعدد البث IPv6 ، P. Savola، B. Haberman (نوفمبر 2004)
- ^ RFC 2908، هندسة تخصيص عناوين البث المتعدد للإنترنت ، د. ثالر، م. هاندلي، د. إسترين (سبتمبر 2000)
- ^ RFC 3306، عناوين البث المتعدد IPv6 المستندة إلى بادئة أحادية البث ، ب. هابرمان، د. ثالر (أغسطس 2002)
- ^ ab S. Thomson; T. Narten; T. Jinmei (سبتمبر 2007). IPv6 Stateless Address Autoconfiguration. Network Working Group. doi : 10.17487/RFC4862 . RFC 4862. مسودة المعيار. أصبحت قديمة الطراز وفقًا لمعيار RFC 2462. تم تحديثها وفقًا لمعيار RFC 7527.
- ^ م. كروفورد (أغسطس 2000). إعادة ترقيم جهاز التوجيه لـ IPv6. مجموعة عمل الشبكة. doi : 10.17487/RFC2894 . RFC 2894. المعيار المقترح.
- ^ T. Narten; R. Draves; S. Krishnan (سبتمبر 2007). "إضافات الخصوصية للتكوين التلقائي للعناوين عديمة الجنسية في IPv6". www.ietf.org . تم الاسترجاع في 13 مارس 2017 .
- ^ F. Gont؛ S. Krishnan؛ T. Narten؛ R. Draves (فبراير 2021). ملحقات العناوين المؤقتة للتكوين التلقائي للعناوين عديمة الجنسية في IPv6. فريق عمل هندسة الإنترنت . doi : 10.17487/RFC8981 . ISSN 2070-1721. RFC 8981. المعيار المقترح يلغي RFC 4941.
- ^ "نظرة عامة على حزمة الشبكات المتقدمة لنظام التشغيل Windows XP". Microsoft . مؤرشف من الأصل في 7 سبتمبر 2017 . تم الاسترجاع 15 أبريل 2019 .
- ^ "إضافات الخصوصية لـ IPv6 SLAAC". جمعية الإنترنت . 8 أغسطس 2014. مؤرشف من الأصل في 23 أكتوبر 2023. تم الاسترجاع 17 يناير 2020 .
- ^ P. Ferguson; H. Berkowitz (January 1997). Network Recoding Overview: Why would I want it and what is it however?. Network Working Group. doi : 10.17487/RFC2071 . RFC 2071. إعلامية.
- ^ Ferguson, P.; Berkowitz, H. (January 1997). "نظرة عامة على إعادة ترقيم الشبكة: لماذا أريدها وما هي على أي حال؟". IETF . doi :10.17487/RFC2071. RFC 2071 . مؤرشف من الأصل في 7 يناير 2024.
- ^ Berkowitz, H. (January 1997). "Router Renuming Guide". IETF . doi :10.17487/RFC2072. RFC 2072 . مؤرشف من الأصل في 8 يونيو 2023.
- ^ كوبر، أليسا؛ جونت، فرناندو؛ ثالر، ديف. توصية بشأن معرفات واجهة IPv6 المستقرة. doi : 10.17487/RFC8064 . RFC 8064.
- ^ Silvia Hagen (2014). IPv6 Essentials: Integrating IPv6 into Your IPv4 Network (الطبعة الثالثة). Sebastopol, CA: O'Reilly Media. ص. 196. ISBN 978-1-4493-3526-7. OCLC 881832733.
- ^ زاك، إي. (يوليو 2013). "تقييم أمان IPv6 والمقارنة المعيارية".
- ^ Gont, F. (مارس 2016). "التأثيرات التشغيلية لحزم IPv6 ذات رؤوس الامتداد". IETF . مؤرشف من الأصل في 27 أكتوبر 2023.
- ^ V. Devarapalli; R. Wakikawa; A. Petrescu; P. Thubert (يناير 2005). بروتوكول الدعم الأساسي لشبكة التنقل (NEMO). مجموعة عمل الشبكة. doi : 10.17487/RFC3963 . RFC 3963. المعيار المقترح.
- ^ د. بورمان؛ س. ديرينج ؛ ر. هيندين (أغسطس 1999). مخططات IPv6 الضخمة. مجموعة عمل الشبكة. doi : 10.17487/RFC2675 . RFC 2675. المعيار المقترح يلغي الحاجة إلى RFC 2147.
- ^ K. Nichols; S. Blake; F. Baker ; D. Black (ديسمبر 1998). تعريف مجال الخدمات المتباينة (DS Field) في عناوين IPv4 وIPv6. مجموعة عمل الشبكة. doi : 10.17487/RFC2474 . RFC 2474. المعيار المقترح. يصبح RFC 1455 و1349 قديمين. تم تحديثه بواسطة RFC 3168 و3260 و8436.
- ^ K. Ramakrishnan; S. Floyd; D. Black (سبتمبر 2001). إضافة إشعار الازدحام الصريح (ECN) إلى IP. مجموعة عمل الشبكة. doi : 10.17487/RFC3168 . RFC 3168. المعيار المقترح. يلغي RFC 2481. ويحدث RFC 2474 و2401 و793. ويحدث بواسطة RFC 4301 و6040 و8311.
- ^ abcd R. Hinden; S. Deering (فبراير 2006). بنية عنونة IP الإصدار 6. مجموعة عمل الشبكة. doi : 10.17487/RFC4291 . RFC 4291. مسودة المعيار. أصبحت RFC 3513 قديمة . تم تحديثها بواسطة RFC 5952 و6052 و7136 و7346 و7371 و8064.
- ^ Graziani, Rick (2012). IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6. Cisco Press . ص. 55. ISBN 978-0-13-303347-2.
- ^ كوفين، توم (2014). تخطيط عناوين IPv6: تصميم خطة عناوين للمستقبل. أوريلي ميديا . ص. 170. ISBN 978-1-4919-0326-1.
- ^ ab Horley, Edward (2013). Practical IPv6 for Windows Administrators. Apress . p. 17. ISBN 978-1-4302-6371-5.
- ^ ab S. Kawamura; M. Kawashima (أغسطس 2010). توصية لتمثيل نص عنوان IPv6. فريق عمل هندسة الإنترنت . doi : 10.17487/RFC5952 . ISSN 2070-1721. RFC 5952. المعيار المقترح. تحديثات RFC 4291.
- ^ م. بلانشيت (أبريل 2008). عناوين IPv6 ذات الاستخدام الخاص. مجموعة عمل الشبكة. doi : 10.17487/RFC5156 . RFC 5156. المعيار المقترح. تم إلغاؤه بموجب RFC 6890.
- ^ T. Berners-Lee ؛ R. Fielding ؛ L. Masinter (يناير 2005). Uniform Resource Identifier (URI): Generic Syntax. Network Working Group. doi : 10.17487/RFC3986 . STD 66. RFC 3986. معيار الإنترنت 66. يجعل RFC 2732 و2396 و1808 غير صالحين . تم تحديثه بواسطة RFC 6874 و7320 و8820. تحديث RFC 1738.
- ^ abc Narten, T. (أغسطس 1999). "اكتشاف الجيران والتكوين التلقائي بدون جنسية في IPv6". IEEE Internet Computing . 3 (4): 54–62. doi :10.1109/4236.780961.
- ^ Narten, T. (سبتمبر 2007). "Neighbor Discovery for IP version 6 (IPv6)". IETF . section 6.3.7. doi : 10.17487/RFC4861 . RFC 4861 . مؤرشف من الأصل في 17 يناير 2024.
- ^ Thomson, S. (سبتمبر 2007). "IPv6 Stateless Address Autoconfiguration - Section 5.5.1". IETF . doi :10.17487/RFC4862. RFC 4862 . مؤرشف من الأصل في 11 يناير 2024.
- ^ "سياسة تخصيص وتعيين عناوين IPv6". RIPE NCC . 8 فبراير 2011. مؤرشف من الأصل في 3 يونيو 2023. تم الاسترجاع 27 مارس 2011 .
- ^ IAB ؛ IESG (سبتمبر 2001). توصيات IAB/IESG بشأن تخصيص عناوين IPv6 للمواقع. مجموعة عمل الشبكة. doi : 10.17487/RFC3177 . RFC 3177. عفا عليها الزمن. تم إلغاؤه بموجب RFC 6177.
- ^ T. Narten; G. Huston; L. Roberts (مارس 2011). تعيين عنوان IPv6 للمواقع النهائية. فريق عمل هندسة الإنترنت (IETF). doi : 10.17487/RFC6177 . ISSN 2070-1721. BCP 157. RFC 6177. أفضل الممارسات الشائعة. يجعل RFC 3177 قديمًا .
- ^ Brzozowski, John (31 January 2011). "Comcast Activates First Users With IPv6 Native Dual Stack Over DOCSIS" (بيان صحفي). Comcast . مؤرشف من الأصل في 23 أكتوبر 2023 . تم الاسترجاع في 15 أبريل 2019 .
- ^ Silvia Hagen (2014). IPv6 Essentials: Integrating IPv6 into Your IPv4 Network . O'Reilly Media, Inc. p. 176. ISBN 9781449335267.
- ^ "مقارنة آلية انتقال IPv6/النفق". Sixxs.net. مؤرشف من الأصل في 23 أكتوبر 2023. تم الاسترجاع في 20 يناير 2012 .
- ^ Silvia Hagen (2014). IPv6 Essentials: Integrating IPv6 into Your IPv4 Network . O'Reilly Media, Inc. ص 222-223. ISBN 9781449335267.
- ^ كاربنتر، ب. (أغسطس 2011). "المبادئ التوجيهية الاستشارية لنشر 6to4". IETF . doi : 10.17487/RFC6343 . RFC 6343. مؤرشف من الأصل في 28 يناير 2023. تم الاسترجاع في 20 أغسطس 2012 .
- ^ "IPv6: Dual stack where you can; tunnel where you must". networkworld.com. 5 سبتمبر 2007. مؤرشف من الأصل في 20 يناير 2024. تم الاسترجاع في 27 نوفمبر 2012 .
- ^ E. Nordmark; R. Gilligan (أكتوبر 2005). آليات الانتقال الأساسية لمضيفات IPv6 وأجهزة التوجيه. مجموعة عمل الشبكة. doi : 10.17487/RFC4213 . RFC 4213. المعيار المقترح يلغي الحاجة إلى RFC 2893.
- ^ Silvia Hagen (2014). IPv6 Essentials: Integrating IPv6 into Your IPv4 Network . O'Reilly Media, Inc. p. 222. ISBN 9781449335267.
- ^ "فهم التراص المزدوج لعناوين IPv4 و IPv6 أحادية البث". Juniper.net . Juniper Networks. 31 أغسطس 2017 . تم الاسترجاع في 19 يناير 2022 .
- ^ "IPv6". NRO.net . مؤرشف من الأصل في 12 يناير 2017. اطلع عليه بتاريخ 13 مارس 2017 .
- ^ Pujol, Enric (12 يونيو 2017). "ما الذي يوقف حركة مرور IPv6 في مزود خدمة إنترنت ثنائي المكدس؟". APNIC.net . APNIC . مؤرشف من الأصل في 27 مارس 2023 . تم الاسترجاع في 13 يونيو 2017 .
- ^ Vaughan-Nichols, Steven J. (14 أكتوبر 2010). "خمس طرق للتعايش السلمي بين IPv6 وIPv4". ZDNET . مؤرشف من الأصل في 5 ديسمبر 2023. تم الاسترجاع في 13 مارس 2017 .
- ^ Silvia Hagen (2014). IPv6 Essentials: Integrating IPv6 into Your IPv4 Network . O'Reilly Media, Inc. p. 33. ISBN 9781449335267.
- ^ م. كوتون؛ ل. فيجودا؛ ب. هابرمان (أبريل 2013). ر. بونيكا (محرر). سجلات عناوين IP للأغراض الخاصة. IETF . doi : 10.17487/RFC6890 . ISSN 2070-1721. BCP 153. RFC 6890. أفضل الممارسات الحالية 153. تجعل RFC 4773 و5156 و5735 و5736 غير صالحة للاستخدام. تم تحديثها بواسطة RFC 8190.
- ^ – دليل واجهات Kernel OpenBSD
- ^ R. Gilligan; S. Thomson; J. Bound; J. McCann; W. Stevens (فبراير 2003). امتدادات واجهة المقبس الأساسية لـ IPv6. مجموعة عمل الشبكة. doi : 10.17487/RFC3493 . RFC 3493.
- ^ C. Bao; C. Huitema ; M. Bagnulo; M. Boucadair; X. Li (أكتوبر 2010). عنونة IPv6 لمترجمي IPv4/IPv6. فريق عمل هندسة الإنترنت (IETF). doi : 10.17487/RFC6052 . ISSN 2070-1721. RFC 6052. المعيار المقترح. تحديثات RFC 4291.
- ^ Gont, Fernando (10 مارس 2019)، أمان IPv6 لمهندسي IPv4 (PDF) ، تم الاسترجاع في 30 أغسطس 2019
- ^ Gont, Fernando (10 January 2019), IPv6 Security Frequently Asked Questions (FAQ) (PDF) , تم الاسترجاع في 30 أغسطس 2019
- ^ مولينز، روبرت (5 أبريل 2012)، شبكات الظل: تأثير جانبي غير مقصود لـ IPv6، تم أرشفته من الأصل في 11 أبريل 2013 ، تم استرجاعه في 2 مارس 2013
- ^ Cicileo, Guillermo; Gagliano, Roque; O'Flaherty, Christian; et al. (أكتوبر 2009). IPv6 للجميع: دليل لاستخدام IPv6 وتطبيقه في بيئات مختلفة (PDF) . ص. 5. تم الاسترجاع في 2 مارس 2013 .
- ^ Jun-ichiro itojun Hagino (أكتوبر 2003). "عناوين IPv4 المرسومة على السلك تعتبر ضارة".
- ^ Bradner, S.; Mankin, A. (ديسمبر 1993). "IP: طلب ورقة بيضاء للجيل التالي (IPng). RFC 1550 .
- ^ "تاريخ جهود IPng". The Sun . مؤرشف من الأصل في 23 مايو 2014.
- ^ Bradner, Scott O.; Mankin, Allison J. (January 1995). "التوصية الخاصة ببروتوكول IP من الجيل التالي – الملحق ب". RFC 1752 .
- ^ وانج، تاو؛ جاو، جياكيونج (1 يناير 2019). "عيوب IPv6 وترقية IPv4". المجلة الدولية للشبكات المتقدمة والمراقبة والضوابط . 4 (1): 1-9. doi : 10.21307/ijanmc-2019-029 .
- ^ حالة نشر IPv6 لعام 2018، جمعية الإنترنت ، 2018، ص. 3
- ^ "Beijing2008.cn jumps to next-generation Net" (بيان صحفي). اللجنة المنظمة لألعاب الأولمبياد التاسعة والعشرين في بكين. 30 مايو 2008. مؤرشف من الأصل في 4 فبراير 2009.
- ^ Das, Kaushik (2008). "IPv6 and the 2008 Beijing Olympics". IPv6.com . مؤرشف من الأصل في 1 أغسطس 2008 . تم الاسترجاع في 15 أغسطس 2008 .
- ^ ab Morr, Derek (9 يونيو 2009). "Verizon Mandates IPv6 Support for Next-Gen Cell Phones". CircleID.
- ^ abc "State of IPv6 Deployment 2018" (PDF) . InternetSociety.org . Internet Society . تم الاسترجاع في 19 يناير 2022 .
- ^ "قضية شركة هوريكان إلكتريك آند كوجنت". BGP.tools . BGP.tools . تم الاسترجاع في 10 سبتمبر 2024 .
روابط خارجية
- IPv6 في نواة Linux بقلم رامي روزن
- مقدمة وإحصائيات حول IPv6 من Google
- الوثيقة القياسية التي تصدق على IPv6 – وثيقة RFC 8200 التي تصدق على IPv6 كمعيار للإنترنت
