определенных свойствах пакетов и требованиях к их обработке; при этом между ними устанавливается псевдосоединение. Например, поток пакетов между двумя процессами на разных хостах может иметь строгие требования к задержкам, что потребует резервирования пропускной способности. Поток устанавливается заранее и получает идентификатор. Когда прибывает пакет с ненулевым значением в поле Flow label, все маршрутизаторы проверяют свои таблицы, чтобы определить, какой тип особой обработки ему требуется. Таким образом, новый протокол пытается объединить достоинства подсетей различных типов: гибкость дейтаграмм и гарантии виртуальных каналов.

С целью обеспечения QoS каждому потоку присваивается адрес источника, адрес назначения и номер потока. Это означает, что для каждой пары IP-адресов можно создать до 220 активных потоков. Кроме того, если два потока приходят с разных хостов, но имеют одинаковую метку, маршрутизатор может отличить их по адресам источника и получателя. Предполагается, что метки потоков выбираются случайно, а не назначаются подряд, начиная с единицы, так что подразумевается, что маршрутизаторы будут их хешировать.

Поле Payload length (Длина пользовательских данных) сообщает, сколько байтов следует за 40-байтным заголовком на илл. 5.57. В заголовке IPv4 аналогичное поле называлось Total length и определяло весь размер пакета. В новом протоколе 40 байт заголовка учитываются отдельно. Это значит, что теперь пользовательские данные могут занимать 65 535 байт вместо 65 515.

Поле Next header (Следующий заголовок) раскрывает секрет упрощения заголовка. Дело в том, что можно использовать дополнительные (необязательные) расширенные заголовки. Это поле сообщает, какой из шести таких заголовков (на текущий момент) следует за основным. В последнем IP-заголовке поле Next header информирует, какому обработчику транспортного уровня (то есть TCP или UDP) передать пакет.

Поле Hop limit (Максимальное число транзитных участков) не дает пакетам вечно блуждать по сети. Оно имеет практически то же назначение, что и поле Time to live в заголовке IPv4. Это поле уменьшается на единицу на каждом транзитном участке. Теоретически в IPv4 это поле должно было содержать секунды существования пакета, однако ни один маршрутизатор не использовал его подобным образом, поэтому имя поля было приведено в соответствие со способом его применения.

Следом идут поля Source address и Destination address. В изначальном предложении Диринга (протоколе SIPP) использовались 8-байтные адреса, но при рассмотрении проекта было решено, что они закончатся всего через несколько десятилетий, в то время как 16-байтных адресов хватит навсегда. Другие возражали, что 16 байт — это слишком много, третьи настаивали на 20-байтных адресах для совместимости с дейтаграммным протоколом OSI. Еще одна фракция выступала за адреса переменной длины. После продолжительных споров, содержащих непечатную лексику, было решено, что наилучшим компромиссным решением являются 16-байтные адреса фиксированной длины.

Для написания 16-байтных адресов была выработана новая нотация. Адреса в IPv6 записываются в виде восьми групп по четыре шестнадцатеричные цифры, разделенных двоеточиями, например:

8000:0000:0000:0000:0123:4567:89AB:CDEF

Поскольку многие адреса содержат большое количество нулей, разрешены три метода сокращенной записи. Во-первых, могут быть опущены ведущие нули в каждой группе, например 0123 можно записывать как 123. Во-вторых, одна или несколько групп, полностью состоящих из нулей, могут заменяться парой двоеточий. Таким образом, приведенный выше адрес принимает вид:

8000::123:4567:89AB:CDEF

Наконец, адреса IPv4 могут записываться как пара двоеточий, после которой пишется адрес в старом десятичном формате, например:

::192.31.20.46

Возможно, об этом нет необходимости говорить столь подробно, но количество всех возможных 16-байтных адресов очень велико — 2128, что приблизительно равно 3 × 1038, или 7 × 1023 IP-адресов на каждый квадратный метр земной поверхности. Те, кто изучал химию, могут заметить, что это число больше числа Авогадро31. Хотя в планы разработчиков не входило предоставление IP-адреса каждой молекуле на поверхности земли, они не так далеки от этого.

На практике не все адресное пространство используется эффективно, так же как и комбинации телефонных номеров. Например, номера Манхэттена (код 212) почти полностью заняты, тогда как в штате Вайоминг (код 307) практически не задействованы. В RFC 3194 Дьюранд (Durand) и Уитема (Huitema) приводят свои вычисления. Утверждается, что если ориентироваться на использование телефонных номеров, то даже при самом пессимистическом сценарии все равно получается более 1000 IP-адресов на квадратный метр поверхности планеты (включая сушу и море). При любом вероятном сценарии обеспечиваются триллионы адресов на квадратный метр. Маловероятно, что в обозримом будущем возникнет их нехватка.

Полезно сравнить заголовок IPv4 (см. илл. 5.47) с заголовком IPv6 (илл. 5.57) и посмотреть, что осталось от старого стандарта. Поле IHL исчезло, так как заголовок IPv6 имеет фиксированную длину. Поле Protocol также было убрано, поскольку поле Next header сообщает, что следует за последним IP-заголовком (например, UDP- или TCP-сегмент).

Были удалены все поля, относящиеся к фрагментации, так как в IPv6 используется другой подход к ней. Во-первых, все хосты, поддерживающие IPv6, должны динамически определять нужный размер пакета. Для этого используется метод поиска путевого значения MTU, о котором мы говорили в разделе 5.5.6. Вкратце, когда хост отправляет слишком большой IPv6-пакет вместо того, чтобы его фрагментировать, маршрутизатор, неспособный переслать пакет дальше, возвращает сообщение об ошибке. Получив это сообщение, хост должен прекратить всю передачу этому адресату. Гораздо правильнее научить все хосты отправлять пакеты требуемого размера, нежели учить маршрутизаторы фрагментировать их на лету. Кроме того, минимальный размер пакета был увеличен с 576 до 1280, чтобы можно было передавать 1024 байт данных и множество заголовков.

Наконец, поле Checksum было удалено, так как подсчет контрольной суммы значительно снижает производительность. В настоящее время все шире используются надежные линии связи, а на канальном и транспортном уровнях подсчитываются свои контрольные суммы, так что наличие еще одной проверки не стоит требуемых затрат ресурсов. В результате удаления всех этих функций получился простой, быстрый и в то же время гибкий протокол сетевого уровня с огромным адресным пространством.

Заголовки расширений

Иногда удаленные поля заголовка могут понадобиться, поэтому в протоколе IPv6 была представлена новая концепция необязательного расширения заголовка (extension header). С его помощью можно добавить дополнительную информацию, при этом она эффективно закодирована. На сегодня определены шесть типов таких заголовков (илл. 5.58). Все они необязательны, но если их два и более, то они должны идти сразу за фиксированным заголовком, желательно в указанном порядке.

У одних заголовков формат фиксированный, другие могут содержать разное количество полей переменной длины. Для них каждый пункт кодируется в виде набора взаимосвязанных величин (тип, длина, значение). Поле Type представляет собой однобайтное поле, обозначающее опцию. Первые два бита указывают маршрутизаторам, которые не знают, как ее обрабатывать. Возможны четыре варианта действий: пропустить опцию, игнорировать пакет, игнорировать пакет и отправить обратно ICMP-пакет, а в случае