بررسی بخش Option و فرمت TLV | آموزش Embedded Ethernet قسمت 12

هرچند از بخش option در پروتکل IP فعلا استفاده ای نمی‌کنیم اما بعضی موارد رو خوب هست که اینجا توضیح بدیم قبل از اینکه از این بخش بگذریم؛ چون این بخش هم مثل چک‌سام در بسیاری از پروتکل‌ها وجود داره. در پروتکل‌هایی که در هدر، بخش Option (گزينه) با طول نامشخص دارند، گزينه ها به دو صورت ارسال ميشن:

• گزینه‌هایی كه فقط بودن يا نبودنشان حايز اهميت هست و مقدار تنظيم شونده ندارند. اين گزینه‌ها تنها يك بايت رو اشغال می‌کنند.
• گزینه‌هایی که دارای مقدار تنظيم شونده هستند و چند بايت را اشغال می‌کنند. در این حالت، اولين بايت نوع گزينه (Type) رو مشخص ميكنه؛ دومين بايت اندازه (Length) گزينه رو مشخص ميكنه و مقادير (Value) گزينه از بايت سوم به بعد قرار می‌گیرند.

گزینه‌های تک‌بایتی در بخش Option پروتکل IP

در پروتكل IP دو گزينه داريم كه فقط بودن یا نبودنشون مهمه و يك بايتي هستند:

گزینه “انتهای لیست گزینه‌ها ” معمولاً در آخر گزینه‌ها قرار می گیره و همون padding هست. چنانچه بخش Option دقیقاً مضربی از 4 باشه، نیازی به استفاده از این گزینه نیست.

گزینه “بدون عملیات” عموماً در بین گزینه‌ها استفاده میشه؛ برای اینکه شروع گزینه بعدی دقیقاً روی آدرس با مضرب 4 بیفته (برای راحتی پردازش). توجه داشته باشید که هر دوی این گزینه‌ها اختیاریست و نوع استفاده از اون به نظر برنامه‌نویس بستگی داره.

گزینه‌های چندبایتی با ساختار TLV در IP

حالت دیگه برای Option اینه که همونطور که گفتیم چند بایتی و به فرم زیر باشن. بایت اول نوع (Type or Kind) گزینه، بایت دوم طول بایت‌های اشغال شده توسط گزینه (Length) و بایت‌های سوم به بعد اطلاعات یا مقادیر گزینه (Value). در بعضی پروتکل‌ها، در بایت دوم یعنی “طول بایت‌های گزینه” دو بایت نوع و طول هم به حساب میان؛ لذا در این حالت، کمترین مقدار اندازه گزینه، عدد 2 خواهد بود؛ بدین معنی که گزینه فاقد داده یا مقدار هست!

به‌عنوان‌مثال فرض کنید گزینة نوع 7 ، دارای سه بایت داده با ارقام 0x0A,0x0B,0x0C هست؛ لذا در فرم اول این گزینه، اینطوری پیاده سازی میشه 0x07,0x03,0X0A,0X0B,0X0C و در حالت دوم به صورت 0X07,0X05,0X0A,0X0B,0X0C پیاده سازی خواهد شد. به این فرمت اصطلاحا TLV گفته میشه که سرنام کلمات Type,Length,Value هست و پروتکل IP از فرم دوم اون استفاده میکنه (یعنی در بخش Length تعداد بایت های نوع و طول هم لحاظ میشه).

همونطور که گفتیم (بسته به تعریف استاندارد پروتکل) ممکنه گزینه‌هایی داشته باشیم  كه مقدار تنظيم شونده ندارند؛ اما از فرمت TLV استفاده می‌کنند؛ مثلاً گزینه شماره 2 در فرم اول به‌صورت 0X02,0X00 و در حالت دوم به‌صورت 0X02,0X02 ثبت خواهد شد.

چرا از گزینه‌های No Operation و End of Option List استفاده می‌شود؟

مجدد یادآوری می‌کنیم؛ چنانچه تعداد کل بایت‌های یک گزینه مضرب 4 نباشه، معمولا در انتهای این گزینه، از گزینه شماره 1 یا همون No operation استفاده میشه تا هم بین گزینه ها فاصله بندازه و هم گزینه بعدی در آدرسی با مضرب 4 شروع بشه.

و در انتهای گزینه‌ها هم چنانچه جای خالی باقی مونده باشه (بر اساس مقدار HLen)؛ گزینه شماره 0 یا همون End of Option List میتونه استفاده بشه.

یک مثال از چگونگی چینش گزینه‌ها در بخش Option

مثال: فرض کنید ما دو گزینه با شماره‌های 8 و 9 داريم که هر کدام فقط یک بایت مقدار (Value) با مقدار 0x0A دارند. در پروتکل IP این دو گزینه به ترتیب بصورت 0x08,0x03,0x0A و 0x09,0x03,0x0A خواهد بود؛ در نتیجه قسمت Option میتونه همچین شکلی داشته باشه

از سمت چپ سه بایت اول مربوط به گزینه شماره 8 هستند، از اونجایی که این گزینه، 3 بایت داره؛ برای اینکه گزینه بعدی در آدرس مضرب 4 قرار بگیره یه گزینه 0x01 یا همون No Operation در بایت چهارم قرار گرفته، 3 بایت بعدی گزینه شماره 9 هست و از اونجایی که گزینه دیگه ای نداریم؛ همچنین یک بایت باید اضافه کنیم تا کل بایت های قسمت Option مضربی از 4 باشه؛ در انتهای بایت ها یه بایت 0x00 که همون End of Option List یا padding هست، اضافه شده. اینم فراموش نکنیم که در این وضعیت مقدار HLen عدد 7 خواهد بود (5 برای بخش اصلی هدر بعلاوه 2 که از تقسیم 8 بایت گزینه ها به 4 بدست میاد).

یا اینکه این‌طوری باشه:

همونطور که می‌بینید؛ دیگه بین گزینه‌ها از No Operation استفاده نشده؛ در عوض مجبور شدیم در آخر بایت ها، دو بایت 0x00 برای padding داشته باشیم.

اهمیت ترتیب، تفسیر و پیاده‌سازی گزینه‌ها

• ترتیب قرارگرفتن گزینه‌ها در بخش Option اهمیتی ندارد. در مثال بالا میتونستیم اول گزینه 9 رو قرار بدیم و بعد گزینه 8 رو.
• برنامه‌نویس در اجرای کد (Implementation) بایست کد رو طوری بنویسه که بتونه هر نوعی از ارسال بخش Optionها رو بخونه و درک کنه.
• چنانچه گزینه‌ای برای گیرنده ناشناخته باشه؛ عموماً دور ریخته میشه و در عوض پیغام خطایی (معمولاً با پروتکل ICMP) به فرستنده ارسال میشه.
• در بعضی پروتکل‌ها، استاندارد میگه که در نرم‌افزار گیرنده؛ دریافت و پردازش تعدادی از گزینه‌ها الزامیه که این الزامات در فایل‌های استاندارد RFC مربوط به هر پروتکلی اومده. پردازش مابقی گزینه‌ها اختیاری‌ست. در پروتکل IP، پردازش دو گزینه 0x00 و 0x01 الزامی‌ست.

تشخیص وجود بخش Option در کدنویسی پروتکل IP

برگردیم سراغ کدنویسی. تا اینجا پیش رفتیم که داخل تابع ETH_Process به‌صورت زیر تست کردیم ببینیم آیا فریم دریافتی شامل پروتکل IP هست یا نه:

تعریف ساختار IP_Frame در پیاده‌سازی

مثل وضعیتی که در برخورد با پروتکل ARP داشتیم در اینجا نیز برای تفکیک بخش‌های مختلف هدر و داده در پروتکل IP یک ساختار (struct) به‌صورت زیر تعریف می‌کنیم:

اگر خواسته باشید در اجرای پروتکل IP بخش Options رو هم در نظر بگیرید؛ از اونجاییکه طول این بخش نامعین هست؛ لذا اون رو هم داخل آرایه data ببینید. طبیعیه که در این حالت، باتوجه‌به عدد واقع در بخش Hlen اندازه بخش هدر مشخص میشه،  اگر این عدد بزرگ‌تر از 20 بایت باشه (HLen=5) در نتیجه، بخش ابتدایی data مربوط به قسمت Options هست.