Пакет протоколу IP має заголовок довжиною до 20 байт та поле даних. Структура заголовка IP-пакету наведено на рис. 5.1. У полі Версія <>довжиною 4 біта вказана версія протоколу IP. У полі Довжина заголовка <>в 4 біта вказується довжина заголовка в 32-бітних словах [3] . Звичайна довжина заголовка - 20 байт (тобто п'ять 32-бітових слів), але в заголовок може бути включена додаткова інформація, розташована в полі Опції. Мал. 5.1. Формат заголовка пакету IPv4 Таким чином, максимальна довжина заголовка може становити 60 байт (тобто 15 32-бітових слів) [4] . У полі Тип обслуговування (Type of Service, TOS) У 8 біт є кілька ноднолів (рис. 5.2). У підполі пріоритет (Precedence), Довжина якого 3 біта, вказується значення пріоритету переданих даних від найнижчого - 0 (звичайний пакет) до найвищого - 7 (пакет з керуючою інформацією). У першу чергу обробляються пакети більш високого пріоритету. Мал. 5.2. Поле Тип обслуговування заголовка IP Після поля пріоритету пакета йдуть чотири біти, які задають тип обслуговування. Тільки один із чотирьох біт може мати значення 1.Перший із цих чотирьох біт вказує, що має бути мала затримка (LowУ Delay, D) під час передачі, другий - висока пропускна здатність (High Throughput, Г), третій - висока надійність (High Reliability, R), У четвертий - низька вартість (Low Cost, З). Останній біт підполя був доданий вже після появи RFC 791 [2] . Сенс значень типу обслуговування абстрактний [6] . Останній біт поля не використовується. У полі Загальна довжина (Total Length) в 16 біт задається загальний розмір пакета в байтах, при цьому враховується довжина заголовка і поля даних. Найбільше значення довжини пакета обмежено розрядністю цього поля і не може перевищувати 65 535 байт, але зазвичай такі великі пакети не пересилаються.

У полі Ідентифікатор пакету), довжина якого 16 біт, вказується номер кожного пакета IP, що пересилається. Цей номер збільшується щоразу на 1 при черговій посилці пакета, за винятком пересилки фрагментованих IP-накетів, в яких значення в даному полі однакове для всіх фрагментів. Для ідентифікації фрагментів використовуються поля Прапори і Зміщення фрагмента. Поле Прапори (Flags) у 3 біти (рис. 5.3) сегмент Чи не фрагментувати (Do not Fragment, DF) забороняє маршрутизатору розбивати пакет на частини, а біт Є ще фрагменти (More Fragments, MF) показує, що пакет не останній серед фрагментів. Перший біт зарезервований. Мал. 53. Поле Прапори заголовка IP У полі Зміщення фрагмента (Fragment Offset) довжиною 13 біт задається, на скільки байт поле даних зміщене від початку вихідного пакету, що фрагментується. Зміщення має бути кратним 8 байтам. У полі Час життя (Time to Live, TTL) (Довжина 8 біт) заданий максимальний термін знаходження пакета в мережі.Зменшення значення цього поля відбувається кожну секунду, або при проходженні пакета через проміжний маршрутизатор. При досягненні значення цього поля 0 відбувається відкидання цього пакета маршрутизатором, а джерелу пакета відправляється повідомлення про закінчення його часу життя у вигляді пакета ICMP, основне призначення якого - запобігти зациклювання маршруту пакета між маршрутизаторами. Пакет ICMP також надсилається джерелу даних у разі, коли на вузлі-одержувачі прийнята лише частина фрагментів пакета IP, але час У житті минув. У цьому випадку відправлення повідомлення, що повідомляє, відбувається в період очікування початку складання пакета на вузлі-одержувачі. Поле Протокол верхнього рівня (Protocol) 8 біт містить ідентифікатор протоколу верхнього рівня, якому належить інформація, що міститься в полі даних пакета. Значення ідентифікаторів для різних протоколів наведені в RFC Assigned Numbers (табл. 5.1). Таблиця 5.1 Ідентифікатори найпоширеніших протоколів