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

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

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

الإصدار الرابع من بروتوكول الإنترنت (بالإنجليزية: Internet Protocol version 4 اختصاراً IPv4)‏ هو بروتوكول تشبيك يعمل في طبقة الشبكة حسبَ نموذج الربط البيني للأنظمة المفتوحة. طوّر هذا البروتوكول في عام 1981م ضمن عمل وكالة مشاريع البحوث المتطورة الدفاعية، وكان أحد الركائز التي قامت شبكة الإنترنت على أساسها.

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

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

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

نبذة تاريخية

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

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

نشر فينت سيرف وبوب خان في عام 1974م ورقة بحثية بعنوان «بروتوكول للاتصال البيني في شبكة الرزم»⁽¹⁾، وصفا فيها بروتوكول نقل يعمل بين المضيفين في شبكة تبديل رزم، يقدم البروتوكول عدداً من الوظائف لرزم بيانات متنوعة الأطوال تشمل: التحكم بالتدفق وعنونة العمليات والتحقق من الخطأ بين الطرفيات وغير ذلك وكان برنامج التحكم بالنقل TCP هو حجر الأساس في هذه الوظائف. ثم نُشرت وثيقة طلب التعليقات التي تحدد مواصفات البرنامج تحت الاسم الرمزي RFC 675. لاحقاً، قُسمت الوظائف التي يُقدّمها البرنامج على بروتوكولين هما بروتوكول الإنترنت وبروتوكول التحكّم بالنقل ⁽²⁾. يعمل البروتوكولان في طبقتين متتابعتين من طبقات نموذج الربط البيني للأنظمة المفتوحة، هما طبقة النقل: وتُقدّم خدمات بين طرفيّة (بالإنجليزية: End-to-end)‏ للتطبيقات التي تعمل في المُضيفين، وطبقة الشبكة: وتدعم الوظائف الخاصّة برزمة البيانات.

في ما يخص بروتوكول الإنترنت، فقد جرى العمل على تطويره ضمن مشروع ممول من قبل وكالة مشاريع البحوث المتطورة الدفاعية المعروفة اختصاراً بالاسم:داربا، فنُشرت إصدرات تجريبية عديدة بين العامين 1977 و1979م. وحملت هذه الإصدارات أرقاماً هي 0 و1 و4،⁽³⁾، وفي ما يلي مجموعة من وثائق المُلاحظات على تجارب الإنترنت التي تصفّ إصدارات بروتوكول الإنترنت السابقة وصولاً للمعيار الرسمي للإصدار الرابع:⁽⁴⁾

• الوثيقة رقم 2: وهي مُؤرّخة في شهر أغسطس للعام 1977م، وجاءت بعنوان: «تعليقات على بروتوكول الإنترنت وبروتوكول التحكّم بالنقل». وتُشدد على الحاجة للفصل بين وظائف بروتوكول الإنترنت ووظائف بروتوكول التحكّم بالنقل، واقترحت الوثيقة أول تصوّر لبروتوكول الإنترنت، واستخدم الرقم 0 للإشارة إلى رقم الإصدار في الترويسة المُقترحة.
• الوثيقة رقم 26: وهي مُؤرّخة في شهر فبراير للعام 1978م، وجاءت بعنوان: «اقتراح لبنية جديدة لترويسة بروتوكول الإنترنت»، وتصف الإصدار الأول من البروتوكول (IPv1).
• الوثيقة رقم 28: وهي مُؤرّخة في شهر فبراير للعام 1978م، وجاءت بعنوان: «مسودّة توصيف الإصدار الثاني لبروتوكول الإنترنت»، وتصف الإصدار الثاني من البروتوكول، أي IPv2.
• الوثيقة رقم 41: وهي مُؤرّخة في شهر يونيو للعام 1978م، وجاءت بعنوان: «محددات الإصدار الرابع من بروتوكول التشبيك».⁽⁵⁾ وهي أوّل وثيقة وصفت الإصدار الرابع من البروتوكول، ولكنّ بنية الترويسة كانت مختلفة عن الشكل النهائي الذي اُعتمد لاحقاً.
• الوثيقة رقم 44: وهي مُؤرّخة في شهر يونيو للعام 1978م، وجاءت بعنوان: «أحدث بُنى الترويسات». وهي تصف التعديلات التي أدخلت على ترويسة البروتوكول الواردة في الوثيقة رقم 41.
• الوثيقة رقم 54: وهي مُؤرّخة في شهر سبتمبر للعام 1978م، وهي بعنوان: «مُحددات الإصدار الرابع من بروتوكول التشبيك». وهي أوّل توصيف للإصدار الرابع من البروتوكول يستخدم الترويسة المُعتمدة في الشكل النهائي للإصدار الرابع.

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

لاحقاً، في شهر يناير من العام 1980م، تحوّلت الوثيقة رقم 128 إلى أوّل وثيقة طلبات تعليقات مُخصصة للبروتوكول وحملت الاسم الرمزي RFC 760، وجاءت تحت عنوان «معيار بروتوكول الإنترنت لوزارة الدفاع» ⁽⁶⁾. وفي شهر سبتمبر من العام التالي صدرت وثيقة طلب التعليقات RFC 791 تحت عنوان: «بروتوكول الإنترنت»، وحلَّت محل الوثيقة السابقة، وهي ما تزال الوثيقة المعياريّة للإصدار الرابع من بروتوكول الإنترنت. اعتمد البروتوكول خلال العامين التاليين قبل أن يصبح بروتوكول التشبيك الرئيس في الشبكة بدءاً من 1 يناير 1983م.

طُوّر الإصدار الخامس IPv5 تحت مُسمى بروتوكول التدفق في شبكة الإنترنت،⁽⁷⁾ ولكنّه لم يتجاوز المرحلة التجريبيّة. بالإضافة لذلك في الفترة بين عامي 1988 و1993م، طُوِّر إصدار جديد من بروتوكول الإنترنت لمعالجة الإشكالات التي صادفها الإصدار الرابع وبالتحديد مشكلة استنفاد عناوين الإصدار الرابع من بروتوكول الإنترنت، وسُميّ بالإصدار السابع من بروتوكول الإنترنت IPv7 اعتباطيّاً، لكن لم تستكمل عملية التطوير لاحقاً. RFC 1475, p. 7.

أمّا الإصدار السادس من بروتوكول الإنترنت IPv6 فهو وريث الإصدار الرابع، وطوّر بالأساس لحل مشكلة استنفاد عناوين الإصدار الرابع من بروتوكول الإنترنت، ففي حين يستخدم الإصدار الرابع عناوين بطول من 32 بت، وهو ما يخلق 4.3x10⁹ عنوان متاح في فضاء العناوين، فإنّ الإصدار السادس يستخدم عناوين بطول 128 بت، ما يسمح بوجود 3.4x10³⁸ عنوان متاح في فضاء عناوينه. وصف الإصدار السادس أوّلاً في وثيقة طلب التعليقات RFC 1883 ، ثُمّ جرى إضافة بعض التعديلات وأُصدر معيار جديد للبروتوكول في العام 1998م تحت الاسم الرمزي RFC 2460. صدرت الوثيقة RFC 8200 أخيراً في عام 2017م وهي تحتوي التعديلات المُضافة على معيار البروتوكول.

في 1 أبريل 1994م، نشرت مجموعة مُهندسي الإنترنت وثيقة طلب تعليقات تُفيد بتطوير الإصدار التاسع من بروتوكول الإنترنت، أي IPv9، ولكن الخبر برمّته كان كذبة أبريل.

مبدأ العمل

طبقة الشبكة في نموذج الربط البيني للأنظمة المفتوحة، حيث يعمل الإصدار الرابع من بروتوكول الإنترنت.

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

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

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

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

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

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

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

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

تتكون رزمة الإصدار الرابع من بروتوكول الإنترنت من ترويسة وحمُولة. يتراوح حجم الترويسة بين 20 و60 بايتاً، أمّا حجم الرزمة ككل، أي الترويسة والحمولة معاً، فمن الممكن أن يصل نظريّاً حتى 65535 بايت.

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

الحقول الإلزاميّة

• حقل الإصدار: بطول 4 بت، ويحتوي دائماً على القيمة 4 في كل رزم الإصدار الرابع من بروتوكول الإنترنت.
• حقل طول الترويسة: بطول 4 بت، ويُحدد موقع نهاية الترويسة وبداية الحمولة، وهو يحتوي عدداً يُمثل عدد الكلمات بطول 32 بت، أو 4 بايت، المُوجودة في لترويسة، وبما أن طول الترويسة بلا خيارات هو 20 بايت، فإنّ أصغر قيمة صحيحة مُمكنة لهذا الحقل هي 5.
• حقل نوع الخدمة: بطول 8 بت، ويحتوي على تراميز خاصّة تُحدد جودة الخدمة QoS المطلوبة لنقل الرزمة، وتحديداً من خلال ضبط مُحددات: أحقية المُضيف والتأخير والإنتاجية والوثوقية. حُددت قيم المُحددات المستعملة لضبط هذا الحقل أولاً في معيار البروتوكول، ثُمّ في وثيقة طلب التعليقات RFC 1349 ، ثُمّ في الوثيقة RFC 2474.
• حقل الطول الإجمالي: بطول 16 بت، يُحدد حجم رزمة البيانات مُقدراً بالبايت. إنّ أكبر قيمة يمكن ترميزها في هذا الحقل هي 65535. نظريّاً، تُمثّل هذه القيمة الحجم الأعظم المُمكن لرزمة البيانات الإصدار الرابع من بروتوكول الإنترنت.
• حقل المُعرّف: بطول 16 بت، وهو يُميّز الرزمة وجميع القطع التي تنتج عن عملية تقطيعها، حيث يُساعد هذا الحقل بروتوكول الإنترنت العامل في طرف الوجهة على تمييز القطع الناتجة عن تقطيع رزم مُختلفة عن بعضها البعض ثمّ إعادة تجميعها لإنتاج الرزمة الأصلية مجدداً، وتصف الوثيقة RFC 6864 كيفية استعمال هذا الحقل.
• حقل الأعلام: بطول 3 بتات، ويحتوي علمين هما علم عدم التقطيع، ويُستخدم لمنع تقطيع الرزمة تحت أي ظرفٍ، وعلم المزيد من القطع، ويُستخدم لتحديد القطعة الأخيرة في الترتيب من مجموعة القطع التي نتجت عن تقطيع رزمة ما. لا تُستخدم هذه الأعلام إلا إذا قُطِّعت الرزمة⁽¹⁰⁾.
• حقل إزاحة القطعة: بطول 13 بت، يُستخدم هذا الحقل إذا فقط كانت الرزمة هي قطعة ناتجة عن تقطيع رزمة أكبر، وتُمثّل هذه القيمة إزاحة القطعة عن أول موقع في الرزمة الأصليّة، ويساعد هذا الحقل في إعادة تجميع القطع تجميعاً سليماً لإنتاج الرزمة الأصيلة في طرف الوجهة، خاصّةً إذا وصلت القطع بترتيبٍ مُغايّر لترتيب الإرسال.أمّا إذا لم تكن الرزمة قطعة من رزمة أكبر فإن هذا الحقل لا يُستعمل ويأخذ القيمة الصفريّة. تكون قيمة الإزاحة المُخزنة في هذا الحقل مقسومة على ثمانيّة، أي إذا احتوى الحقل القيمة 1 فإن قيمة الإزاحة الحقيقية هي 8 بايت، وأكبر قيمة ممكن للإزاحة في هذا الحقل هي: 2¹³=8192، وتقابل 65536 بايت.
• حقل زمن حياة الرزمة: بطول 8 بت، وهو يحتوي عدد القفزات الأعظم الذي يُسمح للرزمة بالقيام بها. تقوم كل عقدة تُعالج الرزمة، كالموجّهات، بإنقاص قيمة حقل زمن الحياة بمقدار 1، وعندما تصل قيمة الحقل إلى الصفر يلزم التخلص من الرزمة. إنّ أقصى قيمة يُمكن أن يحتويها الحقل هي 255، وهي تُمثّل أكبر عدد قفزات مُمكن لمسار رزمة بيانات تدعم الإصدار الرابع من بروتوكول الإنترنت.
• حقل البروتوكول: بطول 8 بت، ويستعمل لأداء وظيفة التنضيد، ويضمّ ترميزاً يُستخدم لتحديد بروتوكول الطبقة التاليّة صُعوداً، تُحدد هيئة أرقام الإنترنت المُخصصَة قيم التراميز والمُستعملة والبروتوكولات المُقابلة له.
• حقل التحقق الجمعي: بطول 16 بت، ويحتوي ناتج خوارزميّة التحقق الجمعيّ التي تطبّق على حقول الترويسة فقط. تشرح مُحددات البروتوكول الخوارزميّة المُتبّعة لحساب قيمة هذا الحقل، ويجب الانتباه إلى ضرورة إعادة حساب قيمة هذا الحقل عند إجراء أي تغيير في محتوى الترويسة أثناء انتقالها عبر الشبكة، مثل حالات إنقاص قيمة زمن الحياة أو إجراء ترجمة عنوان الشبكة.
• حقل عنوان المصدر: بطول 32 بت، يحتوي عنوان بروتوكول الإنترنت للطرف الذي ولّد الرزمة، والذي يُسمّى مصدر الرزمة.
• حقل عنوان الوجهة: بطول 32 بت، يحتوي عنوان بروتوكول الإنترنت للوجهة النهائيّة للرزمة، والتي تُسمّى وجهة الرزمة.

الخيارات

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

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

ليس هناك طول ثابت للخيار، ولكن لجميع الخيارات بنيّة مشتركة، ولا يشذّ عن هذه البنية إلا خياران فقط هما خيار النهاية وخيار لا عمليّة. يتألّف كل خيار من ثلاث حقول هي حقل النوع وطوله 8 بت، وحقل الطول وطوله 8 بت أيضاً، وحقل القيمة وهو ذو طول متغيّر حسب الخيار، يتكوّن حقل النوع من ثلاث حقول فرعية هي:

• علم النسخ (بالإنجليزية: Copy flag، اختصاراً C)‏: وهو بت وحيد، يستخدم في حالة تقطيع رزمة البيانات إلى عدد من الرمز الأصغر حجماً، ويحدد فيما إذا كان الخيار سيُنسخ إلى كل الرزم (C=1) أو لا (C=0).
• صنف الخيار: ويتحدد ببتين، وإما أن يكون الخيار خيار تحكم (₁₀(0) = ₂(00)) أو خيار تنقيح وقياس (₁₀(2) = ₂(10)).
• الرقم: وهو قيمة عددية مميزة لكل خيار، وطوله 5 بتات.

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

جدول بأهم خيارات الإصدار الرابع من بروتوكول الإنترنت

الرقم	الصنف	علم النسخ	الاسم	البنية	الوصف	مرجع
0	0	0	نهاية قائمة الخيارات		يُحدد هذ الخيار نهاية قائمة الخيارات، لا نهاية كل خيار، لذلك فهو يوجد بعد كل الخيارات.
1	0	0	لا عملية		يستخدم هذا الخيار بين الخيارات، على سبيل المثال، لمحاذاة بداية الخيار التالي عند حدود 32 بت.
2	0	1	خيار الأمن		يُستخدم هذا الخيار في الأنظمة البينيّة أو الطرفيّة في الإنترنت من أجل: نقل البيانات بين مُضيفين هما المصدر والوجهة حسب نموذج الأمن المُعتمد في الشبكة. التحقق من كون الرزمة صالحة للنقل من المصدر وتوصيلها إلى الوجهة. التأكد من أن المسار الذي تسلكه الرزمة محمي إلى الدرجة التي تحددها سلطة الحماية.
3	0	1	خيار التوجيه غير المُقيِّد بمسار المَصدر		يسمح هذا الخيار لمصدر رزمة البيانات بتزويد البوابات بمعلومات لتوجيه الرزمة نحو وجهتها. هذا الخيار حُرّ لأنّ البوابات غير مُلزمة بالمعلومات الموجودة فيه، وبإمكانها توجيه الرزمة في أي مسار آخر تختاره.
4	2	0	خيار الوسمة الزمنية		يُستخدم هذا الخيار لتتبع الزمن المنقضي أثناء انتقال ومعالجة الرزمة عبر مسارها. يضيف كل مضيف عنوانه ووسمة زمنية عند معالجة الرزمة، ويمكن أن تضاف الوسمات الزمنية فقط دون عناوين. تكون الوسمات الزمنية عبارة عن أعداد بطول 32 بت، تُمثل الزمن المنقضي منذ منتصف الليلة السابقة حسب التوقيت العالمي ومُقدراً بالميلي ثانية، وبالإمكان أيضاً أن تكون تُمثّل الوسمات قيماً زمنية نسبية لزمن مرجعي آخر.
5	0	1	الخيار الأمن المُوسَّع		يسمح هذا الخيار بنقل معلومات أمنيّة إضافيّة تزيد على ما يسمح به خيار الأمن، وذلك من أجل الاستجابة لمتطلبات الجهات التي تدير خدمات الأمن.
6	0	1	خيار الأمن التجاري		كان الغرض من تطوير هذا الخيار هو تأمين توسيعة لخيار الأمن لبروتوكول الإنترنت من أجل دعم متطلبات الاستخدام التجاري للبروتوكول في أنظمة التشغيل المختلفة، ولكن العمل توقّف في مرحلة إعداد مسودة المعيار.
7	0	0	خيار المسار المُسجّل		يسمح هذا الخيار بتسجيل المسار الذي تسلكه الرزمة في ترويستها. عند استعماله، تقوم كل وحدة تُوجّه الرزمة بإضافة عنوان بروتوكول الإنترنت الخاص بالمنفذ الذي جرى توجيه الرزمة عبره إلى حقل بيانات المسار في هذا الخيار.
8	0	1	خيار مُعرّف التدفق		يُؤمن هذا الخيار طريقة لنقل مُعرّف التدفق المُستعمل في شبكة سات نت عبر شبكة لا تدعم مفهوم التدفق.(13)
9	0	1	خيار التوجيه المُقيِّد بمسار المصدر		يسمح هذا الخيار لمصدر رزمة البيانات بتزويد البوابات بمعلومات لتوجيه الرزمة نحو وجهتها. هذا الخيار مُقيّد بالمصدر لأنّ البوابات مُلزَمِة بالمعلومات الموجُودة بالخيار، ويجب أن توجّه الرزمة حسب تلك المعلومات.
11	0	0	خيار استشعار وحدة النقل العظمى		يستعمل هذا الخيار للتعرف على أصغر وحدة نقل عظمى في كل الشبكات التي مرّت فيها الرزمة عبر مسارها. يُقارن كل مُضيف يستقبل الرزمة قيمة حقل وحدة النقل العظمى في هذا الخيار مع قيمة وحدة النقل العظمى في منفذه الذي ستُوجَّه الرزمة عبره، إذا كانت قيمة وحدة المضيف أصغر قيمة، يضعها المضيف في الحقل بدلاً من القيمة القديمة، وإلا فإنه يبقي على القيمة القديمة.
12	0	0	خيار الرد على استشعار وحدة النقل العظمى		يستعمل هذا الخيار للرد على خيار استشعار وحدة النقل العظمى، وهو يحتوي القيمة الصغرى التي عُثر عليها، ويُضاف إلى رزمة موجّهة نحو المُضيف المصدر الذي ولّد خيار الاستشعار.
14	0	1	خيار التحكم بالوصول التجريبي	- (11)	طُوّر هذا الخيار في عام 1989م، وهو جزء من مجموعة إجراءات أعدَّت للسماح للمنظمات الدولية التي تُشغل شبكات بيانات غير مُتجانسة بنيةً بإدارة تدفق الرزم نحو شبكاتها.
18	2	0	خيار تتبع المسار		طوّر هذا الخيار ليساعد في عمل أداة تتبع المسار. يحتوي الخيار على حقول لتخزين عدد القفزات على مسار الرزمة في الاتجاهين الأمامي والعكسي للمسار، وعلى عنوان بروتوكول الإنترنت لمصدر الرزمة.
20	0	1	خيار إنذار الموجِّه		يُستعمل هذا الخيار لتنبيه المُوجّه ليفحص محتويات الرزمة بدقة.
21	0	1	التوصيل متعدد الوِجهات المدار بواسطة المرسل		يُزوّد هذا الخيار مرسل رزم بيانات بآلية توصيل مباشرة مُتعددة الوجهات تُسمّى نمط البث العام المُوجّه الانتقائي (بالإنجليزية: Selective Directed Broadcast Mode اختصاراً SDBM)‏.
24	0	1	خيار رزم التيار الصاعد في البث المجموعاتي		يُستعمل هذا الخيار من أجل المساعدة في توجيه رزم التيار الصاعد في شجرة البث المجموعاتي. يحتوي هذا الخيار على حقل يستعمل لتخزين عنوان موجه التيار الصاعد.
25	0	1	خيار البداية السريعة	- (12)	يستعمل هذا الخيار من أجل تمييز معدل النقل المتاح لاستعماله في عملية البداية السريعة، عوضاً عن الاعتماد على عملية البداية البطيئة في بروتوكول التحكم بالنقل.
30	2-0	1-0	خيارات تجريبية	بنية الخيار غير مُوضّحة في المعيار.	في هذا الخيار، تستعمل قيمة الرقم 30 مع كل الأزواج الممكنة للصنف وعلم النسخ، ونتيجة ذلك توجد أربعة احتمالات لقيمة حقل النمط. ويستعمل هذا الخيار لأغراض تجريبيّة.

الوظائف

العنونة

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

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

تعاريف

عنوان بروتوكول الإنترنت

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

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

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

يكتب عنوان بروتوكول الإنترنت في النظام العشري المنقط بالشكل #.#.#.# وفيه يُمثّل الرمز # قيمة عددية بنظام العد العشري، ولأن كل خانة تضم أعداد موجبة مُمثلة بثمانية بتات فقط، فإنّ القيمة العشريّة في كل خانة يمكن أن تتراوح بين القيمتين 0 و255 فقط. إنّ 10.0.0.1 و150.255.12.9 و240.0.0.9 هي أمثلة على عناوين إنترنت مكتوبة بنظام العد العشري المُنقّط. كما يمُكن أن يُمثل العنوان بنظام العد الثنائي، من خلال استبدال القيمة العشرية لكل خانة بالمقابل الثنائي، ولكن يجب اعتماد تمثيل واحد فقط عند الكتابة ولا يجوز الخلط بين الشكلين معاً. فمثلاً التمثيلان التاليان يعبران عن نفس عنوان بروتوكول الإنترنت مكتوباً بالتمثيل الثنائي ثُمّ بالتمثيل العشري المُنقط:

00001010.00000000.00000000.00000001

10.0.0.1

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

1. البتات المحجوزة:⁽¹⁴⁾ وهي عدد من البتات التي تستعمل لتحديد وظيفة فضاء العنونة الذي ينتمي إليه العنوان، تبدأ البتات المحجوزة من البت الأكثر أهمية، وقد تكون بتاً واحدً أو أكثر حتى 4 بتات، ويتحدد عددها K حسب نمط العنونة المستعمل.
2. مُعرِّف الشبكة أو مُعرِّف الفضاء (بالإنجليزية: Network identifier)‏، وهو القسم الذي يُميّز الفضاء الذي ينتمي إليه العنوان عن سائر الأفضيّة، ويكون مُشتركاً بين جميع العناوين فيه، ويبدأ حيث انتهى قسم البتات المحجوزة، ويختلف طوله n حسب عدد الأفضية الجزئية الناتجة عن تجزئة الفضاء الكلي A، ويرتبط الاثنان بالعلاقة حسب العلاقة: A = 2ⁿ. فإذا كان طول مُعرّف الشبكة 3 بتات، فإن فضاء العناوين الكلي سيُجزأ إلى 2³ = 8 أفضية جزئية.
3. مُعرّف المُضيف (بالإنجليزية: Host identifier)‏: وهو القسم الذي يُميز المُضيف الذي يستضيف العنوان، وتكون قيمته فريدة من أجل كل عنوان في الفضاء، ويبدأ مُعرف المُضيف حيث انتهى مُعرّف الشبكة ويمتد حتى نهاية العنوان. وأمّا طول قسم المُضيف فيُحدد عدد العناوين في الفضاء الجزئي B، حسب العلاقة B = 2^m، وفيها m هو عدد بتات مُعرّف المُضيف، فإذا كان طول قسم المُضيف 10 بتات، فإن كل فضاءعناوين جزئي سيحتوي على 2¹⁰ = 1024 عنواناً ⁽¹⁵⁾.

يكون مجموع أطوال الأقسام مساوياً لطول عنوان الإصدار الرابع من بروتوكول الإنترنت، أي k+m+n = 32.

فضاء العناوين

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

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

فضاء عناوين بروتوكول الإنترنت (بالإنجليزية: IPv4 address space)‏ هو مجموعة كل عناوين بروتوكول الإنترنت، وهي تضمّ 2³² عنواناً، أي قرابة 4.3 مليار عنوان تقريباً. يُقسّم فضاء العنونة حسب الغرض من الاستخدام إلى ثلاث أفضية جزئيّة يمكن تميزها حسب قيمة البتات المحجوزة، وهي:

1. فضاء عناوين البث فريد الوجهة، ويشغل 7/8 من إجمالي حجم الفضاء، ويكون عدد البتات المحجوزة فيها بت واحد وقيمته ₂(0) أو بتين وقيمتهما ₂(10) أو ثلاث بتات وقيمتها ₂(110).
2. فضاء عناوين البث المجموعاتي، ويشغل 1/16 من إجمالي حجم الفضاء، وعدد البتات المحجوزة فيه 4 بتات وقيمتها ₂(1110).
3. فضاء عناوين محجوز، ويشغل 1/16 من حجم الفضاء أيضاً. وعدد البتات المحجوزة فيه 4 بتات وقيمتها ₂(1111).

يُقسم فضاء عناوين البث فريد الوجهة إلى عدد من الأفضية الجزئية لتسهيل استعماله وإدارته، والفضاء الجزئي هو مجموعة جزئيّة من الفضاء الكلي، ولكل فضاء جزئي حجم محدد يُمثل عدد عناوين بروتوكول الإنترنت التي يحتويها، ويمكن للفضاء الجزئي أن يضمّ أفضية جزئيّة أخرى. بسبب استعمال نظام العد الثنائي في عنونة الإصدار الرابع من بروتوكول الإنترنت، فإنّ حجم الفضاء يجب أن يكون دائماً من مضاعفات العدد 2، أي من المجموعة {2، 4، 8، 16... 2³²}.

هناك طريقتان لتجزئة الأفضية وعنونتها في الإصدار الرابع من بروتوكول الإنترنت، فإمّا أن تكون العنونة قياسيّة أو غير قياسيّة. في العنونة الصنفية، تكون أطوال قسمي الشبكة والمُضيف مُحددة تحديداً قياسياً، وبالتالي، تكون الأفضية الجزئية الناتجة معروفة الحجم، وتصنف حسب حجمها إلى أصناف، هي من الأكبر إلى الأصغر حجماً: الصنف A والصنف B والصنف C، ولذلك تُسمى هذه العنونة أيضاً بالعنونة الصنفيّة (بالإنجليزية: Classful addressing)‏. أمّا في العنونة غير الصنفية فلا يوجد أصناف، وتكون أحجام الأفضية غير ثابتة، ولذلك فإن هذه العنونة تُسمى أيضاً بالعنونة اللاصنفيّة (بالإنجليزية: Classless addressing)‏.

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

قناع الشبكة

القيم الثنائية والعشرية المستعملة في كتابة أقنعة الشبكة

القيمة الثنائية	القيمة العشريّة	عدد الوحدان
0000 0000	0	0
0000 1000	128	1
0000 1100	192	2
0000 1110	224	3
0000 1111	240	4
1000 1111	248	5
1100 1111	252	6
1110 1111	254	7
1111 1111	255	8

قناع الشبكة (بالإنجليزية: Network Mask)‏ هو عدد طوله 32 بت، يُكتب وفقاً لنفس قواعد كتابة عنوان الإصدار الرابع من بروتوكول الإنترنت وله نفس البنية رباعية الخانات. يتميّز القناع بنمط فريد من تكرار الأصفار والوحدان فيه، فهو يضمّ تتابع وحيد غير منقطع من الوحدان يليه تتابع وحيد غير منقطع من الأصفار.

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

مثلاً إذا كان مجموع طولي البتات المحجوزة ومُعرّف الشبكة في فضاء عناوين ما هو 12 بتاً، فإن القناع الموافق للعنوان يكتب بالتمثيل الثنائي بالشكل:

0000 0000. 0000 0000. 0000 1111. 1111 1111

وهذا يقابل القناع 255.240.0.0، أو اختصاراً 12/. والتمثيل الأول هو التمثيل العشري المُنقط، ويمكن الحصول عليه باستبدال القيمة الثنائية لكل خانة بمقابلها العشري. أمّا التمثيل الثاني فهو تمثيل البادئة (بالإنجليزية: Prefix notation)‏، ويمكن الحصول عليه من خلال إحصاء عدد الوحدان المتتالية في القناع، وإضافتها إلى جانب الشريطة المائلة /. تستعمل كلتا الطريقتان للتعبير عن قناع الشبكة، ويضاف القناع دائماً إلى يسار العنوان. فمثلاً: 10.0.0.0/12 و255.240.0.0 10.0.0.0 هما تعبيران متطابقان، ويعنيان أن البتات الإثني عشر الأكثر أهمية في العنوان 10.0.0.0 تشكل قسمي البتات المحجوزة ومُعرّف الشبكة. بعبارة أخرى، كل عناوين بروتوكول الإنترنت التي تبدأ من البت الأكثر أهمية بتتابع البتات: 0000 1010 0000 هي أعضاء في هذا الفضاء الجزئي.

إنّ القيم العشرية المُستعملة في كتابة الخانات في أقنعة الشبكة في الإصدار الرابع من بروتوكول الإنترنت محدودة وعددها 9 فقط، والسبب في ذلك هو شرط الوحدان المتتالية غير المنقطعة، وهذه القيم هي {0، 128، 192، 224، 240، 248، 252، 254، 255}.

عنوان الشبكة

مثال عن كيفيّة حساب عنوان الشبكة للعنوان 200.100.10.1 المُرفَق بالقناع 255.240.0.0 باستعمال عملية العطف المنطقي

عنوان العمود	الخانة الرابعة	الخانة الثالثة	الخانة الثانية	الخانة الأولى
العنوان بنظام العد العشري	1	10	100	200
القناع بنظام العد العشري	0	0	240	255
العنوان بنظام العد الثنائي	0001 0000	1010 0000	0100 0110	1000 1100
القناع بنظام العد الثنائي	0000 0000	0000 0000	0000 1111	1111 1111
ناتج عملية العطف المنطقي بنظام العد الثنائي	0000 0000	0000 0000	0000 0110	1000 1100
ناتج عملية العطف المنطقي بنظام العد العشري	0	0	96	200

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

يمكن حساب عنوان الشبكة رياضياً من انطلاقاً من قناع الشبكة وأحد عناوينها حسب الخوارزمية التاليّة:

1. كتابة العنوان والقناع بالتمثيل الثنائي.
2. إجراء عملية العطف المنطقي بين العنوان والقناع، والنتيجة هي عنوان الشبكة بالتمثيل الثنائي.
3. تمثيل قيم الخانات بنظام العد العشري، والنتيجة هي عنوان الشبكة مكتوباً بالنظام العشري المُنقط.

عنوان البث العام

مثال عن كيفيّة حساب عنوان البث العام للشبكة 200.96.0.0 المُرفَقة بالقناع 255.240.0.0 باستعمال عملية العطف المنطقي

عنوان العمود	الخانة الرابعة	الخانة الثالثة	الخانة الثانية	الخانة الأولى
العنوان بالتمثيل العشري المُنقط	0	0	96	200
القناع بالتمثيل العشري المُنقط	0	0	240	255
العنوان بالتمثيل الثنائي	0000 0000	0000 0000	0000 0110	1000 1100
القناع بالتمثيل الثنائي	0000 0000	0000 0000	0000 1111	1111 1111
تحديد قسم المضيف في العنوان وضعت إشارة (x) في مقابل كل بت	xxxx xxxx	xxxx xxxx	0110xxxx	1000 1100
ضبط بتات قسم المضيف إلى قيم واحدية (عنوان البث العام بالتمثيل الثنائي)	1111 1111	1111 1111	1111 0110	1000 1100
عنوان البث العام (بالتمثيل العشري المُنقط)	255	255	111	200

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

لحساب عنوان البث العام في فضاء ما، انطلاقاً من معرفة قناع الشبكة وأحد العناوين فيه، تتبع الخوارزمية التالية:

1. كتابة العنوان وقناع الشبكة إلى بالتمثيل الثنائي.
2. تحديد طول مُعرّف المضيف في العنوان من خلال مقارنته مع القناع، وبتات مُعرّف المضيف تقابل بتات القناع الصفريّة.
3. ضبط قيمة بتات مُعرّف المُضيف إلى قيم واحدية، والنتيجة هي عنوان البثّ العام مكتوباً بنظام العدّ الثنائي.
4. تمثيل قيم خانات العنوان بنظام العدّ العشري، وكتابة عنوان البث العام بالتمثيل العشري المُنقط.

فضاء البث فريد الوجهة

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

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

1. عنونة قياسية وتُسمّى أيضاً عنونة فئوية أو صنفيّة.
2. عنونة غير قياسية وتُسمى أيضاً عنونة لا فئوية أو لا صنفيّة.

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

الصنفية

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

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

1. الصنف A: يكون عدد البتات المحجوزة بت واحد فقط، وقيمته هي ₂(0) دائماً، ونتيجة لذلك تكون قيمة الخانة الأولى فيه محصورة بين 0 و127. طول قسم الشبكة فيه هو 7 بتات وطول قسم المُضيف هو 24 بتاً، لذلك فهو أكبر الأصناف حجماً (2²⁴ عنواناً في كل صنف) وأقلها عدداً 2⁷ صنفاً.
2. الصنف B: ويكون عدد البتات المحجوزة بتان اثنان، وقيمتهما هي ₂(10) دائماً، ونتيجة لذلك تكون قيمة الخانة الأولى فيه محصورة بين 128 و191. طول قسم الشبكة فيه هو 14 بتات وطول قسم المُضيف هو 16 بتاً، ويضمّ كل صنف 2¹⁶ عنواناً، بالإضافة لوجود 2¹⁴ صنفاً من هذا الحجم.
3. الصنف C: ويكون عدد البتات المحجوزة ثلاث بتات، وقيمتها هي ₂(110) دائماً، ونتيجة لذلك تكون قيمة الخانة الأولى فيه محصورة بين 192 و223. طول قسم الشبكة فيه هو 8 بتات وطول قسم المُضيف هو 21 بتاً، ويضمّ كل صنف 2⁸ عنواناً، بالإضافة لوجود 2²¹ صنفاً من هذا الحجم.

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

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

الصنف	حدود قيم الخانة الأكثر الأولى		قناع الصنف القياسي		حدود الأصناف
	بالثنائي	بالعشري	بالعشري المنقط	التمثيل المختصر
الصنف A	من 00000001 حتى 01111110	من 1 حتى 126(16)	255.0.0.0	8/	من 1.0.0.0/8 حتى 126.255.255.255/8
الصنف B	من 10000000 حتى 10111111	من 128 حتى 191	255.255.0.0	16/	من 128.0.0.0/16 حتى 191.255.255.255/16
الصنف C	من 11000000 حتى 11011111	من 192 حتى 223	255.255.255.0	24/	من 192.0.0.0/24 حتى 223.255.255.255/24

غير الصنفية

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

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

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

تجزئة الشبكة واستخدام الأقنعة مختلفة الطول

المفهوم الأساسي في عمليّة تجزئة الشبكة.

مفهوم استخدام الأقنعة مختلفة الطول.

المقالة الرئيسة: تجزئة الشبكة

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

تُوصف التجزئة السابقة بأنها تجزئة وحيدة المستوى (بالإنجليزية: Single-level subnetting)‏، وإذا طُبقت خوارزمية التجزئة نفسها على إحدى الشبكات الجزئية الناتجة عن التجزئة السابقة، فسينتج أفضية جزئية ذات أحجم أصغر، وتُوصف التجزئة عندها بأنها تجزئة مُتعددة المستويات (بالإنجليزية: Multiple-level subnetting)‏، وينتج عنها شبكات ذات أحجام متباينة وذات أقنعة مختلفة الطول.

أمّا استخدام أقنعة الشبكات الجزئيّة مُختلفة الطول (بالإنجليزية: Variable Length Subnet Mask اختصاراً VLSM)‏ فهو استعمال أفضية جزئية ذات أحجام مختلفة نتجت عن التجزئة مُتعددة المستويات لفضاء صنفي واحد، وبما أن أحجام الأفضية مُختلفة، فإن أطوال الأقنعة سيكون مختلفاً أيضاً، ومن هنا حصلت تقنية التجزئة هذه على اسمها. يُساعد استخدام أقنعة الشبكات الجزئيّة مُختلفة الطول في تحصيص فضاء العناوين تحصيصاً أكثر فعاليّة، ويقلل الهدر في فضاء العناوين، لأنه يمنح إمكانية للتحكم بطول قناع الشبكة الجزئيّة، الذي يُحدد بدوره حجم فضاء العناوين. وقد وصف هذا الاستخدام في وثيقة طلب التعليقات RFC 1878.

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

• 
  مثال عن تجزئة شبكة قياسية من الصنف A.
• 
  مثال عن تجزئة شبكة قياسية من الصنف B.
• 
  مثال عن تجزئة شبكة قياسية من الصنف C.
• 
  مثال عن تجزئة غير قياسية.
• 
  مثال عن استعمال الأقنعة مختلفة الطول.

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

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

فضاء عناوين البث المجموعاتي في الإصدار الرابع من بروتوكول الإنترنت هو فضاء العناوين الذي يشمل كل العناوين التي يكون عدد البتات المحجوزة فيها 4 بتات، وقيمتها ₂(1110)، ويُشار إليه أيضاً بالصنف D، وتتراوح قيمة الخانة الأولى فيه بين القيمتين العشريتين: 224 و239.

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

أفضية عناوين البث المجموعاتي

فضاء العناوين	استعمال الفضاء	أصغر عنوان	أكبر عنوان	عدد العناوين	مرجع
224.0.0.0/24	مجموعة عناوين التحكم في الشبكة المحلية	224.0.0.0	224.0.0.255	28 = 256
224.0.1.0/24	مجموعة عناوين التحكم بين الشبكية	224.0.1.0	224.0.1.255	28 = 256
لا يُمكن تمثيله	مجموعة العناوين المُخصصة الأولى	224.0.2.0	224.0.255.255	28 * 254 = 65024	-
224.1.0.0/16	فضاء محجوز	224.1.0.0	224.1.255.255	216 = 65536	-
224.2.0.0/16	مجموعة عناوين بروتوكولي الإعلان عن الجلسة ووصف الجلسة	224.2.0.0	224.2.255.255	216 = 65536
224.3.0.0/16 و 224.4.0.0/16	مجموعة العناوين المُخصصة الثانية	224.3.0.0	224.4.255.255	216 * 2 = 131072	-
لا يُمكن تمثيله	فضاء محجوز	224.5.0.0	224.255.255.255	216 * 251 = 16449536	-
لا يُمكن تمثيله	فضاء محجوز	225.0.0.0	231.255.255.255	224 * 7 = 117440512	-
232.0.0.0/8	مجموعة عناوين البث المجموعاتي مُحدد المصدر	232.0.0.0	232.255.255.255	224 = 16777216
لا يُمكن تمثيله	مجموعة عناوين غلوب (بالإنجليزية: GLOP Block)‏	233.0.0.0	233.251.255.255	216 * 252 = 16515072
232.252.0.0/14	مجموعة العناوين المُخصصة الثالثة	233.252.0.0.0	233.255.255.255	216 * 4 = 262,144	-
لا يُمكن تمثيله	فضاء محجوز	234.0.0.0	238.255.255.255	224 * 5 = 83886080	-
239.0.0.0/8	مجموعة العناوين المُراقَبِة إشرافيّاً	239.0.0.0	239.255.255.255	224 = 16777216

أفضية محجوزة

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

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

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

فضاء العناوين	تاريخ الحجز	ملاحظات	مرجع
0.0.0.0/8	سبتمبر 1981	يُستخدم أي عنوان من هذا الفضاء كعنوان مصدر لمُضيف يُنجر عملية التهيئة الآلية للحصول على عنوان بروتوكول إنترنت.
10.0.0.0/8	فبراير 1996	فضاء محجوز كشبكة خاصة ضمن فضاء الصنف القياسي A، يُمكن أن تُستخدم عناوين من هذا الفضاء عناوين مصدر أو وجهة في رزم الإصدار الرابع من بروتوكول الإنترنت.
100.64.0.0/10	أبريل 2012	فضاء محجوز ليستعمل بادئة في فضاء العناوين المشترك.
127.0.0.0/8	سبتمبر 1981	فضاء عناوين الحلقة العكسية، يُستخدم أي عنوان من هذا الفضاء كعنوان للمضيف المحلي في أي مُضيف للإصدار الرابع من بروتوكول الإنترنت
169.254.0.0/16	مايو 2005	فضاء محجوز من أجل عناوين الوصلة المحلية في الإصدار الرابع من بروتوكول الإنترنت
172.16.0.0/12	فبراير 1996	فضاء محجوز كشبكة خاصة ضمن فضاء الصنف القياسي B، يُمكن أن تُستخدم عناوين من هذا الفضاء عناوين مصدر أو وجهة في رزم الإصدار الرابع من بروتوكول الإنترنت.
192.0.0.0/24	يناير 2010	فضاء محجوز لهيئة أرقام الإنترنت المُخصصَة من أجل دعم مهمّات مجموعة مهندسي شبكة الإنترنت.
192.0.0.0/29	يونيو 2011	فضاء محجوز من أجل تقنية المُكّدس المزدوج المُبسّطة (بالإنجليزية: Dual-Stack Lite)‏.
192.0.2.0/24	يناير 2010	فضاء عناوين محجوز من أجل عمليات التوثيق.
192.88.99.0/24	يونيو 2001	فضاء عناوين محجوز من أجل عناوين البث نحو الأقرب لتقنية 6 إلى 4 (بالإنجليزية: 6to4 anycast address)‏.
192.168.0.0/16	فبراير 1996	فضاء محجوز كشبكة خاصة ضمن فضاء الصنف القياسي C، يُمكن أن تُستخدم عناوين من هذا الفضاء عناوين مصدر أو وجهة في رزم الإصدار الرابع من بروتوكول الإنترنت.
198.18.0.0/15	مارس 1999	فضاء عناوين محجوز من أجل عمليات المقارنة المرجعيّة.
198.51.100.0/24	يناير 2010	فضاء عناوين محجوز من أجل عمليات التوثيق.
203.0.113.0/24	يناير 2010	فضاء عناوين محجوز من أجل عمليات التوثيق.
240.0.0.0/4	أغسطس 1989	فضاء عناوين الصنف E، وهو محجوز لاستخدامات مُستقبليّة.
255.255.255.255/32	أكتوبر 1984	عنوان بث عام يمكن استعماله في أي شبكة محليّة.

التقطيع وإعادة التجميع

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

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

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

التقطيع

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

تقطيع رزم البيانات (بالإنجليزية: Packet fragmentation)‏ هو وظيفة من وظائف الإصدار الرابع من بروتوكول الإنترنت. عندما تستقبل طبقة الإنترنت التي تُشغّل الإصدار الرابع من بروتوكول الإنترنت رزمة بيانات مُوجَّهة لإرسالها إلى عبر أحد المنافذ، فإنّها تقوم بتحديد قيمة وحدة النقل العظمى في الشبكة المرتبطة مع ذلك المنفذ، ثُمّ يقارن بروتوكول الإنترنت حجم الرزمة مع قيمة وحدة النقل العظمى، فإذا كان حجم الرزمة أكبر، فلا بدَ من تقطيع الرزمة إلى قطع أصغر حجماً تُشكل كل منها رزمة بيانات مستقلّة. يحصل التقطيع في الإصدار الرابع من بروتوكول الإنترنت في مصدر رزمة البيانات وفي أي عقدة وسطيّة تعالج الرزمة عبر مسارها من مصدرها إلى وجهتها، كما يمكن تقطيع القطع إلى قطع أصغر إذا دعت الحاجة إلى ذلك.

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

وصفت خوارزمية التقطيع في محددات البروتوكول، وهي تتبع المراحل التالية:

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

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

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

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

وصفت خوارزمية إعادة التجميع في محددات البروتوكول، وهي تتبع المراحل التالية:

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

هناك خوارزمية تجميع أُخرى، جرى مناقشتها وشرحها في وثيقة طلب التعليقات RFC 815.

المشكلات

مرتبطة بالعنونة

استنفاد فضاء العناوين

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

توصيف المشكلة

لدى هيئة أرقام الإنترنت المُخصصَة وعموم سجلات الإنترنت الإقليمية

لدى سجلات الإنترنت الإقليمية

مخططان زمنيان لانخفاض عدد الأفضية غير المُحصصة في فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت.

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

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

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

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

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

الحلول المقترحة

ترجمة عنوان الشبكة

مثال عن استعمال تقنية ترجمة عناوين الشبكة باستخدام فضاء عناوين خاص من الصنف A هو 10.0.0.0/8.

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

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

توجد ثلاث أشكال لتقنية ترجمة عناوين الشبكة، الأولى هي ترجمة عناوين الشبكة الثابتة (بالإنجليزية: Static NAT)‏، وفيها يجري ترجمة كل عنوان خاص إلى عنوان عام مقابل له في جدول مطابقة مُعدّ مسبقاً. والثانية هي ترجمة عناوين الشبكة الآليّة (بالإنجليزية: Dynamic NAT)‏ وفيها يجري تشارك عدد محدد من العناوين العامة بواسطة عدد أكبر من مُضيفي العناوين الخاصّة، من غير وجود جدول مطابقة مُعدّ مسبقاً، ويُترجِم مُوجّه مُعدّ مسبقاً العنوان الخاص إلى عنوان عام فور توافر الأخير. والثالثة هي ترجمة عنوان الشبكة ورقم المنفذ، والتي تسمّى أيضاً ترجمة عناوين الشبكة المُحمّلة زائداً بترجمة أرقام المنافذ ⁽¹⁷⁾، وفيها يجري تشارك عنوان عام واحد بواسطة عدد كبير جداً من مُضيفي العناوين الخاصّة، يزيد عن 65 ألفاً، اعتماداً على منحهم أرقام منافذ مُتمايزة.

طوّرت تقنيّة ترجمة عناوين الشبكة في العام 1994م لتكون حلاً لمشكة استنفاد عناوين الإصدار الرابع من بروتوكول الإنترنت ضمن الإستراتيجية قصيرة الأمد، ووصفت أساساً في وثيقة طلب التعليقات RFC 1631، وعدّل المعيار لاحقاً وأضيف إليه دعم ترجمة عنوان الشبكة ورقم المنفذ ونُشر في عام 2001 تحت الاسم الرمزي RFC 3022.

جدول للبوادئ المتاحة للاستعمال في العنونة غير الصنفية ، ومكافئاتها حسب العنونة الصنفية.

العنونة غير الصنفية والتوجيه غير الصنفي بين النطاقات

المقالة الرئيسة: توجيه غير صنفي بين النطاقات

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

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

أمّا التوجيه غير الصنفي بين النطاقات (بالإنجليزية: Classless InterDomian Routing اختصاراً CIDR)‏ هو آلية توجيه مبنية على العنونة غير الصنفية في الشبكات المعنونة بالإصدار الرابع من بروتوكول الإنترنت، وهو حلٌ ضمن الإستراتيجية قصيرة الأمد لمشكلة استنفاد عناوين الإصدار الرابع من بروتوكول الإنترنت. وصفت العنونة والتوجيه غير الصنفيان في وثيقة طلب التعليقات RFC 1338 في العام 1992م أولاً ، ثُمّ في الوثيقتين RFC 1518 للعنونة وRFC 1519 للتوجيه في العام 1993م، وأخيراً صدرت الوثيقة RFC 4632 في هذا الصدد في العام 2006م.

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

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

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

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

الإصدار السادس من بروتوكول الإنترنت (بالإنجليزية: Internet Protocol version 6 اختصاراً IPv6)‏ هو الحل المقترح ضمن الإستراتيجية طويلة الأمد لحل مشكلة استنفاد عناوين الإصدار الرابع من بروتوكول الإنترنت. وهو بروتوكول تشبيك يقدم خدمة العنونة في شبكات البيانات، يبلغ طول عنوان الإصدار السادس من بروتوكول الإنترنت 128 بت، ويشمل فضاء عناوين يضم 2¹²⁸ عنواناً أو ما يعادل 3.4x10³⁸ عنوان، وهو عدد ضخم جداً من العناوين من الغير المُمكن استهلاكه في الأفق المنظور.

تضمّن تصميم الإصدار السادس من بروتوكول الإنترنت دعماً افتراضياً لعدد من التقنيات التي سبق وأضيفت للإصدار الرابع مثل تجميع المسارات والعنونة المحلية وترجمة عناوين الشبكة، بالإضافة لتقنيات أخرى جديدة مثل التهيئة الذاتية الآلية (SLAAC) وصنف جديد من العنونة هو العنونة الاختياريّة (بالإنجليزية: Anycast)‏. بالإضافة لذلك، يعتمد الإصدار السادس من بروتوكول الإنترنت اعتماداً كبيراً على بروتوكول رديف طوّر خصصيصاً لدعم هذه الوظائف، وهو بروتوكول اكتشاف الجيران (NDP).

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

طوّر الإصدار السادس من بروتوكول الإنترنت في العام 1995م ووصف في وثيقة طلب التعليقات RFC 1883.، ثُم أدخلت العديد من التعديلات والإضافات وصدر معيار جديد للبروتوكول في العام 1997م تحت الاسم الرمزي RFC 2460. ظل هذا المعيار هو المرجع الرسمي للبروتوكول لعقدين من الزمن حتى العام 2017م، عندما صدرت الوثيقة RFC 8200 التي شملت التعديلات اللازمة لعمل البروتوكول والإضافات التي أدخلت إليه إدخالاً متباعداً في السنوات السابقة.

تراكب أفضية العناوين

مثال عن تراكب أفضية عناوين الشبكة بسبب استخدام غير صحيح للأقنعة مختلفة الطول، فمثلاً يتراكب الفضاءان 200.100.10.0/26 و200.100.10.0/27 وأيضاً: 200.100.10.0/26 و200.100.10.48/28.

تراكب أفضية عناوين بروتوكول الإنترنت (بالإنجليزية: IP address spaces overlap)‏ هي مشكلة مرتبطة بالعنونة، وتحصل غالباً بسبب استخدام غير صحيح للأقنعة مختلفة الطول. عندما تتراكب أفضية العناوين، يصبح هناك مجموعة من العناوين مشتركة بين فضاءَين أو أكثر، ونتيجة لذلك، يمكن أن يحصل مُضيفان على نفس العنوان ولكن يكون لكل منها قناع مختلف، ويؤدي ذلك إلى حصول مشكلة في توجيه رزم البيانات، لذلك لا يجب أن تتراكب أفضية العناوين عند إنجاز عملية العنونة.

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

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

• هجوم القطعة الصغيرة: (بالإنجليزية: Tiny Fragment Attack)‏ وهو هجوم رقمي يحصل عن طريق إرسال رزمة بيانات خبيثة صغيرة بالحجم لتمر عبر جدار الحماية بوصفها قطعة ناتجة عن التقطيع. يعتمد هذا الهجوم على حقيقة أن أصغر رزمة بيانات يمكن لأي وحدة تدعم الإصدار الرابع من بروتوكول الإنترنت التعامل معها هي بطول 68 بايت، وفيها تكون ترويسة بروتوكول الإنترنت بأقصى طول أعظمَ مسموح لها، وهو 60 بايت، في حين تكون الحمولة بطول 8 بايت فقط. ولا يكفي هذا الطول لإدراج ترويسة بروتوكول النقل ضمن الرزمة، وهي تجتاز بذلك جدار الحماية دون أن يتحقق منها، لأنه يتفحص عادة أرقام المنافذ في طبقة النقل، وصفت هذه المشكلة وحلولها في وثيقة طلب التعليقات RFC 3128.
• هجوم القطع المتراكبة (بالإنجليزية: Overlapping Fragment Attack)‏ وهو هجوم رقمي يعتمد على وجود ثغرة في الخوارزمية المُستعملة عند إعادة تجميع الرزمة الأصلية، وعندها يمكن لأي قطعة تالية أن تتراكب مع قطعة أخرى سابقة، وتحل محلها جزئيّاً أو كليّاً، ويعني ذلك أنه بالإمكان تمرير القطعة الأولى، التي تحتوي ترويسة بروتوكول الإنترنت من جدار الحماية تمريراً شرعياً، ثُمّ التلاعب بقيمتها عن طريقة التراكب مع قطعة تالية ترد لاحقاً.
• مشكلات مرتبطة ببروتوكول افتران العناوين: ترتبط هذه المشكلات بطريقة تنفيذ بروتوكول اقتران العناوين، فعند تقطيع رزمة بيانات هل ترسل رسائل البروتوكول من أجل قطعة أم يكتفى بالإرسال من أجل الرزمة الأصلية ؟ بالإضافة لذلك، وفي حال إرسال رسائل البروتوكول لكل قطعة، فإن إعادة تجميع الرزمة يتوقف على نجاح كل القطع في الوصول إلى الوجهة النهائية، ولو فشلت إحداها لأسباب تتعلق بعمل بروتوكول ترجمة العناوين، فإنّ تجميع الرزمة سيكون غير مُمكناً، وستتخلص الوجهة من القطع المستقبلة. نُوقشت القضايا الخاصة بتنفيذ البروتوكول بالشكل الأمثل، ومنها القضيتان المرتبطان بالتقطيع في وثيقة طلب التعليقات RFC 1122.

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

بروتوكولات اقتران العناوين

المقالة الرئيسة: بروتوكول اقتران العناوين

في نموذج الربط البيني للأنظمة المفتوحة، بروتوكولات ترجمة العناوين هي عائلة من البروتوكولات التي تعمل على مطابقة العناوين بين بروتوكول تشبيك العامل في طبقة الشبكة وبروتوكول الوصلة في طبقة الوصلة تبادلاً، وهي تضم عدداً من البروتوكولات منها:

• بروتوكول اقتران العناوين:(بالإنجليزية: Address Resolution Protocol اختصاراً ARP)‏ هو برتوكول ترجمة عناوين يُستعمل لاكتشاف عنوان بروتوكول الوصلة المرتبط مع عنوان بروتوكول الإنترنت في مُضيف بعيد، وهذه المطابقة هي وظيفة جوهرية في عمل حزمة بروتوكولات الإنترنت. طُوّر البروتوكول في عام 1982م ووصف في وثيقة طلب التعليقات RFC 826.
• بروتوكول اقتران العناوين المعكوس: (بالإنجليزية: Inverse Address Resolution Protocol اختصاراً InARP)‏ هو برتوكول اقتران عناوين يُستعمل لاكتشاف عنوان بروتوكول التشبيك المُرتبط مع عنوان بروتوكول الوصلة في مُضيف بعيد، أي أن عمله معاكس لعمل بروتوكول اقتران العناوين، طوّر البروتوكول في عام 1992م، ووصف في الوثيقة RFC 1293.
• بروتوكول اقتران العناوين العكسي: هو بروتوكول ترجمة عناوين يُستعمل لاكتشاف عنوان بروتوكول التشبيك المُرتبط مع عنوان بروتوكول الوصلة في العقدة التي تُشغله، أي أن عمله مطابق لعمل بروتوكول اقتران العناوين العكسية ولكنّه يعمل في العقدة نفسها لا عبرَ الشبكة، طوّر البروتوكول في عام 1984م ووصف في وثيقة طلب التعليقات RFC 903.

بروتوكول رسائل التحكم في شبكة الإنترنت ICMP

بروتوكول رسائل التحكم في الإنترنت
ترويسة عامة لرسائل البروتوكول
اختصار	ICMP
الوظيفة	إنجاز وظائف التحكم بين مضيفي الإصدار الرابع من بروتوكول الإنترنت.
المُطوِّر	وكالة البحوث الدفاعية المتقدمة
تاريخ التطوير	1981م
طبقة نموذج OSI	طبقة الشبكة
وثيقة طلب التعليقات RFC	RFC 792

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

بروتوكول رسائل التحكم في شبكة الإنترنت (بالإنجليزية: Internet Control Message Protocol اختصاراً ICMP)‏ هو بروتوكول اتصال وجزء مدمج من الإصدار الرابع من بروتوكول الإنترنت، يُستعمل من قبل مُضيفي الإصدار الرابع ليؤمن آليّة لوجهة رزمة البيانات لتتواصل مع مصدرها وتزودها بمعلومات متنوعة عن حالة الشبكة أو عن معالجة الرزمة، طُوّر البروتوكول في العام 1981، ووصف في وثيقة طلب التعليقات RFC 792.

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

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

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

بروتوكول إدارة مجموعة الإنترنت IGMP

بروتوكول إدارة مجموعة الإنترنت
ترويسة بروتوكول الإنترنت، و
الوظيفة	إدارة مجموعات البث المجموعاتي
المُطوِّر	مجموعة مهندسي الإنترنت (IETF)
تاريخ التطوير	IGMPv1 : 1989 IGMPv2 : 1997 IGMPv3 : 2002
طبقة نموذج OSI	طبقة الشبكة
وثيقة طلب التعليقات RFC	V1: RFC 1112 V2: RFC 2236 V3: RFC 3376

المقالة الرئيسة: بروتوكول إدارة مجموعة الإنترنت

بروتوكول إدارة مجموعة الإنترتت (بالإنجليزية: Internet Group Management Protocol اختصاراً IGMP)‏ هو بروتوكول اتصال يعمل على مستوى طبقة الشبكة، يدير المجموعات الخاصة بالبث المجموعاتي لرزم الإصدار الرابع من بروتوكول الإنترنت، ويحدد كيفية انضمام المضيفين إلى المجموعات وكيفية مغادرتهاآليّاً، ومعنى ذلك أنه يسمح لأي مُضيف بأن ينضم أو بأن يغادر المجموعة في أيّ وقت يشاء. بالإضافة لذلك، لا يضع البروتوكول قيوداً على عدد أعضاء المجموعة ولا على مواقعهم، كما يسمح لمضيف واحد بالانضمام إلى أكثر من مجموعة في الوقت نفسه.

طوّرت مجموعة مهندسي الإنترنت ثلاث إصدارات من بروتوكول إدارة مجموعات الإنترنت، أولها جاء في العام 1989م، وهو موصوف في الوثيقة RFC 1112، وقد حدد آليّات انضمام المضيف إلى مجموعة ما أو مغادرتها، أما الإصدار الثاني، فطوّر في العام 1997م، ووصف في الوثيقة RFC 2236، وقد احتوى العديد من التعديلات أهمها السماح للمضيف بطلب مُغادرة مجموعة مُعيّنة بحد ذاتها، أما الإصدار الثالث فقد طوّر في العام 2002، وهو موصوف في الوثيقة RFC 3376، وهو يدعم ميّزة البث المجموعاتي مُحدد المصدر وميزة تجميع تقارير العضوية (بالإنجليزية: Membership Report Aggregation)‏.

حزمة أمن بروتوكول الإنترنت IPsec

المقالة الرئيسة: حزمة أمن بروتوكول الإنترنت

حزمة أمن بروتوكول الإنترنت (بالإنجليزية: Internet Protocol Security اختصاراً IPsec)‏ هي مجموعة من البروتوكولات التي تُستعمل لتأمين خدمات الخصوصية والتحقق من الهوية في طبقة الشبكة. تستعمل هذه الحزمة لتأمين الاتصال بين البوابات، أو بين مضيف وبوابة أو بين مضيفين⁽¹⁸⁾، وذلك من أجل الإصدار الرابع أو السادس من بروتوكول الإنترنت أو من أجل بروتوكولات تشبيك أخرى.

هذه الحزمة في معيار مفتوح، ويمكن حصر الوظائف المتنوعة التي تقدمها في ثلاثة بنود هي: بروتوكول ترويسة التحقق من الهوية (بالإنجليزية: Authentication Header اختصاراً AH)‏ ويؤمن سلامة بيانات الرزم والتحقق من هوية مصدرها ، وبروتوكول تغليف الحمولة الآمنة (بالإنجليزية: Encapsulating Security Payload اختصاراً ESP)‏ وهو يؤمن سرية البيانات ويحميها من مجموعة الهجمات التي تعتمد على رسائل الرد ، وتنظيمات الأمن (بالإنجليزية: Security Associations اختصاراً SA)‏ وهي مجموعة من الخوارزميات والمُحددات التي يستعملها البروتوكولان السابقان.

تأسست مجموعة عمل تأمين بروتوكول الإنترنت (بالإنجليزية: IP Security Working Group)‏ لتكون جزءاً من مجموعة مهندسي شبكة الإنترنت في العام 1993م ، بهدف توحيد الجهود المبذولة من قبل عدّة مؤسسات بحثيّة، وفي مقدمتها معمل أبحاث البحرية الأمريكية NRL ووضع معايير لخدمات الأمن المُقدمة في طبقة الشبكة. ونشرت هذه المجموعة ثلاث وثائق في العام 1995 ، وكان ذلك فاتحة لنشر عشرات الوثائق والمعايير اللاحقة في السنوات التالية، قبل أن يتوقف نشاط المجموعة نهائياً في العام 2005.

هوامش

1. العنوان الأصل هو: (بالإنجليزية: A protocol for Packet Network Interconnection)‏.

2. بخصوص بروتوكول التحكم بالنقل، انظر وثيقة طلب التعليقات RFC 793.

3. يلزم الانتباه إلى أن ترقيم الإصدارات يبدأ من الصفر، فالإصدار الأوّل هو الإصدار رقم 0.

4. أسماء وثائق الملاحظات باللغة الإنكليزية وفقاً لترتيب الورود:

• IEN 2: Comments on Internet Protocol and TCP
• IEN 26:A proposed New Internet Header Format
• IEN 28: Draft Internetwork Protocol Description Version 2
• IEN 41: Internet Protocol Specification Version 4
• IEN 44: Latest Header Format
• IEN 54: Internet Protocol Specification Version 4

5. لم يُستخدم الرقمان 2 و3 للإشارة إلى إصدار بروتوكول الإنترنت، وجرى الانتقال من 1 إلى 4 مباشرة.

6.العنوان الأصلي هو: (بالإنجليزية: DOD STANDARD INTERNET PROTOCOL)‏.

7. الاسم الأصلي للبروتوكول هو (بالإنجليزية: Internet Stream Protocol)‏.

8. حسب نموذج الإنترنت، يعمل البروتوكول في طبقة الإنترنت.

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

10. أسماء الأعلام هي (بالإنجليزية: Do not Fragment Flag)‏ لعلم عدم التقطيع، و(بالإنجليزية: More Fragment Flag)‏ لعلم المزيد من القطع.

11. يوجد شكلان لبنية الخيار، الأول هو مخصص للاستعمال إذا كان البروتوكول الذي يستخدم بروتوكول الإنترنت محتفظاً بالحالة (بالإنجليزية: Stateful)‏، وطول الخيار الإجمالي هو 12 بايت، والثاني في حالة كان البروتوكول غير محتفظ بالحالة (بالإنجليزية: Stateless)‏ ويكون طول الخيار هو 44 بايت.

12. يوجد شكلان لبنية الخيار، الأول مخصص لطلب المعدل (بالإنجليزية: Rate Request)‏ والثاني لتقديم تقرير بالمعدل رداً على الطلب (بالإنجليزية: Rate report)‏.

13. سات نت (بالإنجليزية: SATNET)‏ أو شبكة رزم القمر الاصطناعي الأطلسيّة كانت شبكة أقمار اصطناعيّة شكّلت جزء من شبكة الإنترنت الأولى في نهاية السبعينات ومطلع الثمانينيات من القرن العشرين الميلادي، بنتها شركة بي بي إن للتكنولوجيا. وصف البورتوكول الذي يستعمله مضيفو الشبكة في وثيقة ملاحظات الإنترنت رقم 192.

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

15. يجب التمييز بين عدد العناوين في الفضاء ويحسب باستخدام العلاقة 2^m، وبين عدد العناوين المتاحة للاستعمال في عنونة المضيفين ويُحسب بالعلاقة 2^m - 2، وفيها تُمثل m عدد بتات قسم المُضيف في الحالتين. وأمّا العنوانان المطروحين فهما عنوان الشبكة وعنوان البث العام.

16. فضاء العناوين (0.0.0.0/8) محجوز بالكامل، ولا يستعمل في عنونة المُضيفين إلا في أثناء عملية التهيئة الآلية، وأيضاً الفضاء (127.0.0.0/8) محجوز لأغراض الحلقة المحلية ولا يُستخدَم في عنونة المضيفين.

17. أطلق المعيار الأصيل على هذه التقنية اسم ترجمة عنوان الشبكة ورقم المنفذ (بالإنجليزية: Network Address Port Translation اختصاراً NAPT)‏ ، ولكنّها أصبحت تُعرف لاحقاً باسم(بالإنجليزية: Overloading NAT with Port Address Translation)‏.

18. الأسماء الأصيلة هي (بالإنجليزية: Gateway-to-Gateway وHost-to-Gateway وHost-to-Host)‏.

انظر أيضًا

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

المراجع

فهرس المراجع

فهرس المراجع العربية

فهرس المراجع الأجنبية

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

مواقع الويب (مرتبة حسب ورودها في المقالة)

• "Service Name and Transport Protocol Port Number Registry". IANA (بالإنجليزية). Archived from the original on 2019-09-22. Retrieved 2017-07-31.
• "Internet Protocol Version 4 (IPv4) Parameters - IP Option Numbers". IANA (بالإنجليزية). Archived from the original on 2019-11-24. Retrieved 2019-06-26.
• "IPv4 Multicast Address Space Registry". IANA (بالإنجليزية). Archived from the original on 2019-02-06. Retrieved 2019-09-14.
• "Version Numbers". IANA (بالإنجليزية). Archived from the original on 2019-01-18. Retrieved 2019-05-26.
• Huston, Geoff (29 Jan 2016). "Evaluating IPv4 and IPv6 Packet Fragmentation". Réseaux IP Européens Network Coordination Centre RIPE NCC (بالإنجليزية). Archived from the original on 2018-04-25. Retrieved 2019-09-17.
• "Available Pool of Unallocated IPv4 Internet Addresses Now Completely Emptied" (PDF). ICANN (بالإنجليزية). 3 Feb 2011. Archived from the original (PDF) on 2019-09-20. Retrieved 2019-09-20.
• "IP Security Protocol (ipsec) - Group History". IETF (بالإنجليزية). Archived from the original on 2019-09-13. Retrieved 2019-09-28.
• "IP Security Protocol (ipsec)" (بالإنجليزية). Archived from the original on 2019-09-13. Retrieved 2019-09-28.

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

• Paul Baran (Aug 1964), On Distributed communications: I.introduction to distributed communications networks (PDF) (بالإنجليزية), RAND Corporation, DOI:10.7249/RM3420, OCLC:8162492504, QID:Q115920096
• Louis Pouzin (Jan 1973). "Presentation and major design aspects of the CYCLADES computer network". DATACOMM '73 (بالإنجليزية). Association for Computing Machinery: 80–87. DOI:10.1145/800280.811034. ISBN:978-1-4503-7384-5. OCLC:8876960505. QID:Q115920526.
• V. Cerf; R. Kahn (May 1974). "A Protocol for Packet Network Intercommunication" (PDF). IEEE Transactions on Communications (بالإنجليزية). Institute of Electrical and Electronics Engineers. 22 (5): 637–648. DOI:10.1109/TCOM.1974.1092259. ISSN:0090-6778. OCLC:5871436046. QID:Q54195996.
• Peter T. Kirstein (Apr 1978), Annual Report 1 January 1977 - 31 December 1977 (PDF) (بالإنجليزية), Defense Technical Information Center, QID:Q115973410
• J.C. Mogul; G. Tsudik (May 1989). "Visa protocols for controlling interorganizational datagram flow". IEEE Journal on Selected Areas in Communications (بالإنجليزية). Institute of Electrical and Electronics Engineers. 7 (4): 486–498. DOI:10.1109/49.17712. ISSN:0733-8716. OCLC:5871908921. QID:Q115957069.
• Deborah Estrin; Dino Farinacci (17 May 1999), Bi-Directional Shared Trees in PIM-SM (بالإنجليزية) (1st ed.), Internet Engineering Task Force, QID:Q115957272
• Thomas H. Ptacek; Timothy N. Newsham (Jan 1998), Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection (PDF) (بالإنجليزية), Defense Technical Information Center, OCLC:946230316, QID:Q115973156
• Commercial IP Security Option (CIPSO 2.2) (بالإنجليزية) (1st ed.), Internet Engineering Task Force, 16 Jul 1992, QID:Q115957329
• Andrew Main (23 Feb 2005), Textual Representation of IPv4 and IPv6 Addresses (بالإنجليزية) (2nd ed.), Internet Engineering Task Force, QID:Q115965465

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

الإنجليزية:

• Peter John Dyson (1999). Dictionary of Networking (بالإنجليزية) (3rd ed.). San Francisco: Sybex. ISBN:0-7821-2461-5. OCLC:43596809. OL:8096220M. QID:Q115917529.
• Donald C. Lee (2000). Enhanced IP services for Cisco networks (بالإنجليزية) (1st ed.). Indianapolis: Cisco Press. ISBN:978-1-57870-106-3. OCLC:1244715817. QID:Q115941690.
• J.D. Wegner; Robert Rockell (2000). IP Addressing and Subnetting INC IPV6: Including IPv6 (بالإنجليزية). Syngress Publishing. ISBN:978-1-928994-01-5. OCLC:611315767. QID:Q115972434.
• Heather Osterloh (2002). IP routing and primer plus (بالإنجليزية). Indianapolis: Prentice Hall. ISBN:978-0-672-32210-5. OCLC:225957982. QID:Q115942000.
• Anthony Bruno (2003). CCIE routing and switching exam certification guide (بالإنجليزية). Indianapolis: Cisco Press. ISBN:978-1-58720-053-3. OCLC:52644447. QID:Q115927766.
• Andrew Blank (2004). TCP/IP Foundations (بالإنجليزية). San Francisco: Sybex. ISBN:978-1-4175-3992-5. OCLC:56471015. QID:Q115930741.
• 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.
• Kent Hundley (2009). Alcatel-Lucent Scalable IP Networks Self-Study Guide: Preparing for the Network Routing Specialist I (NRS 1) Certification Exam (بالإنجليزية) (1st ed.). Indianapolis: Wiley. ISBN:978-0-470-42906-8. OCLC:941120405. QID:Q115933218.
• 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.
• Toni Janevski (2015). Internet Technoligies for Fixed and Mobile Networks (بالإنجليزية) (1st ed.). Boston: Artech House. ISBN:978-1-60807-921-6. OCLC:933446122. QID:Q115942989.

العربية:

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

ملاحظات تجارب الإنترنت (مرتبة تصاعدياً حسب رقم الوثيقة)

• Jon Postel (15 Aug 1977). "2.3.3.2 Comments on Internet Protocol and TCP". Internet Experiment Note (بالإنجليزية). RFC Editor (2). QID:Q115941189.
• Vint Cerf (14 Feb 1978). "2.3.2.1 A Proposed New Internet Header Format" (PDF). Internet Experiment Note (بالإنجليزية). RFC Editor (26). QID:Q115941327.
• Jon Postel (Feb 1978). "Draft Internetwork Protocol Description Version 2" (PDF). Internet Experiment Note (بالإنجليزية). RFC Editor (28). QID:Q115941399.
• Jon Postel (Jun 1978). "Internetwork protocol specification version 4" (PDF). Internet Experiment Note (بالإنجليزية). RFC Editor (41). QID:Q115941551.
• Jon Postel (Jun 1978). "Latest Header Format" (PDF). Internet Experiment Note (بالإنجليزية). RFC Editor (44). QID:Q115941600.
• Jon Postel (Sep 1978). "Internet Protocol Specification Version 4" (PDF). Internet Experiment Note (بالإنجليزية). RFC Editor (54). QID:Q115941660.
• BBN Technologies (Jul 1981). "Host/SATNET Protocol". Internet Experiment Note (بالإنجليزية). RFC Editor (192). QID:Q115973212.

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

• Vinton Cerf; Yogen Dalal; Carl Sunshine (Dec 1974), Specification of Internet Transmission Control Program (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0675, RFC:675, QID:Q47481342
• J. Postel (Jan 1980), Internet Protocol (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0760, RFC:760, QID:Q3415158
• J. Postel (Sep 1981), Internet Protocol: DARPA Internet Program, Protocol Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0791, RFC:791, QID:Q47467078
• J. Postel (Sep 1981), Internet Control Message Protocol (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0792, RFC:792, QID:Q47477090
• J. Postel (Sep 1981), Transmission Control Protocol (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0793, RFC:793, QID:Q47466552
• J. Postel (Nov 1981), NCP/TCP transition plan (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0801, RFC:801, QID:Q47315900
• D.D. Clark (Jul 1982), IP datagram reassembly algorithms (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0815, RFC:815, QID:Q47467790
• D. Plummer (Nov 1982), Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0826, RFC:826, QID:Q47463767
• J.C. Mogul (Jun 1984), A Reverse Address Resolution Protocol (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0903, RFC:903, QID:Q47253471
• J.C. Mogul (Oct 1984), Broadcasting Internet Datagrams (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0919, RFC:919, QID:Q47208596
• J. Postel; J.C. Mogul (Aug 1985), Internet Standard Subnetting Procedure (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0950, RFC:950, QID:Q47484148
• S.E. Deering (Jul 1986), Host extensions for IP multicasting (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0988, RFC:988, QID:Q47457725
• J. Postel; J.K. Reynolds (Nov 1986), Assigned numbers (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0990, RFC:990, QID:Q47481491
• K. McCloghrie; J.C. Mogul; C. Partridge (Jul 1988), IP MTU discovery options (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1063, RFC:1063, QID:Q47485053
• S. Kent (Nov 1991), U.S. Department of Defense Security Options for the Internet Protocol (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1108, RFC:1108, QID:Q47471823
• S.E. Deering (Aug 1989), Host extensions for IP multicasting (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1112, RFC:1112, QID:Q47460092
• R. Braden (Oct 1989), Requirements for Internet Hosts - Communication Layers (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1122, RFC:1122, QID:Q47467189
• S. Deering (Sep 1991), ICMP Router Discovery Messages (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1256, RFC:1256, QID:Q47472905
• T. Bradley; C. Brown (Jan 1992), Inverse Address Resolution Protocol (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1293, RFC:1293, QID:Q47206843
• T. Li (Jun 1992), Supernetting: an Address Assignment and Aggregation Strategy (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1338, RFC:1338, QID:Q47468405
• P. Almquist (Jul 1992), Type of Service in the Internet Protocol Suite (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1349, RFC:1349, QID:Q47244962
• G. Malkin (Jan 1993), Traceroute Using an IP Option (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1393, RFC:1393, QID:Q47484174
• R. Ullmann (Jun 1993), TP/IX: The Next Internet (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1475, RFC:1475, QID:Q1427033
• Y. Rekhter; T. Li (Sep 1993), An Architecture for IP Address Allocation with CIDR (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1518, RFC:1518, QID:Q47314090
• T. Li (Sep 1993), Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1519, RFC:1519, QID:Q47199620
• J. Onions (Apr 1994), A Historical Perspective On The Usage Of IP Version 9 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1606, RFC:1606, QID:Q47201702
• K. Egevang; P. Francis (May 1994), The IP Network Address Translator (NAT) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1631, RFC:1631, QID:Q47164409
• C. Graff (Mar 1995), IPv4 Option for Sender Directed Multi-Destination Delivery (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1770, RFC:1770, QID:Q47473829
• L. Berger (Aug 1995), Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+ (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1819, RFC:1819, QID:Q47325492
• R. Atkinson (Aug 1995), Security Architecture for the Internet Protocol (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1825, RFC:1825, QID:Q47467043
• R. Atkinson (Aug 1995), IP Encapsulating Security Payload (ESP) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1827, RFC:1827, QID:Q47469722
• T. Pummill; B. Manning (Dec 1995), Variable Length Subnet Table For IPv4 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1878, RFC:1878, QID:Q47484670
• S. Deering; R. Hinden (Dec 1995), Internet Protocol, Version 6 (IPv6) Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1883, RFC:1883, QID:Q47472593
• S. Deering (Dec 1995), Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1885, RFC:1885, QID:Q47468348
• Y. Rekhter; E. Lear (Feb 1996), Address Allocation for Private Internets (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1918, RFC:1918, QID:Q47462819
• M. Handley; C. Perkins (Oct 2000), Session Announcement Protocol (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2974, RFC:2974, QID:Q47165174
• R. Droms (Mar 1997), Dynamic Host Configuration Protocol (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2131, RFC:2131, QID:Q47208716
• W. Fenner (Nov 1997), Internet Group Management Protocol, Version 2 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2236, RFC:2236, QID:Q47483161
• D. Meyer (Jul 1998), Administratively Scoped IP Multicast (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2365, RFC:2365, QID:Q47477520
• S. Kent; R. Atkinson (Nov 1998), IP Authentication Header (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2402, RFC:2402, QID:Q47463063
• S. Kent; R. Atkinson (Nov 1998), IP Encapsulating Security Payload (ESP) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2406, RFC:2406, QID:Q47326996
• D. Maughan; M. Schertler; M. Schneider; J. Turner (Nov 1998), Internet Security Association and Key Management Protocol (ISAKMP) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2408, RFC:2408, QID:Q47392135
• R. Thayer (Nov 1998), IP Security Document Roadmap (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2411, RFC:2411, QID:Q47247332
• S. Deering; R. Hinden (Dec 1998), Internet Protocol, Version 6 (IPv6) Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2460, RFC:2460, QID:Q47467387
• F. Baker; D. Black (Dec 1998), 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
• S. Bradner (Mar 1999), Benchmarking Methodology for Network Interconnect Devices (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2544, RFC:2544, QID:Q47292716
• S. Bradner (Mar 2000), IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2780, RFC:2780, QID:Q47316870
• M. Handley; C. Perkins (Oct 2000), Session Announcement Protocol (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2974, RFC:2974, QID:Q47165174
• P. Srisuresh (Jan 2001), Traditional IP Network Address Translator (Traditional NAT) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3022, RFC:3022, QID:Q47466014
• C. Huitema (Jun 2001), An Anycast Prefix for 6to4 Relay Routers (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3068, RFC:3068, QID:Q47483414
• I. Miller (Jun 2001), Protection Against a Variant of the Tiny Fragment Attack (RFC 1858) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3128, RFC:3128, QID:Q47464125
• D. Meyer (Sep 2001), GLOP Addressing in 233/8 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3180, RFC:3180, QID:Q47245125
• S. Deering; B. Fenner (Oct 2002), Internet Group Management Protocol, Version 3 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3376, RFC:3376, QID:Q47459948
• P. Nesser; II; A. Bergstrom; P. Nesser, II (Jun 2004), Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3789, RFC:3789, QID:Q47483245
• B. Aboba; S. Cheshire (May 2005), Dynamic Configuration of IPv4 Link-Local Addresses (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3927, RFC:3927, QID:Q47471151
• E. Nordmark (Oct 2005), Basic Transition Mechanisms for IPv6 Hosts and Routers (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4213, RFC:4213, QID:Q47473418
• S. Deering; R. Hinden (Feb 2006), IP Version 6 Addressing Architecture (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4291, RFC:4291, QID:Q47470884
• H. Holbrook; B. Cain (Aug 2006), Source-Specific Multicast for IP (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4607, RFC:4607, QID:Q47456359
• T. Li (Aug 2006), Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4632, RFC:4632, QID:Q47485207
• B. Fenner (Nov 2006), Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4727, RFC:4727, QID:Q47466749
• W. Simpson; T. Narten; E. Nordmark (Sep 2007), Neighbor Discovery for IP version 6 (IPv6) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4861, RFC:4861, QID:Q47465975
• T. Narten (Sep 2007), IPv6 Stateless Address Autoconfiguration (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4862, RFC:4862, QID:Q47483181
• R. Housley; G. Huston (Aug 2013), The Internet Numbers Registry System (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7020, RFC:7020, QID:Q47463802
• J. Arkko (Jan 2010), IPv4 Address Blocks Reserved for Documentation (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC5737, RFC:5737, QID:Q47472778
• D. Meyer (Mar 2010), IANA Guidelines for IPv4 Multicast Address Assignments (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC5771, RFC:5771, QID:Q47211563
• S. Krishnan (Feb 2011), IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6071, RFC:6071, QID:Q47477352
• Y. Lee (Aug 2011), Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6333, RFC:6333, QID:Q47446395
• J. Weil; V. Kuarsingh; C. Donley; C. Liljenstolpe; M. Azinger (Apr 2012), IANA-Reserved IPv4 Prefix for Shared Address Space (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6598, RFC:6598, QID:Q47212673
• J. Touch (Feb 2013), Updated Specification of the IPv4 ID Field (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6864, RFC:6864, QID:Q47456644
• R. Bonica; B. Haberman (Apr 2013), Special-Purpose IP Address Registries (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6890, RFC:6890, QID:Q47462480
• R. Housley; G. Huston (Aug 2013), The Internet Numbers Registry System (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7020, RFC:7020, QID:Q47463802
• S. Deering; R. Hinden (Jul 2017), Internet Protocol, Version 6 (IPv6) Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC8200, RFC:8200, QID:Q47476951

وصلات خارجية

• صفحة الإصدار الرابع من بروتوكول الإنترنت في موقع tcpipguide.com.