4. Thomson TCW770 EuroDOCSIS3.0 Wifi роутер
Раз в 15 минут как практически по часам роутер Thomson отключает от интернета все подключенные к нему устройства (Macbook, iPad и iPhone). Это продолжается уже пару недель.
В настройках роутера в момент такого отключения в разделе Connected Clients показывает для всех устройств IP Adress и Host Name — ERROR, в разделе DHCP Clients вообще ни одного устройства не показывает. Сам роутер при этом подключения к сети не теряет.
Устройства, судя по их настройкам, также подключения к роутеру не теряют. При этом если на устройстве отключить и включить обратно wifi, то интернет мгновенно начинает работать.
Все настройки выставил, как рекомендуют на форуме. Все без изменений. Роутер перегружал, настройки на дефолтные откатывал, с бубном плясал.
Что делать теперь ума не приложу. Вроде как интернет есть, но например в скайпе связь каждые 15 минут обрывается. Это бесит.
#4642 snike
Отправлено 13 июня 2015 — 14:34
Посмотрите пожалуйста, что случилось с каналом или с роутером ?
уезжал на 1,5 месяца — до отъезда все ок, сейчас субъективно — тормоза при открытии сайтов, packet lost во всех онлайн играх.
Перегружал — не помогло.
Может перепрошить нужно или с линией чего сотворили за это время.
Договор 90098044
Сообщение отредактировал snike: 13 июня 2015 — 14:36
#4643 Merdue
Отправлено 14 июня 2015 — 14:28
RG IPv4 Mode и ERG IPv4 Mode в чем разница ?
Объясните пожл. по человечьему скоко вешать в граммах — что настроить RG IPv4 Mode или ERG IPv4 Mode и как дальше настроить, в RG с интернетом все фигово скорость загрузки сайтов дергается !? Поставил ERG, но в чем разница ? Все работает тип топ ! Попроще без длинных объяснений и инкапсуляций всяких ! Нигде не нашел нормального объянения rg- erg только в описаниях к TCW770 упоминается моды ERG и RG без раскладки скоко вешать в граммах?
Кстати WiFI на TCW770 у меня отключен и без 2 ната через порт ЛАН подключен к роутеру D-Link DIR825/AC wifi N/AC 5 GHz — LAN с выключеным DHCP все летает и WIFI на 5ГГц на МАКАХ их у меня 2 ноута 2 планшета и три телефона — у семьи после переключения с TCW770 у которого кончилась гарантия купил D-Link DIR825/AC (2300РУБ.) и теперь инет работает и по проводам и по Вафле в норме, а вот ВАФЛЯ на TCW779 самое настоящее ГАМНО! (с нагрузкой потоками по сети Д130 мбит А13мбит грелся в зоне коммутатора +80 С корпус пластик +70С разъем кабеля коакс. +75-85С ) часто 3-8 раз приходилось перезагружать — сейчас лепота и никаких вторых натов ! порт ЛАН-ЛАН роутеры соединяюся все шуршит как нада на тестах все по максу ! Так что тем у кого МАК ————- WiFi роутера TCW770 с железом и прогами (поддержка ВАФЛИ в МАК и APPLE железе (Iphone iPAd и тд) не работает периодически разрывает соединение во всех 5ГГц режимах Вафли и только рестарт роутера Вафлю поднимает при этом проводной ЛАН работает и вафля 2.4ГГц тоже работает но там все забито и скорость низкая у меня инет 150мбит тариф!! В APPLE на 5ГГц каналы должны распределяться при помощи 802.11d но он хотя и включается на ВАФЛЕ TCW770, но нет настройки страны пребывания и других настроек Вафли на 5ГГЦ те на TCW770 вафля 5ГГц гнилая -нет стандарта и греется очень сильно, а на 2.4 разхогрев мешает и забитость скорость все время прыгает но по низам! Те Вафля в TCW770 никакая ее сразу надо выключить в настройках роутера и подключить свой роутер например ASUS илм D-Link с N/AC и с двумя диапазонами !
Спасибо !
#4644 Streamer
Отправлено 15 июня 2015 — 11:13
Merdue (14 июня 2015 — 14:28) писал:
RG IPv4 Mode и ERG IPv4 Mode в чем разница ?
оставить RG4 как и установлено по-умолчанию. для пользователя разницы никакой
ИванЧернов (12 июня 2015 — 19:24) писал:
Все настройки выставил, как рекомендуют на форуме. Все без изменений. Роутер перегружал, настройки на дефолтные откатывал, с бубном плясал.
скриншоты настроек в студию
ИванЧернов (12 июня 2015 — 19:24) писал:
Устройства, судя по их настройкам, также подключения к роутеру не теряют. При этом если на устройстве отключить и включить обратно wifi, то интернет мгновенно начинает работать.
snike (13 июня 2015 — 14:34) писал:
Посмотрите пожалуйста, что случилось с каналом или с роутером ?
уезжал на 1,5 месяца — до отъезда все ок, сейчас субъективно — тормоза при открытии сайтов, packet lost во всех онлайн играх.
Перегружал — не помогло.
Может перепрошить нужно или с линией чего сотворили за это время.
Договор 90098044
RG-EG210G-E
Маршрутизатор серии Ruijie Reyee RG-EG105G — это маршрутизатор с облачным управлением, предназначенный для вилл, ресторанов, небольших офисов, хостелов. он доступен по цене, мал и прост в использовании, но в то же время имеет пропускную способность 500 Мбит/с и поддерживает до 100 терминалов.
- Автоинициализация через самоорганизующуюся сеть: серия RG-EG105G реализует ведущие в отрасли функции автоматического обнаружения и автоматического подключения к сети для шлюзов, коммутаторов и беспроводных сетей.
- Бесплатное управление Ruijie Cloud в течение всего срока службы: дистанционное оповещение о сбоях, управление одним щелчком мыши и обслуживание в приложении Ruijie Cloud.
- Несколько портов WAN: поддерживается до 4 портов WAN.
- Полноценный гигабитный порт. Удовлетворяет потребности в 200M xDS/оптическом доступе, высокоскоростном проводном соединении.
- Интеллектуальное управление потоком
- IPSec VPN: до 8 филиалов.
- Функции корпоративной безопасности: IP/MAC/MAC-Fitering. Независимый VLAN для гостей, изолированный от внутренней офисной сети.
Характеристики
IP-маршрутизация:
Статическая маршрутизация, маршрутизация на основе политик, маршрутизация по адресу оператора, активный/резервный режим, балансировка нагрузки на основе исходного адреса, балансировка нагрузки на основе потоков, взвешенная балансировка нагрузки потоков да
Доступ к сети:
Коммутируемое соединение PPPoE, DHCP-клиент, статический IP-адрес, автоматическая идентификация методов доступа, автоматическое предотвращение конфликтов адресов портов WAN, клонирование MAC-адресов, получение паролей учетных записей с существующих маршру
Местное электроснабжение:
Поддержка местного источника питания 220 В переменного тока
Рекомендуемые решения:
Асимметричная пропускная способность 1 Гбит/с (управление потоком отключено) Асимметричная пропускная способность 1 Гбит/с (включено управление потоком)
Фиксированные порты:
10 портов 10/100/1000M Base-T, поддержка до 4 портов WAN (По умолчанию: 1 порт WAN и 9 портов LAN LAN8, LAN7 и LAN6 можно переключить на порты WAN）
10/100/1000 Ethernet:
Беспроводное управление
Поддержка локального роуминга с переадресацией, роуминга уровня 2, роуминга уровня 3 между точками доступа, просмотра дорожки роуминга STA
Управление точкой доступа:
Поддержка конфигурации с несколькими SSID, скрытие SSID, настройка канала, настройка питания, настройка проводного порта AP, онлайн-обновление AP, настройка количества STA, черный и белый список STA
Управленческий потенциал:
В режиме переменного тока максимальная емкость управления составляет 500 В режиме шлюза максимальная емкость управления составляет 150
Управление коммутатором
Отображение состояния:
Статистика портов, информация мониторинга, обнаружение кабелей, конфигурация VLAN, список MAC-адресов
Управление:
Eweb и Ruijie Cloud
Управление обновлением:
Обновление для каждого устройства, пакетное обновление
Управление портом:
Защита от петель, зеркалирование портов, изоляция портов, конфигурация портов, конфигурация PoE, ограничение портов, контроль штормов, статический MAC-адрес, поиск MAC-адресов
Управленческий потенциал:
Максимальное количество управляемых облачных коммутаторов: 128
Шлюз
IPsec VPN (8 туннелей) сервер и клиент, L2TP, PPTP
Аудит трафика:
Аудит трафика в режиме реального времени, визуализация IP-трафика
Аутентификация:
Маркетинговая аутентификация: WiFiDog (SMS-аутентификация и аутентификация в один клик) Локальная аутентификация: аутентификация по паролю, аутентификация по QR-коду, аутентификация по ваучеру
Распознавание приложений:
Встроенная база данных сигнатур приложений собственной разработки для идентификации приложений. Поддержка бесплатных обновлений
Управление поведением:
Управление доступом на основе времени и IP-политики, фильтрация веб-сайтов
Общие
Безопасность:
ACL, привязка IP-MAC, фильтрация MAC-адресов, динамический ARP, статическая привязка ARP, NAT, NAPT, сопоставление портов
В интернете стремительно заканчиваются IP-адреса
В 1981 году основатель Microsoft Билл Гейтс заявил, что 640 килобайт оперативной памяти — это вполне достаточно для персонального компьютера. Примерно тогда же примерно так же считали люди, разрабатывающие интернет-протокол IPv4, который позволял «раздать» чуть больше 4 миллиардов IP-адресов устройствам, подключенным к Сети. История показала, что все заблуждались.
Дефицитные адреса
В настоящее время IP-адреса стремительно заканчиваются. В Европе свободные адреса, когда-то выданные интернет-провайдерам, закончатся уже в этом году — все расхватают новые подключенные пользователи. В США дефицит IP-адресов тоже ощущается, но тотальная нехватка произойдет в следующем году. При этом массового внедрения нового протокола IPv6, который позволит кардинально решить проблему нехватки адресов (которых будет на несколько десятков порядков больше), до сих пор не произошло.
6 июня в Санкт-Петербурге собрались специалисты по интернет-технологиям, которые попытались разобраться, почему так происходит. На конференции под названием «Российский день IPv6», посвященной всемирному запуску поддержки протокола крупными интернет-операторами (включая Akamai, Google, Bing, Yahoo, Facebook и другие), прозвучало много умных слов и технических терминов, но если вникнуть в самую суть, то все выглядит примерно так.
Сейчас подавляющая часть абонентского оборудования — модемы, роутеры и так далее — не поддерживает новый протокол, а провайдерам и операторам связи, у которых в загашнике есть свободные IP-адреса, незачем, по их мнению, волноваться и дергаться: все работает, а абоненты приносят необходимые средства. Как заявил технический директор петербургского провайдера «ПиН Телеком» Кирилл Малеванов, резервных адресов в старом протоколе IPv4 хватит еще на пять лет, а оборудование надо менять как на стороне оператора, так и дома у абонентов, а это — деньги, недополученная прибыль, дополнительные расходы.
То есть бизнес не видит прибыли от IPv6 — в ближайшее время она вряд ли станет осязаемой, а многие компании живут сегодняшним днем. «Провайдеры ставят абонентам старое оборудование, интернет-площадки не спешат с внедрением, ссылаясь на провайдеров, а разработчики приложений ссылаются на малое количество пользователей. Получается замкнутый круг», — прокомментировал ситуацию с IPv6 директор Координационного центра доменов .RU/.РФ Андрей Колесников.
Во-вторых, играет роль инертность. Многие компании не хотят включать поддержку IPv6, пока этого не сделают другие — просто чтобы посмотреть на результат, учесть ошибки конкурентов. В результате все сидят и ждут друг друга.
«Все» — это, конечно, небольшой перегиб, однако статистика неумолима: в России всего 0,2 процента пользователей заходят на сайты по новому протоколу, а в мире — 0,6 процента. В России, как подчеркнул Андрей Колесников, IPv6 поддерживают всего несколько крупных операторов и интернет-площадок, в том числе «Яндекс». А весь мир меж тем «утилизирует заначки», и количество свободных адресов уменьшается катастрофически быстро.
Безвыходных ситуаций не бывает
Конечно, выход есть всегда — на один IP-адрес можно «повесить» сразу несколько (или даже несколько сотен или тысяч) пользователей. То есть какой-то небольшой провайдер может обладать одним-единственным интернет-адресом, за которым скрываются его абоненты. И это — одна из серьезных проблем.
Предположим, один из пользователей такого провайдера случайно скачал на свой компьютер какой-нибудь вирус, который присоединил ПК к ботнету, сделав зараженную машину участником DDoS-атаки. Или сам пользователь оказался нечистоплотным, принявшись распространять в Сети что-нибудь нелицензионное. Как быть, к примеру, администрации сайта, на который ведется атака? Она просто блокирует этот IP-адрес. В результате все абоненты этого провайдера из-за одной «паршивой овцы» не могут зайти на сайт, который теряет посетителей.
Протокол IPv6, где экономить адреса не нужно, эту проблему успешно решает — IP-адрес можно выдать каждому человеку, хватит на всех, рассказывает Андрей Робачевский, директор по программам организации ISOC, которая занимается внедрением протокола. И отследить злоумышленника будет гораздо проще — ведь он не «растворяется» среди прочих пользователей, а наоборот, отыскивается очень легко.
Божьи мельницы
В пословице говорится, что божьи мельницы мелют медленно, но мелко. С одной стороны, как утверждает Андрей Колесников, на внедрение IPv6 может уйти ни много ни мало двадцать лет. Александр Туркот, исполнительный директор кластера информационных технологий «Сколково», считает, что понадобится существенно меньше времени — по его мнению, уже лет через 7-8 каждый пользователь интернета будет иметь собственный IP-адрес для «айфона», компьютера, планшета, холодильника и утюга.
Поддержка с воздуха
Поддерживать перспективные проекты и стартапы, которые помогут скорее внедрить в России новый протокол, будет фонд «Сколково», заявил Александр Туркот. Это может быть и материальная поддержка, и включение проекта в список резидентов, и налоговые льготы.
В свою очередь, Андрей Колесников подчеркнул, что правительство должно принять меры — в частности, внести изменения в закон о закупках, указав, что новое сервисное оборудование должно поддерживать IPv6.
Незаметно для всех
Сами пользователи не должны ощутить каких-то изменений после перехода с IPv4 на IPv6, заявил Андрей Робачевский. Конечно, многим из них придется расстаться с милыми сердцу запылившимися ADSL-модемами и роутерами, а у кого-то уже есть оборудование, которому требуется лишь небольшая настройка. Один американский провайдер, кстати, изобрел хитрый способ обмена старых модемов на новые: администраторы имитировали сбой на линии, после чего сообщали клиенту, что его модем сломался и бесплатно меняли его на новый. Перенастраивать операционную систему большинству людей также не потребуется — особенно если все параметры будут установлены в автоматический режим.
Однако даже если вдруг в процессе «переезда» с одного протокола на другой модем забарахлит и перестанет принимать сигнал — лучше потерпеть день или два, а затем все вернется в привычное русло. И в течение ближайшего миллиона лет новые протоколы нам вряд ли понадобятся.
IPv6 для домашних сетей
В этой статье мы постараемся описать текущее состояние поддержки и варианты внедрения IPv6 в домашних сетях. Статья написана осенью 2012 года, вполне возможно, что уже через год она будет совершенно неактуальной, но всё-таки мы опишем статус IPv6 на сегодняшний день. Информация ориентирована в первую очередь на провайдеров домашних сетей, соответственно, под определение «провайдер» в данной статье магистралы не подпадают.
Не так давно закончилась свободная раздача IPv4 адресов, поэтому вопросов по IPv6 с каждым днём становится всё больше. Но сами вопросы чаще всего показывают разрыв между понятием IPv6 в головах вопрошающих и реальным положением вещей.
Из наиболее частых вопросов можно выделить: «А ваш биллинг поддерживает IPv6 адреса?». При этом ответ: «А всё ваше оборудование готово к его внедрению?» вызывает удивление: «А что там готовить надо?».
Не хочется заниматься переписыванием основ IPv6 из rfc (http://tools.ietf.org/html/rfc2460) или википедии (http://ru.wikipedia.org/wiki/Ipv6), поэтому на этот фундаментальный вопрос ответим двумя предложениями. IPv4 и IPv6 — это два разных протокола, совсем разных. Как, например, AppleTalk или IPX — совсем разные. Поэтому IPv6 — это не просто «другие адреса», это совершенно другой протокол.
Вышесказанное необходимо осознавать в первую очередь украинским провайдерам: никакого UA-IX в IPv6 сетях нет, протоколом заложены элементы маршрутизации уже в заголовке IPv6 пакета (http://tools.ietf.org/html/rfc3587), сети аггрегируются по умолчанию, IPv6 full-view не может превышать 8К префиксов. Соответственно, провайдерам прийдётся отвечать на волну вопросов абонентов: «А почему у меня нет 100М на UA-IX?».
Также, в настоящее время ни одна биллинговая система не поддерживает полноценное управление IPv6. Некоторые системы заявили о поддержке IPv6, но на практике эта «поддержка» представляет собой лишь модифицированное поле IP адреса. А по стандарту, конечному пользователю адрес не выделяется, конечному пользователю должна выделяться сеть, по старым рекомендациям — /48 сеть (http://tools.ietf.org/html/rfc6177), по новым рекомендациям RIPE — уже /56 сеть, т.е. 256 сетей по 18446744073709551616 адресов. Повторим — каждому абоненту. Ни один из известных биллингов в настоящее время не поддерживает данные стандарты.
Тем не менее, невозможность получить IPv4 адреса и неуклонное подорожание их аренды заставляет задумываться об использовании IPv6 протокола.
Мы рассмотрим два варианта внедрения IPv6: в Dual-Stack, и «чистого» IPv6.
Использование IPv6 в Dual-Stack
Dual-Stack — это параллельное использование IPv6 и IPv4. Пользователь получает оба варианта адресов. Очевидно, что выдавать реальный IPv4 адрес при этом никто не собирается, т.к. тогда смысла в IPv6 для провайдера нет, задача стоит экономить IPv4 адреса.
В настоящее время всё клиентское оборудование хорошо и качественно поддерживает получение адресов и маршрутов для обоих протоколов, со стороны пользователей Dual-Stack проблем не вызывает. Однако, со стороны провайдера всё несколько грустнее.
Начнём с коммутаторов доступа. Прекрасно показавшая себя связка dhcp snooping + opt82 имеется «из коробки» в IPv6 протоколе, только называется она opt37 (http://tools.ietf.org/html/rfc4649), но при этом сам коммутатор должен поддерживать IPv6 протокол, как минимум, уметь блокировать «чужие» RA, фильтровать ND, пр. Иначе ситуация будет подобна сети с DHCP на «тупых» свичах, где адреса раздаёт любой клиентский роутерчик.
На сегодняшний день подобная поддержка IPv6 известна только у последних D-Link, начиная с DES-3200, и более экстремальных вариантах типа коммутаторов SNR от уважаемого nag.ru, приобретая которые провайдер за собственные деньги подписывается в вечные бета-тестеры глюков прошивок. Но, надо отдать должное DCN (http://www.dcnglobal.com): а это и SNR, и Edge-Core, и многие другие торговые марки, — покупая коммутаторы D-Link, тоже немало времени будет потрачено администраторами на бета-тестирование и отлов багов.
Также, нельзя не отметить, что тестирование работы необходимого IPv6 функционала под реальной нагрузкой особо не проводилось, у подавляющего большинства провайдеров IPv6 существует только в тестовом виде, так что рискнувший на внедрение IPv6 в эксплуатацию, вполне может стать первопроходцем на этом поле.
Использование же VPN (PPTP, PPPoE) для выдачи адресов, несомненно, уменьшает запросы к коммутаторам доступа, однако увеличивает объём негатива среди абонентов.
Итого: в настоящее время поддержка необходимых функций защиты IPv6 сети имеется лишь у незначительного количества новых моделей коммутаторов «нестабильных» производителей.
Не лучше обстоят дела в центре сети. Мы не будем тщательно рассматривать вариант, где центром сети является сервер под FreeBSD/Linux, подобные сети обычно невелики, и имеющихся у них /22 или даже /23 IPv4 адресов с головой и надолго хватит на всех пользователей. Напомним только, что для FreeBSD dummynet пока ещё не научился использовать несколько ядер.
- number of unicast mac addresses: 1.5K
- number of IPv4 unicast routes: 2.75K
- number of directly-connected IPv4 hosts: 1.5K
- number of indirect IPv4 routes: 1.25K
- number of directly-connected IPv6 addresses: 1.5K
- number of indirect IPv6 unicast routes: 1.25K
- number of unicast mac addresses: 3K
- number of IPv4 unicast routes: 11K
- number of directly-connected IPv4 hosts: 3K
- number of indirect IPv4 routes: 8K
Но самая главная проблема заключается в том, что пользователей необходимо NAT-ить под реальный IPv4. В условиях «средней» сети это совсем непростая задача. Необходимость прогонять пару гигабит через сервера приведёт к низкому качеству трафика, высоким задержкам, жалобам и оттоку абонентов.
Получается, что при объёме трафика в несколько гигабит возвращаться к «софтовым» шейперам на базе FreeBSD/Linux/Mikrotik уже невозможно, а приобретать оборудование уровня Cisco ASR1000 — нереально дорого.
Да и что делать с самим IPv6 трафиком, тоже вопрос. Отдавать аплинку? Почти все аплинки отдельно тарифицируют транзит IPv6 трафика. Заворачивать у себя IPv6 to IPv4? Тогда использование IPv6 вообще не имеет смысла. Поднять туннельный пиринг с кем-либо типа Hurricane Electric (http://www.tunnelbroker.net/new_tunnel.php?type=bgp)? Во-первых, трафик пойдёт через «мир» (у кого есть подобное разделение), во-вторых, при достижении определённых лимитов, Hurricane Electric тоже начнёт брать деньги за транзит. Получается, что кроме увеличения накладных расходов, внедрение IPv6 ничего положительного не даст. Если уж всё равно использовать NAT, то можно просто NAT-ить серые IPv4 адреса, и всё. Пользователи не заметят разницы.
Итого: типичное для «среднего» провайдера оборудование либо совсем невозможно использовать для работы пользователей в Dual-Stack, либо же оно будет нагружено сильнее в несколько раз (отдельная маршрутизация плюс NAT).
Использование «чистого» IPv6
С учётом нецелесообразности развёртывания Dual-Stack в домашних сетях, у провайдеров возникает вполне логичный вопрос: «А что, если мы только один сегмент сети переведём на «чистый» IPv6, а остальные пусть работают, как раньше?». В теории подобная схема выглядит неплохо: поставить отдельную железку под IPv6, раздать пользователям IPv6 адреса, докупить у аплинков IPv6 транзит — и пусть себе работают. Рассмотрим подробнее, как обстоят дела с поддержкой «чистого» IPv6 в настоящее время.
В этот раз опустим анализ коммутаторов доступа — всё аналогично описанному в разделе про Dual-Stack, разве что необходимо отметить, что коммутаторы D-Link при получении IPv6 по автоконфигурации не видят предлагаемых роутов, так что надо быть готовым к тому, что default gateway необходимо будет прописывать вручную.
В качестве примера «центра» сети мы опять использовали оборудование Cisco, IOS версии 15.1. К «настоящей» cisco претензий нет никаких: IPv6 адреса и маршруты как по автоконфигурации, так и по DHCPv6 получает корректно; сама в роли роутера выступает корректно; вариантов работы с RA, ND и пр. множество, всё функционирует согласно документации; адреса раздаёт как по автоконфигурации, так и по DHCPv6 тоже корректно. Тут провайдеры домашних сетей могут только позавидовать магистралам, у которых проблем с запуском IPv6 особо и нет.
Перейдём к клиентскому оборудованию. Об этом писалось много раз, например, самим IETF (http://tools.ietf.org/html/rfc6586), однако надежда на то, что поддержка IPv6 активно развивается производителями, заставила пробежаться по основным вариантам пользовательских подключений. А именно, мы проверили работоспособность «чистого» IPv6 подключения для Wi-Fi роутера Cisco (Linksys), а также компьютеров под управлением Debian/Ubuntu, Mac OS X, Windows 7. Всё вышеперечисленное имело последние версии ПО/обновлений/патчей/прошивок.
- На WAN порту роутер корректно получил IPv6 адрес и маршруты, однако не подхватил DNS. Вручную прописанный DNS корректно заработал.
- Даже при отключенной поддержке IPv4 роутер пытается его использовать, так, например, ping на 2a00:1450:400d:804::1009 работает, а вот ping на google.com говорит, что не может найти А запись. Тоже относится к NTP: в поле ввода сервера прописать IPv6 адрес можно, но роутер пытается отрезолвить его А запись, и засыпает лог соответствующими ошибками.
- Роутер не умеет делать IPv6 NAT. Никак не удалось настроить выход в интернет из локалки с использованием «серых» адресов. Единственное решение — это в настройках DHCPv6 на роутере прописать реальную IPv6 сеть для LAN и прописать соответствующие маршруты в разделе IPv6 роутинга.
- При инсталяции Debian корректно получает IPv6 адрес по автоконфигурации, маршруты и DNS работают корректно, однако при переполучении адреса теряются все маршруты, включая default gateway. Соответственно, доступ в интернет пропадает, что может привести к остановке инсталляции при коротком таймауте DHCP lease.
- При запуске установленной системы IPv6 адрес и DNS Debian получает корректно как по автоконфигурации, так и по DHCPv6, однако default gateway упорно отсутсвует, его необходимо прописывать вручную. Радует только то, что в дальнейшем он не затирается при переполучении адреса.
- IPv6 адрес и маршруты получает корректно как по автоконфигурации, так и по DHCPv6, однако DNS не подхватывается. При прописывании DNS вручную всё работает корректно.
- Несмотря на то, что сеть полностью функционирует, для сетевых подключений выводится значок ошибки с восклицательным знаком. Чтобы его убрать, необходимо зайти в настройки сети, выбрать получение адреса вручную, и прописать любой IPv4 адрес.
- IPv6 адрес получает как по автоконфигурации, так и по DHCPv6, однако маска устанавливается /48, вне зависимости от того, какую выдаёт сервер. Вспомним рекомендации RIPE о выдаче /56 сетей, получается, что в случае Windows автоматическая раздача адресов невозможна.
- DNS не подхватывается. При прописывании DNS вручную его параметры сохраняются.
- Предложенные маршруты в таблицу маршрутизации заносятся, но с приоритетом меньшим, чем туннели Teredo. Для того, чтобы заработало IPv6 подключение, необходимо остановить и отключить связанные с туннелями службы и настройки, из которых бОльшая часть требует прав администратора. Более того, часть операций возможно осуществить только (!) через командную строку, используя утилиту netsh.
- Даже после упомянутых выше операций «чистая» IPv6 в данной ОС не функционирует, выводится значок ошибки «Подключение ограничено или отсутствует». Необходимо прописать любой IPv4 адрес, без шлюза и DNS, после чего IPv6 сеть начинает полноценно функционировать.
- по IPv6 работают: google, youtube, facebook, vkontakte
- по IPv6 не работают: skype, icq, yandex, odnoklassniki, steam, ex.ua и почти все остальные, включая новостные, развлекательные и игровые ресурсы.
Да и заявленная работоспособность, например, youtube, тоже относительна: сам ресурс полностью поддерживает IPv6, однако для его использования нужен Adobe Flash Player, который скачать и установить невозможно, т.к. все ресурсы Adobe недоступны по IPv6.
Выходом остаётся всё тот же NAT, только уже в другом направлении, а единственным известным софтверным решением является TAYGA, NAT64 for Linux (http://www.litech.org/tayga), последние изменения в котором датированы 10.06.2011, и который не входит в состав ни одного распространённого дистрибутива. Да и очевидно, что более 90% клиентского трафика будет уходить в IPv4 сеть, а вопросы необходимых мощностей для Dual-Stack рассматривались выше.
Итоги
- В настоящее время провайдерам домашних сетей протокол IPv6 можно рассматривать как вспомогательный, ожидать скорого перехода на IPv6 в мире не имеет смысла по причине не очень широкого наполнения IPv6 сети пользовательскими ресурсами.
- Не представляется практически возможным развернуть «чистую» IPv6 сеть: ни оборудование доступа, ни абонентское оборудование не поддерживает полноценную сеть без IPv4 протокола.
- Использование Dual-Stack не имеет смысла, т.к. представляет из себя всё тот же NAT, но отягощённый необходимостью обновить всё оборудование доступа и центра на поддерживающее IPv6, а также отдельно приобретать полосу для транзита IPv6 трафика.
- Фактически в настоящее время использовать IPv6 сеть будут только сервисы google и торренты, остальной трафик будет уходить в IPv4. Вопрос: менять ли всё оборудование доступа ради улучшенной поддержки торрентов? — надо полагать, для провайдеров имеет только один ответ.
UPD: Приношу извинения andrewsh, что не заметили собранного им пакета tayga для Debian Wheezy.