上个月帮一个实验项目调容器网络，两个服务挂在同一个自定义 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-ip=fe80::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-ip=fe80::a1b2:c3d4:e5f6:700/64 \ alpine sleep 3600--link-local-ip可以重复传多次，给同一个容器配多个链路本地地址：
docker run -d --name ll-a \ --network ll-lab \ --link-local-ip=fe80::a1b2:c3d4:e5f6:700/64 \ --link-local-ip=fe80::a1b2:c3d4:e5f6:701/64 \ alpine sleep 3600如果你不写前缀长度，比如只写--link-local-ip=fe80::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 \ --subnet=2001:db8:abcd::/64 \ --gateway=2001: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-ip=fe80::a1b2:c3d4:e5f6:700/64 \ alpine sleep 3600 docker run -d --name ll-b \ --network ll-lab \ --link-local-ip=fe80::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 有 DAD（Duplicate 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-ip=fe80::...，进入容器却发现 eth0 上根本没有这个地址。原因往往是网络本身没有启用 IPv6。不同 Docker 版本处理方式不一样，有的会报错，有的干脆静默忽略。
所以在排障时，不要假设“写了就一定有”。配置完之后，第一时间执行docker exec <容器名> ip -6 addr show eth0确认。如果发现地址没配上，先检查网络是否开了 IPv6：
docker 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，不妨从这几个参数开始建立自己的地址规划。
