زوایای پنهان عملکرد IPv6؛ مزایا و تصورات اشتباه

در نوشته ها و گفته های متعدد در رابطه با IPv6 با این عبارت روبه رو می شویم که:

‏IPv6‎‏ عملکرد بهتری نسبت به ‏IPv4‎‏ دارد.

و گاهی ‏در پی این عبارت دلایلی نیز آورده می شود. اما چه میزان این مطلب و دلایلی که در پی آن به عنوان مواردی برای ‏بهبود عملکرد ‏IPv6‎‏ مطرح می شوند، صحت دارند؟ ‏بیان بسیاری از این دلایل شاید تنها در وجهه‌ی عمومی و همراه ساختن عموم جامعه در حرکت به سمت استفاده از IPv6 قانع‌کننده و مقبول باشند اما از لحاظ فنی این انتظار وجود دارد که یک کارشناس حوزه‌ی اینترنت، توانایی استدلال در رد یا قبول هر یک از دلایلی که در پی این عبارت مطرح می شوند را داشته باشد. در این مقاله قصد داریم تا نگاهی فنی تر به این دلایل داشته باشیم.

***

در IPv6 انجام تغییراتی در ساختار و قالب این پروتکل سبب ایجاد بهبود کارایی آن در برخی موارد گشته که عبارتند از:

۱-‏ فضای آدرس دهی بسیار بزرگتر
اولین مزیتی که برای ‏IPv6‎‏ ‏ بیان می شود آن است که ‏IPv6‎‏ فضای آدرس دهی بزرگتری نسبت به ‏IPv4‎‏ ‏داشته و به همین دلیل می تواند تعداد آدرس های بیشتری را فراهم آورد. بله این عبارت درست است! ‏IPv6‎‏ ‏به دلیل ۱۲۸ بیتی بودن قادر است تقریبا ‏‎۳٫۴*۱۰^۳۸‎‏ آدرس ممکن را فراهم کند که با گسترش شبکه ها ‏و افزایش دستگاه هایی که توانایی اتصال به اینترنت را دارند، این مقدار آدرس ‏IP‏ تا مدت های زیادی ‏جوابگوی نیازها خواهد بود. اما این موضوع چه ارتباطی با بهبود عملکرد ‏IPv6‎‏ ‏دارد؟

تصور کنید آنقدر آدرس ‏IP‏ وجود دارد که هر دستگاه می تواند Public IP (آدرس عمومی اینترنی) متعلق به خود را داشته ‏باشد. دقت کنید که گفته شد آدرس Public IP‏. بله دقیقا منظور آدرس های ‏IP‏ ای هستند که در دنیای اینترنت ‏قابل مسیریابی می باشند. به نظر شما زمانی که هر دستگاه بتواند یک آدرس ‏Public IP مخصوص به خود ‏داشته باشد و خود به صورت مستقیم به اینترنت متصل گردد، چه مزیتی وجود خواهد داشت؟

برای رسیدن به جواب این سوال، به چندین سال قبل، زمانی که برای اولین بار احساس شد که آدرس های عمومیِ ‏IPv4‏ رو به اتمام هستند، باز می گردیم. در آن زمان اولین راهکاری که برای نجات ‏IPv4‎‏ ‏از این ‏اوضاع مطرح شد، راهکاری به اسم ‏Network Address Translation‏ یا همان ‏NAT‏ بود.

عملی که این ‏راهکار انجام می داد آن بود که دستگاه‌هایی که در داخل یک ساختار (مثلا دستگاه های داخل یک سازمان یا ‏دستگاه های داخل خانه و یا …) قرار داشتند، برای آن که بتوانند با هم ارتباط برقرار نمایند، از آدرس هایی ‏استفاده می کردند معروف به Private IPv4 (‏RFC1918‎‏) که این آدرس ها در اینترنت قابل مسیریابی نبودند و اگر قرار بود این دستگاه ها به اینترنت متصل ‏شوند و با سایر دستگاه ها در دنیای اینترنت ارتباط داشته باشند، Private IP‏ آن ها توسط ‏gateway‏ آن ساختار (مثلا مودم یا روتر) به یک Public IP‏ ترجمه می شد. به این ترتیب دیگر ‏نیازی نبود که همه‌ی دستگاه های درون یک ساختار یک IP آدرس ‏Public‏ مجزا و مخصوص به خود داشته ‏باشند، بلکه کافی بود به کل ساختاری که دستگاه ها در آن قرار داشتند تنها یک آدرس ‏عمومی IPv4 تعلق ‏گیرد و هر دستگاهی که قصد برقراری ارتباط با اینترنت را داشت، آدرس ‏Private‏ آن به آدرس ‏Public‏ ‏اختصاص یافته به ساختار ترجمه می گشت. ‏

این ترجمه ی آدرس، خواه یا ناخواه باعث ایجاد پیچیدگی‌های سخت افزاری در دستگاه ‏gateway‏ و همین ‏طور صرف زمانی (هرچند اندک) برای ترجمه ی آدرس ها از ‏Private‏ به ‏Public‏ و برعکس می شد. از سوی ‏دیگر پیکربندی دستگاه ‏gateway‏ برای پشتیبانی از ‏NAT‏ در برخی مواقع خیلی سخت و باعث تاثیر سو بر ‏یکسری عملکردهای دیگر می گشت.‏

حال بیایید به سراغ سوالمان برویم: اگر هر دستگاهی بتواند برای خود یک Public IP مستقل خود داشته ‏باشد چه مزیتی خواهد داشت؟ بر اساس آن چه که بالا گفته شد مفهوم ‏NAT‏ در چنین حالتی به طور کل از ‏بین می رود و هنگامی که ‏NAT‏ نباشد، پیچیدگی سخت افزاری و زمان اضافی برای ترجمه‌ی آدرس پکت ‏های ورودی و خروجی به دستگاه ‏gateway‏ کاهش پیدا می کند و از سوی دیگر پیکربندی ساختار شبکه ‏هم به طرز قابل ملاحظه ای ساده تر می گردد!‏

‏۲-‏ ارتباطات ‏end-to-end
زمانی که هر دستگاهی آدرس ‏Public IP‏ مختص خود را داشته باشد و نیازی به ‏NAT‏ نباشد، به این معنی ‏است که ارتباط دستگاه ها کاملا به صورت ‏end-to-end‏ خواهد بود در نتیجه در ساختارهای ‏IPv6‎‏، ‏اپلیکیشن های ‏peer-to-peer‏ ای مثل ‏VoIP‏ عملکرد کارآمدتر و موثرتری خواهند داشت.‏

‏۳-‏ آدرس دهی آسان تر دستگاه ها
یکی از دغدغه ها در ساختارهای ‏IPv4‎، روش های ‏IP‏ دهی به دستگاه ها است. در چنین ساختارهایی ‏اطلاعاتی مثل آدرس ‏IP، ‏Gateway، ‏DNS Server‏ و … برای یک دستگاه یا باید به صورت دستی برای آن ‏دستگاه تنظیم شوند و یا دستگاه ها این اطلاعات را از طریق یک ‏DHCP Server‏ به دست آورند.

در ‏ساختارهای ‏IPv6‎‏ ‏ این مکانیزم ساده تر شده است. دستگاه ها برای به دست آوردن اطلاعات شبکه هم می ‏توانند از یک ‏DHCP‏ سرور (‏DHCPv6‎‏) استفاده نمایند که به این روش اصطلاحا ‏Stateful Address ‎Auto Configuration‏ گفته می شود و یا این که در روشی جذابتر، بطور خودکار صاحبِ یک ‏Global IPv6‎ ‎Address‏ ‏‎شوند که به این روش اصطلاحا ‏Stateless Address Auto Configuration‏ گفته می ‏شود. در این روش یک ‏Host‏ از طریق یک یا چند ‏Link Prefix‏ ای که از طریق یک پیام ‏RA (Router ‎Advertisement)‎‏ به دست آورده، و اضافه‌کردن آن به ابتدای ‏Interface ID‏ که برای خود محاسبه کرده، ‏صاحب یک ‏Global IPv6 Address‏ ‏می‌شود. پس در ساختارهای ‏IPv6‎‏، حتی اگر هیچ تنظیم خاصی هم ‏صورت نگیرد و دستگاه فقط ‏IPv6‎ Enabled‏ باشد کافی است تا یک آدرس ‏IP‏ عمومیِ مختص به خود را داشته باشد.‏

همین امر سبب آسان تر شدن مدیریت آدرس های ‏IPv6‎‏ می شود. تصور کنید در یک ساختار ‏IPv4‎‏ ‏قرار بر ‏تغییر طرح آدرس دهی شبکه باشد. در چنین شرایطی شما به عنوان مدیر شبکه باید تک تک دستگاه ها را ‏دوباره آدرس دهی نمایید اما در ‏IPv6‎‏ با همین ویژگیِ آدرس‌دهی خودکار، سربارِ کاریِ شما نیز به عنوان یک مدیر ‏به مراتب کاهش چشمگیری پیدا کرده و ساده تر می شود.‏

‏۴-‏ افزایش سرعت در پردازش پکت ها
قبل از پرداختن به این مورد بهتر است نگاهی به هدر ‏IPv4‎‏ و هدر ‏IPv6‎‏ بیاندازیم:‏

IPv4 Header
هدر IPv4
IPv6 Header
هدر IPv6

دو موضوع در ‏IPv4‎‏، پردازش پکت های مربوط به آن ‏را زمان‌بر می‌کند. اول آن که هر روتری که یک پکت ‏IPv4‎‏ ‏دریافت کند باید برای بررسی عدم وجود خطا و مشکل در پکتی که دریافت کرده، مجددا ‏Checksum‏ را برای آن پکت محاسبه کرده و مقدار به دست آمده را با مقدار فیلد ‏Checksum‏ پکت ‏دریافتی مقایسه نماید. دوم این که اگر قرار بر انجام یکسری عملیات های اختیاری برای پکت ‏IPv4‎‏ ‏باشد ‏‏(مثلا ‏Source Routing‏)، این عملیات ها توسط مقداری که در فیلد ‏Option‏ در هدر پکت ‏IPv4‎‏ قرار ‏می گیرند، مشخص می شوند و هر روتری که یک پکت ‏IPv4‎‏ ‏دریافت نماید باید فیلد ‏option‏ در هدر ‏IP‏ آن ‏پکت را نیز بررسی کند.‏

اگر این موضوع را در نظر بگیریم که پروتکل‌های لایه‌های بالاتر دارای مکانیزم‌های تشخیص و تصحیح خطا ‏هستند، آیا نمی‌توان ‏Checksum‏ را از هدر ‏IP‏ حذف نمود و به این ترتیب زمانی برای محاسبه ی ‏checksum‏ ‏صرف نگردد؟
یا به عنوان مثال، اگر برای پکتی قرار نباشد هیچ عملیات خاصی صورت گیرد و فیلد ‏option‏ ‏هم خالی باشد، نمی‌توان کاری کرد که روتر مجبور به انجام این بررسی اضافی نباشد؟ و یا فقط برای پکت‌هایی این بررسی را انجام دهد که در فیلد ‏option‏ آن ها مقداری وجود داشته باشد؟

افرادی که در حال توسعه ی ‏IPv6‎‏ ‏بودند نیز دقیقا با در نظر گرفتن این سوال ها به یک نتیجه ی مهم ‏دست یافتند: آن ها نه تنها فیلدهای ‏checksum‏ و ‏option، بلکه تمام فیلدهای اضافی را که معمولاً در شرایط عادی اصلا استفاده نشده (که صرفاً بدلیل وجود در IPv4 Header مورد بررسی قرار می‌گرفتند) را از هدر ‏IPv6‎‏ ‏حذف کردند و به این ترتیب به دو ‏طریق سبب افزایش سرعت پردازش و کارایی هدر پکت ‏IPv6‎‏ شدند:‏

  • اول آن که یک پکت ‏IPv6‎‏ فقط اطلاعات مورد نیاز را حمل می کند و هیچ فیلد بلااستفاده ‏ای در هدر آن وجود ندارد.‏
  • دوم آن که دیگر نیازی به پردازش اضافی برای بررسی عملکردهای اختیاری نیست، چرا که ‏اطلاعات مربوط به این عملکردها توسط هدرهای جداگانه ای حمل می شوند که اصطلاحا ‏Extension Header‏ نامیده می شوند. ‏

