Чи повинен маршрутизатор використовувати SLAAC для призначення IPv6 адреси?

Мене трохи бентежить наступні 2 RFC, що стосуються IPv6:

• RFC 4862 (Автоконфігурація адреси без стану IPv6)
• RFC 7084 (вимоги до маршрутизатора IPv6 CE)

RFC 4862 заявляє:

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

RFC 7084 перераховує одну з вимог конфігурації на стороні WAN для призначення адреси як:

WAA-1: Маршрутизатор IPv6 CE ОБОВ'ЯЗКОВО підтримує автоконфігурацію адреси без стану (SLAAC) [RFC4862].

Чи є тут суперечність?

Чи повинен маршрутизатор мати можливість налаштувати IPv6-адресу для свого інтерфейсу WAN?

Чому пише RFC 4862

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

Якщо я використовую маршрутизатор, наприклад, для підключення своєї локальної мережі до Інтернет-провайдера, чи немає в мережі провайдера маршрутизатор, який розмовляє з моїм маршрутизатором?

Я б подумав, що цілком розумно мати 2 (або більше) маршрутизаторів, прикованих разом. У цьому випадку чому б не використовувати SLAAC на інтерфейсі WAN другого маршрутизатора?

Можливо, питання зводиться до штучного розрізнення хостів і маршрутизаторів? Від RFC 4862:

вузол - пристрій, що реалізує IP.

маршрутизатор - вузол, який пересилає IP-пакети, явно не адресовані собі.

хост - будь-який вузол, який не є маршрутизатором.

Але чи не може хост (тобто машина, на якій розміщені сервери чи програми) також не має таблиці маршрутизації та функціонувати як маршрутизатор? І ми знову знову з’єднуємо 2 маршрутизатора разом.

Редагувати : додаткову інформацію, яку я пізніше виявив ...

Ядро Linux обробляє SLAAC, і воно чітко слідує за RFC 4862. Відразу до розрізнення хостів і маршрутизаторів. Дивіться документацію на ядро ​​на ip-sysctl :

• Поведінка HOST передбачається. Це означає, що маршрутизатори будуть відправлені, а рекламні маршрутизатори будуть використані для автоматичної конфігурації адреси.
• Тільки якщо ввімкнено переадресацію ( /proc/sys/net/ipv6/conf/all/forwarding), пристрій вважається маршрутом . Що означає, що жодні розсилки маршрутизаторів не надсилатимуться, а реклами маршрутизаторів будуть ігноровані.

Виявляється, це відмінність відходить назад, до IPv6. Дивіться параметр /proc/sys/net/ipv4/ip_forward:

Ця змінна особлива, її зміна скидає всі параметри конфігурації до їх стандартного стану ( RFC1122 для хостів, RFC1812 для маршрутизаторів)

У RFC 7084 він також зазначає:

W-1: Коли маршрутизатор приєднаний до посилання на інтерфейс WAN, він ОБОВ'ЯЗКОВО виконувати функцію хоста IPv6 для цілей без РФ [RFC4862] або присвоєння стану [RFC3315] інтерфейсу.

Отже, коротше, так - маршрутизатор повинен мати можливість налаштувати IPv6-адресу для свого інтерфейсу WAN.

Насправді ж більшість провайдерів реалізують DHCPv6 та DHCPv6-PD ( RFC3633 ) для розподілу адрес за низхідним потоком, а також делегування префіксів.

Це гарантує, що ваш маршрутизатор не тільки отримує адресу в його WAN-інтерфейсі, але і отримує префікс, який він може використовувати і у своєму внутрішньому інтерфейсі LAN.

RFC 4862 дійсно описує маршрутизатори в рамках одного адміністративного управління. RFC 7084 пояснює, як повинні вести себе маршрутизатори клієнтів. Це дає провайдеру деяку свободу в тому, як він підтримує IPv6 своїм клієнтам.

Для маршрутизатора PE, маршрутизатор CE є вузлом. З точки зору локальної мережі (домен рівня 2, включаючи посилання від PE до CE), маршрутизатор дійсно є лише ще одним хостом у мережі. У більшості випадків адреси посилань WAN визначатимуться статично, через DHCP або через PPP, фактично не використовуючи SLAAC.

Я думаю, ви пропустили ту частину в RFC 7084, яка передує тому, що ви цитували:

Вимоги на стороні WAN:

W-1: Коли маршрутизатор приєднаний до посилання на інтерфейс WAN, він ОБОВ'ЯЗКОВО виконувати функцію хоста IPv6 для цілей без РФ [ RFC4862 ] або присвоєння стану [ RFC3315 ] інтерфейсу.

Чому RFC 4862 говорить: "Оскільки в автоконфігурації хоста використовується інформація, що рекламується маршрутизаторами, маршрутизатори повинні бути налаштовані якимись іншими способами".

Люди, які написали цей документ (а це його попередник RFC 2462), майже напевно мали світогляд, що існують два типи пристроїв. "хостів", які були численними та тягарями для управління, і "маршрутизаторів", якими керували компетентні адміністратори мережі.

На початку 2000-х у нас було зростання постійних DSL / кабельних з'єднань, а також збільшення кількості людей, які мали вдома більше, ніж один комп’ютер, який міг використовувати інтернет. Оскільки багато провайдерів дають клієнтові лише одну IP-адресу (принаймні, не стягуючи додаткових витрат), ми побачили масове зростання використання «домашніх маршрутизаторів» з NAT для приховування декількох комп'ютерів за таким з'єднанням. NAT дозволив "домашньому маршрутизатору" приховати справжню природу від провайдера, що стосується провайдера, то "домашній маршрутизатор" був як хост.

Таке використання спочатку лише «терпилось» з боку Інтернет-провайдерів, але врешті вони вирішили, що все-таки це не так вже й погано, і почали фактично надавати / продавати «домашні маршрутизатори» своїм клієнтам. Як результат, ми закінчилися величезною кількістю цих пристроїв, які сиділи в будинках та невеликих будинках.

Лише порівняно недавно IETF почав належним чином досліджувати, як «домашні маршрутизатори» та провайдери послуг, які їх обслуговують, повинні вести себе в контексті IPv6. Відповідь полягає в тому, що інтерфейс "сторона WAN" повинен виглядати як хост, тоді як інтерфейси "сторони локальної мережі" повинні вести себе як звичайний маршрутизатор. Оскільки NAT не існує, необхідні деякі додаткові деталі для обробки введення адрес для локальної мережі.

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