stringtranslate.com

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

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

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

История

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

Цель

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

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

Адресация

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

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

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

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

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

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

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

Частные сети

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


Поскольку две частные сети, например два филиала, не могут напрямую взаимодействовать через общедоступный Интернет, эти две сети должны быть соединены через Интернет через виртуальную частную сеть (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-пакеты, исходные адреса которых принадлежат этой сети, никогда не должны появляться за пределами хоста. Пакеты, полученные на интерфейсе без обратной связи с адресом источника или назначения обратной связи, должны быть отброшены.

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

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

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

Однако это не означает, что каждый адрес, заканчивающийся на 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] : 31  Адреса 192.168.1.0 , 192.168.2.0 и т. д. могут быть назначены, несмотря на то, что они заканчиваются на 0.

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Заголовок

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

Версия
Первое поле заголовка в IP- пакете — это четырехбитное поле версии. Для IPv4 это всегда равно 4.
Длина интернет-заголовка (IHL)
Заголовок IPv4 имеет переменный размер из-за необязательного 14-го поля (параметры). Поле IHL содержит размер заголовка IPv4; он имеет 4 бита, которые определяют количество 32-битных слов в заголовке. Минимальное значение этого поля — 5, [32] , что указывает на длину 5 × 32 бита = 160 бит = 20 байт. Для 4-битного поля максимальное значение равно 15; это означает, что максимальный размер заголовка IPv4 составляет 15 × 32 бита = 480 бит = 60 байт.
Кодовая точка дифференцированных услуг (ДСКП )
Первоначально это поле определялось как тип услуги (ToS), но теперь оно определяет дифференцированные услуги (DiffServ). [33] Потоковая передача данных в реальном времени использует поле DSCP. Примером является передача голоса по IP (VoIP), которая используется для интерактивных голосовых услуг.
Явное уведомление о перегрузке (ECN )
Это поле позволяет осуществлять сквозное уведомление о перегрузке сети без потери пакетов . [34] ECN — это дополнительная функция, доступная, если ее поддерживают обе конечные точки, и эффективная, если она также поддерживается базовой сетью.
Общая длина
Это 16-битное поле определяет размер всего пакета в байтах, включая заголовок и данные. Минимальный размер — 20 байт (заголовок без данных), максимальный — 65 535 байт. Все хосты должны иметь возможность собирать датаграммы размером до 576 байт, но большинство современных хостов обрабатывают пакеты гораздо большего размера. Каналы могут накладывать дополнительные ограничения на размер пакета, и в этом случае дейтаграммы должны быть фрагментированы . Фрагментация в IPv4 выполняется либо на отправляющем хосте, либо на маршрутизаторах. Обратная сборка выполняется на принимающем хосте.
Идентификация
Это поле является полем идентификации и в основном используется для уникальной идентификации группы фрагментов одной IP-дейтаграммы. В некоторых экспериментальных работах предлагалось использовать поле ID для других целей, например, для добавления информации о отслеживании пакетов, чтобы помочь отслеживать датаграммы с поддельными адресами источника, [35] , но любое такое использование теперь запрещено. [36]
Флаги
Далее следует трехбитовое поле, которое используется для управления или идентификации фрагментов. Это (в порядке от наиболее значимого к наименее значимому):
  • бит 0: Зарезервировано; должно быть равно нулю. [а]
  • бит 1: Не фрагментировать (DF)
  • бит 2: Больше фрагментов (MF)
