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

Carrier Grade NAT IPv6

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.

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
10 часов назад, Ivan_83 сказал:

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

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

 

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

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

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

 

Share this post


Link to post
Share on other sites
7 часов назад, sdy_moscow сказал:

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

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

Share this post


Link to post
Share on other sites
18 минут назад, Sergey Gilfanov сказал:

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

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

Share this post


Link to post
Share on other sites
Только что, [anp/hsw] сказал:

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

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

Share this post


Link to post
Share on other sites
4 минуты назад, Sergey Gilfanov сказал:

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

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

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

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

 

Share this post


Link to post
Share on other sites
13 минут назад, [anp/hsw] сказал:

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

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

Share this post


Link to post
Share on other sites
4 минуты назад, Sergey Gilfanov сказал:

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

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

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

 

Share this post


Link to post
Share on other sites
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" коммутатор. Вполне себе стандартный.

 

 

Share this post


Link to post
Share on other sites
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 там будет?

Share this post


Link to post
Share on other sites
12 часов назад, Ivan_83 сказал:

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

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

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

 

 

 

 

 

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

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

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

Share this post


Link to post
Share on other sites
Только что, [anp/hsw] сказал:

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

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

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

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

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

 

 

Share this post


Link to post
Share on other sites
Только что, Sergey Gilfanov сказал:

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

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

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

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

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

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

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

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

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

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

 

 

Share this post


Link to post
Share on other sites
43 минуты назад, [anp/hsw] сказал:

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

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

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

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

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

 

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

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

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

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

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

Share this post


Link to post
Share on other sites
42 минуты назад, Sergey Gilfanov сказал:

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

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

Share this post


Link to post
Share on other sites
40 минут назад, sdy_moscow сказал:

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

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

Share this post


Link to post
Share on other sites
11 минут назад, Sergey Gilfanov сказал:

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

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

Share this post


Link to post
Share on other sites
Только что, 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 сказал:

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites
3 минуты назад, Sergey Gilfanov сказал:

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

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

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

 

Share this post


Link to post
Share on other sites
Только что, sdy_moscow сказал:

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

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

Share this post


Link to post
Share on other sites
6 минут назад, Sergey Gilfanov сказал:

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

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

Share this post


Link to post
Share on other sites
9 минут назад, [anp/hsw] сказал:

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

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

 

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this