跳到主要内容

4. Deployment Scenarios (部署场景)

4. Deployment Scenarios (部署场景)

4.1 Access Model (接入模型)

Dual-Stack Lite 模型并非依赖级联 NAT, 而是建立在 IPv4-in-IPv6 隧道之上, 穿越网络到达运营商级 IPv4-IPv4 NAT (即 AFTR), 客户在其中共享 IPv4 地址. 该做法带来若干好处:

  • 该技术将服务提供商网络中 (直至客户驻地设备或 CPE) 的 IPv6 部署与全球互联网及客户应用与设备中的 IPv6 部署解耦.

  • 通过利用庞大的 IPv6 地址空间, 服务提供商接入网络的管理得以简化. 为支持极大规模客户群, 不再需要使用重叠的私有 IPv4 地址空间.

  • 由于隧道可在服务提供商网络中的任意位置终结, 该架构适合水平扩展, 并具有一定灵活性以适应变化的业务负载. 关于水平扩展的更多讨论见附录 A.

  • 隧道在 B4 与 AFTR 之间提供直连. 这可用来使客户及其应用能够控制 AFTR 的 NAT 功能如何执行.

该方法的一个关键特征是, 端节点之间的通信保持在各自的地址族内. IPv6 源仅与 IPv6 目的通信, IPv4 源仅与 IPv4 目的通信. 该方法不涉及协议族之间的转换 (translation). 这大大简化了可能在载荷中携带字面 IP 地址的应用所面临的任务.

4.2 CPE (用户驻地设备)

本节描述以家庭网关或 CPE 为特征的家庭局域网 (Local Area Network, LAN), 该 CPE 由服务提供商仅配置 IPv6.

DS-Lite CPE 是一种支持 IPv6 的 CPE, 在其 WAN 接口上实现了 B4 接口.

DS-Lite CPE 不应该在内部接口与 B4 接口之间运行 NAT 功能, 因为 NAT 功能将由服务提供商网络中的 AFTR 执行. 这将避免意外处于双重 NAT (double-NAT) 环境.

然而, 它应该运行自己的 DHCP(v4) 服务器, 向家庭中的主机分配 RFC 1918 地址空间 (例如 192.168.0.0/16). 它应该向这些家庭主机通告自身为默认 IPv4 路由器. 它还应该在 DHCP Option 6 (DNS Server) 中通告自身为 DNS 服务器. 此外, 它应该运行 DNS 代理 (DNS proxy), 接受来自家庭主机的 DNS IPv4 请求并通过 IPv6 将其发送到服务提供商 DNS 服务器, 如第 5.5 节所述.

注意: 若某 IPv4 家庭主机决定使用另一 IPv4 DNS 服务器, DS-Lite CPE 将通过 B4 接口转发这些 DNS 请求, 与其转发任何常规 IPv4 分组的方式相同. 然而, 每个 DNS 请求都会在 AFTR 中创建一条绑定. 大量 DNS 请求可能直接影响 AFTR 的 NAT 表利用率.

支持 IPv6 的设备直接到达 IPv6 互联网. 分组仅遵循 IPv6 路由, 不经过隧道, 也不受任何转换影响. 预期大多数支持 IPv6 的设备也将支持 IPv4, 并将在家庭网络内仅配置 IPv4 RFC 1918 风格地址, 与家庭内的传统仅 IPv4 设备以相同方式访问 IPv4 互联网.

纯 IPv6-only 设备 (即不包含 IPv4 协议栈的设备) 不在本文档范围之内.

4.3 Directly Connected Device (直连设备)

在宽带家庭网络中, 某些设备直接连接到宽带服务提供商. 它们直接连接到调制解调器, 而不经过家庭网关. 这些设备实际上充当 CPE.

在此场景下, 客户设备是一台由服务提供商仅配置 IPv6 的具备双栈能力的主机. 设备自身充当 B4 元素, IPv4 业务通过 IPv4-in-IPv6 隧道提供, 与家庭网关/CPE 情形相同. 该设备可运行 IPv4 和/或 IPv6 应用的任意组合.

直连的 DS-Lite 设备应该通过 IPv6 向其已配置的 IPv6 DNS 服务器发送 DNS 请求.

与前几节类似, IPv6 分组遵循 IPv6 路由, 不经过隧道, 也不受任何转换影响.

本文档不涵盖此场景下对仅 IPv4 设备与仅 IPv6 设备的支持.