DHCPv6 Rapid Commit
Configuring DHCPv6 Rapid Commit (MX Series, EX Series)
You can configure the DHCPv6 local server to support the DHCPv6 Rapid Commit option (DHCPv6 option 14). When rapid commit is enabled, the server recognizes the Rapid Commit option in Solicit messages sent from the DHCPv6 client. (DHCPv6 clients are configured separately to include the DHCPv6 Rapid Commit option in the Solicit messages.) The server and client then use a two-message exchange (Solicit and Reply) to configure clients, rather than the default four-message exchange (Solicit, Advertise, Request, and Reply). The two-message exchange provides faster client configuration, and is beneficial in environments in which networks are under a heavy load.
You can configure the DHCPv6 local server to support the Rapid Commit option globally, for a specific group, or for a specific interface. By default, rapid commit support is disabled on the DHCPv6 local server.
To configure the DHCPv6 local server to support the DHCPv6 Rapid Commit option:
- Specify that you want to configure the overrides options:
[edit system services dhcp-local-server dhcpv6] user@host# edit overrides
See Also
Configuring the DHCPv6 Client Rapid Commit Option
The DHCPv6 client can obtain configuration parameters from a DHCPv6 server through a rapid two-message exchange (solicit and reply). When the rapid commit option is enabled by both the DHCPv6 client and the DHCPv6 server, the two-message exchange is used, rather than the default four-method exchange (solicit, advertise, request, and reply). The two-message exchange provides faster client configuration and is beneficial in environments in which networks are under a heavy load.
To configure the DHCPv6 client to support the DHCPv6 rapid commit option on SRX300, SRX320, SRX340, SRX550M, and SRX1500 devices:
- Specify the DHCPv6 client interface.
[edit] user@host# set interfaces ge-0/0/0 unit 0 family inet6 dhcpv6-client
[edit interfaces ge-0/0/0 unit 0 family inet6 dhcpv6-client] user@host# set rapid-commit
DHCPv6 Rapid Commit
Konfigurieren von DHCPv6 Rapid Commit (MX-Serie, EX-Serie)
Sie können den lokalen DHCPv6-Server so konfigurieren, dass er die DHCPv6 Rapid Commit-Option (DHCPv6-Option 14) unterstützt. Wenn Rapid Commit aktiviert ist, erkennt der Server die Rapid Commit-Option in Solicit-Nachrichten, die vom DHCPv6-Client gesendet werden. (DHCPv6-Clients werden separat konfiguriert, um die DHCPv6 Rapid Commit-Option in den Solicit-Nachrichten einzuschließen.) Server und Client verwenden dann einen Austausch mit zwei Nachrichten (Solicit and Reply), um Clients zu konfigurieren, anstatt den Standardaustausch mit vier Nachrichten (Solicit, Advertise, Request, and Reply). Der Austausch von Zwei-Nachrichten ermöglicht eine schnellere Client-Konfiguration und ist in Umgebungen von Vorteil, in denen Netzwerke stark belastet sind.
Sie können den lokalen DHCPv6-Server so konfigurieren, dass er die Rapid Commit-Option global, für eine bestimmte Gruppe oder für eine bestimmte Schnittstelle unterstützt. Standardmäßig ist die schnelle Commit-Unterstützung auf dem lokalen DHCPv6-Server deaktiviert.
So konfigurieren Sie den lokalen DHCPv6-Server zur Unterstützung der DHCPv6 Rapid Commit-Option:
- Geben Sie an, dass Sie die overrides Optionen konfigurieren möchten:
[edit system services dhcp-local-server dhcpv6] user@host# edit overrides
Siehe auch
Konfigurieren der DHCPv6 Client Rapid Commit-Option
Der DHCPv6-Client kann Konfigurationsparameter von einem DHCPv6-Server über einen schnellen Austausch von zwei Nachrichten (Solicit and Reply) abrufen. Wenn die Schnelle Commit-Option sowohl vom DHCPv6-Client als auch vom DHCPv6-Server aktiviert wird, wird der Austausch mit zwei Nachrichten anstelle des Standardmäßigen Austauschs mit vier Methoden (Solicit, Advertise, Request, And Reply) verwendet. Der Austausch von Zwei-Nachrichten bietet eine schnellere Client-Konfiguration und ist in Umgebungen von Vorteil, in denen Netzwerke unter hoher Last stehen.
Zur Konfiguration des DHCPv6-Clients zur Unterstützung der DHCPv6 Rapid Commit-Option auf SRX300-, SRX320-, SRX340-, SRX550M- und SRX1500-Geräten:
- Geben Sie die DHCPv6-Clientschnittstelle an.
[edit] user@host# set interfaces ge-0/0/0 unit 0 family inet6 dhcpv6-client
[edit interfaces ge-0/0/0 unit 0 family inet6 dhcpv6-client] user@host# set rapid-commit
распределение адресов ipv6 в сети
Провайдер динамически выдает префикс ipv6 /64 (~18 квадриллионов адресов). Возник вопрос, как эти адреса распределять без SLAAC? т.е. надо как то передать динамически получаемый префикс на другие DHCP сервера и при этом как то поделить диапазоны ip между ними.
Как это делается?
torm7 ★
13.12.21 14:03:32 MSK
Провайдер динамически выдает префикс ipv6 /64
Это плохо — у меня также. По идее должен /48, с расчетом /64 на железку.
Turbid ★★★★★
( 13.12.21 14:24:03 MSK )
Но выше правильно написали, что провайдер должен был тебе /56 или /48 выделить т.к. slaac работает только с /64 префиксами.
Kolins ★★★
( 13.12.21 14:28:28 MSK )
Последнее исправление: Kolins 13.12.21 14:28:45 MSK (всего исправлений: 1)
Ответ на: комментарий от Turbid 13.12.21 14:24:03 MSK
Нафига столько адресов.
/96 должно хватать на всё с огромным запасом а вы /64 недоволны.
firkax ★★★★★
( 13.12.21 14:33:16 MSK )
Ответ на: комментарий от Kolins 13.12.21 14:28:28 MSK
Я так понимаю что это делегация сетей от /64 и больше. Меня же интересует дальнейшее дробление этой сети для распределения этих адресов.
torm7 ★
( 13.12.21 14:51:35 MSK ) автор топика
Ответ на: комментарий от torm7 13.12.21 14:51:35 MSK
Я так понимаю что это делегация сетей от /64 и больше.
нет. можно и /64 бить на более мелкие подсети. Конкретно у микротов в ipv6->pool указываешь исходный префикс и размер префиксов на которые ты будешь его бить.
Kolins ★★★
( 13.12.21 15:04:20 MSK )
Ответ на: комментарий от firkax 13.12.21 14:33:16 MSK
Хочешь поспорить со стандартом?
intelfx ★★★★★
( 13.12.21 15:40:18 MSK )
Ответ на: комментарий от Kolins 13.12.21 15:04:20 MSK
На это есть какая то инструкция? Что то беглый поиск ничего не дал.
torm7 ★
( 13.12.21 15:56:04 MSK ) автор топика
Ответ на: комментарий от torm7 13.12.21 15:56:04 MSK
Kolins ★★★
( 13.12.21 16:01:37 MSK )
Ответ на: комментарий от intelfx 13.12.21 15:40:18 MSK
Эм. Я бы ещё подумал если бы речь шла про действительно значимый и действительно стандарт. А тут сомнительные рекомендации по ведению бизнеса, впихнутые в технический документ, который и без этого был сомнительного качества. Нарезание сетей внутри автономной системы — это сфера исключительно коммерческих отношений между провайдером и его клиентами, а никак не стандарта.
Лично мне осознание того, что можно было сэкономить ненужные 8 байт заголовков из моих локальных адресов, коих мне выделили целых 128-48=80 бит=10 байт, оставив только 2 байта, которых заведомо на всё хватит, но нельзя из-за дури каких-то странных людей из 90-х, сочинивших этот «стандарт», вело бы только к негативу.
Впрочем, если ipv6 таки окажется массово принят, и всем действительно будут выдавать /48, то скорее всего эти лишние бесполезные 16 байт в ipv6 пакете (8 байт от адреса источника и 8 байт от адреса назначения) скорее всего научатся использовать под что-то более полезное (слать через них какие-нить другие метаданные, куки, мониторинг итд).
firkax ★★★★★
( 13.12.21 16:02:50 MSK )
Последнее исправление: firkax 13.12.21 16:11:25 MSK (всего исправлений: 2)
Ответ на: комментарий от firkax 13.12.21 16:02:50 MSK
А кто будет решать, что есть «действительно значимый и действительно стандарт»? Ты?
intelfx ★★★★★
( 13.12.21 16:45:32 MSK )
Ответ на: комментарий от intelfx 13.12.21 16:45:32 MSK
Не надо демагогии, все давно понимают что ipv6 это провал. То, что он вообще используется — происходит лишь потому, что конца ipv4-адресов действительно некоторые боятся, а альтернатив расширить адресное пространство нет.
А уж прописывать в стандарт, какими блоками провайдер должен раздавать адреса своим физлицам-клиентам — вообще дичь.
firkax ★★★★★
( 13.12.21 17:17:17 MSK )
Ответ на: комментарий от firkax 13.12.21 17:17:17 MSK
Вот именно — не надо демагогии.
intelfx ★★★★★
( 13.12.21 18:13:41 MSK )
Ответ на: комментарий от intelfx 13.12.21 18:13:41 MSK
Чем мне нравится лор — тяга людей к «поболтать под пивасик, желательно ни о чем» 🙂
ipv6 работает, работает замечательно, протокол заметно проще, чем ipv4 (одно отсутствие броадкаста чего стоит).
Что касается стандартов, то они определяют технологию, а не бизнес-процесс, и обычный DHCP вовсе не является обязательным для применения в провайдинге.
ipv6 предусматривает разные технологические варинаты раздачи, а провайдер сам вбирает из своих соображений — пользоваться ли ему преимуществом ipv6, или гонять его в режиме ipv4.
Oleg_Iu ★
( 13.12.21 20:03:54 MSK )
имхо
удаляй роутер подключай тупо свитч
всякие winxp подключай через роутер к свитчу
файсбук так и делает инфа100
nanosecond ★
( 13.12.21 22:28:16 MSK )
Последнее исправление: nanosecond 13.12.21 22:31:23 MSK (всего исправлений: 2)
Ответ на: комментарий от Turbid 13.12.21 14:24:03 MSK
/56 по полиси. /48 это уже чтобы роутиться можно было.
Dark_SavanT ★★★★★
( 13.12.21 22:43:50 MSK )
IPv6 — классовая система адресации. Существует несколько классов (которые политкорректно называются форматами) IPv6 адресов.
Нас в данном случае интересует unicast/anycast формат: 64 бита — префикс сети (номер сети в терминологии IPv4), 64 — бита идентификатор интерфейса (номер хоста в терминологии IPv4).
Предполагалось, что префикс сети будет состоять из 48 бит (глобального) префикса маршрутизации и 16-ти бит идентификатора подсети.
Прошу заметить, существует известная путаница между подсетями IPv4 и CIDR. Это — две разных спецификации: подсети были определены в рамках классовой маршрутизации IPv4, CIDR — как раз и есть бесклассовая маршрутизация. Отсюда, разница в нотациях (кстати, маску подсети можно/нужно было задавать а-ля 0.0.255.0).
Соответственно, предполагалось что глобальная маршрутизация IPv6 будет осуществляться максимум по 48 битам. Что существенно облегчало построение таблиц маршрутизации. Но реальность распорядилась иначе.
Никому даже и в голову не пришло бы использовать CIDR для IPv6 ввиду бессмысленности и ввиду того что CIDR проектировался как временный механизм (ага, как обычно, чо). Поэтому, подсети IPv6 следует понимать в оригинальной трактовке.
Оператор связи может выдавать /64 на абонента. Никаких проблем это не принесёт. Но, в этом случае абонент лишается возможности настраивать несколько глобально маршрутизируемых подсетей на своей территории. В современных реалиях это очень полезно.
Проблема IPv6 не в его форме адреса, а в том что IPv6 предлагает возврат к классической модели маршрутизации на уровне оператора связи. Ни один оператор связи никогда не применял классическую маршрутизацию в своих «хомячных» сетях доступа.
С внедрениями покрупнее, есть сомнения (и вполне обоснованные) в адекватности механизмов автоконфигурации IPv6.
anonymous
( 14.12.21 00:47:21 MSK )
Что то я не понимаю хода ваших мыслей. Вопрос был вполне конкретный, как в сети распределять ~18 квадриллионов адресов, которые выделили. Одна l2 сеть с одним DHCP, это как то ну совсем… Такое количество адресов как бы подразумевает деление сети на l3 уровне. При таком количестве узлов не принципиально что выделят /64, /56, /48, /96. Это всё очень много и всё равно надо как-то делить. Просто я этим никогда не занимался, за ненадобностью, а сейчас встал вопрос, т.к. виртуализация/контейнеризация/SDN стали доступны для простых смертных, а тут ещё и ipv6 завезли, так что стало возможно взаимодействовать со всем этим из вне…
torm7 ★
( 14.12.21 10:12:27 MSK ) автор топика
Ответ на: комментарий от torm7 14.12.21 10:12:27 MSK
Такое количество адресов как бы подразумевает деление сети на l3 уровне
По мнению авторов ipv6 не подразумевает. Типа держи /64 на хост и хоть на каждый процесс по ip генерируй.
Хочешь делить — да без проблем, можешь руками, можешь по dhcpv6-pd раздавать, но slaac в префиксах больше /64 работать не будет: настраивай статикой или запускай обычный dhcpv6 в каждом сегменте (хотя и там без ra не обойдешься т.к. def. route по dhcpv6 больше не раздается).
Kolins ★★★
( 14.12.21 10:45:12 MSK )
Ответ на: комментарий от anonymous 14.12.21 00:47:21 MSK
Но, в этом случае абонент лишается возможности настраивать несколько глобально маршрутизируемых подсетей на своей территории. В современных реалиях это очень полезно.
Это как это? Глобальная маршрутизация делается между провайдерами. Провайдер внутри себя (если большой) может делать ещё какую-то, но в целом не нагруженную таблицами. Ну а пользователь — тебе выдали аплинк, всё что снизу твоё, маршрутизируй сколько хочешь, в чём проблема? Глобально ты всё равно виден как 1 порт в свитче у провайдера.
firkax ★★★★★
( 14.12.21 10:54:29 MSK )
Ответ на: комментарий от torm7 14.12.21 10:12:27 MSK
сколь помню задумка множества адресов была для того чтобы твою локальную сеть осмотреть было трудно, коль она все равно голым задом в тырнет светит.
так что адреса выдавать рандомно.
pfg ★★★★★
( 14.12.21 11:05:45 MSK )
Ответ на: комментарий от Kolins 14.12.21 10:45:12 MSK
Меня SLAAC не интересует, это для «домохозяек», которым воткнул и работает. Мне нужно немного больше чем просто «работает».
За ссылки спасибо, я микротик вроде настроил, поделил /64 на /66 сегменты. Когда руки дойдут, попробую в виртуальную сеть передать этот кусок.
torm7 ★
( 14.12.21 11:30:51 MSK ) автор топика
Ответ на: комментарий от torm7 14.12.21 11:30:51 MSK
Меня SLAAC не интересует, это для «домохозяек», которым воткнул и работает.
Вопрос не в домохозяйках. SLAAC позволяет скрывать мониторинг клиента разными интернет-сервисами при помощи расширения безопасности. Это САМЫЙ важный «побочный» эффект протокола. А в целом, SLAAC сильно упрощает настройку стека ipv6.
Далее, в отличие от ipv4, в шестой версии у каждой ноды, подключенной к сети, по сути, своя роль. Условно можно выделить, как минимум, три вида нод — хост, роутер и сервер. И с ними можно (и нужно) работать по разному.
Хост — обычный ip-чайник/телевизор, которому нужен просто доступ к интернету. Тут slaac просто прописан по хрестоматии.
Роутер — тут понятно, что это нода, через которую осуществляется доступ к сетям. Тут, понятно, dhcpv6-pd, если это подчиненные сети. Ну и есть еще разные уловки, что бы реализовать настройку роутинга через тот же RA протокол. Но так делают очень редко.
Сервер — нода, к которой требуется аргументированный доступ из интернета. Например, сайт. Тут чаще всего используется статически настроенные ip, и не морочат себе голову.
У современных провайдеров в настройках/тарифах клиент сам выбирает уровень услуги — т.е. я, как клиент, заказываю делегирование /64 или /48 (или /56). Если мне оно надо. Но все это, как мы понимаем, квартирный интернет. Для профессиональной деятельности все делается немного не так.
Ну и последнее — как делить префикс… Как сказали выше — да как угодно. Как хочется, так и надо делить. И надо помнить, что префикс, это НЕ броадкаст. Если вы повесили префикс на интерфейс, то никто не запрещает вам кусок этого префикса (например /96 из /64) зароутить вообще в другую часть сети.
В общем, ipv6 — это еще то чудо. 🙂
Oleg_Iu ★
( 14.12.21 18:00:45 MSK )
Ответ на: комментарий от torm7 14.12.21 10:12:27 MSK
Для начала — выкинуть тупую пропаганду про «стотыщщпиццот сикстилионов» из головы.
Уникаст IPv6-адрес — пара 64-битных чисел: . Идентификатор, прошу заметить, а не «номер» или «адрес».
То что пространство идентификаторов интерфейса 64-бита, не значит что их должно быть/будет 2^64.
Избыточность пространства идентификаторов интерфейса позволяет решить задачу перенумерации хостов в случае смены провайдера: она не требуется. Большое количество подсетей позволяет без проблем настраивать адресное пространство на разных площадках, с возможностью маршрутизации между ними.
Ещё раз. В IPv6 — классовая маршрутизация. Поэтому, маршрутизация по префиксам > /64 невозможна, даже если в какой-то реализации она «работает».
Соответственно, распределить пространство идентификаторов интерфейсов можно единственным способом: выдавать из него 64-битные идентификаторы.
Делается это через механизм автоконфигурации.
- Хост рассчитывает 64-битный идентификатор интерфейса.
- Хост проверяет, что идентификатор не занят.
- Хост формирует локальный адерс: .
- Хост использует механизм ND (neighbor discovery) либо для дальнейшей поиска маршрутизатора и дальнейшей автоконфигурации, либо для поиска DHCPv6 сервера.
Поэтому, в простых ситуациях достаточно включить поддержку IPv6 в совместимом маршрутизаторе, а дальше «оно само».
anonymous
( 14.12.21 22:08:15 MSK )
Ответ на: комментарий от firkax 14.12.21 10:54:29 MSK
Это как это? Глобальная маршрутизация делается между провайдерами.
Возьмём из головы пример. В наличии: домашняя беспроводная, домашняя проводная, домашняя беспроводная гостевая, DMZ для торрентокачалки.
Если бы провайдер не жлобился бы и выдавал несколько подсетей, задача сегментирования значительно бы упростилась: для каждой подсети отдельный механизм (авто)конфигурации, для каждой подсети свои правила доступа во внешние сети, для каждой подсети свои правила маршрутизации между подсетями. И всё это управлялось бы строго в одном месте.
anonymous
( 14.12.21 22:27:48 MSK )
Итого, пообщался со своим провайдером(«ЭР-ТЕЛЕКОМ»), они сказали что выделяют только префикс /64 и в обозримом будущем другой выделять не будут. На этом теоретические выкладки о SLAAC, автоконфигурации и как бы было хорошо если бы…, можно прекращать. Имею то что имею. Настроил как советовал Kolins
[rav@MikroTik] > /ipv6/dhcp-client/ print detail Flags: D - dynamic; X - disabled, I - invalid 0 interface=dom.ru status=bound duid="0x00030001cc2de078ef45" dhcp-server-v6=fe80::a67b:2cff:fe23:121f request=prefix add-default-route=yes default-route-distance=1 use-peer-dns=no dhcp-options="" pool-name="dhcp_v6_pool" pool-prefix-length=112 prefix-hint=::/0 dhcp-options="" prefix=xxxx:xxxx:xxxx:xxxx::/64, 23h39m37s [rav@MikroTik] > /ipv6/pool/print detail Flags: D - dynamic 0 D name="dhcp_v6_pool" prefix=xxxx:xxxx:xxxx:xxxx::/64 prefix-length=112 expires-after=23h54m5s [rav@MikroTik] > /ipv6/dhcp-server/print detail Flags: D - dynamic; X - disabled, I - invalid 0 name="v6_dhcp" interface=br1-lan address-pool=dhcp_v6_pool lease-time=3m rapid-commit=yes use-radius=no preference=255 dhcp-option="" route-distance=1 allow-dual-stack-queue=no duid="0x00030001cc2de078ef45" Вопрос, как настроить debian что бы этот префикс получить? Запись request_prefix 1 в /etc/network/interfaces ничего не дала.
torm7 ★
( 15.12.21 11:56:18 MSK ) автор топика
Ответ на: комментарий от torm7 15.12.21 11:56:18 MSK
Вопрос, как настроить debian что бы этот префикс получить? Запись request_prefix 1 в /etc/network/interfaces ничего не дала.
Если не ошибаюсь, то там может принимать pd wide-dhcpv6-client . В сети, если не ошибаюсь, полно описаний, как это сделать.
Oleg_Iu ★
( 15.12.21 13:21:26 MSK )
Ответ на: комментарий от torm7 15.12.21 11:56:18 MSK
Но там веселуха конечно, ты по dhcpv6-pd-client получаешь префикс и должен его скриптами передать в dhcpv6-server/radvd/dnsmasq для раздачи в подсеть. Автоматики в wide/kea/isc dhcp не было, но я этим проектом летом 2020 занимался (и у меня был не debian, а китайский sdk под MT7621), может кто и довел до ума.
Kolins ★★★
( 15.12.21 13:29:42 MSK )
Последнее исправление: Kolins 15.12.21 13:35:22 MSK (всего исправлений: 1)
Ответ на: комментарий от Kolins 15.12.21 13:29:42 MSK
Kolins от туда и брал. Правда глубоко погрузиться не удалось, времени не было. Oleg_Iu wide-dhcp не пробовал, с ним в wiki mikrotik передают префикс, если с ics не получится, то с ним попробую.
torm7 ★
( 15.12.21 14:04:20 MSK ) автор топика
Ответ на: комментарий от anonymous 14.12.21 22:27:48 MSK
Для этого достаточно одной сети из 256 адресов выше крыши. Надо только использовать адекватные инструменты без нелепых ограничений вида «без /48 не работаю». Это же твоя личная сеть, ты не ограничен в ней никакими стандартами, можешь даже свой кастомный dhcp написать, плюя на любые бумажки и решая свою личную задачу. Стандарт регламентирует только интерфейс аплинка.
firkax ★★★★★
( 15.12.21 14:46:47 MSK )
Ответ на: комментарий от firkax 15.12.21 14:46:47 MSK
Проблема только в том, что программы могут с тобой не согласиться. Например, я делал сеть с префиксом /107, но временные адреса в ней никто получить не мог (что в целом ни разу не удивительно, но было бы прикольно, если бы где-то это отработало)
Khnazile ★★★★★
( 15.12.21 15:10:09 MSK )
Ответ на: комментарий от Khnazile 15.12.21 15:10:09 MSK
Что значит «не мог»? Говорю же — ты можешь написать свой dhcp client, который будет получать какие угодно адреса по какому угодно протоколу. То, что какие-то программы не умеют получать адреса в /107 — это проблема этих программ, а не сетей /107.
Впрочем, повторюсь, ipv6 весь какое-то недоразумение, и вполне возможно младшие 64 бита адреса в итоге будут использовать для чего-то другого, а настоящий адрес останется 64-битным.
firkax ★★★★★
( 15.12.21 15:20:03 MSK )
Последнее исправление: firkax 15.12.21 15:20:18 MSK (всего исправлений: 1)
Ответ на: комментарий от firkax 15.12.21 15:20:03 MSK
А операционную систему мне тоже свою написать? Нафиг мне сеть, с которой не смогут работать реальные устройства из этого мира?
Khnazile ★★★★★
( 15.12.21 15:35:41 MSK )
Ответ на: комментарий от Khnazile 15.12.21 15:35:41 MSK
А операционную систему мне тоже свою написать?
Почему нет? Линус написал же и теперь она в каждом утюге. 🙂
anc ★★★★★
( 15.12.21 15:37:45 MSK )
По сабжу — твой провайдер гондон, а ты страдаешь фигней, пытаясь подстроится под него. Если очень надо много сетей, и больше вариантов нет — получи адресное пространство у какого-нибудь HE и делай NAT в адресное пространство сети /64 на роутере. Да это стремный костыль, но лучше костылять трансляцию, чем стремную адресацию внутри сети.
Khnazile ★★★★★
( 15.12.21 15:42:41 MSK )
Ответ на: комментарий от Khnazile 15.12.21 15:42:41 MSK
А может и не гондон, может ТС с чего-то решил что вся /64 его личная.
IPv6, Mikrotik и Sarkor (инструкция)
Протокол IPv6 был создан более 25 лет назад. И несмотря на то, что на текущий момент он уже старше некоторых состоявшихся IT специалистов, для многих он является чем-то новым и неизведанным. Разговоры о переходе на IPv6 шли уже давно и подогревались паникой перед неизбежным концом далеко не бесконечных адресов v4. Но как бы не противилось человечество, научиться работать с этим, недружелюбным на первый взгляд протоколом, всё же, придётся.
Многие провайдеры до сих пор игнорируют необходимость внедрения нового протокола. Но это вовсе не помешало многим энтузиастам потренироваться на туннельных брокерах, некоторые из которых щедро раздают префиксы, вплоть до /48 совершенно бесплатно, практически любому желающему. Будучи одним из таких энтузиастов, я более-менее разобрался в базовых понятиях и принципах работы IPv6 и стал с нетерпеньем ждать, когда эти сети будут предоставляться нативно локальными провайдерами. И вот, в феврале 2022 года провайдер Sarkor Telecom первым в Узбекистане (по моей информации) анонсировал скорый запуск сетей IPv6 для обычных абонентов. С момента анонса прошло прилично времени, пока нововведение добралось до моего узла. Это и понятно, ведь внедрение ipv6 требует серьёзных изменений в работе сети и тесно связано с серьёзными последствиями, в случае плохо обдуманных решений.
Основные опасения тут связаны с тем, что в сети шестой версии абсолютно все устройства имеют собственный «белый» адрес, а значит, видимы из «мира». Людям, привыкшим к демилитаризованным зонам за NAT следует учесть это и очень серьёзно подойти к настройке фаерволлов. Если ранее в домашней сети можно было не беспокоиться о хранилище или камере со стандартным паролем (или вовсе без него) то теперь, получив глобальный адрес, такое устройство может легко стать жертвой злоумышленника. Правда, тут стоит оговориться, что «насканить» уязвимое устройство в сети v6 не так-то просто, поскольку даже в самом маленьком префиксе /64 (который дадут абоненту домой) чуть более 18 квинтиллионов адресов. Говоря проще – дохрена! Впрочем, есть ведь и шанс, что ваше устройство само обратится на вредоносный сервер, раскрыв свой адрес?
Что-ж, если вы дочитали (или пролистали) до этого абзаца – значит (по крайней мере, я на это надеюсь) вы в полной мере понимаете, что вы делаете и зачем вам это нужно.
Приступим, непосредственно, к настройке.
У меня установлена версия RouterOS 7.6 и в ней уже встроен IPv6. В случае с шестой веткой, возможно, вам потребуется включить одноимённый пакет поддержки протокола.
1) Включаем DHCPv6-client прямо на pppoe соединении.
Галочками отмечены опции для получения DNSv6 от провайдера, и ещё Rapid commit, которая позволяет быстрее «договориться» с DHCPv6 сервером, в случае, если на нём так-же включена такая опция.
В интерфейсах выбираем ваше PPPoE соединение в сторону саркора. В качестве имени пула можно указать что фантазии угодно. Длинна префикса в моём случае /64 бита. Если вдруг вам посчастливится стать владельцем сети покрупнее – ставьте соответствующее число. Маршрут по умолчанию далее мы получим в любом случае, так что галочку тут можно не ставить.
2) Если всё завязалось как надо, в нижнем правом углу окошка настройки DHCP клиента вы увидите надпись Status: bound а во вкладке status вы найдёте префикс, выданный провайдером.
Копируем этот префикс в буфер и переходим в IPv6 > Addresses
Добавляем новый адрес. В поле адреса вставляем из буфера ранее скопированный префикс. В поле From pool выбираем пул адресов. Если он у вас не появился, значит что-то пошло не так в предыдущих шагах.
В качестве интерфейса тут нужно выбрать тот интерфейс, через который ваш роутер будет раздавать адреса в локальную сеть. Этот способ заменят привычный нам DHCPv4. Тут вместо DHCP так называемый «Advertising» который в данном случае можно перевести как объявление адресов в сеть. Если хотим раздать адреса – отмечаем соответствующий чекбокс. Альтернативный путь – не раздавать адреса кому попало, а прописать их вручную только нужным устройствам. Имейте в виду, что на данный момент наш любимый tas-ix не особо в курсе, что такое ipv6 по этому, скорее всего, трафик в этом адресном пространстве побежит мимо всяких пиринговых стыков и локальных CDN. Подумайте хорошенько, нужно ли вам это. 🙂
3) Если не передумали, двигаем в IPv6 > Neghbor Discoveri и убеждаемся в том, что ND включен для интерфейса, в котором обитает наше сетевое окружение. По дефолту в этой настройке стоит разрешение на все интерфейсы, но я предпочёл ограничиться бриджем своей локалки, ибо интерфейсов у меня много, а раздавать туда адреса совершенно ни к чему.
4) Так-же, на всякий пожарный, стоит заглянуть в ipv6 > settings и убедиться в том, что поддержка протокола не выключена, а транзит (forward) не запрещён.
При необходимости, можно зайти в IP > DNS и добавить туда какие-либо дополнительные v6 адреса DNS серверов. В моём случае я уже получил их динамически по DHCPv6.
5) И вот наступает момент, когда, казалось бы, всё должно работать, но тут меня ждал подлый сюрприз. Половина сайтов не открывается, а SSH сессия по ipv6 тупо зависает, спустя несколько секунд после подключения. Я попробовал открыть ssh сессию прямо с микротика и как ни странно, она заработала нормально. Тогда мне пришло в голову проверить, какой размер пакета пролезает через сеть с роутера, а какой с клиента локалки. Пинги с разной длиной пакета сразу же указали на ключ к разгадке: если с роутера пакеты спокойно добегали в размере 1492 байта (MTU PPPoE соединения) то с клиентской машины максимальный размер оказался 1444 байта. Ну это уже ни в какие фреймы. 😉 Если честно, я пока так и не разобрался в причинах такого поведения, и решил проблему добавив в фаерволл правила для автоматической подстройки размера пакета.
И так, идём в IPv6 > Firewall > Mangle и жмём плюсик.
У двух правил разные только направления, всё остальное идентично друг другу.
Конечная остановка:
Если вы всё сделали верно – попингуйте мой сайт, и вы увидите длинный и некрасивый ipv6 адрес. 😉
!ВАЖНО!
Напоминаю ещё раз! Не забудьте про фаерволл. Вот базовые правила, которые закроют всю активность извне, разрешая при этом вашей локалке бегать в интернеты.
/ipv6 firewall filter
add action=accept chain=input comment=»Related, Established» connection-state=\
established,related,untracked
add action=accept chain=input comment=»accept from my net» in-interface=bridge
add action=accept chain=input comment=»accept ICMPv6″ protocol=icmpv6
add action=accept chain=forward comment=»Related, established» connection-state=\
established,related,untracked in-interface=sarkor
add action=drop chain=forward comment=»DROP fw to my net» connection-state=invalid,new in-interface=\
sarkor
add action=drop chain=input comment=»DROP all input» connection-state=invalid,new in-interface=sarkor \
protocol=tcp
Имя интерфейса заменить на имя вашего PPPoE соединения. Исключения добавлять по необходимости. Варить 20 минут, соли по вкусу. 😉