بروتوكول الإنترنت (الإصدار السادس)

  هذه المقالة عن بروتوكول الإنترنت (الإصدار السادس). لمعانٍ أخرى، طالع بروتوكول الإنترنت (توضيح).

الإصدار السادس من بروتوكول الإنترنت
ترويسة الإصدار السادس من بروتوكول الإنترنت
اختصار	IPv6
الوظيفة	بروتوكول تشبيك
المُطوِّر	مجموعة مهندسي الإنترنت
تاريخ التطوير	ديسمبر 1995م
حل محل	الإصدار الرابع من بروتوكول الإنترنت
تأثَّر بـ	الإصدار الرابع من بروتوكول الإنترنت
طبقة نموذج OSI	طبقة الشبكة

الإصدار السادس من بروتوكول الإنترنت (بالإنجليزية: Internet Protocol Version 6 اختصارًا IPv6)‏ هو بروتوكول تشبيك يعمل في طبقة الشبكة حسبَ نموذج الربط البيني للأنظمة المفتوحة، يُستعمل هذا البروتوكول في شبكات البيانات ويقدم خدمات العنونة والتقطيع وإدارة حركة البيانات. طوِّر الإصدار السادس في عام 1995م على يد مجموعة مهندسي الإنترنت بصفته حلًّا نهائيًّا لمشكلة استنفاد فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت.

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

يُعرِّف البروتوكول فضاءً من العناوين يضم قرابة 3.4x10³⁸ عنوانًا طول كل منها 128 بتًّا. يُقسَّم الفضاء رياضيًّا إلى فضاء البث فريد الوجهة وإلى فضاء البث المجموعاتي، وتدير هيئة العناوين المُخصصة كلا الفضاءَين. يدعم البروتوكول ثلاثة أنماط من العنونة هي العنونة فريدة الوجهة وعنونة البث نحو الأقرب وعنونة البث المجموعاتي، ولا يدعم البث العام.

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

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

ينشأ عن استعمال الإصدار السادس من بروتوكول الإنترنت مجموعة من الثغرات الأمنية التي قد تكون منطلقًا لمجموعة من الهجمات، بعضها مرتبط بالتقطيع مثل هجوم القطعة الصغيرة أو هجوم القطع المتراكبة، وبعضها مرتبط بإدارة حركة رزم البيانات مثل هجوم سرقة الخدمة.

نبذة تاريخية

أصناف عناوين البث فريد الوجهة في الإصدار الرابع من بروتوكول الإنترنت وبنية عناوينها.

خط زمني لتطوُّر البروتوكولات الرئيسة في حزمة بروتوكولات الإنترنت

خط زمني للمعايير الناظمة للإصدار السادس من بروتوكول الإنترنت والبروتوكولات الرديفة له.

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

اعتمد الإصدار الرابع من بروتوكول الإنترنت على نظام عنونة مبني على فضاء يبلغ طول العنوان فيه 32 بتًّا، وُقسِّم هذا الفضاء إلى أصناف، خُصصت ثلاثٌ منها لعنونة البث فريد الوجهة، وهي الصنف A وعدد أفضيته 128 صنفًا، وهو أكبر الأصناف حجمًا (2²⁴ عنوانًا في كل صنف)، والصنف B وضمَّ الفضاء 2¹⁴ صنفًا في كل منها 2¹⁶ عنوانًا، والصنف C وهو أكثر الأصناف عددًا بواقع 2²¹ صنفًا، ولكنها أصغرها حجمًا، حيث يضمّ كل صنف 2⁸ عنوانًا. وخُصص فضاء رابع للبث المجموعاتي، وسمي الصنف D.

شكَّلت مجموعة مهندسي الإنترنت، وهي الهيئة الناظمة لتطوير معايير الإنترنت، في شهر نوفمبر من العام 1991م، مجموعة عمل التوجيه والعنونة والمعروفة اختصارًا باسم رُوْد (بالإنجليزية: Routing and Addressing اختصاراً ROAD)‏ بهدف معالجة هذه المشكلة، وعرَّفت هذه المجموعة ثلاثَ مُشكلات رئيسيَّة تعيق نمو الإنترنت:

1. استنفاد فضاء عناوين الصنف B، وهذه هي نتيجة لغياب فضاء عناوين يناسب منظمة متوسطة الحجم، ففضاء الصنف C صغير الحجم، وهو ما يدفع هذه المنظمات لاستعمال فضاء من الصنف B، على الرغم من أن حجم الفضاء يزيد بكثير عن حاجة المنظمة.
2. نمو جداول التوجيه في موجهات الإنترنت لتصبح بحاجة إلى قدرات معالجة غير متوافرة بالبرمجيات أو المعدات المتوافرة.
3. الاستنفاد النهائي لفضاء عناوين الإصدار الرابع.

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

في ما يخص الإستراتيجية طويلة الأمد، فقد بدأت مجموعة مهندسي الإنترنت في العمل منذ مطلع التسعينيات على تطوير إصدار جديد من بروتوكول الإنترنت. في العام 1993م، كان التوجه العام هو طرح نظام عنونة جديد موسع في إصدار جديد من بروتوكول الإنترنت، ولذلك طلبت المجموعة اقتراحات في هذا الشأن مع نهاية تلك السنة. في نهاية العام 1993م أيضًا، شكّلت المجموعة نطاق عمل جديد سمته الجيل التالي من بروتوكول الإنترنت (بالإنجليزية: IP Next Generation اختصاراً IPng)‏، وعمل 15 مهندسًا من اختصاصات متنوعة على مراجعة ودراسة الاقتراحات لصياغة حل شامل.

في شهر ديسمبر من العام 1995، صدر المعيار الأول للإصدار السادس من بروتوكول الإنترنت تحت الاسم الرمزي RFC 1883. وصدر معه أيضًا المعياران الأولان لمُحددات بنية العناوين في الإصدار السادس ولبروتوكول رسائل التحكم للإصدار السادس، وحملت وثائق طلب التعليقات الخاصة بهما الاسمين الرمزيين RFC 1884 وRFC 1885 على الترتيب. صدر المعياران الأولان لبروتوكول اكتشاف الجيران ولآلية التهيئة الذاتية الآلية لاحقًا في شهر أغسطس من العام التالي، وحملا الاسمين الرمزيين على RFC 1970 وRFC 1971 على الترتيب.

صدرت مجموعة تحديثات جديدة تضمنت أربعة وثائق طلب تعليقات تمتد أسماؤها الرمزية من RFC 2460 حتى RFC 2463 في ديسمبر من العام 1998م، وشملت معاييرَ جديدةً للإصدار السادس، ولبروتوكول رسائل التحكم الخاص به ولبروتوكول اكتشاف الجيران ولآلية التهيئة الذاتية الآلية. واستمرت التحديثات بالصدور منفصلة أو بشكل مجموعات، فصدرت ثلاث معايير متتابعة لبنية عناوين الإصدار السادس، آخرها في فبراير من العام 2006م، وحمل الاسم الرمزي RFC 4291، وصدر معيارٌ ثالث لبروتوكول رسائل التحكم للإصدار السادس في مارس من العام 2006م أيضًا، وحمل الاسم الرمزي RFC 4443، وصدر ثالثًا زوجان من المعايير أحدهما لبروتوكول اكتشاف الجيران والآخر لآلية التهيئة الذاتية الآلية في فبراير 2007م وحملا الاسمين الرمزيين على RFC 4861 وRFC 4862 على الترتيب. وأخيرًا صدر المعيار الحالي للإصدار السادس من بروتوكول الإنترنت في يونيو من العام 2017م وحمل الاسم الرمزي RFC 8200.

مبدأ العمل

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

بشكل مشابه للإصدار الرابع، يقدم الإصدار السادس خدمتي العنونة والتقطيع. في ما يخص العنونة فإن الإصدار السادس من بروتوكول الإنترنت يُعرِّف فضاء عناوين يضم 2¹²⁸ عنوانًا، ويدعم ثلاثة أنماط من العنونة: هي عنونة البث فريد الوجهة، وعنونة البث المجموعاتي وعنونة البث نحو الأقرب، أما البث العام فهو غير مدعوم في هذا البروتوكول. في ما يخص التقطيع، يمكن للبروتوكول أن يقطع رزم بيانات الإصدار السادس في مصدرها فقط، وأن يعيد تجميع القطع في وجهتها النهائية فقط، ولا حاجة لتقطيع الرزم على طول المسار، وذلك لامتلاك مصدر رزم البيانات آليةً للتعرف على حجم وحدة النقل العظمى للمسار قبل البدء بالإرسال، ما يسمح له باختيار الحجم المناسب وتقطيع رزمة البيانات على أساسه.

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

بالإضافة لذلك، تُعرِّف مُحددات البروتوكول المُصطلحات التالية وتستخدمها وثائق طلب التعليقات ذات الصلة:

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

الترويسات

أمثلة متنوعة عن تتابع الترويسات في الإصدار السادس من بروتوكول الإنترنت.

تتابع الترويسات

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

لكل نوع ترويسة مُعرِّف مُحدد، وتحتوي الترويسات جميعها، بما في ذلك ترويسة الإصدار السادس، على حقل مُخصص ليضم قيمة مُعرِّف نوع الترويسة التالية، ويسمح ذلك بإمكانية إنشاء تتابع من الترويسات، حيث تشير قيمة حقل المُعرِّف في كل ترويسة إلى نوع الترويسة التالية، في حين تُخصص القيمة 59 للإشارة إلى عدم وجود ترويسة تالية وتستعمل في الترويسة الموجودة في نهاية التتابع. تدير هيئة أرقام الإنترنت المُخصصة ضبط القيم المعيارية لمُعرفات أنواع الترويسة. وإذا وردت عدة ترويسات، فتكون بالترتيب التالي:⁽¹⁾

1. ترويسة بروتوكول الإنترنت
2. ترويسة خيارات المسار
3. ترويسة خيارات الوجهة (للخيارات التي ستعالج في الوجهة الأولى على المسار أو أي وجهة بينية أخرى مُحددة بترويسة التوجيه ما خلا الوجهة النهائية)
4. ترويسة التوجيه
5. ترويسة القطعة
6. ترويسة تأمين الحمولة بالتغليف
7. ترويسة خيارات الوجهة (للخيارات التي ستُعالج في الوجهة النهائية فقط)
8. ترويسة بروتوكول الطبقة العليا

يجب أن يكون طول ترويسة التوسعة عددًا صحيحًا من مضاعفات 8 بايت، أي 16 و24 و32 إلخ ... وذلك ضروريٌ لمحاذاة الترويسات المتتابعة، وتضم بعض الترويسات عددًا من الخيارات التي يكون لها بنية محددة أيضًا بحيث تصطف وتُحاذَى تلقائيًَّا داخل الترويسة.

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

بنى الترويسات

ترويسة البروتوكول

ترويسة الإصدار السادس من بروتوكول الإنترنت.

يبلغ طول ترويسة الإصدار السادس 40 بايت، وتتكون من ثمانية حقول هي وفقًا لترتيب وردوها:

• حقل رقم الإصدار: وطوله 4 بت، ويمثل رقم الإصدار، وقيمته هي 6 دائمًا في ترويسة الإصدار السادس من بروتوكول الإنترنت.
• حقل صنف حركة البيانات: وطوله 8 بت، ويحتوي مُعرِّف رقمي يمكن ضبطه لتحديد جودة الخدمة التي ستحصل عليها رزمة البيانات.
• حقل لافتة التدفق: وطوله 20 بت، ويحتوي مُعرِّف رقمي يُحدد التدفق الذي تنتمي إليه رزمة البيانات، ويمكن أن تستعمل هذه القيمة في تحديد كيفية معالجة الرزمة في الموجهات التي تعالج الرزمة على طول المسار نحو وجهتها.
• حقل طول الحمولة: وطوله 16 بت، ويحتوي عدد صحيح موجب يمثل طول حمولة الرزمة التي توجد فيها الترويسة مُقدرًا بالبايت، يشمل ذلك ترويسات التوسعة جميعها والتي تلي ترويسة الإصدار السادس.
• حقل الترويسة التالية: وطوله 8 بت، ويحدد نوع الترويسة التالية، التي تلي هذه الترويسة، إذا كانت الترويسة مغايرة لترويسات التوسعات، فإن قيم هذه الحقل مُطابقة للقيم المُستعملة في الإصدار الرابع من البروتوكول.
• حقل عدد القفزات: وطوله 8 بت، ويحتوي عددًا صحيحًا موجبًا. ينقص كل موجه يُعالج رزمة البيانات ويُوجِّههها واحدًا من هذه القيمة. يفحص كل موجه يستقبل رزمة البيانات قيمة هذا الحقل أولًا، إذا كانت مساوية للصفر، فإنه يتخلص منها. إذا استقبلت الوجهة النهائية الرزمة بقيمة صفرية لهذا الحقل، لا تتخلص منها بل تعالجها.
• حقل عنوان المصدر: وطوله 128 بت، عنوان العقدة المصدر التي ولدت رزمة البيانات.
• حقل عنوان الوجهة: وطوله 128 بت، عنوان وجهة الرزمة. قد يحتوي عنوان الوجهة الأخيرة، أو عنوان المُستقبل التالي للرزمة إذا كانت ترويسة التوجيه موجودة بعد ترويسة البروتوكول.

