В ноябре прошлого года я впервые поехал на встречу IETF. IETF — это интересное место: кажется, что на треть оно состоит из тяжелой сопроводительной работы, на треть из расширения уже созданных вещей, а на треть — из безумных, далеких от реальности иследований (в этом месте Avery употребил словосочетание «blue sky insanity», образованное им от выражения blue skies research — прим. перев.). Я принимал участие в основном потому, что хотел посмотреть, как люди отреагируют на TCP BBR, который был впервые представлен. (Ответ: по большей части положительно, но с недоверием. Он казался слишком хорошим, чтобы оправдать надежды.)
Как бы то ни было, встречи IETF состоят в том числе из множества презентаций об IPv6, который должен был прийти на смену протоколу IPv4, составляющему основу интернета. (Кое-кто сказал бы, что замена уже идёт; некоторые — что она уже произошла.) Помимо этих презентаций про IPv6, присутствует большое количество людей, считающих его лучшим, величайшим из всего, и они уверены, что он вот-вот наконец придёт (В Любой Момент), а IPv4 — это просто большая куча хаков, которой предначертано умереть, чтобы интернет снова стал красивым.
Я думал, что представится хорошая возможность попробовать на самом деле выяснить, что происходит. Почему IPv6 представляет из себя настолько запутанный бардак по сравнению с IPv4? Не было ли лучше, если бы это был просто IPv4 с увеличенным количеством бит в адресе? Но нет, ради всего святого, всё сделано не так. Поэтому я начал расспрашивать всех вокруг, и вот что я узнал.
Шины разрушили всё
Давным-давно жила-была телефонная сеть, которая использовала физическое переключение цепей. В сущности, это означало перемещение соединителей таким образом, что ваш телефон буквально оказывался подключен очень длинным проводом (уровень 1 OSI). А «выделенная линия» была тем самым длинным проводом, который вы брали у телефонной компании в аренду. Вы клали биты с одной стороны в этот провод, а из другого его конца они выходили спустя фиксированный промежуток времени. Вам не нужны были адреса, потому что на каждом конце была только одна машина.
Однажды телефонные компании всё это немного оптимизировали. Появились мультиплексирование с разделением по времени (TDM) и «виртуальное переключение каналов». Телефонные компании могли прозрачно брать биты на низкой скорости от многих линий, группировать их вместе при помощи мультиплексоров и демультиплексоров, и пускать их по телефонной системе, используя меньше проводов, чем раньше. Чтобы это работало, требовалось больше работы чем раньше, но пока для нас, пользователей модемов, всё было по-прежнему: кладём биты в один конец, они вылезают из другого. Никаких адресов не нужно.
Интернет (тогда так ещё не называвшийся) был построен поверх этих каналов. У вас была связка проводов, в которые можно засовывать биты и ловить с другой стороны. Если у одного компьютера два или три сетевых интерфейса, то он может, если его правильно проинструктировать, пересылать биты с одной линии на другую, а вы можете сделать что-нибудь гораздо более эффективное, чем отдельные линии связи между каждой парой компьютеров. И так появились IP адреса («уровень 3»), подсети и маршрутизация. Даже тогда, с этими каналами точка-точка, вам не нужны были MAC-адреса, потому что как только пакет оказывался в проводе, было только одно место, откуда он мог выйти. Вам нужны были IP адреса только для того, чтобы решить, куда он должен направиться после этого.
Тем временем, в качестве альтернативы были изобретены локальные сети (LAN). Если вы хотели у себя соединить свои компьютеры (или терминалы и мэйнфрейм), вы получали неудобство в виде множества интерфейсов, которые необходимо было иметь для каждого соединения в топологии «звезда». Чтобы снизить издержки на электронику, людям нужна была сеть типа «шина» (также известная как «домен широковещания», понятие, которое будет важно в дальнейшем), где множество станций могли быть просто подключены в один провод, и разговаривать с любым, кто подключен в него же. Это были не те же самые люди, кто строил интернет, поэтому они не пользовались IP адресами для этого. Они изобрели свою собственную схему («уровень 2»).
Одной из ранних локальных сетей типа «шина» была дорогая моему сердцу arcnet (я написал первый Linux драйвер arcnet и стихи arcnet в далеких девяностых, спустя много времени после того как arcnet устарела). Адреса arcnet уровня 2 были очень простыми: только 8 бит, устанавливаемых перемычками или переключателями DIP на тыльной стороне сетевой карты. Это была ваша задача как владельца сети — настроить адреса и убедиться, что у вас нет дубликатов, или в противном случае произойти может любая чертовщина. Это было слегка болезненно, но сети arcnet были обычно достаточно небольшими, так что это было всего лишь подобие боли.
Несколько лет спустя пришел Ethernet и решил эту проблему раз и навсегда, используя гораздо больше бит (на самом деле, 48) в адресах второго уровня. Это достаточно бит, чтобы вы могли присвоить отличный от других (шардированно-последовательный (тут, видимо, имеется в виду что первые три байта MAC-адреса закрепляются как диапазон за конкретным производителем — прим. перев.)) адрес каждому устройству, которое когда-либо было выпущено, и не иметь пересечений. И именно это они и сделали! Так появились MAC-адреса Ethernet.
Различные технологии LAN появлялись и уходили, включая одну из моих любимых, IPX (межсетевой (internetwork — прим. перев.) обмен пакетами, хотя у него не было ничего общего с «настоящим» интернетом), и Netware, который работал великолепно, до тех пор пока все клиенты и серверы были в сети из одной шины. Вам никогда не приходилось настраивать никакие адреса. Это было и красиво, и надёжно, и работоспособно. Практически, золотой век сетестроения.
Конечно, кто-то должен был это разрушить: большие сети компаний/университетов. Они хотели иметь столько подключенных компьютеров, что разделение 10 Мбит/с на единой шине между ними всеми стало узким местом, так что им понадобился способ иметь множество шин, и соединять между собой — «интернетить», если хотите — эти шины вместе. Вы, наверное, думаете, «конечно! Используйте Протокол Интернета (IP) для этого», правильно? Ха-ха, нет. Протокол интернета, всё ещё так не называвшийся, не был ещё достаточно взрослым и популярным в то время, и никто не воспринимал его всерьёз. Netware-over-IPX (и многочисленные на то время другие протоколы локальных сетей) был серьёзным делом, и как делает любой серьёзный бизнес, они изобрели свои собственные штуки, чтобы расширять набравший популярность Ethernet. Устройства на Ethernet уже имели адреса, MAC-адреса, которые были, наверное, единственным, о чем использовавшие различные протоколы LAN люди могли договориться, поэтому они решили использовать адреса Ethernet в качестве ключей для своих механизмов маршрутизации. (Вообще-то, вместо «маршрутизации» они называли это bridging и switching.)
Проблема, связанная с Ethernet адресами, заключается в том, что они назначаются последовательно на заводе, так что они не могут составлять иерархию. Это означает, что «bridging таблица» не так хороша как современная таблица IP маршрутизации, которая может содержать запись о маршруте до целой подсети сразу. Чтобы сделать эффективный мост (bridging), вы должны были запоминать, в какой шинной сети каждый MAC-адрес может быть найден. А человеки не хотели настраивать каждый из них руками, так что это нужно было выяснить самостоятельно. Если у вас было запутанное соединение сетей при помощи мостов, всё становилось немного сложновато. Насколько я понимаю, вот что привело к поэме об остовном дереве, и я, наверное, просто оставлю это здесь. Поэзия очень важна в сетевых технологиях.
Как бы то ни было, по большей части это работало, хотя и было немного запутанно, и у вас то там, то здесь случались широковещательные «потопы», а маршруты не всегда были оптимальны, и это всё почти невозможно было отлаживать. (Вы определенно не могли написать что-то вроде traceroute для мостов, потому что ничто из инструментов, которые нужны были, чтобы это заработало — такие как возможность настроить адрес на промежуточном мосту — не существуют в голом Ethernet.)
С другой стороны, все эти мосты были аппаратно оптимизированы. Железячниками была изобретена попросту целая система в качестве механизма, обманывающего софт, который понятия не имел о множестве шин и мостах между ними, чтобы тот работал в бoльших сетях. Аппаратный bridging означает, что мост может работать действительно быстро, настолько же быстро, как сам Ethernet. Сейчас это не звучит как что-то выдающееся, но в то время это было очень много. Ethernet был 10 Мбит/с, так что вы, возможно, смогли бы забить его, подключив несколько компьютеров сразу, но один компьютер 10 Мбит/с выдать не мог. В те времена это звучало бредово.
В любом случае, смысл в том, что bridging был месивом, которое невозможно отлаживать, но он был быстрым.
Интернет по шинам
Пока это всё происходило, те самые интернетчики взялись за работу, и, конечно, они не проморгали появление крутых дешевых LAN технологий. Я думаю, что это могло быть примерно то самое время, когда ARPANET переименовывался в Internet, хотя я в этом не уверен. Давайте скажем, что так и было, потому что история звучит лучше, когда её рассказывают уверенно.
В какой-то момент прогресс перешел от соединения отдельных компьютеров Интернет через дальние линии связи точка-точка к желанию соединять целые локальные сети вместе через соединения точка-точка. В общем, хотелось иметь «длинные мосты».
Вы могли бы подумать: «эй, да нет проблем, почему бы не построить мост на длинной линии связи и покончить с этим?» Звучит хорошо, но это не работает. Я не буду вдаваться в подробности, но вкратце проблема заключается в контроле перегрузки (к сожалению, почему-то нет русского перевода этой статьи на вики — прим. перев.). Страшная тёмная тайна Ethernet бриджинга — это допущение, что все ваши соединения работают примерно на одной скорости, и/или сильно недогружены, потому что у них нет механизма торможения. Вы просто выплёвываете данные так быстро, как можете, и ожидаете что они придут. Но когда ваш Ethernet работает на 10 Mbps, а ваше соединение точка-точка — на 0.128 Mbps, это совершенно безнадёжно. Другая проблема состоит в том, что выяснение маршрутов при помощи отправки по всем каналам, чтобы понять какой из них правильный — а таким образом бриджинг обычно и работает — слишком затратно для медленных соединений. А неоптимальная маршрутизация, досадная и в локальных сетях, где низкая задержка и высокая пропускная способность, на медленных и дорогих дальних каналах связи совсем отвратительна. Это просто не масштабируется.
К счастью, интернетчики (если интернет уже назывался так) работали в точности над теми же проблемами. Если мы смогли бы использовать инструменты Internet для соединения Ethernet шин вместе, мы были бы в хорошей форме.
И тогда они разработали «формат фрейма» для пакетов интернет через Ethernet (и arcnet заодно, и всех остальных типов LAN).
И вот здесь всё пошло наперекосяк.
Первой проблемой, которую надо было решить, стало то, что теперь, когда вы кладёте пакет в провод, стало совсем непонятно, какая машина должна его «услышать» и, возможно, переправить дальше. Если несколько интернет маршрутизаторов находятся в одном сегменте Ethernet, у вас не получится сделать так чтобы они все приняли пакет и попытались перенаправить его; это путь в сторону пакетных штормов и зацикленных маршрутов. Нет, вам нужно самостоятельно выбрать, какой маршрутизатор в шине Ethernet должен его подобрать. Мы не можем просто использовать поле IP адреса назначения для этого, потому что мы уже туда записали адрес получателя сообщения, а не адрес роутера. Вместо этого мы определяем желаемый роутер, используя его MAC-адрес в фрейме Ethernet.
Таким образом, чтобы настроить вашу локальную таблицу маршрутов IP, вы хотели бы иметь возможность сказать что-нибудь наподобие «отправляй пакеты к адресу 10.1.1.1 через роутер c MAC 11:22:33:44:55:66.» Это то самое, что вы хотели бы выразить. Важно! Назначение вашего пакета — IP адрес, но ваш роутер — это MAC. Но если вы когда-либо настраивали таблицу маршрутизации, вы возможно заметили, что никто так их не записывает. Вместо этого вы пишете: «отправляй пакеты к 10.1.1.1 через роутер на 192.168.1.1».
На самом деле, это только всё усложняет. Теперь ваша операционная система должна сначала найти MAC-адрес для 192.168.1.1, понять что это 11:22:33:44:55:66, и наконец собрать пакет с адресом назначения Ethernet 11:22:33:44:55:66 и адресом назначения IP 10.1.1.1. Адрес 192.168.1.1 нигде в пакете не указан, это просто абстракция для людей.
Чтобы сделать этот бесполезный промежуточный шаг, вам нужно добавить ARP (протокол разрешения адресов), простой не-IP протокол, задача которого — преобразование IP адреса в Ethernet адрес. Это делается широковещательным запросом всем в локальном сегменте Ethernet, с вопросом нет ли у них вот этого IP адреса. Если у вас есть мосты, они должны пересылать все ARP пакеты на все свои интерфейсы, потому что они являются широковещательными пакетами, а это как раз то, что и означает слово «широковещание» (broadcasting). В большой, занятой сети Ethernet со множеством связанных LAN, избыточные broadcast-ы становятся одним из ваших ночных кошмаров. Особенно плохо это в сетях WiFi. С течением времени, чтобы бороться с этой проблемой, люди придумали мосты/свитчи со специальными хаками, позволяющими избегать пересылки ARP до тех пор, пока это технически возможно. Некоторые устройства (в особенности точки доступа Wi-Fi) просто отвечают поддельными ARP ответами, чтобы помочь. Но это всё костыли, хотя подчас и необходимые.
Смерть из-за наследия
Шло время. Однажды (и вообще-то это заняло прилично времени) люди практически перестали использовать не-IP протоколы в Ethernet. Так что в основном все сети стали физическим проводом (уровень 1), со многими станциями на шине (уровень 2), шины объединяются при помощи мостов (попались! всё ещё уровень 2), а эти интер-шины соединены IP-маршрутизаторыми (уровень 3).
Какое-то время спустя люди устали вручную настраивать IP адреса в стиле arcnet, и захотели, чтобы они настраивались самостоятельно, в стиле Ethernet, ну, за исключением того, что было уже поздно делать это в стиле Ethernet, потому что а) устройства уже выпускались с адресами Ethernet, а не IP, б) IP адреса были лишь 32-битными, что недостаточно чтобы просто производить их бесконечно без пересечений, и в) простое последовательное назначение IP адресов вместо использования подсетей вернуло бы нас к началу: это был бы ещё один Ethernet, сделанный с нуля, а у нас уже есть Ethernet.
И тут появились bootp и DHCP. Эти протоколы, кстати, особенные — наподобие ARP (только они пытаются не быть особенными, технически являясь IP пакетами). Им необходимо быть особенными, потому что IP узел должен иметь возможность отправить их до того, как получит IP адрес, что конечно же невозможно, поэтому он просто заполняет IP заголовки по сути бессмыслицей (хотя и указанной в RFC), так что их можно спокойно отбросить. (Вы опознаете эти бессмысленные заголовки, потому что DHCP должен открыть raw сокет и заполнить их вручную; уровень IP в ядре не может это сделать.) Но никто не стремился радостно изобретать ещё один протокол, который не был IP, так что они сделали вид что это IP, и все были довольны. Ну, настолько, насколько возможно, когда вы изобретаете DHCP.
Я немного отвлёкся. Отличительная черта здесь следующая: в отличие от настоящих служб IP протоколам bootp и DHCP нужно знать об адресах Ethernet, потому что, в конце концов, это их работа — слушать ваши Ethernet адреса и присвоить вам IP адреса для дальнейшей работы. По сути это обращение протокола ARP, за исключением того, что мы не можем так сказать, потому что уже есть протокол RARP, который буквально и является «обратным ARP» (reverse ARP — прим. перев.). Вообще-то RARP работал вполне неплохо и делал то же, что и bootp и DHCP, будучи гораздо проще, но не будем об этом.
Смысл всего этого в том, что Ethernet и IP всё сильнее и сильнее переплетались. Сейчас они практически неотделимы. Сложно представить сетевой интерфейс (кроме ppp0) без 48-битного MAC-адреса, и сложно представить этот интерфейс работающим без IP адреса. Вы записываете вашу IP таблицу маршрутизации, используя IP адреса, но конечно вы знаете, что вы лжёте, называя роутер по его IP адресу; вы просто косвенно говорите, что вы хотите маршрутизировать через MAC-адрес. И у вас есть ARP, который ходит через мосты, но понарошку, и DHCP, который является протоколом IP, но на самом деле Ethernet и т. п.
Более того, мы всё ещё имеем и мосты (bridging), и маршрутизацию (routing), и они оба усложняются, в то время как локальные сети и интернет также усложняются и усложняются. Бриджинг всё ещё, в основном, аппаратный и определен IEEE, людьми, которые управляют стандартами Ethernet. Роутинг всё ещё, в основном, программный и определен IETF, людьми, контролирующими стандарты Интернет. Обе группы всё ещё пытаются делать вид, что другой группы нет. Сетевые операторы попросту выбирают bridging vs routing, опираясь на то, насколько быстро они хотят чтобы он работал и насколько сильно они ненавидят настройку DHCP серверов, которую они на самом деле ненавидят очень сильно, что означает что они используют мосты настолько, насколько это возможно и маршрутизацию — когда им приходится.
Фактически, мосты настолько вышли из-под контроля, что люди решили вынести решения, принимаемые на уровне моста, целиком на более высокий уровень (конечно же, обмен конфигурацией между мостами делается с использованием протокола поверх IP!), чтобы можно было ими централизованно управлять. Это называется программно-определяемая сеть (SDN). Это сильно лучше, по сравнению с тем, когда свитчам и мостам разрешено делать что им угодно, но это также фундаментально глупо, потому что знаете, что такое программно-определяемая сеть? IP. Это он буквально и есть, и всегда был SDN, которую вы используете для соединения сетей, ставших слишком большими. Но проблема в том, что IPv4 изначально было слишком сложно ускорить аппаратно, и в любом случае, он не получил аппаратного ускорения, а настройка DHCP — сущий ад, так что сетевые операторы просто научились, как соединять мостами всё большие и большие сущности. А сейчас большие датацентры попросту основаны на SDN, и вы могли бы не использовать IP в датацентре вообще с тем же успехом, потому что никто не маршрутизирует пакеты. Это всё просто одна большая сеть типа «шина».
Это, коротко говоря, бардак.
Теперь забудьте, что я всё это рассказал...
Хорошая история, правда? Хорошая. Теперь притворимся, что ничего этого не произошло, а мы вернулись обратно в 1990-е, когда большая часть всего на самом деле и случилась, но люди в IETF всё ещё делали вид что этого не было и «надвигающейся» катастрофы можно избежать. Это хорошая часть!
Я кое-что забыл упомянуть в этой длинной истории выше: где-то в этой цепи событий мы совсем перестали использовать шинные сети. Ethernet на самом деле больше не шина. Он только притворяется шиной. Попросту говоря, мы не могли бы заставить работать известный CSMA/CD по мере роста скоростей, так что мы вернулись назад к старой доброй топологии «звезда». У нас идёт пачка кабелей от свитча, так что мы можем протянуть один кабель от каждой станции к центру. Стены, потолок и полы заполнены большими, толстыми и дорогими связками кабелей Ethernet, потому что мы не смогли разобраться, как заставить шину работать хорошо… на уровне 1. Это несколько забавно, если задуматься. Если, конечно, вы находите забавными грустные вещи.
На самом деле, в порядке приступа безумия, даже WiFi — предельный случай «шинной» сети — правильно! — где буквально все разделяют одну и ту же среду открытого пространства, мы почти везде используем WiFi в режиме, называемом «инфраструктура», который эмулирует топологию гигантской «звезды». Если у вас есть две WiFi станции, подключенные к одной точке доступа, они не общаются друг с другом напрямую, даже когда могут хорошо «слышать» друг друга. Они отправляют пакет точке доступа, но адресованный MAC-адресу другого узла. Точка доступа затем отражает его в сторону узла назначения.
ПРИДЕРЖИТЕ КОНЕЙ ДАЙТЕ МНЕ ДЛЯ ВАС ЭТО ПОЯСНИТЬ. Есть здесь один подвох. Когда узел X хочет отправить что-то в интернет узлу Z, через IP роутер Y, через Wi-Fi точку доступа A, как выглядит пакет? Нарисуем картинку, что мы хотим:
X -> [wifi] -> A -> [wifi] -> Y -> [internet] -> Z
Z — адрес IP назначения, так что, очевидно, поле IP destination должно быть Z. Y — роутер, который, как мы узнали выше, указываем его Ethernet MAC-адресом в поле Ethernet destination. Но в Wi-Fi, X не может просто отправить пакет к Y, по разным причинам (включая то, что они не знают ключи шифрования WPA2 друг друга). Нам нужно отправлять в A. Вы возможно спросите, куда мы положим адрес A?
Не проблема! 802.11 имеет такую вещь как трехадресный режим. Они добавили третий Ethernet MAC-адрес в каждый фрейм, чтобы можно было говорить о настоящем Ethernet destination и промежуточном Ethernet destination. Поверх этого, есть ещё битовые поля, называемые «to-AP» и «from-AP», которые говорят вам, что пакет идёт от станции к точке доступа или от точки доступа к станции, соответственно. Но вообще-то они могут быть оба истиной, потому что так делают Wi-Fi повторители (ТД отправляет пакеты к ТД).
Кстати о повторителях! Если A — репитер, отправлять обратно к базовой станции B ему нужно по пути, который выглядит вот так:
X -> [wifi] -> A -> [wifi-repeater] -> B -> [wifi] -> Y -> [internet] -> Z
X->A использует трехадресный режим, но на A->B возникает проблема: Ethernet источника — X, а Ethernet назначения — Y, но пакет по воздуху пересылается от A к B; X и Y вообще не задействованы. Достаточно сказать, что есть такая штука как четырехадресный режим, и он работает именно так как вы могли подумать.
(В меш-сетях 802.11s есть режим, называемый шестиадресным, и примерно на этом месте я бросил попытки понять.)
Avery, мне обещали IPv6, а ты ещё даже не упомянул его
Ой-ой. Этот пост немного сошел с рельс, вы не находите?
Вот цель всего этого рассказа. Люди в IETF, когда придумывали IPv6, посмотрели на всё это безобразие — и, возможно, предсказали ещё большую неразбериху, которая должна была появиться, хотя я сомневаюсь, что они могли бы предсказать SDN и режимы повторителя WiFi — и сказали, погодите-ка минутку, стойте. Нам не нужно всё это дерьмо! Что если вместо этого мир вокруг нас работал бы вот так:
- Никаких больше физических шинных сетей (уже готово!)
- Никаких больше интерсетей уровня 2 (для этого есть третий уровень)
- Никаких больше броадкастов (уровень два всегда будет точка-точка, поэтому куда вы бы отправили броадкаст? Заменим многадресными рассылками — multicast)
- Никаких больше MAC-адресов (в сетях точка-точка очевидно, кто отправитель и кто получатель, а мультикаст вы можете сделать и на IP адресах)
- Никаких больше ARP и DHCP (нет MAC-адресов, поэтому нет отображения IP адресов на MAC)
- Никаких больше сложностей с заголовками IP (так что вы можете аппаратно ускорить маршрутизацию)
- Никаких больше нехваток IP адресов (так что мы можем вернуться к маршрутизации больших подсетей)
- Никакой больше ручной конфигурации IP адресов, кроме ядра (сети Интернет — прим. перев.) (а у нас есть столько IP адресов, что мы можем рекурсивно раздавать подсети по дереву оттуда)
Представьте, что мы жили бы в таком мире: WiFi репитеры были бы просто IPv6 роутерами. И точки доступа тоже. И Ethernet свитчи. И SDN. С ARP штормами было бы покончено. Каждую проблему маршрутизации можно было бы tracerout-ить. И что лучше всего, мы могли бы выбросить 12 байт (MACадреса источника и назначения) из каждого пакета Ethernet, и по 18 байт (источник/назначение/точка доступа) из каждого WiFi пакета. Конечно, IPv6 добавит нам дополнительные 24 байта адресов (по сравнению с IPv4), но вы выбросите 12 байт Ethernet, так что оверхед составит лишь 12 байт — сравнимо с использованием двух 64-битных IP адресов, если вы оставите заголовок Ethernet. Идея, что однажды мы сможем выбросить адреса Ethernet, помогла оправдать раздувание IPv6 адресов.
Это было бы красиво. Кроме одной проблемки: этого не случилось.
Реквием по мечте
Один коллега на работе сказал лучше всех: «слои всегда только добавляются, и никогда не исчезают».
Для всех этих чудес необходима возможность начать сначала и выбросить наследие, построенное к тому моменту. А это, к сожалению, по большей части невозможно. Даже если бы IPv6 достиг проникновения в 99%, это не значило бы что мы избавились от IPv4. А если мы не избавились от IPv4, мы не избавились от Ethernet адресов, или WiFi адресов. А если нам нужно соблюдать стандарты фреймов IEEE 802.3 и 802.11, мы никогда не сможем выбросить те байты. Поэтому нам всегда будет нужен протокол обнаружения соседей «IPv6 neighbour discovery», который просто является более сложным ARP. Даже хотя мы больше не пользуемся шинными сетями, нам всегда нужно будет некое подобие броадкастов, потому что так работает ARP. Нам нужно будет держать запущенным локальный DHCP сервер дома, чтобы наши устаревшие IPv4 лампочки продолжали работать. Нам всё ещё нужен будет NAT, чтобы устаревшие IPv4 лампочки смогли добраться до интернета.
И это ещё не самое худшее. Хуже всего то, что нам всё ещё нужна бесконечная мерзость в виде бриджинга второго уровня, из-за ещё одной ошибки, которую команда IPv6 забыла исправить. К сожалению, когда они разрабатывали IPv6 в 1990-х, идея была сначала запустить IPv6 — это должно было занять несколько лет — а затем работать над ним, когда IPv4 и MAC-адреса уже исчезнут, тогда эту задачу стало бы проще решить, а на тот момент всё равно ни у кого на самом деле не было по-настоящему «мобильных IP-устройств». То есть, что бы это вообще должно было значить — носить с собой ноутбук и втыкать его в Ethernet порты один за другим, в то время как файл загружается по FTP? Звучит тупо.
Приложение-убийца: мобильный IP
Конечно, имея пару десятков лет истории позади, сейчас мы знаем несколько примеров переносных компьютеров — ваш телефон — и подключения его к
Не совсем, из-за постыдного секрета Интернета: это всё работает только из-за bridging-а второго уровня. Маршрутизация интернета не работает с мобильностью, совсем. Если вы перемещаетесь по IP сети, ваш IP адрес меняется, а это ломает все открытые вами соединения.
Корпоративные WiFi сети обманывают вас, объединяя LAN целиком на втором уровне мостом, так что гигантский центральный DHCP сервер всегда отдаёт вам один и тот же IP адрес независимо от того, к какой корпоративной точке доступа вы подключились, а потом доставляет вам ваши пакеты, максимум с переывом на несколько секунд, пока мост переконфигурируется. Эти новомодные домашние WiFi системы со множественными репитерами/экстендерами делают то же самое. Но если вы переключаетесь с одной WiFi сети к другой пока гуляете по улице — если бы публичный WiFi был во всех магазинах подряд — то всё плохо. Каждая из них выдаёт вам новый IP адрес, и каждый раз, когда ваш IP адрес меняется, все ваши соединения рвутся.
LTE старается ещё усерднее. Вы сохраняете свой IP адрес (обычно IPv6 адрес в случае мобильных сетей), даже когда перемещаетесь на километры и многочисленные сотовые вышки передают вас от одной к другой. Как? Ну… они обычно просто туннелируют ваш трафик к центральной точке, где он весь соединяется мостом (хотя и через усиленную фильтрацию файрволлами) в одну супер-огромную виртуальную сеть второго уровня. И ваши соединения продолжают жить. Ценой большой сложности и действительно обескураживающего количества дополнительных задержек, которые они правда хотели бы убрать, но это практически невозможно.
Как заставить мобильные сети работать
Ну ладно, это была длинная история, но мне удалось-таки вытянуть её из людей в IETF. Когда мы добрались досюда, до проблемы мобильных IP, я ничего не мог поделать, кроме как спросить. Что пошло не так? Почему мы не можем заставить это работать?
Выясняется, что ответ удивительно прост. Большой недостаток кроется в том, как была определена известная «четвёрка» (IP источника, порт источника, IP назначения, порт назначения). Мы используем эту четвёрку для идентификации данной сессии TCP или UDP; если в пакете указаны те же четыре поля, то он принадлежит этой сессии, и мы можем отправить её в тот сокет, который обслуживает сессию. Но четвёрка покрывает два уровня: сетевой (третий) и транспортный (четвёртый). Если бы вместо этого мы определяли сессии с использованием только данных четвёртого уровня, то мобильные клиенты работали бы превосходно.
Приведём короткий пример. Порт 1111 клиента X общается с 80 портом Y, поэтому он должен отправить четвёрку (X,1111,Y,80). Ответ приходит с (Y,80,X,1111), а ядро доставляет его в сокет, которых создал первый пакет. Когда X отпраляет ещё пакеты, обозначенные (X,1111,Y,80), Y отправляет их в тот же серверный сокет, и т. д.
Затем X меняет IP адрес, и получает имя, скажем, Q. Теперь он начинает отправлять пакеты с четвёркой (Q,1111,Y,80). Y понятия не имеет что это значит, и выбрасывает его. Тем временем, если Y отправит пакеты, обозначенные (Y,80,X,1111), то они потеряются, потому что больше нет X, готового их получить.
Представьте теперь, что мы бы пометили сокеты без привязки к IP адесам. Чтобы это работало, нам нужны гораздо большие номера портов (которые сейчас составляют 16 бит). Давайте сделаем их, скажем, длиной 128 или 256 бит, чем-то вроде уникального хэша.
Теперь X отправляет пакет Y с меткой (uuid,80). Заметьте, пакеты сами по себе всё ещё содержат информацию об адресах IP (X,Y), на уровне 3 — именно так они маршрутизируются до правильной машины. Но ядро не использует информацию уровня 3 для принятия решения о том, в какой сокет отправить пакет; оно просто использует uuid. Порт назначения (80 в этом случае) нужен только для начала новой сессии, чтобы определить к какой службе вы хотите подключиться, и может после этого игнорироваться или не приниматься во внимание.
Для обратного направления, ядро Y кэширует тот факт, что пакеты для (uuid) идут в IP адрес X, который является последним адресом, с которого приходили пакеты для (uuid).
Теперь представим, что X меняет адрес на Q. Он всё ещё посылает пакеты с тэгом (uuid,80) на IP адрес Y, но теперь эти пакеты приходят с адреса Q. Машина Y получает этот пакет и сверяет его с сокетом, ассоциированным с (uuid), замечает, что пакеты для этого сокета теперь приходят с адреса Q и обновляет кэш. Теперь пакеты в обратную сторону могут быть отправлены, с тэгом (uuid), в сторону Q вместо X. Всё работает! (С учётом мер, необходимых для предотвращения атак самозванцев).
Есть только один подвох: UDP и TCP так не работают, и слишком поздно их обновлять. Обновление UDP и TCP было бы сравнимо с обновлением IPv4 до IPv6; проектом, казавшийся простым тогда в 1990-х, но десятилетия спустя не завершенном и наполовину (и первая половина была простой; оставшаяся часть гораздо сложнее).
Хорошая новость в том, что возможно нам удастся обойти это ещё одним нарушением «расслоения». Если мы выбросим TCP — он всё равно уже достаточно стар — и вместо этого будем использовать QUIC поверх UDP, то мы сможем просто перестать использовать четвёрку UDP в качестве идентификатора соединения. Вместо этого, если номер порта UDP равен определенному значению, означающему «слой мобильности», то мы распакуем содержимое, которое может быть другим пакетом с правильным тэгом UUID, сверим его с правильной сессией и доставим эти пакеты в нужный сокет.
Есть ещё более хорошая новость: экспериментальный QUIC протокол уже, по крайней мере в теории, имеет правильную структуру пакета, чтобы так работать. Выясняется, что вам в любом случае нужны уникальные идентификаторы сессий (ключи), если вы хотите использовать stateless (без сохранения состояния) шифрование и аутентификацию, как делает QUIC. Так что, возможно с небольшими доработками, QUIC мог бы поддержать прозрачный роуминг. Каким стал бы такой мир!
Здесь всё, что нам нужно сделать — убрать все остатки UDP и TCP из интернета, а тогда у нас бы точно пропала необходимость в мостах второго уровня, на этот раз по-настоящему, и тогда мы могли бы избавиться от броадкастов и MAC-адресов, и SDN, и DHCP и всего остального.
Тогда интернет стал бы опять изящным.
Комментарии (55)
tyomitch
21.10.2017 16:08+1с использованием двух 64-битных IP адресов
Ээ, что? В какой вселенной они 64-битные?
rzerda
21.10.2017 16:47В выдуманной. Автор статьи имел в виду, что размеры заголовков для IPv6 без Ethernet и для мифического IPv4+ с IP-адресами 64 бита и Ethernet будут одинаковы.
black_semargl
22.10.2017 13:14ну вообще говоря адрес: протокол: порт — 64 бита.
И если порт разумно оставить, то протокол не нужен.
Плюс из заголовка дропнуто всё связанное с фрагментацией.Kib0rg Автор
22.10.2017 13:24Тут речь о том, что при разработке ipv6 рассматривали разные варианты, в том числе, вероятно, увеличение разрядности адреса до 64 бит с сохранением формата фрейма ethernet, но 128 бит без него было бы предпочтительнее.
sotnikdv
21.10.2017 20:21А может пора перестать строить космические корабли и решить одну, но важную проблему, нехватку адресов?
Если бы какой-нибудь ipv5 банально расширил адресное пространство, уже все давно бы мигрировали и забыли о ipv4. И совместимость элементарная, делаем к ipv4 адресу стандартный префикс, например нули.
И было бы куча времени (сколько уже ipv6 типа внедряется?) на построение нового протокола. С солитером и гейшами.
Глубокоуважаемый автор предлагает строить еще одну конструкцию, эпичнее не взлетевшей предыдущей.
khim
21.10.2017 20:48И совместимость элементарная, делаем к ipv4 адресу стандартный префикс, например нули.
Проблема в том, что «элементарная совместимость» работает строго не в ту строну: можно поверх IPv6 сетей (которых нет) запускать IPv4 траффик (который есть и отлично работает в сетях IPv4).
В обратную сторону ваше предложение не работает, однако.
Если бы какой-нибудь ipv5 банально расширил адресное пространство, уже все давно бы мигрировали и забыли о ipv4.
Серьёзно? Вот приходите вы, весь такой в белом, и говорите руковождству: а давайте внедрим поддержку IPv5 во все наши операционки, программы и прочее. Главное — заменить все дорогущие железные роутеры. А на резонный вопрос «а науха?» вы отвечаете «ну прямо сейчас это никому ничего не даст, но когда все прейдут наэсперантоIPv7 — то проблема нехватки IP-адресов (от которой мы, в общем-то прямо сейчас никак не страдаем) будет решена».
Как вы думаете, каков будет ответ? Возможные варианты, которые приходят мне в голову:
- А не выпить ли тебе чего-нибудь от ...?
- А не пошёл бы ты в ...?
- А на пошёл бы ты на ...?
- Ну или чего-нибудь в этом духе...
Любая замена IPv4 упиралась в одну и ту же вещь: затраты нужны прямо сейчас, а выиграш будет неизвесно когда. Хоть IPv6, хоть IPv7 (номер под IPv5 занят, потому IPv5 лучше не пытаться использовать).
На самом деле всё прошло ровно так, как мудрые люди говорили умным: не парьтесь вы и не пытайтесь «дать больше времени на переход» — все ваши попытки только лишь затянут начало этого процесса и сделают его более болезненным.
И, собственно, переход на IPv6 внедряется ровно столько времени, сколько его нужно внедрять. Как рак на горе свистнул — так и начали. И довольно-таки бодренько. А всё, что было до того — предистория.
Глубокоуважаемый автор предлагает строить еще одну конструкцию, эпичнее не взлетевшей предыдущей.
Отнюдь. Он предлагает заменить TCP на другой протокол, QUIC — но эта замена не требует замены инфраструктуры и потому её можно внедрить [относительно] малой кровью — примерно как внедряли HTTP/2.
equand
22.10.2017 13:10Не надо ничего расширять. Не знаю почему, но VLAN tagging не был введен на глобальном уровне. А это извините 2^44 IPv4 адресов. Этого достаточно для планеты. Все что надо было сделать это придумать альтернативную схему для такого количества IP адресов. Что-то вроде 11 номеров F.FF.FF.FF.FF.FF или 0-15.0-255.0-255.0-255.0-255.0-255
В таком случае не нужно было бы городить огород и большинство программ потребовалось бы только проапгрейдить софт (BGP обычно на CPU весит).
Все равно было бы проще нежели IPv6, проблема которого именно описание. Да и проблем он по сути больше 2^48 не решает т.к. конечным пользователям выделяют их в последнее время.
Эх. Написать чтоли RFC.
Kib0rg Автор
22.10.2017 13:37+1Про проблему лампочек, работающих на IPv4, в статье сказано, и вы упрётесь в неё же. Всё, что нельзя по каким-либо причинам перепрограмировать, работать не будет как с IPv6, так и в вашей схеме, поэтому IPv6 создавался таким образом, чтобы заодно избавиться и от некоторых костылей, появившихся во времена, когда ethernet был шиной.
Провайдеры же со своей стороны не готовы доставлять клиентам такие неудобства и тратить заранее приличные суммы денег на апгрейд оборудования с непонятным профитом, пока адреса v4 не когчились.
qw1
22.10.2017 13:57+2Допустим, мы используем 12 бит vlan из ethernet кадра на расширение dst-адреса. Но нужно ещё столько же на src-адрес. Иначе, как сервер узнает, кому отвечать на соединение, если адрес клиента из другого vlan id.
equand
22.10.2017 14:33-1Ок, использовать 802.1q который с 2003 в поддержке везде. Тогда получается 3 байта на source и 3 байта на destination. Еще больше IP, как раз догнали IPv6 /48. Да и запись упрощается.
Хоте честно говорят все это полное Г.
IPv6 строился без понимания глобального рутинга, в котором как раз и проблема.
Поэтому имхо нужна замена БГП блокчейном. Тогда сможем избавиться от региональных раздавателей и интернет будет более устойчивым к атакам и ошибкам нежели сейчас. Прелесть правильно составленного блокчейн протокола в том, что он будет скалироваться от локальной сети к глобальной без проблемы.
qw1
22.10.2017 15:33Блокчейны сейчас работают поверх IP. Не будет маршрутизации IP — блокчейн развалится, а маршрутизацию вы хотите вынести в блокчейн )))
equand
22.10.2017 15:50Вы немного не поняли. Я предлагаю блокчейн маршрутизацию на уровне железа. Допустим домашние ноды SPF ноды с локальной верифицирующей нодой рутера. Обмануть рутер невозможно, т.к. мы используем пару паблик-прайват ключей между рутерами с сабключами для устройств под рутером. Пакеты шифруются сабключем.
В этом случае сетевая инфраструктура непоколебима между доверенными устройствами. Маршрутизация происходит по каналам зарегистрированным выполненной работой (сложность работы позволяет регулировать скорость работы сети и сложность MITM с потерянным сабключем)
Прелесть всего этого в отсутствии необходимости в IP в целом. Непоколебимости при взламывании.
Идея не полностью додумана, но по сути мы упрощаем кучу сложностей текущих сетевых технологий.
Ринг-топология с 1000 в 1000 q-in-q? Весь этот шлак ненужен когда в пакетах только данные "канал" "нонс" "тело пакета" и это шифровано сабключем.
Я пока еще не думал об этом полностью, но БГП тоже можно загнать в подобную топологию, где пиринг это "канал" между верхними рутерами.
firk
22.10.2017 16:00+1Адепты блокчейнов добрались и сюда.
Прелесть всего этого в отсутствии необходимости в IP в целом.
А если написать программу для выполнения операций сложения и прочей арифметики, то можно будет делать компы без процессоров и с этой программой вместо них.
equand
22.10.2017 17:02Нет почему же. Проблема Византийских генералов всегда присутствовала в обмене информации. Блокчейн решает ее до 50% — то есть по допустимому максимуму.
В Ethernet эта проблема решена через — одна авторитарная нода (рутер) и много работников. Только в итоге все равно пришлось все это дело расширять (VLAN, STP, OSPF, BGP и сотня других протоколов расширения), чтобы уменьшить проблему этих самых генералов (ARP Spoof, ARP poisoning, DHCP/DNS Cache poisoning, VLAN spoofing и т.п. и т.д.). Все это нужно, чтобы Вася с мак адресом FF:FF:FF:FF:FF:FF доставил сообщение Косте с мак адресом BB:BB:BB:BB:BB:BB в другой конец мира.
По сути принцип авторитарный. Но фейлится он конкретно, там где нет авторитета — например на уровне BGP (когда Костин провайдер внезапно прописал туеву хучу препендингов и повалил весь интернет в мире).
Блокчейн элегантно и легко это решает, особенно на топ уровне. Или же Вы предполагаете, что текущий Full table не похож на мемпул? :)
firk
23.10.2017 01:42Вы знаете кучу умных слов, но совершенно не понимаете как принципы построения сетей, так и механизм работы своего любимого блокчейна. Впрочем от блокчейн-адептов другого ждать не приходится.
equand
23.10.2017 11:13Я этим на хлеб зарабатываю (построение сетей и механизм работы блокчейна). Прошу удержать кидание какашками, если отсутствуют аргументы.
qw1
22.10.2017 16:12+1Вы немного не поняли
Почему же? В p2p-сети у каждой ноды есть адрес (обычно, рандомное число 128-512 бит), и таблица маршрутизации (сделанная через DHT), мапящая этот адрес на IP-адрес, чтобы любая нода p2p-сети могла найти другую ноду по p2p-id и послать сообщение.
Т.е. всё равно придётся реализовывать сетевой уровень, чтобы на нём сделать блокчейн, а на котором будет IP-сеть )))equand
22.10.2017 17:25Не обязательно!
Как я уже писал выше в посте https://habrahabr.ru/post/340626/?reply_to=10485286#comment_10485368 проблема византийских генералов присутствует всегда. В LAN она решается через выбор "кто рутер". В WAN выбор "с кем пирится, кто транзитит". Всегда выбирается авторитет. Вот только секьюрность авторитетности ничем не доказывается. В WAN WIFI такая проблема присутствует например. С блокчейном сибил атака как на WPA2 недавно была бы невозможна, потому что цепочка длинее и с большей работой выиграла бы, чем хакерская с меньшей работой и короткой историей.
Как обойти другие неприятности можно было бы проработать, сейчас к сожалению нет на это времени.
qw1
22.10.2017 21:44Вы говорите о проблеме консенсуса, я же говорю о том, что пиры, прежде чем договариваться между собой, должны уже иметь каналы связи.
equand
22.10.2017 23:20Я же и предлагаю переделать L2. Сейчас каналы связи все равно устанавливают L2 соединение по физическому лейеру. И с него начинается наша матрешка лейеров. Как я уже писал выше можно начать с Layer 2, то что ближе к железу. Сделать авторизацию (открытие L2 канала по физическому уровню) через обмен ключей и синхронизацию локального блокчейна каналов (адреса неизвестны, ВАУ! +1 к приваси). Вариации с публичным/приватным ключом скажут мастер ноде об уровне физического доверия к системе (аля L2 port locking, только куда более секьюрным чем ARP+MAC+IP). И все — 90% текущих сетевых проблем ушло. Прочесть чужой канал невозможно, т.к. пакеты либо зашифрованы аппаратно (если есть TLS или AES), либо адресат его читает по зашифрованному нонсу, ключ шифра которого знает только он и открыватель канала, потому что обмен нонса был в шифрованном виде (или вообще в оффлайне) (допустим у нас хаб, или бридж и все видят траффик друг друга). Нонса два и они всегда обновляются.
Получается мы так можем выкинуть огромную часть L2 и L2/L3 мусора. Остаются только части для работы над потерями.
qw1
23.10.2017 18:07То есть, возложить на оборудование всё-такие две функции:
— протокол чейна, установление каналов, шифрование,
— поверх того, что получилось, гонять IP.
Это будет очень дорого, если каждый свич/роутер будет жужжать как топовый bitcoin-ASIC.equand
23.10.2017 18:46-1Нет. IP вообще не гонять, он больше не нужен будет. Для соединения нам надо будет создавать каналы с адресами.
Каждому свичу и рутеру не нужно будет быть биткоин асиком.
Количество работы будет определяться необходимым уровнем безопасности в сети. Например в локальной сети дома вообще работа не нужна будет, т.к. дома без проблем вместо IP адресов можно ввести сабключ и возможность взлома только в случае, если кто-то получить мастер-приватный-ключ. Но только у Вас тогда проблемы посерьезнее. В СМБ и интерпрайзе абсолютно такой же подход. Сверху-вниз там вполне ок.
А вот в интернете с БГП, который каждый может оверлоадить или перезаписать это конечно плохо, что работа не выполняется. Соответственно там уже блокчейн работает напрямую. НО работа выполняется для поддержания каналов рабочими. Как я уже говорил транзакция с отложенной датой реализации = канал. Прелесть в том, что токены заложенные в эти транзакции и будут криптовалютой автоматически по завершении транзакции оплачивающие работу канала. Принцип работы схожий с лайтнинг нетворком. Для создания канала объявляется транзакция на обмен 50/50 токенов. Которые в случае не оплаты схлопывается без продления, так что обе стороны должны прийти к согласию в чью сторону перейдут токены по окончании работы канала.
В итоге два или несколько пиринг партнера, желающих заключить договор просто подключаются L1 к друг другу. Заверяют консенсус обменом сабключами, для создания L2 соединения. Объявляют транзакцию в мем пул, мем пул канал-транзакция заверяется шахтерами соединенными единой L2 сетью и отправляется другим участникам L2 обмена (между всеми способными содержать всю БД блоков (фулл нодами) и шахтерами (которые по умолчанию фулл ноды) любой участник обмена может быть шахтером). После создания канала, они используются для соединения.
Как видите в этой схеме не нужны асики на каждой системе. Да и не обязательно использовать такие асики, можно реализовать proof-of stake или если страх жирных рук получающих 51% реализовать proof-of-bandwidth тогда проблемы вообще не будет ибо это именно то что нужно сетевым операторам. Реализовать ее на L2 уровне и при поддержке железа довольно просто.
К тому же можно уйти с заверения блоков, и заверять конкретные каналы.
Много решений, голова кипит, но это было бы лучшим решением, если реализовать верно.
qw1
23.10.2017 20:32реализовать proof-of-bandwidth
Забивать каналы, вместо того, чтобы жечь CPU?
это было бы лучшим решением, если реализовать верно
Скорее, мы бы получили на ровном месте кучу других проблем. Начиная с банальной «теперь всех сетевых инженеров надо заменить к.т.н. по теории чисел, чтобы они смогли отдебажить непонятные глюки в сети, ведь всё теперь зашифровано».
И заканчивая DoS-атаками на блокчейн (или транзакции сделать платными? Тогда можно будетграбить корованывыходить на ICO всей подсетью )))
Не понимаю, зачем оперативной информации блокчейн. Тут же нет задач узнать, а какой роут был 100 лет назад до подсети, которая сейчас уже в другой город переехала.
Если хочется децентрализации, достаточно базы с записями вида <порядковый номер, роут>, подписанными ключом владельца адреса. И записи с большим порядковым номером безальтернативно замещают предыдущие записи, и консенсус не нужен.equand
24.10.2017 01:29-1Вы видимо не до конца понимаете концепт.
Насчет pob да, что-то должно тратиться для увеличения стоимости атаки. Либо делать proof of connectivity, но это тоже чревато. В крайнем случае Proof of stake
Сетевикам наоборот работы меньше, ибо вместо матрешки им разбираться только с последовательными каналами.
Транзакция открывает канал, транзакция платная, переводы в канале бесплатны. То бишь ддосер чтобы совершить атаку должен будет заплатить дохрена. Иначе он просто откроет простой канал за типичную стоимость. В наше время ддос почти бесплатен.
Блокчейн не храниться ради истории, Вы видимо не понимаете необходимости блокчейна. Да если бы историю можно было бы убрать ее б давно уже убрали. В начале истории биткоина полная история транзакций была одним из камней преткновения. К сожалению способа избавиться от нее, не потеряв точную уверенность владения, не нашли пока что.
Блокчейн в данном случае будет регистрировать сделки пиринга и транзита на самом низком уровне между ISP. Им история понадобится. А если не понадобится от нее можно избавиться соглашением (голосованием нод), аля purge и перерегистрация с такого-то блока при 90% консенсусе.
И в принципе не обязательно фулл хистори хранить, достаточно хранить только что релевантно, а остальное можно хранить только то, что имеет смысл (аля purge в биткоине).
qw1
23.10.2017 20:52Нет. IP вообще не гонять, он больше не нужен будет. Для соединения нам надо будет создавать каналы с адресами.
Поверх которых будет IP, потому что «уровни абстракции только добавляются, но никогда не исчезают» ))equand
24.10.2017 01:29Необязательно. Зачем IP поверх? Если уж надо будет что поверх послать, можно сделать каналы поверх, которые и будут соединениями от точки к точке.
khim
22.10.2017 16:35Идея не полностью додумана, но по сути мы упрощаем кучу сложностей текущих сетевых технологий.
Вау, как круто. А вы не забыли про главное, фундаментальное, ограничение, вокруг которого «накручивается» всё остальное в глобальных сетях?
Оно, в общем-то, очевидно даже третьекласснику (но адепты блокчейна, о нём, по всей видимости, не подозревают).
Посмотрите на карту мира. Что вы там видите? Правильно: материки. А между ними — океаны. На материках живут сотни миллионов людей — на каждом. А «ниточек», связывающих оные материки — десятки, в лучшем случае — сотни. Дорого потому что очень.
Соответственно на этих магистралях речь идёт о сумасшедших, звучащих почти фантастически, скоростях — сегодня речь идёт десятках и сотнях терабит в секунду.
Соответственно все сетевые технологии вынуждены учитывать то, что роутеры не могут быть умными. Всякие разные вспомогательные таблицы — могут быть сложными и хитрыми, но обработка пакетов должна происходить в железе.
Потому и всякие хитные схемы с использованием опциональных полей в IPV4 заголовка и многое другое провалилось. Магистральные роутеры — невероятно умны и тупы одновременно.
У них есть «умная» часть, которая не работает с индувидуальными пакетами (но может себе позволить работать с шифрованием и прочим), и «тупая» — то, что непосредственно пересылает пакеты не задействуюне то, что сложную математику, но даже CPU.
А вот теперь, когда мы обсудили фундаментальную проблему глобальных сетей — можно обсуждать как блокчейн её решать будет.equand
22.10.2017 17:20Да я в курсе как это работает. Каждый день с этим работаю. Спасибо за ELI5 switching/routing ASIC.
И да это тоже можно учесть, как я уже говорил через subchain и subchannels.
В итоге вместо проверки в forwarding таблице, checksum и туевой хучи компонентов каждого пакета ASIC придется проверять только ключи инкрементального нонса каналов во внутреннем блокчейне (или что-то навроде того).
ECC ASIC уже существуют и довольно дешевы. Производство начинать не надо. На CPU эти ASIC вообще не нужны, т.к. проверка на компьютере прозрачна (занимает наносекунды) и только сайнинг занимает время.
Как я уже сказал, я только продумывал эту идею пару раз. Но нет времени развернуть в полную.
Но это реально и реально лучше чем текущая ситуация.
Каждый человек бы мог иметь уникальный адрес. Каждая муха, каждый атом.
equand
22.10.2017 17:59К тому же, будьте уверены, что сначала накрутился софт, а потом под них делались ASIC, а не наоборот.
khim
22.10.2017 18:32Это был итеративный процесс. Вначале создали TCP/IP с кучей плюшек, а потом его безжалостно порезали, чтобы засунуть в ASIC. Примерно с середины 80х (грубо говоря с момента появления CISCO) «рулят процессом» возможности железа.
equand
22.10.2017 19:34Ну так, никто не предлагает внедрить это сейчас. Хотя по сути, если есть решение всех проблем разом, почему бы и нет? Как я уже писал выше, если проитерировать и разработать протокол, было бы отличным решением от домашних ПК и принтеров до международных мультитерабитных рутеров.
Рано или поздно мы упремся в 2^64 количество рутов в V6. Это может случиться рано. http://bgphelp.com/2017/01/01/bgpsize/ в 19 году уже большинство провайдеров получат проблемы.
Bitcoin решил не только проблему генералов, он решил и проблему рутинга и проблему адресации. Весь этот легаси делали т.к. не было в то время такого решения. По сути БГП нужен только потому что мы не знаем, кто где что объявил своим. Для этого же нужен и локальный рутер/свитч. Для идентификации владельца. Вот только при использовании не криптографически безопасных функций мы приходим ко всяким PVLAN, портлокерам и тому подобному груздю для защиты L2 и всяким БГП, ОСПФ и тому подобному для поддержки L3 и хуже всего центральным авторитетам для поддержки IPv4, IPv6.
Представьте мир, где подключение происходит не по синакам, а по мультиподписанной транзакции с определенной длиной сессии, которая может обновляться (да подсмотрел в лайтнинге) (переносные сессии по всему миру? их есть у меня!). Где каждый может сгенерировать свой адрес и подключить его к глобальной сети хоть через радио сигнал на улице, хоть дома, главное иметь токен.
Да тут такое навернуть можно, Сатоши ох**ет.
eov
22.10.2017 20:43Рано или поздно мы упремся в 2^64 количество рутов в V6. Это может случиться рано. bgphelp.com/2017/01/01/bgpsize в 19 году уже большинство провайдеров получат проблемы.
Проблемы мы получим уже в 2018 из-за РКН, который день и ночь трудится над реестром… Из-за этого IPv4 таблица уже получила не малый прирост… Страшно представить что будет с IPv6 таблицей когда в ней начнут появляться IPv6 ресурсы из реестра…equand
22.10.2017 23:01Да, с Блокчейном заблокировать будет нереально, т.к. ендпоинты будут создавать каналы для связи, вместо постоянно активного адреса.
eov
23.10.2017 08:09Ну, если процессинг будет на региональных площадках КГБ, а в каждом пакете будет ФИО или СНИЛС, то об этом в нашей стране еще можно помечтать. В проивном случае, ни один оператор на получит «одобрям» от КГБ и легально работать не сможет. Про реализацию «3-ей Яровой» и подумать страшно. Боюсь, что на него не хватит и всего НАТО-овского бюджета на несколько лет.
equand
23.10.2017 11:19Канальный процессинг все еще возможен, к сожалению (если не использовать SSL/TLS), т.к. можно найти какие адреса подписали канал и уже оттуда искать где этот канал используется по канальным данным. Хотя я уверен возможен способ установления секретных анонимизированных каналов без SSL/TLS, он скорее всего, к сожалению, будет чересчур дорогим (как монеровские транзакции).
Однако для того, чтобы знать, куда уходит траффик, нужно знать обе стороны канала — а это уже сложно, потому что обе стороны будут псевдонимизированы.
Записывать каналы они смогут, но с внутренним шифрованием это будет бессмысленно.
qw1
22.10.2017 21:41переносные сессии по всему миру? их есть у меня
Зачем так сложно? При прочтении статьи на проблему смены IP между точками у меня возникла простейшая идея:
Если клиент меняет IP, то операционная система клиента знает об этом. Она посылает специальный пакет на сервер с оригинальным адресом/портом, на котором подключение инициировалось и с новым, текущим, (для безопасности можно добавить начальный SeqNo или любую другую куку, чтобы соединение не увели злые хакеры))), и сервер перебиндивает свой сокет на новый адрес и отправляет подтверждение на новый адрес (чтобы, если пакет смены адреса не дошёл до сервера, можно было переотправить его по тайм-ауту).
И всё, для TCP-соединений нужет только небольшой хак ОС клиента и сервера, для приложений будет полностью прозрачно.
Для UDP-соединений, конечно, чуть сложнее — приложение должно получить от OS событие смены IP и самостоятельно отправить серверу такой пакет, а серверный софт сам должен поправить IP-адрес клиента в своих таблицах соединений.equand
22.10.2017 23:23Это Ваше предложение прям горит лампочкой easyMitM
qw1
23.10.2017 20:35Да ну сделать это только для SSL-соединений и шифровать пакет смены адреса ключом сессии. Взлом будет равносилен взлому SSL. Хотя, это убивает красивую идею сделать всё силами tcp-стека или ОС, не меняя приложения.
firk
22.10.2017 12:53Статья несколько сумбурная и с водой. Практически всё то, что он ставит в минусы имеющихся протоколов (IPv4 ARP TCP итд) — элементарно исправляется без затрагивания самих протоколов, сменой алгоритмов работы сетевого железа (возможно тут и нет преимущества по деньгам перед ipv6, но тут не ломается глобальная совместимость с остальным интернетом).
Я тоже не понимаю зачем писать адрес шлюза в виде ip-адреса, а не mac-ом и зачем вообще эмулировать шину на современном железе, где её фактически нет. Но вот например решение, которое практически убирает эти ненужные детали, не ломая никаких совместимостей: вся сеть предприятия логически организуется как один диапазон, в прошивку свитчей встраивается ARP-заглушка, чтобы отдавать хоть какой-то ответ на запросы от клиентов, а весь реальный роутинг делается по полям адреса IP-заголовка. При этом с вопросами типа "где шлюз", "куда слать пакеты для внешнего инета" разберётся уже сам апгрейднутый свитч, не грузя этим клиентские устройства и не генерируя лишние броадкасты. MAC-адреса при этом можно (но не обязательно) использовать свитчами для автоконфигурации клиентов, игнорируя и заменяя заглушками большую часть DHCP-протокола, а так же для дополнительного небольшого слоя безопасности, если надо.
При этом изменить надо только прошивку сетевого железа (да, это может быть затратно), а всё остальные железки могут продолжать, что находятся в традиционой IPv4-сети и ничего не заметят.Kib0rg Автор
22.10.2017 14:13Про IP адрес маршрутизатора в роут-таблице, в целом, вопрос понятный: чтобы не перенастраивать всю сеть при замене роутера. Конечно, при наличии DHCP это можно теоретически автоматизировать, но это гораздо сложнее, чем всегда указывать какой-то фиксированный адрес из диапазона, например первый.
Про ethernet — он сильно врос в IPv4. Избавляться от заголовков ethernet только ради избавления, рискуя сломать себе сеть, потратив деньги и ничего не получив взамен, никто не будет.
В вашей схеме не решен, по крайней мере, вопрос нехватки адресов v4, а также непонятен профит в материальном выражении для организации от замены всех сетевых железок на другие.firk
22.10.2017 14:36Про IP адрес маршрутизатора в роут-таблице, в целом, вопрос понятный: чтобы не перенастраивать всю сеть при замене роутера.
Так речь как раз о том, что "всей сети" этот адрес вообще не нужен. Для включённого в порт компьютера есть "адрес маршрутизатора" — он шлёт пакеты в подключённый к нему кабель, а куда они пойдут дальше — уже должно быть делом свитча. Но вместо этого работает legacy-схема где свитч эмулирует шину с кучей неструктурированных участников, по которой они договариваются самостоятельно с использованием ненужных по сути протоколов.
Избавляться от заголовков ethernet только ради избавления, рискуя сломать себе сеть, потратив деньги и ничего не получив взамен, никто не будет.
Ну да.
В вашей схеме не решен, по крайней мере, вопрос нехватки адресов v4,
Да, это был ответ на статью, в которой рассказывается про некоторые другие "проблемы", кроме адресов.
а также непонятен профит в материальном выражении для организации от замены всех сетевых железок на другие.
Например можно немного сэкономить те же адреса, не выделяя их на адреса сеетй, броадкасты и адреса маршрутизаторов. А так же такая система по-моему работает более прозрачно.
Kib0rg Автор
23.10.2017 02:28Так речь как раз о том, что «всей сети» этот адрес вообще не нужен
зачем писать адрес шлюза в виде ip-адреса, а не mac-ом
Я вот на это отвечал в том фрагменте, в остальном согласен.
Например можно немного сэкономить те же адреса, не выделяя их на адреса сеетй, броадкасты и адреса маршрутизаторов. А так же такая система по-моему работает более прозрачно.
Про прозрачность понятно, хотя и несколько спорно, т. к. в том, как работают сети сейчас, разбирается любой более-менее квалифицированный админ, а вот сеть описанного вида может привести в негодность шаблон коллеге. А сэкономленных адресов получается слишком мало чтобы решить даже краткосрочные проблемы в случае их нехватки, уж проще NAT заиспользовать. А уж если менять всё сетевое оборудование — так на поддерживающее IPv6, тем более что другого, по-моему, на рынке нет уже лет так с десяток.
scruff
22.10.2017 13:15+1Сетевые операторы попросту выбирают bridging vs routing, опираясь на то, насколько быстро они хотят чтобы он работал и насколько сильно они ненавидят настройку DHCP серверов, которую они на самом деле ненавидят очень сильно, что означает что они используют мосты настолько, насколько это возможно и маршрутизацию — когда им приходится.
Не подскажете почему операторы именно так и делают, хотя я слышу об этом впервые. И почему так сильно нелюбим DHCP?Kib0rg Автор
22.10.2017 13:51Не знаю, что именно подразумевал автор, но, возможно, имелось в виду что-нибудь из следующего:
— один общий DHCP настроить и поддерживать проще, чем по серверу на каждый сегмент сети
— каждый сервер требует настройки диапазона адресов, как этим рулить?
— вопрос про отказоустойчивость и резервирование DHCP
— бесшовность сети невозможна или сильно осложнена при переходе клиента между сегментами сети
— возможно, что-то ещё, о чем я забыл или не знаюscruff
22.10.2017 18:32Скорее 4-й ну и.....5-й пункты играют основную роль, т.к. первые три, в большинстве своём, осуществимы (DHCP-relay и DHCP HA уже давно существуют)
alex7
22.10.2017 13:15В биологии считается, что на коротких промежутках времени естественный отбор отбирает самых приспособленных к текущим условиям. Но на длинных — работает на увеличение скорости эволюции. С данными протоколами главная проблема не в том, что они перестали соответствовать современному миру, а в сложности их замены.
firk
22.10.2017 13:23Любой основополагающий широко используемый протокол будет сложно заменить (это про IP). А всякие надстройки над ним, о которых сокрушается автор, заменить очень легко, но никому обычно не нужно — всё и так работает.
duger
23.10.2017 23:48Теперь представим, что X меняет адрес на Q. Он всё ещё посылает пакеты с тэгом (uuid,80) на IP адрес Y, но теперь эти пакеты приходят с адреса Q. Машина Y получает этот пакет и сверяет его с сокетом, ассоциированным с (uuid), замечает, что пакеты для этого сокета теперь приходят с адреса Q и обновляет кэш. Теперь пакеты в обратную сторону могут быть отправлены, с тэгом (uuid), в сторону Q вместо X. Всё работает! (С учётом мер, необходимых для предотвращения атак самозванцев).
Хорошо жить в таком мире, где любая сетевая коммуникация — это всегда запрос-ответ со стороны мобильного устройства. Односторонний поток данных с сервера на клиента? Не, не слышал.Kib0rg Автор
23.10.2017 23:59А как вы узнаете адрес клиента для отправки данных до смены им IP адреса без коммуникации со стороны клиента?
Pave1
24.10.2017 14:14ИМХО все эти идеи избавиться от второго уровня — это ошибка. Уровни заложены точно не зря. Проблема не в «лишних слоях». Проблема в убогости и древности именно самой технологии ethernet и ее обвязки с выше стоящим уровнем. Вместо того, чтобы поставить на ней крест и создать нормальную технологию с нуля, полутруп пихают стеройдами и надстраивают костыли, вроде stp, dcb, trill и т.д.
firk
24.10.2017 16:25А что вы хотите от ethernet? Свою задачу — передавать цифровые пакеты по витой паре либо по оптоволокну (это как минимум две разные технологии, кстати) между двумя портами — он выполняет нормально. И ничего большего, кажется, не требует. Всё остальное — софт на устройствах с этими портами.
eov
Не совсем понял к чему была фраза «Как заставить мобильные сети работать»…
Может оно и так, но CGNAT-тилка на несколько миллионов одновременно работающих мобильных абонентов стоит не малых денег, которые в итоге добываются с абонентов. А если этой NAT-илке не дать достаточное количество public IPv4 адресов на out, то некоторые ресурсы (к примеру Google) начинают воспринимать большое количество соединений с одного IPv4 как атаку. C IPv6 такой проблемы нет. Думаю, что большая популярность IPv6 в мобильных сетях в USA получилась не просто так. Все больше и больше развиваются сервисы доставки видео контента как по проводам, так и по воздуху. На IPv6 они работают весьма не плохо даже с учетом задержек в сотовых сетях и за вычетом задержки, вносимой NAT-ом. Тут были статьи, из которых веяло нежеланием админов разбираться с IPv6 (типа «только в мою смену мы будем его внедрять»), но мне хочется верить, что этот паровоз в итоге поедет и чем дальше, тем быстрее.askv
Статья скорее про ущербность TCP чем про достоинства IPv6.
Loiqig
Насколько я понял автора, он говорит о принципиальной возможности такой работы, т.е. если не обращать внимание ни на количество IPv4 адресов ни на цену оборудования. IPv6 должен был склеить вместе L2 и L3 чего не получилось и видимо не получится, он используется по сути как расширялка адресного пространства IPv4 и Ethernet одновременно, ни больше ни меньше, весь заложенный потенциал пошёл прахом — о чём автор и сожалеет.
За перевод спасибо — просто песня!