01.10.2014

Итоги сентября и первых девяти месяцев 2014г.

(бОльшая часть статистики и иллюстраций вынесены на отдельную страницу)

Наш IPv6-трафик не изменился по сравнению с августом, то есть составил те же 0.011% от IPv4-трафика. Количество DNS-запросов, полученных по IPv6, немножко упало и составило 0.86% от общего.

Количество IPv6-префиксов в «большой» таблице превысило 19,100, а от MSK-IX получаем более 1000 префиксов.

В логах данного сайта за месяц зафиксировано 235 уникальных IPv6-адресов /128 (201 уникальный по /64), то есть примерно 8 адресов в сутки.

19.09.2014

В Великобритании тоже появился свой национальный Совет по внедрению IPv6.  Вот его цели (кратко):

  • организовать обмен информацией об успешном внедрении IPv6
  • сотрудничать со всеми организациями, продвигать развитие IPv6 в Великобритании
  • добиваться изменения мнения о Великобритании, как о стране с низким уровнем развития IPv6

12.09.2014

В министерстве обороны США есть сеть под названием DREN (Defense Research and Engineering Network), то есть сеть для исследований в сфере безопасности. Сеть была создана давно, а в 2003 году в ней уже работала поддежка IPv6. В июле 2014г. было принято решение, что всё, что работает в этой сети (и оборудование, и программы) должно поддерживать IPv6. Формулировки звучали примерно так:

Правило №1

Если нельзя получить доступ к сайту какой-либо компании или к сайту про какой-либо продукт по IPv6, то такой продукт не рассматривается.

Причины:

  • если не осваивать IPv6 сейчас, то это затруднит его освоение в будущем — лучше обнаружить все ошибки и проблемы заранее.
  • если сайт какой-либо фирмы доступен по IPv6, то это служит хорошим признаком того, что эта фирма развивается
  • такой подход со стороны DOD создает заинтересованность у других организаций в освоении IPv6

«DREN — это IPv6-сеть, в которой есть поддержка старого (IPv4) протокола.»

Ссылки:

  1. www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/DREN_Success_Story.pdf
  2. www.internetsociety.org/deploy360/blog/2014/09/us-dods-dren-will-only-buy-products-with-an-ipv6-website/

07.09.2014

RFC 5952 — рекомендации по текстовому представлению IPv6-адреса. Август 2010

(перевод-конспект)

2.1. Не нужно писать лидирующие нули в отдельных полях.
2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
2001:db8:aaaa:bbbb:cccc:dddd:eeee:1

2.2. Можно использовать специальное обозначение для сокращения записи адреса с непрерывной группой нулей.
2001:db8:aaaa:bbbb:cccc:dddd::1
2001:db8:aaaa:bbbb:cccc:dddd:0:1

Можно выбирать количество сокращаемых нулей
2001:db8:0:0:0::1
2001:db8:0:0::1
2001:db8:0::1
2001:db8::1

Обозначение «::» можно использовать в адресе только один раз
2001:db8::aaaa:0:0:1
2001:db8:0:0:aaaa::1

2.3. Можно использовать и верхний, и нижний регистр
2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa

3. Возможные проблемы

3.1. Поиск по адресу

3.1.1. UNIX чувствителен к регистру символов, но многие приложения при работе с адресом понимают оба регистра.

3.1.2. Поиск в тексте и др.
При поиске адреса в текстах или эл.таблицах нужно иметь в виду, что адрес может быть записан с сокращениями. Это особенно важно, если при поиске используются регулярные выражения.

3.1.3. Поиск по Whois
Эта утилита выдает результаты поиска в нескращеном виде, что может сбивать с толку.
Например, при поиске адреса 2001:db8::/48, он может быть показан в выдаче как 2001:0db8:0000::/48.

3.1.4. Поиск адреса в сетевых схемах и документах.
В документации часто присутствуют сетевые адреса. Во время возникновения проблем в сети часто нужно найти нужный адрес на схеме (в документации). Разные способы записи (сокращения записи) адреса могут привести к увеличению времени, необходимого
для поиска нужного адреса.

3.2.2. Ведение логов
Если приложение записывает адрес в несокращеном виде, то это делает адрес громоздким, особенно по сравнению с v4. Перед выводом адрес нужно преобразовывать к сокращенному виду (если это возможно). Если лог ведется на две системы, то представление адреса должно быть на них одинаковым.

3.2.3. Ситуация 1
Есть много методов проверки конфигураций роутеров. Иногда это делается путем сравнения старой и фактической конфигурации. В этом случае, если адрес 2001:db8::1 был изменен на 2001:0db8:0000:0000:0000:0000:0000:0001 только потому, что так понятнее новому инженеру, применение утилит типа diff покажет, что конфигурация была изменена.

3.2.4. Ситуация 2
В случае использования программ, работающих с IP addresses, если будет зафиксирована разница в написании адреса, то может быть вызвана ложная тревога. Результат SNMP GET, преобразованный в текст, и сравниваемый с тем же адресом, записанным человеком, не совпадут.

3.2.5. Дополнительные проверки
Некоторые протоколы проводят дополнительные проверки, например при работе с сертификатами X.509. Если IPv6-адрес в такой ситуации будет некорректно конвертирован в текстовое представление, то сертификат не будет подтвержден.

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

3.3.1. Выводы
Если инженер задает IPv6-адрес 2001:db8:0:0:1:0:0:1, система может принять его и отобразить как 2001:DB8::1:0:0:1. Профессионала это не смутит, но начинающие могут счесть ошибкой.

3.3.2. Обращения от клиентов
Когда клиент звонит и сообщает о проблеме, следует внимательно работать с IPv6-адресом. Не все клиенты разбираются в адресах, и инженер в службе поддержки должен уметь работать с любой записью адреса, чтобы избежать длительных обьяснений клиенту, что 2001:db8:0:1::1 и 2001:db8::1:0:0:0:1 одно и то же.

3.3.3. Работа с жалобами
Жалобы обычно включают в себя IP-адрес источника, манера записи адреса может отличаться в разных системах (у разных инженеров). Персонал, занимающийся обработкой жалоб, должен знать, что 2001:db8::1:0:1 и 2001:db8:1::0:1 — не одно и то же. Ошибки в использовании символов «::» могут дорого обойтись. Система сопровождения сообщений о таких инцидентах должна уметь обрабатывать IPv6-адрес корректно независимо от манеры написания (сокращения). Информация о регистре букв в адресе неважна, но некоторые люди могут придавать этому значение.

3.4.1. Замена ОС или оборудования.
Когда происходит замена ОС или оборудования нужно принимать во внимание, что что-то может не заработать из-за разницы в манере записи IPv6-адреса.

3.4.2. Ведение документации
Документ, который составляют несколько авторов, может оказаться сложным для прочтения.

3.4.3. «Большая» буква D и цифра 0 похожи по виду и это может привести к ошибке. Аналогично В и 8.

4. Рекомендации по написанию IPv6-адреса.
Приведенные ниже рекомендации полностью соответствуют [RFC4291]. Все системы, при генерации текстового представления IPv6-адреса, должны следовать этим рекомендациям и понимать любой формат записи адреса из [RFC4291]. Предполагается, что инженеры
также будут следовать этим рекомендациям.

4.1. Лидирующие нули в адресе.
Лидирующие НУЖНО нужно опускать. Например, запись 2001:0db8::0001 неприемлема и должна выглядеть как 2001:db8::1. Одно 16-битное поле 0000 НУЖНО записывать как 0.

4.2.1. Сокращать как можно больше
Символы «::» ДОЛЖНЫ быть использованы для МАКСИМАЛЬНОГО сокращения записи.
Например, 2001:db8:0:0:0:0:2:1 должно сокращаться до 2001:db8::2:1.
Однако запись 2001:db8::0:1 неприемлема, так как символы «::» могут быть использованы более продуктивно, до вида 2001:db8::1.

4.2.2. Одно 16-битное поле с нулями в адресе.
НЕ СЛЕДУЕТ использовать символы «::» для сокращения только одного 16-битного поля с нулями. Например, такая запись является правильной, 2001:db8:0:1:1:1:1:1, а такая 2001:db8::1:1:1:1:1 НЕТ.

4.2.3. Где следует ставить символы «::»
В случае, если символы «::» можно поставить в нескольких местах, следует выбирать для замены самую длинную последовательность нулей, например — 2001:0:0:1:0:0:0:1 нужно записывать как 2001:0:0:1::1. В случае, если встретились две одинаковые по длине последовательности нулей, то нужно заменять первую, например , вместо 2001:db8:0:0:1:0:0:1 писать 2001:db8::1:0:0:1.

4.3. Регистр символов
Символы «a», «b», «c», «d», «e», и «f» в IPv6-адресах ДОЛЖНЫ быть в нижнем регистре.

5. Текстовое представление специальных видов адресов
Адреса вида IPv4-Mapped IPv6, ISATAP [RFC5214], и IPv4-транслируемые адреса [ADDR-FORMAT] содержат встроенный IPv4 адрес в последних 32 битах. Они могут быть представлены в смешанном шестнадцатиричном или десятичном (с точкой) формате. Для таких
адресов РЕКОМЕНДУЕТСЯ такое смешанное представление, при этом считается, что префикс известен.
Для старших бит следует использовать все, что изложено выше — то есть писать ::ffff:192.0.2.1, а не 0:0:0:0:0:ffff:192.0.2.1).

6. Обьединение адреса и номера порта
Существует много путей отображения адреса вместе с портом. Примеры приведены ниже:

  • [2001:db8::1]:80
  • 2001:db8::1:80
  • 2001:db8::1.80
  • 2001:db8::1 port 80
  • 2001:db8::1p80
  • 2001:db8::1#80

Это несильно отличается от IPv4, наибольшее отличие — в использовании символов во втором примере. Такая запись НЕ РЕКОМЕНДУЕТСЯ, следует использовать [] стиль. URI, содержащие IPv6 адрес, нужно записывать в соответствии с [RFC3986]

7. Запись префиксов
Префиксы следует записывать по тем же правилам, что и адреса.

8. Безопасность.
При работе с X.509-сертификатами рекомендуется сравнивать IPv6-адреса в двоичном виде.

10.1. Другая документация
[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate
Requirement Levels», BCP 14, RFC 2119, March 1997.
[RFC2765] Nordmark, E., «Stateless IP/ICMP Translation Algorithm
(SIIT)», RFC 2765, February 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
«Uniform Resource Identifier (URI): Generic Syntax»,
STD 66, RFC 3986, January 2005.
[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing
Architecture», RFC 4291, February 2006.

10.2. Вспомогательная документация
[ADDR-FORMAT] Bao, C., «IPv6 Addressing of IPv4/IPv6 Translators»,
Work in Progress, July 2010.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, «Application Aspects of IPv6 Transition»,
RFC 4038, March 2005.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, «Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)»,
RFC 5214, March 2008.

Приложение A. Для разработчиков
Разработчикам рекомендуется визуально проверять, как в их разработках отображается IPv6-адрес.
Автор: Seiichi Kawamura

01.09.2014

Итоги августа и первых восьми месяцев 2014г.

(бОльшая часть статистики и иллюстраций вынесены на отдельную страницу)

Наш IPv6-трафик остался на июльском уровне, то есть составил те же 0.011% от IPv4-трафика. Количество DNS-запросов, полученных по IPv6, немножко возросло, но не превысило 1%.

Количество IPv6-префиксов в «большой» таблице превысило 18,800, а от MSK-IX получаем чуть менее 1000 префиксов.

В логах данного сайта за месяц зафиксировано 222 уникальных IPv6-адреса /128 (177 уникальных по /64), то есть примерно 8 адресов в сутки.

 

01.08.2014

Итоги июля и первых семи месяцев 2014г.

(бОльшая часть статистики и иллюстраций вынесены на отдельную страницу)

Наш IPv6-трафик немного уменьшился и в июле составил 0.011% от IPv4-трафика. Количество DNS-запросов, полученных по IPv6, тоже несколько упало.

Количество IPv6-префиксов в «большой» таблице превысило 18,400, а от MSK-IX получаем около 1000 префиксов.

В логах данного сайта за месяц зафиксировано 225 уникальных IPv6-адресов /128 (192 уникальных по /64), то есть примерно 8 адресов в сутки.

01.07.2014

Итоги июня и первого полугодия 2014г.

(бОльшая часть статистики и иллюстраций вынесены на отдельную страницу)

Наш IPv6-трафик снова пошел вниз и в июне составил 0.012% от IPv4-трафика. А вот количество DNS-запросов, полученных по IPv6, немножко возросло, средний уровень таких запросов в течение последнего года составляет примерно 1%.

Количество IPv6-префиксов в «большой» таблице превысило 18,000, а MSK-IX вот-вот пересечет рубеж в 1000 префиксов. Ждем-с!

В логах данного сайта за месяц зафиксировано 270 уникальных IPv6-адресов /128 (227 уникальных по /64), то есть примерно 9 адресов в сутки.

Количество запросов, приходящих к Гуглу по IPv6, превысило 4%.