Jump to content
Калькуляторы

Надо бы попробовать IPv6

Насколько я понимаю должна работать схема когда роутер хомяка по лонклокал адресам до провайдера ходит, а полученные 64 выдаёт в локалку.

/127 это извращенские фантазии без всякого смысла.

Share this post


Link to post
Share on other sites

5 часов назад, Ivan_83 сказал:

Насколько я понимаю должна работать схема когда роутер хомяка по лонклокал адресам до провайдера ходит, а полученные 64 выдаёт в локалку.

/127 это извращенские фантазии без всякого смысла.

Поддерживаю. Только кмк роутер не выдаёт в локалку /64, а работает в режиме комутатора и локалка сама к провайдеру за адресами ходит. Разве не в этом одна из прелестей ipv6 - заменить умные домашние роутеры тупыми свитчами?

Share this post


Link to post
Share on other sites

9 hours ago, killonik said:

Поддерживаю. Только кмк роутер не выдаёт в локалку /64, а работает в режиме комутатора и локалка сама к провайдеру за адресами ходит. Разве не в этом одна из прелестей ipv6 - заменить умные домашние роутеры тупыми свитчами?

Нет. В плане роутинга там все также.

 

14 hours ago, rm_ said:

Поздравляю, cегодня ты смог сделать этот мир чуточку хуже. Читающие это провайдеры потом, может быть через годы, тебе же и организуют /64. Без всякого "механизма по запросу", о чём вообще речь, это фантастика.

 

Рекомендация хорошая и правильная, а если хотите топить за то чтоб в России IPv6 был не как в остальном мире а гораздо более унылый и костыльный - мотивация к этому мне непонятна.

я оговорился, что 

 

17 hours ago, ShyLion said:

Хотя... я опять рассуждаю с позиции жадины :)

 

Share this post


Link to post
Share on other sites

59 minutes ago, ShyLion said:

Нет. В плане роутинга там все также.

 

Не очень понятно как "также". Клиентский роутер должен получить сеть, а потом начать выдавать по dhcp адреса из полученного диапазона? Клиентские роутеры на нынешний момент умеют такое вообще? И нужен ли там вообще клиентский роутер если клиентские устройства могут обращаться напрямую к dhcp провайдера и работать через коммутатор?

Впрочем к ipv6 есть ряд иных претензий.

Edited by Rivia

Share this post


Link to post
Share on other sites

10 minutes ago, Rivia said:

Не очень понятно как "также". Клиентский роутер должен получить сеть, а потом начать выдавать по dhcp адреса из полученного диапазона? Клиентские роутеры на нынешний момент умеют такое вообще? И нужен ли там вообще клиентский роутер если клиентские устройства могут обращаться напрямую к dhcp провайдера и работать через коммутатор?

Впрочем к ipv6 есть ряд иных претензий.

 

В протоколе DHCPv6 есть специально для этого механизм - Prefix Delegation.

CPE после поднятия линка делает запрос PD-request. На линке с провайдером. В ответ шлется делегируемая сеть. CPE руководствуясь собственным алогритмом, в зависимости от размера делегированого блока, распределяет их по линкам. В простейшем случае домашнего роутера назначает на LAN самый первый /64 из делегированого перфикса.

В RADIUS есть соответсвующие атрибуты.

Share this post


Link to post
Share on other sites

5 minutes ago, ShyLion said:

В протоколе DHCPv6 есть специально для этого механизм - Prefix Delegation.

CPE после поднятия линка делает запрос PD-request. На линке с провайдером. В ответ шлется делегируемая сеть. CPE руководствуясь собственным алогритмом, в зависимости от размера делегированого блока, распределяет их по линкам. В простейшем случае домашнего роутера назначает на LAN самый первый /64 из делегированого перфикса.

В RADIUS есть соответсвующие атрибуты.

Ок, выглядит неплохо. Будете ограничивать кол-во отдаваемых сетей на порт коммутатора тогда?

Share this post


Link to post
Share on other sites

Всё роутеры умеют. Если есть поддержка ipv6, практически всегда поддерживается и dhcp6-prefix-delegation. Роутер получает префикс, внутри раздает через чаще по slaac, инногда dhcp6.

Сейчас пробуем протестить на небольшой выборке. По роутерам:

 

ASUS - нужно включить в настройках ipv6, ничего хитрого прописывать не нужно.

OpenWrt свежие - взлетает сразу

OpenWrt старые - некоторые траблы, нужны доп. настройки и т.п.

Zyxel - вроде тоже сразу

 

Естественно, имеются ввиду модели, где поддержка ipv6 заявлена.

В общем ситуация сейчас значительно лучше, чем года три назад.

Если просто включить DHCPv6 в абонентском влане, куча клиентов просят адреса.

Edited by Valaskor

Share this post


Link to post
Share on other sites

Just now, Rivia said:

Ок, выглядит неплохо. Будете ограничивать кол-во отдаваемых сетей на порт коммутатора тогда?

Не понял вопроса.

Какова модель предоставления услуги имеется в виду?

 

ЗЫ: с моей стороны это все теория, пока что в реальности ни один абонент не попросил IPv6, по дефолту не даем. Экспериментировал только с PPPoE с линукс клиентом.

 

Share this post


Link to post
Share on other sites

8 minutes ago, ShyLion said:

Не понял вопроса.

Какова модель предоставления услуги имеется в виду?

 

ЗЫ: с моей стороны это все теория, пока что в реальности ни один абонент не попросил IPv6, по дефолту не даем. Экспериментировал только с PPPoE с линукс клиентом.

 

Вопрос примерно в этом, да. Если клиенту предполагается выдавать больше 1 подсети (или вообще не ограничивать), то клиент может просто ставить себе свитч и не заморачиваться роутером. Другой вопрос там про вайфай, но в любом случае некоторые клиенты начнут при такой схеме пользовать свитчи.

Edited by Rivia

Share this post


Link to post
Share on other sites

Сделайте над собой усилие, и перестаньте думать, что /64, /48 или /32 это «слишком много».

Дизайн ipv6 рассчитан не для сохранения свободных адресов для всех провайдеров на миллион лет вперед, а перспективу геометрического роста клиентских ip-адресов и уменьшение количества маршрутов путем агрегации (при этом ДОЛЖНА осуществляется ОГРОМНАЯ бесполезная трата v6-ипишников на запасы во всех местах).

 

Немного тезисов из рекомендаций райпа (https://www.ripe.net/publications/docs/ripe-690):

Рекомендуется использовать для конечных пользователей:
/48 (для абсолютно всех может казаться излишне, но все равно делайте, райп даст адреса, всем хватит)
/56 (рекомендуется ВСЕМ, кроме бизнес сегмента(любого), для них мало!)
/60 только при аппаратных ограничениях (не рекомендуется!)

/64 для конечного клиента – райп осуждает и крайне не рекомендует так делать!

Т.е. предполагается, что клиентский роутер поделит /56 на кучу сетей /64, отдельно вайфай, отдельно провод, гостевая и т.д.

При делении подсетей, настоятельно рекомендуется идти кратно 4 битам, чтоб не путаться с hex-нотацией адреса.

 

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

 

Между роутером абонента и провайдером рекомендуется отдельная /64 (нормально работают трассы и и.п.), но не обязательно. (например, мы сейчас вообще там юзаем автоматические link-local, пакеты нормально ходят в сетку юзера и обратно).

 

Пока думаю делить как-то так:

Префикс лировский /32 (меньше они не выделяли, при этом он еще до /29 расширяется – место автоматически зарезервировано райпом). Из него юзаем /36, остальное запас (т.е. используем 1/16).

Получается до 16 (сейчас 6) узлов агрегации по /40. А на узлах агрегации до 65к клиентов по /56. (фактический онлайн сейчас в несколько раз меньше).

Share this post


Link to post
Share on other sites

1 hour ago, Rivia said:

Вопрос примерно в этом, да. Если клиенту предполагается выдавать больше 1 подсети (или вообще не ограничивать), то клиент может просто ставить себе свитч и не заморачиваться роутером. Другой вопрос там про вайфай, но в любом случае некоторые клиенты начнут при такой схеме пользовать свитчи.

В варианте когда вам в линк смотрят конечные устройства - они и не будут PD запросы делать.

 

17 hours ago, Ivan_83 said:

/127 это извращенские фантазии без всякого смысла.

Коллега, как предполагается бороться с атакой на neighbour cache?

Есть готовые решения?

Я не ради сарказма, а просто интересуюсь.

Share this post


Link to post
Share on other sites

2 часа назад, ShyLion сказал:

Коллега, как предполагается бороться с атакой на neighbour cache?

А как вы боролись с arp cache poision ?

Share this post


Link to post
Share on other sites

4 минуты назад, Ivan_83 сказал:

С левыми PPPoE концентраторами?

ну с этим бороться совсем просто(просто л2-изоляция), в отличии от всяких arp cache атак, где точка терминирования должна сверять л2 хедеры с л3

Share this post


Link to post
Share on other sites

@Valaskor, спасибо. Читал райп, но вы прям как для людей расписали.

Только, всё равно, надо экономить. Райп же бесплатно не расширит ранее купленный блок)

