глава 3 ip: протокол internet

ip это рабочая лошадь семейства протоколов tcp/ip. tcp, udp, icmp и igmp передают свои данные как ip датаграммы (рисунок 1.4). один факт часто удивляет новичков tcp/ip, особенно тех кто работал с x.25 или sna, этот факт заключается в том, что ip ненадежный протокол, предоставляющий сервис доставки датаграмм без соединения.

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

термин без соединения (connectionless) означает, что ip не содержит никакой информации о продвижении датаграмм. каждая датаграмма обрабатывается независимо от других. это также означает, что может быть доставлена испорченная датаграмма. если источник отправляет две последовательные датаграммы (первая a, затем b) в один и то же пункт назначения, каждая из них маршрутизируется независимо и может пройти по разным маршрутам, датаграмма b может прибыть раньше чем a.

в этой главе мы кратко рассмотрим поля ip заголовка, опишем ip маршрутизацию и коротко опишем разделение на подсети. также мы рассмотрим две очень полезные команды: ifconfig и netstat. более подробно некоторые поля ip заголовка будут описаны в следующих главах. именно тогда мы точно расскажем, как используются те или иные поля. rfc 791 [postel 1981a] является официальной спецификацией для ip.

на рисунке 3.1 показан формат ip датаграммы. стандартный размер ip заголовка составляет 20 байт, если не присутствуют опции.

рисунок 3.1 ip датаграмма, поля ip заголовка.

мы покажем как выглядят заголовки протоколов tcp/ip на рисунке 3.1. старший значащий бит имеет номер 0 (слева), а младший значащий бит из 32-х бит имеет номер 31 и показан справа.

4 байта из 32-битного значения передаются в следующем порядке: сначала биты 0 - 7, затем биты 8 - 15, затем 16 - 23 и, наконец, 24 - 31. такой порядок движения байтов называется big endian (примечание переводчика: big endian - метод хранения или передачи данных, при котором старший значащий бит или байт стоит первым) и обязателен для всех двоичных целых чисел в tcp заголовках при их передаче по сети. это называется порядок сетевых байтов (network byte order). машины, которые хранят двоичные целые в других форматах, как например в формате little endian (little endian - метод хранения или передачи данных, при котором младший значащий бит или байт стоит первым), должны конвертировать значения заголовков в соответствующий порядок сетевых байтов перед передачей данных.

текущая версия протокола - 4, поэтому ip иногда называется ipv4. в разделе "будущее ip" рассматриваются некоторые предложения для новых версий ip.

длина заголовка (header length) это количество 32-битных слов в заголовке, включая любые опции. так как это 4-битное поле, оно ограничивает размер заголовка в 60 байт. в главе 8 мы увидим, что это ограничение сильно влияет на некоторые опции, такие как опция записи маршрута. обычная величина в этом поле (когда отсутствуют опции) - 5.

поле типа сервиса (tos - type-of-service) состоит из 3-битного поля приставки (которое в настоящее время игнорируется), 4 бит tos и неиспользуемого бита, который должен быть равен 0. 4 бита tos следующие: минимальная задержка, максимальная пропускная способность, максимальная надежность и минимальная стоимость. только один из этих 4 бит может быть установлен в единицу одновременно. если все 4 бита равны 0, это означает обычный сервис. rfc 1340 [reynolds and postel 1992] указывает, как эти биты должны быть установлены для всех стандартных приложений. rfc 1349 [almquist 1992] содержит некоторые коррекции для этого rfc и более детальное описание характеристики tos.

на рисунке 3.2 показаны рекомендованные значения поля tos для различных приложений. в последней колонке приведено шестнадцатиричное значение, которое мы увидим в выводе tcpdump позже в этой главе.

рисунок 3.2 рекомендованные значения поля типа сервиса (tos).

диалоговые приложения, telnet и rlogin, требуют свести к минимуму задержку, так как они используются человеком интерактивно и осуществляют небольшую передачу данных. передача файлов с использованием ftp, с другой стороны, требует максимальной пропускной способности. максимальная надежность необходима для сетевого управления (snmp) и для протоколов маршрутизации. новости usenet (nntp) это единственное приложение, которое требует минимизации стоимости.

характеристика tos, в настоящее время, большинством реализаций tcp/ip не поддерживается, однако она включена в новые системы, начиная с 4.3bsd reno. некоторые протоколы маршрутизации, такие как ospf и is-is, имеют возможность принимать решение о маршрутизации на основе этого поля.

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

поле полной длины (total length) содержит полную длину ip датаграммы в байтах. благодаря этому полю и полю длины заголовка, мы знаем, с какого места начинаются данные в ip датаграмме и их длину. так как это поле состоит из 16 бит, максимальный размер ip датаграммы составляет 65535 байт. (обратитесь к рисунку 2.5 и обратите внимание, что hyperchannel имеет mtu, равный 65535. в действительности это не mtu - здесь используется максимально возможный размер ip датаграммы). это поле изменяется в момент фрагментации и повторной сборки датаграммы, что будет описано в разделе "фрагментация ip" главы 11.

несмотря на то что существует возможность отправить датаграмму размером 65535 байт, большинство канальных уровней поделят подобную датаграмму на фрагменты. более того, от хоста не требуется принимать датаграмму размером больше чем 576 байт. tcp делит пользовательские данные на части, поэтому это ограничение обычно не оказывает влияния на tcp. что касается udp, услугами которого пользуются многие приложения (rip, tftp, bootp, dns, snmp), то он ограничивает себя 512 байтами пользовательских данных, что даже меньше ограничения в 576 байт. большинство приложений в настоящее время (особенно те, которые поддерживают nfs - network file system) позволяют использовать ip датаграмму размером 8192 байта.

однако, поле полной длины требуется в ip заголовке для некоторых каналов (как например, ethernet), который дополняет маленькие фреймы до минимальной длины. несмотря на то что минимальный размер фрейма ethernet составляет 46 байт (рисунок 2.1), ip датаграмма может быть еще меньше. если поле полной длины не было представлено, ip уровень не будет знать, сколько 46-байтных фреймов ethernet получится из ip датаграммы.

поле идентификации (identification) уникально идентифицирует каждую датаграмму, отправленную хостом. значение, хранящееся в поле, обычно увеличивается на единицу с посылкой каждой датаграммы. мы обратимся к этому полю, когда будем рассматривать фрагментацию и обратную сборку в разделе "фрагментация ip" главы 11. там же мы рассмотрим поле флагов (flags) и поле смещения фрагментации (fragmentation offset).

rfc 791 [postel 1981a] сообщает, что поле идентификации должно быть выбрано верхним уровнем, который отправляет ip датаграммы, а это означает, что две последовательно отправленные ip датаграммы, одна из которых сгенерирована tcp, а другая - udp, должны иметь одно и то же поле идентификации. подобный подход работает (алгоритм сборки может обработать такую ситуацию). однако, большинство реализаций, произошедших от berkeley, увеличивают соответствующую переменную в ядре ip уровня каждый раз, когда отправляется ip датаграмма, вне зависимости от того какой уровень отправляет данные через ip. переменная ядра инициируется каждый раз в момент загрузки системы.

поле времени жизни (ttl - time-to-live) содержит максимальное количество пересылок (маршутизаторов), через которые может пройти датаграмма. это поле ограничивает время жизни датаграммы. значение устанавливается отправителем (как правило 32 или 64) и уменьшается на единицу каждым маршрутизатором, который обрабатывает датаграмму. когда значение в поле достигает 0, датаграмма удаляется, а отправитель уведомляется об этом с помощью icmp сообщения. подобный алгоритм предотвращает зацикливание пакетов в петлях маршрутизации. мы вернемся к этому полю в главе 8, когда будем рассматривать программу traceroute.

мы говорили о поле протокола (protocol) в главе 1 и показали на рисунке 1.8 как оно используется в ip для демультиплексирования входящих датаграмм. это поле указывает, какой протокол отправил данные через ip.

контрольная сумма заголовка (header checksum) рассчитывается только для ip заголовка. она не включает в себя данные, которые следуют за заголовком. icmp, igmp, udp и tcp имеют контрольные суммы в своих собственных заголовках, которые охватывают их заголовки и данные.

