То что вы этого не видели, это не значит что этого нет. :) Чаще всего провайдеры используют динамический CGNAT, не подразумевающий вообще входящие соединания для пользователя, соответственно уведомлять пользователя не о чем. Если же вы реализуете архитектуру с фиксированным пулом портов для пользователя, то пользователь должен его знать. В нашем случае нет необходимости сообщать CPE назначеный ему пул портов, он его знает по последним битам полученного приватного IP адреса (механизм описан в указанном мною драфте), а свой публичный адрес используемый на CGNAT - через опцию 125 DHCPv4. Использовать только предоставляемый нами CPE не обязательно, эта логика AFAIK поддерживается OpenWRT. Можно вообще обойтись без этой логики, если ваш CPE (или ваш комп с напрямую воткнутым патчордом) позволяет задать пул портов для трансляции вручную. Все исходящие соединения, которые использует порты не входящие в ваш пул просто не пройдут CGNAT. Так же, чисто для информации, ваш публичный IPv4 адрес и пул портов указаны в вашем кабинете на портале провайдера.
Я не видел провайдеров позволяющих доступ исключительно со своих CPE, хотя, судя по обсуждениям на форумах, такие есть. Чаще всего вы может заменить провайдерский CPE на свой, хотя при этом скорее всего потеряете такие фичи как телефонию и TVoIP. Ну и разумеется в случае DSL ваш CPE должен иметь (или вы должны иметь внешний ) модем, а в случае FTTH ваш провайдер должен предлагать отдельный ONT (а не только CPE с инетгрированным ONT).
Если даже решать эту проблему, получится слишком специфично у каждого провайдера, общедоступную технологию на этом не построишь.
Ну тут либо шашечки, либо ехать. Чудес не бывает, даже если найти решение. Так что согласен. Аминь.
А ну понятно, двухуровневая схема. Я про такие даже не слышал.
Простите, а какую схему вы видели? Пользователю в лучшем случае выдают 1 публичный IPv4 адрес для CPE, а не подсеть для LAN. Так что у пользователя NAPT как минимум есть, на его CPE. А если выдают приватный, чтобы потом странслировать его на CGNAT, то суть точно та же. Ну а так как мы изначально говорим про CGNAT, то вот вам вторая точка трансляции.
Это же не корпоративная сеть, где пользователи в общей сети и нужеен только один адресный транслятор на границе.
1:8, хотя в теории могло быть плотнее, зато нагрузка выносится с центральной железки на много железок моменьше.
1:8 - это результат анализа нашей собственной статистики. Даже у озабоченных гиков суммарное количество открытых соединений не превышает двух тысяч, у большинства обычных пользователей - пара сотен. Так что 8К портов на пользователя - это с запасом.
Это для фиксированного доступа. Для мобильного CGNAT 1:128 или 1:256. С учетом, что 99,9% мобильных пользователей это единственный терминал (смартофон), то 256 портов более чем хватает. Или 512.
На множестве маленьких железок у нас реализован MAP-T. Я не знаю, общая ли это ситуация или наш частный случай, но CGNAT был взят на мощном железе и стоил сильно дорого, хотя это возможно из-за кастомной логики реализующей упомянутый мной драфт. Его имело смысл централизовать, а не децентрализовывать, как MAP-T. Хотя и MAP-T, IMHO, лучше централизовать и размещать как можно ближе к пирингу, но это выбор архитекторов конкрентной сети согласно конкретным условиям.
Видеоконфа на число участников > 2 требует центральный сервер
Для большинства пользователей нужны point2ponint звонки, а не видеоконференции.
атомизировать пользователей и жёстко завязать их на свои сервера
Зачем? Наоборот! Выгодней разгрузить свои сервера, пусть пользователи сами, на своем же железе, раздают выложеные нами файлы. Всем выгода - компании нагрузка меньше, пользователю - распространение быстрее, а доступность раздаваемых файлов - выше. А еще можно самому себе проблем создать. Мне помнится как на заре iPhon'ов Apple выложил апдейт и весь мир ломанулся апгрейдиться однвременно, положив сервера Apple похлеще DDoS атаки.
Бизнес на обьеме трафика уже много лет как нет, разве что у Tier 1 провайдеров, да и то, если они ошибаюсь, они за BW берут, а не за прокаченный трафик. Так что компании в первую очередь интересно избежать наплыва пользователей и лишнего трафика.
Будут сидеть в своих p2p-сетках, IRC-чатиках (что важно - немодерируемых, а потому более привлекательных.
Некая малая часть несомненно будет, но по сравнению с аудиторией FB, VK и иже сними - это так, в размере погрешности. Основная масса не найдет в этих p2p-сетках и IRC-чатиках ни котиков, ни "лайкни, чтобы посмотреть сколько нас" и "99% людей на смогли решить 2+2x2". Большинство не слезет с дофаминовых лент ради независимого общения в чатах формата 20+-летней давности. Я тоже ностальгирую по news конференциям и фидо, но эта эпоха уже ушла.
Такое было в дремучие 00-е, когда можно было посканить локальные адреса и поломать виндовые шары своих соседей. Сейчас у провайдеров считается минимальной гигиеной не роутить локальные адреса между абонентами.
Ничего подобного. То что абоненты сидят в общей подсети еще не значит, что она в одном броадкаст-домене. Коллекторы организуются как hub&spoke и трафик между двумя абонентами одной подсети поднимается до BNG. А в этом плане без разницы какие у них адреса - приватные или публичные. В последнем случае трафик поднимется еще выше - до CGNAT. Если CGNAT находится не около BNG, а ближе к точкам пиринга, то гонять трафик через полсети - смысл?
Единственное что верно, это то, что на долю межабонентского трафика сегодня приходится лишь несколько процентов, большая часть приходится на крупные ресурсы, такие как Facebook, Youtube, видеостримеры и т.д.
Дырявый NAT делали только ради экономии 4 байт памяти на соединение
Дело не в количестве байтов на слот, а в количестве слотов. И в мощностях затрачиваемых на lookup по таблице и его скорости. Симметричный NAT позволяет минимизировать количество используемых публичных адресов, но колчество xlate будет расти экспоненциально. Но это сферические размышления в вакууме, это надо уже брать конкретный кейс с соответствующим количеством абонентов, средним количеством отрытых соединений tcp+udp на абонента, конкретное железо и смотреть какой у него рейт по трансляции.
На практике же речи о внедрении симетричного NAT не идет (даже при фантастической экономии публичных адресов), ибо слишком брутально бьет по доступной пользователю функциональности сети. Я не знаю ни одного случая его воплощения на уровне CGNAT. Только единожды на фаерволе и совсем по другим причинам, нежели экономия адресов.
Любой NAT требует.
Нет, не требует. У нас реализован CGNAT на основе драфта draft-tsou-stateless-nat44-02, что позволяет разделить каждый публичный IP адрес между несколькими абонентами (например 1:8), зафиксировав за каждым абонентом его диапазон портов tcp/udp (65К / 8 соответственно для каждого из транспортных протоколов). CPE абонента производит NAPT во внешний приватный адрес из пула RFC6598, но используя только порты из закрепленного за абонентом диапазона портов. Далее пакет роутится до CGNAT, где транслируется только приватный RFC6598 IPv4 адрес в соответствующий публичный (чистый NAT), при этом количество требуемых слотов равно 8 x количество уже задействованных публичных адресов. Это на порядки меньше, чем если бы на CGNAT был реализован NAPT.
Дополнительный плюс (а в нашем случае это обязательное условие), что при этой статической трансляции, пользователь доступен для входящих соединений (хоть и только в рамках зафиксированного за ним диапазона портов), остается только пробросить в LAN нужные порты на CPE.
Я не знаю, какие P2P гоняют типичные юзеры. Мессенджеры уже 15 лет как централизованы
В плане голосовых звонков - WhatsApp децентрализован, Telegram децентрализован, Webex, Meets - тоже. Да собственно любая SIP телефония и видеоконференции. С учетом qos интернета других вариантов нет. Microsoft Windows Update использует протокол схожий с bittorrent'ом для распространения обновлений. Есть другие.
На бумаге и YouTube не запрещён
Но о реальном положении дел все повсеместно знают и открыто говорят. Вы слышали что-нибудь о гонении на IPv6 в России? Хотя бы кулуарно? Не теории заговора и слухи, а реальные распряжения/инструкции/утечки. Я даже слухов не слышал.
Для примера Яндекс, насколько я знаю, не просто всячески внедряет IPv6, но и открывает (открывал) датацентр (в Финляндии) на IPv6-only - а это глубокий уровень освоения IPv6.
Ответ на "зачем" - "выгодно олигархам".
Ну это вообще не серьезно. VK/Facebook/Ticktok/etc. это сервисы сами в себе, люди идут к ним целенеправлено за их дофаминовым контентом, наличие/отсутствие у вас возможности одноуровневого пиринга им вообще перпендикулярно.
Свои протоколы делать слабо, а сидеть на старье и отставать от всего мира опасно
Китайцы пытаются (IPv9), но не выходит. Правда и мотивация за этим стоит совсем другая, не техническая.
Да, и забыл сказать. Если принять вашу гипотезу, то IPv6 следут вообще запретить с самого начала в отдельно взятой стране, ибо с ним вообще весь NAT исчезает. Россия может быть отстает по внедрению IPv6, но не пытается же его запретить? А если под боком есть уже существующая алтернатива, без всяких NAT и ограничений на P2P, то зачем огород городить? Да еще городить с протоколом, который исчезнет в ближайшие годы.
Я понял вашу мысль. Такая конфигурация осложнит открытие P2P соединений, но не полностью искореняет их возможность. В частности это будет работать если обе точки находятся за отдельными CGNAT, причем оба CGNAT работают в режиме симметричного NAT. Кроме того, пользователи за общим CGNAT смогут устанавливать пиринг по своим приватным адресам (а это от тысяч до десятков и даже сотен тысяч пользователей), хотя это зависит от архитектуры сети и можно запретить пользователям коммуницировать напрямую без прохождения CGNAT.
В реальности это сложно и накладно. Cимметричный NAT потребует создания слота трансляции с уникальным кортежем на каждое соединение пользователя (а это сотни одновременных соединений на кажого "пользователя" (то есть всей его LAN)), а не условно 1 слот на кажого пользователя. Соответствующие требования к ресурсам железа. Учитывая тысячи и тысячи пользователей за каждым CGNAT, а так же что в сети крупного провайдера этих CGNAT по регионам может быть десятки, учитывая необходимую избыточность, а так же запрет на пиринг по приватным адресам за общим CGNAT (то есть форсировать 100% трафика через CGNAT), лицензии, обслуживание, и и.д., то решение в итоге становится золотым. То есть на бумаге это реализовать не сложно, в реальности можно, но проблематично. И опять-таки, одно дело обязать провайдера воткнуть СОРМ от органов в разрыв сети, он для провайдера "black box", который не влияет на архитектуру и толпологию сети и провайдер его не обслуживает и за него не отвечает. Другое дело - требовать от провайдера затачивать саму архитектуру провайдерской сети под такое решение, причем за свой счет. Можно ли заставить провайдеров это реализовать? Конечно. В конце-концов можно вообще разрешить выходить в сеть только с общественного компьютера в библиотеке под запись в жернал и с логгированием всех действий пользователя (уже было, а в КНДР возможно и сегодня так), но все же давайте будем реалистами. :)
И это при том, что элементарный прокси-сервер в сети сводит на нет все усилия с симметричной трансляцией. Да, через него торрентом качать не выйдет, но пустить телефонию - не проблема от слова совсем. Да и вообще надо почитать что там нового в STUN. С RFC3489 уже много лет прошло, я не смотрел что изменилось в RFC 5389 и затем в RFC8489.
Ну и отказ от P2P технологий это серьезный удар по ряду современных сервисов в сети (помимо битторрента и мессенжеров), что будет означать создавать самим себе трудности на ровном месте для всей сети страны в целом.
Подытожу тем, что не знаю какие страны вы имеете в виду, но мне внедрение такой архитектуры кажется нерациональным даже с точки зрения параноидального Большого Брата и я о таких тенденциях не слышал.
Могут. Но для этого не нужно перестраивать существующие сети или менять связи между абонентами. В тех же точках контроля трафика установить DPI. Как решать вопрос шифрованного трафика - это другой вопрос.
Да, есть такая проблема, я с ней сталкиваюсь, и это одна из причин развертывания IPv6 во внутренних сетях провайдеров и операторов (чем пока что мало кто из них заморачивается, решая в первую очередь задачу предоставления сервиса IPv6 для клиентов). И это даже в том случае, если провайдер не использует приватные IPv4 адреса для абонентских пулов. Даже наоборот, приходится для внутренних нужд использовать пул приватных адресов зарезервированный специально для CGNAT - 100.64.0.0/10 (RFC6598) в качестве приватных адресов RFC1918.
Простите, это абсурд, идущий в противоречие с самими фундаментальными принципами сетевой архитектуры. Это не значит, что так технически нельзя сделать, но в этом попросту нет никакого смысла. Ваше подключение и так не может не проходить через того или иного провайдера лицензированного государством, а следовательно способного применить комплекс мер по идентификации и перехвату трафика. То есть если мы говорим от открытой сети, то ваша "прямая" связь между абонентами будет так или иначе проходить через точки контроля трафика у одного или нескольких провайдеров.
Можно, конечно, говорить о прямых физических соединениях (радио, лазером, голубями, флажками), но это смехотворный масштаб, который не может рассматриваться даже параноидальным государством как угроза требующая контроля.
А сейчас и вынуждены сажать, потому что доступных публичных IPv4 адресов все равно нехватает. И да, для подавляющего большинства пользователей переход на NAT оказывается совершенно незаметным (особенно для мобильной связи). Как минимум NAT/PAT уже реализован на пользовательском роутере, независимо от того публичный или приватный IPv4 адрес выдает вам провайдер, только в случае с приватным адресом NAT будет реализован дважды - на вашем роутере и еще раз на CGNAT. NAT сам по себе создает ряд проблем и ограничений, здесь же проблемы множатся и централизованная динамическая трансляция будет (чаще всего) вне контроля пользователя. Никаких проброса портов, эффективных p2p сетей, проблемы с рядом протоколов, с производительностю. Фактически пользователь с приватным адресом не является полноправным участником интернета, а лишь потребителем неких сервисов, предоставляемых провайдером. Публичный же адрес не ограничивает пользователя. Хоть серфите, хоть домашний хостинг открывайте - это ваше личное дело и провайдер не должен в это вмешиваться. Если хотите, это часть западной общепринятой философии. Потому при внедрении CGNAT предусмотрено, что любой абонент может переключить свою линию обратно на единоличный публичный IPv4 адрес.
Так что да, CGNAT внедряется, но исключительно как вынужденная мера, как временное решение на пути перехода на IPv6.
Речь не идет о переводах или адаптации. Речь идет о форсировании терминологии в угоду неким высоким идеям, но без всякой связи с реальностью и устоявшимися традициями.
Россия здесь, кстати, далеко не первая. Например, Франция очень щепетильно относится к родному языку и академики (из Academie Francaise) ежегодно публикует официальные эквиваленты для английских терминов в информатике. Но есть одно "но". Никто не заставляет ITшников использовать эти официальные термины. Ни в работе, ни в переписке, ни в документации, ни в публикациях. Хочешь - валяй, не хочешь - используй англицизмы, главное чтобы коллеги и собеседники понимали смысл сказанного. Многие локальные эквиваленты вполне устоялись и входят в ежедневную речь (a computer = un ordinateur, a chip = une puce, RAM = une mémoire vive, и т.д., многие термины просто франциализированы под французское произношение, например, a router = un routeur). У немцев то же самое, например Festplatte для HDD. Есть еще один аспект - академики просто не в состоянии поспевать выдумывать эквиваленты новым терминам, учитывая скорость их появления. Ну и не последний момент: английский является де-факто международным языком в информатике и если вы читаете документацию, статьи, участвуете в конференциях, общаетесь с разработчиками и конструкторами оборудования, то вам придется поддерживать два контекста общения - для внутреннего и внешнего пользования.
Что касается советского подхода. Если вы застали те времена, то помните, что терминология определялась ГОСТом (15987-хх, возьмите -84 для полного впечатления) и вы были обязаны использовать эту терминологию. И ладно если вы занимались разработкой архитектуры (например 13й машины в НИИВК) - это одно, своя разработка, свои термины. А если вы работали программистом или лаборантом на СМ ЭВМ, которая оказалась фактически клоном PDP-11 - это другое. Никто не пользовался унылой "официальной" терминологией, а незнание оригинальной английской породило целый жаргонарий терминов, на которых и общались.
Есть два похода, которые наглядно иллюстрирует урбанистика: можно проложить бетонные дорожки там, где задумал архитектор во имя красоты, а потом удивляться, почему никто не ходит по прекрасным перпендикулярным дорожкам, зато протаптывает тропинки по грязи наискосок, как удобнее и ближе. А можно дать людям протоптать дорожки как им удобнее, а потом проложенные дорожки забетонировать, получив дороги и удобные и обустроенные.
С терминологией то же самое. Можно всех загонять строем в счастье, а можно взять за основу сложившееся само собой удобное всем состояние и зафиксировать его, причесав и подогнав где надо.
Тем, что есть перевод смысла, а есть канцелярит. PC скорее соответствует ПК (персональный компьютер), а ПЭВМ - песональная-электронно-вычислительная-машина - это избыточная конструкция, пригодная для описания абстрактного сферического предмета в вакууме, но не для эффективной коммуникации.
RAM описывает тип памяти, а ОЗУ - абстрактрый блок в схеме компьютерной архитектуры (устройство), а не тип памяти, чтобы указать на его отличие от ROM (ПЗУ) или НГ/ЖМД. Короче усложнение ради усложнения.
В других странах ситуация принципиально другая. Но ситуация разнится от страны к стране. В странах западной Европы общепринятой практикой была выдача публичного IPv4 адреса каждому абоненту. Поэтому исчерпание IPv4 адресов в 2010х стало сказываться напрямую на возможностях операторов, причем в краткосрочной перспективе. Дополнительно ситуацию усугубил взрвыной рост количества мобильных абонентов, которые тоже потребляли по 1 публичному адресу на терминал. Сегодня переход на IPv6 в этом плане безальтернативен, дополнительно стимулируется переходом на IPv6 всех крупных источников контента - Google, Facebook, CDN провайдеров типа Akamai. Для примера, уровень покрытия доступом IPv6 для абонентов во Франции - 90%, Германия - 70%. Общий заподноевропейский трафик IPv6 в этом году практически сравнялся с IPv4 и по прогнозам должен его превзойти в 2026м. Для операторов есть и другие плюсы перехода на IPv6, например SRv6. Применяемые технологии CGNAT и MAP-T направлены исключительно на выигрыш времени для планомерного перехода на IPv6-only.
В странах с молодой истрией развития сетей ситация еще ярче. Покрытие IPv6 в Индии и Китае - почти 100%, многие операторы этих стран ipv6-only, а возможность получить IPv4 адрес существует, но является платной услугой.
Ну например чтобы получить сеть построенную на энтузиазме. Не загаженную рекламой и без сбора данных о юзерах. С высоким порогом вхождения, обусловленного необходимостью определенного уровня технических знаний, и, как правило, высшего образования. Ориентированную на вдумчивое общение посредством обьемных текстов, а не на дофаминовую дозу от листания ленты, на 99% полную безсмысленными собщениями.
Ностальгия по ФИДО связана не технологиями, а с тем сообществом, которое в нем возникло.
Не правда. Затраты в основном идут на обучение и повышение квалификации персонала, но они идут постепенно, в плановом порядке. В большинстве случаев внедрение не требует замены оборудования (вне плановой замены), не требуется редизайна архитектуры, а требования к поддержке IPv6 и включение в дизайн включено в список требований новых проектов. Таким образом внедрение происходит постепенно, без перетурбаций и дополнительных вложений.
Да, ошибки в планировании адресации компании потом могут дорого обойтись при исправлении, но в большинстве случаев это еще не совершенные ошибки.
Это не так. Большинство IP инженеров и архитекторов в телекоме имеют базовое представление о IPv6, достаточное для реализации проектов. Развитие и углубление знаний требуется, потому что я вижу много ошибок связанных с попытками переноса философии и мышления IPv4 на IPv6, но это нормальная ситуация.
Использовать Link-Local адресов (LLA) для встроенной сети вполне возможно и даже приемлимо, если все устройства находятся в общем канальном сегменте. Даже если есть несколько соединенных маршрутизатором сегментов, то построить общую сеть на LLA все же можно (даже без динамической маршрутизации), но это порождает множество проблем или, как минимум, неудобств. Следует так же учитывать необязательное использование EUI-64 (а часть устройств может генерировать интерфейсную часть адреса случайным образом), возможное использование одиного и того же LLA на разных интерфейсах одного и того же маршрутизатора (LLA должен быть уникальным только в пределах одного сегмента), и прочие проблемы, осложняющие настройку и отладку.
Для изолированных сетей (включая встраиваемые сети) дизайнерами IPv6 был разработан специальный тип адресов - ULA (Unique Local Address). Это если вы желаете чтобы устройства из внутренней сети не могли коммуницировать наружу. А если необходим доступ, то нет никаких проблем с назначением внутренним устройствам глобальных адресов (GUA). Что с ULA, что с GUA, DHCPv6 сервер не обязателен, адреса можно раздать через IA_PD в RS/RA (а так же адреса серверов DNS), но если неоходимо передать устройствам специфическую информацию (сервер NTP, etc.) то DHCP сервер необходим.
Мыслите вы правильно и в верном направлении, но, как мне кажется, не вполне эффективно пытаетесь использовать стек IPv6.
То что вы этого не видели, это не значит что этого нет. :) Чаще всего провайдеры используют динамический CGNAT, не подразумевающий вообще входящие соединания для пользователя, соответственно уведомлять пользователя не о чем. Если же вы реализуете архитектуру с фиксированным пулом портов для пользователя, то пользователь должен его знать. В нашем случае нет необходимости сообщать CPE назначеный ему пул портов, он его знает по последним битам полученного приватного IP адреса (механизм описан в указанном мною драфте), а свой публичный адрес используемый на CGNAT - через опцию 125 DHCPv4. Использовать только предоставляемый нами CPE не обязательно, эта логика AFAIK поддерживается OpenWRT. Можно вообще обойтись без этой логики, если ваш CPE (или ваш комп с напрямую воткнутым патчордом) позволяет задать пул портов для трансляции вручную. Все исходящие соединения, которые использует порты не входящие в ваш пул просто не пройдут CGNAT. Так же, чисто для информации, ваш публичный IPv4 адрес и пул портов указаны в вашем кабинете на портале провайдера.
Я не видел провайдеров позволяющих доступ исключительно со своих CPE, хотя, судя по обсуждениям на форумах, такие есть. Чаще всего вы может заменить провайдерский CPE на свой, хотя при этом скорее всего потеряете такие фичи как телефонию и TVoIP. Ну и разумеется в случае DSL ваш CPE должен иметь (или вы должны иметь внешний ) модем, а в случае FTTH ваш провайдер должен предлагать отдельный ONT (а не только CPE с инетгрированным ONT).
Ну тут либо шашечки, либо ехать. Чудес не бывает, даже если найти решение. Так что согласен. Аминь.
Простите, а какую схему вы видели? Пользователю в лучшем случае выдают 1 публичный IPv4 адрес для CPE, а не подсеть для LAN. Так что у пользователя NAPT как минимум есть, на его CPE. А если выдают приватный, чтобы потом странслировать его на CGNAT, то суть точно та же. Ну а так как мы изначально говорим про CGNAT, то вот вам вторая точка трансляции.
Это же не корпоративная сеть, где пользователи в общей сети и нужеен только один адресный транслятор на границе.
1:8 - это результат анализа нашей собственной статистики. Даже у озабоченных гиков суммарное количество открытых соединений не превышает двух тысяч, у большинства обычных пользователей - пара сотен. Так что 8К портов на пользователя - это с запасом.
Это для фиксированного доступа. Для мобильного CGNAT 1:128 или 1:256. С учетом, что 99,9% мобильных пользователей это единственный терминал (смартофон), то 256 портов более чем хватает. Или 512.
На множестве маленьких железок у нас реализован MAP-T. Я не знаю, общая ли это ситуация или наш частный случай, но CGNAT был взят на мощном железе и стоил сильно дорого, хотя это возможно из-за кастомной логики реализующей упомянутый мной драфт. Его имело смысл централизовать, а не децентрализовывать, как MAP-T. Хотя и MAP-T, IMHO, лучше централизовать и размещать как можно ближе к пирингу, но это выбор архитекторов конкрентной сети согласно конкретным условиям.
Для большинства пользователей нужны point2ponint звонки, а не видеоконференции.
Зачем? Наоборот! Выгодней разгрузить свои сервера, пусть пользователи сами, на своем же железе, раздают выложеные нами файлы. Всем выгода - компании нагрузка меньше, пользователю - распространение быстрее, а доступность раздаваемых файлов - выше. А еще можно самому себе проблем создать. Мне помнится как на заре iPhon'ов Apple выложил апдейт и весь мир ломанулся апгрейдиться однвременно, положив сервера Apple похлеще DDoS атаки.
Бизнес на обьеме трафика уже много лет как нет, разве что у Tier 1 провайдеров, да и то, если они ошибаюсь, они за BW берут, а не за прокаченный трафик. Так что компании в первую очередь интересно избежать наплыва пользователей и лишнего трафика.
Некая малая часть несомненно будет, но по сравнению с аудиторией FB, VK и иже сними - это так, в размере погрешности. Основная масса не найдет в этих p2p-сетках и IRC-чатиках ни котиков, ни "лайкни, чтобы посмотреть сколько нас" и "99% людей на смогли решить 2+2x2". Большинство не слезет с дофаминовых лент ради независимого общения в чатах формата 20+-летней давности. Я тоже ностальгирую по news конференциям и фидо, но эта эпоха уже ушла.
Ничего подобного. То что абоненты сидят в общей подсети еще не значит, что она в одном броадкаст-домене. Коллекторы организуются как hub&spoke и трафик между двумя абонентами одной подсети поднимается до BNG. А в этом плане без разницы какие у них адреса - приватные или публичные. В последнем случае трафик поднимется еще выше - до CGNAT. Если CGNAT находится не около BNG, а ближе к точкам пиринга, то гонять трафик через полсети - смысл?
Единственное что верно, это то, что на долю межабонентского трафика сегодня приходится лишь несколько процентов, большая часть приходится на крупные ресурсы, такие как Facebook, Youtube, видеостримеры и т.д.
Дело не в количестве байтов на слот, а в количестве слотов. И в мощностях затрачиваемых на lookup по таблице и его скорости. Симметричный NAT позволяет минимизировать количество используемых публичных адресов, но колчество xlate будет расти экспоненциально. Но это сферические размышления в вакууме, это надо уже брать конкретный кейс с соответствующим количеством абонентов, средним количеством отрытых соединений tcp+udp на абонента, конкретное железо и смотреть какой у него рейт по трансляции.
На практике же речи о внедрении симетричного NAT не идет (даже при фантастической экономии публичных адресов), ибо слишком брутально бьет по доступной пользователю функциональности сети. Я не знаю ни одного случая его воплощения на уровне CGNAT. Только единожды на фаерволе и совсем по другим причинам, нежели экономия адресов.
Нет, не требует. У нас реализован CGNAT на основе драфта draft-tsou-stateless-nat44-02, что позволяет разделить каждый публичный IP адрес между несколькими абонентами (например 1:8), зафиксировав за каждым абонентом его диапазон портов tcp/udp (65К / 8 соответственно для каждого из транспортных протоколов). CPE абонента производит NAPT во внешний приватный адрес из пула RFC6598, но используя только порты из закрепленного за абонентом диапазона портов. Далее пакет роутится до CGNAT, где транслируется только приватный RFC6598 IPv4 адрес в соответствующий публичный (чистый NAT), при этом количество требуемых слотов равно 8 x количество уже задействованных публичных адресов. Это на порядки меньше, чем если бы на CGNAT был реализован NAPT.
Дополнительный плюс (а в нашем случае это обязательное условие), что при этой статической трансляции, пользователь доступен для входящих соединений (хоть и только в рамках зафиксированного за ним диапазона портов), остается только пробросить в LAN нужные порты на CPE.
В плане голосовых звонков - WhatsApp децентрализован, Telegram децентрализован, Webex, Meets - тоже. Да собственно любая SIP телефония и видеоконференции. С учетом qos интернета других вариантов нет. Microsoft Windows Update использует протокол схожий с bittorrent'ом для распространения обновлений. Есть другие.
Но о реальном положении дел все повсеместно знают и открыто говорят. Вы слышали что-нибудь о гонении на IPv6 в России? Хотя бы кулуарно? Не теории заговора и слухи, а реальные распряжения/инструкции/утечки. Я даже слухов не слышал.
Для примера Яндекс, насколько я знаю, не просто всячески внедряет IPv6, но и открывает (открывал) датацентр (в Финляндии) на IPv6-only - а это глубокий уровень освоения IPv6.
Ну это вообще не серьезно. VK/Facebook/Ticktok/etc. это сервисы сами в себе, люди идут к ним целенеправлено за их дофаминовым контентом, наличие/отсутствие у вас возможности одноуровневого пиринга им вообще перпендикулярно.
Китайцы пытаются (IPv9), но не выходит. Правда и мотивация за этим стоит совсем другая, не техническая.
Да, и забыл сказать. Если принять вашу гипотезу, то IPv6 следут вообще запретить с самого начала в отдельно взятой стране, ибо с ним вообще весь NAT исчезает. Россия может быть отстает по внедрению IPv6, но не пытается же его запретить? А если под боком есть уже существующая алтернатива, без всяких NAT и ограничений на P2P, то зачем огород городить? Да еще городить с протоколом, который исчезнет в ближайшие годы.
Я понял вашу мысль. Такая конфигурация осложнит открытие P2P соединений, но не полностью искореняет их возможность. В частности это будет работать если обе точки находятся за отдельными CGNAT, причем оба CGNAT работают в режиме симметричного NAT. Кроме того, пользователи за общим CGNAT смогут устанавливать пиринг по своим приватным адресам (а это от тысяч до десятков и даже сотен тысяч пользователей), хотя это зависит от архитектуры сети и можно запретить пользователям коммуницировать напрямую без прохождения CGNAT.
В реальности это сложно и накладно. Cимметричный NAT потребует создания слота трансляции с уникальным кортежем на каждое соединение пользователя (а это сотни одновременных соединений на кажого "пользователя" (то есть всей его LAN)), а не условно 1 слот на кажого пользователя. Соответствующие требования к ресурсам железа. Учитывая тысячи и тысячи пользователей за каждым CGNAT, а так же что в сети крупного провайдера этих CGNAT по регионам может быть десятки, учитывая необходимую избыточность, а так же запрет на пиринг по приватным адресам за общим CGNAT (то есть форсировать 100% трафика через CGNAT), лицензии, обслуживание, и и.д., то решение в итоге становится золотым. То есть на бумаге это реализовать не сложно, в реальности можно, но проблематично. И опять-таки, одно дело обязать провайдера воткнуть СОРМ от органов в разрыв сети, он для провайдера "black box", который не влияет на архитектуру и толпологию сети и провайдер его не обслуживает и за него не отвечает. Другое дело - требовать от провайдера затачивать саму архитектуру провайдерской сети под такое решение, причем за свой счет. Можно ли заставить провайдеров это реализовать? Конечно. В конце-концов можно вообще разрешить выходить в сеть только с общественного компьютера в библиотеке под запись в жернал и с логгированием всех действий пользователя (уже было, а в КНДР возможно и сегодня так), но все же давайте будем реалистами. :)
И это при том, что элементарный прокси-сервер в сети сводит на нет все усилия с симметричной трансляцией. Да, через него торрентом качать не выйдет, но пустить телефонию - не проблема от слова совсем. Да и вообще надо почитать что там нового в STUN. С RFC3489 уже много лет прошло, я не смотрел что изменилось в RFC 5389 и затем в RFC8489.
Ну и отказ от P2P технологий это серьезный удар по ряду современных сервисов в сети (помимо битторрента и мессенжеров), что будет означать создавать самим себе трудности на ровном месте для всей сети страны в целом.
Подытожу тем, что не знаю какие страны вы имеете в виду, но мне внедрение такой архитектуры кажется нерациональным даже с точки зрения параноидального Большого Брата и я о таких тенденциях не слышал.
За NAT где? На CPE пользователя? Или на CGNAT? Или на обоих?
Могут. Но для этого не нужно перестраивать существующие сети или менять связи между абонентами. В тех же точках контроля трафика установить DPI. Как решать вопрос шифрованного трафика - это другой вопрос.
Да, есть такая проблема, я с ней сталкиваюсь, и это одна из причин развертывания IPv6 во внутренних сетях провайдеров и операторов (чем пока что мало кто из них заморачивается, решая в первую очередь задачу предоставления сервиса IPv6 для клиентов). И это даже в том случае, если провайдер не использует приватные IPv4 адреса для абонентских пулов. Даже наоборот, приходится для внутренних нужд использовать пул приватных адресов зарезервированный специально для CGNAT - 100.64.0.0/10 (RFC6598) в качестве приватных адресов RFC1918.
Простите, это абсурд, идущий в противоречие с самими фундаментальными принципами сетевой архитектуры. Это не значит, что так технически нельзя сделать, но в этом попросту нет никакого смысла. Ваше подключение и так не может не проходить через того или иного провайдера лицензированного государством, а следовательно способного применить комплекс мер по идентификации и перехвату трафика. То есть если мы говорим от открытой сети, то ваша "прямая" связь между абонентами будет так или иначе проходить через точки контроля трафика у одного или нескольких провайдеров.
Можно, конечно, говорить о прямых физических соединениях (радио, лазером, голубями, флажками), но это смехотворный масштаб, который не может рассматриваться даже параноидальным государством как угроза требующая контроля.
Вопрос, на самом деле, не праздный. Я сталкивался с необходимостью пробросить snmp и dns через ssh тунель. Возможные решения обсуждалось, например, здесь: https://superuser.com/questions/53103/udp-traffic-through-ssh-tunnel
В моем случае удалось решить иначе, активировав dns через tcp и перейдя на snmp v3 через tcp, это было проще.
А как вы решаете задачу с тунелированием udp соединений?
А сейчас и вынуждены сажать, потому что доступных публичных IPv4 адресов все равно нехватает. И да, для подавляющего большинства пользователей переход на NAT оказывается совершенно незаметным (особенно для мобильной связи). Как минимум NAT/PAT уже реализован на пользовательском роутере, независимо от того публичный или приватный IPv4 адрес выдает вам провайдер, только в случае с приватным адресом NAT будет реализован дважды - на вашем роутере и еще раз на CGNAT. NAT сам по себе создает ряд проблем и ограничений, здесь же проблемы множатся и централизованная динамическая трансляция будет (чаще всего) вне контроля пользователя. Никаких проброса портов, эффективных p2p сетей, проблемы с рядом протоколов, с производительностю. Фактически пользователь с приватным адресом не является полноправным участником интернета, а лишь потребителем неких сервисов, предоставляемых провайдером. Публичный же адрес не ограничивает пользователя. Хоть серфите, хоть домашний хостинг открывайте - это ваше личное дело и провайдер не должен в это вмешиваться. Если хотите, это часть западной общепринятой философии. Потому при внедрении CGNAT предусмотрено, что любой абонент может переключить свою линию обратно на единоличный публичный IPv4 адрес.
Так что да, CGNAT внедряется, но исключительно как вынужденная мера, как временное решение на пути перехода на IPv6.
Речь не идет о переводах или адаптации. Речь идет о форсировании терминологии в угоду неким высоким идеям, но без всякой связи с реальностью и устоявшимися традициями.
Россия здесь, кстати, далеко не первая. Например, Франция очень щепетильно относится к родному языку и академики (из Academie Francaise) ежегодно публикует официальные эквиваленты для английских терминов в информатике. Но есть одно "но". Никто не заставляет ITшников использовать эти официальные термины. Ни в работе, ни в переписке, ни в документации, ни в публикациях. Хочешь - валяй, не хочешь - используй англицизмы, главное чтобы коллеги и собеседники понимали смысл сказанного. Многие локальные эквиваленты вполне устоялись и входят в ежедневную речь (a computer = un ordinateur, a chip = une puce, RAM = une mémoire vive, и т.д., многие термины просто франциализированы под французское произношение, например, a router = un routeur). У немцев то же самое, например Festplatte для HDD. Есть еще один аспект - академики просто не в состоянии поспевать выдумывать эквиваленты новым терминам, учитывая скорость их появления. Ну и не последний момент: английский является де-факто международным языком в информатике и если вы читаете документацию, статьи, участвуете в конференциях, общаетесь с разработчиками и конструкторами оборудования, то вам придется поддерживать два контекста общения - для внутреннего и внешнего пользования.
Что касается советского подхода. Если вы застали те времена, то помните, что терминология определялась ГОСТом (15987-хх, возьмите -84 для полного впечатления) и вы были обязаны использовать эту терминологию. И ладно если вы занимались разработкой архитектуры (например 13й машины в НИИВК) - это одно, своя разработка, свои термины. А если вы работали программистом или лаборантом на СМ ЭВМ, которая оказалась фактически клоном PDP-11 - это другое. Никто не пользовался унылой "официальной" терминологией, а незнание оригинальной английской породило целый жаргонарий терминов, на которых и общались.
Есть два похода, которые наглядно иллюстрирует урбанистика: можно проложить бетонные дорожки там, где задумал архитектор во имя красоты, а потом удивляться, почему никто не ходит по прекрасным перпендикулярным дорожкам, зато протаптывает тропинки по грязи наискосок, как удобнее и ближе. А можно дать людям протоптать дорожки как им удобнее, а потом проложенные дорожки забетонировать, получив дороги и удобные и обустроенные.
С терминологией то же самое. Можно всех загонять строем в счастье, а можно взять за основу сложившееся само собой удобное всем состояние и зафиксировать его, причесав и подогнав где надо.
Тем, что есть перевод смысла, а есть канцелярит. PC скорее соответствует ПК (персональный компьютер), а ПЭВМ - песональная-электронно-вычислительная-машина - это избыточная конструкция, пригодная для описания абстрактного сферического предмета в вакууме, но не для эффективной коммуникации.
RAM описывает тип памяти, а ОЗУ - абстрактрый блок в схеме компьютерной архитектуры (устройство), а не тип памяти, чтобы указать на его отличие от ROM (ПЗУ) или НГ/ЖМД. Короче усложнение ради усложнения.
В других странах ситуация принципиально другая. Но ситуация разнится от страны к стране. В странах западной Европы общепринятой практикой была выдача публичного IPv4 адреса каждому абоненту. Поэтому исчерпание IPv4 адресов в 2010х стало сказываться напрямую на возможностях операторов, причем в краткосрочной перспективе. Дополнительно ситуацию усугубил взрвыной рост количества мобильных абонентов, которые тоже потребляли по 1 публичному адресу на терминал. Сегодня переход на IPv6 в этом плане безальтернативен, дополнительно стимулируется переходом на IPv6 всех крупных источников контента - Google, Facebook, CDN провайдеров типа Akamai. Для примера, уровень покрытия доступом IPv6 для абонентов во Франции - 90%, Германия - 70%. Общий заподноевропейский трафик IPv6 в этом году практически сравнялся с IPv4 и по прогнозам должен его превзойти в 2026м. Для операторов есть и другие плюсы перехода на IPv6, например SRv6. Применяемые технологии CGNAT и MAP-T направлены исключительно на выигрыш времени для планомерного перехода на IPv6-only.
В странах с молодой истрией развития сетей ситация еще ярче. Покрытие IPv6 в Индии и Китае - почти 100%, многие операторы этих стран ipv6-only, а возможность получить IPv4 адрес существует, но является платной услугой.
И сорока лет не прошло и вот опять....
ЭВМ, УВВ, УПЗС, АЦПУ, ИРПР, МВВ, ОЗУ, СОП, ПЗУ, НГМД, НМЛ, УПС, ППП, ДВК, УВК, ЦП...
Терминология времен АЛГОЛа и ФОРТАНа, которая использовалась для написания диссертаций и книг. И документации, которую никто не читал.
Ну например чтобы получить сеть построенную на энтузиазме. Не загаженную рекламой и без сбора данных о юзерах. С высоким порогом вхождения, обусловленного необходимостью определенного уровня технических знаний, и, как правило, высшего образования. Ориентированную на вдумчивое общение посредством обьемных текстов, а не на дофаминовую дозу от листания ленты, на 99% полную безсмысленными собщениями.
Ностальгия по ФИДО связана не технологиями, а с тем сообществом, которое в нем возникло.
Простите, вы имеете в виду российских провайдеров?
На данный момент покрытие IPv6 сильно разнится от страны к стране, в Европе составляет от 40 до 80 процентов. Интерактивная карта ARCEP (французский регулятор), построеная на статистике Google, Akamai, Facebook и APNIC https://www.arcep.fr/cartes-et-donnees/nos-cartes/ipv6/carte-interactive-ipv6.html
Если взять Францию, то все 4 основных оператора имеют покрытие более 90%
У многих китайских и индийских операторов - 100%.
Это не так. Крупные сервисы такие как Google и Facebook полностью доступны через IPv6. Крупные хостеры (как OVH) - тоже. По той же Франции - количество веб сереверов в национальных TLD доступных по IPv6 - 35%, почтовых серверов - 25%. https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html
Не правда. Затраты в основном идут на обучение и повышение квалификации персонала, но они идут постепенно, в плановом порядке. В большинстве случаев внедрение не требует замены оборудования (вне плановой замены), не требуется редизайна архитектуры, а требования к поддержке IPv6 и включение в дизайн включено в список требований новых проектов. Таким образом внедрение происходит постепенно, без перетурбаций и дополнительных вложений.
Да, ошибки в планировании адресации компании потом могут дорого обойтись при исправлении, но в большинстве случаев это еще не совершенные ошибки.
Это не так. Большинство IP инженеров и архитекторов в телекоме имеют базовое представление о IPv6, достаточное для реализации проектов. Развитие и углубление знаний требуется, потому что я вижу много ошибок связанных с попытками переноса философии и мышления IPv4 на IPv6, но это нормальная ситуация.
Использовать Link-Local адресов (LLA) для встроенной сети вполне возможно и даже приемлимо, если все устройства находятся в общем канальном сегменте. Даже если есть несколько соединенных маршрутизатором сегментов, то построить общую сеть на LLA все же можно (даже без динамической маршрутизации), но это порождает множество проблем или, как минимум, неудобств. Следует так же учитывать необязательное использование EUI-64 (а часть устройств может генерировать интерфейсную часть адреса случайным образом), возможное использование одиного и того же LLA на разных интерфейсах одного и того же маршрутизатора (LLA должен быть уникальным только в пределах одного сегмента), и прочие проблемы, осложняющие настройку и отладку.
Для изолированных сетей (включая встраиваемые сети) дизайнерами IPv6 был разработан специальный тип адресов - ULA (Unique Local Address). Это если вы желаете чтобы устройства из внутренней сети не могли коммуницировать наружу. А если необходим доступ, то нет никаких проблем с назначением внутренним устройствам глобальных адресов (GUA). Что с ULA, что с GUA, DHCPv6 сервер не обязателен, адреса можно раздать через IA_PD в RS/RA (а так же адреса серверов DNS), но если неоходимо передать устройствам специфическую информацию (сервер NTP, etc.) то DHCP сервер необходим.
Мыслите вы правильно и в верном направлении, но, как мне кажется, не вполне эффективно пытаетесь использовать стек IPv6.