IPv4

Интернет-протокол версии 4

Стек протоколов
IPv4-пакет
Аббревиатура	IPv4
Цель	Межсетевой протокол
Разработчик(и)	ДАРПА
Введение	1981 год ( 1981 )
Под влиянием	IPv6
Уровень OSI	Сетевой уровень
RFC(ы)	791

Интернет-протокол версии 4 ( IPv4 ) — это первая версия Интернет-протокола (IP) как отдельная спецификация. Это один из основных протоколов основанных на стандартах методов межсетевого взаимодействия в Интернете и других сетях с коммутацией пакетов . IPv4 был первой версией, развернутой для производства в SATNET в 1982 году и в ARPANET в январе 1983 года. Он до сих пор используется для маршрутизации большей части интернет-трафика . даже при продолжающемся развертывании Интернет-протокола версии 6 (IPv6), его преемник.

IPv4 использует 32-битное адресное пространство, которое обеспечивает 4 294 967 296 (2 ³² ) уникальные адреса, но большие блоки зарезервированы для специальных сетевых целей.

История

Более ранние версии TCP/IP представляли собой объединенную спецификацию TCP/IPv3. С появлением IPv4 Интернет-протокол стал отдельной спецификацией.

Интернет-протокол версии 4 описан в публикации IETF RFC 791 (сентябрь 1981 г.), заменяющей более раннее определение от января 1980 г. (RFC 760). В марте 1982 года Министерство обороны США приняло решение о выборе пакета интернет-протоколов (TCP/IP) в качестве стандарта для всех военных компьютерных сетей .

Цель

Интернет-протокол — это протокол, который определяет и обеспечивает межсетевое взаимодействие на интернет-уровне набора интернет-протоколов. По сути, это формирует Интернет. Он использует систему логической адресации и выполняет маршрутизацию , то есть пересылку пакетов от хоста-источника к следующему маршрутизатору, который находится на один шаг ближе к предполагаемому хосту назначения в другой сети.

IPv4 — это протокол без установления соединения , который работает по модели доставки с максимальными усилиями , поскольку он не гарантирует доставку, а также не обеспечивает правильную последовательность или предотвращение дублирования доставки. Эти аспекты, включая целостность данных, решаются транспортным протоколом верхнего уровня , таким как протокол управления передачей (TCP).

Адресация

Для более широкого освещения этой темы см. IP-адрес .

Разложение представления адреса IPv4, разделенного четырьмя точками, на его двоичное значение.

IPv4 использует 32-битные адреса, что ограничивает адресное пространство до 4 294 967 296 (2 ³² ) адреса.

IPv4 резервирует специальные блоки адресов для частных сетей (2 ²⁴  + 2 ²⁰  + 2 ¹⁶ ≈ 18 миллионов адресов) и многоадресных адресов (2 ²⁸ ≈ 268 млн адресов).

Адресные представления

Адреса IPv4 могут быть представлены в любой записи, выражающей 32-битное целое значение. Чаще всего они записываются в десятично-точечной системе счисления , которая состоит из четырех октетов адреса, выраженных индивидуально десятичными числами и разделенных точками .

Например, IP-адрес, разделенный четырьмя точками на рисунке ( 172.16.254.1 ), представляет собой 32-битное десятичное число 2886794753, которое в шестнадцатеричном формате равно 0xAC10FE01.

Нотация CIDR объединяет адрес с его префиксом маршрутизации в компактном формате, в котором за адресом следует косая черта (/) и количество ведущих последовательных битов 1 в префиксе маршрутизации (маске подсети).

Другие представления адресов широко использовались, когда классовая сеть практиковалась . Например, обратной связи адрес 127.0.0.1 обычно записывался как 127.1 , учитывая, что он принадлежит сети класса A с восемью битами для маски сети и 24 битами для номера хоста. Когда в адресе было указано менее четырех чисел в точечной записи, последнее значение рассматривалось как целое число из такого количества байт, которое требуется для заполнения адреса до четырех октетов. Таким образом, адрес 127.65530 эквивалентен 127.0.255.250 .

Распределение

В исходной версии IPv4 IP-адрес был разделен на две части: идентификатор сети представлял собой самый старший октет адреса, а идентификатор хоста — остальную часть адреса. Последнее еще называли полем отдыха . Эта структура позволяла использовать максимум 256 сетевых идентификаторов, что было быстро признано недостаточным.

Чтобы преодолеть это ограничение, в 1981 году был переопределен старший октет адреса для создания сетевых классов в системе, которая позже стала известна как классовая сеть. Пересмотренная система определила пять классов. Классы A, B и C имели разную длину бит для идентификации сети. Остальная часть адреса, как и раньше, использовалась для идентификации хоста в сети. Из-за разных размеров полей в разных классах каждый класс сети имел разную способность адресации хостов. В дополнение к трем классам адресации хостов класс D был определен для многоадресной адресации, а класс E был зарезервирован для будущих приложений.

Разделение существующих классовых сетей на подсети началось в 1985 году с публикации РФК   950 . Это разделение стало более гибким с введением масок подсети переменной длины (VLSM). RFC   1109 в 1987 году. В 1993 году на основе этой работы RFC   1517 представил бесклассовую междоменную маршрутизацию (CIDR), который выражал количество битов (начиная с самого старшего ), как, например, /24 , а схема на основе классов была названа классовой , напротив, . CIDR был разработан, чтобы разрешить перераспределение любого адресного пространства, чтобы пользователям можно было выделять меньшие или большие блоки адресов. Иерархическая структура, созданная CIDR, управляется Управлением по присвоению номеров Интернета (IANA) и региональными реестрами Интернета (RIR). Каждый RIR поддерживает общедоступную базу данных WHOIS , которая предоставляет информацию о присвоении IP-адресов.

Адреса специального назначения

Инженерная группа Интернета (IETF) и IANA запретили общее использование различных зарезервированных IP-адресов для специальных целей. В частности, эти адреса используются для многоадресного трафика и для предоставления адресного пространства для неограниченного использования в частных сетях.

Специальные адресные блоки

Адресный блок	Диапазон адресов	Количество адресов	Объем	Описание
0.0.0.0/8	0.0.0.0–0.255.255.255	16 777 216	Программное обеспечение	Текущая (локальная, «эта») сеть
10.0.0.0/8	10.0.0.0–10.255.255.255	16 777 216	Частная сеть	Используется для локальной связи внутри частной сети.
100.64.0.0/10	100.64.0.0–100.127.255.255	4 194 304	Частная сеть	Общее адресное пространство для связи между поставщиком услуг и его абонентами при использовании NAT операторского уровня
127.0.0.0/8	127.0.0.0–127.255.255.255	16 777 216	Хозяин	Используется для адресов обратной связи с локальным хостом.
169.254.0.0/16	169.254.0.0–169.254.255.255	65 536	Подсеть	Используется для локальных адресов ссылок. между двумя хостами по одному каналу, если IP-адрес не указан иным образом, например, который обычно был бы получен с DHCP- сервера
172.16.0.0/12	172.16.0.0–172.31.255.255	1 048 576	Частная сеть	Используется для локальной связи внутри частной сети.
192.0.0.0/24	192.0.0.0–192.0.0.255	256	Частная сеть	Назначения протоколов IETF, DS-Lite (/29)
192.0.2.0/24	192.0.2.0–192.0.2.255	256	Документация	Присвоено как TEST-NET-1, документация и примеры.
192.88.99.0/24	192.88.99.0–192.88.99.255	256	Интернет	Сдержанный. Ранее использовался для IPv6 на IPv4. ретрансляции (включен IPv6 блок адреса 2002::/16 ).
192.168.0.0/16	192.168.0.0–192.168.255.255	65 536	Частная сеть	Используется для локальной связи внутри частной сети.
198.18.0.0/15	198.18.0.0–198.19.255.255	131 072	Частная сеть	Используется для эталонного тестирования межсетевой связи между двумя отдельными подсетями.
198.51.100.0/24	198.51.100.0–198.51.100.255	256	Документация	Присвоено как TEST-NET-2, документация и примеры.
203.0.113.0/24	203.0.113.0–203.0.113.255	256	Документация	Присвоено как TEST-NET-3, документация и примеры.
224.0.0.0/4	224.0.0.0–239.255.255.255	268 435 456	Интернет	Используется для многоадресной рассылки (бывшая сеть класса D)
233.252.0.0/24	233.252.0.0–233.252.0.255	256	Документация	Назначено как MCAST-TEST-NET, документация и примеры (Обратите внимание, что это часть вышеуказанного пространства многоадресной рассылки.)
240.0.0.0/4	240.0.0.0–255.255.255.254	268 435 455	Интернет	Зарезервировано для будущего использования (бывшая сеть класса E)
255.255.255.255/32	255.255.255.255	1	Подсеть	Зарезервировано для адреса назначения «ограниченной трансляции ».

Частные сети

Из примерно четырех миллиардов адресов, определенных в IPv4, около 18 миллионов адресов в трех диапазонах зарезервированы для использования в частных сетях. Адреса пакетов в этих диапазонах не маршрутизируются в общедоступном Интернете; они игнорируются всеми общедоступными маршрутизаторами. Таким образом, частные хосты не могут напрямую взаимодействовать с общедоступными сетями, но для этой цели требуется преобразование сетевых адресов на шлюзе маршрутизации.

Зарезервированные диапазоны частных сетей IPv4

Имя	CIDR- блок	Диапазон адресов	Количество адреса	Классное описание
24-битный блок	10.0.0.0/8	10.0.0.0 – 10.255.255.255	16 777 216	Одноместный класс А
20-битный блок	172.16.0.0/12	172.16.0.0 – 172.31.255.255	1 048 576	Непрерывный диапазон из 16 блоков класса B
16-битный блок	192.168.0.0/16	192.168.0.0 – 192.168.255.255	65 536	Непрерывный диапазон из 256 блоков класса C

Поскольку две частные сети, например два филиала, не могут напрямую взаимодействовать через общедоступный Интернет, эти две сети должны быть соединены через Интернет через виртуальную частную сеть (VPN) или IP-туннель , который инкапсулирует пакеты, включая их заголовки, содержащие частные адреса на уровне протокола во время передачи по общедоступной сети. Кроме того, инкапсулированные пакеты могут быть зашифрованы для передачи по общедоступным сетям для защиты данных.

Локальная адресация канала

RFC 3927 определяет специальный блок адреса 169.254.0.0/16 для локальной адресации. Эти адреса действительны только для канала (например, сегмента локальной сети или соединения «точка-точка»), напрямую подключенного к хосту, который их использует. Эти адреса не маршрутизируются. Как и частные адреса, эти адреса не могут быть источником или пунктом назначения пакетов, проходящих через Интернет. Эти адреса в основном используются для автоматической настройки адреса ( Zeroconf ), когда хост не может получить IP-адрес от DHCP-сервера или других методов внутренней настройки.

Когда блок адресов был зарезервирован, стандартов автоконфигурации адресов не существовало. Microsoft создала реализацию под названием «Автоматическая частная IP-адресация» (APIPA), которая была развернута на миллионах компьютеров и стала стандартом де-факто . Много лет спустя, в мае 2005 года, IETF определил формальный стандарт в RFC 3927, озаглавленный « Динамическая конфигурация локальных адресов каналов IPv4» .

петлевая проверка

Основная статья: Локальный хост

Сеть класса A 127.0.0.0 сеть 127.0.0.0/8 ( бесклассовая ) зарезервирована для обратной связи . IP-пакеты, исходные адреса которых принадлежат этой сети, никогда не должны появляться за пределами хоста. Пакеты, полученные на интерфейсе без обратной связи с адресом источника или назначения обратной связи, должны быть отброшены.

Первый и последний адреса подсети

См. также: Справочник по подсетям IPv4.

Первый адрес в подсети используется для идентификации самой подсети. В этом адресе все биты хоста равны 0 . Во избежание двусмысленности представления этот адрес зарезервирован. В последнем адресе все биты хоста установлены в 1 . Он используется как локальный широковещательный адрес для одновременной отправки сообщений всем устройствам в подсети. Для сетей размером / 24 или больше широковещательный адрес всегда заканчивается на 255.

Например, в подсети ( 192.168.5.0 255.255.255.0 маска подсети . ) идентификатор 192.168.5.0/24 используется для обозначения всей подсети Широковещательный адрес сети — 192.168.5.255 .

Тип	Двоичная форма	Десятично-точечное обозначение
Сетевое пространство	11000000.10101000.00000101.00000000	192.168.5.0
Широковещательный адрес	11000000.10101000.00000101.11111111	192.168.5.255
Красным цветом показана хостовая часть IP-адреса; другая часть — это префикс сети. Хост инвертируется (логическое НЕ), но префикс сети остается нетронутым.

Однако это не означает, что каждый адрес, заканчивающийся на 0 или 255, не может использоваться в качестве адреса хоста. Например, в / 16 подсети 192.168.0.0/255.255.0.0 192.168.255.255 192.168.255.255 , что эквивалентно диапазону адресов 192.168.0.0 — , широковещательный адрес — . Для хостов можно использовать следующие адреса, даже если они заканчиваются на 255: 192.168.1.255 , 192.168.2.255 и т. д. Кроме того, 192.168.0.0 является идентификатором сети и не должен назначаться интерфейсу. Адреса 192.168.1.0 , 192.168.2.0 и т. д. могут быть назначены, несмотря на то, что они заканчиваются на 0.

В прошлом конфликт между сетевыми адресами и широковещательными адресами возникал из-за того, что некоторые программы использовали нестандартные широковещательные адреса с нулями вместо единиц.

В сетях меньше / 24 Например, подсеть CIDR имеет 203.0.113.16/28 широковещательные адреса не обязательно заканчиваются на 255. широковещательный адрес 203.0.113.31 .

Тип	Двоичная форма	Десятично-точечное обозначение
Сетевое пространство	11001011.00000000.01110001.00010000	203.0.113.16
Широковещательный адрес	11001011.00000000.01110001.00011111	203.0.113.31
Красным цветом показана хостовая часть IP-адреса; другая часть — это префикс сети. Хост инвертируется (логическое НЕ), но префикс сети остается нетронутым.

В частном случае сеть / 31 рассчитана всего на два хоста. Эти сети обычно используются для соединений «точка-точка». Для этих сетей не существует идентификатора сети или широковещательного адреса.

Разрешение адреса

Основная статья: Система доменных имен

Хосты в Интернете обычно известны по именам, например, www.example.com, а не по IP-адресу, который используется для маршрутизации и идентификации сетевого интерфейса. Использование доменных имен требует их перевода, называемого разрешением , в адреса и наоборот. Это аналогично поиску номера телефона в телефонной книге по имени получателя.

Преобразование между адресами и доменными именами выполняется системой доменных имен (DNS), иерархической распределенной системой именования, которая позволяет делегировать пространства имен другим DNS-серверам.

Ненумерованный интерфейс

Ненумерованный канал «точка-точка » (PtP), также называемый транзитным каналом, — это канал, который не имеет связанного с ним номера IP-сети или подсети, но все же имеет IP-адрес. Впервые представленный в 1993 году, Фил Карн из Qualcomm считается оригинальным дизайнером.

Целью транзитного канала является маршрутизация датаграмм . Они используются для освобождения IP-адресов из ограниченного пространства IP-адресов или для упрощения управления назначением IP и настройкой интерфейсов. Раньше для каждого канала необходимо было выделить подсеть / 31 или / 30, используя 2 или 4 IP-адреса для каждого канала «точка-точка». Если канал не пронумерован, идентификатор маршрутизатора используется — один IP-адрес, заимствованный из определенного (обычно Loopback ) интерфейса. Один и тот же идентификатор маршрутизатора может использоваться на нескольких интерфейсах.

Одним из недостатков ненумерованных интерфейсов является то, что их сложнее проводить удаленное тестирование и управление.

Исчерпание адресного пространства

Основная статья: исчерпание адресов IPv4

График исчерпания IPv4-адресов

В 1980-х годах стало очевидно, что пул доступных адресов IPv4 истощается со скоростью, которая изначально не предполагалась в первоначальном проекте сети. К основным рыночным силам, ускорившим истощение адресов, относилось быстро растущее число пользователей Интернета, которые все чаще использовали мобильные вычислительные устройства, такие как портативные компьютеры , персональные цифровые помощники (КПК) и смартфоны с услугами IP-передачи данных. Кроме того, высокоскоростной доступ в Интернет основывался на постоянно включенных устройствах. Угроза истощения побудила к внедрению ряда лечебных технологий, таких как:

• Бесклассовая междоменная маршрутизация (CIDR) для небольших выделений интернет-провайдеров.
• Ненумерованные интерфейсы устранили необходимость в адресах на транзитных каналах.
• Трансляция сетевых адресов (NAT) устранила необходимость в сквозном принципе .

К середине 1990-х годов NAT широко использовался в системах поставщиков доступа к сети, наряду со строгой политикой распределения ресурсов в зависимости от использования в региональных и местных интернет-регистратурах.

Пул первичных адресов Интернета, поддерживаемый IANA, был исчерпан 3 февраля 2011 года, когда последние пять блоков были выделены пяти RIR . APNIC была первой RIR, исчерпавшей свой региональный пул 15 апреля 2011 года, за исключением небольшого объема адресного пространства, зарезервированного для технологий перехода на IPv6, которое должно быть выделено в соответствии с ограниченной политикой.

Долгосрочным решением проблемы исчерпания адресов стала спецификация в 1998 году новой версии интернет-протокола IPv6 . Он обеспечивает значительно увеличенное адресное пространство, а также позволяет улучшить агрегирование маршрутов в Интернете и предлагает большие выделения подсетей, минимум 2 ⁶⁴ адреса хостов конечным пользователям. Однако IPv4 несовместим напрямую с IPv6, поэтому хосты, поддерживающие только IPv4, не могут напрямую взаимодействовать с хостами, поддерживающими только IPv6. После прекращения эксплуатации экспериментальной сети 6bone , начавшегося в 2004 году, в 2006 году началось постоянное официальное развертывание IPv6. что завершение развертывания IPv6 займет значительное время. Ожидается, поэтому необходимы технологии промежуточного перехода , чтобы позволить хостам участвовать в Интернете, используя обе версии протокола.

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

IP- пакет состоит из раздела заголовка и раздела данных. IP-пакет не имеет контрольной суммы данных или какого-либо другого нижнего колонтитула после раздела данных.Обычно канальный уровень инкапсулирует IP-пакеты в кадры с нижним колонтитулом CRC, который обнаруживает большинство ошибок. Многие протоколы транспортного уровня, передаваемые по IP, также имеют собственную проверку ошибок.

Заголовок

Заголовок пакета IPv4 состоит из 14 полей, из которых 13 являются обязательными. 14-е поле является необязательным и имеет удачное название: options. Поля в заголовке упаковываются первым значащим байтом ( сетевой порядок байтов ), а для диаграммы и обсуждения первыми считаются наиболее значимые биты ( нумерация бит MSB 0 ). Самый старший бит имеет номер 0, поэтому поле версии фактически находится, например, в четырех старших битах первого байта.

Формат заголовка IPv4

Смещения	Октет	0								1								2								3
Октет	Кусочек	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Версия				МГП				ДСКП						ECN		Общая длина
4	32	Идентификация																Флаги			Смещение фрагмента
8	64	Время жить								Протокол								Контрольная сумма заголовка
12	96	Исходный адрес
16	128	Адрес назначения
20	160	Варианты (если МГП > 5)
⋮	⋮
56	448

Версия

Первое поле заголовка в IP- пакете — это четырехбитное поле версии. Для IPv4 это всегда равно 4.

Длина интернет-заголовка (IHL)

Заголовок IPv4 имеет переменный размер из-за необязательного 14-го поля (параметры). Поле IHL содержит размер заголовка IPv4; он имеет 4 бита, которые определяют количество 32-битных слов в заголовке. Минимальное значение для этого поля — 5, что указывает на длину 5 × 32 бит = 160 бит = 20 байт. Для 4-битного поля максимальное значение равно 15; это означает, что максимальный размер заголовка IPv4 составляет 15 × 32 бита = 480 бит = 60 байт.

Кодовая точка дифференцированных услуг ( ДСКП )

определялось как тип услуги Первоначально это поле (ToS), но теперь оно определяет дифференцированные услуги (DiffServ). Потоковая передача данных в реальном времени использует поле DSCP. Примером является передача голоса по IP (VoIP), которая используется для интерактивных голосовых услуг.

Явное уведомление о перегрузке ( ECN )

Это поле позволяет осуществлять сквозное уведомление о перегрузке сети без потери пакетов . ECN — это дополнительная функция, доступная, если ее поддерживают обе конечные точки, и эффективная, если она также поддерживается базовой сетью.

Общая длина

Это 16-битное поле определяет размер всего пакета в байтах, включая заголовок и данные. Минимальный размер — 20 байт (заголовок без данных), максимальный — 65 535 байт. Все хосты должны иметь возможность собирать датаграммы размером до 576 байт, но большинство современных хостов обрабатывают пакеты гораздо большего размера. Каналы могут накладывать дополнительные ограничения на размер пакета, и в этом случае дейтаграммы должны быть фрагментированы . Фрагментация в IPv4 выполняется либо на отправляющем хосте, либо на маршрутизаторах. Обратная сборка выполняется на принимающем хосте.

Идентификация

Это поле является полем идентификации и в основном используется для уникальной идентификации группы фрагментов одной IP-дейтаграммы. В некоторых экспериментальных работах предлагалось использовать поле ID для других целей, например, для добавления информации о отслеживании пакетов, чтобы помочь отслеживать датаграммы с поддельными адресами источника. но любое такое использование теперь запрещено.

Флаги

Далее следует трехбитовое поле, которое используется для управления или идентификации фрагментов. Это (в порядке от наиболее значимого к наименее значимому):

• бит 0: Зарезервировано; должно быть равно нулю.
• бит 1: Не фрагментировать (DF)
• бит 2: Больше фрагментов (MF)

Если флаг DF установлен и для маршрутизации пакета требуется фрагментация, пакет отбрасывается. Это можно использовать при отправке пакетов на хост, у которого нет ресурсов для повторной сборки фрагментов. Его также можно использовать для обнаружения MTU пути либо автоматически с помощью программного обеспечения IP хоста, либо вручную с помощью диагностических инструментов, таких как ping или Traceroute .

Для нефрагментированных пакетов флаг MF сбрасывается. Для фрагментированных пакетов все фрагменты, кроме последнего, имеют установленный флаг MF. Последний фрагмент имеет ненулевое поле смещения фрагмента, что отличает его от нефрагментированного пакета.

Смещение фрагмента

В этом поле указывается смещение конкретного фрагмента относительно начала исходной нефрагментированной IP-дейтаграммы. Значение смещения фрагментации для первого фрагмента всегда равно 0. Поле имеет ширину 13 бит, поэтому смещение может быть от 0 до 8191 (от (2 ⁰ – 1) до (2 ¹³ – 1)). Фрагменты указываются в блоках по 8 байт, поэтому длина фрагмента должна быть кратна 8. Таким образом, 13-битное поле допускает максимальное смещение (2 ¹³ – 1) × 8 = 65 528 байт с учетом длины заголовка (65 528 + 20 = 65 548 байт), поддержка фрагментации пакетов, превышающих максимальную длину IP в 65 535 байт.

Время жить (TTL)

Восьмибитное поле времени жизни ограничивает время жизни дейтаграммы, чтобы предотвратить сбой сети в случае возникновения петли маршрутизации . Оно указывается в секундах, но временные интервалы менее 1 секунды округляются до 1. На практике поле используется как счетчик прыжков — когда дейтаграмма поступает на маршрутизатор , маршрутизатор уменьшает поле TTL на единицу. Когда поле TTL достигает нуля, маршрутизатор отбрасывает пакет и обычно отправляет о превышении времени ICMP . отправителю сообщение

Программа трассировки отправляет сообщения с скорректированными значениями TTL и использует эти сообщения ICMP о превышении времени для идентификации маршрутизаторов, через которые проходят пакеты от источника к месту назначения.

Протокол

Это поле определяет протокол, используемый в части данных IP-дейтаграммы. IANA ведет список номеров IP-протоколов .

Контрольная сумма заголовка

16-битное поле контрольной суммы заголовка IPv4 используется для проверки заголовка на наличие ошибок. Когда пакет поступает на маршрутизатор или в пункт назначения, сетевое устройство вычисляет контрольную сумму заголовка, включая поле контрольной суммы. Ожидается значение 0xFFFF. Если получен другой результат, устройство отбрасывает пакет. Ошибки в части данных пакета обрабатываются отдельно с помощью инкапсулированного протокола. И UDP , и TCP имеют отдельные контрольные суммы, которые применяются к их данным.

Когда пакет поступает на маршрутизатор, маршрутизатор уменьшает поле TTL в заголовке. Следовательно, маршрутизатор должен вычислить новую контрольную сумму заголовка.

Поле контрольной суммы представляет собой 16-битное дополнение суммы всех 16-битных слов в заголовке. Для расчета контрольной суммы значение поля контрольной суммы равно нулю.

Исходный адрес

Это 32-битное поле представляет собой IPv4-адрес отправителя пакета. Его можно изменить при передаче с помощью трансляции сетевых адресов (NAT).

Адрес назначения

Это 32-битное поле представляет собой IPv4-адрес получателя пакета. На это может повлиять NAT.

Параметры

Поле опций используется не часто. Пакеты, содержащие некоторые параметры, могут рассматриваться некоторыми маршрутизаторами как опасные и блокироваться. Значение в поле IHL должно включать достаточное количество дополнительных 32-битных слов для хранения всех опций и любого заполнения, необходимого для обеспечения того, чтобы заголовок содержал целое число 32-битных слов. Если IHL больше 5 (т.е. от 6 до 15), это означает, что поле опций присутствует и его необходимо учитывать. Список опций может завершаться опцией EOOL (конец списка опций, 0x00); это необходимо только в том случае, если конец опций иначе не совпадал бы с концом заголовка.

Поскольку большинство параметров IP включают спецификации о том, сколько или какие промежуточные устройства должен пройти пакет, параметры IP не используются для связи через Интернет, и пакеты IP, включая некоторые параметры IP, должны быть отброшены в соответствии с оценкой безопасности IPv4. RFC   6274 , поскольку они могут раскрывать топологию сети или сведения о сети.

Возможные варианты, которые можно поместить в шапку, следующие:

Поле	Размер (бит)	Описание
Скопировано	1	Установите значение 1, если параметры необходимо скопировать во все фрагменты фрагментированного пакета.
Класс опции	2	Общая категория опций. 0 — для опций управления , а 2 — для отладки и измерения . 1 и 3 зарезервированы.
Номер опции	5	Указывает параметр.
Длина опции	8	Указывает размер всей опции (включая это поле). Это поле может отсутствовать для простых опций.
Данные опции	Переменная	Данные, специфичные для опции. Это поле может отсутствовать для простых опций.

В таблице ниже показаны определенные параметры для IPv4. Столбец «Тип опции» формируется из битов «Скопировано», «Класс опции» и «Номер опции», как определено выше.

Тип опции (десятичный/шестнадцатеричный)	Название опции	Описание
0/0x00	ЕОЛ	Конец списка опций
1/0x01	НЕТ	Нет операции
2/0x02	SEC	Безопасность (несуществующая)
7/0x07	RR	Запись маршрута
10/0x0А	ЗСУ	Экспериментальное измерение
11/0x0B	МТУП	MAN Зонд
12/0x0C	МТУР	MAN Ответить
15/0x0F	КОДИРОВАТЬ	КОДИРОВАТЬ
25/0x19	КО	Быстрый старт
30/0x1E	Опыт	Эксперимент в стиле RFC3692
68/0x44	ТС	Временная отметка
82/0x52	ТР	Трассировка
94/0x5E	Опыт	Эксперимент в стиле RFC3692
130/0x82	SEC	Безопасность (РИПСО)
131/0x83	ЛСР	Свободный исходный маршрут
133/0x85	Э-СЕК	Расширенная безопасность (RIPSO)
134/0x86	СИПСО	Вариант коммерческой IP-безопасности
136/0x88	SID	Идентификатор потока
137/0x89	ССР	Строгий исходный маршрут
142/0x8E	ВИЗА	Экспериментальный контроль доступа
144/0x90	ИМИТД	Дескриптор трафика IMI
145/0x91	ЭИП	Расширенный интернет-протокол
147/0x93	ДОБАВИТЬ	Расширение адреса
148/0x94	РТРАЛТ	Оповещение маршрутизатора
149/0x95	СКБ	Избирательное направленное вещание
151/0x97	ДПС	Динамическое состояние пакета
152/0x98	УМЗ	Восходящий многоадресный пакет
158/0x9E	Опыт	Эксперимент в стиле RFC3692
205/0xCD	ФИНН	Экспериментальное управление потоком
222/0xDE	Опыт	Эксперимент в стиле RFC3692

Данные

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

Список номеров IP-протоколов содержит полный список типов протоколов полезной нагрузки. Некоторые из распространенных протоколов полезной нагрузки включают в себя:

Номер протокола	Имя протокола	Аббревиатура
1	Протокол управляющих сообщений Интернета	ICMP
2	Протокол управления интернет-группами	IGMP
6	Протокол управления передачей	TCP
17	Протокол пользовательских датаграмм	UDP
41	Инкапсуляция IPv6	ЭНКАП
89	Сначала откройте кратчайший путь	ОСПФ
132	Протокол передачи управления потоком	SCTP

Фрагментация и повторная сборка

Основная статья: Фрагментация IP

Интернет-протокол обеспечивает передачу трафика между сетями. Проект позволяет использовать сети различной физической природы; он не зависит от базовой технологии передачи, используемой на канальном уровне. Сети с разным оборудованием обычно различаются не только скоростью передачи, но и максимальным блоком передачи (MTU). Когда одна сеть хочет передать дейтаграммы в сеть с меньшим MTU, она может фрагментировать свои дейтаграммы. В IPv4 эта функция была размещена на уровне Интернета и выполняется на маршрутизаторах IPv4, что ограничивает подверженность хостов этим проблемам.

Напротив, IPv6 , следующее поколение Интернет-протокола, не позволяет маршрутизаторам выполнять фрагментацию; хосты должны выполнить обнаружение Path MTU перед отправкой дейтаграмм.

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

Когда маршрутизатор получает пакет, он проверяет адрес назначения и определяет используемый исходящий интерфейс и MTU этого интерфейса. Если размер пакета больше, чем MTU, а бит «Не фрагментировать» (DF) в заголовке пакета установлен на 0, маршрутизатор может фрагментировать пакет.

Маршрутизатор делит пакет на фрагменты. Максимальный размер каждого фрагмента равен исходящему MTU минус размер IP-заголовка (минимум 20 байт; максимум 60 байт). Маршрутизатор помещает каждый фрагмент в отдельный пакет, причем в каждый пакет фрагментов вносятся следующие изменения:

• Поле общей длины — это размер фрагмента.
• Флаг большего количества фрагментов (MF) устанавливается для всех фрагментов, кроме последнего, которому присвоено значение 0.
• Поле смещения фрагмента устанавливается на основе смещения фрагмента в исходных полезных данных. Это измеряется в блоках по 8 байт.
• Поле контрольной суммы заголовка пересчитывается.

Например, для MTU размером 1500 байт и размера заголовка 20 байт смещения фрагмента будут кратны ${\frac {1{,}500-20}{8}}=185$ (0, 185, 370, 555, 740 и т. д.).

Возможно, что пакет фрагментируется на одном маршрутизаторе, а фрагменты фрагментируются на другом маршрутизаторе. Например, пакет размером 4520 байт, включая 20-байтовый IP-заголовок, фрагментируется в канале на два пакета с MTU 2500 байт:

Фрагмент	Размер (байты)	Размер заголовка (байты)	Размер данных (байты)	Флаг Больше фрагментов	Смещение фрагмента (8-байтовые блоки)
1	2,500	20	2,480	1	0
2	2,040	20	2,020	0	310

Общий размер данных сохраняется: 2480 байт + 2020 байт = 4500 байт. Смещения $0$ и ${\frac {0+2{,}480}{8}}=310$.

При пересылке на канал с MTU 1500 байт каждый фрагмент фрагментируется на два фрагмента:

Фрагмент	Размер (байты)	Размер заголовка (байты)	Размер данных (байты)	Флаг Больше фрагментов	Смещение фрагмента (8-байтовые блоки)
1	1,500	20	1,480	1	0
2	1,020	20	1,000	1	185
3	1,500	20	1,480	1	310
4	560	20	540	0	495

Опять же, размер данных сохраняется: 1480 + 1000 = 2480 и 1480 + 540 = 2020.

Также в этом случае бит More Fragments остаётся 1 для всех пришедших фрагментов с 1, а для последнего пришедшего фрагмента он работает как обычно, то есть бит MF устанавливается в 0 только в последнем. И, конечно же, поле «Идентификация» продолжает иметь одно и то же значение во всех перефрагментированных фрагментах. Таким образом, даже если фрагменты повторно фрагментируются, получатель знает, что изначально все они начались из одного и того же пакета.

Последнее смещение и последний размер данных используются для расчета общего размера данных: $495\times 8+540=3{,}960+540=4{,}500$.

Сборка

Получатель знает, что пакет является фрагментом, если выполняется хотя бы одно из следующих условий:

• Установлен флаг больше фрагментов , который справедлив для всех фрагментов, кроме последнего.
• поля Смещение фрагмента не равно нулю, что справедливо для всех фрагментов, кроме первого.

Получатель идентифицирует совпадающие фрагменты, используя адреса источника и назначения, идентификатор протокола и поле идентификации. Получатель повторно собирает данные из фрагментов с одинаковым идентификатором, используя как смещение фрагмента, так и флаг большего количества фрагментов. Когда получатель получает последний фрагмент, у которого флаг «больше фрагментов» установлен в 0, он может вычислить размер исходной полезной нагрузки данных, умножив смещение последнего фрагмента на восемь и добавив размер данных последнего фрагмента. В данном примере этот расчет был $495\times 8+540=4{,}500$ байты. Когда у получателя есть все фрагменты, их можно собрать в правильной последовательности в соответствии со смещениями, чтобы сформировать исходную дейтаграмму.

Вспомогательные протоколы

IP-адреса не привязаны каким-либо постоянным образом к сетевому оборудованию, и действительно, в современных операционных системах сетевой интерфейс может иметь несколько IP-адресов. Чтобы правильно доставить IP-пакет хосту назначения по каналу, хостам и маршрутизаторам необходимы дополнительные механизмы для установления связи между аппаратным адресом. сетевых интерфейсов и IP-адресов. Протокол разрешения адресов (ARP) выполняет преобразование IP-адреса в аппаратный для IPv4. Кроме того, часто необходима обратная корреляция. Например, если адрес не настроен заранее администратором, когда IP-хост загружается или подключается к сети, ему необходимо определить свой IP-адрес. Протоколы для таких обратных корреляций включают протокол динамической конфигурации хоста (DHCP), протокол начальной загрузки (BOOTP) и, реже, обратный ARP .

См. также

• История Интернета
• Список назначенных блоков адресов /8 IPv4

Ссылки

Эта статья была адаптирована из следующего источника под лицензией CC BY 4.0 ( 2022 г. ): Мишель Бакни; Сандра Ханбо (9 декабря 2022 г.). «Обзор Интернет-протокола версии 4 (IPv4)» (PDF) . Викижурнал науки . дои : 10.15347/WJS/2022.002 . ISSN   2470-6345 . OCLC   9708517136 . S2CID   254665961 . Викиданные   Q104661268 .

Внешние ссылки

• Управление по присвоению номеров в Интернете (IANA)
• IP, Интернет-протокол. Архивировано 14 мая 2011 г. на Wayback Machine — разбивка заголовка IP, включая конкретные параметры.
• Поддержка IP-мобильности для IPv4 . РФК   3344 .
• Официальное текущее состояние распределений IPv4/8, поддерживаемое IANA.