я уже рассказывал, что IPv6 это удобно. однако я отмечал, что стандарт IPv6 требует минимальной сети IPv6 /64 это 1.8*10^19 адресов. этого должно быть достаточно для абонентских устройств провайдера любого размера, но если вы сделаете префикс для сети больше, то работа сети нарушится. так делать нельзя.
в предлагаемом решении ранее (роутер на палке) физически один роутер и что-то с ним сделать сложно, хотя и возможно, если он, например, поддерживает VRFs или аналогичную логическую изоляцию, где у каждого интерфейса/сабинтерфейса свой изолированный L2-домен, но будем использовать более простое и интуитивно понятное решение с физически разными маршрутизаторами.
изобретаем велосипед
суть хака
двойная маска мы анонсируем по BGP префикс /64 (напр., 2001:db8:1:1::/64), но внутри нашей сети логически разбиваем его на сегменты по /80
ещё стоит отметить, что принципе нельзя анонсировать по BGP префикс больше чем /64, но в таблице маршрутизатора может быть запись /80. т.е. на основном маршрутизаторе прописываются статические маршруты (или они динамически распространяются внутри AS) для каждого /80.
более подробно: вы анонсируете по BGP 2001:db8:1:1::/64. но для себя разбиваем дальше:
- cегмент A: 2001:db8:1:1:0001::/80
- cегмент B: 2001:db8:1:1:0002::/80
- cегмент C: 2001:db8:1:1:0003::/80
- ... и так далее.
обращаю внимание что хоть формально хоть мы и разбили сеть на /80 физически это /64. это возможно потому что это изолированные l2 сегменты — настоящий префикс который мы анонсируем один — 2001:db8:1:1:0001::/64. но подразумеваем префиксы 2001:db8:1:1:0001::/80. на сегмент мы отвели 16 бит т.е. 65536 сегментов — хватит надолго.
на обозначение клиента выделяем еще 16 бит т.е /96 что составляет 65535 клиентов на сегмент. маршрутизаторы находятся в отдельном префиксе. номер сегмента у них такой же как у клиентов только для простоты маршрутизатор будет в этом сегменте иметь адрес 1 (между номером сегмента и последней единицей в адресе нули).
адреса роутеров сегментов:
- cегмент A: 2001:db8:1:1:0001::1
- cегмент B: 2001:db8:1:1:0002::2
- cегмент C: 2001:db8:1:1:0003::3
- ... и так далее
префиксы абонентов:
- сег. A: 2001:db8:1:1:0001::/80 абонент 1 2001:db8:1:1:0001:0001::/96
- сег. A: 2001:db8:1:1:0001::/80 абонент 2 2001:db8:1:1:0001:0002::/96
- ... и так далее
- сег. B: 2001:db8:1:1:0002::/80 абонент 255 2001:db8:1:1:0002:00ff::/96
- сег. B: 2001:db8:1:1:0002::/80 абонент 5 2001:db8:1:1:0002:0005::/96
- ... и так далее
т.е. клиентским устройствам предоставляется 2^(128-96)~ 4,3 *10^9 адресов. вообще говоря мы до конца даже не сломали SLAAC ему нужно просто генерировать адрес из префикса /96, но это повлечёт за собой хоть и небольшие, но все таки изменения в стандарте. для устройства клиента адрес будет иметь вид:
адреса устройств абонентов:
- сег. A абонент 1 устройство 1: 2001:db8:1:1:0001:0001::1
- сег. A абонент 2 устройство 1: 2001:db8:1:1:0001:0002::1
- ...
- сег. B абонент 1 устройство 1: 2001:db8:1:1:0002:0001::1
- сег. B абонент 6 устройство 3: 2001:db8:1:1:0002:0006::3
- . . .
- сег.C абонент 42991 устройство 7: 2001:db8:1:1:0003:a7ef::7
но придётся полностью положиться на Stateful DHCPv6. даже скажем более конкретно: в RA должен быть установлен флаг M-flag =1 тогда работа сети будет полностью зависеть от DHCP сервера и DHCPv6 Relay Option 18 (Interface-ID) и Option 37 (Remote-ID). на основании этих опций DHCP сервер должен назначить клиенту нужный адрес.
основной роутер будет оперировать префиксами /80 — адресами сегментов который физически будут существовать только в таблице основного маршрутизатора.
ну что же вот мы описали наш хак который конечно же имеет ограничения:
- отказ от SLAAC: вы навсегда привязаны к stateful DHCPv6. любое устройство, которое хочет "просто подключиться" автоматически, скорее всего не сможет этого сделать т.к. будет использоваться префикс /64, который он видит в RA. генерируемый адрес из всего диапазона 2001:db8:1:1::/64 почти наверняка попадёт в чужой /80.
- как уже говорилось это будет работать только с физически разными роутерами. соответственно требуется больше сравнительно дорогого оборудования.
- в сети крупного оператора связи могут возникнуть сложности т.к. придётся как минимум распространять маршруты до префиксов /80 внутри AS.
- Neighbor Solicitation (аналог ARP-запроса). запрос не уйдёт за пределы сегмента, т. к. они изолированы физически. т.е связь между узлами разных сегментов не может быть установлена напрямую, что противоречит логике подсети.
- отход от стандартов сам по себе не сулит ничего хорошего.
вывод такой: это может быть эффективно использовано только в сети небольшого оператора связи, но при этом требования противоречивы: оператор небольшой, а оборудования надо больше, да и настройка более запутанная.
меняем стандарты.
суть предложения:
- BRAS делегирует абоненту не целый /64, а виртуальный /96 в рамках общего /64
- абонентский роутер использует этот /96 для SLAAC внутри своей сети
- на BRAS есть маршруты до каждого конкретного /96.
рассмотрим подробно. представим себе ситуацию абонент подключён через роутер. я буду использовать это слово «роутер» чтоб обозначить маленькое абонентское устройство. обычно роутер использует тот или иной тип PPP соединения, обычно используется PPPoE.
что происходит дальше. клиенту PPP предоставляют один единственный адрес. роутер организует свою LAN используя немаршрутизируемые глобально адреса, например 192.168.1/24. сам роутер становится маршрутизатором по умолчанию для этой LAN например имет адрес 192.168.1.1/24.
абонентские устройства настраиваются через DHCP и получают адреса из префикса 192.168.1/24. например адрес устройства имет вид: 192.168.1.71/24. пусть такое устройство получает адреса DNS серверов которые получает PPP клиент и обязательно маршрут по умолчанию 192.168.1.1/24. все клиентские устройства транслируются при помощи NAT в один единственный IP который получает PPP клиент.
как известно NAT в обычном понимании этого слова в IPv6 нет. есть специальные случаи. я описывал NAT64. но придумаем ему замену классическому NAT.
путь у нас 2001:db8:1:1:0001::/80 обозначает не сегмент, а номер BRAS. тогда его клиент обозначается 2001:db8:1:1:0001:0001::/96 как в примере с l2 сегментами.
пусть роутер используют свою LAN из префикса /64. но выделяет он по SLAAC адреса из /96. те клиентские устройство имет адрес например 2001:db8:1:1:0001:0001::а1b2.
вроде бы все хорошо. в по определению отдельному абонентском l2 сегменте устройства абонента могут устанавливать между собой. они могут устанавливать соединения с устройствами других абонентов т.к. на BRAS существуют маршруты до каждого клиентского префикса /96 кроме того
должны существовать маршруты до конкретного BRAS /80 в таблице маршрутизаторов вышестоящих роутеров. ну и на конец мы анонсируем
префикс /64 на основном маршрутизаторе.
ограничения: BRAS должен работать с физически разными l2 сегментами к которым подключены абоненты, чтобы могли существовать маршруты /80. это может создавать неудобства конфигурации и обслуживания.
немного скучный, но хорошо работающий вариант
если вы хотите чтобы все работало хорошо назначайте уж как положено /64 на изолированный l2 сегмент, как было описано. вам и проблем с этим решением хватит — основная, что не все устройства могут хорошо работать с DHCP, а могут требовать чистого SLAAC. в прочем таких устройств становится все меньше и меньше.
сам SLAAC тоже не поломан. отказ от него сознательное решение в пользу учёта абонентов. посадив все устройства нескольких тысяч абонентов в один l2 вы уже экономите адреса и обеспечили себе пищу для размышлений по крайней мере на этапе проектирования сети. делать что-то сверх того неразумно.
вывод? а он банален Keep It Simple, Stupid.
текст создан при экспертной поддержке DeepSeek