IPv6

بروتوكول الإنترنت الإصدار السادس ( IPv6 ) هو أحدث إصدار من بروتوكول الإنترنت (IP)، وهو بروتوكول الاتصالات الذي يوفر نظامًا لتحديد هوية وموقع أجهزة الكمبيوتر على الشبكات وتوجيه حركة البيانات عبر الإنترنت . طُوّر IPv6 من قِبل فريق عمل هندسة الإنترنت (IETF) لمعالجة مشكلة استنفاد عناوين IPv4 التي طال انتظارها ، وكان الهدف منه استبدال IPv4 . [ 1 ] في ديسمبر 1998، أصبح IPv6 مسودة معيار لفريق عمل هندسة الإنترنت (IETF)، [ 2 ] الذي صادق عليه لاحقًا كمعيار إنترنت في 14 يوليو 2017. [ 3 ] [ 4 ]

تُخصص للأجهزة المتصلة بالإنترنت عناوين IP فريدة لتحديد هويتها وموقعها. مع النمو السريع للإنترنت بعد طرحه تجاريًا في التسعينيات، بات من الواضح أن هناك حاجة إلى عدد أكبر بكثير من العناوين لربط الأجهزة مقارنةً بحوالي 4 مليارات عنوان (2^ 32 ) التي وفرها بروتوكول IPv4. بحلول عام 1998، أقرت فرقة عمل هندسة الإنترنت (IETF) بروتوكول IPv6، وهو البروتوكول اللاحق. يستخدم هذا البروتوكول عناوين بطول 128 بت ، مما يوفر مساحة عناوين تبلغ 2^ 128 عنوانًا ( حوالي 10^32 عنوانًا).3.4 × 10 38 , 340 أونديسيليون ). تم ابتكار العديد من آليات الانتقال للسماح لـ IPv4 و IPv6 بالعمل معًا، لكن IPv6 ليس متوافقًا مع الإصدارات السابقة من IPv4 ولا يعمل الاثنان معًا بشكل مباشر.

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

تُمثَّل عناوين IPv6 بثماني مجموعات، كل مجموعة تتكون من أربعة أرقام سداسية عشرية ، مفصولة بنقطتين رأسيتين. [ 5 ] يجب اختصار التمثيل الكامل قدر الإمكان وفقًا لقواعد محددة؛ على سبيل المثال، يصبح العنوان 2001:0db8:0000:0000:0000:8a2e:0370:7334 هو 2001:db8::8a2e:370:7334 . [ 6 ]

الميزات الرئيسية

مسرد المصطلحات المستخدمة لعناوين IPv6

IPv6 هو بروتوكول طبقة الإنترنت للربط الشبكي عبر تبديل الحزم ويوفر نقل البيانات من طرف إلى طرف عبر شبكات IP متعددة، مع الالتزام الوثيق بمبادئ التصميم التي تم تطويرها في الإصدار السابق من البروتوكول، بروتوكول الإنترنت الإصدار 4 (IPv4).

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

تتيح بنية عنونة IPv6 ثلاثة أنواع مختلفة من الإرسال: أحادي البث ، وأي بث ، ومتعدد البث . [ 7 ] [ 8 ] : 210 لا يدعم IPv6 البث العام ، وبالتالي لا يوجد لديه مفهوم عنوان البث .

الدافع والأصل

استنفاد عناوين IPv4

تفكيك تمثيل عنوان IPv4 ذي النقاط العشرية إلى تدوينه الثنائي

كان بروتوكول الإنترنت الإصدار الرابع (IPv4) أول إصدار يُستخدم علنًا من بروتوكول الإنترنت . طُوّر IPv4 كمشروع بحثي من قِبل وكالة مشاريع البحوث الدفاعية المتقدمة (DARPA)، التابعة لوزارة الدفاع الأمريكية ، قبل أن يُصبح أساسًا للإنترنت وشبكة الويب العالمية . يتضمن IPv4 نظام عنونة يستخدم مُعرّفات رقمية تتكون من 32 بت. تُعرض هذه العناوين عادةً بنظام العد العشري النقطي ، كقيم عشرية من أربعة أجزاء (ثمانيات)، كل جزء منها في النطاق من 0 إلى 255، أي 8 بتات لكل رقم. وبذلك، يُوفر IPv4 إمكانية عنونة تصل إلى 2 ^32 ، أو ما يُقارب 4.3 مليار عنوان.

لم يكن استنفاد العناوين مصدر قلق في البداية في بروتوكول IPv4، إذ كان يُفترض أن يكون هذا الإصدار اختبارًا لمفاهيم الشبكات الخاصة بوكالة مشاريع الأبحاث الدفاعية المتقدمة (DARPA). [ 9 ] خلال العقد الأول من تشغيل الإنترنت، اتضح ضرورة تطوير أساليب للحفاظ على مساحة العناوين. في أوائل التسعينيات، حتى بعد إعادة تصميم نظام العنونة باستخدام نموذج شبكة لا يعتمد على الفئات ، بات من الواضح أن هذا لن يكون كافيًا لمنع استنفاد عناوين IPv4 ، وأن هناك حاجة إلى مزيد من التغييرات في بنية الإنترنت التحتية. [ 10 ]

في فبراير 2011، قامت هيئة الأرقام المخصصة للإنترنت (IANA) بتخصيص آخر 16 مليون عنوان IPv4 غير مُخصصة من المستوى الأعلى لخمسة سجلات إنترنت إقليمية (RIRs). [ 11 ] في ذلك الوقت، كان لدى كل سجل RIR مجموعات عناوين متاحة، وكان من المتوقع أن يستمر في تطبيق سياسات تخصيص العناوين القياسية حتى يتبقى نطاق واحد من نوع /8 CIDR.

بعد ذلك، اقتصرت خدمات سجلات الإنترنت الإقليمية (RIRs) على توفير نطاقات عناوين IPv4 (/22) من 1024 عنوانًا فقط. ومنذ ذلك الحين، وصلت جميع سجلات الإنترنت الإقليمية الخمسة - مركز معلومات شبكة آسيا والمحيط الهادئ (APNIC)، ومركز تنسيق شبكة RIPE NCC، ومركز معلومات شبكة أمريكا اللاتينية ومنطقة البحر الكاريبي (LACNIC)، ومركز معلومات الشبكة الأفريقية (AFRINIC)، والسجل الأمريكي لأرقام الإنترنت (ARIN) - إلى هذه المرحلة. [ 12 ] [ 13 ] [ 14 ] [ 15 ] وكان مركز RIPE NCC آخر من فعل ذلك؛ إذ أعلن عن نفاد عناوين IPv4 لديه بالكامل في 25 نوفمبر 2019، [ 16 ] ودعا إلى إحراز تقدم أكبر في اعتماد IPv6.

مقارنة مع IPv4

على الإنترنت، تُنقل البيانات على شكل حزم شبكية . يحدد بروتوكول IPv6 تنسيقًا جديدًا للحزم ، مصممًا لتقليل معالجة رؤوس الحزم بواسطة أجهزة التوجيه. [ 2 ] [ 17 ] نظرًا للاختلاف الكبير بين رؤوس حزم IPv4 وIPv6، فإن البروتوكولين غير متوافقين. مع ذلك، لا تحتاج معظم بروتوكولات طبقة النقل والتطبيق إلا إلى تغييرات طفيفة أو معدومة للعمل عبر IPv6؛ باستثناء بروتوكولات التطبيقات التي تتضمن عناوين طبقة الإنترنت، مثل بروتوكول نقل الملفات (FTP) وبروتوكول وقت الشبكة (NTP)، حيث قد يتسبب تنسيق العنوان الجديد في حدوث تعارضات مع بنية البروتوكول الحالية.

مساحة عناوين أكبر

تتمثل الميزة الرئيسية لبروتوكول IPv6 مقارنةً ببروتوكول IPv4 في مساحة عناوين أكبر. يبلغ حجم عنوان IPv6 128 بت، مقارنةً بـ 32 بت في IPv4. [ 2 ] وبالتالي، تحتوي مساحة العناوين على 2 ^128 عنوانًا (تقريبًا).3.4 × 10 ^ 38,340 أونديسيليون). بعض كتل هذه المساحة وبعض العناوين المحددة محجوزة لاستخدامات خاصة .

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

البث المتعدد

بنية البث المتعدد في IPv6

يُعدّ البث المتعدد ، أي إرسال حزمة بيانات إلى وجهات متعددة في عملية إرسال واحدة، جزءًا من المواصفات الأساسية لبروتوكول IPv6. أما في IPv4، فهو ميزة اختيارية (وإن كانت شائعة الاستخدام). [ 18 ] يتشارك بروتوكول IPv6 في بعض الميزات والبروتوكولات مع بروتوكول IPv4، ولكنه يُقدّم أيضًا تحسينات وتغييرات من خلال الاستغناء عن بعض البروتوكولات. لا يُطبّق IPv6 البث التقليدي لبروتوكول الإنترنت ، أي إرسال حزمة بيانات إلى جميع الأجهزة المضيفة على الرابط المتصل باستخدام عنوان بث خاص ، وبالتالي لا يُحدّد عناوين البث. في IPv6، يُمكن تحقيق النتيجة نفسها بإرسال حزمة بيانات إلى مجموعة البث المتعدد المحلية لجميع العُقد على الرابط على العنوان ff02::1 ، وهو ما يُشابه البث المتعدد في IPv4 إلى العنوان 224.0.0.1 . كما يُوفّر IPv6 تطبيقات جديدة للبث المتعدد، بما في ذلك تضمين عناوين نقاط الالتقاء في عنوان مجموعة البث المتعدد في IPv6، مما يُبسّط نشر حلول الربط بين النطاقات. [ 19 ]

في بروتوكول IPv4، يصعب على أي مؤسسة الحصول على تخصيص واحد لمجموعة بث متعدد قابلة للتوجيه عالميًا، كما أن تطبيق حلول الربط بين النطاقات معقد للغاية. [ 20 ] تتضمن تخصيصات عناوين البث الأحادي من قِبل سجل إنترنت محلي لبروتوكول IPv6 بادئة توجيه لا تقل عن 64 بت، مما يُتيح أصغر حجم شبكة فرعية متاح في IPv6 (أيضًا 64 بت). مع هذا التخصيص، يُمكن تضمين بادئة عنوان البث الأحادي في تنسيق عنوان البث المتعدد لبروتوكول IPv6، مع توفير كتلة 32 بت، وهي البتات الأقل أهمية في العنوان، أو ما يُقارب 4.2 مليار مُعرّف لمجموعة البث المتعدد. وبالتالي، يُتاح لكل مُستخدم لشبكة فرعية IPv6 تلقائيًا مجموعة من مجموعات البث المتعدد الخاصة بالمصدر والقابلة للتوجيه عالميًا لتطبيقات البث المتعدد. [ 21 ]

