مفهوم Carrier Grade NAT (CGN)

اگر از پست قبل به خاطر داشته باشید، Dual Stack ساده ترین روش برای حرکت به سمت استفاده از IPv6 بود. در این روش، در صورتی که در یک ساختار IPv6، تمام دستگاه ها قابلیت پشتیبانی از هر دوی ورژن های IPv4/IPv6 را داشته باشند قادر خواهند بود تا با هر مقصدی؛ چه IPv4 و چه IPv6؛ ارتباط برقرار نمایند. این روش زمانی که اکثر کاربران هنوز در حال استفاده از IPv4 باشند، روش مناسبی است.

اما مشکل این روش آن بود که به ازای هر اینترفیسی، همزمان یک آدرس IPv4 و یک آدرس IPv6 نیاز بود و این امر در حالی است که آدرس های IPv4 به پایان رسیده اند و قرار بر پیاده سازی  روشی برای توسعه ی IPv6  و نه افزایش نیاز به IPv4 ای است که دیگر وجود ندارد!

در گذشته برای کاهش نیاز به آدرس های IPv4 Public عموما از دو روش استفاده می شد:

  • یکی از راه ها استفاده از DHCP بود که شاید در آن زمان که تعداد دستگاه هایی که باید به صوت همزمان آنلاین می بودند، کم بود، روش موفقی محسوب می شد اما در حال حاضر که تعداد بیشماری دستگاه وجود دارد که همه همزمان آنلاین هستند، روش خوبی تلقی نمی شود.
  • راه حل بعدی استفاده از NAT44 بود که در واقع نگاشتی را بین آدرس های IPv4 Private، به یک آدرس IPv4 Public انجام می داد و به این ترتیب برای سازمان ها این امکان فراهم می شد که برای ارتباطات دستگاه های داخلی خود از آدرس های IPv4 Private استفاده کنند و اگر نیازی به ارتباط با اینترنت بود، از NAT استفاده می شد و نیاز به آدرس IPv4 Public کاهش پیدا می کرد.

اما این روش هم مشکلی مشابه روش استفاده از DHCP داشت. تعداد آدرس های IPv4 Public محدود بودند و اگر همزمان تعداد زیادی دستگاه نیاز به اتصال به اینترنت داشتند، این روش جوابگو نبود. بنابراین عملکرد NAT44 به گونه ای تغییر داده شد که از شماره پورت ها در هنگام نگاشت آدرس ها استفاده شود. همانطور که می دانید مشهورترین اصطلاح برای این روش Port Address Translation  یا PAT بود که اکنون دیگر PAT یک روش جداگانه محسوب نمی شود و تبدیل به عملکرد نرمال NAT44 گشته است.

اول این مبحث مطرح شد که روش Dual Stack در واقع مشکل IPv4 را حل نمی کرد چراکه نیاز به آدرس های IPv4 Public به تعداد زیاد، داخل Service Provider ها هم چنان وجود داشت و سپس همانطور که مطرح شد عملی که NAT انجام می داد آن بود که به شما این امکان را می داد که در داخل ساختار از آدرس های IPv4 Private استفاده کنید و بعد با داشتن چند آدرس محدود Public و استفاده از NAT، بین این آدرس ها نگاشت انجام دهید. پس آیا امکان پذیر نیست که ایده ی استفاده از NAT به داخل سرویس پروایدرها منتقل شود؟

در این مقاله به مسایلی که به آن ها اشاره شد پرداخته می شود و نهایتا به معرفی راهکار Carrier Grade NAT یا CGN ختم می گردد.

Understanding Carrier Grade NAT

معمای Dual Stack

اخباری که بر پایان عمر IPv4 اشاره می کنند روز به روز در حال افزایش هستند. خبری که این روزها باعث ترس عده ی زیادی شده، یک خبر جدید نیست بلکه از سال ها قبل هشدار این رویداد داده شده بود و روش هایی برای مدیریت این شرایط معرفی گردیده بود.

در هر حال، چه در اوج هوشیاری از این رویداد و چه بی خبر از آن، تمام سازمان ها باید به فکر دوره ی گذار از IPv4 به IPv6 باشند. این گذار احتمالا سخت و دشوار خواهد بود چرا که هنوز تعداد زیادی از کاربران  و دستگاه هایی که به اینترنت متصل می شوند از IPv4 استفاده می نمایند، ارتباط بسیاری از ISP ها با مشتریانشان و حتی با سایر ISP ها بر بستر IPv4 است، دسترسی به بسیاری از محتواها در دنیای اینترنت بر پایه ی IPv4 می باشد و … ادامه خواندن “معمای Dual Stack”

روز اول سال جدید و تعداد IPv6

روز اول سال جدید رو با دونستن تعداد IPv6 شروع کنیم

میدونین در بدن انسان در حالت معمول چند اتم وجود داره؟ حتماً می‌پرسین خب چه ربطی داره به شبکه؛ حق دارین.

در بدن انسان 27^10 * 7 (7,000,000,000,000,000,000,000,000,000) اتم وجود داره.

اگر به هر اتم موجود در بدن تمام انسان ها!! یک آدرس IPv6 داده بشه، بازهم معادل 3e+38 آدرس باقی می مونه

مهاجرت به IPv6: دیتاسنترهای فیسبوک

در بحث مهاجرت به IPv6 ، شاید بشه گفت دیتاسنترها اولین نقطه‌ای هستن که باید براشون برنامه‌ریزی کرد تا سرویس‌ها IPv6-enabled و در دسترس باشن. شرکتهای بزرگ راهکارهای حرکت به سمت IPv6 خاص خودشون رو دارن. در این میون شرکتی مثل فیسبوک از ایده های جالبی برای پیاده سازی IPv6 در دیتاسنترهای خودش استفاده کرده.

99 درصد ترافیک درون شبکه ای فیسبوک و نیمی از کلاسترهای اون ها IPv6 only هستن و این در حالی هست که تنها 15 درصد کابران فیسبوک از IPv6 استفاده می کنند و 85 درصد ترافیکی که به سمت سرورهای فیسبوک روونه میشه، IPv4 only هستن!

فیسبوک در استفاده از راهکارها و دیوایس های خاص خودش همیشه مشهور بوده، برای همین شاید براتون جالب باشه که بدونید چطور فیسبوک بدون هیچ تداخلی تونسته ترافیک IPv4 ای که بخش اعظمی از ترافیک ورودی به دیتاسنترهاش رو شامل میشه از بستری مبتنی بر IPv6 عبور بده. پیشنهاد می کنم این پست کوتاه که با زبانی بسیار ساده به توضیح این راهکارها پرداخته مطالعه کنید 🙂

https://code.facebook.com/posts/635645183305089/legacy-support-on-ipv6-only-infra

خواندنی: مهاجرت به IPv6 – راه‌کارهای تنظیم سرور

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

IPv6 configuration approaches for servers