RFC 4727 Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers

Network Working Group                                      B. Fenner
Request for Comments: 4727                      AT&T Labs - Research
Category: Standards Track                              November 2006

Экспериментальные значения в заголовках IPv4, IPv6, ICMPv4, ICMPv6, UDP и TCP

Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers

PDF

Статус документа

В этом документе приведена спецификация проекта стандартного протокола Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущий статус стандартизации протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Документ может распространяться свободно.

Авторские права

Copyright (C) The IETF Trust (2006).

Аннотация

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

1. Введение

[RFC3692] рекомендует выделять номера опций для экспериментов и тестирования. В этом документе зафиксировано несколько случаев выделения таких значений для пространств имен, которые требуют согласования с IANA в соответствии с [RFC2780]. Этот документ в основном следует [RFC2780].

При использовании таких значений следует внимательно рассмотреть рекомендации разделов 1 и 1.1 документа [RFC3692]. Не следует просто выбирать одно из таких значений и жестко фиксировать его в системе.

Примечание. Хотя в [RFC3692] сказано, что выделение значение для портов UDP и TCP может не быть обязательным, в разделах 6 и 7.1 явно резервируются порты для экспериментов во избежание возникновения конфликтов.

2. Поля в заголоках IPv4

Заголовок IPv4 [RFC0791] содержит ряд полей, значения для которых распределяются агентством IANA. К таким полям относятся Version, Type of Service, Protocol, Source Address, Destination Address и Option Type.

2.1. Поле IP Version в заголовке IPv4

Поле Version в заголовках IPv4 всегда имеет значение 4.

2.2. Поле Type of Service в IPv4

[RFC2474] определяет пул 2 (Pool 2 — все коды вида xxxx11, где x может принимать значение 0 или 1), как предназначенный для экспериментов и локального использования (Experimental/Local Use), поэтому дополнительных кодов определять не требуется. Для поля ECN¹ [RFC3168] свободных кодов для распределения уже нет.

2.3. Поле Protocol в IPv4

[RFC3692] выделяет в поле IPv4 Protocol два значения кодов для экспериментальных целей (253 и 254).

2.4. Адреса отправителя и получателя IPv4

2.4.1. Индивидуальные адреса IPv4

Адресов IPv4 для экспериментальных целей не выделено. Для некоторых экспериментов могут быть полезны блоки адресов, выделенные для приватного использования в [RFC1918]. Другие адреса IPv4 специального назначения [RFC3330] не следует использовать для экспериментов.

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

2.4.2. Групповые адреса IPv4

Группа 224.0.1.20 с глобальной маршрутизацией выделена для экспериментов. Для некоторых экспериментов могут оказаться полезными группы, определенные в [RFC2365]. Этот документ определяет одну группу с видимостью на уровне локального соединения — 254.

2.5. Поле IPv4 Option Type

Этот документ выделяет один номер опции с определенными значениями полей copy и class, что дает в результате четыре разных кода типа опции. Значения приведены в разделе 8.

3. Поля заголовков IPv6

Заголовок IPv6 [RFC2460] содержит следующие поля, значения для которых выделяются из контролируемых IANA пространств имен: Version, Traffic Class, Next Header, Source Address и Destination Address. В дополнение к этому заголовки расширения IPv6 Hop-by-Hop Options и Destination Options включают поле Option Type, значения которого выделяются из контролируемого IANA пространства имен. Заголовок IPv6 Routing Header содержит поле Type, для которого в настоящее время не определена явно политика распределения для IANA.

3.1. Поле IP Version в заголовке IPv6

Поле Version в пакетах IPv6 всегда имеет значение 6.

3.2. Поле IPv6 Traffic Class

[RFC2474] определяет Pool 2 (все коды имеют значения xxxx11, где x может принимать значение 0 или 1), как Experimental/Local Use, поэтому дополнительные коды для экспериментов не требуются. Поле ECN [RFC3168] не имеет свободных кодов для распределения.

3.3. Поле IPv6 Next Header

[RFC3692] выделяет два экспериментальных кода (253 и 254) для поля IPv6 Next Header.

3.4. Адреса отправителя и получателя IPv6

3.4.1. Индивидуальные адреса IPv6

[RFC2928] определяет набор адресов IPv6 для тестирования и экспериментов.

Блок Sub-TLA ID, выделенный IANA (т. е., 2001:0000::/29 — 2001:01F8::/29) предназначен для тестов и экспериментов в поддержку таких направлений, как 6bone,а также для новых приложений типа точек обмена.

Однако на момент написания этого документа не было известно о выделении для экспериментов адресов IPv6 в стиле RFC3692. В работе [HUSTON05] предложен реестр IANA, который в будущем может включать такие адреса. Для некоторых экспериментов могут быть полезны уникальные локальные адреса (ULA²) [RFC4193]. Адреса из префикса, выделенного для документов [RFC3849], не подходят для экспериментирования.

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

3.4.2. Групповые адреса IPv6

Группа FF0X::114 выделена для экспериментов во всех областях действия. Более мелкие области действия могут быть особенно полезны для экспериментов, поскольку они определены так, чтобы не выходить за указанную границу, в качестве которой может быть выбрана граница эксперимента. Для некоторых экспериментов могут быть полезны иные групповые адреса с установленным битом T (временный адрес) bit [RFC4291].

3.5. Поля IPv6 Hop-by-Hop и Destination Option

Этот документ выделяет один тип опций со всеми возможными значениями полей act и chg, что дает 8 различных кодов типа опции. Выделенные значения рассмотрены в разделе 8.

3.6. Тип маршрутизации в заголовке IPv6 Routing

Этот документ выделяет два значения для поля Routing Type в заголовке IPv6 Routing Header — 253 и 254.

4. Поля в заголовке IPv4 ICMP

Этот документ выделяет два новых значения для типов ICMPv4 — 253 и 254. Значения кодов ICMPv4 выделяются по типам, поэтому нет смысла присваивать в этом документе экспериментальные значения.

5. Поля в заголовке IPv6 ICMP

[RFC4443] включает экспериментальные значения типов ICMPv6 для сообщений Informational (информационное — 200, 201) и Error (ошибка — 100, 101). Значения кодов ICMPv6 выделяются по типам, поэтому нет смысла присваивать в этом документе экспериментальные значения.

5.1. Поля IPv6 Neighbor Discovery

Заголовок IPv6 Neighbor Discovery [RFC2461] содержит три поля, использующие значения из распределяемого IANA пространства — Type, Code, Option Type.

5.1.1. IPv6 Neighbor Discovery Type

Поле Neighbor Discovery Type совпадает с полем ICMPv6 Type. Значения приведены в разделе 8³.

5.1.2. IPv6 Neighbor Discovery Code

Поле ICMPv6 Code не используется IPv6 Neighbor Discovery и экспериментальные значения не требуются.

5.1.3. IPv6 Neighbor Discovery Option Type

Этот документ выделяет два значения типов IPv6 Neighbor Discovery Option — 253 и 254.

6. Поля в заголовке UDP

Два номера портов (1021 и 1022) зарезервированы для экспериментов с протоколами UDP и TCP.

7. Поля в заголовке TCP

7.1. Порты отправителя и получателя TCP

Два номера портов (1021 и 1022) зарезервированы для экспериментов с протоколами UDP и TCP.

7.2. Резервные биты в заголовке TCP

Число резервных битов недостаточно для выделения экспериментальных значений.

7.3. Поле TCP Option

Две опции TCP с номерами 253 и 254 выделены для экспериментов с TCP Option.

8. Согласование с IANA

Ниже приведены новые значения, выделенные в этом документе.

Групповые адреса IPv4 (групповые адреса (224.0.0/24) раздел Local Network Control Block) (параграф 2.4.2)

Групповой адрес	Описание
224.0.0.254	Эксперименты в стиле RFC36924

Групповые адреса IPv4 (групповые адреса, раздел относительной адресации) (параграф2.4.2)

Относительный адрес	Описание
254	Эксперименты в стиле RFC36922

Номера опций IPv4 (раздел ip-parameters) (параграф 2.5)

Копия	Класс	Номер	Значение
0	0	30	30
0	2	30	94
1	0	30	158
1	2	30	222

