Випущена чернетка для IPv8. Навіщо?
Нещодавно побачив у інеті, що випустили чернетку специфікації протоколу IPv8.
Головна фішка в ньому в тому — це те, як вони вирішили проблему з нестачею адрес. Замість довжелезних і незрозумілих символів з IPv6, тут пропонують використовувати звичний формат IPv4, але додавати до нього спереду номер автономної системи (<asn>.n.n.n.n). Тобто кожній такій мережі просто виділяють свій власний величезний діапазон класичних IP-адрес. А якщо цей префікс нульовий, то це взагалі звичайнісінький старий IPv4.
Розробники запевняють, що перехід буде абсолютно безшовним і нам не доведеться викидати старі роутери чи переписувати софт. Усе це працюватиме завдяки спеціальному транслятору XLATE8, який відразу конвертуватиме трафік між старими та новими мережами (типу щось на кшталт NATу).
А от що дійсно змінили кардинально, так це безпеку. Тепер усі елементи мережі мають авторизуватися через сучасні токени OAuth2. Більше того, кожне нове з’єднання має обов’язково пройти перевірку через їхній новий DNS. Якщо пристрій спробує підключитися кудись без цього запиту, транслятор просто заблокує з’єднання.
Разом із самим протоколом пропонують оновити й усю інфраструктуру. Вони буквально взяли всі базові мережеві інструменти і зробили їм нові версії — так з’явилися DHCP8, ICMPv8, BGP8 та інші. Керувати всією цією телеметрією, аутентифікацією та маршрутизацією має єдина платформа під назвою Zone Server. Пристрій буде підключатися до мережі, отримувати всі необхідні налаштування і працювати.
Загалом звучить цікаво, але поки що, знову ж таки, це лише чернетка. Що думаєте про це новшество? І загалом, нащо було придумувати IPv8, якщо ще IPv6 не до кінця змогли впровадити?
36 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівУ ipv6 багато чого цікавого, але щоб його осягнути треба забути про ipv4. Ipv8 виглядає більше еволюційним, ніж революційним в цьому плані.
О! Це ж воно! Ну, нарешті! Так, дуже цікава ідея. Логічна, проста і зрозуміла. Сподіваюсь, IPv8 таки краще зайде народу і виробникам, ніж v6 ;-)
Если еще верификацию возраста в пакет встроить, будет вообще збс.
Класичне — джуну складно розібратись з існуючим, придумаю ка я щось своє нове «краще»
проблема з ip6 в тому що він народився в лабораторії і коли почали реально використовувати то повилазило безліч проблем. Те що «вирішує» цей джун зі своїм ip8 взагалі не проблема, точніше проблема читанням людиною відносна і при бажанні можна виділяти тільки «людські» адреси для такого. Я більше скажу — можна прийняти якийсь стандарт для переводу з ip6 в ip4 по префіксу чи ще як шоб зберегти сумісність но ip6 взагалі не про це.
він більший і основна його задача буди універсальною унікальною адресою як MAC тільки один на всіх. як з usb-c в який вшито унікальний номер. І тут та же проблема як із usb-c — тим хто тримає ринок це все нaxуй не потрібно, вони і так заробляють гроші. навіщо складнощі. Можна частково використовувати ip6 для закриття основних потреб (приклад Yggdrasil), можна використовувати повноцінно (InfiniBand як писали нижче). Все можна, но знову ж таки нікому нaxуй не потрібно поки працює те що е. Зараз вже йде закат глобального інтернету і нічого дивного в тому, що нікому воно не потрібно — ті кому потрібно роблять свої проприоритатні костилі, а час глобальних рішень та стандартів вже пройшов. Едине що — якщо захочуть вкрутити гайки на максимум то дуже швидко випустять якійсь «секьюрний» стандарт який буде потребувати центри сертифікації (державні звичайно же) і без них навіть локально нічого не буде працювати.
Ip6 має таку кучу недоліків, що ip8 має шанси.
вайбкодінг вже дістався ietf
чума 21 століття
Jamie Thain of One Limited, based in Bermuda вирішив винайти чергове колесо
Адресное пространство в IPv6 и так 128 битное, чего хватит для адресации каждого атома на Земле, так что эта проблема уже решена и в дальнейших улучшениях не нуждается. Идея насчёт подписывания каждого соединения через OAuth2 абсурдна, и закладывает базис для сворачивания свободного пользования интернетом. Поскольку решительно любое сетевое взаимодействие будет зависеть от центров сертификации. В общем, звучит как построение цифрового гулага. Идея скорее всего может принадлежать роскомнадзору, или ещё каким-то подобным мыслителям.
На самом деле она даже нуждается в «ухудшениях», то есть, смысл в сокращении до 64 бит есть. Никому нахрен не нужно адресовать каждый атом, а вот недостатки от сверхдлинного адреса таки есть: место в пакетах, место в конфигах, заморочки админам, которым приходится (в отличие от юзеров) использовать и числовые адреса на постоянной основе, а запомнить их таких нереально, и даже глазами сверить сложно.
Если бы сделали, например, до 24 бит на адресацию в пределах L2 сегмента, и (пусть 1/2 отдана под юникасты) 39 на глобальный, это бы дало все те же преимущества, кроме одного: возможности гарантированно бесконфликтно формировать локальные адреса из MAC-адреса (базовый SLAAC). Но с1994-го года, когда первый IPv6 был заложен, и так изменилось чуть менее чем всё, и в половине случаев те MAC-адреса тоже генерируются рандомно; а neighbor solicitation даёт проверку адреса перед его окончательным захватом, так что и тут пользы около нуля. А расширенный SLAAC и так проблемный из-за отсутствия скоупа действия адреса по дальности, так что он нихрена реально не даёт к секьюрити.
И мало того, у варианта 128 бит нету реального обоснования в принципе! При первой разработке сначала долго выбирали, 64 или 128, причём 128 было конкатенацией двух уникальных адресов(!) — локального и глобального. Потом один военный (реально военный, @кое-что.navy.mil) сказал «любой фиксированный размер лучше переменного!», все взяли под козырёк и обсуждение остановилось без формального принятия решения.
По всему описанному, эти 128 бит — чемодан без ручки, который навязан сначала бездумным принятием, потом уже сложившимся легаси, когда код устоялся задолго до первого применения за пределами лаборатории.
Вообще, при первых задумках предполагали, что IPv6 адрес _заменит_ ещё и MAC-адреса сетевух. Реально это было сделано только на InfiniBand, там именно так и работает — точнее, адрес состоит из IPv6 link-local на основании UUID (аналог MAC) карточки и ещё и виртуального слота в ней. Но поверх Ethernet маки не отменили, и продолжается гимор с двумя уровнями.
Зато при его принятии не сделали того, что реально нужно и уже тогда это было очевидно: расширение номера порта в TCP, UDP и прочих.
Положительное, конечно, есть — в первую очередь после вообще хоть какого-то расширения адреса это переформирование пакетов с вынесением routing header, fragment header и пр. из основного заголовка. Но этого мало.
Тут уже грустнее, угу. Формально ничего не мешает делать свои центры сертификации, включая локальные. Но представим себе покупку и настройку свежего раутера: я не смогу к нему подключиться лаптопом без авторизации через центр? Или вначале будет, временно, без авторизации?
Если замена IPv6 не взлетит, гарантия 100%, то тут уже 200%, что никто не примет. Подмена существующих работающих механизмов за пределами компетенции L3 в принципе — не будет принята.
Насчёт кто продвигает — не думаю, что тут какой-то намеренный гулагострой. Разве что этот драфт был выдвинут намеренно ради того, чтобы получить отказ и потом кричать «наши великолепные предложения зарезали ибо кровавая ната»...
За свою жизнь насмотрелся на разное. Проблему с портами и протоколами решали прямо разными адресами тупо и все, то есть программы работают только с ip6 адресами есть свой шифратор-дешифратор который позволяет из ip6 адреса понять что это и тд (это все было в gRPC и на енумах, шикарная переносимость, от nodejs до php). Но там было для своей закрытой «рабочей» сети и потому в «общепринятые» правила даже не заглядывали. И делали так из-за цейнота на ресурсы, что бы критичное летало даже на голубиной почте, то есть чем тоньше оболочка пакета тем лучше
Вообще ip6 это очень гибкая штука в том плане, что туда можно напихать очень много чего при этом не ломая ничего. То есть инфраструктура живет отдельно на стандартных средствах, а програмно можно уже извращатся как хочешь.
І адрес IPv4 б вистачило, якби провайдери просто виділяли один IP на десяток-другий користувачів (наприклад на під’їзд) і щоб залізо автоматично прокидувало порти NAT, так щоб кожному абоненту виділялося 256 портів. Тобто перший байт порту ідентифікував машину за NAT, другий байт порт з трансляцією. Таким би чином фактично отримали не 32, а 40біт на адресу, а це вже 281 трильйонів адрес, нестача яких наче була головною мотивацією створення IPv6.
Ну добре, а чому 256, а не 64 чи 1024? Звідки фіксація на конкретній цифрі — просто так зручно?
А якщо у одного абонента нормально, що створюється 500 зʼєднань, а у іншого ніколи не буває більше 10?
А якщо за NAT більше 256 машин? Наприклад, якась велика організація вся сидить за одним IP?
Все, що ви кажете, _може_ бути зроблено і з поточним NAT, і іноді і робиться саме в такому дусі — мапінгом по портах. Але якщо так робиться, то для того, щоб легше було самім же відслідковувати джерело активности, коли логів забагато, щоб їх можна було зберігати. Але це не вирішує головні і принципово неусувні проблеми NAT: 1) необхідність підтримки в протоколах, через ALG чи з боку сервера, 2) конфлікт портів, 3) проблемність будь-якої політики таймаутів, 4) ціна тримання мапи трансляцій і підміни адресів.
«281 трільйонів» це 2^48, а не 2^40. Я не знаю, як ви це рахуєте.
бо зазвичай маска локальної мережі /24, тобто один байт на хост. Тому так- бо зручно.
До чого тут кількість з’єднань до портів, доступних до з’єднання ззовні? Чи у приватного абонента 500 серверів та по одному вхідному з’єднанню на кожен? Чи ви рахуєте вихідні з’єднання від абонента? 256 умовних [софтових] серверів запущених в абонента — це вже анріл.
Ну а зараз як? Головне, що від провайдера автоматично прокинуті порти, а куди їх мапить роутер злиденної організації, яка не може дозволити собі з таким парком купити білий IP, то вже інша справа.
Мова про те, що воно могло б робитися автоматично без ручного вбивання чи скриптів, щоб була домовленість і свій RFC , ну і виробники роутерів трохи обновили ПО NAT. Через це звичайним побутовим користувачам не доводилося б виділяти білу адресу (чи купувати статичну), значить, вивільнолося б багато блоків IPV4.
Нащо він тут, якщо фактично статично прокинуті порти?
Які ще конфлікти?
Ніякої мапи. Я ж кажу, що виділяємо один (потенційно) байт з номера порту, який напряму транслюється в локальну адресу хоста. Тобто при зовнішньому підключені на 1.2.3.4:1026 роутер просто бере локальну маску з адресою 192.168.1.0/24 і підставляє 4 з першого байту порту виходить що ззовні стукають до локального 192.168.1.4, а порт (2) з другого байту + домовлене в RFC зміщення, скажімо на 5000, от і виходить що ззовні 1.2.3.4:1024 транслюється в 192.168.1.4:5002, а що вже там робить абоненьский роутер з цим то його справа. Це вже дає софту абоненського ПК можливість приймати підключення з інтернету, і він міг би легко виявити доступність цих портів автоматично.
Білий IP дає можливість зовнішнього підключення, а так би могли шарити один IP між невибагливими абонентами, і вони б все одно мали можливість підключення без складних костилів для VoIP, Torrent, HomeAssistant, IoT, IP камери і т.д. Їм все одно який там зовні буде порт, та і редірект можна автоматизувати. А компанії будуть собі використовувати вивільнені блоки IP і пула IPV4 б вистачило з головою для населення землі.
«Зручно» — згоден. Фіксувати це як стандарт дизайну мереж — ні. Не для того в94-му уходили від класів мереж, щоб знову фіксуватись на тих же розмірах.
Да, я рахую і вихідні зʼєднання. Бо інакше не можна. Зʼєднання (для UDP теж використовуватиму цей термін, маючи на увазі «асоціацію») ідентифікується для кожної з двох сторін чотирма параметрами: host_local, host_remote, port_local, port_remote. Тепер подивимось, що буде, якщо ці клієнтські компʼютери встановлюють зʼєднання до чогось ззовні:
1. Для всіх зʼєднань на один і той же серверний хост — NAT має видати їм кожному окремий порт, бо інакше сервер буде плутати зʼєднання. І якщо є вихідні, то що буде, коли сервер має зробити своє зʼєднання на той же порт, а четвірка параметрів вже використана?
2. На різні серверні хости, звісно, можна поєднувати порти. Але це працює тільки з TCP чи SCTP. Для UDP формально ніщо не може завадити приймати на той же порт пакети з інших зовнішніх хостів — а це приводить до того, що NAT має кожному внутрішньому UDP порту, який показав активність, ставити у відповідність один зовнішній. А приймаючи до уваги, що на UDP зараз перейшов, в значній мірі, веб (бо QUIC), це стає невідворотнім.
Ось і виходить, що в загальному випадку на зовнішній стороні NAT має аллокувати по порту на кожне зʼєднання.
Не треба для цього ніякого оновлення NAT. Таким же чином, яким NAT зараз працює, він може працювати і далі. З тими же обмеженнями, які я пояснив трохи вище.
Дивіться вище. Варіанти з обмеженням кількости зовнішніх портів, обʼєднанням їх для різних клієнтів, працюють дуже проблемно і на практиці їх виключають. Всі існуючі реалізації NAT, за межами власне обмеженої кількости статичних трансляцій для пробросу зʼєднань на внутрішню мережу або DMZ, динамічно призначають зовнішні порти. Різниця між реалізаціями в тому, чи можна поєднувати зовнішні порти у випадку TCP і SCTP (symmetric режим) чи ні (full cone, restricted cone). Для домашнього раутера cone дозволений, для масштабу фірми — зазвичай вже ні. І друга різниця — як контролювати завершення зʼєднання (асоциації) і який виставляти таймаут.
Тобто у вас всі дозволені порти це один діапазон, у вашому прикладі 5000...5255?
Я дуже сумніваюсь, що це працюватиме. Багато чого із софта не можна так обмежити. Ну і, знову, вище було сказано про проблеми конфліктів.
Це ж не про дизайн мереж, а про функціонал NAT — виставив в його налаштуваннях якийсь там «direct-dst» і нехай собі автоматично мапить на свою локалку з налаштувань мережі DHCP. Ні для кого нічого не змінюється.
Там я вже нижче писав, що алокація вихідного порту ж не була б жорстко прив’язана до вхідного пулу, тобто 255 портів на локальний IP. В мережі активних хостів в кожен відрізок часу явно не 255, і взагалі їх там фізично може скільки не бути. DCHP бачить же активні хости і вільні пули портів. Але так, краще статично віддати половину під пул для мапінгу, а другу половину для вихідних і буде по 128 вхідних портів. Та навіть якби там було по 32 — все одно це краще, ніж 0, і коли заради того, щоб ззовні підключитися до своєї мережі, доводиться купувати виділений IP і використовувати там один чи два порти. Так що таке собі ущільнення мало б допомогти.
Тобто ніяк? Чи негри будуть руками прокидувати порти кожному абоненту?
Хм, ну наче ж там описав, що ніякого мапінгу аж на всі абонеські порти не було б, просто провайдерський NAT мапить умовні 255 зовнішніх портів на порт зі статичним зміщенням, наприклад, 5000- тобто ззовні можна було б достукатися тільки на порти з5000-5255. Все. Нікуди більше. Ніякої складної трансляції. Далі якщо абонент хоче собі мапить на своєму роутері їх як хоче і куди хоче. Головне, що від провайдера прокинутий блок портів. А якщо це пк, то софт, наприклад, торрент, міг би перевірити ці порти на доступність ззовні і далі використовувати для обміну p2p.
Ззовні на 80 порт? Може купити виділений IP? А як на локальний 80 порт, то в абоненському роутері нема DST-NAT?
Визнаю вашу безперечну і всеосяжну мудрість. Бути з вами на одному форумі велика честь, якої не достойний жодний смертний.
Який є частиною дизайну мереж.
І знову дивне. Більшости таких взагалі не треба жодного вхідного порту, а кому треба, треба менше 10, навіть з зустрічними зʼєднаннями в стилі SIP/WebRTC/etc. Але на вихідних зʼєднаннях і тимчасово запитаних асоціаціях вже будуть проблеми, які я описав.
«Негри» в особі, наприклад, протоколу SOCKS існують з середини1990-х. У нього при тому і не буде обмежень на порти клієнта. Питання лише в бажанні провайдера підтримувати такі юзерські запити.
Це ви навмисно зберегли частини першої версії відповіді, вже після того, як я різко зменшив тон? Для чого?
Ну, якщо хочете зупинитись, я таки підтримаю. Бо дійсно продовжувати мало сенсу, ті фрази, що я видалив з фінальної версії, згідно вашим репликам, залишаються актуальними. Але про «жодного смертного» це тяжке перебільшення: щоб розуміти тему, треба не більше ніж пару годин RTFM. Спробуйте, і якщо дійсно зробите, підніметесь на рівень «не-смертних».
nat взагалі непотрібен в ipv6 а замість 256 «портів» для «ще раз нат» тобі дають цілі блоки які ти можеш в ідеалі використовувати для будьчого, не 40 і не 32 біт а 64 і часто більше
весь наівний хейт ipv6 зводиться до набивання «незручних» адрес які взагалі люди не вбивають. рожать цілі нові стеки протоколів сидячи на бермудах без дупля що взагалі є ipv6 — краще хай в носі колупається
NAT — воркераунд, а не солюшен, як і всі інші хитрожопі ньютрансляції з бермуд
Якщо взяти наприклад к8с то там намучено три вагона складності де її взагалі не мало би бути якби це був ipv6 з нуля і це все було легасі вже коли воно було створене.
через те що комусь не подобаються ipv6 адреси і всьотут
Чудесно. Але мова була про те, що з IPv4 можна було досягти подібного «блоку» хоча б для домашніх користувачів і вивільнити адреси для корпоративних чи вибагливих користувачів. Куча провайдерських мереж і досі без підтримки IPv6, і куча грошей була витрачена на модернізацію. Та й сумнівний смисл цього блоку, якщо його треба буде зарізати на фаєрволі, щоб з КНДР не брутфорсили умовний смарт-унітаз з дирявою адмінкою.
Костиль вирішує дві основні взаємопов’язані проблеми — нестачу адрес і можливість вхідних підключень.
Основний інтернет протокол не вирішує проблеми «хоча б користувачів» коштом інших «вибагливих користувачів»
Я маю на увазі що ти пропонуєш виріщити конрктений кейс, тоді як стандарт має вирішувати загальну проблему з багатьма кейсами від домохазяйки до tier1 провайдерів, в країнах з різною щільністю використання адрес, для телеком стільникового зв’язку з мільйонами абонентів і мільярдамм конекшенів, і для домашнього роутера що кашляє в інтернет свої нещасні запити щоб хтось подивився кіно
Проблеми ipv6 не в нестачі адрес і не в нотації. Нестача адрес вирішена. Якби замість ipv6 нотації була використана інша нотація, все одно був би хейт «не звично». Не звично поки не звикнеш
це якраз одна з хороших критик IPv6, і що ти в загальному випадку не захочеш. Тобто ти робиш помилку з 1990х.
Оригінально це й було задумано, e2e конктівіті девайсів, але виявляється що ідеали 1990х не зовсім працюють в 2020х де люди особливо ендюзери зовсім не в захваті що адресний простір фактично працює як рентген в їхню мережу. А девайси раптом можуть бути якимись контейнерами, а зовсім не девайсами
Короче кажучи є в ipv6 купа проблем, щось подібного плану, щось іншого. Але пропоузал бермудського генія нічого тут не вирішить
Проблема IPv6 в тому, що більшості користувачів достатньо IPv4.
більшості користувачів взагалі до лампочки як вони заходять на амазон і порносайти ;) ніхто не помітить як їхній трафік раптом стане v6. А любителі поколупатись, поприбивати порти можуть і далі користуватись v4 якого їм досить
Ніхто ж не забороняє
Але в інтернеті користувач — AS, їм якраз не досить IPv4. Якщо ти не пентагон звісно
більше того як юшо брати цей висєр всерйоз то ось це
> усі елементи мережі мають авторизуватися через сучасні токени OAuth2. Більше того, кожне нове з’єднання має обов’язково пройти перевірку через їхній новий DNS
скоріше підійде для якоїсь піхвокореї й ростелекому ніж людським країнам
до кожного пакета справку ростелекома й дозвіл від товаріща майора їм не хочеться? це навіть коментувати стидно, але ж чомусь це з’явилося на IETF ) може на болотах вирішили віднайти скрепний «лучший» болєє соврємєнний айпіпротокол? А на від v8 лутше чем v6. На целих два 😀
В тому і проблема, що і вбивають, і читають з екрану, і порівнюють. І всі ці зайві байти це джерело помилок, око замилюється, різницю десь всередині тяжко помітити.
Потрібен. Бо
1) NAT крім концентрації в одній зовнішньому адресі має ще одну функцію, для деяких застосувань критичну — повне маскування внутрішньої структури мережі.
2) Без файрволлу не можна відкривати мережу всім зовнішнім хостам, неважливо, це IPv4 чи IPv6. А правила файрволла не можна адекватно для всіх сформулювати так, щоб доступатись до тільки того у внутрішній мережі, куди реально можна.
Пункт (2) можна було б вирішити, якби до параметрів сокета додали обмеження по дальности учасників. Але IETF думає про що завгодно, тільки не про те, що треба.
Твердження про непотрібність NAT з IPv6, бо, мов, адрес вистачає, це та ж свята наївність, що зробила взагалі весь початковий стандарт — на початку90-х, коли навіть email спама ще не було.
маскування побічна функція nat, а не основна. Основна — ефективне використаня публічних адрес.
В IPv6 nat опція, хочеш — нать, не хочеш не нать.
А коли ти телеком, тобі нат раптом не потрібен з v6, щоб обслужити всіх клієнтів одночасно, без іпучих трансляцій.
Як ти думаєш кожен смартфон і сенсор отримує доступ в інтернет взагалі через lte коли адрес не вистачає?
І тобі він теж непотрібен. Для прайвасі є privacy addressing
Хто визначив, де основна, а де побічна функція? Наведіть цитату, будь ласка. З документів IETF чи IANA.
Ну і в IPv4 те ж саме. Ніхто не забороняє накупити адресів і виставити всіх публічно. Але чомусь не роблять:)
Тоді чому на телефон, якщо виділяють IPv6, то приходить один IP, а не блок /64, як положено згідно базовим RFC?
Слушне питання. Відповідаю: не знаю, бо залежить від рівня жадібности і тупости провайдера. Видача одної IPv6 адреси на клієнтський раутер — це зараз в рази частіше, ніж навіть /64, або тих /56, що полагаються згідно стандарту. А якщо прийшла одна адреса — варіанту крім NAT6 не існує.
бо це цифри, вони взагалі безкоштовні ресурси, мають бути
www.rfc-editor.org/rfc/rfc1631
Introduction
The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing
CGNAT
На роутер має приходити префікс від провайдера. Це дає тобі всесвіт адрес. У роутера звісно одна адреса з цього префікса. В ідеалі має приходити /48, нормально /56, і ти маєш навіть змогу вдома/офісі це нарізати як тобі треба цей твій особистий публічний простір
Все що /64 і менше /64 — це вже про жадібність, криворукість і пєрєгіби на мєстах, це не технічна проблема ipv6
Але смартфон через LTE це інше питання. Технічно смартфон це не роутер, для нього нема причин мати великий префікс. Провайдер нарізає свій простір так як вважає за доцільне. /64 для смартфона забагато. Нахіба взагалі? З’явиться причина — почнуть роздавати префікси на смартфони.
Ось через такі, мʼяко кажучи, недальновидні погляди ми і отримали вичерпання IPv4 на декілька років раніше, ніж це мало б стати. Ті, хто отримав за таким принципом перші аллокації, до того, як ARIN, RIPE NCC і інші встановили нову політику розподілу за поточними заявками, на цілком законних підставах тримають по декілька /8, з яких використовують малу частину.
Ні, якщо будь-який ресурс являє собою природню монополію, за його користування, при будь-якому реальному вичерпанні, мають платити ринковий рівень. (Конкретний механізм і винятки — це вже деталі, але для більшости має бути щось по типу аукціона, наприклад, кожні 5 років.) Оскільки у нас один Internet, а не нескінченна кількість, то його адреси мають відповідати цьому принципу.
Один з перших. Тоді дійсно ще формулювали це як єдину мету — але, примітьте, ніде не сказано, що вона головна. Але вже в RFC2663, першому, що узагальнює накопичений досвід, явно сказано про користь ховання внутрішніх деталей і заборону довільних вхідних зʼєднань. Є сучасні приклади (а не часів, коли про Інтернет навіть в розвинених країнах більшість тільки чула?)
Та хоч в три рівні, якщо комусь треба (є чутки, що Воля-Кабель робить тільки в своїй мережі ще два рівні, на доданок до клієнтського). А ось у мене зараз не Воля, і я маю фіксований білий IP на своєму раутері. Про що це каже? А ось дві хмарні віртуалки, на Vultr білий IP прямо на інтерфейсі, а на AWS на інтерфейсі 172.31.x.x, хоча адреси транслюються 1:1 на бордері. І знову, хто більш правий?
Дякую за підтримку :)
А тому, що зараз і смартфон це повноцінний компʼютер з віртуалізацією всього, що можна: наприклад, Android штатно дозволяє зробити «вкладену» систему з підмножиною застосунків. Логічно для неї мати і окремий IP стек зі своєю адресою. А ще він штатно працює hotspotʼом...
Звісно, тут для більшости випадків і якогось /112 вистачило б, але поки в IPv6 префіксів між /64 і /128 не існує, про це не думаємо.
здрасті
оце старайся називається відповідай вишукуй
бермудський геній мабуть ото так само, розпереживався й подарував нам цілий IPv8, страшно уявити що б чекало на планету, якби не він
інтернет з секурними токенами якраз те що треба для операційок з нескучними обоями
256 портів це критично мало, одна вкладка в браузері може давати 10 зʼєднань одночасно = портів. Але... покажи мені підʼїзд, де у всіх білі айпішки? 192.168.0.0/16 це 16k адрес.
Ну, то ж 255 для вхідних з’єднань, а як там NAT буде шукати вільні порти для вихідних з’єднань, це вже інше питання. Не може ж бути прямо всі 255 хостів онлайн, щоб вичерпати пул. Та і це ж просто концепт, а не реальні числа, бо як мінімум не враховано зарезервовані сервісні порти роутера, хоча умовний 192.168.1.1 і так сам роутер. Можливо, половину портів NAT зарезервувати під пул вихідних з’єднань, а другу — на пул, щоб прокидувати по 128 портів в локальну мережу за NAT. 128 — це все одно добіса для побутового користувача, якщо зараз по суті нуль, якщо без всіляких там STUN.
Там ліміт 6 одночасних, і це менш актуально для HTTP/2 через мультиплексування в один тунель на оріджн.
Та не так давно було, але років з 8 як уже забрали. В будь-якому разі у когось є динамічні білі IP на абонента, стане на умовних 30 і при цьому можна вже давати статичну, вже економія адрес. Той, хто купляв статичний просто заради вхідних підключень, наприклад, до NVR поза хмарою, теж зможе обійтися. А кому дійсно треба окремий вже купить.
≈64k (254*256 == 65024).
У мене на раутер приходить білий IP. Це таки зручно.
Це просто маячня, яких випускають таких штук4-5 на рік.
Уж на що я нелюбитель IPv6 за несчисленні проблеми дизайну — точніше, що в деяких принципових моментах дизайну просто не було — але, всі подібні пропозиції спізнились на 20 років, а в дещому і 30. Все, поїзд пішов.
Ось краще зацініть цей драфт: datatracker.ietf.org/doc/draft-meow-mrrp
Тю, я знаю про що цей драфт. Це хотячка в моєї киці. Вона мені не спати не життя не дає. Як на дворі, то десяток котів за нею бігає, як дома то вона за мною бігає. Все точно як в драфті )))
Сама ідея і концепт дуже класні, це те чим по суті мав би бути IPv6, але проблема в тому що в IPv6 було надто багато вкладено грошей і вже поступово перейшли на нього(>50% трафіку в інтернеті), компанії гіганти вже все перебудували для них, і переходити на новий це ще раз проходити це пекло. Плюсом ідея ще надто нова і будуть ще роки дискусій і суперечок. Та й роботи щоб це все імплементувати багато. Тому якщо воно буде серйозно імплементуватись то я думаю що не менше 10 років потрібно для повного адекватного переходу.
А в чому «класність» ідеї?
Судячи по даті і
, хтось святкує перше квітня по старому стилю.
Думаю, це просто дурні.
Я в індустрії не довго, але на мої пам’яті, ще вже десь 5та пропозиція, якось розширити пул ip, були вже люди які знаходили, bit що «не використовується», і пропозиції, робити NAT — так ніби зараз їх не роблять, ну люди розважаються