NAT как основа для de facto P2P поверх IPv4: почему бы и нет?
Переход на IPv6 буксует уже больше 25 лет — главным образом из-за несовместимости оборудования: провайдерам нужно менять маршрутизаторы, свитчи, прошивки на миллионах устройств, включая legacy и embedded-системы, которые физически нельзя обновить программно. Это капитальные затраты, растянутые на десятилетия.
У меня возникла идея, как получить de facto P2P-связность через NAT, не трогая при этом сам IPv4/TCP-IP стек — то есть добиться результата, сравнимого с тем, что даёт IPv6, но ценой изменений только на прикладном уровне.
**Суть схемы**
Берём пул, скажем, 10 млн IP-адресов. На каждый IP выделяем все 65536 портов × 2 (TCP/UDP). Итого около 1,3 трлн внешних "точек входа". Провайдер выступает чистым NAT-форвардером: пересылает пакет с `внешний_IP:порт` на внутреннего пользователя, без терминации соединения, без держания VPN-туннелей — то есть ничего сверх обычной NAT-таблицы, которая и так работает в любом CGNAT сегодня.
Дальше вся "магия" — на стороне пользователя. За каждым портом висит клиентский мультиплексор (по сути freestanding namespace, наподобие slirp), который добавляет второй уровень адресации внутри уже установленного соединения — условно 256×256×256 внутренних адресов на каждый порт. Итоговое адресное пространство получается порядка 10^27 уникальных адресуемых точек — с огромным запасом на любой мыслимый IoT-бум (для сравнения, IPv6 даёт 3,4×10^38, то есть на 11 порядков больше, но с практической точки зрения этот запас уже избыточен настолько, что разница не имеет значения).
**Что нужно поменять**
- **DNS**: новый тип записи (расширение по типу SRV/NAPTR), который отдаёт не просто IP, а `IP:порт + внутренний адрес второго уровня`.
- **Почта**: аналогично — MX-записи и MTA (Postfix, Exim и т.д.) должны научиться работать с этим форматом.
- **Центры сертификации**: в теории их можно вообще не трогать, если второй уровень адресации резолвится до TLS-хендшейка и остаётся частью транспортной маршрутизации, а не идентичности — сертификат по-прежнему выдаётся на домен.
- Сам IPv4, TCP/IP и физическая инфраструктура провайдеров — не меняются вообще.
Формально получаем P2P: после резолва пакет идёт от узла к узлу, NAT просто переписывает адрес/порт, не выступая прикладным посредником (в отличие, например, от классических VPN-relay или TURN-серверов).
**Мой главный вопрос**
NAT в его нынешнем виде существует с 1990-х, и вся "тяжёлая" инфраструктурная часть (форвардинг пакетов по таблице) давно повсеместно развёрнута и отработана. По сути, для описанной схемы не хватает лишь протокола прикладного уровня поверх уже существующей инфраструктуры.
Почему индустрия не пошла по этому пути, а вместо этого 25+ лет пытается продавить IPv6 через замену оборудования? Мне видятся несколько причин (инерция NAT как "костыля, а не платформы"; проблема координации, просто перенесённая с ISP на DNS-резолверы/CA/MTA-разработчиков; новые security-риски двухуровневой адресации; тот факт, что IPv6 и так уже "достаточно готов" и внедряется фоном по мере естественной замены железа) — но хотелось бы услышать мнение сообщества: есть ли в этой схеме принципиальный изъян, который я упускаю, или же это действительно нетронутая ниша, которую просто никто не считал стоящей усилий по сравнению с "дожать IPv6"?
так именно так работают мобильные провайдеры, внутри провайдера своя локальная сеть (что бы при смене базовой станции при перемещении у пользователя связь не рвалась) и NAT-ятся (иногда двойной) в мир.
Тем самым ваш тезис гласит, зачем развиваться, надо и дальше придумывать костыли?
"25+ лет пытается продавить IPv6" В каком смысле пытается, по статистикам уже 50 % (или около) работает.
Я уже второй год на нем.
Немного не логичный вопрос, учитывая что я предлагаю решить проблему NAT, самим же NAT используя его как транслятор входящих соединений. Да есть костыли, которые предполагают использование строгий relay сервисов, но жто зависимость от чужой инфраструктур, а этот стандарт мог бы избавить от этого костыля, и сделать универсальность, не трогая, а соселтсвуя с классическом интернетом, работая поверх ipv4, TCP/ip, избавляя провайдеров от расходов на дорого ipv6 железо. Да расходы будут, но из модно делать постепенно, быстрее, ничего не ломая и дешевле
Chuvaaaak, ну как минимум проблема в том что для каждой сессии открывается свой порт, упор в железо 10 млн пользователей по 200 сессий это гдето 1 tb ram только под conntrack + логирование соединений(по закону 3 года) где-то 300гб в сутки(9tb в месяц, 324tb за 3 года) +задержки на "пробег процессора" с miss ram(ну врятли вся таблица будет постоянно в памяти) по таким таблицам будет очень болшой порядка 100-300мс
Ну допустим есть у нас один порт прямой порт накладные расходы под инкапсуляцию вторичны, только одно соединение на клиента за раз(одна tcp сессия с srcip:port:dstip:port, так как src:port константа на выходе и dstip:port константа на входе иначе сломается conntrack) для тунеля ok а для ускорения передачи часто несколько сессий(ftp или download master как пример)
Zerg89, почему вся таблица должна быть в памяти, и причём у одного правадйера. Я имею ввиду что из пула в 10 млн раздается ip каждой AS(ну и там вся кухня по раздаче ip другим провабйерам, и тд) и за каждый endpoint порт выдается только по факту его нахождения в сети самого провадйера? Ну и типо, 1,3 трлн возможных комбинацией айпи порта никто не будет исаольщвать сразу, это как колоссальный запас на про все и вся. Реально это должно быть максимум 12 млрд на весь мир. И да, твой пример покроет всю россиюю, то есть около 100 раз;) ну то есть.
Я имею ввиду что из пула в 10 млн раздается ip каждой AS
в 10 млн клиентов(tcp сессий с привязкой порта) даже Москва не влезет у каждого(98%) есть дома интернет и смартфон а то и не один и на каждого нужна srcnat запсь и в таблице contrack записей может быть больше чем 1 клиент подключенный к другому одновременно, открыл сайт у тебя уже 5-15 сессий висит одна к основному сайту и несколько сверху(к cloudflayer за контентом, к vk и/или к yandex и google мертрики, а и к dns серверу еще, возможно еще и к уц сертификаты проверить надо а неотозваны ли они и тд а мы только одну страничку открыли
С распределенной отдачей контента(yuotube как пример) можно умножать на 5 количество сессий каждый узел надо резолвить и проверить его сертификат(http3 вроде также)
Zerg89, а почему вообще решили, что именно через выделенный пул IP люди будут ходить в интернет. IP распределяются на каждую AS/ноду. Через этот IP никто не ходит в интернет, он лишь служит для проброса. Ходят в интернет через другой. DNS не переписываем, просто используем HINFO и A-запись (в HINFO кладём 5 байт для описания внутренней адресации). И по сути, при каждой смене IP_из_пула+порт меняем HINFO — аналог DDNS.
косяк разрабов ipv4 в ограниченном количестве адресов. обоснование понятно - 640 кб хватит всем....
решение косяка:
1. прямое - увеличение размера адреса. (ipv6).
минус меняется очень и очень многое.
плюс: адресу выделено 128 бит (теоритически). некоторые попутные переработки протоколов, вычищение найденных ошибок.
2. костыльное - растягиваем адрес за счет портов (твое).
плюс: к адресу добавляется всего два байта , т.е. получаем 48 бит адреса (теоритически).
плюс: меньшеее количество изменений в протоколах. огромная часть ПО вообще можно не менять.
минус: полностью теряем систему "порт как сервис". переработка все равно требуется и один херъ она будет тормозить. и попутно будет лезть огромное количество косяков гибридной работы.
Тип NAT в CGNAT как правило Full Cone, т.е. при отправке первого пакета порт «открывается» для любых источников, а не только для того, куда он был отправлен (destination-independent). Этой особенностью пользуются все программы, работающие с/за NAT.
Половина населения планеты подключается к Google через IPv6.
