Summary

  • RIPE NCC said 86% of clients supported its IPv6-only meeting network, which used NAT64 to reach IPv4 traffic.
  • The team still disabled three access-point radios in the main room, enabled six extra access points and reported some remaining Wi-Fi issues.

Three access-point radios went dark so an IPv6-only meeting network could keep working. RIPE NCC’s closing report paired that workaround with a strong headline number: 86% of clients supported the setup. The percentage measures device capability; the radio change records the operating work behind the service.

At RIPE 93 in Sofia, the network covered five floors. The tech team said the internal cabling worked as expected. Clients in the IPv6-only group received an IPv6 address and used NAT64 for IPv4 traffic. The 86% figure shows that a large share of devices could use this path.

The access-point problem sat below NAT64. RIPE’s team said some APs kept dropping solicited-node multicast, the IPv6 Neighbor Discovery traffic used to resolve a nearby device’s link-layer address. RFC 4861 describes that exchange: a node sends a Neighbor Solicitation to the target’s solicited-node multicast address and waits for an advertisement. When this exchange completes, the client can send traffic onward to NAT64 for translation.

The fault already had a history: RIPE meetings had seen similar drops. A vendor said it had fixed them, while RIPE staff still saw the same symptoms at its Amsterdam office on a different model from the same generation. At RIPE 93, the team ran an NDP fixer on the firewall; Schepers said it helped with the dropped multicast. In the main room, staff then switched off the radios on three APs and enabled six additional ones. The side room and coffee area did not show the same pattern. Even after the change, the report said some small issues remained.

The report gives an engineering account; service quality needs a second set of figures. “86% support this” describes client capability. Schepers said the main room worked properly “at least most of the time.” The transcript omits the client count, per-room connection results and NAT64 graph data; a dated record of those values would show whether the capability share became dependable service and whether the plotted directions reconcile.

The graph review raised a second measurement question. During Q&A, an attendee asked why the two NAT64 traffic lines looked symmetrical if they represented traffic in and out. Schepers said they were slightly different and agreed to look; the chair said the team would investigate. The transcript preserves the challenge and the team’s commitment to check the graph.

Stateful NAT64 connects IPv6 clients to IPv4 servers; it sits at a different point in the path from Wi-Fi multicast and Neighbor Discovery. A dashboard of translated traffic shows activity at the gateway. Room-level connection results show whether clients reached it cleanly, and labelled graph directions let readers check what the two lines compare.

RIPE 93’s team moved radios, added coverage, installed a workaround and asked attendees to report faults. The report also shows why operational success deserves more than a compatibility percentage. A network can pass the IPv6-only test while a technician keeps one room online.

Primary records: RIPE 93 Closing Plenary transcript · RIPE 93 Tech Report session · RFC 4861 · RFC 6146.