Етапи розгортання IPv6

Для розгляду буде прийнято ситуацію мережі, в якій ще не почалося розгортання IPv6. Буде розглянуто етапи, на останньому з яких IPv4 інфраструктура може бути згорнута, тобто відбудеться повний перехід на IPv6. Звичайно, цей процес буде відбуватись декілька років. Більше того, до уваги потрібно прийняти відсутність синхронізації переходу на IPv6 між різними частинами мережі.

Для того, щоб більш ясно розглядати процес переходу мережі без явного управління на IPv6, необхідно відокремити 3 основні складові такої мережі: ISP (можливо, з обладнанням доступу – CPE), шлюз, хости (комп’ютери та інтелектуальні пристрої). Кожен з цих складових може перебувати в одній з трьох стадій підтримки IPv6: без підтримки IPv6 (лише IPv4), підтримка обох протоколів IPv4 та IPv6, підтримка лише IPv6. В результаті отримуємо 27 можливих варіантів. Для розгляду можна вибрати лише основні з них. Будемо вважати, що в кожному випадку хости є групою з IPv4-хостів, хостів з подвійним стеком, лише-IPv6 хостів.

Таким чином отримуємо наступні варіанти:

A)  шлюз без підтримки IPv6;

B)   шлюз з подвійним стеком, який під’єднано до ISP, що підтримує обидва протоколи;

C)   шлюз з подвійним стеком, який під’єднано до ISP, що підтримує лише IPv4;

D)  шлюз, під’єднаний до ISP, який підтримує лише IPv6.

В більшості цих випадків передбачається використання механізму NAT на шлюзі. Варіанти, де такий механізм не використовується можуть бути зведені до наведених вище варіантів.

Варіант А

Цей варіант вирізняється тим, що шлюз не має підтримки IPv6. В такому випадку ISP може мати підтримку IPv6 або не мати її, але все одно шлюз не буде забезпечувати можливість використання IPv6 сервісів. Цей варіант є найбільш розповсюдженим варіантом при використанні апаратних шлюзів. Хоча потрібно відмітити той факт, що такі пристрої, зазвичай, мають можливість оновлення програмного забезпечення. А отже, з появою оновленого програмного забезпечення цей варіант може бути переведений до варіантів B, C, або D, в залежності від можливостей ISP.

Підтримка прикладних програм для Варінту А. За вказаних вище умов, головною метою є забезпечення обміну даними між хостом в мережі без явного управління та лише-IPv6 хостом за межами мережі. Основна увага в найближчому майбутньому буде надана програмам типу рівний-з-рівним. Локальні прикладні програми не зазнають змін при Варіанті А, оскільки вони і далі можуть використовувати IPv4. Серверні програми також не зазнають змін, оскільки вони занадто залежні від системи DNS, яка в умовах NAT не може бути ефективно використана для IPv4 та IPv6 з’єднань. Для клієнтських програм потрібно забезпечити можливість з’єднання з зовнішніми лише-IPv6 серверами.

За таких умов, прикладні програми типу рівний-з-рівним є найбільш вдалим рішенням для використання. Такі програми розвиваються узгоджено з розвитком мереж рівний-з-рівним. Більше того, такі мережі мають власну систему імен, а отже не залежать від DNS.

Адресація та зв’язність для Варіанту А. Оскільки передбачається, що на шлюзі буде використовуватись механізм NAT, то єдиним способом підключення до зовнішніх мереж є спеціальний вид тунелювання з можливістю обходу NAT (NAT traversal). На сьогодні існують такі рішення, одне з яких розглянуто далі. Завдяки такому підходу, хост отримує глобальну IPv6 адресу і може використовувати прикладні програми клієнтського типу та типу рівний-з-рівним.

Служби імен для Варіанту А. Головна задача полягає в тому, щоб забезпечити хости бібліотекою визначальника, яка підтримує визначення IPv4 та IPv6 адреси по імені та навпаки. Проблема може виникнути з механізмом зворотнього пошуку в DNS. Деякі з серверних програм (наприклад, поштові) вимагають, щоб результат зворотнього пошуку збігався з іменем хосту. Якщо збігу не відбувається, то у встановленні з’єднання може бути відмовлено. Таким чином, для цього віріанту дуже важливим є можливість внесення змін до зворотніх зон DNS.

Варіант B

Цей варіант передбачає, що ISP та шлюз мають подвійний стек. В такому випадку шлюз може мати натуральне IPv6 підключення до мережі провайдера з використанням IPv6 префіксу, наданого провайдером.

Підтримка прикладних програм для Варінту B. Якщо мережа ISP та шлюз мають подвійний стек, то клієнтські прикладні програми, програми типу рівний-з-рівним та серверні програми можуть використовуватись без жодних проблем на мережі без явного управління.

Очікується, що на мережі без явного управління будуть присутні три типи хостів: лише-IPv4, лише-IPv6 та хости з подвійним стеком. Якщо хости з подвійним стеком можуть взаємодіяти з усіма іншими хостами, то хости з підтримкою лише одного протоколу можуть це зробити лише через транслюючі сервіси. Проте використання таких сервісів є небажаним, оскільки воно загальмує розвиток IPv6. Крім того, розробка і підтримання таких сервісів не є легкою справою. Для підтвердження цієї думки можна звернутись до роботи [31], де описано створення транслюючого проксі-серверу лише для одного протоколу – HTTP.

Таким чином, єдина можливість надання сервісів як IPv4 так і IPv6 хостам це використання подвійного стеку на хостах, які виконують серверні програми.

Адресація та зв’язність для Варіанту B. Для цього варіанту шлюз з оновленим програмним забезпеченням працює, як IPv6 маршрутизатор. Звичайно, що він продовжує забезпечувати зв’язки по IPv4 завдяки використанню NAT. Вузли в локальній мережі можуть мати наступні типи адрес:

–          IPv4 адреса (з приватного діапазону, або IPv4 адреса шлюзу),

–          IPv6 адреса локальна в межах каналу зв’язку,

–          IPv6 глобальна адреса.

Для того, щоб використовувати IPv6 з’єднання з Інтернет, шлюз повинен отримати від ISP глобальний адресний префікс, а потім оголосити хостам про наявність такого префіксу.

Служби імен для Варіанту B. Для цього випадку хости в мережі без явного управління можуть використовувати як IPv4 так і IPv6 доступ до DNS серверу провайдера – все залежить лише від підтримки цих протоколів на самих хостах. Однією з проблем є розміщення адресної інформації про локальні сервери в DNS. Для вирішення цієї проблеми може бути використаний механізм делегування частини домену ip6.arpa від DNS серверу провайдера до „локального” DNS серверу. Єдина вимога, що залишається, це доступність „локального” DNS серверу для зовнішніх DNS клієнтів.

Проблеми, які можуть виникнути при використанні DNS хостами, які мають підтримку обох протоколів були наведені в п. “Доменна система імен”.

Варіант С

Для цього варіанту визначним є відсутність підтримки IPv6 в мережі ISP, але наявність подвійного стеку для шлюзу. Такий варіант є характерним для випадку використання програмних рішень на основі мережних ОС (наприклад, шлюз на основі ОС FreeBSD). Такі шлюзи вже довгий час мають підтримку IPv6, в деяких (таких як, FreeBSD, OpenBSD, NetBSD, Linux 2.6.x) ця підтримка активована за замовчуванням, але в деяких (Linux 2.4.x, Microsoft Windows Server family) таку підтримку достатньо лише активувати. Проте, яка б ОС в шлюзі не використовувалась, все одно натурального IPv6 з’єднання з ISP встановити для цього варіанту неможливо.

Підтримка прикладних програм для Варінту C. Для цього варіанту характерні ті ж особливості, що і для Варіанту B.

Адресація та зв’язки для Варіанту С. Для цього варіанту шлюз з оновленим програмним забезпеченням виступає, як IPv6 маршрутизатор. Звичайно, що він продовжує забезпечувати IPv4 зв’язки завдяки використанню NAT. Вузли в локальній мережі можуть мати наступні типи адрес:

–          IPv4 адреса (з приватного діапазону, або IPv4 адреса шлюзу),

–          IPv6 адреса локальна в межах каналу зв’язку,

–          IPv6 глобальна адреса.

Існує 2 шляхи для забезпечення IPv6 зв’язків через IPv4 інфраструктуру – автоматичне тунелювання та конфігуроване тунелювання. Обидва ці види були детально розглянуті ( див “Конфігуроване тунелювання” та “Автоматичне тунелювання“).

Служби імен для Варіанту С. В своїй основі вимоги до служби імен залишаються ті самі, що і для Варіанту В. Єдина зміна стосується механізму делегування для зони зворотнього пошуку. Якщо використовуються механізми автоматичного тунелювання, то необхідно забезпечити відповідність між отриманим префіксом і записами в зоні зворотнього пошуку.

Варіант D

Найважливіша риса цього варіанту в тому, що ISP не надає послуг по IPv4 з’єднанню. Отже, шлюз не має з’єднання з глобальною IPv4 мережею, але всередині мережі без явного управління можуть бути присутні 3 види хостів – лише-IPv4, лише-IPv6 та хости з подвійним стеком. Для забезпечення зв’язності з IPv4 Інтернет ISP повинен запровадити послугу міжпротокольної трансляції.

Підтримка прикладних програм для Варінту D. На цій фазі переходу IPv6 хости можуть використовувати всі типи прикладних програм для з’єднання з іншими IPv6 хостами. IPv4 хости всередині мережі можуть використовувати локальні прикладні програми для взаємодії з іншими IPv4 хостами в мережі, або з двопротокольними хостами.

Потрібно зауважити, що відсутність можливості з’єднання по IPv4 з іншими хостами в глобальному Інтернет через відсутність такої послуги, робить ISP менш конкурентноспроможним в порівнянні з іншими ISP, які надають такі послуги.

Існує три можливі варіанти, завдяки яким ISP може надавати зв’язкі по IPv4: використовуючи набір ретрансляторів прикладного рівня; використовуючи сервіс трансляції адрес; використовуючи тунелювання IPv4 над IPv6 (IPv4-over-IPv6). З цих трьох методів найбільш вживаним буде тунелювання, оскільки на той час вже буде достатній досвід використання тунелів типу IPv6 над/в IPv4, а технології ретрансляторів, які вже згадувались для Варіанту В, є достатньо складними.

Адресація та зв’язкі для Варіанту D. В цьому випадку ISP призначає IPv6 префікс для мережі без явного управління. Таким чином, хости матимуть глобальну IPv6 адресу, яку можна використовувати для забезпечення глобальних IPv6 зв’язків. Делегування IPv6 префіксу має відбуватись за тих самих умов, що і для Варіанту В.

Для задоволення потреби IPv4 хостів та хостів з подвійним стеком в з’єднанні з віддаленими IPv4 хостами, ISP повинен надати спеціальний шлюз, який має принаймі одну IPv4 адресу і використовує механізм тунелювання IPv4 над IPv6.

Служби імен для Варіанту D. Відсутність IPv4 зв’язків має прямий вплив на забезпечення служби імен. В багатьох мережах без явного управління хости отримують параметри конфігурації DNS від локального шлюзу, зазвичай, через DHCP. В даному варіанті такий механізм можливо реалізувати лише з використанням IPv6. Також потрібно відмітити, що для всіх запитів до DNS буде використовуватись IPv6. Що стосується IPv4 хостів в локальній мережі, то для того щоб вони могли використовувати DNS, шлюз повинен прцювати, як рекурсивний сервер імен.


31. Eiji Kawai, Kiyoshi Tsukada, Akira Shirahase, Suguru Yamaguchi, “Practical Migration Strategy to IPv6 for Enterprise Web Services”, Cyber Kansai Project (CKP). http://www.ckp.jp/indexe.html.

Далі – “Висновок

Опубліковано на сайті: “IPv6 українською

Advertisements

2 Responses to Етапи розгортання IPv6

  1. Max коментує:

    Ну і які провайдери вже надають підтримку IPv6 ?

  2. ipv6ua коментує:

    Та взагалі багато хто, якщо в світовому масштабі. Але наразі не слідкую за цим, тому не можу дати точні дані

Залишити відповідь

Заповніть поля нижче або авторизуйтесь клікнувши по іконці

Лого WordPress.com

Ви коментуєте, використовуючи свій обліковий запис WordPress.com. Log Out / Змінити )

Twitter picture

Ви коментуєте, використовуючи свій обліковий запис Twitter. Log Out / Змінити )

Facebook photo

Ви коментуєте, використовуючи свій обліковий запис Facebook. Log Out / Змінити )

Google+ photo

Ви коментуєте, використовуючи свій обліковий запис Google+. Log Out / Змінити )

З’єднання з %s

%d блогерам подобається це: