TCP/IP использует 4-байтовые (32-битовые) адреса в теперешней
реализации (IPv4), также называемые IP-адресами
(Internet-Protocol адреса), для адресации хостов.
TCP/IP позволяет любым двум машинам общаться напрямую. Чтобы это
осуществить все хосты, находящиеся в сети, должны иметь уникальный
IP адрес. Чтобы гарантировать это, IP адреса контролируются одной
центральной организацией - InterNIC. Она выдает определенные диапазоны
адресов (сетевых адресов) напрямую сайтам, желающим войти в структуру
Интернет или Интернет провайдерам, которые, в свою очередь, выдают
адреса своим пользователям.
Если Ваш университет или компания подключены к Интернет, то он(она)
имеет (как минимум) один такой сетевой адрес для собственных нужд,
обычно полученный не напрямую от InterNIC, а через поставщика
услуг Интрнет (Internet Service Provider ISP).
Если Вы всего лишь хотите запустить вашу частную сеть для дома, см.
далее как «создать» Ваши собственные IP адреса. Тем не
менее, если Вы хотите подключить Вашу машину к (реальной :-) Интренет,
Вы должны получить IP адреса от Вашего локального администратора сети
или провайдера.
IP адреса обычно записываются в «четырехчисловом с
точками» формате
- четыре байта записываются в десятеричной системе (наиболее значимые
байты идут первыми),
и разделяются точками. Например, 132.199.15.99 должен быть верным
адресом. Другой способ записи IP адреса: можно использовать одно
32-битное шестнадцатеричное слово, например, 0x84c70f63. Это не так
удобно как четырехчисловая форма, но также используется довольно
часто (см. далее!).
Иметь доступ к сети не означает ничего более кроме установки
вышеописанных 32 бит адреса в определенное значение. Некоторые биты
используются для идентификации сети и называются сетевыми битами.
Оставшиеся биты могут использоваться для адресации хостов в этой сети,
их называют битами хоста.
Рисунок 20.1, «
IPv4 адреса делятся на большую часть определяющую сеть - и меньшую
определяющую хост.
» иллюстрирует разделение.
Рисунок 20.1.
IPv4 адреса делятся на большую часть определяющую сеть - и меньшую
определяющую хост.
В приведенном выше адресе 132.199.0.0
(биты хоста выставлены в 0 в сетевом адресе), адрес хоста в этой
сети - 15.99.
Откуда мы узнали что адрес хоста длинной 16 бит? Ну,
это определяется провайдером, который предоставляет Ваши сетевые
адреса. В классах междоменной маршрутизации (classless inter-domain
routing CIDR) используемых теперь,
размер поля хоста обычно находится в пределах от 2 до
16 бит, а количество бит сети пишется после сетевого адреса и
отделяется «/», например, 132.199.0.0/16
говорит о том, что в данной нотации 16 сетевых бит.
Когда говорят о «размере» сети, обычно имеется в виду
«/16», «/24», и т.д.
До использования CIDR, использовались четыре класса сетей.
Каждая начиналась с определенного набора битов, идентифицирующих ее.
Вот эти четыре класса:
-
Сласс A начинается с «0» как самого значимого бита.
Следующие семь бит адреса класса A определяют сеть, оставшиеся
24 бита могут использоваться для адресации хостов.
Так в одной сети класса A может быть до
224 хостов.
Вероятно нет необходимости для Вас (или Вашего университета,
или компании, или чего-либо еще) использовать все пространство
адресов класса A.
В нотации CIDR сеть класса A с ее восемью битами сети это
«/8».
-
Класс B начинается с «10» как самых значимых бит.
Следующие 14 бит используются для адреса сети, оставшиеся
16 бит используются для адресации более 65000 хостов.
Адреса класса B сегодня используются очень редко,
они используются в основном компаниями и университетами
редко встречающимся в адресном пространстве IPv4.
В нотации CIDR сеть класса B с ее шестнадцатью битами сети
будет описана как «/16».
Возвращаясь к предыдущему примеру, Вы можете видеть что
132.199.15.99 (или 0x84c70f63, который здесь более уместен!)
находится в сети класса B, так как 0x84... =
1000... (двоичная система).
Следовательно, адрес 132.199.15.99 может быть разделен на
адрес ести 132.199.0.0 и адрес хоста 15.99.
-
Класс C определяется по MSB со
«110», позволяет адресовать лишь
256 (в действительности: лишь 254, см. далее) хостов в каждой из
221 возможных сетей класса C.
Адреса класса C обычно используются в (небольших) компаниях.
В нотации CIDR сеть класса C с ее двадцатью четырьмя битами сети
будет описана как «/24».
Остальные адреса, начиная со
«111». Используются в специальных целях
(например, широковещательные адреса) и сейчас нас не интересуют.
Пожалуйста запомните, что биты, используемые для идентификации класса
сети, являются частью сетевого адреса.
Если отделить адрес хоста от адреса сети, легко получим
«сетевую маску». В этой маске все биты сети
установлены в «1», биты хоста «0». Таким
образом, соединив вместе IP-адреса и сетевую маску логической функцией
AND, получим адрес сети.
Продолжая наш пример, 255.255.0.0 возможная маска сети для
132.199.15.99. Если добавить эту маску, останется адрес сети
132.199.0.0.
Для адресов в нотации CIDR, количество бит сети скажут нам
сколько значащих бит адреса необходимо установить в «1»
чтобы получить сетевую маску для рассматриваемой сети.
Для классовой адресации, каждый класс сети имеет фиксированную
предустановленную маску:
Класс A (/8): предустановленная маска сети: 255.0.0.0, первый байт
адреса: 1-127
Класс B (/16): предустановленная маска сети: 255.255.0.0, первый
байт адреса: 128-191
Класс C (/24): предустановленная маска сети: 255.255.255.0, первый
байт адреса: 192-223
Еще одно понятие, упоминаемое здесь - «широковещательный
адрес». При обращении к этому адресу, все
хосты рассматриваемой сети получат отправленное сообщение.
Широковещательный адрес характеризуется установленными в
«1» всеми битами хоста.
Говоря о 132.199.15.99 с сетевой маской 255.255.0.0, широковещательный
адрес должен получиться 132.199.255.255.
Вы можете спросить: Но если я хочу использовать для адресации хостов
все биты «0» или «1»? Ну, это не будет
работать, так как сетевой и широковещательный адреса должны
существовать! По этому, сеть класса B
(/16) может содержать
216-2 хостов, а класса C (/24)
не может содержать более 28-2
= 254 хостов.
С другой стороны кроме всех этих категорий адресов, существует
специальный IP адрес 127.0.0.1 который всегда ссылается на
«локальный» хост, т.е. если Вы обратитесь к 127.0.0.1
Вы будете общаться сами с собой без какой-либо сетевой активности.
Это иногда используется программами, установленными на Вашей машине
или для проигрывания окружения, если у Вас нет других хостов,
подключенных к Вашей сети.
Давайте соберем вместе знания полученные в этом разделе:
- IP адрес
32-битный - адрес, содержащий биты хоста и сети.
- Адрес сети
IP адрес со всеми битами хоста, установленными в
«0».
- Маска сети
32-битная маска с «1» для битов сети и
«0» для битов хоста.
- Широковещательный адрес
IP адрес со всеми битами хоста выставленными в
«1».
- Адрес локального хоста (locahost)
IP адрес всегда равный 127.0.0.1.
После подробного обсуждения сетевых масок, адресов сети, хоста и
других, я должен сказать, что это еще не вся правда.
Представьте ситуацию в Вашем университете, который обычно использует
адреса класса B (/16), допустим имеется до
216 ~= 65534
хостов в этой сети. Может быть лучше иметь все эти машины в одной
сети, но это просто невозможно из-за ограничений транспортных
носителей зачастую используемых на данный момент.
Например, при использовании «тонкого» ethernet,
максимальная длинна кабеля будет 185 метров. Даже с повторителями,
в которых усиливается сигнал, этого будет не достаточно чтобы покрыть
все необходимое расположение машин. С другой стороны, максимальное
количество хостов на линию ethernet не может превышать 1024 и Вы
потеряете часть производительности если перейдете этот предел.
Так, теперь вы в тупике? Имеете адрес, который позволяет использовать
более 60000 хостов, но связаны носителем который позволяет
использовать намного меньше этого предела?
Ну, конечно нет! :-)
Решение в разделении «большой» сети класса B на несколько
меньших сетей, обычно называемых подсетями. Эти подсети лишь позволят
иметь, скажем, 254 хостов в них (т.е. Вы разделите одну большую сеть
класса B на несколько сетей класса C!).
Чтобы это сделать, Вам нужно изменить Вашу сетевую маску, увеличив
количество сетевых бит и уменьшив количество бит хоста в ней.
Для этого обычно достаточно границы байта,
но Вы не обязаны делать это именно так. Так, часто Ваша сетевая маска
не будет 255.255.0.0 как поддерживается сетью класса B,
но ее можно установить в 255.255.255.0.
В нотации CIDR, Вы теперь запишете «/24» вместо
«/16» показав, что 24 бита адреса используются для
идентификации сети и подсети, вместо 16-ти которые использовались
до этого.
Это даст Вам один добавочный байт сети для присвоения каждой
(физической!) сети. Все 254 хоста в этой подсети смогут теперь
обращаться напрямую к любому другому и Вы сможете создать 256 таких
сетей класса C. Это должно удовлетворить Ваши требования.
Чтобы понять лучше этот момент, давайте продолжим наш предыдущий
пример. Скажем наш хост 132.199.15.99 (я буду называть его dusk с этого момента; поговорим об
назначении имен хостам позже) имеет маску сети
255.255.255.0 и таким образом он в подсети 132.199.15.0/24. Давайте,
кроме того, введем еще немного хостов с которыми мы можем работать,
см. Рисунок 20.2, «Наша демонстрационная сеть».
В данной сети, dusk может обращаться напрямую к
dawn, так как они оба
находятся в одной подсети. (Здесь имеются другие компьютеры
подключенные к подсети 132.199.15.0/24, но на данный момент они для
нас не имеют значения)
Но что, если dusk
понадобится обратиться к хосту из другой подсети?
Тогда трафик пройдет через один или больше шлюзов (маршрутизаторов),
которые подключены в две подсети. Поэтому, маршрутизатор всегда имеет
2 различных адреса, по одному для каждой подсети. Маршрутизатор
функционально прозрачен, т.е. Вам не нужно обращаться к нему чтобы
достичь хостов с «другой» стороны. Вместо этого, Вы
обращаетесь к этому хосту непосредственно и пакеты будут правильно
смаршрутизированы.
Например. Скажем dusk необходимо получить несколько
файлов с локального ftp сервера. Так dusk не может достичь ftp непосредственно (потому что он в
другой подсети), все эти пакеты будут перенаправлены к нему через
«основной шлюз» (defaultrouter) rzi (132.199.15.1), который знает
куда перенаправить пакеты.
Dusk знает адрес основного
шлюза в его сети (rzi, 132.199.15.1), и он перенаправит
любые пакеты адресованные не этой подсети, т.е. перенаправит все IP
пакеты в которых третий байт адреса не 15.
Тогда (основной)маршрутизатор отправит пакеты назначенному хосту,
также как и в сеть сервера FTP.
В данном примере, все пакеты перенаправляются в
сеть 132.199.1.0/24, просто потому что это базовая сеть,
самая важная часть сети, которая переносит весь трафик, который
передается между разными сетями.
Почти все остальные сети, находящиеся рядом с 132.199.15.0/24
подключаются к основной сети аналогичным способом.
Но что, если мы подключим еще одну подсеть к 132.199.15.0/24
кроме 132.199.1.0/24? Сходная ситуация отображена на
Рисунок 20.3, «Подключение одной подсети к другой».
Если мы теперь из dusk
попытаемся достичь хоста, который расположен в подсети
132.199.16.0/24, то это не должно маршрутизироваться на
rzi, а прямиком
отправится на route2
(132.199.15.2). Dusk должен знать о необходимости
перенаправлять эти пакеты на route2 и отправлять все остальные на
rzi.
Когда конфигурируется dusk, Вы говорите ему отправлять все
пакеты для подсети 132.199.16.0/24 на route2, и все остальные на
rzi. Вместо определения
этих значений по умолчанию 132.199.1.0/24, 132.199.2.0/24,
и т.д., 0.0.0.0 может использоваться для определения основного
маршрутизатора.
Возвращаясь к Рисунок 20.2, «Наша демонстрационная сеть», здесь аналогичная проблема
когда dawn хочет отправить
сообщение на noon, который
подключен к dusk
через последовательную линию. Тогда посмотрим на IP адрес,
noon кажется что он
подключен к сети 132.199.15.0, но это не так. Вместо этого dusk используется как шлюз и
dawn должен отправлять
эти пакеты на dusk, который будет перенаправлять их
на noon. То, каким образом
dusk принимает пакеты
которые адресованы не ему, а другому хосту
(noon) называется
«arp проксирование».
То же происходит когда хост из другой подсети хочет отправить пакет на
noon. Он отправляет пакет
dusk
(возхможно смаршрутизированный через
rzi).
В предыдущем разделе, когда мы говорили о хостах, мы обращались к ним
по IP адресам. Это было необходимо чтобы сформировать представление о
различных типах адресов. Когда говорят о хостах, то в основном удобнее
использовать «имена», как мы делали, когда говорили о
маршрутизации.
Большинству приложений безразлично выдаете вы им IP адрес или имя
хоста. Тем не менее, внутри они используют IP адреса
и есть несколько способов сопоставить имена хостов с IP адресами,
каждый из которых имеет свой собственный метод конфигурации.
В этом разделе мы рассмотрим смысл каждого способа,
в следующей главе, мы поговорим о конфигурационной части.
Преобразование из имен хостов (и доменных имен) в IP адреса
заключается в части программного обеспечения, называемой
«resolver (разрешатель)».
Это не дополнительный сервис, но некоторые библиотеки, которые обычно
привязываются ко всем приложениям, используют сетевые вызовы. Тогда
resolver попытается вернуть по предоставленному Вами имени хоста
его IP адрес. См. [RFC1034]
и [RFC1035] для получения более
детальной информации по resolver.
Имена хостов обычно длинной до 256 символов и содержат буквы,
цифры и символы («-»); регистр игнорируется.
Для сетей и подсетей возможно (и желательно) группировать хосты в
домены и поддомены. Когда получаете Ваш сетевой адрес,
Вы обычно также получаете доменное имя от Вашего провайдера.
Так подсети, представляют Ваши поддомены.
С другой стороны, касаемо IP адресов,
(под)домены на прямую не зависят от (под)сетей; например,
один домен может содержать хосты из разных подсетей.
Рисунок 20.2, «Наша демонстрационная сеть» отображает следующее: обе подсети
132.199.1.0/24 и 132.199.15.0/24 (и остальные) являются частью
поддомена
«rz.uni-regensburg.de». Домен
университета Резенбурга получен от его IP провайдера
«uni-regensburg.de»
(«.de» для
Германии), поддомен «rz» для вычислительного центра,
компьютерного центра.
Имена хостов, поддоменные и доменные имена разделяются точками
(«.»). Также возможно использовать более одного уровня
поддоменов, хотя обычно это не практикуется. Примером может быть
runetbsd.devnet.apk.od.ua.
Имя хоста, включающее (под)домен также называется
полным доменным именем (fully qualified domain name
FQDN). Например,
IP адрес 132.199.15.99 принадлежит хосту с FQDN dusk.rz.uni-regensburg.de.
Ранее я говорил что IP адрес 127.0.0.1 всегда
принадлежит локальному хосту, независимо от «реального»
IP адреса хоста. Следовательно, 127.0.0.1 всегда соотносится с именем
«localhost».
Три различных способа преобразования имен хостов в
IP адреса: /etc/hosts, сервис доменных имен
(Domain Name Service - DNS) и сетевой информационный
сервис (Network Information Service - NIS).
Первый и самый простой способ преобразования имен хостов в
IP адреса - использование таблицы, говорящей какие IP адреса
принадлежат каким именам хостов. Эта таблица находится в файле
/etc/hosts в следующем формате:
IP адрес имя хоста [псевдоним [...]]
Строки, начинающиеся с символа «#»
определяются как комментарии. Остальные строки содержат один
IP адрес и соответствующее(ие) имя(имена) хоста(ов).
Невозможно присвоить несколько IP адресов одному хосту, даже
если Вы подумали о мрашрутизаторе.
Например rzi
в действительности имеет два определенных имени, для каждого адреса:
rzi
и rzia (но, пожалуйста,
не спрашивайте меня какое имя принадлежит какому адресу!).
Выдача хосту нескольких псевдонимов может быть удобна, если Вы
хотите определить Вашему хосту предоставлять специальные услуги
под этим именем, так обычно поступают с FTP серверами. Первое
(саме левое) имя обычно реальное (каноническое) имя хоста.
Также выдача псевдонимов удобна для назначения полного имени хоста
(включая домен) как канонического имени и использовать только это
имя хоста (без домена) как псевдоним.
Важно: Здесь
должно быть соотношение
localhost к 127.0.0.1 в /etc/hosts!
/etc/hosts присущи проблемы, характерные для
больших сетей: когда добавляется даже один хост или у одного хоста
меняется адрес, файлы
/etc/hosts на всех машинах должны быть
изменены! Это не только занимает время, это также, очень возможно
приведет к ошибкам и несоответствиям, влекущим за собой проблемы.
Другой способ - оставить одну таблицу (базу данных) имен хостов
для сети и делать клиентские запросы к этому «серверу
имен». Обновлять нужно будет лишь один сервер имен.
Это основная идея заложенная в сервис доменных имен (DNS).
Обычно, используется один сервер имен на каждый домен (далее
DNS) и каждый хост (клиент) в этом домене знает какой это домен и
к какому серверу имен в этом домене обращаться.
Когда сервер получает запрос о хосте, который не находится в этом
домене, он перенаправляет запрос к любому DNS домена в запросе или
узнает какой DNS запрашивать в данном домене. Если DNS,
перенаправляющий запрос, не знает как его обработать, он
перенаправляет его к DNS одной ступенью выше. Это не бесконечно,
существуют несколько «корневых (root)» серверов,
которые знают обо всех доменах.
См. Глава 23, Система доменных имен для детального ознакомления с DNS.
Желтые страницы (Yellow Pages - YP) были
предложены
Sun Microsystems. Название было изменено на сервис сетевой
информации
(Network Information Service NIS) потому что YP
уже были торговой маркой British telecom. Так, когда я говорю о
NIS вы будете знать, что я имею в виду. ;-)
Он имеет довольно немного конфигурационных файлов в Unix системе
и часто изменению подлежит лишь один из файлов
соединенных хостов. Эти хосты группируются вместе в домене NIS
(который не имеет ничего общего с доменами,
построенными с использованием DNS!) и обычно содержатся в одном
кластере рабочих систем.
Например конфигурационные файлы разделяемые среди этих хостов:
/etc/passwd,
/etc/group - и последний, но немаловажный -
/etc/hosts.
Так, Вы можете «злоупотреблять» NIS для получения
уникального преобразования имен в адреса на всех хостах в одном
(NIS-)домене.
Единственный недостаток, который не позволяет везде использовать NIS
для этого преобразования: в отличие от DNS, NIS не предоставляет
возможности разрешать имена хостов, которых нет в таблице.
Здесь нет хостов «уровнем выше» которые сервер
NIS может запросить и преобразование не состоится!
Sun'овский NIS+ содержит решение этой проблемы, но
так как NIS+ доступен только на системах Solaris, этого слишком мало
сейчас для нас.
Не поймите меня не правильно: NIS это хороший способ управления,
например, пользовательской информацией
(/etc/passwd, ...) в кластере рабочих систем,
это просто не очень удобно для разрешения имен хостов.
Методы разрешения имен описанные выше обычно используются сегодня
для разрешения имен хостов в IP адреса, но они не единственные.
В основном, может использоваться любой механизм баз данных, но
они не используются в NetBSD.
Давайте быстро посмотрим, что Вам может встретиться.
С NIS-подобной иерархией структуры данных, NIS+ не предполагает
рассмотрения в этой части. Хотя таблицы могут устанавливаться так,
что если запрос не может быть обработан доменным сервером, его может
обработать «вышестоящий» домен. Например, Вы можете
выбрать домен содержащий список всех хостов (пользователей,
групп,...) которые действительны для всей компании, который
определяет это для каждого подразделения, и т.д. NIS+, на
сегодняшний день, не используется массово, даже Sun вернула назад
NIS по умолчанию.
В последнем столетии, был создан стандарт X.500 для объединения
как простых баз данных типа /etc/hosts
так и комплексных, иерархических систем, которые
могут использоваться сегодня, например, в DNS. X.500 не имел
реального успеха, в основном из-за того, что пытался сделать
слишком много одновременно.
Урезанная версия, доступная сегодня как легковесный протокол доступа
к каталогам (Lightweight Directory Access
Protocol LDAP), который стал популярен в
последнее время для управления данными как пользователей, так и
хостов и другого в маленьких и средних организациях.
Согласно экспертам, Интернет, который мы знаем, столкнется с
проблемами в ближайшие несколько лет. Это произойдет из-за быстрого
роста и ограничений в его устройстве, это будет точка, когда не
останется больше свободных адресов, доступных для подключения новых
хостов. Тогда будет невозможно добавить новых web серверов, новые
пользователи не смогут получить учетную запись у провайдеров, новые
машины не смогут получить доступ к web или участвовать в онлайн
играх - некоторые люди могут назвать это серьезной проблемой.
Некоторые проблемы можно решить. Один из популярных способов - не
получать уникальный всемирный адрес для каждой пользовательской
машины, а в основном назначить им «локальные» адреса,
и скрыть некоторые машины за официальным, глобальным уникальным
адресом. Это достигается так называемой «Трансляцией
сетевых адресов» (Network
Address Translation - NAT), также известной как
IP
маскарадинг). Это имеет недостатки, так машины, скрытые за
глобальным адресом не могут быть адресованы и, как результат этого,
не может быть открыто соединение с теми - кто использует онлайновые
игры, одноранговые сети, и т.д. Более подробно недостатки
NAT, можно рассмотреть в [RFC3027].
Избавиться от проблем с Интернет адресами можно отказавшись от
старого Инетрнет протокола у которого такие ограничения возможности
адресации и используя новый протокол, не имеющий таких ограничений.
Протокол или, в действительности, набор протоколов, используемый
машинами для соединения в сегодняшнем Интернете - блок TCP/IP
(Transmission Control Protocol, Internet Protocol, протокол контроля
передачи и Интернет протокол), и версия 4, которая используется
сейчас, имеет все недостатки, описанные ранее. Переход на другую
версию протокола, не имеющую этих недостатков, конечно необходимо
чтобы эта версия существовала, сегодня очень актуален. Интернет
протокол версии 6 (IPv6) полностью покрывает любые возможные
в будущем требования к адресному пространству и также рассчитан на
такие вещи как секретность, шифрование и лучшую поддержку мобильных
технологий.
Пропустим основные понятия нынешних принципов работы IPv4,
этот текст рассчитан как введение в протокол IPv6.
Покрыты изменения в формате адреса и разрешении имен.
Параллельно почитайте
Раздел 25.4, «IPv6 соединения и переход сквозь 6to4», здесь объясняется как
использовать IPv6 даже если Ваш провайдер не предлагает
испльзование простого и эффективного механизма перехода,
называемого 6to4. Цель - выйти в онлайн с IPv6, приведены примеры
конфигурации для NetBSD.
Когда говоришь людям о миграции с IPv4 на IPv6, вопрос, который Вы
обычно слышите: «зачем?». Это имеет смысл сделать по
следующим причинам:
Большее адресное пространство, предлагаемое IPv6, саме очевидное
отличие от IPv4. В то время как сегодняшняя архитектура Интернет
базируется на 32-битной адресации,
новая версия имеет для этого 128 возможных бит.
Благодаря увеличенному адресному пространству рабочие окружения,
такие как NAT, больше не понадобятся. Это позволит сделать IP
соединения полностью безусловными как для сегодняшних,
базирующихся на IP, машин так и для, набирающих популярность,
мобильных устройств, таких как PDA и мобильные телефоны, которые
получат полный IP доступ через GPRS и UMTS.
Пока припомним мобильные устройства и IP, еще одно важное условие:
нужно иметь в виду что нужен некий специальный протокол,
поддерживающий мобильность, и осуществляющий это протокол,
называемый - «мобильный IP» (Mobile IP) - одно из
требований ко всему стеку IPv6. Таким образом, если Вы перейдете
на IPv6, Вы получите поддержку роуминга между разными сетями,
каждый раз как Вы покидаете одну сеть и входите в другую.
Поддержка роуминга возможна также и с IPv4, но
здесь есть несколько условий, которые необходимо выполнить,
пока это заработает. С IPv6 Вам это не понадобится - поддержка
мобильности одно из требований дизайна IPv6. См.
[RFC3024] чтобы более подробно ознакомиться с
требованиями, которые необходимо выполнить для осуществления
мобильной адресации IP в IPv4.
Кроме поддержки мобильности, безопасность также является
требованием для преемника сегодняшней версии Интернет протокола.
Как результат - стек протокола IPv6 требует включения IPsec. IPsec
позволяет идентифицировать, шифровать и сжимать любой
IP трафик. В отличие от протоколов уровня приложения, таких как
SSL или SSH, весь IP трафик между двумя узлами может быть
обработан без установки каких бы то ни было приложений.
Что позволяет всем приложениям использовать шифрование и
идентификацию и эта политика может быть установлена на
межхостовой
(или даже межсетевой) основе, но не межприложенческой/сервисной.
Для ознакомления с IPsec список документации можно найти в
[RFC2411], корневой протокол описан в
[RFC2401].
После беглого ознакомления со всеми важнейшими свойствами
IPv6, здесь мы детально рассмотрим основы IPv6.
Небольшое понимание работы IPv4 получено
и отличия в IPv6 отмечены. Начнем с адресов
IPv6, их разделения на различные типы и того как получить
широковещательный адрес, после чего обсудим уровень IP в части
изменений в разрешении имен и что нового в DNS для IPv6.
Адрес IPv4 это 32-битное значение, которое обычно записывается в
«четырехчисловм с точками» виде, где каждая
«четверть» представляет байт со значением от 0 до
255, например:
127.0.0.1
Это, теоретически, позволяет даресовать до
232 или ~4 биллионов
хостов, для подключения к интренет сегодня. Из-за группировки
не все адреса еще доступны.
Адреса IPv6 используют 128 бит, которые в результате предоставляют
2128
теоретически адресуемых хостов. Это позволит адресовать
действительно большое количество машин и конечно покроет все
сегодняшние требования, плюс все новомодные КПК и телефоны
IP телефонии без каких-либо проблем в ближайшем будущем.
При написании адресов IPv6, они обычно представляются группами
по 16 бит, записанных как четыре шестнадцатеричных цифры,
и группы разделяются двоеточием. Например:
fe80::2a0:d2ff:fea5:e9f5
Здесь виден особый нюанс - серия последовательных нулей
может быть один раз заменена двойным двоеточием «::»
в адресе IPv6. Таким образом вышеуказанный адрес соответствует
fe80:0:00:000:2a0:d2ff:fea5:e9f5 - ведущие нули в группах можно
пропускать, а «::» может использоваться в адресе
IPv6 лишь один раз.
Чтобы сделать адреса удобнее, они разбиваются на две части,
которые содержат биты идентифицирующие сеть, в которой находится
машина, и биты идентифицирующие машину в
(под)сети. Эти биты известны как биты сети и биты хоста,
и в обоих: IPv4 и IPv6, биты сети находятся «слева»,
самые значимые биты в IP адресе, а биты хоста
«справа», наименее значимые биты, как показано на
Рисунок 20.4, «
Адреса IPv6 также разделены на более значимые биты сети и менее
значимые биты хоста
».
RFC2461]),
являющегося преемником ARP протокола IPv4. В отличие от
ARP, NDP производит не только поиск адреса IPv6 для
MAC адреса (часть запрос/предоставление окружения), но также
предоставляет услуги по маршрутизации и обслуживаемым префиксам,
используемым для автоконфигурации хостов IPv6, как описано в
предыдущем параграфе.
В IPv4, хост обычно имеет один IP адрес на сетевой
интерфейс или даже на машину если стек IP это позволяет.
Только очень редкие приложения как веб сервера позволяют на
машинах иметь белее одного IP адреса. В IPv6 это не так.
Для каждого интерфейса в нем не один уникальный глобальный
IP адрес, а еще два других адреса: локальный адрес связи
и локальный адрес места. Локальный адрес связи имеет префикс
fe80::/64 и биты хоста полученные из EUI64 адреса интерфейса.
Локальный адрес связи используется для контактов хостов и
маршрутизаторов только в той же самой сети,
адреса не видимы и не достижимы из остальных подсетей.
Если необходимо, это способ другого использования глобальных
адресов (как назначенных провайдером), или использование
локального адреса места. Локальный адрес места назначается
сетевым адресом fec0::/10, и подсети и хосты могут быть адресованы
просто как назначенная провайдером сеть. Единственное отличие в
том, что адреса не видимы машинам извне, так как находятся в
другой сети, и их адрес «локального места» находится
в другой физической сети (если это все назначено). Как с 10/8
сетью в IPv4, адрес локального места может использоваться, но
также не существовать. Для IPv6 обычно имеется назначенные хостам
локальный адрес связи и глобальный IP адрес. Локальный адрес
места довольно необычен в наши дни и не заменяет глобальный
уникальный адрес если требуется глобальное подключение.
В окружении IP, есть три способа обратиться к хосту:
одиночный запрос (unicast), широковещательный запрос (broadcast) и
множественный запрос (multicast). В основном используются прямые
обращения через адрес для одиночного запроса. В
IPv4, адрес одиночного запроса это «обычный» IP адрес
назначенный конкретному хосту, со всеми установленными битами
адреса. Широковещательный адрес используется для адресации всех
хостов в той же IP подсети и имеет биты сети, установленные в
адрес
сети, и все биты хоста, установленные в «1» (который
можно просто получить использовав маску подсети и некоторые
побитовые операции). Адреса множественных запросов используются
для достижения количества хостов в той же группе множественного
запроса, в которой машины могут быть разбросаны по всей Интернет.
Машины должны явно включаться в мультивещательные группы и в этом
случае существует специальные адреса IPv4, используемые для
множественных запросов, расположенные в подсести
224/8. Мультивещание не очень широко используется в IPv4,
лишь некоторые приложения типа MBone широковещательных аудио и
видео утилит их используют.
В IPv6, адрес одиночного запроса используется тот же, что и в
IPv4, никаких сюрпризов - все биты сети и хоста предназначаются
для идентификации целевых сети и машины. Широковещательные запросы
в IPv6 более не поддерживаются тем же образом как в IPv4,
здесь входят в игру множественные запросы.
Адреса в сети ff::/8 зарезервированы для мультивещательных
приложений, и здесь существует два специальных мультивещательных
адреса, которые заменяют широковещательные адреса из IPv4.
Один - это мультивещательный адрес «все
маршрутизаторы», другой - для «всех хостов».
Адреса, специфичные для подсети, т.е. маршрутизатор подключенный
к двум независимым сетям может адресовать все хосты/маршрутизаторы
в любой из подсетей к которым подключен. Здесь адреса: