企业官网建设流程全解析

做城域网的朋友，这两年见面聊得最多的就是IPv6过渡。公网IPv4地址早就枯竭，可还有一大堆存量业务和终端只认IPv4，双栈又扛不住地址和运维压力。于是各种过渡技术来回比选，DS-Lite、NAT64、6rd听了一圈，最后发现MAP技术往往是城域网场景里最绕不开的那个选项。这篇自由谈就把MAP技术拆开聊透，分上下两讲，这第一讲重点讲原理、定位和落地要点，适合运营商网络工程师、企业网网工，以及做家宽和专线接入方案的人参考。

1. 为什么城域网过渡绕不开MAP

1.1 IPv6过渡问题的本质

很多人把IPv6过渡理解成“把协议版本从v4改到v6”，真上手就知道完全不是这么回事。过渡期的尴尬在于：公网IPv4地址不够分，IPv6地址倒是充足，可存量终端、旧应用、部分海外服务器还是只有IPv4。运营商不可能把一个地区的用户全部强制切成IPv6单栈，因为切了以后很多业务直接不能用，代价太大。

所以过渡技术解决的不是“替换协议”，而是“怎么在IPv6网络里继续跑IPv4流量”。双栈（Dual Stack）是最简单粗暴的答案，给每个用户同时分配IPv4和IPv6地址，让用户自己选路。可双栈的问题也明显：IPv4地址还是不够，运维要同时维护两套路由和地址分配策略，费用翻倍，而且IPv4地址枯竭问题一点没解决。

MAP技术走的是另一条路：把IPv4地址和端口资源“塞进”IPv6地址里，让CE（用户侧设备）在IPv6-only网络上“模拟”出一套可用的IPv4连接能力。这样骨干网跑IPv6，用户侧存量IPv4应用还能继续用，公网IPv4地址也能用共享方式大幅节省。

1.2 过渡技术家族里的关键位置

IPv6过渡技术其实分了好几条线，我习惯把常见方案归成三类：

• 隧道类：IPv6流量封装进IPv4隧道，典型代表是6rd，解决的是“只有IPv4网络的时候怎么提供IPv6”，严格说是IPv6接入技术，不是IPv4过渡技术。
• 翻译类：在IPv4和IPv6之间做协议转换，典型代表是NAT64、464XLAT，解决“IPv6-only终端访问IPv4-only服务器”的问题。
• 地址嵌入共享类：把IPv4地址片段和端口集编码进IPv6地址，典型代表就是MAP、DS-Lite。其中DS-Lite引入集中式NAT状态，MAP则尽量保持无状态。

MAP实际包含两种变体：MAP-E（Mapping of Address and Port with Encapsulation）和MAP-T（Mapping of Address and Port with Translation）。MAP-E把整个IPv4报文封装到IPv6头里，MAP-T则是把IPv4报文翻译成IPv6报文再传输。两者原理接近，差异主要体现在封装还是翻译，后文会专门拆。

1.3 为什么大网场景更偏爱MAP

城域网和IDC组网不太一样，最大的特点是CE数量巨大、流量模型分散。一个省网可能有几百万个宽带用户，如果靠DS-Lite那种集中式AFTR做NAT，核心设备要维护几百万条会话状态，扩容成本、故障恢复成本都非常高。

MAP把状态尽量推到边缘。BR（Border Relay，边界中继）在IPv6域边缘做无状态转发，不用记录每个用户“当前占用了哪个端口、哪条会话”；CE侧自己根据算法从IPv6地址里还原出IPv4共享地址和端口集，自己管理内部主机的端口映射。对运营商来说，BR就是一台“无状态路由器”，负载分担和高可用都简单很多。这也是MAP在省网、城域网这类超大规模场景中被频繁讨论的重要原因。

2. MAP技术核心原理拆解

2.1 MAP-E和MAP-T：一个封装，一个翻译

MAP-E的全称是Mapping of Address and Port with Encapsulation，核心动作是“IPv4报文外面套一个IPv6头”。CE从家庭主机收到IPv4报文后，按照MAP规则把IPv4报文整个放进IPv6 payload，然后发往IPv6骨干网。BR收到后，剥掉IPv6头，拿到里面的IPv4报文，再转发到IPv4网络。回程方向反过来。

MAP-T的全称是Mapping of Address and Port with Translation，核心动作是“把IPv4报文翻译成IPv6报文”。CE收到IPv4报文后，把IPv4头里的地址、端口等信息映射到IPv6头对应的字段中，翻译成IPv6报文后在IPv6域里传输。BR收到后，再把IPv6报文翻译回IPv4报文，送去IPv4网络。这里注意，MAP-T不是隧道，IPv4报文在IPv6网络里是以“IPv6报文”的形式传输的，整体开销比MAP-E更小，但是对IPv4头的转换处理要求更高。

MAP-E的好处是IPv4报文的语义被完整保留，遇到分片、校验和问题的时候好排查。MAP-T的好处是不引入额外的IPv6封装长度，适合那些希望骨干网“纯IPv6化”的运营商。中移动、中电信有些场景偏好MAP-T，部分海外运营商则偏好MAP-E，这没有绝对优劣，主要看现网运维习惯和承载网设备转发能力。

2.2 关键角色：BR、CE、PSID

MAP域里三个关键角色，从网络规划第一天就得理清楚：

• CE：用户侧设备，可能是家庭网关、企业CPE，也可能是BRAS/OLT后面的用户网关。它负责从MAP规则里“解析”出自己的IPv4地址和端口集，并作为IPv6网络里的一个普通IPv6节点工作。
• BR：IPv6域和IPv4域之间的边界节点。它不用维护每个CE的会话状态，只需要根据MAP规则，把去往IPv4网络的流量从IPv6报文里解封装/翻译出来，再把IPv4回程流量“翻译/封装”回IPv6域。BR是无状态的，这是MAP能在超大规模网络里存活的重要原因。
• PSID：Port Set Identifier，端口集标识。这是MAP最核心的概念。一个公网IPv4地址可以被多个用户共享，每个用户分到一组端口范围，PSID就是用来区分不同用户的“端口子集编号”。

打个比方，一个公网IPv4地址相当于一栋大楼的地址，PSID相当于楼里的楼层号。多户人家共用同一个门牌号，但各家住在不同楼层，快递员靠楼层号区分。MAP的BR拿到一个IPv4报文后，根据IPv6地址里嵌入的PSID，就知道这个报文属于哪个用户，不容易串流量。

2.3 地址和端口映射算法

MAP的地址映射不是“随机分配”，而是通过算法从IPv6地址直接推导出IPv4共享地址和端口集。每一条MAP规则（Rule）里至少包含：

• IPv6前缀：MAP域的IPv6地址块，比如2001:db8:100::/40。
• IPv4前缀：被共享的IPv4地址块，比如203.0.113.0/24。
• PSID长度和偏移：决定端口集大小和端口范围对齐方式。

CE根据自己分到的IPv6地址，用规则里的IPv4前缀和PSID位置，反推出自己的共享IPv4地址和端口集合。比如PSID长度取8位（p=8），偏移a取0时，一个用户拿到的端口范围就是连续的256个端口，比如1024~1279。如果偏移a取6，端口范围就不是连续整段，而是每隔64个端口取一段，这种设计是为了兼容某些只能识别特定端口对齐的应用。

这个算法是整个MAP技术的地基。配置MAP域的时候，IPv4前缀、IPv6前缀、PSID长度、偏移四者必须严格匹配，任何一个参数不对，CE和BR算出来的端口集就对不上，用户上网就断断续续。我在实际开局中见过好几次“配置看着没问题，但PSID偏移两边不一致”，最后抓包发现BR把流量送到了错误的CE，就是这个原因。

2.4 为什么MAP能保留“公网入站”能力

DS-Lite被家宽用户吐槽最多的点，是用户侧做了NAT后无法自建服务。用户在自己的服务器上跑了个Web服务，想让外网通过IPv4访问，结果地址是运营商CGN分配的私网地址，外网根本找不到你。这个问题在MAP场景下基本不存在。

MAP下的CE虽然也是和别人共享一个公网IPv4地址，但这个共享地址和端口集是“公网语义”的。只要用户在CE上把某个端口映射给内网主机，外网通过共享IPv4地址加对应端口访问时，BR会把流量正确送到用户的CE，CE再根据端口转发给内网主机。因为BR无状态、CE能看到完整的公网地址和端口集，所以入站连接是可实现的。

这就是很多做物联网、远程视频监控、PS5远程串流的用户，在IPv6过渡方案里更偏爱MAP的原因。PS5映射公网IPv6地址是一回事，可还有很多老设备只支持IPv4，这时MAP能提供的“可入站IPv4端口映射”就很香。

3. 从规划到落地：MAP的实操要点

3.1 网络拓扑与角色划分

MAP域落地前，先把拓扑明确下来。城域网里典型组法是：BR部署在省干/城域核心路由器旁，CE则部署在用户侧BRAS/OLT后面，或者直接集成进家庭网关。BR的IPv6侧接入城域IPv6骨干，IPv4侧接Internet出口或运营商IPv4骨干；CE的IPv6侧接IPv6承载网，IPv4侧接用户局域网。

规划阶段必须敲定两个东西：IPv4共享前缀和IPv6 MAP前缀。IPv4前缀最好选一整段连续地址，比如某个公网IPv4/24段，专门用于MAP共享；IPv6前缀根据用户规模选，BR和CE都要在这段里面分配地址。我建议规划时先画一张表，把“IPv4前缀、IPv6前缀、PSID长度、偏移、预期用户数、每个用户的端口数”算清楚，再进设备配置，否则容易边配边乱。

3.2 CE侧配置要点

CE侧要做的核心事情有三个：让IPv6先通，拿到IPv6前缀，然后配置MAP规则。

先保证IPv6通。如果是家庭网关/CPE，WAN口要设置为Native IPv6或者PPPoE/IPoE带IPv6，确保能从运营商侧获取IPv6地址和前缀。如果是BRAS下挂，BRAS需要开启DHCPv6-PD功能，给CE下发可用于内网分配的IPv6前缀。经常有人问我“有IPv6地址但是不能使用”，十有八九是RA通告没开、DHCPv6-PD没下发，或者防火墙禁了ICMPv6，排障顺序一般先看这三样。

MAP规则配置各家厂商命令不同，逻辑一致。我以一个通用配置风格示意，不要直接照抄到生产环境：

# 定义MAP域 map domain 1 rule 1 ipv6-prefix 2001:db8:100::/40 rule 1 ipv4-prefix 203.0.113.0/24 rule 1 psid-length 8 offset 0 # 在WAN接口启用MAP-E interface GigabitEthernet0/0/1 ipv6 enable ipv6 address 2001:db8:100:1::2/64 map enable domain 1

配置完以后，CE会基于这个IPv6地址自动计算出自己的IPv4共享地址和可用端口集。可以在设备上执行类似display map info的命令查看，确认计算出的IPv4地址和端口范围符合预期。

3.3 BR侧配置要点

BR侧同样要配置MAP域规则，但角色是边界中继。BR必须有一个IPv6侧接口接MAP域，一个IPv4侧接口接IPv4网络。IPv6侧接口地址一般作为BR地址，CE会把去往IPv4的流量发送到这个BR地址。

BR配置示意如下，同样是通用风格：

map domain 1 rule 1 ipv6-prefix 2001:db8:100::/40 rule 1 ipv4-prefix 203.0.113.0/24 rule 1 psid-length 8 offset 0 interface GigabitEthernet0/0/0 ipv6 enable ipv6 address 2001:db8:100:ffff::1/64 map enable domain 1 interface GigabitEthernet0/0/1 ip address 198.51.100.1/30

注意BR和CE的MAP域规则必须完全一致。BR本身不需要为每个CE建立会话，它只根据规则把IPv6报文中的IPv4信息解析出来就行。检查配置时，在BR上确认“无状态会话计数”不超过设备资源限制，通常这类转发是硬件线速处理的。

3.4 双栈域、DHCPv6-PD和地址分配注意事项

MAP落地过程中，有几个和“双栈”经常一起出现的问题值得提醒。

第一个是DNS双栈问题。很多时候终端同时有IPv4和IPv6地址，DNS返回了AAAA记录，但IPv6路由质量很差，结果就是浏览器卡顿、连接超时。很多用户抓狂地问“为什么开了IPv6以后网速变慢”，本质是IPv6链路质量或前缀策略问题。Windows下可以用netsh interface ipv6 show prefixpolicies查看前缀优先级，排障时临时调整策略，把IPv4优先级调高，可以快速验证是不是IPv6链路的问题。公共DNS建议用支持IPv6的地址，比如腾讯的2402:4e00::，但前提是你的IPv6承载质量要过关。

第二个是DHCPv6-PD和前缀分配。光猫、CPE、BRAS之间要配合好。以常见的移动光猫场景为例，光猫要开启IPv6和DHCPv6-PD，BRAS要允许向下分配前缀，CPE的WAN口设置成“DHCPv6-PD获取前缀”，这样内网设备才能拿到可用的全球单播IPv6地址。很多“有IPv6地址但不能用”的问题，就是前缀下发链路没打通，一半设备有v6地址，但路由根本不通。

第三个是业务系统监听IPv6地址的问题。比如SpringBoot服务要连接IPv6地址的Redis，配置里地址要写带中括号的IPv6格式，比如redis://[240e:xxx:xxx::1]:6379。很多开发兄弟第一反应是“为什么连不上”，查来查去才发现是配置解析问题。

3.5 MAP落地常见问题速查表

下面这个表是我在实际现场和测试环境里经常遇到的，贴出来供参考：

4. 和其他过渡技术对比：MAP到底强在哪

4.1 MAP和DS-Lite：一个无状态一个有状态

DS-Lite和MAP都实现了“多个用户共享一个公网IPv4地址”，但实现路径不同。DS-Lite用户侧CE把IPv4报文封装进IPv6隧道，送到运营商侧的AFTR（Address Family Transition Router），由AFTR统一做NAT和端口复用。AFTR必须维护每个用户的NAT会话表，用户量一大，AFTR压力非常大，而且单点故障影响面广。

MAP把端口集分配提前固化到了IPv6地址里，BR不需要记录任何会话。从扩展性上说，MAP比DS-Lite高一个量级。DS-Lite的优势是部署简单、对CE要求低，早期很多存量CPE不支持MAP，DS-Lite更现实。但从省网规模看，MAP更好，因为BR无状态意味着可以做简单的负载均衡和跨设备冗余。

4.2 MAP和6rd：想解决的问题不一样

6rd是IPv6 over IPv4隧道技术，主要目标是让只有IPv4网络的用户也能拿到IPv6地址。CE通过IPv4隧道连接到6rd BR，BR把IPv6流量接入IPv6网络。它解决的是“在IPv4网络里提供IPv6接入”，不是“在IPv6网络里承载IPv4流量”。

MAP解决的是反过来：IPv6网络已经有了，但用户还有IPv4应用访问需求。这两个技术经常被放在一起讨论，因为都是无状态地址映射思路，但方向完全相反。选型时先问自己：用户缺的是IPv6地址，还是缺IPv4公网能力？答案不同，方案就不同。

4.3 MAP和NAT64 / 464XLAT：互补大于竞争

NAT64通常部署在IPv6-only网络和IPv4 Internet之间，它把IPv6报文翻译成IPv4报文，让“IPv6-only终端”能访问“IPv4-only服务器”。464XLAT是NAT64的扩展，在终端侧加了一个CLAT功能，让IPv4应用也能跑在IPv6-only网络上。

MAP和NAT64经常被误解为二选一，其实它们可以互补。MAP解决的是“IPv4用户怎么在IPv6骨干里继续用IPv4”，NAT64解决的是“IPv6单栈用户怎么访问遗留IPv4服务器”。很多运营商的最终架构是：接入侧用MAP给存量IPv4设备提供兼容能力，核心侧用NAT64/464XLAT兜底IPv4访问，双管齐下才能彻底关停IPv4 IP地址分配。

