مکانیزم های مهاجرت به IPv6: راهکار ۴۶۴XLAT

با استفاده از راهکار NAT64 دستگاه‌های موبایل IPv6-only توانایی برقراری ارتباط با سرورهای IPv4-only را داشتند. اما NAT64 به تنهایی جوابگوی نیازهای شبکه های موبایل نبود چرا که اکثر نرم‌افزارهای موبایل هم چنان بر مبنای IPv4 می باشند. به همین دلیل راهکار دیگری با نام ۴۶۴XLAT معرفی گردید.

با استفاده از این مکانیزم آدرس IPv4 آن دسته از کاربران (بیشتر موبایل و نرم‌افزارهای موبایلی) که IPv6 را پشتیبانی نمی کنند، توسط نرم‌افزاری با نام Customer-side Translator یا به اختصار CLAT، به یک آدرس IPv6 با mask ای خاص، /۹۶، ترجمه شده و پکت از طریق ساختار IPv6 به سمت PLAT یا Provider-site Translator ارسال می شود.

PLAT با گشودن پکت IPv6 به آدرس های Private IPv4 مبدا و مقصد داخل پکت دست یافته و پکت را به مقصد مورد نظر ارسال می کند. به عبارتی در این روش کلاینت و سرور فقط از طریق Private IPv4 خود در بستری مبتنی بر IPv6 می توانند با یکدیگر ارتباط برقرار نمایند.

روش ۴۶۴XLAT تنها از مدل های کلاینت-سروری پشتیبانی می کند و نمی‌توان از طریق آن یک ارتباط peer-to-peer بر اساس IPv4 Private را برقرار ساخت. ویدیوی زیر از RIPE NCC به تشریح عملکرد این مکانیزم می پردازد (به جهت سهولت دسترسی هم وطنان داخل کشور، این ویدیو در آپارات آپلود شده است).

ادامه خواندن “مکانیزم های مهاجرت به IPv6: راهکار ۴۶۴XLAT”

مکانیزم های مهاجرت به IPv6: راهکار NAT64

یکی از مشکلات بر سر راه Mobile Provider ها فراهم کردن شرایطی است که هاست های IPv6-only بتوانند با سرورهای IPv4-only ارتباط برقرار نمایند. NAT64 مکانیزمی است بر پایه ی Network Address Translation (NAT) که با نگاشت آدرس IPv6 هاست متصل به پروایدر به یک آدرس IPv4، این مشکل را برطرف می سازد. ادامه خواندن “مکانیزم های مهاجرت به IPv6: راهکار NAT64”

تغییر رفتار پیش‌فرض eBGP با RFC8212

پیرو Route Leakage‌های مختلفی که در دنیای اینترنت رخ داده‌است، و همینطور نیاز مبرم Service Providerها، از اواسط سال ۲۰۱۵، در IETF گروه GROW بحثی شروع شد مبنی بر طراحی یک رفتار پیش‌فرض BGP در رابطه با تبادل روت‌ها با همسایگان خارجی (eBGP).
همانطور که می‌دانید در RFCهای مرتبط با BGP، علی‌الخصوص RFC4271، تابحال توضیحی در رابطه با رفتار پیش‌فرض همسایه‌های eBGP در تبادل روت‌ها زمانی که Policy خاصی اعمال نشده، ارائه نشده است، و این امر باعث شده که هر وِندوری رفتار سلیقه‌ای داشته باشد.

فارغ از جزئیات، بعنوان نمونه می‌توان به مدل‌های پیاده‌سازی زیر اشاره کرد:

  • بطور پیش‌فرض دو همسایه eBGP، زمانی که Policy خاصی روی ارتباطات eBGP تنظیم نشده باشد، روت‌های انتخاب‌شده در BGP Table خود را به یکدیگر ارسال می‌کنند و از یکدیگر قبول می‌کنند.
  • هیچ روتی ارسال نمی‌شود و هیچ روتی قبول نمی‌شود (discard) مگر اینکه Policy متناسبی تنظیم شده باشد.
  • برخی پیاده‌سازی‌ها هیچ روتی قبول نمی‌کنند و فقط روت‌های مربوط به AS خود را advertise می‌کنند.

مثلاً در حالت مثال اول، یکی از مخاطرات ممکن زمانی است که یک AS ناخواسته ترانزیت ارتباط بین ASهای دیگر می‌شود (در RFC7908 توضیح خوبی درباره‌ی Lateral ISP-ISP-ISP Leak همراه با دو بررسی دقیق در قسمت منابع، ارائه شده) ادامه خواندن “تغییر رفتار پیش‌فرض eBGP با RFC8212”

MPLS و MPLS-TE مقدمه‌ای برای Segment Routing

از زمانی که احساس شد مسیریابی صرفا بر اساس مقصد همیشه خوب و دلخواه نیست، ایده ی تعیین شرایط مسیریابی در مبدا متولد گشت و برای تحقق این ایده، مدام راهکارهای مختلفی مطرح شد: از PBR تا رفتن به سمت MPLS و سپس پیشرفت آن به MPLS-TE و نهایتا معرفی روشی با نام Segment Routing.

به این ترتیب تعیین شرایط مسیریابی در مبدا یا به عبارت بهتر، انجام Source Routing که روزی تنها در حد یک ایده بود، روز به روز به یک واقعیت و منطق جدید در مسیریابی نزدیکتر شد. آنچه سبب شده تا ایده ی Source Routing بیشتر به واقعیت نزدیک شود، راهکار Segment Routing می باشد. برای درک بهتر عملکرد Segment Routing ابتدا بهتر است مروری بر عملکرد MPLS و MPLS-TE داشته باشیم.

MPLS و ارسال پکت ها

تکنولوژی MPLS، تکنولوژی با قدمتی تقریبا ۲۰ ساله و آشنا برای مهندسین اینترنت می باشد. مبنا و اساس کار MPLS بر پایه ی دو مفهوم Control Plane و Forwarding Plane بوده و به صورت خلاصه نحوه ی عملکرد آن به این صورت است که:

به مجموعه ای از روترها که توانایی پردازش و تشخیص Label ها را داشته باشند اصطلاحا Label Switch Router یا به اختصار LSR گفته می شود. در دامنه ی MPLS که شامل مجموعه ای از LSR هاست، به هر کدام از LSR ها نقشی داده می شود. اولین LSR ای که در لبه ی دامنه ی MPLS قرار دارد و پکتی را از خارج این ساختار به داخل دامنه ی MPLS فوروارد می کند اصطلاحا Ingress LSR نامیده می شود و به روتری که در لبه ی انتهایی دامنه ی MPLS قرار دارد و پکتی را از داخل دامنه ی MPLS به خارج این ساختار ارسال می کند، اصطلاحا Egress LSR گفته می شود.

به مسیری که یک پکت از یک Ingress LSR تا یک Egress LSR طی می کند اصطلاحا LSP یا Label Switched Path گفته می شود که این مسیر یا بر اساس کوتاهترین مسیر محاسبه شده توسط IGP ها مشخص می گردد و یا بر اساس پارامترهای Traffic Engineering یا به اختصار TE. ادامه خواندن “MPLS و MPLS-TE مقدمه‌ای برای Segment Routing”

زوایای پنهان عملکرد 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‏ ‏اختصاص یافته به ساختار ترجمه می گشت. ‏ ادامه خواندن “زوایای پنهان عملکرد IPv6؛ مزایا و تصورات اشتباه”