Это просто туннелирование, оно никоим образом не решает вопрос оперирования конечных устройств по новому протоколу и фактически означает не-переход на новый протокол.
Учитывая цикл обновления оборудования провайдерами и пересмотра архитектуры, я думаю, что в ближайшие 5 лет основной тренд будет в переводе публичных ресурсов на DualStack и предоставление IPv6 по умолчанию. Сама миграция (включая внутренние сети) - ближайшие 10-15 лет.
Включить пространство v4 в v6 это не проблема вообще. Проблема во всем прочем - нельзя было сделать обратную совместимость, даже просто увеличив поля под адреса в заголоке. Проблема не в IPv6, а в IPv4, последний не поддается модернизации.
Но опять же, решить только проблему нехватки адреса - это костыль, который не решал прочие врожденные недостатки IPv4. И когда стало ясно, что совместимости не будет даже при минимальных изменениях, то было решено создать новый протокол с нуля и заодно исправить недочеты предыдущего протокола. И это правильно.
ну такое себе. во-первых, это сразу сильно сужает выбор провайдеров.во-вторых, вероятность того, что два канала одного провайдера перестанут работать вместе, остаётся высокой.
Спрос рождает предложение. Сейчас найти такие предложения не составит труда, все провайдеры работающие с сегментом B2B в состоянии предложить подобное решение. Тем более, что такие решения не тербуют капитальных затрат для провайдера, ни на оборудование, ни на архитектуру. Связка технологий дана для примера, это может быть FTTx+Mobile, FTTx+xDSL, FTTx+SAT и т.д. или в любых других комбинациях и технологиях. Даже для связки +Mobile не обязательно быть сотовым оператором, можно быть MVNO. B2B вообще гораздо более гибок в этом плане.
То, что два канала одного провайдера перестанут работать вместе очень низка, так как возможные SPOF могут быть только на уровне сетей доступа, а все что выше, начиная от агрегационных сетей и бекбона, имеет избыточность как минимум n+1. Сети наземного доступа и мобильного доступа (RAN) это физически раздельные сети (как минимум до уровня агрегации), а глобальный инцидент если и возможен, то провайдер имеет контрактное обязательство устранить неполадки в течении согласованного времени (SLA обычно 4 часа). Вот если гипотетический простой в 4 часа неприемлим для клиентского бизнеса, то подключаться к двум разным провайдерам имеет смысл.
так-то оно так, но адреса ipv4 кончились уже несколько лет как, но их можно купить/арендовать, плюс цена за адрес снижается.
Можно. Но это как из детской сказки - сколько можно сделать шапок из одной шкуры? 2 можно? Можно. А 3? Можно. А 5? Можно. Хоть 10, если не оговаривать размер получаемых шапок. Так и с IPv4. Можно выкручиваться, докупать адреса, ставить динамический CGNAT и начинать шарить каждый адрес на все большее и большее количество абонентов. Можно так делать? Конечно! Работать будет? Вполне. Некоторое время. Только доступный абонентам сервис будет все уже и уже. Доступ извне? Зачем? P2P сети? Ненужно. SIP телефония? Не скрепно. И т.д. Итог один : вместо поредоставления доступа в интернет, вы предоставляете некий доступ к некому сервису. "Доступ к VK и Госуслугам из дома", "чат с друзьями в MAX", "видео с Рутуба". Остальные пртоколы и сервисы вам не нужны, значит и нечего огрод городить. Тем более заморачиваться с IPv6 от которого ничего кроме головной боли. Мы как-то проглядели момент, когда временное и приносящее неудобства и ограничения решение NAT на IPv4 стало теплым и ламповым, а полноценная свобода доступа в инет стала пугающей и ненужной.
Кстати, цены на блоки IPv4 снижались, но похоже стабилизировались и начинают снова расти в цене. Есть много трактовок причин, суть в том, что это не принципиальное падение интереса к IPv6, а не более чем отсрочка в процессе перехода.
вот смотрите, есть город, есть сотни магазинов в нём.магазинам нужен бесперебойный интернет (эквайринг и всё такое). обычно это решается резервным каналом связи. в вашей картине мира нужно получать по AS на каждый магазин?
Нет, конечно. Все же выриант с AS это тотальное решение, когда сеть должна иметь не только резервный канал, но еще и через независимого провайдера. В большинстве случаев для малых клиентов такое резервирование черезмерно, достаточно резервирования через два канала одного провайдера, но по разным технологиям - например FTTO + 4G/5G. В этом случае гараздо проще предоставить клиетну один и тот же PD через оба пути. Клиент защищен от сбоев в разных сетях доступа (Landed vs RAN), а там где общая часть провайдеской сети (бекбон, пиринги) - SLA контракта с провайдерм. Собственно, сегодня это распространенный пакет предлагаемый многими провайдерами для B2B.
и дуалстек получается тупиковая ветвь — возни больше, чем с чистым v4, а выхлопа вообще не видно.
...если не держать в голове, что DualStack это решение переходного периода и так или иначе исчезнет с переходом к чистому IPv6. Независимо от отношения к IPv6, переход на него неизбежен, потому как проблема исчерпания IPv4 никуда исчезнуть не может, а IPv6, помимо решения проблемы адресации, является более оптимальным с точки зрения сетевых техноглогий. Как именно реализовывать доступ для v4 - это второстепенный вопрос, ибо зависит от конкретных условий.
с динамическим префиксом-то? ну так себе…да и практика показала, что задачи «нужно чтобы все хосты локалки были доступны из инета» нет.
Динамическим - это двусмысленный термин. Префиксы должны назначаться статично, а вопрос доступа решается разными путями. Если ода префикса розданы хостам и оба доступны одновременно, то DNS можно резолвить в оба. Если динамическая замена - DynDNS. Может есть еще варианты, надо подумать.
Рассуждать о такой задаче в общем виде довольно бессмыслено, решения есть и другой вопрос - какое из них оптимально, но оптимальным оно может быть только под конкретную ситуацию и задачи.
вроде как теперь куда-то на учёт надо вставать, а то и СОРМ за свой счёт ставить…дальше, возьмём какой-нибудь магазин, основной канал через кабель, резервный — сотовый оператор, ему тоже свою AS получать? BGP настраивать? вы серьёзно?
Я, кстати, не знал про такой выверт российского законодательства. Но было бы странно, чтобы дизайнеры протокола учитывали непредсказуемость Фемиды в каждом отдельном государстве, с другой - да, выбирая оптимальное решение приходится брать такое в расчет.
Если же мы говорим про клиента как юрлицо, то большинство операторов могут предложить решение с предоставлением AS и пула, который может быть анонсирован через другого провайдера (даже при том, что выдаваемый пул входит в глобальный пул выдающего оператора). Тем более что крупные операторы обычно явдяются LIRами и могут зарегистрировать PI для клиента. Я не уверен, что клиент подпадает под требование установки СОРМ, так как не является саб-провайдером и не имеет нисходящих клиентов.
и как сделать в таком случае, например, «весь трафик в РФ идёт с префиксом A, а за границу — с префиксом B»? пихать таблицу маршрутизации с тысячами записей на все устройства в сети? что-то такое себе. а если просто балансировку между каналами делать?
На уровне хостов - никак. Собственно два PD это решение Active/Backup, оно не подразумевает специфичной логики маршрутизации или лоад-балансинга. Хотя последний может быть возможно реализовать посредством MP-TCP.
мне гораздо привычнее схема, когда маршрутизация задаётся на одном месте, на роутере
Мне тоже. Но дизайн IP подразумевает в этом случае либо отдельную AS и динамический роутинг с аплинками, либо шаманство в виде NAT, PBR и т.д.
именно. тут мы имеем трудозатраты по внедрению ipv6, но не получаем никаких плюсов. и да, чтобы всё работало нам ещё nat64/dns64 надо настроить. ибо ipv4-only сервера сплошь и рядом, а ipv6-only кроме ntc.party и не встречал
Трудозатраты относительно небольшие, по крайней мере те же по сравнению с подобной схемой с NAPT на IPv4. Но выгода все же есть. NPT66 не NAPT, нет манипуляции с портами, так что хосты внутри сети могут быть доступны извне, а значит главное преимущество IPv6 сохраняется.
nat64/dns64 - это при условии, что провайдерская сеть IPv6Only. Ежели она DualStack, то эта проблема отпадает. Но даже случай IPv6Only - это тоже не архисложно, но метод зависит от архитектуры провайдера.
Использование серых адресов сейчас, точнее последние 5 лет. Я собственно нигде это и нее отрицал. Но речь шла о десятилетиях использованя публичных статичных адресов IPv4 для ШПД.
Вы решили ткнуть меня носом в положение дел во Франции и ссылаетесть на сайт https://www.broadband.co.uk/ дающий обзор английских операторов? С вами все в порядке?
The four operators all have different IPv4 address sharing practices depending on their fixed network technologies:
- The majority of Free fixed network customers (75% in xDSL and 85% in FttH) as well as a small proportion of Bouygues Telecom customers (5% in xDSL and 2% in FttH) have a shared IPv4 address. However, these ISPs offer a dedicated IPv4 address free of charge on request.
- As of this year, some SFR customers also have a shared IPv4 address (8% in FttH) and this operator does not offer a dedicated IPv4 address on request for these customers.
- With regard to fixed 4G access, while Bouygues Telecom and SFR customers have a dedicated IPv4, Free and Orange customers have a shared IPv4 address.
These two ISPs do not offer dedicated IPv4 for fixed 4G.
- This sharing of IPv4 between several customers could become generalized in the coming years to face the shortage of IPv4.
И это при том, что отчет концентрируется именно на введении shared адресов операторами в последние годы, а не о практике существовавшей десятилетиями и приведшей к исчерпанию. Но вы же разбираетесь в теме, не так ли?
Необязательно речь идет о замене CPE, вполне возможно достаточна доработка софта. CPE поставляется провайдером? Тогда это затраты провайдера на доработку ПО CPE для поддержки MAP-T. Собственно это логично, так как необходимое изменение ПО связано с выбором архитектуры сети провайдером, точнее это часть провайдерской архитектуры. Если CPE личное пользовательское, то реализация MAP-T существует у многих производителей (включая OpenWRT). В конце-концов это не какой-то стремный хак, а стандарт (RFC7599).
Это собственно так и работает с применением MAP-T (или MAP-E).
CPE пользователя получает только IPv6 PD, используемый для адресации LAN пользователя. Так же эта LAN адресуется как обычно IPv4 RFC1918. Пользовательский трафика IPv6 роутится нативно. Трафик IPv4 декапсулируется на CPE, данные инкапсулируются (в случае MAP-T) в пакет IPv6, где адрес назначения IPv6 в части префикса содержит адрес BR (шлюз CGNAT), а в части интерфейса - переведенный в hex адрес назначения IPv4. Пакет нативно роутится через IPv6Only бекбон провайдера до BR, где данные декапсулируются из пакета IPv6 и создается пакет IPv4 с адресом назначения извлеченным их интерфейсной части адреса IPv6, а адресом источника IPv4 ставится публичный адрес IPv4 из пула на BR. Для ответного пакета трансляции происходят в обратном порядке.
В результате устройство, которые ранее мы называли словом роутер, теперь все равно должно оставаться, но выполнять функции сетевого экрана, причем изначально быть сетевым экраном, а не случайно-побочно, как NAT.
Собственно это и происходит де факто уже много лет. Обычный юзер не имеет (да и не должен иметь) желания собирать у себя целую сеть из отдельных узкоспециализированных устройств и для этого разбираться с кучей технологий и протоколов. Потому вполне логично, что необходимые функции и сервисы интегрируются в одну коробку - роутер, файерволл, точка доступа WiFi, шлюз IP телефонии, файловый сервер. Обьеденить все это в одной коробке логично как для провайдера (которому удобнее предоставлять все эти сервисы как единый пакет услуг в одной коробке), так и для пользователя, так как снимает с него всю головную боль. Наверно это звучит банально и очевидно, но это вполне естественное положение вещей.
Я несу вам свет знания о том, что происходит в мире.
Вас это возможно сильно поразит, но большинство крупных операторов в Западной Европе и в США десятилетиями предоставляют частным абонентам публичные IPv4 адреса. Без каких-либо красных флажков. Потому что это является нормальной ситуацией по-умолчанию.
Вы, конечно, можете жить согласно своей личной реальности, но прочая действительность к счастью об этом не в курсе. Мне как-то странно спорить и доказывать то, что является окружающим меня фактом, а так же доказывать выбор сделанный (а следовательно обоснованный технически и финансово) моей компанией - вторым по размеру и охвату оператором Франции. Как собственно и обьяснять положение дел в отрасли, в которой я работаю более 17 лет (и более 25 лет в IT).
Если вас интересует конструктивная беседа на тему - с удовольствием, если вы желаете спорить ради спора или вашего самоутверждения - простите, меня это не интересует. Уважайте собеседника и читателей.
Да я вроде ничего загадчного не говорил. Давайте с точки зрения провайдера.
Решается в перспективе вопрос исчерпания запасов IPv4 провайдера. Следует отметить, что западная традиция подразумевает выделение каждому абоненту фиксированного доступа одного постоянного публичного IPv4 адреса, так как иначе абонент не может считаться участником интернета. Это можно долго обсуждать, но стоит зафиксировать это как изначальное условие. Последствие - прямая угроза исчерпания резервов с ростом абонентской базы или потолок роста. Фиксированные CGNAT и MAP-T позволяют включить экономию и отсрочить исчерпание, выиграть время на массовый переход на IPv6, затем потребность в IPv4 станет уменьшаться. Но альтернативного решения нет. Использовать динамический CGNAT или более агрессивное соотношение трансляции (мы используем 1:8) значит предложить условия хуже конкурентов на рынке, для маркетинга и менеджмента это не приемлимо. Это прямые финансовые риски.
С MAP-T абонентский CPE получает только IPv6 адрес (вместо IPv4+IPv6 сегодня в DualStack). Это дает уменьшение требуемых ресурсов на BNG, упрощение процесса конфигурации CPE (DHCPv6 вместо DHCPv4+DHCPv6 сегодня), упрощение обслуживания базы Radius OSS (включая акаунтинг). Оптимизация CAPEX/OPEX.
Отказ от IPv4 на CPE позволяет перевести в перспективе агрегационные сети и бекбон на IPv6Only, что сильно упрощает управление сетями с точки зрения стека протоколов (хотя это менее критично сейчас, после перехода на SR/MPLS и отказа от LDP). Оптимизация CAPEX/OPEX.
Позволяет перейти на SRv6, что даст значительные возможности для гараздо более эффективной маршрутизации и управлению трафиком end-to-end, включая разные уровни SLA, слайсинг, и т.д. Оптимизация CAPEX, новые сервисы для клиентов (особенно корпоративных).
Для разработчиков прошивки CPE отказ от IPv4 дает снижение затрат на разработку прошивки примерно на треть. Оптимизация OPEX.
Для разделяемых между операторами сетей доступа RAN 2G/3G/4G/5G переход на IPv6 для коммуникации с ядром сети каждого оператора дает значительное упрощение адресации, отсутствие конфликтов, более эффективную маршрутизацию и балансировку трафика (за счет более грамотного плана агрегации). Оптимизация CAPEX.
Это пример тех случаев применения IPv6 которые мы считаем обоснованными и выгодными за счет экономии и оптимизации. Есть еще пара десятоков юзкесов, которые мы считаем потенциально интересными, но пока о них рано говорить (включая SDN, перевод андерлея DC на IPv6 и т.д.).
Почему подмена понятий? Я имел в виду, что сам принцип захвата устройства для превращение в члена ботнета возможен как на IPv4, так и на IPv6 - смотря где и какой найдется эксплоит и что доступно затем для отправки трафика. А так хоть ATM, IPX или голубиная почта. Лишь бы голубь знал как пролезть в форточку и так нагадить на роутер, чтобы тот замбировался и вошел в ботнет.
Для исходящих - да. Но имелся в виду расчет в плане количества портов доступных для входящих соединений.
Чаще всего провайдеры используют динамический CGNAT и пользователь не имеет возможности пробросить внешний порт с CGNAT на свой CPE. У нас реализован CGNAT на основе драфта draft-tsou-stateless-nat44-02, что позволяет разделить каждый публичный IP адрес между несколькими абонентами (например 1:8), зафиксировав за каждым абонентом его диапазон портов tcp/udp (65К / 8 соответственно для каждого из транспортных протоколов). CPE абонента производит NAPT во внешний приватный адрес из пула RFC6598, но используя только порты из закрепленного за абонентом диапазона портов. Далее пакет роутится до CGNAT, где транслируется только приватный RFC6598 IPv4 адрес в соответствующий публичный (чистый NAT).
Дополнительный плюс (а в нашем случае это обязательное условие), что при этой статической трансляции, пользователь доступен для входящих соединений (хоть и только в рамках зафиксированного за ним диапазона портов), остается только пробросить в LAN нужные порты на CPE.
Главным преимуществом этой схемы является простота вычисления пула портов в зависимости от приватного адреса. Для кодирования группы портов при рейте 1:8 нужно три старших бита из 16 бит порта, которые равны трем последним битам приватного IPv4 адреса. Таким образом каждому приватному IPv4 адресу соответствует конкретная группа 8К портов. То есть не надо назначать и помнить группу портов для каждого пользователя, только его приватный IPv4 и соответствубщий публичный IPv4 (точнее знать пулы IPv4 - например, приватный /24 - соответствующий ему публичный /27.)
То, что оборудование поддерживает IPv6, это не значит, что осталось пнуть рубильник и все заработает. Для оператора это:
Дизайн архитектуры, план адресации, написание HLD, LLD, ModOps
Тестирование конфигурации в testbed
Интеграция мониторинга в cockpit
интеграция с СОРМ
Интеграция в утилиты OSS (а то и дописывание утилит)
Обучение инженеров и команд эксплуатации
и многое другое, от маркетинга до поддержки
наконец сама конфигурация на роутерах разных уровней, BNG, MAP-T BR
допиливание софта для пользовательских CPE, со своими дизайном, спецификациями, тестированием
И это отдельно для бекбонов, агрегации, датацентров и т.д.
Это просто туннелирование, оно никоим образом не решает вопрос оперирования конечных устройств по новому протоколу и фактически означает не-переход на новый протокол.
Учитывая цикл обновления оборудования провайдерами и пересмотра архитектуры, я думаю, что в ближайшие 5 лет основной тренд будет в переводе публичных ресурсов на DualStack и предоставление IPv6 по умолчанию. Сама миграция (включая внутренние сети) - ближайшие 10-15 лет.
Включить пространство v4 в v6 это не проблема вообще. Проблема во всем прочем - нельзя было сделать обратную совместимость, даже просто увеличив поля под адреса в заголоке. Проблема не в IPv6, а в IPv4, последний не поддается модернизации.
Но опять же, решить только проблему нехватки адреса - это костыль, который не решал прочие врожденные недостатки IPv4. И когда стало ясно, что совместимости не будет даже при минимальных изменениях, то было решено создать новый протокол с нуля и заодно исправить недочеты предыдущего протокола. И это правильно.
Я бы не был столь категоричен. В частности в Индии существует программа перевода государственных сайтов c доступом IPv6Only
https://lafibre.info/images/logiciel/202503_gemini_test_ipv6_inde.pdf
И насколько я знаю, не только в Индии.
Спрос рождает предложение. Сейчас найти такие предложения не составит труда, все провайдеры работающие с сегментом B2B в состоянии предложить подобное решение. Тем более, что такие решения не тербуют капитальных затрат для провайдера, ни на оборудование, ни на архитектуру. Связка технологий дана для примера, это может быть FTTx+Mobile, FTTx+xDSL, FTTx+SAT и т.д. или в любых других комбинациях и технологиях. Даже для связки +Mobile не обязательно быть сотовым оператором, можно быть MVNO. B2B вообще гораздо более гибок в этом плане.
То, что два канала одного провайдера перестанут работать вместе очень низка, так как возможные SPOF могут быть только на уровне сетей доступа, а все что выше, начиная от агрегационных сетей и бекбона, имеет избыточность как минимум n+1. Сети наземного доступа и мобильного доступа (RAN) это физически раздельные сети (как минимум до уровня агрегации), а глобальный инцидент если и возможен, то провайдер имеет контрактное обязательство устранить неполадки в течении согласованного времени (SLA обычно 4 часа). Вот если гипотетический простой в 4 часа неприемлим для клиентского бизнеса, то подключаться к двум разным провайдерам имеет смысл.
Можно. Но это как из детской сказки - сколько можно сделать шапок из одной шкуры? 2 можно? Можно. А 3? Можно. А 5? Можно. Хоть 10, если не оговаривать размер получаемых шапок. Так и с IPv4. Можно выкручиваться, докупать адреса, ставить динамический CGNAT и начинать шарить каждый адрес на все большее и большее количество абонентов. Можно так делать? Конечно! Работать будет? Вполне. Некоторое время. Только доступный абонентам сервис будет все уже и уже. Доступ извне? Зачем? P2P сети? Ненужно. SIP телефония? Не скрепно. И т.д. Итог один : вместо поредоставления доступа в интернет, вы предоставляете некий доступ к некому сервису. "Доступ к VK и Госуслугам из дома", "чат с друзьями в MAX", "видео с Рутуба". Остальные пртоколы и сервисы вам не нужны, значит и нечего огрод городить. Тем более заморачиваться с IPv6 от которого ничего кроме головной боли. Мы как-то проглядели момент, когда временное и приносящее неудобства и ограничения решение NAT на IPv4 стало теплым и ламповым, а полноценная свобода доступа в инет стала пугающей и ненужной.
Кстати, цены на блоки IPv4 снижались, но похоже стабилизировались и начинают снова расти в цене. Есть много трактовок причин, суть в том, что это не принципиальное падение интереса к IPv6, а не более чем отсрочка в процессе перехода.
Да, верно. Надо будет изучить поподробнее.
Как интересно у вас мир перевернут.
Нет, конечно. Все же выриант с AS это тотальное решение, когда сеть должна иметь не только резервный канал, но еще и через независимого провайдера. В большинстве случаев для малых клиентов такое резервирование черезмерно, достаточно резервирования через два канала одного провайдера, но по разным технологиям - например FTTO + 4G/5G. В этом случае гараздо проще предоставить клиетну один и тот же PD через оба пути. Клиент защищен от сбоев в разных сетях доступа (Landed vs RAN), а там где общая часть провайдеской сети (бекбон, пиринги) - SLA контракта с провайдерм. Собственно, сегодня это распространенный пакет предлагаемый многими провайдерами для B2B.
...если не держать в голове, что DualStack это решение переходного периода и так или иначе исчезнет с переходом к чистому IPv6. Независимо от отношения к IPv6, переход на него неизбежен, потому как проблема исчерпания IPv4 никуда исчезнуть не может, а IPv6, помимо решения проблемы адресации, является более оптимальным с точки зрения сетевых техноглогий. Как именно реализовывать доступ для v4 - это второстепенный вопрос, ибо зависит от конкретных условий.
Динамическим - это двусмысленный термин. Префиксы должны назначаться статично, а вопрос доступа решается разными путями. Если ода префикса розданы хостам и оба доступны одновременно, то DNS можно резолвить в оба. Если динамическая замена - DynDNS. Может есть еще варианты, надо подумать.
Рассуждать о такой задаче в общем виде довольно бессмыслено, решения есть и другой вопрос - какое из них оптимально, но оптимальным оно может быть только под конкретную ситуацию и задачи.
Я, кстати, не знал про такой выверт российского законодательства. Но было бы странно, чтобы дизайнеры протокола учитывали непредсказуемость Фемиды в каждом отдельном государстве, с другой - да, выбирая оптимальное решение приходится брать такое в расчет.
Если же мы говорим про клиента как юрлицо, то большинство операторов могут предложить решение с предоставлением AS и пула, который может быть анонсирован через другого провайдера (даже при том, что выдаваемый пул входит в глобальный пул выдающего оператора). Тем более что крупные операторы обычно явдяются LIRами и могут зарегистрировать PI для клиента. Я не уверен, что клиент подпадает под требование установки СОРМ, так как не является саб-провайдером и не имеет нисходящих клиентов.
На уровне хостов - никак. Собственно два PD это решение Active/Backup, оно не подразумевает специфичной логики маршрутизации или лоад-балансинга. Хотя последний может быть возможно реализовать посредством MP-TCP.
Мне тоже. Но дизайн IP подразумевает в этом случае либо отдельную AS и динамический роутинг с аплинками, либо шаманство в виде NAT, PBR и т.д.
Трудозатраты относительно небольшие, по крайней мере те же по сравнению с подобной схемой с NAPT на IPv4. Но выгода все же есть. NPT66 не NAPT, нет манипуляции с портами, так что хосты внутри сети могут быть доступны извне, а значит главное преимущество IPv6 сохраняется.
nat64/dns64 - это при условии, что провайдерская сеть IPv6Only. Ежели она DualStack, то эта проблема отпадает. Но даже случай IPv6Only - это тоже не архисложно, но метод зависит от архитектуры провайдера.
Использование серых адресов сейчас, точнее последние 5 лет. Я собственно нигде это и нее отрицал. Но речь шла о десятилетиях использованя публичных статичных адресов IPv4 для ШПД.
Вы решили ткнуть меня носом в положение дел во Франции и ссылаетесть на сайт https://www.broadband.co.uk/ дающий обзор английских операторов? С вами все в порядке?
Вас не затруднит, если вы намерены спорить, хотя бы предварительно исследовать тему в первоисточниках? Или хотя бы взять адекватеный обзор? Я облегчу вам жизнь. Вот отчет ARCEP (французского регулятора) касательно всех четырех основных французских операторов - Orange, Free, Bouygues Telecom и SFR. https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arcep_2021_Barometer_of_the_Transition_to_IPv6.pdf
The four operators all have different IPv4 address sharing practices depending on their fixed network technologies:
- The majority of Free fixed network customers (75% in xDSL and 85% in FttH) as well as a small proportion of Bouygues Telecom customers (5% in xDSL and 2% in FttH) have a shared IPv4 address. However, these ISPs offer a dedicated IPv4 address free of charge on request.
- As of this year, some SFR customers also have a shared IPv4 address (8% in FttH) and this operator does not offer a dedicated IPv4 address on request for these customers.
- With regard to fixed 4G access, while Bouygues Telecom and SFR customers have a dedicated IPv4, Free and Orange customers have a shared IPv4 address.
These two ISPs do not offer dedicated IPv4 for fixed 4G.
- This sharing of IPv4 between several customers could become generalized in the coming years to face the shortage of IPv4.
И это при том, что отчет концентрируется именно на введении shared адресов операторами в последние годы, а не о практике существовавшей десятилетиями и приведшей к исчерпанию. Но вы же разбираетесь в теме, не так ли?
Необязательно речь идет о замене CPE, вполне возможно достаточна доработка софта. CPE поставляется провайдером? Тогда это затраты провайдера на доработку ПО CPE для поддержки MAP-T. Собственно это логично, так как необходимое изменение ПО связано с выбором архитектуры сети провайдером, точнее это часть провайдерской архитектуры. Если CPE личное пользовательское, то реализация MAP-T существует у многих производителей (включая OpenWRT). В конце-концов это не какой-то стремный хак, а стандарт (RFC7599).
Это собственно так и работает с применением MAP-T (или MAP-E).
CPE пользователя получает только IPv6 PD, используемый для адресации LAN пользователя. Так же эта LAN адресуется как обычно IPv4 RFC1918. Пользовательский трафика IPv6 роутится нативно. Трафик IPv4 декапсулируется на CPE, данные инкапсулируются (в случае MAP-T) в пакет IPv6, где адрес назначения IPv6 в части префикса содержит адрес BR (шлюз CGNAT), а в части интерфейса - переведенный в hex адрес назначения IPv4. Пакет нативно роутится через IPv6Only бекбон провайдера до BR, где данные декапсулируются из пакета IPv6 и создается пакет IPv4 с адресом назначения извлеченным их интерфейсной части адреса IPv6, а адресом источника IPv4 ставится публичный адрес IPv4 из пула на BR. Для ответного пакета трансляции происходят в обратном порядке.
Собственно это и происходит де факто уже много лет. Обычный юзер не имеет (да и не должен иметь) желания собирать у себя целую сеть из отдельных узкоспециализированных устройств и для этого разбираться с кучей технологий и протоколов. Потому вполне логично, что необходимые функции и сервисы интегрируются в одну коробку - роутер, файерволл, точка доступа WiFi, шлюз IP телефонии, файловый сервер. Обьеденить все это в одной коробке логично как для провайдера (которому удобнее предоставлять все эти сервисы как единый пакет услуг в одной коробке), так и для пользователя, так как снимает с него всю головную боль. Наверно это звучит банально и очевидно, но это вполне естественное положение вещей.
Я несу вам свет знания о том, что происходит в мире.
Вас это возможно сильно поразит, но большинство крупных операторов в Западной Европе и в США десятилетиями предоставляют частным абонентам публичные IPv4 адреса. Без каких-либо красных флажков. Потому что это является нормальной ситуацией по-умолчанию.
Вы, конечно, можете жить согласно своей личной реальности, но прочая действительность к счастью об этом не в курсе. Мне как-то странно спорить и доказывать то, что является окружающим меня фактом, а так же доказывать выбор сделанный (а следовательно обоснованный технически и финансово) моей компанией - вторым по размеру и охвату оператором Франции. Как собственно и обьяснять положение дел в отрасли, в которой я работаю более 17 лет (и более 25 лет в IT).
Если вас интересует конструктивная беседа на тему - с удовольствием, если вы желаете спорить ради спора или вашего самоутверждения - простите, меня это не интересует. Уважайте собеседника и читателей.
Да я вроде ничего загадчного не говорил. Давайте с точки зрения провайдера.
Решается в перспективе вопрос исчерпания запасов IPv4 провайдера. Следует отметить, что западная традиция подразумевает выделение каждому абоненту фиксированного доступа одного постоянного публичного IPv4 адреса, так как иначе абонент не может считаться участником интернета. Это можно долго обсуждать, но стоит зафиксировать это как изначальное условие. Последствие - прямая угроза исчерпания резервов с ростом абонентской базы или потолок роста. Фиксированные CGNAT и MAP-T позволяют включить экономию и отсрочить исчерпание, выиграть время на массовый переход на IPv6, затем потребность в IPv4 станет уменьшаться. Но альтернативного решения нет. Использовать динамический CGNAT или более агрессивное соотношение трансляции (мы используем 1:8) значит предложить условия хуже конкурентов на рынке, для маркетинга и менеджмента это не приемлимо. Это прямые финансовые риски.
С MAP-T абонентский CPE получает только IPv6 адрес (вместо IPv4+IPv6 сегодня в DualStack). Это дает уменьшение требуемых ресурсов на BNG, упрощение процесса конфигурации CPE (DHCPv6 вместо DHCPv4+DHCPv6 сегодня), упрощение обслуживания базы Radius OSS (включая акаунтинг). Оптимизация CAPEX/OPEX.
Отказ от IPv4 на CPE позволяет перевести в перспективе агрегационные сети и бекбон на IPv6Only, что сильно упрощает управление сетями с точки зрения стека протоколов (хотя это менее критично сейчас, после перехода на SR/MPLS и отказа от LDP). Оптимизация CAPEX/OPEX.
Позволяет перейти на SRv6, что даст значительные возможности для гараздо более эффективной маршрутизации и управлению трафиком end-to-end, включая разные уровни SLA, слайсинг, и т.д. Оптимизация CAPEX, новые сервисы для клиентов (особенно корпоративных).
Для разработчиков прошивки CPE отказ от IPv4 дает снижение затрат на разработку прошивки примерно на треть. Оптимизация OPEX.
Для разделяемых между операторами сетей доступа RAN 2G/3G/4G/5G переход на IPv6 для коммуникации с ядром сети каждого оператора дает значительное упрощение адресации, отсутствие конфликтов, более эффективную маршрутизацию и балансировку трафика (за счет более грамотного плана агрегации). Оптимизация CAPEX.
Это пример тех случаев применения IPv6 которые мы считаем обоснованными и выгодными за счет экономии и оптимизации. Есть еще пара десятоков юзкесов, которые мы считаем потенциально интересными, но пока о них рано говорить (включая SDN, перевод андерлея DC на IPv6 и т.д.).
Почему подмена понятий? Я имел в виду, что сам принцип захвата устройства для превращение в члена ботнета возможен как на IPv4, так и на IPv6 - смотря где и какой найдется эксплоит и что доступно затем для отправки трафика. А так хоть ATM, IPX или голубиная почта. Лишь бы голубь знал как пролезть в форточку и так нагадить на роутер, чтобы тот замбировался и вошел в ботнет.
Для исходящих - да. Но имелся в виду расчет в плане количества портов доступных для входящих соединений.
Чаще всего провайдеры используют динамический CGNAT и пользователь не имеет возможности пробросить внешний порт с CGNAT на свой CPE. У нас реализован CGNAT на основе драфта draft-tsou-stateless-nat44-02, что позволяет разделить каждый публичный IP адрес между несколькими абонентами (например 1:8), зафиксировав за каждым абонентом его диапазон портов tcp/udp (65К / 8 соответственно для каждого из транспортных протоколов). CPE абонента производит NAPT во внешний приватный адрес из пула RFC6598, но используя только порты из закрепленного за абонентом диапазона портов. Далее пакет роутится до CGNAT, где транслируется только приватный RFC6598 IPv4 адрес в соответствующий публичный (чистый NAT).
Дополнительный плюс (а в нашем случае это обязательное условие), что при этой статической трансляции, пользователь доступен для входящих соединений (хоть и только в рамках зафиксированного за ним диапазона портов), остается только пробросить в LAN нужные порты на CPE.
Главным преимуществом этой схемы является простота вычисления пула портов в зависимости от приватного адреса. Для кодирования группы портов при рейте 1:8 нужно три старших бита из 16 бит порта, которые равны трем последним битам приватного IPv4 адреса. Таким образом каждому приватному IPv4 адресу соответствует конкретная группа 8К портов. То есть не надо назначать и помнить группу портов для каждого пользователя, только его приватный IPv4 и соответствубщий публичный IPv4 (точнее знать пулы IPv4 - например, приватный /24 - соответствующий ему публичный /27.)
Понятно изложено, спасибо.
Думаю, что в вашем решении NPT это единственный выход из ситуации.