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

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

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

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

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

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

نبذة تاريخية

طُوِّر بروتوكول رسائل التحكم في الإنترنت بالتوازي مع تطوير الإصدار الرابع من بروتوكول الإنترنت، وطُرح أول معيار له شهر أبريل من العام 1981 في وثيقة طلب التعليقات RFC 777، ثُمَّ طُرحت وثيقة أخرى بعدخمسة أشهر في سبتمبر من نفس العام وهي وثيقة طلب التعليقات RFC 792،⁽¹⁾ وهي المعيار الرسمي للبروتوكول حتى اليوم.

احتوى المعيار الرسميّ للبروتوكول على توصيف مُقتضب لإحدى عشرة رسالة تحكُّمٍ، تلا ذلك شرحٌ مُفصَّل عن كيفية عمل البروتوكول ومتى يَلزم إِرسال الرسائِل وتفاصيلُ دقيقةٌ أخرى صدرت في وثيقتين منفصلتين، الأولى موجهة لتوصيف عمل مُضيفي الإصدار الرابع من بروتوكول الإنترنت، وهي وثيقة طلب التعليقات RFC 1122 المعنونة:"متطلبات مُضيفي الإنترنت -- طبقات الاتصال"⁽²⁾ والَّتي صدرت في شهر أوكتوبر من العام 1989م، والثانية مُخصصةٌ لتوصيف عمل المُوجِّهات، وهي الوثيقة RFC 1812 المُعنونة:"مُتطلبات مُوجِّهات الإصدار الرابع من بروتوكول الإنترنت"⁽³⁾ والتي صدرت في شهر يونيومن العام 1995.

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

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

مبدأ العمل

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

رسائل الأخطاء

رسائل الاستعلام

مخططا تتابع بلغة النمذجة الموحدة لوصف عمل نوعي رسائل بروتوكول رسائل التحكم

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

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

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

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

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

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

تتكون ترويسة بروتوكول رسائل التحكم من مجموعتين من الحقول، أوَّلها هي الحقول الدائمة، وتوجد في ترويسات رسائل البروتوكول كُلِّها، بغض النظر عن نوع الرسالة، وثانيها هي حقول المُحتوى، وتتغير في العدد والبنية بحسب نوع الرسالة، ويمكن وصف حقول الرسالة كالتالي:

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

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

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

جدول برسائل بروتوكول رسائل التحكم التي ما تزال قيد الاستعمال مُصنفةً وفقاً للنوع
حقل النوع	اسم الرسالة بالعربية	اسم الرسالة بالإنجليزية	تصنيف الرسالة
0	الصدى⁽⁶⁾	Echo Replay	استعلام
3	عدم بلوغ الوجهة	Destination unreachable	خطأ
5	إعادة التوجيه	Redirect	خطأ
8	توليد الصدى⁽⁶⁾	Echo	استعلام
9	إعلان الموجه	Router Advertisement	استعلام
10	التماس الموجه	Router Solicitation	استعلام
11	نفاد الزمن	Time exceeded	خطأ
12	مشكلة في محدد	Parameter problem	خطأ
13	طلب وسمة زمنيَّة	Timestamp	استعلام
14	الردُّ على طلب الوسمة الزمنيَّة	Timestamp Reply	استعلام

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

جدول برسائل بروتوكول رسائل التحكم المُبطَلِة
حقل النوع	اسم الرسالة بالعربية	اسم الرسالة بالإنجليزية	سبب الإبطال
4	تهدئة المصدر	Source Quench	بسبب عدم فعاليَّة الآلية في معالجة ظاهرة الازدحام.
6	عنوان المضيف البديل	Alternate Host Address	ليس هناك معلومات متوافرة عن هذا النوع من الرسائل
15	طلب معلومات	Information Request	بسبب ظهور تقنيَّات أخرى تقدِّم هذه الخدمات بكفاءة، مثل بروتوكول التهيئة الآلية للمضيفين
16	الرد على طلب المعلومات	Information Reply
17	طلب قناع عنوان	Address Mask Request
18	الرد على طلب قناع عنوان	Information Reply
30	تتبع المسار	Traceroute	عُرّّفت الرسالة كخيار تجريبي للإصدار الرابع من بروتوكول الإنترنت، ولم تُطبَّق أبداً على نطاق واسع.
31	خطأ في تحويل حزمة البيانات	Datagram Conversion Error	كان الهدف من تطوير هذه الرسالة هوالإبلاغ عن أحطاء تحويل حزم البيانات في الإصدار السابع من بروتوكول الإنترنت (TP/IX)،⁽⁷⁾ ولكن البروتوكول ولم يُطبَّق أبداً على نطاق واسع.
32	إعادة توجيه المُضيف المُتحرك	Mobile Host Redirect	طُوِّرت هذه الرسالة بالأصل لتكون جزءاً من بروتوكول تجريبي لمضيفي بروتوكول الإنترنت المتحركين، ولكن البروتوكول لم يُطبَّق أبداً على نطاق واسع.
33	الإصدار السادس، أين أنت	IPv6 Where-Are-You	طوِّرت هاتان الرسالتان كجزء من مشروع يهدف لتحديد العقد المجاورة التي تُشغِّل الإصدار السادس من بروتوكول الإنترنت، ولكن البروتوكول لم يُطبَّق أبداً على نطاق واسع.
34	الإصدار السادس، أنا هنا	IPv6 I-Am-Here
35	طلب الإنضمام	Mobile Registration Request	طُوِّرت هاتان الرسالتان لدعم توجيه رزم بيانات الإصدار السادس من بروتوكول الإنترنت لدى العُقد المُتحركة، ولكن البروتوكول لم يُطبَّق أبداً على نطاق واسع.
36	الرد على طلب الإنضمام	Mobile Registration Reply
37	طلب اسم النطاق	Domain Name Request	طُوِّرت هاتان الرسالتان ضمن آلية تسمح للمضيف بالحصول على اسم النطاق المؤهل المُكتَمل، ولكن البروتوكول لم يُطبَّق أبداً على نطاق واسع.
38	الرد على طلب اسم النطاق	Domain Name Reply
39	تتبع المسار	Traceroute	طُوِّرت هذه الرسالة لدعم إدارة المفاتيح البسيطة لبروتوكولات الإنترنت (SKIP)، ولكن البروتوكول لم يُطبَّق أبداً على نطاق واسع.

الوظائف

رسائل الأخطاء

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

تُحدد وثيقة طلب التعليقات RFC 1812 بعض الحالات التي لا يجب حتى تُرسل رسائل الأخطاء فيها، وهي كالتالي:

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

عدم بلوغ الوجهة

بنية رسالة عدم بلوغ الوجهة

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

1. من مُوجِّه يُعالج الرزمة:

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

2. من المُضيف الوجهة:

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

قيم حقل الرمز في رسالة عدم بلوغ الوجهة
حقل الرمز	الحالة	الوصف
0	عدم بلوغ الشبكة	يُولِّدها مُوجِّه يعالج رزمة بيانات ما إذا كان المسار نحوالشبكة الوجهة غير مُتوافِر في جدول التوجيه.
1	عدم بلوغ المضيف	يُولِّدها مُوجِّه يعالج رزمة بيانات ما إذا كانت المُضيف الوجهة يقع في شبكةٍ مُتصِلةٍ بشكلٍ مُباشر معه، ولكن المسار نحوالمُضيف الوجهة غير مُتوافِر.
2	عدم بلوغ البروتوكول	تُولَّد في المضيف الوجهة إذا كان بروتوكول طبقة النقل الذي يجب حتى يعالج محتوى رزمة البيانات غير مدعومٍ.
3	عدم بلوغ المنفذ	تُولَّد في المضيف الوجهة إذا كانت بروتوكول طبقة النقل الذي يجب حتى يعالج محتوى رزمة البيانات لا يدعم رقم المنفذ الموجود في محتوياتها.
4	الحاجة للتقطيع وفهم عدم التقطيع مرفوع	يُولِّدها مُوجِّه يعالج رزمة بيانات ما إذا كانت يتوجب عليه تقطيع الرزمة ولكن فهم عدم التقطيع مرفوعٌ فيها.
5	فشل مسار المصدر	يُولِّدها مُوجِّه لم يستطيع توجيه رزمة بيانات ما وفقاً لما يوجد في خيار المسار المُقيّد بالمصدر.⁽⁸⁾
6	الشبكة الوجهة غير مَعرُوفة	لا يجب توليد رسالة عدم بلوغ وجهة بهذا الرمز، لأنَّها تعطي المصدر انطباعاً بأنَّ الشبكة الوجهة غير مَوُجودة. عوضاً عن الرسالة، تُولَّد رسالةُ عدم بلوغ وجهةٍ تكون قيمة حقل النوع فيها مساويةً للصفر.
7	المضيف الوجهة غير معروفة	تولد هذه الرسالة في حالة محددة هي عندما يتمكَّن المُوجِّه، اعتماداً على معلومات طبقة الربط، من الجزم بصورة أكيدة بأنَّ المُضيف الوجهة غير موجود.
8	المضيف المصدر معزول	مُبطلَة، لا تُستعمل.
9	الاتصال مع الشبكة الوجهة مَحظُور إشرافيَّاً	لا يُسمح للمضيف المصدر بإرسال رزم البيانات إلى الشبكة حيث يُوجَد المُضيف الوجهة.
10	الاتصال مع المضيف الوجهة محظور إشرافيَّاً	لا يُسمح للمضيف المصدر بإرسال رزم البيانات إلى المُضيف الوجهة.
11	عدم بلوغ الشبكة الوجهة بسبب نوع الخدمة	يُولِّدها مُوجِّه يعالج رزمة بيانات ما لم يكن هناك مسارٌ نحوالشبكة الوجهة متوافِقٌ مع نوع الخدمة الافتراضي.
12	عدم بلوغ المضيف الوجهة بسبب نوع الخدمة	يُولِّدها مُوجِّه يعالج رزمة بيانات ما لم يكن هناك مسارٌ نحوالمُضيف الوجهة متوافقٌ مع نوع الخدمة الافتراضي أوالمطلوب وفقاً للرزمة.
13	الاتصال محظور إشرافيَّاً	تُولَّد في مُوجِّه إذا لم يكن باستطاعته توجيه رزمة بيانات ما بسبب عملية ترشيح إشرافيَّة.
14	انتهاك أحقيَّة المضيف	تُرسل من مُوجِّهٍ متصِلٍ بشكلٍ مُباشر مع شبكة المضيف المصدر لإخباره بأنَّه لا يحق له إنجاز عملية الإرسال لأغراض تتعلق بنوع الخدمة، مثلاً لا يحق للمُضيف إنشاء اتصال بين زوج عناوين المصدر والوجهة أوأرقام منافذ المصدر والوجهة أوغير ذلك.⁽⁹⁾
15	أحقيَّة غير كافية	تُرسل من مُوجِّه مُتصِلٍ بشكلٍ مُباشرٍ مع شبكة المُضيف لإخباره بأنَّه لا يحقق درجة الأحقيَّة الدُنيا اللازمة لإتمام العملية.⁽⁹⁾

إعادة التوجيه

بنية رسالة إعادة التوجيه.

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

تُرسل رسالة إعادة التوجيه من مُوجِّه مُتصِلٍ بشكلٍ مباشر مع شبكة المضيف المصدر لرزمة بيانات من أجل إبلاغه باستحسان حتى يُرسل رزم البيانات الموجهة لوجهة مُحددة إلى مُوجِّه آخر متصل بشكل مباشر مع الشبكة المحليَّة نفسها.(RFC 1812 P.57) أفضل لرزمة بيانات تجاوز وأوفدها. في هذه الحالةقد يكون هناك مُوجِّهان على الأقل مُتصِلان مع الشبكة المحلية حيث يُوجد المُضيف، وليكونا مثلاً R₁ وR₂. يُولِّد المُضيف رزمة بيانات نحووجهة ما، ولتكن X، وأفضل مسار لبلوغ هذه الشبكة هوعبر الموجه R₂، ولكن المُضيف يُرسلها نحوالموجه R₁، وهنا يقوم هذا الموجه بتوجيهها نحوالموجه R₂، ثُمَّ يُرسل رسالة إعادة توجيه للمضيف الذي ولد الرزمة، يبلغه فيها بتوجيه الرزم المستقبلية التي تكون وجهتها هي X نحوالموجه R₂.

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

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

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

نفاد الزمن

بنية رسالة نفاد الزمن.

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

تكون قيمة حقل النوع في رسالة نفاد الزمن هي 11 دائماً، أما قيمة حقل الرمز فتكون إما 0 أو1 وفقاً للجدول التالي:

قيم حقل الرمز في رسالة نفاد الزمن
حقل الرمز	الحالة	الوصف
0	نفاد زمن حياة الرزمة	قيمة حقل زمن حياة الرزمة في ترويسة الإصدار الرابع من بروتوكول الإنترنت بلغت الصفر.
1	نفاد زمن التجميع	انتهى زمن الانتظار لتجميع بتر رزمة بيانات، وبعض البتر لم تصل بعدُ.

مشكلة في محدِد

بنية رسالة مشكلةٌ في محدِد في بروتوكول رسائل التحكم للإصدار الرابع من بروتوكول الإنترنت.

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

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

قيم حقل الرمز في رسالة نفاد الزمن
حقل الرمز	الحالة	المرجع
0	حقل المُؤشِّر يُشير إلى مسقط الخطأ
1	هناك خيارٌ مَطلُوب في الترويسة، ولكنَّه غير موجودٍ فيها

رسائل الاستعلام

توليد الصدى والصدى

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

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

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

تكون قيمة حقل النوع هيثمانية في رسالة توليد الصدى و0 في رسالة الصدى. أمَّا قيمة حقل الرمز، فهي 0 دائماً في كلتا الرسالتين.

اكتشاف الموجه

بنية رسالة إعلان المُوجِّه.

بنية رسالة التماس المُوجِّه.

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

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

تُرسل رسائل الإعلان بشكل دوريٍّ بفواصل زمنيَّة تتراوح بينسبعة و10 دقائق، وتكون مدة زمن الحياة هي 30 دقيقة افتراضيَّاً.

الوسمة الزمنية

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

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

تكون قيمة حقل النوع في رسالة الوسمة الزمنية هي 13 وفي رسالة الرد عليها 14، أمَّا قيمة حقل الرمز فهي 0 دائماً في الرسالتين.

التطبيقات

أمر التحقق من الاتصال

لقطة شاشة لأمر التحقق من الاتصال في نظام التشغيل دوز المُدمَج ضمن إصدارات ويندوز المُختلِفة.

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

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

أمر تتبع المسار

لقطة شاشة لأمر تتبع المسار في نظام التشغيل دوز المُدمَج ضمن إصدارات ويندوز المتنوعة.