чтобы рассчитать контрольную сумму ip для исходящей датаграммы, поле контрольной суммы сначала устанавливается в 0. затем рассчитывается 16-битная сумма с поразрядным дополнением (one's complement - поразрядное дополнение к двоичной системе.) (заголовок целиком воспринимается как последовательность 16-битных слов). 16-битное поразрядное дополнение этой суммы сохраняется в поле контрольной суммы. когда ip датаграмма принимается, вычисляется 16-битная сумма с поразрядным дополнением. так как контрольная сумма, рассчитанная приемником, содержит в себе контрольную сумму, сохраненную отправителем, контрольная сумма приемника состоит из битов равных 1, если в заголовке ничего не было изменено при передаче. если в результате не получились все единичные биты (ошибка контрольной суммы), ip отбрасывает принятую датаграмму. сообщение об ошибке не генерируется. теперь задача верхних уровней каким-либо образом определить, что датаграмма отсутствует, и обеспечить повторную передачу.

icmp, igmp, udp и tcp используют такой же алгоритм расчета контрольной суммы. также tcp и udp включают в себя различные поля из ip заголовка, в дополнение к своим собственным заголовкам и данным. rfc 1071 [braden, borman, and partridge 1988] описывает технику и реализацию расчета контрольной суммы internet. так как маршрутизаторы обычно изменяют только поле ttl (уменьшают его значение на единицу), маршрутизатор может просто увеличить на единицу контрольную сумму, когда он перенаправляет полученную датаграмму, вместо того чтобы рассчитывать контрольную сумму заново для ip заголовка в целом. rfc 1141 [mallory and kullberg 1990] описывает как этого можно добиться.

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

каждая ip датаграмма содержит ip адрес источника (source ip address) и ip адрес назначения (destination ip address). это 32-битные значения, которые мы описали в разделе "адресация internet" главы 1.

и последнее поле - поле опций (options), это список дополнительной информации переменной длины. в настоящее время опции определены следующим образом:

• безопасность и обработка ограничений (для военных приложений, описано в rfc 1108 [kent 1991]),
• запись маршрута (запись каждого маршрута и его ip адрес, глава 7, раздел "опция записи ip маршрута"),
• временная марка (запись каждого маршрута, его ip адрес и время, глава 7, раздел "ip опция временной марки"),
• свободная маршрутизация от источника (указывает список ip адресов, через которые должна пройти датаграмма, глава 8, раздел "опция ip маршрутизации от источника"), и
• жесткая маршрутизация от источника (то же самое, что и в предыдущем пункте, однако ip датаграмма должна пройти только через указанные в списке адреса, глава 8, раздел "опция ip маршрутизации от источника").

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

поле опций всегда ограничено 32 битами. байты заполнения, значение которых равно 0, добавляются по необходимости. благодаря этому ip заголовок всегда кратен 32 битам (как это требуется для поля длины заголовка).

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

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

в соответствии с общей схемой, ip может получать датаграммы от собственных уровней tcp, udp, icmp и igmp (это датаграммы, формирующиеся здесь же), которые необходимо отправить, однако датаграммы могут быть приняты с какого-либо сетевого интерфейса (эти датаграммы должны быть перенаправлены). ip уровень имеет в памяти таблицу маршрутизации, которую он просматривает каждый раз при получении датаграммы, которую необходимо перенаправить. когда датаграмма принята с сетевого интерфейса, ip, во-первых, проверяет, не принадлежит ли ему указанный ip адрес назначения или не является ли этот ip адрес широковещательным. если это так, то датаграмма доставляется в модуль протокола, указанный в поле протокола в ip заголовке. если датаграмма не предназначается для этого ip уровня (1), если ip уровень был сконфигурирован для того чтобы работать как маршрутизатор, пакет перенаправляется (в этом случае датаграмма обрабатывается как исходящая, что будет описано ниже), иначе (2) датаграмма молча уничтожается.

каждый пункт таблицы маршрутизации содержит следующую информацию:

• ip адрес назначения. это может быть как полный адрес хоста (host address) или адрес сети (network address), что указывается в поле флагов (описывается ниже). адрес хоста имеет ненулевое значение идентификатора хоста (рисунок 1.5) и указывает на один конкретный хост, тогда как адрес сети имеет идентификатор хоста, установленный в 0, и указывает на все хосты, включенные в определенную сеть (ethernet, token ring).
• ip адрес маршрутизатора следующей пересылки (next-hop router), или, иначе говоря, ip адрес непосредственно подключенной сети. маршрутизатор следующей пересылки принадлежит одной из непосредственно подключенных сетей, в которую мы можем отправить датаграммы для их доставки. маршрутизатор следующей пересылки это не конечный пункт назначения, однако он принимает датаграммы, которые мы посылаем, и перенаправляет их в направлении конечного пункта.
• флаги. один флаг указывает, является ли ip адрес пункта назначения, адресом сети или адресом хоста. другой флаг указывает на то, является ли маршрутизатор следующей пересылки действительно маршрутизатором или это непосредственно подключенный интерфейс (мы опишем эти флаги в разделе "принципы маршрутизации" главы 9).
• указание на то, на какой сетевой интерфейс должны быть переданы датаграммы для передачи.

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

ip маршрутизация осуществляет следующие действия:

1. осуществляется поиск в таблице маршрутизации, при этом ищется пункт, который совпадет с полным адресом пункта назначения (должен совпасть идентификатор сети и идентификатор хоста). если пункт найден в таблице маршрутизации, пакет посылается на указанный маршрутизатор следующей пересылки или на непосредственно подключенный интерфейс (в зависимости от поля флагов). как правило, так определяются каналы точка-точка, при этом другой конец такого канала, как правило, является полным ip адресом удаленного хоста.
2. осуществляется поиск в таблице маршрутизации пункта, который совпадет, как минимум, с идентификатором сети назначения. если пункт найден, пакет посылается на указанный маршрутизатор следующей пересылки или на непосредственно подключенный интерфейс (в зависимости от поля флагов). маршрутизация ко всем хостам, находящимся в сети назначения, осуществляется с использованием этого единственного пункта таблицы маршрутизации. например, все хосты локальной сети ethernet представляются в таблицах маршрутизации именно таким образом. эта проверка совпадения идентификатора сети осуществляется с использованием возможной маски подсети, которую мы опишем в следующем разделе.
3. в таблице маршрутизации ищется пункт, помеченный "по умолчанию" (default). если пункт найден, пакет отсылается на указанный маршрутизатор по умолчанию.

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

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

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

для начала представим себе простой пример: хост bsdi имеет ip датаграмму, которую необходимо послать на хост sun. оба хоста находятся в одной и той же сети ethernet (рисунок находится на внутренней стороне обложки). на рисунке 3.3 показан процесс доставки датаграммы.

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

датаграмма передается в драйвер устройства ethernet и посылается на sun в виде ethernet фрейма (рисунок 2.1). адрес назначения в ip датаграмме это ip адрес sun (140.252.13.33), а адрес назначения в заголовке канального уровня это 48-битовый ethernet адрес интерфейса ethernet машины sun. 48-битный ethernet адрес получается с использованием arp, как это делается - мы увидим в следующей главе.

рисунок 3.3 доставка ip датаграммы от bsdi к sun.

рассмотрим еще один пример: bsdi имеет ip датаграмму, которую необходимо послать на хост ftp.uu.net, ip адрес которого 192.48.96.9. на рисунке 3.4 показан путь датаграммы через первые три маршрутизатора. bsdi просматривает свою таблицу маршрутизации, однако не находит совпадающий хост или совпадающую сеть. он использует пункт таблицы маршрутизации по умолчанию, в соответствии с которым необходимо послать датаграмму на sun, который является маршрутизатором следующей пересылки. когда датаграмма передается от bsdi к sun, ip адрес для нее это конечный адрес назначения (192.48.96.9), однако адрес канального уровня - это 48-битный ethernet адрес интерфейса ethernet машины sun. сравните эту датаграмму с одной из показанных на рисунке 3.3, где ip адрес назначения и адрес назначения канального уровня указывают на один и тот же хост (sun).

когда sun получает датаграмму, он понимает, что ip адрес назначения этой датаграммы не его собственный, и если sun сконфигурирован для того чтобы выполнять функции маршрутизатора, он перенаправляет датаграмму. происходит просмотр его таблицы маршрутизации, в результате чего выбирается пункт по умолчанию. из этого пункта следует, что sun должен перенаправить датаграмму на маршрутизатор следующей пересылки - netb, ip адрес которого 140.252.1.183. датаграмма пересылается по slip каналу точка-точка с использованием минимальной инкапсуляции, показанной на рисунке 2.2. мы не показываем заголовок канального уровня, как в случае с ethernet, потому что его нет в случае slip канала.

когда netb получает датаграмму, он осуществляет те же самые шаги, которые только что осуществил sun: датаграмма не предназначается какому-либо из его ip адресов, а так как netb сконфигурирован так, чтобы выполнять функции маршрутизатора, он перенаправляет датаграмму. в данном случае также используется пункт таблицы маршрутизации по умолчанию, при этом датаграмма посылается на маршрутизатор следующей пересылки gateway (140.252.1.4). с использованием arp в сети ethernet 140.252.1, netb получает 48-битный ethernet адрес соответствующий адресу 140.252.1.4. именно этот ethernet адрес становится адресом назначения в заголовке канального уровня.

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

из приведенного примера можно сделать несколько важных выводов.

1. все хосты и маршрутизаторы в данном примере используют маршрут по умолчанию.
2. ip адрес назначения датаграммы никогда не меняется. (в разделе "опция ip маршрутизации от источника" главы 8 мы увидим, что это не всегда верно, если используется маршрутизация от источника, что бывает довольно редко.) все решения о маршрутизации основываются на этом адресе назначения.
3. для каждого канала могут быть использованы различные заголовки канального уровня, а адрес назначения канального уровня (если присутствует) всегда содержит адрес маршрутизатора следующей пересылки. в нашем примере датаграммы, инкапсулированные во фреймы канального уровня, содержали ethernet адрес следующей пересылки, однако slip не содержал. адреса ethernet обычно получаются с использованием arp.

в настоящее время существует требование, чтобы все хосты поддерживали адресацию подсетей (rfc 950 [mogul and postel 1985]). теперь ip адрес не делится просто на идентификатор сети и идентификатор хоста: идентификатор хоста делится на идентификатор подсети и идентификатор хоста.

в сетях класса a и в сетях класса b адреса отводится слишком много бит на идентификатор хоста: 2²⁴ - 2 и 2¹⁶ - 2 соответственно. как правило, такое количество хостов не подключается к одной сети. (на рисунке 1.5 показан формат ip адресов сетей различных классов сетей.) в данном случае вычитается 2, потому что идентификатор хоста из всех нулевых битов или всех единичных битов не используется.

после получения от internic идентификатора сети определенного класса, системный администратор решает, делить ли сеть на подсети или нет, а если делить, то сколько бит будет отведено на идентификатор подсети и сколько на идентификатор хоста. например, сети, описываемые в этом тексте, имеют адреса класса в (140.252), а из оставшихся 16 бит 8 отводятся под идентификатор подсети, а 8 на идентификатор хоста. это показано на рисунке 3.5.

рисунок 3.5 разделение на подсети адреса класса b.

подобное разделение позволяет создать 254 подсети по 254 хоста в каждой.

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

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

разделение на подсети скрывает детали внутренней организации сети от внешних маршрутизаторов. в нашем примере, все ip адреса имеют идентификатор сети класса в - 140.252, однако в ней существует более чем 30 подсетей и более чем 400 хостов, распределенных по этим подсетям. один маршрутизатор обеспечивает подключение к internet, как показано на рисунке 3.6.

на этом рисунке мы пометили большинство маршрутизаторов как rn, где n это номер подсети. мы показали маршрутизаторы, которые соединяют эти подсети вместе с девятью системами, которые показаны на рисунке, находящимся на внутренней стороне обложки. сети ethernet показаны жирными линиями, а каналы точка-точка показаны пунктиром. мы показали не все хосты, находящиеся в различных подсетях. например, более 50 хостов находятся в подсети 140.252.3 и более 100 в подсети 140.252.1.

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

рисунок 3.6 настройки большинства подсетей noao.edu 140.252.

для того чтобы получить доступ к хосту, ip адрес которого начинается с 140.252, внешний маршрутизатор должен всего лишь знать путь к ip адресу 140.252.104.1. это означает, что для доступа ко всем сетям 140.252 необходим только один пункт в таблице маршрутизации, вместо 30-ти пунктов в случае использования 30 адресов класса с. таким образом, деление на подсети уменьшает размер таблиц маршрутизации (в разделе "cidr: бесклассовая маршрутизация между доменами" главы 10 мы рассмотрим новую технологию, которая помогает уменьшить размер таблиц маршрутизации даже если используются адреса класса с).

для того чтобы показать что подсети непрозрачны для маршрутизаторов внутри подсети, обратимся к рисунку 3.6 и представим, что датаграмма прибывает в gateway из internet с адресом назначения 140.252.57.1. маршрутизатор gateway должен знать где находится подсеть 57 и что датаграммы для этой подсети надо посылать в kpno. в свою очередь, kpno должен посылать датаграммы в r55, который пошлет их в r57.

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

в дополнение к ip адресу, хосту также необходимо знать, сколько бит будет использовано в качестве идентификатора подсети и сколько бит будет использовано в качестве идентификатора хоста. это также определяется во время загрузки с использованием маски подсети. маска это 32-битное значение, которое содержит биты, установленные в единицу для идентификатора сети и идентификатора подсети, и биты, установленные в 0 для идентификатора хоста. на рисунке 3.7 показано формирование маски подсети для двух различных разделений адреса класса в. в верхнем примере происходит разделение на хосте noao.edu, как показано на рисунке 3.5, где идентификатор подсети и идентификатор хоста занимают 8 бит. в нижнем примере показано разделение адреса класса в, при этом идентификатор подсети занимает 10 бит, а идентификатор хоста - 6 бит.

рисунок 3.7 пример масок подсетей для двух различных подсетей класса b.

несмотря на то, что ip адреса обычно пишутся в десятичном виде с точками, маски подсети, как правило, пишутся в шестнадцатиричном виде, особенно если разделение происходит не побайтно, а побитно.

после того как хост получил свой ip адрес и маску подсети, он может определить, предназначена ли ip датаграмма для (1) хоста в его собственной подсети, (2) хосту в другой подсети его собственной сети, или (3) хосту в другой сети. зная собственный ip адрес, можно определить, к какому классу он относится: а, в или с (по старшим битам), также можно определить, где проведена граница между идентификатором сети и идентификатором подсети. по маске подсети можно определить где проведена граница между идентификатором подсети и идентификатором хоста.

представьте себе адрес хоста 140.252.1.1 (адрес класса в), и маску подсети - 255.255.255.0 (8 бит на идентификатор подсети и 8 бит на идентификатор хоста).

• если ip адрес назначения 140.252.4.5, мы знаем, что идентификатор сети класса в тот же самый (140.252), однако идентификатор подсети другой (1 и 4). на рисунке 3.8 показано, как происходит сравнение двух ip адресов с использованием маски подсети.
• если ip адрес назначения 140.252.1.22, то идентификатор сети класса в тот же самый (140.252), и идентификатор подсети также тот же самый (1). однако идентификатор хоста другой.
• если ip адрес назначения 192.43.235.6 (адрес класса с), идентификатор сети другой. с этим адресом не может быть произведено дальнейшее сравнение.

рисунок 3.8 сравнение двух подсетей класса в, использующих маски подсети.

в процессе ip маршрутизации, сравнения, подобные этому, делаются все время с использованием двух ip адресов и маски подсети.

в процессе описания подсетей может встретится семь специальных ip адресов (см. рисунок 3.9). на этом рисунке 0 означает поле, состоящее из всех бит, установленных в ноль, -1 означает поле из бит, установленных в единицы, а netid (идентификатор сети), subnetid (идентификатор подсети) и hostid (идентификатор хоста) обозначает соответствующие поля, которые установлены не в единицы и не в нули. пустая колонка идентификатора подсети означает, что адреса не могут быть разбиты на подсети.

рисунок 3.9 специальные ip адреса.

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

первые два пункта в таблице с идентификатором сети, равным 0, могут существовать только как адрес источника во время процедуры инициализации, когда хост определяет свой собственный ip адрес, например, с использованием протокола bootp (глава 16).

в разделе "широковещательные запросы" главы 12 мы рассмотрим четыре типа широковещательных адресов более подробно.

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

сейчас, когда мы описали канальный уровень и ip уровень, мы можем показать команду, которая используется для конфигурирования сетевого интерфейса который используется tcp/ip. команда ifconfig(8) обычно запускается в момент загрузки хоста при конфигурации каждого интерфейса.

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

в следующем примере показаны значения для подсети, описываемой в книге. сравните эти значения с теми, что приведены на рисунке 3.12.

sun % /usr/etc/ifconfig -a опция -a в sunos означает "все интерфейсы" le0: flags=63<up,broadcast, notrailers, running> inet 140.252.13.33 netmask ffffffe0 broadcast 140.252.13.63 sl0: flags=1051<up, pointopoint, running, link0> inet 140.252.1.29 --> 140.252.1.183 netmask ffffff00 lo0: flags=49<up, loopback, running> inet 127.0.0.1 netmask ff000000

интерфейс loopback (глава 2, раздел "интерфейс loopback") воспринимается как сетевой интерфейс. он использует адрес класса a и не позволяет разбивать себя на подсети.

обратите внимание на то, что в ethernet не используется инкапсуляция завершителей (глава 2, раздел "инкапсуляция завершителей") и что ethernet поддерживает широковещательные запросы, тогда как slip канал это канал точка-точка.

флаг link0 для slip интерфейса это опция конфигурирования, которая позволяет осуществлять сжатие slip (cslip, глава 2, раздел "slip с компрессией (cslip)"). еще одна возможная опция это link1, которая включает cslip, если принят сжатый пакет с удаленного конца, и link2, которая позволяет отбрасывать все исходящие пакеты icmp. мы рассмотрим адрес назначения этого slip канала в разделе "уполномоченный агент arp" главы 4.

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

еще один маршрутизатор - bsdi. так как опция -a это характеристика sunos, (bsd релизы не имеют подобной опции) мы должны исполнить ifconfig несколько раз, указывая имя интерфейса в качестве аргумента:

bsdi % /sbin/ifconfig we0 we0: flags=863<up, broadcast, notrailers, running, simplex> inet 140.252.13.35 netmask ffffff00 broadcast 140.252.13.63 bsdi % /sbin/ifconfig sl0 sl0: flags=1011<up, pointopoint, link0> inet 140.252.13.66 --> 140.252.13.65 netmask ffffff00

здесь у интерфейса ethernet мы видим новую опцию (we0): simplex. эта опция из 4.4bsd, которая указывает на то, что интерфейс не может слушать свою собственную передачу. она устанавливается в bsd/386 для всех интерфейсов ethernet. если опция установлена, интерфейс, посылающий фрейм с широковещательным адресом, посылает копию на локальный хост и посылает копию на loopback. (мы покажем пример данной характеристики в разделе "icmp запрос и отклик маски адреса" главы 6.)

на хосте slip конфигурация интерфейса slip примерно такая же, как показано выше для bsdi, за исключением того, что ip адреса на двух концах переставлены местами:

slip % /sbin/ifconfig sl0 sl0: flags=1011<up, pointopoint, link0> inet 140.252.13.65 --> 140.252.13.66 netmask ffffffe0

последний интерфейс - это ethernet на хосте svr4. он аналогичен интерфейсу ethernet, показанному ранее, за исключением того, что версия команды ifconfig в svr4 не печатает флаг running:

svr4 % /usr/sbin/ifconfig emd0 emd0: flags=23<up, broadcast, notrailers> inet 140.252.13.34 netmask ffffffe0 broadcast 140.252.13.63

команда ifconfig обычно поддерживает и другие семейства протоколов (не tcp/ip), а также имеет несколько дополнительных опций. обратитесь к руководству по вашей системе, для того чтобы изучить эту команду более подробно.

команда netstat(1) также предоставляет информацию об интерфейсах системы. флаг -i выдает информацию об интерфейсах, а флаг -n выдает ip адреса вместо имен хостов.

sun % netstat -in name mtu net/dest address ipkts ierrs opkts oerrs collis queue le0 1500 140.252.13.32 140.252.13.33 67719 0 92133 0 1 0 sl0 552 140.252.1.183 140.252.1.29 48035 0 54963 0 0 0 lo0 1536 127.0.0.1 127.0.0.1 15548 0 15548 0 0 0

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

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

у ip существуют три проблемы. все они явились результатом феноменального роста сети internet за последние несколько лет. (обратитесь к упражнению 2 главы 1.)

1. почти половина всех адресов класса в уже распределена. если адреса класса в будут распространяться с такой же скоростью как сейчас, то их запас будет исчерпан где-то в 1995 году.
2. 32-битные адреса в общем случае непригодны для долговременного роста internet.
3. текущая структура маршрутизации не иерархическая, а плоская, при этом на каждую сеть требуется запись в таблицы маршрутизации. по мере роста количества сетей все более распространяются адреса класса с, а также узлы, в которых сосредоточено несколько сетей (вместо адреса класса в), при этом заметен рост таблиц маршрутизации.

бесклассовая маршрутизация между доменами (cidr - classless interdomain routing) призвана разрешить третью проблему, при этом к текущей версии ip будут добавлены некоторые расширения (ip версия 4). мы обсудим это более подробно в разделе "cidr: бесклассовая маршрутизация между доменами" главы 10.

что касается новой версии ip, которую часто называют ipng, было сделано четыре предложения для следующих поколений ip. в майском выпуске ieee network (vol.7, no.3) за 1993 год содержится обзор первых трех предложений вместе с cidr. rfc 1454 [dixon 1993] также сравнивает первые три предложения.

1. простой протокол internet (sip - simple internet protocol) . предлагается минимальный набор изменений к ip, после чего ip будет использовать 64-битные адреса и другой формат заголовка. (первые 4 бита заголовка также содержат номер версии, которые устанавливается в 4.)
2. pip. здесь также используются большие, переменной длины, иерархические адреса с другим форматом заголовка.
3. tuba, что означает tcp и udp с увеличенными адресами (tcp and udp with bigger addresses), основан на osi clnp (сетевой протокол без соединения - connectionless network protocol), протокол osi похожий на ip. он предлагает еще большие адреса: переменной длины, до 20 байт. однако, сlnp это существующий протокол, тогда как sip и pip это всего лишь предложения, более того, clnp уже документирован. rfc 1347 [callon 1992] описывает детали tuba. глава 7 [perlman 1992] содержит сравнение ipv4 и clnp. множество маршрутизаторов уже поддерживают clnp, однако большинство хостов не поддерживают.
4. tp/ix, который описан в rfc 1475 [ullmann 1993]. как и в случае с sip, он использует 64-битные ip адреса, также изменяя tcp и udp заголовки: 32-битный номер порта для обоих протоколов, 64-битный номер последовательности, 64-битный номер подтверждения и 32-битные окна для tcp.

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

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

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

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

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

мы закончили главу, описав возможные изменения, которые могут произойти в протоколах internet при появлении следующего поколения ip.

упражнения

1. должен ли быть адрес интерфейса loopback всегда 127.0.0.1?
2. на рисунке 3.6 определите маршрутизаторы, которые имеют больше двух интерфейсов.
3. в чем отличие маски подсети для адреса класса а с 16 битами для идентификатора подсети и адреса класса в с 8 битами для адреса подсети?
4. прочитайте rfc 1219 [tsuchiya 1991], для того чтобы познакомиться с рекомендуемой технологией назначения идентификаторов подсетей и идентификаторов хостов.
5. можно ли использовать маску подсети 255.255.0.255 для адресов класса а?
6. почему mtu для интерфейса loopback, показанного в разделе "команда netstat", установлен в 1536?
7. семейство протоколов tcp/ip построено на основе уровня ip, который определяет технологию передачи датаграмм по сети. существуют семейства протоколов, которые основаны на применении сетевых технологий, ориентированных на соединения. прочитайте [clark 1988], чтобы найти три преимущества сетей с передачей датаграмм.