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

بروتوكول الإنترنت الإصدار الرابع
مجموعة البروتوكولات
	حزمة IPv4
اختصار	بروتوكول الإنترنت الإصدار الرابع
غاية	بروتوكول الشبكات
المطور(ون)	داربا
مقدمة	1981 ؛ منذ 43 سنة
متأثر	بروتوكول الإنترنت الإصدار 6
طبقة OSI	طبقة الشبكة
طلبات التعليقات	791

بروتوكول الإنترنت الإصدار 4 ( IPv4 ) هو الإصدار الأول من بروتوكول الإنترنت (IP) كمواصفة مستقلة. وهو أحد البروتوكولات الأساسية لطرق الشبكات القائمة على المعايير في الإنترنت والشبكات الأخرى التي تعمل بالتبديل بالحزم . كان IPv4 هو الإصدار الأول الذي تم نشره للإنتاج على SATNET في عام 1982 وعلى ARPANET في يناير 1983. ولا يزال يستخدم لتوجيه معظم حركة الإنترنت اليوم، ^[1] حتى مع النشر المستمر لبروتوكول الإنترنت الإصدار 6 (IPv6)، ^[2] خليفته.

يستخدم IPv4 مساحة عنوان مكونة من 32 بتًا توفر 4,294,967,296 (2 ³² ) عنوانًا فريدًا، ولكن يتم حجز كتل كبيرة لأغراض الشبكات الخاصة. ^[3]^[4]

تاريخ

كانت الإصدارات السابقة من TCP/IP عبارة عن مواصفات مشتركة من خلال TCP/IPv3. ومع IPv4، أصبح بروتوكول الإنترنت مواصفات منفصلة. ^[5]

تم وصف إصدار بروتوكول الإنترنت الرابع في منشور IETF RFC 791 (سبتمبر 1981)، ليحل محل التعريف السابق الصادر في يناير 1980 (RFC 760). في مارس 1982، قررت وزارة الدفاع الأمريكية استخدام مجموعة بروتوكولات الإنترنت (TCP/IP) كمعيار لجميع شبكات الكمبيوتر العسكرية . ^[6]

غاية

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

IPv4 هو بروتوكول بدون اتصال ، ويعمل وفقًا لنموذج التسليم بأفضل جهد ، حيث لا يضمن التسليم، ولا يضمن التسلسل السليم أو تجنب التسليم المكرر. تتم معالجة هذه الجوانب، بما في ذلك سلامة البيانات، بواسطة بروتوكول نقل الطبقة العليا ، مثل بروتوكول التحكم في الإرسال (TCP).

معالجة

يستخدم IPv4 عناوين مكونة من 32 بت، مما يحد من مساحة العنوان إلى 4 294 967 296 (2 ³² ) عنوان.

يحتفظ IPv4 بكتل عناوين خاصة للشبكات الخاصة (2 ²⁴ + 2 ²⁰ + 2 ¹⁶ ≈ 18 مليون عنوان) وعناوين البث المتعدد (2 ²⁸ ≈ 268 مليون عنوان).

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

يمكن تمثيل عناوين IPv4 بأي صيغة تعبر عن قيمة عددية صحيحة مكونة من 32 بت. وغالبًا ما تُكتب هذه العناوين بالصيغة العشرية النقطية ، والتي تتكون من أربعة أوكتات من العنوان يتم التعبير عنها بشكل فردي بأرقام عشرية ويفصل بينها نقاط .

على سبيل المثال، يمثل عنوان IP ذو النقاط الرباعية في الرسم التوضيحي ( 172.16.254.1 ) الرقم العشري المكون من 32 بت 2886794753، والذي يكون في التنسيق السداسي عشر 0xAC10FE01.

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

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

توزيع

في التصميم الأصلي لـ IPv4، تم تقسيم عنوان IP إلى قسمين: معرف الشبكة هو الثماني بتات الأكثر أهمية في العنوان، ومعرف المضيف هو بقية العنوان. كان الأخير يسمى أيضًا حقل الباقي . سمح هذا الهيكل بحد أقصى 256 معرف شبكة، وهو ما تبين سريعًا أنه غير كافٍ.

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

بدأ تقسيم الشبكات الطبقية الموجودة إلى شبكات فرعية في عام 1985 بنشر RFC 950. أصبح هذا التقسيم أكثر مرونة مع تقديم أقنعة الشبكة الفرعية ذات الطول المتغير (VLSM) في RFC 1109 في عام 1987. في عام 1993، بناءً على هذا العمل، قدم RFC 1517 التوجيه بين النطاقات بدون فئات (CIDR)، ^[7] والذي عبر عن عدد البتات (من الأكثر أهمية ) على سبيل المثال، /24 ، وتم تسمية المخطط القائم على الفئة بالطبقي ، على النقيض من ذلك. تم تصميم CIDR للسماح بإعادة تقسيم أي مساحة عنوان بحيث يمكن تخصيص كتل أصغر أو أكبر من العناوين للمستخدمين. تتم إدارة الهيكل الهرمي الذي أنشأته CIDR بواسطة هيئة أرقام الإنترنت المخصصة (IANA) وسجلات الإنترنت الإقليمية (RIRs). تحتفظ كل RIR بقاعدة بيانات WHOIS قابلة للبحث العام توفر معلومات حول تعيينات عناوين IP.

عناوين الاستخدام الخاص

قامت مجموعة عمل هندسة الإنترنت (IETF) وIANA بتقييد استخدام عناوين IP المحجوزة المختلفة لأغراض خاصة. ^[4] ومن الجدير بالذكر أن هذه العناوين تُستخدم لحركة المرور المتعددة وتوفير مساحة عنونة للاستخدامات غير المقيدة على الشبكات الخاصة.

كتل العناوين الخاصة
كتلة العنوان	نطاق العنوان	عدد العناوين	نِطَاق	وصف
0.0.0.0/8	0.0.0.0–0.255.255.255	16 777 216	برمجة	الشبكة الحالية (المحلية، "هذه") ^[4]
10.0.0.0/8	10.0.0.0–10.255.255.255	16 777 216	شبكة خاصة	تستخدم للاتصالات المحلية داخل شبكة خاصة ^[8]
100.64.0.0/10	100.64.0.0–100.127.255.255	4 194 304	شبكة خاصة	مساحة عنوان مشتركة ^[9] للاتصالات بين مزود الخدمة ومشتركيه عند استخدام NAT من الدرجة الناقلة
127.0.0.0/8	127.0.0.0–127.255.255.255	16 777 216	يستضيف	تستخدم لعناوين الحلقة الراجعة إلى المضيف المحلي ^[4]
169.254.0.0/16	169.254.0.0–169.254.255.255	65 536	الشبكة الفرعية	تُستخدم لعناوين الارتباط المحلية ^[10] بين مضيفين على ارتباط واحد عندما لا يتم تحديد عنوان IP بخلاف ذلك، كما كان من الممكن استرداده عادةً من خادم DHCP
172.16.0.0/12	172.16.0.0–172.31.255.255	1 048 576	شبكة خاصة	تستخدم للاتصالات المحلية داخل شبكة خاصة ^[8]
192.0.0.0/24	192.0.0.0–192.0.0.255	256	شبكة خاصة	تعيينات بروتوكول IETF، DS-Lite (/29) ^[4]
192.0.2.0/24	192.0.2.0–192.0.2.255	256	التوثيق	تم تعيينه كـ TEST-NET-1، الوثائق والأمثلة ^[11]
192.88.99.0/24	192.88.99.0–192.88.99.255	256	إنترنت	محجوز. ^[12] كان يستخدم سابقًا لتتابع IPv6 إلى IPv4 ^[13] (يتضمن كتلة عنوان IPv6 2002::/16 ).
192.168.0.0/16	192.168.0.0–192.168.255.255	65 536	شبكة خاصة	تستخدم للاتصالات المحلية داخل شبكة خاصة ^[8]
198.18.0.0/15	198.18.0.0–198.19.255.255	131 072	شبكة خاصة	تستخدم لاختبار معايير الاتصالات بين الشبكات الفرعية المنفصلة ^[14]
198.51.100.0/24	198.51.100.0–198.51.100.255	256	التوثيق	تم تعيينه كـ TEST-NET-2، الوثائق والأمثلة ^[11]
203.0.113.0/24	203.0.113.0–203.0.113.255	256	التوثيق	تم تعيينه كـ TEST-NET-3، الوثائق والأمثلة ^[11]
224.0.0.0/4	224.0.0.0–239.255.255.255	268 435 456	إنترنت	قيد الاستخدام للبث المتعدد ^[15] (شبكة الفئة D السابقة)
233.252.0.0/24	233.252.0.0–233.252.0.255	256	التوثيق	تم تعيينه كـ MCAST-TEST-NET، الوثائق والأمثلة (لاحظ أن هذا جزء من مساحة البث المتعدد المذكورة أعلاه.) ^[15]^[16]
240.0.0.0/4	240.0.0.0–255.255.255.254	268 435 455	إنترنت	محجوز للاستخدام المستقبلي ^[17] (شبكة الفئة E السابقة)
255.255.255.255/32	255.255.255.255	1	الشبكة الفرعية	محجوز لعنوان الوجهة " البث المحدود " ^[4]

الشبكات الخاصة

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

نطاقات شبكة IPv4 الخاصة المحجوزة ^[8]
اسم	كتلة CIDR	نطاق العنوان	عدد العناوين	وصف فئوي
كتلة 24 بت	10.0.0.0/8	10.0.0.0 – 10.255.255.255	16 777 216	فئة واحدة أ
كتلة 20 بت	172.16.0.0/12	172.16.0.0 – 172.31.255.255	1 048 576	مجموعة متجاورة من 16 كتلة من الفئة ب
كتلة 16 بت	192.168.0.0/16	192.168.0.0 – 192.168.255.255	65 536	مجموعة متجاورة من 256 كتلة من الفئة C

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

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

يحدد RFC 3927 كتلة العنوان الخاصة 169.254.0.0/16 للتوجيه المحلي للارتباط. هذه العناوين صالحة فقط على الرابط (مثل جزء شبكة محلية أو اتصال من نقطة إلى نقطة) المتصل مباشرة بمضيف يستخدمها. هذه العناوين غير قابلة للتوجيه. مثل العناوين الخاصة، لا يمكن أن تكون هذه العناوين مصدرًا أو وجهة للحزم التي تمر عبر الإنترنت. تُستخدم هذه العناوين في المقام الأول للتكوين التلقائي للعناوين ( Zeroconf ) عندما لا يتمكن المضيف من الحصول على عنوان IP من خادم DHCP أو طرق التكوين الداخلية الأخرى.

عندما تم حجز كتلة العنوان، لم تكن هناك معايير موجودة للتكوين التلقائي للعناوين. أنشأت Microsoft تطبيقًا يسمى " العنونة التلقائية الخاصة لعناوين IP" (APIPA)، والذي تم نشره على ملايين الأجهزة وأصبح معيارًا بحكم الأمر الواقع . بعد سنوات عديدة، في مايو 2005، حددت IETF معيارًا رسميًا في RFC 3927، بعنوان " التكوين الديناميكي لعناوين IPv4 المحلية للارتباط" .

حلقة الرجوع

الشبكة من الفئة A 127.0.0.0 (الشبكة غير المصنفة 127.0.0.0 / 8 ) محجوزة للارتداد . لا ينبغي أبدًا أن تظهر حزم IP التي تنتمي عناوين مصدرها إلى هذه الشبكة خارج المضيف. يجب إسقاط الحزم المستلمة على واجهة غير ارتداد ذات عنوان مصدر أو وجهة ارتداد.

عناوين الشبكة الفرعية الأولى والأخيرة

يتم استخدام العنوان الأول في الشبكة الفرعية لتحديد الشبكة الفرعية نفسها. في هذا العنوان تكون جميع بتات المضيف 0. لتجنب الغموض في التمثيل، يتم حجز هذا العنوان. ^[18] يتم تعيين جميع بتات المضيف على العنوان الأخير على 1. يتم استخدامه كعنوان بث محلي لإرسال الرسائل إلى جميع الأجهزة الموجودة على الشبكة الفرعية في وقت واحد. بالنسبة للشبكات ذات الحجم / 24 أو أكبر، ينتهي عنوان البث دائمًا بالرقم 255.

على سبيل المثال، في الشبكة الفرعية 192.168.5.0 / 24 (قناع الشبكة الفرعية 255.255.255.0 )، يتم استخدام المعرف 192.168.5.0 للإشارة إلى الشبكة الفرعية بالكامل. عنوان البث للشبكة هو 192.168.5.255 .

يكتب	الشكل الثنائي	تدوين النقاط العشرية
مساحة الشبكة	`11000000.10101000.00000101.00000000`	192.168.5.0
عنوان البث	`11000000.10101000.00000101.11111111`	192.168.5.255
باللون الأحمر، يظهر جزء المضيف من عنوان IP؛ والجزء الآخر هو بادئة الشبكة. يتم عكس المضيف (NOT منطقيًا)، لكن بادئة الشبكة تظل سليمة.

ومع ذلك، لا يعني هذا أنه لا يمكن استخدام كل عنوان ينتهي بالرقم 0 أو 255 كعنوان مضيف. على سبيل المثال، في الشبكة الفرعية / 16 192.168.0.0 / 255.255.0.0 ، وهو ما يعادل نطاق العناوين 192.168.0.0 – 192.168.255.255 ، يكون عنوان البث هو 192.168.255.255 . ويمكن للمرء استخدام العناوين التالية للمضيفين، على الرغم من أنها تنتهي بالرقم 255: 192.168.1.255 ، 192.168.2.255 ، إلخ. كما أن 192.168.0.0 هو معرف الشبكة ولا يجب تعيينه لواجهة. ^[19]^{: 31} يمكن تخصيص العناوين 192.168.1.0 و 192.168.2.0 وما إلى ذلك، على الرغم من أنها تنتهي بالرقم 0.

في الماضي، نشأ الصراع بين عناوين الشبكة وعناوين البث لأن بعض البرامج تستخدم عناوين بث غير قياسية تحتوي على أصفار بدلاً من الواحدات. ^[19]^{: 66}

في الشبكات الأصغر من / 24 ، لا تنتهي عناوين البث بالضرورة بالرقم 255. على سبيل المثال، تحتوي شبكة فرعية CIDR 203.0.113.16 / 28 على عنوان البث 203.0.113.31 .

يكتب	الشكل الثنائي	تدوين النقاط العشرية
مساحة الشبكة	`11001011.00000000.01110001.00010000`	203.0.113.16
عنوان البث	`11001011.00000000.01110001.00011111`	203.0.113.31
باللون الأحمر، يظهر جزء المضيف من عنوان IP؛ والجزء الآخر هو بادئة الشبكة. يتم عكس المضيف (NOT منطقيًا)، لكن بادئة الشبكة تظل سليمة.

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

حل العنوان

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

يتم إجراء الترجمة بين العناوين وأسماء النطاقات بواسطة نظام اسم النطاق (DNS)، وهو نظام تسمية موزع هرمي يسمح بالتفويض الفرعي لمساحات الأسماء إلى خوادم DNS أخرى.

واجهة غير مرقمة

رابط نقطة إلى نقطة غير مرقم (PtP)، والذي يُسمى أيضًا رابط العبور، هو رابط ليس له رقم شبكة IP أو شبكة فرعية مرتبط به، ولكنه لا يزال لديه عنوان IP. تم تقديمه لأول مرة في عام 1993، ^[21]^[22]^[23]^[24] ويُنسب الفضل إلى فيل كارن من شركة كوالكوم باعتباره المصمم الأصلي.

