摘要

  • RIPE NCC报告称，86%的客户端支持其纯IPv6会议网络，IPv4流量通过NAT64转换。
  • 主会场仍有接入点丢弃邻居发现组播的问题，团队关闭三台接入点的无线电并启用六台额外AP，随后仍记录到少量问题。

主会场先关掉三台接入点的无线电，再启用六台额外AP。RIPE 93闭幕技术报告把这项处置和另一项数字放在同一份记录里：86%的客户端支持会议采用的纯IPv6网络。一个讲设备能力，一个记录现场补救，合在一起才是完整的运维成绩。

这次会议的网络覆盖五层楼。技术团队说内部布线正常工作。支持纯IPv6配置的客户端只拿到IPv6地址，需要访问IPv4流量时由NAT64转换。86%说明这种配置在参会设备中具有较广兼容性；服务质量还要看实际连接结果。

问题出现在NAT64之前。技术报告称，部分无线接入点会丢弃IPv6邻居发现使用的 solicited-node 组播报文。RFC 4861说明，设备不知道邻居的链路层地址时，会向目标对应的 solicited-node 组播地址发送Neighbor Solicitation，并等待应答。邻居发现完成后，客户端才会把后续流量送往NAT64转换。

团队说，最近几场RIPE会议也遇到过相同或类似问题。设备厂商此前称已经修复，RIPE人员仍在阿姆斯特丹办公室的同代接入点上观察到问题。团队在防火墙主机上运行NDP fixer；Menno Schepers说，这对被丢弃的组播有帮助。主会场的三台AP关闭了无线电，另外六台AP投入使用。侧厅和咖啡区没有出现相同现象。报告同时说明，调整后仍有一些小问题。

这是一份有用的运维记录，服务质量还需要另一组数据。“86%的客户端支持”描述设备能力。Schepers说主会场Wi-Fi“至少大多数时候”正常。转录稿没有客户端总数、分室连接结果和NAT64图表数列；补上这些记录才能判断86%的能力比例是否对应可靠服务，以及图中两个方向是否对得上。

另一条线索来自NAT64图表。问答环节中，有人指出两条流量线看起来过于对称，若它们分别代表进出流量就令人困惑。Schepers说两条线略有差异，并答应检查；会议主持人也说团队会调查。转录保留了这个质疑和团队检查图表的承诺。

RFC 6146描述了IPv6客户端访问IPv4服务器的NAT64机制，它处在网络路径的另一段。网关上的流量图显示已转换的流量；分室连接结果显示客户端是否顺利完成无线侧的邻居发现。带有方向标签的数列则能说明两条线的比较关系。

团队关闭无线电、增加接入点、部署防火墙绕行，并请参会者反馈问题，动作清楚而具体。闭幕报告若把现场结果与兼容比例并列，读者便能看见完整的运行成本：纯IPv6网络覆盖大多数客户端时，某个房间仍需要工程师维持在线。

一手材料：RIPE 93闭幕全会转录 · RIPE 93技术报告场次 · RFC 4861 · RFC 6146。