так в том-то и дело, что любой p2p смешивает понятия клиента и сервера
могут быть на файрволах закрыты входящие соединения? могут.
но при попытке совместить получаются трусы и крестик.
только надо будет найти администратора файрвола шлюза и попросить его открыть входящие соединения.
По моему это у вас трусы и крестик головного мозга. Скрепы трешат?
То вы пол года доходили что входящий трафик не разрешон по умолчанию, теперь вы пол года будете доходить до того что вы это должны на шлюзе настроить на вкладке firewall и вы о ужас должны управлять firewall так же как и делать nat (но не будет double nat), а год доходить о том что NAT, UPnP & stun это костыли, если вообще дойдет...
нырните в ад 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.
Это называется явная маршрутизация. Когда вам нужно будет сделать исходящее соединение вы его сделаете и после этого в пределах той сессии вам смогут приходить пакеты от того кому вы отправили пакет. А если захотите сделаете себе разрешение для 1 ip и порта, и будете ходить когда хотите. Поучите сети лучше :)
У меня дома 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 - сейчас такое есть, оно будет улучшатся, но не более.
Что бы разницу заметить нужно что бы был он не только у вас :)
Существует для способа создания 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 закончатся и цена будет не подьемная, начинать рыпатся уже будет поздно и в результате куда более проблематично, в спешке и тяп ляп.
Да. Это единственный рабочий вариант multihome без asn, по крайней мере я сделал такой вывод для себя еще давно и других вариантов не знаю :)
В LAN вы используете подсеть 2000:a::/48, которую вам выдал основной WAN01. В NPt вы создаете правило: сменить 2000:a::/48 на 2002:b::/48 если трафик идет через WAN02. Понятное дело если вы захотите сделать SD-WAN, аля динамическую маршрутизацию на основе х условий, то будет дурдом и тут 100% нужен AS. Но, обычный failover переживет.
на фоне общего числа пользователей — пренебрежимо малое количество.
С таким подходом можно сказать что вообще кроме dns/http все остальные протоколы не нужны, ибо ими пользуется "пренебрежимо малое количество", но это ж бред :)
И почему вы все сводите к домохозякам? Вон, бизнес - найдите провайдера в странах СНГ где нормально имплементировали ipv6 что бы использовать его в бизнесе. Таких провайдеров раз-два и все. К - конкуренция.
Откройте гугл и напишите double nat problem. Веб это не только котики в соц сетях :) И если забыть что ip pool на дне, погуглите сколько людей пытается настроить upnp или пробросить порты для игр по сети. Люди доплачивают что бы иметь белый статичный ipv4, когда с ipv6 это было бы у всех и из коробки и за даром. Нырните в ад voip и грабли которые накручены из-за nat, почему нужны такие костыли как stun,turn,ace когда может быть простая и явная маршрутизация?
В сегменте провайдерского\телеком оброудования? Примеры в студию
У многих провайдеров городских до сих пор бушные 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 клиенты не искали новый.
Увы не однократно сталкивался с ДЦ у которых ipv6 сделан на "авось", статика без prefix delegation, без dhcpv6, без следования рекомендациям ripe как выделять пулы конечным потребителям. Ripe даже описали какие "отступы делать", что бы в случае когда клиент захочет больше IP ему можно было бы просто выдать сосдний с его текущим пул, или расширить существующиц.
Один ДЦ вообще хотел давать /128 и все, при том что на ipv4 он мне дал /29. Когда я сказал что мне положено /48, или хотя бы /56 подсеть они сделали квадратные глаза, спросили зачем мне так много и что мне это обойдется как крыло от самолёта. В итоге я им обьяснил насколько они не правы, намекнул на то сколько у них /32 подсетей и "сколько стоит /48 подсеть - 0.1 цента", что ipv6 так не строится. В итоге - получил свою /48 которая оказалась статикой, которую без npdproxy не завести, разозлился, кинул им пару док с сайта ripe, порычал и пошел на tunnelbroker создавать еще один тунель... (facepalm). Так что да, основная проблема это специалисты, и отсутствие желания вкладывать в это деньги, так как что бы что то поменять нужно время, а время это деньги.
Фишка в том что кто лампочке будет открывать входящий трафик и зачем? Весь iot работает по принципу исходящих подключений, дешёвого mqtt, и им в принципе никто порты из мира не откроет ибо это и не нужно.
Вы говорите про доп номер с уровня человека который не шарит в сетях в принципе, не вышло бы там так, просто поверьте или разберитесь. По поводу рая для хакеров: я вам отвечу - все в точности и наоборот. Ipv4 интернет это гнилое место зашумленное ботами, сканерами, брутфорсерами, не явной маршрутизацией и наличие у лампочки своего ip не меняет того факта что она не доступна из вне на прямую всем и вся, это распространенное грубое заблуждение. Имея продакшн системы на ipv4 & ipv6 могу сказать что мусорного трафика на ipv6 нет вообще. Под мусорным трафиком я подразумеваю сканирование портов, ip, brute force атаки и тд, сюда я не отношу веб ботов что лазят по сайтам, ибо те оперируют доменами, а не ip, и это немного другая картина. Сканировать ipv6 просто нет смысла ибо это займет вечность, а ipv6 имеет не статичиские адреса для конечных клиентов для анонимности.
По поводу найти железку которая не поддерживает 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.
Скажем так: о каком обходе gmail dmarc может идти речь когда у gmail чёрным по белому написано:
_dmarc.gmail.com. 600 IN TXT "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
И такое у многих freemail. Просто реклама smime. Я с таким же приколом могу дать ссылку на efail: https://efail.de и сказать что smime это тлен и он не работает от слова совсем, но это будет точно такая же не правда как и та что написана в статье, ибо у всего есть свои кондишены, есть свои недостатки, и просто делать такие вбросы ради рекламы, ну фу...
P.s. не иметь шифрования между клиентом и почтовиком, это куда более страшный кейс чем не иметь smime без которого все живут на ура и наличие smime не каким боком не защитит вашу авторизацию к серверу без шифрования, просто вброс. Настраивайте client => ssl => mta => ssl => mta и будет вам счастье. Увы да, протокол smtp не может никак гарантировать как другой клиент с обратной стороны подключиться к своему mta, но это уже не на вашей совести. Добиться mandatory client => ssl => mta очень просто настройками вашего почтового сервера. Добиться входящего mta => ssl => mta тоже не так уж и сложно с помощью dane/mta-sts или обоих вместе взятых. Dane поддерживают почти все уважающие себя mta, в отличие от mta-sts, минус только в том что для некоторых dnssec непостижимо сложен или TLD тормозит с внедрением. В случаях когда TLD тормозит внедрение dnssec можно хотя бы сам MX повесить на нормальный TLD с dnssec, этого уже будет достаточно для того чтобы заставить отправителей не падать в plaintext. Добиться исходящего mta => ssl => mta можно с помощью политик, и написать их для всех заведомо частых dst.
По моему это у вас трусы и крестик головного мозга. Скрепы трешат?
То вы пол года доходили что входящий трафик не разрешон по умолчанию, теперь вы пол года будете доходить до того что вы это должны на шлюзе настроить на вкладке firewall и вы о ужас должны управлять firewall так же как и делать nat (но не будет double nat), а год доходить о том что NAT, UPnP & stun это костыли, если вообще дойдет...
Все тут логично, вы явно путаете клиента и сервер или просто ворнякаете что бы варнякать :)
Ваш voip шлюз (sip к примеру с портами 5060/tcp&upd & sip over ssl 5061/tcp) должен принимать входящие соединения, ибо это сервер Карл. Мало того нужно еще разрешить входящий UDP для media диапазона настроенного на asterisk (или что там у вас). Клиенты по ipv6 подключаться и все хорошо работает. В ipv4 с NAT начинается: указите в asterisk публичный ipv4, или ddns, на клиенте за nat удостоверьтесь в работе stun, а иначе гайки.
В случае клиент - сервер архитектуры сервер всегда должен открыть свои порты на inbound, это логично, нет?
А вы собираетесь поднимать "сервер" на мобильном интернете? О_о
Быть так же как и в ipv4 - звонить в support и просить разлочить или менять isp.
я уже 5 раз сказал: ДА! (facepalm) идите и учите сети ...
Это называется явная маршрутизация. Когда вам нужно будет сделать исходящее соединение вы его сделаете и после этого в пределах той сессии вам смогут приходить пакеты от того кому вы отправили пакет. А если захотите сделаете себе разрешение для 1 ip и порта, и будете ходить когда хотите. Поучите сети лучше :)
это как раз то о чем я пишу: вы слепы и не понимаете и не читаете что на шлюзе есть браундмауер и по умолчанию весь входящий трафик заблокирован? :\
Я всем всегда говорю что 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 - сейчас такое есть, оно будет улучшатся, но не более.
Kiev - Warszawa & Kiev - Budapest. Один WAN на один ендпоинт, второй WAN на другой. По замерам одному пинг быстрее к Польше, а второму к Венгрии.
Они не настолько велеки что бы быть ощютимыми, как и mtu ниже. Конечно я бы рад иметь нативный ipv6, но, не судьба.
Что бы разницу заметить нужно что бы был он не только у вас :)
Устройства получают оба ip, temporary/anonymous и static/stable-privacy. Это поведение в некоторых ОС разное и настраиваемое. Можно и свою статику взять.
Вообще то да, про него.
Использовать нат что бы спрятать... в ipv6 такое не нужно просто.
Если говорить про маршрутизацию, то если в шлюзе есть маршрут до конечной цели то достучитесь вы что по ipv4, что по ipv6, если разрешено все и ничего не запрещено.
Один из вариантов. Второй вариант это gpo, третий - принт сервер. Если это тот же l2 сегмент то link-local. Правда сам замечал что сами дрова на принтеры не дружат еще с ipv6. Про сканеры: вообще отдельная тема, если у вас сканят до 20 человек, то да по сети скан на ПК ок, но в большинстве мфу с сетевым сканером больше подключить не получится и скан уходит либо на файлшару либо на емейл, а тут вообще пофиг какой ip у сканера :).
Я сам знаю что ipv6 only сеть это не реально в обозримом будущем. Но все же я считаю что с dualstack через счюр люди затягивают, тем более с учётом существующих атак на "пустующюю имплементацию ipv6". Я понимаю с чем это связано - по сути работы в 2 раза больше, настраивать нужно и то и то и отдельно друг от друга. Но если не двигается, то ничего и не поменяется совсем. А когда всем пригорит - когда все загашники ipv4 закончатся и цена будет не подьемная, начинать рыпатся уже будет поздно и в результате куда более проблематично, в спешке и тяп ляп.
Да. Это единственный рабочий вариант multihome без asn, по крайней мере я сделал такой вывод для себя еще давно и других вариантов не знаю :)
В LAN вы используете подсеть 2000:a::/48, которую вам выдал основной WAN01. В NPt вы создаете правило: сменить 2000:a::/48 на 2002:b::/48 если трафик идет через WAN02. Понятное дело если вы захотите сделать SD-WAN, аля динамическую маршрутизацию на основе х условий, то будет дурдом и тут 100% нужен AS. Но, обычный failover переживет.
Уходим по большей части, nat будет только при failover'е. Большую часть времени natа не будет.
С таким подходом можно сказать что вообще кроме dns/http все остальные протоколы не нужны, ибо ими пользуется "пренебрежимо малое количество", но это ж бред :)
И почему вы все сводите к домохозякам? Вон, бизнес - найдите провайдера в странах СНГ где нормально имплементировали ipv6 что бы использовать его в бизнесе. Таких провайдеров раз-два и все. К - конкуренция.
Я писал выше про multihome, почитайте ;)
Откройте гугл и напишите double nat problem. Веб это не только котики в соц сетях :) И если забыть что ip pool на дне, погуглите сколько людей пытается настроить upnp или пробросить порты для игр по сети. Люди доплачивают что бы иметь белый статичный ipv4, когда с ipv6 это было бы у всех и из коробки и за даром. Нырните в ад voip и грабли которые накручены из-за nat, почему нужны такие костыли как stun,turn,ace когда может быть простая и явная маршрутизация?
У многих провайдеров городских до сих пор бушные d/tp-link которые реально не сном не духом об ipv6. По mikrotik слышал жалобы на проблемы в стабильности имплементации ipv6, сам не юзаю давно, не скажу когда и как. То же unifi оборудование на основе unifi network controller, да, не провайдерский сегмент конечно, но они вообще ни сном ни духом про ipv6 почти, и то что они могут по ipv6 больше похоже на комтыль чем имплементацию.
Домохозяйке это не нужно, а вот:
ее сыну страдающему от того что он свой сервер Minecraft захостить не может из-за CGNAT - да
людям которым голос жует во время конференции из-за отсутсвия нормальго p2p соединения
людям которые мучаются с NAT и отсутствием возмоности заюзать дефолтные порты когда есть несколько сервисов на разных устройствах
людям которые понимают что upnp дырявое зло, и прямой бекдор без авторизации и смс, но дома от него они не могут отказаться из-за p2p: voip, games, file transfer и тд
Лозунги придумывать не моя задача, я не маркетолог и не мыслю как домохозяйка, но до ее чада и гиков пользу донести можно без проблем. Плюс наличие ipv6 должно быть как раз одним из факторов привлечения новых клиентов от других провайдеров и не должно влиять особо на конечную стоимость.
SLAAC не рандомный. Берется link local, prefix и вуаля. Открываете тому кому нужно и все. Это не отличается от того что вы даете статику по MAC на ipv4 и делаете nat, ничем, кроме того что вам даже не нужно настраивать статику.
Если у вас есть nat проброс, а ответного правила в allow в firewall - нет, то и доступа не будет, что за глупости?
При использовании Ipv6, вещи типа принтеров вообще будут подключены через mdns, bonjour или link local. А в случае использования принт сервера проблем - 0. В всех остальных случаях все так же - юзайте dns/mdns, он и создан что бы не мучаться с ip, и в случае смены ip клиенты не искали новый.
Увы не однократно сталкивался с ДЦ у которых ipv6 сделан на "авось", статика без prefix delegation, без dhcpv6, без следования рекомендациям ripe как выделять пулы конечным потребителям. Ripe даже описали какие "отступы делать", что бы в случае когда клиент захочет больше IP ему можно было бы просто выдать сосдний с его текущим пул, или расширить существующиц.
Один ДЦ вообще хотел давать /128 и все, при том что на ipv4 он мне дал /29. Когда я сказал что мне положено /48, или хотя бы /56 подсеть они сделали квадратные глаза, спросили зачем мне так много и что мне это обойдется как крыло от самолёта. В итоге я им обьяснил насколько они не правы, намекнул на то сколько у них /32 подсетей и "сколько стоит /48 подсеть - 0.1 цента", что ipv6 так не строится. В итоге - получил свою /48 которая оказалась статикой, которую без npdproxy не завести, разозлился, кинул им пару док с сайта ripe, порычал и пошел на tunnelbroker создавать еще один тунель... (facepalm). Так что да, основная проблема это специалисты, и отсутствие желания вкладывать в это деньги, так как что бы что то поменять нужно время, а время это деньги.
Фишка в том что кто лампочке будет открывать входящий трафик и зачем? Весь iot работает по принципу исходящих подключений, дешёвого mqtt, и им в принципе никто порты из мира не откроет ибо это и не нужно.
6rd, 6in4, teredo и тд.
Вы говорите про доп номер с уровня человека который не шарит в сетях в принципе, не вышло бы там так, просто поверьте или разберитесь. По поводу рая для хакеров: я вам отвечу - все в точности и наоборот. Ipv4 интернет это гнилое место зашумленное ботами, сканерами, брутфорсерами, не явной маршрутизацией и наличие у лампочки своего ip не меняет того факта что она не доступна из вне на прямую всем и вся, это распространенное грубое заблуждение. Имея продакшн системы на ipv4 & ipv6 могу сказать что мусорного трафика на ipv6 нет вообще. Под мусорным трафиком я подразумеваю сканирование портов, ip, brute force атаки и тд, сюда я не отношу веб ботов что лазят по сайтам, ибо те оперируют доменами, а не ip, и это немного другая картина. Сканировать ipv6 просто нет смысла ибо это займет вечность, а ipv6 имеет не статичиские адреса для конечных клиентов для анонимности.
По поводу найти железку которая не поддерживает 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?
Скажем так: о каком обходе gmail dmarc может идти речь когда у gmail чёрным по белому написано:
И такое у многих freemail. Просто реклама smime. Я с таким же приколом могу дать ссылку на efail: https://efail.de и сказать что smime это тлен и он не работает от слова совсем, но это будет точно такая же не правда как и та что написана в статье, ибо у всего есть свои кондишены, есть свои недостатки, и просто делать такие вбросы ради рекламы, ну фу...
P.s. не иметь шифрования между клиентом и почтовиком, это куда более страшный кейс чем не иметь smime без которого все живут на ура и наличие smime не каким боком не защитит вашу авторизацию к серверу без шифрования, просто вброс. Настраивайте client => ssl => mta => ssl => mta и будет вам счастье. Увы да, протокол smtp не может никак гарантировать как другой клиент с обратной стороны подключиться к своему mta, но это уже не на вашей совести. Добиться mandatory client => ssl => mta очень просто настройками вашего почтового сервера. Добиться входящего mta => ssl => mta тоже не так уж и сложно с помощью dane/mta-sts или обоих вместе взятых. Dane поддерживают почти все уважающие себя mta, в отличие от mta-sts, минус только в том что для некоторых dnssec непостижимо сложен или TLD тормозит с внедрением. В случаях когда TLD тормозит внедрение dnssec можно хотя бы сам MX повесить на нормальный TLD с dnssec, этого уже будет достаточно для того чтобы заставить отправителей не падать в plaintext. Добиться исходящего mta => ssl => mta можно с помощью политик, и написать их для всех заведомо частых dst.
Плюсую, тот же mitm6 приплетен за уши об обратном - что будет если в сети нет ipv6, и его кто либо "задействует во зло". А все остальное просто база.