Типы опций IPv6 (ipv6-parameters, параграф5.b.) (параграф 3.5)

HEX	act	chg	rest
0x1e	00	0	11110
0x3e	00	1	11110
0x5e	01	0	11110
0x7e	01	1	11110
0x9e	10	0	11110
0xbe	10	1	11110
0xde	11	0	11110
0xfe	11	1	11110

Форматы IPv6 Neighbor Discovery Option (icmpv6-parameters) (параграф 5.1.3)

Тип	Описание
253	Эксперименты в стиле RFC36922
254	Эксперименты в стиле RFC36922

Типы IPv6 Routing Header Routing Types (ipv6-parameters, параграф 5.c.) (параграф 3.6)

Тип	Описание
253	Эксперименты в стиле RFC36925
254	Эксперименты в стиле RFC36921

Типы ICMPv4 (icmp-parameters) (параграф 4)

Тип	Описание
253	Эксперименты в стиле RFC36921
254	Эксперименты в стиле RFC36921

Номера портов (port-numbers) (параграфы 6 и 7.1)

Обозначение	Номер	Описание
exp1	1021/udp	Эксперименты в стиле RFC36921
exp1	1021/tcp	Эксперименты в стиле RFC36921
exp2	1022/udp	Эксперименты в стиле RFC36921
exp2	1022/tcp	Эксперименты в стиле RFC36921

Опции TCP (tcp-parameters) (параграф 7.3)

Тип	Размер	Описание
253	N	Эксперименты в стиле RFC36921
254	N	Эксперименты в стиле RFC36921

Каждый из этих реестров сопровожден примечанием.

(*) Использование этого значения приемлемо только в явных экспериментах, недопустима поставка с установленным по умолчанию таким значением. См. RFC 3692.

9. Вопросы безопасности

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

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

Поскольку экспериментальные опции IPv4, определенные в параграфе 2.5, не учитываются при расчетах IPsec AH [RFC4302], аутентификация их использования не возможна. Об этом следует помнить при разработке и постановке экспериментов. Пользователи экспериментальных опций IPv6, определенных в параграфе 3.5, могут самостоятельно решить вопрос о включении этих опций в расчет AH, выбирая значение поля chg.

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

10. Литература

10.1. Нормативные документы

[RFC0791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, February 1996.

[RFC2365] Meyer, D., «Administratively Scoped IP Multicast», BCP 23, RFC 2365, July 1998.

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460⁶, December 1998.

[RFC2461] Narten, T., Nordmark, E., and W. Simpson, «Neighbor Discovery for IP Version 6 (IPv6)», RFC 2461, December 1998.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.

[RFC2780] Bradner, S. and V. Paxson, «IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers», BCP 37, RFC 2780, March 2000.

[RFC2928] Hinden, R., Deering, S., Fink, R., and T. Hain, «Initial IPv6 Sub-TLA ID Assignments», RFC 2928, September 2000.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, September 2001.

[RFC3330] IANA, «Special-Use IPv4 Addresses», RFC 3330, September 2002.

[RFC3692] Narten, T., «Assigning Experimental and Testing Numbers Considered Useful», BCP 82, RFC 3692, January 2004.

[RFC3849] Huston, G., Lord, A., and P. Smith, «IPv6 Address Prefix Reserved for Documentation», RFC 3849, July 2004.

[RFC4193] Hinden, R. and B. Haberman, «Unique Local IPv6 Unicast Addresses», RFC 4193, October 2005.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[RFC4302] Kent, S., «IP Authentication Header», RFC 4302, December 2005.

[RFC4443] Conta, A., Deering, S., and M. Gupta, «Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification», RFC 4443, March 2006.

10.2. Дополнительная литература

[HUSTON05] Huston, G., «Administration of the IANA Special Purpose Address Block», Work in Progress⁷, December 2005.

Адрес автора

Bill Fenner

AT&T Labs — Research

75 Willow Rd

Menlo Park, CA 94025

USA

Phone: +1 650 330-7893

EMail: fenner@research.att.com

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The IETF Trust (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Интеллектуальная собственность

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

---