RFC 5737 IPv4 Address Blocks Reserved for Documentation

Internet Engineering Task Force (IETF)                      J. Arkko
Request for Comments: 5737                                  Ericsson
Updates: 1166                                              M. Cotton
Category: Informational                                    L. Vegoda
ISSN: 2070-1721                                                ICANN
                                                        January 2010

 

 

Блок адресов IPv4, зарезервированных для документации

IPv4 Address Blocks Reserved for Documentation

PDF

Тезисы

Три блока индивидуальных (unicast) адресов IPv4 зарезервированы для использования в качестве примеров в спецификациях и других документах. В данном документе описано использование этих блоков.

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

Этот документ не является спецификацией проекта стандарта Internet и публикуется с информационными целями.

Документ является результатом работы IETF1 и представляет согласованное мнение сообщества IETF. Документ был вынесен на открытое обсуждение и одобрен для публикации IESG2. Не все документы, одобренные IESG, претендуют на статус тех или иных стандартов Internet (см. раздел 2 документа RFC 5741).

Информация о статусе этого документа, обнаруженных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc5737.

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

Авторские права (c) 2010 принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

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

В [RFC1166] зарезервирован первый из трех адресных блоков — 192.0.2.0/24. Два других блока были выделены недавно, прежде всего для упрощения подготовки примеров, включающих адресацию для множества сетей.

Прочие пространства идентификаторов для документации были определены IETF и включают префикс IPv6 для документации [RFC3849] и примеры доменных имен [RFC2606]. В документации могут также использоваться диапазоны адресов, определенные в [RFC1918].

2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119].

3. Блоки адресов для документации

Блоки адресов 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) и 203.0.113.0/24 (TEST-NET-3) предназначены для использования в документации.

4. Operational Implications

Адреса из блоков TEST-NET-1, TEST-NET-2 и TEST-NET-3 не следует применять в публичной сети Internet. Эти адреса могут использоваться без какой-либо координации с IANA или регистраторами Internet [RFC2050]. Сетевым операторам следует добавить эти блоки адресов в число немаршрутизируемых, а при использовании пакетных фильтров следует добавить эти адреса в списки фильтрации.

Блоки адресов не предназначены для локального использования и фильтры могут применяться как в локальном, так и в публичном контексте.

5. Статус блока 128.66.0.0/16

Отметим, что в прошлом для примеров иногда использовался блок адресов 128.66.0.0/16. Однако этот блок исключен из списка префиксов специального назначения [RFC3330] и, следовательно, больше не является зарезервированным для таких целей. При обычном использовании данного блока следует соблюдать осторожность.

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

Этот документ не оказывает влияния на безопасность.

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

Агентство IANA зафиксировало выделение трех описанных здесь блоков адресов IPv4 в реестре адресов. Эти адреса не выделены кому-либо конкретно.

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

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

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

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

[RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, «Internet numbers», RFC 1166, July 1990.

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

[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J. Postel, «INTERNET REGISTRY IP ALLOCATION GUIDELINES», BCP 12, RFC 2050, November 1996.

[RFC2606] Eastlake, D. and A. Panitz, «Reserved Top Level DNS Names», BCP 32, RFC 2606, June 1999.

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

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

Приложение A. Благодарности

Авторы хотят выразить свою признательность регистратору APNIC, номинировавшему блоки 198.51.100.0/24 и 203.0.113.0/24 для использования в документации. Авторы также отмечают с благодарностью, что этот документ наследует материалы из [RFC3849].

Авторы благодарны Geoff Huston, Peter Koch, Ulf Olsson, John Klensin и другим людям за интересные дискуссии по теме.

Адреса авторов

Jari Arkko

Ericsson

Jorvas 02420

Finland

EMail: jari.arkko@piuha.net

Michelle Cotton

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey 90292

United States of America

Phone: +1-310-823-9358

EMail: michelle.cotton@icann.org

URI: http://www.iana.org/

Leo Vegoda

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey 90292

United States of America

Phone: +1-310-823-9358

EMail: leo.vegoda@icann.org

URI: http://www.iana.org/


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

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

nmalykh@gmail.com

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

4В настоящее время этот документ утратил силу и заменен RFC 5735. Прим. перев.




RFC 5736 IANA IPv4 Special Purpose Address Registry

Internet Engineering Task Force (IETF)                     G. Huston
Request for Comments: 5736                                     APNIC
Category: Informational                                    M. Cotton
ISSN: 2070-1721                                            L. Vegoda
                                                               ICANN
                                                        January 2010

 

 

Реестр IANA для адресов IPv4 специального назначения

IANA IPv4 Special Purpose Address Registry

PDF

Тезисы

В этом документе содержатся рекомендации агентству IANA по созданию и поддержке реестра адресов IPv4 специального назначения (IANA IPv4 Special Purpose Address Registry).

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

Этот документ не является спецификацией проекта стандарта Internet и публикуется с информационными целями.

Документ является результатом работы IETF1 и представляет согласованное мнение сообщества IETF. Документ был вынесен на открытое обсуждение и одобрен для публикации IESG2. Не все документы, одобренные IESG, претендуют на статус тех или иных стандартов Internet (см. раздел 2 документа RFC 5741).

Информация о статусе этого документа, обнаруженных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc5736.

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

Авторские права (c) 2010 принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено из версии HTML

1. Введение

В этом документе содержатся рекомендации агентству [IANA] по созданию и поддержке реестра адресов IPv4 специального назначения (IANA IPv4 Special Purpose Address Registry). Реестр будет служить для записи выделенных IETF протокольных значений, начиная с блока 192.0.0.0/24 и продолжая новыми адресными префиксами, которые будут распределены впоследствии, как описано в разделе 3.

2. Блок адресов специального назначения IANA IPv4

В [RFC5735] указано выделение адресного префикса IPv4 агентством IANA для распределения протоколов IETF.

192.0.0.0/24 — этот блок зарезервирован IETF для протоколов.

Это выделение адресов агентству IANA предназначено для поддержки выделения протоколов IETF. Более общее рассмотрение роли IANA в части распределения адресов приведено в документе [RFC2860]:

4.3. […] Отметим, что […] (b) выделение специализированных адресных блоков (таких, как блоки для групповой или индивидуальной адресации), (c) экспериментальное выделение не относятся к вопросам политики и продолжают оставаться субъектом положений данного раздела 4 (в данном MOU термин «присваивание» включает и выделение).

Ссылка на раздел 4 приведена для указания на общую техническую роль IANA, как указано в [RFC2860]:

4.1. Агентство IANA будет выделять и регистрировать параметры протоколов Internet только в соответствии с критериями и процедурами, заданными в документах RFC, включая проекты — Proposed, Draft, законченные документы — Internet Standard и BCP3, а также любые другие RFC, где указано присваивание через IANA.

Этот документ служит руководством для IANA по выделению блока адресов специального назначения в соответствии с [RFC2860].

Этот документ запрашивает у IANA создание реестра адресов специального назначения IPv4 Special Purpose Address Registry для управления выделенными IANA адресными блоками. Регистрация адресов специального назначения будет осуществляться из этого реестра для присваивания протоколов IETF и иных специальных целей, как указано в рассмотренных IESG документах RFC в соответствии с условиями, приведенными в параграфе 4.1 документа [RFC2860].

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

IANA поддерживает реестр «IANA IPv4 Special Purpose Address Registry», содержащий текущее выделение блока адресов из поддерживаемого IANA пула адресов IPv4 специального назначения.

Эти рекомендации относятся к поддержке адресного пула, используемого IETF для присвоения протоколов, как указано в [RFC5735], а именно — блока 192.0.0.0/24. В соответствии с правилами, указанными в [RFC5226], дальнейшее выделение адресного пространства агентству IANA для последующего выделения адресных префиксов с указанными здесь целями следует выполнять только по процедуре IETF Review.

IANA может выделить адреса специального назначения для тестов и экспериментов, инициируемых IETF, или для специализированного применения указанного адресного блока в контексте (например, anycast), связанном с проектом стандартного протокола Internet. Все такие назначения адресов должны документироваться в разделе «Согласование с IANA (IANA Considerations), рассматриваемого IESG документа RFC.

Реестр IANA IPv4 Special Purpose Address Registry включает для текущего назначения адресов, выполненного IANA:

  1. префикс назначенных адресов;
  2. указание RFC, в котором запрошено у IANA назначение адресов;
  3. дату назначения адресов;
  4. дату прекращения использования (если адреса назначаются на ограниченный срок);
  5. назначение выделенных адресов (например, эксперименты с unicast или протоколом anycast);
  6. для экспериментальных приложений и в других случаях, когда это применимо, в реестре указывается идентификация объекта и контактные данные, связанные с назначением адресов;
  7. в реестре для каждого выделения будет указываться также область маршрутизации адреса (локальная, приватная или глобальная маршрутизация);
  8. в качестве даты указывается дата соответствующего действия IANA (например, дата выделения).

В данном реестре IANA в качестве комментария общего назначения указывается, что префиксы, перечисленные в реестре адресов специального назначения (IPv4 Special Purpose Address Registry) не обязательно будут маршрутизируемыми в любом конкретном приватном или глобальном контексте.

IANA не поддерживает дополнительных субреестров для любого из блока адресов IPv4 специального назначения, выделенного в соответствии с этим документом.

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

Безопасность системы маршрутизации Internet базируется на способности обеспечить контроль за уникальностью блоков адресов. Защитные меры основываются на контроле принадлежности блока адресов к известному выделенному блоку и наличия достоверной и уникальной ссылки на этот блок в адресном реестре IANA.

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

5. Благодарности

Этот документ основан на документе [RFC4773], подготовленном с участием Leslie Daigle, Brian Haberman, Bob Hinden, David Kessens, Kurt Lindqvist, Thomas Narten и Paul Wilson. Хотя не все из этих людей явно принимали явное участие в подготовке данного документа, благодарим их за участие в работе над исходным документом.

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

[IANA] IANA, «IANA Matrix for Protocol Parameter Assignment/Registration Procedures», <http://www.iana.org/numbers.html>.

[RFC2860] Carpenter, B., Baker, F., and M. Roberts, «Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority», RFC 2860, June 2000.

[RFC4773] Huston, G., «Administration of the IANA Special Purpose IPv6 Address Block», RFC 4773, December 2006.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5735] Cotton, M. and L. Vegoda, «Special Use IPv4 Addresses», BCP 153, RFC 5735, January 2010.

Адреса авторов

Geoff Huston

Asia Pacific Network Information Centre

PO Box 2131

Milton, QLD 4064

Australia

Phone: +61-7-3858-3100

EMail: gih@apnic.net

URI: http://www.apnic.net/

Michelle Cotton

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey, CA 90292-6601

USA

Phone: +1-310-823-9358

EMail: michelle.cotton@icann.org

URI: http://www.iana.org/

Leo Vegoda

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey, CA 90292-6601

USA

Phone: +1-310-823-9358

EMail: leo.vegoda@icann.org

URI: http://www.iana.org/


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

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

nmalykh@gmail.com

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Best Current Practice.




RFC 5735 Special Use IPv4 Addresses

Internet Engineering Task Force (IETF)                     M. Cotton
Request for Comments: 5735                                 L. Vegoda
BCP: 153                                                       ICANN
Obsoletes: 3330                                         January 2010
Category: Best Current Practice
ISSN: 2070-1721

Адреса IPv4 специального назначения

Special Use IPv4 Addresses

PDF

Тезисы

Этот документ служит заменой RFC 3330 и описывает блоки адресов IPv4 специального назначения, выделенные агентством IANA1. Документ не рассматривает адресное пространство IPv4, выделяемое операторам и пользователям через региональные агентства RIR2, а также адресное пространство IPv4, распределенное IANA до образования агентств RIR. Документ также не рассматривает распределения адресного пространства IPv6 и номеров автономных систем.

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

Этот документ относится к категории обмена опытом (Internet BCP3).

Документ является результатом работы IETF4 и представляет согласованное мнение сообщества IETF. Документ был вынесен на открытое обсуждение и одобрен для публикации IESG5. Дополнительную информацию о серии документов BCP можно найти в разделе 2 документа RFC 5741.

Информация о статусе этого документа, обнаруженных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc5735.

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

Авторские права (c) 2010 принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено из версии HTML

1. Введение

В процессе развития сети Internet было организовано центральное агентство IANA, ответственное за распределение различных идентификаторов, требуемых для работы Internet [RFC1174]. В части адресного пространства IPv4 агентство IANA выделяет блоки адресов региональным агентствам (RIR) в соответствии с их потребностями. Региональные агентства отвечают за распределение полученных блоков адресов между операторами и пользователями в рамках своего региона.

Агентство IANA было на постоянной основе назначено IETF выполнять распределение в поддержку процессов стандартизации Internet [RFC2860]. Сам процесс распределения описан в разделе 4 указанного документа.

Небольшие фрагменты адресного пространства IPv4 были выделены IANA для использования в качестве адресов специального назначения. Факты такого выделения адресного пространства зафиксированы в различных RFC и других документах. Задачей этого документа является сбор воедино этих разрозненных распределений и составление единого списка адресов IPv4 специального назначения.

Этот документ является пересмотром RFC 3330 [RFC3330], который утрачивает силу; основной целью пересмотра является учет изменений в списке выделенных адресов IPv4 специального назначения, которые произошли с момента публикации RFC 33306. Аналогичные задачи для адресов специального назначения IPv6 решены в [RFC5156].

2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119].

3. Блоки адресов специального назначения

0.0.0.0/8 — адреса этого блока указывают хосты-отправители из данной сети (this network). Адрес 0.0.0.0/32 может использоваться в качестве адреса отправителя «данный хост данной сети» (this host on this network), а прочие адреса из блока 0.0.0.0/8 могут указывать на конкретные хосты данной сети ([RFC1122], параграф 3.2.1.3).

10.0.0.0/8 — этот блок предназначен для использования в приватных сетях. Его применение документировано в [RFC1918], где указано, что адреса из данного блока не являются легитимными в публичной сети Internet. Этот блок адресов может использоваться без согласования с IANA или регистраторами Internet.

127.0.0.0/8 — этот блок предназначен для использования в качестве loopback-адресов хостов Internet. Дейтаграмма, переданная протоколом вышележащего уровня по адресу из этого блока, не покинет этот хост (вернется ему же). Изначально этот процесс был реализован с использованием одного адреса 127.0.0.1/32. Как указано в [RFC1122] (параграф 3.2.1.3), адреса из блока 127.0.0.0/8 не могут легитимно появляться где-либо в сети.

169.254.0.0/16 — этот блок используется для «локального» канала (link local). Как указано в [RFC3927], адреса из этого блока выделяются для связи между хостами, подключенными к одному каналу. Хосты получают такие адреса через процедуры автоматического конфигурирования, если не удается обнаружить сервер DHCP7.

172.16.0.0/12 — этот блок предназначен для использования в приватных сетях. Его применение документировано в [RFC1918], где указано, что адреса из данного блока не являются легитимными в публичной сети Internet. Этот блок адресов может использоваться без согласования с IANA или регистраторами Internet.

192.0.0.0/24 — этот блок зарезервирован IETF для протоколов. На момент подготовки данного документа каких-либо адресов из этого блока не было распределено. Процедура выделения адресов из данного блока описана в [RFC5736].

192.0.2.0/24 — этот блок выделен, как тестовая сеть TEST-NET-1 для использования в документации и примерах кода. Зачастую этот блок используется вместе с именами типа example.com или example.net в документации на оборудование и протоколы. Как указано в [RFC5737], адреса из этого блока не являются легитимными для публичной сети Internet и могут использоваться без согласования с IANA или регистраторами Internet (см. [RFC1166]).

192.88.99.0/24 — этот блок выделен для использования в качестве индивидуальных адресов при трансляции 6to4 [RFC3068]. В отличии от описанных ранее блоков пакеты, адресованные в этот блок, могут появляться в публичной сети Internet. В параграфе 7 документа [RFC3068] описано практическое использование этих адресов с учетом предотвращения злоупотреблений адресами из данного блока в протоколах маршрутизации.

192.168.0.0/16 — этот блок предназначен для использования в приватных сетях. Его применение документировано в [RFC1918], где указано, что адреса из данного блока не являются легитимными в публичной сети Internet. Этот блок адресов может использоваться без согласования с IANA или регистраторами Internet.

198.18.0.0/15 — этот блок выделен для использования при тестировании производительности устройств межсетевого взаимодействия. В [RFC2544] указано, что этот блок выделен с целью минимизации вероятности возникновения конфликтов при тестировании, когда проверяемое устройство может оказаться подключенным к сети Internet. Пакеты с адресами отправителя из этого блока не пересылаются через Internet.

198.51.100.0/24 — этот блок выделен, как тестовая сеть TEST-NET-2 для использования в документации и примерах кода. Зачастую этот блок используется вместе с именами типа example.com или example.net в документации на оборудование и протоколы. Как указано в [RFC5737], адреса из этого блока не являются легитимными для публичной сети Internet и могут использоваться без согласования с IANA или регистраторами Internet.

203.0.113.0/24 — этот блок выделен, как тестовая сеть TEST-NET-3 для использования в документации и примерах кода. Зачастую этот блок используется вместе с именами типа example.com или example.net в документации на оборудование и протоколы. Как указано в [RFC5737], адреса из этого блока не являются легитимными для публичной сети Internet и могут использоваться без согласования с IANA или регистраторами Internet.

224.0.0.0/4 — этот блок, известный ранее, как пространство адресов класса D, был выделен для использования в качестве групповых (multicast) адресов IPv4. Рекомендации IANA по использованию адресов из этого блока даны в [RFC3171].

240.0.0.0/4 — этот блок, известный ранее, как пространство адресов класса E, зарезервирован для использования в будущем (см. параграф 4 [RFC1112]).

Единственным исключением из этого блока является адрес «ограниченного широковещания» (limited broadcast) 255.255.255.255. Как указано в [RFC0919] и [RFC0922], пакеты с таким адресом получателя не пересылаются на уровне IP.

4. Таблица выделенных блоков

Блок адресов Назначение Документ
0.0.0.0/8 Данная сеть RFC 1122, параграф 3.2.1.3
10.0.0.0/8 Использование в приватных сетях RFC 1918
127.0.0.0/8 Loopback-интерфейс RFC 1122, параграф 3.2.1.3
169.254.0.0/16 Локальное соединение (Link Local) RFC 3927
172.16.0.0/12 Использование в приватных сетях RFC 1918
192.0.0.0/24 Резерв IETF для протоколов RFC 5736
192.0.2.0/24 Тестовая сеть TEST-NET-1 RFC 5737
192.88.99.0/24 Индивидуальный адрес для трансляции 6to4 RFC 3068
192.168.0.0/16 Использование в приватных сетях RFC 1918
198.18.0.0/15 Тестирование производительности устройств межсетевого взаимодействия RFC 2544
198.51.100.0/24 Тестовая сеть TEST-NET-2 RFC 5737
203.0.113.0/24 Тестовая сеть TEST-NET-3 RFC 5737
224.0.0.0/4 Групповая адресация RFC 3171
240.0.0.0/4 Резерв для использования в будущем RFC 1112, раздел 4
255.255.255.255/32 RFC 919, раздел 7, RFC 922, раздел 7

5. Выделение блоков адресов IPv4 для обычного использования

Агентство IANA отвечает за распределение параметров протоколов, используемых в сети Internet, в соответствии с требованиями документа Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority [RFC2860]. Наряду с прочим, [RFC2860] требует, чтобы протокольные параметры выделялись в соответствии с критериями и процедурами, указанными в документах серии RFC, включая проекты — Proposed, Draft и завершенные документы Internet Standards, Best Current Practice, а также любых других RFC, связанных с распределением через агентство IANA.

С пространствами доменных имен и адресов IP связаны вопросы политики (правил), наряду с техническими вопросами, поэтому требования [RFC2860] в общем случае неприменимы к этим пространствам. Тем не менее, IANA отвечает за распределение адресов IPv4 в соответствии с процессом стандартизации Internet8. Когда часть пространства адресов IPv4 запрашивается тем или иным RFC, в соответствии с [RFC5226] требуется описание технических требований (например, размер блока, длина префикса). Непосредственно перед публикацией RFC агентство IANA, консультируясь с региональными регистраторами (RIR), выделяет требуемые адреса и уведомляет редактора документа (RFC Editor) о публикации RFC.

В соответствии с требованиями [RFC2860], IANA также распределяет адреса IPv4 для экспериментов, консультируясь с RIR.

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

В этом документе описана прошлая и современная практика IANA в части выделения адресов и не запрашивается какого-либо нового выделения пространства от IANA.

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

Практическое выделение адресов IPv4 специального назначения, каталогизированное в этом документе, не порождает непосредственно проблем безопасности. Тем не менее, в сети Internet нет средств защиты от злоупотреблений такими адресами. Например, если вы предполагаете, что все пакеты из вашего приватного адресного пространства (скажем, 10.0.0.0/8 или 169.254.0.0/16) исходят из вашей сети, все маршрутизаторы на периметре сети должны фильтровать пакеты от внешних отправителей с такими адресами. Возможна организация атак, основанных на неожиданном использовании таких адресов.

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

8. Благодарности

Множество людей предоставило свои отклики на предварительные версии этого документа. Авторы особо хотят отметить и поблагодарить Scott Bradner, Randy Bush, Harald Alvestrand, Peter Koch, Alfred Hoenes и Jari Arkko за из конструктивные замечания и комментарии. Отдельная благодарность от авторов агентству APNIC, включившему в документ блоки адресов 198.51.100.0/24 и 203.0.113.0/24.

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

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

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

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

[RFC0919] Mogul, J., «Broadcasting Internet Datagrams», STD 5, RFC 919, October 1984.

[RFC0922] Mogul, J., «Broadcasting Internet datagrams in the presence of subnets», STD 5, RFC 922, October 1984.

[RFC1112] Deering, S., «Host extensions for IP multicasting», STD 5, RFC 1112, August 1989.

[RFC1122] Braden, R., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, «Internet numbers», RFC 1166, July 1990.

[RFC1174] Cerf, V., «IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet «connected» status», RFC 1174, August 1990.

[RFC1700] Reynolds, J. and J. Postel, «Assigned Numbers», RFC 170010, October 1994.

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

[RFC2544] Bradner, S. and J. McQuaid, «Benchmarking Methodology for Network Interconnect Devices», RFC 2544, March 1999.

[RFC2860] Carpenter, B., Baker, F., and M. Roberts, «Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority», RFC 2860, June 2000.

[RFC3068] Huitema, C., «An Anycast Prefix for 6to4 Relay Routers», RFC 3068, June 2001.

[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, «IANA Guidelines for IPv4 Multicast Address Assignments», BCP 51, RFC 3171, August 2001.

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

[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, «Dynamic Configuration of IPv4 Link-Local Addresses», RFC 3927, May 2005.

[RFC5156] Blanchet, M., «Special-Use IPv6 Addresses», RFC 5156, April 2008.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5736] Huston, G., Cotton, M., and L. Vegoda, «IANA IPv4 Special Purpose Address Registry», RFC 5736, January 2010.

[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, «IPv4 Address Blocks Reserved for Documentation», RFC 5737, January 2010.

Приложение A. Отличия от RFC 3330

Блоки адресов, которые были зарезервированы в RFC 3330 для специального применения, но перестали быть таковыми, исключены из разделов 4 и 5. В результате этого стали доступны следующие блоки:

  • 14.0.0.0/8 больше не используется для распределения в международных системах передачи данных, как было указано ранее на стр. 181 [RFC1700]; в настоящее время этот блок доступен для распределения региональным агентствам RIR;
  • 24.0.0.0/8 больше не принадлежит американскому агентству ARIN11 (с 2001 года);
  • 39.0.0.0/8 передан для обычного распределения региональным агентствам RIR в 2001 году;
  • 128.0.0.0/16 больше не является резервным и предназначен для нормального распределения региональным агенствам RIR;
  • 191.255.0.0/16 больше не является резервным и предназначен для нормального распределения региональным агенствам RIR;
  • 198.51.100.0/24 выделен в качестве тестовой сети TEST-NET-2 для использования в документации и примерах кода;
  • 203.0.113.0/24 выделен в качестве тестовой сети TEST-NET-3 для использования в документации и примерах кода;
  • 223.255.255.0/24 больше не является резервным и предназначен для нормального распределения региональным агентствам RIR.

Адреса авторов

Michelle Cotton

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey, CA 90292

USA

Phone: +1-310-823-9358

EMail: michelle.cotton@icann.org

URI: http://www.iana.org/

Leo Vegoda

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey, CA 90292

USA

Phone: +1-310-823-9358

EMail: leo.vegoda@icann.org

URI: http://www.iana.org/


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

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

nmalykh@gmail.com

1Internet Assigned Numbers Authority.

2Regional Internet Registry.

3Best Current Practice.

4Internet Engineering Task Force.

5Internet Engineering Steering Group.

6После публикации данного документа был выделен еще один блок адресов специального назначения, описанный в документе RFC 6598. Прим. перев.

7И адрес не задан статически в параметрах конфигурации хоста. Прим. перев.

8Internet Standards Process.

10В соответствии с RFC 3232 этот документ утратил силу. Реестры выделенных идентификаторов доступны по ссылкам на сайте IANA. Прим. перев.

11American Registry for Internet Numbers.