1. 为什么今天还要回头啃 IPv4 和 IPv6 这些老概念
刚入行那会儿，我也觉得 IP 协议这东西属于“教科书里翻烂了、工作中用不上”的典型代表。直到有一次排查一个跨机房调用超时的问题，抓包发现 TCP 三次握手都完成了，但应用层数据就是过不去，最后定位到是两端 MTU 不一致加上中间设备对分片处理策略不同导致的。那一刻我才真正意识到，IP 层的东西你不主动去搞明白，它就会在你最不想出问题的时候跳出来教你做人。
IPv4 和 IPv6 是网络世界里最基础的两套寻址和转发体系。IPv4 撑起了互联网前四十年的运转，IPv6 则是为了解决地址枯竭和路由表膨胀而生的下一代协议。这篇文章不是照本宣科地念 RFC，而是把我自己在实际项目、排障、组网过程中反复用到的知识点重新梳理一遍。不管你是刚学计算机网络的学生，还是已经工作几年但一直没系统整理过网络基础的开发者、运维人员，这篇内容都能帮你把散落的知识点串成一条线。
我会从协议设计的底层逻辑讲起，把地址结构、子网划分、报文格式、过渡技术这些核心内容拆开揉碎，再配上可以直接上手操作的命令和配置示例。中间会穿插大量我在实际工作中踩过的坑和总结出来的排查技巧，这些东西你在标准文档里基本看不到，但恰恰是真正干活时最值钱的。
2. IPv4 地址结构与子网划分的底层逻辑
2.1 点分十进制背后的二进制真相
IPv4 地址是 32 位二进制数，写成我们熟悉的192.168.1.1这种点分十进制格式，只是为了方便人类阅读。每一段十进制数对应 8 位二进制，四段加起来正好 32 位。这个转换关系听起来简单，但很多人在做子网划分时卡壳，根本原因就是没有把十进制和二进制之间的映射练到条件反射的程度。
我建议你花半小时把 0 到 255 之间每个数字对应的二进制写一遍，重点记住几个关键节点：128、192、224、240、248、252、254、255。这几个数字对应的二进制分别是 10000000、11000000、11100000、11110000、11111000、11111100、11111110、11111111。记住它们之后，看到任何子网掩码你都能在脑子里快速还原出二进制形态，判断网络位和主机位的边界在哪里。
举个例子，255.255.255.192这个掩码，最后一段 192 对应二进制 11000000，意味着最后 8 位里有 2 位是网络位、6 位是主机位。所以这个子网能容纳的主机数是 2 的 6 次方减 2，等于 62 台。为什么要减 2？因为全 0 的主机位代表网络地址，全 1 的主机位代表广播地址，这两个不能分配给具体设备。这个计算过程看起来是小学数学，但我在面试候选人和带新人的时候发现，至少有一半的人没法在不查资料的情况下流畅地完成这个推导。
2.2 子网掩码与 CIDR 的实战意义
早期的 IPv4 采用分类编址，A 类地址第一段范围是 1 到 126，B 类是 128 到 191，C 类是 192 到 223。这种分类方式非常死板，一个 B 类地址能容纳六万多台主机，但很多组织根本用不了这么多，造成大量浪费。后来引入了 CIDR（无类别域间路由），用斜杠后面的数字表示网络前缀长度，比如192.168.1.0/24就表示前 24 位是网络位。
CIDR 的好处不仅仅是省地址，更重要的是它让路由聚合成为可能。比如你有四个连续的 /24 子网：10.0.0.0/24、10.0.1.0/24、10.0.2.0/24、10.0.3.0/24，在路由表里可以聚合成一条10.0.0.0/22的记录。这样核心路由器的路由表规模就能大幅缩减，转发效率自然就上去了。我在实际组网时，只要条件允许，都会尽量做路由聚合，这能让后续的排障和扩容都轻松很多。
下面这张表列出了常见 CIDR 前缀对应的子网掩码、可用主机数和典型使用场景，建议收藏备用：
| CIDR 前缀 | 子网掩码 | 可用主机数 | 典型场景 |
|---|---|---|---|
| /30 | 255.255.255.252 | 2 | 点对点互联链路 |
| /29 | 255.255.255.248 | 6 | 小型设备管理网段 |
| /28 | 255.255.255.240 | 14 | 小型办公区 |
| /27 | 255.255.255.224 | 30 | 中型部门 |
| /26 | 255.255.255.192 | 62 | 标准业务子网 |
| /25 | 255.255.255.128 | 126 | 较大业务子网 |
| /24 | 255.255.255.0 | 254 | 传统 C 类网段 |
| /23 | 255.255.254.0 | 510 | 聚合网段 |
| /22 | 255.255.252.0 | 1022 | 大型园区 |
注意：/31 和 /32 是两个特殊情况。/31 用于点对点链路，两个地址都可用，不需要网络地址和广播地址；/32 表示单个主机地址，常用于环回接口或主机路由。
2.3 私有地址与 NAT 的功过是非
IPv4 地址枯竭是推动 IPv6 发展的最直接原因。32 位地址空间理论上能提供约 43 亿个地址，但考虑到分类编址的历史遗留、预留地址段、组播地址等因素，实际可分配的地址远没有这么多。为了缓解这个问题，RFC 1918 定义了三个私有地址段：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。这些地址只能在内部网络使用，不能出现在公网上。
配合私有地址使用的就是 NAT（网络地址转换）。NAT 让大量内部设备共享少量公网地址访问外部网络，确实在很大程度上延缓了 IPv4 地址耗尽的时间。但 NAT 也带来了不少问题：破坏了端到端连通性，让 P2P 应用变得复杂，增加了状态维护开销，还给排障带来了额外难度。我在排查跨网问题时，经常需要同时关注 NAT 表项、端口映射和会话超时时间，这些都是 NAT 引入的额外复杂度。
从长远来看，IPv6 才是根本解决方案。但在相当长一段时间内，IPv4 和 IPv6 会共存，NAT 也不会立刻消失。所以理解 NAT 的工作原理和常见配置，仍然是网络从业者的必备技能。
3. IPv6 地址体系与报文格式深度拆解
3.1 128 位地址空间的表达方式
IPv6 最直观的变化就是地址从 32 位扩展到了 128 位。这个数字有多大？理论上可以为地球上每一粒沙子分配一个 IP 地址，而且还有富余。IPv6 地址写成八组四位十六进制数，比如2001:0db8:0000:0000:0000:ff00:0042:8329。为了简化书写，RFC 5952 规定了压缩规则：每组开头的 0 可以省略，连续的全零组可以用双冒号::代替，但双冒号只能出现一次。
上面那个地址压缩后就是2001:db8::ff00:42:8329。这个规则看起来简单，但我在实际配置时见过不少人因为双冒号用错位置导致地址解析失败。记住一个原则：双冒号代表的是“一个或多个全零组”，具体是几组要根据总组数补全到八组来推算。如果地址里出现了两个双冒号，那这个地址就是非法的，设备会直接报错。
IPv6 地址分为三大类：单播地址、组播地址和任播地址。注意，IPv6 没有广播地址这个概念，广播的功能被组播替代了。常见的单播地址包括全球单播地址（2000::/3）、链路本地地址（fe80::/10）、唯一本地地址（fc00::/7）等。链路本地地址特别重要，每台启用 IPv6 的接口都会自动生成一个，用于同一链路上的邻居发现和路由协议通信，不需要手动配置。
3.2 IPv6 报文头的精简与扩展
IPv6 报文头和 IPv4 相比，最大的变化是去掉了校验和字段、去掉了选项字段、去掉了分片相关字段（移到扩展头里），固定头长度从 IPv4 的 20 字节（不含选项）变成了固定的 40 字节。这个设计思路是让路由器处理报文时更快，因为固定长度的头部更容易用硬件解析。
IPv6 的扩展头机制非常灵活。需要分片时用分片扩展头，需要逐跳选项时用逐跳选项头，需要路由时用路由头。这些扩展头按顺序排列在固定头之后，路由器只处理自己需要关心的部分，其他部分可以快速跳过。这种设计比 IPv4 的选项字段优雅得多，IPv4 的选项字段会导致头部长度可变，路由器处理起来更麻烦。
下面这张表对比了 IPv4 和 IPv6 报文头的关键字段差异：
| 字段 | IPv4 | IPv6 | 说明 |
|---|---|---|---|
| 版本 | 4 位 | 4 位 | 分别表示 4 和 6 |
| 头部长度 | 4 位 | 无 | IPv6 固定 40 字节 |
| 总长度 | 16 位 | 16 位 | 载荷长度，不含固定头 |
| 标识/标志/片偏移 | 有 | 无 | 移到分片扩展头 |
| TTL | 8 位 | 无 | 改为跳数限制，8 位 |
| 协议 | 8 位 | 无 | 改为下一个头，8 位 |
| 校验和 | 16 位 | 无 | 由上层协议保证 |
| 源/目的地址 | 32 位 | 128 位 | 地址空间大幅扩展 |
| 流标签 | 无 | 20 位 | 用于 QoS 标记 |
提示：IPv6 去掉头部校验和是一个有争议的设计。支持者认为链路层和传输层已经有校验机制，网络层再做一次是重复劳动；反对者认为这降低了网络层的健壮性。实际使用中，这个问题并不突出，因为现代链路的误码率已经很低了。
3.3 邻居发现协议替代 ARP 的机制
IPv4 里用 ARP 做地址解析，IPv6 里用邻居发现协议（NDP）。NDP 基于 ICMPv6 实现，功能比 ARP 丰富得多。除了地址解析，NDP 还负责路由器发现、前缀发现、地址自动配置、重复地址检测等功能。可以说 NDP 是 IPv6 能实现即插即用的关键。
NDP 用五种 ICMPv6 报文：路由器请求、路由器通告、邻居请求、邻居通告、重定向。主机启动时先发路由器请求，路由器回路由器通告，主机根据通告里的前缀信息自动生成全球单播地址。这个过程叫无状态地址自动配置，简称 SLAAC。SLAAC 让设备接入网络后不需要 DHCP 就能获得可用的 IPv6 地址，这对物联网设备特别友好。
不过 SLAAC 也有局限性，它没法下发 DNS 服务器地址等额外信息。虽然后来 RFC 8106 定义了 RDNSS 选项来弥补这个缺陷，但实际部署中支持度参差不齐。所以在企业网络里，通常还是用 DHCPv6 来做地址分配，或者用 SLAAC 加 DHCPv6 的组合方案。我在配置时一般会根据客户的实际需求来选择，如果只是简单上网，SLAAC 就够了；如果需要精细管控，DHCPv6 更合适。
4. 双栈与过渡技术的选型与实操
4.1 双栈：最稳妥的过渡方案
双栈是指设备同时运行 IPv4 和 IPv6 协议栈，接口同时配置两种地址。这是目前最主流的过渡方案，因为它的逻辑最简单：能通 IPv6 就走 IPv6，不能通就回退到 IPv4。操作系统层面，Windows、Linux、macOS 都默认支持双栈，网络设备也基本都支持。
双栈的配置不复杂，以 Linux 为例，给接口加一个 IPv6 地址只需要一条命令：
# 给 eth0 接口添加 IPv6 地址 ip -6 addr add 2001:db8::1/64 dev eth0 # 查看接口 IPv6 地址 ip -6 addr show dev eth0 # 添加默认路由 ip -6 route add default via 2001:db8::ffff dev eth0配置完成后，用ping6或ping -6测试连通性。如果 ping 不通，先检查链路本地地址是否正常生成，再用ip -6 neigh查看邻居表项是否解析成功。我遇到过好几次因为交换机端口没放行 IPv6 组播导致的邻居解析失败，这种问题在纯 IPv4 环境下不会出现，需要特别注意。
双栈的缺点是运维复杂度翻倍。你需要同时维护两套地址规划、两套路由策略、两套安全规则。而且双栈并不意味着 IPv6 一定比 IPv4 快，实际路径选择取决于路由表和策略配置。我在实际项目中见过双栈环境下 IPv6 绕路导致延迟反而更高的情况，所以上线前一定要做路径探测和性能对比。
4.2 隧道技术：在 IPv4 海洋里跑 IPv6
隧道技术的思路是把 IPv6 报文封装在 IPv4 报文里，穿过不支持 IPv6 的网络。常见的隧道技术有 6in4、6to4、Teredo、ISATAP 等。6in4 是手动配置的静态隧道，适合两个固定节点之间的互联；6to4 是自动隧道，用 6to4 地址前缀，但依赖中继路由器，实际效果不稳定；Teredo 和 ISATAP 更偏向过渡期的临时方案，现在用得越来越少。
以 6in4 为例，配置大致是这样的：
# 创建隧道接口 ip tunnel add tun6in4 mode sit remote 203.0.113.1 local 198.51.100.1 ttl 255 # 启用接口 ip link set tun6in4 up # 配置 IPv6 地址 ip -6 addr add 2001:db8:1::1/64 dev tun6in4 # 添加路由 ip -6 route add 2001:db8:2::/64 dev tun6in4隧道技术的核心问题是 MTU。因为外层 IPv4 头加上内层 IPv6 头，实际可用的 MTU 会减少。如果没做好 MSS 钳制，大包会被丢弃，表现为“小包能通、大包不通”的诡异现象。我一般会把隧道接口的 MTU 设成 1480，同时在边界设备上配置 TCP MSS 调整为 1400 左右，这样基本能避免分片问题。
4.3 翻译技术：NAT64 与 DNS64 的配合
翻译技术的代表是 NAT64，它让纯 IPv6 主机能够访问纯 IPv4 资源。NAT64 网关维护一个 IPv6 地址池，把 IPv4 地址映射成特定的 IPv6 前缀（通常是 64:ff9b::/96），然后在转发时做协议转换。DNS64 则负责在 DNS 解析时，如果查询的是 A 记录（IPv4），就合成一个 AAAA 记录（IPv6）返回给客户端，让客户端以为目标就是 IPv6 地址。
NAT64 的配置因设备而异，以某开源实现为例，核心配置包括地址池定义、前缀设置、会话超时时间等。这里不展开具体命令，重点说几个实操要点：第一，NAT64 是有状态的，会话表会占用内存，大规模部署时要评估容量；第二，不是所有协议都能顺利翻译，比如 FTP 这种在载荷里带地址信息的协议就需要 ALG 支持；第三，DNS64 合成的地址只能用于访问，不能用于被访问，所以纯 IPv6 主机没法对外提供服务。
注意：NAT64 和 DNS64 通常配合使用，但 DNS64 不是必须的。如果客户端能直接拿到 IPv4 地址并自己发起 NAT64 转换，也可以不用 DNS64。不过实际部署中，为了对客户端透明，两者一般都会开启。
5. 地址规划与路由配置的实战经验
5.1 IPv4 地址规划的层次化思路
地址规划看起来是小事，但规划不好会给后续运维埋下大坑。我的经验是遵循“层次化、可聚合、留余量”三个原则。层次化是指按区域、按功能、按楼层等维度划分地址块，让地址本身就能反映拓扑位置；可聚合是指相邻的地址块尽量连续，方便做路由汇总；留余量是指每个地址块预留足够的扩展空间，避免后期扩容时地址不够用。
举个例子，一个园区网可以这样规划：核心互联用10.0.0.0/24，办公区用10.1.0.0/16，服务器区用10.2.0.0/16，管理网用10.3.0.0/16。办公区内部再按楼层划分：一楼10.1.1.0/24，二楼10.1.2.0/24，以此类推。这样核心路由器的路由表里，办公区就是一条10.1.0.0/16，非常清爽。
IPv6 的规划思路类似，但空间大得多，可以更奢侈一些。我通常会给每个区域分配一个 /48 前缀，每个子网用 /64。这样即使一个区域有上万个子网也够用。而且 /64 是 SLAAC 的要求，子网前缀必须是 64 位，否则自动配置会出问题。
5.2 静态路由与动态路由的选择
小规模网络用静态路由就够了，配置简单、可控性强。但静态路由的缺点是没法自动适应拓扑变化，一旦链路故障就需要手动切换。中大型网络必须用动态路由协议，常见的有 OSPF、IS-IS、BGP 等。IPv6 环境下，OSPFv3 和 IS-IS 都支持，BGP 也早就支持 IPv6 地址族了。
我在实际项目中的选择逻辑是这样的：园区网内部用 OSPFv3，因为它配置简单、收敛快；数据中心用 BGP，因为需要精细的策略控制；跨域互联用 BGP，因为它是事实上的域间路由标准。静态路由则用在边缘设备、默认路由、管理网段等场景。
配置动态路由时，有几个参数需要特别注意。一是路由器 ID，OSPFv3 虽然不依赖 IPv4 地址，但仍然需要一个 32 位的路由器 ID，通常用环回口的 IPv4 地址；二是链路开销，要根据实际带宽设置，否则可能出现次优路径；三是认证，生产环境一定要开认证，防止路由欺骗。
5.3 路由聚合与黑洞路由的配合
路由聚合能减小路由表规模，但聚合后如果某个子网不可达，流量会被吸引到聚合路由器然后被丢弃，形成黑洞。解决办法是配置一条指向 null0 的黑洞路由，让聚合路由器在子网不可达时明确丢弃流量，而不是转发到错误的方向。
以 Cisco 设备为例，配置大致如下：
# 配置聚合路由指向 null0 ip route 10.1.0.0 255.255.0.0 null0 # 配置具体子网路由 ip route 10.1.1.0 255.255.255.0 192.168.1.1 ip route 10.1.2.0 255.255.255.0 192.168.1.2这样当10.1.1.0/24和10.1.2.0/24都可达时，具体路由生效；当它们都不可达时，聚合路由生效，流量被丢弃而不是绕路。这个技巧在 BGP 环境里特别常用，能有效防止路由环路和流量黑洞。
IPv6 的路由聚合逻辑一样，只是地址格式不同。配置时注意前缀长度和下一跳地址的写法，别把 IPv4 和 IPv6 的命令搞混了。
6. 常见问题排查与避坑指南
6.1 IPv4 排障的经典套路
IPv4 排障有一套成熟的流程：先看物理层和链路层，确认接口 up、协商正常；再看网络层，确认 IP 地址、掩码、网关配置正确；然后看路由表，确认有到达目标的路由；接着看 ARP 表，确认下一跳地址解析成功；最后看防火墙和 ACL，确认没有拦截。这个流程能解决大部分连通性问题。
我遇到最多的坑是掩码配错。比如两台主机明明在同一网段，但一台配了 /24，另一台配了 /25，结果就是部分地址能通、部分不通。这种问题用ip addr或ifconfig一看就能发现，但如果不熟悉子网划分，可能排查半天都找不到原因。所以我在带新人的时候，第一课永远是子网划分，这个基本功不扎实，后面全是坑。
另一个常见问题是 MTU 不匹配。表现为 ping 小包能通，ping 大包不通，或者 TCP 连接能建立但传输大文件时卡死。排查方法是用ping -M do -s 1472逐步减小包大小，找到能通的最大值，然后推算出路径 MTU。解决方法是调整接口 MTU 或配置 MSS 钳制。
6.2 IPv6 排障的特殊注意事项
IPv6 排障和 IPv4 有相似之处，但也有几个特殊点。第一，链路本地地址是自动生成的，如果接口没起来或者驱动有问题，链路本地地址可能缺失，导致邻居发现失败。第二，IPv6 的组播地址很多，防火墙如果没放行必要的 ICMPv6 类型，NDP 就没法工作。第三，双栈环境下，DNS 解析顺序和地址选择策略会影响实际走哪条路径，需要检查gai.conf或注册表设置。
我踩过的一个坑是：服务器配了 IPv6 地址，但没配默认路由，结果服务器尝试用 IPv6 访问外部网络，超时后才回退到 IPv4，导致访问延迟很高。排查时用ip -6 route一看，默认路由是空的。加上默认路由后问题解决。这个案例说明，双栈环境下一定要确保两套协议栈的配置都是完整的，不能只配一半。
还有一个坑是 ICMPv6 被过度拦截。有些安全策略为了“安全”，把所有 ICMPv6 都封了，结果 NDP 没法工作，IPv6 直接瘫痪。正确的做法是放行 NDP 必需的几种 ICMPv6 类型：133（路由器请求）、134（路由器通告）、135（邻居请求）、136（邻居通告），以及路径 MTU 发现需要的 2（包太大）。
6.3 常见问题速查表
下面这张表整理了我在实际工作中遇到的高频问题、排查思路和解决方法，建议打印出来贴在工位上：
| 问题现象 | 可能原因 | 排查命令 | 解决方法 |
|---|---|---|---|
| 同网段部分主机不通 | 掩码不一致 | ip addr | 统一掩码配置 |
| ping 小包通大包不通 | MTU 不匹配 | ping -M do -s | 调整 MTU 或 MSS |
| IPv6 地址无法生成 | 接口未启用 IPv6 | sysctl net.ipv6.conf.all.disable_ipv6 | 启用 IPv6 |
| NDP 解析失败 | ICMPv6 被拦截 | tcpdump icmp6 | 放行必要 ICMPv6 类型 |
| 双栈访问延迟高 | IPv6 路由缺失 | ip -6 route | 补全 IPv6 路由 |
| 隧道不通 | 协议号被拦截 | tcpdump proto 41 | 放行协议号 41 |
| NAT64 部分应用失败 | ALG 未启用 | 查看会话表 | 启用对应 ALG |
| 路由聚合后黑洞 | 缺少 null0 路由 | show ip route | 配置黑洞路由 |
提示：排障时养成抓包的习惯。很多问题看配置看不出来，但抓包一看就明白了。Wireshark 对 IPv6 的支持很完善，ICMPv6 的各种类型都有解析，用起来很方便。
6.4 几个容易被忽视的细节
第一个细节是 IPv4 的 TTL 和 IPv6 的跳数限制。TTL 每经过一个路由器减一，减到零就丢弃并回 ICMP 超时。traceroute 就是利用这个机制工作的。IPv6 的跳数限制功能一样，只是名字不同。排查路由环路时，看 TTL 或跳数限制的变化就能判断路径长度。
第二个细节是 IPv6 的地址生命周期。IPv6 地址有首选生命周期和有效生命周期两个参数。首选生命周期内地址可以正常用于新连接，过了首选但还在有效期内可以用于已有连接但不能用于新连接，过了有效期地址就失效了。这个机制在地址重新编址时很有用，能让旧地址平滑退出。配置 DHCPv6 或 RA 时要注意这两个参数的设置。
第三个细节是 IPv4 的 ARP 缓存和 IPv6 的邻居缓存超时时间。缓存时间太长会导致地址变化后流量发往错误的目的地，太短会导致频繁解析增加开销。Linux 默认的 ARP 缓存超时是 30 秒左右，邻居缓存类似。在高动态环境下可以适当调短，在稳定环境下可以调长。
7. 从协议细节到工程实践的几点体会
搞网络这行，最怕的就是“知其然不知其所以然”。IPv4 和 IPv6 的很多设计细节，背后都有深刻的历史背景和工程权衡。比如 IPv4 的选项字段为什么设计得那么别扭，IPv6 为什么要去掉头部校验和，NAT 为什么会在短期内无法被完全替代，这些问题想明白了，你在做技术选型和排障时就会更有底气。
我在实际工作中最大的体会是：协议规范是死的，但网络环境是活的。同样一个 IPv6 地址配置，在不同厂商的设备上可能有不同的默认行为；同样一个 NDP 流程，在不同操作系统上可能有不同的实现细节。所以看文档的同时一定要动手实验，用抓包工具验证实际行为，这样才能真正掌握。
另外，IPv6 的普及是大势所趋，但这个过程会比很多人想象的漫长。在过渡期内，双栈、隧道、翻译这些技术都会长期存在。与其纠结哪种技术“更好”，不如把每种技术的适用场景和局限性搞清楚，在实际项目中根据需求灵活选择。我个人的经验是：新建网络优先上双栈，存量网络根据业务重要性逐步改造，边缘场景可以用翻译技术快速打通。
最后分享一个我常用的 IPv6 连通性测试脚本，放在跳板机上定时跑，能提前发现很多问题：
#!/bin/bash # IPv6 连通性巡检脚本 TARGETS=("2001:db8::1" "2001:db8::2" "2001:db8:1::1") for target in "${TARGETS[@]}"; do if ping -6 -c 3 -W 2 "$target" > /dev/null 2>&1; then echo "OK: $target" else echo "FAIL: $target" # 进一步诊断 ip -6 route get "$target" ip -6 neigh show fi done这个脚本虽然简单，但配合告警系统使用，能帮你第一时间发现 IPv6 链路故障。排查时先看路由，再看邻居，最后抓包，基本能覆盖大部分场景。网络这东西，平时多流汗，故障时就少流血。把基础打牢，把工具用熟，把流程跑顺，剩下的就是经验积累了。
