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), или где-то ещё? Да и добавление четырёх байт к L2 header (802.1q, q-in-q) никаких особенных проблем не вызывает, но это совсем другая история.
Относительно к IPv6, с которого все началось. Вы реально думаете, что они настолько упоротые, что не увидели "простого и элегантного" решения, в котором "все решается само"?
Я думаю, что они жили в другом веке, и плохо себе представляли степень распространения IP и сложности перехода с одного протокола на другой в то время, когда этот переход окажется необходим.
Кроме того, они в уме считали прибыли от продажи железа с поддержкой IPv6, софта с поддержкой IPv6, курсов по обучению IPv6 и всего остального. Как, например, производители автомобилей - они не тупые, что ставят пластиковые бамперы, которые гнутся одновременно со всем кузовом, просто им это выгодно. В отличие от пользователей.
Да, вот только подход IPv6 в части фрагментации, например, снижает требования к маршрутизаторам, убирая оттуда эту функцию. А, следовательно, снижает их стоимость.
Есть у меня большие подозрения, что при распространении IPv6 и появлении там серьёзного туннелирования с криптованием, от фрагментирования никуда уйти не получится. В IPv4 тоже TCP фрагментировать не положено, но по факту фрагментируется аж бегом.
Можно по пунктам проблемы IPv6 и чем твои 64bit лучше?
В этом треде приводил чуть раньше перечислал по пунктам.
Мы уже разобрались, что все равно нужен новый стек. Совместимости нет.
Нет, извини. Новый стек не нужен, нужна модификация старого. Полной совместимости нет, обратная совместимость есть.
Нужны новые протоколы (либо реинжиниринг старых).
Да. Есть уровень стека, протоколов, админов, разработчиков, юзеров... Для расширения адресного пространства достаточно изменений на уровне стека и протоколов. IPv6 же требует нетривиальных действий вообще на всех уровнях.
А в IPv6, например, нет бродкаста. Переработана фрагментация. Нативный ipsec.
Ты так говоришь, как будто это что-то хорошее. :) -- Паша.