داستان آدرس‌دهی IP؛ از جزیره‌های جدا افتاده تا دهکده جهانی

یکی از اولین چیزهایی که در دنیای شبکه با آن برخورد می‌کنیم، غولِ بی شاخ و دمی به نام «آدرس IP» و محاسبات آن است! با اینکه تسلط بر IP از نان شب برای یک کارشناس شبکه واجب‌تر است، اما معمولاً برای شبکه‌آموزان به کابوس تبدیل می‌شود. چرا؟ چون از همان ابتدا آن‌ها را در استخری از محاسبات صفر و یک (باینری) غرق می‌کند!

در این مقاله قرار است مسیر متفاوتی را برویم. می‌خواهیم سوار ماشین زمان شویم و داستان آدرس‌دهی IP را از دل تاریخ ورق بزنیم. وقتی بفهمید هر مفهوم چرا و به چه علتی به وجود آمده است، محاسبات آن هم مثل آب خوردن برایتان ساده می‌شود؛ به طوری که بعد از خواندن این راهنما، دیگر نیازی به هیچ آموزش دیگری نخواهید داشت. پس کمربندها را ببندید!

پیشنیازها

تلاشم بر این بوده تا حد ممکن پیچیدگی‌ها را کنار بگذارم تا بدون هیچ پیش‌زمینه خاصی بتوانید همسفر ما شوید. اما اگر با دو مفهوم زیر از قبل آشنایی داشته باشید، لذت بیشتری از این مسیر خواهید برد (که احتمالاً چون سراغ این مقاله آمده‌اید، آن‌ها را می‌شناسید):

• مدل مرجع OSI: (به خصوص لایه ۳ یا همان لایه شبکه)
• تبدیل مبنا: (به ویژه تبدیل ساده بین باینری و دهدهی)

اصلا این IP چیست؟

قبل از اینکه وارد اصل داستان شویم، یک سوتفاهم قدیمی را حل کنیم.

عبارت IP مخفف Internet Protocol است. خودِ پروتکل، در واقع یک «کتابچه قانون» است؛ مجموعه‌ای از قوانین که مشخص می‌کند بسته‌های داده چطور آدرس‌دهی و در میان شبکه‌ها مسیریابی شوند تا سالم به مقصد برسند.

بنابراین، پروتکل IP با آدرس IP یکی نیست! آدرس IP در واقع شناسه‌ای است که بر اساس قوانینِ این پروتکل به دستگاه‌ها داده می‌شود. اما خب، در گفت‌وگوهای روزمره و حتی بین متخصصین، به آدرس IP به اختصار همان «IP» می‌گویند که ما هم در این مقاله با آن همراه می‌شویم.

دنیای قبل ازIP؛ جزیره‌های جدا افتاده

برای اینکه ارزش کار سازندگان IP را درک کنیم، باید بدانیم قبل از آن دنیا چه شکلی بود.

در دهه‌های ۱۹۷۰ و ۱۹۸۰ میلادی، چیزی به نام «اینترنت یکپارچه» وجود نداشت. در عوض، شبکه‌های آزمایشی کوچکی به نام شبکه‌های سوئیچینگ بسته (مثل ARPANET در آمریکا یا CYCLADES در فرانسه) وجود داشتند. این شبکه‌ها مثل جزیره‌هایی جدا از هم بودند که هرکدام با زبان، سخت‌افزار و تکنولوژی اختصاصی خودشان کار می‌کردند. کامپیوترهای یک شبکه، اصلاً نمی‌توانستند با کامپیوترهای شبکه دیگر صحبت کنند؛ درست مثل جزیره‌های دور افتاده که هیچ راهی برای سفر بین آن‌ها نیست.

در این میان، ایده‌ای به نام Catenet (شبکه‌ای از شبکه‌ها) متولد شد. ایده این بود: «بیایید زنجیره‌ای بسازیم تا شبکه‌های مختلف را به هم وصل کند و بسته‌های داده (Datagram) بتوانند بدون توجه به اینکه سخت‌افزار شبکه چیست، از مبدأ در یک شبکه به مقصد در شبکه‌ای دیگر سفر کنند.»

اما برای تحقق این ایده، به یک میانجی یا «زبان مشترک جهانی» نیاز بود. در تلاش‌های اولیه، دانشمندان سعی کردند تمام وظایف شبکه (از آدرس‌دهی گرفته تا تضمین رسیدن داده‌ها و کنترل سرعت ارسال) را در یک پروتکل غول‌آسا بگنجانند. اما این کار سیستم را بیش از حد پیچیده و سنگین کرد.

نتیجه؟ تصمیم گرفتند کارها را تقسیم کنند. پروتکل IP به عنوان یک «کارمند ساده و چابک» طراحی شد که وظیفه‌اش حداقلی اما حیاتی بود: فقط آدرس‌دهی کند، بسته‌ها را به سمت مقصد بفرستد و اگر بسته بزرگ بود آن را ریز کند (Fragmentation).

کارمند چابک ما (IP) کاری به این نداشت که آیا بسته حتماً سالم به مقصد رسیده یا نه؛ او فقط پستچی بود! وظایف سنگین‌تر مانند تضمین سلامت ارسال و کنترل جریان داده، به لایه‌های بالاتر و پروتکل دیگری به نام TCP واگذار شد.

ظهور IP؛ تقسیم ساده‌ی جهان به ۲۵۶ شبکه بزرگ

اکنون در ژانویه سال ۱۹۸۰ میلادی هستیم؛ سالی که برای حل آشفتگی‌های گذشته، بالاخره پروتکل رسمی IP در نسخه اولیه خود طراحی و به جهان معرفی شد.

در آن روزهای نخستین، آدرس IP درست مانند امروز یک آدرس ۳۲ بیتی بود، اما یک تفاوت بزرگ با تصویر ذهنی ما داشت: هنوز خبری از سیستم کلاس‌بندیِ معروف (A، B و C) نبود.

طراحان اولیه اینترنت فکرش را هم نمی‌کردند که روزی قرار است میلیاردها دستگاه به این شبکه وصل شوند. بنابراین، آدرس ۳۲ بیتی را به ساده‌ترین شکل ممکن به دو بخش تقسیم کردند:

• ۸ بیت اول: برای شناسه شبکه (Network Number)
• ۲۴ بیت باقی‌مانده: برای آدرس‌های محلی یا همان هاست‌ها (Rest Field)

شاید امروز خنده‌دار به نظر برسد، اما با این فرمان، کل اینترنت جهان در آن زمان تنها می‌توانست ۲۵۶ شبکه مستقل داشته باشد! چرا؟ چون با ۸ بیت فقط می‌توان 28 یعنی ۲۵۶ حالت مختلف ایجاد کرد. در مقابل، هرکدام از این شبکه‌ها می‌توانستند صاحب بیش از ۱۶ میلیون میزبان (Host) باشند؛ یعنی تعداد شبکه‌های کم با ظرفیت سرسام‌آور. از این ۲۵۶ شبکه، شماره‌های 0 و 255 از همان ابتدا برای مصارف خاص رزرو شدند. شماره‌های 34 تا 254 هنوز به جایی تخصیص داده نشده بودند و دست‌نخورده باقی ماندند.و تنها شماره‌های 1 تا 33 مصرف شده بودند. برای مثال، شماره شبکه ۱۰ به شبکه معروف ARPANET اختصاص داده شده بود.

کالبدشکافی یک آدرس قدیمی

برای اینکه حس بهتری از این ساختار پیدا کنید، بیایید یک آدرس فرضی مثل 10.20.30.40 را در آن دوران کالبدشکافی کنیم:

در این مدل قدیمی، عدد ۱۰ (بخش ۸ بیتی اول) نشان‌دهنده شماره شبکه بود و بخش ۲۰.۳۰.۴۰ (۲۴ بیت بعدی) آدرس دستگاه یا همان هاست متصل به آن شبکه را نشان می‌داد. برای درک بهتر نحوه چیدمان بیت‌ها و ساختار ۳۲ بیتی آدرس IP، به تصویر زیر نگاه کنید:

تحول به سیستم کلاس‌بندی؛ وقتی جامعه‌ی اینترنت طبقاتی شد!

تنها یک سال بعد، در سپتامبر ۱۹۸۱، طراحان اینترنت متوجه شدند که این تقسیم‌بندی بیتی برای رشد اینترنت و تنوع اندازه‌ی شبکه‌ها انعطاف کافی ندارد و پاسخگوی رشد سریع شبکه اینترنت نیست. برخی سازمان‌ها یک شبکه کوچک با چند ده کامپیوتر می‌خواستند و برخی دیگر، شبکه‌ای غول‌آسا. در این سال تعداد شبکه‌های فعال کل دنیا به 44 عدد رسیده بود.

برای حل این مشکل، مهندسان آستین‌ها را بالا زدند و سیستم معروف کلاس‌بندی آدرس‌ها (Classful Addressing) را معرفی کردند. ایده ساده بود: جهان را به سه طبقه یا کلاس اصلی (A، B و C) تقسیم کنیم تا هر کس به اندازه نیازش آدرس بگیرد. در استانداردی که در این سال وضع شده بود اسمی از کلاس D و E به میان نیامده و فقط عبارت «escape to extended addressing mode» برایشان ذکر شده‌بود تا راه برای آینده باز بماند.

بیایید این سه کلاس را بررسی کنیم:

• کلاس A (شبکه‌های بسیار بزرگ):

این کلاس برای شبکه‌های دولتی یا شرکت‌های عظیم طراحی شده بود؛ تعداد کمی شبکه، اما با تعداد بسیار زیادی دستگاه.

• مشخصه: اولین بیت آدرس در مبنای دو (باینری) همیشه با ۰ شروع می‌شود.
• ساختار: ۸ بیت اول برای شناسه شبکه (Network Number) و ۲۴ بیت باقی‌مانده برای دستگاه‌ها (Host).
• محدوده آدرس‌ها: از 0.0.0.0 تا 127.255.255.255.
• جزئیات بیشتر: در آن دوران، محدوده‌های0.0.0.0/8  و 127.0.0.0/8 برای کاربردهای خاص رزرو شده بودند و محدوده 45.0.0.0  تا126.255.255.255  هنوز به کسی داده نشده بود و دست‌نخورده باقی مانده بود.
• مثال: آدرس 10.0.0.1 یک آدرس کلاس A است. اینجا 10.0.0.0 شماره شبکه و 0.0.0.1 آدرس میزبان است.
• کلاس B (شبکه‌های متوسط):

این کلاس تعادلی بین تعداد شبکه‌ها و تعداد دستگاه‌ها ایجاد می‌کرد.

• • مشخصه: دو بیت اول آدرس در مبنای دو همیشه 10 است.
  • ساختار: ۱۶ بیت اول برای شناسه شبکه و ۱۶ بیت باقی‌مانده برای میزبان است.
  • محدوده آدرس‌ها: از 128.0.0.0 تا 191.255.255.255 .
  • جزئیات بیشتر: 128.0.0.0 تا 128.0.255.255 و 191.255.0.0 تا 191.255.255.255 رزرو شده بود و 128.1.0.0 تا 191.254.255.255 قابل استفاده بود اما تخصیص داده نشده‌بود.
  • مثال: آدرس 128.32.1.5 یک آدرس کلاس B است که در آن 128.32.0.0 شماره شبکه و 0.0.1.5آدرس میزبان است.
• کلاس C (شبکه‌های کوچک):

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

• مشخصه: سه بیت اول آدرس در مبنای دو همیشه 110 است.
• ساختار: ۲۴ بیت اول برای شناسه شبکه و ۸ بیت باقی‌مانده برای میزبان است.
• محدوده آدرس‌ها: از 192.0.0.0 تا 223.255.255.255 .
• جزئیات بیشتر: 192.0.0.0 تا 192.0.0.255 و 223.255.255.0 تا 223.255.255.255 رزرو شده و 192.0.1.0 تا 223.255.254.255 قابل استفاده و تخصیص داده نشده بود.
• مثال: آدرس 192.168.1.100 یک آدرس کلاس C است که در آن 192.168.1.0 شماره شبکه و 0.0.0.100 آدرس میزبان است.
• آدرس‌های رزرو شده:

هر آدرسی که با بیت‌های 111 شروع می‌شد، در دسته آدرس‌های رزرو شده قرار می‌گرفت که محدوده‌ای از 224.0.0.0 تا255.255.255.255  را شامل می‌شد. (کلاس‌های D برای مالتی‌کست و E برای مصارف آزمایشی، چند سال بعد یعنی در سال ۱۹۸۶ رسماً از دل این محدوده متولد شدند).

توجه داشته باشید که حتی با معرفی کلاس‌ها در سال ۱۹۸۱، هنوز چیزی به نام Subnetting و ماسک‌های زیرشبکه (Subnet Mask) وجود نداشت. روترها در آن زمان فقط به بیت‌های اول آدرس نگاه می‌کردند تا بفهمند بسته متعلق به کدام کلاس است و مرز شبکه کجاست. مفاهیم ماسک و زیرشبکه سال‌ها بعد برای نجات شبکه‌های داخلی سازمان‌ها ابداع شدند که در بخش بعدی به سراغشان می‌رویم.

Subnetting؛ وقتی یک شبکه بزرگ، زیادی بزرگ بود

حدود چهار سال پس از تثبیت آدرس‌دهی کلاس‌دار در 1981، مشخص شد یک شماره شبکه کلاسیک، مانند یک شبکه  Class B، برای سازمان‌های بزرگ ساختار داخلی کافی ایجاد نمی‌کند.

فرض کنید یک دانشگاه یک شبکه Class B دریافت کرده است. این دانشگاه شاید ده‌ها ساختمان، چندین دانشکده، کتابخانه، واحد اداری و آزمایشگاه داشته باشد. اگر همه دستگاه‌ها در یک شبکه بزرگ قرار بگیرند، مدیریت شبکه سخت می‌شود و ترافیک‌هایی مثل Broadcast و درخواست‌های ARP می‌توانند در کل سازمان پخش شوند.

برای حل این مسئله، در سال ۱۹۸۵، مکانیزم Subnetting معرفی شد. به همین دلیل سطح سوم سلسله‌مراتب یعنی؛ آدرس‌دهی از حالت دو سطحی (شبکه-میزبان) به سه سطحی (شبکه-زیرشبکه-میزبان) تغییر یافت. به این ترتیب، یک سازمان می‌توانست شبکه‌ای را که از بیرون به آن اختصاص داده شده بود، در داخل مجموعه به چند شبکه کوچک‌تر تقسیم کند؛ بدون اینکه برای هر ساختمان یا هر LAN مجبور باشد یک شماره شبکه جدید از مراجع تخصیص آدرس بگیرد.

ماسک آدرس (Address Mask)؛ نقشه‌ای برای پیدا کردن مرزها

هم‌زمان، مفهومی بنام Address Mask معرفی شد که امروزه آن را با نام Subnet Mask  می‌شناسیم. از آنجا که مرز زیرشبکه دیگر از روی بیت‌های ابتدایی آدرس قابل تشخیص نبود، ماسک به عنوان یک عدد ۳۲ بیتی مجزا تعریف شد تا مشخص کند کدام بیت‌ها مربوط به بخش شبکه و زیرشبکه هستند و کدام بیت‌ها برای میزبان‌ها باقی مانده‌اند.

برای مثال، در ماسک زیر:

255.255.255.0

24 بیت اول مربوط به شبکه و زیرشبکه‌اند و تنها 8 بیت آخر برای میزبان باقیست.

اما Subnet Mask دقیقاً چه کاری انجام می‌دهد؟

Subnet Mask به روتر یا سیستم‌عامل می‌گوید کدام بخش از آدرس IP مربوط به شبکه و زیرشبکه است و کدام بخش مربوط به میزبان. قاعده‌اش ساده است:

• هر بیتی که در ماسک ۱ باشد، جزو بخش شبکه و زیرشبکه محسوب می‌شود.
• هر بیتی که در ماسک ۰ باشد، جزو بخش میزبان است.

مثلاً اگر این آدرس IP را داشته باشیم:

128.10.3.25

و Subnet Mask آن این باشد:

255.255.255.0

نمایش دودویی این Subnet Mask بصورت زیر است:

11111111. 11111111. 11111111.00000000

یعنی 24 بیت اول متعلق به بخش شبکه و زیرشبکه‌اند و فقط 8 بیت آخر برای Host باقی‌مانده است.

دستگاه‌های موجود در شبکه، آدرس IP را با Subnet Mask بصورت بیتی AND می‌کند؛ خروجی این عملیات، آدرس شبکه را مشخص می‌کند. اگر در همین مثال آدرس IP و Subnet Mask آن AND شود خروجی 128.10.3.0 خواهد بود.

یک دانشگاه و یک شبکه Class B بزرگ

فرض کنید یک دانشگاه بزرگ در دهه ۱۹۸۰ یک شبکه Class B دریافت کرده است:

128.10.0.0

در آدرس‌دهی کلاس‌دار، این شبکه به‌صورت پیش‌فرض چنین ساختاری دارد:

یعنی دانشگاه در ظاهر یک شبکه بزرگ با فضای آدرس‌دهی زیر دارد:

128.10.0.0 

 128.10.255.255

این یعنی بیش از ۶۵ هزار آدرس در یک شبکه واحد؛ برای یک دانشگاه بزرگ، از نظر تعداد شاید مفید به نظر برسد، اما از نظر مدیریت و کنترل Broadcast اصلاً ایده‌آل نیست.

اما دانشگاه چند ساختمان دارد:

• دانشکده مهندسی
• دانشکده علوم
• کتابخانه
• ساختمان اداری

بنابراین دانشگاه تصمیم می‌گیرد شبکه خود را به چند  زیرشبکه تقسیم کند. از ۱۶ بیت بخش Host، تعداد 8 بیت را برای شماره زیرشبکه قرض می‌گیرد. در نتیجه ساختار آدرس و ماسک جدید چنین می‌شود:

این کار به دانشگاه اجازه می‌دهد تا شبکه بزرگ خود را به ۲۵۶ زیرشبکه تقسیم کند. هر زیرشبکه ۲۵۶ آدرس دارد که از میان آن‌ها، ۲۵۴ آدرس به میزبان‌ها قابل تخصیص است. اکنون دانشگاه می‌تواند زیرشبکه‌های زیر را داشته باشد

نکته مهم این است که اینترنت بیرون از دانشگاه لازم نبود تمام این زیرشبکه‌ها را جداگانه بشناسد. از دید اینترنت، دانشگاه همچنان همان شبکه اصلی 128.10.0.0 با ماسک 255.255.0.0 بود. این روترهای داخلی دانشگاه بودند که می‌دانستند مثلاً بسته‌ای برای 128.10.3.25 باید به شبکه کتابخانه برود، نه دانشکده علوم.

این مدل، چون همه زیرشبکه‌ها را با یک ماسک ثابت می‌ساخت، چیزی است که امروز آن را FLSM یا Fixed Length Subnet Masking می‌نامیم.

انقلاب CIDR؛ پایان عصر کلاس‌ها و نجات اینترنت

در اوایل دهه ۱۹۹۰، اینترنت با یک بحران جدی روبه‌رو شد. ساختار کلاس‌های A، B و C که انعطاف کمی داشتند دیگر جوابگوی انفجار جمعیت وب نبود. از یک طرف، آدرس‌های کلاس B (که برای سازمان‌های متوسط بود) با سرعتی سرسام‌آور در حال تمام شدن بودند؛ چون سازمان‌ها یا مجبور بودند کلاس C بخرند که بسیار کوچک بود (فقط ۲۵۴ آدرس) یا به سراغ کلاس B می‌رفتند که بسیار بزرگ بود (۶۵,۵۳۶ آدرس) و بخش زیادی از آن هدر می‌رفت. از طرف دیگر، روترهای ستون فقرات اینترنت (Backbone Routers) زیر بار سنگین مسیرهای مختلف کمر خم کرده بودند و جدول مسیریابی جهان در حال انفجار بود.

 برای حل این مشکل، در سال 1993 رویکردی جدید معرفی شد که بر پایه آدرس‌دهی بدون کلاس (Classless) بود که با نام CIDR  (Classless Inter-Domain Routing) شناخته می‌شود. در این روش، مفهوم کلاس‌های ثابت کنار گذاشته شد و دیگر نیازی نبود ماسک شبکه حتماً روی مرزهای ۸ بیت، ۱۶ بیت یا ۲۴ بیت قفل شود. از این پس، طول بخش شبکه با یک اسلش ساده در انتهای آدرس (مانند /21 یا /25 ) مشخص می‌شد.

معرفی CIDR زمینه را برای Subnetting با ماسک‌های طول متغیر (VLSM- Variable Length Subnet Masking) فراهم کرد؛ یعنی به مدیران شبکه اجازه داد تا یک بلوک آدرس بزرگ را به زیرشبکه‌هایی با اندازه‌های کاملاً متفاوت (متناسب با نیاز واقعی) تقسیم کنند. نه اینکه همه زیرشبکه‌ها اندازه‌ای یکسان داشته باشند.

همچنین، این تحول امکان تجمیع مسیرها یا Supernetting را نیز فراهم کرد؛ به این معنا که چندین شبکه کوچک می‌توانستند در یک آدرس واحد خلاصه و در روترهای اینترنت معرفی شوند و در نتیجه، فشار روی روترهای جهانی کاهش یابد. به طور کلی، آدرس‌دهی اینترنت از یک ساختار ثابت و سخت در دهه ۱۹۷۰، به یک نظام کلاس‌بندی‌شده در سال ۱۹۸۱، سپس به Subnetting در ۱۹۸۵ و در نهایت به مدل منعطف و بدون کلاس CIDR در سال ۱۹۹۳ رسید.

بازگشت به دانشگاه با سلاح CIDR و VLSM

یادتان هست که در روش قدیمی FLSM، دانشگاه در دهه 1980 مجبور شد کل شبکه کلاس B خود یعنی 128.10.0.0/16 را به زیرشبکه‌های هم‌اندازه تقسیم کند (هر زیرشبکه با 254 آدرس قابل استفاده)؟

این کار دو مشکل بزرگ ایجاد می‌کرد:

·         اتلاف آدرس: فرض کنید بخش اداری فقط به ۱۰ هاست نیاز دارد، اما به آن یک Subnet با ۲۵۴ آدرس قابل استفاده تخصیص داده شده! این یعنی ۲۴۴ آدرس تلف می‌شود. اگر چندین بخش کوچک وجود داشته باشند، این اتلاف بسیار شدید خواهد شد.

• شلوغی جدول‌های مسیریابی: روترهای اینترنت باید تمام ۲۵۶ مسیر مجزا (برای هر 128.10.X.0/24) را در جداول خود ثبت کنند که باعث شلوغی شدید جدول مسیریابی می‌شود.

حالا ما قصد داریم با تکنولوژی جدیدتر CIDR و VLSM همان آدرس 128.10.0.0/16 را در همین دانشگاه مدیریت کنیم. ابتدا باید نیازسنجی کنیم که نیاز فعلی هر ساختمان چند آدرس IP است و سپس آینده‌نگری داشته باشیم و برای توسعه شبکه نیز آدرس اضافه در نظر بگیریم. برای مثال فرض کنید نیازسنجی ما بصورت جدول زیر است:

این بار بجای استفاده از FLSM که طول ثابت برای هر زیرشبکه در نظر می‌گرفت از VLSM استفاده می‌کنیم و هر شبکه را متناسب با نیاز آن ایجاد می‌کنیم. برای انجام اینکار نیاز است که دو فرمول را بخاطر بسپارید سپس گام‌به‌گام محاسبات را انجام می‌دهیم:

• 2 به توان n= تعداد کل آدرس‌ها در یک بلوک.
• 2 به توان n  منهای 2= تعداد آدرس‌های قابل استفاده برای Host‌ها.

(در این فرمول n تعداد بیت‌هایی است که به Hostها اختصاص می‌دهیم).

محاسبات قدم‌به‌قدم به روش VLSM

گام اول: مرتب سازی نیازها از بزرگ به کوچک

در محاسبات VLSM همیشه از بزرگترین عدد نیاز شروع می‌کنیم و به سمت کوچکترین نیاز پیش می‌رویم. این کار باعث می‌شود تقسیم‌بندی آدرس‌ها پشت سرهم و بدون تداخل انجام شود. در این مسئله بصورت اتفاقی نیازهای ما مرتب شده هستند. آدرس شروع ما نیز اولین آدرس بلاک یعنی 128.10.0.0 است.

گام دوم: شروع محاسبات برای هر زیر شبکه

براساس مرتب‌سازی نیازها که در گام قبلی صورت گرفته اقدام به محاسبه برای هر ساختمان می‌کنیم. من محاسبه یکی از ساختمان‌ها را بصورت تشریحی انجام می‌دهم و سه ساختمان دیگر را با همین روش حساب می‌کنم و از نوشتن آن پرهیز می‌کنم.

با توجه به فرمول‌هایی که پیشتر ذکر شد باید برای ساختمان مهندسی به دنبال nیی بگردیم که بزرگتر مساوی 102 باشد:

·         اگر ۵ بیت به هاست بدهیم 25=32 آدرس به ما می‌دهد که با کم کردن ۲ آدرس رزرو، 30  آدرس خواهیم داشت که خیلی کم است.

·         اگر ۶ بیت به هاست بدهیم 26=64 آدرس به ما می‌دهد که با کم کردن ۲ آدرس رزرو، 62 آدرس داریم که هنوزم کم است.

·         اگر ۷ بیت به هاست بدهیم 27=128 آدرس به ما می‌دهد که با کم کردن ۲ آدرس رزرو، ۱۲۶ آدرس قابل استفاده داریم که برای ۱۰۰ هاست ما کاملاً کافی و مناسب است.

برای تعیین ماسک، کل بیت‌های آدرس IP که برابر ۳۲ بیت است را منهای n که ۷ بیت است می‌کنیم، یعنی 32-7=25 بیت برای شبکه می‌ماند. پس ماسک ما /25  است. پس آدرس ساختمان مهندسی بصورت زیر خواهد بود:

برای بقیه ساختمان‌ها نیز به ترتیب شرایط زیر را داریم:

مقایسه FLSM در برابر VLSM

بیایید نگاهی به آمار بیندازیم تا ببینیم چقدر در مصرف آدرس‌ها صرفه‌جویی کرده‌ایم:

یعنی از کل 128.10.0.0/16، فقط بازه‌ی 128.10.0.0 تا 128.10.0.239 (که در واقع کمتر از یک /24 است) مصرف شده و تقریباً کل فضا برای توسعه‌های آینده‌ی دانشگاه دست‌نخورده باقی مانده، که در مقایسه‌ با روش قدیمی FLSM که 256×4=1024 آدرس را اشغال کرده بود، 784 آدرس صرفه‌جویی شده.

شاید این محاسبات شما را گیج کرده باشد و این طبیعی است و تا وقتی خودتان دست به قلم و کاغذ نبرید ممکن است یادگیری این مبحث کمی دشوار باشد. با این حال تصویر متحرک (GIF) زیر می‌تواند درک و شهود مناسبی نسبت به این موضوع به شما بدهد.

Supernetting؛ ادغام مسیرها برای نجات روترهای جهان

فرض کنید روتر داخلی دانشگاه می‌خواهد مسیرهای مربوط به چهار ساختمان خود را به روتر اصلی یا اینترنت بیرون اعلام (Advertise) کند. در حالت عادی، روتر باید ۴ مسیر مجزا را اعلام کند. اگر روترهای بیرون بخواهند تک‌تک این مسیرهای کوچک را ثبت کنند، جدول مسیریابی اینترنت به شدت شلوغ می‌شود. از آنجایی که تمام این ۴ زیرشبکه در دل اولین قطعه از اکتت چهارم (یعنی از آدرس.0 تا .239) قرار دارند و با در نظر گرفتن بخش رزرو برای توسعه آینده (.240 تا .255 که یک بلوک /28 دیگر است)، کل این فضا دقیقاً منطبق بر یک بلوک کامل /24 است.

بنابراین، روتر دانشگاه با استفاده از Supernetting، هر ۴ مسیر را در یک مسیر واحد خلاصه (Aggregate) کرده و به بیرون اعلام می‌کند:

128.10.0.0/24 البته که 128.10.0.0/16 هم امکان پذیر است چون /24 زیرمجموعه /16 است ولی برای چهار شبکه فعلی /24 مناسب است.

حالا وقتی بسته‌ای از اینترنت با مقصد مثلاً  128.10.0.130 که مربوط به دانشکده علوم است، می‌آید، روترهای بیرونی اینترنت نیازی ندارند مسیر دقیق/26  را بشناسند؛ آن‌ها فقط با دیدن مسیر خلاصه‌شده128.10.0.0/24  بسته را به سمت روتر دانشگاه هدایت می‌کنند. پس از رسیدن بسته به روتر مرزی دانشگاه، این روتر داخلی است که با نگاه کردن به جدول VLSM دقیق خود، بسته را به دست دپارتمان مربوطه می‌رساند.

این مسیر خلاصه (/24)، کل محدوده128.10.0.0  تا 128.10.0.255 را پوشش می‌دهد. این یعنی فضا یا بلوک باقی‌مانده انتهای آدرس‌ها (128.10.0.240/28) نیز به صورت خودکار درون این خلاصه قرار دارد و در آینده بدون نیاز به تغییر در مسیرهای بیرونی، قابل استفاده خواهد بود. تصویر زیر دید بهتری در مورد چگونگی Supernetting به شما خواهد داد.

تفکیک فضای آدرس‌دهی به عمومی و خصوصی

به دلیل رشد چشمگیر استفاده از شبکه‌های TCP/IP و استفاده سازمان‌ها و شرکت‌ها از پروتکل IP برای ارتباطات درون سازمانی، در سال 1994 پیشنهادی مطرح شد که سه بلوک از آدرس‌های IP بعنوان آدرس‌های خصوصی (Private) در نظر گرفته‌شوند. این آدرس‌ها فقط در شبکه‌های داخلی (Intranet) قابل استفاده هستند و توسط مسیریاب‌های اینترنت، مسیریابی نمی‌شوند. محدوده آدرس‌ها به شرح زیر بودند:

براساس این تقسیم‌بندی Hostهایی که نیازی به اتصال مستقیم به اینترنت ندارند Private Host نامیده می‌شوند (گرچه در ابتدا تصور می‌شد Private Hostها برای همیشه از اینترنت جدا می‌مانند، اما با ظهور فناوری NAT، این امکان فراهم شد که این میزبان‌ها بدون نیاز به تغییر آدرس خصوصی خود، به صورت غیرمستقیم به اینترنت متصل شوند.) و از این آدرس‌ها که Private Address نامیده‌ می‌شوند استفاد می‌کنند و هر سازمانی می‌تواند بدون هماهنگی با IANA از این آدرس‌ها استفاده کند چون دیگر این آدرس‌ها اینترنتی نیستند. همچنین Hostهایی که باید به اینترنت متصل شوند Public Host نامیده شدند و باید از Public Addressها برای اتصال به اینترنت استفاده کنند.

این پیشنهاد پس از اصلاح ایرادات اولیه و انطباق کامل با ساختار مسیریابی بدون‌کلاس (CIDR)، سرانجام در سال ۱۹۹۶ به عنوان یک توصیه و استاندارد رسمی پذیرفته شد و تا به امروز مبنای آدرس‌دهی شبکه‌های داخلی در سراسر جهان است.

معرفی NAT

در سال ۱۹۹۴، همزمان با مطرح شدن CIDR بعنوان راهکاری برای کاهش سرعت اتمام آدرس‌های IPv4 و کنترل رشد جدول‌های مسیریابی، پیشنهاد دیگری نیز ارائه شد که می‌گفت CIDR به‌تنهایی یک درمان کوتاه‌مدت است و تا زمان فراگیر شدن IPv6 به یک راهکار مکمل نیاز داریم. این ایده با عنوان The IP Network Address Translator یا  NAT(Network Address Translation) معرفی شد.

هدف NAT این بود که میزبان‌های دارای آدرس خصوصی (Private Host) بتوانند بدون تغییر آدرس IP داخلی خود و با همان Private Address، به‌صورت غیرمستقیم به اینترنت دسترسی پیدا کنند. ایده‌ی پایه ساده بود: روتر مرزی سازمان (Internet Gateway) هنگام خروج ترافیک از شبکه داخلی، آدرس مبدأ (Source IP) بسته را تغییر می‌دهد و در عوض یک آدرس عمومی(Public Address) را در فیلد مبدأ قرار می‌دهد. برای اینکه مسیر برگشت نیز درست کار کند، روتر نگاشتی از این تغییر را در یک جدول نگه می‌دارد:

در نسخه‌های ابتدایی، این مدل عملاً به این معنی بود که هر میزبان خصوصی برای ارتباط همزمان با اینترنت به یک آدرس عمومی اختصاصی نیاز دارد (ترجمه ۱ به ۱ در حالت همزمان).

تکامل NAT: ظهور NAPT/PAT  بالاترین حد صرفه‌جویی

در سال 2001، نسخه بالغ‌تری از NAT مطرح شد که امکان استفاده چندین میزبان داخلی از یک آدرس عمومی را فراهم می‌کرد. به این ترتیب که بجای ذخیره کردن آدرس داخلی، آدرس داخلی به همراه پورت در جدول NAT ذخیره می‌شود. این همان نقطه‌ای است که «جهش بزرگ در صرفه‌جویی IPv4» رخ داد. با این روش، روی کاغذ تا حدود ۶۵,۰۰۰ نشست (Session) مختلف می‌توانستند تنها از یک IP عمومی استفاده کنند. به این روش جدید Network Address Port Translation یا NAPT گفته می‌شود که ممکن است شما با عناوینی همچون Port Address Translation یا PAT و یا NAT Overload آن را بشناسید.

گذار بهIPv6؛ راهکار نهایی مقابله با قحطی آدرس‌های IPv4

هنگامی که در اواسط دهه ۱۹۹۰ محدودیت ظرفیت آدرس‌دهی ۳۲ بیتی IPv4 و وقوع حتمی بحران اتمام آدرس‌ها اثبات شد، کار روی طراحی نسل جدیدی از پروتکل اینترنت تحت عنوانIPv6  آغاز گردید. هرچند تدوین و تصویب نهایی استاندارد رسمی آن تا سال ۲۰۱۷ به طول انجامید، اما این پروتکل با تغییر بنیادین ساختار آدرس‌دهی از ۳۲ بیت به ۱۲۸ بیت، فضای آدرس‌دهی را به شدت گسترش داد.

در IPv6 تعداد 2128 درس منحصربه‌فرد وجود دارد؛ عددی فراتر از تصور که نه‌تنها برای آدرس‌دهی تمام تجهیزات روی کره زمین، بلکه برای آدرس‌دهی کل جهان شناخته‌شده نیز کفایت می‌کند. با این حال، IPv6 صرفاً یک راه‌حل برای افزایش تعداد آدرس‌ها نبود، بلکه ویژگی‌های ارزشمند دیگری را نیز به ساختار شبکه تزریق کرد:

• حذف ترافیک Broadcast: بله، بجای استفاده از Broadcast از Multicast استفاده می‌کند. و این یعنی پروتکل‌هایی مانند ARP که با Broadcast کار می‌کنند به وسیله راه‌حل‌های دیگر جایگزین شده‌اند.
• Stateless Address Autoconfiguration: این ویژگی Hostها را قادر می‌سازد تا بدون نیاز به DHCP و بصورت خودکار برای خود IP تنظیم کنند. به این قابلیت SLAAC نیز می‌گویند.
• سهولت تغییر آدرس ثابت: تغییر آدرس‌های IPv4 ثابت ایستا کاری وقت‌گیر و طاقت‌فرسا است بخصوص اگر تعداد Hostها زیاد باشد. در حالیکه اگر از SLAAC استفاده شود با تغییر Prefix همه Hostها IPv6 خود را به صورت خودکار عوض می‌کنند.
• پشتیبانی از جابجایی (Mobility): در IPv6 قابلیت پشتیبانی از جابجایی بصورت داخلی (Built-in) وجود دارد. برای مثال وقتی با تلفن‌همراه خود به اینترنت متصل هستید، در صورت جابجایی بین شبکه خانگی و همراه IPv4 شما تغییر می‌کند که باعث قطع و وصلی در ارتباط‌های فعال شما می‌شود. چنین مشکلی در IPv6 حل شده‌است.
• بی‌نیاز از NAT و PAT: فضای آدرس IPv6 آنقدر زیاد است که نیاز به استفاده از PAT و NAT نیست و همه Hostها می‌توانند آدرس عمومی IPv6 داشته‌باشند. توجه داشته باشید که به این معنی نیست که نمی‌توان در IPv6 این قابلیت را پیاده‌سازی کرد.
• IPSec: IPv6 بصورت توکار از IPSec پشتیبانی می‌کند.

