Одержавши адресу мережевого адаптера, ARP зберігає його разом з відповідною IP-адресою в своєму кеші. Протокол ARP перед формуванням широкомовного ARP-запиту завжди шукає в кеші адресу IP і мережевого адаптера. Протокол ARP описаний в RFC 826.

Для зменшення числа широкомовних пакетів ARP кешируєт адреси для подальшого використовування. Застосовується два типи записів в кеші ARP - динамічні (додаються і віддаляються автоматично) і статичні (знаходяться в кеші до перезавантаження комп'ютера).

На додаток до цього в кеші протоколу ARP завжди присутня адреса для широкомовлення в локальній підмережі (FFFFFFFFFFFF) у вигляді статичного запису, який не відображається при прогляданні кеша.

За умовчанням для кеша протоколу ARP встановлені тайм-аути, рівні 2 хвилинам для незатребуваних записів і 10 хвилинам для записів, до яких зверталися. Якщо в реєстр додати параметр ARPCacheLife і задати тайм-аут в секундах, саме ця величина використовуватиметься замість згаданих.Примітка В деяких реалізаціях TCP/IP при повторному використовуванні запису їй привласнюється нова відмітка про час надходження, яка додає додаткові 10 хвилин до часу її життя.

Протоколи ICMP і IGMP

Тоді як протокол IP використовується для маршрутизації в об'єднаних мережах, протокол ICMP (Internet Control Message Protocol) оповіщає про помилки і управляє повідомленнями для протоколу IP, який інформує маршрутизатори про існування в мережі вузлів, що належать якійсь групі, за допомогою IGMP (Internet Group Management Protocol). Інформація протоколу IGMP проходить через інші маршрутизатори таким чином, що кожен підтримуючий групову адресацію маршрутизатор знає, яка група вузлів в якій мережі знаходиться. Пакети IGMP передаються датаграммами протоколу IP і тому ненадійні.

Протокол IP

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

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

Поля IP-датаграмми наведені нижче додаються в заголовок пакету при його отриманні з транспортного рівня.

Source IP-address (IP-адреса відправника) – ідентифікує відправника датаграмми за допомогою IP-адреси.

Destination IP-address (IP-адреса одержувача) – ідентифікує одержувача датаграмми за допомогою IP-адреси.

Protocol (протокол) – інформує протокол IP вузла-одержувача про те, якому протоколу верхнього рівня TCP або UDP - його слід передати.

Checksum (контрольна сума) – легко обчислюване значення для перевірки цілісності пакету, що прийшов.

Time to live, або TTL (час життя) – визначає скільки секунд знаходиться датаграмма в мережі, перш ніж вона буде знехтувана (discarded). Запобігає нескінченному блуканню пакетів по мережі. Маршрутизатори повинні зменшувати TTL на кількість секунд, проведених датаграммой в маршрутизаторі. TTL зменшується щонайменше на одну секунду кожного разу, коли датаграмма проходить через маршрутизатор. За умовчанням в Windows NT 4.0 TTL рівно 128 секундам.

Маршрутизатор обробляє одержані ним IP-пакети наступним чином.

Flag (Прапор), вказуючий, що існують і інші фрагменти, які будуть відправлені услід;

Fragment ID (Ідентифікатор фрагмента), ідентифікуючий всі фрагменти, що становлять один пакет;

Fragment Offset (Зсув фрагмента), забезпечуючий правильну збірку пакету на вузлі-одержувачі.

На наступному вузлі пакет потрапляє по стеку протоколів до TCP або UDP. Цей процес повторюється на кожному маршрутизаторі до тих пір, поки пакет не дійде до адресата; там протокол IP збирає з фрагментів пакет в первинному вигляді.

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

Поля заголовка IP-пакету (для IP версії 4) приведені в таблиці.

Version (версія) – 4 біти використовуються для відображення версії протоколу IP. Поточна версія - четверта. Наступної буде шості (див. розділ 4).

Header Length (довжина заголовка) – 4 біти використовуються для відображення кількості 32-бітових слів в заголовку IP-пакету. Мінімальний розмір заголовка - 20 байт, отже, довжина мінімального заголовка - 0x5. Опції IP можуть збільшити мінімальний розмір заголовка на 4 байти. Якщо опція не використовує їх все, то біти, що залишилися, заповнюються нулями, тому довжина заголовка завжди кратна 4 байтам.

Type of Service (тип обслуговування) – 8 біт використовуються для позначення якості обслуговування, що вимагається для цієї датаграмми, при доставці через маршрутизатори об'єднаної IP-мережі. У них є біти, виділені для пріоритету, затримки, пропускної спроможності і характеристик надійності.

Total Length (загальна довжина) – 16 біт використовуються для відображення загальної довжини датаграмми протоколу IP (заголовок IP-пакету + його зміст). Сюди не включений заголовок мережевого кадру.

Identification (ідентифікація) – 16 біт використовуються як ідентифікатор даного IP-пакету. Якщо IP-пакет фрагментований, то всі фрагменти мають однакові ідентифікатори, використовувані при збірці вузлом-одержувачем.

Fragmentation Flags (прапори фрагментацій) – 3 біти зарезервовані для прапорів фрагментації; проте тільки 2 біти визначені для поточного використовування. Один прапор служить для позначення фрагментованого пакету, інший - для ідентифікації останнього фрагмента.

Fragment Offset (зсув фрагмента) – 13 біт використовуються як лічильник зсуву для вказівки положення фрагментів щодо початку поля даних IP-пакету.