Network Working Group A. Retana Request for Comments: 3021 R. White Category: Standards Track Cisco Systems V. Fuller GTE Internetworking D. McPherson Amber Networks December 2000
Использование префиксов размером 31 бит на каналах «точка-точка» в IPv4
Using 31-Bit Prefixes on IPv4 Point-to-Point Links
Статус документа
Данный документ содержит спецификацию стандартного протокола Internet, предложенного сообществу Internet, и является приглашением к дискуссии в целях развития этого протокола. Сведения о текущем состоянии стандартизации протокола вы найдете в документе «Internet Official Protocol Standards» (STD 1). Документ можно распространять без ограничений.
Авторские права
Copyright (C) The Internet Society (2000). All Rights Reserved.
Аннотация
Обостряющаяся проблема нехватки адресного пространства IP в сети Internet вынуждает к поиску путей хотя бы незначительного повышения эффективности использования адресов. Одним из таких путей является рассматриваемое в данном документе снижение вдвое расхода адресов, выделяемых для соединений «точка-точка» (широко распространенных в инфраструктуре Internet), за счет ограниченного использования масок подсетей размером 31 бит.
1. Введение и мотивация
Осознание проблемы нехватки адресов Internet привело к внесению множества изменений в практику использования адресного пространства и разработке множества подходов для решения этой проблемы:
- более жесткие требования по распределению адресов, предъявляемые IANA и региональными регистраторами [RFC2050];
- использование трансляторов сетевых адресов (NAT1), позволяющее использовать небольшое число адресов, соответствующих требованиям IANA, для большего числа устройств, топологически расположенных за устройством NAT [RFC1631];
- развертывание новых протоколов Internet с увеличенным размером адресного пространства; один из таких протоколов (IPv6 [RFC2460]) прошел требуемые процедуры IETF, но еще недостаточно широко поддерживается оборудованием; на развертывание этого протокола потребуется многолетний переходный период.
До расширения адресного пространства представляется разумным рассмотреть варианты повышения эффективности имеющегося пространства адресов.
Одним из таких вариантов (незначительного) повышения эффективности будет изменение адресации на каналах «точка-точка». Одним из вариантов экономии адресов на таких соединениях служит использование безадресных интерфейсов на каналах «точка-точка» в некоторых частях Internet. Хотя такой подход может казаться решением проблемы, он создает множество новых проблем и, в частности, усложняет управление безадресными каналами и доступ к маршрутизаторам через такие каналы, существенно осложняет обслуживание и поиск неполадок для таких каналов, а также не имеет должной стандартизации [RFC1812].
В настоящее время для подсетей Internet не применяются маски размером более 30 битов (в большинстве случаев), а это ведет к расходу на каждое соединение 4 адресов – два адреса для хостов, адрес сети (все нули) и широковещательный адрес (все единицы). Для соединений «точка-точка», где может быть только две конечных точки и любой пакет, передаваемый в канал, адресуется расположенному на другой стороне канала устройству, такой подход к распределению адресов не обеспечивает эффективного использования адресного пространства.
Другим вариантом является использование на обоих концах канала адресов хостов2. Этот вариант обеспечивает такую же экономию адресного пространства, как при использовании масок подсети размером 31 бит, но его можно применять только на каналах с инкапсуляцией PPP [RFC1332]. Использование адресов хостов позволяет на каждой стороне соединения задавать адреса IP из разных сетей, что усложняет управление каналами и сетями.
Этот документ базируется на идее сохранения пространства IP для адресации каналов «точка-точка» (за счет использования масок подсетей размером более 30 битов) в обеспечением управляемости и максимального соответствия стандартам. Существуют документы [RFC950], в которых уже рекомендуется по возможности использовать для нумерации хостов поле размером 1 бит.
Увидеть экономию адресного пространства в результате реализации предлагаемого изменения легко – для каждого соединения «точка-точка» в сетях будет расходоваться 2 адреса вместо четырех. В масштабах сети с 500 каналами «точка-точка» будет сэкономлено 1000 адресов, что эквивалентно 4 сетям класса C.
2. Префиксы размером 31 бит
В этом разделе рассматривается возможное влияние использования префиксов /31 для каналов «точка-точка» на маршрутизацию и работу Internet. Приведенные здесь соображения отражены в разделе 3.
В этом документе адрес IP интерпретируется, как пара
<Номер сети><Номер хоста>
где <Номер хоста> представляет собой немаскируемую часть адреса. Размер этого поля следует устанавливать не менее 1 бита. В последующем рассмотрении предполагается, что система маршрутизации поддерживает бесклассовую маршрутизацию CIDR в соответствии с [RFC1519].
2.1. Адресация
Если для канала «точка-точка» используется маска размером 31 бит, для поля <Номер хоста> остается только 1 бит. Следовательно, в такой подсети могут существовать только два адреса
{<Номер сети>, 0} и {<Номер сети>, -1}
Эти адреса исторически связаны с номером сети и широковещательным адресом (см. параграф 2.2). Для каналов «точка-точка» такие адреса должны интерпретироваться, как адреса хостов.
2.2. Широковещательные и сетевые адреса
Существует несколько признанных типов широковещательных адресов для сегментов IP [RFC1812]
- направленное широковещание
{<Номер сети>, -1} {<Номер сети>, 0}
Форма {<Номер сети>, 0} является устаревшим вариантом для направленного широковещания, но может до сих пор применяться на старых хостах.
- локальное для канала (ограниченное) широковещание
{-1, -1} {0, 0}
Форма {0, 0} является устаревшим вариантом ограниченного широковещания, но может до сих пор применяться на старых хостах.
При использовании префиксов размером 31 бит остается только два адреса (см. параграф 2.1), что не позволяет использовать направленное широковещание для соединения (см. параграф 2.2.1). Для всего широковещательного трафика на каналах «точка-точка» с маской подсети /31 должно применяться ограниченное широковещание.
Поле <Номер сети> задается администратором сети и является уникальным в масштабе домена маршрутизации. Квалификация IP-адреса получателя в качестве адреса направленного широковещания или адреса хоста выполняется маршрутизатором, напрямую подключенным к сегменту назначения. На используемые в настоящее время маршрутизаторами схемы и алгоритмы пересылки никакого влияния не оказывается.
Назначение этого документа состоит в обсуждении применимости и использования для каналов «точка-точка» префиксов размером 31 бит. Влияние (если таковое есть) на другие типы интерфейсов здесь не рассматривается.
2.2.1. Направленное широковещание
Когда устройство хочет отправить пакет всем хостам данной (скорей удаленной, нежели подключенной напрямую) подсети, он может установить для пакета в качестве адреса получателя широковещательный адрес подсети канала. Такая возможность не поддерживается для каналов «точка-точка» с 31-битовым префиксом.
Как указано в разделе 6, потеря функциональности направленного широковещания может на самом деле давать побочный позитивный эффект в виде некоторого повышения устойчивости сети к некоторым классам DoS-атак [RFC2644, SMURF].
2.3. Влияние на протоколы маршрутизации
Сети с префиксом размером 31 бит не оказывают влияния на используемые протоколы маршрутизации. Большинство из развернутых протоколов предназначены для обеспечения бесклассовой маршрутизации. Более того, обмен данными между партнерами осуществляется с использованием групповой и индивидуальной адресации или ограниченного широковещания (всем хостам локальной сети), ни на одну из которых использование масок подсетей /31 не оказывает влияния.
3. Рекомендации
Высказанные в разделе 2 соображения оказывают влияние на ряд опубликованных ранее документов. В этом разделе подробно рассмотрены корректировки, которые следует внести в соответствующие документы.
3.1. Requirements for Internet Hosts — Communication Layers [RFC1122]
Пункт 3.2.1.3 (e) заменяется приведенным ниже текстом3:
(e) { <Номер сети>, <Номер подсети>, -1 }
Направленное широковещание для заданной подсети. Такой адрес недопустимо использовать в качестве адреса получателя за исключением тех случаев, когда отправитель является одной из двух конечных точек соединения «точка-точка» с 31-битовой маской.
Добавляется новый пункт 3.2.1.3 (h):
(h) { <Номер сети>, <Номер подсети>, 0 }
Номер подсети. Этот адрес не следует использовать в качестве адреса отправителя за исключением ситуаций, когда отправитель является одной из двух конечных точек соединения «точка-точка» с 31-битовой маской. Для других типов каналов пакеты с таким адресом получателя следует отбрасывать без уведомления. Если такие пакеты не отбрасываются, они должны трактоваться, как широковещательные пакеты IP [RFC1812].
3.2. Assigned Numbers [RFC1700]
Пункт (e) раздела «Специальные адреса» во «Введении» заменяется приведенным ниже текстом:
(e) {<Номер сети>, <Номер подсети>, -1}
Направленное широковещание для заданной подсети. Может использоваться только в качестве адреса получателя. Аднако в случаях, когда отправитель является одной из двух конечных точек соединения «точка-точка» с 31-битовой маской, этот адрес может указываться и для отправителя.
3.3. Requirements for IP Version 4 Routers [RFC1812]
Пункт 4.2.2.11 (d) заменяется приведенным ниже текстом:
(d) { <Префикс сети>, -1 }
Направленное широковещание — широковещательные пакеты для указанного сетевого префикса. Такой адрес недопустимо использовать в качестве адреса получателя за исключением тех случаев, когда отправитель является одной из двух конечных точек соединения «точка-точка» с 31-битовой маской. Маршрутизатор может генерировать пакеты Network Directed Broadcast. Маршрутизатор может иметь конфигурационную опцию, позволяющую ему принимать пакеты направленного широковещания, однако по умолчанию эта опция должна быть отключена и, таким образом, маршрутизатору недопустимо принимать пакеты Network Directed Broadcast, пока это явно не задано в конфигурации.
Приведенный выше текст включает обновления, внесенные [RFC2644].
Добавляется новый пункт 4.2.2.11 (f):
(f) { <Номер сети>, <Номер подсети>, 0 }
Номер подсети. Такой адрес не следует использовать в качестве адреса отправителя за исключением тех случаев, когда отправитель является одной из двух конечных точек соединения «точка-точка» с 31-битовой маской. Для других типов каналов пакеты с таким адресом в поле получателя следует отбрасывать без уведомления. Если такие пакеты не отбрасываются, они должны трактоваться, как широковещательные пакеты IP.
В параграфе 4.2.3.1 пункты (1), (2) и (4) заменяются приведенным ниже текстом:
(1) Должны трактоваться, как широковещательные пакеты IP все пакеты, направленные по адресу 255.255.255.255 или { <Префикс сети>, -1 }.
На каналах «точка-точка» с маской размером 31 бит, пакеты, направленные по адресу { <Префикс сети>, -1 }, соответствующему одной из конечных точек этого канала, должны трактоваться, как направленные маршрутизатору, на котором установлен этот адрес.
(2) Следует отбрасывать без уведомления (т. е., даже без доставки даже работающим на маршрутизаторе приложениям) все пакеты, направленные по адресу 0.0.0.0 или { <Префикс сети>, 0 }. Если такие пакеты не отбрасываются, они должны трактоваться, как широковещательные пакеты IP (см. параграф 5.3.5). Может использоваться конфигурационная опция, позволяющая принимать такие пакеты. По умолчанию следует устанавливать для этой опции отбрасывание пакетов.
На каналах «точка-точка» с маской размером 31 бит, пакеты, направленные по адресу { <Префикс сети>, 0 }, соответствующему одной из конечных точек этого канала, должны трактоваться, как направленные маршрутизатору, на котором установлен этот адрес.
(4) Не следует генерировать дейтаграммы, направленные по адресу 0.0.0.0 или {<Префикс сети>, 0 }. Может использоваться конфигурационная опция, позволяющая генерировать такие пакеты (вместо использования подходящего формата широковещания). По умолчанию для опции следует использовать значение, не позволяющее генерировать такие пакеты.
На каналах «точка-точка» с маской размером 31 бит в конфигурации следует разрешать генерацию дейтаграмм, направленных по адресу { <Префикс сети>, 0 }.
В параграф 4.3.3.9 добавляется приведенный ниже текст:
Широковещательный адрес 255.255.255.255 должен использоваться для широковещательных откликов Address Mask Reply на каналах «точка-точка» с маской подсети размером 31 бит.
4. Опыт применения
Представленные в этом документе рекомендации были реализованы несколькими производителями маршрутизаторов в бета-версиях программ. Реализации были протестированы по крайней мере тремя ISP с положительными результатами (т. е., без возникновения проблем). Тестирование проводилось с протоколами маршрутизации OSPF, IS-IS, BGP и EIGRP.
Предполагается, что протестированные реализации программ будут официально выпущены в течение нескольких месяцев и другие производители также реализуют рекомендации в своих устройствах.
5. Вопросы развертывания
Целью этого документа является рассмотрение применимости и вопросов использования префиксов /31 на каналах «точка-точка». Влияние таких префиксов (если оно есть) на каналы иных типов не рассматривалось. Отметим, что каналы «точка-точка», в которых только одна из сторон поддерживает префиксы размером 31 бит, могут работать некорректно.
6. Вопросы безопасности
С учетом существования различных типов атак на службы (DoS) в Internet вопросы безопасности требуют серьезного внимания. Использование масок подсетей /31 в магистральных сетях Internet будет сниэать число каналов, подверженных влиянию DoS, основанных на репликации пакетов за счет использования направленного широковещания [RFC2644, SMURF].
В целом реализация приведенных в этом документе рекомендаций будет повышать устойчивость Internet к таким DoS-атакам.
7. Благодарности
Авторы документа не заявляют каких-либо претензий в части оригинальности описанных здесь идей. Наряду с другими людьми, авторы выражают свою признательность Алексу Зинину (Alex Zinin) за полученные от него комментарии и многочисленным участникам тестирования сетей /31 в лабораториях и сетях.
8. Литература
[RFC950] Mogul, J. and J. Postel, “Internet Standard Subnetting Procedure”, STD 5, RFC 950, August 1985.
[RFC1122] Braden, R., “Requirements for Internet Hosts – Communication Layers”, STD 3, RFC 1122, October 1989.
[RFC1332] McGregor, G., “The PPP Internet Protocol Control Protocol (IPCP)”, RFC 1332, May 1992.
[RFC1519] Fuller, V., Li, T., Yu, J. and K. Varadhan, “Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy”, RFC 1519, September 1993.
[RFC1631] Egevang, K. and P. Francis, “The IP Network Address Translator (NAT)”, RFC 1631, May 1994.
[RFC1700] Reynolds, J. and J. Postel, “Assigned Numbers”, STD 2, RFC 17005, October 1994.
[RFC1812] Baker, F., “Requirements for IP Version 4 Routers”, RFC 1812, June 1995.
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, “Internet Registry IP Allocation Guidelines”, BCP 12, RFC 2050, November 1996.
[RFC2460] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460, December 1998.
[RFC2644] Senie, D., “Changing the Default for Directed Broadcasts in Routers”, BCP 34, RFC 2644, August 1999.
[SMURF] Huegen, C., “The Latest in Denial of Service Attacks: ‘Smurfing’: Description and Information to Minimize Effects”, URL: http://users.quadrunner.com/chuegen/smurf.cgi
9. Адреса авторов
Alvaro Retana
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
EMail: aretana@cisco.com
Russ White
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
EMail: riw@cisco.com
Vince Fuller
GTE Internetworking
3801 E. Bayshore Rd.
Palo Alto, CA, 94303
EMail: vaf@valinor.barrnet.net
Danny McPherson
Amber Networks
2465 Augustine Drive
Santa Clara, CA 95054
EMail: danny@ambernetworks.com
Перевод на русский язык
Николай Малых
Полное заявление авторских прав
Copyright (C) The Internet Society (2000). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.
Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Подтверждение
Финансирование функций RFC Editor обеспечено Internet Society.
1Network Address Translator.
2С маской /32. Прим. перев.
3В имеющийся на сайте перевод этого документа внесены соответствующие изменения. Прим. перев.
5В соответствии с RFC 3232 этот документ утратил силу и заменен базой данных, доступной по ссылке www.ietf.org/numbers/. Прим. перев.