ترويسة خيارات المسار

بنية ترويسة خيارات المسار

تستعمل ترويسة خيارات المسار (بالإنجليزية: Hop-by-hop options header)‏ لحمل معلومات لخيارات يُمكن فحصها أو معالجة محتواها في كل مُوجِّه تمر به الرزمة عبر مسارها إلى وجهتها النهائية. إن قيمة النوع الخاصة بهذه الترويسة هي 0، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.

طول ترويسة خيارات المسار مُتغيِّرٌ، وهي تتكون من حقلين ثابتي الطول يليهما حقل واحد مُتغيِّر الطول، وهذه الحقول هي وفقًا لترتيب ورودها:

• حقل الترويسة التالية: طوله 8 بت، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
• حقل طول ترويسة التوسعة: وطوله 8 بت، ويحتوي عدد صحيح موجب يمثل طول ترويسة خيارات المسار بواحدة 8 بايت، دونَ احتساب البايتات الثمانية الأولى. مثلًا إذا كان طول الترويسة هو 16 بايت، فإن قيمة هذا الحقل هي 1، وإذا كان طول الترويسة هو 32 بايت فإن قيمة هذا الحقل هي 3.
• حقل الخيارات: مُتغيِّر الطول، يضم خيارًا واحدًا أو أكثر من خيارات المسار، ويلزم يكون طول هذا القسم متوافقًا مع واحدة 8 بايت، أي من المقبول أن يكون الطول: 8 أو 16 أو 24 بايت ... إلخ.

ترويسة التوجيه

بنية ترويسة التوجيه

يستعمل مصدر رزمة بيانات للإصدار السادس من بروتوكول الإنترنت ترويسة التوجيه (بالإنجليزية: Routing header)‏ لتحديد مسارها أو جزءًا منه من خلال إضافة قائمة تضم عناوين العقد الوسيطية التي يلزم أن تزورها الرزمة عبر مسارها وصولًا إلى وجهتها. تتشابه وظيفة هذه الترويسة مع وظيفة خيار المسار الحرّ من المصدر في الإصدار الرابع من بروتوكول الإنترنت. إن قيمة النوع الخاصّ بترويسة التوجيه هي 43، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.

ترويسة التوجيه متغيرة الطول، وهي تتكون من أربعة حقول ثابتة الطول يليها حقل وحيد متغير الطول، وهذه الحقول هي وفقًا لترتيب ورودها:

• حقل الترويسة التالية: طوله 8 بت، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
• حقل طول ترويسة التوسعة: طوله 8 بت، ويحتوي عدد صحيح موجب يمثل طول ترويسة خيارات المسار بواحدة 8 بايت، دونَ احتساب البايتات الثمانية الأولى.
• حقل نوع التوجيه: طوله 8 بت، ويضمّ مُعرفًا يُحدد نوع التوجيه، وتحدد هيئة أرقام الإنترنت المُخصصة قائمة المُعرفات المدعومة من قبل البروتوكول ومعاني كلٍّ منها. اعتمد النوع ذو القيمة 0 في المعيار الأصلي، لكنه أُبطل لأسباب أمنية.⁽³⁾
• حقل القطاعات المتبقية: طوله 8 بت، ويضمّ معرِّفًا رقميًّا لعدد قطاعات الشبكة الوسيطية⁽⁴⁾ التي يلزم زيارتها قبل الوصول إلى الوجهة النهائية، ولكنَّها لما تُزر بعدُ.
• حقل بيانات مُرتبطة بالنوع: مُتغيِّر الطول، ويحتوي مجموعة واحدة أو أكثر من هياكل البيانات التي يكون طولها متوافقًا مع واحدة 8 بايت، لتكون نهايتها عند نهاية الترويسة دائمًا، أما بنية الهياكل، فهي تتحدد بنوع التوجيه.

توجد حالتان مرتبطتان بترويسة التوجيه تستوجبان إرسال رسائل أخطاء خاصَّة ببروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت، وهما:

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

ترويسة القطعة

بنية ترويسة القطعة

تضاف ترويسة القطعة (بالإنجليزية: Fragment header)‏ إلى جميع القطع الناتجة عن عملية تقطيع رزمة بيانات. إنَّ قيمة النوع الخاصة بهذه الترويسة هي 44، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.

يبلغ طول ترويسة القطعة 8 بايت، وتتألف من 6 حقول دائمة، هي وفقًا لترتيب وردوها:

• حقل الترويسة التالية: طوله 8 بت، ويضبط بشكل مشابه لحقل الترويسة التالية في ترويسة البروتوكول الأصلية.
• حقل محجوز طوله 8 بت، يُضبط إلى قيمة صفرية في مصدر الرزمة عند الإرسال.
• حقل إزاحة القطعة: طوله 13 بت، يحتوي موقع حمولة القطعة النسبي ضمن حمولة الرزمة الأصلية، وتعبر قيمة الرقم الموجود عن الإزاحة بواحدة هي 8 بايت، فإذا كانت قيمة هذا الحقل مثلًا هي 2، فإن إزاحة القطعة الحقيقية هي 16 بايت.
• حقل محجوز طوله 2 بت، يُضبط إلى قيمة صفرية في مصدر الرزمة عند الإرسال.
• علم المزيد من القطع: طوله 1 بت، ويستخدم للإشارة إلى القطعة الأخيرة، إذا كانت قيمته 1، فهذا يعني وجود قطع لاحقة نتجت عن عملية التقطيع، أما إذا كانت قيمته 0 فذلك يعني بأنَّ هذه القطعة هي القطعة الأخيرة.
• حقل مُعرّف القطعة طوله 32 بت، وهي يحتوي قيمة فريدة تُميّز الرزمة الأصلية وجميع القطع التي نتجت عن تقطيعها. توجد خوارزميات عديدة لاختيار قيمة المعرّف بحيث يكون فريدًا وآمنًا، وهي موصوفة في وثيقة طلب التعليقات RFC 7739.

ترويسة خيارات الوجهة

بنية ترويسة خيارات الوجهة.

تُستخدم ترويسة خيارات الوجهة (بالإنجليزية: Destination Options Header)‏ لحمل الخيارات التي تُعالجها الوجهة النهائية للرزمة فقط. إنَّ قيمة النوع الخاصّ بترويسة التوجيه هي 60، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.

ترويسة خيارات الوجهة مُتغيَّرة الطول، وهي تتكون من حقلين ثابتي الطول يليهما حقل وحيد متغير الطول، وهذه الحقول هي وفقًا لترتيب ورودها:.

• حقل الترويسة التالية: طوله 8 بت، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
• حقل طول ترويسة التوسعة: وطوله 8 بت، ويحتوي عدد صحيح موجب يمثل طول ترويسة خيارات المسار بواحدة 8 بايت، دونَ احتساب البايتات الثمانية الأولى.
• حقل الخيارات: متغيِّر الطول، يضم خيارًا واحدًا أو أكثر من خيارات الوجهة، ويلزم أن يكون طول هذا القسم متوافقًا مع واحدة 8 بايت، أي من المقبول أن يكون الطول: 8 أو 16 أو 24 بايت ... إلخ.

ترويسة المصادقة

بنية ترويسة المصادقة.

تُؤَمِّن ترويسة المصادقة (بالإنجليزية: Authentication Header)‏ آليةً للتحقق من سلامة رزم البيانات المنقولة عبر اتصال يجري عبر قناة غير مُهيَّأة وتحققًا من هوية مصدر هذه الرزمة. تسمح آلية التحقق من السلامة بمنع تلاعب وسيط ما برزم البيانات عند حركتها بين مصدرها ووجهتها، وتستخدم في التصدي لهجمات الوسيط. إنَّ قيمة النوع الخاصّ بترويسة المصادقة هي 51، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.

ترويسة خيارات الوجهة مُتغيَّرة الطول، وهي تتكون من ستة حقول، خمسةٌ منها ثابتة الطول يليها حقل وحيد متغير الطول، وهذه الحقول هي وفقًا لترتيب ورودها:

• حقل الترويسة التالية: طوله 8 بت، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
• حقل طول الحمولة: طوله 8 بت، ويحتوي طول ترويسة التوسعة بواحدة 32 بت، أو 4 بايت، منقوصًا منها بايتان. أي إذا كان طول الترويسة هو 100 بايت، فإن قيمة هذا الحقل هي 2-(100/4)= 2-25 = 23.
• حقل محجوز: بطول 16 بت.
• حقل فهرس وسائط الأمن: بطول 32 بت، ويحتوي مُعرِّف الجلسة الآمنة، وهي قيمة عشوائية يضيفها المصدر إلى الترويسة وتُستخدم من قبل الوجهة لتمييز الجلسة الآمنة التي أرسلت الرزمة عبرها.
• حقل رقم التتابع: بطول 32 بت، يحتوي عداد تضبط قيمته في المصدر إلى قيمة محددة مع بدء الجلسة الآمنة، ثم قيمة التتابع بمقدار واحد مع كل رزمة بيانات تُرسل في الجلسة.
• حقل قيمة التحقق من السلامة: متغيِّر الطول، ويلزم أن يكون طوله من مضاعفات 32 بت، ويُضمُّ قيمة رياضية تُحسب في العقدة المصدر من أجل محتويات رزمة البيانات التي لا تتغير خلال عبورها الشبكة. في العقدة الوجهة، لا يمكن الحصول على قيمة حقل التحقق من السلامة نفسِها إلا إذا كانت محتويات الرزمة هي نفسُها، أي أنها وصلت من المصدر إلى الوجهة دونَ تلاعب فيها.

ترويسة تأمين الحمولة بالتغليف

بنية ترويسة تأمين الحمولة بالتغليف.

تُستعمل ترويسة تأمين الحمولة بالتغليف (بالإنجليزية: Encapsulating Security Payload header)‏ لتأمين مجموعة من خدمات الأمن التي تشمل: سرية البيانات وللتحقق من هوية مصدرها ولسلامة الاتصال عبر القنوات غير المُهيَّأة وللحماية من الهجمات المضادة لإعادة الإرسال (بالإنجليزية: Anti-replay attacks)‏. إنَّ قيمة النوع الخاصّ بترويسة التوجيه هي 50، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.

ترويسة تأمين الحمولة بالتغليف مُتغيَّرة الطول، وهي تتكون من سبعة حقول، أربعة منها ثابتة الطول. وحقول هذه الترويسة هي وفقًا لترتيب ورودها:

• حقل فهرس وسائط الأمن: بطول 32 بت. ويحتوي مُعرِّف الجلسة الآمنة، وهي قيمة عشوائية يضيفها المصدر إلى الترويسة وتُستخدم من قبل الوجهة لتمييز الجلسة الآمنة التي أرسلت الرزمة عبرها.
• حقل رقم التتابع: بطول 32 بت. يحتوي عداد تضبط قيمته الابتدائية في المصدر إلى قيمة محددة عند بدأ الجلسة الآمنة، ثم تُزاد قيمة التتابع بمقدار واحد مع كل رزمة بيانات يُرسلها مصدر الرزم في تلك الجلسة.
• حقل بيانات الحمولة: مُتغير الطول، يحتوي المعلومات التي تُعمَّى من أجل حمايتها.
• حقل الحشو: متغير الطول يتراوح طوله بين 0 و 255 بايت، يحتوي بايتات إضافية مُلحقة بالحمولة. يُضاف حقل الحشو لسببين:

1. قد يلزم حد أدنى أو قيم محددة لطول البيانات المُراد تعميتها. مثلًا، مضاعفات 4 أو 8 أو 16 بايت ... إلخ، وعندها تضاف بايتات الحشو لإكمال طول البيانات حتى القيمة اللازمة.
2. قد يلزم إضافة عدة بايتات لجعل نهاية الحقلين التاليين تقع عند مضاعفات 4 بايت، وعندها تُضاف بايتات حشو حسب الحاجة لتحقيق ذلك.

• حقل طول الحشو: طوله 8 بت، ويحتوي عدد البايتات المُضافة في قسم الحشو.
• حقل الترويسة التالية: طوله 8 بت، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
• حقل قيمة التحقق من السلامة: متغيِّر الطول ويلزم أن يكون طوله من مضاعفات 32 بت، ويُضمُّ قيمة عددية تُحسب في العقدة المصدر من أجل محتويات رزمة البيانات التي لا تتغير خلال عبورها الشبكة. يعاد حساب هذه القيمة في العقدة الوجهة، ولا يمكن الحصول على القيمة نفسِها لحقل التحقق من السلامة إلا إذا كانت محتويات الرزمة هي نفسُها دون تغيير، ومعنى ذلك أنها وصلت من المصدر إلى الوجهة دونَ تلاعبٍ فيها.

بنية الخيارات

بنية الخيار العامة في الإصدار السادس من بروتوكول الإنترنت.

يُمكن لترويستان من الترويسات التي تُعرِّفها محددات البروتوكول أن تحمل خياراتٍ مُختلفة العدد والحجم، وهما ترويستا خيارات المسار وخيارات الوجهة. إن بنية خيارات البروتوكول ثلاثية الحقول، وهي تتكون من البنية التالية:

• حقل النوع: طوله 8 بت، ويحتوي مُعرِّف رقمي يحدد نوع الخيار.
• حقل الطول: طوله 8 بت، ويحتوي طول الخيار مُقدرًا بالبايت.
• حقل القيمة: مُتغيِّر الطول، وتكون بنيته ومعاني القيم فيها مرتبطة بنوع الخيار.

تُحدد قيمة البتان الأكثر أهمية في حقل النوع سلوك العقدة التي تُعالج الخيار إذا أخفق في التَّعرُّف على نوعه، فإذا كانت قيمتهما ₂(00) فعلى العقدة تخطي الخيار واستكمال معالجة الترويسة. وإذا كانت قيمتهما ₂(01) فعلى العقدة التخلُّص من الرزمة. وإذا كانت قيمتهما ₂(10) فعلى العقدة التخلص من الرزمة والاعتماد على بروتوكول رسائل التحكم للإصدار السادس لإرسال رسالة خطأ يُشير فيها إلى عدم إمكانية التعرف على نوع الخيار، وذلك بغض النظر عن كون مصدر الرزمة عنوان بث فريد الوجهة أو عنوان بث مجموعاتي. أما إذا كانت قيمتهما ₂(11) فعلى العقدة تنفيذ ما سبق فقط إذا لم يكن عنوان مصدر الرزمة عنوان بثِّ مجموعاتي. أما البت الثالث من حيث الأهمية، فإن قيمته تحدد فيما إذا كان محتوى الخيار يتغير أثناء انتقال الرزمة عبر الشبكة. فإن كان المحتوى مُتغيرًا، كانت قيمة البت هي 1، وإن كان ثابتًا كانت قيمته 0.

مع أن مُحددات البروتوكول تقدم دليلًا إرشاديًّا لتبيان كيفية تصميم خيارات للإصدار السادس من بروتوكول الإنترنت، إلا أن وثيقة مُحددات البروتكول لا تُعرِّف إلا خيارين اثنين فقط، هما خيار حشو بايتٍ واحد (بالإنجليزية: Pad1 option)‏، وخيار حشو N بايت (بالإنجليزية: PadN option)‏. ويُستخدمان لمحاذاة نهاية الخيار مع واحدة طول الترويسة، وهي 4 بايت. أي إذا كان طول الخيار مثلًا 11 بايتًا، فيضاف خيار حشو بايت وحيدٍ في النهاية، وإن كان 13 بايتًا يُضاف خيار حشوٍ لثلاث بايتات. وخيار حشو بايت واحد هو الخيار الوحيد الذي لا يتبع بنية الخيارات السابقة، بل يتكون من بايت وحيد صفريّ البتات.

• 
  بنية خيار حشو بايت واحد
• 
  بنية خيار حشو N بايت

الوظائف

العنونة

تعاريف

تُعرِّف محددات البروتوكول فضاءً للعناوين، ويبلغ طول العنوان فيه 128 بتًّا، ومعنى ذلك أن الفضاء يضمّ 2¹²⁸ عنوانًا أي ما يقارب 3.4x10³⁸ عنوانًا. تُمنح عناوين الإصدار السادس للمنافذ، لا للعقد، ويمكن للمنفذ أن يستضيف أكثر من عنوان في الوقت نفسه. يدعم الإصدار السادس من بروتوكول الإنترنت ثلاثة أنماط لعنونة المنافذ هي عنونة البث فريد الوجهة، وعنونة البث المجموعاتي وعنونة البث نحو الأقرب، ولا يدعم البروتوكول نمط عنونة البث العام. في عنونة البث فريد الوجهة، يستضيف منفذ ما عنوانًا فريدًا، ويجري توجيه الرزم المُرسلة نحو هذا العنوان إلى المنفذ الذي يستضيفه. أما في عنونة البث المجموعاتي، فتَستضيف مجموعة من المنافذ عنوانًا ما في الوقت نفسه، ويجري توجيه الرزم المُرسلة نحو ذلك العنوان إلى المنافذ التي تستضيفه جميعُها. أما في عنونة البث الأقرب، فتستضيف مجموعة من المنافذ عنوانًا ما في الوقت نفسه، ويجري توجيه الرزم المُرسلة نحو هذا العنوان إلى أقرب منفذ يستضيفه.⁽⁵⁾ إذا كان للعقدة منفذٌ وحيدٌ فقط يستضيف عنوان بثٍ فريد الوجهة فقط، يجوز أن يُستعمل العنوان مُعرِّفًا للعقدة.

التمثيل الرياضي

مسرد للمصطلحات المُستعملة في عناوين الإصدار السادس من بروتوكول الإنترنت

يبلغ طول عنوان الإصدار السادس من بروتوكول الإنترنت 128 بتًّا، ويكون البت الواقع في أقصى اليسار هو البت ذو الأهمية العليا. يُكتب عنوان الإصدار السادس باستعمال نظام العد ست العشري، وتُمثَّل كل 4 بتات متتالية بخانة ستة عشرية واحدة تكون قيمتها حسب الجدول التالي:

جدول تحويل مباشر بين قيم نظامي العد الثنائي وستة العشري

قيمة البتات الأربعة بنظام العد الثنائي	القيمة الموافقة بنظام العد ست العشري	قيمة البتات الأربعة بنظام العد الثنائي	القيمة الموافقة بنظام العد ست العشري
0000	0	1000	8
0001	1	1001	9
0010	2	1010	a(6)
0011	3	1011	b
0100	4	1100	c
0101	5	1101	d
0110	6	1110	e
0111	7	1111	f

البنية العامة لعنوان بث فريد الوجهة في الإصدار السادس من بروتوكول الإنترنت.

تُسمَّى كل أربع خانات ستة عشرية متتالية رباعيةً (بالإنجليزية: Quartet)‏،⁽⁷⁾ ويُفصل بين كل رباعيتين متتاليتين محرف النقطتين الرأسيتين، أي ":"، وتكون الرباعية الواقعة في أقصى اليسار هي الأعلى أهمية. مثلًا العنوان التالي هو مثال عن عنوان من الإصدار السادس من بروتوكول الإنترنت:

0123:4567:89ab:cdef:0123:4567:89ab:cdef

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

تمثيل العناوين والأقنعة

أمثلة عن اختصار عناوين الإصدار السادس من بروتوكول الإنترنت

العنوان المُكتمل	العنوان المختصر
2340:0000:0010:0100:1000:abcd:0101:1010	2340:0:10:100:1000:abcd:101:1010
30A0:abcd:ef12:3456:0ABC:B0B0:9999:9009	30A0:abcd:ef12:3456:ABC:B0B0:9999:9009
3210:0000:0000:0000:0000:0000:0000:0000	::3210
0000:0000:0000:0000:0000:0000:0000:1	1::
34ba:000b:000b:0000:0000:0000:0020	34ba:b:b::20

يُمثَّل عنوان الإصدار السادس من بروتوكول الإنترنت بثلاثة طرق:

• التمثيل المكتمل: وفيه يكتب العنوان كاملًا بالشكل #:#:#:#:#:#:#:#، وفيه يُمثل الرمز # أربع مراتب ستة عشرية. ومثاله العنوان:0123:4567:89ab:cdef:0123:4567:89ab:cdef.
• التمثيل المُختصر: وفيه تختصر أجزاء من العنوان بالشكل التالي:

1. كانت المرتبة الأعلى أهميةً في رباعية ما صفرية لوحدها أو صفرية مع أكثر من مرتبة متتابعة معها، تهمل الأصفار وتُسقط من الكتابة وتكتب المراتب الست عشرية غير الصفرية فقط، فمثلًا الرباعية 0123 تُكتب بالشكل 123 والرباعية 0011 تكتب بالشكل 11.
2. إذا كانت المراتب الست عشرية في رباعية ما صفريَّة القيمة جميعها، تمثل الرباعية بصفر واحدة، أي 0000 تُكتب: 0.
3. إذا اجتمعت أكثر من رباعية صفرية متتالية، أمكن اختزالها والتعويض عنها بمحرفي نقطتين رأسيتين متتاليتين. فمثلًا العنوان:1234:0:0:0:0:0:0:1111 يُكتب اختصارًا: 1111::1234
4. إذا وجد أكثر من تتابع رباعيات صفرية في عنوان واحد، فلا يجوز اختزال إلا تتابع واحد منها فقط، فمثلًا العنوان:1234:0:0:0:2222:0:0:1111 يُكتب اختصارًا: 2222:0:0:1111::1234 أو 1111::2222:0:0:0:1234 ولا يكتب 1111::2222::1234. وأمَّا إذا كان طول التتابعين متساويًا، أمكن اختزال أحدهما دون تمييز.

• التمثيل المُختلط: وهو تمثيل يُستعمل في الشبكات التي يستضيف المضيفون فيها عناوين من الإصدارين الرابع والسادس معًا، ويكون شكل العنوان d.d.d.d:#:#:#:#:#:#، حيث يُمثِّل الرمز # رباعيةً مكونة من 4 خانات ست عشرية غير صفرية، وتطبق قواعد الاختصار إذا وجدت خانات صفرية، أمَّا المحرف d فيُمثِّل خانة من خانات عنوان الإصدار الرابع من بروتوكول الإنترنت مكتوبة بالنظام العشري المُنقَّط ، ومثال هذا التمثيل العنوان: 1111:0:0:0:0:0:200.100.10.1 والذي يمكن أن يكتب بعد الاختصار بالشكل التالي: 200.100.10.1::1111.

تمثيل البادئات

البادئة (بالإنجليزية: Prefix)‏ هي فضاء جزئي من الفضاء الكلي لعناوين البروتوكول، وتُمثَّل كل بادئة بعنوان يُسمى عنوان البادئة. ويتشابه تمثيل البادئات في الإصدار السادس من بروتوكول الإنترنت مع تمثيلها في الإصدار الرابع، والذي أُقِرَّ بعد اعتماد آلية التوجيه غير الصنفي بين النطاقات. تتكون كل بادئة من جزئين، هما عنوان من الإصدار السادس من بروتوكول الإنترنت وطول البادئة، أي عدد البتات فيها، ويكون شكل البادئة:

طول البادئة/عنوان الإصدار السادس

يمكن اختصار العنوان الموجود في البادئة وفقًا لقواعد اختصار عناوين الإصدار السادس نفسها. فمثلًا، ما سيأتي هو أمثلة عن بادئات مكتوبة بشكل صحيح:

