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, самим же NAT используя его как транслятор входящих соединений. Да есть костыли, которые предполагают использование строгий relay сервисов, но жто зависимость от чужой инфраструктур, а этот стандарт мог бы избавить от этого костыля, и сделать универсальность, не трогая, а соселтсвуя с классическом интернетом, работая поверх ipv4, TCP/ip, избавляя провайдеров от расходов на дорого ipv6 железо. Да расходы будут, но из модно делать постепенно, быстрее, ничего не ломая и дешевле
