RFC: 2453
Оригинал: RIP Version 2
Предыдущие версии: RFC 1388, RFC 1723
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Сергей Кедров

RFC 2453, Страница 12 из 25

3.7. Адресация

Маршрутизация с использованием distance vector алгоритма может служить для расчета маршрутов как к сетям, так и к отдельным устройствам (хостам). RIP поддерживает обе возможности. «Назначение» (IP-адрес), содержащийся в сообщении, может указывать сеть, хост или специальный код, используемый для указания маршрута «по умолчанию» — default address. Как правило, в большинстве сетей расчет маршрутов к конкретным хостам не требуется. Однако сети, содержащие линии связи точка-точка могут потребовать от маршрутизаторов высчитывать и хранить маршруты к конкретным хостам. Реализация протокола должна поддерживать использование хостов. В том случае, если использование хостов не поддерживается, информация о них просто игнорируется.

В случае использования RIPv1 протокол не в состоянии отличить различные типы адресов — нет маски. Поле IP-адрес может содержать следующие значения:

  • Нулевой адрес — default route.

    Для default route используется специальный тип адреса — 0.0.0.0. default route используется маршрутизатором в том случае, когда адрес назначения пакета не соответствует ни одному из адресов, содержащихся в таблице маршрутизации. Как правило, default route поднимается на одном из маршрутизаторов вручную. Например это может быть маршрутизатор, через который осуществляется доступ в глобальную сеть. Все остальные маршрутизаторы могут получать информацию о default route с помощью RIP-update’ов. С точки зрения RIP default route ничем не отличается от любого другого сетевого адреса.

  • Адреса сетей или хостов.

    При пересылке информации маршрутизатор будет использовать наиболее точное соответствие между адресом назначения в пакете и полем «адрес» в таблице маршрутизации. Приведем пример. Маршрутизатор должен переслать пакет с адресом назначения 115.168.14.13. Таблица маршрутизации содержит записи с полем адреса, равным 115.168.14.0 и 115.168.0.0. Для передачи пакета будет использоваться запись, содержащая поле адреса, равное 115.168.14.0. Соответственно, если таблица маршрутизации будет содержать адрес хоста 115.168.14.13, то пакет будет отправлен с использованием информации, соответствующей данному хосту.

При получении информации через RIPv1-маршрутизатор может интерпретировать полученные данные в зависимости от того, знает ли он маску подсети, соответствующую полученным сетям. Если знает, то в состоянии правильно интерпретировать полученную информацию.

Например, рассмотрим сеть 128.6, имеющую маску подсети 255.255.255.0. Таким образом, адрес сети 128.6.0.0, адрес подсети 128.6.4.0 и 128.6.4.1 адрес хоста. Однако если получивший информацию маршрутизатор не знает масок, оценка полученных данных может быть некорректной. Например, если полученный адрес не содержит нулевых октетов, то невозможно определить, указывает ли он на хост или на какую-либо подсеть. Поскольку подсеть без маски определить невозможно, в таких ситуациях подразумевается, что получен адрес хоста. Для того, чтобы избежать подобных ситуаций, необходимо учесть, что в среде RIPv1 узлы знают маски только тех подсетей, которые непосредственно к ним подключены. Таким образом, не следует рассылать информацию о подсетях за пределы области, в которой маска для этих подсетей известна. RIPv2 разрешает эту проблему, используя в своих пакетах поле маски.

В среде RIP можно использовать «граничные» — «border» маршрутизаторы. Такие маршрутизаторы одной стороной подключены к сетям, использующим маски подсети. Внутри области, использующей маски подсети, такой маршрутизатор будет рассылать сообщения, содержащие отдельные RTE для каждой подсети. Другой стороной border-маршрутизатор подключен к оставшейся части сети. В эту оставшуюся часть сети border-маршрутизатор будет посылать сообщения, содержащие один общий RTE для всех подсетей, то есть будет подразумеваться использование натуральной маски. В результате — border-маршрутизатор будет посылать на разные интерфейсы разные версии update’ов.

Страница 12 из 25

2007 - 2022 © Русские переводы RFC, IETF, ISOC.