26.10.2011

Обнаружил еще один занятный документ, » IPv6 Guidance for Internet Content and Application Service Providers«. Ниже следует перевод-конспект.

(рекомендации по внедрению IPv6 у контент-провайдеров и сервис-провайдеров, черновик)

Введение.
Внедрение IPv6 продолжается, и число пользователей, у которых будет отсутствовать IPv4, возрастет в ближайшие годы. Сервис-провайдерам и контент-провайдерам нужно внедрять IPv6, чтобы не потерять таких пользователей. Сейчас самое время этим заняться, так как количество «чистых» IPv6-пользователей невелико.
Важно принять меры, чтобы внедрение версии 6 не ухудшило работу с пользователями версии 4.
Сложно предсказать, когда количество пользователей версии 6 станет коммерчески-значимым, но (особенно с ростом числа мобильных пользователей) это может произойти достаточно быстро.
Единственная разумная стратегия внедрения версии 6 — это «поднять» оба протокола в равных условиях, для удовлетворения нынешних и будущих пользователей (RFC6180). Такая стратегия предусматривает два направления:
— «outside in» — предоставление доступа по IPv6 к своим ресурсам для «внешних» пользователей
— «inside out» — начать строить внутреннюю сетевую IPv6-инфраструктуру для пользователей из своих сетей
Нужно, чтобы все сотрудники, знающие основы IPv4, также знали и основы IPv4, например как записывается IPv6-адрес.
Известны забавные ситуации, происходящие при внедрении версиии 6:
— в одной организации избегали букв A-F в адресах, чтобы не сбивать с толку «старых» сетевых администраторов. Или — инженер поддежки советовал клиенту «отключить One-Pv6», то есть он так читал IPv6.
Очень полезно создать тестовую-лабораторную конфигурацию для того, чтобы набраться опыта.
Соединение с Интернетом может быть как «чистое» IPv6, так и туннельное. На начальном этапе рекомендуется второй вариант, но это замедляет доступ, особенно к «тяжелым» веб-страницам, а также уменьшает MTU, что ведет к фрагментации. По этой причине для получения качественных результатов использовать «чистое» IPv6-соединение.
В новой инфраструктуре можно отметить такие моменты: можно использовать как IP, так и PA-адреса, ничего принципиально отличного от версии 4 тут нет. Также не должно быть особых сложностей из-за маршрутизации, ведь эти процессы для 4 и 6 версий работают независимо. В DNS необходимо внести соответствующие AAAA-записи для ресурсов, правда есть сложности с Windows XP, где даже при наличии правильно сконфигурированного IPv6, DNS-запросы отправляются только по IPv4. DNS-сервер должен поддерживать обработку запросов как в 4, так и в 6 версии протокола. Не должно быть проблем с балансировкой нагрузки, так как в ближайшее время не ожидается сколько-нибудь значительного IPv6-трафика, и задержка с обновлением устройств балансировки нагрузки не должна внести негативный вклад. HTTP-прокси можно сконфигурировать так, что он будет принимать запросы по IPv6, а затем отправлят дальше по IPv4.
ТСР/IP стек поддерживает оба сетевых проткола во всех популярных ОС, нужно только разрешить работу 6 версии, и возможно — DHCPv6.
На прикладном уровне также не должно быть особых проблем. Основные HTTP-серверы поддерживают IPv6, другие приложения (например, почтовые программы) — тоже. Но нельзя сказать чего-либо определенного про специфические приложения, или про свои собственные разработки. Можно рекомендовать использовать в приложениях не IP-адреса, а доменные имена, что сделает их более гибкими. Есть специфическая проблема HTTP-сервисами, которые используют ip-адрес в cookies. Сервер может создать cookie на основании IPv4 или IPv6-адреса, но нет гарантии, что клиент будет использовать ту же самую версию сетевого проткола. Общие соображения о переносе приложений приведены в RFC4038.
Геолокация: с течением времени базы данных по привязке IPv6-адресов к географическим пунктам будут наполняться, и принципиальных различий с 4 версией не будет. Трудности могут появиться из-за возрастающего количества мобильных пользователей.
Наиболее сложные проблемы будут при использовании туннельных соединений: отсутствие АААА-записей, проблемы с Path MTU Discovery, MSS и проч. Использование специальных URL, например ipv6.somedomain.tld в дополнение к «классическому» www вряд ли целесообразно, так как вряд ли пользователи станут запоминать второй URL.
Контент-провайдеры также получат набор проблем, если на некоторых точках их присутствия будет только IPv6, а на других — dual-stack.

Словом, «Волга впадает в Каспийское море».


  *** Via IPv4 ***