3.3.4.2 Требования для многодомных хостов
Приведенные здесь правила применяются при выборе IP-адреса отправителя для передачи дейтаграмм многодомными хостами.
Если дейтаграмма передается в ответ на принятую дейтаграмму, адрес отправителя должен совпадать с адресом получателя в принятой дейтаграмме. Более подробное описание требования для вышележащих уровней приведено в параграфах 4.1.3.5 и 4.2.3.7, а также в параграфе «Общие вопросы» работы [RFC1123]. В остальных случаях адрес отправителя можно выбирать.
Приложение должно быть способно явно указывать адрес отправителя при организации соединения или запросе.
При отсутствии такой спецификации сетевые программы должны выбирать адрес отправителя в соответствии с приведенными ниже правилами.
С многодомными хостами связаны два ключевых вопроса:
Хост может отбрасывать без уведомления входящие дейтаграммы, в которых адрес получателя не соответствует физическому интерфейсу, принявшему дейтаграмму.
Хост может ограничить себя передачей дейтаграмм IP (не source-route) только через физический интерфейс, соответствующий IP-адресу отправителя в дейтаграмме.
- Обсуждение:
Разработчики программ для хостов Internet используют две различных по концепции модели многодомных хостов, кратко рассмотренные ниже. В этом документе не отдается преимущества какой-либо модели — обе имеют свои плюсы и минусы.
Различия между этими моделями, рассмотренные в (A) и (B), являются опциональными.
Модель Strong ES
Модель Strong ES придает важное значение различиям между хостами и маршрутизаторами (ES/IS) и применительно к ней следует изменить может на должен в пунктах (A) и (B), рассмотренных выше. В этой модели многодомный хост представляется как множество логических хостов в одном физическом компьютере.
Применительно к (A) сторонники модели Strong ES отмечают, что механизм автоматической маршрутизации Internet не обеспечивает маршрутизации дейтаграмм в физические интерфейсы, которые не соответствуют адресу получателя. В модели Strong ES расчет маршрута для исходящих дейтаграмм представляет собой отображение:
маршрут(IP-адрес отправителя, IP-адрес получателя, TOS) -> шлюз
Адрес отправителя включен как параметр для того, чтобы выбрать шлюз, напрямую доступный через соответствующий физический интерфейс. Отметим, что эта модель логически требует по крайней мере одного принятого по умолчанию шлюза и предпочитает иметь множество таких шлюзов для каждого IP-адреса отправителя.
Модель Weak ES
В этой модели различия между хостами и маршрутизаторами не считаются существенными и следует использовать недопустимо вместо может для приведенных выше пунктов (A) и (B). Эта модель может быть более естественной для хостов, прослушивающих протоколы маршрутизации, и просто необходима для хостов с поддержкой встроенной маршрутизации.
Модель Weak ES может приводить к сбоям в работе механизма Redirect. Если дейтаграмма передана физическому интерфейсу, который не соответствует адресу получателя, первый маршрутизатор не сможет понять, когда ему нужно отправить сообщение Redirect. С другой стороны, хост поддерживающий функции маршрутизации, может получать маршрутную информацию без использования сообщений Redirect.
В модели Weak ES расчет маршрута для исходящих дейтаграмм представляет собой отображение:
маршрут(IP-адрес получателя, TOS) -> шлюз, интерфейс