1111:0000:0000:2222:0000:0000:0000:0000/64

1111:0:0:2222:0:0:0:0/64

64/::1111:0:0:2222

بنى العناوين وفقًا لنمط التوجيه

أنماط التوجيه
بث فريد الوجهة
بثّ عام
بث مجموعاتي
بث نحو الأقرب
بث جغرافي

يُعرِّف الإصدار السادس من بروتوكول الإنترنت فضاءً يضمُّ 2¹²⁸ عنوانًا فيه، ويدعم ثلاثة أنماط من العنونة هي العنونة هي عنونة البث الفريد الوجهة وعنونة البث المجموعاتي وعنونة البث نحو الأقرب. يُخصص فضاء محجوز للبث المجموعاتي، ويُحجز فضاء خاص أيضًا لعناوين البث فريد الوجهة الوصلة المحلية، وفيما يخصص العنوان الصفري ليكون العنوان غير المُحدد والعنوان الذي يليه ليكون عنوان الحلقة العكسية، وفيما خلا ذلك، فما تبقى من الفضاء مُخصص لفضاء عناوين البث فريد الوجهة العالمي. ويبين الجدول التالي العناوين المحجوزة والأفضية الجزئية في الإصدار السادس من بروتوكول الإنترنت:

أقسام فضاء عناوين الإصدار السادس من بروتوكول الإنترنت

الاسم	البادئة (طول البادئة [بت])	تمثيل الفضاء
العنوان غير المُحدد	0 ... 00 (128)	128/::
عنوان الحلقة العكسية	1 ... 00 (128)	1/128::
فضاء البث المجموعاتي	11111111 (8)	ff00::/8
فضاء البث فريد الوجهة في الوصلة المحلية	1111111010 (10)	fe80::/10
فضاء البث فريد الوجهة العالمي	كل ما تبقى من الفضاء

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

عناوين البث فريد الوجهة

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

توجد أنواع عديدة لعناوين الفضاء فريد الوجهة منها، هي:

• العنوان غير المُحدد (بالإنجليزية: The Unspecified Address)‏: هو العنوان الصفريّ، أي 0:0:0:0:0:0:0:0 أو اختصارًا ::. يُستعمل للدلالة إلى عدم استضافة المنفذ لعنوان من الإصدار السادس من بروتوكول إنترنت رغم وجود دعم للبروتوكول فيه، لذلك لا يجب أن يُمنح هذا العنوان لأي منفذ. لا يُستعمل هذا العنوان كعنوان وجهة لرزم البيانات، ويلزم أن تتخلص المُوجِّهات أي رزمة مُوجَّهة نحو هذا العنوان.
• عنوان الحلقة العكسية (بالإنجليزية: The Loopback Address)‏: وهو العنوان 0:0:0:0:0:0:0:1 أو اختصارًا 1::، ويُمكن أن يستخدم من قبل أي عقدة لإرسال رزم بيانات إلى نفسها، لذلك لا يجب أن يُمنح هذا العنوان لأي منفذ مادي. لا يُستعمل هذا العنوان كعنوان مصدر للرزم التي ستغادر عقدة ما، ولا يجب أن تُوجَّه الرزم التي تكون وجهتها عنوان الحلقة العكسية نحو خارج العقدة. ويلزم أن تتخلص الموجهات أي رزمة موجهة نحو عنوان الحلقة العكسية.
• عناوين البث فريد الوجهة العالمي (بالإنجليزية: Global Unicast Address)‏: وتُستخدم لعنونة منفذ ما على الإنترنت بشكلٍ فريدٍ على مستوى العالم. يتكون العنوان من ثلاثة حقول: حقل بادئة التوجيه العالمية، وهي تمنح للموقع الذي يُشغل المنفذ بحسب هرمية تحصيص رباعية المستويات تديرها هيئة أرقام الإنترنت المُخصصة، وحقل مُعرف الشبكة الجزئية والذي يَضبطه مشغلو الموقع، حيث يوجد المنفذ، وذلك بهدف تجزئة الفضاء الممنوح إلى أفضية جزئية أصغر حجمًا لأغراض إدارية أو تنظيمية.

في عناوين البث فريد الوجهة العالمية التي لا تكون قيمة البتات ذات الأهمية العليا فيها ₂(000)، يكون مجموع طولي حقلي بادئة التوجيه العالمية ومُعرِّف الشبكة الجزئية 64 بت، ما يترك 64 بتًّا لمُعرف المنفذ، وبهذا تتوافق بنية هذه العناوين مع آلية التهيئة الذاتية الآلية. أما العناوين التي تكون قيمة البتات ذات الأهميةً العليا فيها ₂(000) فهي لا تُلزَم بالبنية السابقة. وفي ما يأتي مثالٌ عن هذا العنوان:

1::2001:1111:2222:3333

• عناوين البث فريد الوجهة في الوصلة المحلية (بالإنجليزية: Link-Local Unicast Address)‏: ويشغل الفضاء fe80::/10، تُستخدم عناوين هذا الفضاء على مستوى الوصلة المحلية فقط، وهي مصممة لتخدم أغراضًا مثل التهيئة الآلية للعنوان واكتشاف الجيران. لا يجب على المُوجِّهات توجيه أي رزمة بيانات يكون عنوان مصدرها أو وجهتها عنوان وصلة محلية.

يتكون عنوان الوصلة المحلية من ثلاثة حُقول: الحقل الأول هو مُعرِّف فضاء عناوين الوصلة المحلية، وطوله 10 بتات وقيمته ₂(1111111010)، أما الحقل الثاني فهو حقل صفري يبلغ طوله 54 بتًّا، والحقل الثالث هو حقل مُعرف المنفذ، ويُستخدم لتمييز المنفذ بشكل فريد على مستوى الوصلة المحلية. وفي ما يأتي مثالٌ عن هذا العنوان:

fe80::1ff:fe01:101

• عناوين البث فريد الوجهة الفريد المحلي (بالإنجليزية: Unique Local IPv6 Unicast Addresses)‏: حُجر له الفضاء fc00::/7، ويُستخدم من أجل عنونة منفذ بشكل فريد على المستوى العالمي، ولكن من أجل إنشاء اتصالات محلية فقط، ولذلك لا يمكن توجيه الرزم المعنونة بهذه العناوين خارج الموقع الذي ولِّدت فيه.

يتألف العنوان الفريد المحلي من 5 حقول، أولها هو حقل البادئة وطوله 7 بتات وقيمته هي ₂(1111110) دائمًا، ويليه بت المحلية، ويُضبط إلى القيمة 1 دائمًا للإشارة إلى أن العنوان قد وُلِّد محليًّا،⁽⁸⁾ ثُمَّ حقل المُعرِّف العالمي وطوله 40 بتًّا، وهو مُعرِّف فريد على مستوى العالم يضبط محليًّا إلى قيمة عشوائية، ثُمّ حقل مُعرِّف الشبكة الجزئية طوله 16 بت، وهو حقل مخصص لمديري الشبكة لإتاحة إمكانية إنشاء شبكات جزئية، وأخيرًا مُعرِّف المنفذ وطوله 64 بتًّا، ويميز كل منفذ على حدته بشكل فريد. وفي ما يأتي مثالٌ عن هذا العنوان: مرجع

fdf8:f53b:82e4::53

• عناوين البث فريد الوجهة المحلي في الموقع (بالإنجليزية: Site-Local Unicast Address)‏: وهو صنف مُبطَل من عناوين البث فريد الوجهة. طُوِّر في الأصل ليَخدُم غرض العنونة داخل موقع ما دون الحاجة لبادئات عالمية. حُجر له الفضاء fec::/10، كانت بنية هذه العناوين مكونة من ثلاثة حقول: الحقل الأول هو معرف فضاء العناوين المحلية في الموقع، وطوله 10 بتات وقيمته ₂(1111111011)، أما الحقل الثاني فهو مُعرِّف الشبكة الجزئية، ويضبطه مشرفو الموقع حسب الحاجة، وأما الحقل الثالث فهو مُعرِّف المنفذ ويبلغ طوله 64 بتًّا. وفي ما يأتي مثالٌ عن هذا العنوان:
  fec0::1234:5678:9abc
• عناوين البث فريد الوجهة التي تتضمن عناوين من الإصدار الرابع: يوجد عنوانان من عناوين البث فريد الوجهة في الإصدار السادس يحملان في البتات الاثنين والثلاثين ذات الأهمية الدنيا عناوين من الإصدار الرابع من بروتوكول الإنترنت وهما:

• عناوين البث فريدة الوجهة المُتوافِقة مع الإصدار الرابع (بالإنجليزية: IPv4-Compatible Unicast Address)‏: عُرِّفت هذه العناوين في الأصل لتساهم في دعم عملية الانتقال من استعمال الإصدار الرابع إلى الإصدار السادس من بروتوكول الإنترنت. يتكون هذا العنوان بدءًا من الخانة الأكثر أهمية من 80 صفرًا يليها عنوان الإصدار الرابع من بروتوكول الإنترنت الذي يلزم أن يكون فريدًا عالميًّا.

تُستخدم الطريقة الهجينة لتمثيل هذه العناوين. أبطلت طريقة الانتقال التي تستعمل هذه العناوين، ولذلك لم تعد هذه العناوين قيد الاستخدام. وفي ما يأتي مثالٌ عن هذا العنوان:

200.100.10.1::

• عناوين البث فريدة الوجهة المُقترنة مع الإصدار الرابع (بالإنجليزية: IPv4-Mapped Unicast Address)‏ وتستعمل لحمل عنوان الإصدار الرابع من بروتوكول الإنترنت الذي تستضيفه العقدة التي تدعم الإصدار السادس أيضًا. وصفت طريقة استعمال هذا العنوان في وثيقة طلب التعليقات RFC 4038، وهو يتكون من ثلاثة حقول بدءًا من الخانة الأكثر أهمية هي 80 صفرًا متتاليًّا في الحقل الأول، يليها 16 واحدًا متتاليًّا في الحقل الثاني، ثُمَّ عنوان الإصدار الرابع من بروتوكول الإنترنت. وفي ما يأتي مثالٌ عن هذا العنوان:
  ffff:192.0.2.47::

• 
  بنية عنوان البث فريد الوجهة العالمي.
• 
  بنية عنوان البث فريد الوجهة في الوصلة المحلية.
• 
  بنية عنوان البث فريد الوجهة في الفريد المحلي.
• 
  بنية عنوان البث فريد الوجهة المحلي في الموقع.
• 
  بنية عنوان البث فريد الوجهة المُتوافِق مع الإصدار الرابع من بروتوكول الإنترنت.
• 
  بنية عنوان البث فريد الوجهة المُقترن مع الإصدار الرابع من بروتوكول الإنترنت.

عناوين البث نحو الأقرب

عنوان البث نحو الأقرب في الإصدار السادس من بروتوكول الإنترنت (بالإنجليزية: IPv6 anycast address)‏ هو عنوان بث فريد الوجهة يُمنح لأكثر من منفذ في الوقت عينه، وغالبًا ما تكون في هذه المنافذ في عقد متمايزة. إذا أُرسلت رزمة بيانات ما إلى عنوان بث نحو الأقرب، فإنها تُرسل إلى أقرب⁽⁵⁾ عقدة تستضيف ذلك العنوان. تُحصص عناوين البث نحو الأقرب من فضاء البث فريد الوجهة، من غير أي قيود إضافية، لذلك لا يمكن تمييز عناوين البث نحو الأقرب عن عناوين البث فريد الوجهة رياضيًّا. بعبارة أخرى، إذا مُنح عنوان بث فريد الوجهة إلى أكثر من منفذ في الوقت عينه فإنَّه يًصبح عنوان بثٍّ نحو الأقرب، ويجب تهيئة العقد بشكل صريح لتكون على دراية بذلك.

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

يَلزَم أن تميير المُوجِّهات عنوان البث نحو الأقرب ببند فريد في جداول التوجيه ضمن جزء الطوبولوجيا الذي توجد فيه العناوين، ولكن خارج هذا الجزء، يمكن تجميع العنوان مع مسارات أخرى ولا داعٍ لتمييزه ببند فريد. توجد حالة خاصة يلزم أن يكون فيه بند عنوان البث نحو الأقرب فريدًا على مستوى الإنترنت كلها ولا يجوز تجميع هذا البند مع أي بند آخر، وتحصل هذه الحالة عند استعمال بادئة غير مُحدَدة طوبولوجيًّا (بالإنجليزية: null prefix)‏، أي أنها يمكن أن تمنح للمنافذ في أي موقع في الإنترنت.

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

طالع أيضًا: بث مجموعاتي

بنية عنوان البث المجموعاتي.

عنوان البث المجموعاتي هو مُعرِّف رقمي يُميِّز مَجموعة محددة من المنافذ التي تستضيفه. إن إرسال أي رزمة بيانات إلى عنوان بث مجموعاتي ما سيؤدي إلى توجيهها إلى جميع أعضاء المجموعة المميزة بذلك العنوان. يتكون عنوان البث المجموعاتي من أربعة حقول هي وفقًا لترتيب ورودها من الخانة الأعلى أهمية:

• حقل بادئة البث المجموعاتي: طوله 8 بت، ويحتوي القيمة ₂(11111111) أو ₁₆(FF)، وهي تميز عناوين فضاء البث المجموعاتي جميعها.
• حقل الأعلام: طوله 4 بت، تُثبَّت قيمة البت الأعلى أهمية فيه إلى القيمة 0، وأما البتات الثلاثة اللاحقة في وفقًا لترتيب ورودها من الخانة الأعلى أهمية:

علم الالتقاء: ويحدد فيما إذا كان العنوان يتضمن عنوان نقطة الالتقاء أم لا، فهو كذلك إذا كان واحديًّا، أما إذا كان صفريًّا فهو بخلاف ذلك.

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

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

• حقل المجال: طوله 4 بت، ويضم رمزًا يحدد المجال الطوبولوجي الذي تمتد عليه المجموعة كما في الجدول التالي:

قيمة حقل المجال بنظام العد الثنائي	اسم المجال	امتداد المجال
0000	محجوز	-
0001	مجال المنفذ	يشمل هذا المجال منفذًا واحدًا في عقدة واحدة، ويستعمل هذا المجال في تطبيقات الحلقة العكسية.
0010	مجال الوصلة المحلية	يمتد المجال ليغطي الشبكة المحلية بشكلٍ متوافق مع شبكة عناوين البث فريد الوجهة المُستخدَمة محليًّا.
0011	محجوز	-
0100	مجال الإشراف المحلي	يمتد المجال على جزء من الشبكة يقوم مشرفوها بتحديده، وهو أصغر مجال يمكن تحديده إشرافيًّا.
0101	مجال الموقع المحلي	يمتد المجال ليغطي موقعًا محليًّا واحدًا، قد يشمل عدة شبكات محلية، ولكنَّها تعود لمنظمة واحدة.
0100	مجال المنظمة المحلي	يمتد المجال على عدة مواقع محلية لمنظمة واحدة.
1110	المجال العالمي	يشمل المجال الإنترنت كاملة.
1111	محجوز	-

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

• حقل مُعرف المجموعة، وطوله 112 بت، ويضم مُعرفًا رقميًّا يميز المجموعة ضمن المجال المُحدد بحقل المجال. توجد بنى عناوين بث مجموعاتي أكثر تخصصًا، ومنها مثلًا ما تُعرِّفه الوثيقة RFC 3306، وفيه يُقسم مُعرف المجموعة إلى ثلاثة أربعة حقول تتضمن مُعرِّفًا للمجموعة بطول 32 بت فقط، وحقلًا لبادئة شبكة البث فريد الوجهة الذي يُمنح العنوان على أساسها. وتصف الوثيقة RFC 7371 بنى عناوين البث المجموعاتي في الإصدار السادس وحالاتها المُختلفة ومعاني كلٍ منها.

أفضية محجوزة

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

أفضية البث فريد الوجهة والبث نحو الأقرب

طالع أيضًا: أفضية بروتوكول الإنترنت المحجوزة

جدول بأفضية العناوين الجزئية المحجوزة من فضاء عناوين الإصدار السادس من بروتوكول الإنترنت

فضاء العناوين	تاريخ الحجز	ملاحظات	مرجع
128/::	فبراير 2006	العنوان غير المُحدد
1/128::	فبراير 2006	عنوان الحلقة العكسية
ff9b::/96	أكتوبر 2010	مخصص لمترجمات العناوين بين الإصدارين الرابع والسادس
ffff:0:0/96::	فبراير 2006	فضاء العناوين المقترنة مع الإصدار الرابع
64/::100	يونيو 2012	بادئة الاستبعاد (بالإنجليزية: Discard Prefix)‏، وهي بادئة تستعمل في عملية التوجيه والترشيح للتخلص من رزم البيانات
23/::2001	سبتمبر 2000	مخصص لعملية تطوير إرشادات لمنح أفضية الإصدار السادس من بروتوكول الإنترنت
32/::2001	فبراير 2006	مخصص لدعم تقنية تيريدو للانتقال من الإصدار الرابع نحو الإصدار السادس من بروتوكول الإنترنت
1/48::2001:1	أكتوبر 2015	عنوان مُخصص للبث نحو الأقرب لبروتوكول التحكم بالمنافذ
2/48::2001:1	فبراير 2017	عنوان مُخصص للبث نحو الأقرب بروتوكول تخطي الترجمة باستعمال المُرحلات TURN
48/::2001:2	أبريل 2008	فضاء مخصص لعملية المقارنة المرجعية
32/::2001:3	ديسمبر 2014	فضاء مخصص للإنشاء الآلي لأنفاق البث المجموعاتي
48/::2001:4:112	ديسمبر 2014	فضاء مخصص لمشروع النظام المستقل رقم 112 (بالإنجليزية: AS112 project)‏
28/::2001:10	أبريل 2007(9)	فضاء مخصص لبادئة معرفات التجزئة المُعمَّاة المتراكبة القابلة للتوجيه، المعروفة اختصارًا بالاسم الرمزي: أوركيد ORCHID
28/::2001:20	يوليو 2014	فضاء مخصص للإصدار الثاني لبادئة معرفات التجزئة المُعمَّاة المتراكبة القابلة للتوجيه، المعروفة اختصارًا بالاسم الرمزي: أوركيد 2
2001:0db8::/32	يوليو 2004	فضاء مخصص لعملية التوثيق
16/::2002	فبراير 2001	فضاء مخصص لدعم تقنية 6 إلى 4 (بالإنجليزية: 6to4)‏ للانتقال من الإصدار السادس نحو الإصدار الرابع من بروتوكول الإنترنت
fc00::/7	أكتوبر 2005	مخصص لفضاء عناوين البث فريد الوجهة الفريد المحلي
fe80::/10	أكتوبر 2005	مخصص لفضاء عناوين البث فريد الوجهة في الوصلة المحلية

فضاء البث المجموعاتي

تدير أيانا فضاء عناوين البث المجموعاتي في الإصدار السادس من بروتوكول الإنترنت، وهو الفضاء الذي يتحدد بالبادئة ff00::/8. توجد مجموعة من العناوين المُعرَّفة المحجوزة التي لا يجب منحها لأي مجموعة في شبكات الإصدار السادس، وهي:

• جميع العناوين ذات البنية ff0#:0:0:0:0:0:0:0، وعددها 16 عنوانًا، حيث # هي مرتبة ستة عشرية تأخذ أي قيمة من المجال {9 .. 1,2} أو{a,b .. f}.
• عنوانا مجموعتي كل العقد في مجال المنفذ وفي المجال المحلي، وهما على الترتيب: ff01:0:0:0:0:0:0:1 وff02:0:0:0:0:0:0:1.
• عناوين مجموعات كل الموجهات في مجال المنفذ والمجال المحلي ومجال الموقع، وهذه العناوين هي على الترتيب: ff01:0:0:0:0:0:0:2 وff02:0:0:0:0:0:0:2 وff05:0:0:0:0:0:0:2.
• • عناوينُ التماس العقدة من فضاء البثٍّ فريد الوِجهة أو فضاء البثّ نحو الأَقرب، ويتحدد هذا الفضاء بالبادئة: ff02:0:0:0:0:1:ff00::/104.
• أي عناوين مجموعات أخرى محجوزة من قبل هيئة أرقام الإنترنت المُخصصة، مثل مجموعات الموجهات التي تشغل بروتوكولات التوجيه، مثلًا ff02:0:0:0:0:0:0:9 من أجل مجموعة كل الموجهات التي تشغل بروتوكول معلومات التوجيه، وff02:0:0:0:0:0:0:a من أجل مجموعة كل الموجهات التي تشغل بروتوكول التوجيه الداخلي المحسن بين البوابات وغير ذلك.

عناوين ملزمة

تميّز معايير الإصدار السادس من بروتوكول الإنترنت بين المُضيف والمُوجِّه، فالموجه هو عقدة تُوجِّه رزم بيانات لم تولدها للإصدار السادس من بروتوكول الإنترنت. أمَّا المُضيف فهو أي عقدة ما خلا الموجهات. بناءً على ذلك، يلزم على كل مُضيف أن يكون قادرًا على تمييز العناوين التالية بصفتها معرفاتٍ ذاتية:

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

أمَّا المُوجِّه، فيلزم أن يميز العناوين السابقة التي يميزها المضيف، وأيضًا العناوين التالية، بوصفها مُعرفات ذاتية:

• عناوين البث نحو الأقرب للشبكات الجزئية على جميع المنافذ التي هُيِّئت لتعمل بوصفها منافذَ للمُوجه.
• جميع عناوين البث نحو الأقرب التي جرت تهيئة المُوجِّه بها.
• جميع عناوين البث المجموعاتي المحجوزة للمُوجِّهات.

التهيئة الذاتية الآلية

التهيئة الذاتية الآلية في الإصدار السادس من بروتوكول الإنترنت أو التهيئة غير المركزية الآلية (بالإنجليزية: IPv6 Stateless Address Autoconfiguration)‏ هي آلية تحدد الخطوات التي يتخذها مضيفو الإصدار السادس من أجل تهيئة منافذهم ذاتيًّا بعناوين وصلة محلية أو عناوين عالمية باستعمال معرفات المنفذ المولدة محليًَّا ومعلومات البادئات التي يحصل المُضيف عليها من إعلانات الموجهات في الشبكة المحلية، وتشمل هذه الآلية أيضًا إجراءاتٍ مُحددة لاكتشاف الاستخدام المتعدد للعنوان لضمان فرادته على مستوى الوصلة المحلية. لا تتطلب التهيئة الذاتية أي إعداد يدوي في المضيفين، وإعداد بسيطًا، وقد لا يكون ضروريًّا، في الموجهات وهي لا تحتاج لوجود مُخدِّمات. يمكن للمضيف، في غياب الموجهات، أن يولد عنوانًا محليًّا في الوصلة ذاتيًّا دون أي تدخل خارجي.

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

1. تكون بادئة العنوان هي fe80::/10، وتحجز البتات العشرة الأعلى أهمية.
2. يُملأ سائر العنوان بالأصفار.
3. يحسب مُعرِّف المنفذ وليكن طوله N بت، وقد يحتوي عنوان مادي موجود في المنفذ نفسه، ويكون طوله 64 بت في الغالب.
4. بدءًا من الخانة الأقل أهمية في العنوان يُستبدل N صفرًا في العنوان بمُعرف المنفذ.

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

في ما يخص مُعرفات المنافذ، فيمكن توليدها باستعمال العناوين المادية كما في آلية توليد المُعرّف الفريد المُوسّع (EUI) المطورة من قبل معهد مهندسي الكهرباء والإلكترونيات، أو تُولَّد بصورة مستقلة العناوين المادية باعتماد خوارزمية موصوفة في وثيقة طلب التعليقات RFC 7217 وتكون المُعرفات الناتجة عنها آمنة ومستقرة وفريدة على المستويين المحلي والعالمي.

إدارة فضاء العناوين: التحصيص والمنح

هرمية تحصيص فضاء عناوين بروتوكول الإنترنت رباعية المستويات.

مثال عن مستويات التحصيص في الإصدار السادس من بروتوكول الإنترنت.

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

وضع آيكان سياسةً تُنظِّم عملية التحصيص، تُلزَم أيانا بموجبها على تقديم حصص من العناوين لسجلات الإنترنت الإقليمية تكفي حاجتها 18 شهرًا على الأقل، على أن يكون طول البادئة الأدنى الذي تحصصه أيانا هو البادئة 12/. توفِّر عملية التهيئة الذاتية الآلية (بالإنجليزية: Stateless address autoconfiguration اختصاراً SLAAC)‏ وسيلةً لعنونة المُضيفين آليًَّا باستعمال العناوين المحليَّة دون الحاجة لتدخلٍ يدويٍّ من قبل مدير الشبكة، حيث يجري ملء قسم مُعرِّف المنفذ اعتمادًا على مُعرِّفات المنافذ. تحدد وثيقة طلب التعليقات RFC 4291 العلاقة بين طول البادئة ومُعرِّف المنفذ في عنوان الإصدار السادس الذي يبلغ طوله 128 بتًّا، فإذا كان طول البادئة هو n بت، فإن طول مُعرِّف المنفذ الملائم لعملية التهيئة الذاتية الآلية سيكون (128-n) بتًّا، وتدعم الشركات المُصنِّعة لبطاقات الشبكة هذا المعيار أو تقدِّم حلولًا متوافقة معه، مثل حل المُعرِّف الفريد المُوسَّع الذي وضعه معهد مهندسي الكهرباء والإلكترونيات لإيجاد التوافق مع العنوان المادي في الإيثرنت الذي يبلغ طوله 48 بتًّا فقط. أي يُستحسن أن يكون طول البادئة النهائي هو 64 بتًّا لإتاحة الفرصة لعملية التهيئة الذاتية الآلية

نظريًَّا، خلال عمليتي التحصيص والتخصيص⁽¹⁰⁾ لعناوين الإصدار السادس من بروتوكول الإنترنت، يكون طول البادئة محصورًا بين البادئة 12/ وهو الطول الأدنى الذي تحصصه أيانا، والبادئة 64/، وهو الطول الأقصى اللازم لدعم عملية التهيئة الذاتية الآلية. عمليًَّا، حصصت أيانا بادئات بأطوال 23/ و12/ لسجلات الإنترنت الإقليمية التي قدمت بدورها حلولًا لمزودات الخدمة أو للعملاء على حد سواء، لمنح أفضية جزئيَّة متنوعة الأحجام ذات بادئات لا يتجاوز طولها البادئة 64/، وعلى سبيل المثال، يَدعم مركز تنسيق شبكة الإنترنت الأوروبي (RIPE NCC)، وهو سجل إنترنت إقليمي، حصصًا لأفضية جزئية ذات بادئات يتراوح طولها بين البادئتين 32/ و64/، ويشير إلى أن الأطوال الأكثر شعبية هي للبادئتين 48/ و56/ وهي تضم على التوالي: 65,536 و256 شبكة جزئية مُحددة بالبادئة 64/.

التجزئة

جدول لأطوال بادئة التوجيه غير الصنفي بين النطاقات في الإصدار السادس من بروتوكول الإنترنت وأعداد الشبكات الجزئية الموافقة لكل منها وعدد بتات قسم مُعرف المنفذ.

حالات حدود معرف الشبكة الجزئية (SID) في الإصدار السادس من بروتوكول الإنترنت.

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

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

إن التجزئة في الإصدار السادس من بروتوكول الإنترنت تتشابه من حيث الآلية الرياضية مع التجزئة في الإصدار الرابع، لكنها تختلف من حيث الغاية، فهي تهدف إلى تنظيم استعمال فضاء العناوين بطريقة متوافقة مع آلية التوجيه، ولا تستخدم لتحديد حجم محدد من أفضية العناوين كما في الحالة في الإصدار الرابع، فعدد العناوين المتاحة في شبكة جزئية واحد من الإصدار السادس طول بادئتها 64 بت، يبلغ المليارات، وهو بحد ذاته، أكبر من كامل فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت.

يتكون عنوان الإصدار السادس من بروتوكول الإنترنت من 128 بت، ويكتب بنظام العد الست عشري على شكل عدد مكوّن من 32 مرتبة ست عشرية، ويجري تجميع هذه المراتب ضمن رباعيات عددها 8 يضم كل منها 4 مراتب ست عشرية أو 16 بت. عند تجزئة فضاء عناوين من الإصدار السادس، يجري اقتطاع قسم من مُعرّف المنفذ وإنشاء قسم جديد هو معرف الشبكة الجزئية، يمكن وفقًا لموقع نهاية مُعرّف الشبكة الجزئية ضمن العنوان التمييز بين الحالات التالية:

1. مُعرّف الشبكة الجزئية ينتهي عند حدود إحدى المجموعات الرباعية، ويعني ذلك أن نهاية المُعرّف تكون عند أحد البتات ذوات الفهارس {15,31,47,63,79,95,111,127}.
2. مُعرّف الشبكة الجزئية ينتهي عند حدود إحدى المراتب الست عشرية ضمن مجموعة رباعية، وتوجد 3 حالات ممكنة في كل مجموعة رباعية، مثلًا في المجموعة الأولى هي البتات ذات الفهارس {3,7,11} وفي الثانية {19,23,27} وهكذا..
3. مُعرّف الشبكة الجزئية ينتهي عند حدود أحد البتات ضمن خانة ست عشرية داخل مجموعة رباعية، وتوجد 3 حالات ممكنة في ضمن كل خانة ست عشرية، مثلًا في الخانة الست عشرية الثانية تكون الحدود الممكنة عند البتات ذات الفهارس {4,5,6} وفي الخانة الست عشرية الثالثة عند البتات ذات الفهارس {8,9,10} وهكذا.⁽¹¹⁾

أمثلة عن التجزئة في الإصدار السادس من بروتوكول الإنترنت:

• 
  التجزئة من أجل عدد محدد لأفضية عناوين الشبكات الجزئية، حالة معرف الشبكة الجزئية ينتهي عند حدود المجموعة الرباعية.
• 
  التجزئة من أجل عدد محدد لأفضية عناوين الشبكات الجزئية، حالة معرف الشبكة الجزئية ينتهي عند حدود مرتبة ست عشرية.
• 
  التجزئة من أجل حجم محدد لأفضية عناوين الشبكات الجزئية، حالة معرف الشبكة الجزئية ينتهي عند حدود بت ضمن مرتبة ست عشرية.
• 
  التجزئة من أجل طول محدد لقناع الشبكات الجزئية، حالة معرف الشبكة الجزئية ينتهي عند حدود مرتبة ست عشرية.

التقطيع

المبدأ العام للتقطيع في الإصدار السادس من بروتوكول الإنترنت.

المقالة الرئيسة: تقطيع (شبكات) § التقطيع في الإصدار السادس من بروتوكول الإنترنت

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

نظريًّا، يمكن إرسال رزمة بيانات تبلغ من الطول 65535 بايتًا من غير تقطيعها ولكن غالبًا ما يلزم التقطيع للتماشي مع طول نقل أعظم أقل من هذه القيمة مُحدد سلفًا في طبقة الوصلة، أما طول رزمة البيانات الأدنى الذي يدعمه البروتوكول فهو 1280 بايت. يدعم البروتوكول أيضًا الرزم العملاقة (بالإنجليزية: Jumbogram)‏، وهي رزم بيانات يتراوح طولها بين 2¹⁶=65535 و2³²=4294967295 بايت وتستخدم في شبكات بيانات تدعم أحجام نقل عظمى أكبر من 65535.

التقطيع

مخطط تدفقي يبين خوارزمية عملية التقطيع في الإصدار السادس من بروتوكول الإنترنت.

يعامِل المُضيف المصدر رزمة البيانات التي يريد تقطيعها على أنها مكوِّنة من ثلاثة أجزاء:

1. الترويسات التي ستوضع في القطع كلها: تضم هذه الترويسات ترويسة الإصدار السادس وترويسات التوسعة التالية لها حتى ترويسة التوجيه، إن وجدت، وإلا فحتى ترويسة خيارات المسار، إن وجدت، فإن غابت الترويستان السابقتان ضمَّ هذا الجزء ترويسة الإصدار السادس فقط.
2. ترويسات التوسعة والطبقات العليا: وتضم جميع ترويسات التوسعة الأخرى التي لم تُشمل في القسم السابق، أما ترويسات الطبقات العليا فتشمل جميع الترويسات التي ليست ترويسات توسعة مثل ترويسات بروتوكول التحكم بالنقل وبروتوكول حزم بيانات المستخدم أو ترويسة بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت.⁽¹²⁾
3. الحمولة: وهي القسم الذي سوف يُقطَّع، ويبدأ بعد ترويسات الطبقات العليا.

تجري عملية التقطيع وفق الخطوات التالية:

1. تحديد طول رزمة الإصدار السادس التي ستنتج عن التقطيع.
2. إنشاء القطعة الأولى، وهي تتضمن ما يأتي وفقًا لتسلسل الورود: الترويسات التي ستوضع في القطع كلها وترويسة القطعة وترويسات التوسعة والطبقات العليا وقطعة من الحمولة، يحدد طولها كما يأتي:
   1. يُحسب مجموع أطوال الترويسات التي ستوضع في القطع كلها وترويسة القطعة وترويسات التوسعة والطبقات العليا.
   2. يُطرح المجموع من طول رزمة الإصدار السادس المُحدد بالخطوة الأولى، والناتج هو طول حمولة القطعة الأولى.
3. تُقتطع حمولة القطعة الأولى من حمولة الرزمة الأصلية.
4. تحديد عدد القطع اللازم تقطيعها بتقسيم حمولة الرزمة الأصلية، بعد اقتطاع حمولة القطعة الأولى، على طول الرزمة المُحدد بالخطوة الأولى، إذا كان الجواب كسريًّا، فإن القسم الصحيح هو عدد القطع الوسطى، أي التي تقع بين القطعتين الأولى والأخيرة، وأما الجزء الكسري، فيمثل القطعة الأخيرة.
5. تقسم حمولة الرزمة الأصلية، بعد اقتطاع حمولة القطعة الأولى، إلى عدد القطع المحددة بالخطوة الرابعة.
6. إنشاء القطع الوسطى: تتضمن القطع الوسطى الترويسات التي ستوضع في القطع كلها وترويسة القطعة وقطعة من الحمولة الناتجة عن الخطوة الخامسة ما خلا القطعة الأخيرة إذا كان عدد القطع كسريًّا.
7. إنشاء القطعة الأخيرة: وتتضمَّن الترويسات التي ستوضع في القطع كلها وترويسة القطعة والقطعة الأخيرة من الحمولة الناتجة عن الخطوة الخامسة.

إعادة التجميع

بنية رزمة بيانات الإصدار السادس من بروتوكول الإنترنت الناتجة عن إعادة تجميع القطع في المضيف الوجهة.

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

إدارة حركة البيانات

تعريف تدفقات حركة البيانات

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

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

تصنيف حركة البيانات

بنية حقل صنف حركة البيانات في ترويسة الإصدار البروتوكول.

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

يُقسَّم حقل صنف حركة البيانات إلى قسمين، هما قسم موقع ترميز الخدمات المتمايزة (بالإنجليزية: Differentiated services codepoint)‏ ويشغل البتات الستة الأكثر أهمية من الحقل، وقسم البتات غير المُستعملة ويشمل البتين الأخيرين. وتحدد الوثيقة RFC 2474 بنية محددة لقسم موقع الترميز هي: "xxx000" حيث تُمثِّل x بتًّا واحدًا قد تكون قيمته 0 أو 1، ويسمح ذلك بإنشاء 8 أصناف متمايزة لرزم البيانات. يُحجز الترميز "000000" ليكون القيمة الافتراضية الدائمة لهذا الحقل، أما القيم السبعة الأخرى، أي {"001000"، "010000"، "011000"... "111000"}، فهي قابلة للتهيئة وفقًا للحاجة ولتعريف مستويات جودة الخدمة المطلوبة.

المُشكلات

مرتبطة بتقطيع البيانات

ينتج عن استخدام التقطيع في الإصدار السادس من بروتوكول الإنترنت عدد من الثغرات الأمنيّة التي قد تستخدم لشن هجمات مثل هجوم القطعة الصغيرة أو هجوم القطع المتراكبة، وتختلف إمكانية شن الهجمات وفقًا لنظام التشغيل الذي يستعمل البروتوكول. بشكلٍ مُشابه للإصدار الرابع من بروتوكول الإنترنت، لم تمنع مُحددات الإصدار السادس إنشاء قطع متراكبة عند التقطيع، أي من الممكن أن يتكرر المقطع نفسه من الحمولة في أكثر من قطعة، على أن يُعتمد المقطع الوارد في آخر قطعة تمّ استقبالها عند التجميع، يسبب ذلك ثغرة أمنية، ويسمح بتنفيذ هجوم القطع المتراكبة، لاحقًا أُكِّد بوضوح على منع تراكب القطع عند التقطيع في وثيقة طلب التعليقات RFC 5722.

يقبل مُضيف الإصدار السادس من بروتوكول الإنترنت أن تحتوي رزمة البيانات على ترويسة القطعة من غير أن تكون القطعة ناتجة عن عملية تقطيع، وتسمى هذه القطع بالقطع الذرية (بالإنجليزية: Atomic Fragment)‏ وهي تنتج في حالات خاصة ناقشها المعيار الأصلي للبروتوكول، على الرغم من أن هذه القطع تكون وحدانًا، أي لا يجب تجميعها مع أي قطع أخرى، فإنّ المُضيف الوجهة يعاملها مُعاملة القطع التي تنتظر التجميع، ما يُسبب ثغرة أمنية، فقد يرسل المهاجم قطعة خبيثة مع قيم مُناسبة في ترويسة القطعة، بحيث تكون قطعة ذرية تقبل التجميع مع قطع أخرى خبيثة تُرسل لاحقًا، ناقشت الوثيقة RFC 6946 كيفية معالجة القطع الذرية لتلافي هذا النوع من الهجمات.

مرتبطة بإدارة حركة البيانات

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

يوجد هجوم يُسمى هجوم سرقة الخدمة (بالإنجليزية: Theft of Service)‏ وفيه تُغيَّر قيمة حقل صنف الخدمة في رزمة بيانات ما من أجل زيادة أولويتها أو رفع جودة الخدمة المُقدمة لها، كما يُمكن أن يُشنَّ هجوم حجب الخدمة أيضًا من خلال تغيير قيمة حقل صنف الخدمة، لجعل رزمة أو مجموعة رزم بيانات تحصل على جودة خدمة أقل من الجودة المتوقعة لها، وقد يسبب هذا تأخيرًا زمنيًّا في وصولها إلى هدفها أو التخلص منها في الوجهة.

بروتوكولات رديفة

بروتوكول رسائل التحكم في الإنترنت للإصدار السادس

بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت
اختصار	ICMPv6
الوظيفة	بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت
المُطوِّر	مجموعة مهندسي الإنترنت
تاريخ التطوير	ديسمبر 1995
مبني على	بروتوكول رسائل التحكم في الإنترنت
طبقة نموذج OSI	طبقة الشبكة
وثيقة طلب التعليقات RFC	RFC 4443

بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت (بالإنجليزية: Internet Control Message Protocol for IPv6 اختصارًا ICMPv6)‏ هو بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت وجزءٌ مدمج منه، طُوِّر هذا البروتوكول بالتوازي مع الإصدار السادس من بروتوكول الإنترنت وصدر معياره الأصلي في شهر ديسمبر من العام 1995م ووصف في وثيقة طلب التعليقات RFC 1885.

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

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

في شهر ديسمبر من العام 1998 صدر تحديث جديد للبروتوكول في وثيقة طلب التعليقات RFC 2463، وبعدها بثمانية سنوات صدرت الوثيقة RFC 4443 وهي المعيار الحالي للبروتوكول وهي تتضمن تفصيلًا إضافيًّا عن الثغرات الأمنية التي يمكن استعماها لشن هجمات عبر البروتوكول وكيفية الوقاية منها ومجموعة من الاعتبارات اللازمة لهيئة أرقام الإنترنت المُخصصة من أجل تعريف أنواع رسائل جديدة.

بروتوكول اكتشاف الجيران

بروتوكول اكتشاف الجيران
اختصار	NDP
الوظيفة	بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت
المُطوِّر	مجموعة مهندسي الإنترنت
تاريخ التطوير	أغسطس 1996
مبني على	بروتوكول رسائل التحكم في الإنترنت
طبقة نموذج OSI	طبقة الشبكة وطبقة الوصلة
وثيقة طلب التعليقات RFC	RFC 4861

المقالة الرئيسة: بروتوكول اكتشاف الجيران

بروتوكول اكتشاف الجيران (بالإنجليزية: Neighbor Discovery Protocol)‏ هو بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت، يعمل بين الطبقتين الثانية والثالثة وفقًا نموذج الربط البيني للأنظمة المفتوحة، ويقدم خدمات التعرف على الموجهات والتعرف على الجيران وإعادة التوجيه. طرح المعيار الأصلي للبروتوكول في أغسطس من العام 1996 ووصف في وثيقة طلب التعليقات RFC 1970.

يُعرِّف هذا البروتوكول 5 رسائل من بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت هن: رسالة إعادة التوجيه وزوجين من الرسائل لاكتشاف عناوين الموجهات في الشبكة المحلية، هما رسالة التماس الموجه ورسالة الإعلان عن الموجه، وزوجين لاكتشاف عناوين الجيران، هما رسالة التماس الجار ورسالة الإعلان عن الجار اللتان أدى بهما البروتوكول مع الإصدار السادس وظيفة اقتران العناوين بين الطبقتين الثالثة والثانية، وهي الوظيفة نفسها التي يؤديها بروتوكول اقتران العناوين مع الإصدار الرابع من بروتوكول الإنترنت.

طُوِّرت أشكال متنوعة مشتقة من هذا البروتوكول، منها بروتوكول اكتشاف الجيران العكسيّ (بالإنجليزية: Inverse Neighbor Discovery Protocol)‏ الذي يؤدي وظيفة اقتران العناوين العكسية بين الطبقتين الثانية والثالثة والذي وصف في الوثيقة RFC 3122 على أنه توسعة لبروتوكول اكتشاف الجيران، وأيضًا بروتوكول اكتشاف الجيران الآمن (بالإنجليزية: SEcure Neighbor Discovery Protocol اختصارًا SEND)‏ الذي يُعرِّف آلياتٍ آمنة لتبادل بيانات الشبكة وفق بروتوكول اكتشاف الجيران، وقد وُصِف في وثيقة طلب التعليقات RFC 3971.

صدر تحديث جديد للمعيار في ديسمبر من العام 1998م، وحملت الوثيقة الاسم الرمزي RFC 2461. ثم صدرت الوثيقة RFC 4861 في شهر سبتمبر من العام 2007م، وهي المعيار الحالي لبروتوكول اكتشاف الجيران.

بروتوكول اكتشاف مستمعي البث المجموعاتي

بروتوكول اكتشاف مستمعي البث المجموعاتي
الوظيفة	إدارة مجموعة البث المجموعاتي في الإصدار السادس من بروتوكول الإنترنت
المُطوِّر	مجموعة مهندسي الإنترنت
تاريخ التطوير	2004
طبقة نموذج OSI	طبقة الشبكة
وثيقة طلب التعليقات RFC	RFC 3810

بروتوكول اكتشاف مستمعي البث المجموعاتي (بالإنجليزية: Multicast Listener Discovery اختصاراً MLD)‏ هو بروتوكول اتصال يعمل على مستوى الطبقة الثالثة وفقًا لنموذج الربط البيني للأنظمة المفتوحة، يدير المجموعات الخاصة بالبث المجموعاتي لرزم الإصدار السادس من بروتوكول الإنترنت، وبشكلٍ خاص اكتشاف أعضاء المجموعات في الشبكات المحلية وتحديد أي المجموعات التي يهتمون باستقبال رزمها.

يُقدّم البروتوكول مفهومًا خاصًّا بالإصدار السادس هو مفهوم مُستمع البث المجموعاتي (بالإنجليزية: Multicast Listener)‏، وهو وفقًا للتعريف، عقدة ترغب في استقبال رزم البث المجموعاتي. إذا استضاف المستمع عنوان مجموعة ما، أصبح عضوًا فيها، وبات يهتم باستقبال رزمها. يمكن أن ينضم المستمع إلى أكثر من مجموعة في الوقت نفسه. ومن هنا حصل البروتوكول على اسمه، فالبروتوكول يساعد تجهيزات الطبقة الثالثة المُتصلة مع الشبكة المحليّة على اكتشاف وجود المُستمعين فيها. يُوصف البروتوكول أيضًا بأنه غير متناظر (بالإنجليزية: Asymmertic)‏، لأنه يسلك سلوكًا مختلفًا عند تعامله مع المستمعين عن ذلك الذي يتبعه مع تجهيزات الطبقة الثالثة، مثل المُوجِّهات.

يوجد إصداران لبروتوكول اكتشاف مستمعي الإنترنت، الإصدار الأول منه موصوف في وثيقة طلب التعليقات RFC 2710 وقد طُوّر في العام 1999م، وهو مُكافئ للإصدار الثاني من بروتوكول إدارة مجموعة الإنترنت (IGMPv2) من حيث الوظيفة، أمّا الإصدار الثاني فطوّر في العام 2004م، وهو موصوف بالوثيقة RFC 3810 ويُكافئ الإصدار الثالث من بروتوكول إدارة مجموعة الإنترنت (IGMPv3)، ويدعم ميزات إضافية مثل البث المجموعاتي مُحدد المصدر .

هوامش

1. لا يُلزم المعيار منفذي البروتوكول اتباعَ الترتيب التالي اتباعًا إلزاميًّا، ولكنه يستحسن ذلك.

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

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

4. القطاع الشبكي هو اتصال كهربائي مشترك بين منافذ الشبكة.

5. يختلف تفسير معنى كلمة «أقرب» باختلاف بروتوكول التوجيه المُستعمل، فلكل بروتوكول توجيه آلية محددة لقياس وزن المسار، قد تعتمد على عدد القفزات للوجهة، أو على مُعدل النقل في الوصلات أو غير ذلك، ويتحدد المنفذ الأقرب حسبَ هذه الآلية.

6. يلزم أن تُكتب الحروف اللاتينية بالحالة الصغيرة لا الكبيرة، أي a لا A.

7. لا تستخدم محددات البروتوكول كلمة رباعية، ولكن هذه الكلمة شائعة لوصف هذا المفهوم.

8. بسبب كون قيمة بت المحلية ثابتة دائماً على القيمة 1، لعدم وجود استخدام آخر لها حتى الآن، فإن بعض المراجع تشير لبادئة هذا الفضاء بالشكل fd::/8 بدلاً من fc::/7، وهذا خطأ شائع لا يجوز، لأن المعيار الرسمي يُشير إلى إمكانية تطوير لاحقة لاستخدامات أخرى لهذا العنوان تكون قيمة بت محلية فيها مساويةً للصفر.

9. حُرر هذا الفضاء في شهر مارس من العام 2014، ولم يعد محجوزًا.

10. للتحصيص (بالإنجليزية: Allocation)‏ وللتخصيص (بالإنجليزية: Assignment)‏ معنيان متمايزان في نظام سجلات عناوين الأنترنت. يُشير الأول، أي التحصيص، إلى تفويض منظمةٍ بالإشراف على فضاءٍ جزئيٍّ من فضاء بروتوكول الإنترنت مع توقعٍ بقيام هذه المنظمة بتجزئة الفضاء وتفويض الأفضية الجزئية الناتجة إلى منظمات أخرى. أمّا الثاني، أي التخصيص، فهو يستعمل عند منح الفضاء إلى الجهات التي تستخدمه مباشرة في عنونة مجموعة من المضيفين.

11. يُستثنى البت رقم (0) من المرتبة الستة عشرية الأولى، ولذلك فحدود نهاية معرّف الشبكة الجزئية الخاصة بها تضمّ البتات ذات الفهارس {1,2} فقط، والسبب في ذلك أن استعماله يعني بادئة شبكة بطول (0) بت، وهي حالة مستحيلة.

12. في هذا السياق، تُستثنى ترويسة تأمين الحمولة بالتغليف وتعامل معاملة ترويسة الطبقات العليا مع أنها من أنها ترويسة توسعة للإصدار السادس من البروتوكول.

