 |
|
 |
| Главное меню | ||
· Главная · Права на контект · Скачать NOD32 |
||
| Сетевые технологии | ||
· Учебные пособия и обзоры · Беспроводные технологии · Локальные сети · Сетевое оборудование · Сети хранения данных · TCP/IP · xDSL · ATM · Netware |
||
| Счетчики | ||
|
|
||
| Друзья | ||
 |
 |
|
В конце 1992 года сообщество Интернет для решения проблем адресного пространства и ряда смежных задач разработало три проекта протоколов: “TCP and UDP with Bigger Addresses (TUBA)”; “Common Architecture for the Internet (CatnIP)” и “Simple Internet Protocol Plus (SIPP) [смотри “Протоколы и ресурсы Интернет” Семенов Ю.А., Радио и связь, М 1995]. После анализа всех этих предложений был принят новый протокол IPv6 с IP-адресами в 128 бит вместо 32 для IPv4. Внедрение этого нового протокола представляет отдельную серьезную проблему, так как этот процесс не предполагает замены всего программного обеспечения во всем мире одновременно.
Адресное пространство IPv6 будет распределяться IANA(Internet Assigned Numbers Authority - комиссия по стандартным числам в Интернет [RFC-1881]). В качестве советников будут выступать IAB (internet architecture board - совет по архитектуре Интернет) и IESG (Internet Engineering Steering Group - инженерная группа управления Интернет). IANA будет делегировать права выдачи IP-адресов региональным сервис-провайдерам, субрегиональным структурам и организациям. Отдельные лица и организации могут получить адреса непосредственно от регионального распределителя или сервис провайдера. Передача адресного пространства от IANA не является необратимым. Если по мнению IANA распорядитель адресного пространства допустил серьезные ошибки, IANA может аннулировать выполненное ранее выделение. IANA в этом случае должна сделать все возможное, чтобы не отзывать адреса, находящиеся в активном использовании, за исключением случаев, когда это диктуется техническими соображениями. Оплата за распределение адресов должна использоваться исключительно на деятельность, непосредственно связанную с выделением адресов, поддержанием соответствующих баз данных и т.д. Адресное пространство само по себе не должно стоить ничего. Следует избегать монополизации и любых злоупотреблений при распределении IP-v6 адресов. IANA разработает план первичного распределения IPv6 адресов, включая автоматическое выделение адресов индивидуальным пользователям. IPv6 представляет собой новую версию протокола Интернет (RFC-1883), являющуюся преемницей версии 4 (IPv4; RFC-791). Изменения IPv6 по отношению к IPv4 можно поделить на следующие группы: Расширение адресации В IPv6 длина адреса расширена до 128 бит (против 32 в IPv4), что позволяет обеспечить больше уровней иерархии адресации, увеличить число адресуемых узлов, упростить авто-конфигурацию. Для расширения возможности мультикастинг-маршрутизации в адресное поле введено субполе \"scope\" (группа адресов). Определен новый тип адреса \"anycast address\" (эникастный), который используется для посылки запросов клиента любой группе серверов. Эникаст адресация предназначена для использования с набором взаимодействующих серверов, чьи адреса не известны клиенту заранее. Спецификация формата заголовков Некоторые поля заголовка IPv4 отбрасываются или делаются опционными, уменьшая издержки, связанные с обработкой заголовков пакетов с тем, чтобы уменьшить влияние расширения длины адресов в IPv6. Улучшенная поддержка расширений и опций Изменение кодирования опций IP-заголовков позволяет облегчить переадресацию пакетов, ослабляет ограничения на длину опций, и делает более доступным введение дополнительных опций в будущем. Возможность пометки потоков данных Введена возможность помечать пакеты, принадлежащие определенным транспортным потокам, для которых отправитель запросил определенную процедуру обработки, например, нестандартный тип TOS (вид услуг) или обработка данных в реальном масштабе времени. Идентификация и защита частных обменов В IPv6 введена спецификация идентификации сетевых объектов или субъектов, для обеспечения целостности данных и при желании защиты частной информации. Формат и семантика адресов IPv6 описаны в документе RFC-1884. Версия ICMP IPv6 рассмотрена в RFC-1885. Представление записи адресов (текстовое представление адресов) Существует три стандартные формы для представления ipv6 адресов в виде текстовых строк: Основная форма имеет вид x:x:x:x:x:x:x:x, где \'x\' шестнадцатеричные 16-битовые числа. Примеры: fedc:ba98:7654:3210:FEDC:BA98:7654:3210 1080:0:0:0:8:800:200C:417A Заметьте, что ненужно писать начальные нули в каждом из конкретных полей, но в каждом поле должна быть, по крайней мере, одна цифра (за исключением случая, описанного в пункте 2.). Из-за метода записи некоторых типов IPv6 адресов, они часто содержат длинные последовательности нулевых бит. Для того чтобы сделать запись адресов, содержащих нулевые биты, более удобной, имеется специальный синтаксис для удаления лишних нулей. Использование записи \"::\" указывает на наличие групп из 16 нулевых бит. Комбинация \"::\" может появляться только при записи адреса. Последовательность \"::\" может также использоваться для удаления из записи начальных или завершающих нулей в адресе. Например:1080:0:0:0:8:800:200c:417a уникаст-адрес ff01:0:0:0:0:0:0:43 мультикаст адрес 0:0:0:0:0:0:0:1 адрес обратной связи 0:0:0:0:0:0:0:0 неспецифицированный адрес может быть представлено в виде:1080::8:800:200c:417a уникаст-адрес ff01::43 мультикаст адрес ::1 адрес обратной связи :: не специфицированный адрес Альтернативной формой записи, которая более удобна при работе с ipv4 и IPv6, является x:x:x:x:x:x:d.d.d.d, где \'x\' шестнадцатеричные 16-битовые коды адреса, а \'d\' десятичные 8-битовые, составляющие младшую часть адреса (стандартное IPv4 представление). Например: 0:0:0:0:0:0:13.1.68.3 0:0:0:0:0:FFFF:129.144.52.38 или в сжатом виде: ::13.1.68.3 ::FFFF:129.144.52.38 Максимальное время жизни пакета В отличие от IPv4, узлы IPv6 не требуют установки максимального времени жизни пакетов. По этой причине поле IPv4 \"time to live\" (TTL) переименовано в \"hop limit\" (предельное число шагов) для IPv6. На практике очень немногие IPv4 приложения, используют ограничения по TTL, так что фактически это не принципиальное изменение. Максимальный размер поля данных для протоколов высокого уровня При вычислении максимального размера поля данных, доступного для протокола верхнего уровня, должен приниматься во внимание большой размер заголовка IPv6 относительно IPv4. Например, в IPv4, mss опция TCP вычисляется как максимальный размер пакета (значение по умолчанию или величина полученная из MTU) минус 40 октетов (20 октетов для минимальной длины IPv4 заголовка и 20 октетов для минимальной длины TCP заголовка). При использовании TCP поверх IPv6, MSS должно быть вычислено как максимальная длина пакета минус 60 октетов, так как минимальная длина заголовка IPv6 (т.e., IPv6 заголовок без заголовков расширения) на 20 октетов больше, чем для IPv4. Расширение DNS для поддержки IP-версии 6 (DNS Extensions to Support IP Version 6. S. Thomson. RFC-1886) Существующая поддержка записи адресов Интернет в DNS (Domain Name System) не может быть легко расширена для поддержки IPv6-адресов, так как приложение предполагает, что адресный запрос вернет только 32-битовый IPv4-адрес. Для того чтобы запоминать IPv6-адреса, определены следующие расширения: Определен новый тип ресурсной записи, для того чтобы установить соответствие между именами доменов и адресами IPv6. Определен новый домен, предназначенный для обработки запросов по новым адресам. Существующие запросы, которые выполняют выявление IPv4-адресов, переопределены для получения как IPv4, так и IPv6-адресов. Изменения выполнены так, чтобы быть совместимыми с имеющимся программным обеспечением. Существующая поддержка IPv4-адресов сохраняется. |