Основной заголовок IPv6
Заголовок IPv6 показан на рис. 5.49. Поле Версия содержит число 6 для IPv6 (и 4 для IPv4). На период перехода с IPv4 на IPv6, который, вероятно, займет около десяти лет, маршрутизаторы по значению этого поля смогут отличать пакеты нового стандарта от старого. Подобная проверка потребует нескольких тактов процессора, что может оказаться нежелательным в некоторых ситуациях, тем более что в заголовке с информацией о канале передачи данных обычно указан протокол для демультиплексирования, так что эту проверку можно пропустить. Например, в Ethernet у поля Тип существует несколько разных значений, определяющих полезные данные IPv4- или IPv6-пакета. Дискуссия между лагерями, руководствующимися принципами «Делай правильно» и «Делай быстро», несомненно, будет долгой и энергичной.
Поле Дифференцированное обслуживание (изначально Класс трафика ) используется для того, чтобы различать пакеты с разными требованиями к доставке в реальном времени. Оно используется для обеспечения качества обслуживания вместе с архитектурой дифференцированного обслуживания (точно так же, как и одноименное поле IPv4). Кроме того, так же как и в IPv4, младшие 2 бита отводятся под явные уведомления о перегрузке.
Поле Метка потока применяется для того, чтобы отправитель и получатель могли сообщить сети об определенных свойствах пакетов и требованиях к их обработке; при этом между ними устанавливается псевдосоединение. Например, поток пакетов между двумя процессами на разных хостах может обладать строгими требованиями к задержкам, что потребует резервирования пропускной способности. Поток устанавливается заранее и получает идентификатор. Когда прибывает пакет с отличным от нуля содержимым поля Метка потока , все маршрутизаторы смотрят в свои таблицы, чтобы определить, какого рода особая обработка ему требуется. Таким образом, новый протокол пытается соединить достоинства подсетей различных типов: гибкость дейтаграмм и гарантии виртуальных каналов.

Рис. 5.49.Фиксированный заголовок IPv6 (обязательные поля)
С целью обеспечения должного качества обслуживания каждый поток описывается адресом источника, адресом назначения и номером потока. Это значит, что для каждой пары IP-адресов можно создать до 2 20активных потоков. Кроме того, два потока с одинаковыми номерами, но различными адресами отправителя или получателя считаются разными потоками и различаются маршрутизаторами по адресам. Ожидается, что номера каналов будут выбираться случайным образом, а не назначаться подряд начиная с 1, что облегчит маршрутизаторам их распознавание.
Поле Длина полезной нагрузки сообщает, сколько байт следует за 40-байтовым заголовком, показанным на рис. 5.49. В заголовке IPv4 аналогичное поле называлось Полная длина и определяло весь размер пакета. В новом протоколе 40 байт заголовка учитываются отдельно. Это значит, что теперь полезная нагрузка может занимать 65 535 байт вместо 65 515.
Поле Следующий заголовок раскрывает секрет возможности использования упрощенного заголовка. Дело в том, что после обычного 40-байтового заголовка могут идти дополнительные (необязательные) расширенные заголовки. Это поле сообщает, какой из шести дополнительных заголовков (на текущий момент) следует за основным. В последнем IP-заголовке поле Следующий заголовок сообщает, какой обрабатывающей программе протокола транспортного уровня (то есть TCP или UDP) передать пакет.
Поле Максимальное число транзитных участков не дает пакетам вечно блуждать по сети. Оно имеет практически то же назначение, что и поле Время жизни в заголовке протокола IPv4. Это поле уменьшается на единицу на каждом транзитном участке. Теоретически, в протоколе IPv4 это поле должно было содержать секунды времени жизни пакета, однако ни один маршрутизатор не использовал его подобным образом, поэтому имя поля было приведено в соответствие со способом его применения.
Следом идут поля Адрес отправителя и Адрес получателя. В исходном предложении Диринга (протоколе SIPP) использовались 8-байтовые адреса, но при рас смотрении проекта было решено, что 8-байтовых адресов хватит лишь на несколько десятилетий, в то время как 16-байтовых адресов должно хватить навечно. Другие возражали, что 16 байт для адресов слишком много, тогда как третьи настаивали на 20-байтных адресах для совместимости с дейтаграммным протоколом OSI. Еще одна фракция ратовала за адреса переменной длины. После продолжительных споров, содержащих непечатную лексику, было решено, что наилучшим компромиссным решением являются 16-байтовые адреса фиксированной длины.
Читать дальше
Конец ознакомительного отрывка
Купить книгу