Так, по крайней мере, выглядел план. Внедрение протокола IPv6 оказалось его ахиллесовой пятой. Он по-прежнему не слишком распространен, хотя уже более 10 лет его полностью поддерживают все основные операционные системы. Обычно операторы сети вводят IPv6, только когда нуждаются в дополнительных IP-адресах. Но надо заметить, что этот протокол постепенно одерживает верх. На него уже приходится большая часть трафика Comcast и примерно четверть трафика Google, так что прогресс налицо.
Чтобы упростить переход к IPv6, разработано множество стратегий. Среди них методы автоматической настройки туннелей, обеспечивающих передачу IPv6-пакетов через сеть IPv4, и технологии, позволяющие хостам автоматически находить конечную точку туннеля. Двухстековые хосты поддерживают как IPv4, так и IPv6 и могут выбирать протокол в зависимости от адреса получателя. Эти стратегии помогут ускорить процесс перехода к IPv6, когда он будет неизбежным. Подробнее об этом — в книге Дэвиса (Davies, 2008).
5.7.4. Управляющие протоколы интернета
Помимо IP, используемого для передачи данных, в интернете есть несколько дополнительных управляющих протоколов сетевого уровня, к которым относятся ICMP, ARP и DHCP. В данном разделе мы рассмотрим их по очереди, описывая те версии, которые соответствуют IPv4 (так как именно они распространены сегодня). У ICMP и DHCP существуют аналогичные версии для IPv6; эквивалентом APR является протокол обнаружения соседей (Neighbor Discovery Protocol, NDP).
ICMP — протокол управляющих сообщений интернета
За работой интернета следят маршрутизаторы. Если во время обработки пакета происходит что-то непредвиденное, маршрутизатор сообщает об этом отправителю с помощью протокола управляющих сообщений интернета (Internet Control Message Protocol, ICMP). Он также используется для тестирования интернета. Существует около десятка типов сообщений ICMP. Каждое ICMP-сообщение вкладывается в IP-пакет. Наиболее важные из них перечислены на илл. 5.61.
Тип сообщения
Описание
Destination unreachable
Пакет не может быть доставлен
Time exceeded
Время жизни пакета уменьшилось до нуля
Parameter problem
Неверное поле заголовка
Source quench
Сдерживающий пакет
Redirect
Научить маршрутизатор географии
Echo and echo reply
Проверить, работает ли машина
Timestamp request/reply
То же, что и запрос отклика, но с временной меткой
Router advertisement/solicitation
Найти ближайший маршрутизатор
Илл. 5.61. Основные типы ICMP-сообщений
Сообщение DESTINATION UNREACHABLE (адресат недоступен) используется, когда маршрутизатор не может обнаружить пункт назначения или когда пакет с битом DF (не фрагментировать) не может быть доставлен, так как путь ему преграждает сеть с ограничением на размер пакетов.
Сообщение TIME EXCEEDED (время истекло) отправляется, когда пакет игнорируется, так как его счетчик TtL (Time to live) уменьшился до нуля. Это событие — признак того, что пакеты двигаются по зацикленному пути или что установлено слишком низкое значение таймера.
В 1987 году Ван Джейкобсон (Van Jacobson) предложил хитрый способ использования этого сообщения об ошибке — утилиту traceroute. Она находит маршрутизаторы, расположенные в узлах пути от хоста к получателю. При этом ей не требуется особый уровень поддержки. Метод состоит в отправке на адрес назначения последовательности пакетов с TtL 1, 2, 3 и т.д. Счетчики в пакетах достигают нуля по мере прохождения через маршрутизаторы на пути. Каждый маршрутизатор послушно отправляет обратно на хост сообщение TIME EXCEEDED. Так хост определяет их IP-адреса и получает информацию о маршруте. Конечно, TIME EXCEEDED предназначалось не для этого. Но вполне возможно, что это самый полезный инструмент отладки сети за всю историю.
Сообщение PARAMETER PROBLEM (проблема параметра) указывает на то, что обнаружено ошибочное значение в поле заголовка. Это признак наличия ошибки в программном обеспечении хоста, отправившего этот пакет, или промежуточного маршрутизатора.
Сообщение SOURCE QUENCH (подавление источника) ранее использовалось для «усмирения» хостов, которые отправляли слишком много пакетов. Хост, получивший такое сообщение, должен был снизить свою активность. В настоящее время SOURCE QUENCH используется редко, так как при возникновении перегрузки эти пакеты только подливают масла в огонь, еще больше загружая сеть. К тому же неясно, как на них отвечать. Теперь борьба с перегрузкой в интернете осуществляется в основном на транспортном уровне; а сигналом перегрузки является утеря пакетов. В главе 6 мы подробно обсудим, как это происходит.
Сообщение REDIRECT (переадресовать) отсылается хосту-источнику, когда маршрутизатор замечает, что у пакета ошибка в адресе назначения. Таким способом маршрутизатор предлагает хосту обновить путь.
Сообщения ECHO (запрос отклика) и ECHO REPLY (отклик) отправляются, чтобы определить, достижим ли в данный момент конкретный адресат и функционирует ли он. Получив ECHO, хост должен ответить сообщением ECHO REPLY. Эти сообщения используются утилитой ping, которая проверяет, работает ли хост и подключен ли он к интернету.
Сообщения TIMESTAMP REQUEST (запрос временной метки) и TIMESTAMP REPLY (отклик с временной меткой) имеют то же назначение, но при этом в ответе проставляется время получения сообщения и время отправления ответа. Этот механизм применяется для измерения производительности сети.
Сообщения ROUTER ADVERTISEMENT (обнаружение маршрутизатора) и ROUTER SOLICITATION (запрос к маршрутизатору) позволяют хостам находить ближайшие маршрутизаторы. Хосту необходимо знать IP-адрес хотя бы одного из них, чтобы он мог передавать пакеты за пределы LAN.
Кроме перечисленных сообщений определены и другие. Их полный список хранится в интернете по адресу www.iana.org/assignments/icmp-parameters.
ARP — протокол разрешения адресов
Хотя у каждого устройства в интернете есть один или несколько IP-адресов, их недостаточно для отправки пакетов. Сетевые карты канального уровня, например Ethernet-карты, не понимают интернет-адресов. Каждая когда-либо выпущенная сетевая карта Ethernet имеет 48-разрядный Ethernet-адрес. Производители карт запрашивают у IEEE блок Ethernet-адресов, что гарантирует их уникальность (это позволяет избежать конфликтов при наличии одинаковых сетевых карт в одной LAN). Сетевые карты отправляют и принимают фреймы, основываясь на 48-разрядных Ethernet-адресах. О 32-разрядных IP-адресах им ничего не известно.
Таким образом, возникает вопрос: как устанавливается соответствие IP-адресов и адресов уровня передачи данных (например, Ethernet-адресов)? Чтобы понять, как это работает, рассмотрим пример на илл. 5.62. Здесь изображен небольшой университет с двумя сетями /24. На рисунке мы видим две коммутируемые сети Ethernet: одна сеть (CS) на факультете кибернетики, с префиксом 192.31.65.0/24, а другая (EE) — на электротехническом факультете, с префиксом 192.31.63.0/24. Они соединены IP-маршрутизатором. У каждого компьютера сети и у каждого интерфейса на маршрутизаторе есть уникальный Ethernet-адрес (на рисунке — от E1 до E6) и уникальный IP-адрес в сети CS или EE.
Рассмотрим, как пользователь хоста 1 передает пакет пользователю хоста 2 в сети CS. Допустим, отправителю известно имя получателя, eagle.cs.uni.edu. Сначала надо найти IP-адрес для хоста 2. Этот поиск осуществляется службой системы имен доменов DNS (Domain Name System), которую мы рассмотрим в главе 7. На данный момент мы просто предположим, что служба DNS возвращает IP-адрес для хоста 2 (192.32.65.5).
Илл. 5.62. Две коммутируемые LAN Ethernet, соединенные маршрутизатором
Теперь программное обеспечение верхнего уровня хоста 1 создает пакет со значением 192.31.65.5 в поле Destination address и передает его IP-программе для пересылки. Программное обеспечение IP может посмотреть на адрес и увидеть, что адресат находится в сети CS (то есть в его собственной сети), но ему нужно как-то определить Ethernet-адрес получателя. Одно из решений состоит в том, чтобы хранить в системе конфигурационный файл, в котором были бы перечислены соответствия всех локальных IP-адресов Ethernet-адресам. Такое решение, конечно, возможно, но в организациях с тысячами компьютеров обновление этих файлов потребует много времени и подвержено ошибкам.