Комментарии 327
NDN — бред какойто, я посмотрю как они будут эти адреса запоминать/вбивать кудато.
Из-за того, что у пользователя меняется ИП при переходе в другую сеть, надо нагнуть всю систему и поменять ее?
Из-за того, что у пользователя меняется ИП при переходе в другую сеть, надо нагнуть всю систему и поменять ее?
Нет, конечно лучше внедрять костыли в других технологиях, вроде фактического нахождения IP-адреса на БС в мобильной связи, а не на телефоне абонента.
Почему сразу костыли? ПОчему нельзя сделать версию протокола 6.1?
ДНС же проапгрейдили?
Мне кажется, что озвученная проблема надуманная и касается очень небольшой горстки пользователей.
ДНС же проапгрейдили?
Мне кажется, что озвученная проблема надуманная и касается очень небольшой горстки пользователей.
Mobility Support in IPv6
tools.ietf.org/html/rfc6275
tools.ietf.org/html/rfc6275
Как? Еще легче IP, потому что NDN выглядит как путь, к которым люди привыкли. IPv6 — вот где вопрос, как это вбивать и запоминать. По факту, невозможно.
Не то, чтобы я поддерживаю NDN, вообще первый раз про такое слышу, но претензия ваша странная. Глобальное иерархической пространство имен это отличная идея, в теории. По сути, это как если DNS имена поместить прямо на этом уровне. Людям это только проще. Вот железу вряд ли — имена переменной длины это проблема.
Не то, чтобы я поддерживаю NDN, вообще первый раз про такое слышу, но претензия ваша странная. Глобальное иерархической пространство имен это отличная идея, в теории. По сути, это как если DNS имена поместить прямо на этом уровне. Людям это только проще. Вот железу вряд ли — имена переменной длины это проблема.
NDN — бред какойто, я посмотрю как они будут эти адреса запоминать/вбивать кудато.Конечно же, это вбить и запомнить сильно проще:
FE80:0000:0000:0000:0202:B3FF:FE1E:8329
Конечно я сравнивал с ИП4, но адрес типа
/ucla/videos/demo.mpg/1/3...100500/// и тп то же не запомнишь, неизвестно какой реальной вложенности он будет в реальности.
Также, в адресе прописывать весь маршрут, это как заставить пользователя самому обращаться к ДНС чтобы узнать ИП сайта.
/ucla/videos/demo.mpg/1/3...100500/// и тп то же не запомнишь, неизвестно какой реальной вложенности он будет в реальности.
Также, в адресе прописывать весь маршрут, это как заставить пользователя самому обращаться к ДНС чтобы узнать ИП сайта.
/russia/moscov/tverskaya/25/222/room1/pc1 — так ведь уже гораздо лучше, правда? Но с приватностью бяда
По IP адресу и так можно получить точность до города. А дальше провайдер может самостоятельно раздавать номера. т.е. будет /russia/moscov/addrProvidera/{userID}/{user-defined identifier}
а уж сколько разночтений можно сгенерировать — moscov/moskau/moscow/moskva/msk — и поди вспомни какой из вариантов использовал для того узла
Так одной из целью как раз отвязаться от места расположения. Что бы адрес был закреплён за устройством, а устройство может сегодня быть на тверской, а завтра на павелецкой, а то и в МО.
Can't find 'moscov '. Нет, не лучше — не работает.
Перенёс во вторую комнату — всё сломалось, взял pc1 из другого места — всё сломалось.
Перенёс во вторую комнату — всё сломалось, взял pc1 из другого места — всё сломалось.
Увы, но не лучше. Наличие / создает лишние затраты при передаче данных. На одном адресе это незаметно, но пожирание ресурсов сразу скажется на производительности у первого же районного провайдера в час пик.
Я вот реально не пойму: зачем в IPv6 сделали 128-битный адрес? Это с расчётом на какое будущее, на миллионы лет вперёд? Придумали бы какой-нибудь IPv5 с вдвое увеличенной длиной адреса с 32 до 64 бит, и этого было бы за глаза.
Это чтобы при необходимости мигрировать сразу всю инфраструктуру достаточно было только сменить префикс. IPv6 блоки именно поэтому раздаются сразу по /48 и /64
Озвучивался вариант оставить 32 бита, только добавить к нему номер автономной системы, то есть как выше сказано, фактически 64 бита. Тоже с миграцией не должно быть проблем. Вообще ничего менять не надо.
И всё же некоторая логика в этом есть, т.к. услуги разные — связность с сетью, к которой заранее неизвестно что и сколько вы собираетесь подключать, и заведомо известный один vps/дедик, которому ну вот честно — зачем больше одного адреса при наличии всяких там vhost/sni?
А что провайдер не выдаёт — так подключите туннель. Какой-нибудь Teredo/HE/Netassist, полно же их.
А что провайдер не выдаёт — так подключите туннель. Какой-нибудь Teredo/HE/Netassist, полно же их.
Блин, я видел ультранищеброд-впс типа «6$ в год» и всё равно хотя бы /112. Стоило бы такого хостера покинуть, принципиально за «поштучный IPv6».
Чтобы снова не наступить на те же грабили, на которые наступили с IPv4, называются «должно хватить». IPv5 уже придумали много лет назад, но это не то, о чём можно было бы подумать, поглядев на IPv4 и IPv6
Можно покопаться в истории — архивы рассылки SIPP за 1994 год.
Вначале цикл обсуждений типа «адрес переменной длины или постоянной?» и несколько сообщений очень уверенным тоном «любой длины, но постоянной, иначе раутеры задолбутся это разбирать».
Затем предполагался адрес из двух параллельных друг другу 64-битных частей(!) — глобально уникальной и локально уникальной.
Потом вдруг молча (по крайней мере в рассылке) уже все говорят только о 128-битном варианте из глобальной и локальной части, хотя для глобальной уже не ставится требования уникальности — она идентифицирует конкретный локальный сегмент.
Вероятно, в это время произошла устная встреча участников… я не выяснял. Но видимого в сети обсуждения толком не было, результат просто принят кулуарно.
И это ещё в те времена, когда CIDR на IPv4 не вошёл в полную силу, и не было уверенности, что IPv4 сможет прожить ещё хотя бы 5 лет — строились такие мрачные прогнозы. CIDR в результате оттянул смерть IPv4 минимум лет на 30.
Вначале цикл обсуждений типа «адрес переменной длины или постоянной?» и несколько сообщений очень уверенным тоном «любой длины, но постоянной, иначе раутеры задолбутся это разбирать».
Затем предполагался адрес из двух параллельных друг другу 64-битных частей(!) — глобально уникальной и локально уникальной.
Потом вдруг молча (по крайней мере в рассылке) уже все говорят только о 128-битном варианте из глобальной и локальной части, хотя для глобальной уже не ставится требования уникальности — она идентифицирует конкретный локальный сегмент.
Вероятно, в это время произошла устная встреча участников… я не выяснял. Но видимого в сети обсуждения толком не было, результат просто принят кулуарно.
И это ещё в те времена, когда CIDR на IPv4 не вошёл в полную силу, и не было уверенности, что IPv4 сможет прожить ещё хотя бы 5 лет — строились такие мрачные прогнозы. CIDR в результате оттянул смерть IPv4 минимум лет на 30.
FE80:0000:0000:0000:0202:B3FF:FE1E:8329 → FE80::0202:B3FF:FE1E:8329
Уже немного короче.
Зачем кому-то запоминать линк-локал адрес?..
Уже немного короче.
Зачем кому-то запоминать линк-локал адрес?..
Ну, есть укороченный вариант записи:
fe80::202:b3ff:fe1e:8329
Но да, всё же недостаточно просто.
fe80::202:b3ff:fe1e:8329
Но да, всё же недостаточно просто.
У IPv6 с запоминанием тоже не очень. Я вот даже не представляю как, допустим, обычному пользователю в IPv6 only сети по телефону продиктовать адрес роутера. Типа введите http://[::ffff:c0a8:101], при том что на 192.168.1.1 многие ломаются.
Путь выглядит более привычным и понятным.
Путь выглядит более привычным и понятным.
Я как-то сразу вспомнил попытки продиктовать е-майл по телефону…
C как русская "ЭС", С как доллар, P как русская "ЭР"
Так что легче не станет
Для таких вещей давно уже придумали фонетический алфавит.
Кстати, даже тому, кто в школе английский не учил, можно сказать Sierra Papa и всё будет понятно, какие буквы писать.
А теперь объясните какой-нибудь бабушке, что такое этот ваш фонетический алфавит.
эскакдоллариликрючёчек
Вот зачем бабушкам диктовать IP адрес? Пожалейте старушек, они от слова IP то сразу за валерьянкой бегут. А вообще да, удовольвтсие сомнительное, представляю как удлиннятся диалоги сетевиков между собой. Хотя как показывает практика с маками, последних 4 цифр достаточно.
Пока они внедрят, бабушками и дедушками будут люди, уже родившиеся в эпоху домашних ПК ;-)
А если нужны буквы C или Q? Тут уже нужно знать эти слова и как они пишутся.
(Здесь должен быть старый анекдот про русского пилота и еврейского диспетчера)
Именно поэтому во всех deployment гайдах по IPv6 настоятельно рекомендуют сразу же поднимать DNS, т.к. человеки несовершенны и им по какой-то причине сложно запомнить последовательности в 128 нулей и единиц, даже если они в прекрасном удобочитаемом HEX формате ;-)
А почему не выпустить расширенную версию HEX — включающую все буквы латинского алфавита и все цифры и того 36-ричная система. Тогда будет всего 25 символов в адресе).
Тогда уж Base32. Чтоб не путать O там или 0.
Вы переизобрели Base56 :)
Вспоминается местечковый провайдер, после 22 поддержка только через форум.
«Если у вас не работает интернет (например завис домовой свич), пишите на форум, там есть сотрудники поддержки».
«Если у вас не работает интернет (например завис домовой свич), пишите на форум, там есть сотрудники поддержки».
А как написать на форум, если свич завис?
при том что на 192.168.1.1 многие ломаются.
«Вот и именно» Должен быть QR код на устройстве или что то подобное. Проблемы с вводом адреса есть и для IPv4, суть не меняется.
По слухам администрация некоторых сайтов отказывается делать сайт доступным по ipv6, чтобы упростить отсев нежелательных постеров.
Это неграмотные администраторы, которые не знают ничего про ipv6 и не хотят его внедрять из за боязни новизны и нежелания изучать новые технологии.
В плане отсева нежелательных постеров все элементарно просто, нужно банить не единичный ip адрес, а /64 подсеть, которая рекомендована для выдачи одному пользователю. Набрать множество /64 подсетей будет уже проблематично, так же, как и множество единичных ipv4 адресов.
То ли у ВК тоже неграмотные админы, то ли это им не помогло, но они тоже отрубили IPv6 из-за «нежелательных постеров»
В ВК же нельзя ничего постить без регистрации и СМС. Нежелательные постеры всё время проходили новую регистрацию с разных IPv6 адресов и отрубить IPv6 стало единственным выходом?
Я склонен думать, что российские компании сторонятся ipv6 по причине финансовой невыгодности, не более. Потому что на внедрение и поддержку нужны серьезные затраты, а дополнительной прибыли им это не принесет. Думать с заделом на будущее у нас не умеют, живут сегодняшним днем, чтобы получить максимум прибыли с минимумом затрат сегодня, что в текущих политических условиях в принципе оправдано.
Тем не менее IPv6 в ВК был вполне внедрён некоторое время. Я спрашивал в поддержке, почему отключили — сказали из-за спамеров (подробности рассказывать отказались, чтоб типа спамерам не подсказывать)
сказали из-за спамеров (подробности рассказывать отказались, чтоб типа спамерам не подсказывать)
Не верю, точно не из за этого. Тем более там все регистрации через телефон подтверждаются, а с блокированием диапазонов ipv6 нет никаких проблем.
Скорее всего отключили, т.к. при наличии AAAA записи, браузеры по-умолчанию начинают ломиться по IPv6, который у многих клиентов, увы, настроен неправильно (по крайней мере раньше это было актуально), в результате чего они теряли клиентов.
Звучит логично, но тогда непонятно, зачем мне в поддержке врать про спамеров
Поддержка может не знать и иметь список ответов на такие вопросы, либо нежелание открывать хоть какую-то информацию про прибыль или потери клиентов. Такая параноидальная модель — не использовать «теряем пользователей» никогда и ни за что, ибо изнасилованные блоггеры все равно все переврут. А так — спамеры и спамеры, кого ими удивишь сейчас.
что гугл, что яндекс, что фейсбук не боятся по этой причине терять пользователей, хотя наверняка их абузят спамеры, но эти компании более-менее умеют с ними справляться
¯\_(ツ)_/¯
только вот у гугла/фейсбука нету как таковой альтернативы, они могут себе позволить эксперименты. это как с виндовс.
Статья же была от Яндекса на эту тему на Хабре, про то с чем они столкнулись, когда разрешили IPV6. Статья старая и сейчас наверное все хорошо, но в тот момент был адок. Например они вводили белые листы провайдеров. Поэтому цитаты от разных компаний, о невозможности нормальной работы могут быть оправданы.
Возможно это следствие. Я видел темы на форумах, люди писали что у ВК IPv6 глючит часто, а по v4 сайт открывает. То есть они со своей стороны не асилили нормально, в итоге были проблемы с доступом у людей с приоритетом IPv6.
Не знаю, как это может быть связано с ВК, но РКН и провайдеры до сих пор не умеет блокировать IPv6 трафик. Если использовать нормальный DNS и провайдер умеет в IPv6, то можно часть блокировать даже не заметить.
Возможно, у Mail.ru на этот счёт свой пунктик.
Возможно, у Mail.ru на этот счёт свой пунктик.
Не согласен. В России очень даже неплохой интернет. В то время как половина Европы ещё на adsl сидит, там не то что ipv6 внедрять, там хотя бы догнать надо.
В России очень даже неплохой интернет.
Вот скоро роскомпозор станет правилами маршрутизации управлять и диктовать специалистам, как им работу делать и все может измениться.
В то время как половина Европы ещё на adsl сидит, там не то что ipv6 внедрять, там хотя бы догнать надо.
Статистика врать не станет, в Европе ipv6 трафика 10-40%, в то время, как в России всего 2,5%.
Ну а откуда ему у нас взяться, если, например, у моего провайдера доступ по IPv6 — это дополнительная платная услуга.
В России ipv6 мало кем поддерживается. МТС, но только на мобильных и нужно специально подключать и Дом.ру (и то не во всех городах насколько мне известно), кажется на этом все. Тот же ТТК в 12 году обещал внедрить и даже запускал в тестовом режиме, но потом почему-то отказался от этой затеи.
IPv6 у МТС включен по умолчанию у всех пользователей оператора.
В некоторых регионах у Ростелекома есть IPv6, также есть у МГТС.
В некоторых регионах у Ростелекома есть IPv6, также есть у МГТС.
К сожалению, поддержка v6 даже в пределах одного провайдера\оператора разнится в зависимости от региона. К примеру, в Твери у РТК вместо v6 бублик — как и у Билайна, «Горсети» (той самой, которую когда-то выпер из Зеленоградо «Акадо»), Нетбайнета и многих других.
Про более мелких провайдеров — в том числе и по Москве и МО — и говорить нечего: когда я искал себе провайдера в новую квартиру, и задавал саппорту вопрос о поддержке v6 — на меня в лучшем случае смотрели как на идиота и спрашивали «эээ, а зачем?».
Про более мелких провайдеров — в том числе и по Москве и МО — и говорить нечего: когда я искал себе провайдера в новую квартиру, и задавал саппорту вопрос о поддержке v6 — на меня в лучшем случае смотрели как на идиота и спрашивали «эээ, а зачем?».
На онлайм ipv6 prefix delegation работает.
Вообще это вполне адекватный вопрос. Зная конечную цель можно попробовать найти другой вариант если конкретно этот недоступен. К тому же зная какие проблемы вы хотите решать этим инструментом компания может прикинуть сколько вообще людей с такими проблемами может быть и оценить выгоду от разработки/внедрения инструмента. Но это в теории.
А доступ в эту сеть вам нужен просто чтобы был? Я так понимаю что вы с помощью доступа в сеть IPv6 все-таки решаете какую-то свою задачу. И если провайдер не имеет конкретно IPv6, то в случае когда вы отвечаете «за надом» он ничем помочь вам не может и с некоторой вероятностью потеряет вас как клиента. Но если бы вы описали вашу пролему (не то чтобы вы должны конечно, я описываю мотивацию провайдера), то провайдер мог бы попробовать найти другое решение. Опять же. Ваша проблема вряд ли уникальна конкретно для вас. Зная о проблеме провайдер может попробовать оценить сколько еще людей ее имеют и насколько решение этой проблемы можно продать. Продать необязательно предоставив услугу за деньги, но и просто получив преимущество перед конкурентами например.
Давно? Я с полгода-год назад подключал специально. Да и сейчас оно как отдельная услуга вынесено.
На домашнем МТС никакого ipv6 и вовсе нет, даже подключить нельзя.
На домашнем МТС никакого ipv6 и вовсе нет, даже подключить нельзя.
Не согласен. У МТС недавно подключал симку, через приложение отдельно нужно было включить эту функцию, хоть она и бесплатна
МГТС GPON?
Что-то не нашёл опции...
мне пришла смс (на МТС) о подключении услуги IPv6, сам специально не подключал ничего.
В России Интернет неплохой?! Да ладно, много где даже 2G нет. А то, что пользуются adsl, так во многих банках и у нас пользуются, это безопасней в разы.
А вот что касается не использования IPv6, это скорее, что в России много компаний, у которых оборудование еще тех годов, где не внедряли эту технологию и покупать ради этого другое оборудование не намерены. Пройдет еще пяток лет и будут догонять остальные страны.
А вот что касается не использования IPv6, это скорее, что в России много компаний, у которых оборудование еще тех годов, где не внедряли эту технологию и покупать ради этого другое оборудование не намерены. Пройдет еще пяток лет и будут догонять остальные страны.
Справедливости ради, в России действительно достаточно неплохой интернет — что кабельный, что мобильный. В Финляндии (Хельсинки, Котка, Коувола) и Чехии (Прага), по моему опыту, 3G и LTE будут медленнее, чем они же в Москве или Твери.
В том же Хельсинки довелось этой осенью посидеть несколько дней на кабеле от Telia — выше 20 мегабит выжать не удавалось. Тот же Netflix очень долго мялся и кешировался, прежде чем перейти на 720p.
С другой стороны, что в Финляндии, что в Чехии существует очень много публичного, открытого вайфая — зачастую даже без какого-либо кэптив портала, не говоря уже про авторизацию по номеру телефона. Просто подключился и сидишь.
В том же Хельсинки довелось этой осенью посидеть несколько дней на кабеле от Telia — выше 20 мегабит выжать не удавалось. Тот же Netflix очень долго мялся и кешировался, прежде чем перейти на 720p.
С другой стороны, что в Финляндии, что в Чехии существует очень много публичного, открытого вайфая — зачастую даже без какого-либо кэптив портала, не говоря уже про авторизацию по номеру телефона. Просто подключился и сидишь.
Справедливости ради, в России действительно достаточно неплохой интернет — что кабельный, что мобильный
Он еще и дешевый.
С другой стороны, что в Финляндии, что в Чехии существует очень много публичного, открытого вайфая
В Европе и препейд симки есть, без всяких договоров-паспортов берешь и покупаешь.
Он еще и дешевый.Если в пересчёте на евро — возможно.
В Европе и препейд симки есть, без всяких договоров-паспортов берешь и покупаешь.Про карточки я в курсе, но вот количество вайфая откровенно удивило.
Можно было в принципе не пользоваться роумингом — по Хельскинки открытых сетей хватало выше крыши.
Ну я же написал, что много где, а не везде. Понятное дело, что в МСК и округе, да и в других крупных городах Интернет норм будет. Но если взять всю Россию…
Ну таки Тверь ни дыры не крупный город — около 420 тысяч на данный момент. Тем не менее, ещё в 2016-м году я имел 75 мегабит за 400 рублей в месяц.
Округа МСК, при чём не просто где-то сбоку, а прямо по прямой линии в СПБ.
Для удобства с другой статьи
www.company.rt.ru/about/net/magistr/ROS_map%20Magistral2014.png
Для удобства с другой статьи
www.company.rt.ru/about/net/magistr/ROS_map%20Magistral2014.png
Я в Твери прожил чуть меньше 20 лет, и от близости МСК она получает приблизительно ничего. Рекомендую вам съездить туда и прочувствовать, насколько может рваться шаблон — хотя казалось бы, отъехали на 170 километров от столицы.
Я не в плане прожиточного уровня, а в плане кабелей.
Уровень жизни напрямую влияет на то, как много готовы вкладывать провайдеры в рынок. Деньги тоже нужно как-то отбивать — и этого не сделать, если брать за услуги деньги, которых у людей нет.
Самое дорогое, это протянуть трассу до города, а если она и так проходит мимо, почему бы не воспользоваться. А вот если в сторону отъехать до города, где оптику не завезли, вот там кэшироваться нетфликс еще дольше будет
Вот это очень правильная мысль. Однако реальная стоимость Интернета у нас настолько низкая по невероятно простой причине — стоимость труда крайне низкая. Оборудование дорогое, но оно в бюджет элементарно укладывается, тем более, что оно точно так же дешевеет. А вот инженер работая за 100к в месяц будет считать себя ахуенным средним классом и радоваться жизни. Плевать, что абсолютно точно такой же инженер (разве что русский очень плохой или полностью отсутствует) в Хельсинге получает раза в 3 больше в худшем случае.
В Хельсинге :) у него и расходы другие. Доводилось видеть не Хельсингов, а рядом их соседей в ресторане в России. Наши запросто заплатили на тот момент (лет 10 назад) что-то вроде 1500 рублей с носа, Хельсинги были в абсолютном шоке.
Май спич из нот со грейт. Хельсинки офк. Остальное не понял, извините.
Отдыхали со скандинавами в ресторане в Питере, 10 лет назад. Когда пришла пора расплачиваться, наши легко заплатили за съеденное и выпитое, скандинавы были в шоке от суммы счёта. Так что нет смысла напрямую сравнивать инженера в Хельсинки и инженера в России, причём не в Москве и с зарплатой 100 тыс рублей.
В шоке они были потому что в Европе принято что цена в ресторане -+ одинаковая а чтобы установить ценник x5 нужно об этом очень сильно "предупредить"
Ну это как бы совсем немного, еда в принципе в РФ не очень дешёвая, у меня до трети зарплаты уходит на еду и заведения, но я совершенно не готовлю сам — слишком много времени занимает. Хотя вообще не верю про в шоке, лет 8 назад приезжали немецкие подруги — вообще ничего такого не было, даже не обсуждали чек, точное число не помню, но на десятерых как по мне был очень приличный чек. Да и в Эстонии и Хельсинки когда был мне цены показались относительно Питера вполне нормальными. Прям ну вот цены как цены, хз чё за байки, я правда студентом был и в ту бытность особо не пытался шиковать. Но последний мой поход в ресторан, причём относительно помпезный, попросил у моего кошелька около 10к на шестерых. И это за плотный ужин с хорошим вином и видом на Охту. Я бы не сказал дёшево, но оказывается могу позволить себе хоть каждый день там обедать (правда моя пенсия идёт лесом, но это лирика). В принципе, это ещё зависит и от предпочтений. Вполне можно и в очень дорогом ресторане весьма бюджетно отобедать, равно как и в дешёвой забегаловке потипу макдака почти штуку на одного оставить. Зависит от.
Вот квадратный метр их удивляет. Они вообще не понимают нашу экономику строительства, а американец в скайпе как-то даже сказал про наши квартирные ипотеки прямым текстом: «вы там совсем 3.14».
Ещё дороги удивили немок, сначала они не совсем понимали зачем так много ренж роверов, а когда поехали на дачу их прямо осенило. Что для нас отличная дачная дорога для них ралли какое-то.
Смысл сравнивать есть всегда. Смотря каким образом. Напрямую ясное дело это глупо, но если проводить достаточный анализ это вполне можно и нужно делать. Как минимум в это время мы что-то новое узнаём о культуре и жизни.
Вот квадратный метр их удивляет. Они вообще не понимают нашу экономику строительства, а американец в скайпе как-то даже сказал про наши квартирные ипотеки прямым текстом: «вы там совсем 3.14».
Ещё дороги удивили немок, сначала они не совсем понимали зачем так много ренж роверов, а когда поехали на дачу их прямо осенило. Что для нас отличная дачная дорога для них ралли какое-то.
Смысл сравнивать есть всегда. Смотря каким образом. Напрямую ясное дело это глупо, но если проводить достаточный анализ это вполне можно и нужно делать. Как минимум в это время мы что-то новое узнаём о культуре и жизни.
С другой стороны, что в Финляндии, что в Чехии существует очень много публичного, открытого вайфая
И у нас так было, пока не запретили.
О, интересно, сейчас живу в Хельсинки у меня противоположный опыт:
Сейчас пользуюсь безлимитным тарифом у Elisa (4G) и скорость спокойно держится на уровне 5-7мбайт/сек. Использую телефон вместо домашнего модема.
Йота в Москве/Питере не только требует отдельной оплаты за использование телефона как точки доступа, но и качество хуже было.
Сейчас пользуюсь безлимитным тарифом у Elisa (4G) и скорость спокойно держится на уровне 5-7мбайт/сек. Использую телефон вместо домашнего модема.
Йота в Москве/Питере не только требует отдельной оплаты за использование телефона как точки доступа, но и качество хуже было.
У меня в роуминге на МТС цеплялась Telia — фиг знает, как по-местному её оценивают, как терпимого ОПСОСа или нет, но мне категорически не понравилось. Я предпочёл выключить телефонный модуль вовсе, и пользовался бесплатными сетями, которые находил по городу, да домашним вайфаем на арендованной квартире.
Что касается Йоты в МСК и Питере — регион в принципе весьма сильно нагружен, и качество связи на ней упало капитально. Не в последнюю очередь потому перекатился на МТС.
Что касается Йоты в МСК и Питере — регион в принципе весьма сильно нагружен, и качество связи на ней упало капитально. Не в последнюю очередь потому перекатился на МТС.
Роуминг может заметно отличаться по условиям от той же сети для местных. Телия, не знаю как в Хельсинки, но к нам в Оулу она только пришла и пока что предлагают очень неплохие условия. Правда лично не пользуюсь и опытом поделится не могу, но по слухам — там все хорошо сейчас. Вообще в европейском реддите есть мнение что интернет и мобильная связь в европе лучше всего по всем параметрам именно в Финляндии. У меня — DNA и дома интернет тоже от них и ни разу каких-то проблем не было. Торренты вполне себе под заявленную 10ку качаются, нетфликс не тормозит, с играми проблем нет (естественно что последние — не одновременно с торрентами).
Про торренты, кому интересно
Писем счастья за торренты ни мне, ни моим знакомым ни разу не приходило. Но мы и финские вещи не качаем, в основном это то, чего нет на нетфликсе/спотифае, большей частью это что-то российское или с русской локализацией, возможно что местным правообладателям это просто неинтересно контролировать.
это безопасней в разы.
Безопасней, чем кричать?
Лишь рекомендована. И фильтруя такого пользуна ты понятия не имеешь забанил ты его с его кофеваркой и микроволновкой или одной строкой выпилил несколько сотен абонентов этого же провайдера.
/64 является минимальной маршрутизируемой единицей в IPv6, как 1 IP в IPv4, то есть, раздавать /64 на множество клиентов провайдер может только разделяя их по L2, что несколько нетривиально и довольно хлопотно в плане учёта. Есть ещё всякие ещё более костыльные варианты, но сомневаюсь, что такие мазохисты водятся в провайдерской среде
Это просто ускорит внедрение DPI-решений.
В IPv6 провайдеры настраивают reverse path filtering строже, и атаки с подменой адреса отправителя проводить (различные амплификации) заметно сложнее.
Производитель CG-NAT пишет о том, что IPv6 провалился, как мило.
В то время как везде наблюдается рост трафика IPv6.
В то время как везде наблюдается рост трафика IPv6.
Я возможно не прав, и не до конца понимаю суть вопроса, но меня от перевода моих серверов на IPv6 останавлавает одна простая вешь — отсутствие связаности между IP и IPv6 сетями. То есть если мой сервер будет доступен только по IPv6, то из нормального интернета (IP) я его не увижу. Это так? А если так, то смысл менять?
Даже у моего домашнего сервера два IP — 4 и 6. Доступен по обоим. В чем вопрос-то? Почему вместо, а не вместе?
Вопрос в том, зачем это нужно. Если IPv6 уже есть на сервере — здорово! Убирать его точно не надо. Но вот специально его там заводить… Я в сомнениях :) Времени жалко, а смысла не вижу. Даже если заведу, то буду пользоваться старыми IP адресами. Они то везде работают :)
Интернет IPv4 и IPv6 — это две разных сети, с разной связанностью. На сервере и клиенте одновременно включаются оба протокола (называется dualstack), IPv6 по-умолчанию имеет более высокий приоритет и постепенно вытесняет IPv4, после чего выключается устаревший IPv4.
Поэтому необходимо включать одновременно оба протокола, отдельно брать их на мониторинг.
Поэтому необходимо включать одновременно оба протокола, отдельно брать их на мониторинг.
Поэтому необходимо включать одновременно оба протокола
Эээ… Кому надо? Первый абзац безусловно верный, но из него не следует необходимость включения обоих протоколов.
Вы меня поимите правильно, я за IPv6, но приходиться работать на разных площадках — например в банке мне просто не разрешат сделать тунель до IPv6 брокера, а своего у них нет. И зачем мне тогда на сервере IPv6 если я с ним работаю по IP? Что бы было?
Можно сделать сервер доступным одновременно по IPv4 и IPv6 (dualstack).
а зачем менять? добавьте IPv6 адрес, пусть в обоих сетях висит.
Добавить можно, вопрос зачем? Что бы было? Сервер мой, использует его ограниченый набор людей. Им не нужны варианты. Им нужен один рабочий способ для работы с ним. То есть я могу сказать им — используйте appv6.example.com/app, а если не работает, то запустите тунель, а если не работает, то используйте appv4.example.com:6427/app. На что получу вопрос — а appv4.example.com:6427/app будет всегда работать? А если да, то почему просто не использовать его?
Достаточно app.example.com, и такая проблема отпадёт.
зачем такие сложности?
вот вы испытываете какие то проблемы с доступом до гугла? а он между прочим в обоих сетях висит. И никого не напрягает.
4-х адресов мало. Мы вот, как провайдер, уже не можем каждому клиенту дать в4 реалку. Даем нат — серый адрес на pppoe, который натится в мир. Если паралелльно включить v6 — то клиент получает связность по v6 и нат по v4. Например на тот же гугл и ютуб молча идет по в6 сети. А на все остальное — по в4… Особых трудностей пока не встретили за три года работы по такой схеме…
вот вы испытываете какие то проблемы с доступом до гугла? а он между прочим в обоих сетях висит. И никого не напрягает.
4-х адресов мало. Мы вот, как провайдер, уже не можем каждому клиенту дать в4 реалку. Даем нат — серый адрес на pppoe, который натится в мир. Если паралелльно включить v6 — то клиент получает связность по v6 и нат по v4. Например на тот же гугл и ютуб молча идет по в6 сети. А на все остальное — по в4… Особых трудностей пока не встретили за три года работы по такой схеме…
Ох уж эти торопыги. Вам бы комментарий до конца дочитать… Тогда вы вы увидели, что кроме IPv4 там еще и порт, с которым DNS не поможет. Поэтому и имена разные. Просто дайте себе время подумать :)
Над чем думать? Над тем, как устроить себе проблемы? Есть много способов, помимо описанных вами. А ответа, на вопрос: зачем всё делать через задний проход — вы так и не дали.
Зачем там порт? Точнее, с чего это вдруг порт у IPv4 и у IPv6 неодинаковый?
Потому, что IP один, а приложений много. И да, я знаю про прокси. Но его нет.
И что вам мешает прописать порт 6427 и на IPv6 тоже?
затем, что это лишает IPv6 весомого преимущества (каждому сервису свой IP и стандартний порт, как следствие этого) перед IPv4, а так да — из любви к прогресу, я могу так сделать :) Правда, ни мне ни пользователям сервиса это ничего не принесёт. Просто задел на будущее.
Это весомое преимущество начнёт работать только при отказе от IPv4. В глобальной сети это будет не в ближайшие десять и не двадцать лет. Лишая пользователей возможности использовать приложение через IPv6, вы тормозите отказ от IPv4 и тем самым мешаете этому, как вы выразились, весомому преимуществу начать действовать.
Плюс к этому вы лишаете возможности пользоваться вашим приложением тех, кто уже сейчас имеет только IPv6 без IPv4 (говорят, существуют такие дешёвые VDS, хотя лично пользоваться не доводилось).
В общем, в ближайшие десять-двадцать лет лучше не выпендривайтесь и просто делайте app.example.com:8080/app для IPv4 и IPv6. За эти годы вы всё равно сломаете обратную совместимость API несколько раз, и если к тому времени большинство клиентов станут ходить к вам по IPv6, то у вас появится возможность задействовать это ваше весомое преимущество на всю катушку и отказаться от IPv4. Но не сейчас. Не спешите. Не всё сразу.
Так всегда ничем не оправданный максимализм, каприз, жадность потом переходят в стенания и опускание рук. Либо все, либо ничего — обыкновенная российская припадочная философия.
Макаренко, Антон Семёнович, 1928й год
Макаренко, Антон Семёнович, 1928й год
appA.example.com — с А и АААА записями
appB.example.com — с А и АААА записями
Вы холодное с мягким путаете. Вы пытаетесь номерами портов решить вопрос, который логичнее решать при помощи ДНС, похоже. Или у вас приложения — это не веб-приложения?..
appB.example.com — с А и АААА записями
Вы холодное с мягким путаете. Вы пытаетесь номерами портов решить вопрос, который логичнее решать при помощи ДНС, похоже. Или у вас приложения — это не веб-приложения?..
Веб, но что с того? Вот, например Sonar (https://www.sonarqube.org/) и Sentry (https://sentry.io). Первый на sonar.example.com:9000, второе на sentry.example.com:9500, оба ставятся независимо и не могут работать на одном сервере приложений, и чем мне поможет ващ мудрый совет? Спрятать все под третий продукт — reverse proxy? Купить еще немножко IP адресов? То есть заплатить своим временем или деньгами за то, без чего это работает и будет работать пока IPv4 не исчезнет с рынка?
sonar.example.com будет иметь и А и AAAA-запись, в чём проблема?
Я понимаю, советами, наверняка утомили, но хамить-то зачем?
Я понимаю, советами, наверняка утомили, но хамить-то зачем?
Я уже отвечал на это выше. Если кратко, то у меня нет клиентов только с IPv6.
AAAA-запись никак не помешает клиенту без IPv6, зато поможет с ним. И не надо будет заводить никаких дурацких appv4.example.com и appv6.example.com. Заводите один домен, как обычно, добавляете AAAA-запись. Всё.
Те у кого есть ipv6 — используют адреса из AAAA-записи, те у кого нет — из А-записи.
Те у кого есть ipv6 — используют адреса из AAAA-записи, те у кого нет — из А-записи.
А можно конкретнее — чем именно поможет и кому? Сервису? Клиенту? Инфраструктуре между нами? Ну типа — «соеденение пойдёт через друрой набор хопов и за счет меньшей нагрузки на IPv6 будет эффективней (правда за счет меньшей связаности между IPv6 сетями и нередких еще ошибок в конфигурации промежуточных роутеров может и нет :)».
Как минимум будет сделан ещё один шаг в сторону отказа от дуалстека, например. IPv6 не взлетел в первую очередь потому, что возникла рекурсиная проблема «нет IPv6-трафика от клиентов — потому что нет контента — потому что нет трафика».
А, кстати, чем ешё может помочь. Есть такая штука как «Реестр информационных ресурсов и информационно-телекоммуникационных сетей, доступ к которым ограничен», ну так вот, там нет ни одного IPv6 адрес, зато IPv4 там жирненько так, подсетями целыми. Не факт, что завтра какая-нибудь из сеток вашего хостера там не окажется.
А, кстати, чем ешё может помочь. Есть такая штука как «Реестр информационных ресурсов и информационно-телекоммуникационных сетей, доступ к которым ограничен», ну так вот, там нет ни одного IPv6 адрес, зато IPv4 там жирненько так, подсетями целыми. Не факт, что завтра какая-нибудь из сеток вашего хостера там не окажется.
А зачем мне веб приложение, скажем, на порту 8080, если в случае с IPv6 я каждому приложению могу дать свой IP и хостить его на стандартном 80 порту? А вот в случае с IPv4 я это сделать не могу — он один.
А зачем вам ставить разные порты на IPv4 и IPv6, если можно поставить один и тот же порт 8080 и не любить мозги ни себе, ни пользователям ваших приложений? Говорите пользователям — используйте app.example.com:8080/app, а через что они при этом будут ходить, IPv4 или IPv6 — уже не ваши проблемы. Зачем вы всё усложняете?
Мой вопрос изначально был именно таким — поможет ли IPv6 в моём случае, или можно не усложнять и ехать дальше на IPv4. В том варианте, который передлагаете вы — нет, не поможет. Нет у меня пользователей с чистой IPv6 сетью, а даже если бы и были, то проблем у них не будет — сейчас это работает ровно так, как вы описали — и DNS и порты :) Хотелось, для тех кто поедет на IPv6 упростить жизнь.
Нет у меня пользователей с чистой IPv6 сетью
С вашим отношением — и не появятся никогда. Вы тормозите прогресс. Не надо так.
Хотелось, для тех кто поедет на IPv6 упростить жизнь.
Выше ответил, когда эту жизнь станет возможно упростить
Я вас тоже огорчу, но не все сервисы, которые вешаются на IP + port позволяют сконфигуровать то, а чём вы говорите, даже если они потом общаются через HTTP(S). Ставить перед ними еще прокси (nginx например) не вариант.
Гы гы — счастливо вам общаться с разработчикати :) Вот тут можете свой плюсик добавить — stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t
Ставить перед ними еще прокси (nginx например) не вариант.
Вы уже как минмимум два раза упомянули, что (реверс-)прокси не вариант, а почему — я так и не понял. Всё своё, что я запускаю (да и не только своё, впрочем), висит за nginx и отлично работает. На одном домене, на единственном порту 443 и одновременно на IPv4 и IPv6, ага :) Что у вас за сервисы такие, что так нельзя?
Ну, проблем с реверс прокси много (например, некоторые сервисы используют ссылки на себя и не все они ловятся проксей автоматом), да они все решаемые, но… Чистый IPv6 решает ту же проблему намного изящней :)
Если сервисы не умеют работать с реверс-прокси, то это проблемы сервисов, а не реверс-прокси, потому что реверс-прокси это стандартная штука на подавляющем большинстве серверов. Если никто чинить сервисы не хочет, то тут уже остаётся только посочувствовать
Но это всё равно не должно быть поводом для отказа от IPv6 — никто по-прежнему не мешает вешать сервис на один и тот же IPv4/IPv6 порт. Чистый IPv6 это хорошо, но до него ещё дожить надо, не спешите
К сожалению, после установки реверс-прокси это становится моей головной болью.
А что касается отказа от IPv6, то это не совсем так — я еще N сообщений назад написал — «сейчас это работает ровно так, как вы описали — и DNS и порты». Как вы описали — это A + AAAA и тот же порт. Вот только это не значит, что вопрос с закрыт. Я понимаю, что это поможет прогрессу (уже лет этак 5), но я продолжаю утверждать, что для моих пользователей это ничего не поменяло за эти пять лет.
А что касается отказа от IPv6, то это не совсем так — я еще N сообщений назад написал — «сейчас это работает ровно так, как вы описали — и DNS и порты». Как вы описали — это A + AAAA и тот же порт. Вот только это не значит, что вопрос с закрыт. Я понимаю, что это поможет прогрессу (уже лет этак 5), но я продолжаю утверждать, что для моих пользователей это ничего не поменяло за эти пять лет.
Кстати, где-то в этой ветке ещё хотелось бы упомянуть, что в DNS существуют SRV-записи, в которых можно прописывать этот самый несчастный порт.
К примеру, в протоколе XMPP при подключении к jabber.org надо запросить SRV-запись у _xmpp-client._tcp.jabber.org и из-ответа узнать, что нужно подключаться к hermes2.jabber.org на порт 5222.
Но, к сожалению, для протокола HTTP эту штуку не используют, потому что он появился раньше SRV :(
У вас есть два пути — dualstack и NAT64.
Dualstack — все сетевые устройства поддерживают одноврмененно IPv4 и IPv6. Соответственно нагрузка на маршрутизаторы возрастает — нужно поддерживать 2 таблицы маршрутизации для каждого VRF плюs ARP и IPv6 ND таблицы для каждого VLAN. Однако с точки зрения хоста это максимально прозрачная конфигурация — просто включаешь IPv6 и ОС сама выбирает какой протокол использовать в том или ином случае. Как правило при получении DNS ответа содержащего как AAA так и АААА записи предпочтение отдается AAAA, т.е. IPv6
NAT64 — в данном случае вы можете использовать только IPv6 в вашей внутренней сети. Общение же с IPv4 сетями происходит после трансляции адресов на маршрутизаторе. Не берусь судить насколько высок оверхед на сетевой инфраструктуре по сравнению с dualstack. Данное решение выглядит более аккуратным и логичным, но только на бумаге — нужно делать PoC для каждой отдельной имплементации, чтобы убедиться в отсутствии подводных камней в реализации данного протокола в кажой конкретной железке.
Dualstack — все сетевые устройства поддерживают одноврмененно IPv4 и IPv6. Соответственно нагрузка на маршрутизаторы возрастает — нужно поддерживать 2 таблицы маршрутизации для каждого VRF плюs ARP и IPv6 ND таблицы для каждого VLAN. Однако с точки зрения хоста это максимально прозрачная конфигурация — просто включаешь IPv6 и ОС сама выбирает какой протокол использовать в том или ином случае. Как правило при получении DNS ответа содержащего как AAA так и АААА записи предпочтение отдается AAAA, т.е. IPv6
NAT64 — в данном случае вы можете использовать только IPv6 в вашей внутренней сети. Общение же с IPv4 сетями происходит после трансляции адресов на маршрутизаторе. Не берусь судить насколько высок оверхед на сетевой инфраструктуре по сравнению с dualstack. Данное решение выглядит более аккуратным и логичным, но только на бумаге — нужно делать PoC для каждой отдельной имплементации, чтобы убедиться в отсутствии подводных камней в реализации данного протокола в кажой конкретной железке.
Dualstack — не подходит по причине невозможности его поддержки у всех пользователей сервера. Да что там говорить, я даже у себя его не могу всегда включить (смотри выше пример с банком).
NAT64 — бессмыслен в моей ситуации, по причине отсутствия внутренней сети :)
Есть сервер с белым IP и несколько сервисов, разнесённых по портам. Теоретически можно включить IPv6 (вualstack только на сервере), дать каждому сервису свой IPv6 и радоваться жизни. Практически это лишено смысла — пользователи будут продолжать использовать IPv4+port, потому что это работает всегда, а им нужно работать а не модные технологии :(
NAT64 — бессмыслен в моей ситуации, по причине отсутствия внутренней сети :)
Есть сервер с белым IP и несколько сервисов, разнесённых по портам. Теоретически можно включить IPv6 (вualstack только на сервере), дать каждому сервису свой IPv6 и радоваться жизни. Практически это лишено смысла — пользователи будут продолжать использовать IPv4+port, потому что это работает всегда, а им нужно работать а не модные технологии :(
Именно поэтому внедрение IPv6 и идет так медленно — польза от него не всем очевидна. Причем это не от того, что пользователь «глюпий», а реально IPv6 далеко не всем нужен и частенько внедряется лишь как «модная технология» :)
Раз уж у вас белый IPv4 прям на сервере то можно включить 6to4 и будет у вас адрес сервера 2002:XXXX:XXXX::1 и целая /48 подсеть.
Каждая базовая станция постоянно следит за наличием свободных адресов, чтобы гарантировать подключение новых устройств. При этом IPv6 для «переключения станций» использует те же самые механизмы (handover), что и IPv4.
Полный бред. Базовая станция не имеет ни малейшего представления какой/какие у абонента IP-адреса (IPv4 или IPv6 или IPv4v6).
Всё просто. IP протоколы отвечают за доставку пакета от точки к точке. Нехватка IPv4 заставила придумывать костыли в виде NAT. IPv6 тоже имеет свой костыль для работы поверх IPv4 сетей. И любой пользователь или провайдер может завести себе IPv6 сеть через шлюз если нет возможности подключится к IPv6 напрямую.
А для мобильной да и не мобильной идентификации на уровне пакетов можно добавить уровень с хешем публичного ключа. Он позволит менять IP адреса без разрыва текущих соединений и агрегировать несколько потоков с разных провайдеров в один. Ну естественно ответные пакеты должны быть шифрованы используя этот ключ.
NAT — это не «костыль», а удобный способ скрыть узлы локальной сети от подключений извне.
Межсетевой экран — программный или программно-аппаратный элемент компьютерной сети, осуществляющий контроль и фильтрацию проходящего через него сетевого трафика в соответствии с заданными правилами.
А NAT это костыль.
Утверждение, повторенное дважды — является в два раза более убедительным.
NAT, это действительно костыль как например и DHCP.
Ну, а для скрытия узла есть межсетевой экран как правильно сказали.
Он же используется и для ipv6. DHCP в ipv6 завезли только из-за слез, уж больно entr прикипел. Хотя к машинам надо обращаться тупо по любому тебе удобному имени.
Ну, а для скрытия узла есть межсетевой экран как правильно сказали.
Он же используется и для ipv6. DHCP в ipv6 завезли только из-за слез, уж больно entr прикипел. Хотя к машинам надо обращаться тупо по любому тебе удобному имени.
Ну, а для скрытия узла есть межсетевой экран как правильно сказали.Межсетевой экран конечно есть, да он никуда и не девался. Но проблема в том, что любая минимальная ошибка в его настройке грозит открытым снаружи доступом, а ошибка в конфигурации NAT не грозит ничем. А с учётом того, что примерно в 90% случаев (да, 90%) роутер настраивается по принципу «о, вроде заработало», то сообществу ещё предстоит столкнуться с данной проблемой, и какие костыли потребуются для её решения — совершенно непонятно.
Это не проблема технологии, это проблема неграмотных пользователей, не путайте понятия. И практически все потребительские дешевые роутеры и так идут с преднастроенным фаерволом и закрытым доступом извне.
Разница в том, что с неграмотными пользователями сделать ничего нельзя, а с технологией — можно.
То есть будем резать возможности и гибкость настройки в угоду — «как бы чего плохого не вышло»?
Вы совершенно правы, давайте отменим ПДД и разрешим ездить людям без прав и на самодельных машинах. Так ведь будет более гибко.
Я понимаю что сравниваю не сравнимое, но ко всему надо подходить разумно.
Я понимаю что сравниваю не сравнимое, но ко всему надо подходить разумно.
ПДД это как раз таки пример правильных настроек, при возможностях тотальной свободы в настройках.
А пример с крайней необходимостью NAT — это каждую полосу в свой бетонный туннель закатать, и шлюзовое кпп на въезде.
А пример с крайней необходимостью NAT — это каждую полосу в свой бетонный туннель закатать, и шлюзовое кпп на въезде.
Почему все норовят отменить ПДД и суд при, например, голословных утверждениях в науке вместо принятия там сопоставимой ответственности? Давайте и тут отвечайте.
но это же повод нас тащить в средние века? так можно дорассуждаться, что и Интернет нужно по талончикам предоставлять.
Если вы думаете, что вы настроив NAT защищаете свою сеть, я вас только могу поздравить. NAT не защищает от слово совсем и обойти NAT и обратится до внутрянки сети без защиты в общем и целом не составит труда. А в 90% случаев роутеры имеют закрытый тем же самым сетевым экраном доступ в вашу сеть. Ваш КЭП.
Дополнительно — NAT заставляет нас греть воздух. Тем что нужно держать таблицу contrack в памяти и отслеживать состояние соединений. Процессор роутера напрягается. А если уж пользователь качает торренты… В общем — энергоэффективность на уровне!
А statefull фаервол не трекает соединения чтобы работало правило типа
так?
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTтак?
Так он работает на пека и сервере, где много памяти, а не на трёхгрошовом роутере с производительностью картофелины.
А Вы хорошо подумали нужен ли Вам statefull firewall с указанным правилом?
Может достаточно будет просто правил по портам или правил роутинга по хостам? По крайней мере того, что умеет работать через fastpath (fasttrack) и минимально грузить проц и сетевуху.
Может достаточно будет просто правил по портам или правил роутинга по хостам? По крайней мере того, что умеет работать через fastpath (fasttrack) и минимально грузить проц и сетевуху.
> Может достаточно будет просто правил по портам или правил роутинга по хостам?
Не будет достаточно, если надо обеспечивать свободный доступ в мир из внутренней сети, но при этом внутрь пропускать только на адреса по белому списку. А это как раз самый типичный вариант требований к настройке.
Так что — conntrack без альтернатив (как бы он ни назывался в конкретной реализации).
Не будет достаточно, если надо обеспечивать свободный доступ в мир из внутренней сети, но при этом внутрь пропускать только на адреса по белому списку. А это как раз самый типичный вариант требований к настройке.
Так что — conntrack без альтернатив (как бы он ни назывался в конкретной реализации).
Мне бы хотелось узнать хоть об одном способе, как извне обойти NAT и получить доступ к внутренним ip? Только не надо про взлом роутера и установку руткитов на машинах в локалке — от этого и файрволл никак не защитит.
Провайдер может нечаянно поставить маршрут в Вашу RFC 1918 сеть на своем пограничном роутере. Очень маловероятно, но факапы случаются. Ещё source routing есть, который, внезапно, по дефолту мало у каких железок отключен. И, не смотря на то, что «no ip source-route» везде пишут большим жирным текстом, кто-то может забыть его поставить. Чем меньше хопов, тем больше вероятность, что source routing прокатит.
NAT != firewall, и он не разрабатывался как средство защиты. Полагаться на спрятанные внутренние адреса — security through obscurity. Нужно исходить от того, что злоумышленник уже знает строение внутренней сети.
NAT != firewall, и он не разрабатывался как средство защиты. Полагаться на спрятанные внутренние адреса — security through obscurity. Нужно исходить от того, что злоумышленник уже знает строение внутренней сети.
Ну я же вроде аргументированно намекнул на то что есть межсетевой экран который как раз для контроля подключений и предназначен. А для NAT наоборот придумали дополнительный костыль который позволяет приложениям через UPnP открыть порт без участия админа.
Конечно когда уже используется NAT межсетевой экран может быть лишней сущностью. Но изначальное его предназначение это предостовление доступа в интернет через ограниченное IPv4 адресов большему количеству абонентов. Но он же пораждает проблему связи двух абонентов находящихся за NAT. А это с развитием P2P технологий, видео и аудио связи становится проблемой. Так как трафик вместо прямого пути от одного абонента к другому делает крюк через прокси сервер.
Непонятно то ли это проблема, то ли это фича. NAT фактически не даёт сделать нормальную P2P сеть: мой телефон не может запомнить адрес другого телефона и через пару дней послать ему UDP пакет. А какой смысл мешать делать P2P сети? Чтобы всё было централизованным.
Предполагаете заговор правительств?
Тут дело какое. Логически — ipv6 действительно децентрализован. Но физически — все соединения так же будут проходить через конечное количество линков, как и раньше. И в чем разница !?
Тут дело какое. Логически — ipv6 действительно децентрализован. Но физически — все соединения так же будут проходить через конечное количество линков, как и раньше. И в чем разница !?
Согласен, что NAT — это костыль.
Достаточно вспомнить каких уродцев он порождает за собой. Включая необходимость вмешиваться в трафик пользователя (такое или такое).
И hair-pin NAT.
И сложности настройки, если у нас два интерфейса смотрят в Интернет.
И попросту иллюзию защищенности (ага, про правила форварда из сети в сеть мы ес-но забываем, если есть NAT).
Достаточно вспомнить каких уродцев он порождает за собой. Включая необходимость вмешиваться в трафик пользователя (такое или такое).
И hair-pin NAT.
И сложности настройки, если у нас два интерфейса смотрят в Интернет.
И попросту иллюзию защищенности (ага, про правила форварда из сети в сеть мы ес-но забываем, если есть NAT).
Если вы настроите NAT, но не настроите межсетевой экран, извне в вашу сеть за NAT всё равно смогут подключаться.
См. habr.com/ru/post/402187/#comment_18100267 и выше.
См. habr.com/ru/post/402187/#comment_18100267 и выше.
Я пробовал по возможности использовать IPv6 на серверах, оказалось что сетевая связность в пределах IPv6 очень хреновая, и например апдейты на центос качаются со скоростью порядка 128 кб/с, на гигабитном канале. И это притом, что сервер был расположен на одном из крупнейших европейских хостингов.
На том эксперимент и закончился.
На том эксперимент и закончился.
Одиночный замер не показатель. У меня тест скорости иногда выдаёт на IPv6 скорость выше чем на IPv4 до того же узла.
На том эксперимент и закончился.
Зря. Из за одного неудачного опыта вот так все бросать. Это разные сети с разной связностью, разными маршрутами, естественно и проблемы на них могут быть разные. Иногда наоборот по ipv6 скорость лучше.
Можете аргументированно объяснить, почему по ipv6 скорость на одних и тех же маршрутах может быть выше? КЭП подсказывает, что пакеты ipv6 больше по размеру, сл-но никак не могут проходить быстрее.
Для домашнего использования вы правы.
Тут скорее вопрос в скорости принятия решения по выбору маршрута, когда магистральным маршрутизаторам приходится хранить fullview эпических размеров (следствие дробления адресного пространства) и для каждого пакета искать в нем маршрут.
Тут скорее вопрос в скорости принятия решения по выбору маршрута, когда магистральным маршрутизаторам приходится хранить fullview эпических размеров (следствие дробления адресного пространства) и для каждого пакета искать в нем маршрут.
Не такой уж он и эпический. Примерно 700 тысяч маршрутов, при том что для магистральных маршрутизаторов достаточно обычно иметь 4 миллиона. Это имеется в виду аппаратной поддержки на ASIC/TCAM, то есть там практически нет никаких затрат времени на поиски маршрутов. На задержки больше влияют расстояния, тысячи километров оптики, в которой свет распространяется ощутимо медленнее, чем в вакууме.
А маршрутизация в интернете сильно зависит от политически-коммерческих нюансов,
когда-то было запросто, что между соседними домами в одном городе трафик ходит через Амстердам или Франкфурт. Вот и может выйти, что по v4 идёт через Франкфурт, а через v6 слегка более близким путём.
А маршрутизация в интернете сильно зависит от политически-коммерческих нюансов,
когда-то было запросто, что между соседними домами в одном городе трафик ходит через Амстердам или Франкфурт. Вот и может выйти, что по v4 идёт через Франкфурт, а через v6 слегка более близким путём.
Потому что маршруты не одни и те же. Сети разные и маршруты разные.
Можно это представить, как два разных провайдера дома, оба работают, но на одном скорость чуть больше, пинги чуть меньше. А до каких конкретно адресов с какого провайдера будет лучшая связность, тут уже как повезет. Так же с dualstack.
Можно это представить, как два разных провайдера дома, оба работают, но на одном скорость чуть больше, пинги чуть меньше. А до каких конкретно адресов с какого провайдера будет лучшая связность, тут уже как повезет. Так же с dualstack.
У меня как-то была VPS-ка в Европе, с пятью разными IPv6 айпишниками из совсем разных подсетей. Так связность до них всегда «плавала». То один пингуется нормально, а потом умирает, то другой и так далее. Тоже сложилось впечатление очень сырой технологии и очень странного роутинга.
У нас гоняется реал-тайм видео от сервера к клиентам и обратно. Пришлось отключить IPv6 на сервере полностью — потери пакетов были просто огромные, ни о какой видеотрансляции речь просто не шла.
Интересно, возможна ли технология, в которую изначально будет заложено сопротивление цензуре и блокировкам интернета? Т.е. некая адресация, не привязывающая контент к каким-либо адресам вообще и исключающая возможность отследить адрес получателя. Т.е. сделать весь интернет без исключения i2p-подобным, или как-то так.
некая адресация, не привязывающая контент к каким-либо адресам вообще
ipfs, адресация по содержимому. На так только статический контент можно распространять.
В ней есть также адресация по публичному ключу что позволяет и не статический контент распростронять.
IPFS это реализация давно известной идеи которая как и все упёрлась в большой бетонный блок на дороге под названием NAT. Ключевая концепция IPFS это DHT (та которая Kademlia), а чтобы сделать хорошую DHT нужно позволить клиентским нодам (по сути телефонам) иметь предсказуемые адреса и обмениваться UDP пакетами без долгого и сложного бутстрапа. Без настоящей DHT у нас получается всё та же централизованная сеть.
В dht бутстрап начинается вроде с хотя бы одной живой ноды из захардкоженного списка в клиенте. То есть начало работы все равно централизованное как-никак(
В нормальном DHT клиенте входные встроенные ноды используются только при первом запуске. Далее клиент использует для входа тот набор узлов который собирает во время работы и в случае неудачи снова использует встроенные. Но IPFS кажись до сих пор использует только встроенные ноды для входа.
DHT — всё таки немножко о другом, о поиске содержимого и узлов где его можно найти. В том числе в виде задачи типа «найти узел с идентификатором Х и способ связаться с ним»
Таким образом DHT использет существующие связи для поиска новых. Первичный набор «существующих связей» традиционно делается бутстрапом, да. Но к этому механизму можно добавит (и в IPFS добавлено) например mDNS — поиск узлов при помощи мультикаста.
Таким образом DHT использет существующие связи для поиска новых. Первичный набор «существующих связей» традиционно делается бутстрапом, да. Но к этому механизму можно добавит (и в IPFS добавлено) например mDNS — поиск узлов при помощи мультикаста.
Думается мне, что правительства некоторых стран будут сильно против внедрения подобной технологии.
За ipv6 будущее, так или иначе. ipv4 становится проблемой в плане цены и доступности.
Дома я использую ipv6 через туннель от HE уже несколько лет и примерно 10-20% домашнего трафика у меня идет через него. О внедрении нативного ipv6 российскими провайдерами даже не мечтаю, им это, как и 99,9% абонентов, нахрен не надо, к сожалению.
На vps серверах уже давно ipv6 адреса это стандарт, хотя многие до сих пор выдают только единичные ip адреса, а не подсети, что неправильно. Немалую роль в распространении протокола, я считаю, вносит CloudFlare, все сайты за ним доступны по ipv6. Сайтам за CloudFlare и вовсе не обязательно иметь ipv4 адрес, у меня там несколько сайтов и все с одной AAAA dns записью.
Дома я использую ipv6 через туннель от HE уже несколько лет и примерно 10-20% домашнего трафика у меня идет через него. О внедрении нативного ipv6 российскими провайдерами даже не мечтаю, им это, как и 99,9% абонентов, нахрен не надо, к сожалению.
На vps серверах уже давно ipv6 адреса это стандарт, хотя многие до сих пор выдают только единичные ip адреса, а не подсети, что неправильно. Немалую роль в распространении протокола, я считаю, вносит CloudFlare, все сайты за ним доступны по ipv6. Сайтам за CloudFlare и вовсе не обязательно иметь ipv4 адрес, у меня там несколько сайтов и все с одной AAAA dns записью.
На самом деле тот факт, что российские провайдеры «не чешутся» немного удручает. Потому что в США, Европе и многих других странах всё идёт плану: 50% пользователей уже на IPv6, ещё 2-3 года — и вы получите от некоторых сервисов заявление что, всё, без IPv6 мы вам сервис предоставлять не будем… И что тогда будут делать абоненты, которым до этого момента всё «нахрен не надо» было?
Удивительно как люди умудряются годами танцевать на одних и тех же граблях: «внезапное» исчезновение Java и Flash, «внезапный» отказ от костылей с EDNS и прочее… такое ощущение, как будто им прямо в кайф довести всё до телефонных звонков — а потом всё чинить ночами, сидя на энергетиках…
Удивительно как люди умудряются годами танцевать на одних и тех же граблях: «внезапное» исчезновение Java и Flash, «внезапный» отказ от костылей с EDNS и прочее… такое ощущение, как будто им прямо в кайф довести всё до телефонных звонков — а потом всё чинить ночами, сидя на энергетиках…
Тоже дома использую туннель от HE, с цифрами полностью согласен, посмотрел свои графики и получается около 20% трафика через IPv6.
Эх, 2019-й на дворе, мой провайдер (один крупнейших в РФ) до сих пор ничего не знает о IPv6, даже 6to4 не поддерживает.
К вам пинги от 192.88.99.1 возвращаются? Если да то попробую довести до ума 6to4 пингер и дать протестить.
Пинги не значат 100% успеха. Оно может пинговаться, но не работать.
Пока айпишник белый, работает, как меняется на серый, перестает.
6to4 зависит от внешнего IPv4. Если внешний IPv4 меняется соответственно надо менять и IPv6 на соответствующий новому.
На сером IPv4 нужно добавлять в IPv6 после внешнего IPv4 ещё два октета со случайным числом и брать зону /64. Я так на сером IPv4 три тунеля поднял. Работают нормально.
Мне кажется на сером сильно зависит от вида NAT и настроек файрвола провайдера. В общем случае не стоит надеяться на работу 6to4 за NAT'ом.
Да может мне просто везёт с провайдерами. В любом случае я запилил ping6to4 и можно проверить работает ли тунель через NAT.
Только надо отключить isatap чтоб тот 6to4 пакеты не перехватывал.
netsh interface isatap set state disabled
Возможно 6to4 тоже надо вырубить на время теста.
Ну и запускать пингер надо из под админа.
>Слишком затратно это
Интересно, что они там затратного то нашли?
Интересно, что они там затратного то нашли?
Когда я работал админом у ISP уже почти 20 лет назад, BGP full view весила около 120МБ. Роутеру нужно было выкачивать эти 120МБ от каждого соседа, и хранить эти данные у себя в памяти. Память для кошек в то время стоила ой-ой как недёшево. Сейчас, думаю, BGP v4 таблицы «распухли» раза в 2, не меньше. Внедрение ipv6 увеличит эти таблицы ещё в разы — а это память пограничных роутеров, потребуется апгрейд — вот вам и прямые затраты.
Создатели технологии предлагают заменить IP-адрес устройства иерархическим именем, например2:5020/123.45 ;-)
И сломав все, что можно, т.к. 256 значений — это байт. А 1024 — ? Дробное количество байт?
И чтобы решило расширение с 256 значений до 1024? Принципиально?
И чтобы решило расширение с 256 значений до 1024? Принципиально?
может надо было с переди и сзади еще по байту добавить? и один вложить в другой протокол.
Так и было сделано: IPv6 адреса, в частности, можно получить из Mac-адреса. Там как раз спереди и сзади байт добавляется (ну и ещё сам Mac инвертируется).
Я имел в виду из IPv4.
А смысл? Там даже несколько протоколов, но в сухом остатке: они решают совсем не ту проблему. IPv6 в IPv4 «не вкладывается» (иначе не имело бы смысла и огород городить), а вложив IPv4 в IPv6 (одним из нескольких способов) вы решите проблему того, как передать данные IPv4 через IPv6-Интернет (которого нет) для IPv4-интернета (который есть).
Вот лет через 20, когда от IPv4 останутся только «островки» — этот подход будет очень актуален… но для внедрения IPv6 — нет.
Вот лет через 20, когда от IPv4 останутся только «островки» — этот подход будет очень актуален… но для внедрения IPv6 — нет.
Первое из них — Named Data Networking (NDN). Создатели технологии предлагают заменить IP-адрес устройства иерархическим именем, например /ucla/videos/demo.mpg/1/3.
UUCP переизобретают, не иначе:
User barbox!user would generally publish their UUCP email address in a form such as …!bigsite!foovax!barbox!user. This directs people to route their mail to machine bigsite (presumably a well-known and well-connected machine accessible to everybody) and from there through the machine foovax to the account of user user on barbox.
У нас ряд приложений в AppStore не проходили модерацию, из-за того что у проверяющего сервера не были доступны по ipv6.
Я думаю если крупные компании, типа Google и Apple введут в обязательные требования доступность по ipv6 серверов с которыми работают приложения, это даст значительный буст.
Я думаю если крупные компании, типа Google и Apple введут в обязательные требования доступность по ipv6 серверов с которыми работают приложения, это даст значительный буст.
Создатели технологии предлагают заменить IP-адрес устройства иерархическим именем, например /ucla/videos/demo.mpg/1/3.
В России будет начинаться с корня «РНК». А РКН просто будет «забывать» те ветки, которые содержат контент, которые «что-то им не понравился» (про законность не говорим).
Письменность существует несколько тысяч лет, однако до сих пор почти восемьсот миллионов взрослых людей неграмотны. Есть мнение, что письменность провалилась?
Текст статьи не столь пессимистичен, как её название. Из текста следует, что движение вперёд есть, хоть и медленное.
Текст статьи не столь пессимистичен, как её название. Из текста следует, что движение вперёд есть, хоть и медленное.
IPv6 не провалился, но вот в плане безглючности работы у него всё очень плохо ибо реализацию в соответствии с RFC мало кто пилит, обычно пилят через одно место и работает оно соответствующим образом.
Сам по себе IPv6 прекрасен. Из него изначально убраны костыли, на которых держится весь мир IPv4 в наше время. Как простейшие примеры — зачем нужно отдельное понятие broadcast, если есть multicast? NAT — кошмарнейший костыль, призванный решить проблему нехватки адресного пространства. Никакой «дополнительной безопасностью» там и не пахнет — цитируя популярную шутку, «буква S в аббревиатуре NAT означает Security».
Вот только есть одна сложность, которая сопровождает каждого IT-специалиста на протяжении всей его жизни, мешая жить, спать и внедрять новые классные технологии, вроде IPv6. Имя ей — Legacy, авторы её неизвестны, и подвиг их бессмертен. А поддерживать dual-stack конечному пользователю — это уже практически инновации ради инноваций.
Вот только есть одна сложность, которая сопровождает каждого IT-специалиста на протяжении всей его жизни, мешая жить, спать и внедрять новые классные технологии, вроде IPv6. Имя ей — Legacy, авторы её неизвестны, и подвиг их бессмертен. А поддерживать dual-stack конечному пользователю — это уже практически инновации ради инноваций.
Даже habr.com не вещает по IPv6 о чем вы? :) Хотя на удивление мой провайдер последней мили по DHCP выдает v6 адресацию…
nslookup -q=AAAA habr.com 2001:4860:4860::8844
Server: 2001:4860:4860::8844
Address: 2001:4860:4860::8844#53
Non-authoritative answer:
*** Can't find habr.com: No answer
Authoritative answers can be found from:
habr.com
origin = ns1.habradns.net
mail addr = nsmaster.habralab.ru
serial = 2019011501
refresh = 3600
retry = 900
expire = 1209600
minimum = 3600
У этого ответ простой — хабр работает через анти-ддос сервис Qrator, который IPv6 не предоставляет.
Вот тоже странно, серьезный сервис, на передовой технологий так сказать, а такие технологии сам и не поддерживает… У меня был опыт работы с другим сервисом не знаю насколько он крупный по v4 десятки гигабит могут фильтровать и они же по крайней мере в переписке сказали, что и IPv6 они могут, но за отдельные деньги
ИМХО, отлично бы подошла адресация, по типу как было в fidonet:
Zone:Net/Node.Point — 4D-адресация, имя сети по умолчанию fidonet.
и было бы что-то типа ripe:ua/kh.123123, все просто и понятно
Zone:Net/Node.Point — 4D-адресация, имя сети по умолчанию fidonet.
и было бы что-то типа ripe:ua/kh.123123, все просто и понятно
С какой скоростью вы сможете маршрутизировать трафик в такой сети? Предположим, у вас в устройство приходит 10 линков по 40G. Это всего-то навсего 400 гигабит. 6.2 гигапакета для linespeed (в каждую сторону по 400 гигабит). Таблица маршрутизации около 500к префиксов. Сколько у вас lookup одного адреса займёт? В один поток надо укладываться за 16 нс. (на всё про всё — распарсить, найти маршрут, сформировать новый заголовок, отправить). Если потоков 40, можно «расслабиться» и делать это за 0.64мкс.
IPv6 не провалился, а борется с инерцией вендоров и энтерпрайза.
Любой другой «заменитель ipv4» будет бороться не только с ipv4, но и с ipv6, т.е. гарантировано провалится ещё больше.
А ситуация такая — ipv4 всё дорожают и дорожают. Пока межоператорские цены всё ещё ниже клиентских (цены IP для виртуалки), но растут. В какой-то момент поползут и клиентские, и будет «ой».
Любой другой «заменитель ipv4» будет бороться не только с ipv4, но и с ipv6, т.е. гарантировано провалится ещё больше.
А ситуация такая — ipv4 всё дорожают и дорожают. Пока межоператорские цены всё ещё ниже клиентских (цены IP для виртуалки), но растут. В какой-то момент поползут и клиентские, и будет «ой».
IP6 зарубили, чтобы не плодить P2P-сети.
Холопы электронного концлагеря должны сидеть за NATами с серых динамических адресов и посещать только сайты из «белого списка» Хозяина по хозяйским сертификатам из хозяйских браузеров, склёпанных по хозяйским стандартам.
Коммунизм закончился. Вольные 90-е закончились. Добро пожаловать в 1984-й!
Холопы электронного концлагеря должны сидеть за NATами с серых динамических адресов и посещать только сайты из «белого списка» Хозяина по хозяйским сертификатам из хозяйских браузеров, склёпанных по хозяйским стандартам.
Коммунизм закончился. Вольные 90-е закончились. Добро пожаловать в 1984-й!
Создатели технологии предлагают заменить IP-адрес устройства иерархическим именем, например /ucla/videos/demo.mpg/1/3. Такой подход разработчики назвали «информационно-центрированным». В этом случае приложения могут представлять зависимости между данными в виде иерархии.
Ничто не ново под луной…
2:5030/687.2XX
Достаточно было перейти на «телефонную» адресацию, делов-то.
Сейчас особой необходимости в нем нету, у меня провайдер выдает белый ип бесплатно всем кто попросит, вот когда он будет стоить хотя бы $10/месяц тогда думаю будет рентабельно.
По поводу розовый мечты что всё бытовые приборы будут со своим ип, это звучит прикольно на на деле у меня дома сейчас нету нечего из интернет вещей, и думаю 99% таких.
Так же я не совсем понимаю почему сейчас требуется менять роутеры куда делась модель оси, она вроде как для этого же и придумана мы ведь физически нечего не меняем и даже на канальном уровне всё остается тот же ethernet, то есть почему не достаточно прошивки роутеров и сетевых карт?
куда делась модель оси
А что, её кто-то доставал? Модель IP появилась немножко раньше модели OSI ;)
Ну а если серьезно, то вопрос составляет таблица маршрутизации — её размер, и скорость поиска по ней. Прошивкой можно добавить возможности ipv6, конечно же, но вот влезет ли таблица в память? Какой будет скорость работы(где-то выше упоминались хардварные решения для ipv4)?
Все подобные бредни рождаются из того, что люди разучились делать даже самый примитичвный факт-чекинг. Вот совсем. Давайте я вам покажу как это делается.
Вот у нас есть факт: самая быстрый канал у нас — это 160 терабит. В секунду. Один пакет — 1500 байт. Самый быстрый процессор (плюс минус) — это 3.2GHz, 64 ядра. Если посчитать — получим примерно два такта на пакет.
Ну хорошо, всунули пару таких или, может, 4-8 в роутер (ну не 1000 же их туда всовывать?)… получим, ну, от силы — полсотни тактов на пакет.
Вот можно xPomaHx миллиарды долларов и кучу программистов — но напишет он софт, который обрабатывает пакет за полсотни тактов. Ну никак. Там будет масса мест в которые он упрётся: шина, память и много чего ещё.
Что это значит? А значит это, что магистральные роутеры не обрабатывают пакеты на CPU — это попросту не работает.
Там ASIC. Специализированный чип под конкретный протокол. IPv4 или IPv6.
Да, таблицы марштуризации или что-то там ещё — может обрабатывать софт. Но сами пакеты — нет. Простой счёт «на пальцах» это показывает.
Соответственно если «в железе» у вас IPv6 нету — никакая прошивка этого не изменит.
Вот у нас есть факт: самая быстрый канал у нас — это 160 терабит. В секунду. Один пакет — 1500 байт. Самый быстрый процессор (плюс минус) — это 3.2GHz, 64 ядра. Если посчитать — получим примерно два такта на пакет.
Ну хорошо, всунули пару таких или, может, 4-8 в роутер (ну не 1000 же их туда всовывать?)… получим, ну, от силы — полсотни тактов на пакет.
Вот можно xPomaHx миллиарды долларов и кучу программистов — но напишет он софт, который обрабатывает пакет за полсотни тактов. Ну никак. Там будет масса мест в которые он упрётся: шина, память и много чего ещё.
Что это значит? А значит это, что магистральные роутеры не обрабатывают пакеты на CPU — это попросту не работает.
Там ASIC. Специализированный чип под конкретный протокол. IPv4 или IPv6.
Да, таблицы марштуризации или что-то там ещё — может обрабатывать софт. Но сами пакеты — нет. Простой счёт «на пальцах» это показывает.
Соответственно если «в железе» у вас IPv6 нету — никакая прошивка этого не изменит.
Но опять же — это все относится только к у-вам провайдерского или операторского уровня. Я совершенно не верю, что домашнему ТП-ЛИНКУ нужно держать в памяти 100500 ipv6 маршрутов. Его задача совершенно другая — ну, раздать адреса по DHCP в локалке от провайдера и привет (а их там будут максимум десятки).
ОК. Остается еще средний бизнес, который закупил цисок, но он и так, и так страдать будет )
ОК. Остается еще средний бизнес, который закупил цисок, но он и так, и так страдать будет )
В цисках, даже уровня SOHO, поддержка IPv6 появилась довольно давно, лет так 10-15 назад уже было.
И именно поэтому у IPv6 шансы есть, а ни у чего другого — нет.
Потому что любой другой альтернативе предстоит тот же самый путь: быть добавленной в роутеры, но при этом в выключенном виде (ибо админам пофиг), потом, потихоньку, включаться.
Ну или лет через 10-15, накануне победы, обсуждения… взлетит или не взлетит?
Потому что любой другой альтернативе предстоит тот же самый путь: быть добавленной в роутеры, но при этом в выключенном виде (ибо админам пофиг), потом, потихоньку, включаться.
Ну или лет через 10-15, накануне победы, обсуждения… взлетит или не взлетит?
Здесь есть две проблемы. Техническая и маркетинговая.
0) Суровые маршрутизатизаторы часто содержат значительно больше настроек и правил, многие из которых нужно ощутимо переделывать для ipv6, да и требуют ресурсов они немало. Простейший пример — таблица bgp. Она и так растёт сильно, что старое железо уже далеко не всегда справляется даже с парой каналов. С ipv6 она значительно вырастет — не поместится и одна штука в существующее железо.
1) Зачем делать новый софт под кучи старых маршрутизаторов/коммутаторов, если можно продать людям новый?
0) Суровые маршрутизатизаторы часто содержат значительно больше настроек и правил, многие из которых нужно ощутимо переделывать для ipv6, да и требуют ресурсов они немало. Простейший пример — таблица bgp. Она и так растёт сильно, что старое железо уже далеко не всегда справляется даже с парой каналов. С ipv6 она значительно вырастет — не поместится и одна штука в существующее железо.
1) Зачем делать новый софт под кучи старых маршрутизаторов/коммутаторов, если можно продать людям новый?
Можно сколь угодно долго выискивать крайнего, но это ни к чему не приведет. Пользователи инета они все разные. И выгода при внедрении новых технологий для разных групп разная.
Нет. Освобождение IPv4 — это сильно следующий этап. Сильно. Для начала идёт речь об обзаведении IPv6 в дополнение к IPv4.
Нет. Люди просто получают IPv6 диапазон и становятся доступны по обоим протоколам. То есть в DNS теперь два типа записи A и AAAA для IPv4 и IPv6 соответственно. Далее уже пользовательское програмное обеспечение решает какой протокол использовать для связи с хостом.
Странно читать про экспертов, которые упрекают IPv6 в том что он работает по тому же принципу что и v4. Или же автор вырвал это из контекста. IPv6 решает конкретную проблему которую хорошо что увидели еще до её появления и благодаря этому сейчас, когда она появилась на горизонте, инфраструктура уже не просто готова, а частично перешла на новый протокол.
Есть мнение: IPv6 провалился — кто и почему так считает