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

Представление адресов IPv6 в DNS

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

Хранить соответствия между именами и адресами узлов надо, конечно же, в DNS. Какие изменения потребуются, чтобы инфраструктура DNS приобрела поддержку IPv6?

Первый кандидат на пересмотр — это прямая зона. В ней соответствия "имя -> адрес IPv4" хранились в виде записей RR A. У такой записи формат данных RDATA совершенно негибкий, так что правая сторона записи А может содержать только адрес IPv4. Следовательно, нам нужен новый тип записи RR, способный хранить адрес IPv6.

Если мы примем как неоспоримую истину, что IPv6 — это последнее и окончательное слово в протоколах сетевого уровня, то новый тип RR тоже не потребует особой гибкости: его поле данных RDATA будет просто адресом IPv6 в двоичном представлении с сетевым порядком байтов [§2.2 RFC 3596]. Адрес IPv6 вчетверо длиннее адреса IPv4, так что дадим новому типу RR остроумное имя AAAA [§2.1 RFC 3596]. Его общепринятый численный код — 28.

Текстовый формат записи AAAA очевиден: слева доменное имя, справа адрес IPv6 в стандартной нотации из §2.2. Например: www.example.org. AAAA 2001:db8:c001::f00d

Все, прямая зона к IPv6 готова. Перейдем к обратной зоне, хранящей соответствия "адрес -> имя". Эта зона привлекает записи PTR, а они не привязаны к определенному семейству адресов. На самом деле, эти записи вообще не имеют прямого отношения к адресам, так как их данные RDATA — доменные имена [§3.3.12 RFC 1035]. Однако сейчас нам нужно поместить адрес в левую часть такой записи, а там доменное имя содержится вообще у всех записей DNS.

Чтобы закодировать адрес IPv4 как доменное имя, пригодное для этой роли, потребовались следующие инструменты: обратная запись по байтам и служебный домен in-addr.arpa. Обратная запись позволяет делегировать префиксы IP в виде доменов. Это полезная особенность, и мы ее сохраним в IPv6. Между тем, мы понизим гранулярность делегирования до полубайта. Вдобавок, чтобы не путать IPv4 и IPv6, мы выделим новый служебный домен: ip6.arpa [§2.5 RFC 3596].

Каждому полубайту отвечает цифра в полной записи адреса IPv6 (без сокращений). Поэтому закодировать адрес IPv6 несложно: надо развернуть все сокращения, затем выписать цифры в обратном порядке через точку и, наконец, добавить справа домен ip6.arpa. Только и всего!

Например, приведенный выше адрес 2001:db8:c001::f00d в полной записи выглядит так:

2001:0db8:c001:0000:0000:0000:0000:f00d

Далее он превращается в такое доменное имя:

d.0.0.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.c.8.b.d.0.1.0.0.2.ip6.arpa.

Всего получится 32 уровня за вычетом ip6.arpa — по числу полубайтов в адресе IPv6. Так как это доменное имя, сокращенной записи для него не предусмотрено: все символы придется выписать полностью.

Естественным для нас вопросом будет, как соотносятся публикация адресов IPv6 в DNS и их зонная архитектура. В частности, будет ли иметь смысл внесение в DNS адресов, область действия которых меньше глобальной? Развернутый ответ на эти вопросы мы дадим в §6.7, когда у нас будут все необходимые инструменты. Однако уже сейчас нам интуитивно понятно, что в глобальных, публично доступных зонах DNS не следует размещать сведения о неглобальных адресах IPv6.

Помимо этого, даже в частном DNS адреса ограниченной области действия не может сопровождать zone_id, потому что он имеет смысл только в пределах одного узла, тогда как DNS поставляет свои сведения многим узлам сразу. Публиковать в DNS адреса с идентификаторами зон совершенно бессмысленно, и мы не ошиблись, отведя полю RDATA записи AAAA только 128 бит и полностью проигнорировав возможный zone_id. Зона действия полученного из DNS адреса IPv6 должна быть ясна из контекста, например, внутрисайтовые адреса принадлежат тому сайту, которых их размещает на своем частном сервере DNS; очевидно, они не должны быть видны другим сайтам во избежание двусмысленности.