Необходимость модернизации транспортных протоколов стека TCP/IP была вызвана несколькими причинами, и, прежде всего, переходом к промышленному использованию Internet: построение корпоративных сетей с использованием транспортных средств Internet (виртуальные частные сети), применение Web-технологии для получения доступа к корпоративной информации, ведение электронной коммерции с помощью Internet, внедрение Internet в индустрию развлечений (распространение видеофильмов, звукозаписей, интерактивные игры).
В результате наблюдается быстрый рост сети, изменяется характер трафика и меняются требования, предъявляемые к качеству обслуживания сетью ее пользователей.
Динамика роста Internet такова, что сегодня трудно привести вполне достоверные сведения о числе сетей, узлов и пользователей Internet. Быстрый рост сети усугубляет уже давно ощущаемый дефицит IP-адресов, вызывает перегрузку маршрутизаторов, которые должны уже сегодня обрабатывать в своих таблицах маршрутизации информацию о нескольких десятках тысяч номеров сетей, а также ведет к резкому увеличению суммарного объема передаваемого по Internet трафика.
Все более широкое использование Internet в качестве общемировой широковещательной сети, заменяющей сети радио и телевидения, приводит к изменению характера передаваемого трафика. Наряду с традиционным компьютерными данными все большую долю трафика составляют мультимедийные данные. Синхронный характер мультимедийного трафика предъявляет нетрадиционные для Internet требования по качеству обслуживания - предоставления гарантированной полосы пропускания с заданным уровнем задержки передаваемых пакетов.
Промышленное использование Internet предполагает определенный уровень защиты данных - аутентификацию абонентов, обеспечение конфиденциальности и целостности данных. Особенно это важно при ведении в Internet электронной торговли, а также при построении частных виртуальных сетей.
Рост популярности Internet привел к появлению новых категорий пользователей. Во-первых, в сеть пришло много непрофессиональных пользователей - сотрудников предприятий, работающих на дому, людей, использующих Internet как средство развлечения или как неисчерпаемый источник информации. Многие из них желали бы работать как мобильные пользователи, не расставаясь со своим компьютером в поездках, вдали от своей "родной" сети. В этих случаях очень важным становится такое требование как возможность автоконфигурирования стека TCP/IP, когда все параметры стека (в основном это касается IP-адресов компьютера, DNS-сервера и маршрутизаторов) автоматически сообщаются компьютеру при его подключении к сети.
Таким образом, главными целями модификации транспортных протоколов Internet являются:
Активные работы по модернизации протокола IP и разработке новых, прилегающих к нему протоколов начались в 1992 году. В это время сообществу Internet были предложены несколько альтернативных варианта протокола IP нового поколения: IPv7 (разработчик - Ullman), TUBA (Callon), ENCAPS (Hinden), SIP (Deering) и PIP (Fracis). В результате развития линии ENCAPS (с промежуточной версией IPAE), SIP и PIP слились в 1993 году в предложение SIPP, которое в июле 1994 года было принято в качестве основы для создания протокола IP нового поколения, получившего формальное название IPv6, где "6" обозначает номер версии протокола (сейчас используется версия IPv4). Часто это предложение называют IPng (IP next generation), хотя иногда под IPng понимают все варианты модернизации IP, включая и те, которые не вошли в проект IPv6, но продолжают развиваться.
Документом, фиксирующим появление IPv6, является RFC 1752 "The Recommendation for the IP Next Generation Protocol". Базовый набор протоколов IPv6 был принят IETF в сентябре 1995 года и получил статус Proposed Standard.
Система адресации IPv6 существенно отличается от системы адресации IPv4.
Адреса назначения и источника в IPv6 имеют большую длину: 128 бит или 16 байт. Это дает возможность пронумеровать огромное количество узлов: 340 282 366 920 938 463 463 374 607 431 762 211 456 или примерно 1015 адресов на каждого жителя Земли. Выбранная длина IP-адреса должна надолго снять проблему дефицита IP-адресов. Кроме того, в версии IPv6 предполагается использование протокола DHCP, позволяющего разделять одни и те же адреса между большим количеством узлов сети. Использование proxy-серверов, подменяющих внутренние адреса узлов сети одним собственным IP-адресом, также направлено на снижение потребности в IP-адресах.
Однако, главной целью изменения системы адресации было не механическое увеличение разрядности адреса, а обеспечение возможности увеличения числа уровней иерархии в адресе. Вместо прежних двух уровней (номер сети и номер узла) в IPv6 предлагается использовать 5 уровней, включая двухуровневую идентификацию провайдеров, и трехуровневую - абонентов сети.
| 010 | Идентификатор провайдера | Идентификатор абонента | Идентификатор подсети | Идентификатор узла |
Предполагается также, что младшие 6 байт, которые содержат идентификатор узла, представляют собой МАС-адрес сетевого адаптера (как это уже давно делается в протоколе IPX), что обеспечит возможность автоконфигурации стека.
В версии IPv6 не вводятся классы адресов сетей, вместо этого предполагается использовать бесклассовую технологию CIDR (Classless Inter-Domain Routing). Эта технология заключается в назначении каждому провайдеру непрерывного диапазона в пространстве IP-адресов. При таком подходе все адреса сетей каждого провайдера имеют общий префикс, так что маршрутизация на магистралях Internet может осуществляться на основе префиксов, а не полных адресов всех сетей конечных абонентов. Локализация адресов позволяет уменьшить объем таблиц в маршрутизаторах всех уровней, а, следовательно, ускорить работу маршрутизаторов и повысить пропускную способность Internet. Деление IP-адреса на номер сети и номер узла в технологии CIDR происходит не на основе нескольких старших бит (класса сети А, В или С), а на основе маски переменной длины, назначаемой провайдером.
Технология CIDR уже успешно используется в текущей версии IPv4 и поддерживается такими протоколами маршрутизации как OSPF, RIP-2, BGP4. Предполагается , что эти же протоколы будут работать и с IPv6.
Идея CIDR требует, в общем случае, перенумерации сетей. Однако эта процедура сопряжена с определенными временными и материальными затратами. Например, в одной из публикаций приводятся данные о том, что для перенумерации сети, состоящей из 100 компьютеров, потребовалось 3 недели работы и 5-6 высокооплачиваемых специалистов. В качестве стимулов для проведения перенумерации сети предлагается введение платы за маршрутизации - оплата за строку маршрутизации или за обновление информации в маршрутизаторах сети, или же введение оплаты за каждый адрес узла.
Техника CIDR помогает также решить известную проблему фрагментации адресного пространства IPv4. Например, очень редко абонент использует все 254 адреса сети класса С или 65 534 адреса сети класса В. Часть адресов узлов пропадает. Требование оплаты каждого адреса узла поможет пользователю решиться на перенумерацию, с тем, чтобы получить ровно столько адресов, сколько ему нужно.
Как и в версии IPv4, в IPv6 вводится несколько типов адресов.
Синтаксически адрес anycast не отличим от адреса unicast. Схема назначения адресов состоит в следующем. Каждому порту маршрутизатора наряду с уникальным адресом присваивается еще один, общий для всех портов и маршрутизаторов данного провайдера адрес, который и является anycast-адресом.
Для обеспечения плавного перехода от версии IPv4 к версии IPv6 введен специальный тип адресов - IPv4-compatible. Такие адреса содержат нули в старших 96 разрядах, а в младшие 32 разряда помещается 4-х байтовый адрес версии IPv4. Такие адреса легко могут транслироваться в обе стороны. Это позволит на начальном этапе внедрения IPv6 решить проблему совместимости частей Internet, работающих по IPv6, с частями Internet, пока поддерживающими только версию IPv4. Для этого узлам в "островках" IPv6 будут присваиваться адреса типа IPv4-compatible. Для передачи трафика IPv6 через те части Internet, маршрутизаторы которых пока не поддерживают версию IPv6, будет использоваться техника туннелирования - пришедший пакет IPv6 будет упаковываться пограничным маршрутизатором в пакет формата IPv4, при этом в качестве адреса будет использоваться младшая часть адреса из пакета IPv6.
Главной целью изменения формата заголовка в IPv6 было снижение накладных расходов, то есть уменьшение объема служебной информации, передаваемой с каждым пакетом. Для этого в новом IP было введены понятия основного и дополнительного заголовков. Основной заголовок присутствует всегда, а дополнительные являются опциональными.
Основной заголовок имеет фиксированную длину в 40 байт и имеет следующий формат:
Поле "Следующий заголовок" (Next Header) соответствует по назначению полю Protocol в версии IPv4 и определяет тип заголовка, который следует за данным. Каждый следующий дополнительный заголовок также содержит поле Next Header. Если IP-пакет не содержит дополнительных заголовков, то в этом поле будет значение, закрепленное за протоколами TCP, UDP, RIP, OSPF или другими, определенными в стандарте IPv4.
В предложениях по IPv6 фигурируют пока следующие типы дополнительных заголовков:
Поскольку маршрутизаторы обрабатывают только основные заголовки (почти все дополнительные заголовки обрабатываются только в конечных узлах.), то это увеличивает их производительность и тем самым пропускную способность сети. Напомним, что в IPv4 все опции обрабатываются маршрутизаторами.
Наличие большого количества дополнительных необязательных параметров позволяет расширить функциональность протокола IP.
Повышение пропускной способности сети требует повышения пропускной способности всех физических каналов, в особенности магистральных, а также повышения пропускной способности маршрутизаторов, особенно магистральных.
Развитие стека TCP/IP идет в направлении снижения нагрузки на маршрутизаторы:
Многие аналитики считают, что сеть Internet сможет приспособиться к требованиям ее широкого коммерческого использования только в том случае, если она сможет предложить абонентам такое же качество обслуживания, которое сейчас является обычным для сетей frame relay, ISDN и ATM. То есть сети IP должны достаточно тонко различать классы трафика и, в зависимости от класса, гарантировать либо определенную постоянную пропускную способность (например, для голосового трафика), либо среднюю интенсивность и максимальную пульсацию трафика (например, для передачи компрессированного видеоизображения), либо предоставлять полосу пропускания не ниже определенного уровня (для пульсирующего компьютерного трафика).
При работе протокола IP поверх протоколов frame relay, ISDN или ATM, которые способны обеспечивать нужное качество обслуживания самостоятельно, протокол IP должен по крайней мере уметь принимать от абонентов запросы на то или иное качество обслуживания и транслировать их на нижние уровни.
Для поддержки качества обслуживания в протокол IPv6 введено такое понятие как "метка потока" (flow label). Метка потока - это признак, размещаемый в основном заголовке IP-пакета в поле "Метка потока", который указывает принадлежность данного пакета к последовательности пакетов - потоку, для которого требуется обеспечить определенные параметры обслуживания.
Потоки обрабатываются маршрутизаторами на основании значения метки потока и идентификатора источника, что позволяет каждому источнику локально назначать значение метки.
Для того, чтобы конечные узлы могли сообщить маршрутизаторам сети их потребности в качестве обслуживания своих потоков, необходим дополнительный протокол. В рамках сообщества Internet разработан один из таких протоколов, который получил название RSVP - Resource reSerVation Protocol, то есть протокол резервирования ресурсов. Этот протокол имеет пока статус проекта стандарта (draft) и состоит в следующем.
Узел-источник, который собирается передавать данные, требующие определенного нестандартного качества обслуживания, например постоянной полосы пропускания для передачи видеоинформации, посылает по сети по протоколу RSVP специальное сообщение. Это сообщение, называемое сообщением о пути (path message) содержит данные о том, какую информацию собирается пересылать по образуемому потоку узел-отправитель и какая пропускная способность нужна для получения ее с хорошим качеством. Сообщение о пути отправляется по определенному адресу назначения, который может быть и мультивещательным. Это сообщение передается от маршрутизатора к маршрутизатору, при этом определяется последовательность маршрутизаторов, в которых нужно зарезервировать определенную пропускную способность.
Когда узел назначения получает сообщение о пути, то он извлекает из него данные о том, какую пропускную способность он должен зарезервировать и в каких маршрутизаторах. Узлов назначения может быть и несколько, если узел-отправитель хочет начать мультивещательную сессию. На основании полученной информации каждый узел назначения отправляет по протоколу RSVP сообщение, названное recv, с помощью которого он запрашивает у сети определенную пропускную способность для определенного потока. Это сообщение передается каждому маршрутизатору на пути от узла-отправителя до узла назначения.
Маршрутизатор, который получает такое сообщение, проверяет свои ресурсы, для того, чтобы выяснить, может ли он выделить требуемую пропускную способность. Если нет, то маршрутизатор запрос отвергает. Если же да, то маршрутизатор настраивает алгоритм обработки пакетов таким образом, чтобы указанному потоку всегда предоставлялась требуемая пропускная способность, а затем передает сообщение recv следующему маршрутизатору вдоль пути.
По мере передачи сообщения с запросом о резервировании пропускной способности по направлению к узлу-источнику оно может слиться с аналогичным сообщением от другого узла назначения (если сессия мультивещательная). Слияние запросов исключает ненужное дублирование потоков. При слиянии запросов удовлетворяются потребности в максимальной пропускной способности, найденной в нескольких запросах. При этом ни один из узлов-приемников не получит обслуживания с качеством ниже того, что он запросил.
Кроме протокола RSVP, существует также проект протокола RTP (Real-Time Protocol), который должен использоваться на транспортном уровне вместо протоколов TCP и UDP, когда необходимо передавать по Internet трафик реального времени. Протокол RTP будет переносить в своем заголовке временные отметки, необходимые для успешного восстановления голоса или видеоизображения в приемном узле, а также данные о типе кодирования информации (JPEG, MPEG и т.п.).
Защита информации - ключевая проблема, которую нужно решить для превращения Internet в публичную всемирную сеть с интеграцией услуг. Без обеспечения гарантий конфиденциальности передаваемой информации бум вокруг Internet быстро утихнет, оставив ей роль поставщика интересной информации.
Сегодня защиту информации в Internet обеспечивают различные нестандартные средства и протоколы - firewall'ы корпоративных сетей и специальные прикладные протоколы, типа S/MIME, которые обеспечивают аутентификацию сторон и шифрацию передаваемых данных для какого-либо определенного прикладного протокола, в данном случае - электронной почты.
Существуют также протоколы, которые располагаются между прикладным и транспортным уровнями стека TCP/IP. Наиболее популярным протоколом такого типа является протокол SSL (Secure Socket Layer), предложенный компанией Netscape Communications, и широко используемый в серверах и браузерах службы WWW. Протоколы типа SSL могут обеспечить защиту данных для любых протоколов прикладного уровня, но недостаток их заключается в том, что приложения нужно переписывать заново, если они хотят воспользоваться средствами защиты, так как в приложения должны быть явно встроены вызовы функций протокола защиты, расположенного непосредственно под прикладным уровнем.
Проект IPv6 предлагает встроить средства защиты данных в протокол IP. Размещение средств защиты на сетевом уровне сделает их прозрачными для приложений, так как между уровнем IP и приложением всегда будет работать протокол транспортного уровня. Приложения переписывать при этом не придется.
В протоколе IPv6 предлагается реализовать два средства защиты данных. Первое средство использует дополнительный заголовок "Authentication Header" и позволяет выполнять аутентификацию конечных узлов и обеспечивать целостность передаваемых данных. Второе средство использует дополнительный заголовок "Encapsulating Security Payload" и обеспечивает целостность и конфиденциальность данных.
Разделение функций защиты на две группы вызвано практикой, применяемой во многих странах на ограничение экспорта и/или импорта средств, обеспечивающих конфиденциальность данных путем шифрации.
Каждое из имеющихся двух средств защиты данных может использоваться как самостоятельно, так и одновременно с другим.
В проектах протоколов защиты данных для IPv6 нет привязки к определенным алгоритмам аутентификации или шифрации данных. Методы аутентификации, типы ключей (симметричные или несимметричные, то есть пара "закрытый-открытый"), алгоритмы распределения ключей и алгоритмы шифрации могут использоваться любые. Параметры, которые определяют используемые алгоритмы защиты данных, описываются специальным полем Security Parameters Index, которое имеется как в заголовке "Authentication Header", так и в заголовке "Encapsulating Security Payload".
Тем не менее, для обеспечения совместимой работы оборудования и программного обеспечения на начальной стадии реализации протокола IPv6 предложено использовать для аутентификации и целостности широко распространенный алгоритм хэш-функции MD5 с секретным ключом, а для шифрации сообщений - алгоритм DES.
Протокол обеспечения конфиденциальности, основанный на заголовке "Encapsulating Security Payload", может использоваться в трех различных схемах.
В первой схеме шифрацию и дешифрацию выполняют конечные узлы. Поэтому заголовок пакета IPv6 остается незашифрованным, так как его содержимое нужно маршрутизаторам для выполнения своей работы.
Во второй схеме шифрацию и дешифрацию выполняют пограничные маршрутизаторы, которые отделяют частные сети предприятия от публичной сети Internet. Эти маршрутизаторы полностью зашифровывают пакеты IPv6, получаемые от конечных узлов в исходном виде, в затем инкапсулируют (эта операция и дала название заголовку - Encapsulating) зашифрованный пакет в новый пакет, который они посылают от своего имени. Информация, находящаяся в заголовке "Encapsulating Security Payload", помогает маршрутизатору-получателю извлечь зашифрованный пакет, расшифровать его и направить узлу-получателю.
В третьей схеме один из узлов самостоятельно выполняет операции шифрации-дешифрации, а второй узел полагается на услуги маршрутизатора-посредника.
Переход от версии IPv4 к версии IPv6 только начинается. Сегодня существуют фрагменты Internet, в которых маршрутизаторы поддерживают обе версии протокола. Эти фрагменты объединены между собой, образуя так называемую 6-магистраль (6Bone). В своей работе магистраль 6Bone использует технику инкапсуляции пакетов IPv6 при транзитной передаче через те части Internet, где протокол IPv6 еще не поддерживается.
Многие производители операционных систем и маршрутизаторов уже выполнили реализацию протокола IPv6 для своих продуктов. Список продуктов, поддерживающих IPv6, включает операционные системы 4.4-lite BSD, BSDI/OS, Digital UNIX, WIN95, DOS, Windows, HP-UX, Linux, NetBSD, Novell, SCO Unix, Solaris, и маршрутизаторы компаний 3com, Bay Networks, cisco Systems, Telebit, Penril и Ipsilon.