sintech Опубликовано 30 июня, 2011 (изменено) · Жалоба После чего их ПР могут идти далеко с заявлениями о "технологичности" компаний. Даже для галочки не смогли нигде в6 поднять, пусть бы хоть на пинги отвечало. http://www6.mail.ru Хороший пример поднятия v6 для галочки. На главной доступной по v6 все ссылки ведут на сайты v4. Вот еще пример: ipv6.yandex.ru Изменено 30 июня, 2011 пользователем sintech Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nomo Опубликовано 30 июня, 2011 · Жалоба p.s. вот у меня счас работает между двемя маршрутизаторами \126 и пашет же Ну и что? Вот у меня сейчас работает между двумя маршрутизаторами вообще без адресов. И пашет же! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 30 июня, 2011 · Жалоба И вновь становятся актуальными фильтрующие мосты: http://www.usenix.org/events/neta99/full_papers/limoncelli/limoncelli_html/ http://www.freebsd.org/doc/en_US.ISO8859-1/articles/filtering-bridges/article.html Хотя почитав это, как думается про коммутатор с л3 фильтрацией. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mt6561 Опубликовано 1 июля, 2011 · Жалоба www6.mail.ru, ipv6.yandex.ru - открывается фактически только главная страница. ЛЮБОЙ клик уводит на v4 сайт. В чем прикол-то? ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tima Опубликовано 1 июля, 2011 · Жалоба В том, что не все сразу :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 12 июля, 2011 · Жалоба Если речь о заливке прошивки через веб интерфейс в железку, то вендоры любят по разным оффсетам писать волшебные идентификаторы, чтобы хотя бы через гуй пользователи не лили всякую хрень, в тч прошивки конкурентов. Некоторые вообще умудряются криптовать прошивку. Программисты, ничего не понимаю, помогите советом. Есть TP-Link TL-WR841ND ver. 5.4 Здесь http://wiki.openwrt.org/toh/tp-link/tl-wr841nd сказано, что аппаратная ревизия 5.х поддерживает "OEM easy installation". Здесь http://svn.code.sf.net/p/dslite-6rd/svn/backfire/ выкачал исходники с поддержкой 6rd. Через "make menuconfig" подправил дефолтный конфиг для линксиса, изменив таргет профиль на свое железо, сохранил, вышел. Скомпилировал. В /bin должны попасть результаты. Все на месте, и со squashfs и с jffs2. Беру имидж с поддержкой squashfs. Подсовываю его для обновления, ругается, что вообще не видит имиджа. Добавляю расширение .bin, ругается, что не тот формат. Беру заведомо рабочую прошивку здесь http://downloads.openwrt.org/backfire/10.03.1-rc4/ar71xx/openwrt-ar71xx-tl-wr841nd-v5-squashfs-factory.bin Все проходит успешно. Пытаюсь уже из нее залить свою, ругается "The uploaded image does not contain a supported format". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 12 июля, 2011 · Жалоба Я пихал фряху, в другие коробочки и не из дефолтной прошивки. Читайте инструкции, где то должен быть ответ на ваш вопрос. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 2 августа, 2011 (изменено) · Жалоба Учитесь продавать ipv6! На каждую виртуалку в Xen выделяют: IPv4 1x IPv6 5x (с) Изменено 2 августа, 2011 пользователем vlad11 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 2 августа, 2011 · Жалоба vlad11 у них панельки типа SolusVM и аналогичных не умеют адреса назначать виртуалкам иначе как поштучно. Там, где сделано не через зад, выделяют по 1x/128 + 1x/64 на VPS. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
netime Опубликовано 2 августа, 2011 · Жалоба Вот не помню такоего в RFC на сам адрес, что - то подобное было в куске про автоконфиругирование ( вроде это опция) . Половина провайдеров, которые работают с IPv6 выдает клиентам аж поштучно. нищеброды, дебилы, отстой, торгаши сраные, идете работать в грузчики, итд итп. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 15 августа, 2011 · Жалоба Нарисовал примерную схему как я понимаю совместную работу ipv6 и ipv4. Но возникли вопросы для нагрузки существующего ipv6 канала: как аннонсировать 192.88.99.1/24 в пределах одной AS, а не грузить публичные 192.88.99.1/24 ? чем "натить" 2002::/16 из свой AS? как перехватывать запросы к публичным teredo-серверам, например от Микрософт? сколько вообще существует публичных teredo-брокеров? как получить их список? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 16 августа, 2011 · Жалоба Не уверен, что до конца понял суть вашей мысли. Если цель не предоставлять клиентам нативный IPv6, а пытаться работать на 6to4 и teredo, то: * так прямо и анонсировать эникастом, внешние зарезать. * "натить" не надо, сорцы IPv6 адреса вида 2002:... успешно уйдут с вашего релея к реальному нативному IPv6 хосту, а обратный пакет вернется на, скорее всего, чужой ретранслятор, анонсирующий 2002:/16 Можно вообще не поднимать свой релей, а пользоваться чужим * Смотрите на первичную инициализацию, например здесь http://www.scribd.com/doc/22176512/490/to4-Support-in-Windows * не знаю Нужно помнить, что ни 6to4 ни teredo не спасают вас от распространения обратного трафика через чужой релей. Вам это грозит постоянными проблемами, а чуть позже полным закрытием публичных релеев ввиду увеличения трафика. Насколько я знаю, по этой причине никто не идет по этому пути. Ваш выбор 6RD (если экономите на натив). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 16 августа, 2011 (изменено) · Жалоба Если цель не предоставлять клиентам нативный IPv6, а пытаться работать на 6to4 и teredo, то: Цель пока не предоставляя native ipv6, завернуть весь траффик с 2002::/16 и 2001::/32 внутри AS на канал ipv6. Чтоб не грузить публичные сервисы. * так прямо и анонсировать эникастом, внешние зарезать. А какой тогда сервис будет осуществлять трансляцию из 192.88.99.1/24 в ipv6 ? * "натить" не надо, сорцы IPv6 адреса вида 2002:... успешно уйдут с вашего релея к реальному нативному IPv6 хосту, а обратный пакет вернется на, скорее всего, чужой ретранслятор, анонсирующий 2002:/16 в том-то и дело, что хочется, чтоб возврат пошел к нам по ipv6 каналу. * Смотрите на первичную инициализацию, например здесь http://www.scribd.com/doc/22176512/490/to4-Support-in-Windows Буду смотреть. Проще прикрыть порты чужых teredo серверов/релеев. Нужно помнить, что ни 6to4 ни teredo не спасают вас от распространения обратного трафика через чужой релей. Вам это грозит постоянными проблемами, а чуть позже полным закрытием публичных релеев ввиду увеличения трафика. Насколько я знаю, по этой причине никто не идет по этому пути. Ваш выбор 6RD (если экономите на натив). Мдас. Это тоже костыль. Значит, надо максимально быстро клиентам выдавать native ipv6. Изменено 16 августа, 2011 пользователем vlad11 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 16 августа, 2011 · Жалоба А какой тогда сервис будет осуществлять трансляцию из 192.88.99.1/24 в ipv6 ? Это делает релей, например на 7600. Только скорее не трансляцию, а убирание обертки из Ipv4 адреса и пересылку внутреннего IPv6 содержимого дальше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 16 августа, 2011 · Жалоба А какой тогда сервис будет осуществлять трансляцию из 192.88.99.1/24 в ipv6 ? Это делает релей, например на 7600. Только скорее не трансляцию, а убирание обертки из Ipv4 адреса и пересылку внутреннего IPv6 содержимого дальше. Кошек нет и врядли будут. Аналог под Linux|FreeBSD есть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 16 августа, 2011 (изменено) · Жалоба Кошек нет и врядли будут. Аналог под Linux|FreeBSD есть? Это таки 6to4 через stf|sit. на lo0 цепляем ip из 192.88.99.0/24 его же прописываем статиком в пределах AS Настраиваем stf|sit, указывая ipv4 адрес из 192.88.99.0/24, а в ipv6 весь префикс, выданный RIPE Сперто с Free Изменено 16 августа, 2011 пользователем vlad11 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bambuk Опубликовано 23 августа, 2011 · Жалоба Планируем раздавать абонентам /56 или /60. Чтобы в случае флапа доступа, абоненту всегда выдавался один и тот же префикс и адреса в LAN абонента оставались без изменений, думаем статически привязывать эти префиксы к абонентам. А как делаете вы и что думаете по этому поводу? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ivb1232 Опубликовано 31 августа, 2011 · Жалоба Подняли BGP IPV6 с магистралом. У абонентов "серые" и "белые" IPV4 На выходе жунипер мх. Следующий шаг 6rd пробовать, смысл есть ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 1 сентября, 2011 · Жалоба Bambuk звучит нормально. ivb1232 6rd промежуточный вариант, по идее его пользуют временно, чтобы прямо сейчас с минимальными затратами и апгрейдами чего-то раздать. Comcast к примеру от него уходит. Посмотрите, может вам 6rd и не нужен? Сразу на обычный dual-stack. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fenix-vt Опубликовано 8 сентября, 2011 · Жалоба Подскажите, пожалуйста, с чем связано требование программы Google over IPv6 поднимать отдельные сервера DNS для IPv6 и IPv4 протоколов? Ну, кроме мифического риска доступности их ресурсов по обоим протоколам одновременно? Вставляется ли какой-то "модуль" от Гугла в IPv6-DNS сервер провайдера для организации доступа по IPv6 для Dual-stack сетей? Спасибо! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
iten Опубликовано 9 сентября, 2011 · Жалоба интересует вопрос. если действительно выдавать /64 на клиента, как настраивать интерфейс, скажем на cisco? не сажать же каждого клиента в отдельный влан/сабинтерфейс/интерфейс влан. а если завести все префиксы на одном интерфейсе, клиенты будут использовать чужие ip. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 9 сентября, 2011 · Жалоба А почему бы и не посадить каждого клиента в отдельный влан? QinQ решает вопрос количества вланов. Я реализовал дуалстек таким образом: vlan per customer, индивидуальные v6 и серые v4 подсети каждому клиенту, а также белые v4 адреса поштучно (rfc3069). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bambuk Опубликовано 10 сентября, 2011 · Жалоба Клиенту выдавать CPE. С помощью DHCPv6-PD назначать на CPE /56. CPE из выделенного префикса назначает на свои интерфейсы /64 и может делегировать более короткие префиксы для другой инфраструктуры клиента. Так правильнее будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 10 сентября, 2011 · Жалоба интересует вопрос. если действительно выдавать /64 на клиента, как настраивать интерфейс, скажем на cisco? не сажать же каждого клиента в отдельный влан/сабинтерфейс/интерфейс влан. а если завести все префиксы на одном интерфейсе, клиенты будут использовать чужие ip. У более-менее серьёзных операторов обычно используются брасы, которые, как правило, умеют делать динамическую привязку mac<->ip(после авторизации(например, по id порта на доступе, по mac, по связке mac и vlan и т.п.)) и если много ваших кастомеров будут в одном влане, то по L2 они друг друга не увидят(если конечно включить pvlan/segmentation на доступе), а будут ходить друг к другу через шлюз. При этом забирать чужие ip они тоже не смогут,т.к. брас создаст привязку mac-ip. Если у вас есть возможность засунуть каждого абонента в отдельный vlan, то с точки зрения безопасности это самое правильное решение. И самое главное, что это минимизирует кол-во софтфич на доступе и теортечески можно сделать авторизацию по первому и второму тэгу(если брас сумеет запихнуть это в radius-запрос) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 11 сентября, 2011 · Жалоба Клиенту выдавать CPE.Так правильнее будет. Идея неправильная с точки зрения бизнеса.Возрастают затраты на обслуживание - возникает лишняя точка отказа, критичная к сбоям питания. Поскольку эра ipv6 only ещё не наступила, то дешёвые CPE создадут узкое место на торрентах с кучей v4 коннектов и мелкими udp пакетиками, и тому подобных задачах. Объяснять пользователю, что во время игры в "контру" торренты лучше ставит на паузу - это даже не смешно. Далее - если выдавать за счёт оператора, то это зачем-то ещё и лишние затраты. А навязывать клиенту выкуп/аренду CPE в РФ запрещено законом. Самый лучший вариант - чтобы можно было воткнуть патчик в клиентский компьютер и всё работало само. А при необходимости включения более одного компьютера - чтобы по-минимуму хватало простейшего свича-мыльницы. Пример правильного подхода - известный в мск провайдер OnLime. (впрочем, как у них с v6 - не знаю…) Если у вас есть возможность засунуть каждого абонента в отдельный vlan, то с точки зрения безопасности это самое правильное решение. И самое главное, что это минимизирует кол-во софтфич на доступеИменно!И позволяет использовать самые дешёвые решения для доступа, типа DES-1228/ME, от которых ничего кроме dot1q и не требуется вовсе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...