التكوين التلقائي للعناوين بدون حالة (SLAAC)

تُهيئ مضيفات IPv6 نفسها تلقائيًا. لكل واجهة عنوان محلي للرابط مُولّد ذاتيًا، وعند الاتصال بشبكة، يتم حل التعارضات، وتُوفّر أجهزة التوجيه بادئات الشبكة عبر إعلانات التوجيه. [ 22 ] يُمكن تحقيق تهيئة أجهزة التوجيه بدون حالة باستخدام بروتوكول خاص لإعادة ترقيم أجهزة التوجيه. [ 23 ] عند الضرورة، يُمكن للمضيفات تهيئة عناوين إضافية ذات حالة عبر بروتوكول تهيئة المضيف الديناميكي الإصدار 6 (DHCPv6) أو عناوين ثابتة يدويًا.

يدعم بروتوكول IPv6، مثل IPv4، عناوين IP فريدة عالميًا . ويهدف تصميم IPv6 إلى إعادة التأكيد على مبدأ الاتصال من طرف إلى طرف في تصميم الشبكة، وهو المبدأ الذي تم تصوره في الأصل عند إنشاء الإنترنت في بداياته، وذلك بجعل ترجمة عناوين الشبكة غير ضرورية. وبالتالي، يمكن الوصول إلى أي جهاز على الشبكة عالميًا مباشرةً من أي جهاز آخر.

يُسهّل عنوان IP ثابت وفريد ​​وقابل للعنونة عالميًا تتبع الجهاز عبر الشبكات. ولذلك، تُشكّل هذه العناوين مصدر قلق خاص بخصوصية الأجهزة المحمولة، مثل أجهزة الكمبيوتر المحمولة والهواتف المحمولة. [ 24 ] ولمعالجة هذه المخاوف المتعلقة بالخصوصية، يتضمن بروتوكول SLAAC ما يُسمى عادةً "عناوين الخصوصية" أو، بشكل أدق، "العناوين المؤقتة". [ 25 ] العناوين المؤقتة عشوائية وغير مستقرة. يُنشئ جهاز المستهلك العادي عنوانًا مؤقتًا جديدًا يوميًا ويتجاهل حركة البيانات المُوجّهة إلى عنوان قديم بعد أسبوع واحد. تُستخدم العناوين المؤقتة افتراضيًا في نظام التشغيل Windows منذ XP SP1، [ 26 ] ونظام macOS منذ  الإصدار  10.7، ونظام Android منذ الإصدار 4.0، ونظام iOS منذ الإصدار 4.3. ويختلف استخدام العناوين المؤقتة في توزيعات Linux. [ 27 ]

إعادة ترقيم شبكة قائمة لمزود اتصال جديد ذي بادئات توجيه مختلفة يُعدّ جهدًا كبيرًا في بروتوكول IPv4. [ 28 ] [ 29 ] أما في بروتوكول IPv6، فيمكن من حيث المبدأ إعادة ترقيم شبكة كاملة بتغيير البادئة التي تُعلنها بعض أجهزة التوجيه، نظرًا لإمكانية تكوين مُعرّفات المضيف (أقل 64 بتًا أهميةً في العنوان) ذاتيًا بشكل مستقل من قِبل المضيف. [ 22 ] وتعتمد طريقة توليد عناوين SLAAC على التنفيذ. وتوصي فرقة عمل هندسة الإنترنت (IETF) بأن تكون العناوين حتمية ولكنها غير شفافة دلاليًا. [ 30 ]

بروتوكول أمان الإنترنت (IPsec)

طُوِّر بروتوكول أمان الإنترنت (IPsec) في الأصل لبروتوكول IPv6، لكنه انتشر على نطاق واسع أولًا في IPv4، حيث أُعيدت هندسته من أجله. كان IPsec جزءًا إلزاميًا من جميع تطبيقات بروتوكول IPv6، [ 2 ] وكان يُوصى باستخدام بروتوكول تبادل مفاتيح الإنترنت (IKE)، ولكن مع RFC 6434، خُفِّضَ تضمين IPsec في تطبيقات IPv6 إلى مجرد توصية، لأنه اعتُبِر من غير العملي اشتراط تطبيق IPsec بالكامل على جميع أنواع الأجهزة التي قد تستخدم IPv6. [ 31 ] مع ذلك، اعتبارًا من RFC 4301، يجب على تطبيقات بروتوكول IPv6 التي تُطبِّق IPsec تطبيق IKEv2 ودعم مجموعة دنيا من خوارزميات التشفير . سيساعد هذا الشرط على جعل تطبيقات IPsec أكثر قابلية للتشغيل البيني بين الأجهزة من مختلف المُصنِّعين. يُطبَّق كلٌّ من رأس مصادقة IPsec (AH) ورأس حمولة الأمان المُغلَّفة (ESP) كرؤوس امتداد لبروتوكول IPv6. [ 32 ]

معالجة مبسطة بواسطة أجهزة التوجيه

يُعدّ رأس حزمة IPv6 أبسط من رأس حزمة IPv4. فقد نُقلت العديد من الحقول قليلة الاستخدام إلى امتدادات اختيارية للرأس. وقد سهّل رأس حزمة IPv6 عملية توجيه الحزم بواسطة أجهزة التوجيه . على الرغم من أن حجم رؤوس حزم IPv6 يبلغ ضعف حجم رؤوس حزم IPv4 على الأقل، إلا أن معالجة الحزم التي تحتوي فقط على رأس IPv6 الأساسي بواسطة أجهزة التوجيه قد تكون، في بعض الحالات، أكثر كفاءة، نظرًا لانخفاض الحاجة إلى المعالجة في أجهزة التوجيه بسبب محاذاة الرؤوس لتتوافق مع أحجام الكلمات الشائعة . [ 2 ] [ 17 ] مع ذلك، تُطبّق العديد من الأجهزة دعم IPv6 برمجيًا (بدلاً من عتاديًا)، مما يؤدي إلى ضعف أداء معالجة الحزم. [ 33 ] إضافةً إلى ذلك، في العديد من التطبيقات، يتسبب استخدام رؤوس الامتداد في معالجة الحزم بواسطة وحدة المعالجة المركزية لجهاز التوجيه، مما يؤدي إلى ضعف الأداء أو حتى مشاكل أمنية. [ 34 ]

علاوة على ذلك، لا يتضمن رأس IPv6 مجموعًا اختباريًا. يُحسب المجموع الاختباري لرأس IPv4 لرأس IPv4 نفسه، ويتعين على أجهزة التوجيه إعادة حسابه كلما انخفض وقت البقاء (المعروف بحد القفزات في بروتوكول IPv6) بمقدار واحد. يُعزز غياب المجموع الاختباري في رأس IPv6 مبدأ التكامل من طرف إلى طرف في تصميم الإنترنت، والذي يفترض أن معظم عمليات المعالجة في الشبكة تتم في العقد الطرفية. يُفترض أن حماية سلامة البيانات المُغلفة في حزمة IPv6 مضمونة من خلال طبقة الربط أو اكتشاف الأخطاء في بروتوكولات الطبقات العليا، وتحديدًا بروتوكول التحكم في الإرسال (TCP) وبروتوكول بيانات المستخدم (UDP) في طبقة النقل . وبالتالي، بينما سمح IPv4 بعدم احتواء رؤوس حزم بيانات UDP على مجموع اختباري (يُشار إليه بالرقم 0 في حقل الرأس)، فإن IPv6 يشترط وجود مجموع اختباري في رؤوس UDP.

لا تقوم أجهزة توجيه IPv6 بتجزئة عناوين IP . يجب على مضيفي IPv6 القيام بأحد الإجراءات التالية: إجراء اكتشاف MTU للمسار ، أو إجراء تجزئة من طرف إلى طرف، أو إرسال حزم لا تتجاوز حجم وحدة الإرسال القصوى الافتراضية (MTU)، وهي 1280 بايت .

التنقل

على عكس بروتوكول IPv4 للهواتف المحمولة، يتجنب بروتوكول IPv6 للهواتف المحمولة التوجيه المثلثي ، وبالتالي فهو يتمتع بنفس كفاءة بروتوكول IPv6 الأصلي. كما قد تسمح أجهزة توجيه IPv6 بانتقال الشبكات الفرعية بأكملها إلى نقطة اتصال جديدة بجهاز التوجيه دون إعادة ترقيمها. [ 35 ]

رؤوس الامتداد

أمثلة عديدة على رؤوس امتداد IPv6

يبلغ الحد الأدنى لحجم رأس حزمة IPv6 أربعين بايتًا (320 بتًا). تُنفَّذ الخيارات كإضافات. يتيح ذلك إمكانية توسيع البروتوكول مستقبلًا دون التأثير على بنية الحزمة الأساسية. [ 2 ] مع ذلك، تشير RFC 7872 إلى أن بعض مشغلي الشبكات يتجاهلون حزم IPv6 ذات رؤوس الإضافات عند مرورها عبر أنظمة النقل المستقلة .

جامبوجرام

يُحدد بروتوكول IPv4 حجم الحزم بـ 65,535 (2 ^16 - 1) بايت من البيانات. يمكن لعقدة IPv6، اختيارياً، معالجة الحزم التي تتجاوز هذا الحد، والتي تُعرف باسم "الحزم الضخمة" (Jumbograms )، والتي قد يصل حجمها إلى 4,294,967,295 (2 ^32 - 1) بايت. قد يُحسّن استخدام الحزم الضخمة الأداء عبر روابط MTU العالية . ويُشار إلى استخدام الحزم الضخمة من خلال رأس امتداد خيار الحمولة الضخمة (Jumbo Payload Option). [ 36 ]

حزم IPv6

رأس حزمة IPv6

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

يشغل رأس الحزمة الثابت أول 40 بايت (320 بت) من حزمة IPv6. ويحتوي على عنواني المصدر والوجهة، وفئة حركة البيانات، وعدد القفزات، ونوع الامتداد الاختياري أو الحمولة التي تلي الرأس. يُخبر حقل "الرأس التالي" المُستقبِل بكيفية تفسير البيانات التي تلي الرأس. إذا كانت الحزمة تحتوي على خيارات، فإن هذا الحقل يحتوي على نوع الخيار التالي. يشير حقل "الرأس التالي" للخيار الأخير إلى بروتوكول الطبقة العليا المُضمّن في حمولة الحزمة . 

