none7

А вдруг у клиента целый замок и в каждой комнате по роутеру, чтобы было больше 100 мбит/с по Wi-Fi. И каждому нужно минимум 2 сети. Как ему без 65536 сетей? Вообще ИМХО изначально планировалось, что крупные маршрутизаторы не будут хранить все 16 байт префикса маршрута, ограничиваясь шестью, ведь высокоскоростная SRAM недёшева. 48 бит это просто минимально необходимая длина префикса кратная 8, достаточная для решения проблемы дефицита адресов, нижние 64 для метки устройства на основе EUI-64, а дополнительные 16 просто излишек для выравнивания по 32 бита. Экономя почти бесконечные виртуальные цыферки, вы тратите настоящую и очень дорогую память. Если бы вместо IPv6 приняли расширение для IPv4 позволяющее расширять адреса до любой длины, как оператору так и клиенту, то сколько бит вы бы прибавили к своим IPv4-адресам?

ИМХО специально по этому поводу провайдерам стоит начать продавать VPN для действующих абонентов. Если трафик будет от пира, то это лишь незначительно поднимет себестоимость услуги. Преимущество перед NAT очевидно. Если основной линк отвалится, то абонент этого даже не заметит, а отвал ядра сети явление редкое. Можно даже сделать из этого комплексную услугу, когда абонент просто арендует роутер с батарейками на 10-15 часов работы и дополнительным беспроводным каналом подключенным к виртуальному оператору. Все деньги пойдут одному провайдеру, а тратится будут только при поломке основного канала к абоненту. Так же NAT плохо дружит с IPSec, а ведь именно его предлагается использовать для соединения с корпоративными сетями вместо разнообразных VPN. Ведь все туннельные интерфейсы регулярно создают конфликты адресации. Кстати, если маркетологи будут убеждать корпоративных клиентов, что им просто необходимо удобство прозрачной адресации, то может быть удастся продать IPv6.

Не у всех ли сотовых операторов есть тариф 10+ рублей за мегабайт трафика для всех не купивших пакет в несколько гигабайт? Если хоть один байт будет отправлен за пределы социально-значимого ресурса, то доступ станет не таким уж и бесплатным. Если покупать пакет трафика, то какой смысл в этих бесплатных ресурсах?

Ох, "сам дурак" это в данном случае обо мне. Как я понял речь о нерабочем DNS-резольвере по причине blackhole, IPv6 тут вообще нипричём. Но ведь у CPE должен быть IPv4-адрес резольвера, какой в CPE кривой DNS forwarder, если не пытается в случае ошибок отправки запроса к первому не пытается осуществить отправку второму. Никаких таймаутов в случае отсутсвия маршрута быть не должно, а если маршрут работает, но используя link-local, то это уже баг ОС.

Использование link-local адреса для DNS-сервера это не лучшая идёя и вообще для всех протоколов передающих адреса. Учитывая, что угадывание идентификфтора интерфейса не входит в обязанности ПО. Нормально link-local адреса будут работать только в link-local p2p, вроде SMB или MDNS. Если у IPv4 несколько интерфейсов с адресами 169.254.*, то там вероятно выползет таже самая проблема, этими адресами никто не пользуется, но и не учитывают последстия их использования. Проще говоря кто неподумав шорошенько начал использовать link-local адреса, тот сам дурак.

Что мешает изменить структуру адреса, ведь оно не будет конфликтовать с сетью 2001::/32 | prefix (3-64) | client ip bits (64-prefix) | server (32) | port (16) | symmetric (1) | anything (15) | Естественно желательно передать список локальных сетей. В этих протоколах отсутствует оптимизация маршрута. Эти протоколы не лелеет Microsoft и придётся клиентам, что то доустанавливать, в случае Teredo MS пришлёт обновление почти всем. Знаете другой способ быстро развернуть IPv6 с минимальными затратами и при наличии IPv4 only CPE купленных полгода назад. Естественно CPE никто кроме гиков перепрошивать не станет.

6rd требует поддержки CPE и требует поддержки себя в L3-коммутаторах, если конечно нет желания потратить целую сеть /32 только на раздачу одной /64 на IPv4-адрес. Teredo легко проходит через большинство натов, если поставить у провайдера железку для проксирования(relay) и выдать IPv6-адрес из диапазона провайдера, то будет работать на всех типах натов и без задержки первого пакета. При этом железка может быть stateless если клиент сам будет поддерживать подключение, что позволит сделать железку дешёвой. Если каждый IPv4 адрес будет обладать своей сетью /64, то проблем с банами клиентов не будет.

А как быть с конечными серверами и клиентами, они тоже должны его поддерживать, IPv6 даже спустя 20 лет не может дождаться своей поддержки большинством. А так же всё ПО общающееся с интернетом, в том числе серверные скрипты, которые пишут пользователи плохо разбирающиеся в сетях. Всё L3 оборудование провайдера должно поддерживать это расширение. Проблемы те же самые, что и у IPv6, только биллинг и возможно CPE обновлять не нужно, но если их производители обратили бы внимание на IPv6 10 лет назад, то проблемы замены оборудования сейчас бы не стояли. Мне самым экономичным решением видится инкапсуляция протокола в UDP, но с IPv6 тоже так можно и собственно самый успешный переходный механизм Teredo так и работает. Сейчас наиболее разумным для провайдеров будет проталкивать изменения в rfc Teredo необходимые им, а так же требовать у вендоров железки необходимые для работы улучшенного Teredo.

нашёл на одном из сайтов: IPv6 applications are being developed with the belief that IPv6 addressing is end-to-end… Под NAT 2:1 я подразумевал по 2 адреса на каждый узел. Таким образом адрес будет преобразован с сохранением младших 64 бит, например 2001:db8:1234::abcd в 2001:db8:fedc::abcd. При этом определить для какого адреса пришёл пакет не составит труда, даже если такой записи нет в таблице сопоставлений.

Большинство туннельных брокеров и правда используют 6in4, но если не работает gogoCLIENT(TSP протокол), то видимо от IPv6 пытаются избавится целенаправленно. Однако если Вы пытались пользоваться именно им, то есть вероятность, что попали на момент когда у брокера были проблемы с серверами. Никто не запрещает Вам использовать NAT 2:1 для этих целей.

Не зашевелятся, наты дешевле. Зашевелятся только когда появится IPv6-only контент, столь важный, что доступ к нему станет критерием выбора провайдера. Teredo не любит только symmetric NAT и то, MS в последней версии протокола предусмотрела некоторые варианты и для такого типа NAT.

agr Проблема с TCP таймаутом эта проблема 1-2% клиентов в Интернете. Связана эта проблема с одним и тем же, у Вас есть IPv6 маршрут к Google и прочим, но пакеты реально до них не доходят. В данном случае это вызвано багом в ядре Linux, из за которого при получении RA ответа без префикса сети, глобальный IPv6-адрес не настраивается, но настраивается маршрут по умолчанию на этот недороутер. Временное решение: заблокировать в ip6tables RA пакеты от недороутеров. У кого нет такого маршрута, у тех проблем нет, попытка подключения обрывается мгновенно и браузер перебирает адреса дальше.

Сама по себе необходимость юзать DHCPv6 и RADVD поверх PPP - вызывает недоумение. Зачем городить кофигураторы поверх протокола с поддержкой конфигурации? Потому, что это уже принятый стандарт. Конфигурация PPP настраивает только link-local адреса, хотя разработчики стандарта могли скопировать в него весь функционал ICMPv6 RS/RA и DHCPv6, но их никто не убедил в необходимости этого. К тому же эти стандарты изначально были рассчитаны на работу с таким L2, поэтому это не костыль, так и было задумано изначально. Даже если Вы сможете протолкнуть изменения в RFC, то будете ещё 15 лет ждать, пока все реализуют это обновление.

DVB-С есть только в новых моделях, как правило там же есть и DVB-T и MPEG4 декодер. В списке телевизоров market.yandex.ru, в первой двадцатке самых дешёвых моделей, умеющей DVB-T, только 8 умеют и DVB-C, поддержку MPEG4 имеют единицы.

Да.

Дополнительные адреса могут быть получены клиентами через клиентский свитч(много ли таких клиентов?) или префиксом через DHCPv6-PD. Роутеры и винды расшаривающие доступ в сеть, создают свой L3-сегмент, соответственно будут просить DHCPv6-PD. А SNMP TRAP на обновление таблицы ND Snooping'а нельзя настроить? Если нет, то нужно просить у Dlink добавить в прошивку такую возможность, это было бы наилучшим костылём. WXP DNSv6 вообще не умеет, по крайней мере без установки спец.дополнений. Тестировал Ubuntu 10.04, работает только rdnss и то, с ужасными глюками, в частности если сбросить настройки IPv6, то придётся ждать следующего широковещательного RA пакета, так как никаких дополнительных запросов она не делает, даже при down/up интерфейса. Остаётся надеяться, что в новых версиях починили.

isc-dhcp6? В Linux у этого сервера были проблемы с виртуальными интерфейсами, пробуйте другие реализации dhcpv6 сервера. Ещё одна проблема в том, что существующие dhcpv6 сервера для prefix-delegation требуют duid, хотя для vpn подключений это явно лишнее и взять его просто неоткуда. Тут придётся изобретать костыли. Кстати dhcpv6 без RA ничего не даст, у клиента не будет настроен маршрут по умолчанию.

Может у Вас v6 мультикаст от клиентов фильтруется? Или косяк в коммутаторе фильтрующий v6. Смотрел широковещательный трафик в маленькой сети (около 500 машин) и раз в 2-3 секунды приходил DHCPv6 пакет. В каком смысле? (вспоминается выражение "немножко беременна"). В смысле вообще не работают. Оба. Если считать роутеры не поддерживающие v6 вообще, то да не работают. Сама же Windows 7 прекрасно поддерживает DHCPv6 и SLAAC, лично тестировал и то и другое и даже через pppoe. А по поводу бриджинга, как Вы собираетесь отличать одних клиентов от других на бордере? Создадите список адресов для каждого клиента? И сколько адресов смогут фильтровать Ваши коммутаторы доступа? Сгруппировать адреса сеткой не /64 не получится, SLAAC не даст, DHCPv6 поддерживают не все(например Apple), а руками настраивать всех клиентов Вы не хотите. Придётся сидеть и ждать минимум 10 лет(устаревшие технологии умирают очень долго) пока весь мир поймёт насколько гениальна Ваша идея и начнут делать ОС и железки совместимые с Вашей сетью.

Нет на сервере никакого trunk, вот ссылка.

Не понимаю в чём проблема размещения 6rd relay, необходимо отроутить трафик на него мимо NAT, но через шейпер. На цисках это должно решаться одним правилом в access-list. 6rd - временный механизм для переходя на IPv6. За год использования 6rd они выкинули всё несовместимое с native IPv6 железо и теперь 6rd им не нужен, так как у них Native Dual Stack.

Должен уметь. Настройка 6rd-шлюза по идее не должна сильно отличатся от настройки клиента. ip tunnel add 6rdtun mode sit local 10.0.0.1 ttl 64 ip tunnel 6rd dev 6rdtun 6rd-prefix 2001:db8:f000::/36 6rd-relay_prefix 10.0.0.0/8 ip link set 6rdtun up ip add address 2001:db8:f000::1/36 dev zs6rdtun

В каком смысле получить доступ? К тому же сеть 2002::/16 одна и является всея IPv4-Интернетом. Весь трафик на 2002::/16 нужно отправлять в туннельный 6to4 интерфейс, дальше пойдёт обычный IPv4 роутинг. Разработчики стандарта видимо думали что публичных шлюзов будет больше, но увы. Никак. Вы ведь не проверяете доступность IPv4-адресов сайтов. Можно конечно написать statefull анализатор новых сессий, но кому это надо. Надеюсь Вам помогут эти ссылки [1], [2], [3].

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

Справа от кнопок "создать сообщение", "создать новую тему" есть белые невидимые ссылки "Ответить" и "Открыть тему". Браузер Opera.

Выше уже где-то говорилось, что все помеченные посты появятся в quote если нажать кнопку "ответить".