4.4 选型建议

选型没有银弹，只能看网络现状。我个人经验是：

• 如果骨干网已经IPv6化、IPv4地址紧张、用户量巨大，优先考虑MAP-E或MAP-T。
• 如果绝大部分用户是家庭网关，很多老CPE不支持MAP，短期可以先上DS-Lite过渡，再逐步替换支持MAP的终端。
• 如果重点是让IPv6单栈用户访问存量IPv4服务，NAT64是必备组件。
• 如果只是想给IPv4用户快速开通IPv6访问能力、不完全关停IPv4，6rd或DS-Lite可能更省事。

下面这张表是几个核心维度的对比，方便一眼看明白：

5. MAP实战中的排错经验与第一讲总结

5.1 从CE侧开始的排查思路

MAP排错建议从上往下逐段看。先在CE上确认IPv6基础通不通，ping一下BR的IPv6地址，能通再谈MAP。IPv6本身不通的时候，先查RA、DHCPv6-PD、防火墙ICMPv6策略，这套路径我已经固定成肌肉记忆了。

IPv6基础通了以后，再检查CE计算出的MAP映射表。重点看两点：第一，CE算出的IPv4共享地址是否正确；第二，端口集是否覆盖实际业务需要的端口。如果内网有服务器要映射外网端口，该端口必须在PSID范围内，否则映射配了也白配。

第三步是抓包。在CE的WAN口抓IPv6报文，通过BR回程的流量里应该能看到清晰的IPv6头，其中IPv4地址和PSID应该符合MAP规则。服务商设备一般都有抓包统计命令，或者用镜像口上抓包软件。看到IPv6头里嵌入的IPv4信息不对，基本就是规则配置问题，不是链路问题。

最后查MTU。IPv6头和MAP-E的隧道封装会占用额外空间，IPv4报文的最大可用MSS变小。如果用户反馈网页图片加载不出来、文件传一半断掉，优先检查BR和CE接口的MTU设置，以及TCP MSS clamping配置。

5.2 我踩过的坑和心得

MAP我前前后后验证过不少次，有几个坑印象深刻。

第一个坑是PSID偏移不一致。表面上看两台设备的MAP规则一模一样，但厂家默认的“偏移”取值不同，CE算了端口0~255，BR认为这个用户用的是256~511，结果所有流量都走错门。从那以后我配置MAP规则时会特别把“offset”参数单独列进工单，而不是只写“PSID长度”。

第二个坑是IPv4校验和和分片。MAP-T因为要做协议翻译，IPv4头和IPv6头之间的转换必然涉及校验和重算，很多设备默认开启“硬件卸载本地计算”没问题，但只要开了某些加速特性，分片报文的校验和就容易出错。遇到ARP正常但TCP/UDP大包不通，先关设备的“分片快速转发”再测。

第三个坑是忽略ICMPv6的重要作用。MAP域里IPv6邻居发现、路由通告、NDP都依赖ICMPv6。有些网络为了“安全”把ICMPv6禁了，结果终端能拿到地址却永远找不到网关，表现就是“有IPv6地址但是不能使用”。我现在的原则是：ICMPv6不要全局禁，要禁只禁特定类型。

第四个经验是测试时别用“玄学”判断。很多人看IPv6网页慢，第一反应骂运营商，其实用curl -6和curl -4分别测一下同一个站点，就能快速确认是IPv6路由问题还是应用自身问题。Windows下配合netsh interface ipv6 show prefixpolicies看前缀策略，基本能定位大多数“IPv6拉了后腿”的故障。

5.3 下一讲预告

MAP的技术细节远不止这一篇能讲完，还有MAP-T的翻译细节、BR设备的性能调优、MAP和SRv6结合的新形态、以及跨厂商互通测试案例，这些内容我打算放到“MAP技术篇（2）”里写。如果你正好在做城域网或接入网改造，欢迎拿这篇当基础读一遍，对照自己的设备配置把规则理一理。MAP上手不算难，真正麻烦的是那些隐藏在映射算法里的边界条件，先想清楚PSID和端口集，后面就能少踩一半坑。