Сетевой уровень — различия между версиями
Juliet (обсуждение | вклад) |
Avalanche (обсуждение | вклад) (→ICMP) |
||
| (не показано 9 промежуточных версий 2 участников) | |||
| Строка 4: | Строка 4: | ||
Пропуская через себя пакеты, промежуточные компьютеры не обращают внимания на заголовки прикладного и транспортного уровней. А вот информация, хранящаяся в заголовке сетевого уровня для них имеет большое значение. По этой информации они определяют по какому интерфейсу и кому передать пакет дальше. | Пропуская через себя пакеты, промежуточные компьютеры не обращают внимания на заголовки прикладного и транспортного уровней. А вот информация, хранящаяся в заголовке сетевого уровня для них имеет большое значение. По этой информации они определяют по какому интерфейсу и кому передать пакет дальше. | ||
| − | Таким образом, получается, что в передаче сообщения принимают участие прикладные программы и драйверы транспортного уровня только конечных компьютеров, а драйверы сетевого уровня | + | Таким образом, получается, что в передаче сообщения принимают участие прикладные программы и драйверы транспортного уровня только конечных компьютеров, а драйверы сетевого уровня — всех компьютеров в цепочке. |
===Основные составляющие=== | ===Основные составляющие=== | ||
| − | *'''Протокол IP''' | + | * '''Протокол IP'''. Работает на всех компьютерах в цепочке передачи. На каждом решает кому отправить дальше (таблицы маршрутизации); |
| − | *'''Протоколы маршрутизации''' | + | * '''Протоколы маршрутизации'''. Позволяют динамически менять таблицы маршрутизации; |
| − | *Иерархическая система адресации ('''IP-адреса'''). | + | * '''Иерархическая система адресации''' ('''IP-адреса'''). |
===IP-адреса=== | ===IP-адреса=== | ||
| − | IP-адрес | + | IP-адрес — это 4-байтовое число (32 разряда), например, 192.168.10.153. Он присваивается каждому интерфейсу. Примерами интерфейса являются сетевая карта, модем. |
| − | |||
| − | |||
| − | Он присваивается каждому интерфейсу. | ||
Считается, что IP-адрес состоит из двух частей: | Считается, что IP-адрес состоит из двух частей: | ||
| − | + | * '''сетевая часть''' (номер подсети); | |
| − | + | * '''интерфейсная часть''' (номер интерфейса узла). | |
| − | IP-адреса образуют иерархическую систему адресации, которая позволяет определить местоположение. | + | IP-адреса образуют иерархическую систему адресации, которая позволяет определить местоположение. У оконечной системы может быть несколько IP-адресов (если несколько интерфейсов). Нет строгого разделения, где заканчивается сетевая часть и начинается интерфейсная. |
| − | + | В случае изолированной сети её адрес может быть выбран администратором из специально зарезервированных для таких сетей блоков адресов (192.168.0.0/16, 172.16.0.0/12 или 10.0.0.0/8). Если же сеть должна работать как составная часть Интернета, то адрес сети выдаётся провайдером либо '''региональным интернет-регистратором''' (Regional Internet Registry, RIR). Существует пять RIR: | |
| − | + | * ARIN, обслуживающий Северную Америку; | |
| − | + | * APNIC, обслуживающий страны Юго-Восточной Азии; | |
| + | * AfriNIC, обслуживающий страны Африки; | ||
| + | * LACNIC, обслуживающий страны Южной Америки и бассейна Карибского моря; | ||
| + | * RIPE NCC, обслуживающий Европу, Центральную Азию, Ближний Восток. | ||
| − | + | Региональные регистраторы получают номера автономных систем и большие блоки адресов у IANA, а затем выдают номера автономных систем и блоки адресов меньшего размера '''локальным интернет-регистраторам''' (Local Internet Registries, LIR), обычно являющимся крупными провайдерами. | |
| − | === | + | ===Разделение сетей на классы=== |
| − | Нетрудно посчитать, что всего в пространстве адресов IP | + | [[Файл:Разделение IP-адресов на классы.JPG|500px|thumb|left|Разделение IP-адресов на классы]] |
| − | + | Нетрудно посчитать, что всего в пространстве адресов IP — 128 сетей по 16 777 216 адресов класса A, 16384 сети по 65536 адресов класса B и 2 097 152 сети по 256 адресов класса C, а также 268 435 456 адресов многоадресной рассылки и 134 317 728 зарезервированных адресов. С ростом сети Интернет эта система оказалась неэффективной и была вытеснена CIDR (бесклассовой адресацией). Такое разделение на классы устарело. | |
| − | |||
| − | |||
| − | |||
{{Hider | {{Hider | ||
|title = Историческая справка. | |title = Историческая справка. | ||
|content = | |content = | ||
| − | Before classes | + | '''Before classes''' |
| + | |||
Originally, the 32-bit IPv4 address consisted simply of an 8-bit network number field (which specified the particular network a host was attached to), and a rest field, which gave the address of the host within that network. This format was chosen before the advent of local area networks (LANs), when there were only a few, large, networks such as the ARPANET. | Originally, the 32-bit IPv4 address consisted simply of an 8-bit network number field (which specified the particular network a host was attached to), and a rest field, which gave the address of the host within that network. This format was chosen before the advent of local area networks (LANs), when there were only a few, large, networks such as the ARPANET. | ||
This resulted in a very low number (254) of possible independent networks, and very early on, as local area networks started to appear, it became obvious that this would not be enough. | This resulted in a very low number (254) of possible independent networks, and very early on, as local area networks started to appear, it became obvious that this would not be enough. | ||
| − | Classes | + | |
| + | '''Classes''' | ||
| + | |||
To remain compatible with the existing IP address space and the IP packet structure, the definition of IP addresses was changed in 1981 in RFC 791 to allow unicast addresses with three different sizes of the network number field (and the associated rest field), as specified in the table (см. рис.) | To remain compatible with the existing IP address space and the IP packet structure, the definition of IP addresses was changed in 1981 in RFC 791 to allow unicast addresses with three different sizes of the network number field (and the associated rest field), as specified in the table (см. рис.) | ||
The number of usable host addresses available is always 2N - 2 (where N is the number of bits used, and the subtraction of 2 adjusts for the use of the all-bits-zero host portion for network address and the all-bits-one host portion as a broadcast address. Thus, for a Class C address with 8 bits available in the host field, the number of hosts is 254. | The number of usable host addresses available is always 2N - 2 (where N is the number of bits used, and the subtraction of 2 adjusts for the use of the all-bits-zero host portion for network address and the all-bits-one host portion as a broadcast address. Thus, for a Class C address with 8 bits available in the host field, the number of hosts is 254. | ||
| Строка 48: | Строка 48: | ||
The IP address netmask, which is commonly associated with an IPv4 address today, was not required because the mask was implicitly derived from the IP address itself. Any network device would inspect the first few bits of the IP address to determine the class of the address. | The IP address netmask, which is commonly associated with an IPv4 address today, was not required because the mask was implicitly derived from the IP address itself. Any network device would inspect the first few bits of the IP address to determine the class of the address. | ||
The method of comparing the network numbers of two IP addresses did not change (see subnet). For each address, the network number field size and its subsequent value were determined (the rest field was ignored). The network numbers were then compared. If they matched, then the two addresses were on the same network. | The method of comparing the network numbers of two IP addresses did not change (see subnet). For each address, the network number field size and its subsequent value were determined (the rest field was ignored). The network numbers were then compared. If they matched, then the two addresses were on the same network. | ||
| − | The replacement of classes | + | |
| + | '''The replacement of classes''' | ||
| + | |||
The first design changes extended the addressing capability in the Internet, but did not prevent IP address shortage. The principal problem was that too many sites were too big for a Class C network number, and therefore received a Class B block. With the rapid growth of the Internet, the available pool of Class B addresses (214, or about 16,000 total) was rapidly being depleted. Classful networking was replaced by Classless Inter-Domain Routing (CIDR), starting in about 1993, to attempt to solve this problem. | The first design changes extended the addressing capability in the Internet, but did not prevent IP address shortage. The principal problem was that too many sites were too big for a Class C network number, and therefore received a Class B block. With the rapid growth of the Internet, the available pool of Class B addresses (214, or about 16,000 total) was rapidly being depleted. Classful networking was replaced by Classless Inter-Domain Routing (CIDR), starting in about 1993, to attempt to solve this problem. | ||
Early allocations of IP addresses by IANA were in some cases not made very efficiently, which contributed to the problem. (However, the commonly held notion that some American organizations unfairly or unnecessarily received Class A networks is wrong; most such allocations date to the period before the introduction of address classes, when the only address blocks available were what later became known as Class A networks.) | Early allocations of IP addresses by IANA were in some cases not made very efficiently, which contributed to the problem. (However, the commonly held notion that some American organizations unfairly or unnecessarily received Class A networks is wrong; most such allocations date to the period before the introduction of address classes, when the only address blocks available were what later became known as Class A networks.) | ||
| Строка 54: | Строка 56: | ||
===Бесклассовая адресация=== | ===Бесклассовая адресация=== | ||
| − | Проблема нехватки IP-адресов решилась предоставлением сети возможности разделения на несколько частей. Например, вместо одного адреса класса В с 14 битами для номера сети и 16 битами для номера хоста было предложено использовать несколько другой формат — формировать адрес подсети из нескольких битов. Например, если в университете существует 35 подразделений, то 6-битным номером можно кодировать подсети, а 10-битным — номера хостов. С помощью такой адресации можно организовать до 64 сетей по 1022 хоста в каждой (адреса 0 и | + | [[Файл:Бесклассовая адресация.JPG|400px|thumb|rigth|Бесклассовая адресация]] |
| + | Проблема нехватки IP-адресов решилась предоставлением сети возможности разделения на несколько частей. Например, вместо одного адреса класса В с 14 битами для номера сети и 16 битами для номера хоста было предложено использовать несколько другой формат — формировать адрес подсети из нескольких битов. Например, если в университете существует 35 подразделений, то 6-битным номером можно кодировать подсети, а 10-битным — номера хостов. С помощью такой адресации можно организовать до 64 сетей по 1022 хоста в каждой (адреса 0 и 1 не используются, как уже говорилось, поэтому не 1024 , а именно 1022 хоста). | ||
===Иерархия IP-адресов=== | ===Иерархия IP-адресов=== | ||
| + | [[Файл:Иерархия IP-адресов.JPG|500px|left]] | ||
| + | <br clear="both" /> | ||
===Зарезервированные адреса=== | ===Зарезервированные адреса=== | ||
| Строка 66: | Строка 71: | ||
===Пример=== | ===Пример=== | ||
| − | + | [[Файл:Пример. Сети.JPG|500px|rigth]] | |
| − | |||
| − | Из Танненбаума | + | На рисунке NAT нет. Изображено всего 7 сетей: 3 (между маршрутизаторами) (192.168.2.0, 192.168.3.0 и 192.168.1.0) + 4 (172.17.0.0, 10.0.0.0, 172.16.0.0, 192.168.4.0). |
| + | |||
| + | [[Файл:Route print.JPG|500px|thumb|left|Таблица маршрутизации. Результат команды route print]] | ||
| + | <!--Из Танненбаума--> | ||
Чтобы понять, как функционируют подсети, следует рассмотреть процесс обработки IP-пакетов маршрутизатором. У каждого маршрутизатора есть таблица,содержащая IP-адреса сетей (вида <сетъ, 0>) и IP-адреса хостов (вида <эта_сеть, хост>). Адреса сетей позволяют получать доступ к удаленным сетям, а адреса хостов — обращаться к локальным хостам. С каждой таблицей связан сетевой интерфейс, применяющийся для получения доступа к пункту назначения, а также другая информация. Когда IP-пакет прибывает на маршрутизатор, адрес получателя, указанный в пакете, ищется в таблице маршрутизации. Если пакет направляется в удаленную сеть, он пересылается следующему маршрутизатору по интерфейсу, указанному | Чтобы понять, как функционируют подсети, следует рассмотреть процесс обработки IP-пакетов маршрутизатором. У каждого маршрутизатора есть таблица,содержащая IP-адреса сетей (вида <сетъ, 0>) и IP-адреса хостов (вида <эта_сеть, хост>). Адреса сетей позволяют получать доступ к удаленным сетям, а адреса хостов — обращаться к локальным хостам. С каждой таблицей связан сетевой интерфейс, применяющийся для получения доступа к пункту назначения, а также другая информация. Когда IP-пакет прибывает на маршрутизатор, адрес получателя, указанный в пакете, ищется в таблице маршрутизации. Если пакет направляется в удаленную сеть, он пересылается следующему маршрутизатору по интерфейсу, указанному | ||
в таблице. Если пакет предназначен локальному хосту (например, в локальной сети маршрутизатора), он посылается напрямую адресату. Если номера сети, в которую посылается пакет, в таблице маршрутизатора нет, пакет пересылается маршрутизатору по умолчанию, с более подробными таблицами. Такой алгоритм означает, что каждый маршрутизатор должен учитывать только другие сети и локальные хосты, а не пары <сеть, хост>, что значительно уменьшает размер таблиц маршрутизатора. | в таблице. Если пакет предназначен локальному хосту (например, в локальной сети маршрутизатора), он посылается напрямую адресату. Если номера сети, в которую посылается пакет, в таблице маршрутизатора нет, пакет пересылается маршрутизатору по умолчанию, с более подробными таблицами. Такой алгоритм означает, что каждый маршрутизатор должен учитывать только другие сети и локальные хосты, а не пары <сеть, хост>, что значительно уменьшает размер таблиц маршрутизатора. | ||
| − | === | + | ===Формат IP-дейтаграммы=== |
| − | + | [[Файл:Формат IP-дейтаграммы.JPG|400px|thumb|right|Формат IP-дейтаграммы]] | |
| + | IP-дейтаграмма состоит из заголовка и текстовой части. Заголовок содержит обязательную 20-байтную часть, а также необязательную часть переменной длины. Формат заголовка показан на рисунке. Поле ''Версия'' содержит версию протокола, к которому принадлежит дейтаграмма. Включение версии в каждую дейтаграмму позволяет использовать разные версии протокола на разных машинах. Дело в том, что с годами протокол изменялся, и на одних машинах сейчас работают новые версии, тогда как на других продолжают использоваться старые. Сейчас происходит переход от версии IPv4 к версии IPv6. Он длится уже много лет, и не похоже, что скоро завершится. Длина заголовка является переменной величиной, для хранения которой выделено поле IHL (информация в нем представлена в виде 32-разрядных слов). Минимальное значение длины (при отсутствии необязательного поля) равно 5. Максимальное значение этого 4-битового поля равно 15, что соответствует заголовку длиной 60 байт; таким образом, максимальный размер необязательного поля равен 40 байтам. Для некоторых приложений, например, для записи маршрута, по которому должен быть переслан пакет, 40 байт слишком мало. В данном случае дополнительное поле оказывается бесполезным. | ||
| − | + | Поле ''Тип службы'' — единственное поле, смысл которого с годами несколько изменился. Оно было (впрочем, и до сих пор) предназначено для различения классов обслуживания. Возможны разные комбинации надежности и скорости. Для оцифрованного голоса скорость доставки важнее точности. При передаче файла, наоборот, передача без ошибок важнее быстрой доставки. Изначально 6-разрядное поле ''Тип службы'' состояло из трехразрядного поля ''Precedence'' и трех флагов — ''D'', ''Т'' и ''R''. Поле ''Precedence'' указывало приоритет, от 0 (нормальный) до 7 (управляющий сетевой пакет). Три флаговых бита позволяли хосту указать, что беспокоит его сильнее всего, выбрав из набора {Delay, Throughput, Reliability} (Задержка, Пропускная способность, Надежность). Теоретически, эти поля позволяют маршрутизаторам выбрать, например, между спутниковой линией с высокой пропускной способностью и большой задержкой и выделенной линией с низкой пропускной способностью и небольшой задержкой. На практике сегодняшние маршрутизаторы часто вообще игнорируют поле | |
| − | + | ''Тип службы''. Поле ''Полная длина'' содержит длину всей дейтаграммы, включая как заголовок, так и данные. Максимальная длина дейтаграммы 65 535 байт. В настоящий момент этот верхний предел достаточен, однако с появлением гигабитных сетей могут понадобиться дейтаграммы большего размера. (когда Таненбаум это писал, гигабитных сетей еще не было) Поле Идентификатор позволяет хосту-получателю определить, какой дейта- | |
| − | Поле Тип службы — единственное поле, смысл которого с годами несколько изменился. Оно было (впрочем, и до сих пор) предназначено для различения классов обслуживания. Возможны разные комбинации надежности и скорости. Для оцифрованного голоса скорость доставки важнее точности. При передаче файла, наоборот, передача без ошибок важнее быстрой доставки. Изначально 6-разрядное поле Тип службы состояло из трехразрядного поля Precedence и трех флагов — D, Т и R. Поле Precedence указывало приоритет, от 0 (нормальный) до 7 (управляющий сетевой пакет). Три флаговых бита позволяли хосту указать, что беспокоит его сильнее всего, выбрав из набора {Delay, Throughput, Reliability} (Задержка, Пропускная способность, Надежность). Теоретически, эти поля позволяют маршрутизаторам выбрать, например, между спутниковой линией с высокой пропускной способностью и большой задержкой и выделенной линией с низкой пропускной способностью и небольшой задержкой. На практике сегодняшние маршрутизаторы часто вообще игнорируют поле | ||
| − | Тип службы. Поле Полная длина содержит длину всей дейтаграммы, включая как заголовок, так и данные. Максимальная длина дейтаграммы 65 535 байт. В настоящий момент этот верхний предел достаточен, однако с появлением гигабитных сетей могут понадобиться дейтаграммы большего размера. (когда Таненбаум это писал, гигабитных сетей еще не было) Поле Идентификатор позволяет хосту-получателю определить, какой дейта- | ||
грамме принадлежат полученные им фрагменты. Все фрагменты одной дейтаграммы содержат одно и то же значение идентификатора. Следом идет один неиспользуемый бит и два однобитных поля. Бит DF означает Don't Fragment (He фрагментировать). Это команда маршрутизатору, запрещающая ему фрагментировать дейтаграмму, так как получатель не сможет восстановить ее из фрагментов. Например, при загрузке компьютера его ПЗУ | грамме принадлежат полученные им фрагменты. Все фрагменты одной дейтаграммы содержат одно и то же значение идентификатора. Следом идет один неиспользуемый бит и два однобитных поля. Бит DF означает Don't Fragment (He фрагментировать). Это команда маршрутизатору, запрещающая ему фрагментировать дейтаграмму, так как получатель не сможет восстановить ее из фрагментов. Например, при загрузке компьютера его ПЗУ | ||
может запросить образ памяти в виде единой дейтаграммы. Пометив дейтаграмму битом DF, отправитель гарантирует, что дейтаграмма дойдет единым блоком, даже если для ее доставки придется избегать сетей с маленьким размером пакетов. От всех машин требуется способность принимать фрагменты размером 576 байт и менее. | может запросить образ памяти в виде единой дейтаграммы. Пометив дейтаграмму битом DF, отправитель гарантирует, что дейтаграмма дойдет единым блоком, даже если для ее доставки придется избегать сетей с маленьким размером пакетов. От всех машин требуется способность принимать фрагменты размером 576 байт и менее. | ||
| − | Бит MF означает More Fragments (Продолжение следует). Он устанавливается во всех фрагментах, кроме последнего. По этому биту получатель узнает о прибытии последнего фрагмента дейтаграммы. Поле Смещение фрагмента указывает положение фрагмента в исходной дейтаграмме. Длина всех фрагментов в байтах, кроме длины последнего фрагмента, должна быть кратна 8. Так как на это поле выделено 13 бит, максимальное количество фрагментов в дейтаграмме равно 8192, что дает максимальную длину дейтаграммы 65 536 байт, на 1 байт больше, чем может содержаться в поле Полная длина. | + | Бит ''MF'' означает More Fragments (Продолжение следует). Он устанавливается во всех фрагментах, кроме последнего. По этому биту получатель узнает о прибытии последнего фрагмента дейтаграммы. Поле ''Смещение фрагмента'' указывает положение фрагмента в исходной дейтаграмме. Длина всех фрагментов в байтах, кроме длины последнего фрагмента, должна быть кратна 8. Так как на это поле выделено 13 бит, максимальное количество фрагментов в дейтаграмме равно 8192, что дает максимальную длину дейтаграммы 65 536 байт, на 1 байт больше, чем может содержаться в поле ''Полная длина''. |
| − | Поле Время жизни (Число переходов) представляет собой счетчик, ограничивающий время жизни пакета. Предполагалось, что он будет отсчитывать время в секундах, таким образом, допуская максимальное время жизни пакета в 255 с. На каждом маршрутизаторе это значение должно было уменьшаться как минимум на единицу плюс время стояния в очереди. Однако на практике этот счетчик просто считает количество переходов через маршрутизаторы. Когда значение этого поля становится равным нулю, пакет отвергается, а отправителю отсылается пакет с предупреждением. Таким образом удается избежать вечного странствования пакетов, | + | Поле ''Время жизни'' (''Число переходов'') представляет собой счетчик, ограничивающий время жизни пакета. Предполагалось, что он будет отсчитывать время в секундах, таким образом, допуская максимальное время жизни пакета в 255 с. На каждом маршрутизаторе это значение должно было уменьшаться как минимум на единицу плюс время стояния в очереди. Однако на практике этот счетчик просто считает количество переходов через маршрутизаторы. Когда значение этого поля становится равным нулю, пакет отвергается, а отправителю отсылается пакет с предупреждением. Таким образом удается избежать вечного странствования пакетов, что может произойти, если таблицы маршрутизаторов по какой-либо причине испортятся. |
| − | что может произойти, если таблицы маршрутизаторов по какой-либо причине испортятся. | ||
| − | Собрав дейтаграмму из фрагментов, сетевой уровень должен решить, что с ней делать. Поле Протокол сообщит ему, какому процессу транспортного уровня ее передать. Это может быть TCP, UDP или что-нибудь еще. Нумерация процессов глобально стандартизирована по всему Интернету. Номера протоколов вместе с некоторыми другими были сведены в RFC 1700, однако теперь доступна интернет-версия в виде базы данных, расположенной по адресу www.iana.org. Поле Контрольная сумма заголовка защищает от ошибок только заголовок. Подобная контрольная сумма полезна для обнаружения ошибок, вызванных неисправными микросхемами памяти маршрутизаторов. Алгоритм вычисления суммы просто складывает все 16-разрядные полуслова в дополнительном коде, преобразуя результат также в дополнительный код. Таким образом, проверяемая получателем контрольная сумма заголовка (вместе с этим полем) должна быть равна нулю. Этот алгоритм надежнее, чем обычное суммирование. Обратите внимание на то, что значение Контрольной суммы заголовка должно подсчитываться заново на каждом транзитном участке, так как по крайней мере одно поле постоянно меняется (поле Время жизни). Для ускорения расчетов применяются некоторые хитрости. | + | Собрав дейтаграмму из фрагментов, сетевой уровень должен решить, что с ней делать. Поле ''Протокол'' сообщит ему, какому процессу транспортного уровня ее передать. Это может быть TCP, UDP или что-нибудь еще. Нумерация процессов глобально стандартизирована по всему Интернету. Номера протоколов вместе с некоторыми другими были сведены в RFC 1700, однако теперь доступна интернет-версия в виде базы данных, расположенной по адресу www.iana.org. Поле ''Контрольная сумма'' заголовка защищает от ошибок только заголовок. Подобная контрольная сумма полезна для обнаружения ошибок, вызванных неисправными микросхемами памяти маршрутизаторов. Алгоритм вычисления суммы просто складывает все 16-разрядные полуслова в дополнительном коде, преобразуя результат также в дополнительный код. Таким образом, проверяемая получателем контрольная сумма заголовка (вместе с этим полем) должна быть равна нулю. Этот алгоритм надежнее, чем обычное суммирование. Обратите внимание на то, что значение ''Контрольной суммы'' заголовка должно подсчитываться заново на каждом транзитном участке, так как по крайней мере одно поле постоянно меняется (поле ''Время жизни''). Для ускорения расчетов применяются некоторые хитрости. |
| − | Поля Адрес отправителя и Адрес получателя указывают номер сети и номер | + | Поля ''Адрес отправителя'' и ''Адрес получателя'' указывают номер сети и номер хоста. Поле ''Необязательная часть'' (Параметры) было создано для того, чтобы с появлением новых вариантов протокола не пришлось вносить в заголовок поля, отсутствующие в нынешнем формате. Оно же может служить пространством для различного рода экспериментов, испытания новых идей. Кроме того, оно позволяет не включать в стандартный заголовок редко используемую информацию. |
| − | |||
| − | |||
| − | |||
| − | испытания новых идей. Кроме того, оно позволяет не включать в стандартный | ||
| − | заголовок редко используемую информацию. | ||
===Служебные протоколы=== | ===Служебные протоколы=== | ||
| − | ===ICMP=== | + | ====ICMP==== |
| − | Internet Control Message Protocol — межсетевой протокол управляющих сообщений. | + | '''ICMP''' (Internet Control Message Protocol) — межсетевой протокол управляющих сообщений. Основная задача — передача информации об ошибках в дейтаграммах. Используется в программах ping (проверяет работает ли удаленный компьютер) и traceroute (определяет маршрут следования данных в сетях TCP/IP). |
| − | + | {{Hider | |
| + | |title = Использование в traceroute | ||
| + | |content = | ||
| + | Программа traceroute – определение маршрута до заданной оконечной системы. Принципы работы: | ||
| + | # На нужную оконечную систему отправляется серия дейтаграмм с разным временем жизни (1,2,3,…N; max=64). При получении устаревшей дейтаграммы маршрутизатор отвечает специальным ICMP сообщением. | ||
| + | # Программа запрашивает время между отправкой дейтаграммы и получением соответствующего ICMP сообщения. В ответ включается имя маршрутизатора. | ||
| + | # В итоге формируется список маршрутизаторов на основе ICMP – сообщений. | ||
| + | }} | ||
| + | {{Hider | ||
| + | |title = Типы ICMP сообщений | ||
| + | |content = | ||
| + | * ICMP сообщения (тип 12) генерируются при нахождении ошибок в заголовке IP пакета (за исключением самих ICMP пакетов, дабы не привести к бесконечно растущему потоку ICMP сообщений об ICMP сообщениях). | ||
| + | * ICMP сообщения (тип 3) генерируются маршрутизатором при отсутствии маршрута к адресату. | ||
| + | * Утилита ping, служащая для проверки возможности доставки IP пакетов использует ICMP сообщения с типом 8 (эхо-запрос) и 0 (эхо-ответ). | ||
| + | * Утилита traceroute, отображающая путь следования IP пакетов, использует ICMP сообщения с типом 11. | ||
| + | * ICMP сообщения с типом 5 используются маршрутизаторами для обновления записей в таблице маршрутизации отправителя. | ||
| + | * ICMP сообщения с типом 4 используются получателем (или промежуточным маршрутизатором) для управления скоростью отправки сообщений отправителем. | ||
| + | }} | ||
| − | + | ====DHCP==== | |
| + | '''DHCP''' (Dynamic Host Configuration Protocol — протокол динамического конфигурирования узлов) позволяет компьютерам автоматически получать IP-адрес и другие параметры. | ||
| − | + | DHCP — это сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Для этого компьютер обращается к специальному серверу, называемому '''сервером DHCP'''. Сетевой администратор может задать диапазон адресов, распределяемых среди компьютеров. Это позволяет избежать ручной настройки компьютеров сети и уменьшает количество ошибок. Протокол DHCP используется в большинстве крупных (и не очень) сетей TCP/IP. | |
| − | + | Протокол DHCP предоставляет три способа распределения IP-адресов: | |
| − | + | * '''Ручное распределение'''. При этом способе сетевой администратор сопоставляет аппаратному адресу (обычно MAC-адресу) каждого клиентского компьютера определённый IP-адрес. Фактически, данный способ распределения адресов отличается от ручной настройки каждого компьютера лишь тем, что сведения об адресах хранятся централизованно (на сервере DHCP), и потому их проще изменять при необходимости. | |
| − | + | * '''Автоматическое распределение'''. При данном способе каждому компьютеру на постоянное использование выделяется произвольный свободный IP-адрес из определённого администратором диапазона. | |
| − | + | * '''Динамическое распределение'''. Этот способ аналогичен автоматическому распределению, за исключением того, что адрес выдаётся компьютеру не на постоянное пользование, а на определённый срок. Это называется арендой адреса. По истечении срока аренды IP-адрес вновь считается свободным, и клиент обязан запросить новый (он, впрочем, может оказаться тем же самым). | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Некоторые реализации службы DHCP способны автоматически обновлять записи DNS, соответствующие клиентским компьютерам, при выделении им новых адресов. | Некоторые реализации службы DHCP способны автоматически обновлять записи DNS, соответствующие клиентским компьютерам, при выделении им новых адресов. | ||
| − | ====Принципы работы DHCP==== | + | =====Принципы работы DHCP===== |
| − | Компьютер отправляет широковещательный UDP-пакет: | + | * Компьютер отправляет широковещательный UDP-пакет: «Кто может назначить мне IP-адрес?» |
| − | «Кто может назначить мне IP | + | * DHCP-серверы сети отправляют в ответ DHCP-предложения. |
| − | + | * Клиент получает список предложений, выбирает нужное и отправляет DHCP-запрос на конкретный сервер. | |
| − | DHCP | + | * От сервера приходит DHCP-подтверждение (в нем указывается IP-адрес, присвоенный клиенту). |
| − | |||
| − | Клиент получает список предложений, выбирает нужное и отправляет DHCP-запрос на конкретный сервер | ||
| − | От сервера приходит DHCP-подтверждение (в нем указывается IP | ||
===Решение проблемы нехватки IP-адресов (NAT)=== | ===Решение проблемы нехватки IP-адресов (NAT)=== | ||
| − | NAT ( | + | '''NAT''' (Network Address Translation — «преобразование сетевых адресов») — это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов. |
| − | '''Транзитными''' пакеты могут быть для коммуникационного оборудования (если вы настроили ваш ПК как роутер | + | '''Транзитными''' пакеты могут быть для коммуникационного оборудования (если вы настроили ваш ПК как роутер/гейт, то он также может считаться коммуникационным оборудованием). Задача коммуникаторов — доставлять по адресу приходящие пакеты. Пакеты, которые не предназначены самому коммуникатору, а должны быть перенаправлены и доставлены другому адресату можно уже назвать транзитными. Хотя есть еще один контекст этого понятия. Обычно коммуникаторы ставят на границе локальной и внешней сети. Если пакет пришел в один из портов коммуникатора из внешней сети, и должен быть перенаправлен в другой порт внешней сети, то его называют транзитным. |
Преобразование адресов методом NAT может производиться почти любым маршрутизирующим устройством — маршрутизатором, сервером доступа, межсетевым экраном. Суть механизма состоит в замене адреса источника (source) при прохождении пакета в одну сторону и обратной замене адреса назначения (destination) в ответном пакете. Наряду с адресами source/destination могут также заменяться номера портов source/destination. | Преобразование адресов методом NAT может производиться почти любым маршрутизирующим устройством — маршрутизатором, сервером доступа, межсетевым экраном. Суть механизма состоит в замене адреса источника (source) при прохождении пакета в одну сторону и обратной замене адреса назначения (destination) в ответном пакете. Наряду с адресами source/destination могут также заменяться номера портов source/destination. | ||
| Строка 158: | Строка 151: | ||
При инициации соединения изнутри сети создаётся '''трансляция'''. Ответные пакеты, поступающие снаружи, соответствуют созданной трансляции и поэтому пропускаются. Если для пакетов, поступающих снаружи, соответствующей трансляции не существует (а она может быть созданной при инициации соединения или статической), они не пропускаются. | При инициации соединения изнутри сети создаётся '''трансляция'''. Ответные пакеты, поступающие снаружи, соответствуют созданной трансляции и поэтому пропускаются. Если для пакетов, поступающих снаружи, соответствующей трансляции не существует (а она может быть созданной при инициации соединения или статической), они не пропускаются. | ||
| − | ===Недостатки=== | + | ====Недостатки==== |
* Не все протоколы могут «преодолеть» NAT. Некоторые не в состоянии работать, если на пути между взаимодействующими хостами есть трансляция адресов. Некоторые межсетевые экраны, осуществляющие трансляцию IP-адресов, могут исправить этот недостаток, соответствующим образом заменяя IP-адреса не только в заголовках IP, но и на более высоких уровнях (например, в командах протокола FTP). Из-за трансляции адресов «много в один» появляются дополнительные сложности с идентификацией пользователей и необходимость хранить полные логи трансляций. | * Не все протоколы могут «преодолеть» NAT. Некоторые не в состоянии работать, если на пути между взаимодействующими хостами есть трансляция адресов. Некоторые межсетевые экраны, осуществляющие трансляцию IP-адресов, могут исправить этот недостаток, соответствующим образом заменяя IP-адреса не только в заголовках IP, но и на более высоких уровнях (например, в командах протокола FTP). Из-за трансляции адресов «много в один» появляются дополнительные сложности с идентификацией пользователей и необходимость хранить полные логи трансляций. | ||
* DoS со стороны узла, осуществляющего NAT — если NAT используется для подключения многих пользователей к одному и тому же сервису, это может вызвать иллюзию DoS атаки на сервис (множество успешных и неуспешных попыток). Например, избыточное количество пользователей ICQ за NAT’ом приводит к проблеме подключения некоторых пользователей из-за превышения допустимой скорости коннектов к серверу. Частичным решением проблемы является использование пула адресов (группы адресов), для которых осуществляется трансляция. | * DoS со стороны узла, осуществляющего NAT — если NAT используется для подключения многих пользователей к одному и тому же сервису, это может вызвать иллюзию DoS атаки на сервис (множество успешных и неуспешных попыток). Например, избыточное количество пользователей ICQ за NAT’ом приводит к проблеме подключения некоторых пользователей из-за превышения допустимой скорости коннектов к серверу. Частичным решением проблемы является использование пула адресов (группы адресов), для которых осуществляется трансляция. | ||
| − | * Сложности в работе с пиринговыми сетями, в которых необходимо не только инициировать исходящие соединения, но также принимать входящие. | + | * Сложности в работе с пиринговыми сетями, в которых необходимо не только инициировать исходящие соединения, но также принимать входящие. |
| − | ===Маршрутизация | + | ===Маршрутизация=== |
| − | Маршрутизатор(устройство) получает пакет и должен отправить его дальше, но кому? | + | Маршрутизатор (устройство) получает пакет и должен отправить его дальше, но кому? |
'''Маршрутизация''' (англ. routing) — это процесс определения маршрута следования информации в сетях связи. | '''Маршрутизация''' (англ. routing) — это процесс определения маршрута следования информации в сетях связи. | ||
| − | Зачастую в его таблицах маршрутизации есть несколько записей для заданной в пакете сети назначения. Тогда маршрутизатор смотрит на значение метрики. | + | Зачастую в его таблицах маршрутизации есть несколько записей для заданной в пакете сети назначения. Тогда маршрутизатор смотрит на значение метрики. Он выбирает маршрут с наименьшей метрикой. Метрика назначается для каждого сетевого интерфейса. |
| − | |||
| − | Он выбирает маршрут с наименьшей метрикой. Метрика назначается для каждого сетевого интерфейса. | ||
В зависимости от того как вносятся изменения в таблицы маршрутов, маршрутизация называется '''статической''' или '''динамической'''. Существуют специальные протоколы, которые описывают правила согласования таблиц маршрутизации множества маршрутизаторов в какой-нибудь сети. Они называются '''протоколами маршрутизации'''. | В зависимости от того как вносятся изменения в таблицы маршрутов, маршрутизация называется '''статической''' или '''динамической'''. Существуют специальные протоколы, которые описывают правила согласования таблиц маршрутизации множества маршрутизаторов в какой-нибудь сети. Они называются '''протоколами маршрутизации'''. | ||
| − | + | Протоколы обмена маршрутной информацией (протоколы маршрутизации) реализуют следующие типов алгоритмов: | |
* дистанционно-векторный алгоритм (Distance Vector Algorithms, DVA); | * дистанционно-векторный алгоритм (Distance Vector Algorithms, DVA); | ||
| − | * алгоритм состояния связей (Link State Algorithms, LSA). | + | * алгоритм состояния связей (Link State Algorithms, LSA); |
| + | * другие (например, гибридный протокол маршрутизации EIGRP от Cisco). | ||
| − | ===Алгоритмы дистанционно-векторного типа=== | + | ====Алгоритмы дистанционно-векторного типа==== |
В алгоритмах дистанционно-векторного типа каждый маршрутизатор периодически и широковещательно рассылает по сети вектор расстояний от себя до всех известных ему сетей. Под расстоянием обычно понимается число промежуточных маршрутизаторов через которые пакет должен пройти прежде, чем попадет в соответствующую сеть. Может использоваться и другая метрика, учитывающая не только число перевалочных пунктов, но и время прохождения пакетов по связи между соседними маршрутизаторами. Получив вектор от соседнего маршрутизатора, каждый маршрутизатор добавляет к нему информацию об известных ему других сетях, о которых он узнал непосредственно (если они подключены к его портам) или из аналогичных объявлений других маршрутизаторов, а затем снова рассылает новое значение вектора по сети. В конце-концов, каждый маршрутизатор узнает информацию об имеющихся в интерсети сетях и о расстоянии до них через соседние маршрутизаторы. | В алгоритмах дистанционно-векторного типа каждый маршрутизатор периодически и широковещательно рассылает по сети вектор расстояний от себя до всех известных ему сетей. Под расстоянием обычно понимается число промежуточных маршрутизаторов через которые пакет должен пройти прежде, чем попадет в соответствующую сеть. Может использоваться и другая метрика, учитывающая не только число перевалочных пунктов, но и время прохождения пакетов по связи между соседними маршрутизаторами. Получив вектор от соседнего маршрутизатора, каждый маршрутизатор добавляет к нему информацию об известных ему других сетях, о которых он узнал непосредственно (если они подключены к его портам) или из аналогичных объявлений других маршрутизаторов, а затем снова рассылает новое значение вектора по сети. В конце-концов, каждый маршрутизатор узнает информацию об имеющихся в интерсети сетях и о расстоянии до них через соседние маршрутизаторы. | ||
| Строка 187: | Строка 179: | ||
Наиболее распространенным протоколом, основанным на дистанционно-векторном алгоритме, является протокол RIP. | Наиболее распространенным протоколом, основанным на дистанционно-векторном алгоритме, является протокол RIP. | ||
| − | ===Алгоритмы состояния связей=== | + | ====Алгоритмы состояния связей==== |
Алгоритмы состояния связей обеспечивают каждый маршрутизатор информацией, достаточной для построения точного графа связей сети. Все маршрутизаторы работают на основании одинаковых графов, что делает процесс маршрутизации более устойчивым к изменениям конфигурации. Широковещательная рассылка используется здесь только при изменениях состояния связей, что происходит в надежных сетях не так часто. | Алгоритмы состояния связей обеспечивают каждый маршрутизатор информацией, достаточной для построения точного графа связей сети. Все маршрутизаторы работают на основании одинаковых графов, что делает процесс маршрутизации более устойчивым к изменениям конфигурации. Широковещательная рассылка используется здесь только при изменениях состояния связей, что происходит в надежных сетях не так часто. | ||
| Строка 193: | Строка 185: | ||
Протоколом, основанным на алгоритме состояния связей, в стеке TCP/IP является протокол OSPF. | Протоколом, основанным на алгоритме состояния связей, в стеке TCP/IP является протокол OSPF. | ||
| − | ===Иерархическая маршрутизация=== | + | ====Иерархическая маршрутизация==== |
| − | Вся сеть разбивается на вложенные подсети. | + | Вся сеть разбивается на вложенные подсети. Внутри каждой автономной подсети используются протоколы '''внутренней маршрутизации'''. Автономные системы соединяются друг с другом с помощью шлюзов (gateway). Маршрутизация между этими шлюзами — '''внешняя маршрутизация'''. Все вместе это может быть также автономной подсетью. |
| − | Внутри каждой автономной подсети используются протоколы '''внутренней маршрутизации'''. | ||
| − | Автономные системы соединяются друг с другом с помощью шлюзов (gateway). | ||
| − | Маршрутизация между этими шлюзами — '''внешняя маршрутизация'''. | ||
| − | Все вместе это может быть также автономной подсетью. | ||
Протоколы: | Протоколы: | ||
| − | внутренняя: RIP (Routing Internet Protocol) и OPSF (Open Shortest Path First) | + | * внутренняя маршрутизация: RIP (Routing Internet Protocol) и OPSF (Open Shortest Path First); |
| − | внешняя: BGP (Border Gateway Protocol) | + | * внешняя маршрутизация: BGP (Border Gateway Protocol). |
<!--Танненбаум--> | <!--Танненбаум--> | ||
| − | При использовании иерархической маршрутизации маршрутизаторы разбиваются на отдельные, так называемые, | + | При использовании иерархической маршрутизации маршрутизаторы разбиваются на отдельные, так называемые, регионы. Каждый маршрутизатор знает все детали выбора маршрутов в пределах своей области, но ему ничего не известно о внутреннем строении других регионов. При объединении нескольких сетей естественно рассматривать их как отдельные регионы, при этом маршрутизаторы одной сети освобождаются от необходимости знать топологию других сетей. В очень больших сетях двухуровневой иерархии <!--написать что это--> может оказаться недостаточно. Может потребоваться группировать регионы в кластеры, кластеры в зоны, зоны в группы, и т. д., пока у нас не иссякнет фантазия на названия для новых образований. |
| − | ====RIP | + | =====RIP===== |
| − | Протокол '''RIP''' ( | + | Протокол '''RIP''' (Routing Information Protocol) — это один из наиболее распространенных протоколов маршрутизации в небольших компьютерных сетях, который позволяет маршрутизаторам динамически обновлять маршрутную информацию (направление и дальность в хопах<!--написать что это-->), получая ее от соседних маршрутизаторов. |
| − | Протокол RIP представляет собой один из старейших протоколов обмена маршрутной информацией, | + | Протокол RIP представляет собой один из старейших протоколов обмена маршрутной информацией, он до сих пор чрезвычайно распространен в вычислительных сетях. |
{{Hider | {{Hider | ||
| Строка 218: | Строка 206: | ||
}} | }} | ||
| − | В этом протоколе все сети имеют номера (способ образования номера зависит от используемого в сети протокола сетевого уровня), а все маршрутизаторы — идентификаторы. Протокол RIP широко использует понятие | + | В этом протоколе все сети имеют номера (способ образования номера зависит от используемого в сети протокола сетевого уровня), а все маршрутизаторы — идентификаторы. Протокол RIP широко использует понятие «вектор расстояний». Вектор расстояний представляет собой набор пар чисел, являющихся номерами сетей и расстояниями до них в хопах. |
| + | |||
| + | Вектора расстояний итерационно распространяются маршрутизаторами по сети, и через несколько шагов каждый маршрутизатор имеет данные о достижимых для него сетях и о расстояниях до них. Если связь с какой-либо сетью обрывается, то маршрутизатор отмечает этот факт тем, что присваивает элементу вектора, соответствующему расстоянию до этой сети, максимально возможное значение, которое имеет специальный смысл — "связи нет". Таким значением в протоколе RIP является число 16. | ||
| + | |||
| + | {| {{prettytable}} align="center" | ||
| + | |- | ||
| + | | [[Файл:RIP.JPG]] | ||
| + | | | ||
| + | <div style="text-align: center;"> | ||
| + | {| {{prettytable}} | ||
| + | |+ Таблица 1.<br>Начальная информация в узле 2 | ||
| + | |- style="background: #DDFFDD;" | ||
| + | ! Сеть | ||
| + | ! Расстояние | ||
| + | ! Сосед | ||
| + | |- | ||
| + | | A | ||
| + | | 1 | ||
| + | | — | ||
| + | |- | ||
| + | | B | ||
| + | | 1 | ||
| + | | — | ||
| + | |- | ||
| + | | C | ||
| + | | 1 | ||
| + | | — | ||
| + | |} | ||
| + | </div> | ||
| + | | | ||
| + | <div style="text-align: center;"> | ||
| + | {| {{prettytable}} | ||
| + | |+ Таблица 2.<br>Информация в узле 2 после двух шагов | ||
| + | |- style="background: #DDFFDD;" | ||
| + | ! Сеть | ||
| + | ! Расстояние | ||
| + | ! Сосед | ||
| + | |- | ||
| + | | A | ||
| + | | 1 | ||
| + | | — | ||
| + | |- | ||
| + | | B | ||
| + | | 1 | ||
| + | | — | ||
| + | |- | ||
| + | | C | ||
| + | | 1 | ||
| + | | — | ||
| + | |- | ||
| + | | D | ||
| + | | 2 | ||
| + | | 3 | ||
| + | |- | ||
| + | | E | ||
| + | | 2 | ||
| + | | 5 | ||
| + | |- | ||
| + | | D | ||
| + | | 3 | ||
| + | | 5 | ||
| + | |- | ||
| + | | F | ||
| + | | 3 | ||
| + | | 5 | ||
| + | |} | ||
| + | </div> | ||
| + | |} | ||
| − | + | На рисунке цифрами обозначены маршрутизаторы. Каждый маршрутизатор хранит у себя вектор дистанций. Вектор дистанций — это таблица, где указаны IP-адреса сетей (первый столбец), расстояние до этих сетей в хопах ('''хоп''' — это количество ребер на графе) (второй столбец) и какому следующему маршрутизатору нужно отправить, чтобы пакет дошел до нужной сети. Буквами A, B, C, D, E, F обозначены сети между каждыми двумя маршрутизаторами. | |
| − | + | В таблице 1 приведена начальная информация, содержащаяся в топологической базе маршрутизатора 2, а в таблице 2 — информация в этой же базе после двух итераций обмена маршрутными пакетами протокола RIP. После определенного числа итераций маршрутизатор 2 будет знать о расстояниях до всех сетей интерсети, причем у него может быть несколько альтернативных вариантов отправки пакета к сети назначения. | |
| − | При необходимости отправить пакет в сеть D маршрутизатор просматривает свою базу данных маршрутов и выбирает порт, имеющий наименьшее расстояния до сети назначения (в данном случае порт, связывающий его с маршрутизатором 3). | + | Пусть в нашем примере сетью назначения является сеть D. При необходимости отправить пакет в сеть D маршрутизатор просматривает свою базу данных маршрутов и выбирает порт, имеющий наименьшее расстояния до сети назначения (в данном случае порт, связывающий его с маршрутизатором 3). |
Для адаптации к изменению состояния связей и оборудования с каждой записью таблицы маршрутизации связан таймер. Если за время тайм-аута не придет новое сообщение, подтверждающее этот маршрут, то он удаляется из маршрутной таблицы. | Для адаптации к изменению состояния связей и оборудования с каждой записью таблицы маршрутизации связан таймер. Если за время тайм-аута не придет новое сообщение, подтверждающее этот маршрут, то он удаляется из маршрутной таблицы. | ||
| Строка 230: | Строка 285: | ||
При использовании протокола RIP работает эвристический алгоритм динамического программирования Беллмана-Форда, и решение, найденное с его помощью является не оптимальным, а близким к оптимальному. Преимуществом протокола RIP является его вычислительная простота, а недостатками — увеличение трафика при периодической рассылке широковещательных пакетов и неоптимальность найденного маршрута. | При использовании протокола RIP работает эвристический алгоритм динамического программирования Беллмана-Форда, и решение, найденное с его помощью является не оптимальным, а близким к оптимальному. Преимуществом протокола RIP является его вычислительная простота, а недостатками — увеличение трафика при периодической рассылке широковещательных пакетов и неоптимальность найденного маршрута. | ||
| − | ===Неустойчивая работа при изменении конфигурации=== | + | ======Неустойчивая работа при изменении конфигурации====== |
| − | На рисунке показан случай неустойчивой работы сети по протоколу RIP при изменении конфигурации | + | [[Файл:Неустойчивая работа при изменении конфигурации.JPG|300px|left]] |
| + | На рисунке показан случай неустойчивой работы сети по протоколу RIP при изменении конфигурации - отказе линии связи маршрутизатора M1 с сетью 1. При работоспособном состоянии этой связи в таблице маршрутов каждого маршрутизатора есть запись о сети с номером 1 и соответствующим расстоянием до нее. | ||
| − | При обрыве связи с сетью 1 маршрутизатор М1 отмечает, что расстояние до этой сети приняло значение 16. Однако получив через некоторое время от маршрутизатора М2 маршрутное сообщение о том, что от него до сети 1 расстояние составляет 2 хопа, маршрутизатор М1 наращивает это расстояние на 1 и отмечает, что сеть 1 достижима через маршрутизатор 2. В результате пакет, предназначенный для сети 1, будет циркулировать между маршрутизаторами М1 и М2 до тех пор, пока не истечет время хранения записи о сети 1 в маршрутизаторе | + | При обрыве связи с сетью 1 маршрутизатор М1 отмечает, что расстояние до этой сети приняло значение 16. Однако получив через некоторое время от маршрутизатора М2 маршрутное сообщение о том, что от него до сети 1 расстояние составляет 2 хопа, маршрутизатор М1 наращивает это расстояние на 1 и отмечает, что сеть 1 достижима через маршрутизатор 2. В результате пакет, предназначенный для сети 1, будет циркулировать между маршрутизаторами М1 и М2 до тех пор, пока не истечет время хранения записи о сети 1 в маршрутизаторе 2, и он не передаст эту информацию маршрутизатору М1. |
Для исключения подобных ситуаций маршрутная информация об известной маршрутизатору сети не передается тому маршрутизатору, от которого она пришла. | Для исключения подобных ситуаций маршрутная информация об известной маршрутизатору сети не передается тому маршрутизатору, от которого она пришла. | ||
| − | + | =====OSPF===== | |
| − | + | Протокол '''OSPF''' (Open Shortest Path Firs) является достаточно современной реализацией алгоритма состояния связей (он принят в 1991 году) и обладает многими особенностями, ориентированными на применение в больших гетерогенных сетях. | |
| − | ==== | ||
| − | Протокол '''OSPF''' (Open Shortest Path Firs) является достаточно современной реализацией алгоритма состояния связей (он принят в 1991 году) и обладает многими особенностями, ориентированными на применение в больших гетерогенных | ||
Протокол OSPF вычисляет маршруты в IP-сетях, сохраняя при этом другие протоколы обмена маршрутной информацией. | Протокол OSPF вычисляет маршруты в IP-сетях, сохраняя при этом другие протоколы обмена маршрутной информацией. | ||
| − | Непосредственно связанные (то есть достижимые без использования промежуточных маршрутизаторов) маршрутизаторы называются | + | Непосредственно связанные (то есть достижимые без использования промежуточных маршрутизаторов) маршрутизаторы называются '''соседями'''. Каждый маршрутизатор хранит информацию о том, в каком состоянии по его мнению находится сосед. Маршрутизатор полагается на соседние маршрутизаторы и передает им пакеты данных только в том случае, если он уверен, что они полностью работоспособны. Для выяснения состояния связей маршрутизаторы-соседи достаточно часто обмениваются короткими сообщениями HELLO. |
Для распространения по сети данных о состоянии связей маршрутизаторы обмениваются сообщениями другого типа. Эти сообщения называются '''router links advertisement''' — объявление о связях маршрутизатора (точнее, о состоянии связей). OSPF-маршрутизаторы обмениваются не только своими, но и чужими объявлениями о связях, получая в конце-концов информацию о состоянии всех связей сети. Эта информация и образует граф связей сети, который, естественно, один и тот же для всех маршрутизаторов сети. | Для распространения по сети данных о состоянии связей маршрутизаторы обмениваются сообщениями другого типа. Эти сообщения называются '''router links advertisement''' — объявление о связях маршрутизатора (точнее, о состоянии связей). OSPF-маршрутизаторы обмениваются не только своими, но и чужими объявлениями о связях, получая в конце-концов информацию о состоянии всех связей сети. Эта информация и образует граф связей сети, который, естественно, один и тот же для всех маршрутизаторов сети. | ||
| Строка 252: | Строка 306: | ||
Маршрутизатор вычисляет оптимальный маршрут до каждой адресуемой сети, но запоминает только первый промежуточный маршрутизатор из каждого маршрута. Таким образом, результатом вычислений оптимальных маршрутов является список строк, в которых указывается номер сети и идентификатор маршрутизатора, которому нужно переслать пакет для этой сети. Указанный список маршрутов и является маршрутной таблицей, но вычислен он на основании полной информации о графе связей сети, а не частичной информации, как в протоколе RIP. | Маршрутизатор вычисляет оптимальный маршрут до каждой адресуемой сети, но запоминает только первый промежуточный маршрутизатор из каждого маршрута. Таким образом, результатом вычислений оптимальных маршрутов является список строк, в которых указывается номер сети и идентификатор маршрутизатора, которому нужно переслать пакет для этой сети. Указанный список маршрутов и является маршрутной таблицей, но вычислен он на основании полной информации о графе связей сети, а не частичной информации, как в протоколе RIP. | ||
| − | Представим себе один день из жизни транзитной локальной сети. Пусть у нас имеется сеть Ethernet, в которой есть три маршрутизатора | + | [[Файл:Протокол состояния связей OSPF.JPG|300px|left]] |
| − | + | Представим себе один день из жизни транзитной локальной сети. Пусть у нас имеется сеть Ethernet, в которой есть три маршрутизатора — Джон, Фред и Роб (имена членов рабочей группы Internet, разработавшей протокол OSPF). Эти маршрутизаторы связаны с сетями в других городах с помощью выделенных линий. | |
| − | |||
| − | + | Пусть произошло восстановление сетевого питания после сбоя. Маршрутизаторы и компьютеры перезагружаются и начинают работать по сети Ethernet. После того, как маршрутизаторы обнаруживают, что порты Ethernet работают нормально, они начинают генерировать сообщения HELLO, которые говорят о их присутствии в сети и их конфигурации. Однако маршрутизация пакетов начинает осуществляться не сразу — сначала маршрутизаторы должны синхронизировать свои маршрутные базы. | |
| − | Когда период отказа маршрутизатора истекает, то маршрутизатор с наивысшим приоритетом и наибольшим идентификатором объявляет себя выделенным (а следующий за ним по приоритету маршрутизатор объявляет себя резервным выделенным маршрутизатором) и начинает синхронизировать свою базу данных с другими маршрутизаторами. | + | На протяжении интервала отказа маршрутизаторы продолжают посылать сообщения HELLO. Когда какой-либо маршрутизатор посылает такое сообщение, другие его получают и отмечают, что в локальной сети есть другой маршрутизатор. Когда они посылают следующее HELLO, они перечисляют там и своего нового соседа. Когда период отказа маршрутизатора истекает, то маршрутизатор с наивысшим приоритетом и наибольшим идентификатором объявляет себя выделенным (а следующий за ним по приоритету маршрутизатор объявляет себя резервным выделенным маршрутизатором) и начинает синхронизировать свою базу данных с другими маршрутизаторами. С этого момента времени база данных маршрутных объявлений каждого маршрутизатора может содержать информацию, полученную от маршрутизаторов других локальных сетей или из выделенных линий. Роб, например, вероятно получил информацию от Мило и Робина об их сетях, и он может передавать туда пакеты данных. Они содержат информацию о собственных связях маршрутизатора и объявления о связях сети. Базы данных теперь синхронизированы с выделенным маршрутизатором, которым является Джон. Джон суммирует свою базу данных с каждой базой данных своих соседей — базами Фреда, Роба и Джеффа — индивидуально. В каждой cинхронизирующейся паре объявления, найденные только в какой-либо одной базе, копируются в другую. Выделенный маршрутизатор, Джон, распространяет новые объявления среди других маршрутизаторов своей локальной сети. Например, объявления Мило и Робина передаются Джону Робом, а Джон, в свою очередь, передает их Фреду и Джеффри. Обмен информацией между базами продолжается некоторое время, и пока он не завершится, маршрутизаторы не будут считать себя работоспособными. После этого они себя таковыми считают, потому что имеют всю доступную информацию о сети. |
| − | + | Посмотрим теперь как Робин вычисляет маршрут через сеть. Две из связей, присоединенных к его портам, представляют линии T-1, а одна - линию 56 Кб/c. Робин сначала обнаруживает двух соседей — Роба с метрикой 65 и Мило с метрикой 1785. Из объявления о связях Роба Робин обнаружил наилучший путь к Мило со стоимостью 130, поэтому он отверг непосредственный путь к Мило, поскольку он связан с большей задержкой, так как проходит через линии с меньшей пропускной способностью. Робин также обнаруживает транзитную локальную сеть с выделенным маршрутизатором Джоном. Из объявлений о связях Джона Робин узнает о пути к Фреду и, наконец, узнает о пути к маршрутизаторам Келли и Джеффу и к их тупиковым сетям. | |
| − | + | После того, как маршрутизаторы полностью входят в рабочий режим, интенсивность обмена сообщениями резко падает. Обычно они посылают сообщение HELLO по своим подсетям каждые 10 секунд и делают объявления о состоянии связей каждые 30 минут (если обнаруживаются изменения в состоянии связей, то объявление передается, естественно, немедленно). Обновленные объявления о связях служат гарантией того, что маршрутизатор работает в сети. Старые объявления удаляются из базы через определенное время. | |
| − | + | Представим, что какая-либо выделенная линия сети отказала. Присоединенные к ней маршрутизаторы распространяют свои объявления, в которых они уже не упоминают друг друга. Эта информация распространяется по сети, включая маршрутизаторы транзитной локальной сети. Каждый маршрутизатор в сети пересчитывает свои маршруты, находя, может быть, новые пути для восстановления утраченного взаимодействия. | |
| − | + | =====BGP===== | |
| − | + | '''BGP''' (Border Gateway Protocol — протокол граничного шлюза) — основной протокол динамической маршрутизации в Интернете. BGP, в отличие от других протоколов динамической маршрутизации, предназначен для обмена информацией о маршрутах не между отдельными маршрутизаторами, а между целыми автономными системами, и поэтому, помимо информации о маршрутах в сети, переносит также информацию о маршрутах на автономные системы. | |
| − | + | BGP использует маршрутизацию с использованием вектора путей. Маршрутизация с использованием вектора путей отличается и от маршрутизации с использованием вектора длины маршрута, и от маршрутизации состоянием линий. Каждый вход в таблицу маршрутизации содержит сеть пункта назначения, следующий маршрутизатор и путь до пункта назначения. Путь обычно определяется как упорядоченный список автономных систем, которые должен пройти пакет для достижения пункта назначения. Пример таблицы маршрутизации векторов пути приведен ниже. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | BGP использует маршрутизацию с использованием вектора путей. | ||
| − | Маршрутизация с использованием вектора путей отличается и от маршрутизации с использованием вектора длины маршрута, и от маршрутизации состоянием линий. Каждый вход в таблицу маршрутизации содержит сеть пункта назначения, следующий маршрутизатор и путь до пункта назначения. Путь обычно определяется как упорядоченный список автономных систем, которые должен пройти пакет для достижения пункта назначения. | ||
{| {{prettytable}} | {| {{prettytable}} | ||
| − | |+ | + | |+ Маршрутизация векторов путей |
|- style="background: #DDFFDD;" | |- style="background: #DDFFDD;" | ||
! Сеть | ! Сеть | ||
| Строка 300: | Строка 347: | ||
| AS62,AS02, AS09 | | AS62,AS02, AS09 | ||
|} | |} | ||
| − | + | ||
| − | Автономный пограничный маршрутизатор, который участвует в маршрутизации с использованием вектора путей, извещает о достижимости сетей в их собственной автономной системе для соседних автономных пограничных маршрутизаторов. Концепция окружения здесь та же самая, как в уже рассмотренных протоколах RIP и OSPF. Два пограничных маршрутизатора автономных систем, подключенные к той же самой сети, | + | Автономный пограничный маршрутизатор, который участвует в маршрутизации с использованием вектора путей, извещает о достижимости сетей в их собственной автономной системе для соседних автономных пограничных маршрутизаторов. Концепция окружения здесь та же самая, как в уже рассмотренных протоколах RIP и OSPF. Два пограничных маршрутизатора автономных систем, подключенные к той же самой сети, — соседи. |
| + | |||
Каждый маршрутизатор, который получает вектор пути, проверяет, что предложенный путь согласован с его политикой (набором правил, назначаемых администратором, который управляет маршрутизатором). Если политика маршрутизации соответствует записанной в программе, маршрутизатор обновляет таблицы маршрутизации и модифицирует сообщение, прежде чем послать его к следующему соседу. Модификация содержит дополнение номера своего АС для пути и замещающий номер следующего маршрутизатора, входящего со своим собственным идентификатором. | Каждый маршрутизатор, который получает вектор пути, проверяет, что предложенный путь согласован с его политикой (набором правил, назначаемых администратором, который управляет маршрутизатором). Если политика маршрутизации соответствует записанной в программе, маршрутизатор обновляет таблицы маршрутизации и модифицирует сообщение, прежде чем послать его к следующему соседу. Модификация содержит дополнение номера своего АС для пути и замещающий номер следующего маршрутизатора, входящего со своим собственным идентификатором. | ||
| − | === | + | ====Устройство маршрутизатора==== |
| − | + | {{Hider | |
| + | |title=Изображения маршрутизаторов | ||
| + | |content= | ||
| + | <gallery perrow=3 widths="300px" heights="250px"> | ||
| + | Файл:Маршрутизатор 1.JPG|Маленькие — для маленьких фирм и локальных сетей | ||
| + | Файл:Маршрутизатор 2.JPG| | ||
| + | Файл:Маршрутизатор 3.JPG| | ||
| + | Файл:Маршрутизатор 4.JPG|Большой от Cisco — для магистральных провайдеров | ||
| + | </gallery> | ||
| + | }} | ||
| − | + | '''Основная задача маршрутизатора''': получение дейтаграммы и отправка ее по одному из своих интерфейсов. | |
| − | |||
| − | + | '''Задача маршрутного процессора''': составление таблиц продвижения данных. | |
| − | |||
| − | + | Дейтаграммы приходят по одному из входных портов и отправляются на какой-то выходной порт. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | [[Файл:Устройство маршрутизатора.JPG|500px|thumb|left|Устройство маршрутизатора]] | |
| − | + | При наличии таблицы продвиженния данных поиск представляет собой относительно простую задачу — мы просто просматриваем таблицу продвижения данных, ища запись, которая лучше всего соответствует сетевому адресу получателя пакета. Если такую запись в таблице найти не удастся, для передачи пакета выбирается маршрут по умолчанию. На практике, однако, все не так просто. Возможно, наиболее важный усложняющий фактор состоит в том, что магистральные маршрутизаторы должны paботать на высоких скоростях, выполняя миллионы операций поиска в секунду. В самом деле, желательно, чтобы входной порт мог работать на скорости линии, то есть операция поиска должна выполняться быстрее операции приема пакета во входной порт. В этом случае обработка полученного пакета может быть выполнена прежде чем завершится операция получения следующего пакета. | |
| − | + | Чтобы получить представление о необходимой производительности операции поиска, рассмотрим линию, передающую данные на скорости 2,5 Гбит/с. При длине пакетов 256 байт входной порт должен успевать выполнять приблизительно миллион операций поиска в секунду. | |
| − | |||
| − | + | Поскольку скорости передачи данных в современных линиях связи очень высокие, линейный поиск а таблице продвижения данных просто невозможен. Более разумный подход заключается в хранении таблицы продвижения данных в виде дерева, каждый уровень которого соответствует одному двоичному разряду адреса получателя. Поиск адреса начинается с вершины дерева. Если первый бит адреса равен нулю, тогда, дальнейший поиск ведется по левому поддереву, в противном случае адрес получателя должен находиться в правом поддереве. На каждом шаге просматривается один разряд адреса получателя и выбирается одна ветвь дерева из двух. Таким образом, всю таблицу продвижения данных можно просмотреть за N шагов, где N — количество двоичных разрядов в адресе. Такой поиск называется двоичным поиском в адресном пространстве размера 2^N. | |
| − | |||
| − | |||
| − | |||
Но даже при N=32 (например, для 32-разрядного IP-адреса) скорость просмотра таблицы методом двоичного поиска оказывается недостаточно высокой для маршрутизации в современных магистралях. Например, если на каждом шаге работы алгоритма требуется одно обращение к памяти, то при памяти со временем доступа 40нс уровня одного миллиона операций в секунду достичь не удастся. Для увеличения скорости поиска применяются несколько приемов. Один ни таких приемов заключается и использовании ассоциативной памяти. | Но даже при N=32 (например, для 32-разрядного IP-адреса) скорость просмотра таблицы методом двоичного поиска оказывается недостаточно высокой для маршрутизации в современных магистралях. Например, если на каждом шаге работы алгоритма требуется одно обращение к памяти, то при памяти со временем доступа 40нс уровня одного миллиона операций в секунду достичь не удастся. Для увеличения скорости поиска применяются несколько приемов. Один ни таких приемов заключается и использовании ассоциативной памяти. | ||
| − | Стандартные реализации очереди FIFO (первым пришел, первым ушел) первыми отправляют наиболее раннее из полученных сообщений и отбрасывают все последующие, если очередь уже полна. Недавние исследования показывают, что удаление сообщений, по крайней мере для TCP/IP, имеет серьезные побочные эффекты. Например, когда сообщение потеряно, приложение-отправитель может рассматривать это как сигнал о том, что оно посылает пакеты слишком быстро. TCP реагирует на такой сигнал замедлением отправки сообщений. Но когда очередь полна, то часто несколько сообщений отбрасываются друг за другом | + | Стандартные реализации '''очереди FIFO''' (первым пришел, первым ушел) первыми отправляют наиболее раннее из полученных сообщений и отбрасывают все последующие, если очередь уже полна. Недавние исследования показывают, что удаление сообщений, по крайней мере для TCP/IP, имеет серьезные побочные эффекты. Например, когда сообщение потеряно, приложение-отправитель может рассматривать это как сигнал о том, что оно посылает пакеты слишком быстро. TCP реагирует на такой сигнал замедлением отправки сообщений. Но когда очередь полна, то часто несколько сообщений отбрасываются друг за другом, в результате целый ряд приложений решает замедлить передачу. После этого приложения зондируют сеть для определения ее загруженности и буквально через несколько секунд возобновляют передачу с прежним темпом, что опять приводит к перегрузке. |
| − | Случайное раннее обнаружение (Random Early Detection, RED) представляет альтернативу очередям FIFO. Оно позволяет смягчить эффект от потери трафика даже при очень больших нагрузках, так что приложения не синхронизированы друг с другом, как это имело место в предыдущем случае. Такая очередь по-прежнему использует принцип FIFO, но, вместо того чтобы отбрасывать сообщения из конца очереди, RED отбрасывает трафик статистически, когда средняя длина очереди за данный промежуток времени превосходит некоторое значение. Таким образом, заполнение очереди оптимизировано для обеспечения большей устойчивости алгоритма. Этот процесс был придуман специально для TCP, но те, кто его изобрел, считают, что он применим к любому трафику, когда сеть не гарантирует доставки. | + | '''Случайное раннее обнаружение''' (Random Early Detection, RED) представляет альтернативу очередям FIFO. Оно позволяет смягчить эффект от потери трафика даже при очень больших нагрузках, так что приложения не синхронизированы друг с другом, как это имело место в предыдущем случае. Такая очередь по-прежнему использует принцип FIFO, но, вместо того чтобы отбрасывать сообщения из конца очереди, RED отбрасывает трафик статистически, когда средняя длина очереди за данный промежуток времени превосходит некоторое значение. Таким образом, заполнение очереди оптимизировано для обеспечения большей устойчивости алгоритма. Этот процесс был придуман специально для TCP, но те, кто его изобрел, считают, что он применим к любому трафику, когда сеть не гарантирует доставки. |
'''Очередь с приоритетами''' — это алгоритм, при котором несколько очередей FIFO или RED образуют одну систему очередей. Трафик распределяется между данными очередями в соответствии с некоторыми заданными критериями, например в соответствии с приложением или получателем. Однако трафик отправляется в порядке строгой очередности: сначала трафик с высоким приоритетом, затем со средним и т. д. При всей простоте понимания и реализации этот алгоритм не очень хорошо работает при высоких нагрузках, потому что очереди с низким приоритетом оказываются блокированными в течение продолжительного периода времени или низкоприоритетный трафик имеет такую большую задержку в результате следования по окружному пути, что становится бесполезным. | '''Очередь с приоритетами''' — это алгоритм, при котором несколько очередей FIFO или RED образуют одну систему очередей. Трафик распределяется между данными очередями в соответствии с некоторыми заданными критериями, например в соответствии с приложением или получателем. Однако трафик отправляется в порядке строгой очередности: сначала трафик с высоким приоритетом, затем со средним и т. д. При всей простоте понимания и реализации этот алгоритм не очень хорошо работает при высоких нагрузках, потому что очереди с низким приоритетом оказываются блокированными в течение продолжительного периода времени или низкоприоритетный трафик имеет такую большую задержку в результате следования по окружному пути, что становится бесполезным. | ||
| Строка 343: | Строка 388: | ||
'''Взвешенная справедливая очередь''' (Weighted Fair Queuing, WFQ) является частным случаем CBQ, когда отдельному классу соответствуют независимые потоки. Как и в случае CBQ, каждому классу WFQ соответствует одна очередь FIFO и гарантируется некоторая часть пропускной способности канала. Если некоторые потоки используют предоставленную им пропускную способность не полностью, то другие потоки увеличивают свою долю соответственно. Так как каждый класс - это отдельный поток, то гарантия пропускной способности эквивалентна в данном случае гарантии максимальной задержки. Зная параметры сообщения, вы можете по известной формуле вычислить его максимальную задержку при передаче по сети. Выделение дополнительной пропускной способности позволяет уменьшить максимальную задержку. | '''Взвешенная справедливая очередь''' (Weighted Fair Queuing, WFQ) является частным случаем CBQ, когда отдельному классу соответствуют независимые потоки. Как и в случае CBQ, каждому классу WFQ соответствует одна очередь FIFO и гарантируется некоторая часть пропускной способности канала. Если некоторые потоки используют предоставленную им пропускную способность не полностью, то другие потоки увеличивают свою долю соответственно. Так как каждый класс - это отдельный поток, то гарантия пропускной способности эквивалентна в данном случае гарантии максимальной задержки. Зная параметры сообщения, вы можете по известной формуле вычислить его максимальную задержку при передаче по сети. Выделение дополнительной пропускной способности позволяет уменьшить максимальную задержку. | ||
| + | |||
| + | ===Структура Internet=== | ||
| + | [[Файл:Структура Internet.JPG|400px|right]] | ||
| + | Internet изначально строилась как сеть, объединяющая большое количество существующих систем. С самого начала в ее структуре выделяли магистральную сеть (core backbone network), а сети, присоединенные к магистрали, рассматривались как автономные системы (autonomous systems). Магистральная сеть и каждая из автономных систем имели свое собственное административное управление и собственные протоколы маршрутизации. Общая схема архитектуры сети Internet показана на рисунке. Далее маршрутизаторы будут называться шлюзами для следования традиционной терминологии Internet. | ||
| + | |||
| + | Шлюзы, которые используются для образования подсетей внутри автономной системы, называются '''внутренними шлюзами''' (interior gateways), а шлюзы, с помощью которых автономные системы присоединяются к магистрали сети, называются '''внешними шлюзами''' (exterior gateways). Непосредственно друг с другом автономные системы не соединяются. Соответственно, протоколы маршрутизации, используемые внутри автономных систем, называются '''протоколами внутренних шлюзов''' (interior gateway protocol, IGP), а протоколы, определяющие обмен маршрутной информацией между внешними шлюзами и шлюзами магистральной сети — '''протоколами внешних шлюзов''' (exterior gateway protocol, EGP). | ||
| + | |||
| + | Смысл разделения всей сети Internet на автономные системы в ее многоуровневом представлении, что необходимо для любой крупной системы, способной к расширению в больших масштабах. Внутренние шлюзы могут использовать для внутренней маршрутизации достаточно подробные графы связей между собой, чтобы выбрать наиболее рациональный маршрут. Однако, если информация такой степени детализации будет храниться во всех маршрутизаторах сети, то топологические базы данных так разрастутся, что потребуют наличия памяти гигантских размеров, а время принятия решений о маршрутизации непременно возрастет. | ||
| + | |||
| + | При инициализации внешний шлюз узнает уникальный идентификатор обслуживаемой им автономной системы, а также таблицу достижимости (reachability table), которая позволяет ему взаимодействовать с другими внешними шлюзами через магистральную сеть. Затем внешний шлюз начинает взаимодействовать по протоколу EGP с другими внешними шлюзами и обмениваться с ними маршрутной информацией (это информация, относящаяся непосредственно к маршрутизации, которой обмениваются маршрутизаторы), состав которой описан выше. В результате, при отправке пакета из одной автономной системы в другую, внешний шлюз данной системы на основании маршрутной информации, полученной от всех внешних шлюзов, с которыми он общается по протоколу EGP, выбирает наиболее подходящий внешний шлюз и отправляет ему пакет. | ||
| + | |||
| + | В протоколе EGP определены три основные функции: | ||
| + | * установление соседских отношений; | ||
| + | * подтверждение достижимости соседа; | ||
| + | * обновление маршрутной информации. | ||
| + | |||
| + | Каждая функция работает на основе обмена сообщениями запрос-ответ. | ||
| + | |||
| + | Развитием протокола EGP является протокол '''BGP''' (Border Gateway Protocol), имеющий много общего с EGP и используемый наряду с ним в магистрали сети Internet. | ||
===Протокол IPv6=== | ===Протокол IPv6=== | ||
====Причины перехода c IPv4 на IPv6==== | ====Причины перехода c IPv4 на IPv6==== | ||
| − | * | + | * недостаточность объёма 32-битного адресного пространства; |
| − | * | + | * разрастание таблиц маршрутизации; |
| − | * | + | * сложность массового изменения IP-адресов; |
| − | * | + | * относительная сложность обработки заголовков пакетов IPv4. |
====Адреса==== | ====Адреса==== | ||
| − | + | Как правило, адрес стандарта IPv6 состоит из восьми шестнадцатеричных фрагментов по четыре цифры в каждом, разделенных двоеточиями. Полный адрес IPv6 выглядит следующим образом: 2001:0db8:0049:0000:ab00:0000:0000:0102. Он занимает 16 байт и записываются в виде 8 двухбайтных чисел. Первые четыре фрагмента (64 бита) адреса указывают на его сетевую принадлежность и называются сетевым префиксом. Поскольку адреса в формате IPv6 имеют иерархическую структуру, в сетевом префиксе последовательно указываются организация, провайдер и другие элементы цепочки распространения. Последние четыре фрагмента (64 бита) образуют уникальный идентификационный номер интерфейса, который чаще всего формируется на основе MAC-адреса устройства. | |
| − | 2001: | + | |
| + | Поскольку полный адрес, показанный выше, оказывается довольно громоздким и неудобным в обращении, IPv6 предусматривает возможность сжатия адреса, которое осуществляется в два этапа. Сначала убираются все вводные нули в каждом из четырехзначных фрагментов. При этом адрес, показанный выше, примет вид 2001:db8:49:0:ab00:0:0:102. Кроме того, все состоящие из нулей фрагменты можно заменить двойным двоеточием — тогда мы получим окончательно сжатый адрес вида 2001:db8:49:0:ab00::102. Сокращению не могут быть подвергнуты 2 разделенные нулевые группы из-за возникновения неоднозначности. | ||
Сокращения записи: | Сокращения записи: | ||
| Строка 362: | Строка 427: | ||
2001:0db8::1428:57ab | 2001:0db8::1428:57ab | ||
2001:db8::1428:57ab</pre> | 2001:db8::1428:57ab</pre> | ||
| − | |||
| − | |||
| − | |||
| − | |||
=====Типы адресов===== | =====Типы адресов===== | ||
| − | + | {| {{prettytable}} | |
| − | + | |- | |
| − | + | ! unicast | |
| − | + | | Идентификатор одиночного интерфейса. Пакет, посланный по уникастному адресу, доставляется интерфейсу, указанному в адресе. | |
| − | + | |- | |
| − | + | ! anycast | |
| − | + | | Идентификатор набора интерфейсов (принадлежащих разным узлам). Пакет, посланный по эникастному адресу, доставляется одному из интерфейсов, указанному в адресе (ближайший, в соответствии с мерой, определенной протоколом маршрутизации). | |
| − | + | |- | |
| + | ! multicast | ||
| + | | Идентификатор набора интерфейсов (обычно принадлежащих разным узлам). Пакет, посланный по мультикастинг-адресу, доставляется всем интерфейсам, заданным этим адресом. | ||
| + | |} | ||
| − | :: | + | =====Зарезервированные адреса===== |
| + | <pre><nowiki>:: ↔ 0.0.0.0 | ||
::1 ↔ 127.0.0.1 | ::1 ↔ 127.0.0.1 | ||
::a.b.c.d ↔ a.b.c.d | ::a.b.c.d ↔ a.b.c.d | ||
::FFF.a.b.c.d ↔ a.b.c.d | ::FFF.a.b.c.d ↔ a.b.c.d | ||
| − | FF**:: - широковещательные | + | FF**:: - широковещательные</nowiki></pre> |
| − | |||
| − | |||
| − | |||
| − | |||
| − | Определен и второй тип IPv6 адреса, который содержит внутри IPv4 адрес. Этот адрес используется для представления IPv6 адресов узлам IPv4 (тем, что не поддерживают IPv6). Этот тип адреса называется | + | =====IPv6-адреса с вложенными IPv4-адресами===== |
| − | + | Алгоритмы IPv6 включают в себя механизм (для ЭВМ и маршрутизаторов) организации туннелей для IPv6-пакетов через маршрутную инфраструктуру IPv4. Узлам IPv6, которые используют этот метод, присваиваются специальные IPv6 уникастные адреса, которые в младших 32 битах содержат адрес IPv4. Этот тип адреса называется '''IPv4-compatible IPv6 address'''. Определен и второй тип IPv6 адреса, который содержит внутри IPv4 адрес. Этот адрес используется для представления IPv6 адресов узлам IPv4 (тем, что не поддерживают IPv6). Этот тип адреса называется '''IPv4-mapped IPv6 address'''. | |
====Метки потоков==== | ====Метки потоков==== | ||
'''Поток''' — это последовательность пакетов, посылаемых отправителем определённому адресату. | '''Поток''' — это последовательность пакетов, посылаемых отправителем определённому адресату. | ||
| − | '''Метки потоков''' | + | '''Метки потоков''' — случайные 24-битные числа. |
При получении первого пакета с меткой потока маршрутизатор анализирует дополнительные заголовки, выполняет предписанные этими заголовками функции и запоминает результаты обработки (адрес следующего узла, опции заголовка переходов, перемещение адресов в заголовке маршрутизации и т. д.) в локальном кеше. Ключом для такой записи является комбинация адреса источника и метки потока. Последующие пакеты с той же комбинацией адреса источника и метки потока обрабатываются с учётом информации кеша без детального анализа всех полей заголовка. | При получении первого пакета с меткой потока маршрутизатор анализирует дополнительные заголовки, выполняет предписанные этими заголовками функции и запоминает результаты обработки (адрес следующего узла, опции заголовка переходов, перемещение адресов в заголовке маршрутизации и т. д.) в локальном кеше. Ключом для такой записи является комбинация адреса источника и метки потока. Последующие пакеты с той же комбинацией адреса источника и метки потока обрабатываются с учётом информации кеша без детального анализа всех полей заголовка. | ||
| + | |||
Время жизни записи в кеше составляет не более 6 секунд, даже если пакеты этого потока продолжают поступать. При обнулении записи в кеше и получении следующего пакета потока, пакет обрабатывается в обычном режиме и для него происходит новое формирование записи в кеше. Следует отметить, что указанное время жизни потока может быть явно определено узлом отправителем с помощью протокола управления или опций заголовка переходов, и может превышать 6 секунд. | Время жизни записи в кеше составляет не более 6 секунд, даже если пакеты этого потока продолжают поступать. При обнулении записи в кеше и получении следующего пакета потока, пакет обрабатывается в обычном режиме и для него происходит новое формирование записи в кеше. Следует отметить, что указанное время жизни потока может быть явно определено узлом отправителем с помощью протокола управления или опций заголовка переходов, и может превышать 6 секунд. | ||
| − | + | Прио''Курсивное начертание''ритезация пакетов обеспечивается маршрутизаторами на основе поля приоритета. Данное 4-битное поле содержит код требуемого приоритета. Множество значений этого поля разделено на два подмножества: | |
| − | Множество значений этого поля разделено на два подмножества: | ||
* от 0 до 7 — трафик с контролем перегрузки (например, протокол TCP снижает трафик при получении сигнала перегрузки); | * от 0 до 7 — трафик с контролем перегрузки (например, протокол TCP снижает трафик при получении сигнала перегрузки); | ||
* от 8 до 15 — трафик без контроля перегрузки (приложения реального времени с постоянной скоростью). | * от 8 до 15 — трафик без контроля перегрузки (приложения реального времени с постоянной скоростью). | ||
| − | ====Формат заголовка==== | + | ====Формат заголовка пакета==== |
| − | + | [[Файл:Формат заголовка пакета IPv6.JPG|500px|thumb|right|Формат заголовка пакета IPv6]] | |
| − | {| {{prettytable}} | + | {| {{prettytable}} |
| − | | Версия | + | | ''Версия'' |
| 4-битный код номера версии Интернет протокола (версия Интернет протокола для IPv6= 6) | | 4-битный код номера версии Интернет протокола (версия Интернет протокола для IPv6= 6) | ||
|- | |- | ||
| − | | Приоритет | + | | ''Приоритет'' |
| 4-битный код приоритета | | 4-битный код приоритета | ||
|- | |- | ||
| − | | Метка потока | + | | ''Метка потока'' |
| 24-битный код метки потока | | 24-битный код метки потока | ||
|- | |- | ||
| − | | Размер поля данных | + | | ''Размер поля данных'' |
| 16-битовое число без знака. Несет в себе код длины поля данных в октетах, которое следует сразу после заголовка пакета. Если код равен нулю, то длина поля данных записана в поле данных jumbo, которое в свою очередь хранится в зоне опций. | | 16-битовое число без знака. Несет в себе код длины поля данных в октетах, которое следует сразу после заголовка пакета. Если код равен нулю, то длина поля данных записана в поле данных jumbo, которое в свою очередь хранится в зоне опций. | ||
|- | |- | ||
| − | | Следующий заголовок | + | | ''Следующий заголовок'' |
| 8-битовый разделитель. Идентифицирует тип заголовка, который следует непосредственно за IPv6 заголовком. Использует те же значения, что и протокол IPv4 [RFC-1700]. | | 8-битовый разделитель. Идентифицирует тип заголовка, который следует непосредственно за IPv6 заголовком. Использует те же значения, что и протокол IPv4 [RFC-1700]. | ||
|- | |- | ||
| − | | Предельное число шагов | + | | ''Предельное число шагов'' |
| 8-битовое целое число без знака. Уменьшается на 1 в каждом узле, через который проходит пакет. При предельном числе шагов, равном нулю, пакет удаляется. | | 8-битовое целое число без знака. Уменьшается на 1 в каждом узле, через который проходит пакет. При предельном числе шагов, равном нулю, пакет удаляется. | ||
|- | |- | ||
| − | | Адрес отправителя | + | | ''Адрес отправителя'' |
| 128-битовый адрес отправителя пакета. См. RFC-1884. | | 128-битовый адрес отправителя пакета. См. RFC-1884. | ||
|- | |- | ||
| − | | Адрес получателя | + | | ''Адрес получателя'' |
| 128-битовый адрес получателя пакета (возможно не конечный получатель, если присутствует маршрутный заголовок). См. RFC-1884. | | 128-битовый адрес получателя пакета (возможно не конечный получатель, если присутствует маршрутный заголовок). См. RFC-1884. | ||
|} | |} | ||
| − | + | ===Переход с IPv4 на IPv6. Взаимодействие IPv6 и IPv4=== | |
| − | + | Существует несколько приемлемых способов совмещения протоколов IPv4 и IPv6, однако интернет-сообщество еще не решило, какой из них наиболее удобен и позволит обеспечить безболезненный переход к использованию новой технологии. | |
| − | + | ||
| + | Три основных способа обеспечения взаимодействия IPv6 и IPv4: | ||
* туннелирование; | * туннелирование; | ||
* двойной стек; | * двойной стек; | ||
* трансляция протоколов. | * трансляция протоколов. | ||
| − | + | ====Туннелирование==== | |
| + | [[Файл:Туннелирование.jpg|500px|right]] | ||
Суть туннелирования состоит в том, что пакет данных IPv6 внедряется (инкапсулируется) в поле данных пакета IPv4. Получившийся в результате этой операции пакет IPv4 содержит в себе два заголовка, IPv6 и IPv4, и может передаваться через обычные IPv4-сети. Он доставляется к узлу (хосту) декапсуляции, где заголовок IPv4 отбрасывается, а данные передаются к устройству, использующему IPv6. В зависимости от того, где происходит инкапсуляция и декапсуляция, выделяют следующие виды туннелирования: | Суть туннелирования состоит в том, что пакет данных IPv6 внедряется (инкапсулируется) в поле данных пакета IPv4. Получившийся в результате этой операции пакет IPv4 содержит в себе два заголовка, IPv6 и IPv4, и может передаваться через обычные IPv4-сети. Он доставляется к узлу (хосту) декапсуляции, где заголовок IPv4 отбрасывается, а данные передаются к устройству, использующему IPv6. В зависимости от того, где происходит инкапсуляция и декапсуляция, выделяют следующие виды туннелирования: | ||
* "Маршрутизатор – Маршрутизатор"; | * "Маршрутизатор – Маршрутизатор"; | ||
| Строка 444: | Строка 507: | ||
* "Маршрутизатор – Хост". | * "Маршрутизатор – Хост". | ||
Туннель, используемый в процессе передачи данных, должен иметь точку входа и точку выхода. Точка входа находится на границе инфраструктуры IPv4, а потому определить ее достаточно легко. | Туннель, используемый в процессе передачи данных, должен иметь точку входа и точку выхода. Точка входа находится на границе инфраструктуры IPv4, а потому определить ее достаточно легко. | ||
| − | Точка выхода может задаваться инкапсулятору как вручную (в этом случае туннелирование называется конфигурируемым), так и автоматически (так называемое | + | Точка выхода может задаваться инкапсулятору как вручную (в этом случае туннелирование называется '''конфигурируемым'''), так и автоматически (так называемое '''автоматическое туннелирование'''). Во втором подходе декапсулятору присваивается совместимый IPv4/IPv6 адрес, в котором адрес IPv4 встроен в последние 32 бита адреса IPv6. Остаток IPv6-адреса в этом случае заполняется нулями. |
| − | В основе туннелирования лежит следующая идея. Предположим, два IPv4-узла (например, узлы В и Е на | + | В основе туннелирования лежит следующая идея. Предположим, два IPv4-узла (например, узлы В и Е на рисунке) хотят обменяться IPv6-дейтаграммами, но их разделяют IPv4-маршрутизаторы. Промежуточные IPv4-маршрутизаторы мы будем называть '''туннелем'''. Метод туннелирования заключается в том, что передающий IPv4-узел (узел В) помещает IPv6-дейтаграмму целиком в поле данных дейтаграммы формата IPv4. Затем эта IPv4-дейтаграмма, адресованная получающему IPv4-узлу на другой стороне туннеля (узлу Е), передается первому узлу туннеля (узлу С). Промежуточные IPv4-маршрутизаторы передают эту дейтаграмму друг другу, как обычную дейтаграмму, не зная о том, что она содержит полную дейтаграмму формата IPv6. Наконец, принимающий IPv6-узел на другой стороне туннеля получает IPv4-дейтаграмму, определяет, что она содержит дейтаграмму формата IPv6, извлекает IPv6-дейтаграмму и переправляет ее дальше, как если бы он получил ее по сети от непосредственного соседа. |
| − | + | ====Двойной стек==== | |
Реализация технологии двойного стека предполагает поддержку устройством (узлом), имеющим доступ в Интернет, и протокола IPv6, и протокола IPv4. При этом адрес IPv4, приписанный узлу, должен быть уникальным. Поэтому к моменту исчерпания адресного пространства в IPv4 важно, чтобы внедрение новой технологии находилось на таком уровне, который позволял бы большинству устройств взаимодействовать друг с другом, используя только IPv6-адреса. | Реализация технологии двойного стека предполагает поддержку устройством (узлом), имеющим доступ в Интернет, и протокола IPv6, и протокола IPv4. При этом адрес IPv4, приписанный узлу, должен быть уникальным. Поэтому к моменту исчерпания адресного пространства в IPv4 важно, чтобы внедрение новой технологии находилось на таком уровне, который позволял бы большинству устройств взаимодействовать друг с другом, используя только IPv6-адреса. | ||
| − | + | ====Трансляция протоколов==== | |
Трансляция протоколов заключается в преобразовании пакетов одной версии протокола в пакеты другой по определенным правилам. Она может осуществляться несколькими способами. | Трансляция протоколов заключается в преобразовании пакетов одной версии протокола в пакеты другой по определенным правилам. Она может осуществляться несколькими способами. | ||
| − | Первый из них состоит в использовании протокол-шлюзов, которые размещаются на границах между IPv6-сетями и IPv4-сетями. Кроме того, трансляция может осуществляться с помощью транспортного ретранслятора, который обрабатывает в передаваемом пакете данных IP-заголовки и заголовки транспортного уровня. | + | Первый из них состоит в использовании протокол-шлюзов, которые размещаются на границах между IPv6-сетями и IPv4-сетями. Кроме того, трансляция может осуществляться с помощью транспортного ретранслятора, который обрабатывает в передаваемом пакете данных IP-заголовки и заголовки транспортного уровня. Наконец, трансляция протоколов возможна путем их преобразования на прикладном уровне через прокси-сервер. |
| − | Наконец, трансляция протоколов возможна путем их преобразования на прикладном уровне через прокси-сервер | ||
| − | |||
| − | + | ===Взаимодействие IPv6 и DNS=== | |
| − | Еще одна проблема, связанная с внедрением IPv6, | + | Еще одна проблема, связанная с внедрением IPv6, — ее несовместимость с DNS, которая используется сегодня в Интернете. DNS представлена в виде ресурсных записей, каждая из которых принадлежит конкретному доменному имени и содержит ряд сведений о нем, в том числе его IP-адрес. До начала внедрения IPv6 существовало 20 типов таких записей. Они относились к 32-разрядным IP-адресам (так называемые записи "A"), что делало DNS и IPv6 несовместимыми. |
Однако затем был определен новый тип ресурсной записи "AAAA", который служит для хранения 128-битного IPv6-адреса. Сам адрес определен в информационной части этой записи и в виде имени представляется в специально созданном домене ip6.int. Это имя выглядит как набор символов, разделенных точками, и заканчивается суффиксом ip6.int. | Однако затем был определен новый тип ресурсной записи "AAAA", который служит для хранения 128-битного IPv6-адреса. Сам адрес определен в информационной части этой записи и в виде имени представляется в специально созданном домене ip6.int. Это имя выглядит как набор символов, разделенных точками, и заканчивается суффиксом ip6.int. | ||
| − | Клиент, направляющий с устройства запросы на DNS-сервер, должен уметь распознавать записи как об адресах IPv4, так и об адресах IPv6. Получив запрос, DNS-сервер определяет тип ресурсной записи (A или AAAA) и отправляет ее устройству. Распознав запись, устройство выбирает для передачи данных либо протокол IPv4, либо протокол IPv6. При этом, когда IPv4-совместимый адрес назначается какому-либо узлу, в DNS создается две ресурсных записи: AAAA и A. Первая отображает этот адрес в 128-битном формате, а вторая – в 32-битном. Это позволяет устройствам, использующим только протокол IPv6, получать IPv6-адреса, а узлам, работающим только на IPv4 | + | Клиент, направляющий с устройства запросы на DNS-сервер, должен уметь распознавать записи как об адресах IPv4, так и об адресах IPv6. Получив запрос, DNS-сервер определяет тип ресурсной записи (A или AAAA) и отправляет ее устройству. Распознав запись, устройство выбирает для передачи данных либо протокол IPv4, либо протокол IPv6. При этом, когда IPv4-совместимый адрес назначается какому-либо узлу, в DNS создается две ресурсных записи: AAAA и A. Первая отображает этот адрес в 128-битном формате, а вторая – в 32-битном. Это позволяет устройствам, использующим только протокол IPv6, получать IPv6-адреса, а узлам, работающим только на IPv4 — IPv4 адреса. |
Для полной совместимости с IPv6 DNS требует серьезной перестройки. | Для полной совместимости с IPv6 DNS требует серьезной перестройки. | ||
Текущая версия на 00:24, 7 июня 2011
Содержание
- 1 Сетевой уровень
- 1.1 Основные составляющие
- 1.2 IP-адреса
- 1.3 Разделение сетей на классы
- 1.4 Бесклассовая адресация
- 1.5 Иерархия IP-адресов
- 1.6 Зарезервированные адреса
- 1.7 Пример
- 1.8 Формат IP-дейтаграммы
- 1.9 Служебные протоколы
- 1.10 Решение проблемы нехватки IP-адресов (NAT)
- 1.11 Маршрутизация
- 1.12 Структура Internet
- 1.13 Протокол IPv6
- 1.14 Переход с IPv4 на IPv6. Взаимодействие IPv6 и IPv4
- 1.15 Взаимодействие IPv6 и DNS
Сетевой уровень
Транспортный уровень предоставляет услуги связи между двумя процессами. Он опирается на функции сетевого уровня. Сетевой уровень передает данные от одного компьютера в сети к другому через цепочку промежуточных компьютеров. Пропуская через себя пакеты, промежуточные компьютеры не обращают внимания на заголовки прикладного и транспортного уровней. А вот информация, хранящаяся в заголовке сетевого уровня для них имеет большое значение. По этой информации они определяют по какому интерфейсу и кому передать пакет дальше.
Таким образом, получается, что в передаче сообщения принимают участие прикладные программы и драйверы транспортного уровня только конечных компьютеров, а драйверы сетевого уровня — всех компьютеров в цепочке.
Основные составляющие
- Протокол IP. Работает на всех компьютерах в цепочке передачи. На каждом решает кому отправить дальше (таблицы маршрутизации);
- Протоколы маршрутизации. Позволяют динамически менять таблицы маршрутизации;
- Иерархическая система адресации (IP-адреса).
IP-адреса
IP-адрес — это 4-байтовое число (32 разряда), например, 192.168.10.153. Он присваивается каждому интерфейсу. Примерами интерфейса являются сетевая карта, модем.
Считается, что IP-адрес состоит из двух частей:
- сетевая часть (номер подсети);
- интерфейсная часть (номер интерфейса узла).
IP-адреса образуют иерархическую систему адресации, которая позволяет определить местоположение. У оконечной системы может быть несколько IP-адресов (если несколько интерфейсов). Нет строгого разделения, где заканчивается сетевая часть и начинается интерфейсная.
В случае изолированной сети её адрес может быть выбран администратором из специально зарезервированных для таких сетей блоков адресов (192.168.0.0/16, 172.16.0.0/12 или 10.0.0.0/8). Если же сеть должна работать как составная часть Интернета, то адрес сети выдаётся провайдером либо региональным интернет-регистратором (Regional Internet Registry, RIR). Существует пять RIR:
- ARIN, обслуживающий Северную Америку;
- APNIC, обслуживающий страны Юго-Восточной Азии;
- AfriNIC, обслуживающий страны Африки;
- LACNIC, обслуживающий страны Южной Америки и бассейна Карибского моря;
- RIPE NCC, обслуживающий Европу, Центральную Азию, Ближний Восток.
Региональные регистраторы получают номера автономных систем и большие блоки адресов у IANA, а затем выдают номера автономных систем и блоки адресов меньшего размера локальным интернет-регистраторам (Local Internet Registries, LIR), обычно являющимся крупными провайдерами.
Разделение сетей на классы
Нетрудно посчитать, что всего в пространстве адресов IP — 128 сетей по 16 777 216 адресов класса A, 16384 сети по 65536 адресов класса B и 2 097 152 сети по 256 адресов класса C, а также 268 435 456 адресов многоадресной рассылки и 134 317 728 зарезервированных адресов. С ростом сети Интернет эта система оказалась неэффективной и была вытеснена CIDR (бесклассовой адресацией). Такое разделение на классы устарело.
Before classes
Originally, the 32-bit IPv4 address consisted simply of an 8-bit network number field (which specified the particular network a host was attached to), and a rest field, which gave the address of the host within that network. This format was chosen before the advent of local area networks (LANs), when there were only a few, large, networks such as the ARPANET. This resulted in a very low number (254) of possible independent networks, and very early on, as local area networks started to appear, it became obvious that this would not be enough.
Classes
To remain compatible with the existing IP address space and the IP packet structure, the definition of IP addresses was changed in 1981 in RFC 791 to allow unicast addresses with three different sizes of the network number field (and the associated rest field), as specified in the table (см. рис.) The number of usable host addresses available is always 2N - 2 (where N is the number of bits used, and the subtraction of 2 adjusts for the use of the all-bits-zero host portion for network address and the all-bits-one host portion as a broadcast address. Thus, for a Class C address with 8 bits available in the host field, the number of hosts is 254. The expanded network number field allowed a larger number of networks, thereby accommodating the continued growth of the Internet. The IP address netmask, which is commonly associated with an IPv4 address today, was not required because the mask was implicitly derived from the IP address itself. Any network device would inspect the first few bits of the IP address to determine the class of the address. The method of comparing the network numbers of two IP addresses did not change (see subnet). For each address, the network number field size and its subsequent value were determined (the rest field was ignored). The network numbers were then compared. If they matched, then the two addresses were on the same network.
The replacement of classes
The first design changes extended the addressing capability in the Internet, but did not prevent IP address shortage. The principal problem was that too many sites were too big for a Class C network number, and therefore received a Class B block. With the rapid growth of the Internet, the available pool of Class B addresses (214, or about 16,000 total) was rapidly being depleted. Classful networking was replaced by Classless Inter-Domain Routing (CIDR), starting in about 1993, to attempt to solve this problem. Early allocations of IP addresses by IANA were in some cases not made very efficiently, which contributed to the problem. (However, the commonly held notion that some American organizations unfairly or unnecessarily received Class A networks is wrong; most such allocations date to the period before the introduction of address classes, when the only address blocks available were what later became known as Class A networks.)
Бесклассовая адресация
Проблема нехватки IP-адресов решилась предоставлением сети возможности разделения на несколько частей. Например, вместо одного адреса класса В с 14 битами для номера сети и 16 битами для номера хоста было предложено использовать несколько другой формат — формировать адрес подсети из нескольких битов. Например, если в университете существует 35 подразделений, то 6-битным номером можно кодировать подсети, а 10-битным — номера хостов. С помощью такой адресации можно организовать до 64 сетей по 1022 хоста в каждой (адреса 0 и 1 не используются, как уже говорилось, поэтому не 1024 , а именно 1022 хоста).
Иерархия IP-адресов
Зарезервированные адреса
255.255.255.255 – широковещательный.
127.0.0.0 / 8 – петля обратной связи.
10.0.0.0 / 8 и 192.168.0.0 / 16 – частные сети, подсоединенные к Интернету через NAT.
Пример
На рисунке NAT нет. Изображено всего 7 сетей: 3 (между маршрутизаторами) (192.168.2.0, 192.168.3.0 и 192.168.1.0) + 4 (172.17.0.0, 10.0.0.0, 172.16.0.0, 192.168.4.0).
Чтобы понять, как функционируют подсети, следует рассмотреть процесс обработки IP-пакетов маршрутизатором. У каждого маршрутизатора есть таблица,содержащая IP-адреса сетей (вида <сетъ, 0>) и IP-адреса хостов (вида <эта_сеть, хост>). Адреса сетей позволяют получать доступ к удаленным сетям, а адреса хостов — обращаться к локальным хостам. С каждой таблицей связан сетевой интерфейс, применяющийся для получения доступа к пункту назначения, а также другая информация. Когда IP-пакет прибывает на маршрутизатор, адрес получателя, указанный в пакете, ищется в таблице маршрутизации. Если пакет направляется в удаленную сеть, он пересылается следующему маршрутизатору по интерфейсу, указанному в таблице. Если пакет предназначен локальному хосту (например, в локальной сети маршрутизатора), он посылается напрямую адресату. Если номера сети, в которую посылается пакет, в таблице маршрутизатора нет, пакет пересылается маршрутизатору по умолчанию, с более подробными таблицами. Такой алгоритм означает, что каждый маршрутизатор должен учитывать только другие сети и локальные хосты, а не пары <сеть, хост>, что значительно уменьшает размер таблиц маршрутизатора.
Формат IP-дейтаграммы
IP-дейтаграмма состоит из заголовка и текстовой части. Заголовок содержит обязательную 20-байтную часть, а также необязательную часть переменной длины. Формат заголовка показан на рисунке. Поле Версия содержит версию протокола, к которому принадлежит дейтаграмма. Включение версии в каждую дейтаграмму позволяет использовать разные версии протокола на разных машинах. Дело в том, что с годами протокол изменялся, и на одних машинах сейчас работают новые версии, тогда как на других продолжают использоваться старые. Сейчас происходит переход от версии IPv4 к версии IPv6. Он длится уже много лет, и не похоже, что скоро завершится. Длина заголовка является переменной величиной, для хранения которой выделено поле IHL (информация в нем представлена в виде 32-разрядных слов). Минимальное значение длины (при отсутствии необязательного поля) равно 5. Максимальное значение этого 4-битового поля равно 15, что соответствует заголовку длиной 60 байт; таким образом, максимальный размер необязательного поля равен 40 байтам. Для некоторых приложений, например, для записи маршрута, по которому должен быть переслан пакет, 40 байт слишком мало. В данном случае дополнительное поле оказывается бесполезным.
Поле Тип службы — единственное поле, смысл которого с годами несколько изменился. Оно было (впрочем, и до сих пор) предназначено для различения классов обслуживания. Возможны разные комбинации надежности и скорости. Для оцифрованного голоса скорость доставки важнее точности. При передаче файла, наоборот, передача без ошибок важнее быстрой доставки. Изначально 6-разрядное поле Тип службы состояло из трехразрядного поля Precedence и трех флагов — D, Т и R. Поле Precedence указывало приоритет, от 0 (нормальный) до 7 (управляющий сетевой пакет). Три флаговых бита позволяли хосту указать, что беспокоит его сильнее всего, выбрав из набора {Delay, Throughput, Reliability} (Задержка, Пропускная способность, Надежность). Теоретически, эти поля позволяют маршрутизаторам выбрать, например, между спутниковой линией с высокой пропускной способностью и большой задержкой и выделенной линией с низкой пропускной способностью и небольшой задержкой. На практике сегодняшние маршрутизаторы часто вообще игнорируют поле Тип службы. Поле Полная длина содержит длину всей дейтаграммы, включая как заголовок, так и данные. Максимальная длина дейтаграммы 65 535 байт. В настоящий момент этот верхний предел достаточен, однако с появлением гигабитных сетей могут понадобиться дейтаграммы большего размера. (когда Таненбаум это писал, гигабитных сетей еще не было) Поле Идентификатор позволяет хосту-получателю определить, какой дейта- грамме принадлежат полученные им фрагменты. Все фрагменты одной дейтаграммы содержат одно и то же значение идентификатора. Следом идет один неиспользуемый бит и два однобитных поля. Бит DF означает Don't Fragment (He фрагментировать). Это команда маршрутизатору, запрещающая ему фрагментировать дейтаграмму, так как получатель не сможет восстановить ее из фрагментов. Например, при загрузке компьютера его ПЗУ может запросить образ памяти в виде единой дейтаграммы. Пометив дейтаграмму битом DF, отправитель гарантирует, что дейтаграмма дойдет единым блоком, даже если для ее доставки придется избегать сетей с маленьким размером пакетов. От всех машин требуется способность принимать фрагменты размером 576 байт и менее.
Бит MF означает More Fragments (Продолжение следует). Он устанавливается во всех фрагментах, кроме последнего. По этому биту получатель узнает о прибытии последнего фрагмента дейтаграммы. Поле Смещение фрагмента указывает положение фрагмента в исходной дейтаграмме. Длина всех фрагментов в байтах, кроме длины последнего фрагмента, должна быть кратна 8. Так как на это поле выделено 13 бит, максимальное количество фрагментов в дейтаграмме равно 8192, что дает максимальную длину дейтаграммы 65 536 байт, на 1 байт больше, чем может содержаться в поле Полная длина.
Поле Время жизни (Число переходов) представляет собой счетчик, ограничивающий время жизни пакета. Предполагалось, что он будет отсчитывать время в секундах, таким образом, допуская максимальное время жизни пакета в 255 с. На каждом маршрутизаторе это значение должно было уменьшаться как минимум на единицу плюс время стояния в очереди. Однако на практике этот счетчик просто считает количество переходов через маршрутизаторы. Когда значение этого поля становится равным нулю, пакет отвергается, а отправителю отсылается пакет с предупреждением. Таким образом удается избежать вечного странствования пакетов, что может произойти, если таблицы маршрутизаторов по какой-либо причине испортятся.
Собрав дейтаграмму из фрагментов, сетевой уровень должен решить, что с ней делать. Поле Протокол сообщит ему, какому процессу транспортного уровня ее передать. Это может быть TCP, UDP или что-нибудь еще. Нумерация процессов глобально стандартизирована по всему Интернету. Номера протоколов вместе с некоторыми другими были сведены в RFC 1700, однако теперь доступна интернет-версия в виде базы данных, расположенной по адресу www.iana.org. Поле Контрольная сумма заголовка защищает от ошибок только заголовок. Подобная контрольная сумма полезна для обнаружения ошибок, вызванных неисправными микросхемами памяти маршрутизаторов. Алгоритм вычисления суммы просто складывает все 16-разрядные полуслова в дополнительном коде, преобразуя результат также в дополнительный код. Таким образом, проверяемая получателем контрольная сумма заголовка (вместе с этим полем) должна быть равна нулю. Этот алгоритм надежнее, чем обычное суммирование. Обратите внимание на то, что значение Контрольной суммы заголовка должно подсчитываться заново на каждом транзитном участке, так как по крайней мере одно поле постоянно меняется (поле Время жизни). Для ускорения расчетов применяются некоторые хитрости.
Поля Адрес отправителя и Адрес получателя указывают номер сети и номер хоста. Поле Необязательная часть (Параметры) было создано для того, чтобы с появлением новых вариантов протокола не пришлось вносить в заголовок поля, отсутствующие в нынешнем формате. Оно же может служить пространством для различного рода экспериментов, испытания новых идей. Кроме того, оно позволяет не включать в стандартный заголовок редко используемую информацию.
Служебные протоколы
ICMP
ICMP (Internet Control Message Protocol) — межсетевой протокол управляющих сообщений. Основная задача — передача информации об ошибках в дейтаграммах. Используется в программах ping (проверяет работает ли удаленный компьютер) и traceroute (определяет маршрут следования данных в сетях TCP/IP).
Программа traceroute – определение маршрута до заданной оконечной системы. Принципы работы:
- На нужную оконечную систему отправляется серия дейтаграмм с разным временем жизни (1,2,3,…N; max=64). При получении устаревшей дейтаграммы маршрутизатор отвечает специальным ICMP сообщением.
- Программа запрашивает время между отправкой дейтаграммы и получением соответствующего ICMP сообщения. В ответ включается имя маршрутизатора.
- В итоге формируется список маршрутизаторов на основе ICMP – сообщений.
- ICMP сообщения (тип 12) генерируются при нахождении ошибок в заголовке IP пакета (за исключением самих ICMP пакетов, дабы не привести к бесконечно растущему потоку ICMP сообщений об ICMP сообщениях).
- ICMP сообщения (тип 3) генерируются маршрутизатором при отсутствии маршрута к адресату.
- Утилита ping, служащая для проверки возможности доставки IP пакетов использует ICMP сообщения с типом 8 (эхо-запрос) и 0 (эхо-ответ).
- Утилита traceroute, отображающая путь следования IP пакетов, использует ICMP сообщения с типом 11.
- ICMP сообщения с типом 5 используются маршрутизаторами для обновления записей в таблице маршрутизации отправителя.
- ICMP сообщения с типом 4 используются получателем (или промежуточным маршрутизатором) для управления скоростью отправки сообщений отправителем.
DHCP
DHCP (Dynamic Host Configuration Protocol — протокол динамического конфигурирования узлов) позволяет компьютерам автоматически получать IP-адрес и другие параметры.
DHCP — это сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Для этого компьютер обращается к специальному серверу, называемому сервером DHCP. Сетевой администратор может задать диапазон адресов, распределяемых среди компьютеров. Это позволяет избежать ручной настройки компьютеров сети и уменьшает количество ошибок. Протокол DHCP используется в большинстве крупных (и не очень) сетей TCP/IP.
Протокол DHCP предоставляет три способа распределения IP-адресов:
- Ручное распределение. При этом способе сетевой администратор сопоставляет аппаратному адресу (обычно MAC-адресу) каждого клиентского компьютера определённый IP-адрес. Фактически, данный способ распределения адресов отличается от ручной настройки каждого компьютера лишь тем, что сведения об адресах хранятся централизованно (на сервере DHCP), и потому их проще изменять при необходимости.
- Автоматическое распределение. При данном способе каждому компьютеру на постоянное использование выделяется произвольный свободный IP-адрес из определённого администратором диапазона.
- Динамическое распределение. Этот способ аналогичен автоматическому распределению, за исключением того, что адрес выдаётся компьютеру не на постоянное пользование, а на определённый срок. Это называется арендой адреса. По истечении срока аренды IP-адрес вновь считается свободным, и клиент обязан запросить новый (он, впрочем, может оказаться тем же самым).
Некоторые реализации службы DHCP способны автоматически обновлять записи DNS, соответствующие клиентским компьютерам, при выделении им новых адресов.
Принципы работы DHCP
- Компьютер отправляет широковещательный UDP-пакет: «Кто может назначить мне IP-адрес?»
- DHCP-серверы сети отправляют в ответ DHCP-предложения.
- Клиент получает список предложений, выбирает нужное и отправляет DHCP-запрос на конкретный сервер.
- От сервера приходит DHCP-подтверждение (в нем указывается IP-адрес, присвоенный клиенту).
Решение проблемы нехватки IP-адресов (NAT)
NAT (Network Address Translation — «преобразование сетевых адресов») — это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов.
Транзитными пакеты могут быть для коммуникационного оборудования (если вы настроили ваш ПК как роутер/гейт, то он также может считаться коммуникационным оборудованием). Задача коммуникаторов — доставлять по адресу приходящие пакеты. Пакеты, которые не предназначены самому коммуникатору, а должны быть перенаправлены и доставлены другому адресату можно уже назвать транзитными. Хотя есть еще один контекст этого понятия. Обычно коммуникаторы ставят на границе локальной и внешней сети. Если пакет пришел в один из портов коммуникатора из внешней сети, и должен быть перенаправлен в другой порт внешней сети, то его называют транзитным.
Преобразование адресов методом NAT может производиться почти любым маршрутизирующим устройством — маршрутизатором, сервером доступа, межсетевым экраном. Суть механизма состоит в замене адреса источника (source) при прохождении пакета в одну сторону и обратной замене адреса назначения (destination) в ответном пакете. Наряду с адресами source/destination могут также заменяться номера портов source/destination.
NAT выполняет две важных функции:
- Позволяет сэкономить IP-адреса, транслируя несколько внутренних IP-адресов в один внешний публичный IP-адрес (или в несколько, но меньшим количеством, чем внутренних).
- Позволяет предотвратить или ограничить обращение снаружи ко внутренним хостам, оставляя возможность обращения изнутри наружу.
При инициации соединения изнутри сети создаётся трансляция. Ответные пакеты, поступающие снаружи, соответствуют созданной трансляции и поэтому пропускаются. Если для пакетов, поступающих снаружи, соответствующей трансляции не существует (а она может быть созданной при инициации соединения или статической), они не пропускаются.
Недостатки
- Не все протоколы могут «преодолеть» NAT. Некоторые не в состоянии работать, если на пути между взаимодействующими хостами есть трансляция адресов. Некоторые межсетевые экраны, осуществляющие трансляцию IP-адресов, могут исправить этот недостаток, соответствующим образом заменяя IP-адреса не только в заголовках IP, но и на более высоких уровнях (например, в командах протокола FTP). Из-за трансляции адресов «много в один» появляются дополнительные сложности с идентификацией пользователей и необходимость хранить полные логи трансляций.
- DoS со стороны узла, осуществляющего NAT — если NAT используется для подключения многих пользователей к одному и тому же сервису, это может вызвать иллюзию DoS атаки на сервис (множество успешных и неуспешных попыток). Например, избыточное количество пользователей ICQ за NAT’ом приводит к проблеме подключения некоторых пользователей из-за превышения допустимой скорости коннектов к серверу. Частичным решением проблемы является использование пула адресов (группы адресов), для которых осуществляется трансляция.
- Сложности в работе с пиринговыми сетями, в которых необходимо не только инициировать исходящие соединения, но также принимать входящие.
Маршрутизация
Маршрутизатор (устройство) получает пакет и должен отправить его дальше, но кому?
Маршрутизация (англ. routing) — это процесс определения маршрута следования информации в сетях связи.
Зачастую в его таблицах маршрутизации есть несколько записей для заданной в пакете сети назначения. Тогда маршрутизатор смотрит на значение метрики. Он выбирает маршрут с наименьшей метрикой. Метрика назначается для каждого сетевого интерфейса.
В зависимости от того как вносятся изменения в таблицы маршрутов, маршрутизация называется статической или динамической. Существуют специальные протоколы, которые описывают правила согласования таблиц маршрутизации множества маршрутизаторов в какой-нибудь сети. Они называются протоколами маршрутизации.
Протоколы обмена маршрутной информацией (протоколы маршрутизации) реализуют следующие типов алгоритмов:
- дистанционно-векторный алгоритм (Distance Vector Algorithms, DVA);
- алгоритм состояния связей (Link State Algorithms, LSA);
- другие (например, гибридный протокол маршрутизации EIGRP от Cisco).
Алгоритмы дистанционно-векторного типа
В алгоритмах дистанционно-векторного типа каждый маршрутизатор периодически и широковещательно рассылает по сети вектор расстояний от себя до всех известных ему сетей. Под расстоянием обычно понимается число промежуточных маршрутизаторов через которые пакет должен пройти прежде, чем попадет в соответствующую сеть. Может использоваться и другая метрика, учитывающая не только число перевалочных пунктов, но и время прохождения пакетов по связи между соседними маршрутизаторами. Получив вектор от соседнего маршрутизатора, каждый маршрутизатор добавляет к нему информацию об известных ему других сетях, о которых он узнал непосредственно (если они подключены к его портам) или из аналогичных объявлений других маршрутизаторов, а затем снова рассылает новое значение вектора по сети. В конце-концов, каждый маршрутизатор узнает информацию об имеющихся в интерсети сетях и о расстоянии до них через соседние маршрутизаторы.
Дистанционно-векторные алгоритмы хорошо работают только в небольших сетях. В больших сетях они засоряют линии связи интенсивным широковещательным трафиком, к тому же изменения конфигурации могут отрабатываться по этому алгоритму не всегда корректно, так как маршрутизаторы не имеют точного представления о топологии связей в сети, а располагают только обобщенной информацией — вектором дистанций, к тому же полученной через посредников. Работа маршрутизатора в соответствии с дистанционно-векторным протоколом напоминает работу моста, так как точной топологической картины сети такой маршрутизатор не имеет.
Наиболее распространенным протоколом, основанным на дистанционно-векторном алгоритме, является протокол RIP.
Алгоритмы состояния связей
Алгоритмы состояния связей обеспечивают каждый маршрутизатор информацией, достаточной для построения точного графа связей сети. Все маршрутизаторы работают на основании одинаковых графов, что делает процесс маршрутизации более устойчивым к изменениям конфигурации. Широковещательная рассылка используется здесь только при изменениях состояния связей, что происходит в надежных сетях не так часто.
Для того, чтобы понять, в каком состоянии находятся линии связи, подключенные к его портам, маршрутизатор периодически обменивается короткими пакетами со своими ближайшими соседями. Этот трафик также широковещательный, но он циркулирует только между соседями и поэтому не так засоряет сеть. Протоколом, основанным на алгоритме состояния связей, в стеке TCP/IP является протокол OSPF.
Иерархическая маршрутизация
Вся сеть разбивается на вложенные подсети. Внутри каждой автономной подсети используются протоколы внутренней маршрутизации. Автономные системы соединяются друг с другом с помощью шлюзов (gateway). Маршрутизация между этими шлюзами — внешняя маршрутизация. Все вместе это может быть также автономной подсетью.
Протоколы:
- внутренняя маршрутизация: RIP (Routing Internet Protocol) и OPSF (Open Shortest Path First);
- внешняя маршрутизация: BGP (Border Gateway Protocol).
При использовании иерархической маршрутизации маршрутизаторы разбиваются на отдельные, так называемые, регионы. Каждый маршрутизатор знает все детали выбора маршрутов в пределах своей области, но ему ничего не известно о внутреннем строении других регионов. При объединении нескольких сетей естественно рассматривать их как отдельные регионы, при этом маршрутизаторы одной сети освобождаются от необходимости знать топологию других сетей. В очень больших сетях двухуровневой иерархии может оказаться недостаточно. Может потребоваться группировать регионы в кластеры, кластеры в зоны, зоны в группы, и т. д., пока у нас не иссякнет фантазия на названия для новых образований.
RIP
Протокол RIP (Routing Information Protocol) — это один из наиболее распространенных протоколов маршрутизации в небольших компьютерных сетях, который позволяет маршрутизаторам динамически обновлять маршрутную информацию (направление и дальность в хопах), получая ее от соседних маршрутизаторов.
Протокол RIP представляет собой один из старейших протоколов обмена маршрутной информацией, он до сих пор чрезвычайно распространен в вычислительных сетях.
Алгоритм маршрутизации RIP (алгоритм Беллмана-Форда) был впервые разработан в 1969 г., как основной для сети ARPANET. Алгоритм Беллмана-Форда — это алгоритм поиска кратчайшего пути во взвешенном графе.
В этом протоколе все сети имеют номера (способ образования номера зависит от используемого в сети протокола сетевого уровня), а все маршрутизаторы — идентификаторы. Протокол RIP широко использует понятие «вектор расстояний». Вектор расстояний представляет собой набор пар чисел, являющихся номерами сетей и расстояниями до них в хопах.
Вектора расстояний итерационно распространяются маршрутизаторами по сети, и через несколько шагов каждый маршрутизатор имеет данные о достижимых для него сетях и о расстояниях до них. Если связь с какой-либо сетью обрывается, то маршрутизатор отмечает этот факт тем, что присваивает элементу вектора, соответствующему расстоянию до этой сети, максимально возможное значение, которое имеет специальный смысл — "связи нет". Таким значением в протоколе RIP является число 16.
|
|
|
На рисунке цифрами обозначены маршрутизаторы. Каждый маршрутизатор хранит у себя вектор дистанций. Вектор дистанций — это таблица, где указаны IP-адреса сетей (первый столбец), расстояние до этих сетей в хопах (хоп — это количество ребер на графе) (второй столбец) и какому следующему маршрутизатору нужно отправить, чтобы пакет дошел до нужной сети. Буквами A, B, C, D, E, F обозначены сети между каждыми двумя маршрутизаторами.
В таблице 1 приведена начальная информация, содержащаяся в топологической базе маршрутизатора 2, а в таблице 2 — информация в этой же базе после двух итераций обмена маршрутными пакетами протокола RIP. После определенного числа итераций маршрутизатор 2 будет знать о расстояниях до всех сетей интерсети, причем у него может быть несколько альтернативных вариантов отправки пакета к сети назначения.
Пусть в нашем примере сетью назначения является сеть D. При необходимости отправить пакет в сеть D маршрутизатор просматривает свою базу данных маршрутов и выбирает порт, имеющий наименьшее расстояния до сети назначения (в данном случае порт, связывающий его с маршрутизатором 3).
Для адаптации к изменению состояния связей и оборудования с каждой записью таблицы маршрутизации связан таймер. Если за время тайм-аута не придет новое сообщение, подтверждающее этот маршрут, то он удаляется из маршрутной таблицы.
При использовании протокола RIP работает эвристический алгоритм динамического программирования Беллмана-Форда, и решение, найденное с его помощью является не оптимальным, а близким к оптимальному. Преимуществом протокола RIP является его вычислительная простота, а недостатками — увеличение трафика при периодической рассылке широковещательных пакетов и неоптимальность найденного маршрута.
Неустойчивая работа при изменении конфигурации
На рисунке показан случай неустойчивой работы сети по протоколу RIP при изменении конфигурации - отказе линии связи маршрутизатора M1 с сетью 1. При работоспособном состоянии этой связи в таблице маршрутов каждого маршрутизатора есть запись о сети с номером 1 и соответствующим расстоянием до нее.
При обрыве связи с сетью 1 маршрутизатор М1 отмечает, что расстояние до этой сети приняло значение 16. Однако получив через некоторое время от маршрутизатора М2 маршрутное сообщение о том, что от него до сети 1 расстояние составляет 2 хопа, маршрутизатор М1 наращивает это расстояние на 1 и отмечает, что сеть 1 достижима через маршрутизатор 2. В результате пакет, предназначенный для сети 1, будет циркулировать между маршрутизаторами М1 и М2 до тех пор, пока не истечет время хранения записи о сети 1 в маршрутизаторе 2, и он не передаст эту информацию маршрутизатору М1.
Для исключения подобных ситуаций маршрутная информация об известной маршрутизатору сети не передается тому маршрутизатору, от которого она пришла.
OSPF
Протокол OSPF (Open Shortest Path Firs) является достаточно современной реализацией алгоритма состояния связей (он принят в 1991 году) и обладает многими особенностями, ориентированными на применение в больших гетерогенных сетях.
Протокол OSPF вычисляет маршруты в IP-сетях, сохраняя при этом другие протоколы обмена маршрутной информацией.
Непосредственно связанные (то есть достижимые без использования промежуточных маршрутизаторов) маршрутизаторы называются соседями. Каждый маршрутизатор хранит информацию о том, в каком состоянии по его мнению находится сосед. Маршрутизатор полагается на соседние маршрутизаторы и передает им пакеты данных только в том случае, если он уверен, что они полностью работоспособны. Для выяснения состояния связей маршрутизаторы-соседи достаточно часто обмениваются короткими сообщениями HELLO.
Для распространения по сети данных о состоянии связей маршрутизаторы обмениваются сообщениями другого типа. Эти сообщения называются router links advertisement — объявление о связях маршрутизатора (точнее, о состоянии связей). OSPF-маршрутизаторы обмениваются не только своими, но и чужими объявлениями о связях, получая в конце-концов информацию о состоянии всех связей сети. Эта информация и образует граф связей сети, который, естественно, один и тот же для всех маршрутизаторов сети.
Кроме информации о соседях, маршрутизатор в своем объявлении перечисляет IP-подсети, с которыми он связан непосредственно, поэтому после получения информации о графе связей сети, вычисление маршрута до каждой сети производится непосредственно по этому графу по алгоритму Дэйкстры. Более точно, маршрутизатор вычисляет путь не до конкретной сети, а до маршрутизатора, к которому эта сеть подключена. Каждый маршрутизатор имеет уникальный идентификатор, который передается в объявлении о состояниях связей. Такой подход дает возможность не тратить IP-адреса на связи типа "точка-точка" между маршрутизаторами, к которым не подключены рабочие станции.
Маршрутизатор вычисляет оптимальный маршрут до каждой адресуемой сети, но запоминает только первый промежуточный маршрутизатор из каждого маршрута. Таким образом, результатом вычислений оптимальных маршрутов является список строк, в которых указывается номер сети и идентификатор маршрутизатора, которому нужно переслать пакет для этой сети. Указанный список маршрутов и является маршрутной таблицей, но вычислен он на основании полной информации о графе связей сети, а не частичной информации, как в протоколе RIP.
Представим себе один день из жизни транзитной локальной сети. Пусть у нас имеется сеть Ethernet, в которой есть три маршрутизатора — Джон, Фред и Роб (имена членов рабочей группы Internet, разработавшей протокол OSPF). Эти маршрутизаторы связаны с сетями в других городах с помощью выделенных линий.
Пусть произошло восстановление сетевого питания после сбоя. Маршрутизаторы и компьютеры перезагружаются и начинают работать по сети Ethernet. После того, как маршрутизаторы обнаруживают, что порты Ethernet работают нормально, они начинают генерировать сообщения HELLO, которые говорят о их присутствии в сети и их конфигурации. Однако маршрутизация пакетов начинает осуществляться не сразу — сначала маршрутизаторы должны синхронизировать свои маршрутные базы.
На протяжении интервала отказа маршрутизаторы продолжают посылать сообщения HELLO. Когда какой-либо маршрутизатор посылает такое сообщение, другие его получают и отмечают, что в локальной сети есть другой маршрутизатор. Когда они посылают следующее HELLO, они перечисляют там и своего нового соседа. Когда период отказа маршрутизатора истекает, то маршрутизатор с наивысшим приоритетом и наибольшим идентификатором объявляет себя выделенным (а следующий за ним по приоритету маршрутизатор объявляет себя резервным выделенным маршрутизатором) и начинает синхронизировать свою базу данных с другими маршрутизаторами. С этого момента времени база данных маршрутных объявлений каждого маршрутизатора может содержать информацию, полученную от маршрутизаторов других локальных сетей или из выделенных линий. Роб, например, вероятно получил информацию от Мило и Робина об их сетях, и он может передавать туда пакеты данных. Они содержат информацию о собственных связях маршрутизатора и объявления о связях сети. Базы данных теперь синхронизированы с выделенным маршрутизатором, которым является Джон. Джон суммирует свою базу данных с каждой базой данных своих соседей — базами Фреда, Роба и Джеффа — индивидуально. В каждой cинхронизирующейся паре объявления, найденные только в какой-либо одной базе, копируются в другую. Выделенный маршрутизатор, Джон, распространяет новые объявления среди других маршрутизаторов своей локальной сети. Например, объявления Мило и Робина передаются Джону Робом, а Джон, в свою очередь, передает их Фреду и Джеффри. Обмен информацией между базами продолжается некоторое время, и пока он не завершится, маршрутизаторы не будут считать себя работоспособными. После этого они себя таковыми считают, потому что имеют всю доступную информацию о сети.
Посмотрим теперь как Робин вычисляет маршрут через сеть. Две из связей, присоединенных к его портам, представляют линии T-1, а одна - линию 56 Кб/c. Робин сначала обнаруживает двух соседей — Роба с метрикой 65 и Мило с метрикой 1785. Из объявления о связях Роба Робин обнаружил наилучший путь к Мило со стоимостью 130, поэтому он отверг непосредственный путь к Мило, поскольку он связан с большей задержкой, так как проходит через линии с меньшей пропускной способностью. Робин также обнаруживает транзитную локальную сеть с выделенным маршрутизатором Джоном. Из объявлений о связях Джона Робин узнает о пути к Фреду и, наконец, узнает о пути к маршрутизаторам Келли и Джеффу и к их тупиковым сетям.
После того, как маршрутизаторы полностью входят в рабочий режим, интенсивность обмена сообщениями резко падает. Обычно они посылают сообщение HELLO по своим подсетям каждые 10 секунд и делают объявления о состоянии связей каждые 30 минут (если обнаруживаются изменения в состоянии связей, то объявление передается, естественно, немедленно). Обновленные объявления о связях служат гарантией того, что маршрутизатор работает в сети. Старые объявления удаляются из базы через определенное время.
Представим, что какая-либо выделенная линия сети отказала. Присоединенные к ней маршрутизаторы распространяют свои объявления, в которых они уже не упоминают друг друга. Эта информация распространяется по сети, включая маршрутизаторы транзитной локальной сети. Каждый маршрутизатор в сети пересчитывает свои маршруты, находя, может быть, новые пути для восстановления утраченного взаимодействия.
BGP
BGP (Border Gateway Protocol — протокол граничного шлюза) — основной протокол динамической маршрутизации в Интернете. BGP, в отличие от других протоколов динамической маршрутизации, предназначен для обмена информацией о маршрутах не между отдельными маршрутизаторами, а между целыми автономными системами, и поэтому, помимо информации о маршрутах в сети, переносит также информацию о маршрутах на автономные системы.
BGP использует маршрутизацию с использованием вектора путей. Маршрутизация с использованием вектора путей отличается и от маршрутизации с использованием вектора длины маршрута, и от маршрутизации состоянием линий. Каждый вход в таблицу маршрутизации содержит сеть пункта назначения, следующий маршрутизатор и путь до пункта назначения. Путь обычно определяется как упорядоченный список автономных систем, которые должен пройти пакет для достижения пункта назначения. Пример таблицы маршрутизации векторов пути приведен ниже.
| Сеть | Следующий маршрутизатор | Путь |
|---|---|---|
| N01 | R01 | AS14,AS23, AS67 |
| N02 | R05 | AS22,AS67, AS05, AS89 |
| N03 | R06 | AS67,AS89, AS09, AS34 |
| N04 | R12 | AS62,AS02, AS09 |
Автономный пограничный маршрутизатор, который участвует в маршрутизации с использованием вектора путей, извещает о достижимости сетей в их собственной автономной системе для соседних автономных пограничных маршрутизаторов. Концепция окружения здесь та же самая, как в уже рассмотренных протоколах RIP и OSPF. Два пограничных маршрутизатора автономных систем, подключенные к той же самой сети, — соседи.
Каждый маршрутизатор, который получает вектор пути, проверяет, что предложенный путь согласован с его политикой (набором правил, назначаемых администратором, который управляет маршрутизатором). Если политика маршрутизации соответствует записанной в программе, маршрутизатор обновляет таблицы маршрутизации и модифицирует сообщение, прежде чем послать его к следующему соседу. Модификация содержит дополнение номера своего АС для пути и замещающий номер следующего маршрутизатора, входящего со своим собственным идентификатором.
Устройство маршрутизатора
Маленькие — для маленьких фирм и локальных сетей
Большой от Cisco — для магистральных провайдеров
Основная задача маршрутизатора: получение дейтаграммы и отправка ее по одному из своих интерфейсов.
Задача маршрутного процессора: составление таблиц продвижения данных.
Дейтаграммы приходят по одному из входных портов и отправляются на какой-то выходной порт.
При наличии таблицы продвиженния данных поиск представляет собой относительно простую задачу — мы просто просматриваем таблицу продвижения данных, ища запись, которая лучше всего соответствует сетевому адресу получателя пакета. Если такую запись в таблице найти не удастся, для передачи пакета выбирается маршрут по умолчанию. На практике, однако, все не так просто. Возможно, наиболее важный усложняющий фактор состоит в том, что магистральные маршрутизаторы должны paботать на высоких скоростях, выполняя миллионы операций поиска в секунду. В самом деле, желательно, чтобы входной порт мог работать на скорости линии, то есть операция поиска должна выполняться быстрее операции приема пакета во входной порт. В этом случае обработка полученного пакета может быть выполнена прежде чем завершится операция получения следующего пакета.
Чтобы получить представление о необходимой производительности операции поиска, рассмотрим линию, передающую данные на скорости 2,5 Гбит/с. При длине пакетов 256 байт входной порт должен успевать выполнять приблизительно миллион операций поиска в секунду.
Поскольку скорости передачи данных в современных линиях связи очень высокие, линейный поиск а таблице продвижения данных просто невозможен. Более разумный подход заключается в хранении таблицы продвижения данных в виде дерева, каждый уровень которого соответствует одному двоичному разряду адреса получателя. Поиск адреса начинается с вершины дерева. Если первый бит адреса равен нулю, тогда, дальнейший поиск ведется по левому поддереву, в противном случае адрес получателя должен находиться в правом поддереве. На каждом шаге просматривается один разряд адреса получателя и выбирается одна ветвь дерева из двух. Таким образом, всю таблицу продвижения данных можно просмотреть за N шагов, где N — количество двоичных разрядов в адресе. Такой поиск называется двоичным поиском в адресном пространстве размера 2^N.
Но даже при N=32 (например, для 32-разрядного IP-адреса) скорость просмотра таблицы методом двоичного поиска оказывается недостаточно высокой для маршрутизации в современных магистралях. Например, если на каждом шаге работы алгоритма требуется одно обращение к памяти, то при памяти со временем доступа 40нс уровня одного миллиона операций в секунду достичь не удастся. Для увеличения скорости поиска применяются несколько приемов. Один ни таких приемов заключается и использовании ассоциативной памяти.
Стандартные реализации очереди FIFO (первым пришел, первым ушел) первыми отправляют наиболее раннее из полученных сообщений и отбрасывают все последующие, если очередь уже полна. Недавние исследования показывают, что удаление сообщений, по крайней мере для TCP/IP, имеет серьезные побочные эффекты. Например, когда сообщение потеряно, приложение-отправитель может рассматривать это как сигнал о том, что оно посылает пакеты слишком быстро. TCP реагирует на такой сигнал замедлением отправки сообщений. Но когда очередь полна, то часто несколько сообщений отбрасываются друг за другом, в результате целый ряд приложений решает замедлить передачу. После этого приложения зондируют сеть для определения ее загруженности и буквально через несколько секунд возобновляют передачу с прежним темпом, что опять приводит к перегрузке.
Случайное раннее обнаружение (Random Early Detection, RED) представляет альтернативу очередям FIFO. Оно позволяет смягчить эффект от потери трафика даже при очень больших нагрузках, так что приложения не синхронизированы друг с другом, как это имело место в предыдущем случае. Такая очередь по-прежнему использует принцип FIFO, но, вместо того чтобы отбрасывать сообщения из конца очереди, RED отбрасывает трафик статистически, когда средняя длина очереди за данный промежуток времени превосходит некоторое значение. Таким образом, заполнение очереди оптимизировано для обеспечения большей устойчивости алгоритма. Этот процесс был придуман специально для TCP, но те, кто его изобрел, считают, что он применим к любому трафику, когда сеть не гарантирует доставки.
Очередь с приоритетами — это алгоритм, при котором несколько очередей FIFO или RED образуют одну систему очередей. Трафик распределяется между данными очередями в соответствии с некоторыми заданными критериями, например в соответствии с приложением или получателем. Однако трафик отправляется в порядке строгой очередности: сначала трафик с высоким приоритетом, затем со средним и т. д. При всей простоте понимания и реализации этот алгоритм не очень хорошо работает при высоких нагрузках, потому что очереди с низким приоритетом оказываются блокированными в течение продолжительного периода времени или низкоприоритетный трафик имеет такую большую задержку в результате следования по окружному пути, что становится бесполезным.
Очереди в соответствии с классом (Class-Based Queuing, CBQ) — это алгоритм, при котором трафик делится на несколько классов. Определение класса трафика в значительной мере произвольно. Класс может представлять весь трафик через данный интерфейс, трафик определенных приложений, трафик к заданному подмножеству получателей, трафик с качеством услуг, гарантированным RSVP. Каждый класс имеет собственную очередь, и ему гарантируется, по крайней мере, некоторая доля пропускной способности канала. Если какой-либо класс не исчерпывает предоставленный ему лимит пропускной способности, то остальные классы увеличивают свою долю пропорциональным образом.
Взвешенная справедливая очередь (Weighted Fair Queuing, WFQ) является частным случаем CBQ, когда отдельному классу соответствуют независимые потоки. Как и в случае CBQ, каждому классу WFQ соответствует одна очередь FIFO и гарантируется некоторая часть пропускной способности канала. Если некоторые потоки используют предоставленную им пропускную способность не полностью, то другие потоки увеличивают свою долю соответственно. Так как каждый класс - это отдельный поток, то гарантия пропускной способности эквивалентна в данном случае гарантии максимальной задержки. Зная параметры сообщения, вы можете по известной формуле вычислить его максимальную задержку при передаче по сети. Выделение дополнительной пропускной способности позволяет уменьшить максимальную задержку.
Структура Internet
Internet изначально строилась как сеть, объединяющая большое количество существующих систем. С самого начала в ее структуре выделяли магистральную сеть (core backbone network), а сети, присоединенные к магистрали, рассматривались как автономные системы (autonomous systems). Магистральная сеть и каждая из автономных систем имели свое собственное административное управление и собственные протоколы маршрутизации. Общая схема архитектуры сети Internet показана на рисунке. Далее маршрутизаторы будут называться шлюзами для следования традиционной терминологии Internet.
Шлюзы, которые используются для образования подсетей внутри автономной системы, называются внутренними шлюзами (interior gateways), а шлюзы, с помощью которых автономные системы присоединяются к магистрали сети, называются внешними шлюзами (exterior gateways). Непосредственно друг с другом автономные системы не соединяются. Соответственно, протоколы маршрутизации, используемые внутри автономных систем, называются протоколами внутренних шлюзов (interior gateway protocol, IGP), а протоколы, определяющие обмен маршрутной информацией между внешними шлюзами и шлюзами магистральной сети — протоколами внешних шлюзов (exterior gateway protocol, EGP).
Смысл разделения всей сети Internet на автономные системы в ее многоуровневом представлении, что необходимо для любой крупной системы, способной к расширению в больших масштабах. Внутренние шлюзы могут использовать для внутренней маршрутизации достаточно подробные графы связей между собой, чтобы выбрать наиболее рациональный маршрут. Однако, если информация такой степени детализации будет храниться во всех маршрутизаторах сети, то топологические базы данных так разрастутся, что потребуют наличия памяти гигантских размеров, а время принятия решений о маршрутизации непременно возрастет.
При инициализации внешний шлюз узнает уникальный идентификатор обслуживаемой им автономной системы, а также таблицу достижимости (reachability table), которая позволяет ему взаимодействовать с другими внешними шлюзами через магистральную сеть. Затем внешний шлюз начинает взаимодействовать по протоколу EGP с другими внешними шлюзами и обмениваться с ними маршрутной информацией (это информация, относящаяся непосредственно к маршрутизации, которой обмениваются маршрутизаторы), состав которой описан выше. В результате, при отправке пакета из одной автономной системы в другую, внешний шлюз данной системы на основании маршрутной информации, полученной от всех внешних шлюзов, с которыми он общается по протоколу EGP, выбирает наиболее подходящий внешний шлюз и отправляет ему пакет.
В протоколе EGP определены три основные функции:
- установление соседских отношений;
- подтверждение достижимости соседа;
- обновление маршрутной информации.
Каждая функция работает на основе обмена сообщениями запрос-ответ.
Развитием протокола EGP является протокол BGP (Border Gateway Protocol), имеющий много общего с EGP и используемый наряду с ним в магистрали сети Internet.
Протокол IPv6
Причины перехода c IPv4 на IPv6
- недостаточность объёма 32-битного адресного пространства;
- разрастание таблиц маршрутизации;
- сложность массового изменения IP-адресов;
- относительная сложность обработки заголовков пакетов IPv4.
Адреса
Как правило, адрес стандарта IPv6 состоит из восьми шестнадцатеричных фрагментов по четыре цифры в каждом, разделенных двоеточиями. Полный адрес IPv6 выглядит следующим образом: 2001:0db8:0049:0000:ab00:0000:0000:0102. Он занимает 16 байт и записываются в виде 8 двухбайтных чисел. Первые четыре фрагмента (64 бита) адреса указывают на его сетевую принадлежность и называются сетевым префиксом. Поскольку адреса в формате IPv6 имеют иерархическую структуру, в сетевом префиксе последовательно указываются организация, провайдер и другие элементы цепочки распространения. Последние четыре фрагмента (64 бита) образуют уникальный идентификационный номер интерфейса, который чаще всего формируется на основе MAC-адреса устройства.
Поскольку полный адрес, показанный выше, оказывается довольно громоздким и неудобным в обращении, IPv6 предусматривает возможность сжатия адреса, которое осуществляется в два этапа. Сначала убираются все вводные нули в каждом из четырехзначных фрагментов. При этом адрес, показанный выше, примет вид 2001:db8:49:0:ab00:0:0:102. Кроме того, все состоящие из нулей фрагменты можно заменить двойным двоеточием — тогда мы получим окончательно сжатый адрес вида 2001:db8:49:0:ab00::102. Сокращению не могут быть подвергнуты 2 разделенные нулевые группы из-за возникновения неоднозначности.
Сокращения записи:
2001:0db8:0000:0000:0000:0000:1428:57ab 2001:0db8:0000:0000:0000::1428:57ab 2001:0db8:0:0:0:0:1428:57ab 2001:0db8:0:0::1428:57ab 2001:0db8::1428:57ab 2001:db8::1428:57ab
Типы адресов
| unicast | Идентификатор одиночного интерфейса. Пакет, посланный по уникастному адресу, доставляется интерфейсу, указанному в адресе. |
|---|---|
| anycast | Идентификатор набора интерфейсов (принадлежащих разным узлам). Пакет, посланный по эникастному адресу, доставляется одному из интерфейсов, указанному в адресе (ближайший, в соответствии с мерой, определенной протоколом маршрутизации). |
| multicast | Идентификатор набора интерфейсов (обычно принадлежащих разным узлам). Пакет, посланный по мультикастинг-адресу, доставляется всем интерфейсам, заданным этим адресом. |
Зарезервированные адреса
:: ↔ 0.0.0.0 ::1 ↔ 127.0.0.1 ::a.b.c.d ↔ a.b.c.d ::FFF.a.b.c.d ↔ a.b.c.d FF**:: - широковещательные
IPv6-адреса с вложенными IPv4-адресами
Алгоритмы IPv6 включают в себя механизм (для ЭВМ и маршрутизаторов) организации туннелей для IPv6-пакетов через маршрутную инфраструктуру IPv4. Узлам IPv6, которые используют этот метод, присваиваются специальные IPv6 уникастные адреса, которые в младших 32 битах содержат адрес IPv4. Этот тип адреса называется IPv4-compatible IPv6 address. Определен и второй тип IPv6 адреса, который содержит внутри IPv4 адрес. Этот адрес используется для представления IPv6 адресов узлам IPv4 (тем, что не поддерживают IPv6). Этот тип адреса называется IPv4-mapped IPv6 address.
Метки потоков
Поток — это последовательность пакетов, посылаемых отправителем определённому адресату.
Метки потоков — случайные 24-битные числа.
При получении первого пакета с меткой потока маршрутизатор анализирует дополнительные заголовки, выполняет предписанные этими заголовками функции и запоминает результаты обработки (адрес следующего узла, опции заголовка переходов, перемещение адресов в заголовке маршрутизации и т. д.) в локальном кеше. Ключом для такой записи является комбинация адреса источника и метки потока. Последующие пакеты с той же комбинацией адреса источника и метки потока обрабатываются с учётом информации кеша без детального анализа всех полей заголовка.
Время жизни записи в кеше составляет не более 6 секунд, даже если пакеты этого потока продолжают поступать. При обнулении записи в кеше и получении следующего пакета потока, пакет обрабатывается в обычном режиме и для него происходит новое формирование записи в кеше. Следует отметить, что указанное время жизни потока может быть явно определено узлом отправителем с помощью протокола управления или опций заголовка переходов, и может превышать 6 секунд.
ПриоКурсивное начертаниеритезация пакетов обеспечивается маршрутизаторами на основе поля приоритета. Данное 4-битное поле содержит код требуемого приоритета. Множество значений этого поля разделено на два подмножества:
- от 0 до 7 — трафик с контролем перегрузки (например, протокол TCP снижает трафик при получении сигнала перегрузки);
- от 8 до 15 — трафик без контроля перегрузки (приложения реального времени с постоянной скоростью).
Формат заголовка пакета
| Версия | 4-битный код номера версии Интернет протокола (версия Интернет протокола для IPv6= 6) |
| Приоритет | 4-битный код приоритета |
| Метка потока | 24-битный код метки потока |
| Размер поля данных | 16-битовое число без знака. Несет в себе код длины поля данных в октетах, которое следует сразу после заголовка пакета. Если код равен нулю, то длина поля данных записана в поле данных jumbo, которое в свою очередь хранится в зоне опций. |
| Следующий заголовок | 8-битовый разделитель. Идентифицирует тип заголовка, который следует непосредственно за IPv6 заголовком. Использует те же значения, что и протокол IPv4 [RFC-1700]. |
| Предельное число шагов | 8-битовое целое число без знака. Уменьшается на 1 в каждом узле, через который проходит пакет. При предельном числе шагов, равном нулю, пакет удаляется. |
| Адрес отправителя | 128-битовый адрес отправителя пакета. См. RFC-1884. |
| Адрес получателя | 128-битовый адрес получателя пакета (возможно не конечный получатель, если присутствует маршрутный заголовок). См. RFC-1884. |
Переход с IPv4 на IPv6. Взаимодействие IPv6 и IPv4
Существует несколько приемлемых способов совмещения протоколов IPv4 и IPv6, однако интернет-сообщество еще не решило, какой из них наиболее удобен и позволит обеспечить безболезненный переход к использованию новой технологии.
Три основных способа обеспечения взаимодействия IPv6 и IPv4:
- туннелирование;
- двойной стек;
- трансляция протоколов.
Туннелирование
Суть туннелирования состоит в том, что пакет данных IPv6 внедряется (инкапсулируется) в поле данных пакета IPv4. Получившийся в результате этой операции пакет IPv4 содержит в себе два заголовка, IPv6 и IPv4, и может передаваться через обычные IPv4-сети. Он доставляется к узлу (хосту) декапсуляции, где заголовок IPv4 отбрасывается, а данные передаются к устройству, использующему IPv6. В зависимости от того, где происходит инкапсуляция и декапсуляция, выделяют следующие виды туннелирования:
- "Маршрутизатор – Маршрутизатор";
- "Хост – Маршрутизатор";
- "Маршрутизатор – Хост".
Туннель, используемый в процессе передачи данных, должен иметь точку входа и точку выхода. Точка входа находится на границе инфраструктуры IPv4, а потому определить ее достаточно легко. Точка выхода может задаваться инкапсулятору как вручную (в этом случае туннелирование называется конфигурируемым), так и автоматически (так называемое автоматическое туннелирование). Во втором подходе декапсулятору присваивается совместимый IPv4/IPv6 адрес, в котором адрес IPv4 встроен в последние 32 бита адреса IPv6. Остаток IPv6-адреса в этом случае заполняется нулями.
В основе туннелирования лежит следующая идея. Предположим, два IPv4-узла (например, узлы В и Е на рисунке) хотят обменяться IPv6-дейтаграммами, но их разделяют IPv4-маршрутизаторы. Промежуточные IPv4-маршрутизаторы мы будем называть туннелем. Метод туннелирования заключается в том, что передающий IPv4-узел (узел В) помещает IPv6-дейтаграмму целиком в поле данных дейтаграммы формата IPv4. Затем эта IPv4-дейтаграмма, адресованная получающему IPv4-узлу на другой стороне туннеля (узлу Е), передается первому узлу туннеля (узлу С). Промежуточные IPv4-маршрутизаторы передают эту дейтаграмму друг другу, как обычную дейтаграмму, не зная о том, что она содержит полную дейтаграмму формата IPv6. Наконец, принимающий IPv6-узел на другой стороне туннеля получает IPv4-дейтаграмму, определяет, что она содержит дейтаграмму формата IPv6, извлекает IPv6-дейтаграмму и переправляет ее дальше, как если бы он получил ее по сети от непосредственного соседа.
Двойной стек
Реализация технологии двойного стека предполагает поддержку устройством (узлом), имеющим доступ в Интернет, и протокола IPv6, и протокола IPv4. При этом адрес IPv4, приписанный узлу, должен быть уникальным. Поэтому к моменту исчерпания адресного пространства в IPv4 важно, чтобы внедрение новой технологии находилось на таком уровне, который позволял бы большинству устройств взаимодействовать друг с другом, используя только IPv6-адреса.
Трансляция протоколов
Трансляция протоколов заключается в преобразовании пакетов одной версии протокола в пакеты другой по определенным правилам. Она может осуществляться несколькими способами. Первый из них состоит в использовании протокол-шлюзов, которые размещаются на границах между IPv6-сетями и IPv4-сетями. Кроме того, трансляция может осуществляться с помощью транспортного ретранслятора, который обрабатывает в передаваемом пакете данных IP-заголовки и заголовки транспортного уровня. Наконец, трансляция протоколов возможна путем их преобразования на прикладном уровне через прокси-сервер.
Взаимодействие IPv6 и DNS
Еще одна проблема, связанная с внедрением IPv6, — ее несовместимость с DNS, которая используется сегодня в Интернете. DNS представлена в виде ресурсных записей, каждая из которых принадлежит конкретному доменному имени и содержит ряд сведений о нем, в том числе его IP-адрес. До начала внедрения IPv6 существовало 20 типов таких записей. Они относились к 32-разрядным IP-адресам (так называемые записи "A"), что делало DNS и IPv6 несовместимыми.
Однако затем был определен новый тип ресурсной записи "AAAA", который служит для хранения 128-битного IPv6-адреса. Сам адрес определен в информационной части этой записи и в виде имени представляется в специально созданном домене ip6.int. Это имя выглядит как набор символов, разделенных точками, и заканчивается суффиксом ip6.int.
Клиент, направляющий с устройства запросы на DNS-сервер, должен уметь распознавать записи как об адресах IPv4, так и об адресах IPv6. Получив запрос, DNS-сервер определяет тип ресурсной записи (A или AAAA) и отправляет ее устройству. Распознав запись, устройство выбирает для передачи данных либо протокол IPv4, либо протокол IPv6. При этом, когда IPv4-совместимый адрес назначается какому-либо узлу, в DNS создается две ресурсных записи: AAAA и A. Первая отображает этот адрес в 128-битном формате, а вторая – в 32-битном. Это позволяет устройствам, использующим только протокол IPv6, получать IPv6-адреса, а узлам, работающим только на IPv4 — IPv4 адреса.
Для полной совместимости с IPv6 DNS требует серьезной перестройки.
