Заголовок вышел кликбейтный, конечно, но я действительно задался этим вопросом.
Ретроградом себя чувствовать неприятно, но тем не менее…
Краткая предыстория. Году так в 2010-м, когда я только узнал об ipv6, я изучил всё, что тогда было доступно, развернул его в небольшой локальной сети, чтобы потрогать руками, попробовал подключить туннельного брокера (но довольно быстро отключил, т.к. сайты стали считать, что я нахожусь в Нидерландах, а менять геопозицию руками мне довольно быстро надоело) и стал с нетерпением ждать, когда же, ну когда же мой провайдер начнёт раздавать ipv6!
Прошло довольно много времени. Недавно я снова проверил — как там дела у провайдера и увидел, что да, в колхозный сельсовет пришло электричество провайдер начал выдавать ipv6-адреса.
И тут я выяснил две вещи:
GeoIP считает, что я нахожусь в Москве (а не в этом моём Улан-Удэ);
я благополучно забыл практически всё, что знал по теме.
Что ж, настроив по минимуму файрволл, начал разбираться.
Проверяю ipv6.google.com — работает, иду на ubuntu.com — не открывается ни в какую.
Ну, я опытный камикадзе, делаю curl -4 ubuntu.com — работает. Т.е. через IPv4 работает, через IPv6 — нет.
И вот на этом месте у меня и возник вопрос из заголовка.
Смотрите.
Я понимаю, что проблема с ubuntu.com — это не проблема технологии, а просто кривой маршрут где-то от меня до, собственно, сервера. Всё так.
Но!
Получается, что я получил дополнительную точку отказа, так?
Что же я получил взамен?
И вот тут у меня нет внятного ответа.
У любого устройства у меня в квартире будет свой ipv6-адрес и до него будет можно достучаться из интернета?
Так первое, что я сделал — закрыл внешний доступ файрволлом, он мне может и нужен, но контролируемый и NAT-а для этого мне вполне хватает.
У пакета ipv6 возможен больший пэйлоад, чем у ipv4?
Так это нивелируется тем, что ipv6 не фрагментируется, всё равно размер упирается в MTU на оборудовании провайдера.
ipv4-адреса скоро закончатся?
Так я это слышу с того самого 2010.
Если их такой дефицит, они должны расти в цене, так? Однако они доступны и если сравнить динамику роста цены ipv4-адреса и цены биткоина (могу ошибаться, но кажется он примерно тогда же появился), то это какие-то очень разные динамики выходят.
У меня стойкое ощущение, что я что-то упускаю.
Что я чего-то не вижу.
Что даёт ipv6, если нет дефицита ipv4?
P.S. понимаю, что тут просто просится ответ в духе "значит вам это не нужно". Так я и пытаюсь понять — а кому это нужно?
Комментарии (113)
Alexeyslav
18.01.2023 18:27+3Так IPv4 давно уже закончился. Всё что сейчас есть это жалкие остатки на перепродажу, да и многие уже привыкли к NAT-у и связанными с этим костылями. Надо сказать, и сам NAT настолько оброс костылями и технологиями...
aploskov
18.01.2023 18:58+10Надо сказать, что NAT ещё и пользу имеет.
Ибо нефиг каждому чайнику сообщать всему миру "HTTP 418 I'm a teapot", ибо чайники теперь дырявые и любят собираться в альянсы и грабить корованы.
Huawei со своим NewIP весьма хорош на самом деле, ибо чайник не должен хостить что-то всему интернету, пока не наберет квалификацию.
datacompboy
18.01.2023 19:12+2Для этого есть дефолтное полиси deny
vvzvlad
19.01.2023 02:01Так это полиси все равно придется где-то задавать на граничном маршрутизаторе. Раньше были правила forward port from to, а сейчас deny all, allow ports… По сложности столько же, только адресация чуть удобнее стала, нет маппинга портов.
select26
19.01.2023 11:21По сложности совершенно разные вещи!
Port forwarding - это connection tracking со всеми прелестями: таблица соединений, таймауты и т.п.
A deny - просто deny. Безо всяких дополнительных ресурсов. Lightweight вариант по сравнения с port forwarding.vvzvlad
19.01.2023 19:26По сложности работы внутри роутера — да, разница есть. По сложности конфигурации пользователем — ну, в целом примерно так же.
DreamingKitten
19.01.2023 00:08Звучит как предложение решать проблему косорукости разработчиков прошивок чайников на уровне сетевого протокола с помощью костыля, для этого вообще не предназначенного.
Vizmaros
19.01.2023 01:43+2А причем здесь косорукость? Как я понимаю, без NAT вся локальная сеть доступна из интернета, правильно? Но зачем кому-то вне этой сети доступ к чайнику? Я могу понять если это логи или подключение от владельца, включающего чайник заранее из машины, но ИМХО, это должно быть РАЗРЕШЕНО из самой локальной сети. Хотя-бы самим чайником для доступа к серверам производителя. В иных случаях устройствам вне дома доступ к чайнику не нужен
DreamingKitten
19.01.2023 01:56-3А причем здесь косорукость?
При том, что у каждого уважающего себя чайника должен быть whitelist тех, с кем ему разрешено общаться. И тогда проблема "нефиг сообщать всему миру" не возникнет.
Как я понимаю, без NAT вся локальная сеть доступна из интернета, правильно? Но зачем кому-то вне этой сети доступ к чайнику?
Нет, не правильно. Если на вашу локалку нарезано, скажем, /64 в SLAAC (что является рекомендуемой практикой для ipv6), то для этого кого-то вопрос выяснения даже просто IP адреса вашего чайника становится весьма нетривиальным.
vvzvlad
19.01.2023 02:02+3При том, что у каждого уважающего себя чайника должен быть whitelist тех, с кем ему разрешено общаться. И тогда проблема «нефиг сообщать всему миру» не возникнет.
Да-да, удачи на каждом устройстве прописывать правила.DreamingKitten
19.01.2023 02:06-2У вас дома настолько много чайников, что их настройка станет реальной трудоёмкой проблемой?
vvzvlad
19.01.2023 02:09+1Ну, эм, только 30 устройств зигби, еще десяток-другой остальных в wifi. Зигби мог быть теоретически в виде Thread, c ipv6. Вы предлагаете мне проходиться по всем этим устройствам и что-то там конфигурировать, если я хочу поменять правила?
DreamingKitten
19.01.2023 02:23-3Я предлагаю вам не выдумывать несуществующую проблему либо указать, КОНКРЕТНО В ЧЁМ она состоит. С учётом вышесказанного про /64 и slaac.
vvzvlad
19.01.2023 02:24+1Ээээ, в том, что мне не хочется менять одну и ту же настройку на 50 устройствах?
DreamingKitten
19.01.2023 02:26Какую настройку и зачем её менять?
Кстати, а подключаете вы устройства в свою сеть, не настраивая их?
vvzvlad
19.01.2023 02:28+1Какую настройку и зачем её менять?
Ну как же, тот самый вайтлист из «При том, что у каждого уважающего себя чайника должен быть whitelist тех, с кем ему разрешено общаться». А менять — ну потому что завтра я захочу еще дать кому-нибудь доступ к инфраструктуре.Кстати, а подключаете вы устройства в свою сеть, не настраивая их?
Есть разница между «подключить один раз» и «настраивать вайтлисты на каждом устройстве вручную каждый раз»
DreamingKitten
19.01.2023 02:36Какой ещё "каждый раз"? Один раз при подключении (!) указать сеть из которой разрешены запросы. И нет разницы.
Ну как же, тот самый вайтлист из «При том, что у каждого уважающего себя
чайника должен быть whitelist тех, с кем ему разрешено общаться».Это был ответ на гипотетическую ситуацию в сценарии с ipv4/NAT.
vvzvlad
19.01.2023 02:37+1Какой ещё «каждый раз»? Один раз при подключении (!) указать сеть из которой разрешены запросы. И нет разницы.
Указал. Завтра хочу еще из одной сети разрешить запросы. Что делать?
Vizmaros
19.01.2023 03:38+2В моем вопросе не было про настройку конкретного чайника, а ограничение на доступ к нему с стороны Интернета. Соответственно и WhiteList мне кажется необходимо настраивать для всей сети. А вот зачем DreamingKitten предлагает в подобной ситуации настраивать этим способом каждый чайник, я не совсем понимаю, поскольку правила идентичны для всей сети, проще использовать принцип DRY
DreamingKitten
19.01.2023 03:38-2Нормально планировать инфраструктуру.
«Завтра хочу» это не проблема версии протокола.
vvzvlad
19.01.2023 03:46+1Ахахах, смешно, смешно.
Давайте переформулирую. Офис в котором куча iot-тятины под потолком, светом рулит, штук сто девайсов. Допустим, устройства такие продвинутые, что умеют в списки доступа. В вайтлисте сеть офиса, все хорошо, настроили, работает.
Через год-два-три компания выросла, открываем новый офис, и нужна связность. Ваше предложение, как я понимаю, заключается в том, чтобыпредусмотретьпредвидеть это заранее и добавить нужную подсеть, а если предвидеть не смогли, то вы просто не смогли «нормально спланировать инфраструктуру», сами себе злобные буратины и ползайте под потолком, настраивая сотню устройств, я правильно понимаю?
Выглядит как фантазии человека, который кроме как в пределах домашней инфраструктры в десять девайсов и одну подсеть с сетью никогда не работал.
DreamingKitten
19.01.2023 04:07Мда.
Вы всерьёз предлагаете рассмотреть пример офиса, который освещается сотней независимых (видимо) IoT устройств, приписываете мне какой-то бред и называете это моими фантазиями.
Во-первых. Никто в здравом уме не будет так проектировать освещение. Нормальные люди возьмут какой-нибудь Wiren Board и сделают управление светом через него. С какими угодно настройками вайт и блэк-листов в одном удобном для конфигурирования месте.
Во-вторых, даже если кто-то ударился головой и решил таки повесить сотню отдельных смартлампочек, то под потолком лазить не нужно -- они же в сети. Конфигурай их сидя на рабочем месте ну или напиши скрипт, который делает провизионинг их всех сразу, если бюджет позволяет.
В-третьих, вы уже, как мне кажется, запутались в собственной аргументации. Потому что операция "добавить разрешённую сеть" выполняется в принципе одинаково что для ipv4, что для ipv6 и в чём поинт этого вашего примера -- неясно.
И не надо пытаться угадать, в чём у меня есть опыт, а в чём нет. Это бессмысленное и неблагодарное занятие.
vvzvlad
19.01.2023 04:18Ну, в общем, уровень понятен. Предлагаю модельную ситуацию, мне начинают говорить, что так не будет, а будет по другому, поэтому на первоначальный вопрос смысла отвечать нет.
Какие-то фантазии о вайтлистах на тупых устройствах с МК. С легкой руки которые обзаводятся конфигураторами этих вайтлистов по сети. Далее предложение писать какие-то скрипты, чтобы починить архитектурную проблему, которую вы предложили.Потому что операция «добавить разрешённую сеть» выполняется в принципе одинаково что для ipv4, что для ipv6 и в чём поинт этого вашего примера — неясно.
Эм, ну, например, в том, что в ipv4 никому в голову не придет давать белые IP внутренним устройствам?И не надо пытаться угадать, в чём у меня есть опыт, а в чём нет. Это бессмысленное и неблагодарное занятие.
Да, вы правы, сложно угадать, с чем вы работали в плане сетевой инфраструктуры — исключительно со смарт-тв и DIR300, или все-таки там был кинетик. Пожалуй не буду.
Давайте на этом закончим диалог, пожалуй. Ваша аргументация и ее уровень мне понятен, свои возражения я высказал, смысла убеждать вас в чем-то не вижу.
DreamingKitten
19.01.2023 04:27Эм, ну, например, в том, что в ipv4 никому в голову не придет давать белые IP внутренним устройствам?
ой да неужели. а как же
Через год-два-три открываем новый офис, и нужна связность.
Расскажите, будьте так любезны, как вы организуете связность нового офиса с сотней лампочек за NATом в старом? Судя по всему, у вас огромный опыт в такого рода проектах.
Ваша аргументация и ее уровень мне понятен,
Это да.
Мне до уровня офисного освещения из сотни отдельных смартлампочек ещё расти и расти...
identw
19.01.2023 11:10+1Так нет же проблемы. Вместо Ната, вы просто настраиваете файрвол на маршрутизаторе. И из мира никто к вашим устройствам не сможет достучаться. То есть дефолтная настройка Ната, меняется на дефолтную настройку файрвола. Не совсем понимаю зачем вам тут рассказывают что надо вайтлиситы на устройствах ковырять. Для решения вашей задачи, чтобы добиться того же что и в ipv4 (невозможность обратиться к устройству из интернета) вам лишь надо в случае использования ipv6 добавить одно правило в файрвол маршрутизатора. И по идее при повсеместном использовании ipv6 это будет дефолтом, как сейчас дефолт нат.
StraNNicK Автор
19.01.2023 11:18Ну, там не одно, чуть больше, но ровно это я и сделал.
А теперь следите за руками.
Вот есть ubuntu.com из моего примера (на практике — абсолютно любой сайт). Вот его админ настроил ipv6 криво (или админ провайдера настроил криво роуты ipv6).
И всё. Сайт недоступен для пользователя, потому что если включен двойной стек ipv4+ipv6, недоступность сайта по ipv6 означает недоступность сайта вообще.
Вот что меня напрягло и сильно.Т.е. вот она недвусмысленная точка отказа, которую я получаю в обмен на что?
Пока из комментариев получается, что в рамках домашней / SOHO сети никаких преимуществ я не получаю.
Разумеется, если мы говорим о варианте "нет дефицита IPv4-адресов". Пусть и пока.
edo1h
19.01.2023 13:24Вот есть ubuntu.com из моего примера (на практике — абсолютно любой сайт)
Вы явно преувеличиваете масштаб проблем. Я уже писал, что двойной стек уже очень массово используется в сотовых сетях. Стонов пользователей не слышно.
Вроде бы в Азии есть даже ipv6-only сети.
M_AJ
19.01.2023 05:35Через год-два-три компания выросла, открываем новый офис, и нужна связность
С ip4 будто проще. Особенно если в одном из офисов серый ip. Будут поднимать VPN, тунеллировать трафик, прописывать маршруты на роутерах из одной локальной сети в другую, либо настраивать OSPF/EIGRP/RIP. И отдельное веселье если у нас адресация в локальной сети и первого и второго и третьего офиса совпадает. Если зайдёте в телеграмм-чатики где тусуются начинающие сисадмины, увидите, что там вопросы про то, как связать офисы и почему компы не из одной сети не видят другую задаются каждый божий день, а вы просто привыкли ко всему этому, знаете, что нужно настраивать, где и как подпирать NAT-костылями и делаете это на автомате, поэтому вам кажется это проще, чем настроить фаервол для ip6.
vvzvlad
19.01.2023 19:29Будут поднимать VPN, тунеллировать трафик, прописывать маршруты на роутерах из одной локальной сети в другую, либо настраивать OSPF/EIGRP/RIP. И отдельное веселье если у нас адресация в локальной сети и первого и второго и третьего офиса совпадает.
Да не, я не говорю что на v4 все замечательно, и что v6 не нужен. Я просто спорю с тезисом «а вот щас мы щас перейдем на v6 и все сделаем доступным снаружи и все будет зашибись и может даже не надо будет умирать»
M_AJ
19.01.2023 21:33+2Я просто спорю с тезисом «а вот щас мы щас перейдем на v6 и все сделаем доступным снаружи и все будет зашибись
Честно говоря не видел в этой ветке такого утверждения. Никто не говорил, что нам нужно высунуть все наружу, никто не призывал отменить фаерволы. А вот отсутствие серых айпишников это на мой взгляд несомненный плюс, уже хотя бы потому, что можно будет избавиться от костылей которые необходимы, чтобы два устройства находящихся за натом могли установить соединение. А аргументы "за NAT" честно говоря выглядят как аргументы за то, чтобы всю жизнь ходить на костылях, там тоже свои плюсы есть – устойчивость на скользком асфальте лучше, и от хулиганов ими можно отбиваться.
vvzvlad
20.01.2023 02:37Честно говоря не видел в этой ветке такого утверждения. Никто не говорил, что нам нужно высунуть все наружу, никто не призывал отменить фаерволы.
Да вон: «При том, что у каждого уважающего себя чайника должен быть whitelist тех, с кем ему разрешено общаться. И тогда проблема „нефиг сообщать всему миру“ не возникнет.»
M_AJ
20.01.2023 09:33Там сам пример с чайником странный, он почему-то приведён как плюс NAT, хотя регуляция доступа к "чайникам" это функционал фаервола, для ната это просто побочный эффект, который иногда срабатывает в плюс, хотя если чайник имеет UPnP то спокойно высунется себе в инет через NAT, если посчитает нужным, со всеми своими дырами. Вообще NAT в итоге сыграл с людьми злую шутку, многие настолько привыкли к побочке, что рассчитывают на неё, вместо того, чтобы делать как задумано — настраивать фаервол.
Aelliari
19.01.2023 09:41Стоп, всякая iot-яина может вполне следовать политике default deny для глобальных ipv6. Но откликаться на unique-local внутри сегмента сети (у вас же стоит пограничный маршрутизатор? Пусть объявляет префикс. Нет? Есть ещё Link-local...). Если iotятины мало - можно ручками ждать доступ из вне, если много - пожалуйста, управляй централизованно через контроллер
Vizmaros
19.01.2023 03:31+1При том, что у каждого уважающего себя чайника должен быть whitelist тех, с кем ему разрешено общаться. И тогда проблема «нефиг сообщать всему миру» не возникнет.
Тогда да, косорукость. Хотя я вот почитал, локальные IPv6 адреса вполне заменяют эту функцию NAT.Вопрос выяснения даже просто IP адреса вашего чайника становится весьма нетривиальным
Вот с этим поспорю. Это работает только если цель найти конкретное устройство, что ИМХО, не самый частый вариант атаки. А если атакуются все адреса, сложность выяснения конкретного значения не имеет
turbotankist
19.01.2023 08:35Какие все адреса атакуются?
Все несколько миллиардов или триллионов?
В ipv6 нет бродкаста.
StraNNicK Автор
19.01.2023 11:06+1тут просто два подхода:
верить, что просканировать N адресов невозможно и поэтому мы в безопасности;
знать, потому что вот этот блок адресов закрыт файрволлом.
P.S. я просто помню времена, когда с той же интонацией, что у вас про миллиарды или триллионы говорилось про взлом md5, например (я понимаю, что "взлом" не самый удачный термин, я про сам принцип).
PuerteMuerte
19.01.2023 03:33+3При том, что у каждого уважающего себя чайника должен быть whitelist тех, с кем ему разрешено общаться. И тогда проблема «нефиг сообщать всему миру» не возникнет.
Это перенос проблемы с больной головы на ещё более больную. Перекладывать вопросы безопасности только лишь на конечные клиентские устройства, это никогда толком не работало, не работает, и уже и не заработает, к сожалению.
StraNNicK Автор
18.01.2023 18:59Я не стал раздувать заметку, хотя в качестве примеров просились IP-телефония и прочий WebRTC.
И там же, в примере, хотел написать, что сейчас NAT-T вполне себе работает.datacompboy
18.01.2023 19:12+2Да, для каждой дырки мы нашли затычки разной сложности. Только дыры продолжают появляться.
plFlok
18.01.2023 18:56-1Сам не настоящий сетевик, но стоял рядом с настоящим.
От него слышал, что проблема недоступности ubuntu.com по ipv6 - это проблема того, что гигантские AS до сих пор не могут договориться друг с другом о тарификации обмена трафиком, и фактически ipv6 интернет порван во многих местах. И через атлантику он порван прямо капитально.edo1h
18.01.2023 21:33серьёзно?
попробовал пинговать этот ubuntu.com с разных точек (россия, европа) — проблем нет.StraNNicK Автор
19.01.2023 06:22+4я очень рад, что у вас нет проблем с пингом ubuntu.com. У меня были.
но я написал это всё не для того, чтобы пожаловаться на, возможно, временную недоступность ubuntu.com через ipv6.
Это просто пример, иллюстрирующий тезис "двойной стек ipv4+ipv6 не уменьшает количества проблем, а увеличивает их".datacompboy
19.01.2023 12:20Я несколько удивлён, что сайт при этом не открывается. Мой опыт использования браузера с очень плохо настроенными сайтами говорит, что такое же бывает и с ipv4, когда один из прописанных адресов недоступен. Нажатие F5 пару раз заставляет браузер взять другой адрес и достучаться в итоге.
DaemonGloom
19.01.2023 13:40Я подобную проблему с ipv6 ловил на некоторых сайтах, когда mtu канала отличался от mtu, раздаваемого локальным устройствам. Что-то в фрагментации пакетов ломалось — и ответы сайта уже не могли собраться. После установки на маршрутизаторе в разделе ipv6 Neighbor Discovery правильного mtu — проблема решилась.
Revertis
19.01.2023 16:37Да может просто админ ubuntu.com забанил подсеть HE из-за любителей поспамить или побрутить из неё. Так же, как многие банят подсети выходных айпишников Tor или даже некоторых VPN.
Adler_lug
18.01.2023 19:43+1ipv6 по моим наблюдениям работает странно.
Дома он через Miredo настроен, на работе нативный от провайдерам и есть несколько vds в РФ и Европе. Где-то "с коробки", где то через брокер. И не раз наблюдал такую картину, что например с работы пропадает доступ к одному из vds, при этом домашний комп доступен и с него есть доступ к тому vds. Или наоборот, пропадает доступ к домашнему компу, в то время как есть до vds и с него есть доступ к домашнему компу. И такое наблюдал не раз в разных комбинациях, когда и vds между собой то доступны, то нет.
Как будто маршрутизация периодически рассыпается.
simenoff
18.01.2023 20:03Стоит включить ipv6 и для https://xml.yandex.ru/settings/ твой айпи начинает регулярно меняться(
ivan386
18.01.2023 22:13-3В IPv6 вроде как мультикаст изначально продумали с учётом вещания через интернет. Благодаря мультикасту любой стример сможет вещать напрямую своей аудитории и на сервисы отдавая один поток и не забивая канал до отказа. И как я понял мультикаст адреса сразу разделили флагом на два диапазона. Один регистрируется а второй свободный.
StraNNicK Автор
19.01.2023 06:24+1Мультикаст никак не поможет стримеру, если он работает не в режиме ТВ (когда все смотрят одно и то же, в одном и том же качестве, в одно и то же время, а не так, что сначала я включил ролик у себя на телефоне, а через секунду — жена на своём, причём оба смотрим сначала)
ivan386
19.01.2023 10:02Стрим и предполагает что люди смотрят именно то что происходит в этот момент и общаются со стримером. Можно вещать несколько потоков в разном качестве благо адресного простраства на это хватит. Чат тоже кстати может по мультикасту работать.
ammo
19.01.2023 15:36Вы несете какую-то ересь. В глобальном интернете нет никакого мультикаста от слова совсем, неважно, ipv4 или ipv6, операторы им просто не обмениваются (за исключением каких-то местячковых случаев). Мультикаст существует только в пределах одного административного домена - одного оператора связи (например, для IPTV) или одной корпоративной сети.
datacompboy
19.01.2023 15:45+1В 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)
ammo
20.01.2023 01:46Ммм, статьи про ипв6 для домохозяек в качестве пруфа. Как это опровергает то, что я сказал про отсутствие обмена мультикаст трафиком между tier 1? Никак. То, что мультикаст-групп в ипв6 просто больше и вероятность их уникальности выше, никак мультикаст-интернет из воздуха не создаст.
Мультикаст - это полностью другой control plane по сравнению с юникастом, т.е. условно сложность администрирования сети при включении мультикаста увеличивается в 2 раза. Его локально в пределах своей сети то стараются не включать без крайней необходимости, и уж тем более операторы им не обмениваются между собой просто так "чтоб было"datacompboy
20.01.2023 02:32Я к тому, что технически можно. Будет ли это когда-либо таки работать... Вопрос. Оборудование поддерживает (вроде (часть точно(неточно)))
DreamingKitten
19.01.2023 00:04+4Проверяю 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
vvzvlad
19.01.2023 02:03и к тому времени, когда каждая зажигалка станет IoE устройством,
А чем зажигалке не подходит локальный IP-то?DreamingKitten
19.01.2023 02:17+4Я не могу придумать и продумать заранее все возможные сценарии использования устройств в будущем.
Интернет ведь называется Интернетом именно потому, что он -- о межсетевой связности и избыточности. То есть о том, что каждый должен иметь возможность связаться с каждым, даже если где-то что-то порвалось.
А NAT фундаментально нарушает эту парадигму, и это приносит ряд неудобств лично мне прямо сейчас.
Например, когда я хочу захостить на домашнем сервере веб-сайт или dedicated server какой-нибудь игры, оно не работает из коробки, а приходится идти на роутер и делать там nftables-магию. Какого хрена? Чтобы торрент-клиент или там bitcoind/monerod в ipv4 у меня работал как следует, мне приходится поднимать на роутере upnp/igd. Когда я принимаю лабораторки у студентов по линуху, я не могу просто так взять и подключиться по ssh к его компу, чтобы посмотреть что там или помочь, нам приходится использовать опять же port forward, ngrok или что-то ещё. То есть, по факту, использовать костыли второго порядка для преодоления проблем, созданных костылями первого порядка.
Вы просто привыкли к тому, что NAT вас сношает и считаете это нормой.
Интернет не для этого придуман был. Поэтому NAT это зло, а IPv6 -- будущее.
vvzvlad
19.01.2023 02:20+1Например, когда я хочу захостить на домашнем сервере веб-сайт или dedicated server какой-нибудь игры, оно не работает из коробки, а приходится идти на роутер и делать там nftables-магию. Какого хрена? Чтобы торрент-клиент или там bitcoind/monerod в ipv4 у меня работал как следует, мне приходится поднимать на роутере upnp/igd. Когда я принимаю лабораторки у студентов по линуху, я не могу просто так взять и подключиться по ssh к его компу, чтобы посмотреть что там или помочь, нам приходится использовать опять же port forward, ngrok или что-то ещё.
Так а в счастливом будущем IPv6 вам все равно придется идти на роутер и делать там магию по разрешению доступа к устройству.DreamingKitten
19.01.2023 02:25Нет, зачем? Они по умолчанию смогут принимать входящие. Роутер будет только роутером, т.е. маршрутизировать пакеты.
vvzvlad
19.01.2023 02:26+2Т.е. любая железка будет торчать голой жопой в интернет, даже если она на мелком контроллере, который можно положить десятком запросов в секунду или не поддерживается и имеет внутри уязвимости?
DreamingKitten
19.01.2023 02:33Во-первых, вы занимаетесь подменой тезиса: "Разрешение доступа к устройству" предполагает, что на роутере сидит файрволл, рубящий всё кроме белого листа, а отфильтровать траффик на мелкий контроллер это задача штучная, единичная.
Во-вторых, вам известен способ выяснить ipv6 адрес мелкого контроллера? Что-то вы тщательно избегаете этого вопроса в нашей дискуссии.
edo1h
19.01.2023 02:42Во-вторых, вам известен способ выяснить ipv6 адрес мелкого контроллера?
например, присоединиться к пулу ntp-серверов
DreamingKitten
19.01.2023 03:03И надеяться на то, что а) вашей потенциальной жертве вообще нужно ntp-время, и б) что она доберётся до вашего сервера в вашем пуле. Хороший план.
edo1h
19.01.2023 03:06+2Да, если вам нужна конкретная жертва, то это неподходящий вариант.
А вот если вам просто нужен большой список потенциальных жертв, то всё становится интереснее.
vvzvlad
19.01.2023 02:53+3Во-первых, вы занимаетесь подменой тезиса: «Разрешение доступа к устройству» предполагает, что на роутере сидит файрволл, рубящий всё кроме белого листа,
Ну так уже выяснили выше, что если у вас больше ноута-телефона-телевизора в сети, вам нужен фаервол на роутере, потому что вручную конфигурировать права доступа на каждом устройстве неудобно (не говоря уж о том, насколько легко найти фаервол, скажем, на умный телевизор с закрытой прошивкой). Ну или пусть они торчат в инет, ботнетов же не существует.Во-вторых, вам известен способ выяснить ipv6 адрес мелкого контроллера? Что-то вы тщательно избегаете этого вопроса в нашей дискуссии.
Вы предлагаете безопасность через неясность? Типа, если адресов много, то никто его не найдет, не парьтесь?
Так вы напрасно надеетесь на /64. Подсеть у большинства пользователей будет одна, из этой подсети идет трафик, и адрес подсети несложно вычислить. Конечно, остается 6 байт MAC-а, но три из них как правило, остаются на совести производителя, и настоящим рандомом обладают лишь три, и у нас остается для перебора несколько диапазонов по 16м адресов, что уже не выглядит так внушительно, как целая /64.
А еще как бы сами устройства трафик генерируют. И этот трафик замечательно светится по всей цепочке сетевого оборудования с адресом получателя и отправителя. Сможете гарантировать что ни один из промежуточных провайдеров эти адреса не сольет никуда?
Сможете гарантировать что ни один из сервисов DNS/NTP/MQTT/любой общедоступный протокол не сольет адреса?
Сможете гарантировать что ни один конечный сервер не потеряет свои логи или бд устройств(подразумевается, что он может на эти устройства пушить данные, для чего ему нужен список актуальных IP)?DreamingKitten
19.01.2023 03:12Ну так уже выяснили выше, что если у вас больше ноута-телефона-телевизора в сети, вам нужен фаервол на роутере
Это не так чтобы напрямую к теме относится, но, если уж на то пошло, я не имею ничего против файрволла на роутере в сетях ipv6. Я только против того, чтобы наследовать плохие практики там, где возможность им не следовать заложена в архитектуру.
и у нас остается для перебора несколько диапазонов по 16м адресов, что уже не выглядит так внушительно, как целая /64.
RFC 4941 вам в помощь.
Сможете гарантировать что ни один из промежуточных провайдеров эти адреса не сольет никуда?
Смогу. Если в стоимость взлома вашего мелкоконтроллера входит цена слива трафика с промежуточных провайдеров, то проблема перестаёт быть технической и становится организационной. И тогда вам никакой NAT не поможет в принципе.
vvzvlad
19.01.2023 03:25+1Смогу. Если в стоимость взлома вашего мелкоконтроллера входит цена слива трафика с промежуточных провайдеров, то проблема перестаёт быть технической и становится организационной. И тогда вам никакой NAT не поможет в принципе.
А вы, простите, знаете, как ботнеты из роутеров организуют? Там тоже не то, чтобы в стоимость взлома каждого роутера входит написание экплоита для его софта. Нужен не мой роутер, нужен любой подходящий роутер. И как достаточно понятно, я очень не хочу, чтобы мой роутер/телевизор/комп/любое устройство оказались «подходящими».RFC 4941 вам в помощь.
Опять же, гарантируете работу на любых устройствах? И даже если оно действительно будет работать, все еще остается сбор трафика.DreamingKitten
19.01.2023 03:30А вы, простите, знаете, как ботнеты из роутеров организуют?
Знаю.
Ботнет будет башлять провайдеру за слив траффика потенциальной жертвы?
я очень не хочу, чтобы мой роутер/телевизор/комп/любое устройство оказались «подходящими».
см. выше про файрволл.
И кстати! Как это вы лихо с оконечных устройств перескочили на роутеры. Они ведь и сейчас в Интернет торчат, даже по ipv4. С этим у вас нет проблем, да?
Опять же, гарантируете работу на любых устройствах?
Я гарантирую работу на устройствах, которые я покупаю для своей сети.
vvzvlad
19.01.2023 03:52+2Ботнет будет башлять провайдеру за слив траффика потенциальной жертвы?
Ботнет. Башлять. Провайдеру.
Ботнет это набор устройств, он никому ничего башлять не будет. Человек, заинтересованный в создании ботнета или взломе конкретных-пылесосов-с-камерой — да.И кстати! Как это вы лихо с оконечных устройств перескочили на роутеры. Они ведь и сейчас в Интернет торчат, даже по ipv4. С этим у вас нет проблем, да?
У меня нет проблем, у меня все ненужное запрещено. Но речь не обо мне, речь в целом о влиянии на безопасность. И я как бы только что сказал что ботнеты организуют из роутеров — это и есть проблема. И это очень небольшая часть роутеров, потому что не у всех есть доступный снаружи адрес. А вы предлагаете раздать всем-всем устройствам публично доступные адрес, сначала увеличив поверхность атаки за счет доступа к тем же маршрутизаторам поголовно, а потом еще и добавив к возможным вариантам атаки все устройства в доме. Замечательно. Теперь не только роутер будет ботнетом, потому что на нем пять лет прошивку не обновляли, но еще и телевизор, пылесос, медиа-приставка, и так далее.Я гарантирую работу на устройствах, которые я покупаю для своей сети.
А, ну, ясно. «У меня такая же нога и ничего не болит, а все остальное мне не важно и неинтересно, пусть хоть огнем горит»
DreamingKitten
19.01.2023 04:21Человек, заинтересованный в создании ботнета или взломе конкретных-пылесосов-с-камерой — да.
Ну тогда опять-таки см. выше про бюджет взлома. От той проблемы, через которую вы пытаетесь выстроить свою аргументацию, ни NAT ни файрволл не спасёт.
Замечательно. Теперь не только роутер будет ботнетом
...
А вы предлагаете раздать всем-всем устройствам публично доступные адрес
Нет, я не это предлагаю. Я предлагаю не использовать костыли, придуманные ради других костылей, которые были созданы для решения другой проблемы, чем та, которую вы ими решаете.
Я уже повторяюсь и мы, похоже, ходим по кругу.
Угроза ботнетизации вами преувеличена, и я уже выше намекнул почему, даже RFC назвал, написанный для решения конкретно указанной вами проблемы.
Сценарий массового подкупа магистралов владельцами ботнетов, извините, я всерьёз рассматривать не буду -- это компетенция правоохранительных органов, а не разработчиков протокола.
vvzvlad
19.01.2023 04:51+3Сценарий массового подкупа магистралов владельцами ботнетов, извините, я всерьёз рассматривать не буду — это компетенция правоохранительных органов, а не разработчиков протокола.
О, узнаю сугубо теоретический подход: если наша замечательная идея не вписывается в реальный мир, где существуют ботнеты, уязвимости, глупые устройства, невнимательные пользователи, разработчики, пренебрегающие частью стандартов, странно организованные сети, и прочие интересные вещи, то мы просто скажем, что это мир/ботнеты/пользователи плохо пользуются нашей идеей, передайте им, пусть пользуются правильно. Менять красивую идею? Ой, право, зачем.
DreamingKitten
19.01.2023 05:07-1Я ничего из вами перечисленного не говорил и не утверждал -- вы опять приписываете мне какой-то выдуманный вами бред. Я только указал (в очередной раз), что вы пытаетесь в техническом споре использовать нетехнические аргументы.
Приведите известные примеры подкупа магистралов владельцами ботнета.
Если таковые есть -- я признаю вашу правоту во всём, отныне и присно.
Если таковых нет -- то тогда теоретик как раз вы, а не я.
nukler
19.01.2023 17:23+1>>Угроза ботнетизации вами преувеличена
Угроза преувеличена? Это не технический ответ. Наверняка разработчики которые дефолтные пароли на админку в роутерах, то же думали, да кто узнает.
Что будет если завтра чувак в больших очках придумает способ перебирать /64 за секунды, ну хорошо за минуты? Что ответят инженеры? Упс, вычеркиваем RFC 4941 из пула преимуществ? Давайте же всем миром думать как защитится?
И еще, захват и нахождение пограничных устройств становится первоочередной задачей и именно для упрощения нахождения адресов проходящих через устройство.
Alexeyslav
21.01.2023 12:09Думаю, если придумают способ хотябы перебора 64 битногр числа за секунду атаки на домашние сети покадутся мелочью. В тот момент падёт криптографиятпотвсему миру. И это... как бы сам сканер не испарился из-за высокой концентрации энергии. Делотв том что есть незыблемые законы физики, и количество необходимой энергии только лишь на перебор всех комбинаций 64 бит сопоставим с энергией содержащейся вот всей вмеленной. Так что тупой перебор адресов точно не будет практиковаться, будут лишь атаки на ГПСЧ которые генерируют внутренние адреса. А тут такое дело... добавив чуток соли мы нарушаемтвсе планы атакующего. В итоге простая защита становится в миллионы раз дешевле атаки и атака просто теряет смысл.
grey_dog
20.01.2023 17:53+1Если факты противоречат моей теории, тем хуже для фактов
Георг Вильгельм Фридрих Гегель
identw
19.01.2023 23:20Вы предлагаете безопасность через неясность? Типа, если адресов много, то никто его не найдет, не парьтесь?
Почему вы продолжаете игнорировать тот факт, что запрет подключений из интернета к вашим устройствам запрещается простым правилом файрвола, также как и одной строкой настраивается правила для NAT. В плане количества правил тут вообще нет особых различий.
Это ничем не хуже NAT. Но при этом избавляет от conntrack и всех других костылей которые идут вместе с натом (например способы сохранения source ip клиента и так далее)
kozlyuk
20.01.2023 00:32От conntrack всё же не избавляет, так как нужно пропускать обратные пакеты. От conntrack IPv6 освобождает не клиентов, а провайдеров, если им достаточно stateless фильтров на входящий трафик.
vvzvlad
20.01.2023 02:35Почему вы продолжаете игнорировать тот факт, что запрет подключений из интернета к вашим устройствам запрещается простым правилом файрвола, также как и одной строкой настраивается правила для NAT. В плане количества правил тут вообще нет особых различий.
Я? Игнорировать? Да я это в самом начале диалога написал: «Так это полиси все равно придется где-то задавать на граничном маршрутизаторе. Раньше были правила forward port from to, а сейчас deny all, allow ports… По сложности столько же, только адресация чуть удобнее стала, нет маппинга портов.»
v6 лучше, я с этим и не спорю. Но вот от граничных роутеров с фаерволами он совсем не избавляет.identw
20.01.2023 20:02Ну вроде никто и не обещал избавляться от маршрузитаторов и файрволов. Но избавление от ната сильно улучшает ситуацию как по мне.
И все таки ты можешь при желании выставить свою домшнюю машинку полностью в интернет, когда например тебе нужно случайные порты слушать. Ты просто разрешающее правило добавляешь для конкретной машины
В nat'е же тебе придется пробрасывать только конкретный список портов. А если у тебя еще одна машинка есть, и список портов между ними пересекается. То всё, приехали.
Во многих кейсах и dhcp становиться не нужен
Alexeyslav
21.01.2023 12:12один из уровней эшелонированной защиты, который простымтспособом в милоионы раз усложняет проведение атаки в лоб. С другой стороны, достаточно одного троянца, который тупо изнутри сдаст все внутренние адреса атакующему.
StraNNicK Автор
19.01.2023 06:34и NAT, и IPv6 — технологии.
вся ваша аргументация и здесь, и по ссылке, которую вы привели строится вокруг двух тезисов:NAT это зло, а IPv6 -- будущее.
всё отлично работает в идеальном мире.
M_AJ
19.01.2023 08:33+1Только Nat ещё и костыль, который возник, когда появилась необходимость выпускать много клиентов через малое число IP-адресов.
StraNNicK Автор
19.01.2023 06:32У меня оба хоста пингуются и открываются через ipv6, ЧЯДНТ?
полагаете, что раз УМВР, то и у всех так. К сожалению, это не так. Тем более в плане сетевой связности в интернете.
Ну и это просто пример, иллюстрирующий тезис "двойной стек ipv4+ipv6 не уменьшает количества проблем, а увеличивает их".
Смотрите, реальная ситуация, ресурс доступен по ipv4 и недоступен по ipv6.
Что это значит для пользователя на практике? Ресурс недоступен.А почему внешний доступ нельзя контролировать без NAT?
Неудачная формулировка. Я хотел сказать, что мне нужен вариант "всё закрыто по умолчанию, внешний доступ открываю я и очень выборочно".
Доступность не означает что они дешевеют.
Я и не говорил, что они дешевеют. Я привёл два примера ограниченных ресурсов и указал на то, что динамика роста цены отличается весьма значительно.
datacompboy
19.01.2023 12:24Во времена начала. Ркн, у меня было море контактов которые были доступны по ипв6 и недоступны по ипв4. И успешно пользовались. То есть на самом деле связность увеличивается, за счёт увеличения опций. Часть адресов может быть недоступна в любой момент времени вне зависимости от протокола
arheops
19.01.2023 00:23Проблемы в основном из-за таблиц в маршрутизаторах.
Старым не хватает памяти. Новые — дорого.
Потому большинство провайдеров просто тратит больше усилий на 4 и 6 может работать или нет.
В теории маршрутизация должна была работать по префиксам адреса. На практике — каждый имеет 100500 разных приоритетов по цене или провайдеров, и минимальный путь — не основная метрика.
Точно по той же причине не взлетели супер-самолеты на 200 человек. Да, в теории выгодно — на практике никто не хочет работать через один аеропорт.
Но все равно рано или поздно все перейдем на ipv6, выбора особо нету.vvzvlad
19.01.2023 02:06Точно по той же причине не взлетели супер-самолеты на 200 человек.
Что это они не взлетели? Новые широкофузеляжники это 200-300 человек.arheops
19.01.2023 03:38А380 по факту используется только арабами.
Все остальные от них отказалися, ибо система супер-хабов не особо получилася.
Да там 400+, извиняюсь. Но самые активно летающие все еще 200.
edo1h
19.01.2023 02:40а, при всё моём скептицизме, не могу не заметить, что ipv6 таки внедряется.
на мелких vps цена ip-адреса соспоставима с ценой самой vps, и брать ipv6-only vps стало осмысленным. да, есть проблемы (хотя бы дефолтные репозиториии докера и гитхаба не имеют ipv6-адресов), но с трэшем «ubuntu.com не пингуется» я не встречался.и не слышно шума, но в мобильных сетях (и в РФ тоже) всё шире используется ipv6. десятки миллионов телефонов (а в мировом масштабе, наверное, миллиарды) получили реальные адреса. и всё просто работает.
StraNNicK Автор
19.01.2023 06:43ну так я и не говорю, что "ipv6 не нужен".
Нужность никто не оспаривает, мне привели уже минимум два примера, когда он прямо на своём месте:магистральные сети;
Яндекс.Облако внутри на 100% IPv6. Ибо размер 10.0.0.0/8 далеко не так велик, как может показаться.
мой спич был о том — готов ли ~линукс для десктопа~ ipv6 для домашнего использования.
пока по ощущениям, скорее нет, чем да.P.S. а сколько стоит ipv6-only vps?
edo1h
19.01.2023 08:01мой спич был о том — готов ли ~линукс для десктопа~ ipv6 для домашнего использования.
пока по ощущениям, скорее нет, чем да.мой опыт говорит об обратном. домру, посмотрел на даты конфигов, судя по всему, настроил ipv6 в феврале 2016-го.
с самого начала были единичные проблемы (уже не вспомню все детали, но мысли отказаться от dual stack были), последние же лет пять всё просто работает.P.S. а сколько стоит ipv6-only vps?
ну, например у iphoster минимальная ipv6-only vps стоит 1.95$ против 2.95$ на первый месяц и 3.95$ в дальнейшем.
pda0
19.01.2023 10:45Так я это слышу с того самого 2010.
Потому что ipv6 выдавливается пока в мобильные сети. Можно найти информацию, что у T-Mobile, ряда индийских провайдеров, сети уже v6 only. С тунелированием в v4 конечно. Но факт остаётся фактом: На всех v4 адресов уже не хватает.
StraNNicK Автор
19.01.2023 11:11это понятно. То, что никуда мы от ipv6 не денемся — тоже понятно.
Мой вопрос звучал так — в чём плюс внедрения ipv6 в условиях, когда дефицита ipv4 нет?
Пока все примеры, которые я видел, и которые выглядят очень убедительно (включая ваш, да) звучат как "не для домашней / SOHO сети"
vagonovozhaty
19.01.2023 12:17+1Диктую комментарий голосом на Маке, Siri распознала "IPv6" как "пиво и секс"
Может, в этом проблема?
kazimir17
19.01.2023 12:20Если экстраполировать график гугла https://www.google.ru/intl/en/ipv6/statistics.html прямой линией то до полного перехода на ipv6 примерно 10 лет, но вероятно в реальности линия не будет прямой, а вот какой точно сложно сказать.
Alexeyslav
21.01.2023 12:17Как-то все забыли, чтотна заре IPv4 были те же "по адресу для каждой лампочке" и тогда думали что 32 бит адресов должно хватить всем... ан нет, не хватило. И ещё задолго до проникновения IOT даже не в каждый дом.
datacompboy
Я так понимаю, мы научились жить в условиях строжайшего дефицита ipv4 до такой степени, что их нехватка превратилась просто в технологическую сложность на разных уровнях.
IPv6 даёт возможности и убирает часть сложностей, перенося их на магистрали и фильтрующие точки. В теории, трансляции NAT превращены в более простые фильтры и allow/deny решения без необходимости вмешиваться в сам пакет. С одной стороны -- это даёт максимальную пиковую производительность магистралей с минимизацией задержи. Нефрагментируемость пакетов оттуда же растёт. Но как таковая фрагментация уже давно не нужна -- с поддержкой почти повсеместной jumbo фреймов и на 4м.
Что мы получаем на выходе? Так же как с IPv4 -- очень легко его сделать неправильно. Очень много даз банных надо обновлять (это касательно GeoIP -- эти базы всегда были низкой точности, но со временем всё точнее и точнее, 6ые базы только недавно собираются и начинаются с обычного "возьмём всё корнем а там будем думать")...
Айпикопалипсис всё ближе -- но мы очень хорошо оттягиваем его. Не в последнюю очередь за счет миграции больших потребителей.
kozlyuk
Дело не в простоте, дело в отсутствии состояния, и следовательно, возможности масштабирования. Можно на лету поставить вторую коробку, направить на нее часть трафика, и это будет работать без разрыва сессий, которые шли через первую. Подменять адреса и порты и инкрементально обновлять контрольную сумму нетрудно (врочем, спасибо, что в IPv6 ее убрали).
Фильтровать IPv6 сам по себе сложнее. Мои претензии как разработчика пакетного фильтра:
DreamingKitten
И как же сейчас BGP с этим справляется?
Может, умные люди уже об этом подумали и делегируют подсети по /48 ?
kozlyuk
BGP работает с подсетями операторов, которых сравнительно мало, а ACL должен работать с клиентами, то есть до /64 (если рекомендацию не выдавать меньше соблюдают, а ее нарушают).
DaemonGloom
Да, но при этом мы теряем возможность прозрачно направить часть трафика клиента в другой канал. Условно, если мы хотим, чтобы трафик до какого-то сайта шёл через тоннель, а остальной трафик шёл напрямую — то с ipv6 это гораздо сложнее.
kozlyuk
Непонятно, какие с этим проблемы именно от IPv6 и отсутствия состояния. Туннелю все равно, пакеты каких сессий по нему идут.
DaemonGloom
Проблемы тут идут от основного "преимущества" IPv6 — отсутствия NAT. Туннелю всё равно, а вот провайдеру после туннеля и локальному провайдеру — нет. Если в туннель ушёл пакет с адресом от локального провайдера — то он просто дропнется на выходе из туннеля дальним провайдером. А поскольку сами компьютеры о наличии нескольких путей ничего не знают — адреса они ставят какие попало.
ivan386
А дальнему провайдеру не пополам какой обратный адрес у пакета?
DaemonGloom
Проверено — не пополам. И ближний провайдер пакеты к остальным сайтам, идущие по ipv6, но с некорректным обратным адресом, тоже рубит.
Проверял на связке туннель HE + локальный дом.ру.
datacompboy
Да, чтобы завернуть надо обратный туннель анонсировать тут. Либо таки включать NAT. Который не умер, просто стал реже быть нужен.
datacompboy
Обычно не пополам, и пакет который обратно не может быть зароучен в канал с которого пришел подлежит дропу. Если только у вас нет спец договорённостей что тебе -- можно.
Цэ ж вопрос безопасности от тех же самых ботнетов и иже с ними.
ivan386
А как же UDP у которого в обратном адресе могут быть нули если ответ не требуется?
kozlyuk
Не в src ip, а в src port, который в L3 маршрутизации не участвует.
kozlyuk
Сейчас (IPv4) в туннель уходит пакет с src из блока локального провайдера, из его пула внешних адресов NAT. Будет (IPv6) — с src клиента из блока локального провайдера. В обоих случаях на выходе src маршрутизируемый, из блока локального провайдера. Если удаленный провайдер режет src не своего блока (BCP-38), в чем разница между IPv4 и IPv6?
DaemonGloom
Сейчас в туннель ipv4 пакет уходит с локальным адресом устройства, и на выходе из дальней стороны уже проходит NAT/masquerade, где получает в качестве src внешний адрес дальней стороны. И если он не нужен в туннеле — то маскарад проходит на локальном роутере и выдаётся адрес ближнего провайдера.
Но в ipv6 туннель он уходит с адресом из блока провайдера в качестве src, и не всегда — с нужным. Равно как и вне туннеля идущий ipv6 пакет может вылететь с некорректным адресом.
vikarti
IPv6 NAT (полноценный, с заменой адресов) все же существует. Не рекомендуется к использованию, не так давно появился но… например RouterOS так может (потому что люди очень сильно дергали Mikrotik). Нужно например для Multi WAN если нет возможности свою ASN а решение с тем что внутрисетевое железо имеет IPv6-адреса сразу от двух провайдеров и невозможно нормально контролировать на роутере через кого пойдет трафик.
Да, это очень особое решение но оно все же есть если надо.
С другой стороны — получить свою /48 + ASN значительно проще (и дешевле) чем с IPv4 получить /24. А уж то что при желании можно на каждом чайнике поднять публично-доступный вебсервер с поддержкой rfc2324 — это очень хорошо.
DaemonGloom
Да, это очень особое решение. И в момент, когда пытаешься его реализовать, возникает вопрос — а зачем при этом ipv6, если мы выкинули его основное преимущество?
Получение своего ASN — это уже задачи для крупного бизнеса, и там вряд ли захотят поднимать вебсервер на чайнике. А для мелких компаний — это всё равно проблематично, да и не нужно им /24 обычно.