Share this post


Link to post
Share on other sites

12 часов назад, killonik сказал:

@Valaskor, спасибо. Читал райп, но вы прям как для людей расписали.

Только, всё равно, надо экономить. Райп же бесплатно не расширит ранее купленный блок)

если есть статус LIR, то бесплатно еще /32 выпишет. не нужно экономить!!! пусть горят в аду, кто балансирует трафик префиксами, а не community и те, кто пилит ipv6 и анонсирует отдельные блоки, которые должны агрегированным префиксом улетать.

Share this post


Link to post
Share on other sites

3 часа назад, dmvy сказал:

если есть статус LIR, то бесплатно еще /32 выпишет. не нужно экономить!!! пусть горят в аду, кто балансирует трафик префиксами, а не community и те, кто пилит ipv6 и анонсирует отдельные блоки, которые должны агрегированным префиксом улетать.

Вот я так и думал, что лир бесплатно получит, а нам загонит за бешенные бабки. Нет у нас, к сожалению, статуса лир.

 

1 час назад, ShyLion сказал:

PI /48 стоит 50 ойро в год.

Скиньте ваш ссыль пжлста. Потому что в прайсе той конторы, где мы закупали ранее адреса 300$ за /48 PI и 500$ за /32 PA. http://ipaddr.ru/prices

Вообще мы тут уже прикинули распределение адресов и пришли к выводу, что /48 нам не хватит, чтобы всё по уму сделать.

 

А за 50 ойро они могут документы привезти))

Share this post


Link to post
Share on other sites

52 minutes ago, killonik said:

Скиньте ваш ссыль пжлста. Потому что в прайсе той конторы, где мы закупали ранее адреса 300$ за /48 PI и 500$ за /32 PA. http://ipaddr.ru/prices

https://www.ripe.net/publications/docs/ripe-686

https://www.ripe.net/participate/member-support/payment/billing-procedure-and-fee-schedule-2018#fees-for-existing-members

 

 

Для примера - в основной конторе где я работаю - среднего размера энтерпрайз (не провайдер) нашим sponsoring-LIR является Ростелеком. Там на сколько я знаю мы вообще им не платим за PI ресурсы просто потому что мы им за каналы платим на пару порядков больше.

 

Если вы уже немаленький оператор, то становитесь LIR сами. Заодно вам еще и IPv4 /22 дадут.

Share this post


Link to post
Share on other sites

кхмм... Мы ещё не настолько крупный оператор. Взносы за ЛИРство выходят значительно дороже, чем мы сейчас платим+возможно будем платить за /32.

Share this post


Link to post
Share on other sites

Just now, killonik said:

кхмм... Мы ещё не настолько крупный оператор. Взносы за ЛИРство выходят значительно дороже, чем мы сейчас платим+возможно будем платить за /32.

/32 вам же дают PA, т.е. они формально не ваши.

Share this post


Link to post
Share on other sites

1 минуту назад, ShyLion сказал:

/32 вам же дают PA, т.е. они формально не ваши.

Ну не отберут же их у нас как в 90-е)) Плати ежегодно и пользуйся. Разве не так?

Share this post


Link to post
Share on other sites

Тут каждый сам за себя решает :)

Ну и политика райпа тоже может поменяться. Плюс та контора может сама загнуться или начать вас шантажировать (ну в теории конечно).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.