Итак, пришло «письмо счастья» из RIPE и вы стали счастливым обладателем блока IPv6-адресов. Затем вы сконфигурировали IPv6 на магистральных маршрутизаторах, настроили этот протокол на базовых провайдерских серверах (сервисах) и «довели» его до уровня распределения-доступа. Теперь нужно начинать планировать раскладку («нарезку») этого блока по подсетям, клиентам, сервисам, регионам и прочим офисам, причем чем тщательнее и продуманнее будет эта раскладка, тем легче будет в дальнейшем.

Небольшое отступление: изменится ли что-нибудь в схемах подключения при внедрении IPv6 (речь идет о схемах подключения мелких-средних клиентов)?

Какие схемы подключения клиентов используются в Ipv4?

Раньше (10 лет назад) использовалась «каноническая»: между клиентским роутером и роутером провайдера конфигурировалась подсеть /30, а на входной адрес на стороне клиента маршрутизировалась подсеть для него. Со стороны провайдера такая подсеть /30 могла конфигурироваться на отдельном физическом интерфейсе роутера, или на субинтерфейсе, или на виртуальном интерфейсе (после появления L3-свитчей). Проблема в том, что интерфейсов, субинтерфейсов или виртуальных интерфейсов можно сконфигурировать не так уж много, их количетво ограничено используемой моделью роутера или версией его операционной системы. Как правило, сейчас так подключают соседей-операторов или крупных клиентов.

Часто встречается случай, когда в офисном здании размещается несколько десятков (или сотен) офисов, сдаваемых в аренду, а арендатору требуется всего один IP-адрес. То есть у вас (у провайдера) установлен маршрутизатор, а после него установлено некоторое количество свитчей, к портам которых подключены другие ваши свитчи или клиентское оборудование. Вся структура разбивается на подсети и соответствующие им VLAN, далее все это распределяется при помощи dot1Q, а все вместе называется “router-on-the-stick”

В таких случаях клиентов с потребностью в 1-2 адреса обычно обьединяют в одну достаточно большую подсеть, клиенту выделяют адрес, который автоматически или вручную конфигурируется на клиентском компьютере или NAT-роутере (это в случае, если у клиента несколько компьютеров обьединены в локальную сеть).

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

В чем будет принципиальная разница при использовании IPv6? Только в том, что у клиента будет или один-единственный адрес, предоставленный провайдером (только в случае, если у клиента будет использоваться один компьютер), или подсеть, предоставленная провайдером, так как при предоставлении IPv6-доступа в интернет не предусматривается использование NAT: каждому клиенту нужно выделять подсеть, или предусмотреть выделение посети в будущем, когда у клиента появится еще один компьютер и желание построить локальную сеть. Желательно сразу предусмотреть выделение посдети, но поначалу сильно «давит» жадность, привычка экономить Ipv4-адреса.

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

Какого же размера подсеть можно (нужно) выделять для каждого клиента? RIPE рекомендует для соединений «точка-точка» использовать подсеть /64, а клиентам маршрутизировать /56, другие источники рекомендуют ограничиться на подсети для клиента размером /64 . Рассмотрим практические примеры:

На первом этапе, с целью упрощения процедуры перехода (или точнее — с целью упрощения внедрения dual-stack), и с целью избежать путаницы, можно сохранить сетевые адреса старых подсетей в структуре IPv6-адересов. В случае, если в вашем распоряжении имеется только один Ipv4-префикс с маской /16 или длиннее, это сделать совсем просто — достаточно перенести значения последних 16 бит из IPv4-адреса в 33-64 биты IPv6-адреса, и независимо от маски IPv4-подсети выбирать маску /64 для соответствующих IPv6-подсетей.

Далее везде в примерах предполагается, что у вас был блок 198.18.0.0/16, и вы получили 2001:db8::/32.

**Старая IPv4-подсеть  -  Новая IPv6-подсеть**

    198.18.231.0 /24 —> 2001:db8:231::/64

    198.18.231.64 /26 —> 2001:db8:231:64::/64

    198.18.232.252 /30 —> 2001:db8:232:252::/64

То есть можно «перенести» меняющуюся часть адреса, а маску выбрать /64. Адресов хватит…

Все достаточно очевидно, но возникает неоднозначность с первыми подсетями: 198.18.231.0/24, 198.18.231.0/26, 198.18.231.0/27. Тут можно использовать буквенные обозначения:

    198.18.231.0/24 —> 2001:db8:231::/64 или 2001:db8:2310::/64

    198.18.231.0/25 —> 2001:db8:231a::/64

    198.18.231.0/26 —> 2001:db8:231b::/64

    198.18.231.0/27 —> 2001:db8:231c::/64

.. и так далее.

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

    2001:db8:a::1 2001:db8:b::2 для DNS, 
    2001:db8:a::11 2001:db8:b::12 для SMTP, 
    2001:db8:f::1 2001:db8:f::2 для WWW

… и так далее.

(не забудем приберечь для себя на будущее короткие «вкусные» адреса вида 2001:db8::1 2001:db8:1::1 2001:db8:2::1 )

А что, если у вас несколько префиксов с маской длиннее /16 ? Да ничего страшного, можно использовать такую же схему обозначений, а соответствующий префикс обозначать буквой, например:

• 198.18.xxx.yyy/zz —> 2001:db8:axxx:yyy::/64
• 172.16.mmm.nnn/26 —> 2001:db8:bmmm:nnn::/64

Можно несколько усложнить задачу: поскольку кроме соединения «провайдер-клиент» еще всегда придется маршрутизировать к клиенту подсеть /64 (или /56 по рекомендации RIPE) для клиента, то нужно заранее побеспокоиться о выделении соответствующего диапазона. Ну, например, так: выбираем для первого делегирования «красивые» подсети вида 2001:0db8:64mm:nnnn::/64, где mm и nnnn — любые допустимые в адресе знаки. Всего в нашем распоряжении окажется 6 ниблов, то есть 24 разряда, или два в двадцать четвертой степени подсетей по маске /64. Это будет около 4 миллиардов подсетей.

Если (в среднем) в одной подсети будет обьединены внешние интерфейсы не более чем 256 клиентов или клиентских роутеров, то есть 2**8, то мы сможем поделить этот сегмент на 2**(24-8)=32768 подсетей. Другими словами, выбрав для делегирования клиентам подсети размером /64 и взяв только легкозапоминаемый префикс 2001:db8:6400::/40, мы полностью обеспечим клиентов в 32 тысячах сетей при условии не более 256 клиентов в сети. Или в 1024 сетях, где не более 1024 клиента в каждой. И это при использовании только одного-единственного «красивого» префикса.

А если следовать рекомендациям RIPE и выделять клиентам /56? Получается поменьше, но тоже достаточно много: выбираем для делегирования по маске /56 префикс 2001:db8:56mm:nn00::/56, и получаем 2**16 вариантов, например 256 делегируемых подсетей для сети, где не более 256 клиентов.

Итак, даже при значительных ограничениях («красивый» префикс) цифры все равно получаются очень большие. Адресов много, очень много, можно даже сделать парадоксальный вывод: всех клиентов можно обьединить в подсеть /64, адресов вполне хватит! То есть всем, абсолютно всем клиентам в любой AS можно назначить адреса из одной подсети, скажем 2001:db8::aaaa:/64, и при этом в ней останется много свободных адресов! Конечно же, на часть адресов нужно будет маршрутизировать подсети, скажем /56 или /64, в зависимости от запросов клиентов. Вот здорово! Ставим один роутер, добавляем DHCPv6-сервер для раздачи адресов DNS-серверов и делегирования префиксов, далее при помощи свитчей обьединяем всех клиентов в один VLAN – и все готово!

Разумеется, так можно сделать только в маленькой сети, которая раскинулась по небольшой территории, так как обьединить в один VLAN территориально-разделенные обьекты не всегда возможно. А главное – небезопасно, например при таком «односетевом» подключении первый же аналог arp-атаки создаст проблемы всем подключениям и пользователям.

Скорее всего придется сохранить схему подключения, используемую сейчас у большинства провайдеров: формируются подсети по территориальному признаку (дом, район, квартал) или по сервисному (клиентские серверы, размещаемые в датацентре провайдера), далее формируется схема маршрутизации «один vlan = одна подсеть» для подключения «скромных» клиентов (1 адрес на договор), а таких клиентов большинство, то есть внедрение IPv6 можно проводить без изменения существующей топологии.

Ну, а если у вас есть префикс (или префиксы) с длиной маски менее 16 бит, что тогда? Тогда у вас наверняка есть бригада инженеров-сетевиков, которая легко справится с данной задачей.

Как назначать IPv6-адреса?

В первые дни, а также на серверах и роутерах это можно (точнее — придется) делать вручную. Можно вручную «прописать» нескольких клиентов. Но ведь надоест.. Тут помогут новый SLAAC и старый DHCP.

Механизм SLAAC прекрасно справляется с задачей автоматического назначения адресов, но у него есть ограничения:

• не умеет назначать ip-адреса dns-серверов: требуется назначить их вручную или использовать DHCP-сервер (справедливости ради следует сказать, что разрабатывается процедура использования RA для назначения адресов DNS-серверов)
• не умеет делегировать префиксы – тоже некритично, так как есть динамические протоколы маршрутизации, правда клиенту придется вручную настроить как минимум адрес на внутреннем интерфейсе своего роутера
• роутер должен передавать RA в такую подсеть
• осталась проблема «привязки» трафика к клиенту, ведь по закону эти данные хранятся три года. Вот (ИМХО) это и есть самое сложное…

Такая ситуация нестрашна в небольшой офисной или «гостевой» сети, где не требуется «привязать» трафик к клиенту.

DHCPv6 дает следующие возможности:

• можно назначать клиенту все параметры
• можно «привязать» назначение к клиенту
• можно делегировать префиксы
• (минус) требуется отдельный сервер (или сервис на роутере)
• можно обьединить DHCP-сервер с файерволом, чтобы доступ в интернет получали только клиенты, получившие параметры по DHCP (ISC DHCP)
• можно связать DHCP-сервер с DNS и клиенты будут сразу получать имя, что упрощает обращение к ним (но не нужно автоматически генерировать реверсную запись во избежание спама)

Словом, работы многo.