Розберу як мережевий інженер.
Що пропонує IPv8 (коротко)
Документ draft-thain-ipv8-00 намагається
перевинайти не тільки IP, а всю мережеву модель одразу:
Ключові ідеї:
- Єдиний “Zone Server”:
- DHCP, DNS, NTP, auth, logging — все разом
- Авторизація всього через OAuth2/JWT
- Кожен пакет перевіряється через DNS + WHOIS
- Адресація:
- 64-біт (менше ніж IPv6!)
- прив’язка до ASN
- Глобальна маршрутизація:
- максимум 1 маршрут на ASN
- Повна backward compatibility з IPv4
- Нульова міграція (“no flag day”)
Звучить як “IPv6 + SDN + Zero Trust + cloud-native все в одному”.
Що в цьому справді цікаво (і навіть розумно)
1. Проблема сформульована правильно
Автор чітко б’є в слабкі місця:
- фрагментація (DHCP, DNS, auth окремо)
- складність операцій
- відсутність вбудованої безпеки
- BGP і hijacking
Це абсолютно валідно.
IPv8 намагається вирішити
операційні проблеми, а не тільки адресацію — це плюс.
2. Ідея “менеджмент як частина протоколу”
Zone Server — це фактично:
- SDN controller + identity provider + DHCP/DNS
Це близько до сучасних трендів:
- Zero Trust
- SASE
- intent-based networking
У корпоративних мережах це виглядає логічно.
3. Обмеження routing table
Ідея:
“1 маршрут на ASN” (
IETF)
Це намагається вирішити реальну проблему:
- BGP таблиця > 900k маршрутів
Теоретично це дуже красиво.
А тепер — проблеми (і їх багато)
1. 
“100% backward compatibility” — майже фантастика
“No existing device requires modification” (
IETF)
Це червоний прапор.
Реальність:
- навіть IPv6 не зміг це зробити
- NAT, firewall, middleware — все ламається при зміні моделі
Тут обіцяється
занадто багато без ціни.
2. Централізація (Zone Server)
Вся мережа залежить від:
- Zone Server
- DHCP8
- OAuth cache
Це означає:
- single point of failure (навіть якщо “active/active”)
- повна втрата роботи при збоях контролера
Це протилежність дизайну Інтернету:
- Інтернет = децентралізований by design
- IPv8 = сильно централізований
3. Перевірка кожного пакета через DNS/WHOIS
“Every packet … validated against DNS8 and WHOIS8” (
IETF)
Це виглядає красиво, але:
- latency ↑
- complexity ↑↑
- масштабування — під питанням
Це суперечить базовому принципу IP:
forwarding має бути максимально простим і швидким
4. ASN як основа адресації
Ідея:
- кожен ASN отримує 2³² адрес
- routing = по ASN
Проблеми:
- ASN ≠ реальна топологія
- multihoming стає складнішим
- PI/PA адресація зникає
Це ламає десятиліття еволюції BGP.
5. 64-bit адресація
IPv8:
IPv6:
Це крок назад:
- IoT, privacy extensions, SLAAC — потребують більше простору
- майбутній запас менший
6. “Все в одному протоколі”
IPv8 об’єднує:
- routing
- auth
- telemetry
- updates
- identity
Це порушує фундаментальний принцип:
separation of concerns
У результаті:
- складність ↑
- важче еволюціонувати окремі компоненти
7. Нереалістичний adoption model
Документ каже:
“No flag day, no migration” (
IETF)
Але реально:
- нові протоколи (BGP8, DNS8, DHCP8)
- новий стек
- нові API
Це
повний fork Інтернету, а не еволюція.
Чому це виглядає “підозріло”
Є кілька характерних ознак “напівсерйозного” RFC:
1. “Ми вирішуємо все одразу”
- адресація
- безпека
- менеджмент
- routing
У реальних RFC такого не буває.
2. Ідеальний світ без компромісів
- 100% сумісність
- нульова міграція
- краща безпека
- менша складність
Це звучить як pitch deck, а не стандарт.
3. Дуже сильні припущення
Наприклад:
- всі довіряють WHOIS8
- всі ASN поводяться “правильно”
- всі впроваджують Zone Server
У реальному Інтернеті це не працює.
Вердикт
Це не жарт, але…
Це
серйозна інженерна спекуляція / thought experiment, а не практичний стандарт.
Ймовірність впровадження: ~0%
Причини:
- несумісність з принципами Інтернету
- централізація
- занадто великий “blast radius” змін
- конкуренція з IPv6 (який уже існує)
Що з цього може “вижити”
Окремі ідеї:
- інтегрований network management
- identity-aware networking
- route validation (RPKI-подібні ідеї)
Але вони вже розвиваються
окремо, без “IPv8”.
Коротко
- Це не проривний стандарт, який реально приймуть
- Але і не тролінг
- Це радше:
“А що як перебудувати Інтернет з нуля під сучасні вимоги?”
