Перехід від стратегій IPv4 до IPv6

Як всім відомо, у нас немає адрес IPv4, і незабаром (якщо ще не буде) ми переходимо до IPv6. Які є хороші стратегії та практики для міграції повної мережі IPv4 на IPv6?

Я не маю повної стратегії, але ось грубо, як я це зробив у $ JOB [-1]:

1. Отримайте блок IPv6 або з вашого існуючого оператора, або з RIR
2. Ви також можете позначити блок fc00 :: / 7 (Унікальний локальний) для повністю внутрішніх підмереж, якщо у вас є блок провайдерів, і вам може знадобитися перенумерування
3. Вирішіть про свій V6 IGP, IS-IS все ще є більш безпечним варіантом, ніж OSPFv3, але багато комплект не зробить IS-IS
4. Виведіть v6 на свій основний комплект, від Інтернету до крайніх комутаторів постійного струму
5. Якщо ви перейдете до транзиту v6, якщо у вас є тунель BGP з he.net, він може працювати, очікуючи, що провайдер застряг в останньому десятилітті (не забудьте включити v6 на вашій мережі iBGP, якщо у вас є)
6. Створити інфраструктурні служби v6, в основному DNS, доступні v4 тут добре
7. Увімкніть v6 в одній серверній мережі (ви, мабуть, тут брандмауері заперечуєте за замовчуванням)
8. Перевірте підключення v6 до світу, чи це порушить справи?
9. Поверніть v6 на другу серверну мережу для надмірності
10. Підберіть сервер DHCPv6, якщо ви хочете ним користуватися
11. Вивести v6 в єдину мережу доступу (ІТ-персонал тут хороший вибір)
12. Тест. Переконайтесь, що нічого не ламається
13. Вивести v6 на сервери, що залишилися
14. Додайте назву v6 імені v6 для своїх доменів та запис DNS v6 для MX (один або всі, крім одного, є хорошим вибором для подвійного стека)

Тепер, відкриваючи нові сервіси або оновлюючи їх, ви можете перевірити, чи вони працюють на v6, і додати відповідні записи DNS (майже всі веб-сервіси будуть "просто працювати"), з часом ви можете почати шукати служби, що залишаються на v4, і виправити їх , але поспішати з цим немає.

Я думаю, що тут важливо розділити дві різні цілі:

• Робота з підтримкою IPv6. Основні проблеми з цією метою зазвичай пов'язані з обладнанням у вашій мережі, що не підтримує IPv6, і вам потрібно використовувати якесь рішення для тунелювання / транспорту, щоб обійти ці елементи. 6-а та 6ПЕ дуже популярні.
• З іншого боку, існують стратегії протидії вичерпанню адреси IPv4. Єдиний спосіб вирішити це питання - це реалізація якихось NAT (клас NAT, DSLite, NAT64 ...)

Деякі технології вирішують перше питання, деякі вирішують друге, а деякі вирішують обидва.

Все розвивається дуже швидко, і ви повинні стежити за новими рішеннями, що виникають. Наприклад. Одне рішення, яке останнім часом привертає багато уваги, - це MAP-E та MAP-T, які наразі знаходяться у статусі проекту (MAP-E близький до того, щоб стати RFC) і дозволяють реалізувати IPv6 та вирішувати виснаження IPv4 адреси дуже розумно шлях. Додаткову інформацію можна отримати на http://tools.ietf.org/html/draft-ietf-softwire-map-06

Щоб отримати більш детальну інформацію, мені потрібно знати контекст та вимоги. Я маю на увазі, рішення залежать від типу мережі (Постачальник послуг сильно відрізняється від постачальника вмісту чи малої бізнес-мережі) та мети, яку ви намагаєтеся досягти.

З повагою,

Дієго Нуево

Міграція IPv6 на високому рівні?

1. Увімкніть IPv6 у всій мережі, поки можливості та зв’язок IPv6 не будуть рівні з IPv4.
2. Зачекайте наступного дня, коли IPv4 вже не актуальний.

Тепер про низький рівень:

Отримайте префікс (в ідеалі з RIR) і озвучіть його, я рекомендую OSPFv3 для вашого IGP, якщо у вас не трапляється велика плоска мережа, до якої ви вважаєте, що IS-IS краще підходить. Якщо у вас є застаріле обладнання, призначене лише для IPv4, подумайте про те, щоб обійти це, зробивши тунелі 6in4 або GRE по всій апараті.

Якщо у вас є план управління адресами, простір IPv6 не є цінним, якщо у вас є / 32, і ви думаєте, що клієнти хочуть чогось більшого, ніж / 64, спрямовуйте достатньо місця до вашого обладнання; якщо один маршрутизатор або пара маршрутизаторів обслуговує 100 клієнтів, і кожен отримує / 56, ваш IGP не повинен містити кожного / 56 - виділіть / 48 для цього маршрутизатора (пари), і ви закінчили. Простір IPv6 настільки величезний, що фрагментація підмережі ніколи не повинна бути необхідною, якщо ви робите це правильно.

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

Почніть знайомитися з технологіями, які запобігають катастрофам, коли у вас немає простору IPv4 і ви не зможете отримати його більше - тримайте палець на пульсі таких речей, як NAT64 і 464XLAT, щоб, коли настає час, можна визначити життєздатність наявності IPv6 розміщує лише хостинг, використовуючи простір RFC6598 та NAT44 (4). Налаштуйте лабораторію, експериментуйте.

Тоді? Зачекайте на заохочення вітрів IPv4.

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

Повернення ipv6 - це хороший перший крок https://networkengineering.stackexchange.com/a/261/20201, який допомагає вирішити це . Це дозволяє вам взаємодіяти з пристроями, що працюють лише в v6 в Інтернеті, це зменшує навантаження на ваші NAT і, отже, зменшує кількість зовнішніх IP-адрес / портів, необхідних для обслуговування цих NAT. З великими сервісами, такими як Google і facebook, що підтримують IPv6, швидше за все значна частина інтернет-трафіку переміститься (я бачив цифри до 70%).

Наступне питання, яке ви повинні задати собі, - чи є ваша організація достатньо великою, щоб ризикувати втратою приватного IPv4. Для переважної більшості організацій відповідь буде «ні».

Якщо припустити, що відповідь - ні, я не бачу мало підстав для видалення приватного IPv4 з існуючих розгортань найближчим часом. Позбавлення приватного IPv4 може трохи спростити адміністрування в довгостроковій перспективі, але в короткостроковій перспективі це принесе багато додаткових зривів для невеликого прибутку.

Якщо у вас не вистачає загальнодоступних версій v4, наступним кроком буде аудит вашого загального користування v4. Шукайте загальнодоступні адреси v4, які можна було б звільнити, змінивши підмережу. Шукайте системи, які могли б перейти з загального ipv4 на ipv6 або приватного ipv4. Розгляньте такі схеми, як балансири навантаження та DNAT, які можуть застосовувати невеликий пул загальнодоступних V4-адрес саме там, де вони потрібні, а в деяких випадках ділять загальнодоступну v4-адресу серед кількох служб.

Подумайте про розгортання шлюзу NAT64 / DNS64, щоб нові системи могли бути зроблені лише v6 та все ще мати доступ до ресурсів в ipv4 Інтернеті.