Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Интернет-протокол версии 4
Стек протоколов
Пакет IPv4 -en.svg
Пакет IPv4
Цельмежсетевой протокол
Разработчики)DARPA
Введено1981 г.
Слой OSIСетевой уровень
RFC (ы)RFC 791
Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой
  • ARP
  • OSPF
  • Туннели
    • L2TP
  • PPP
  • MAC
    • Ethernet
    • Вай фай
    • DSL
    • ISDN
    • FDDI
  • более...
  • v
  • т
  • е

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

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

История [ править ]

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

Цель [ править ]

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

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

Обращение [ править ]

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

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

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, а схема на основе классов получила название classful  , напротив. CIDR был разработан, чтобы разрешить перераспределение любого адресного пространства, чтобы пользователи могли выделять меньшие или большие блоки адресов. Иерархическая структура, созданная CIDR, управляется Управлением по присвоению номеров Интернета (IANA) и региональными интернет-реестрами (RIR). Каждый RIR ведет общедоступную базу данных WHOIS с возможностью поиска, в которой содержится информация о назначенных IP-адресах.

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

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

Специальные адресные блоки
Блок адресовДиапазон адресовКоличество адресовОбъемОписание
0.0.0.0/80.0.0.0–0.255.255.25516 777 216Программного обеспеченияТекущая сеть [6] (действительна только в качестве адреса источника).
10.0.0.0/810.0.0.0–10.255.255.25516 777 216Частная сетьИспользуется для локальной связи в частной сети . [7]
100.64.0.0/10100.64.0.0–100.127.255.2554 194 304Частная сетьОбщее адресное пространство [8] для связи между поставщиком услуг и его абонентами при использовании NAT операторского уровня .
127.0.0.0/8127.0.0.0–127.255.255.25516 777 216ХозяинИспользуется для обратных адресов к локальному хосту. [6]
169.254.0.0/16169.254.0.0–169.254.255.25565 536ПодсетьИспользуется для локальных адресов канала [9] между двумя хостами по одному каналу, когда IP-адрес не указан иначе, например, который обычно был бы получен с DHCP- сервера.
172.16.0.0/12172.16.0.0–172.31.255.2551 048 576Частная сетьИспользуется для локальной связи в частной сети. [7]
192.0.0.0/24192.0.0.0–192.0.0.255256Частная сетьНазначение протокола IETF. [6]
192.0.2.0/24192.0.2.0–192.0.2.255256ДокументацияОбозначается как TEST-NET-1, документация и примеры. [10]
192.88.99.0/24192.88.99.0–192.88.99.255256ИнтернетЗарезервированный. [11] Ранее использовалось для ретрансляции IPv6 в IPv4 [12] (включая блок адресов IPv6 2002 :: / 16 ).
192.168.0.0/16192.168.0.0–192.168.255.25565 536Частная сетьИспользуется для локальной связи в частной сети. [7]
198.18.0.0/15198.18.0.0–198.19.255.255131 072Частная сетьИспользуется для эталонного тестирования межсетевого взаимодействия между двумя отдельными подсетями. [13]
198.51.100.0/24198.51.100.0–198.51.100.255256ДокументацияОбозначается как TEST-NET-2, документация и примеры. [10]
203.0.113.0/24203.0.113.0–203.0.113.255256ДокументацияОбозначается как TEST-NET-3, документация и примеры. [10]
224.0.0.0/4224.0.0.0–239.255.255.255268 435 456ИнтернетИспользуется для многоадресной IP-рассылки . [14] (Бывшая сеть класса D).
240.0.0.0/4240.0.0.0–255.255.255.254268 435 455ИнтернетЗарезервировано для использования в будущем. [15] (Бывшая сеть класса E).
255.255.255.255/32255.255.255.2551ПодсетьЗарезервировано для адреса назначения "ограниченной широковещательной рассылки". [6] [16]

Частные сети [ править ]

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