امروزه با وجود اینکه زیرساخت‌های بزرگ ارتباطی و دیتاسنترها به IPv6 مجهز شده‌اند، اما به دلیل پیوند عمیق IPv4 با تار و پود اینترنت جهانی، گذار کامل زمان‌بر خواهد بود. به همین دلیل امروزه اکثر تجهیزات مدرن از مکانیزم پشته دوگانه (Dual Stack) برای پشتیبانی هم‌زمان از هر دو پروتکل استفاده می‌کنند.

ساختار آدرس‌دهی در IPv6 به طور کلی با IPv4 متفاوت است. طراحان IPv6 نه‌تنها فضای آدرس‌دهی را به شدت گسترش دادند، بلکه ساختار نمایش، نوع آدرس‌ها و نحوه تخصیص آن‌ها را نیز بازطراحی کردند تا مسیریابی در هسته اینترنت کارآمدتر و ساده‌تر شود.در ادامه با این ساختار آشنا خواهیم شد.

نحوه نمایش آدرس IPv6

همانطور که گفته شد در IPv6 از 128 بیت برای آدرس‌دهی استفاده شده‌است که همین طولانی بودن طول آدرس سبب شده بجای نمایش دهدهی (Deciaml) از نمایش در مبنای شانزده یا (Hexadecimal) استفاده شود. همچنین بجای 4 اکتت، 8 بخش 16 بیتی داریم که به هرکدام Hexadectet یا به اختصار Hextet یا Double Octet گفته می‌شود و با دو نقطه (:) از هم جدا می‌شوند.

یک نمونه آدرس کامل IPv6 را در زیر مشاهده می‌کنید:

2001: 0db8: 85a3: 0000: 0000: 8a2e: 0370: 7334

قوانین فشرده‌سازی و خلاصه‌نویسی

از آنجایی که به خاطر سپردن و حتی نوشتن 32 کاراکتر هگزادسیمال کار سختی است، برای ساده‌سازی، دو قانون خلاصه‌نویسی برای این آدرس‌ها وجود دارد:

• حذف صفر‌های سمت چپ عدد: میتوانیم هر تعداد صفر سمت چپ عدد در هر بخش وجود دارد را حذف کنیم:

2001: db8: 85a3: 0: 0: 8a2e: 370: 7334

• استفاده از دو نقطه: می‌توان یک یا چند بخش متوالی که همگی صفر هستند را با یکبار نوشتن دو نقطه (::) جایگزین کرد. توجه داشته باشید که استفاده از این قانون تنها یکبار امکان پذیر است.

2001: db8: 85a3:: 8a2e: 370: 7334

انواع آدرس IPv6

علی‌رغم تفاوت‌هایی IPv6 با IPv4 دارد، شباهت‌هایی هم دارند. برای مثال آدرس‌های Unicast و آدرس‌های Public و Private هم در IPv6 با اسم‌های دیگر وجود دارند. اما آدرس‌های Unicast در IPv6 انواع متفاوتی دارد. در IPv6 آدرس‌های Multicast را هم داریم با همان کاربردی که در IPv4 داشت. آدرس‌های رزرو شده هم در IPv6 که استفاده‌های مشابه در IPv4 دارند. مورد جدیدی که در IPv6 داریم آدرس‌های نوع Anycast می‌باشد که آدرسی است که می‌تواند بر روی چند Host استفاده شود و بسته به نزدیک‌ترین Host خواهد رسید. و همانطور که پیشر گفته‌شد ترافیک Broadcast در IPv6 نداریم و بجای آن از Multicast استفاده می‌شود.

در ادامه نگاهی عمیق‌تر به انواع آدرس‌ها خواهیم داشت.

• Unicast: آدرس‌های Unicast در IPv6 دقیقا همان مفهوم مشابه در IPv4 است. این آدرس به منظور تنظیم بر روی کارت‌شبکه یک Host جهت ارسال و دریافت بسته‌های IPv6 کاربرد دارد. آدرس‌های Unicast انواع مختلفی دارند که عبارتند از:
  • Global Unicast: این نوع آدرس معادل آدرس‌های Public در IPv4 هستند و می‌توانند در اینترنت استفاده شوند. بزرگترین تفاوت آن با IPv4 این است که فضای آدرس بسیار بزرگی دارند که این امکان را به ما می‌دهند برای هر دستگاه شبکه از این آدرس استفاده کنیم.
  •  Unique Local: این نوع آدرس معادل آدرس‌های Private در IPv4 هستند. شما می‌‎توانید از این نوع آدرس در شبکه‌های خودتان استفاده کنید اگر نمی‌خواهید از که شبکه‌تان به اینترنت متصل شود و یا اگر قصد دارید از IPv6 NAT استفاده کنید. مزیت استفاده از این آدرس‌ اینست که نیازی نیست که IPv6 را اجاره کنید و برای آن پول بپردازید. این پیشوند FC00::/7 برای این آدرس‌های در نظر گرفته شده است و در عمل از FD00::/8 قابل استفاده است.
  • Link-Local: این آدرس چیزی شبیه آدرس APIPA در IPv4 است. به محض اینکه یک Host به شبکه وصل شود یک آدرس Link-Local بصورت خودکار تولید می‌کند. این آدرس قابل Route نیست ولی Hostهایی که روی یک لینک قرار دارند (یعنی ارتباط لایه دویی دارند) می‌توانند روی این IP با هم صحبت کنند و یکدیگر را پیدا کنند. از این آدرس برای Neighbor Discovery که جایگزین پروتکل ARP است استفاده می‌شود. این آدرس با پیشوند FE80::/10 شروع می‌شود.
  • Site-Local: این آدرس‌های برای این طراحی شده‌بود که به عنوان محدوده Private مورد استفاده قرار بگیرد، اما منسوخ شد و جای خود را به Unique Localها داد. این آدرس با FEC0::/10 شروع می‌شد.
  • Unspecified: آدرس 0:0:0:0:0:0:0:0 یا بطور خلاصه :: آدرس Unspecified یا آدرس نامشخص نامیده می‌شود. این نباید بر روی هیچ Hostیی استفاده شود و برای نشان دادن اینکه یک Host هیچ آدرسی ندارد از این آدرس استفاده می‌شود.
  • Loopback: آدرس 0:0:0:0:0:0:0:1 یا بطور خلاصه ::1 آدرس Loopback می‌باشد. دستگاه‌ها از این آدرس برای ارسال بسته به خودشان به منظور تست استفاده می‌کنند. این آدرس معادل 127.0.0.1 در IPv4 می‌باشد و قابل استفاده در شبکه هم نیست.
• Multicast: این آدرس‌های برای ارسال بسته به چند مقصد استفاده می‌شود. این آدرس با پیشوند FF00::/8 شروع می‌شود.
• Anycast: این نوع آدرس، نوع جدیدی است که در IPv6 وجود دارد. یک آدرس یکسان می‌تواند بر روی چندین Host تنظیم شود و حتی توسط پروتکل‌های مسیریابی Advertise شود. هنگامی که بسته‌ای به چنین مقصدی ارسال می‌شود، بسته به نزدیک‌ترین Host ارسال می‌شود. در IPv4 دقیقا چنین مفهومی وجود نداشت. برای این آدرس پیشوند مشخصی وجود ندارد، هر آدرس Unicast که بر روی چند Host استفاده شود تبدیل به این نوع آدرس می‌شود.

ساختار آدرس IPv6

یک آدرس IPv6 که برای اینترنت استفاده می‌شود، معمولا به دو بخش مساوی 64 بیتی تقسیم می‌شود:

• بخش شبکه (64 بیت اول): 
  • Global Routing Prefix: معمولا 48 بیت اول است و توسط ISP یا سازمان‌های ثبت اینترنت به سازمان تخصیص داده می‌شود و مشخص‌کننده موقعیت شبکه در اینترنت جهانی است.
  •  Subnet ID: معمولا 16 بیت بعدی (بیت 49 تا 64) است که به مدیر شبکه سازمان اجازه می‌دهد تا 216 یعنی ۶۵,۵۳۶ زیرشبکه داخلی ایجاد کند.
• بخش میزبان: 64 بیت دوم است که شناسه منحصربه‌فرد کارت شبکه (اینترفیس) دستگاه است. در IPv6 به دلیل بزرگ بودن این فضا، برخلاف IPv4 نیازی به VLSM برای صرفه‌جویی در بخش Host نیست و استاندارد همواره روی ۶۴ بیت آخر متمرکز است. این شناسه می‌تواند به صورت تصادفی، دستی، یا از روی آدرس MAC کارت شبکه به روش EUI-64 تولید شود.

روش تولید شناسه کارت شبکه به روش EUI-64

EUI-64 یا Extended Unique Identifier روشی برای تولید Interface ID از روی MAC کارت شبکه است. به کمک این روش نیازی به پیکربندی دستی IPv6 روی کارت شبکه نیست. اما چطور یک MAC آدرس 48 بیتی می‌تواند Interface ID را که 64 بیت است پر کند؟ برای این مهم مراحل زیر طی می‌شود:

• MAC آدرس به دو قسمت 24 بیتی تقسیم می‌شود.

• مقدار هگزادسیمال FFEE بین این دو قسمت قرار می‌گیرد.

  بعد	قبل
  001A: 2BFF: EE3C: 4D5E	001A: 2B _ _: _ _ 3C: 4D5E

• بیت هفتم معکوس می‌شود: بایت اول در مثال “00” است که اگر آن را به صورت دودویی بنویسیم و بیت هفتم آن را معکوس کنیم (یعنی اگر صفر است یک و اگر یک است صفر کنیم) عدد هگزادسیمال 02 به دست می‌آید.

سخن پایانی

نوشتن این مقاله، اولین تجربه من در کاوش مستقیم و عمیق در میان مستندات رسمی اینترنت یا همان RFCها بود؛ سندی به سند دیگر رفتن برای بیرون کشیدن تاریخ دقیق پیدایش یک پروتکل و پیوند زدن آن به داستانِ تکامل IP، مسیر چالش‌برانگیز اما به‌شدت لذت‌بخشی بود.

در این مقاله تمام تلاش خود را به کار بستم تا تقدم و تأخر تاریخی مفاهیم را کاملاً رعایت کنم؛ چرا که معتقدم تا ندانیم دیروز چه مشکلی وجود داشته، نمی‌توانیم راه‌حل‌های امروز (مانند سابنت‌ماسک، CIDR یا NAT) را به‌درستی درک کنیم. همچنین به زیبایی علم و مهندسی در پیشرفت و تصحیح تکنولوژی پی ببریم. تلاش کردم تا این مفاهیم فنی را در قالب یک روایت داستانی منسجم و ساده بیان کنم تا برای هر علاقه‌مندی قابل‌فهم باشد.

امیدوارم این مقاله برای شما مفید بوده‌ و زاویه دید جدید و شفافی از دنیای آدرس‌دهی شبکه به شما داده‌باشد. با این حال، مثل هر مسیر یادگیری دیگری، این نوشته هم ممکن است خالی از اشکال نباشد. خوشحال می‌شوم اگر کم و کسری در متن می‌بینید، نکته‌ای به نظرتان ناواضح است یا نیاز به اصلاح دارد، آن را حتماً با من در میان بگذارید تا با هم کامل‌ترش کنیم.