IPv6 单栈网络部署面临 IPv4 组播业务连续性难题。现有 DS-Lite、NAT64、MAP-E 等单播过渡机制若强行扩展至组播，将丧失核心网资源优化优势。RFC8114 定义了一种无状态转换算法，配合 mB4 与 mAFTR 功能实体，在保持 IP 组播收益的前提下，实现 IPv4 组播报文经 IPv6 组播网络透传至 IPv4 客户端。
核心机制：无状态地址映射与双模支持
RFC8114 采用无状态转换算法，同时兼容源特定组播（SSM）与任意源组播（ASM）两种模式。映射规则基于 IPv6 组播前缀（mPrefix64）与 IPv6 单播地址，将 IPv4 组播地址确定性转换为 IPv6 组播地址，无需维护每流状态表项。该算法在封装与解封装两端对称执行，保证转发路径上组播树结构不变，核心网仍按 IPv6 组播转发，资源优化特性完整保留。原文未给出具体映射算法细节与前缀长度数值。
功能实体：mB4 与 mAFTR 分工协作
mB4 部署于接入侧，承担 IGMP 与 MLD 互通职能：将客户端 IGMP 报文转译为 MLD 报文向上游 MLD Querier 发送，并在下行方向解封装 IPv4-in-IPv6 组播包还原为 IPv4 组播包。mAFTR 位于网络侧，作为 IPv4 组播源的 IPv6 映射实体，负责将接收到的 IPv4 组播包封装为 IPv4-in-IPv6 包，并以对应 IPv6 组播源身份注入 IPv6 组播网络（PIM 域）。两实体均无需维护每组播流状态，符合无状态设计原则。原文未给出部署拓扑位置与性能指标。
部署前提与协议栈要求
方案要求接入网侧终端保留 IPv4 协议栈以发送 IGMP 报文，接入网络设备需支持 MLD 与 PIM 协议构建 IPv6 组播转发平面。mB4 与 mAFTR 需在 IPv6 组播网络边界部署，且 IPv6 网络已启用 PIM。该架构不改变现有 IPv4 组播源与客户端协议行为，仅在网络层引入封装隧道。原文未给出具体硬件规格、软件版本要求或迁移步骤。
对运维工程师而言，RFC8114 提供了一条不依赖双栈、不牺牲组播效率的 IPv4 组播承载路径。在 IPv6 单栈骨干网已建成、接入侧仍需服务存量 IPv4 组播业务（如 IPTV、金融行情分发）的场景下，可按标准部署 mB4/mAFTR 对，避免维护双栈带来的地址规划与设备成本开销。
原文: APNIC Blog（2017-05-02）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog