Comments 108
сеть получает единую управляемую платформу
... размещённую на территории Российской федерации (с).
Может цена на статистику IP будет дешевле, было бы хорошо
начнем платить за nat
В IPv6 согласно bcom-690 провайдеры должны выдавать клиентам стабильный префикс /48, ну или /56, если они хотят разделить бизнес и домашних пользователей. Выдача динамического префикса по сути нарушение этих рекомендаций. Тот же Ростелеком их нарушает.
У местного провайдера вообще выдается статика - /64 для маршрутизатора, и 15 сетей по /64 для локалки. Зато, какой-никакой IPv6.
Если судить по https://version6.ru/isp то в РФ рекомендации по /56 выполняют очень немногие
...There is a specific case for cellular phones to be assigned a single /64 per each PDP context, but this is out of the scope of this document...
Ростелеком уже несколько лет прекрасно отдаёт /56. Нужно только правильно «попросить».
Это чья то глупая шутка. Такой протокол будет совместим только сам с собой. Никакой обратной совместимости не будет. Нереализуемо.
В заголовке IP помимо обязательных для IP4 первых 20байт есть ещё options размером до 40байт. Поэтому можно оставить ip4 как есть и запихать старшие байты адреса в options. C сохранением нормального функционирования ip4 внутри ip8.
Однако они и тут умудрились обосраться
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ASN Prefix (r.r.r.r) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Host Address (n.n.n.n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ASN Prefix (r.r.r.r) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Host Address (n.n.n.n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Вместо заголовка, совместимого с ip4 чтобы этот ASN prefix попадал в options.
Source Host Address (n.n.n.n)
Destination Host Address (n.n.n.n)
Source ASN Prefix (r.r.r.r)
Destination ASN Prefix (r.r.r.r)
сказочные создания
Строго говоря, это Вы зря. Если Version == 8, то имитация IPv4 Options не требуется. Зачем тратить 2+2 байта впустую?
Ну как бы да, не требуется, но зачем специально ломать эту остаточную частичную совместимость v8->v4 когда пакет с 0.0.0.0.192.168.1.1 всё же мог бы нормально восприняться старым оборудованием если ему только поле версии у протокола поменять.
Про зря потраченные байты - не понял. вроде всё как есть только в другом порядке, единственное что адрес собирать по кускам придётся.
Если мы делаем честное "туннелирование" 8to4, то в после IPv4 заголовка (Version == 4), мы должны дать идентификатор опции и её длину - 2 байта, потом тело опции, ну и плюс 2 байта выравнивания. И тогда пакет будет восприниматься старым оборудованием, если оно не DPI. Итого: 4 дополнительных байта.
Если Version == 8, то вопрос философский.
А зачем оставлять старое оборудование в стеке оператора? Этот переход задуман исправить все недочеты глобальной связи, а не только лишь отдельных отшельников.
Ну да, отшельник будет мучатся, а мы заменим оборудование, лишь бы избавиться от всего этого бардака.
Тут усе в плюсе. Производители железа, пользователи. А операторы свои деньги отобьют. А девопсу платят за работу и переписанный код. Так что все будет окей, если будет)))
В принципе, возможный вариант реализации 8to4 при помощи опций IPv4, но могут быть проблемы с межсетевыми экранами и/или DPI.
Как я понял, они выбрали "ip8 внутри ip4" - "...8to4 tunnelling. HTTPS tunnelling is the preferred encapsulation...", со ссылкой на ещё неопубликованный draft-thain-routing-protocols-00. (Странный выбор, но для запоздалой первоапрельской шутки - нормально)
приложение делает резовл доменного имени и получает IPv4 или IPv6
совместимость закончилась здесь
типы записей есть A или AAAA. если отдавать только часть полного адреса в старом поле А то приложение работает только внутри своего сегмента
Ранее предлагался китайский IPv9, где вместо адресов использовались бы иерархично организованные сотовые номера (округ-город-район…), и там бы у каждого был свой уникальный адрес.
Ipv8 выглядит как нейрослоп. И не взлетит по многим причинам.
32 бита ASN + 32 бита host
Т.е. 64 бита вместо 128 IPv6. Вот если бы сразу так продумали, а сейчас как бы поезд ушел... Но 64 бита, то есть 18446744073709551616 вариантов - без шуток хватит всем. Если на Земле будет проживать 1 триллион человек (вряд ли больше выдержит) - каждому достанется по 18+ млн. адресов - хватит на все гаджеты с запасом.
Я просто искренне не понимаю такого расточительства как 128, когда 64 вполне хватило бы с запасом. Возможно проблема с построением иерархии - но неужели никакой алгоритм не могли придумать, чтобы и 64 хватило?
А вдруг человечество станет межзвездной цивилизацией с несколькими сотнями планет размером с землю?))) тогда все 128 бит ipv6 пригодяться)
Я тут ради интереса уже прикидывал. Сейчас распределяется блок 2000::/3. Если его весь оставить на земле, то для других планет остается всего-лишь 7 аналогичных блоков (а если выкинуть префикс E000::/3, в котором располагаются зарезервированные блоки, то всего 6).
Так что если сорить адресами так же как на земле, то наша межзвездная цивилизация будет всего-то 7-8 планет. Мелковато)
upd: на солнечную систему должно хватить. А для межзвездной цивилизации придется новый протокол внедрять, на 256 бит адресного пространства.
NAT выходит на межпланетный уровень
Сразу на 512, обратносовместимый с ipv6) чтоб сразу 32 шестнадцатеричных блока разделенных двоеточиями. Прикиньте такое запоминать) А то многие ноют про то что ipv6 запомнить не могут)
Ну кстати по логике v8 можно допилить и зарезервировать еще поле. Для идентификаторов планет, каждая со своим ASN))))
Скорее всего придется новый протокол, такое заранее не предусмотришь.
Мне тоже в первую очередь представилось как через неск тысяч лет люди с такой же болью будут переходить с ipv8 на какой нибудь ipv16
18446744073709551616 вариантов - без шуток хватит всем
Где то я это уже слышал =D
Как бы, 64 бит случайной (для temporary IPv6) или псевдослучайной (для secured IPv6) локальной части адреса обеспечивают существенную трудоёмкость перебора адресов домашней сети. И это существенно лучше, чем NAT IPv4, где нужно подобрать всего 16 бит. 😉
существенную трудоёмкость перебора адресов домашней сети
Как я понимаю, сейчас безопасность обеспечивается другими средствами.
Межсетевой экран с отслеживанием состояний - дело доброе, хотя и требовательное к процессору домашнего маршрутизатора. Но часто это простой NAT, а NAT это такая же угадайка, но попроще.
Ну не знаю, 8 байт не выглядит как абсолютная защита, если скорость и пинг увеличатся на порядки. Ну т.е. вроде норм, на уровне среднего пароля - но полностью доверить безопасность - нельзя. Там же еще парадокс дней рождений добавляется, т.к. в сетке не один давайс а может быть тысяча. И достаточно найти хотя бы один.
Как бы, пусть в домашней сети 1000 термометров, датчиков и счётчиков, которые лезут в облака.
В случае IPv4, даже если не рассматривать специализированные NAT атаки, они все имеют открытые NAT порты (номер порта - 16 бит, предположим, случайный). Сколько пакетов надо, что бы им всем устроить DoS?
А в случае IPv6, сколько пакетов надо для DoS?
Сколько пакетов надо, что бы им всем устроить DoS?
Обычно же DoS - на вполне себе открытые IP-адреса, которые публично известны для всех.
Оно, получается, что IPv6 вроде и решает проблему, но решает ее плохо во всех аспектах. И проблему DoS не решает и проблему безопасности не решает.
DoS если IP публичный - никак не решает. А если сервис и IP закрытый - то можно оставить вход только для твоего белого адреса.
Как бы ни к селу ни к городу - только лишний трафик в каждом пакете.
Конечно, стоило бы более точно систематизировать и определить, что именно Вас интересует, когда Вы говорите "безопасность обеспечивается".
Однако, ИМХО, при прочих равных:
IPv6 с маршрутизатором на много порядков безопаснее IPv4 с маршрутизатором;
IPv6 с маршрутизатором на два-три порядка безопаснее IPv4 с NAT;
IPv6 с межсетевым экраном в разы безопаснее IPv4 с межсетевым экраном;
Сравнение с IPv8 не имеет смысла, поскольку безопасность IPv8 - отрицательна. 😉 Пока рядом не стояла, и требует массы дополнительного времени под проектирование с непредсказуемым результатом.
P.S.
Но, конечно, поскольку мы все млекопитающие, сначала появился анус, а потом уже IPv6 (IPv4). 😉
Это если не стоит правило вида chain=forward connection-nat=!dstnat in-interface-list=WAN action=drop))))
По сути из 128 бит для выделения клиентам используется только 64. Но и даже эти 64 нарушают рекомендации и тогда для адреса клиента остаётся уже 56 бит. А если следовать полностью рекомендациям RIPE NCC, то для адресации клиента вообще остаётся всего 48 бит. Все остальные биты адреса уходят клиентам. Благодаря таком распределению адресов клиентам никогда не понадобится NAT, а в его сети будет нормально работать автоконфигурация. Но даже при таком раскладе каждому человеку на земле достанется как минимум по 200 сетей /48 только в одном диапазоне 2000::/3.
странно видеть проблему в фиксированных 40 байтах заголовка ipv6 по сравнению с переменными 20-60 в ipv4. точки зрения обработки, фиксированные 40 намного эффективнее переменных 20-60. да и по вкладу в трафик не всё в пользу ipv4.
Ну в теории каждый житель может вообще свой ASN заиметь)))) Включая стариков и младенцев))))
Главная причина 'не взлетающего' ipv6 - это производители потребительского оборудования (и возможно у провайдера но тут у меня знаний недостаточно), которые не предоставляют хотя бы того же функционала что есть при ipv4 при использовании ipv6.
Например NAT это встроенная фича блокировать все кроме разрешенного, попробуйте настроить то же самое, если все (максимально ненадежные и дырявые) устройства в вашей локальной сети будут иметь адрес в глобальной сети а в интерфейсе роутера единственное относящееся к ipv6 будет - включить/выключить.
Локальная сеть - это простейший фаервол, со своими недостатками, но главное, изоляция причем как снаружи так и изнутри.
p.s. в свете глобальных начинаний по разрушению интернета россии и других странах, ipv6 не будет внедрен еще дольше,.. это как беспокоиться о том какого цвета воротничок у рубашки будет, если тут головы рубят через одного.
Потребительское оборудование (роутеры) давно имеют штатный файрвол, закрывающий входящий трафик по дефолту. Обычному домашнему пользователю другое и не надо. Для всяких торрент-клиентов есть UPnP, который автоматически добавляет разрешающие правила в файрволе.
Другое дело, что провайдеров, предоставляющих IPv6 что-то не особо и видно. Некоторые крупные провайдеры в некоторых регионах может быть и дают IPv6, но всякая мелочевка - увы.
Аналогично у меня вопрос к хостерам и крупным контент-площадкам. Яндекс сам полностью доступен по IPv6, но в их же облаке IPv6 нет. Я сервис, живущий в яндекс-облаке, не могу выпустить в мир по IPv6. VK в принципе по IPv6 не доступен (что там в их облаке творится - не знаю, но думаю тоже ничего хорошего). Некоторые хостеры ipv6 только за деньги дают (алё, вам ipv6 адресов жалко?).
Короче типичная проблема курицы и яйца. И клиентское оборудование тут далеко не самая главная причина. Оно-то как раз и готово уже.
То что мне сейчас предоставил мой провайдер (ростелеком) этого не умеет, есть кнопка включить поддержку ipv6 и все (и ту включили по просьбе к саппорту, который кстати не мог сказать, есть ли у них поддержка ipv6 или нет).
Ранее у меня были роутеры как dlink так и keenetic (да не самые дорогие модели), так вот я не видел там ничего про настройку ipv6, а нужно минимум - полный запрет доступа и возможность разрешить доступ к конкретному устройству и конкретным портам.
Практически каждый год по стране в разных городах в местах где проживаем, роутеры стоят никакущие, ни о каком ipv6 речи не идет.
Проблема в первую очередь в оборудовании потребителя, во вторую - в провайдере (ipv6 over ip4 могло бы помочь как переходный момент), за все время у меня в принципе работало ipv6to4 только на одном, и это было лет 10 назад.
Провайдер должен дать Ipv6, больше у него никаких галочек и не должно быть.
Если использовать роутеры с прошивками 10-тилетней давности, то там да, с ipv6 всё плохо.
В keenetic с актуальной прошивкой (она есть даже для многих древних устройств) есть и поддержка ipv6 (причем с 5.х уже не модулем, а встроено наглухо), и файрвол закрытый по дефолту (можно отключить), и UPnP для торрента и даже можно разрешить входящий траф на определенный хост (но пока только через cli, возможно когда-нибудь и это в вебморду притащат).
Другое дело, что провайдеров, предоставляющих IPv6 что-то не особо и видно.
Аналогично у меня вопрос к хостерам и крупным контент-площадкам.
Это, к сожалению, в основном российские проблемы. А доля России в мировом интернете будет неуклонно снижаться.
...VK в принципе по IPv6 не доступен...
Непонятно, к примеру, пробуем:
$ nc -v -v -6 vk.com 80
Connection to vk.com port 80 [tcp/http] succeeded!tcp6 0 0 2a00:1fa0:4540:5.65134 64:ff9b::57f0:81.80 ESTABLISHEDУспех?
Ну, да, IPv6 Addressing of IPv4/IPv6 Translators, но в чём проблема?
Это у вас какие-то костыли используются? Потому что у меня вот так:
$ 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$ ping -6 vk.com
При проверке связи не удалось обнаружить узел vk.com.
Как бы, правильный DNS, в этом случае, должен вернуть адрес IPv4/IPv6 Translators, типа, 64:ff9b::57f0:8443, 64:ff9b::57f0:844e т.е. IPv6 представление 87.240.132.67, 87.240.132.78:
$ ping6 vk.com
PING6(56=40+8+8 bytes) 2a00:1fa0:4540:561:4c26:1286:65af:7caa --> 64:ff9b::57f0:8443
16 bytes from 64:ff9b::57f0:8443, icmp_seq=0 hlim=52 time=58.920 ms
...
$ ping6 vk.com
PING6(56=40+8+8 bytes) 2a00:1fa0:4540:561:4c26:1286:65af:7caa --> 64:ff9b::57f0:844e
16 bytes from 64:ff9b::57f0:844e, icmp_seq=0 hlim=52 time=78.452 ms
....
Это у вас какие-то костыли используются?
Обычный российский провайдер - МТС. По-моему, действует строго в рамках стандартов Интернет.
Значит это костыли со стороны МТС (я считаю IPv4/IPv6 трансляцию костылями. Это не нативный ipv6, а именно временное решение на переходный период).
Я использую гугловые DNS, они не отдают AAAA-записи для vk.com
$ nslookup vk.com 2001:4860:4860::8888
╤хЁтхЁ: dns.google
Address: 2001:4860:4860::8888
Не заслуживающий доверия ответ:
╚ь : vk.com
Addresses: 87.240.132.78
87.240.132.67
93.186.225.194
87.240.137.164
87.240.132.72
87.240.129.133
Как бы, правильные Google DNS отдают:
$ nslookup -query=AAAA vk.com 2001:4860:4860::6464
Server: 2001:4860:4860::6464
Address: 2001:4860:4860::6464#53
Non-authoritative answer:
vk.com has AAAA address 64:ff9b::57f0:8185
vk.com has AAAA address 64:ff9b::57f0:8448
vk.com has AAAA address 64:ff9b::57f0:8443
vk.com has AAAA address 64:ff9b::57f0:89a4
vk.com has AAAA address 64:ff9b::57f0:844e
vk.com has AAAA address 64:ff9b::5dba:e1c2
...
$ nslookup -query=AAAA vk.com 2001:4860:4860::64
Server: 2001:4860:4860::64
Address: 2001:4860:4860::64#53
Non-authoritative answer:
vk.com has AAAA address 64:ff9b::57f0:8185
vk.com has AAAA address 64:ff9b::57f0:8443
vk.com has AAAA address 64:ff9b::57f0:8448
vk.com has AAAA address 64:ff9b::57f0:89a4
vk.com has AAAA address 64:ff9b::5dba:e1c2
vk.com has AAAA address 64:ff9b::57f0:844eНепонятно, если Вам нужен IPv6, почему Вы их не используете?
именно временное решение на переходный период
Слово "переходный" - это фигура речи. Если, 6 июня 2012 доля IPv6 была ≈1%, а 16 апреля 2026 доля IPv6 ≈43%, стало быть, длительность полупереходного периода - 17 лет.
Так что, 90% следует ожидать к 2070...2080 годам. На наш век должно хватить. 😉
IPv6 это не замена, это дополнение к IPv4.
Мне в техподдержке МТС сказали, что IPv6 для домашнего интернета не предоставляют даже платно. Дом Ру - включается одной галочкой, Мегафон - тоже на роутере завелся без проблем. Г. Нижний Новгород.
P.S.
У меня профиль МТС - только IPv6, для вариантов только IPv4 или IPv4/IPv6 может быть иначе.
$ nslookup -query=AAAA vk.com 2a00:1fa0:7e00::64
Server: 2a00:1fa0:7e00::64
Address: 2a00:1fa0:7e00::64#53
Non-authoritative answer:
vk.com has AAAA address 64:ff9b::57f0:8448
vk.com has AAAA address 64:ff9b::5dba:e1c2
vk.com has AAAA address 64:ff9b::57f0:89a4
vk.com has AAAA address 64:ff9b::57f0:8185
vk.com has AAAA address 64:ff9b::57f0:844e
vk.com has AAAA address 64:ff9b::57f0:8443А, ну тогда понятно, для сетей IPv6-only использование NAT64 для доступа в IPv4 сеть нормальное явление.
Т.е. vk.com нормально обслуживает клиентов IPv6 без каких-либо проблем.
Нет. Это МТС превращает ваш IPv6 в IPv4 и засылает его в vk.com.
Upd: если есть аккаунт в ВК, зайдите https://id.vk.ru/account/#/devices, ткните "это устройство" и увидьте там ipv4 адрес в который натит МТС ваш трафик. Если бы ВК умело ipv6 нативно, то там был бы ipv6 адрес.
Нет. Это МТС превращает ваш IPv6 в IPv4 и засылает его в vk.com.
Ну, я же могу по IPv4 обратится (кстати, это чаще), маршрутизатор преобразует в IPv6, потом кто-то ещё обратно IPv4 (может даже и не один раз). Стандартный двойной стек Интернет (IPv4/IPv6).
Не понимаю, Вам шашечки? Или ехать? Клиентов IPv6 vk.com обслуживает? Ну, если они правильный Google DNS или иной правильный DNS используют? 😉
Клиентов IPv6
vk.comобслуживает?
Нет, не обслуживает. То что кто-то где-то сделал 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% - все ресурсы в Интернет должны иметь нативные адреса, без извращений.
Чтобы ipv6 стал 100% - все ресурсы в Интернет должны иметь нативные адреса, без извращений
Хм, Улита едет, когда-то будет. К гадалке не ходи, ещё лет 40-50-60 переходить будем, как минимум (до уровня 93%). И это не извращение, а нормальный двойной стек Интернет.
P.S.
К примеру, в СССР в розетках 230В первый раз появилось в 1928 году в Витебске и Бобруйске, а все 99% перешли в районе 2000. И нормально.
Читер. Я также могу сделать со своим DNS64+NAT64 и спокойно сидеть в своей IPv6only сети с доступом ко всем сервисам интернета без ограничений по версии протокола. Только это не отменяет того, что vk недоступен по IPv6.
это какие-то локальные костыли провайдера, потому что из внешнего мира ipv6 vk.com неизвестен (попробовал поресолвить ipv6 адреса vk.com со старлинка, который выдает нативные /64 префиксы).
а вот остальные сервисы типа гугл, aws, instagram, facebook, reddit и десятки других - прекрасно ресолвяца и работают по v6
В Беларуси ещё 5 лет назад был закон чтобы все провайдеры его поддержали. Первые годы были вопросы, особенно с pppoe. На удивление, большинство крупных провайдеров все сделали правильно, префикс /56 на абонента, можно статический. Мобильные операторы поддерживают все, кроме специфических случаев типа клон сим-карты. Целесообразность? Не знаю, например открытый в фаерволе ssh с адресом ipv6 slaac и стандартным портом не был брутфоршен ни разу за годы :)
А вот местные организации: всякие порталы новостные или госы — никто не умеет в ipv6.
Есть впечатление что весь белорусский ipv6 был заведен для частных энтузиастов и медийного эффекта (возможно есть и серьёзные причины, но обывателю они не ясны).
Есть впечатление что весь белорусский ipv6 был заведен для частных энтузиастов и медийного эффекта (возможно есть и серьёзные причины, но обывателю они не ясны).
Как бы, если у меня установлен "только IPv6" здесь, а лично у меня он установлен, то и у вас он будет работать точно также. Удобно, как минимум, для путешественников.
А вот местные организации: всякие порталы новостные или госы — никто не умеет в ipv6.
А смысл, если поставщики "только IPv6", согласно рекомендаций IETF, обязаны иметь IPv4/IPv6 Translators (NAT64)?
Возможно, в будущем, лет через 20, когда доля IPv6 абонентов подберётся к 75%, кто знает? Но сейчас, таковых всего 43%.
Стоит заметить, что у многих порталов также нету и обязательного SSL (иногда нет SSL вообще). Это вызвано в первую очередь огромным очень медленно обновляющимся парком клиентского оборудования во многих застарело-консервативных госорганизациях (даже XP на платформах с DDRI, IE6 - вот это все еще актуально). Там ipv6 сродни космическим технологиям. В одном месте я еще сам менял коаксиал на витую пару несколько лет назад (сохранил железо для музейных целей :D).
Потреблятельское оборудование смотря какое. Траффика три типа: inрut chain, output chain и forward chain. Первые два предназначены чисто роутеру, он обычно мизерный. Основной объем у роутеров в отличие от конечных устройств течет по третьей цепочке, а вот там как фантазия вендора разгуляется) И вот тут уже работают над connection state. К примеру, могут забыть запретить non-dstnated forward траффик, это тот, для которого есть записи соединений в таблице трансляции, которые обычно инициированы изнутри))) И вот тут плохишу достаточно у себя на пк прописать маршрут до подсети жертвы со шлюзом в виде ip-адреса на wan порту терпилы))) Но большинство вменяемых производителей наверняка уже лепят по дефолту подобное правило))))
Господи, сколько можно твердить что NAT сам по себе ни от чего не защищает.
Защищает Stateful Firewall, который ровно так же работает с IPv6 и не даёт доступа извне к девайсам за роутером.
nat закрывает доступ к локальным машинам извне
типовые настройки позволяют блокировать интернет машинам адресно, просто отключив шлюз по умолчанию (либо настройками на самой машине либо настройками dhcp)
эта защита - встроенная/автоматическая фича самой системы NAT, того факта что сеть разделена на локальную и интернет.
ipv6 это убирает (хотя само собой есть и там nat но вопрос в наличии поддержки ВСЕГО железа, что есть на рынке), открывая доступ ко всему оборудованию пользователя ПО УМОЛЧАНИЮ, и требует что бы роутер что то делал дополнительно что бы доступ был закрыт. Вот это 'делал' - отсутствует в интерфейсе потребительского оборудования, отсутствует по умолчанию, так как 90% потребителей не обязаны знать как это включать, они должны получить железо на руки, воткнуть в розетку и пользоваться.
Само собой, существуют иные уязвимости, например вебкамера по умолчанию сливает фото в облако, предоставляет удаленный доступ со слабым шифрованием или без и т.п... это не проблема ipv6 это другой уровень, никак с этим не связанный
То что NAT закрывает локальные устройства от внешнего доступа - это побочный эффект, который (при неправильной настройке NAT) можно обойти.
В современных бытовых роутерах с IPv6 файрвол включен по дефолту и пользователю не надо его включать.
я неправильными словами говорю?
в современном роутере по умолчанию будет предоставлен доступ ко ВСЕМ железкам пользователя в сети по ipv6, если нет, дайте модель роутера пожалуйста
Я вам тоже не теми словами говорю? В СОВРЕМЕННОМ роутере входящие по IPv6 ЗАКРЫТЫ ПО ДЕФОЛТУ. Никакого доступа снаружи нет!
Роутер - любой кинетик с актуальной прошивкой.
То, что в IPv6 сквозная прозрачность вовсе не означает что узел А может общаться с узлом Б! И современные маршрутизаторы по умолчанию настроены так, чтобы не пускать кого попало в периметр локальной сети. И им никакой NAT не нужен, чтобы это сделать для IPv6.
Mikrotik RB5009
По-умолчанию в цепочке input есть запрет на все, что не идет из LAN, в цепочке forward аналогично. Доступ извне - только если есть разрешающее правило на forward
Вы не понимаете как работает сеть и роутинг\трансляция адресов\файрволлы.
Например NAT это встроенная фича блокировать...
Например, общеупотребительные встроенные IPv6 temporary (RFC 4941) для исходящих соединений, для домашних применений, ничем не хуже. 😉
Если нужен домашний сервер, то общеупотребительные IPv6 secured (RFC 7217) для входящих соединений, то же неплохи.
Но, как заметил @Heggi, ни IPv4 NAT, ни даже IPv6 temporary/secured не заменят нормальный межсетевой экран.
По дефолту нат не защищает, это просто таблица трансляции. Защищают правила.
Хм, в случае NAT, часто предполагается, что любой "термометр" в локальной сети может открыть порт NAT одним из стандартных протоколов управления NAT.
Ну nat без правил файрвола не защитит, к примеру, от того что плохиш может тупо прописать у себя (наугад, перебором) маршрут до подсети за натом, указав в качестве шлюза Ваш адрес на wan порту. От этого уже защищают правилв. Во-первых, accept forward для new,related и untracked состояний, во-вторых, invalid drop, но главное - закрыть форвард цепочку со стороны wan в сторону lan для всех, кто не есть в таблице dst-nat) В микротиках последнее правило по дефолту с завода, но до сих пор далеко не все это правило включают, ограничившись первыми двумя.
Насчёт NAT с межсетевым экраном дело тёмное, если динамические правила запрещены, то может, они и помогут.
А если каждый “термометр” в локальной сети может открыть порт NAT одним из стандартных протоколов управления NAT, и для него правила модифицируют, то некоторое количество уязвимостей уже встречалось...
Выглядит как AMD64 в мире процессоров, но производители оборудования и оказатели услуг упорно внедряют IA-64.
Внедрённый на 50% неидеальный стардарт, обкатаный десятилетиями, многократно лучше драфта потенциально лучшего стандарта с нулём эксплуатационного опыта.
С другой стороны, в вечном статусе полувнедрения хорошего ничего тоже нет))) на вендорном и провайдерском уровне оно может и легко осваивается (ибо в промышленных масштабах городится), но на более мелких уровнях, как по мне, ipv6 это прям зло. Ipv4 запоминается легко, хотя и не всегда, а вот наркоманский ipv6 вводишь как будто длинный пароль. Полагаю, дичайшее неудобство играет свою роль в непопулярности.
Нужно избавляться от привычки вводить адреса руками. Для больших сетей есть DNS, для домашних - mDNS. На крайний случай - закладки в браузере.
вечном статусе полувнедрения хорошего ничего тоже нет
Кто сказал вечный? Через год будет 50%, через 18 лет все 75% или немного больше. По-моему, мы заметно операжаем график перехода со 110 В на 230 В, но немного медленнее, чем с 32-х бит процессоров на 64-е битные.
Полагаю, что всем заранее было понятно, что переход займёт лет 50. 😉
Да, никто в IPv6 не запоминает адреса. Либо они "рандомные" - всякие SLAAC и прочее, либо статика и копи-паст в DNS, плюс, как выше сказали - всякие динамические mDNS/LLMNR.
Чудес не бывает - хотите большое адресное пространство? Придётся иметь длинные адреса. Шестандцатиричное представление - самое компактное в данном случае, скажите спасибо что не оставили десятичное :) Можно было бы, конечно, какое-нибудь base64-подобное придумать, но это бы усложнило скорее всего всё.
проще сделать глобально маршрутизируемый anycast nat64 для ipv6. что-то типо 2600:6464::/96. и тогда ipv4 тоже будет подмножеством ipv6. в чем проблема? зачем изобретать велоспиеды? если сделать глобально маршрутизируемій nat64, то получиться что 8.8.8.8 = 2600:6464::8.8.8.8 = 2600:6464::808:808
Уже есть запись ::ffff:8.8.8.8 для совместимости. Достаточно узаконить её в виде настоящих адресов ::ffff:808:808
можно и так кстати. вполне неплохая идея, хотя я все же предпочел "заведомо глобальный" префикс, чтобы ни на каком оборудовании это не сломалось в случае чего.
Там в другой ветке обсуждали NAT64, там по сути трансляция адресов уже есть из коробки. И префикс зарезервирован 64:ff9b::808:808 и ваше предложение по сути уже реализовано. Нужны только anycast nat64 раскиданные по миру.
Кстати, 64:ff9b::808:808 и 64:ff9b::8.8.8.8 - синонимы, но только объявить его anycast немного недостаточно. Без DNS64 его польза немного ограничена. Собственно, рекомендации IETF для поставщиков "только IPv6", как бы, и так имеются в RFC 6586.
Возможно, кто-то где-то их выполняет не в полном объёме, ну так экцессы исполнителей случаются. 😔
@meizuflyme префикс 64:ff9b::/96 заведомо глобальный: IPv6 Special-Purpose Address Space , для приватных преобразований, к примеру, преобразований приватных адресов и/или преобразований иными методами есть 64:ff9b:1::/48, к примеру: 64:ff9b:1:fffe::192.0.2.1.
P.S.
Что до префикса, ::ffff:0:0/96, то в RFC 6052 поясняется, что он для другого алгоритма, и иногда, некоторые ОС выполняют преобразование на месте, что иногда нежелательно.
NAT64 в немаршрутизируемом формате64:ff9b::/96 работает только внутри сети провайдера. А идея в том, чтобы сделать его anycast-овым и доступным даже если провайдер на это забил.
...
64:ff9b::/96работает только внутри сети провайдера...
Как бы, нормативный документ IANA IPv6 Special-Purpose Address Space не имеет такового ограничения:
Source: True;
Destination: True;
Forwardable: True;
Globally Reachable: True.
Но никто не мешает написать черновик на одну страничку и заслать в IETF с целью уточнения данного разночтения (константный Globally Reachable префикс, но не anycast). Примерно так, как это сделал Jamie Thain с Бермудских островов, прости Господи. Творчество которого и породило данную дискуссию.
Желаете инициировать данное действие? Что бы этот префикс был бы зарегистрирован ещё в одной таблице IANA.
Нельзя. Одной из причин внедрения IPv6, является катастрофическая ошибка с распределением IPv4. Когда они начали заканчиваться, их стали нарезать всё меньшими и меньшими сетями. В итоге в BGP Full View сейчас около миллиона IPv4 маршрутов. Маршрутизаторы хранят таблицу маршрутизации в SRAM, а это очень дорогая оперативная память. Нет идеи ужаснее, чем втащить этот миллион маршрутов в IPv6 BGP Full View.
Изначально предполагалось вообще ввести в IPv6 уровни сетей, чтобы их можно было агрегировать. То есть Tier-2 должны были гарантировать путь до любой сети в определённой стране или даже континенте. В таком случае обрыв линии одной из сетей в интернете не приведёт к перестроению таблицы маршрутизации всего мира, а только региона. Но закончилось это либеральным предложением брать сразу столько адресов сколько надо, чтобы был один маршрут на одного LIR. То есть провайдеры обязаны жадничать, а не просить одну /32, а потом ещё одну и ещё...
Звучит приятно, но есть одно но. На этот адрес будет литься весь трафик IPv4. Если это будет какой-то публичный шлюз, то по сути туда пойдёт весь IPv4 трафик интернета. Что делать, чтобы не перегружать узел? Использовать не один, а несколько. Но тут мы упираемся в префикс 64:ff9b::/96. Его могут использовать провайдеры на своей сети. В таком случае достаточно клиенту предоставить DNS64, или просто на клиенте указать DNS64 от Google или Cloudflare, и весь его трафик IPv4 польётся на NAT64 шлюз провайдера. Примерно также, как льётся IPv4 трафик сейчас на CGNAT провайдера. Только CGNAT с каждым годом всё больше и больше загружен, а нагрузка на NAT64 будет падать по мере внедрения на интернет сервисах IPv6.
В принципе, провайдеры тоже могут маршрутизировать 64:ff9b::/96 на вышестоящего оператора, который будет на своей сети иметь NAT64.
IPv8 выглядит как мечта.
сеть получает единую управляемую платформу
Тоталитарные у вас мечты.
В карму дал плюсом, в статью минусом — не согласен с изложенным.
Вы же никаких аргументов толком не даете, а выбросили Ваши эмоцию. В данном случае я могу так же поспекулировать и дать Вам пример взрывного роста ии моделей на трансформерах. Казалось бы, зачем, ломать всю индустрию видеоигр, производства карт памяти и карт графики? Зачем-то строят эти дата центры и выкупают все пластины кремния.
Поэтому, если построить правильное лобби, то может и взлетит.
жду с нетерпением октября, посмотрим как закроют этот черновик
Замечательное наблюдение, но у товарища с Бермудских островов, уже третья редакция https://datatracker.ietf.org/doc/draft-thain-ipv8/
Это совершенно не выглядит как мечта. Это выглядит как огромнейший костыль, который толком ничего не решает. А ещё, это выглядит как нейрослоп.
Что у нас уже есть и что нам предлагают? А есть у нас протокол IPv6, который прекрасно работает в самом ядре интернета и у провайдеров, которые его осилили. Этот протокол может делать всё, что умеет IPv4. Этот протокол совместим с IPv4 и вполне может транспортировать пакеты IPv4 внутри себя. Если у вас есть на устройстве протокол IPv6, то вы можете организовать доступ к любым ресурсам. Для этого нужен модифицированный костыль, который повсеместно применяется для IPv4, даже многоуровневый (NAT). DNS уже давно адаптирован для IPv6. DHCPv6 уже давно существует и при этом не является обязательным условием для автоконфигурирования сети (всё работает и без него, но вы можете его использовать для более сложной конфигурации). Все современные операционные системы поддерживают протокол IPv6, а если есть какие-то проблемы, то это проблемы конкретного софта, а не самой операционной системы. Все мобильные ОС умеют работать в сетях с исключительно IPv6-адресацией и из коробки имеют необходимый костыль — CLAT, для работы с IPv4 сервисами, которые не удаётся обмануть с помощью NAT64+DNS64. Большая часть сервисов работает без CLAT. Из того, что не работает без CLAT, я нашёл толко торрент клиенты и Steam. Точнее, торренты работают, но число пиров на IPv6 значительно меньше, чем IPv4 и часто невозможно скачать некоторые раздачи без доступа к IPv4 пирам. CLAT в настольных ОС из коробки есть только macOS, для Linux есть несколько решений, в будущей версии NetworkManager 1.58 тоже будет поддержка (можно попробовать уже сейчас установить версию 1.57). Для Windows 11 соответствующий патч проходит тестирование.
Производителям маршрутизаторов не нужно изобретать велосипед, так как уже есть, как минимум, OpenSource операционная система OpenWrt, которая поддерживает IPv6 из коробки, настроена по умолчанию безопасно (нужно только задать пароль для входа в интерфейс) и которую производители могут адаптировать под своё железо.
Чего не хватает в IPv6? То, что если вы пользуетесь только IPv4, то вам недоступны ресурсы IPv6. Есть костыльные решения, которые позволяют организовать доступ, но вы становитесь зависимым от туннельного брокера.
Что же нам предлагают по этому документу? Сегментировать интернет. Сделать кучу разных сегментов, которые напрямую друг с другом не связаны. Те устройства, что будут оставаться в сети IPv4 также не будут иметь доступа в сеть IPv8. Для доступа к IPv8 тоже нужен будет аналогичный костыль, как и для доступа к IPv6. Только подобный костыль для доступа к IPv6 уже есть, можно сказать есть даже несколько видов костылей. Т.е. единственная вещь, за что можно поругать IPv6 характерна и для IPv8. Для IPv8 нужно будет изобретать что-то новое, этим кто-то должен будет заниматься. IPv8 частично решает проблему нехватки адресов, но оставляет старые костыли в виде NAT для устройств пользователя, как минимум. Сквозную прозрачность хороним сразу. Более того, связь между устройствами из разных сегментов сети будет идти через устройства с довольно сложной логикой трансляции адресов. Это как NAT, только ещё более сложный. И эти устройства должны быть установлены в самое «ядро» интернета, где идут огромные потоки данных. Сомнительно, что современные технологии позволят обеспечить скорость передачи пакетов, которая сейчас есть в IPv4 и IPv6.
IPv6 создавался с прицелом на устранение выявленных недостатков IPv4, ведь при расширении адресного пространства протокол становился уже несовместим с IPv4 напрямую, поэтому и смысла нести дальше с собой все недостатки IPv4 не было. И именно поэтому протокол так отличается от IPv4 в лучшую сторону, хоть и требует некоторого времени на знакомство и выкидывания из головы «IPv4 головного мозга». IPv8 продолжает тянуть за собой все косяки IPv4 дальше.
Я не вижу никакого смысла во внедрении IPv8, даже если напишут то, чего сейчас не хватает даже для того, чтобы его попробовать. Внедрение IPv8 - это шаг назад. Индустрия уже сделала шаг в сторону внедрения IPv6 и на текущий момент любой провайдер при желании может включить IPv6 на своей сети. «Вой», что железки IPv6 не понимают… где вы нашли современное железо, которое не поддерживает IPv6? Вы до сих пор используете коммутаторы и маршрутизаторы из нулевых годов? Можно я не буду вашим клиентом. Лично мне не хочется, чтобы надёжность сети зависела от явно устаревшего железа, которое к тому же имеет довольно низкую, по современным меркам производительность.
Насколько я знаком с IPv6? Мне интересен этот протокол. В настоящее время я использую его в своей домашней сети. У меня есть устройства, которые работают исключительно на IPv6, в том числе сотовые телефоны у членов семьи и мой личный ноутбук с ОС Linux. Особого смысла так настраивать сеть нет, но лично мне интересно было настроить именно IPv6-only сеть, а не дуалстэк. И, как показала практика, это рабочее решение.
Что есть IPv6? Ошибка. Ошибка эксперимента, которую исправляют в течении последних 30 лет. И довольно успешно.
Что не так с IPv6?
Одно единое пространство идентификаторов. Дополнительные 96 бит, без структуры. Для хостов, между которых есть соединение, достаточно идентификаторов, которые уникальные в контексте тех хостов. Для роутеров, к которым те хосты подключены, идентификаторы хостов безразличны, им достаточно знать, как дойти до последнего роутера. Получается два пространства идентификаторов, которые имеют раздельные домены интерпретации и иерархию в адресации. 8+8 и производные были в обсуждении IPng, но проиграли, так как не соответствовали архитектурной чистоте end-to-end соединения. 10 лет позднее L3VPN практично показал, что при правильном структурировании иерархии адреса масштабируемость не является ограничивающей проблемой - полно сетей, которые по L3VPN AFI несут на порядок больше префиксов, чем IPv4 и IPv6 вместе взяты. 20 лет позднее LISP, ILNP, и их производные практично показали, что map + encap не требует дополнительного слоя туннелей, и может пользовать нативный IPv6, в котором части адреса приходят из разных и взаимно не связанных сущностей. IPv8 пробует сюда смотреть, но пропонент не знаком с механизмом раздачи блоков ASN регистраторам, и не потрудился подумать о сценариях TE.
Отсутствие интеграции идентификаторов и имен. В FC изначально сделали правильно - эндпоинты имеют имена и между собой общаются по имени, фабрик представляет передачу от точки к точке по адресам, а система разрешения имен соединяет имена и адресацию в единое. Не надо пользователю знать и показывать адреса, достаточно имен. И сегодняшнее представление 128 бит в hex строке - это тоже должно быть интерпретировано как имя, если у ендпоинта нет другого имени. IPv8 здесь ничего не делает.
Отсутствие механизма OAM, и, смотря более широко - отсутствие механизма сигнализации между хостом и сетью. Как убедится, что удаленный эндпоинт доступен? По NOOP протокола верхнего уровня? А если такого нет? Как убедится, что мы подключены к тому удаленному ендпоинту, к которому были подключени прежде? А есть ли возможности послать что-то, что удаленная сторона сможет идентифицировать не как данные, а как сервисное сообщение? Как запросить резервирование или гарантию каких-то ресурсов? При помощи костылей всякого рода. Пропонент IPv8 об этом молчит.
Принятие на себя функциональности транспорта. Фреймирование - это задача транспорта, а транспорт - это ответственность хоста. Роутер IPv6 по OAM каналу информирует хост о PMTU и не пробует быть слишком умным притворяясь, что сможет сам порезать на фрагменты правильно и быстро. Пропонент IPv8 смог найти место для поля Fragment Offset в хедере. Но дальше не смог.
Игнорирование реальности аппаратных платформ. Для того, что-бы железо работало быстро, надо тому железу намеренно не мешать. Фиксированные положения и длины полей, маскирование, сосредотачивание компактно тех полей, которых надо обработать, правильное выравнивание - за такое железо вам поблагодарит. За IPv6 EH железо вас будет ненавидеть тепловыделением и тормозами. За 30 лет радикально ситуация не поменялась, и не предвидится, что радикально поменяется в перспективе. IPv8 здесь не меняет ничего принципиального.
Что так с IPv6?
Достаточно места в полях идентификаторов для гибкого их использования. 128 бит может вместить много всего, а несколько раз по 128 - и того больше. SR - это в сторону того, как проблематика адресации и иерархий должно было быть решено изначально. IPv8 в этом контексте - это шаг назад.
Механизмы расширения. EH в форме фиксированных хедеров, которые всегда присутствуют, но не всегда заполненные. В идеале - унификация механики EH с Geneve. Пропонент IPv8 о таком не слышал.
Множество типов адресов. При правильной интеграции системы имен достаточно только локальных адресов, желательно еще адреса для ноды, а не только для интерфейсов. Пропонент IPv8 об таком не слышал.
Адреса фиксированной длины. Все, что фиксированной длины - это радость для железа. Для софта желательно, что-бы адрес влез по ширине в нативный регистр. Но SSE и эквиваленты в параллельных вселенных сегодня есть на абсолютно всем релевантном. IPv8 маргинально проще для скалярного домена.
Что произошло за эти 30 лет?
Поменялась концепция доступности соединения - нет большой потребности иметь возможность установить соединение с любой точкой в сети, в доминирующем количестве случаев достаточно до ближайшей точки обмена, где все релевантные контент провайдеры примут то соединение. И без большей разницы - по IPv4 или по IPv6. Эта тенденция не имеет склонности поменятся обратно в обозримом будущем. Если TLS одинаково хорошо работает поверх IPv4 или IPv6 - то для доминирующего большинства сфер применения нет потребности смотреть ниже что и как там пользуется.
Что делать с IPv8?
Игнорировать и забыть. :-) Нет, надо об этом говорить. Что-бы набежавшие академики, блогеры и прочие эксперды и поклонники SCION не наделали проблем, как 30+ лет назад с IPv6. Статью что-ли написать с разбором IPv8?
IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит