RFC 922 BROADCASTING INTERNET DATAGRAMS IN THE PRESENCE OF SUBNETS

Network Working Group                      Jeffrey Mogul
Request for Comments: 922    Computer Science Department
                                     Stanford University
                                            October 1984

Широковещательная рассылка дейтаграмм IP при наличии подсетей

BROADCASTING INTERNET DATAGRAMS IN THE PRESENCE OF SUBNETS

(PDF)

Статус документа

В этом документе предлагаются простые правила для широковещательной рассылки дейтаграмм Internet в локальных сетях, поддерживающих широковещание, и пересылки широковещательных дейтаграмм через шлюзы.

Этот документ содержит стандарт, предложенный сообществу ARPA-Internet, и служит запросом на обсуждение с целью совершенствования протокола. Документ может распространяться свободно.

Благодарности

Этот документ был создан в результате дискуссий с целой группой специалистов. Особенно отмечу вклад J. Noel Chiappa и Christopher A. Kent.

1. Введение

Использование широковещательной адресации (особенно в скоростных ЛВС) обеспечивает хорошую базу для множества приложений. Поскольку широковещательная адресация не рассматривается в базовой спецификации IP [12], не существует согласованного способа использования широковещательных адресов и разработчики не могут пользоваться такой адресацией (этот вопрос поднимался и ранее – например, в работе [6], но стандарт не был предложен).

В этой работе рассматривается только случай широковещательной рассылки дейтаграмм без гарантии доставки и использования порядковых номеров, а также с возможностью дублирования (вопросы широковещательной рассылки TCP рассматриваются в работе [10].) Широковещательная рассылка дейтаграмм достаточно эффективна [1], несмотря на отсутствие гарантий доставки и ограниченные размеры дейтаграмм.

Мы предполагаем, что канальный уровень локальной сети поддерживает эффективный механизм широковещания (например, Ethernet [7, 5], ChaosNet [9], token ring [2] и т. п.).

Никаких предположений о надежности широковещания не делается (этот вопрос может решаться на уровне протоколов, лежащих над IP). Гарантированная доставка широковещательных пакетов – дорогое удовольствие и взамен просто делается предположение, что хост будет получать большую часть переданных широковещательных пакетов. Важно избежать чрезмерного использования широковещания, поскольку все хосты будут тратить свои ресурсы на обработку каждого широковещательного пакета.

Когда дейтаграмма передается с использованием широковещания, ее обработка отнимает ресурсы каждого хоста, принявшего такую дейтаграмму. Поэтому широковещание следует использовать только в тех случаях, когда оно обеспечивает наилучшее решение задачи.

2. Терминология

Поскольку широковещательная рассылка зависит от используемого в локальной сети протокола канального уровня, этот вопрос следует рассматривать в контексте физических и логических сетей. Термины, которые используются в документе применительно к физической сети, рассматриваются с точки зрения хоста, передающего или пересылающего широковещательные пакеты.

Локальная сеть (Local Hardware Network)

Физическая сеть, к которой подключен хост.

Удаленная физическая сеть (Remote Hardware Network)

Физическая сеть, отделенная от хоста по крайней мере одним маршрутизатором.

Набор физических сетей (Collection of Hardware Networks)

Набор физических сетей, соединенных через маршрутизаторы.

IP включает несколько типов логических сетей. Во избежание путаницы будем использовать следующие термины:

Internet

Набор IP-сетей DARPA Internet.

Сеть IP (IP Network)

Одна или несколько физических сетей, имеющих общий номер IP.

Подсеть (Subnet)

Один из элементов набора физических сетей, составляющих сеть IP. Хосты подсети используют такие же номера сети IP, как и хосты других подсетей данной сети IP, но локальная часть адреса делится на номер подсети и номер хоста. Мы не делаем никаких предположений о делении локальной части адреса, поскольку способ деления может варьироваться в разных сетях.

Введение уровня подсетей в иерархию адресов является отклонением от спецификации IP [12], но, поскольку подсети используются все шире, схема широковещания должна поддерживать подсети. Дополнительную информацию о подсетях вы найдете в работе [8].

В этом документе термин «адрес хоста» относится к связанной с хостом локальной части адреса (номер хоста в подсети — host-on-subnet address) при использовании подсетей или всему локальному адресу (номер хоста в сети — host-part) в остальных случаях.

Сеть IP может состоять из одной или множества физических сетей – с точки зрения хостов других IP-сетей это не имеет значения.

3. Зачем нужно широковещание?

Широковещание полезно в тех случаях, когда хосту нужно найти информацию при отсутствии точных сведений о хосте, который ее обеспечивает, или когда требуется передать информацию большому числу хостов одновременно.

Когда хосту требуется информация, которая может храниться у одного или нескольких соседей, этот хост может использовать список соседей для передачи запросов или просто опрашивать всех соседей, пока не будет получен ответ. Использование списков подключенных к сети хостов порождает множество административных проблем и не обеспечивает достаточной гибкости. С другой стороны, передача запросов всем соседям будет занимать много времени по причине большого числа соседей (например, в сети ARPANET существует около 65 тысяч хостов). Большинство реализаций IP поддерживает списки подключенных к сети хостов (например, адреса первичных шлюзов). К счастью, использование широковещательной рассылки обеспечивает хосту простой и быстрый способ связи со всеми соседями.

Хост может использовать широковещательную рассылку также для передачи той или иной информации всем своим соседям (например, шлюз может анонсировать присутствие другого маршрутизатора).

Широковещание можно рассматривать как частный случай групповой адресации (multicasting). На практике широковещательную рассылку часто используют взамен групповой адресации, передавая широковещательные пакеты на аппаратном уровне и используя фильтрацию этих пакетов на принимающих хостах (пакет принимают только те хосты, которым он нужен).

Более подробное рассмотрение широковещательных приложений приводится в работах [1, 3].

4. Классы широковещания

Существует несколько классов широковещания IP:

  • Широковещательная рассылка дейтаграмм с конкретным адресом получателя через локальную сеть IP — дейтаграммы направлены конкретному адресату, но передающий хост использует широковещание на канальном уровне (возможно, для того, чтобы избежать маршрутизации). Поскольку такое широковещание не относится к IP, уровень IP не участвует в широковещательной рассылке (за исключением того, что он обеспечивает отбрасывание дейтаграмм без уведомления).
  • Широковещательная рассылка всем хостам локальной сети IP — в качестве номера хоста используется специальное значение1. Принимающий уровень IP должен распознавать такой адрес, как свой собственный.
    Однако, на вышележащих уровнях может быть полезно различие между широковещательными и обычными дейтаграммами (особенно на маршрутизаторах). Этот вариант широковещания наиболее полезен – он позволяет хостам детектировать шлюзы (маршрутизаторы) без использования протоколов преобразования адресов, а также обеспечивает возможность работы с серверами имен, серверами времени и другими службами без использования явного адреса.
  • Широковещательная рассылка всем хостам удаленной сети IP — в некоторых случаях такая рассылка может оказаться полезной (например, для поиска последней версии базы данных с именами хостов, удаленной загрузки или мониторинга сетевой службы точного времени). Этот случай совпадает с широковещательной рассылкой в локальной сети – дейтаграмма передается обычным путем, пока она не попадет на маршрутизатор, подключенный к сети-адресату, который и организует широковещательную рассылку в своей локальной сети. Этот класс называется направленным широковещанием (directed broadcasting) или letter bomb [1].
  • Широковещательная рассылка всем хостам сети IP, разделенной на подсети (мультисегментное широковещание — Multisubnet broadcasts) — для обозначения всех подсетей (all subnets) используется специальный адрес IP2. Широковещательная рассылка всем хостам удаленной сети IP, разбитой на подсети, осуществляется с использованием направленного широковещания для отдельных подсетей.
  • Широковещательная рассылка в масштабе Internet: такая рассылка вряд ли полезна и, во всяком случае, нежелательна.

По соображениям безопасности и производительности (загрузки каналов) маршрутизаторы могут не пересылать широковещательные дейтаграммы; в частности хорошей идеей является запрет на пересылку широковещательных дейтаграмм в автономную группу сетей или за пределы такой группы.

5. Методы широковещания

На принимающем хосте требуется модернизация уровня IP для поддержки широковещания. В отсутствие широковещания хост проверяет принадлежность дейтаграммы путем сравнения адреса получателя в ней со своими адресами IP. При использовании широковещания хост должен сравнивать адрес получателя не только со своими адресами, но и с возможными широковещательными адресами подсетей, к которым этот хост относится.

Вопросы оптимизации широковещательной рассылки подробно рассмотрены в работах [1, 3, 4, 13, 14]. Поскольку мы предполагаем, что эта проблема уже решена на канальном уровне, хост IP, желающий передать широковещательную дейтаграмму в локальную или удаленную сеть (directed broadcast), должен лишь указать подходящий адрес получателя и передать дейтаграмму обычным путем. Изощренные алгоритмы обработки широковещания требуются только шлюзам.

Задача широковещательной рассылки всем хостам при использовании подсетей является более сложной. Однако, даже в таких случаях существуют алгоритмы, не требующие каких-либо дополнительных возможностей от хостов, не являющихся шлюзами. Эффективный метод широковещания при использовании подсетей должен соответствовать следующим дополнительным критериям:

  • Формат дейтаграмм IP не должен изменяться.
  • Должна обеспечиваться разумная эффективность с учетом числа избыточных копий и стоимости выбора пути.
  • Минимальные изменения для шлюзов (как для кода, так и для пространства данных).
  • Высокая вероятность доставки дейтаграмм.

Лучшим вариантом представляется метод RPF (Reverse Path Forwarding – рассылка по обратному пути) [4]. Хотя алгоритм RPF не совсем оптимален с точки зрения стоимости и надежности доставки, он достаточно хорош и очень прост в реализации, а также не требует дополнительного пространства данных на шлюзах.

6. Шлюзы и рассылка широковещательных дейтаграмм

Основная сложность поддержки широковещания ложится на шлюзы. Если шлюз получает directed broadcast для сети, к которой он не подключен непосредственно, такая дейтаграмма просто пересылается с использованием обычных механизмов. Если же широковещательная дейтаграмма адресована в одну из подключенных к маршрутизатору сетей, требуется выполнение дополнительных операций.

6.1. Локальное широковещание

Когда шлюз получает локальную широковещательную дейтаграмму, возможно несколько вариантов. Ситуация однозначна, но без некоторых мер предосторожности могут возникать бесконечные петли. Выполняемое при получении широковещательной дейтаграммы действие зависит от нескольких обстоятельств – подсети, из которой дейтаграмма получена, подсети получателя и адреса шлюза.

  • Основным правилом предотвращения петель является следующее: «никогда не пересылать дейтаграмму в широковещательном режиме в физическую сеть, из которой она была принята». Достаточно сложно избежать повтора дейтаграмм, которые шлюз принял от себя. Это правило позволяет избавиться от повтора дейтаграмм, которые шлюз принял от самого себя; сохраняется возможность возникновения петель при наличии нескольких шлюзов в одной физической сети.
  • Если дейтаграмма получена из физической сети, в которую она адресована, такую дейтаграмму не следует пересылать. Однако, шлюзу следует рассматривать себя как получателя таких дейтаграмм (например, они могут использоваться при рассылке маршрутных обновлений).
  • В остальных случаях, если дейтаграмма адресована в физическую сеть, к которой подключен шлюз, она должна быть передана в эту сеть с использованием широковещательной адресации на канальном уровне. Шлюз в этом случае также должен рассматривать себя, как получателя дейтаграммы.
  • В противном случае шлюз должен использовать обычную процедуру маршрутизации для выбора следующего шлюза и передать дейтаграмму выбранному маршрутизатору.

6.2. Широковещание во множество подсетей

Когда шлюз получает широковещательную дейтаграмму, предназначенную для всех подсетей IP, он должен использовать алгоритм RPF для принятия решения. Этот метод прост – шлюзу следует переслать копии дейтаграммы через все подключенные к нему каналы тогда и только тогда, когда дейтаграмма принята из канала, который является частью лучшего пути между шлюзом и отправителем дейтаграммы. В остальных случаях дейтаграммы должны отбрасываться.

Этот алгоритм можно усовершенствовать, если маршрутизаторы (все или часть) будут обмениваться между собой дополнительной информацией (этот обмен можно сделать совершенно прозрачным с точки зрения хостов и даже других шлюзов). Дополнительную информацию о таком усовершенствовании можно найти в работах [4, 3].

6.3. Псевдо-код алгоритма маршрутизации

На рисунке 1 показан псевдо-код алгоритма, который следует использовать шлюзам. Ниже приведены определения использованных при описании алгоритма терминов.

RouteLink(хост)

Функция, принимающая адрес хоста в качестве параметра и возвращающая канал для первого интервала пути от шлюза к хосту.

RouteHost(хост)

Эта функция аналогична предыдущей, но возвращает адрес хоста на первом интервале.

ResolveAddress(хост)

Эта функция возвращает аппаратный адрес хоста по адресу IP.

IncomingLink

Канал, на который прибывает пакет.

OutgoingLinkSet

Набор каналов, в которые пакет должен следует передать.

OutgoingHardwareHost

Аппаратный адрес хоста, которому передается пакет.

Destination.host

Связанная с хостом часть адреса получателя (номер хоста).

Destination.subnet

Номер подсети в адресе получателя.

Destination.ipnet

Номер сети IP в адресе получателя.

BEGIN
   IF Destination.ipnet IN AllLinks THEN
   BEGIN
      IF IsSubnetted(Destination.ipnet) THEN
      BEGIN
         IF Destination.subnet = BroadcastSubnet THEN
         BEGIN /* используется алгоритм RPF */
            IF IncomingLink = RouteLink(Source) THEN
            BEGIN IF Destination.host = BroadcastHost THEN
               OutgoingLinkSet <- AllLinks -
               IncomingLink;
               OutgoingHost <- BroadcastHost;
               Проверка возможности внутреннего использования пакета;
            END
            ELSE /* отбрасывание дубликатов от других шлюзов */
               Discard;
         END
         ELSE
            IF Destination.subnet = IncomingLink.subnet THEN
            BEGIN /* пересылка будет порождать петлю */
               IF Destination.host = BroadcastHost THEN
                  Проверка возможности внутреннего использования пакета;
               Discard;
            END
            ELSE BEGIN /* пересылка в (возможно локальную) подсеть */
               OutgoingLinkSet <- RouteLink(Destination);
               OutgoingHost <- RouteHost(Destination);
            END
         END
         ELSE BEGIN /* пакет адресован в одну из локальных сетей */
            IF Destination.ipnet = IncomingLink.ipnet THEN
               BEGIN /* пересылка будет порождать петлю */
                  IF Destination.host = BroadcastHost THEN
                     Проверка возможности внутреннего использования пакета;
                  Discard;
               END
               ELSE BEGIN /* может быть широковещательным */
                  OutgoingLinkSet <- RouteLink(Destination);
                  OutgoingHost <- RouteHost(Destination);
               END
            END
         END
         ELSE BEGIN /* пересылка в удаленную сеть IP */
            OutgoingLinkSet <- RouteLink(Destination);
            OutgoingHost <- RouteHost(Destination);
         END
         OutgoingHardwareHost <- ResolveAddress(OutgoingHost);
      END

Рисунок 1: Код Pseudo-Algol для алгоритма маршрутизации широковещательных дейтаграмм.

7. Соглашение о широковещательных адресах IP

Для совместимости реализаций IP они должны поддерживать специальный номер для обозначения всех хостов сети (all hosts) и всех подсетей (all subnets).

Поскольку сетевой уровень локальной сети всегда отображает адреса IP на адреса канального уровня, выбор «широковещательного номера хоста» IP является в какой-то степени произвольным. Для простоты этот номер не должен совпадать ни с одним из реальных номеров хостов. Номер, содержащий только «1», удовлетворяет этому требованию; использование таких номеров для широковещания было впервые предложено в работе [6]. Такие номера достаточно редко применяются для реальных хостов, поэтому использование этого номера для широковещательной рассылки, скорей всего, не потребует каких-либо изменений в конфигурации сети.

Номер «все подсети» (all subnets) также содержит только 1 – это означает, что хост, желающий передать дейтаграмму всем хостам удаленной сети IP может ничего не знать о подсетях удаленной сети. Например, 36.255.255.255 может указывать на все хосты одной физической сети или все хосты разделенной на подсети IP-сети (например, 1 байт содержит поле подсети, а 2 байта – номер хоста; возможно и любое другое разделение на подсети).

Адрес 255.255.255.255 является широковещательным для локальной сети и дейтаграммы с таким адресом недопустимо пересылать в другие сети. Такой адрес может использоваться, например, хостами, которым не известен номер их сети, когда они пытаются получить этот номер от сервера.

Таким образом, хост сети с номером 36 (например) может:

  • рассылать дейтаграммы своим непосредственным соседям по локальной сети, используя адрес 255.255.255.255;
  • рассылать широковещательные дейтаграммы по всей сети 36, используя адрес 36.255.255.255,

не имея сведений о подсетях (если подсети не используются, оба способа адресации дают одинаковый эффект). Отказоустойчивые приложения могут пытаться использовать первый адрес и при отсутствии отклика повторить попытку через некоторое время. В работе [1] подробно рассмотрен метод «поиска по расширяющемуся кругу».

Если «все единицы» в поле адреса IP используются для широковещания, значение «все нули» можно использовать для неуказанного адреса. Возможно это является причиной появления таких значений в поле отправителя дейтаграмм ICMP Information Request. Однако в соответствии с соглашением о нотации такие адреса (все нули) используются для обозначения сетей3. Например, 36.0.0.0 означает «сеть номер 36″, а 36.255.255.255 – широковещательный адрес «все хосты сети 36».

7.1. Широковещательные адреса и серверы ARP

Протокол преобразования адресов ARP, описанный в [11], может при некорректной реализации порождать проблемы, связанные с использованием широковещания в сетях, где не все хосты понимают, какой адрес является широковещательным. Возникает искушение изменить сервер ARP так, чтобы он мог обеспечивать отображение широковещательных адресов IP в широковещательные аппаратные адреса. Этому искушению не следует поддаваться. Серверу ARP никогда не следует давать отклики на запросы, в которых получатель задан широковещательным адресом. Такие запросы могут исходить только от хостов, которые не распознают этот адрес в качестве широковещательного (это легко приводит к возникновению петель в пересылке). Если имеется N таких хостов в физической сети, тогда дейтаграмма, переданная со значением TTL = T, может привести к генерации TN повторных широковещательных дейтаграмм.

8. Литература

  1. David Reeves Boggs. Internet Broadcasting. Ph.D. Th., Stanford University, January 1982.

  2. D.D. Clark, K.T. Pogran, and D.P. Reed. «An Introduction to Local Area Networks». Proc. IEEE 66, 11, pp1497-1516, November 1978.
  3. Yogan Kantilal Dalal. Broadcast Protocols in Packet Switched Computer Networks. Ph.D. Th., Stanford University, April 1977.
  4. Yogan K. Dalal and Robert M. Metcalfe. «Reverse Path Forwarding of Broadcast Packets». Comm. ACM 21, 12, pp1040-1048, December 1978.
  5. The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specifications. Version 1.04, Digital Equipment Corporation, Intel, Xerox, September 1980.
  6. Robert Gurwitz and Robert Hinden. IP — Local Area Network Addressing Issues. IEN-2125, BBN, September 1982.
  7. R.M. Metcalfe and D.R. Boggs. «Ethernet: Distributed Packet Switching for Local Computer Networks»6. Comm. ACM 19, 7, pp395-404, July 1976. Also CSL-75-7, Xerox Palo Alto Research Center, reprinted in CSL-80-2.
  8. Jeffrey Mogul. Internet Subnets. RFC 9177, Stanford University, October 1984.
  9. David A. Moon. Chaosnet. A.I. Memo 628, Massachusetts Institute of Technology Artificial Intelligence Laboratory, June 1981.
  10. William W. Plummer. Internet Broadcast Protocols. IEN-108, BBN, March 1977.
  11. David Plummer. An Ethernet Address Resolution Protocol. RFC 826, Symbolics, September 1982.
  12. Jon Postel. Internet Protocol. RFC 791, ISI, September 1981.
  13. David W. Wall. Mechanisms for Broadcast and Selective Broadcast. Ph.D. Th., Stanford University, June 1980.
  14. David W. Wall and Susan S. Owicki. Center-based Broadcasting. Computer Systems Lab Technical Report TR189, Stanford University, June 1980.


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1Все биты номера хоста имеют значение 1. Прим. прев.

2Все биты номера подсети имеют значение 1. Прим. прев.

3Нулевые значения имеют биты номера хоста. Прим. перев.

4Версия 2.0 этой спецификации доступна по ссылке http://vt100.net/mirror/antonio/aa-k759b-tk.pdf. Прим. перев.

5Копия этого документа доступна по ссылке http:www.postel.org/ien/pdf/ien212.pdf. Прим. перев.

6Эта статья доступна на сайте http://portal.acm.org/ft_gateway.cfm?id=358015&type=pdf&coll=GUIDE&dl=ACM&CFID=53904378&CFTOKEN=8167. Прим. перев.

7Перевод этого документа имеется на сайте www.protocols.ru. Прим. перев.

8Копия этого документа доступна по ссылке http://www.isi.edu/in-notes/ien/ien10.txt. Прим. перев.




RFC 919 BROADCASTING INTERNET DATAGRAMS

Network Working Group                                  Jeffrey Mogul
Request for Comments: 919                Computer Science Department
                                                 Stanford University
                                                        October 1984

Широковещательная рассылка дейтаграмм IP

BROADCASTING INTERNET DATAGRAMS

(PDF)

Статус документа

В этом документе предлагаются простые правила для широковещательной рассылки дейтаграмм Internet в локальных сетях, поддерживающих широковещание, и пересылки широковещательных дейтаграмм через шлюзы.

Этот документ содержит стандарт, предложенный сообществу ARPA-Internet, и служит запросом дальнейшего обсуждения с целью совершенствования протокола. Документ может распространяться свободно.

Благодарности

Этот документ был создан в результате дискуссий с целой группой специалистов. Особенно отмечу вклад J. Noel Chiappa и Christopher A. Kent.

1. Введение

Использование широковещательной адресации (особенно в скоростных ЛВС) обеспечивает хорошую базу для множества приложений. Поскольку широковещательная адресация не рассматривается в базовой спецификации IP [13], не существует согласованного способа использования широковещательных адресов и разработчики не могут пользоваться такой адресацией (этот вопрос поднимался и ранее — например, в работе [6], но стандарт не был предложен).

В этой работе рассматривается только случай широковещательной рассылки дейтаграмм без гарантии доставки и использования порядковых номеров, а также с возможностью дублирования (вопросы широковещательной рассылки TCP рассматриваются в работе [11].) Широковещательная рассылка дейтаграмм достаточно эффективна [1], несмотря на отсутствие гарантий доставки и ограниченные размеры дейтаграмм.

Мы предполагаем, что канальный уровень локальной сети поддерживает эффективный механизм широковещания (например, Ethernet [7, 5], ChaosNet [10], token ring [2] и т. п.).

Никаких предположений о надежности широковещания не делается (этот вопрос может решаться на уровне протоколов, лежащих над IP). Гарантированная доставка широковещательных пакетов — дорогое удовольствие и взамен просто делается предположение, что хост будет получать большую часть переданных широковещательных пакетов. Важно избежать чрезмерного использования широковещания, поскольку каждый хост будет тратить свои ресурсы на обработку каждого такого пакета.

Когда дейтаграмма передается с использованием широковещания, ее обработка отнимает ресурсы каждого хоста, принявшего такую дейтаграмму. Поэтому широковещание следует использовать только в тех случаях, когда оно обеспечивает наилучшее решение задачи.

Отметим, что некоторые организации делят свою сеть IP на подсети, в соответствии с предложенным стандартом [8]. Данный документ не рассматривает вопросы широковещательной рассылки в среде с подсетями (эта тема рассматривается в работе [9]).

2. Терминология

Поскольку широковещательная рассылка зависит от используемого в локальной сети протокола канального уровня, этот вопрос следует рассматривать в контексте физических и логических сетей. Термины, которые используются в документе применительно к физической сети, рассматриваются с точки зрения хоста, передающего или пересылающего широковещательные пакеты.

Локальная сеть (Local Hardware Network)

Физическая сеть, к которой подключен хост.

Удаленная физическая сеть (Remote Hardware Network)

Физическая сеть, отделенная от хоста по крайней мере одним маршрутизатором.

Набор удаленных сетей (Collection of Hardware Networks)

Набор физических сетей, соединенных через маршрутизаторы.

IP включает несколько типов логических сетей. Во избежание путаницы будем использовать следующие термины:

