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

Через те, що розглядається питання переходу на IPv6, необхідно сформулювати вимоги прикладних програм, які можуть бути об’єднані в такі категорії: прикладні програми, які працювали з IPv4 мають продовжувати працювати на протязі переходу; використання IPv6 має забезпечити розгортання нових програм, які неможливо використовувати в мережах IPv4. Основні питання, які необхідно вирішити для кожного типу прикладних програм такі: з’єднання через IPv6; перетворення імен; безпека. З’єдання через IPv6 має аспекти, пов’язані з адресами IPv6  – чи потрібна хосту адреса глобального масштабу, на який термін часу потрібно виділяти цю адресу. Перетворення імен стосується управління іменами для хостів: чи потребує хост запису в DNS, а також запису для зворотного пошуку. Питання безпеки мають можливі обмеження щодо встановлення з’єднань, питання приватності, а також все інше, що може стосуватись безпеки прикладних програм.

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

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

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


29. E. Guttman, C. Perkins, J. Veizades, M. Day, “Service Location Protocol, Version 2”, RFC 2608, June 1999.

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

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

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

Advertisements

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

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

Лого WordPress.com

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

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

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