Які точні відмінності між "маршрутизованим префіксом" та "префіксом зв'язку" для IPv6?
Як ці відмінності в дротяній скарбці-сліді? (якщо ви спостерігаєте хоста з призначеним "маршрутизованим префіксом" або хоста з призначеним "префіксом зв'язку").
Як впливають ці відмінності в Протоколі про відкриття сусідів? (з точки зору іншого / зовнішнього хоста)
Чи працюють вони разом , ці два типи префіксів?
Відповіді:
Найпростіший спосіб зрозуміти різницю між ними - це приклад, що показує ієрархічний характер префіксів.
Приклад ієрархії
Провайдеру було виділено префікс з RIR (Регіонального Інтернет-реєстру), який у цьому прикладі ми будемо вважати таким 2001:db8::/32. Цей префікс відрізняється від тих, що передаються клієнтам, в тому сенсі, що провайдеру доведеться оголосити його через BGP іншим Інтернет-провайдерам, з якими він працює.
Зараз провайдер надасть клієнтам приставки. Спочатку вони призначають 2001:db8:0:1::/64посилання, що з'єднує маршрутизатор ISP з маршрутизатором CPE (обладнання для клієнтів). Це префікс посилання, оскільки він присвоєний посиланню. Загальною рекомендацією повинні бути всі префікси посилання в IPv6 /64.
Маршрутизатор ISP надсилатиме маршрутизатору рекламу, що оголошує цей префікс, і CPE використовуватиме SLAAC для побудови адреси для зовнішнього інтерфейсу, який спрямований на маршрутизатор ISP всередині /64. Припустимо, що зовнішній інтерфейс отримав IP-адресу 2001:db8:0:1:42:ff:fe00:42/64(в цю нотацію /64включено, щоб нагадати нам, яка довжина префіксу посилання, але я також міг його залишити).
Цей префікс посилання достатній для того, щоб маршрутизатор CPE міг спілкуватися з рештою світу, але це не допомагає маршрутизатору CPE підтримувати будь-яких клієнтів у локальній мережі, підключених до його внутрішнього інтерфейсу. Маршрутизатору CPE потрібен префікс для локальної мережі, який проходить через цей маршрутизатор CPE, отже, це називається маршрутизованим префіксом .
Спрямований префікс може бути налаштований статично або через DHCPv6. Точна інформація про те, як маршрутизатор CPE узгоджує довжину префікса з сервером DHCPv6, наданим провайдером послуг, виходить за рамки цієї відповіді. Пошук делегування префіксів може розповісти вам більше про це. Припустимо, що в результаті закінчився маршрутизований префікс 2001:db8:1::/48. На маршрутизаторі ISP буде створено запис таблиці маршрутизації, який вказує 2001:db8:1::/48на необхідність маршрутизації через шлюз 2001:db8:0:1:42:ff:fe00:42. Цей запис таблиці маршрутизації є визначальною особливістю маршрутизованого префікса.
Маршрутизатор CPE може мати декілька внутрішніх локальних мереж, з них /48він може виділити /64префікс посилання для кожної внутрішньої локальної мережі. Якщо ми припускаємо, що одна з локальних мереж була призначена 2001:db8:1:1::/64як префікс посилання, вузол цього посилання може отримати адресу 2001:db8:1:1::42:ff:fe00:43через SLAAC. Цей вузол може бути бездротовим маршрутизатором, для якого потрібен префікс для його бездротового інтерфейсу. CPE може призначити 2001:db8:1:100::/60префікс маршрутизованого бездротового маршрутизатора, а бездротовий маршрутизатор може призначити 2001:db8:1:100::/64префікс зв'язку для бездротового інтерфейсу.
Тепер у таких налаштуваннях є ієрархія префіксів. Нижче наведені всі вкладені один під одного:
2001:db8::/32 BGP оголосив префікс2001:db8:1::/48 маршрутизований префікс2001:db8:1:100::/60 маршрутизований префікс2001:db8:1:100::/64 префікс посиланняЯк реально обробляються пакети
Коли маршрутизатор ISP отримує пакет, для 2001:db8:0:1::/64якого є префікс посилання, він виконує пошук сусіда, щоб знайти MAC-адресу хоста в межах /64.
Таким чином, маршрутизатору провайдера потрібно буде окремий запис кешу сусіда для кожної IP-адреси в префіксі посилання.
Коли маршрутизатор ISP отримує пакет, для 2001:db8:1::/48якого є маршрутизований префікс, він виконує пошук сусідів, щоб знайти MAC-адресу шлюзу 2001:db8:0:1:42:ff:fe00:42.
Таким чином, маршрутизатору ISP потрібен лише один запис кешу сусіда для шлюзу, щоб перенаправити пакети до будь-якої IP-адреси в маршрутизованому префіксі. Ця властивість має вирішальне значення для масштабованості Інтернету.
Обхід відсутність маршрутизованого префіксу
Іноді клієнти стикаються з Інтернет-провайдером, який надаватиме лише префікс посилання та відсутність маршрутизованого префікса. У такій ситуації замовник може встановити демон, який відповідає на виявлення сусіда для всіх IP-адрес у певному піддіапазоні префікса посилання. Це матиме ефект, подібний до налаштування цього префіксу як маршрутизованого префікса. Але він має кілька недоліків:
/64, але демон, що відповідає на запити на виявлення сусідів, може створити лише "маршрутизований" префікс, який довший, ніж /64.Обробка накладних витрат на маршрутизаторі провайдера може бути суттєвою проблемою. Деякі маршрутизатори були настільки погано при обробці потоку пакетів , які потребують виявлення сусідів , що він перетворився в реальні атаки DoS, а також з допомогою більш довгих посилань префіксів (в /120- 127діапазоні) була використано в якості тимчасового рішення для таких атак DoS.
Навіть якщо маршрутизатор не вразливий для DoS-атаки, пам'ять, необхідна для записів кеша сусідів, коли використовується описаний вище спосіб, набагато дорожче для ISP, ніж IP-адреси для маршрутизованого префікса, тому причин мало щоб провайдер відмовився роздавати маршрутизований префікс.
Особливі випадки навколо посилань "точка-точка"
Посилання "точка-точка" (наприклад, 6-туннельні тунелі та PPP-посилання) для відкриття сусідів не потребують. Існує лише один напрямок для надсилання пакета за таким посиланням, і перед відправленням пакету не потрібно шукати апаратну адресу.
Це означає, що накладні витрати на виявлення сусіда не є проблемою на такому посиланні. Отже, мати один кінець зв'язку "точка-точка" використовувати багато адрес не є проблемою, якщо кінцеві точки мають деяку угоду щодо того, хто використовує адреси. Відсутність виявлення сусіда означає, що також немає виявлення дублікатів адреси, тому обидві кінцеві точки намагатимуться використовувати ту саму адресу, яка не працюватиме, як очікувалося (якщо ви не очікуєте, що вона поводитиметься як адреса anycast).
Є одне застереження, яке слід пам’ятати навколо посилань, що вказують на точки. Кожна кінцева точка передбачає, що всі адреси посилання, яке воно не призначене, присвоєні іншому кінці. Це означає, що невикористані адреси на лінії "точка-точка" схильні викликати цикл маршрутизації. Такого циклу маршрутизації (та кількох інших випадків циклів маршрутизації) можна уникнути, якщо кінцева точка ніколи не надсилає пакет безпосередньо до вузла, від якого він отриманий. Таким чином, пакет, отриманий від зв'язку до точки, не повинен пересилатись назад через ту саму точку до точки зв'язку, доки одна кінцева точка отримає це право, цикл маршрутизації порушується. Як бічний вузол в Ethernet, дійсно потрібно отримати пакет і переслати його назад на ту саму посилання, але це гарна ідея уникати цього, якщо він буде перенаправлений назад на ту саму MAC-адресу, звідки він був отриманий.
Оскільки більшість адрес на посилання "точка-точка" просто переадресують на інший кінець посилання без необхідності виявлення сусідів, це виглядає дуже схоже на маршрутизований префікс. Наприклад, якщо ISP присвоїв 2001: db8: 42 :: / 64 посилання "точка-точка" з кінцевими точками, яким присвоєні адреси 2001: db8: 42 :: 1 та 2001: db8: 42 :: 2, то пакети для більшості адрес у 2001 році: db8: 42 :: / 64 буде передано з ISP клієнту так само, як це було б, якби це був маршрутизований префікс, використовуючи 2001: db8: 42 :: 2 як шлюз.
Це означає, що певний злом можливий. У CPE можна фактично налаштувати 2001: db8: 42 :: / 64 як префікс посилання в локальній мережі. Для того, щоб CPE дізнався, на якому з двох посилань знаходиться певне місце призначення, фактичну конфігурацію пункту "точка-точка" до ISP слід було б змінити на 2001 рік: db8: 42 :: / 126. Це все буде працювати за одним незначним винятком, хости в локальній мережі не можуть спілкуватися з чотирма IP-адресами в 2001 році: db8: 42 :: / 126. Оскільки їм, мабуть, не потрібно було спілкуватися з ними, це не є великою проблемою. Однак використовувати цей хак не рекомендується, належна конфігурація - отримати маршрутизований префікс від провайдера.
Ще один хак для збереження адрес - виділити лише глобальні адреси для маршрутизованого префікса та використовувати RFC 4193 адреси для посилання "точка-точка". Це, однак, дурний хакер, оскільки він все ще вносить деякі недоліки для вирішення неіснуючої проблеми.
Можливо також взагалі не присвоювати жоден префікс пункту посилання. Поки кожна кінцева точка має інший інтерфейс, на якому вона має глобальну адресу, вони можуть використовувати адресу, призначену іншому інтерфейсу, при спілкуванні по лінії "точка-точка". Я не знаю жодних недоліків цього підходу, тому якщо ви виявите, що такий підхід для вказівки на точки спрощує вашу конфігурацію мережі, не соромтеся використовувати її, але не використовуйте її як міру збереження адрес.
Використовуйте регістри для маршрутизованого префікса
Більш детальним прикладом останньої точки можуть бути рекурсори DNS. Оскільки я не бачу, як DNSSEC отримує велику тягу до моменту, коли ми почнемо боротьбу з IPv4, необхідні інші заходи проти отруєння DNS. Докладено зусиль для отримання якомога більшої кількості ентропій у запитах. Ідентифікаційний номер і номер порту можуть містити не більше 32 біт ентропії, ще кілька біт можуть міститися в запиті, якщо верхнє і нижнє регістри змішані з доменним іменем, яке потрібно вирішити. Таким чином, ви рідко зможете отримати більше 48 біт. Присвоєння повного /64рекурсору DNS дозволило б збільшити ентропію на 64 біти за один раз, що більше, ніж усі інші зусилля разом.
/48результатів отримує сусідський пакет запиту для IP-адреси призначення, то це дійсно звучить так, як постачальник налаштував /48як префікс посилання. Налаштування /48префіксу посилання не є рекомендованою конфігурацією, але я чув, що провайдери це роблять. Якби це був маршрутизований префікс, то незалежно від того, на яку IP-адресу всередині /48пакета було націлено, сусідське звернення, яке ви бачили, буде для кожного і того ж IP-адреси. І як тільки ви відповіли на це, ви більше не побачите сусідських клопотань.
Префікс посилання використовується між маршрутизатором і провайдером.
Спрямований префікс використовується у вашій мережі.
Якщо ви отримаєте від провайдера провайдера / 64 маршрутизований префікс, ви просто пропонуєте маршрутизатору рекламувати цей префікс у вашій локальній мережі. Якщо у вас є префікс менший за / 64 (можливо, / 48?), Ви повинні розглянути, як підмережу підфіксувати таким чином, щоб використовувати всі ваші маршрутизатори у вашій організації.
У Wireshark, залежно від того, де ви захоплюєте пакети, ви можете бачити лише використаний маршрутизований префікс (якщо ви захоплюєте в локальній мережі) або обидва використані префікси (якщо ви захоплюєте в WAN).
Щодо протоколу виявлення сусідів, він також залежить від посилання. На зв'язку між ISP і маршрутизатором NDP використовується для виявлення MAC-адреси WAN-інтерфейсу вашого маршрутизатора та MAC-адреси маршрутизатора вгору за поточним маршрутизатором. У вашому інтерфейсі LAN NDP використовується для виявлення MAC-адреси хостів у вашому сегменті локальної мережі.
Сподіваюсь, це допомагає.
If you received a /64 from your ISP, then you would simply have your router advertise that prefix on your LAN, ймовірно, буде менш зрозумілим, якщо ви зробите це явним, що /64має на увазі маршрутизований префікс.
Префікс - це маршрутизований префікс, якщо пакети до цього префікса повинні пройти через маршрутизатор, щоб досягти їх призначення. Префікс - це префікс посилання, якщо він знаходиться на сегменті, до якого приєднаний інтерфейс локальної мережі.
Оскільки пакет рухається по Інтернету, / 64 він орієнтується, щоб він був маршрутизованим префіксом, поки ви не досягнете останнього скаку. Тоді це буде префікс посилання.
Маршрутизовані префікси зазвичай агрегуються. Багато / 64 можуть бути об'єднані в один коротший префікс, щоб зменшити таблиці маршрутизації менше. На межі між Інтернет-провайдерами прийнято застосовувати максимальну довжину префікса / 48.
Якщо префікс - що-небудь від / 0 до / 63, зазвичай можна припустити, що це маршрутизований префікс. Якщо префікс / 64, вам потрібна додаткова інформація, щоб знати, чи це маршрутизований або префікс посилання.