IP in IP

IP in IP — це протокол IP-тунелювання, який інкапсулює один IP-пакет в інший IP-пакет. Інкапсуляція одного IP пакета в інший IP пакет, це додавання зовнішнього заголовка з SourceIP — точкою входу в тунель, і Destination — точкою виходу з тунелю. При цьому внутрішній пакет не був змінений (крім поля TTL, який зменшився). Поля "Do not Fragment" і "The Type of Service" повинні бути скопійовані в зовнішній пакет. Якщо розмір пакета більше ніж Path MTU, пакет фрагментується в інкапсуляторі, оскільки зовнішній заголовок має бути включеним. Декапсулятор повинен буде зібрати пакет.

IP in IP Інкапсулятор

Інкапсуляція IP in IP

Зовнішній IP заголовок

Внутрішній IP заголовок

Корисна інформація

R: 1 біт
Цей біт зарезервований і повинен бути встановлений в 0.
DF: 1 біт
Це поле вказує чи можна фрагментувати дейтаграму чи ні. Якщо біт встановлено в 1 у внутрішньому заголовку, то в зовнішньому він теж повинен бути встановлений в 1, це говорить про те, що дейтаграму фрагментувати не можна. Якщо біт встановлено в 0 у внутрішньому заголовку, то в зовнішньому він може бути 1/0.
MF: 1 біт
Поле використовується, коли дейтаграма фрагментована, показує, що дейтаграма містить ще фрагменти, це поле не копіюється із внутрішнього заголовка.
Fragment Offset: 13 біт
Це поле використовується, коли збираються фрагменти.
Time To Live (TTL): 8 біт
Це поле використовується, щоб відстежувати час життя датаграми. Внутрішній заголовок TTL зменшується до інкапсуляції і не змінюється в декапсуляторі. Зовнішній заголовок встановлює значення TTL таке, щоб датаграма була доставлена ​​до кінцевої точки тунелю.
Protocol: 8 біт
Це поле указує наступний після цього протокол датаграми. Значення встановлено в 4. У більшості випадків буде протокол IPv4, якщо немає будь-яких додаткових заголовків для інкапсульованого пакета.
Header Checksum: 16 біт

Це поле містить довжину заголовка інкапсульованого IP (включаючи заголовок зовнішнього IP, заголовок внутрішнього IP, корисну інформацію)
Identification: 16 біт
Це поле використовується для ідентифікації фрагментів дейтаграми, необхідне для складання фрагментів інкапсулятора. Для зовнішнього заголовка IP це нове згенероване число.
Flags: 3 біта

R

DF

MF

R: 1 біт
Цей біт зарезервований і повинен бути встановлений в 0.
DF: 1 біт
Це поле вказує чи може фрагментувати дейтаграмму чи ні. Якщо біт встановлено у 1 у внутрішньому заголовку, то в зовнішньому він теж повинен бути встановлений в 1, це говорить про те, що дейтаграмму фрагментувати не можна. Якщо біт встановлено у 0 у внутрішньому заголовку, то в зовнішньому він може бути 1/0.
MF: 1 біт
Поле використовується коли дейтаграма фрагментована, показує, що дейтаграмма містить ще фрагменти, це поле не буде копіюватися із внутрішнього заголовка.
Fragment Offset: 13 біт
Це поле використовується, коли збираються фрагменти.
Time To Live (TTL): 8 біт
Це поле використовується, щоб відстежувати час життя датаграми. Внутрішній заголовок TTL зменшується до інкапсуляції і не змінюється в декапсуляторі. Зовнішній заголовок встановлює значення TTL таке, щоб датаграма була доставлена ​​до кінцевої точки тунелю.
Protocol: 8 біт
Це поле вказує наступний після цього протокол датаграми. Значення встановлено в 4. У більшості випадків буде протокол IPv4, якщо немає будь-яких додаткових заголовків для інкапсульованого пакета.
Header Checksum: 16 біт
Це поле містить контрольну суму IP зовнішнього заголовка.
Source IP Address: 32 біта
Це поле містить IP адресу інкапсулятора
Destination IP Address: 32 біта
Це поле містить IP адресу декапсулятора
Options: Мінлива довжина
Це поле не копіюється із заголовка внутрішнього IP. Нові опції можуть бути додані.
Padding: Мінлива довжина
Це поле використовується для заповнення дейтаграми, так щоб корисне навантаження починалася з кордону в 32 біта.

Обробка ICMP повідомлень

Після отримання дейтаграми, є ймовірність що інкапсулятор отримає ICMP повідомлення від проміжних вузлів. Інкапсулятор вживає заходів для ICMP повідомлення в залежності від Типу і Коду ICMP повідомлення. Наступні ICMP повідомлення з Типом і Кодом, а також заходи прийняті інкапсулятором.

• Destination Unreacheable (Тип 3)
  • Network Unreachable (Code 0) — ICMP повідомлення про помилку з Типом 3 і Кодом 0 має бути відправлено оригінальному відправнику.
  • Host Unreachable (Code 1) — ICMP повідомлення про помилку з Типом 3 і Кодом 1 повинно бути відправлено оригінальному відправнику.
  • Protocol Unreachable (Code 2) — ICMP повідомлення про помилку з Типом 3 і Кодом 0 або 1 повинно бути відправлено оригінальному відправнику.
  • Port Unreachable (Code 3) — ICMP повідомлення про помилку не слід направити відправнику
  • Datagram too big (Code 4) — ICMP повідомлення про помилку з Типом 3 і Кодом 4 або 1 повинно бути відправлено оригінальному відправнику.
  • Source Route Failed (Code 5) ICMP повідомлення про помилку не слід направити оригінальному відправнику.
• Sourse Quence (Type 4) — не ICMP повідомлення про помилку слід відправити оригінальному відправнику
• Redirect (Type 5) — ICMP повідомлення про помилку не слід направляти оригінальному відправнику
• Time Exceeded (Type 6) ICMP повідомлення про помилку з типом 3 і кодом 1 слід направляти оригінальному відправнику (випадок петель в маршрутах в тунелі)
• Parameter Problem (Type 12)
  • Якщо повідомлення про помилку в точці копірованного поля з неінкапсульованими дейтаграми, тоді ICMP повідомлення про помилку слід відправити оригінальному відправнику
  • Якщо повідомлення про помилку в полі доданому інкапсулятором, значить ICMP повідомлення про помилку не слід відправляти оригінальному відправнику.

Обробка петель в тунелях

Петлі в тунелях можуть виникати з таких причин:

1. Коли IP адреса джерела дейтаграми така ж, як і IP адреса маршрутизатора в будь-якому інтерфейсі
2. Коли джерело IP дейтаграми таке ж, як кінцева точка тунелю.

В обох випадках маршрутизатор повинен не відправляти дейтаграму. Замість цього дейтаграма повинна бути відкинута.

Управління тунелями

Для ICMP повідомлень проміжні маршрутизатори повертають 64 бітну дейтаграму поверх заголовка IP, для якого мало скопіювати внутрішній заголовок. Так інкапсулятор не зможе ретранслювати відповідне повідомлення оригінальному відправнику. Але воно може бути оброблено ПЗ туннеля. Повідомлення має підтримувати наступне:

• MTU тунелю
• TTL тунелю
• Досяжність декапсулятора.

Посилання

• RFC2003 [Архівовано 19 вересня 2017 у Wayback Machine.]