Здравствуйте, vsb, Вы писали:
vsb>Если IPv6 реализовывать как полагается, то как раз 64 бита и будет использоваться для адресации устройства. Вторые 64 бита должны быть случайными. Причём на квартиру должны подавать вообще 48 битов, а внутри квартиры уже на 65536 устройств можно раскидать адреса. Правда те, кто IPv6 реализует, естественно, ничего не понимают в этом и зачастую делают как попало, вплоть до организации NAT-а на IPv6 но это проблема не стандартов.
Вообще случайная генерация 64 бит — это уже доработки и костыли, когда выяснили насколько же кривое поделие вышло.
Ты просто обоснуй необходимость в каждом пакете через всё сеть слать 64 + 64 бита случайных данных. Условно говоря 1-2% всего трафика — никому не нужный мусор, просто из-за изумительно квалификации авторов IPv6.
vsb>А так — IPv4 оказался достаточно хорош, насущной необходимости принимать входящие подключения на туалетной бумаге не возникло, поэтому никуда IPv4 и не девался. И не денется. Хотя и IPv6 тоже применяется широко.
Это то и удивляет, как имея хороший протокол можно было наворотить IPv6 и потом его 20 лет адаптировать, менять и дорабатывать новыми RFC.
Re[3]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, m2l, Вы писали:
m2l> Условно говоря 1-2% всего трафика — никому не нужный мусор, просто из-за изумительно квалификации авторов IPv6.
На общем фоне "эффективности" ("замусоренности") современных веб-ресурсов — это ни о чем. А там, где это имеет значение, используют различные техники повышения эффективности полезной нагрузки (типа jumbo frames) и сокращения маршрутов (чего в условиях IPv4 добиться или очень сложно или нереально).
Re[9]: Разумность 16 байтных IP-адресов - ведь глупость сдел
Здравствуйте, Shmj, Вы писали:
S>Обоснуй. Дай план как ты пытался распределить и почему тебе не хватило 18 квинтиллионов адресов.
Представь, что ты облачный провайдер. У тебя есть своя подсеть /64. В твоем распоряжении осталось 8 байт. 1 байт — датацентр, 1 байт availability zone внутри датацентра, 3 байта — идентификатор клиента, и еще три байта в распоряжение клиента. Всё, адресное пространство закончилось.
лэт ми спик фром май харт
Re[4]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, Anton Batenev, Вы писали:
AB>На общем фоне "эффективности" ("замусоренности") современных веб-ресурсов — это ни о чем. А там, где это имеет значение, используют различные техники повышения эффективности полезной нагрузки (типа jumbo frames) и сокращения маршрутов (чего в условиях IPv4 добиться или очень сложно или нереально).
Да даже поиск по IP сделать — уже лучше 8 байт — нейтивный для процессора тип.
Re[10]: Разумность 16 байтных IP-адресов - ведь глупость сдел
Здравствуйте, mrTwister, Вы писали:
T>Представь, что ты облачный провайдер. У тебя есть своя подсеть /64. В твоем распоряжении осталось 8 байт. 1 байт — датацентр, 1 байт availability zone внутри датацентра, 3 байта — идентификатор клиента, и еще три байта в распоряжение клиента. Всё, адресное пространство закончилось.
Не нужно разбрасываться байтами. Так не хватит никаких байт.
Нужно распоряжаться на уровне бит.
Концепцию портов — не стоит отменять, она довольно удобна. Стандартные порты, форвардинг портов и т.д. — все удобно.
Клиенту не давать пачку просто так — только 1 адрес, по запросу 2, 3 и т.д. Т.е не разбрасываться. Можно порт встроить в IP, но тогда останется 6 байт а не 8, а это уже ну не так чтобы мало, но без запаса. Т.е. не нужно разбрасываться — может клиенту 1 адрес нужен — а вы ему выделили сразу 16 млн. Зафига?
И так смотришь — уже нет такой необходимости миллиарды расходовать на пустом месте.
Re[5]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, Shmj, Вы писали:
S>Клиенту не давать пачку просто так — только 1 адрес, по запросу 2, 3 и т.д. Т.е не разбрасываться. Можно порт встроить в IP, но тогда останется 6 байт а не 8, а это уже ну не так чтобы мало, но без запаса. Т.е. не нужно разбрасываться — может клиенту 1 адрес нужен — а вы ему выделили сразу 16 млн. Зафига?
И еще потом каждому роутеру объясняй, как роутить пакеты для каждого адреса, что вот эти два адреса принадлежат одноу клиенту, им можно друг с другом общаться, а вот другим адресам нельзя. И как только выдаем новый адрес кому-то, то не забыть сходить переконфигурировать роутеры и фаерволы. Спасибо. Чтобы этой голимотьей не заниматься, и придумали IPv6, на нем можно построить гораздо более простую и надежную инфраструктуру. Без центральных реестров адресов, без натов, без переконфигурирования фаерволов и роутеров на каждый чих.
S>И так смотришь — уже нет такой необходимости миллиарды расходовать на пустом месте.
Чтобы тратить триллионы на наты, управление каждым отдельным адресом и гигантские таблицы маршрутизации?
лэт ми спик фром май харт
Re[10]: Разумность 16 байтных IP-адресов - ведь глупость сдел
Здравствуйте, mrTwister, Вы писали:
S>>Обоснуй. Дай план как ты пытался распределить и почему тебе не хватило 18 квинтиллионов адресов.
T>Представь, что ты облачный провайдер. У тебя есть своя подсеть /64.
Уже не представляю себе. Раз ты про /64, значит, там больше 64, значит, современный IPv6. К нему PA allocation даётся блоками /32.
T> В твоем распоряжении осталось 8 байт. 1 байт — датацентр,
На каждый датацентр будет свой PA, скорее всего. Если мы говорим про реально распределённый случай (как у (условного) AWS — один в Каролине, другой в Польше, третий в Шанхае), а не про несколько соседних зданий. Так что ещё больше.
T> 1 байт availability zone внутри датацентра, 3 байта — идентификатор клиента, и еще три байта в распоряжение клиента. Всё, адресное пространство закончилось.
Клинический бред, извини, основанный на полном игнорировании прилагающихся к адресации рекомендаций практик раздачи адресов. Откуда ты вообще это высосал и зачем?
The God is real, unless declared integer.
Re[12]: Разумность 16 байтных IP-адресов - ведь глупость сдел
Здравствуйте, mrTwister, Вы писали:
T>И еще потом каждому роутеру объясняй, как роутить пакеты для каждого адреса, что вот эти два адреса принадлежат одноу клиенту, им можно друг с другом общаться, а вот другим адресам нельзя.
Это в любом случае нужно делать, т.к. то что клиент взял 10 IP адресов — не значит что ему нужны они для одного и того же ресурса. Возможно и скорее всего ресурсы не связанные и правила должны быть особыми.
T>И как только выдаем новый адрес кому-то, то не забыть сходить переконфигурировать роутеры и фаерволы.
Иначе никак. Можно сразу пачку выдавать, но не автоматом а по запросу. И это не должно быть дармовым. Не дорогим, но не дармовым — иначе никаких емкостей не хватит — я один заберу все.
T>Спасибо. Чтобы этой голимотьей не заниматься, и придумали IPv6, на нем можно построить гораздо более простую и надежную инфраструктуру. Без центральных реестров адресов, без натов, без переконфигурирования фаерволов и роутеров на каждый чих.
Никак не получится — выдача по своей сути централизованная. Иначе я один заберу себе все адресам мира.
S>>И так смотришь — уже нет такой необходимости миллиарды расходовать на пустом месте. T>Чтобы тратить триллионы на наты, управление каждым отдельным адресом и гигантские таблицы маршрутизации?
Наоборот — когда адрес сократится до нейтивного для большинства процессоров — будет экономия. Притом и экономия памяти в таблицах маршрутизации.
Re[12]: Разумность 16 байтных IP-адресов - ведь глупость сдел
Здравствуйте, mrTwister, Вы писали:
S>>Клиенту не давать пачку просто так — только 1 адрес, по запросу 2, 3 и т.д. Т.е не разбрасываться. Можно порт встроить в IP, но тогда останется 6 байт а не 8, а это уже ну не так чтобы мало, но без запаса. Т.е. не нужно разбрасываться — может клиенту 1 адрес нужен — а вы ему выделили сразу 16 млн. Зафига?
T>И еще потом каждому роутеру объясняй, как роутить пакеты для каждого адреса, что вот эти два адреса принадлежат одноу клиенту, им можно друг с другом общаться, а вот другим адресам нельзя.
Выдача в IPv6, точно так же как IPv4, идёт блоками адресов фиксированной длины префикса. Ты сам в предыдущем сообщении использовал обозначения типа /64, но не понимаешь, что они значат.
T> И как только выдаем новый адрес кому-то, то не забыть сходить переконфигурировать роутеры и фаерволы. Спасибо. Чтобы этой голимотьей не заниматься, и придумали IPv6, на нем можно построить гораздо более простую и надежную инфраструктуру. Без центральных реестров адресов, без натов, без переконфигурирования фаерволов и роутеров на каждый чих.
Ты вообще хоть немного понимаешь, о чём говоришь, или нет? Я очень сомневаюсь.
Разница возникает в других местах.
S>>И так смотришь — уже нет такой необходимости миллиарды расходовать на пустом месте. T>Чтобы тратить триллионы на наты, управление каждым отдельным адресом и гигантские таблицы маршрутизации?
Здравствуйте, Anton Batenev, Вы писали:
S>> Да даже поиск по IP сделать — уже лучше 8 байт — нейтивный для процессора тип.
AB>По поводу поиска я тебе уже отвечал, что в "правильно" спроектированном api или программе размерность адреса не имеет абсолютно никакого значения.
Очень даже имеет, в плане скорости работы.
То, что влезает в один регистр, передаётся через регистр.
То, что не влезает, как 16-байтное значение, уже требует подпорок разных стилей. В Unix стиле, включая, например, соглашения по вызову для x86-64 и AArch64, могут передаваться парой регистров. В других уже будут передаваться в стеке или по указателю. В памяти тут уже дороже. По указателю — ещё дороже, лишняя индирекция.
Аналогично, возьмём, например, сравнение по маске. Пусть у тебя есть три параметра: сравниваемый адрес, адрес образца и длина префикса образца (больше 0). Вариант для одного целого: вычислил маску: ~((1ul<<(64-pl))-1ul), и сравнил. Как будет выглядеть вариант для 128 бит? Если нет нативной поддержки uint128_t, будет явное ветвление в коде, дорого. Если есть uint128_t, будет неявное ветвление, с тем же результатом. Можешь посмотреть сам на компиляторный выхлоп.
Раутеры, кстати, в своей массе не умеют вообще работать с префиксами длиннее /64 для раутинга за пределами локального интерфейса — они сравнивают только старшую половинку IPv6 адреса, а в соответствующих протоколах маршрутизации такие префиксы просто выкидывают. Это именно потому, что иначе будут потери в дохрена процентов на обработке каждого пакета или раута — а оно того не стоит.
The God is real, unless declared integer.
Re[11]: Разумность 16 байтных IP-адресов - ведь глупость сдел
T>> 1 байт availability zone внутри датацентра, 3 байта — идентификатор клиента, и еще три байта в распоряжение клиента. Всё, адресное пространство закончилось.
N>Клинический бред, извини, основанный на полном игнорировании прилагающихся к адресации рекомендаций практик раздачи адресов. Откуда ты вообще это высосал и зачем?
Healthcheck nodes обращаются к балансировщикам с помощью так называемых квази-IPv6-адресов. Квазиадрес — это IPv6-адрес, внутри которого зашит IPv4-адрес и id подсети пользователя. Трафик попадает на балансировщик, тот извлекает из него IPv4-адрес ресурса, заменяет IPv6 на IPv4 и отправляет пакет в сеть пользователя.
Такое использование ipv6 тоже не соответствует практикам и рекомендациям? А тем не менее, сервиспровайдеры изгаляются так, как им удобно.
лэт ми спик фром май харт
Re[11]: Разумность 16 байтных IP-адресов - ведь глупость сдел
Здравствуйте, Shmj, Вы писали:
S>Клиенту не давать пачку просто так — только 1 адрес, по запросу 2, 3 и т.д. Т.е не разбрасываться. Можно порт встроить в IP, но тогда останется 6 байт а не 8, а это уже ну не так чтобы мало, но без запаса. Т.е. не нужно разбрасываться — может клиенту 1 адрес нужен — а вы ему выделили сразу 16 млн. Зафига?
Если мы хотим сделать, чтобы NAT был нужен только для параноиков, а остальным хватало разумного файрволла плюс, хотелось бы, временные дополнительные адреса через SLAAC, то это означает, что на каждый эзернет-сегмент нужно 16 бит. Ну с большим скрипом 12.
Если же ещё на клиента предполагаем несколько таких сегментов, то ещё 4 или 8.
Получается в сумме от 16 до 24 бит.
Вот это уже вполне нормальные затраты.
NATʼом можно, конечно, сократить до 1 адреса. Но некузяво.
Кстати, даже на NAT лучше выделять побольше. На локалку уровня "2 продажника и бухгалтер" — 4 адреса.
И да, это уже осмысленные затраты, а не 2^80 как на текущей рекомендуемой схеме для IPv6.
S>И так смотришь — уже нет такой необходимости миллиарды расходовать на пустом месте.
The God is real, unless declared integer.
Re[4]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, Anton Batenev, Вы писали:
m2l>> Условно говоря 1-2% всего трафика — никому не нужный мусор, просто из-за изумительно квалификации авторов IPv6.
AB>На общем фоне "эффективности" ("замусоренности") современных веб-ресурсов — это ни о чем. А там, где это имеет значение, используют различные техники повышения эффективности полезной нагрузки (типа jumbo frames)
Ни разу не видел на дальних маршрутах MTU больше 1500. Часто даже меньше, за счёт MPLS и прочих туннелей.
AB> и сокращения маршрутов (чего в условиях IPv4 добиться или очень сложно или нереально).
IPv6 этому ничуть не помогает.
The God is real, unless declared integer.
Re[12]: Разумность 16 байтных IP-адресов - ведь глупость сдел
Здравствуйте, mrTwister, Вы писали:
T>>> 1 байт availability zone внутри датацентра, 3 байта — идентификатор клиента, и еще три байта в распоряжение клиента. Всё, адресное пространство закончилось.
N>>Клинический бред, извини, основанный на полном игнорировании прилагающихся к адресации рекомендаций практик раздачи адресов. Откуда ты вообще это высосал и зачем?
T>Каких рекомендаций, каких практик?
Читай документы IANA, и разных RIRов, как RIPE NCC.
/32 на провайдера (PA), от /32 до /48 на PI.
У провайдера от /48 до /56 для не-collocation клиента (который подключен проводом любого типа).
Клиент распределяет их своими средствами на энное количество локалок, каждая по /64.
Вот это то, что установлено в реале, а не то, что ты вычислил по трещинам на потолке.
T> Вот, например, статья: https://habr.com/ru/companies/yandex/articles/448588/ T>
Healthcheck nodes обращаются к балансировщикам с помощью так называемых квази-IPv6-адресов. Квазиадрес — это IPv6-адрес, внутри которого зашит IPv4-адрес и id подсети пользователя. Трафик попадает на балансировщик, тот извлекает из него IPv4-адрес ресурса, заменяет IPv6 на IPv4 и отправляет пакет в сеть пользователя.
T>Такое использование ipv6 тоже не соответствует практикам и рекомендациям? А тем не менее, сервиспровайдеры изгаляются так, как им удобно.
Принципы формирования локальной части IPv6 адреса, не пересекающейся с EUI-64, отданы на откуп локальным правилам. Тем более то, что ты описал, это на 200% внутренняя кухня и не имеет отношения к обсуждаемым вопросам.
The God is real, unless declared integer.
Re[3]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, m2l, Вы писали:
vsb>>Если IPv6 реализовывать как полагается, то как раз 64 бита и будет использоваться для адресации устройства. Вторые 64 бита должны быть случайными. Причём на квартиру должны подавать вообще 48 битов, а внутри квартиры уже на 65536 устройств можно раскидать адреса. Правда те, кто IPv6 реализует, естественно, ничего не понимают в этом и зачастую делают как попало, вплоть до организации NAT-а на IPv6 но это проблема не стандартов.
m2l>Вообще случайная генерация 64 бит — это уже доработки и костыли, когда выяснили насколько же кривое поделие вышло. m2l>Ты просто обоснуй необходимость в каждом пакете через всё сеть слать 64 + 64 бита случайных данных. Условно говоря 1-2% всего трафика — никому не нужный мусор, просто из-за изумительно квалификации авторов IPv6.
Я не обосную, я в этом разбираюсь плохо. Но я уверен, что протокол проектировали люди, которые потратили куда больше времени на обдумывание вариантов и я им доверяю.
А так — если в IPv4 внимательно вглядеться, там тоже много ненужных полей.
Version: 4 bits, For IPv4, this is always equal to 4.
Differentiated Services Code Point (DSCP): 6 bits
Explicit Congestion Notification (ECN): 2 bits
Total Length: 16 bits (реально хватило бы 12 битов, если мы говорим про публичный интернет)
Identification: 16 bits
Fragment Offset: 13 bits
Protocol: 8 bits (реально используется 3-4 протокола, 2 битов бы хватило)
Header Checksum: 16 bits (в низлежащих протоколах контрольная сумма есть, это не нужно)
Всё это — мусор, нужный только в крайне редких случаях. Ничего, живём как-то. Если так жалко 16 байтов, лучше пожаловаться на то, что дефлтный 1.5 КБ пакет стоило бы увеличить раз в 10, тогда уже будет не 1-2%, а 0.1-0.2%.
Re: Разумность 16 байтных IP-адресов - ведь глупость сделали
S>Не кажется
S>Более того — 8 байт это 4 группы по 4 цифры — типа FFAA-BBDD-5566-7788. Т.е. похоже на всем нам знакомый номер банковской карты, расширенный до 16-ричных цифр. Просто и удобно.
S>И похоже
S>И кажется
Слушай, а можешь сформулировать простыми словами, для не очень умного человека — какую проблему ты хочешь этим решить?
Все проблемы от жадности и глупости
Re[13]: Разумность 16 байтных IP-адресов - ведь глупость сдел
N>Читай документы IANA, и разных RIRов, как RIPE NCC. N>/32 на провайдера (PA), от /32 до /48 на PI. N>У провайдера от /48 до /56 для не-collocation клиента (который подключен проводом любого типа). N>Клиент распределяет их своими средствами на энное количество локалок, каждая по /64. N>Вот это то, что установлено в реале, а не то, что ты вычислил по трещинам на потолке.
А, ты про это. Я просто хотел на пальцах показать что не все 128 бит используются для адресации, соответственно столько там квантилионов получается — это не важно. Важно, что адрес поделен на куски и значительная часть адреса используется для кодирования разной информации.
N>Принципы формирования локальной части IPv6 адреса, не пересекающейся с EUI-64, отданы на откуп локальным правилам. Тем более то, что ты описал, это на 200% внутренняя кухня и не имеет отношения к обсуждаемым вопросам.
Ну и что что локальная кухня, почему она не имеет отношения к обсуждаемым вопросам? Кто-то на этой локальной кухне будет свой фаерволл настраивать, кто-то еще что придумает. 0
лэт ми спик фром май харт
Re[4]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, vsb, Вы писали:
vsb>Я не обосную, я в этом разбираюсь плохо. Но я уверен, что протокол проектировали люди, которые потратили куда больше времени на обдумывание вариантов
В том и проблема, что нет, ничего они не обдумывали.
В 1994(!) в рассылках SIPP и потом IPng шло обсуждение двух схем, на 8 и на 16 байт, причём 16-байтная была такая, что 64 — globally unique(!!!) и 64 — locally unique, а зачем одновременно два адреса — никто не думал.
Потом проскочила одна реплика "любая схема с фиксированной длиной лучше схемы с переменной".
Потом мистически (потому что не было видно обсуждения, может, оно прошло вживую) остался только один вариант, 16 байт.
И уже потом переназначили на то, что младшие 8 байт добавляются к старшим.
Архив SIPP есть, архива IPng я быстро не нашёл, там основное — район сентября 1994. Увы, не сохранил, а надо было бы сделать локальную копию. Найдёте — скажите URL.
vsb> и я им доверяю.
Вот это и есть полная глупость тут. Не было там никакого разумного рассмотрения размерности адреса.
vsb>А так — если в IPv4 внимательно вглядеться, там тоже много ненужных полей. vsb>Version: 4 bits, For IPv4, this is always equal to 4.
Давайте по порядку.
Здесь они предполагали сети, в которых не было разделения через ethernet frame type на v4 и v6 (и на другие типы), потому что была ещё завязка на поддержку IEEE 802.3 (который передаёт длину, а не тип). Позже все транспорты IEEE 802.3 были тупо отвергнуты, остался Ethernet II, который передаёт именно тип кадра.
Да, это легаси, но которое не могли быстро отвергнуть. Точно так же как до 2020 не хотели оставить единственность 2ʼs complement для C++.
vsb>Differentiated Services Code Point (DSCP): 6 bits
Оно сейчас активно используется, вы не в курсе.
vsb>Explicit Congestion Notification (ECN): 2 bits
Вы с TCP перепутали. И там оно используется.
vsb>Total Length: 16 bits (реально хватило бы 12 битов, если мы говорим про публичный интернет)
Иногда таки бывают пакеты побольше. В IPv6 поле убрано.
vsb>Identification: 16 bits vsb>Fragment Offset: 13 bits
В IPv6 исправили, вынесли в fragment header.
vsb>Protocol: 8 bits (реально используется 3-4 протокола, 2 битов бы хватило)
UDP, TCP, SCTP, ICMPv4, ICMPv6, IPIP (два), GRE, ESP, AH, L2TP. Это те, что постоянно используются. Это уже 11 штук. С запасом на расширение и эксперименты как раз 1 байт и получится. Заметьте, UDP — самый простой сейчас — номер 17. Потому что простота не возникает сразу, нужен опыт.
vsb>Header Checksum: 16 bits (в низлежащих протоколах контрольная сумма есть, это не нужно)
В IPv6 устранили, да.
Зато там заполнили оставшееся место flow label на 20 бит, которая реально используется около нуля.
vsb>Всё это — мусор, нужный только в крайне редких случаях. Ничего, живём как-то. Если так жалко 16 байтов, лучше пожаловаться на то, что дефлтный 1.5 КБ пакет стоило бы увеличить раз в 10, тогда уже будет не 1-2%, а 0.1-0.2%.
Это тоже имеет смысл, да. Особенно на нынешних скоростях.
The God is real, unless declared integer.
Re[5]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, netch80, Вы писали:
N>Потом проскочила одна реплика "любая схема с фиксированной длиной лучше схемы с переменной".
Я её, пожалуй, тут приведу...
Subject: re: IPng ADs Wish to Gauge Consensus on Address Length Requirements
To: SIPP Mailing list <sipp@sunroof2.eng.sun.com>,
big-Internet@munnari.oz.au
Date: Thu, 7 Jul 1994 15:35:29 -0500 (EST)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Daniel L. McDonald" <danmcd@sundance.itd.nrl.navy.mil>
Cc: mankin@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu,
"Daniel L. McDonald" <danmcd@sundance.itd.nrl.navy.mil>
Message-Id: <9407072035.aa15952@sundance.itd.nrl.navy.mil>
> Hi, TUBA, SIPP, CATNIP, BIG-INTERNET, and IETF:
Hi from SIPP, IETF, and BIG-INTERNET.
> At this time it would appear to us that there is considerable consensus
> that a fixed length, topologically structured, hierarchical
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. Granted,
flow ID's and optimizing for certain common ("fast path") cases may help
this, but flow ID's still require tables with flow ID's for keys, and
today's common case may be tomorrow's exception. Authentication and
encryption also present problems similar to flow ID's with key lookup. I
don't want to rewrite my (statically configured) OS kernel in 4 years when
today's common cases no longer exist. (Although, admittedly, current trends
in OS research may render this argument obsolete.)
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:
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. Granted,
flow ID's and optimizing for certain common ("fast path") cases may help
this, but flow ID's still require tables with flow ID's for keys, and
today's common case may be tomorrow's exception. Authentication and
encryption also present problems similar to flow ID's with key lookup. I
don't want to rewrite my (statically configured) OS kernel in 4 years when
today's common cases no longer exist. (Although, admittedly, current trends
in OS research may render this argument obsolete.)
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:
Since it is still fixed length it has none of the nightmares of
variable-length addresses.
> longer than 16 byte fixed length address now.
I would like to see why we NEED any address space above 16-bytes. Does
anyone have any solid arguments as to why 16 bytes is not enough? I've seen
ones for 8, but not 16.
Also, let's consider alignment issues if picking a size above 16 bytes. 20
blows 8-byte alignment, 24 does not. (But of course, if 128-bit machines
happen, 24-byte addresses will be annoying on 128-bit machines.)
But hey, at least it's fixed length.
> only 16 byte length addresses now but ability
> to lengthen the address later.
This will add confusion to implementations, and smacks of variable-length.
Experience with OSI implementations shows that many do not handle NSAP's
greater than 20 bytes.
Absolutely not a good idea.
> At this point the consensus among the IPng directorate
> and on several of the mailing lists seems fairly clear
> (a 16 byte length address is good for those things).
Yes, but IMHO, no MORE than 16 bytes.
> This is a good time to bring forward your remaining views
> about the requirements for address length for IPng.
My position can be best summarized as:
The SMALLEST possible fixed-length address. And that length
better have a good justification for why it cannot be smaller.
--
Dan McDonald | Mail: {danmcd,mcdonald}@itd.nrl.navy.mil --------------+
Computer Scientist | WWW: http://wintermute.itd.nrl.navy.mil/danmcd.html |
Naval Research Lab | Phone: (202) 404-7122 #include <disclaimer.h> |
Washington, DC | "Rise from the ashes, A blaze of everyday glory" — Rush +
Вот так, военный рявкнул — все взяли под козырёк.
А вот почему smallest оказался 16 байт — найти не получается.
И финально:
To: sipp@sunroff.eng.sun.com, ipng@cmf.nrl.navy.mil,
big-internet@munnari.oz.au
Cc: deering@parc.xerox.com
Subject: SIPP-16 draft
Date: Mon, 18 Jul 1994 01:13:15 PDT
X-Orig-Sender: Steve Deering <deering@parc.xerox.com>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <94Jul18.011317pdt.12171@skylark.parc.xerox.com>
I have submitted a new version of the SIPP spec, with 16-byte addresses,
as an Internet Draft. If you want to grab a copy before it shows up in
the official directories, you can get it from:
Besides the change of address size, a number of other changes were made,
arising from the implementors' meeting in Seattle and subsequent events.
Be sure to read through Appendix B to find out everything that changed
since the last draft.
Steve
После этого молча все переключились на 16-байтный вариант.
N>Потом мистически (потому что не было видно обсуждения, может, оно прошло вживую) остался только один вариант, 16 байт. N>И уже потом переназначили на то, что младшие 8 байт добавляются к старшим.
