Необязательно речь идет о замене 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.)
Пока нет массовых подключений со множеством путей, то нет и особого смысла в SCTP или MP-TCP. MP-TCP я вижу в обсуждениях более 10 лет, но ни разу не видел реализацию, даже в лабе.
Меня больше смущает большое количество частных нюансов (в контексте IPv6), в виде тунелей и внешних серверов, а так же протоколов маршрутизации. Если потенциальные IPv6 адреса должны роутиться посредством IGP, то вам придется поднимать OSPFv3 в довесок к существующему или переходить на ISIS. Без знания топологии вашей сети сложно дать стоящий совет.
Можно. Я это и имею в виду при упоминаниии контейнеризации. Это один из аргументов использования DHCPv6-PD с серверами.
Но все же это частный юзкейс. Все описанное вами вполне реализуется в классическом виде на сервере с единственным адресом, так как все сервисы используют разные tcp/udp порты. Это случай по-умолчанию, он проще, особенно с точки зрения хостера.
Так ведь мне не надо ничего доказывать, я поделился той базой, которая была использована нами при разработке дизайна CGNAT/MAP-T в нашей сети. Другие провайдеры могут использовать другой подход в оценке. Пригодится вам моя информация - прекрасно, нет - вы можете провести свое собственное исследование и обосновать его для вашей сети.
Нет. Не заставлял. Разворачивание IPv6 началось задолго до участия регуляторов в этом вопросе. Да и то, кроме требования IPv6 для получения частот 5G, других фактов обязывания операторов в этом вопросе я не знаю. ARCEP занимается пропагандой IPv6, но никак не проталкиванием в приказном порядке.
Вся документация того же ARCEP доступна в открытом доступе, можете изучить и контраргументировать.
Разворачиванием IPv6 в том числе занимаются и малые операторы и хостеры, которые под понятие бигтех не подпадают вообще никак.
Необязательно речь идет о замене 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 это единственный выход из ситуации.
С этим, простите, не ко мне.
Пока нет массовых подключений со множеством путей, то нет и особого смысла в SCTP или MP-TCP. MP-TCP я вижу в обсуждениях более 10 лет, но ни разу не видел реализацию, даже в лабе.
А смысл? :)
Меня больше смущает большое количество частных нюансов (в контексте IPv6), в виде тунелей и внешних серверов, а так же протоколов маршрутизации. Если потенциальные IPv6 адреса должны роутиться посредством IGP, то вам придется поднимать OSPFv3 в довесок к существующему или переходить на ISIS. Без знания топологии вашей сети сложно дать стоящий совет.
Это так. Но хоть что-то. Хотя до сих пор не понимаю, почему разработчики Андроида так уперлись рогом.
Можно. Я это и имею в виду при упоминаниии контейнеризации. Это один из аргументов использования DHCPv6-PD с серверами.
Но все же это частный юзкейс. Все описанное вами вполне реализуется в классическом виде на сервере с единственным адресом, так как все сервисы используют разные tcp/udp порты. Это случай по-умолчанию, он проще, особенно с точки зрения хостера.
Так ведь мне не надо ничего доказывать, я поделился той базой, которая была использована нами при разработке дизайна CGNAT/MAP-T в нашей сети. Другие провайдеры могут использовать другой подход в оценке. Пригодится вам моя информация - прекрасно, нет - вы можете провести свое собственное исследование и обосновать его для вашей сети.
Даже для сетевика это слишком замороченное решение, либо затратное.
Решений на данный момент не так уж много - либо раздать префиксы от всех доступных аплинков каждому устройству, либо NPT66.
Проблема сейчас активно обсуждается. В частности на последнем DENOG17 : https://pretalx.com/media/denog17/submissions/QNDD3G/resources/slides-denog17-ipv_0gJks2a.pdf
Ух ты. Не знал, что так закручено.
Скорей всего так и будет. В загончике можно будет аккуратно складывать IPv4 адреса рядом со стеллажами фидошных адресов. Впрок. :)
На внутреннее исследование? :)
Нет. Не заставлял. Разворачивание IPv6 началось задолго до участия регуляторов в этом вопросе. Да и то, кроме требования IPv6 для получения частот 5G, других фактов обязывания операторов в этом вопросе я не знаю. ARCEP занимается пропагандой IPv6, но никак не проталкиванием в приказном порядке.
Вся документация того же ARCEP доступна в открытом доступе, можете изучить и контраргументировать.
Разворачиванием IPv6 в том числе занимаются и малые операторы и хостеры, которые под понятие бигтех не подпадают вообще никак.