4、车载以太网网络层：IPv4与IPv6在车内的应用、ARP协议、ICMP协议、车载网络中的子网划分

网络层，说白了就是负责把数据包从源节点送到目标节点的那个层级。在车里，这个层级决定了你的诊断报文能不能准确到达ECU，OTA升级包能不能完整下发。我这些年调试过的车载项目，至少有一半的通信故障都跟网络层配置有关。今天咱们就把这块掰开揉碎了讲清楚。

4.1 IPv4与IPv6在车内的应用

车内网络到底用IPv4还是IPv6？这不是一个非黑即白的选择题。目前量产车型里，IPv4仍然是绝对主力，但IPv6的渗透速度比很多人想象的要快。

4.1.1 IPv4：成熟但地址紧张

IPv4地址只有32位，理论可用地址约43亿个。在传统车载网络里，一个域控制器下面挂几十个ECU，用私有地址段（比如192.168.x.x或10.x.x.x）完全够用。我参与的第一个车载项目就是纯IPv4架构，当时觉得地址多得用不完。

但问题出在云端对接上。车端用私有IPv4地址，上云时必须做NAT转换。每次建立连接都要经过网关映射，延迟增加了不说，有些长连接还会被NAT表项老化踢掉。我记得有次调试T-Box的MQTT心跳，总是莫名其妙断连，查了两天才发现是NAT超时时间设置得太短。

4.1.2 IPv6：为车联网而生

IPv6的128位地址空间，说白了就是给每个传感器、每个ECU甚至每个传感器上的每个数据通道都分配一个全球唯一地址。这对车联网来说是天然优势——不需要NAT，端到端通信，延迟更低，安全性更好。

我最近在做的下一代域控项目，已经开始要求所有新开发的模块必须同时支持IPv4和IPv6双栈。虽然短期内IPv6的流量占比还很低，但主机厂的要求很明确：三年后的车型，IPv6将是必选项。

4.2 ARP协议：谁有我的MAC地址？

ARP（地址解析协议）解决的是一个很基础的问题：我知道对方的IP地址，但我不知道它的MAC地址，怎么把数据帧发过去？

在车载网络里，ARP的交互频率其实不高。因为车内拓扑相对固定，很多设备在启动阶段通过DHCP获取IP后，ARP缓存就建立起来了。但有一种情况特别坑——ARP风暴。

我曾经在一个项目里遇到过：某次OTA升级后，所有ECU同时重启，然后同时发送ARP请求。百兆以太网上瞬间被ARP广播包塞满，正常的诊断报文根本发不出去。后来我们在交换机上配置了ARP限速和端口隔离，才彻底解决这个问题。

4.2.1 ARP的工作流程

1. 主机A想发送数据给IP_B，但不知道IP_B的MAC地址
2. 主机A广播ARP请求："谁是IP_B？请告诉MAC_A"
3. 所有主机收到广播，只有IP_B响应
4. IP_B单播回复："我是IP_B，我的MAC是MAC_B"
5. 主机A将映射关系写入ARP缓存，开始通信

4.3 ICMP协议：网络通不通？

ICMP（互联网控制报文协议）最常用的就是Ping和Traceroute。在车载开发中，ICMP是定位网络故障的第一把刀。

我记得有次客户反馈说T-Box经常掉线。我远程连上去，先Ping网关——通了。再Ping DNS服务器——也通了。最后Ping云平台IP——超时。问题一下就定位到了：不是车端网络问题，是云平台那边的路由出了问题。

4.3.1 车载场景下的ICMP应用

• 连通性检测：ECU启动后Ping网关，确认链路正常
• MTU探测：通过ICMP的"分片需要"消息，找到路径上的最小MTU
• 路由重定向：告诉发送方有更优的下一跳路径
• 超时通知：TTL耗尽时，路由器返回超时消息

4.4 车载网络中的子网划分

子网划分，说白了就是把一个大网络切成几个小网络。在车里这么做，主要是为了隔离广播域、控制流量、提升安全性。

我见过最极端的案例：某款车型全车只有一个192.168.1.0/24网段，所有ECU都在同一个广播域里。结果娱乐系统的DHCP请求广播，把ADAS的摄像头数据流冲得七零八落。后来改方案，把网络拆成三个子网，问题迎刃而解。

4.4.1 车载子网划分原则

4.4.2 子网间通信

不同子网之间不能直接通信，必须通过网关（通常是域控制器或中央网关）做路由转发。这就引出了另一个关键点：路由表配置。

我建议在中央网关上配置静态路由，不要用动态路由协议。车内拓扑变化频率极低，静态路由简单可靠，不容易出问题。动态路由协议（如OSPF）在车里反而可能因为链路抖动导致路由震荡。

好了，网络层的这几个核心知识点就讲到这里。ARP、ICMP、IPv4/IPv6、子网划分，每一个在车载场景下都有它独特的坑和最佳实践。做车载以太网，不能只懂协议本身，更要懂这些协议在车里怎么落地、怎么避坑。下一层咱们会讲传输层，TCP和UDP在车里的那些事儿，到时候再聊。