4. 开发环境搭建

IP层是整个网络协议栈的腰杆子。腰杆子硬不硬，直接决定了你的设备能不能在复杂的网络环境里站稳脚跟。今天咱们就把Zephyr的IP层四个核心机制掰开揉碎了讲清楚。

4.1 IPv4/IPv6双栈实现

双栈，说白了就是让设备同时支持IPv4和IPv6两套协议。Zephyr的实现方式很巧妙——它不是两套独立的协议栈，而是共享传输层，在IP层做分流。

我记得第一次在Zephyr上调试双栈时，遇到一个坑：默认配置下，IPv6的地址自动配置（SLAAC）是开启的，但IPv4的DHCP客户端默认没开。结果设备只拿到了IPv6地址，IPv4通信全挂。后来我养成了一个习惯——检查双栈配置时，先看prj.conf里的这两项：

# 启用IPv4
CONFIG_NET_IPV4=y
CONFIG_NET_DHCPV4=y

# 启用IPv6
CONFIG_NET_IPV6=y
CONFIG_NET_IPV6_ND=y

双栈的地址选择策略也值得注意。Zephyr默认使用RFC 6724的源地址选择算法。简单说就是：优先选相同作用域的地址，优先选临时地址（IPv6隐私扩展），优先选匹配目的地址类型的地址。

场景	IPv4行为	IPv6行为
地址配置	DHCP或静态	SLAAC、DHCPv6或静态
地址数量	通常1个	可多个（链路本地+全局+临时）
默认路由	DHCP提供	RA（路由器通告）提供
邻居发现	ARP	NDP（ICMPv6）

4.2 路由表管理

路由表是IP层的导航地图。Zephyr的路由表实现基于最长前缀匹配算法，支持IPv4和IPv6的路由条目共存。

我个人习惯把路由表分成三类来理解：

• 直连路由： 设备自己接口上的网段，自动生成
• 静态路由： 手动配置的固定路径
• 默认路由： 0.0.0.0/0 或 ::/0，所有未知目的地的兜底

Zephyr的路由表操作API很简洁。我项目中常用的是这几个：

// 添加默认路由（IPv4）
struct net_route_entry *route;
struct in_addr gateway = {0};
net_addr_pton(AF_INET, "192.168.1.1", &gateway);
route = net_route_add(&gateway, NULL, NULL, NET_ADDR_PREFERRED);

// 添加静态路由（IPv6）
struct in6_addr dest, nexthop;
net_addr_pton(AF_INET6, "2001:db8::/32", &dest);
net_addr_pton(AF_INET6, "fe80::1", &nexthop);
net_route_add(&dest, &nexthop, NULL, NET_ADDR_PREFERRED);

路由查找的性能也很关键。Zephyr使用哈希表+链表的结构来存储路由条目。查找时先哈希到桶，再在桶内线性遍历。对于大多数IoT场景，几十条路由的规模完全够用。但如果你的设备需要处理上千条路由，建议考虑外部路由表方案。

4.3 邻居发现协议（NDP）

NDP是IPv6替代ARP的协议。它用ICMPv6报文来完成地址解析、邻居不可达检测、路由器发现等功能。

Zephyr的NDP实现包含以下几个核心组件：

• 邻居缓存（Neighbor Cache）： 存储IP地址到链路层地址的映射
• 目标缓存（Destination Cache）： 存储目的IP到下一跳的映射
• 前缀列表（Prefix List）： 记录网络前缀信息
• 默认路由器列表（Default Router List）： 记录可用的路由器

邻居缓存的状态机是NDP最复杂的部分。Zephyr实现了RFC 4861定义的5种状态：

状态	含义	触发条件
INCOMPLETE	正在解析地址	发送NS后，等待NA
REACHABLE	地址可达	收到NA或上层确认
STALE	超过可达时间	REACHABLE超时
DELAY	延迟探测	STALE后有流量
PROBE	正在探测	DELAY超时，发送NS

嗯，这里要注意一个细节：Zephyr的NDP实现默认开启了路由器请求（RS）功能。设备启动后会主动发送RS报文，等待路由器回复RA。如果网络中没有IPv6路由器，设备会一直重试。我曾经在一个隔离的测试网络中调试，设备每隔几秒就发RS，把日志刷得满满当当。解决方案很简单：

// 在应用层关闭RS发送
struct net_if *iface = net_if_get_default();
net_if_ipv6_set_rs_interval(iface, NET_IPV6_RS_INFINITE);

4.4 IP分片与重组

IP分片是网络层最容易被忽视的机制。你想想看，以太网MTU是1500字节，但UDP应用层可能一次发8KB的数据。没有分片，大包根本出不去。

Zephyr的IP分片实现遵循RFC 791（IPv4）和RFC 2460（IPv6）。两者的核心区别在于：

• IPv4： 中间路由器可以分片，接收端重组
• IPv6： 只有发送端可以分片，中间路由器不允许分片

分片重组需要缓冲区来暂存分片数据。Zephyr使用分片重组缓冲区池来管理。默认配置下，每个分片重组上下文最多可以缓存6个分片，超时时间60秒。

// 分片重组相关配置
CONFIG_NET_IPV4_FRAGMENT=y        // 启用IPv4分片重组
CONFIG_NET_IPV6_FRAGMENT=y        // 启用IPv6分片重组
CONFIG_NET_FRAGMENT_MAX_PKT=6     // 最大分片数量
CONFIG_NET_FRAGMENT_TIMEOUT=60    // 超时时间（秒）

分片性能调优的关键在于避免分片。能不分片就别分片，分片带来的CPU开销和内存开销都不小。我建议的做法是：

1. 应用层做MTU探测，动态调整发送大小
2. 使用PMTUD（路径MTU发现）自动发现路径MTU
3. 对于UDP应用，把发送缓冲区大小控制在1280字节以内（IPv6最小MTU）

最后，我用一张图来总结IP层的核心数据流：

这张图展示了数据从应用层到MAC层的完整路径。注意看IP层分流这个节点——它是双栈实现的核心。Zephyr根据目的地址的地址族（AF_INET或AF_INET6）来决定走哪条路径。如果socket绑定了特定IP版本，那就强制走对应路径。