Комментарии 59
выясняется, что ничего в этом разделе не требует IPv6. Всё работало бы и с IPv4 через NAT, даже роуминг через несколько NAT-ов.Может оно и так, но CGNAT-тилка на несколько миллионов одновременно работающих мобильных абонентов стоит не малых денег, которые в итоге добываются с абонентов. А если этой NAT-илке не дать достаточное количество public IPv4 адресов на out, то некоторые ресурсы (к примеру Google) начинают воспринимать большое количество соединений с одного IPv4 как атаку. C IPv6 такой проблемы нет. Думаю, что большая популярность IPv6 в мобильных сетях в USA получилась не просто так. Все больше и больше развиваются сервисы доставки видео контента как по проводам, так и по воздуху. На IPv6 они работают весьма не плохо даже с учетом задержек в сотовых сетях и за вычетом задержки, вносимой NAT-ом. Тут были статьи, из которых веяло нежеланием админов разбираться с IPv6 (типа «только в мою смену мы будем его внедрять»), но мне хочется верить, что этот паровоз в итоге поедет и чем дальше, тем быстрее.
За перевод спасибо — просто песня!
с использованием двух 64-битных IP адресов
Ээ, что? В какой вселенной они 64-битные?
И если порт разумно оставить, то протокол не нужен.
Плюс из заголовка дропнуто всё связанное с фрагментацией.
И совместимость элементарная, делаем к ipv4 адресу стандартный префикс, например нули.Проблема в том, что «элементарная совместимость» работает строго не в ту строну: можно поверх IPv6 сетей (которых нет) запускать IPv4 траффик (который есть и отлично работает в сетях IPv4).
В обратную сторону ваше предложение не работает, однако.
Если бы какой-нибудь ipv5 банально расширил адресное пространство, уже все давно бы мигрировали и забыли о ipv4.Серьёзно? Вот приходите вы, весь такой в белом, и говорите руковождству: а давайте внедрим поддержку IPv5 во все наши операционки, программы и прочее. Главное — заменить все дорогущие железные роутеры. А на резонный вопрос «а науха?» вы отвечаете «ну прямо сейчас это никому ничего не даст, но когда все прейдут на
Как вы думаете, каков будет ответ? Возможные варианты, которые приходят мне в голову:
- А не выпить ли тебе чего-нибудь от ...?
- А не пошёл бы ты в ...?
- А на пошёл бы ты на ...?
- Ну или чего-нибудь в этом духе...
Любая замена IPv4 упиралась в одну и ту же вещь: затраты нужны прямо сейчас, а выиграш будет неизвесно когда. Хоть IPv6, хоть IPv7 (номер под IPv5 занят, потому IPv5 лучше не пытаться использовать).
На самом деле всё прошло ровно так, как мудрые люди говорили умным: не парьтесь вы и не пытайтесь «дать больше времени на переход» — все ваши попытки только лишь затянут начало этого процесса и сделают его более болезненным.
И, собственно, переход на IPv6 внедряется ровно столько времени, сколько его нужно внедрять. Как рак на горе свистнул — так и начали. И довольно-таки бодренько. А всё, что было до того — предистория.
Глубокоуважаемый автор предлагает строить еще одну конструкцию, эпичнее не взлетевшей предыдущей.Отнюдь. Он предлагает заменить TCP на другой протокол, QUIC — но эта замена не требует замены инфраструктуры и потому её можно внедрить [относительно] малой кровью — примерно как внедряли HTTP/2.
Не надо ничего расширять. Не знаю почему, но 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.
Провайдеры же со своей стороны не готовы доставлять клиентам такие неудобства и тратить заранее приличные суммы денег на апгрейд оборудования с непонятным профитом, пока адреса v4 не когчились.
Ок, использовать 802.1q который с 2003 в поддержке везде. Тогда получается 3 байта на source и 3 байта на destination. Еще больше IP, как раз догнали IPv6 /48. Да и запись упрощается.
Хоте честно говорят все это полное Г.
IPv6 строился без понимания глобального рутинга, в котором как раз и проблема.
Поэтому имхо нужна замена БГП блокчейном. Тогда сможем избавиться от региональных раздавателей и интернет будет более устойчивым к атакам и ошибкам нежели сейчас. Прелесть правильно составленного блокчейн протокола в том, что он будет скалироваться от локальной сети к глобальной без проблемы.
Вы немного не поняли. Я предлагаю блокчейн маршрутизацию на уровне железа. Допустим домашние ноды SPF ноды с локальной верифицирующей нодой рутера. Обмануть рутер невозможно, т.к. мы используем пару паблик-прайват ключей между рутерами с сабключами для устройств под рутером. Пакеты шифруются сабключем.
В этом случае сетевая инфраструктура непоколебима между доверенными устройствами. Маршрутизация происходит по каналам зарегистрированным выполненной работой (сложность работы позволяет регулировать скорость работы сети и сложность MITM с потерянным сабключем)
Прелесть всего этого в отсутствии необходимости в IP в целом. Непоколебимости при взламывании.
Идея не полностью додумана, но по сути мы упрощаем кучу сложностей текущих сетевых технологий.
Ринг-топология с 1000 в 1000 q-in-q? Весь этот шлак ненужен когда в пакетах только данные "канал" "нонс" "тело пакета" и это шифровано сабключем.
Я пока еще не думал об этом полностью, но БГП тоже можно загнать в подобную топологию, где пиринг это "канал" между верхними рутерами.
Адепты блокчейнов добрались и сюда.
Прелесть всего этого в отсутствии необходимости в IP в целом.
А если написать программу для выполнения операций сложения и прочей арифметики, то можно будет делать компы без процессоров и с этой программой вместо них.
Нет почему же. Проблема Византийских генералов всегда присутствовала в обмене информации. Блокчейн решает ее до 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 не похож на мемпул? :)
Вы немного не понялиПочему же? В p2p-сети у каждой ноды есть адрес (обычно, рандомное число 128-512 бит), и таблица маршрутизации (сделанная через DHT), мапящая этот адрес на IP-адрес, чтобы любая нода p2p-сети могла найти другую ноду по p2p-id и послать сообщение.
Т.е. всё равно придётся реализовывать сетевой уровень, чтобы на нём сделать блокчейн, а на котором будет IP-сеть )))
Не обязательно!
Как я уже писал выше в посте https://habrahabr.ru/post/340626/?reply_to=10485286#comment_10485368 проблема византийских генералов присутствует всегда. В LAN она решается через выбор "кто рутер". В WAN выбор "с кем пирится, кто транзитит". Всегда выбирается авторитет. Вот только секьюрность авторитетности ничем не доказывается. В WAN WIFI такая проблема присутствует например. С блокчейном сибил атака как на WPA2 недавно была бы невозможна, потому что цепочка длинее и с большей работой выиграла бы, чем хакерская с меньшей работой и короткой историей.
Как обойти другие неприятности можно было бы проработать, сейчас к сожалению нет на это времени.
Я же и предлагаю переделать L2. Сейчас каналы связи все равно устанавливают L2 соединение по физическому лейеру. И с него начинается наша матрешка лейеров. Как я уже писал выше можно начать с Layer 2, то что ближе к железу. Сделать авторизацию (открытие L2 канала по физическому уровню) через обмен ключей и синхронизацию локального блокчейна каналов (адреса неизвестны, ВАУ! +1 к приваси). Вариации с публичным/приватным ключом скажут мастер ноде об уровне физического доверия к системе (аля L2 port locking, только куда более секьюрным чем ARP+MAC+IP). И все — 90% текущих сетевых проблем ушло. Прочесть чужой канал невозможно, т.к. пакеты либо зашифрованы аппаратно (если есть TLS или AES), либо адресат его читает по зашифрованному нонсу, ключ шифра которого знает только он и открыватель канала, потому что обмен нонса был в шифрованном виде (или вообще в оффлайне) (допустим у нас хаб, или бридж и все видят траффик друг друга). Нонса два и они всегда обновляются.
Получается мы так можем выкинуть огромную часть L2 и L2/L3 мусора. Остаются только части для работы над потерями.
— протокол чейна, установление каналов, шифрование,
— поверх того, что получилось, гонять IP.
Это будет очень дорого, если каждый свич/роутер будет жужжать как топовый bitcoin-ASIC.
Нет. IP вообще не гонять, он больше не нужен будет. Для соединения нам надо будет создавать каналы с адресами.
Каждому свичу и рутеру не нужно будет быть биткоин асиком.
Количество работы будет определяться необходимым уровнем безопасности в сети. Например в локальной сети дома вообще работа не нужна будет, т.к. дома без проблем вместо IP адресов можно ввести сабключ и возможность взлома только в случае, если кто-то получить мастер-приватный-ключ. Но только у Вас тогда проблемы посерьезнее. В СМБ и интерпрайзе абсолютно такой же подход. Сверху-вниз там вполне ок.
А вот в интернете с БГП, который каждый может оверлоадить или перезаписать это конечно плохо, что работа не выполняется. Соответственно там уже блокчейн работает напрямую. НО работа выполняется для поддержания каналов рабочими. Как я уже говорил транзакция с отложенной датой реализации = канал. Прелесть в том, что токены заложенные в эти транзакции и будут криптовалютой автоматически по завершении транзакции оплачивающие работу канала. Принцип работы схожий с лайтнинг нетворком. Для создания канала объявляется транзакция на обмен 50/50 токенов. Которые в случае не оплаты схлопывается без продления, так что обе стороны должны прийти к согласию в чью сторону перейдут токены по окончании работы канала.
В итоге два или несколько пиринг партнера, желающих заключить договор просто подключаются L1 к друг другу. Заверяют консенсус обменом сабключами, для создания L2 соединения. Объявляют транзакцию в мем пул, мем пул канал-транзакция заверяется шахтерами соединенными единой L2 сетью и отправляется другим участникам L2 обмена (между всеми способными содержать всю БД блоков (фулл нодами) и шахтерами (которые по умолчанию фулл ноды) любой участник обмена может быть шахтером). После создания канала, они используются для соединения.
Как видите в этой схеме не нужны асики на каждой системе. Да и не обязательно использовать такие асики, можно реализовать proof-of stake или если страх жирных рук получающих 51% реализовать proof-of-bandwidth тогда проблемы вообще не будет ибо это именно то что нужно сетевым операторам. Реализовать ее на L2 уровне и при поддержке железа довольно просто.
К тому же можно уйти с заверения блоков, и заверять конкретные каналы.
Много решений, голова кипит, но это было бы лучшим решением, если реализовать верно.
реализовать proof-of-bandwidthЗабивать каналы, вместо того, чтобы жечь CPU?
это было бы лучшим решением, если реализовать верноСкорее, мы бы получили на ровном месте кучу других проблем. Начиная с банальной «теперь всех сетевых инженеров надо заменить к.т.н. по теории чисел, чтобы они смогли отдебажить непонятные глюки в сети, ведь всё теперь зашифровано».
И заканчивая DoS-атаками на блокчейн (или транзакции сделать платными? Тогда можно будет
Не понимаю, зачем оперативной информации блокчейн. Тут же нет задач узнать, а какой роут был 100 лет назад до подсети, которая сейчас уже в другой город переехала.
Если хочется децентрализации, достаточно базы с записями вида <порядковый номер, роут>, подписанными ключом владельца адреса. И записи с большим порядковым номером безальтернативно замещают предыдущие записи, и консенсус не нужен.
Вы видимо не до конца понимаете концепт.
Насчет pob да, что-то должно тратиться для увеличения стоимости атаки. Либо делать proof of connectivity, но это тоже чревато. В крайнем случае Proof of stake
Сетевикам наоборот работы меньше, ибо вместо матрешки им разбираться только с последовательными каналами.
Транзакция открывает канал, транзакция платная, переводы в канале бесплатны. То бишь ддосер чтобы совершить атаку должен будет заплатить дохрена. Иначе он просто откроет простой канал за типичную стоимость. В наше время ддос почти бесплатен.
Блокчейн не храниться ради истории, Вы видимо не понимаете необходимости блокчейна. Да если бы историю можно было бы убрать ее б давно уже убрали. В начале истории биткоина полная история транзакций была одним из камней преткновения. К сожалению способа избавиться от нее, не потеряв точную уверенность владения, не нашли пока что.
Блокчейн в данном случае будет регистрировать сделки пиринга и транзита на самом низком уровне между ISP. Им история понадобится. А если не понадобится от нее можно избавиться соглашением (голосованием нод), аля purge и перерегистрация с такого-то блока при 90% консенсусе.
И в принципе не обязательно фулл хистори хранить, достаточно хранить только что релевантно, а остальное можно хранить только то, что имеет смысл (аля purge в биткоине).
Нет. IP вообще не гонять, он больше не нужен будет. Для соединения нам надо будет создавать каналы с адресами.Поверх которых будет IP, потому что «уровни абстракции только добавляются, но никогда не исчезают» ))
Идея не полностью додумана, но по сути мы упрощаем кучу сложностей текущих сетевых технологий.Вау, как круто. А вы не забыли про главное, фундаментальное, ограничение, вокруг которого «накручивается» всё остальное в глобальных сетях?
Оно, в общем-то, очевидно даже третьекласснику (но адепты блокчейна, о нём, по всей видимости, не подозревают).
Посмотрите на карту мира. Что вы там видите? Правильно: материки. А между ними — океаны. На материках живут сотни миллионов людей — на каждом. А «ниточек», связывающих оные материки — десятки, в лучшем случае — сотни. Дорого потому что очень.
Соответственно на этих магистралях речь идёт о сумасшедших, звучащих почти фантастически, скоростях — сегодня речь идёт десятках и сотнях терабит в секунду.
Соответственно все сетевые технологии вынуждены учитывать то, что роутеры не могут быть умными. Всякие разные вспомогательные таблицы — могут быть сложными и хитрыми, но обработка пакетов должна происходить в железе.
Потому и всякие хитные схемы с использованием опциональных полей в IPV4 заголовка и многое другое провалилось. Магистральные роутеры — невероятно умны и тупы одновременно.
У них есть «умная» часть, которая не работает с индувидуальными пакетами (но может себе позволить работать с шифрованием и прочим), и «тупая» — то, что непосредственно пересылает пакеты не задействуюне то, что сложную математику, но даже CPU.
А вот теперь, когда мы обсудили фундаментальную проблему глобальных сетей — можно обсуждать как блокчейн её решать будет.
Да я в курсе как это работает. Каждый день с этим работаю. Спасибо за ELI5 switching/routing ASIC.
И да это тоже можно учесть, как я уже говорил через subchain и subchannels.
В итоге вместо проверки в forwarding таблице, checksum и туевой хучи компонентов каждого пакета ASIC придется проверять только ключи инкрементального нонса каналов во внутреннем блокчейне (или что-то навроде того).
ECC ASIC уже существуют и довольно дешевы. Производство начинать не надо. На CPU эти ASIC вообще не нужны, т.к. проверка на компьютере прозрачна (занимает наносекунды) и только сайнинг занимает время.
Как я уже сказал, я только продумывал эту идею пару раз. Но нет времени развернуть в полную.
Но это реально и реально лучше чем текущая ситуация.
Каждый человек бы мог иметь уникальный адрес. Каждая муха, каждый атом.
К тому же, будьте уверены, что сначала накрутился софт, а потом под них делались ASIC, а не наоборот.
Ну так, никто не предлагает внедрить это сейчас. Хотя по сути, если есть решение всех проблем разом, почему бы и нет? Как я уже писал выше, если проитерировать и разработать протокол, было бы отличным решением от домашних ПК и принтеров до международных мультитерабитных рутеров.
Рано или поздно мы упремся в 2^64 количество рутов в V6. Это может случиться рано. http://bgphelp.com/2017/01/01/bgpsize/ в 19 году уже большинство провайдеров получат проблемы.
Bitcoin решил не только проблему генералов, он решил и проблему рутинга и проблему адресации. Весь этот легаси делали т.к. не было в то время такого решения. По сути БГП нужен только потому что мы не знаем, кто где что объявил своим. Для этого же нужен и локальный рутер/свитч. Для идентификации владельца. Вот только при использовании не криптографически безопасных функций мы приходим ко всяким PVLAN, портлокерам и тому подобному груздю для защиты L2 и всяким БГП, ОСПФ и тому подобному для поддержки L3 и хуже всего центральным авторитетам для поддержки IPv4, IPv6.
Представьте мир, где подключение происходит не по синакам, а по мультиподписанной транзакции с определенной длиной сессии, которая может обновляться (да подсмотрел в лайтнинге) (переносные сессии по всему миру? их есть у меня!). Где каждый может сгенерировать свой адрес и подключить его к глобальной сети хоть через радио сигнал на улице, хоть дома, главное иметь токен.
Да тут такое навернуть можно, Сатоши ох**ет.
Рано или поздно мы упремся в 2^64 количество рутов в V6. Это может случиться рано. bgphelp.com/2017/01/01/bgpsize в 19 году уже большинство провайдеров получат проблемы.
Проблемы мы получим уже в 2018 из-за РКН, который день и ночь трудится над реестром… Из-за этого IPv4 таблица уже получила не малый прирост… Страшно представить что будет с IPv6 таблицей когда в ней начнут появляться IPv6 ресурсы из реестра…
Да, с Блокчейном заблокировать будет нереально, т.к. ендпоинты будут создавать каналы для связи, вместо постоянно активного адреса.
Канальный процессинг все еще возможен, к сожалению (если не использовать SSL/TLS), т.к. можно найти какие адреса подписали канал и уже оттуда искать где этот канал используется по канальным данным. Хотя я уверен возможен способ установления секретных анонимизированных каналов без SSL/TLS, он скорее всего, к сожалению, будет чересчур дорогим (как монеровские транзакции).
Однако для того, чтобы знать, куда уходит траффик, нужно знать обе стороны канала — а это уже сложно, потому что обе стороны будут псевдонимизированы.
Записывать каналы они смогут, но с внутренним шифрованием это будет бессмысленно.
переносные сессии по всему миру? их есть у меняЗачем так сложно? При прочтении статьи на проблему смены IP между точками у меня возникла простейшая идея:
Если клиент меняет IP, то операционная система клиента знает об этом. Она посылает специальный пакет на сервер с оригинальным адресом/портом, на котором подключение инициировалось и с новым, текущим, (для безопасности можно добавить начальный SeqNo или любую другую куку, чтобы соединение не увели злые хакеры))), и сервер перебиндивает свой сокет на новый адрес и отправляет подтверждение на новый адрес (чтобы, если пакет смены адреса не дошёл до сервера, можно было переотправить его по тайм-ауту).
И всё, для TCP-соединений нужет только небольшой хак ОС клиента и сервера, для приложений будет полностью прозрачно.
Для UDP-соединений, конечно, чуть сложнее — приложение должно получить от OS событие смены IP и самостоятельно отправить серверу такой пакет, а серверный софт сам должен поправить IP-адрес клиента в своих таблицах соединений.
Я пока не собрался с мыслями как это сделать, я здесь в комментариях просто спекуляцию описал. Но это возможно!
Как я уже говорил в IP сетях точно такая же проблема масштабируемости, но из-за структуры IPv4 и IPv6 сетей она не скалируема в принципе. Что будет если дозволят /25 рутинг, /26, /30? А в IPv6 /96? В БГП выгружается фулл тейбл, чтобы оптимизировать руты. Сколько рутеров выдержат его при таких изменениях?
Конечно п2п сети имеют свои проблемы, но в дальнейших комментах я сузил проблемы используя доминантные системы в L2 на нижнем уровне (саб ключи от рутеров для подписания каналов в локальных сетях, только рутеры рулят всем), таким образом грубо говоря (очень очень грубо) мы будем иметь обычные ПК в виде lightweight нод, которые работают только в локальной криптосети, в которой блокчейн не нужен в принципе (достаточно ключей и обмен ключей) или же можно сделать блокчейн для платежа за ресурсы (выдача ключа = IP, за это надо "заплатить") или даже дуальную сеть (те кто используют сабключи введеные заранее не платят, те кто не имеют — платят).
Дальше проблема у меня с каналами, механизм установки локального канала и анонса его установлен. Вопрос в propagation — распространении и оптимизации этого дела.
Между клиентом и ISP должна быть блокчейн связь, чтобы была оплата и соответственно ISP передает каналы далее согласно контракту (правильно, multisig с расписанными правилами передачи канала). Между ISP и ISP тоже должна быть связь подобного рода. L2 легко решается, L3 и рутинг поверх пока еще не разобрался в конец, не было времени подумать.
Статья несколько сумбурная и с водой. Практически всё то, что он ставит в минусы имеющихся протоколов (IPv4 ARP TCP итд) — элементарно исправляется без затрагивания самих протоколов, сменой алгоритмов работы сетевого железа (возможно тут и нет преимущества по деньгам перед ipv6, но тут не ломается глобальная совместимость с остальным интернетом).
Я тоже не понимаю зачем писать адрес шлюза в виде ip-адреса, а не mac-ом и зачем вообще эмулировать шину на современном железе, где её фактически нет. Но вот например решение, которое практически убирает эти ненужные детали, не ломая никаких совместимостей: вся сеть предприятия логически организуется как один диапазон, в прошивку свитчей встраивается ARP-заглушка, чтобы отдавать хоть какой-то ответ на запросы от клиентов, а весь реальный роутинг делается по полям адреса IP-заголовка. При этом с вопросами типа "где шлюз", "куда слать пакеты для внешнего инета" разберётся уже сам апгрейднутый свитч, не грузя этим клиентские устройства и не генерируя лишние броадкасты. MAC-адреса при этом можно (но не обязательно) использовать свитчами для автоконфигурации клиентов, игнорируя и заменяя заглушками большую часть DHCP-протокола, а так же для дополнительного небольшого слоя безопасности, если надо.
При этом изменить надо только прошивку сетевого железа (да, это может быть затратно), а всё остальные железки могут продолжать, что находятся в традиционой IPv4-сети и ничего не заметят.
Ну а потом, имея уже вышеописанный вариант сетевой инфраструктуры, можно постепенно и неторопясь вырезать из клиентов уже ненужный функционал типа ARP (если он беспокоит).
Про ethernet — он сильно врос в IPv4. Избавляться от заголовков ethernet только ради избавления, рискуя сломать себе сеть, потратив деньги и ничего не получив взамен, никто не будет.
В вашей схеме не решен, по крайней мере, вопрос нехватки адресов v4, а также непонятен профит в материальном выражении для организации от замены всех сетевых железок на другие.
Про IP адрес маршрутизатора в роут-таблице, в целом, вопрос понятный: чтобы не перенастраивать всю сеть при замене роутера.
Так речь как раз о том, что "всей сети" этот адрес вообще не нужен. Для включённого в порт компьютера есть "адрес маршрутизатора" — он шлёт пакеты в подключённый к нему кабель, а куда они пойдут дальше — уже должно быть делом свитча. Но вместо этого работает legacy-схема где свитч эмулирует шину с кучей неструктурированных участников, по которой они договариваются самостоятельно с использованием ненужных по сути протоколов.
Избавляться от заголовков ethernet только ради избавления, рискуя сломать себе сеть, потратив деньги и ничего не получив взамен, никто не будет.
Ну да.
В вашей схеме не решен, по крайней мере, вопрос нехватки адресов v4,
Да, это был ответ на статью, в которой рассказывается про некоторые другие "проблемы", кроме адресов.
а также непонятен профит в материальном выражении для организации от замены всех сетевых железок на другие.
Например можно немного сэкономить те же адреса, не выделяя их на адреса сеетй, броадкасты и адреса маршрутизаторов. А так же такая система по-моему работает более прозрачно.
Так речь как раз о том, что «всей сети» этот адрес вообще не нужен
зачем писать адрес шлюза в виде ip-адреса, а не mac-омЯ вот на это отвечал в том фрагменте, в остальном согласен.
Например можно немного сэкономить те же адреса, не выделяя их на адреса сеетй, броадкасты и адреса маршрутизаторов. А так же такая система по-моему работает более прозрачно.Про прозрачность понятно, хотя и несколько спорно, т. к. в том, как работают сети сейчас, разбирается любой более-менее квалифицированный админ, а вот сеть описанного вида может привести в негодность шаблон коллеге. А сэкономленных адресов получается слишком мало чтобы решить даже краткосрочные проблемы в случае их нехватки, уж проще NAT заиспользовать. А уж если менять всё сетевое оборудование — так на поддерживающее IPv6, тем более что другого, по-моему, на рынке нет уже лет так с десяток.
Не подскажете почему операторы именно так и делают, хотя я слышу об этом впервые. И почему так сильно нелюбим DHCP?
— один общий DHCP настроить и поддерживать проще, чем по серверу на каждый сегмент сети
— каждый сервер требует настройки диапазона адресов, как этим рулить?
— вопрос про отказоустойчивость и резервирование DHCP
— бесшовность сети невозможна или сильно осложнена при переходе клиента между сегментами сети
— возможно, что-то ещё, о чем я забыл или не знаю
Теперь представим, что X меняет адрес на Q. Он всё ещё посылает пакеты с тэгом (uuid,80) на IP адрес Y, но теперь эти пакеты приходят с адреса Q. Машина Y получает этот пакет и сверяет его с сокетом, ассоциированным с (uuid), замечает, что пакеты для этого сокета теперь приходят с адреса Q и обновляет кэш. Теперь пакеты в обратную сторону могут быть отправлены, с тэгом (uuid), в сторону Q вместо X. Всё работает! (С учётом мер, необходимых для предотвращения атак самозванцев).
Хорошо жить в таком мире, где любая сетевая коммуникация — это всегда запрос-ответ со стороны мобильного устройства. Односторонний поток данных с сервера на клиента? Не, не слышал.
Мир, в котором IPv6 придуман хорошо