Nodeny+IPv6

[Cell]

может быть просто всем давать /64, а там пусть сами они разбираются - роутер это или конечный клиент
все равно подавляющее большинство будет роутеры

Я так и планирую и предлагаю условится что мы выдаем юзеру всегда /64 и что уж он с этим будет делать  не наше дело. Самый простой вариант реализации - статическая выдача адреса с привязкой /64 сети к юзеру навсегда.  Да, переход получится длительный и трудоемкий, но поверьте мне что с дхцп будет тоже самое с учетом наличного парка роутеров всех мастей. Поэтому я бы особо не рассчитывал на волшебные свойства динамики особенно с учетом того что к мак адресу это дело подцепить не получится и тут только опция рулит. Не везде есть возможность сделать опцию а много где она есть только теоретическая. Поэтому статика - это наше все )

[elite]

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

тогда просто принимаем, что /64 префикс - это один клиент, некий аналог 1 адреса ipv4

[Cell]

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

тогда просто принимаем, что /64 префикс - это один клиент, некий аналог 1 адреса ipv4

Об этом и речь. Генерим необходимое количество префиксов (т.к. 65тыс. в большинстве случаев никому не нужно) и принимаем что /64 это один клиент. НО
Нужно еще адреса на интерфейсную пару. Самосгенерированные для этого не подходят, на них только icmp ходит. Поэтому на каждый влан навешиваем еще по сеточке /64 или больше для организации интерфейсных пар (которые можно не маршрутизировать в интернет). Вполне себе нормальный способ обезопасить себя от хулиганья. И нафиг не нужны опции, влан на юзера и т.п.

[Redmen]

И нафиг не нужны опции, влан на юзера и т.п.

а как же безопасность? а как юзать с dual-stack? а как внедрять в существующую топологию? а как бить с брасами типа цыски, джун и прочие? как в билинге в6 к абонам цеплять, шейпить и мониторить?
или ты планируешь абонам отдавать либо в4 либо в6?

или ты просто планируешь запустить в6 конкретно под себя?
тогда смысл здесь на форуме это обсуждать?

если делать функционал, то уже нормально 

[Cell]

Спрашивали, отвечаем:
Я не солнце, чтобы всем нравится и переписать весь биллинг для того чтобы кому-то показалось что сделано "нормально".
Что качается безопасности - сначала попробуйте сделать что-то с ipv6 в одном влане ))) а оптом громко заявлять по безопасность. Это другой протокол! и довольно продвинутый. Что касается совместной работы - то оно работает аж в путь.
Я ищу вариант прикрутить IPv6 к биллингу чтобы сделать жизнеспособной схему которая уже работает!!!!!! без шейперов и ограничений.
Для того чтобы это стало все жизнеспособным - биллинг должен поддерживать IPv6 хоть в каком-то виде, т.е. нужно наладить учет и переписать noserver для поддержки нового пула. Я планирую использовать  IPv4 и IPv6 одновременно. Выдавать оба варианта юзеру одновременно  - они друг другу не мешают.
Что делать с брасами которых у меня нет в заведовании - мне глубоко фиолетово, это должна быть забота админов, которые их используют.
Как-то так. И еще... я так особо никому ничего не должен, а на форуме пишу потому, что биллинг IPv6 не поддерживает ни в каком виде, ни в "нормальном" ни в каком-либо еще. Поэтому кому-то это может быть полезно. Можно эту тему не читать, если режет глаза.
Что-то конкретики никакой нет, одна критика. Кроме Элита вообще всем пофиг?

[Jovani]

Спрашивали, отвечаем:
Я не солнце, чтобы всем нравится и переписать весь биллинг для того чтобы кому-то показалось что сделано "нормально".
Что качается безопасности - сначала попробуйте сделать что-то с ipv6 в одном влане ))) а оптом громко заявлять по безопасность. Это другой протокол! и довольно продвинутый. Что касается совместной работы - то оно работает аж в путь.
Я ищу вариант прикрутить IPv6 к биллингу чтобы сделать жизнеспособной схему которая уже работает!!!!!! без шейперов и ограничений.
Для того чтобы это стало все жизнеспособным - биллинг должен поддерживать IPv6 хоть в каком-то виде, т.е. нужно наладить учет и переписать noserver для поддержки нового пула. Я планирую использовать  IPv4 и IPv6 одновременно. Выдавать оба варианта юзеру одновременно  - они друг другу не мешают.
Что делать с брасами которых у меня нет в заведовании - мне глубоко фиолетово, это должна быть забота админов, которые их используют.
Как-то так. И еще... я так особо никому ничего не должен, а на форуме пишу потому, что биллинг IPv6 не поддерживает ни в каком виде, ни в "нормальном" ни в каком-либо еще. Поэтому кому-то это может быть полезно. Можно эту тему не читать, если режет глаза.
Что-то конкретики никакой нет, одна критика. Кроме Элита вообще всем пофиг?

Поддерживаю и читаю. На будущее нужный функционал.

[goletsa]

Хех, IPv6 тема ожила. И без меня даже.
На самом деле у меня тоже лежит в планах доработка, но сразу несколько нюансов.

/48 провайдеру - мало, это обычно PI блок, который нельза выдавать клиентам.
Если вы LIR то спокойно получаете /32../29 (а вообще при последнем выделении v4 заставляли сначала v6 блок взять).

Клиенту надо выделять /56 (Ну или /64 плюс делать резервирование блока адресов до /56), юрикам рекомендация выдавать /48 (чтобы они уже внутри себя разруливали).
Патамушта /64 для домашней сети может быть тупо мало и могут запросить расширение.
https://www.ripe.net/publications/docs/ripe-690#1--executive-summary

Основная идея у меня такая, что для упрощения выдачи адресов не надо городить никаких сложных схем с делением адресов.
У нас есть уникальный идентификатор клиента - UID, это в общем-то целое число.
Никто не мешает его использовать в качестве ключа при выдаче адресов, даже если мы будем использовать их не оптимально, адресов все равно много, крохоборить с /127 не надо.

Пример, есть блок 2000::/32
Это 65,536  сетей /48.

Для простоты можно просто в качестве третьего блока адресов подставлять UID или его HEX представление, для большинства сетей этого хватит.
То есть технически самое простое решение выделять на один UID клиента /48, но в зависимости от условий отдавать клиенту /64 блок, оставляя за собой возможность расшириться в случае необходимости до /56 или до /48

2000:0000:UID::/64
2000:0000:UID::/56
2000:0000:UID::/48

Для ситуации с /48 блоком и распиливанием меньше чем на /64 блоки считайте сами, но уж если внедрять, то сразу нормально.

[Cell]

Для простоты можно просто в качестве третьего блока адресов подставлять UID или его HEX представление, для большинства сетей этого хватит.

Если отвлечься от обсуждения размера префикса, то это вообще интересная идея, которая подлежит осмыслению.
С другой стороны что нам это дает?  С таким же успехом в пуле имеется поле uid которое связывает ип адрес и абонента.

[goletsa]

Для простоты можно просто в качестве третьего блока адресов подставлять UID или его HEX представление, для большинства сетей этого хватит.

Если отвлечься от обсуждения размера префикса, то это вообще интересная идея, которая подлежит осмыслению.
С другой стороны что нам это дает?  С таким же успехом в пуле имеется поле uid которое связывает ип адрес и абонента.

Биллинг может вообще не знать о существовании IPv6 адресов как класса и не надо будет городить лишние костыли чтобы вкорячивать хранение префиксов, делегирование блоков итд.
Максимум например хранить размер блока который ты отдаешь клиенту в допполе, можно как целое число и уже на базе простой математики отдавать все параметры на стороне noserver'а или radius'a

[Cell]

Биллинг может вообще не знать о существовании IPv6 адресов как класса и не надо будет городить лишние костыли чтобы вкорячивать хранение префиксов, делегирование блоков итд.
Максимум например хранить размер блока который ты отдаешь клиенту в допполе, можно как целое число и уже на базе простой математики отдавать все параметры на стороне noserver'а или radius'a

Это интересная идея. Нужно будет подумать над этим.

[cojiict]

Клиенту надо выделять /56 (Ну или /64 плюс делать резервирование блока адресов до /56), юрикам рекомендация выдавать /48 (чтобы они уже внутри себя разруливали).
Патамушта /64 для домашней сети может быть тупо мало и могут запросить расширение.

От тут непанятка. З якого переляку 18446744073709551616 адрес (/64) в домашній мережі може бути мало? /48 це 65536 /64 підмереж. Тут варто враховувати ще вартість /48 і як його раціонально розділяти клієнтам.
З.І. З ІРv6 знайомий тільки в теорії, тому якщо щось не розумію, то ткніть носом

[goletsa]

Потому что большинство клиентского оборудования ожидает увидеть /64 на интерфейсе.
А как только хочешь завести гостевую сеть - она должна быть уже в другой /64, иначе теряется весь смысл гостевой сети.
А вообще я скинул ссылку на официальные рекомендации райпа по адресации в в6 сетях, почитайте.

[Cell]

А можно просто взять и выдать 2-3-10 префиксов /64 в зависимости от того что попросит клиент. На этом считаю дискуссии на тему размера префикса нужно прекращать ))) а то это затянется как внедрение телевидение высокой четкости ))) стандарты которого пытались утвердить еще в моем детстве, да так и не смогли пока японцы взяли да не запустили HD формат. А прошло всего-то 40 лет )
 

[Gosha]

Кто то уже тестирует IPv6 с nodeny?
Обновлю тему, ибо v6 уже актуально.

[goletsa]

Кто то уже тестирует IPv6 с nodeny?
Обновлю тему, ибо v6 уже актуально.

Пока нет, но в планах все еще стоит, очень долго мигрировали с ND50