همین دو عامل سبب می شوند که روترهایی که در میانه‌ی راه رسیدن یک بسته از یک مبدا به یک مقصد ‏قرار دارند، دیگر نیازی به صرف زمان برای تجزیه و تحلیل هدر پکت ‏IPv6‎‏ ‏و انجام اعمالی مثل تکه تکه ‏کردن پکت (Fragmentation) و سرهم کردن مجدد آن‌ها (reassembly) نداشته باشند و به این ترتیب سربار پردازش روترها و پیچیدگی ‏سخت افزاری کاهش پیدا کرده و پردازش پکت ها سریعتر انجام شود.‏

۵-‏ پشتیبانی ذاتی از ‏Multicasting‏ و مدیریت کارآمدتر جریان ترافیک در ساختار
یکی از مشکلات ‏IPv4‎‏ ‏ضعف و محدودیت آن در اعمال ‏Multicasting‏ است. در ساختارهای ‏IPv4‎‏ ‏این ‏عمل تنها می‌تواند به زیرشبکه ها خلاصه شود و اکثر روترهای اینترنتی نمی توانند از ‏IPv4 Multicasting‏ ‏پشتیبانی کنند. در ‏IPv6‎‏ این مشکل دیگر وجود ندارد و علت آن نیز پشتیبانی ذاتی ‏IPv6‎‏ ‏از ‏Multicasting‏ می باشد. تمام دستگاه هایی که ‏IPv6‎‏ ‏بر روی آن ها فعال شود در کم ترین حالت، به ‏صورت خودکار عضو یک گروه ‏Multicast‏ یکسان خواهند شد. همینطور برخلاف ‏IPv4‎‏ که برای عمل ‏Multicasting‏ یک رنج محدود ‏IP‏ در نظر گرفته شده بود، در ‏IPv6‎‏ ‏ این بازه به مراتب خیلی بزرگتر شده ‏و دیگر محدودیت های تعداد ‏IP‏ های ‏Multicast‏ نیز وجود ندارد.‏

اما ‏IPv6‎‏ مکانیزم جالبتری را نیز برای مدیریت بهتر و کارآمدتر جریان ترافیک در یک ساختار ارایه می دهد، ‏یعنی آدرس های ‏Anycast.

با استفاده از آدرس های ‏Anycast‏ می توان به مجموعه ای از nodeها، آدرس ‏یکسانی اختصاص داد. به عنوان مثال تصور کنید در ساختاری چند سرور وجود دارد که سرویس یکسانی ارایه ‏می‌دهند، مثلاً چندین DNS Server در شبکه‌ی وسیع یک سرویس‌دهنده‌ی اینترنت. همه ی آن ها می توانند یک آدرس Anycast‏ یکسان داشته باشند، و روتر زمانی که قرار باشد ‏ترافیک سرویس مربوطه را به یکی از این سرورها ارسال کند، ‏نزدیکترین سرور را به صورت خودکار انتخاب می نماید؛ اگر این سرور نزدیکتر بنا به هر دلیلی ‏fail‏ شود، ‏روتر بلافاصله سرور نزدیکتر بعدی را جایگزین آن خواهد کرد.‏

موارد بالا به صورت خلاصه بر تغییراتی که سبب بهبود عملکرد IPv6 می شدند اشاره داشتند اما در این میان اشتباهات و تصورات نادرستی نیز در رابطه با IPv6 و کاربردهای آن وجود دارد:

۱-‏ IPv6‎‏ از ‏IPv4‎‏ امن تر است:‏
این گفته معمولاً بخاطر بحث پشتیبانی ذاتی IPv6 از IPSec بیان می‌شود، اما چنین نتیجه‌گیری چندان هم درست نیست چرا که هم در ‏IPv4‎‏ و هم در ‏IPv6‎‏، زمانی این امنیت وجود دارد ‏که شما ‏IPSec‏ را پیاده سازی نمایید. مزیت و برتری ‏IPv6‎‏ نسبت به ‏IPv4‎‏ در بحث ‏IPSec‏ آن است که، ‏در ‏IPv6‎‏ اطلاعات مربوط به ‏IPSec‏ از طریق ‏Extension Header‏ ها منتقل می شوند، و علی‌الخصوص دیگر مشکلی برای انتقال ترافیک ‏Multicast‏ از طریق یک ‏IPv6 IPSec VTI‏ وجود ندارد. در ‏IPv4‎‏ انتقال ترافیک ‏Multicast‏ از طریق یک ‏IPv4 IPsec VTI‏ امکان پذیر نیست و برای این منظور باید از ‏تانل هایی چون ‏GRE‏ استفاده شود. این بیشتر بمعنی پیچیدگی کمتر هست، تا امنیت بیشتر!

چه بسا IPv6 به خاطر داشتن مکانیزم های Plug-and-Play، عدم فیلترینگ ICMPv6 در خیلی از موارد و … مشکلات امنیتی بیش تری نسبت به IPv4 بهمراه بیاورد.

۲-‏ با از بین رفتن ‏NAT‏ در ‏IPv6‎‏، امنیت کاهش می یابد:‏
در حقیقت هیچ گاه ‏NAT‏ به معنای مکانیزمی برای ایجاد امنیت نبوده و همانطور که در ابتدای این متن نیز ‏توضیح داده شد، هدف از ‏NAT‏ تنها کاهش نیاز به آدرس های ‏عمومی IPv4 بوده است و این امر که با ‏NAT‏ ‏آدرس حقیقی دستگاه مخفی می ماند، برداشت درستی نیست. از سوی دیگر با توجه به وسعت آدرس‌های IPv6، اسکن‌کردن این آدرس‌ها‎‏ به منظور یافتن ‏هاست‌های آسیب پذیر امری بی فایده تلقی می شود. پس بطور کلی، وجود یا حذف ‏NAT‏ هیچ تاثیری بر امنیت یا عدم امنیت در ‏IPv6‎‏ نخواهد داشت.‏

۳-‏ IPv6‎‏ از ‏QoS‏ پشتیبانی بهتری به عمل می آورد:‏
یکی از عواملی که منجر به این برداشت اشتباه می گردد درک اشتباه نحوه‌ی عملکرد فیلدی با نام ‏Flow ‎Label‏ در هدر ‏IPv6‎‏ می باشد. با ‏Flow Label‏ می توان پکت های متعلق به یک جریان یکسان ‏‏(یعنی ترافیکی که مبدا و مقصد یکسانی داره) را برچسب زد و مشخص نمود که این پکت ها همیشه ‏از یک مسیر یکسان به سمت مقصد مورد نظر ارسال شوند. شاید این فیلد به نوعی به جریان ارسال ترافیک ‏بر روی لینک‌‎هایی با پهنای‌باند کم کمک کند اما در لینک هایی با پهنای‌باند بالا نیز هم‌چنان مجبور خواهید بود که ‏اعمال مربوط به ‏DiffServ‏ را از طریق فیلد ‏DSCP‏ که در هدر ‏IPv6‎‏ با نام ‏Traffic Class‏ نامیده می شود، ‏انجام دهید. بنابراین ‏QoS‏ در ‏IPv6‎‏ و ‏IPv4‎‏ فرق چندانی با یکدیگر نخواهند داشت.‏

۴-‏ IPv6‎‏ باعث کاهش سایز Routing Table خواهد شد:‏
گاها اینگونه مطرح می شود که با آدرس دهی سلسله مراتبی و تجمیع آدرس های ‏IPv6‎‏ می توان سایز ‏جداول ‏Route‏ را کاهش داد. این مساله در ‏IPv4‎‏ نیز به همین شکل صادق است و تفاوت چندانی بین ‏IPv4‎‏ ‏و ‏IPv6‎‏ در این مبحث وجود ندارد. از سوی دیگر بیان می شود که مکانیزم های ‏Multihoming‏ در ‏IPv6‎‏ ‏چون ‏SHIM، ‏SCTP‏ و … می توانند به امر کاهش سایز جدوال ‏Route‏ کمک کنند اما حقیقت آن است که ‏IETF‏ با وجود چندین سال تلاش هنوز نتوانسته است این راهکارها را عملی نماید و هنوز هر فردی می تواند آدرس Global خود را داشته و بر حجم جداول Route بیافزاید.

۵-‏ IPv6‎‏ سبب کاهش مشکلات ‏BGP‏ می گردد:‏
نه تنها ‏IPv6‎‏ مشکلات ‏BGP‏ را کم نمی کند بلکه ممکن است بر این مشکلات نیز بیافزاید. همانطور که در ‏بالا نیز ذکر گردید در دنیای ‏IPv6‎‏ هرکسی می تواند آدرس ‏global‏ خود را داشته باشند، پس نه تنها سایز ‏جداول ‏Route‎‏ اینترنتی افزایش می یابد بلکه ‏‎ IPv6 BGP Routing Tableها، فضای بیشتر و متعاقبا ‏پهنای باند بیشتری نسبت به ‏IPv4 BGP Routing Table‏ ها استفاده می کنند.‏ البته با توجه به اینکه روز به روز تجهیزات اینترنتی قوی‌تر شده و media های جدید پهنای باند بیشتری ارائه می‌کنند، نگرانی مصرف پهنای‌باند بیشتر بخاطر سایز بیشتر IPv6 Routing Table قابل چشم‌پوشی خواهد بود. اما مشکل دیگری که بواسطه‌ی افزایش تعداد Route ها در دنیای اینترنت و BGP بوجود می‌آید، بحث Flapping روت‌ها خواهد بود که باعث ناپایداری اینترنت خواهد شد. البته به مرور زمان مکانیزم‌هاو سیاست‌های بهتری جهت افزایش Stability جداول روتینگ بوجود می‌آیند کمااینکه مثلاً در حال حاضر بحث Route Flap Damping وجود دارد (RFC7196 و RIPE-580)

آن چه در این مقاله بررسی گردید، عملکرد IPv6 ای است که هنوز در حال توسعه و تلاش برای بهبود و گسترش می باشد. چه بسا در آینده برای تمام معایب ذکر شده در بالا راهکاری عملی یافت شود و چه بسا خیلی از مواردی که به عنوان مزیت برای این پروتکل مطرح گردید هیچ گاه در دنیای واقعی عملی نشوند. در هر حال حرکت به سوی IPv6 آغاز شده و با تمام مزایا و معایب، دیر یا زود همه درگیر این پروتکل خواهند شد.

نویسنده: محمّد مقدّس‌

یک عکاس آماتور، علاقمند به شبکه ها و IP، ساکن اینترنت!

