stringtranslate.com

IPv6

Интернет-протокол версии 6 ( IPv6 ) — это последняя версия Интернет-протокола (IP), протокола связи , который обеспечивает систему идентификации и определения местоположения компьютеров в сетях и маршрутизирует трафик через Интернет . IPv6 был разработан Инженерной рабочей группой Интернета (IETF) для решения давно ожидаемой проблемы исчерпания адресов IPv4 и был предназначен для замены IPv4 . [1] В декабре 1998 года IPv6 стал проектом стандарта для IETF, [2] который впоследствии ратифицировал его как Интернет-стандарт 14 июля 2017 года. [3] [4]

Устройствам в Интернете назначается уникальный IP-адрес для идентификации и определения местоположения. С быстрым ростом Интернета после коммерциализации в 1990-х годах стало очевидно, что для подключения устройств потребуется гораздо больше адресов, чем было доступно в адресном пространстве IPv4. К 1998 году IETF формализовал протокол-преемник. IPv6 использует 128- битные адреса, теоретически допуская 2 128 , или приблизительно3,4 × 10 38 всего адресов. Фактическое число немного меньше, так как несколько диапазонов зарезервированы для специального использования или полностью исключены из общего использования. Эти два протокола не предназначены для взаимодействия , и, таким образом, прямая связь между ними невозможна, что усложняет переход на IPv6. Однако было разработано несколько механизмов перехода, чтобы исправить это.

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

Адреса IPv6 представлены в виде восьми групп по четыре шестнадцатеричных цифры в каждой, разделенных двоеточиями. Полное представление может быть сокращено; например, 2001:0db8:0000:0000:0000:8a2e:0370:7334 становится 2001:db8::8a2e:370:7334 .

Основные характеристики

Глоссарий терминов, используемых для адресов IPv6

IPv6 — это протокол интернет-уровня для пакетной коммутации сетевых соединений , который обеспечивает сквозную передачу датаграмм по нескольким IP-сетям, строго следуя принципам проектирования, разработанным в предыдущей версии протокола — Интернет-протоколе версии 4 (IPv4).

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

Архитектура адресации IPv6 определена в RFC  4291 и допускает три различных типа передачи: одноадресную , произвольной и многоадресную . [5] : 210 

Мотивация и происхождение

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

Разложение точечно-десятичного представления адреса IPv4 на его двоичную запись

Протокол Интернета версии 4 (IPv4) был первой публично используемой версией протокола Интернета . IPv4 был разработан как исследовательский проект Агентства перспективных исследовательских проектов Министерства обороны США (DARPA) , прежде чем стать основой для Интернета и Всемирной паутины . IPv4 включает в себя систему адресации, которая использует числовые идентификаторы, состоящие из 32 бит. Эти адреса обычно отображаются в точечно-десятичном представлении как десятичные значения из четырех октетов, каждый в диапазоне от 0 до 255, или 8 бит на число. Таким образом, IPv4 обеспечивает возможность адресации 2 32 или приблизительно 4,3 миллиарда адресов. Исчерпание адресов изначально не было проблемой в IPv4, поскольку эта версия изначально предполагалась как проверка сетевых концепций DARPA. [6] В течение первого десятилетия работы Интернета стало очевидно, что необходимо разработать методы для экономии адресного пространства. В начале 1990-х годов, даже после перепроектирования системы адресации с использованием модели бесклассовой сети , стало ясно, что этого будет недостаточно для предотвращения исчерпания адресов IPv4 , и что необходимы дальнейшие изменения в инфраструктуре Интернета. [7]

Последние нераспределенные блоки адресов верхнего уровня из 16 миллионов адресов IPv4 были выделены в феврале 2011 года Управлением по распределению адресов в Интернете (IANA) пяти региональным интернет-регистраторам (RIR). [8] Однако каждый RIR по-прежнему имеет доступные пулы адресов и, как ожидается, продолжит использовать стандартные политики распределения адресов до тех пор, пока не останется один блок бесклассовой междоменной маршрутизации (CIDR) /8 . После этого только блоки из 1024 адресов (/22) будут предоставлены RIR локальному интернет-регистратору (LIR). По состоянию на сентябрь 2015 года все Азиатско-Тихоокеанский сетевой информационный центр (APNIC), Центр координации сетей Réseaux IP Européens (RIPE NCC), Латиноамериканский и Карибский сетевой информационный центр (LACNIC) и Американский реестр интернет-номеров (ARIN) достигли этой стадии. [9] [10] [11] Это оставляет African Network Information Center (AFRINIC) единственным региональным интернет-регистратором, который все еще использует обычный протокол для распределения адресов IPv4. По состоянию на ноябрь 2018 года минимальное распределение AFRINIC составляет /22 или 1024 адреса IPv4. LIR может получить дополнительное распределение, когда будет использовано около 80% всего адресного пространства. [12]

RIPE NCC объявил, что 25 ноября 2019 года у него полностью закончились адреса IPv4 [13] , и призвал к большему прогрессу в принятии IPv6.

Сравнение с IPv4

В Интернете данные передаются в виде сетевых пакетов . IPv6 определяет новый формат пакетов , разработанный для минимизации обработки заголовков пакетов маршрутизаторами. [2] [14] Поскольку заголовки пакетов IPv4 и пакетов IPv6 существенно различаются, эти два протокола несовместимы. Однако большинству транспортных и прикладных протоколов для работы через IPv6 требуются небольшие изменения или их отсутствие; исключения составляют прикладные протоколы, которые встраивают адреса интернет-уровня, такие как протокол передачи файлов (FTP) и сетевой протокол времени (NTP), где новый формат адреса может вызвать конфликты с существующим синтаксисом протокола.

Больше адресного пространства

Главное преимущество IPv6 над IPv4 — большее адресное пространство. Размер адреса IPv6 составляет 128 бит, по сравнению с 32 битами в IPv4. [2] Таким образом, адресное пространство имеет 2 128 = 340 282 366 920 938 463 463 374 607 431 768 211 456 адресов (340 ундециллионов , приблизительно3,4 × 10 38 ). Некоторые блоки этого пространства и некоторые конкретные адреса зарезервированы для специального использования .

Хотя это адресное пространство очень велико, разработчики IPv6 не ставили себе целью обеспечить географическую насыщенность пригодными для использования адресами. Напротив, более длинные адреса упрощают распределение адресов, обеспечивают эффективную агрегацию маршрутов и позволяют реализовать специальные функции адресации. В IPv4 были разработаны сложные методы бесклассовой междоменной маршрутизации (CIDR), чтобы наилучшим образом использовать небольшое адресное пространство. Стандартный размер подсети в IPv6 составляет 2 64 адреса, что примерно в четыре миллиарда раз больше размера всего адресного пространства IPv4. Таким образом, фактическое использование адресного пространства в IPv6 будет небольшим, но управление сетью и эффективность маршрутизации улучшаются за счет большого пространства подсетей и иерархической агрегации маршрутов.

Многоадресная рассылка

Структура многоадресной рассылки в IPv6

Многоадресная рассылка , передача пакета нескольким адресатам за одну операцию отправки, является частью базовой спецификации IPv6. В IPv4 это необязательная (хотя обычно реализуемая) функция. [15] Многоадресная адресация IPv6 имеет функции и протоколы, общие с многоадресной рассылкой IPv4, но также обеспечивает изменения и улучшения, устраняя необходимость в определенных протоколах. IPv6 не реализует традиционную широковещательную рассылку IP , т. е. передачу пакета всем хостам на присоединенном канале с использованием специального широковещательного адреса , и, следовательно, не определяет широковещательные адреса. В IPv6 тот же результат достигается путем отправки пакета в локальную для канала группу многоадресной рассылки всех узлов по адресу ff02::1, что аналогично многоадресной рассылке IPv4 по адресу 224.0.0.1. IPv6 также обеспечивает новые реализации многоадресной рассылки, включая встраивание адресов точек рандеву в адрес группы многоадресной рассылки IPv6, что упрощает развертывание междоменных решений. [16]

В IPv4 организации очень сложно получить даже одно глобально маршрутизируемое назначение многоадресной группы, а реализация междоменных решений является запутанной. [17] Назначение одноадресных адресов локальным интернет-реестром для IPv6 имеет по крайней мере 64-битный префикс маршрутизации, что дает наименьший размер подсети, доступный в IPv6 (также 64 бита). При таком назначении можно встроить префикс одноадресного адреса в формат многоадресного адреса IPv6, при этом по-прежнему предоставляя 32-битный блок, наименее значимые биты адреса или приблизительно 4,2 миллиарда идентификаторов многоадресных групп. Таким образом, каждый пользователь подсети IPv6 автоматически имеет доступный набор глобально маршрутизируемых групп многоадресной рассылки, специфичных для источника, для многоадресных приложений. [18]

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

Хосты IPv6 настраиваются автоматически. Каждый интерфейс имеет самогенерируемый локальный адрес связи, и при подключении к сети выполняется разрешение конфликтов, а маршрутизаторы предоставляют сетевые префиксы через объявления маршрутизатора. [19] Конфигурация маршрутизаторов без сохранения состояния может быть достигнута с помощью специального протокола перенумерации маршрутизаторов. [20] При необходимости хосты могут настраивать дополнительные адреса с сохранением состояния с помощью протокола динамической конфигурации хоста версии 6 (DHCPv6) или статических адресов вручную.

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

Стабильный, уникальный, адресуемый по всему миру IP-адрес облегчит отслеживание устройства в сетях. Поэтому такие адреса представляют особую проблему конфиденциальности для мобильных устройств, таких как ноутбуки и мобильные телефоны. [21] Для решения этих проблем конфиденциальности протокол SLAAC включает то, что обычно называют «адресами конфиденциальности» или, точнее, «временными адресами». [22] Временные адреса являются случайными и нестабильными. Типичное потребительское устройство ежедневно генерирует новый временный адрес и будет игнорировать трафик, адресованный на старый адрес, через неделю. Временные адреса используются по умолчанию в Windows, начиная с XP SP1, [23] macOS, начиная с (Mac OS X) 10.7, Android, начиная с 4.0, и iOS, начиная с версии 4.3. Использование временных адресов в дистрибутивах Linux различается. [24]

Перенумерация существующей сети для нового поставщика услуг связи с другими префиксами маршрутизации является серьезной задачей при использовании IPv4. [25] [26] [27] Однако при использовании IPv6 изменение префикса, объявленного несколькими маршрутизаторами, может в принципе перенумеровать всю сеть, поскольку идентификаторы хостов (младшие значимые 64 бита адреса) могут быть независимо настроены хостом. [19]

Метод генерации адресов SLAAC зависит от реализации. IETF рекомендует, чтобы адреса были детерминированными, но семантически непрозрачными. [28]

IPsec

Internet Protocol Security (IPsec) изначально был разработан для IPv6, но нашел широкое распространение сначала в IPv4, для которого он был переработан. IPsec был обязательной частью всех реализаций протокола IPv6, [2] и был рекомендован Internet Key Exchange (IKE), но с RFC 6434 включение IPsec в реализации IPv6 было понижено до рекомендации, поскольку было сочтено нецелесообразным требовать полной реализации IPsec для всех типов устройств, которые могут использовать IPv6. Однако, начиная с RFC 4301, реализации протокола IPv6, которые реализуют IPsec, должны реализовывать IKEv2 и должны поддерживать минимальный набор криптографических алгоритмов . Это требование поможет сделать реализации IPsec более совместимыми между устройствами от разных поставщиков. Заголовок аутентификации IPsec (AH) и заголовок инкапсуляции полезной нагрузки безопасности (ESP) реализованы как заголовки расширения IPv6. [29]

Упрощенная обработка маршрутизаторами

Заголовок пакета в IPv6 проще, чем заголовок IPv4. Многие редко используемые поля были перемещены в необязательные расширения заголовков. Заголовок пакета IPv6 упростил процесс пересылки пакетов маршрутизаторами . Хотя заголовки пакетов IPv6 по крайней мере вдвое больше заголовков пакетов IPv4, обработка пакетов, содержащих только базовый заголовок IPv6 маршрутизаторами, в некоторых случаях может быть более эффективной, поскольку маршрутизаторам требуется меньше обработки из-за того, что заголовки выравниваются в соответствии с общими размерами слов . [2] [14] Однако многие устройства реализуют поддержку IPv6 в программном обеспечении (в отличие от оборудования), что приводит к очень плохой производительности обработки пакетов. [30] Кроме того, для многих реализаций использование заголовков расширений приводит к тому, что пакеты обрабатываются центральным процессором маршрутизатора, что приводит к низкой производительности или даже проблемам безопасности. [31]

Более того, заголовок IPv6 не включает контрольную сумму. Контрольная сумма заголовка IPv4 вычисляется для заголовка IPv4 и должна пересчитываться маршрутизаторами каждый раз, когда время жизни (называемое пределом перехода в протоколе IPv6) уменьшается на единицу. Отсутствие контрольной суммы в заголовке IPv6 способствует сквозному принципу проектирования Интернета, который предполагает, что большая часть обработки в сети происходит в конечных узлах. Предполагается, что защита целостности данных, инкапсулированных в пакет IPv6, обеспечивается как канальным уровнем , так и обнаружением ошибок в протоколах более высокого уровня, а именно протоколом управления передачей (TCP) и протоколом пользовательских датаграмм (UDP) на транспортном уровне . Таким образом, в то время как IPv4 позволял заголовкам датаграмм UDP не иметь контрольной суммы (обозначенной 0 в поле заголовка), IPv6 требует контрольной суммы в заголовках UDP.

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

Мобильность

