TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Шрифт:
■ Первые 3 октета физического адреса для многоадресной рассылки имеют значение 01-00-5E.
■ Следующий далее бит должен быть установлен в 0, а последние 23 бита должны иметь значение младших 23-х битов IP-адреса многоадресной рассылки.
Такое отображение показано на рис. 5.18:
■ Последние 23 бита IP-адреса многоадресной рассылки отмечены как "х". Эти биты копируются в младшие биты физического адреса многоадресной рассылки.
■ Отмеченные символами "?" позиции IP-адреса многоадресной рассылки могут быть заполнены произвольными битами. Они не
Рис. 5.18. Отображение части IP-адреса на физический адрес
Таким образом, три IP-адреса многоадресной рассылки
11100000 00010001 00010001 00010001
11100000 10010001 00010001 00010001
11100001 10010001 00010001 00010001
будут отображаться на один и тот же физический адрес многоадресной рассылки:
00000001 00000000 01011110 00010001 00010001 00010001
Интерфейсы систем, принадлежащих одной из трех групп, будут реагировать на многоадресные рассылки в своих группах. Однако каждый из хостов на уровне IP будет отбрасывать (игнорировать) посторонние многоадресные рассылки.
Хорошим способом исключения дополнительной обработки является выбор адресов многоадресных рассылок, в которых в позициях "?" стоят нули. При этом все равно остается 2²³ (примерно 9 млн.) адресов для многоадресных рассылок.
5.27.3 Трансляция адресов многоадресных рассылок в адреса Token-Ring
К сожалению, рассмотренную выше схему для Ethernet и FDDI почти никогда нельзя применить в Token-Ring (по крайней мере, на момент написания этой книги), поскольку многие аппаратные интерфейсы Token-Ring не могут быть сконфигурированы на произвольные адреса многоадресных рассылок. Следовательно, остается применить один из трех методов трансляции (в зависимости от оборудования):
■ Вставить 23 бита IP-адреса многоадресных рассылок (этот метод рассмотрен выше)
■ Выбрать и использовать один из функциональных (functional) адресов Token-Ring
■ Применить широковещательную рассылку по всему кольцу Token-Ring
Существует 31 функциональный физический адрес. Они применяются для идентификации систем со специальными свойствами (например, мостов, концентраторов кольцевых подключений или мониторов ошибок в кольце). При выборе второго метода многоадресную рассылку нужно направить по функциональному физическому адресу:
03-00-00-20-00-00
Когда станция получит кадр, содержащий датаграмму многоадресной рассылки, по IP-адресу будет проверено, действительно ли станция является членом группы многоадресной рассылки.
Поскольку один функциональный адрес применяется для всех адресов многоадресных рассылок, такой метод не очень эффективен. Однако он гораздо лучше, чем третий вариант, когда используется широковещательная рассылка по всем станциям.
5.28
Классы адресов определены в стандарте IP RFC 791. Выделение подсетей описывается в RFC 950, а формирование суперсетей — в RFC 1519. Широковещательные рассылки рассмотрены в RFC 919 и RFC 922.
Протокол Address Resolution Protocol специфицирован для Ethernet в RFC 826. Обратные ARP обсуждаются в RFC 903.
RFC 1112 посвящен многоадресным рассылкам в IP. RFC 1390 определяет трансляцию между IP-адресами многоадресных рассылок и адресами FDDI. RFC 1469 специфицирует трансляцию между IP-адресами многоадресных рассылок и адресами Token-Ring.
RFC 1178 содержит как серьезные, так и не совсем серьезные советы по выбору имени для компьютера. RFC 1034 и 1101 подробно обсуждают именование доменов. RFC 1035 описывает протоколы для создания Domain Name System и реализацию этой системы.
Стандарт Hosts Requirements (Требования к хостам), RFC 1122, предоставляет дополнительные сведения об именовании и адресации, равно как и корректирует неточности в некоторых стандартах.
Глава 6
Протокол интернета
6.1 Введение
Вспомним, что интернет — это набор сетей, соединенных маршрутизаторами (во многих ранних документах RFC использовался термин "шлюз" вместо "маршрутизатор"), a IP — это протокол сетевого уровня, обеспечивающий маршрутизацию данных в интернете. При создании IP исследователи и разработчики руководствовались следующими требованиями Министерства обороны США:
■ Приспособить к взаимодействию хосты и маршрутизаторы различных производителей
■ Объединить расширяющееся множество сетей различного типа
■ Обеспечить расширение сети без прерывания работы сетевых служб
■ Реализовать поддержку высокоуровневых сеансов и служб, ориентированных на сообщения
Всем этим требованиям удовлетворяет архитектура сетевого уровня IP.
Более того, она позволяет интегрировать островки локальных сетей (разбросанных по различным организациям) таким образом, чтобы обеспечить подключение новых островков без изменений в уже объединенных.
Все это сделало IP основным сетевым протоколом для правительственных агентств, университетов и коммерческих организаций.
6.2 Датаграммы IP
Протокол IP предоставляет механизм для пересылки по интернету элементов, называемых датаграммами IP (IP datagram). Как показано на рис. 6.1, датаграмма IP формируется из заголовка IP и перемещаемой по сети порции данных.
Рис. 6.1. Формат датаграммы
Протокол IP можно назвать "протоколом наилучшей попытки". Это означает, что IP гарантирует не целостность доставки датаграммы в пункт назначения, а только наилучшую попытку выполнить доставку (см. рис. 6.2). Датаграмма может разрушиться по следующим причинам: