Grundik's lair

Наверняка многие из вас наслышаны о существовании этого протокола. А некоторые наверное даже его используют. А частенько от его поддержки хотят даже избавиться (когда поддержка IPv6 со стороны ОС есть, но при этом нет ни одного глобального адреса, то естественно что оно не работает и иногда даже мешает работать остальному), хотя более адекватно было бы воспользоваться ее преимеществами. А я хочу составить краткий обзор о том, что же это такое, как им пользоваться и что это дает.

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

Что же это такое, IPv6?

Протокол IP набрал огромную популярность, и естественно в нем выявились некоторые недостатки. Часть из них оказалось возможно поправить используя зарезервированные поля и иные механизмы расширения (например так появились QoS, IPSec, CIDR, олдфаги смогут вспомнить еще), и казалось бы все прекрастно работает и трогать ничего не надо. Но в последнее время все более заметным становится один недостаток, который по началу был совершенно не актуальным. Да, это количество доступных адресов.

Как многие знают, в IPv4 для адресации используется 32 бита, что позволяет задавать до ~4 миллиардов адресов. Теоретически. Практически же значительные диапазоны зарезервированы под служебные нужды. А развитие сети шагает вперед и вперед. На данный момент осталось свободно примерно 30 (UPD: прошло несколько месяцев, и их осталось уже 24 UPD2: уже не осталось ни одной сети, все уже распределены, глобально свободных сетей больше не осталось.) сетей вида NNN.*.*.* (Или, как принято такое обозначать, /8 — первые 8 бит обозначают подсеть, остальные адрес внутри нее). Так что адреса неминуемо закончатся.

Для решения этой проблемы есть два подхода:

• Использование NAT (Network Address Translation): без него адреса закончились бы уже много лет назад. Суть заключается в том, что один адрес делится между несколькими пользователями (иногда даже между несколькими сотнями, а то и тысячами пользователей). Ныне используется повсеместно. Метод хороший, но имеет существенный недостаток: пользователи такого „общественного“ адреса не могут принимать входящие подключения, что не только исключает возможность предоставления собственных сервисов, но и накладывает некоторые ограничения на использование чужих. Не говоря уже о том, что приходится мириться с сосуществованием: например многие сервисы (например рапидшара и ее аналоги) ограничивают число одновременных подключений с одного адреса, и не всегда можно воспользоваться таким сервисом из-за другого пользователя, который успел сделать это раньше.
• Эволюция протокола. Еще в далеком 1992м году было предложено развитие протокола IP, которое в 1996м развилось до стандарта IPv6. С тех пор этот протокол развивался, и в настоящее время (и уже много лет как) вполне работоспособен на просторах интернета. О нем и пойдет речь далее.

Сравнение с IPv4

   (12) In protocol design, perfection has been reached not when there
           is nothing left to add, but when there is nothing left to take
           away.
                                                              RFC 1925

С бытовой точки зрения заметно расширение диапазона адресов, с 32 бит до 128. Также будет заметно появившееся автоопределение адресов. Собственно больше конечный пользователь врядли увидит, и это нормально — нечего голову забивать. Кому не интересны подробности — переходите сразу к использованию. Пара-тройка операций и все будет работать.

Оценить масштаб увеличения адресного пространства на самом деле довольно сложно — получившееся число астрономическое. Как указано в википедии: «Если бы земля состояла из песчинок в кубический миллиметр каждая, то доступных IPv6 адресов хватило бы, чтобы присвоить уникальный адрес каждой песчинке на 300 миллионах планет размером с Землю». Но тут есть некоторые нюансы:

• невозможно выделить 100% адресов — таблицы маршрутизации и так огромны, адреса выделяются подсетями (пулами), а использовать на 100% все пулы не реально, где-нибудь да останутся неиспользуемые адреса. Однако выделить их произвольному абоненту невозможно. Это можно сравнить с телефонными номерами — если у вашей АТС не осталось свободных номеров, то вы подключиться не сможете, даже если на соседней АТС номера еще остались;
• текущий план распределения предполагает выделение конечным абонентам сетей /48, в отличии от еденичных адресов, как это было в IPv4 — что соответственно уменьшает доступный пул адресов до 2⁴⁸ (если продолжить аналогию с песчинками, то это уже большой пляж, 60 км в длину, 30 м в ширину и 30 см глубиной). Причем уже сейчас нельзя уменьшить выделяемую подсеть до размера меньше чем /64 — спецификации автоматической генерации адресов завязаны на такой диапазон;
• также текущий план распределения предусматривает довольно разреженное выделение, например допускается выделение провайдерам следующего по размеру диапазона (в 2 раза больше адресов) уже при 10% использования текущего;
• примерно 85% адресного пространства зарезервировано (пространство для маневра на случай, если текущая система распределения окажется неудачной) — сейчас под глобальные адреса выделена подсеть 2000::/3 (в двоичной системе исчисления адреса вида 001xxx…xxx).

Т.е. фактически текущий диапазон, в котором выделяются глобальные IPv6 адреса, в 8 тысяч раз превышает полный диапазон адресов IPv4. Таким образом прогнозируется, что при этой схеме адресов хватит на 50-100 лет, а там якобы будет видно, и можно будет распечатать зарезервированные запасы. Также, уплотнив эту схему, число выделенных адресов можно увеличить примерно в 10-50 раз. Пока повода так ужиматься нет, и предпочли простоту и удобство плотности.

Но углубимся чуть дальше. В IPv4 одному сетевому интерфейсу обычно соответствует один адрес. В IPv6 это не так (в IPv4, кстати, возможность иметь несколько адресов на одном интерфейсе — это одна из фич пришедшая из IPv6). Для IPv4 это приятное дополнение, а в IPv6 это sine qua non. Причина этого — разные адреса имеют разную „область видимости“.

В IPv6 есть такие „служебные“ диапазоны (не буду в очередной раз рассказывать об способе записи адресов, кому интересно — можете почитать в вики, а остальные могут пропустить этот раздел):

• ::/128 (адрес из одних нулей) — несуществующий, используется только в ПО (аналог 0.0.0.0).
• ::1/128 — аналог 127.0.0.1
• fc00::/7 — „уникальные локальные адреса“, некоторый аналог 192.168.x.x и подобных диапазонов. Генерируются автоматически для каждого интерфейса с помощью специального алгоритма, который дает с большой долей вероятности уникальный адрес. Часто используется устаревший аналог этого диапазона, fec0::/10. Как следствие автоматичности, локальная сеть на IPv6 будет работать сразу, без дополнительных настроек.
• ff00::/8 — мультикаст адреса. В IPv6 нет бродкаст адресов, все реализуется через мультикаст. Поэтому некоторые мультикаст диапазоны зарезервированы под определенное использование. Например мультикаст адрес ff02::1 это аналог бродкаста, если его пингануть то должны ответить все хосты, поддерживающие IPv6 (естественно в пределах сегмента). И ответят они со своих локальных адресов.
• ::ffff:0:0/96 — IPv4-совместимые адреса. Используются только в ПО, например для указания слушающему сокету, чтобы он принимал IPv4 соединения или чтобы показать что полученное соединение было по IPv4. Также используется устаревший диапазон ::0:0/96 с такой же целью. В обоих типах в младших 32 битах вписывается IPv4 адрес. Благодаря такому в программе, использующей входящие IPv6 соединения, IPv4 будет тоже работать, причем автоматически.
• 2000::/3 — глобальные адреса, именно в этом диапазоне они в настоящее время выделяются. Можно выделить следующие поддиапазоны:
  • 2001::/32 — Teredo адреса.
  • 2002::/16 — 6-to-4 адреса (о последних двух типах ниже).

Таким образом у IPv6 интерфейса обычно 2 адреса — автоматический локальный и глобальный. Глобальный тоже может автоматически определяться (с помощью мультикаст-запроса определяется роутер, который говорит подсеть, в которой и сгенерируется адрес, см. далее про  Router Advertising). Также, т.к. не всегда понятно к какому интерфейсу относится адрес, интерфейс иногда указывают после адреса через знак «%». Например команда «ping6 ff02::1%eth0» отправит запрос в мультикаст группу «все узлы» в сеть, к которой подключен интерфейс eth0. Без подобного уточнения команда либо не будет работать вообще или может выбрать не тот интерфейс, который бы хотелось вам. В винде интерфейсы просто нумеруются и такое тоже работает.

Углубимся еще сильнее. С низкоуровневой точки зрения заголовок упростился: из него были изъяты поля «размер» — он теперь фиксированного размера и «контрольная сумма» — ее больше нет в IP пакете, т.к. более высокоуровневые протоколы (например TCP, UDP) ведут свои контрольные суммы, низкоуровневые (например ethernet) свои. Смысла в еще одной контрольной сумме нет, поэтому ее изъяли. Поэтому маршрутизаторам не нужно анализировать пакет на предмет вычисления длины заголовка или пересчитывать контрольную сумму при изменении TTL пакета.

                                 IPv4                                                                IPv6
   ┌───────┬───────┬───────────────┬───────────────────────────────┐   ┌───────┬───────────────┬───────────────────────────────────────┐
   │Version│  IHL  │Type of Service│          Total Length         │   │Version│ Traffic Class │           Flow Label                  │
   ├───────┴───────┴───────────────┼─────┬─────────────────────────┤   ├───────┴───────────────┴───────┬───────────────┬───────────────┤
   │         Identification        │Flags│      Fragment Offset    │   │         Payload Length        │  Next Header  │   Hop Limit   │
   ├───────────────┬───────────────┼─────┴─────────────────────────┤   ├───────────────────────────────┴───────────────┴───────────────┤
   │  Time to Live │    Protocol   │         Header Checksum       │   │                                                               │ 
   ├───────────────┴───────────────┴───────────────────────────────┤   │                         Source Address                        │ 
   │                       Source Address                          │   │                                                               │
   ├───────────────────────────────────────────────────────────────┤   ├───────────────────────────────────────────────────────────────┤ 
   │                    Destination Address                        │   │                                                               │
   ├───────────────────────────────────────────────┬───────────────┤   │                      Destination Address                      │ 
   │                    Options                    │    Padding    │   │                                                               │ 
   └───────────────────────────────────────────────┴───────────────┘   └───────────────────────────────────────────────────────────────┘

Поле «протокол» изменилось на «следующий заголовок». С одной стороны это чисто синтаксическое изменение (в него записывается тип следующего заголовка, т.е. для TCP пакетов в этом поле будет стоять 6. Значения этих полей совместимы), но с другой именно с помощью этого поля теперь добавляются расширения вместо использования заголовка нефиксированной длины.

Также переименовалось поле «TTL», теперь оно называется «Hop Limit». Функционально изменилось лишь то, что для IPv4 роутер должен был уменьшать значение TTL на 1 за каждую секунду удержания пакета в очереди. Для IPv6 такое не требуется, что также упрощает обработку.

IPv6 не поддерживает фрагментацию пакетов, и опять вздох облегчения у маршрутизаторов. Строго говоря возможность фрагментировать пакеты есть, но, в отличии от IPv4, она может производиться только изначальным отправителем пакета, маршрутизаторы пакеты не фрагментируют. При этом есть возможность использования гигантских пакетов (Jumbogram, до 4 Гб). Правда практическое применение этой возможности не велико — фрагментации то толком нет.

Эта особенность иногда приводит к проблемам — для эффективности передачи пакеты должны быть максимально большими, а алгоритм определения максимального возможного размера пакета (PMTU Discovery) базируется на том, что маршрутизатор, который не может отправить пакет дальше из-за его размера, отсылает отправителю ICMP пакет «Packet too big», на что отправитель соответственно реагирует — переходит на использование пакетов меньшего размера. Однако если где-то по пути стоит параноидальный фильтр, не пропускающий такие пакеты, то система не работает: отправка пакета повторяется снова и снова, но он как отбрасывался этим маршрутизатором, так и продолжает отбрасываться. В конце концов соединение рвется. Теоретически реализация стека протокола могла бы при ретрансмиссиях уменьшать размер пакета, чтобы автоматически обходить эту проблему, но пока так не делается.

Не смотря на то что де-факто максимальный размер пакета (MTU) практически всегда 1500 байт (здесь и далее 1 байт = 1 октет), по пути могут встречаться прозрачные туннели, для прохождения через которые пакеты инкапсулируются в другие пакеты, что естественно увеличивает их размер. И если такой туннель есть — изначальный пакет в 1500 байт через него уже не пролезет, его необходимо уменьшить. А если при этом еще и блокируются ICMP пакеты, то все, финита.

В моей практике я с такими проблемами при обычном использовании не сталкивался — возможно или везло или на данный момент таких параноидальных фильтров в сети почти не осталось. Но если возникают странные проблемы, когда соединение устанавливается и зависает, то это скорее всего эта ситуация и есть. Для решения подобных проблем предлагается следующий подход: поставить MTU интерфейса на ~100 байт меньше, в 1400. Или, менее радикально, воспользоваться ip6tables таргетом TCPMSS с той же целью. Первый вариант подействует на все пакеты, второй — только на TCP. Для абсолютной гарантии MTU можно уменьшить до минимально возможного — 1280, но с моей точки зрения это уже перебор.

Но такое возникало при использовании IPSec: реализация IPSec в линуксе страдает тем, что PMTU Discovery в ней не работает, но это тема для отдельного разговора. Поэтому как минимум для IPSec пакетов такими обходными путями воспользоваться придется, причем в обязательном порядке.

Возвращаясь к отличиям IPv6 от IPv4: в целом заголовок вырос до 40 байт, против 20+ у IPv4, также выросло требование к минимальному MTU до 1280 байт. Но число полей в заголовке уменьшилось с 12 до 8. Если учесть что длина полей адресов выросла с 32 до 128 бит, т.е. в 4 раза, оверхед увеличился вполне терпимо.

Интересная особенность — в IPv6 не используется ARP для определения MAC-адресов соседей. Вместо него используется протокол Neighbor Discovery, заслуживающий отдельного разговора. В данном случае главное отличие заключается в том, что используются мультикаст запросы вместо бродкаст, что снижает нагрузку на сеть и невинные машины в ней.

Как воспользоваться IPv6?

Есть много методов. Расскажу о них в порядке „кошерности“, но если вы простой пользователь — переходите сразу к последнему пункту, про Teredo :)

• Нативный IPv6. Самый родной и близкий к телу.
  • Плюсы: если он есть, то обычно получается автоматически (см. ниже).
  • Минусы: К сожалению на данный момент нативный IPv6 ни один известный мне провайдер в России не предоставляет. Более того нативный IPv6 в России похоже вообще почти отсутствует, хотя на точке обмена трафиком MSK-IX есть и IPv6 обмен. Так что будет работать только для хостов в вашей локалке при комбинации с другими методами, о которых дальше.
  • Настройка:
    • Статически. Самый элементарный способ. Вписываете в настройках интерфейса и вуаля.
      • Плюсы: ничего ставить не надо, вписал и все.
      • Минусы: нужно иметь этот статический адрес, вручную его вписывать и настраивать роутинг.
    • Router Advertising, одна из возможностей протокола Neighbor Discovery. Тоже простой способ. Чем-то похоже на DHCP, но проще и быстрее. От клиента (получателя адреса) не требуется вообще ничего (получение адреса таким образом входит в стандарный алгоритм автоопределения адреса). На сервере требуется соответствующий демон — radvd.
      • Плюсы: поставил такой демон на маршрутизатор, и все машины с поддержкой IPv6 в локалке автоматом будут получать IPv6 адреса.
      • Минусы: адреса могут быть динамическими (хотя с какой-то точки зрения это и плюс), т.е. могут генерироваться различными от соединения к соединению. Однако в большинстве реализаций адреса будут по возможности выбираться одинаковыми каждый раз (на основе MAC-адреса сетевой карты). Требуется аж /64 подсеть (хотя для IPv6 это не проблема).
    • DHCPv6: развитие старого доброго DHCP
      • Плюсы: адреса можно сделать статическими, не требуется настройка на клиентских машинах.
      • Минусы: но нужно настраивать сервер, и также требуется пул адресов. Более того, далеко не все DHCP серверы знают о DHCPv6, т.к. это несколько другой протокол. Например популярный демон от ISC только в 4й версии научился. Да и DHCP клиент не всякий такое осилит.
    • Не забываем настраивать маршрутизацию на роутере в свою сеть: /sbin/route -6 add <сеть>::/<маска> eth0
• Туннель до нативной IPv6 сети. Берется IPv6-провайдер, с ним заключается соглашение и вы получаете в свое распоряжение некоторую подсеть. Поднимаете туннель до сервера этого провайдера, настраиваете роутинг и вуаля — у вас есть своя нативная IPv6 сеть, адреса из которой вы можете распределять как описано выше.
  • Плюсы: своя нативная подсеть.
  • Минусы: нужно регистрироваться и настраивать.
  • Настройка:
    • Провайдеры, даже предоставляющие бесплатные, но адекватные услуги есть. К сожалению не в России (как уже говорил в России с нативным IPv6 пока глухо). Самый популярный наверное SixXs. У них на сайте все расписано: нужно зарегистрироваться и запросить подсеть. Оплата производится своеобразными баллами, зарабатываются которые путем поддержания туннеля работоспособным. Также туннели дает Hurricane Electric, с ним все проще, и никаких баллов не надо.
    • Туннели обычно поднимаются с помощью программки AICCU (Automatic IPv6 Connectivity Client Utility), она есть под многие популярные операционки, даже есть в репозиториях дебиана. Имеет и GUI версию. Hurricane Electric дает прямые туннели, никаких программ не надо, однако необходим внешний IPv4 адрес. И желательно статичный, иначе придется переконфигурировать туннель каждый раз при смене IP.

• 6-to-4 туннель. Если у вас есть статический внешний IPv4 адрес — вам повезло, у вас уже есть IPv6 подсеть вида 2002:aabb:ccdd::/48, где aabb:ccdd это ваш IPv4 адрес aa.bb.cc.dd (в пересчете на десятичную систему исчисления конечно).
  • Плюсы: адреса просто есть, не нужно нигде никого спрашивать.
  • Минусы: но только если есть статический внешний IPv4 адрес. Возможны некоторые проблемы со скоростью из-за нагрузки гейта, но я такого не замечал.
  • Настройка: есть специальный anycast адрес 192.88.99.1, под которым находятся гейты 6-to-4 -> IPv6. Теоретически должен автоматически выбираться ближайший такой сервер, в идеале сервер провайдера, но практически т.к. в России с IPv6 глухо (да, я повторяюсь, но что делать?) будет использоваться какой-нибудь зарубежный. Но ничего страшного в этом обычно нет.
    • В линуксе настраивается следующим образом:
      • поднимается специальный интерфейс (sit): /sbin/ifconfig sit0 up
      • к этому интерфейсу добавляется 6-to-4 адрес: /sbin/ifconfig sit0 add <local6to4address>/16
        <local6to4address> расчитывается как уже сказано выше, для роутера обычно берется адрес <сеть>::1, так что для приведенного выше примера он будет 2002:aabb:ccdd::1
      • настраивается роутинг на гейт: /sbin/route -A inet6 add 2000::/3 gw ::192.88.99.1 dev sit0
      • для инкапсуляции пакетов используются пакеты IPv4 с полем протокола установленным в 41. Не забываем разрешить этот протокол на файрволе.
      • подробнее можно прочитать тут: http://tldp.org/HOWTO/Linux+IPv6-HOWTO/configuring-ipv6to4-tunnels.html
    • В винде:
      • Включаете 6to4 командой: netsh int ipv6 6to4 set relay 192.88.99.1 enabled 1440
      • Если у вас XP, то вероятно предварительно придется включить интерфейс ipv6 командой: netsh interface ipv6 install
      • Также вместо этого можно включить Teredo (см. следующий пункт) — если есть внешний IP адрес, то teredo-клиент винды это увидит и будет использовать 6to4 вместо teredo. Это универсальный вариант, должен работать при любом раскладе.
• Teredo. Самый универсальный способ, работает практически всегда. Даже если у вас нет внешнего IPv4 адреса, и вообще вы за NAT'ом, а то и не одним, обычно все равно можно получить полноценный доступ к IPv6. Teredo это специальный вид туннеля, совмещенный со STUN (Simple Traversal of UDP through NATs, пробиватель NAT'ов). Реализация встроена в винды начиная с Windows XP SP2. В *IX-подобных операционках реализуется программой miredo.
  • Плюсы: просто работает, практически всегда. Соединения с другими Teredo (и 6-to-4) клиентами происходят напрямую, с нативными IPv6 хостами через автоматически определяемые гейты.
  • Минусы: относительно большой оверхед: на инкапсуляцию, на STUN и т.п. Адреса назначаются динамические. Соединения с нативными IPv6 хостами производятся через гейты, что может накладывать ограничения на скорость (но т.к. гейты ставятся на довольно толстых каналах, то обычно тут все в порядке). Опять же, теоретически гейты должны реализовываться провайдерами (что не особо сложно делается), но фактически этим никто не заморачивается, так что выбираться будут не особо близкорасположенные.
    Также этот метод не будет стабильно работать, если ваш провайдер динамически меняет NAT-сервера, через которые выпускает вас в интернет.
  • Настройка:
    • Если у вас линукс: поставить miredo из дистрибутива и запустить. Вуаля, все готово. Конечно если в вашем ядре есть модуль для IPv6, но в наше время врядли будет иначе.
    • Если виндовз: В этих ОС достаточно в настройках сети поставить протокол „Microsoft TCP/IP версии 6“. В вистах и выше вроде оно стоит по-умолчанию, и скорее всего все уже работает. Если же протокол установлен, но Teredo не работает, то следует включить его вручную. Делается это так:
      • От административного аккаунта запускается программа netsh, и далее следует вводить следующие строки одну за одной:

        interface
        ipv6
        set teredo type=client

      • В итоге текст в окне должен выглядеть так:

        netsh>interface
        netsh interface>ipv6
        netsh interface ipv6>set teredo type=client
        OK.
        

      • Через несколько секунд все должно заработать. Имеющиеся в системе адреса можно увидеть с помощью команды ipconfig. Глобальные IPv6 адреса обычно начинаются с «2xxx:…», адреса «fe80:…» локальные, они автоматически генерируются для всех интерфейсов и их наличие не дает выхода за пределы локальной сети (а то и какой-то отдельной ее части, в зависимости от ее топологии).
      • В некоторых случаях (например если машина заведена в домен) требуется форсированное включение teredo, для этого вместо «type=client» следует использовать «type=enterpriseclient». Только смотрите чтобы администратор домена вас за это не отлупил.

Проверить подключение можно с помощью команды «ping6 ipv6.google.com». Или зайти на сайт http://www.kame.net/ — если подключение установлено по IPv6, то черепашка будет анимированной.

Теперь ваш комп может принимать входящие соединения. Но не все соединения одинаково полезны. С другой стороны далеко не все программы слушают IPv6, да и адресов у него столько, что сканировать их нереально (особенно динамические вроде Teredo или Router Advertising), это не IPv4 в котором куда ни плюнь — в кого-нибудь да попадешь :) Но это все равно не повод пренебрегать контрацепцией, особенно если подключение будет активно использоваться. В линуксе это делается с помощью netfilter, управление которым осуществляется программой ip6tables. Она практически идентична iptables, за исключением используемого стека протоколов.

И таблицы nat у IPv6 нет — NAT/IPv6 реализовать теоретически можно, но практически он не нужен (хотя жаль таргет redirect, он иногда был полезен).

С другой стороны обычному пользователю закрывать файрволом практически нечего. Системные службы в современных ОС наружу не торчат, а запущенное самостоятельно (типа того же FTP сервера или торрента) для того и запущено, чтобы к ним можно было подключаться извне.

Зачем это нужно, и что это дает?

Вообще IPv6 полностью снимает проблему нехватки адресов, тем самым убирая таких губителей P2P как NAT. И даже если вы сейчас за NAT'ом — включаете teredo и все проблемы решены. Теоретически. Фактически же как ни странно, не смотря на работоспособность и простоту (причем обращаю внимание — появились эти возможности далеко не вчера, им уже много лет), P2P приложения IPv6 мало используют. Но профит все-таки есть.

• IM-клиенты (прямое соединение весьма полезно например при передаче файлов или при голосовом общении):
  • XMPP aka Jabber aka GTalk в принципе позволяют подключаться к серверу по IPv6. И при желании установить прямое соединение xmpp-клиент будет предлагать своему пиру IPv6 адрес, так что казалось бы тут все пучком. За исключением маленькой, но серьезной подлянки: в известных мне случаях клиенты будут предлагать друг-другу именно тот адрес, который использовался для подключения к серверу. Что вызовет проблемы когда часть клиентов подсоединено по IPv4, а часть по IPv6, особенно для тех IPv4 клиентов, которые не имеют поддержки IPv6 (а их пока большинство). Ну и не считая того, что пока еще далеко не все клиенты IPv6 в принципе умеют. Да и на популярных XMPP серверах IPv6 не настроено (по крайней мере на jabber.ru и jabber.org нет), но тут все относительно просто — в ejabberd включить IPv6 можно даже без перезапуска сервера, так что буде фича воспользована — настройки появятся. Отсутствие поддержки клиентами хуже.
  • MSN: вроде-бы поддерживает IPv6, но в каком виде и на сколько полно — не знаю. Как минимум у официального логин-сервера IPv6 адрес не прописан.
  • Другие IM системы за поддержкой IPv6 замечены не были.
• VoIP-программы: в традиционном SIP'е обычно используется свой STUN, но есть и системы с поддержкой IPv6: например для asterisk есть соответствующий патч, а начиная с версии 1.8 поддержка IPv6 в asterisk встроена. Также некоторые программные телефоны умеют. Вероятно скайп умеет IPv6. Точных данных на этот счет у меня нет, но запросы на эту функциональность были, и это слишком простой способ решения многих сложностей, чтобы им не воспользоваться.
• P2P-файлообмен: в протоколе bittorrent есть возможность использовать IPv6, но реализовано это несколько кривовато. Но практически все популярные торрент-клиенты IPv6 поддерживают. Проблема только в том, что трекеров с поддержкой IPv6 почти нет: из известных только бухта и IPv6-only трекер SixXs. Но есть и менее известные, плюс возможно получение IPv6 пиров через PEX.
  • Лирическое отступление: битторрент вполне нормально живет на IPv6, проблемы тут заключаются только при условии гибридного подключения IPv4+IPv6. Основная проблема в том, что подключившись к трекеру клиент „светит“ только один свой адрес. Да, можно еще передать и дополнительный, но так никто не делает, т.к. это во первых не удобно, а во вторых трекеры такое обычно игнорируют. Единственное адекватное решение — мультитрекерные торренты, в которых прописаны ipv4-only и ipv6-only трекеры. Или понадеяться на PEX, в расчете на то, что клиенты друг с другом разберутся. И, к счастью, обычно таки да, через PEX в рой попадают IPv6 адреса узлов, что позволяет пользоваться прямыми соединениями по v6 на всех трекерах, даже не поддерживающих v6.
• Web: сайтов, доступных по IPv6 не мало. Естественно практически все из них также доступны и по IPv4. Современные браузеры, в свою очередь, IPv6 обычно умеют.
  • Еще одно отступление: если вы делаете свой сайт, и он оказывается доступным по IPv6 то в большинстве случаев ни сайт, ни его скрипты не заметят ничего необычного и все будет работать как и раньше. Но вот некоторые места, завязанные на форматы IPv4 (например системы блокировок по IP) могут сломаться. А могут и не сломаться, смотря как сделаны.
• FTP: вполне нормально работает по IPv6, но требует поддержки клиентом и сервером команд EPSV и/или EPRT. В общем-то и те и те в большинстве своем это умеют, разве что в некоторых фтп-клиентах (типа fireftp) нужно ткнуть отдельную галочку для их использования.
• Игры: в основном конечно они расчитаны на игру через официальные сервера или в пределах локалки (и ни там ни там нет проблем с адресами), но много игр позволяют играть через интернет друг-с-другом напрямую. Однако IPv6 тут как-то не популярен, хотя есть и исключения. Например в XBOX360 используется Teredo. Майкрософт вообще активно продвигает IPv6.
• Можно поднять свой сервис (например http или ftp сервер, систему для удаленного управления своим компом в общем или отдельной программой в частности) даже находясь за провайдерским NATом (т.е. не имея выделенного внешнего IP). А динамические ДНС с поддержкой IPv6 (например от http://www.dns6.org/) позволяют с удобством этим пользоваться.
• IPSec — не смотря на существование NAT-T для IPSec/IPv4, его использование в условиях NAT'ов все равно весьма проблематично. Для IPv6 же IPSec родной, и работает превосходно (правда не в винде).
• PPPoE-VPN'ы и прочие GRE туннели — через NAT'ы работают довольно плохо и капризно. С IPv6 проблем быть не должно, плюс у IPv6 для этих целей есть IPSec, который также умеет туннелирование.
• Продолжите список?

Может показаться что при таком положении дел заморачиваться с включением у себя IPv6 смысла нет. Однако дела таковы в частности потому, что IPv6 пока не очень популярен среди конечных пользователей. Так сделаем же его популярней, и да будет больше софта использующего возможности установки прямых соединений между пользователями без проблем с NAT'ами. Ведь переход на IPv6 неизбежен, IPv4 адреса рано или поздно кончатся (по прогнозам их осталось еще на ~3 года).

С IPv6 есть только одна потенциальная проблема, из-за которой у пользователей часто возникает желание «отключить его нафик»: когда IPv6 включен, и окружение (роутеры, или прямые настройки системы) утверждает что у системы есть глобальный IPv6 адрес, а фактически этот адрес не работает. В таких случаях при попытке соединения с узлом, имеющим гибридное подключение (и v4 и v6 адреса одновременно) будет изначально использоваться подключение по v6, что ни к чему не приведет (т.к. локальный v6 адрес не работает, фактического подключения нет). Механизмы резервирования конечно поймут что по v6 соединение не устанавливается, и попробуют v4 — но на это ведь нужно время. А пользователи же нетерпеливые. «АААааааа, из-за ипв6 ничего не работает!!!1111 Ааааа, отключить его нахрен!!!!1111». Мораль отсюда такая: не следует настраивать роутеры, чтобы они врали клиентам о наличии глобального подключения. Или хотя-бы не блокировать ICMP, чтобы до клиентов доходило сообщение «network unreachable», и переключение на v4 происходило сразу же, а не по таймауту. Ну и еще такое случается когда teredo соединение «протухло» — машина пользователя думает что оно еще работает, а NAT уже убрал из таблицы трансляции записи, используемые этим соединением для STUN, и соответственно фактически соединение уже не работает. Тут, к сожалению, все зависит от NAT’а, иногда можно помочь keep-alive пакетами (пингуя время от времени по v6 какой-нибудь хост), а иногда нет.

А может я что-то полезное упускаю?

Изложение довольно сумбурное, но нельзя объять необъятное. Надеюсь что охватил хотя-бы по верхам большинство интересных аспектов.