На сайті Internet Engineering Task Force (IETF) з’явився чернетковий документ, що описує новий інтернет-протокол Internet Protocol Version 8 (IPv8). Автор позиціонує його як «наступний крок» після IPv6, обіцяючи спрощену адресацію та повну зворотну сумісність з IPv4. Публікація миттєво привернула увагу мережевої та кібербезпекової спільноти, зокрема через нетипову архітектуру протоколу та ознаки активного використання генеративного ШІ під час підготовки тексту.
Як влаштований IPv8: 64-бітна адресація та порівняння з IPv4/IPv6
У чернетці IPv8 пропонується розширити розмір IP-адреси до 64 біт, але зберегти звичний формат запису у вигляді крапково-десяткових чисел. Якщо IPv4 складається з чотирьох октетів (наприклад, 203.0.113.1), то в IPv8 описано вісім октетів, розділених крапками: 1.1.1.1.1.1.1.1. Кожен октет, як і раніше, має діапазон від 0 до 255.
Таке подвоєння довжини адреси формує простір у 264 можливих адрес — близько 18,4 квінтильйонів унікальних ідентифікаторів. Це значно більше за ~4,29 млрд адрес у IPv4 (232), але все ще на кілька порядків менше за 128-бітний простір IPv6, де доступно приблизно 3,4×1038 адрес. Таким чином, IPv8 займає проміжне положення між обмеженим IPv4 та «майже нескінченним» IPv6.
Заявлена повна сумісність IPv8 з IPv4
Ключова ідея автора — трактувати IPv4 як підмножину IPv8. Пропонується, що якщо старший частковий префікс IPv8 має нульове значення, адреса може інтерпретуватися як звичайна IPv4-адреса. На папері це виглядає як спосіб уникнути масової заміни обладнання та програмного забезпечення.
Однак з практичної точки зору будь-який наявний маршрутизатор, комутатор, міжмережевий екран або мережева карта, побачивши в заголовку IP-пакета Version=8, не зможе коректно його обробити й, з великою ймовірністю, просто відкине. Для роботи з IPv8 потрібні оновлені стекі ОС, прошивки, драйвери та підтримка в протоколах маршрутизації. Це суперечить тезі про «непомітну» сумісність і фактично означає масштабну міграцію інфраструктури.
Zone Server, OAuth2 та небезпечне змішування мережевих і прикладних функцій
Чернетка IPv8 пропонує не лише нову адресацію, а й радикально іншу архітектуру управління мережею. Автор вводить централізований компонент Zone Server, якому делегуються одразу кілька критичних функцій: телеметрія, резолвінг імен, синхронізація часу, контроль доступу, трансляція адрес, аутентифікація пристроїв.
Особливо дискусійною є вимога, щоб кожен керований мережевий елемент проходив аутентифікацію через OAuth2 з використанням JWT-токенів. Тобто механізми, які традиційно належать до прикладного рівня (7-й рівень моделі OSI), пропонується вбудувати прямо в основу мережевого рівня (3-й рівень), де працює IP.
Більшість мережевих пристроїв — від комутаторів доступу до промислових контролерів — не розраховані на виконання складних операцій авторизації на рівні OAuth2. Вбудовування таких механізмів у базовий протокол різко розширює поверхню атаки, ускладнює управління ключами та токенами, прив’язує мережеву доступність до коректної роботи центральних Zone Server. Компрометація такого сервера або його OAuth-інфраструктури потенційно дає зловмисникам інструмент для масової деавторизації пристроїв, блокування сегментів мережі або підміни трафіку.
Критичний погляд спільноти: статус Internet-Draft, авторство та сумнівна практичність
Що означає статус Internet-Draft в IETF
Частина дискусій стосується саме статусу документа. Internet-Draft не є стандартом і навіть офіційною «пропозицією стандарту». Будь-яка особа може надіслати чернетку, а її публікація на сайті IETF не означає схвалення або підтримки робочими групами. У тексті прямо вказано, що документ не має формального статусу в процесі стандартизації і, за відсутності інтересу спільноти, автоматично втратить чинність приблизно через шість місяців.
Невідомий автор і роль генеративного ШІ
Автором IPv8 зазначений James Thain з компанії One Limited, зареєстрованої на Бермудських островах. Для професійної мережевої спільноти це ім’я нове, а участі автора в розробці чинних інтернет-протоколів не зафіксовано. Додаткові запитання викликало те, що протягом кількох днів було опубліковано відразу три ревізії IPv8 та близько десятка пов’язаних чернеток щодо Zone Server, маршрутизації тощо.
Аналіз тексту за допомогою сервісу виявлення ШІ-контенту GPTZero показав, що значна частина документа, ймовірно, згенерована штучним інтелектом, із сумарною оцінкою «ймовірності походження від ІІ» близько 76%. Формально це не заборонено, але для критичних стандартів, що визначають роботу всієї інфраструктури Інтернету, така практика підвищує вимоги до незалежної експертизи та ретельного технічного аудиту.
Проблеми сумісності, безпеки та конфлікт версій
Опис IPv8 фактично передбачає нові типи DNS-записів, оновлені API сокетів, модифікації ARP, ICMP, протоколів маршрутизації BGP/OSPF/IS-IS, обов’язкову інтеграцію з Zone Server та OAuth2 на портах комутаторів. Сукупно це означає не еволюційне розширення IPv4/IPv6, а комплексну заміну мережевої екосистеми з відповідними операційними й безпековими ризиками.
Окремо експерти звертають увагу, що номер версії IP 8 вже використовувався в минулому для P Internet Protocol (PIP), який сьогодні вважається застарілим. Повторне використання того самого номера може призвести до плутанини під час аналізу трафіку, роботи IDS/IPS-систем і засобів моніторингу.
Залежність від централізованих Zone Server створює додаткові точки відмови й привабливі цілі для атак. У випадку збою або компрометації такого вузла організація ризикує втратити керованість великої частини мережі, а зловмисники — отримати важелі для масштабних деструктивних операцій.
Ситуація з IPv8 наочно демонструє, наскільки важливо уважно ставитися до будь-яких нових ініціатив в IETF: перевіряти їхній статус як Internet-Draft, аналізувати архітектуру та оцінювати реальні наслідки для кібербезпеки. Організаціям доцільно інвестувати в підвищення кваліфікації фахівців, участь у профільних робочих групах та розбудову внутрішніх процесів експертизи протоколів. Це допоможе вчасно відокремлювати перспективні стандарти від ризикованих експериментів, зменшувати кількість нових точок відмови, контролювати сценарії компрометації токенів і ключів та забезпечувати стійкість мережевої інфраструктури в умовах швидкого розвитку технологій і генеративного ШІ.
