Комментарии 75
Выглядит правда так себе, но хорошая новость в том, что в таких адресах можно сократить нули слева направо, поэтому большой адрес можно записать вот так, что гораздо симпатичнее.
2001:0db8:0000:0000:0000:0000:0010:ad12
2001:db8:10:ad12
В общем случае - очевидно некорректное утверждение. Без указания дополнительных правил/критериев, с применением только озвученного, один и тот же финальный укороченный адрес очевидно можно получить из нескольких разных исходных.
Или описывайте правило сокращения полностью, или не пишите о нём вообще. Иначе получается заведомое введение читателей в заблуждение.
Ну и двоеточие они пропустили: 2001:db8::10:ad12
и условие, что заменяться на :: может только одна, как правило самая длинная последовательность нулей.
например, адрес
2001:0:acbd:89ef:0:0:0:1
можно записать как
2001:0:acbd:89ef::1
нельзя записать как
2001::acbd:89ef::1
можно даже 2001::acbd:89ef:0:0:0:1, хотя смысла в этом не очень много, лучше выкинуть самую длинную последовательность.
да тут много прекрасного
Это дает 2128 вариантов уникальных адресов
новый протокол делает каждые девайс полноценным участником интернета: устройства могут общаться друг с другом напрямую, минуя даже DNS-сервера
Разметка поехала. 2 в степени 128
Читал в 1997 году, что уже через пару лет все перейдут на IPV6.
Тогда и был придуман IP-адрес, который выглядит вот так:
Честно говоря до сих пор не понимаю почему не добавили маску к MAC и не сделали ту же адресацию на этом уровне. Лан, как написано у Олиферов "исторически так сложилось"
Начнем с того, что для провайдеров обновляться на IPv6 очень дорого.
Провайдеры за последние 10-15 лет уже и так все оборудование обновили, т.к. скорости выросли кратно и найти железку не подерживающую IPv6 надо умудриться, тем более в бизнес сегменте.
Во-вторых, на текущий момент всё еще очень мало понимания, как настраивать IPv6. ... В-третьих, IPv6 не имеет обратной совместимости с IPv4.
Проблемы IPv6 не в этом, а в том что он конечному пользователю не нужен, раз он не нужен, то и продавать сложно, а раз сложно продавать то какой смысл внедрять?
Вторая большая проблема IPv6 это то что при переходе от одного провайдера к другому поедет вся сеть. Вы не можете перетащить весь блок, как итог привет перенастройка всего и вся. Ладно переезды случаются не часто. Но вот как быть с резервированием каналов у двух провайдеров?
Третья проблема, IPv6 требует настройки firewall, внятной и вдумчивой. NAT'ом можно просто отгородиться ото всех и плевать что там с дырками в необновляемом IoT-конвекторе. С IPv6 сорян, надо правила писать. Добавим сюда вот этот самый SLAAC и начинается веселье.
Честно говоря до сих пор не понимаю почему не добавили маску к MAC и не сделали ту же адресацию на этом уровне
Сделали, это называется link local address.
При чем тут link local, когда речь о L2-уровне?
Я может не очень точно выразил мысль. Сейчас на L2 мы имеем фрейм содержащий src.mac, dst.mac и type. Можно же было добавить mac.mask и все вот это вот gateway.mac, route.mac - получив маршрутизацию на 1 уровень ниже без дополнительных абстракций
Была такая сеть IPX. Она проиграла конкуренцию с IP.
А какую бы роль играла Mac.mask ?
А сетевой мост или коммутатор сколько Кеша Mac адресов должны иметь чтобы пересылать пакеты только в определенный выходной порт ?
Или пусть это будет как в концентрах - на все порты устройства ?
Прекрасная идея... Представляете себе как выглядела бы таблица маршрутизации? А еще давайте помечтаем о route summarization в подобном адке :-D Вы же в курсе про OUI и как он раздается?
Прекрасная идея...
Это не идея, это вопрос почему так не сделали в 1981? Очевидно, что раз не сделали, значит были причины - вопрос только в этом. Route summarization появился значительно позже, собсно когда IP стал стандартом.
Представляете себе как выглядела бы таблица маршрутизации?
Точно так же как сейчас выглядит таблица IP-маршрутизации. Где были бы mac'овские подсети.
По поводу найти железку которая не поддерживает ipv6: легко. А найти железку которая поддерживает ipv6, но работает с ним не так как хотелось или глючит еще проще.
По поводу проблемы IPv6 не в этом, а в том что он конечному пользователю не нужен: пользователю он как раз таки и нужен. Не судите по себе лол. Проблема в отсутствии спецов, что доказывает следущий ваш пункт: IPv6 требует настройки firewall. Просто рука лицо. Вы не поверите но когда вы настраиваете NAT вы тоже должны настроить firewall, просто большинство железок это делает за вас. А вот с IPv6 настраивать не нужно совсем ничего: in deny и точка. Хотите сделать что то доступным с мира: разрешайте, а NAT это костыль, а не лекарство.
По поводу вторая большая проблема IPv6 это то что при переходе от одного провайдера к другому поедет вся сеть: у меня multihome с failover на протяжении 3 лет и без своей asn, и решение есть, и да это костыль под названием NPt - вот тот ваш хвалёный NAT, только всей подсети. С ipv4 у вас тоже едит wan ip ;), так в чем разница? Если это просто смена ISP то проблем вообще 0 - клиенты просто получат новые IP и маршрутизацию. Если хотите полноценный multihome без NPt придется раскошелиться на AS.
И чем вам уже не угодил SLAAC?
поводу найти железку которая не поддерживает ipv6: легко.
В сегменте провайдерского\телеком оброудования? Примеры в студию
По поводу проблемы IPv6 не в этом, а в том что он конечному пользователю не нужен: пользователю он как раз таки и нужен.
Расскажите мне домохозяйке с пятого подъезда зачем ей надо тратить дополнительные 100 рублей на IPv6? Как изменится ее жизнь? Что она получит такого, чего у нее нет сейчас? Можете сразу слогоном.
Хотите сделать что то доступным с мира: разрешайте... in deny и точка.
Окей, домашний сервер с 80 портом, и IoT-железка с 80 портом. Один должнен быть виден с интернета, второй нет. Как решать при использовании SLAAC, где пол адреса генерится рандомно?
Вы не поверите но когда вы настраиваете NAT вы тоже должны настроить firewall
Кому должен? Предположим, что не настроил, будет доступ к эндпоинтам и их сервисам?
NPt не жмакал, возможно он и спасет ситуацию, но "клиенты просто получат новые IP и маршрутизацию." - меня не радует от слова совсем, т.к. что делать со статикой в виде принтеров, сканеров и прочих штук - смена IP (их или клиента) приводит к отказу ПО и злым пользователям.
В сегменте провайдерского\телеком оброудования? Примеры в студию
У многих провайдеров городских до сих пор бушные d/tp-link которые реально не сном не духом об ipv6. По mikrotik слышал жалобы на проблемы в стабильности имплементации ipv6, сам не юзаю давно, не скажу когда и как. То же unifi оборудование на основе unifi network controller, да, не провайдерский сегмент конечно, но они вообще ни сном ни духом про ipv6 почти, и то что они могут по ipv6 больше похоже на комтыль чем имплементацию.
Расскажите мне домохозяйке с пятого подъезда зачем ей надо тратить дополнительные 100 рублей на IPv6? Как изменится ее жизнь? Что она получит такого, чего у нее нет сейчас? Можете сразу слогоном
Домохозяйке это не нужно, а вот:
ее сыну страдающему от того что он свой сервер Minecraft захостить не может из-за CGNAT - да
людям которым голос жует во время конференции из-за отсутсвия нормальго p2p соединения
людям которые мучаются с NAT и отсутствием возмоности заюзать дефолтные порты когда есть несколько сервисов на разных устройствах
людям которые понимают что upnp дырявое зло, и прямой бекдор без авторизации и смс, но дома от него они не могут отказаться из-за p2p: voip, games, file transfer и тд
Лозунги придумывать не моя задача, я не маркетолог и не мыслю как домохозяйка, но до ее чада и гиков пользу донести можно без проблем. Плюс наличие ipv6 должно быть как раз одним из факторов привлечения новых клиентов от других провайдеров и не должно влиять особо на конечную стоимость.
Как решать при использовании SLAAC, где пол адреса генерится рандомно?
SLAAC не рандомный. Берется link local, prefix и вуаля. Открываете тому кому нужно и все. Это не отличается от того что вы даете статику по MAC на ipv4 и делаете nat, ничем, кроме того что вам даже не нужно настраивать статику.
Кому должен? Предположим, что не настроил, будет доступ к эндпоинтам и их сервисам?
Если у вас есть nat проброс, а ответного правила в allow в firewall - нет, то и доступа не будет, что за глупости?
но "клиенты просто получат новые IP и маршрутизацию." - меня не радует от слова совсем, т.к. что делать со статикой в виде принтеров, сканеров и прочих штук
При использовании Ipv6, вещи типа принтеров вообще будут подключены через mdns, bonjour или link local. А в случае использования принт сервера проблем - 0. В всех остальных случаях все так же - юзайте dns/mdns, он и создан что бы не мучаться с ip, и в случае смены ip клиенты не искали новый.
У многих провайдеров городских до сих пор бушные d/tp-link которые реально не сном не духом об ipv6
свитчи? им обычно и не нужно знать о ipv6.
да и сейчас всё чаще клиенту выдают гигабит, соответвенно, на подъезд приходит обычно 10 гигабит, так что старые свитчи не очень актуальны.
У многих провайдеров городских до сих пор бушные d/tp-link которые реально не сном не духом об ipv6.
Как на старых бу-шных длинках завести среднюю в 60 мбит\с на клиента?
Согласно исследованию, лидером среди российских интернет-провайдеров стала МТС со средней скоростью скачивания 71,97 Мбит/с и скоростью выгрузки файлов 79,13 Мбит/с. Второе место занял «ЭР-Телеком» (66,52 Мбит/с и 73,70 Мбит/с соответственно), третье — «Вымпелком» (57,29 Мбит/с и 65,18 Мбит/с). Самыми медленными среди крупных операторов связи оказались «Ростелеком» (50,11 Мбит/с и 45,52 Мбит/с) и ТТК (50,11 Мбит/с и 45,52 Мбит/с), по данным исследования.
У меня микроты с IPv6 нормально, нареканий нет, но в прошивках переодически всплывают баг-фиксы. Unifi - в принципе сегмент допила, они там роуминг пилили года полтора-два если не ошибаюсь. Может мы про что-нибудь более цисковское, juniper'ное, да даже про те же аллиеды поговорим.
Домохозяйке это не нужно, а вот:
А вот все остальные, ну кроме может быть геймеров, очень малый сегмент рынка. У меня дома включен IPv6 и знаете что? Ни_ка_кой разницы. Торренты как качаются так и качаются, скайпо-зумы что так, что так работают одинаково.
Единственное что зло это двойной нат - но мобильные пользователи жуют, не бастуют.
SLAAC не рандомный. Берется link local, prefix и вуаля.
3.PC1 получает сообщение RA, содержащее префикс и длину префикса для локальной сети. PC1 будет использовать эту информацию для создания собственного глобального индивидуального IPv6-адреса. PC1 имеет теперь 64-разрядный префикс сети, но требует 64-битный идентификатор интерфейса (IID) для создания глобального индивидуального адреса.
Существует для способа создания PC1 собственного уникального IID: EUI-64, генерация случайным образом. ....
Пруф. ...или это что-то другое? Повторюсь, я не сильно влезал в IPv6.
Если у вас есть nat проброс...
Проброс чего и куда? Мы же не про порт форвардинг. Есть 192.168.1.0/24 которая NAT'иться на интерфейс 10.10.10.10. Внутри есть хост с 192.168.1.123 с кучей открытых порторв. На 10.10.10.10 отключен файрволл и нет никаких других сервисов. Можете ли вы попасть из .1.0/24 на 10.123? без проблем. Можете ли вы попасть с .10.123 на .1.123? Да нифига потому что трансляции в обратную сторону нет. Каким боком тут фаерволл?
В всех остальных случаях все так же - юзайте dns/mDNS
т.е. по факту привязать все к хостнейму устройства (Option12)?
Ни_ка_кой разницы
Что бы разницу заметить нужно что бы был он не только у вас :)
Существует для способа создания PC1 собственного уникального IID: EUI-64, генерация случайным образом.
Устройства получают оба ip, temporary/anonymous и static/stable-privacy. Это поведение в некоторых ОС разное и настраиваемое. Можно и свою статику взять.
Мы же не про порт форвардинг.
Вообще то да, про него.
Использовать нат что бы спрятать... в ipv6 такое не нужно просто.
Если говорить про маршрутизацию, то если в шлюзе есть маршрут до конечной цели то достучитесь вы что по ipv4, что по ipv6, если разрешено все и ничего не запрещено.
т.е. по факту привязать все к хостнейму устройства (Option12)?
Один из вариантов. Второй вариант это gpo, третий - принт сервер. Если это тот же l2 сегмент то link-local. Правда сам замечал что сами дрова на принтеры не дружат еще с ipv6. Про сканеры: вообще отдельная тема, если у вас сканят до 20 человек, то да по сети скан на ПК ок, но в большинстве мфу с сетевым сканером больше подключить не получится и скан уходит либо на файлшару либо на емейл, а тут вообще пофиг какой ip у сканера :).
Я сам знаю что ipv6 only сеть это не реально в обозримом будущем. Но все же я считаю что с dualstack через счюр люди затягивают, тем более с учётом существующих атак на "пустующюю имплементацию ipv6". Я понимаю с чем это связано - по сути работы в 2 раза больше, настраивать нужно и то и то и отдельно друг от друга. Но если не двигается, то ничего и не поменяется совсем. А когда всем пригорит - когда все загашники ipv4 закончатся и цена будет не подьемная, начинать рыпатся уже будет поздно и в результате куда более проблематично, в спешке и тяп ляп.
Что бы разницу заметить нужно что бы был он не только у вас :)
А что изменится? Скорость выше не станет, единственное что меняется - доступность ресурсов, вот только они сейчас и так доступны. Вывод - для домашнего пользователя разницы никакой. Для корпоративного сегмента это головная боль, которая не дает ощутимых плюх. Так что IPv6 нужен больше магистральным провайдерам, чтобы разгрузить каналы (и то чет я не уверен что тот же ростелеком будет рад перераспределению траффика), ну и ЦОДам разного пошиба.
Устройства получают оба ip, temporary/anonymous и static/stable-privacy. Это поведение в некоторых ОС разное и настраиваемое. Можно и свою статику взять.
Вы извинте что пристаю, очень хочу для себя понять - по итогу то имеем ситуацию когда SLAAC будет всетаки выдавать рандомные номера после ребутов. Т.о. файрволл должен быть или динамическим или, как вы писали, прописывать статику или ставить свой DHCPv6. Ну и как бы ... от меня ускользает кто целевая аудитория SLAAC? Вот еще пруф:
Поэтому, приватности ради и безопасности для, современные ОС на конечных устройствах генерируют адреса случайным образом.
У меня есть стойкое ощущение, что с IPv6 проще защищать эндпоинты и с его приходом надо менять идеологию корпоративной сети (безопасники будут рады). Понятие периметра исчезает в принципе.
Вообще то да, про него. ...
Использовать нат что бы спрятать... в ipv6 такое не нужно просто.
Такое нужно и этим пользуются сплошь и рядом. Небольшие сети на 10 ПК, где сотрудникам нужен только выход в интернет.
Но если не двигается, то ничего и не поменяется совсем.
Когда технология кому-то нужна, она очень быстро внедряется (см. мобильный сегмент 2\3\4\5G, который по сути ровестник IPv6), когда технология нафиг не уперлась, она лежит годами. Как только на IPv6 можно будет заработать или существенно начать экономить, или она начнет решать какие-то конкретные проблемы, ее тут же внедрят.
Так что IPv6 нужен больше магистральным провайдерам, чтобы разгрузить каналы (и то чет я не уверен что тот же ростелеком будет рад перераспределению траффика)
честно говоря, я не понял, как ipv6 помогает разгружать каналы.
магистралам радости в ipv6 мало из-за того, что, как только начнётся массовое использование, начнут пухнуть таблицы маршрутизации.
и от того, что записи «жирнее», и от того, что их потенциально гораздо больше (в bgp ipv4 попадали записи от /24, в ipv6 /48 ЕМНИП)
что делать со статикой в виде принтеров, сканеров и прочих штук — смена IP (их или клиента) приводит к отказу ПО и злым пользователям.
в идеологии ipv6 на каждом интерфейсе больше одного адреса.
в ipv4 так тоже можно было, но было не особо принято, а тут уже почти всегда есть как минимум link-local и global адреса.
никто не мешает вам помимо белых адресов использовать и приватные адреса, в стандарте они предусмотрены (fd00::/8).
меня смущает другой вопрос:
если у меня два аплинка, то с натом всё понятно, роутер решает через какой канал пустить запрос из локалки, можно реализовать всякие разные схемы распределения нагрузки и файловера.
а вот без ната каждый клиент должен знать с какого реального адреса отправить трафик, даже с файловером могут быть проблемы, не говоря уже про более сложные схемы.
Я писал выше про multihome, почитайте ;)
да это понятно, только в итоге мы от nat никуда не уходим
Уходим по большей части, nat будет только при failover'е. Большую часть времени natа не будет.
если я вас правильно понял, то вы предлагаете использовать NPt, который является частным случаем nat'а
Да. Это единственный рабочий вариант multihome без asn, по крайней мере я сделал такой вывод для себя еще давно и других вариантов не знаю :)
В LAN вы используете подсеть 2000:a::/48, которую вам выдал основной WAN01. В NPt вы создаете правило: сменить 2000:a::/48 на 2002:b::/48 если трафик идет через WAN02. Понятное дело если вы захотите сделать SD-WAN, аля динамическую маршрутизацию на основе х условий, то будет дурдом и тут 100% нужен AS. Но, обычный failover переживет.
По поводу проблемы IPv6 не в этом, а в том что он конечному пользователю не нужен: пользователю он как раз таки и нужен
нет
ни типичному домашнему пользователю он не нужен (ipv6-only сервисов не наблюдается), ни владельцу сервиса он не нужен (ipv6-only клиентов не наблюдается).
да, некоторые сервисы, например торренты, могут выигрывать от наличия прямого адреса, но (a) 99.9…% пользователей нужны веб и инстаграм, (b) все эти сервисы приучились вполне сносно жить и за nat.
Откройте гугл и напишите double nat problem. Веб это не только котики в соц сетях :) И если забыть что ip pool на дне, погуглите сколько людей пытается настроить upnp или пробросить порты для игр по сети. Люди доплачивают что бы иметь белый статичный ipv4, когда с ipv6 это было бы у всех и из коробки и за даром. Нырните в ад voip и грабли которые накручены из-за nat, почему нужны такие костыли как stun,turn,ace когда может быть простая и явная маршрутизация?
погуглите сколько людей
на фоне общего числа пользователей — пренебрежимо малое количество.
пробросить порты для игр по сети
не играю, но подозреваю, что современные игры вовсе не умеют p2p без сервера.
Нырните в ад voip
для рядового пользователя это звонки в вотсапе, изредка в скайпе. и они у него работают, на ipv4
Веб это не только котики в соц сетях :)
разве? )
выше правильно сказали:
Расскажите мне домохозяйке с пятого подъезда зачем ей надо тратить дополнительные 100 рублей на IPv6? Как изменится ее жизнь? Что она получит такого, чего у нее нет сейчас?
нет платёжеспособного спроса ⟹ нет бюджета на внедрение ⟹ внедрение идёт десятилетиями
на фоне общего числа пользователей — пренебрежимо малое количество.
С таким подходом можно сказать что вообще кроме dns/http все остальные протоколы не нужны, ибо ими пользуется "пренебрежимо малое количество", но это ж бред :)
И почему вы все сводите к домохозякам? Вон, бизнес - найдите провайдера в странах СНГ где нормально имплементировали ipv6 что бы использовать его в бизнесе. Таких провайдеров раз-два и все. К - конкуренция.
Вон, бизнес — найдите провайдера в странах СНГ где нормально имплементировали ipv6 что бы использовать его в бизнесе
так то же самое, спроса со стороны бизнеса тоже нет.
я могу решить завтра внедрять ipv6 в сети предприятия на работе, только:
- потрачу на это кучу сил и времени (я думаю, что проект не на месяц);
- техподдержка меня возненавидит;
- окончательно от ipv4 избавиться не получится, ибо окажется, что какой-нибудь контроллер холодильной камеры на складе не умеет ipv6.
и главный вопрос: а что в итоге выиграет бизнес?
никто не спорит с тем, что ipv6 решает проблемы ipv4. только за то время, пока ipv6 готовился к внедрению, проблемы ipv4 научились решать/обходить.
единственная реальная проблема, которая может подтолкнуть внедрение: дефицит блоков ipv4 (пока именно дефицит, кончились они только у ripe, на рынке адреса и продаются, и сдаются в аренду; но цены неизбежно растут).
Каждой лампочке не нужен белый IP, это будет просто рай для взломщиков, если все устройства свои порты в интернет выставят.
6rd, 6in4, teredo и тд.
Вы говорите про доп номер с уровня человека который не шарит в сетях в принципе, не вышло бы там так, просто поверьте или разберитесь. По поводу рая для хакеров: я вам отвечу - все в точности и наоборот. Ipv4 интернет это гнилое место зашумленное ботами, сканерами, брутфорсерами, не явной маршрутизацией и наличие у лампочки своего ip не меняет того факта что она не доступна из вне на прямую всем и вся, это распространенное грубое заблуждение. Имея продакшн системы на ipv4 & ipv6 могу сказать что мусорного трафика на ipv6 нет вообще. Под мусорным трафиком я подразумеваю сканирование портов, ip, brute force атаки и тд, сюда я не отношу веб ботов что лазят по сайтам, ибо те оперируют доменами, а не ip, и это немного другая картина. Сканировать ipv6 просто нет смысла ибо это займет вечность, а ipv6 имеет не статичиские адреса для конечных клиентов для анонимности.
Каждой лампочке не нужен белый IP, это будет просто рай для взломщиков, если все устройства свои порты в интернет выставят.
С одной стороны, да все так и есть. Со второй - найти ту же лампочку в пуле /64 не так то и просто.
Фишка в том что кто лампочке будет открывать входящий трафик и зачем? Весь iot работает по принципу исходящих подключений, дешёвого mqtt, и им в принципе никто порты из мира не откроет ибо это и не нужно.
У меня дома 3 китайских камеры, по умолчанию все порты у них открыты, и по rtsp можно получить поток с камеры без авторизации. Я не хочу им давать ipv6.
найти ту же лампочку в пуле /64 не так то и просто.
Это пока мало кто ее ищет, чем больше ботов тем выше шанс, а он есть и сейчас.
У меня дома 3 китайских камеры, по умолчанию все порты у них открыты, и по rtsp можно получить поток с камеры без авторизации. Я не хочу им давать ipv6.
это как раз то о чем я пишу: вы слепы и не понимаете и не читаете что на шлюзе есть браундмауер и по умолчанию весь входящий трафик заблокирован? :\
Это пока мало кто ее ищет, чем больше ботов тем выше шанс, а он есть и сейчас
Я всем всегда говорю что obscurity != security, но в плане ipv6 - реально не сейчас, не завтра, ни когда останется только ipv6 никто не будет "искать" каждый ip в /64 пуле. Если сейчас что бы просканировать базовые сервисы на стандартном ipv4 занимает 30 секунд и считать что icmp echo заблокирован. То что бы просканировать 64 подсеть, нужно с такими же темпами, нужно 2^64*30\60\60\356 и выйдет: 431,805,806,968,856.5 лет. Ну сканируйте на здоровье... Останется только сканирование dns по dictionary и резолвинг их в ip, и сканирования уже этого ip - сейчас такое есть, оно будет улучшатся, но не более.
не понимаете и не читаете что на шлюзе есть браундмауер и по умолчанию весь входящий трафик заблокирован? :\
Да, не понимаю как одновременно может быть p2p и шлюз который трафик блокирует. Если по умолчанию весь трафик блокирует шлюз, то в чем отличия от нат?
Нат -- это, упрощённо, маскарадинг. То есть, подмена адреса отправителя/получателя. Это всего лишь одна из фич фаервола. Контролем доступа занимается как раз сам фаервол, который отслеживает соединения (через conntrack), блокирует входящие соединения, либо все подозрительные пакеты.
Допустим, без фаервола, но с NAT может быть такая ситуация, что на роутер с WAN-интерфейса прилетит пакет, у которого установлен адрес получателя внутри вашей сети. И роутер не отобьёт этот пакет, а доставит в вашу локальную сеть.
Это называется явная маршрутизация. Когда вам нужно будет сделать исходящее соединение вы его сделаете и после этого в пределах той сессии вам смогут приходить пакеты от того кому вы отправили пакет. А если захотите сделаете себе разрешение для 1 ip и порта, и будете ходить когда хотите. Поучите сети лучше :)
Это я понимаю, если у устройства по умолчанию все порты закрыты, тогда неважно за натом оно или напрямую смотрит в интернет. А если камера имеет открытый порт на просмотр видео без пароля, и смотрит ipv6 в интернет, разве не может любой в интернете посмотреть через этот порт в камеру? Сейчас, пока камера находится за ipv4 рoутером, он не пускает любого на нее посмотреть, тупо скрывая что камера есть, но если камера конектится к серверу китайскому, может получить от него инструкции какието.
Разве в случае, если камера получит ipv6 она не будет уязвима?(допустим какойто бот угадал ее ip, сможет ли он посмотреть ее) Разве роутер все равно будет все равно запрещать конект к камере извне без дополнительных настроек? Если так, то я срочно иду изучать сети.
не читаете что на шлюзе есть браундмауер и по умолчанию весь входящий трафик заблокирован? :\
а как же
нырните в ад voip и грабли которые накручены из-за nat, почему нужны такие костыли как stun,turn,ace когда может быть простая и явная маршрутизация?
из соседних комментариев?
как говорится, или крестик снимите, или трусы наденьте:
или ipv6 удобен и решает проблемы p2p, или же по умолчанию входящие соединения запрещены и для их разрешения нужно предпринимать какие-то действия. и как быть со случаями, когда файрвол вне нашего контроля? мобильные сети, например.
а как же
нырните в ад voip и грабли которые накручены из-за nat, почему нужны такие костыли как stun,turn,ace когда может быть простая и явная маршрутизация?
из соседних комментариев?
как говорится, или крестик снимите, или трусы наденьте
Все тут логично, вы явно путаете клиента и сервер или просто ворнякаете что бы варнякать :)
Ваш voip шлюз (sip к примеру с портами 5060/tcp&upd & sip over ssl 5061/tcp) должен принимать входящие соединения, ибо это сервер Карл. Мало того нужно еще разрешить входящий UDP для media диапазона настроенного на asterisk (или что там у вас). Клиенты по ipv6 подключаться и все хорошо работает. В ipv4 с NAT начинается: указите в asterisk публичный ipv4, или ddns, на клиенте за nat удостоверьтесь в работе stun, а иначе гайки.
или ipv6 удобен и решает проблемы p2p, или же по умолчанию входящие соединения запрещены и для их разрешения нужно предпринимать какие-то действия
В случае клиент - сервер архитектуры сервер всегда должен открыть свои порты на inbound, это логично, нет?
и как быть со случаями, когда файрвол вне нашего контроля? мобильные сети, например.
А вы собираетесь поднимать "сервер" на мобильном интернете? О_о
Быть так же как и в ipv4 - звонить в support и просить разлочить или менять isp.
Все тут логично, вы явно путаете клиента и сервер или просто ворнякаете что бы варнякать :)
так в том-то и дело, что любой p2p смешивает понятия клиента и сервера: sip-клиент, торрент-клиент, вы писали про старые игры.
для работы их за nat придумали всякие upnp, stun и прочие.
теперь вы говорите, что ipv6 всё изменит, все эти костыли будут не нужны, всё будет работать из коробки. только надо будет найти администратора файрвола шлюза и попросить его открыть входящие соединения.
то есть вроде бы по частям всё верно: могут сервера работать из коробки? может. могут быть на файрволах закрыты входящие соединения? могут.
но при попытке совместить получаются трусы и крестик.
так в том-то и дело, что любой p2p смешивает понятия клиента и сервера
могут быть на файрволах закрыты входящие соединения? могут.
но при попытке совместить получаются трусы и крестик.
только надо будет найти администратора файрвола шлюза и попросить его открыть входящие соединения.
По моему это у вас трусы и крестик головного мозга. Скрепы трешат?
То вы пол года доходили что входящий трафик не разрешон по умолчанию, теперь вы пол года будете доходить до того что вы это должны на шлюзе настроить на вкладке firewall и вы о ужас должны управлять firewall так же как и делать nat (но не будет double nat), а год доходить о том что NAT, UPnP & stun это костыли, если вообще дойдет...
ещё раз: далеко не всегда управление файрволом доступно пользователю.
и в итоге мы потенциально имеем две ситуации:
- на файрволе по умолчанию входящие соединения разрешены, тогда имеем новую реальность с каждым устройством, доступным из интернета.
да, перебор ipv6-адресов не особо осмысленен, да и большинство устройств уже готовы «торчать голой жопой в интернет». но, всё-таки, уверен, успешные атаки со временем появятся; - на файрволе по умолчанию входящие соединения запрещены, если файрвол не наш, то возвращаемся к ситуации, которая была с ipv4 с nat (более того, техники соединений двух хостов за натом, которые работали в ipv4 c cgnat, тут неприменимы по причину отсутствия nat).
какой подход используется, например, сотовыми операторами, я не знаю, подозреваю, что первый.
да и фиксированные провайдеры часто выдают домашним клиентам преднастроенные роутеры без возможности конфигурирования пользователем, как они будут настроены — не знаю, подозреваю, что у разных операторов по-разному.
Мне кажется вы путаете функционал фаервола и ната. И говорите что это одно и то же и проблемы те же. Это в корне не так. Большая часть проблем клиентов, которые должны выступать сервером, это нат а не фаервол.
Большая часть проблем клиентов, которые должны выступать сервером, это нат а не фаервол
и чем файрвол с политикой «отклоняем все входящие соединения» лучше, чем nat?
Мне кажется вы путаете функционал фаервола и ната. И говорите что это одно и то же и проблемы те же
разумеется, это не одно и то же.
но это не мешает быть проблеме подключения из интернета к хосту за nat/firewall быть общей.
Вот, вы сейчас абсолютно точно описали главную проблему IPv6. Что не получится безопасность и внутренние сервера/p2p одновременно! Именно потому, что на железке мобильного провайдера, которая в ipv4 занималась натом, теперь будет то же самый conntrack, только на v6. И точно так же будут рубиться входящие и межклиентские, ибо иначе у юзеров поломают их дырявые телефоны через старые уязвимости и они прибегут жаловаться.
А вот неправы вы в другом. V6 даст возможность получать либо безопасность, либо p2p. Галочка в личном кабинете "1. Трусы 2. Крестик" :). Ну то есть по умолчанию у всех разрешены только исходящие соединения, тот же conntrack, просто без ната, но продвинутый юзер может его отключить, согласившись что теперь за все свои дыры отвечает он сам. И вот это введение птички и есть необходимый шаг для получения профита от v6. Иначе есть только 2 варианта - либо ко всем полезут через дыры в лампочках, либо будет та же невозможнсть p2p, но с адресами в 4 раза длиннее.
Увы не однократно сталкивался с ДЦ у которых ipv6 сделан на "авось", статика без prefix delegation, без dhcpv6, без следования рекомендациям ripe как выделять пулы конечным потребителям. Ripe даже описали какие "отступы делать", что бы в случае когда клиент захочет больше IP ему можно было бы просто выдать сосдний с его текущим пул, или расширить существующиц.
Один ДЦ вообще хотел давать /128 и все, при том что на ipv4 он мне дал /29. Когда я сказал что мне положено /48, или хотя бы /56 подсеть они сделали квадратные глаза, спросили зачем мне так много и что мне это обойдется как крыло от самолёта. В итоге я им обьяснил насколько они не правы, намекнул на то сколько у них /32 подсетей и "сколько стоит /48 подсеть - 0.1 цента", что ipv6 так не строится. В итоге - получил свою /48 которая оказалась статикой, которую без npdproxy не завести, разозлился, кинул им пару док с сайта ripe, порычал и пошел на tunnelbroker создавать еще один тунель... (facepalm). Так что да, основная проблема это специалисты, и отсутствие желания вкладывать в это деньги, так как что бы что то поменять нужно время, а время это деньги.
порычал и пошел на tunnelbroker создавать еще один тунель...
хм, это же лишние задержки
Они не настолько велеки что бы быть ощютимыми, как и mtu ниже. Конечно я бы рад иметь нативный ipv6, но, не судьба.
Они не настолько велеки
скажите а вы в какую страну приземляете и откуда
у меня есть несколько из разных точек приземлённых на урале и в сибири, задержки ужас, скорость тоже не впечатляет. но я думал это норма учитывая что до точки где терминируется трафик не каждый конь доскачет. но может я был не прав и можно улучшить ситуацию?
Недавно в чате про IPv6 обсуждалась такая проблема: из-за того, что по DNS надо резолвить оба адреса (А / IPv4 и AAAA / IPv6), интернет на дуалстеке работает чуть медленнее (задержка пару миллисекунд при DNS запросе, сначала посылается АААА, потом А). На 4pda писали, что отключение IPv6 делает приложения более отзывчивыми.
Даже на NAT64 подключении все равно посылается 2 запроса. При этом, если не запущен CLAT, и IPv6 адрес нерабочий по каким-то причинам, по IPv4 подключение не идёт и запрос IPv4 адреса вообще зря выполняется. Сайт сотового оператора Мегафон относится к таким ресурсам (у него есть IPv6 адрес, но нерабочий).
Не сказано про мобильных операторов. Вот вы хотите поставить на даче камеру и подключаться к ней. На IPv4 у вас не получится никак без привлечения внешних сервисов: внешних адресов операторы не дают, а по внутренним связь недоступна. А внешние сервисы - это зависимость от кого-то или необходимость их поддерживать. Кроме этого, с сервисом со стороны камеры нужно держать соединение, чтобы операторский NAT транслятор не забыл о ней, что ест трафик. Хотя есть ещё вариант, я даже видел на одной сигналке реализацию: на клиенте дома внешний IP и проброс портов, на сигналку посылается СМС с этим внешним IP и портом, она подключается к приложению для управления. Но это костыльно, и через браузер на простом веб-интерфейсе не работает, нужен специальный клиент, принимающий входящие подключения, и внешний IP на клиенте.
А на IPv6 это возможно. Хотя операторы не дают статические IPv6 адреса, поэтому придётся либо с динамическим DNS заморачиваться (хотя это тоже внешний сервис), либо какой-то другой способ передачи адреса использовать, хоть по СМС.
С IP-телефонией то же самое, для IPv4 нужны костыли, с IPv6 гораздо проще, можно просто звонить с телефона на телефон по IP-адресу или DNS-имени (хотя тогда тоже динамический DNS может понадобиться), даже SIP-сервер не обязателен.
В России IPv6 есть пока только у одного сотового оператора, это МТС. По слухам, тестированием занимается Мегафон, скорее всего скоро он станет вторым.
Выглядит правда так себе, но хорошая новость в том, что в таких адресах можно сократить нули слева направо, поэтому большой адрес можно записать вот так, что гораздо симпатичнее.
2001:0db8:0000:0000:0000:0000:0010:ad12
2001:db8:10:ad12
Вы точно понимаете что пишете?
А почему 2001:db8:10:ad12 это именно 2001:0db8:0000:0000:0000:0000:0010:ad12, а не 2001:0000:0db8:0000:0000:0000:0010:ad12 или 2001:0000:0000:0000:0000:0db8:0010:ad12 ?
Если вы ниже пишете, что до сих пор многие не умеют настраивать IPV6, так это в том числе и из-за статей с такими ошибками.
Во-вторых, спроектировать протокол в 70-х, с которого даже сейчас не могут спрыгнуть, настолько он удобный - это совсем не "спроектировать с ошибками". Это значит очень круто спроектировать, что уже понимая и технические проблемы и проблемы бизнеса, IPV6 спроектировали так, что на него так неудобно переходить.
Я думаю неудобно переходить, потому что 40 лет учили ipv4 и оно воспринимается как "просто", ибо знаешь. За 40 лет как минимум 2 поколения специалистов изучило ipv4, а тут новое.
Совершенно несложно было добавить просто еще два октета и решить проблему недостатка IP адресов.
Или проблема недостатка IP адресов несколько надумана и вполне решается nat, ipv6 шлюзы и поиском огромных диапазонов неиспользуемых IP которые когда-то выделяли подсетями А и Б.
Или просто когда "продумывали" IPv6 очень плохо продумали что момент перехода должен быть максимально комфортным, а не менять вообще всю концепцию мирового интернета.
Про NAT ещё не совсем точно написали. Приведённый пример относится к тому, когда на роутере настроено перенаправление порта для приёма входящих соединений, хотя NAT чаще всего работает на исходящих.
Опишу жизненную ситуацию, которая больше похожа на NAT.
Есть Анна, она работает в одной из школ в Польше, преподаёт школьникам польский язык и русский как иностранный. Есть Мартин, польский школьник, который учится в одной из школ и и знает Анну. И есть я :) я живу в Москве и мы все готовы обменяться с кем-то открытками на Новый год. Мартин выступает в качестве клиента, а я - в качестве сервера, принимающего входящие соединения.
Анна узнала мой адрес (и адреса других желающих поучаствовать в обмене) и предложила ученикам написать открытки. Мартин заинтересовался, но у него нет желания обмениваться адресами (тем более, что дешевле послать несколько открыток в одном отправлении). Мартин знает обо мне (тут разница - в интернете он должен знать мой точный IP-адрес, но в этой ситуации это не обязательно, все равно информации обо мне достаточно, чтобы идентифицировать меня), знает об учительнице. Он пишет открытку, передаёт её учительнице, а она уже пересылает мне вместе с другими.
Как это выглядит с моей стороны? Я не знаю о Мартине, не знаю его адреса и не могу написать ему напрямую. У него может и не быть своего почтового адреса вовсе (внешнего IP). Я вижу, что мне пришла открытка с адреса Анны (NAT-шлюза), она имеет свой почтовый адрес (внешний IP), но там написано, что написал её Мартин. Значит, за Анной есть клиенты за NATом, она переводит внутренний адрес отправителя ("школьник Мартин из такого-то класса такой-то школы"), который недоступен мне, во внешний (почтовый адрес Анны), поэтому технология и называется NAT (Network Address Translation).
Но самое интересное в том, что NAT-шлюз запоминает соответствия.
Что будет, если я захочу ответить Мартину? Я вижу, что мне пришла открытка с адреса Анны, поэтому я отправляю ответ на её адрес и имя, но пишу на открытке, что она для Мартина (что пакет более высокого уровня OSI идёт не по основному соединению с Анной, а с Мартином). В TCP/IP для идентификации соединений служат номера портов, которые были бы разными для Анны и Мартина. Анна помнит, что Мартин передавал ей открытку для меня (это если с момента отправки прошло не слишком много времени, иначе она об этом забудет), поэтому она после получения ответной открытки передаёт её Мартину. В итоге Мартин может обменяться со мной открытками, не имея глобального почтового адреса (внешнего IP), у него есть только внутренняя идентификация как какого-то ученика какой-то школы, которая мне ни о чём не говорит и по которой я не могу связаться с ним.
А в мире IPv6 у него должен быть какой-то свой идентификатор, например, свой почтовый адрес, и он написал бы мне напрямую. Он мог бы тоже передать открытку учительнице, чтобы она отнесла её на почту, но указал бы свой адрес, и получил бы ответ сам, независимо от учительницы. Если у него нет своего почтового адреса, он мог бы указать почтовый адрес школы в поле "куда" и своё имя и фамилию (может и класс) в поле "кому". Его полная идентификация состояла бы из адреса школы (префикса сети) и своей внутренней идентификации (ID узла). Разница с предыдущим случаем заключалась бы в том, что я увидел бы полный идентификатор Мартина и отправлял бы ответ именно ему, указав на конверте его имя, класс и адрес школы. При этом не нужно запоминать соединения. Анна могла бы пойти в отпуск, но сотрудник школы, обрабатывающий входящую почту, смог бы передать открытку Мартину по данным на конверте, и он получил бы свою открытку и независимо от Анны.
Когда ipv6 дойдёт до массового использвоания?) я уже 15 лет слышу что ipv4 все. Успею ли до пенсии застать это) лет за 30 управятся?
Мне кажется, основной недостаток IPv4 в том, что в своё время слишком много адресов было бездумно выделено абы кому. И вместо того, чтобы придумать механизм отжима IPv4 у всех, кто не может показать целесообразность владения огромными пулами IPv4, был придуман сверхизбыточный IPv6. Который тоже может резко закончиться, если выдавать его также бездумно, как и IPv4.
IPv6 фактически пригодится только тем пользователям, кому нужно больше 1 публичного IP.
Что такое и зачем нужен IPV6? Разбор