يقسم الاستخدام الحالي لحقل فئة حركة مرور IPv6 هذا الحقل بين نقطة رمز الخدمات المتباينة ذات 6 بتات [ 37 ] وحقل إشعار الازدحام الصريح ذي 2 بتات [ 38 ] . تحمل رؤوس الامتداد خيارات تُستخدم لمعالجة خاصة للحزمة في الشبكة، مثل التوجيه والتجزئة والأمان باستخدام إطار عمل IPsec . بدون خيارات خاصة، يجب ألا يتجاوز حجم الحمولة 64 كيلوبايت . مع خيار الحمولة الضخمة (في رأس امتداد خيارات القفزة تلو القفزة )، يجب ألا يتجاوز حجم الحمولة 4  جيجابايت. على عكس IPv4، لا تقوم أجهزة التوجيه بتجزئة الحزمة أبدًا. من المتوقع أن تستخدم الأجهزة المضيفة اكتشاف الحد الأقصى لوحدة النقل (MTU) للمسار لجعل حزمها صغيرة بما يكفي للوصول إلى الوجهة دون الحاجة إلى تجزئتها. انظر تجزئة حزم IPv6 .

معالجة

بنية عامة لعنوان IPv6 أحادي البث

تتكون عناوين IPv6 من 128 بت. ويختلف تصميم مساحة عناوين IPv6 عن تصميم IPv4، حيث استُخدم تقسيم الشبكة الفرعية لتحسين كفاءة استخدام مساحة العناوين الصغيرة. في IPv6، تُعتبر مساحة العناوين كبيرة بما يكفي للمستقبل المنظور، وتستخدم الشبكة الفرعية المحلية دائمًا 64 بت لجزء المضيف من العنوان، المُخصص كمُعرّف للواجهة، بينما تُستخدم الـ 64 بت الأكثر أهمية كبادئة توجيه. [ 7 ] : 9 ورغم شيوع الاعتقاد باستحالة مسح الشبكات الفرعية في IPv6، إلا أن RFC 7707 يُشير إلى أن الأنماط الناتجة عن بعض تقنيات وخوارزميات تكوين عناوين IPv6 تسمح بمسح العناوين في العديد من سيناريوهات العالم الحقيقي. [ 39 ]

تمثيل العنوان

تُمثَّل عناوين IPv6 المكونة من 128 بتًا في 8 مجموعات، كل مجموعة تتكون من 16 بتًا. تُكتب كل مجموعة على شكل أربعة أرقام سداسية عشرية (تُسمى أحيانًا hextets [ 40 ] [ 41 ] أو بشكل أكثر رسمية hexadectets [ 42 ] وبشكل غير رسمي quibble أو quad-nibble [ 42 ] )، وتُفصل المجموعات بنقطتين رأسيتين (:). مثال على هذا التمثيل هو 2001:0db8:0000:0000:0000:ff00:0042:8329 .

لأغراض التسهيل والوضوح، يمكن اختصار تمثيل عنوان IPv6 وفقًا للقواعد التالية:

  • تُحذف صفرة واحدة أو أكثر من الأصفار البادئة لأي مجموعة من الأرقام السداسية عشرية، ويُجرى ذلك عادةً على جميع الأصفار البادئة. على سبيل المثال، تُحوّل المجموعة 0042 إلى 42 ، وتُحوّل المجموعة 0000 إلى 0 .
  • تُستبدل المقاطع المتتالية من الأصفار بنقطتين رأسيتين (::). لا يجوز استخدام هذا إلا مرة واحدة في العنوان، لأن الاستخدام المتكرر سيجعل العنوان غير قابل للتحديد. لا يجوز استخدام نقطتين رأسيتين للدلالة على حذف مقطع واحد من الأصفار. [ 43 ] : §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 [ 44 ] ويتم اختصاره إلى ::1 باستخدام كلا القاعدتين.

بما أن عنوان IPv6 قد يكون له أكثر من تمثيل، فقد أصدرت فرقة عمل هندسة الإنترنت (IETF) معيارًا مقترحًا لتمثيله نصيًا . [ 43 ] ولأن عناوين IPv6 تحتوي على نقطتين رأسيتين، وتستخدم عناوين URL النقطتين الرأسيتين لفصل المضيف عن رقم المنفذ، يجب وضع عنوان IPv6 المستخدم كجزء المضيف من عنوان URL بين قوسين مربعين، [ 45 ] على سبيل المثال http://[2001:db8:4006:812::200e] أو http://[2001:db8:4006:812::200e]:8080/path/page.html .

بنية عنوان البث الأحادي المحلي للرابط في IPv6

تتطلب جميع واجهات مضيفات IPv6 عنوانًا محليًا للرابط ، يبدأ بالبادئة fe80:: / 10. يلي هذه البادئة 54 بتًا يمكن استخدامها لتقسيم الشبكة الفرعية، على الرغم من أنها تُضبط عادةً على أصفار، ثم مُعرّف واجهة مكون من 64 بتًا. يستطيع المضيف حساب مُعرّف الواجهة وتعيينه بنفسه دون الحاجة إلى وجود أو تعاون أي مكون شبكة خارجي مثل خادم DHCP، وذلك في عملية تُسمى التكوين التلقائي للعنوان المحلي للرابط .

كانت البتات الـ 64 السفلى من عنوان الارتباط المحلي (اللاحقة) تُستمد في الأصل من عنوان MAC لبطاقة واجهة الشبكة الأساسية. ولأن هذه الطريقة في تخصيص العناوين كانت تُسبب تغييرات غير مرغوب فيها في العناوين عند استبدال بطاقات الشبكة المعيبة، ولأنها كانت تعاني أيضًا من عدد من مشكلات الأمان والخصوصية، فقد استبدلت RFC 8064 الطريقة الأصلية القائمة على عنوان MAC بالطريقة القائمة على التجزئة المحددة في RFC 7217 .  

تفرد العنوان وطلب جهاز التوجيه

يستخدم بروتوكول IPv6 آلية جديدة لربط عناوين IP بعناوين طبقة الربط (مثل عناوين MAC )، لأنه لا يدعم أسلوب العنونة بالبث ، الذي تعتمد عليه وظيفة بروتوكول تحليل العناوين (ARP) في IPv4. يُطبّق IPv6 بروتوكول اكتشاف الجوار (NDP، ND) في طبقة الربط ، والذي يعتمد على بروتوكول ICMPv6 والإرسال متعدد البث . [ 8 ] : تتحقق أجهزة IPv6 من تفرد عناوين IPv6 الخاصة بها في الشبكة المحلية (LAN) عن طريق إرسال رسالة طلب الجوار، تطلب فيها عنوان طبقة الربط الخاص بعنوان IP. إذا كان أي جهاز آخر في الشبكة المحلية يستخدم هذا العنوان، فإنه يستجيب. [ 46 ]

يقوم المضيف الذي يُنشئ واجهة IPv6 جديدة أولاً بإنشاء عنوان محلي فريد للرابط باستخدام إحدى الآليات المصممة لإنشاء عنوان فريد. في حال اكتشاف عنوان غير فريد، يمكن للمضيف المحاولة مرة أخرى باستخدام عنوان جديد. بمجرد إنشاء عنوان محلي فريد للرابط، يحدد مضيف IPv6 ما إذا كانت الشبكة المحلية متصلة عبر هذا الرابط بأي واجهة موجه تدعم IPv6. ويتم ذلك عن طريق إرسال رسالة طلب موجه ICMPv6 إلى مجموعة البث المتعدد all-routers [ 47 ] مع عنوانه المحلي للرابط كمصدر. إذا لم يتلقَّ المضيف أي رد بعد عدد محدد مسبقًا من المحاولات، يستنتج أنه لا توجد موجهات متصلة. أما إذا تلقى ردًا، يُعرف باسم إعلان الموجه، من موجه، فإن الرد يتضمن معلومات تكوين الشبكة للسماح بإنشاء عنوان فريد عالميًا مع بادئة شبكة أحادية البث مناسبة. [ 48 ] يوجد أيضًا بتان للإشارة تُخبر المضيف ما إذا كان ينبغي عليه استخدام DHCP للحصول على مزيد من المعلومات والعناوين.

  • يشير بت الإدارة إلى ما إذا كان ينبغي على المضيف استخدام DHCP للحصول على عناوين إضافية بدلاً من الاعتماد على عنوان تم تكوينه تلقائيًا من إعلان جهاز التوجيه.
  • يشير البت الآخر إلى ما إذا كان ينبغي على المضيف الحصول على معلومات أخرى من خلال بروتوكول DHCP أم لا. تتكون المعلومات الأخرى من خيار واحد أو أكثر من خيارات معلومات البادئة للشبكات الفرعية التي يتصل بها المضيف، ومدة صلاحية البادئة، وعلامتين: [ 46 ]
    • On-link: إذا تم تعيين هذا العلم، فسيتعامل المضيف مع جميع العناوين الموجودة على الشبكة الفرعية المحددة على أنها متصلة بالشبكة وسيرسل الحزم مباشرة إليها بدلاً من إرسالها إلى جهاز توجيه طوال مدة العمر المحددة.
    • العنوان: يشير هذا العلم إلى المضيف لإنشاء عنوان عالمي فعليًا.

العنونة العالمية

بنية عنوان البث الأحادي العالمي في IPv6

تتشابه آلية تخصيص العناوين العالمية مع آلية إنشاء العناوين المحلية. ويتم توفير البادئة من إعلانات الموجه على الشبكة. وتؤدي إعلانات البادئات المتعددة إلى تكوين عناوين متعددة. [ 46 ]

يتطلب التكوين التلقائي للعناوين بدون حالة (SLAAC) نطاق عناوين / 64 . [ 7 ] تُخصص سجلات الإنترنت المحلية نطاقات / 32 على الأقل ، والتي تُوزعها على الشبكات الفرعية. [ 49 ] نصت التوصية الأولية الصادرة في سبتمبر 2001 على تخصيص شبكة فرعية / 48 لمواقع المستهلكين النهائيين. [ 50 ] وفي مارس 2011، جرى تحسين هذه التوصية: [ 51 ] توصي فرقة عمل هندسة الإنترنت (IETF ) بمنح المواقع المنزلية نطاقًا أكبر بكثير من نطاق / 64 واحد ، ولكنها لا توصي بمنح كل موقع منزلي نطاق / 48 . وتُؤخذ نطاقات / 56 بعين الاعتبار بشكل خاص. ويبقى أن نرى ما إذا كانت شركات تزويد خدمة الإنترنت ستلتزم بهذه التوصية. فعلى سبيل المثال، خلال التجارب الأولية، مُنح عملاء شركة كومكاست شبكة واحدة من نطاق / 64 . [ 52 ]

IPv6 في نظام أسماء النطاقات

في نظام أسماء النطاقات (DNS)، تُربط أسماء المضيفين بعناوين IPv6 بواسطة سجلات موارد AAAA (رباعية A). وللحل العكسي ، حجزت IETF النطاق ip6.arpa ، حيث يُقسّم نطاق الأسماء هرميًا بواسطة التمثيل السداسي العشري المكون من رقم واحد لوحدات النصف بايت (4 بتات) من عنوان IPv6. [ 53 ]

عندما يستعلم جهاز مضيف ثنائي البروتوكول (IPv6 وIPv4) من خادم DNS لحل اسم نطاق مؤهل بالكامل (FQDN)، يرسل عميل DNS الخاص بالمضيف طلبين، أحدهما للاستعلام عن سجلات AAAA والآخر عن سجلات A، بهذا الترتيب افتراضيًا. إذا أعاد خادم DNS كلا النوعين من العناوين، وكان هناك مسار متاح، يُفضّل عنوان IPv6 على عنوان IPv4. مع ذلك، قد يكون نظام تشغيل المضيف مُهيأً لاختيار عنوان بديل. [ 54 ] [ 55 ]

استُخدم نوع سجل بديل في التطبيقات المبكرة لنظام أسماء النطاقات (DNS) لبروتوكول IPv6، مصمم لتسهيل إعادة ترقيم الشبكة. استُخدم سجل موارد A6 للبحث الأمامي، مُكمَّلًا بعدد من الابتكارات الأخرى مثل تسميات السلاسل الثنائية وسجلات DNAME . [ 56 ] بعد مناقشة مزايا وعيوب كلا النظامين، [ 57 ] تم إيقاف استخدام سجلات موارد A6 وجعلها تجريبية. [ 58 ]

آليات الانتقال

لا يُتوقع أن يحل بروتوكول IPv6 محل بروتوكول IPv4 بشكل فوري. سيستمر كلا البروتوكولين في العمل بالتوازي لبعض الوقت. لذلك، ثمة حاجة إلى آليات انتقالية لبروتوكول IPv6 لتمكين أجهزة IPv6 من الوصول إلى خدمات IPv4، وللسماح لأجهزة وشبكات IPv6 المعزولة بالتواصل فيما بينها عبر بنية IPv4 التحتية. [ 59 ]

بحسب سيلفيا هاجن ، يُعدّ تطبيق بروتوكولي IPv4 وIPv6 معًا على الأجهزة أسهل طريقة للانتقال إلى IPv6. [ 60 ] تستخدم العديد من آليات الانتقال الأخرى تقنية النفق لتغليف حركة مرور IPv6 داخل شبكات IPv4 والعكس صحيح. هذا حل غير مثالي، إذ يُقلّل من وحدة الإرسال القصوى (MTU) للرابط، وبالتالي يُعقّد عملية اكتشاف MTU للمسار ، وقد يزيد من زمن الاستجابة . [ 61 ] [ 62 ]

تنفيذ بروتوكول الإنترنت ثنائي المكدس

توفر تطبيقات بروتوكول الإنترنت ثنائية المكدس حزم بروتوكولات IPv4 وIPv6 كاملة في نظام تشغيل الحاسوب أو جهاز الشبكة فوق تطبيق الطبقة الفيزيائية المشتركة ، مثل الإيثرنت . وهذا يسمح للأجهزة المضيفة ثنائية المكدس بالمشاركة في شبكات IPv6 وIPv4 في آن واحد. [ 63 ]

يمتلك الجهاز الذي يدعم بروتوكولي IPv4 وIPv6 عنوان IPv4 وعنوان IPv6، ويمكنه التواصل مع الأجهزة الأخرى في الشبكة المحلية أو الإنترنت باستخدام أيٍّ منهما. يستخدم كلا بروتوكولي IP بروتوكول DNS لحلّ أسماء النطاقات المؤهلة بالكامل وعناوين IP، ولكن يتطلب دعم بروتوكولي IPv4 وIPv6 أن يكون خادم DNS قادرًا على حلّ كلا النوعين من العناوين. يحتفظ خادم DNS هذا بعناوين IPv4 في سجلات A وعناوين IPv6 في سجلات AAAA. بناءً على الوجهة المراد الوصول إليها، قد يُعيد خادم أسماء DNS عنوان IPv4 أو IPv6، أو كليهما. يجب تهيئة آلية اختيار العنوان الافتراضية، أو البروتوكول المُفضّل، إما على الأجهزة المضيفة أو على خادم DNS.

أصدرت فرقة عمل هندسة الإنترنت (IETF) بروتوكول Happy Eyeballs لدعم التطبيقات ثنائية البروتوكول، بحيث يمكنها الاتصال باستخدام كلٍ من IPv4 وIPv6، مع تفضيل اتصال IPv6 عند توفره. مع ذلك، يجب تطبيق ثنائية البروتوكول على جميع أجهزة التوجيه بين المضيف والخدمة التي خصص لها خادم DNS عنوان IPv6. ينبغي تهيئة عملاء ثنائية البروتوكول لتفضيل IPv6 فقط إذا كانت الشبكة قادرة على إعادة توجيه حزم IPv6 باستخدام إصدارات IPv6 من بروتوكولات التوجيه . عند تطبيق بروتوكولات الشبكة ثنائية البروتوكول، يمكن ترحيل طبقة التطبيق إلى IPv6. [ 64 ] [ 65 ] على الرغم من دعم أنظمة التشغيل الرئيسية وموردي أجهزة الشبكة لثنائية البروتوكول، إلا أن أجهزة الشبكات والخوادم القديمة لا تدعم IPv6.

عملاء مزودي خدمة الإنترنت الذين لديهم بروتوكول IPv6 عام

آلية تخصيص بادئات IPv6 مع IANA وRIRs ومزودي خدمة الإنترنت

يتزايد لجوء مزودي خدمة الإنترنت إلى تزويد عملائهم من الشركات والأفراد بعناوين IPv6 أحادية البث العالمية المتاحة للعامة. مع ذلك، إذا كان بروتوكول IPv4 لا يزال مستخدمًا في الشبكة المحلية (LAN)، ولم يكن لدى مزود خدمة الإنترنت سوى عنوان IPv6 واحد متاح للعامة، فسيتم تحويل عناوين IPv4 الخاصة بالشبكة المحلية إلى عنوان IPv6 متاح للعامة باستخدام NAT64 ، وهي آلية لترجمة عناوين الشبكة (NAT). بعض مزودي خدمة الإنترنت لا يستطيعون تزويد عملائهم بعناوين IPv4 وIPv6 متاحة للعامة، وبالتالي لا يدعمون الشبكات ثنائية البروتوكول، لأن بعضهم قد استنفد مخزون عناوين IPv4 المتاحة للتوجيه عالميًا. في الوقت نفسه، لا يزال عملاء مزودي خدمة الإنترنت يحاولون الوصول إلى خوادم الويب التي تعمل ببروتوكول IPv4 وغيرها من الوجهات. [ 66 ]

حصلت نسبة كبيرة من مزودي خدمات الإنترنت في جميع مناطق سجلات الإنترنت الإقليمية (RIR) على نطاق عناوين IPv6. ويشمل ذلك العديد من مزودي خدمات الإنترنت ومشغلي شبكات الهاتف المحمول الرئيسيين في العالم ، مثل Verizon Wireless و StarHub Cable و Chubu Telecommunications و Kabel Deutschland و Swisscom و T-Mobile و Internode و Telefónica . [ 67 ]

بينما لا تزال بعض شركات تزويد خدمة الإنترنت تخصص عناوين IPv4 فقط لعملائها، فإن العديد منها تخصص عناوين IPv6 فقط أو عناوين IPv4 وIPv6 معًا. وتشير تقارير شركات تزويد خدمة الإنترنت إلى أن نسبة حركة مرور IPv6 من العملاء عبر شبكاتها تتراوح بين 20% و40%، ولكن بحلول منتصف عام 2017، لم تكن حركة مرور IPv6 تمثل سوى جزء ضئيل من إجمالي حركة المرور في العديد من نقاط تبادل الإنترنت الرئيسية (IXPs). فقد أفادت AMS-IX بأنها 2%، بينما أفادت SeattleIX بأنها 7%. وكشف استطلاع رأي أُجري عام 2017 أن العديد من عملاء DSL الذين يتلقون الخدمة من مزود خدمة إنترنت يدعم بروتوكول IPv6 المزدوج لم يطلبوا من خوادم DNS تحويل أسماء النطاقات المؤهلة بالكامل إلى عناوين IPv6. كما وجد الاستطلاع أن غالبية حركة المرور من موارد خوادم الويب المهيأة لـ IPv6 لا تزال تُطلب وتُقدم عبر IPv4، ويعود ذلك في الغالب إلى عملاء مزودي خدمة الإنترنت الذين لا يستخدمون ميزة بروتوكول IPv4 المزدوج التي يوفرها مزود الخدمة، وإلى حد أقل إلى عملاء مزودي خدمة الإنترنت الذين يدعمون IPv4 فقط. [ 68 ]

حفر الأنفاق

تم توضيح الأساس التقني لتقنية النفق، أو تغليف حزم IPv6 داخل حزم IPv4، في RFC 4213. عندما كانت البنية التحتية للإنترنت تعتمد على IPv4 فقط، كان بروتوكول 6to4 أحد بروتوكولات النفق شائعة الاستخدام . [ 69 ] كما استُخدم نفق Teredo بكثرة لدمج شبكات LAN التي تعمل بنظام IPv6 مع البنية التحتية للإنترنت التي تعمل بنظام IPv4. تم توضيح Teredo في RFC 4380، وهو يسمح لشبكات LAN التي تعمل بنظام IPv6 بالنقل عبر شبكات IPv4، وذلك بتغليف حزم IPv6 داخل UDP. يُعد مرحل Teredo جهاز توجيه IPv6 يعمل كوسيط بين خادم Teredo وشبكة IPv6 الأصلية. كان من المتوقع أن ينتشر استخدام 6to4 وTeredo على نطاق واسع حتى تتحول شبكات مزودي خدمة الإنترنت إلى IPv6 الأصلي، ولكن بحلول عام 2014، أظهرت إحصائيات جوجل أن استخدام كلا الآليتين انخفض إلى الصفر تقريبًا. [ 70 ]

عناوين IPv6 المُرتبطة بـ IPv4

عنوان أحادي البث متوافق مع IPv4 IPv6
عنوان IPv6 أحادي البث المُطابق لـ IPv4

تتعرف تطبيقات IPv6/IPv4 الهجينة ثنائية المكدس على فئة خاصة من العناوين، وهي عناوين IPv6 المُطابقة لـ IPv4. [ 71 ] : §2.2.3 [ 7 ] تُكتب هذه العناوين عادةً ببادئة 96 بت بتنسيق IPv6 القياسي، وتُكتب البتات الـ 32 المتبقية بالترميز العشري النقطي المعتاد لـ IPv4.

تتكون العناوين في هذه المجموعة من بادئة طولها 80 بت من الأصفار، تليها 16 بت من الآحاد، أما الـ 32 بت المتبقية، وهي الأقل أهمية، فتحتوي على عنوان IPv4. على سبيل المثال، يُمثل ::ffff:192.0.2.128 عنوان IPv4 رقم 192.0.2.128 . كان هناك تنسيق سابق يُسمى "عنوان IPv6 متوافق مع IPv4"، وهو ::192.0.2.128 ؛ إلا أن هذا الأسلوب أصبح مُهملًا. [ 7 ]

نظراً للاختلافات الداخلية الكبيرة بين حزم بروتوكولات IPv4 وIPv6، فإن بعض الوظائف الأساسية المتاحة للمبرمجين في حزمة IPv6 لا تعمل بنفس الطريقة عند استخدامها مع عناوين IPv4 المُرتبطة. بعض حزم IPv6 الشائعة لا تُفعّل ميزة عناوين IPv4 المُرتبطة، إما لأن حزمتي IPv6 وIPv4 تُنفّذان بشكل منفصل (مثل Microsoft Windows 2000 وXP وServer 2003)، أو لأسباب أمنية (مثل OpenBSD ). [ 72 ] في هذه الأنظمة، يجب على البرنامج فتح منفذ منفصل لكل بروتوكول IP يستخدمه. في بعض الأنظمة، مثل نواة Linux و NetBSD و FreeBSD ، يتم التحكم في هذه الميزة بواسطة خيار المنفذ IPV6_V6ONLY. [ 73 ] : 22

يُعدّ بادئة العنوان 64:ff9b::/96 فئة من عناوين IPv6 المضمنة في IPv4، وتُستخدم في طرق تحويل NAT64 . [ 74 ] على سبيل المثال، يُمثّل 64:ff9b::192.0.2.128 عنوان IPv4 رقم 192.0.2.128 .

حماية

قد ينشأ عدد من التداعيات الأمنية عن استخدام بروتوكول IPv6. بعضها قد يكون مرتبطًا ببروتوكولات IPv6 نفسها، بينما قد يكون البعض الآخر مرتبطًا بعيوب في التنفيذ. [ 75 ] [ 76 ]

شبكات الظل

قد يؤدي إضافة عُقد مُفعّل عليها بروتوكول IPv6 افتراضيًا من قِبل مُصنِّع البرامج إلى إنشاء شبكات ظلّية غير مقصودة ، مما يتسبب في تدفق بيانات IPv6 إلى شبكات تعتمد على إدارة أمان IPv4 فقط. وقد يحدث هذا أيضًا مع ترقيات أنظمة التشغيل، عندما يُفعِّل نظام التشغيل الأحدث بروتوكول IPv6 افتراضيًا، بينما لم يُفعِّله النظام الأقدم. وقد يؤدي عدم تحديث البنية التحتية للأمان لاستيعاب IPv6 إلى تجاوز بيانات IPv6 لها. [ 77 ] وقد ظهرت الشبكات الظلّية في شبكات الأعمال التي تستبدل فيها المؤسسات أنظمة Windows XP التي لا تحتوي على حزمة بروتوكولات IPv6 مُفعّلة افتراضيًا، بأنظمة Windows 7 التي تحتوي عليها. [ 78 ] ولذلك، أوصى بعض مُنفِّذي حزمة بروتوكولات IPv6 بتعطيل عناوين IPv4 المُخصصة واستخدام شبكة ثنائية الحزمة عند الحاجة إلى دعم كلٍّ من IPv4 وIPv6. [ 79 ]

تجزئة حزم IPv6

أظهرت الأبحاث أن استخدام التجزئة يمكن استغلاله للتحايل على ضوابط أمان الشبكة، على غرار بروتوكول IPv4. ونتيجةً لذلك، يُشترط الآن أن يحتوي الجزء الأول من حزمة IPv6 على سلسلة ترويسة IPv6 كاملة، [ 80 ] مما يحظر بعض حالات التجزئة الشاذة للغاية. بالإضافة إلى ذلك، ونتيجةً للأبحاث المتعلقة بالتحايل على بروتوكول RA-Guard، تم إيقاف استخدام التجزئة مع بروتوكول اكتشاف الجوار ، [ 81 ] ويُنصح بتجنبه مع بروتوكول اكتشاف الجوار الآمن (SEND). [ 82 ]

التقييس من خلال طلبات التعليقات

مقترحات فريق العمل

جدول زمني للمعايير التي تحكم بروتوكول الإنترنت الإصدار السادس (IPv6)

نظراً للنمو العالمي المتوقع للإنترنت ، بدأت فرقة عمل هندسة الإنترنت (IETF) في أوائل التسعينيات جهوداً لتطوير بروتوكول IP من الجيل التالي. [ 8 ] : 209 وبحلول بداية عام 1992، ظهرت عدة مقترحات لنظام عناوين إنترنت موسع، وفي نهاية عام 1992 أعلنت فرقة عمل هندسة الإنترنت عن دعوة لتقديم أوراق بحثية. [ 83 ]

في سبتمبر 1993، أنشأت فرقة عمل هندسة الإنترنت (IETF) قسمًا مؤقتًا ومخصصًا لتقنية الجيل التالي لبروتوكول الإنترنت (IPng) لمعالجة هذه القضايا تحديدًا. قاد هذا القسم الجديد أليسون مانكين وسكوت برادنر ، وضمّ مديريةً مؤلفةً من 15 مهندسًا من خلفيات متنوعة لوضع التوجهات ومراجعة الوثائق الأولية: [ 10 ] [ 84 ] وكان أعضاء فريق العمل هم: ج. ألارد (مايكروسوفت)، وستيف بيلوفين (AT&T)، وجيم باوند ( شركة ديجيتال إكويبمنت )، وروس كالون (ويلفليت)، وبرايان كاربنتر (سيرن)، وديف كلارك (معهد ماساتشوستس للتكنولوجيا)، وجون كوران (نيرنت)، وستيف ديرينغ (زيروكس)، ودينو فاريناتشي (سيسكو)، وبول فرانسيس (NTT)، وإريك فليشمان (بوينغ)، ومارك كنوبير (أميريتك)، وغريغ مينشال (نوفيل)، وروب أولمان (لوتس)، وليكسيا تشانغ (زيروكس). [ 85 ]

اعتمدت فرقة عمل هندسة الإنترنت نموذج IPng في 25 يوليو 1994، مع تشكيل العديد من مجموعات العمل المعنية بـ IPng. [ 10 ] وبحلول عام 1996، صدرت سلسلة من وثائق RFC التي تحدد بروتوكول الإنترنت الإصدار 6 (IPv6)، بدءًا من RFC 1883. (استُخدم الإصدار 5 بواسطة بروتوكول الإنترنت التجريبي للتدفق ). 

توحيد معايير RFC

كانت أول وثيقة RFC تُوحّد بروتوكول IPv6 هي RFC 1883 في عام 1995. [ 86 ] وفي عام 1998، أصبحت RFC 2460 هي RFC لبروتوكول IPv6. [ 8 ] : 209. في يوليو 2017، حلت RFC 8200 محل RFC 2460 ، مما رفع مستوى IPv6 إلى "معيار الإنترنت" (أعلى مستوى نضج لبروتوكولات IETF). [ 3 ] تُعد RFC 8201 معيارًا ذا صلة ببروتوكول IPv6، حيث تصف كيفية اكتشاف مسار الشبكة الأكثر كفاءة من المصدر إلى الوجهة، والذي يتميز بأكبر حجم حزمة مسموح به لتجنب تجزئة حزم IP ، وبالتالي الحفاظ على أداء نقل الحزم.   

الانتشار

تخصيصات IPv6 الشهرية لكل سجل إنترنت إقليمي (RIR)

أدى إدخال التوجيه بين النطاقات بدون فئات (CIDR) في عام 1993 في توجيه وتخصيص عناوين IP للإنترنت، والاستخدام المكثف لترجمة عناوين الشبكة (NAT)، إلى تأخير استنفاد عناوين IPv4 للسماح بنشر IPv6، الذي بدأ في يوليو 1999. [ 87 ]

كانت الجامعات من أوائل الجهات التي تبنت بروتوكول IPv6. قامت جامعة فرجينيا للتكنولوجيا بتطبيق IPv6 في موقع تجريبي عام 2004، ثم وسّعت نطاق استخدامه ليشمل شبكة الحرم الجامعي بأكملها . وبحلول عام 2016، بلغت نسبة حركة البيانات على شبكتها التي تستخدم IPv6 82%. أما كلية إمبريال كوليدج لندن، فقد بدأت تطبيق IPv6 تجريبياً عام 2003، وبحلول عام 2016، تراوحت نسبة حركة البيانات التي تستخدم IPv6 على شبكاتها بين 20% و40%. وقد نتج جزء كبير من هذه الحركة عن تعاونها في مجال فيزياء الطاقة العالية مع مركز سيرن ، الذي يعتمد كلياً على IPv6. [ 88 ]

يدعم نظام أسماء النطاقات (DNS) بروتوكول IPv6 منذ عام 2008. وفي العام نفسه، استُخدم بروتوكول IPv6 لأول مرة في حدث عالمي كبير خلال دورة الألعاب الأولمبية الصيفية في بكين 2008. [ 89 ] [ 90 ]

بحلول عام 2011، كانت جميع أنظمة التشغيل الرئيسية المستخدمة على أجهزة الكمبيوتر الشخصية وأنظمة الخوادم تدعم بروتوكول IPv6 بجودة إنتاجية عالية. وشكّلت أنظمة الهواتف الخلوية مجالًا واسعًا لنشر أجهزة بروتوكول الإنترنت، حيث انتقلت خدمة الهاتف المحمول من تقنيات الجيل الثالث (3G) إلى تقنيات الجيل الرابع (4G )، والتي تُقدّم فيها خدمة الصوت عبر بروتوكول الإنترنت (VoIP) التي تستفيد من تحسينات IPv6. في عام 2009، أصدرت شركة فيريزون، مشغّل شبكات الهاتف الخلوي في الولايات المتحدة ، المواصفات الفنية للأجهزة التي ستعمل على شبكاتها "من الجيل التالي". [ 91 ] وقد اشترطت هذه المواصفات تشغيل IPv6 وفقًا لمواصفات الإصدار الثامن من مشروع شراكة الجيل الثالث (3GPP) (مارس 2009) ، وألغت دعم IPv4 كخيار إضافي. [ 91 ]

استمر نشر بروتوكول IPv6 في البنية التحتية للإنترنت . في عام 2018، لم يُعلن سوى 25.3% من حوالي 54,000 نظام مستقل عن كلٍ من بادئات IPv4 وIPv6 في قاعدة بيانات توجيه بروتوكول بوابة الحدود (BGP) العالمية. كما أعلنت 243 شبكة أخرى عن بادئة IPv6 فقط. وتواجدت شبكات عبور البنية التحتية للإنترنت التي تدعم IPv6 في جميع دول العالم، باستثناء أجزاء من أفريقيا والشرق الأوسط والصين. [ 92 ] : 6. بحلول منتصف عام 2018، قامت بعض شركات تزويد خدمات الإنترنت الأوروبية الكبرى بنشر IPv6 لغالبية عملائها. فقد زودت شركة Sky UK أكثر من 86% من عملائها ببروتوكول IPv6، بينما بلغت نسبة نشر IPv6 لدى شركة Deutsche Telekom 56%، ولدى شركة XS4ALL في هولندا 73%، وفي بلجيكا، بلغت نسبة نشر IPv6 لدى شركتي VOO و Telenet 73% و63% على التوالي. [ 92 ] : 7 في الولايات المتحدة، بلغت نسبة استخدام بروتوكول IPv6 لدى مزود خدمة الإنترنت عريض النطاق Xfinity حوالي 66%. وفي عام 2018، أفادت Xfinity بوجود ما يقدر بنحو 36.1 مليون مستخدم لبروتوكول IPv6، بينما أفادت AT&T بوجود 22.3 مليون مستخدم لبروتوكول IPv6. [ 92 ] : 7-8

حتى يونيو 2026، تُشير إحصائيات جوجل إلى أن حوالي 50% من المستخدمين يصلون إلى خدمات جوجل عبر اتصال IPv6 الأصلي. [ 93 ] ويختلف معدل التبني اختلافًا كبيرًا باختلاف المناطق، حيث سجلت دول مثل الهند وفرنسا وألمانيا معدلات تبني تتجاوز 70%، بينما تتخلف دول أخرى عن الركب. [ 94 ]

مشاكل التناظر

هناك نزاع قائم بشأن تبادل البيانات بين شركتي Hurricane Electric و Cogent Communications على بروتوكول IPv6، حيث يرفض مزودا الشبكة تبادل البيانات. [ 95 ]

انظر أيضاً

مراجع

  1. "الأسئلة الشائعة" . فريق عمل IPv6 في نيوزيلندا. مؤرشف من الأصل بتاريخ 29 يناير 2019. تم الاطلاع عليه بتاريخ 26 أكتوبر 2015 .
  2. 1 2 3 4 5 6 إس. ديرينغ ؛ آر. هيندن (ديسمبر 1998). مواصفات بروتوكول الإنترنت، الإصدار 6 (IPv6) . مجموعة عمل الشبكة. doi : 10.17487/RFC2460 . RFC 2460 .مُلغى. تم إلغاؤه بموجب RFC 8200. يُلغي RFC 1883. تم تحديثه بموجب RFC 5095 و 5722 و 5871 و 6437 و 6564 و 6935 و 6946 و 7045 و 7112 .   
  3. 1 2 إس. ديرينغ ؛ آر. هيندن (يوليو 2017). مواصفات بروتوكول الإنترنت، الإصدار 6 (IPv6) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC8200 . STD 86. RFC 8200 .معيار الإنترنت 86. عفا عليه الزمن RFC 2460 . 
  4. صديقي، أفتاب (17 يوليو 2017). "RFC 8200 - تم توحيد بروتوكول IPv6" . جمعية الإنترنت . مؤرشف من الأصل في 23 أكتوبر 2023. تم الاطلاع عليه في 25 فبراير 2018 .
  5. ديرينغ، ستيف إي.؛ هيندن، بوب (فبراير 2006). بنية عنونة بروتوكول الإنترنت الإصدار 6 (تقرير). فريق عمل هندسة الإنترنت.
  6. كاوامورا، سييتشي؛ كاواشيما، ماسانوبو (أغسطس 2010). توصية بشأن تمثيل عناوين IPv6 نصيًا (تقرير). فريق عمل هندسة الإنترنت.
  7. 1 2 3 4 5 ر. هيندن؛ س. ديرينغ (فبراير 2006). بنية عنونة بروتوكول الإنترنت الإصدار 6. مجموعة عمل الشبكة. doi : 10.17487/RFC4291 . RFC 4291 .مسودة معيار. تلغي RFC 3513. تم تحديثها بواسطة RFC 5952 و 6052 و 7136 و 7346 و 7371 و 8064 .  
  8. 1 2 3 4 روزن، رامي (2014). شبكات نواة لينكس: التنفيذ والنظرية . نيويورك: أبريس. ISBN 9781430261971. OCLC 869747983 . 
  9. مؤتمر جوجل لبروتوكول الإنترنت الإصدار السادس (IPv6) لعام ٢٠٠٨: كيف سيبدو الإنترنت في ظل بروتوكول الإنترنت الإصدار السادس؟ يبدأ الحدث الساعة ١٣:٣٥. مؤرشف من الأصل بتاريخ ١١ ديسمبر ٢٠٢١. تم الاطلاع عليه بتاريخ ١٠ يونيو ٢٠٢٦ .
  10. 1 2 3 برادنر، س.؛ مانكين، أ. (يناير 1995). التوصية الخاصة ببروتوكول الجيل التالي لبروتوكول الإنترنت . IETF . doi : 10.17487/RFC1752 . RFC 1752 .
  11. «نفاد مساحة عناوين IPv4 المتاحة» . NRO.net . مونتيفيديو : منظمة موارد الأرقام. 3 فبراير 2011. مؤرشف من الأصل في 18 يناير 2024. تم الاطلاع عليه في 19 يناير 2022 .
  12. رشيد، فهميدة (1 فبراير 2011). "نفاد عناوين IPv4 ليس سببًا فوريًا للقلق بشأن IPv6 قيد التطوير" . eWeek . تم الاطلاع عليه بتاريخ 23 يونيو 2012 .{{cite web}}: CS1 maint: url-status ( link )
  13. وارد، مارك (14 سبتمبر 2012). "أوروبا تصل إلى حدود عناوين الإنترنت القديمة" . بي بي سي نيوز . مؤرشف من الأصل في 5 نوفمبر 2023. تم الاطلاع عليه في 15 سبتمبر 2012 .
  14. هيوستن، جيف. "تقرير عناوين IPv4" . مؤرشف من الأصل في 10 يناير 2024.
  15. "أفرينيك تدخل المرحلة الثانية من استنفاد عناوين IPv4" . afrinic.net . 13 يناير 2020. تم الاطلاع عليه بتاريخ 10 يونيو 2026 .
  16. «نفدت عناوين IPv4 لدى مركز RIPE NCC» (بيان صحفي). مركز RIPE NCC . 25 نوفمبر 2019. مؤرشف من الأصل في 19 يناير 2019. تم الاطلاع عليه في 26 نوفمبر 2019 .
  17. 1 2 سي. بارتريدج؛ إف. كاستنهولز (ديسمبر 1994). المعايير الفنية لاختيار بروتوكول الإنترنت من الجيل التالي (IPng) . مجموعة عمل الشبكة. doi : 10.17487/RFC1726 . RFC 1726 .لأغراض إعلامية.
  18. إس. ديرينغ (أغسطس 1989). ملحقات المضيف للبث المتعدد عبر بروتوكول الإنترنت . مجموعة عمل الشبكة. doi : 10.17487/RFC1112 . STD 5. RFC 1112 .المعيار الخامس للإنترنت. يلغي المعيارين RFC 988 و 1054. تم تحديثه بواسطة المعيار RFC 2236 .  
  19. ب. سافولا؛ ب. هابرمان (نوفمبر 2004). تضمين عنوان نقطة الالتقاء (RP) في عنوان البث المتعدد IPv6 . مجموعة عمل الشبكة. doi : 10.17487/RFC3956 . RFC 3956 .معيار مقترح. تم تحديثه بواسطة RFC 7371. يحدّث RFC 3306 .  
  20. د. ثالر؛ م. هاندلي؛ د. إسترين (سبتمبر 2000). بنية تخصيص عناوين البث المتعدد للإنترنت . مجموعة عمل الشبكة. doi : 10.17487/RFC2908 . RFC 2908 .قديم. تم إلغاؤه بموجب RFC 6308 . 
  21. ب. هابرمان؛ د. ثالر (أغسطس 2002). عناوين البث المتعدد لبروتوكول IPv6 المستندة إلى بادئة البث الأحادي . مجموعة عمل الشبكة. doi : 10.17487/RFC3306 . RFC 3306 .المعيار المقترح. تم تحديثه بواسطة RFC 3956 و 4489 و 7371 . 
  22. 1 2 س. طومسون؛ ت. نارتن؛ ت. جينمي (سبتمبر 2007). التكوين التلقائي لعناوين IPv6 عديمة الحالة . مجموعة عمل الشبكة. doi : 10.17487/RFC4862 . RFC 4862 .مسودة معيار. تلغي RFC 2462. تم تحديثها بواسطة RFC 7527 .  
  23. م. كروفورد (أغسطس 2000). إعادة ترقيم الموجهات لبروتوكول IPv6 . مجموعة عمل الشبكة. doi : 10.17487/RFC2894 . RFC 2894 .المعيار المقترح.
  24. تي. نارتن؛ آر. دريفز؛ إس. كريشنان (سبتمبر 2007). "امتدادات الخصوصية لتكوين العناوين التلقائي عديم الحالة في IPv6" . www.ietf.org . تاريخ الاسترجاع: 13 مارس 2017 .
  25. ف. غونت؛ س. كريشنان؛ ت. نارتن؛ ر. دريفز (فبراير 2021). امتدادات العناوين المؤقتة لتكوين العناوين التلقائي عديم الحالة في IPv6 . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC8981 . ISSN 2070-1721 . RFC 8981 . المعيار المقترح. يلغي RFC 4941 . 
  26. "نظرة عامة على حزمة الشبكات المتقدمة لنظام التشغيل ويندوز إكس بي" . مايكروسوفت . مؤرشف من الأصل في 7 سبتمبر 2017. تم الاطلاع عليه في 15 أبريل 2019 .
  27. "امتدادات الخصوصية لبروتوكول IPv6 SLAAC" . جمعية الإنترنت . 8 أغسطس 2014. مؤرشف من الأصل في 23 أكتوبر 2023. تم الاطلاع عليه في 17 يناير 2020 .
  28. فيرغسون، ب.؛ بيركويتز، هـ. (يناير 1997). " نظرة عامة على إعادة ترقيم الشبكات: لماذا قد أرغب بها وما هي أصلاً؟" . IETF . doi : 10.17487/RFC2071 . RFC 2071. مؤرشف من الأصل في 7 يناير 2024. تم الاطلاع عليه في 10 يونيو 2026 . 
  29. بيركويتز، هـ . (يناير 1997). "دليل إعادة ترقيم أجهزة التوجيه" . IETF . doi : 10.17487/RFC2072 . RFC 2072. مؤرشف من الأصل في 8 يونيو 2023. تم الاطلاع عليه في 10 يونيو 2026 . 
  30. كوبر، أليسا؛ جونت، فرناندو؛ ثالر، ديف. توصية بشأن مُعرّفات واجهة IPv6 المستقرة . IETF . doi : 10.17487/RFC8064 . RFC 8064 .
  31. إي. جانكيويتش؛ ج. لوغني؛ ت. نارتن (ديسمبر 2011). متطلبات عقدة IPv6 . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6434 . ISSN 2070-1721 . RFC 6434 . مُلغى. ص 17. أُلغي بموجب RFC 8504. يُلغي RFC 4294. سابقًا، كان بروتوكول IPv6 يُلزم بتطبيق بروتوكول IPsec ويُوصي بنهج إدارة المفاتيح IKE. تُحدّث هذه الوثيقة تلك التوصية بجعل دعم بنية IPsec RFC4301 أمرًا مُستحسنًا لجميع عُقد IPv6.  
  32. سيلفيا هاجن (2014). أساسيات IPv6: دمج IPv6 في شبكة IPv4 الخاصة بك ( الطبعة الثالثة). سيباستوبول، كاليفورنيا: أورايلي ميديا. ص 196. ISBN   978-1-4493-3526-7. OCLC 881832733 . 
  33. زاك، إي. (يوليو 2013). "تقييم وقياس أداء أمان بروتوكول IPv6" . www.ipv6hackers.org . تم الاطلاع عليه بتاريخ 10 يونيو 2026 .
  34. غونت، ف. (مارس 2016). "الآثار التشغيلية لحزم IPv6 ذات رؤوس التمديد" . IETF . مؤرشف من الأصل في 27 أكتوبر 2023.
  35. ف. ديفارابالي؛ ر. واكيكاوا؛ أ. بيتريسكو؛ ب. ثوبيرت (يناير 2005). بروتوكول الدعم الأساسي لتنقل الشبكة (NEMO) . مجموعة عمل الشبكة. doi : 10.17487/RFC3963 . RFC 3963 .المعيار المقترح.
  36. د. بورمان؛ س. ديرينغ ؛ ر. هيندن (أغسطس 1999). حزم IPv6 . مجموعة عمل الشبكة. doi : 10.17487/RFC2675 . RFC 2675 .المعيار المقترح. يلغي RFC 2147 . 
  37. ك. نيكولز؛ س. بليك؛ ف. بيكر ؛ د. بلاك (ديسمبر 1998). تعريف حقل الخدمات المتباينة (حقل DS) في رؤوس IPv4 وIPv6 . مجموعة عمل الشبكة. doi : 10.17487/RFC2474 . RFC 2474 .معيار مقترح. يلغي المعيارين RFC 1455 و 1349 . تم تحديثه بواسطة المعايير RFC 3168 و 3260 و 8436 .  
  38. ك. راماكريشنان؛ س. فلويد؛ د. بلاك (سبتمبر 2001). إضافة إشعار الازدحام الصريح (ECN) إلى بروتوكول الإنترنت (IP ). مجموعة عمل الشبكة. doi : 10.17487/RFC3168 . RFC 3168 .معيار مقترح. يلغي RFC 2481. يُحدّث RFC 2474 و 2401 و 793 . تم تحديثه بواسطة RFC 4301 و 6040 و 8311 .   
  39. استطلاع الشبكة في شبكات IPv6 . IETF . doi : 10.17487/RFC7707 . RFC 7707 .
  40. غراتسياني، ريك (2012). أساسيات IPv6: مدخل مباشر لفهم IPv6 . دار نشر سيسكو . ص 55. ISBN  978-0-13-303347-2تم الاطلاع عليه بتاريخ 10 يونيو 2026 .
  41. كوفين، توم (2014). تخطيط عناوين IPv6: تصميم خطة عناوين للمستقبل . دار نشر أورايلي ميديا . ص 170. ISBN  978-1-4919-0326-1تم الاطلاع عليه بتاريخ 10 يونيو 2026 .
  42. 1 2 هورلي، إدوارد (2013). IPv6 عملي لمسؤولي أنظمة ويندوز . أبريس . ص 17. ISBN  978-1-4302-6371-5تم الاطلاع عليه بتاريخ 10 يونيو 2026 .
  43. 1 2 س. كاوامورا؛ م. كاواشيما (أغسطس 2010). توصية بشأن تمثيل نص عنوان IPv6 . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC5952 . ISSN 2070-1721 . RFC 5952 . المعيار المقترح. تحديثات RFC 4291 . 
  44. م. بلانشيه (أبريل 2008). عناوين IPv6 ذات الاستخدام الخاص . مجموعة عمل الشبكة. doi : 10.17487/RFC5156 . RFC 5156 .المعيار المقترح. تم إلغاؤه بموجب RFC 6890 . 
  45. تي. بيرنرز-لي ؛ آر. فيلدينغ ؛ إل. ماسينتر (يناير 2005). مُعرِّف الموارد الموحد (URI): الصيغة العامة . مجموعة عمل الشبكة. doi : 10.17487/RFC3986 . STD 66. RFC 3986 .المعيار 66 للإنترنت. يلغي المعايير RFC 2732 و 2396 و 1808 . تم تحديثه بواسطة المعايير RFC 6874 و 7320 و 8820 . يُحدّث المعيار RFC 1738 .   
  46. 1 2 3 نارتن، ت. (أغسطس 1999). "اكتشاف الجوار والتكوين التلقائي عديم الحالة في IPv6". مجلة IEEE للحوسبة عبر الإنترنت . 3 (4): 54-62 . Bibcode : 1999IIC.....3d..54N . doi : 10.1109/4236.780961 .
  47. نارتن، ت. (سبتمبر 2007). " اكتشاف الجوار لبروتوكول الإنترنت الإصدار السادس (IPv6)" . IETF . القسم 6.3.7. doi : 10.17487/RFC4861 . RFC 4861. مؤرشف من الأصل في 17 يناير 2024. تم الاطلاع عليه في 10 يونيو 2026 . 
  48. تومسون، س. (سبتمبر 2007). " التكوين التلقائي لعناوين IPv6 عديمة الحالة - القسم 5.5.1" . IETF . doi : 10.17487/RFC4862 . RFC 4862. مؤرشف من الأصل في 11 يناير 2024. تم الاطلاع عليه في 10 يونيو 2026 . 
  49. "سياسة تخصيص عناوين IPv6" . RIPE NCC . 8 فبراير 2011. مؤرشف من الأصل في 3 يونيو 2023. تم الاطلاع عليه في 27 مارس 2011 .
  50. IAB ؛ IESG (سبتمبر 2001). توصيات IAB/IESG بشأن تخصيص عناوين IPv6 للمواقع . مجموعة عمل الشبكة. doi : 10.17487/RFC3177 . RFC 3177 .قديم. تم إلغاؤه بموجب RFC 6177 . 
  51. تي. نارتن؛ جي. هوستون؛ إل. روبرتس (مارس 2011). تخصيص عناوين IPv6 للمواقع الطرفية . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6177 . ISSN 2070-1721 . BCP 157. RFC 6177 . أفضل الممارسات الحالية 157. يلغي RFC 3177 . 
  52. برزوزوفسكي، جون (31 يناير 2011). "كومكاست تُفعّل أول المستخدمين الذين يستخدمون بروتوكول IPv6 ثنائي المكدس الأصلي عبر DOCSIS" (بيان صحفي). كومكاست . مؤرشف من الأصل في 23 أكتوبر 2023. تم الاطلاع عليه في 15 أبريل 2019 .
  53. إس. طومسون؛ سي. هويتيما ؛ في. كسينانت؛ إم. سويسي (أكتوبر 2003). امتدادات نظام أسماء النطاقات لدعم بروتوكول الإنترنت الإصدار 6. مجموعة عمل الشبكة. doi : 10.17487/RFC3596 . STD 88. RFC 3596 .المعيار 88 للإنترنت. يلغي RFC 3152 و 1886 . 
  54. د. ثالر؛ ر. دريفز؛ أ. ماتسوموتو؛ ت. تشاون (سبتمبر 2012). د. ثالر (محرر). اختيار العنوان الافتراضي لبروتوكول الإنترنت الإصدار 6 (IPv6) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6724 . ISSN 2070-1721 . RFC 6724 . المعيار المقترح. يلغي RFC 3484 . 
  55. سيلفيا هاجن (2014). أساسيات IPv6: دمج IPv6 في شبكة IPv4 الخاصة بك . دار نشر أورايلي ميديا، ص 176. ISBN  9781449335267.
  56. م. كروفورد؛ س. هويتيما (يوليو 2000). امتدادات نظام أسماء النطاقات لدعم تجميع عناوين IPv6 وإعادة ترقيمها . مجموعة عمل الشبكة. doi : 10.17487/RFC2874 . RFC 2874 .تاريخي. تم تحديثه بواسطة RFC 3152 و 3226 و 3363 و 3364 . تحديثات RFC 1886 .  
  57. ر. أوستين (أغسطس 2002). المفاضلات في دعم نظام أسماء النطاقات (DNS) لبروتوكول الإنترنت الإصدار 6 (IPv6) . مجموعة عمل الشبكة. doi : 10.17487/RFC3364 . RFC 3364 .معلوماتية. تحديثات RFC 2673 و 2874 . 
  58. ر. بوش؛ أ. دوراند؛ ب. فينك؛ أ. غودموندسون؛ ت. هاين، محررون. (أغسطس 2002). تمثيل عناوين بروتوكول الإنترنت الإصدار 6 (IPv6) في نظام أسماء النطاقات (DNS) . مجموعة عمل الشبكة. doi : 10.17487/RFC3363 . RFC 3363 .معلوماتية. تحديثات RFC 2673 و 2874 . 
  59. "مقارنة آلية الانتقال إلى IPv6/الأنفاق" . Sixxs.net. مؤرشف من الأصل في 23 أكتوبر 2023. تم الاطلاع عليه في 20 يناير 2012 .
  60. سيلفيا هاجن (2014). أساسيات IPv6: دمج IPv6 في شبكة IPv4 الخاصة بك . دار نشر أورايلي ميديا، الصفحات 222-223 . ISBN  9781449335267.
  61. كاربنتر، ب. (أغسطس 2011). " إرشادات استشارية لنشر 6to4" . IETF . doi : 10.17487/RFC6343 . RFC 6343. مؤرشف من الأصل في 28 يناير 2023. تم الاطلاع عليه في 20 أغسطس 2012 . 
  62. "IPv6: استخدام بروتوكول مزدوج حيثما أمكن؛ استخدام نفق حيثما كان ذلك ضرورياً" . networkworld.com. 5 سبتمبر 2007. مؤرشف من الأصل في 20 يناير 2024. تم الاطلاع عليه في 27 نوفمبر 2012 .
  63. إي. نوردمارك؛ آر. جيليجان (أكتوبر 2005). آليات الانتقال الأساسية لمضيفي وموجهات IPv6 . مجموعة عمل الشبكة. doi : 10.17487/RFC4213 . RFC 4213 .المعيار المقترح. يلغي RFC 2893 . 
  64. ساور، بيوتر (10 يونيو 2026). "التحقق من عنوان IP" . تم الاسترجاع في 10 يونيو 2026 .
  65. سيلفيا هاجن (2014). أساسيات IPv6: دمج IPv6 في شبكة IPv4 الخاصة بك . دار نشر أورايلي ميديا، ص 222. ISBN  9781449335267.
  66. "فهم التكديس المزدوج لعناوين IPv4 و IPv6 أحادية البث" . Juniper.net . شبكات جونيبر. 31 أغسطس 2017. تم الاطلاع عليه في 19 يناير 2022 .
  67. "IPv6" . NRO.net . مؤرشف من الأصل بتاريخ 12 يناير 2017. تم الاطلاع عليه بتاريخ 13 مارس 2017 .
  68. بوجول، إنريك (12 يونيو 2017). "ما الذي يعيق حركة مرور IPv6 في مزود خدمة إنترنت ثنائي البروتوكول؟" . APNIC.net . APNIC . مؤرشف من الأصل في 27 مارس 2017. تم الاطلاع عليه في 13 يونيو 2017 .
  69. فوغان-نيكولز، ستيفن ج. (14 أكتوبر 2010). "خمس طرق لتعايش بروتوكولي IPv6 وIPv4 بسلام" . ZDNET . مؤرشف من الأصل في 5 ديسمبر 2023. تم الاطلاع عليه في 13 مارس 2017 .
  70. سيلفيا هاجن (2014). أساسيات IPv6: دمج IPv6 في شبكة IPv4 الخاصة بك . دار نشر أورايلي ميديا، ص 33. ISBN  9781449335267.
  71. م. كوتون؛ ل. فيغودا؛ ب. هابرمان (أبريل 2013). ر. بونيكا (محرر). سجلات عناوين IP ذات الأغراض الخاصة . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6890 . ISSN 2070-1721 . BCP 153. RFC 6890 . أفضل الممارسات الحالية 153. تلغي هذه الممارسة RFC 4773 و 5156 و 5735 و 5736 . تم تحديثها بواسطة RFC 8190 .  
  72. دليل واجهات نواة OpenBSDinet6(4)  
  73. ر. جيليجان؛ س. طومسون؛ ج. باوند؛ ج. ماكان؛ و. ستيفنز (فبراير 2003). ملحقات واجهة المقبس الأساسية لبروتوكول IPv6 . مجموعة عمل الشبكة. doi : 10.17487/RFC3493 . RFC 3493 .
  74. سي. باو؛ سي. هويتيما ؛ إم. باغنولو؛ إم. بوكادير؛ إكس. لي (أكتوبر 2010). عنونة IPv6 لمترجمي IPv4/IPv6 . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6052 . ISSN 2070-1721 . RFC 6052 . المعيار المقترح. تحديثات RFC 4291 . 
  75. غونت، فرناندو (10 مارس 2019)، أمن بروتوكول الإنترنت الإصدار السادس لمهندسي بروتوكول الإنترنت الإصدار الرابع (ملف PDF) ، تم الاطلاع عليه في 30 أغسطس 2019
  76. غونت، فرناندو (10 يناير 2019)، الأسئلة الشائعة حول أمان بروتوكول الإنترنت الإصدار السادس (ملف PDF) ، تم الاطلاع عليه في 30 أغسطس 2019
  77. مولينز، روبرت (5 أبريل 2012)، "الشبكات الظلية: أثر جانبي غير مقصود لبروتوكول IPv6" ، الحوسبة الشبكية ، مؤرشف من الأصل في 11 أبريل 2013 ، تم استرجاعه في 2 مارس 2013
  78. سيسيلو، غييرمو؛ غاليانو، روكي؛ أوفلاهيرتي، كريستيان؛ وآخرون . (أكتوبر 2009). IPv6 للجميع: دليل لاستخدام وتطبيق IPv6 في بيئات مختلفة (ملف PDF) . ص 5. تم الاطلاع عليه في 2 مارس 2013 .  
  79. جون-إيتشيرو إيتوجون هاغينو (أكتوبر 2003). "العناوين المُرتبطة ببروتوكول IPv4 على الشبكة تُعتبر ضارة" . تم الاطلاع عليه بتاريخ 10 يونيو 2026 .
  80. ف. غونت؛ ف. مانرال؛ ر. بونيكا (يناير 2014). آثار سلاسل رؤوس IPv6 كبيرة الحجم . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7112 . ISSN 2070-1721 . RFC 7112 . المعيار المقترح. تحديثات RFC 2460 . 
  81. ف. غونت (فبراير 2014). نصائح تنفيذية لحماية إعلانات موجه IPv6 (RA-Guard) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7113 . ISSN 2070-1721 . RFC 7113 . معلومات. تحديثات RFC 6105 . 
  82. ف. غونت (أغسطس 2013). الآثار الأمنية لتجزئة IPv6 مع اكتشاف الجوار في IPv6 . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6980 . ISSN 2070-1721 . RFC 6980 . المعيار المقترح. تحديثات RFC 3971 و 4861 . 
  83. برادنر، س.؛ مانكين، أ. (ديسمبر 1993). "طلب ورقة بيضاء حول بروتوكول الإنترنت: الجيل التالي (IPng)" . RFC 1550. تم الاطلاع عليه في 10 يونيو 2026 . 
  84. "تاريخ جهود IPng" . صحيفة ذا صن . مؤرشف من الأصل في 23 مايو 2014.
  85. برادنر، سكوت أو.؛ ​​مانكين، أليسون ج. (يناير 1995). "التوصية الخاصة ببروتوكول الجيل التالي لبروتوكول الإنترنت - الملحق ب" . RFC 1752. تم الاطلاع عليه في 10 يونيو 2026 . 
  86. وانغ، تاو؛ غاو، جياكيونغ (1 يناير 2019). "عيوب بروتوكول IPv6 وترقية بروتوكول IPv4" . المجلة الدولية للشبكات المتقدمة والمراقبة والتحكم . 4 (1): 1-9 . doi : 10.21307/ijanmc-2019-029 .
  87. "تاريخ بروتوكول الإنترنت الإصدار السادس @ ARIN" . www.arin.net . تم الاطلاع عليه بتاريخ 8 يوليو 2026 .
  88. حالة نشر بروتوكول الإنترنت الإصدار السادس (IPv6) لعام 2018 ، جمعية الإنترنت ، 2018، ص 3 ، تم الاطلاع عليه في 10 يونيو 2026 
  89. «موقع Beijing2008.cn ينتقل إلى الجيل التالي من الإنترنت» (بيان صحفي). اللجنة المنظمة لدورة الألعاب الأولمبية التاسعة والعشرين في بكين. 30 مايو 2008. مؤرشف من الأصل في 4 فبراير 2009.
  90. داس، كوشيك (2008). "بروتوكول الإنترنت الإصدار السادس وأولمبياد بكين 2008" . IPv6.com . مؤرشف من الأصل في 1 أغسطس 2008. تم الاطلاع عليه في 15 أغسطس 2008 .
  91. 1 2 مور، ديريك (9 يونيو 2009). "شركة فيريزون تفرض دعم بروتوكول الإنترنت الإصدار السادس (IPv6) على هواتف الجيل التالي" . سيركل آي دي . تم الاطلاع عليه في 10 يونيو 2026 .
  92. 1 2 3 "حالة نشر بروتوكول IPv6 لعام 2018" (ملف PDF) . InternetSociety.org . جمعية الإنترنت . تم الاطلاع عليه بتاريخ 19 يناير 2022 .
  93. "اعتماد بروتوكول IPv6" . تم الاطلاع عليه بتاريخ 15 ديسمبر 2025 .
  94. "حالة الإنترنت / تصور تبني بروتوكول IPv6" . أكاماي. مؤرشف من الأصل في 11 نوفمبر 2020. تم الاطلاع عليه في 15 ديسمبر 2025 .
  95. "قضية شركتي Hurricane Electric و Cogent" . BGP.tools . تم الاطلاع عليه بتاريخ 10 سبتمبر 2024 .