Там в другой ветке обсуждали NAT64, там по сути трансляция адресов уже есть из коробки. И префикс зарезервирован 64:ff9b::808:808 и ваше предложение по сути уже реализовано. Нужны только anycast nat64 раскиданные по миру.
Нет, не обслуживает. То что кто-то где-то сделал NAT64, это не заслуга VK. В чистой IPv6 сети VK недоступен.
ping 64:ff9b::57f0:8185
Обмен пакетами с 64:ff9b::57f0:8185 по с 32 байтами данных:
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
ping -6 google.com
Обмен пакетами с google.com [2a00:1450:4002:405::200e] с 32 байтами данных:
Ответ от 2a00:1450:4002:405::200e: время=68мс
Ответ от 2a00:1450:4002:405::200e: время=68мс
Ответ от 2a00:1450:4002:405::200e: время=66мс
Ответ от 2a00:1450:4002:405::200e: время=68мс
Я с таким же успехом могу придумать IPv100500, сделать DNS-сервер, который будет транслировать А записи в мою адресацию и NAT, который будет транслировать мои адреса в IPv4 и назад. Но это не означает, что VK вдруг стал работать по IPv100500
В данном случае нужны именно шашечки. Чтобы ipv6 стал 100% - все ресурсы в Интернет должны иметь нативные адреса, без извращений.
Это неправильный гуглоDNS. Это именно DNS64, который "придумывает" ipv6 адреса для ipv4-only хостов (т.е. если в оригинале AAAA записи нет). И без NAT64 оно бесполезно.
Нет. Это МТС превращает ваш IPv6 в IPv4 и засылает его в vk.com.
Upd: если есть аккаунт в ВК, зайдите https://id.vk.ru/account/#/devices, ткните "это устройство" и увидьте там ipv4 адрес в который натит МТС ваш трафик. Если бы ВК умело ipv6 нативно, то там был бы ipv6 адрес.
Это у вас какие-то костыли используются? Потому что у меня вот так:
$ ping -6 vk.com
При проверке связи не удалось обнаружить узел vk.com.
Проверьте имя узла и повторите попытку.
$ ping -4 vk.com
Обмен пакетами с vk.com [87.240.132.67] с 32 байтами данных:
Ответ от 87.240.132.67: число байт=32 время=25мс TTL=51
Ответ от 87.240.132.67: число байт=32 время=26мс TTL=51
Ответ от 87.240.132.67: число байт=32 время=25мс TTL=51
Ответ от 87.240.132.67: число байт=32 время=26мс TTL=51
Я тут ради интереса уже прикидывал. Сейчас распределяется блок 2000::/3. Если его весь оставить на земле, то для других планет остается всего-лишь 7 аналогичных блоков (а если выкинуть префикс E000::/3, в котором располагаются зарезервированные блоки, то всего 6). Так что если сорить адресами так же как на земле, то наша межзвездная цивилизация будет всего-то 7-8 планет. Мелковато)
upd: на солнечную систему должно хватить. А для межзвездной цивилизации придется новый протокол внедрять, на 256 бит адресного пространства.
Есть некоторые блоки адресов, которые вроде как можно использовать, но т.к. когда-то давно они были зарезервированы для определенных целей, некоторый старый софт с этими адресами может не работать.
А про то что некоторые блоки адресов нельзя передать на другой континент - чисто организационно-юридическая проблема, а не техническая. Технически нет никаких проблем анонсить любой валидный блок адресов от любой ASN
Провайдер должен дать Ipv6, больше у него никаких галочек и не должно быть.
Если использовать роутеры с прошивками 10-тилетней давности, то там да, с ipv6 всё плохо.
В keenetic с актуальной прошивкой (она есть даже для многих древних устройств) есть и поддержка ipv6 (причем с 5.х уже не модулем, а встроено наглухо), и файрвол закрытый по дефолту (можно отключить), и UPnP для торрента и даже можно разрешить входящий траф на определенный хост (но пока только через cli, возможно когда-нибудь и это в вебморду притащат).
Я знаю такой хостинг. Новая виртуалка имеет их ключик у рута. Но они об этом честно предупреждают и не возражают, если ты его уберешь (но тогда без их поддержки в случае чего)
Потребительское оборудование (роутеры) давно имеют штатный файрвол, закрывающий входящий трафик по дефолту. Обычному домашнему пользователю другое и не надо. Для всяких торрент-клиентов есть UPnP, который автоматически добавляет разрешающие правила в файрволе.
Другое дело, что провайдеров, предоставляющих IPv6 что-то не особо и видно. Некоторые крупные провайдеры в некоторых регионах может быть и дают IPv6, но всякая мелочевка - увы.
Аналогично у меня вопрос к хостерам и крупным контент-площадкам. Яндекс сам полностью доступен по IPv6, но в их же облаке IPv6 нет. Я сервис, живущий в яндекс-облаке, не могу выпустить в мир по IPv6. VK в принципе по IPv6 не доступен (что там в их облаке творится - не знаю, но думаю тоже ничего хорошего). Некоторые хостеры ipv6 только за деньги дают (алё, вам ipv6 адресов жалко?).
Короче типичная проблема курицы и яйца. И клиентское оборудование тут далеко не самая главная причина. Оно-то как раз и готово уже.
Думаете 8193.3512.34211.0.0.35374.880.29492 выглядит лучше и удобнее? Или 32.1.13.184.133.163.0.0.0.0.138.46.3.112.115.52 ? Для такого огромного адресного пространства любая запись выглядит ужасно.
IPv6 за 30 лет не смогли внедрить, а это поделие тоже 30 лет будут внедрять? При том оно не решает никаких проблем ipv4, кроме размера адресного пространства.
Там в другой ветке обсуждали NAT64, там по сути трансляция адресов уже есть из коробки. И префикс зарезервирован 64:ff9b::808:808 и ваше предложение по сути уже реализовано. Нужны только anycast nat64 раскиданные по миру.
Нет, не обслуживает. То что кто-то где-то сделал NAT64, это не заслуга VK. В чистой IPv6 сети VK недоступен.
Я с таким же успехом могу придумать IPv100500, сделать DNS-сервер, который будет транслировать А записи в мою адресацию и NAT, который будет транслировать мои адреса в IPv4 и назад. Но это не означает, что VK вдруг стал работать по IPv100500
В данном случае нужны именно шашечки. Чтобы ipv6 стал 100% - все ресурсы в Интернет должны иметь нативные адреса, без извращений.
Это неправильный гуглоDNS. Это именно DNS64, который "придумывает" ipv6 адреса для ipv4-only хостов (т.е. если в оригинале AAAA записи нет). И без NAT64 оно бесполезно.
Нет. Это МТС превращает ваш IPv6 в IPv4 и засылает его в vk.com.
Upd: если есть аккаунт в ВК, зайдите https://id.vk.ru/account/#/devices, ткните "это устройство" и увидьте там ipv4 адрес в который натит МТС ваш трафик. Если бы ВК умело ipv6 нативно, то там был бы ipv6 адрес.
А, ну тогда понятно, для сетей IPv6-only использование NAT64 для доступа в IPv4 сеть нормальное явление.
Те кому надо и так знают вплоть до квартиры. Остальным не надо)
Значит это костыли со стороны МТС (я считаю IPv4/IPv6 трансляцию костылями. Это не нативный ipv6, а именно временное решение на переходный период).
Я использую гугловые DNS, они не отдают AAAA-записи для vk.com
Это у вас какие-то костыли используются? Потому что у меня вот так:
Уже есть запись ::ffff:8.8.8.8 для совместимости. Достаточно узаконить её в виде настоящих адресов ::ffff:808:808
Я тут ради интереса уже прикидывал. Сейчас распределяется блок 2000::/3. Если его весь оставить на земле, то для других планет остается всего-лишь 7 аналогичных блоков (а если выкинуть префикс E000::/3, в котором располагаются зарезервированные блоки, то всего 6).
Так что если сорить адресами так же как на земле, то наша межзвездная цивилизация будет всего-то 7-8 планет. Мелковато)
upd: на солнечную систему должно хватить. А для межзвездной цивилизации придется новый протокол внедрять, на 256 бит адресного пространства.
Есть некоторые блоки адресов, которые вроде как можно использовать, но т.к. когда-то давно они были зарезервированы для определенных целей, некоторый старый софт с этими адресами может не работать.
А про то что некоторые блоки адресов нельзя передать на другой континент - чисто организационно-юридическая проблема, а не техническая. Технически нет никаких проблем анонсить любой валидный блок адресов от любой ASN
Я вам тоже не теми словами говорю? В СОВРЕМЕННОМ роутере входящие по IPv6 ЗАКРЫТЫ ПО ДЕФОЛТУ. Никакого доступа снаружи нет!
Роутер - любой кинетик с актуальной прошивкой.
То что NAT закрывает локальные устройства от внешнего доступа - это побочный эффект, который (при неправильной настройке NAT) можно обойти.
В современных бытовых роутерах с IPv6 файрвол включен по дефолту и пользователю не надо его включать.
Провайдер должен дать Ipv6, больше у него никаких галочек и не должно быть.
Если использовать роутеры с прошивками 10-тилетней давности, то там да, с ipv6 всё плохо.
В keenetic с актуальной прошивкой (она есть даже для многих древних устройств) есть и поддержка ipv6 (причем с 5.х уже не модулем, а встроено наглухо), и файрвол закрытый по дефолту (можно отключить), и UPnP для торрента и даже можно разрешить входящий траф на определенный хост (но пока только через cli, возможно когда-нибудь и это в вебморду притащат).
Я знаю такой хостинг. Новая виртуалка имеет их ключик у рута. Но они об этом честно предупреждают и не возражают, если ты его уберешь (но тогда без их поддержки в случае чего)
Потребительское оборудование (роутеры) давно имеют штатный файрвол, закрывающий входящий трафик по дефолту. Обычному домашнему пользователю другое и не надо. Для всяких торрент-клиентов есть UPnP, который автоматически добавляет разрешающие правила в файрволе.
Другое дело, что провайдеров, предоставляющих IPv6 что-то не особо и видно. Некоторые крупные провайдеры в некоторых регионах может быть и дают IPv6, но всякая мелочевка - увы.
Аналогично у меня вопрос к хостерам и крупным контент-площадкам. Яндекс сам полностью доступен по IPv6, но в их же облаке IPv6 нет. Я сервис, живущий в яндекс-облаке, не могу выпустить в мир по IPv6. VK в принципе по IPv6 не доступен (что там в их облаке творится - не знаю, но думаю тоже ничего хорошего). Некоторые хостеры ipv6 только за деньги дают (алё, вам ipv6 адресов жалко?).
Короче типичная проблема курицы и яйца. И клиентское оборудование тут далеко не самая главная причина. Оно-то как раз и готово уже.
Чтобы через дцать лет не наступать на те же грабли
Про JSON Web Token я что-то вообще не понял куда это и зачем
Думаете 8193.3512.34211.0.0.35374.880.29492 выглядит лучше и удобнее?
Или 32.1.13.184.133.163.0.0.0.0.138.46.3.112.115.52 ?
Для такого огромного адресного пространства любая запись выглядит ужасно.
IPv6 за 30 лет не смогли внедрить, а это поделие тоже 30 лет будут внедрять? При том оно не решает никаких проблем ipv4, кроме размера адресного пространства.