Коротка історія Internet та IP-технологій

М. Павликевич

ТЕЛЕКОМУНІКАЦІЙНІ МЕРЕЖІ

МережІ IP

Лекції для студентів cпеціальності

7.092402 “Інформаційні мережі зв’язку”

Львів, 2002

 

Зміст

ТЕЛЕКОМУНІКАЦІЙНІ МЕРЕЖІ................................................................................................ 1

3.1. Коротка історія Internet та IP-технологій........................................................................ 5

3.2. Модель TCP/IP........................................................................................................................ 7

3.3. Потреба в проектуванні IP-мереж....................................................................................... 8

3.3.1. Проектування IP-мережі................................................................................................... 9

3.3.1.1. Загальний погляд на проектування..................................................................................................................... 9

3.3.1.2. Етапи проектування мережі............................................................................................................................... 10

3.3.1.3. Розгляд застосувань........................................................................................................................................... 11

3.3.1.4. Розгляд платформ.............................................................................................................................................. 13

3.3.1.5. Розгляд мережевої інфраструктури.................................................................................................................. 14

3.3.1.6. Ідеальна мережа.................................................................................................................................................. 14

3.4. IP-адресація......................................................................................................................... 14

3.4.1. Структура IP-адреси................................................................................................... 14

3.4.2. Повнокласова та безкласова IP-адресація................................................................. 15

3.4.2.1. Структура IP-адрес при повнокласовій адресації............................................................................................. 15

3.4.2.2. Використання мережевої маски........................................................................................................................ 18

3.4.2.3. Безкласова IP-адресація..................................................................................................................................... 18

3.4.3. Мережі та підмережі........................................................................................................ 19

3.4.3.1. Спосіб впровадження підмереж............................................................................... 19

3.4.3.2. Розширений мережевий префікс і мережева маска............................................... 21

3.4.3.3. Організація підмереж – складання адресного плану............................................... 21

3.4.3.4. Загальні правила побудови адресного плану мережі з підмережами.................... 23

3.4.3.5. Нові розв’язання для масштабування адресного простору Internet....................... 24

3.4.3.6. Мережеві маски змінної довжини............................................................................ 24

3.4.3.7. Впровадження CIDR.................................................................................................. 27

3.4.3.8. Раутінг у безкласовому середовищі......................................................................... 29

3.5. Трансляція мережевих адрес............................................................................................ 30

3.5.1. Статична NAT................................................................................................................. 31

3.5.2. Динамічна NAT.............................................................................................................. 32

3.5.3. Динамічна NAT з перевантаженням............................................................................ 34

3.5.4. Динамічна NAT з надлишковими зовнішніми інтерфейсами................................... 35

3.5.5. NAT всередині локальних адрес................................................................................... 36

3.5.6. Динамічна NAT з трансляцією номерів портів для глобальної адресації................ 36

3.5.7. Спільне використання статичної та динамічної NAT............................................... 37

3.5.8. Переваги та недоліки NAT............................................................................................. 38

3.6. Відповідність між MAC-адресами та IP-адресами........................................................ 38

3.6.1. Протоколи високого рівня і MAC-адреси.................................................................... 38

3.6.2. Протокол ARP............................................................................................................... 38

3.6.3. Протокол RARP (Reverse Address Resolution Protocol)............................................... 40

3.7. Пересилання данограм..................................................................................................... 41

3.7.1. Концепція пересилання данограм............................................................................... 41

3.7.2. IP-данограма................................................................................................................... 41

3.7.2.1. IP-данограма та її формат...................................................................................... 41

3.7.2.2. Опції данограми......................................................................................................... 43

3.7.1. Інкапсуляція, фрагментація та реасемлювання данограми....................................... 46

3.7.1.1. Інкапсуляція данограми..................................................................................................................................... 46

3.7.1.2. Фрагментація данограми................................................................................................................................... 46

3.7.1.3. Реасемблювання данограми.............................................................................................................................. 48

3.8. Протокол повідомлень управління ICMP........................................................................ 49

3.8.1. Повідомлення ICMP....................................................................................................... 49

Модель TCP/IP.

У той час, як протоколи OSI розвиваються повільно, головним чином внаслідок їх формального, базованого на комітетах, інженерного підходу, система протоколів TCP/IP швидко розвивається і визріває. З політикою впровадження і модифікації системи протоколів RFC він встановився як кращий протокол для більшості комунікаційних мереж.

Як еталонна модель OSI і більшість інших комунікаційних протоколів для даних, TCP/IP є стеком протоколів, який складається з чотирьох рівнів (рис. 3.1).

Рис. 3.1. Стек протоколів TCP/IP.

Рівень застосувань – це процеси користувача, пов’язані з іншими процесами в тій самій або іншій станції. Він забезпечується програмами користувача, які вживають TCP/IP для комунікації. Прикладами поширених застосувань, які використовують TCP/IP, є Telnet – протокол для віддаленого сполучення терміналів, FTP – протокол пересилання файлів, SMTP - протокол пересилання електронної пошти. Існує багато інших, але це основні застосування. За винятком ping (який є простим засобом діагностики – протокол висилає пакет і визначає, чи отримане ехо-відповідь від призначення, щоб визначити досяжність призначення і як довго пакет слідує до призначення і назад), інші застосування є застосуваннями типу “клієнт-сервер”. Файли пересилаються до/від сервера від/до клієнта,електронна пошта висилається від клієнта до поштового сервера, читається із цього сервера клієнтом-приймачем; віддалене управління портом станції фактично є управлінням портом telnet-сервера з боку telnet-клієнта. Для таких застосувань кожен клієнт виконує “клієнтську програму”, тоді як сервер –“серверну програму”. Програми застосувань клієнта і сервера взаємодіють, спочатку для відкриття сесії (повідомлення про реєстрацію, адреса або назва ресурсу, доступ до якого портібний), потім для створення передавального і приймального буферів для сесії у клієнта і сервера, а також для встановлення правильних параметрів подання (кодування, шифрування, компресії, формату друку тощо). Як тільки ця фаза завершеня, то викликається рівень пакування-розпакування – Трансортний рівень. Інтерфейси між Рівнем застосувань і Транспортним рівнем визначені номерами протокольних портів і гніздами (sockets).

Транспортний рівень забезпечує наскрізне пересилання даних. Він відповідає за надійний обмін інформацією. В дійсності протоколи Транспортного рівня фізично не переміщають даних, вони тільки здійснюють їх упакування і розпакування. Програми і апаратура для переміщення даних викликаються цими протоколами для виконання властивих їм завдань.

Головним транспортним протоколом є TCP (Transmission Control Protocol – протокол управління пересиланням). TCP - це складний повнодуплексний протокол, який здійснює послуги зі встановленням сполучення. Він розділяє файл, що підлягає пересиланню, на частини, які називають “сегментами”. Сегмент TCP складається із заголовка і даних, пов’язаних із ним. Порти джерела і призначення використовуються для визначення номерів сесій клієнта і сервера.

Для кожного сегменту його місце у послідовності визначається висиланням спеціального пакету TCP і підтвердженням через отримання відповідного TCP-пакету. При висиланні пакетів TCP управління потоком сегментів керується призначенням “вікна”, яке має стільки бітів, скільки передавач може вислати водночас. Крім того, TCP може позначати дані як “термінові” або як “зовнішньо-термінові/слід_вислати”, і погоджувати максимальний розмір сегменту. Сегменти висилаються послідовно, перевіряються за допомогою циклічної контрольної суми (CRC); при виявленні помилок вимагається повторне пересилання. Порядковий номер сегменту TCP у послідовності, номер підтвердження, CRC, прапорці портів призначення і джерела, а також опції поміщені перед даними у заголовку сегменту.

Іншим протоколом Транспортного рівня є UDP (User Datagramm Protocol – протокол данограм користувача), який забезпечує послуги без встановлення сполучення. UDP – це дуже простий протокол, який пов’язує заголовок із даними, що складаються із номерів портів призначення і джерела та CRC, і пересилає дані одним пакетом (данограмою) без контролю послідовності або помилок. Це означає, що застосування, які вживають UDP як транспортний протокол, повинні забезпечувати власне наскрізне управління потоком. Звичайно UDP вживають для застосувань, які потребують швидкого механізму транспорту.

Рівень об’єднання мереж, який також називають Рівнем internet або Мережевим рівнем, забезпечує образ віртуальної мережі для об’єднання мереж (internet), є найвищим рівнем для типової мережевої архітектури, розташованої під цим рівнем, і відділяє фізичну мережу від рівнів понад нею. Найважливішим протоколом цього рівня є IP (Internet Protocol). Це протокол без встановлення сполучення, який не передбачає надійності нижніх рівнів. IP не забезпечує надійності, управління потоком або виправлення помилок. Ці функції повинні бути передбачені на вищих рівнях, зокрема, на Транспортному рівні при використанні TCP, або на Рівні застосувань, якщо вживається UDP. Одиницею повідомлення в IP-мережі є данограма. Це основний інформаційний блок, який пересилається через мережу TCP/IP. У стеку протоколів IP забезпечує функції раутінгу для розподілу цих данограм до коректних приймачів (адресатів).

Спосіб, у який працює протокол IP, полягає в наступному. У станції-джерелі TCP або UDP сегментують повідомлення і передають сегменти до IP. Протокол IP поміщає сегменти в данограми, дописуючи IP-заголовок, і пересилає данограми до “раутера за замовчуванням” (який в TCP/IP називають шлюзом). Раутер перевіряє заголовок кожної данограми і порівнює IP-адресу призначення з адресами мереж, які знаходяться під контролем цього раутера. Якщо адреса узгоджується, то раутер приймає пакет і пересилає його до мережі, в якій розташована станція-призначення. Якщо ні, то раутер перевіряє свою таблицю раутінгу для знаходження раутера наступного стрибка, до якого пересилає (маршрутує) данограму. Останній раутер, тобто той, який встановив відповідність адреси призначення своїй мережі, доручає данограму до станції-призначення. При цьому раутер використовує таблицю відповідності IP-адрес MAC-адресам станцій в мережі. Це таблиця протоколу розв’язування адрес (Address Resolution Protocol - ARP). Якщо потрібної адреси нема в таблиці, то раутер висилає ARP-запит, отримує ARP-відповідь про MAC-адресу потрібної станції та заносить її у таблицю.

Іншими протоколами Рівня internet є ICMP, IGMP та RARP.

Рівень мережевого інтерфейсу, який також називають Канальним рівнем, є здійснює інтерфейс до наявного мережевого обладнання (Фізичного рівня). Цей рівень також не гарантує надійного доручення даних; він може бути орієнтованим на пакети або потоки. TCP/IP не визначає жодного конкретного протоколу для цього рівня. Він може використовувати будь-який наявний мережевий інтерфейс, реалізуючи цим гнучкість мережі і сумісність з наявною інфраструктурою. Прикладами протоколів мережевого інтерфейсу, які підтримуються, є IEEE 802.3, Ethernet, X.25 (який є надійним сам по собі), Frame Relay, ATM. Канальний і Фізичний рівні фактично здійснюють транспорт даних.

Проектування IP-мережі

Внаслідок простоти та гнучкості IP, мережі можуть бути з’єднані між собою невпорядкованим чином. Це поширений спосіб сполучення мереж і вони можуть добре працювати. Якщо масштаб мереж невеликий. Проблеми виникають тоді, коли необхідно внести зміни, а документація відсутня. IP-мережа, яка не була систематично спроектована, неодмінно створює проблеми від початку стдії впровадження. Коли модернізується чинна мережа, то звичайно наявні інші чинні мережі. Які необхідно під’єднати.Впровадження нової технології без вивчення обмежень наявної мережі також може вести до появи непередбачених проблем. Тому проектування мережі слід здійснювати перед будь-яким впровадженням. Проект мережі повинен постійно переглядатися, коли протягом певного часу змінюються вимоги. Добрий проект включає детальну документацію мережі, потрібну для наступних посилань. Добле спроектовані мероежі прості для впровадження і створюють небагато несподіванок.

Методика проектування. Рекомендованою методикою проектування IP-мереж є підхід “зверху вниз”. Ця технологія слідує стеку протоколі TCP/IP. Як видно з рис., зверху стеку розташований рівень застосувань, тому він єпершим рівнем, який розглядається при проектуванні IP-мережі. Наступні два рівні – це Транспорнтий і Мережевий, а Канальний рівень є останнім.

Проектування застосувань визначається потребами організації. Правила діяльності організації, потоки процесів, вимоги безпеки і очікувані результати перетворюють у специфкації застосувань. Ці вимоги не тільки впливають на проектування застосувань, але суттєво відчутні на всіх нижчих рівнях.

Як тільки вимоги до Рівня застосувань визначені, то з них слідують вимоги до нижчих рівнів. Наприклад, якщо Рівень застосувань містить програму, яка вимагає двосекундного часу реакції на будь-яку мережеву транзакцію, то у проекті IP-мережі слід взяти це до уваги і вважати оптимізацію характеристик мережі найвищим пріоритетом. Канальний рівень повинен бути спроектований таким чином, щоб ці вимоги могли бути дотримані. При цьому використання плоскої моделі мережі з сотнями станцій, базованих на Windows, не є ідеальним вирішенням. Коли проектування IP-мережі завершене у погодженні з Рівнем застосувань, розпочинається її впровадження.

Проектування мережевої інфраструктури відіграє важливу роль і має визначальний вплив на загальний проект. Добрим прикладом є модульність і масштабованість всієї мережі. Нижче наведені основні аспекти проектування IP-мережі.

Етапи проектування мережі

Нижче викладено суть структурованого підходу до проектування IP-мереж. Основні етапи процесу проектування показані на рис. 3.2.

Рис. 3.2. Етапи проектування мережі.

Визначення цілей мережі. Цей етап проектування вимагає проведення досліджень і може бути тривалим. При цьому слід розглянути такі питання:

q Хто є користувачами IP-мережі і якими є їх потреби?

q Які застосування повинні підтримуватися?

q Чи IP-мережа заміняє чинну комунікаційну систему?

q Які кроки міграції необхідно розглянути?

q Якими є конкретні вимоги, загалом сформульовані вище в п. “Загальний погляд на проектування”?

q Хто відповідає за управління мережею?

q Чи мережа повинна бути поділена на більш керовані сегменти?

q Яким є час інснування мережі?

q Яким є бюджет?

Збір інформації для проектування. Інформація, неоюхідна для побудови мережі, залежить від кожного індивідуального впровадження, однак основні види потрібної інформації можуть бути виведені з “Загального погляду на проектування”. Важливо зібрати цю інформацію і витратити дещо часу на її аналіздля зрозуміння вимог середовища і обмежень перед проектуванням нової IP-мережі.

Формування пропозицій або специфікацій. Після збору інформації та визначення цілей мережі можна сформулювати пропозиції, які потім можуть бути оптимізовані. Міркування щодо проекту можуть надавати перевагу одній цілі за рахунок інших. Наприклад, мережа може бути оптимізована за характеристиками, за стійкістю до відмов, за захищеністю. Коли пріоритети для проектування визначені, можна створювати і документувати проект.

Огляд. Останнім етапом процесу проектування є огляд проекту перед впровадженням. На цьому етапі проект може бути модифікований, перш ніж здійснено інвестиції в інфраструктуру або в роботи з впровадження. Коли цей етап завершено, переходять до впровадження.

Розгляд застосувань

Як вказано вище, найвищим рівнем TCP/IP є Рівень застосувань. Елементи, які містяться на цьому рівні, визначаються потребами організації і ці компоненти повинні розглядатися як дуже важливі при початковому розгляді проекту в методиці проектування “зверху вниз”. Існує цілий ряд питань, які слід розглянути, при чому окремі з них є спільними для всіх застосувань, тоді як інші стосуються тільки до підмножини застосувань. Ці питання повинні бути визначені та опрацьовані.

Вимоги до ширини смуги. Різні застосування потребують різного обсягу смуги мережі. Очевидно, що застосування, які повинна підтримувати мережа, визначають тип мережі, яка буде остаточно спроектована. Не слід проектувати мережу без розгляду того, які застосування потрібні негайно, а які будуть потрібні в майбутньому.

Вимоги до характеристик. Слід розглянути вимоги до характеристик мережі від її користувачів. Користувачі мережі можуть допускати більший час відгуку від HTTP- або FTP-застосувань, але можуть не сприймати змін затримок (jitter) при пересиланні голосу через IP (VoIP), оскільки це викликає спотворення звуку. Також слід враховувати величину затримки при пересиланні трафіку. Великі затримки неприйнятні для застосувань, які оперують потоками даних, таких, як відео через IP. Правильність, з якою мережа здатна забезпечити дані для застосувань, також відноситься до проеткування мережі. Різна інфраструктура забезпечує різні рівні правильності для мережі.

Необхідні протоколи. Рівень застосувань TCP/IP підтрмує постійно зростаючу кількість протоколів. Основним при виборі протоколу для застосувань є те, чи застосування використовує TCP, чи UDP. TCP здійснює послуги віртуальних кіл, тоді як UDP – послуги данограм. UDP швидше доручає мережевий відгук власлідок того, що відсутнє службове навантаження від заголовку TCP, однак він не має надійності TCP, властивостей управління потоком і корекції помилок.

Якість послуг і тип послуг. Якість послуг (Quality of Service – QoS) і тип послуг (Type of Service – ToS) з’являються з одної причини – певні дані користувачів “важливіші” від інших і повинні бути обслужені у першу чергу. Вимоги до QoS і ToS включені в застосування і мають вплив на проектування мережі. Пристрої для сполучення, такі як раутери і комутатори, повинні мати можливість першочергового доручення інформації для підтримки вимог застосування.

Окремі застосування, такі як VoIP або системи впорядкування (сортування)інформації повинні працювати в режимі реального часу. Для них мережа повинна гарантувати рівень послуги. Застосування реального часу можуть потребувати впровадження власного управління потоками та виправлення помилок, якщо вони використовують UDP як транспортний протокол. Вимоги застосувань реального часу можуть також мати вплив на впровадження мережевої інфраструктури. Нариклад, мережа ATM може повністю задовільнити ці вимоги, тоді як мережа Ethernet зі спільним використанням середовища (протокол CSMA/CD) не може їх задовільнити.

Чутливість до втрат пакетів і затримок. Чутливість застосувань до втрат пакетів і затримок може мати драматичний вплив на користувача. Мережа повинна забезпечувати надійне доручення пакетів для таких застосувань. Наприклад, застосування реального часу з малою буферизацією не допускає затримок в дорученні пакетів, але поодинокі пакети втрачаються. VoIP є одним з прикладів таких застосувань,на відміну від перегляду Web.

Багатоадресне пересилання. Доказано, що багатоадресне пересилання (multicastang) – це добрий засіб для ощадності ширини смуги мережі, якщо вона правильно впроваджена. Впровадження багатоадресності залучає до тісної співпраці всі пристрої для сполучення, такі як раутери та комутатори, застосування, клієнтські операційні системи і сервери. Багатоадресне пересилання не може працювати, якщо кожна з цих підсистем не буде дотрмуватися вимог або якщо вони мають жорсткі обмеження.

Оснащення дорученнями. Наявність протоколів застосувань, які здійснюють доручення (proxyed), має вплив на вимоги до ширини смуги і на безпеку мережі. Так, застосування HTTP можуть бути просто керовані, коли для безпеки зінстальована “пожежна стінка” (firewall), бо послуги за дорученням (proxy) можуть бути розташовані поза пожежною стінкою в “демілітаризованій зоні” для обслуговування трафіку HTTP через пожежну стінку до застосувань. Однак для застосувань, базованих на протоколі TELNET, це не так просто. Протокол TELNET не підтрмує послуг за дорученням для свого трафіку. Тому або пожежна стінка повинна залишатися відкритою для цього порта, а застосування повинні використовувати сервер SOCK, або застосування не зможуть комунікуватися через пожежну стінку.

Потреба у директоріях. Різні застосування вимагають послуг директорій в IP-мережі. Послуги директорій включають DNS (Domain Name Service – послуга доменних імен), NIS, LDAP, X.500, DCE (Distributed Computing Environment – середовище розподілених обчислень) і, можливо, інші. Вибір послуг директорій залежить від підтримки застосувань цими послугами. Наприклад, застосуванням, базованим на стандарті ITU X.500, мало відповідають мережі, яка мають тільки сервери DNS. Певні застосування, базовані на протоколах PING та TFTP, не вимагають послуг директорій для свого функціонуванняч, хоч без цього складнощі з їх вживанням можуть значно зрости. Інші застосування безумовно вимагають послуг директорій, наприклад, електронна пошта, базована на протоколі SMTP.

Розподілені застосування можуть вимагати певного рівня послуг від IP-мережі. Ці послуги повинні поставлятися мережею, тому вони мусять бути враховані при її проектуванні. Наприклад, Distributed Computing Environment – середовище розподілених обчислень забезпечує платформу для побудови і використання розподілених застосувань, пов’язаних з такими послугами, як послуга директорії комірок (Cell Directory Service – CDS), послуга глобальної директорії (Global Direcriry Service – GDS), послуга захисту (Security Service), DCE Threads, послуга розподілу часу (Distributed Time Service – DTS) і послуга розподілених файлів (Distributed File Service – DFS). Ці послуги роблять доступними через мережу, тобто колективними, і вони забезпечують основу захищеного ядра для середовища DCE.

Масштабованість. Застосування, які вимагають масштабованості, повинні мати мережу, здатну задовільнити їх майбутні потреби, або придатну до модернізації. Якщо застосування спроектовані модульно, то мережа також повинна бути модульною.

