[sintech]

После чего их ПР могут идти далеко с заявлениями о "технологичности" компаний. Даже для галочки не смогли нигде в6 поднять, пусть бы хоть на пинги отвечало.

 

http://www6.mail.ru

Хороший пример поднятия v6 для галочки.

На главной доступной по v6 все ссылки ведут на сайты v4.

Вот еще пример: ipv6.yandex.ru

Изменено 30 июня, 2011 пользователем sintech

[nomo]

p.s. вот у меня счас работает между двемя маршрутизаторами \126 и пашет же

Ну и что? Вот у меня сейчас работает между двумя маршрутизаторами вообще без адресов. И пашет же!

[Ivan_83]

И вновь становятся актуальными фильтрующие мосты:

 

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 фильтрацией.

 

 

[mt6561]

www6.mail.ru, ipv6.yandex.ru - открывается фактически только главная страница. ЛЮБОЙ клик уводит на v4 сайт. В чем прикол-то? ;)

[Tima]

В том, что не все сразу :)

[rus-p]

Если речь о заливке прошивки через веб интерфейс в железку, то вендоры любят по разным оффсетам писать волшебные идентификаторы, чтобы хотя бы через гуй пользователи не лили всякую хрень, в тч прошивки конкурентов.

 

Некоторые вообще умудряются криптовать прошивку.

 

Программисты, ничего не понимаю, помогите советом.

 

Есть 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".

[Ivan_83]

Я пихал фряху, в другие коробочки и не из дефолтной прошивки. Читайте инструкции, где то должен быть ответ на ваш вопрос.

[vlad11]

Учитесь продавать ipv6!

На каждую виртуалку в Xen выделяют:

IPv4 	1x
IPv6 	5x

 

(с)

Изменено 2 августа, 2011 пользователем vlad11

[rm_]

vlad11

у них панельки типа SolusVM и аналогичных не умеют адреса назначать виртуалкам иначе как поштучно.

Там, где сделано не через зад, выделяют по 1x/128 + 1x/64 на VPS.

[netime]

Вот не помню такоего в RFC на сам адрес, что - то подобное было в куске про автоконфиругирование ( вроде это опция) . Половина провайдеров, которые работают с IPv6 выдает клиентам аж поштучно.

нищеброды, дебилы, отстой, торгаши сраные, идете работать в грузчики, итд итп.

[vlad11]

Нарисовал примерную схему как я понимаю совместную работу ipv6 и ipv4.

 

Но возникли вопросы для нагрузки существующего ipv6 канала:

• как аннонсировать 192.88.99.1/24 в пределах одной AS, а не грузить публичные 192.88.99.1/24 ?
  
• чем "натить" 2002::/16 из свой AS?
  
• как перехватывать запросы к публичным teredo-серверам, например от Микрософт?
  
• сколько вообще существует публичных teredo-брокеров? как получить их список?
  

[rus-p]

Не уверен, что до конца понял суть вашей мысли.

Если цель не предоставлять клиентам нативный IPv6, а пытаться работать на 6to4 и teredo, то:

* так прямо и анонсировать эникастом, внешние зарезать.

* "натить" не надо, сорцы IPv6 адреса вида 2002:... успешно уйдут с вашего релея к реальному нативному IPv6 хосту, а обратный пакет вернется на, скорее всего, чужой ретранслятор, анонсирующий 2002:/16

Можно вообще не поднимать свой релей, а пользоваться чужим

* Смотрите на первичную инициализацию, например здесь http://www.scribd.com/doc/22176512/490/to4-Support-in-Windows

* не знаю

 

Нужно помнить, что ни 6to4 ни teredo не спасают вас от распространения обратного трафика через чужой релей.

Вам это грозит постоянными проблемами, а чуть позже полным закрытием публичных релеев ввиду увеличения трафика.

Насколько я знаю, по этой причине никто не идет по этому пути.

Ваш выбор 6RD (если экономите на натив).

[vlad11]

Если цель не предоставлять клиентам нативный 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

[rus-p]

А какой тогда сервис будет осуществлять трансляцию из 192.88.99.1/24 в ipv6 ?

 

Это делает релей, например на 7600. Только скорее не трансляцию, а убирание обертки из Ipv4 адреса и пересылку внутреннего IPv6 содержимого дальше.

[vlad11]

А какой тогда сервис будет осуществлять трансляцию из 192.88.99.1/24 в ipv6 ?

 

Это делает релей, например на 7600. Только скорее не трансляцию, а убирание обертки из Ipv4 адреса и пересылку внутреннего IPv6 содержимого дальше.

 

Кошек нет и врядли будут.

Аналог под Linux|FreeBSD есть?

[vlad11]

Кошек нет и врядли будут.

Аналог под 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

[Bambuk]

Планируем раздавать абонентам /56 или /60.

Чтобы в случае флапа доступа, абоненту всегда выдавался один и

тот же префикс и адреса в LAN абонента оставались без изменений,

думаем статически привязывать эти префиксы к абонентам.

А как делаете вы и что думаете по этому поводу?

[ivb1232]

Подняли BGP IPV6 с магистралом.

У абонентов "серые" и "белые" IPV4

На выходе жунипер мх.

Следующий шаг 6rd пробовать,

смысл есть ?

[rm_]

Bambuk

звучит нормально.

 

ivb1232

6rd промежуточный вариант, по идее его пользуют временно, чтобы прямо сейчас с минимальными затратами и апгрейдами чего-то раздать.

Comcast к примеру от него уходит. Посмотрите, может вам 6rd и не нужен? Сразу на обычный dual-stack.

[fenix-vt]

Подскажите, пожалуйста, с чем связано требование программы Google over IPv6 поднимать отдельные сервера DNS для IPv6 и IPv4 протоколов?

Ну, кроме мифического риска доступности их ресурсов по обоим протоколам одновременно?

Вставляется ли какой-то "модуль" от Гугла в IPv6-DNS сервер провайдера для организации доступа по IPv6 для Dual-stack сетей?

Спасибо!

[iten]

интересует вопрос.

если действительно выдавать /64 на клиента, как настраивать интерфейс, скажем на cisco?

не сажать же каждого клиента в отдельный влан/сабинтерфейс/интерфейс влан.

а если завести все префиксы на одном интерфейсе, клиенты будут использовать чужие ip.

[rdc]

А почему бы и не посадить каждого клиента в отдельный влан? QinQ решает вопрос количества вланов.

Я реализовал дуалстек таким образом: vlan per customer, индивидуальные v6 и серые v4 подсети каждому клиенту, а также белые v4 адреса поштучно (rfc3069).

[Bambuk]

Клиенту выдавать CPE. С помощью DHCPv6-PD назначать на CPE /56.

CPE из выделенного префикса назначает на свои интерфейсы /64

и может делегировать более короткие префиксы для другой инфраструктуры клиента.

Так правильнее будет.

[s.lobanov]

интересует вопрос.

если действительно выдавать /64 на клиента, как настраивать интерфейс, скажем на cisco?

не сажать же каждого клиента в отдельный влан/сабинтерфейс/интерфейс влан.

а если завести все префиксы на одном интерфейсе, клиенты будут использовать чужие ip.

 

У более-менее серьёзных операторов обычно используются брасы, которые, как правило, умеют делать динамическую привязку mac<->ip(после авторизации(например, по id порта на доступе, по mac, по связке mac и vlan и т.п.)) и если много ваших кастомеров будут в одном влане, то по L2 они друг друга не увидят(если конечно включить pvlan/segmentation на доступе), а будут ходить друг к другу через шлюз. При этом забирать чужие ip они тоже не смогут,т.к. брас создаст привязку mac-ip.

 

Если у вас есть возможность засунуть каждого абонента в отдельный vlan, то с точки зрения безопасности это самое правильное решение. И самое главное, что это минимизирует кол-во софтфич на доступе и теортечески можно сделать авторизацию по первому и второму тэгу(если брас сумеет запихнуть это в radius-запрос)

[rdc]

Клиенту выдавать CPE.

Так правильнее будет.

Идея неправильная с точки зрения бизнеса.

Возрастают затраты на обслуживание - возникает лишняя точка отказа, критичная к сбоям питания.

Поскольку эра ipv6 only ещё не наступила, то дешёвые CPE создадут узкое место на торрентах с кучей v4 коннектов и мелкими udp пакетиками, и тому подобных задачах.

Объяснять пользователю, что во время игры в "контру" торренты лучше ставит на паузу - это даже не смешно.

 

Далее - если выдавать за счёт оператора, то это зачем-то ещё и лишние затраты.

А навязывать клиенту выкуп/аренду CPE в РФ запрещено законом.

 

Самый лучший вариант - чтобы можно было воткнуть патчик в клиентский компьютер и всё работало само. А при необходимости включения более одного компьютера - чтобы по-минимуму хватало простейшего свича-мыльницы.

 

Пример правильного подхода - известный в мск провайдер OnLime.

(впрочем, как у них с v6 - не знаю…)

 

Если у вас есть возможность засунуть каждого абонента в отдельный vlan, то с точки зрения безопасности это самое правильное решение. И самое главное, что это минимизирует кол-во софтфич на доступе

Именно!

И позволяет использовать самые дешёвые решения для доступа, типа DES-1228/ME, от которых ничего кроме dot1q и не требуется вовсе.