Таблица А.6. Сообщения ICMPv6
| Тип | Код | Описание | Обработчик или errno |
| 1 | Administratively prohibited, firewall filter (Запрещено администратором, фильтр брандмауэра) | EHOSTUNREACH |
| 2 | Not a neighbor, incorrect strict source route (He сосед, некорректный маршрут отправителя) | EHOSTUNREACH |
| 3 | Address unreachable (Адрес недоступен) | EHOSTDOWN |
| 4 | Port unreachable (Порт недоступен) | ECONNREFUSED |
| 2 | 0 | Packet too big (Слишком большой пакет) | Ядро выполняет обнаружение транспортной MTU |
| 3 | Time exceeded (Превышено время передачи) |
| 0 | Hop limit exceeded in transit (При передаче превышено значение предельного количества транзитных узлов) | Пользовательский процесс |
| 1 | Fragment reassembly time exceeded (Истекло время сборки из фрагментов) | Пользовательский процесс |
| 4 | Parameter problem (Проблема с параметром) |
| 0 | Erroneous header filed (Ошибочное поле заголовка) | ENOPROTOOPT |
| 1 | Unrecognized next header (Следующий заголовок нераспознаваем) | ENOPROTOOPT |
| 2 | Unrecognized option (Неизвестный параметр) | ENOPROTOOPT |
| 128 | 0 | Echo request (Эхо-запрос (Ping)) | Ядро генерирует ответ |
| 129 | 0 | Echo reply (Эхо-ответ (Ping)) | Пользовательский процесс (Ping) |
| 130 | 0 | Group membership query (Запрос о членстве в группе) | Пользовательский процесс |
| 131 | 0 | Group membership report (Отчет о членстве в группе) | Пользовательский процесс |
| 132 | 0 | Group membership reduction (Сокращение членства в группе) | Пользовательский процесс |
| 133 | 0 | Router solicitation (Запрос маршрутизатору) | Пользовательский процесс |
| 134 | 0 | Router advertisement (Извещение маршрутизатора) | Пользовательский процесс |
| 135 | 0 | Neighbor solicitation (Запрос соседу) | Пользовательский процесс |
| 136 | 0 | Neighbor advertisement (Извещение соседа) | Пользовательский процесс |
| 137 | 0 | Redirect (Перенаправление) | Ядро обновляет таблицу маршрутизации |
Запись «пользовательский процесс» в этой таблице означает, что ядро не обрабатывает сообщение и ждет обработки данного сообщения от пользовательского процесса с символьным сокетом. Также следует отметить, что различные реализации могут обрабатывать одни и те же сообщения по-разному. Например, в Unix сообщения типа
Router solicitation
(Запрос маршрутизатору) и
Router advertisement
(Извещение маршрутизатора) обычно обрабатываются как пользовательские процессы, но некоторые реализации могут обрабатывать эти сообщения в ядре.
Версия ICMPv6 сбрасывает старший бит поля тип для сообщения об ошибке (типы 1-4) и устанавливает этот бит для информационного сообщения (типы 128–137).
Приложение Б
Виртуальные сети
Б.1. Введение
Поддержка новых возможностей протокола TCP, например каналов с повышенной пропускной способностью (RFC 1323), требуется только на узле, использующем TCP, тогда как маршрутизаторы в модернизации не нуждаются. Эти изменения, описанные в RFC 1323, постепенно проявляются в реализациях TCP на узлах. Когда устанавливается новое TCP-соединение, каждая сторона может определить, поддерживает ли другая сторона новую возможность, и если для обоих узлов это так, ею можно воспользоваться.
Иная ситуация с изменениями IP-уровня, такими как многоадресная передача, появившаяся в конце 80-х, или новая версия протокола IPv6, возникшая в середине 90-х, поскольку они требуют изменений на всех узлах и на всех маршрутизаторах. Но люди хотят начать использовать новые возможности, не дожидаясь, когда все системы будут модернизированы. Для этого существующий протокол IPv4 был дополнен так называемыми виртуальными сетями (virtual network), использующими туннели (tunnels).
Б.2. MBone
Наш первый пример виртуальной сети, построенной с использованием туннелей, — это сеть MBone, которая начала использоваться примерно с 1992 года [29]. Если два или более узла в локальной сети поддерживают многоадресную передачу, то на всех этих узлах могут быть запущены приложения многоадресной передачи, которые могут общаться друг с другом. Для соединения одной локальной сети с другой локальной сетью, также содержащей узлы с возможностью многоадресной передачи, между двумя узлами из этих сетей конфигурируется туннель, как показано на рис. Б.1. На этом рисунке отмечены следующие шаги:
Рис. Б.1. Упаковка IPv4 в IPv4, применяемая в MBone
1. Приложение на узле отправителя MH1 посылает групповую дейтаграмму адресам класса D.
2. На рисунке эта дейтаграмма показана как UDP-дейтаграмма, поскольку большинство приложений многоадресной передачи используют протокол UDP. Более подробно о многоадресной передаче и о том, как посылать и получать многоадресные дейтаграммы, рассказано в главе 21.