6 دیدگاه برای “زوایای پنهان عملکرد IPv6؛ مزایا و تصورات اشتباه”

  1. سلام
    اول ممنون از مطالب کاربردی تون
    در مورد بخش دوم تصورات نادرست یعنی تاثیر NAT در امنیت سوالی برام بوجود اومده
    اونم اینکه خب در این حالت مهاجم نمیتونه مستقیما با کاربر در ارتباط باشه و در نتیجه امکان نفوذ به سیستم رو به حداقل میرسونه البته در NAT متود هایی مثل PAT و Full Cone NAT وجود داره ولی در حالت پیش فرض NAT خب بنظرم باعث ایجاد امنیت در سمت داخلی میشود تا حدودی
    ممنون میشم اگر اشتباه برداشت کردم توضیح دهید یا لینکی برای توضیح مطلب قرار دهید
    ممنون

    1. سلام. ممنونم.
      بحث جالبی رو مطرح کردین.

      قضیه اینه که NAT همراه خودش یکسری جوانب داره که میشه گفت نمود امنیتی دارن. اما اصل NAT، “بنظر بنده” نباید بعنوان یک ویژگی و افزوده ی امنیتی شناخته بشه.
      فکر کنم بهتر باشه بگیم NAT ابزاری در طراحی هست که در معماری امنیتی ازش در موقع نیاز میشه استفاده کرد (مثلاً برقراری ارتباط با یک شبکه ی دیگه) اما به صرف خود جای firewall رو نمی گیره و یک ویژگی امنیتی نیست.

      شاید خوب باشه رفتار انواع NAT رو از بالا و بطور کلی بررسی کنیم:

      • در NAT معمولی یا یک-به-یک که در RFC2663 بهش پرداخته شده، host داخلی کلاً از زمانی که session رو آغاز کنه در خطر خواهد بود پس بحث امنیت کلاً منتفی هست
      • بحث NAPT (یا NAT overload یا masquerade یا PAT) که در RFC2663 و RFC4787 بهش پرداخته شده، بطور کلی میگه وقتی host داخلی یک session ایحاد کرد در NAT table یک ردیف جدید ایجاد میشه و بسته NAT میشه و به سمت مقصد ارسال میشه؛ و اگر یک Session جدید از بیرون اومد که ناخواسته هست اون ارتباط منع میشه. ولی بهتره دوحالت مشخص رو که در RFC4787 اومده بررسی کنیم اینجا:
        • در مدل Endpoint independent mapping جدول NAT فقط اطلاعات مبدا رو نگه میداره؛ آدرس IP، پروتکل و پورت. در این حالت به محض ایجاد session، هر host خارجی میتونه از اون session باز استفاده کنه. این نوع پیاده سازی رو من شخصاً بررسی نکردم که کجا استفاده شده اما فکر میکنم در تجهیزات قدیمی یا تجهیزات خانگی رده پایین به اینصورت باشه، پس باز هم هیچ امنیتی ارائه نمیشه.
        • در مدل Address and Port-Dependent Mapping، که عموماً در پیاده سازی ها بروزتر استفاده میشه (مثلاً JunOS یا نسخه های مختلف IOS) عملیات NAT بر مبنای ۵-tuple صورت می گیره که مشابه عملکرد فایروال Stateful هست اما باید در نظر داشت که تجهیزی که NAT میکنه (مثلاً روتر) محتویات session و معتبر بودن header هارو بررسی نمی کنه چون این وظیفه NAT و یا تجهیز روتر و سوئیچ نیست. (در حالت عمومی)
        • نهایتاً میشه نتیجه گرفت که NAPT به نوعی یک packet filtering اولیه رو همراه خودش داره.
      • و در آخر مدل Stateless NAT که در برخی الگوریتم های IPv6-to-IPv4 (و بالعکس) وجود داره که که در این حالت آدرس IPv6 بر اساس یک الگوریتم یا تنظیم دستی از روی IPv4 محاسبه میشه؛ خب اینم شد مثل همون NAT معمولی.

      در کنار مواردی که عرض کردم، NAT گاهی مشکلات/محدودیت/پیچیدگی رو هم بهمراه خودش میاره، مخصوصاً در شرایطی که end-to-end connectivity مهم هست (مثلاً در IPSec که authentication و encryption به ثبات IP address ها در IP header وابستگی دارن؛ البته که میشه یجورایی این مشکلات رو دور زد اما همین دور زدن خودش یک پیچیدگی اضافی هست)

      پیشنهاد میکنم دو بخش Security Considerations از RFCهای ۲۹۹۳ و ۲۶۶۳ رو مطالعه کنین:

      بجز توضیحاتی که بنده عرض کردم، در مطالب زیر هم توضیحات خیلی خوبی ارائه شده:

      فراموش نکنیم: NAT برای حل موقتی مشکل کمبود IPv4 بوجود اومد! (که امروزه گاهی به عنوان یک آپشن امنیتی دیده میشه). اگر تصور کنیم NAT برای ما امنیت بوجود آورده ممکنه از سایر بحث های امنیتی دور بشیم.
      و لطفاً گفته های بنده مبنی بر این نباشه که نباید از NAT استفاده کرد؛ عرضِ من همونیه که اول گفتم: “NAT ابزاری در طراحی هست که در معماری امنیتی ازش در موقع نیاز میشه استفاده کرد (مثلاً برقراری ارتباط با یک شبکه ی دیگه) اما به صرف خود جای firewall رو نمی گیره و یک ویژگی امنیتی نیست.”

      موفق باشید.

  2. عملکرد IPv6 نسبت به IPv4 در حال حاضر همیشه بهتر نیست. شاید مزایا یا قابلیت متفاوتی داشته باشه ولی نباید اونها رو با عملکرد بهتر اشتباه گرفت. پیشنهاد میکنم ارایه Vaibhav Bajpa در نشست IETF99 که پنج شنبه گذشته در پراگ برگزار شد رو ببینید. در تحقیقی که در یک بازه سه ساله در مورد عملکرد IPv6 با محتوای یوتیوب انجام دادند مشخص شد که IPv4 عملکرد بهتری داشته:

    However, even though clients prefer streaming videos over IPv6, we observe
    worse performance over IPv6 than over IPv4. We witness consistently higher TCP
    connection establishment times and startup delays (∼۱۰۰ ms or more) over IPv6.
    We also observe consistently lower achieved throughput both for audio and
    video over IPv6. We observe less than 1% stall rates over both address
    families.

    موفق باشید.

    1. سلام. خیلی ممنون از اینکه سر زدید

      بنده هم کاملاً با صحبت شما موافقم و در این مطلب هم سعی شد به این اشاره بشه که IPv6 چه مزایایی همراه خودش داره، و مهم تر اینکه چه تصورات غلطی درباره‌اش وجود داره که باید ازشون پرهیز کرد.
      بنظر بنده، اینکه بگیم IPv4 یا IPv6 عملکرد بهتری نسبت به هم دارند برداشت برداشت کاملی نیست. منظورم صرف پروتکل هست.
      اما مستقلاً در رابطه با IPv6، من فکر میکنم علت اینکه گاهی حس میشه IPv4 نسبت به دیگری performance بهتری داره عموماً بخاطر اینه که هنوز IPv6 از لحاظ Adoption بجایی که باید تا امروز می‌رسید، هنوز نرسیده و متاسفانه خیلی اوقات ترافیک درگیر sub-optimal routing میشه. ولی خب ما در IETF در تمام Area ها تعهدنامه ای امضا کردیم که تمام پروتکل ها باید با اولیت برای IPv6 طراحی بشن. حتی در IETF97، یک اظهاریه توسط IAB منتشر شد که استانداردهای شبکه باید کاملاً از IPv6 پشتیبانی کنن و در پروتکل های جدید یا افزونه‌های جدید بر پروتکل‌های قبلی، دیگه IPv4-compatibility بعنوان یک requirement نباشه. حتی یک working group ایجاد شده تحت نام Sunsetting IPv4. امیدوارم این تلاش کمک کنه که IPv6 به اونجایی که لازمه برسه.

      تحقیقی که اشاره فرمودین قرار هست در نشست مربوط به IRTF (داخل IETF99 پراگ) ۲۰ جولای در جلسه گروه maprg ارائه بشه. درواقع هنوز برگزار نشده اما معمولاً توی IETF بعضیا سریع هستن (که خیلی هم خوب هست) و از قبل اسلایدها رو قرار میدن تا افراد بتونن برنامه ریزی کنن و وقت بگذارن تا جلسات مفید باشه و بتونن بحث کنن.
      بنده از ۴ IETF قبلی همه رو شرکت کردم ولی خب بر حسب جهت‌گیری کارم، بیشتر در Routing Area (معمولاً wgهای i2rs، idr، mpls، rtgwg و spring) فعال هستم. اما اگر خودتون در IETF99 شرکت نمی‌کنین و فکر میکنین این ارائه ممکنه مورد علاقتون باشه شاید بتونم در اون جلسه برم و خروجی‌اش رو به اشتراک بگذارم؛ البته از چند IETF قبل همه جلسات record میشن و در YouTube قرار میگیرن. بجز این خودتون هم میتونین بصورت remote و رایگان در جلسات شرکت کنین.
      از IETF97 سئول، بنده معمولاً در کانال تلگرام بلاگ و اینستاگرام مطالبی رو از جلسات به اشتراک میگذارم که اگر علاقه داشتید خوشحال میشم دنبال کنین.

      خیلی ممنون

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *