Це "IPv10" жарт чи серйозний проект RFC?

Специфікація Internet Protocol версії 10 (IPv10)

Назва смішна (IPv4 + IPv6 == IPv10), але фактична пропозиція виглядає дивним (ще один формат пакету для боротьби з несумісністю форматів пакетів).

Це нормальна пропозиція, яка має збалансовані плюси та мінуси чи просто мінімально життєздатний документ, щоб посміятися з "IPv10" із серйозним обличчям?

Якщо це серйозно, будь ласка, опишіть це "tl; dr". Чому це, а не інша технологія переходу, як nat64 / teredo?

Як сказав Рон, кожен може написати пропозицію. Мені важко сприймати пропозиції серйозно від того, хто пропонує з'єднати супутники з оптичним волокном .

Крім того, я не можу уявити, що ця фактична пропозиція набирає будь-яких обертів, особливо завдяки цій примітці:

Усі хости, підключені до Інтернету, повинні бути хостами IPv10, щоб мати можливість спілкуватися незалежно від використовуваної версії IP, а процес розгортання IPv10 може здійснюватися ВСІМ технологічними компаніями, що розробляють ОС для мережевих пристроїв та пристроїв безпеки.

Отже, щоб вирішити проблему хостів, які підтримують лише IPv4, не в змозі спілкуватися з хостами, які підтримують лише IPv6 (і навпаки), вам потрібно реалізувати інший протокол: IPv10. Тоді, чому б це турбуватись, а не просто реалізовувати IPv6 на цьому хості, призначеному лише для IPv4, і робити з цим

Крім того, як можна прочитати в RFC7059 , вже існує більш ніж достатньо тунельних механізмів, які можна використовувати для вирішення частин цієї проблеми.

Якщо чесно, я думаю, що автор сподівається на якийсь комерційний успіх, вимагаючи авторські права, про що можна прочитати в цих твітах :

Оголошення: Захист авторських прав, протокол маршрутизації # IPv10 та KHALED (#KRP або #RRP) розроблений генеральним директором @The_Road_Series.

ЇХ НЕ МОЖЕ бути представлено або опубліковано будь-якою організацією без погодження з їх розробником @Eng_Khaled_Omar

Сьогодні, 26 травня 2017 року, ietf було надіслано 2-й запит на видалення чернетки # IPv10 #KRP (#RRP) зі свого сховища.

Ви повинні пам’ятати, що кожен може подавати пропозиції до IETF, і вони сприймаються серйозно, поки вони не будуть прийняті або не помруть через відсутність інтересу.

Ця конкретна пропозиція закінчилася, а автор кілька разів поновлювався. Здається, він не має великої, якщо така є, підтримки, і навіть не має запропонованого статусу RFC, наприклад, Track Standards. Автор, мабуть, серйозно ставиться до своєї пропозиції, але, схоже, він не отримав серйозної підтримки цієї пропозиції.

Є пропозиція заходу IPv4, що є серйозним, і за ним стоїть повна робоча група, але перед нею довгий важкий шлях до повного прийняття. Він має намір вирішити проблеми, притаманні переходу від IPv4 до IPv6.

Це "IPv10" жарт чи серйозний проект RFC?

І те й інше. Я здогадуюсь, що Блок серйозний, і він не отримує тих смішних схем, які пропонує. Жарт на нього.

Пропозиція Fibre Satellite ще більше смішна, оскільки вона нехтує необхідною довжиною волокон і повністю ігнорує орбітальну механіку.

IETF повинен заблокувати його для тролінгу.

Це серйозна спроба вирішити реальну проблему. Незалежно від того, добре рішення чи погано (це, мабуть, сміття), його твердження про проблему правильне: нинішня стратегія спроб впровадження IPv6 поки що не вдалася. Як говориться в його вступі, 19 років IPv6, і ми досі не можемо побачити, що ми перейшли будь-яким значущим чином.

Як уже згадується, у нас вже є кілька мостикових рішень, таких як NAT64 (він згадує і про інших). Вони прекрасні і хороші, але все ж не дозволяють повністю перейти до IPv6 - вони припускають, що тут залишаються публічні хости лише для IPv4.

З цього приводу я скептично ставлюсь до того, як ця специфікація допоможе, враховуючи те, що я бачу як фундаментальні проблеми з переходом на IPv6. Я не витрачав багато часу, намагаючись зрозуміти, як це намагається, і, можливо, він мудріший за мене (хоча консенсус серед інших відповідей говорить про те, що я правий), але, схоже, страждає та сама проблема завантаження, що і IPv6 у першість.

Відповісти на "Але" - це все-таки серйозна спроба вирішити проблему.

Існує деяка обґрунтованість з реалізацією нового протоколу. Поточний протокол перекладу - NAT64.

NAT64 - це механізм переходу IPv6, який полегшує зв’язок між хостами IPv6 та IPv4 за допомогою форми трансляції мережевих адрес (NAT). Шлюз NAT64 - це перекладач між протоколами IPv4 та IPv6, 1 для функціонування якого потрібен щонайменше одна адреса IPv4 та мережевий сегмент IPv6, що містить 32-бітний адресний простір. Клієнт IPv6 вбудовує адресу IPv4, з якою бажає спілкуватися, використовуючи хост-частину мережевого сегмента IPv6, в результаті чого IPv6-вбудований IPv6-адресу (звідси 32-бітний адресний простір у мережевому сегменті IPv6) та відправляє пакети на мережу отримана адреса. Шлюз NAT64 створює відображення між IPv6 та IPv4 адресами, які можуть бути вручну налаштовані або визначені автоматично.

Джерело

Головною ідеєю для IPv10 було б усунення NAT64. Власне кажучи, NAT завжди був вузьким місцем.