Модификация системы dns для применения совместно с ipv6 реферат

Обновлено: 07.07.2024

В IPv4 поставщики интернет-услуг (ISP) обычно предоставляют своим клиентам информацию IN-ADDR.ARPA, предварительно заполняя зону одной записью PTR для каждого доступного адреса. Эта практика не масштабируется в IPv6. В этом документе анализируются различные подходы и соображения для интернет-провайдеров по управлению зоной IP6.ARPA.

Статус этой заметки

Этот документ не является спецификацией Internet Standards Track; опубликовано в ознакомительных целях.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Не все документы, утвержденные IESG, являются кандидатами на любой уровень интернет-стандарта; см. раздел 2 RFC 7841.

Уведомление об авторских правах

1. Введение

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

Администраторы интернет-провайдеров должны учитывать, нужны ли записи PTR клиента, и, если это так, оценивать способы ответа на обратные DNS-запросы в IPv6.

1.1. Обратный DNS в IPv4

Многие интернет-провайдеры генерируют записи PTR для всех IP-адресов, используемых для клиентов, а многие создают соответствующую запись A.

1.2. Обратное рассмотрение DNS в IPv6

Интернет-провайдеры часто делегируют префикс IPv6 своим клиентам. Поскольку в одной / 48 зоне может быть сконфигурировано 2 ^^ 80 возможных адресов, нецелесообразно записывать зону с каждым введенным возможным адресом, даже с автоматизацией. Если бы 1000 записей могли быть записаны в секунду, зона была бы неполной через 38 триллионов лет.

Кроме того, часто невозможно связать имена хостов и адреса, так как 64 бита в части идентификатора интерфейса адреса часто назначаются с помощью автоматической конфигурации адреса без сохранения состояния (SLAAC) [RFC4862], когда хост подключается к сети, и они могут быть недолговечными.

2. Альтернативы в IPv6

Существует несколько вариантов предоставления обратного DNS в IPv6. Все эти параметры также существуют для IPv4, но проблема масштабирования гораздо менее серьезна в IPv4. Каждый вариант должен оцениваться на предмет его способности к масштабированию, соответствия существующим стандартам и передовым методам и доступности в общих системах.

2.1. Отрицательный ответ

Некоторые DNS-администраторы интернет-провайдера могут выбрать предоставление только ответа NXDOMAIN на запросы PTR для адресов абонентов. В некотором смысле это самый точный ответ, так как информация об имени хоста не известна. Однако предоставление отрицательного ответа на запросы PTR не удовлетворяет ожиданию в [RFC1912] совпадений записей. Пользователи служб, которые зависят от успешного поиска, будут иметь плохой опыт. Например, некоторые веб-службы и соединения Secure Shell (SSH) ждут ответа DNS, даже NXDOMAIN, прежде чем ответить. Поэтому для лучшего взаимодействия с пользователем важно возвращать ответ, а не время без ответа. С другой стороны, внешние почтовые серверы могут отклонять соединения, что может быть преимуществом в борьбе со спамом.

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

2.2. Подстановочный знак

Использование подстановочных знаков в DNS описано в [RFC4592], а их использование в обратном DNS IPv6 описано в [RFC4472].

Это решение обычно хорошо масштабируется. Однако, поскольку ответ будет совпадать с любым адресом в диапазоне символов подстановки (/ 48, / 56, / 64 и т. Д.), Прямой поиск DNS по данному ответу не сможет вернуть одно и то же имя хоста. Таким образом, этот метод не соответствует ожиданиям в [RFC1912], что прямое и обратное совпадение будут совпадать. Масштабируемость DNSSEC [RFC4035] ограничена подписанием подстановочной зоны, что может быть удовлетворительным.

2.3. Динамический DNS

Один из способов обеспечения совпадения прямой и обратной записей состоит в том, что хосты динамически обновляют DNS-серверы после завершения настройки интерфейса (с помощью SLAAC, DHCPv6 или другими способами), как описано в [RFC4472]. Хозяева должны будут предоставлять обновления AAAA и PTR и должны знать, какие серверы будут принимать информацию.

2.3.1. Динамический DNS от отдельных хостов

Как только он узнает свой адрес и имеет разрешающий сервер имен, хост должен выполнить поиск SOA для записи IP6.ARPA, которая будет добавлена, чтобы найти владельца и, в конечном итоге, сервер, который является полномочным для зоны (которая может принимать динамические обновления). Может потребоваться несколько рекурсивных поисков, чтобы найти самый длинный префикс, который был делегирован. Администратор DNS должен назначить основной главный сервер для самого длинного требуемого соответствия. После обнаружения хост отправляет динамические обновления AAAA и PTR с использованием определенной выше конкатенации ("hostname.customer.example.com").

Чтобы использовать эту альтернативу, хосты должны быть настроены на использование динамического DNS. Это не поведение по умолчанию для многих хостов, что является препятствием для большого провайдера. Эта опция может быть масштабируемой, хотя регистрация после сбоя может вызвать значительную нагрузку, и хосты, использующие расширения конфиденциальности [RFC4941], могут обновлять записи ежедневно. Хост должен предоставить совпадающие прямые и обратные записи и обновить их при изменении адреса.

2.3.2. Динамический DNS через жилые шлюзы

У частных клиентов может быть шлюз, который может предоставлять хостам услугу DHCPv6 с делегированного префикса. Интернет-провайдеры должны предоставить шлюзу сервер рекурсивных имен DNS и список поиска домена, как описано выше и в [RFC3646] и [RFC8106]. Существует два варианта того, как шлюз использует эту информацию. Первый вариант - шлюз отвечает на запросы DHCPv6 тем же сервером рекурсивных имен DNS и списком поиска доменов, предоставленным провайдером. Альтернативный вариант - для шлюза передавать динамические обновления DNS с хостов на серверы и в домен, предоставляемые провайдером. Поведение хоста не изменилось; хост отправляет те же динамические обновления либо на сервер интернет-провайдера (предоставляемый шлюзом), либо на шлюз для пересылки. Шлюз должен быть способен и настроен на использование динамического DNS.

2.3.3. Автоматическое делегирование DNS

Затем провайдер может также делегировать зону IP6.ARPA для префикса, делегированного клиенту, как в (для 2001:db8:f00::/48) "0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA".

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

Если шлюз клиента является сервером имен, он предоставляет свою собственную информацию хостам в сети, как описано в [RFC2136], что часто делается для корпоративных сетей.

Интернет-провайдер может предоставить достоверные ответы в качестве вторичного сервера на главный сервер клиента. Например, домашний сервер имен шлюзов может быть главным сервером, а провайдер предоставляет только опубликованные NS-серверы.

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

2.3.4. Генерация динамических записей

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

Этот метод также зависит от способности хостов предоставлять динамические обновления DNS, что не является поведением по умолчанию для многих хостов.

2.3.5. Заполнить с DHCP-сервера

Сервер DHCPv6 интернет-провайдера может заполнять прямую и обратную зоны при получении запроса DHCP, если запрос содержит достаточно информации [RFC4704].

2.3.6. Заполните с сервера RADIUS

Пользователь может получить адрес или префикс от сервера RADIUS [RFC2865], подробности которого могут быть записаны с помощью данных учета RADIUS [RFC2866]. Интернет-провайдер может заполнить прямую и обратную зоны из учетных данных, если он содержит достаточно информации. Это решение позволяет интернет-провайдеру заполнять данные, относящиеся к выделенным префиксам в соответствии с разделом 2.2 (подстановочные знаки) и конечными точками абонентского оборудования (CPE). Однако, как и в разделе 2.3.5, он не позволяет интернет-провайдеру заполнять информацию об отдельных хостах.

2.4. Делегировать DNS

Для клиентов, которые могут запускать свои собственные DNS-серверы, таких как коммерческие клиенты, часто лучшим вариантом является делегирование им обратной зоны DNS, как описано в [RFC2317] (для IPv4). Тем не менее, поскольку большинство пользователей в жилых помещениях не имеют ни оборудования, ни опыта для работы с DNS-серверами, этот метод недоступен для бытовых интернет-провайдеров.

Это общий случай конкретного случая, описанного в разделе 2.3.3. Все те же соображения все еще применяются.

Обычной практикой в IPv4 является предоставление записей PTR для всех адресов, независимо от того, использует ли хост адрес в действительности. В IPv6 интернет-провайдеры могут генерировать записи PTR для всех адресов IPv6, когда запрашиваются записи. Несколько DNS-серверов способны на это.

DNSSEC [RFC4035] подписание записей на лету может увеличить нагрузку; неподписанные записи могут указывать, что эти записи менее надежны, что может быть приемлемо.

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

3. Ручные обновления пользователя

Можно создать пользовательский интерфейс, такой как веб-страница, который позволил бы конечным пользователям вводить имя хоста для связи с адресом. Такой интерфейс должен быть аутентифицирован; только авторизованный пользователь может добавлять / изменять / удалять записи. Если провайдер изменит префиксы, назначенные клиентам, интерфейсу потребуется указать только биты хоста. Следовательно, серверная часть должна быть интегрирована с назначением префикса, чтобы при назначении нового префикса клиенту служба DNS искала созданные пользователем имена хостов, удаляла старую запись и создавала новую.

Соображения по поводу того, что некоторые записи являются статическими, а другие динамическими или динамически генерируемыми (Раздел 2.5) и творческий подход пользователей (Раздел 5.5), все еще применимы.

4. Соображения и рекомендации

Существует шесть распространенных вариантов использования поиска PTR:

В качестве общего руководства, когда присвоение адреса и имя находятся под одним и тем же полномочием или когда хост имеет статический адрес и имя, записи AAAA и PTR должны существовать и совпадать. Для бытовых пользователей, если эти варианты использования важны для интернет-провайдера, администратор должен будет рассмотреть, как предоставить записи PTR.

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

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

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

5. Вопросы безопасности и конфиденциальности

5.1. Использование обратного DNS для безопасности

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

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

5.2. Безопасность DNS с динамическим DNS

Вопросы безопасности для использования динамического DNS описаны в [RFC3007]. Расширения безопасности DNS описаны в [RFC4033].

Взаимодействие с DNSSEC описано в этом документе.

5.3. Соображения по поводу другого использования DNS

Существует несколько способов предоставления ключей шифрования в DNS. Любой из представленных здесь вариантов может мешать этим ключевым методам.

5.4. Вопросы конфиденциальности

Учитывая соображения в [RFC8117], имена хостов, которые предоставляют информацию о пользователе, ставят под угрозу его конфиденциальность. Некоторые пользователи могут захотеть идентифицировать свои хосты, используя указанные им имена хостов, но поведение по умолчанию не должно заключаться в том, чтобы идентифицировать пользователя, его местоположение, их подключение или другую информацию в записи PTR.

5.5. Творчество пользователя

6. Соображения IANA

В этом документе нет действий IANA.

7. Ссылки

7.1. Нормативные ссылки

[RFC1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996, .

[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997,
.

[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
.

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000,
.

[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000,
.

[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
.

[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003,
.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005,
.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
.

[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
.

[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, .

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007,
.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
.

[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
.

[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017,
.

7.2. Информационные ссылки

[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998,
.

[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, DOI 10.17487/RFC4472, April 2006,
.

[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011,
.

[RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname Practice Considered Harmful", RFC 8117, DOI 10.17487/RFC8117, March 2017,
.

Подтверждения

Автор хотел бы поблагодарить Алена Дюранда, JINMEI Tatuya, Дэвида Фридмана, Эндрю Салливана, Криса Гриффитса, Даррила Таннера, Эд Льюиса, Джона Бржозовского, Криса Донли, Уэса Джорджа, Джейсона Вейля, Джона Спенса, Теда Лемона, Стефана Лагерхольма, Стейнара Хауга Марк Эндрюс, Крис Рузенраад, Фернандо Гонт, Джон Левин и многие другие, которые обсуждали и предоставляли предложения для этого документа.

IPv6-адреса представлены в системе доменных имен в виде АААА-записей (так называемых 4А-записей) для поиска вперед; для обратного поиска используется ip6 .arpa (ранее ip6 .int) с помощью отсечения адреса. Эта схема является простой адаптацией А-записей и in-addr.arpa схемы, определенной в RFC 3596.

АААА-схема была предложена одной из первых во время разработки архитектуры IPv6. Другое предложение, содержало идею A6-записей для поиска вперед и ряд других нововведений, таких, как bit-string labels и DNAME-записи. Оно представлено в экспериментальном RFC 2874 и ссылается (с последующими обсуждение преимуществ и недостатков обеих систем) на RFC 3364.

AAAA-запись

NAME	доменное имя
TYPE	AAAA (28)
CLASS	Internet (1)
TTL	Time to live в секундах
RDLENGTH	длина поля RDATA
RDATA	строковое представление IPv6-адреса, определенное в RFC 3513

RFC 3484 определяет, каким образом следует приложениям выбирать IPv6 или IPv4-адрес для использования, в том числе это касается адресов, извлеченных из DNS.

IPv6 и DNS RFC

RFC 2874 – DNS Extensions to Support IPv6 Address Aggregation and Renumbering – Defines the A6 record
RFC 3364 – Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)
RFC 3484 – Default Address Selection for Internet Protocol version 6 (IPv6)
RFC 3513 – Internet Protocol Version 6 (IPv6) Addressing Architecture
RFC 3596 – DNS Extensions to Support IP Version 6 – Defines the AAAA record and obsoletes RFC 1886 and RFC 3152

До тех пор, пока IPv6 окончательно не вытеснит IPv4, что вряд ли произойдет в обозримом будущем, будут использоваться переходные механизмы, необходимые для того, чтобы IPv6-узлы могли использовать IPv4-сервися и чтобы изолированные IPv6-хостов и сети могли использовать IPv6-интернет через IPv4-инфраструктуры.

Двойной стек

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

Большинство современных реализаций IPv6 используют двойной стек. В некоторых ранних экспериментальных реализациях используется независимые стеки IPv4 и IPv6. Есть также реализации, которые осуществляют поддержку только IPv6.

Туннели

Для того чтобы добраться до IPv6-интернет, изолированные узлы или сети должен иметь возможность использовать существующие инфраструктуры IPv4 для передачи IPv6-пакетов. Это можно сделать, используя метод, известный как туннелирование, который заключается во встраивании IPv6-пакетов в IPv4, по сути IPv4, используя в качестве канального уровня для IPv6.

IPv6-пакеты могут быть непосредственно встроены в IPv4-пакеты с использованием протокола номер 41. Они также могут быть встроены в UDP-пакеты, например, для использования перекрестной маршрутизации или NAT, которые блокируют трафик протокола 41. Они, конечно, могут использовать общие схемы инкапсуляции, как например, AYIYA или GRE.

Автоматическое туннелирование

Автоматическое туннелирование относится к технике, в которой конечные точки туннеля, автоматически определяется маршрутизирующей инфраструктурой. Рекомендованной методикой для автоматического туннелирования является 6to4-туннель, который использует протокол инкапсуляции 41. Конечные точки туннеля определяется с помощью хорошо известных IPv4 anycast-адресов на принимающей стороне, и вложения IPv4 адреса в IPv6 адреса на отправляющей стороне. 6to4 широко используется на данный момент.

Еще одним механизмом автоматического туннелирования является ISATAP. Этот протокол “видит” IPv4-сеть как виртуальную местную IPv6-сеть, с маппингом IPv4-адресов в локальные IPv6-адреса.

Teredo является автоматическим методом туннелирования, который использует UDP инкапсуляцию. Создатели утверждают, что пакеты способны пересечь несколько NAT-трансляций. Teredo не нашел широкого применения, но экспериментальные версии его встроены в Windows XP SP2 IPv6-стек. IPv6, 6to4 и Teredo включены по умолчанию в Windows Vista и Mac OS X Leopard от Apple AirPort Extreme.

Настраиваемое туннелирование

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

Настраиваемое туннелирование использует протокол 41 в IPv4-пакетах. Этот метод также известен как 6in4.

Прокси и трансляция

Когда IPv6-узел нуждается в доступе к IPv4-сервису (например, веб-серверу), в той или или иной форме требуется трансляция. Одной из форм трансляции является двухстекового прокси уровня приложений, например, веб-прокси.

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

О разном

Вам нужен ремонт квартир требовавший качественного исполнения? Обращайтесь в компанию ЛЮКСРЕМОНТ. Мы давно и успешно работаем на данном рынке.

Этот пост March 27, 2009 at 12:33 pm опубликовал molse в категории IPv6, Сетевые протоколы. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

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

Адресация

Начал я с того, что попросил администрацию университета выделить мне кусочек лабораторного диапазона IPv6 для своей небольшой песочницы. Мне был торжественно делегирован префикс 2001:6b0:32::/49. Поначалу я обижался и несколько раз хотел бежать и просить еще, но в итоге, прибросив схему адресации так и этак на бумаге, я решил что 6x10 23 адресов должно хватить.
Определившись с адресацией, я настроил интерфейсы на маршрутизаторах. Здесь необходимо сказать, что маршрутизаторы в CareNet необычные, построенные на базе высокопроизводительной аппаратно-программной Linux-платформы Bifrost. Это университетская разработка выходящая сейчас на коммерческий рынок. Интерфейсы между маршрутизаторами имеют пропускную способность 10 Гбит/с. За маршрутизацию (control plane) отвечает программный пакет Quagga.

Внутренняя маршрутизация, OSPFv3

Добавив IPv6 адреса на интерфейсы маршрутизаторов я запустил OSPFv3 в качестве динамического протокола маршрутизации. Настройки базовые, одна OSPF-зона 0.0.0.0. Технического объяснения почему выбран OSPF не будет. Лично я выбираю по названию. RIPng мне не нравится. Вот IS-IS с удовольствием, но Quagga его не поддерживает.
С пакетом Quagga работал впервые, но освоился моментально потому что командный интерфейс аналогичен Cisco CLI. Пример конфигурации демона ospf6d привожу для двух маршрутизаторов:

Динамическое выделение адресов, DHCPv6

Маршрутизация активирована и следующим возник вопрос о динамическом выделении IPv6-адресов серверам в ферме и клиентам в сетях доступа. Эту задачу решено было возложить на DHCPv6 сервер. Я развернул два DHCPv6-сервера: ISC DHCP и Dibbler. Был организован конкурс по условиям которого тот из серверов, кто первым обслужит клиента выделив ему IPv6 адрес, останется функционировать. Dibbler оказался расторопнее, поэтому ISC DHCP был уничтожен. Пример настройки диапазонов выделяемых адресов:

Внешняя маршрутизация, BGP

Внутренняя маршрутизация функционирует, клиенты получили адреса, дело за малым — открыть IPv6 доступ в интернет. Догадываясь о том, что мой непосредственный сосед — AS 2839 (KTH-LAN) уже является частью глобального IPv6 пространства, я осмелился просить его администраторов разрешить мне установить с KTH-LAN дополнительную сессию BGP для объявления моего префикса IPv6. После согласования всех технических деталей соседство IPv6 BGP было установлено. Пара дней ушла на то, чтобы убедить автономную систему следующую далее по цепочке (SUNET) обновить свои входящие BGP-фильтры и наконец выпустить мой префикс в свободное плавание. Конфигурация демона bgpd:

Помимо фильтрации объявляемых и принимаемых префиксов неплохо было бы активировать идентичные фильтры непосредственно для пересекающего границу автономной системы трафика, как механизм противодействия атакам “IP spoofing”. Простой список контроля доступа ACL вполне справится с этой задачей.

DNS для IPv6

Напоследок расскажу как был настроен DNS для работы с адресами IPv6. Устанавливать DNS сервер с нуля не потребовалось, потому что в сети уже имелся сервер BIND, обслуживающий диапазон IPv4. В прямую DNS-зону к уже имеющимся адресам IPv4 были добавлены записи IPv6. Довольно прямолинейно и просто, но на всякий случай приведу пример конфигурации:

А вот с обратной зоной (reverse DNS lookup) пришлось повозиться. Был создан отдельный файл, названный в соответствии с канонами 2.3.0.0.0.b.6.0.1.0.0.2.ip6.arpa. Название образовано из префикса 2001:6b0:32::/49 записанного в обратном порядке и дополненного нулями. Далее в достаточно недружелюбном и трудном к восприятию формате добавлены обратные DNS-записи для всех IPv6-систем в сети. Часть конфигурации приведена ниже:

Заключение и дополнительная информация

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

Переход от IPv4 к IPv6 является процессом , который направлен на постепенно заменить IPv4 с IPv6 в Интернете .

Резюме

Фазы перехода

Адреса IPv4 и IPv6 несовместимы, поэтому связь между хостом, имеющим только адреса IPv6, и хостом, имеющим только адреса IPv4, является проблемой.

Возможны два подхода к общению:

переводчики протоколов,
двойной стек.

Трансляция протокола может происходить на нескольких уровнях: сетевой (NAT-PT, NAT64), транспортный (TRT, RFC 3142 ) или прикладной (DNS-ALG, RFC 2766 ). Хотя его можно использовать для обеспечения связи для ограниченного числа хостов или приложений, преобразование сталкивается с проблемами масштабирования ( RFC 4966 ).

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

На втором этапе двойной стек будет распространен на большую часть Интернета. Поэтому использование IPv6 поверх туннелей IPv4 становится все менее и менее необходимым.

На заключительном этапе происходит постепенный отказ от IPv4 в Интернете. Некоторые частные сети продолжают использовать его, поскольку подключение к Интернету не требуется.

Переход для индивидуальных хостов и корпоративных сетей

Самый простой способ получить доступ к IPv6 - при подписке выбрать поставщика услуг Интернета, который изначально предлагает IPv6 , то есть не прибегая к туннелям.

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

Явно настроенные туннели

Используемые протоколы могут быть:

6in4 ( RFC 4213 ) использует IP-протокол номер 41 и поэтому иногда блокируется межсетевыми экранами и NAT.
AYIYA позволяет передавать данные по UDP или TCP и управляет изменением IP-адреса.
GRE использует протокол номер 47.

Setup Tunnel Protocol ( RFC +5572 ) облегчает создание туннеля и обеспечивает мобильность и аутентификацию. Протокол информации и управления туннелями , используемый AICCU (in) , автоматизирует создание туннелей.

6to4 ( RFC 3056 ), если доступен общедоступный (предпочтительно фиксированный) IPv4-адрес, настроить 6to4 в принципе было просто. Для доступа к IPv6-адресам за пределами префикса 2002 :: / 16 (зарезервирован для 6to4) был зарезервирован произвольный адрес ретрансляции 192.88.99.1, но позже он был объявлен устаревшим из-за неразрешимых операционных проблем (что привело к 6to4 в категории автоматических туннели; административное использование остается возможным, но не рекомендуется)
6over4 ( RFC 2529 ) позволяет подключаться через сеть IPv4, которая поддерживает многоадресную рассылку.
ISATAP ( RFC 5214 ), усовершенствованный по сравнению с предыдущим, который не требует поддержки многоадресной рассылки.
Teredo ( RFC 4380 ) может использоваться в сети частных IPv4-адресов, подключенных к Интернету через маршрутизатор, обеспечивающий преобразование адресов. Реализация Teredo является частью стека IPv6 для систем Windows , а реализация для систем Linux и BSD - miredo.

Трансляция IP / ICMP без сохранения состояния (SIIT, RFC 2765 ) - это механизм трансляции заголовков между IPv6 и IPv4. RFC обычно не описывает связывание адресов IPv6 и IPv4. Работа SIIT не позволяет связывать более двух уникальных адресов каждого протокола на хост. Это означает, что каждый хост IPv6 также должен иметь общедоступный IPv4-адрес.

NAT-PT ( RFC 2766 ) аналогичен. Промежуточные маршрутизаторы между IPv6 и IPv4 изменяют заголовки. Прокси-сервер DNS проверяет запросы от хостов и назначает фиктивные адреса IPv4 или IPv6, когда ответ DNS указывает на отсутствие семейства. Однако использование модификации DNS RR делает DNSSEC неработоспособным.
Однако RFC NAT-PT классифицируется как исторический и поэтому больше не рекомендуется. Причины этой классификации подробно описаны в RFC 4966 .

Механизм перехода с двойным стеком (DSTM) также обеспечивает преобразование адресов IPv4 и IPv6.

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

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

Можно использовать серверы с двойным стеком, которые действуют как шлюз уровня приложения (ALG), например , веб- прокси- сервер .

NAT64 и DNS64

RFC 6146 и RFC 6147 описывает транслятор протокола , который позволяет хостам IPv6 для доступа к серверам IPv4.

DNS64 выполняет манипуляции с доменным именем и предоставляет в своем ответе клиенту адрес IPv6 (AAAA) для имени хоста, имеющего адрес IPv4 (A), но не адреса IPv6. Он построен с зарезервированным префиксом 64: ff9b :: / 96, к которому мы добавляем 32 бита адреса IPv4 (возможны другие методы, если инкапсуляция адреса IPv4 согласована между NAT64 и DNS64). Когда NAT64 получает соединение с адресом типа 64: ff9b :: / 96 в качестве пункта назначения, он создает запись в таблице состояний и назначает этому потоку номер выходного порта (преобразование портов) или IPv4-адрес из группы. (преобразование адресов), который будет взят в качестве источника потока IPv4. NAT64 работает с TCP, UDP и ICMP.

NAT64 и DNS64 не нуждаются в взаимодействии. Если клиент использует DNSSEC и проверяет сам ответ, то DNS64 не может работать должным образом. Аналогично, если AH IPsec активен и защищает заголовок, NAT64 не будет работать должным образом.

Переход для операторов и провайдеров доступа

Столкнувшись с исчерпанием адресов IPv4 и необходимостью предоставления услуг IPv6 своим клиентам, операторы адаптируют свои IP-сети. Их основные проблемы заключаются в следующем:

предоставлять клиентам услугу транзита IPv6 на том же уровне, что и транзит IPv4,
обеспечить непрерывность транзита в Интернет IPv4, несмотря на исчерпание адресов IPv4.

Есть ряд сценариев, которые изучаются и являются предметом интернет-проектов. Они различаются по степени прогрессивности развертывания и надежности решения.

NAT операторского класса

Использование крупномасштабного NAT ( NAT операторского класса , Large Scale NAT или NAT44) решает проблему отсутствия адреса IPv4 для назначения клиентам. Он состоит из распределения частных адресов между шлюзом новых клиентов вместо публичного адреса и преобразования этих адресов в публичные адреса в Интернете.

CGN использует трансляцию портов, поэтому один публичный адрес используется многими клиентами. Количество шлюзов TCP и UDP зарезервировано в публичных адресах для каждого из клиентов. Учитывая, что существует 65 535 номеров портов, и предполагая, что общий адрес используется 100 клиентами, каждый клиент имеет приблизительно 650 номеров портов, то есть как можно больше одновременных подключений. Нет единого мнения о минимальном количестве портов, которое следует назначить каждому клиенту. Некоторые приложения, которые устанавливают много параллельных подключений, могут пострадать, если это число слишком мало.

Несмотря на то, что это значительно снижает потребность в адресе IPv4, CGN не является переходной системой как таковой, а используется в сочетании с другими подходами для обеспечения непрерывного подключения к Интернету IPv4.

CGN для перехода на IPv6

CGN можно использовать для плавного перехода к IPv6 путем инкапсуляции трафика IPv6 в туннель IPv4 по схеме, аналогичной 6rd.

A + P - это метод, который позволяет использовать определенное количество битов номера порта TCP или UDP для маршрутизации. Он описан в RFC 6346.

Поэтому несколько CPE могут использовать один и тот же IP-адрес, но с разными диапазонами портов. Маршрутизация к CPE использует не только IP-адрес, но и несколько битов номера порта.

Как и CGN, A + P адресует исчерпание IP-адресов, но не является методом перехода на IPv6.

Переводчик протокола

NAT-PT (преобразование протоколов ), NAT64, NAT46 или AFT ( преобразование семейства адресов ) могут преобразовывать IPv4 и IPv6. Если он не имеет гражданства, его также называют IVI.

Это позволяет назначать клиентам адреса IPv6, сохраняя при этом возможность подключения к Интернету IPv4.

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

NAT-PT связан с DNS в RFC 2766, но был устаревшим в RFC 4966 из-за проблем.

6rd (rd для быстрого развертывания , RFC 5569 ) - это вариант 6to4, в котором задействован провайдер, а не интернет-шлюзы. Префикс 2002 :: / 16, зарезервированный для 6to4, не используется, но используется адресное пространство IPv6 поставщика доступа. Маршрутизатор клиента ( домашний шлюз , HG) инкапсулирует трафик IPv6 в туннель, предназначенный для хорошо известного адреса 6-го шлюза провайдера.

Его можно использовать в сочетании с CGN.

6rd был развернут вендором Free в 2007 году.

Двойной стек Lite

Dual-Stack Lite - это подход, при котором сеть интернет-провайдера изначально переводится на IPv6. Трафик IPv4 клиентского шлюза инкапсулируется в туннель IPv6, называемый softwire, и завершается на шлюзе DS-Lite провайдера. Это действует как CGN для IPv4. Это устраняет необходимость назначать общедоступные IPv4-адреса маршрутизаторам клиентов.

Кадры Ethernet могут транспортироваться на уровне 2 в сети MPLS.

В сети MPLS метод 6PE ( RFC 4798 ) позволяет соединять клиентов IPv6 с маршрутизаторами PE, сохраняя ядро сети (P) в IPv4.

Основные маршрутизаторы P обмениваются метками и не знают IPv6. Уровень управления MPLS остается в IPv4 (соединения маршрутизаторов MPLS , IGP , LDP и / или RSVP , а также транспорт MP-BGP ).

Префиксы IPv6 обмениваются через MP-BGP между 6PE, следующим переходом является отображение IPv6-адреса IPv4 в форме :: ffff: 0: 0/96, за которым следуют 32 бита IPv4-адреса PE. Однако префиксы включены в GRF, а не в IPv6 VPRN.

Предпоследний Hop Popping (PHP) в последний P маршрутизатор открыть пакет IPv6 до его передачи в EP Eler (выход этикетки Пограничный маршрутизатор), несмотря на то, что маршрутизатор P не ожидается , иметь знания о IPv6. Поэтому в 6PE дополнительная метка (например, метка IPv6 Explicit-Null) всегда добавляется маршрутизатором PE iLER (входящий пограничный маршрутизатор метки), поэтому всегда используется Ultimate Hop Popping (UHP).

Эта технология более эффективна, чем туннель IPv6 поверх IPv4, и допускает постепенное развертывание. Однако отсутствие действительного IPv6 VPRN может быть ограничением.

6VPE ( RFC 4659 ) позволяет создать реальный IPv6 VPRN и является простым функциональным эквивалентом IPv6 для IPv4 VPRN: L3VPN MPLS IPv6.

4rd позволяет операторам развертывать домены, в которых используется только протокол IPv6, сохраняя при этом для пользователей остаточную услугу IPv4.

Спецификация 4rd является предметом RFC 7600 . Он находится в экспериментальной категории в IETF .

Другие услуги

Развертывание IPv6 в сети оператора также предполагает изменения:

Во Франции

Во Франции ARCEP выпустила отчет о переходе с IPv4 на IPv6 в октябрь 2016 .

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

В 2016 году нехватка IPv4-адресов привела к существованию непрозрачного рынка, на котором IPv4-адреса продаются по цене около 10 евро за адрес.

RIPE-NCC на которой Франция зависит предвидит глобальный конец доступности IPv4 - адресов на 2021 Тем не менее, многие игроки уже лишены способности приобретать новые адреса IPv4.

Во Франции реализуются обходные пути, например, через NAT, но эти исправления имеют различные недостатки: сбои в работе определенных приложений, отсутствие устойчивости, в частности, стоимость внедрения и обслуживания.

Серверы AFNIC используются только до 18% для транспорта IPv6.

Провайдер контента видит, что только 10,5% пользователей во Франции используют технологию IPv6 с точки зрения Google и от 10 до 12 с точки зрения Akamai на момент составления отчета.

Для Cisco 50% онлайн-контента доступно в IPv6, но некоторые правительственные веб-сайты с более высоким трафиком не могут быть просмотрены в IPv6, а также некоторые сайты государственных услуг, такие как те, которые используются для медицинского страхования или в фонд семейных пособий.

По данным Cisco, доля транзитных сетей, используемых поставщиками доступа и контента, расположенными во Франции, составляет около 70% для совместимости с IPv6.

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

Читайте также: