IPv6
Части этой статьи (относящиеся к RFC 8200 и RFC 8201) необходимо обновить . ( июль 2017 г. ) |
Протокол связи | |
Аббревиатура | IPv6 |
---|---|
Цель | Межсетевой протокол |
Разработчик(и) | Целевая группа по интернет-инжинирингу |
Введение | декабрь 1995 г |
На основе | IPv4 |
Уровень OSI | Сетевой уровень |
RFC(ы) | 2460 , 8200 |
Набор интернет-протоколов |
---|
Прикладной уровень |
Транспортный уровень |
Интернет-слой |
Слой связи |
Интернет-протокол версии 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 — это протокол интернет-уровня для с коммутацией пакетов межсетевых сетей , который обеспечивает сквозную передачу дейтаграмм по нескольким IP-сетям, строго придерживаясь принципов проектирования, разработанных в предыдущей версии протокола — Интернет-протокола версии 4 (IPv4).
Помимо предоставления большего количества адресов, IPv6 также реализует функции, отсутствующие в IPv4. Он упрощает аспекты настройки адресов, перенумерации сетей и объявлений маршрутизаторов при смене поставщиков сетевых подключений. Это упрощает обработку пакетов на маршрутизаторах, возлагая ответственность за фрагментацию пакетов на конечные точки. IPv6 Размер подсети стандартизируется путем фиксации размера части адреса, представляющей идентификатор хоста, равным 64 битам.
Архитектура адресации IPv6 определена в RFC 4291 и допускает три различных типа передачи: одноадресную , произвольную и многоадресную . [5] : 210
Мотивация и происхождение
[ редактировать ]Исчерпание 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 по-прежнему имеет доступные пулы адресов и, как ожидается, продолжит использовать стандартные политики распределения адресов до тех пор, пока не останется один блок /8 бесклассовой междоменной маршрутизации (CIDR). (LIR) будут передаваться только блоки по 1024 адреса (/22) После этого из RIR в локальный интернет-реестр . По состоянию на сентябрь 2015 года все Азиатско-Тихоокеанский сетевой информационный центр (APNIC), Координационный центр сети Réseaux IP Européens (RIPE NCC), Сетевой информационный центр Латинской Америки и Карибского бассейна (LACNIC) и Американский реестр интернет-номеров (ARIN) имеют достиг этой стадии. [9] [10] [11] В результате Африканский сетевой информационный центр (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. В 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 включает то, что обычно называют «адресами конфиденциальности» или, точнее, «временными адресами», кодифицированными в RFC 4941, «Расширения конфиденциальности для автоматической настройки адресов без сохранения состояния в IPv6». [22] Временные адреса случайны и нестабильны. Типичное потребительское устройство ежедневно генерирует новый временный адрес и через неделю игнорирует трафик, адресованный старому адресу. Временные адреса используются Windows по умолчанию, начиная с XP SP1. [23] macOS начиная с (Mac OS X) 10.7, Android начиная с 4.0 и iOS начиная с версии 4.3. Использование временных адресов в дистрибутивах Linux различается. [24]
Перенумерация существующей сети для нового поставщика услуг связи с другими префиксами маршрутизации является серьезной задачей при использовании IPv4. [25] [26] Однако в случае IPv6 изменение префикса, объявленного несколькими маршрутизаторами, в принципе может перенумеровать всю сеть, поскольку идентификаторы хоста (наименее значимые 64 бита адреса) могут быть самостоятельно настроены хостом самостоятельно. [19]
Метод генерации адреса SLAAC зависит от реализации. IETF рекомендует, чтобы адреса были детерминированными, но семантически непрозрачными. [27]
IPsec
[ редактировать ]Безопасность интернет-протокола (IPsec) изначально была разработана для IPv6, но получила широкое распространение сначала в IPv4, для чего была переработана. IPsec был обязательной частью всех реализаций протокола IPv6. [2] и обмен ключами через Интернет (IKE), но в RFC 6434 включение IPsec в реализации IPv6 было понижено до рекомендации, поскольку считалось непрактичным требовать полной реализации IPsec для всех типов устройств, которые могут использовать IPv6. Однако, начиная с RFC 4301, реализации протокола IPv6, которые реализуют IPsec, должны реализовывать IKEv2 и поддерживать минимальный набор криптографических алгоритмов . Это требование поможет сделать реализации IPsec более совместимыми между устройствами разных производителей. Заголовок аутентификации IPsec (AH) и заголовок инкапсулирующей безопасности (ESP) реализованы как заголовки расширения IPv6. [28]
Упрощенная обработка маршрутизаторами
[ редактировать ]Заголовок пакета в IPv6 проще, чем заголовок IPv4. Многие редко используемые поля были перенесены в дополнительные расширения заголовков. Заголовок пакета IPv6 упростил процесс пересылки пакетов маршрутизаторами . Хотя заголовки пакетов IPv6 как минимум в два раза превышают размер заголовков пакетов IPv4, обработка маршрутизаторами пакетов, которые содержат только базовый заголовок IPv6, в некоторых случаях может быть более эффективной, поскольку на маршрутизаторах требуется меньше обработки из-за выравнивания заголовков. для соответствия обычным размерам слов . [2] [14] Однако многие устройства реализуют поддержку IPv6 программно (а не аппаратно), что приводит к очень низкой производительности обработки пакетов. [29] Кроме того, во многих реализациях использование заголовков расширений приводит к тому, что пакеты обрабатываются процессором маршрутизатора, что приводит к снижению производительности или даже проблемам безопасности. [30]
Более того, заголовок IPv6 не содержит контрольной суммы. Контрольная сумма заголовка IPv4 рассчитывается для заголовка IPv4 и должна пересчитываться маршрутизаторами каждый раз, когда время жизни (называемое лимитом переходов в протоколе IPv6) уменьшается на единицу. Отсутствие контрольной суммы в заголовке IPv6 способствует реализации сквозного принципа проектирования Интернета, который предполагает, что большая часть обработки в сети происходит на конечных узлах. Предполагается, что защита целостности данных, инкапсулированных в пакет IPv6, обеспечивается как канальным уровнем , так и обнаружением ошибок в протоколах более высокого уровня, а именно протоколе управления передачей (TCP) и протоколе пользовательских дейтаграмм (UDP) на транспортном уровне. слой . Таким образом, в то время как IPv4 позволяет заголовкам датаграмм UDP не иметь контрольной суммы (обозначается 0 в поле заголовка), IPv6 требует наличия контрольной суммы в заголовках UDP.
Маршрутизаторы IPv6 не выполняют фрагментацию IP . Хосты IPv6 должны выполнить одно из следующих действий: выполнить обнаружение Path MTU , выполнить сквозную фрагментацию или отправить пакеты размером не больше, чем максимальная единица передачи (MTU) по умолчанию, которая составляет 1280 октетов .
Мобильность
[ редактировать ]В отличие от мобильного IPv4, мобильный IPv6 избегает треугольной маршрутизации и поэтому столь же эффективен, как и собственный IPv6. Маршрутизаторы IPv6 также могут разрешать целым подсетям перемещаться на новую точку подключения маршрутизатора без изменения нумерации. [31]
Заголовки расширений
[ редактировать ]Заголовок пакета IPv6 имеет минимальный размер 40 октетов (320 бит). Опции реализованы как расширения. Это дает возможность расширить протокол в будущем, не затрагивая структуру ядра пакета. [2] Однако в RFC 7872 отмечается, что некоторые сетевые операторы отбрасывают пакеты IPv6 с заголовками расширения при прохождении через транзитные автономные системы .
Джамбограммы
[ редактировать ]IPv4 ограничивает количество пакетов до 65 535 (2 16 −1) октеты полезной нагрузки. Узел IPv6 может дополнительно обрабатывать пакеты, превышающие этот предел, называемые джамбограммами , размер которых может достигать 4 294 967 295 (2 32 −1) октеты. Использование джамбограмм может повысить производительность каналов с большим MTU . На использование Jumbograms указывает заголовок расширения Jumbo Payload Option. [32]
IPv6-пакеты
[ редактировать ]Пакет IPv6 состоит из двух частей: заголовка и полезной нагрузки .
Заголовок состоит из фиксированной части с минимальной функциональностью, необходимой для всех пакетов, и за ним могут следовать дополнительные расширения для реализации специальных функций.
Фиксированный заголовок занимает первые 40 октетов (320 бит) пакета IPv6. Он содержит адреса источника и назначения, класс трафика, количество переходов и тип дополнительного расширения или полезной нагрузки, которая следует за заголовком. Это поле следующего заголовка сообщает получателю, как интерпретировать данные, следующие за заголовком. Если пакет содержит опции, это поле содержит тип следующей опции. пакета Поле «Следующий заголовок» последней опции указывает на протокол верхнего уровня, который содержится в полезной нагрузке .
Текущее использование поля класса трафика IPv6 делит его на 6-битную кодовую точку дифференцированных услуг. [33] и 2-битное поле явного уведомления о перегрузке. [34]
Заголовки расширений содержат параметры, которые используются для специальной обработки пакета в сети, например, для маршрутизации, фрагментации и обеспечения безопасности с использованием инфраструктуры IPsec .
Без специальных опций полезная нагрузка должна быть меньше 64 КБ . При использовании опции Jumbo Payload (в заголовке расширения Hop-By-Hop Options ) полезная нагрузка должна быть меньше 4 ГБ.
В отличие от IPv4, маршрутизаторы никогда не фрагментируют пакет. Ожидается, что хосты будут использовать Path MTU Discovery , чтобы сделать свои пакеты достаточно маленькими, чтобы они могли достичь пункта назначения без необходимости фрагментации. См. раздел «Фрагментация пакетов IPv6» .
Адресация
[ редактировать ]Адреса IPv6 имеют длину 128 бит. В дизайне адресного пространства IPv6 реализована другая философия проектирования, чем в IPv4, в котором разделение на подсети использовалось для повышения эффективности использования небольшого адресного пространства. В IPv6 адресное пространство считается достаточно большим в обозримом будущем, и локальная подсеть всегда использует 64 бита для хостовой части адреса, обозначаемой как идентификатор интерфейса, в то время как наиболее значимые 64 бита используются для маршрутизации. префикс. [35] Хотя существует миф о невозможности сканирования подсетей IPv6, в RFC 7707 отмечается, что шаблоны, возникающие в результате некоторых методов и алгоритмов настройки адресов IPv6, позволяют сканировать адреса во многих реальных сценариях.
Представление адреса
[ редактировать ]128 бит адреса IPv6 представлены 8 группами по 16 бит каждая. Каждая группа записывается четырьмя шестнадцатеричными цифрами (иногда называемыми гекстетами). [36] [37] или, более формально, гексадектеты [38] и неофициально придирка или четверной клев [38] ) и группы разделяются двоеточиями (:). Примером такого представления является 2001:0db8:0000:0000:0000:ff00:0042:8329 .
Для удобства и ясности представление IPv6-адреса можно сократить с помощью следующих правил:
- Один или несколько ведущих нулей из любой группы шестнадцатеричных цифр удаляются, что обычно делается со всеми ведущими нулями. Например, группа 0042 преобразуется в 42 . Группа 0000 преобразуется в 0 .
- Последовательные части нулей заменяются двумя двоеточиями (::). Его можно использовать только один раз в адресе, так как многократное использование сделает адрес неопределенным. RFC 5952 требует, чтобы двойное двоеточие не использовалось для обозначения пропущенной одиночной части нулей. [39]
Пример применения этих правил:
- Начальный адрес: 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 определен в RFC 5156 и сокращается до ::1 при использовании обоих правил.
Поскольку адрес IPv6 может иметь более одного представления, IETF выпустил предлагаемый стандарт для их представления в тексте . [40]
Поскольку адреса IPv6 содержат двоеточия, а URL-адреса используют двоеточия для отделения хоста от номера порта, RFC2732 [41] указывает, что адрес IPv6, используемый как хост-часть URL-адреса, должен быть заключен в квадратные скобки, например http://[2001:db8:4006:812::200e] или http://[2001:db8:4006: 812::200e]:8080/path/page.html.
Ссылка-локальный адрес
[ редактировать ]Все интерфейсы хостов IPv6 требуют локального адреса канала , который имеет префикс fe80:: / 10 . За этим префиксом следуют 54 бита, которые можно использовать для создания подсетей (хотя обычно они равны нулю), а также 64-битный идентификатор интерфейса. Хост может вычислить и назначить идентификатор интерфейса самостоятельно без присутствия или сотрудничества внешнего сетевого компонента, такого как DHCP-сервер, в процессе, называемом автоконфигурацией локального адреса канала . [ нужна ссылка ]
Младшие 64 бита локального адреса канала (суффикс) изначально были получены из MAC-адреса базовой сетевой интерфейсной карты. Поскольку этот метод назначения адресов может привести к нежелательным изменениям адреса при замене неисправных сетевых карт, а также связан с рядом проблем безопасности и конфиденциальности, RFC 8064 заменил исходный метод на основе MAC на метод на основе хэша, указанный в РФК 7217 . [ нужна ссылка ]
Уникальность адреса и запрос маршрутизатора
[ редактировать ]IPv6 использует новый механизм сопоставления IP-адресов с адресами канального уровня (например, MAC-адресами ), поскольку он не поддерживает метод широковещательной функциональность протокола разрешения адресов адресации, на котором основана (ARP) в IPv4. IPv6 реализует протокол обнаружения соседей (NDP, ND) на канальном уровне , который опирается на ICMPv6 и многоадресную передачу. [5] : 210 Хосты IPv6 проверяют уникальность своих адресов IPv6 в локальной сети (LAN), отправляя сообщение запроса соседа с запросом адреса канального уровня IP-адреса. Если какой-либо другой хост в локальной сети использует этот адрес, он отвечает. [42]
Хост, подключающий новый интерфейс IPv6, сначала генерирует уникальный локальный адрес канала, используя один из нескольких механизмов, предназначенных для генерации уникального адреса. Если обнаружен неуникальный адрес, хост может повторить попытку с новым сгенерированным адресом. После того как уникальный локальный адрес канала установлен, хост IPv6 определяет, подключена ли локальная сеть по этому каналу к какому-либо маршрутизатора интерфейсу , поддерживающему IPv6. Это делается путем отправки сообщения запроса маршрутизатора ICMPv6 всем маршрутизаторам. [43] многоадресная группа с ее локальным адресом в качестве источника. Если после заданного количества попыток ответа нет, хост приходит к выводу, что маршрутизаторы не подключены. Если он получает ответ, известный как объявление маршрутизатора, от маршрутизатора, ответ включает информацию о конфигурации сети, позволяющую установить глобально уникальный адрес с соответствующим префиксом одноадресной сети. [44] Есть также два бита флага, которые сообщают хосту, следует ли ему использовать DHCP для получения дополнительной информации и адресов:
- Бит управления, который указывает, должен ли хост использовать DHCP для получения дополнительных адресов, а не полагаться на автоматически настроенный адрес из объявления маршрутизатора.
- Бит Other, который указывает, должен ли хост получать другую информацию через DHCP. Другая информация состоит из одного или нескольких параметров префикса для подсетей, к которым подключен хост, срока действия префикса и двух флагов: [42]
- On-link: если этот флаг установлен, хост будет рассматривать все адреса в определенной подсети как находящиеся в режиме on-link и отправлять пакеты непосредственно на них, а не отправлять их на маршрутизатор в течение заданного срока службы.
- Адрес: этот флаг сообщает хосту, что он должен создать глобальный адрес.
Глобальная адресация
[ редактировать ]Процедура назначения глобальных адресов аналогична построению локальных адресов. Префикс предоставляется из рекламы роутера в сети. Объявления с несколькими префиксами приводят к настройке нескольких адресов. [42]
Для автоматической настройки адреса без сохранения состояния (SLAAC) требуется блок из 64 адресов, как определено в РФК 4291 . Локальным интернет-реестрам выделяется не менее 32 блоков, которые они делят между подчиненными сетями. [45] В первоначальной рекомендации говорилось о назначении 48-й подсети сайтам конечных потребителей ( RFC 3177 ). Это было заменено на RFC 6177 , который «рекомендует давать домашним сайтам значительно больше, чем один 64 », но также не рекомендует присваивать каждому домашнему сайту 48 ». 56 с конкретно рассматриваются. Еще неизвестно, выполнят ли интернет-провайдеры эту рекомендацию. Например, во время первоначальных испытаний клиентам Comcast была предоставлена одна сеть 64 . [46]
IPv6 в системе доменных имен
[ редактировать ]В системе доменных имен (DNS) имена хостов сопоставляются с адресами IPv6 с помощью записей ресурсов AAAA («quad-A»). Для обратного разрешения IETF зарезервировал домен ip6.arpa , где пространство имен иерархически разделено однозначным шестнадцатеричным представлением полубайтовых единиц (4 бита) адреса IPv6. Эта схема определена в РФК 3596 .
Когда узел с двойным стеком запрашивает DNS-сервер для разрешения полного доменного имени (FQDN), DNS-клиент узла отправляет два DNS-запроса: один запрашивает записи A, а другой запрашивает записи AAAA. Операционная система хоста может быть настроена с предпочтением правил выбора адреса. РФК 6724 . [47]
Альтернативный тип записи использовался в ранних реализациях DNS для IPv6, предназначенных для облегчения перенумерации сетей, записей A6 для прямого поиска и ряда других нововведений, таких как метки битовых строк и записи DNAME . Это определено в RFC 2874 и ссылки на него (с дальнейшим обсуждением плюсов и минусов обеих схем в RFC 3364 ), но объявлен устаревшим до экспериментального статуса ( RFC 3363 ).
Механизмы перехода
[ редактировать ]Не предполагается, что IPv6 мгновенно вытеснит IPv4. Оба протокола будут продолжать работать одновременно в течение некоторого времени. Таким образом, механизмы перехода IPv6 , чтобы позволить хостам IPv6 получать доступ к службам IPv4 и позволить изолированным хостам и сетям IPv6 связываться друг с другом через инфраструктуру IPv4. необходимы [48]
По словам Сильвии Хаген , реализация двойного стека IPv4 и IPv6 на устройствах — это самый простой способ перехода на IPv6. [49] Многие другие механизмы перехода используют туннелирование для инкапсуляции трафика IPv6 в сетях IPv4 и наоборот. Это несовершенное решение, которое уменьшает максимальную единицу передачи (MTU) канала и, следовательно, усложняет Path MTU Discovery и может увеличить задержку . [50] [51]
Реализация двухстекового IP
[ редактировать ]Реализации IP с двойным стеком обеспечивают полные стеки протоколов IPv4 и IPv6 в операционной системе компьютера или сетевого устройства поверх общей реализации физического уровня , такой как Ethernet . Это позволяет хостам с двойным стеком одновременно участвовать в сетях IPv6 и IPv4. Метод определен в РФК 4213 . [52]
Устройство с двухстековой реализацией в операционной системе имеет адрес 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. [53]
Хотя двойной стек поддерживается основными поставщиками операционных систем и сетевых устройств, устаревшее сетевое оборудование и серверы не поддерживают IPv6.
Клиенты интернет-провайдеров с общедоступным IPv6
[ редактировать ]Интернет-провайдеры (ISP) все чаще предоставляют своим корпоративным и частным клиентам общедоступные глобальные одноадресные адреса IPv6. Однако если IPv4 все еще используется в локальной сети (LAN) и интернет-провайдер может предоставить только один общедоступный адрес IPv6, адреса локальной сети IPv4 преобразуются в общедоступный адрес IPv6 с использованием NAT64 , преобразования сетевых адресов (NAT). ) механизм. Некоторые интернет-провайдеры не могут предоставить своим клиентам общедоступные адреса IPv4 и IPv6, тем самым поддерживая двухстековую сеть, поскольку некоторые интернет-провайдеры исчерпали свой глобально маршрутизируемый пул адресов IPv4. Тем временем клиенты интернет-провайдеров все еще пытаются подключиться к веб-серверам IPv4 и другим направлениям. [54]
Значительный процент интернет-провайдеров во всех зонах регионального реестра Интернета (RIR) получил адресное пространство IPv6. Сюда входят многие крупные мировые интернет-провайдеры и операторы мобильных сетей , такие как Verizon Wireless , StarHub Cable , Chubu Telecommunication , Kabel Deutschland , Swisscom , T-Mobile , Internode и Telefónica . [55]
Хотя некоторые интернет-провайдеры по-прежнему выделяют клиентам только адреса IPv4, многие интернет-провайдеры выделяют своим клиентам только IPv6 или двойной стек IPv4 и IPv6. Интернет-провайдеры сообщают, что доля трафика IPv6 от клиентов в их сети составляет от 20% до 40%, но к середине 2017 года трафик IPv6 все еще составлял лишь часть общего трафика в нескольких крупных точках обмена Интернетом (IXP). AMS-IX сообщил, что этот показатель составляет 2%, а SeattleIX сообщил о 7%. Опрос 2017 года показал, что многие клиенты DSL, обслуживаемые интернет-провайдером с двойным стеком, не запрашивали DNS-серверы для преобразования полных доменных имен в адреса IPv6. Опрос также показал, что большая часть трафика с ресурсов веб-сервера, поддерживающего IPv6, по-прежнему запрашивалась и обслуживалась через IPv4, в основном из-за клиентов интернет-провайдеров, которые не использовали функцию двойного стека, предоставляемую их интернет-провайдером, и в меньшей степени из-за клиентов. интернет-провайдеров, поддерживающих только IPv4. [56]
Туннелирование
[ редактировать ]Техническая основа туннелирования или инкапсуляции пакетов IPv6 в пакеты IPv4 изложена в RFC 4213. Когда магистраль Интернета была только IPv4, одним из часто используемых протоколов туннелирования был 6to4 . [57] Туннелирование Teredo также часто использовалось для интеграции локальных сетей IPv6 с магистральной сетью Интернета IPv4. Teredo описан в RFC 4380 и позволяет локальным сетям IPv6 туннелировать через сети IPv4 путем инкапсуляции пакетов IPv6 в UDP. Ретранслятор Teredo — это маршрутизатор IPv6, который является посредником между сервером Teredo и собственной сетью IPv6. Ожидалось, что 6to4 и Teredo будут широко распространены до тех пор, пока сети интернет-провайдеров не перейдут на собственный IPv6, но к 2014 году статистика Google показала, что использование обоих механизмов упало почти до 0. [58]
IPv6-адреса, сопоставленные с IPv4
[ редактировать ]Гибридные реализации IPv6/IPv4 с двойным стеком распознают особый класс адресов — адреса IPv6, сопоставленные с IPv4. [59] [60] Эти адреса обычно записываются с 96-битным префиксом в стандартном формате IPv6, а остальные 32 бита записываются в обычной десятичной записи IPv4.
Адреса в этой группе состоят из 80-битного префикса нулей, следующие 16 бит — единицы, а оставшиеся, наименее значимые 32 бита содержат адрес IPv4. Например, ::ffff:192.0.2.128 представляет IPv4-адрес 192.0.2.128 . Предыдущий формат, называемый «IPv4-совместимым адресом IPv6», был ::192.0.2.128 ; однако этот метод устарел. [60]
Из-за значительных внутренних различий между стеками протоколов IPv4 и IPv6 некоторые функции нижнего уровня, доступные программистам в стеке IPv6, не работают одинаково при использовании с адресами, сопоставленными с IPv4. Некоторые распространенные стеки IPv6 не реализуют функцию сопоставления адресов IPv4 либо потому, что стеки IPv6 и IPv4 являются отдельными реализациями (например, Microsoft Windows 2000, XP и Server 2003), либо из соображений безопасности ( OpenBSD ). [61] В этих операционных системах программа должна открывать отдельный сокет для каждого используемого ею IP-протокола. В некоторых системах, например, в ядре Linux , NetBSD и FreeBSD , эта функция контролируется опцией сокета IPV6_V6ONLY. [62] : 22
Префикс адреса 64:ff9b::/96 представляет собой класс встроенных в IPv4 адресов IPv6 для использования в методах перехода NAT64 . [63] Например, 64:ff9b::192.0.2.128 представляет IPv4-адрес 192.0.2.128 .
Безопасность
[ редактировать ]Использование IPv6 может привести к ряду последствий для безопасности. Некоторые из них могут быть связаны с самими протоколами IPv6, а другие — с недостатками реализации. [64] [65]
Теневые сети
[ редактировать ]Добавление узлов, у которых IPv6 включен по умолчанию производителем программного обеспечения, может привести к непреднамеренному созданию теневых сетей , в результате чего трафик IPv6 будет поступать в сети, в которых реализовано только управление безопасностью IPv4. Это также может произойти при обновлении операционной системы, когда новая операционная система по умолчанию включает IPv6, а старая — нет. Если не обновить инфраструктуру безопасности для поддержки IPv6, трафик IPv6 может обходить ее. [66] Теневые сети возникли в бизнес-сетях, в которых предприятия заменяют системы Windows XP , в которых по умолчанию не включен стек IPv6, на Windows 7 , в которых он есть. системы [67] Поэтому некоторые разработчики стека IPv6 рекомендуют отключить отображаемые адреса IPv4 и вместо этого использовать сеть с двойным стеком, где необходима поддержка как IPv4, так и IPv6. [68]
Фрагментация пакетов IPv6
[ редактировать ]Исследования показали, что использование фрагментации можно использовать для обхода контроля сетевой безопасности, аналогично IPv4. Как результат, RFC 7112 требует, чтобы первый фрагмент пакета IPv6 содержал всю цепочку заголовков IPv6, поэтому некоторые очень патологические случаи фрагментации запрещены. Кроме того, в результате исследования уклонений от RA-Guard в RFC 7113 , В RFC 6980 запрещено использование фрагментации с помощью Neighbor Discovery и не рекомендуется использовать фрагментацию с Secure Neighbor Discovery (SEND).
Стандартизация посредством RFC
[ редактировать ]Предложения рабочей группы
[ редактировать ]В связи с ожидаемым глобальным ростом Интернета в ( начале 1990-х годов Инженерная группа Интернета IETF) начала разработку протокола IP следующего поколения. [5] : 209 К началу 1992 года появилось несколько предложений по расширенной системе адресации Интернета, а к концу 1992 года IETF объявила о призыве к выпуску официальных документов. [69] В сентябре 1993 года IETF создал временную специальную зону IP Next Generation (IPng) для решения таких проблем. Новым отделом руководили Эллисон Мэнкин и Скотт Брэднер , и в нем было управление из 15 инженеров разного происхождения для определения направлений и предварительного рассмотрения документов: [7] [70] Членами рабочей группы были Дж. Аллард (Microsoft), Стив Белловин (AT&T), Джим Баунд (Digital Equipment Corporation), Росс Каллон (Wellfleet), Брайан Карпентер (CERN), Дэйв Кларк (MIT), Джон Карран (NEARNET). , Стив Диринг (Xerox), Дино Фариначчи (Cisco), Пол Фрэнсис (NTT), Эрик Флейшманн (Boeing), Марк Кноппер (Ameritech), Грег Миншалл (Novell), Роб Ульманн (Lotus) и Ликсия Чжан (Xerox). [71]
Рабочая группа по разработке Интернета приняла модель IPng 25 июля 1994 года, сформировав несколько рабочих групп по IPng. [7] К 1996 году была выпущена серия RFC, определяющая версию 6 Интернет-протокола (IPv6), начиная с РФК 1883 . (Версия 5 использовалась экспериментальным протоколом Internet Stream Protocol .)
Стандартизация RFC
[ редактировать ]Первым RFC, стандартизировавшим IPv6, был RFC 1883 в 1995 г., [72] который устарел из-за RFC 2460 в 1998 году. [5] : 209 В июле 2017 года этот RFC был заменен на RFC 8200 , который повысил уровень IPv6 до «Интернет-стандарта» (самый высокий уровень зрелости для протоколов IETF). [3]
Развертывание
[ редактировать ]Внедрение в 1993 году бесклассовой междоменной маршрутизации (CIDR) для маршрутизации и распределения IP-адресов в Интернете, а также широкое использование трансляции сетевых адресов (NAT) отложили исчерпание адресов IPv4 , чтобы обеспечить возможность развертывания IPv6, которое началось в середине -2000-е.
Университеты были одними из первых, кто внедрил IPv6. Технологический институт штата Вирджиния развернул IPv6 в пробном месте в 2004 году, а затем расширил развертывание IPv6 по всей сети кампуса . К 2016 году 82% трафика в их сети использовало IPv6. Имперский колледж Лондона начал экспериментальное развертывание IPv6 в 2003 году, и к 2016 году трафик IPv6 в их сетях составлял в среднем от 20% до 40%. Значительная часть этого IPv6-трафика была создана благодаря сотрудничеству в области физики высоких энергий с CERN , которое полностью полагается на IPv6. [73]
Система доменных имен (DNS) поддерживает IPv6 с 2008 года. В том же году IPv6 был впервые использован на крупном мировом мероприятии во время летних Олимпийских игр 2008 года в Пекине . [74] [75]
К 2011 году все основные операционные системы, используемые на персональных компьютерах и серверных системах, имели реализацию IPv6 промышленного качества. Сотовые телефонные системы представляют собой обширное поле для развертывания устройств, использующих Интернет-протокол, поскольку услуги мобильной телефонной связи осуществили переход от технологий 3G к технологиям 4G , в которых голос предоставляется как услуга передачи голоса по IP (VoIP), которая будет использовать усовершенствования IPv6. В 2009 году американский оператор сотовой связи Verizon опубликовал технические характеристики устройств для работы в его сетях «следующего поколения». [76] Спецификация предписывала работу IPv6 в соответствии со спецификациями 3GPP Release 8 (март 2009 г.) и объявляла IPv4 устаревшим как необязательную возможность. [76]
Продолжалось внедрение IPv6 в магистральной сети Интернет . В 2018 году только 25,3% из примерно 54 000 автономных систем рекламировали префиксы IPv4 и IPv6 в глобальной базе данных маршрутизации протокола пограничного шлюза (BGP). Еще 243 сети рекламировали только префикс IPv6. Магистральные транзитные сети Интернета, поддерживающие IPv6, существовали во всех странах мира, за исключением некоторых частей Африки , Ближнего Востока и Китая. [77] : 6 К середине 2018 года некоторые крупные европейские интернет-провайдеры широкополосного доступа внедрили IPv6 для большинства своих клиентов. Sky UK обеспечила более 86% своих клиентов IPv6, Deutsche Telekom обеспечила 56% внедрения IPv6, XS4ALL в Нидерландах имела 73% внедрения, а в Бельгии интернет-провайдеры широкополосного доступа VOO и Telenet имели 73% и 63% внедрения IPv6 соответственно. [77] : 7 В США у широкополосного интернет-провайдера Xfinity уровень внедрения IPv6 составил около 66%. В 2018 году Xfinity сообщила о 36,1 миллионах пользователей IPv6, а AT&T сообщила о 22,3 миллионах пользователей IPv6. [77] : 7–8
См. также
[ редактировать ]- Интернет нового поколения в Китае
- Сравнение поддержки IPv6 в операционных системах
- Сравнение поддержки IPv6 в распространенных приложениях
- Сертификация продукта DoD IPv6
- ОККАИД
- Лаборатория совместимости Университета Нью-Гэмпшира
Ссылки
[ редактировать ]- ^ «Часто задаваемые вопросы» . Целевая группа Новой Зеландии по IPv6. Архивировано из оригинала 29 января 2019 года . Проверено 26 октября 2015 г.
- ^ Jump up to: а б с д и ж С. Диринг ; Р. Хинден (декабрь 1998 г.), Спецификация Интернет-протокола версии 6 (IPv6) , Рабочая группа по разработке Интернета (IETF), RFC 2460 устарел RFC 1883.
- ^ Jump up to: а б С. Диринг ; Р. Хинден (июль 2017 г.), «Спецификация Интернет-протокола версии 6 (IPv6)», Страницы запроса комментариев IETF (RFC) — тестирование , Инженерная группа Интернета (IETF), ISSN 2070-1721 , RFC 8200 Устаревший RFC 2460.
- ^ Сиддики, Афтаб (17 июля 2017 г.). «RFC 8200 – IPv6 стандартизирован» . Интернет-сообщество . Архивировано из оригинала 23 октября 2023 года . Проверено 25 февраля 2018 г.
- ^ Jump up to: а б с д Розен, Рами (2014). Сеть ядра Linux: реализация и теория . Нью-Йорк: Апресс. ISBN 9781430261971 . OCLC 869747983 .
- ^ Конференция Google IPv6 2008: Как будет выглядеть Интернет IPv6? . Событие происходит в 13:35. Архивировано из оригинала 11 декабря 2021 года.
- ^ Jump up to: а б с Брэднер, С.; Манкин, А. (январь 1995 г.). Рекомендации по протоколу IP следующего поколения . IETF . дои : 10.17487/RFC1752 . РФК 1752 .
- ^ «Свободный пул адресного пространства IPv4 исчерпан» . НРО.нет . Монтевидео : Организация номерных ресурсов. 3 февраля 2011 г. Архивировано из оригинала 18 января 2024 г. Проверено 19 января 2022 г.
- ^ Рашид, Фахмида (1 февраля 2011 г.). «Исчерпание IPv4-адресов не является мгновенной причиной для беспокойства по поводу IPv6 в Wings» . электронная неделя. Архивировано из оригинала 20 января 2024 года . Проверено 23 июня 2012 г.
- ^ Уорд, Марк (14 сентября 2012 г.). «Европа достигла старых ограничений на интернет-адреса» . Новости Би-би-си . Архивировано из оригинала 5 ноября 2023 года . Проверено 15 сентября 2012 г.
- ^ Хьюстон, Джефф. «Отчет об адресе IPV4» . Архивировано из оригинала 10 января 2024 года.
- ^ "ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ" . my.afrinic.net . АФРИНИК . Архивировано из оригинала 23 октября 2023 года . Проверено 28 ноября 2018 г.
- ^ «У RIPE NCC закончились адреса IPv4» (пресс-релиз). РАЙП НКЦ . 25 ноября 2019 года. Архивировано из оригинала 19 января 2024 года . Проверено 26 ноября 2019 г. .
- ^ Jump up to: а б Партридж, К.; Кастенхольц, Ф. (декабрь 1994 г.). «Технические критерии выбора IP следующего поколения (IPng)» . РФК 1726 .
- ^ RFC 1112 , Расширения хоста для многоадресной IP-рассылки , С. Диринг (август 1989 г.)
- ^ RFC 3956 , Встраивание адреса точки встречи (RP) в адрес многоадресной рассылки IPv6 , П. Савола, Б. Хаберман (ноябрь 2004 г.)
- ^ RFC 2908 , Архитектура распределения адресов многоадресной рассылки в Интернете , Д. Талер, М. Хэндли, Д. Эстрин (сентябрь 2000 г.)
- ^ RFC 3306 , Многоадресные адреса IPv6 на основе одноадресных префиксов , Б. Хаберман, Д. Талер (август 2002 г.)
- ^ Jump up to: а б Томсон, С.; Нартен, Т.; Джинмей, Т. (сентябрь 2007 г.). «Автоконфигурация адреса без сохранения состояния IPv6» . IETF . дои : 10.17487/RFC4862 . РФК 4862 . Архивировано из оригинала 11 января 2024 года.
- ^ RFC 2894 , Перенумерация маршрутизаторов для IPv6 , М. Кроуфорд, август 2000 г.
- ^ Т. Нартен; Р. Дрейвс; С. Кришнан (сентябрь 2007 г.). «Расширения конфиденциальности для автоматической настройки адресов без сохранения состояния в IPv6» . www.ietf.org . Проверено 13 марта 2017 г.
- ^ Нартен, Томас; Дравс, Ричард; Кришнан, Суреш. Расширения конфиденциальности для автоматической настройки адресов без сохранения состояния в IPv6 . дои : 10.17487/RFC4941 . РФК 4941 .
- ^ «Обзор расширенного сетевого пакета для Windows XP» . Майкрософт . Архивировано из оригинала 7 сентября 2017 года . Проверено 15 апреля 2019 г.
- ^ «Расширения конфиденциальности для IPv6 SLAAC» . Интернет-сообщество . 8 августа 2014 г. Архивировано из оригинала 23 октября 2023 г. . Проверено 17 января 2020 г.
- ^ Фергюсон, П.; Берковиц, Х. (январь 1997 г.). «Обзор перенумерации сети: зачем мне это нужно и что это вообще такое?» . IETF . дои : 10.17487/RFC2071 . РФК 2071 . Архивировано из оригинала 7 января 2024 года.
- ^ Берковиц, Х. (январь 1997 г.). «Руководство по перенумерации маршрутизатора» . IETF . дои : 10.17487/RFC2072 . РФК 2072 . Архивировано из оригинала 8 июня 2023 года.
- ^ Купер, Алисса; Гонт, Фернандо; Талер, Дэйв. Рекомендации по стабильным идентификаторам интерфейса IPv6 . дои : 10.17487/RFC8064 . RFC 8064 .
- ^ Сильвия Хаген (2014). Основы IPv6: интеграция IPv6 в вашу сеть IPv4 (3-е изд.). Севастополь, Калифорния: O'Reilly Media. п. 196. ИСБН 978-1-4493-3526-7 . OCLC 881832733 .
- ^ Зак, Э. (июль 2013 г.). «Оценка и сравнительный анализ безопасности IPv6» .
- ^ Гонт, Ф. (март 2016 г.). «Эксплуатационные последствия пакетов IPv6 с заголовками расширений» . IETF . Архивировано из оригинала 27 октября 2023 года.
- ^ RFC 3963 , Поддержка базового протокола Network Mobility (NEMO) , В. Деварапалли, Р. Вакикава, А. Петреску, П. Туберт (январь 2005 г.)
- ^ RFC 2675 , Джамбограммы IPv6 , Д. Борман, С. Диринг , Р. Хинден (август 1999 г.)
- ^ RFC 2474
- ^ RFC 3168
- ^ RFC 4291 , стр. 9.
- ^ Грациани, Рик (2012). Основы IPv6: простой подход к пониманию IPv6 . Сиско Пресс . п. 55. ИСБН 978-0-13-303347-2 .
- ^ Коффен, Том (2014). Планирование адресов IPv6: разработка плана адресации будущего . О'Рейли Медиа . п. 170. ИСБН 978-1-4919-0326-1 .
- ^ Jump up to: а б Хорли, Эдвард (2013). Практический IPv6 для администраторов Windows . Апресс . п. 17. ISBN 978-1-4302-6371-5 .
- ^ Кавамура, С. (август 2010 г.). «Рекомендации по текстовому представлению адресов IPv6 — раздел 4.22» . IETF . дои : 10.17487/RFC5952 . РФК 5952 . Архивировано из оригинала 12 января 2024 года.
- ^ Кавамура, С. (август 2010 г.). «Рекомендации по текстовому представлению адресов IPv6» . IETF . дои : 10.17487/RFC5952 . РФК 5952 . Архивировано из оригинала 12 января 2024 года.
- ^ Хинден, Р .; Карпентер, Б.; Масинтер, Л. (август 2010 г.). «Формат буквальных адресов IPv6 в URL-адресах» . IETF . дои : 10.17487/RFC2732 . РФК 2732 . Архивировано из оригинала 5 января 2024 года.
- ^ Jump up to: а б с Нартен, Т. (август 1999 г.). «Обнаружение соседей и автоконфигурация без сохранения состояния в IPv6». IEEE Интернет-вычисления . 3 (4): 54–62. дои : 10.1109/4236.780961 .
- ^ Нартен, Т. (сентябрь 2007 г.). «Обнаружение соседей для IP версии 6 (IPv6)» . IETF . раздел 6.3.7. дои : 10.17487/RFC4861 . RFC 4861 . Архивировано из оригинала 17 января 2024 года.
- ^ Томсон, С. (сентябрь 2007 г.). «Автоконфигурация адреса без сохранения состояния IPv6 — раздел 5.5.1» . IETF . дои : 10.17487/RFC4862 . РФК 4862 . Архивировано из оригинала 11 января 2024 года.
- ^ «Политика выделения и назначения адресов IPv6» . РАЙП НКЦ . 8 февраля 2011 г. Архивировано из оригинала 3 июня 2023 г. . Проверено 27 марта 2011 г.
- ^ Бжозовский, Джон (31 января 2011 г.). «Comcast активирует первых пользователей с помощью встроенного двойного стека IPv6 через DOCSIS» (пресс-релиз). Комкаст . Архивировано из оригинала 23 октября 2023 года . Проверено 15 апреля 2019 г.
- ^ Сильвия Хаген (2014). Основы IPv6: интеграция IPv6 в вашу сеть IPv4 . О'Рейли Медиа, Инк. с. 176. ИСБН 9781449335267 .
- ^ «Механизм перехода IPv6/сравнение туннелирования» . Sixxs.net. Архивировано из оригинала 23 октября 2023 года . Проверено 20 января 2012 г.
- ^ Сильвия Хаген (2014). Основы IPv6: интеграция IPv6 в вашу сеть IPv4 . O'Reilly Media, Inc., стр. 222–223. ISBN 9781449335267 .
- ^ Карпентер, Б. (август 2011 г.). «Консультативные рекомендации по развертыванию 6to4» . IETF . дои : 10.17487/RFC6343 . RFC 6343 . Архивировано из оригинала 28 января 2023 года . Проверено 20 августа 2012 г.
- ^ «IPv6: двойной стек там, где можно; туннель там, где нужно» . networkworld.com. 5 сентября 2007 г. Архивировано из оригинала 20 января 2024 г. Проверено 27 ноября 2012 г.
- ^ Нордмарк, Э.; Гиллиган, Р. (октябрь 2005 г.). «Базовые механизмы перехода для хостов и маршрутизаторов IPv6» . IETF . дои : 10.17487/RFC4213 . РФК 4213 . Архивировано из оригинала 11 января 2024 года . Проверено 20 августа 2012 г.
- ^ Сильвия Хаген (2014). Основы IPv6: интеграция IPv6 в вашу сеть IPv4 . О'Рейли Медиа, Инк. с. 222. ИСБН 9781449335267 .
- ^ «Понимание двойного стека одноадресных адресов IPv4 и IPv6» . Джунипер.нет . Джунипер Нетворкс. 31 августа 2017 года . Проверено 19 января 2022 г.
- ^ «IPv6» . НРО.нет . Архивировано из оригинала 12 января 2017 года . Проверено 13 марта 2017 г.
- ^ Пуйоль, Энрик (12 июня 2017 г.). «Что останавливает трафик IPv6 у интернет-провайдера с двойным стеком?» . APNIC.net . АПНИК . Архивировано из оригинала 27 марта 2023 года . Проверено 13 июня 2017 г.
- ^ Воган-Николс, Стивен Дж. (14 октября 2010 г.). «Пять способов мирного сосуществования IPv6 и IPv4» . ЗДНЕТ . Архивировано из оригинала 5 декабря 2023 года . Проверено 13 марта 2017 г.
- ^ Сильвия Хаген (2014). Основы IPv6: интеграция IPv6 в вашу сеть IPv4 . О'Рейли Медиа, Инк. с. 33. ISBN 9781449335267 .
- ^ М. Коттон; Л. Вегода; Б. Хаберман (апрель 2013 г.). Р. Боника (ред.). Реестры IP-адресов специального назначения . IETF. сек. 2.2.3. дои : 10.17487/RFC6890 . BCP 153. RFC 6890 . Таблица 20.
- ^ Jump up to: а б Р. Хинден ; С. Диринг (февраль 2006 г.). Архитектура IP-адресации версии 6 . Сетевая рабочая группа. дои : 10.17487/RFC4291 . РФК 4291 .
- ^ OpenBSD по интерфейсам ядра Руководство –
- ^ Р. Гиллиган; С. Томсон; Дж. Баунд; Дж. Макканн; У. Стивенс (февраль 2003 г.). Базовые расширения интерфейса сокетов для IPv6 . Сетевая рабочая группа. дои : 10.17487/RFC3493 . РФК 3493 .
- ^ К. Бао; К. Уитема; М. Багнуло; М. Букадер; С. Ли (октябрь 2010 г.). IPv6-адресация трансляторов IPv4/IPv6 . IETF . дои : 10.17487/RFC6052 . РФК 6052 .
- ^ Гонт, Фернандо (10 марта 2019 г.), Безопасность IPv6 для инженеров IPv4 (PDF) , получено 30 августа 2019 г.
- ^ Гонт, Фернандо (10 января 2019 г.), Часто задаваемые вопросы по безопасности IPv6 (FAQ) (PDF) , получено 30 августа 2019 г.
- ^ Маллинз, Роберт (5 апреля 2012 г.), Shadow Networks: непреднамеренный побочный эффект IPv6 , заархивировано из оригинала 11 апреля 2013 г. , получено 2 марта 2013 г.
- ^ Чичилео, Гильермо; Гальяно, Роке; О'Флаэрти, Кристиан; и др. (октябрь 2009 г.). IPv6 для всех: Руководство по использованию и применению IPv6 в различных средах (PDF) . п. 5 . Проверено 2 марта 2013 г.
- ^ Дзюн-итиро итодзюн Хагино (октябрь 2003 г.). «Адреса, сопоставленные с IPv4, считаются вредными» .
- ^ Брэднер, С.; Манкин, А. (декабрь 1993 г.). «IP: запрос официального документа следующего поколения (IPng)» . РФК 1550 .
- ^ «История усилий IPng» . Солнце . Архивировано из оригинала 23 мая 2014 года.
- ^ Брэднер, Скотт О.; Мэнкин, Эллисон Дж. (январь 1995 г.). «Рекомендации по протоколу IP следующего поколения – Приложение B» . РФК 1752 .
- ^ Ван, Тао; Гао, Цзяцюн (1 января 2019 г.). «Недостатки IPv6 и обновление IPv4» . Международный журнал передовых сетей, мониторинга и контроля . 4 (1): 1–9. doi : 10.21307/ijanmc-2019-029 .
- ^ Состояние развертывания IPv6 в 2018 году , Internet Society , 2018, стр. 3
- ^ «Beijing2008.cn переходит в сеть нового поколения» (пресс-релиз). Пекинский оргкомитет игр XXIX Олимпиады. 30 мая 2008 г. Архивировано из оригинала 4 февраля 2009 г.
- ^ Дас, Кошик (2008). «IPv6 и Олимпийские игры 2008 года в Пекине» . IPv6.com . Архивировано из оригинала 1 августа 2008 года . Проверено 15 августа 2008 г.
- ^ Jump up to: а б Морр, Дерек (9 июня 2009 г.). «Verizon требует поддержки IPv6 для сотовых телефонов следующего поколения» . ID круга.
- ^ Jump up to: а б с «Состояние развертывания IPv6, 2018 г.» (PDF) . Интернет-сообщество.org . Интернет-сообщество . Проверено 19 января 2022 г.
Внешние ссылки
[ редактировать ]- IPv6 в ядре Linux, Рами Розен
- Введение и статистика об IPv6 от Google
- Стандартный документ, ратифицирующий IPv6 – документ RFC 8200, ратифицирующий IPv6 как стандарт Интернета.