ЛАБОРАТОРНА РОБОТА № 7

Тема: Протоколи мережного рівня – IP та ICMP.

Мета: Вивчити протокол IP, зокрема, формат IP-дейтаграми. Вивчити деякі

аспекти протоколу ICMP, формат та зміст ICMP-повідомлень

Час виконання: 2 год.

ХІД РОБОТИ
У цій лабораторній роботі ми вивчимо протокол IP, зосередивши свою
увагу на форматі IP дейтаграми. Будемо робити це на основі аналізу
послідовності IP дейтаграм, відправлених та отриманих під час виконання
програми traceroute. Також проведемо дослідження різних полів IP
дейтаграми.
Перед тим, як починати лабораторну роботу, рекомендуємо повторити те,
що вам відомо про протокол ІР (інформація є також у додатку).

Перехоплення пакетів ІР програми traceroute

З метою формування послідовності IP дейтаграм будемо використовувати

програму traceroute для відправки дейтаграм різних розмірів у певний пункт
призначення.
traceroute працює таким чином: спочатку відправляється одна або
декілька дейтаграм з встановленим в 1 полем заголовку IP “час життя” (time-to-
live – TTL). Потім надсилається серія з однієї або декількох дейтаграм з тією ж
адресою призначення, але зі значенням TTL 2, далі – серія дейтаграм зі
значенням TTL 3, і так далі. Кожний маршрутизатор повинен зменшувати на 1
TTL кожної отриманої дейтаграми. Коли TTL досягне 0, маршрутизатор
повинен знищити дейтаграму і повернути повідомлення ICMP TTL-exceeded
(типу 11) на хост-відправник. У результаті, дейтаграма з TTL 1 знайде адресу
першого маршрутизатора, дейтаграма з TTL 2 викличе відправку ICMP
відповіді маршрутизатора 2, і т.д. Таким чином, програма traceroute допоможе
виявити маршрут від вашого комп’ютера до шуканої адреси.
Запустимо traceroute і змусимо відправляти дейтаграми різної довжини.
Послідовність дій відрізняється в залежності від того, на якій платформі
виконується робота – Unix/Linux чи Windows.

Linux/Unix

За допомогою команди traceroute розмір дейтаграми UDP, що

посилається за призначенням, може бути явно встановлений шляхом
зазначення кількості байтів дейтаграми. Це значення вводиться в команді
traceroute відразу після імені або адреси призначення. Наприклад, щоб
traceroute відправила дейтаграму довжиною 2000 байт на адресу 10.25.0.1,
команда має виглядати:
% traceroute 10.25.0.1 2000
Виконайте наступні дії:

1. Запустіть Wireshark і почніть перехоплення пакетів.

2. Введіть 3 команди traceroute, одна з довжиною 56 байт, наступна з

довжиною 2000 байт, і остання з довжиною 3500 байт.

3. Зупиніть перехоплення пакетів (Ви можете завантажувати послідовність

перехоплених дейтаграм у файл).

Windows

У Windows замість traceroute застосовується програма tracert, яка

працює за аналогічним алгоритмом. Однак, tracert в якості запитів застосовує
не дейтаграми UDP, як traceroute, а ICMP ехо-запити (ping). У більшості
випадків це не впливає на результат.
Але програма tracert не дозволяє змінити розмір запиту. Тому для
трасування у цій частині лабораторної роботи ми будемо використовувати
програму pingplotter, що доступна у безкоштовній і умовно-безкоштовній
версіях на http://www.pingplotter.com. Будемо вважати, що ця програма вже
встановлена на робочій станції, на якій виконують лабораторну роботу.
Протестуйте pingplotter, виконавши декілька traceroute-запитів на ваші
улюблені сайти. Ви можете явно встановити розмір ехо-запитів в pingplotter,
вибравши в меню Edit → Advanced Options→ Packet Options, а потім
заповнивши поле розміру пакетів. За замовчуванням розмір пакетів дорівнює 56
байтам.
Виконайте наступні дії:

1. Запустіть Wireshark і почніть перехоплення пакетів.

2. Запустіть pingplotter і введіть адресу призначення в полі Address to Trace
Window. Введіть 3 в полі # of times to Trace (не дуже багато, щоб не
збирати забагато даних). Виберіть пункт меню Edit → Advanced Options
→ Packet Options і введіть значення 56 в полі Packet Size, а потім
натисніть ОК. Натисніть кнопку Trace. Ви повинні побачити вікно
pingplotter, яке виглядає приблизно так, як на рис.
 Рис. Вікно програми pingplotter

3. Далі відправте набір дейтаграм більшої довжини, для чого виберіть Edit
→ Advanced Options → Packet Options і введіть значення 2000 в полі
Packet Size, а потім натисніть ОК. Тепер натисніть кнопку Resume.
4. І нарешті, відправте набір дейтаграм ще більшої довжини, для чого
виберіть Edit → Advanced Options → Packet Options і введіть значення
3000 в полі Packet Size, а потім натисніть ОК. Знов натисніть кнопку
Resume.
5. Зупиніть Wireshark трасування.

Дослідження перехоплених пакетів ІР

У перехоплених даних ви повинні побачити серію ICMP ехо-запитів

(Windows) або сегментів UDP (Unix), що були відправлені, та відповіді на них
проміжних маршрутизаторів (на рисунку наявні обидва типи запитів). У
наведених нижче питаннях вважаємо, що ви використовуєте Windows. У
випадку, якщо ОС – Unix, відповідні питання також мають бути зрозумілими.
 Рис. Запити traceroute і tracert, і відповіді на них

1. Виберіть перший ICMP ехо-запит, який був посланий вашим

комп'ютером, і розкрийте деталі заголовку протоколу ІР. Якою є ІР
адреса Вашого комп’ютера?
2. Дивлячись на заголовок ІР, скажіть яким є значення поля протоколу
вищого рівня.
3. Який розмір має ІР-заголовок? Скільки байтів містять дані корисного
навантаження ІР-дейтаграми? Поясніть, будь-ласка, як ви це визначили.
4. Чи була ця ІР-дейтаграма фрагментована? Поясніть вашу відповідь.

Далі, відсортуйте пакети трасування за ІР-адресою відправника. Виберіть

перший ICMP ехо-запит і розкрийте деталі заголовку протоколу ІР.
Використовуючи стрілки на клавіатурі, переключайтеся по ICMP
повідомленнях, що були послані Вашим комп’ютером.

5. Які поля IP дейтаграми завжди змінюються?

6. Які поля IP дейтаграми не змінюються? Які поля не мають змінюватися?
Які поля мають змінюватися? Чому?

Далі, знайдіть пакети ICMP-відповідей.

 7. Якими є значення полів ідентифікації та TTL ?
8. Чи ці значення не змінюються для всіх ICMP-пакетів, що були послані на
Ваш комп’ютер найближчим роутером? Чому?

Фрагментація

Відсортуйте лістинг пакетів за часом.

9. Знайдіть перший ICMP Echo Request, який було надіслано на Ваш

комп'ютер після того, як Ви змінили розмір пакета в pingplotter на 2000.
Чи було це повідомлення фрагментованим на декілька дейтаграм?
10. Виведіть перший фрагмент фрагментованої ІР-дейтаграми. Яка
інформація підкаже, що ця дейтаграма була фрагментована? Якої
довжини ця ІР дейтаграма?
11. Виведіть другий фрагмент. Яка інформація покаже, що це не перший
фрагмент? Чи існують ще якісь фрагменти? Чому?
12. Яке поле змінилося в заголовку ІР в першому і другому фрагментах?

Знайдіть перший ICMP Echo Request, який було надіслано на Ваш комп'ютер
після того, як ви змінили розмір пакета в pingplotter на 3500.

13. Скільки фрагментів було створено з оригінальної дейтаграми?

14. Яке поле змінюється в ІР заголовку у фрагментах?

Дослідження протоколу ICMP

Далі ми розглянемо деякі аспекти протоколу ICMP:

1. ICMP-повідомлення, які генеруються програмою ping;

2. ICMP-повідомлення, які генерується програмою traceroute;
3. Формат та зміст ICMP-повідомлень.

До того, як починати, ми рекомендуємо повторити інформацію про протокол

ІР.

ICMP та ping

Почнемо дослідження ICMP за допомогою програми ping. Нагадаємо, що

програма ping – це простий засіб, який дозволяє будь-якому користувачеві
перевірити досяжність деякої IP адреси. Програма ping відправляє пакет ICMP
(ехо-запит) на цільову IP адресу, яку ми перевіряємо, а та або відповідає,
надсилаючи нам пакет ICMP (ехо-відповідь), або не відповідає.
Виконайте наступне:

1. Запустіть командне вікно (у Windows – cmd, у Unix/Linux – shell).

2. Запустіть Wireshark і почніть перехоплення пакетів.
 3. В командному рядку наберіть команду

ping –n 10 <hostname>
де hostname – це доменне ім’я або IP адреса хосту. Поясніть, що означає
аргумент 10.

4. Спостерігайте за результатами, які виводить програма ping. Після

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

Лістинг на рисунку показує 20 пакетів: 10 тих, що були відправлені, та 10,

які були отримані у відповідь. Також бачимо, що ІР дейтаграми даних пакетів
мають номер мережного протоколу 1, що є номером ІСМР. Це означає, що
дейтаграми ІР містять повідомлення ІСМР.
Зверніть увагу на те, що ICMP пакети, що генеруються програмою ping, є
пакетами типу 8 з кодом 0 – так звані пакети ІСМР ехо-запитів. Також зверніть
увагу на те, що ці пакети обов’язково мають контрольну суму, ідентифікатор та
порядковий номер.
За результатами ping-тесту дайте відповіді на наступні запитання:

1. Якою є ІР адреса вашого комп’ютера? Якою є ІР адреса хоста

призначення?
2. Чому ІСМР пакети не мають порта відправника та порта призначення?
3. Яким є тип і код ІСМР пакету, що був відправлений вами?
4. Яким є тип і код ІСМР пакету, що був отриманий вами у відповідь?

ICMP та tracert

Дослідимо пакети ІСМР, що відправляються програмою tracert (в ОС

Windows). Докладніше про цю програму та принципи її роботи розказано вище.

5. Відкрийте командний рядок Windows

6. Запустіть Wireshark і почніть перехоплення пакетів.
7. В командному рядку наберіть

tracert <hostname>
де hostname – це віддалений хост.

8. Після закінчення тесту припиніть перехоплення пакетів Wireshark.

Рисунок нижче показує вікно Wireshark, що виводить ІСМР пакети, які

були повернуті маршрутизатором. Зверніть увагу на те, що це повідомлення
ІСМР про помилки, які містять набагато більше інформації, ніж ті пакети ICMP
ехо-запитів, що призвели до цих помилок.
 Результат роботи програми tracert у вікні Wireshark

Зверніть увагу на те, що виведено у командному вікні і у вікні Wireshark, і

дайте відповіді на наступні питання:

5. Якою є Ваша ІР адреса? Якою є ІР адреса хоста призначення?

6. Якщо ІСМР надсилає UDP пакети, чи буде для даних пакетів номер
протоколу ІР 01? Якщо ні, то яким він буде?
7. Яка різниця між ICMP пакетами, що були отримані в першій частині
лабораторної роботи і в другій?
8. Дослідіть ІСМР-пакети помилок. Які є відмінності між ними і пакетами
ICMP echo?
9. Чи з виведених даних tracert можна дізнатися, який з каналів маршруту
мав затримку з відповіддю значно довшу, аніж інші?
Додаток

Протокол IP
Основні функції протоколу IP

Основу транспортних засобів стеку протоколів TCP/IP становить протокол

міжмережевої взаємодії (Internet Protocol, IP). Він забезпечує передачу дейтаграм від
відправника до одержувачів через об'єднану систему комп'ютерних мереж.
Назва протоколу – Internet Protocol – відображає його суть: він повинен передавати
пакети між мережами. У кожній черговій мережі, що лежить на шляху переміщення пакета,
протокол IP викликає засоби транспортування, прийняті в цій мережі, щоб з їхньою
допомогою передати цей пакет на маршрутизатор, що веде до наступної мережі, або
безпосередньо на вузол-одержувач.
Протокол IP належить до протоколів без установлення сполучень. Перед IP не
ставиться задача надійної доставки повідомлень від відправника до одержувача. Протокол IP
обробляє кожен IP-пакет як незалежну одиницю, що не має зв'язку ні з якими іншими IP-
пакетами. У протоколі IP немає механізмів, звичайно застосовуваних для збільшення
вірогідності кінцевих даних: відсутнє квітування – обмін підтвердженнями між
відправником й одержувачем, немає процедури впорядкування, повторних передач або
інших подібних функцій. Якщо під час просування пакета відбулася яка-небудь помилка, то
протокол IP зі своєї ініціативи нічого не робить для виправлення цієї помилки. Наприклад,
якщо на проміжному маршрутизаторі пакет був відкинутий через закінчення часу життя або
через помилку в контрольній сумі, то модуль IP не намагається заново послати зіпсований
або загублений пакет. Всі питання забезпечення надійності доставки даних по складеній
мережі в стеці TCP/IP вирішує протокол TCP, що працює безпосередньо над протоколом IP.
Саме TCP організує повторну передачу пакетів, коли в цьому виникає необхідність.
Важливою особливістю протоколу IP, що відрізняє його від інших мережевих
протоколів (наприклад, від мережевого протоколу IPX), є його здатність виконувати
динамічну фрагментацію пакетів при передачі їх між мережами з різними максимально
припустимими значеннями поля даних кадрів MTU. Властивість фрагментації багато в чому
сприяла тому, що протокол IP зміг зайняти домінуючі позиції в складних складених
мережах.
Є прямий зв'язок між функціональною складністю протоколу й складністю заголовка
пакетів, які цей протокол використовує. Це пояснюється тим, що основні службові дані, на
підставі яких протокол виконує ту або іншу дію, переносяться між двома модулями, що
реалізують цей протокол на різних машинах, саме в полях заголовків пакетів. Тому дуже
корисно вивчити призначення кожного поля заголовка IP-пакета, і це вивчення дає не тільки
формальні знання про структуру пакета, але й пояснює всі основні режими роботи протоколу
щодо обробки й передачі IP-дейтаграм.

Структура IP-пакета

IP-пакет складається із заголовка й поля даних. Заголовок, що, як правило, має

довжину 20 байтів, має наступну структуру (див. рис. нижче).
 Структура заголовка IP-пакета

Поле Номер версії (Version), що займає 4 біти, вказує версію протоколу IP. Зараз
повсюдно використовуються версії 4 (IPv4) і 6 (IPv6).
Поле Довжина заголовка (IHL) IP-пакета займає 4 біти і вказує значення довжини
заголовка, вимірюване в 32-бітових словах. Звичайно заголовок має довжину в 20 байтів
(п'ять 32-бітових слів), але при збільшенні обсягу службової інформації ця довжина може
бути збільшена за рахунок використання додаткових байтів у полі Опції (IP Options).
Поле Тип сервісу (Type of Service) займає один байт і задає пріоритетність пакета й вид
критерію вибору маршруту. Перші три біти цього поля утворюють підполе пріоритету
пакета (Precedence). Пріоритет може мати значення від найнижчого – 0 (нормальний пакет)
до найвищого – 7 (пакет керуючої інформації). Маршрутизатори й комп'ютери можуть брати
до уваги пріоритет пакета й обробляти більш важливі пакети в першу чергу. Поле Тип сервісу
містить також три біти, що визначають критерій вибору маршруту. Реально вибір
здійснюється між трьома альтернативами: малою затримкою, високою вірогідністю та
високою пропускною здатністю. Встановлений біт D (delay) говорить про те, що маршрут
повинен вибиратися для мінімізації затримки доставки даного пакета, біт Т – для
максимізації пропускної здатності, а біт R – для максимізації надійності доставки. У багатьох
мережах поліпшення одного із цих параметрів пов'язане з погіршенням іншого, крім того,
обробка кожного з них вимагає додаткових обчислювальних витрат. Тому рідко коли має
сенс установлювати одночасно хоча б два із цих трьох критеріїв вибору маршруту.
Зарезервовані біти мають нульове значення.
Поле Загальна довжина (Total Length) займає 2 байти й означає загальну довжину
пакета з урахуванням заголовка й поля даних. Максимальна довжина пакета обмежена
розрядністю поля, що визначає цю величину, і становить 65535 байтів, однак у більшості
хост-комп'ютерів і мереж настільки великі пакети не використовуються. Під час передачі по
мережах різного типу довжина пакета вибирається з урахуванням максимальної довжини
пакета протоколу нижнього рівня, що несе IP-пакети. Якщо це кадри Ethernet, то
вибираються пакети з максимальною довжиною в 1500 байтів, що вміщаються в поле даних
кадру Ethernet. У стандарті передбачається, що всі хости повинні бути готові приймати
пакети аж до 576 байтів завдовжки (приходять вони цілком, чи фрагментами). Хостам
рекомендується відправляти пакети розміром більш ніж 576 байтів, тільки якщо вони
впевнені, що приймаючий хост або проміжна мережа готові обслуговувати пакети такого
розміру.
 Поле Ідентифікатор пакета (Identification) займає 2 байти й використовується для
розпізнавання пакетів, що утворилися фрагментацією вихідного пакета. Всі фрагменти
повинні мати однакове значення цього поля.
Поле Прапори (Flags) займає 3 біти й містить ознаки, пов'язані із фрагментацією.
Встановлений біт DF (Do not Fragment) забороняє маршрутизатору фрагментувати даний
пакет, а встановлений біт MF (More Fragments) говорить про те, що даний пакет є проміжним
(не останнім) фрагментом. Біт, що залишився, зарезервований.
Поле Зсув фрагмента (Fragment Offset) займає 13 бітів і задає зсув у байтах поля
даних цього пакета від початку загального поля даних вихідного пакета, підданого
фрагментації. Використовується при зборці/розбиранні фрагментів пакетів при передачах їх
між мережами з різними величинами MTU. Зсув повинен бути кратним 8 байтам.
Поле Час життя (Time to Live) займає один байт й означає граничний строк,
протягом якого пакет може переміщатися по мережі. Час життя даного пакета виміряється в
секундах і задається джерелом передачі. На маршрутизаторах та інших вузлах мережі після
закінчення кожної секунди з поточного часу життя віднімається одиниця; одиниця
віднімається й у тому випадку, коли час затримки менше секунди. Оскільки сучасні
маршрутизатори рідко обробляють пакет довше, ніж за одну секунду, то час життя можна
вважати рівним максимальному числу вузлів, які дозволено пройти даному пакету до того,
як він досягне місця призначення. Якщо параметр часу життя стане нульовим до того, як
пакет досягне одержувача, цей пакет буде знищений. Час життя можна розглядати як
годинниковий механізм самознищення. Значення цього поля змінюється під час обробки
заголовка IP-пакета.
Ідентифікатор Протокол верхнього рівня (Protocol) займає один байт і вказує, якому
протоколу верхнього рівня належить інформація, розміщена в полі даних пакета (наприклад,
це можуть бути сегменти протоколу TCP, дейтаграми UDP, пакети ICMP або OSPF).
Значення ідентифікаторів для різних протоколів приводяться в документі RFC «Assigned
Numbers».
Контрольна сума (Header Checksum) займає 2 байти й розраховується тільки по
заголовку. Оскільки деякі поля заголовка міняють своє значення в процесі передачі пакета по
мережі (наприклад, час життя), контрольна сума перевіряється й повторно розраховується
під час кожної обробки IP-заголовка. Контрольна сума – 16 бітів – підраховується як
доповнення до суми всіх 16-бітових слів заголовка. На час обчислення контрольної суми
значення самого поля «контрольна сума» встановлюється в нуль. Якщо контрольна сума
неправильна, то пакет буде відкинуто, як тільки помилку буде виявлено.
Поля IP-адреса джерела (Source IP Address) і IP-адреса призначення (Destination IP
Address) мають однакову довжину – 32 біти – і однакову структуру.
Поле Опції (IP Options) є необов'язковим і використається зазвичай тільки під час
налагодження мережі. Механізм опцій надає функції керування, які необхідні або просто
корисні в певних ситуаціях, однак він не потрібен у звичайних комунікаціях. Це поле
складається з декількох підполів, кожне з яких може бути одним з восьми визначених типів.
У цих підполях можна вказувати точний маршрут проходження маршрутизаторів,
реєструвати маршрутизатори, які проходить пакет, поміщати дані системи безпеки, а також
часові оцінки. Оскільки число підполів може бути довільним, то наприкінці поля Опції
мають бути додані кілька байтів для вирівнювання заголовку пакета по 32-бітній межі.
Поле Вирівнювання (Padding) використовується для того, щоб переконатися в тому,
що IP-заголовок закінчується на 32-бітній межі. Вирівнювання здійснюється нулями.
Нижче наведено роздрук значень полів заголовка одного з реальних IP-пакетів,
захоплених у мережі Ethernet засобами аналізатора протоколів Microsoft Network Monitor.

IP: Version = 4 (0x4)

IP: Header Length = 20 (0x14)
IP: Service Type = 0 (0x0)
IP: Precedence = Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: Total Length = 54 (0x36)
IP: Identification = 31746 (Ox7C02)
IP: Flags Summary = 2 (0x2)
IP: .......0 = Last fragment in datagram
IP: ......1. = Cannot fragment datagram
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 128 (0x80)
IP: Protocol = TCP - Transmission Control
IP: Checksum = OxEB86
IP: Source Address = 194.85.135.75
IP: Destination Address = 194.85.135.66
IP: Data: Number of data bytes remaining = 34 (0x0022)

Фрагментація IP-пакетів

Протокол IP дозволяє виконувати фрагментацію пакетів, що надходять на вхідні

порти маршрутизаторів.
Доцільно розрізняти фрагментацію повідомлень у вузлі-відправнику й динамічну
фрагментацію повідомлень у транзитних вузлах мережі – маршрутизаторах. Практично у
всіх стеках протоколів є протоколи, які відповідають за фрагментацію повідомлень
прикладного рівня на такі частини, які укладаються в кадри канального рівня. У стеці TCP/IP
це завдання вирішує протокол TCP, що розбиває потік байтів, переданий йому з прикладного
рівня на повідомлення потрібного розміру (наприклад, на 1460 байтів для протоколу
Ethernet). Тому протокол IP у вузлі-відправнику не використовує свої можливості по
фрагментації пакетів.
А от за необхідності передати пакет у наступну мережу, для якої розмір пакета є
занадто великим, IP-фрагментація стає необхідною. У функції рівня IP входить розбивка
занадто довгого для конкретного типу складової мережі повідомлення на коротші пакети зі
створенням відповідних службових полів, потрібних для наступного складання фрагментів у
вихідне повідомлення.
У більшості типів локальних і глобальних мереж значення MTU, тобто максимальний
розмір поля даних, у яке повинен інкапсулювати свій пакет протокол IP, значно різняться.
Мережі Ethernet мають значення MTU, що дорівнює 1500 байтів, мережі FDDI – 4096 байтів,
а мережі Х.25 найчастіше працюють із MTU в 128 байтів.
IP-пакет може бути позначений як такий, що не фрагментується. Будь-який пакет,
позначений таким чином, модуль IP не може фрагментувати ні за яких умов. Якщо ж пакет,
позначений як не фрагментований, не може досягти одержувача без фрагментації, то цей
пакет просто знищується, а вузлу-відправникові надсилається відповідне ICMP-
повідомлення.
Протокол IP допускає можливість використання в межах окремої підмережі її власних
засобів фрагментування, невидимих для протоколу IP. Наприклад, технологія ATM ділить
вхідні IP-пакети на комірки з полем даних в 48 байтів за допомогою свого рівня
сегментування, а потім збирає комірки у вихідні пакети на виході з мережі. Але такі
технології, як ATM, є скоріше винятком, ніж правилом.
Процедури фрагментації та складання протоколу IP розраховані на те, щоб пакет
можна було б розбити на практично будь-яку кількість частин, які згодом можна було би
знову зібрати. Одержувач фрагмента використовує поле ідентифікації для того, щоб не
переплутати фрагменти різних пакетів. Модуль IP, що відправляє пакет, встановлює в поле
ідентифікації значення, яке повинне бути унікальним для даної пари відправник –
одержувач, а також час, протягом якого пакет може бути активним у мережі.
Поле зсуву фрагмента повідомляє одержувачеві положення фрагмента у вихідному
пакеті. Зсув фрагмента й довжина визначають частину вихідного пакета, принесену цим
фрагментом. Прапор «more fragments» показує появу останнього фрагмента. Модуль
протоколу IP, що відправляє нерозбитий на фрагменти пакет, встановлює в нуль прапор
«more fragments» і зсув у фрагменті.
Ці поля дають достатню кількість інформації для збирання пакета.
Щоб розділити на фрагменти великий пакет, модуль протоколу IP, встановлений,
наприклад, на маршрутизаторі, створює кілька нових пакетів і копіює вміст полів IP-
заголовка з великого пакета в IP-заголовки всіх нових пакетів. Дані зі старого пакета діляться
на відповідне число частин, розмір кожної з яких, крім останньої, обов'язково повинен бути
кратним 8 байтам. Розмір останньої частини даних дорівнює отриманому залишку.
Кожна з отриманих частин даних поміщається в новий пакет. Коли відбувається
фрагментація, то деякі параметри IP-заголовка копіюються в заголовки всіх фрагментів, а
інші залишаються лише в заголовку першого фрагмента. Процес фрагментації може змінити
значення даних, розташованих у полі параметрів, і значення контрольної суми заголовка,
змінити значення прапора «mоrе fragments» і зсув фрагмента, змінити довжину IP-заголовка
й загальну довжину пакета. У заголовок кожного пакета заносяться відповідні значення в
поле зсуву «fragment offset», а в поле загальної довжини пакета міститься довжина кожного
пакета. Перший фрагмент буде мати в полі «fragment offset» нульове значення. У всіх
пакетах, крім останнього, прапор «more fragments» встановлюється в одиницю, а в
останньому фрагменті – у нуль.
Щоб зібрати фрагменти пакета, модуль протоколу IP (наприклад, модуль на хост-
комп'ютері) поєднує IP-пакети, що мають однакові значення в полях ідентифікатора,
відправника, одержувача й протоколу. Таким чином, відправник повинен вибрати
ідентифікатор таким чином, щоб він був унікальний для даної пари відправник-одержувач,
для даного протоколу й протягом того часу, поки даний пакет (або будь-який його фрагмент)
може існувати в складеній IP-мережі.
Очевидно, що модуль протоколу IP, що відправляє пакети, повинен мати таблицю
ідентифікаторів, де кожна запис співвідноситься з кожним окремим одержувачем, з яким
здійснювався зв'язок, і вказує останнє значення максимального часу життя пакета в IP-
мережі. Однак, оскільки поле ідентифікатора допускає 65536 різних значень, деякі хости
можуть використовувати просто унікальні ідентифікатори, що не залежать від адреси
одержувача.
У деяких випадках доцільно, щоб ідентифікатори IP-пакетів вибиралися протоколами
більш високого, ніж IP, рівня. Наприклад, у протоколі TCP передбачена повторна передача
TCP-сегментів, що з якихось причин не дійшли до адресата. Імовірність правильного
прийому збільшувалася б, якби при повторній передачі ідентифікатор для IP-пакета був би
тим же, що й у вихідному IP-пакеті, оскільки його фрагменти могли б використатися для
складання правильного ТCP-сегмента.
Процедура об'єднання полягає в поміщенні даних з кожного фрагмента в позицію,
зазначену в заголовку пакета в поле «fragment offset».
Кожен модуль IP має бути здатним передати пакет з 68 байтів без подальшої
фрагментації. Це пов'язане з тим, що IP-заголовок може включати до 60 байтів, а
мінімальний фрагмент даних – 8 байтів. Кожен одержувач повинен могти прийняти пакет з
576 байт як єдиний шматок або у вигляді фрагментів, що підлягають збиранню.
Якщо біт прапора заборони фрагментації (Don't Fragment, DF) встановлений, то
фрагментацію цього пакета заборонено, навіть якщо в цьому випадку він буде загублений.
Даний засіб може використовуватися для запобігання фрагментації в тих випадках, коли
хост-отримувач не має достатніх ресурсів для складання фрагментів.
Роботу протоколу IP щодо фрагментації пакетів у хостах і маршрутизаторах
проілюстровано на рисунку нижче.
Нехай комп'ютер 1 пов'язаний з мережею, що має значення MTU 4096 байтів,
наприклад з мережею FDDI. При надходженні на IP-рівень комп'ютера 1 повідомлення від
транспортного рівня розміром в 5600 байтів протокол IP ділить його на два IP-пакети,
встановлюючи в першому пакеті ознаку фрагментації із присвоєнням пакету унікального
ідентифікатора, наприклад 486. У першому пакеті розмір поля зсуву дорівнює 0, а в другому
– 2800. Ознака фрагментації в другому пакеті дорівнює нулю, що показує, що це останній
фрагмент пакета. Загальна величина IP-пакета становить 2800 плюс 20 (розмір IP-заголовка),
тобто 2820 байт, що вміщається в поле даних кадру FDDI. Далі модуль IP комп'ютера 1
передає ці пакети своєму мережевому інтерфейсу (утвореному протоколами канального
рівня К1 і фізичного рівня Ф1). Мережевий інтерфейс відправляє кадри наступному
маршрутизатору.

Фрагментація IP-пакетів при передачі між мережами з різним максимальним розміром

пакетів: К1 і Ф1 — канальний і фізичний рівень мережі 1; К2 і Ф2 — канальний і фізичний
рівень мережі 2

Після того, як кадри пройдуть рівень мережевого інтерфейсу маршрутизатора (К1 і

Ф1) і звільняться від заголовків FDDI, модуль IP за мережевою адресою визначає, що два
прибулі пакети потрібно передати в мережу 2, що є мережею Ethernet і має значення MTU,
яка дорівнює 1500. Отже, IP-пакети, що прибули, необхідно фрагментувати. Маршрутизатор
витягає поле даних з кожного пакета й ділить його ще навпіл, щоб кожна частина вмістилася
в поле даних кадру Ethernet. Потім він формує нові IP-пакети, кожний з яких має довжину
1400 + 20 = 1420 байт, що є меншим від 1500 байтів, тому вони нормально поміщаються в
поле даних кадрів Ethernet.
У результаті в комп'ютер 2 по мережі Ethernet приходять чотири IP-пакети із
загальним ідентифікатором 486, що дозволяє протоколу IP, який працює в комп'ютері 2,
правильно зібрати вхідне повідомлення. Якщо пакети прийшли не в тому порядку, у якому
були послані, то зсув покаже правильний порядок їхнього об'єднання.
Відзначимо, що IP-маршрутизатори не збирають фрагменти пакетів у великі пакети,
навіть якщо на шляху трапляється мережа, що допускає таке укрупнення. Це пов'язано з тим,
що окремі фрагменти повідомлення можуть переміщатися по інтермережі різними
маршрутами, а тому немає гарантії, що всі фрагменти проходять через який-небудь
проміжний маршрутизатор на їхньому шляху.
Після надходження першого фрагмента пакета вузол призначення запускає таймер,
що визначає максимально припустимий час очікування приходу інших фрагментів цього
пакета. Таймер встановлюється на максимальне із двох значень: початковий встановлений
час очікування і час життя, зазначені в прийнятому фрагменті. Таким чином, первісна
установка таймера є нижньою межею для часу очікування під час збирання. Якщо таймер
минає раніше прибуття останнього фрагмента, то всі ресурси збирання, пов'язані з даним
пакетом, звільняються, всі отримані до цього моменту фрагменти пакета відкидаються, а у
вузол, що послав вихідний пакет, направляється повідомлення про помилку за допомогою
протоколу ICMP.
Протокол обміну керуючими повідомленнями ICMP
Загальна характеристика протоколу ICMP

Протокол обміну керуючими повідомленнями ICMP (Internet Control Message

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

Формат повідомлень протоколу ICMP

Існує кілька типів повідомлень ICMP. Кожен тип повідомлення має свій формат, при
цьому всі вони починаються з загальних трьох полів: 8-бітного цілого числа, що позначає
тип повідомлення (TYPE), 8-бітного поля коду (CODE), який конкретизує призначення
повідомлення, і 16-бітного поля контрольної суми (CHECKSUM). Крім того, повідомлення
ICMP завжди містить заголовок і перші 64 біти даних пакета IP, який викликав помилку. Це
робиться для того, щоб вузол-відправник зміг точніше проаналізувати причину помилки,
оскільки всі протоколи прикладного рівня стеку TCP/IP містять найбільш важливу
інформацію для аналізу в перших 64 бітах своїх повідомлень.
Поле типу може мати наступні значення:

Значення Тип повідомлення

0 Ехо-відповідь (Echo Replay)
3 Вузол призначення недосяжний (Destination Unreachable)
4 Погашення джерела (Source Quench)
5 Перенаправлення маршруту (Redirect)
8 Ехо-запит (Echo Request)
11 Спливання часу дейтаграми (Time Exceeded for a Datagram)
12 Проблема з параметром пакета (Parameter Problem on a Datagram)
13 Запит відмітки часу (Timestamp Request)
14 Відповідь відмітки часу (Timestamp Replay)
17 Запит маски (Address Mask Request)
18 Відповідь маски (Address Mask Replay)

Як видно з використовуваних типів повідомлень, протокол ICMP є певним

об'єднанням протоколів, які вирішують свої вузькі завдання.
Ехо-протокол

Протокол ICMP надає мережевим адміністраторам засоби для тестування досяжності

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

Повідомлення про недосяжність вузла призначення

Коли маршрутизатор не може передати або доставити IP-пакет, він відсилає вузлу,
який відправив цей пакет, повідомлення "Вузол призначення недосяжний" (тип
повідомлення – 3). Це повідомлення містить в полі коду значення, що уточнює причину, з
якої пакет не було доставлено. Причина кодується таким чином:

Код Причина
0 Мережа недосяжна
1 Вузол недосяжний
2 Протокол недосяжний
3 Порт недосяжний
4 Потрібна фрагментація, а встановлено біт DF
5 Помилка в маршруті, який задало джерело
6 Мережа призначення невідома
7 Вузол призначення невідомий
8 Вузол-джерело ізольований
9 Взаємодію з мережею призначення адміністративно заборонено
10 Взаємодію з вузлом призначення адміністративно заборонено
11 Мережа недосяжна для заданого класу сервісу
12 Вузол недосяжний для заданого класу сервісу

Маршрутизатор, який виявив з якої-небудь причини, що він не може передати IP-

пакет далі по мережі, повинен відправити ICMP-повідомлення вузлу-джерелу, і тільки потім
відкинути пакет. Крім причини помилки, ICMP-повідомлення включає також заголовок
недоставленого пакета і його перші 64 біти поля даних.
Вузол або мережа призначення можуть бути недосяжні через тимчасову
непрацездатність апаратури, через те, що відправник вказав неправильну адресу
призначення, а також через те, що маршрутизатор не має даних про маршрут до мережі
призначення.
Недосяжність протоколу і порту означають відсутність реалізації будь-якого
протоколу прикладного рівня в вузлі призначення або ж відсутність відкритого порту
протоколів UDP або TCP в вузлі призначення.
 Помилка фрагментації виникає тоді, коли відправник послав у мережу пакет з
ознакою DF, що забороняє фрагментацію, а маршрутизатор зіткнувся з необхідністю
передачі цього пакета в мережу зі значенням MTU меншим, ніж розмір пакету.

Перенаправлення маршруту

Маршрутні таблиці у комп'ютерів зазвичай є статичними, бо конфігурують їх

адміністратори мереж, а у маршрутизаторів – динамічними, які формувались автоматично за
допомогою протоколів обміну маршрутної інформації. Тому з плином часу після змін
топології мережі маршрутні таблиці комп'ютерів можуть застарівати. Крім того, ці таблиці
зазвичай містять мінімум інформації, наприклад, тільки адреси кількох маршрутизаторів.
Для коригування поведінки комп'ютерів маршрутизатор може використовувати
повідомлення протоколу ICMP, яке називають "Перенаправлення маршруту" (Redirect).
Це повідомлення надсилається в тому випадку, коли маршрутизатор бачить, що
комп'ютер відправляє пакет деякої мережі призначення нераціональним чином, тобто не
тому маршрутизаторові локальної мережі, від якого починається коротший маршрут до
мережі призначення.
Механізм перенаправлення протоколу ICMP дозволяє комп'ютерам мати в
конфігураційному файлі тільки IP-адреси його локальних маршрутизаторів. За допомогою
повідомлень про перенаправлення маршрутизатори будуть повідомляти комп'ютерові всю
необхідну йому інформацію про те, через який маршрутизатор слід відправляти пакети для
тієї чи іншої мережі призначення. Тобто маршрутизатори передадуть комп'ютеру потрібну
йому частину їх таблиць маршрутизації.
У повідомленні "Перенаправлення маршруту" маршрутизатор поміщає IP-адресу
маршрутизатора, яким потрібно користуватися в подальшому, і заголовок вихідного пакета з
першими 64 бітами його поля даних. З заголовка пакета вузол дізнається, для якої мережі
необхідно користуватися зазначеним маршрутизатором.