Pull to refresh
0
0
Send message
То что вам по звонку в банк отменили авторизацию операции вовсе не означает, что при наступлении расчетов по операции эту сумму не удержат с вашего счета.
Похоже кто-то лишнего сболтнул…
Я имел ввиду как раз НЕ DCC.
Тот же, например, Аванград с VISA уже достаточно давно перешел на следующую схему расчетов:
Покупка в долларах — клиринг в долларах, покупка в евро — клиринг в евро, покупка в другой валюте — клиринг в рублях по курсу МПС.
Получается чуть-чуть выгоднее за счет отсутствия цепочки конвертации, например йены в доллары (в МПС), а потом долларов в рубли (в банке, если карта рублевая).
Зависит от вашего банка.

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы поймите одну простую истину — я исхожу не из того, как это описано в RFC и продумано умными и не очень людьми, а из наших, в частности Российских, реалий, как бы это ни было грустно.
По-моему вы вполне сами себе на вопрос и ответили, разве нет?
Если нет, то в случае IPv4 это банальный extended ACL, а во втором это уже залезание внутрь пакета, что умеют далеко не все коммутаторы.
Поделитесь секретом, кто (и на основании чего) принимает решение о выдаче абоненту блока 2002:b00e:d4f2:1::/64, как это описано в вашем случае.
1

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity