Статей по пониманию IPv6 написано предостаточно для всех категорий: от пользователей до провайдеров и если пользователю с «правильным» dual-stack провайдером нужно просто включить устройство, поддерживающее IPv6, то что делать провайдеру с его IPv6-блоком не ясно. Попробуем в этом разобраться. Статья подразумевает что читатель умеет считать маски IPv6, большего не требуется.
Если же даже со счетом проблемы, то картинка должна немного помочь
Итак, типично выделяемый блок IPv6 — /32. Это 79228162514264337593543950336 уникальных IP-адресов, которых «должно хватить каждому». Казалось бы с таким количеством даже среднему ISP можно особо не заботится о исчерпаемости адресного пространства, но сетевые инженеры знают что проблема правильного адресного планирования не только в экономии адресов, но в и том, что оно влияет на производительность оборудования и, как следствие, на работоспособность всей сети.
Существуют некоторые рекомендации, которые дают региональные регистраторы и RFC6177:
Очевидно что при таком подходе смысл VLAN per user, VLAN per access-switch либо vlan per building с поправкой на разные типы клиентов не совсем разумны и противоречат рекомендациям RIPE. На мой взгляд достаточно будет 2-4 VLAN на сайт: корпоративные клиенты, физические лица и, возможно, телефония и ТВ, если есть необходимость разносить их (н-р для ACL, netflow и т.д.) где на уровне доступа сделать соответствующие привязки, н-р DHCPv6 opt37
Визуализация:
Возьмем сферического ISP, присутствующего в пяти городах, в каждом из которых есть/планируется 100 сайтов, на каждом будут корпоративные клиенты, физ. лица и SIP с IPTV. Провайдер у нас правильный, корпоративным клиентам предлагает самые разнообразные тарифы (безлимиты и по трафику), физикам, как мне кажется, уже никто по трафику не предоставляет, а также на своем SIP-сервере/SoftSwitch разрешает доступ лишь с определенных подсетей, в которых находятся голосовые шлюзы (абонент телефонию получает в виде FXS-порта). И вот получает 2001:DB8::/32 (адрес, рекомендованный для документации, RFC3849). Дальше простая математика уровня 5 класса: в каждый город нам нужно по /38 сети, но более «красиво» будет разбить на /36 сеть на город, сетей при такой разбивке хватит еще на 11 городов. Назовем это первым уровнем адресного пространства.
Дальше распределяем адреса в городе. Второй уровень. Пусть это будет Самара с её 2001:db8:2::/48. Вспоминаем что на сайт должна приходиться /64. Сразу оговорюсь что промежуточный этап суммирования блоков нескольких агрегаций в какие-то промежуточные между /64 и /48 я опускаю, т.к. считаю что это типовой схемой не описать, зависит от физического и логического посторения сети (н-р все /64-сети одной ospf area можете объединить в один более короткий префикс). Т.о. мы получаем не более 5 VLAN на аггрегации (+managment), не считая VPN, экономия ресурсов устройств, простоту настройки STP, QoS и т.д., а также коммутаторов доступа (конфиг будет отличаться лишь управляющим IP). Корпоративные клиенты, желающие н-р /56 также удачно вписываются в эту картину.
В некоторых случаях, возможно, будет смысл преобразования типовой трехуровневой модели построения сети (ядро-агрегация-доступ) в ядро-доступ, поставив на уровень агрегации что-то L2-уровня для удешевления сети.
Статья получилась не большая, примеры конфигураций IPv6 приводить не стал, т.к. это выходит за рамки статьи, если будет желание читателей — типовые вещи на основании этой статьи могу расписать. Я постарался собрать все рекомендации по IPv6 и расписать их человеческим языком. Всячески приветствуются правки, комментарии, пожелания и дополнения!
Если же даже со счетом проблемы, то картинка должна немного помочь
Итак, типично выделяемый блок IPv6 — /32. Это 79228162514264337593543950336 уникальных IP-адресов, которых «должно хватить каждому». Казалось бы с таким количеством даже среднему ISP можно особо не заботится о исчерпаемости адресного пространства, но сетевые инженеры знают что проблема правильного адресного планирования не только в экономии адресов, но в и том, что оно влияет на производительность оборудования и, как следствие, на работоспособность всей сети.
Существуют некоторые рекомендации, которые дают региональные регистраторы и RFC6177:
- На ISP выделяется /32 блок
- Каждый узел, где агрегируются адреса должен получать /48 сеть (65536 сетей /64 размера)
- Не должно быть подсетей длинее /64, что значит что на каждый VLAN выделяется подсеть /64 (18446744073709551616 IP-адресов)
- Все loopback-и должны быть в одной /64 подсети, маска интерфейса — /128
Очевидно что при таком подходе смысл VLAN per user, VLAN per access-switch либо vlan per building с поправкой на разные типы клиентов не совсем разумны и противоречат рекомендациям RIPE. На мой взгляд достаточно будет 2-4 VLAN на сайт: корпоративные клиенты, физические лица и, возможно, телефония и ТВ, если есть необходимость разносить их (н-р для ACL, netflow и т.д.) где на уровне доступа сделать соответствующие привязки, н-р DHCPv6 opt37
Визуализация:
Возьмем сферического ISP, присутствующего в пяти городах, в каждом из которых есть/планируется 100 сайтов, на каждом будут корпоративные клиенты, физ. лица и SIP с IPTV. Провайдер у нас правильный, корпоративным клиентам предлагает самые разнообразные тарифы (безлимиты и по трафику), физикам, как мне кажется, уже никто по трафику не предоставляет, а также на своем SIP-сервере/SoftSwitch разрешает доступ лишь с определенных подсетей, в которых находятся голосовые шлюзы (абонент телефонию получает в виде FXS-порта). И вот получает 2001:DB8::/32 (адрес, рекомендованный для документации, RFC3849). Дальше простая математика уровня 5 класса: в каждый город нам нужно по /38 сети, но более «красиво» будет разбить на /36 сеть на город, сетей при такой разбивке хватит еще на 11 городов. Назовем это первым уровнем адресного пространства.
Получили мы 16 следующих сетей
| 2001:db8::/48 | Москва |
| 2001:db8:1::/48 | Санкт-Петербург |
| 2001:db8:2::/48 | Самара |
| 2001:db8:3::/48 | Тамбов |
| 2001:db8:4::/48 | Владивосток |
| 2001:db8:5::/48 | Резерв |
| 2001:db8:6::/48 | Резерв |
| 2001:db8:7::/48 | Резерв |
| 2001:db8:8::/48 | Резерв |
| 2001:db8:9::/48 | Резерв |
| 2001:db8:a::/48 | Резерв |
| 2001:db8:b::/48 | Резерв |
| 2001:db8:c::/48 | Резерв |
| 2001:db8:d::/48 | Резерв |
| 2001:db8:e::/48 | Резерв |
| 2001:db8:f::/48 | Резерв |
Дальше распределяем адреса в городе. Второй уровень. Пусть это будет Самара с её 2001:db8:2::/48. Вспоминаем что на сайт должна приходиться /64. Сразу оговорюсь что промежуточный этап суммирования блоков нескольких агрегаций в какие-то промежуточные между /64 и /48 я опускаю, т.к. считаю что это типовой схемой не описать, зависит от физического и логического посторения сети (н-р все /64-сети одной ospf area можете объединить в один более короткий префикс). Т.о. мы получаем не более 5 VLAN на аггрегации (+managment), не считая VPN, экономия ресурсов устройств, простоту настройки STP, QoS и т.д., а также коммутаторов доступа (конфиг будет отличаться лишь управляющим IP). Корпоративные клиенты, желающие н-р /56 также удачно вписываются в эту картину.
В некоторых случаях, возможно, будет смысл преобразования типовой трехуровневой модели построения сети (ядро-агрегация-доступ) в ядро-доступ, поставив на уровень агрегации что-то L2-уровня для удешевления сети.
Статья получилась не большая, примеры конфигураций IPv6 приводить не стал, т.к. это выходит за рамки статьи, если будет желание читателей — типовые вещи на основании этой статьи могу расписать. Я постарался собрать все рекомендации по IPv6 и расписать их человеческим языком. Всячески приветствуются правки, комментарии, пожелания и дополнения!