Кратко

  • По сообщению RIPE NCC, IPv6-only-сеть с NAT64 для IPv4 поддерживали 86% клиентских устройств.
  • В главном зале команда выключила радиомодули трёх точек доступа, включила ещё шесть и всё же зафиксировала небольшие проблемы.

Три радиомодуля выключили. Шесть точек доступа добавили. Так выглядела инженерная сноска к более красивому показателю RIPE 93: 86% клиентских устройств поддерживали сеть только с IPv6. Процент описывает совместимость, перестройка сети — работу команды на площадке.

Сеть встречи в Софии проходила через пять этажей. Техническая команда сообщила, что внутренняя кабельная разводка работала штатно. Устройства в IPv6-only-сегменте получали только IPv6-адрес и использовали NAT64 для трафика к IPv4. Показатель в 86% подтверждает, что такая схема подошла большей части устройств.

Описанный сбой возникал раньше NAT64. Некоторые точки доступа продолжали отбрасывать solicited-node multicast, который IPv6 Neighbor Discovery использует для поиска канального адреса соседа. RFC 4861 описывает этот обмен: узел отправляет Neighbor Solicitation на solicited-node multicast-адрес целевого узла и ждёт ответа. После завершения обмена клиент передаёт трафик на NAT64 для перевода в IPv4.

Команда уже встречала тот же или похожий сбой на предыдущих встречах RIPE. Поставщик оборудования сообщил, что исправил проблему, однако сотрудники RIPE продолжали видеть её в амстердамском офисе на точках доступа того же поколения. На межсетевом экране запустили NDP fixer; Menno Schepers сказал, что это помогло с потерей multicast. В главном зале радиомодули трёх AP отключили и включили ещё шесть точек доступа. В боковой комнате и зоне кофе такого поведения не заметили. При этом небольшие проблемы, по словам докладчика, остались.

Это полезный технический отчёт; оценка качества требует отдельного ряда результатов. Формулировка «86% поддерживают эту схему» описывает возможности устройств. Schepers сказал, что Wi-Fi в главном зале работал нормально «по крайней мере большую часть времени». Стенограмма не указывает число устройств, результаты по помещениям и выгрузку графика NAT64; эти данные показали бы, превратилась ли заявленная совместимость в надёжный сервис и согласуются ли направления на графике.

Вопрос из зала поднял ещё одну тему измерения. Две линии NAT64-графика выглядели слишком симметрично, если это входящий и исходящий трафик. Schepers ответил, что линии немного различаются, и пообещал проверить; председатель сказал, что команда разберётся. Стенограмма сохраняет вопрос и обещание проверить график.

RFC 6146 описывает NAT64 как механизм связи IPv6-клиентов с IPv4-серверами. Он работает в другой точке пути, чем беспроводной Neighbor Discovery. График на шлюзе показывает переведённые пакеты; результаты по помещениям показывают, разрешили ли клиенты адрес соседа по Wi-Fi. Подписи направлений помогают понять сравнение двух линий.

Команда изменила радиопокрытие, включила дополнительные точки доступа, поставила обходное решение и попросила участников сообщать о проблемах. Финальный отчёт показывает совместимость рядом с результатами эксплуатации: сеть прошла тест IPv6-only для большинства устройств, а Wi-Fi в одном зале всё ещё поддерживал инженер.

Первичные источники: стенограмма заключительного пленарного заседания RIPE 93 · сессия технического отчёта RIPE 93 · RFC 4861 · RFC 6146.