
- •1. Терминология
- •2. Формат заголовка iPv6
- •3. Ip версия 6 архитектуры адресации
- •4. Модель адресации
- •4.1. Представление записи адресов (текстовое представление адресов)
- •0:0:0:0:0:0:13.1.68.3 0:0:0:0:0:Ffff:129.144.52.38
- •4.2. Представление типа адреса
- •4.3. Уникастные адреса
- •4.3.1. Примеры уникастных адресов
- •4.4. Не специфицированный адрес
- •4.5. Адрес обратной связи
- •4.6. IPv6 адреса с вложенными iPv4 адресами
- •4.7. Nsap адреса
- •4.8. Ipx Адреса
- •4.9. Провайдерские глобальные уникаст-адреса
- •4.10. Локальные уникаст-адреса iPv6
- •4.11. Эникаст-адреса
- •4.11.1. Необходимые эникаст-адреса
- •4.12. Мульткаст-адреса
- •11111111 В начале адреса идентифицирует адрес, как мультикатинг-адрес.
- •4.12.1. Предопределенные мультикаст-адреса
- •4.13. Необходимые адреса узлов
- •5. Заголовки расширения iPv6
- •5.1. Порядок заголовков расширения
- •6. Опции
- •6.1. Опции заголовка Hop-by-Hop (шаг за шагом)
- •7. Маршрутный заголовок
- •8. Заголовок фрагмента
- •9. Заголовок опций места назначения
- •10. Отсутствие следующего заголовка
- •11. О размере пакетов
- •12. Метки потоков
- •13. Приоритет
- •14. О протоколе верхнего уровня 14.1 Контрольные суммы верхнего уровня
- •15. Максимальное время жизни пакета
- •16. Максимальный размер поля данных для протоколов высокого уровня
- •17. Приложение a. Рекомендации по формированию опций
- •18. Соображения безопасности
- •19. Расширение dns для поддержки ip-версии 6 (dns Extensions to Support ip Version 6. S. Thomson. Rfc-1886)
- •19.1. Определение новой ресурсной записи и домена
- •19.2. Модификации существующих типов запроса
- •20. Протокол управляющих сообщений (icmPv6) для спецификации iPv6 (rfc-1885)
- •20.1. IcmPv6 (icmp для iPv6)
- •20.2. Общий формат сообщений
- •20.3. Сообщения об ошибках icmPv6
- •20.4. Информационные сообщения icmPv6
13. Приоритет
4-битовое поле приоритета в IPv6 заголовке позволяет отправителю идентифицировать относительный приоритет доставки пакетов. Значения приоритетов делятся на два диапазона. Коды от 0 до 7 используются для задания приоритета трафика, для которого отправитель осуществляет контроль перегрузки (например, снижает поток TCP в ответ на сигнал перегрузки). Значения с 8 до 15 используются для определения приоритета трафика, для которого не производится снижения потока в ответ на сигнал перегрузки, например, в случае пакетов “реального времени”, посылаемых с постоянной частотой.
Для трафика, управляемого сигналами перегрузки, рекомендуются следующие значения приоритета для конкретных категорий приложений (см. таблицу 4.4.1.1.2).
Таблица 4.4.1.1.2. Значения кодов приоритета
Код приоритета |
Назначение |
0 |
Нехарактеризованный трафик |
1 |
Заполняющий трафик (например, сетевые новости) |
2 |
Несущественный информационный трафик (например, электронная почта) |
3 |
Резерв |
4 |
Существенный трафик (напр., FTP, HTTP, NFS) |
5 |
Резерв |
6 |
Интерактивный трафик (напр. telnet, x) |
7 |
Управляющий трафик Интернет (напр., маршрутные протоколы, snmp) |
Предполагается, что чем больше код, тем выше приоритет данных, тем быстрее они должны быть доставлены. Так для передачи мультимедийной информации, где управление скоростью передачи не возможно, уровень приоритета должен лежать в пределах 8-15. Практически, уровни приоритета выше или равные 8 зарезервированы для передачи данных в реальном масштабе времени.
Для трафика, не контролируемого на перегрузки, нижнее значение приоритета (8) должно использоваться для тех пакетов, которые отправитель разрешает выбросить в случае перегрузки (например, видео трафик высокого качества), а высшее значение (15) следует использовать для пакетов, которые отправитель не хотел бы потерять (напр., аудио трафик с низкой надежностью). Не существует связи между относительными приоритетами обменов с и без контроля перегрузки.
14. О протоколе верхнего уровня 14.1 Контрольные суммы верхнего уровня
Любой транспортный или другой протокол верхнего уровня, который включает адреса IP-заголовка в свою контрольную сумму, должен быть модифицирован, чтобы работать с 128-битовыми IPv6адресами вместо 32-битовых IPv4. В частности, ниже показаны псевдо-заголовки для TCP и UDPв IPv6 (рис. 4.4.1.1.26):
Рис. 4.4.1.1.26. Формат псевдо-заголовков для TCP и UDP
Если пакет содержит заголовок маршрутизации, в качестве адреса места назначения в псевдо-заголовке используется оконечный адрес. В исходном узле этот адрес будет последним элементом заголовка маршрутизации; для узла получателя он будет находиться в поле адрес места назначения IPv6 заголовка.
Код поля следующий заголовок в псевдо-заголовке идентифицирует протокол верхнего уровня (например, 6 для TCPили 17 для UDP). Он будет отличаться от кода поля следующий заголовок в IPv6 заголовке, если имеются заголовки расширения между заголовком IPv6 и заголовком протокола верхнего уровня.
В качестве кода длины поля данных в псевдо-заголовке используется длина пакета протокола верхнего уровня, включая заголовок верхнего уровня. Он будет меньше длины поля данных в заголовке (или в опции Jumbo Payload), если имеются заголовки расширения между IPv6 заголовком и заголовком верхнего уровня.
В отличие от IPv4, при формировании udp пакетов в IPv6 узле, контрольная сумма не является опционной. Поэтому при формировании UDP-пакета IPv6 узел должен вычислить контрольную UDP сумму пакета и псевдо-заголовка и, если вычисление дает в качестве результата нуль, он должен быть заменен на FFFF для помещения в UDP заголовок. IPv6-получатели должны выбрасывать UDP пакеты, содержащие нулевую контрольную сумму и фиксировать при этом состояние ошибки.
IPv6 версия ICMP-пакетов [RFC-1885] включает псевдо-заголовок в вычисление контрольной суммы; это отличается от IPv4 версии ICMP, которая не включает псевдо-заголовок в контрольную сумму. Причина изменения связана с попыткой защитить ICMP от некорректной доставки или искажений важных полей в IPv6 заголовке, который в отличие от IPv4 не защищен контрольным суммированием на интернет-уровне. Поле следующий заголовок в псевдо-заголовке для ICMP содержит код 58, который идентифицирует IPv6 версию ICMP.