Переход с IPv4 на IPv6
Теперь, когда мы обсудили технические детали протокола IPv6, рассмотрим довольно практический вопрос: как перевести на IPv6 Интернет, функционирующий по протоколу IPv4? Проблема заключается в том, что, хотя новые IPv4-системы можно сделать обратно совместимыми, то есть реализовать в них поддержку дейтаграмм старого формата, уже работающие IPv4-системы не смогут обрабатывать IPv4-дейтаграммы. Решений может быть несколько.
Одним из решений могло бы стать объявление о некой дате перехода с IPv4 на IPv6. Последняя подобная глобальная смена технологий (переход с протокола NCP на TCP для предоставления надежной транспортной службы) произошла почти 20 лет назад (RFC 801). Однако уже довольно давно, еще когда Интернет был крошечный и управлялся небольшим количеством «волшебников», стало ясно, что подобный «день икс» невозможен. Сегодня такая операция затронула бы сотни миллионов машин и миллионы сетевых администраторов и пользователей. В RFC 2893 описываются два подхода (которые можно использовать вместе или по отдельности) постепенного ввода IPv6-xoctob в «мир» IPv4 (с долгосрочной целью, разумеется, полного перехода IPv4-узлов на протокол IPv6).
Вероятно, наиболее простой способ внедрить в Интернет узлы, поддерживающие протокол IPv6, представляет собой метод двойного стека, при котором IPv4-узлы обладают полной поддержкой протокола IPv4. Некоторые узлы, называемые в RFC 2893 IPv6/IPv4-узлами, обладают способностью принимать и посылать как IPv4-дейтаграммы, так и IPve-дейтаграммы. Взаимодействуя с IPv4-узлом, IPv6/ IPv4-узел может использовать IPv4-дейтаграммы; взаимодействуя с IPv4-узлом, он может использовать IPv4-дейтаграммы. У IPv6/IPv4-узла должен быть как IPv4-адрес, так и IPv4-адрес. Кроме того, они должны уметь определять, поддерживает ли другой узел протокол IPv6 или только IPv4. Эта проблема может быть разрешена с помощью DNS-сервера, возвращающего IPv4-адрес узла, если данный узел поддерживает протокол IPv6, или IPv4-адрес узла в противном случае. Разумеется, если узел, выдающий DNS-запрос, сам поддерживает только протокол IPv4, DNS-сервер возвращает только IPv4-адрес.
При таком подходе, если либо отправитель, либо получатель поддерживает только протокол IPv4, должна быть использована IPv4-дейтаграмма. В результате возможна ситуация, когда два узла, поддерживающие протокол IPv6, обмениваются дейтаграммами в формате IPv4. Эту ситуацию иллюстрирует рис. 4.40. Предположим, что узел А, поддерживающий протокол IPv6, хочет переслать IP-дейтаграмму узлу F, который также обеспечивает поддержку протокола IPv6. То есть узлы А и В могут обмениваться дейтаграммами формата IPv6, но чтобы переслать дейтаграмму узлу С, узел В должен создать IPv4-дейтаграмму. Разумеется, поле данных IPv4-дейтаграммы копируется в поле данных IPv4-дейтаграммы, также выполняется соответствующее преобразование адресов. Однако некоторые поля протокола IPv6 (например, поле идентификатора потока) не имеют соответствий в IPv4-дейтаграммах. В результате при подобном преобразовании хранящаяся в этих полях информация теряется. Таким образом, хотя узлы Е и F могут обмениваться дейтаграммами формата IPv6, переданная узлу Е узлом D IPv4-дейтаграмма не содержит всех полей, которые были в оригинальной дейтаграмме, полученной от узла А.
Альтернативный метод, также обсуждаемый в RFC 2893, называется туннелированием. Путем туннелирования можно решить упомянутую выше проблему, то есть узел Е сможет принять отправленную узлом А IPv4-дейтаграмму в исходном виде. В основе туннелирования лежит следующая идея. Предположим, два IPv4-узла (например, узлы В и Е на рис. 4.40) хотят обменяться IPve-дейтаграммами, но их разделяют IPv4-маршрутизаторы. Промежуточные IPv4-маршрутизаторы мы будем называть туннелем, как показано на рис. 4.41. Метод туннелирования заключается в том, что передающий IPv4-узел (например, узел В) помещает IPv4-дейтаграмму целиком в поле данных дейтаграммы формата IPv4. Затем эта IPv4-дейтаграмма, адресованная получающему IPv4-узлу на другой стороне туннеля (например, узлу Е), передается первому узлу туннеля (например, узлу С). Промежуточные IPv4-маршрутизаторы передают эту дейтаграмму друг другу, как обычную дейтаграмму, не зная о том, что она содержит полную дейтаграмму формата IPv6.
Наконец, принимающий IPv6-узел на другой стороне туннеля получает IPv4-дейта-грамму, определяет, что она содержит дейтаграмму формата IPv6, извлекает IPv6-дейтаграмму и переправляет ее дальше, как если бы он получил ее по сети от непосредственного соседа.
В завершение этого раздела отметим, что процесс перехода на протокол IPv6 пока что продвигается не слишком быстрыми темпами. Вспомним, что основным мотивом разработки протокола IPv6 было истощение адресного пространства протокола IPv4. Однако, как отмечалось в разделе «Интернет-протокол», протоколу IPv4 удалось значительно «продлить жизнь» с помощью таких методов, как бесклассовая внутридоменная маршрутизация (позволяет использовать сетевую часть адреса любой длины), динамическое выделение адреса протоколом DHCP, трансляция сетевых адресов (позволяет к 32 бит IP-адресов добавить 16 бит номера порта). Однако возможно, что широкое распространение мобильных телефонов и других портативных устройств может привести к тому, что адресного пространства протокола IPv4 снова станет недостаточно. Компания Ericsson планирует выпуск телефонов с поддержкой протокола IPv6 в 2002 г., а Европейская программа партнерства третьего поколения (Third Generation Partnership Program, 3GPP) специфицировала протокол IPv6 как стандартную схему адресации для мобильных мультимедийных устройств. Хотя за первые семь лет своего существования протокол IPv6 не получил широкого распространения, без всякого сомнения, у него большие перспективы. Подобно тому как потребовалось несколько десятков лет, чтобы сформировалась современная система телефонных номеров (она используется уже почти полвека и, похоже, уходить не собирается), для широкого распространения протокола IPv6 может потребоваться некоторое время, но затем он будет применяться в течение долгого срока. Брайан Карпентер, бывший председатель совета по архитектуре Интернета (Internet Architecture Board, IAB), а также автор нескольких документов RFC, относящихся к протоколу IPv6, говорит: «Я всегда рассматривал это как 15-летний процесс, начавшийся в 1995 году». Если верить Крапен-теру, мы еще лишь на полпути!
Один важный урок, который мы должны усвоить из знакомства с протоколом IPv6, состоит в том, что сменить сетевой протокол крайне сложно. С начала 90-х годов множество новых сетевых протоколов провозглашались следующим революционным прорывом в Интернете, но большая часть их просуществовала очень недолго. К этим протоколам относятся IPv6, протоколы групповой рассылки (см. раздел «Групповая маршрутизация»), а также протоколы резервирования ресурсов . В самом деле, введение нового протокола в сетевой уровень подобно замене фундамента у здания — это сложно сделать, не развалив весь дом или, по меньшей мере, не переселив временно его жильцов. С другой стороны, Интернет был свидетелем быстрого развертывания новых протоколов прикладного уровня. Классическими примерами являются web, передача сообщений в реальном времени, коллективное использование файлов одноранговыми (равноправными) узлами. К другим примерам относятся передача потокового аудио и видео, чат. Внедрение новых протоколов прикладного уровня подобно перекраске здания — это относительно легко сделать, и, если вы выберете привлекательный цвет, соседи быстро сделают то же самое. Итак, в будущем мы можем ожидать изменений на сетевом уровне стека протоколов Интернета, но эти изменения, скорее всего, будут происходить значительно медленнее изменений на прикладном уровне.