✖
~~~~~~~~~~~~~~~~~~~~ Arc.Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~ 
Номер скриншота №:
✰ 08621F17E057941BA430A07464955039__1718683080 ✰
Заголовок документа оригинал.:
✰ IPv4 - Wikipedia ✰
Заголовок документа перевод.:
✰ IPv4 — Википедия ✰
Снимок документа находящегося по адресу (URL):
✰ https://en.wikipedia.org/wiki/IPv4 ✰
Адрес хранения снимка оригинал (URL):
✰ https://arc.ask3.ru/arc/aa/08/39/08621f17e057941ba430a07464955039.html ✰
Адрес хранения снимка перевод (URL):
✰ https://arc.ask3.ru/arc/aa/08/39/08621f17e057941ba430a07464955039__translat.html ✰
Дата и время сохранения документа:
✰ 21.06.2024 04:00:56 (GMT+3, MSK) ✰
Дата и время изменения документа (по данным источника):
✰ 18 June 2024, at 06:58 (UTC). ✰ 

~~~~~~~~~~~~~~~~~~~~~~ Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~~ 
Сервисы Ask3.ru: 
 Архив документов (Снимки документов, в формате HTML, PDF, PNG - подписанные ЭЦП, доказывающие существование документа в момент подписи. Перевод сохраненных документов на русский язык.) 
✰ https://arc.ask3.ru ✰
 Ответы на вопросы (Сервис ответов на вопросы, в основном, научной направленности) 
✰ https://ask3.ru/answer2question ✰
 Товарный сопоставитель (Сервис сравнения и выбора товаров) ✰✰
✰ https://ask3.ru/product2collation ✰
 Партнеры 
✰ https://comrades.ask3.ru ✰


Совет. Чтобы искать на странице, нажмите Ctrl+F или ⌘-F (для MacOS) и введите запрос в поле поиска.
Arc.Ask3.ru: далее начало оригинального документа

IPv4 — Википедия Jump to content

IPv4

Эта статья была опубликована в рецензируемом журнале WikiJournal of Science (2022). Нажмите, чтобы просмотреть опубликованную версию.
Из Википедии, бесплатной энциклопедии
Интернет-протокол версии 4
Стек протоколов
IPv4-пакет
Сокращение IPv4
Цель Межсетевой протокол
Разработчики) ДАРПА
Введение 1981 год ; 43 года назад ( 1981 )
Под влиянием IPv6
Уровень OSI Сетевой уровень
RFC(ы) 791
Набор интернет-протоколов
Прикладной уровень
Транспортный уровень
Интернет-слой
Слой связи

Интернет-протокол версии 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).

Адресация [ править ]

Для более широкого освещения этой темы см. IP-адрес .
Разложение представления адреса 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 объединяет адрес с его префиксом маршрутизации в компактном формате, в котором за адресом следует косая черта (/) и количество ведущих последовательных битов 1 в префиксе маршрутизации (маске подсети).

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

Распределение [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

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

Петлевая обратная связь [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

Разрешение адреса [ править ]

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

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

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

Ненумерованный интерфейс [ править ]

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

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

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

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

Основная статья: исчерпание адресов IPv4
График исчерпания 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 году, в 2006 году началось постоянное официальное развертывание IPv6. [30] Ожидается, что завершение развертывания IPv6 займет значительное время. [31] поэтому необходимы технологии промежуточного перехода , чтобы позволить хостам участвовать в Интернете, используя обе версии протокола.

Структура пакета [ править ]

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

Заголовок [ править ]

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

Формат заголовка IPv4
Смещения Октет 0 1 2 3
Октет Кусочек 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Версия МГП ДСКП ECN Общая длина
4 32 Идентификация Флаги Смещение фрагмента
8 64 Время жить Протокол Контрольная сумма заголовка
12 96 Адрес источника
16 128 Адрес назначения
20 160 Варианты (если МГП > 5)
⋮ ⋮
56 448
Версия
Первое поле заголовка в IP- пакете — это четырехбитное поле версии. Для IPv4 это всегда равно 4.
Длина интернет-заголовка (IHL)
Заголовок IPv4 имеет переменный размер из-за необязательного 14-го поля (параметры). Поле IHL содержит размер заголовка IPv4; он имеет 4 бита, которые определяют количество 32-битных слов в заголовке. Минимальное значение для этого поля — 5, [33] что указывает на длину 5 × 32 бит = 160 бит = 20 байт. Для 4-битного поля максимальное значение равно 15; это означает, что максимальный размер заголовка IPv4 составляет 15 × 32 бита = 480 бит = 60 байт.
Кодовая точка дифференцированных услуг ( ДСКП )
определялось как тип услуги Первоначально это поле (ToS), но теперь оно определяет дифференцированные услуги (DiffServ). [34] Потоковая передача данных в реальном времени использует поле DSCP. Примером является передача голоса по IP (VoIP), которая используется для интерактивных голосовых услуг.
Явное уведомление о перегрузке ( ECN )
Это поле позволяет осуществлять сквозное уведомление о перегрузке сети без потери пакетов . [35] ECN — это дополнительная функция, доступная, если ее поддерживают обе конечные точки, и эффективная, если она также поддерживается базовой сетью.
Общая длина
Это 16-битное поле определяет размер всего пакета в байтах, включая заголовок и данные. Минимальный размер — 20 байт (заголовок без данных), максимальный — 65 535 байт. Все хосты должны иметь возможность собирать датаграммы размером до 576 байт, но большинство современных хостов обрабатывают пакеты гораздо большего размера. Каналы могут накладывать дополнительные ограничения на размер пакета, и в этом случае дейтаграммы должны быть фрагментированы . Фрагментация в IPv4 выполняется либо на отправляющем хосте, либо на маршрутизаторах. Обратная сборка выполняется на принимающем хосте.
Идентификация
Это поле является полем идентификации и в основном используется для уникальной идентификации группы фрагментов одной IP-дейтаграммы. В некоторых экспериментальных работах предлагалось использовать поле ID для других целей, например, для добавления информации о отслеживании пакетов, чтобы помочь отслеживать датаграммы с поддельными адресами источника. [36] но любое такое использование теперь запрещено. [37]
Флаги
Далее следует трехбитовое поле, которое используется для управления или идентификации фрагментов. Это (в порядке от наиболее значимого к наименее значимому):
  • бит 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. [38] Таким образом, 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-протоколов . [39]
Контрольная сумма заголовка
16-битное поле контрольной суммы заголовка IPv4 используется для проверки заголовка на наличие ошибок. Когда пакет поступает на маршрутизатор или в пункт назначения, сетевое устройство вычисляет контрольную сумму заголовка, включая поле контрольной суммы. Ожидается значение 0xFFFF. Если получен другой результат, устройство отбрасывает пакет. Ошибки в части данных пакета обрабатываются отдельно с помощью инкапсулированного протокола. И UDP , и TCP имеют отдельные контрольные суммы, которые применяются к их данным.
Когда пакет поступает на маршрутизатор, маршрутизатор уменьшает поле TTL в заголовке. Следовательно, маршрутизатор должен вычислить новую контрольную сумму заголовка.
Поле контрольной суммы представляет собой 16-битное дополнение суммы всех 16-битных слов в заголовке. Для расчета контрольной суммы значение поля контрольной суммы равно нулю.
Адрес источника
Это 32-битное поле представляет собой IPv4-адрес отправителя пакета. Его можно изменить при передаче с помощью трансляции сетевых адресов (NAT).
Адрес назначения
Это 32-битное поле представляет собой IPv4-адрес получателя пакета. На это может влиять NAT.
Параметры
используется Поле опций не часто. Пакеты, содержащие некоторые параметры, могут рассматриваться некоторыми маршрутизаторами как опасные и блокироваться. [40] Значение в поле IHL должно включать достаточное количество дополнительных 32-битных слов для хранения всех опций и любого заполнения, необходимого для обеспечения того, чтобы заголовок содержал целое число 32-битных слов. Если IHL больше 5 (т.е. от 6 до 15), это означает, что поле опций присутствует и его необходимо учитывать. Список опций может завершаться опцией EOOL (конец списка опций, 0x00); это необходимо только в том случае, если конец опций иначе не совпадал бы с концом заголовка.
Поскольку большинство параметров IP включают спецификации, сколько или какие промежуточные устройства должен пройти пакет, параметры IP не используются для связи через Интернет, и пакеты IP, включая некоторые параметры IP, должны отбрасываться в соответствии с оценкой безопасности IPv4 RFC6274, поскольку они может раскрыть топологию сети или детали сети.
Возможные варианты, которые можно поместить в шапку, следующие:
Поле Размер (бит) Описание
Скопировано 1 Установите значение 1, если параметры необходимо скопировать во все фрагменты фрагментированного пакета.
Класс опции 2 Общая категория опций. 0 — для опций управления , а 2 — для отладки и измерения . 1 и 3 зарезервированы.
Номер опции 5 Указывает параметр.
Длина опции 8 Указывает размер всей опции (включая это поле). Это поле может отсутствовать для простых опций.
Данные опции Переменная Данные, специфичные для опции. Это поле может отсутствовать для простых опций.
В таблице ниже показаны определенные параметры для IPv4. Столбец «Тип опции» формируется из битов «Скопировано», «Класс опции» и «Номер опции», как определено выше. [41]
Тип опции (десятичный/шестнадцатеричный) Название опции Описание
0/0x00 ЕОЛ Конец списка опций
1/0x01 НЕТ Нет операции
2/0x02 SEC Безопасность (несуществующая)
7/0x07 RR Запись маршрута
10/0x0А ЗСУ Экспериментальное измерение
11/0x0B МТУП MAN Зонд
12/0x0C МТУР MAN Ответить
15/0x0F КОДИРОВАТЬ КОДИРОВАТЬ
25/0x19 КО Быстрый старт
30/0x1E Опыт Эксперимент в стиле RFC3692
68/0x44 ТС Временная отметка
82/0x52 ТР Трассировка
94/0x5E Опыт Эксперимент в стиле RFC3692
130/0x82 SEC Безопасность (РИПСО)
131/0x83 ЛСР Свободный исходный маршрут
133/0x85 Э-СЕК Расширенная безопасность (RIPSO)
134/0x86 СИПСО Вариант коммерческой IP-безопасности
136/0x88 SID Идентификатор потока
137/0x89 ССР Строгий исходный маршрут
142/0x8E ВИЗА Экспериментальный контроль доступа
144/0x90 ИМИТД Дескриптор трафика IMI
145/0x91 ЭИП Расширенный интернет-протокол
147/0x93 ДОБАВИТЬ Расширение адреса
148/0x94 РТРАЛТ Оповещение маршрутизатора
149/0x95 СКБ Избирательное направленное вещание
151/0x97 ДПС Динамическое состояние пакета
152/0x98 УМЗ Восходящий многоадресный пакет
158/0x9E Опыт Эксперимент в стиле RFC3692
205/0xCD ФИНН Экспериментальное управление потоком
222/0xDE Опыт Эксперимент в стиле RFC3692

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

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

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

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

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

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

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

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

Фрагментация [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

Сборка [ править ]

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

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

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

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

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

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

Retrieved from "https://en.wikipedia.org/w/index.php?title=IPv4&oldid=1229697011"
Arc.Ask3.Ru: конец оригинального документа.
Arc.Ask3.Ru
Номер скриншота №: 08621F17E057941BA430A07464955039__1718683080
URL1:https://en.wikipedia.org/wiki/IPv4
Заголовок, (Title) документа по адресу, URL1:
IPv4 - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть, любые претензии не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, денежную единицу можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)