Mon, Feb 02, 2015 at 09:19:35, anton wrote about "Re: [uanog] Re: [uanog] Белые IP Freenet/O3":
Ну то есть, ты предлагаешь кусок адреса засунуть в ip options? Очень плохая идея.
Аргументируй, пожалуйста. Место в номерах опций есть. Насколько я понял RFC791, опции обязательны к пониманию всеми участниками, то есть пакет не пройдёт дальше раутера, который такое не знает; то есть, неправильной интерпретации адреса не будет. Что ещё не так?
Именно это не так. Тут и ломается наша совместимость.
Ещё раз. Если сторона не умеет новые адреса, то она не будет распознавать пакет. Так? Так это не "ломается совместимость", это "не умеет новое", и это совершенно нормально в данной ситуации.
Вопрос цены обработки в раутерах я тут не рассматриваю, он очевиден и не в пользу варианта Павла, но о нём речь не шла.
Я думал, мы комплексно пытаемся подойти к проблеме :-)
Именно. В чём ты видишь ещё проблему, кроме банальности, что старая собака не обучится новому трюку?
Есть совместимость в пределах старых возможностей и адекватная реакция на использование новых. Это и называется корректной обратной совместимостью.
Значит мы по-разному понимаем совместимость. Если хост А не понимает options хоста В, они не совместимы.
Извини за прямоту, ты вообще пробовал в выражении "обратная совместимость" обратить внимание не только на последнее слово? ;) Или ты надеешься на магическую укладку 64 бит в 32 без потерь? ;)
Вендору легче будет держать отдельный RIP/FIB, чем ковырять уже давно вылизанное.
Не легче, извини. Просто представь себе это внутри железяки, с конкретными протоколами.
Ну вот я представил. И представил себе логику RIB/FIB lookup. Не сходится у меня картинка.
Что именно не сходится? Давай подробнее. Вот у нас есть 64-битное поле для лукапа, там, где было 32-битное. Вот у нас укладка значений в него, которая кладёт нули в старшую часть, если не задано расширение адреса. Вот лукап, в зависимости от свойств архитектуры, 1 или 2 чтения из памяти. И что принципиально меняется, кроме расширения до 3 полей в длинной записи, где этих полей (если используется комбинированный FIB стиля CEF) штук 20-30?
Вариант Павла _не_ требует dual stack. Перечти ещё раз внимательно, если не видишь, почему. Местами задвоение есть, да. Начиная с DNS (вот уж где поле непаханое извращений). Но оно будет видно только технарям. Сейчас же проблема видна любому юзеру.
Без dual stack мы лишаем коннективити старые хосты и новые. Это никому не надо.
Что ты имеешь в виду? Если оба адреса короткие, то пакеты пройдут по всей цепочке без проблем. Если хотя бы один длинный, то последствия для коннективити ровно такие же, как сейчас в случае IP4/IP6, но не нужно держать два стека со всеми последствиями этого в виде двух наборов IP блоков, двух сервисов раздачи адресов, двух комплектов настроек файрволлов, и т.д.
Даже не беря юзеров (99% из которых абсолютно плевать, чо там внутри, они мыслят категорией "сайт не грузиццо"). Возьми внутренние системы оператора, которые работают между собой по каким-то east-west, north-south протоколам. Нам надо будет либо: а) делать апдейт всего и сразу б) делать dual stack c) строить новую систему
Выбери самый простой и дешевый вариант :-)
Я как раз и описываю самый простой и дешёвый вариант. Твои же варианты требуют как минимум перевода. Чем отличается (c) от остальных вариантов?
То есть, в какой-то момент нам надо будет на определенных элементах держать стек, который понимает и новое, и старое. Что это, как не dual stack?
Нет, это не dual stack. Dual это IP4/IP6, когда стеки независимы. -netch-