Мы описали схему адресации TCP/IP, в которой каждому ГВМ назначается 32-битовый адрес и сказали, что интернет ведет себя как виртуальная сеть при использовании этих назначенных адресов для посылки и приема пакетов. Мы также рассмотрели несколько физических сетевых технологий и заметили, что две машины в данной физической сети могут взаимодействовать только в том случае, если каждая из них знает физический сетевой адрес другой машины. О чем мы не упоминали, так это о том, как ГВМ или шлюз отображает IP-адрес в корректный физический адрес, когда ему нужно послать пакет по физической сети. Эта глава рассматривает это отображение, показывая, как оно реализуется для двух самых распространенных схем физических адресов.
Рассмотрим две машины А и В, которые присоединены к одной физической сети. Каждая из них имеет назначенный IP-адрес Ia и Ib, а также физический адрес Pa и Pb. Нашей целью является разработка низкоуровневого программного обеспечения, которое скрывало бы физические адреса и позволяло бы программам более высокого уровня работать только с межсетевыми адресами. Тем не менее, в конечном счете взаимодействие реализуется физическими сетями, использующими какую-либо схему физических адресов. Предположим, что машина А хочет послать пакет машине В по физической сети, к которой они обе присоединены, но А знает только межсетевой адрес Ib. Возникает вопрос: как может А отобразить этот адрес в физический адрес Pb ?
Проблема отображения высокоуровневых адресов в физические адреса известна как проблема разрешения адресов и решается несколькими способами. Некоторые связки протоколов хранят на каждой машине таблицы, содержащие пары высокоуровневых и физических адресов. Другие решают проблему, кодируя аппаратные адреса в высокоуровневых адресах. Использование только одного из этих подходов в лучшем случае делает проблему высокоуровневой адресации неудобной. Эта глава рассматривает две технологии для разрешения адресов, используемые протоколами TCP/IP.
Существуют два основных типа физических адресов: характерным представителем первого типа является Ethernet, использующий большие, фиксированные физические адреса, а второго - proNET-10, использующий маленькие легко изменяемые физические адреса. Разрешение адресов трудно для сетей типа Ethernetа, но легко для сетей типа proNET-10. Мы рассмотрим первым легкий случай.
Рассмотрим сеть с маркерным кольцом proNET-10. Как вы помните, из главы 2 мы знаем, что она использует небольшие целые числа в качестве физических адресов и позволяет пользователю выбрать аппаратный адрес при установке платы интерфейса в компьютер. Главной причиной, делающей разрешение адресов легким для сети proNET-10, является то, что раз можно назначать как IP-адреса, так и физические адреса, то можно выбрать их такими, что их части будут совпадать. Обычно при назначении IP-адресов поле идГВМ делается равным 1,2,3 и т.д., а затем при установке сетевого интерфейсного оборудования выбирается физический адрес, совпадающий с полем идГВМ в IP-адресе. Например, можно выбрать физический адрес 3 для машины, имеющей IP-адрес 192.5.48.3, так как 192.5.48.3 является адресом класса С, у которого поле идГВМ равно 3.
Для сетей, таких как proNET-10, вычисление физического адреса на основе IP-адреса тривиально. Вычисление состоит из выделения полу идентификатора ГВМ из IP-адреса. Это вычислительно эффективно, так как требует выполнения нескольких машинных команд. Это легко осуществить, так как может быть выполнено без обращения к внешним данным. И ,наконец, новые машины могут быть добавлены к сети без изменения данных или перекомпиляции кода. Концептуально выбор схемы нумерации, делающей разрешение адресов эффективным, означает выбор функции F, которая отображает IP-адреса в физические адреса. Разработчик может также выбрать схему нумерации физических адресов. Разрешение IP-адреса Ia означает вычисление
Pa=F(Ia)
Мы хотим, чтобы вычисление F было эффективным. Если множество физических адресов ограничено, можно по-другому эффективно сделать это отображение. Например, при использовании X.25 нельзя выбрать физические адреса. Обычно, шлюзы в сетях X.25 хранят пары IP-адресов и физических адресов X.25 в таблице и осуществляют поиск в этой таблице при разрешении IP-адресов. Чтобы сделать разрешение адресов эффективным в таких случаях, программное обеспечение может использовать хэш-функцию для поиска в таблице. Упражнение 5.1 предлагает еще один подход.
Чтобы понять, почему разрешение адресов так трудно в некоторых сетях, рассмотрим технологию Ethernetа. Как вы знаете из главы 2, Ethernet имеет 48-битовые физические адреса, назначаемые производителями при изготовлении интерфейсных плат. Как следствие, при выходе оборудования из строя и замене интерфейсной платы физический адрес машины меняется. Более того, так как адрес в Ethernetе имеет длину 48 бит, не стоит и рассчитывать, что его можно закодировать в 32-битном IP-адресе. Разработчики протоколов TCP/IP нашли конструктивное решение проблемы разрешения адресов для сетей, таких как Chaosnet или Ethernet, которые имеют возможность широковещания. Это решение позволяет добавлять машины к сети без перекомпиляции кода и без создания центральной базы данных. Чтобы избежать создания таблиц отображения разработчики решили использовать низкоуровневый протокол для динамической связки адресов. Названный Протокол Разрешения Адресов(ARP), он обеспечивает механизм, который является как эффективным, так и легким для реализации.
Как показывает рисунок 5.1 , идея, лежащая в основе динамического разрешения в ARP, проста: когда ГВМ А хочет разрешить IP-адрес Ib, он широковещательно распространяет специальный пакет, который просит ГВМ с IP-адресом Ib ответить ему, указав свой физический адрес Pb. Все ГВМ, включая В, получают этот запрос, но только ГВМ В узнает свой IP-адрес и посылает ответ, содержащий свой физический адрес. Когда А получает ответ, он использует физический адрес для посылки межсетевого пакета прямо к В. Итоги всего вышесказанного можно изложить так:
Протокол Разрешения Адресов,ARP, позволяет ГВМ установить физический адрес ГВМ назначения в той же самой физической сети, имея только IP-адрес назначения.
<---|---------------------------------------->
===============|==========|==========|====================
| | | | | | |
| V | V | V |
----- ----- ----- -----
| А | | X | | B | | Y |
| | | | | | | |
----- ----- ----- -----
(а)
---------------------
======|===================|===============================
| | | | | |
| V | | | |
----- ----- ----- -----
| А | | X | | B | | Y |
| | | | | | | |
----- ----- ----- -----
(б)
Рисунок 5.1 Протокол ARP. Чтобы определить физический адрес В, Pb, по его IP-адресу, Ib, (а) ГВМ А широковещательно распространяет запрос ARP, содержащий Ib, по всем машинам, и (б) ГВМ В отвечает на него ответом ARP, содержащим пару (Ib,Pb).
Может показаться глупым то, что А, посылая пакет к В, сначала посылает широковещательный пакет, который достигает В. Или может показаться еще глупее, что А широковещательно задает вопрос:"Как я могу связаться с вами?" вместо того, чтобы просто широковещательно послать пакет, который он хочет передать. Но есть важная причина для таких передач. Широковещание слишком дорого, чтобы использовать его всякий раз, когда одной машине требуется передать пакет другой машине, так как оно требует от каждой машины в сети обработки широковещательного пакета. Чтобы уменьшить затраты на взаимодействие, ГВМ, использующие ARP, создают кэш недавно узнанных связок между физическим адресом и IP-адресом, и поэтому они не должны повторно использовать ARP. Всякий раз, когда ГВМ получает ответ ARP, он сохраняет IP-адрес машины и соответствующий ему аппаратный адрес в своем кэше для последующих обращений. При передаче пакета ГВМ ищет связку в кэше перед тем, как послать запрос ARP. Если ГВМ нашел нужную связку в своем кэше, ему не надо передавать широковещательный пакет в сеть. Опыт показывает, что так как большинство сетевых взаимодействий включает передачу более чем одного пакета, даже небольшой кэш будет полезен.
Можно сделать несколько уточнений ARP. Во-первых, заметим, что если ГВМ А использует ARP, так как ему нужно послать запрос к В, то существует большая вероятность того, что ГВМ В в ближайшем будущем тоже потребуется послать пакеты к А. Если мы учтем потребности В, мы можем избежать передачи лишнего траффика по сети, заставив А включить связку своего IP-адреса с физическим в пакет при посылке запроса к В. Во-вторых, отметим, что так как А широковещательно передает свой начальный запрос, все машины в сети получают его и могут выделить и сохранить в своих кэшах связку между IP-адресом и физическим адресом для А. В-третьих, когда новая машина появляется в сети(например, когда загружается операционная система), мы можем избежать того, что какая-либо другая машина будет запускать ARP, если широковещательно распространим пару IP-адреса и физического адреса новой машины. Следующее правило обобщает уточнения:
ARP - это низкоуровневый протокол, который скрывает базовую физическую сетевую адресацию, позволяя назначать IP-адреса по нашему выбору каждой машине. Мы будем думать о нем как о части физической сетевой системы, а не как о части межсетевых протоколов.
Функционально ARP состоит из двух частей. Одна часть определяет физические адреса при посылке пакета, а другая отвечает на запросы от других машин. Разрешение адресов для выходящих пакетов кажется элементарным, но некоторые детали усложняют реализацию. Получив IP-адрес назначения, ГВМ просматривает кэш ARP, чтобы проверить, не знает ли он уже физического адреса для этого IP-адреса. Если ГВМ знает его, он выделяет физический адрес, помещает данные в кадр, используя этот адрес, и посылает этот кадр. Если же он не знает отображения, он должен широковещательно передать запрос ARP и ждать ответа. Широковещание запроса ARP для нахождения отображения адреса может оказаться сложным. Машина получателя может быть выключена или быть слишком занята, чтобы принять запрос. Если такое случится, отправитель может не получить ответа или ответ может задержаться. Так как Ethernet является системой с негарантированной доставкой, то исходный широковещательный запрос ARP тоже может быть потерян(в этом случае отправитель должен будет повторно отправлять его по крайней мере еще один раз). Между тем ГВМ должен хранить исходный передаваемый пакет, чтобы его можно было послать, когда будет разрешен адрес(если задержка становится значительной, ГВМ может уничтожить передаваемый пакет). Фактически, ГВМ должен решить, можно ли работать другим прикладным программам, пока он обрабатывает запрос ARP(в большинстве случаев можно). Если можно, то он должен учитывать случай, когда приложение будет генерировать дополнительные запросы ARP для того же адреса, не посылая широковещательный запрос несколько раз для одного и того же получателя.
Наконец, рассмотрим случай, когда машина А получила связку для машины В, но оборудование В вышло из строя и было заменено. Хотя адрес В изменился, не изменилась связка в кэше А, поэтому А будет использовать несуществующий аппаратный адрес, делая успешный прием невозможным. Этот случай показывает, почему важно, чтобы программное обеспечение ARP рассматривало свою таблицу связок как кэш и удаляло ее элементы по истечении фиксированного промежутка времени. Конечно, таймер для каждого элемента кэша должен сбрасываться всякий раз, когда принимается широковещание ARP, содержащее эту связку(но не сбрасывается, когда этот элемент, используется для посылки пакета).
Вторая часть кода ARP обрабатывает пакеты ARP, прибывающие из сети. Когда появляется пакет ARP, это программное обеспечение должно выделить пару IP-адреса и аппаратного адреса отправителя, и проверить свой кэш на наличие в нем элемента для этого отправителя. Если в кэше есть элемент для указанного IP-адреса, обработчик обновит этот элемент, заменив физический адрес тем, что получен из пакета. Получатель затем обрабатывает оставшуюся часть пакета ARP.
Получатель должен обрабатывать два типа входящих пакетов ARP. Если входящий пакет ARP - запрос, принимающая машина должна проверить, не является ли она назначением для этого запроса(т.е. какая-то другая машина широковещательно выдала запрос о физическом адресе приемника). Если это так, то программное обеспечение ARP формирует ответ, указывая в нем свой физический адрес, и посылает ответ прямо тому, кто запрашивал. Получатель также добавляет пару адресов отправителя к своему кэшу, если там нет такой пары. если IP-адрес, указанный в запросе ARP, не совпадает с локальным адресом IP, то этот пакет является запросом на отображение между адресами для какой-то другой машины в сети и может игнорироваться.
Другой интересный случай возникает, когда приходит ответ ARP. В зависимости от реализации обработчику может понадобиться создание элемента кэша или такой элемент может уже существовать. В любом случае, как только кэш был обновлен, получатель пытается сопоставить ответ ранее выданному запросу. Обычно ответу соответствует запрос, сгенерированный в связи с тем, что машина имеет пакет, который нужно доставить. В промежуток времени между широковещательной передачей ARP-запроса и получением ответа прикладные программы или высокоуровневые протоколы могли сгенерировать дополнительные запросы для этого адреса; программное обеспечение должно помнить, что оно уже послало запрос и не посылать его больше. Обычно, оно помещает дополнительные запросы в очередь. Как только пришел ответ и физический адрес стал известен, программное обеспечение ARP удаляет элементы из очереди и отвечает на каждый из них полученной связкой. Если машина не выдавала запрос для IP-адреса, указанного в ответе, она прекращает обработку этого пакета.
Когда сообщения ARP пересылаются от одной машины к другой, они должны передаваться в физических кадрах. Рисунок 5.2 показывает, что сообщение ARP передается как поле данных кадра.
-------------------------------------
| сообщение ARP |
-------------------------------------
| |
V V
-----------------------------------------------------------
| заголовок кадра | поле данных кадра |
-----------------------------------------------------------
Рисунок 5.2 Сообщение ARP, заключенное в кадре физической сети
Чтобы идентифицировать, что кадр содержит запрос или ответ ARP, отправитель присваивает специальное значение полю типа в заголовке кадра и помещает сообщение ARP в поле данных кадра. Когда кадр прибывает на ГВМ, система смотрит тип кадра, чтобы определить его содержимое. Например, в Ethernete, кадры, несущие сообщения ARP, имеют в поле типа значение 0806 в шестнадцатиричном формате. Это стандартное значение, назначенное ведомством, устанавливающим стандарты Ethernetа.
В отличие от большинства протоколов, данные в пакетах ARP не имеют фиксированного формата заголовка. Вместо этого его сообщения были разработаны так, чтобы их можно было использовать для различных сетевых технологий. Поэтому, первые поля заголовка содержат счетчики, которые указывают длину следующих полей. Фактически, ARP можно использовать с произвольными физическими адресами и произвольными протокольными адресами. Пример на рисунке 5.3 показывает 28-октетный формат сообщения ARP, используемый для оборудования Ethernetа(у которого физические адреса являются 48-битовыми или 6-октетными) при разрешении протокольных адресов IP(имеющих длину 4 октета).
Рисунок 5.3 показывает сообщение ARP по 4 байта в строке, в формате, который будет стандартным на протяжении всей книги. К сожалению, в отличие от большинства остальных протоколов, поля переменной длины в пакетах ARP не выровнены на границу 32 бит, что приводит к трудности восприятия диаграммы. Например, аппаратный адрес отправителя, помеченный как ОТПРАВИТЕЛЬ АА, занимает 6 непрерывных октетов, что приводит к появлению его на двух строках диаграммы.
0 8 16 24 31 ----------------------------------------------------------- | ТИП ОБОРУДОВАНИЯ | ТИП ПРОТОКОЛА | ----------------------------------------------------------- | HLEN | PLEN | ОПЕРАЦИЯ | ----------------------------------------------------------- | ОТПРАВИТЕЛЬ АА (октеты 0-3) | ----------------------------------------------------------- |ОТПРАВИТЕЛЬ АА(октеты 4-5)|ОТПРАВИТЕЛЬ IP(октеты 0-1) | ----------------------------------------------------------- |ОТПРАВИТЕЛЬ IP(октеты 2-3)|ПОЛУЧАТЕЛЬ АА(октеты 0-1) | ----------------------------------------------------------- | ПОЛУЧАТЕЛЬ АА(октеты 2-5) | ----------------------------------------------------------- | ПОЛУЧАТЕЛЬ IP(октеты 0-3) | -----------------------------------------------------------
Рисунок 5.3 Пример формата сообщения ARP/RARP для разрешения адресов IP-Ethernet. Длины полей зависят от длин аппаратных и протокольных адресов, которые имеют значение соответственно 6 октетов для адреса Ethernetа и 4 октета для IP-адреса.
Поле ТИП ОБОРУДОВАНИЯ определяет тип аппаратного интерфейса, для которого отправитель ищет ответ; оно содержит значение 1 для Ethernetа. Аналогичным образом, поле ТИП ПРОТОКОЛА указывает тип адреса протокола более высокого уровня, который использует отправитель; оно содержит 0800 в шестнадцатиричном формате для IP-адреса. Поле ОПЕРАЦИЯ указывает запрос ARP(1), ответ ARP(2), запрос RARP(3), или ответ RARP(4)(RARP, другой протокол, использующий тот же самый формат сообщения, будет рассмотрен в следующей главе). Поля HLEN и PLEN позволяют использовать ARP в любых сетях, так как они указывают длину аппаратного адреса и адреса протокола верхнего уровня. Отправитель передает свой аппаратный адрес и IP-адрес, если они известны ему, в полях ОТПРАВИТЕЛЬ АА и ОТПРАВИТЕЛЬ IP.
При посылке запроса отправитель также указывает IP-адреса назначения(ARP) или аппаратного адреса назначения(RARP), используя поля ПОЛУЧАТЕЛЬ АА и ПОЛУЧАТЕЛЬ IP. Отвечающая машина перед передачей ответа заполняет отсутствующие адреса, меняет местами пары отправителя и получателя и меняет код операции на ответ. Поэтому ответ содержит IP- и аппаратный адреса исходного отправителя, а также IP- и аппаратный адреса машины, которая разрешила эту связку.
IP-адреса назначаются независимо от физического аппаратного адреса машины. Чтобы доставить межсетевой пакет, сетевое программное обеспечение должно отобразить IP-адрес в физический аппаратный адрес и использовать этот аппаратный адрес для передачи кадра. Если аппаратные адреса являются небольшими числами, которые могут быть легко изменены, можно реализовать прямое отображение, закодировав физические адреса машин в их IP-адресах. Иначе, отображение должно выполняться динамически. Протокол Разрешения Адресов(ARP) выполняет динамическое разрешение адресов, используя только низкоуровневую сетевую коммуникационную систему. ARP позволяет машинам разрешать адреса, не храня постоянно информации о связках адресов.
Машина использует ARP, чтобы найти аппаратный адрес другой машины с помощью широковещания запроса ARP. Запрос содержит IP-адрес машины, для которой нужно узнать аппаратный адрес. Каждая машина отвечает на запросы, соответствующие ее IP-адресу, посылая ответы, содержащие требуемый аппаратный адрес. Чтобы сделать ARP эффективным, каждая машина кэширует связки (IP-адрес;аппаратный адрес). Так как межсетевой траффик имеет тенденцию состоять из последовательности взаимодействий между парами машин, кэш приводит к ненужности большинства широковещательных запросов ARP.
Протокол разрешения адресов, использованный здесь, описан Plumer[RFC 826] и стал стандартным межсетевым протоколом. Dalal и Printis[1981] описывают связь между адресами IP и Ethernetа, а Clark[RFC 814] обсуждает адреса и связки в общем. Parr[RFC 1029] рассматривает разрешение адресов, устойчивое к ошибкам. Документ Межсетевые Номера[RFC 1010] указывает значения, используемые для идентификации сетевых кадров. Comer[1987] представляет пример реализации ARP для операционной системы Xinu.
5.1 Вам задано небольшое множество физических адресов(положительных целых чисел). Найдите функцию F и назначения для IP-адресов, такие, что F отображает однозначно IP-адреса в физические адреса и вычисление F эффективно. 5.2 В каком особом случае ГВМ, присоединенному к Ethernetу, не надо использовать ARP , или кэш ARP перед передачей дейтаграммы IP ?
5.3 Один известный алгоритм управления кэшем ARP заменяет элемент, не использовавшийся самое долгое время, при добавлении нового. При каких условиях этот алгоритм может приводить к генерации избыточного траффика ?
5.4 Должен ли ARP обновлять кэш, если для заданного IP-адреса уже существует элемент ? Почему да или почему нет ?
5.5 Должен ли ARP модифицировать кэш даже в том случае, когда он получает информацию, которую он не запрашивал ? Почему да или почему нет ?
5.6 Любая реализация ARP, использующая кэш фиксированного размера, может аварийно завершиться, если используется в сети, имеющей много ГВМ и много траффика ARP. Объясните почему.
5.7 ARP часто считается слабым в отношении секретности. Объясните почему.
5.8 Объясните, что может произойти, если поле аппаратного адреса в запросе ARP разрушится при передаче по сети. Замечание: реализации ARP обычно не удаляют элементы кэша, если они часто используются.
5.9 Предположим, что машина С приняла запрос ARP, посланный от А к машине В, и предположим, что С имеет связку для Ib в своем кэше. Следует ли С отвечать на этот запрос ? Объясните.
5.10 Как может рабочая станция использовать ARP при своей загрузке для того, чтобы установить, нет ли в сети какой-либо другой машины с таким же адресом ? Каковы недостатки этой схемы ?
Назад | Содержание | Вперед