IP in IP

Материал из Википедии — свободной энциклопедии
Данная страница не проверялась участниками с соответствующими правами.
Перейти к навигации Перейти к поиску

IP in IP — это протокол IP-туннелирования, который инкапсулирует один IP-пакет в другой IP-пакет. Инкапсуляция одного IP пакета в другой IP пакет, это добавление внешнего заголовка с SourceIP — точкой входа в туннель, и Destination — точкой выхода из туннеля. При этом внутренний пакет не был изменен (кроме поля TTL, которое уменьшилось). Поля Don’t Fragment и The Type of Service должны быть скопированы в внешний пакет. Если размер пакета больше чем Path MTU, пакет фрагментируется в инкапсуляторе, это должно быть во внешнем заголовке. Декапсулятор должен будет собрать пакет.

Инкапсуляция IP in IP

[править | править код]
Внешний IP заголовок Внутренний IP заголовок Полезная информация


Внешний IP заголовок имеет следующие поля
Version: 4 бита
Это поле содержит номер версии протокола. Всегда 4 так как IP в IP поддерживается только для IPv4.
Header Length: 4 бита
Это поле содержит длину заголовка внешнего IP.
Type of Service (TOS): 8 бит
Это поле копируется из заголовка внутреннего IP.
Total Length: 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 Unreachabe (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 туннеля
  • Достижимость декапсулятора

Ссылки

[править | править код]
Источник — https://ru.wikipedia.org/wiki/IP_in_IP