Комментарии 150
Я так понимаю, мы научились жить в условиях строжайшего дефицита ipv4 до такой степени, что их нехватка превратилась просто в технологическую сложность на разных уровнях.
IPv6 даёт возможности и убирает часть сложностей, перенося их на магистрали и фильтрующие точки. В теории, трансляции NAT превращены в более простые фильтры и allow/deny решения без необходимости вмешиваться в сам пакет. С одной стороны -- это даёт максимальную пиковую производительность магистралей с минимизацией задержи. Нефрагментируемость пакетов оттуда же растёт. Но как таковая фрагментация уже давно не нужна -- с поддержкой почти повсеместной jumbo фреймов и на 4м.
Что мы получаем на выходе? Так же как с IPv4 -- очень легко его сделать неправильно. Очень много даз банных надо обновлять (это касательно GeoIP -- эти базы всегда были низкой точности, но со временем всё точнее и точнее, 6ые базы только недавно собираются и начинаются с обычного "возьмём всё корнем а там будем думать")...
Айпикопалипсис всё ближе -- но мы очень хорошо оттягиваем его. Не в последнюю очередь за счет миграции больших потребителей.
В теории, трансляции NAT превращены в более простые фильтры и allow/deny решения без необходимости вмешиваться в сам пакет.
Дело не в простоте, дело в отсутствии состояния, и следовательно, возможности масштабирования. Можно на лету поставить вторую коробку, направить на нее часть трафика, и это будет работать без разрыва сессий, которые шли через первую. Подменять адреса и порты и инкрементально обновлять контрольную сумму нетрудно (врочем, спасибо, что в IPv6 ее убрали).
Фильтровать IPv6 сам по себе сложнее. Мои претензии как разработчика пакетного фильтра:
- Адреса IPv4 можно было векторными инструкциями обработать несколько за раз. Адреса IPv6 даже по одному лучше обрабатывать векторно. С адресами разрядностью больше шины данных неэффективно работать атомарно.
- Адресов условно бесконечное количество. В сочетании с предыдущим любые таблицы становятся огромными. Даже если речь о специальном оборудовании с CAM, этой дорогой памяти нужно много.
- В заголовке IPv4 прямо прописан протокол L4 смещение до его заголовка. В IPv6 нужно перебирать цепочку опций, которая может вообще закончиться ESP, то есть перебор был зря.
Но как таковая фрагментация уже давно не нужна — с поддержкой почти повсеместной jumbo фреймов и на 4м.
- Jumbo фреймы за пределами ДЦ? Фрагментация нужна протоколам, у которых нет MTU discovery.
- Фрагментация IPv6 есть в виде расширений. Не знаю, насколько широко применяется — только что поддерживается железом.
Адресов условно бесконечное количество. В сочетании с предыдущим любые таблицы становятся огромными. Даже если речь о специальном оборудовании с CAM, этой дорогой памяти нужно много.
И как же сейчас BGP с этим справляется?
Может, умные люди уже об этом подумали и делегируют подсети по /48 ?
Можно на лету поставить вторую коробку, направить на нее часть трафика, и это будет работать без разрыва сессий, которые шли через первую.
Да, но при этом мы теряем возможность прозрачно направить часть трафика клиента в другой канал. Условно, если мы хотим, чтобы трафик до какого-то сайта шёл через тоннель, а остальной трафик шёл напрямую — то с ipv6 это гораздо сложнее.
Непонятно, какие с этим проблемы именно от IPv6 и отсутствия состояния. Туннелю все равно, пакеты каких сессий по нему идут.
Проблемы тут идут от основного "преимущества" IPv6 — отсутствия NAT. Туннелю всё равно, а вот провайдеру после туннеля и локальному провайдеру — нет. Если в туннель ушёл пакет с адресом от локального провайдера — то он просто дропнется на выходе из туннеля дальним провайдером. А поскольку сами компьютеры о наличии нескольких путей ничего не знают — адреса они ставят какие попало.
А дальнему провайдеру не пополам какой обратный адрес у пакета?
Проверено — не пополам. И ближний провайдер пакеты к остальным сайтам, идущие по ipv6, но с некорректным обратным адресом, тоже рубит.
Проверял на связке туннель HE + локальный дом.ру.
Обычно не пополам, и пакет который обратно не может быть зароучен в канал с которого пришел подлежит дропу. Если только у вас нет спец договорённостей что тебе -- можно.
Цэ ж вопрос безопасности от тех же самых ботнетов и иже с ними.
Сейчас (IPv4) в туннель уходит пакет с src из блока локального провайдера, из его пула внешних адресов NAT. Будет (IPv6) — с src клиента из блока локального провайдера. В обоих случаях на выходе src маршрутизируемый, из блока локального провайдера. Если удаленный провайдер режет src не своего блока (BCP-38), в чем разница между IPv4 и IPv6?
Сейчас в туннель ipv4 пакет уходит с локальным адресом устройства, и на выходе из дальней стороны уже проходит NAT/masquerade, где получает в качестве src внешний адрес дальней стороны. И если он не нужен в туннеле — то маскарад проходит на локальном роутере и выдаётся адрес ближнего провайдера.
Но в ipv6 туннель он уходит с адресом из блока провайдера в качестве src, и не всегда — с нужным. Равно как и вне туннеля идущий ipv6 пакет может вылететь с некорректным адресом.
IPv6 NAT (полноценный, с заменой адресов) все же существует. Не рекомендуется к использованию, не так давно появился но… например RouterOS так может (потому что люди очень сильно дергали Mikrotik). Нужно например для Multi WAN если нет возможности свою ASN а решение с тем что внутрисетевое железо имеет IPv6-адреса сразу от двух провайдеров и невозможно нормально контролировать на роутере через кого пойдет трафик.
Да, это очень особое решение но оно все же есть если надо.
С другой стороны — получить свою /48 + ASN значительно проще (и дешевле) чем с IPv4 получить /24. А уж то что при желании можно на каждом чайнике поднять публично-доступный вебсервер с поддержкой rfc2324 — это очень хорошо.
Да, это очень особое решение. И в момент, когда пытаешься его реализовать, возникает вопрос — а зачем при этом ipv6, если мы выкинули его основное преимущество?
Получение своего ASN — это уже задачи для крупного бизнеса, и там вряд ли захотят поднимать вебсервер на чайнике. А для мелких компаний — это всё равно проблематично, да и не нужно им /24 обычно.
С другой стороны — получить свою /48 + ASN значительно проще (и дешевле) чем с IPv4 получить /24
получить asn может быть и просто, а вот договориться о bgp-пиринге с провайдерами может оказаться сложнее. а в случае резервного канала через 4g скорее невозможно.
Так IPv4 давно уже закончился. Всё что сейчас есть это жалкие остатки на перепродажу, да и многие уже привыкли к NAT-у и связанными с этим костылями. Надо сказать, и сам NAT настолько оброс костылями и технологиями...
Для этого есть дефолтное полиси deny
Звучит как предложение решать проблему косорукости разработчиков прошивок чайников на уровне сетевого протокола с помощью костыля, для этого вообще не предназначенного.
А причем здесь косорукость?
При том, что у каждого уважающего себя чайника должен быть whitelist тех, с кем ему разрешено общаться. И тогда проблема "нефиг сообщать всему миру" не возникнет.
Как я понимаю, без NAT вся локальная сеть доступна из интернета, правильно? Но зачем кому-то вне этой сети доступ к чайнику?
Нет, не правильно. Если на вашу локалку нарезано, скажем, /64 в SLAAC (что является рекомендуемой практикой для ipv6), то для этого кого-то вопрос выяснения даже просто IP адреса вашего чайника становится весьма нетривиальным.
При том, что у каждого уважающего себя чайника должен быть whitelist тех, с кем ему разрешено общаться. И тогда проблема «нефиг сообщать всему миру» не возникнет.
Да-да, удачи на каждом устройстве прописывать правила.
У вас дома настолько много чайников, что их настройка станет реальной трудоёмкой проблемой?
Я предлагаю вам не выдумывать несуществующую проблему либо указать, КОНКРЕТНО В ЧЁМ она состоит. С учётом вышесказанного про /64 и slaac.
Какую настройку и зачем её менять?
Кстати, а подключаете вы устройства в свою сеть, не настраивая их?
Какую настройку и зачем её менять?
Ну как же, тот самый вайтлист из «При том, что у каждого уважающего себя чайника должен быть whitelist тех, с кем ему разрешено общаться». А менять — ну потому что завтра я захочу еще дать кому-нибудь доступ к инфраструктуре.
Кстати, а подключаете вы устройства в свою сеть, не настраивая их?
Есть разница между «подключить один раз» и «настраивать вайтлисты на каждом устройстве вручную каждый раз»
Какой ещё "каждый раз"? Один раз при подключении (!) указать сеть из которой разрешены запросы. И нет разницы.
Ну как же, тот самый вайтлист из «При том, что у каждого уважающего себя
чайника должен быть whitelist тех, с кем ему разрешено общаться».
Это был ответ на гипотетическую ситуацию в сценарии с ipv4/NAT.
Какой ещё «каждый раз»? Один раз при подключении (!) указать сеть из которой разрешены запросы. И нет разницы.
Указал. Завтра хочу еще из одной сети разрешить запросы. Что делать?
Нормально планировать инфраструктуру.
«Завтра хочу» это не проблема версии протокола.
Давайте переформулирую. Офис в котором куча iot-тятины под потолком, светом рулит, штук сто девайсов. Допустим, устройства такие продвинутые, что умеют в списки доступа. В вайтлисте сеть офиса, все хорошо, настроили, работает.
Через год-два-три компания выросла, открываем новый офис, и нужна связность. Ваше предложение, как я понимаю, заключается в том, чтобы
Выглядит как фантазии человека, который кроме как в пределах домашней инфраструктры в десять девайсов и одну подсеть с сетью никогда не работал.
Мда.
Вы всерьёз предлагаете рассмотреть пример офиса, который освещается сотней независимых (видимо) IoT устройств, приписываете мне какой-то бред и называете это моими фантазиями.
Во-первых. Никто в здравом уме не будет так проектировать освещение. Нормальные люди возьмут какой-нибудь Wiren Board и сделают управление светом через него. С какими угодно настройками вайт и блэк-листов в одном удобном для конфигурирования месте.
Во-вторых, даже если кто-то ударился головой и решил таки повесить сотню отдельных смартлампочек, то под потолком лазить не нужно -- они же в сети. Конфигурай их сидя на рабочем месте ну или напиши скрипт, который делает провизионинг их всех сразу, если бюджет позволяет.
В-третьих, вы уже, как мне кажется, запутались в собственной аргументации. Потому что операция "добавить разрешённую сеть" выполняется в принципе одинаково что для ipv4, что для ipv6 и в чём поинт этого вашего примера -- неясно.
И не надо пытаться угадать, в чём у меня есть опыт, а в чём нет. Это бессмысленное и неблагодарное занятие.
Какие-то фантазии о вайтлистах на тупых устройствах с МК. С легкой руки которые обзаводятся конфигураторами этих вайтлистов по сети. Далее предложение писать какие-то скрипты, чтобы починить архитектурную проблему, которую вы предложили.
Потому что операция «добавить разрешённую сеть» выполняется в принципе одинаково что для ipv4, что для ipv6 и в чём поинт этого вашего примера — неясно.
Эм, ну, например, в том, что в ipv4 никому в голову не придет давать белые IP внутренним устройствам?
И не надо пытаться угадать, в чём у меня есть опыт, а в чём нет. Это бессмысленное и неблагодарное занятие.
Да, вы правы, сложно угадать, с чем вы работали в плане сетевой инфраструктуры — исключительно со смарт-тв и DIR300, или все-таки там был кинетик. Пожалуй не буду.
Давайте на этом закончим диалог, пожалуй. Ваша аргументация и ее уровень мне понятен, свои возражения я высказал, смысла убеждать вас в чем-то не вижу.
Эм, ну, например, в том, что в ipv4 никому в голову не придет давать белые IP внутренним устройствам?
ой да неужели. а как же
Через год-два-три открываем новый офис, и нужна связность.
Расскажите, будьте так любезны, как вы организуете связность нового офиса с сотней лампочек за NATом в старом? Судя по всему, у вас огромный опыт в такого рода проектах.
Ваша аргументация и ее уровень мне понятен,
Это да.
Мне до уровня офисного освещения из сотни отдельных смартлампочек ещё расти и расти...
PS: знаете, что лет десять назад про v6 прямым текстом (ЕМНИП, под запись) сказал Дима Кохманюк, который один из двух человек за .ua ccTLD и жил тогда примерно пополам между штатами и Киевом? Что которая по счёту истерика насчёт «конца v4» развязана в т.ч. Cisco, которым тупо надо новых продаж.
Я не знаком с этим человеком и почему его мнение для меня должно что-то значить вопреки объективным фактам — не понимаю, а вы объяснить не можете.
развязана в т.ч. Cisco, которым тупо надо новых продаж.
Зачем? Уже больше десяти лет как всё их железо умеет в IPv6, так что этот фактор при планировании бюджета на инфраструктуру на -надцатом месте.
Так нет же проблемы. Вместо Ната, вы просто настраиваете файрвол на маршрутизаторе. И из мира никто к вашим устройствам не сможет достучаться. То есть дефолтная настройка Ната, меняется на дефолтную настройку файрвола. Не совсем понимаю зачем вам тут рассказывают что надо вайтлиситы на устройствах ковырять. Для решения вашей задачи, чтобы добиться того же что и в ipv4 (невозможность обратиться к устройству из интернета) вам лишь надо в случае использования ipv6 добавить одно правило в файрвол маршрутизатора. И по идее при повсеместном использовании ipv6 это будет дефолтом, как сейчас дефолт нат.
Ну, там не одно, чуть больше, но ровно это я и сделал.
А теперь следите за руками.
Вот есть ubuntu.com из моего примера (на практике — абсолютно любой сайт). Вот его админ настроил ipv6 криво (или админ провайдера настроил криво роуты ipv6).
И всё. Сайт недоступен для пользователя, потому что если включен двойной стек ipv4+ipv6, недоступность сайта по ipv6 означает недоступность сайта вообще.
Вот что меня напрягло и сильно.
Т.е. вот она недвусмысленная точка отказа, которую я получаю в обмен на что?
Пока из комментариев получается, что в рамках домашней / SOHO сети никаких преимуществ я не получаю.
Разумеется, если мы говорим о варианте "нет дефицита IPv4-адресов". Пусть и пока.
Вот есть ubuntu.com из моего примера (на практике — абсолютно любой сайт)
Вы явно преувеличиваете масштаб проблем. Я уже писал, что двойной стек уже очень массово используется в сотовых сетях. Стонов пользователей не слышно.
Вроде бы в Азии есть даже ipv6-only сети.
Через год-два-три компания выросла, открываем новый офис, и нужна связность
С ip4 будто проще. Особенно если в одном из офисов серый ip. Будут поднимать VPN, тунеллировать трафик, прописывать маршруты на роутерах из одной локальной сети в другую, либо настраивать OSPF/EIGRP/RIP. И отдельное веселье если у нас адресация в локальной сети и первого и второго и третьего офиса совпадает. Если зайдёте в телеграмм-чатики где тусуются начинающие сисадмины, увидите, что там вопросы про то, как связать офисы и почему компы не из одной сети не видят другую задаются каждый божий день, а вы просто привыкли ко всему этому, знаете, что нужно настраивать, где и как подпирать NAT-костылями и делаете это на автомате, поэтому вам кажется это проще, чем настроить фаервол для ip6.
Будут поднимать VPN, тунеллировать трафик, прописывать маршруты на роутерах из одной локальной сети в другую, либо настраивать OSPF/EIGRP/RIP. И отдельное веселье если у нас адресация в локальной сети и первого и второго и третьего офиса совпадает.
Да не, я не говорю что на v4 все замечательно, и что v6 не нужен. Я просто спорю с тезисом «а вот щас мы щас перейдем на v6 и все сделаем доступным снаружи и все будет зашибись и может даже не надо будет умирать»
Я просто спорю с тезисом «а вот щас мы щас перейдем на v6 и все сделаем доступным снаружи и все будет зашибись
Честно говоря не видел в этой ветке такого утверждения. Никто не говорил, что нам нужно высунуть все наружу, никто не призывал отменить фаерволы. А вот отсутствие серых айпишников это на мой взгляд несомненный плюс, уже хотя бы потому, что можно будет избавиться от костылей которые необходимы, чтобы два устройства находящихся за натом могли установить соединение. А аргументы "за NAT" честно говоря выглядят как аргументы за то, чтобы всю жизнь ходить на костылях, там тоже свои плюсы есть – устойчивость на скользком асфальте лучше, и от хулиганов ими можно отбиваться.
Честно говоря не видел в этой ветке такого утверждения. Никто не говорил, что нам нужно высунуть все наружу, никто не призывал отменить фаерволы.
Да вон: «При том, что у каждого уважающего себя чайника должен быть whitelist тех, с кем ему разрешено общаться. И тогда проблема „нефиг сообщать всему миру“ не возникнет.»
Там сам пример с чайником странный, он почему-то приведён как плюс NAT, хотя регуляция доступа к "чайникам" это функционал фаервола, для ната это просто побочный эффект, который иногда срабатывает в плюс, хотя если чайник имеет UPnP то спокойно высунется себе в инет через NAT, если посчитает нужным, со всеми своими дырами. Вообще NAT в итоге сыграл с людьми злую шутку, многие настолько привыкли к побочке, что рассчитывают на неё, вместо того, чтобы делать как задумано — настраивать фаервол.
Стоп, всякая iot-яина может вполне следовать политике default deny для глобальных ipv6. Но откликаться на unique-local внутри сегмента сети (у вас же стоит пограничный маршрутизатор? Пусть объявляет префикс. Нет? Есть ещё Link-local...). Если iotятины мало - можно ручками ждать доступ из вне, если много - пожалуйста, управляй централизованно через контроллер
При том, что у каждого уважающего себя чайника должен быть whitelist тех, с кем ему разрешено общаться. И тогда проблема «нефиг сообщать всему миру» не возникнет.
Тогда да, косорукость. Хотя я вот почитал, локальные IPv6 адреса вполне заменяют эту функцию NAT.
Вопрос выяснения даже просто IP адреса вашего чайника становится весьма нетривиальным
Вот с этим поспорю. Это работает только если цель найти конкретное устройство, что ИМХО, не самый частый вариант атаки. А если атакуются все адреса, сложность выяснения конкретного значения не имеет
Какие все адреса атакуются?
Все несколько миллиардов или триллионов?
В ipv6 нет бродкаста.
тут просто два подхода:
верить, что просканировать N адресов невозможно и поэтому мы в безопасности;
знать, потому что вот этот блок адресов закрыт файрволлом.
P.S. я просто помню времена, когда с той же интонацией, что у вас про миллиарды или триллионы говорилось про взлом md5, например (я понимаю, что "взлом" не самый удачный термин, я про сам принцип).
При том, что у каждого уважающего себя чайника должен быть whitelist тех, с кем ему разрешено общаться. И тогда проблема «нефиг сообщать всему миру» не возникнет.
Это перенос проблемы с больной головы на ещё более больную. Перекладывать вопросы безопасности только лишь на конечные клиентские устройства, это никогда толком не работало, не работает, и уже и не заработает, к сожалению.
Я не стал раздувать заметку, хотя в качестве примеров просились IP-телефония и прочий WebRTC.
И там же, в примере, хотел написать, что сейчас NAT-T вполне себе работает.
Сам не настоящий сетевик, но стоял рядом с настоящим.
От него слышал, что проблема недоступности ubuntu.com по ipv6 - это проблема того, что гигантские AS до сих пор не могут договориться друг с другом о тарификации обмена трафиком, и фактически ipv6 интернет порван во многих местах. И через атлантику он порван прямо капитально.
серьёзно?
попробовал пинговать этот ubuntu.com с разных точек (россия, европа) — проблем нет.
я очень рад, что у вас нет проблем с пингом ubuntu.com. У меня были.
но я написал это всё не для того, чтобы пожаловаться на, возможно, временную недоступность ubuntu.com через ipv6.
Это просто пример, иллюстрирующий тезис "двойной стек ipv4+ipv6 не уменьшает количества проблем, а увеличивает их".
Я несколько удивлён, что сайт при этом не открывается. Мой опыт использования браузера с очень плохо настроенными сайтами говорит, что такое же бывает и с ipv4, когда один из прописанных адресов недоступен. Нажатие F5 пару раз заставляет браузер взять другой адрес и достучаться в итоге.
Я подобную проблему с ipv6 ловил на некоторых сайтах, когда mtu канала отличался от mtu, раздаваемого локальным устройствам. Что-то в фрагментации пакетов ломалось — и ответы сайта уже не могли собраться. После установки на маршрутизаторе в разделе ipv6 Neighbor Discovery правильного mtu — проблема решилась.
Да может просто админ ubuntu.com забанил подсеть HE из-за любителей поспамить или побрутить из неё. Так же, как многие банят подсети выходных айпишников Tor или даже некоторых VPN.
ipv6 по моим наблюдениям работает странно.
Дома он через Miredo настроен, на работе нативный от провайдерам и есть несколько vds в РФ и Европе. Где-то "с коробки", где то через брокер. И не раз наблюдал такую картину, что например с работы пропадает доступ к одному из vds, при этом домашний комп доступен и с него есть доступ к тому vds. Или наоборот, пропадает доступ к домашнему компу, в то время как есть до vds и с него есть доступ к домашнему компу. И такое наблюдал не раз в разных комбинациях, когда и vds между собой то доступны, то нет.
Как будто маршрутизация периодически рассыпается.
В IPv6 вроде как мультикаст изначально продумали с учётом вещания через интернет. Благодаря мультикасту любой стример сможет вещать напрямую своей аудитории и на сервисы отдавая один поток и не забивая канал до отказа. И как я понял мультикаст адреса сразу разделили флагом на два диапазона. Один регистрируется а второй свободный.
Мультикаст никак не поможет стримеру, если он работает не в режиме ТВ (когда все смотрят одно и то же, в одном и том же качестве, в одно и то же время, а не так, что сначала я включил ролик у себя на телефоне, а через секунду — жена на своём, причём оба смотрим сначала)
Стрим и предполагает что люди смотрят именно то что происходит в этот момент и общаются со стримером. Можно вещать несколько потоков в разном качестве благо адресного простраства на это хватит. Чат тоже кстати может по мультикасту работать.
Вы несете какую-то ересь. В глобальном интернете нет никакого мультикаста от слова совсем, неважно, ipv4 или ipv6, операторы им просто не обмениваются (за исключением каких-то местячковых случаев). Мультикаст существует только в пределах одного административного домена - одного оператора связи (например, для IPTV) или одной корпоративной сети.
В ipv4 -- да.
В ipv6 -- "Multicast groups aren’t constrained by local or global (network) geography. Whether the host is on the local network or on the internet, as long as it’s signaling to join a multicast group, it can receive multicast packets sent to that group." (https://www.menandmice.com/blog/ipv6-reference-multicast)
Ммм, статьи про ипв6 для домохозяек в качестве пруфа. Как это опровергает то, что я сказал про отсутствие обмена мультикаст трафиком между tier 1? Никак. То, что мультикаст-групп в ипв6 просто больше и вероятность их уникальности выше, никак мультикаст-интернет из воздуха не создаст.
Мультикаст - это полностью другой control plane по сравнению с юникастом, т.е. условно сложность администрирования сети при включении мультикаста увеличивается в 2 раза. Его локально в пределах своей сети то стараются не включать без крайней необходимости, и уж тем более операторы им не обмениваются между собой просто так "чтоб было"
Проверяю ipv6.google.com — работает, иду на ubuntu.com — не открывается ни в какую.
У меня оба хоста пингуются и открываются через ipv6, ЧЯДНТ?
Так первое, что я сделал — закрыл внешний доступ файрволлом, он мне может и нужен, но контролируемый и NAT-а для этого мне вполне хватает.
А почему внешний доступ нельзя контролировать без NAT?
Если их такой дефицит, они должны расти в цене, так? Однако они доступны
...
Что даёт ipv6, если нет дефицита ipv4?
Доступность не означает что они дешевеют.
Потому, что они таки дорожают. End-user'ам домой белую статику продают поштучно за 1-2€/mo, VDSам по 3€/mo в среднем и эта цена только растёт. Не быстро, но растёт.
Дефицит есть. Просто он ещё не опустился с уровня RIR'ов на уровень tier-3 операторов благодаря повсеместному распространению чумы NAT и тому, что начали дерибанить древние /8 и /16 диапазоны. Это неизбежно произойдёт, и к тому времени, когда каждая зажигалка станет IoE устройством, лучше бы нам иметь обкатанное и повсеместно доступное средство обеспечения связности сети.
Статьи "нахрена нужен IPv6" появляются на Хабре с завидной регулярностью, примерно 2-3 раза в год.
В прошлый раз я все релевантные соображения уже изложил тут, можете ознакомиться при желании
https://habr.com/ru/company/vasexperts/blog/508518/comments/#comment_24744586
и к тому времени, когда каждая зажигалка станет IoE устройством,
А чем зажигалке не подходит локальный IP-то?
Я не могу придумать и продумать заранее все возможные сценарии использования устройств в будущем.
Интернет ведь называется Интернетом именно потому, что он -- о межсетевой связности и избыточности. То есть о том, что каждый должен иметь возможность связаться с каждым, даже если где-то что-то порвалось.
А NAT фундаментально нарушает эту парадигму, и это приносит ряд неудобств лично мне прямо сейчас.
Например, когда я хочу захостить на домашнем сервере веб-сайт или dedicated server какой-нибудь игры, оно не работает из коробки, а приходится идти на роутер и делать там nftables-магию. Какого хрена? Чтобы торрент-клиент или там bitcoind/monerod в ipv4 у меня работал как следует, мне приходится поднимать на роутере upnp/igd. Когда я принимаю лабораторки у студентов по линуху, я не могу просто так взять и подключиться по ssh к его компу, чтобы посмотреть что там или помочь, нам приходится использовать опять же port forward, ngrok или что-то ещё. То есть, по факту, использовать костыли второго порядка для преодоления проблем, созданных костылями первого порядка.
Вы просто привыкли к тому, что NAT вас сношает и считаете это нормой.
Интернет не для этого придуман был. Поэтому NAT это зло, а IPv6 -- будущее.
Например, когда я хочу захостить на домашнем сервере веб-сайт или dedicated server какой-нибудь игры, оно не работает из коробки, а приходится идти на роутер и делать там nftables-магию. Какого хрена? Чтобы торрент-клиент или там bitcoind/monerod в ipv4 у меня работал как следует, мне приходится поднимать на роутере upnp/igd. Когда я принимаю лабораторки у студентов по линуху, я не могу просто так взять и подключиться по ssh к его компу, чтобы посмотреть что там или помочь, нам приходится использовать опять же port forward, ngrok или что-то ещё.
Так а в счастливом будущем IPv6 вам все равно придется идти на роутер и делать там магию по разрешению доступа к устройству.
Нет, зачем? Они по умолчанию смогут принимать входящие. Роутер будет только роутером, т.е. маршрутизировать пакеты.
Во-первых, вы занимаетесь подменой тезиса: "Разрешение доступа к устройству" предполагает, что на роутере сидит файрволл, рубящий всё кроме белого листа, а отфильтровать траффик на мелкий контроллер это задача штучная, единичная.
Во-вторых, вам известен способ выяснить ipv6 адрес мелкого контроллера? Что-то вы тщательно избегаете этого вопроса в нашей дискуссии.
Во-вторых, вам известен способ выяснить ipv6 адрес мелкого контроллера?
например, присоединиться к пулу ntp-серверов
И надеяться на то, что а) вашей потенциальной жертве вообще нужно ntp-время, и б) что она доберётся до вашего сервера в вашем пуле. Хороший план.
Да, если вам нужна конкретная жертва, то это неподходящий вариант.
А вот если вам просто нужен большой список потенциальных жертв, то всё становится интереснее.
в) у жертвы не работает privacy extension, поэтому она использует только один статичный адрес
Во-первых, вы занимаетесь подменой тезиса: «Разрешение доступа к устройству» предполагает, что на роутере сидит файрволл, рубящий всё кроме белого листа,
Ну так уже выяснили выше, что если у вас больше ноута-телефона-телевизора в сети, вам нужен фаервол на роутере, потому что вручную конфигурировать права доступа на каждом устройстве неудобно (не говоря уж о том, насколько легко найти фаервол, скажем, на умный телевизор с закрытой прошивкой). Ну или пусть они торчат в инет, ботнетов же не существует.
Во-вторых, вам известен способ выяснить ipv6 адрес мелкого контроллера? Что-то вы тщательно избегаете этого вопроса в нашей дискуссии.
Вы предлагаете безопасность через неясность? Типа, если адресов много, то никто его не найдет, не парьтесь?
Так вы напрасно надеетесь на /64. Подсеть у большинства пользователей будет одна, из этой подсети идет трафик, и адрес подсети несложно вычислить. Конечно, остается 6 байт MAC-а, но три из них как правило, остаются на совести производителя, и настоящим рандомом обладают лишь три, и у нас остается для перебора несколько диапазонов по 16м адресов, что уже не выглядит так внушительно, как целая /64.
А еще как бы сами устройства трафик генерируют. И этот трафик замечательно светится по всей цепочке сетевого оборудования с адресом получателя и отправителя. Сможете гарантировать что ни один из промежуточных провайдеров эти адреса не сольет никуда?
Сможете гарантировать что ни один из сервисов DNS/NTP/MQTT/любой общедоступный протокол не сольет адреса?
Сможете гарантировать что ни один конечный сервер не потеряет свои логи или бд устройств(подразумевается, что он может на эти устройства пушить данные, для чего ему нужен список актуальных IP)?
Ну так уже выяснили выше, что если у вас больше ноута-телефона-телевизора в сети, вам нужен фаервол на роутере
Это не так чтобы напрямую к теме относится, но, если уж на то пошло, я не имею ничего против файрволла на роутере в сетях ipv6. Я только против того, чтобы наследовать плохие практики там, где возможность им не следовать заложена в архитектуру.
и у нас остается для перебора несколько диапазонов по 16м адресов, что уже не выглядит так внушительно, как целая /64.
RFC 4941 вам в помощь.
Сможете гарантировать что ни один из промежуточных провайдеров эти адреса не сольет никуда?
Смогу. Если в стоимость взлома вашего мелкоконтроллера входит цена слива трафика с промежуточных провайдеров, то проблема перестаёт быть технической и становится организационной. И тогда вам никакой NAT не поможет в принципе.
Смогу. Если в стоимость взлома вашего мелкоконтроллера входит цена слива трафика с промежуточных провайдеров, то проблема перестаёт быть технической и становится организационной. И тогда вам никакой NAT не поможет в принципе.
А вы, простите, знаете, как ботнеты из роутеров организуют? Там тоже не то, чтобы в стоимость взлома каждого роутера входит написание экплоита для его софта. Нужен не мой роутер, нужен любой подходящий роутер. И как достаточно понятно, я очень не хочу, чтобы мой роутер/телевизор/комп/любое устройство оказались «подходящими».
RFC 4941 вам в помощь.
Опять же, гарантируете работу на любых устройствах? И даже если оно действительно будет работать, все еще остается сбор трафика.
А вы, простите, знаете, как ботнеты из роутеров организуют?
Знаю.
Ботнет будет башлять провайдеру за слив траффика потенциальной жертвы?
я очень не хочу, чтобы мой роутер/телевизор/комп/любое устройство оказались «подходящими».
см. выше про файрволл.
И кстати! Как это вы лихо с оконечных устройств перескочили на роутеры. Они ведь и сейчас в Интернет торчат, даже по ipv4. С этим у вас нет проблем, да?
Опять же, гарантируете работу на любых устройствах?
Я гарантирую работу на устройствах, которые я покупаю для своей сети.
Ботнет будет башлять провайдеру за слив траффика потенциальной жертвы?
Ботнет. Башлять. Провайдеру.
Ботнет это набор устройств, он никому ничего башлять не будет. Человек, заинтересованный в создании ботнета или взломе конкретных-пылесосов-с-камерой — да.
И кстати! Как это вы лихо с оконечных устройств перескочили на роутеры. Они ведь и сейчас в Интернет торчат, даже по ipv4. С этим у вас нет проблем, да?
У меня нет проблем, у меня все ненужное запрещено. Но речь не обо мне, речь в целом о влиянии на безопасность. И я как бы только что сказал что ботнеты организуют из роутеров — это и есть проблема. И это очень небольшая часть роутеров, потому что не у всех есть доступный снаружи адрес. А вы предлагаете раздать всем-всем устройствам публично доступные адрес, сначала увеличив поверхность атаки за счет доступа к тем же маршрутизаторам поголовно, а потом еще и добавив к возможным вариантам атаки все устройства в доме. Замечательно. Теперь не только роутер будет ботнетом, потому что на нем пять лет прошивку не обновляли, но еще и телевизор, пылесос, медиа-приставка, и так далее.
Я гарантирую работу на устройствах, которые я покупаю для своей сети.
А, ну, ясно. «У меня такая же нога и ничего не болит, а все остальное мне не важно и неинтересно, пусть хоть огнем горит»
Человек, заинтересованный в создании ботнета или взломе конкретных-пылесосов-с-камерой — да.
Ну тогда опять-таки см. выше про бюджет взлома. От той проблемы, через которую вы пытаетесь выстроить свою аргументацию, ни NAT ни файрволл не спасёт.
Замечательно. Теперь не только роутер будет ботнетом
...
А вы предлагаете раздать всем-всем устройствам публично доступные адрес
Нет, я не это предлагаю. Я предлагаю не использовать костыли, придуманные ради других костылей, которые были созданы для решения другой проблемы, чем та, которую вы ими решаете.
Я уже повторяюсь и мы, похоже, ходим по кругу.
Угроза ботнетизации вами преувеличена, и я уже выше намекнул почему, даже RFC назвал, написанный для решения конкретно указанной вами проблемы.
Сценарий массового подкупа магистралов владельцами ботнетов, извините, я всерьёз рассматривать не буду -- это компетенция правоохранительных органов, а не разработчиков протокола.
Сценарий массового подкупа магистралов владельцами ботнетов, извините, я всерьёз рассматривать не буду — это компетенция правоохранительных органов, а не разработчиков протокола.
О, узнаю сугубо теоретический подход: если наша замечательная идея не вписывается в реальный мир, где существуют ботнеты, уязвимости, глупые устройства, невнимательные пользователи, разработчики, пренебрегающие частью стандартов, странно организованные сети, и прочие интересные вещи, то мы просто скажем, что это мир/ботнеты/пользователи плохо пользуются нашей идеей, передайте им, пусть пользуются правильно. Менять красивую идею? Ой, право, зачем.
Я ничего из вами перечисленного не говорил и не утверждал -- вы опять приписываете мне какой-то выдуманный вами бред. Я только указал (в очередной раз), что вы пытаетесь в техническом споре использовать нетехнические аргументы.
Приведите известные примеры подкупа магистралов владельцами ботнета.
Если таковые есть -- я признаю вашу правоту во всём, отныне и присно.
Если таковых нет -- то тогда теоретик как раз вы, а не я.
>>Угроза ботнетизации вами преувеличена
Угроза преувеличена? Это не технический ответ. Наверняка разработчики которые дефолтные пароли на админку в роутерах, то же думали, да кто узнает.
Что будет если завтра чувак в больших очках придумает способ перебирать /64 за секунды, ну хорошо за минуты? Что ответят инженеры? Упс, вычеркиваем RFC 4941 из пула преимуществ? Давайте же всем миром думать как защитится?
И еще, захват и нахождение пограничных устройств становится первоочередной задачей и именно для упрощения нахождения адресов проходящих через устройство.
Думаю, если придумают способ хотябы перебора 64 битногр числа за секунду атаки на домашние сети покадутся мелочью. В тот момент падёт криптографиятпотвсему миру. И это... как бы сам сканер не испарился из-за высокой концентрации энергии. Делотв том что есть незыблемые законы физики, и количество необходимой энергии только лишь на перебор всех комбинаций 64 бит сопоставим с энергией содержащейся вот всей вмеленной. Так что тупой перебор адресов точно не будет практиковаться, будут лишь атаки на ГПСЧ которые генерируют внутренние адреса. А тут такое дело... добавив чуток соли мы нарушаемтвсе планы атакующего. В итоге простая защита становится в миллионы раз дешевле атаки и атака просто теряет смысл.
Делотв том что есть незыблемые законы физики, и количество необходимой энергии только лишь на перебор всех комбинаций 64 бит сопоставим с энергией содержащейся вот всей вмеленной.
Эээ, простите, что?
2^64 = 18 446 744 073 709 551 616
Вы хотите сказать, что я принципиально не могу постучаться в каждый? Могу. Берем ботнет из миллиарда хостов, на проверку каждого адреса тратим 100мс, и нам надо 2^64/(10*1000000000*60*60*24*365) = 58,49 лет на перебор. Долго. Реально не применимо. Но никакой энергией вселенной там и не пахнет даже близко.
С чего вы взяли, что придуман будет полный перебор? Смысл чего-то придумать - как раз ускорения процесса относительно него. Даже в соседнем треде показали, что достаточно перебора нескольких десятков миллионов по MAC-адресу, что уже вполне осуществимо, с какими-нибудь придумками объем уменьшится еще на порядки.
> вы пытаетесь в техническом споре
> использовать нетехнические аргументы
:D
(вытирая слёзы: ох, дядьки уже кто за тридцать, кто за сорок — а проблемы всё те же, что и в горшковой группе; правда, если человек и впрямь до сих пор на Владимирской, то остаётся лишь пособолезновать и пожелать хотя бы неухудшения психической устойчивости)
Что будет если завтра чувак в больших очках придумает способ перебирать /64 за секунды, ну хорошо за минуты? Что ответят инженеры?
Если это произойдёт, то устойчивость адресов к перебору станет наименьшей из возникших проблем.
Так как это вопрос из разряда "что будет если завтра чувак изобретёт антигравитацию".
Природу обмануть нельзя. Математику -- тоже нельзя.
Если факты противоречат моей теории, тем хуже для фактов
Георг Вильгельм Фридрих Гегель
Вы предлагаете безопасность через неясность? Типа, если адресов много, то никто его не найдет, не парьтесь?
Почему вы продолжаете игнорировать тот факт, что запрет подключений из интернета к вашим устройствам запрещается простым правилом файрвола, также как и одной строкой настраивается правила для NAT. В плане количества правил тут вообще нет особых различий.
Это ничем не хуже NAT. Но при этом избавляет от conntrack и всех других костылей которые идут вместе с натом (например способы сохранения source ip клиента и так далее)
От conntrack всё же не избавляет, так как нужно пропускать обратные пакеты. От conntrack IPv6 освобождает не клиентов, а провайдеров, если им достаточно stateless фильтров на входящий трафик.
Почему вы продолжаете игнорировать тот факт, что запрет подключений из интернета к вашим устройствам запрещается простым правилом файрвола, также как и одной строкой настраивается правила для NAT. В плане количества правил тут вообще нет особых различий.
Я? Игнорировать? Да я это в самом начале диалога написал: «Так это полиси все равно придется где-то задавать на граничном маршрутизаторе. Раньше были правила forward port from to, а сейчас deny all, allow ports… По сложности столько же, только адресация чуть удобнее стала, нет маппинга портов.»
v6 лучше, я с этим и не спорю. Но вот от граничных роутеров с фаерволами он совсем не избавляет.
Ну вроде никто и не обещал избавляться от маршрузитаторов и файрволов. Но избавление от ната сильно улучшает ситуацию как по мне.
И все таки ты можешь при желании выставить свою домшнюю машинку полностью в интернет, когда например тебе нужно случайные порты слушать. Ты просто разрешающее правило добавляешь для конкретной машины
В nat'е же тебе придется пробрасывать только конкретный список портов. А если у тебя еще одна машинка есть, и список портов между ними пересекается. То всё, приехали.
Во многих кейсах и dhcp становиться не нужен
один из уровней эшелонированной защиты, который простымтспособом в милоионы раз усложняет проведение атаки в лоб. С другой стороны, достаточно одного троянца, который тупо изнутри сдаст все внутренние адреса атакующему.
А что, security by obscurity уже стало хорошей практикой?
А чем любая железка, торчащая голой жопой в интернет, отличается от роутера? Роутер ведь такая же железка.
У вас дверь в квартиру тоже наверное выходит в общественное пространство (в подъезд), вы ж наверное ее закрываете?) Или из подъезда никто не проникнет?)
2)Роутер лучше защищен, чем среднее устройство. По крайней мере, нормальные роутеры предполагают что их могут попробовать взломать извне и закрывают на WAN все потенциально-уязвимое, дольше обновляют прошивки, хотя бы в виде safety-update (чего не скажешь о умных телевизорах, например), и так далее.
3)Даже если он защищен так же, я предпочту одно устройство с шансом взлома Х, чем пять устройств с таким же шансами взлома у каждого.
Все три пункта - default deny на global ipv6 должно быть, но это уже вопрос у вендору, а многие из производителей те ещё косячники и озвученной проблемы не будет, и из локальной сети связь оставлять в рамках локального, не маршрутизируемого префикса.
Да и вообще, можно наверное, в рамках объявленного роутером глобального префикса не блочить связь с устройством, ну для тех кто в одной с ним сети
и NAT, и IPv6 — технологии.
вся ваша аргументация и здесь, и по ссылке, которую вы привели строится вокруг двух тезисов:
NAT это зло, а IPv6 -- будущее.
всё отлично работает в идеальном мире.
Только Nat ещё и костыль, который возник, когда появилась необходимость выпускать много клиентов через малое число IP-адресов.
Я привёл конкретные примеры, когда NAT создаёт проблемы, которые просто не возникли бы в IPv6 сетях.
Ну не считайте уже других априори глупее или неопытнее себя — сами-то, поди, за клоуна голосовали? Вот то-то и оно.
Вам привели конкретные примеры проблем, созданных v6 и просто не возникающих в v4-сетях (да, с NAT)
Где привели? дайте ссылку на комментарий с этими примерами, пожалуйста.
Ну не считайте уже других априори глупее или неопытнее себя
Я-то не считаю. Они, видимо, сами так считают, упоминая проблемы, решения для которых не просто существуют, а даже уже стандартизированы.
У меня оба хоста пингуются и открываются через ipv6, ЧЯДНТ?
полагаете, что раз УМВР, то и у всех так. К сожалению, это не так. Тем более в плане сетевой связности в интернете.
Ну и это просто пример, иллюстрирующий тезис "двойной стек ipv4+ipv6 не уменьшает количества проблем, а увеличивает их".
Смотрите, реальная ситуация, ресурс доступен по ipv4 и недоступен по ipv6.
Что это значит для пользователя на практике? Ресурс недоступен.
А почему внешний доступ нельзя контролировать без NAT?
Неудачная формулировка. Я хотел сказать, что мне нужен вариант "всё закрыто по умолчанию, внешний доступ открываю я и очень выборочно".
Доступность не означает что они дешевеют.
Я и не говорил, что они дешевеют. Я привёл два примера ограниченных ресурсов и указал на то, что динамика роста цены отличается весьма значительно.
Старым не хватает памяти. Новые — дорого.
Потому большинство провайдеров просто тратит больше усилий на 4 и 6 может работать или нет.
В теории маршрутизация должна была работать по префиксам адреса. На практике — каждый имеет 100500 разных приоритетов по цене или провайдеров, и минимальный путь — не основная метрика.
Точно по той же причине не взлетели супер-самолеты на 200 человек. Да, в теории выгодно — на практике никто не хочет работать через один аеропорт.
Но все равно рано или поздно все перейдем на ipv6, выбора особо нету.
а, при всё моём скептицизме, не могу не заметить, что ipv6 таки внедряется.
на мелких vps цена ip-адреса соспоставима с ценой самой vps, и брать ipv6-only vps стало осмысленным. да, есть проблемы (хотя бы дефолтные репозиториии докера и гитхаба не имеют ipv6-адресов), но с трэшем «ubuntu.com не пингуется» я не встречался.
и не слышно шума, но в мобильных сетях (и в РФ тоже) всё шире используется ipv6. десятки миллионов телефонов (а в мировом масштабе, наверное, миллиарды) получили реальные адреса. и всё просто работает.
ну так я и не говорю, что "ipv6 не нужен".
Нужность никто не оспаривает, мне привели уже минимум два примера, когда он прямо на своём месте:
магистральные сети;
Яндекс.Облако внутри на 100% IPv6. Ибо размер 10.0.0.0/8 далеко не так велик, как может показаться.
мой спич был о том — готов ли ~линукс для десктопа~ ipv6 для домашнего использования.
пока по ощущениям, скорее нет, чем да.
P.S. а сколько стоит ipv6-only vps?
мой спич был о том — готов ли ~линукс для десктопа~ ipv6 для домашнего использования.
пока по ощущениям, скорее нет, чем да.
мой опыт говорит об обратном. домру, посмотрел на даты конфигов, судя по всему, настроил ipv6 в феврале 2016-го.
с самого начала были единичные проблемы (уже не вспомню все детали, но мысли отказаться от dual stack были), последние же лет пять всё просто работает.
P.S. а сколько стоит ipv6-only vps?
ну, например у iphoster минимальная ipv6-only vps стоит 1.95$ против 2.95$ на первый месяц и 3.95$ в дальнейшем.
Так я это слышу с того самого 2010.
Потому что ipv6 выдавливается пока в мобильные сети. Можно найти информацию, что у T-Mobile, ряда индийских провайдеров, сети уже v6 only. С тунелированием в v4 конечно. Но факт остаётся фактом: На всех v4 адресов уже не хватает.
это понятно. То, что никуда мы от ipv6 не денемся — тоже понятно.
Мой вопрос звучал так — в чём плюс внедрения ipv6 в условиях, когда дефицита ipv4 нет?
Пока все примеры, которые я видел, и которые выглядят очень убедительно (включая ваш, да) звучат как "не для домашней / SOHO сети"
ну так дефицит IPv4 адресов есть. Его не видно рядовому домашнему пользователю потому что у него не белый IP и сидит он за провайдерским NAT. Как только стоимость аренды IPv4 блоков для провайдера станет значительной он как миленький переведёт абонентов на IPv6.
Ну вот я рядовой домашний пользователь.
У меня два провайдера, оба выдают вполне себе белые IPv4.
У VPS, которую я арендую за 3 евро в месяц тоже вполне себе белый IP, можно докупить дополнительные по цене 2 евро за штуку.
На работе если нужно докупить IP-адресов -- тоже без проблем за какие-то копейки.
Т.е. дефицит-то вроде как есть, число конечное и все уже розданы.
Но на практике столкнуться с ним практически не получается.
А теперь загуглите динамику изменения цены на /24 префикс. Там конечно не биткоин, но цена растёт. Фактически сейчас новых блоков совсем нет. Теперь уже есть биржи, где те кто не пользуются продают свои блоки тем кому надо. Именно биржи, так что цена там вполне себе биржевая.
так я в заметке, собственно, ровно то же самое и написал (но несколько с другим посылом).
Вроде бы ресурс конечный, вроде бы всё, кончился уже десять лет как (точно не помню, по плюс/минус), а цена растёт не так, чтобы очень заметно.
Судя по комментариям, ipv6 штука нужная (что, в целом, сомнению и не подвергалась), но скорее нишевая (магистрали, специфические ДЦ и т.п.).
Я скорее согласен с одним из комментаторов, что решение это просто решение не для последней мили.
Диктую комментарий голосом на Маке, Siri распознала "IPv6" как "пиво и секс"
Может, в этом проблема?
Если экстраполировать график гугла https://www.google.ru/intl/en/ipv6/statistics.html прямой линией то до полного перехода на ipv6 примерно 10 лет, но вероятно в реальности линия не будет прямой, а вот какой точно сложно сказать.
Как-то все забыли, чтотна заре IPv4 были те же "по адресу для каждой лампочке" и тогда думали что 32 бит адресов должно хватить всем... ан нет, не хватило. И ещё задолго до проникновения IOT даже не в каждый дом.
1 января было 40 лет практическому использованию TCP/IP, мы каждое десятилетие празднуем юбилей и как раз обсуждаем тематику "ipv6 в массы". И я уже лет двадцать транслирую мысль, что ipv6 для последней мили и, особенно, для физлиц - сущность ненужная.
Что не отменяет прекрасную возможность использовать его в любых оверлейных технологических решениях, требующих адресации - и тот же SRv6 вполне себе пошел в магистралов, и даже для технического почтового адреса ipv6 подходит неплохо, тут на хабре недавно тему активно крутили в комментариях к посту про извилистость почтовых адресов.
А в последнюю милю - не надо, незачем.
Очень забавно конечно в качестве довода читать что какая-то база GeoIP (что в принципе не возможно) определяет не правильно город.
Наверное автор даже не слышал про anycast анонсы, когда один и тот же префикс можно заанонсить в разных городах, которые находятся в разных регионах и под управлением разных RIR.
Типичное еженедельное/ежемесячное нытье о том, что v6 не нужен, он усложнен, он все всем сломает, нам нужно будет что-то лишнее жмякать... Причем даже не разбираясь в вопросе про чайники и зажигалки, которые будут подключены к домашнему роутеру, у которого по дефолту, даже для v6, будет прописан reject в input-chain.
Мне кажется, или ipv6 переоценён?