2015-02-01 22:25 GMT+02:00 Pavel Gulchouck
On Sun, Feb 01, 2015 at 09:46:00PM +0200, Anton Turygin writes:
Ну как не создаст? MPLS метка создает проблемы (те же 32 бита), а твои 32 бита не создадут? В чем отличие?
MPLS увеличивает размер L2-пакета, потому что это более низкий уровень, чем IP. 64-битные IP увеличели бы размер L3-заголовка, соответственно, при том же MTU уменьшили размер L3 payload без какого-либо влияния на прохождение этих пакетов через оборудование.
Что значит уменьшили payload? Вот так взяли и уменьшили?
Ну да. Когда ты говоришь, например, "mtr --psize 1500 8.8.8.8", для вычисления размера payload mtr вычитает из этих 1500 размер IP-заголовка. При установлении IP-соединения MSS тоже устанавливается не от фонаря, а исходя из MTU интерфейса и размера ip header. В чём проблема с увеличением размера ip header? В том же IPv6 тоже по умолчанию mtu 1500, ip header больше, payload меньше - где проблема? Кто знает размер payload при установлении tcp-сессии? Пользователь не знает. Программист тоже не знает. Даже маршрутизатор - и тот толком не знает, не говоря уже о свичах. Так что да, вот так взяли и уменьшили.
Так это новый стек. В чем отличие от IPv6 кроме того, что ьебе удобно читать?
Это не новый стек. Существующий стек определяет размер payload исходя из ip mtu и размера ip-заголовка. Потом может корректировать по MSS и icmp needfrag. В этом ничего менять не надо.
[...]
Ты, похоже, постоянно думаешь, что при увеличении заголовка IP на 32 бита каким-то образом размер L2-пакета должен на эти же 32 бита тоже вырасти. Но это ведь совершенно необязательно.
Для того, чтобы оно не выросло, эти 4 байта надо где-то заимствовать.
Кто-то из нас тупит. :) Максимальный размер IP-пакета не меняется, он остаётся 1500 байт. Соответственно, размер L2-пакета тоже не меняется. Если размер ip header увеличивается, то уменьшается размер payload. Если ip header уменьшается - размер payload увеличивается. MTU всё равно остаётся 1500. Где проблема? В том, что под freebsd вместо "ping -s 1472 -D 193.0.0.100" нужно будет говорить "ping -s 1468 -D 193.0.0.100", потому что тамошний пинг, в отличие от линуксового, не вычитает sizeof(struct ip_header), или где-то ещё?
Ну то есть, ты предлагаешь кусок адреса засунуть в ip options? Очень плохая идея.
Можно по пунктам проблемы IPv6 и чем твои 64bit лучше?
В этом треде приводил чуть раньше перечислал по пунктам.
Извини, но совсем неубедительно :-)
Мы уже разобрались, что все равно нужен новый стек. Совместимости нет.
Нет, извини. Новый стек не нужен, нужна модификация старого. Полной совместимости нет, обратная совместимость есть.
Я так и не понял, что такое "обратная совместимость". Ты же сам написал, что старые стеки с новыми работать не будут. Значит совместимости нет.
Нужны новые протоколы (либо реинжиниринг старых).
Да. Есть уровень стека, протоколов, админов, разработчиков, юзеров... Для расширения адресного пространства достаточно изменений на уровне стека и протоколов. IPv6 же требует нетривиальных действий вообще на всех уровнях.
Ну каких, например, нетривиальных действий? В твоем подходе тоже надо полностью перерабатывать маршрутизаторы. Переписывать логику работы ткам-ов и т.п. Вендору легче будет держать отдельный RIP/FIB, чем ковырять уже давно вылизанное.
А в IPv6, например, нет бродкаста. Переработана фрагментация. Нативный ipsec.
Ты так говоришь, как будто это что-то хорошее. :)
С моей точки зрения, это очень хорошие и здравые подходы. Они работают и их можно оценить. Я не увидел в твоем подходе вообще ничего, что кардинально отличалось бы от подхода IPv6. Кроме размера адреса и вроде как какого-то удобства для разработчиков софта. Никто не будет держать два паралельных интернета без взаимодоступности. Ни контентщики, ни сервисники. Все равно это все вырождается в дуалстек, нат и т.д. И, как следствие, тем же migration technics, поторые применяются для IPv6. В которых, кстати, какого-то rocket science нет.