Comments 143
В IPV6 есть мультикаст в Интернете?! Это точно?!
Нет, сынок, это фантастика… (с)
Поражен продемонстрированным вами высоким профессиональным уровнем в этом обсуждении
Так что, есть или нет? Я считал, что ни в IPv4, ни в IPv6 мультикаст не будет работать без содействия маршрутизаторов (и владеющих ими провайдеров). Я неправ?
v4 точно нет, v6 — я не настолько в теме, чтобы ответить, я считал что нет, автор темы пишет что да, вот я собственно и спросил…
потому что цена вопроса очень высокая, но и стандарт пишут тоже не самые простые ребята, они могли бы продвинуть такое…
потому что цена вопроса очень высокая, но и стандарт пишут тоже не самые простые ребята, они могли бы продвинуть такое…
В IPv4 multicast является необязательной фичей, а в IPv6 — обязательной. Конечно, ничто (кроме несоотвествия спецификации) не мешает провайдерам отключать его или брыть дополнительную плату.
Т.е. «обязательность мультикаста в IPv6» это всего лишь слова, т.к. ответственности перед интернет-сообществом или отдельными пользователями за отключение, как я понимаю, механизмов выделения и маршрутизации мультикаст-групп, не предусмотрено(?)… Чем это тогда отличается от мультикаста в IPv4?
Регистрация: www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml
Насчёт ответственности: предположим, вам провайдер завтра зафильтрует UDP. Какая ответственность за это предусмотрена в IPv4?
Насчёт ответственности: предположим, вам провайдер завтра зафильтрует UDP. Какая ответственность за это предусмотрена в IPv4?
Гнев раздосадованных геймеров и телекомьютеров. Тогда как мультимедийное ПО, которое умеет мультикаст, как правило, будет работать и без оного, юникастом (ещё и трафика больше можно будет клиенту продать).
Конечно, документация по IPv6 хороша тем, что там в одном месте собрана куча последних замечательных нововведений, таких как link-local address assignment, discovery и т.п. Но это-то, с другой стороны, и плохо, т.к. сделать IPv6 систему, которая сразу поддерживает всё там описанное — гораздо сложнее, чем сделать IPv4 систему, которая поддерживает заданный наперёд набор RFC, итеративно добавляя конкретную функциональность к уже поддерживаемой.
P.S. аналог приведённой вами портянки для IPv4: www.iana.org/assignments/multicast-addresses/multicast-addresses.txt
P.P.S. под обязательным мультикастом я подразумеваю возможность выделения динамических адресов под группы, tools.ietf.org/html/rfc4607.
Конечно, документация по IPv6 хороша тем, что там в одном месте собрана куча последних замечательных нововведений, таких как link-local address assignment, discovery и т.п. Но это-то, с другой стороны, и плохо, т.к. сделать IPv6 систему, которая сразу поддерживает всё там описанное — гораздо сложнее, чем сделать IPv4 систему, которая поддерживает заданный наперёд набор RFC, итеративно добавляя конкретную функциональность к уже поддерживаемой.
P.S. аналог приведённой вами портянки для IPv4: www.iana.org/assignments/multicast-addresses/multicast-addresses.txt
P.P.S. под обязательным мультикастом я подразумеваю возможность выделения динамических адресов под группы, tools.ietf.org/html/rfc4607.
А как происходит соединение с сайтами, которым назначено несколько ip адресов?
Утверждения о безграничности ipv6 несколько преувеличены. С учётом, что уникаст — это /3, а на сайт выделяется /48, мы получаем 2^45 сайтов. Что, конечно, лучше, чем число ip-адресов, но всё-таки величина очень конечная — 32 триллиона.
Заметим, что при грамотном плане нумерации, реально из этого будет роздана дай бог четверть, а то и меньше.
Заметим, что при грамотном плане нумерации, реально из этого будет роздана дай бог четверть, а то и меньше.
А почему бы сразу не сделать 8-уровневую систему IP адоесов? Ведь неизвестно, что нас ждет в будущем. Я думаю в 81-ом никто и предположить не мог, что IP-адреса когда-то закончатся.
на сайт — /64
на физика — /64
на юрика — /56
на провайдера — мин /32 или /48
на физика — /64
на юрика — /56
на провайдера — мин /32 или /48
Очень нелогично выделать на одного пользователя только /64. Если ему вдруг понадобится subnetting (виртуальные машины в отдельную подсеть выделить или ещё что-нибудь), он потеряет возможность пользоваться SLAAC.
Неправильно. Во-первых, использовать несколько префиксов плохо. Во-вторых, политика простая: если сайту (отдельной административной зоне) нужно адресное пространство для внутренней маршрутизации, то это /48. /64 — если маршрутизация (внутри сайта) не требуется.
Это я по итогам августовского семинара RIPE говорю. У них в тестовом задании были «маршрутизирующие холодильники с VoIP'ом», так на них предполагалось выделять по /48 на каждый. Итого — /32 на миллион холодильников.
Это я по итогам августовского семинара RIPE говорю. У них в тестовом задании были «маршрутизирующие холодильники с VoIP'ом», так на них предполагалось выделять по /48 на каждый. Итого — /32 на миллион холодильников.
tools.ietf.org/html/rfc6177
In 2005, the RIRs began discussing IPv6 address assignment policy again. Since then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE], and RIPE [RIPE-ENDSITE] have revised the end site assignment policy to encourage the assignment of smaller (i.e., /56) blocks to end sites.
У нас LIR продают мин /48 и по цене от 550 €
Несмотря на требование:
The minimum allocation size for IPv6 address space is /32.
Несмотря на требование:
The minimum allocation size for IPv6 address space is /32.
Эфирное телевещание при такой схеме даже представить страшно.
RTP? Чес слово, такая штука есть даже у региональных провайдеров, и она даже работает. Благо IGMP поддерживается достаточным классом железяк.
у региональных конечно есть, в любой сети где все маршрутизаторы под контролем, это не особенно сложно…
а вот скажите, куда мне пойти, и кому заплатить, чтобы получить этот самый заветный мультикаст-адресочек для всего Интернета?
а вот скажите, куда мне пойти, и кому заплатить, чтобы получить этот самый заветный мультикаст-адресочек для всего Интернета?
А у вас есть уверенность, что оно всему интернету нужно?
У меня есть уверенность в том, что мне нужно, чтобы любой пользователь Интернета при желании мог присоединиться к моей группе мультикаста.
Поделитесь, пожалуйста, соображениями — зачем Вам это.
То, сколько трафика генерирует youtube, с одной стороны, говорит, что как минимум доля истины в ваших словах есть. Но он же упрямо доказывает, что толщина каналов и количество серверов вполне способны с этим справиться.
Мысли, почему это не востребовано:
1. Локальные ISP уже сами выстроили инфраструктуру для вещания ЦТВ по своим сетям, притом количество каналов у них вполне достойное (т.е. большого резона это просто через интернет гнать нет);
2. для значительно части народонаселения удобнее не за вещанием следить (оно ведь real-time), а в удобное время его поглядеть. Учитывая скорости — это можно делать на лету даже для 720-1080p (а где нельзя — там мультикаст-вещание тоже не потянет).
То, сколько трафика генерирует youtube, с одной стороны, говорит, что как минимум доля истины в ваших словах есть. Но он же упрямо доказывает, что толщина каналов и количество серверов вполне способны с этим справиться.
Мысли, почему это не востребовано:
1. Локальные ISP уже сами выстроили инфраструктуру для вещания ЦТВ по своим сетям, притом количество каналов у них вполне достойное (т.е. большого резона это просто через интернет гнать нет);
2. для значительно части народонаселения удобнее не за вещанием следить (оно ведь real-time), а в удобное время его поглядеть. Учитывая скорости — это можно делать на лету даже для 720-1080p (а где нельзя — там мультикаст-вещание тоже не потянет).
Но он же упрямо доказывает, что толщина каналов и количество серверов
вполне способны с этим справиться.
Зачем вкладывать деньги в каналы и серверы, если можно без этого обойтись?
Жалко, что пока что обойтись нельзя.
вполне способны с этим справиться.
Зачем вкладывать деньги в каналы и серверы, если можно без этого обойтись?
Жалко, что пока что обойтись нельзя.
Это капец как востребовано, но это миллиардный бизнес и Tier 1 провайдеры это ограничивают.
Вы отталкиваетесь от того, что эфирное вещание уже умерло, но это не так. Достаточно посмотреть на проблемы вещания по время крупных спортивных мероприятий. Никто не хочет смотреть финал кубка UEFA в повторе, все хотят смотреть в рилтайме. И эти все — дикие миллионы людей. Это один из примеров, например.
Штука в том, что событий, которые хочется посмотреть в рилтайме довольно много. Различные концерты, праздники, движуха идёт постоянно. И если вам неинтересен Новый Год в Нью-Йорке, это ещё не значит что вещание не соберёт миллиона зрителей.
Вот в чём дело, да.
Штука в том, что событий, которые хочется посмотреть в рилтайме довольно много. Различные концерты, праздники, движуха идёт постоянно. И если вам неинтересен Новый Год в Нью-Йорке, это ещё не значит что вещание не соберёт миллиона зрителей.
Вот в чём дело, да.
Я отталкиваюсь от того, что все необходимое для него _уже_ успешно используется. Каналы вещают ТВ и продают его в том числе провайдерам. Провайдеры передают ТВ до каждого абонента через существующие средства мультикаста.
А на концерты я предпочитаю ходить, а не смотреть по телеку. А уж если смотреть — то фиолетово, с каким лагом.
А на концерты я предпочитаю ходить, а не смотреть по телеку. А уж если смотреть — то фиолетово, с каким лагом.
А вот как обстоит дело с Ipv4/IPv6 в ГЗ МГУ:
Так что какой-то прогресс есть, что не может не радовать.
Так что какой-то прогресс есть, что не может не радовать.
Как там, кстати, до сих пор «самая большая неструктурированная сеть в европе»?) Помню, участвовал во всем этом безобразии годах эдак в 2003-2005…
Вроде бы почти везде уже официалка.
И что, разрешили тянуть по колодцам?
А Водолазский еще там?
А Водолазский еще там?
Неплохо у вас там с каналами, однако. Я как раз IPv6 на работе (ISP) проталкиваю уже как почти год, пока всё упирается в CE-оборудование: очень сложно защитить от IPv6-анонсов, подмен IP и т.д. на пользовательских коммутаторах. Помимо этого его надо, IPv6-трафик надо собирать (превед, Netflow v9), считать и биллинговать. Что просто огромная головная боль.
А так в офис протянуть IPv6 получилось, в общем-то, без проблем. Вот аналогичный вашему тест, хоть скорость и пониже (с Питера):
А так в офис протянуть IPv6 получилось, в общем-то, без проблем. Вот аналогичный вашему тест, хоть скорость и пониже (с Питера):
так отрубить завтра все IP и делов-то. Через недельку все уже будут работать на 6
Как-то так?
К переходу на ipv6 «всё готово на 80%», подавляющее большинство и серверов, и пользовательских машин ipv6 уже держат. С сетевой инфраструктурой хуже, во многих случаях ipv6 поддерживается, но а) медленно и б) выключено на всякий случай, ибо безопасность и вообще надо настраивать и некуда сливать. Но при этом есть куча старого софта, есть старые маршрутизаторы, и пока длится эпоха ipv4 — их не обновят никогда. Эти «80% готовности» могут болтаться вечно.
Надежда на гугл и подобного размера компании, желательно в сговоре, чтобы собрались и объявили — всё мол, такие-то плюхи по ipv4 работать не будут. Какое-нибудь p2p killer app вполне может стать локомотивом. И рекламу, обещающую неземные блага перешедшим на шестерку. И тут же подтянутся конторы помельче, увидев возможность продать новую, ipv6-ready версию проги, домашнего роутера и т.п. Весь процесс может пройти за пару лет, главное толкнуть.
Вот кто, а важнее даже когда этот толчок сделает — вот это конечно вопрос.
Надежда на гугл и подобного размера компании, желательно в сговоре, чтобы собрались и объявили — всё мол, такие-то плюхи по ipv4 работать не будут. Какое-нибудь p2p killer app вполне может стать локомотивом. И рекламу, обещающую неземные блага перешедшим на шестерку. И тут же подтянутся конторы помельче, увидев возможность продать новую, ipv6-ready версию проги, домашнего роутера и т.п. Весь процесс может пройти за пару лет, главное толкнуть.
Вот кто, а важнее даже когда этот толчок сделает — вот это конечно вопрос.
Еще неготовы специалисты, которые еще все-таки в большинстве не освоили новую технологию :) Правда многие из них и ipv4 не освоили толком :) И видят в ipv6 препятствие из-за отсутсвия запоминаемых циферок. :)
>неготовы специалисты, которые еще все-таки в большинстве не освоили новую технологию
а нафига ее осваивать, пока не пнут?
>Надежда на гугл и подобного размера компании,
пока ISP не почешутся, нихера не двинется. впрочем, гугл, как isp мне тоже нравится.
а нафига ее осваивать, пока не пнут?
>Надежда на гугл и подобного размера компании,
пока ISP не почешутся, нихера не двинется. впрочем, гугл, как isp мне тоже нравится.
ISP — ISPsystem или конкретно ISPmanager? Во втором, насколько я знаю, уже давно есть поддержка IPv6. Но, возможно, у них есть другие продукты с такой проблемой, тогда, не помешает уточнить.
А еще стоит глянуть какой % AS владеет собственным ipv6-блоком
В «отдельно взятой стране», вопрос с ipv6 легко можно решить административно: хочешь чтобы Россвязьнадзор не отобрал лицензию на телематику — предъяви работающую ipv6 инфраструктуру.
В глобальном масштабе, правда это не прокатит (разве что если IANA начнет отбирать AS у тех провайдеров кто не сделал поддержку IPv6). Кстати, интересная тема, интересно, есть ли у кого контакты с такими организациями как IANA, надо будет им тему закинуть.
А если серьезно, то проблема внедрения IPv6 это проблема отсутствия лиц материально заинтересованных во внедрении. Сейчас же для любой фирмы что для частного клиента, что для корпоративного клиента, что для хостера, что для провайдера последней мили, что для магистрального провайдера заниматься внедрением ipv6 это просто неокупающиеся затраты сил времени и финансов.
Создать «спрос снизу на ipv6» как видим, тоже не получается, большинство конечных юзеров настолько далеки от сетевых технологий, что просто не будут покупать всякие роутеры с наклеечкой «IPv6 Ready», иначе производители сетевого оборудования уже давно бы крутили рекламу IPv6 по всем каналам.
В глобальном масштабе, правда это не прокатит (разве что если IANA начнет отбирать AS у тех провайдеров кто не сделал поддержку IPv6). Кстати, интересная тема, интересно, есть ли у кого контакты с такими организациями как IANA, надо будет им тему закинуть.
А если серьезно, то проблема внедрения IPv6 это проблема отсутствия лиц материально заинтересованных во внедрении. Сейчас же для любой фирмы что для частного клиента, что для корпоративного клиента, что для хостера, что для провайдера последней мили, что для магистрального провайдера заниматься внедрением ipv6 это просто неокупающиеся затраты сил времени и финансов.
Создать «спрос снизу на ipv6» как видим, тоже не получается, большинство конечных юзеров настолько далеки от сетевых технологий, что просто не будут покупать всякие роутеры с наклеечкой «IPv6 Ready», иначе производители сетевого оборудования уже давно бы крутили рекламу IPv6 по всем каналам.
А вот здесь нужен тот самый киллер апп. Планшетик, в котором птички или тыковки, в которые можно рубиться с соседями через p2p, который не работает без ipv6. И кто-нибудь размаха apple, google или там microsoft, который указанный планшетик разрекламирует и сделает фетишем.
Интересная утопическая мысль — чтобы заинтересованные лица проспонсировали акции типа «сдай свой старый роутер и получи новый с IPv6 за половину/четверть цены. Думаю, многие поддадутся не ломая голову о том, что означает «IPv6 Ready». Ну и параллельно ограничить/запретить импорт IPv4-only.
В том то и дело, что как раз «заинтересованные лица» (особенно и готовые при этом что-то «проспонсировать») отсутствуют. Вы-то сами-то например, готовы выступить в роли «генерального спонсора» подобной акции?
Что-то мне очень сдается, что если все-таки развернется масштабное внедрение, то это будет именно по-принципу «административное решение продавленное сверху». Сейчас попробую обосновать свою точку зрения. Для этого давайте рассмотрим основных «действующих лиц» и посмотрим насколько каждый из них является «тормозом на пути внедрения ipv6»:
Начнем с оборудования у простых массовых юзеров, если вы уж их затронули. И зададимся вопросом насколько «оборудование у юзера» тормоз для ipv6. Кстати, вообще, что это за «оборудование такое»? Это ведь, обычный говнороутер стоимостью 800-2000р (по цене и характеристикам почти что «расходник» как принтерный картридж), особенно учитывая его недолгий «2-3 летний средний срок жизни». Некоторые личности на сигареты в месяц больше тратят.
Может «информационная инфраструктура конечного юзера» — главный тормоз? Ну, во-первых ее практически нет, во-вторых среднестатистический юзер и не занимается настройкой этой «инфраструктуры», а третьих эта «сетевая инфраструктура среднестатистического домашнего юзера» опять-таки совсем, оказывается тоже не тормоз внедрения ipv6. Комп юзера которому которого говнороутер 192.168.0.1 выделил по DHCPv4 ip-адрес 192.168.0.2 так сидит в своей маленькой локальной ipv4-сети из компа и говнороутера который его дальше NATит, и он просто не увидит (если не захочет) ipv6-инфраструктуры которая имеется «по ту сторону» от роутера. Да, о существовании «какого-то там ipv6» за пределами роутера на компе юзера будет знать например ipv6-capable торрент-клиент (Но юзер при этом вообще будет не в курсах почему у него «попер вверх» рейтинг на торрент-трекерах, когда просто обновил новую версию торрент-клиента). Остальные ipv4-программы так и будут ходить как ходили через роутеровский NAT.
Advanced userы. Во-первых их единицы, а во-вторых, они вообще-то не «тормоз», а «локомотив» :) И они-то будут вкушать как прелести ipv6, так и при надобности приплачивать по 150-200р в месяц за статический ipv4-адрес (если он им нужен).
Корпоративные клиенты. Тоже нет, учитывая что основной парк машин (который мог бы вызвать какой-то массовый геморой) у них торчат в private-локалках 192.168.X.X скрытые за корпоративными проксями и натами.
Производители оборудования — про них вообще нечего сказать, они так вообще ничего не теряют, а наоборот «обоими руками и ногами за тотальное внедрение ipv6», готовы хоть завтра отгружать вагонами ipv6-capable железо, поскольку это все им по-любому копеечка в карман. Был бы только спрос… Вот только спроса нету.
Так, вот, Поэтому единственные, для кого «внедрение ipv6» это реальный геморой, связанный с нехилого масштаба реальным вложением средств, массовым привлечением людских ресурсов, расходованием кучи сил на конфигурацию, тестирование и поддержку — это провайдеры (кстати, провайдеры в широком смысле: как провайдеры последней мили и магистральных так и не в меньшей степени хостинг-провайдеры.)
Согласитесь, расходы на внедрение у провайдеров не идут ни в какое сравнение с расходами конечного юзера, выбросившего старый говнороутер на помойку и купивший новый говнороутер «всего за 999руб 99коп получив при этом в подарок фирменый стикер».
Так вот, учитывая, что провайдеры-то как раз далеко не глупые и считать деньги умеют, они просто так по доброй воли не пойдут на эти реально не малые расходы. Более того, боюсь, что как раз заставить провайдеров пойти на подобные оргомные расходы, можно только «из-под палки» (типа реальной угрозы отзыва лицензии, нехилые штрафы и прочие нехорошие санкции).
Что-то мне очень сдается, что если все-таки развернется масштабное внедрение, то это будет именно по-принципу «административное решение продавленное сверху». Сейчас попробую обосновать свою точку зрения. Для этого давайте рассмотрим основных «действующих лиц» и посмотрим насколько каждый из них является «тормозом на пути внедрения ipv6»:
Начнем с оборудования у простых массовых юзеров, если вы уж их затронули. И зададимся вопросом насколько «оборудование у юзера» тормоз для ipv6. Кстати, вообще, что это за «оборудование такое»? Это ведь, обычный говнороутер стоимостью 800-2000р (по цене и характеристикам почти что «расходник» как принтерный картридж), особенно учитывая его недолгий «2-3 летний средний срок жизни». Некоторые личности на сигареты в месяц больше тратят.
Может «информационная инфраструктура конечного юзера» — главный тормоз? Ну, во-первых ее практически нет, во-вторых среднестатистический юзер и не занимается настройкой этой «инфраструктуры», а третьих эта «сетевая инфраструктура среднестатистического домашнего юзера» опять-таки совсем, оказывается тоже не тормоз внедрения ipv6. Комп юзера которому которого говнороутер 192.168.0.1 выделил по DHCPv4 ip-адрес 192.168.0.2 так сидит в своей маленькой локальной ipv4-сети из компа и говнороутера который его дальше NATит, и он просто не увидит (если не захочет) ipv6-инфраструктуры которая имеется «по ту сторону» от роутера. Да, о существовании «какого-то там ipv6» за пределами роутера на компе юзера будет знать например ipv6-capable торрент-клиент (Но юзер при этом вообще будет не в курсах почему у него «попер вверх» рейтинг на торрент-трекерах, когда просто обновил новую версию торрент-клиента). Остальные ipv4-программы так и будут ходить как ходили через роутеровский NAT.
Advanced userы. Во-первых их единицы, а во-вторых, они вообще-то не «тормоз», а «локомотив» :) И они-то будут вкушать как прелести ipv6, так и при надобности приплачивать по 150-200р в месяц за статический ipv4-адрес (если он им нужен).
Корпоративные клиенты. Тоже нет, учитывая что основной парк машин (который мог бы вызвать какой-то массовый геморой) у них торчат в private-локалках 192.168.X.X скрытые за корпоративными проксями и натами.
Производители оборудования — про них вообще нечего сказать, они так вообще ничего не теряют, а наоборот «обоими руками и ногами за тотальное внедрение ipv6», готовы хоть завтра отгружать вагонами ipv6-capable железо, поскольку это все им по-любому копеечка в карман. Был бы только спрос… Вот только спроса нету.
Так, вот, Поэтому единственные, для кого «внедрение ipv6» это реальный геморой, связанный с нехилого масштаба реальным вложением средств, массовым привлечением людских ресурсов, расходованием кучи сил на конфигурацию, тестирование и поддержку — это провайдеры (кстати, провайдеры в широком смысле: как провайдеры последней мили и магистральных так и не в меньшей степени хостинг-провайдеры.)
Согласитесь, расходы на внедрение у провайдеров не идут ни в какое сравнение с расходами конечного юзера, выбросившего старый говнороутер на помойку и купивший новый говнороутер «всего за 999руб 99коп получив при этом в подарок фирменый стикер».
Так вот, учитывая, что провайдеры-то как раз далеко не глупые и считать деньги умеют, они просто так по доброй воли не пойдут на эти реально не малые расходы. Более того, боюсь, что как раз заставить провайдеров пойти на подобные оргомные расходы, можно только «из-под палки» (типа реальной угрозы отзыва лицензии, нехилые штрафы и прочие нехорошие санкции).
Ещё вариант, что их заставит пойти на это борьба за клиента, когда действительно NAT перестанет спасать.
Только не говорите мне, что вы, взрослый человек, всерьез верите в то, что вы только что сейчас сказали?
Поручать провайдерам «внедрять ipv6» это примерно то же самое что поручатьмилицииполиции внедрять очередной «комплекс мер против коррупции в органах мвд». Все предельно просто — никто в зравом уме не будет вставать с жопы и дергаться чтобы что-то там делать для того, что заведомо тебе же и невыгодно, вместо того чтобы очередной раз срубить невозбранный профит от спуска всех этих «очередных благородных инициатив» на тормозах.
Так вот, в связи с этим, я утверждаю, если что и «будет», так это будет далеко не «борьба за клиента» а просто повод поднять цену на внешние белые ipv4.
Кстати, как вы думаете, какой процент пользователей будет названивать провайдерам спрашивать «а вы предоставляете услуги доступа по ipv6»? Три с половиной чудика на всю необъятную Россию может быть и найдется. Ведь «клиенту» нужен далеко не «ipv6-вещь-в-себе как таковой», а всего лишь услуга полноценного доступа к возможностям IP-протокола. И именно ее и будут спрашивать, а вовсе не «какой-то там новомодный ipv6».
Посмотрите правде в глаза, будьте, в конце концов, реалистами. У вас хватит ли фантазиии (за пределами комедийного жанра конечно же ;) ), представить себе среднестатистическую «гламурную блондинку» или «пацанчика с раёна», звонящих провайдеру и толкающих речь на половину состоящую из слов «протокол», «роутер», «NAT», «туннелирование», «VPN», «IPv6/IPv4» и пр?
Если вы считаете что подавляющее большинство людей разбирается в сетевых технологиях то это означает тольк что вы сами «бородатый админ» и все ваши друзья тоже такие же «бородатые админы». А 99% населения имеют такое же представление о NATах и проблемах внедрения ipv6 не более чем о теории относительности Эйнштейна.
Вы скажете, но все-таки кому-то ведь «услуга полноценного IP-протокола» нужна? Да, конечно, нужна! Но кому? (точнее скольким процентам населения?)
Посмотрите правде в глаза: Те, кого «всякие эти ваши NATы» не устраивают, уже давным давно приплачивают провайдерам (самого начала при подключении услуг интернет) по 150р в месяц за услугу «внешний статический IP-адрес». И уж поверьте (это я уже по себе и прочим моим коллегам говорю), тому кому это надо реально (не по-приколу а для рабочих нужд), спокойно будут также платить и по 200 и 300 и 500 и даже 1000р в месяц. (А некоторые, для которых это «bussiness-critical» будут готовы платить и еще больше. На чем, не сомневайтесь, жадные провайдеры при возможности сыграют. В этом не сомневайтесь;) )
Так вот, я утверждаю, что те, кому нужен «нормальный ip-протокол», уже и так его имеют. А тем у кого его счас нет я скажу: если у вас сейчас нет внешнего ip-адреса, то пожалуйста признайтесь себе честно, значит он вам вовсе и не был никогда настолько «критически» нужен (Потому что, если было бы нужно — уже бы купили за любые деньги.)
Что из этого следует? Оопять позволю себе еще «риторический вопрос»: так ли много таких, кому это «дело жизни и смерти»? Пара-тройка людей на тысячу абонентов? И что? это разве «много»? Уж поверьте, любой провайдер у которого десяток-другой миллионов абонентов, найдет «в своих загашниках»десяток-другой тысяч «белых ipv4 адресов» для тех, кому они нужны и тех, кто готов за них при этом приплачивать.
Кстати, сразу возникла мысль вслух: А давайте подумаем, ipv4 «кончились», просто так что ли? Давайте задумаемся, куда все эти 2^32 ipv4 адресов-то подевались? не испарились же они разом? Правда «нехорошая мысль»? А еще ведь новость «все, чуваки, это пипец, finita la comedia, ipv4 закончились!» прошла еще несколько месяцев назад! Да! Несколько месяцев мы живем без ipv4-адресов! И…
Оглядитесь вокруг! Вы разве видите, что-нибудь хоть сильно изменилось?
Так вроде ведь «ничего и не произошло»! Неужели все-таки наконец-то началась смертельная «борьба за клиента»? Но я оглядываюсь по-стронам и почему-то совсем паники вокруг не вижу! Никто до сих пор из-за этого не выбросился из окна и никто от «осознания фатальности данного факта» не сделал себе сёппуку.
А Почему? А разгадка простая! Даже мой грубый расчет показывает что даже до повышения цен на услугу «статический внешний ipv4» в ближайшее время врядли дойдет. Потому что парочка-троечка моих запросов к whois говорит что у «провайдеров-монстров» имеются такие «стратегические запасы» ipv4-адресов, что даже если каждый десятый захочет себе «белый ipv4» то у них хватит без напрягов. И не только россиянам и не только гражданам стран снг, но и даже китайцам с индусами останется.
Продолжаем «крамольную мысль» по поводу закончившихся ipv4: Да, куда-то 4миллиарда ip делись, наверное все-таки осели в чьих-то руках. В чьих и зачем? Мое чутье подсказывает что «все это неспроста»: закончившиеся ipv4 адреса — это прекрасный «гарант стабильности» для текущего состояния сильно олигополизированного рынка провайдерских услуг. Никакой новый и дерзкий игрок сейчас уже просто никак не сможет вклиниться в этот рынок провайдерских услуг. Просто — уже не сможет! На провайдерском рынке нет место новым игрокам! IPv4-адресов просто нет! Ха! Ах, так вы хотите стать новым провайдером? Какой вы смелый! Наверное у вас ничего не выйдет — вам ведь тогда придется сначала договариватся с кем-то из текущих крупных игроков чтобы выделил вам кусочек ipv4 диапазона из своих «стратегических запасов» (естественно на выгодных условиях). PROFIT :)
Вот и вся «борьба за клиента». А если вдруг их будет не хватать, можно будет чуток (раза в два-три) поднять цену на услугу «внешний статический ip4-адрес» — да сразу мигом отвалятся все «ненужно-несерьезные абоненты» которых не больно и жалко было (то есть те кому это надо для всяких грузящих магистральные каналы торрентов и иже с ними «несерьезных нужд», и кто просто не готово платить лишние 300р в месяц за возможность скачать фильмичек-музычку).
А останутся только те кому это нужно «для серьезного бизнеса» (всякие VPN, доступ к серверам, корпоративным сетям, и прочим вещам без которых не жить). Т.е. те кто кто как платил 150р в месяц и не вякал точно также будет платить 300-500 и тоже особенно не будет возмущатся.
Это я к тому, что если вдруг все-таки и появится достаточно мощный спрос (среди тех клиентов кому не зватает NATа), провайдерам невыгодно будет дергаться в сторну внедрения ipv6, им выгодно будет пользуясь случаем сначала «срубить бабла на пустом месте» т.е. просто подняв чуток цены на услуги «внешние белые ipv4». И все!
А еще при этом никто не будет жаловаться и паниковать! Вся эта «буря в стакане вокруг NAT и IPv4/IPv6» даже если и возникнет, она вообще практически пройдет незамеченной (в широких массах). Пресловутые 95%, которым интернет нужен чтобы зайти во вконтактичек/однокласнички, затем проверить почту, а затем вбив в адресной строке гугля запрос «фишки.нет» остаток для рассматривать прикольные картинки, при этом не будут подозревать что это все у них осуществлялось за счет такой мощной сетевой технологии как NAT.
А на оставшиеся 5% «тех которые advanced» (и которых не устраивает NAT, и тех которые готовы раскошелится), уж поверьте, провайдеры не минут пользуясь случаем, напоследок «навариться».
Увы, PROFIT же.
Поручать провайдерам «внедрять ipv6» это примерно то же самое что поручать
Так вот, в связи с этим, я утверждаю, если что и «будет», так это будет далеко не «борьба за клиента» а просто повод поднять цену на внешние белые ipv4.
Кстати, как вы думаете, какой процент пользователей будет названивать провайдерам спрашивать «а вы предоставляете услуги доступа по ipv6»? Три с половиной чудика на всю необъятную Россию может быть и найдется. Ведь «клиенту» нужен далеко не «ipv6-вещь-в-себе как таковой», а всего лишь услуга полноценного доступа к возможностям IP-протокола. И именно ее и будут спрашивать, а вовсе не «какой-то там новомодный ipv6».
Посмотрите правде в глаза, будьте, в конце концов, реалистами. У вас хватит ли фантазиии (за пределами комедийного жанра конечно же ;) ), представить себе среднестатистическую «гламурную блондинку» или «пацанчика с раёна», звонящих провайдеру и толкающих речь на половину состоящую из слов «протокол», «роутер», «NAT», «туннелирование», «VPN», «IPv6/IPv4» и пр?
Если вы считаете что подавляющее большинство людей разбирается в сетевых технологиях то это означает тольк что вы сами «бородатый админ» и все ваши друзья тоже такие же «бородатые админы». А 99% населения имеют такое же представление о NATах и проблемах внедрения ipv6 не более чем о теории относительности Эйнштейна.
Вы скажете, но все-таки кому-то ведь «услуга полноценного IP-протокола» нужна? Да, конечно, нужна! Но кому? (точнее скольким процентам населения?)
Посмотрите правде в глаза: Те, кого «всякие эти ваши NATы» не устраивают, уже давным давно приплачивают провайдерам (самого начала при подключении услуг интернет) по 150р в месяц за услугу «внешний статический IP-адрес». И уж поверьте (это я уже по себе и прочим моим коллегам говорю), тому кому это надо реально (не по-приколу а для рабочих нужд), спокойно будут также платить и по 200 и 300 и 500 и даже 1000р в месяц. (А некоторые, для которых это «bussiness-critical» будут готовы платить и еще больше. На чем, не сомневайтесь, жадные провайдеры при возможности сыграют. В этом не сомневайтесь;) )
Так вот, я утверждаю, что те, кому нужен «нормальный ip-протокол», уже и так его имеют. А тем у кого его счас нет я скажу: если у вас сейчас нет внешнего ip-адреса, то пожалуйста признайтесь себе честно, значит он вам вовсе и не был никогда настолько «критически» нужен (Потому что, если было бы нужно — уже бы купили за любые деньги.)
Что из этого следует? Оопять позволю себе еще «риторический вопрос»: так ли много таких, кому это «дело жизни и смерти»? Пара-тройка людей на тысячу абонентов? И что? это разве «много»? Уж поверьте, любой провайдер у которого десяток-другой миллионов абонентов, найдет «в своих загашниках»десяток-другой тысяч «белых ipv4 адресов» для тех, кому они нужны и тех, кто готов за них при этом приплачивать.
Кстати, сразу возникла мысль вслух: А давайте подумаем, ipv4 «кончились», просто так что ли? Давайте задумаемся, куда все эти 2^32 ipv4 адресов-то подевались? не испарились же они разом? Правда «нехорошая мысль»? А еще ведь новость «все, чуваки, это пипец, finita la comedia, ipv4 закончились!» прошла еще несколько месяцев назад! Да! Несколько месяцев мы живем без ipv4-адресов! И…
Оглядитесь вокруг! Вы разве видите, что-нибудь хоть сильно изменилось?
Так вроде ведь «ничего и не произошло»! Неужели все-таки наконец-то началась смертельная «борьба за клиента»? Но я оглядываюсь по-стронам и почему-то совсем паники вокруг не вижу! Никто до сих пор из-за этого не выбросился из окна и никто от «осознания фатальности данного факта» не сделал себе сёппуку.
А Почему? А разгадка простая! Даже мой грубый расчет показывает что даже до повышения цен на услугу «статический внешний ipv4» в ближайшее время врядли дойдет. Потому что парочка-троечка моих запросов к whois говорит что у «провайдеров-монстров» имеются такие «стратегические запасы» ipv4-адресов, что даже если каждый десятый захочет себе «белый ipv4» то у них хватит без напрягов. И не только россиянам и не только гражданам стран снг, но и даже китайцам с индусами останется.
Продолжаем «крамольную мысль» по поводу закончившихся ipv4: Да, куда-то 4миллиарда ip делись, наверное все-таки осели в чьих-то руках. В чьих и зачем? Мое чутье подсказывает что «все это неспроста»: закончившиеся ipv4 адреса — это прекрасный «гарант стабильности» для текущего состояния сильно олигополизированного рынка провайдерских услуг. Никакой новый и дерзкий игрок сейчас уже просто никак не сможет вклиниться в этот рынок провайдерских услуг. Просто — уже не сможет! На провайдерском рынке нет место новым игрокам! IPv4-адресов просто нет! Ха! Ах, так вы хотите стать новым провайдером? Какой вы смелый! Наверное у вас ничего не выйдет — вам ведь тогда придется сначала договариватся с кем-то из текущих крупных игроков чтобы выделил вам кусочек ipv4 диапазона из своих «стратегических запасов» (естественно на выгодных условиях). PROFIT :)
Вот и вся «борьба за клиента». А если вдруг их будет не хватать, можно будет чуток (раза в два-три) поднять цену на услугу «внешний статический ip4-адрес» — да сразу мигом отвалятся все «ненужно-несерьезные абоненты» которых не больно и жалко было (то есть те кому это надо для всяких грузящих магистральные каналы торрентов и иже с ними «несерьезных нужд», и кто просто не готово платить лишние 300р в месяц за возможность скачать фильмичек-музычку).
А останутся только те кому это нужно «для серьезного бизнеса» (всякие VPN, доступ к серверам, корпоративным сетям, и прочим вещам без которых не жить). Т.е. те кто кто как платил 150р в месяц и не вякал точно также будет платить 300-500 и тоже особенно не будет возмущатся.
Это я к тому, что если вдруг все-таки и появится достаточно мощный спрос (среди тех клиентов кому не зватает NATа), провайдерам невыгодно будет дергаться в сторну внедрения ipv6, им выгодно будет пользуясь случаем сначала «срубить бабла на пустом месте» т.е. просто подняв чуток цены на услуги «внешние белые ipv4». И все!
А еще при этом никто не будет жаловаться и паниковать! Вся эта «буря в стакане вокруг NAT и IPv4/IPv6» даже если и возникнет, она вообще практически пройдет незамеченной (в широких массах). Пресловутые 95%, которым интернет нужен чтобы зайти во вконтактичек/однокласнички, затем проверить почту, а затем вбив в адресной строке гугля запрос «фишки.нет» остаток для рассматривать прикольные картинки, при этом не будут подозревать что это все у них осуществлялось за счет такой мощной сетевой технологии как NAT.
А на оставшиеся 5% «тех которые advanced» (и которых не устраивает NAT, и тех которые готовы раскошелится), уж поверьте, провайдеры не минут пользуясь случаем, напоследок «навариться».
Увы, PROFIT же.
Я про ситуацию когда возможностей НАТ не будет хватать для нормальной возможности сидеть вконтакте. Когда-нибудь она наступит, может через год, а может через 10, 100 или 1000 лет. И тогда, провайдеры предлагающие IPv6, на вопрос «блондинок»: «А у вас я вконтакте смогу нормально сидеть?» смогут отвечать «Конечно, и даже за те же деньги, что вы платите сейсас, а не +1000 рублей, как ваш нынешний провайдер предлагает».
А кто, по-вашему, должен финансировать смену оконечного пользовательского оборудования (модемы, роутеры)? Я в своё время покупал модем у провайдера, мне новый покупать?
Автор забыл про SIP/H.323/WebRTC и прочие RTP протоколы.
> за NAT-сидит 62000 человек
За одним? Надеюсь, Вы не работаете в провайдере.
За одним? Надеюсь, Вы не работаете в провайдере.
>OpenVPN, Cisco VPN от этой проблемы не страдают, но и пользователю их настроить сложнее (в комплект Microsoft Windows они не входят).
А кого волнует то что нормальные VPN не входят в штатную поставку венды?
А кого волнует то что нормальные VPN не входят в штатную поставку венды?
админчиков винды. их много и они громко кричят.
откройте для себя уже DirectAccess под Windows. Он уже давно нормально работает если блокируют GRE и IPSec и прочее.
blogs.technet.com/b/abeshkov/archive/2009/06/29/direct-access.aspx
blogs.technet.com/b/abeshkov/archive/2009/06/29/direct-access.aspx
>Основное отличие DirectAccess от VPN состоит в том, что безопасное соединение устанавливается в фоновом режиме без участия пользователя.
И все? Встроили VPN в систему — и это уже новая технология? И за NAT не работает.
Спецификаций протокола (даже базовых) я тоже не нашел.
Спасибо, но лучше я буду использовать проверенные и открытые вещи, а не непонятно какую поделку.
И все? Встроили VPN в систему — и это уже новая технология? И за NAT не работает.
Спецификаций протокола (даже базовых) я тоже не нашел.
Спасибо, но лучше я буду использовать проверенные и открытые вещи, а не непонятно какую поделку.
Для тех кто не удосужился почитать перед тем как комментировать разъясняю.
В случае блокировки gre произойдет переключение на ipsec. Если и это не удастся DirectAccess переключается на Https.
Вот сравнение DirectAccess и обычных VPN
technet.microsoft.com/en-us/library/dd875522(WS.10).aspx
Документации по DirectAccess полно. Откройте для себя поисковики.
technet.microsoft.com/ru-ru/library/ee942785.aspx
technet.microsoft.com/ru-ru/library/ff182522.aspx
В случае блокировки gre произойдет переключение на ipsec. Если и это не удастся DirectAccess переключается на Https.
Вот сравнение DirectAccess и обычных VPN
technet.microsoft.com/en-us/library/dd875522(WS.10).aspx
Документации по DirectAccess полно. Откройте для себя поисковики.
technet.microsoft.com/ru-ru/library/ee942785.aspx
technet.microsoft.com/ru-ru/library/ff182522.aspx
99% устройств уже поддерживают IPv6. Это статистика endgadget. Так что ожидается безболезненный переход на новую систему адресов.
Устройства поддерживают, а приложения?
В любом случае приложения обновлять намного проще железа.
будете в нашей версии реальности — передайте привет ie6
В Windows начиная с Vista с ipv6 уже все отлично работает.
>В Windows начиная с Vista с ipv6 уже все отлично работает.
при чем тут виндовс виста?
при чем тут виндовс виста?
При том что люди сидят на клиентских системах и им ipv6 совсем не интересен если он что то сломает.
Поэтому переход на ipv6 имеет две стороны провайдерскую и клиентскую.
При учете того что самый распространенный клиент это Windows логично знать что там уже все готово к ipv6.
Надеюсь донес доходчиво. :)
Поэтому переход на ipv6 имеет две стороны провайдерскую и клиентскую.
При учете того что самый распространенный клиент это Windows логично знать что там уже все готово к ipv6.
Надеюсь донес доходчиво. :)
По моему, самый распространённый клиент это все же модемы и(или) роутеры во всём своём многообразии и именно они прежде всего должны быть готовы работать с новым стандартом.
Не скажите, есть куча не пойми когда и кем писанного ПО, ни авторов ни исходников от которого уже нет.
расскажите об этом тем, кто до сих пор использует IE6 =)
>безболезненный переход на новую систему адресов.
Ha-ha-ha!
посыпется *ВСЕ* — от крупного софта, до наколеночных шелл-скриптов у линуксоадминчиков.
Ha-ha-ha!
посыпется *ВСЕ* — от крупного софта, до наколеночных шелл-скриптов у линуксоадминчиков.
Это слишком оптимистичная оценка.
В действительности, например, выпущена уйма мобильных телефонов с GPRS, новые прошивки к которым никто выпускать не станет. Старые же — IPv4 only.
И это только то, что на поверхности. А ещё есть масса неочевидного железа — веб-камеры, бытовые роутеры и т.д.
В действительности, например, выпущена уйма мобильных телефонов с GPRS, новые прошивки к которым никто выпускать не станет. Старые же — IPv4 only.
И это только то, что на поверхности. А ещё есть масса неочевидного железа — веб-камеры, бытовые роутеры и т.д.
>… устройств уже поддерживают…
Вероятно, надо добавить слово «новых». Новых устройств. Серьезно, очень рад за них, за новые.
А вот как быть людям и компаниям, которые живут, стыдно сказать, на старом? Кто недавно купил IPv4-only роутер домой? Кто в корпоративе строил сети масштабов страны на IPv4-only оборудовании?
Серьезно, как Вам видится: вот люди «от задач своих» строили что-то лет 10, а тут «безболезненный переход в светлое завтра», и они с криками «наконец-то» все выкидывают, и на последние кровные покупают новое железо? А все административные скрипты, вся документация, все-все остальное — с этим что делать? А с софтом?
Ну ладно, софт — он софт и есть, его можно обновлять в смысле версии, а в новой может и есть уже поддержка. Но кто переписывать будет логику работы приложений, которые (и которая) унаследованы?
Простой пример: сущность «IP-адрес» используется в очень большом кол-ве приложений — и эти адреса их часто хранятся в базах уровня MySQL, где IP перед хранением прогоняется через INET_ATON. И вот завтра у нас меняется оборудование, и все-все побежали не только железо новое осваивать, но и (кто бы подумал) срочно переписывать свои скрипты, вспоминать их логику, думать, как переписать/обойти злосчастные места кода…
Я, конечно, понимаю, что Вы мне скажете: надо было им ставить БД покруче, и хранить IP в полях, для того предназначенных, но — не всегда на «что-то круче» есть ресурсы, хотя бы даже память и проц, не говоря уже о времени изучения и т.д.
Так что «безболезненным» я бы этот переход назвал бы только в смысле запуска IPv6 в маленькой, оторванной от интернета, сети. А чуть поглубже копнешь…
Вероятно, надо добавить слово «новых». Новых устройств. Серьезно, очень рад за них, за новые.
А вот как быть людям и компаниям, которые живут, стыдно сказать, на старом? Кто недавно купил IPv4-only роутер домой? Кто в корпоративе строил сети масштабов страны на IPv4-only оборудовании?
Серьезно, как Вам видится: вот люди «от задач своих» строили что-то лет 10, а тут «безболезненный переход в светлое завтра», и они с криками «наконец-то» все выкидывают, и на последние кровные покупают новое железо? А все административные скрипты, вся документация, все-все остальное — с этим что делать? А с софтом?
Ну ладно, софт — он софт и есть, его можно обновлять в смысле версии, а в новой может и есть уже поддержка. Но кто переписывать будет логику работы приложений, которые (и которая) унаследованы?
Простой пример: сущность «IP-адрес» используется в очень большом кол-ве приложений — и эти адреса их часто хранятся в базах уровня MySQL, где IP перед хранением прогоняется через INET_ATON. И вот завтра у нас меняется оборудование, и все-все побежали не только железо новое осваивать, но и (кто бы подумал) срочно переписывать свои скрипты, вспоминать их логику, думать, как переписать/обойти злосчастные места кода…
Я, конечно, понимаю, что Вы мне скажете: надо было им ставить БД покруче, и хранить IP в полях, для того предназначенных, но — не всегда на «что-то круче» есть ресурсы, хотя бы даже память и проц, не говоря уже о времени изучения и т.д.
Так что «безболезненным» я бы этот переход назвал бы только в смысле запуска IPv6 в маленькой, оторванной от интернета, сети. А чуть поглубже копнешь…
пруф?
Мой модем (прошивка от 2004 года) входит в 1%.
В IPv4 максимальная скорость передачи данных по TCP из-за размеров «окна» равна: 64Кбайт / <время отклика>
64Кбайт — это окно в RFC 793, RFC 1323 (1992 год) вводит window scaling, расширяющий размеры окна до гигабайта.
В IPv6 такого жесткого ограничения нет
Вы будете смеяться, но TCP — он один и тот же, и в IPv4 и в IPv6.
А еще есть Bulk Dataflow…
И Jumbo Frames…
… который описывается каким RFC?
Не специалист, просветите?
Я, собственно, хочу понять, о чём вы говорите, потому что словосочетание «Bulk Dataflow» ничего кроме ассоциаций с названием одной из глав «TCP/IP illustrated» у меня не вызывает. Т.е. вы ссылаетесь на какой-то документированный механизм, или просто словосочетание красивое?
А что разве он должен быть четко документирован, чтобы его можно было использовать? Повторюсь, я не специалист, но я сильно удивлюсь, если реализации такого механизма (или ему подобного) нету в имплементации TCP в современных ОС.
Протоколы, которые не имеют понятие порта (например GRE), идентифицируются в NAT только по <IP-адресу сервера>, из-за этого за NAT по этим протоколам может к серверу подключиться только один клиент.
В случае поддержки трекинга соединений не правда. Трекать pptp который шурует по GRE linux умеет уже давненько.
У вас не указано одной еще вещи. Переход в чистый IPv6 приводит к информационному голоду. Очень малое количество сайтов сейчас доступно по IPv4. И тут нас спасает опять же нат NAT64 который позволяет транслировать IPv4 интернет в один из сегментов IPv6.
>И тут нас спасает опять же нат NAT64
И где он есть кроме линукса?
И где он есть кроме линукса?
Да много где есть. На эту штуку уже есть RFC.
Уже — это Апрель этого года. Ни одной железки не знаю, которая его бы поддерживала. Программную реализация только одна. Идет под линуксом и OpenBSD.
>yandex.ru откроется у всех, так как имя yandex.ru ссылается на 6 IP-адресов;
>vk.ru откроется только у части пользователей, так как имя vk.ru ссылается на 1 IP-адрес (портов не хватило).
эээээ… при нате могут висеть два соединения с одинаковыми ip и портами на стороне клиента (клиент в данном случае сервер с натом)?
>vk.ru
кто такой, чем знаменит?
>vk.ru откроется только у части пользователей, так как имя vk.ru ссылается на 1 IP-адрес (портов не хватило).
эээээ… при нате могут висеть два соединения с одинаковыми ip и портами на стороне клиента (клиент в данном случае сервер с натом)?
>vk.ru
кто такой, чем знаменит?
Эпоха IPv6 определённо наступит, но не мгновенно. С точки зрения абонентских устройств и серверов, особых проблем нет, хотя и тут не всё так просто, особенно в части производителей CPE. А вот у операторов головной боли заметно прибавится. Взять и резко перейти на шестёрку, забыв про остальной интернет не получится, т.к. далеко не все ресурсы торопятся открывать доступ по IPv6. Так что всякие Carrier-grade NAT и различные игрища типа 6to4 неизбежны, а это дополнительные, и весьма нехилые затраты для операторов. Было бы клёво, если бы в один прекрасный день все операторы нажали на большую красную кнопку Ipv4 disable/IPv6 enable, но это фантастика.
vk.com
Addresses: 93.186.224.244
93.186.224.247
87.240.131.101
87.240.131.102
87.240.131.103
87.240.131.104
87.240.188.248
87.240.188.253
Addresses: 93.186.224.244
93.186.224.247
87.240.131.101
87.240.131.102
87.240.131.103
87.240.131.104
87.240.188.248
87.240.188.253
«В IPv4 максимальная скорость передачи данных по TCP из-за размеров «окна» равна: 64Кбайт /
То есть, если время отклика равно 150 мс, то данные по одному TCP-потоку можно прокачивать со скоростью не более 426 Кбайт/сек.»
А где можно подробней почитать про это? Почему такая зависимость скорости от пинга.
То есть, если время отклика равно 150 мс, то данные по одному TCP-потоку можно прокачивать со скоростью не более 426 Кбайт/сек.»
А где можно подробней почитать про это? Почему такая зависимость скорости от пинга.
TCP требует подтверждения доставки, в отличие от UDP.
150мс туда, 150мс обратно, итого 300мс на пакет.
150мс туда, 150мс обратно, итого 300мс на пакет.
TCP/IP illustrated например
«Протоколы, которые не имеют понятие порта (например GRE), идентифицируются в NAT только по <IP-адресу сервера>, из-за этого за NAT по этим протоколам может к серверу подключиться только один клиент.»
Эта проблема преувеличена.
NAT хранит соответствие трёх адресов:
— локальный адрес абонента;
— внешний адрес NAT, с которого выходит данный абонент;
— адрес VPN сервера, куда присоединяется абонент,
и проблема возникнет только в том случае, если все эти три адреса одновременно совпадут.
Фактически, она возникнет только в одном случае — если количество желающих присоединиться к одному и тому же VPN серверу превысит объём пула IPv4 адресов, выделенных провайдером для NAT.
Эта проблема преувеличена.
NAT хранит соответствие трёх адресов:
— локальный адрес абонента;
— внешний адрес NAT, с которого выходит данный абонент;
— адрес VPN сервера, куда присоединяется абонент,
и проблема возникнет только в том случае, если все эти три адреса одновременно совпадут.
Фактически, она возникнет только в одном случае — если количество желающих присоединиться к одному и тому же VPN серверу превысит объём пула IPv4 адресов, выделенных провайдером для NAT.
для TCP и UDP оно равно 65535 — 4096 = 61439
Если не секрет, откуда число 4096?
Привилегированные порты?
Вот я и пытаюсь понять где их 4к нашли. Берем самую первую ссылку из гугла — www.w3.org/Daemon/User/Installation/PrivilegedPorts.html и видим 1024 штуки. И в MSDN про Windows написано про 1024 штуки. Вот и справшиваю — может man какой-то волшебный есть где 4к? А то как бы плохо если что-то про TCP не знаю -_-"
62000 НАТ-юзеров за одним айпишником порадовала.
Количество оборудования, готовое поддерживать IPv6 «из коробки» сильно преувеличено.
Даже на провайдерском уровне хватает железа, которое понимает L2 только IPv4. И не во всем железе можно исправить это прошивками (а даже если и можно, это очень сильно загрузить процессор). Просто потому, что SOIC-чипы коммутаторов рассчитаны на 32-битный IPv4 и работать со 128-битным IPv6 они не смогут физически. А если смогут за счет прошивки, то коммутация будет реализована софтовым методом, что является костылем и далеко не самым лучшим и производительным.
Я уж не говорю целой куче «домашних» роутеров и тупых свичей которые о IPv6 ни сном ни духом.
Насчет производительности в маршрутизации и больших таблиц — учитывая то, что IPv6 128-битный, то есть в 4 раза больше IPv4, таблицы маршрутизации будут в любом случае больше, что тянет за собой увеличенный расход памяти и процессорного времени. Трансляция и NAT, конечно, увеличит нагрузку, но на сколько?
Опять же поддержка со стороны клиентского оборудования и ПО — тот же Windows 7, который изначально вроде как поддерживает IPv6, с ним очень странно работает. Поддержка XP тоже под большим вопросом.
Мультикаст без IGMP толком работать не будет где угодно — в сети и так хватает трафика, если его еще и не особо контролируемым мультикастом забивать, то с загрузкой каналов будет вообще все печально. Вопрос поддержки мультикаста и IGMP на самом деле не такой уж тривиальный. Опять же стандартизации IPTV-вещания как такового нету, в результате каждый производитель лепит реализацию в меру своего понимания.
Насчет VPN — из-за NAT к VPN-серверу все замечательно коннектиться и вполне себе даже работает. В обратную сторону при настройке форвардинга портов на марщрутизаторе тоже вполне себе функционирует.
При этом не стоит забывать, что для обычного пользователя NAT является одним из порогов безопасности — злоумышленнику сложнее попасть на конечный компьютер клиента, тогда как при наличии прямого «белого» IP все связанные с ним угрозы — вирусные и DoS атаки и т.п. — представляются во всей своей прелести.
Проблема одновременного доступа к сетевым ресурсам все-таки несколько надумана. Учитывая то, что в любых достаточно крупных проектах происходит балансировка нагрузки между несколькими серверами и сразу и одновременный (точнее даже — одномоментный) доступ десятков тысяч пользователей это либо DoS либо плохо спроектированная система. Переход на IPv6 проблему DoS-а не снимает ни разу.
Теперь насчет скорости. Какое отношение TCP имеет к IP? IP это способ адресации устройства. И TCP не особо принципиально какой там именно пакет будет бегать внутри — IPv4 или v6. Стек TCP один и тот же. С UDP и RTP сравнивать некорректно. Для увеличения пропускной способности по Ethernet есть технология Jumbo Frame, которая позволяет передавать увеличенные пакеты данных, за счет чего ускоряется передача. И TCP с гарантированной доставкой пакетов не надо путать с UDP и RTP (негарантированная доставка).
И насчет ревизии ранее выданных адресов — все-таки ресурс тут есть и не совсем маленький.
Я, конечно, понимаю стремление производителей побыстрее впарить новые железки (а полноценный переход на IPv6 без перехода на новое железо просто невозможен) и нагнетаемую по этому поводу панику (новое железо мало того, что стоит денег, так еще и дороже за счет увеличившейся сложности). Но не совсем понимаю стремление присвоить каждой кофеварке IP-адрес. Для чего? Чтобы можно было поднять на ней Torrent-клиент? Или чтобы можно было легко заДоСить даже кофеварку?
Даже на провайдерском уровне хватает железа, которое понимает L2 только IPv4. И не во всем железе можно исправить это прошивками (а даже если и можно, это очень сильно загрузить процессор). Просто потому, что SOIC-чипы коммутаторов рассчитаны на 32-битный IPv4 и работать со 128-битным IPv6 они не смогут физически. А если смогут за счет прошивки, то коммутация будет реализована софтовым методом, что является костылем и далеко не самым лучшим и производительным.
Я уж не говорю целой куче «домашних» роутеров и тупых свичей которые о IPv6 ни сном ни духом.
Насчет производительности в маршрутизации и больших таблиц — учитывая то, что IPv6 128-битный, то есть в 4 раза больше IPv4, таблицы маршрутизации будут в любом случае больше, что тянет за собой увеличенный расход памяти и процессорного времени. Трансляция и NAT, конечно, увеличит нагрузку, но на сколько?
Опять же поддержка со стороны клиентского оборудования и ПО — тот же Windows 7, который изначально вроде как поддерживает IPv6, с ним очень странно работает. Поддержка XP тоже под большим вопросом.
Мультикаст без IGMP толком работать не будет где угодно — в сети и так хватает трафика, если его еще и не особо контролируемым мультикастом забивать, то с загрузкой каналов будет вообще все печально. Вопрос поддержки мультикаста и IGMP на самом деле не такой уж тривиальный. Опять же стандартизации IPTV-вещания как такового нету, в результате каждый производитель лепит реализацию в меру своего понимания.
Насчет VPN — из-за NAT к VPN-серверу все замечательно коннектиться и вполне себе даже работает. В обратную сторону при настройке форвардинга портов на марщрутизаторе тоже вполне себе функционирует.
При этом не стоит забывать, что для обычного пользователя NAT является одним из порогов безопасности — злоумышленнику сложнее попасть на конечный компьютер клиента, тогда как при наличии прямого «белого» IP все связанные с ним угрозы — вирусные и DoS атаки и т.п. — представляются во всей своей прелести.
Проблема одновременного доступа к сетевым ресурсам все-таки несколько надумана. Учитывая то, что в любых достаточно крупных проектах происходит балансировка нагрузки между несколькими серверами и сразу и одновременный (точнее даже — одномоментный) доступ десятков тысяч пользователей это либо DoS либо плохо спроектированная система. Переход на IPv6 проблему DoS-а не снимает ни разу.
Теперь насчет скорости. Какое отношение TCP имеет к IP? IP это способ адресации устройства. И TCP не особо принципиально какой там именно пакет будет бегать внутри — IPv4 или v6. Стек TCP один и тот же. С UDP и RTP сравнивать некорректно. Для увеличения пропускной способности по Ethernet есть технология Jumbo Frame, которая позволяет передавать увеличенные пакеты данных, за счет чего ускоряется передача. И TCP с гарантированной доставкой пакетов не надо путать с UDP и RTP (негарантированная доставка).
И насчет ревизии ранее выданных адресов — все-таки ресурс тут есть и не совсем маленький.
Я, конечно, понимаю стремление производителей побыстрее впарить новые железки (а полноценный переход на IPv6 без перехода на новое железо просто невозможен) и нагнетаемую по этому поводу панику (новое железо мало того, что стоит денег, так еще и дороже за счет увеличившейся сложности). Но не совсем понимаю стремление присвоить каждой кофеварке IP-адрес. Для чего? Чтобы можно было поднять на ней Torrent-клиент? Или чтобы можно было легко заДоСить даже кофеварку?
Что вы подразумеваете под «L2 только IPv4»?
Может имеют в виду второй уровень модели OSI. Хотя непонятно, если IP на третьей начинается.
Упс. Да, конечно L3 — промахнулся малеха. L2 — это Ethernet и там IP, естественно, не фигурирует.
Но, кстати, в управляемых свичах используются технологии так или иначе завязанные на IP — та же RADIUS аутентификация, WEB-управление, 802.1x завязанный на тот же RADUIS. То есть фичи где так или иначе IP-адрес присутствует.
Конечно, именно это скорее всего можно «вылечить» обновленной прошивкой. Поэтому все проблемы начинаются на уровне 3, начиная с маршрутизации.
Заработался. Таки L2 отношение к IP не имеет — там канальный уровень и, собственно, и тупой свич должен обрабатывать IPv6 ничуть не хуже IPv4, ибо о них он вообще-то не знает, а оперирует MAC-ами и Ethernet-фреймами.
Тем не менее производители под шумок начинают нагнетать панику и продвигать новые железки (естественно дороже). Тот же D-Link серию 31хх весьма оперативно свернул и теперь делает поставки только серии 32хх версии, на которой гордо красуется «IPv6 Support» и стоит уже заметно дороже своих предшественников. Обновление же старого железа уже не планируется. Так что назначить IPv6-адрес на управляющий интерфейс на старом оборудовании не получиться.
Но, кстати, в управляемых свичах используются технологии так или иначе завязанные на IP — та же RADIUS аутентификация, WEB-управление, 802.1x завязанный на тот же RADUIS. То есть фичи где так или иначе IP-адрес присутствует.
Конечно, именно это скорее всего можно «вылечить» обновленной прошивкой. Поэтому все проблемы начинаются на уровне 3, начиная с маршрутизации.
Заработался. Таки L2 отношение к IP не имеет — там канальный уровень и, собственно, и тупой свич должен обрабатывать IPv6 ничуть не хуже IPv4, ибо о них он вообще-то не знает, а оперирует MAC-ами и Ethernet-фреймами.
Тем не менее производители под шумок начинают нагнетать панику и продвигать новые железки (естественно дороже). Тот же D-Link серию 31хх весьма оперативно свернул и теперь делает поставки только серии 32хх версии, на которой гордо красуется «IPv6 Support» и стоит уже заметно дороже своих предшественников. Обновление же старого железа уже не планируется. Так что назначить IPv6-адрес на управляющий интерфейс на старом оборудовании не получиться.
>тот же Windows 7, который изначально вроде как поддерживает IPv6, с ним очень странно работает.
Есть что-то конкретное?
Есть что-то конкретное?
Помню была проблема в одновременной работе IPv4 и IPv6.
В Win7 IPv6 по-умолчанию включен. Если в сети есть доступ к IPv6, то он будет предпочитаемым и IPv4 использовать не будет. Для того, чтобы в таком случае попасть по адресу IPv4 где-то в промежутке должна быть настроена трансляция/NAT/маршрутизация IPv6 в IPv4 и наоборот.
Возможно этот баг пофиксили (возможно это и не баг, а фича), но в первоначальном выпуске Win7 такое вроде как наблюдалось.
Ну а про общую адаптацию остального ПО для работы с IPv6 уже написано и не мало.
P.S. Кроме того, для меня с чисто юзерской точки зрения адресация IPv6 с ее кучей октетов в шестнадцатеричной системе (еще и с возможностью пропускать 0000 в октетах и сокращать их группы просто до "::") просто абзац.
«http://[2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d]:8080/»
против
«htpp://192.168.0.1:8080/»
это ж просто ад.
В Win7 IPv6 по-умолчанию включен. Если в сети есть доступ к IPv6, то он будет предпочитаемым и IPv4 использовать не будет. Для того, чтобы в таком случае попасть по адресу IPv4 где-то в промежутке должна быть настроена трансляция/NAT/маршрутизация IPv6 в IPv4 и наоборот.
Возможно этот баг пофиксили (возможно это и не баг, а фича), но в первоначальном выпуске Win7 такое вроде как наблюдалось.
Ну а про общую адаптацию остального ПО для работы с IPv6 уже написано и не мало.
P.S. Кроме того, для меня с чисто юзерской точки зрения адресация IPv6 с ее кучей октетов в шестнадцатеричной системе (еще и с возможностью пропускать 0000 в октетах и сокращать их группы просто до "::") просто абзац.
«http://[2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d]:8080/»
против
«htpp://192.168.0.1:8080/»
это ж просто ад.
Сложность адресации преувеличена. Для пользователей есть DNS. Зачем им запоминать адреса?
Для админов надо запомнить префикс организации (/32), адрес сети и адрес компьютера, который как правило простой при отсутствии SLAAC. То есть более реальный адрес: 2a00:14d0:0:3::25. Что запомнить не на много сложнее IPv4 адреса.
Для админов надо запомнить префикс организации (/32), адрес сети и адрес компьютера, который как правило простой при отсутствии SLAAC. То есть более реальный адрес: 2a00:14d0:0:3::25. Что запомнить не на много сложнее IPv4 адреса.
Не уверен, что такая проблема была в Win7, но сейчас такой проблемы нет.
Кажется, что пытаются заработать деньги на шумихе, как было с Y2K.
В Microsoft Windows штатная реализация VPN использует протокол GRE
В Microsoft Windows сейчас 5 (пять) штатных реализаций VPN. GRE из них использует только PPTP, и использование его уже много лет «нерекомендуемо».
Протоколы, которые не имеют понятие порта (например GRE), идентифицируются в NAT только по <IP-адресу сервера>, из-за этого за NAT по этим протоколам может к серверу подключиться только один клиент
У ICMP тоже нет понятия порта — как он ходит через NAT?
Вот и GRE может так же — необходимо вычленить идентификатор сессии из данных протокола. И это давно и много кто умеет. От RRAS до ASA.
В IPv4 максимальная скорость передачи данных по TCP из-за размеров «окна» равна: 64Кбайт / <время отклика>
Откройте для себя RFC 1323 и CTCP.
У NAT есть офигенное преимущество, о котором почему-то не упомянуто — он на 100% защищает от внешних атак через IP-протокол, то есть злые хакеры, даже если у вас непатченный Windows 95, не смогут вас атаковать никаким эксплойтом. Я сижу за НАТом без антивируса и файерволла и хоть бы хны. Единственный способ нанести мне какой-то ущерб — заДДОСить магистральные каналы не самого маленького питерского провайдера. Ну-ну, удачи.
Если всем раздать Ipv6 и открыть соединения снаружи, это обернется волной заражений, так как 95% пользователей одна известная корпорация подсунула свою крайне глючную и дырявую ОСь. Также, зная IP-адрес гражданина, можно злонамеренно завалить канал к нему флудом и нарушить работу сети, например, с целью мошенничества. Ил ис целью DNS-спуфинга. Или еще с какой-нибудь нехорошей целью.
Также, сложно юудет владельцам серверов — если раньше ботов и ДДОСеров можно было банить по IP, то теперь, когда адреса станут дешевыми, и любой злодей сможет их покпать тысячами, непонятно как их банить и отличать от добронамеренных юзеров.
В общем, как видим, больше всего преимуществ получат разные черные шляпы.
Если всем раздать Ipv6 и открыть соединения снаружи, это обернется волной заражений, так как 95% пользователей одна известная корпорация подсунула свою крайне глючную и дырявую ОСь. Также, зная IP-адрес гражданина, можно злонамеренно завалить канал к нему флудом и нарушить работу сети, например, с целью мошенничества. Ил ис целью DNS-спуфинга. Или еще с какой-нибудь нехорошей целью.
Также, сложно юудет владельцам серверов — если раньше ботов и ДДОСеров можно было банить по IP, то теперь, когда адреса станут дешевыми, и любой злодей сможет их покпать тысячами, непонятно как их банить и отличать от добронамеренных юзеров.
В общем, как видим, больше всего преимуществ получат разные черные шляпы.
Посмешили. NAT не является мерой повышения безопасности. Он не защищает от атак на службы и приложения вашей Windows 95. Если она обменивается данными с внешним миром значит ее можно атакковать. Атаковать ваш домашний D-Link на сетевом уровне никому не интересно.
Да это же знатный тролль, у него работа такая — смешить грамотных людей.
Всё же является. Атаки возможны только по соединениям, которые винда сама инициировала. В худшем случае, если взломают или заразят провайдерскую инфраструктуру. Неужели вы считаете, что провайдерский НАТ защищён от атак слабее чем вин95?
А разве домашняя машина у вас будет без исходящих соединений? Смысл в такой машине? Проще всего будет прислать эксплоит Flash в Excel или PDF.
Обычно в плюсах на NAT перечисляют что он скрывает внутреннюю топологию сети. Но она в общем для атакующего имеет малый приоритет.
Вот статья про то почему NAT это не серьезное решение безопасности
book.soundonair.ru/cisco/ch06lev1sec2.html
Обычно в плюсах на NAT перечисляют что он скрывает внутреннюю топологию сети. Но она в общем для атакующего имеет малый приоритет.
Вот статья про то почему NAT это не серьезное решение безопасности
book.soundonair.ru/cisco/ch06lev1sec2.html
Ну, оно не то чтобы совсем офигенное преимущество, но как одно из звеньев в цепочке безопасности имеет право на жизнь.
Не серьезное, но всё же решение. Когда у нас в сетке быр разрешён внутрисетевой трафик, то постоянно наблюдал сканирование портов, попытки подключения по SMB и т. п… Не стоял бы у меня детектор и блокировщик, не исключено что некоторые атаки увенчались бы успехом.
Сделали бы лучше сразу адресацию переменной длины, байтовыми строками.
128-бит тоже когда-то кончатся, особенно если каждой лампочке давать по IP-шнику.
128-бит тоже когда-то кончатся, особенно если каждой лампочке давать по IP-шнику.
Не написали ещё, что NAT на больших сетях достаточно дорого. Не дороже конечно чем внедрение IPv6, но достаточно дорого, чтобы провайдеры, имея возможность, начали всем выдавать динамически белые адреса.
Купил книгу
Д. Мэлоун. IPv6. Администрирование сетей
www.books.ru/books/ipv6-administrirovanie-setey-454087/
сижу читаю и осваиваю на практике… хабра-жителям рекомендую книгу.
всё расписано доходчиво… плюсы/минусы IPv4 и как проектировали IPv6.
почему выбрали 128 бит и почему рекомендует IETF использовать /64 и не является ли это разбазариванием адресов.
Д. Мэлоун. IPv6. Администрирование сетей
www.books.ru/books/ipv6-administrirovanie-setey-454087/
сижу читаю и осваиваю на практике… хабра-жителям рекомендую книгу.
всё расписано доходчиво… плюсы/минусы IPv4 и как проектировали IPv6.
почему выбрали 128 бит и почему рекомендует IETF использовать /64 и не является ли это разбазариванием адресов.
Sign up to leave a comment.
Мысли вслух про IPv6, или почему нас не спасет NAT