Планирование IPv6-пространства (2)

Рассмотрим часто встречающуюся схему подключения: N клиентов, у которых внешние интерфейсы маршрутизаторов находятся в одной подсети, и на эти интерфейсы маршрутизируются блоки /56 (в соответствии с рекомендациями RIPE).

Количество клиентов (интерфейсов) в одной подсети вряд ли превзойдет 254, то есть одной подсети /64 на «внешние» интерфейсы хватит. А вот количество бит, необходимых для выбора делегируемых префиксов, необходимо вычислить. Далее исходим из предположения, что границы делегируемых участков формируем строго по границе «ниблов», то есть длину префикса выбираем кратной 4, чтобы повысить наглядность и упростить работу с реверсными зонами.

Количество подсетей для N клиентов, составляет (разумеется) N, а количество бит k определяем исходя из соотношения

2k > N,    (1)

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

Из (1) следует, что минимальное значение опредляется как

k=log2N, или точнее k=int(log2N)+1,   (2)

так как количество бит — величина целочисленная.

Аналогично вычисляется ближайшее число бит, кратное 4, то есть определяется количество ниблов:

k= int((int(log2N)+1)/4)  + 1   (3)

Выражение (3) несложно реализовать даже в Excel, поскольку там есть встроенные функции и для натурального логарифма, и для логарифма по произвольному основанию.

Вот несколько примеров (во второй колонке фактически показано требуемое число ниблов):

NN ниблов бит
6 1 4
15 1 4
17 2 8
63 2 8
255 2 8
257 3 12
4095 3 12
4097 4 16
65535 4 16

Есть естественные ограничения: в вашем распоряжении вовсе не 128 бит, а:

  • вычитаем 64 бита для младших разрядов адреса
  • вычитаем 32 бита в старших разрядах, так как они у вас уже определены (если вы LIR)
  • вычитаем 8 бит, необходимых для формирования /56

… и получаем, что в вашем распоряжении остается всего 24 бита, то есть более 16 миллионов подсетей /56, что совсем не мало.

А можно обойтись и без вычислений, поскольку видно, что:

  • до 16 клиентов — обойдемся 1 ниблом (точнее, с учетом служебной сети, до 15)
  • до 255 клиентов — обойдемся 2 ниблами
  • до 4095 клиентов — обойдемся 3 ниблами
  • до 65535 клиентов — обойдемся 4 ниблами

.. и остается совсем немного бит..

Так, если у вас есть статус LIR, то есть блок /32, и вы делегируете клиентам /56, то в самых «ходовых» подсетях

  • до   255 клиентов — у вас остается 56-32-8=16 бит, то есть более 65,000 подсетей,
  • до 4096  клиентов — у вас остается 56-32-12=12 бит, то есть 4096 подсетей.

Остановимся на «универсальном» варианте с количеством клиентов до 255. При этом у вас остается 16 свободных бит, половину из этого пространства можно использовать как метку сайта (района, региона, площадки и т.д.). Адрес при этом будет иметь вид:

2001:db8:NNNN:xx00::/56,

где 2001:0db8 — ваш префикс

NNNN — код сайта

xx — номер подсети /56 на сайте (до 256 подсетей)

Итак, получается такая раскладка:

2001:db8::           — идентификатор вашей сети (получено от RIPE)

2001:db8:NNNN::  — идентификатор подраздела вашей сети (город, регион, сайт, обьект)

2001:db8:xx00::   — идентификатор подсети /56, делегируемой клиенту

.. и не забываем выделить 2001:db8:x000::/56 для служебных нужд.

Если вы хотите использовать подсети до 4095 клиентов с делегированием /56, то расклад будет такой:

2001:db8:NNNx:yz00::/56,

где xyz — идентификатор подсети /56, маршрутизируемой клиенту

.. и у вас остается всего 12 бит для обозначения сайтов. С другой стороны, 4096 крупных подразделений, в котором до 4095 пользователей — не так уж и мало.

То есть: на идентификацию сайта и на делегирование подсети /56 клиенту остается 56-32=24 бита, которые вы делите на 2 части: на идентификатор сайта и на идентификатор подсети. Если поделить поровну, по 12 бит, то получим по 4096 подсетей и 4096 сайтов, что тоже неплохо. Другое дело, что такое количество клиентов в одной подсети создает серьезные проблемы с обеспечением безопасности (arp-шторм, RA-флуд и проч. ND-подмены).