Зарезервированные диапазоны частных сетей IPv4 [7]
ИмяБлок CIDRДиапазон адресовКоличество адресовКлассное описание
24-битный блок10.0.0.0/810.0.0.0 - 10.255.255.25516 777 216Одиночный класс А.
20-битный блок172.16.0.0/12172.16.0.0 - 172.31.255.2551 048 576Непрерывный диапазон из 16 блоков класса B.
16-битный блок192.168.0.0/16192.168.0.0 - 192.168.255.25565 536Непрерывный диапазон из 256 блоков класса C.

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

Локальная адресация ссылки [ править ]

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

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

Loopback [ править ]

Основная статья: 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.00000000192.168.5.0
Адрес трансляции11000000.10101000.00000101.11111111192.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.00010000203.0.113.16
Адрес трансляции11001011.00000000.01110001.00011111203.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 64 адреса хоста. Однако 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
СмещенияОктет0123
ОктетКусочек0123456789101112131415161718192021 год2223242526 год2728 год293031 год
00ВерсияМГПDSCPECNОбщая длина
432ИдентификацияФлагиСмещение фрагмента
864Время житьПротоколКонтрольная сумма заголовка
1296Исходный IP-адрес
16128IP-адрес получателя
20160Варианты (если МГП> 5)
24192
28 год224
32256
Версия
Первое поле заголовка в 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 . [a] При потоковой передаче данных в реальном времени используется поле DSCP. Примером является передача голоса по IP (VoIP), который используется для интерактивных голосовых услуг.
Явное уведомление о перегрузке ( ECN )
Это поле определено в RFC 3168 и позволяет сквозное уведомление о перегрузке сети без потери пакетов . ECN - это дополнительная функция, доступная, когда ее поддерживают обе конечные точки, и эффективная, когда она также поддерживается базовой сетью.
Общая длина
Это 16-битное поле определяет полный размер пакета в байтах, включая заголовок и данные. Минимальный размер составляет 20 байтов (заголовок без данных), а максимальный - 65 535 байтов. Все хосты должны иметь возможность собирать дейтаграммы размером до 576 байт, но большинство современных хостов обрабатывают гораздо большие пакеты. Иногда ссылки накладывают дополнительные ограничения на размер пакета, и в этом случае дейтаграммы должны быть фрагментированы. Фрагментация в IPv4 обрабатывается либо на хосте, либо в маршрутизаторах.
Идентификация
Это поле является полем идентификации и в основном используется для однозначной идентификации группы фрагментов одной дейтаграммы IP. Некоторые экспериментальные работы предлагали использовать поле ID для других целей, например, для добавления информации об отслеживании пакетов, чтобы помочь отслеживать дейтаграммы с поддельными адресами источника [30], но RFC 6864 теперь запрещает любое такое использование.
Флаги
Далее следует трехбитовое поле, которое используется для управления или идентификации фрагментов. Это (в порядке убывания значимости):
  • бит 0: зарезервирован; должно быть равно нулю. [b]
  • бит 1: не фрагментировать (DF)
  • бит 2: Больше фрагментов (MF)