انظر أيضًا

• بروتوكول الإنترنت
• الإصدار الرابع من بروتوكول الإنترنت

المراجع

فهرس المراجع

فهرس المنشورات العربية

فهرس المنشورات الأجنبية

فهرس مواقع الويب

معلومات المراجع المُفصَّلة

الكتب (مرتبة تصاعديًّا حسب تاريخ النشر)

الإنجليزية:

• Peter John Dyson (1999). Dictionary of Networking (بالإنجليزية) (3rd ed.). San Francisco: Sybex. ISBN:0-7821-2461-5. OCLC:43596809. OL:8096220M. QID:Q115917529.
• Network Protocols Handbook (بالإنجليزية) (2nd ed.). California: Javvin Technologies Inc. 2005. ISBN:978-0-9740945-2-6. OCLC:61854497. OL:8581250M. QID:Q118316084.
• Charles Kozierok (2005). The TCP/IP Guide: a comprehensive, illustrated Internet protocols (PDF) (بالإنجليزية). San Francisco: No Starch Press. ISBN:978-1-59327-047-6. OCLC:1047847974. OL:8871404M. QID:Q115917346.
• Rami Rosen (2014). Linux Kernel Networking: implementation and theory (بالإنجليزية). New York City: Apress. ISBN:978-1-4302-6197-1. OCLC:869747983. OL:37413258M. QID:Q119841470.
• Kevin R. Fall; W. Richard Stevens (2012). TCP/IP illustrated: Volume 1, The protocols (PDF) (بالإنجليزية) (2nd ed.). Boston: Addison-Wesley. ISBN:978-0-321-33631-6. OCLC:774930889. OL:25162208M. QID:Q115922106.
• Wendell Odom (2013). Cisco CCENT/CCNA ICND1 100-101 Official Cert Guide (بالإنجليزية). Indianapolis: Cisco Press. ISBN:978-1-58714-485-1. OCLC:863128088. OL:26185412M. QID:Q115919723.

العربية:

• ميشيل بكني (2022). ساندرا هانبو (المحرر). بروتوكول الإِنترنت: الإِصداران الرابع والسادس. أورتيز: مطبعة إيسن. DOI:10.6084/M9.FIGSHARE.19326086. ISBN:978-2-9576887-1-5. OCLC:1425075897. OL:36773625W. QID:Q111284802.

وثائق طلب التعليقات (مرتبة تصاعديًّا حسب رقم الوثيقة)

• J. Postel (1981-09), Internet Protocol: DARPA Internet Program, Protocol Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0791, RFC:791, QID:Q47467078 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S.E. Deering (1989-08), Host extensions for IP multicasting (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1112, RFC:1112, QID:Q47460092 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• T. Li (1992-06), Supernetting: an Address Assignment and Aggregation Strategy (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1338, RFC:1338, QID:Q47468405 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• Y. Rekhter; T. Li (1993-09), An Architecture for IP Address Allocation with CIDR (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1518, RFC:1518, QID:Q47314090 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• T. Li (1993-09), Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1519, RFC:1519, QID:Q47199620 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Bradner; A. Mankin (1993-12), IP: Next Generation (IPng) White Paper Solicitation (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1550, RFC:1550, QID:Q47470454 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• K. Egevang; P. Francis (1994-05), The IP Network Address Translator (NAT) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1631, RFC:1631, QID:Q47164409 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Bradner; A. Mankin (1995-01), The Recommendation for the IP Next Generation Protocol (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1752, RFC:1752, QID:Q47457995 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Deering; R. Hinden (1995-12), Internet Protocol, Version 6 (IPv6) Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1883, RFC:1883, QID:Q47472593 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Deering; R. Hinden (1995-12), IP Version 6 Addressing Architecture (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1884, RFC:1884, QID:Q47461872 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Deering (1995-12), Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1885, RFC:1885, QID:Q47468348 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• W. Simpson; T. Narten; E. Nordmark (1996-08), Neighbor Discovery for IP Version 6 (IPv6) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1970, RFC:1970, QID:Q47474638 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• T. Narten (1996-08), IPv6 Stateless Address Autoconfiguration (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1971, RFC:1971, QID:Q47471157 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• J. Postel (1996-11), Internet Registry IP Allocation Guidelines (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2050, RFC:2050, QID:Q47483471 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Deering; R. Hinden (1998-12), Internet Protocol, Version 6 (IPv6) Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2460, RFC:2460, QID:Q47467387 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• W. Simpson; T. Narten; E. Nordmark (1998-12), Neighbor Discovery for IP Version 6 (IPv6) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2461, RFC:2461, QID:Q47466167 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• T. Narten (1998-12), IPv6 Stateless Address Autoconfiguration (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2462, RFC:2462, QID:Q47469328 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Deering (1998-12), Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2463, RFC:2463, QID:Q47455723 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• F. Baker; D. Black (1998-12), Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2474, RFC:2474, QID:Q47470529 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Deering; R. Hinden; D. Borman (1999-08), IPv6 Jumbograms (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2675, RFC:2675, QID:Q47468506 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Deering; B. Haberman; W. Fenner (1999-10), Multicast Listener Discovery (MLD) for IPv6 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2710, RFC:2710, QID:Q47464272 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Deering; R. Hinden (2000-09), Initial IPv6 Sub-TLA ID Assignments (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2928, RFC:2928, QID:Q47466415 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• A. Conta (2001-06), Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3122, RFC:3122, QID:Q47477469 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• B. Carpenter (2001-02), Connection of IPv6 Domains via IPv4 Clouds (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3056, RFC:3056, QID:Q47477513 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• D. Thaler; B. Haberman (2002-08), Unicast-Prefix-based IPv6 Multicast Addresses (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3306, RFC:3306, QID:Q47472870 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• R. Vida; L. Costa (2004-06), Multicast Listener Discovery Version 2 (MLDv2) for IPv6 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3810, RFC:3810, QID:Q47467351 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• G. Huston (2004-07), IPv6 Address Prefix Reserved for Documentation (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3849, RFC:3849, QID:Q47468196 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• C. Huitema; B. Carpenter (2004-09), Deprecating Site Local Addresses (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3879, RFC:3879, QID:Q47322494 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• B. Haberman (2004-11), Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3956, RFC:3956, QID:Q47476136 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• J. Arkko (2005-03), SEcure Neighbor Discovery (SEND) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3971, RFC:3971, QID:Q47312783 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• M-K. Shin; Y-G. Hong; J. Hagino; P. Savola; E. M. Castro (2005-03), Application Aspects of IPv6 Transition (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4038, RFC:4038, QID:Q47481039 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Deering; R. Hinden (2006-02), IP Version 6 Addressing Architecture (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4291, RFC:4291, QID:Q47470884 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• R. Hinden; B. Haberman (2005-10), Unique Local IPv6 Unicast Addresses (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4193, RFC:4193, QID:Q47470421 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Kent (2005-12), IP Authentication Header (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4302, RFC:4302, QID:Q47469832 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Kent (2005-12), IP Encapsulating Security Payload (ESP) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4303, RFC:4303, QID:Q47468417 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• C. Huitema (2006-02), Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4380, RFC:4380, QID:Q47455351 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• B. Haberman (2006-08), Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4604, RFC:4604, QID:Q47461464 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• T. Li (2006-08), Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4632, RFC:4632, QID:Q47485207 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• P. Nikander; J. Laganier; F. Dupont (2007-04), An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4843, RFC:4843, QID:Q47468599 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• W. Simpson; T. Narten; E. Nordmark (2007-09), Neighbor Discovery for IP version 6 (IPv6) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4861, RFC:4861, QID:Q47465975 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• T. Narten (2007-09), IPv6 Stateless Address Autoconfiguration (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4862, RFC:4862, QID:Q47483181 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• J. Abley; P. Savola; G. Neville-Neil (2007-12), Deprecation of Type 0 Routing Headers in IPv6 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC5095, RFC:5095, QID:Q47322771 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• C. Popoviciu; A. Hamza; G. Van de Velde; D. Dugatkin (2008-05), IPv6 Benchmarking Methodology for Network Interconnect Devices (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC5180, RFC:5180, QID:Q47320263 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Krishnan (2009-12), Handling of Overlapping IPv6 Fragments (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC5722, RFC:5722, QID:Q47483158 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Kawamura; M. Kawashima (2010-08), A Recommendation for IPv6 Address Text Representation (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC5952, RFC:5952, QID:Q47462322 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• C. Perkins; J. Arkko (2011-07), Mobility Support in IPv6 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6275, RFC:6275, QID:Q47472726 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• B. Carpenter; S. Jiang (2011-11), IPv6 Flow Label Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6437, RFC:6437, QID:Q47461703 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• M. Boucadair; C. Huitema (2010-10), IPv6 Addressing of IPv4/IPv6 Translators (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6052, RFC:6052, QID:Q47471511 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• D. Freedman; N. Hilliard (2012-08), A Discard Prefix for IPv6 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6666, RFC:6666, QID:Q47471990 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• R. Bonica; B. Haberman (2013-04), Special-Purpose IP Address Registries (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6890, RFC:6890, QID:Q47462480 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• F. Gont (2013-05), Processing of IPv6 "Atomic" Fragments (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6946, RFC:6946, QID:Q47484143 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• R. Housley; G. Huston (2013-08), The Internet Numbers Registry System (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7020, RFC:7020, QID:Q47463802 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• F. Gont (2014-04), A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7217, RFC:7217, QID:Q47470898 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• J. Laganier; F. Dupont (2014-09), An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7343, RFC:7343, QID:Q47483506 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• R. Droms (2014-08), IPv6 Multicast Address Scopes (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7346, RFC:7346, QID:Q47301999 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• M. Boucadair; S. Venaas (2014-09), Updates to the IPv6 Multicast Addressing Architecture (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7371, RFC:7371, QID:Q47207470 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• R. Moskowitz; T. Heer; P. Jokela; T. Henderson (2015-04), Host Identity Protocol Version 2 (HIPv2) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7401, RFC:7401, QID:Q47455650 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• G. Bumgardner (2015-02), Automatic Multicast Tunneling (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7450, RFC:7450, QID:Q47466972 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• W. Kumari (2015-05), AS112 Redirection Using DNAME (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7535, RFC:7535, QID:Q47246249 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Kiesel; R. Penno (2016-01), Port Control Protocol (PCP) Anycast Addresses (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7723, RFC:7723, QID:Q47471706 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• F. Gont (2016-02), Security Implications of Predictable Fragment Identification Values (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7739, RFC:7739, QID:Q47476057 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• T. Reddy; P. Patil; D. Wing (2017-04), Traversal Using Relays around NAT (TURN) Server Auto Discovery (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC8155, RFC:8155, QID:Q47201872 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• S. Deering; R. Hinden (2017-07), Internet Protocol, Version 6 (IPv6) Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC8200, RFC:8200, QID:Q47476951 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)
• J. Mogul; S. Deering; R. Hinden (2017-07), Path MTU Discovery for IP version 6 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC8201, RFC:8201, QID:Q47456249 {{استشهاد}}: تحقق من التاريخ في: |publication-date= (help)

معايير تقانة (مرتبة تصاعديًّا حسب تاريخ النشر)

• 802.3-2008 - IEEE Standard for Information technology--Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications (بالإنجليزية). Institute of Electrical and Electronics Engineers. 2008. DOI:10.1109/IEEESTD.2008.4726971. ISBN:978-0-7381-5796-2. OCLC:874809175. QID:Q117948716.
• Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID) (PDF) (بالإنجليزية), Institute of Electrical and Electronics Engineers, 2017, QID:Q118316116

وصلات خارجية

• الإصدار السادس من بروتوكول الإنترنت للجميع كتيب من إعداد مجتمع الإنترنت.
• التقطيع في الإصدار السادس من بروتوكول الإنترنت، مقالة من جيف هوستِن.
• اكتشاف الجيران والتهيئة الذاتية الآلية في الإصدار السادس من بروتوكول الإنترنت، مقالة من توماس نارتِن.
• أمن الإصدار السادس من بروتوكول الإنترنت، أسئلة متكررة، مقالة من مجتمع الإنترنت.
• أمن الشبكات، أمن الإصدار السادس لمهندسي الإصدار الرابع، مقالة من مجتمع الإنترنت.