В сетевой отрасли, как и в компьютерной индустрии в целом, основанные на очевидных тенденциях развития прогнозы очень часто не оправдывались, во всяком случае они сбывались лишь в весьма ограниченной мере.

В середине 80-х годов многие считали, что сетевая модель TCP/IP опирается на хаотические принципы и что место TCP/IP неизбежно займут сети OSI. Более того, в США правительственным учреждениям даже предписывалось переходить на сети OSI. Однако оказалось, что, несмотря на красоту и логичность построения архитектуры, сети OSI обладают чрезмерной избыточностью и, как следствие, низкой эффективностью. Поэтому-то, спустя некоторое время, проект вынуждены были свернуть.

Аналогичный казус в начале 90-х годов произошел с сетями ATM, когда казалось, что, благодаря представлению гарантированного качества услуг и высокой пропускной способности, технологии ATM удастся в течение ближайших нескольких лет вытеснить всех остальных конкурентов. Но революции так и не получилось — ATM получила распространение только на уровне магистрали.

Когда несколько лет назад я только начинал заниматься сетевыми технологиями, мне неоднократно попадались прогнозы, что к середине 90-х годов все свободные IP-адреса в текущей версии IPv4 неизбежно должны закончиться и мир вынужден будет перейти к новой версии протокола IP с расширенной адресацией. Как и всякий новичок, я верил прогнозам, тем более что они основывались на очевидных фактах. Поэтому уже в те годы я пытался разобраться в спецификации новой версии IPv6, в том числе по публикуемым документам RFC. Правда, меня несколько удивляло, почему производители программно-аппаратного обеспечения не спешат переходить к IPv6.

В дальнейшем момент перехода на IPv6 был перенесен на конец 90-х годов, а сейчас речь уже ведется о 2001—2003 гг. Однако теперь меня никто и ничто не убедит, что IPv6 будет реализован в широком масштабе в ближайшие 10 лет. Как говорится, пессимист — это информированный оптимист.

Действительно, разработчики четвертой версии IP оказались не слишком прозорливыми, когда выделили для адресации только 32 разряда. Интересно, что разработчики появившегося раньше и, в отличие от IP, предназначенного исключительно для локальных сетей протокола Ethernet оказались гораздо мудрее и выделили под адресное пространство 48 разрядов.

Кроме того, особого восторга не вызывает и принятая в IPv4 схема разделения на классы, когда самому широко используемому классу C выделена только 1/8 часть общего адресного пространства IP!

Казалось бы, в связи с бурным развитием Internet, когда в Сети каждые несколько секунд появляется новый хост, у IPv6 есть все шансы быстро вытеснить IPv4. Вдобавок, развитие новых технологий, в частности передачи мультимедиа, голоса и видео, внедрение электронной торговли ставят на повестку проблемы обеспечения безопасности и управления качеством услуг, в результате чего привлекательность IPv6 еще более возрастает.

Но почему же прогнозы относительно даты перехода на новый протокол никак не сбываются? Все очень просто! Проблемы с адресным пространством IPv4 не так уж серьезны, как это представлялось прежде. Вернее, разработанные за последние годы методы борьбы с нехваткой адресного пространства резко снизили актуальность проблемы. Прежде всего, это концепция подсетей (subnet), введение которой позволило оптимизировать использование адресов в сетях классов A и B (и даже C).

Вторым важным шагом можно назвать внедрение бесклассовой междоменной маршрутизации (Classless Inter-Domain Routing, CIDR), предусматривающей отказ от деления на классы за счет группирования префиксов сетевых адресов. Такой подход позволил не только успешно бороться с нерациональным использованием адресов, но и серьезно увеличить производительность магистральных маршрутизаторов — этой ахиллесовой пяты Internet.

Весьма своевременным оказалась и разработка протокола динамической конфигурации хостов (Dynamic Host Configuration Protocol, DHCP), с помощью которого IP-адреса могут назначаться динамически. Поскольку значительная часть подключений к Internet осуществляется по коммутируемым линиям связи (dial-up), то применение DHCP провайдерами Internet дает возможность ограничить число используемых IP-адресов количеством коммутируемых линий связи, находящихся в распоряжении провайдеров, а не выделять каждому пользователю отдельный IP-адрес.

Но самым кардинальным методом борьбы с нехваткой адресов оказалась технология трансляции сетевых адресов (Network Address Translation, NAT). В соответствии с ней, находящиеся внутри локальной или корпоративной сети хосты могут иметь незарегистрированные IP-адреса. Общение же компьютеров с внешним миром осуществляется посредством трансляции внутренних адресов во внешние, закрепленные за внешним интерфейсом шлюза NAT. Фактически, при грамотной политике InterNIC применение NAT может закрыть проблему нехватки IP-адресов на долгие годы, поскольку даже очень крупной корпорации будет достаточно иметь всего несколько зарегистрированных IP-адресов (заметьте, IP-адресов, а не IP-сетей). Между прочим, шлюзы NAT подходят не только для рядовых организаций, но и для провайдеров, правда, последние не горят желанием их устанавливать. Что же касается проблем снижения производительности при трансляции IP-адресов, то, учитывая не слишком высокую пропускную способность глобальных линий связи (даже магистральных), данную проблему в большинстве случаев трудно назвать основной.

