Sun, Feb 01, 2015 at 21:08:00, anton wrote about "[uanog] Re: [uanog] Re: [uanog] Белые IP Freenet/O3":
Как ты будешь мерять MTU в транспортной сети между двумя хостами? Кто будет фрагментировать? Что произойдет, если icmp не ходит? Ничего не изменится по отношению к тому, как оно есть сейчас. А как оно есть сейчас?
Вот пример. При одном и том же MTU 1500, если анализировать TCP пакеты, можно увидеть два типичных варианта: MSS 1460 и 1448. Первое возникает при отсутствии опций увеличения размера окна свыше 64K - что типично для всяких мелких железяк прошлого поколения, до тотальной линуксизации и выхода в режим "процессором для embedded называется 32-битный процессор" - отказа широких вендорских масс работать на AVR/PIC/etc. Второе - при современной ОС на 32/64-битном железе, когда добавляются такие опции. Прикладное же программирование вообще не меняется. Конечно, можно предположить, что где-то в Пенджабе очередной Сутрапохмел Абдулкумар сделает Первый Великий Ляп работы с TCP - предположит, что тот сохраняет границы порций по send(), и будет посылать по 1460 - но даже среди таких это будет очень редкий случай.
Из-за этой проблемы (отчасти) фрагментацию в IPv6 переложили на плечи хостов.
Эта проблема там ни при чём. Отказ от фрагментации на раутерах, это неоднократно писалось прямым текстом, вызван двумя причинами: 1. Разгрузка процессоров раутеров. По этой же причине убрали hop limit (бывший TTL) из контрольной суммы IP заголовка: если пакет побьётся, целостность этого поля непринципиальна, а не-пересчитывать каждый раз контрольную сумму, это - величайший выигрыш. 2. Избавление от проблем последовательной фрагментации. Пример: если есть промежуточные линки с MTU 1400 и где-то за ним с 1300, то в IP4 без DF на финальный хост придёт 1300+100+100, а не 1300+200 (для ясности, размер fragment header не считаю). Само по себе это никак не лечит проблемы MTU и фрагментации, разве что способно методом шоковой терапии заставить всех написать правильную реализацию. Но, судя по тому, что в 2015 году продолжаются проблемы с негенерацией ICMP needfrag в чуть нетривиальных конструкциях типа "IPIP внутри IPSec", руки писателей стеков от этого не выпрямились (наблюдали с месяц назад на Linux). Генерацию на конечных хостах чуть улучшили - теперь она умеет, например, сама пробовать уменьшать MTU, если перестали проходить пакетики; но, с учётом скорости реакции этого механизма, для чего-то с требованием оперативности быстрее минуты лучше писать реализацию самому поверх UDP, чем полагаться на эти механизмы.
Относительно к IPv6, с которого все началось. Вы реально думаете, что они настолько упоротые, что не увидели "простого и элегантного" решения, в котором "все решается само"?
Да, они упоротые. Потому что реально ничего вообще не продумывалось. В 1994-м (год окончательного принятия 128 бит) шли шатания в предложениях; было параллельно 64 и 128, причём 128 вначале состояли из двух разных уникальных адресов (!) - 64 на глобально уникальный и 64 на локально уникальный. Одно это уже способно однозначно показать, в каких безумных эмпиреях и воздушных замках витали авторы предложения. Обсуждение вариантов молча (письменных свидетельств нет) завершилось на 128 битах после того, как некто Daniel L. McDonald из рассылки SIPP (оно тогда так называлось) 07.07.1994 написал следующие слова: ===== Yes, you said the magic words, "FIXED LENGTH." I have espoused the virtues of fixed length addresses before. My biggest beef with variable length addresses is the issue of maintaining additional state or taking additional time to parse an address whose length I don't know at the start.<...> Parsing addresses is a problem all along the path (both network hops, and within each system) an IPng datagram takes. Both routers and end-systems have to parse addresses, at least to the point of finding a fast path. Our implementation experience has shown us that variable length addresses adds a whole new layer of complexity to things such as: * Routing lookups * User interface issues * Storage requirements * Address parsing (for lookups, incoming packets, etc.) and everyone's favorite * Application programmer level backward compatibility ===== С этого момента предложение на 64 бита _молча_ исчезло, оставив в силе предложение с двумя уникальными адресами(!!!!!), и только через некоторое время оно преобразовалось в нынешний вариант - когда рекомендацией для младшей половины является EUI-64, и оно уникально в пределах фиксированной старшей половины, а не вообще; но именно EUI-64 происходит из идеи "младшая половина уникальна сама по себе". Вся эта безумная траектория предложений и показывает, что реального рассмотрения альтернатив НЕ БЫЛО. "Узкая группа ограниченных людей" (tm) варилась в своём соку, занимаясь вопросами, которые никому больше не были интересны, и выдвигала предложения без всякого практического обоснования. Более того, старт работы этой группы начался ещё в 92-м году, когда был в ходу классовый раутинг, на котором адреса должны были закончиться не позже 96-го; введение безклассового оттянуло конец IP4 на 20 лет, но это сделала ДРУГАЯ группа, а не та, которая строила воздушные замки вокруг SIP -> SIPP -> IPv6. И, да, переход на безклассовый раутинг был реформой примерно того же типа, что предлагает Павел, хотя заметной только для сетевиков; писатели прикладного софта её не заметили, а вот писателям сетевого пришлось переделать чуть менее чем всё. Не знаю, работал ли ты тогда в телекоммуникациях, но можешь погуглить по словам "два раутера Bay Networks, BGP, RIPv1 и падение всего интернета", ветераны ещё должны помнить - эта история как, извините за длинное слово, квинтэссенция всех проблем этого перехода. -netch-