۲۷. IP Options

در این فصل، نحوه ارسال و پردازش آپشن‌های IPv4 و IPv6 را با هم بررسی خواهیم کرد.

پروتکل IPv4 یک هدر ثابت ۲۰ بایتی دارد و می‌تواند شامل فیلدهای متغیری با حداکثر اندازه ۴۰ بایت باشد.

در سوی دیگر، IPv6 از یک هدر ثابت ۴۰ بایتی (ترکیب هدر IPv6 و هدر لایه Transport) بهره می‌برد و چون به جای Socket options از طریق اینترفیس‌ها در دسترس قرار می‌گیرد، کاربر نیازی به تفسیر مستقیم گزینه‌های هدر ندارد.

فهرست مطالب

1. گزینه‌های IPv4
2. IPv4 Source Routing
3. IPv6 Extension Headers
4. گزینه‌های Hop-by-Hop و Destination
5. IPv6 Routing Header

گزینه‌های IPv4

پروتکل IPv4 هدر ثابت ۲۰ بایتی دارد و تا سقف ۴۰ بایت به شما امکان استفاده از گزینه‌های اضافی (Options) را می‌دهد.

• فیلد ثابت ۲۰ بایتی + فیلد گزینه‌ها (حداکثر ۴۰ بایت) ← طول کل هدر بین ۲۰ تا ۶۰ بایت متغیر خواهد بود.

طول این گزینه‌ها با هم متفاوت است و در مجموع ۱۰ نوع مختلف دارند:

1. NOP

• مخفف No Operation؛ یک گزینه ۱ بایتی است که به عنوان Padding عمل می‌کند تا گزینه بعدی دقیقاً در مرز مضرب ۴ بایت (4-byte boundary) تراز شود.
• بیشتر تجهیزات شبکه و سیستم‌عامل‌ها طوری طراحی شده‌اند که هدر IPv4 با واحدهای ۴ بایتی تراز شود. این کار به منظور بهینه‌سازی حافظه، ارتقای راندمان پردازشی CPU و سازگاری سخت‌افزاری انجام می‌گیرد.
• به همین دلیل، فیلد IHL در هدر IPv4 بر حسب مضارب ۴ بایت بیان می‌شود؛ یعنی اندازه هدر برابر است با IHL × 4 (از حداقل ۵ یعنی ۲۰ بایت برای هدر پایه تا حداکثر ۱۵ یعنی ۶۰ بایت با احتساب آپشن‌ها).

۲. EOL

• برای مشخص کردن انتهای گزینه‌ها یا خالی بودن فیلد آپشن به کار می‌رود.

۳. Loose Source and Record Route (LSRR)

• فرستنده می‌تواند بخشی از روترهایی را که بسته باید از آن‌ها عبور کند، تعیین نماید.
• بسته لزوماً محدود به عبور از همین روترها نیست و مسیر می‌تواند انعطاف‌پذیر باشد.
• برای تست و بررسی مسیر شبکه و موارد مشابه استفاده می‌شود.

۴. Strict Source and Record Route (SSRR)

• فرستنده کل مسیر و تمام روترهایی را که بسته باید از آن‌ها رد شود، به طور دقیق مشخص می‌کند.
• بسته حتماً و بدون استثنا باید دقیقاً از همان مسیر تعیین‌شده حرکت کند.

۵. Timestamp

• هر روتری که بسته از آن رد می‌شود، یک برچسب زمانی (Timestamp) روی آن ثبت می‌کند.
• کاربردها: تحلیل تأخیر بسته، سنجش کارایی و ارزیابی عملکرد شبکه.
• اندازه این فیلد متغیر است (حداکثر تا ۴۰ بایت).

۶. Record Route

• برای ثبت و ضبط مسیر حرکت بسته به کار می‌رود.

۷. Basic Security (obsolete)

• این آپشن در شبکه‌های عمومی کاربردی ندارد و برای تعیین سطوح و رده‌بندی‌های امنیتی طراحی شده بود.

۸. Extended Security (obsolete)

• گزینه‌ای برای ارائه اطلاعات امنیتی تکمیلی.

۹. Stream identifier

• امروزه تقریباً منسوخ شده و استفاده نمی‌شود.
• برای شناسایی جریان‌های داده (Data Streams) مشخص در سطح شبکه به کار می‌رفت.

۱۰. Router Alert

• به تمام روترهای سر راه اعلام می‌کند که این دیتاگرام را به طور دقیق بررسی کنند.
• این قابلیت به‌خصوص در پروتکل‌های Multicast نقش بسیار مهمی ایفا می‌کند.

در محیط‌های مبتنی بر Unix، با استفاده از توابع getsockopt و setsockopt می‌توان به این آپشن‌ها دسترسی داشت.

در فصل ۷ با اینترفیسی مشابه این ساختار آشنا شدیم:

در اینجا آرگومان‌های چهارم و پنجم به ترتیب optval و optlen هستند؛ یعنی بافر آپشن و اندازه آن به تابع ارسال می‌شوند.

نکته جالب این است که اشاره‌گر بافر به جای حداکثر ۴۰ بایت، ۴۴ بایتی است. این موضوع به نحوه مدیریت گزینه‌های مسیریابی مبدأ برمی‌گردد؛ چرا که فیلدهای اضافی به LSRR و SSRR اضافه می‌شوند، اما سایر مقادیر دقیقاً از همان قالب استاندارد دیتاگرام IP پیروی می‌کنند.

وقتی کانکشن از طریق تابع accept ایجاد شده و تابع getsockopt برای دریافت آپشن‌های IP یک سوکت TCP صدا زده می‌شود، مسیر Source Routing معکوس می‌گردد؛ یعنی مسیری که بر اساس «کلاینت به سرور» تعریف شده بود، حالا در جهت «سرور به کلاینت» دریافت می‌شود.

• پروتکل TCP کل این فرایند را به صورت خودکار مدیریت می‌کند.
• در پیاده‌سازی‌های Berkeley، دریافت گزینه‌های IP از جمله گزینه sourceip برای سوکت‌های UDP امکان‌پذیر نیست. جالب است بدانید هرچند کدهای مربوط به این قابلیت از نسخه 4.3BSD Reno وجود داشته، اما ظاهراً همیشه به صورت کامنت باقی مانده است. این یعنی برنامه‌های مبتنی بر UDP عملاً نمی‌توانند از اطلاعات Source Routing دیتاگرام‌های دریافتی بهره ببرند.

نکته ۱) همان‌طور که پیش‌تر اشاره شد، هنگام فراخوانی تابع setsockopt باید دقت داشته باشید که تمام بسته‌های درون آن سوکت تحت تأثیر این گزینه قرار می‌گیرند؛ بنابراین، برای غیرفعال کردن آن باید یک اشاره‌گر Null به optval پاس دهید یا مقدار optlen را برابر ۰ بگذارید.

نکته ۲) برخلاف سوکت‌های UDP و TCP، در سوکت‌های Raw IP حتی بدون استفاده از تابع getsockopt() هم می‌توانید گزینه‌های IP را بررسی کنید؛ چرا که توابعی مانند recvfrom() کل بسته شامل IP Header را برمی‌گردانند و بنابراین گزینه‌های IP نیز به طور خودکار به همراه آن تحویل داده می‌شوند. نکته ۳) پیاده‌سازی Berkeley هیچ گزینه IPای را برای سوکت‌های UDP بازنمی‌گرداند.

مسیریابی مبدأ در پروتکل IPv4 (IPv4 Source Routing)

به طور کلی دو نوع Source Route وجود دارد:

• حالت Strict: در این حالت، دیتاگرام باید دقیقاً و فقط از میان گره‌های مشخص‌شده عبور کند؛ به عبارت دیگر، تمام نودهای تعیین‌شده در Source Route باید همسایه مستقیم یکدیگر باشند.
• حالت Loose: دیتاگرام ملزم است حتماً از گره‌های مشخص‌شده عبور کند، اما مجاز است در این میان از نودهای واسطِ ذکرنشده نیز بگذرد.

بافری که برای ارسال گزینه‌های Source Routing استفاده می‌شود به صورت زیر است:

اندازه خود گزینه‌های IP حداکثر ۴۰ بایت است، اما همان‌طور که اشاره شد، ۴ بایت اضافه نیز ارسال می‌شود تا متادیتاهای لازم منتقل شوند.

• فیلد NOP: برای Padding و تراز کردن بایت‌ها به کار می‌رود.
• فیلد Code: وظیفه شناسایی نوع عملکرد (اینکه از نوع Strict Source Routing است یا Loose Source Routing) را بر عهده دارد.
• فیلد Len: اندازه مقدار گزینه را بر حسب بایت نشان می‌دهد. این محدوده شامل تمام مقادیر به جز NOP است و در نتیجه می‌تواند حداکثر مقداری برابر با ۴۳ داشته باشد.
• فیلد Ptr: نقش نشان‌دهنده موقعیت آدرس مسیریابی (Pointer/Offset) را دارد و هم‌گام با پیشرفت فرایند مسیریابی، مقدار آن ۴ بایت ۴ بایت افزایش می‌یابد.

جالب است بدانید مقدار Len مذکور در طول مسیر مسیریابی کاهش می‌یابد؛ چرا که هنگام خروج بسته از مبدأ (Source Host)، اولین آدرس IP از فهرست گزینه‌ها حذف شده و به عنوان آدرس مقصد بسته تعیین می‌شود.

مثال

در ادامه، سه تابع کلیدی را معرفی می‌کنیم و با جمع‌بندی آن‌ها، روند Source Routing را با جزئیات بیشتری بررسی خواهیم کرد.

1. مقداردهی اولیه گزینه‌های Source Route
2. ساخت Source Route
3. پردازش گزینه‌های Source Route

مقداردهی اولیه گزینه Source Route (تابع inet_srcrt_init)

ساخت Source Route (تابع inet_srcrt_add)

پردازش گزینه Source Route (تابع inet_srcrt_print)

اگر بسته‌ای با تنظیمات Source Route ارسال شود و پس از دریافت، گزینه‌های سوکت را با استفاده از getsockopt بخوانید، خروجی در قالبی شبیه به ساختار زیر برگردانده خواهد شد:

در اینجا آدرس‌ها توسط کرنل در جهتی معکوس نسبت به ترتیب اولیه Source Routing بازگردانده می‌شوند.

طی این فرایند مرتب‌سازی، اولین آدرس IP درست پیش از NOP جای می‌گیرد.

مقدار این گزینه روی ساختار (Struct) زیر نگاشت می‌شود که با فرمت تنظیم‌شده در setsockopt تفاوت دارد. آدرس‌ها نیز معکوس هستند، اما (طبق پیاده‌سازی Berkeley) هنگام فراخوانی مجدد setsockopt برای پاسخ به فرستنده، این ترتیب دوباره اصلاح می‌شود؛ به این معنا که تبدیل فرمت 27.4 به 27.1 به طور خودکار توسط کرنل انجام می‌گیرد.

تابعی که وظیفه دریافت بسته و چاپ خروجی را بر عهده دارد به شرح زیر است. این تابع با دریافت گزینه‌های سوکت، آن‌ها را خوانده و مسیرهای باقی‌مانده را چاپ می‌کند:

اکنون بیایید کد نمونه Client-Server برای TCP echo را که از این سه تابع بهره می‌برد مشاهده کنیم:

این برنامه معمولاً با دستوری شبیه به این اجرا می‌شود: tcpcli01 -g macosx freebsd4 macosx

• گزینه g-: استفاده از Loose Source Route
• پارامترهای macosx و freebsd4: مشخص‌کننده گام‌ها (Hopها)
• پارامتر macosx: مقصد نهایی

سرور TCP echo پس از دریافت بسته از کلاینت، باید مسیرهای باقی‌مانده را نمایش دهد.

ساختار آن تفاوت چندانی با سرور TCP echo مطرح‌شده در فصل ۵ ندارد، اما روال کلی آن به صورت زیر است:

همان‌طور که مشاهده می‌کنید، گزینه‌های سوکت دریافت شده و برای چاپ به تابع مربوطه ارسال می‌شوند.

لازم به یادآوری است که Source Routing به‌ویژه برای برنامه‌هایی که احراز هویت را صرفاً بر اساس آدرس IP انجام می‌دهند، یک رخنه امنیتی خطرناک به شمار می‌رود.