Если установлен флаг DF и для маршрутизации пакета требуется фрагментация, то пакет отбрасывается. Это можно использовать при отправке пакетов на хост, у которого нет ресурсов для обработки фрагментации. Его также можно использовать для определения MTU пути , либо автоматически программным обеспечением IP хоста, либо вручную с помощью диагностических инструментов, таких как ping или traceroute .
Для нефрагментированных пакетов флаг MF сбрасывается. Для фрагментированных пакетов все фрагменты, кроме последнего, имеют установленный флаг MF. Последний фрагмент имеет ненулевое поле смещения фрагмента, что отличает его от нефрагментированного пакета.
Смещение фрагмента
Поле смещения фрагмента измеряется в блоках по восемь байтов. Он имеет длину 13 бит и определяет смещение конкретного фрагмента относительно начала исходной нефрагментированной IP-дейтаграммы. Первый фрагмент имеет нулевое смещение. Это позволяет максимальное смещение (2 13  - 1) × 8 = 65 528 байтов, что превышает максимальную длину IP-пакета в 65 535 байтов с учетом длины заголовка (65 528 + 20 = 65 548 байтов).
Время жить (TTL)
Восьмибитное поле времени жизни помогает предотвратить сохранение дейтаграмм (например, круговое движение) в Интернете. Это поле ограничивает время жизни дейтаграммы. Он указывается в секундах, но интервалы времени менее 1 секунды округляются до 1. На практике это поле стало счетчиком переходов - когда дейтаграмма достигает маршрутизатора , маршрутизатор уменьшает поле TTL на единицу. Когда поле TTL достигает нуля, маршрутизатор отбрасывает пакет и обычно отправляет сообщение ICMP Time Exceeded отправителю.
Программа traceroute использует эти сообщения 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 / 0x00EOOLКонец списка опций
1 / 0x01NOPНет операции
2 / 0x02SECБезопасность (несуществующий)
7 / 0x07RRЗапись маршрута
10 / 0x0AЗСУЭкспериментальное измерение
11 / 0x0BMTUPЗонд MTU
12 / 0x0CМТУРMTU Ответ
15 / 0x0FКОДИРОВАТЬКОДИРОВАТЬ
25 / 0x19QSБыстрый старт
30 / 0x1EEXPRFC3692 эксперимент
68 / 0x44TSШтамп времени
82 / 0x52TRTraceroute
94 / 0x5EEXPRFC3692 эксперимент
130 / 0x82SECБезопасность (RIPSO)
131 / 0x83ЛСРМаршрут свободного источника
133 / 0x85E-SECРасширенная безопасность (RIPSO)
134 / 0x86CIPSOВариант коммерческой защиты IP
136 / 0x88SIDID потока
137 / 0x89ССРСтрогий исходный маршрут
142 / 0x8EВИЗАЭкспериментальный контроль доступа
144 / 0x90IMITDДескриптор трафика IMI
145 / 0x91EIPРасширенный интернет-протокол
147 / 0x93ДОБАВИТЬРасширение адреса
148 / 0x94РТРАЛЬТПредупреждение маршрутизатора
149 / 0x95SDBСелективная направленная трансляция
151 / 0x97ДПСДинамическое состояние пакета
152 / 0x98UMPUpstream Multicast Pkt.
158 / 0x9EEXPRFC3692 эксперимент
205 / 0xCDFINNЭкспериментальное управление потоком
222 / 0xDEEXPRFC3692 эксперимент

Данные [ редактировать ]

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

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

Номер протоколаИмя протоколаСокращение
1Протокол управляющих сообщений ИнтернетаICMP
2Протокол управления интернет-группамиIGMP
6Протокол управления передачейTCP
17Протокол пользовательских датаграммUDP
41 годИнкапсуляция IPv6ENCAP
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 байтов смещения фрагментов будут кратны . Эти кратные: 0, 185, 370, 555, 740, ...

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

ФрагментРазмер
(байты)		Размер заголовка
(байты)		Размер данных
(байты)		Пометить
Больше фрагментов		Смещение фрагмента
(8-байтовые блоки)
1250020248010
22040 г.202020 г.0310

Общий размер данных сохраняется: 2480 байт + 2020 байт = 4500 байт. Смещения равны и .

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

ФрагментРазмер
(байты)		Размер заголовка
(байты)		Размер данных
(байты)		Пометить
Больше фрагментов		Смещение фрагмента
(8-байтовые блоки)
1150020148010
210202010001185
315002014801310
4560205400495

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

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

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

Повторная сборка [ править ]

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

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

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

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

Вспомогательные протоколы [ править ]

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

См. Также [ править ]

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

Заметки [ править ]

  1. ^ Обновлено RFC 3168 и RFC 3260
  2. ^ Как первоапрельская шутка, предложенная для использования в RFC 3514 как « Злой бит »

Ссылки [ править ]

  1. ^ «Отчеты об анализе BGP» . Проверено 9 января 2013 .
  2. ^ "Где IPv1, 2, 3 и 5?" . blog.alertlogic.com . Проверено 12 августа 2020 .
  3. ^ «Краткая история IPv4» . Группа рынка IPv4 . Проверено 19 августа 2020 .
  4. ^ «Понимание IP-адресации: все, что вы когда-либо хотели знать» (PDF) . 3Com. Архивировано из оригинального (PDF) 16 июня 2001 года.
  5. ^ RFC 5735
  6. ^ а б в г М. Коттон; Л. Вегода; Р. Боника; Б. Хаберман (апрель 2013 г.). Реестры IP-адресов специального назначения . Инженерная группа Интернета . DOI : 10,17487 / RFC6890 . BCP 153. RFC 6890 . Обновлено RFC 8190 .
  7. ^ а б в г Ю. Рехтер; Б. Московиц; Д. Карренберг; GJ de Groot; Э. Лир (февраль 1996 г.). Распределение адресов для частных сетей . Сетевая рабочая группа. DOI : 10,17487 / RFC1918 . BCP 5. RFC 1918 . Обновлено RFC 6761 .
  8. ^ J. Weil; В. Куарсингх; К. Донли; К. Лильенстолпе; М. Азингер (апрель 2012 г.). Зарезервированный IANA префикс IPv4 для общего адресного пространства . Инженерная группа Интернета (IETF). DOI : 10,17487 / RFC6598 . ISSN 2070-1721 . BCP 153. RFC 6598 . 
  9. ^ С. Чешир; Б. Абоба; Э. Гуттман (май 2005 г.). Динамическая конфигурация IPv4 Link-Local адресов . Сетевая рабочая группа. DOI : 10,17487 / RFC3927 . RFC 3927 .
  10. ^ a b c Дж. Аркко; М. Коттон; Л. Вегода (январь 2010 г.). Блоки адресов IPv4 зарезервированы для документации . Инженерная группа Интернета . DOI : 10,17487 / RFC5737 . ISSN 2070-1721 . RFC 5737 . 
  11. ^ О. Troan (май 2015). Б. Карпентер (ред.). Устарело использование префикса Anycast для маршрутизаторов ретрансляции 6to4 . Инженерная группа Интернета . DOI : 10,17487 / RFC7526 . BCP 196. RFC 7526 .
  12. ^ С. Huitema (июнь 2001). Префикс Anycast для маршрутизаторов ретрансляции 6to4 . Сетевая рабочая группа. DOI : 10,17487 / RFC3068 . RFC 3068 . Устарело RFC 7526 .
  13. ^ С. Брэднер; Дж. Маккуэйд (март 1999 г.). Методология сравнительного анализа для устройств сетевого взаимодействия . Сетевая рабочая группа. DOI : 10,17487 / RFC2544 . RFC 2544 . Обновлено: RFC 6201 и RFC 6815 .
  14. ^ М. Коттон; Л. Вегода; Д. Мейер (март 2010 г.). Рекомендации IANA по назначению адресов многоадресной рассылки IPv4 . Инженерная группа Интернета . DOI : 10,17487 / RFC5771 . BCP 51. RFC 5771 .
  15. ^ Дж. Рейнольдс, изд. (Январь 2002 г.). Присвоенные номера: RFC 1700 заменен интерактивной базой данных . Сетевая рабочая группа. DOI : 10,17487 / RFC3232 . RFC 3232 . Устарел RFC 1700 .
  16. ↑ Джеффри Могул (октябрь 1984 г.). Вещание интернет-дейтаграмм . Сетевая рабочая группа. DOI : 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 . Проверено 23 января 2011 .
  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 . Проверено 13 декабря 2019 .
  26. ^ RFC 3701 , Р. Финк, Р. Хинден, 6bone (выделение адресов для тестирования IPv6) поэтапный отказ (март 2004 г.)
  27. ^ 2016 IEEE Международная конференция по новым технологиям и инновационной бизнес - практик для трансформации обществ (EmergiTech): дата, 3-6 августа 2016 . Технологический университет, Маврикий, Институт инженеров по электротехнике и электронике. Пискатауэй, штат Нью-Джерси. ISBN 9781509007066. OCLC  972636788 .CS1 maint: другие ( ссылка )
  28. ^ RFC 1726 раздел 6.2
  29. ^ Постел, J. Интернет-протокол . DOI : 10,17487 / RFC0791 . RFC 791 .
  30. ^ Дикарь, Стефан. «Практическая сетевая поддержка IP-трассировки» . Проверено 6 сентября 2010 .
  31. ^ "Неофициальный FAQ Cisco" . Проверено 10 мая 2012 .
  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 (приблизительный)