上个月帮一个实验项目调容器网络两个服务挂在同一个自定义 bridge 上IPv6 全局地址、路由表、防火墙规则看上去全都没问题可服务就是偶尔超时。把 tcpdump 挂到网桥上之后才发现问题出在一个很容易忽略的细节某个容器手工配置的链路本地地址前缀长度写成了 128和它自己该用的 fe80::/64 对不上源地址选择跟着出了岔子。这件事让我把 Docker 里LinkLocalIPv6Address和LinkLocalIPv6PrefixLen这两个参数重新翻了出来。它们在docker run命令里对应的入口是--link-local-ip但因为名字不够直白官方文档讲得也很简单很多人用过一次就再没碰过。这篇就把链路本地地址机制、配置方法、完整实验和常见坑一次说清楚。适合在 Docker 里做 IPv6 网络实验、做容器二层互通调试、或者被 fe80 地址冲突困扰过的读者。1. 链路本地IPv6在Docker容器里的存在方式1.1 链路本地地址到底是干什么的IP 地址里有一类比较特殊的角色它不追求全网可达只管当前这一条链路上的通信。IPv4 时代的 169.254.x.x 是这样IPv6 时代的fe80::/10也是这样。我们平时讨论 IPv6 地址通常看到的是2001:db8::这类全局地址但对协议栈来说链路本地地址才是真正“每时每刻都在用”的那个。IPv6 链路本地地址最常见的形式是fe80::/64前 64 位固定后 64 位由接口自己生成。它不像全局地址那样依赖 DHCP、路由器公告或者人工规划只要接口把 IPv6 协议栈打开内核就会自动生成一个。它干的活也大多和“邻居”有关NDP 邻居发现、无状态地址自动配置、路由下一跳解析。IPv6 路由表里的下一跳地址几乎都是链路本地地址因为你不会拿一个全局地址去当直连邻居的下一跳。你可以把链路本地地址理解成“同一桌人之间喊的小名”。饭局上喊一声“老张”全桌人都知道是谁但出了这个饭局就没人认识了。它不需要在全球范围唯一只需要在当前这条链路上唯一。这个特性放在容器网络里特别有用因为容器网络本质上就是一堆虚拟网卡挂在同一个桥接域里链路本地地址天然适合做容器之间的二层直连标识。1.2 Docker容器默认的fe80地址从哪里来Docker 给容器创建 veth 对时容器里的 eth0 默认就会启用 IPv6内核自动生成一个fe80::/64地址。实际环境里你经常会看到类似fe80::42:acff:fe11:2/64这种样式这是从容器网卡的 MAC 地址比如02:42:ac:11:00:02按 EUI-64 规则算出来的。也就是说容器每次被创建如果 MAC 变了链路本地地址也会跟着变。这个默认地址在大多数场景下够用但有两个麻烦一是不可控容器重建后地址就变抓包、防火墙、监控里很难用地址来指认某个容器二是不可规划当两个地址冲突或者多网卡环境里需要固定一个标识时你没有一个入口去规定它。Docker 因此留了--link-local-ip这个手段也就是标题里两个内部字段的来源。手动指定链路本地地址之后好处是可预期、可过滤、不随网络重建变化。比如你要做协议实验、要固定某个容器的 fe80 地址作为服务发现源地址、要在 tcpdump 里用一个稳定的过滤条件手动规划几乎是必须的。2. LinkLocalIPv6Address / LinkLocalIPv6PrefixLen 的真实入口与配置写法2.1 为什么docker run文档里搜不到这两个参数如果你去docker run的参考文档里搜LinkLocalIPv6Address大概率是搜不到的。因为它不是 CLI 参数而是 Docker API 和守护进程内部的数据结构字段。CLI 层的统一入口是--link-local-ip同时接受 IPv4 和 IPv6 地址。用户敲下--link-local-ipfe80::a1b2:c3d4:e5f6:700/64之后客户端会把它塞进网络端点的 IPAM 配置里服务端真正落到底层时才会把它拆成LinkLocalIPv6Address和LinkLocalIPv6PrefixLen两个独立的值。所以你在官方文档里搜不到这两个词并不奇怪它们属于“幕后字段”。但理解这一点很有用网上一堆讨论这两个参数的文章实际都是在说同一个东西只是有的人站在 CLI 层讲--link-local-ip有的人站在 API 层讲LinkLocalIPv6Address。如果你在看 Docker 的网络源码或者调 Docker SDK就会频繁碰到这两个字段名。2.2 命令行、Compose、SDK三种配置路径命令行是最直接的用法docker run -d --name ll-a \ --network ll-lab \ --link-local-ipfe80::a1b2:c3d4:e5f6:700/64 \ alpine sleep 3600--link-local-ip可以重复传多次给同一个容器配多个链路本地地址docker run -d --name ll-a \ --network ll-lab \ --link-local-ipfe80::a1b2:c3d4:e5f6:700/64 \ --link-local-ipfe80::a1b2:c3d4:e5f6:701/64 \ alpine sleep 3600如果你不写前缀长度比如只写--link-local-ipfe80::a1b2:c3d4:e5f6:700解析时会按 IPv6 默认/64处理IPv4 地址则默认/16。这个默认行为来自 libnetwork 的地址解析函数算是链路本地地址的规范做法。如果你用 Go SDK 操作 Docker API对应关系就很清晰了import ( github.com/docker/docker/api/types/container github.com/docker/docker/api/types/network ) endpointConfig : network.EndpointSettings{ NetworkID: ll-lab, IPAMConfig: network.EndpointIPAMConfig{ LinkLocalIPs: []string{fe80::a1b2:c3d4:e5f6:700/64}, }, } networkingConfig : network.NetworkingConfig{ EndpointsConfig: map[string]*network.EndpointSettings{ ll-lab: endpointConfig, }, } _, err : cli.ContainerCreate(ctx, container.Config{Image: alpine}, container.HostConfig{}, networkingConfig, nil, ll-a, )Python Docker SDK 的对应位置也是networking_config里的link_local_ips字段名保持一致。至于 Docker Compose我目前看到的规范里没有直接暴露这两个字段的标准键我的习惯是要么干脆用docker run要么在服务启动脚本里用ip addr add补地址。别在 Compose 文件里硬塞不存在的配置项容易造成误解。2.3 PrefixLen怎么填才不给自己挖坑链路本地地址虽然严格定义是fe80::/10但实际使用中大家都把它当作fe80::/64来管理后 64 位是接口标识符。因此你手工指定地址时前缀长度应该写64。如果写成128含义就变成“这个接口上只有一个孤立地址”。邻居发现仍然可以工作因为 IPv6 的邻居发现走的是链路层多播不依赖地址前缀匹配但内核在做源地址选择时会觉得你的目标地址和这个孤立地址“不在同一个子网”于是可能放弃它而去选其他地址甚至绕到全局路由上。我在开头说的排障故事根因就是这个。3. 只靠fe80地址打通两个容器一次完整实验3.1 实验准备与网络规划为了让你能直接照着跑我先给一个完整实验。思路很简单创建一个启用了 IPv6 的自定义 bridge 网络两个容器都不指定全局 IPv6 地址只给它们各分配一个固定的fe80::/64链路本地地址然后验证互通。docker network create -d bridge \ --ipv6 \ --subnet2001:db8:abcd::/64 \ --gateway2001:db8:abcd::1 \ ll-lab这里用了2001:db8:abcd::/64作为测试网段。需要注意这个子网和网关只是让 Docker 把网络的 IPv6 功能启用起来并不是实验真正依赖的东西。我们验证的是链路本地地址的直连能力就算容器后来自动多出一个2001:db8:abcd::开头的地址也影响不到 fe80 这条链路。3.2 启动容器并验证地址生效启动两个容器docker run -d --name ll-a \ --network ll-lab \ --link-local-ipfe80::a1b2:c3d4:e5f6:700/64 \ alpine sleep 3600 docker run -d --name ll-b \ --network ll-lab \ --link-local-ipfe80::a1b2:c3d4:e5f6:701/64 \ alpine sleep 3600然后进容器查看地址docker exec ll-a ip -6 addr show eth0输出里应该能看到类似这样的片段inet6 fe80::a1b2:c3d4:e5f6:700/64 scope link valid_lft forever preferred_lft forever同时你可能还会看到一个内核自动生成的 fe80 地址比如fe80::42:acff:fe12:3/64 scope link。这取决于 Docker 版本和网络的 IPv6 配置不是异常属于 IPv6 允许多个地址叠加在同一个接口上的正常表现。3.3 打通链路ping、邻居表、抓包三重验证从 ll-a 里 ping ll-b 的链路本地地址docker exec ll-a ping6 -c 3 -I eth0 fe80::a1b2:c3d4:e5f6:701如果镜像里的 ping6 不支持-I参数可以改用邻居表验证docker exec ll-a ip -6 neigh show dev eth0正常情况下你会看到 ll-b 的地址进入REACHABLE状态说明 NDP 邻居解析已经完成fe80::a1b2:c3d4:e5f6:701 dev eth0 lladdr 02:42:ac:12:00:03 REACHABLE想看得更底层一点可以在宿主机上找到该网络对应的网桥然后抓 ICMPv6 包docker network inspect ll-lab --format {{json .Options}} ip link show type bridge sudo tcpdump -i br-xxxxxx -n -e ip6在你第一次发起 ping 之前先清一下邻居缓存能更清楚地看到 NDP 的完整过程docker exec ll-a ip -6 neigh del fe80::a1b2:c3d4:e5f6:701 dev eth0然后重新 ping抓包里会依次出现 Neighbor Solicitation、Neighbor Advertisement以及 Echo request/reply。这里有个小技巧如果你想保证源地址固定用你指定的那个 fe80 地址可以在容器里加一条带src的主机路由docker exec ll-a ip -6 route add fe80::a1b2:c3d4:e5f6:701/128 dev eth0 src fe80::a1b2:c3d4:e5f6:700这样内核在选择源地址时就有了明确倾向排障时能少一些干扰。4. 我在实际配置中踩过的坑和排查思路4.1 前缀长度填128导致的源地址选择异常这是我最先踩的坑也是这组参数最容易出问题的地方。很多人配地址时习惯性写成/128觉得“反正就是给我这一个接口配一个地址”。对全局地址来说/128也许没问题但在链路本地地址上它会把地址从fe80::/64的公共子网里“抠”出来。具体现象是本机手工地址是fe80::a1b2:c3d4:e5f6:700/128对端是fe80::a1b2:c3d4:e5f6:701/64。NDP 解析没问题邻居表也能看到对端但 ICMPv6 就是不通或者延迟抖动很严重。因为内核在选源地址时认为你这个手工地址和目标是两个不同前缀的“孤岛”优先级不如接口上另一个自动生成的fe80::/64地址于是把流量从一个你意料之外的源地址发出去了。抓包一看源地址根本不是规划好的那个所有基于源地址的过滤规则全部失效。排查思路很简单先用ip -6 addr show eth0看每个地址的前缀把所有手工地址改成/64如果业务上确实需要多个链路本地地址也让它们都落在fe80::/64这个子网内。4.2 链路本地地址冲突与DAD失败链路本地地址不需要全网唯一但同一个链路内必须唯一。同一个 Docker bridge 网络上的所有容器属于同一条二层链路后 64 位如果冲突就麻烦了。IPv6 有 DADDuplicate Address Detection机制新地址加入接口后会发送邻居请求探测是否冲突。如果冲突地址会一直停留在tentative或者dadfailed状态。用ip -6 addr show dev eth0能看到这种状态地址前面会带dadfailed标记。遇到这种情况的典型场景是你手写了一个fe80::a1b2:c3d4:e5f6:700而另一个容器恰好通过 MAC 自动生成了完全一样的地址。虽然概率不高但在大规模容器编排里重复的容器 MAC 相同的自动生成规则会让概率明显上升。解决办法是手工规划地址时使用随机性足够强的后 64 位比如fe80::a1b2:c3d4:e5f6:700这种虽然好记但别让所有环境都用同一套更稳妥的是将容器 ID 的一部分映射到地址后 64 位里确保不同容器之间差异足够大。4.3 网络没开IPv6时参数可能被静默忽略我见过不止一次命令里写了--link-local-ipfe80::...进入容器却发现 eth0 上根本没有这个地址。原因往往是网络本身没有启用 IPv6。不同 Docker 版本处理方式不一样有的会报错有的干脆静默忽略。所以在排障时不要假设“写了就一定有”。配置完之后第一时间执行docker exec 容器名 ip -6 addr show eth0确认。如果发现地址没配上先检查网络是否开了 IPv6docker network inspect ll-lab --format {{json .EnableIPv6}}稳妥的做法是创建网络时显式加--ipv6并给一个测试子网。严格来说链路本地地址本身不需要全局子网但 Docker 对网络 IPv6 能力的开关管得比较死让网络先支持 IPv6再谈链路本地地址能少踩很多版本差异的坑。4.4 手动地址与内核自动地址并存给接口指定了手工链路本地地址后内核自动生成的 fe80 地址通常还在。也就是说一个 eth0 上可能出现两个scope link的地址一个是你指定的一个是自动生成的。我在某些版本里看到的是手工地址排在前面自动地址排在后面但有些环境里顺序会反过来。这不是 bug是 IPv6 允许一接口多地址的正常机制。但要提醒一句当你抓包或者做策略路由时别以为“我配了固定地址流量就一定从固定地址出去”。内核选择源地址有一套复杂规则自动生成的fe80::42:acff:fe12:3/64完全可能被选中。如果要求严格固定源地址用前面提到的带src的路由或者在应用层直接绑定地址。4.5 macvlan/ipvlan场景下的额外注意点bridge 网络里容器和宿主机之间隔着一层虚拟网桥链路本地地址虽然共享一个 L2 域但结构相对清晰。macvlan/ipvlan 就不一样了容器直接暴露在物理链路上宿主机的物理网卡自己也有一个 fe80 地址如果不小心把容器地址规划成和宿主机网卡相同的后 64 位DAD 会直接失败。另外macvlan 模式下容器和宿主机默认不互通所以从容器里去 ping 宿主机网卡的 fe80 地址不通反而是正常行为别拿 bridge 网络的预期去套 macvlan。ipvlan L2 模式虽然容器和宿主机可以互通但父接口和子接口共享同一个 MAC抓包时看到的地址关系比 bridge 更复杂。在这些网络驱动下建议先画清楚“谁和谁在同一链路谁需要唯一”再动手配置地址。5. 这几个场景用固定LinkLocalIPv6确实顺手5.1 本地服务发现与协议实验如果你在容器里跑 mDNS、avahi、zeroconf 之类的服务或者研究 IGMP/组播协议链路本地地址是绕不开的。很多服务发现协议的源地址就是 fe80 地址容器每次重建都换一个随机 fe80 地址的话对端的服务缓存、本地的防火墙规则、抓包过滤器全得跟着变。给容器规划一个固定 fe80 地址之后至少有三件事变简单抓包时直接过滤src fe80::a1b2:c3d4:e5f6:700防火墙规则可以按地址精确放行业务日志里记录的是可识别的容器身份而不是一串每次重建都不同的随机后缀。5.2 故障演练中的可控IPv6失效注入我做高可用组件的故障演练时经常需要模拟“IPv6 链路层出问题但全局地址看起来正常”的微妙状态。这时候固定链路本地地址的价值就体现出来了。在容器里执行ip -6 addr del fe80::a1b2:c3d4:e5f6:700/64 dev eth0可以精确地把规划好的地址删掉制造一个“链路本地能力异常”的故障。由于接口上可能还有其他自动地址删掉手工地址之后通信未必完全中断但这本身就是很好的演练素材——验证高可用组件在地址缺失、源地址切换、邻居缓存老化这些场景下的表现比单纯断网更接近真实故障。5.3 多容器桥接网络里的容器定位与抓包在几十个容器的桥接网络里单靠全局 IP 找容器其实很痛苦因为 IPAM 分配的地址和容器名的对应关系要看 Docker 的分配记录。但链路本地地址如果规划得够好可以直接从邻居表里反推容器。我的习惯做法是把容器 ID 的一部分映射到 fe80 地址的后 64 位里。比如某容器 ID 尾部是3f2a9c就规划成fe80::3f2a:9cff:fe00:1/64。这样在宿主机上执行ip -6 neigh show看到某个 fe80 地址时心里基本能猜到是哪个容器。配合 tcpdump 的icmp6过滤排障速度快很多。我自己现在做 IPv6 容器实验的标准动作就是三件套网络创建时开 IPv6、每个容器规划好fe80::/64的链路本地地址、抓包时统一过滤fe80::/64。这套习惯花不了多少时间但排障时收益很大。如果你也在容器网络里折腾 IPv6不妨从这几个参数开始建立自己的地址规划。