در ابتدا با توجه به شکل زیر مروری سریع به هدر IPV4 می اندازیم و سپس هدر IPV6 و تفاوت آن با IPV4 را بررسی خواهیم کرد. می خواهیم ببینیم چه ویژگی های جدیدی در هدر IPV6 اضافه شده است.

در هدر IPV4 علاوه بر آدرس مبدا و مقصد که هر کدام 32 بیت هستند، فیلد TTL برای جلوگیری از Loop، فیلد Checksum برای تشخیص خطا، فیلد Upper-Layer Protocol برای معرفی پروتکلی که روی IP سوار شده است، فیلد TOS برای کیفیت سرویس، فیلدهای Identifier، Flag و Fragmentation Offset با هدف Fragmentation و نهایتا فیلد Options که اختیاری است و در مواردی همچون Source Routing بکار گرفته می شود، دیگر فیلدهای هدر IPV4 را تشکیل می دهند.

هدر IPV4 بدون فیلد Option، 20 بایت است اما چنانچه فیلد Option در هدر IPV4 استفاده شود، سایز هدر IPV4 متغیر و نامعلوم است که این خود منشاء سربار اضافی در پردازش هدر IPV4 است و یکی از معایب IPV4 محسوب می شود.

فرمت هدر IPV4

فرمت هدر IPV4

هدر IPV6 نسبت به IPV4 چه تغییراتی داشته است؟ هدر IPV6 به دو بخش فیلدهای اجباری و فیلدهای توسعه ای و یا Extension Header تقسیم می شوند. فیلد های اجباری همواره در هدر IPV6 وجود دارند اما Extension Header ها در صورت لزوم به فیلدهای اجباری اضافه می شوند. در صورت اضافه شدن Extension Header، فیلد Next Header که از فیلدهای اجباری هدر IPV6 است به آن اشاره می کند و اگر بیش از یک Extension Header اضافه شود در هر Extension Header، فیلد Next Header به Extension Header بعدی اشاره می کند و بنابراین بر خلاف IPV4 که با اضافه شدن فیلد و یا فیلدهای Options، سایز هدر IPV4 برای پردازشگر متغیر و نامعلوم است در IPV6 سایز هدر IPV6 با کمک Next Header برای پردازشگر همواره معلوم و ثابت است و بنابراین بار پردازشی کمتری نیاز دارد. هدر IPV6 بدون در نظر گرفتن Extension Header ها 40 بایت ثابت است.

در هدر IPV6 نسبت به IPV4 چندین فیلد اضافه و چندین فیلد نیز کم شده است. البته فیلدهایی هم هستند که با همان مفهوم قبلی وجود دارند اما صرفا تغییر نام داده اند.

فرمت هدر IPV6

فرمت هدر IPV6

فیلدهایی که همچنان با همان مفهوم قبلی وجود دارند:

  • آدرس مبدا و مقصد فقط از 32 بیت به 128 بیت تغییر کرده اند و بنابراین فضای آدرسی بسیار بزرگتری را پوشش می دهند
  • فیلد TTL به Hop Limit تغییر نام داده است اما مفهوم آن تغییری نکرده است
  • فیلد TOS به Traffic Class تغییر نام داده است اما مفهوم آن تغییری نکرده است
  • فیلد Protocol به Next Header تغییر نام داده است. این فیلد هم در هدر اصلی IPV6 و هم در تمام Extension Header ها وجود دارد.

فیلدهایی که به هدر IPV6 اضافه شده اند:

  • فیلد Flow Label در هدر IPV6 به عنوان فیلد جدید اضافه شده است. به صورت کلی می توان گفت که این فیلد در کنار فیلد Traffic Class در کیفیت سرویس کاربرد دارد. اگر بخواهیم دقیق تر در مورد این فیلد صحبت کنیم، مبدا می تواند تمام ترافیک هایی که در یک Flow و یا یک Session قرار دارند را یک برچسب یکسان ارسال نماید. با این روش روترهای میانی می توانند بسته های مرتبط با یک Flow را تشخیص داده و با همه یک برخوردی یکسان داشته باشند. مثلا اگر اولین بسته ترافیک Real Time از یک Flow خاص با اولویت بالا در روتر سرویس دهی و ارسال می گردد، دیگر بسته های همان Flow نیز به همان نسبت سرویس دهی شوند. برای اینکار روتر باید بتواند بسته های مرتبط به یک Flow یکسان را شناسایی نماید. ضمنا فقط یکبار فیلدهای Routing header و Extension Header در ترافیک های مربوط به یک Flow پردازش می شوند. نتیجه پردازش در جایی از روتر ذخیره می شود و همه بسته های همان Flow با نتیجه بدست آمده سرویس دهی خواهند شد و نیاز به پردازش مجدد نخواهند داشت

فیلدهایی که از هدر IPV6 حذف شده اند:

فیلدهای زیر در هدر IPV6 نسبت به IPV4 کاهش یافته است

  • فیلد Fragmentation/Reassembly: در شبکه IPV4 در مبدا و یا مسیر، هر جایی که طول بسته از MTU لینک بزرگتر باشد، بسته مورد نظر به چند بخش تقسیم می شود و فیلدهای مرتبط با Fragmentation در هدر IPV4 به نحوی تکمیل می گردد که در مقصد، بسته های بخش بندی شده مجددا بسته بندی شوند. در IPV6 عمل Fragmentation فقط در مبدا مجاز است و در مسیر امکان Fragmentation وجود ندارد. در مبداء مکانیزمی به نام Path MTU Discovery حداقل MTU مسیر را شناسایی می کند و بسته ارسالی با سایز متناسب با حداقل MTU مسیر ارسال می گردد و بنابراین در مسیر نیازی به Fragmentation مجدد وجود ندارد. به همین دلیل این فیلد از هدر IPV6 حذف شده است و به Extension Header ها اضافه شده است. این فیلد به صورت کامل حذف نشده است زیرا که در مبدا همچنان امکان Fragmentation وجود دارد.
  • فیلد Checksum که برای تشخیص خطا استفاده می شود در هدر IPV6 حذف شده است. این بدان دلیل است که عمل تشخیص خطا هم در لایه 2 و هم در لایه 4 انجام می شود بنابراین انجام مجدد تشخیص خطا در لایه 3 اضافی به نظر می رسد و به همین دلیل در شبکه IPV6 از هدر حذف شده است.
  • فیلد Option که در هدر IPV4 فیلد اختیاری محسوب می شود در هدر IPV6 حذف شده است و Extension Header ها جایگزین آن شده است. فیلد Option در هدر IPV4 باید توسط تمام روترهای میانی پردازش شود اما اکثر Extension Header ها توسط روترهای میانی پردازش نمی شوند تا زمانی که بسته مورد نظر به مقصد می رسد و در مقصد پردازش خواهند شد.

همانطور که بارها گفته شد، Extension Header ها در IPV6 فیلدهای اختیاری هستند و در صورت لزوم ارسال می شوند. بعضی از Extension Header ها به شرح ذیل هستند:

  • Hop-by-Hop Extension Header: همانطور که از نام این هدر پیداست، این هدر باید توسط تمام روترهای میانی علاوه بر مبدا و مقصد پردازش شود و به همین جهت شبیه فیلد Options در هدر IPV4 است. چنانچه این فیلد در هدر IPV6 وجود داشته باشد، حتما باید به عنوان اولین Extension Header به بسته اضافه شود تا قابلیت پردازش توسط روتر را ساده نماید. کاربرد این فیلد عمدتا در پشتیبانی Jumbo-grams و یا Router Alert Option است که در پروتکل MLD و RSVP در IPV6 کاربرد دارد.
  • Destination Extension Header: همانطور که از نام آن پیداست، این هدر فقط در مقصد پردازش می شود و کاربرد آن عمدتا در IPV6 Mobility است
  • Routing Extension Header: کاربرد این فیلد عمدتا در IPV6 Mobility و همچنین Source Routing است. برای جلوگیری از حملات DDOS عمدتا Source Routing غیر فعال می شود
  • Fragmentation Extension Header: زمانی که بخواهیم بسته های Fragment شده ارسال نماییم، این فیلد ضروری است. یادآوری می شود که در IPV6 عمل Fragmentation فقط در مبدا مجاز است و اجازه Fragmentation در روترهای مسیر وجود ندارد
  • Mobility Extension Header: کاربرد این فیلد، همانطور که از نام آن پیداست، در سرویس IPV6 Mobility است.
  • AH Extension Header: این فیلد معادل AH در پروتکل IPSec در IPV4 است که برای احراز هویت و اطمینان از عدم جعل بسته های ارسالی است
  • ESP Extension Header: این فیلد معادل ESP در پروتکل IPSec در IPV4 است که علاوه بر احراز هویت و اطمینان از عدم جعل بسته های ارسالی، می تواند بسته های ارسالی را رمز نماید تا مانع از شنود شود.

نوشتن دیدگاه


تصویر امنیتی
تصویر امنیتی جدید