Основной заголовок iPv6

Заголовок IPv6 показан на рис. 5.58. Поле Версия содержит число 6 для IPv6 (и 4 для IPv4). На период перехода с IPv4 на IPv6, который, вероятно, займет около десяти лет, маршрутизаторы по значению этого поля смогут различать пакеты нового и старого стандарта. Подобная проверка потребует нескольких тактов процессора, что может оказаться нежелательным в некоторых ситуациях, поэто­му многие реализации, вероятно, попытаются избежать этих накладных расходов и будут отличать пакеты IPv4 от пакетов IPv6 с помощью некоторого поля в заго­ловке уровня передачи данных. При этом пакеты будут передаваться напрямую нужному сетевому уровню. Однако знакомство уровня передачи данных с типа­ми пакетов сетевого уровня полностью нарушает принцип разделения протоко­лов на уровни, при котором каждый уровень не должен знать назначения битов из пакетов более высокого уровня.

Поле Класс трафика используется для того, чтобы различать пакеты с разными требованиями к доставке в реальном времени. Такое поле присутствовало в стан­дарте IP с самого начала, однако оно реально обрабатывалось маршрутизаторами лишь в единичных случаях. Сейчас проводятся эксперименты, направленные на то, чтобы определить, как лучше всего использовать это поле для передачи дан­ных в реальном времени.

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

Каждый поток описывается адресом источника, адресом назначения и номе­ром потока, так что для каждой пары IP-адресов можно создать много активных потоков. Два потока с одинаковыми номерами, но различными адресами отправи­теля или получателя считаются разными потоками и различаются маршрутизато­рами по адресам. Ожидается, что номера каналов будут выбираться случайным образом, а не назначаться подряд начиная с 1, что облегчит маршрутизаторам их распознавание.

Поле Длина полезной нагрузки сообщает, сколько байт следует за 40-байтовым заголовком, показанным на рис. 5.58. В заголовке IPv4 аналогичное поле называ­лось Полная длина и определяло весь размер пакета. В новом протоколе 40 байт заголовка учитываются отдельно.

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

Поле Максимальное число транзитных участков не дает пакетам вечно блуж­дать по сети. Оно имеет практически то же назначение, что и поле Время жизни в заголовке протокола IPv4. Это поле уменьшается на единицу на каждом тран­зитном участке. Теоретически, в протоколе IPv4 это поле должно было содер­жать секунды времени жизни пакета, однако ни один маршрутизатор не исполь­зовал его подобным образом, поэтому имя поля было приведено в соответствие способу его применения.

Следом идут поля Адрес отправителя и Адрес получателя. В исходном пред­ложении Диринга (протоколе SIPP) использовались 8-байтовые адреса, но при рассмотрении проекта было решено, что 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

Полезно сравнить заголовок IPv4 с заголовком IPv6, чтобы увидеть, что осталось от старого стандарта. Поле IHL исчезло, так как за­головок IPv6 имеет фиксированную длину. Поле Протокол также было убрано, поскольку поле Следующий заголовок сообщает, что следует за последним IP-за­головком (то есть UDP- или ТСР-сегмент).

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

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