الغرض من رابط العبور هو توجيه حزم البيانات . يتم استخدامها لتحرير عناوين IP من مساحة عنوان IP النادرة أو لتقليل إدارة تعيين IP وتكوين الواجهات. في السابق، كان كل رابط يحتاج إلى تخصيص شبكة فرعية / 31 أو / 30 باستخدام 2 أو 4 عناوين IP لكل رابط من نقطة إلى نقطة. عندما يكون الرابط غير مرقم، يتم استخدام معرف جهاز التوجيه ، وهو عنوان IP واحد مستعار من واجهة محددة (عادةً ما تكون loopback ). يمكن استخدام معرف جهاز التوجيه نفسه على واجهات متعددة.

أحد عيوب الواجهات غير المرقمة هو أنه من الصعب إجراء الاختبار والإدارة عن بعد.

استنفاد مساحة العنوان

في ثمانينيات القرن العشرين، أصبح من الواضح أن مجموعة عناوين IPv4 المتاحة كانت تستنفد بمعدل لم يكن متوقعًا في البداية في التصميم الأصلي للشبكة. ^[25] تضمنت قوى السوق الرئيسية التي أدت إلى تسريع استنفاد العناوين العدد المتزايد بسرعة من مستخدمي الإنترنت، الذين استخدموا بشكل متزايد أجهزة الحوسبة المحمولة، مثل أجهزة الكمبيوتر المحمولة ، والمساعدين الرقميين الشخصيين (PDAs)، والهواتف الذكية مع خدمات بيانات IP. بالإضافة إلى ذلك، كان الوصول إلى الإنترنت عالي السرعة يعتمد على الأجهزة التي تعمل دائمًا. حفز خطر الاستنزاف إدخال عدد من التقنيات العلاجية، مثل:

التوجيه بين المجالات بدون فئات (CIDR)، لتخصيصات مزودي خدمة الإنترنت الأصغر
لقد أدت الواجهات غير المرقمة إلى إزالة الحاجة إلى العناوين على روابط النقل.
لقد أزالت ترجمة عنوان الشبكة (NAT) الحاجة إلى مبدأ النهاية إلى النهاية .

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

تم استنفاد مجموعة العناوين الأساسية للإنترنت، التي تديرها IANA، في 3 فبراير 2011، عندما تم تخصيص آخر خمس كتل لسجلات الإنترنت الخمسة . ^[26]^{[27] كان} APNIC أول سجل إنترنت يستنفد مجموعته الإقليمية في 15 أبريل 2011، باستثناء كمية صغيرة من مساحة العناوين المخصصة لتقنيات الانتقال إلى IPv6، والتي سيتم تخصيصها بموجب سياسة مقيدة. ^[28]

كان الحل طويل الأمد لمعالجة الإرهاق هو مواصفات عام 1998 لإصدار جديد من بروتوكول الإنترنت، IPv6 . ^[29] فهو يوفر مساحة عناوين متزايدة بشكل كبير، ولكنه يسمح أيضًا بتجميع مسارات محسّن عبر الإنترنت، ويقدم تخصيصات كبيرة للشبكة الفرعية بحد أدنى 2 ⁶⁴ عنوان مضيف للمستخدمين النهائيين. ومع ذلك، فإن IPv4 غير متوافق بشكل مباشر مع IPv6، بحيث لا يمكن لمضيفي IPv4 فقط التواصل مباشرة مع مضيفي IPv6 فقط. مع التخلص التدريجي من شبكة 6bone التجريبية بدءًا من عام 2004، بدأ النشر الرسمي الدائم لـ IPv6 في عام 2006. ^[30] ومن المتوقع أن يستغرق استكمال نشر IPv6 وقتًا طويلاً، ^[31] بحيث تكون تقنيات الانتقال الوسيطة ضرورية للسماح للمضيفين بالمشاركة في الإنترنت باستخدام كلا الإصدارين من البروتوكول.

بنية الحزمة

تتكون حزمة IP من قسم رأس وقسم بيانات. لا تحتوي حزمة IP على مجموع اختباري للبيانات أو أي تذييل آخر بعد قسم البيانات. عادةً ما تقوم طبقة الارتباط بتغليف حزم IP في إطارات بتذييل CRC يكتشف معظم الأخطاء. تحتوي العديد من بروتوكولات طبقة النقل التي يحملها IP أيضًا على فحص الأخطاء الخاص بها. ^[32]^{: §6.2}

يتكون رأس حزمة IPv4 من 14 حقلاً، منها 13 حقلاً مطلوبًا. والحقل الرابع عشر اختياري ويُسمى بشكل مناسب: الخيارات. يتم تعبئة الحقول الموجودة في الرأس بالبايت الأكثر أهمية أولاً ( ترتيب بايتات الشبكة )، وبالنسبة للرسم التخطيطي والمناقشة، يتم اعتبار البتات الأكثر أهمية تأتي أولاً ( ترقيم بتات MSB 0 ). يتم ترقيم البت الأكثر أهمية بالرقم 0، وبالتالي يتم العثور على حقل الإصدار في الواقع في البتات الأربعة الأكثر أهمية في البايت الأول، على سبيل المثال.

تنسيق رأس IPv4
الإزاحة	ثماني بتات	0								1								2								3
ثماني بتات	قليل	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	الإصدار (4)				القانون الدولي الإنساني				دي إس بي سي						شبكة الاتصالات الإلكترونية		الطول الإجمالي
4	32	تعريف																الأعلام			إزاحة القطعة
8	64	الوقت للعيش								بروتوكول								مجموع التحقق من الرأس
12	96	عنوان المصدر
16	128	عنوان الوجهة
20	160	(الخيارات) (إذا كان IHL > 5)
⋮	⋮
56	448

الإصدار : 4 بت

حقل الرأس الأول في حزمة IP هو حقل الإصدار . بالنسبة لـ IPv4، يكون هذا دائمًا مساويًا لـ 4 .

طول رأس الإنترنت (IHL): 4 بت

رأس IPv4 متغير الحجم بسبب الحقل الاختياري الرابع عشر ( الخيارات ). يحتوي حقل IHL على حجم رأس IPv4؛ فهو يحتوي على 4 بتات تحدد عدد الكلمات المكونة من 32 بت في الرأس. القيمة الدنيا لهذا الحقل هي 5، ^[33] مما يشير إلى طول 5 × 32 بت = 160 بت = 20 بايت. كحقل مكون من 4 بتات، تكون القيمة القصوى 15؛ وهذا يعني أن الحد الأقصى لحجم رأس IPv4 هو 15 × 32 بت = 480 بت = 60 بايت.

نقطة رمز الخدمات المتميزة (DSCP ): 6 بت

تم تعريف هذا الحقل في الأصل على أنه نوع الخدمة (ToS)، وهو يحدد الخدمات المتمايزة (DiffServ). ^[34] يستخدم تدفق البيانات في الوقت الفعلي حقل DSCP. ومن الأمثلة على ذلك Voice over IP (VoIP)، والذي يستخدم للخدمات الصوتية التفاعلية.

إشعار صريح بالازدحام (ECN ): 2 بت

يسمح هذا المجال بإرسال إشعارات شاملة حول ازدحام الشبكة دون إسقاط الحزم . ^[35] ECN هي ميزة اختيارية متاحة عندما تدعمها كلتا النقطتين النهائيتين وتكون فعالة عندما تدعمها أيضًا الشبكة الأساسية.

الطول الإجمالي : 16 بت

يحدد هذا الحقل المكون من 16 بت حجم الحزمة بالكامل بالبايتات، بما في ذلك الرأس والبيانات. الحد الأدنى للحجم هو 20 بايت (الرأس بدون بيانات) والحد الأقصى هو 65535 بايت. يجب أن تكون جميع المضيفات قادرة على إعادة تجميع حزم البيانات التي يصل حجمها إلى 576 بايت، ولكن معظم المضيفات الحديثة تتعامل مع حزم أكبر بكثير. قد تفرض الروابط قيودًا إضافية على حجم الحزمة، وفي هذه الحالة يجب تجزئة حزم البيانات . يتم إجراء التجزئة في IPv4 إما في المضيف المرسل أو في أجهزة التوجيه. تتم إعادة التجميع في المضيف المستقبل.