Безпека. Безпека застосувань забезпечується протоколами, розташованими нижче, або самими застосуваннями. Наприклад, якщо застосування вживає протокол UDP на Транспортному рівні, то воно мусить використовувати власне шифрування і забезпечити власні потреби захисту.

Розгляд платформ.

Важливим кроком до побудови застосувань є вибір платформ для застосувань. Слід відповісти на деякі основні питання:

q Чи робоча станція підтримує графіку, чи тільки текст?

q Чи робоча станція відповідає основним вимогам щодо характеристик – швидкість процесора, обсяг пам’яті, дисковий простір тощо?

q Чи робоча станція має можливості для під’єднання до мережі, які відповідають вимогам?

Відповіді на наступні запитання можуть бути потрібні, якщо опрацьовуються застосування для робот під стеком TCP/IP:

q Чи робоча станція підтримує потрібну карту мережевого інтерфейсу? Мультимедійні застосування можуть потребувати використання мережі ATM, однак не всі робочі станції підтримують мережеві карти ATM.

q Чи ця карта відповідає застосованій кабельній системі? Сучасні мережеві карти мають порт для під’єднання до кабельної системи UTP, однак може бути потрібне під’єднання до багатомодового оптичного кабеля.

q Чи мережева карта оснащена потрібним драйвером?

q Чи операційна система станції підтрмує TCP/IP? Існують різні варіанти впроваджень TCP/IP. Добрим прикладом є Classical IP (CIP) та емуляція LAN (LANE) при використанні мережі ATM. Певні операційні системи можуть підтримувати тільки CIP.

q Чи стек TCP/IP підтримує підмережі? Не всі системи підримують підмережі, особливо старі системи.

q Чи операційна система підтримує потрібні API? Поширений спосіб побудови застосувань в TCP/IP полягає у використанні програмування гнізд (sockets), однак стек TCP/IP на робочій станції може не повністю підтримувати це програмування. Це особливо небезпечно в мережах з різними типами робочих станцій, які оснащені різними операційними системами.

q Чи операційна система підтримує декілька маршрутів за замовчуванням (default routes)? Деякі операційні системи (наприклад, Windows 95) не підтримують декількох маршрутів за замовчуванням. Це може бути серйозним пунктом відмови для деяких цільових застосувань.

q Чи операційна система підтримує багато визначень DNS? Якщо клієнти здатні мати тільки одне визначення DNS, то потрібні опції повинні бути вбудовані в сервер DNS. З другого боку, коли клієнти здатні підтримувати багато DNS, то застосування мусить підтримуватися API, які забезпечують таку можливість.

q Чи операційна система підтримує багатоадресні пересилання? Це може бути потрібне для доручення відео до користувачів, що дозволяє ощадно використовувати смугу мережі. Однак не всі клієнти підтримують багатоадресні пересилання.

q Чи операційна система підтримує новітні властивості, такі як протокол резервування ресурсів (Resource Reservation Protocol – RSVP)?

Ідеальна мережа

Що слід вважати ідеальною мережею? Якщо менеджер мережі призначений для побудови мережі організації, то він повинен знати, як уникнути всіх проблем, вказаних вище. Він повинен використати найкраще обладнання і вибрати найкращу з можливих мережевих технологій. Однак все ще неясно, чи побудована мережа буде досконалою.

В дійсності ідеальна мережа не існує. Проектування мережі базується на сьогоднішніх вимогах, які можуть не відповідати майбутнім. Середовище діяльності організації змінюється і це має наростаючий вплив на інфраструктуру. Очікувана кількість службовців і потреби користувачів змінюються, нові потреби адресуються застосуванням і це викликає потреби змін у мережевій інфраструктурі. Найкраще, коли мережа придатна до масштабування та адаптивна до змін. До того дня, коли будуть досягнені технічні обмеження мережі, ці два критерії залишаються доречними, після цього потрібні радикальні зміни.

IP-адресація

Структура IP-адреси.

Специфікації першого стандарту IP (IP version 4 або IPv4), прийнятого у 1981 році в документі RFC, вимагають, щоб кожна система, під’єднана до IP-мережі, мала призначену унікальну 32-бітову IP-адресу. Таким чином в IP-мережі з протоколом IPv4 адресний простір містить 2³²= 4 294 967 296 адрес.

IP-адреса має дворівневу структуру (рис. 3.3).

Рис. 3.3. Загальна структура IP-адреси.

Перша частина IP-адреси ідентифікує мережу, до якої під’єднана станція, а друга - конкретну станцію у даній мережі. Першу частину адреси називають номером мережі, ідентифікатором мережі (NetID) або, частіше, мережевим префіксом; другу частину – мережевим суфіксом, номером станції або ідентифікатором станції (HostID). Останній термін, хоч загальноприйнятий, неточно відображає суть цієї частини адреси. Наприклад, станція, яка має два або більше фізичних під’єднань до мереж (multi-home host), потребує двох або більше IP-адрес, при чому кожна адреса відповідає одному з під’єднань станції до відповідної мережі. Раутер, який з’єднує n мереж, має n різних IP-адрес, по одній для кожного мережевого під’єднання (інтерфейсу). Тому точніше було б мережевий суфікс називати номером інтерфейсу станції.

Дворівнева структура IP-адреси відображає ієрархічний принцип побудови адресного простору в IP-мережах. Всі станції в даній мережі мають той самий мережевий префікс, але різні (унікальні) номери станцій. Будь-які дві станції в різних мережах мусять мати різні мережеві префікси, але можуть мати однакові номери станцій. Це означає, що кожна станція (точніше, кожен мережевий інтерфейс станції) однозначно ідентифікується за номером мережі, до якого вона належить, і номером станції (інтерфейсу станції) у цій мережі. Ієрархічна побудова адресного простору в IP-мережах дозволяє побудувати маршрутизацію (раутінг) пакетів таким чином, що пакети спочатку скеровуються до потрібної мережі на підставі мережевого префіксу адреси призначення, а в межах цієї мережі – до потрібної станції з використанням номера станції (інтерфейсу).

Спосіб поділу 32 бітів адреси на номер мережі та номер станції, тобто спосіб визначення пункту поділу 32 бітів на частину, яка описує мережевий префікс, і частину, яка відповідає номеру станції, визначає два підходи до побудови і використання адресного простору: історично перший – повнокласову адресацію і новітній – безкласову адресацію в IP-мережах. На даний час в IP-мережах застосовуються обидва підходи. Це обумовлено тим, що повнокласова адресація, як історично перша, все ще широко використовується у програмних модулях раутерів вищих рівнів ієрархії IP-мереж, а великий розмір сучасних IP-мереж (Internet) не дозволяє достатньо швидко і без ускладнень здійснити повсюдний перехід до більш прогресивної безкласової адресації. Більш детальна інформація про переваги та недоліки повнокласової і безкласової адресації в IP-мережах наведена нижче.

Безкласова IP-адресація

У 1992 році, внаслідок експоненціального зростання Internet, IETF розпочав роботи щодо забезпечення можливості масштабування системи раутінгу Internet і підтримки майбутнього зростання. Опрацьована концепція безкласового внутрішньодоменного раутінгу (Classless Inter-Domain Routing – CIDR). CIDR офіційно удокументована у вересні 1993 року в RFC 1517, RFC 1518, RFC 1519 та RFC 1520. CIDR підтримує дві важливі характеристики, які покращують глобальну систему раутінгу Internet:

q CIDR виключає традиційну концепцію мережевих адрес класів A, B і C, замінюючи її узагальненою концепцією мережевого префіксу. Замість перших трьох бітів IP-адреси, для визначення точки поділу IP-адреси на мережеву адресу (NetID) та адресу станції (HostID). раутери використовують мережевий префікс. Тому CIDR підтримує впровадження мережевих адрес довільного розміру (у межах, можливих для IPv4) замість стандартних 8-бітових, 16-бітових або 24-бітових мережевих адрес, властивих повнокласовій адресації.. Це створює можливість ефективного розподілу адресного простору IPv4, що, у свою чергу, дозволяє подальше зростання Internet до наступного впровадження IPv6.

q CIDR підтримує агрегування маршрутів, коли окремий вхід таблиці раутінгу може репрезентувати адресний простір, який охоплює тисячі традиційних повнокласових маршрутів, визначаючи, як маршрутувати трафік до багатьох індивідуальних мережевих адрес. Агрегування маршрутів допомагає контролювати обсяг раутінгової інформації в раутерах магістралей Internet, зменшує швидкі зміни наявності маршрутів і спрощує локальні адмістративні витрати на модифікацію зовнішньої раутінгової інформації.

