为什么不能整类封禁
四层时代很多人习惯把控制报文协议整类封禁，理由是怕被扫描。六层这样做会同时废掉两套关键机制：邻居发现用它完成地址解析与路由器发现，路径最大传输单元探测用它做差错反馈。封掉之后表现为地址解析不完整、大包全部丢失，而症状看起来与防火墙毫无关系。
必须放行哪些
差错类报文必须放行，包括目标不可达、报文过大、超时与参数错误，其中报文过大直接决定大包能否正常传输。邻居发现相关的四类报文必须放行，它们是地址解析与重定向的基础。回显请求与应答建议放行，便于排障；在严格环境里可以限制来源范围而不是整类封禁。
基本信息
| 差错类报文 | 类型一到四，必须放行 |
|---|---|
| 地址与路由器发现 | 类型一百三十三与一百三十四，必须放行 |
| 地址解析 | 类型一百三十五与一百三十六，必须放行 |
| 重定向 | 类型一百三十七，建议放行 |
| 回显 | 类型一百二十八与一百二十九，建议放行 |
典型使用场景
- 边界策略制定：把必需类型写进基线，避免照搬四层时代的整类封禁
- 排查大包不通：确认报文过大类型的差错报文是否被策略拦截
- 排查地址解析失败：确认地址解析相关类型是否双向放行
- 安全加固：在放行的前提下限定来源范围，兼顾排障需求与安全
- 审计检查：核查现有策略是否把必需类型一并封禁，这是常见的隐性缺陷
- 培训讲解：说明为什么这两种机制必须保留，比罗列类型编号更有说服力
示例：只放必要类型
示例：只放必要类型
# 按报文类型逐条放行，顺序与写法按实际环境调整
ip6tables -A INPUT -p icmpv6 --icmpv6-type 133 -j ACCEPT # 路由器请求
ip6tables -A INPUT -p icmpv6 --icmpv6-type 135 -j ACCEPT # 邻居请求
ip6tables -A INPUT -p icmpv6 --icmpv6-type 2 -j ACCEPT # 报文过大
# 放行前先确认策略顺序，避免后续规则把已放行的类型再次拦截放行清单
| 类型 | 名称 | 必要性 | 被拦截的后果 |
|---|---|---|---|
| 一到四 | 差错报文（含报文过大） | 必须 | 大包丢失、路径探测失效 |
| 一百三十三与一百三十四 | 路由器请求与通告 | 必须 | 无法自动配置 |
| 一百三十五与一百三十六 | 邻居请求与通告 | 必须 | 地址解析永远不完成 |
| 一百三十七 | 重定向 | 建议 | 路径次优但可用 |
| 一百二十八与一百二十九 | 回显 | 建议 | 排障手段缺失 |
照搬四层习惯整类封禁控制报文，会同时废掉邻居发现与路径最大传输单元探测，症状是地址解析异常加上大包丢光，排查时极易怀疑网络设备而不是防火墙策略。
放行不等于全开：可以按来源范围、接口与速率做限制，只对必要类型放行。这样既保留排障能力，也不至于把控制平面完全暴露。