IPv6-адрес

Метка для идентификации сетевого интерфейса компьютера или другого сетевого узла.

Разложение адреса IPv6 в двоичную форму

Адрес протокола Интернета версии 6 ( адрес IPv6 ) — это числовая метка, которая используется для идентификации и определения местоположения сетевого интерфейса компьютера или сетевого узла , участвующего в компьютерной сети с использованием IPv6 . IP-адреса включаются в заголовок пакета для указания источника и пункта назначения каждого пакета. IP-адрес пункта назначения используется для принятия решений о маршрутизации IP-пакетов в другие сети.

IPv6 является преемником первой адресной инфраструктуры Интернета , Интернет -протокола версии 4 (IPv4). В отличие от IPv4, который определял IP-адрес как 32-битное значение, адреса IPv6 имеют размер 128 бит. Поэтому, по сравнению с ним, IPv6 имеет значительно увеличенное адресное пространство .

Методы адресации

Адреса IPv6 классифицируются по основным методам адресации и маршрутизации, распространенным в сетях: одноадресная адресация, произвольная адресация и многоадресная адресация. ^[1]

Адрес unicast идентифицирует один сетевой интерфейс. Интернет-протокол доставляет пакеты, отправленные на адрес unicast, на этот конкретный интерфейс.

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

Многоадресный адрес также используется несколькими хостами, которые получают многоадресный адрес назначения, участвуя в протоколе многоадресного распределения среди сетевых маршрутизаторов. Пакет, отправленный на многоадресный адрес , доставляется на все интерфейсы, которые присоединились к соответствующей многоадресной группе. IPv6 не реализует широковещательную адресацию . Традиционная роль широковещательной рассылки сводится к многоадресной адресации для многоадресной группы all-nodes link-local ff02::1 . Однако использование группы all-nodes не рекомендуется, и большинство протоколов IPv6 используют многоадресные группы link-local, специфичные для протокола, чтобы не мешать каждому интерфейсу в данной сети.

Форматы адреса

Адрес IPv6 состоит из 128 бит. ^[1] Для каждой из основных методологий адресации и маршрутизации распознаются различные форматы адресов путем деления 128 бит адреса на группы бит и использования установленных правил для связывания значений этих групп бит со специальными функциями адресации.

Формат адреса Unicast и Anycast

Адреса Unicast и Anycast обычно состоят из двух логических частей: 64-битного сетевого префикса, используемого для маршрутизации , и 64-битного идентификатора интерфейса, используемого для идентификации сетевого интерфейса хоста.

Сетевой префикс ( префикс маршрутизации в сочетании с идентификатором подсети ) содержится в самых значимых 64 битах адреса. Размер префикса маршрутизации может варьироваться; больший размер префикса означает меньший размер идентификатора подсети. Биты поля идентификатора подсети доступны сетевому администратору для определения подсетей в данной сети. 64-битный идентификатор интерфейса автоматически устанавливается случайным образом, получается с сервера DHCPv6 или назначается вручную. (Исторически он автоматически генерировался из MAC-адреса интерфейса с использованием модифицированного формата EUI-64 , но этот метод теперь не рекомендуется из соображений конфиденциальности. ^[2] )

Уникальные локальные адреса — это адреса, аналогичные частным сетевым адресам IPv4.

Поле префикса содержит двоичное значение 1111110. Бит L равен единице для локально назначенных адресов; диапазон адресов с L, установленным на ноль, в настоящее время не определен. Случайное поле выбирается случайным образом один раз, в начале префикса маршрутизации / 48 .

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

Поле префикса содержит двоичное значение 1111111010. Следующие 54 нуля делают общий сетевой префикс одинаковым для всех локальных адресов связи ( префикс локального адреса связи fe80:: / 64 ), что делает их немаршрутизируемыми.

Формат многоадресного адреса

Многоадресные адреса формируются в соответствии с несколькими конкретными правилами форматирования в зависимости от приложения.

Для всех многоадресных адресов поле префикса содержит двоичное значение 11111111.

В настоящее время определены три из четырех битов флага в поле flg ; ^[1] старший бит флага зарезервирован для будущего использования.

Четырехбитное поле области действия ( sc ) используется для указания того, где адрес является действительным и уникальным.

Кроме того, поле области действия используется для идентификации специальных многоадресных адресов, таких как запрошенный узел .

Поле sc(ope) содержит двоичное значение 0010 (link-local). Адреса многоадресной рассылки запрошенного узла вычисляются как функция адресов одноадресной рассылки или произвольной рассылки узла. Адрес многоадресной рассылки запрошенного узла создается путем копирования последних 24 бит адреса одноадресной рассылки или произвольной рассылки в последние 24 бита адреса многоадресной рассылки.

Многоадресные адреса в области ссылок используют сопоставимый формат. ^[6]

Представление

Адрес IPv6 представлен в виде восьми групп по четыре шестнадцатеричных цифры, каждая группа представляет 16 бит ^[a] Группы разделены двоеточиями (:). Пример адреса IPv6:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

Стандарты обеспечивают гибкость в представлении адресов IPv6. Полное представление восьми четырехзначных групп может быть упрощено несколькими методами, исключающими части представления. В целом, представления сокращаются настолько, насколько это возможно. Однако эта практика усложняет несколько общих операций, а именно поиск определенного адреса или шаблона адреса в текстовых документах или потоках и сравнение адресов для определения эквивалентности. Для смягчения этих осложнений IETF определил канонический формат для отображения адресов IPv6 в тексте: ^[9]

• Шестнадцатеричные цифры всегда сравниваются без учета регистра, но рекомендации IETF предполагают использование только строчных букв. Например, 2001:db8::1 предпочтительнее, чем 2001:DB8::1 ;
• Начальные нули в каждом 16-битном поле подавляются, но каждая группа должна сохранить по крайней мере одну цифру. Например, 2001:0db8::0001:0000 отображается как 2001:db8::1:0 ;
• Самая длинная последовательность полей, состоящих из одних нулей, заменяется двумя двоеточиями ( :: ). Если адрес содержит несколько серий полей, состоящих из одних нулей, одинакового размера, то для предотвращения неоднозначностей сжимается самое левое поле. Например, 2001:db8:0:0:1:0:0:1 отображается как 2001:db8::1:0:0:1, а не как 2001:db8:0:0:1::1 . :: не используется для представления только одного поля, состоящего из одних нулей. Например, 2001:db8:0:0:0:0:2:1 сокращается до 2001:db8::2:1 , но 2001:db8:0000:1:1:1:1:1 отображается как 2001:db8:0:1:1:1:1:1 .

Эти методы могут привести к очень коротким представлениям для адресов IPv6. Например, адрес localhost (loopback), 0:0:0:0:0:0:0:1 , и неопределенный адрес IPv6, 0:0:0:0:0:0:0:0:0 , сокращаются до ::1 и :: соответственно.

При переходе Интернета с IPv4 на IPv6 типично работать в среде смешанной адресации. Для таких случаев использования была введена специальная нотация, которая выражает IPv4-отображенные и IPv4-совместимые адреса IPv6 путем записи наименее значимых 32 бит адреса в привычной точечно-десятичной нотации IPv4 , тогда как 96 наиболее значимых бит записываются в формате IPv6. Например, IPv4-отображенный адрес IPv6 ::ffff:c000:0280 записывается как ::ffff:192.0.2.128 , таким образом четко выражая исходный адрес IPv4, который был сопоставлен с IPv6.

Сети

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

