Комментарии 309
По-моему это новость отлично иллюстрирует текущее состояние IT
Нужен достаточно мощный стимул и всё полетит, а без стимула, оно не сильно то и надо.
Даже если все сайты будут на IPv6, домашние интернет-провайдеры всё равно не будут ничего делать, ведь на гугл им пофиг, а сайты успешно работают и по IPv4. Откуда взять стимул для провайдеров?
Если баннер будет появляться одновременно и в хроме, и в FF и в остальных браузерах, то некуда будет пересаживаться. Это уже было с HTTPS. А сейчас, например, это происходит с DoH — благодаря внедрению технологии во все популярные браузеры одновременно, тем, кому это не нравится, сложно с этим бороться (если испортить DoH, то пользователи уйдут к тому провайдеру, который не портит DoH, а не сменят браузер).
Типичному сайту-визитке всё это не нужно, его задача — показать десяток картинок и пару страниц текста.
Однако кооперация определённых организаций привела к тому, что и такие сайты стали внедрять HTTPS. Вот точно так же можно и IPv6 пропихнуть в массы.
Я никаким образом не агитирую неиспользование HTTPS. Это как с полнодисковым шифрованием — лучше зашифровать всё, чем долго думать и делать это избирательно, ведь из-за одной маленькой ошибки в конфигурации шифрование может стать бесполезным.
Прежде всего, это кооперация нечистых на руку провайдеров и мобильных операторов, которые решили, что можно внедрять рекламу через http.
Помимо чисто юридического решения, техническое бы тоже не помешало.
Люди законы не нарушают не только потому, что в законах прописана «ответственность», которую причинит государство. А потом что так воспитаны, потому что есть куча мелких преград, потому что в некоторых местах висят камеры, и т. д. В общем, комплексный подход.
Закон «Об обязанности быть просто трубой» гораздо сложнее нарушить, если трафик зашифрован. Меньше возможностей легко делать правонарушения — меньше правонарушений — меньше бюджета на это — увереннее люди. И это не говоря уже о том, что обновление на сервере или в браузерах обычно легче разверуть, чем принять законы во всех странах мира, организовать соблюдение этих законов, наказание за их несоблюдение, и т. д.
Устройства обновлять не нужно. Маршрутизацию менять не нужно.
И вообще, https касается только отдельной небольшой части интернет, вто время как IPV6 касается ВСЕХ ее аспектов.
https для всех промежуточных устройств работает прозрачно.
Для всех маршрутизаторов он работает прозрачно.
То есть чтобы включить https соединение между Канадой и Австралией, нужно просто двум людям поправить у одного браузер, у другого веб сервер. Кому надо — тот пользуется, кому не надо — не пользуется.
А для полноценной работы ipv6 нужно обновить все промежуточные устройства, некоторые из которых не подлежат программной перепрошивке, обновить всю топологию инета, когда все участники настроят новые адреса, подсети, маршрутизацию и так далее.
Иначе, нагрузка сожрёт все ресурсы сервера
Это только на тех серверах, у которых высокая нагрузка. Предположительно, такие сервера и так не старые.
Я же говорю про множество реально старых вещей.
Компьютеры в муниципальных заведениях. IP камеры, видеоприставки, старые игровые приставки, которые тоже могут быть не только дома у мажоров, но и в различных учреждениях, особенно муниципальных, например дома престарелых, в которые могли быть закуплены по какой-то программе 10-20 лет назад, и просто работают, за ними почти никто не следит.
Обновлять весь стек таких устройств — это целая программа поддержки, которую кто-то должен не только оплатить, но еще и организовать по всей стране.
А значит нельзя просто так взять и отрубить глобально IPV4, надо оставлять какие-то гейтвеи. А раз они остаются, то и ipv4 остается рабочим. А раз остаются, то нет мотивации срочно все брать и переезжать. IP адресов ведь на самом деле не хватает кому-то там, а подавляющей массе — достаточно.
1) сетевую карту (для поддержки IPv6) (скорее всего, у же не актуально)
2) OS (уже не актуально, современные OS поддеживают IPv6)
3) ПО (для поодержки IPv6)
4) Маршрутизатор
5) Оборудование провайдера/самого провайдера
При этом к HTTPS относится лишь пункт 3 — браузер с поддержкой IPv6
Пункт 4 — основной тормоз распространения IPv6 (на мой взгляд)
1) сетевую карту (для поддержки IPv6)
что?!?
4) Маршрутизатор
где вы сейчас найдёте маршрутизатор без поддержки ipv6?
Я расписал стек технологий. Переход на некоторых этапах уже сделан, на некоторых ещё нет. Не вижу объективных причин для спора.
> что?!?
Что? Частично парсинг пакетов происходит уже на уровне сетевой карты. Современные сетевые карты уже имеют поддержку IPv6
> где вы сейчас найдёте маршрутизатор без поддержки ipv6?
В легаси системах?
Частично парсинг пакетов происходит уже на уровне сетевой карты. Современные сетевые карты уже имеют поддержку IPv6
Чушь полная.
Вы путаете ethernet-пакеты (уровень L2 модели OSI) и IP-пакеты (уровень L3 модели OSI).
Сетевые карты и их драйвера работают на уровне L2 модели OSI, протокол IP - на уровне L3.
Просто потому, что эту информацию можно поменять, и получатель не определит факт этой замены.
В итоге в содержимом «cats_smooth_scroll.js» может прилететь «evil_cryptominer.js» или ещё чего похуже.
В итоге в содержимом «cats_smooth_scroll.js» может прилететь «evil_cryptominer.js» или ещё чего похуже.
априори, если на захожу на сайт по http, то я считаю его недоверенным.
на недоверенном сайте может быть вредоносный js.
что меняет добавление https?
HTTPS даёт гарантию неизменности содержимого в процессе доставки. Всё.
Если я доверяю автору, то я буду доверять его сайту при использовании https, и не буду при использовании http.
Если я не доверяю автору — никакой https не изменит моего отношения.
HTTPS даёт гарантию неизменности содержимого в процессе доставки. Всё.
да, именно это и хотел сказать
и именно поэтому я не понимаю, зачем для условного anekdot.ru нужен https.
Чтобы удостовериться, что исполняются у вас скрипты, которые имели в виду разработчики anekdot.ru, а не, например, ваш провайдер или корпоративный админ добавил что-то от себя (хотя с админом сложнее).
какая разница, если для меня разработчик anekdot.ru и провайдер — одинаково недоверенные лица?
Для вас одинаково, для меня, например, нет.
Далее. Взял в чехии вдс. Только ipv4. Почему? Пиринг v4 — куча вариантов, все готовы. v6 — за отдельную БОЛЬШУЮ сумму, при том что у площадки уже есть какая-то своя сеть, /32 если не больше.
Помнится, была история что у ряда площадок включая контакт был v6 в тестовом режиме, но проект признали провальным и отключили. Ну и host vk.com мне реально не даёт v6 адреса площадки.
Ощущение, что v6 просто никому не нужен.
ЗЫ огромная просьба, если кто не согласен — не просто лепить минус, а обосновать. Это всё моё имхо, но я честно пытался подключиться к в6. 2 года пытался, потом перестал.
Тем более о реальных проблемах есть шикарные комментарии, типа habr.com/ru/company/vasexperts/blog/508518/#comment_21784304
ЗЫЫ если кто не знает, есть уже в стандарте NATv6
Ощущение, что v6 просто никому не нужен.
Всё верно. А время от времени вылезающие v6-агитаторы несколько достали, хотя в последнее время их меньше стало.
Давно пользуюсь vps от hetzner. IPv6 был в комплекте и бесплатно.
Так что не везде проблемы с IPv6 адресами.
Это ровно 1 адрес
Домашним провайдерам это как раз больше всего пофиг: они ставят NAT и не парятся. Единицам клиентов, желающим внешний IP, можно впарить дополнительную платную услугу — вообще благодать!
Для меня такой провайдер стал поводом перейти на другой, ибо надоело убеждать гугл, что я не робот.
Ну просто он был или жадный, илм тупой. Oversubscription нужно держать на уровне 16 серых в 1 белый и не будет никаких капч. Многие, кто только начал натить не понимают этого и лупят 1:128 и больше. Раньше это бы разорвало ТП, а сейчас тупо отток увеличивает. (Ваш случай)
Понятно что когда 16 человек за одним ip сидит, шансы в 8 раз ниже чем когда 128. Но всё равно даже при 16-ти будут те кто вынужденно будет вводить капчи.
а я одно время сталкивался с капчей дома, где в сети компьютер и пара телефонов (мой и жены). реальный динамический ip, меняется крайне редко («не было ни единого разрыва»).
это было одним из поводов ещё раз попробовать на яндекс перейти, но нет, на моих запросах качество поиска у гугла лучше.
притом оно «наплывами», одно время и на работе такое было, потом прошло (а там на одном внешнем ip сотни компьютеров).
Вон Теле2 всем ставит китайские роутера с оптикой по квартирам но…
Не включает в настройка получение адреса IPv6 по DHCP хотя он у него уже есть, и давно.
В общем, зайдите на роутер и включите. Возможно что IPv6 у вас уже есть, просто вы не в курсе об этом.
(Я говорю про Пермь, и да… у Дом.ру тоже есть IPv6 если в вас включено получение адреса IPv6 по DHCP)
У провайдера v6 нет, поэтому дома поднят туннель через HE, при этом варианте гугл никогда не считает меня роботом, зато яндекс — всегда. Понять почему так можно, но достоинства использования v6 перевешивают оные от яндекса, поэтому яндексом просто не пользуюсь.
Что IPv6 даёт сайтам?
Ровным счётом ничего.
А https даёт шифрование и потоки.
В гугле не дураки, дураки где-то в другом месте.
Но много ли кому эта возможность реально нужна?
В крупном сервисе, у которого одна машина не сможет обработать весь поток входящих в одну точку запросов от балансировщика отказаться не получится. Но у типичного хостинга есть куча мелких клиентов, и целая пачка сайтов влезает на одну машину. В таком случае можно анонсировать адрес сайта, крутящегося на этой машине наружу, и тогда трафик будет сразу приходить на неё.
Если не рассматривать хостинги, а ограничиться домашними пользователями, то возможность повесить по адресу на каждое своё устройство позволит избавиться от целой кучи костылей в виде ALG и обеспечить хорошо работающую end-to-end связность, что может быть полезно для IoT (не той домашней автоматизации, что сейчас, когда устройства разговаривают с единым центром, а именно интернета, когда устройства разговаривают друг с другом).
Вот к примеру биос и вендоры материнок вообще особо не парятся — там жуткая жуть у некоторых производителей, в том числе и с SecureBoot. А казалось бы куда ответственней место. А тут холодильник какой-то.
Ну и отдавать безопасность «чёрной коробке» очень недальновидно. Проблема в том, что пользователи давно пользуются устройствами по принципу — включил, протыкал да, да, да, ок и работаешь.
А с файерволами всё не так прикольно, да и как только включаешь на них «пароноидальный» режим, то сразу начинает что-то нужное отваливаться и нужно лезть разрешать. Через N итераций типичный пользователь замучается бороться с этим и разрешит всё.
Особенно учитывая, что многие нынешние программы поднимают по 100500 соединений и постоянно мигрируют между площадками (и это нормально). Тут сразу возникает вопрос об обязательности DNSsec и так во всём. Чем дальше в лес — тем толще партизаны. Простые проблемы становятся сложными, обрастают своими костылями и результат мы видим в текущем состоянии отрасли
небезопасное соединение!
Но ведь это неправда?
Соединение по Ipv4 по безопасности не хуже, чем ipv6, в отличие от http/https
«у вас пропадёт доступ, если ваш провайдер выключит IPv4».
Это тоже неправда.
Для хостеров категорически нельзя просто выключить. Им клиенты деньги платят. Перед каким-либо отключением ipv4, им нужно будет либо согласовать со всеми клиентами переход, включая перенастройку ДНС, либо придумать гейт между протоколами.
Было бы все так просто, не толклись бы 10 лет на одном месте
Как показывает практика, хостерам и провайдерам "последней мили" достаточно просто заблаговременного уведомления клиентов, чтобы что-то изменить. Да и без него вообще делали. Например, один из питерских провайдеров просто закрыл трафик между своими клиентами "по просьбам трудящихся" (что-то там с виндовой сетью было связано). Включая клиентов с белым статическим IP. Для них потом откатил, а для остальных нет.
Сколько уже говорили — не пользуйтесь левыми хостингами.
Лечиться ходите тоже по рекламе к первому попавшемуся?
Левые или нелевые сложно разобраться. OVH левый например или нет?
SEO рекламой считается?
Учитесь распознавать.
Это OVH вам "закрыл трафик между своими клиентами" ?
OVH для меня хостер, весьма вольно обходящийся с уже оплаченными услугами. Оплатил тариф на год, а через несколько месяцев тебя уведомляют, что до конца оплаченного года этот тариф не доживёт, деньги не вернут, а дадут какую-то скидку, если приобретешь новый сервер по новым тарифам, в строгом соответствии с "мелким шрифтом" — шаг влево-вправо и скидка не действует.
Привет таким «экспертам», как указанный журналист, с их призывами. Забыть на много лет о проблеме — это ок, а что ipv6 перемудрен, отчего никем не понимается как должен — вот это проблема. Ах да, есть еще софт, который нужно переписать, правда, и баги, которые нужно отловить.
Ага, поэтому для link local адреса приходится аж имя интерфейса дописывать
Так это как раз результат упрощения — все link local адреса принадлежат сети fe80::/10.
Пример, с которым сталкивались многие: если подключаться через VPN к себе в локальную сеть и в гостевой сети тот же диапазон, что и в локальной — поимеем проблемы с маршрутизацией. В ipv6 проблема хорошо решена рекомендацией использовать глобальные адреса, в том числе для локальных ресурсов и суффиксом интерфейса для link-local.
И со сменой интернет-провайдера вся локальная IPv6-сеть тоже полетит к чертям?
Если глобальные адреса использовать (и не покупать PI-диапазон) — да, полетит. Если link-local — не полетит.
С одной стороны я очень люблю IPv6, но вот за отсутствие роуминга авторам даже не даой, а кол.
Вот эти все ставки, dns зоны и всё такое — кривой костыль.
В итоге, для получения persistent адреса при двух аплинках (очень даже легко даже в обычных квартирах) нужно ставить где-то vps, поднимать туда vpn через оба линка, поднимать ospf… задача ну явно не для простого пользователя ;(
Та же проблема существует и с IPv4. И решения примерно те же.
А какое решение бы вы предложили для реализации роуминга?
А какое решение бы вы предложили для реализации роуминга?
Наличие флага резервный префикс в ответах RA, наличие уведомления prefix route is dead. Желательно иметь возможность заранее отправить удалённому узлу свой резервный адрес и бесшовный переход на него.
обязательной частью реализации IPv6С каких пор наличие MUST в стандарте начало останавливать людей от публикации и продажи недоделок? Часто Вы этикетку IPv6 Ready P2 видите?
С каких пор наличие MUST в стандарте начало останавливать людей от публикации и продажи недоделок?
С тем же успехом можно продавать коробку с антенной без беспроводного модуля внутри. Или корпус от жёсткого диска с гайками для веса. Это не будет IPv6-роутером, а попытка об этом заявить потребителю станет обманом.
Тогда производитель будет вынужден написать, что у него почти IPv6-соместимый роутер, что уже не столь привлекательно выглядит.
возможность заранее отправить удалённому узлу свой резервный адрес и бесшовный переход на него
Это сломает TCP в текущем виде. Но можно пытаться это исправить с помощью SCTP и MPTCP.
Та же проблема существует и с IPv4. И решения примерно те же.
Факт. Отчасти это решилось возможностью использовать /24 в глобальной BGP маршрутизации ценой существенного увеличения размера BGP Full View.
А какое решение бы вы предложили для реализации роуминга?
Память маршрутизаторов существенно подешевела, поэтому видится самый простой вариант — выдавать PI адреса массово всем подряд (а это будут десятки-сотни миллионов подключений для тех, кому нужен PI) и заложить необходимость поддержки пиринга с обычными клиентами.
Если добавить некоторые ограничения по агрегации, то совсем уж жирными таблицы не будут.
С другой стороны — обычному пользователю и так хорошо с IPv4+NAT, почти бесшовное переключение каналов работает чуть ли не из коробки.
И выходит, что сейчас переезд на IPv6 — это реальный шаг назад :(
Да да
Только в4 знают тупо все эникеи вокруг, а в6 боятся даже опытные админы заюзать. Простой потому что?
При том, что на домашнем роутере v6 настраивается буквально в два щелчка. Куда проще то?
При том, что на домашнем роутере v6 настраивается буквально в два щелчка. Куда проще то?С учетом того, что домашняя сеть это самое простое что только может быть, то было бы удивительно, если бы там все не настраивалось в 2 клика. Только как это поможет что-либо понять? И да, домашние сети — это как раз то место, где IPv6 нафиг не упал.
И да, домашние сети — это как раз то место, где IPv6 нафиг не упал.А мне вот как раз нафиг упал именно в домашней сети. Начиная от дополнительных IPv6-пиров в торрентах и продолжая прямой связностью с рабочими VPS, у которых тоже IPv6 есть.
Начиная от дополнительных IPv6-пиров в торрентахIPv6 пиры в торрентах сейчас реально дают заметный прирост в скорости? У меня просто и без них в 99% случаев все просто в пропускную способность сети упирается, а в оставшихся 1% — в то что раздачу ведут полтора человека и скорость у них в принципе не ахти.
продолжая прямой связностью с рабочими VPS, у которых тоже IPv6 есть.Ну это совсем специфичный кейс, такое нужно долям процентов пользователей. Если не секрет, а зачем вам прямая связность для VPS?
зачем вам прямая связность для VPS
Не знаю сценария DreamingKitten, но мне удонбо делать
ssh hostname на внутренние удалённые узлы, ничего не настраивая, кроме, возможно, фаервола на той стороне. Увы, SSH, в отличии от HTTP, не умеет virtual host.И если единственный сервис, который биндится на IN[6]ADDR_ANY — это хорошо настроенный sshd, то почему бы и нет?
Как минимум, для удобства DNS или аналогичная система резолвинга человекочитаемых имён должна быть не где-то сверху, а неотъемлемой частью протокола.
IPv6 пиры в торрентах сейчас реально дают заметный прирост в скорости?
Если на редкой раздаче почти нет сидов и все за двойным IPv4 NAT, то да. Скорость будет выше нуля.
С учетом того, что домашняя сеть это самое простое что только может быть, то было бы удивительно, если бы там все не настраивалось в 2 клика. Только как это поможет что-либо понять?
А там понимать — меньше чем в v4 по количеству сущностей.
1. вам выделяется сабнет /48 или /64 (обычно).
2. если вы не хотите маяться с DHCP6 — вам нужен SLAAC, который работает с /64. т.е. если у вас корпоративная сеть — вам нужен /48. если вам не хватит 65535 сабнетов — я очень удивлюсь.
3. на роутере сабнета поднимается RADVD, указывается дефолтный интерфейс для роутинга v6 трафика, дальше все работает автомагически.
дальше все работает автомагически.А дальше какой-нибудь сервис работающий на каком-нибудь условном древнем jetty поднимет лапки и скажет «не умею я эти ваши IPv6». А дальше сиди и думай как бы так закостылить, чтобы оно все завелось. И в рельной корпоративной сети таких сервисов будет не 1 и не 2. Переход IPv4/IPv6 затрагивает не только IP адреса, но и потенциально вообще все что как-то работает с сетью, а в реальной сети там будут сотни сервисов, и далеко не во всех них есть поддержка IPv6, и далеко не все сервисы которые заявляют поддержку IPv6 реально его поддерживают.
Но вот вопрос: сидел я ввиду вируса дома, собрались мы с коллегами в видеонференции. Все всех видят, а меня — нет. Оказалось, что все по в4 работают, а трафик от меня рванулся наружу через в6, и с другими участниками конфы медиа не состыковалась. Привет, конечно, конф-софту (не буду хаять, но — оно российское, у них и так багов на 5 лет фиксения, и в6 для них никак не в приоритете в этом смысле — и так есть что ремонтировать, а покупают у них «под вирус» со страшной силой, и репортят проблемы тоже помногу).
Это я к чему: я знаю, как поднять в6. Знаю несколькими способами, и в разных позициях. Я агитировал за него намного раньше, чем многие здесь на Хабре узнали или задумались о нём. Так что говорить, полагаю, право имею, и именно не в стиле «мой роутер осилил, я стал крутым в6-админом!»
Более того, замечу, что статьи и посты «как настроить себе в6 годами идут в стиле „туннель поднять не так и сложно“, и почти никто не пишет про „мой оператор дает в6, как его принять и использовать в своей сети. Только правильно настроить от этого а) не стали уметь шире, б) нет желания связываться и ловить баги в) операторы прямо говорят (да, 8 лет точно) “мы в6 даем в режиме теста, т.к. сами не уверены, что он у вас как у клиентов заработает как надо» (и это — про руки, свои и клиентские).
Что софт в6 не умеет без багов — известно. Если мы про сеть компании, то нужно, условно, чтобы 1с или Autocad (или какой там софт для работы у нас стоит — и, да, весь рабочий софт) умели в6 «как часы», если про сеть дома, то речь про домашний софт, но тоже весь (хотя бы тот, что в семье используют, чтобы перед домашними не было стыдно).
Я уже молчу про старые и не очень ОС, про прооритет в4 или в6. Вот даже отладить работу сайта, который доступен по в4 и по в6: пусть у нас на сервере сломался в6 — в одной и той же локалке, на соседних машинах у кого-то сайт открывается отлично (потому что там в4 имеет приоритет), а на другой сайт не отзывается (на ней поставлен приоритет в сторону в6).
Добавляет ли это уверенности всем, начиная с магистралов, и заканчивая конечными пользователями? Нет. Проще не использовать, либо поставить в план себе «разобраться», но потом, «когда уже оно заработает».
Так и живем.
Так что агитировать — это хорошо, но давайте о жизни.
Добавлю, что куча встроенного оборудования тупо не умеет в6 и менять их не будут минимум 10 лет ибо дорого. У китайцев до сих пор нет дешёвых ethernet контроллеров с поддержкой в6 из коробки, везде допилинг нужен в части прошивки, а это тоже деньги и вычислительных ресурсы тоже деньги.
в ipv6 надо месяц вникать, и то без практики все вылетает из головы.
При том, что на домашнем роутере v6 настраивается буквально в два щелчка. Куда проще то?
А IPv4 в ноль щелчков.
А IPv4 в ноль щелчков.
Да щас, ага. DHCP настрой, диапазон адресов выбери, еще и дурацкий NAT, ибо глобальных адресов не хватает.
NAT по дефолту включен.
Аплинк тоже по DHCP настраивается от провайдера.
То есть при адекватном провайдере — купил, пришел, воткнул — работает.
Только если wifi нужен — придется имя сети и пароль придумать.
А если еще и админский пароль догадался сменить — то уже и защищен, насколько это возможно.
То же самое при адекватном провайдере — купил, пришёл, воткнул — работает.
в любой порт вставить шнурок от провайдера, в любые другие порты вставить свои компьютеры.Оно уже так без всяких IPv6. Разве что все-таки не в любой порт, разделение на WAN/LAN по-умолчанию еще есть.
Это просто лень, тут не нужны сложные оправдания.
Иногда это просто отсуствие информации.
Даже банальный проброс на микротике по IPv6 не везде расписан.
Вот как доступ до сайта дать по IPv6 через mikrotik
awsswa.livejournal.com/42767.html
NAT не нужен.Ага, и вместо него придется везде втыкать фаервол, ибо сейчас каждая лампочка начинает подключаться к сети. И с безопасностью у IoT девайсов зачастую всё просто охренительно плохо. Сейчас они хоть как-то прикрыты NAT'ом, а вот с IPv6 вся эта хрень начнёт торчать наружу. Нет, кончено более-менее разбирающиеся люди это все понимают и все себе прикроют, благо это просто. Но вот обычные пользователи резко начнут охреневать, ибо их умной лампочкой сможет рулить каждый второй школьник.
Но вот обычные пользователи резко начнут охреневать, ибо их умной лампочкой сможет рулить каждый второй школьник.Ой, можно подумать сейчас сотни IPv4 приватных вебкамер не ищутся простыми запросами в гугле. Это не проблема протокола.
Между развёртыванием NAT и развёртыванием файерволла принципиальной разницы нет, зачастую для этого даже софт один и тот же используется.И в итоге мы пришли к тому, что NAT не нужен, но на самом деле нужен.
Это не проблема протокола.Конечно не проблема протокола, это проблема всех этих миллионов кривых IoT девайсов. Вот только NAT хоть как-то эту кривизну прикрывает. И переход на IPv6 без NAT эту заплатку сорвет. А теперь, внимание вопрос: какой резон условному провайдеру переходить на IPv6 без NAT если это создает проблемы его пользователям?
У меня к примеру роутер TL-WR1042ND умеет работать ipv6, но умеет только трафик пускать по нему и ip раздавать.
Файервол и QoS, черные списки — только для v4.
Потому я сначала поднял ipv6, так как провайдер его даёт, а увидев что у меня все девайсы будут прямиком в сеть смотреть, тут же погасил.
Это надо долго тренироваться, чтобы так суметь.
Если хотите рассказать о смотрящих в инет IoT устройствах, начните с того, как потенциальный хакер узнает их IPv6 адрес.
Штука в том, что такой пакет скорее всего окажется отфильтрован интернет-провайдером, так как он не поймёт куда его роутить (но зато сам интернет-провайдер может отправить такой пакет если захочет, это да)
add deny all from any to 10.0.0.0/8 via ${external_face}
add deny all from any to 172.16.0.0/12 via ${external_face}
add deny all from any to 192.168.0.0/24 via ${external_face}
И вроде как этих трёх строчек было достаточно, чтобы не работать шлюзом в обратную сторону.
какой резон условному провайдеру переходить на IPv6 без NAT если это создает проблемы его пользователям?
Если бы провайдерам было дело до пользователей, то они бы не воевали с контентом играясь с приоритетами трафика или даже грубо его подменяя. Вероятно внедрение HTTPS это результат того, что многие пытались стрясти с гугла денег и подменяли рекламу.
Подмена адреса вещь не бесплатная, она требует памяти с низким временем доступа(SRAM желательно). Так же приходится пересчитывать TCP/UDP чек-суммы, ну и чек-суммы самого IPv4. Всё это требует операций процессора(или ASIC), который стоит денег. И электричества, тепло от которого нужно отводить. В этом смысле IPv6 маршрутизировать дешевле. А, чтобы вирусня не плодилась, обычно достаточно фильтра на порты 0-1024. Некоторые даже пытаются продать услугу по снятию данного фильтра.
что NAT не нужен, но на самом деле нужен.Не знаю, с чего такой вывод. Мне NAT ни разу не понадобился там, где я разворачивал IPv6.
Вот только NAT хоть как-то эту кривизну прикрывает. И переход на IPv6 без NAT эту заплатку сорвет.Нет, не прикрывает. И нет, не сорвёт. Брутфорсить адрес лампочки в /64 будете до конца дней своих. А если вектор атаки предполагает его априорное знание, то вот тут уж точно протокол ни при чём.
А если вектор атаки предполагает его априорное знание, то вот тут уж точно протокол ни при чём.Комментарии не читаем? Я же уже писал, проблема не в протоколе, проблема в том, что есть туча девайсов, которым прямо противопоказано торчать в публичную сеть. В сетях IPv4 с NAT сейчас это не проблема, в сетях IPv6 без NAT это станет проблемой.
В сетях v6 работает файрвол (как собственно и в v4), который по умолчанию дропает пакеты до любого устройства сети. NAT это костыль, а не средство безопасности.
В чём тогда преимущество v6 для домохозяйства? :)
По сравнению с v4, ничего, кроме того, что на конкретное устройство можно обратиться откуда угодно, а не только из локальной сети. Естественно работать это будет при разрешающем правиле файрвола на пограничном устройстве и на самом устройстве (если поддерживает). P2P соединения наконец-то будут прямыми.
То есть лишь незначительные плюсы по сравнению с пробросом порта на NAT с v4 — типа порт стандартный, а не свободный на роутере? Если как-то решить проблему нечеловеческих адресов.
Неудивительно, что переход затянулся несколько...
А с v6 адреса запоминать )
Проброс ещё неудобен тем, что когда транзитных узлов несколько (роутер-десктоп-виртуалка), то нужно либо настраивать делегацию внутренних IPv4-сетей, либо пробрасывать порты по цепочке. А в IPv6 можно тупо свалить всё в один бридж LAN (где домашняя /64), и оно будет работать.
Он не для этого придуман и не для этого должен использоватьсяМы как будто на разных языках говорим. Я тут нигде не утверждал, что NAT — это хорошее средство безопасности. Я утверждал, что несмотря на то что функцию защиты он выполняет хреново, он все-таки используется в таком качестве, это объективный факт. И нельзя просто так взять и выкинуть этот элемент и не заменить чем-нибудь. Да, фаерволл — это ровно то что нужно, но блин, есть уже 100500 девайсов, на которых этот фаерволл настроен никак, либо вообще не настраивается.
В грамотно спроектированной сети фаерволлом должен быть именно фаерволл, и ничто другое.Да никто тут не утверждал, что в грамотно спроектированных сетях могут быть проблемы с IPv6, вот только основные потребители контента в интернете — это человеки, которые сидят из дома через SOHO роутеры. И вот 99.99% пользователей SOHO роутеров вообще не задумываются о каком-либо проектировании домашней сети.
И он, естественно, будет в v6-capable маршрутизаторах, с чего вы взяли обратное?С того, что уже есть на рынке? Нет, в светлом будущем конечно все это будет учтено. Но вот что делать с оборудованием, которое есть сейчас у домохозяек?
Уже достаточно давно продаются v6-capable роутеры, у которых файерволла для v6 нет. То есть файерволл в v6 — это не естественно, это воля вендора должна быть добавить его, да и UI понятным каждой домохозяйки и/или девайсами/софтами "пробивающими" его изнутри.
А можно конкретные примеры таких, для общего развития и составления списка «плохих» роутеров?
Увы, не вспомню, это в отзывах было, когда последний раз роутер выбирал. Хотя v6 в ближайшем времени не светит, но захотел выбрать с поддержкой и столкнулся с таким понятием как "минимальная поддержка", когда роутер работает как тупой маршрутизатор без возможности что-то где-то подтюнить. Где-то чуть больше, где-то чуть меньше, но в отзывах было "не берите для в6 — открывает всю сеть наружу"
То, что в IPv6-случае этой защищённости по умолчанию не будет и потребуются лишние телодвижения, чтобы включить фаерволл — это конечно же никак не является преимуществом IPv6.
Если у вас «достаточная защищённость домашней сети» состоит в единственном правиле, запрещающем на входе всё, чего нет в таблице трансляции — ну и флаг в руки. В реальной жизни всё чуть сложнее — кому-то надо порты пробросить, кому-то заблокировать надоедливую баннерную сеть и так далее. Файрволл необходим в любом случае.
А понадеявшись на всемогущий NAT, можете обломаться, когда какой-то умник пробьёт его через hole punching.
Ну да, допустим, теоретически могут быть умники, которые могут найти дыру в NAT и причинить какой-то ущерб. Но если вероятность испытать это на себе меньше, чем попасть под трамвай, то защищаться от такой угрозы бессмысленно.
Это как вместо заваривания лишней входной двери в квартире прикрыть её огромным тяжёлым шкафом — почти всегда будет работать, но это не является предназачением шкафа, хотя и частично даёт желаемый результат в качестве побочного эффекта. А ещё удобно ведь, шкафом умеет пользоваться больше людей, чем сварочным аппаратом, да и полочки есть.
Я не согласен, что при этом получается ложное впечатление безопасности, так как те угрозы, которые остаются, требуют большого сочетания факторов для их эксплуатации и, соответственно, уже несущественны на фоне более вероятных угроз. То есть, безопасность от NAT — адекватная.
То, что якобы кто-то хотел чтобы NAT использовали для одного, а эти мерзкие людишки приспособили его для другого — это не объективная претензия. Пользователи не видят в этом никакой проблемы и вообще им не важно то, что с точки зрения некоторых это философски неверно устроено где-то внутри.
Если NAT выключить, то фаервол останется.
Другой вопрос насколько адекватно он настроен, но в openwrt/ddwrt в этим всё хорошо — пользователь может не разбираться в сетях совсем, и получить адекватный набор правил, который не будет ему мешать, и при этом не давать злоумышленнику подключиться снаружи. Возможно, что в современных прошивках от вендоров тоже всё неплохо, но я давно не проверял.
Брутфорсить адрес лампочки в /64 будете до конца дней своих
а если не брутфорсить, а сниффить?
NAT is not a security feature.
Серьёзно. Закрывать лампочки от внешнего мира — не задача NAT, и он её не решает совершенно. Какой-нибудь вполне нередкий full-cone и весь интернет сможет увидеть голый сокет вашей лампочки, радостно свисающий наружу. Закрывать должен (и закрывает) фаервол, желательно stateful. Точка.
Кроме того достаточно дико выглядит сама идея найти ваши лампочки даже в условной /64, которую получит их сегмент сети в вашем жилище. Это просто охренеть, не встать, сколько адресов нужно перебрать при условии случайного распределения ip адресов девайсов в подсети.
Единственное применение (впрочем кажущееся мне весьма востребованным в теории) — избавление от необходимости менять всю адресацию в инфраструктуре абстрактной фирмы при смене оператора. Потому что PI всем получать — маразм, а пиринг с каждым ООО "Вектор" провайдеры откажутся поднимать.
А чем принципиально сеть небольшой компании отличается от домашней?
Серьёзно. Закрывать лампочки от внешнего мира — не задача NAT, и он её не решает совершенно.Да, я прекрасно понимаю, что для защиты нужно использовать файервол, а не NAT. Да, защита — это не задача NAT, но он её, по факту, решает для очень большой прослойки пользователей. Да, решает хреново. Да, это адский костыль. Но он, блин, хоть как-то, но работает. Нельзя просто так взять и выкинуть костыль не заменив его чем-то.
Можно сколь угодно долго разглагольствовать как правильно настраивать домашнюю сеть. Вот только типичный пользователь не будет этим заниматься, не будет этим заниматься и «домашний мастер за 500р в час». Если просто взять и выкинуть NAT и сказать всем «настраивайте firewall», то получится как сейчас в Москве с масками, когда люди носят одноразовые маски по несколько недель тем самым только хуже себе делая.
Я надеюсь за 2 года вы передумали. NAT ничего толком не решает. NAT просто позволяет через один адрес принимать входящие подключения для кучи адресов. Если вы выкидываете NAT, то просто теперь вместо ресурсоёмкой операции NAT (нужно кучу всего хранить в таблицах, нужно изменять проходящие пакеты) просто запрещаете все входящие на устройство по умолчанию. Теперь всё, что вам нужно делать, запоминать, что есть сессия TCP и разрешать входящие пакеты для неё, ровно тоже, что вам нужно делать при NAT, только без модификации пакетов. А чтобы разрешить доступ извне теперь не нужно делать проброс портов, вы просто разрешаете прохождение пакетов на нужный адрес и порт.
Для меня IPv4 как Internet Explorer недавно. Вроде бы и нафиг не нужен, но всё равно на него надо было рассчитывать и усложнять код, добавлять костыли.
Если вы выкидываете NAT, то просто теперь вместо ресурсоёмкой операции NAT (нужно кучу всего хранить в таблицах, нужно изменять проходящие пакеты)
Теперь всё, что вам нужно делать, запоминать, что есть сессия TCP и разрешать входящие пакеты для неё, ровно тоже, что вам нужно делать при NAT, только без модификации пакетов
то есть всё-таки таблица conntrack никуда не девается, лишь становится жирнее (а, значит, операции с ней медленнее).
А в честь чего она будет жирнее? Количество записей в ней не изменится, разве что размер записи немного вырастет из-за длины адреса. Зато отпадает надобность в NAT и со всем, что с ним связано. Просто проверили реквизиты пакета, убедились, что ему можно проходить и отправили дальше в таком же виде, в каком он есть.
Количество записей в ней не изменится, разве что размер записи немного вырастет из-за длины адреса
в том то и дело, что адрес растёт в 4 раза, так что и записи растут не немного. что в conntrack, что в таблицах маршрутизации.
Зато отпадает надобность в NAT и со всем, что с ним связано
ещё раз: чем всем? таблица conntrack остаётся. убирается изменение нескольких байт в заголовке пакета.
в том то и дело, что адрес растёт в 4 раза, так что и записи растут не немного. что в conntrack, что в таблицах маршрутизации.
Для домашнего маршрутизатора большая таблица вообще не проблема. Оперативка нынче дёшева.
А вот на глобальном уровне таблицы маршрутизации для IPv6 легче, потому что там не надо свободные блоки адресов перекидывать из региона в регион. Каждый регион имеет огромный запас адресов, а если ему будет мало, может получить ещё один огромный запас и займёт это ровно одну запись. Нашёл, что IPv4 адреса уже на блоки /26 кромсают. И все эти блоки должны глобально маршрутизироваться.
ещё раз: чем всем? таблица conntrack остаётся. убирается изменение нескольких байт в заголовке пакета.
Отслеживать соединения нужно только для устройств, которые вы защищаете этим своим внешним файерволом. Для всех остальных пакеты ходят свободно и ничего отслеживать вообще не нужно. Ну и для NAT тоже нужно время извлечь информацию о получателе, исправить это всё в заголовке пакета и уже потом его отправлять.
Ну и не забываем о постоянно растущей стоимости IPv4 адресов ввиду их исчерпания.
А вот на глобальном уровне таблицы маршрутизации для IPv6 легче, потому что там не надо свободные блоки адресов перекидывать из региона в регион. Каждый регион имеет огромный запас адресов,
«похожесть» адресов внутри региона что-то меняет? роутинг же строится не географически, а по связности в bgp.
роутинг же строится не географически, а по связности в bgp.
Региональным регистратором выдаётся сеть /32. Т.е. теперь у провайдера для 65536 клиентов будет одна запись в глобальной таблице маршрутизации. Но оператор, скорее всего, не выдаст /48, а выдаст /56, т.е. этого хватит на 256*65536 клиентов, каждый из которых сможет себе организовать до 256 сетей. Например, так делает Ростелеком для домашних пользователей (но при этом отказывается, что у него вообще в рабочем состоянии IPv6 и не принимает заявки на исправление косяков).
А сколько при этом записей IPv4 в нашинкованной адресации для того же количества пользователей? Ещё и часть клиентов приходится под NAT провайдерский загонять, иначе не хватит адресов. Для клиента это вообще двойной NAT.
Да не работает оно так. Провайдеру нужен блок адресов на город/в датацентр/etc — он его получает. И пропихивает в bgp, так как нужна связность. В bgp уже сейчас полно сетей /48.
И так как сетей /48 (и даже /32) в ipv6 потенциально может быть очень много, скоро full view ipv6 станет намного жирнее, чем ipv4.
Это действительно странно, пробрасывать в bgp сеть, которая должна отдаваться для одного клиента. Также странно, как отдавать сеть /30 в IPv4. Тут могу сказать одно, либо что-то я не так понял, либо те, кто так пробрасывает.
так клиенту зачастую отдаётся /64, так что сети /48 вполне достаточно для небольшого провайдера или дц.
и дело даже не в этом.
речь про то, что одна as — это минимум одна запись в bgp, переход на ipv6 никак количество as не снизит, так что с чего ожидать снижения числа записей в bgp?
взял городской провайдер вместо сети /20 ipv4 сеть /32 ipv6, это ровно та же одна запись в bgp.
Если бы глобальный раутинг был хоть как-то региональным — типа, вот эти вот адреса в Калифорнии, а эти в Тверской области — это было бы правдой.
Но сейчас глобальный раутинг на основе BGP с AS никак не соответствует этим ограничениям, и чтобы его загнать в нужное прокрустово ложе, нужны законодательные меры по всему миру (чего не будет).
честно говоря, не очень понимаю как оно может работать.
вот условный мегафон поднял линк на условном ix в амстердаме. сегодня понятно — в bgp появляются линки между as мегафона и as участников ix, трафик начинает бегать.
как оно может работать в случае с географическим роутингом? все линки на уровне государств, а не компаний? и то же самое с линками между городами, всё централизовано? хрень какая-то, не взлетит )
ещё раз: чем всем?Например расходом дорогущей SRAM на хранение conntrack в маршрутизаторе. С чего собственно сотовые операторы в США в направлении IPv6 зашевелились? Просто ценник железа способного переварить необходимое количество сессий стал негуманным. И NAT в их случае не масштабируется втыканием нескольких дешёвых железок.
Зачем в индексе хранить всю длину адреса, мы ведь адреса не по одной штуке маршрутизируем?
смотрю на https://github.com/torvalds/linux/blob/master/include/net/ip6_fib.h
насколько я понимаю, везде, где нужен адрес с маской, используется структура
struct rt6key {
struct in6_addr addr;
int plen;
};Просто ценник железа способного переварить необходимое количество сессий стал негуманным
ой ли. у провайдеров используется cgnat без conntrack.
вот пример реализации на линуксе:
https://github.com/andrsharaev/xt_NAT
It allows to have 40Gbps NAT on commodity servers like 2*Xeon E5-2698 v3 @ 2.30GHz (2 x 16 Cores) with Intel X710/XL710/X540 10G adapters.
на старом дешёвом x86 сервере натили 40 гигабит.
Может я чего-то не знаю, но conntrack это же часть NAT?
При тупом форвардинге пакетов оно разве требуется?
А ведь и IPv6 и SLAAC придумывались и для того, чтобы не нужно было вообще требовать какую-то фильтрацию на входе.
Но реализация на чистом security by obscurity, похоже, проваливается.
Кроме того достаточно дико выглядит сама идея найти ваши лампочки даже в условной /64, которую получит их сегмент сети в вашем жилище. Это просто охренеть, не встать, сколько адресов нужно перебрать при условии случайного распределения ip адресов девайсов в подсети.
Очень даже не дико. И даже уже находили способ найти устройства.
https://habr.com/ru/post/276831/
dhcp6 не нужен, но он есть.
nat6 не нужен, но иногда нужен (и опять же он есть).
так что стало проще?
dhcp6 не нужен, но он есть.
Он не нужен для домашней сетки, но может понадобиться для сети предприятия. Там кроме выдачи IP адресов и DNS есть ещё куча возможностей. Например, можно объявить адрес TFTP сервера и указать образ для загрузки по сети.
nat6 не нужен, но иногда нужен (и опять же он есть).
Протокол спроектирован таким образом, что при соблюдении рекомендаций из RFC такая штука как NAT не нужна. Она просто будет сжирать ресурсы узла. А зачем, если этого можно избежать просто правильно спроектировав сеть? Но если у вас есть пистолет, то это ваше дело, стрелять себе в ногу или не стрелять.
Он не нужен для домашней сетки, но может понадобиться для сети предприятия
ну то есть вы подтверждаете мои слова: хотели избавиться от dhcp, в результате не вышло.
и да, у эр-телекома, например, и домашний ipv6 выдаётся через dhcpv6.
Протокол спроектирован таким образом, что при соблюдении рекомендаций из RFC такая штука как NAT не нужна. Она просто будет сжирать ресурсы узла. А зачем, если этого можно избежать просто правильно спроектировав сеть?
ну расскажите мне, как без nat пустить часть трафика на одного провайдера, а часть — на другого (или, для реалий рф, в vpn)
ну то есть вы подтверждаете мои слова: хотели избавиться от dhcp, в результате не вышло.
Он стал опционален. Маршрутизатор без него справится! Но если тебе нужен контроль над сетью, то можешь поднять сервис DHCP. Да и когда маршрутизатор делает RA, то зачем забивать сообщение ненужной для большинства узлов информацией. В DHCP много параметров можно добавить.
ну расскажите мне, как без nat пустить часть трафика на одного провайдера, а часть — на другого (или, для реалий рф, в vpn)
Вот тут просто с ходу не подскажу. Я не знаком так глубоко с IPv6. Но, вроде, есть механизмы, когда IP пакеты от одного узла могут идти разными путями. Позвольте уже тут вас попросить погуглить. У меня просто не было соответствующих кейсов.
Но, вроде, есть механизмы, когда IP пакеты от одного узла могут идти разными путями
а причём тут пути?
в случае с nat с каким src ip пойдёт пакет определяет роутер, соответственно вся логика выбора апстрима (выборочная маршрутизация, файловер, балансировка) лежит на нём.
в случае же без nat с каким src ip уйдёт пакет — с таким он и будет путешествовать по интернету, логику выбора придётся тащить на клиента.
в случае с nat с каким src ip пойдёт пакет определяет роутер, соответственно вся логика выбора апстрима (выборочная маршрутизация, файловер, балансировка) лежит на нём.
Ну добавь второй белый IP на машину и отправляй ответы с нужного. Ну или, для извращения, меняй IP по алгоритму на шлюзе - серый/белый, если уж так хочется менять адреса. Есть реальный пример, где нужно сделать? Там будет проще варианты придумать.
Ну добавь второй белый IP на машину и отправляй ответы с нужного
только это придётся делать на каждой машине, со всем зоопарком ос (включая всякие пылесосы, которые после очередной выгрузки ркн могут потерять доступ к своим серверам).
Есть реальный пример, где нужно сделать? Там будет проще варианты придумать.
так я вроде описал:
a. есть два (или более) провайдера, требуется сделать балансировку/файловер;
b. есть заблокированные в РФ сайты; есть сайты, которые блокируют клиентов из РФ. трафик до этих сайтов требуется перенаправить в vpn.
с помощью nat на роутере и первая, и вторая задача легко решаются.
RFC4191 и RFC3775 вам в помощь.
Провайдер не поддерживает ipv6. Настроил tunnelbroker. В итоге за 9 суток 678Гб общего трафика, из них 492Гб по ipv6..
Вся проблема, что IPv6 гемор ещё больший для правительства, чем интернет. Его и так тяжело контролировать. Даже в IPv4 списки блокировки убивают оборудование… с IPv6 будет ещё хуже. Видимо поэтому, найти провайдера с нативной поддержкой IPv6 просто нереально. А даже если и нашёл в своём городе (для примера, Новосибирск), то не факт, что он у тебя в доме услуги предоставляет. Максимум через партнёров, которые хотя бы статический IP выдают бесплатно, так что можно юзать хотя бы 6to4.
P.S. А в импортозамещённом оборудовании от того же местного Eltex поддержки IPv6 нет даже в прошивке, несмотря на то, что 802.11ac присутствует (оборудование не совсем древнее).
Дополнение из будущего. Железка от Eltex всё-таки сдохола. Заменили её на Sercomm. Там поддержка IPv6 есть. И, о чудо, включив нативный IPv6 я обнаружил, что он на Ростелекоме работает, выдают сеть /56. Но радость была недолгой. Оказалось, что все входящие соединения чем-то блокируются. Т.е. даже имея белый IPv6 адрес вы не сможете получить соединение для аудио/видеозвонков, торрентов, а Wireguard работать не будет. Кроме этого, даже не смотря на заказанный белый IPv4, префикс IPv6 выдаётся динамически. Пользы от такого IPv6 мало, но на сайты ходить можно.
Позже проверил в другом регионе с маршрутизатором Asus. Там есть возможность отключить брандмауэр или создать разрешающие правила. Однако, там тоже входящие не проходят, блокируются оператором.
В поддержку обращаться бесполезно. Сказали, мол мы вообще рекомендуем нашим инсталляторам отключать поддержку IPv6. Так что, мол считайте, что поддержки этой нет, а если и есть, то пользуйтесь тем, что есть.
А ещё случайно протестировал глюк биллинга. Забыл заплатить за интернет и не сразу понял, что интернет отключили, т.к. соединение IPv6 продолжало работать как ни в чём не бывало. Для того же Youtube вполне достаточно. За одно выяснил, что большинство отечественных сайтов не имеет IPv6 адреса, в том числе и Хабр. Как-то странно для IT-ресурса!
Я вот знаю, что у меня есть условно дача, которая торчит во внешку по ХХХ.ХХХ.ХХХ.ХХХ на домене subdomain1.domain.xyz, есть квартира по YYY.YYY.YYY.YYY, которая торчит по subdomain2.domain.xyz, где «левые» устройства получают по dhcp адреса в локалке 100-200, «местные» висят 0-100 у них порты такие-то, апи такое-то. Что-то не торчит во внешку, зачем телевизору например внешний адрес — неясно. Насколько я понимаю, если провайдер будет выделять v6, то это будет /64 или /32 (просто вдумайтесь), с малозапоминаемым общим «префиском» адреса, а еще внутренние «суффиксы», да все это в 16-ричке.
Ну и цена, совместимость конечно, если забыть про вышенаписанное.
Если для видео будет использоваться RTSP, то понадобятся нетривиальные костыли (PAT, ALG) на том устройстве, которое делает NAT. Это усложняет отладку.
Что, к слову, является камнем в огород разработчиков протокола. RTSP, FTP, SIP, вот это вот всё великолепие, в котором разработчики грубейшим образом нарушили принцип уровней стека протоколов. Ну не должен application layer ничего про ip адреса из ip layer знать в принципе, иначе вот такие костыли как ALG и будут необходимы.
А вот ни RTSP ни остальные не заведутся без ALG, потому что идиотия стандарта предписывает делать соединения с адресом, который в application level положен, пофиг что там и откуда сетевой стек получил.
Просто модель OSI это далеко не универсальная концепция. Вот DHCP к какому уровню принадлежит?
Ещё раз: DNS это протокол-справочник. Вы запрашиваете у сервера какое-то абстрактное значение по ключу. Это может быть какой-то ip, это может быть почтовый адрес, просто строка, да что угодно. Вы спросили значение, вам прислали ответ. Ответ вам присылают не на какой-то там ip адрес, указанный в application level запроса, а на ip тот адрес, который увидел сетевой стек ОС. Тут не нарушается никакая вложенность слоёв стека. Содержимое — просто какое-то содержимое, оно не влияет на выбор адреса назначения, маршрута и исходящего интерфейса.
В плохом протоколе для ответа используют не тот адрес, который увидел сетевой стек ОС в поле адреса источника, а тот адрес, что вам прислали внутри application level. И это совершенно, абсолютно неправильно. В нормальной ситуации приложение, использующее для запроса открытый через системный вызов сокет, понятия не имеет о том, какой в итоге маршрут
(а следовательно и src ip адрес) будет позже выбран сетевым стеком системы. Поэтому и нарушаются базовые принципы разделения уровней стека — приложение должно знать какой
адрес позже будет выбран системой (я уже молчу о том, что адрес может в процессе передачи пакета по сети попросту поменяться). Да в конце концов в таком протоколе может быть прописано вообще что угодно совершенно умышленно.
Если вы разницы не видите, то пардон, мы с вами общего языка не найдём.
ЗЫ: DHCP — вполне себе application level. Да, он, казалось бы, знает мак интерфейса, но протокол предполагает жесткую привязку каждого инстанса к конкретному интерфейсу и работу только в пределах широковещательного домена. Поэтому мы точно можем определить какой мак взять.
DNS-сервер за NAT работать не может вообще.
Тогда как у меня домены жили пять лет, если оба DNS-а торчали за NATом и на них было установлен тупой проброс 53/udp?
Да потому что нельзя просто так взять и внедрить в провайдере этот в6, даже в 2020.
Первое. Надо перестроить сеть на vlan per user. По сути это же доступно и с pppoe, но те кто на нём до сих пор точно уж в6 делать не будут. L3 connected невозможен, не получится полисить. Нужна именно прямая видимость. Отсюда возникает проблема резервирования, всё что легко и просто делалось банальным ospf превращается во всякие vpls multihomed, что на порядок сложней. Это реально проблема — ни кадров, ни желания.
Второе. Нужно найти вменяемый брас, который сделает нормальный дуалстек. По dot1q second any динамически поднимет сессии. ASR в пролете, софтовые BNG коих тысячи тазов там же. Это умеют mx и говорят нокии. Плюс там же неплохо бы иметь поддержку cgnat, ну и в идеале еще и жить без крашей раз в две недели. Это реально проблема — решения, адекватного, подходящего тысяче и одной региональных просто нет.
Третье. Нужна нормальная поддержка на абонентских CPE, тех самых которые лежат в магазине DNS. До сих пор многие домашние роутеры не могут внятно осиливать мальтикасты, хотя им уже сто лет в обед. А с прозрачным пропуском или ределегацией префиксов на оконечки всё более чем плохо. Сюда же занесем все оконечки, заодно, там тоже то одно не работает, то другое, то патч ставить надо.
Четвертое. Реальной проблемы с в4 и нет. Адреса прекрасно покупаются или арендуются. Единственный вопрос это геолокация, максмайнд не обновляет своевременно инфу даже если дергать. Стоимость покупки/аренды ниже стоимости перестройки сетей.
Пятое. Маршрутов на в6 в фул вью после его "полного запуска" будет больше чем сейчас с повальным /24 из каждого угла. Это потребует еще и апгрейды опорных PE.
Шестое. В6 слишком долго делает му-му. Интерес в нем во всем железе выглядит как "сделаем для галочки". Чтобы сидеть именно на этом стандарте нужно реально централизованно убит в4, но мы все понимаем какие это потери бабла, поэтому этого не будет. Всякие мягкие переходы тоже не решают вопрос. Нужно что-то реально существенное доя стимуляции. Или нужен в7, разработанный с учетом косяков в6 и не имеющий вариации механизмов, однозначно прописанный.
В ipv6 еще круче. На каждого LIR выдаем /32, на каждого клиента /48. Это уже по определению большее количество в FV. В разделе, вообще, говориться о планировании выдачи, а не о фактических маршрутах. Т.е. лир вам выдаст всё агрегировано, но анонсировать вы всё равно будете от имени своей as, а потом вам нужно будет еще один префикс и вы его купите у другого лира, ну просто потому что так случится, он вообще не обязан быть вашим апстримом.
В общем, мне тяжело объяснить, но относительно ripe-707 вы спутали «выделение» и «маршрутизацию».
С другой стороны, если тупо посчитать пропорцию, то когда все 68653 AS проанонсируют свой единственный префикс, которого им должно хватить на всю жизнь, то маршрутов будет всего-лишь ~300k.
(сейчас 68653 as анонсируют 840k ipv4; сейчас 19956 as анонсируют 90k ipv6)
Согласен абсолютно, нужен именно v7/v8, который будет предлагать плавный апгрейд, а не революцию во всем мире сразу. Уже обсуждали в другой теме месяц назад. Или вообще забить на это все, раз IPv4 живет себе и живет.
Мне кажется, мы с вами уже спорили в другой теме… Плавный — это когда не меняется НИЧЕГО, кроме длины адреса. Никаких новых сетевых архитектур, маршрутизаций, просто другой формат пакета и DHCP научается выдавать два адреса — новый и старый. Все остальное — как было. И транслирующий НАТ из коробки, и просто все всегда само работает.
В идеале — я как консьюмер покупаю роутер, он автоматом включает НАТ и раздает IPv6 внутри, если может — берет IPv6 снаружи, нет — транслирует в v4.
А это единственно разумный путь — IPv4++. А "полноценный" IPv6 вообще похоронить.
Нет. IPv4 сделан немодульным и костыльным. IPv6 приносит нам множество вещей, которые наконец решили сделать правильно:
- Extension Headers (да, тот самый IPv6++).
- Хорошо сделанные мультикасты. В IPv6 мультикаст — это first-class citizen, он работает всегда и весь протокол проектировали с учётом его наличия.
- NDP вместо ARP. ARP был прибит костылями сбоку, гадил в broadcast и был уязвим. NDP — встроен в ядро стека IPv6 и спроектирован с учётом ошибок IPv4.
И это я ещё ничего не сказал про очевидные вещи, типа NAT, расширения диапазона адресов и прочего.
Как ни встраивай нативно мультикаст в ipv6, всё равно на типичном и не сильно умном l2 железе это добро будет радостно рассылаться широковещательно и лететь на каждый хост в широковещательном домене. Ну отбросили вы полученный пакет чуть пораньше, увидев, ещё на уровне разборки ip-адреса, что этот мультикаст не вам, и что? Профит в реальности достаточно призрачный.
А с NAT что не так? NAT 1:1 один чёрт нужен для ряда ситуаций. Историй боли и простоев работы от изменения адресации на всей инфраструктуре из-за
смены провайдера и при отсутствии PI адресов я видел уже немало.
Никто не мешает для каких-то случаев сделать NATv6 и применить unique-local адреса. В локальной сети организации, если нет PI-диапазона, то почему бы и нет. v6 можно настроить так же, как и v4 и концептуально ничего не поменяется.
Просто это необязательно, и по умолчанию применяется более простая схема: всем раздать глобальные адреса. В такой схеме и провайдеру не нужен NAT, и на CPE он тоже не нужен.
В локальной сети организации, если нет PI-диапазона, то почему бы и нет. v6 можно настроить так же, как и v4 и концептуально ничего не поменяется.
Но вот когда просишь помощи настроить v6 аналогично имеющемуся v4, то, обычно, на форумах и прочих QA ресурсах тебе объясняют "тебе это не нужно". Хорошо если в вежливой форме, а не в условно нормальной для лора.
В локальной сети организации, если нет PI-диапазона
со временем PI-диапазонов будет примерно столько же, сколько сейчас IPv4-адресов. Выдержит ли BGP?
Никаких новых сетевых архитектур, маршрутизаций, просто другой формат пакетаТо есть вы предлагаете продолжать тащить за собой легаси из всех косяков старого протокола, к которым вы уже настолько привыкли, что считаете их частью архитектуры… То есть как-то обойтись без SLAAC, RDNSS и DAD, которые значительно облегчают автонастройку узла?
DHCP научается выдавать два адреса — новый и старыйТак он и сейчас это умеет.
нет — транслирует в v4А расскажите, как транслировать IP пакеты, у которых адреса назначения и источника имеют разную длину?
Такое ощущение, что ваше решение даже для простых кейсов намного сложнее, чем IPv6.
Да, потому что все эти "косяки" реально используются в продакшене, и их замена обойдется дороже эксплуатации.
Транслировать — как обычный NAT, просто некоторые порты будут вести на локальные хосты IPv6. Адрес назначения будет заменяться на эквивалентный IPv4 (резолвиться и заменяться). Если эквивалента нет, извините, работать не будет.
И да, решение вполне может быть сложнее, зато проще во внедрении.
Например, у меня есть 128-битный адрес, и у вас тоже есть 128-битный адрес, но между нами есть провайдер, который умеет только 32-битные адреса.
В обратную сторону проблема уже хоть как-то решена в IPv6, есть NAT64 и DNS64 и даже 464XLAT.
Придумать некий способ энкапсуляции пакетов в этом случае. Да, это будут костыли — но любая миграция состоит из костылей, и только так можно что-то вообще сделать.
А можно сидеть на ж… ровно и стенать, когда же будет внедрен IPv6. Никогда.
Мы проверили за 20 лет, что стоимость внедрения IPv6 запредельно высока. Мы 20 лет пытаемся мигрировать и не можем. Может быть, пойти каким-то другим путем?
Я вот так сказал бы, что dualstack как раз зло. Самое простое — делать в6 онли, и нат в в4 на границе. Да, вроде криво, но тогда есть резон вылизывать внутр сеть
А зачем во внутренней ipv6? Если мои провайдеры начнут раздавать v6, то сначала я начну копать в сторону как условные 192.168.0.128/25 замапить в выданные провайдером /64 как /249, а остальное до лампочки. Ну, пока не понадобится каждой лампочек внешний адрес выдать :) И то, на это и в4 хватит
Если добавить в эту схему пару NATов (скажем, один в wi-fi роутере пользователя, другой у мобильного оператора), то реализовать её будет гораздо сложнее — придётся сооружать relay на стороне сервиса. А когда все находятся в одном общем 128-битном адресном пространстве, end-to-end connectivity обеспечивать гораздо проще.
Чтобы выключатель смог сходить в облачный сервис для конфигурации умного дома, зарегистрировать себя, потом узнать своё предназначение (например, управление лампочкой), узнать адрес лампочки и дальше ходить в лампочку напрямую.Оно и сейчас так прекрасно работает. NAT не мешает сходить выключатель в облако, не мешает он и узнать адрес лампочки, и не помешает он к этой лампочки сходить. Единственное что может пойти в этой схеме не так, это если вы разместили лампочку и выключатель в разных локальных сетях, но это достаточно специфичный кейс и он вполне себе решается взаимодействием через то самое облако.
Вы справедливо заметили, что relay через облако решает проблему, но такой подход обладает по крайней мере следующими недостатками:
1. Проблема с приватностью. Зачем внешнему сервису знать о каждом моём нажатии на выключатель?
2. Такой подход подталкивает неопытного разработчика к неправильному подходу при проектировании, когда и лампочка, и выключатель всецело доверяют сервису. Если сервис сказал лампочке «выключатель попросил тебя включить», то ей приходится верить ему.
3. Если сервис упал или даже перестал существовать, то у пользователя пропадает не только возможность менять конфигурации, но и использовать уже запрограммированное поведение в своём умном доме.
При наличии end-to-end связности между лампочками и выключателями таких проблем нет. В момент конфигурации лампочка может запомнить публичные ключи всех выключателей, которым позволено управление светом, а потом получать от них команды напрямую.
А насчёт остального:
Проблема с приватностью. Зачем внешнему сервису знать о каждом моём нажатии на выключатель?Ну если приватность — эта такая острая проблема, то к чему вообще связываться с выключателем который требует облачного сервиса для конфигурирования? Тоже самое, кстати и про ситуацию, когда этот сервис пропадает.
Такой подход подталкивает неопытного разработчика к неправильному подходу при проектировании, когда и лампочка, и выключатель всецело доверяют сервису. Если сервис сказал лампочке «выключатель попросил тебя включить», то ей приходится верить ему.Ну а подход с прямым взаимодействием лампочки и выключателя подталкивает неопытного разработчика к тому чтобы лампочка начала отдаваться любому выключателю. Неопытный разработчик в лбом случае найдёт где споткнуться, по себе знаю :)
Но в целом, согласен, даже если IPv6 и не является для подобного рода взаимодействий чем-то необходимым, то как минимум даёт больше вариантов для реализации, что хорошо. Возможно даже это как-то простимулировать производителей IoT начать думать о безопасности (хотя кого я блин обманываю, всем, кроме полутора гиков, на безопасность насрать)
V6-only core + ipv4 as a service вот прямо сейчас пока ещё имеет некоторые трудности с разворачиванием, в основном из-за всяких упущений и недоделок в мире mpls.
А почему это полисить то L3 connected не выйдет при ipv6 вдруг?
Может просто надо признать, что v6 не удался? И не терять времени на натягивание его на глобус. А потратить силы на какой-нибудь условный v8, учтя ошибки v6?
Именно так и надо поступить, плюсую. Должна быть возможность плавной миграции.
IPv4 изначально создан недостаточно расширяемым для создания плавной миграции. При его создании никто не думал, что нужно будет куда-то мигрировать с него. Проблема именно в IPv4, а не в IPv6.
Шестёрка имеет поддержку extension headers, что по сути является "плагинами" для протокола. А вот IPv4 таких штук не имеет. Пропозал есть, но пока не принят.
Значит надо принять пропоузал и его реализовать. На его основе постепенно расширить адреса. А все остальное похоронить.
И получим два формата адресов: старые/новые. И проблемы с маршрутизацией и ещё вагон проблем, с учётом того, что вспомогательные протоколы, типа тех же ARP, IGMP и прочих не поддержат новый формат адресов. Хоронить надо IPv4, а не обвешивать костылями. Он хорошо отработал, пора уступить место новому. Как IPX уступил место IPv4.
Да, получим. Но так мы хотя бы куда-нибудь перейдем, а не будем вечно планировать переход.
Не получим и не перейдем. Потому что абсолютно точно так же придется менять горы железа и софта у операторов, клиентская часть годами будет кое-как и с багами подтягиваться, но так и не будет работать как положено и написано в стандарте, а про проблемы с роутингом и оверхедом на операции на транзитном железе я даже думать боюсь.
Нет, серьёзно, вот на v6 стандарты разжеваны, вдоль и поперёк задокументированы и лежат в открытом доступе даже не годами, а натурально десятилетиями. И что как? Реализовано как положено везде? Нет? А почему вы считаете, что с другим стандартом будет всё иначе?
Я уверен, что если ставить своей целью лёгкость миграции, то можно сделать более простой во внедрении стандарт. Проблема IPv6, на мой взгляд, в том, что он игнорирует сложность миграции и ставит во главу угла архитектурную стройность. Результат мы наблюдаем. Если сделать даже не наоборот, а хотя бы компромиссно, мне кажется, получится куда лучше.
Посмотрите на версии TLS, на версии WiFi, на версии сотовых стандартов, как им всем удалось перейти, и не раз, а снова и снова. А тут никак.
Вы путаете горячее с холодным. Для использования TLS достаточно обновить ПО, WiFi — клиентское оборудование (захотел клиент ax — пошел купил), сотовым операторам выгодно щеголять фразой "самый быстрый интернет", а вот фраза "мы поддерживаем ipv6" это не продающая фраза, отсюда и задержка во внедрении.
Дык вы поймите, если нет продающей фразы, зачем вообще его внедрять? Если бы покупать адреса четверки было бы дорого, шестерка бы экономила деньги. Если бы шестерка упрощала реально администрирование сетей, она бы так же экономила деньги либо повышала качество. И т.д.
А получается, что вообще никаких преимуществ, измеримых финансово. А расходы реально большие. И зачем это кому бы то ни было надо?
Для успешного внедрения надо эту картинку перевернуть — получить осязаемые бонусы и снизить стоимость. Переделка стандарта — имхо один из путей к этому.
А теперь давайте подумаем сколько у нас производителей сетевого железа? Домашних роутеров? Операционных систем? Десятки? Сотни? Протоколов сколько завязано, от банальных SIP-RTSP до всяческого из мира mp-bgp и mpls?
Как вы думаете в какой ситуации нормальное внедрение всеми производителями будет проще?
В масштабе всего мира и вовлечённых отраслей разница в сложности перехода, вот честно, просто колоссальная. И у операторов дело далеко не в сложности продажи. Клиентам в основном пофигу какой-там-ай-пи-номер, ему нормальная работа связи нужна, а её по ряду причин нельзя вот так взять и гарантировать. Как минимум, оператору нужно по ряду причин ставить практически всем клиентам свои CPE и гарантировать работу до выхода трафика из этих CPE. А это значит перенастроить и обойти ногами огромную кучу пользователей. Если бы вам стандарт сотовой сети меняли с необходимостью вызова техника, не знаю даже на 2G или на 3G сейчас бы сидело большинство.
Вот-вот, во всех этих случаях специально думали об обратной совместимости! И для вайфая, что очень непросто, и для сотовых сетей, что тоже ни разу не очевидно. И да, разработчикам пришлось сложно, и может даже решение получилось не идеальным. Зато оно взлетело и работает, а не ждет внедрения.
По факту по сути оказалось, что мир уже внедрил некий самопально-костыльный аналог IPv6 — когда сеть разделяется НАТами на сегменты нужного размера. И реальной необходимости в уходе от этой схемы, за которую люди готовы платить деньгами, как-то не просматривается.
Проблема именно в IPv4, а не в IPv6.Проблема в обоих протоколах. Если рассматривать IPv6 как протокол в вакууме, то да, он хорош. Если рассматривать как протокол, который должен решить проблемы IPv4, то он хреновый, ибо процесс миграции на него слишком болезненный. Нужна именно что плавная миграция, т.е. вводить какой-нибудь IPv4.1 который будет обратно совместим с IPv4, но в котором будут необходимы механизмы для плавной миграции, дождаться когда он распространится по девайсам и софту и только после этого начинать миграцию.
Это, походу, тот самый случай, когда фичу продвинули технари, а не маркетологи.
Вроде всё есть, а не продаётся.
Моё дело стратегия? :)
А много ещё волшебных префиксов в ip v6, которые надо бы запомнить?
Запоминать их совсем не обязательно, например NAT64 обычно поднимают в паре с DNS64, чтобы github.com резолвился в 64:ff9b::8c52:7603.
Такое уже есть в NAT64
только nat64 — необязательная вещь, берёшь ipv6-only хост у какого-нибудь хетцнера, и тебе не доступны ни github.com, ни docker.io
да, есть публичные сервера nat64, но работоспособность, разумеется, никто не гарантирует.
Поднимаем транслятор на /96 префиксе
чтобы его поднять, нужен ipv4 )))
Так сделать нельзя.
Размер адреса в IPv4 прибит намертво. Причем и в куче в дополнительных протоколов вроде ARP. Причем часто — еще и в железо (а не только прошивки) сетевого оборудования.
Все это менять — проблем не меньше чем с IPv6.
Существуют и работают ARPv6, ICMPv6 и т.п.
Сетевого оборудования моложе 20 лет, не понимающего IPv6, не встречал.
Всё, как обычно, упирается в лень или некомпетентность админов.
Сетевого оборудования моложе 20 лет, не понимающего IPv6, не встречал.
а что вы понимаете под сетевым оборудованием? хост с linux считается?
берём ipv6-only хост, делаем docker pull xxx — не работает, у дефолтного docker.io нет адреса ipv6.
делаем git clone https://github.com/xxx — не работает, у гитхаба тоже нет ipv6.
или вам пример именно железки, принципиально не умеющей ipv6? да полно их, вот модель 2021 года, например:
https://sbr02.cityron.ru/nastrojki_1.htm?ms=EgYE&st=MA%3D%3D&sct=MA%3D%3D&mw=MzIw
рядом тоже пишут: https://habr.com/ru/company/vasexperts/blog/508518/#comment_21784972
а что вы понимаете под сетевым оборудованием? хост с linux считается?
Считается. Емнип, линукс научился IPv6 ещё на 2.6 ядре.
docker.io
Вы это сейчас серьёзно пытаетесь представить лень и\или некомпетентность сисдаминов как недостаток протокола?
да полно их, вот модель 2021 года, например:
Это не сетевое оборудование, это контроллер для промавтоматики. Такие вещи и не должны торчать в Интернет вообще, ни в 4-й ни в 6-й.
Это не сетевое оборудование, это контроллер для промавтоматики. Такие вещи и не должны торчать в Интернет вообще, ни в 4-й ни в 6-й.
то есть ipv4 в локалке всё-таки придётся держать? и зачем мне тогда ipv6 в локалке?
и да, полно ipv4-only устройств, которые связываются со своими серверами в интернете.
Вы это сейчас серьёзно пытаетесь представить лень и\или некомпетентность сисдаминов как недостаток протокола?
почему пытаюсь? констатирую факт.
кому нужен интернет-протокол, через который мега-популярные интернет-сервисы не работают?
для админа докер, для программиста гитхаб, для домашнего пользователя вк.
то есть ipv4 в локалке всё-таки придётся держать?
Или ipv6. Я не вижу принципиальной разницы, кроме того разве что, что в ipv6 локалка настраивается чуточку проще.
и да, полно ipv4-only устройств, которые связываются со своими серверами в интернете.
для чего-нибудь типа умного дома -- пусть связываются.
для промавтоматики, особенно критической инфраструктуры -- категорически недопустимо.
почему пытаюсь? констатирую факт. кому нужен интернет-протокол, через который мега-популярные интернет-сервисы не работают? для админа докер, для программиста гитхаб, для домашнего пользователя вк.
Факт чего? Не надо перекладывать рукожопость с больной головы на здоровую.
Ни админ ваш, ни программист, ни домашний пользователь ещё очень долго не будут вынуждены работать в v6-only окружении, а в дуалстэке работаёт всё прекрасно и так.
А некоторые сайты, которые смотрят в будущее дальше других, уже работают в v6-only (YouTube, например). Да даже на Хабре местная файлохранилка hsto.org умеет в IPv6.
для домашнего пользователя вк.
VK актуально только для России и её сателлитов.
Facebook, Instagram, Google, Wikipedia, Netflix прекрасно работают в v6-only. Миллионам пользователей Интернета большего и не нужно.
Twitch, Twitter, Amazon -- частично (CDNы у них уже на IPv6).
В общем, все идут не в ногу, один вы в ногу.
А некоторые сайты, которые смотрят в будущее дальше других, уже работают в v6-only (YouTube, например)
ну вот именно, что некоторые.
В общем, все идут не в ногу, один вы в ногу.
нет, не так. я уже писал, ложка дёгтя портит бочку мёда, относительно небольшое число неработающих через ipv6 сервисов делают сегодня ipv6-only окружение непрактичным.
давайте зайдём с другой стороны: назовите хоть один пример хоть сколько-нибудь популярного сервиса, не работающего с ipv4-only клиентами.
пока таких сервисов нет, но есть сервисы, не работающие с ipv6-only клиентами, не то что, чистый ipv6, даже dual stack не особо осмысленен.
да, дома я держу ipv6; есть и ipv6-only сервера у хостеров; но внедрять ipv6 в сети на работе пока никакого смысла не вижу.
прочитайте ещё раз тезис, вынесенный в заголовок статьи, в комментариях к которой мы общаемся.
как пишут в баге на гитхабе, It's 2022, World IPv6 Launch Day was 10 years ago. а до полного перехода на ipv6 всё так же далеко.
ну вот именно, что некоторые.
Это не просто некоторые, это, вообще-то, сайты из топ10 Интернета.
делают сегодня ipv6-only окружение непрактичным.
но есть сервисы, не работающие с ipv6-only клиентами,
Вы боретесь с выдуманной проблемой. Я не знаю никого, кто бы вынуждал сегодня кого-то работать в v6-only или хотя бы активно агитировал за такое.
прочитайте ещё раз тезис, вынесенный в заголовок статьи, в комментариях к которой мы общаемся.
Да я в курсе. Просто вы выступаете так, как будто бы в принципе против такого перехода.
Просто вы выступаете так, как будто бы в принципе против такого перехода.
скажем так, я от него не в восторге. я не вижу как ipv6 делает мою жизнь проще/приятнее.
да, он решает фундаментальную проблему дефицита ip-адресов, и да, других альтернатив у нас нет, поэтому «все там будем»; но какого-то энтузиазма внедрение ipv6 у меня не вызывает.
Я не знаю никого, кто бы вынуждал сегодня кого-то работать в v6-only или хотя бы активно агитировал за такое.
повторяю вопрос: и какой резон тогда обычному пользователю/админу настраивать в дополнение к ipv4 ещё и ipv6?
как раз в ipv6-only смысл временами уже есть (тот же hetzner сделал ipv4 платным), а dual stack по мне — способ собрать максимальное число граблей.
я не вижу как ipv6 делает мою жизнь проще/приятнее.
А я вижу. Вижу потому, что помню, что Интернет изначально задумывался, проектировался и развивался как децентрализованная отказоустойчивая сеть, в которой отказоустойчивость обеспечивается именно возможностью P2P взаимодействия на транспортном уровне, то есть возможностью связности каждого узла с каждым.
Пока дефицит адресного пространства не клюнул в попу, так оно и было -- я ещё помню такое явление как «клиентский пул» оператора, из которого белые IP адреса выдавались клиентам мобильного Интернета и клиентам dialup/pptp.
И это было хорошо. Как минимум, не надо было танцевать с бубном, сношаться со STUN/UPNP/IGDP и прочими извращениями, для того чтобы захостить у себя что-то: веб-сервер, сетевую игру, ноду p2p файлообменки, запросить помощь по rdp/ssh и так далее. Skype не гонял весь траффик через свои сервера, а работал как P2P. Gnutella 1/2 прекрасно работали без серверов вообще.
А потом всю сеть поразила раковая опухоль NAT и дурацких аргументов в пользу того, почему оторвать от узла возможность принимать входящие коннекты (вместо того, чтобы нормально настроить firewall) это очень хорошо и сесурно.
Вы просто привыкли к нынешнему положению вещей и вам оно кажется естественным. Но это не так.
И вот IPv6 это как раз то решение, которое потенциально снова может сделать Интернет тёплым и ламповым, каким он уже был когда-то.
но какого-то энтузиазма внедрение ipv6 у меня не вызывает.
Предложите более правильный вариант?
повторяю вопрос: и какой резон тогда обычному пользователю/админу настраивать в дополнение к ipv4 ещё и ipv6?
Это необходимо для осуществления плавного перехода с IPv4 на IPv6.
Сервисы, с которыми ежедневно взаимодействует пользователь или организация, смогут постепенно, контролируемо, прозрачно и незаметно для них переползать с IPv4 на IPv6, пока однажды, через сколько-то там лет, поддержка этими сервисами IPv4 не станет просто легаси, которое можно будет отключить без ущерба для большинства пользователей.
И дуалстэк нужен как раз для того, чтобы в этот момент у тех, кто всё проспал, не возникло внезапной срачки-горячки по переводу всей инфраструктуры с дедлайном на вчера.
а dual stack по мне — способ собрать максимальное число граблей.
Назовите парочку граблей, самых актуальных. Только не связанных с некомпетентностью сисадминов.
Пока дефицит адресного пространства не клюнул в попу, так оно и было — я ещё помню такое явление как «клиентский пул» оператора, из которого белые IP адреса выдавались клиентам мобильного Интернета и клиентам dialup/pptp.
гхм. у меня в квартире два оператора, оба выдают белый но динамический ipv4. один из операторов выдаёт и ipv6, разумеется, тоже белый, и, сюрприз, тоже динамический.
и да, из трёх крупных провайдеров в городе ipv6 предлагает только один.
Skype не гонял весь траффик через свои сервера, а работал как P2P
заметьте, это отлично работало и через nat тоже. а отказ от p2p был вызван ИМХО политическими, так сказать, мотивами.
современному, извините за выражение, хомячку вообще всё это безразлично: у него всё одинаково работает что через c ipv4, что с ipv6, что с nat, что без nat
Назовите парочку граблей, самых актуальных. Только не связанных с некомпетентностью сисадминов.
«назовите проблемы жигулей, не связанные с качеством сборки и качеством запчастей». да все жигули, можно сказать, состоят из этих проблем.
какое мне дело до сверкающего ipv6 в воображаемом мире? меня интересует реальный мир и реальные проблемы в нём.
Это необходимо для осуществления плавного перехода с IPv4 на IPv6.
Сервисы, с которыми ежедневно взаимодействует пользователь или организация, смогут постепенно, контролируемо, прозрачно и незаметно для них переползать с IPv4 на IPv6, пока однажды, через сколько-то там лет, поддержка этими сервисами IPv4 не станет просто легаси, которое можно будет отключить без ущерба для большинства пользователей.
анекдот про евреев, которые учились пить водку, помните? )))
гхм. у меня в квартире
Вам повезло. А в моём городе провайдеры уже давно выдают белую статику только как платную доп. услугу, запихивая обычных клиентов на серые адреса и под NAT. И хорошо, если только один.
А нативный IPv6 дают может 3 или 4 из нескольких десятков.
заметьте, это отлично работало и через nat тоже.
Как Скайп "отлично" работал, не надо мне рассказывать, я ещё помню.
а отказ от p2p был вызван ИМХО политическими, так сказать, мотивами.
А вы можете это чем-то подтвердить?
Потому что мне ситуация видится немного обратной -- проблемы, возникающие из-за трансляции адресов, закрыли просто вбухав бабла в выделенную серверную инфраструктуру потому, что Microsoft просто могла себе это позволить.
да все жигули, можно сказать, состоят из этих проблем.
В Топгире, кажется, был эпизод как жигули сдали механикам Лотуса и те сделали из неё конфетку. То есть дело таки не в жигулях, а в том что, повторяю снова, не надо считать рукожопость внедряющих недостатком протокола.
какое мне дело до сверкающего ipv6 в воображаемом мире? меня интересует реальный мир и реальные проблемы в нём.
Существенная доля этих проблем вызвана тем, что ответственные люди относятся к вопросу так же, как вы.
анекдот про евреев, которые учились пить водку
В чём ваш поинт? Что Гугл, Вики, Нетфликс и другие топы -- все дураки, ничего не понимают и перешли на v6 ради прихоти. А вот вы, проигнорировавший вопрос о более правильном пути перехода -- светоч истины. Я всё понял.
1. Персонал не обучен этому.
2. IPv6 не внедрён посвеместно, поэтому желающие его использовать прибегают к куче различных костылей (различные способы энкапсуляции IPv6 внутрь IPv4), каждый из которых требует отдельного подхода для контроля. В IPv4 проблемы ровно те же — пользователи могут натянуть оверлейную сеть поверх контролируемой и получить «децентрализованный интернет» (всякие TOR, I2P и cjdns это успешно делают). Просто с IPv6 появляется дополнительный стимул эти костыли использовать, вот и вся разница.
- В Екатеринбурге только один провайдер предоставляет ipv6 домашним пользователям (Планета), и еще Билайн может дать корпоративным.
- В России только один мобильный оператор предоставляет ipv6 (МТС)
- В гостевой сети офиса пришлось отключить ipv6 т.к. после какого-то обновления телефоны Xiaomi перестали получать (точнее присваивать себе) адрес.
- На прокси пришлось понизить приоритет v6 т.к. тоже были глюки
Переход на IPv6 может занять еще десять лет