Записи с меткой «ipv6»

ЭВМ/ IPv6 для Linode в Лондоне

21.12.2011

С пол года назад Linode объявила о настоящей поддержке IPv6 для своих виртуальных машин. До этого энтузиасты вроде меня использовали различные туннели. Однако, для большинства пользователей из России эта новость оказалась чуть менее чем полностью бесполезной, так как IPv6 заработал только для американских дата-центров, а наши люди в основном размещают свои машины в Лондоне, чтобы время отклика было поменьше.

И вот на днях IPv6 появился и для лондонских машин! Чтобы его включить, достаточно во вкладке «Remote Access» нажать на «Enable IPv6», после чего перезагрузить машину. Понятно, что, строго говоря, перезагрузка не является технически необходимой, но, видимо, ребятам из Linode так проще, простим им это. «Непорядок» уже работает на новом IPv6 адресе.

Кстати, в панели управления появилось много других новых штук, в частности ядро Linux 3.0, так что тоже обязательно посмотрите.

,

ЭВМ/ Новости IPv6 от HE

13.11.2011

Hurricane Electric сообщает, что среди 39570 сетей в мире, использующих BGP, IPv6 сейчас используют 4830 или 12,2%. Год назад было 7,4%, пол года назад – 9,5%. Глобальная таблица маршрутизации IPv6 перешагнула рубеж в 7000 префиксов. Подробный отчет.

,

ЭВМ/ День IPv6

03.02.2011

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

ЭВМ/ Футболка для мудреца

09.09.2010

Вчера смотрю в почтовый ящик, а там извещение о посылке, международной. Странно, подумал я, я ничего такого не жду, все посылки с eBay уже давно пришли. Пошел на почту, получил небольшую коробочку. Обратный адрес незнакомый, американский. Открываю, а там…

Да, это она, футболка сертифицированного IPv6 мудреца! Честно говоря, я про нее уже и забыл, решив, что he.net передумал их рассылать. Однако ж нет, пришла родимая. Будет теперь в чем щеголять на конференциях.

, ,

ЭВМ/ Недолго музыка играла

25.08.2010

Моего прекрасного местечкового провайдера поглотил Netbynet, после чего у меня отвалился IPv6. Причем внешний IPv6 интерфейс моего маршрутизатора все еще виден из мира, но пропала маршрутизация моей домашней сети, которую в свое время мне любезно предоставили. Хамоватый мальчик с первой линии техподдержки NBN пояснил, что IPv6 у них нет и быть не может. Бывший инженер моего бывшего провайдера, с которым удалось связаться, также сказал, что уже ничем не может помочь. Такие дела.

,

ЭВМ/ IPv6 мудрец

31.05.2010

Получил тут письмо от he.net (он же tunnelbroker.net), в котором, помимо прочих новостей, сообщалось, что они решили выслать футболки всем, кто получил высший статус Sage (мудрец) в их программе бесплатной IPv6 сертификации. Эту сертификацию я у них и раньше видел, когда регистрировал 6in4 туннель, но тогда пренебрежительно прошел мимо. Бесплатная футболка же сильно меняет дело, под таким соусом можно и сертифицироваться.

Процесс сертификации несложный, нужно ответить  на пару десятков вопросов и сделать несколько практических шагов: настроить в собственном домене веб-сервер, почту и DNS для доступа по IPv6. Однако выполнение этих шагов позволит достичь только уровня Guru. Чтобы перейти на последний уровень Sage, нужно, чтобы в информации о домене, который ты администрируешь, присутствовали IPv6 «glue» записи. Эти записи заводятся у регистратора домена и хранятся на серверах домена первого уровня. И вот тут наступает облом: в зоне .ru IPv6 glue записи не поддерживаются.

В расстройстве я решил пошарить, вдруг где можно зарегистрировать домен ненадолго в приличной зоне и у приличного регистратора, чтобы нужные мне «приклеенные» записи поддерживались. Зашел на GoDaddy и обнаружил там распродажу доменов в зоне .info по $1. Без промедления приобрел домен ipv6sage.info, настроил на нем все необходимые для сертификации сервисы (кстати это «чистый» IPv6 домен, все его сервисы, включая пресловутые glue records, доступны только по IPv6) и за пару минут получил статус Sage.

IPv6 Certification Badge for ipv6sage

Осталось дождаться футболку, обещали выслать в конце июня.

,

ЭВМ/ непорядок v6

12.05.2010

Рад сообщить, что «непорядок» теперь доступен по IPv6. Те, кто используют IPv6, увидят маленький синий значок «v6» рядом с названием сайта.

К сожалению Linode не предоставляет собственной IPv6 связности, но дает подробные инструкции, как получить оную через туннель от Hurricane Electric, он же Tunnel Broker. Ширина полосы в бесплатном туннеле конечно регулируется, но на времени отклика это никак не сказывается. Одна из точек присутствия Hurricane Electric находится в Лондоне, там же расположен ДЦ Linode, где у меня VPS. Поэтому вход в туннель оказывается очень близко:

li153-251:~# ip link show 6in4
11: 6in4@NONE:
 mtu 1280 qdisc noqueue state UNKNOWN
    link/sit 0.0.0.0 peer 216.66.80.26
li153-251:~# traceroute 216.66.80.26
traceroute to 216.66.80.26 (216.66.80.26), 30 hops max, 40 byte packets
 1  109.74.192.2 (109.74.192.2)  0.437 ms  0.462 ms  0.526 ms
 2  te3-1-border76-01.lon2.telecity.net (217.20.44.217)  0.744 ms * *
 3  217.20.44.194 (217.20.44.194)  0.687 ms * *
 4  10gigabitethernet1-1.core1.lon1.he.net (195.66.224.21)  8.024 ms  7.974 ms  7.829 ms
 5  tserv5.lon1.ipv6.he.net (216.66.80.26)  0.938 ms  0.779 ms  0.812 ms
li153-251:~# ping -c3 216.66.80.26
PING 216.66.80.26 (216.66.80.26) 56(84) bytes of data.
64 bytes from 216.66.80.26: icmp_seq=1 ttl=60 time=1.02 ms
64 bytes from 216.66.80.26: icmp_seq=2 ttl=60 time=3.39 ms
64 bytes from 216.66.80.26: icmp_seq=3 ttl=60 time=2.98 ms

--- 216.66.80.26 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 1.021/2.466/3.398/1.036 ms

Непосредственная связность с внешним миром тоже очень хорошая, наличие туннеля совсем незаметно:

li153-251:~# ping6 -c3 ipv6.google.com
PING ipv6.google.com(2a00:1450:8006::68) 56 data bytes
64 bytes from 2a00:1450:8006::68: icmp_seq=1 ttl=57 time=8.25 ms
64 bytes from 2a00:1450:8006::68: icmp_seq=2 ttl=57 time=8.35 ms
64 bytes from 2a00:1450:8006::68: icmp_seq=3 ttl=57 time=8.75 ms

--- ipv6.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 8.259/8.458/8.758/0.240 ms

Для того, чтобы nginx начал обрабатывать IPv6 запросы, пришлось обновить его до версии 0.7.65. В стандартном репозитории Debian Lenny есть только версия 0.6.32, поэтому пришлось подключить репозиторий Backports и ставить из него.

Еще один интересный момент связан с конфигурацией. nginx по умолчанию открывает порт только для IPv4 соединений, это задает директива listen в файле /etc/nginx/sites-available/default:

listen 80 default;

Чтобы принимать IPv6 соединения, нужно добавить еще одну директиву listen для IPv6:

listen [::] default;

Специальный адрес [::] является так называемым wildcard и означает «все IPv6 адреса». Однако с такой конфигурацией nginx не запускается и выдает ошибку:

[emerg]: bind() to [::]:80 failed (98: Address already in use)

Дело в том, что в IPv6 существует такое понятие как IPv4-mapped адрес. Суть его в том, что пространство IPv4 адресов отображается в пространство IPv6 адресов с помощью специального префикса ::ffff. Сделано это, видимо, для облегчения процесса перехода на новый протокол. Покойный itojun говорил, что это возможность является потенциальной дырой в безопасности, поэтому, например, в OpenBSD она отключена. В других системах, более терпимых к дырам, наличие этой возможности контролируется специальным параметром для сокетов IPV6_V6ONLY. И в Linux по умолчанию IPv4-mapped адреса включены. Это приводит к тому, что вызов bind(2) с IPv6 wildcard в качестве адреса пытается помимо IPv6 адресов захватить и IPv4 адреса, которые уже заняты предыдущей директивой listen. Чтобы решить проблему, необходимо отключить IPv4-mapped адреса с помощью параметра ipv6only в конфиге nginx:

listen [::] default ipv6only=on;
, , , , ,

OpenBSD/ RFC4941

07.04.2010

В OpenBSD появилась поддержка RFC4941 — «Privacy Extensions for Stateless Address Autoconfiguration in IPv6». Как известно, при stateless автоконфигурации сетевого интерфейса его IPv6 адрес формируется из MAC адреса, при этом в разных сетях эта часть адреса всегда будет одинаковой. Таким образом можно отследить перемещение мобильных устройств, и, как следствие, их владельцев. Данное расширение устраняет эту проблему, используя случайный идентификатор для формирования IPv6 адреса. Пользоваться так:

# ifconfig ral0 autoconfprivacy

Или так:

# cat /etc/hostname.ral0
dhcp
inet6 autoconfprivacy
rtsol

ЭВМ/ IPv6 в массы addenum

17.03.2010

После того, как все было настроено, я подумал, что моя конфигурация не такая уж редкая. Сейчас уже у многих людей есть пластмассовые китайские WiFi-маршрутизаторы, и часть этих людей хотела бы иметь больше одного «белого» IPv6 адреса, чтобы не возиться с пробросом портов. Что же им, писать заявки на выделение префикса в техподдержку и настраивать все вручную?

Нет, все оказалось проще. В протоколе DHCPv6 предусмотрена возможность не только выдавать один адрес, но и делегировать целый префикс. Таким образом получается следующая схема прихода IPv6 в массы. Обычные люди через stateless автоконфигурацию получают по одному IPv6 адресу. Те, кто хочет больше одного адреса, покупают услугу «IPv6 префикс», как сейчас многие покупают «статический IP адрес». Купившим эту услугу DHCPv6 сервер провайдера делегирует префикс, не забывая конечно добавить у себя соответствующий маршрут.

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

Кстати, как мне кажется, движущей силой прихода IPv6 в массы должны стать различные P2P сети типа BitTorrent. В этих сетях генерируется огромное количество трафика (а именно рост IPv6 трафика будет стимулировать операторов связи к переходу на новый протокол), и остро стоит проблема «белых» IP адресов.

ЭВМ/ IPv6 в массы

16.03.2010

Я живу в небольшом городе в так называемом «ближнем» Подмосковье, это примерно в 10 км от МКАД. В городе есть несколько Интернет-провайдеров, все они предоставляют доступ в Интернет через локальные городские сети. К одному из них подключен и я.

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

Условия просто отличные: прямой пиринг с вышестоящими провайдерами (то есть никаких дурацких туннелей) и — тадам! — бесплатный нелимитированный трафик. Понятное дело, я сразу взялся поднять у себя это дело.

И тут возник вопрос. Основным преимуществом IPv6 перед IPv4 является не просто большое, а гигантское адресное пространство, адреса в IPv6 могут закончиться только если земной Интернет распространится и в другие галактики. При такой прорве адресов логично, если все мои машины в квартире получат по «белому» IPv6 адресу. Однако у провайдера IPv6 настроен очень просто и без затей: в локальную сеть раздаются адреса из /64 префикса через stateless автоконфигурацию. Таким образом мой маршрутизатор может получить один адрес на своем внешнем интерфейсе, а все внутренние сети придется по прежнему пропускать через NAT.

Чтобы избавиться от NAT нужно получить не просто адрес, а сеть. Я написал письмо в техподдержку с вопросом о возможности такой процедуры, но ответа не получил. Я написал еще раз, добавив в копию адрес noc@. Оказалось, что такого адреса нет, и снова письмо осталось без ответа. И тогда я решил действовать самостоятельно.

Из префикса /64 можно абсолютно безболезненно вырезать себе необходимый кусок. Дело в том, что при автоконфигурации IPv6 адреса в этом префиксе генерируются на базе MAC-адресов клиентов. Таким образом, подобрав заведомо несуществующий блок MAC-адресов, можно выделить себе нужный подпрефикс.

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

Первая проблема решается так же, как и в мире IPv4 — через ARP-прокси. Только вместо ARP в IPv6 используется NDP — Neighbor Discovery Protocol. Для управления этим протоколом в OpenBSD существует утилита ndp(8). Вторую проблему можно решить довольно неожиданным способом. В IPv6 каждый сетевой интерфейс имеет так называемый link-local адрес. Этот адрес имеет смысл только внутри локального сегмента сети и не маршрутизируется. Понятно, что и внешний интерфейс моего маршрутизатора, и внутренний интерфейс маршрутизатора провайдера имеют по такому адресу, и эти адреса находятся в одной сети.

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

Итак, городить огород не пришлось, чему я очень рад. Дальше все было просто. В силу того, что выдали мне префикс /64, раздавать на внутренних интерфейсах я мог только более узкие сети, например /80. Для таких сетей простая stateless автоконфигурация не работает, нужно поднимать DHCPv6. Для этого был поставлен из портов и настроен WIDE-DHCPv6. Кроме того был поднят rtadvd(8), который выдавал маршрут по умолчанию и флаг «Other statefull configuration», сообщающий клиентам, что адреса необходимо получать по DHCP.

После этого все отлично заработало как на лаптопе с OpenBSD, так и на десктопе с Windows 7. Замеры скорости приятно удивили: 12-13 Мбит/сек. Еще один приятный сюрприз: сервисы Google, в том числе YouTube, оказались доступны по IPv6. Дело в том, что Google не дает IPv6 адреса своих сервисов всем подряд. Чтобы получить доступ, провайдер должен связаться с Google, доказать, что предоставляет IPv6 связность хорошего качества, и тогда Google вносит рекурсивные DNS серверы провайдера в «белый» список, разрешая им резолвить имена своих сервисов в IPv6 адреса. Видимо, мой провайдер всю эту процедуру прошел.