Internet

Набор IP-сетей DARPA Internet.

Сеть IP (IP Network)

Одна или несколько физических сетей, имеющих общий номер IP.

3. Зачем нужно широковещание?

Широковещание полезно в тех случаях, когда хосту нужно найти информацию при отсутствии точных сведений о хосте, который ее обеспечивает, или когда требуется передать информацию большому числу хостов одновременно.

Когда хосту требуется информация, которая может храниться у одного или нескольких соседей, этот хост может использовать список соседей для передачи запросов или просто опрашивать всех соседей, пока не будет получен ответ. Использование списков подключенных к сети хостов порождает множество административных проблем и не обеспечивает достаточной гибкости. С другой стороны, передача запросов всем соседям будет занимать много времени по причине большого числа соседей (например, в сети ARPANET существует около 65 тысяч хостов). Большинство реализаций IP поддерживает списки подключенных к сети хостов (например, адреса Prime-шлюзов). К счастью, использование широковещательной рассылки обеспечивает хосту простой и быстрый способ связи со всеми соседями.

Хост может использовать широковещательную рассылку также для передачи той или иной информации всем своим соседям (например, шлюз может анонсировать присутствие другого маршрутизатора).

Широковещание можно рассматривать как частный случай групповой адресации (multicasting). На практике широковещательную рассылку часто используют взамен групповой адресации, передавая широковещательные пакеты на аппаратном уровне и используя фильтрацию этих пакетов на принимающих хостах (пакет принимают только те хосты, которым он нужен).

Более подробное рассмотрение широковещательных приложений приводится в работах [1, 3].

4. Классы широковещания

Существует несколько классов широковещания IP:

  • Широковещательная рассылка дейтаграмм с конкретным адресом получателя через локальную сеть IP: дейтаграммы направлены конкретному адресату, но передающий хост использует широковещание на канальном уровне (возможно, для того, чтобы избежать маршрутизации). Поскольку такое широковещание не относится к IP, уровень IP не участвует в широковещательной рассылке (за исключением того, что он обеспечивает отбрасывание дейтаграмм без уведомления).
  • Широковещательная рассылка всем хостам локальной сети IP: в качестве номера хоста используется специальное значение1. Принимающий уровень IP должен распознавать такой адрес, как свой собственный.
    Однако, на вышележащих уровнях может быть полезно различие между широковещательными и обычными дейтаграммами (особенно на маршрутизаторах). Этот вариант широковещания наиболее полезен — он позволяет хостам детектировать шлюзы (маршрутизаторы) без использования протоколов преобразования адресов, а также обеспечивает возможность работы с серверами имен, серверами времени и др. службами без использования явного адреса.
  • Широковещательная рассылка всем хостам удаленной сети IP: в некоторых случаях такая рассылка может оказаться полезной (например, для поиска последней версии базы данных с именами хостов, удаленной загрузки или мониторинга сетевой службы точного времени). Этот случай совпадает с широковещательной рассылкой в локальной сети — дейтаграмма передается обычным путем, пока она не попадет на маршрутизатор, подключенный к сети-адресату, который и организует широковещательную рассылку в своей локальной сети. Этот класс называется направленным широковещанием (directed broadcasting) или letter bomb [1].
  • Широковещательная рассылка в масштабе Internet: такая рассылка вряд ли полезна и, во всяком случае, нежелательна.

По соображениям безопасности и производительности (загрузки каналов) маршрутизаторы могут не пересылать широковещательные дейтаграммы за пределы сети или автономной группы сетей.

5. Методы широковещания

На принимающем хосте требуется модернизация IP-уровня для поддержки широковещания. В отсутствие широковещания хост проверяет принадлежность дейтаграммы путем сравнения адреса получателя в ней со своими адресами IP. При использовании широковещания хост должен сравнивать адрес получателя не только со своими адресами, но и с возможными широковещательными адресами подсетей, к которым этот хост относится.

Вопросы оптимизации широковещательной рассылки подробно рассмотрены в работах [1, 3, 4, 14, 15]. Поскольку мы предполагаем, что эта проблема уже решена на канальном уровне, хост IP желающий передать широковещательную дейтаграмму в локальную или удаленную сеть (directed broadcast), должен лишь указать подходящий адрес получателя и передать дейтаграмму обычным путем. Изощренные алгоритмы обработки широковещания требуются только шлюзам.

6. Шлюзы и рассылка широковещательных дейтаграмм

Основная сложность поддержки широковещания ложится на шлюзы. Если шлюз получает directed broadcast для сети, к которой он не подключен непосредственно, такая дейтаграмма просто пересылается с использованием обычных механизмов. Если же широковещательная дейтаграмма адресована в одну из подключенных к маршрутизатору сетей, ситуация несколько меняется.

Когда шлюз получает локальную широковещательную дейтаграмму, возможно несколько вариантов. Ситуация однозначна, но без некоторых мер предосторожности могут возникать бесконечные петли. Выполняемое при получении широковещательной дейтаграммы действие зависит от нескольких параметров — подсети, из которой дейтаграмма получена, подсети получателя и адреса шлюза.

  • Основным правилом предотвращения петель является следующее: «никогда не пересылать дейтаграмму в широковещательном режиме в физическую сеть, из которой она была принята». Это правило позволяет избавиться от повтора дейтаграмм, которые шлюз принял от самого себя. Однако, этого недостаточно, чтобы предотвратить петли при наличии нескольких шлюзов в одной физической сети.
  • Если дейтаграмма получена из физической сети, в которую она адресована, такую дейтаграмму не следует пересылать. Однако, шлюзу следует рассматривать себя, как получателя таких дейтаграмм (например, при рассылке маршрутных обновлений).
  • В остальных случаях, если дейтаграмма адресована в физическую сеть, к которой подключен шлюз, она должна быть передана в эту сеть с использованием широковещательной адресации на канальном уровне. Шлюз в этом случае должен рассматривать себя, как получателя дейтаграммы.
  • В противном случае шлюз должен использовать обычную процедуру маршрутизации для выбора следующего шлюза и передать дейтаграмму выбранному маршрутизатору.

7. Широковещательная адресация IP – предложенные стандарты

Для совместимости реализаций IP они должны поддерживать специальный номер для обозначения всех хостов сети (all hosts).

Поскольку сетевой уровень локальной сети всегда отображает адреса IP на адреса канального уровня, выбор широковещательного номера IP (broadcast host number) является в какой-то степени произвольным. Для простоты этот номер не должен совпадать ни с одним из реальных номеров хостов. Номер, содержащий только 1, удовлетворяет этому требованию; использование таких номеров для широковещания было впервые предложено в работе [6]. Такие номера достаточно редко используются для реальных хостов, поэтому применение этого номера для широковещательной рассылки скорей всего не потребует каких-либо изменений в конфигурации сети.

Адрес 255.255.255.255 является широковещательным для локальной сети и дейтаграммы с таким адресом не должны пересылаться в другие сети. Такой адрес может использоваться, например, хостами, которым не известен номер их сети, когда они пытаются получить этот номер от сервера.

Таким образом, хост сети с номером 36 (например) может:

  • рассылать дейтаграммы своим непосредственным соседям по локальной сети, используя адрес 255.255.255.255;
  • рассылать широковещательные дейтаграммы по всей сети 36, используя адрес 36.255.255.2552.

Если «все единицы» в поле адреса IP используются для широковещания, значение «все нули» можно использовать для неуказанного адреса (unspecified). Возможно это является причиной появления таких значений в поле отправителя дейтаграмм ICMPInformationRequest. Однако в соответствии с соглашением о нотации такие адреса (все нули) используются для обозначения сетей3. Например, 36.0.0.0 означает «сеть номер 36», а 36.255.255.255 — широковещательный адрес «все хосты сети 36».

7.1. Широковещательные адреса и серверы ARP

Протокол преобразования адресов ARP, описанный в [12], может при некорректной реализации порождать проблемы, связанные с использованием широковещания в сетях, где не все хосты понимают, какой адрес является широковещательным. Возникает искушение изменить сервер ARP так, чтобы он мог обеспечивать отображение широковещательных адресов IP в широковещательные аппаратные адреса. Этому искушению не следует поддаваться. Серверу ARP никогда не следует давать отклики на запросы, в которых получатель задан широковещательным адресом. Такие запросы могут исходить только от хостов, которые не распознают этот адрес в качестве широковещательного (это легко приводит к возникновению петель в пересылке). Если имеется N таких хостов в физической сети, тогда дейтаграмма, переданная со значением TTL = T, может привести к генерации TN повторных широковещательных дейтаграмм.

8. Литература

  1. David Reeves Boggs. Internet Broadcasting. Ph.D. Th., Stanford University, January 1982.
  2. D.D. Clark, K.T. Pogran, and D.P. Reed. «An Introduction to Local Area Networks». Proc. IEEE 66, 11, pp1497-1516, 1978.
  3. Yogan Kantilal Dalal. Broadcast Protocols in Packet Switched Computer Networks. Ph.D. Th., Stanford University, April 1977.
  4. Yogan K. Dalal and Robert M. Metcalfe. «Reverse Path Forwarding of Broadcast Packets». Comm. ACM 21, 12, pp1040-1048, December 1978.
  5. The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specifications. Version 1.0, Digital Equipment Corporation, Intel, Xerox, September 1980.
  6. Robert Gurwitz and Robert Hinden. IP — Local Area Network Addressing Issues. IEN-212, Bolt Beranek and Newman, September 1982.
  7. R.M. Metcalfe and D.R. Boggs. «Ethernet: Distributed Packet Switching for Local Computer Networks»4. Comm. ACM 19, 7, pp395-404, July 1976. Also CSL-75-7, Xerox Palo Alto Research Center, reprinted in CSL-80-2.
  8. Jeffrey Mogul. Internet Subnets. RFC-917, Stanford University, October 1984.
  9. Jeffrey Mogul. Broadcasting Internet Packets in the Presence of Subnets. RFC 922, Stanford University, October 1984.
  10. David A. Moon. Chaosnet. A.I. Memo 628, Massachusetts Institute of Technology Artificial Intelligence Laboratory, June 1981.
  11. William W. Plummer. Internet Broadcast Protocols. IEN-10, Bolt Beranek and Newman, March 1977.
  12. David Plummer. An Ethernet Address Resolution Protocol6. RFC 826, Symbolics, September 1982.
  13. Jon Postel. Internet Protocol. RFC 791, ISI, September 1981.
  14. David W. Wall. Mechanisms for Broadcast and Selective Broadcast. Ph.D. Th., Stanford University, June 1980.
  15. David W. Wall and Susan S. Owicki. Center-based Broadcasting. Computer Systems Lab Technical Report TR189, Stanford University, June 1980.

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1 Все биты номера хоста имеют значение 1. Прим. перев.

2Если сеть 36 не разбита на подсети, эти способы адресации эквивалентны.

3Нулевые значения имеют биты номера хоста. Прим. перев.

4Эта статья доступна на сайте http://portal.acm.org/ft_gateway.cfm?id=358015&type=pdf&coll=GUIDE&dl=ACM&CFID=53904378&CFTOKEN=8167 Прим. перев.

6Этот документ обновлен RFC 5227 и RFC 5494. Прим. перев.




RFC 917 INTERNET SUBNETS

Network Working Group                                  Jeffrey Mogul
Request for Comments: 917                Computer Science Department
                                                 Stanford University
                                                        October 1984

Подсети Internet

INTERNET SUBNETS

(PDF)

Статус документа

В этом RFC описан протокол, предложенный сообществу ARPA-Internet, и содержится приглашение к дискуссии и совершенствованию протокола. Документ может распространяться без ограничений.

Обзор

Мы обсуждаем парадигму «подсетей» (subnet) в сетях Internet1, представляющих собой видимые подмножества единой сети IP. По административным и техническим причинам многие организации делят свою сеть IP на несколько подсетей вместо приобретения дополнительных блоков адресов IP.

Мы предлагаем процедуры для использования подсетей и обсуждаем варианты решения возникающих проблем (в частности, маршрутизации).

Благодарности

Эти предложения являются результатом обсуждения с некоторыми людьми. В частности, J. Noel Chiappa, Chris Kent, и Tim Mann внесли важные предложения.

1. Введение

Исходное представление сети Internet включало два уровня иерархии — верхний уровень представлял сеть catenet в целом, и нижний — множество сетей IP, каждая из которых имеет свой номер (мы не предполагаем в Internet иерархической топологии, но интерпретация адресов является иерархической).

Хотя такое представление обеспечивает простоту и мощь, многие организации считают его неадекватным и добавляют третий уровень в иерархическую схему интерпретации адресов IP. В этом случае сеть IP может быть поделена на некоторое количество подсетей.

Исходное, двухуровневое представление основано на строгом допущении о том, что для хоста в сети IP эта сеть может представляться, как единое целое; иными словами, сеть можно трактовать, как «черный ящик», к которому подключены хосты. Это верно для ARPANET, поскольку IMP маскируют использование конкретных каналов в сети. Это верно также для большинства технологий ЛВС типа Ethernet или сетей с кольцевой топологией.

Однако это допущение неверно для многих практических случаев, поскольку организациям средних размеров (например, университетам или компаниям, расположенным в нескольких зданиях) зачастую приходится использовать более одной ЛВС2 для покрытия «локальной области». Например, на момент подготовки этого документа в сети Стэнфордского университета использовалось 18 ЛВС и планировалось увеличение их числа.

Существует несколько причин, по которым организации могут использовать несколько ЛВС для покрытия территории:

  • Различные топологии – зачастую (особенно в исследовательских организациях) в сети могут присутствовать ЛВС различных типов (например, Ethernet и сети с кольцевой топологией).
  • Технологические ограничения – большинству топологий ЛВС присущи те или иные ограничения (электрические параметры, число хостов в ЛВС, общая протяженность кабеля). Использование подсетей позволяет достаточно просто преодолеть эти ограничения (особенно ограничение протяженности кабеля).
  • Насыщение сети – в локальных сетях могут возникать ситуации, когда небольшая группа хостов фактически монополизирует полосу пропускания сетевой среды. Общим решением таких проблем является сегментирование сети (разбиение на несколько фрагментов) с организацией раздельных кабельных систем.
  • Использование каналов «точка-точка» — иногда «локальная сеть» (например, кампусная сеть университета) разделена на несколько фрагментов (например, ЛВС отдельных зданий), соединенных между собой скоростными каналами «точка-точка».

Организации, имеющие более одной ЛВС, могут выбрать один из трех вариантов распределения адресов IP:

  1. Получить отдельный блок адресов для каждой ЛВС.
  2. Использовать для всей организации общий номер сети и распределять адреса независимо от принадлежности хостов к ЛВС. Такой вариант получил название transparent subnets (прозрачные подсети).
  3. Используя один номер сети, разделить адресное пространство на несколько подсетей в соответствии с имеющимися ЛВС. Такой вариант называется explicit subnets (явные подсети).

Каждый из вариантов имеет свои преимущества и недостатки. Первый вариант не требует добавления или изменения протоколов, но ведет к разрастанию таблиц маршрутизации Internet. Информация о внутренней структуре сети распространяется повсюду, хотя она мало кому нужна и в большинстве случаев не используется за пределами организации. В некоторых реализациях шлюзов может возникать проблема нехватки пространства в таблице маршрутов, поэтому такой вариант лучше не использовать3.

Второй вариант требует использования неких соглашений или протоколов, позволяющих объединить множество ЛВС в одну сеть IP. Например, этот вариант можно реализовать в ЛВС, где каждый адрес IP транслируется в аппаратный адрес с использованием протокола ARP4, имея мосты между ЛВС, которые будут перехватывать запросы ARP для нелокальных адресатов. Однако такое решение возможно не для всех технологий ЛВС, особенно в тех случаях, когда технология не использует протокол ARP или ЛВС не поддерживает широковещания. Более фундаментальная проблема заключается в том, что мосты должны узнавать к какой ЛВС принадлежит хост, возможно используя для этого широковещательные рассылки. По мере увеличения числа ЛВС расходы на поддержку такого широковещания будут быстро возрастать; расти будет и размер кэша трансляции в мостах, требуемого для преобразования адресов.

Третий вариант рещает ключевую проблему — существующие стандарты предполагают, что все хосты в сети IP подключены к одной ЛВС. Решение заключается в явной поддержке подсетей. Этот вариант тоже имеет недостатки – в частности, требуется модификация протокола IP, которая влечет за собой необходимость изменения существующих реализаций IP (если планируется использовать их с подсетями). Однако требуемые изменения сравнительно невелики и после их внесения проблема будет эффективно решена5. Кроме того, этот вариант не требует каких-либо изменений, которые будут несовместимы с существующими хостами в сетях без разбиения на подсети.

После выбора одного из вариантов может оказаться, что хосты, которые предполагалось использовать в среде без подсетей, попадут в одну из подсетей, как описано ниже. Такое решение может быть полезно в тех случаях, когда нет возможности явно поддерживать подсети или требуется постепенный переход. С учетом этого для использования второго варианта, описанного выше, нет достаточно веских причин.

В остальной части этого документа описывается модель разбиения сетей IP на подсети.

1.1. Терминология

Во избежание разнотолков и многословия определим термины, которые будут использоваться далее.

Catenet

Набор соединенных между собой сетей IP.

Network — сеть

Отдельная сеть IP (поделенная или не поделенная на подсети).

Subnet — подсеть

Подсеть сети IP.

Network Number — номер сети

В соответствии с [8].

Local Address — локальный адрес

Биты адреса IP, не используемые в номере сети. Используется также термин «rest field» (остальные биты).

Subnet Number — номер подсети

Номер, идентифицирующий подсеть внутри сети.

Subnet Field — поле подсети

Битовое поле в адресе IP, используемое для задания номера подсети.

Host Field — поле хоста

Битовое поле в адресе IP, используемое для адресации конкретного хоста.

Gateway — шлюз6

Узел, подключенный к двум или более сетям с различным административным управлением и/или подсетям, которому хосты направляют дейтаграммы для пересылки.

Bridge — мост

Узел, подключенный к двум или более подсетям, разделенным физически, но находящимся под единым административным управлением, который автоматически пересылает между этими сетями дейтаграммы (при необходимости), оставаясь «незаметным» для остальных хостов. Для обозначения мостов используют также термин software repeater7 (программный повторитель).

2. Стандарты для адресации подсетей

Следуя делению, представленному в [2], мы обнаружили, что подсети являются фундаментальной проблемой адресации. В этом разделе мы впервые описываем предложенную интерпретацию адресации Internet Addressing для поддержки подсетей. Далее рассматривается взаимодействие этого формата адресации с широковещанием и в заключение представлен протокол детектирования используемого в конкретной сети способа интерпретации адресов.

2.1. Интерпретация адресов IP

Предположим, что организации был выделен номер сети Internet8, сеть была поделена на множество подсетей и нужно распределять адреса для хостов. Как следует это делать? Поскольку существуют минимальные ограничения на выделение «локальной части» адреса Internet, предлагается несколько вариантов представления номеров подсетей:

  1. Поле переменной длины — для нумерации подсетей используется произвольное число битов локальной части адреса. Размер поля номера подсети сохраняется в масштабах каждой подсети, но может различаться в разных подсетях. Если поле имеет нулевой размер, это говорит об отсутствии подсетей.
  2. Поле фиксированной длины — для нумерации подсетей используется фиксированное число битов (например, 8).
  3. Поле переменной длины с автокодированием. Классы сетей (размер поля номера сети) определяются значениями старших битов адреса IP – аналогично этому старшие биты локальной части адреса могут задавать размер поля номера подсети.
  4. Поле фиксированной длины с автокодированием. Для нумерации подсетей используется заданное число битов. Единица в старшем бите этого поля говорит об использовании подсетей, при нулевом значении старшего бита вся локальная часть адреса служит для нумерации хостов9.

Поскольку отсутствуют видимые признаки преимуществ иного варианта, во всех этих схемах для нумерации подсетей используются старшие биты локальной части адреса. Поскольку для сетей класса C локальная часть достаточно мала, для этого класса адресов использование подсетей менее осмысленно, нежели для сетей класса A или B.

По каким критериям следует выбирать одну из четырех предложенных схем? Во-первых, мы хотим использовать автокодирование, позволяющее по адресу Internet определить, используется ли в сети разбиение на подсети без привлечения другой информации.

Одним из преимуществ автокодирования является возможность определить, поделена ли нелокальная сеть на подсети. Практическое использование этого преимущества не очевидно. Однако основное преимущество заключается в том, что реализации не требуется дополнительных данных для определения принадлежности двух адресов к одной подсети. Однако это может казаться недостатком, поскольку может вызывать проблемы для сетей без разбиения на подсети, в которых номера с 1 в старшем бите локальной части адреса уже используются10 (см. примечание 2 в конце страницы). Иными словами, полезно иметь возможность контроля разбиения сети на подсети независимо от распределения номеров хостов. Другим недостатком любой схемы с автокодированием является то, что такие схемы уменьшают доступный размер локального пространства адресов по крайней мере вдвое.

Если не использовать схему с автокодированием, ясно, что предпочтительным будет вариант с переменным размером поля номера подсети. Поскольку в любом случае требуется некий «флаг», показывающий использование подсетей, дополнительные издержки в результате использования целого числа (размер поля номера подсети) вместо логической переменной (флаг) пренебрежимо малы. Преимущество использования поля номера подсети с переменным размером заключается в том, что каждая организация получает возможность выбора способа использования достаточно скудного чсла битов локальной части адреса для нумерации подсетей и хостов.

Наше предложение, следовательно, заключается в том, что адреса Internet интепретируются, как три поля:

<network-number><subnet-number><host-number>

где поле <network-number> определено в [8], поле <host-number> имеет размер не менее 1 бита, а поле <subnet-number> постоянно для данной подсети. Дополнительной структуры для полей <subnet-number> и <host-number> не требуется. Если размер поля <subnet-number> равен 0, сеть не делится на подсети (т. е., используется интерпретация [8]).

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|      Сеть     |    Подсеть    |         Номер хоста         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Например, в сети класса A с 8-битовым полем номера подсети поля адреса имеют вид, показанный на рисунке справа.

Предполагается, что для упрощения и повышения эффективности реализаций протокола большинство организаций будет выбирать размер поля номера подсети, кратный восьми битам. Однако реализации должны быть готовы к обработке полей номера подсети иного размера.

Мы отказываемся от рекурсивного использования подсетей с дополнительным делением поля номера хоста по ряду причин:

  • четырехуровневая иерархия обычно не требуется;
  • число битов адреса IP недостаточно велико для такого деления;
  • сложность механизмов дополнительного деления.

2.2. Измнение программ хостов для поддержки подсетей

В большинстве реализация протокола IP имеется код для обслуживания исходящих потоков типа приведенного ниже:

IF ip_net_number(packet.ip_dest) = ip_net_number(my_ip_addr)
THEN
   send_packet_locally(packet, packet.ip_dest)
ELSE
   send_packet_locally(packet, gateway_to(ip_net_number(packet.ip_dest)))

Код с поддержкой множества подключенных сетей несколько сложнее, но в данном случае это не имеет значения.

Для поддержки подсетей нужно сохранить одно дополнительное 32-битовое значение — маску IP (my_ip_mask). Эта битовая маска представляет собой строку битов, в которой установлены (1) значения битов, соответствующий номеру сети IP и номеру подсети. Например, для сети класса A с 8-битовым полем номера подсети маска будет иметь значение 255.255.0.0.

Упомянутый выше код тогда принимает вид:

IF bitwise_and(packet.ip_dest, my_ip_mask) = bitwise_and(my_ip_addr, my_ip_mask)
THEN
   send_packet_locally(packet, packet.ip_dest)
ELSE
   send_packet_locally(packet, gateway_to(bitwise_and(packet.ip_dest, my_ip_mask)))

Очевидно, что часть выражения в условном операторе может быть вычислена заранее.

Может потребоваться изменение функции gateway_to с включением такого же условия сравнения.

Для поддержки хостов со множеством подключения код может быть изменен так, чтобы значения my_ip_addr и my_ip_mask сохранялись для каждого интерфейса, а выражения в условном операторе должны вычисляться для каждого интерфейса.

2.3. Подсети и широковещание

В отсутствии подсетей для протокола IP возможны только два варианта широковещания11 — всем хостам указанной сети или всем хостам данной сети. Последний вариант полезен в тех случаях, когда хост не знает номера своей сети.

При наличии подсетей ситуация слегка усложняется. Во-первых появляется возможность широковещательной передачи в масштабе подсети. Во-вторых, для широковещания всем хостам подсети требуется дополнительный механизм (в работе [6] предложено использовать механизм12 [3]). И, наконец, интерпретация широковещания в данную сеть изменяется и пакеты не пересылаются за пределы исходной подсети.

Следовательно, реализации должны распознавать три типа широковещательных адресов в дополнение к своему адресу хоста:

This physical network — данная физическая сеть

Адрес получателя, состоящий из одних единиц (255.255.255.255), приводит к передаче дейтаграммы как широковещательной в масштабе физической сети; для шлюзов пересылка таких дейтаграмм недопустима.

Specific network — указанная сеть

Адрес получателя содержит корректный номер сети, а локальная часть адреса — только единицы (например, 36.255.255.255).

Specific subnet — указанная подсеть

Адрес получателя содержит корректные номера сети и подсети, а номер хоста — только единицы (например, 36.40.255.255).

Дополнительную информацию о широковещании Internet можно найти в работе [6].

Одним из факторов при решении вопроса об использовании подсетей является возможность широковещания всем хостам сети с подсетями в один прием со стороны передающего хоста. Если бы хосты находились в разных сетях, такая операция стала бы невозможной.

2.4. Определение размера поля номера подсети

Как хост (или шлюз) может определить использование поля номера подсети в подключенной к нему сети? Эта проблема аналогична проблемам, возникающим при загрузке хостов Internet, — как хост может узнать свой адрес и адрес шлюза в своей сети? Для всех ситуаций существует два варианта решения этих проблем — «аппаратная» информация и протоколы на основе шероковещания.

«Аппаратная» информация удобна для изолированных (не подключенных к сети) хостов. Она может быть «встроена» или храниться в дисковом файле (предпочтительно). Однако для широко распространенного случая загрузки бездисковых станций через ЛВС, «аппаратная» информация не подходит. Если технология ЛВС поддерживает широковещание, лучшим методом будет использование «свежезагруженным» хостом широковещательной передачи запроса на получение требуемой информации. Например, для определения адреса IP хост может использовать протокол обратного преобразования адресов RARP13 [4].

Мы предлагаем расширить протокол ICMP [9], добавив пару типов сообщений — Address Format Request и Address Format Reply14, аналогичных сообщениям Information Request и Information Reply (см Приложение I)15.

Новые сообщения ICMP используются следующим образом – хост при загрузке передает широковещательное сообщение Address Format Request16, а шлюз (или хост, действующий вместо шлюза), получив такое сообщение, будет передавать отклик Address Format Reply. Если в запросе отправитель не был указан (поле IP Source Address имеет значение 0), отклик также передается в широковещательном сообщении. Запросивший информацию хост получит это сообщение и сможет определить размер поля номера подсети.

Поскольку для каждой конкретной ЛВС в сообщении Address Format Reply может содержаться только одно значение, нет необходимости проверять соответствие отклика запросу. Даже при получении отклика от нескольких шлюзов, информация во всех сообщениях будет совпадать. Предполагается, что хосты перезагружаются достаточно редко, поэтому количество широковещательных сообщений для определения маски будет достаточно мало.

Если хост подключен к множеству ЛВС, он должен использовать этот протокол для каждой из сетей, пока не будет обнаружено (по отклику одной из ЛВС), что некоторые ЛВС относятся к одной сети и, следовательно, имеют одинаковый размер поля номера подсети.

Одной из возможных проблем является отсутствие сообщений Address Format Request после разумного числа попыток запроса. Возможны три причины возникновения таких ситуаций:

  1. Локальная сеть постоянно изолирована от всех других сетей.
  2. Подсети не используются и ни один из хостов не поддерживает таких запросов ICMP.
  3. Все шлюзы локальной сети (временно) находятся в нерабочем состоянии (down).

В первых двух случаях подразумевается, что поле номера подсети имеет нулевой размер. В третьем случае не существует способа определить размер поля номера подсети и самым безопасным вариантом будет считать этот размер нулевым. Хотя позднее может обнаружиться некорректность такого выбора, это не порождает проблем при передаче. После того, как восстановится нормальная работа шлюза, он будет передать широковещательное сообщение Address Format Reply; когда хост получит это сообщение, он сможет заменить свои допущения полученным от шлюза значением. Хостам и шлюзам не следует передавать сообщений Address Format Reply с «предполагаемой» маской.

В заключение отметим, что хост не обязан использовать протокол ICMP для определения размера поля номера подсети – параметры хоста могут сохраняться в энергонезависимой памяти.

3. Методы маршрутизации подсетей

Обной из проблем, с которыми сталкиваются все хосты Internet, является определение маршрута к другому хосту. Использование подсетей лишь слегка изменяет эту проблему.

При использовании подсетей возникает два уровня процесса маршрутизации вместо одного. Если получатель находится в одной сети с отправителем, в маршрутизации участвуют только маршрутизаторы подсетей между хостами. Если получатель находится в другой сети, процесс маршрутизации требует выбора шлюза для выхода из сети отправителя и маршрута через эту сеть к выбранному шлюзу.

К счастью, большинство хостов могут игнорировать это различие (фактически, игнорировать любой выбор маршрута), используя принятый по умолчанию шлюз в качестве начала маршрута ко всем получателям и опираясь на сообщения ICMP Host Redirect для определения более подходящих маршрутов. Однако такой метод неэффективен для шлюзов и многодомных хостов, поскольку перенаправление может оказаться бесполезным при некорректном начальном выборе маршрута. Таким хостам следует использовать протокол обмена маршрутной информацией, но этот вопрос выходит за пределы настоящего документа. В любом случае, описанная выше проблема не зависит от использования подсетей.

Проблема хостов с одним подключением заключается в поиске хотя бы одного соседнего шлюза. Здесь также имеются два варианта — аппаратная информация и широковещание. Мы полагаем, что проблема поиска соседнего шлюза не зависит от использования подсетей и, следовательно, решение этой проблемы при наличии подсетей будет таким же.

Однако еще одна проблема сохраняется — отправитель должен понять, следует передавать дейтаграмму для адресата шлюзу или ее можно отправить получателю напрямую. Иными словами, находится ли адресат в одной физической сети с отправителем? Эта фаза процесса маршрутизации является единственной, которая требует от реализации явной поддержки подсетей. Фактически, если широковещание не применяется, это единственная ситуация, когда реализацию IP требуется изменить для поддержки подсетей.

В силу сказанного, возможно использовать существующие реализации без внесения изменений даже при наличии подсетей17. Для того, чтобы это тсало возможным, реализация должна:

  • использоваться только на хостах с одним подключением, но не на шлюзах;
  • использоваться в широковещательной ЛВС;
  • использовать протокол преобразования адресов (типа ARP [7]);
  • не требовать поддержки соединения в случаях отказов шлюза.

В такой ситуации можно ограничиться модификацией сервера ARP в подсети так, чтобы он при получении запроса ARP проверял адрес получателя на предмет определения своей принадлежности к лучшему пути в направлении получателя. При положительном результате проверки сервер передает запрашивающему хосту отклик ARP со своим аппаратным адресом. Запрашивающий хост в результате предполагает, что ему известен аппаратный адрес получателя и передает пакеты по этому адресу. Фактически пакеты получает шлюз, который пересылает их адресату обычным путем.

Этот метод требует некоторого «размывания» уровней на шлюзах, поскольку сервер ARP и таблица маршрутизации IP обычно не связаны. Однако реализовать такую связь можно достаточно просто и без существенного снижения производительности. Одна из проблем состоит в том, что при аварии исходного шлюза для отправителя не будет способа узнать другие маршруты к получателю, если такие маршруты имеются. В результате соединение будет прервано.

Не следует путать этот метод организации «подсетей на базе ARP» со слегка похожим на него использованием мостов на основе ARP. Подсети на базе ARP используют возможность шлюза проверять адрес IP и устанавливать маршрут к получателю на основе явной топологии подсети. Иными словами, малая часть процесса выбора маршрута переносится от хоста-отправителя к шлюзу. Мост на основе ARP, напротив, должен узнать расположение каждого хоста без помощи отображения между адресами хостов и топологией. Системы, построенные на основе таких мостов, не следует считать поделенными на подсети.

Важно отметить, что использование подсетей на базе ARP осложняется широковещанием. Серверу ARP [7] никогда не следует отвечать на запросы, где получатель имеет широковещательный адрес. Такие запросы могут исходить только от хостов, которые не распознают широковещательных адресов в таком качестве и ответ на подобный запрос почти всегда будет приводить к возникновению маршрутной петли. Если имеется N таких хостов, которые не распознают адрес в качестве широковещательного, пакет, переданный с TTL18 может приводить к возникновению TN ненужных широковещательных пакетов.

4. Примеры использования подсетей

В этом разделе кратко описаны примеры использования подсетей в нескольких организациях.

4.1. Сиэнфордский университет

В Стенфордском университете подсети появились по историческим причинам. В сети университета использовались протоколы Pup [1] для нескольких экспериментальных сетей Ethernet [5] с 1979 года, на несколько лет раньше начала использования протоколов Internet. В работе было множество шлюзов Pup, а все хосты и шлюзы обменивались таблицами маршрутизации с использованием простого широковещательного протокола.

После появления протокола IP было принято решение об использовании восьмибитового поля номера подсети и номера подсетей Internet были выбраны в соответствии с номерами сетей Pup для данной ЛВС Ethernet и номерами хостов Pup (тоже восемь битов) в качестве номеров хостов в адресах Internet.

Шлюзы, поддерживающие только Pup, были модифицированы для пересылки дейтаграмм Internet в соответствии с таблицами маршрутизации Pup, поскольку без такой модификации они просто не понимали пакетов Internet и фактически не меняли значение поля TTL в заголовках IP. Такое решение представлялось приемлемым, поскольку ошибок, вызывающих появление маршрутных петель, не наблюдалось. Хосты Internet, которые были многодомными и могли, таким образом, функционировать в качестве маршрутизаторов, меняли значение TTL. Поскольку все такие хосты одновременно являлись шлюзами Pup дополнительного обмена маршрутными данными не требовалось.

Реализации хостов Internet были модернизированы для поддержки подсетей (различными путями, но с одинаковым результатом). Поскольку все эти хосты уже имели реализации Pup, таблицы маршрутизации Internet поддерживались теми же процессами, что и таблицы Pup — номера сетей Pup просто транслировались в номера подсетей Internet.

При добавлении сетей Ethernet 10 Мбит/с шлюзы были модифицированы для использования описанной выше схемы на базе ARP. Это позволило использовать немодифицированные хосты в сетях Ethernet 10 Мбит/с.

Подсети IP начали использоваться с 1982 г; в настоящее время19 насчитывается около 330 хостов, 18 подсетей и близкое число шлюзов между подсетями. Поскольку шлюзы, поддерживающие только Pup, были преобразованы в шлюзы Internet, был добавлен протокол обмена маршрутной информацией Internet, заменивший протокол Pup.

4.2. MIT

MIT20 был первым сайтом IP с большим набором локальных сетевых соединений. Поскольку это было до деления сетевых номеров на классы, выделение каждому каналу MIT своего номера сети IP привело бы к расходу значительной части адресного пространства. В MIT было принято решение использовать один номер сети IP и самостоятельно управлять оставшимися 24 битами адреса, разделив их на три 8-битовых поля — номер подсети, резервное поле (0) и номер хоста. Поскольку уже использовавшийся в MIT протокол CHAOS работает с восьмибитовым полем номера подсети, можно было выделить каждому каналу одинаковые номера для обоих протоколов. Для номера хоста IP было выбрано 8-битовое поле потому, что в тот момент большинство сетевого оборудования использовало 8-битовые адреса, как в протоколе CHAOS. Это позволило также зарезервировать часть битов адреса IP на будущее.

Первоначальный план предполагал использование протоколов динамической маршрутизации между шлюзами подсетей IP — несколько протоколов этого типа тогда обсуждалось, но ни один не был реализован, поэтому продолжают использоваться статические таблицы. Ясно, что переход к динамической маршрутизации со временем произойдет.

Для решения проблемы с необходимостью модификации импортируемых программ IP для работы в средахх с подсетями, MIT начал искать модель, позволяющую обойтись минимальными изменениями IP на хостах. В результате была выбрана модель, в которой шлюзы IP передают сообщения ICMP Host Redirect, а не Network Redirect. Сейчас все внутренние IP-шлюзы MIT поступают таким образом. С хостами, которые могут поддерживать таблицы маршрутизации IP для нелокального обмена пакетами на уровне хостов, это позволяет скрыть основную часть структуры подсетей. Минимальные правки программ на хостах для корректной работы в средах с подсетями и без них включали поддержку алгоритма битовых масок, упомянутого выше.

У MIT нет плана незамедлительного перехода на использование одного «одобренного» протокола — это обусловлено локальной автономностью и количеством установленных программ, а также отсутствием единого индустриального стандарта. Вместо этого была принята модель обеспечения одного набора физических каналов и пакетных коммутаторов и деление на несколько «виртуальных» сетей в одном наборе физических каналов. У MIT был некоторый опыт попыток обмена маршрутной информацией между протоколами и «заворачивания» одного протокола в другой. Общей моделью было сохранение изоляции протоколов при использовании общего базового оборудования. Использование ARP для сокрытия структуры подсетей не так важно, поскольку ведет к усложнению операций преобразования адресов. В усложненной системе (с петлями и разноскоростными каналами) потребуется более изощренный обмен информацией между шлюзами, что делает этот явный (но изолированный от хоста) механизм лучшим решением.

4.3. Университет Карнеги-Мэллона

CMU21 использует сеть класса B, поделенную на 11 физических подсетей (2 сети 3Mbit Experimental Ethernet, 7 сетей Ethernet 10 Мбит/с и два кольца ProNet). Адреса хостов распределены так, что все адреса с данным третьим октетом относятся к одной подсети (обратное не обязательно верно), это важно с точки зрения удобства администрирования. Программы не знают специфики этого механизма распределения и не зависят от маршрутов между ЛВС.

Вместо этого используется схема с мостами на базе ARP. Когда хост передает широковещательный запрос ARP, все мосты, получившие этот запрос, кэшируют исходное отображение протокольного адреса и пересылают запрос (после предварительных операций), как широковещательный запрос ARP в каждую из подключенных к мосту сетей. Когда мост получает (не широковещательный) отклик ARP, в котором целевой протокольный адрес не относится к этому мосту, он просматривает кэш ARP для определения сети, в которую следует переслать отклик. Мосты, таким образом, пытаются расширить протокол ARP на гетелогенную сеть из множества ЛВС. Следовательно, мостам требуется преобразовывать широковещательные запросы ARP из одной сети в широковещательные запросы ARP во все другие сети, подключенные к мосту, даже когда мост «знает лучшую» сеть. Этот алгоритм работает только в отстуствии циклов в графе сетевой связности (в данном случае это выполняется). Ведутся работы по замене этого простого алгоритма протоколом, реализованным в мостах, для поддержки избыточных путей и снижения объема широковещания. Задача состоит в сохранении базы ARP и прозрачности хостов, если это возможно.

Реализации, поддерживающие Ethernet 3 Мбит/с и кольца proNET 10 Мбит/с в CMU, используют RFC 826 ARP (взамен того или иного аппаратного отображения типа простого использования 8-битовых аппаратных адресов в качестве четвертого октета адреса IP).

Поскольку избыточные пути между ЛВС отсутствуют, возникает вопрос поддержки соединений при аварии моста. При количестве поддерживающих IP хостов порядка 150 на сеть, размер кэша в мостах сохраняется в разумных пределах и на пересылку широковещательных запросов ARP расходуется достаточно малая полоса.

Сеть CMU растет от небольшой конфгурации с одним подключением в подразделении CS/RI до кампусной сети с множеством департаментов, 5000-10000 хостов и избыточными соединениями между ЛВС. Возможно, что схема с мостами на базе ARP не обеспечит требуемого масштабирования и может потребоваться система с явными подсетями. Среднесрочной задачей, однако, является создание среды, в которую можно импортировать необновленные реализации IP (в частности, Ethernet 10 Мбит/с), чтобы сохранить прозрачный (т. е., основанный на ARP) механизм маршрутизации как можно дольше. CMU считает, что даже при включении подсетей в стандарты IP, они не будут использоваться достаточно широко — в этом состоит основная помеха использованию подсетей в CMU.

I. Формат пакетов ICMP

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |      Code     |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |       Sequence Number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Пакеты Address Format Request и Address Format Reply включают показанные на рисунке поля22.

Поля IP

Адреса

Адрес отправителя в сообщении Address Format Request будет адресом получателя Address Format Reply. При создании отклика адрес отправителя из запроса становится адресом получателя, а в качестве отправителя отклика указывается адрес отвечающего хоста, код типа меняется на A2, значение размера поля номера подсети помещается в поле Code и запово рассчитывается контрольная сумма. Однако если в качестве адреса отправителя запроса указан 0, в качестве адреса получателя отклика указывается широковещательный адрес.

Поля ICMP

Type — тип

A1 для запросов;

A2 для откликов.

Code — код

0 для сообщений Address Format Request.

Размер поля номера подсети в сообщениях Address Format Reply.

Checksum — контрольная сумма

Контрольная сумма представляет собой 16-битовое поразрядное дополнение до 1 суммы дополнений до 1, рассчитанной для сообщения ICMP, начиная с поля ICMP Type. При расчете контрольной суммы значение поля принимается нулевым. Механизм расчета контрольной суммы в будущем может измениться.

Identifier — идентификатор

Идентификатор служит для сопоставления запросов и откликов. Может иметь нулевое значение.

Sequence Number — порядковый номер

Номер служит для сопоставления запросов и откликов. Может иметь нулевое значение.

Описание

Шлюзу, получившему сообщение Address Format Request следует возвратить отклик на него, указав в поле Code число битов поля номера подсети в адресах IP для сети, в которую дейтаграмма была адресована. Если запрос был широковещательным, получателем будет «данная сеть». Размер поля Subnet может принимать значения от 0 до (31 — N), где N задает число битов в поле номера сети IP (т. е., 8, 16 или 24).

Если запрашивающий хост не знает своего адреса IP, он может указать значение 0 в поле адреса отправителя; отклик следует передавать по широковещательному адресу. Поскольку для сети существует один возможный формат адреса, нет необходимости устанавливать соответствие между запросами и откликами. Однако такого подхода следует, по возможности, избегать, поскольку он ведет к росту широковещательной нагрузки на сеть.

Тип A1 может приходить от шлюза или хоста.

Тип A2 может приходить от шлюза или хоста, действующего в качестве шлюза.

II. Примеры

В приведенных здесь примерах предполагается, что запрашивающий хост имеет адрес 36.40.0.123, адрес шлюза — 36.40.0.62, сеть — 36.0.0.0, а поле номера подсети занимает 8 битов.

Сначала предположим, что широковещание разрешено и хост 36.40.0.123 знает свой адрес. Он будет отправилять дейтаграмму:

Source address: 36.40.0.123
Destination address: 36.255.255.255
Protocol: ICMP = 1
Type: Address Format Request = A1
Code: 0

36.40.0.62 будет слышать эту дейтаграмму в ответ на которую ему следует передать отклик:

Source address: 36.40.0.62
Destination address: 36.40.0.123
Protocol: ICMP = 1
Type: Address Format Reply = A2
Code: 8

В качестве следующего примера предположим, что 255.255.255.255 означает «широковещательный адрес данной физической сети», как описано в [6].

Предыдущий пример неэффективен, поскольку запрос может в широковещательном режиме пересылаться во множество подсетей. Более эффективный метод, который мы рекомендуем, заключается в том, что хост сначала определяет свой адрес (возможно с помощью протокола RARP, описанного в [4]), а после этого передает запрос ICMP по адресу 255.255.255.255:

Source address: 36.40.0.123
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Format Request = A1
Code: 0

Шлюз в этом случае может напрямую ответить запрашивающему хосту.

Предположим, что 36.40.0.123 является бездисковой станцией, которая не знает даже свой номер хоста. Она может передать дейтаграмму:

Source address: 0.0.0.0
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Format Request = A1
Code: 0

36.40.0.62 услышит эту дейтаграмму, на которую ему следует ответить дейтаграммой:

Source address: 36.40.0.62
Destination address: 36.40.255.255
Protocol: ICMP = 1
Type: Address Format Reply = A2
Code: 8

Отметим, что шлюз использует максимально «узкий» широковещательный адрес для отклика (передача отклика по адресу 36.255.255.255 приведет к рассылке отклика во множество подсетей в дополнение к той, которой он предназначен). Но даже в этом случае излишнее использование широковещания приведет к неоправданному росту широковещательной нагрузки на все хосты подсети, поэтому рекомендуется использовать «анонимный» адрес отправителя запросов как можно реже.

Если широковещание не разрешено, мы предполагаем, что хост имеет «встроенную» информацию о соседних шлюзах. Таким образом, 36.40.0.123 может передать дейтаграмму:

Source address: 36.40.0.123
Destination address: 36.40.0.62
Protocol: ICMP = 1
Type: Address Format Request = A1
Code: 0

36.40.0.62 следует отвечать на эту дейтаграмму, как в предыдущем случае.

Литература

  1. D.R. Boggs, J.F. Shoch, E.A. Taft, and R.M. Metcalfe. «Pup: An Internetwork Architecture.» IEEE Transactions on Communications COM-28, 4, pp612-624, April 1980.

  2. David D. Clark. Names, Addresses, Ports, and Routes. RFC-814, MIT-LCS, July 1982.
  3. Yogan K. Dalal and Robert M. Metcalfe. «Reverse Path Forwarding of Broadcast Packets.» Comm. ACM 21, 12, pp1040-1048, December 1978.
  4. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A Reverse Address Resolution Protocol. RFC-903, Stanford University, June 1984.
  5. R.M. Metcalfe and D.R. Boggs. «Ethernet: Distributed Packet Switching for Local Computer Networks.» Comm. ACM 19, 7, pp395-404, July 1976. Also CSL-75-7, Xerox Palo Alto Research Center, reprinted in CSL-80-2.
  6. Jeffrey Mogul. Broadcasting Internet Datagrams. RFC-919, Stanford University, October 1984.
  7. David Plummer. An Ethernet Address Resolution Protocol. RFC-826, Symbolics, September 1982.
  8. Jon Postel. Internet Protocol. RFC-791, USC-ISI, September 1981.
  9. Jon Postel. Internet Control Message Protocol. RFC-792, USC-ISI, September 1981.


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1Сеть IP в современной терминологии, используемой в переводе. Прим. перев.

2В оригинале используется термин «кабель», поскольку ЛВС во время создания документа чаще всего представляла собой сеть с «общей» коаксиальной шиной, соединяющей последовательно все компьютеры сети. Прим. перев.

3Современные маршрутизаторы и протоколы маршрутизации не порождают таких проблем, но этот вариант все равно остается нежелательным по причине общей нехватки адресов IP и снижения уровня защиты сетей. Прим. перев.

4Address Resolution Protocol — протокол преобразования адресов. Прим. перев.

5В настоящее время эта проблема успешно разрешена. Прим. перев.

6Сейчас такие узлы обычно называют «маршрутизаторами». Прим. перев.

7В настоящее время этот термин устарел и практически не используется. Прим. перев.

8В современной терминологии «блок адресов». Прим. перев.

9В RFC 950 этот тезис уже исключен. Причина, по-видимому, заключается в некоторой противоречивости самого тезиса и неэффективном использовании адресов при отказе от подсетей (старший бит локальной части в этом случае не может иметь значение 1, что приводит к невозможности использования половины адресов. Прим. перев.

10Например, для некоторых хостов используются адреса, представляющие собой комбинацию номера сети класса A и 24 младших битов 48-битового аппаратного адреса Ethernet.

11Широковещание Internet рассматривается на основе работы [6].

12Reverse Path Forwarding — пересылка по обратному пути.

13Reverse Address Resolution Protocol.

14Запрос адресной информации и отклик на такой запрос, соответственно.

15В конечном итоге в протокол ICMP были добавлены два типа сообщений Address Format Request и Address Format Reply. Прим. перев.

16Если широковещание не поддерживается, предполагается, что хост «знает» соседнего шлюза и сообщение ICMP следует передавать этому шлюзу.

17В более ранних работах это назувалось «сосуществованием прозрачных и явных подсетей в одной сети».

18Time-To-Live — время жизни пакета в сети.

191984 год. Прим. перев.

20Massachusetts Institute of Technology — Массачусетский технологический институт. Прим. перев.

21Carnegie-Mellon University.

22В RFC 950, принятом в качестве стандарта, даны слегка отличающиеся имена сообщений и их полей. Прим. перев.




RFC 925 Multi-LAN Address Resolution

Network Working Group                                      J. Postel
Request for Comments: 925                                        ISI
                                                        October 1984

Преобразование адресов в сетях с множеством ЛВС

Multi-LAN Address Resolution

PDF

Статус документа

Этот документ был инициирован Jeffery Mogul, который в RFC 917 Internet Subnets, рассмотрел использование «явных подсетей» (explicit subnet) в средах с множеством ЛВС. В этом документе я пытаюсь рассмотреть случай «прозрачных подсетей» (transparent subnets0. Данный документ описывает предложенный сообществу ARPA-Internet протокол и служит приглашением к дискуссии в целях развития протокола. Документ может распространяться свободно.

Введение

Проблема трактовки множества локальных сетей (ЛВС), как одной сети Internet1, вызывает некоторый интерес и озабоченность. Выделять отдельную сеть IP для каждой ЛВС на сайте было бы непрактично. Детали соединений между ЛВС на сайте желательно скрыть от пользователей, шлюзов и хостов, находящихся за пределами сайта. Возникает вопрос — как это лучше сделать или хотя бы просто сделать. Одним из вариантов является использование явных подсетей [1]. Схема с явными подсетями предлагает рекурсивное применение механизмов управления сетями Internet к управлению ЛВС в рамках одной сети. В этом документе предложена другая модель — прозрачные подсети — на основе расширения протокола ARP [2] для множества ЛВС.

Обзор

Рассмотрим кратко протокол преобразования адресов ARP2. Каждый хост в широковещательной ЛВС знает свой физический аппаратный адрес HA в ЛВС и спой адрес IP (IA). Когда хост A знает IA для хоста B и хочет отправить тому дейтаграмму, хост A должен найти HA, соответствующий IA хоста B. Для решения этой задачи хост A формирует пакет ARP, содержащий значения HA и IA данного хоста, а также IA искомого хоста B). Этот пакет ARP хост A передает в широковещательном режиме. Хосты, получившие этот пакет ARP проверяют соответствие искомого адреса их собственному. При совпадении (только на хосте B) адресов хост отвечает отправителю запроса (хост A) откликом со своим адресом HA. В результате хост A будет знать оба адреса (HA и IA) получателя (хост B). Полученную информацию хост A сохраняет в своей таблице для использования в будущем.

Примечание. Задачи протокола ARP в реальности шире, чем описано в этом примере.

Идея данного документа заключается в расширении ARP для работы в среде с множеством соединенных ЛВС.

Предположим, что некий «магический хост» (BOX) подключен одновременно к двум (или более) ЛВС.

Поведение хостов в точности соответствует базовому ARP.

Когда любой из хостов передает широковещательный запрос ARP, BOX читает этот запрос (как и остальные хосты ЛВС). В дополнение к обычной проверке соответствия адресов (и ответа при совпадении), BOX проверяет в своем кэше для каждой из подключенных ЛВС наличие отображения IA:HA.

Случай 1. Если отображение для хоста найдено в кэше ЛВС, из которой поступил запрос, BOX не отвечает на такой запрос (позволяя ответить хосту с соответствующим адресом).

Случай 2. Если отображение найдено в кэше не той ЛВС, откуда пришел запрос, BOX передает отклик со своим адресом HA в ЛВС, из которой поступил запрос. В данном случае BOX выступает, как агент искомого хоста.

Случай 3. Если отображение отсутствует в таблицах для всех ЛВС, BOX должен попытаться узнать этот адрес и реагировать на запрос, как в случае 1 или 2.

В случае 3 BOX делает кое-что «магическое».

BOX хранит список поиска хостов. Каждая запись списка включает IA искомого хоста, идентификатор интерфейса, через который получен запрос ARP, и адреса отправителя исходного запроса. В описанном выше случае 3 хост обращается к списку поиска. Если адрес искомого хоста присутствует в списке, поиск завершается (отправителю исходного запроса при этом ничего не передается и запись сохраняется в списке).

Если адреса в списке не обнаружено, сначала в создается пустая запись, затем BOX создает и отправляет пакет ARP через каждый интерфейс, кроме того, через который был принят исходный запрос. При получении отклика данные вносятся в соответствующий кэш, запись удаляется из списка поиска и для исходного запроса создается и отправляется отклик ARP, как в случае 13 или 2. Если отклика не было получено, отправителю исходного запроса ничего не передается и запись сохраняется в списке поиска.

Для записей в кэше и списке поиска должен устанавливаться срок действия (тайм-аут).

При получении каждого запроса ARP хост BOX должен включать отображение адресов IA:HA в кэш для ЛВС, из которой запрос был принят.

Протокол ARP для множества соединенных ЛВС

План заключается в применении протокола ARP в его исходном виде. Новым элементом является «магический хост» (мост на базе ARP), который транслирует запросы ARP в соседние ЛВС и выступает в качестве агента по трансляции дейтаграмм хостам других ЛВС.

Детали

Хосты работают точно так же, как при обычном ARP.

ЛВС соединяются между собой хостами BOX (компьютер, подключенный по крайней мере к двум ЛВС). BOX реализует описанные ниже процедуры.

Каждый хост BOX хранит таблицу для каждой ЛВС, к которой он подключен (или для каждого интерфейса в ЛВС). Записи в таблице хранятся ограниченное время, поэтому таблицы представляют собой кэш свежей информации. Записи таблицы представляют собой пары адресов IA:HA для данной ЛВС.

При передаче широковещательного запроса ARP любым из хостов BOX получает этот запрос (как и остальные хосты данной ЛВС). В дополнение к сравнению искомого адреса в запросе со своим адресом (и отклику при совпадении) BOX просматривает в своем кэше отображения IA:HA для всех ЛВС, к которым он подключен.

Случай 1. Если отображение для хоста найдено в кэше ЛВС, из которой поступил запрос, BOX не отвечает на такой запрос (позволяя ответить хосту с соответствующим адресом). Отсчет тайм-аута для записи не возобновляется.

Случай 2. Если отображение найдено в кэше не той ЛВС, откуда пришел запрос, BOX передает отклик со своим адресом HA в ЛВС, из которой поступил запрос. Отсчет тайм-аута для записи не возобновляется.

В этом случае BOX показывает, что он будет выступать в качестве агента искомого хоста. При поступлении дейтаграммы IP на BOX этот хост попытается переслать ее, используя информацию из кэша отображений.

Случай 3. Если отображение отсутствует в таблицах для всех ЛВС, BOX должен попытаться узнать этот адрес и реагировать на запрос, как в случае 1 или 2. В этом случае BOX делает кое-что «магическое».

BOX хранит список поиска хостов (искомых, но не найденных). Каждая запись такого списка включает IA искомого хоста, интерфейс ЛВС, с которого был получен запрос ARP, и адреса отправителя исходного запроса.

В случае 3 просматривается список поиска. При обнаружении адреса искомого хоста в списке поиск прекращается.

Если адрес отсутствует в списке, поиск продолжается путем создания хостом BOX записи в списке поиска, а затем созданий запроса ARP и отправки его через все интерфейсы4. Эти запросы ARP включают адреса IA и HA хоста BOX, а также адрес IA искомого хоста и запрашивают адрес HA для искомого хоста. При получении отклика на запрос ARP информация из него вносится в соответствующий кэш, запись удаляется из списка поиска и BOX реагирует на исходный запрос ARP, как в описанных выше случаях 1 и 2. Если отклика не получено, на исходный запрос не передается никакого отклика и запись сохраняется в списке поиска.

Отметим, что хосту BOX следует соблюдать меру при отправке запросов ARP. Для обычных хостов нормальным считается повторение запросов ARP до 5 раз и BOX должен придерживаться этого ограничения.

При прерывании поиска отправителю запроса не передается никакого отклика и запись сохраняется в списке поиска.

Для запросов ARP не предусмотрено отрицательной обратной связи, поэтому единственным критерием констатации неудачного поиска является тайм-аут.

Для каждого полученного запроса ARP хост BOX должен также помещать отображение IA:HA для передавшего запрос хоста в кэш для ЛВС, из которой получен запрос.

Время присутствия записей в кэшах и списке поиска должно быть ограничено (тайм-аут).

Нужно сохранять список поиска и следовать правилам для предотвращения бесконечной трансляции запросов ARP для хоста, который не отвечает. Если хост указан в списке поиска, запросы ARP для него не будут транслироваться. Если хост, который не работал (или по каким-то причинам не отвечал на запросы ARP), восстанавливает работоспособность (начинает отвечать на запросы ARP), он по-прежнему будет не доступен для хостов других ЛВС, пока не наступит тайм-аут для записи в таблице.

Для этой проблемы имеется два решения — 1) задавать достаточно короткий тайм-аут и 2) периодически отправлять с хоста BOX запросы ARP для каждой записи из списка.

В описанной схеме используется несколько тайм-аутов.

  1. Время, в течение которого хост пытается определить адрес с помощью ARP. На практике может выполняться несколько попыток до принятия решения о том, что хост не отвечает. Нужно тщательно оценить время, в течение которого хост может повторять попытки. Обозначим это время T1.

  2. Время, в течение которого запись сохраняется в списке поиска, или время между генерацией хостом BOX пакетов ARP для преобразования данного адреса. Обозначим это время T2.

    Отметим, что T2 должно превышать сумму значений T1 для самой длинной «петли» ЛВС.

  3. Время хранения в кэше записей для каждой ЛВС. Обозначим это время T3.

Должно выполняться соотношение T1 < T2 < T3.

Предлагается устанавливать для T1 значение меньше 1 минуты, для T2 — 10 минут, T3 — 1 час.

Если среда достаточно статична, увеличение T3 будет снижать число операций поиска (и трафик ARP). В динамичной среде уменьшение T3 будет ускорять адаптацию к изменениям.

Другим вариантом является перезапуск таймера для записи в кэше при каждом обращении к ней и малое значение для T3. Это приведет к тому, что востребованные записи будут долго сохраняться в кэше, а редко используемые — будут быстро удаляться. К сожалению нет каких-либо корреляций между частотой использования и корректностью. Этот метод может приводить к длительному сохранению в кэше устаревших записей, если для такой записи запросы будут повторяться чаще одного раза за период тайм-аута.

При обслуживании обычных дейтаграмм устройства BOX должны уменьшать значение поля TTL5 и обновлять контрольную сумму заголовка IP. При нулевом значении TTL дейтаграмма отбрасывается (не пересылается).

ARP, в соответствии с текущим определением, будет считать недавнюю информацию лучшей и наиболее актуальной. В более сложной среде с множеством ЛВС, где имеются петли в связности, очевидно наличие двух или более откликов на запрос ARP для хоста из другой ЛВС. Возможно, что первым будет отклик от устройства BOX на более эффективном пути.

Единственным изменением в реализации ARP в соответствии с предложениями данного документа является предотвращение замены отображений, полученных из первого отклика.

Возможные проблемы

Некорректные записи в кэше

Если в кэше появилась та или иная некорректная информация, она будут сохраняться в течение времени T3. Сохранение в кэше устаревшей информации может приводить к (временной) потере связи с хостом, если у него изменится отображение IA:HA.

Одним из способов замены устаревших записей в кэше является явная интерпретация устройством BOX широковещательного отклика ARP, как требования замены записи для данного IA или HA в соответствии с новым отображением IA:HA. Важно, чтобы серверы передавали широковещательные отклики ARP, когда они приходят.

Хосты без поддержки ARP

Не представляется реальным сосуществование и взаимодействие в одной ЛВС хостов, поддерживающих и не поддерживающих ARP. Случай, когда все не поддерживающие ARP хосты собраны в одной ЛВС, рассматривается в следующем параграфе (ЛВС без широковещания).

Хосты, не поддерживающие ARP, должны использовать какой-то иной механизм отображения адресов. Они могут поддерживать полную таблицу хостов, пользоваться такой таблицей на неком сервере с использованием того или иного протокола или принимать все решения о маршрутизации на основе анализа адресных полей.

ЛВС без широковещания

Устройства BOX, подключенные к ЛВС без поддержки широковещания и/или ЛВС с хостами, не отвечающими на ARP, могут применять статические или динамические таблицы отображений IA:HA для таких ЛВС LAN (или один адрес может рассчитываться на основе другого). Все хосты такой ЛВС должны быть включены в таблицу.

Когда устройству BOX нужно найти адресное отображение и ему приходится отправлять запрос ARP в ЛВС без поддержки широковещания (это может произойти только для хоста, не входящего в ЛВС без поддержки широковещания, поскольку все хосты таких ЛВС включены в таблицу), оно должно вместо этого отправить запросы всем другим устройствам BOX в данной ЛВС.

Размер таблиц

Наихудшим случаем для размера таблиц в BOX будет по записи для каждого хоста всего множества ЛВС. Т. е., таблицы, хранящиеся для интерфейсов в каждую ЛВС могут (в худшем случае) содержать по записи для каждого хоста всех ЛВС. Однако в реальности в таблицах кэшируются записи, потребные для текущей коммуникационной активности и упомянутый худший случай не является типичным. Большинство хостов будет взаимодействовать в основном с хостами своей ЛВС, и иногда с небольшим числом хостов из других ЛВС. Большая часть сетевой активности будет состоять из обмена данными между рабочими станциями и серверами. Можно считать, что большая часть взаимодействий будет включать основные серверные хосты и записи для этих хостов будут находиться постоянно в таблицах устройств BOX.

Возникновение петель

Возникновение бесконечных коммуникационных петель через соединенные между собой ЛВС предотвращается путем хранения списков поиска в устройствах BOX и прерывания поиска при наличии искомого адреса в таком списке.

Коммуникационные петли для обычных дейтаграмм не могут возникать по причине уменьшения устройствами BOX значений TTL и отбрасывания дейтаграмм с TTL = 0. Для отлаживания полезно, чтобы устройства BOX сообщали а таких фактах отбрасывания дейтаграмм.

Широковещание

Отметим, что широковещание не имеет ничего общего с прозрачными или явными подсетями. Поскольку этот вопрос рассматривался в работе [1], обсудим его и здесь. Две из трех рассмотренных в [1] функций широковещания работают в нашем случае точно так же, и третья тоже может поддерживаться.

Утверждается также, что вопрос поддержки широковещательной интерпретации адресов IA сложнее вопроса выбора между явными и прозрачными подсетями и должен рассматриваться отдельно.

Отмечено также, что широковещание не является эффективным и лучше использовать групповую адресацию (multicast). Может иметь смысл выяснение вопросов групповой адресации Internet до принятия схемы с широковещанием.

Данная сеть IP

Если используется IA, состоящий из номера данной сети и номера хоста, содержащего все 1 (например, 36.255.255.255), подразумевается широковещательная отправка всем хостам данной сети IP (все ЛВС). Устройства BOX должны пересылать такую дейтаграмму. Кроме того, устройство BOX должно проверять, не предназначена ли дейтаграмма и ему.

Для предотвращения бесконечных петель каждое устройство BOX должно сохранять список недавних широковещательных пакетов. Записи этого списка включают IA отправителя и значение поля Identification из заголовка дейтаграммы. Если полученный широковещательный пакет соответствует записи в списке, такой пакет отбрасывается без пересылки. Записи сохраняются в списке в течение времени T2.

Только данная ЛВС

Если адрес IA содержит только 1 (т. е., 255.255.255.255) это означает широковещательную передачу IP всем хостам только данной ЛВС. Устройствам BOX недопустимо пересылать такие дейтаграммы. Кроме того, устройство BOX должно проверять, не предназначена ли дейтаграмма и ему.

Только другие ЛВС

Поскольку ЛВС не идентифицируются по IA, такую адресацию невозможно задать обычным путем. Некоторые даже считают поддержку подобной адресации глупостью.

Одним из способов такой адресации будет организация специального IA для каждой ЛВС, который будет означать «широковещательный пакет для ЛВС». Например, 36.255.255.128 определяет широковещательный пакет для ЛВС A, 36.255.255.187 — широковещательный пакет для ЛВС B и т. д. Эти адреса будут соответствующим образом интерпретироваться устройствами BOX, подключенными к соответствующим ЛВС, где адрес имеет специальное значения, а прочие устройства BOX будут относится к ним, как к обычным адресам IA. Так, где происходит специальная обработка таких адресов, они должны преобразовываться в широковещательные адреса «только для данной ЛВС».

Обсуждение

Заявление для расширенной схемы ARP заключается в том, что среднему хосту даже не нужно знать, что он работает в среде с множеством ЛВС.

Если хост проанализирует свой локальный кэш отображений IA:AH, он может обнаружить, что несколько адресов IA отображаются на один адрес HA. А если он проведет временной анализ, то может увидеть, что некоторые хосты отвечают быстрее других. Более того, он может увидеть корреляции между этими наблюдениями. Но лишь немногие хосты делают это.

Структура адреса

В схеме с явными подсетями некоторые биты IA предназначены для идентификации подсети (т.е., ЛВС). Адрес делится на поля сети, подсети и хоста. Как правило, такое выделение полей снижает эффективность использования адресного пространства. Могут возникать существенные проблемы в реализациях при появлении новых сетей и связанной с этим необходимости изменения размера поля подсети. На сегодняшний день схема с явными подсетями представляется непрактичной для адресов IA класса C.

В схеме с расширенным ARP адрес включает только поля для сети и хоста. Расширение ARP подходит для IA всех классов.

Перемещение хостов

В схеме с явными подсетями перенос хоста из одной ЛВС в другую требует смены адреса IA.

В схеме с расширенным ARP адрес IA можно не менять.

При внимательном рассмотрении ситуации можно заметить две реальных проблемы.

  1. Как хост определяет местоположение адресата (та же или другая ЛВС)?

    Этот вопрос предполагает, что хосту следует понимать различия и по-разному вести себя в двух случаях, а также то, что знающий ответ хост будет понимать, как передавать данные (напрямую хосту или через BOX).

    В предлагаемом здесь варианте хосты не обязаны различать эти два случая и могут вести себя одинаково в обоих.

  2. Как устройство BOX, соединяющее ЛВС узнает, какие устройства BOX ведут в какие ЛВС?

    Этот вопрос предполагает, что устройства BOX должны понимать топологию сети и обмениваться по специальному протоколу (BOX-to-BOX) данными о связности.

    Предлагаемый здесь вариант не требует от BOX знания топологии сети и наличия сведений о наличии других устройств BOX.

Предполагается существование двух проблем — 1) маршрутизация на хостах и 2) маршрутизация в BOX. Предлагается для решения каждой проблемы использовать конкурирующие стратегии и возможность использования частей обеих стратегий при выборе решения.

Например, использовать ARP внутри ЛВС и передавать отклики ARP с устройств BOX, действующих в качестве агентов (схема расширенного ARP), наряду с применением протокола взаимодействия между устройствами BOX для получения информации о местоположении хостов самими устройствами BOX (схема с явными подсетями).

Программный код вовлечен в эту задачу в двух местах — на многочисленных хостах и на небольшом числе устройств BOX. При выборе между схемами с явными подсетями и расширением ARP следует взвешенно оценивать объем работы, выполняемой на хостах и устройствах BOX.

Что делают хосты?

Схема с явными подсетями

Хост должен быть способен решить вопрос о принадлежности адреса IA к его или другой ЛВС. Для адресов из той же сети используется некая процедура для определения адреса HA. Если адрес относится к другой ЛВС выполняется некая процедура получения HA от устройства BOX.

Схема с расширенным ARP

Во всех случаях для получения отображения IA:HA используется ARP.

Что делают устройства BOX?

Схема с явными подсетями

Устройство BOX должно быть способно определить, к какой из ЛВС сайта относится адресат. Устройство BOX должно иметь некую таблицу маршрутизации, которая говорит, через какой интерфейс следует передавать дейтаграммы в каждую ЛВС. Эта таблица маршрутизации должна обновляться тем или иным способом (возможно с помощью протокола типа Internet Gateway-to-Gateway).

Схема с расширенным ARP

Устройство BOX должно сохранять кэш-таблицы с отображениями IA:HA для каждого интерфейса и таблицу поиска. Не требуется использования специальных протоколов (BOX-to-BOX) и даже не нужно знаать о существовании других устройств BOX.

Топология и сложность реализации

Дерево

Если ЛВС и устройства BOX соединены в древовидную структуру, устройства BOX могут быть очень простыми и им не нужно сохранять списков поиска, поскольку в сети нет петель, препятствующих запросам ARP.

Петли

При наличии в сети петель поддержка списков поиска становится важной. Если топология сбалансирована так, что больших петель в сети нет (все петли примерно одного размера) и ЛВС сравнительно близки по параметрам задержки, описанная здесь процедура будет работать хорошо.

Комплексная топология

В сети с комплексной, несбалансированной топологией и смешением разнотипных (по задержкам) ЛВС может оказаться более эффективным использование протокола маршрутизации BOX-to-BOX.

Заключение

Будет хорошо, если сообщество Internet достигнет того или иного соглашения по решению проблемы сетей со множеством ЛВС и настоятельно рекомендует производителям рабочих станций придерживаться этого решения.

Предлагается рассмотреть описанную здесь схему расширенного ARP.

Предполагается, что большая часть рабочих станций подключена к ЛВС с поддержкой широковещания и большинство рабочих станций будет применяться в ситуациях, не требующих явных подсетей, и, кроме того, большинство станций будет применяться там, где возможно использование адресов IP класса C (и явные подсети невозможны). Таким образом, предполагается, что лучше будет попросить производителей включить поддержку ARP на рабочих станциях. Предполагается также, что будут созданы, протестированы и произведены «магические устройства» (magic box), предложенные здесь.

Следует отметить, что ни в данном документе, ни в [1] не предлагается конкретная процедура маршрутизации или протокол BOX-to-BOX. Это обусловлено тем, что задача маршрутизации является весьма сложной. Предложенный здесь план позволяет начать работу в сетях со множеством ЛВС без такого протокола. Если позднее будет принято решение о целесообразности использования процедуры маршрутизации между устройствами BOX, это не потребует вносить какие-либо изменения на хостах.

Глоссарий

ARP

Address Resolution Protocol — протокол преобразования адресов (см. [2]).

BOX

Magic Box — устройство (компьютер), подключенное к множеству ЛВС одной сети. Используется также термин ARP-мост (ARP-based bridge).

Bridge — мост

Узел (компьютер), подключенный к нескольким административно не различаемым, но разделенным физически подсетям, который при необходимости автоматически пересылает дейтаграммы между подсетями, оставаясь невидимым для других хостов. Используется также термин «программный повторитель» (software repeater).

Datagram — дейтаграмма

Коммуникационный блок данных на уровне IP.

Explicit Subnet — явная подсеть

Подсеть, явно идентифицируемая в адресе IA полем номера подсети и, таким образом, видимая другим как в данной сети, так и за ее пределами.

Gateway — шлюз

Узел (компьютер), подключенный к двум или более административно различающимся сетям (подсетям) и пересылающий дейтаграммы между хостами этих сетей.

HA

Аппаратный адрес, используемый в пакетах ЛВС.

Host Number — номер хоста

Адрес хоста в данной сети, выражаемый младшими битами IA.

IA

Адрес протокола IP.

Internet

Множество соединенных между собой сетей IP.

IP

Протокол Internet (см. [3]).

LAN — ЛВС

Локальная вычислительная сеть.

Multi-LAN Network — сеть с множеством ЛВС

Множество ЛВС, соединенных в единую сеть (т. е., использующих общий номер сети). Отдельные ЛВС сети могут быть явными или прозрачными подсетями.

Network — сеть

Единая сеть IP (возможно, разделенная на подсети или состоящая из множества ЛВС), идентифицируемая номером.

Network Number — номер сети

Номер сети IP, задаваемые старшими битами IA.

Packet — пакет

Единица обмена информацией на аппаратном уровне ЛВС.

Subnet — подсеть

Часть сети IP, выделенная логически или физически.

Transparent Subnet — прозрачная подсеть

Подсеть, не идентифицируемая адресом IA и, таким образом, не видимая другим (см. Сети с множеством ЛВС).

TTL

Поле Time-To-Live в заголовке IP.

Литература

[1] J. Mogul, «Internet Subnets», RFC 917, Stanford University, October 1984.

[2] D. Plummer, «An Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48-bit Ethernet Addresses for Transmission on Ethernet Hardware», RFC 826, Symbolics, November 1982.

[3] J. Postel, «Internet Protocol», RFC 791, USC-ISI, September 1981.

Перевод на русский язык

Николай Малых

nmalykh@gmail.com


1В современной терминологии «сети IP». Прим. перев.

2Address Resolution Protocol.

3Очевидная неточность. Реакции, как в случае 1 здесь возникнуть не может, поскольку в сеть, откуда пришел исходный запрос BOX не отправляет своего запроса и, следовательно, не может получить отклика. Прим. перев.

4Явное несоответствие сказанному на предыдущей странице и здравому смыслу. Отправлять запрос в ЛВС, откуда он был принят никакого смысла нет. Прим. перев.

5Time-To-Live — время жизни.