В отличие от мобильного IPv4, мобильный IPv6 избегает треугольной маршрутизации и поэтому так же эффективен, как и собственный IPv6. Маршрутизаторы IPv6 также могут позволять целым подсетям перемещаться в новую точку подключения маршрутизатора без перенумерации. [32]

Заголовки расширений

Несколько примеров заголовков расширения IPv6

Заголовок пакета IPv6 имеет минимальный размер 40 октетов (320 бит). Опции реализованы как расширения. Это дает возможность расширить протокол в будущем, не влияя на основную структуру пакета. [2] Однако в RFC 7872 отмечается, что некоторые сетевые операторы отбрасывают пакеты IPv6 с заголовками расширения, когда они проходят транзитные автономные системы .

Джамбограммы

IPv4 ограничивает пакеты до 65 535 (2 16 −1) октетов полезной нагрузки. Узел IPv6 может опционально обрабатывать пакеты сверх этого лимита, называемые джамбограммами , которые могут быть размером до 4 294 967 295 (2 32 −1) октетов. Использование джамбограмм может улучшить производительность на каналах с высоким MTU . Использование джамбограмм указывается в заголовке расширения Jumbo Payload Option. [33]

Пакеты IPv6

Заголовок пакета IPv6

Пакет IPv6 состоит из двух частей: заголовка и полезной нагрузки .

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

Фиксированный заголовок занимает первые 40  октетов (320 бит) пакета IPv6. Он содержит адреса источника и назначения, класс трафика, количество переходов и тип необязательного расширения или полезной нагрузки, которая следует за заголовком. Это поле Next Header сообщает получателю, как интерпретировать данные, которые следуют за заголовком. Если пакет содержит опции, это поле содержит тип опции следующей опции. Поле «Next Header» последней опции указывает на протокол верхнего уровня, который передается в полезной нагрузке пакета .

Текущее использование поля класса трафика IPv6 делит его на 6-битную точку кода дифференцированных услуг [34] и 2-битное поле явного уведомления о перегрузке . [35]

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

Без специальных опций полезная нагрузка должна быть менее 64 кБ . С опцией Jumbo Payload (в заголовке расширения Hop-By-Hop Options ) полезная нагрузка должна быть менее 4 ГБ.

В отличие от IPv4, маршрутизаторы никогда не фрагментируют пакет. Хосты должны использовать Path MTU Discovery , чтобы сделать свои пакеты достаточно маленькими, чтобы достичь пункта назначения без необходимости фрагментации. См. фрагментация пакетов IPv6 .

Адресация

Общая структура одноадресного адреса IPv6

Адреса IPv6 имеют 128 бит. Проект адресного пространства IPv6 реализует иную философию проектирования, чем в IPv4, в котором подсети использовались для повышения эффективности использования небольшого адресного пространства. В IPv6 адресное пространство считается достаточно большим для обозримого будущего, и локальная подсеть всегда использует 64 бита для хостовой части адреса, обозначенной как идентификатор интерфейса, в то время как наиболее значимые 64 бита используются как префикс маршрутизации. [36] : 9  Хотя существовал миф о том, что подсети IPv6 невозможно сканировать, RFC 7707 отмечает, что шаблоны, полученные в результате некоторых методов и алгоритмов конфигурации адресов IPv6, позволяют сканировать адреса во многих реальных сценариях.

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

128 бит адреса IPv6 представлены в 8 группах по 16 бит в каждой. Каждая группа записывается в виде четырех шестнадцатеричных цифр (иногда называемых гекстетами [37] [38] или более формально гексадектетами [39] и неформально квиблом или квадро-нибблом [39] ), а группы разделяются двоеточиями (:). Примером такого представления является 2001:0db8:0000:0000:0000:ff00:0042:8329 .

Для удобства и ясности представление адреса IPv6 можно сократить с помощью следующих правил:

Пример применения этих правил:

Начальный адрес: 2001:0db8:0000:0000:0000:ff00:0042:8329 .
После удаления всех начальных нулей в каждой группе: 2001:db8:0:0:0:ff00:42:8329 .
После пропуска последовательных секций нулей: 2001:db8::ff00:42:8329 .

Адрес обратной связи определяется как 0000:0000:0000:0000:0000:0000:0000:0001 [41] и сокращается до ::1 с использованием обоих правил.

Поскольку адрес IPv6 может иметь более одного представления, IETF выпустила предлагаемый стандарт для представления их в тексте . [40]

Поскольку адреса IPv6 содержат двоеточия, а в URL-адресах двоеточия используются для отделения хоста от номера порта, адрес IPv6, используемый в качестве хостовой части URL-адреса, следует заключать в квадратные скобки, [42] например http://[2001:db8:4006:812::200e] или http://[2001:db8:4006:812::200e]:8080/path/page.html.

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

Структура локального одноадресного адреса в IPv6

Все интерфейсы хостов IPv6 требуют адрес локальной ссылки , который имеет префикс fe80:: / 10. За этим префиксом следуют 54 бита, которые могут использоваться для подсетей, хотя они обычно устанавливаются в нули, и 64-битный идентификатор интерфейса. Хост может вычислить и назначить идентификатор интерфейса самостоятельно без присутствия или сотрудничества внешнего сетевого компонента, такого как сервер DHCP, в процессе, называемом автоконфигурацией локальной ссылки . [ необходима цитата ]

Нижние 64 бита локального адреса (суффикс) изначально были получены из MAC-адреса базовой сетевой карты. Поскольку этот метод назначения адресов мог вызвать нежелательные изменения адресов при замене неисправных сетевых карт, а также поскольку он страдал от ряда проблем безопасности и конфиденциальности, RFC  8064 заменил исходный метод на основе MAC-адреса на метод на основе хэша, указанный в RFC  7217. [ необходима цитата ]

Уникальность адреса и запрос маршрутизатора

IPv6 использует новый механизм для сопоставления IP-адресов с адресами канального уровня (например, MAC-адресами ), поскольку он не поддерживает метод широковещательной адресации, на котором основана функциональность протокола разрешения адресов (ARP) в IPv4. IPv6 реализует протокол обнаружения соседей (NDP, ND) на канальном уровне , который опирается на ICMPv6 и многоадресную передачу. [5] : 210  хостов IPv6 проверяют уникальность своих адресов IPv6 в локальной сети (LAN), отправляя сообщение запроса соседа с запросом адреса канального уровня IP-адреса. Если какой-либо другой хост в LAN использует этот адрес, он отвечает. [43]

Хост, запускающий новый интерфейс IPv6, сначала генерирует уникальный локальный адрес с помощью одного из нескольких механизмов, разработанных для генерации уникального адреса. Если будет обнаружен неуникальный адрес, хост может повторить попытку с новым сгенерированным адресом. После того, как будет установлен уникальный локальный адрес с помощью, хост IPv6 определяет, подключена ли локальная сеть по этой ссылке к любому интерфейсу маршрутизатора , который поддерживает IPv6. Он делает это, отправляя сообщение запроса маршрутизатора ICMPv6 в многоадресную группу all-routers [44] со своим локальным адресом с помощью источника. Если после определенного количества попыток ответа нет, хост делает вывод, что ни один маршрутизатор не подключен. Если он получает ответ, известный как объявление маршрутизатора, от маршрутизатора, ответ включает информацию о конфигурации сети, чтобы разрешить установку глобально уникального адреса с соответствующим префиксом одноадресной сети. [45] Также есть два бита флага, которые сообщают хосту, следует ли ему использовать DHCP для получения дополнительной информации и адресов:

Глобальная адресация

Глобальная структура одноадресной рассылки в IPv6

Процедура назначения глобальных адресов похожа на построение локальных адресов. Префикс предоставляется из объявлений маршрутизатора в сети. Несколько объявлений префикса приводят к настройке нескольких адресов. [43]

Автоконфигурация адресов без сохранения состояния (SLAAC) требует блока адресов / 64. [36] Локальным интернет-реестрам назначается не менее / 32 блоков, которые они делят между подчиненными сетями. [46] Первоначальная рекомендация от сентября 2001 года гласила назначение подсети / 48 сайтам конечных потребителей. [47] В марте 2011 года эта рекомендация была уточнена: [48] IETF « рекомендует давать домашним сайтам значительно больше, чем один / 64 , но не рекомендует, чтобы каждому домашнему сайту давали / 48 ». Блоки / 56 рассматриваются специально. Еще неизвестно, будут ли интернет-провайдеры соблюдать эту рекомендацию. Например, во время первоначальных испытаний клиентам Comcast была предоставлена ​​одна сеть / 64. [49]

IPv6 в системе доменных имен

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

Когда хост с двойным стеком запрашивает DNS-сервер для разрешения полностью квалифицированного доменного имени (FQDN), DNS-клиент хоста отправляет два DNS-запроса, один из которых запрашивает записи A, а другой — записи AAAA. Операционная система хоста может быть настроена с предпочтением правил выбора адреса RFC  6724. [50]

Альтернативный тип записи использовался в ранних реализациях DNS для IPv6, разработанных для облегчения сетевой перенумерации, записи A6 для прямого поиска и ряд других инноваций, таких как метки битовых строк и записи DNAME . Он определен в RFC  2874 и его ссылках (с дальнейшим обсуждением плюсов и минусов обеих схем в RFC  3364), но был устарел до экспериментального статуса ( RFC  3363).

Механизмы перехода

Не предполагается, что IPv6 мгновенно заменит IPv4. Оба протокола будут продолжать работать одновременно в течение некоторого времени. Поэтому необходимы механизмы перехода IPv6 , чтобы позволить хостам IPv6 достичь служб IPv4 и позволить изолированным хостам IPv6 и сетям достичь друг друга через инфраструктуру IPv4. [51]

По словам Сильвии Хаген , реализация двух стеков IPv4 и IPv6 на устройствах — самый простой способ перехода на IPv6. [52] Многие другие механизмы перехода используют туннелирование для инкапсуляции трафика IPv6 в сетях IPv4 и наоборот. Это несовершенное решение, которое уменьшает максимальный блок передачи (MTU) соединения и, следовательно, усложняет обнаружение MTU пути и может увеличить задержку . [53] [54]

Реализация двухстековой IP-сети

Реализации IP с двойным стеком предоставляют полные стеки протоколов IPv4 и IPv6 в операционной системе компьютера или сетевого устройства поверх общей реализации физического уровня , такой как Ethernet . Это позволяет хостам с двойным стеком одновременно участвовать в сетях IPv6 и IPv4. [55]

Устройство с реализацией двойного стека в операционной системе имеет адрес IPv4 и IPv6 и может взаимодействовать с другими узлами в локальной сети или Интернете, используя либо IPv4, либо IPv6. Протокол DNS используется обоими протоколами IP для разрешения полностью определенных доменных имен и IP-адресов, но двойной стек требует, чтобы разрешающий сервер DNS мог разрешать оба типа адресов. Такой сервер DNS с двойным стеком хранит адреса IPv4 в записях A и адреса IPv6 в записях AAAA. В зависимости от назначения, которое должно быть разрешено, сервер имен DNS может возвращать IP-адрес IPv4 или IPv6, или оба. Механизм выбора адреса по умолчанию или предпочтительный протокол необходимо настроить либо на хостах, либо на сервере DNS. IETF опубликовал Happy Eyeballs для помощи приложениям с двойным стеком, чтобы они могли подключаться с использованием как IPv4, так и IPv6, но предпочитали соединение IPv6, если оно доступно. Однако двойной стек также необходимо реализовать на всех маршрутизаторах между хостом и службой, для которой DNS-сервер вернул адрес IPv6. Клиенты с двойным стеком должны быть настроены на предпочтение IPv6 только в том случае, если сеть может пересылать пакеты IPv6 с использованием версий протоколов маршрутизации IPv6 . Когда используются сетевые протоколы с двойным стеком, прикладной уровень может быть перенесен на IPv6. [56]

Хотя двойной стек поддерживается основными поставщиками операционных систем и сетевых устройств, устаревшее сетевое оборудование и серверы не поддерживают IPv6.

Клиенты интернет-провайдеров с общедоступным IPv6

Механизм назначения префикса IPv6 с IANA, RIR и интернет-провайдерами

Интернет-провайдеры (ISP) все чаще предоставляют своим корпоративным и частным клиентам общедоступные глобальные одноадресные IPv6-адреса. Однако, если IPv4 все еще используется в локальной сети (LAN), и ISP может предоставить только один общедоступный IPv6-адрес, IPv4-адреса локальной сети преобразуются в общедоступный IPv6-адрес с помощью NAT64 , механизма трансляции сетевых адресов (NAT). Некоторые ISP не могут предоставить своим клиентам общедоступные IPv4- и IPv6-адреса, тем самым поддерживая двухстековую сеть, поскольку некоторые ISP исчерпали свой глобально маршрутизируемый пул IPv4-адресов. Между тем, клиенты ISP все еще пытаются достичь веб-серверов IPv4 и других пунктов назначения. [57]

Значительный процент интернет-провайдеров во всех зонах региональных интернет-регистраторов (RIR) получили адресное пространство IPv6. Это включает в себя многих крупнейших мировых интернет-провайдеров и операторов мобильной связи , таких как Verizon Wireless , StarHub Cable , Chubu Telecommunications , Kabel Deutschland , Swisscom , T-Mobile , Internode и Telefónica . [58]

В то время как некоторые интернет-провайдеры по-прежнему выделяют клиентам только адреса IPv4, многие интернет-провайдеры выделяют своим клиентам только IPv6 или IPv4 и IPv6 с двойным стеком. Интернет-провайдеры сообщают, что доля трафика IPv6 от клиентов по их сети составляет от 20% до 40%, но к середине 2017 года трафик IPv6 по-прежнему составлял лишь часть общего трафика в нескольких крупных точках обмена интернет-трафиком (IXP). AMS-IX сообщил, что он составлял 2%, а SeattleIX — 7%. Опрос 2017 года показал, что многие клиенты DSL, обслуживаемые интернет-провайдером с двойным стеком, не запрашивали DNS-серверы для преобразования полностью определенных доменных имен в адреса IPv6. Опрос также показал, что большая часть трафика с ресурсов веб-сервера с поддержкой IPv6 по-прежнему запрашивалась и обслуживалась по IPv4, в основном из-за клиентов интернет-провайдеров, которые не использовали функцию двойного стека, предоставляемую их интернет-провайдером, и в меньшей степени из-за клиентов интернет-провайдеров, поддерживающих только IPv4. [59]

Туннелирование

Техническая основа туннелирования или инкапсуляции пакетов IPv6 в пакеты IPv4 изложена в RFC 4213. Когда магистраль Интернета работала только на IPv4, одним из часто используемых протоколов туннелирования был 6to4 . [60] Туннелирование Teredo также часто использовалось для интеграции локальных сетей IPv6 с магистралью Интернета IPv4. Teredo изложен в RFC 4380 и позволяет локальным сетям IPv6 туннелировать через сети IPv4, инкапсулируя пакеты IPv6 в UDP. Ретранслятор Teredo — это маршрутизатор IPv6, который является посредником между сервером Teredo и собственной сетью IPv6. Ожидалось, что 6to4 и Teredo будут широко развернуты до тех пор, пока сети интернет-провайдеров не перейдут на собственный IPv6, но к 2014 году статистика Google показала, что использование обоих механизмов упало почти до 0. [61]

Адреса IPv6, сопоставленные с IPv4

IPv4-совместимый одноадресный IPv6-адрес
IPv4-сопоставленный одноадресный IPv6-адрес

Гибридные реализации IPv6/IPv4 с двойным стеком распознают специальный класс адресов — IPv4-сопоставленные адреса IPv6. [62] : §2.2.3  [36] Эти адреса обычно записываются с 96-битным префиксом в стандартном формате IPv6, а оставшиеся 32 бита записываются в обычной точечно-десятичной нотации IPv4.

Адреса в этой группе состоят из 80-битного префикса нулей, следующие 16 бит — единицы, а оставшиеся, наименее значимые 32 бита содержат адрес IPv4. Например, ::ffff:192.0.2.128 представляет адрес IPv4 192.0.2.128 . Предыдущий формат, называемый «IPv4-совместимый адрес IPv6», был ::192.0.2.128 ; однако этот метод устарел. [36]

Из-за существенных внутренних различий между стеками протоколов IPv4 и IPv6 некоторые из низкоуровневых функций, доступных программистам в стеке IPv6, не работают одинаково при использовании с сопоставленными IPv4 адресами. Некоторые распространенные стеки IPv6 не реализуют функцию сопоставленных IPv4 адресов либо потому, что стеки IPv6 и IPv4 являются отдельными реализациями (например, Microsoft Windows 2000, XP и Server 2003), либо из-за проблем безопасности ( OpenBSD ). [63] В этих операционных системах программа должна открывать отдельный сокет для каждого используемого ею протокола IP. В некоторых системах, например, ядре Linux , NetBSD и FreeBSD , эта функция управляется опцией сокета IPV6_V6ONLY. [64] : 22 

Префикс адреса 64:ff9b::/96 представляет собой класс IPv6-адресов, встроенных в IPv4, для использования в методах перехода NAT64 . [65] Например, 64:ff9b::192.0.2.128 представляет IPv4-адрес 192.0.2.128 .

Безопасность

Использование IPv6 может привести к ряду последствий для безопасности. Некоторые из них могут быть связаны с самими протоколами IPv6, в то время как другие могут быть связаны с недостатками реализации. [66] [67]

Теневые сети

Добавление узлов, в которых производитель программного обеспечения включил IPv6 по умолчанию, может привести к непреднамеренному созданию теневых сетей , в результате чего трафик IPv6 будет поступать в сети, в которых реализовано только управление безопасностью IPv4. Это также может произойти при обновлении операционной системы, когда новая операционная система включает IPv6 по умолчанию, а старая — нет. Невыполнение обновления инфраструктуры безопасности для поддержки IPv6 может привести к тому, что трафик IPv6 будет обходить его. [68] Теневые сети возникали в бизнес-сетях, в которых предприятия заменяли системы Windows XP , в которых стек IPv6 не включен по умолчанию, на системы Windows 7 , в которых он включен. [69] Поэтому некоторые разработчики стека IPv6 рекомендовали отключить сопоставленные адреса IPv4 и вместо этого использовать сеть с двойным стеком, где необходима поддержка как IPv4, так и IPv6. [70]

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

Исследования показали, что использование фрагментации может быть использовано для обхода контроля сетевой безопасности, аналогичного IPv4. В результате RFC  7112 требует, чтобы первый фрагмент пакета IPv6 содержал всю цепочку заголовков IPv6, так что некоторые очень патологические случаи фрагментации запрещены. Кроме того, в результате исследования обхода RA-Guard в RFC  7113, RFC  6980 устарело использование фрагментации с Neighbor Discovery и не поощряет использование фрагментации с Secure Neighbor Discovery (SEND).

Стандартизация посредством RFC

Предложения рабочей группы

Хронология стандартов, регулирующих IPv6

В связи с ожидаемым глобальным ростом Интернета , в начале 1990-х годов Группа инженеров Интернета (IETF) начала работу по разработке протокола IP следующего поколения. [5] : 209  К началу 1992 года появилось несколько предложений по расширенной системе адресации Интернета, а к концу 1992 года IETF объявила о приеме официальных документов. [71] В сентябре 1993 года IETF создала временную специальную область IP Next Generation (IPng) для решения именно таких вопросов. Новое направление возглавляли Эллисон Мэнкин и Скотт Брэднер , а также имело дирекцию из 15 инженеров с различным опытом для определения направлений и предварительного обзора документов: [7] [72] Членами рабочей группы были Дж. Аллард (Microsoft), Стив Белловин (AT&T), Джим Баунд (Digital Equipment Corporation), Росс Каллон (Wellfleet), Брайан Карпентер (CERN), Дэйв Кларк (MIT), Джон Карран (NEARNET), Стив Диринг (Xerox), Дино Фариначчи (Cisco), Пол Фрэнсис (NTT), Эрик Флейшманн (Boeing), Марк Кноппер (Ameritech), Грег Миншалл (Novell), Роб Ульманн (Lotus) и Лися Чжан (Xerox). [73]

Рабочая группа по инжинирингу Интернета приняла модель IPng 25 июля 1994 года, сформировав несколько рабочих групп IPng. [7] К 1996 году был выпущен ряд RFC, определяющих версию 6 Интернет-протокола (IPv6), начиная с RFC  1883. (Версия 5 использовалась экспериментальным протоколом Internet Stream Protocol .)

Стандартизация RFC

Первым RFC для стандартизации IPv6 был RFC  1883 в 1995 году, [74] который устарел с появлением RFC  2460 в 1998 году. [5] : 209  В июле 2017 года этот RFC был заменен RFC  8200, который повысил IPv6 до «стандарта Интернета» (высший уровень зрелости для протоколов IETF). [3]

Развертывание

Ежемесячное распределение IPv6 по региональному интернет-регистратору (RIR)

Внедрение в 1993 году бесклассовой междоменной маршрутизации (CIDR) в маршрутизацию и распределение IP-адресов для Интернета, а также широкое использование трансляции сетевых адресов (NAT) задержали исчерпание адресов IPv4 , что позволило начать развертывание IPv6, которое началось в середине 2000-х годов.

Университеты были среди первых, кто принял IPv6. Virginia Tech развернул IPv6 в тестовом режиме в 2004 году, а затем расширил развертывание IPv6 по всей сети кампуса . К 2016 году 82% трафика в их сети использовало IPv6. Imperial College London начал экспериментальное развертывание IPv6 в 2003 году, и к 2016 году трафик IPv6 в их сетях в среднем составлял от 20% до 40%. Значительная часть этого трафика IPv6 была сгенерирована в результате их сотрудничества в области физики высоких энергий с CERN , который полностью полагается на IPv6. [75]

Система доменных имен (DNS) поддерживает IPv6 с 2008 года. В том же году IPv6 был впервые использован на крупном мировом мероприятии во время летних Олимпийских игр 2008 года в Пекине . [76] [77]

К 2011 году все основные операционные системы, используемые на персональных компьютерах и серверных системах, имели качественные реализации IPv6. Сотовые телефонные системы представляли собой обширное поле для развертывания устройств на основе интернет-протокола, поскольку мобильная телефонная связь перешла с технологий 3G на 4G , в которых голос предоставляется как услуга передачи голоса по IP (VoIP), которая будет использовать усовершенствования IPv6. В 2009 году американский оператор сотовой связи Verizon выпустил технические спецификации для устройств, работающих в его сетях «следующего поколения». [78] Спецификация предписывала работу IPv6 в соответствии со спецификациями 3GPP Release 8 (март 2009 года) и исключала IPv4 как необязательную возможность. [78]

Развертывание IPv6 в магистральной сети Интернет продолжалось. В 2018 году только 25,3% из примерно 54 000 автономных систем анонсировали как префиксы IPv4, так и IPv6 в глобальной базе данных маршрутизации Border Gateway Protocol (BGP). Еще 243 сети анонсировали только префикс IPv6. Магистральные транзитные сети Интернет, предлагающие поддержку IPv6, существовали в каждой стране мира, за исключением некоторых частей Африки , Ближнего Востока и Китая. [79] : 6  К середине 2018 года некоторые крупные европейские поставщики широкополосного доступа в Интернет развернули IPv6 для большинства своих клиентов. Sky UK предоставила более 86% своих клиентов IPv6, Deutsche Telekom развернула 56% IPv6, XS4ALL в Нидерландах развернула 73%, а в Бельгии поставщики широкополосного доступа в Интернет VOO и Telenet развернули 73% и 63% IPv6 соответственно. [79] : 7  В Соединенных Штатах широкополосный интернет-провайдер Xfinity имел развертывание IPv6 около 66%. В 2018 году Xfinity сообщила о приблизительно 36,1 миллионах пользователей IPv6, в то время как AT&T сообщила о 22,3 миллионах пользователей IPv6. [79] : 7–8 

Проблемы с пирингом

Между Hurricane Electric и Cogent Communications идет пиринговый спор по IPv6, при этом два сетевых провайдера отказываются от пирингового взаимодействия. [80]

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

Ссылки

  1. ^ "FAQs". New Zealand IPv6 Task Force. Архивировано из оригинала 29 января 2019 года . Получено 26 октября 2015 года .
  2. ^ abcdef S. Deering ; R. Hinden (декабрь 1998 г.), Спецификация протокола Интернета версии 6 (IPv6) , Internet Engineering Task Force (IETF), RFC 2460 Отменяет действие RFC 1883.
  3. ^ ab S. Deering ; R. Hinden (июль 2017 г.), «Спецификация интернет-протокола версии 6 (IPv6)», Страницы запросов на комментарии (RFC) IETF – Тест , Internet Engineering Task Force (IETF), ISSN  2070-1721, RFC 8200 Отменяет действие RFC 2460.
  4. ^ Сиддики, Афтаб (17 июля 2017 г.). «RFC 8200 – IPv6 был стандартизирован». Internet Society . Архивировано из оригинала 23 октября 2023 г. . Получено 25 февраля 2018 г. .
  5. ^ abcd Rosen, Rami (2014). Linux Kernel Networking: Implementation and Theory . Нью-Йорк: Apress. ISBN 9781430261971. OCLC  869747983.
  6. ^ Google IPv6 Conference 2008: Как будет выглядеть Интернет IPv6?. Событие происходит в 13:35. Архивировано из оригинала 11 декабря 2021 года.
  7. ^ abc Bradner, S.; Mankin, A. (январь 1995 г.). Рекомендация по протоколу IP следующего поколения. IETF . doi : 10.17487/RFC1752 . RFC 1752.
  8. ^ "Free Pool of IPv4 Address Space Depleted". NRO.net . Монтевидео : Организация номерных ресурсов. 3 февраля 2011 г. Архивировано из оригинала 18 января 2024 г. Получено 19 января 2022 г.
  9. ^ Рашид, Фахмида (1 февраля 2011 г.). «Исчерпание адресов IPv4 — не мгновенная причина для беспокойства по поводу IPv6 в Wings». eWeek. Архивировано из оригинала 20 января 2024 г. Получено 23 июня 2012 г.
  10. ^ Уорд, Марк (14 сентября 2012 г.). «Европа достигает старых ограничений интернет-адресов». BBC News . Архивировано из оригинала 5 ноября 2023 г. Получено 15 сентября 2012 г.
  11. ^ Хьюстон, Джефф. "IPV4 Address Report". Архивировано из оригинала 10 января 2024 г.
  12. ^ "FAQ". my.afrinic.net . AFRINIC . Архивировано из оригинала 23 октября 2023 г. Получено 28 ноября 2018 г.
  13. ^ "RIPE NCC закончились адреса IPv4" (пресс-релиз). RIPE NCC . 25 ноября 2019 г. Архивировано из оригинала 19 января 2024 г. Получено 26 ноября 2019 г.
  14. ^ ab Партридж, К.; Кастенхольц, Ф. (декабрь 1994 г.). «Технические критерии выбора IP следующего поколения (IPng)». RFC 1726 . 
  15. ↑ RFC  1112, Расширения хоста для многоадресной IP-рассылки , С. Диринг (август 1989 г.)
  16. ^ RFC  3956, Встраивание адреса точки встречи (RP) в многоадресный адрес IPv6 , П. Савола, Б. Хаберман (ноябрь 2004 г.)
  17. ^ RFC  2908, Архитектура распределения адресов многоадресной рассылки в Интернете , Д. Талер, М. Хэндли, Д. Эстрин (сентябрь 2000 г.)
  18. ^ RFC  3306, Многоадресные адреса IPv6 на основе одноадресного префикса , Б. Хаберман, Д. Талер (август 2002 г.)
  19. ^ ab S. Thomson; T. Narten; T. Jinmei (сентябрь 2007 г.). Автоматическая конфигурация IPv6-адресов без сохранения состояния. Сетевая рабочая группа. doi : 10.17487/RFC4862 . RFC 4862. Проект стандарта. Отменяет RFC 2462. Обновлен RFC 7527.
  20. ^ М. Кроуфорд (август 2000 г.). Изменение нумерации маршрутизаторов для IPv6. Сетевая рабочая группа. doi : 10.17487/RFC2894 . RFC 2894. Предлагаемый стандарт.
  21. ^ T. Narten; R. Draves; S. Krishnan (сентябрь 2007 г.). «Расширения конфиденциальности для автоконфигурации адресов без сохранения состояния в IPv6». www.ietf.org . Получено 13 марта 2017 г. .
  22. ^ 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.
  23. ^ "Обзор Advanced Networking Pack для Windows XP". Microsoft . Архивировано из оригинала 7 сентября 2017 г. Получено 15 апреля 2019 г.
  24. ^ "Privacy Extensions for IPv6 SLAAC". Internet Society . 8 августа 2014 г. Архивировано из оригинала 23 октября 2023 г. Получено 17 января 2020 г.
  25. ^ P. Ferguson; H. Berkowitz (январь 1997 г.). Обзор перенумерации сетей: зачем она мне и что это вообще такое?. Сетевая рабочая группа. doi : 10.17487/RFC2071 . RFC 2071. Информационный.
  26. ^ Фергюсон, П.; Берковиц, Х. (январь 1997 г.). «Обзор перенумерации сетей: зачем она мне и что это вообще такое?». IETF . doi :10.17487/RFC2071. RFC 2071 . Архивировано из оригинала 7 января 2024 г. 
  27. ^ Berkowitz, H. (январь 1997 г.). «Руководство по перенумерации маршрутизаторов». IETF . doi :10.17487/RFC2072. RFC 2072 . Архивировано из оригинала 8 июня 2023 г. 
  28. ^ Купер, Алисса; Гонт, Фернандо; Талер, Дэйв. Рекомендации по стабильным идентификаторам интерфейсов IPv6. doi : 10.17487/RFC8064 . RFC 8064.
  29. ^ Сильвия Хаген (2014). Основы IPv6: Интеграция IPv6 в вашу сеть IPv4 (3-е изд.). Севастополь, Калифорния: O'Reilly Media. стр. 196. ISBN 978-1-4493-3526-7. OCLC  881832733.
  30. ^ Зак, Э. (июль 2013 г.). «Оценка и сравнительный анализ безопасности IPv6».
  31. ^ Gont, F. (март 2016 г.). «Эксплуатационные последствия пакетов IPv6 с заголовками расширения». IETF . Архивировано из оригинала 27 октября 2023 г.
  32. ^ V. Devarapalli; R. Wakikawa; A. Petrescu; P. Thubert (январь 2005 г.). Базовый протокол поддержки сетевой мобильности (NEMO). Сетевая рабочая группа. doi : 10.17487/RFC3963 . RFC 3963. Предлагаемый стандарт.
  33. ^ D. Borman; S. Deering ; R. Hinden (август 1999). IPv6 Jumbograms. Сетевая рабочая группа. doi : 10.17487/RFC2675 . RFC 2675. Предложенный стандарт. Отменяет RFC 2147.
  34. ^ К. Николс; С. Блейк; Ф. Бейкер ; Д. Блэк (декабрь 1998 г.). Определение поля дифференцированных услуг (поле DS) в заголовках IPv4 и IPv6. Сетевая рабочая группа. doi : 10.17487/RFC2474 . RFC 2474. Предложенный стандарт. Отменяет RFC 1455 и 1349. Обновлен RFC 3168, 3260 и 8436.
  35. ^ K. Ramakrishnan; S. Floyd; D. Black (сентябрь 2001 г.). Добавление явного уведомления о перегрузке (ECN) к IP. Сетевая рабочая группа. doi : 10.17487/RFC3168 . RFC 3168. Предложенный стандарт. Отменяет RFC 2481. Обновляет RFC 2474, 2401 и 793. Обновлен RFC 4301, 6040 и 8311.
  36. ^ abcd R. Hinden; S. Deering (февраль 2006 г.). Архитектура адресации IP версии 6. Сетевая рабочая группа. doi : 10.17487/RFC4291 . RFC 4291. Проект стандарта. Отменяет RFC 3513. Обновлен RFC 5952, 6052, 7136, 7346, 7371 и 8064.
  37. ^ Грациани, Рик (2012). Основы IPv6: Прямой подход к пониманию IPv6. Cisco Press . стр. 55. ISBN 978-0-13-303347-2.
  38. ^ Коффен, Том (2014). Планирование адресов IPv6: Разработка плана адресов для будущего. O'Reilly Media . стр. 170. ISBN 978-1-4919-0326-1.
  39. ^ ab Хорли, Эдвард (2013). Практический IPv6 для администраторов Windows. Apress . стр. 17. ISBN 978-1-4302-6371-5.
  40. ^ ab S. Kawamura; M. Kawashima (август 2010 г.). Рекомендация по текстовому представлению адресов IPv6. Internet Engineering Task Force . doi : 10.17487/RFC5952 . ISSN  2070-1721. RFC 5952. Предложенный стандарт. Обновления RFC 4291.
  41. ^ М. Бланше (апрель 2008 г.). Адреса IPv6 специального назначения. Сетевая рабочая группа. doi : 10.17487/RFC5156 . RFC 5156. Предложенный стандарт. Устаревший из-за RFC 6890.
  42. ^ 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.
  43. ^ abc Narten, T. (август 1999 г.). «Обнаружение соседей и автоконфигурация без сохранения состояния в IPv6». IEEE Internet Computing . 3 (4): 54–62. doi :10.1109/4236.780961.
  44. ^ Narten, T. (сентябрь 2007 г.). «Обнаружение соседей для IP версии 6 (IPv6)». IETF . раздел 6.3.7. doi : 10.17487/RFC4861 . RFC 4861. Архивировано из оригинала 17 января 2024 г. 
  45. ^ Томсон, С. (сентябрь 2007 г.). «Автоконфигурация IPv6 Stateless Address — раздел 5.5.1». IETF . doi :10.17487/RFC4862. RFC 4862 . Архивировано из оригинала 11 января 2024 г. 
  46. ^ "Политика распределения и назначения адресов IPv6". RIPE NCC . 8 февраля 2011 г. Архивировано из оригинала 3 июня 2023 г. Получено 27 марта 2011 г.
  47. ^ IAB ; IESG (сентябрь 2001 г.). Рекомендации IAB/IESG по распределению адресов IPv6 для сайтов. Сетевая рабочая группа. doi : 10.17487/RFC3177 . RFC 3177. Устарело. Устарело согласно RFC 6177.
  48. ^ 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.
  49. ^ Brzozowski, John (31 января 2011 г.). «Comcast Activates First Users With IPv6 Native Dual Stack Over DOCSIS» (пресс-релиз). Comcast . Архивировано из оригинала 23 октября 2023 г. . Получено 15 апреля 2019 г. .
  50. ^ Сильвия Хаген (2014). Основы IPv6: Интеграция IPv6 в вашу сеть IPv4 . O'Reilly Media, Inc. стр. 176. ISBN 9781449335267.
  51. ^ "Механизм перехода IPv6/Сравнение туннелирования". Sixxs.net. Архивировано из оригинала 23 октября 2023 г. Получено 20 января 2012 г.
  52. ^ Сильвия Хаген (2014). Основы IPv6: Интеграция IPv6 в вашу сеть IPv4 . O'Reilly Media, Inc. стр. 222–223. ISBN 9781449335267.
  53. ^ Карпентер, Б. (август 2011 г.). «Рекомендательные рекомендации по развертыванию 6to4». IETF . doi : 10.17487/RFC6343 . RFC 6343 . Архивировано из оригинала 28 января 2023 г. . Получено 20 августа 2012 г. . 
  54. ^ "IPv6: двойной стек, где можно; туннель, где необходимо". networkworld.com. 5 сентября 2007 г. Архивировано из оригинала 20 января 2024 г. Получено 27 ноября 2012 г.
  55. ^ E. Nordmark; R. Gilligan (октябрь 2005 г.). Основные механизмы перехода для хостов и маршрутизаторов IPv6. Сетевая рабочая группа. doi : 10.17487/RFC4213 . RFC 4213. Предложенный стандарт. Отменяет RFC 2893.
  56. ^ Сильвия Хаген (2014). Основы IPv6: Интеграция IPv6 в вашу сеть IPv4 . O'Reilly Media, Inc. стр. 222. ISBN 9781449335267.
  57. ^ «Понимание двойного стекирования адресов IPv4 и IPv6 Unicast». Juniper.net . Juniper Networks. 31 августа 2017 г. . Получено 19 января 2022 г. .
  58. ^ "IPv6". NRO.net . Архивировано из оригинала 12 января 2017 года . Получено 13 марта 2017 года .
  59. ^ Пуйоль, Энрик (12 июня 2017 г.). «Что останавливает трафик IPv6 у интернет-провайдера с двойным стеком?». APNIC.net . APNIC . Архивировано из оригинала 27 марта 2023 г. . Получено 13 июня 2017 г. .
  60. ^ Vaughan-Nichols, Steven J. (14 октября 2010 г.). «Пять способов мирного сосуществования IPv6 и IPv4». ZDNET . Архивировано из оригинала 5 декабря 2023 г. Получено 13 марта 2017 г.
  61. ^ Сильвия Хаген (2014). Основы IPv6: Интеграция IPv6 в вашу сеть IPv4 . O'Reilly Media, Inc. стр. 33. ISBN 9781449335267.
  62. ^ 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.
  63. ^ inet6(4)  –  Руководство по интерфейсам ядра OpenBSD
  64. ^ R. Gilligan; S. Thomson; J. Bound; J. McCann; W. Stevens (февраль 2003 г.). Базовые расширения интерфейса сокетов для IPv6. Сетевая рабочая группа. doi : 10.17487/RFC3493 . RFC 3493.
  65. ^ 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.
  66. ^ Gont, Fernando (10 марта 2019 г.), Безопасность IPv6 для инженеров IPv4 (PDF) , получено 30 августа 2019 г.
  67. ^ Gont, Fernando (10 января 2019 г.), Часто задаваемые вопросы (FAQ) по безопасности IPv6 (PDF) , получено 30 августа 2019 г.
  68. ↑ Маллинз, Роберт (5 апреля 2012 г.), Теневые сети: непреднамеренный побочный эффект IPv6, архивировано из оригинала 11 апреля 2013 г. , извлечено 2 марта 2013 г.
  69. ^ Cicileo, Guillermo; Gagliano, Roque; O'Flaherty, Christian; et al. (октябрь 2009 г.). IPv6 для всех: руководство по использованию и применению IPv6 в различных средах (PDF) . стр. 5. Получено 2 марта 2013 г.
  70. ↑ Дзюнъитиро итодзюн Хагино (октябрь 2003 г.). «IPv4-сопоставленные адреса в сети считаются вредоносными».
  71. ^ Брэднер, С.; Манкин, А. (декабрь 1993 г.). «IP: Следующее поколение (IPng) White Paper Solicitation». RFC 1550 . 
  72. ^ "История усилий IPng". The Sun. Архивировано из оригинала 23 мая 2014 года.
  73. ^ Брэднер, Скотт О.; Манкин, Эллисон Дж. (январь 1995 г.). «Рекомендация по протоколу IP следующего поколения – Приложение B». RFC 1752 . 
  74. ^ Ван, Тао; Гао, Цзяцюн (1 января 2019 г.). «Недостатки IPv6 и обновление IPv4». Международный журнал передовых сетей, мониторинга и управления . 4 (1): 1–9. doi : 10.21307/ijanmc-2019-029 .
  75. ^ Состояние развертывания IPv6 в 2018 году, Internet Society , 2018, стр. 3
  76. ^ "Beijing2008.cn переходит на новый уровень сети" (пресс-релиз). Пекинский оргкомитет Игр XXIX Олимпиады. 30 мая 2008 г. Архивировано из оригинала 4 февраля 2009 г.
  77. ^ Das, Kaushik (2008). "IPv6 и Олимпиада 2008 года в Пекине". IPv6.com . Архивировано из оригинала 1 августа 2008 года . Получено 15 августа 2008 года .
  78. ^ ab Morr, Derek (9 июня 2009 г.). «Verizon обязывает поддерживать IPv6 для сотовых телефонов следующего поколения». CircleID.
  79. ^ abc "State of IPv6 Deployment 2018" (PDF) . InternetSociety.org . Internet Society . Получено 19 января 2022 г. .
  80. ^ "Дело Hurricane Electric And Cogent". BGP.tools . BGP.tools . Получено 10 сентября 2024 г. .

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

Wikidata имеет свойство:
  • Префикс маршрутизации IPv6 (P3793) (см. использование )
Викиверситет содержит обучающие ресурсы по IPv6
Найдите IPv6 в Викисловаре, бесплатном словаре.