Раутер, який підтримує CIDR, не використовує перших трьох бітів адреси для визначення довжини мережевого префіксу. Натомість префікси розглядаються як неперервний блок адресного простору. Наприклад, всі префікси /20 представляють той сам обсяг адресного простору (2¹²=4096 адрес станцій). На відміну від повнокласової адресації, у моделі CIDR кожна частина раутінгової інформації оголошується разом з мережевою маскою або з довжиною префіксу. Наприклад, мережа з 20-бітовим номером мережі та 12-бітовими номерами станцій повинна оголошуватися з 20-бітовою довжиною префіксу, тобто як /20. Така IP-адреса може належати до колишнього класу A, B або C. Для ілюстрації в табл. наведені найбільш широко впроваджені адресні блоки CIDR.

Таблиця 3.3. Адресні блоки CIDR.

Довжина префіксу CIDR	Мережева маска	Кількість індивідуальних адрес	Кількість повнокласових мереж
/13	255.248.0.0	512 K	8 B або 2048 C
/14	255.252.0.0	256 K	4 B або 1024 C
/15	255.254.0.0	128 K	2 B або 512 C
/16	255.255.0.0	64 K	1 B або 256 C
/17	255.255.128.0	32 K	128 C
/18	255.255.192.0	16 K	64 C
/19	255.255.224.0	8 K	32 C
/20	255.255.240.0	4 K	16 C
/21	255.255.248.0	2 K	8 C
/22	255.255.252.0	1 K	4 C
/23	255.255.254.0		2 C
/24	255.255.255.0		1 C
/25	255.255.255.128		½ C
/26	255.255.255.192		¼ C
/27	255.255.255.224		^1/8 C

Мережі та підмережі.

Впровадження CIDR

У повнокласовому середовищі надавач послуг Internet (Internet Service Provider – ISP) може виділяти тільки блоки адрес /8, /16 або /24, що веде до великих втрат адресного простору. У середовищі CIDR ISP може виділити такий блок з зареєстрованого за ним адресного простору, який точно відповідає потребам кожного клієнта.

Приклад 1. Нехай для ISP виділений адресний блок 206.0.64.0/18, який містить 2¹⁴=16384 адреси, які можна інтерпретувати як 64 блоки /24. Якщо клієнт потребує 800 адрес станцій, то замість виділення йому класу B (і втрати 64700 адрес) або чотирьох класів C (і впровадження чотирьох нових маршрутів до таблиць раутінгу глобального Internet) ISP може призначити для клієнта адресний блок 206.0.68.0/22, у якому є 1024 адреси, але з агрегуванням і оголошенням одного входу для таблиці раутінгу, що еквівалентне чотирьом послідовним /24 (табл.).

Таблиця 3.5. Ефективність виділення адресного простору CIDR.

Адресний блок ISP	206.0.64.0/18
Адресний блок клієнта	206.0.68.0/22
Блок класу C № 0	206.0.68.0/24
Блок класу C № 1	206.0.69.0/24
Блок класу C № 2	206.0.70.0/24
Блок класу C № 3	206.0.71.0/24

 

Приклад 2. Приймемо, що ISP має блок адрес 200.25.0.0/16. Цей блок містьть 2¹⁶=65536 IP-адрес або 256 груп /24. З цього блоку необхідно виділити адресний блок 200.25.16.0/20, в якому є 4096 адрес (або 16 блоків по /24). У повнокласовому середовищі ISP мусить виділяти блок /20 як 16 окремих однакових блоків по /24:

Мережа № 0	200.25.16.0/24
Мережа № 1	200.25.17.0/24
Мережа № 2	200.25.18.0/24
Мережа № 3	200.25.19.0/24
Мережа № 4	200.25.20.0/24
: :	: :
Мережа № 13	200.25.16.29/24
Мережа № 14	200.25.16.30/24
Мережа № 15	200.25.16.31/24

Однак, у безкласовому середовищі ISP може поділити адресний блок так, як це доцільно. Наприклад, він може виділити половину адресного простору для організації А, далі поділити другу половину навпіл (кожна частина становитиме ¼ адресного простору) і призначити одну частину організації B, нарешті, поділити решту на дві частини (кожна по ¹/₈ адресного простору) і призначити їх організаціям C і D, як це проілюстроване нижче.

1) Поділ блоку адрес 200.25.16.0/20 на дві частини по 2¹¹=2048 адрес:

Адресний блок ISP	200.25.16.0/20
Організація A	200.25.16.0/21
Резерв	206.25.24.0/21