Заголовок Routing (Маршрутизация) содержит информацию об одном или нескольких маршрутизаторах, которые следует посетить на пути к получателю. Это весьма напоминает свободную маршрутизацию IPv4, так как перечисленные маршрутизаторы должны быть пройдены строго по порядку, а остальные посещаются попутно. Формат заголовка Routing показан на илл. 5.60.
Илл. 5.60. Заголовок расширения Routing
Первые четыре байта заголовка Routing содержат четыре однобайтных целых числа. Поля Next header и Header extension length (Длина расширения заголовка) были описаны ранее. В поле Routing type (Тип маршрутизации) описывается формат оставшейся части заголовка. Если он равен 0, это означает, что далее следует зарезервированное 32-разрядное слово, а за ним — некоторое число адресов IPv6. Возможно в будущем по мере необходимости станут разрабатываться новые поля. Наконец, в поле Segments left (Число оставшихся сегментов) указывается, сколько адресов из списка еще нужно посетить. Его значение уменьшается при прохождении каждого адреса. Когда оно достигает нуля, пакет оставляется на произвол судьбы — без дальнейших указаний относительно его пути. Обычно к этому моменту он уже находится близко к получателю, и оптимальный маршрут очевиден.
Заголовок Fragment (Фрагмент) решает проблему фрагментации способом, схожим с протоколом IPv4. Он содержит идентификатор дейтаграммы, номер фрагмента и бит, информирующий о том, является ли этот фрагмент последним. В отличие от IPv4, в протоколе IPv6 фрагментировать пакет может только хост-источник. Маршрутизаторы фрагментировать пересылаемые пакеты не могут. Хотя это изменение можно считать отказом от оригинальной философии IP, оно вполне в духе современного применения IPv4. Вдобавок оно упрощает и ускоряет работу маршрутизаторов. Как уже было сказано, маршрутизатор отвергает слишком большие пакеты, отправляя в ответ ICMP-пакет, указывающий хосту-источнику на необходимость заново передать пакет, разделив его на меньшие фрагменты.
Заголовок Authentication (Аутентификация) предоставляет механизм подтверждения подлинности отправителя пакета. Заголовок Encrypted security payload (Шифрование пользовательских данных) обеспечивает конфиденциальность: прочесть содержимое пакета сможет только тот, для кого он предназначен. Для выполнения этих задач в заголовках используются криптографические методы, которые будут рассмотрены в главе 8.
Полемика
С учетом открытости, с которой разрабатывался протокол IPv6, а также убежденности большого количества разработчиков в собственной правоте неудивительно, что многие решения принимались в условиях весьма жарких дискуссий. О некоторых из них будет рассказано ниже. Все жуткие подробности вы найдете в соответствующих RFC.
О спорах по поводу длины поля адреса уже упоминалось. В результате было принято компромиссное решение: 16-байтные адреса фиксированной длины.
Другое сражение разгорелось из-за размера поля Hop limit. Некоторые участники дискуссии считали, что ограничение количества транзитных участков числом 255 (которое явно следует из использования 8-битного поля) — большая ошибка. В самом деле, маршруты из 32 транзитных участков уже стали обычным явлением, а через 10 лет в обиход могут войти более длинные пути. Сторонники этого лагеря заявляли, что использование длинных полей адресов было дальновидным решением, в отличие от внедрения крохотных счетчиков транзитных участков. Самый страшный грех, который, по их мнению, могут совершить специалисты по вычислительной технике, — выделить для чего-нибудь недостаточное количество разрядов.
В ответ им было заявлено, что подобные аргументы можно привести для увеличения любого поля, что приведет к раздутому заголовку. Кроме того, назначение поля Hop limit состоит в том, чтобы не допустить слишком долгого странствования пакетов, и 65 535 транзитных участков — это очень много. К тому же по мере роста интернета будет создаваться все большее количество междугородних линий, что позволит передавать пакеты между любыми странами максимум за шесть транзитных пересылок. Если от получателя или отправителя до соответствующего международного шлюза окажется более 125 транзитных участков, то, видимо, что-то не в порядке с магистралями этого государства. В итоге эту битву выиграли сторонники 8-битного счетчика.
Еще одним предметом спора оказался максимальный размер пакета. Обладатели суперкомпьютеров настаивали на размере пакетов, превышающем 64 Кбайт. Когда суперкомпьютер начинает передачу, он занимается серьезным делом и не хочет, чтобы его прерывали через каждые 64 Кбайт. Аргумент против больших пакетов заключается в том, что если пакет размером в 1 Мбайт будет передаваться по линии Т1 со скоростью 1,5 Мбит/с, то он займет линию на целых 5 с, что вызовет слишком большую задержку, заметную для интерактивных пользователей. В итоге удалось достичь компромисса: обычные пакеты ограничены размером 64 Кбайт, но с помощью заголовка расширения можно передавать огромные дейтаграммы.
Еще одним спорным вопросом оказалось удаление контрольной суммы IPv4. Кое-кто сравнивал этот ход с удалением тормозов из автомобиля. При этом автомобиль становится легче и может двигаться быстрее, но если на пути что-то встретится, возникнет проблема.
Аргумент против контрольных сумм состоял в следующем. Каждое приложение, которое действительно заботится о целостности своих данных, считает контрольную сумму на транспортном уровне, поэтому еще одна на сетевом является излишней (кроме того, она подсчитывается еще и на уровне передачи данных). К тому же эксперименты показали, что вычисление контрольной суммы составляло основные затраты 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 — протокол управляющих сообщений интернета