Компьютерные сети. 6-е изд.

5.7. Сетевой уровень интернета

Теперь самое время подробно поговорить о сетевом уровне интернета. Но прежде чем перейти к деталям, имеет смысл познакомиться с принципами, которые легли в его основу при разработке и обеспечили его дальнейший успех. В наше время ими все чаще пренебрегают. Между тем эти принципы пронумерованы и включены в документ RFC 1958, который стоит изучить (а разработчики просто обязаны его прочитать и сдать по нему экзамен). Этот документ использует идеи, изложенные в работах Кларка (Clark, 1988) и Зальцера и др. (Saltzer et al., 1984). Ниже мы приведем 10 основных принципов, начиная с самых важных.

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

2. Упрощайте. Если есть сомнения, выбирайте самое простое решение. Уильям Оккам (William Occam) декларировал этот принцип еще в XIV веке (так называемая «Бритва Оккама»). Его можно кратко выразить так: «Борись с излишествами». Если какое-то свойство не является абсолютно необходимым, забудьте о нем, особенно если того же эффекта можно добиться комбинированием уже имеющихся свойств.

3. Всегда делайте четкий выбор. Если есть несколько способов реализации одного и того же, выбирайте только один из них. Увеличение количества способов приведет к проблемам. В стандартах часто можно встретить несколько опций, режимов или параметров лишь потому, что при разработке несколько авторитетных сторон настаивали на своем. Разработчики должны решительно сопротивляться подобным тенденциям. Надо просто уметь говорить «нет».

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

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

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

7. Лучшее — враг хорошего. Очень часто разработчики создают хорошие проекты, но не могут предусмотреть какие-нибудь необычные частные случаи. Не стоит портить то, что в большинстве ситуаций работает нормально. Лучше переложить бремя ответственности за «улучшения» проекта на тех, кто предъявляет свои странные требования.

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

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

10. Помните о производительности и цене. Никто не будет использовать низкопроизводительную или дорогостоящую сеть.

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

Самые крупные магистрали (к которым необходимо подключиться, чтобы получить доступ к остальной части интернета) называются сетями Tier 1 (Tier 1 networks). К ним присоединены провайдеры, обеспечивающие доступ к интернету для домашних пользователей и предприятий, дата-центров и станций колокации с большим числом серверов, а также для региональных сетей (сетей среднего уровня). Центры обработки данных обслуживают большую часть интернет-трафика. К региональным сетям присоединяются другие интернет-провайдеры, LAN многочисленных университетов и компаний, а также прочие периферийные сети. Эта квазииерархическая структура схематично показана на илл. 5.46.

Вся эта конструкция держится благодаря протоколу IP (Internet Protocol). В отличие от большинства ранних протоколов сетевого уровня, IP с самого начала разрабатывался для межсетевого обмена. Его задача — предоставить уровень обслуживания best effort (то есть без гарантий) при передаче пакетов от отправителя к получателю, независимо от того, находятся они в одной сети или нет.

Обмен данными в интернете происходит следующим образом. Транспортный уровень разбивает потоки данных так, чтобы их можно было отправить в виде IP-пакетов. В теории каждый пакет может достигать 64 Кбайт, но на практике он обычно не превышает 1500 байт (укладывается в один фрейм Ethernet). IP-маршрутизаторы передают пакеты по сети, от одного маршрутизатора к другому,

Илл. 5.46. Интернет представляет собой набор соединенных друг с другом сетей

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

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

5.7.1. Протокол IP версии 4

Мы начнем изучение сетевого уровня интернета с формата IPv4-дейтаграмм. Такая дейтаграмма состоит из заголовка и основной части (пользовательских данных). Заголовок содержит фиксированную 20-байтную часть, а также необязательную часть, длина которой варьируется. Формат заголовка показан на илл. 5.47. Биты передаются слева направо и сверху вниз, то есть старший бит поля Version (Версия) идет первым. (Такой порядок байтов называется «от старшего к младшему» («big-endian»). На компьютерах с порядком «от младшего к старшему» («little-endian»), например Intel x86, требуется программное преобразование, как при передаче, так и при приеме.) Сегодня уже совершенно ясно, что для IP лучше было использовать порядок «от младшего к старшему», но на момент создания протокола это было не столь очевидно.

Поле Version содержит версию протокола, к которому принадлежит дейтаграмма. Сейчас в интернете доминирует версия 4, поэтому с нее мы и начали обсуждение IP. Указание версии в начале каждой дейтаграммы позволяет переходить от одной версии к другой в течение долгого времени. На самом деле протокол IPv6 (следующая версия IP) разработан более десяти лет назад, но применять его начинают только сегодня. О нем мы поговорим позже в этом разделе. Широкое распространение протокол IPv6 получит, когда у каждого из почти 231 жителей Китая будет настольный ПК, ноутбук и IP-телефон. Что касается нумерации, то ничего странного в ней нет: в свое время существовал малоизвестный экспериментальный потоковый протокол реального времени IPv5.

Илл. 5.47. Заголовок IPv4

Поскольку длина заголовка является переменной величиной, она указывается в поле IHL и выражается в 32-разрядных словах. Минимальное значение длины — при отсутствии поля Options (Опции) — равно 5. Максимальное значение этого 4-битного поля равно 15, что соответствует заголовку длиной 60 байт; таким образом, максимальный размер поля Options равен 40 байтам. Для некоторых функций, например для записи маршрута, пройденного пакетом, 40 байт недостаточно, и дополнительное поле оказывается бесполезным.

Поле Differentiated services (Дифференцированное обслуживание) — одно из немногих полей, смысл которых с годами слегка изменился. Изначально оно называлось Type of service (Тип службы). Его задача (была и остается) — определять различные классы обслуживания. Возможны разные комбинации надежности и скорости. Для цифрового голосового сигнала скорость доставки важнее точности. При передаче файла, наоборот, отсутствие ошибок важнее быстрой доставки. В поле Type of service 3 бита обозначали приоритет, еще 3 бита показывали, что беспокоит хост больше всего: задержка, пропускная способность или надежность. Никто не знал, что делать со всеми этими битами на маршрутизаторах, поэтому они не использовались в течение многих лет. Когда появилось дифференцированное обслуживание, IETF сдался и нашел этому полю другое применение. Теперь первые 6 бит задают класс обслуживания; о срочном и гарантированном обслуживании мы уже говорили ранее в этой главе. В последние два бита помещаются явные уведомления о перегрузке, которые обсуждались в разделе 5.3.

Поле Total length (Полная длина) содержит длину всей дейтаграммы: заголовок и данные. Максимальная длина дейтаграммы — 65 535 байт. В настоящий момент этого достаточно, однако для будущих сетей могут понадобиться дейтаграммы большего размера.

Поле Identification (Идентификация) позволяет хосту-получателю определить, какому пакету принадлежат принятые им фрагменты. Все фрагменты одного пакета содержат одно и то же значение идентификатора.

Далее идет неиспользуемый бит, что достаточно странно, так как место в IP-заголовке крайне ограниченно. В качестве первоапрельской шутки Белловин (Bellovin, 2003) предложил использовать его для обнаружения вредоносного трафика. Это значительно упростило бы защиту сети: пакеты с таким битом можно было бы просто удалять, зная, что они отправлены злоумышленниками. К сожалению, сетевую безопасность невозможно обеспечить столь простым способом, как бы заманчиво идея ни выглядела.

Затем следуют два однобитных поля, относящиеся к фрагментации. Бит DF означает «Don’t Fragment» («Не фрагментировать»); он запрещает маршрутизатору фрагментировать пакет. Изначально предполагалось, что это поле будет помогать хостам, которые не могут восстановить пакет из фрагментов. Сейчас оно используется при определении путевого значения MTU, которое равно максимальному размеру пакета, передаваемого по пути без фрагментации. Пометив дейтаграмму битом DF, отправитель гарантирует, что либо дейтаграмма дойдет единым блоком, либо отправитель получит сообщение об ошибке.

Бит MF означает «More Fragments» («Дополнительные фрагменты»). Он устанавливается во всех фрагментах, кроме последнего. По этому биту получатель узнает о прибытии последнего фрагмента дейтаграммы.

Поле Fragment offset (Смещение фрагмента) указывает положение фрагмента в исходном пакете. Длина всех фрагментов в байтах, кроме длины последнего фрагмента, должна быть кратной 8. Так как на это поле выделено 13 бит, максимальное количество фрагментов в дейтаграмме равно 8192, что дает максимальную длину пакета вплоть до пределов поля Total length. Поля Identification, MF и Fragment offset используются при реализации схемы фрагментации, описанной в разделе 5.5.6.

Поле TtL, Time to live (Время жизни) представляет собой счетчик, ограничивающий время существования пакета. Изначально предполагалось, что он будет отсчитывать время в секундах. Максимальное значение равнялось 255 с. На каждом маршрутизаторе оно должно было уменьшаться как минимум на единицу плюс время стояния в очереди. Однако на практике отсчитывается количество переходов через маршрутизаторы. Когда значение этого поля достигает нуля, пакет отвергается, а отправителю отсылается пакет с предупреждением. Таким образом удается избежать вечного странствования пакетов, что может произойти, если таблицы маршрутизаторов по какой-либо причине будут повреждены.

Собрав пакет из фрагментов, сетевой уровень должен решить, что с ним делать. Поле Protocol (Протокол) сообщит ему, какому процессу транспортного уровня нужно передать пакет: TCP, UDP или какому-либо другому. Нумерация процессов глобально стандартизирована по всему интернету. Номера протоколов (и некоторые другие) были перечислены в RFC 1700, но теперь они собраны в базе данных по адресу www.iana.org.

Поскольку заголовок содержит важную информацию (в частности, адрес), для ее защиты существует отдельное поле Header checksum (Контрольная сумма заголовка). Алгоритм вычисления суммы просто складывает все 16-разрядные полуслова заголовка по мере их поступления с помощью арифметики дополнительных кодов, а затем использует дополнение результата. Алгоритм предполагает, что контрольная сумма заголовка по прибытии должна быть нулевой. Этот метод полезен для обнаружения ошибок, возникающих во время прохождения пакета по сети. Обратите внимание, что значение поля Header checksum должно подсчитываться заново на каждом транзитном участке, поскольку хотя бы одно поле постоянно меняется (поле Time to live). Для ускорения расчетов применяются некоторые хитрости.

Поля Source address (Адрес отправителя) и Destination address (Адрес получателя) указывают IP-адреса сетевых интерфейсов отправителя и получателя. Интернет-адреса будут обсуждаться в следующем разделе.

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

Тип

Описание

Security

Указывает уровень секретности дейтаграммы

Strict source routing

Задает полный путь следования дейтаграммы

Loose source routing

Задает список маршрутизаторов, которые нельзя миновать

Record route

Требует, чтобы все маршрутизаторы добавляли свой IP-адрес

Timestamp

Требует, чтобы все маршрутизаторы добавляли свой IP-адрес и временную метку

Илл. 5.48. Некоторые типы поля опций IP-дейтаграммы

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

Опция Strict source routing (Строгая маршрутизация от источника) задает полный путь следования дейтаграммы от отправителя до получателя в виде последовательности IP-адресов. Дейтаграмма обязана следовать именно по этому маршруту. Эта опция наиболее полезна потому, что с ее помощью системный администратор может отправить экстренные пакеты в случае повреждения таблиц маршрутизатора или измерить параметры времени и производительности.

Опция Loose source routing (Свободная маршрутизация от источника) требует, чтобы пакет прошел через указанный список маршрутизаторов в заданном порядке, но при этом он может проходить через любые другие маршрутизаторы. Обычно указывается лишь небольшое число маршрутизаторов. Например, чтобы заставить пакет, отправляемый из Лондона в Сидней, двигаться не на восток, а на запад, можно указать IP-адреса маршрутизаторов в Нью-Йорке, Лос-Анджелесе и Гонолулу. Эта опция нужна, когда по политическим или экономическим соображениям пакет должен пересечь определенные страны или, напротив, обойти их.

Опция Record route (Запись маршрута) требует от всех маршрутизаторов на пути следования пакета добавлять свой IP-адрес к полю Options. Это позволяет системным администраторам выявлять ошибки в алгоритмах маршрутизации (к примеру, когда все пакеты, отправляемые из Хьюстона в Даллас, сначала попадают в Токио). Когда появилась сеть ARPANET, пакеты проходили максимум через 9 маршрутизаторов, поэтому 40 байт для этого параметра вполне хватало. Как уже говорилось, сегодня этого недостаточно.

Наконец, опция Timestamp (Временная метка) аналогична Record route, но кроме 32-разрядного IP-адреса каждый маршрутизатор также записывает 32-разрядную запись о текущем времени. Timestamp также применяется в основном для измерения параметров сети.

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

5.7.2. IP-адреса

Определяющим признаком IPv4 является его 32-битный адрес. У каждого хоста и маршрутизатора в интернете есть IP-адрес, который может использоваться в полях Source address и Destination address IP-пакетов. Важно отметить, что IP-адрес на самом деле не имеет отношения к хосту. Он относится к сетевому интерфейсу, поэтому хост, соединенный с двумя сетями, должен иметь два IP-адреса. Однако на практике большинство хостов подключены к одной сети, следовательно, имеют один адрес. Маршрутизаторы, наоборот, обычно имеют несколько интерфейсов, а значит, и несколько IP-адресов.

Префиксы

В отличие от Ethernet-адресов IP-адреса имеют иерархическую организацию. Первая часть 32-битного адреса имеет переменную длину и задает сеть, а последняя указывает на хост. Сетевая часть совпадает для всех хостов одной сети (например, LAN Ethernet). Таким образом, сеть соответствует непрерывному блоку пространства IP-адресов, который называется префиксом (prefix).

IP-адреса обычно записываются в виде четырех десятичных чисел (которые соответствуют отдельным байтам), разделенных точками (dotted decimal notation). Например, шестнадцатеричный адрес 80D00297 записывается как 128.208.2.151. Префикс задается наименьшим IP-адресом в блоке и размером блока. Размер определяется числом битов в сетевой части; оставшиеся биты в части хоста могут варьироваться. Таким образом, размер является степенью двойки. По традиции он пишется после префикса IP-адреса в виде слеша и длины сетевой части в битах. В нашем примере префикс содержит 28 адресов и поэтому для сетевой части отводится 24 бита. Пишется это так: 128.208.2.0/24.

Поскольку длина префикса не выводится из IP-адреса, протоколы маршрутизации вынуждены передавать префиксы на маршрутизаторы. Иногда они задаются с помощью указания длины (например, «/16»). Длина префикса соответствует двоичной маске, в которой единицы указывают на сетевую часть. Такая маска называется маской подсети (subnet mask). Выполнение операции AND между маской и IP-адресом позволяет выделить сетевую часть. В нашем примере (илл. 5.49) маска подсети выглядит так: 255.255.255.0.

Илл. 5.49. Префикс IP-адреса и маска подсети

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

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

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

Подсети

Во избежание конфликтов номера сетей назначаются некоммерческой организацией — Корпорацией по управлению доменными номерами и IP-адресами (Internet Corporation for Assigned Names and Numbers, ICANN). В свою очередь, ICANN передала полномочия по присвоению некоторых частей адресного пространства региональным органам, занимающимся выделением IP-адресов провайдерам и другим компаниям. Именно так компании получают блоки IP-адресов.

Однако это только начало, так как компаниям по мере роста требуются новые IP-адреса. Как мы уже говорили, маршрутизация по префиксу требует, чтобы у всех хостов сети был один и тот же сетевой номер. Это свойство IP-адресации может вызвать проблемы при увеличении сети. Например, представьте, что университет создал сеть с префиксом /16 из нашего примера. Она используется факультетом информатики в качестве Ethernet. Год спустя подключиться к интернету захотел факультет электротехники, а затем и факультет искусств. Какие IP-адреса будут использовать эти факультеты? Если запросить дополнительные блоки, то получится, что новые сети не будут частью сети университета; к тому же это может быть дорого и неудобно. Более того, префикс /16 позволяет подключить более 60 000 хостов. Возможно, он был выбран с учетом того, что сеть может вырасти. Но пока этого не произошло, выделять университету новые блоки будет неэффективно. Требуется новая архитектура.

Проблема решается предоставлением сети возможности разделения на несколько частей с точки зрения внутренней организации. Это называется разбиением на подсети (subnetting). Сети, полученные в результате разделения крупной сети (например, локальные сети Ethernet), называются подсетями (subnets). Как уже упоминалось в главе 1, новое использование этого термина конфликтует со старым понятием «подсети», обозначающим множество всех маршрутизаторов и линий связи в сети.

На илл. 5.50 показано, как разбиение на подсети может пригодиться в нашем примере. Единая сеть /16 разделена на части. Они не должны быть одинаковыми, но адреса распределяются с учетом длины оставшейся части хоста. В нашем случае половина блока (/17) выделяется факультету информатики, четверть (/18) — факультету электротехники, восьмая часть (/19) — факультету искусств. Оставшаяся восьмая часть не используется. Еще один способ понять, как блок разбивается на части, — посмотреть на префиксы в двоичной нотации.

Информатика

10000000

11010000

1|xxxxxxx

xxxxxxxx

Электротехника

10000000

11010000

00|xxxxxx

xxxxxxxx

Искусства

10000000

11010000

011|xxxxx

xxxxxxxx

Вертикальная черта (|) обозначает границу между номером подсети и номером хоста.

Илл. 5.50. Разделение IP-префикса при разбиении на подсети

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

Когда приходит пакет, маршрутизатор просматривает адрес назначения и определяет, к какой подсети он относится. Для этого он может выполнить операцию AND от этого адреса и маски каждой подсети, сравнивая результат с соответствующим префиксом. Пусть у нас есть пакет с адресом 128.208.2.151. Чтобы проверить, относится ли он к факультету информатики, прибавим к нему (используя логическое AND) маску 255.255.128.0, таким образом отрезав первые 17 бит (то есть 128.208.0.0). Далее сравним полученный результат с префиксом (128.208.128.0). Они не совпадают. Для факультета электротехники аналогичным образом берем первые 18 бит адреса и получаем 128.208.0.0. Это значение совпадает с префиксом, поэтому пакет передается на интерфейс, ведущий к сети факультета электротехники.

Разбиение на подсети можно впоследствии изменить. Для этого нужно обновить сведения о сетевых масках подсетей на всех маршрутизаторах университета. За пределами сети это разделение незаметно, поэтому нет нужды с появлением каждой подсети обращаться в ICANN или менять какие-либо внешние базы данных.

CIDR — бесклассовая междоменная маршрутизация

Даже при эффективном выделении IP-адресов проблема разрастания таблицы маршрутизации сохраняется.

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

Маршрутизаторы интернет-провайдеров и магистралей не могут позволить себе такую роскошь. Они должны знать путь к любой сети, поэтому для них не может существовать простого правила по умолчанию. Про магистральные маршрутизаторы говорят, что они находятся в свободной от умолчаний зоне (default-free zone) интернета. Никто не знает точно, сколько всего сетей подключено к интернету, но очевидно, что их много — возможно, порядка миллиона. Из них можно составить огромную таблицу. Может, она не слишком большая с точки зрения компьютерных стандартов, но представьте, что маршрутизатор должен просматривать ее при отправке каждого пакета (а за секунду он отправляет миллионы таких пакетов). Для такой скорости обработки требуются специализированные аппаратные средства и быстродействующая память; обычный компьютер для этого не подойдет.

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

Проблему таблиц маршрутизации можно было бы решить, увеличив число уровней иерархии, как это происходит в телефонных сетях. Например, каждый IP-адрес мог бы содержать номер страны, региона, города, сети и хоста. В таком случае маршрутизатор должен знать, как достичь любого другого государства, а также всех регионов своей страны, всех городов в них и каждой сети своего города. К сожалению, этот подход потребует гораздо больше, чем 32 бита, а адресное поле будет использоваться неэффективно (для Лихтенштейна будет выделено столько же разрядов, сколько для США).

К счастью, способ сократить таблицы маршрутизации все же существует. Используем тот же принцип, что и при разбиении на подсети: маршрутизатор может узнавать о расположении IP-адресов по префиксам разной длины. Но вместо разделения сети на подсети мы объединим несколько коротких префиксов в один. Этот процесс называется агрегацией маршрута (route aggregation). Длинный префикс, полученный в результате, называется суперсетью (supernet), в противоположность подсетям с разделением блоков адресов.

При агрегации IP-адреса содержатся в префиксах различной длины. Один и тот же IP-адрес может рассматриваться одним маршрутизатором как часть блока /22 (содержащего 210 адресов), а другим — как часть более крупного блока /20 (содержащего 212 адресов). Это зависит от информации, которой обладает маршрутизатор. Этот метод работает и для разбиения на подсети и называется бесклассовой междоменной маршрутизацией (Classless InterDomain Routing, CIDR). Последняя на сегодняшний день версия описана в RFC 4632 (Фуллер и Ли; Fuller and Li, 2006). Название иллюстрирует отличие от адресов, кодирующих иерархию с помощью классов, о которой мы в скором времени поговорим.

Чтобы лучше понять алгоритм маршрутизации, рассмотрим пример. Предположим, у нас есть блок из 8192 адресов, начиная с 194.24.0.0. Допустим, что Кембриджскому университету требуется 2048 адресов, и ему выделяются адреса от 194.24.0.0 до 194.24.7.255, а также маска 255.255.248.0. Это будет префикс /21. Затем Оксфордский университет запрашивает 4096 адресов. Так как блок из 4096 адресов должен располагаться на границе, кратной 4096, то ему не могут быть выделены адреса, начинающиеся с 194.24.8.0. Вместо этого он получает адреса от 194.24.16.0 до 194.24.31.255 вместе с маской 255.255.240.0. Наконец, Эдинбургский университет просит выделить ему 1024 адреса и получает адреса от 194.24.8.0 до 194.24.11.255 и маску 255.255.252.0. Все эти присвоенные адреса и маски сведены в таблицу на илл. 5.51.

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

Теперь посмотрим на эту троицу университетов с точки зрения отдаленного маршрутизатора в Нью-Йорке. Все IP-адреса, относящиеся к этим трем префиксам, должны отправляться из Нью-Йорка (или из США вообще) в Лондон. Процесс маршрутизации в Лондоне узнает об этом, соединяет три префикса в одну агрегированную запись 194.24.0.0/19 и передает ее в Нью-Йорк. Этот префикс содержит 8 Кбайт адресов и включает три университета плюс 1024 свободных адреса. Агрегация позволила объединить три префикса в один, благодаря чему уменьшилось количество префиксов, о которых должен знать маршрутизатор в Нью-Йорке, и число записей в его таблице.

Если агрегация включена, она производится автоматически. Этот процесс зависит от того, где расположены различные префиксы, а не от администратора, который выделяет сетям адреса. В интернете агрегация используется очень активно, снижая размер таблиц маршрутизации примерно до 200 000 префиксов.

Университет

Первый адрес

Последний адрес

Количество

Форма записи

Кембридж

194.24.0.0

194.24.7.255

2048

194.24.0.0/21

Эдинбург

194.24.8.0

194.24.11.255

1024

194.24.8.0/22

(Свободно)

194.24.12.0

194.24.15.255

1024

194.24.12.0/22

Оксфорд

194.24.16.0

194.24.31.255

4096

194.24.16.0/20

Илл. 5.51. Набор присвоенных IP-адресов

Илл. 5.52. Агрегация IP-префиксов

Дальше все становится еще интереснее: префиксы могут пересекаться. Согласно правилу, пакеты передаются в направлении самого специализированного блока, или самого длинного совпадающего префикса (longest matching prefix), в котором находится меньше всего IP-адресов. Поведение маршрутизатора в Нью-Йорке (илл. 5.53) показывает, насколько гибким является такой тип маршрутизации. Для отправки пакетов в три университета нью-йоркский маршрутизатор использует один агрегированный префикс. Но что делать, если ранее свободный блок адресов теперь принадлежит сети в Сан-Франциско? Например, нью-йоркский маршрутизатор может хранить четыре префикса: один для Сан-Франциско и три для Лондона. Вместо этого маршрутизация по самому длинному совпадающему префиксу позволяет обойтись двумя префиксами, как показано на рисунке. Один общий префикс используется, чтобы направлять трафик, предназначенный для всего лондонского блока. По второму, более точному, данные передаются в Сан-Франциско. В соответствии с правилом самого длинного совпадающего префикса пакеты, предназначенные для IP-адресов в Сан-Франциско, будут переданы по соответствующей исходящей линии. Пакеты, предназначенные для более крупной сети, будут направлены в Лондон.

Илл. 5.53. Маршрутизация по самому длинному совпадающему префиксу на нью-йоркском маршрутизаторе

По сути, CIDR работает так. Когда прибывает пакет, необходимо определить, указан ли нужный адрес в префиксе; для этого просматривается таблица маршрутизации. Может оказаться, что по значению подойдет несколько записей, тогда выбирается самый длинный префикс. То есть если найдено совпадение для маски /20 и /24, то для выбора исходящей линии будет использоваться запись, соответствующая /24. Однако если бы таблица действительно просматривалась запись за записью, этот процесс был бы слишком долгим. Чтобы этого избежать, был разработан сложный алгоритм для ускорения процесса поиска адреса в таблице (Руис-Санчес и др.; Ruiz-Sanchez et al., 2001). В маршрутизаторах для коммерческого использования применяются специальные чипы VLSI, в которые эти алгоритмы встроены на аппаратном уровне.

Классовая и специальная адресация

Чтобы лучше понять преимущества CIDR, рассмотрим метод, который применялся ранее. До 1993 года IP-адреса разделялись на 5 категорий (илл. 5.54). Такое распределение называется классовой адресацией (classful addressing).

Илл. 5.54. Форматы IP-адреса

Форматы классов A, B и C позволяют задавать адреса для 128 сетей с 16 млн хостов в каждой, 16 384 сетей с 64 536 хостами или 2 млн сетей (например, LAN) с 256 хостами (хотя некоторые из них могут быть специальными). Предусмотрен класс для многоадресной рассылки (D), при которой дейтаграммы рассылаются одновременно на несколько хостов. Адреса, начинающиеся с 1111, зарезервированы для будущего применения. Неплохо было бы использовать их уже сейчас, когда адресное пространство IPv4 практически закончилось. Но так как в течение долгого времени они были запрещены, многие хосты будут их отвергать — не так просто заставить старый хост изменить свои привычки.

Такая структура является иерархической. Но в отличие от CIDR здесь используются фиксированные размеры блоков адресов. Существует свыше 2 млрд 21-битных адресов, однако организация адресного пространства с использованием классов ведет к потере миллионов адресов. И настоящий виновник этого — класс сетей В. Для большинства организаций 16 млн адресов в классе А — это слишком много, а 256 адресов класса С — слишком мало. Класс В с 65 536 адресами — то, что нужно. В интернет-фольклоре эта дилемма известна как проблема трех медведей (three bears problem). Совсем как в «Сказке про трех медведей»30 Роберта Саути (Southey, 1848).

На самом деле класс В также слишком велик для большинства организаций. Исследования показали, что более чем в половине случаев сети класса В включают в себя менее 50 хостов. Всем этим компаниям хватило бы и сетей класса С, но почему-то все уверены, что в один прекрасный день маленькое предприятие разрастется настолько, что сеть выйдет за пределы 8-битного адресного пространства хостов. Сейчас, оглядываясь назад, кажется, что лучше было бы использовать в классе С 10-битную адресацию (до 1022 хостов в сети). Возможно, в этом случае многие организации приняли бы разумное решение устанавливать сети класса С, а не В. Таких сетей могло бы быть полмиллиона, а не 16 384, как в случае класса В.

В создавшейся ситуации нельзя обвинять разработчиков интернета за то, что они не увеличили (или не уменьшили) адресное пространство сетей класса В. Когда принималось решение о создании трех классов сетей, интернет был инструментом научно-исследовательских организаций США (и еще нескольких компаний и военных организаций). Никто не предполагал, что интернет станет коммерческой системой коммуникации общего пользования, соперничающей с телефонной сетью. Несомненно, в тот момент кто-то сказал: «В США около 2000 колледжей и университетов. Даже если все они подключатся к интернету и к ним присоединятся университеты из других стран, мы никогда не превысим число 16 000, потому что высших учебных заведений по всему миру не так уж много. Зато мы будем кодировать номер хоста целым числом байтов, что ускорит процесс обработки пакетов» (в то время это выполнялось исключительно программными средствами). Быть может, однажды кто-то воскликнет, обвиняя разработчиков телефонной сети: «Вот идиоты! Почему они не включили номер планеты в телефонный номер?» Когда телефонные сети создавались, никто не думал, что это понадобится.

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

Отказ от классов усложнил процесс маршрутизации. В старой классовой системе маршрутизация происходила следующим образом. По прибытии пакета на маршрутизатор копия IP-адреса, извлеченного из пакета и сдвинутого вправо на 28 бит, давала 4-битный номер класса. Затем с помощью 16-стороннего ветвления пакеты рассортировывались на A, B, C (а также D и E): восемь были зарезервированы для А, четыре для В, два для С. Затем при помощи маскировки по коду каждого класса определялся 8-, 16 или 32-битный сетевой номер, который и записывался с выравниванием по правым разрядам в 32-битное слово. Сетевой номер отыскивался в таблице А, В или С, причем для А и В применялась индексация, а для С — хеш-функция. По найденной записи определялась выходная линия, и по ней пакет отправлялся далее. Этот метод гораздо проще, чем нахождение наиболее длинного совпадающего префикса, при котором простой поиск по таблице невозможен, так как префиксы IP-адресов могут иметь произвольную длину.

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

Некоторые адреса имеют особое назначение (илл. 5.55). IP-адрес 0.0.0.0 — наименьший адрес — используется хостом только при включении. Он означает «эта сеть» или «этот хост». IP-адреса с нулевым номером сети обозначают текущую сеть. Такие адреса позволяют устройствам обращаться к хостам собственной сети, не зная ее номера (но они должны знать маску сети, чтобы знать количество используемых нулей). Адрес, состоящий только из единиц, или 255.255.255.255 — наибольший адрес — обозначает все хосты в указанной сети.

Илл. 5.55. Специальные IP-адреса

Он обеспечивает широковещание в пределах текущей (обычно локальной) сети. Адреса, в которых указана сеть, но в поле номера хоста одни единицы, обеспечивают широковещание в пределах любой удаленной LAN, соединенной с интернетом. Однако многие сетевые администраторы отключают эту возможность по соображениям безопасности. Наконец, все адреса вида 127.xx.yy.zz зарезервированы для тестирования обратной петли. Пакеты, переданные на этот адрес, не попадают на линию, а обрабатываются локально как входные. В результате они могут быть отправленными на хост, даже если отправитель не знает его номера, что полезно для тестирования.

NAT — трансляция сетевого адреса

IP-адреса являются дефицитным ресурсом. У провайдера может быть /16-адрес (бывший класс В), дающий возможность подключить 65 534 хоста. Если клиентов становится больше, возникают проблемы. Так, количество 32-разрядных адресов составляет только 232, и все они закончились.

Этот дефицит ресурсов стал причиной появления методов эффективного использования IP-адресов. Согласно одному из них IP-адрес выделяется компьютеру, который в данный момент включен и подключен к сети; когда этот компьютер становится неактивным, его адрес присваивается новому соединению. В этом случае один /16-адрес будет обслуживать до 65 534 активных пользователей.

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

Проблема усугубляется еще и тем, что все больше частных пользователей желают иметь ADSL или кабельное соединение с интернетом, поскольку при этом не нужно (как когда-то) платить за подключение на почасовой основе — взимается только ежемесячная абонентская плата. Многие пользователи имеют дома два и более компьютера (например, по одному на каждого члена семьи) и хотят, чтобы все устройства имели постоянный выход в интернет. Решение таково: необходимо установить (беспроводной) маршрутизатор и объединить все компьютеры в домашнюю LAN. Сам маршрутизатор должен быть подключен к провайдеру. С точки зрения провайдера, в этом случае семья будет выступать в качестве аналога маленькой фирмы с несколькими компьютерами. Добро пожаловать в компанию «Ивановы»! Если использовать обычные схемы, то каждый компьютер будет сохранять свой IP-адрес в течение всего дня. Но для провайдеров с несколькими тысячами клиентов (многие из которых представляют собой целые организации или семьи, также похожие на небольшие организации) такая ситуация недопустима, так как IP-адресов попросту не хватит.

Дефицит IP-адресов не является теоретической проблемой, которая может возникнуть в далеком будущем. Это происходит здесь и сейчас. В долгосрочной перспективе решением будет тотальный перевод всего интернета на протокол IPv6 со 128-битной адресацией. Этот переход действительно постепенно происходит, но процесс идет так медленно, что затянется на годы. А пока необходимо найти какое-нибудь временное решение. Им стал популярный метод трансляции сетевого адреса (Network Address Translation, NAT), описанный в RFC 3022. Суть его мы рассмотрим ниже, а более подробную информацию можно найти в работе Датчера (Dutcher, 2001).

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

10.0.0.0 — 10.255.255.255/8 (16 777 216 хостов)

172.16.0.0 — 172.31.255.255/12 (1 048 576 хостов)

192.168.0.0 — 192.168.255.255/16 (65 536 хостов)

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

Работа метода NAT показана на илл. 5.56. В пределах территории абонента у каждого компьютера имеется собственный уникальный адрес вида 10.x.y.z. Тем не менее перед тем, как пакет выходит за пределы помещения абонента, он проходит через NAT-блок (NAT box), транслирующий внутренний IP-адрес источника (10.0.0.1 на рисунке) в реальный IP-адрес, полученный абонентом от провайдера (198.60.42.12 для нашего примера). NAT-блок обычно представляет собой единое устройство с межсетевым экраном, обеспечивающим безопасность путем строгого отслеживания входящего и исходящего трафика абонентской сети. Межсетевые экраны мы изучим отдельно в главе 8. NAT-блок может быть также интегрирован с маршрутизатором или модемом ADSL.

Мы до сих пор обходили одну маленькую деталь: когда приходит ответ на запрос (например, от веб-сервера), он адресуется 198.60.42.12. Как же NAT-блок узнает, каким внутренним адресом заменить общий адрес компании? В этом и состоит главная проблема применения NAT. Если бы в заголовке IP-пакета было свободное поле, его можно было бы использовать для запоминания адреса того, кто отправил запрос. Но в заголовке остается неиспользованным всего один бит. В принципе, можно было бы создать поле для реального адреса источника, но это потребовало бы изменения IP-кода на всех устройствах интернета. Это не лучший выход, особенно если мы хотим найти быстрое решение проблемы нехватки IP-адресов.

Илл. 5.56. Расположение и работа NAT-блока

На самом деле происходит следующее. Разработчики NAT заметили, что большая часть пользовательских данных IP-пакетов — это либо TCP, либо UDP. Когда мы будем рассматривать TCP и UDP в главе 6, мы увидим, что оба формата имеют заголовки, содержащие номера портов источника и получателя. Ниже мы обсудим порты TCP, но с портами UDP происходит то же самое. Номера портов представляют собой 16-разрядные целые числа, показывающие, где начинается и заканчивается TCP-соединение. Место хранения номеров портов используется в качестве поля, необходимого для работы NAT.

Когда процесс хочет установить TCP-соединение с удаленным процессом, он связывается со свободным TCP-портом на своем компьютере. Этот порт становится портом источника (source port) и сообщает TCP-коду, куда направлять пакеты данного соединения. Процесс также определяет порт назначения (destination port). Посредством этого порта сообщается, кому отдать пакет на удаленной стороне. Порты с 0-го по 1023-й зарезервированы для хорошо известных служб. Например, 80-й порт используется веб-серверами, соответственно, на них могут ориентироваться удаленные клиенты. Каждое исходящее сообщение TCP содержит информацию о портах источника и назначения. Вместе они служат для идентификации процессов на обоих концах, использующих соединение.

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

С помощью поля Source port решается проблема отображения адресов. Когда исходящий пакет приходит в NAT-блок, адрес источника вида 10.x.y.z заменяется настоящим IP-адресом. Кроме того, поле Source port TCP заменяется индексом таблицы перевода NAT-блока, содержащей 65 536 записей. Каждая запись включает исходный IP-адрес и номер исходного порта. Наконец, пересчитываются и вставляются в пакет контрольные суммы заголовков TCP и IP. Поле Source port нужно заменять, поскольку устройства с местными адресами 10.0.0.1 и 10.0.0.2 могут случайно пожелать воспользоваться одним и тем же портом (5000-м, например). Так что для однозначной идентификации процесса отправителя единственного поля Source port оказывается недостаточно.

Когда пакет прибывает на NAT-блок со стороны провайдера, извлекается значение поля Destination port заголовка TCP. Оно используется в качестве индекса таблицы отображения NAT-блока. По найденной в этой таблице записи определяются внутренний IP-адрес и настоящий порт TCP. Эти два значения вставляются в пакет. Затем заново подсчитываются контрольные суммы TCP и IP. Пакет передается на главный маршрутизатор абонента для нормальной доставки с адресом вида 10.x.y.z.

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

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

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

В-четвертых, NAT нарушает одно из фундаментальных правил построения многоуровневых протоколов: уровень k не должен строить никаких предположений относительно того, что именно уровень k + 1 поместил в поле Payload. Этот принцип обеспечивает независимость уровней друг от друга. Если когда-нибудь на смену ТСР придет ТСР-2, у которого будет другой формат заголовка (например, 32-битная адресация портов), то NAT потерпит фиаско. Вся идея многоуровневых протоколов состоит в том, чтобы изменения в одном уровне никак не влияли на остальные уровни. NAT разрушает эту независимость.

В-пятых, процессы в интернете вовсе не обязаны использовать только TCP или UDP. Если пользователь устройства А придумает новый протокол транспортного уровня для общения с пользователем устройства В (например, с целью поддержки какого-либо мультимедийного приложения), то ему придется бороться с тем, что NAT-блок не сможет корректно обработать поле TCP Source port.

В-шестых, некоторые приложения предусматривают использование множественных TCP/IP-соединений или UDP-портов. Так, стандартный протокол передачи файлов (File Transfer Protocol, FTP) вставляет IP-адрес в тело пакета, чтобы затем получатель извлек его оттуда и обработал. Так как NAT об этом не знает, он не сможет переписать адрес или как-то иначе его обработать. Это озна­чает, что FTP и другие приложения, например протокол интернет-телефонии H.323 (мы рассмотрим его в главе 7), не смогут работать с NAT, если не будут приняты специальные меры. Зачастую NAT можно исправить и заставить его корректно работать в этих случаях, но невозможно дорабатывать его всякий раз, когда появляется новое приложение.

Наконец, поскольку поле TCP Source port является 16-разрядным, то одному IP-адресу может соответствовать максимум 65 536 устройств. На самом деле это число несколько меньше: первые 4096 портов зарезервированы для служебных нужд. В общем, если есть несколько IP-адресов, то каждый из них может поддерживать до 61 440 устройств.

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

5.7.3. Протокол IP версии 6

Протокол IP активно применяется вот уже десятки лет и работает превосходно, что подтверждается экспоненциальным ростом интернета. К сожалению, он стал жертвой собственной популярности: его адресное пространство заканчивается. Даже несмотря на то что CIDR и NAT используют это пространство достаточно экономно, последние адреса IPv4 были выделены 25 ноября 2019 года. Надвигающуюся угрозу заметили почти 20 лет назад, и вопрос о том, что с этим делать, вызвал в интернет-сообществе бурю дискуссий и скандалов.

В этом разделе мы обсудим проблему и несколько предлагаемых решений. Единственной перспективной идеей является переход к более длинным адресам. IP версии 6 (IP version 6, IPv6) — новая разработка, призванная заменить IPv4. IPv6 использует 128-битные адреса; в обозримом будущем дополнительного увеличения длины адреса, скорее всего, не потребуется. Но оказалось, что внедрить IPv6 не так просто. Это принципиально новый протокол сетевого уровня, несовместимый с IPv4, несмотря на многочисленные сходства с ним. Кроме того, компании и отдельные пользователи не понимают, почему им надо переходить на IPv6. На данный момент он охватывает лишь небольшую часть интернета (около 25 %), несмотря на то что признан стандартом еще в 1998 году. В следующие несколько лет нас ждут интересные события. Каждый адрес IPv4 стоит около $19. В 2019 году некий мужчина был осужден за попытку перепродажи на черном рынке 750 000 IP-адресов, общая стоимость которых составляет около $14 млн.

На фоне проблем с адресами вырисовываются и другие вопросы. До недавнего времени интернетом пользовались в основном университеты, высокотехнологичные предприятия и правительственные организации США (особенно Министерство обороны). В середине 90-х годов интерес к интернету резко возрос, и теперь доступ к нему имеет огромное количество людей с принципиально разными требованиями. Во-первых, многочисленные владельцы смартфонов с помощью интернета поддерживают связь с домашними компьютерами. Во-вторых, при неминуемом сближении компьютерной, коммуникационной и развлекательной индустрии очень скоро все телефоны и телевизоры планеты могут стать интернет-узлами. Это приведет к появлению миллиардов устройств, используемых для аудио и видео по запросу. В таких обстоятельствах становится очевидно, что IP должен эволюционировать и стать более гибким.

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

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

2. Сократить таблицы маршрутизации.

3. Упростить протокол для ускорения обработки пакетов маршрутизаторами.

4. Обеспечить более высокий уровень безопасности (аутентификации и конфиденциальности).

5. Уделять больше внимания типу службы, особенно при передаче данных в реальном времени.

6. Упростить работу многоадресных рассылок с помощью указания областей рассылки.

7. Предоставить хосту возможность перемещаться, сохраняя сетевой адрес.

8. Предусмотреть будущее развитие протокола.

9. Обеспечить сосуществование старого и нового протоколов в течение нескольких лет.

Разработка IPv6 дала шанс улучшить характеристики IPv4, исходя из потребностей современного интернета. Чтобы найти протокол, удовлетворяющий всем этим требованиям, IETF опубликовал в RFC 1550 призыв к дискуссиям и предложениям. Был получен двадцать один ответ. В декабре 1992 года были рассмотрены семь серьезных предложений. Их содержание варьировалось от небольших изменений в IP до полного отказа от него и замены совершенно другим протоколом.

В частности, было предложено запустить TCP на базе CLNP, протокола сетевого уровня, разработанного для OSI. Обладая 160-разрядным адресом, CLNP навсегда обеспечил бы достаточное адресное пространство. Он мог бы предоставить адрес каждой молекуле воды в Мировом океане (а это порядка 25 адресов), чтобы они могли создать свою небольшую сеть. Кроме того, это решение объединило бы два основных сетевых протокола. Но тогда пришлось бы признать, что кое-что в модели OSI было сделано правильно, а это утверждение является политически некорректным в интернет-кругах. Протокол CLNP на самом деле очень мало отличается от IP. Окончательный выбор был сделан в пользу протокола, отличающегося от IP значительно сильнее. Еще одним аргументом против CLNP была его слабая поддержка типов служб, которые требовались для эффективной передачи мультимедиа.

Три лучших предложения были опубликованы в журнале IEEE Network Дирингом (Deering, 1993), Фрэнсисом (Francis, 1993), а также Кацем и Фордом (Katz and Ford, 1993). После долгих обсуждений, переработок и борьбы за первое место была выбрана модифицированная комбинированная версия Диринга и Фрэнсиса, получившая название Простого интернет-протокола Плюс (Simple Internet Protocol Plus, SIPP). Новому протоколу было дано обозначение IPv6.

Протокол IPv6 прекрасно справляется с поставленными задачами. Он обладает достоинствами IP и лишен некоторых его недостатков (либо обладает ими в меньшей степени), к тому же наделен новыми свойствами. Как правило, IPv6 несовместим с IPv4. Зато он сочетается со всеми остальными протоколами интернета, включая TCP, UDP, ICMP, IGMP, OSPF, BGP и DNS. Иногда это требует небольших изменений для работы с более длинными адресами. Основные функции IPv6 представлены далее. Дополнительные сведения о нем можно найти в стандартах RFC 2460–RFC 2466.

Прежде всего, поля адресов у протокола IPv6 больше, чем у IPv4. Их длина составляет 128 бит, что решает основную задачу, поставленную при разработке протокола, — обеспечить практически неограниченный запас интернет-адресов. Мы кратко обсудим адреса чуть позднее.

Второе заметное улучшение IPv6 по сравнению с IPv4 состоит в упрощенном заголовке пакета. Он состоит всего из 7 полей (вместо 13 у IPv4). Таким образом, маршрутизаторы могут быстрее обрабатывать пакеты, что повышает производительность. Краткое описание заголовков будет приведено ниже.

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

Далее, протокол IPv6 демонстрирует большой шаг вперед в области безо­пасности. У IETF была полная папка вырезок из газет с сообщениями о том, как 12-летние мальчишки со своего персонального компьютера взломали банк или военную базу. Было ясно, что надо как-то улучшить систему безопасности. Аутентификация и конфиденциальность являются ключевыми чертами нового IP-протокола. Позже IPv4 был модифицирован, и разница с точки зрения безо­пасности стала не так уж и велика.

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

Основной заголовок IPv6

Заголовок IPv6 показан на илл. 5.57. Поле Version содержит число 6 для IPv6 (и 4 для IPv4). На период перехода с IPv4 на IPv6, который длится уже более десяти лет, маршрутизаторы по значению этого поля смогут различать пакеты нового и старого стандартов. Заметим, что такая проверка приводит к потере нескольких инструкций в критически важном для производительности тракте. В заголовке с информацией о канале передачи данных обычно указан протокол для демультиплексирования, так что некоторые маршрутизаторы могут пропустить проверку. Например, в Ethernet у поля Type (Тип) есть несколько разных значений, определяющих пользовательские данные IPv4- или IPv6-пакета. Бурная дискуссия между сторонниками принципов «делай правильно» и «делай быстро», несомненно, затянется на долгие годы.

Илл. 5.57. Фиксированный заголовок IPv6 (обязательные поля)

Поле Differentiated services (изначально Traffic class, Класс трафика) необходимо, чтобы отличать пакеты с разными требованиями к доставке в реальном времени. Оно используется для обеспечения QoS вместе с архитектурой дифференцированного обслуживания (аналогично одноименному полю IPv4). Кроме того, так же как и в IPv4, младшие 2 бита отводятся под явные уведомления о перегрузке.

Поле Flow label (Метка потока) применяется для того, чтобы отправитель и получатель могли сообщить сети об определенных свойствах пакетов и требованиях к их обработке; при этом между ними устанавливается псевдосоединение. Например, поток пакетов между двумя процессами на разных хостах может иметь строгие требования к задержкам, что потребует резервирования пропускной способности. Поток устанавливается заранее и получает идентификатор. Когда прибывает пакет с ненулевым значением в поле Flow label, все маршрутизаторы проверяют свои таблицы, чтобы определить, какой тип особой обработки ему требуется. Таким образом, новый протокол пытается объединить достоинства подсетей различных типов: гибкость дейтаграмм и гарантии виртуальных каналов.

С целью обеспечения QoS каждому потоку присваивается адрес источника, адрес назначения и номер потока. Это означает, что для каждой пары IP-адресов можно создать до 220 активных потоков. Кроме того, если два потока приходят с разных хостов, но имеют одинаковую метку, маршрутизатор может отличить их по адресам источника и получателя. Предполагается, что метки потоков выбираются случайно, а не назначаются подряд, начиная с единицы, так что подразумевается, что маршрутизаторы будут их хешировать.

Поле Payload length (Длина пользовательских данных) сообщает, сколько байтов следует за 40-байтным заголовком на илл. 5.57. В заголовке IPv4 аналогичное поле называлось Total length и определяло весь размер пакета. В новом протоколе 40 байт заголовка учитываются отдельно. Это значит, что теперь пользовательские данные могут занимать 65 535 байт вместо 65 515.

Поле Next header (Следующий заголовок) раскрывает секрет упрощения заголовка. Дело в том, что можно использовать дополнительные (необязательные) расширенные заголовки. Это поле сообщает, какой из шести таких заголовков (на текущий момент) следует за основным. В последнем IP-заголовке поле Next header информирует, какому обработчику транспортного уровня (то есть TCP или UDP) передать пакет.

Поле Hop limit (Максимальное число транзитных участков) не дает пакетам вечно блуждать по сети. Оно имеет практически то же назначение, что и поле Time to live в заголовке IPv4. Это поле уменьшается на единицу на каждом транзитном участке. Теоретически в IPv4 это поле должно было содержать секунды существования пакета, однако ни один маршрутизатор не использовал его подобным образом, поэтому имя поля было приведено в соответствие со способом его применения.

Следом идут поля Source address и Destination address. В изначальном предложении Диринга (протоколе SIPP) использовались 8-байтные адреса, но при рассмотрении проекта было решено, что они закончатся всего через несколько десятилетий, в то время как 16-байтных адресов хватит навсегда. Другие возражали, что 16 байт — это слишком много, третьи настаивали на 20-байтных адресах для совместимости с дейтаграммным протоколом OSI. Еще одна фракция выступала за адреса переменной длины. После продолжительных споров, содержащих непечатную лексику, было решено, что наилучшим компромиссным решением являются 16-байтные адреса фиксированной длины.

Для написания 16-байтных адресов была выработана новая нотация. Адреса в IPv6 записываются в виде восьми групп по четыре шестнадцатеричные цифры, разделенных двоеточиями, например:

8000:0000:0000:0000:0123:4567:89AB:CDEF

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

8000::123:4567:89AB:CDEF

Наконец, адреса IPv4 могут записываться как пара двоеточий, после которой пишется адрес в старом десятичном формате, например:

::192.31.20.46

Возможно, об этом нет необходимости говорить столь подробно, но количество всех возможных 16-байтных адресов очень велико — 2128, что приблизительно равно 3 × 1038, или 7 × 1023 IP-адресов на каждый квадратный метр земной поверхности. Те, кто изучал химию, могут заметить, что это число больше числа Авогадро31. Хотя в планы разработчиков не входило предоставление IP-адреса каждой молекуле на поверхности земли, они не так далеки от этого.

На практике не все адресное пространство используется эффективно, так же как и комбинации телефонных номеров. Например, номера Манхэттена (код 212) почти полностью заняты, тогда как в штате Вайоминг (код 307) практически не задействованы. В RFC 3194 Дьюранд (Durand) и Уитема (Huitema) приводят свои вычисления. Утверждается, что если ориентироваться на использование телефонных номеров, то даже при самом пессимистическом сценарии все равно получается более 1000 IP-адресов на квадратный метр поверхности планеты (включая сушу и море). При любом вероятном сценарии обеспечиваются триллионы адресов на квадратный метр. Маловероятно, что в обозримом будущем возникнет их нехватка.

Полезно сравнить заголовок IPv4 (см. илл. 5.47) с заголовком IPv6 (илл. 5.57) и посмотреть, что осталось от старого стандарта. Поле IHL исчезло, так как заголовок IPv6 имеет фиксированную длину. Поле Protocol также было убрано, поскольку поле Next header сообщает, что следует за последним IP-заголовком (например, UDP- или TCP-сегмент).

Были удалены все поля, относящиеся к фрагментации, так как в IPv6 используется другой подход к ней. Во-первых, все хосты, поддерживающие IPv6, должны динамически определять нужный размер пакета. Для этого используется метод поиска путевого значения MTU, о котором мы говорили в разделе 5.5.6. Вкратце, когда хост отправляет слишком большой IPv6-пакет вместо того, чтобы его фрагментировать, маршрутизатор, неспособный переслать пакет дальше, возвращает сообщение об ошибке. Получив это сообщение, хост должен прекратить всю передачу этому адресату. Гораздо правильнее научить все хосты отправлять пакеты требуемого размера, нежели учить маршрутизаторы фрагментировать их на лету. Кроме того, минимальный размер пакета был увеличен с 576 до 1280, чтобы можно было передавать 1024 байт данных и множество заголовков.

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

Заголовки расширений

Иногда удаленные поля заголовка могут понадобиться, поэтому в протоколе IPv6 была представлена новая концепция необязательного расширения заголовка (extension header). С его помощью можно добавить дополнительную информацию, при этом она эффективно закодирована. На сегодня определены шесть типов таких заголовков (илл. 5.58). Все они необязательны, но если их два и более, то они должны идти сразу за фиксированным заголовком, желательно в указанном порядке.

У одних заголовков формат фиксированный, другие могут содержать разное количество полей переменной длины. Для них каждый пункт кодируется в виде набора взаимосвязанных величин (тип, длина, значение). Поле Type представляет собой однобайтное поле, обозначающее опцию. Первые два бита указывают маршрутизаторам, которые не знают, как ее обрабатывать. Возможны четыре варианта действий: пропустить опцию, игнорировать пакет, игнорировать пакет и отправить обратно ICMP-пакет, а в случае многоадресной рассылки — игнорировать пакет, но не отвечать ICMP-пакетом (чтобы один неверный пакет не породил миллионы ICMP-донесений).

Поле Length (Длина) также имеет размер 1 байт. Оно сообщает, насколько велико значение (от 0 до 255 байт). Поле Value (Значение) содержит необходимую информацию размером до 255 байт.

Заголовок расширения

Описание

Hop-by-hop options

Разнообразная информация для маршрутизаторов

Destination options

Дополнительная информация для получателя

Routing

Частичный список транзитных маршрутизаторов на пути пакета

Fragment

Управление фрагментами дейтаграмм

Authentication

Проверка подлинности отправителя

Encrypted security payload

Информация о зашифрованном содержимом

Илл. 5.58. Заголовки расширения IPv6

Заголовок Hop-by-hop options (Опции переходов) содержит информацию, которая должна исследоваться маршрутизаторами на протяжении всего пути следования пакета. На данный момент определен один вариант его использования: поддержка дейтаграмм, превышающих 64 Кбайт. Формат заголовка показан на илл. 5.59. При этом полю Payload length в фиксированном заголовке присваивается значение 0.

Илл. 5.59. Заголовок Hop-by-hop options для крупных дейтаграмм (джамбограмм)

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

Следующие 2 байта указывают, что данная опция несет информацию о размере дейтаграммы (код 194) в виде 4-байтного числа. Последние 4 байта содержат размер. Размеры меньше 65 536 не допускаются, так как могут привести к тому, что первый же маршрутизатор проигнорирует данный пакет и отправит ICMP-сообщение. Дейтаграммы с такими заголовками расширений называются джамбограммами (jumbograms). Джамбограммы нужны для суперкомпьютерных приложений, передающих по интернету гигабайты данных.

Заголовок Destination options (Опции адресата) предназначен для полей, которые должны интерпретироваться только хостом-получателем. В изначальной версии IPv6 задавались только «нулевые» опции для дополнения этого заголовка до кратности 8 байтам, и сам заголовок не использовался. Это делалось, чтобы новое программное обеспечение маршрутизаторов и хостов могло их обработать, если кто-нибудь подумает об опциях адресата в будущем.

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

Илл. 5.60. Заголовок расширения Routing

Первые четыре байта заголовка Routing содержат четыре однобайтных целых числа. Поля Next header и Header extension length (Длина расширения заголовка) были описаны ранее. В поле Routing type (Тип маршрутизации) описывается формат оставшейся части заголовка. Если он равен 0, это означает, что далее следует зарезервированное 32-разрядное слово, а за ним — некоторое число адресов IPv6. Возможно в будущем по мере необходимости станут разрабатываться новые поля. Наконец, в поле Segments left (Число оставшихся сегментов) указывается, сколько адресов из списка еще нужно посетить. Его значение уменьшается при прохождении каждого адреса. Когда оно достигает нуля, пакет оставляется на произвол судьбы — без дальнейших указаний относительно его пути. Обычно к этому моменту он уже находится близко к получателю, и оптимальный маршрут очевиден.

Заголовок Fragment (Фрагмент) решает проблему фрагментации способом, схожим с протоколом IPv4. Он содержит идентификатор дейтаграммы, номер фрагмента и бит, информирующий о том, является ли этот фрагмент последним. В отличие от IPv4, в протоколе IPv6 фрагментировать пакет может только хост-источник. Маршрутизаторы фрагментировать пересылаемые пакеты не могут. Хотя это изменение можно считать отказом от оригинальной философии IP, оно вполне в духе современного применения IPv4. Вдобавок оно упрощает и ускоряет работу маршрутизаторов. Как уже было сказано, маршрутизатор отвергает слишком большие пакеты, отправляя в ответ ICMP-пакет, указывающий хосту-источнику на необходимость заново передать пакет, разделив его на меньшие фрагменты.

Заголовок Authentication (Аутентификация) предоставляет механизм подтверждения подлинности отправителя пакета. Заголовок Encrypted security payload (Шифрование пользовательских данных) обеспечивает конфиденциальность: прочесть содержимое пакета сможет только тот, для кого он предназначен. Для выполнения этих задач в заголовках используются криптографические методы, которые будут рассмотрены в главе 8.

Полемика

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

О спорах по поводу длины поля адреса уже упоминалось. В результате было принято компромиссное решение: 16-байтные адреса фиксированной длины.

Другое сражение разгорелось из-за размера поля Hop limit. Некоторые участники дискуссии считали, что ограничение количества транзитных участков числом 255 (которое явно следует из использования 8-битного поля) — большая ошибка. В самом деле, маршруты из 32 транзитных участков уже стали обычным явлением, а через 10 лет в обиход могут войти более длинные пути. Сторонники этого лагеря заявляли, что использование длинных полей адресов было дальновидным решением, в отличие от внедрения крохотных счетчиков транзитных участков. Самый страшный грех, который, по их мнению, могут совершить специалисты по вычислительной технике, — выделить для чего-нибудь недостаточное количество разрядов.

В ответ им было заявлено, что подобные аргументы можно привести для увеличения любого поля, что приведет к раздутому заголовку. Кроме того, назначение поля Hop limit состоит в том, чтобы не допустить слишком долгого странствования пакетов, и 65 535 транзитных участков — это очень много. К тому же по мере роста интернета будет создаваться все большее количество междугородних линий, что позволит передавать пакеты между любыми странами максимум за шесть транзитных пересылок. Если от получателя или отправителя до соответствующего международного шлюза окажется более 125 транзитных участков, то, видимо, что-то не в порядке с магистралями этого государства. В итоге эту битву выиграли сторонники 8-битного счетчика.

Еще одним предметом спора оказался максимальный размер пакета. Обладатели суперкомпьютеров настаивали на размере пакетов, превышающем 64 Кбайт. Когда суперкомпьютер начинает передачу, он занимается серьезным делом и не хочет, чтобы его прерывали через каждые 64 Кбайт. Аргумент против больших пакетов заключается в том, что если пакет размером в 1 Мбайт будет передаваться по линии Т1 со скоростью 1,5 Мбит/с, то он займет линию на целых 5 с, что вызовет слишком большую задержку, заметную для интерактивных пользователей. В итоге удалось достичь компромисса: обычные пакеты ограничены размером 64 Кбайт, но с помощью заголовка расширения можно передавать огромные дейтаграммы.

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

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

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

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

Другая сторона вопроса расположения системы безопасности заключается в том, что во многих (хотя, конечно, далеко не во всех) странах приняты строгие экспортные законы, касающиеся шифрования и зашифрованных данных, особенно личной информации. В некоторых странах, в частности во Франции32 и Ираке, строго запрещено использование шифрования даже внутри страны, чтобы у населения не могло быть секретов от органов власти. В результате любая реализация IP с достаточно мощной криптографической системой не может быть экспортирована за пределы США (и многих других стран). Таким образом, приходится поддерживать два набора программного обеспечения — один для внутреннего использования и другой для экспорта, против чего решительно выступает большинство производителей компьютеров.

Единственный вопрос, по которому не было споров, — никто не рассчитывал, что IPv4-интернет будет отключен в воскресенье, а в понедельник утром ему на смену придет IPv6-интернет. Вместо этого вначале появятся «островки» IPv6, которые будут общаться по туннелям (см. раздел 5.5.4). По мере роста эти островки будут соединяться в более крупные острова. Наконец, все они объединятся, и интернет будет полностью трансформирован.

Так, по крайней мере, выглядел план. Внедрение протокола IPv6 оказалось его ахиллесовой пятой. Он по-прежнему не слишком распространен, хотя уже более 10 лет его полностью поддерживают все основные операционные системы. Обычно операторы сети вводят IPv6, только когда нуждаются в дополнительных IP-адресах. Но надо заметить, что этот протокол постепенно одерживает верх. На него уже приходится большая часть трафика Comcast и примерно четверть трафика Google, так что прогресс налицо.

Чтобы упростить переход к IPv6, разработано множество стратегий. Среди них методы автоматической настройки туннелей, обеспечивающих передачу IPv6-пакетов через сеть IPv4, и технологии, позволяющие хостам автоматически находить конечную точку туннеля. Двухстековые хосты поддерживают как IPv4, так и IPv6 и могут выбирать протокол в зависимости от адреса получателя. Эти стратегии помогут ускорить процесс перехода к IPv6, когда он будет неизбежным. Подробнее об этом — в книге Дэвиса (Davies, 2008).

5.7.4. Управляющие протоколы интернета

Помимо IP, используемого для передачи данных, в интернете есть несколько дополнительных управляющих протоколов сетевого уровня, к которым относятся ICMP, ARP и DHCP. В данном разделе мы рассмотрим их по очереди, описывая те версии, которые соответствуют IPv4 (так как именно они распространены сегодня). У ICMP и DHCP существуют аналогичные версии для IPv6; эквивалентом APR является протокол обнаружения соседей (Neighbor Discovery Protocol, NDP).

ICMP — протокол управляющих сообщений интернета

За работой интернета следят маршрутизаторы. Если во время обработки пакета происходит что-то непредвиденное, маршрутизатор сообщает об этом отправителю с помощью протокола управляющих сообщений интернета (Internet Control Message Protocol, ICMP). Он также используется для тестирования интернета. Существует около десятка типов сообщений ICMP. Каждое ICMP-сообщение вкладывается в IP-пакет. Наиболее важные из них перечислены на илл. 5.61.

Тип сообщения

Описание

Destination unreachable

Пакет не может быть доставлен

Time exceeded

Время жизни пакета уменьшилось до нуля

Parameter problem

Неверное поле заголовка

Source quench

Сдерживающий пакет

Redirect

Научить маршрутизатор географии

Echo and echo reply

Проверить, работает ли машина

Timestamp request/reply

То же, что и запрос отклика, но с временной меткой

Router advertisement/solicitation

Найти ближайший маршрутизатор

Илл. 5.61. Основные типы ICMP-сообщений

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

Сообщение TIME EXCEEDED (время истекло) отправляется, когда пакет игнорируется, так как его счетчик TtL (Time to live) уменьшился до нуля. Это событие — признак того, что пакеты двигаются по зацикленному пути или что установлено слишком низкое значение таймера.

В 1987 году Ван Джейкобсон (Van Jacobson) предложил хитрый способ использования этого сообщения об ошибке — утилиту traceroute. Она находит маршрутизаторы, расположенные в узлах пути от хоста к получателю. При этом ей не требуется особый уровень поддержки. Метод состоит в отправке на адрес назначения последовательности пакетов с TtL 1, 2, 3 и т.д. Счетчики в пакетах достигают нуля по мере прохождения через маршрутизаторы на пути. Каждый маршрутизатор послушно отправляет обратно на хост сообщение TIME EXCEEDED. Так хост определяет их IP-адреса и получает информацию о маршруте. Конечно, TIME EXCEEDED предназначалось не для этого. Но вполне возможно, что это самый полезный инструмент отладки сети за всю историю.

Сообщение PARAMETER PROBLEM (проблема параметра) указывает на то, что обнаружено ошибочное значение в поле заголовка. Это признак наличия ошибки в программном обеспечении хоста, отправившего этот пакет, или промежуточного маршрутизатора.

Сообщение SOURCE QUENCH (подавление источника) ранее использовалось для «усмирения» хостов, которые отправляли слишком много пакетов. Хост, получивший такое сообщение, должен был снизить свою активность. В настоящее время SOURCE QUENCH используется редко, так как при возникновении перегрузки эти пакеты только подливают масла в огонь, еще больше загружая сеть. К тому же неясно, как на них отвечать. Теперь борьба с перегрузкой в интернете осуществляется в основном на транспортном уровне; а сигналом перегрузки является утеря пакетов. В главе 6 мы подробно обсудим, как это происходит.

Сообщение REDIRECT (переадресовать) отсылается хосту-источнику, когда маршрутизатор замечает, что у пакета ошибка в адресе назначения. Таким способом маршрутизатор предлагает хосту обновить путь.

Сообщения ECHO (запрос отклика) и ECHO REPLY (отклик) отправляются, чтобы определить, достижим ли в данный момент конкретный адресат и функционирует ли он. Получив ECHO, хост должен ответить сообщением ECHO REPLY. Эти сообщения используются утилитой ping, которая проверяет, работает ли хост и подключен ли он к интернету.

Сообщения TIMESTAMP REQUEST (запрос временной метки) и TIMESTAMP REPLY (отклик с временной меткой) имеют то же назначение, но при этом в ответе проставляется время получения сообщения и время отправления ответа. Этот механизм применяется для измерения производительности сети.

Сообщения ROUTER ADVERTISEMENT (обнаружение маршрутизатора) и ROUTER SOLICITATION (запрос к маршрутизатору) позволяют хостам находить ближайшие маршрутизаторы. Хосту необходимо знать IP-адрес хотя бы одного из них, чтобы он мог передавать пакеты за пределы LAN.

Кроме перечисленных сообщений определены и другие. Их полный список хранится в интернете по адресу www.iana.org/assignments/icmp-parameters.

ARP — протокол разрешения адресов

Хотя у каждого устройства в интернете есть один или несколько IP-адресов, их недостаточно для отправки пакетов. Сетевые карты канального уровня, например Ethernet-карты, не понимают интернет-адресов. Каждая когда-либо выпущенная сетевая карта Ethernet имеет 48-разрядный Ethernet-адрес. Производители карт запрашивают у IEEE блок Ethernet-адресов, что гарантирует их уникальность (это позволяет избежать конфликтов при наличии одинаковых сетевых карт в одной LAN). Сетевые карты отправляют и принимают фреймы, основываясь на 48-разрядных Ethernet-адресах. О 32-разрядных IP-адресах им ничего не известно.

Таким образом, возникает вопрос: как устанавливается соответствие IP-адресов и адресов уровня передачи данных (например, Ethernet-адресов)? Чтобы понять, как это работает, рассмотрим пример на илл. 5.62. Здесь изображен небольшой университет с двумя сетями /24. На рисунке мы видим две коммутируемые сети Ethernet: одна сеть (CS) на факультете кибернетики, с префиксом 192.31.65.0/24, а другая (EE) — на электротехническом факультете, с префиксом 192.31.63.0/24. Они соединены IP-маршрутизатором. У каждого компьютера сети и у каждого интерфейса на маршрутизаторе есть уникальный Ethernet-адрес (на рисунке — от E1 до E6) и уникальный IP-адрес в сети CS или EE.

Рассмотрим, как пользователь хоста 1 передает пакет пользователю хоста 2 в сети CS. Допустим, отправителю известно имя получателя, eagle.cs.uni.edu. Сначала надо найти IP-адрес для хоста 2. Этот поиск осуществляется службой системы имен доменов DNS (Domain Name System), которую мы рассмотрим в главе 7. На данный момент мы просто предположим, что служба DNS возвращает IP-адрес для хоста 2 (192.32.65.5).

Илл. 5.62. Две коммутируемые LAN Ethernet, соединенные маршрутизатором

Теперь программное обеспечение верхнего уровня хоста 1 создает пакет со значением 192.31.65.5 в поле Destination address и передает его IP-программе для пересылки. Программное обеспечение IP может посмотреть на адрес и увидеть, что адресат находится в сети CS (то есть в его собственной сети), но ему нужно как-то определить Ethernet-адрес получателя. Одно из решений состоит в том, чтобы хранить в системе конфигурационный файл, в котором были бы перечислены соответствия всех локальных IP-адресов Ethernet-адресам. Такое решение, конечно, возможно, но в организациях с тысячами компьютеров обновление этих файлов потребует много времени и подвержено ошибкам.

Более удачное решение заключается в рассылке хостом 1 по сети Ethernet широковещательного пакета с вопросом: «Кому принадлежит IP-адрес 192.32.65.5?» Этот пакет будет получен всеми компьютерами сети CS Ethernet, и каждый из них проверит его IP-адрес. Только хост 2 ответит на вопрос своим Ethernet-адресом E2. Таким образом, хост 1 узнает, что IP-адрес 192.32.65.5 принадлежит хосту с Ethernet-адресом E2. Протокол, который задает подобный вопрос и получает ответ на него, называется протоколом разрешения адресов (Address Resolution Protocol, ARP) и описан в RFC 826. Он работает почти на всех устройствах интернета.

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

Затем программное обеспечение протокола IP хоста 1 создает Ethernet-фрейм для E2, помещает в его поле Payload IP-пакет, адресованный 192.32.65.5, и передает его по сети Ethernet. IP- и Ethernet-адреса этого пакета приведены на илл. 5.62. Сетевая карта Ethernet хоста 2 обнаруживает фрейм, замечает, что он адресован ей, считывает его и вызывает прерывание. Ethernet-драйвер извлекает IP-пакет из поля Payload и передает его IP-программе. Эта программа видит, что пакет адресован правильно, и обрабатывает его.

Существует несколько методов повышения эффективности ARP. Во-первых, компьютер, на котором он работает, может запоминать результат преобразования адреса на случай, если ему придется снова связываться с тем же устройством. В следующий раз он найдет нужный адрес в своем кэше, сэкономив на рассылке широковещательного пакета. Скорее всего, хосту 2 понадобится ответить на пакет, что также потребует от него обращения к ARP для определения адреса отправителя. Этого обращения можно избежать, если отправитель включит в ARP-пакет свои IP- и Ethernet-адреса. Когда широковещательный ARP-пакет прибудет на хост 2, пара (192.32.65.7, E1) будет сохранена хостом 2 в ARP-кэше для будущего использования. Более того, эту пару адресов могут сохранить у себя все устройства сети Ethernet.

Чтобы разрешить изменение соответствий адресов, например, если хост использует новый IP-адрес (но Ethernet-адрес остается прежним), записи в ARP-кэше должны устаревать за несколько минут. Существует хороший способ поддержания актуальности информации об адресах в кэше, улучшая производительность. Идея в том, что каждое устройство может рассылать свою пару адресов во время настройки. Обычно эта широковещательная рассылка производится в виде ARP-пакета, запрашивающего свой собственный IP-адрес. Ответа на такой запрос быть не должно, но все устройства могут запомнить эту пару адресов. Это называется добровольным ARP-сообщением (gratuitous ARP). Если ответ все же (неожиданно) придет, это будет означать, что двум компьютерам назначен один и тот же IP-адрес. Они не смогут пользоваться сетью, пока проблема не будет решена системным администратором.

Посмотрим снова на илл. 5.62. Пусть на этот раз хост 1 хочет послать пакет хосту 4 (192.32.63.8) в сети EE. Хост 1 увидит, что IP-адрес получателя не относится к сети CS. Он знает, что такие внешние пакеты нужно передавать на маршрутизатор, который иногда называют шлюзом по умолчанию (default gateway). Принято, что шлюз по умолчанию имеет наименьший адрес сети (198.32.65.1). Но чтобы отправить фрейм на этот маршрутизатор, хост 1 должен знать еще и Ethernet-адрес интерфейса маршрутизатора в сети CS. Поэтому он отправляет широковещательный ARP-пакет для 198.32.65.1 и узнает E3. После этого он отправляет фрейм. Аналогичным образом пакеты передаются от одного маршрутизатора к другому на всем пути до места назначения.

Когда сетевая карта Ethernet получает этот фрейм, она передает пакет на обработку программным средствам IP. По сетевым маскам маршрутизатор понимает, что пакет должен быть доставлен на хост 4 в сети EE. Если ему неизвестен Ethernet-адрес хоста 4, он снова использует ARP, чтобы узнать его. В таблице на илл. 5.62 приведен список Ethernet- и IP-адресов из фреймов сетей CS и EE. Обратите внимание на то, что для одного фрейма в разных сетях Ethernet-адреса меняются, а IP-адреса — нет (так как они указывают на конечную точку во всех объединенных сетях).

Существует способ передать пакет от хоста 1 хосту 4 так, чтобы отправитель не знал, что получатель находится в другой сети. Нужно, чтобы маршрутизатор отвечал на ARP-запросы сети CS для хоста 4, передавая при этом свой Ethernet-адрес E3. Хост 4 не ответит, так как не увидит широковещательного пакета (маршрутизаторы не переправляют широковещательные пакеты Ethernet-уровня). В результате маршрутизатор получит фреймы для 192.32.63.8 и передаст их в сеть EE. Этот метод называется ARP-прокси (ARP-proxy) и используется в особых случаях, когда хосту требуется сымитировать свое присутствие в сети. Например, когда портативный компьютер находится вне домашней сети и хочет, чтобы какой-то другой узел принимал для него пакеты.

DHCP — протокол динамической настройки хостов

ARP (как и другие интернет-протоколы) предполагает, что хосты обладают базовыми сведениями, например, знают свой IP-адрес. Но как хосты получают эту информацию? Можно настраивать их вручную, но это очень трудоемкий процесс, часто ведущий к ошибкам. Есть более удобный способ — протокол динамической настройки хостов (Dynamic Host Configuration Protocol, DHCP).

Каждая сеть должна иметь DHCP-сервер, отвечающий за настройки. При запуске у каждого компьютера есть Ethernet-адрес, встроенный в сетевую карту (или другой адрес канального уровня), но нет IP-адреса. В поисках своего IP-адреса компьютер широковещательным способом рассылает специальный пакет DHCP DISCOVER (Обнаружение DHCP). Он должен прийти на DHCP-сервер. Если сервер не подключен к сети напрямую, пакет будет ретранслирован на DHCP-сервер независимо от того, где он находится.

Когда DHCP-сервер получает пакет, он выделяет свободный IP-адрес и отправляет его обратно с помощью пакета DHCP OFFER (Предложение DHCP) (который также может ретранслироваться). Даже если у хоста нет IP-адреса, сервер определяет хост по его Ethernet-адресу (который содержится в пакете DHCP DISCOVER).

Возникает вопрос: на какое время можно выдавать в автоматическом режиме IP-адреса из пула? Если хост покинет сеть и не освободит захваченный адрес, этот адрес будет навсегда утерян. С течением времени будет исчезать все больше адресов. Чтобы это предотвратить, IP-адреса выдаются не навсегда, а на определенное время. Это называется арендой (leasing). Перед окончанием срока действия аренды хост отправляет на DHCP-сервер запрос о продлении срока пользования IP-адресом. Если запрос не был сделан или в просьбе было отказано, хост не имеет права продолжать использование выданного ранее адреса.

Протокол DHCP описан в стандартах RFC 2131 и 2132. Он широко применяется в интернете для настройки ряда параметров и приписывания IP-адресов. Помимо сетей предприятий и домашних сетей, DHCP используют провайдеры. С его помощью они настраивают устройства через интернет-соединение, чтобы абонентам не приходилось узнавать эту информацию у своего провайдера по телефону. Чаще всего с помощью DHCP передается маска сети, IP-адрес шлюза по умолчанию, а также IP-адреса DNS и серверов времени. DHCP во многом заменил более ранние протоколы RARP и BOOTP, функциональность которых оставляла желать лучшего.

5.7.5. Коммутация меток и MPLS

До сих пор, изучая сетевой уровень интернета, мы говорили в основном о пакетах и дейтаграммах, передаваемых IP-маршрутизаторами. Сейчас все чаще используется (особенно провайдерами) еще одна технология, позволяющая передавать интернет-трафик по сети, — мультипротокольная коммутация меток (MultiProtocol Label Switching, MPLS). Она находится в опасной близости к коммутации каналов. Хотя многие участники интернет-сообщества испытывают неприязнь к сетям, ориентированным на установление соединения, похоже, что эта идея снова становится популярной. Как сказал Йоги Берра (Yogi Berra)33, «и снова это дежавю». Но между созданием маршрутов в интернете и в сетях с установлением соединения есть существенная разница, так что этот метод все же отличается от коммутации каналов.

MPLS присваивает пакету специальную метку, и пересылка производится по ней, а не по адресу. Если добавить метки во внутреннюю таблицу в виде индексов, то чтобы найти нужный выходной канал, достаточно всего лишь ее просмотреть, что существенно ускоряет пересылку. Эта идея легла в основу MPLS. Изначально она разрабатывалась как патентованная технология, известная под разными именами, например, коммутация меток (tag switching). В конечном счете IETF начал стандартизировать эту идею. Она описана в RFC 3031 и многих других RFC. Ее главные преимущества, проверенные временем, — гибкая маршрутизация и быстрая передача пакетов, позволяющая обеспечить необходимый уровень QoS.

Первая проблема заключается в том, куда поставить метку. IP-пакеты не предназначены для виртуальных каналов, и в их заголовке не предусмотрено место для номеров таких каналов. Значит, нужно добавлять новый заголовок MPLS в начало IP-пакета. На линии между маршрутизаторами используется протокол, включающий заголовки PPP, MPLS, IP и TCP (илл. 5.63).

Илл. 5.63. Передача TCP-сегмента с использованием IP, MPLS и PPP

Обычно в заголовок MPLS входит четыре поля, наиболее важное из которых — поле Label (Метка), в котором содержится индекс. Поле QoS указывает на применяемый класс обслуживания. Поле S связано со стеком меток (речь об этом пойдет ниже). Поле TtL показывает, сколько еще раз пакет можно переслать. Его значение уменьшается на каждом маршрутизаторе; если оно равно 0, пакет игнорируется. Благодаря этому исключаются бесконечные циклы при сбое маршрутизации.

MPLS располагается между протоколом сетевого уровня IP и протоколом канального уровня PPP. Этот уровень нельзя назвать третьим, так как метки задаются на основе IP-адреса или другого адреса сетевого уровня. Но это и не второй уровень хотя бы потому, что MPLS контролирует передачу пакета на нескольких транзитных участках, а не на одном. Иногда его называют протоколом уровня 2.5. Это яркий пример того, что реальные протоколы не всегда вписываются в идеальную уровневую модель.

Заголовки MPLS не являются частью пакетов сетевого уровня и не имеют отношения к фреймам канального уровня. Поэтому MPLS — это метод, не зависящий от этих уровней. Помимо прочего, это свойство означает, что можно создать такие коммутаторы MPLS, которые могут по необходимости пересылать как IP-, так и не-IP-пакеты. Именно отсюда следует «мультипротокольность», отраженная в названии MPLS. Также он может передавать IP-пакеты через не-IP-сети.

Когда пакет, расширенный за счет заголовка MPLS, прибывает на маршрутизатор коммутации меток (Label Switched Router, LSR), извлеченная из него метка используется в качестве индекса таблицы. Далее по таблице определяется исходящая линия и значение новой метки. Смена меток используется во всех сетях с виртуальными каналами. Метки имеют только локальное значение, и два разных маршрутизатора могут снабдить независимые пакеты одной меткой, если их нужно направить на одну и ту же линию третьего маршрутизатора. Поэтому, чтобы метки можно было различить на стороне получателя, их приходится менять при каждом переходе. Мы видели этот механизм в действии — на илл. 5.3. В MPLS используется такой же метод.

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

Так как большинство хостов и маршрутизаторов не воспринимают MPLS, мы могли бы задаться вопросом, как и когда метки прикрепляются к пакетам. Это происходит в тот момент, когда пакет достигает границы MPLS-сети. Пограничный маршрутизатор (Label Edge Router, LER) проверяет IP-адрес назначения и другие поля, определяя, по какому MPLS-пути должен пойти пакет, и присваивает пакету соответствующую метку. По ней пакет пересылается в сети MPLS. На другой границе MPLS-сети метка уже не нужна, и она удаляется, после чего IP-пакет становится открытым для другой сети. Этот процесс показан на илл. 5.64. От традиционных виртуальных каналов он отличается уровнем агрегации. Конечно, можно каждому проходящему через MPLS-сеть потоку дать собственный набор меток. Но более распространенный прием — группировка потоков, заканчивающихся на данном маршрутизаторе или в данной LAN, и использование для них одной метки. Такие потоки принадлежат одному классу эквивалентности пересылок (Forwarding Equivalence Class, FEC). В него входят пакеты, идущие по одному и тому же маршруту и обслуживаемые по одному классу (в терминах дифференцированного обслуживания), поскольку при пересылке все они обрабатываются одинаково.

Илл. 5.64. Пересылка IP-пакета через MPLS-сеть

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

На самом деле MPLS идет дальше. Этот протокол может работать одновременно на многих уровнях, используя несколько меток. Представьте себе ряд пакетов с различными метками (например, если сеть должна по-разному их обрабатывать). Они должны пройти один и тот же путь до определенного адреса. В таком случае мы можем задать для всех пакетов один путь. Когда пакеты, уже имеющие метку, попадают в стартовую точку пути, в начало пакета записывается новая метка. Это называется стеком меток. Внешняя метка служит проводником пакета по маршруту. В конце пути она удаляется, и оставшиеся метки (если они есть) ведут пакет дальше. Бит S (см. илл. 5.63) позволяет маршрутизатору, удаляющему метку, узнать, есть ли еще метки у пакета. Единичное значение бита сообщает, что метка — последняя в стеке, а нулевое значение говорит об обратном.

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

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

Основные идеи MPLS просты, однако его детали чрезвычайно запутанны, при этом существует множество вариаций, находящихся в стадии активной разработки. Дополнительную информацию можно найти в книгах Дейви и Фаррела (Davie and Farrel, 2008), а также Дейви и Рехтера (Davie and Rekhter, 2000).

5.7.6. Протокол внутреннего шлюза OSPF

Итак, мы изучили процесс передачи пакетов в интернете. Перейдем к новой теме — маршрутизации в интернете. Мы уже упоминали, что интернет состоит из множества независимых сетей или автономных систем, АС (Autonomous Systems, AS), которыми управляют различные организации — компании, университеты, провайдеры. В своей сети организация может использовать собственный алгоритм внутридоменной (или внутренней) маршрутизации (intradomain routing). Но популярных стандартных протоколов существует совсем немного. В этом разделе мы рассмотрим внутридоменную маршрутизацию и популярный протокол OSPF. Протокол внутридоменной маршрутизации также называют протоколом внутреннего шлюза (Interior Gateway Protocol, IGP). В следующем разделе мы обсудим маршрутизацию между независимыми сетями — междоменную маршрутизацию (interdomain routing). В этом случае все сети должны использовать один и тот же протокол междоменной маршрутизации, или протокол внешнего шлюза (exterior gateway protocol). В интернете применяется протокол пограничной маршрутизации (Border Gateway Protocol, BGP). Мы подробно обсудим его в разделе 5.7.7.

Изначально в качестве протокола внутридоменной маршрутизации использовалась схема маршрутизации по вектору расстояний, основанная на распределенном алгоритме Беллмана — Форда (Bellman — Ford) и унаследованная от ARPANET. В первую очередь это использующийся до сих пор протокол маршрутной информации (Routing Information Protocol, RIP). Он хорошо работал в небольших системах, но по мере увеличения АС стали проявляться его недостатки (к примеру, проблема счета до бесконечности и медленная сходимость), поэтому в мае 1979 года он был заменен протоколом состояния каналов. В 1988 году IETF начал работу над протоколом внутридоменной маршрутизации, учитывающим состояние линий. Он получил название открытого алгоритма предпочтительного выбора кратчайшего маршрута (Open Shortest Path First, OSPF) и был признан стандартом в 1990 году. Идея была заимствована из протокола связи между промежуточными системами (Intermediate System to Intermediate System, IS-IS), ставшего стандартом ISO. У OSPF и IS-IS больше сходств, чем различий. Более подробное описание см. в RFC 2328.

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

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

В-четвертых (это требование впервые было предъявлено именно к OSPF), он должен поддерживать выбор маршрутов, основываясь на типе службы. Новый протокол должен уметь по-разному выбирать путь трафика реального времени и других видов трафика. В то время IP-пакет содержал поле Type of service, но ни один из имевшихся протоколов маршрутизации не использовал его. Это поле было и в OSPF, но и здесь оно игнорировалось. Поэтому в результате его убрали. Возможно, это требование опередило свое время, так как появилось до дифференцированного обслуживания, возродившего классы обслуживания.

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

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

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

OSPF поддерживает двухточечные линии (например, SONET) и широковещательные сети (большинство LAN). Он также поддерживает сети с множественными маршрутизаторами, каждый из которых может напрямую соединяться с любым другим (сети множественного доступа — multi-access networks), даже если в них невозможно широковещание. Предыдущие протоколы не так хорошо справлялись с этой задачей.

На илл. 5.65 (а) показан пример АС. Здесь не указаны хосты, так как обычно они не играют большой роли в OSPF. Значительно важнее — маршрутизаторы и сети (которые могут содержать хосты). Большинство маршрутизаторов соединены между собой двухточечными линиями, а также с сетями, к хостам

Илл. 5.65. Сеть множественного доступа. (а) Автономная система. (б) Представление (а) в виде графа

которых им нужен доступ. Но R3, R4 и R5 соединены широковещательной LAN, например коммутируемой Ethernet.

В основе работы OSPF лежит обобщенное представление о множестве сетей, маршрутизаторов и каналов в виде направленного графа, каждому ребру которого присвоен весовой коэффициент (расстояние, задержка и т.д.). Двухточечное соединение между двумя маршрутизаторами представляется в виде пары ребер, по одному в каждом направлении. Их веса могут различаться. Широковещательная сеть представляется в виде узла для самой сети, а также в виде узла для каждого маршрутизатора. Ребра, идущие от сетевого узла к узлам маршрутизаторов, обладают нулевым весом. Но они все равно важны, так как без них не будет пути через сеть. У других сетей, состоящих исключительно из хостов, имеются ребра, ведущие только к ним; ребра в обратном направлении отсутствуют. То есть маршруты к хостам возможны, а через них — нет.

Сеть на илл. 5.65 (а) представлена в виде графа на илл. 5.65 (б). По сути, как раз это и делает OSPF. Когда представление в виде графа получено, маршрутизаторы могут вычислить кратчайшие пути до всех остальных узлов с помощью метода, учитывающего состояние линий. Возможно, некоторые пути одинаково короткие. Тогда OSPF запоминает оба пути и использует их для разделения трафика. Этот метод называется использованием множества равноценных маршрутов (Equal Cost MultiPath, ECMP). С его помощью нагрузка распределяется более равномерно.

Многие АС в интернете сами по себе довольно крупные, и управлять ими непросто. OSPF позволяет делить их на пронумерованные области (areas), то есть на сети или множества смежных сетей. Области не должны перекрываться, но не обязаны быть исчерпывающими: некоторые маршрутизаторы могут не принадлежать ни к одной из них. Если маршрутизатор полностью принадлежит к какой-то области, он называется внутренним маршрутизатором (internal router). Область — это обобщение отдельной сети. За пределами области видны ее адреса, но не ее топология. Это упрощает масштабирование процесса маршрутизации.