Ну т.е. уже начались костыли — перевод на самом деле не по номеру телефона, а по номер телефона+инициалы. Плюс переводить деньги, вообще говоря, можно не только человеку, но и организации — там с инициалами плохо.
Почему бы сразу устойчивый идентификатор не использовать?
так чтобы человек который переводит понимал что он не ошибся и деньги будут доставлены кому и планировалось.
Проблема только в том, что в номере телефона нет контрольной суммы. И человек не понимает, что не ошибся в наборе.
А если телефон выбирается из контактов и ничего набирать на надо — то точно так же не надо набирать номер банковского счета для получения денег, который может в контакте лежать.
Чип есть не у всех, вы смотрите на РФ которая очень даже продвинутая, а вот например в США большая часть банкоматов читает только магнитную полосу…
Даже в США уже несколько лет идет EMV liability shift. И банк, который не поменял банкомат на тот, который умеет читать чип, по сути, согласился вернуть деньги на чипованную карточку буквально по первому слову пользователя этой карточки.
Поэтому в процессе было очень смешно. Банкам хотелось и безопасность повысить и сделать так, чтобы карты с чипом не распространялись слишком быстро. В прессе были статьи о том, что карточка с чипом карта — это безопаснее. И одновременно же — что запоминать PIN — это страшно неудобно, сложно и старый способ с полосой был лучше. После чего внедрялись терминалы, где надо расписываться стилом. где-то так(Youtube). После чего продавцы жаловались, что, чипованные карты скорость прохождения очереди замедляют.
К сожалению, бумажное устройство стремительно устаревает. Я так понимаю, что изготовление подделки, которую нельзя распознать без сложного оборудования — стало очень простым.
Но я не очень поддерживаю идею единого, на все случаи годного паспорта-карточки. Слишком много прав в одном устройстве концентрируется и единая точка отказа создается. Вот тут объяснял, как это с моей дочки зрения должно выглядеть.
Ну и еще неплохо то из них, в котором официальная ЭЦП хранится, выполнять не в виде карточки, а с корпусом, служащим штампом личной печати (например, в таком, как у японцев это выглядит). И электронику для сканнеров биометрии есть куда поместить, и защищенности (скажем, пожароустойчивость) можно добавить, выбрав правильный материал, и использовать можно на бумажных документах в дополнении к подписи. И, самое главное — солидность-официальность придает. А то у нас большая часть людей так до сих пор и не понимает, как этой ЭЦП обращаться надо. Может, если это будет в форм-факторе "большая круглая печать" — дойдет.
Не совсем. Если купить телефон и поломать у него все интерфейсы (беспроводные и, по возможности, проводные) — то следить за актуальностью софта нужно гораздо меньше.
Собственно, вся идея не лишена смысла, если бы применялся не телефон, а специально разработанное (пусть и на базе телефонов) под это дело устройство.
Так не надо ничего постоянно синхронизировать. Та подсеть, которая вам выдана (еще раз — это не то, что на внешнем интерфейсе) выдается практически навечно и не меняется. Соответственно, поднимаешь сервис, выбираешь для него IP из сервисной сети. Прописываешь IP в DNS и больше оно никогда не меняется.
Работает это все дорожно приблизительно так:
На внешнем интерфейсе маршрутизатора провайдер дает, скажем
2001:db8:0:0:aaaa:bbbb:cccc:dddd (любым способом). Этот адрес никого не интересует и может быть более-менее произвольно провайдером меняться
Одновременно он выдает клиенту 2001:0db8:0000:ee00::/56 и маршрутизирует ее на этот адрес.
Клиент берет одну из /64 (например, 2001:0db8:0000:ee10::/64) в качестве адресов внутреннего сегмента для своих устройств — из нее адреса устройства будут автоматически получать. Если не страдать паранойей — всегда одни и те же, т.к. по MAC адресу генерироваться будут.
Еще одну сетку /64 (например, 2001:0db8:0000:ee11::/64) выбираем для для адресов сервисов.
Теперь что делаем, когда поднимаем сервис:
Есть у нас устройство, где сервис хотим поднять с адресом 2001:0db8:0000:ee10:1234:5678:9abc:def1 — это адрес постоянный внутри сегмента
Выбираем адрес из сервисной сети (2001:0db8:0000:ee11:2345:6789:abcd:ef01/128), вешаем его статиком на интерфейсе того устройства, где сервис живет (т.е рядом с 2001:0db8:0000:ee10:1234:5678:9abc:def1).
Прописываем 2001:0db8:0000:ee11:2345:6789:abcd:ef01 в DNS в виде servicename.mydomain.home
На маршрутизаторе прописываем маршрут 2001:0db8:0000:ee11:2345:6789:abcd:ef01 via 2001:0db8:0000:ee10:1234:5678:9abc:def1 и открываем нужные порты
Все.
Когда хотим сервис на другую железку перенести — переносим 2001:0db8:0000:ee11:2345:6789:abcd:ef01/128 уже на нее и меняем маршрут.
Уже писал тут где-то рядом. Тот адрес, который внешний на маршрутизаторе — он в случае с IPv6 вообще не должен для сервисов использоваться. Сервисы вешаются в отдельную подсетку, которая вырезается из тех адресов, что абоненту выданы. И это подсетка — она не из /64 с внешнего интерфейса.
Просто вот это желание использовать "внешний адрес" — это привычка от IPv4, когда адресов абоненту мало давали.
Ну, технически, это все-таки будет NAT-ом (адреса в пакетах меняются все-таки). Просто не таким сложным, как в случае с IPv4. А просто и тупо заменяем один адрес на другой и отправляем дальше, не занимаясь разными connection tracking.
Хотя лучше бы взять одну из подсеток из твоей /56, /48 специально для адресов публичных сервисов, назначать адреса из нее на том хосте, где сервис живет. А на маршрутизаторе прописывать маршрут "этот адрес — вон на том сервере".
Насколько я понимаю, одна из идей IPv6 — что, наоборот, каждый сервис можно не только на отдельный порт повесить, но и на свой отдельный адрес. Даже если физически они на одной машине. Так что желание "чтобы выглядело как один сервер" не очень понятно.
Итого, большая часть проблем — что выдается всего один /64. Что, как верно указано, совершенно не так, как было задумано.
Но происходит все от недоработки тех самой Legacy обвязки железок у провайдера. Как я понимаю, это должно работать так:
Тот /64, что на внешнем интерфейсе — Stateless и вообще никого не интересует, кроме провайдера, может более-менее произвольно меняться, скажем, при переконфигурации сети и вообще не должен использоваться в качестве адреса для входящих соединений.
Одновременно с этим, в тот момент, когда он выдается на интерфейс, на него маршрутизируется какая-то постоянная /48 (ну ладно /56, если очень адресов жалко). Которая и используется клиентом как ему хочется. И где живут все железки и сервисы, которые, собственно, интернет хотят. Причем эту /48 можно прибить гвоздями к конкретному клиенту навечно и он ее будет сохранять при переездах в рамках одного оператора.
Но вот всего, что выше — софт операторов просто не умеет и дописывать его никто не будет.
Кто в принципе, кроме рынка, может обязать производителей сделать по-человечески?
Производители, в общем, в свое время практически подтянулись. Но выяснилось, что возиться с IPv6 не хотят операторы. И производители домашних железок на это дело плюнули.
Обратная совместимость и legacy бывает не только по железкам, которые заменили для того, чтобы справится с трафиком. Но и у того, что вокруг железок. Если биллингу оператора каким-нибудь образом сносит крышу от IPv6 трафика, то оператор его включать не будет, даже если все железки уже его умеют.
Рутер, который способен делать stateful connection tracking (а NAT без этого не работает), совершенно спокойно потянет совершенно тупой практически не-stateful файрволл для IPv6 вида "наружу пропускаем все, а внутрь — только пакеты с установленным флажком установленного соединения.
Так что там, где у IPv4-го маршрутизатора по умолчанию NAT без настроек, у IPv6 по умолчанию односторонний файрволл тоже без настроек.
Эквивалентом прокидывания порта внутрь (как с NAT делать иногда надо) будет просто открытие порта на вход.
Интерфейс с точки зрения пользователя может быть совершенно идентичным.
Ситуация же ничем не отличается от ситуации в тех местах, где банковские карты традиционно именно кредитные и оплата происходит в долг? Человек как-то потратил те деньги, которых у него нет, продавец свои деньги получил. А потом уже банк, когда до него все платежки дойдут, разбирается с тем, чтобы все долги взять.
Много лет так живут, все системы на подобное заточены, так что не вижу проблемы.
У человека тоже алгоритмы распознавания и обученная нейронка. Но таблички ставят.
Соответственно и тут — с машинно-читабельными 'табличками' система вполне может лучше работать и реже ошибаться.
Поскольку есть радар, то можно, наверное, не оптические QR коды, а какие-нибудь пассивные (или даже активные — электричества рядом есть) метки для радара.
Если я правильно понимаю, то по номеру карты в другой банк — идут через карточную платежную систему. Потому что банки не хотят и не имею права сообщить друг другу соответствие "номер карты <-> номер банковского счета", и поэтому не могут сделать перевод мимо нее. Тот случай, когда "защита персональных данных" работает против удобства.
А перевод по номеру телефона — идет через эту эту самую новую "Систему быстрых платежей". Про которую и были требования ЦБ.
Пример:
Берем данные отсюда, центробанк россии
"Операции, совершенные на территории России с использованием карт, эмитированных российскими кредитными организациями"
За 2019 год:
Количество операций: 41677.7 млн единиц
Объем операций: 90932.4 млрд рублей
Если считать по "0.5% от суммы перевода" — то платежной системе достанется 454.622 млдр рублей
Ту же сумму по фиксированной плате получаем при чуть больше 10 рублей за платеж. За хлеб/мороженное уже задумаешься, стоит ли платить.
Ну т.е. уже начались костыли — перевод на самом деле не по номеру телефона, а по номер телефона+инициалы. Плюс переводить деньги, вообще говоря, можно не только человеку, но и организации — там с инициалами плохо.
Почему бы сразу устойчивый идентификатор не использовать?
Проблема только в том, что в номере телефона нет контрольной суммы. И человек не понимает, что не ошибся в наборе.
А если телефон выбирается из контактов и ничего набирать на надо — то точно так же не надо набирать номер банковского счета для получения денег, который может в контакте лежать.
Даже в США уже несколько лет идет EMV liability shift. И банк, который не поменял банкомат на тот, который умеет читать чип, по сути, согласился вернуть деньги на чипованную карточку буквально по первому слову пользователя этой карточки.
Поэтому в процессе было очень смешно. Банкам хотелось и безопасность повысить и сделать так, чтобы карты с чипом не распространялись слишком быстро. В прессе были статьи о том, что карточка с чипом карта — это безопаснее. И одновременно же — что запоминать PIN — это страшно неудобно, сложно и старый способ с полосой был лучше. После чего внедрялись терминалы, где надо расписываться стилом. где-то так(Youtube). После чего продавцы жаловались, что, чипованные карты скорость прохождения очереди замедляют.
К сожалению, бумажное устройство стремительно устаревает. Я так понимаю, что изготовление подделки, которую нельзя распознать без сложного оборудования — стало очень простым.
Но я не очень поддерживаю идею единого, на все случаи годного паспорта-карточки. Слишком много прав в одном устройстве концентрируется и единая точка отказа создается. Вот тут объяснял, как это с моей дочки зрения должно выглядеть.
Ну и еще неплохо то из них, в котором официальная ЭЦП хранится, выполнять не в виде карточки, а с корпусом, служащим штампом личной печати (например, в таком, как у японцев это выглядит). И электронику для сканнеров биометрии есть куда поместить, и защищенности (скажем, пожароустойчивость) можно добавить, выбрав правильный материал, и использовать можно на бумажных документах в дополнении к подписи. И, самое главное — солидность-официальность придает. А то у нас большая часть людей так до сих пор и не понимает, как этой ЭЦП обращаться надо. Может, если это будет в форм-факторе "большая круглая печать" — дойдет.
Не совсем. Если купить телефон и поломать у него все интерфейсы (беспроводные и, по возможности, проводные) — то следить за актуальностью софта нужно гораздо меньше.
Собственно, вся идея не лишена смысла, если бы применялся не телефон, а специально разработанное (пусть и на базе телефонов) под это дело устройство.
При должной автоматизации точка синхронизации одна — адрес, записанный в DNS. А в остальных местах он может проставляться по читаемому имени.
Сценарий с резервным каналом — надо смотреть, как адреса назначаются в том префиксе, что провайдер отдал.
Если руками — то у сервисных сеток и адресов у сервиса будет по две штуки. Из адресов одного провайдера и из адресов другого.
Так не надо ничего постоянно синхронизировать. Та подсеть, которая вам выдана (еще раз — это не то, что на внешнем интерфейсе) выдается практически навечно и не меняется. Соответственно, поднимаешь сервис, выбираешь для него IP из сервисной сети. Прописываешь IP в DNS и больше оно никогда не меняется.
Работает это все дорожно приблизительно так:
На внешнем интерфейсе маршрутизатора провайдер дает, скажем
2001:db8:0:0:aaaa:bbbb:cccc:dddd (любым способом). Этот адрес никого не интересует и может быть более-менее произвольно провайдером меняться
Одновременно он выдает клиенту 2001:0db8:0000:ee00::/56 и маршрутизирует ее на этот адрес.
Клиент берет одну из /64 (например, 2001:0db8:0000:ee10::/64) в качестве адресов внутреннего сегмента для своих устройств — из нее адреса устройства будут автоматически получать. Если не страдать паранойей — всегда одни и те же, т.к. по MAC адресу генерироваться будут.
Еще одну сетку /64 (например, 2001:0db8:0000:ee11::/64) выбираем для для адресов сервисов.
Теперь что делаем, когда поднимаем сервис:
Есть у нас устройство, где сервис хотим поднять с адресом 2001:0db8:0000:ee10:1234:5678:9abc:def1 — это адрес постоянный внутри сегмента
Выбираем адрес из сервисной сети (2001:0db8:0000:ee11:2345:6789:abcd:ef01/128), вешаем его статиком на интерфейсе того устройства, где сервис живет (т.е рядом с 2001:0db8:0000:ee10:1234:5678:9abc:def1).
Прописываем 2001:0db8:0000:ee11:2345:6789:abcd:ef01 в DNS в виде servicename.mydomain.home
На маршрутизаторе прописываем маршрут 2001:0db8:0000:ee11:2345:6789:abcd:ef01 via 2001:0db8:0000:ee10:1234:5678:9abc:def1 и открываем нужные порты
Все.
Когда хотим сервис на другую железку перенести — переносим 2001:0db8:0000:ee11:2345:6789:abcd:ef01/128 уже на нее и меняем маршрут.
Уже писал тут где-то рядом. Тот адрес, который внешний на маршрутизаторе — он в случае с IPv6 вообще не должен для сервисов использоваться. Сервисы вешаются в отдельную подсетку, которая вырезается из тех адресов, что абоненту выданы. И это подсетка — она не из /64 с внешнего интерфейса.
Просто вот это желание использовать "внешний адрес" — это привычка от IPv4, когда адресов абоненту мало давали.
Ну, технически, это все-таки будет NAT-ом (адреса в пакетах меняются все-таки). Просто не таким сложным, как в случае с IPv4. А просто и тупо заменяем один адрес на другой и отправляем дальше, не занимаясь разными connection tracking.
Хотя лучше бы взять одну из подсеток из твоей /56, /48 специально для адресов публичных сервисов, назначать адреса из нее на том хосте, где сервис живет. А на маршрутизаторе прописывать маршрут "этот адрес — вон на том сервере".
Насколько я понимаю, одна из идей IPv6 — что, наоборот, каждый сервис можно не только на отдельный порт повесить, но и на свой отдельный адрес. Даже если физически они на одной машине. Так что желание "чтобы выглядело как один сервер" не очень понятно.
Итого, большая часть проблем — что выдается всего один /64. Что, как верно указано, совершенно не так, как было задумано.
Но происходит все от недоработки тех самой Legacy обвязки железок у провайдера. Как я понимаю, это должно работать так:
Тот /64, что на внешнем интерфейсе — Stateless и вообще никого не интересует, кроме провайдера, может более-менее произвольно меняться, скажем, при переконфигурации сети и вообще не должен использоваться в качестве адреса для входящих соединений.
Одновременно с этим, в тот момент, когда он выдается на интерфейс, на него маршрутизируется какая-то постоянная /48 (ну ладно /56, если очень адресов жалко). Которая и используется клиентом как ему хочется. И где живут все железки и сервисы, которые, собственно, интернет хотят. Причем эту /48 можно прибить гвоздями к конкретному клиенту навечно и он ее будет сохранять при переездах в рамках одного оператора.
Но вот всего, что выше — софт операторов просто не умеет и дописывать его никто не будет.
Производители, в общем, в свое время практически подтянулись. Но выяснилось, что возиться с IPv6 не хотят операторы. И производители домашних железок на это дело плюнули.
Обратная совместимость и legacy бывает не только по железкам, которые заменили для того, чтобы справится с трафиком. Но и у того, что вокруг железок. Если биллингу оператора каким-нибудь образом сносит крышу от IPv6 трафика, то оператор его включать не будет, даже если все железки уже его умеют.
Рутер, который способен делать stateful connection tracking (а NAT без этого не работает), совершенно спокойно потянет совершенно тупой практически не-stateful файрволл для IPv6 вида "наружу пропускаем все, а внутрь — только пакеты с установленным флажком установленного соединения.
Так что там, где у IPv4-го маршрутизатора по умолчанию NAT без настроек, у IPv6 по умолчанию односторонний файрволл тоже без настроек.
Эквивалентом прокидывания порта внутрь (как с NAT делать иногда надо) будет просто открытие порта на вход.
Интерфейс с точки зрения пользователя может быть совершенно идентичным.
Не понял, почему это проблема.
Ситуация же ничем не отличается от ситуации в тех местах, где банковские карты традиционно именно кредитные и оплата происходит в долг? Человек как-то потратил те деньги, которых у него нет, продавец свои деньги получил. А потом уже банк, когда до него все платежки дойдут, разбирается с тем, чтобы все долги взять.
Много лет так живут, все системы на подобное заточены, так что не вижу проблемы.
У человека тоже алгоритмы распознавания и обученная нейронка. Но таблички ставят.
Соответственно и тут — с машинно-читабельными 'табличками' система вполне может лучше работать и реже ошибаться.
Метка в данном случае имеется в виду — с хорошо читаемым номером или другой короткой информацией. Машинно-читаемый аналог таблички с буквами.
Поскольку есть радар, то можно, наверное, не оптические QR коды, а какие-нибудь пассивные (или даже активные — электричества рядом есть) метки для радара.
Если я правильно понимаю, то по номеру карты в другой банк — идут через карточную платежную систему. Потому что банки не хотят и не имею права сообщить друг другу соответствие "номер карты <-> номер банковского счета", и поэтому не могут сделать перевод мимо нее. Тот случай, когда "защита персональных данных" работает против удобства.
А перевод по номеру телефона — идет через эту эту самую новую "Систему быстрых платежей". Про которую и были требования ЦБ.
Пример:
Берем данные отсюда, центробанк россии
"Операции, совершенные на территории России с использованием карт, эмитированных российскими кредитными организациями"
За 2019 год:
Количество операций: 41677.7 млн единиц
Объем операций: 90932.4 млрд рублей
Если считать по "0.5% от суммы перевода" — то платежной системе достанется 454.622 млдр рублей
Ту же сумму по фиксированной плате получаем при чуть больше 10 рублей за платеж. За хлеб/мороженное уже задумаешься, стоит ли платить.