Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 42
И все это добро сломает 10.0.0.0/8?
В каком смысле сломает? Имеете ввиду nat? Если да, то кто сидел за ним, так и будет сидеть.
У многих аппаратных решений до сих пор нет полной поддержки IPv6, а вы тут предлагаете очередной костыль для IPv4.
Половина транспорта — костыли. Но приходится с ними работать. Ну а о поддержке ipv6 — парк оборудования, с которым я работаю полностью его поддерживает, честно говоря давно не встречал оборудование, не поддерживающее ipv6 — во всяком случае на оборудовании операторского класса такой беды не наблюдал.
Не взлетит. Индустрия давно движется к dualstack. Для этого есть NAT44 + Native IPv6. Вряд ли эту отлаженную схему будут менять. 90% сервисов в ближайшие 10-20 лет мигрируют на IPv6, а IPv4 останется для совместимости старого софта.
Оглянитесь по сторонам: много вы видите сетей на базе IPX? А ведь лет 20 назад их было чуть ли не 90%.
Так и с IPv4. IPv4 вымрет — и довольно быстро. И примерно даже понятно когда.
После того, как пользователей с поддержкой IPv6 станет больше, чем пользователей без оной поддержки вложение станет элементарно невыгодно вкладывать деньги в поддержку IPv4 пользователей.
Какое-то время будет казаться, что «всё отлично, ведь web-сайты работают», чего ещё нужно? Но появится какой-нибудь очередной WhatsApp без поддержки IPv4 — и всё кончится.
Конечно предсказать заранее какой именно сервис запустит лавину нельзя, но так ли это важно в долгосрочной перспективе?
Так и с IPv4. IPv4 вымрет — и довольно быстро. И примерно даже понятно когда.
После того, как пользователей с поддержкой IPv6 станет больше, чем пользователей без оной поддержки вложение станет элементарно невыгодно вкладывать деньги в поддержку IPv4 пользователей.
Какое-то время будет казаться, что «всё отлично, ведь web-сайты работают», чего ещё нужно? Но появится какой-нибудь очередной WhatsApp без поддержки IPv4 — и всё кончится.
Конечно предсказать заранее какой именно сервис запустит лавину нельзя, но так ли это важно в долгосрочной перспективе?
Ситуация с ipv4 и ipx разная. ОС NetWare не выдержал конкуренции, да и устройств на этой ОС было на несколько порядков меньше чем сейчас IPv4. Останется множество телефонов, камер и других устройств, которые не получат обновление ПО с поддержкой IPv6 и оператор связи не сможет отказать такому клиенту лишь по причине «мы используем только IPv6». Трафик уйдет на новую версию — освободятся мощности для NAT — они и будут поддерживать совместимость без дополнительных вложений.
А зачем ему отказывать? Достаточно выкатить ценник подольше. Что, во многих случаях, произойдёт автоматом. Какой смысл провайдеру за свой счёт кому-то предоставлять сервис?
4G, скажем, требует IPv6, а стоимость килобайта там будет элементарно ниже. То же самое и в других случаях. А дальше — спираль начнёт сжиматься: поддержка «освободившихся мощностей для NAT'а» будет ложиться на всё меньшее число абонентов, что в свою очередь, заредёт цены ещё выше.
Не нравится пример с IPX — вспомните про модемные пулы. Принцип тот же: вначале «старая» технология становится «слегка дороже», потом ещё, а потом неожиданно и резко она становится вдруг «сильно дороже», после чего умирает.
Конечно речь тут идёт о годах, а не днях. Но очень сильно сомневаюсь что о десятилетиях. Скорее речь может идти о десятилетии — одном.
Подавляющее большинство устройств может быть поддержано «прозрачным proxy» на домашнем роутере — вот такой вариант, вполне возможно, будет жить ещё долго.
4G, скажем, требует IPv6, а стоимость килобайта там будет элементарно ниже. То же самое и в других случаях. А дальше — спираль начнёт сжиматься: поддержка «освободившихся мощностей для NAT'а» будет ложиться на всё меньшее число абонентов, что в свою очередь, заредёт цены ещё выше.
Не нравится пример с IPX — вспомните про модемные пулы. Принцип тот же: вначале «старая» технология становится «слегка дороже», потом ещё, а потом неожиданно и резко она становится вдруг «сильно дороже», после чего умирает.
Конечно речь тут идёт о годах, а не днях. Но очень сильно сомневаюсь что о десятилетиях. Скорее речь может идти о десятилетии — одном.
Подавляющее большинство устройств может быть поддержано «прозрачным proxy» на домашнем роутере — вот такой вариант, вполне возможно, будет жить ещё долго.
сложно согласиться. Между IPX и IP разница несколько иная, чем между IPv4 и IPv6. И сейчас хватает ПО, которое работает только на IPv6. Тот же DirectAccess, например. Что никак не мешает механизму инкапсуляции. Так что, как мне кажется, ПО тут роли особой не сыграет. Например, в службах кластера Hyper-V при трансляции содержимого оперативной памяти с ноды на ноду даже IP протокол не используется в качестве функционального.
Вся история перехода и с IPX на IPv4 и с IPv4 на Ipv6 описывается пресловутым закона Меткалфа.
Для одной IPX-сети Меткалфа действует, спору нет — но IPX-сети ограничены размером, автоматической маршрутизации нет, весь шарик ими не покроешь. Потому куча отдельных IPX-сетей очень быстро стали менее «полезны» чем одна, единая TCP/IP сеть.
Пока у IPv4 сетей были резервы (IP-адресов хватало) ни у какой другой технологии (EnIP, IPv6 или чего-нибудь ещё) шансов не было. Однако появление многослойных NAT'ов хотя и дало резервы для расширения сетей, но оный закон «сломало», причём кардинально. Исчерпание IP-адресов же фактически развите в смысле «полезности» заморозило вообще. Ни о какой «сети» в современном Интернете речи не идёт. Куча сервисов фактически перешла на топологию «звезда» — и «не от хорошей жизни».
IPv6 же, хотя и начал развиваться сильно позже, развивается примерно теми же темпами, что и IPv4 поначалу. Закон Меткалфа действует, хотя много организаций прилагают усилия, чтобы его ограничить. Когда IPv6 сеть станет «полезнее», чем IPv4 сеть, то она довольно быстро убьёт старую.
Но для того, чтобы это случилось нужно не просто ПО, которое работает поверх IPv6, а такое ПО, которое будет эффективнее работать при прямом соединении, а не при работе через сервера. DirectAccess — это круто, конечно, не только там никакой сети нет, фактически речь идёт о соединении точка-точка (хотя и поверх Интернета). Нужно ПО где будут устанавливаться прямые соединяние между клиентами (для тех или иных нужд). Только такое ПО сможет «проявить» закон Меткалфа и «убить» IPv4. Претендентов — вагон, но ясно, что 99% из них умрут. Но в то, что умрут все — я не верю.
Для одной IPX-сети Меткалфа действует, спору нет — но IPX-сети ограничены размером, автоматической маршрутизации нет, весь шарик ими не покроешь. Потому куча отдельных IPX-сетей очень быстро стали менее «полезны» чем одна, единая TCP/IP сеть.
Пока у IPv4 сетей были резервы (IP-адресов хватало) ни у какой другой технологии (EnIP, IPv6 или чего-нибудь ещё) шансов не было. Однако появление многослойных NAT'ов хотя и дало резервы для расширения сетей, но оный закон «сломало», причём кардинально. Исчерпание IP-адресов же фактически развите в смысле «полезности» заморозило вообще. Ни о какой «сети» в современном Интернете речи не идёт. Куча сервисов фактически перешла на топологию «звезда» — и «не от хорошей жизни».
IPv6 же, хотя и начал развиваться сильно позже, развивается примерно теми же темпами, что и IPv4 поначалу. Закон Меткалфа действует, хотя много организаций прилагают усилия, чтобы его ограничить. Когда IPv6 сеть станет «полезнее», чем IPv4 сеть, то она довольно быстро убьёт старую.
Но для того, чтобы это случилось нужно не просто ПО, которое работает поверх IPv6, а такое ПО, которое будет эффективнее работать при прямом соединении, а не при работе через сервера. DirectAccess — это круто, конечно, не только там никакой сети нет, фактически речь идёт о соединении точка-точка (хотя и поверх Интернета). Нужно ПО где будут устанавливаться прямые соединяние между клиентами (для тех или иных нужд). Только такое ПО сможет «проявить» закон Меткалфа и «убить» IPv4. Претендентов — вагон, но ясно, что 99% из них умрут. Но в то, что умрут все — я не верю.
если совсем формально подходить, то ПО работает на 4 уровне модели DOD и ему глубоко все равно, как будет доставлена информация до другого ПО на другом участнике сети. Главное, чтобы они нашли друг друга. Другими словами, у ПО есть функциональные требования и не функциональные требования. И отнести IP протокол к функциональным, на мой взгляд, никак нельзя. Это лишь средство транспорта. Т.е. все фишки IPv6 касаются лишь стороны соединения и функционирования соединения. Накладные расходы, которые уменьшает IPv6 и дополнительный функционал вполне реализуем и на IPv4.
И я, если честно, не уловил почему IPX не маршрутизируемый протокол? Создавайте подсети и настраивайте маршруты. Все будет бегать. По чуть иным условиям, но концепция точно такая же. Что же до ограничений размером, то это субъективно. Зависит не от размера шарика, а от количества потребителей. Когда-то и IPv4 казался неисчерпаемым. IPv6 хоть и имеет совершенно иные способности к масштабированию, тоже не бесконечен.
И я, если честно, не уловил почему IPX не маршрутизируемый протокол? Создавайте подсети и настраивайте маршруты. Все будет бегать. По чуть иным условиям, но концепция точно такая же. Что же до ограничений размером, то это субъективно. Зависит не от размера шарика, а от количества потребителей. Когда-то и IPv4 казался неисчерпаемым. IPv6 хоть и имеет совершенно иные способности к масштабированию, тоже не бесконечен.
И я, если честно, не уловил почему IPX не маршрутизируемый протокол?Потому что таким уж он сделан.
Создавайте подсети и настраивайте маршруты.Серьёзно? Как аналог BGP для IPX называется не подскажите?
Да, на базе IPX можно было бы сделать вполне современный протокол. Но… не сделали. Эту нишу занял IP.
Т.е. все фишки IPv6 касаются лишь стороны соединения и функционирования соединения. Накладные расходы, которые уменьшает IPv6 и дополнительный функционал вполне реализуем и на IPv4.Не реаализуются. Смысл закона Меткалфа — в том, что ценность сети зависит не от количества участников, а от количества потенциально возможных связей между ними, а это — квадрат количества участников. IPv4 интернет сейчас устроен как «ядро», мощность которого растёт как положено, квадратично (сервара) и «периферию» (оконечное оборудование), которое соединяется только с ядром.
мне кажется, вы не совсем понимаете разницу между маршрутизируемым протоколом, которым является IPX (и тот же IP) и протоколом маршрутизации, которых великое множество. Последний раз с IPX я работал в 95 году, поэтому вряд ли могу что-либо сообщить о нем, т.к. в 96 году все стремительно перешли на IP.
Мне кажется это вы не понимаете разницы между теорией и практикой. В теории свойства протокола могут влиять на что-то сами по себе, безотносительно к окружающей обстановке. На практите, увы и ах, но «короля играет свита».
IPX — более новый и потому более прогрессивный протокол. В частности адреса там 80-битные, так если бы, вдруг, в 90е годы выиграл IPX, то никакого болезненного перехода на IPXv6 бы не потребовалось.
Однако, увы и ах, к моменту, когда IP и IPX сети схлестнулись IP-сети были уже региональными и BGP был уже третьей инкарнацией соответствующих инженерных наработок (после GGP и EGP), а IPX сети застряли на RIP и EIGRP с NLSP. Это позволяло поддерживать локалки довольно-таки приличного размера, но на региональные сети (и тем более на глобальные) не тянуло.
Эксперимент с объединением сетей оказался слишком удачным и ни у IPXа, ни у пресловутых OSI протоколов не осталось времени. От последних осталась идиотская OSI модель¹), а IPX… IPX попросту сгинул.
――――――
¹) Строго говоря ничего идиотского в OSI модели нет. Идиотским является её использование. Когда выяснилось что денег спалили дофига и больше, а практического применения у этого чуда нет кому-то пришла в голову «спасительная» мысль: а пусть то, что мы породили будет не описанием мертворождённого высера, а как бы типа «описание всех сетей вообще». Попасть под обвинения о растрате никому не захотелось и OSI модель ретроспективно сделали описанием всех сетей вообще. С тех пор мы с этим идиотизмом и мучаемся. Это всё равно как взять чертежи и термины от танка и применять их при работе с самолётами. И делать вид, что у самолётов тоже есть гусеницы и трансмиссия.
IPX — более новый и потому более прогрессивный протокол. В частности адреса там 80-битные, так если бы, вдруг, в 90е годы выиграл IPX, то никакого болезненного перехода на IPXv6 бы не потребовалось.
Однако, увы и ах, к моменту, когда IP и IPX сети схлестнулись IP-сети были уже региональными и BGP был уже третьей инкарнацией соответствующих инженерных наработок (после GGP и EGP), а IPX сети застряли на RIP и EIGRP с NLSP. Это позволяло поддерживать локалки довольно-таки приличного размера, но на региональные сети (и тем более на глобальные) не тянуло.
Эксперимент с объединением сетей оказался слишком удачным и ни у IPXа, ни у пресловутых OSI протоколов не осталось времени. От последних осталась идиотская OSI модель¹), а IPX… IPX попросту сгинул.
――――――
¹) Строго говоря ничего идиотского в OSI модели нет. Идиотским является её использование. Когда выяснилось что денег спалили дофига и больше, а практического применения у этого чуда нет кому-то пришла в голову «спасительная» мысль: а пусть то, что мы породили будет не описанием мертворождённого высера, а как бы типа «описание всех сетей вообще». Попасть под обвинения о растрате никому не захотелось и OSI модель ретроспективно сделали описанием всех сетей вообще. С тех пор мы с этим идиотизмом и мучаемся. Это всё равно как взять чертежи и термины от танка и применять их при работе с самолётами. И делать вид, что у самолётов тоже есть гусеницы и трансмиссия.
Простите, а что в OSI модели идиотского? Обычная абстракция. Впрочем, т.к. вы не различаете маршрутизирумые протоколы (т.е. протоколы с возможностью организации сегментов) и протоколы маршрутизации (т.е. протоколы, призванные строить маршруты между уже созданными сегментами) то у вас есть определенные пробелы в сетевых знаниях.
Простите, а что в OSI модели идиотского?Как я уже сказал: идиотизм заключается не в OSI модели, как таковой (для описания OSI протоколов она подходит как нельзя лучше), а к попыткам прикрутить её к TCP/IP. В котором, на минуточку, уровней не 7, а 4. Да и «разделение обязанностей» между ними совсем не такое как в OSI. Если вы начнёте устраивать разные виды инкапсуляции, то уровней может и 10 оказаться, только вот беда: к 7 уровням OSI модели это всё равно всё не будет иметь никакого отношения.
у вас есть определенные пробелы в сетевых знаниях.Ну тут как бы вопрос о том, чего вы хотите.
Если вы под сетевыми знаниями понимаете «умение складывать „умные“ слова в „умные“ фразы не понимая что за всем этим стоит» — то да, в этих знаниях у меня пробелы. Если вы понимаете под этим «умение проектировать и создавать системы, которыми будут пользоваться миллионы (а то и миллиарды) пользователей» — то тут дело другое. Тут мне есть что сказать.
Выбор — за вами, как всегда.
Забавная технология, но мне кажется что по производительности на маршрутизаторах будет тоже самое что NAT (а вероятно и гораздо медленнее).
И я так понимаю «проблему клиента» оно не решает, без апгрейда клиентских устройств они не смогут подключиться к такому URL который резолвится в IPv6 адрес — а значит никто не будет так хоститься ибо это убыточно.
Проще уже дождаться IPv6.
И я так понимаю «проблему клиента» оно не решает, без апгрейда клиентских устройств они не смогут подключиться к такому URL который резолвится в IPv6 адрес — а значит никто не будет так хоститься ибо это убыточно.
Проще уже дождаться IPv6.
Оно другой проблемы не решает: все эти пакеты пойдут на всех роутерах через софт. Замедление — катастрофическое. То есть для практического использования не одним-двумя пользователями для соединения двух офисов, а для всего интернета — нужно менять всё оборудование. Если менять оборудование — можно порейти на IPv6. Так спрашивается: нафига козе баян?
не, софт надо менять только в 4-5 местах, причём 2 из этих мест сами хосты.
Надо менять не софт. Надо менять железо. IP пакеты был опций CISCO обрабатывает в «железе» (hardware switching). IP пакеты с опциями отправляются в Cisco IOS, где обрабатываются программно. Разница в скорости — хороше если на порядок (а не на два).
Что это значит? Если хотите обработать сколько-нибудь осмысленный процент траффика в режиме EnIP — извольте заменить всё оборудование на всех магистралях. Но, позвольте, если мы закатали рукава и уже меняем всё оборудование — почему сразу IPv6 не внедрить?
Что это значит? Если хотите обработать сколько-нибудь осмысленный процент траффика в режиме EnIP — извольте заменить всё оборудование на всех магистралях. Но, позвольте, если мы закатали рукава и уже меняем всё оборудование — почему сразу IPv6 не внедрить?
Вообще, разработчики позиционируют данную технологию, как решение проблем с катастрофической нехваткой IP адресов для мобильных девайсов, особенно в свете того, что технология 4G вообще не предусматривает CS-Core, и все соединение должно устанавливаться через IMS. Это значит, что каждый телефон должен иметь поддержку SIP и передачу данных в сетях 4G. Внедрить в телефон поддержку EnIP не думаю что сложно, как и обновить софт на некоторых железках.
То что IP пакеты с опциями попадают на CPU а не обрабатываются на ASIC конечно плачевно, но где-то в описании EnIP я натыкался на стоки кода, которые позволяют транзитным маршрутизаторам игнорировать поле опций, если оно имеет код 26. ASIC — по сути компьютер на чипе, и думаю реализовать на них такую функцию можно (могу ошибаться, поправьте если что).
Есть еще один вариант избежать обработки опций транзитными маршрутизаторами — MPLS. Навешиваем метку, FEC — адрес маршрутизатора, который должен произвести замену адресов. Что бы метка не была снята до попадания на узел, который должен произвести смену адреса назначения, можно использовать explicit nul label.
То что IP пакеты с опциями попадают на CPU а не обрабатываются на ASIC конечно плачевно, но где-то в описании EnIP я натыкался на стоки кода, которые позволяют транзитным маршрутизаторам игнорировать поле опций, если оно имеет код 26. ASIC — по сути компьютер на чипе, и думаю реализовать на них такую функцию можно (могу ошибаться, поправьте если что).
Есть еще один вариант избежать обработки опций транзитными маршрутизаторами — MPLS. Навешиваем метку, FEC — адрес маршрутизатора, который должен произвести замену адресов. Что бы метка не была снята до попадания на узел, который должен произвести смену адреса назначения, можно использовать explicit nul label.
ASIC — по сути компьютер на чипе, и думаю реализовать на них такую функцию можно (могу ошибаться, поправьте если что).ASIC — это таки ASIC. Вы можете добавить туда любую функциональность, в том числе ту, о которой говорите вы — но после этого извольте «испечь» новую микросхему. Обновление возможно только с заменой железки.
Можно делать что угодно, но всё упирается в ту же дилемму: без замены «железа» это всё работать не будет, а если «железо» всё равно менять, то неясно чем все эти схемы лучше простого IPv6 без извращений.
ASIC — это таки ASIC. Вы можете добавить туда любую функциональность, в том числе ту, о которой говорите вы — но после этого извольте «испечь» новую микросхему. Обновление возможно только с заменой железки.
Вообще то я и имел ввиду, что это возможно, но как вы и сказали, потребует замены железа (в данном случае линейных плат маршрутизаторов)
Но при использовании MPLS транзитные маршрутизаторы на смотрят внутрь IP заголовка, а производят коммутацию на основании меток согласно LFIB. В самом худшем случае можно использовать стек меток, подобно технологии 6PE.
Но при использовании MPLS транзитные маршрутизаторы на смотрят внутрь IP заголовка, а производят коммутацию на основании меток согласно LFIB. В самом худшем случае можно использовать стек меток, подобно технологии 6PE.Как это всё использовать в уже существующей сети?
Очередная байка про сову, мышей и ёжиков, блин… Кто, как и почему будет это чудо внедрять? Какую задачу они будут решать? Почему они не смогут просто использовать IPv6?
Подождите, я вас заставляю использовать эту технологию??? Давайте проанализируем текст статьи и посмотрим, о чем же я писал: есть технология, которая имеет право на жизнь, и я ее и описал.
Я предложил возможное решение озвученной вами проблемы — как оставить производительность транзитных узлов на прежнем уровне.
Но вам и это не понравилось. Вы начинаете о каких то мышах и ежиках говорить и задаете вопросы, ответы на которые очевидны. Но я на них отвечу:
Кто, как и почему будет это чудо внедрять? — когда мне скажут внедрить эту технологию, я это сделаю, хотя понимаю что это «гремучий костыль».
Какую задачу они будут решать? — решать задачу отсутствия белых IPv4 адресов в период, когда IP адрес уже в приделали к пылесосу и кофеварке.
Почему они не смогут просто использовать IPv6? — есть несколько подходов для миграции с IPv4 на IPv6. Самый оптимальный (на мой взгляд) — dual stack с плавным уменьшением сервисов на IPv4. Но для этого нужны люди, которые будут заниматься внедрением данной технологии, пока остальные будут устранять эксплуатировать IPv4 сервисы и устранять аварии. То есть снова все упирается в деньги. А сразу взять и перейти на IPv6 — нереально. Поэтому мы и будем дальше топтаться на IPv4, придумывая все более изощренные технологии, не дающие умереть этому протоколу.
Я предложил возможное решение озвученной вами проблемы — как оставить производительность транзитных узлов на прежнем уровне.
Но вам и это не понравилось. Вы начинаете о каких то мышах и ежиках говорить и задаете вопросы, ответы на которые очевидны. Но я на них отвечу:
Кто, как и почему будет это чудо внедрять? — когда мне скажут внедрить эту технологию, я это сделаю, хотя понимаю что это «гремучий костыль».
Какую задачу они будут решать? — решать задачу отсутствия белых IPv4 адресов в период, когда IP адрес уже в приделали к пылесосу и кофеварке.
Почему они не смогут просто использовать IPv6? — есть несколько подходов для миграции с IPv4 на IPv6. Самый оптимальный (на мой взгляд) — dual stack с плавным уменьшением сервисов на IPv4. Но для этого нужны люди, которые будут заниматься внедрением данной технологии, пока остальные будут устранять эксплуатировать IPv4 сервисы и устранять аварии. То есть снова все упирается в деньги. А сразу взять и перейти на IPv6 — нереально. Поэтому мы и будем дальше топтаться на IPv4, придумывая все более изощренные технологии, не дающие умереть этому протоколу.
В этой ветке мы, собственно, обсуждаем не саму технологию, а не, софт надо менять только в 4-5 местах, причём 2 из этих мест сами хосты.
К самой технологии вопросов нет: как оно работает — понятно, непонятно "зачем?". Какой в ней смысл. Когда от неё может быть больше толку, чем от какого-нибудь Teredo?
Это новый протокол, который абсолютно бессмысленен в малых сетях (там хватает «серых» IPv4 адресов, никакой нехватки адресов у них нет) и столь же бессмысленен в больших («большие» существующие роутеры использовать нельзя, нужно закупать новое оборудование). А какое у него есть преимущество над IPv6 — мне неясно.
Вся статья, собственно, очердная иллюстрация базовой правды о сетях номер три. Вернее её первого предложения. Но мне кажется, что кто-то забыл про второе и третье…
К самой технологии вопросов нет: как оно работает — понятно, непонятно "зачем?". Какой в ней смысл. Когда от неё может быть больше толку, чем от какого-нибудь Teredo?
А сразу взять и перейти на IPv6 — нереально. Поэтому мы и будем дальше топтаться на IPv4, придумывая все более изощренные технологии, не дающие умереть этому протоколу.Проблема в том, что то, что вы тут придумали — это не IPv4. Адреса 8-байтовые, то есть клиенты IPv4 работать не будут.
Это новый протокол, который абсолютно бессмысленен в малых сетях (там хватает «серых» IPv4 адресов, никакой нехватки адресов у них нет) и столь же бессмысленен в больших («большие» существующие роутеры использовать нельзя, нужно закупать новое оборудование). А какое у него есть преимущество над IPv6 — мне неясно.
Вся статья, собственно, очердная иллюстрация базовой правды о сетях номер три. Вернее её первого предложения. Но мне кажется, что кто-то забыл про второе и третье…
по идее, оно легче чем NAT, т.к. не надо таблицу соединений в памяти держать.
«В теории — теория и практика одинаковы, однако на практике это не так».
То есть где-нибудь «в далёкой-далёкой галактике» EnIP и будет легче, чем NAT. Но не в нашей вселенной. По одной простой причине: таблицы для NAT'а в роутерах уже есть и работа с ними происходит аппаратно. CPU в этом процессе не участвует. А вот обработка пакетов с IP опциями — происходит программно. Всё. Приехали. Закрыли тему.
То есть где-нибудь «в далёкой-далёкой галактике» EnIP и будет легче, чем NAT. Но не в нашей вселенной. По одной простой причине: таблицы для NAT'а в роутерах уже есть и работа с ними происходит аппаратно. CPU в этом процессе не участвует. А вот обработка пакетов с IP опциями — происходит программно. Всё. Приехали. Закрыли тему.
Проблемы ID/Locator это все не решает.
Ну все, наконец-то можно будет достойно отвечать «NAT — не Firewall», ссылаясь на этот стандарт.
итак, нам в типичном случае нужно обновить:
1. сетевой стек на компьютере пользователя. (чтоб писал все эти опции)
2. прошивку на домашнем рутере (чтоб не поломал всё нафиг)
3. BRAS у провайдера интернет (чтоб заголовки програмно переписывал)
4. Балансировщик в датацентре у провайдера услуг (чтоб тоже заголовки програмно переписывал)
5. сетевой стек на сервере у провайдера услуг (чтоб писал все эти опции в ответный пакет)
…
вопрос автору статьи: я уверен есть реализация драфта в опенсорсе,
у вас хватило терпения настроить стенд со всеми участниками процесса и проверить как оно работает с разными программами?
не совсем понятно как будут работать существующие приложения, которые писались под 4х октетный адрес.
кто, какая программная сущность будет дописывать опции и знать как поля заполнять?
1. сетевой стек на компьютере пользователя. (чтоб писал все эти опции)
2. прошивку на домашнем рутере (чтоб не поломал всё нафиг)
3. BRAS у провайдера интернет (чтоб заголовки програмно переписывал)
4. Балансировщик в датацентре у провайдера услуг (чтоб тоже заголовки програмно переписывал)
5. сетевой стек на сервере у провайдера услуг (чтоб писал все эти опции в ответный пакет)
…
вопрос автору статьи: я уверен есть реализация драфта в опенсорсе,
у вас хватило терпения настроить стенд со всеми участниками процесса и проверить как оно работает с разными программами?
не совсем понятно как будут работать существующие приложения, которые писались под 4х октетный адрес.
кто, какая программная сущность будет дописывать опции и знать как поля заполнять?
Стенд собирали (на виртуалках), браузер работал, поднятый сайт открывался (правда не было DNS сервера и открывали сайт по EnIP).
Как будут работать приложения, заточенные под IPv4 особо протестировать не получилось. Но точно работают SSH, SSL, HTTP. Точно не работает IPSec.
Опции в IPv4 используются и сейчас, поэтому проблем с добавлением опций не должно быть. Правда придется обновлять софт (в Linux уже есть поддержка данной технологии, версию ядра не помню к сожалению).
Как будут работать приложения, заточенные под IPv4 особо протестировать не получилось. Но точно работают SSH, SSL, HTTP. Точно не работает IPSec.
Опции в IPv4 используются и сейчас, поэтому проблем с добавлением опций не должно быть. Правда придется обновлять софт (в Linux уже есть поддержка данной технологии, версию ядра не помню к сожалению).
в Linux уже есть поддержка данной технологии, версию ядра не помню к сожалениюЭк вы красиво завернули. Patch для древнего ядра, валяющийся и не обновляющийся год — это не называется «в Linux уже есть поддержка данной технологии», уж извините.
Типичный пример: функциональность IFS (Inherited File System) из старого древнего дистрибутива Stackware 1994 года выпуска была-таки добавлена в ядро. В 2014м году! Разумеется это был уже совсем-совсем другой код. Переписанный раз… много.
А сколько всего просто осталось никому не нужными patch'ами валяющимися на просторах archive.org?
Нет в Linux никакого EnIP и, скорее всего, никогда не будет, не нужно обманывать.
Не буду переубеждать, но и не стоит говорить, что человек врет, если не владеете полной информацией.
Вот ссылка https://github.com/EnIP/enhancedip/tree/master/v1.1 скачивайте и пробуйте.
Если вы имели ввиду, что официально нет, то наверно вы правы — официальной версии я не видел.
Вот ссылка https://github.com/EnIP/enhancedip/tree/master/v1.1 скачивайте и пробуйте.
Если вы имели ввиду, что официально нет, то наверно вы правы — официальной версии я не видел.
Я имею в виду, что в Linux — даже в самой последней версии 4.4, вышедшей несколько дней назад.
То, что у кого где-то под столом есть какие-то патчи, не обновляющиеся уже год не делает технологию доступной в Linux'е!
То, что у кого где-то под столом есть какие-то патчи, не обновляющиеся уже год не делает технологию доступной в Linux'е!
Да, согласен софт не обновлялся, но хотя бы он есть. Отвечая на ваш комментарий, я имел ввиду, что пока что попробовать эту технологию можно в Линукс, если есть желание, про остальные системы не знаю. Давайте не будем спорить по пустякам, как говорится, давайте жить дружно:)
С такой поправкой — ответ принимается. Да, попробовать можно.
Просто такое ощущение что кто-то студенческую лабораторную работу с соотвествующей кафедры пытается представить как-то что-то реальное и серьёзное. Что, мягко говоря, вызывает недоумение.
Как студенческая работа — так очень даже неплохо, но рассматривать это всерьёз??? Странно это, как-то. Если бы эти все изыски были предствалены в стиле как я провёл лето, то у меня вопросов не было бы.
Просто такое ощущение что кто-то студенческую лабораторную работу с соотвествующей кафедры пытается представить как-то что-то реальное и серьёзное. Что, мягко говоря, вызывает недоумение.
Как студенческая работа — так очень даже неплохо, но рассматривать это всерьёз??? Странно это, как-то. Если бы эти все изыски были предствалены в стиле как я провёл лето, то у меня вопросов не было бы.
есть еще префикс 224.0.0.0/4, но он до сих пор не распределен
Ничего не путаете? Может быть имеется в виду 240/4?
Спасибо внимательном читателю. Естественно 240 — автозамена видимо была при наборе, а я не заметил. Поправил
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Enhanced IP