Если флаг DF установлен и для маршрутизации пакета требуется фрагментация, пакет отбрасывается. Это можно использовать при отправке пакетов на хост, у которого нет ресурсов для повторной сборки фрагментов. Его также можно использовать для обнаружения MTU пути либо автоматически с помощью программного обеспечения IP хоста, либо вручную с помощью диагностических инструментов, таких как ping или Traceroute .
Для нефрагментированных пакетов флаг MF сбрасывается. Для фрагментированных пакетов все фрагменты, кроме последнего, имеют установленный флаг MF. Последний фрагмент имеет ненулевое поле «Смещение фрагмента», что отличает его от нефрагментированного пакета.
Смещение фрагмента
В этом поле указывается смещение конкретного фрагмента относительно начала исходной нефрагментированной IP-дейтаграммы. Значение смещения фрагментации для первого фрагмента всегда равно 0. Поле имеет ширину 13 бит, поэтому смещение может быть от 0 до 8191 (от (2 0  – 1) до (2 13  – 1)). Фрагменты указываются в единицах по 8 байт, поэтому длина фрагмента должна быть кратна 8. [37] Следовательно, 13-битное поле допускает максимальное смещение (2 13  – 1) × 8 = 65 528 байт, при этом включенная длина заголовка (65 528 + 20 = 65 548 байт), поддерживающая фрагментацию пакетов, превышающих максимальную длину IP в 65 535 байт.
Время жить (TTL)
Восьмибитное поле времени жизни ограничивает время жизни дейтаграммы, чтобы предотвратить сбой сети в случае возникновения петли маршрутизации . Оно указывается в секундах, но временные интервалы менее 1 секунды округляются до 1. На практике поле используется как счетчик прыжков — когда дейтаграмма поступает на маршрутизатор , маршрутизатор уменьшает поле TTL на единицу. Когда поле TTL достигает нуля, маршрутизатор отбрасывает пакет и обычно отправляет отправителю сообщение о превышении времени ICMP .
Программа трассировки отправляет сообщения с скорректированными значениями TTL и использует эти сообщения ICMP о превышении времени для идентификации маршрутизаторов, через которые проходят пакеты от источника к месту назначения.
Протокол
Это поле определяет протокол, используемый в части данных IP-дейтаграммы. IANA ведет список номеров IP-протоколов . [38]
Контрольная сумма заголовка
16-битное поле контрольной суммы заголовка IPv4 используется для проверки заголовка на наличие ошибок. Когда пакет поступает на маршрутизатор или в пункт назначения, сетевое устройство вычисляет контрольную сумму заголовка, включая поле контрольной суммы. Ожидается значение 0xFFFF. Если получен другой результат, устройство отбрасывает пакет. Ошибки в части данных пакета обрабатываются отдельно с помощью инкапсулированного протокола. И UDP , и TCP имеют отдельные контрольные суммы, которые применяются к их данным.
Когда пакет поступает на маршрутизатор, маршрутизатор уменьшает поле TTL в заголовке. Следовательно, маршрутизатор должен вычислить новую контрольную сумму заголовка.
Поле контрольной суммы представляет собой 16-битное дополнение суммы всех 16-битных слов в заголовке. Для расчета контрольной суммы значение поля контрольной суммы равно нулю.
Адрес источника
Это 32-битное поле представляет собой IPv4-адрес отправителя пакета. Его можно изменить при передаче с помощью трансляции сетевых адресов (NAT).
Адрес назначения
Это 32-битное поле представляет собой IPv4-адрес получателя пакета. На это может влиять NAT.
Параметры
Поле опций используется не часто. Пакеты, содержащие некоторые параметры, могут рассматриваться некоторыми маршрутизаторами как опасные и блокироваться. [39] Значение в поле IHL должно включать достаточное количество дополнительных 32-битных слов для хранения всех опций и любого заполнения, необходимого для обеспечения того, чтобы заголовок содержал целое число 32-битных слов. Если IHL больше 5 (т.е. от 6 до 15), это означает, что поле опций присутствует и его необходимо учитывать. Список опций может завершаться опцией EOOL (конец списка опций, 0x00); это необходимо только в том случае, если конец опций иначе не совпадал бы с концом заголовка. Возможные варианты, которые можно поместить в шапку, следующие:
В таблице ниже показаны определенные параметры для IPv4. Столбец «Тип опции» формируется из битов «Скопировано», «Класс опции» и «Номер опции», как определено выше. [40]

Данные

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

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

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

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

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

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

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

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

Например, для MTU размером 1500 байт и размера заголовка 20 байт смещения фрагмента будут кратны (0, 185, 370, 555, 740 и т. д.).

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

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

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

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

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

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

Сборка

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

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

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

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

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

Примечания

  1. ^ В качестве первоапрельской шутки предложено для использования в RFC 3514 как « Злой бит » .
  2. ^ Для сетевых технологий IEEE 802 , включая Ethernet , аппаратным адресом является MAC-адрес .

Рекомендации

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

  1. ^ «Отчеты об анализе BGP» . Отчеты BGP . Проверено 9 января 2013 г.
  2. ^ «IPv6 – Google». www.google.com . Проверено 28 января 2022 г.
  3. ^ «Реестр адресов специального назначения IANA IPv4» . www.iana.org . Проверено 28 января 2022 г.
  4. ^ abcdef М. Коттон; Л. Вегода; Б. Хаберман (апрель 2013 г.). Р. Боника (ред.). Реестры IP-адресов специального назначения. IETF . дои : 10.17487/RFC6890 . ISSN  2070-1721. BCP 153. RFC 6890. Лучшая общая практика. Устаревшие RFC 4773, 5156, 5735 и 5736. Обновлено RFC 8190.
  5. ^ «Краткая история IPv4». Группа рынка IPv4 . Проверено 19 августа 2020 г.
  6. ^ «Понимание IP-адресации: все, что вы когда-либо хотели знать» (PDF) . 3Ком. Архивировано из оригинала (PDF) 16 июня 2001 г.
  7. ^ abcd Ю. Рехтер; Б. Московиц; Д. Карренберг; Дж. Дж. де Гроот; Э. Лир (февраль 1996 г.). Распределение адресов для частных сетей Интернет. Сетевая рабочая группа. дои : 10.17487/RFC1918 . БКП 5. RFC 1918. Лучшая общая практика. Устарели RFC 1627 и 1597. Обновлено RFC 6761.
  8. ^ Дж. Вейль; В. Куарсингх; К. Донли; К. Лильенстолпе; М. Азингер (апрель 2012 г.). Префикс IPv4, зарезервированный IANA, для общего адресного пространства. Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC6598 . ISSN  2070-1721. BCP 153. RFC 6598. Лучшая общая практика. Обновления RFC 5735.
  9. ^ С. Чешир; Б. Абоба; Э. Гуттман (май 2005 г.). Динамическая конфигурация локальных адресов каналов IPv4. Сетевая рабочая группа. дои : 10.17487/RFC3927 . РФК 3927. Предлагаемый стандарт.
  10. ^ abc Дж. Аркко; М. Коттон; Л. Вегода (январь 2010 г.). Блоки адресов IPv4 зарезервированы для документации. Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC5737 . ISSN  2070-1721. РФК 5737. Информационный. Обновления RFC 1166.
  11. ^ О. Троан (май 2015 г.). Б. Карпентер (ред.). Устаревший префикс Anycast для ретрансляционных маршрутизаторов 6to4. Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC7526 . BCP 196. RFC 7526. Лучшая современная практика. Устаревшие RFC 3068 и 6732.
  12. ^ К. Хуитема (июнь 2001 г.). Префикс Anycast для релейных маршрутизаторов 6to4. Сетевая рабочая группа. дои : 10.17487/RFC3068 . РФК 3068. Информационный. Устарело согласно RFC 7526.
  13. ^ С. Брэднер; Дж. Маккуэйд (март 1999 г.). Методика сравнительного анализа сетевых межсетевых устройств. Сетевая рабочая группа. дои : 10.17487/RFC2544 . РФК 2544. Информационный. Обновлено: RFC 6201 и RFC 6815.
  14. ^ аб М. Коттон; Л. Вегода; Д. Мейер (март 2010 г.). Рекомендации IANA по назначению адресов многоадресной рассылки IPv4. IETF . дои : 10.17487/RFC5771 . ISSN  2070-1721. BCP 51. RFC 5771. Лучшая общая практика. Устаревшие RFC 3138 и 3171. Обновляет RFC 2780.
  15. ^ С. Венаас; Р. Парех; Г. Ван де Вельде; Т. Чоун; М. Юбэнкс (август 2012 г.). Адреса многоадресной рассылки для документации. Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC6676 . ISSN  2070-1721. РФК 6676. Информационный.
  16. ^ Дж. Рейнольдс , изд. (январь 2002 г.). Присвоенные номера: RFC 1700 заменен онлайновой базой данных. Сетевая рабочая группа. дои : 10.17487/RFC3232 . РФК 3232. Информационный. Устаревший RFC 1700.
  17. ^ Дж. Рейнольдс ; Дж. Постель (октябрь 1984 г.). НАЗНАЧЕННЫЕ НОМЕРА. Сетевая рабочая группа. дои : 10.17487/RFC0923 . РФК 923. Устаревший. Устарело по RFC 943. Устарело по RFC 900. Специальные адреса: в определенных контекстах полезно иметь фиксированные адреса с функциональным значением, а не как идентификаторы конкретных хостов. Когда такое использование требуется, нулевой адрес следует интерпретировать как означающий «это», например «эта сеть».
  18. ^ аб Р. Брейден , изд. (октябрь 1989 г.). Требования к интернет-хостам — коммуникационные уровни. Сетевая рабочая группа. дои : 10.17487/RFC1122 . СТД 3. RFC 1122. Интернет-стандарт 3. Обновлен RFC 1349, 4379, 5884, 6093, 6298, 6633, 6864, 8029 и 9293.
  19. ^ А. Ретана; Р. Уайт; В. Фуллер; Д. Макферсон (декабрь 2000 г.). Использование 31-битных префиксов в каналах IPv4 «точка-точка». Сетевая рабочая группа. дои : 10.17487/RFC3021 . РФК 3021. Предлагаемый стандарт.
  20. ^ Алмквист, Филип; Кастенхольц, Франк (декабрь 1993 г.). «К требованиям к IP-маршрутизаторам». Рабочая группа по интернет-инжинирингу .
  21. ^ П. Алмквист (ноябрь 1994 г.). Ф. Кастенхольц (ред.). К требованиям к IP-маршрутизаторам. Сетевая рабочая группа. дои : 10.17487/RFC1716 . РФК 1716. Устаревший. Устарело согласно RFC 1812.
  22. ^ Ф. Бейкер , изд. (июнь 1995 г.). Требования к маршрутизаторам IP версии 4. Сетевая рабочая группа. дои : 10.17487/RFC1812 . РФК 1812. Предлагаемый стандарт. Устарели RFC 1716 и 1009. Обновлены RFC 2644 и 6633.
  23. ^ «Понимание и настройка команды ip unnumbered» . Циско . Проверено 25 ноября 2021 г.
  24. ^ «В мире заканчиваются интернет-адреса» . Архивировано из оригинала 25 января 2011 г. Проверено 23 января 2011 г.
  25. ^ Смит, Люси; Липнер, Ян (3 февраля 2011 г.). «Свободный пул адресного пространства IPv4 исчерпан». Организация номерного ресурса . Проверено 3 февраля 2011 г.
  26. ^ ICANN, список рассылки nanog. «Пять /8 выделено RIR – нераспределенных одноадресных IPv4 /8 не осталось».
  27. ^ Азиатско-Тихоокеанский сетевой информационный центр (15 апреля 2011 г.). «Пул адресов IPv4 APNIC достиг финального уровня /8» . Архивировано из оригинала 7 августа 2011 года . Проверено 15 апреля 2011 г.
  28. ^ С. Диринг ; Р. Хинден (декабрь 1998 г.). Спецификация Интернет-протокола версии 6 (IPv6). Сетевая рабочая группа. дои : 10.17487/RFC2460 . РФК 2460. Устаревший. Устарело RFC 8200. Устарело RFC 1883. Обновлено RFC 5095, 5722, 5871, 6437, 6564, 6935, 6946, 7045 и 7112.
  29. ^ Р. Финк; Р. Хинден (март 2004 г.). Поэтапное прекращение использования 6bone (распределение адресов тестирования IPv6). Сетевая рабочая группа. дои : 10.17487/RFC3701 . РФК 3701. Информационный. Устаревший RFC 2471.
  30. ^ Международная конференция IEEE 2016 по новым технологиям и инновационным бизнес-практикам для трансформации общества (EmergiTech) . Пискатауэй, Нью-Джерси: Технологический университет Маврикия, Институт инженеров по электротехнике и электронике. Август 2016. ISBN. 9781509007066. ОКЛК  972636788.
  31. ^ Партридж, К.; Кастенхольц, Ф. (декабрь 1994 г.). «6.2 Контрольная сумма IP-заголовка». Технические критерии выбора IP следующего поколения (IPng). п. 26. сек. 6.2. дои : 10.17487/RFC1726 . РФК 1726.
  32. ^ Дж. Постел , изд. (сентябрь 1981 г.). ИНТЕРНЕТ-ПРОТОКОЛ — СПЕЦИФИКАЦИЯ ПРОТОКОЛА ИНТЕРНЕТ-ПРОГРАММЫ DARPA. IETF . дои : 10.17487/RFC0791 . STD 5. RFC 791. IEN 128, 123, 111, 80, 54, 44, 41, 28, 26. Интернет-стандарт 5. Устарел RFC 760. Обновлен RFC 1349, 2474 и 6864.
  33. ^ К. Николс; С. Блейк; Ф. Бейкер ; Д. Блэк (декабрь 1998 г.). Определение поля дифференцированных услуг (поля DS) в заголовках IPv4 и IPv6. Сетевая рабочая группа. дои : 10.17487/RFC2474 . РФК 2474. Предлагаемый стандарт. Устарели RFC 1455 и 1349. Обновлены RFC 3168, 3260 и 8436.
  34. ^ К. Рамакришнан; С. Флойд; Д. Блэк (сентябрь 2001 г.). Добавление явного уведомления о перегрузке (ECN) в IP. Сетевая рабочая группа. дои : 10.17487/RFC3168 . РФК 3168. Предлагаемый стандарт. Устаревший RFC 2481. Обновлены RFC 2474, 2401 и 793. Обновлено RFC 4301, 6040 и 8311.
  35. ^ Сэвидж, Стефан (2000). «Практическая сетевая поддержка обратной трассировки IP». Обзор компьютерных коммуникаций ACM SIGCOMM . 30 (4): 295–306. дои : 10.1145/347057.347560 .
  36. ^ Дж. Тач (февраль 2013 г.). Обновленная спецификация поля идентификатора IPv4. IETF . дои : 10.17487/RFC6864 . ISSN  2070-1721. РФК 6864. Предлагаемый стандарт. Обновления RFC 791, 1122 и 2003.
  37. ^ Бхардвадж, Рашми (04.06.2020). «Смещение фрагмента — IP с легкостью». ipwithease.com . Проверено 21 ноября 2022 г.
  38. ^ Дж. Постель (сентябрь 1981 г.). НАЗНАЧЕННЫЕ НОМЕРА. Сетевая рабочая группа. дои : 10.17487/RFC0790 . РФК 790. Устаревший. Устарело RFC 820. Устарело RFC 776, 770, 762, 758, 755, 750, 739, 604, 503, 433 и 349. Устарело IEN: 127, 117, 93.
  39. ^ «Неофициальные часто задаваемые вопросы по Cisco» . Проверено 10 мая 2012 г.
  40. ^ «Параметры Интернет-протокола версии 4 (IPv4)» .

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