التعريف : 16 بت

هذا الحقل هو حقل تعريف ويستخدم في المقام الأول لتحديد مجموعة من أجزاء برقية IP واحدة بشكل فريد. اقترحت بعض الأعمال التجريبية استخدام حقل التعريف لأغراض أخرى، مثل إضافة معلومات تتبع الحزم للمساعدة في تتبع برقيات البيانات التي تحتوي على عناوين مصدر مزيفة، ^[36] ولكن أي استخدام من هذا القبيل محظور الآن. ^[37]

الأعلام: 3 بت

هناك ثلاثة أعلام محددة داخل هذا المجال.

محجوز (R): 1 بت: محجوز. يجب ضبطه على 0. ^[أ]
لا تجزئ (DF): 1 بت: يحدد هذا الحقل ما إذا كان يمكن تجزئة حزمة البيانات أم لا. ويمكن استخدام هذا الحقل عند إرسال الحزم إلى مضيف ليس لديه الموارد اللازمة لإعادة تجميع الحزم. ويمكن استخدامه أيضًا لاكتشاف MTU للمسار ، إما تلقائيًا بواسطة برنامج IP للمضيف، أو يدويًا باستخدام أدوات التشخيص مثل ping أو traceroute . إذا تم تعيين علامة DF، وكانت التجزئة مطلوبة لتوجيه الحزمة، فسيتم إسقاط الحزمة.
المزيد من الشظايا (MF): 1 بت: بالنسبة للحزم غير المجزأة، يتم مسح علامة MF. بالنسبة للحزم المجزأة، يتم تعيين علامة MF على جميع الشظايا باستثناء الأخيرة. تحتوي الشظية الأخيرة على حقل إزاحة شظية غير صفري ، لذا لا يزال من الممكن تمييزها عن الحزمة غير المجزأة.

إزاحة القطعة : 13 بت: يحدد هذا الحقل إزاحة جزء معين بالنسبة لبداية برقية IP الأصلية غير المجزأة. يتم تحديد الأجزاء بوحدات 8 بايت، ولهذا السبب تكون أطوال الأجزاء دائمًا مضاعفات لـ 8؛ باستثناء الجزء الأخير، الذي قد يكون أصغر. ^[39]
تكون قيمة إزاحة التجزئة للجزء الأول دائمًا 0. يبلغ عرض الحقل 13 بتًا، لذا تتراوح قيمة الإزاحة من 0 إلى 8191 (من (2 ⁰ – 1) إلى (2 ¹³ – 1)). لذلك، يسمح بإزاحة جزء قصوى تبلغ (2 ¹³ – 1) × 8 = 65528 بايت، مع تضمين طول الرأس (65528 + 20 = 65548 بايت)، مما يدعم تجزئة الحزم التي تتجاوز الحد الأقصى لطول IP وهو 65535 بايت.
الوقت للعيش (TTL ): 8 بت: يحدد حقل وقت البقاء عمر حزمة البيانات لمنع فشل الشبكة في حالة حدوث حلقة توجيه . يتم تحديده بالثواني، ولكن يتم تقريب الفترات الزمنية التي تقل عن ثانية واحدة إلى 1. في الممارسة العملية، يتم استخدام الحقل كعدد للقفزات - عندما تصل حزمة البيانات إلى جهاز التوجيه ، يقوم جهاز التوجيه بتقليل حقل TTL بمقدار واحد. عندما يصل حقل TTL إلى الصفر، يتجاهل جهاز التوجيه الحزمة ويرسل عادةً رسالة تجاوز وقت ICMP إلى المرسل.; يرسل برنامج traceroute رسائل تحتوي على قيم TTL معدلة ويستخدم رسائل تجاوز وقت ICMP هذه لتحديد أجهزة التوجيه التي عبرتها الحزم من المصدر إلى الوجهة.
البروتوكول : 8 بت: يحدد هذا الحقل بروتوكول طبقة النقل المستخدم في جزء البيانات من مخطط بيانات IP. يتم صيانة قائمة أرقام بروتوكول IP بواسطة هيئة أرقام الإنترنت المخصصة (IANA). ^[17]; تتضمن بعض بروتوكولات الحمولة الشائعة ما يلي:

رقم البروتوكول	اسم البروتوكول	اختصار
1	بروتوكول رسائل التحكم في الإنترنت	بروتوكول الإنترنت لمكافحة مرض التصلب العصبي المتعدد
2	بروتوكول إدارة مجموعة الإنترنت	بروتوكول الإنترنت العالمي للشبكات
6	بروتوكول التحكم في الإرسال	بروتوكول التحكم في الإرسال
17	بروتوكول بيانات المستخدم	بروتوكول بيانات المستخدم
41	تغليف IPv6	إنكاب
89	افتح المسار الأقصر أولاً	بروتوكول OSPF
132	بروتوكول نقل التحكم في التدفق	مركز مراقبة الجودة

مجموع التحقق من الرأس : 16 بت: يتم استخدام حقل المجموع الاختباري لرأس IPv4 للتحقق من أخطاء الرأس. قبل إرسال الحزمة، يتم حساب المجموع الاختباري باعتباره مكملًا واحدًا مكونًا من 16 بتًا لمجموع مكمل واحد لجميع الكلمات المكونة من 16 بتًا في الرأس. يتضمن هذا حقل المجموع الاختباري للرأس نفسه، والذي يتم تعيينه على صفر أثناء الحساب. يتم إرسال الحزمة مع المجموع الاختباري للرأس الذي يحتوي على القيمة الناتجة. عندما تصل الحزمة إلى جهاز توجيه أو وجهتها، يعيد جهاز الشبكة حساب قيمة المجموع الاختباري للرأس، بما في ذلك الآن حقل المجموع الاختباري للرأس . يجب أن تكون النتيجة صفرًا؛ إذا تم الحصول على نتيجة مختلفة، يتجاهل الجهاز الحزمة.; عندما تصل حزمة إلى جهاز التوجيه، يقوم جهاز التوجيه بتقليص حقل TTL في الرأس. وبالتالي، يجب على جهاز التوجيه حساب مجموع اختباري جديد للرأس قبل إرسالها مرة أخرى.; يتم التعامل مع الأخطاء في جزء البيانات من الحزمة بشكل منفصل بواسطة البروتوكول المغلف. يحتوي كل من UDP و TCP على مجموعات اختبار منفصلة تنطبق على بياناتهما.
عنوان المصدر : 32 بت: يحتوي هذا الحقل على عنوان IPv4 لمرسل الحزمة. ويمكن تغييره أثناء النقل عن طريق ترجمة عنوان الشبكة (NAT).
عنوان الوجهة : 32 بت: يحتوي هذا الحقل على عنوان IPv4 للمستقبل المقصود للحزمة. وقد يتأثر أيضًا بـ NAT.; إذا كان من الممكن الوصول إلى الوجهة مباشرةً، فسيتم تسليم الحزمة بواسطة طبقة الارتباط الأساسية ، بمساعدة ARP . إذا لم يكن الأمر كذلك، فستحتاج الحزمة إلى التوجيه وسيتم تسليمها إلى عنوان البوابة بدلاً من ذلك.
الخيارات : 0 - 320 بت، مبطنة بمضاعفات 32 بت: لا يتم استخدام حقل الخيارات كثيرًا. قد تعتبر بعض أجهزة التوجيه الحزم التي تحتوي على بعض الخيارات خطيرة وقد يتم حظرها. ^[40] يجب أن تتضمن القيمة في حقل IHL عددًا كافيًا من الكلمات الإضافية المكونة من 32 بت لاحتواء جميع الخيارات وأي حشو مطلوب لضمان احتواء الرأس على عدد صحيح من الكلمات المكونة من 32 بت. إذا كانت قيمة IHL أكبر من 5 (أي أنها من 6 إلى 15) فهذا يعني أن حقل الخيارات موجود ويجب أخذه في الاعتبار. يمكن إنهاء قائمة الخيارات بالخيار EOOL (نهاية قائمة الخيارات، 0x00)؛ وهذا ضروري فقط إذا كانت نهاية الخيارات لن تتطابق مع نهاية الرأس.; نظرًا لأن معظم خيارات IP تتضمن مواصفات حول عدد الأجهزة الوسيطة التي يجب أن تمر بها الحزمة أو أي منها، فإن خيارات IP لا تُستخدم للاتصال عبر الإنترنت ويجب إسقاط حزم IP التي تتضمن بعض خيارات IP، ^[41]^{: §3.13} لأنها يمكن أن تكشف عن طوبولوجيا الشبكة أو تفاصيل الشبكة.

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

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

على النقيض من ذلك، لا يسمح IPv6 ، الجيل التالي من بروتوكول الإنترنت، لأجهزة التوجيه بإجراء التجزئة؛ يجب على المضيفين إجراء Path MTU Discovery قبل إرسال البيانات.

التفتت

عندما يستقبل جهاز التوجيه حزمة، فإنه يفحص عنوان الوجهة ويحدد الواجهة الصادرة التي سيتم استخدامها وMTU الخاصة بهذه الواجهة. إذا كان حجم الحزمة أكبر من MTU، وتم تعيين بت عدم التجزئة (DF) في رأس الحزمة على 0، فقد يقوم جهاز التوجيه بتجزئة الحزمة.

يقوم جهاز التوجيه بتقسيم الحزمة إلى أجزاء. ويكون الحجم الأقصى لكل جزء هو وحدة نقل البيانات القصوى الصادرة مطروحًا منها حجم رأس IP (20 بايت كحد أدنى؛ 60 بايت كحد أقصى). ويضع جهاز التوجيه كل جزء في الحزمة الخاصة به، حيث تحتوي كل حزمة من الأجزاء على التغييرات التالية:

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

على سبيل المثال، بالنسبة لوحدة نقل بيانات قصوى تبلغ 1500 بايت وحجم رأس يبلغ 20 بايت، فإن إزاحات الشظايا ستكون مضاعفات (0، 185، 370، 555، 740، وما إلى ذلك). ${\frac {1{,}500-20}{8}}=185$

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

قطعة	الحجم (بايت)	حجم الرأس (بايت)	حجم البيانات (بايت)	العلم المزيد من الشظايا	إزاحة القطعة (كتل مكونة من 8 بايتات)
1	2,500	20	2,480	1	0
2	2,040	20	2,020	0	310

يتم الحفاظ على حجم البيانات الإجمالي: 2,480 بايت + 2,020 بايت = 4,500 بايت. الإزاحات هي و . $0$ ${\frac {0+2{,}480}{8}}=310$

عند إعادة التوجيه إلى رابط يحتوي على MTU يبلغ 1500 بايت، يتم تجزئة كل جزء إلى جزءين:

قطعة	الحجم (بايت)	حجم الرأس (بايت)	حجم البيانات (بايت)	العلم المزيد من الشظايا	إزاحة القطعة (كتل مكونة من 8 بايتات)
1	1500	20	1,480	1	0
2	1,020	20	1000	1	185
3	1500	20	1,480	1	310
4	560	20	540	0	495

مرة أخرى، يتم الحفاظ على حجم البيانات: 1,480 + 1,000 = 2,480، و1,480 + 540 = 2,020.

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

يتم استخدام الإزاحة الأخيرة وحجم البيانات الأخير لحساب الحجم الإجمالي للبيانات: . $495\times 8+540=3{,}960+540=4{,}500$

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

يعرف المستقبل أن الحزمة عبارة عن جزء، إذا كان أحد الشروط التالية على الأقل صحيحًا:

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

يقوم المستقبل بتحديد القطع المتطابقة باستخدام عناوين المصدر والوجهة ومعرف البروتوكول وحقل التعريف. يقوم المستقبل بإعادة تجميع البيانات من القطع التي لها نفس المعرف باستخدام كل من إزاحة القطعة وعلم المزيد من القطع. عندما يستقبل المستقبل القطعة الأخيرة، والتي تم تعيين علم المزيد من القطع عليها إلى 0، يمكنه حساب حجم الحمولة الأصلية للبيانات، عن طريق ضرب إزاحة القطعة الأخيرة بثمانية وإضافة حجم بيانات القطعة الأخيرة. في المثال المعطى، كان هذا الحساب بايت. عندما يكون لدى المستقبل كل القطع، يمكن إعادة تجميعها بالترتيب الصحيح وفقًا للإزاحات لتشكيل البيانات الأصلية. $495\times 8+540=4{,}500$

البروتوكولات المساعدة

لا ترتبط عناوين IP بأي شكل دائم بأجهزة الشبكات، وفي الواقع، في أنظمة التشغيل الحديثة ، يمكن أن تحتوي واجهة الشبكة على عناوين IP متعددة. من أجل توصيل حزمة IP بشكل صحيح إلى المضيف الوجهة على رابط، تحتاج المضيفات وأجهزة التوجيه إلى آليات إضافية لإنشاء ارتباط بين عنوان الأجهزة ^[b] لواجهات الشبكة وعناوين IP. يقوم بروتوكول تحليل العنوان (ARP) بإجراء هذه الترجمة من عنوان IP إلى عنوان الأجهزة لـ IPv4. بالإضافة إلى ذلك، غالبًا ما يكون الارتباط العكسي ضروريًا. على سبيل المثال، ما لم يتم تكوين عنوان مسبقًا بواسطة مسؤول، عند تشغيل مضيف IP أو توصيله بشبكة، فإنه يحتاج إلى تحديد عنوان IP الخاص به. تتضمن البروتوكولات لمثل هذه الارتباطات العكسية بروتوكول تكوين المضيف الديناميكي (DHCP) وبروتوكول التمهيد (BOOTP) ونادرًا ما يكون بروتوكول تحليل العنوان العكسي (ARP ).

انظر أيضا

ملحوظات

^ كنكتة يوم كذبة أبريل ، تم اقتراح استخدامها في RFC 3514 باعتبارها " البت الشرير " ^[38]
^ بالنسبة لتقنيات الشبكات IEEE 802 ، بما في ذلك Ethernet ، فإن عنوان الأجهزة هو عنوان MAC .

مراجع

تم تعديل هذه المقالة من المصدر التالي بموجب ترخيص CC BY 4.0 (2022): ميشيل بقني؛ ساندرا هانبو (9 ديسمبر 2022). "مسح حول بروتوكول الإنترنت الإصدار 4 (IPv4)" (PDF) . ويكي مجلة العلوم . دوى : 10.15347/WJS/2022.002 . ISSN 2470-6345. OCLC 9708517136. S2CID 254665961. ويكي بيانات Q104661268.

