От переводчика: я не нашел на хабре подходящего «низкоуровневого сетевого» блога и сначала даже сомневался, стоит ли делать данный перевод. Но всё-таки, все мы с вами разработчики (надеюсь, хотя бы большинство), и описываемая в статье проблема с IPv6 сейчас актуальна, как никогда. До сих пор я вынужден отказываться от любимого русского зеркала Debian (ftp.chg.ru), по причине того, что слишком передовое зеркало отлично работает по IPv6, а мой провайдер выдаёт IPv6 адреса, но IPv6 трафик не роутит, да. В общем, я связался с Оле Якобсеном (Ole J. Jacobsen), главным редактором The Internet Protocol Journal, и с его благословения публикую эту статью. Поехали.
Чтобы быть успешными, новые технологии должны приносить радость пользователям. В процессе поиска лучшего способа внедрить технологию как правило придумывают, исследуют, пробуют и отбрасывают несколько подходов. Данная статья рассматривает два таких подхода для IPv6 и протокола передачи с управлением потоком (Stream Control Transmission Protocol, SCTP)[10].
Современные браузеры, веб-серверы и операционные системы поддерживают IPv4 и IPv6. IPv6 также поддерживается несколькими крупных контент-провайдерами, включая Google, NetFlix и Facebook. Однако их контент нельзя назвать широко доступным через IPv6 из-за конфликта между технологией IPv6 и бизнес-реалиями.
Подключение в веб-браузерах и операционных системах включает в себя выполнение DNS-запросов к AAAA (IPv6 — прим. пер.) и A (IPv4 — прим. пер.) записям, а затем попытки последовательно соединиться с результирующими IPv6 и IPv4 адресами. Если путь по IPv6 недоступен (или медленный), соединение может сожрать много времени, прежде чем программа начнёт пробовать традиционный IPv4. Процесс будет особенно мучителен на среднестатистических веб-сайтах, запрашивающих объекты с различных узлов — каждая проблема IPv6 вызовет задержку. В сочетании операционной системы с браузером, если IPv6 недоступен, задержка может вылиться в тормоза от 20 секунд до нескольких минут[2]. Типичный поток сообщений от TCP-клиента показан на рисунке 1. Очевидно, что подобная задержка неприемлема для пользователей, которые спасаются от торможения, отключая у себя поддержку IPv6 протокола[3] или избегая поддерживающих IPv6 сайтов.
Рисунок 1: поведение обычного веб-браузера
Проблема «сломанных» IPv6 сетей распространена достаточно широко[6]. Предоставление контента — это бизнес, как прямой (например, воспроизведение потокового видео), так и непрямой (продажа рекламных показов). Если пользователи испытывают лаги, просматривая поддерживающий IPv6 контент (по технологическим причинам, указанным выше), у них сразу появляется отличный стимул посещать другие сайты. Этот сценарий означает упущенную прибыль и категорически не подходит для бизнеса. Учитывая то, что все потребители сегодняшнего интернета могут достичь контента через IPv4, включать IPv6 — большой бизнес-риск, так как некоторые потребители обязательно от этого пострадают. Крупные контент-провайдеры в течение некоторого времени изучали ситуацию и в итоге опубликовали результаты [7], показывающие, что количество отказов IPv6 слишком большое, чтобы включать IPv6 AAAA для их контента.
IPv6 проблемы вызваны несколькими причинами. Это новая технология, и качество сети IPv6 всё ещё не находится на том же уровне, что и для IPv4, из-за точечных тоннелей, неуправляемых тоннелей[11] (как правило, 6to4) и неправильно настроенных файрволов, кроме того, отказы отдельных роутеров и соединений также весьма легко вызывают отказы IPv6. Множество приложений продолжают поддерживать только IPv4, сетевые администраторы полагаются на то, что двухстековое оборудование прозрачно переключится на IPv4 во время отказов IPv6.
Однако, такие переключения не бывают прозрачными для пользователей — они занимают множество секунд или даже минут! Чтобы избежать этих проблем, у контент-провайдеров есть только один выход — не отдавать свои AAAA записи тем, у кого IPv6 соединение может оказаться поломанным или медленным.
Чтобы обойти эту проблему, в Google создали белый список DNS-серверов, которым они будут предоставлять свои AAAA записи[8]. Тем не менее, в своём текущем воплощении ведение белого списка DNS масштабируется плохо, так как сначала интернет-провайдер должен доказать своё хорошее IPv6-соединение с гуглом, после чего гугл внесёт в белый список DNS-серверы провайдера. Проблема масштабируемости заключается в том, что в мире, вообще говоря, существуют тысячи интернет-провайдеров, и ведение белого списка превращается в утомительный ручной труд, как для провайдеров, так и для Google. Помимо этого, если каждый контент-провайдер введет белый список DNS, каждому интернет-провайдеру придётся работать сразу с несколькими контент-провайдерами, чтобы обеспечить выгодность развернутой среди их пользователей IPv6-сети! Поэтому контент-провайдеры начали работать совместно, чтобы утвердить требования для внесения в белый список DNS и создать некий общий сервис для автоматизации данного процесса[5].
В дополнение к этому, внесение в белый список DNS еще не гарантирует работающую (или быструю) IPv6 сеть, так как между хорошей IPv6 связностью и наличием AAAA-записей на DNS-сервере пользовательского интернет-провайдера нет прямой связи. Даже с наилучшим замыслом и дизайном сети, всё равно будут возникать случаи, когда доступен только один путь — либо IPv4, либо IPv6 — в то время, как второй вид транспорта недоступен. Результатом будут чрезмерные задержки для клиентов, поддерживающих IPv4 либо оба стека, в зависимости от того, какого рода поломка случилась.
Данная ситуация вносит свой вклад в пользовательское ощущение того, что интернет или конкретный сайт «упали». Пользователь предпочтёт ходить на другой сайт, вероятно, уже никогда не возвращаясь на «упавший».
Прим. пер.: в оригинале употребляется «happy eyeballs» что буквально переводится как «счастливые глазные яблоки», но в западном телекоме «eyeballs» обычно означает «пользователи интернет».
Данную проблему решает другой подход. Вместо того чтобы неспешно пытаться установить соединение по IPv6, а затем по IPv4, приложение делает одновременные попытки установить соединение сразу через IPv4 и IPv6.
Одновременные попытки соединения потребляют немного большую часть канала и удваивают число попыток соединения с сервером. Чтобы уменьшить ненужный трафик, также используется кэш, в котором хранится история удачных и провальных попыток соединения через IPv4/6. Мы называем данный подход: «Счастливые глазки»[1], так как именно глазки (пользователи) более счастливы — их компьютер мгновенно отображает содержимое, хотя скорость работы сети и уменьшается (рисунок 2).
Рисунок 2: Двухстековый браузер, реализующий «Счастливые глазки»
Очевидно, посылка TCP SYN через IPv6 и IPv4 удваивает число попыток соединения, сделанных клиентом. Этот избыток соединений может быть уменьшен путём запоминания приложением, какой протокол использовался при предыдущем соединении — IPv6 или IPv4, — и использования этой информации при последующих попытках. Возможное усложнение данного кэша зависит от памяти (или диска), но даже простое кэширование может быть весьма эффективным. При подключении к новой сети (3G, различным Wi-Fi сетям или физическому Ethernet) можно определить связность этой сети и при необходимости очистить кэш попыток, частично или полностью.
Таким образом, удвоение числа попыток соединения случается только при подключении к новой сети. В этом случае начальная попытка соединения будет происходить с задержкой, в силу того что IPv6 (или IPv4) будет пробоваться в первую очередь. В любом случае, если IPv6 (или IPv4) маршрут недоступен, значительных заметных пользователю тормозов не будет. Цель «Счастливых глазок» — сохранить IPv6 включенным, при этом спасая пользователей от его падений — так, чтобы посещение сайтов с IPv6 не вызывало тормозов.
При таком подходе пользователи постепенно мигрируют с IPv4 на IPv6, при необходимости мгновенно возвращаясь к использованию IPv4. Данное решение демонстрирует значительное улучшение по сравнению с существующими веб-браузерами. Препятствием же для этой идеи является то, что ее необходимо воплощать в каждом отдельном приложении. Хотя обновление браузеров — это дополнительный тяжкий труд, существует всего пять основных браузеров[9], а кроме того, браузеры получают мгновенную выгоду от таких активных попыток подключения. Кроме того браузеры всё равно часто обновляют во имя быстрых движков JavaScript и других новых фич.
Еще одной идеей определения работоспособности IPv6 является посылка ping-ов или других простых запросов к какому-нибудь IPv6 ресурсу в интернете и отключение IPv6, если ресурс не ответил. Этот подход служит препятствием для внутреннего IPv6 трафика предприятий (который может ходить вполне успешно, в то время как доступа в IPv6-интернет не имеется), а также отключение IPv6 сломает IPv6 возможности, внедренные в операционную систему (например, DirectAccess в Windows или Back to My Mac в Mac OS X). Преимуществом же является то, что если IPv6 отключен, ни одно приложение уже не пострадает от его падения и задержек, связанных с переключением на IPv4.
Вдобавок к проблеме выбора протокола сетевого уровня схожая задача существует и на транспортном уровне. Возможно, это для кого-то будет сюрпризом, но помимо TCP существует еще один транспортный протокол — протокол передачи с управлением потоком (SCTP). SCTP предоставляет существенные преимущества по сравнению с TCP и был спроектирован с учётом тех проблем, с которыми приходилось сталкиваться при реализации и внедрении TCP[4].
В отличие от IPv6 и IPv4, для которых имеются различные DNS записи (AAAA и A), у нас нет специальной записи, показывающей, что приложению можно или нужно использовать другой транспортный протокол. Но даже если бы мы могли обозначить поддержку SCTP в DNS, где-то в ходе следования маршрута SCTP может блокироваться, снижая полезность данной DNS-записи. Маршрут также может быть заблокирован NAT'ом или файрволлом, ожидающими исключительно TCP или UDP.
«Счастливые глазки» также описывают методику, при которой клиент может одновременно пробовать подключаться, используя и TCP, и SCTP. При необходимости данные попытки делаются приложением, и приложению надлежит выбрать транспорт, который ответил быстрее, и закэшировать эту информацию для уменьшения флуда во время последующих попыток подключения к данному серверу. Сценарий подключения показан на рисунке 3.
Рисунок 3: Клиент, реализующий «Счастливые глазки» для выбора между TCP и SCTP
Комбинируя выбор IPv6/IPv4 с выбором SCTP/TCP, веб-браузер, запущенный на компьютере, подключенном к новой двухстековой сети, посылает четыре пакета: IPv4 TCP SYN, IPv6 TCP SYN, IPv4 SCTP INIT и IPv6 SCTP INIT. Основываясь на ответах, браузер решает, какой транспортный протокол и адресное пространство (IPv6 или IPv4) предпочесть и отбрасывает остальные подключения. Как описано ранее, информация о соединении кэшируется для последующего использования, чтобы снизить потребляемую ширину канала и серверные ресурсы.
Новые технологии, направленные на улучшение жизни пользователей, будут успешными только в случае, если оправдают ожидания — улучшат эту самую жизнь. Так как многие компании извлекают всю свою прибыль, работая в интернете, любое ухудшение сервиса означает упущенную прибыль. Поэтому развертывание новой технологии не должно негативно сказываться на впечатлении пользователя. Данная статья описывает один из механизмов, которые могут использоваться разработчиками, чтобы избежать негативной реакции ваших пользователей.
[1] Dan Wing, Andrew Yourtchenko, and Preethi Natarajan, «Happy Eyeballs: Trending Towards Success (IPv6 and SCTP),» Internet-Draft, Work-in-Progress, July 2009: http://tools.ietf.org/html/draft-wing-http-new-tech
[2] «Broken IPv6 clients,» Lorenzo Colitti, June 2010: https://sites.google.com/site/ipv6implementors/2010/agenda
[3] «Google Trends»: http://www.google.com/trends?q=enable+ipv6%2C+disable+ipv6
[4] P. Natarajan, «Leveraging Innovative Transport Layer Services for Improved Application Performance,» February 2009: http://www.cis.udel.edu/~amer/PEL/poc/pdf/NatarajanPhDdissertation.pdf
[5] Carolyn Duffy Marsan, «Google, Microsoft, Netflix in talks to create shared list of IPv6 users,» Network World, March 2010: http://www.networkworld.com/news/2010/032610-dns-ipv6-whitelist.html
[6] Tore Anderson, «IPv6 brokenness experiment, November results,» November 2009: http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002707.html
[7] Igor Gashinsky, «IPv6 & recursive resolvers: How do we make the transition less painful?» March 2010: http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf
[8] «Access Google services over IPv6»: http://www.google.com/intl/en/ipv6
[9] «Usage share of web browsers»: http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
[10] R. Stewart, Ed., «Stream Control Transmission Protocol,» RFC 4960, September 2007.
[11] Gunter Van de Velde, Ole Troan, and Tim Chown, «Non-Managed IPv6 Tunnels considered Harmful,» July 2009: http://tools.ietf.org/html/draft-vandevelde-v6ops-harmful-tunnels
Прошу простить меня за моё косноязычие, накладывающееся на чрезмерно научный стиль статьи. Надеюсь, вам было интересно. А теперь минутка обязательной информации:
Перепечатано с разрешения The Internet Protocol Journal (IPJ) из тома 13, №3, Сентябрь 2010. IPJ — ежеквартальный технический журнал, публикуемый Cisco Systems. См. www.cisco.com/ipj
Reprinted with permission from The Internet Protocol Journal (IPJ), Volume 13, No. 3, September, 2010. IPJ is a quarterly technical journal published by Cisco Systems. See www.cisco.com/ipj
Чтобы быть успешными, новые технологии должны приносить радость пользователям. В процессе поиска лучшего способа внедрить технологию как правило придумывают, исследуют, пробуют и отбрасывают несколько подходов. Данная статья рассматривает два таких подхода для IPv6 и протокола передачи с управлением потоком (Stream Control Transmission Protocol, SCTP)[10].
Современные браузеры, веб-серверы и операционные системы поддерживают IPv4 и IPv6. IPv6 также поддерживается несколькими крупных контент-провайдерами, включая Google, NetFlix и Facebook. Однако их контент нельзя назвать широко доступным через IPv6 из-за конфликта между технологией IPv6 и бизнес-реалиями.
Подключение в веб-браузерах и операционных системах включает в себя выполнение DNS-запросов к AAAA (IPv6 — прим. пер.) и A (IPv4 — прим. пер.) записям, а затем попытки последовательно соединиться с результирующими IPv6 и IPv4 адресами. Если путь по IPv6 недоступен (или медленный), соединение может сожрать много времени, прежде чем программа начнёт пробовать традиционный IPv4. Процесс будет особенно мучителен на среднестатистических веб-сайтах, запрашивающих объекты с различных узлов — каждая проблема IPv6 вызовет задержку. В сочетании операционной системы с браузером, если IPv6 недоступен, задержка может вылиться в тормоза от 20 секунд до нескольких минут[2]. Типичный поток сообщений от TCP-клиента показан на рисунке 1. Очевидно, что подобная задержка неприемлема для пользователей, которые спасаются от торможения, отключая у себя поддержку IPv6 протокола[3] или избегая поддерживающих IPv6 сайтов.
Рисунок 1: поведение обычного веб-браузера
Проблема «сломанных» IPv6 сетей распространена достаточно широко[6]. Предоставление контента — это бизнес, как прямой (например, воспроизведение потокового видео), так и непрямой (продажа рекламных показов). Если пользователи испытывают лаги, просматривая поддерживающий IPv6 контент (по технологическим причинам, указанным выше), у них сразу появляется отличный стимул посещать другие сайты. Этот сценарий означает упущенную прибыль и категорически не подходит для бизнеса. Учитывая то, что все потребители сегодняшнего интернета могут достичь контента через IPv4, включать IPv6 — большой бизнес-риск, так как некоторые потребители обязательно от этого пострадают. Крупные контент-провайдеры в течение некоторого времени изучали ситуацию и в итоге опубликовали результаты [7], показывающие, что количество отказов IPv6 слишком большое, чтобы включать IPv6 AAAA для их контента.
IPv6 проблемы вызваны несколькими причинами. Это новая технология, и качество сети IPv6 всё ещё не находится на том же уровне, что и для IPv4, из-за точечных тоннелей, неуправляемых тоннелей[11] (как правило, 6to4) и неправильно настроенных файрволов, кроме того, отказы отдельных роутеров и соединений также весьма легко вызывают отказы IPv6. Множество приложений продолжают поддерживать только IPv4, сетевые администраторы полагаются на то, что двухстековое оборудование прозрачно переключится на IPv4 во время отказов IPv6.
Однако, такие переключения не бывают прозрачными для пользователей — они занимают множество секунд или даже минут! Чтобы избежать этих проблем, у контент-провайдеров есть только один выход — не отдавать свои AAAA записи тем, у кого IPv6 соединение может оказаться поломанным или медленным.
Чтобы обойти эту проблему, в Google создали белый список DNS-серверов, которым они будут предоставлять свои AAAA записи[8]. Тем не менее, в своём текущем воплощении ведение белого списка DNS масштабируется плохо, так как сначала интернет-провайдер должен доказать своё хорошее IPv6-соединение с гуглом, после чего гугл внесёт в белый список DNS-серверы провайдера. Проблема масштабируемости заключается в том, что в мире, вообще говоря, существуют тысячи интернет-провайдеров, и ведение белого списка превращается в утомительный ручной труд, как для провайдеров, так и для Google. Помимо этого, если каждый контент-провайдер введет белый список DNS, каждому интернет-провайдеру придётся работать сразу с несколькими контент-провайдерами, чтобы обеспечить выгодность развернутой среди их пользователей IPv6-сети! Поэтому контент-провайдеры начали работать совместно, чтобы утвердить требования для внесения в белый список DNS и создать некий общий сервис для автоматизации данного процесса[5].
В дополнение к этому, внесение в белый список DNS еще не гарантирует работающую (или быструю) IPv6 сеть, так как между хорошей IPv6 связностью и наличием AAAA-записей на DNS-сервере пользовательского интернет-провайдера нет прямой связи. Даже с наилучшим замыслом и дизайном сети, всё равно будут возникать случаи, когда доступен только один путь — либо IPv4, либо IPv6 — в то время, как второй вид транспорта недоступен. Результатом будут чрезмерные задержки для клиентов, поддерживающих IPv4 либо оба стека, в зависимости от того, какого рода поломка случилась.
Данная ситуация вносит свой вклад в пользовательское ощущение того, что интернет или конкретный сайт «упали». Пользователь предпочтёт ходить на другой сайт, вероятно, уже никогда не возвращаясь на «упавший».
Счастливые глазки
Прим. пер.: в оригинале употребляется «happy eyeballs» что буквально переводится как «счастливые глазные яблоки», но в западном телекоме «eyeballs» обычно означает «пользователи интернет».
Данную проблему решает другой подход. Вместо того чтобы неспешно пытаться установить соединение по IPv6, а затем по IPv4, приложение делает одновременные попытки установить соединение сразу через IPv4 и IPv6.
Одновременные попытки соединения потребляют немного большую часть канала и удваивают число попыток соединения с сервером. Чтобы уменьшить ненужный трафик, также используется кэш, в котором хранится история удачных и провальных попыток соединения через IPv4/6. Мы называем данный подход: «Счастливые глазки»[1], так как именно глазки (пользователи) более счастливы — их компьютер мгновенно отображает содержимое, хотя скорость работы сети и уменьшается (рисунок 2).
Рисунок 2: Двухстековый браузер, реализующий «Счастливые глазки»
Очевидно, посылка TCP SYN через IPv6 и IPv4 удваивает число попыток соединения, сделанных клиентом. Этот избыток соединений может быть уменьшен путём запоминания приложением, какой протокол использовался при предыдущем соединении — IPv6 или IPv4, — и использования этой информации при последующих попытках. Возможное усложнение данного кэша зависит от памяти (или диска), но даже простое кэширование может быть весьма эффективным. При подключении к новой сети (3G, различным Wi-Fi сетям или физическому Ethernet) можно определить связность этой сети и при необходимости очистить кэш попыток, частично или полностью.
Таким образом, удвоение числа попыток соединения случается только при подключении к новой сети. В этом случае начальная попытка соединения будет происходить с задержкой, в силу того что IPv6 (или IPv4) будет пробоваться в первую очередь. В любом случае, если IPv6 (или IPv4) маршрут недоступен, значительных заметных пользователю тормозов не будет. Цель «Счастливых глазок» — сохранить IPv6 включенным, при этом спасая пользователей от его падений — так, чтобы посещение сайтов с IPv6 не вызывало тормозов.
При таком подходе пользователи постепенно мигрируют с IPv4 на IPv6, при необходимости мгновенно возвращаясь к использованию IPv4. Данное решение демонстрирует значительное улучшение по сравнению с существующими веб-браузерами. Препятствием же для этой идеи является то, что ее необходимо воплощать в каждом отдельном приложении. Хотя обновление браузеров — это дополнительный тяжкий труд, существует всего пять основных браузеров[9], а кроме того, браузеры получают мгновенную выгоду от таких активных попыток подключения. Кроме того браузеры всё равно часто обновляют во имя быстрых движков JavaScript и других новых фич.
Еще одной идеей определения работоспособности IPv6 является посылка ping-ов или других простых запросов к какому-нибудь IPv6 ресурсу в интернете и отключение IPv6, если ресурс не ответил. Этот подход служит препятствием для внутреннего IPv6 трафика предприятий (который может ходить вполне успешно, в то время как доступа в IPv6-интернет не имеется), а также отключение IPv6 сломает IPv6 возможности, внедренные в операционную систему (например, DirectAccess в Windows или Back to My Mac в Mac OS X). Преимуществом же является то, что если IPv6 отключен, ни одно приложение уже не пострадает от его падения и задержек, связанных с переключением на IPv4.
Новый транспорт — SCTP
Вдобавок к проблеме выбора протокола сетевого уровня схожая задача существует и на транспортном уровне. Возможно, это для кого-то будет сюрпризом, но помимо TCP существует еще один транспортный протокол — протокол передачи с управлением потоком (SCTP). SCTP предоставляет существенные преимущества по сравнению с TCP и был спроектирован с учётом тех проблем, с которыми приходилось сталкиваться при реализации и внедрении TCP[4].
В отличие от IPv6 и IPv4, для которых имеются различные DNS записи (AAAA и A), у нас нет специальной записи, показывающей, что приложению можно или нужно использовать другой транспортный протокол. Но даже если бы мы могли обозначить поддержку SCTP в DNS, где-то в ходе следования маршрута SCTP может блокироваться, снижая полезность данной DNS-записи. Маршрут также может быть заблокирован NAT'ом или файрволлом, ожидающими исключительно TCP или UDP.
«Счастливые глазки» также описывают методику, при которой клиент может одновременно пробовать подключаться, используя и TCP, и SCTP. При необходимости данные попытки делаются приложением, и приложению надлежит выбрать транспорт, который ответил быстрее, и закэшировать эту информацию для уменьшения флуда во время последующих попыток подключения к данному серверу. Сценарий подключения показан на рисунке 3.
Рисунок 3: Клиент, реализующий «Счастливые глазки» для выбора между TCP и SCTP
Комбинируя выбор IPv6/IPv4 с выбором SCTP/TCP, веб-браузер, запущенный на компьютере, подключенном к новой двухстековой сети, посылает четыре пакета: IPv4 TCP SYN, IPv6 TCP SYN, IPv4 SCTP INIT и IPv6 SCTP INIT. Основываясь на ответах, браузер решает, какой транспортный протокол и адресное пространство (IPv6 или IPv4) предпочесть и отбрасывает остальные подключения. Как описано ранее, информация о соединении кэшируется для последующего использования, чтобы снизить потребляемую ширину канала и серверные ресурсы.
Заключение
Новые технологии, направленные на улучшение жизни пользователей, будут успешными только в случае, если оправдают ожидания — улучшат эту самую жизнь. Так как многие компании извлекают всю свою прибыль, работая в интернете, любое ухудшение сервиса означает упущенную прибыль. Поэтому развертывание новой технологии не должно негативно сказываться на впечатлении пользователя. Данная статья описывает один из механизмов, которые могут использоваться разработчиками, чтобы избежать негативной реакции ваших пользователей.
Ссылки
[1] Dan Wing, Andrew Yourtchenko, and Preethi Natarajan, «Happy Eyeballs: Trending Towards Success (IPv6 and SCTP),» Internet-Draft, Work-in-Progress, July 2009: http://tools.ietf.org/html/draft-wing-http-new-tech
[2] «Broken IPv6 clients,» Lorenzo Colitti, June 2010: https://sites.google.com/site/ipv6implementors/2010/agenda
[3] «Google Trends»: http://www.google.com/trends?q=enable+ipv6%2C+disable+ipv6
[4] P. Natarajan, «Leveraging Innovative Transport Layer Services for Improved Application Performance,» February 2009: http://www.cis.udel.edu/~amer/PEL/poc/pdf/NatarajanPhDdissertation.pdf
[5] Carolyn Duffy Marsan, «Google, Microsoft, Netflix in talks to create shared list of IPv6 users,» Network World, March 2010: http://www.networkworld.com/news/2010/032610-dns-ipv6-whitelist.html
[6] Tore Anderson, «IPv6 brokenness experiment, November results,» November 2009: http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002707.html
[7] Igor Gashinsky, «IPv6 & recursive resolvers: How do we make the transition less painful?» March 2010: http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf
[8] «Access Google services over IPv6»: http://www.google.com/intl/en/ipv6
[9] «Usage share of web browsers»: http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
[10] R. Stewart, Ed., «Stream Control Transmission Protocol,» RFC 4960, September 2007.
[11] Gunter Van de Velde, Ole Troan, and Tim Chown, «Non-Managed IPv6 Tunnels considered Harmful,» July 2009: http://tools.ietf.org/html/draft-vandevelde-v6ops-harmful-tunnels
Финал от переводчика
Прошу простить меня за моё косноязычие, накладывающееся на чрезмерно научный стиль статьи. Надеюсь, вам было интересно. А теперь минутка обязательной информации:
Перепечатано с разрешения The Internet Protocol Journal (IPJ) из тома 13, №3, Сентябрь 2010. IPJ — ежеквартальный технический журнал, публикуемый Cisco Systems. См. www.cisco.com/ipj
Reprinted with permission from The Internet Protocol Journal (IPJ), Volume 13, No. 3, September, 2010. IPJ is a quarterly technical journal published by Cisco Systems. See www.cisco.com/ipj
