• Банковская карта от «МегаФона»
    0
    То что вам по звонку в банк отменили авторизацию операции вовсе не означает, что при наступлении расчетов по операции эту сумму не удержат с вашего счета.
  • Payler: обновление сертификации PCI DSS до версии 3.0 — DONE
    +3
    Похоже кто-то лишнего сболтнул…
  • Путешествия банковской транзакции
    +1
    Я имел ввиду как раз НЕ DCC.
    Тот же, например, Аванград с VISA уже достаточно давно перешел на следующую схему расчетов:
    Покупка в долларах — клиринг в долларах, покупка в евро — клиринг в евро, покупка в другой валюте — клиринг в рублях по курсу МПС.
    Получается чуть-чуть выгоднее за счет отсутствия цепочки конвертации, например йены в доллары (в МПС), а потом долларов в рубли (в банке, если карта рублевая).
  • Путешествия банковской транзакции
    0
    Зависит от вашего банка.

    Например если у вас карточка банка Авангард, то VISA сконвертирует йены сразу в рубли по своему курсу и выставит уже в рублях Авангарду, который спишет с вас эту сумму в рублях, ну и еще добавит 0.75% комиссии за трансграничную операцию.
  • Путешествия банковской транзакции
    0
    Само собой, все такие расчёты осуществляются в долларах

    VISA уже давным давно замечательно проводит расчеты с банками и в долларах и в евро и даже в рублях.
  • Практика IPv6 — домашняя сеть
    +1
    Нормальный роутер, IPv6 на нем работает вполне достойно.
  • Практика IPv6 — домашняя сеть
    0
    Я не пробовал и более того не уверен, что схема с HE сработает с home роутером/микротиком.
    Мне повезло больше — я пнул аплинков и они мне выдали IPv6 BGP связность в реальные сроки.
    В остальном, повторюсь, на туннелях живут операторы, которым интересен IPv6. Уж не знаю насколько они довольны явно более высоким задержкам, но при отсутствии альтернатив…
  • Практика IPv6 — домашняя сеть
    +1
    Как ни банально, но он не умеет так делать.

    Надо понимать, что оператору УДОБНО, когда абонент получает все по DHCPv6.

    P.S. И не надо рассказывать, что оператор должен делать так как удобно абоненту — это утопия, такого нет, не было и не будет.

    P.S.2 Схема с DHCPv6 работает практически идеально, зачем выдумывать разные странные схемы для достижения ТОГО же результата?
  • Практика IPv6 — домашняя сеть
    +1
    Никто, это всецело на совести тех, кто пишет софт для абонентских роутеров.
  • Практика IPv6 — домашняя сеть
    +1
    Отнюдь, ряд ОПЕРАТОРОВ (надо понимать, что речь про далекие регионы необъятной), аплинки которых не готовы к поднятию IPv6 BGP сессий, поступают именно так.
  • Практика IPv6 — домашняя сеть
    0
    Не табличка, а сплошная жуть. Было бы полезно еще указывать в ней последний примененный патч к ОС, ибо там тоже встречаются изменения.

    Что касается провайдера-нищеброда, то писать в логи все связанное с RA не столь простая задача, как это выглядит если эту фразу написать на хабре, увы. Вы думаете на доступе у всех, тем более нищебродов-провайдеров, стоят коммутаторы которые знают что такое IPv6? Так вы глубочайшим образом заблуждаетесь.
    Если речь идет о фиксировании всех IPv6 соседей на ближайшем IPv6 роутере оператора, то да, технически возможно, но это геморрой. Проще отказать абоненту в такой шалости, не выпустив его в «мир».
  • Практика IPv6 — домашняя сеть
    +1
    Попробуйте вариант с туннелем до he, статический паблик при таком раскладе не нужен.
  • Практика IPv6 — домашняя сеть
    +3
    Не я показал конечно

    Пардон, я все еще пытаюсь привыкнуть к возможности писать на хабре, а не только читать :)

    Основная идея в том, что операторский маршрутизатор при всем желании не должен являться DNS сервером, это, как минимум не его задача. То, что видно в дампе пакета существует только в связке абонентский роутер -> абонентский компьютер. В связке абонентский роутер -> операторский роутер такая схема не взлетит.

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

    P.S. Я, похоже, догадываюсь в чем возникает общее противоречие между моими постами и постами других участников обсуждения — все рассматривают IPv6 со стороны абонента, я же, напротив, со стороны оператора.
  • Практика IPv6 — домашняя сеть
    0
    Мы с вами друг друга пока не поняли.
    Кто принял решение выдать именно этот блок, кто сгенерировал именно такой пакет, дамп которого вы показали?
  • Практика IPv6 — домашняя сеть
    +1
    Рассматриваем ситуацию, когда абонентский компьютер подключен напрямую к сети оператора без абонентского роутера.
    Если есть абонентский роутер, то все выше и нижеописанное не имеет ровно никакого значения.
    Так вот, если абонентский компьютер игнорирует флаги обозначающие, что настройки нужно получать по DHCPv6, то он получит свой адрес по SLAAC из prefix-advertisement блока оператора, при этом винда при включенном (by default) temporarily ipv6 address получит еще один (второй) ipv6 адрес и все соединения будет выполнять от его «имени».

    Так вот, мы получим абонента, выходящего в сеть интернет каждый раз с нового в6 адреса. Мы будем вынуждены каждый раз запоминать с какого адреса он вышел (т.е. идентифицировать его с полученным временным в6 адресом) чтобы в случае получения запроса от органов «какой абонент выходил в сеть Интернет такого-то числа с такого-то в6 адреса» мы могли ответить не «а пес его знает», а выдать конкретный ответ.
  • Практика IPv6 — домашняя сеть
    0
    Да нет, не промахнулся.
    То, что они не обязаны, вовсе не означает, что такая схема взлетит в реальной сети.
    И, кстати говоря, в реальной сети взлетает ровно так как выставлены флаги.

    P.S. Выше я описал, что будет если игнорировать флаги.
  • Практика IPv6 — домашняя сеть
    +1
    Тем, что большинство коммутаторов умеют делать ACL только на L4 уровне. То, что о чем мы с вами говорим, уже совсем не L4.

    В терминологии DLink это, вроде как, PCL — packet content layer.
  • Практика IPv6 — домашняя сеть
    0
    Так кто ж против, получил себе «левый» ipv6 адрес из shared блока типа temporarily ipv6 address в винде — сиди в локалке, в мир с него не пустим. Учитывая, что он при каждом чихе меняется на новый, возникает слишком много головной боли ради всяких сормов и прочих любителей поприсылать запросы, их постоянно фиксировать и сохранять.

    Вы поймите одну простую истину — я исхожу не из того, как это описано в RFC и продумано умными и не очень людьми, а из наших, в частности Российских, реалий, как бы это ни было грустно.
  • Практика IPv6 — домашняя сеть
    0
    По-моему вы вполне сами себе на вопрос и ответили, разве нет?
    Если нет, то в случае IPv4 это банальный extended ACL, а во втором это уже залезание внутрь пакета, что умеют далеко не все коммутаторы.
  • Практика IPv6 — домашняя сеть
    0
    Поделитесь секретом, кто (и на основании чего) принимает решение о выдаче абоненту блока 2002:b00e:d4f2:1::/64, как это описано в вашем случае.
  • Практика IPv6 — домашняя сеть
    0
    Ой ли…
    Не поверите, но большинство абонентских роутеров вообще ни разу не ожидает увидеть в качестве полученного PD что-то отличное от /64. А причина очень проста — они едва ли научились вообще с IPv6 работать и в сорцах в большинстве случаев чуть ли не константами прописаны размерности сетей равные 64. Надо отдать должное, IPv6, как и годами раньше, это, увы, до сих пор всего лишь игрушка, а не стабильно работающий «инструмент».
  • Практика IPv6 — домашняя сеть
    +1
    Потому что заблочить входящие с абонентского порта IPv4 пакеты с source портом 67 всяко проще, чем разбирать IPv6 RA в поисках что ж там абонентский роутер решил наанонсить «в мир», да еще и мультикастом в придачу.
  • Практика IPv6 — домашняя сеть
    +1
    Stateless DHCP — это тот же DHCP, хотя покороче. Данные из RA могут учитываться, а могут и не учитываться. Тут разные системы ведут себя по-разному.

    По хорошему, они должны себя вести ровно так как установлены биты/флаги в RA сообщениях.
    А именно managed-config-flag и other-config-flag.
    Один отвечает за то, что адрес таки нужно получать не из prefix announcement, иными слова не stateless, а statefull, а другой, что еще пачку параметров можно/нужно получить по dhcp6, будь то DNS сервера, как пример.
  • Практика IPv6 — домашняя сеть
    0
    RIPE советует, вообще, пользователям /56 давать.

    Это все, безусловно, замечательно, однако основной идеей RIPE при выдаче такого блока было, что этот /56 будет поделен на внушительную пачку /64, каждая из которых будет жить своей жизнью из серии, одна /64 это своя сетка, вторая гостевая, третья еще как-нить, например, техническая и так далее; зачем под это отдали так много — лично я не понимаю.
    По факту я вижу то, что абонентские роутеры едва ли в состоянии справиться с единичной /64 и меня терзают смутные сомнения, что им не поплохеет, если они получат вместо ожидаемых /64 вдруг /56.
  • Практика IPv6 — домашняя сеть
    +1
    В целом, нынче IPv6 FullView это чуть меньше 15К префиксов (против 477К в ipv4). По моим наблюдениям, рост крайне слабый.
    Надо отдать должное, что варианты когда один и тот же оператор анонсирует более одного v6 префикса сейчас практически не наблюдаются, что позволяет держать рост таблицы минимальным.
  • Практика IPv6 — домашняя сеть
    +3
    Роутер DUID не запоминает, я склонен считать, что он вообще не знает что это такое :)
    DUID нужен только вашему dhcpv6 клиенту чтобы как-то идентифицироваться и нашему dhcpv6 серверу чтобы вас идентифицировать. Наш dhcpv6 сервер по вашему DUID понимает про кого именно идет речь и отправляет dhcpv6 reply в сторону нашего маршрутизатора. Наш маршрутизатор ловит ответ смотрит что там решили выдать абоненту и создает динамический раут, после чего отправляет ответ уже вашему dhcpv6 клиенту.

    Так как на нашем dhcpv6 сервере четко указан выданный вам блок, то он будет всегда одним и тем же.
    Полученную /64 сетку вы мучаете как вам угодно, но лишь в пределах вашего роутера, на который мы ее смаршрутизировали.

    Прибитая гвоздями схема лишь от части будет работать с попытками поднять динамическую маршрутизацию, однако если реальный Ipv6 адрес с внешнего интерфейса вашего роутера принудительно не убирать, то ничего не сломается.
  • Практика IPv6 — домашняя сеть
    +3
    В идеальной схеме отдельно выдаваемый адрес роутеру вообще не нужен и является откровенно лишним. Со стороны провайдера так или иначе блок должен маршрутизироваться на fe80 адрес роутера.
    Частные случаи, когда мы выдаем отдельный адрес роутеру, связаны с абонентскими роутерами, которые не в состоянии отправлять исходящие в мир запросы с адреса, назначенного внутреннему интерфейсу (т.е. с адреса выданного блока).
  • Практика IPv6 — домашняя сеть
    +3
    Правильное решение это dhcpv6 клиент с вашей стороны.
    В нем все просто — говорим, чтобы запрашивал блок. Дальше по связке он сам рисует конфиг для radvd на основе полученных адресов.
    При этом со стороны оператора это выглядит как dhcpv6 request с DHCPv6 DUID по которому в конечном счете мы и авторизуем абонента, наш маршрутизатор релеет ваш запрос на наш dhcpv6 сервер, сервер отвечает релею, релей (маршрутизатор) создает динамический IPv6 route, выданного абоненту блока, на IPv6 адрес (причем это будет как раз fe80 адрес) и направляет ответ уже роутеру абонента.
    Это идеальная схема, которая работает у нас для 99% абонентов так или иначе захотевших IPv6.

    Что касается конфига — тут все сильно индивидуально для каждого вендора абонентского роутера. Начиная с того, что у кого-то это isc-dhcp, а у кого-то wide-dhcp.
  • Практика IPv6 — домашняя сеть
    0
    Увы ничего не мешает и такие ситуации встречаются относительно часто. Бороться можно лишь в случае когда на доступе стоит коммутатор умеющий фильтровать неугодные (заведомо нелегитимные) RA.
  • Практика IPv6 — домашняя сеть
    +2
    Надо еще заметить, что RIPE выдает /32 не подряд, а с приличными «пробелами» позволяя позже лишь по запросу оператора именно расширить выданный блок аж до /29. Причем в последних письмах они делают упор, что сделают это с удовольствием, без лишней переписки, по первому же запросу оператора/LIRа.
  • Практика IPv6 — домашняя сеть
    +4
    Ваш случай, признаюсь, наиболее непопулярный и наименее удобный для меня, как оператора. С вашей стороны получилось все в целом просто и ненавязчиво, с моей же стороны мне пришлось нарисовать пачку костылей чтобы системы контроля конфигов маршрутизаторов не трогали статический IPv6 раут выданного вам блока на ваш роутер ибо все остальное работает действительно автоматически, как у вас :)

    Я давно вынашиваю идею либо выступить с лекцией по опыту внедрению IPv6 на одной из распространенных российский телеком пьянок, и/или написать статью на хабре, чтобы показать как все это выглядит со стороны оператора и какие реальные масштабные проблемы создают неудачное исполнение IPv6 на абонентских роутерах.