^ "تقارير تحليل BGP". تقارير BGP . تم الاسترجاع في 2013-01-09 .
^ "IPv6 – Google". www.google.com . تم الاسترجاع في 2022-01-28 .
^ "سجل عناوين IANA IPv4 للأغراض الخاصة". www.iana.org . تم الاسترجاع في 2022-01-28 .
^ abcdef M. Cotton; L. Vegoda; B. Haberman (أبريل 2013). R. Bonica (محرر). سجلات عناوين IP للأغراض الخاصة. IETF . doi : 10.17487/RFC6890 . ISSN 2070-1721. BCP 153. RFC 6890. أفضل الممارسات الحالية 153. تجعل RFC 4773 و5156 و5735 و5736 غير صالحة للاستخدام. تم تحديثها بواسطة RFC 8190.
^ ديفيس، ليديا. "فينت سيرف - لا يزال أمامنا 80 في المائة من العالم للاتصال". نيويورك تايمز . تم الاسترجاع في 2024-05-10 .
^ "تاريخ موجز لـ IPv4". مجموعة سوق IPv4 . تم الاسترجاع في 2020-08-19 .
^ "فهم عناوين IP: كل ما تريد معرفته" (PDF) . 3Com. مؤرشف من الأصل (PDF) في 16 يونيو 2001.
^ abcd Y. Rekhter ؛ B. Moskowitz؛ D. Karrenberg؛ GJ de Groot؛ E. Lear (فبراير 1996). تخصيص العناوين للإنترنت الخاصة. مجموعة عمل الشبكة. doi : 10.17487/RFC1918 . BCP 5. RFC 1918. أفضل الممارسات الحالية 5. إلغاء RFC 1627 و1597. تم تحديثه بواسطة RFC 6761.
^ J. Weil; V. Kuarsingh; C. Donley; C. Liljenstolpe; M. Azinger (أبريل 2012). بادئة IPv4 المحجوزة من IANA لمساحة العناوين المشتركة. فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6598 . ISSN 2070-1721. BCP 153. RFC 6598. أفضل الممارسات الشائعة. تحديثات RFC 5735.
^ S. Cheshire ؛ B. Aboba؛ E. Guttman (مايو 2005). التكوين الديناميكي لعناوين IPv4 المحلية. مجموعة عمل الشبكة. doi : 10.17487/RFC3927 . RFC 3927. المعيار المقترح.
^ abc J. Arkko; M. Cotton; L. Vegoda (يناير 2010). IPv4 Address Blocks Reserved for Documentation. Internet Engineering Task Force . doi : 10.17487/RFC5737 . ISSN 2070-1721. RFC 5737. إعلامي. تحديثات RFC 1166.
^ O. Troan (مايو 2015). B. Carpenter (محرر). إلغاء بادئة Anycast لأجهزة توجيه 6to4 Relay. فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7526 . BCP 196. RFC 7526. أفضل الممارسات الحالية. يجعل RFC 3068 و6732 غير صالحين .
^ C. Huitema (يونيو 2001). بادئة Anycast لموجهات التتابع 6to4. مجموعة عمل الشبكة. doi : 10.17487/RFC3068 . RFC 3068. إعلامي. تم إلغاؤه بموجب RFC 7526.
^ S. Bradner; J. McQuaid (مارس 1999). منهجية المقارنة المعيارية لأجهزة الربط الشبكي. مجموعة عمل الشبكة. doi : 10.17487/RFC2544 . RFC 2544. إعلامي. تم التحديث بواسطة: RFC 6201 و RFC 6815.
^ ab M. Cotton; L. Vegoda; D. Meyer (مارس 2010). إرشادات IANA لتعيينات عناوين البث المتعدد IPv4. IETF . doi : 10.17487/RFC5771 . ISSN 2070-1721. BCP 51. RFC 5771. أفضل الممارسات الحالية 51. يجعل RFC 3138 و3171 غير صالحين. ويقوم بتحديث RFC 2780.
^ S. Venaas؛ R. Parekh؛ G. Van de Velde؛ T. Chown؛ M. Eubanks (أغسطس 2012). عناوين البث المتعدد للتوثيق. فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6676 . ISSN 2070-1721. RFC 6676. إعلامية.
^ ab J. Reynolds , ed. (يناير 2002). Assigned Numbers: RFC 1700 is Replaced by an On-line Database. Network Working Group. doi : 10.17487/RFC3232 . RFC 3232. إعلامي. يجعل RFC 1700 قديمًا .
^ J. Reynolds ؛ J. Postel (أكتوبر 1984). الأرقام المخصصة. مجموعة عمل الشبكة. doi : 10.17487/RFC0923 . RFC 923. عفا عليها الزمن. عفا عليها الزمن بموجب RFC 943. عفا عليها الزمن بموجب RFC 900. العناوين الخاصة: في سياقات معينة، من المفيد أن يكون لدينا عناوين ثابتة ذات أهمية وظيفية بدلاً من كونها معرفات لمضيفين محددين. عندما يكون هذا الاستخدام مطلوبًا، يجب تفسير العنوان صفر بمعنى "هذا"، كما في "هذه الشبكة".
^ ab R. Braden ، محرر (أكتوبر 1989). متطلبات مضيفات الإنترنت - طبقات الاتصال. مجموعة عمل الشبكة. doi : 10.17487/RFC1122 . STD 3. RFC 1122. معيار الإنترنت 3. تم تحديثه بواسطة RFC 1349، 4379، 5884، 6093، 6298، 6633، 6864، 8029 و9293.
^ A. Retana; R. White; V. Fuller; D. McPherson (ديسمبر 2000). استخدام بادئات 31 بت في روابط نقطة إلى نقطة IPv4. مجموعة عمل الشبكة. doi : 10.17487/RFC3021 . RFC 3021. المعيار المقترح.
^ Almquist, Philip; Kastenholz, Frank (December 1993). "نحو متطلبات أجهزة توجيه IP". فريق عمل هندسة الإنترنت .
^ P. Almquist (نوفمبر 1994). F. Kastenholz (محرر). نحو متطلبات أجهزة توجيه IP. مجموعة عمل الشبكة. doi : 10.17487/RFC1716 . RFC 1716. عفا عليها الزمن. تم إلغاؤه بموجب RFC 1812.
^ F. Baker ، محرر (يونيو 1995). متطلبات أجهزة توجيه IP الإصدار 4. مجموعة عمل الشبكة. doi : 10.17487/RFC1812 . RFC 1812. المعيار المقترح. يصبح قديمًا RFC 1716 و1009. تم تحديثه بواسطة RFC 2644 و6633.
^ "فهم وتكوين أمر IP غير المرقم". Cisco . تم الاسترجاع في 2021-11-25 .
^ "العالم ينفد من عناوين الإنترنت". مؤرشف من الأصل في 2011-01-25 . تم الاسترجاع في 2011-01-23 .
^ سميث، لوسي؛ ليبنر، إيان (3 فبراير 2011). "استنزاف مساحة عناوين IPv4 المجانية". منظمة موارد الأرقام . تم الاسترجاع في 3 فبراير 2011 .
^ ICANN، قائمة بريدية nanog. "خمسة /8s مخصصة لـ RIRs - لا يوجد /8s أحادية البث IPv4 غير مخصصة متبقية".
^ مركز معلومات شبكة آسيا والمحيط الهادئ (15 أبريل 2011). "APNIC IPv4 Address Pool Reaches Final /8". مؤرشف من الأصل في 7 أغسطس 2011. تم الاسترجاع في 15 أبريل 2011 .
^ S. Deering ؛ R. Hinden (ديسمبر 1998). مواصفات بروتوكول الإنترنت، الإصدار 6 (IPv6). مجموعة عمل الشبكة. doi : 10.17487/RFC2460 . RFC 2460. عفا عليها الزمن. تم إلغاؤه بموجب RFC 8200. أصبح عفا عليه الزمن بموجب RFC 1883. تم تحديثه بموجب RFC 5095 و5722 و5871 و6437 و6564 و6935 و6946 و7045 و7112.
^ R. Fink; R. Hinden (مارس 2004). 6bone (اختبار تخصيص عنوان IPv6) Phaseout. Network Working Group. doi : 10.17487/RFC3701 . RFC 3701. إعلامي. يجعل RFC 2471 قديمًا .
^ مؤتمر معهد مهندسي الكهرباء والإلكترونيات الدولي لعام 2016 حول التقنيات الناشئة وممارسات الأعمال المبتكرة لتحويل المجتمعات (EmergiTech) . بيسكاتاواي، نيوجيرسي: جامعة التكنولوجيا، موريشيوس، معهد مهندسي الكهرباء والإلكترونيات. أغسطس 2016. ISBN 9781509007066. OCLC 972636788.
^ C. Partridge; F. Kastenholz (ديسمبر 1994). المعايير الفنية لاختيار بروتوكول الإنترنت الجيل التالي (IPng). مجموعة عمل الشبكة. doi : 10.17487/RFC1726 . RFC 1726. إعلامية.
^ J. Postel ، محرر (سبتمبر 1981). بروتوكول الإنترنت - مواصفات بروتوكول برنامج الإنترنت التابع لوكالة مشاريع الأبحاث الدفاعية المتقدمة. IETF . doi : 10.17487/RFC0791 . STD 5. RFC 791. IEN 128, 123, 111, 80, 54, 44, 41, 28, 26. معيار الإنترنت 5. يصبح RFC 760 قديمًا. تم تحديثه بواسطة RFC 1349 و2474 و6864.
^ K. Nichols; S. Blake; F. Baker ; D. Black (ديسمبر 1998). تعريف مجال الخدمات المتباينة (DS Field) في عناوين IPv4 وIPv6. مجموعة عمل الشبكة. doi : 10.17487/RFC2474 . RFC 2474. المعيار المقترح. يصبح RFC 1455 و1349 قديمين. تم تحديثه بواسطة RFC 3168 و3260 و8436.
^ K. Ramakrishnan; S. Floyd; D. Black (سبتمبر 2001). إضافة إشعار الازدحام الصريح (ECN) إلى IP. مجموعة عمل الشبكة. doi : 10.17487/RFC3168 . RFC 3168. المعيار المقترح. يلغي RFC 2481. ويحدث RFC 2474 و2401 و793. ويحدث بواسطة RFC 4301 و6040 و8311.
^ Savage, Stefan (2000). "Practical network support for IP traceback". ACM SIGCOMM Computer Communication Review . 30 (4): 295–306. doi : 10.1145/347057.347560 .
^ J. Touch (فبراير 2013). مواصفات محدثة لحقل معرف IPv4. IETF . doi : 10.17487/RFC6864 . ISSN 2070-1721. RFC 6864. المعيار المقترح. تحديثات RFC 791 و1122 و2003.
^ S. Bellovin (1 أبريل 2003). علم الأمان في رأس IPv4. مجموعة عمل الشبكة. doi : 10.17487/RFC3514 . RFC 3514. إعلامي. هذا طلب للتعليقات في يوم كذبة أبريل .
^ Bhardwaj, Rashmi (2020-06-04). "Fragment Offset - IP With Ease". ipwithease.com . تم الاسترجاع في 2022-11-21 .
^ "أسئلة شائعة غير رسمية حول شركة سيسكو" . تم الاسترجاع في 10 مايو 2012 .
^ F. Gont (يوليو 2011). تقييم أمان بروتوكول الإنترنت الإصدار 4. فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6274 . ISSN 2070-1721. RFC 6274. إعلامية.