أمر تتبع المسار (بالإنجليزية: Traceroute أوTracert)‏ هوأمر برمجيٌّ مَدعُومٌ في شبكات البيانات التي تُشغِّل حزمة بروتوكولات الإنترنت، يهدف إلى تعقب المسار الذي تسلكه رزم البيانات عند انتنطقها من مصدرها إلى وجهتها. يُقدِّم الأمر بياناتٍ عن عدد القفزات على طول المسار والزمن الذي استغرقه جميع منها.

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

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

المُشكلات

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

في ما يأتي، تصنيفٌ للهجمات التي يمكن شنها باستعمال البروتوكول وفقاً لنوع الرسالة:

أولاً: رسالتا توليد الصدى والصدى:

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

ثانياً: رسالة إعادة التوجيه:

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

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

هوامش

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

2. العنوان الأَصليّ هو: (بالإنجليزية: Requirements for Internet Hosts -- Communication Layers)‏.

3. العنوان الأَصليّ هو: (بالإنجليزية: Requirements for IP Version أربعة Routers)‏.

4. يُمكن تبين العلاقة الوثيقة بين بروتوكول رسائل التحكم والإصدار السادس من بروتوكول الإنترنت بتتبع الأسماء الرمزية للمعايير الرسمية، فقد حمل المعيار الأول للإصدار السادس من بروتوكول الإنترنت الاسم RFC 1883، في حين خُصصت الوثيقة RFC 1884 للعنونة باستعمال هذا الإصدار، وتلاهما معيار بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت الذي حملت وثيقته الاسم الرمزي RFC 1885.

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

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

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

8. انظر خيار المسار المُقيَّد بالمصدر في الإصدار الرابع من بروتوكول الإنترنت.

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

10. في زمن تطوير البروتوكول كانت خدمة التوقيت في الإنترنت (بالإنجليزية: Internet Clock Service اختصاراً ICS)‏ تحت إشراف مختبرات كومسات (بالإنجليزية: COMSAT Laboratories)‏.

11. السنفور (الجمع: السنافر) هوشخصية خيالية صغيرة الحجم، زرقاء اللون، وتعيش في غابة في أوروبة في العصور الوسطى، ابتكرها الرسام البلجيكي بيير كوليفور (بالفرنسية: Pierre Culliford)‏ في العام 1958م، وسبب تسمية الهجوم هوكناية عن صغر حجم الرسائل المستعملة في هذا الهجوم مع كثرة عددها.

انظر أيضا

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

الإصدار الرابع من بروتوكول الإنترنت (IPv4)
أمر التحقق من الاتصال (Ping)
أمر تتبع المسار (Traceroute)

المراجع

فهرس المراجع