Вариантов разбиения по границе ниблов не так уж много: 4+20, 8+16, 12+12, 16+8 и 20+4.

subn_v6

Практический пример разбиения LIR-блока на подсети с числом клиентов до 255 и с делегированием /56 каждому клиенту.

Случай 1: внешние интерфейсы клиентского оборудования находятся в общей разделяемой подсети.

Предположим, речь идет об обьекте 007. Тогда:

2001:db8:7::/56 — отводим для служебных целей

2001:db8:7:ff00:/56 — резервируем

2001:db8:7:1:/64 — подсеть для внешних интерфейсов клиентских маршрутизаторов

2001:db8:7:100::/56 — 2001:db8:7:fe00::/56 — подсети для делегирования клиентам

Вообще-то тут получается 254 подсети, но в случае появлени 255го клиента можно использовать зарезервированный блок 2001:db8:7:ff00:/5.

Случай 2: на обьекте снова до 255 клиентов, но используется ррр-соединение или «vlan-per-client». Тогда планируем пространство так:

2001:db8:7::/56 — снова отводим для служебных целей

2001:db8:7:ffxx::/64 — подсеть для ррр-соединений, где хх — номер клиента (или тэг vlan)

2001:db8:7:100::/56 — 2001:db8:7:fe00::/56 — подсети для делегирования клиентам

Случай 3: у провайдера 5 обьектов, на каждом до 5000 клиентов. Очевидно, на маркировку обьекта хватит 1 нибла, а 5000 клиентов разбиваем на сегменты по 256. Итого, 20 сегментов, на их нумерацию нужно 5 бит, округляем до 8 (ближайшее превосходящее число, кратное 4). Вывод: на служебные цели нужно 1+2=3 нибла (12 бит).

Получаем структуру:
2001:db8:00NM:MM00:: где N — код обьекта, а MMM — код сегмента. Остальное — по аналогиии со случаем 1 или 2.

Все просто..

Итак, в большинстве случаев для LIR категории small подойдет такая структура адреса:

2001:db8:pqrs:mnxx::
где pqrs (16 бит) — код или номер крупного формата (филиал, город, район), причем можно смело писать p=0 q=0 и резервировать 8 бит на будущее
mn — маршрутизируемая клиенту подсеть /56 (разумеется, при этом хх=»00″)
и остается только зарезервировать первый и последний сегменты для своих целей.

То есть (для ясности использована полная форма записи адреса):
от 2001:0db8:0000:0000::/64 и до 2001:0db8:00ff:ffff::/64 — служебный сегмент
от 2001:0db8:ff00:0000::/64 и до 2001:0db8:ffff:ffff::/64 — служебный сегмент (или резерв)
от 2001:0db8:0100:0000::/64 и до 2001:0db8:01ff:ffff::/64 — первый крупный обьект (сайт, город, огромный офисный центр)
2001:0db8:01[0-f][0-f]:[0-f][0-f][0-f][0-f]:: — подсети на обьекте (в том числе и /56 для клиентов)

Подробнее: обьект 01 и его подсети:
2001:0db8:01xy:mn00::/64 — общий вид адресов на первом обьекте
2001:0db8:0100:0000::/56 (или 2001:db8:100::/56) — служебный сегмент адресов

Первая подсеть:
от 2001:0db8:0101:0000::/56 (или 2001:db8:101::/56) — подсети для маршрутизации клиентам
до 2001:0db8:0101:fe00::/56

2001:0db8:0101:ff00::/56 (или 2001:db8:100::/56) — служебный сегмент адресов, или резерв

Тот же обьект 01, вторая подсеть (тоже до 254 клиентов)

это — диапазон от 2001:db8:102::/64 до 2001:db8:102:ffff::/64

где lanuser.ru — мелкий воришка

2001:db8:102::/56  — служебный сегмент
2001:db8:102:ff00::/56  — служебный сегмент (или резерв)

2001:db8:102:100:/56  — служебный сегмент
2001:db8:102:fe00::/56  — служебный сегмент (или резерв)


  *** Via IPv4 ***  

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.