چرا که اگر یک مهاجم در فیلد مبدأ (Source) یک آدرس IP معتبر و مورد اعتماد قرار دهد و سرور نفوذی خود را در مسیر Source Route بگنجاند، بسته‌های برگشتی مستقیماً و بی‌دفاع به سرور مهاجم هدایت می‌شوند.

دقیقاً به همین دلیل است که امروزه استفاده از این قابلیت تقریباً منسوخ شده و به ندرت به کار می‌رود.

هدرهای توسعه در پروتکل IPv6 (IPv6 Extension Headers)

پروتکل IPv6 از هدرهای افزونه (Extension Headers) استفاده می‌کند که انواع این هدرهای اختیاری عبارتند از:

• هدر Hop by hop: شامل گزینه‌هایی است که تمام روترهای مسیر باید آن را پردازش کنند و درست بعد از هدر اصلی IPv6 قرار می‌گیرد.
• هدر Destination: حاوی گزینه‌هایی است که فقط باید در مقصد نهایی بسته پردازش شوند.
• هدر Routing Header: برای تنظیم گزینه‌های Source Routing استفاده می‌شود.
• هدر Fragmentation Header: جهت قطعه‌قطعه کردن و بازسازی مجدد دیتاگرام‌های IPv6 به کار می‌رود.
• هدر Authentication Header: برای جلوگیری از دستکاری و تأیید اصالت پیام طراحی شده است.
• هدر Encapsulating Security Payload: برای رمزنگاری داده‌ها و تضمین امنیت و احراز هویت به کار می‌رود.

گزینه‌های Hop by hop و Destination

این دو گزینه ساختار و قالبی کاملاً یکسان دارند:

• فیلد Next Header: نوع هدر توسعهٔ بعدی را مشخص می‌کند.
• فیلد Header Extension Length: طول هدر را بر مبنای واحدهای ۸ بایتی (به جز ۸ بایت نخست) مشخص می‌سازد.

فرمت و ساختار آپشن‌ها

آپشن‌های Hop-by-Hop و Destination بر اساس نوع (Type)، طول (Length) و مقدار (Value) تعریف می‌شوند؛ به همین دلیل به این شیوه، کدگذاری TLV (Type Length Value) نیز می‌گویند.

فیلد type: این فیلد ۸ بیتی بوده و نوع آپشن را مشخص می‌کند.

ترکیب دو بیت اول (باارزش‌ترین بیت‌ها) تعیین می‌کند که اگر یک گره در شبکه IPv6 این آپشن را تشخیص ندهد، چه واکنشی باید نشان دهد:

• 00: از روی آپشن رد شو و به پردازش بسته ادامه بده.
• 01: بسته را دور بینداز (Drop کن).
• 10: بسته را دور بینداز و یک پیام خطای ICMP ارسال کن.
• 11: مشابه حالت ۱۰ عمل کن، با این تفاوت که پیام خطا تنها در صورتی ارسال می‌شود که آدرس مقصد بسته، یک آدرس Multicast نباشد.

یک بیتِ بعدی مشخص می‌کند که آیا دیتای این آپشن در طول مسیر انتقال می‌تواند تغییر کند یا خیر:

• 0: دیتای آپشن در طول مسیر تغییر نمی‌کند؛ یعنی پس از ارسال، گره‌های میانی اجازهٔ دستکاری یا تغییر این داده را ندارند.
• 1: در طول مسیر ارسال بسته، گره‌های میانی مجازند مقدار این آپشن را تغییر دهند.

۵ بیت باقی‌مانده نیز اطلاعات خاص مربوط به خود آپشن را در بر می‌گیرند.

فیلد length: طول دادهٔ مقدار آپشن (Value) را بدون احتساب فیلد type و خود فیلد length در خود ذخیره می‌کند.

انواع آپشن‌ها

آپشن‌های قابل تعریف شامل موارد زیر هستند (البته گزینه‌های دیگری نیز وجود دارند که در این بخش به آن‌ها پرداخته نمی‌شود):

1. آپشن pad1: برای اضافه کردن یک بایت پدینگ (Padding) بدون نیاز به فیلدهای طول و مقدار به کار می‌رود.
2. آپشن padN: برای اعمال n بایت پدینگ استفاده می‌شود. از آنجا که خود فیلدهای type و length نیز جزئی از این پدینگ محاسبه می‌شوند، عملکرد آن به صورت زیر خواهد بود:

• در صورت نیاز به ۲ بایت پدینگ: type = 1 / length = 0
• در صورت نیاز به ۳ بایت پدینگ: type = 1 / length = 1 / value = یک بایت با مقدار 0

۳. آپشن Jumbo Payload Length: زمانی استفاده می‌شود که اندازه Payload بیشتر از ظرفیت معمول (بیش از ۶۵۵۳۵ بایت بر پایه فیلد ۳۲ بیتی) باشد. این یک آپشن Hop-by-Hop است و به روترها کمک می‌کند تا حجم بسته را با دقت پردازش کنند.

• در واقع Jumbo Payload Length زمانی به کار می‌آید که بسته‌ای با حجمی فراتر از ظرفیت استاندارد هدر IPv6 ارسال شود تا بتوان این اندازه را مشخص کرد (https://www.ietf.org/archive/id/draft-ietf-ipngwg-jumbo-00.txt).

۴. آپشن Router Alert: این آپشن نیز از نوع Hop-by-Hop است و به روترهای مسیر اعلام می‌کند که باید این بسته را تحویل گرفته و پردازش‌های بیشتری روی آن انجام دهند.

الزامات ترازسازی (Alignment Requirements)

برای پردازش بهینه و ارسال سریع‌تر بسته‌ها، هر آپشن باید از فرمت ترازسازی xn + y پیروی کند.

به عنوان نمونه، Jumbo Payload به ترازسازی 4n + 2 نیاز دارد. این ویژگی باعث می‌شود که خود پی‌لود دقیقاً در مضارب ۴ بایتی قرار بگیرد و عدد ۲ اضافه‌شده در انتها نیز نشان‌دهندهٔ ۲ بایتِ مربوط به فیلدهای type و length است.

نحوه پردازش و مدیریت آپشن‌ها

آپشن‌های Hop-by-Hop و Destination معمولاً در قالب داده‌های کمکی (Ancillary Data) برای توابع sendmsg و recvmsg تعریف می‌شوند.

بنابراین هنگام ارسال پیام، برنامه نیازی به پردازش‌های پیچیده ندارد و صرفاً کافی است هنگام فراخوانی تابع، مقادیر این آپشن‌ها را ارسال کند.

البته برای دریافت مقادیر این آپشن‌ها، مقادیر IPV6_RECVHOPOPTS و IPV6_RECVDSTOPTS باید حتماً در تنظیمات سوکت مشخص شده باشند.

این دو آپشن از طریق داده‌های کمکی به صورت زیر منتقل می‌شوند:

همان‌طور که مشخص است، محتوای هدر آپشن IPv6 از طریق ساختار cmsg_data منتقل می‌شود.

توابع هدر آپشن — ساخت آپشن‌ها هنگام ارسال بسته

تابع inet6_opt_init: این تابع هدر توسعه‌یافته (Extension Header) را مقداردهی اولیه می‌کند. اگر بافر هدر خالی (NULL) نباشد، هدر مقداردهی می‌شود؛ اما اگر طول بافر مضربی از ۸ نباشد، عملیات با خطا مواجه شده و ارور برمی‌گرداند.

تابع inet6_opt_append: وظیفه دارد تا آپشن تعیین‌شده را به هدر توسعه‌یافته بیفزاید. پارامترهای این تابع عبارتند از:

• پارامتر offset: طول کل آپشن‌های اضافه‌شده تا این لحظه را نشان می‌دهد و مقدار آن باید مقدار خروجی inet6_opt_init یا inet6_opt_append باشد.
• پارامتر type: نوع آپشنی که قرار است اضافه شود.
• پارامتر len: طول آپشن مدنظر.
• پارامتر align: بیانگر الزامات ترازسازی آپشن است. این مقدار همان x در رابطه xn + y است و مقدار y نیز باقی‌مانده محاسبه پارامترهای len و align خواهد بود.
• پارامتر databuf: بافری برای نگهداری مقدار آپشن.

تابع inet6_opt_finish: فرایند افزودن هدر توسعه‌یافته را به پایان رسانده و پدینگ‌های مورد نیاز را اعمال می‌کند.

• این کار سبب می‌شود که طول کل هدر دقیقاً مضربی از ۸ بایت شود.

تابع inet6_opt_set_val: مقدار آپشن را درون بافر داده قرار می‌دهد. برای databuf باید از اشاره‌گری که پس از فراخوانی inet6_opt_append به دست می‌آید، استفاده شود.

افزودن آپشن‌ها در دو مرحله (Pass) انجام می‌گیرد:

مرحله اول: محاسبه طول آپشن

• در این مرحله با استفاده از توابع inet6_opt_init ،inet6_opt_append و inet6_opt_finish، حجم مورد نیاز تخمین زده شده و اندازه بافر لازم برای آپشن‌ها محاسبه می‌شود.
• این مرحله به شکل یک اجرای آزمایشی (Dry Run) انجام می‌شود که در آن، برای پارامترهای extbuf و extlen تنها مقادیر NULL و 0 پاس داده می‌شوند.
• سپس با استفاده از سایز نهایی که توسط inet6_opt_finish بازگردانده شده، بافر مورد نظر تخصیص می‌یابد.

مرحله دوم: درج واقعی داده‌ها

• در این گام، مقادیر آپشن‌ها واقعاً داخل بافر درج می‌شوند و داده‌ها متناسب با نوع و طول هر آپشن در جایگاه مناسب قرار می‌گیرند.

علاوه بر این، می‌توان با اختصاص یک بافر به اندازه کافی بزرگ، مرحله اول را رد کرد؛ با این حال، اگر حجم آپشن از حد انتظار فراتر برود، ممکن است خطای سرریز بافر (Buffer Overflow) رخ دهد.

توابع هدرهای آپشن — پردازش آپشن‌های دریافت‌شده

تابع inet6_opt_next: برای پردازش بافر بعدی به کار می‌رود؛ این تابع درست مانند inet6_opt_append، برای پیمایش و پردازش داده‌ها در داخل بافر، مقدار offset را به‌روزرسانی می‌کند.

• پارامتر typep: نوع (Type) آپشنی را مشخص می‌کند که در حال حاضر در دست پردازش است.

تابع inet6_opt_find: با دریافت نوع آپشن مورد نظر، یک آپشن خاص را جستجو و پیدا می‌کند.

تابع inet6_opt_get_val: مقدار واقعی را از بافر آپشنی که توسط inet6_opt_next یا inet6_opt_find بازگردانده شده، استخراج می‌کند.

IPv6 Routing Header

این بخش برای قابلیت Source Routing به کار می‌رود که پیش‌تر در مبحث IPv4 توضیح داده شد. ساختار این هدر به شرح زیر است:

• فیلدهای next header و header extension length: این مقادیر دقیقاً مشابه همان مقادیری هستند که در آپشن‌های hop-by-hop و destination استفاده شده‌اند.
• تا زمانی که حجم کل از اندازه مجاز پکت فراتر نرود، هیچ محدودیتی برای تعداد آدرس‌های درون هدر وجود ندارد.
• فیلد segments left: تعداد نودهایی (Node) را نشان می‌دهد که بسته باید در ادامه مسیر از آن‌ها عبور کند.
• این هدر نیز مانند آپشن‌های hop-by-hop و destination از طریق توابع sendmsg و recvmsg منتقل می‌شود و دریافت آن تنها در صورتی امکان‌پذیر است که آپشن IPV6_RECVRTHDR فعال شده باشد.

توابع هدرهای آپشن — ساخت آپشن‌ها هنگام ارسال پکت

تابع inet6_rth_space: تعداد بایت‌های مورد نیاز برای ذخیره‌سازی Routing Header را محاسبه می‌کند.

• پارامتر type: نوع Routing Header را تعیین می‌کند که معمولاً مقدار آن IPV6_RTHDR_TYPE_0 است.
• پارامتر segments: تعداد روترهایی که بسته باید در طول مسیر از آن‌ها عبور کند.
• مقدار IPV6_RTHDR_TYPE_0 مربوط به قابلیت source routing در بین گزینه‌های مسیریابی است که البته به دلیل ملاحظات امنیتی، استفاده از آن کاملاً منسوخ و کنار گذاشته شده است (https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-3).

تابع inet6_rth_init: وظیفه مقداردهی اولیه Routing Header را بر عهده دارد و پوینتری به بافر حاوی هدر مسیریابی را برمی‌گرداند.

تابع inet6_rth_add: یک آدرس IPv6 جدید به Routing Header اضافه کرده و مقدار segleft را به‌روزرسانی می‌کند.

• پارامتر addr: آدرس IPv6 جدیدی که قرار است اضافه شود.

توابع هدرهای آپشن — پردازش آپشن‌های دریافت‌شده

تابع inet6_rth_reverse: بر اساس Routing Header دریافت‌شده، یک هدر جدید برای ارسال پاسخ در جهت معکوس ایجاد می‌کند.

• پارامتر in: بافری که Routing Header دریافتی در آن قرار دارد و مسیر اولیه بسته را نشان می‌دهد.
• پارامتر out: برای بازگرداندن Routing Header ساخته‌شده در مسیر معکوس استفاده می‌شود.

تابع inet6_rth_segments: تعداد سگمنت‌های موجود در Routing Header (همان rthbuf) را برمی‌گرداند؛ یعنی مشخص می‌کند که بسته از چند نقطه عبور خواهد کرد.

تابع inet6_rth_getaddr: آدرس مربوط به یک سگمنت مشخص را استخراج می‌کند و در صورت موفقیت، پوینتری به آن آدرس IPv6 برمی‌گرداند.

نمونه کد — UDP Client و Server

این بخش، عملکردی کاملاً مشابه کلاینت IPv4 TCP دارد؛ به این صورت که سرور آدرس‌های مسیر عبور را نمایش داده و سپس برای ارسال پاسخ به کلاینت، بسته را ارسال می‌کند.

کد مربوط به کلاینت به صورت زیر است:

در سمت سرور نیز، درست مانند نمونه‌های پیشین سرور UDP، یک سوکت ایجاد شده و تابع echo فراخوانی می‌شود؛ بنابراین در متن کتاب، فرآیند چاپ مسیر source route و معکوس کردن مسیر در تابع dg_echo به عنوان مثال آورده شده است.

IPv6 Sticky option

در فصل ۲۲ و این فصل دیدیم که تبادل انواع داده‌های کمکی (Ancillary Data) از طریق توابع sendmsg و recvmsg چگونه انجام می‌شود.

همچنین اشاره شد که برای هر یک از این انواع داده، فیلدهای cmsg_level و cmsg_type اختصاصی تعریف شده است.

اما اگر لازم باشد یک مقدار داده کمکی مشخص را روی تمامی پکت‌ها اعمال کنیم، تنظیم دستی level و type در هر بار ارسال بسیار ناکارآمد خواهد بود و بهتر است این آپشن مستقیماً روی خود سوکت تنظیم شود.

به این سازوکار Sticky Option گفته می‌شود که برای اعمال خودکار یک سری تنظیمات به تمامی پکت‌های ارسالی سوکت کاربرد دارد. البته در صورت نیاز، می‌توان Sticky Option را با داده‌های کمکی یک پکت خاص بازنویسی (Override) کرد.

• البته این قابلیت Override کردن تنها برای سوکت‌های UDP و Raw IP فراهم است؛ چرا که در TCP از sticky option صرفاً برای اعمال یک آپشن خاص روی کل نشست (Session) استفاده می‌شود.

خلاصه فصل

• پروتکل IPv4 در کل ۱۰ آپشن ارائه می‌دهد که شاخص‌ترین آن‌ها آپشن Source Routing است؛ هرچند امروزه به دلیل مسائل امنیتی، استفاده از آن در شبکه‌های مدرن بسیار کمرنگ شده است.
• در سوی دیگر، IPv6 تعداد ۶ هدر الحاقی (Extension Header) را معرفی می‌کند که مدیریت و دسترسی به آن‌ها از طریق رابط‌های تابعی اختصاصی امکان‌پذیر است.
• هدرهای الحاقی IPv6 عمدتاً با استفاده از داده‌های کمکی در قالب توابع sendmsg و recvmsg رد و بدل می‌شوند.