Тим не менш, можна зробити головний висновок  – незалежно від того, чи надає на даному етапі ISP послуги зв’язів по IPv6 чи ні, все-одно є можливість переходу мережі без явного управління повністю на використання лише IPv6. Більше того, завдяки отриманим перевагам у використанні IPv6 всередині мережі, буде зростати попит на послуги зв’язів по IPv6, а отже це буде стимулювати ISP на розгортання 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, шлюз повинен прцювати, як рекурсивний сервер імен.

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

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

Вимоги локальних прикладних програм. Локальні прикладні програми повинні мати з’єднання лише в локальному масштабі. Вони мають продовжувати працювати навіть у випадку ізольованості мережі без явного управління від Інтернет.

Локальні прикладні програми, як правило, використовують спеціальні механізми для пошуку відповідності між іменами та IP адресами. Більшість з таких механізмів ліцензовані; прикладом стандартного механізму є протокол розміщення сервісу (service location protocol, SLP [29]).

Безпека локальних прикладних програм може бути значно підвищена, якщо мережу ізольовано від Інтернет.

Вимоги клієнтських прикладних програм. Клієнтські прикладні програми потребують з’єднання з глобальним Інтернет. Таким чином, очікується що клієнт буде використовувати глобальну IPv6 адресу, яка буде незмінна принаймі на час сесії клієнт-сервер.

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

Для клієнтських прикладних програм досить суперечливим питанням є питання приватності. Якщо адреса хосту, на якому виконується клієнтська прикладна програма, не змінюється на протязі довгого часу, то сторонні особи можуть визначити коло інтересів користувача конкретного хосту, що є порушенням приватності. Для вирішення цієї проблеми запропоновано механізм періодичної зміни ідентифікатору інтерфейсу в адресі IPv6 [30]. Проте, навіть за таких умов префікс адреси не змінюється, а отже можливе порушення приватності для мережі без явного управління. Слід зауважити, що при використанні IPv4 та механізму NAT ця проблема також присутня, оскільки по зовнішній глобальній IPv4 адресі шлюзу, так само як по IPv6 префіксу, можна ідентифікувати конкретну мережу. Через те, що проблема не була вирішена в IPv4 мережах, наявність її в IPv6 мережі не зменшує рівень безпеки.

Вимоги прикладних програм типу рівний-з-рівним. Програми такого типу потребують з’єднання з глобальною мережею. Очікується, що сторони будуть використовувати глобальні IPv6 адреси, незмінні на весь час сесії між вузлами.

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

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

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

Серверні прикладні програми для свого функціонування потребують запису в DNS для своєї адреси. Таким чином, сервер забезпечується „глобальним іменем в DNS”. Програми цього типу потребують чіткої відповідності між „глобальним іменем в DNS” та поточною IPv6 адресою. Через те, що зміни в DNS відбуваються достатньо повільно (цьому сприяє механізм кешування DNS відповідей), то бажано щоб IPv6 адреса залишалась незмінною. Ця практика була прийнята ще в IPv4 мережах, отже введення IPv6 не запроваджує нових обмежень.

Питання безпеки серверних прикладних програм багато в чому залежить від сутності самої програми та можливих побічних ефектів: в минулому було достатньо багато прикладів того, як відкритий доступ до одного з сервісів надавав можливість доступу до іншого сервісу на тому самому вузлі.

30. T. Narten, R. Draves, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”, RFC 3041, January 2001.

Далі – “Етапи розгортання IPv6“

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

Локальні прикладні програми. Локальність в таких програмах визначається лише тим, що взаємодія відбувається в межах мережі без явного управління. Типічним прикладом таких програм є загальний доступ до файлів (file sharing) або загальний доступ до принтерів (printer sharing).

Локальні прикладні програми ефективно працюють в IPv4 мережах без явного управління навіть у випадку, коли на шлюзі виконується функція NAT або захисного екрану. Це зображено на рис. нижче. Більше того, функції захисного екрану є бажаними в такому випадку, оскільки вони захищають локальні прикладні програми від небажаного доступу з Інтернет.

Локальні прикладні програми

Клієнтські прикладні програми. До такого типу програм можна віднести програми, в яких програма-клієнт знаходиться всередині мережі без явного управління, а програма-сервер знаходиться у віддаленій мережі. Прикладами такого типу програм є програми перегляду веб-сторінок (сторінки розміщені на відділеному веб-сервері), або поштові клієнти (в термінології електронної пошти вони називаються MUA – Mail User Agent), які отрмують пошту із зовнішніх поштових серверів по протоколу POP3 або IMAP.

Процес взаємодії зображено на рис:

Клієнтські прикладні програми

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

Клієнтські прикладні програми працюють без жодних проблем в мережах без явного управління, навіть якщо на шлюзі виконується функція NAT або захисного екрану: ці функції трансляції та захисту були розроблені саме для роботи клієнтських прикладних програм.

Прикладні програми типу рівний-з-рівним. Можливі 2 різновиди такого типу прикладних програм: обидві сторони взаємодії знаходяться в мережі без явного управління; одна із сторін знаходиться всередині мережі без явного управління, а інша сторона – поза мережею. Для розгляду можна прийняти лише другий різновид тіких програм, бо перший різновид легко звести до категорії локальних прикладних програм.

Прикладні програми типу рівний-з-рівним зазвичай не працюють в мережах без явного управління. Розробники прикладних програм змушені використовувати проміжний „сервер-ретранслятор” (relay server), в результаті чого з’єднання рівний-з-рівним перетворюється в пару з’єднаннь клієнт-сервер (рис. нижче).

Прикладні програми типу рівний-з-рівним

Серверні прикладні програми. Для такого типу програм характерно використання серверної частини всередині мережі без явного управління, а також клієнтських програм за межами цієї мережі. Типічним прикладом є встановлений на одному з хостів всередині мережі веб- або поштовий-сервер. Взаємодія в такому випадку відбувається по схемі, зображеній на рис:

Серверні прикладні програми

Використання таких програм вимагає спеціального програмування NAT або захисного екрану. В більшості випадків мережі без явного управління мають лише одну глобальну IP адресу для шлюзу, а тому з використанням технології трансляції портів, конкретний зовнішній порт може бути використаний лише одним внутрішнім сервером. Ще одна проблема при використанні таких серверних програм – це забезпечення кожного серверу постійним ім’ям в DNS, а також втановлення відповідності між цим ім’ям та глобальною IPv4 адресою шлюзу. З одного боку адміністрування DNS переводить такі мережі з розряду мереж без явного управління. З іншого боку іноді достатньо лише один раз сконфігурувати NAT та серверні програми і більше нічого не змінювати.

Далі – “Вимоги прикладних програм в IPv6 мережах без явного управління“

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

Мережі без явного управління

Між підмережею та каналом доступу ISP присутній шлюз, який може виконувати функції NAT та захисного екрану (firewall). Якщо шлюз виконує функції NAT, то всередині підмережі використовуються адреси з діапазону для приватного використання. Головна особливість таких мереж полягає в тому, що шлюз не керованим. В більшості випадків він є простим „пристроєм”, який використовує декілька статичних правил. Зазвичай, шлюз виготовляється і конфігурується самим ISP.

Канал доступу між мережею без явного управління та ISP може бути постійним (наприклад, xDSL), або динамічним (телефонне з’єднання або лінія ISDN). В найбільш простому випадку вся мережа без явного управління може бути представлена одним хостом, під’єднаним до ISP.

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

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

Для такого класу мереж основною вимогою при переході з IPv4 на IPv6 залишається можливість працювати з певним колом прикладних програм. Таких програм може бути дуже багато (електронна пошта, веб-сторінки, передавання файлів), проте всіх їх можна об’єднати в декілька груп в залежності від вимог, які вони вимагають від з’єднання.

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

Далі – “Прикладні програми“

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

Основна проблема, яка виникає при спробі аналізу можливих сценаріїв зміни протоколу мережного рівня в глобальних масштабах це неможливість проаналізувати всі варіанти. Для зменшення кількості варіантів необхідно розбивати множину розгляду на підмножини. Крім того, потрібно вводити додаткові обмеження, таким чином, щоб звести задачу переходу глобального Інтернет на протокол IPv6 до вирішення задачі переходу окремих частин мережі на IPv6.
Поступовість перехіду з IPv4 на IPv6 дозволяє розбити вісь часу на окремі періоди – фази переходу. Більше того, процес переходу окремих частин глобальної мережі на використання IPv6 не може бути синхронізовано, але маючи фіксовану кількість фаз переходу є можливість розглянути процес переходу в кожній з цих фаз.
Таким чином, існує значно менша кількість варіантів переходу на IPv6 в глобальних масштабах. Проте, навіть за такої кількості варіантів розробити концепцію переходу з IPv4 на IPv6 неможливо. Основна проблема, яка заважає цьому – істотна розбіжність у шляхах вирішення проблеми переходу для різних частин Інтернет ієрархії. Для того, щоб зрозуміти цю розбіжність необхідно розглянути структуру сучасного Інтернет.
Хоча сучасний Інтернет це складна мережа, проте в ній можна виділити наступні основні частини:
1. Магістраль. Цю частину Інтернет утворює обмежена кількість потужних операторів зв’язку, які, зазвичай, мають власні первинні мережі (мережі фізичного рівня моделі OSI), або вторинні мережі (мережі канального рівня моделі OSI). Серед таких операторів можна відокремити декілька – UUNET, AT&T, Sprint, Genuity, Level 3, Cable & Wireless. До цих мереж під’єднані маршрутизатори верхнього рівня, тобто маршрутизатори, які не мають запису про маршрут за замовчуванням, а мають записи про всі анонсовані мережі в світі. Крім маршрутизаторів операторів зв’язку до цих магістралей під’єднані також маршрутизатори великих ISP.
2. Інтернет Сервіс Провайдери (ISP). Цю частину Інтернет складають компанії, які є проміжною ланкою між користувачами і глобальним Інтернет. Мережа ISP напряму або через інші ISP приєднана до магістральної частини Інтернет (з використанням маршрутизаторів). Головне призначення ISP – це надання послуг доступу до Інтернет з використанням різноманітних технологій доступу (з’єднання через мережу з комутацією каналів, ISDN мережу, xDSL-технології, Wi-Fi, Ethernet, тощо).
3. Кінцеві користувачі. Це найбільша частина Інтернет. Саме кінцеві користувачі є основною рушійною силою розвитку Інтернет. Кінцевими користувачами є дуже велика категорія різноманітних по своєму розміру мереж – від одного хоста (домашні користувачі) до розгалудженої мережі з декількома маршрутизаторами, під’єднаними до різних провайдерів.
Цей розподіл зроблено на основі розділу Інтернет на зони впливу з точки зору управління. Зазначимо, що кожна з цих частин в плані управління є незалежною від інших, проте всі частини взаємопов’язані в плані свого призначення.
При розгляді питання механізмів переходу було висунуто низку вимог, одна з яких – незалежність в часі переходу одних частин мережі від інших. Таким чином, використовуючи вже розроблені механізми переходу, є можливість одночасного паралельного розгортання IPv6 на незалежних в плані управління частинах Інтернет.
Але перехід з IPv4 на IPv6 це достатньо довгий і тяжкий в фінансовому плані процес. Для того, щоб компанія почала розгортати IPv6 на своїй мережі, їй потрібне додаткове стимуювання. Для ISP таким стимулюванням будуть запити користувачів щодо надання IPv6-зв’язків, для магістральних операторів – запити ISP.
Багато мереж кінцевих користувачів не можуть використовувати всіх переваг глобальної мережі, оскільки не мають необхідної кількості IP адрес. Запровадження IPv6 для таких організацій – єдина можливість стати повноцінною частиною Інтернет.
Тому, перше положення концепції переходу – запровадження IPv6 слід починати на мережах кінцевих користувачів. Звичайно, без підтримки з боку ISP у вигляді префіксного призначення для мережі, використання IPv6 можливе тільки всередині мережі. Але за той час, поки використання IPv6 всередині мережі стане стабільним і потрібним, ISP вже почне розподіляти адресні префікси IPv6.
За проміжок часу між початком розгортання IPv6 на мережі користувача і на мережі ISP необхідно встигнути модифікувати ОС та прикладні програми для використання IPv6. Що стосується ОС, то ситуація дуже оптимістична:
• IP стек це частина ОС;
• Більшість сучасних ОС мають подвійний стек, а отже готові для IPv6;
• Для старіших ОС необхідні пакети оновлення.
Стосовно прикладного програмного забезпечення існує 2 підходи:
• Відкрите програмне забезпечення – будь-хто з бажаючих може внести відповідні зміни в код;
• Платне (закрите) програмне забезпечення – необхідно вимагати підтримку IPv6 від постачальника.
Для прикладу, модифікація популярної мережної гри „Quake” відбувалась всього 2 дні (написання та тестування), сумарний код мав обсяг 350Кбайт, а ці зміни були внесені до одного файлу.
Отже, друге положення концепції переходу – необхідне тестування і оновлення програмного забезпечення.
Враховуючи вимоги до механізмів переходу, а також неможливість одночасного оновлення всього програмного забезпечення, передбачається тривалий період співіснування мереж IPv4 та IPv6. Схематично цей процес зображено на рис:

Перехід від IPv4 до IPv6

Звичайно, кінцеві користувачі не є досвідченими мережними адміністраторами, а тому перехід з одного протоколу мережного рівня на інший для них  буде достатньо незрозумілим завданням. Саме тому, потрібна тісна співпраця між ISP та кінцевими користувачами, а також між магістральними операторами та ISP. Для такої співпраці необхідні чіткі правила.

Отже, третє положення концепції – розробка правил взаємодії між адміністративними частинами Інтернет в плані переходу до використання IPv6.

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

Для прикладу, розглянемо використання цієї концепції для мереж без явного управління – найпростіших мереж з категорії кінцевих користувачів.

Далі – “Мережі без явного управління“

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

Для нормального функціонування має бути принаймі один маршрутизатор, який виконує роль ретранслятора між доменом 6в4 і натуральним IPv6 доменом. Такий ретранслятор майже не відрізняється від звичайного маршрутизатора, окрім того, що він має принаймі один логічний псевдо-інтерфейс 6в4 та один IPv6 інтерфейс.

Таким чином отримуємо три різних класи доменів маршрутизації:

1. Внутрішній IPv6 домен маршрутизації для кожного сайту 6в4;
2. Зовнішній IPv6 домен маршрутизації, який поєднує заданий набір межових маршрутизаторів 6в4, маршрутизаторів-ретрансляторів, та зовнішній домен маршрутизації 6в4;
3. Зовнішній IPv6 домен маршрутизації для кожного з натуральних IPv6 островів.

Можливі 2 види зовнішнього IPv6 домену маршрутизації:

• Без використання протоколів зовнішньої маршрутизації IPv6. В такому випадку на кожному з маршрутизаторів існує маршрут за замовчуванням на маршрутизатор-ретранслятор. На маршрутизаторі-ретрансляторі виконується фільтрація за адресою відправників для того щоб приймати дані лише від визначених маршрутизаторів 6в4.
• З використанням протоколів зовнішньої маршрутизації IPv6. В такому випадку група з маршрутизаторів 6в4 отримує натуральні IPv6 маршрути від маршрутизатора-ретранслятора, використовуючи маршрутні протокли такі як BGP4+ [27]. Маршрутизатор-ретранслятор буде оголошувати всі наявні натуральні IPv6 префікси через свій псевдо-інтерфейс 6в4. Хоча таке рішення більш складне, проте воно дозволяє виконувати більш ефективний контроль за маршрутизаторами 6в4, які можуть працювати з визначеними маршрутизаторами-ретрансляторами.

Для прикладу розглянуто мережу з попереднього пункту. Припутимо, що IPv6 хост на вузлі Б робить запит в DNS для хосту з сайту А, і DNS повертає декілька IPv6 адрес з різними префіксами:

Комбінований сценарій

Для того, щоб сприяти двосторонньому обміну інформацією, маршрутизатор з вузла Б обирає за адресу відправника адресу 6в4 (2002:09fe:fdfc::/48).

Таким чином, використовуючи механізм 6в4 можна без зайвих зусиль з боку адміністраторів, з’єднати між собою розрізнені домени IPv6 через існуючу мережу IPv4.

Далі – “РОЗРОБКА КОНЦЕПЦІЇ ПЕРЕХОДУ“

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

Коли IPv6 хост в сайті Б виконує запит в DNS для пошуку адреси хоста в сайті А, він отримує адресу з префіксом 2002:c001:0203::/48

Об’єднання сайтів

Всередині сайту 6в4, адреси з префіксами 2002::/16, які не відповідають локальному префіксу 2002:IPv4_адреса::/48, будуть обслуговуватись як будь-які інші нелокальні IPv6 адреси, тобто за замовчуванням будуть направлені до межового маршрутизатора 6в4.

Коли вихідний пакет досягає маршрутизатора 6в4, він інкапсулюється. Вхідні пакети деінкапсулюються на маршрутизаторі 6в4.

За цим сценарієм будь-яка кількість сайтів 6в4 може взаємодіяти між собою без налаштування тунелів і додаткових вимог до IPv4 служб. Єдине, що необхідно зробити, це внести відповідні записи в DNS та налаштувати вхідну фільтрацію (аналогічно до “Вхідна фільтрація“). Маршрутизатор також повинен генерувати відповідні оголошення IPv6 префіксів.

Через те, що обидва сайти А і Б повинні використовувати маршрутні протоколи IPv6 лише всередині, вони не мають необхідності використовувати протоколи зовнішньої маршрутизації IPv6 – заовнішня маршрутизація IPv4 виконує цю роботу.

Рекомендовано використовувати лише одну IPv4 адресу для кожного з маршрутизаторів 6в4 і це повинна бути адреса, призначена зовнішньому інтерфейсу маршрутизатора 6в4.

Через відсутність налаштування і розподіленої моделі розгортання, не очікується проблем при масштабуванні підключень, виконаних за таким сценарієм.

Далі – “Комбінований сценарій з ретранслятором до натурального IPv6“

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

Специфікація, яка описує цей механізм [26], була написана до публікації [13], а тому оперує термінами ідентифікатор Агрегації Верхнього Рівня (Top Level Aggregator, TLA) та Агрегатор Наступного Рівня (Next Level Aggregator, NLA). Оскільки ці терміни вже не використовуються (використовується схема, описана в  п. 2.3), то опис, наведений в цій роботі, буде дещо відрізнятись від специфікації:

Таким чином, префікс має формат /48 і може бути записаний у вигляді 2002:IPv4_адреса::/48. Цей префікс може використовуватись як і будь-який інший IPv6 префікс в таблицях маршрутів.

Інкапсуляція в IPv4.

Процес інкапсуляції IPv6 пакету в пакет IPv4 детально описано в розділі “Інкапсуляція пакетів“. Механізм „6в4” використовує ті ж самі принципи інкапсуляції.

Далі – “Сценарії використання. Об’єднання сайтів″

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

При використанні механізму „IPv6 в IPv4” (інша назва „6в4”) жодних додаткових записів не додається до існуючих таблиць маршрутів IPv4. Єдиний запис додається до IPv6 таблиць маршрутів. Також не має потреби в використанні IPv4-сумісних IPv6 адрес.

Хоча механізм пропонується використовувати для з’єднання сайтів IPv6, проте він може бути використаний для з’єднання окремих хостів або дуже малих сайтів. Єдина вимога, що при цьому залишається, це наявність хоча б одної глобальної унікальної IPv4 адреси.

Специфічна для даного механізму термінологія:

Зауваження: в деяких випадках IPv6 хост може використовувати адресу 6в4 для конфігурованого тунелювання. Такий вузол може функціонувати як IPv6 хост, використовуючи адресу 6в4 на своєму сконфігурованому інтерфейсі, а також він може виступати як IPv6 маршрутизатор для інших хостів через псевдо-інтерфейс 6в4, але це різні функції.

Далі – “Призначення IPv6 префіксу“

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