روابط خارجية

هيئة أرقام الإنترنت المخصصة (IANA)
IP، بروتوكول الإنترنت محفوظ في 2011-05-14 على موقع Wayback Machine — تفاصيل عنوان IP، بما في ذلك الخيارات المحددة
C. Perkins، محرر (نوفمبر 2010). دعم التنقل عبر بروتوكول الإنترنت لبروتوكول الإنترنت الإصدار الرابع، منقح. فريق عمل هندسة الإنترنت . doi : 10.17487/RFC5944 . ISSN 2070-1721. RFC 5944. المعيار المقترح يلغي الحاجة إلى RFC 3344.
الحالة الرسمية الحالية لتخصيصات IPv4/8، كما تحتفظ بها IANA

Original text

Rate this translation

Your feedback will be used to help improve Google Translate

[39] كنكتة يوم كذبة أبريل ، تم اقتراح استخدامها في RFC 3514 باعتبارها " البت الشرير " ^[38]

[43] بالنسبة لتقنيات الشبكات IEEE 802 ، بما في ذلك Ethernet ، فإن عنوان الأجهزة هو عنوان MAC .

[:0-1] "تقارير تحليل BGP". تقارير BGP . تم الاسترجاع في 2013-01-09 .

[2] "IPv6 – Google". www.google.com . تم الاسترجاع في 2022-01-28 .

[3] "سجل عناوين IANA IPv4 للأغراض الخاصة". www.iana.org . تم الاسترجاع في 2022-01-28 .

[rfc6890-4] M. Cotton; L. Vegoda; B. Haberman (أبريل 2013). R. Bonica (محرر). سجلات عناوين IP للأغراض الخاصة. IETF . doi : 10.17487/RFC6890 . ISSN 2070-1721. BCP 153. RFC 6890. أفضل الممارسات الحالية 153. تجعل RFC 4773 و5156 و5735 و5736 غير صالحة للاستخدام. تم تحديثها بواسطة RFC 8190.

[5] ديفيس، ليديا. "فينت سيرف - لا يزال أمامنا 80 في المائة من العالم للاتصال". نيويورك تايمز . تم الاسترجاع في 2024-05-10 .

[6] "تاريخ موجز لـ IPv4". مجموعة سوق IPv4 . تم الاسترجاع في 2020-08-19 .

[7] "فهم عناوين IP: كل ما تريد معرفته" (PDF) . 3Com. مؤرشف من الأصل (PDF) في 16 يونيو 2001.

[rfc1918-8] Y. Rekhter ؛ B. Moskowitz؛ D. Karrenberg؛ GJ de Groot؛ E. Lear (فبراير 1996). تخصيص العناوين للإنترنت الخاصة. مجموعة عمل الشبكة. doi : 10.17487/RFC1918 . BCP 5. RFC 1918. أفضل الممارسات الحالية 5. إلغاء RFC 1627 و1597. تم تحديثه بواسطة RFC 6761.

[rfc6598-9] J. Weil; V. Kuarsingh; C. Donley; C. Liljenstolpe; M. Azinger (أبريل 2012). بادئة IPv4 المحجوزة من IANA لمساحة العناوين المشتركة. فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6598 . ISSN 2070-1721. BCP 153. RFC 6598. أفضل الممارسات الشائعة. تحديثات RFC 5735.

[rfc3927-10] S. Cheshire ؛ B. Aboba؛ E. Guttman (مايو 2005). التكوين الديناميكي لعناوين IPv4 المحلية. مجموعة عمل الشبكة. doi : 10.17487/RFC3927 . RFC 3927. المعيار المقترح.

[rfc5737-11] J. Arkko; M. Cotton; L. Vegoda (يناير 2010). IPv4 Address Blocks Reserved for Documentation. Internet Engineering Task Force . doi : 10.17487/RFC5737 . ISSN 2070-1721. RFC 5737. إعلامي. تحديثات RFC 1166.

[rfc7526-12] O. Troan (مايو 2015). B. Carpenter (محرر). إلغاء بادئة Anycast لأجهزة توجيه 6to4 Relay. فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7526 . BCP 196. RFC 7526. أفضل الممارسات الحالية. يجعل RFC 3068 و6732 غير صالحين .

[rfc3068-13] C. Huitema (يونيو 2001). بادئة Anycast لموجهات التتابع 6to4. مجموعة عمل الشبكة. doi : 10.17487/RFC3068 . RFC 3068. إعلامي. تم إلغاؤه بموجب RFC 7526.

[rfc2544-14] S. Bradner; J. McQuaid (مارس 1999). منهجية المقارنة المعيارية لأجهزة الربط الشبكي. مجموعة عمل الشبكة. doi : 10.17487/RFC2544 . RFC 2544. إعلامي. تم التحديث بواسطة: RFC 6201 و RFC 6815.

[rfc5771-15] M. Cotton; L. Vegoda; D. Meyer (مارس 2010). إرشادات IANA لتعيينات عناوين البث المتعدد IPv4. IETF . doi : 10.17487/RFC5771 . ISSN 2070-1721. BCP 51. RFC 5771. أفضل الممارسات الحالية 51. يجعل RFC 3138 و3171 غير صالحين. ويقوم بتحديث RFC 2780.

[rfc6676-16] S. Venaas؛ R. Parekh؛ G. Van de Velde؛ T. Chown؛ M. Eubanks (أغسطس 2012). عناوين البث المتعدد للتوثيق. فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6676 . ISSN 2070-1721. RFC 6676. إعلامية.

[rfc3232-17] J. Reynolds , ed. (يناير 2002). Assigned Numbers: RFC 1700 is Replaced by an On-line Database. Network Working Group. doi : 10.17487/RFC3232 . RFC 3232. إعلامي. يجعل RFC 1700 قديمًا .

[5-18] J. Reynolds ؛ J. Postel (أكتوبر 1984). الأرقام المخصصة. مجموعة عمل الشبكة. doi : 10.17487/RFC0923 . RFC 923. عفا عليها الزمن. عفا عليها الزمن بموجب RFC 943. عفا عليها الزمن بموجب RFC 900. العناوين الخاصة: في سياقات معينة، من المفيد أن يكون لدينا عناوين ثابتة ذات أهمية وظيفية بدلاً من كونها معرفات لمضيفين محددين. عندما يكون هذا الاستخدام مطلوبًا، يجب تفسير العنوان صفر بمعنى "هذا"، كما في "هذه الشبكة".

[rfc1122-19] R. Braden ، محرر (أكتوبر 1989). متطلبات مضيفات الإنترنت - طبقات الاتصال. مجموعة عمل الشبكة. doi : 10.17487/RFC1122 . STD 3. RFC 1122. معيار الإنترنت 3. تم تحديثه بواسطة RFC 1349، 4379، 5884، 6093، 6298، 6633، 6864، 8029 و9293.

[rfc3021-20] A. Retana; R. White; V. Fuller; D. McPherson (ديسمبر 2000). استخدام بادئات 31 بت في روابط نقطة إلى نقطة IPv4. مجموعة عمل الشبكة. doi : 10.17487/RFC3021 . RFC 3021. المعيار المقترح.

[21] Almquist, Philip; Kastenholz, Frank (December 1993). "نحو متطلبات أجهزة توجيه IP". فريق عمل هندسة الإنترنت .

[rfc1716-22] P. Almquist (نوفمبر 1994). F. Kastenholz (محرر). نحو متطلبات أجهزة توجيه IP. مجموعة عمل الشبكة. doi : 10.17487/RFC1716 . RFC 1716. عفا عليها الزمن. تم إلغاؤه بموجب RFC 1812.

[rfc1812-23] F. Baker ، محرر (يونيو 1995). متطلبات أجهزة توجيه IP الإصدار 4. مجموعة عمل الشبكة. doi : 10.17487/RFC1812 . RFC 1812. المعيار المقترح. يصبح قديمًا RFC 1716 و1009. تم تحديثه بواسطة RFC 2644 و6633.

[24] "فهم وتكوين أمر IP غير المرقم". Cisco . تم الاسترجاع في 2021-11-25 .

[25] "العالم ينفد من عناوين الإنترنت". مؤرشف من الأصل في 2011-01-25 . تم الاسترجاع في 2011-01-23 .

[26] سميث، لوسي؛ ليبنر، إيان (3 فبراير 2011). "استنزاف مساحة عناوين IPv4 المجانية". منظمة موارد الأرقام . تم الاسترجاع في 3 فبراير 2011 .

[27] ICANN، قائمة بريدية nanog. "خمسة /8s مخصصة لـ RIRs - لا يوجد /8s أحادية البث IPv4 غير مخصصة متبقية".

[28] مركز معلومات شبكة آسيا والمحيط الهادئ (15 أبريل 2011). "APNIC IPv4 Address Pool Reaches Final /8". مؤرشف من الأصل في 7 أغسطس 2011. تم الاسترجاع في 15 أبريل 2011 .

[rfc2460-29] S. Deering ؛ R. Hinden (ديسمبر 1998). مواصفات بروتوكول الإنترنت، الإصدار 6 (IPv6). مجموعة عمل الشبكة. doi : 10.17487/RFC2460 . RFC 2460. عفا عليها الزمن. تم إلغاؤه بموجب RFC 8200. أصبح عفا عليه الزمن بموجب RFC 1883. تم تحديثه بموجب RFC 5095 و5722 و5871 و6437 و6564 و6935 و6946 و7045 و7112.

[rfc3701-30] R. Fink; R. Hinden (مارس 2004). 6bone (اختبار تخصيص عنوان IPv6) Phaseout. Network Working Group. doi : 10.17487/RFC3701 . RFC 3701. إعلامي. يجعل RFC 2471 قديمًا .

[31] مؤتمر معهد مهندسي الكهرباء والإلكترونيات الدولي لعام 2016 حول التقنيات الناشئة وممارسات الأعمال المبتكرة لتحويل المجتمعات (EmergiTech) . بيسكاتاواي، نيوجيرسي: جامعة التكنولوجيا، موريشيوس، معهد مهندسي الكهرباء والإلكترونيات. أغسطس 2016. ISBN 9781509007066. OCLC 972636788.

[rfc1726-32] C. Partridge; F. Kastenholz (ديسمبر 1994). المعايير الفنية لاختيار بروتوكول الإنترنت الجيل التالي (IPng). مجموعة عمل الشبكة. doi : 10.17487/RFC1726 . RFC 1726. إعلامية.

[rfc791-33] J. Postel ، محرر (سبتمبر 1981). بروتوكول الإنترنت - مواصفات بروتوكول برنامج الإنترنت التابع لوكالة مشاريع الأبحاث الدفاعية المتقدمة. IETF . doi : 10.17487/RFC0791 . STD 5. RFC 791. IEN 128, 123, 111, 80, 54, 44, 41, 28, 26. معيار الإنترنت 5. يصبح RFC 760 قديمًا. تم تحديثه بواسطة RFC 1349 و2474 و6864.

[rfc2474-34] K. Nichols; S. Blake; F. Baker ; D. Black (ديسمبر 1998). تعريف مجال الخدمات المتباينة (DS Field) في عناوين IPv4 وIPv6. مجموعة عمل الشبكة. doi : 10.17487/RFC2474 . RFC 2474. المعيار المقترح. يصبح RFC 1455 و1349 قديمين. تم تحديثه بواسطة RFC 3168 و3260 و8436.

[rfc3168-35] K. Ramakrishnan; S. Floyd; D. Black (سبتمبر 2001). إضافة إشعار الازدحام الصريح (ECN) إلى IP. مجموعة عمل الشبكة. doi : 10.17487/RFC3168 . RFC 3168. المعيار المقترح. يلغي RFC 2481. ويحدث RFC 2474 و2401 و793. ويحدث بواسطة RFC 4301 و6040 و8311.

[36] Savage, Stefan (2000). "Practical network support for IP traceback". ACM SIGCOMM Computer Communication Review . 30 (4): 295–306. doi : 10.1145/347057.347560 .

[rfc6864-37] J. Touch (فبراير 2013). مواصفات محدثة لحقل معرف IPv4. IETF . doi : 10.17487/RFC6864 . ISSN 2070-1721. RFC 6864. المعيار المقترح. تحديثات RFC 791 و1122 و2003.

[rfc3514-38] S. Bellovin (1 أبريل 2003). علم الأمان في رأس IPv4. مجموعة عمل الشبكة. doi : 10.17487/RFC3514 . RFC 3514. إعلامي. هذا طلب للتعليقات في يوم كذبة أبريل .

[40] Bhardwaj, Rashmi (2020-06-04). "Fragment Offset - IP With Ease". ipwithease.com . تم الاسترجاع في 2022-11-21 .

[41] "أسئلة شائعة غير رسمية حول شركة سيسكو" . تم الاسترجاع في 10 مايو 2012 .

[rfc6274-42] F. Gont (يوليو 2011). تقييم أمان بروتوكول الإنترنت الإصدار 4. فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6274 . ISSN 2070-1721. RFC 6274. إعلامية.

اللغة	العربية (RTL)
روابط موسوعية	30 رابطاً
المصدر الأصلي	ويكيبيديا ↗