IPv4 - IPv4 - Wikipedia

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

Стек протоколов
Пакет IPv4
Цель	межсетевое взаимодействие протокол
Разработчики)	DARPA
Введено	1981
Слой OSI	Сетевой уровень
RFC (ы)	RFC 791

Интернет-протокол версии 4 (IPv4) - четвертая версия протокол Интернета (IP). Это один из основных протоколов основанных на стандартах межсетевое взаимодействие методы в Интернет и другие с коммутацией пакетов сети. IPv4 был первой версией, развернутой для производства на САТНЕТ в 1982 г. и на ARPANET в январе 1983 года. Он все еще направляет большую часть интернет-трафика сегодня,^[1] несмотря на продолжающееся развертывание протокола-преемника, IPv6.

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

История

Уровень IP был первоначально отделен в v3 TCP для улучшения дизайна и стабилизирован в версии 4.^[2] IPv4 описан в IETF публикация RFC 791 (Сентябрь 1981 г.), заменяя более раннее определение (RFC 760, Январь 1980 г.). В марте 1982 года Министерство обороны США объявило TCP / IP стандартом для всех военных компьютерных сетей.^[3]

Цель

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

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

Обращение

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

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

IPv4 резервирует специальные блоки адресов для частные сети (~ 18 миллионов адресов) и многоадресная передача адресов (~ 270 миллионов адресов).

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

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

Например, IP-адрес, разделенный точками 192.0.2.235 представляет 32-битный десятичная дробь номер 3221226219, который в шестнадцатеричный формат - 0xC00002EB. Это также может быть выражено в шестнадцатеричном формате с точками как 0xC0.0x00.0x02.0xEB или в восьмеричных байтовых значениях как 0300.0000.0002.0353.

Обозначение 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 году с публикации RFC  950. Это разделение стало более гибким с введением масок подсети переменной длины (VLSM) в RFC  1109 в 1987 г. В 1993 г. на основе этой работы RFC  1517 представил Бесклассовая междоменная маршрутизация (CIDR),^[4] который выражал количество битов (от наиболее значимый ) как, например, / 24, а схема на основе классов была названа классный, напротив. CIDR был разработан, чтобы разрешить перераспределение любого адресного пространства, чтобы пользователи могли выделять меньшие или большие блоки адресов. Иерархическая структура, созданная CIDR, управляется Управление по присвоению номеров в Интернете (IANA) и региональные интернет-регистры (RIR). Каждый RIR поддерживает общедоступный поисковый КТО база данных, которая предоставляет информацию о назначении IP-адресов.

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

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

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

Блок адресов	Диапазон адресов	Количество адресов	Объем	Описание
0.0.0.0/8	0.0.0.0–0.255.255.255	16777216	Программного обеспечения	Текущая сеть[6] (действительно только в качестве адреса отправителя).
10.0.0.0/8	10.0.0.0–10.255.255.255	16777216	Частная сеть	Используется для местной связи в пределах частная сеть.[7]
100.64.0.0/10	100.64.0.0–100.127.255.255	4194304	Частная сеть	Общее адресное пространство[8] для связи между поставщиком услуг и его абонентами при использовании NAT операторского уровня.
127.0.0.0/8	127.0.0.0–127.255.255.255	16777216	Хост	Используется для адреса обратной связи к локальному хосту.[6]
169.254.0.0/16	169.254.0.0–169.254.255.255	65536	Подсеть	Используется для локальные адреса ссылок[9] между двумя хостами по одному каналу, если IP-адрес не указан иначе, например, который обычно был бы получен из DHCP сервер.
172.16.0.0/12	172.16.0.0–172.31.255.255	1048576	Частная сеть	Используется для локальной связи в частной сети.[7]
192.0.0.0/24	192.0.0.0–192.0.0.255	256	Частная сеть	Назначение протокола IETF.[6]
192.0.2.0/24	192.0.2.0–192.0.2.255	256	Документация	Обозначается как TEST-NET-1, документация и примеры.[10]
192.88.99.0/24	192.88.99.0–192.88.99.255	256	Интернет	Зарезервированный.[11] Ранее использовался для IPv6 в IPv4 реле[12] (включены IPv6 адресный блок 2002::/16 ).
192.168.0.0/16	192.168.0.0–192.168.255.255	65536	Частная сеть	Используется для локальной связи в частной сети.[7]
198.18.0.0/15	198.18.0.0–198.19.255.255	131072	Частная сеть	Используется для эталонного тестирования межсетевого взаимодействия между двумя отдельными подсетями.[13]
198.51.100.0/24	198.51.100.0–198.51.100.255	256	Документация	Обозначается как TEST-NET-2, документация и примеры.[10]
203.0.113.0/24	203.0.113.0–203.0.113.255	256	Документация	Обозначается как TEST-NET-3, документация и примеры.[10]
224.0.0.0/4	224.0.0.0–239.255.255.255	268435456	Интернет	Используется для Многоадресная IP-рассылка.[14] (Бывшая сеть класса D).
240.0.0.0/4	240.0.0.0–255.255.255.254	268435455	Интернет	Зарезервировано для использования в будущем.[15] (Бывшая сеть класса E).
255.255.255.255/32	255.255.255.255	1	Подсеть	Зарезервировано для "ограниченного трансляция " адрес назначения.[6][16]

Частные сети

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

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

имя	CIDR блокировать	Диапазон адресов	Количество адресов	Классный описание
24-битный блок	10.0.0.0/8	10.0.0.0 – 10.255.255.255	16777216	Одиночный класс А.
20-битный блок	172.16.0.0/12	172.16.0.0 – 172.31.255.255	1048576	Непрерывный диапазон из 16 блоков класса B.
16-битный блок	192.168.0.0/16	192.168.0.0 – 192.168.255.255	65536	Непрерывный диапазон из 256 блоков класса C.

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

Link-local адресация

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

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

Петля

Основная статья: Localhost

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

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

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

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

Например, в подсети 192.168.5.0/24 (маска подсети 255.255.255.0) идентификатор 192.168.5.0 используется для обозначения всей подсети. Широковещательный адрес сети 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.0.0–192.168.255.255, широковещательный адрес 192.168.255.255. Для хостов можно использовать следующие адреса, даже если они заканчиваются на 255: 192.168.1.255, 192.168.2.255 и т. Д. Кроме того, 192.168.0.0 является идентификатором сети и не должен назначаться интерфейсу.^[18] Адреса 192.168.1.0, 192.168.2.0 и т. Д. Могут быть назначены, несмотря на то, что они заканчиваются на 0.

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

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

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

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

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

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

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

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

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

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

С 1980-х годов стало очевидно, что пул доступных адресов IPv4 истощается со скоростью, которая изначально не предполагалась в первоначальном дизайне сети.^[21] Основные рыночные силы, которые ускорили истощение адресов, включали быстро растущее число пользователей Интернета, которые все чаще использовали мобильные вычислительные устройства, такие как портативные компьютеры, персональные цифровые помощники (КПК) и смартфоны с услугами IP-передачи данных. Кроме того, высокоскоростной доступ в Интернет был основан на постоянно включенных устройствах. Угроза истощения побудила к внедрению ряда лечебных технологий, таких как Бесклассовая междоменная маршрутизация (CIDR) к середине 1990-х, повсеместное использование преобразование сетевых адресов (NAT) в системах провайдеров доступа к сети, а также строгие политики распределения на основе использования в региональных и местных реестрах Интернета.

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

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

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

IP пакет состоит из раздела заголовка и раздела данных. IP-пакет не имеет контрольной суммы данных или любого другого нижнего колонтитула после раздела данных. уровень связи инкапсулирует IP-пакеты во фреймы с нижним колонтитулом CRC, который обнаруживает большинство ошибок, многие протоколы транспортного уровня переносимые по IP, также имеют собственную проверку ошибок.^[28]

Заголовок

Заголовок пакета 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	Версия				МГП				DSCP						ECN		Общая длина
4	32	Идентификация																Флаги			Смещение фрагмента
8	64	Время жить								Протокол								Контрольная сумма заголовка
12	96	Исходный IP-адрес
16	128	IP-адрес получателя
20	160	Опции (если МГП> 5)
24	192
28	224
32	256

Версия

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

Длина заголовка в Интернете (МГП)

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

Кодовый пункт дифференцированных услуг (DSCP)

Первоначально определялся как тип обслуживания (ToS) в этом поле указывается дифференцированные услуги (DiffServ) на RFC 2474 (обновлено RFC 3168 и RFC 3260 ). Появляются новые технологии, которые требуют потоковой передачи данных в реальном времени и поэтому используют поле DSCP. Примером является Голос по IP (VoIP), который используется для интерактивных голосовых услуг.

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

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

Общая длина

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

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

Это поле является полем идентификации и в основном используется для однозначной идентификации группы фрагментов одной дейтаграммы IP. Некоторые экспериментальные работы предлагали использовать поле ID для других целей, например, для добавления информации об отслеживании пакетов, чтобы помочь отслеживать дейтаграммы с поддельными адресами источника,^[30] но RFC 6864 теперь запрещает любое такое использование.

Флаги

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

• бит 0: зарезервирован; должно быть равно нулю.^{[примечание 1]}
• бит 1: не фрагментировать (DF)
• бит 2: Больше фрагментов (MF)

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

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

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

Поле смещения фрагмента измеряется в блоках по восемь байтов. Он имеет длину 13 бит и определяет смещение конкретного фрагмента относительно начала исходной нефрагментированной дейтаграммы IP. Первый фрагмент имеет нулевое смещение. Это позволяет максимальное смещение (2¹³ - 1) × 8 = 65 528 байтов, что превышает максимальную длину IP-пакета в 65 535 байтов с учетом длины заголовка (65 528 + 20 = 65 548 байтов).

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

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

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

Протокол

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

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

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

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

Адрес источника

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

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

Это поле IPv4-адрес получателя пакета. Как и адрес источника, он может быть изменен при передаче преобразование сетевых адресов устройство.

Опции

В поле опций не часто используется. Обратите внимание, что значение в поле IHL должно включать достаточно дополнительных 32-битных слов для хранения всех параметров (плюс любые дополнения, необходимые для обеспечения того, чтобы заголовок содержал целое число 32-битных слов). Список опций может заканчиваться EOL (Конец списка опций, 0x00) вариант; это необходимо только в том случае, если конец параметров иначе не совпадал бы с концом заголовка. Возможные варианты, которые можно поместить в шапку, следующие:

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

• Примечание. Если длина заголовка больше 5 (т. Е. От 6 до 15), это означает, что поле параметров присутствует и его необходимо учитывать.
• Примечание. Копирование, класс параметра и номер параметра иногда называют одним восьмибитным полем, Тип опции.

Пакеты, содержащие некоторые варианты могут считаться опасными некоторыми маршрутизаторами и будет заблокирован.^[31]

В таблице ниже показаны определенные параметры для IPv4. Строго говоря, столбец с меткой «Номер опции» на самом деле является «значением опции», полученным из битов «Скопировано», «Класс опции» и «Номер опции», как определено выше. Однако, поскольку сегодня большинство людей называют этот комбинированный битовый набор «номером опции», эта таблица показывает это общее использование. В таблице показаны как десятичные, так и шестнадцатеричные числа опций.^[32]

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

Данные

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

Вот некоторые из распространенных протоколов полезной нагрузки:

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

Увидеть Список номеров IP-протокола для полного списка.

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

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

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

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

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

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

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

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

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

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

Фрагмент	Размер (байты)	Размер заголовка (байты)	Размер данных (байты)	Флаг Еще фрагменты	Смещение фрагмента (8-байтовые блоки)
1	2500	20	2480	1	0
2	2040	20	2020	0	310

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

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

Фрагмент	Размер (байты)	Размер заголовка (байты)	Размер данных (байты)	Флаг Еще фрагменты	Смещение фрагмента (Блоки по 8 байт)
1	1500	20	1480	1	0
2	1020	20	1000	1	185
3	1500	20	1480	1	310
4	560	20	540	0	495

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

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

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

Повторная сборка

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

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

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

Когда у получателя есть все фрагменты, их можно собрать в правильной последовательности согласно смещениям, чтобы сформировать исходную дейтаграмму.

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

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

Смотрите также

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

Заметки

1. Как Первоапрельские розыгрыши' шутка, предложенная для использования в RFC 3514 как "Злой бит ".

использованная литература

1. «Отчеты об анализе BGP». Получено 2013-01-09.
2. "Где IPv1, 2, 3 и 5?". blog.alertlogic.com. Получено 2020-08-12.
3. «Краткая история IPv4». Группа рынка IPv4. Получено 2020-08-19.
4. «Понимание IP-адресации: все, что вы когда-либо хотели знать» (PDF). 3Com. Архивировано из оригинал (PDF) 16 июня 2001 г.
5. RFC 5735
6. М. Коттон; Л. Вегода; Р. Боника; Б. Хаберман (апрель 2013 г.). Реестры IP-адресов специального назначения. Инженерная группа Интернета. Дои:10.17487 / RFC6890. БКП 153. RFC 6890. Обновлено RFC 8190.
7. Ю. Рехтер; Б. Московиц; Д. Карренберг; Г. Ж. де Гроот; Э. Лир (февраль 1996 г.). Распределение адресов для частных сетей. Сетевая рабочая группа. Дои:10.17487 / RFC1918. ПП 5. RFC 1918. Обновлено RFC 6761.
8. J. Weil; В. Куарсингх; К. Донли; К. Лильенстолпе; М. Азинджер (апрель 2012 г.). Зарезервированный IANA префикс IPv4 для общего адресного пространства. Инженерная группа Интернета (IETF). Дои:10.17487 / RFC6598. ISSN  2070-1721. БКП 153. RFC 6598.
9. С. Чешир; Б. Абоба; Э. Гутман (май 2005 г.). Динамическая настройка IPv4 Link-Local адресов. Сетевая рабочая группа. Дои:10.17487 / RFC3927. RFC 3927.
10. Дж. Аркко; М. Коттон; Л. Вегода (январь 2010 г.). Блоки адресов IPv4 зарезервированы для документации. Инженерная группа Интернета. Дои:10.17487 / RFC5737. ISSN  2070-1721. RFC 5737.
11. О. Троан (май 2015 г.). Б. Карпентер (ред.). Префикс Anycast устарел для маршрутизаторов ретрансляции 6to4. Инженерная группа Интернета. Дои:10.17487 / RFC7526. БКП 196. RFC 7526.
12. К. Уитема (июнь 2001 г.). Префикс Anycast для маршрутизаторов ретрансляции 6to4. Сетевая рабочая группа. Дои:10.17487 / RFC3068. RFC 3068. Устарело RFC 7526.
13. С. Браднер; Дж. Маккуэйд (март 1999 г.). Методология сравнительного анализа для устройств сетевого взаимодействия. Сетевая рабочая группа. Дои:10.17487 / RFC2544. RFC 2544. Автор обновления: RFC 6201 и RFC 6815.
14. М. Коттон; Л. Вегода; Д. Мейер (март 2010 г.). Рекомендации IANA по назначению многоадресных адресов IPv4. Инженерная группа Интернета. Дои:10.17487 / RFC5771. BCP 51. RFC 5771.
15. Дж. Рейнольдс, изд. (Январь 2002 г.). Присвоенные номера: RFC 1700 заменен интерактивной базой данных. Сетевая рабочая группа. Дои:10.17487 / RFC3232. RFC 3232. Устаревшие RFC 1700.
16. Джеффри Могул (октябрь 1984 г.). Вещание Интернет-дейтаграмм. Сетевая рабочая группа. Дои:10.17487 / RFC0919. RFC 919.
17. «RFC 923». IETF. Июнь 1984 г.. Получено 15 ноября 2019. Специальные адреса: в определенных контекстах полезно иметь фиксированные адреса с функциональным значением, а не в качестве идентификаторов конкретных хостов. Когда требуется такое использование, нулевой адрес должен интерпретироваться как означающий «это», как в «этой сети».
18. Роберт Брейден (Октябрь 1989 г.). «Требования к хостам Интернета - уровни связи». IETF. п. 31. RFC  1122.
19. Роберт Брейден (Октябрь 1989 г.). «Требования к хостам Интернета - уровни связи». IETF. п. 66. RFC  1122.
20. RFC  3021
21. "В мире" заканчиваются интернет-адреса'". Архивировано из оригинал на 2011-01-25. Получено 2011-01-23.
22. Смит, Люси; Липнер, Ян (3 февраля 2011 г.). «Свободный пул адресного пространства IPv4 исчерпан». Организация номерного ресурса. Получено 3 февраля 2011.
23. ICANN, список рассылки nanog. «Пять / 8 выделено RIR - не осталось нераспределенных одноадресных IPv4 / 8».
24. Информационный центр Азиатско-Тихоокеанской сети (15 апреля 2011 г.). "Пул IPv4-адресов APNIC достиг финала / 8". Архивировано из оригинал 7 августа 2011 г.. Получено 15 апреля 2011.
25. «Спецификация Интернет-протокола версии 6 (IPv6)». tools.ietf.org. Получено 2019-12-13.
26. RFC 3701, Р. Финк, Р. Хинден, 6bone (выделение адресов для тестирования IPv6) Поэтапный отказ (Март 2004 г.)
27. Международная конференция IEEE по новым технологиям и инновационной деловой практике для трансформации общества (EmergiTech), 2016 г.: дата, 3-6 августа 2016 г.. Технологический университет, Маврикий, Институт инженеров по электротехнике и электронике. Пискатауэй, штат Нью-Джерси. ISBN  9781509007066. OCLC  972636788.
28. RFC 1726 Раздел 6.2
29. Постел, Дж. протокол Интернета. Дои:10.17487 / RFC0791. RFC 791.
30. Дикарь, Стефан. «Практическая сетевая поддержка для отслеживания IP». Получено 2010-09-06.
31. "Неофициальный FAQ Cisco". Получено 2012-05-10.
32. https://www.iana.org/assignments/ip-parameters/ip-parameters.xhtml#ip-parameters-1

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

• Управление по присвоению номеров в Интернете (IANA)
• IP, Интернет-протокол - Разбивка IP-заголовка, включая конкретные параметры
• RFC 3344 - Мобильность IPv4
• IPv6 против NAT операторского уровня / выжать больше из IPv4
• Отчет RIPE о потреблении адресов по состоянию на октябрь 2003 г.
• Официальное текущее состояние распределения IPv4 / 8, поддерживаемое IANA
• Динамически генерируемые графики потребления адресов IPv4 с прогнозами дат исчерпания - Джефф Хьюстон
• IP-адресация в Китае и миф о нехватке адресов
• Обратный отсчет оставшихся доступных адресов IPv4 (по оценкам)