2015-02-02 9:05 GMT+02:00 Valentin Nechayev
Sun, Feb 01, 2015 at 22:49:58, anton wrote about "[uanog] Re: [uanog] Re: [uanog] Белые IP Freenet/O3":
Ну то есть, ты предлагаешь кусок адреса засунуть в ip options? Очень плохая идея.
Аргументируй, пожалуйста. Место в номерах опций есть. Насколько я понял RFC791, опции обязательны к пониманию всеми участниками, то есть пакет не пройдёт дальше раутера, который такое не знает; то есть, неправильной интерпретации адреса не будет. Что ещё не так?
Именно это не так. Тут и ломается наша совместимость.
Вопрос цены обработки в раутерах я тут не рассматриваю, он очевиден и не в пользу варианта Павла, но о нём речь не шла.
Я думал, мы комплексно пытаемся подойти к проблеме :-)
Нет, извини. Новый стек не нужен, нужна модификация старого. Полной совместимости нет, обратная совместимость есть. Я так и не понял, что такое "обратная совместимость". Ты же сам написал, что старые стеки с новыми работать не будут. Значит совместимости нет.
Есть совместимость в пределах старых возможностей и адекватная реакция на использование новых. Это и называется корректной обратной совместимостью.
Значит мы по-разному понимаем совместимость. Если хост А не понимает options хоста В, они не совместимы. Если же брать "совместимость возможностей" - ну окей. Мы привыкли, нам так удобно.
Да. Есть уровень стека, протоколов, админов, разработчиков, юзеров... Для расширения адресного пространства достаточно изменений на уровне стека и протоколов. IPv6 же требует нетривиальных действий вообще на всех уровнях.
Ну каких, например, нетривиальных действий? В твоем подходе тоже надо полностью перерабатывать маршрутизаторы. Переписывать логику работы ткам-ов и т.п.
Это и так делается каждые несколько лет и, как я говорил рядом, было уже однажды сделано - при переходе к безклассовому раутингу; а после этого ещё несколько раз, с каждой новой архитектурой (помнишь, например, переход IOS 11 -> 12 со введением CEF? сколько граблей было, пока оно не начало полностью корректно работать?) Или, переход концепции Cisco к "предоставлению сервисов" и введением всяких DPI - что, оно не ломало всё полностью внутри их продуктов?
В общем, это уж точно не аргумент. А вот возможность массе софта использовать классический IP4 в локальных масштабах (например, серые сети), и при этом выходить в мир, кто умеет, без двойного стека - это очень вкусно.
Вендору легче будет держать отдельный RIP/FIB, чем ковырять уже давно вылизанное.
Не легче, извини. Просто представь себе это внутри железяки, с конкретными протоколами.
Ну вот я представил. И представил себе логику RIB/FIB lookup. Не сходится у меня картинка.
Я не увидел в твоем подходе вообще ничего, что кардинально отличалось бы от подхода IPv6. Кроме размера адреса и вроде как какого-то удобства для разработчиков софта.
Никто не будет держать два паралельных интернета без взаимодоступности. Ни контентщики, ни сервисники. Все равно это все вырождается в дуалстек, нат и т.д. И, как следствие, тем же migration technics, поторые применяются для IPv6. В которых, кстати, какого-то rocket science нет.
Вариант Павла _не_ требует dual stack. Перечти ещё раз внимательно, если не видишь, почему. Местами задвоение есть, да. Начиная с DNS (вот уж где поле непаханое извращений). Но оно будет видно только технарям. Сейчас же проблема видна любому юзеру.
Без dual stack мы лишаем коннективити старые хосты и новые. Это никому не надо. Даже не беря юзеров (99% из которых абсолютно плевать, чо там внутри, они мыслят категорией "сайт не грузиццо"). Возьми внутренние системы оператора, которые работают между собой по каким-то east-west, north-south протоколам. Нам надо будет либо: а) делать апдейт всего и сразу б) делать dual stack c) строить новую систему Выбери самый простой и дешевый вариант :-) То есть, в какой-то момент нам надо будет на определенных элементах держать стек, который понимает и новое, и старое. Что это, как не dual stack?