Перейти к содержимому
Калькуляторы
18 минут назад, Ivan_83 сказал:

Просто подумай ещё раз: зачем людям дома роутер когда у них три планшета и 4 мобилы? Что там "защищать"?

Им нужна точка доступа и всё.

А зачем ИМ вообще IPv6? Он скорее нужен оператору. Клиенту то он зачем?

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

Ты их поди найди в IPv6.

Очень скоро появится новое поколение вирусни (а может оно уже есть), которое только этим и будет заниматься (собирать данные об адресах IPv6 в вашей сети и отсылать "хозяину" для последующих атак).

 

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

А если написать 16 байт рандома - то уже не так страшно.

А если пакетики наконец сделать по 9к то будет сильно меньший процент составлять служебка чем сейчас даже с в4.

Ну и на фоне всеобщего безумного TLS для кофеварок - это таки херня, не говоря о том, что и так 90% трафика это мусор с ютуба и прочих помоек.

Какое отношение этот текст имеет к спору про IPv6 и роутеры?

 

Лучше скажите, зачем надо в современном мире затаскивать Л2 в Л3 и что делать с безопасностью устройств в IPv6?

 

Если Вы не в курсе, то IPv6 был "изобретен" (принят в РФЦ) еще до внедрения DHCP.

 

Повторюсь, протокол IPv6  УЖЕ устарел и перед его реальным массовым запуском требует серьезной ревизии, в том числе в части связанной с безопасностью, администрированием и взаимодействием между Л2 и Л3.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

А зачем им вообще IPv6?

А зачем им IPv4 - у которого нет перспектив?

 

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

Очень скоро появится новое поколение вирусни (а может оно уже есть), которое только этим и будет заниматься (собирать данные об адресах IPv6 в вашей сети и отсылать "хозяину" для последующих атак).

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

 

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

Какое отношение этот текст имеет к спору про IPv6 и роутеры?

Это ответ про лишние байты которые туда-сюда из за IPv6.

 

2 минуты назад, sdy_moscow сказал:

Лучше скажите, зачем надо в современном мире затаскивать Л2 в Л3 и что делать с безопасностью устройств в IPv6?

Если ты про мак в адресе IPv6 - так это херня.

ND - тот же самый арп, только вместо броадкаста - мультикаст.

Всё уже сделано, моё предложение с TTL=1 только дополняет и упрощает безопасность для домашних устройств.

 

2 минуты назад, sdy_moscow сказал:

Повторюсь, протокол IPv6  УЖЕ устарел и перед его реальным массовым запуском требует серьезной ревизии, в том числе в части связанной с безопасностью, администрированием и взаимодействием между Л2 и Л3.

Хорошо.

1. IPv4 устарел ещё больше.

2. Его уже запустили массово.

3. Ждём пул регвестовчерновиков в RFC.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Надеюсь ты оценил элегантность решения: никакого фаера, никакой фильтрации пакетов, никакого NAT но всё вполне секурно, если конечно провайдеру доверять или роутер держать хотя бы в режиме роутера без NAT.

Не сработает. Все эти железки очень хотят ходить к производителю. А производитель - наоборот, на железки. Поэтому никаких TTL=1 железки ставить не будут. Соответственно, firewall придется таки делать. Благо, в ipv6 он простой.

 

6 часов назад, sdy_moscow сказал:

Лучше скажите, зачем надо в современном мире затаскивать Л2 в Л3

За тем, что в какой-то момент Ipv6 адреса можно использовать и как L2 и как L3. Ну вот зачем коммутатору/маршрутизатору про всякие MAC-и знать, если можно просто по ipv6 адресу понять, в какой порт пакет отправить?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

7 часов назад, sdy_moscow сказал:

Ну то есть, то что мы сейчас фактически таскаем с одной стороны мира на другую по два 64-х битных "случайных" числа в каждом пакете IPv6 - это по вашему НЕ БРЕД.

А еще на по дороге много раз прицепляем и отцепляем MAC адреса. Что тоже, по сути, является историческим наследием и может рассматриваться как бред. На L2 уровне место же занимают и пропускную способность уменьшают.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

18 минут назад, Sergey Gilfanov сказал:

зачем коммутатору/маршрутизатору про всякие MAC-и знать, если можно просто по ipv6 адресу понять, в какой порт пакет отправить?

Затем, что кроме ipv6, есть еще много протоколов, работающих по L2. Хоть они и менее распространены, это совсем не означает, что на них можно положить болт.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Только что, [anp/hsw] сказал:

Затем, что кроме ipv6, есть еще много протоколов, работающих по L2. Хоть они и менее распространены, это совсем не означает, что на них можно положить болт.

А почему эти протоколы нельзя проапгрейдить на  прямое использование ipv6 адреса?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

А почему эти протоколы нельзя проапгрейдить на  прямое использование ipv6 адреса?

Во-первых - это значит отказаться от поддержки всего существующего парка устройств, которые его поддерживают. Поддержка многих устройств уже давно закончилась, как пример - всякие ЧПУ станки, системы автоматизации, итд.

Во-вторых - это задержки. ipv6 заголовок несколько сложнее ethernet, и сил для его обработки требуется побольше. Разбор ethernet кадров вылизан годами, а кто будет тестировать и оптимизировать обработку ipv6? Для всяких систем особой важности это критичный фактор.

В-третьих - за чей счет банкет? IP-блоки, чтобы построить свой чип для ethernet-коммутатора можно чуть ли не в свободном доступе найти. Кто будет разрабатывать IPV6-only свич, если большинству заказчиков он не нужен?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

13 минут назад, [anp/hsw] сказал:

В-третьих - за чей счет банкет? IP-блоки, чтобы построить свой чип для ethernet-коммутатора можно чуть ли не в свободном доступе найти. Кто будет разрабатывать IPV6-only свич, если большинству заказчиков он не нужен?

Ну так никто не говорит, что прямо сейчас это все происходить будет. Как IPv6 расползется - начнут оптимизировать. Зачем в IoT железке всякие ARP-образные протоколы для определения MAC адреса маршруризатора иметь, если мы все равно кидаем пакет в сторону коммутатора, который и есть наш маршрутизатор? DST/SRC адреса, которые в Ethernet, перестают выполнять осмысленную функцию.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Зачем в IoT железке всякие ARP-образные протоколы для определения MAC адреса маршруризатора иметь, если мы все равно кидаем пакет в сторону коммутатора, который и есть наш маршрутизатор?

И сразу перестают работать протоколы типа LACP, VRRP о прочего, завязаные на том, что у двух хостов может быть один и тот же IP-адрес, или распределяющие потоки согласно MAC-адреса а не IP. Вы же не будете делать "специальный IOT коммутатор"? Стандарт - он для всех. Как-то надо будет реализовывать подобные фичи, чтобы быть совместимыми в другими коммутаторами.

Опять же - сколько там IPv6-адресов-то? Даже в современных коммутаторах все мак адреса (всего 6 байт!) не влезают в коммутационную матрицу, и приходится считать от них хэш бит так на 12-14, и по нему работать. Как вам больше нравится? Килобитные скорости, или адресные коллизии на каждом втором пакете?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

33 минуты назад, [anp/hsw] сказал:

Опять же - сколько там IPv6-адресов-то? Даже в современных коммутаторах все мак адреса (всего 6 байт!) не влезают в коммутационную матрицу, и приходится считать от них хэш бит так на 12-14, и по нему работать. Как вам больше нравится?

Количество записей в матрице может и уменьшиться. Каждый оконечный пор дает столько записей, сколько ipv6 адресов на подключенной к нему железке. На всех остальных - вообще одна-две, вида "вот этот префикс шлем в тот порт".

Те. входящий префикс для входного маршрутизатора - какой-нибудь 2001:0db8:0013::/46, нарезаем из него  32 штуки /51 по префиксу на порт , следующий уровень - еще 32 штуки /56, еще следующий - 32 штуки /61, следующий - 32 штуки /66 (Ethernet-а как такового у нас уже нет, поэтому "/64 на интерфейс" выполнять уже не обязательно)   4 уровня по 32 порта = 1048576 портов.

 

33 минуты назад, [anp/hsw] сказал:

И сразу перестают работать протоколы типа LACP, VRRP о прочего, завязаные на том, что у двух хостов может быть один и тот же IP-адрес, или распределяющие потоки согласно MAC-адреса а не IP. 

Тут нужно смотреть, какие протоколы еще будут иметь смысл. VRRP, скажем, не имеет. Потому что даже сейчас если ломается коммутатор, куда железка подключена, то наличие двух маршрутизаторов в сети ничему не поможет. Для резервирования нужно два физических линка к двум разным коммутаторам.

33 минуты назад, [anp/hsw] сказал:

Вы же не будете делать "специальный IOT коммутатор"? Стандарт - он для всех.

Cкорее всего, будет какой-нибудь "ipv6 only" коммутатор. Вполне себе стандартный.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

10 минут назад, Sergey Gilfanov сказал:

Те. входящий префикс для входного маршрутизатора - какой-нибудь 2001:0db8:0013::/46, нарезаем из него  32 штуки /51 по префиксу на порт , следующий уровень - еще 32 штуки /56, еще следующий - 32 штуки /61, следующий - 32 штуки /66 (Ethernet-а как такового у нас уже нет, поэтому "/64 на интерфейс" выполнять уже не обязательно)   4 уровня по 32 порта = 1048576 портов.

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

 

11 минут назад, Sergey Gilfanov сказал:

Потому что даже сейчас если ломается коммутатор, куда железка подключена, то наличие двух маршрутизаторов в сети ничему не поможет. Для резервирования нужно два физических линка к двум разным коммутаторам.

Весь мировой интернет не сконцентрирован в коммутаторе. А значит он еще и сам будет решать, к какому из аплинков пускать трафик? Не иначе как ospf или bgp там будет?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

IoT и бытовая техника может просто выставить TTL=1 и вообще не заморачиватся безопасностью - только непроходимая тупость и полнейшее не знание сетей мешают разработчикам так сделать.

Вот тот же UPnP/DLNA просто обязан быть с TTL=1, ибо ему за пределами хаты делать нехер - но нет, кажется я один это запилил или собираюсь запилить у себя в ssdpd.

Изначально в IPv6 были как раз на такие случаи site-local адреса. Но Те кто стоит за сетью и занимается сетями решили, что это слишком сложно, и выпилили нахер.

 

 

 

 

 

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

Ставится на внутренний интерфейс /64, на внешнем lladdr. Это же ipv6, зачем там дополнительные адреса на интерфейсы вешать?

Угу, провайдер у себя роутер или даже порт поменял и схема протухла.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Только что, [anp/hsw] сказал:

Весь мировой интернет не сконцентрирован в коммутаторе. А значит он еще и сам будет решать, к какому из аплинков пускать трафик? Не иначе как ospf или bgp там будет?

Вот не вижу проблемы с настройкой "вот этот порт(ы) - uplink". Это те, на которых у нас Router Advertisement приходят. Оттуда же берем префикс сети, который нам по портам нарезать надо.

3 минуты назад, [anp/hsw] сказал:

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

Не понял. Какие вычислительные ресурсы? Вырезать из адреса 4-6 бит по маске (в соответствии с количеством портов) и по полученному числу выбрать порт?

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Только что, Sergey Gilfanov сказал:

Это те, на которых у нас Router Advertisement приходят.

Т.е теперь еще нужен CPU, который будет обрабатывать RA?

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

Оттуда же берем префикс сети, который нам по портам нарезать надо.

А вот тут по-подробнее: если переложить модель VRRP на вашу, то получается, что с двух портов будет приходить одинаковый префикс, так? Какой из них будет главным?

3 минуты назад, Sergey Gilfanov сказал:

Какие вычислительные ресурсы? Вырезать из адреса 4-6 бит по маске (в соответствии с количеством портов) и по полученному числу выбрать порт?

Т.е. при замене свича на свич с другим количеством портов, адресные пространства будут смещаться? Отлично, вы выдумали еще одну проблему на пустом месте!

Ваш свич собрался коммутировать только в одну сторону? Как быть с ситуацией, когда сетей больше одной, и одну из них надо нарезать "в другую сторону"? А что если статически резать я не хочу, а хочу отдать в один из портов сеть "как есть"? И таких "если" - довольно много. Такими вещами в ASIC уже не заставите заниматься, ему нужна помощь CPU.

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

43 минуты назад, [anp/hsw] сказал:

А вот тут по-подробнее: если переложить модель VRRP на вашу, то получается, что с двух портов будет приходить одинаковый префикс, так? Какой из них будет главным?

Который сконфигурируем. Можно оба через раз использовать.

43 минуты назад, [anp/hsw] сказал:

Т.е. при замене свича на свич с другим количеством портов, адресные пространства будут смещаться?

В этой схеме - да. Router Advertisement сменится и нижостоящие ареса поменяются сами.

 

Если хотим, чтобы не менялось - придется протоколы динамической маршрутизации использовать. Что вроде не должно быть слишком тяжело по нагрузке на CPU, потому что однажды выданные префиксы почти никогда не переезжают

В конце концов, сейчас маршрутизатор вполне успешно помнят и вычисляют "эту сетку отсылать на такой-то MAC". Или, в контексте вопроса в начале темы - даже совсем не легковесный NAT ухитряются делать.

43 минуты назад, [anp/hsw] сказал:

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

Упрощение логики в самих оконечных устройствах. Уменьшение количество уровней в стеке протоколов, которые нужно делать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

42 минуты назад, Sergey Gilfanov сказал:

..Упрощение логики в самих оконечных устройствах...

Это так казалось. А когда выяснилось, что по второй части адреса (64-бит в котором спрятали MAC адрес) можно легко отследить любого юзера и все его передвижения по миру, да еще и сразу понять, что же за устройство в сети - "ОНИ" СХВАТИЛИСЬ ЗА ГОЛОВУ и начали придумывать такие извращения с динамической сменой второй части адреса, что волосы дыбом встают.  В итоге приходится решать те проблемы, которые давно уже решены и вылизаны десятилетиями.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

40 минут назад, sdy_moscow сказал:

Это так казалось. А когда выяснилось, что по второй части адреса (64-бит в котором спрятали MAC адрес) можно легко отследить любого юзера и все его передвижения по миру, да еще и сразу понять, что же за устройство в сети - "ОНИ" СХВАТИЛИСЬ ЗА ГОЛОВУ и начали придумывать такие извращения с динамической сменой второй части адреса, что волосы дыбом встают.  В итоге приходится решать те проблемы, которые давно уже решены и вылизаны десятилетиями.

Это из за того, что пытались добиться совместимости с Ethernet. Делали так, чтобы выбираемые устройством адреса не с кем не конфликтовали. В описанной схеме, где каждому порту выдается уникальный префикс - можно собственного MAC вообще не иметь или не обращать на него внимания. Просто брать первый адрес из полученной от "коммутатора" сети - и он по построению ни с кем пересекаться не будет. Ну да, воткнулся в другой порт - и адрес у тебя сменился. Но это, как бы, так и задумано, что в IPv6 гораздо более географически зависимые - чтобы агрегировать маршруты легче было.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

11 минут назад, Sergey Gilfanov сказал:

Просто брать первый адрес из полученной от "коммутатора" сети - и он по построению ни с кем пересекаться не будет

Там такого нет в RFC. Мало того, сама процедура настройки адреса и параметров соединения не тривиальна. Да и коммутатор при таком раскладе придется превращать в роутер - а зачем?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Только что, sdy_moscow сказал:

Там такого нет в RFC. 

Можно считать, что есть. interface identifier из которого ipv6 адрес генерируется, должен быть уникальным в пределах линка. Если у нас ближайшая сетевая железка - сразу маршрутизатор, и больше никого на этом куске провода,  кроме нас и маршрутизатора не видно, то 

Цитата

The same interface identifier may be used on multiple interfaces on a single node, as long as they are attached to different subnets.

В описанной схеме подсети на разных портах ближайшего маршрутизатора - как раз разные.

 

49 минут назад, sdy_moscow сказал:

Да и коммутатор при таком раскладе придется превращать в роутер - а зачем?

Выкидываем целый слой из стека протоколов. Не надо реализацию (железную и софтовую) делать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Sergey Gilfanov Вам с @Ivan_83 пора определиться уже: "маршрутизатор" (Л3) или "коммутатор" (Л2) у вас между сетью клиента и сетью оператора?

Если маршрутизатор, то все становится понятно и предсказуемо, если коммутатор, то по мне - всё печально, администрировать внутренние сети абонентов за 3 копейки не выйдет .

 

А дальше проблемы только в том, как настроить файрвол на роутере клиента и что делать со скачущими сейчас по умолчанию адресами устройств с точки зрения администрирования, безопасности и файрволов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 минуты назад, Sergey Gilfanov сказал:

Выкидываем целый слой из стека протоколов.

Выкидываете вместе с VLAN, например? Как с ним быть?

Сейчас на каждый уровень модели OSI нужно разное количество ресурсов. Вы же предлагаете убрать L2, и запихать его функционал спомощью костылей в L3. Какую задачу это решит?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Только что, sdy_moscow сказал:

@Sergey Gilfanov Вам с @Ivan_83 пора определиться уже: "маршрутизатор" (Л3) или "коммутатор" (Л2) у вас между сетью клиента и сетью оператора?

Это потому что правильной терминологии нет. Речь идет о том, что сетевой адрес использовать и на уровне соединения железок. Те процедура "Какой ipv6 адрес в какой порт послать" может рассматриваться и как коммутация и как маршрутизация.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

6 минут назад, Sergey Gilfanov сказал:

Это потому что правильной терминологии нет. Речь идет о том, что сетевой адрес использовать и на уровне соединения железок. Те процедура "Какой ipv6 адрес в какой порт послать" может рассматриваться и как коммутация и как маршрутизация.

Администрировать как будем эту кашу? Или заменим все коммутаторы по всему миру на Л3 роутеры? Этак ИПв6 на сетях запустить удастся лет через 50, а ИПв4 УЖЕ не дают.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

9 минут назад, [anp/hsw] сказал:

Сейчас на каждый уровень модели OSI нужно разное количество ресурсов. Вы же предлагаете убрать L2, и запихать его функционал спомощью костылей в L3. Какую задачу это решит?

Смысл в том, что я совсем не уверен, что суммарные ресурсы в раздельные L2 и L3 меньше, чем весь функционал утолкать в L3.

 

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

Администрировать как будем эту кашу? Или заменим все коммутаторы по всему миру на Л3 роутеры?

Да. Разумеется, сильно не скоро. Я где-то там выше  говорил, что все это - это когда Ipv6 расползется по миру.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2422 год - в RIPE заканчиваются IPv6 адреса. Отныне лирам будет выдаваться только /120 подсеть.
А Вам не кажится, что возможен такой сценарий как сейчас с ipv4?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.