Диапазоны сетевых адресов записываются в нотации CIDR . Сеть обозначается первым адресом в блоке (заканчивающимся всеми нулями), косой чертой (/) и десятичным значением, равным размеру префикса в битах. Например, сеть, записанная как 2001:db8:1234:: / 48, начинается с адреса 2001:db8:1234:0000:0000:0000:0000:0000 и заканчивается на 2001:db8:1234:ffff:ffff:ffff:ffff:ffff .

Префикс маршрутизации адреса интерфейса может быть указан непосредственно с адресом с использованием нотации CIDR. Например, конфигурация интерфейса с адресом 2001:db8:a::123, подключенного к подсети 2001:db8:a:: / 64, записывается как 2001:db8:a::123 / 64 .

Размеры адресных блоков

Размер блока адресов указывается путем записи слэша (/) с последующим числом в десятичной системе счисления, значение которого является длиной сетевого префикса в битах. Например, блок адресов с 48 битами в префиксе обозначается как / 48 . Такой блок содержит 2 ^{128 − 48} = 2 ⁸⁰ адресов. Чем меньше длина сетевого префикса, тем больше блок: блок / 21 в 8 раз больше блока / 24 .

Буквальные адреса IPv6 в идентификаторах сетевых ресурсов

Символы двоеточия (:) в адресах IPv6 могут конфликтовать с установленным синтаксисом идентификаторов ресурсов, таких как URI и URL . Двоеточие традиционно используется для завершения пути к хосту перед номером порта . ^[10] Чтобы устранить этот конфликт, буквальные адреса IPv6 заключаются в квадратные скобки в таких идентификаторах ресурсов, например:

http://[2001:db8:85a3:8d3:1319:8a2e:370:7348]/

Если URL также содержит номер порта, запись выглядит следующим образом:

https://[2001:db8:85a3:8d3:1319:8a2e:370:7348]:443/

где конечный 443 — это номер порта примера.

Ограниченные буквальные адреса IPv6 (с индексом зоны)

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

Для того чтобы разрешить неоднозначность в текстовых адресах,Индекс зоны должен быть добавлен к адресу. Индекс зоны отделяется от адреса знакомпроцента(%).^[11]Хотя числовые индексы зоны должны поддерживаться повсеместно, индекс зоны может также быть строкой, зависящей от реализации. Адрес локальной ссылки

fe80::1ff:fe23:4567:890a

может быть выражено

fe80::1ff:fe23:4567:890a%eth2 ^[б]

или

fe80::1ff:fe23:4567:890a%3

Первый вариант (использование имени интерфейса ) является общепринятым в большинстве Unix -подобных операционных систем (например, BSD , Linux , macOS ). ^[12] Последний вариант (использование номера интерфейса) является единственным синтаксисом в Microsoft Windows , но поскольку поддержка этого синтаксиса является обязательной по стандарту, он также доступен в других операционных системах. ^[c]

Операционные системы на базе BSD (включая macOS) также поддерживают альтернативный, нестандартный синтаксис, где числовой индекс зоны кодируется во втором 16-битном слове адреса. Например:

fe80:3::1ff:fe23:4567:890a

Во всех операционных системах, упомянутых выше, индекс зоны для локальных адресов ссылок фактически относится к интерфейсу, а не к зоне. Поскольку несколько интерфейсов могут принадлежать к одной и той же зоне (например, при подключении к одной и той же сети), на практике два адреса с разными идентификаторами зон могут быть фактически эквивалентны и ссылаться на один и тот же хост на одной и той же ссылке. ^[d]

При использовании в унифицированных идентификаторах ресурсов (URI) использование знака процента приводит к синтаксическому конфликту, поэтому его необходимо экранировать с помощью процентного кодирования , ^[13] например:

http://[fe80::1ff:fe23:4567:890a %25 eth0]/

Буквальные адреса IPv6 в именах путей UNC

В операционных системах Microsoft Windows адреса IPv4 являются допустимыми идентификаторами местоположений в именах путей Uniform Naming Convention (UNC). Однако двоеточие является недопустимым символом в имени пути UNC. Таким образом, использование адресов IPv6 также является недопустимым в именах UNC. По этой причине Microsoft реализовала алгоритм транскрипции для представления адреса IPv6 в форме доменного имени, которое может использоваться в путях UNC. Для этой цели Microsoft зарегистрировала и зарезервировала домен второго уровня ipv6-literal.net в Интернете (хотя они отказались от домена в январе 2014 года ^[14] ). Адреса IPv6 транскрибируются как имя хоста или имя поддомена в этом пространстве имен следующим образом:

2001:db8:85a3:8d3:1319:8a2e:370:7348

пишется как

2001-db8-85a3-8d3-1319-8a2e-370-7348.ipv6-literal.net

Эта нотация автоматически разрешается локально программным обеспечением Microsoft, без каких-либо запросов к серверам имен DNS.

Если адрес IPv6 содержит индекс зоны, он добавляется к части адреса после символа «s»:

fe80::1ff:fe23:4567:890a%3

пишется как

fe80--1ff-fe23-4567-890a s3 .ipv6-literal.net

Области действия адреса

Каждый адрес IPv6, за исключением неопределенного адреса ( :: ), имеет область действия ^[11] , которая определяет , в какой части сети он действителен.

Одноадресная передача

Для одноадресных адресов определены две области действия: локальная для канала и глобальная.

Адреса Link-local и адрес loopback имеют область действия link-local , что означает, что они могут использоваться только в одной напрямую подключенной сети. Все остальные адреса (включая уникальные локальные адреса ) имеют глобальную (или универсальную ) область действия, что означает, что они потенциально маршрутизируемы глобально и могут использоваться для подключения к адресам с глобальной областью действия в любом месте или к адресам с областью действия link-local в напрямую подключенной сети.

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

Anycast

Адреса anycast синтаксически идентичны и неотличимы от адресов unicast. Единственное их отличие — административное. Поэтому области действия адресов anycast такие же, как и для адресов unicast.

Многоадресная передача

Для многоадресных адресов четыре младших бита второго октета адреса ( ff0 s :: ) определяют адрес s , т.е. домен, в котором должен распространяться многоадресный пакет. Предопределенные и зарезервированные области действия:

Все остальные области не назначены и доступны администраторам для определения дополнительных регионов.

Адресное пространство

Общее распределение

Управление процессом распределения адресов IPv6 делегировано Internet Assigned Numbers Authority (IANA) ^[16] Советом по архитектуре Интернета и Руководящей группой по инжинирингу Интернета . Его основная функция — распределение больших блоков адресов региональным интернет-регистраторам (RIR), которым делегирована задача распределения поставщикам сетевых услуг и другим локальным регистраторам. IANA ведет официальный список распределения адресного пространства IPv6 с декабря 1995 года. ^[17]

Для того, чтобы обеспечить эффективное агрегирование маршрутов , тем самым уменьшая размер таблиц маршрутизации Интернета, только одна восьмая часть общего адресного пространства ( 2000:: / 3 ) в настоящее время выделяется для использования в Интернете . Остальная часть адресного пространства IPv6 зарезервирована для будущего использования или для специальных целей. Адресное пространство назначается RIR блоками от / 23 до / 12 . ^[18]

RIR назначают меньшие блоки локальным интернет-реестрам , которые распределяют их среди пользователей. Обычно они имеют размеры от / 19 до / 32 . ^{[19] [20] [21]} Глобальные записи назначения одноадресной рассылки можно найти на различных RIR или других веб-сайтах. ^[22]

Затем адреса обычно распределяются между конечными пользователями блоками размером от / 48 до / 56. ^[23] Адреса IPv6 назначаются организациям гораздо большими блоками по сравнению с назначением адресов IPv4 — рекомендуемое распределение — это блок / 48 , содержащий 2 ⁸⁰ адресов, что составляет 2 ⁴⁸ или около того.В 2,8 × 10 ¹⁴ раз больше, чем все адресное пространство IPv4 из 2 ³² адресов и примерно7,2 × 10 ¹⁶ раз больше, чем / 8 блоков адресов IPv4, которые являются крупнейшими распределениями адресов IPv4. Однако общий пул достаточен для обозримого будущего, поскольку их 2 ¹²⁸ (ровно 340 282 366 920 938 463 463 374 607 431 768 211 456) или около3,4 × 1038 ⁽ 340 ундециллионов ) уникальных адресов IPv6.

Каждый RIR может разделить каждый из своих множественных / 23 блоков на 512 / 32 блоков, как правило, по одному для каждого ISP; ISP может разделить свой / 32 блок на 65 536 / 48 блоков, как правило, по одному для каждого клиента; ^[24] клиенты могут создать 65 536 / 64 сетей из своего назначенного / 48 блока, каждый из которых будет иметь 2 ⁶⁴ (18 446 744 073 709 551 616) адресов. Напротив, все адресное пространство IPv4 имеет только 2 ³² (ровно 4 294 967 296 или около4,3 × 10 ⁹ ) адресов.

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

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

Провайдер-независимое адресное пространство назначается непосредственно конечному пользователю региональными интернет-регистраторами из специального диапазона 2001:678:: / 29 и позволяет клиентам менять провайдера без перенумерации своих сетей.

Точкам обмена интернет-трафиком (IXP) назначаются специальные адреса из диапазонов 2001:7f8:: / 32 , 2001:504:: / 30 и 2001:7fa:: / 32 ^[25] для связи с подключенными к ним интернет-провайдерами .

Корневым серверам имен были назначены адреса из диапазона 2001:7f8:: / 29. ^[26 ]

Зарезервированные адреса anycast

Самый низкий адрес в каждом префиксе подсети (идентификатор интерфейса, установленный на все нули) зарезервирован как адрес произвольной рассылки подсети-маршрутизатора . ^[1] Приложения могут использовать этот адрес при обращении к любому из доступных маршрутизаторов, поскольку пакеты, отправленные на этот адрес, доставляются только одному маршрутизатору.

128 самых высоких адресов в каждом префиксе подсети / 64 зарезервированы для использования в качестве адресов anycast. ^[27] Обычно эти адреса имеют первые 57 бит идентификатора интерфейса, установленные на 1, за которыми следует 7-битный идентификатор anycast. Префиксы для сети могут иметь любую длину для целей маршрутизации, но подсети должны иметь длину 64 бита. Адрес со значением 0x7e в 7 младших битах определяется как адрес anycast мобильных домашних агентов IPv6. Адрес со значением 0x7f (все биты 1) зарезервирован и не может использоваться. Больше никаких назначений из этого диапазона не было сделано, поэтому все оставшиеся значения, от 0x00 до 0x7d, также зарезервированы.

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

В IPv6 есть ряд адресов, имеющих особое значение. ^[28] IANA ведет реестр этих адресов специального назначения. ^[29] Они составляют менее 2% всего адресного пространства:

Адреса Unicast

Неуказанный адрес

• :: / 128  – Адрес со всеми нулевыми битами называетсянеуказанным адресом(соответствует 0.0.0.0 / 32 в IPv4). Этот адрес никогда не должен назначаться интерфейсу и должен использоваться только в программном обеспечении до того, как приложение узнает исходный адрес своего хоста, подходящий для ожидающего соединения. Маршрутизаторы не должны пересылать пакеты с неуказанным адресом.

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

В конфигурации таблицы маршрутизации неуказанный адрес может использоваться для представления адреса маршрута по умолчанию (соответствующего 0.0.0.0 / 0 в IPv4) для адресов назначения (одноадресных, многоадресных и других), не указанных в другом месте таблицы маршрутизации.

Местные адреса

• ::1 / 128  –обратной связиявляетсялокального хоста. Этот адрес соответствует 127.0.0.1 / 8 в IPv4.
  Если приложение на хосте отправляет пакеты на этот адрес, стек IPv6 закольцовывает эти пакеты на тот же виртуальный интерфейс.
• fe80:: / 10  — адреса в префиксе link-local действительны и уникальны только в локальной подсети. Этот диапазон адресов сопоставим с адресами автоконфигурации 169.254.0.0 / 16 IPv4.
  В этом префиксевыделяется только одна подсеть / 64 (имеется 54 нулевых бита), что дает эффективный формат fe80:: / 64 . Наименее значимые 64 бита ранее выбирались в качестве аппаратного адреса интерфейса, созданного визмененном формате EUI-64, но теперь являются псевдослучайными значениями для обеспечения конфиденциальности.Локальный адрестребуется для каждого интерфейса с поддержкой IPv6, и приложения могут полагаться на существование локального адреса даже при отсутствии маршрутизации IPv6.

Уникальные локальные адреса

• fc00:: / 7 —Уникальные локальные адреса(ULA) предназначены для локальной связи^[39](сравнимые счастными адресами IPv4 10.0.0.0 / 8 , 172.16.0.0 / 12 и 192.168.0.0 / 16 ).
  Они маршрутизируются только в пределах набора взаимодействующих сайтов. Блок разделен на две половины. Нижняя половина блока ( fc00:: / 8 ) была предназначена для глобально выделенных префиксов, но метод выделения еще не определен. Верхняя половина ( fd00:: / 8 ) используется длявероятностно уникальныхадресов, в которых префикс / 8 объединяется с 40-битным локально сгенерированнымпсевдослучайнымчислом для получениячастного префикса / 48 . Процедура выбора 40-битного числа приводит к незначительной вероятности того, что два сайта, которые хотят объединиться или взаимодействовать, столкнутся с коллизиями адресов, но могут использовать один и тот жепрефикс / 48. ^[39]

Переход с IPv4

• ::ffff:0:0 / 96 — Этот префикс используется длямеханизмов перехода IPv6и обозначается какIPv4-отображенный адрес IPv6.
  За некоторыми исключениями, этот тип адреса позволяет прозрачно использовать протоколытранспортного уровняповерх IPv4 через сетевойинтерфейс программирования приложений. В этойс двойным стекомсерверным приложениям нужно открыть только один прослушивающийсокетдля обработки подключений от клиентов, использующих протоколы IPv6 или IPv4. Клиенты IPv6 обрабатываются изначально, а клиенты IPv4 отображаются как клиенты IPv6 по их IPv4-отображенному адресу IPv6. Передача обрабатывается аналогично; установленные сокеты могут использоваться для передачи датаграммы IPv4 или IPv6 на основе привязки к адресу IPv6 или IPv4-отображенному адресу.
• ::ffff:0:0:0 / 96 — Префикс, используемый дляIPv4-транслируемых адресов. Они используются протоколомStateless IP/ICMP Translation (SIIT).^[40]
• 64:ff9b:: / 96 —Известный префикс. Адреса с этим префиксом используются для автоматического преобразования IPv4/IPv6.^[30]
• 64:ff9b:1:: / 48 — Префикс для локально транслируемых адресов IPv4/IPv6. Адреса с этим префиксом могут использоваться для нескольких механизмов трансляции IPv4/IPv6, таких какNAT64иSIIT.^[31]По сравнению с 64:ff9b:: / 96 , эти адреса содержат транслируемый адрес IPv4 в позициях 48-63 и 72-87.^[30]Это означает, что для каждого адреса IPv4 устройству назначается префикс IPv6 / 88. Это позволяет использовать его в тех же случаях, что и 6to4, когда один публичный адрес IPv4 транслируется в префикс. Таким образом, требуется только один уровень NAT, и устройствам не нужно выполнять NAT66 внутри, если им нужны дополнительные адреса, например, дляинтерфейсовP2Pконтейнеров Docker.
• 2002:: / 16 — Этот префикс использовался для6to4также использовалсяпрефикс из сети IPv4, 192.88.99.0 / 24
  ). Схема адресации 6to4 устарела.^[36]

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

IANA зарезервировала так называемый блок адресов Sub-TLA ID для специальных назначений ^{[28] [41]} 2001 :: / 23 (разделенный на диапазон из 64 сетевых префиксов 2001:0000:: / 29 по 2001:01f8:: / 29 ). В настоящее время выделены три назначения из этого блока:

• 2001:: / 32 — Используется длятуннелирования Teredo,механизма перехода IPv6.
• 2001:2:: / 48 — Используется длясравнительного анализаIPv6. Соответствует 198.18.0.0 / 15, используемому для сравнительного анализа IPv4. Назначен рабочей группе по методологии сравнительного анализа (BMWG).^[42]
• 2001:20:: / 28 — Overlay Routable Cryptographic Hash Identifiers (ORCHIDv2).^[34]Это немаршрутизируемые адреса IPv6, используемые для Cryptographic Hash Identifiers.

Документация

• 2001:db8:: / 32 — Этот префикс используется в документации^[35][e]Адреса следует использовать везде, где приводится пример адреса IPv6 или описываются типовые сетевые сценарии.
• 3fff:: / 20 — Этот новый префикс был выделен для учета современного крупномасштабного сетевого моделирования, которое не может быть охвачено однимпрефиксом / 32. ^[37]

Отказаться

• 100:: / 64 — Этот префикс используется для сброса трафика.^[32]

Устаревший и неактуальный

См. § Устаревшие и неактуальные адреса.

Многоадресные адреса

Адреса многоадресной рассылки ff0x:: , где x — любое шестнадцатеричное значение, зарезервированы ^[1] и управляются Управлением по распределению адресов в Интернете (IANA). ^[44]

Адрес многоадресной рассылки запрошенного узла

Наименее значимые 24 бита идентификатора группы адресов многоадресной рассылки запрошенного узла заполняются наименее значимыми 24 битами адреса одноадресной рассылки или произвольной рассылки интерфейса. Эти адреса позволяют разрешать адрес на уровне канала через протокол обнаружения соседей (NDP) на канале, не нарушая работу всех узлов локальной сети. Хост должен присоединиться к группе многоадресной рассылки запрошенного узла для каждого из его настроенных адресов одноадресной рассылки или произвольной рассылки.

Автоконфигурация адреса без сохранения состояния (SLAAC)

При запуске системы узел автоматически создает локальный адрес связи на каждом интерфейсе с поддержкой IPv6, даже если глобально маршрутизируемые адреса настроены вручную или получены через протоколы конфигурации (см. ниже). Он делает это независимо и без какой-либо предварительной настройки с помощью автоконфигурации адресов без сохранения состояния ( SLAAC ), ^[46] используя компонент протокола обнаружения соседей . Этот адрес выбирается с префиксом fe80:: / 64 .

В IPv4 типичные протоколы конфигурации включают DHCP или PPP. Хотя DHCPv6 существует, хосты IPv6 обычно используют протокол обнаружения соседей для создания глобально маршрутизируемого одноадресного адреса: хост отправляет запросы на запрос маршрутизатора, а маршрутизатор IPv6 отвечает назначением префикса. ^[47]

Идентификатор интерфейса

Нижние 64 бита этих адресов заполняются 64-битным идентификатором интерфейса. Это должно быть псевдослучайное число по соображениям конфиденциальности. Также по соображениям конфиденциальности идентификатор интерфейса отличается для каждого автоматически настроенного адреса этого интерфейса. Это имеет тот недостаток, что для обнаружения соседей необходимо объединить несколько групп многоадресной рассылки . Для этого используется адрес многоадресной рассылки запрошенного узла, сформированный из сетевого префикса ff02::1:ff00:0 / 104 и 24 младших битов адреса.

64-битный идентификатор интерфейса может быть получен из 48-битного MAC-адреса интерфейса , хотя в настоящее время вместо него по умолчанию рекомендуются стабильные адреса конфиденциальности. ^[2] MAC-адрес 00-0C-29-0C-47-D5 преобразуется в 64-битный EUI-64 путем вставки FF-FE в середину: 00-0C-29- FF-FE -0C-47-D5 . ^[f]

Обнаружение дубликатов адресов

Назначение одноадресного IPv6 -адреса интерфейсу включает внутреннюю проверку уникальности этого адреса с использованием сообщений Neighbor Solicitation и Neighbor Advertisement ( ICMPv6 тип 135 и 136). В процессе установления уникальности адрес имеет предварительное состояние.

Узел присоединяется к адресу многоадресной рассылки запрошенного узла для предварительного адреса и отправляет запросы соседям, с предварительным адресом в качестве целевого адреса и неуказанным адресом ( :: / 128 ) в качестве исходного адреса. Узел также присоединяется к адресу многоадресной рассылки всех хостов ff02::1 , поэтому он может получать объявления соседей .

Если узел получает запрос соседа с его собственным предварительным адресом в качестве целевого адреса, то он знает, что его адрес не является уникальным. То же самое верно, если узел получает объявление соседа с предварительным адресом в качестве источника объявления. Только после успешного установления того, что адрес является уникальным, он может быть назначен и использован интерфейсом.

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

Срок действия адреса

Каждый IPv6-адрес, привязанный к интерфейсу, имеет определенный срок службы. Срок службы бесконечен, если не настроен на более короткий период. Существует два срока службы, которые управляют состоянием адреса: предпочтительный срок службы и допустимый срок службы . ^[48] Сроки службы можно настроить в маршрутизаторах , которые предоставляют значения, используемые для автоконфигурации, или указать при ручной настройке адресов на интерфейсах.

Когда адрес назначается интерфейсу, он получает статус preferred , который он удерживает в течение срока действия preferred-lifetime. После истечения этого срока действия статус становится устаревшим , и новые соединения с использованием этого адреса не должны устанавливаться. ^[g] Адрес становится недействительным после истечения срока действия valid-lifetime; адрес удаляется из интерфейса и может быть назначен где-то еще в Интернете .

Временные адреса

Глобально уникальные и статические MAC-адреса, используемые автоконфигурацией адресов без сохранения состояния для создания идентификаторов интерфейсов, дают возможность отслеживать пользовательское оборудование с течением времени и изменениями префикса сети IPv6. ^[49] Чтобы уменьшить вероятность постоянной привязки идентификатора пользователя к части адреса IPv6, узел может создавать временные адреса с идентификаторами интерфейсов на основе изменяющихся во времени случайных битовых строк ^[50] и относительно коротким временем жизни (от нескольких часов до нескольких дней), после чего они заменяются новыми адресами.

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

Сетевые интерфейсы, настроенные для IPv6, используют временные адреса по умолчанию в OS X Lion и более поздних системах Apple ^{[ необходима ссылка ]} , а также в Windows Vista , Windows 2008 Server и более поздних системах Microsoft. ^[51]

Криптографически сгенерированные адреса

В качестве средства повышения безопасности протокола обнаружения соседей в 2005 году ^{[52] были введены} криптографически сгенерированные адреса (CGA) как часть протокола безопасного обнаружения соседей (SEND).

Такой адрес генерируется с использованием двух хэш-функций , которые принимают несколько входных данных. Первая использует открытый ключ и случайный модификатор; последний многократно увеличивается до тех пор, пока не будет получено определенное количество нулевых битов результирующего хеша. ^[h] Вторая хэш-функция принимает сетевой префикс и предыдущее значение хеша. Наименее значимые 64 бита второго результата хеша добавляются к 64-битному сетевому префиксу для формирования 128-битного адреса.

Хэш-функции также могут использоваться для проверки того, удовлетворяет ли конкретный адрес IPv6 требованию быть допустимым CGA. Таким образом, связь может быть установлена ​​исключительно между доверенными адресами.

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

Использование измененного формата EUI-64 имеет серьезные последствия для проблем безопасности и конфиденциальности, ^[53], поскольку базовый аппаратный адрес (чаще всего MAC-адрес ) раскрывается за пределами локальной сети, что позволяет отслеживать действия пользователя и сопоставлять учетные записи пользователей с другой информацией. Это также позволяет использовать стратегии атак, специфичные для поставщика, и уменьшает размер адресного пространства для поиска целей атаки.

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

Генерация стабильного адреса конфиденциальности основана на хэш-функции, которая использует несколько стабильных параметров. Это зависит от реализации, но рекомендуется включать по крайней мере сетевой префикс, имя сетевого интерфейса, счетчик дубликатов адресов и секретный ключ. Полученное значение хэша используется для построения окончательного адреса: обычно 64 младших бита объединяются с 64-битным сетевым префиксом, чтобы получить 128-битный адрес. Если сетевой префикс меньше 64 бит, используется больше бит хэша. Если полученный адрес не конфликтует с существующими или зарезервированными адресами, он назначается интерфейсу. Конфликты разрешаются путем корректировки счетчика дубликатов адресов. ^[53]

Выбор адреса по умолчанию

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

Алгоритм выбора предпочтений выбирает наиболее подходящий адрес для использования в коммуникациях с определенным пунктом назначения, включая использование сопоставленных IPv4 адресов в реализациях с двойным стеком . ^[54] Он использует настраиваемую таблицу предпочтений, которая связывает каждый префикс маршрутизации с уровнем приоритета. Таблица по умолчанию имеет следующее содержимое:

Конфигурация по умолчанию отдает предпочтение использованию IPv6 и выбирает адреса назначения в пределах наименьшего возможного диапазона, так что локальная связь по каналу предпочтительнее глобально маршрутизируемых путей, когда в остальном они одинаково подходят. Таблица политики префиксов похожа на таблицу маршрутизации, в которой значение приоритета играет роль стоимости канала, где более высокое предпочтение выражается как большее значение. Предпочтительно, чтобы исходные адреса имели то же значение метки, что и адрес назначения. Адреса сопоставляются с префиксами на основе самой длинной совпадающей последовательности наиболее значимых битов. Кандидаты на исходные адреса получаются из операционной системы , а кандидаты на адреса назначения могут быть запрошены через DNS.

Чтобы минимизировать время установления соединения, когда для связи доступно несколько адресов, был разработан алгоритм Happy Eyeballs . Он запрашивает DNS для адресов IPv6 и IPv4 целевого хоста, сортирует адреса-кандидаты с использованием таблицы выбора адресов по умолчанию и пытается установить соединения параллельно. Первое установленное соединение прерывает текущие и будущие попытки подключения к другим адресам.

Система доменных имен

В системе доменных имен имена хостов сопоставляются с адресами IPv6 с помощью записей ресурсов AAAA , так называемых записей quad-A . ^[55] Для обратного поиска IETF зарезервировал домен ip6.arpa , где пространство имен иерархически разделено однозначным шестнадцатеричным представлением полубайтовых единиц (4 бита) адреса IPv6.

Как и в IPv4, каждый хост представлен в DNS двумя записями DNS: записью адреса и записью указателя обратного отображения. Например, хост-компьютер с именем derrick в зоне example.com имеет уникальный локальный адрес fdda:5cc1:23:4::1f . Его запись адреса quad-A —

derrick.example.com. В AAAA fdda:5cc1:23:4::1f

и его запись указателя IPv6 -

f.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.3.2.0.0.1.cc5.addfip6.arpa. В PTR derrick.example.com.

Эта запись указателя может быть определена в нескольких зонах в зависимости от цепочки делегирования полномочий в зоне dfip6.arpa.

Протокол DNS независим от протокола транспортного уровня . Запросы и ответы могут передаваться по протоколам IPv6 или IPv4 независимо от семейства адресов запрашиваемых данных.

Исторические заметки

Устаревшие и неактуальные адреса

• Локальный префикс сайта fec0:: / 10 указывает, что адрес действителен только в пределах сети сайта организации. Он был частью исходной архитектуры адресации в декабре 1995 года, ^[56] но его использование было прекращено в сентябре 2004 года, поскольку определение термина сайт было неоднозначным, что привело к запутанным правилам маршрутизации. Новые сети не должны поддерживать этот специальный тип адреса. ^[57] В октябре 2005 года новая спецификация заменила этот тип адреса уникальными локальными адресами . ^[39]
• Блок адресов 200:: / 7 был определен как набор префиксов, сопоставленных OSI NSAP, в августе 1996 года ^{[58] [59],} но был объявлен устаревшим в декабре 2004 года. ^[60]
• 96-битный префикс с нулевым значением :: / 96 , изначально известный как IPv4-совместимые адреса , был упомянут в 1995 году ^[56], но никогда полностью не описан. Этот диапазон адресов использовался для представления адресов IPv4 в рамках технологии перехода IPv6. Такой адрес IPv6 имеет свои первые (самые значимые) 96 бит, установленные в ноль, в то время как его последние 32 бита являются представляемым адресом IPv4. В феврале 2006 года Инженерная группа Интернета (IETF) объявила устаревшим использование IPv4-совместимых адресов. ^[1] Единственное оставшееся использование этого формата адреса — представление адреса IPv4 в таблице или базе данных с элементами фиксированного размера, которые также должны иметь возможность хранить адрес IPv6.
• Блок адресов 3ffe:: / 16 был выделен для тестовых целей для сети 6bone в декабре 1998 года. ^[61] До этого для этой цели использовался блок адресов 5f00:: / 8. ^{Оба блока адресов были возвращены в пул адресов в июне 2006 года. [62]}
• Из-за проблем с эксплуатацией 6to4 использование блока адресов 2002:: / 16 сокращается, поскольку механизм 6to4 устарел с мая 2015 года. ^[36] Хотя блок адресов IPv4 192.88.99.0 / 24 устарел, 2002:: / 16 — нет.
• В апреле 2007 года адресный блок 2001:10:: / 28 был назначен для Overlay Routable Cryptographic Hash Identifiers (ORCHID). ^[63] Он был предназначен для экспериментального использования. В сентябре 2014 года была определена вторая версия ORCHID, ^[34] и с введением блока 2001:20:: / 28 исходный блок был возвращен в IANA .

Разнообразный

• Для обратного поиска DNS адреса IPv6 изначально регистрировались в зоне DNS ip6.int , поскольку ожидалось, что домен верхнего уровня arpa будет упразднен. В 2000 году Совет по архитектуре Интернета (IAB) отменил это намерение и в 2001 году решил, что arpa должен сохранить свою первоначальную функцию. Домены в ip6.int были перемещены в ip6.arpa ^[64] , а зона ip6.int была официально удалена 6 июня 2006 года.
• В марте 2011 года IETF уточнила рекомендации по распределению адресных блоков конечным сайтам. ^[23] Вместо назначения либо a / 48 , / 64 , либо / 128 (согласно взглядам IAB и IESG от 2001 года), ^[65] поставщики интернет-услуг должны рассмотреть назначение меньших блоков (например, a / 56 ) конечным пользователям. Политики региональных регистраторов ARIN , RIPE и APNIC поощряют назначение / 56 там, где это уместно. ^[23]
• Первоначально существовало два предложения по переводу доменных имен в адреса IPv6: одно с использованием записей AAAA, ^[66] другое с использованием записей A6. ^[67] Записи AAAA, метод, который преобладал, сопоставимы с записями A для IPv4, обеспечивая простое сопоставление имени хоста с адресом IPv6. Метод с использованием записей A6 использовал иерархическую схему, в которой сопоставление последующих групп бит адреса определялось дополнительными записями A6, предоставляя возможность перенумеровать все хосты в сети путем изменения одной записи A6. Поскольку предполагаемые преимущества формата A6 не считались перевешивающими предполагаемые затраты, ^{[68] [69] [70] [71]} метод был переведен в экспериментальный статус в 2002 году, ^[69] и, наконец, в исторический статус в 2012 году. ^[71]
• В 2009 году было обнаружено, что многие DNS-резолверы в домашних сетевых устройствах NAT и маршрутизаторах неправильно обрабатывают записи AAAA. ^[72] Некоторые из них просто сбрасывали DNS-запросы для таких записей вместо того, чтобы должным образом возвращать соответствующий отрицательный ответ DNS. Поскольку запрос сбрасывается, хост, отправляющий запрос, должен ждать истечения времени ожидания для срабатывания. Это часто приводит к увеличению задержки при подключении к хостам с двойным стеком IPv6/IPv4, поскольку клиентское программное обеспечение ждет сбоя соединения IPv6, прежде чем пытаться использовать IPv4.

Примечания

1. 16-битное или двухоктетное число иногда также называют гекстетом . ^{[7] [8]}
2. Предположим, что eth2 эквивалентен зоне номер 3. Обычно это так, поскольку реальные номера зон начинаются с 1 (0 — «зона по умолчанию»).
3. Хотя Windows поддерживает API RFC 3493 if_nametoindex()для преобразования имени в номер интерфейса, она не поддерживает обычное расширение «имя после %».
4. Теперь удаленные локальные адреса fec0::/10 также требуют индекс зоны. ^[12]
5. 192.0.2.0 / 24 , 198.51.100.0 / 24 и 203.0.113.0 / 24 используются для документации в IPv4. ^[43]
6. Когда этот EUI-64 используется для формирования адреса IPv6, он изменяется: ^[1] значение бита Universal/Local (7-й по значимости бит EUI-64, начиная с 1) инвертируется, так что 1 теперь означает Universal . Чтобы создать адрес IPv6 с сетевым префиксом 2001:db8:1:2:: / 64, получается адрес 2001:db8:1:2:0 2 0c:29ff:fe0c:47d5 (с битом Universal/Local , вторым по значимости битом подчеркнутого квартета, инвертированным в 1 в этом случае, поскольку MAC-адрес универсально уникален).
7. В большинстве случаев срок службы не истекает, поскольку новые объявления маршрутизатора (RA) обновляют таймеры. Но если больше нет RA, в конечном итоге предпочтительный срок службы истекает, и адрес становится устаревшим .
8. Сравнимо с полем «доказательства работы» в майнинге биткоинов .

Ссылки

1. R. Hinden; S. Deering (февраль 2006 г.). Архитектура адресации IP версии 6. Сетевая рабочая группа. doi : 10.17487/RFC4291 . RFC 4291. Проект стандарта. Отменяет RFC 3513. Обновлен RFC 5952, 6052, 7136, 7346, 7371 и 8064.
2. F. Gont; A. Cooper; D. Thaler; W. Liu (февраль 2017 г.). Рекомендация по стабильным идентификаторам интерфейсов IPv6. Internet Engineering Task Force (IETF). doi : 10.17487/RFC8064 . RFC 8064. Предлагаемый стандарт. Обновления RFC 2464, 2467, 2470, 2491, 2492, 2497, 2590, 3146, 3572, 4291 , 4338, 4391, 5072 и 5121.
3. Сильвия Хаген (май 2006 г.). Основы IPv6 (второе изд.). О'Рейли. ISBN 978-0-596-10058-2.
4. P. Savola; B. Haberman (ноябрь 2004 г.). Встраивание адреса точки рандеву (RP) в многоадресный адрес IPv6. Сетевая рабочая группа. doi : 10.17487/RFC3956 . RFC 3956. Предложенный стандарт. Обновлен RFC 7371. Обновления RFC 3306.
5. B. Haberman; D. Thaler (август 2002 г.). Многоадресные адреса IPv6 на основе одноадресного префикса. Сетевая рабочая группа. doi : 10.17487/RFC3306 . RFC 3306. Предложенный стандарт. Обновлен RFC 3956, 4489 и 7371.
6. JS. Park; MK. Shin; HJ. Kim (апрель 2006 г.). Метод генерации многоадресных адресов IPv6 в области ссылок. Сетевая рабочая группа. doi : 10.17487/RFC4489 . RFC 4489. Предложенный стандарт. Обновления RFC 3306.
7. Грациани, Рик (2012). Основы IPv6: Прямой подход к пониманию IPv6. Cisco Press . стр. 55. ISBN 978-0-13-303347-2.
8. Коффен, Том (2014). Планирование адресов IPv6: Разработка плана адресов для будущего. O'Reilly Media . стр. 170. ISBN 978-1-4919-0326-1.
9. S. Kawamura; M. Kawashima (август 2010 г.). Рекомендация по текстовому представлению адресов IPv6. Internet Engineering Task Force . doi : 10.17487/RFC5952 . ISSN  2070-1721. RFC 5952. Предложенный стандарт. Обновления RFC 4291.
10. T. Berners-Lee ; R. Fielding ; L. Masinter (январь 2005 г.). Унифицированный идентификатор ресурса (URI): общий синтаксис. Сетевая рабочая группа. doi : 10.17487/RFC3986 . STD 66. RFC 3986. Стандарт Интернета 66. Отменяет RFC 2732, 2396 и 1808. Обновлен RFC 6874, 7320 и 8820. Обновляет RFC 1738.
11. S. Deering ; B. Haberman; T. Jinmei; E. Nordmark; B. Zill (март 2005 г.). Архитектура адресов IPv6 Scoped. Сетевая рабочая группа. doi : 10.17487/RFC4007 . RFC 4007. Предложенный стандарт. Обновлен RFC 7346.
12. inet6(4) –  Руководство по интерфейсам ядра FreeBSD «Реализация KAME поддерживает расширенную числовую нотацию адресов IPv6 для локальных адресов связи, например, «fe80::1%de0» [...] draft-ietf-ipngwg-scopedaddr-format-02.txt»
13. B. Carpenter ; S. Cheshire ; R. Hinden (февраль 2013 г.). Представление идентификаторов зон IPv6 в адресных литералах и унифицированных идентификаторах ресурсов. IETF . doi : 10.17487/RFC6874 . ISSN  2070-1721. RFC 6874. Предложенный стандарт. Обновления RFC 3986.
14. "История домена ipv6-literal.net". who.is . Получено 20 октября 2014 г. .
15. Р. Дромс (август 2014 г.). Диапазоны адресов многоадресной рассылки IPv6. Internet Engineering Task Force . doi : 10.17487/RFC7346 . ISSN  2070-1721. RFC 7346. Предложенный стандарт. Обновления RFC 4007 и 4291.
16. Совет по архитектуре Интернета ; Руководящая группа по инжинирингу Интернета (декабрь 1995 г.). Управление распределением адресов IPv6. Сетевая рабочая группа. doi : 10.17487/RFC1881 . RFC 1881. Информационный.
17. Адресное пространство IPv6 в IANA. Iana.org (29.10.2010). Получено 28.09.2011.
18. Назначение одноадресных адресов IPv6, IANA
19. DE-TELEKOM-20050113 ^{[ постоянная мертвая ссылка ]} db.ripe.net. Проверено 28 сентября 2011 г.
20. «Руководство по политике номерных ресурсов ARIN: Первоначальное распределение среди интернет-провайдеров».
21. «Политика распределения и назначения адресов IPv6 RIPE NCC: минимальное распределение».
22. например. Iana.org. Получено 28.09.2011.
23. T. Narten; G. Huston; L. Roberts (март 2011 г.). Назначение адресов IPv6 конечным сайтам. Internet Engineering Task Force (IETF). doi : 10.17487/RFC6177 . ISSN  2070-1721. BCP 157. RFC 6177. Лучшая общепринятая практика. Отменяет RFC 3177.
24. "Планы адресации IPv6". ARIN IPv6 Wiki . Получено 15 июля 2018 г. Все клиенты получают один / 48 , если только они не могут доказать, что им нужно более 65 тыс. подсетей. [...] Если у вас много клиентов-потребителей, вы можете назначить / 56 частным резиденциям.
25. "Что такое Богоны?" . Получено 15.11.2021 .
26. "Адресное пространство, управляемое RIPE NCC" . Получено 22.05.2011 .
27. Д. Джонсон; С. Диринг (март 1999 г.). Зарезервированные адреса произвольной рассылки подсети IPv6. Сетевая рабочая группа. doi : 10.17487/RFC2526 . RFC 2526. Предлагаемый стандарт.
28. M. Cotton; L. Vegoda; B. Haberman (апрель 2013 г.). R. Bonica (ред.). Реестры IP-адресов специального назначения. IETF . doi : 10.17487/RFC6890 . ISSN  2070-1721. BCP 153. RFC 6890. Лучшая текущая практика 153. Отменяет RFC 4773, 5156, 5735 и 5736. Обновлено RFC 8190.
29. "Реестр адресов специального назначения IANA IPv6". www.iana.org . Получено 2024-08-02 .
30. C. Bao; C. Huitema ; M. Bagnulo; M. Boucadair; X. Li (октябрь 2010 г.). Адресация IPv6 трансляторов IPv4/IPv6. Internet Engineering Task Force (IETF). doi : 10.17487/RFC6052 . ISSN  2070-1721. RFC 6052. Предложенный стандарт. Обновления RFC 4291.
31. T. Anderson (август 2017 г.). Префикс локального преобразования IPv4/IPv6. Internet Engineering Task Force . doi : 10.17487/RFC8215 . RFC 8215. Предлагаемый стандарт.
32. N. Hilliard; D. Freedman (август 2012 г.). Отбрасываемый префикс для IPv6. Internet Engineering Task Force . doi : 10.17487/RFC6666 . ISSN  2070-1721. RFC 6666. Информационный.
33. S. Santesson (сентябрь 2006 г.). Сообщение о рукопожатии TLS для дополнительных данных. Сетевая рабочая группа. doi : 10.17487/RFC4680 . RFC 4680. Предложенный стандарт. Обновления RFC 4346. Обновлено RFC 8447 и 8996.
34. J. Laganier; F. Dupont (сентябрь 2014 г.). Префикс IPv6 для маршрутизируемых наложенных криптографических хэш-идентификаторов версии 2 (ORCHIDv2). Internet Engineering Task Force . doi : 10.17487/RFC7343 . ISSN  2070-1721. RFC 7343. Предложенный стандарт. Отменяет RFC 4843.
35. G. Huston; A. Lord; P. Smith (июль 2004 г.). Префикс адреса IPv6 зарезервирован для документации. Сетевая рабочая группа. doi : 10.17487/RFC3849 . RFC 3849. Информационный.
36. O. Troan (май 2015 г.). B. Carpenter (ред.). Отказ от префикса Anycast для маршрутизаторов 6to4 Relay. Internet Engineering Task Force . doi : 10.17487/RFC7526 . BCP 196. RFC 7526. Лучшая текущая практика. Отменяет RFC 3068 и 6732.
37. G. Huston; N. Buraglio (август 2024 г.). Расширение пространства документации IPv6. Internet Engineering Task Force (IETF). doi : 10.17487/RFC9637 . RFC 9637. Информационный. Обновления RFC 3849.
38. Кришнан, С. (15.02.2024). Идентификаторы сегмента SRv6 в архитектуре адресации IPv6. IETF . Идентификатор draft-ietf-6man-sids-06 . Получено 13.06.2024 .
39. R. Hinden; B. Haberman (октябрь 2005 г.). Уникальные локальные адреса IPv6 Unicast. Сетевая рабочая группа. doi : 10.17487/RFC4193 . RFC 4193. Предлагаемый стандарт.
40. C. Bao; X. Li; F. Baker ; T. Anderson; F. Gont (июнь 2016 г.). Алгоритм трансляции IP/ICMP. Internet Engineering Task Force (IETF). doi : 10.17487/RFC7915 . RFC 7915. Предложенный стандарт. Отменяет RFC 6145.
41. R. Hinden; S. Deering ; R. Fink; T. Hain (сентябрь 2000 г.). Первоначальные назначения идентификаторов IPv6 Sub-TLA. Сетевая рабочая группа. doi : 10.17487/RFC2928 . RFC 2928. Информационный.
42. C. Popoviciu; A. Hamza; G. Van de Velde; D. Dugatkin (май 2008 г.). Методология сравнительного анализа IPv6 для сетевых межсетевых устройств. Сетевая рабочая группа. doi : 10.17487/RFC5180 . RFC 5180. Информационный.
43. J. Arkko; M. Cotton; L. Vegoda (январь 2010 г.). Блоки адресов IPv4, зарезервированные для документации. Internet Engineering Task Force . doi : 10.17487/RFC5737 . ISSN  2070-1721. RFC 5737. Информационное. Обновления RFC 1166.
44. "Реестр многоадресного адресного пространства IPv6". Internet Assigned Numbers Authority .
45. T. Mrugalski; M. Siodelski; B. Volz; A. Yourtchenko; M. Richardson; S. Jiang; T. Lemon; T. Winters (ноябрь 2018 г.). Протокол динамической конфигурации хоста для IPv6 (DHCPv6). IETF . doi : 10.17487/RFC8415 . ISSN  2070-1721. RFC 8415. Предлагаемый стандарт. Отменяет RFC 3315, 3633, 3736, 4242, 7083, 7283 и 7550.
46. S. Thomson; T. Narten; T. Jinmei (сентябрь 2007 г.). Автоматическая конфигурация IPv6-адресов без сохранения состояния. Сетевая рабочая группа. doi : 10.17487/RFC4862 . RFC 4862. Проект стандарта. Отменяет RFC 2462. Обновлен RFC 7527.
47. T. Narten; E. Nordmark; W. Simpson; H. Holiman (сентябрь 2007 г.). Neighbor Discovery для IP версии 6 (IPv6). Сетевая рабочая группа. doi : 10.17487/RFC4861 . RFC 4861. Проект стандарта. Отменяет RFC 2461. Обновлен RFC 5942, 6980, 7048, 7527, 7559, 8028, 8319, 8425 и 9131.
48. Ильич ван Бейнум (2006). «Внутреннее устройство IPv6». Журнал Интернет-протокола . Том. 9, нет. 3. С. 16–29.
49. Последствия для конфиденциальности адресации IPv6 без сохранения состояния. Portal.acm.org (2010-04-21). Получено 2011-09-28.
50. F. Gont; S. Krishnan; T. Narten; R. Draves (февраль 2021 г.). Временные расширения адресов для автоконфигурации адресов без сохранения состояния в IPv6. Internet Engineering Task Force . doi : 10.17487/RFC8981 . ISSN  2070-1721. RFC 8981. Предложенный стандарт. Отменяет действие RFC  4941.
51. "IPv6 в Windows" . Получено 2024-03-25 .
52. T. Aura (март 2005 г.). Криптографически сгенерированные адреса (CGA). Сетевая рабочая группа. doi : 10.17487/RFC3972 . RFC 3972. Предложенный стандарт. Обновлен RFC 4581 и 4982.
53. F. Gont (апрель 2014 г.). Метод генерации семантически непрозрачных идентификаторов интерфейсов с помощью автоконфигурации адресов без сохранения состояния IPv6 (SLAAC). Internet Engineering Task Force . doi : 10.17487/RFC7217 . ISSN  2070-1721. RFC 7217. Предлагаемый стандарт.
54. D. Thaler; R. Draves; A. Matsumoto; T. Chown (сентябрь 2012 г.). D. Thaler (ред.). Выбор адреса по умолчанию для протокола Интернета версии 6 (IPv6). Internet Engineering Task Force . doi : 10.17487/RFC6724 . ISSN  2070-1721. RFC 6724. Предлагаемый стандарт. Отменяет RFC 3484.
55. S. Thomson; C. Huitema; V. Ksinant; M. Souissi (октябрь 2003 г.). Расширения DNS для поддержки IP версии 6. Сетевая рабочая группа. doi : 10.17487/RFC3596 . RFC 3596. Стандарт Интернета. Отменяет RFC 3152 и 1886.
56. R. Hinden; S. Deering (декабрь 1995 г.). Архитектура адресации IP версии 6. Сетевая рабочая группа. doi : 10.17487/RFC1884 . RFC 1884. Устарело. Устарело согласно RFC 2373.
57. C. Huitema ; B. Carpenter (сентябрь 2004 г.). Отказ от локальных адресов сайтов. Сетевая рабочая группа. doi : 10.17487/RFC3879 . RFC 3879. Предлагаемый стандарт.
58. G. Houston (август 2005 г.). Предлагаемые изменения в формате реестра IANA IPv6. Сетевая рабочая группа. doi : 10.17487/RFC4147 . RFC 4147. Информационный.
59. J. Bound; B. Carpenter; D. Harrington; J. Houldsworth; A. Lloyd (август 1996 г.). OSI NSAPs и IPv6. Сетевая рабочая группа. doi : 10.17487/RFC1888 . RFC 1888. Устарело. Устарело по RFC 4048. Обновлено по RFC  4548.
60. Б. Карпентер (апрель 2005 г.). RFC 1888 устарел. doi : 10.17487/RFC4048 . RFC 4048. Информационное. Обновлено RFC 4548.
61. R. Hinden; R. Fink; J. Postel (декабрь 1998 г.). Распределение тестовых адресов IPv6. Сетевая рабочая группа. doi : 10.17487/RFC2471 . RFC 2471. Устарело. Устарело из-за RFC 3701. Устаревший RFC 1897.
62. Р. Финк; Р. Хинден (март 2004 г.). Поэтапный отказ от 6bone (распределение тестовых адресов IPv6). Сетевая рабочая группа. doi : 10.17487/RFC3701 . RFC 3701. Информационный. Отменяет действие RFC 2471.
63. P. Nikander; J. Laganier; F. Dupont (апрель 2007 г.). Префикс IPv6 для маршрутизируемых криптографических хэш-идентификаторов наложения (ORCHID). Сетевая рабочая группа. doi : 10.17487/RFC4843 . RFC 4843. Устарело. Устарело согласно RFC 7343.
64. Р. Буш (август 2001 г.). Делегация IP6.ARPA. Сетевая рабочая группа. doi : 10.17487/RFC3152 . BCP 49. RFC 3152. Устарело. Устарело по RFC 3596. Обновления RFC 1886, 2553, 2766, 2772 и 2874
65. IAB ; IESG (сентябрь 2001 г.). Рекомендации IAB/IESG по распределению адресов IPv6 для сайтов. Сетевая рабочая группа. doi : 10.17487/RFC3177 . RFC 3177. Устарело. Устарело согласно RFC 6177.
66. S. Thomson; C. Huitema (декабрь 1995 г.). Расширения DNS для поддержки IP версии 6. Сетевая рабочая группа. doi : 10.17487/RFC1886 . RFC 1886. Устарело. Устарело согласно RFC  3596. Обновлено согласно RFC 2874 и 3152.
67. M. Crawford; C. Huitema (июль 2000 г.). Расширения DNS для поддержки агрегации и перенумерации адресов IPv6. Сетевая рабочая группа. doi : 10.17487/RFC2874 . RFC 2874. Историческое. Обновлено RFC 3152, 3226, 3363 и 3364. Обновления RFC 1886.
68. Сравнение AAAA и A6 (действительно ли нам нужен A6?), Дзюнъитиро итодзюн Хагино, (июль 2001 г.)
69. R. Bush; A. Durand; B. Fink; O. Gudmundsson; T. Hain, ред. (август 2002 г.). Представление адресов протокола Интернета версии 6 (IPv6) в системе доменных имен (DNS). Сетевая рабочая группа. doi : 10.17487/RFC3363 . RFC 3363. Информационное. Обновления RFC 2673 и 2874.
70. Р. Остейн (август 2002 г.). Компромиссы в поддержке системы доменных имен (DNS) для протокола Интернета версии 6 (IPv6). Сетевая рабочая группа. doi : 10.17487/RFC3364 . RFC 3364. Информационное. Обновления RFC 2673 и 2874.
71. A. Bierman; M. Bjorklund (март 2012 г.). Модель контроля доступа к протоколу конфигурации сети (NETCONF). Internet Engineering Task Force . doi : 10.17487/RFC6536 . RFC 6536. Устарело. Устарело согласно RFC 8341.
72. Y. Morishita; T. Jinmei (май 2005 г.). Распространенное неправильное поведение в отношении DNS-запросов для адресов IPv6. doi : 10.17487/RFC4074 . RFC 4074. Информационный.

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

• Многоадресные адреса IP версии 6
• Бейнум, ван, Ильич (2005). Запуск IPv6 . ISBN 978-1-59059-527-5.
• Р. Элц (1 апреля 1996 г.). Компактное представление адресов IPv6. Сетевая рабочая группа. doi : 10.17487/RFC1924 . RFC 1924. Информационный. Это первоапрельская просьба о комментариях . Представьте любой адрес IPv6 в 20 октетах. Этот юмористический RFC определяет альтернативный способ представления адресов IPv6 с использованием кодировки base-85.