↑ RFC 1812, P.52
↑ RFC 792, P.1
↑ The TCP/IP Guide, P610
^ RFC 792, P.20
↑ RFC 950 P.10
↑ "Internet Control Message Protocol (ICMP) Parameters". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 26 مارس 2020. اطلع عليه بتاريخ 18 أبريل 2020.
↑ TCP/IP Illustrated, P.428
^ J. Postel (أبريل 1981). "RFC 777, Internet Control Message Protocol". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC0777. مؤرشف من الأصل في 12 ديسمبر 2019. اطلع عليه بتاريخ 18 أبريل 2020.
↑ RFC 1122, P.1
↑ RFC 1812, P.1
↑ RFC 1256 P.1
^ RFC 6918 P.4-5
↑ S. Deering; R. Hinden (ديسمبر 1995). "RFC 1883, Internet Protocol, Versionستة (IPv6) Specification". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1883. مؤرشف من الأصل في 21 ديسمبر 2019. اطلع عليه بتاريخ 30 مايو2018.
↑ A. Conta; S. Deering (ديسمبر 1995). "RFC 1885, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Versionستة (IPv6) Specification". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1885. مؤرشف من الأصل في 25 يناير 2020. اطلع عليه بتاريخ 18 أبريل 2020.
^ A. Conta; S. Deering (مارس 2006). "RFC 4443, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Versionستة (IPv6) Specification". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC4443. مؤرشف من الأصل فيستة مارس 2020. اطلع عليه بتاريخ 18 أبريل 2020.
^ R. Braden (يونيو1987). "RFC 1009, Requirements for Internet Gateways". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1009. مؤرشف من الأصل في 15 أبريل 2020. اطلع عليه بتاريخ 18 أبريل 2020.
^ RFC 791, P.3
^ TCP/IP Illustrated, P.353
^ TCP/IP Illustrated, P.354
^ "Protocol Numbers". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 17 مارس 2020. اطلع عليه بتاريخ 18 أبريل 2020.
^ TCP/IP Illustrated, P.355
^ S. Bradner; V. Paxson (مارس 2000). "RFC 2780, IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers". The Internet Society (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC2780. مؤرشف من الأصل فيستة مارس 2020. اطلع عليه بتاريخ 18 أبريل 2020.
^ RFC 1812, P.52-53
↑ RFC 792, P.14
^ RFC 792, P.4
↑ RFC 792, P.12
^ RFC 1256, P.5
^ RFC 1256, P.6
↑ RFC 792, P.6
↑ RFC 792, P.8
↑ RFC 792, P.16
↑ F. Gont (مايو2012). "RFC 6633, Deprecation of ICMP Source Quench Messages". The Internet Society (باللغة الإنجليزية). صفحة 2. doi:10.17487/RFC6633. ISSN 2070-1721. مؤرشف من الأصل فيستة مارس 2020. اطلع عليه بتاريخ 18 أبريل 2020.
↑ RFC 6918, P.3
^ The TCP/IP Guide, P.614
^ R. Droms (مارس 1997). "RFC 2131, Dynamic Host Configuration Protocol". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC2131. مؤرشف من الأصل فيستة مارس 2020. اطلع عليه بتاريخ 18 أبريل 2020.
↑ G. Malkin (يناير 1993). "RFC 1393 , Traceroute Using an IP Option". The Internet Society (باللغة الإنجليزية). صفحة 3-4. doi:10.17487/RFC1393. مؤرشف من الأصل في 25 يناير 2020. اطلع عليه بتاريخ 19 أبريل 2020.
↑ C. Pignataro; F. Gont (نوفمبر 2012). "RFC 6814, Formally Deprecating Some IPv4 Options". The Internet Society (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC6814. ISSN 2070-1721. مؤرشف من الأصل في أربعة ديسمبر 2019. اطلع عليه بتاريخ 18 أبريل 2020.
^ "RFC 1475, P.1
^ David B. Johnson (13 يوليو1993). "Transparent Internet Routing for IP Mobile Hosts". Rice University, Department of Computer Science (باللغة الإنجليزية). مؤرشف من الأصل فيخمسة أبريل 2016. اطلع عليه بتاريخ 13 أبريل 2020.
^ W A Simpson (يناير 1995). "IPv6 Neighbor Discovery -- ICMP Message Formats draft-simpson-ipv6-discov-formats-02.txt". IETF (باللغة الإنجليزية). مؤرشف من الأصل في 28 سبتمبر 2019. اطلع عليه بتاريخ 13 أبريل 2020.
^ W A Simpson (نوفمبر 1994). "IPv6 Mobility Support draft-simpson-ipv6-mobility-00.txt". IETF (باللغة الإنجليزية). مؤرشف من الأصل فيعشرة يناير 2020. اطلع عليه بتاريخ 13 أبريل 2020.
^ W. Simpson (أبريل 1995). "RFC 1788, ICMP Domain Name Messages". The Internet Society (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC1788. مؤرشف من الأصل في 27 يناير 2020. اطلع عليه بتاريخ 18 أبريل 2020.
↑ RFC 6918, P.4
^ Ashar Aziz; Tom Markson (21 ديسمبر 1995). "Simple Key-Management For Internet Protocols (SKIP) <draft-ietf-ipsec-skip-06.txt>". IETF (باللغة الإنجليزية). مؤرشف من الأصل في 27 ديسمبر 2018. اطلع عليه بتاريخ 13 أبريل 2020.
^ Ashar Aziz; Tom Markson (21 ديسمبر 1995). "SKIP Algorithm Discovery Protocol <draft-ietf-ipsec-skip-adp-00.txt>". IETF (باللغة الإنجليزية). مؤرشف من الأصل في 27 ديسمبر 2018. اطلع عليه بتاريخ 13 أبريل 2020.
^ RFC 1122, P.38
^ David D. Clark (يوليو1982). "RFC 816, Fault isolation and Recovery". The Internet Society (باللغة الإنجليزية). صفحة 3-4. doi:10.17487/RFC0816. مؤرشف من الأصل في 2 يناير 2019. اطلع عليه بتاريخ 18 أبريل 2020.
^ RFC 1812, P.55
^ RFC792, P.5
^ The TCP/IP Guide, P.622-623
^ RFC 1812, P.80-81
^ RFC 1122, P.39-40
^ RFC 792, P.13
^ RFC 1122, P.40-41
^ The TCP/IP Guide, P.631
↑ RFC 1812, P.82
^ RFC 792, P.6-7
^ RFC 792, P.9
↑ RFC 1812, P.58
↑ RFC 792, P.15
^ RFC 1812, P.59
^ RFC 1256, P.3
^ RFC 1256, P.4
^ RFC 792, P.17
^ Dictionary of Networking, P.301
^ Mike Muuss. "The Story of the PING Program". U.S. Army Research Laboratory (باللغة الإنجليزية). مؤرشف من الأصل في 12 فبراير 2020. اطلع عليه بتاريخ 19 أبريل 2020.
↑ Daniele Raffo (2020) [2013]. (باللغة الإنجليزية) (الطبعة الثامنة). صفحة 115. مؤرشف من الأصل (PDF) في 19 أبريل 2020.
^ Windows Commands Reference, P.643
^ Cisco IOS Command Reference, P.CF-414
^ Dictionary of Networking, P.385
^ Windows Commands Reference, P.852
^ Cisco IOS Command Reference, P.CF-1145
^ D. Senie (أغسطس 1999). "RFC 2644,Changing the Default for Directed Broadcasts in Routers". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC2644. مؤرشف من الأصل في 25 يناير 2020. اطلع عليه بتاريخ 20 أبريل 2020.
^ F. Gont (يوليو2011). "RFC 6274, Security Assessment of the Internet Protocol Version 4". The Internet Society (باللغة الإنجليزية). صفحة 22. doi:10.17487/RFC6274. ISSN 2070-1721. مؤرشف من الأصل في 17 فبراير 2020. اطلع عليه بتاريخ 20 أبريل 2020.
^ "The LAND attack (IP DOS)". Nmap Project (باللغة الإنجليزية). 20 نوفمبر 1997. مؤرشف من الأصل في 13 يوليو2019. اطلع عليه بتاريخ 20 أبريل 2020.
^ TCP/IP Illustrated, P.428-429
^ F. Gont (يوليو2010). "RFC 5927, ICMP Attacks against TCP". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC5927. مؤرشف من الأصل في 24 يناير 2020. اطلع عليه بتاريخ 20 أبريل 2020.
^ RFC 791, P.1
^ R. Hinden; S. Deering (ديسمبر 1995). "RFC 1884, IP Versionستة Addressing Architecture". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1884. مؤرشف من الأصل فيستة مارس 2020. اطلع عليه بتاريخ 18 أبريل 2020.
^ RFC 792, P.10
^ ابن منظور (محرم 1405 هـ). . 14. قُم: نشرأدب الحوزة. صفحة 454. مؤرشف من الأصل في 19 أبريل 2020.
^ RFC 1475, P.7
^ RFC 791, P.18
^ RFC 791, P.12
^ D.L. Mills (18 أبريل 1981). "RFC 778, DCNET Internet Clock Service". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC0778. مؤرشف من الأصل في 12 ديسمبر 2019. اطلع عليه بتاريخ 19 أبريل 2020.

المعلومات الكاملة للمراجع المُستشهد بها أكثر من مرة

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

Peter Dyson; Kevin Shafer (1999). (باللغة الإنجليزية) (الطبعة الثالثة). SYBEX Inc. ISBN .
Charles M. Kozierok (2005). (PDF) (باللغة الإنجليزية). William Pollock. ISBN .
(PDF) (باللغة الإنجليزية). Cisco Systems, Inc. 2010.
Kevin R.Fall; W.Richard Stevens (2012). (PDF) (باللغة الإنجليزية) (الطبعة الثانية). Pearson Education, Inc. ISBN .
(PDF) (باللغة الإنجليزية) (الطبعة WS16). 2018.

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

Postel, J. (سبتمبر 1981). "RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC0791. مؤرشف من الأصل في 12 فبراير 2020.
Postal, J. (أغسطس 1981). "RFC 792, Internet Control Message protocol, DARPA internet program,protocol specification". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC0792. مؤرشف من الأصل في 19 فبراير 2020.
Mogul, J.; Postel, J. (أغسطس 1985). "RFC 950, Internet Standard Subnetting Procedure" (باللغة الإنجليزية). doi:10.17487/RFC0950. مؤرشف من الأصل في 06 يناير 2020.
Braden, R. (أوكتوبر 1989). "RFC 1122, Requirements for Internet Hosts -- Communication Layers". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1122. مؤرشف من الأصل في 15 فبراير 2020.
Deering, S. (سبتمبر 1991). "RFC 1256, ICMP Router Discovery Messages". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1256. مؤرشف من الأصل في 12 أبريل 2020.
R. Ullmann (يونيو1995). "RFC 1475, TP/IX: The Next Internet". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1475.
Baker, F. (يونيو1995). "RFC 1812, Requirements for IP Version أربعة Routers". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1812. مؤرشف من الأصل في 06 مارس 2020.
F. Gont; C. Pignataro (أبريل 2013). "RFC 6918, Formally Deprecating Some ICMPv4 Message Types". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC6918. ISSN 2070-1721. مؤرشف من الأصل في 26 يناير 2020.

وصلات خارجية

بروتوكول رسائل التحكم في شبكة الإنترنت، من مرشد حزمة بروتوكول الإنترنت.

[RFC-60-1] RFC 1812, P.52

[RFC-2-2] RFC 792, P.1

[Book-3-3] The TCP/IP Guide, P610

[RFC-62-4] RFC 792, P.20

[RFC-6-5] RFC 950 P.10

[Web-7-6] "Internet Control Message Protocol (ICMP) Parameters". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 26 مارس 2020. اطلع عليه بتاريخ 18 أبريل 2020.

[BOOK-19-7] TCP/IP Illustrated, P.428

[RFC-1-8] J. Postel (أبريل 1981). "RFC 777, Internet Control Message Protocol". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC0777. مؤرشف من الأصل في 12 ديسمبر 2019. اطلع عليه بتاريخ 18 أبريل 2020.

[RFC-4-9] RFC 1122, P.1

[RFC-5-10] RFC 1812, P.1

[RFC-7-11] RFC 1256 P.1

[RFC-8-12] RFC 6918 P.4-5

[RFC-9-13] S. Deering; R. Hinden (ديسمبر 1995). "RFC 1883, Internet Protocol, Versionستة (IPv6) Specification". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1883. مؤرشف من الأصل في 21 ديسمبر 2019. اطلع عليه بتاريخ 30 مايو2018.

[RFC-11-14] A. Conta; S. Deering (ديسمبر 1995). "RFC 1885, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Versionستة (IPv6) Specification". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1885. مؤرشف من الأصل في 25 يناير 2020. اطلع عليه بتاريخ 18 أبريل 2020.

[RFC-12-15] A. Conta; S. Deering (مارس 2006). "RFC 4443, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Versionستة (IPv6) Specification". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC4443. مؤرشف من الأصل فيستة مارس 2020. اطلع عليه بتاريخ 18 أبريل 2020.

[RFC-15-16] R. Braden (يونيو1987). "RFC 1009, Requirements for Internet Gateways". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1009. مؤرشف من الأصل في 15 أبريل 2020. اطلع عليه بتاريخ 18 أبريل 2020.

[RFC-16-17] RFC 791, P.3

[BOOK-1-18] TCP/IP Illustrated, P.353

[BOOK-2-19] TCP/IP Illustrated, P.354

[Web-6-20] "Protocol Numbers". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 17 مارس 2020. اطلع عليه بتاريخ 18 أبريل 2020.

[BOOK-4-21] TCP/IP Illustrated, P.355

[RFC-19-22] S. Bradner; V. Paxson (مارس 2000). "RFC 2780, IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers". The Internet Society (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC2780. مؤرشف من الأصل فيستة مارس 2020. اطلع عليه بتاريخ 18 أبريل 2020.

[RFC-17-23] RFC 1812, P.52-53

[RFC-18-24] RFC 792, P.14

[RFC-20-25] RFC 792, P.4

[RFC-21-26] RFC 792, P.12

[RFC-22-27] RFC 1256, P.5

[RFC-23-28] RFC 1256, P.6

[RFC-24-29] RFC 792, P.6

[RFC-25-30] RFC 792, P.8

[RFC-26-31] RFC 792, P.16

[RFC-14-32] F. Gont (مايو2012). "RFC 6633, Deprecation of ICMP Source Quench Messages". The Internet Society (باللغة الإنجليزية). صفحة 2. doi:10.17487/RFC6633. ISSN 2070-1721. مؤرشف من الأصل فيستة مارس 2020. اطلع عليه بتاريخ 18 أبريل 2020.

[RFC-27-33] RFC 6918, P.3

[BOOK-6-34] The TCP/IP Guide, P.614

[RFC-29-35] R. Droms (مارس 1997). "RFC 2131, Dynamic Host Configuration Protocol". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC2131. مؤرشف من الأصل فيستة مارس 2020. اطلع عليه بتاريخ 18 أبريل 2020.

[RFC-55-36] G. Malkin (يناير 1993). "RFC 1393 , Traceroute Using an IP Option". The Internet Society (باللغة الإنجليزية). صفحة 3-4. doi:10.17487/RFC1393. مؤرشف من الأصل في 25 يناير 2020. اطلع عليه بتاريخ 19 أبريل 2020.

[RFC-30-37] C. Pignataro; F. Gont (نوفمبر 2012). "RFC 6814, Formally Deprecating Some IPv4 Options". The Internet Society (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC6814. ISSN 2070-1721. مؤرشف من الأصل في أربعة ديسمبر 2019. اطلع عليه بتاريخ 18 أبريل 2020.

[RFC-32-38] "RFC 1475, P.1

[Web-1-39] David B. Johnson (13 يوليو1993). "Transparent Internet Routing for IP Mobile Hosts". Rice University, Department of Computer Science (باللغة الإنجليزية). مؤرشف من الأصل فيخمسة أبريل 2016. اطلع عليه بتاريخ 13 أبريل 2020.

[Web-2-40] W A Simpson (يناير 1995). "IPv6 Neighbor Discovery -- ICMP Message Formats draft-simpson-ipv6-discov-formats-02.txt". IETF (باللغة الإنجليزية). مؤرشف من الأصل في 28 سبتمبر 2019. اطلع عليه بتاريخ 13 أبريل 2020.

[Web-3-41] W A Simpson (نوفمبر 1994). "IPv6 Mobility Support draft-simpson-ipv6-mobility-00.txt". IETF (باللغة الإنجليزية). مؤرشف من الأصل فيعشرة يناير 2020. اطلع عليه بتاريخ 13 أبريل 2020.

[RFC-31-42] W. Simpson (أبريل 1995). "RFC 1788, ICMP Domain Name Messages". The Internet Society (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC1788. مؤرشف من الأصل في 27 يناير 2020. اطلع عليه بتاريخ 18 أبريل 2020.

[RFC-28-43] RFC 6918, P.4

[Web-4-44] Ashar Aziz; Tom Markson (21 ديسمبر 1995). "Simple Key-Management For Internet Protocols (SKIP) <draft-ietf-ipsec-skip-06.txt>". IETF (باللغة الإنجليزية). مؤرشف من الأصل في 27 ديسمبر 2018. اطلع عليه بتاريخ 13 أبريل 2020.

[Web-5-45] Ashar Aziz; Tom Markson (21 ديسمبر 1995). "SKIP Algorithm Discovery Protocol <draft-ietf-ipsec-skip-adp-00.txt>". IETF (باللغة الإنجليزية). مؤرشف من الأصل في 27 ديسمبر 2018. اطلع عليه بتاريخ 13 أبريل 2020.

[RFC-34-46] RFC 1122, P.38

[RFC-35-47] David D. Clark (يوليو1982). "RFC 816, Fault isolation and Recovery". The Internet Society (باللغة الإنجليزية). صفحة 3-4. doi:10.17487/RFC0816. مؤرشف من الأصل في 2 يناير 2019. اطلع عليه بتاريخ 18 أبريل 2020.

[RFC-36-48] RFC 1812, P.55

[RFC-37-49] RFC792, P.5

[BOOK-7-50] The TCP/IP Guide, P.622-623

[RFC-39-51] RFC 1812, P.80-81

[RFC-38-52] RFC 1122, P.39-40

[RFC-43-53] RFC 792, P.13

[RFC-42-54] RFC 1122, P.40-41

[Book-8-55] The TCP/IP Guide, P.631

[RFC-44-56] RFC 1812, P.82

[RFC-45-57] RFC 792, P.6-7

[RFC-47-58] RFC 792, P.9

[RFC-46-59] RFC 1812, P.58

[RFC-48-60] RFC 792, P.15

[RFC-49-61] RFC 1812, P.59

[RFC-50-62] RFC 1256, P.3

[RFC-51-63] RFC 1256, P.4

[RFC-53-64] RFC 792, P.17

[BOOK-9-65] Dictionary of Networking, P.301

[Web-9-66] Mike Muuss. "The Story of the PING Program". U.S. Army Research Laboratory (باللغة الإنجليزية). مؤرشف من الأصل في 12 فبراير 2020. اطلع عليه بتاريخ 19 أبريل 2020.

[BOOK-14-67] Daniele Raffo (2020) [2013]. (باللغة الإنجليزية) (الطبعة الثامنة). صفحة 115. مؤرشف من الأصل (PDF) في 19 أبريل 2020.

[BOOK-17-68] Windows Commands Reference, P.643

[BOOK-12-69] Cisco IOS Command Reference, P.CF-414

[BOOK-10-70] Dictionary of Networking, P.385

[BOOK-18-71] Windows Commands Reference, P.852

[BOOK-13-72] Cisco IOS Command Reference, P.CF-1145

[RFC-54-73] D. Senie (أغسطس 1999). "RFC 2644,Changing the Default for Directed Broadcasts in Routers". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC2644. مؤرشف من الأصل في 25 يناير 2020. اطلع عليه بتاريخ 20 أبريل 2020.

[RFC-57-74] F. Gont (يوليو2011). "RFC 6274, Security Assessment of the Internet Protocol Version 4". The Internet Society (باللغة الإنجليزية). صفحة 22. doi:10.17487/RFC6274. ISSN 2070-1721. مؤرشف من الأصل في 17 فبراير 2020. اطلع عليه بتاريخ 20 أبريل 2020.

[WEB-9-75] "The LAND attack (IP DOS)". Nmap Project (باللغة الإنجليزية). 20 نوفمبر 1997. مؤرشف من الأصل في 13 يوليو2019. اطلع عليه بتاريخ 20 أبريل 2020.

[BOOK-20-76] TCP/IP Illustrated, P.428-429

[RFC-56-77] F. Gont (يوليو2010). "RFC 5927, ICMP Attacks against TCP". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC5927. مؤرشف من الأصل في 24 يناير 2020. اطلع عليه بتاريخ 20 أبريل 2020.

[RFC-3-78] RFC 791, P.1

[RFC-10-79] R. Hinden; S. Deering (ديسمبر 1995). "RFC 1884, IP Versionستة Addressing Architecture". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1884. مؤرشف من الأصل فيستة مارس 2020. اطلع عليه بتاريخ 18 أبريل 2020.

[RFC-13-80] RFC 792, P.10

[Book-5-81] ابن منظور (محرم 1405 هـ). . 14. قُم: نشرأدب الحوزة. صفحة 454. مؤرشف من الأصل في 19 أبريل 2020.

[RFC-33-82] RFC 1475, P.7

[RFC-40-83] RFC 791, P.18

[RFC-41-84] RFC 791, P.12

[RFC-52-85] D.L. Mills (18 أبريل 1981). "RFC 778, DCNET Internet Clock Service". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC0778. مؤرشف من الأصل في 12 ديسمبر 2019. اطلع عليه بتاريخ 19 أبريل 2020.