Ритчи-88 говорил, что если что - люди как-нибудь выживут. Это перекликается с определением некоторых UB флагами компилятора (strict aliasing, знаковое переполнение).
people will somehow survive. C has, after all,survived the vararg and the extern problems.
Ритчи-00 считал, что вклад нового стандарта уступает прежнему, но тоже ничего. Слишком много фич.
I certainly don't desire additional ones [features], and the most obvious reaction is that I wish they [committee] had resisted more firmly.
Ритчи-00 овладевала индифферентность - он называл "вероятно полезной" вещь, которую Ритчи-88 запретил даже переизобретать (noalias из черновика C89 => restrict из C99).
The fact that the Internet is doubling in size about every 11 months means that the cost of transition to IPng (in terms of equipment and manpower) is also increasing.
If the cost of transition outweighed the pain of other solutions (application gateways or address translators) customers would not deploy IPng.
IPng should appear simply like a new release of IPv4; although this would not necessarily bring new features...
Вот это "If we can't transition to the new protocol, then no matter how wonderful it is" из RFC1726 (1994).
"We were assuming a transition between IPv4 and pure IPv6" журналу в 1999 под спойлером в комменте выше.
_____
И мне кажется, или план IETF опирался на одну очень крупную идею, которая не сбылась из-за затянутого перехода?
Интернет переходит на чистый IPv6 => не надо больше маршрутизировать IPv4 между AS => большая ожидаемая выгода (цена TCAM-памяти?), потому что IPv4 фрагментированно распределялся мелкими блоками ("IPv4 swamp") => ради возможности "дефрагментации" отказались от расширения IPv4 вправо через Options или инкапсуляцию доп. заголовка как в IPv4+4 (был шанс избежать изменений в BGP, автоматически сделать каждого владельца IPv4 владельцем ~2^24 IPv4+4, уменьшить число технологий перехода...).
Была ли такая жертва во имя маршрутизации-в-мире-без-IPv4?
Так вы на предпосылку своего вопроса посмотрите - "одинаковая мучительность перехода на любой IPng следует из необходимости обновления сетевого стека ОС и оконечного оборудования". Она очевидно ложная, потому что сетевой стек и оконечное оборудование давно обновлены под IPv6.
На NT4.0 можно было попробовать с весны 1998 (картинка в тему с реддита).
А выступление вы подозрительно обрезали, там всего одного предложения не хватает: "...and the decision was trying to upgrade V4 is as hard as trying to roll out V6, we'll just roll out V6. This is a in-te-res-ti-ng design decision that was made in 1994". Там не говорится, что решение (и понимание проблемы) было верное. Говорится, что оно ин-те-рес-ное и нам в этом интересном мире теперь жить (reality of life, suck it up). И дальше, что IETF игнорировала проблему перехода вплоть до ~2008 (26:30).
Что бы не придумали вместо IPv6, переход на это был бы таким же мучительным.
Я долго думал, как можно прийти к такой мысли и понял, что вы нашли её в "Красной книжечке"... дайте почитать.
"IPv6 to a network engineer is like Communism to a Marxist" - 2013.
Внутри IETF на разборе полётов в 2010 задавались вопросом: Если мы такие умные, почему мы не можем разработать IP-протокол следующего поколения и выработать технически осуществимую стратегию внедрения и сосуществования?
IPv6 - история про амбиции. IETF изначально не мог принять недостаточно амбициозный (достаточно реализуемый) план и это было приправлено деньгами пузыря доткомов. А когда наломал дров, не мог сдать назад. Бесконечный тупик. Да, где-то в ~2045 планируется полный переход на доделанный IPv6, но может получиться как в анекдоте про фальшивые ёлочные игрушки (если интернет в привычном понимании уже кончится).
Itanium иногда считают успехом из-за того, что он потопил конкурентов с их high-end RISC (ну или они сами вовремя умерли). Отменённый IPv6 в альтернативной реальности выглядел бы примерно так же из-за победы над OSI-протоколами (например, федеральная программа GOSIP, 1990-1995).
Вместо IPv6 придумали NAT. Он решал проблему сразу. Но не целиком. Дальше требовалась доработать NAT, чтобы появилась связность между частными адресами (IPv4+4, PR-IP). Но не при живом IPv6.
Там был не только разбор полётов, но и знатный срач. Тыдыщ:
you are one of the main persons behind the failure of IPv6. The living example of the IETF ivory tower
if it was not for your blind opposition to NAT, we could be living in a world of 6to4 implemented in the ubiquitous NAT box
Look what you have done: not only we have more NATv4 than ever, but now we also have NAT46, NAT64, NAT464...whatever and all of these with heavy ALG layers to make it more palatable.
Congratulations.
И ещё много
- Вендоры не хотели добавлять 6to4. - Вендоры устали от систематического торпедирования нами всего, что выглядит как NAT, ходит как NAT и квакает как NAT и постоянных напоминаний, что их продукт - это хлам в пластиковой коробке...
Один говорит, что проблема IPv6 в том, что это IPv4 с лишними битами, а надо было всю систему менять (Noel Chiappa, автор одного кандидата на IPng - Nimrod). Другой говорит, что проблема IPv6 как раз в обратном - мы же в него стремились добавить побольше фич, чтобы использовать шанс.
- Не думаю, что протокол IPv4 был разработан таким образом, чтобы допускать совместимое расширение.
Японец ему про свой PR-IP (про "белые" порты как сущность первого класса с поддержкой в вебе, в DNS, в ARP, которые как бы расширяют адрес почти до 48 бит). И не только ему, всем. Все молчат.
Да? Может быть: 1. Принять IPv6 как его изначально сделал Стив Диринг.
Это может показаться совершенно нелепым предложением... но у IPv4 на самом деле есть Options! (про три предложения из 1992-1994 не вспоминали)
- Отложить вскрытие, пациент ещё живой, хоть и с задержкой в развитии. - Вивисекция!
Я тут понял. План с дуал-стеком 15 лет назад опирался на то, что у всех есть публичный IPv4... а если у всех есть публичный IPv4, то значит их всем хватает... а если их всем хватает, то зачем им IPv6?
- NAT даёт связность там, где её не было. - Нет, NAT лишает связности там, где она была.
- 99% приложений ходят через настроенный NAT, нужен только проброшенный порт. - Существенные нарушения фундаментальных архитектурных принципов IP.
Изначально предполагалось, что IPSEC станет достаточно сильным стимулом для обновления. С тех пор IPSEC был отделён, и мы обнаружили, что безопасность на пакетном уровне далеко не так полезна, как безопасность на транспортном уровне.
>> Вы действительно думаете, что сотрудники IETF (и другие) разработали IPv6 без предварительного тщательного анализа?
> Noel Chiappa: На самом деле, многие в IETF так считают (Это сообщение отправлено вам через NAT-бокс, который я купил в ларьке прямо через улицу. Забавы ради надо было спросить, есть ли у них IPv6...)
Через 5 лет запоёте по-другому. Масштабируемость, QoS, мобильные устройства, веб-устройства прибьют v4 - и UMTS добавит остроты.
"This represents the first time the IETF has seriously and formally examined the possibility of IPv6 not succeeding," says Noel Chiappa, a participant in the July meeting and a former area director for the IETF. "Before we had Plan A - IPv6 - and there was no Plan B. Now we're starting to work on one."
Because IPv6 products were not widely available to solve the Internet address shortage, many network managers deployed NAT devices as a quick fix.
"We were assuming a transition between IPv4 and pure IPv6," Carpenter says
The reasons for this lack of interest in gateways that lose informations and hence are imperfect within the Internet seems to be a drive toward "purity" in the design (Eidnes, 1996). As this purity is likely to be increasingly difficult to maintain in the future, it would be interesting to investigate more closely the role of and attitudes toward gateways within the Internet.
Конфликт "юзер хочет видеть в локалке за файрволом/NAT'ом доверенную зону, а архитектор считает своим долгом уничтожить эту привычку" куда-то в неолит уходит.
TL;DR: затем, что ценность IPv6 в скорости перехода на него, а не в его архитектуре.
Костыльность - вероятно, фундаментальное свойство нашей вселенной. С появления теории относительности картина всё хуже и хуже.
Вокруг нас есть инфраструктурные вещи. Протоколы интернета. Водопровод. Ядро линукса. Их ценность в том, что ими все пользуются и они работают. Сколько костылей в линуксе по сравнению с чистой академической разработкой? Насколько медные трубы круче полипропилена? Каковы недостатки IPv4 по сравнению с IPv6? Ответы: 1) нафиг мне операционка без приложений, 2) третью неделю воды нет!11, 3) да проехали уже, не до того нынче.
исправив известные недостатки
NAT: при подключении к интернету можно сэкономить на "белом" адресе и расплачиваться недоступностью извне во многих ситуациях.
IPv6: при аренде VPS можно сэкономить на IPv4-адресе и расплачиваться недоступностью извне во многих ситуациях.
Ради этого стоило ждать 30 лет. То есть новому протоколу нужен NAT/прокси, чтобы не получилось как с NAT*, но без нового протокола... то есть такие сравнения вообще должны закончиться в конце нулевых.
* а может и на самом деле хуже, потому что
NAT-VPS: при аренде VPS можно сэкономить на "белом" адресе и получить связность лучше IPv6 за счёт "белых" портов.
Всё-таки это безнадёжная история была. Скандалы, интриги, расследования!
Если кратко:
SIPP был в том числе политическим оружием IETF против ISO (и Винтон Серф в этот раз на стороне ISO).
Здесь не до аспектов внедрения, надо застолбить место и убедительно выиграть по фичам.
Ключевые решения приняты в 1992 - до CIDR, до DHCP, до SSL, до NAT и приватных IPv4-диапазонов, до осознания, что фичи IPng портируются обратно в IPv4 (IPsec, DiffServ).
По расширению IPv4 через Options к 1994 было 3 предложения, но с учётом конъюнктуры они бессмысленны (про-ISO'шный конкурент SIPP критиковался как тормоз прогресса, а они тогда - задний ход).
"Победу" CGNAT над IPv6 заметили в прессе в 1999.
Нашёлся RFC, который видел все проблемы IPv6 из 1994 года.
______
SIPP имел одну неочевидную задачу - победить ISO в борьбе за влияние. Правительство США в 1990 запланировало переход на протоколы ISO [pdf, с. 29]. Серф как глава крупного Internet Society (ISOC), связанного с IAB, выступал за замену своего IPv4 на ISO'шный CLNP (TUBA) (близко к IS-IS?) [с. 44].
CLNP предложили на роль IPv7 (7 - фальстарт) летом 1992. И стало ясно, что его надо отстранять, вместе с ISO(совпадение-не-думаю)C ("ISO(silent)C"). Чтобы у IETF было светлое будущее.
Разговоры в 1992:
An argument was advanced against TUBA: its development would not help advance the longer-term research.
IPv7 (CLNP) a mistake First, adopting CLNP means buying into the ISO standards process. we have to face the painful reality that any future changes that the Internet community wishes to see in the network layer will require ISO approval too.
Second, CLNP deals with only *one* of the several issues facing IP, namely address depletion. At the same time, it forces us to take a giant step back on other issues. CLNP does *not* support multicasting.
CLNP as IPv7 seems destined to be a technical step backwards and to place a severe crimp on protocol innovation at a time when we need to innovate
The IAB, in a draft statement issued in June after meeting in Kope, favored TUBA. This raised a storm of hate mail, and the draft statement was retired CLNP addressing plan is bogus, and the CLNP encodings are, to say the list, suboptimal. You are right to mention that we need "another kind of toy"; promising ideas are appearing in the ongoing debate.
Было три серьёзные группы:
одна объединится вокруг SIPP,
другая занимается TUBA,
третья - TP/IX (aka IPv7(другой(их всего 3))) => CATNIP.
CATNIP перенимал ISO'шную адресацию и "CATNIP integrates CLNP, IP, and IPX", так что он тоже неверный.
Сбор требований к новому протоколу в 1993, озвучивание требований в 1994, подведение итогов между тремя протоколами в 1995 - это, видимо, уже декорации для принятия SIPP.
В 1994 сформировалось ещё одно предложение по расширению IPv4 (третье предложение по опциям после EIP и TP/IX (ADDEXT)) - Address Extension by IP Option Usage (AEIOU). И... его не воспринимали как кандидата на IPng сами авторы. Презентовали как штуку на тот случай, если IPng задержится до исчерпания адресов, получили ответ - а зачем нам штука, которая только затруднит переход на IPng.
Капитан ВМС в 1996 в своей магистерской (ADA311814) видел ситуацию так:
SIPP was the proposal that differed least from IPv4, had the most details defined and (most importantly) had the best-thought-out transition plan.
Originally, the IETF thought ISPs would want to move to IPv6 to meet customer demand for new Internet addresses/ However, ISPs have so widely deployed network address translation (NAT) devices ... that they're no hurry to move IPv6".
А в 1994 в IETF шли странные споры о том, зачем вообще нужны частные адреса.
There was a fair amount of spirited debate on RFC 1597, revolving around whether or not it was mandatory, that it was not always applicable if a site would eventually connect to the Internet, etc. Many feel that private addresses are a mistake, while others point out that it is irresponsible to use global address space for numbering hosts that never talk outside their site.
Ранние сомнения в IPng были в RFC1669 в 1994 - там замечают цену, нехватку NAT64, конкуренцию с CGNAT и то, что внедрение отложится до полного исчерпания адресов:
Can IPng compete against IPv4? ... Existing IPv4 users will migrate to IPng for one of three possible reasons:
New functionality not found in IPv4
Reduced costs by using IPng: It is quite unlikely ...
To gain connectivity to otherwise unreachable IPng hosts ... uncertain whether a significant base of IPng sites will be occur prior to IPv4 address depletion
As none of the proposals currently call for dynamic network address translation (NAT), it is inevitable that IPng-only sites will have access to a partial set of IPv4 sites at any given moment.
some sites will have "privately numbered" IPv4 networks and will desire similar Internet services which provide transparent access to the entire Internet
it is not clear that IPng will secure sufficient following to attain market viability compete against IPv4 and the inevitable arrival of network address translation devices
В 1993 на заседании IETF озвучивали, что "The market will resist any IPng that does not just look like a new release of IP. Co-existence, and ease and cost of transition, should be key decision criteria", но в хорошем смысле (не "надо остановиться и задуматься", а "TUBA ещё меньше похожа на IPv4, чем SIPP!"). Дальше: рынок надо направлять, потому что сам он не сможет принять рациональное решение.
Не вижу никаких противоречий с высказыванием Серфа
Интервью с Серфом: адрес зафиксировали в 1973, 128 стран, 24 бита на сеть, 16 миллионов компьютеров на сеть - для эксперимента точно достаточно.
Документы: фиксация адреса откладывается до 1979±1 - уже не эксперимент, а крупный оборонный проект и мотив решения - скорость (не MVP для доработки). 1979 - это уже 100К продаж TRS-80 и статья о том, как военные уплотняют мультимедиа для сетей (7 аудиокодеков).
Где-то здесь ошибка.
Даже если он бы решился выбрать больше, на него бы посмотрели как на дурака: «больше 4 миллиардов дорогущих устройств?».
100К продаж с "starting price of US$600" - перспективы можно углядеть (IBM сразу углядела, до IBM PC два года).
А если на два года в прошлое (1977), то там Xerox в своём протоколе расширяет адрес до 32+48 бит (MAC-адрес). Xerox тоже что-то знал.
Никто тогда не мог составить точный прогноз. Как результат, при разработке IPv6 выкинули всё ненужное.
Это инфраструктура (вроде водопровода), тут всё-таки не важно, насколько приятно выкидывать легаси и переписывать с нуля.
Переменная длина заголовка пакета кстати тоже создаёт некоторый геморрой при обработке. В IPv6 это учли.
В IPv4+4 - тоже. Если бы продавливали решение через Options, то пакет с extra-addr-option тоже был бы фиксированной длины. Если бы совсем отбросили амбиции и попытались набирать ~14 бит через запрет фрагментации, то одинаковой длины с IPv4.
Обеспечение адресами IPv6 тех, кому не предоставляется нативный IPv6 адрес
Так речь о том, чтобы автоматически наделить владельца белого IPv4 адресами нового протокола (~2^(14..32) штук).
Средства для взаимодействия между IPv4 и IPv6. По сути это просто разновидности NAT.
В перечисленных мной вариантах это должен быть обычный NAT. И как можно было принять 464XLAT через ~15 лет после IPv6? ("Сворачивать с пути поздно, но это не мешает признавать неудачу и делать выводы")
Для других протоколов получилось примерно бы тоже самое.
То есть совсем другое.
заставить работать с помощью костыля
IPv6 - сам по себе костыль, только в особом смысле - костыль из башни слоновой кости с синдромом второй системы. Он должен был дать адреса и смотреться выгоднее CGNAT'а в нулевых. Сверх этого можно давать фичи, но давать их вместо - нельзя.
Ещё из RFC1726: "4.1 Архитектурная простота. Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать". Отлично подходит к IPv6.
Они промахивались насчёт IPsec, насчёт лёгкости миграции с IPv4, насчёт связности, возведённой в абсолют, потому что из начала 90-х было трудно предсказать ситуацию через 10-20 лет - и не надо было этого делать. Надо было в соответствии с цитатой отсекать всё, что помешает полному переходу через 15 лет.
Тот же IPv4 по сути протокол лабораторный. Он не был предназначен для коммерческого использования.
Сам руководитель разработки Винт Серф признавался, что он делал протокол чисто для проверки концепций.
Банально, руководителю проекта в голову не могли прийти
Их хватило бы на все мыслимые и немыслимые эксперименты в то время.
Ага, а параллельно существует совсем другая история для взрослых, в которой за 1-2 года:
зафиксировали длину IPv4-адреса ради скорости
за кучу денег пересадили на протокол всю военку, это будет MIL-STD-1777
в журнале "Вестник компьютеризации" Computerworld пишут о годноте для бизнеса, за ваши налоги, без вендор-лока IBM, скоро в широком доступе
Собственно, история
Середина 1978: в IPv4 ещё адрес переменной длины, на месте контрольной суммы стоят длины адресов.
Конец 1979: "Vint ... cited the performance of the system as a key issue" - пора фиксировать длину адреса.
"Rosenthal recalls: ... Vint Cerf and company went off to invent TCP at the time because they got lots of DOD money to make networks work"
"Throughout 1979, Kahn and Cerf lobbied the DOD to make TCP/IP an official communication protocol standard"
"in December 1980, the DOD publicly unveiled TCP/IP"
Computerworld 1981: "May 15 ... plans to market TCP/IP as part of its VAX/VMS network software package for DEC" и пересказ остального: "на ваши налоги сделали протокол (военный стандарт) - как у IBM, только лучше и без вендор-лока, его уже тестируют на процессорах IBM, DEC, Honeywell, CDC, HP и PerkinElmer. В следующем году он будет широко доступен коммерческим пользователям".
а в протокол была заложена расширяемость (ну вдруг кто-то зачешется), спецификация требует: "each internet module must be able to parse every option [options = блок переменной длины в конце заголовка]"
IPv6 же изначально создавался для коммерческого использования.
Ещё одна былина.
"Самолёт может взлететь с авиносца А и сесть на авианосец Бэ" - Технические критерии по выбору IP нового поколения, 1994.
Он создавался как IPv4 - для всех, и для особого клиента в том числе - для родной военки.
И как раз в нём были исправлены косяки IPv4.
Присмотритесь:
из коммента выше
Перед новогодними праздниками (декабрь 1994, RFC1726): нужен протокол с безупречным планом миграции. После новогодних праздников (январь 1995, RFC1752): подписываем протокол без плана миграции, единственный из трёх.
Что последовало за этим дальновидным решением? Wikipedia / List of IPv6 transition mechanisms
Stateless IP/ICMP Translation
Tunnel broker
6rd
Transport Relay Translation
NAT64
DNS64
ISATAP
464XLAT /2013? всего на 18 лет опоздал, ну ничего/
Dual-Stack Lite (DS-Lite)
V4-via-v6 routing
MAP
4rd
NAT-PT
NAPT-PT
Это у нас архитектура, понимать надо.
Может, фильм снимем, где IETF в ушанках с балалайками и водкой заседает?
Ну, а IPv6 сейчас вполне себе жив.
Я повторюсь, он должен быть не жив, а внедрён 15 лет назад. Так в RFC написано, в предновогоднем. Там в 2010 году видят возможность для внедрения следующего протокола. Не консервативную, но и не раннюю, а в самый раз. Как раз к 1995 прошло ~15 лет после утверждения IPv4, а это ещё 15 лет.
Инженерам, которые разрабатывали IPv6, это не удалось, поэтому они решили, что раз уж ломают совместимость, поэтому сразу будут менять то, что плохо работало.
Обсуждение IPv6 всегда в эту демагогию уходит. IPv6 должен был к нулевым успешно конкурировать с провайдерским NAT. Он не смог. Значит, он неудачен, инженеры ошиблись, остальное не принципиально. Сворачивать с пути поздно, но это не мешает признавать неудачу и делать выводы.
Период между принятием и предполагаемым завершением внедрения (50 лет, 1995-2045) у IPv6 как у ITER, но там чистая наука и даже внезапное закрытие проекта почти никого не затронет.
Да, совместимость не сохранить целиком, но каждое лишнее расхождение имеет цену в годах. Одно решение - плюс пять лет, другое решение - ещё плюс пять лет, так отведённые на внедрение ~15 лет и кончатся (начало 90-х - конец нулевых).
two type A records can be used to store the level 1 and level 2 parts of the 4+4 address. For example, the level 1 and 2 parts of the IPv4+4 address of the machine foo.bar.edu are stored under _l1.foo.bar.edu and _l2.foo.bar.edu. Auxiliary protocols, such as DHCP, ARP, RARP, router discovery, etc., need not be modified. IPv4+4 packets are minimally encapsulated IP packets The first three rows of fields in the IPv4+4 header are interpreted in the same manner as the IPv4 header, with the exception that the Protocol 1 field is set to a value that specifies IPv4+4 encapsulation. Upgraded NATs, called realm gateways, are integral part of the 4+4 architecture. If routers are also upgraded in an area, the special role of the realm gateways diminishes and they simply reduce to ordinary routers. There is no need for temporary transition mechanisms (such as tunneling, tunnel brokers, 6to4, 6over4 or DSTM
Поздно? Но она не на пустом месте появилась, она опиралась на предыдущие наработки. Предыдущие наработки отвергли? Ну, это была работа IETF - выбрать верное направление. Была слишком неясная ситуация? Объявить вотум недоверия всем предложениям - это тоже решение, можно потерять 5 лет, а потом сэкономить 30. Учесть неясность и уменьшить горизонт планирования - тоже решение (не пытаться предсказать будущие потребности сверх расширения адресов).
И если мы ее ломаем, то почему сразу не сделать лучше чем есть сейчас?
Потому что вопрос подразумевает академический успех и закрывает глаза на скорость внедрения.
Протокол пытались улучшить в академическом смысле, а на практике то был план, в котором бизнес оплатит издержки за неимением выбора. При создании IPv6 не допускали, что ему придётся конкурировать с NAT-на-IPv4. Поэтому казалось, что нет разницы, насколько ломать совместимость: в любом случае ломаем => надо пользоваться моментом => а добавим ещё вот это...
Любой другой протокол будет несовместим с IPv4, его просто нельзя нормально расширить. Считаете, когда проектировали IPv6, об этом не задумывались?
Конечно нет, тогда было слишком унизительно думать о расширении IPv4 "хоть тушкой, хоть чучелом". А теперь слишком унизительно вспоминать об этой возможности.
Почитайте, как процесс происходил.
В конце 1994 опубликовали RFC1726 Technical Criteria for Choosing IP The Next Generation (IPng). В нём начали с того, что
If we can't transition to the new protocol, then no matter how wonderful it is, we'll never get to it.
А продолжили тем, что нужны фичи. Нужно много фич. И нам тут из минобороны позвонили... у них вертолёты на кораблях. Да, тоже нужно - не обсуждается.
Naval surface combatants carry some aircraft (at a minimum, a helicopter or two) (the ships that move around) the ships carrying the aircraft each aircraft has its own network must be mobile internetworks There is also the requirement for dynamic mobility; a plane might take off from aircraft carrier A and land on carrier B These requirements are not limited to just the navy
Через месяц подвели итоги в RFC1752 - отбор прошли 3 протокола и, как ни странно, они все сложные.
На роль IPv6 выбрали SIPP
The biggest problem the reviewers had with SIPP was with IPAE, SIPP's transition plan. The overwhelming feeling was that IPAE [IP Address Encapsulation] is fatally flawed and could not be made to work reliably in an operational Internet.
____
Надо было начать с расширения IPv4 вправо. Это, конечно, приятно, когда органу есть что распределять, но проще автоматически сделать владельца одного IPv4 владельцем 2^(8/16/32) IPng-адресов. Владельцем обычно будет провайдер, использующий IPv4-адрес под CGNAT.
2^8, если переиспользовать поле Identification при форсировании Don't Fragment - недостаточно из-за неравномерного распределения адресов (мало IPv4 у стран Азии). Ещё 6 бит, если получится задействовать Fragment Offset.
2^16+, если заставить железо поддерживать IPv4 Options либо навсегда инкапсулировать новый заголовок (с расширенной частью адреса) в IPv4.
В этом направлении думали в EIP (1992), IPv4+4 (2002), xIP (2009), EnIP, IP45.
недавно биологи из СПбГУ открыли что художники рисуют не реальных животных, а их стилизацию под реальных
В науке всегда такое можно отыскать. Скажем, зонная теория слуха Гарбузова из 1940-х опиралась на предположение о бесконечной точности слуха. Потому что без этого чучела не хватит новизны и не получится преподносить известное как новую теорию.
не стал бы покупать овердорогой серверный Итаниум, чтобы получить производительность второго пня образца 1998
Да кто их знает, они же всё-таки купили Itanium, который изначально не впечатлял. Хотел добавить, что итаник сразу понимал SSE2, но... это ухудшало производительность, а не улучшало (обзор из начала 2001).
ixbt в 2005 тестировал Itanium2 1.3GHz/3MB. Говорит, что до третьего пня падало.
* "на уровне 2,8 ГГц процессора" ** "соответствует Pentium III 700/450 МГц" *** "примерно уровень Pentium 4 1,7 ГГц"
____ Вообще, не факт, что между аппаратным слоем совместимости и программным "IA-32 EL" из ~2004 было что-то ещё. HP'шный "overview" из 2002 мог врать.
ты точно знаешь, что, как и где можно соптимизировать знаешь, что процессор на это закономерно откликнется и покажет рост производительности
Гхм, с конца 1990-х к процессорам сбоку прикручивают SIMD-расширения, чтобы предсказуемо дробить числа - и где разница?
А там где высокоуровневая бизнес-логика с её нехорошей индирекцией, ветвлениями и промахами кэша - там на одном железе всё равно будет медленно, а в другом - всё равно быстро.
Не, аппаратной совместимостью Intel хвалится в даташите и на 1 поколение (которое "800 MHz and 733 MHz"). Эмуляция в винде там тоже должна быть, потому что про неё Microsoft в августе 2001 пишет(за год до второго итаника).
Скорее уж в Itanium 2 ничего не меняли в этом аспекте.
Из "overview of the new Itanium 2-based hp servers rx2600..."
_____
Не порядок, что бенчмарков последних итаников так и не появилось. Itanium 9500/9700.
Причём первые 2 макроса обычно не нужно было писать самому - достаточно было подключить стандартный хидер из avr-libc, написав #include <avr/io.h>
Их туда добавили, когда компилятор не распознавал идиому над "IO-доступными" адресами, и потом задепрекейтили в 2005 со словами
Cообщество AVR-GCC теперь единственное известное мне сообщество C-программистов, работающих непосредственно с железом, которое до сих пор не поняло, как работают побитовые операции в C. В списках рассылки FreeBSD я никогда не видел запросов на макрос, который заменял бы |= и &=~. [и дальше про то, что если писать макрос для себя, то сразу LED_ON и LED_OFF]
Например? Что интересного он пропустил?
Ритчи-88 говорил, что если что - люди как-нибудь выживут. Это перекликается с определением некоторых UB флагами компилятора (strict aliasing, знаковое переполнение).
Ритчи-93 сказал, что стандарт вышел неплохой.
Ритчи-00 считал, что вклад нового стандарта уступает прежнему, но тоже ничего. Слишком много фич.
Ритчи-00 овладевала индифферентность - он называл "вероятно полезной" вещь, которую Ритчи-88 запретил даже переизобретать (
noaliasиз черновика C89 =>restrictиз C99).Абсолютную полезность измерять не хочется, но эту общую идею вроде до оскомины 30 лет назад повторяли.
Совещание в 1993:
Вот это "If we can't transition to the new protocol, then no matter how wonderful it is" из RFC1726 (1994).
"We were assuming a transition between IPv4 and pure IPv6" журналу в 1999 под спойлером в комменте выше.
_____
И мне кажется, или план IETF опирался на одну очень крупную идею, которая не сбылась из-за затянутого перехода?
Интернет переходит на чистый IPv6
=> не надо больше маршрутизировать IPv4 между AS
=> большая ожидаемая выгода (цена TCAM-памяти?), потому что IPv4 фрагментированно распределялся мелкими блоками ("IPv4 swamp")
=> ради возможности "дефрагментации" отказались от расширения IPv4 вправо через Options или инкапсуляцию доп. заголовка как в IPv4+4 (был шанс избежать изменений в BGP, автоматически сделать каждого владельца IPv4 владельцем ~2^24 IPv4+4, уменьшить число технологий перехода...).
Была ли такая жертва во имя маршрутизации-в-мире-без-IPv4?
Так вы на предпосылку своего вопроса посмотрите - "одинаковая мучительность перехода на любой IPng следует из необходимости обновления сетевого стека ОС и оконечного оборудования". Она очевидно ложная, потому что сетевой стек и оконечное оборудование давно обновлены под IPv6.
А выступление вы подозрительно обрезали, там всего одного предложения не хватает: "...and the decision was trying to upgrade V4 is as hard as trying to roll out V6, we'll just roll out V6. This is a in-te-res-ti-ng design decision that was made in 1994". Там не говорится, что решение (и понимание проблемы) было верное. Говорится, что оно ин-те-рес-ное и нам в этом интересном мире теперь жить (reality of life, suck it up). И дальше, что IETF игнорировала проблему перехода вплоть до ~2008 (26:30).
Я долго думал, как можно прийти к такой мысли и понял, что вы нашли её в "Красной книжечке"... дайте почитать.
"IPv6 to a network engineer is like Communism to a Marxist" - 2013.
Внутри IETF на разборе полётов в 2010 задавались вопросом: Если мы такие умные, почему мы не можем разработать IP-протокол следующего поколения и выработать технически осуществимую стратегию внедрения и сосуществования?
IPv6 - история про амбиции. IETF изначально не мог принять недостаточно амбициозный (достаточно реализуемый) план и это было приправлено деньгами пузыря доткомов. А когда наломал дров, не мог сдать назад. Бесконечный тупик. Да, где-то в ~2045 планируется полный переход на доделанный IPv6, но может получиться как в анекдоте про фальшивые ёлочные игрушки (если интернет в привычном понимании уже кончится).
Itanium иногда считают успехом из-за того, что он потопил конкурентов с их high-end RISC (ну или они сами вовремя умерли). Отменённый IPv6 в альтернативной реальности выглядел бы примерно так же из-за победы над OSI-протоколами (например, федеральная программа GOSIP, 1990-1995).
Вместо IPv6 придумали NAT. Он решал проблему сразу. Но не целиком. Дальше требовалась доработать NAT, чтобы появилась связность между частными адресами (IPv4+4, PR-IP). Но не при живом IPv6.
Там был не только разбор полётов, но и знатный срач. Тыдыщ:
И ещё много
- Вендоры не хотели добавлять 6to4.
- Вендоры устали от систематического торпедирования нами всего, что выглядит как NAT, ходит как NAT и квакает как NAT и постоянных напоминаний, что их продукт - это хлам в пластиковой коробке...
Один говорит, что проблема IPv6 в том, что это IPv4 с лишними битами, а надо было всю систему менять (Noel Chiappa, автор одного кандидата на IPng - Nimrod). Другой говорит, что проблема IPv6 как раз в обратном - мы же в него стремились добавить побольше фич, чтобы использовать шанс.
- Не думаю, что протокол IPv4 был разработан таким образом, чтобы допускать совместимое расширение.
Японец ему про свой PR-IP (про "белые" порты как сущность первого класса с поддержкой в вебе, в DNS, в ARP, которые как бы расширяют адрес почти до 48 бит). И не только ему, всем. Все молчат.
Да? Может быть: 1. Принять IPv6 как его изначально сделал Стив Диринг.
Это может показаться совершенно нелепым предложением... но у IPv4 на самом деле есть Options! (про три предложения из 1992-1994 не вспоминали)
- Отложить вскрытие, пациент ещё живой, хоть и с задержкой в развитии.
- Вивисекция!
Я тут понял. План с дуал-стеком 15 лет назад опирался на то, что у всех есть публичный IPv4... а если у всех есть публичный IPv4, то значит их всем хватает... а если их всем хватает, то зачем им IPv6?
- NAT даёт связность там, где её не было.
- Нет, NAT лишает связности там, где она была.
- 99% приложений ходят через настроенный NAT, нужен только проброшенный порт.
- Существенные нарушения фундаментальных архитектурных принципов IP.
_______
2001:
В журнале в 1999:
В статье в 1998:
Конфликт "юзер хочет видеть в локалке за файрволом/NAT'ом доверенную зону, а архитектор считает своим долгом уничтожить эту привычку" куда-то в неолит уходит.
TL;DR: затем, что ценность IPv6 в скорости перехода на него, а не в его архитектуре.
Костыльность - вероятно, фундаментальное свойство нашей вселенной. С появления теории относительности картина всё хуже и хуже.
Вокруг нас есть инфраструктурные вещи. Протоколы интернета. Водопровод. Ядро линукса. Их ценность в том, что ими все пользуются и они работают. Сколько костылей в линуксе по сравнению с чистой академической разработкой? Насколько медные трубы круче полипропилена? Каковы недостатки IPv4 по сравнению с IPv6? Ответы: 1) нафиг мне операционка без приложений, 2) третью неделю воды нет!11, 3) да проехали уже, не до того нынче.
NAT: при подключении к интернету можно сэкономить на "белом" адресе и расплачиваться недоступностью извне во многих ситуациях.
IPv6: при аренде VPS можно сэкономить на IPv4-адресе и расплачиваться недоступностью извне во многих ситуациях.
Ради этого стоило ждать 30 лет. То есть новому протоколу нужен NAT/прокси, чтобы не получилось как с NAT*, но без нового протокола... то есть такие сравнения вообще должны закончиться в конце нулевых.
* а может и на самом деле хуже, потому что
NAT-VPS: при аренде VPS можно сэкономить на "белом" адресе и получить связность лучше IPv6 за счёт "белых" портов.
Всё-таки это безнадёжная история была. Скандалы, интриги, расследования!
Если кратко:
SIPP был в том числе политическим оружием IETF против ISO (и Винтон Серф в этот раз на стороне ISO).
Здесь не до аспектов внедрения, надо застолбить место и убедительно выиграть по фичам.
Ключевые решения приняты в 1992 - до CIDR, до DHCP, до SSL, до NAT и приватных IPv4-диапазонов, до осознания, что фичи IPng портируются обратно в IPv4 (IPsec, DiffServ).
По расширению IPv4 через Options к 1994 было 3 предложения, но с учётом конъюнктуры они бессмысленны (про-ISO'шный конкурент SIPP критиковался как тормоз прогресса, а они тогда - задний ход).
"Победу" CGNAT над IPv6 заметили в прессе в 1999.
Нашёлся RFC, который видел все проблемы IPv6 из 1994 года.
______
SIPP имел одну неочевидную задачу - победить ISO в борьбе за влияние. Правительство США в 1990 запланировало переход на протоколы ISO [pdf, с. 29]. Серф как глава крупного Internet Society (ISOC), связанного с IAB, выступал за замену своего IPv4 на ISO'шный CLNP (TUBA) (близко к IS-IS?) [с. 44].
CLNP предложили на роль IPv7 (7 - фальстарт) летом 1992. И стало ясно, что его надо отстранять, вместе с ISO(совпадение-не-думаю)C ("ISO(silent)C"). Чтобы у IETF было светлое будущее.
Разговоры в 1992:
Было три серьёзные группы:
одна объединится вокруг SIPP,
другая занимается TUBA,
третья - TP/IX (aka IPv7(другой(их всего 3))) => CATNIP.
CATNIP перенимал ISO'шную адресацию и "CATNIP integrates CLNP, IP, and IPX", так что он тоже неверный.
Сбор требований к новому протоколу в 1993, озвучивание требований в 1994, подведение итогов между тремя протоколами в 1995 - это, видимо, уже декорации для принятия SIPP.
В 1994 сформировалось ещё одно предложение по расширению IPv4 (третье предложение по опциям после EIP и TP/IX (ADDEXT)) - Address Extension by IP Option Usage (AEIOU). И... его не воспринимали как кандидата на IPng сами авторы. Презентовали как штуку на тот случай, если IPng задержится до исчерпания адресов, получили ответ - а зачем нам штука, которая только затруднит переход на IPng.
Капитан ВМС в 1996 в своей магистерской (ADA311814) видел ситуацию так:
В 1999 в Network World замечают, что
А в 1994 в IETF шли странные споры о том, зачем вообще нужны частные адреса.
Ранние сомнения в IPng были в RFC1669 в 1994 - там замечают цену, нехватку NAT64, конкуренцию с CGNAT и то, что внедрение отложится до полного исчерпания адресов:
Can IPng compete against IPv4? ... Existing IPv4 users will migrate to IPng for one of three possible reasons:
New functionality not found in IPv4
Reduced costs by using IPng: It is quite unlikely ...
To gain connectivity to otherwise unreachable IPng hosts ... uncertain whether a significant base of IPng sites will be occur prior to IPv4 address depletion
As none of the proposals currently call for dynamic network address translation (NAT), it is inevitable that IPng-only sites will have access to a partial set of IPv4 sites at any given moment.
some sites will have "privately numbered" IPv4 networks and will desire similar Internet services which provide transparent access to the entire Internet
it is not clear that IPng will secure sufficient following to attain market viability compete against IPv4 and the inevitable arrival of network address translation devices
В 1993 на заседании IETF озвучивали, что "The market will resist any IPng that does not just look like a new release of IP. Co-existence, and ease and cost of transition, should be key decision criteria", но в хорошем смысле (не "надо остановиться и задуматься", а "TUBA ещё меньше похожа на IPv4, чем SIPP!"). Дальше: рынок надо направлять, потому что сам он не сможет принять рациональное решение.
Интервью с Серфом: адрес зафиксировали в 1973, 128 стран, 24 бита на сеть, 16 миллионов компьютеров на сеть - для эксперимента точно достаточно.
Документы: фиксация адреса откладывается до 1979±1 - уже не эксперимент, а крупный оборонный проект и мотив решения - скорость (не MVP для доработки). 1979 - это уже 100К продаж TRS-80 и статья о том, как военные уплотняют мультимедиа для сетей (7 аудиокодеков).
Где-то здесь ошибка.
100К продаж с "starting price of US$600" - перспективы можно углядеть (IBM сразу углядела, до IBM PC два года).
А если на два года в прошлое (1977), то там Xerox в своём протоколе расширяет адрес до 32+48 бит (MAC-адрес). Xerox тоже что-то знал.
Это инфраструктура (вроде водопровода), тут всё-таки не важно, насколько приятно выкидывать легаси и переписывать с нуля.
В IPv4+4 - тоже. Если бы продавливали решение через Options, то пакет с extra-addr-option тоже был бы фиксированной длины. Если бы совсем отбросили амбиции и попытались набирать ~14 бит через запрет фрагментации, то одинаковой длины с IPv4.
Так речь о том, чтобы автоматически наделить владельца белого IPv4 адресами нового протокола (~2^(14..32) штук).
В перечисленных мной вариантах это должен быть обычный NAT. И как можно было принять 464XLAT через ~15 лет после IPv6? ("Сворачивать с пути поздно, но это не мешает признавать неудачу и делать выводы")
То есть совсем другое.
IPv6 - сам по себе костыль, только в особом смысле - костыль из башни слоновой кости с синдромом второй системы. Он должен был дать адреса и смотреться выгоднее CGNAT'а в нулевых. Сверх этого можно давать фичи, но давать их вместо - нельзя.
Ещё из RFC1726: "4.1 Архитектурная простота. Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать". Отлично подходит к IPv6.
Они промахивались насчёт IPsec, насчёт лёгкости миграции с IPv4, насчёт связности, возведённой в абсолют, потому что из начала 90-х было трудно предсказать ситуацию через 10-20 лет - и не надо было этого делать. Надо было в соответствии с цитатой отсекать всё, что помешает полному переходу через 15 лет.
Ага, а параллельно существует совсем другая история для взрослых, в которой за 1-2 года:
зафиксировали длину IPv4-адреса ради скорости
за кучу денег пересадили на протокол всю военку, это будет MIL-STD-1777
в журнале
"Вестник компьютеризации"Computerworld пишут о годноте для бизнеса, за ваши налоги, без вендор-лока IBM, скоро в широком доступеСобственно, история
Середина 1978: в IPv4 ещё адрес переменной длины, на месте контрольной суммы стоят длины адресов.
Конец 1979: "Vint ... cited the performance of the system as a key issue" - пора фиксировать длину адреса.
"Rosenthal recalls: ... Vint Cerf and company went off to invent TCP at the time because they got lots of DOD money to make networks work"
"Throughout 1979, Kahn and Cerf lobbied the DOD to make TCP/IP an official communication protocol standard"
"in December 1980, the DOD publicly unveiled TCP/IP"
Computerworld 1981: "May 15 ... plans to market TCP/IP as part of its VAX/VMS network software package for DEC" и пересказ остального: "на ваши налоги сделали протокол (военный стандарт) - как у IBM, только лучше и без вендор-лока, его уже тестируют на процессорах IBM, DEC, Honeywell, CDC, HP и PerkinElmer. В следующем году он будет широко доступен коммерческим пользователям".
а в протокол была заложена расширяемость (ну вдруг кто-то зачешется), спецификация требует: "each internet module must be able to parse every option [options = блок переменной длины в конце заголовка]"
Ещё одна былина.
"Самолёт может взлететь с авиносца А и сесть на авианосец Бэ" - Технические критерии по выбору IP нового поколения, 1994.
Он создавался как IPv4 - для всех, и для особого клиента в том числе - для родной военки.
Присмотритесь:
Перед новогодними праздниками (декабрь 1994, RFC1726): нужен протокол с безупречным планом миграции.
После новогодних праздников (январь 1995, RFC1752): подписываем протокол без плана миграции, единственный из трёх.
Что последовало за этим дальновидным решением?
Wikipedia / List of IPv6 transition mechanisms
Stateless IP/ICMP Translation
Tunnel broker
6rd
Transport Relay Translation
NAT64
DNS64
ISATAP
464XLAT /2013? всего на 18 лет опоздал, ну ничего/
Dual-Stack Lite (DS-Lite)
V4-via-v6 routing
MAP
4rd
NAT-PT
NAPT-PT
Это у нас архитектура, понимать надо.
Может, фильм снимем, где IETF в ушанках с балалайками и водкой заседает?
Я повторюсь, он должен быть не жив, а внедрён 15 лет назад. Так в RFC написано, в предновогоднем. Там в 2010 году видят возможность для внедрения следующего протокола. Не консервативную, но и не раннюю, а в самый раз. Как раз к 1995 прошло ~15 лет после утверждения IPv4, а это ещё 15 лет.
Обсуждение IPv6 всегда в эту демагогию уходит. IPv6 должен был к нулевым успешно конкурировать с провайдерским NAT. Он не смог. Значит, он неудачен, инженеры ошиблись, остальное не принципиально. Сворачивать с пути поздно, но это не мешает признавать неудачу и делать выводы.
Период между принятием и предполагаемым завершением внедрения (50 лет, 1995-2045) у IPv6 как у ITER, но там чистая наука и даже внезапное закрытие проекта почти никого не затронет.
Да, совместимость не сохранить целиком, но каждое лишнее расхождение имеет цену в годах. Одно решение - плюс пять лет, другое решение - ещё плюс пять лет, так отведённые на внедрение ~15 лет и кончатся (начало 90-х - конец нулевых).
Есть такая штука из 2002: IPv4+4:
Поздно? Но она не на пустом месте появилась, она опиралась на предыдущие наработки.
Предыдущие наработки отвергли? Ну, это была работа IETF - выбрать верное направление.
Была слишком неясная ситуация? Объявить вотум недоверия всем предложениям - это тоже решение, можно потерять 5 лет, а потом сэкономить 30. Учесть неясность и уменьшить горизонт планирования - тоже решение (не пытаться предсказать будущие потребности сверх расширения адресов).
Не тот слайд, там цены на оперативку!
По-моему, вокруг нас хватает замедляющихся экспонент. В основном в железе, но ещё в ~2000 с лёгкой руки бросили, что
А после проверки получилось, скорее, так:
Потому что вопрос подразумевает академический успех и закрывает глаза на скорость внедрения.
Протокол пытались улучшить в академическом смысле, а на практике то был план, в котором бизнес оплатит издержки за неимением выбора. При создании IPv6 не допускали, что ему придётся конкурировать с NAT-на-IPv4. Поэтому казалось, что нет разницы, насколько ломать совместимость: в любом случае ломаем => надо пользоваться моментом => а добавим ещё вот это...
Более длинный коммент рядом.
Конечно нет, тогда было слишком унизительно думать о расширении IPv4 "хоть тушкой, хоть чучелом". А теперь слишком унизительно вспоминать об этой возможности.
Почитайте, как процесс происходил.
В конце 1994 опубликовали RFC1726 Technical Criteria for Choosing IP The Next Generation (IPng). В нём начали с того, что
А продолжили тем, что нужны фичи. Нужно много фич. И нам тут из минобороны позвонили... у них вертолёты на кораблях. Да, тоже нужно - не обсуждается.
Через месяц подвели итоги в RFC1752 - отбор прошли 3 протокола и, как ни странно, они все сложные.
____
Надо было начать с расширения IPv4 вправо. Это, конечно, приятно, когда органу есть что распределять, но проще автоматически сделать владельца одного IPv4 владельцем 2^(8/16/32) IPng-адресов. Владельцем обычно будет провайдер, использующий IPv4-адрес под CGNAT.
2^8, если переиспользовать поле Identification при форсировании Don't Fragment - недостаточно из-за неравномерного распределения адресов (мало IPv4 у стран Азии). Ещё 6 бит, если получится задействовать Fragment Offset.
2^16+, если заставить железо поддерживать IPv4 Options либо навсегда инкапсулировать новый заголовок (с расширенной частью адреса) в IPv4.
В этом направлении думали в EIP (1992), IPv4+4 (2002), xIP (2009), EnIP, IP45.
Почему не так?
2030 - 1972 [создание Си] = 58 лет.
2012 [создание Rust] + 58 = 2070 год - время перехода на убийцу раста.
Ещё добавить коэффициент, учитывающий замедление относительно разных муроподобных законов, и "ещё чего - нейронку на новый язык тренировать".
В науке всегда такое можно отыскать. Скажем, зонная теория слуха Гарбузова из 1940-х опиралась на предположение о бесконечной точности слуха. Потому что без этого чучела не хватит новизны и не получится преподносить известное как новую теорию.
Дольше СССР, однако.
Да кто их знает, они же всё-таки купили Itanium, который изначально не впечатлял. Хотел добавить, что итаник сразу понимал SSE2, но... это ухудшало производительность, а не улучшало (обзор из начала 2001).
ixbt в 2005 тестировал Itanium2 1.3GHz/3MB. Говорит, что до третьего пня падало.
SPEC CPU2000
SPECint/fp_base2000: 1017*/1979 (IA-64)
SPECint/fp_base2000: 306/170 (-70%/-91%) (HW IA-32)**
SPECint/fp_base2000: 569/530 (-44%/-73%) (SW IA-32)***
* "на уровне 2,8 ГГц процессора"
** "соответствует Pentium III 700/450 МГц"
*** "примерно уровень Pentium 4 1,7 ГГц"
____
Вообще, не факт, что между аппаратным слоем совместимости и программным "IA-32 EL" из ~2004 было что-то ещё. HP'шный "overview" из 2002 мог врать.
Гхм, с конца 1990-х к процессорам сбоку прикручивают SIMD-расширения, чтобы предсказуемо дробить числа - и где разница?
А там где высокоуровневая бизнес-логика с её нехорошей индирекцией, ветвлениями и промахами кэша - там на одном железе всё равно будет медленно, а в другом - всё равно быстро.
Не, аппаратной совместимостью Intel хвалится в даташите и на 1 поколение (которое "800 MHz and 733 MHz"). Эмуляция в винде там тоже должна быть, потому что про неё Microsoft в августе 2001 пишет (за год до второго итаника).
Скорее уж в Itanium 2 ничего не меняли в этом аспекте.
_____
Не порядок, что бенчмарков последних итаников так и не появилось. Itanium 9500/9700.
"A key feature of the Itanium architecture is IA-32 instruction set compatibility" - Intel Itanium Architecture Software Developer’s Manual.
Их туда добавили, когда компилятор не распознавал идиому над "IO-доступными" адресами, и потом задепрекейтили в 2005 со словами