4、车载以太网网络层：IPv4与IPv6在车载中的应用、ARP协议与NDP协议、ICMP与诊断报文
网络层，说白了就是负责把数据包从源头发到目的地。在车载以太网里，这一层主要靠IP协议撑着。你可能会问，为什么不用传统的CAN总线那一套？嗯，因为现在的车载系统越来越复杂，ADAS、OTA升级、远程诊断，这些场景对带宽和灵活性的要求，CAN已经扛不住了。
我个人习惯把网络层比作“快递分拣中心”。IP地址就是门牌号，ARP和NDP就是问路的过程，ICMP则是快递员反馈的“查无此人”或“地址错误”。今天我们就来聊聊这些协议在车里是怎么玩的。
4.1 IPv4与IPv6：车载网络的两代“门牌号”
IPv4大家都很熟了，32位地址，写成四个数字，比如192.168.1.100。在车载环境里，IPv4目前还是主流。我在做第一个车载项目时，用的就是IPv4。当时觉得够用，但随着车上ECU数量爆炸式增长，IPv4地址不够的问题就冒出来了。
IPv6呢？128位地址，号称能给地球上每一粒沙子分配一个IP。车载场景下，IPv6的优势很明显：地址空间大、自动配置、安全性更好。但说实话，目前国内量产车用IPv6的还不多，主要是产业链成熟度问题。
关键对比：
| 特性 | IPv4 | IPv6 |
|---|---|---|
| 地址长度 | 32位 | 128位 |
| 地址数量 | 约43亿 | 2^128个 |
| 自动配置 | DHCP | SLAAC（无状态自动配置） |
| 车载现状 | 主流 | 逐步推广 |
| 诊断应用 | DoIP（ISO 13400） | DoIP也支持，但较少 |
在车载诊断系统里，DoIP（Diagnostic over Internet Protocol）是核心。DoIP基于IPv4或IPv6，把诊断报文封装在TCP/UDP里。我个人建议，新项目尽量考虑IPv6兼容，因为未来OTA和V2X场景下，IPv6几乎是必选项。
4.2 ARP协议：IPv4世界的“问路”机制
ARP（Address Resolution Protocol）解决的是一个问题：我知道对方的IP地址，但不知道它的MAC地址，怎么把数据发过去？
ARP的工作原理很简单：广播一个请求包，问“谁有这个IP？”，目标设备回复“我有，我的MAC是XX:XX:XX:XX:XX:XX”。然后发送方把IP-MAC映射缓存起来，下次直接用。
我在项目中遇到过一个问题：某款T-Box在频繁唤醒时，ARP缓存表会溢出，导致诊断连接失败。排查了很久，最后发现是ARP表老化时间设置太短，加上网络拓扑变化太快。解决办法是把缓存超时时间从30秒调整到120秒，问题解决。
避坑指南：我曾经在实车测试时，发现诊断仪连不上某个ECU。抓包一看，ARP请求发出去没人回。后来发现是ECU的MAC地址被误配置成了广播地址。嗯，这种低级错误，检查硬件地址表就能避免。
4.3 NDP协议：IPv6世界的“邻居发现”
IPv6里没有ARP，取而代之的是NDP（Neighbor Discovery Protocol）。NDP的功能更强大，它不只是做地址解析，还负责路由器发现、前缀发现、地址自动配置、重复地址检测等。
NDP的核心报文有五种：
- 路由器请求（RS）：节点启动时，问“有没有路由器？”
- 路由器通告（RA）：路由器回复“我在，前缀是xxxx”
- 邻居请求（NS）：类似ARP请求，“谁有这个IPv6地址？”
- 邻居通告（NA）：类似ARP回复，“我有，我的链路层地址是...”
- 重定向（Redirect）：路由器告诉节点“你走另一条路更快”
在车载环境里，NDP的自动配置功能特别实用。你想想看，一辆车下线时，每个ECU都要手动配置IP？那生产线得疯掉。用SLAAC（无状态地址自动配置），ECU上电后自动生成IPv6地址，省时省力。
注意：NDP虽然强大，但安全性是个隐患。比如伪造的RA报文可以让ECU配置错误的网关，导致诊断流量被劫持。我在做安全方案时，建议启用SEcure Neighbor Discovery（SEND），或者至少用ACL限制RA报文的来源。
4.4 ICMP与诊断报文：网络层的“体检报告”
ICMP（Internet Control Message Protocol）是网络层的“信使”。它不传数据，只传控制消息。比如你ping一个IP，用的就是ICMP Echo请求和回复。
在车载诊断里，ICMP有两个主要用途：
- 连通性检测：诊断仪发送ICMP Echo请求，看ECU是否在线。这是最基础的“心跳”机制。
- 错误报告：比如“目标不可达”、“超时”、“参数错误”等。这些信息对诊断故障很有帮助。
我记得有一次，客户反馈诊断仪连不上某个域控制器。我抓包一看，ICMP回复显示“Destination Unreachable (Port Unreachable)”。这说明ECU在线，但诊断端口（通常是13400）没开。检查后发现是诊断服务进程挂了，重启后恢复。
诊断报文本身（比如UDS诊断请求/响应）是封装在TCP或UDP里的。DoIP协议定义了如何把诊断数据打包成IP报文。一个典型的DoIP诊断流程是这样的：
1. 诊断仪发送DoIP车辆识别请求（广播）
2. ECU回复车辆识别响应（包含VIN、IP地址等）
3. 诊断仪建立TCP连接（端口13400）
4. 发送DoIP诊断报文（包含UDS请求）
5. ECU回复DoIP诊断响应（包含UDS响应）
6. 诊断完成，关闭连接这里有个细节：ICMP报文和诊断报文是两回事。ICMP是网络层的，诊断报文是应用层的。但ICMP的错误信息可以帮助诊断仪快速定位网络层问题，比如路由不通、端口关闭等。
实战建议：在开发诊断工具时，一定要把ICMP的反馈信息显示出来。我见过很多工具只显示“连接超时”，却不告诉你是因为路由不可达还是端口关闭。加上ICMP解析，能省一半的排查时间。
4.5 小结：网络层在车载诊断中的角色
网络层是车载以太网诊断的“骨架”。IPv4/IPv6决定了地址怎么分配，ARP/NDP决定了邻居怎么发现，ICMP决定了错误怎么报告。这三者配合好了，诊断报文才能顺畅地在诊断仪和ECU之间跑起来。
我个人经验是，做车载网络层开发，不要只盯着协议栈代码。多看看抓包数据，理解每个报文在真实场景下的行为。比如ARP广播风暴、NDP的RA攻击、ICMP的Redirect欺骗，这些在实验室里很少出现，但实车环境里一抓一大把。
下一章我们会聊传输层，TCP和UDP在车载诊断里的应用。到时候你会看到，网络层打下的基础，在传输层会如何被放大或制约。