اخباری که بر پایان عمر IPv4 اشاره می کنن روز به روز در حال افزایش هستن. خبری که این روزها باعث ترس خیلی ها شده یک خبر جدید نیست بلکه از سال ها قبل هشدار این رویداد داده شده بود و روش هایی برای مدیریت این شرایط معرفی شده بود.
به هر حال چه در اوج هوشیاری از این رویداد و چه بی خبر از اون، تمام سازمان ها باید به فکر دوره ی گذار از IPv4 به IPv6 باشن. این گذار احتمالا سخت و دشوار خواهد بود چرا که هنوز خیلی از کاربران و دستگاه هایی که به اینترنت متصل میشن از IPv4 استفاده می کنن، ارتباط بسیاری از ISP ها با مشتریانشون و حتی با سایر ISP ها بر بستر IPv4 هست، دسترسی به خیلی از محتواها در دنیای اینترنت بر پایه ی IPv4 هست و …
در چنین شرایطی در صورت عدم در نظر گرفتن نیاز مشتریان، هر نوع تغییری ممکنه منجر به اختلال در سرویس ها، کاهش کیفیت خدماتی که به مشتریان ارایه میشه و نهایتا عدم رضایت مشتریان و از دست دادن اون ها بشه. پس باید به دنبال راهکارهایی بود که در کنار پشتیبانی از IPv4، به سمت IPv6 هم حرکت کرد.
روش های مختلفی برای پیاده سازی ساختارهایی که همزمان قادر به پشتیبانی از هر دوی ورژن های IP باشن وجود دارن. اصطلاحا به این عمل همزیستی IPv4/IPv6 گفته میشه. این روش ها عموما در 4 دسته قرار میگیرن که عبارتند از:
1- Dual Stack
2- Manual Tunnels
3- Automatic Tunnels
4- Translators
یکی از روش های پر کابرد و رایج، استفاده از روش Dual stack هست که در عین کارایی و در ظاهر سادگی، معایب و سختی هایی را هم در پی دارد.
iهمانطور که بیان شد 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 به داخل Service Provider ها منتقل بشه؟
وضیح داده شد که چندین سال از NAT به عنوان راهکاری در ساختارهای شبکه ی مشتریان برای کاهش نیاز به آدرس های IPv4 Public استفاده می شد.
زمانی که آدرس های IPv4 Public به مرز اتمام نزدیک شدن، ISP ها به دنبال جواب این سوال بودن که چطور می تونن ارتباط خودشون با مشتریانشون رو حفظ بکنن. پاسخ این پرسش این بود که اگر NAT در لبه ی مرزی ساختار مشتریان با پروایدرها تونسته بود موفق عمل بکنه پس قطعا میتونه در لبه ی مرزی ساختار پروایدرها با مشتریانشون هم موفق عمل کنه. در واقع این پاسخ، ایده ی اصلی شکل گیری مفهومی با نام Large Scale NAT یا LSN بود.
معماری LSN به این صورته که، ISP ها برای لینک هایی که به سمت مشتریان خودشون دارن به جای تخصیص آدرس IPv4 Public از آدرس های IPv4 Private استفاده می کنن و برای لینک هایی که برای ارتباطشون با اینترنت هست از آدرس IPv4 Public.
بنابراین اگر مشتری در روتر مرزی خودش با سرویس پروایدر، از NAT استفاده کرده باشه، پکتی که از سمت ساختار مشتری به سمت ISP ارسال میشه ابتدا آدرس IPv4 Private اش به یک آدرس IPv4 Private دیگه که از سمت ISP به لینک بین اون و روتر مرزی مشتری اختصاص پیدا کرده نگاشت میشه و در هنگام خروج پکت از ساختار پروایدر به سمت اینترنت، آدرس اون به یک آدرس IPv4 Public ترجمه میشه. پس بنابراین میشه گفت دوبار ترجمه رخ میده: یک آدرس IPv4 Private به یک آدرس IPv4 Private دیگه و نهایتا به یک آدرس IPv4 Public ترجمه میشه. به همین دلیل به این عمل NAT444 گفته میشه.
خوبی این روش این هست که NAT ای که سمت مشتریان پیاده سازی شده هیچ نیازی به تغییر نداره چون که برای NAT اصلا مهم نیست که آدرس outside ای که نگاشت به اون باید انجام بشه، باید Private باشه یا Public. بنابراین از دید تجهیز سمت مشتری، هیچ تغییری رخ نداده.
اما این معماری قطعا مشکلاتی رو هم در پی خواهد داشت: مثلا تصور کنین که مشتری در ساختار خودش از همون رنج آدرس IPv4 Private ای استفاده کرده باشه که پروایدر اون رنج رو به لینک بین خودش و مشتری اختصاص داده باشه، در این صورت overlap رخ خواهد داد. یا مثلا تصور کنین که یک مشتری بخواد پکتی رو به یک مشتری دیگه که در پشت همون LSN ای که باهاش ارتباط داره، ارسال بکنه. خوب معمولا فایروال ها یا ACL هایی که در روترها تعریف میشن، مانع از ورود پکتی با آدرس IP Private به داخل ساختار میشن و این پکت ها رو drop میکنن.
در پست قبل معماری Large Scale NAT یا LSN، به همراه مشکلاتی که سر راه این معماری وجود داشت و همینطور راه حل هایی که برای حل این مشکلات قابل استفاده بودن، توضیح داده شد. به طور خلاصه اگر بخوایم مروری داشته باشیم، قضیه به این صورت بود که:
ساده ترین روش پیاده سازی LSN، بهره گیری از NAT444 بود که یکی از مشکلات سر راه این روش، احتمال ایجاد overlap بین آدرس های IP Private مشتریان و رنج آدرس IP های Private ای بود که ISP به لینک بین دستگاه خودش و مشتری اختصاص داده بود. مشکل بزرگ بعدی زمانی پیش میومد که دو مشتری که هر دو با یک LSN ارتباط داشتن، قصد برقراری ارتباط با هم رو داشته باشن. در این صورت چون آدرس Private به آدرس Public ای نگاشت نمی شد،احتمال drop شدن پکت ها از سوی دستگاه هایی که در لبه ی ساختار شبکه ی مشتری قرار داشتند، افزایش پیدا می کرد.
یکی از راه حل های پیشنهادی برای حل این مشکل این بود که از یک بلوک از آدرس های IPv4 باقی مونده که با آدرس های RFC 1918 (یا همون آدرس های IPv4 Private) هم پوشانی نداشته باشند، به عنوان shared address استفاده بشن و از این طریق هم مشکل هم پوشانی آدرس ها حل بشه و هم از مشکل فیلتر شدن پکت های مشتریانی که در پشت یک LSN یکسان قرار دارند، جلوگیری بشه. اما این پیشنهاد تقریباً هیچ وقت عملیاتی نشد.
راه حل بعدی، استفاده از آدرس های IPv6 بین ISP و مشتریان، به جای آدرس IPv4 بود. در واقع استفاده از NAT464. این روش علاوه بر این که مشکلات NAT444 رو حل می کرد، به Provider ها هم این امکان رو میداد که سریعتر به سمت معماری IPv6-only که مد نظر داشتند، حرکت کنند. سختی این روش این هست که هم CPE NAT ( یا همون NAT سنتی مورد استفاده سمت ساختار مشتری) و هم معماری LSN، باید قابلیت ترجمه ی هردوی آدرس های IPv4 و IPv6 به همدیگه رو داشته باشند که همین موضوع باعث ایجاد پیچیدگی و بروز مشکلات جدیدی در عملکرد، مقیاس پذیری و افزونگی می شه.
روشی که برای حل این مشکلات پیشنهاد شد،
Dual-Stack Lite
نام داشت. در این روش به لینک بین مشتری و ISP، فقط آدرس IPv6 اختصاص داده میشه. پکت IPv4 ای که از جانب ساختار مشتری بخواد به مقصدی خارج از این ساختار، ارسال بشه، در یک پکت IPv6 کپسوله میشه و به سمت پروایدر ارسال میشه. روتری که در لبه ی ساختار پروایدر قرار داره، این پکت IPv6 رو باز می کنه و در قبال محتویات اون ( که در واقع یک پکت IPv4 هست) از NAT44 استفاده می کنه.
پس به این ترتیب با پیاده سازی یک تانل IPv4 بر روی لینک IPv6
بین ساختار مشتری و ISP، این هدف محقق میشه و علاوه بر این که پیاده سازی این تانل خیلی ساده تر از ترجمه ی آدرس هاست، نگرانی های مربوط به مباحث redundancy و performance هم برطرف میشن.