Після нещодавнього розгляду UDP-бродкасту та мережевої підмережі в межах IPv4, настав час звернути увагу на слона в кімнаті — протокол IPv6. Хоча наразі це лише чутка, нібито IPv6 має замінити шановний протокол IPv4. Це не просто IPv4 з більшою кількістю адрес; його розробники скористалися можливістю кардинально переробити протокол для футуристичного світу кінця 90-х — початку 2000-х.
Жарти на бік, але IPv6, представлений у 1995 році, і досі боротьба за витіснення IPv4 викликає занепокоєння щодо того, наскільки легко перейти між цими двома фундаментальними інтернет-протоколами. Наприклад, якщо ми захочемо приєднатися до майбутнього 2000-х і адаптувати наше програмне забезпечення для роботи з IPv6 замість IPv4, що зміниться у згаданих аспектах UDP-бродкасту та підмережі IPv4?
Виступаючи як необізнаний розробник, який знає IPv6 переважно з тих дивних і важкозапам’ятовуваних мережевих адрес, а також з багатьох зламаних реалізацій маршрутизаторів, я не цілком переконаний, що мені сподобається те, що я побачу.
Футуристичний бродкаст
Ми бачили, що з UDP-бродкастом IPv4 це зводилося переважно до визначення адреси бродкасту мережевого інтерфейсу на основі його підмережі або використання найпростішого режиму з локальною адресою бродкасту. Однак у випадку IPv6 нічого з цього не існує. Це ставить запитання: як наш самотній UDP-пакет може досі запитувати всіх у мережі IPv6, чи бачили вони певну мережеву службу?
Проста відповідь полягає в тому, що IPv6 має спеціальну групу багатоадресної розсилки (multicast) на рівні каналу зв’язку з адресою ff02::1, яка функціонує майже ідентично до IP-бродкасту. Це еквівалент багатоадресної розсилки IPv4 на адресу 224.0.0.1, тому це технічно не нова функція, просто багатоадресна розсилка є необов’язковою в IPv4.
Хоча багатоадресна розсилка IPv4, здавалося б, загалом реалізована, показово, що, незважаючи на значну кількість часу, витраченого на дослідження бродкасту IPv4, я не бачив, щоб ця функція «багатоадресної розсилки до всіх» де-небудь використовувалася. Можливо, це робить IPv4 та багатоадресну розсилку IPv4 вартими окремої статті, оскільки це здається цілим іншим супермаркетом консервів.
Крім того, якщо поглянути на це з дещо філософсько-технічного кута зору, то розгляд бродкасту як ще одного типу багатоадресної розсилки має багато сенсу. Замість того, щоб виділяти підмножину вузлів в мережевому інтерфейсі, ми просто натискаємо опцію «всі». Дуже просто й елегантно по-своєму.
Підмережеві речі
Якщо IPv4-підмережі — це чудова тема, яка може розважити будь-якого системного адміністратора протягом днів і щасливо вибухне програмне забезпечення, написане невігласом-розробником — який до того моменту був блаженно не обізнаний про підмережі, крім /24 — то розробники IPv6 поглянули на це справжнє джерело розваг і вирішили, що їм це не потрібно.
В IPv6 ви отримуєте одну підмережу, яка є /64, і ви навчитеся любити всі її 2^64 можливі адреси. Оскільки це приблизно в чотири мільярди разів більше адресного простору, ніж у IPv4, це дає вагомий аргумент на користь того, що підмережі стають непотрібними.
Звісно, хоча люди, які розробляли RFC для IPv6, були задоволені цими змінами, це свого роду тривалий жарт, що це найгірше, що сталося з системними адміністраторами з часів IPv4.
Стандарт 2017 року
Трохи менший слон у кімнаті, який ховається в тіні слона IPv6 з неоновою вивіскою, — це той, що носить рукописний RFC 8200 на шиї, прив’язаний мотузкою. Саме тоді IPv6 RFC отримали рівень зрілості «Інтернет-стандарт», що змусило декого поставити під сумнів, чи був поштовх до переходу на IPv6 у попередні роки взагалі виправданим.
Цей маленький факт — лише одна з багатьох проблем, які мають мережеві фахівці з IPv6. Наприклад, цей розбір 2020 року від Teknikal_Domain, головний акцент якого полягає в тому, що замість того, щоб бути просто IPv4 з 64-бітним адресним простором і деякими згладженими вадами IPv4, він вирішив додати багато деталей та складнощів, яких ніхто не просив, і нові вади, яких можна було б легко уникнути.
Дратує, звісно, те, що виділення інтернет-адрес IPv4 майже вичерпано скрізь, що означає, що ви або маєте щастя мати IP-адресу IPv4, або вам доведеться платити хостинг-провайдеру додатково, або ваше інтернет-з’єднання матиме лише IPv6-з’єднання, а IPv4-частина буде закинута за carrier-grade network address translation (CG-NAT), яка вбиває більшість програм, специфічних для IPv4.
Перехід з IPv4 на IPv6 також є болісним, оскільки між двома протоколами немає прямої сумісності; IPv6 має «інкапсулювати» пакети IPv4, використовуючи подвійний мережевий стек на стороні мережевого обладнання. На жаль, це також означає, що в Інтернеті тепер є секція, яка працює тільки з IPv4, підмножина тільки з IPv6 та вузли, здатні працювати з IPv4/v6, які можуть мати або не мати зламану реалізацію подвійного стеку.
Очевидно, це нікому не допомагає, і можна стверджувати, що для локальних мереж (LAN) IPv4 — це все, що вам потрібно.
Перспектива відкриття UDP
Хоча ідея очищення заплутаних опцій бродкаст-адрес IPv4 за допомогою простої опції багатоадресної розсилки — це чудова ідея, яку я обов’язково спробую у функції багатоадресної розсилки IPv4, а відсутність підмереж — це бажане спрощення, але вся концепція виявлення служб стає дещо дивною з IPv6.
По-перше, IPv6 не використовує NAT, і якщо ви не використовуєте немаршрутизований префікс, ваша локальна мережа не буде приватною у сенсі NAT LAN IPv4. На щастя, IPv6 підтримує NPT, що по суті є NAT, але з префіксами замість адрес, тому це зовсім інше.
Хоча з маршрутизованими префіксами IPv6 можна було б цілком реалізувати глобальне адресне просторове виявлення служб, це, очевидно, було б менш бажаним. Оскільки виявлення служб зазвичай стосується лише пристроїв у локальній мережі, це робить використання IPv6, щонайменше, сумнівною пропозицією, а в найгіршому випадку — небезпекою.
Зрештою, хоча IPv6 в деяких аспектах здається привабливим, коли ви розглядаєте його повністю, це справді викликає бажання, щоб він був, по суті, IPv4 з більшим адресним простором та обов’язковими функціями, такими як багатоадресна розсилка. Поки що це означає, що коли йдеться, наприклад, про мою бібліотеку виявлення служб NyanSD, я не бачу причин використовувати UDP-бродкаст у стилі IPv6, навіть якщо бібліотека вже отримує IP-адресу IPv6 будь-якої знайденої служби.
Цілком можливо, що я помиляюся, і через кілька років ми всі будемо використовувати тільки IPv6 у наших локальних мережах, в ідеалі з глобально маршрутизованими IP, як це було в Інтернеті 90-х, коли люди підключали свої ПК безпосередньо до модему без NAT або інших міркувань.