Шлюзы NAT позволяют не только добиться резкого уменьшения количества необходимых зарегистрированных IP-адресов, но также контролировать и фильтровать информацию, передаваемую между локальной сетью и Internet, тем самым выступая в качестве межсетевого экрана (firewall).

Вместе с тем, очевидно, что технологии CIDR, DHCP и NAT лишь оттягивают кончину IPv4: рано или поздно ему придется уступить место новому протоколу (и это совсем не обязательно будет IPv6), но не менее важно понять, почему с таким трудом пробивает себе дорогу IPv6.

Читая спецификацию IPv6, невольно ловишь себя на мысли, что разработчики попытались внести в протокол все мыслимые и немыслимые возможности с тем, чтобы обезопасить себя на многие десятилетия вперед.

Основные характеристики IPv6 не могут не вызывать восхищения.

1. Адресное пространство увеличено до 128 разрядов. Чтобы наглядно представить себе эту огромную величину, достаточно сказать, что этого количества адресов хватит, чтобы каждый житель планеты владел сетью, соизмеримой с нынешней Internet.

2. Гибкий формат заголовков дейтаграмм IP позволяет маршрутизаторам обрабатывать их намного быстрее.

3. Встроенная поддержка резервирования ресурсов, в частности гарантированного обеспечения качества услуг QoS.

4. Встроенная поддержка протокола шифрования IPSec.

5. Устранение избыточной информации из заголовков дейтаграмм IP.

6. Новые опции в заголовках дейтаграмм IP.

7. Расширяемость протокола без пересмотра стандарта.

8. Гибкое распределение адресного пространства на классы, включая поддержку записи MAC-адресов в IP-адреса. Один из классов выделен для унаследованных адресов IPv4. Адресное пространство IPv6 позволяет создавать многоуровневые схемы адресации.

9. Наличие трех типов адресации: unicast, multicast и cluster (anycast). Первые два типа имеются и в IPv4, новым является лишь тип cluster. В этом случае сообщения посылаются не всем членам группы, а только одному (ближайшему).

Красиво, не правда ли?! В чем же тогда загвоздка? А все дело в проблемах совместимости и интероперабельности протоколов IPv4 и IPv6.

Даже активным сторонникам IPv6 очевидно, что невозможно в один миг перейти на новый протокол: IPv4 и IPv6 придется сосуществовать вместе длительное время. Но и это не снимает остроту проблемы. Переход на IPv6 потребует колоссальных расходов, по сравнению с которыми затраты на решение проблемы 2000 года покажутся цветочками, поскольку миграция затронет все существующее сетевое программное и отчасти аппаратное обеспечение.

Что же касается гарантированного качества услуг QoS и шифрования информации, то протоколы RSVP и IPSec работают не только в IPv6, но и в IPv4.

Сейчас предложены две схемы реализации миграции от IPv4 к IPv6: двойной стек и туннелирование.

Согласно схеме двойного стека на каждом сетевом узле должен быть установлен стек как IPv4, так и IPv6. При таком варианте обновлять придется (пусть постепенно) все сетевое программное обеспечение, поскольку сейчас оно ориентировано исключительно на IPv4. Не стоит надеяться, что для этого достаточно просто увеличить количество байтов, выделенных под IP-адреса. Службы DNS, FTP, NIS, NFS, X11, система доверительных отношений и т. д. слишком привязаны к IPv4, чтобы можно было обойтись простой перекомпиляцией приложений.

В соответствии со схемой туннелирования дейтаграммы IPv6 инкапсулируются в пакеты IPv4 и могут передаваться по старым соединениям. При этом шлюзы, на которых производится туннелирование, должны понимать как протокол IPv4, так и IPv6.

Очевидно, что одновременное применение обеих версий протокола лишь усложняет систему адресации, а совместное функционирование IPv4 и IPv6 серьезно увеличивает нагрузку на магистральные маршрутизаторы. Тем не менее внедрение IPv6 нужно начинать не с рабочих мест, а с магистралей.

Мне кажется, что политика InterNIC и IETF должна быть направлена на то, чтобы максимально оттянуть время перехода на IPv6 и смягчить его последствия.

Разрешите высказать на первый взгляд крамольную идею, как можно достаточно просто решить проблему нехватки адресов в IPv4 в ближайшей перспективе. Для этого InterNIC следует ввести плату за использование IP-адресов по той же схеме, как это принято при регистрации доменов второго уровня. Тогда число случаев, когда организации резервируют IP-адреса, что называется, про запас, значительно уменьшится.

Пользователям пора наконец понять, что затраты на переход к новой версии IP будут столь огромны, что гораздо дешевле раскошелиться на регистрацию адресов в IPv4 или установить шлюзы NAT, чтобы более рационально использовать оставшееся свободное адресное пространство IP.