Компьютерные сети. 6-е изд. - Эндрю Таненбаум

class="p">Аргумент против контрольных сумм состоял в следующем. Каждое приложение, которое действительно заботится о целостности своих данных, считает контрольную сумму на транспортном уровне, поэтому еще одна на сетевом является излишней (кроме того, она подсчитывается еще и на уровне передачи данных). К тому же эксперименты показали, что вычисление контрольной суммы составляло основные затраты IPv4. Это сражение было выиграно лагерем противников контрольной суммы, поэтому в IPv6 ее нет.

Вокруг мобильных хостов также разгорелся спор. Если портативный компьютер окажется на другом конце земли, сможет ли он работать с прежним IPv6-адресом или будет вынужден использовать схему с внутренним и внешним агентами? Появилось много желающих создать в протоколе IPv6 явную поддержку мобильных хостов. Эти попытки потерпели поражение, поскольку ни по одному конкретному предложению не удалось достичь консенсуса.

Вероятно, самые жаркие баталии разгорелись вокруг проблемы безопасности. Все были согласны, что это самый главный вопрос. Спорным было то, где и как следует реализовывать безопасность. Аргументом за размещение системы безо­пасности на сетевом уровне было то, что при этом она становится стандартной службой, которой могут пользоваться все приложения безо всякого предварительного планирования. Контраргумент заключался в том, что по-настоящему защищенным приложениям подходит лишь сквозное шифрование: оно осуществляется самим источником, а дешифровка — непосредственным получателем. Во всех остальных случаях пользователь зависит от реализации сетевого уровня, которую он не контролирует (а в ней могут содержаться ошибки). Однако приложение может просто отказаться от использования встроенных в IP функций защиты и выполнять всю эту работу самостоятельно. Возражение на этот довод состоит в том, что пользователи, не доверяющие сетям, не хотят платить за неиспользуемую функцию, реализация которой утяжеляет и замедляет работу протокола, даже если сама функция отключена.

Другая сторона вопроса расположения системы безопасности заключается в том, что во многих (хотя, конечно, далеко не во всех) странах приняты строгие экспортные законы, касающиеся шифрования и зашифрованных данных, особенно личной информации. В некоторых странах, в частности во Франции32 и Ираке, строго запрещено использование шифрования даже внутри страны, чтобы у населения не могло быть секретов от органов власти. В результате любая реализация IP с достаточно мощной криптографической системой не может быть экспортирована за пределы США (и многих других стран). Таким образом, приходится поддерживать два набора программного обеспечения — один для внутреннего использования и другой для экспорта, против чего решительно выступает большинство производителей компьютеров.

Единственный вопрос, по которому не было споров, — никто не рассчитывал, что IPv4-интернет будет отключен в воскресенье, а в понедельник утром ему на смену придет IPv6-интернет. Вместо этого вначале появятся «островки» IPv6, которые будут общаться по туннелям (см. раздел 5.5.4). По мере роста эти островки будут соединяться в более крупные острова. Наконец, все они объединятся, и интернет будет полностью трансформирован.

Так, по крайней мере, выглядел план. Внедрение протокола 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 используется редко, так как при возникновении перегрузки эти пакеты только подливают масла в огонь, еще больше загружая сеть.