stringtranslate.com

IPv4

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

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

История

Ранние версии TCP/IP были объединенной спецификацией через TCP/IPv3. С IPv4 интернет-протокол стал отдельной спецификацией. [5]

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

Цель

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

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

Адресация

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

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

IPv4 резервирует специальные блоки адресов для частных сетей (2 24  + 2 20  + 2 16  ≈ 18 миллионов адресов) и многоадресных адресов (2 28  ≈ 268 миллионов адресов).

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

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

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

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

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

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

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

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

Разделение существующих классовых сетей на подсети началось в 1985 году с публикацией RFC  950. Это разделение стало более гибким с введением масок подсетей переменной длины (VLSM) в RFC  1109 в 1987 году. В 1993 году на основе этой работы RFC  1517 представил бесклассовую междоменную маршрутизацию (CIDR), [7] которая выражала количество бит (начиная с самого старшего ), например, как /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 создала реализацию под названием Automatic Private IP Addressing (APIPA), которая была развернута на миллионах машин и стала фактическим стандартом . Много лет спустя, в мае 2005 года, IETF определила формальный стандарт в RFC 3927 под названием Dynamic Configuration of IPv4 Link-Local Addresses .

Обратная петля

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

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

Первый адрес в подсети используется для идентификации самой подсети. В этом адресе все биты хоста равны 0. Чтобы избежать неоднозначности в представлении, этот адрес зарезервирован. [18] В последнем адресе все биты хоста установлены в 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 является идентификатором сети и не должен назначаться интерфейсу. [19] : 31  Адреса 192.168.1.0 , 192.168.2.0 и т. д. могут быть назначены, несмотря на то, что они заканчиваются на 0.

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

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

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

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

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

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

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

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

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

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

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

Хронология исчерпания адресов IPv4

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

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


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

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

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

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

Заголовок

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

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

Данные

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

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

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

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

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

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

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

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

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

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

Получатель идентифицирует соответствующие фрагменты, используя адреса источника и назначения, идентификатор протокола и поле идентификации. Получатель повторно собирает данные из фрагментов с тем же идентификатором, используя как смещение фрагмента, так и флаг «больше фрагментов». Когда получатель получает последний фрагмент, у которого флаг « больше фрагментов» установлен на 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) . WikiJournal of Science . doi : 10.15347/WJS/2022.002 . ISSN  2470-6345. OCLC  9708517136. S2CID  254665961. Wikidata  Q104661268.

  1. ^ "Отчеты анализа BGP". Отчеты BGP . Получено 2013-01-09 .
  2. ^ "IPv6 – Google". www.google.com . Получено 2022-01-28 .
  3. ^ "Реестр адресов специального назначения IANA IPv4". www.iana.org . Получено 28.01.2022 .
  4. ^ abcdef М. Коттон; Л. Вегода; Б. Хаберман (апрель 2013 г.). Р. Боника (ред.). Реестры IP-адресов специального назначения. IETF . doi : 10.17487/RFC6890 . ISSN  2070-1721. BCP 153. RFC 6890. Лучшая общепринятая практика. Отменяет RFC 4773, 5156, 5735 и 5736. Обновлено RFC 8190.
  5. ^ Дэвис, Лидия. «Винт Серф — нам еще предстоит подключить 80 процентов мира». The New York Times . Получено 10 мая 2024 г.
  6. ^ "Краткая история IPv4". IPv4 Market Group . Получено 2020-08-19 .
  7. ^ "Понимание IP-адресации: все, что вы когда-либо хотели знать" (PDF) . 3Com. Архивировано из оригинала (PDF) 16 июня 2001 г.
  8. ^ abcd Y. Rekhter; B. Moskowitz; D. Karrenberg; GJ de Groot; E. Lear (февраль 1996 г.). Распределение адресов для частных сетей Интернета. Сетевая рабочая группа. doi : 10.17487/RFC1918 . BCP 5. RFC 1918. Лучшая общепринятая практика. Отменяет RFC 1627 и 1597. Обновлено RFC 6761.
  9. ^ J. Weil; V. Kuarsingh; C. Donley; C. Liljenstolpe; M. Azinger (апрель 2012 г.). Зарезервированный IANA префикс IPv4 для общего адресного пространства. Internet Engineering Task Force . doi : 10.17487/RFC6598 . ISSN  2070-1721. BCP 153. RFC 6598. Лучшая общепринятая практика. Обновления RFC 5735.
  10. ^ S. Cheshire; B. Aboba; E. Guttman (май 2005 г.). Динамическая конфигурация локальных адресов IPv4. Сетевая рабочая группа. doi : 10.17487/RFC3927 . RFC 3927. Предлагаемый стандарт.
  11. ^ abc J. Arkko; M. Cotton; L. Vegoda (январь 2010 г.). Блоки адресов IPv4, зарезервированные для документации. Internet Engineering Task Force . doi : 10.17487/RFC5737 . ISSN  2070-1721. RFC 5737. Информационный. Обновления RFC 1166.
  12. ^ O. Troan (май 2015 г.). B. Carpenter (ред.). Отказ от использования Anycast-префикса для маршрутизаторов 6to4 Relay. Internet Engineering Task Force . doi : 10.17487/RFC7526 . BCP 196. RFC 7526. Лучшая текущая практика. Отменяет RFC 3068 и 6732.
  13. ^ C. Huitema (июнь 2001 г.). Префикс Anycast для маршрутизаторов 6to4 Relay. Сетевая рабочая группа. doi : 10.17487/RFC3068 . RFC 3068. Информационное. Устарело согласно RFC 7526.
  14. ^ S. Bradner; J. McQuaid (март 1999). Методология сравнительного анализа сетевых межсоединительных устройств. Сетевая рабочая группа. doi : 10.17487/RFC2544 . RFC 2544. Информационно. Обновлено: RFC 6201 и RFC 6815.
  15. ^ ab M. Cotton; L. Vegoda; D. Meyer (март 2010 г.). Руководство IANA по назначению адресов многоадресной рассылки IPv4. IETF . doi : 10.17487/RFC5771 . ISSN  2070-1721. BCP 51. RFC 5771. Лучшая общепринятая практика. Отменяет RFC 3138 и 3171. Обновляет RFC 2780.
  16. ^ S. Venaas; R. Parekh; G. Van de Velde; T. Chown; M. Eubanks (август 2012 г.). Многоадресные адреса для документации. Internet Engineering Task Force . doi : 10.17487/RFC6676 . ISSN  2070-1721. RFC 6676. Информационный.
  17. ^ J. Reynolds , ed. (Январь 2002). Присвоенные номера: RFC 1700 заменен онлайновой базой данных. Сетевая рабочая группа. doi : 10.17487/RFC3232 . RFC 3232. Информационный. Устаревший RFC 1700.
  18. ^ J. Reynolds ; J. Postel (октябрь 1984 г.). ПРИСВОЕННЫЕ НОМЕРА. Сетевая рабочая группа. doi : 10.17487/RFC0923 . RFC 923. Устарело. Устарело из-за RFC 943. Устаревший RFC 900. Специальные адреса: В определенных контекстах полезно иметь фиксированные адреса с функциональным значением, а не как идентификаторы конкретных хостов. Когда требуется такое использование, адрес ноль следует интерпретировать как означающий «это», как в «эта сеть».
  19. ^ ab R. Braden , ed. (октябрь 1989). Требования к интернет-хостам — коммуникационные уровни. Сетевая рабочая группа. doi : 10.17487/RFC1122 . STD 3. RFC 1122. Интернет-стандарт 3. Обновлен RFC 1349, 4379, 5884, 6093, 6298, 6633, 6864, 8029 и 9293.
  20. ^ A. Retana; R. White; V. Fuller; D. McPherson (декабрь 2000 г.). Использование 31-битных префиксов в соединениях типа «точка-точка» IPv4. Сетевая рабочая группа. doi : 10.17487/RFC3021 . RFC 3021. Предлагаемый стандарт.
  21. ^ Альмквист, Филипп; Кастенхольц, Франк (декабрь 1993 г.). «К требованиям к IP-маршрутизаторам». Internet Engineering Task Force .
  22. ^ P. Almquist (ноябрь 1994 г.). F. Kastenholz (ред.). Towards Requirements for IP Routers. Сетевая рабочая группа. doi : 10.17487/RFC1716 . RFC 1716. Устарело. Устарело согласно RFC 1812.
  23. ^ Ф. Бейкер , ред. (июнь 1995 г.). Требования к маршрутизаторам IP версии 4. Сетевая рабочая группа. doi : 10.17487/RFC1812 . RFC 1812. Предложенный стандарт. Отменяет RFC 1716 и 1009. Обновлен RFC 2644 и 6633.
  24. ^ "Понимание и настройка команды ip unnumbered". Cisco . Получено 25.11.2021 .
  25. ^ "В мире 'кончились интернет-адреса'". Архивировано из оригинала 2011-01-25 . Получено 2011-01-23 .
  26. ^ Смит, Люси; Липнер, Ян (3 февраля 2011 г.). «Свободный пул адресного пространства IPv4 истощен». Организация ресурсов номеров . Получено 3 февраля 2011 г.
  27. ^ ICANN, список рассылки nanog. «Пять /8 выделены для RIR – нераспределенных IPv4 unicast /8 не осталось».
  28. ^ Азиатско-Тихоокеанский сетевой информационный центр (15 апреля 2011 г.). "APNIC IPv4 Address Pool Reachs Final /8". Архивировано из оригинала 7 августа 2011 г. Получено 15 апреля 2011 г.
  29. ^ S. Deering ; R. Hinden (декабрь 1998 г.). Спецификация протокола Интернета версии 6 (IPv6). Сетевая рабочая группа. doi : 10.17487/RFC2460 . RFC 2460. Устарело. Устарело в соответствии с RFC 8200. Устаревший RFC 1883. Обновлено в соответствии с RFC 5095, 5722, 5871, 6437, 6564, 6935, 6946, 7045 и 7112.
  30. ^ Р. Финк; Р. Хинден (март 2004 г.). Поэтапный отказ от 6bone (распределение тестовых адресов IPv6). Сетевая рабочая группа. doi : 10.17487/RFC3701 . RFC 3701. Информационный. Устаревший RFC 2471.
  31. ^ Международная конференция IEEE 2016 по новым технологиям и инновационным деловым практикам для трансформации обществ (EmergiTech) . Пискатауэй, Нью-Джерси: Технологический университет, Маврикий, Институт инженеров по электротехнике и электронике. Август 2016 г. ISBN 9781509007066. OCLC  972636788.
  32. ^ Партридж, К.; Кастенхольц, Ф. (декабрь 1994 г.). "6.2 Контрольная сумма заголовка IP". Технические критерии выбора IP следующего поколения (IPng). стр. 26. раздел 6.2. doi : 10.17487/RFC1726 . RFC 1726.
  33. ^ J. Postel , ред. (сентябрь 1981 г.). ПРОТОКОЛ ИНТЕРНЕТА - СПЕЦИФИКАЦИЯ ПРОТОКОЛА ПРОГРАММЫ ИНТЕРНЕТА DARPA. IETF . doi : 10.17487/RFC0791 . STD 5. RFC 791. IEN 128, 123, 111, 80, 54, 44, 41, 28, 26. Интернет-стандарт 5. Отменяет действие RFC 760. Обновлен RFC 1349, 2474 и 6864.
  34. ^ К. Николс; С. Блейк; Ф. Бейкер ; Д. Блэк (декабрь 1998 г.). Определение поля дифференцированных услуг (поле DS) в заголовках IPv4 и IPv6. Сетевая рабочая группа. doi : 10.17487/RFC2474 . RFC 2474. Предложенный стандарт. Отменяет RFC 1455 и 1349. Обновлен RFC 3168, 3260 и 8436.
  35. ^ K. Ramakrishnan; S. Floyd; D. Black (сентябрь 2001 г.). Добавление явного уведомления о перегрузке (ECN) к IP. Сетевая рабочая группа. doi : 10.17487/RFC3168 . RFC 3168. Предложенный стандарт. Отменяет RFC 2481. Обновляет RFC 2474, 2401 и 793. Обновлен RFC 4301, 6040 и 8311.
  36. ^ Сэвидж, Стефан (2000). «Практическая сетевая поддержка IP-трассировки». Обзор компьютерной связи ACM SIGCOMM . 30 (4): 295–306. doi : 10.1145/347057.347560 .
  37. ^ J. Touch (февраль 2013 г.). Обновленная спецификация поля идентификатора IPv4. IETF . doi : 10.17487/RFC6864 . ISSN  2070-1721. RFC 6864. Предложенный стандарт. Обновления RFC 791, 1122 и 2003.
  38. ^ Бхардвадж, Рашми (2020-06-04). "Fragment Offset - IP With Ease". ipwithease.com . Получено 2022-11-21 .
  39. ^ J. Postel (сентябрь 1981 г.). НАЗНАЧЕННЫЕ НОМЕРА. Сетевая рабочая группа. doi : 10.17487/RFC0790 . RFC 790. Устаревший. Устарело RFC 820. Устарело RFC 776, 770, 762, 758, 755, 750, 739, 604, 503, 433 и 349. Устарело IEN: 127, 117, 93.
  40. ^ "Cisco неофициальный FAQ" . Получено 2012-05-10 .
  41. ^ «Параметры интернет-протокола версии 4 (IPv4)».

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