Хотя использование поля TTL IPv4 для области действия является принятой и рекомендуемой практикой, предпочтительнее административное управление областями действия, если оно возможно. При этом диапазон адресов от 239.0.0.0 до 239.255.255.255 определяется как
Административно управляемые адреса многоадресной передачи IPv4 затем делятся на локальную область действия и локальную в пределах организации область действия, первая из которых аналогична (но не является семантическим эквивалентом) области действия IPv6, локальной в пределах сайта. Различные правила определения области действия мы приводим в табл. 21.1.
Таблица 21.1. Область действия адресов многоадресной передачи IPv4 и IPv6
Область действия | Значение поля области действия в IPv6 | Значение поля TTL в IPv4 | Административное управление областью действия в IPv4 |
---|---|---|---|
Локальная в пределах узла | 1 | 0 | |
Локальная в пределах сети | 2 | 1 | от 224.0.0.0 до 224.0.0.255 |
Локальная в пределах сайта | 5 | <32 | от 239.255.0.0 до 239.255.255.255 |
Локальная в пределах организации | 8 | от 239.192.0.0 до 239.195.255.255 | |
Глобальная | 14 | <255 | от 224.0.1.0 до 238.255.255.255 |
Сеансы многоадресной передачи
Сочетание адреса многоадресной передачи IPv4 или IPv6 и порта транспортного уровня часто называется
21.3. Сравнение многоадресной и широковещательной передачи в локальной сети
Вернемся к примерам, представленным на рис. 20.2 и 20.3, чтобы показать, что происходит в случае многоадресной передачи. В примере, показанном на рис. 21.3, мы будем использовать IPv4, хотя для IPv6 последовательность операций будет такой же.
Рис. 21.3. Пример многоадресной передачи дейтаграммы UDP
Принимающее приложение на узле, изображенном справа, запускается и создает сокет UDP, связывает порт 123 с сокетом и затем присоединяется к группе 224.0.1.1. Мы вскоре увидим, что операция «присоединения» выполняется при помощи вызова функции setsockopt
. Когда это происходит, уровень IPv4 сохраняет внутри себя информацию и затем сообщает соответствующему канальному уровню, что нужно получить кадры Ethernet, предназначенные адресу 01:00:5e:00:01:01
(см. раздел 12.11 [128]). Это соответствующий IP-адресу многоадресной передачи адрес Ethernet, к которому приложение только что присоединилось (с учетом сопоставления адресов, показанного на рис. 21.1).
Следующий шаг для отправляющего приложения на узле, изображенном слева, — создание сокета UDP и отправка дейтаграммы на адрес 224.0.1.1, порт 123. Для отправки дейтаграммы многоадресной передачи не требуется никаких специальных действий — приложению не нужно присоединяться к группе. Отправляющий узел преобразует IP-адрес в соответствующий адрес получателя Ethernet, и кадр отправляется. Обратите внимание, что кадр содержит и адрес получателя Ethernet (проверяемый интерфейсами), и IP-адрес получателя (проверяемый уровнями IP).
Мы предполагаем, что узел, изображенный в центре рисунка, не поддерживает многоадресную передачу IPv4 (поскольку поддержка многоадресной передачи IPv4 не обязательна). Узел полностью игнорирует кадр, поскольку, во-первых, адрес получателя Ethernet не совпадает с адресом интерфейса; во-вторых, адрес получателя Ethernet не является широковещательным адресом Ethernet, и в-третьих, интерфейс не получал указания принимать сообщения с адресами многоадресной передачи (то есть адресами, у которых младший бит старшего байта равен 1, как на рис. 21.1).