我断开IPv4整整一周，只为理解IPv6过渡机制
IPv6远不止是“简单”切换那么简单。
是时候谈谈让许多人感到不适的话题了。你们沿用传统方法的时间已太久。现在该转向IPv6了。
当然，IPv6远不止是“简单”切换那么简单。近25年来，全球仍有大量系统未采用IPv6。尽管当今软件支持几乎成为标配，但这并不意味着它已被广泛启用。许多网络管理员对IPv6心存畏惧或理解不足，由此产生诸多误解——我将逐一剖析这些问题。
但要向各位阐述未来网络的最佳配置方案，我必须先彻底理解所有IPv6过渡机制的工作原理。为探究过渡机制的失效点，我将进行为期一周的纯IPv6环境测试，并汇报实际运行中的可行与不可行方案。
首先必须强调：你们熟知且厌恶的NAT技术并非互联网协议初创时所设想，它在路由领域引发了诸多棘手问题。请停止将NAT视为安全机制，而应认识到它本质是应急的地址耗尽防护措施。同理，CG-NAT也是迫不得已才部署的紧急地址耗尽防护机制，除非万不得已，没人愿意启用它。当运营商部署CG-NAT时，请勿归咎于他们，而应拥抱IPv6和全球路由技术。
目录 §
IPv6速成指南§
自行部署IPv6时最大的障碍通常并非ISP支持、路由器支持或客户端支持。真正的难点在于如何摆脱传统网络设计的思维定式。IPv6并非简单复制IPv4的缺陷并扩展地址空间，而是回归互联网协议最初的设计理念——在地址耗尽前消除网络地址转换，更注重规范子网设计与路由机制。
以下是理解IPv6的关键要点：
- 地址长度为128位，由8个四字符十六进制块以冒号分隔(例如
fd69:beef:cafe:feed:face:6969:0420:0001) - 前导零可省略(例如
0420可简写为420，但不可简写为42) - 连续零组可用双冒号省略，但每个地址仅限一次(例如
2000:1::1，但不可写成2000::1::1，因其含义模糊) - 网络前缀(几乎)始终为64位长度，后接64位客户端后缀，采用CIDR表示法(例如
2000::/3) - 所有地址均应视为全局唯一，即使仅限于组织内部使用
- 鼓励在单个接口上配置任意数量的地址，以满足不同用途或范围需求
- 同样地，我们可以在同一二层域中部署多个路由器发布前缀，这种做法也值得鼓励
- 由于节点现在能够在广阔的64位本地客户端地址空间中自行分配地址，我们不再需要通过DHCP集中分配地址
- 由于所有地址均具备全局路由能力和唯一性，我们无需进行网络地址转换或端口转发
家庭实验室的优势 §
每当提及IPv6时，我总被反复问到“这对家庭实验室网络有何益处”。以下是您应在自有网络中启用IPv6的理由：
- 若您处于IPv4运营商级NAT环境中，您的IPv6连接仍可实现全球路由，并能接收VPN或游戏服务器等入站连接。我发现通过IPv6可在移动热点上托管服务器
- 诸如游戏等点对点通信通常需应对NAT穿透问题，但IPv6彻底解决了这一难题，尤其适用于多人共用同一网络连接的场景
- IPSec VPN虽应用广泛却常因NAT穿透困难导致性能不佳，而IPv6同样消除了此类问题
- 由于链路本地地址始终可用，点对点链路或孤立网络中完全无需分配地址
- 若需托管服务，无需通过不同端口或反向代理来分离单一广域网地址的单端口流量
- 该优势同样适用于单服务器环境：可为不同服务分配多个地址，甚至可使用相同端口
过渡机制 §
主要过渡方案包括双栈、SIIT、NAT64和464XLAT，其复杂度逐级递增且各有优势。
双栈方案 §
多数情况下最终将部署双栈网络。此架构下，IPv4与IPv6在整个网络中全面部署。资源可通过任一IP版本访问，所有网络段必须同时分配IPv4和IPv6子网，所有路由器必须同时维护IPv4和IPv6路由表。客户端可选择任一IP版本访问资源，通常会同时获取目标地址的A记录和AAAA记录。显然，这种方案对于仅含一台路由器的家庭网络尚可管理，但通常难以扩展。不过对于家庭网络或小型组织而言，这是部署IPv6最简便的方式。
无状态IP/ICMP转换 §
若希望避免重复配置路由表及所有路由设置，可完全迁移至IPv6，并在网络边缘实现IPv4与IPv6的无状态转换。此方法称为“无状态IP/ICMP转换”，最适用于数据中心等场景——其中每个需要访问公共IPv4互联网的设备都拥有公共IPv4地址。通过这种方式，IPv4公共地址可实现1:1的无状态转换至IPv6目标地址，并转发至纯IPv6服务器。这使得数据中心内部能完全采用IPv6运行，同时仍可为公共IPv4客户端提供访问通道。但需注意，此方法不执行传统IPv4网络中常用的源地址转换(NAT/伪装)。
NAT64 §
另一种机制是NAT64。其运作原理类似于“传统”IPv4 NAT：通过单个公共地址掩护一组地址池。但在此场景中，地址池采用IPv6而公共地址为IPv4。因此NAT64服务器接收原生IPv6客户端请求时，会将目标IPv4地址编码到目标IPv6地址中(可能使用已知前缀64:ff9b::/96并在末尾添加32位IPv4地址)。随后它会像IPv4 NAT那样执行协议、地址和端口转换，出站连接离开NAT64服务器时，便呈现为单个公共IPv4地址背后的常规网络。其缺点在于客户端必须明确知道应连接至IPv4目标地址。与传统NAT类似，这是一种状态化转换机制，将NAT64网关置于网络潜在瓶颈位置(正如NAT服务历来的特性)。
与NAT64最常配合使用的机制是DNS64。在此转换机制中，DNS服务器会识别其服务对象为纯IPv6网络，并知晓NAT64转换所用的前缀。当DNS服务器遇到无AAAA记录但存在有效A记录的查询时，会通过将A记录与NAT64前缀组合来合成AAAA记录。此时，任何使用DNS的客户端软件都会自动连接至NAT64网关，通过IPv6访问IPv4互联网。
464XLAT §
除DNS64外，NAT64网络中可部署的最终机制称为“464XLAT”。从概念上讲，它几乎等同于网络层NAT64与设备层SIIT(4→6 1:1 转译后接6→4 NAT)的组合，尽管由于开发机构不同，常采用不同术语。位于网络边缘的NAT64服务器通常执行客户端NAT或CG-NAT，被称为“PLAT”(服务端转换器)。每个客户端则运行自身的“CLAT”(客户端转换器)，该转换器在网络堆栈中为自身分配IPv4地址及IPv6地址，用于与PLAT通信。使用IPv4发送数据包的客户端应用程序将CLAT的IPv4地址视为默认IPv4路由，此时CLAT执行无状态的4->6地址转换。这消除了或减少了对DNS64的需求，对NAT64网关提出了类似的网络要求，并允许兼容客户端在需要直接IPv4通信时执行IPv4->IPv6转换。此方案通常应用于ISP网络中，因其NAT64/PLAT实体本就作为CG-NAT网关存在，可直接在调制解调器/网关上部署CLAT服务，为客户端提供无损的端到端IPv4体验。
在自有网络中，464XLAT的应用主要受限于客户端软件支持。iOS和macOS均具备原生CLAT功能且会自动激活，但旧版macOS及当前所有其他操作系统均不支持自动启用。不过，同一网络中可轻松部署464XLAT与DNS64双方案，因此不支持原生464XLAT的客户端将回退至DNS64，仅在特定点对点软件中使用IPv4字面量时可能出现问题。
经验总结 §
在经历一周无IPv4环境后，我总结出以下经验：
- IPv6早已具备全面部署条件
- 我常用的网站中约半数原生支持IPv6，需加大对网站管理员和CDN服务商的压力推动原生支持
- 从论坛讨论可见，管理员启用IPv6服务的积极性不足——或因漠不关心，或因同时维护公共IPv4和IPv6地址更耗精力
- 网络设计应优先采用IPv6而非IPv4，这种设计思路能有效解决多数核心问题
- 网络架构中应以NAT64替代传统NAT，该方案本质上可直接替换现有架构，仅需等待路由器软件支持优化
- DNS64本身作为过渡机制已基本可用，对于公共Wi-Fi或其他管理完善的网络而言可能“足够”——前提是您清楚哪些服务至关重要，或不介意点对点IPv4地址失效
- 464XLAT是无用户可见缺陷的解决方案，应成为ISP网络未来部署方向，需与CG-NAT结合使用
- 苹果设备对IPv6支持卓越，不仅在具备NAT64功能的设备上完全支持464XLAT自动配置，更以积极态度推动开发者强制采用IPv6支持
- 其他操作系统则表现参差不齐
本文由 TecHug 分享，英文原文及文中图片来自 I spent a WEEK without IPv4 to understand IPv6 transition mechanisms。
令我惊讶的是，互联网上竟有这么多技术达人仍认为IPv6是小众且不可靠的技术。
根据我的亲身经历，在美国，至少Spectrum、AT&T和Xfinity(康卡斯特)这些运营商虽然仍在运行IPv4，但其家庭网络服务中也默认启用了IPv6。
所有主流计算机和移动操作系统默认支持IPv6，并优先通过该协议建立连接。
在许多地区，“所有人”都在使用它。对我们中的许多人而言，父母正通过IPv6使用Facebook和观看Netflix。谷歌美国流量中超过50%已通过IPv6传输。它就是这么可靠。
作为主要手机运营商，T-Mobile旗下ISP仅提供IPv6服务。这意味着除非连接WiFi，否则手机永远不会获取IPv4地址。他们提供配备5G调制解调器和路由器的家庭接入点，外部地址同样仅支持IPv6。
运行效果相当出色。我通过IPv6访问所有可达资源，其余则通过其464XLAT透明传输。
我的局域网仍保留IPv4地址，因为某些老旧网络打印机不支持IPv6。路由器上的OpenWRT系统完美兼容IPv6。当然，除通过Wireguard外，我绝不将任何家用设备暴露在公共互联网中。
讽刺的是，T-Mobile还提供仅支持静态IPv4的商业服务。
我怀疑这是收购业务时保留的独立网络。
若服务区域相同，很可能是隧道传输。你难以想象ISP使用多少隧道技术——他们根本不会直接连接你的网络。
德国情况不同——我们的T-Mobile Business接入仅分配静态IPv6地址，而德国电信(同一家运营商)提供的主干光纤上行链路同时支持两种协议。
这算是某种意义上的“正常工作”吧。
比如我最近参加蒙特利尔IETF会议时，主办方默认提供纯IPv6网络。我的Mac运行正常，但儿子学校配发的Chromebook出现异常，直到我切换到提供IPv4的网络才恢复。
这正是IETF纯IPv6网络试图解决的问题类型。
几年前我去IETF会议时，就因家庭网络不支持IPv6而遭遇纯IPv6网络问题——当时我在家托管了一些服务。这让我下定决心要彻底解决这个问题。
我遇到的IPv6问题在于ISP(Xfinity)拒绝分配静态前缀，导致地址频繁变更。
不同于IPv4，我的局域网地址包含前缀，因此每次变更都会导致所有局域网地址同步更新。
再加上许多设备缺乏DHCPv6支持，这意味着无法通过IP反向解析主机名，使得通过IP识别设备几乎不可能。
我觉得你混淆了好几个概念。当ISP更改IP前缀时，IPv4本身并不能保证局域网地址稳定——这种稳定性是由路由器进行网络地址转换(NAT)实现的。当你从本地地址192.168.0.42发送数据包时，路由器会修改数据包中的字节，使其显示为X.Y.Z.W(路由器的公共地址)。若需要，路由器同样能为IPv6地址执行相同转换。
IPv6同样支持本地地址，且数量更为庞大。所有以 fd00::/8 开头的地址均为本地地址，其中 40 位作为网络号使用。因此你可以使用 fdXX:XXXX:XXXX::/48 前缀(X 为随机字符)构建本地网络，并保留 16 位用于划分子网。即使 ISP 更改公共前缀，这些地址也不会改变。
若需为SLAAC地址添加反向DNS，只需让路由器监听ICMPv6邻居通告地址，并据此更新DNS服务器。或者配置服务器使用基于MAC地址的稳定地址(而非更注重隐私的随机地址)，随后在添加或移除服务器时同步配置DNS。
请注意关联的广域网和局域网偏好设置。
哪些服务器？
局域网中通过DNS和IP连接的设备——正是这些需求促使我们寻求稳定的局域网IP地址。
这正是DNS的意义所在——免去记忆数字地址的麻烦。
若IP地址不频繁变更，DNS配置反而更简便。
这场讨论陷入了循环论证。
若正确配置DNS其实并不复杂。若你硬编码所有DNS地址，那才是错误做法。
那该如何正确设置DNS才能追踪台式机和打印机动态变化的公网地址？同时还得确保能继续使用SLAAC协议。
您通过NDP中的路由器/邻居通告注册地址。在您的RA中，需指向您的DNS服务器，当主机使用新IP地址进行注册时，该服务器将处理注册操作。
实际中有哪些DNS服务器支持此类动态DNS？
哇看，DNS有解决方案！
请问具体如何实现“正确”？
> 与IPv4不同，我的局域网地址包含前缀，因此每次变更都会导致所有局域网地址同步更新。
是的，这是IETF正在热议的话题。可参考BCP RFC 9096《改进客户边缘路由器对IPv6重编号事件的响应》：
* https://datatracker.ietf.org/doc/html/rfc9096
以及信息性RFC 8978《IPv6无状态地址自动配置(SLAAC)对闪存重编号事件的响应》：
* https://datatracker.ietf.org/doc/html/rfc8978
若干草案，如《增强无状态地址自动配置(SLAAC)对闪存重编号事件的健壮性》：
* https://datatracker.ietf.org/doc/html/draft-ietf-6man-slaac-…
使用ULA似乎是多数人的推荐方案：
* https://en.wikipedia.org/wiki/Unique_local_address
您应在网络中发布本地前缀(fd00::/8内的任意前缀)，此方案应能正常工作。局域网无需使用ISP提供的前缀。
若本地服务仍使用任何IPv4地址，可能存在地址源选择问题https://blog.ipspace.net/2022/05/ipv6-ula-made-useless/
这些算问题吗？只要任一寻址方式能正常工作且可达，谁会在意最终优先使用哪一种？
对于IPv6，接口拥有多个地址是常态：接口既包含ISP分配的公共地址(替代IPv4 NAT)，也包含唯一的本地地址(替代稳定的IPv4 RFC 1918局域网地址)。
我的ISP会根据需求为我分配任意数量的/64子网(默认应为/48，若需超过64k个子网则需说明理由)
因此我不存在IP频繁变更的问题。但若需更换ISP则会遇到麻烦——需要更新大量规则，而非仅修改几个DNS条目和两条目标地址转换规则(每个公共IP对应一条)。
我认为IPv6的设计理念是：同一网络可配置多个前缀(包括用于本地服务的fc00::/7前缀)。这意味着存在多层可能出错的环节。
奇怪。
使用基于Openwrt的家用路由器时，我只需告知路由器从前缀中分配子网的偏移量，其余工作它自动完成。
无论是ISP分配的前缀还是我用于内部设备的ULA前缀，都采用这种方式划分。
我更换过三次ISP，从未出现异常。即使ISP偶尔分配新前缀，系统依然正常运行。
唯一需要调整的情况是：从分配/48前缀的ISP更换为仅提供/56前缀时。当时我贪心将/56分配给内部路由器，后来改为/60，并更新其子网分配策略后一切恢复正常。
不过我认为双层无NAT家庭路由器配置算是特例。
对所有需要缩短地址的内部网络使用ULA(唯一本地地址)。其原理类似RFC1918地址，但无需NAT转换。
嗯…这是因为在IPv6环境下，从技术上讲你并不处于局域网中——除非特别配置，否则所有设备默认都是暴露的。
不，你确实处于局域网中，而且路由器通常默认启用防火墙阻断入站连接。某些操作系统(如Windows)也自带默认防火墙，出厂设置就禁止来自不同网络主机的连接。
除了IRC场景和忘记给命令行工具加“别慢吞吞”参数的情况，反向DNS还有实际用途吗？
启用DNS的traceroute会解析目标IP的PTR记录。
(ping命令同理)
嗯…我网络里遇到过奇怪问题，只能通过禁用IPv6解决。虽然可能是我搞砸了，但既然IPv4一切正常，我倒无所谓。总有一天我会深入研究它的原理，或许就能搞明白…总有一天…
随意猜测：PMTUD问题？就像v4那样，有些人搞砸了PMTUD设置却浑然不觉也无法修复，所以必须准备某种变通方案。
如果将客户端MTU设为1280(
ip link set mtu 1280 dev eth0或等效命令)就能神奇解决，那这就是症结所在。唉，真希望澳大利亚也能这样！墨尔本市区明明有高速现代的光纤网络，但我的网络服务商至今完全不支持IPv6。我每年都会提交一次工单，得到的回复总是大同小异——无非是说没有用户需求。
我本想测试所有托管的网络服务是否支持IPv6，却无能为力。至少不借助某种4to6中继方案就无法实现——但这会让所有操作都增加延迟。
刚查了下——原来我的ISP正在“评估IPv6”，因为IPv4地址耗尽了，他们打算给所有人启用CGNAT。虽然这算不上转向IPv6的最糟理由，但他们推诿多年了。真希望他们能尽快落实。
公司笔记本无法使用(他们版本的Windows似乎要求接口必须绑定IPv4地址，不确定是系统要求还是他们强制配置)
这并未消除对NAT的需求——我的有线ISP或许能与我建立BGP，但备用5G网络不行。当我需要通过PBR选择流量传输路径时，仍需进行地址转换。
我的路由器不支持IPv6，只能使用ISP提供的服务，其速度受限于原生IPv4网络。好吧，这属于我的设备配置问题。尚未测试5G运营商的IPv6支持，希望其网络能提供IPv6，但如何配置DNS64仍是难题。
仍需在网络边缘提供IPv4服务，因此必须使用46 NAT才能从仅支持IPv4的位置访问内部仅支持IPv6的服务器。
或许这些问题都源于路由器不支持IPv6，但这也再次证明IPv4仍是必需的。至今未发现纯v6服务，既然必须运行v4网络(哪怕仅作为v6到v4的NAT设备)，何必维持双网络架构？这只会增加两倍的配置错误风险和安全漏洞。在IoShit网络启用双v6将为恶意流量提供更多逃逸路径，意味着需要额外管理防火墙规则集。SLACC等机制使得网络设备识别更困难，如今许多终端设备对用户不友好，仅在v4网络中管控这些设备比同时管理v4和v6更省力。
> 这并不能消除NAT需求——我的有线ISP或许能与我进行BGP，但备用5G网络不行。当我需要通过PBR选择流量传输路径时，NAT仍是必需的。
确实可以。只需让每台路由器(有线和5G)分别发布各自ISP分配的/64前缀。主机将从每个前缀中自动获取v6地址。
要控制流量使用哪条链路，只需在路由器通告中设置优先级(这些都是radvd.conf中的标准配置)。
> 诸如SLACC之类的技术会让识别网络设备变得更困难
再次强调，这种说法并不准确。若您真的不信任设备，仅靠DHCP也无济于事。恶意主机完全可能自行分配未使用的v4地址，而仅查看DHCP租约根本无法察觉异常。
> 确实如此。只需让每台路由器(有线和5G)分别发布各自ISP分配的/64前缀，主机便会从每个前缀中自动获取v6地址。
> 要控制流量使用哪条链路，只需在路由器通告中设置路由器优先级(这些都是radvd.conf中的标准配置)。
你尝试过这个方案吗？实际效果如何？
我测试时发现，客户端常会用路由器A分配的地址向路由器B发送数据，且经常忽略优先级设置。根据RFC规范和客户端行为，路由器优先级字段仅在单次通告包含多个前缀时生效，否则最近通告优先。
既然需要聚合通告，不如直接采用NAT66方案，操作会更简便。
>他们的Windows版本似乎要求接口必须配置IPv4地址
可能是DirectAccess。这是微软在Always On VPN之前内置的VPN解决方案。DirectAccess仅支持IPv4入站连接，因此无法使用纯IPv6栈。底层虽采用IPv4-IPv6转换与翻译协议组合，但Windows客户端设备仍需具备IPv4地址。
若笔记本可执行PowerShell命令，且“Get-DnsClientNrptPolicy”返回DirectAccessDnsServers列表，则该设备属于DirectAccess笔记本。
对于消费级流量，你的判断基本正确。但在数据中心、云计算及各类企业网络解决方案中，IPv4仍是主流。虽然IPv6在这些场景下完全可行，但只要大型科技公司尚未耗尽其持有的CIDR地址段(或可选择使用私有地址段)，现有网络基础设施就缺乏改造动力。
> 云计算
不。大型数据中心底层仅支持IPv6，谷歌和Meta等超大规模企业已多次声明这一点。详见https://www.youtube.com/watch?v=Q3ird3UDnOA及多场NANOG会议记录https://www.youtube.com/@TeamNANOG/videos
底层网络或许采用v6，但这无法改变用户仍大量使用v4承载实际工作负载流量(即云计算部分)的事实。据我上次确认，EC2 VPC仍默认仅支持v4。
超大规模服务商 ≠ 云计算服务商。
大量家庭ISP也仅支持IPv6，会对IPv4数据包进行隧道传输。
亚马逊的情况如何？
我过去能用IPv6，但现在似乎完全失效了。使用Xfinity网络。我能访问外地朋友家的几台服务器，他肯定也没IPv6。或许打电话解决问题，但既然“一切”都还能用(靠IPv4)，也就懒得管了。
这实在奇怪，因为我用的是Comcast，他们对IPv6的支持非常出色。我唯一的抱怨是希望前缀能比/60更大(/56就很好)，以及希望住宅用户也能申请静态前缀。虽然你说过并不打算修复这个问题，但若情况有变，我认为他们应该能轻松解决。IPv6正是他们做得比较到位的领域之一。
好奇你究竟在做什么需要超过16个启用SLAAC的子网(或大量未启用SLAAC的子网)
作为本地交换运营商(ILEC)，CenturyLink仅通过6rd网关提供IPv6服务。其IPv6吞吐量仅为IPv4的零头，延迟也高得多。高峰时段6rd网关饱和，迫使我停止前缀通告才能恢复网络访问，这种状况已持续多年。
更无法针对IPv6故障单独报修。CenturyLink技术支持堪称灾难，客服人员除了点击“检查ONT”按钮和安排数天后上门维修外毫无作为。若询问6rd配置信息，他们会像听不懂外星语般茫然。
即便在技术人员中，IPv6知识也极为稀缺。试想：当价值数百美元的千兆光纤设备安装在你的分界点时，技术人员因你在“IP地址”前多说了两个音节就用看白痴的眼神盯着你。若非眼前站着真人，我简直要以为“IPv6”这个词会让聊天机器人当场崩溃。
结果就是他们的服务实质上仅支持IPv4。
我用过CenturyLink的CPE设备，只要传输分片IPv6数据就会崩溃。真是有趣：P。他们还死守PPPoE协议，至少在我这VDSL2线路里，根本没启用RFC 4638(婴儿巨型帧)来恢复1500MTU。现在用市政光纤真是太爽了(虽然安装费贵得离谱)。
是啊，我的路由器必须通过ONT设备进行标记式PPPoE连接，尽管我付费购买的是静态/28网段。至少不像Xfinity那样还得为子网配置RIP协议。
有趣的是，若订阅他们的IPTV服务，网络端就会变成裸露的以太网口——此时我可以为上游接口配置DHCP，并从我的/28子网中分配下游子网地址。
我甚至考虑过付费订阅电视服务，当作一种精神补偿费。
啊，经典的CenturyLink风格：“我们把TTY放进了TTY。” 庆幸没用电报传输IPv4。
> 它就是管用。
直到你想用GitHub之类的服务。
“管用”和“微软兼容”之间存在明确分界。
我讨厌这些公司强行制定标准。这种情况屡见不鲜，但他们确实投入巨资确保实践演变为标准。
他们玩转了“事实标准”的游戏…
例如：
微软Word文档格式。由于Word的市场主导地位，所有竞争对手的办公软件都不得不支持该格式，通常通过逆向工程破解未公开的文件结构。微软在不同版本间反复修改文件规范以满足自身需求，却始终沿用相同的文件扩展名标识符。
https://en.wikipedia.org/wiki/De_facto_standard
哇！你看到那些目标柱移到哪儿去了吗？
想必在微软崛起之前它们本可正常运作，后来就需要被“拥抱、扩展并消灭”了。
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis…
不过你的目标杆早就从“IPv6直接就能用”移到“纯IPv6环境才行”了。;)
说真的，我启用了IPv6，GitHub对我来说完全没问题。虽然有时速度会慢些，因为我所在区域的IPv4 CGNAT网络拥堵严重。
如果你把这算作IPv6正常工作，那当然可以。
过去十年间，我遇到的多数“网络故障”案例都是通过禁用IPv6解决的。每次都是AT&T运营商莫名无法稳定运行该协议。
我家使用Verizon网络，而他们在我所在地区(华盛顿特区附近)根本不提供IPv6服务。
存在诸多明显障碍使IPv6迁移对多数用户难以实现：
1. IPv6桥接技术无法大规模实用化，这意味着最佳方案是十年(或更久)的双协议共存——而没人愿意支持这种方案。
2. 实际部署必须实现无处不在(这永远不可能实现)。例如弗吉尼亚州的Glo光纤网络：虽然Pfsense能获取IPv6地址，但通常缺乏上游网关(意味着禁用IPv4后将完全断网)。之所以说“通常”，是因为我四次检测中仅有一次分配到网关，但该网关甚至对ICMP请求都毫无响应。
Starlink漫游服务——分配IPv6地址但无桥接功能，禁用v4后将失去大部分网络访问权限。
佛罗里达州Frontier FiOS网络——我的节点完全不支持IPv6。虽在奥兰多/坦帕的商业节点见过带桥接功能的地址分配，但缺乏浏览器及DNS解析支持，仍非实用方案。
3. 并非“所有人”都在使用IPv6，用户接入的设备本身就带有特定网络协议栈。这些用户不会为了规避CGNAT获取独立网络地址而刻意绕弯子。
4. 基础设施限制：我在东海岸两家规模可观的数据中心(esolutions和peak10)各租用半个机架空间，但两家主机商均未默认提供IPv6路由块。所有咨询过的服务商均未默认提供IPv6支持
“令人惊讶的是，互联网上仍有众多技术达人将IPv6视为小众且不可靠的技术。”
此类观点的具体出处何在？
多年来我读过许多关于IPv6优缺点的评论，但从未见过任何将IPv6描述为“小众”或“不可靠”的内容
注：此处要求的是引发引述声明的具体实例
这些实例必须出现在引述声明发表之前的论坛评论中
对引述声明的回应性评论(即后续发表的评论)不符合要求
你上方phil21的评论就称IPv6不可靠。
对许多人而言确实如此。
我在欧洲。我国ISP实际拥有过多IPv4地址，因此均未提供任何IPv6支持。
质疑并非全在“IPv6能否正常工作”，部分质疑在于“作为重视隐私和最小攻击面的终端用户，我为何需要它？”
从我的角度看：
• CGNAT是功能而非缺陷。我本就刻意通过共享数千用户的商业VPN出口节点访问网络。群体匿名性才是关键。IPv6赋予我全球唯一且相对稳定的地址反而会造成退步。
• NAT配合默认拒绝入站连接是简单有效的安全方案。诚然“NAT并非防火墙”，但无端口转发的NAT网关能确保未经请求的入站数据包无法触达我的设备。这是我免费获得的实质性特性。
• IPv6增加了我不需要的配置界面。隐私扩展、临时地址、RA标志、NDP协议、DHCPv6与SLAAC——这些都是IPv4中不存在的问题。更多功能意味着更多需要审计、理解和可能误配置的环节。
• 我早已在不使用全球地址的情况下解决了“访问自有设备”的问题。Tailscale/Headscale为我提供了认证加密的NAT穿透连接，这比全球路由能力更实用。
没错，我父母用IPv6看Netflix。他们不会考虑威胁模型，但我会。仅使用IPv4配合CGNAT+覆盖网络的方案完全满足需求。
“它就是管用”不是我采用IPv6的标准。“能否更好地实现我的目标”才是标准，而IPv6从未达到，也永远达不到。
IPv6的设计初衷绝非“增加位数的IPv4”，而是对网络运作方式的重新构想：将全球可寻址性作为核心特性，采用无状态自动配置，并预设终端节点应当可达。这种理念已融入其基因。对于像我这样将隐蔽性、间接性与最小功能面视为资产的威胁模型从业者而言，IPv6不仅毫无必要，其理念更与我的需求背道而驰。
要我采用新地址方案？那就给我新地址方案，别强加带有偏见的路由理念给我。
> 群体匿名性才是关键
仅适用于基于IP的追踪器。任何嵌入Facebook/Twitter/微软/谷歌追踪器的网页，都已通过多种指纹识别技术使你身份暴露。这包括使用隐私浏览模式时，甚至在qubesOS系统下也无法避免。做这些事时你会感到不安(我也做过这些事)，但这场战役早已败北。
> NAT + 默认拒绝入站是简单有效的安全方案……这是我免费获得的实质性特性
这取决于你对“免费”的定义。仅查询连接状态表更省成本，还是同时查询连接状态表和NAT表更省成本？
> IPv6增加了我不想要的配置界面……更多功能意味着更多需要审计、理解和可能误配置的环节。
完全赞同。复杂性增加意味着攻击面扩大，出错概率上升。
> 我已通过非全局寻址方式解决“访问自有设备”问题……这比全局可路由方案更优。
我也采用类似方案。它更私密更安全，但确实增加了复杂性，且限制了我从非自有终端访问资源的能力——除非另设暴露向量。所谓“更好”取决于优化的指标标准。
> IPv6的设计初衷并非“IPv4的位数扩展版”，而是对网络运作机制的重新构想：将全局可寻址性作为核心特性
恕我直言，全球可寻址性作为核心特性恰恰是互联网的原始设计理念。NAT最初只是作为权宜之计的临时补丁，用于缓解IPv4地址空间不足的问题，直至后续协议解决根本矛盾。
不过必须承认，90年代的互联网与当今已截然不同。基于当前网络环境，你的诸多担忧和观点完全合理且极具说服力。
> “能否更好地满足我的需求”才是衡量标准，而IPv6从未达到且永远无法达到……若要我采用新地址方案，请提供真正的替代方案，而非强加主观的路由理念。
IPv6完全可配置为仅提供新地址方案，同时消除诸多复杂性。但你们偏离了理想路径，用……新的复杂性取代了原有的复杂性。
顺便说一句，我的家庭网络架构与你如出一辙。自2000年代起我就采用双栈网络。自IPv6最初以纯粹教条形式出现以来，技术已取得长足进步。
感谢您的深思熟虑的回复。
关于指纹识别，公平地说，世上没有“万无一失”的防护，但我确实构建了相当稳健的防护体系：DNS层级的广告与追踪器拦截、浏览器扩展层级的广告与追踪器拦截、LibreWolf浏览器的全面反指纹措施、内核层级的kloak防护、默认拦截所有第三方JS等。我的目标并非让国家机构完全无法追踪(当全球90%以上的ISP都能且确实出售网络流量元数据时，这种目标本质上不可能实现——即便采用背景流量伪造/流量模式混淆技术，仍可通过时序和数据包大小关联实现跨跳追踪)，而是要挫败低级别的追踪尝试，主要出于安全考虑减少攻击面， 同时减少向攻击者传递的信息总量——即便这在技术上可能增加用户标识的独特性。例如我的浏览器默认禁用WebGL、JS即时编译、WASM、WebRTC甚至SVG渲染功能，仅根据访问网站的重要性进行个案选择性启用。我会逐一伪造用户代理、屏幕尺寸，并使用住宅SOCKS5代理，以识别YouTube等平台采用哪些指纹识别措施来封锁我——前提是未启用即时编译或SVG渲染功能。这种做法确实会让我更容易被识别(匿名性降低)，但未必会降低隐私性或安全性——比如广告网络的JS代码从一开始就无法在我设备上运行。安全是金字塔的基石，是隐私的前提但无法保证隐私；隐私是中间层，是匿名的前提但无法保证匿名。我正积极攀登这座安全金字塔，在净收益为正的情况下接受某些权衡。我认为安全、隐私和匿名性并非二元属性，而是我正在逐步迭代提升的统一旅程。转向IPv6将极大复杂化并逆转我已完成的旅程进程。
若能请您思考以下问题：您从IPv6中获得了哪些IPv4无法实现的切实效益？采用双栈方案的投资回报率，是否已超过您为安全处理边缘案例、应对异常路由问题、偏离标准路径所投入的时间、精力和配置成本？
> 您从IPv6中获得了哪些IPv4无法实现的切实益处？
个人网络：全球唯一地址体系。这意味着无需为服务配置任何分区DNS，也无需担心自家网络与所接入局域网的地址冲突。
工作网络：收入增长。
> 双栈部署的投资回报率是否超过了您为安全处理边缘案例、应对异常路由问题(偏离标准路径)所投入的时间、精力和配置成本？
个人网络：绝对没有。我已移除双栈配置，全面回归纯IPv4环境。
工作网络：这得问财务部门。
> 任何嵌入facebook/twitter/microsoft/google追踪器的网页都已使你身份暴露
我敢打赌楼主至少已屏蔽其中三家。隐私浏览仅是部分解决方案，针对性地屏蔽/放行域名、脚本等才是抵御滥用行为、捍卫隐私权的可靠方式(指uMatrix/uBlockOrigin这类精细化广告拦截工具)。
我承认这有时很麻烦，尤其对每日上网的人而言，但远离不良行为者(如上述四家中的某些)或许能最终遏制他们——即便“用点击投票”和“用脚投票”一样显得徒劳，毕竟你只是千万网民中的一员。
若未注册任何账户，那四大追踪器究竟能多精准地追踪你？
极其精准。无需账户即可生成唯一指纹，这些指纹终将与某处身份信息关联——数据经纪商的存在正是为此服务。
嗯，这算是某种意义上的“直接生效”吧。
比如我最近参加蒙特利尔的IETF会议——堪称IPv6思想的发源地——那里默认提供纯IPv6网络。我的Mac运行正常，但儿子学校配发的Chromebook一直卡顿，直到我切换到提供IPv4的网络才好转。
通过Terraform管理IPv6的AWS基础设施依然很麻烦。
我属于“小众”——但遇到过Wireguard无法通过IPv6连接到IPv4网络的问题。除此之外，我大部分时间都在IPv6环境下工作，正如你所说，它确实能正常运行。
没错，大型企业资源最雄厚，这很合理。
但多数企业并非如此。
远超多数的个体经营者、中小型企业并非如此。
这包括B2B企业、区域性ISP等。
我在内部局域网使用IPv4，并关闭IPv6
它支持完善、配置简便、私密且安全。
…而且我无需并行配置和保障IPv6的安全性
说得太对了！我猜不少技术人员在家里用IPv4网络的时候，他们的非技术背景的父母、邻居和朋友早就开始用IPv6了(甚至都不知道自己在用)。
家庭环境中使用IPv4极其简单。只需记住末位数字(除非有多个网络，但多数家庭不会)。通过记住“.1”代表路由器、“.2”代表NAS等规则，即可SSH连接任意设备。防火墙配置也十分简便。
购买廉价域名作为家庭DNS(例如“router.myhome.net”对应“192.168.0.1”)即可实现全局访问！无论在家中或通过VPN漫游时都有效。其实我无需在家运行DNS，我的域名托管在Cloudflare DNS，设备使用NextDNS(并为家庭域名禁用了rebind保护)。
我运行OpenWRT系统，为所有已知设备预分配DHCP地址，随后将DHCP地址池缩减至黑名单范围。脚本会自动为预分配设备创建DNS记录。若有新设备出现在黑名单DHCP池中，我可手动为其MAC地址分配正确IP。
利用ACME DNS01验证机制，为家中任何服务获取TLS证书都轻而易举。
Tailscale曾表现出色，直到某次漫游时突然无法连接(需人工干预)，我当即弃用。现转用平淡无奇的OpenVPN Cloud(限额免费)，两年多来从未出错。更重要的是它不会用花哨的尾网地址干扰IP——我直接通过DNS域名访问设备，这些域名解析为私有地址。
因此，无论身处家中还是在外，我都能访问NAS观看电影、将照片同步到Immich、打印文档、查看IP摄像头，甚至能让妻子把文件放在老式扫描仪上，通过树莓派的phpscan网站(网址为https://scanner.myhome.net)直接获取文件。
我确信这样做肯定存在重大隐患，想必有人会立即指出问题所在。
# 家庭网络部署IPv6极其简单。只需记住末位数字即可(除非存在多网络环境，但多数家庭不会遇到)。通过记住“.1”代表路由器、“.2”代表NAS等规则，可SSH连接任意设备。防火墙配置也极其简单。
# 购买廉价域名作为家庭DNS(例如“router.myhome.net”解析为“2003:123:4:5::1”)，即可实现全局访问！无论在家中或通过VPN漫游时均有效。其实我并不需要在家运行DNS。我的域名托管在Cloudflare DNS，设备使用NextDNS(并为家庭域名禁用了rebind保护)。
# 我运行OpenWRT系统，为所有已知设备预分配DHCP地址。随后将DHCP地址池缩减至黑名单范围。脚本会自动为预分配设备创建DNS记录。若新设备出现在黑名单DHCP池中，可手动为其MAC地址分配正确IP。
# 通过ACME DNS01验证机制，为家中任何服务获取TLS证书都轻而易举。
这里v4和v6完全没有区别。
那为何还要折腾v6？
> 家庭环境的IPv4配置简直简单到离谱
完全同意。我偶尔尝试在家“升级”到ipv6，但总因要进行毫无意义的企业级复杂配置而放弃。
编辑：
本质上IPv6过于复杂且自动化，普通人根本无法轻松记住家庭网络的全部配置。
所以技术宅除非痴迷复杂配置，否则不会在家里设置。他们不熟悉这项技术，在工作中也不会推动采用。
推广完全由IPv4地址枯竭驱动，完全没有“新玩具！”的兴奋感。
依我之见，取消NAT才是真正的“新玩具”。它让端到端连接重获新生。任何点对点应用在IPv6上都运行得更顺畅，若你正在开发此类应用，这确实是重新实现的可能性。
你可以尝试使用fd00::1、fd00::2…作为简短的内部静态地址。你不必必须使用该范围内的随机前缀——这只是政策要求(出于合理原因，但对小型网络可能无关紧要)。
> 任何点对点应用在IPv6上运行都更顺畅，若你正在开发此类应用，现在终于能真正实现。
没错，我的Windows主机又能被外部访问了——只要微软默认开启的服务都能被利用…
防火墙固然存在，但潜在攻击者连路由器后方存在什么都不知道，不是更好吗？
附注：自从WebRTC横空出世肆意操控我的网络后，点对点对我而言就意味着“向某家公司捐赠资源”。
IPv4网络通常仅分配一个公共IP地址，用户通过NAT配合端口转发实现外部连接。这种架构下，攻击者只需扫描路由器上的65536个端口，就能穷举整个网络中所有公开可访问的服务器——这仅需约3兆字节流量，耗时几乎为零。
而在v6网络中，无需NAT且网络为/64地址段。要定位所有服务器需扫描2^64个IP地址上的65536个端口，这将产生约720亿PB的数据流量。虽然存在缩减搜索范围的方法，但无论采用何种手段，搜索空间仍远超v4。
若想让攻击者无法知晓路由器背后的网络结构，v6才是正确选择。
> 彻底枚举整个网络中所有公开可访问的服务器
企业思维。我担忧的并非公开服务器，而是那些本不该公开的设备…
正是这个意思。在IPv4环境下，无论是否有意为之，从互联网可达的所有服务器都易如反掌。而在IPv6环境中则并非如此。
需注意IPv6比某些人想象的更易扫描。无需扫描全部2^128个地址——可查阅注册表中的服务商地址块，推测(或实际验证)该服务商为每台服务器分配的地址块大小，进而判断服务器在各块中对应::1或::2地址。虽非穷举扫描，但仍能发现大量服务。
你还可以监控证书透明日志获取主机名。但关键区别在于：没有NAT时，知道网络中一台服务器的信息并不能自动推导出同一网络中其他可访问服务器的IP。你必须逐个尝试主机IP地址，而不能指望路由器自动完成地址转换。
我惊讶于互联网上竟有这么多技术达人仍认为IPv6是小众且不可靠的技术。
越是精通该领域的人，越会意识到相较于IPv4，IPv6确实存在可靠性问题。不过它或许已不再是小众技术了。
遗憾的是，对于许多骨干网络而言——不仅限于美国本土网络——IPv6仍被视为次要考虑。在相同地理位置、相同转接服务商提供的网络资源中，通过IPv4终端与IPv6终端服务的客户端性能指标存在显著差异。
这与“正常工作”的定义背道而驰——具体取决于你如何定义“正常工作”。相比IPv4，IPv6每传输一位数据所需的流量工程工作量要大得多。
> 诸如游戏等点对点通信通常需应对NAT穿透问题，但IPv6彻底解决了这一难题，尤其对共享同一网络连接的多名玩家而言
当第二项“优势”纯属理论推演时，可见其“益处”清单何其单薄。即便IPv6无需NAT穿透，仍需突破路由器防火墙——本质上仍是相同难题。多数ISP提供的家用路由器会默认阻断所有入站IPv6流量(除非存在出站流量)，且几乎不支持自定义IPv6规则。
即便如此，我敢打赌真正采用纯点对点网络的热门游戏几乎为零。
突破防火墙远比突破典型的NAT+防火墙组合容易得多
https://tailscale.com/blog/how-nat-traversal-works
如何穿透防火墙？必须手动开启端口，所谓“穿透防火墙”实为防火墙漏洞。
这是uPnP的常见功能，自2000年代中期起我就看到路由器配置页面中包含此特性。
https://en.wikipedia.org/wiki/Universal_Plug_and_Play#NAT_tr…
启用uPnP的防火墙总让我忍俊不禁。既然允许任意设备随意穿透防火墙，还不如干脆关掉防火墙算了。
典型防火墙会记录出站IP数据包的源/目标头值，然后临时允许具有相反源/目标值的入站数据包通过。
你这纯属断言，未作解释。若我理解有误请指正，但据我所知NAT穿孔的唯一区别在于客户端无法预先知晓其公共端口映射。这实际上对流程影响不大，因为实际操作中仍需中央会合服务器来自动发现对等IP。另一种方案是让每个对等节点通过外部服务(如IRC或Discord)手动向所有其他节点“离线”共享IP地址，这将带来极其糟糕的用户体验。
> 你这番论断缺乏依据。
他们附上了整篇文章详述NAT穿透的复杂性。
我认为显而易见的是：移除整个泄露抽象层后流程将大幅简化。没错，协调服务器依然必要，但无需推导入出端口映射，只需共享每个客户端的“外部IP”——在IPv6场景下这根本不算“外部”，就是“该IP本身”。
我早已了解NAT穿透原理。附上泛泛而谈的说明文章并非有效回应。
况且NAT本身是相当简单的抽象机制，本质上就是一张映射表。
>况且NAT本身是相当简单的抽象机制，本质上就是一张映射表。
…现在，让我们尝试在这个“简单”的表上打个洞。哎呀，有人使用了端口限制型或对称NAT，穿透操作就变得稍微复杂了些。
同意；或者对方使用了CG-NAT，或是CG-NAT后端的消费级NAT，又或是…
> 它仍需穿透路由器的防火墙
正因如此，多数路由器采用状态防火墙。这样无需“穿透”防火墙，只需从本地建立连接即可。
> 除非存在出站流量，否则阻断所有入站IPv6流量，且几乎不支持自定义IPv6规则。
这正是STUN协议存在的意义。
> 我敢打赌，真正采用纯点对点网络的游戏几乎不存在。
用于游戏状态传输？你说的没错。但用于低延迟语音聊天？这种场景比你想象的更普遍。
> 只需从本地端建立连接即可
这正是问题所在。除非你期望用户通过外部服务手动向特定游乐厅中的每位用户共享其IP地址，否则就需要建立一个中央对等发现和连接协调机制，而这种机制最终会与经典的NAT穿透技术极为相似。
复杂性源于临时端口接收外部连接时——这才是关键环节，而非端口创建本身。此类操作未必能被防火墙支持，或至少比单纯部署状态防火墙复杂得多。
获取主播IP会招致DDoS攻击和个人信息泄露，因此游戏中使用P2P技术普遍被视为安全隐患。
没错，P2P仅适用于好友或熟人网络，否则等同于公开发布私人地址供所有人查看。
每天下午四点不用面对拥堵的CGNAT网络，这点优势很棒。
NAT66技术同样存在，我在家庭网络中就使用它。因此仍需配备NAT穿透设备以备不时之需。能像弹性IP那样使用公共地址而非端口转发，体验确实更佳。IPv6拥趸们别再强行宣称IPv6世界里不存在NAT了。
> 地址中连续零组可用双冒号省略，但每个地址仅限一次(如2000:1::1，而2000::1::1因含糊不清不可用)
能否解释为何会产生歧义？
说到底，IPv6是互联网最奇特的发明之一。无论从哪个角度看，其实用性和可行性都显而易见——除了…唯有一点例外。
网络相关事物通常易于记忆并脱稿输入：IPv4、域名、标准端口号。早年电话号码亦是如此——简单易记，需要时随手拨号。而IPv6地址过于冗长，始终需要复制粘贴。在我看来，这正是IPv6注定在未来数十年内沦为二等公民的唯一根本原因。
2000:1::1 展开为 2000:0001:0000:0000:0000:0000:0000:0001
2000::1::1 可能表示为 2000:0000:0000:0000:0001:0000:0000:001，或 2000:00000000:0001:0000:0000:0000:001
第二个地址存在歧义，无法确定五个0000组应填入何处。
第二个地址无效。每个地址中仅允许使用一次::。
编辑：哎呀，没看清上面回复的内容。我的失误。
这正是问题的核心所在，他们已解释了无效原因…
> 在我看来，这才是 IPv6 注定在未来数十年内沦为二等公民的真正原因。
除非你使用的是手机——许多电信运营商仅向移动终端分配IPv6地址。2018年NANOG会议《T-Mobile的IPv6转型之路》报告：
* https://www.youtube.com/watch?v=d6oBCYHzrTA
摘自2014年《案例研究：T-Mobile美国采用464XLAT实现纯IPv6网络》：
* https://www.internetsociety.org/deploy360/2014/case-study-t-…
但谁会在乎手机呢？它们不过是二流设备罢了。
我的T-Mobile 5G调制解调器虽有IPv4地址，但每次加载网页都会变换IP，简直离谱
我习惯了有线调制解调器能保持静态IPv4数月之久，除非MAC地址变更
莫非是100.64.0.0/10？
* https://en.wikipedia.org/wiki/IPv4_shared_address_space
可能是21.0/8
参考：https://old.reddit.com/r/tmobileisp/comments/1gg7361/why_is_…
我使用T-Mobile SIM卡启动了LTE路由器。
不到一小时就更换了WAN IP地址。两者均来自AS749 美国国防部网络信息中心
这些地址被CGNAT转发至T-Mobile公布的ASN后方。
您的IPv4数据包正被隧道传输至拥有IP地址池的CGNAT服务器。
若您的网站支持IPv6，手机端加载速度将更快。这是因为数据包可采用更直接的路由(无需经由中央CGNAT服务器)，且处理过程更简化。如今几乎所有移动网络都采用纯IPv6架构，IPv4流量需经隧道传输并通过CGNAT处理。显然T-Mobile是罕见的例外。
> 我的T-Mobile 5G调制解调器虽有IPv4地址，但每次加载网页都会变换IP，简直疯狂
他们很可能使用了CG-NAT技术，不过如此频繁的IP变更确实有些激进。
> 他们很可能使用CG-NAT，不过IP变换如此频繁确实有些激进。
T-Mobile使用国防部地址空间内的IPv4地址。这些地址确实会频繁意外变更。
没错。由于是国防部IP地址，它们被隐藏在T-Mobile公共ASN背后的CGNAT中。
我自古以来就这么说了，而网络从业者往往不以为然。“直接用DNS不就行了”——那些从未真正从事过网络运维或开发运维的人总这么说。
地址长度过长及其笨拙的ASCII表示形式，绝对是IPv6推广如此缓慢的首要原因。用户体验是影响大规模普及的最强驱动力，而IPv6的用户体验糟糕透顶。
我认为通过改进ASCII表示形式能部分改善用户体验，但这需要大量协调工作——当年就已困难重重，如今更是难如登天。若有人告诉我五百年后我们仍在运行完全未变的IPv4/IPv6双栈，我定会深信不疑。
地址看起来如此糟糕的原因(字面意义上)有一半并非源于IPv6本身，而是因为人们出于隐私考虑，总在子网内选择随机化地址并循环使用。
例如2600:15a3:7020:4c51::52/64尚可接受，但2600:15a3:7020:4c51:3268:b4c4:dd7b:789/64却因客户端无关的意图而变得极其冗长。
这点说得相当到位。若合理规划子网并为主机分配较低地址，IPv6寻址本可相当简洁。但主机自身会放弃这种设计，随机生成64位主机地址——有时甚至每次新连接都生成新地址。结果单台计算机连接互联网时就产生数千个IPv6地址。
消费级设备的“现代”工具对IPv6的支持同样堪忧。现实中能实现的最佳方案是广域网侧支持IPv6，而本地网络全用IPv4——至少我近期接触的热门路由器都是如此。
多年来我始终惊叹于许多顶级路由器竟默认禁用V6功能。
当然我明白缘由。开启V6会因复杂性增加而略微提升边缘案例问题概率。多数用户无需主动启用，故无人察觉。
对了，我忘了SLAAC和那些毫无价值的隐私扩展。
隐私扩展毫无价值，因为指纹识别和追踪手段实在太多了。若连VPN和沙盒化隐私浏览器都懒得用，你根本毫无胜算。真正重视隐私的人必须使用Tor这类工具。
IPv6隐私扩展就像GDPR的Cookie规定——徒增烦扰却毫无实效的对策。
SLAAC同样糟糕。他们本该像V4那样将地址分配权交给管理员或更高层级协议，那样更合理。
正是这些隐私扩展阻止了ISP根据你家联网设备数量收费。
如今多数人本就直接使用ISP提供的路由器作为网关。例如AT&T光纤自豪地宣称能识别ONT+路由器组合中的每台设备——这甚至成了设置端口转发的唯一途径(不能直接输入IP地址，必须选择已发现的设备)。
“但用户可用另一台路由器对v4进行NAT隐藏！” -> 没错，同样拙劣的解决方案在v6上也适用。
“但专业用户至少能通过克隆标识符和特定硬件替换ONT” -> IPv6环境下同样无法改变。
随机化地址确实存在合理应用场景，尤其当连接非自有Wi-Fi网络时，若设置为每次连接随机化MAC地址(而非仅扫描MAC)，但我不认为当前描述的案例具有现实意义。
你改变了我的看法。这个角度我确实没考虑过。
尊重你对新信息的考量。
若ISP尝试此举，用户只会集体回归NAT，即便在IPv6环境下也是如此。
我在之前的帖子中提出过这个观点，结果遭到猛烈抨击。我觉得你说得对。每次看到IPv6地址，我脑子里就冒出“搞死它”的念头。
IPv4虽不完美，但它本就是为解决特定问题而设计。
IPv6的设计过程充满政治博弈。工程师们轮流提出各自的痛点诉求，以此换取足够支持推动提案。当一群计算机人意识到政治斗争有多艰难时，他们发誓永不再犯，于是把地址空间扩大到荒谬的程度，声称就此“一劳永逸”解决了问题。
我坚信，若当初采用任何其他策略——让最基础的网络运维人员也能理解并有效使用地址——我们本可在十年前就实现“IPv6”普及。
我个人倾向于开放E类地址空间(240-255.*)，收回亚马逊囤积的6个/8地址块，未来实施更智能的分配机制，并根据持有地址数量按对数递增收取费用。
> IPv4虽非完美，但其设计初衷正是为解决特定问题集。
IPv4并非为实际应用而设计，而是作为一项学术练习。它是一场实验。一场“逃离实验室”的实验。正如文特·瑟夫所言：
* https://www.pcmag.com/news/north-america-exhausts-ipv4-addre…
若你认为IPv4设计中不存在政治因素，那你就大错特错了：
* https://spectrum.ieee.org/vint-cerf-mistakes
> IPv6的设计过程贯穿政治考量。
除非你所谓的“政治过程”指的是：一群人(线上线下)聚在一起讨论方案，最终选出他们认为最优的选项。IPng的选拔标准有据可查：
* https://datatracker.ietf.org/doc/html/rfc1726
当时存在多个提案，最终入围三项，最终选定SIPP方案：
* https://datatracker.ietf.org/doc/html/rfc1752
> 我坚信，若当初采用任何其他策略，使地址能被技术水平最低的网络运维人员理解并有效操作，我们本可在十年前就实现“IPv6”的普及。
IPng的核心诉求在于实现>32位的地址空间。若要缩短地址长度，唯一途径是减少位数，这将彻底背离该项目的初衷。
要从32位升级到32位以上，就必须为每个设备元素(主机、网关、防火墙、应用程序等)的网络堆栈编写新代码。任何改变sockaddr->sa_family类型与大小的改动(以及新增DNS资源记录类型：如仅支持32位的A记录；参见addrinfo->ai_family)，都将导致代码更新需求。
以上多为针对性论述，现回应最后一点：
> 从32位向>32位迁移时，若不为所有设备组件(主机、网关、防火墙、应用程序等)的网络堆栈更新代码则无法实现。任何改变sockaddr->sa_family类型与大小的变更(以及新增DNS资源记录类型：如A记录仅限32位；参见addrinfo->ai_family)都需编写新代码。
这种说法完全错误。IPv4头部尚存1位保留位(即“恶意位”)，本可用于标记负载前N字节为附加IPv4.1头部——该头部承载额外路由信息。数据包仍可穿越现有网络，而边缘设备若支持“4.1”协议，即可读取附加信息在网络内部进行后续路由决策。这种方案能有效利用IPv4作为核心传输网络，每个接入网络(可理解为ASN)仅需管理少量路由的/32子网。
覆盖网络已广泛部署，技术问题微乎其微。
但这仅能解决地址耗尽问题。工程师常陷入“既然要改代码就顺便改”的思维陷阱。
IPv6被视为与地址扩展同等重要的明确目标，是通过减少字段数量并实现精确对齐(不同于IPv4头部)来简化数据包头，从而实现更快的硬件路由。
你描述的方案未能达成这一目标。
你提这个正合我意，这恰是IPv6的另一大症结。它试图解决的诸多问题如今已不复存在。
90年代路由器采用通用组件时，报头处理与对齐确实是难题。如今我们拥有现代定制ASIC芯片，能在MPLS上的VLAN内以线路速率处理GRE隧道中的IPv4数据。我家里的交换机就能处理780Gbps流量。
我们现在能做什么无关紧要。
在设计之初，IPv6是经过精心设计的，远优于IPv4——毕竟这是在多年使用IPv4积累经验后的必然结果。
IPv6设计者仅犯过一个错误，但却是致命错误：本应将IPv4地址空间纳入IPv6体系，实现新旧地址间的透明互通。
正是这个缺陷导致IPv6过渡进程如此缓慢。
> IPv4地址空间本应纳入IPv6空间 […]
参见RFC 1884第2.4.4节(1995年)及后续RFC中定义的IPv4映射(“IPv4兼容”)IPv6地址：
* https://datatracker.ietf.org/doc/html/rfc1884
* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse…
> IPv4地址空间本应纳入IPv6空间，从而实现任意IP地址间的透明互通——无论其是旧版IPv4地址还是新版IPv6地址。
你会如何实现它，使其与实际存在的NAT64不同，包括将所有IPv4地址塞进64:ff9b::/96？
理想情况下，464XLAT本应从一开始就存在，且其主机部分(CLAT)应成为IP协议栈的强制组成部分。
> 这种说法完全错误。IPv4头部确实还剩一个位(即保留位/“恶意位”) […]
很好，IPv4数据包头确实存在额外位。
我指的是操作系统中的数据结构：sockaddr结构里是否存在额外位用于向应用程序传递信号？若没有，就必须部署全新的结构体。
这还没算上需要在所有系统部署新DNS代码的问题。
但v6确实实现了你描述的功能？
他们并未使用保留位，因为已有专为此设计的字段：下一协议字段。将其设为0x29即可指示负载前几个字节包含v6地址。每个v4地址都通过此机制隧道连接到/48的v6空间，任意两个v4地址都能通过它进行v6通信(包括与这些地址背后的整个网络通信)。
如果基本实现你建议的方案都不足以让你停止抱怨v6的设计者，那他们还能怎么做得更好？
我认为他们本该直接从IPv4头部挪用1-2位用于扩展路由功能，这样就足够用了
这需要所有主机和路由器安装新软件及专用ASIC芯片，且无法兼容旧系统。既然要引发这些问题，不如直接增加96位而非2位，这样就不会很快再次面临相同困境。
IPv6本质上就是IPv4加上更长的地址、微调(如取消校验和)以及可选功能(如SLAAC)。这难道不是你想要的吗？你究竟想要什么？
更新版本解决旧版所有缺陷有什么问题吗？
IPv4地址数量远少于全球人口，根据鸽巢原理，根本不可能为每个人分配独立IP地址——更别提还要为服务器分配地址了。仅扩大6%的地址空间根本解决不了任何问题，我不明白你为何认为它能解决问题。
> 每次看到[冗长]的IPv6地址，我的大脑就发出“去他妈的”的抗议。
我理解这种感受，但我也明白“地址数量如此庞大，我本可以随心所欲分配…前提是我们的光纤ISP能支持这项技术”
当我意识到这是2^64个子网时终于豁然开朗。你拥有一个/48的公共前缀，这其实比IPv4地址长不了多少——尤其考虑到当前普遍采用2001::/16格式，这意味着你只需记住32位网络前缀，就像12.45.67.8/32那样。
现在变成2001:0c2d:4308::/48
之后只需记住子网编号和主机编号。若你记得12.45.67.8对应192.168.13.7，那么可能有
2001:0c2d:4308:13::7
即子网“13”与主机“7”
这与记忆12.45.67.8对应192.168.13.7并无太大区别
> 尤其当所有地址似乎都采用2001::/16格式时
这周我其实早有预感。
我不得不为一次广域网测试(相距几英里)转录一个v6地址。
这时我注意到Charter(Spectrum)分配了
参考：https://bgp.he.net/AS33363#_prefixes6
当前全球单播地址空间实际仅限于2000::/3。
https://www.iana.org/assignments/ipv6-address-space/ipv6-add…
> 网络相关操作通常凭记忆输入很简单[但]IPv6地址实在太长
两分钟前我又遇到了这个问题：从一个IPv6广域网测试另一个时，动态域名解析失效，导致我无法依赖惯用的辅助手段。
> 有人能解释为什么它存在歧义吗？
因为你无法确定中间的0001两侧各有多少个零。
可能是 2000:0000:1:0000:0000:0000:0000:1，也可能是 2000:0000:0000:0000:0000:1:0000:1 等。
IPv6的这种缩写系统反而更糟糕。其规则实在难以记忆。
真的难以记忆吗？语法本身就藏着线索。两个冒号’::’之间是什么？空位。换言之，全是零。
IPv4也有类似的快捷方式，只是很少被记录或使用。比如尝试
ping 1.1，它会展开为1.0.0.1。“::代表全零”这么难？？
到底有多少个零？
恰好填满地址所需的位数，地址长度始终固定。顺便一提，IPv4本质上采用相同机制。地址127.1等同于127.0.0.1。
其实并不相同，其机制存在差异，这种特殊行为更多是偶然现象，而非简写。
在IPv4中，127.257等同于127.0.1.1，123456789等同于7.91.205.21，而010.010.010.010是公认的DNS服务器地址。这种记法同样被多数实现所拒绝。
是吗？这些替代性IPv4表示法在Linux、FreeBSD和MacOS中均被接受。我记得三十多年前在老SunOS主机上就玩过“替代表示法”。
但IPv6“太复杂了”
总共8组4位十六进制数字，所以用8减去已有的组数即可。
google.com: 2607:f8b0:4009:819::200e (5组) -> 2607:f8b0:4009:0819:0000:0000:0000:200e (3组补零)
一个 ULA 地址：fd2a:1::2(3组)→ fd2a:0001:0000:0000:0000:0000:0000:0002 (5个追加)
localhost: ::1 -> 0000:0000:0000:0000:0000:0000:0000:0001
无论剩余多少。在什么情况下需要关注？
只要能让整个A::B数精确达到128位长度即可。
“足够多”
不只是“::全为零”这么简单
…比如？
https://news.ycombinator.com/item?id=46338674
这是篇讨论无效内容的帖子，这些内容并非IPv6地址。
在IPv6地址中，::代表全零序列，不存在歧义。
我不明白你的观点。楼主的说法成立。双冒号仅代表零值(经过压缩未显示)。
你提供的链接并非展示有效压缩后的不同地址，而是展示无效压缩后的不同地址。该链接恰恰说明了我们不该采用的做法。
反之，若将你链接中展开的地址进行压缩，将得到两个不同的压缩地址。
这仅适用于自动生成/SLAAC IP地址。相比之下，手动分配的IPv6地址通常比IPv4更简洁易记。我有一个通用子网前缀，可统一划分至终端网络，且该网络IP地址的末位数字始终为0(因此首台设备地址为xxx::1)。而在IPv4中，我曾使用多个前缀，每个前缀根据预期终端网络设备数量进行非统一划分。由于多数终端网络前缀小于/24(如/26-28)，不同网络的IP地址末段数字存在差异。
确实如此，但无法回避的事实是：随着互联网设备数量激增，IPv4地址池早已被耗尽数个数量级，地址长度必须延长。
或许可以借鉴BIP-39方案设计地址助记短语，但这不过是换汤不换药。
第一个1在2000:和末尾:1之间的位置规则是什么？::规则规定“全零”但未说明长度。
这其实是套复杂的“减法”规则。地址始终为128位长度，即8组四位十六进制数字。2000::1仅占两组，因此中间需填充六组数字才能构成2000:0000:0000:0000:0000:0000:0000:1。但我始终不解为何总有人问这个问题，因为执行减法的永远是你输入地址的计算机。你根本无需输入完整地址，只需输入简写形式即可——因为2000::1本身就是完整地址。
他们是在回答“若允许使用’2000::1::1’为何会产生歧义”的问题。
:1本质上是:0001的简写，只需将地址末尾部分置于末尾，将开头部分置于开头，然后用0000填补中间缺失的组别即可。
“简单”
没错，确实“简单”。这根本不算难。
正是这类抱怨让我确信对v6的反对并不严肃。
好吧，那请示范如何执行这些步骤。
“：1 实质是：0001 的简写”很简单：得到 2001::0001::0001。
接着说“把那部分放在最末尾”——但具体是哪部分？若指“:0001”，那有两个这样的序列，不可能都放在最末。若非指此，又未说明具体是哪部分。无论哪种情况，我都看不出这些说明如何能被遵循，更别说轻松操作了。
我的回答过于简略。若地址中存在两个::，则每个::标识的区段长度皆不确定。它可能是左侧最长的::区段，也可能是右侧最长的::区段，而规则并未定义——因为规定中明确指出仅存在一个::区段。
此问题实为刻意设下的陷阱。
网络管理员对IPv6仍存在诸多误解，他们要么心存畏惧，要么未能真正理解这项技术。
在TP-Link Omada路由器(ER7212PC)上启用IPv6后，所有内部服务都会暴露在外部网络中——因为该设备既没有默认的IPv6全拒规则，也没有IPv6防火墙功能。我理解为何有人会感到不安。
这更证明TP-Link不可信，而非IPv6本身存在问题。即便是20美元的AliExpress廉价路由器，默认也启用了防火墙。
赞同。
我认为这更像是固件中的漏洞，其实早就修复了。
就ER7212PC而言，仅在v2硬件版本中修复。
没有免费升级。
这是个被故意留下的漏洞，因为IPv6的安全防护更复杂。
路由器转发流量会让人紧张？这不正是它的本职工作吗？如果我的路由器不转发流量，我反而会恼火。
当然，如果ER7212PC是防火墙那另当别论。
(且非吹毛求疵：路由器默认应转发流量，防火墙默认应阻断流量。这两类设备的功能本质不同，恰巧都处理第三层协议数据单元而已。)
路由器和接入点通常也属于不同设备类别。但市场早已发现，多数消费者更青睐一体化设备。指望家庭用户在全功能WiFi路由器之外还运行专用防火墙，简直荒谬。
对于普通用户，你建议将ER7212PC(顺带一提，它已身兼VPN网关和云控制器三职)搭配哪款防火墙？
问题在于TP-Link对其产品安全性毫不重视。
> 而且不，我并非在吹毛求疵
你确实如此。
> 然而市场已发现多数消费者偏好一体化设备。指望家庭用户在AiO无线路由器之外再运行专用防火墙简直荒谬至极。
但ER7212PC及Omada子品牌下的所有设备，本就不是面向消费者/家庭的设备。Omada的宣传语是“网络赋能企业”：
* https://www.omadanetworks.com
若要拖拽船只就该买F-150皮卡，别抱怨高尔夫的牵引力不足：针对具体需求/任务选择合适工具。若需全能设备，请购买一体机而非路由器。
>> 且非吹毛求疵
> 恰恰相反
指望路由器不转发IPv6才是不合常理的想法。
您是在建议家庭网络用户同时购买路由器和防火墙吗？按您的观点，还该另购独立Wi-Fi接入点和一两个交换机？
> 您是在建议家庭网络用户同时购买路由器和防火墙吗？
我的观点是ER7212PC并非家用网络设备，因此将两种功能强行整合实属设计缺陷。Omada的宣传语是“网络赋能企业”：
* https://www.omadanetworks.com
默认不转发IPv6的路由器设计，本质上是对其功能定位的误解。
您当然有理，但多数人会持反对意见——现实世界远比理想状态复杂，人们需要基础保障。必须记住：尽管每位网络工程师都清楚IPv4 NAT并非真正的安全保障，但人们仍依赖它——事实上它确实起到了安全作用。
> 必须记住：尽管每位网络工程师都清楚IPv4 NAT并非真正的安全保障，但人们仍依赖它——事实上它确实起到了安全作用。
若需要默认NAT功能及其他消费级特性，就去买支持这些功能的设备。别抱怨通用路由系统默认转发IP数据包——无论IPv4还是IPv6。
想要防火墙就买防火墙。想要集防火墙/网关/接入点于一体的设备，就去买。
在此特定案例中，“问题”不在设备本身，而在于选错了工具。若要运输木材，该买货运厢式车或皮卡，而非大众高尔夫。
“防火墙”只是数据包过滤的俗称，而数据包过滤属于路由器可提供的功能范畴。
客户边缘路由器应具备防火墙功能(参见RFC 7084和RFC 6092)。
> 客户边缘路由器应具备防火墙功能(参见RFC 7084和RFC 6092)。
ER7212PC及Omada系列的任何其他产品均不适用于住宅用户，而RFC 6092《为提供住宅IPv6互联网服务推荐的客户终端设备(CPE)简单安全功能》所指的正是住宅用户。
而RFC 7084中出现两次“防火墙”一词，其中一次(§3.1)涉及IPv4 NAT：
另一处(§4.5)则涉及隧道技术：
我认同面向消费者的全功能防火墙/网关/接入点等设备应(“必须”？)对传入连接采用默认拒绝策略。但引发本讨论的原始投诉针对的是特定设备——该设备并非消费级产品，而是更通用的路由系统，且严格来说不属于“防火墙”范畴。
用户期望路由器通过NAT功能同时充当防火墙。若取消此功能并迫使用户另购硬件恢复预期功能，他们不会更换设备。道理就是这么简单。
所有现代NAT路由器都内置防火墙。它们并非“通过NAT兼具防火墙功能”，而是同时具备NAT和防火墙能力，即使在IPv4环境下亦然。这种设计已沿用多年。
> 所有现代NAT路由器都内置防火墙。
据我所知，ER7212PC并非“NAT路由器”，而只是普通“路由器”。
甚至某些交换机也具备IP层的ACL功能，但它们被标榜为交换机而非防火墙。
没错，但人们仍将NAT作为保护内部网络的安全手段，因此它实质上发挥着防火墙的作用。
以下是中国当前的IPv6计划[1]。即将结束的“十四五”规划明确提出，要使中国大部分互联网接入采用IPv6。目前中国约70%的移动用户已使用IPv6，但固定网络IPv6流量占比仅为27%。
[1] https://www.cac.gov.cn/2025-05/20/c_1749446498560205.htm
不过该报告发布后，其IPv6部署率从40%左右大幅跃升至53%。
https://stats.labs.apnic.net/ipv6/CN
> 我花了一周时间断开IPv4连接，只为理解IPv6过渡机制
> NAT64——本次测试采用的配置方案
> IPv6早已具备全面部署条件，且持续成熟多年
所以…不，你实际是通过额外步骤同时使用v6和v4才撑过一周。若有人宣称“Linux已准备就绪”，却只能靠在Windows虚拟机运行大量应用才能工作，我认为这恰恰证明它根本不成熟。此处情况相同。
不过…这段内容出自2023年初。现在情况可能改善了？
> 话说回来…这可是2023年初的旧闻。现在情况好转了吗？
前阵子我家WiFi意外切换成纯IPv6模式持续数周。直到GitHub无法加载时才察觉(我在家避开工作事务，因此很少访问GitHub)。
顺带骂一句GitHub，他们推行IPv6简直一团糟。现在这状况只能用纯粹的无能来形容。
> 不，你其实花了一周时间通过额外步骤同时使用v6和v4。
不过步骤确实减少了。你可以在纯v6环境中完成所有网络配置，再为需要v4的用户设置模拟环境。没错，完全关闭v4目前仍不现实，就像在ARM架构的Mac上关闭Rosetta功能一样不现实。
我前同事Marco Davids(来自.nl顶级域名运营商SIDN实验室研发部门)在2021年进行过一项实验：他主动禁用了测试网络中所有组件的IPv4支持，甚至在FreeBSD内核中彻底禁用了IPv4协议栈(当时Linux系统尚不支持此操作)。迄今为止，这是我所知唯一接近真实模拟纯IPv6环境的测试案例。
https://www.sidnlabs.nl/en/news-and-blogs/can-we-do-without-…
AAAA记录解析才是普及的真正瓶颈。当双栈环境运行正常后，我进行了一项现实简单的测试：在路由器上释放ISP的IPv4 DHCP租约(终止udhcpc进程)，并在主机端清空DNS缓存。此时所有公共DNS查询都必须解析为IPv6域名。你很快会发现互联网上仍有大量域名未配置AAAA记录。许多热门服务将直接因硬编码域名的解析失败而瘫痪。证毕。
https://whynoipv6.com/
我居住地没有一家ISP提供NAT64网关服务。唯一一家曾宣传过该服务的供应商，我近一年前就注册了，至今仍未为我开通(我怀疑他们根本不提供这项服务，只是忘了撤下宣传页面)。
不行，因为遗憾的是IPv4的需求并未改变。换言之，许多网站和互联网部分仍仅支持IPv4。
在几乎所有服务都迁移至IPv6之前，放弃提供IPv4访问的机制并不现实。
我遇到的两个IPv6问题(即便过去曾使用过HE隧道)：
– 我的本地ISP(US Internet，即将并入T-Mobile Fiber)始终未启用该功能，尽管其CEO在Reddit上承诺多年这是优先事项。如今被收购后，不知何时才能实现。
– Linode允许在服务器间转移v4地址，因此重建服务时无需联系通常掌控DNS的客户。但他们不支持转移v6地址，这意味着我能控制v6访问的网站仅限于那些由我掌控DNS的站点。
若能花几小时解决这些愚蠢的懒惰问题，让IPv6普及似乎会变得超级简单。
> 我的本地ISP(美国互联网公司，即将并入T-Mobile光纤)至今未启用IPv6，尽管其CEO在Reddit上宣称这是优先事项已有多年。如今被收购后，谁知道这事儿会不会实现。
所谓优先级并不等于高优先级。它可能确实是优先事项，但排名垫底，所以其他事情永远优先处理。:P
美国T-Mobile无线业务对IPv6投入颇深，若他们接管网络，很可能会大力推进。
两年前它“终于排到了项目清单首位”，且看后续吧哈哈。
所谓“T-Mobile光纤家庭网络”似乎是由他们收购的本地ISP组成的联盟，且行且看。USI的客服和稳定性一直很出色，希望这次别搞砸。
今年初转用支持IPv6的ISP时，我遇到了些烦人的小问题。Ubuntu因区域服务器配置错误无法更新；OpenDNS的某台服务器在IPv6连接下时常无法访问；还出现过异常行为和延迟问题——IPv6偶尔会短暂路由失败，导致网络切换回IPv4。
这段排查经历令人痛苦：究竟是我的配置错误？开源路由软件的问题？还是ISP或终端服务端故障？在反复排查和报错未果后，我最终放弃了。由于故障具有间歇性，始终无法收集到ISP认可的完整问题报告。
因此我决定暂缓推进，一年后再尝试看看情况是否改善，但显然它尚未准备好投入实际应用。
我每年都会尝试启用IPv6。上次在家尝试时，我完全搞不清自己的子网掩码和分配地址段大小。有人说我的ISP分配的是/60，也有人说是/64。我同样搞不清如何让IP地址保持静态足够长的时间来维持持久的TCP会话。简直一团糟，和20年前初次尝试时(当时开启IPv6导致各种故障不得不关闭)相比也没好多少。
也许2026年才是IPv6真正普及的年份。考虑到连我这种外行都用不来，专业网络人员至今仍弃用IPv6，我对此表示怀疑。
何必费心配置？开启IPv6后，路由器会从上游设备获取前缀，再将网络广播给终端设备。
IPv6的子网掩码基本固定为/64。ISP分配/60前缀以支持多子网，但路由器会从中生成/64子网。
虽然不是楼主，但当初为家庭网络学习IPv6时，我发现配置路由器时必须确保DHCP-PD请求的前缀长度完全正确，否则系统将彻底失效。
我使用康卡斯特服务，他们确实分配了/56前缀，但你无法在DHCP-PD请求中直接申请/56——因为他们不支持单次请求获取全部前缀空间。必须分批申请/60前缀，这点是我通过反复尝试才摸索出来的。
但情况可能更糟(记忆模糊)，记得有次我确实成功获取了/56前缀，但这耗尽了DHCP分配额度，重启路由器后便再也无法获取任何前缀。更糟的是，当时使用的Unifi安全网关似乎无法维持Comcast认可的静态设备标识符(DUID)，导致每次重启都会分配新的前缀地址。
康卡斯特(Comcast)目前自带电缆调制解调器/路由器的用户恐怕寥寥无几，以至于他们基本不提供相关支持。通过电话咨询根本得不到任何帮助，只会被推销租用他们的设备(这些设备都按其网络要求预先配置好)。要想用自有设备运行IPv6，你得有冒险精神才行。
不，你需要了解很多细节。
广域网侧是使用SLAAC还是DHCPv6？那么局域网地址范围该如何获取？是通过DHCPv6前缀分配？还是采用静态分配？有些运营商在广域网侧直接使用链路本地地址，不分配公共v6地址，仅通过RA获取链路本地地址，并通过IA_PD获取GUA地址块。
无论如何，实现方式过于多样化，这阻碍了普及进程——毕竟这并非你所说的“一键开启”那么简单。
这些都由系统自动处理。唯一遇到问题的是那些想手动配置的人。更重要的是，这和IPv4中使用DHCP或手动配置并无二致。
几乎所有ISP都采用DHCPv6-PD，因为手动配置难度更大。地址范围由DHCP-PD提供，路由器自行选择子网。广域网地址是自动分配的，无需关注——毕竟你永远看不到它。我的地址是链路本地地址，直到检查才发现。
我需要知道网络可能分配的IP地址范围，以及计算机应分配的IP地址(或可静态分配的地址)。
地址需在自动配置完成后才能获取，这与IPv4和DHCP并无二致。
若不希望内部使用公共地址，可分配ULA地址。若不愿使用MAC派生地址，则分配静态主机地址。
域名方面我采用mDNS。我并不了解服务器的IPv6地址，若真需要的话会从路由器获取。
IPv6普及的最大障碍，或许在于客户端IP分配方式的繁杂多样性。
对移动运营商而言尚可应对——客户端激活机制已定义需求，运营商只需支持两大系统(iOS和Android)。
家庭用户场景也基本可行，当运营商提供CPE设备并能根据网络架构进行配置时。
但若需自行管理路由器，则面临复杂的配置选择难题。而多数ISP的技术支持也难以令人满意。
专业人士尚可应对，但对于非全职网络人员的高级用户而言，其复杂程度远超合理范围。
若使用AT&T光纤服务，体验堪称灾难。其默认路由器仅支持申请单个/64网段转发。若需多VLAN环境，必须编写脚本申请更多网段，即便如此也仅能获得8个。网关会从分配的/60网段中保留其余8个用于自身。
我唯一能让IPv6正常运行的方法是绕过他们的网关。现在所有VLAN都拥有标准子网大小的/64地址。
我认为绕过网关——即自带路由器——是实现VLAN的唯一途径，因为他们的网关功能极其基础，完全不支持VLAN。
其实通过他们的网关也能实现VLAN，但仅限IPv4环境；若需IPv6，则必须编写自定义脚本申请额外IPv6分配。
有意思。你用的哪款网关型号？我用的BGW320确实不支持VLAN标签功能。
> 运营商部署CG-NAT时不必抱怨，不如拥抱IPv6和全球路由。
理论上这有道理，但实际经验是：我接触过的所有部署CG-NAT的有线ISP都未提供IPv6服务，询问时也无人表现出任何意愿或兴趣。
反观移动运营商，几乎全线采用IPv6优先策略，默认通过6>4转换机制提供v4访问——对此我全力支持。
4>4 CG-NAT本就不该存在，那些部署该技术却未提供完整v6功能的运营商理应受到谴责。
若您的ISP仅提供IPv4，OpenBSD可轻松实现通过NAT64/DNS64连接IPv6 tunnelbroker.net(官方称“距离实验室测试仅一步之遥…”)。
该方案已稳定运行数年。我通过VLAN将纯IPv6网络(家庭实验室)与家庭视频流媒体设备隔离。
在我的pf.conf配置中：
在 /var/unbound/etc/unbound.conf 中：
完成。虽然我在Win11上没有464XLAT，但还是想确认是否存在硬编码的IPv4地址。我从未遇到过问题。
忘记了pf.conf中最关键的部分！
我是不是漏看了什么？他实际讨论当周经历的部分在哪？这段内容直接从IPv6概述跳到了结论部分。
本帖的提问让我非常惊讶。有些极其基础的概念竟无人理解。我怀疑那些抵制IPv6的人根本没花时间研究过它。确实存在难度——它与IPv4行为差异显著，且私有地址耗尽的问题也可能令人震惊。
支持者们没搞懂的是：正常人根本无法直观理解IPv6地址——它们看起来像三倍体MAC地址，记起来或输入起来烦死人，对非网络工程师毫无益处。而且家用路由器用户带着几十台设备的人数，可比运营ISP、财富500强企业及数据中心的人数多得多。你们尽管玩你们的卷积理论吧，二十年后我们这些普通人仍会愉快地使用192.168.x.x地址并对此置之不理。IPv4地址枯竭对普通人而言，就像海底光缆或证书颁发机构问题一样无关痛痒。
> 正常人根本无法直观理解IPv6地址
若有人连“它更长”都无法理解，那问题出在哪儿？
用十六进制替代十进制表示计算机魔术数字，理应更直观而非更晦涩。
从结构上看，前半段是子网，后半段是主机。这比IPv4直观得多。
> 对非网络工程师毫无益处
只要涉及任何点对点操作——通话、文件传输或游戏——都有益处。随着越来越多的ISP部署CGNAT，这种典型优势将随时间增长。
> 用十六进制代替十进制表示计算机魔术数字，理应更直观才对。
如何？对非网络从业者而言，十六进制比二进制或MD5哈希更直观的依据何在？
>只要涉及点对点操作——通话、文件传输或游戏——便存在优势。随着更多ISP部署CGNAT，这种优势将持续增强。
再次质疑：如何增强？近三十年来我始终无障碍进行上述操作。用户能看到什么可量化的好处？这些问题难道不是从Windows XP时代就该解决了吗？
难道我的团队在1000/1000兆稳定光纤连接下通话时，突然不再出现“网络连接差”提示？种子下载突然能找到更多种子和对等节点？我的游戏延迟会降低？因为我想不出还有什么网络问题是几十年前就该解决却至今未解决的。
所谓益处，理应能通过某种方式感知或量化，而非依赖仪表盘和价值数百万美元的机架设备。
> 用户能获得哪些可量化的益处？这些问题难道不是从Windows XP时代就存在至今吗？
设备能自动连接，无需手动端口转发(即便该功能可用)。
穿孔技术在CGNAT环境下极其不可靠。
> 我的团队在1000/1000兆稳定光纤连接下，通话是否会突然不再出现“网络连接差”提示？
我不清楚Teams的数据传输机制，但某些服务确实可能出现这种情况——当IPv4无法建立直接连接时。
> 种子文件会突然找到更多种子和对等节点吗？
是的。典型种子网络中，能接收连接的种子和对等节点比例微乎其微。若您仅通过CGNAT使用IPv4，将无法连接这些节点，反之亦然。IPv6能建立更多连接。
> 我的游戏延迟会降低吗？
这取决于游戏设计。但部分游戏确实能降低延迟，因为它们能直接连接玩家而非通过中继。
> 具体机制？对非网络从业者而言，十六进制地址比二进制或MD5哈希更直观吗？
那么192.168.0.0/27的地址范围呢？对普通人来说同样难以直观理解。
归根结底，IP地址是为计算机设计的，而非人类。
另外…顺便提一句，
>种子文件会突然找到更多种子和对等节点吗？
这说明你绝对没在CGNAT环境下尝试过种子下载。那简直是种折磨。
没有一个种子能主动向你发送数据，客户端必须自行搜索种子节点，而且连接到1-4个种子节点的情况并不少见！
从结构上看，前半部分是子网，后半部分是主机。这比IPv4直观得多。
此规则仅适用于/64地址块，而这类地址块绝非标准配置。例如tunnelbroker.net会免费提供/48地址块。这意味着IPv6地址本质上可免费获取数十亿个，但从外部难以判断它们所属地址块的大小。
无论前缀长度如何，IPv6子网始终为/64。较短前缀仅意味着可拥有更多/64子网。
> 直观理解IPv6地址，因为它们看起来像三倍体MAC地址，记起来或输入起来都令人头疼
我关联的IP地址超过500个。根本不可能去记住它们。输入？你整天都在输入IPv4地址吗？而且99%的情况还是复制粘贴。
> 对非网络工程师毫无益处
非网络工程师应该使用名称。更何况非工程师根本不“操作”IP地址。看看你爷爷——他在浏览器搜索框输入“bbc”就能访问bbc.com。
> 正常人都无法直观理解IPv6地址
但99%的所谓工程师连IPv4都搞不懂。所以这根本不是问题。
我同意。
告诉别人连接203.0.113.88这类地址很简单。我们这些技术人员乃至普通用户，几十年来都习惯用这种点分十进制格式表达地址，这种表达方式早已成为脱口而出的熟悉韵律。
但要让人记住2601:3c7:4f80:1a01:4d2:3b7a:9c10:6f5e就困难得多。这字符串读起来简直像某种测试代码。而接收端呢？诚然，我们“都”曾在学校“学过”十六进制，但普通人日常不使用十六进制，这地址听起来至多像导弹发射密码，最糟则像是某种虐待狂恶作剧。字里行间透着对发音的不熟悉与轻蔑。
(此时DNS从业者必然会跳出来指正我的错误。我真心热爱DNS；真的。但我实在没兴趣为家庭局域网的动态地址维护公共DNS服务。)
(接着就会轮到那些想省事的缩写狂登场，指责这台电脑的地址有误——仿佛当初选地址时我能主动参与似的。)
> 要让人记住2601:3c7:4f80:1a01:4d2:3b7a:9c10:6f5e这个地址可不容易。
若想让IPv6地址更易于人类理解，可采用DHCPv6(与SLAAC并用或替代)，最终获得类似2001:db8:3c7:4f80::123的地址。虽然它由5组(每组3-4个十六进制数字)而非4组(每组最多3位)组成，但我认为比您举的例子更易于记忆。您可将路由器设置为使用<前缀>::1和/或fe80::1(参见OpenWRT的ipv6 suffix/ip6ifaceid选项)。
DNS服务器(你可能偶尔需要手动输入配置)通常拥有“漂亮”的IPv6地址，例如Quad9显然使用2620:fe::fe[1]。
> 但我实在不愿为家庭局域网的动态地址维护公共DNS。
据我所知，如今dnsmasq可为通过DHCP获取主机名的本地设备创建AAAA记录。
若你在互联网上拥有公共服务器，且服务商分配了看似随机的完整128位地址(例如未带/64前缀)，使用(公共)DNS或许可行。
以上仅为个人观点。
[1] https://quad9.net。
> 随后总会冒出那些爱缩写的家伙，指责这台计算机的地址有误——仿佛当初选择地址时我曾参与决策似的
好吧，我上钩了。你究竟为何无法自主选择地址？
通常而言，若你对某个IPv6地址重视到需要手动输入，就该手动分配地址——既然如此，完全可以设置得比2601:3c7:4f80:1a01:4d2:3b7a:9c10:6f5e友好得多。地址后半部分可简化为::<数字>，其中<数字>的长度与该网络中可记忆地址数量呈对数关系。
我家网络全部采用ULA地址，前半部分直接使用我的电话号码，因此家庭路由器地址为fd21:2555:1212::1，NAS地址为fd21:2555:1212::a，以此类推。全局地址(GUA)格式类似2601:abc:def:1201::a，其实还算合理。
天啊，如果你不在乎将来与他人合并网络时可能出现的冲突，直接用 fd00:: 作为 ULA 前缀就行——路由器设为 fd00::1，NAS 设为 fd00::2，等等。比 IPv4 地址还短！
> 好吧，我上钩了。你究竟为什么无法选择地址？
我从未说过自己没有这种能力。或许有，或许没有。我自己也说不清究竟如何。这对我而言是个巨大的谜团。
我确实说过自己与那个冗长地址无关——也就是说，我并未参与将其设计成那样。我不知道这个长地址究竟是通过何种机制(如果存在的话)形成的。不知是分配所得，还是手动选择，抑或/dev/random的产物，又或是这些因素的组合。
我只知道这地址非我所选，且这种形式实在糟糕透顶。
> 通常而言，若你对某个IPv6地址重视到需要手动输入的程度，就该采用手动分配
或许吧。但这与几十年前IPv4世界形成的默认规范截然不同：局域网地址默认动态分配，由本地DHCP服务器分配，以点分十进制表示；广域网地址同样动态分配，由其他DHCP服务器分配，同样以点分十进制表示。两者地址之间毫无关联。
在那个时代：若我想立即(今天，而非明天或下周)为他人提供本地服务供其(在互联网上)使用，只需告知对方标识我广域网接口的简单点分十进制地址即可。
IPv4时代这点很简单。
> 若采用此方案，地址可比2601:3c7:4f80:1a01:4d2:3b7a:9c10:6f5e更易记忆。地址后半部分可简化为::<数字>，其中<数字>的长度随所需可记忆地址数量呈对数级增长。
或许我的枕叶出了问题，但看到这种地址时，实在难以快速辨别地址后半部分的起始位置。说到底，我为什么要寻找地址的“半截”？(这个“半截”的划分标准究竟从何而来？)
不过，好吧。管它为什么是半截呢。所以2001:3c7:4f80:1a01::3可以是局域网里的一个系统，2001:3c7:4f80:1a01::4就是另一个？而且这些都是完整、唯一、全球可路由的地址，只要设置好防火墙规则，世界其他地方的人就能连接？
但前半段是由我的ISP分配的，他们可以随意更改对吧？即使两台计算机在局域网中紧邻，我也无法从 2001:3c7:4f80:1a01::3 可靠地连接到 2001:3c7:4f80:1a01::4，因为明天前缀部分就可能变更——对吗？
我不喜欢局域网地址被当前使用的ISP随意支配的现状。(Spectrum断网后切换到热点备用，结果局域网地址全变了。IPv4在实际部署中从未给我这种麻烦。)
> 嘿，如果你不在乎将来与他人合并网络时可能出现的冲突，直接用 fd00:: 作为 ULA 前缀不就行了？路由器设为 fd00::1，NAS 设备设为 fd00::2，如此类推。比 IPv4 地址还短呢！
我甚至不知道 ULA 是什么意思。
不过听起来ULA类似RFC 1819定义的10.x.x.x私有地址：用户可自由配置，且永不接触互联网，因此完全可行。
理论上听起来很棒。但这不就又回到了使用私有不可路由地址的老路？这不正是我们试图规避的问题吗？
那么fd00::3如何与外部互联网通信？需要NAT吗？
编辑：而且在局域网内，fd00::3究竟比10.3[10.0.0.3]优越在哪里？
> 当时我只需向他们转达标识广域网接口的简单点分八位组地址。
要么你属于极少数在家中拥有/24等独立地址段、为每台设备分配全球IPv4地址的用户，要么你忽略了关键步骤——必须进入路由器随机选择端口进行转发并开放。否则你的网络中不可能像典型IPv6环境那样，让每台主机都“拥有”独立的广域网地址。
> 也就是说2001:3c7:4f80:1a01::3可以是局域网内某台设备，而2001:3c7:4f80:1a01::4又是另一台？这些地址完全独立且具备全球路由能力，只要配置好防火墙规则，全球任何地方都能连接？
是的
> 但前半段是由我的ISP分配的，他们可以随意更改对吧？
就像你的IPv4广域网地址那样，没错
(关于ULA)> 理论上听起来很棒。但现在我们又回到了使用私有、不可路由的地址？
就像IPv4那样。但在IPv6中，你可以在同一个子网内同时拥有ULA(如RFC1918地址)和GUA(实际可路由地址)。这完全没问题。局域网场景下使用ULA地址(额外优势：即使ISP更改前缀，该地址仍保持不变)，而全球唯一地址则用于极少数需要跨洲通信的情况。反正你得修改防火墙规则，不如顺便选个合适的GUA地址(如$global_prefix::1等)。随心所欲即可，毕竟这是你的前缀(除非ISP更改)。
> 那么fd00::3如何与外部互联网通信？需要NAT吗？
无需NAT，它本身就有用于全球通信的备用地址。通常会分配超长的随机地址，这就是它们的用途(甚至会随每次外部服务连接动态变更)。冗长且无法解析的128位地址本质上仅用于隐私保护(即刻意使地址失去实际意义)。任何需要固定IP的场景，直接选择更合适的地址即可。$prefix::1之类的地址。在macOS上只需一条ifconfig命令即可配置，Linux同理。(Windows我没试过但肯定也行。)重启后保持地址不变也轻而易举。
但ISP更改前缀确实是个大问题，因此依赖持久化的全球地址实在太冒险。在需要本地配置IP地址的场景中，使用ULA才是唯一理智的选择。而对于全局地址，一旦遇到不同前缀，简直是巨大的麻烦。
> 编辑：那么在局域网中，fd00::3究竟比10.3 [10.0.0.3]优越在哪里？
> 问题在于它确实与IPv4行为差异显著
若拥有将网络整体迁移至v6的/稳固/过渡方案，这本可接受。但他们在此环节彻底失败，几乎刻意拒绝沿用任何熟悉机制来简化双栈管理。
这种源于大学研究的协议之所以能渗透到商业领域，主要源于人们对全球路由表规模失控、无法存储在内存中的错误担忧。结果完全在预料之中。
我虽然没花太多时间研究电力系统，但按下开关时灯应该亮起来。
(需要专门投入时间配置，某种程度上要么是协议本身的缺陷，要么至少是阻碍普及的因素。)
根据我的经验，IPv6在消费级场景中始终“无缝运行”。唯一遇到的困难是在现有管理型网络中部署时。遗憾的是，多数机构因对IPv4过于依赖而拒绝触碰它。
虽然这些文章有助于理解IPv6的实用性，但真正需要的是一篇详解如何配置IPv6家庭网络的分步教程。该教程应解答以下问题：
– 如何确保地址空间无冲突？即如何选择安全地址，是否有系统机制？
– 如何实现外部网络资源到内部网络资源的路由？具体来说，能否提供连接SMB共享的语法？如何设置无需WireGuard等工具即可运行的Web服务？
– 如何进行网络分段、配置VLAN、设置防火墙？
– 使用SLAAC(不确定DHCPv6是否支持)的设备会通过“重复地址检测”机制自动处理此问题。无需担忧。若手动分配地址时发生冲突，其中一台设备会将自身地址标记为重复并拒绝使用。此机制相当实用。
– 最简便的方式是使用设备的公共地址(“全局单播地址”)，并在防火墙上开放相应流量。这才是IP设计的初衷，无需NAPT。若需互联网访问，可本地使用ULA地址，再通过NPTv6转换。但建议初始阶段避免此方案。
关于服务配置，其实并无IPv6特有的要求。无论v4还是v6，都不应将SMB服务暴露在互联网上。同样地，任何基于IP的服务都可以通过Wireguard或其他隧道方案进行保护，这与v6无关——只需在配置中使用v6地址即可。
– 基本与v4相同；IP协议(无论v4或v6)在第三层的语义基本一致。唯一需要注意的是，需允许特定类型的ICMPv6流量，前提是防火墙厂商未默认封堵该类流量。至于VLAN，属于第二层网络，因此第三层协议在此不发挥作用。
v6的网络分段更具灵活性，充足的地址空间可构建优美的分层拓扑结构。
– 若涉及私有/本地前缀，可使用此类工具生成：https://unique-local-ipv6.com/。否则DHCPv6和SLAAC机制基本能确保不发生冲突。
– 所有设备均应使用全局/公共地址(通过前缀分配等机制)或启用NAT。
– 与IPv4相同。前缀分配机制允许ISP为你分配多个网络，随后大多数路由器会将这些网络拆分为/64子网，分别对应你的VLAN。
– SLAAC – IPv6 地址空间极其庞大，除非人为干预，否则地址冲突几乎不可能发生。
– 打开防火墙端口，将DNS指向该地址，即可正常工作——拥有公共地址的乐趣就在于此。
– 基本与IPv4相同。唯一实质差异在于：SLAAC默认分配/64子网，因此您的网络规模至少应达到此级别。
> 除非人为干预，否则极不可能发生。
但说真的！这可是个合理疑问：选地址时你们就随便乱捣乱捣密钥吗？
> 拥有公共地址的实际乐趣。
如果你的ISP分配了静态IPv6地址。可惜在德国，面向个人用户的ISP都不提供(据我所知)。
> 选地址时你只是随机打乱密钥吗？
不是。ISP或隧道服务商会分配网络前缀，你只需配置SLAAC使用该前缀并在其范围内分配地址即可。
例如前缀可能为2001:470:e904::/48。只要地址以该前缀开头，计算机可自由使用任意地址。由于无需手动为每台设备分配地址，只需配置路由器通过SLAAC分发地址。计算机将通过SLAAC从路由器获取前缀，用随机数填充地址末64位，再向本地网络查询该完整地址是否已被占用。若未被占用则分配成功，获得有效地址。若该地址已被占用，则尝试使用不同随机数重新分配。需要固定地址的服务器可直接使用网卡MAC地址(或类似标识符)替代随机数，协议机制保持不变。
请注意，该机制实际上为您预留了可自由使用的位资源。完整地址长度为128位。前48位用于前缀，后64位分配给设备，中间保留16位。例如可将路由器配置为SLAAC前缀2001:470:e904:42::/64，其余子网则用于其他用途。比如将2001:470:e904:beef::/64设为专用子网，专供冷冻肉库及监控设备使用。具体方案由你自行设计——或许你在企业网络中为电话机设置独立VLAN，普通PC使用另一VLAN，访客WiFi则用第三个VLAN。通过将VLAN标识嵌入SLAAC通告的前缀中，可为每个VLAN分配不同前缀。
若需更精细的地址分配控制，或希望进一步划分网络结构，亦可采用DHCPv6协议。当然，若未来ISP开始分配更短的前缀，该方案同样适用。
> 若您的ISP提供静态IPv6地址。遗憾的是在德国，目前尚无面向个人用户的ISP提供此服务(据我所知)。
确实如此。但他们很可能也不提供静态IPv4地址——除非额外付费。无论如何，若您需要为计算机分配静态标识符，解决方案始终相同：使用DNS。
当然，若你确实运营着包含多个VLAN的企业网络，则应向区域互联网注册管理机构(RIR)申请专属前缀，而非向ISP获取。此时你需向ISP购买IP转接服务而非普通互联网接入服务。此时可通过BGP发布前缀。这与IPv4的操作完全一致：相同软件、相同配置，只是地址更长。额外配置的核心优势在于：即使更换ISP，地址仍可保持静态。您还可通过多ISP多连接复用相同地址，实现更优的冗余性。
这篇概述很到位。我认为IPv6的难点在于人们将IPv4时代发明的一切权宜之计视为固有特性：私有地址NAT能提供安全性(实则不然)和可移植性(确实如此)，而IPv6通常按物理位置划分子网导致故障转移困难，反观IPv4可通过BGP公告实现公共IP的故障转移等。我并非主张哪种方式更优，只是强调IPv6差异显著，而人们仍固守IPv4的世界观。
> 但说真的！这可是个合理问题——选地址时你们就随便乱配密钥吗？
我确实给出过答案：SLAAC。
> 若您的ISP提供静态IPv6地址。遗憾的是在德国，目前尚无面向个人用户的ISP提供此服务(据我最新了解)。
奇怪，我在英国用过的所有ISP都分配过静态/56网段。不过解决方法与动态IPv4地址相同(使用DDNS)，您依然能享受无需处理NAT的优势。
更令人费解的是，我所在的公司竟禁用了IPv6，导致开发机连调试iOS应用这类基础任务都无法完成(该设备底层本就使用IPv6)。
官方理由：安全政策认定IPv6安全性不足。
我本想将网络全面切换至IPv6并采用NAT64/DNS64方案，但全球最主流的Android系统却故意禁用了DHCPv6。为兼容这些缺陷设备，我不得不继续支持IPv4/DHCPv4方案。
> 我希望能将网络全面切换至IPv6并使用NAT64/DNS64，但全球最流行的操作系统Android却故意禁用了DHCPv6。
它并非“禁用”DHCPv6，而是不支持DHCPv6。Android(确切说是Lorenzo Colitti)以臭名昭著的“WONTFIX”态度拒绝添加DHCPv6客户端支持：
* https://issuetracker.google.com/issues/36949085
当然，在十余年否认Android需要任何形式的IPv6 DHCP支持后，该系统或许终于迎来某种解决方案：
* https://android-developers.googleblog.com/2025/09/simplifyin…
* 来源：https://blog.ipspace.net/2025/09/android-dhcpv6-prefix-deleg…
希望他们承认(？)仅支持SLAAC的错误做法后，除了DHCPv6-PD外，还能添加“常规”DHCPv6。
天啊安卓的DHCPv6状况简直疯了。关注Colitti先生的闹剧已久，却直到现在才得知前缀委派功能。现在居然能委派整个子网却无法获取普通地址？为什么啊为什么不能像地球上其他操作系统那样拥有个该死的正常DHCPv6客户端？
安卓支持SLAAC，对xlat464和DHCP选项108等过渡技术也有良好支持。
我在网络和办公室都用这些方案实现了安卓设备的纯IPv6环境。
既然有这些方案，缺乏DHCPv6功能怎么会阻碍你在安卓上使用IPv6？
若要同时运行SLAAC和DHCPv6而不让设备获得多重地址，Android又因不支持DHCPv6，我只能另建基于SLAAC的安卓专用网络。随后还得处理防火墙规则、多播反射等问题。
我最初也认为这是个问题。后来意识到地址资源并不短缺，便不再在意部分设备获取多重地址。关键设备通过DHCPv6分配地址，防火墙据此生效；其余设备仅获得基础连接能力。
对我而言运行良好。
难道不会出现客户端使用错误源地址导致防火墙规则匹配失败的情况吗？
不会。坦白说，我的防火墙规则仅用于为特定设备提供基础功能之外的额外权限。反正我只对重要客户端这样操作，因此总能要求他们使用正确地址。
我是另一个人，但同样没有。我从不基于单个源地址编写防火墙规则——它们太容易伪造了。况且IPv6的隐私扩展机制下，你永远无法确定特定机器的源地址。
有意思。那本地网络中的目标地址如何处理？像其他用户和我一样用DHCPv6吗？
我从未用过DHCPv6。我会通过DNS(或更优的mDNS)将主机名分配给目的机的固定IPv6地址或ULA(两者均为静态)。不过我从不手动分配IPv6地址，完全交由SLAAC按设计机制处理。
分配多个地址有什么问题吗？
无法控制使用哪个源地址。我为大量客户端分配DHCP保留地址，以便使用静态地址进行监控和防火墙规则配置。当同一网络存在多个地址时，客户端可能使用其SLAAC地址，这将导致与防火墙规则不匹配。
这逻辑仍难以成立。为何不在单个子网运行SLAAC并统一配置防火墙规则？安卓设备本就不承载核心服务器，规则设计本应简单。
SLAAC仅能在大于/64的子网运行，而他们可能无法访问更大范围的子网。
严格来说它确实能在精确/64的子网运行。如今还有人分配更小的地址段吗？
我的意思是，他们可能从ISP那里只获得1/64的地址空间；或者获得/62等较小的地址块，但实际仍需更多子网。在这种情况下，你可能没有额外的/64地址块专门用于某些设备的SLAAC。
没错。我只是纠正了你关于SLAAC需要超过64位才能工作的说法。但我的疑问依然存在：是否有ISP分配的地址块小于/64？
Linux 系统存在控制源地址选择的 API，但操作可能较为繁琐 https://www.davidc.net/networking/ipv6-source-address-select…
啊，这样说有道理。
Android支持DHCPv6，但不支持状态化DHCPv6。你可以为每台设备分配独立的/64网段，若需精确追踪设备使用情况，应在基础网络之上部署认证层。
为何不能使用无状态自动配置？
因为我需要控制分配给设备的后缀，用于防火墙规则和监控目的。
除非你的网络有多个路由器/网关，否则这似乎是错误的层级。
使用MAC地址作为防火墙和监控的键值。这样就不会为每个设备创建多个规则。
“你拿错了”
如何让IPv6在家庭网络中实现每个设备都能简单稳定地映射到独立子网？我喜欢IPv4和ISP NAT提供的偶然半随机性，但除了将整个家庭网络置于VPN之外(成本高且无法匹配ISP带宽)，似乎找不到类似方案。
每个设备在WAN侧都能通过v6直接寻址，但同时获得一个随机化隐私IP且频繁轮换，因此单个设备与v4+NAT环境下的“隐蔽性”完全一致。
你的v6子网前缀本质上与NAT提供的任何WAN侧v4地址并无二致。广域网侧IP的“偶然半随机化”并不可靠。许多ISP实际分配的是近似静态IP——即便理论上随机分配，但IP池资源严重受限，通常因IP租约在设备重启后延续而保持不变。这还是在CGNAT技术出现之前的情况。
若您担忧IP地址可追溯性，依赖任何v4地址特征都是错误策略。请使用随机化出口节点的VPN。
据我所知，没有任何ISP会对v6地址进行随机化处理。该地址将永久绑定至您的账户。
现实中确实存在实用价值——人们无法通过v4地址精确定位具体家庭。失去这种价值实属遗憾。
确实，没有CGNAT就无法实现CGNAT。根据需求，可通过NAT66使整个网络呈现为单一IP地址。
我愿意付费让ISP每周轮换我的IPv6子网。但这根本不可行。Comcast的IP偶尔会变，这倒有些价值。
我不明白为何他人能确定性地访问我网络中的特定设备。除非我提供服务，否则这对我毫无价值。
那么价值不就显而易见了？这种能力让你能够运行服务。或许你当下并不需要——完全可以不用这项能力。但若你改变主意，它始终在那里供你使用。
此外…人们能够确定性地访问你网络中特定设备的能力，恰恰是你用于确定性访问他人网络中特定设备的能力，只是视角相反。如果互联网不是一个人们可以决定在自己的网络上运行服务、并连接到他人网络上运行的服务的地方，那它还有什么意义呢？
IPv6支持用户自主控制的前缀轮换机制。通过配置路由器定期更改设备唯一标识符(DUID)，即可设定轮换频率。当然，您的ISP可能无视该机制始终分配相同前缀，但这绝不能归咎于IPv6本身。
您家中的每位成员都已映射到单一IPv4地址，且多数ISP很少更改该地址。我的地址三年多未变，IPv6 /56前缀分配同样保持稳定。
机制略有不同，但您可使用ULA实现静态子网与设备地址。
我启用IPv6后最大的变化之一是：每个接口拥有多个地址已成为常态。由于ULA地址不可全球路由，我将其视为局域网地址。另一个方案是mDNS，但其支持度尚未广泛普及。
全球地址可能变更，就像你家动态IPv4地址偶尔会变那样。
ULA地址。它就像v4中RFC1918地址的升级版。
你所说的“简单而稳定地映射到唯一子网”具体指什么？
世界IPv6日6月6日，直接关闭IPv4。让世界跟上步伐。
我在6月6日也说过同样的话。
呃，我喜欢这个！
我有些服务仅支持IPv6，但很少能说服别人需要IPv6连接……
我的ISP对IPv6支持良好。我曾使用过一段时间，最近为简化维护在家庭网络中将其禁用，将vyos配置缩减了一半。当需要访问IPv4不可用的资源时我会重新启用，但我不认为这种情况会在我有生之年发生。
在我25年的网络工程生涯中，作为用户真正需要IPv6的情况仅出现过一次，就在今年早些时候。Supabase的免费套餐要求通过IPv6才能直接连接Postgres数据库。可惜这项部署对所有人而言都成了漫长而昂贵的过程。
我三个月前亲身尝试过这个实验。在路由器上彻底移除了ISP分配的IPv4动态地址。尝试访问的公共网站中约50%无法解析。受影响的网站数量之多，让我仅一天就放弃并恢复双栈模式。谷歌、ChatGPT等少数热门网站能正常接收纯IPv6流量，但eBay甚至HN都无法解析。IPv6显然尚未成熟到能让所有人一夜之间完成迁移。
HN无法解析倒是颇具讽刺意味。
作为普通用户：我为何需要IPv6？
据我所知，约70%的网站尚未支持IPv6。
我不认为数据准确。当然这取决于如何定义“多数网站”。
多数统计显示前100网站中有60-70%已支持。不过这可能与你实际使用场景不符。
你为何需要它？或许当下并不急迫，毕竟纯IPv6站点仍属小众。我认为最直接的优势在于规避CGNAT。尤其对游戏玩家而言，这种技术会引入延迟。Xbox Live等服务正因如此明确支持IPv6。
取决于你的网络服务商。若你所在地区IPv4地址稀缺，CGNAT正是导致你频繁遭遇Cloudflare/Akamai/Google验证码的根源，而IPv6能彻底解决这个问题。
这就像北欧人因粮食短缺被迫发明各种精妙食品保存技术，并围绕作物限制与战争形成复杂权力斗争体系的道理。
而赤道附近地区，人们只需简单生存就能共存共荣。
简而言之，美国人就像原住民部落。我们拥有充足的IPv4地址，根本不在乎SLAAC或其他复杂的月亮太阳季节潮汐神灵、盐渍鳕鱼和盐矿开采。我们根本不需要在意冗长的地址——这里地址多得用不完。
你需要它，因为IPv4地址不足。
若你持有移动数据设备，很可能已在使用它。
全球所有手机和物联网设备真需要公开可寻址吗？这当真有益？
使用互联网就需要IP地址。
通过在同一局域网部署多台主机并共享传输层资源，可以复用IP地址。NAT技术正是为解决地址短缺而诞生。
CGNAT确保你在网络中拥有合理否认权。NAT同时保证你无法被互联网直接定位。
这本是设计特性。
直到它不再是。
若我想发送消息(邮件)，必须经由第三方中转。
若我想查看家庭监控画面，必须经由第三方中转。
我认为这并未真正探讨取消NAT是否会导致隐私或安全损失。我的主力设备(Mac/iPhone/iPad)始终保持更新且能应对，但问题在于：我是否真的希望恒温器、门铃、门锁、车库门开启器或灯开关直接暴露在互联网上？NAT是否正发挥着重要作用？本文似乎未触及这个核心。
> 但我的恒温器、门铃、门锁、车库门开启器或电灯开关真的需要直接暴露在互联网上吗？NAT是否具有实际价值？
无论使用v4还是v6协议，都应部署防火墙。
你应该这样做，但没有NAT时，没有防火墙的风险会高得多。携带私有网络IP的数据包在互联网上如同外星人，除非它们来自同一网络且ISP基础设施未将其丢弃，否则无法到达你的设备。IPv6地址可在整个互联网中路由，因此这些数据包很可能到达你的路由器，这意味着在没有防火墙的情况下，任何互联网用户都能与你的局域网通信。
现实情况是，消费级路由器固件在各个方面都糟糕透顶，尤其在安全性方面，而IPv6的普及也无法改变这一现状。我最担心的情况是：ISP会在其端设置入站防火墙，届时我们的处境将比现在更糟。
那些顽劣的入站数据包即使在无状态NAT全防火墙环境下仍能直达私有设备。具体实现取决于NAT的转换机制，但完全可能让某个随机高端口($randomHighPort)将所有入站流量直接发送到特定设备。换言之，NAT无法保证基于第4层四元组进行精准匹配。
若谷歌宣布Chrome将在n个月内停止支持IPv4，或许能推动事情进展。;)
确实如此，但别忘了世上远不止HTTP(S)这类服务。
例如我上次使用纯IPv6主机时，从GitHub克隆项目就遇到了问题——由于github.com未配置IPv6记录，“git clone git@github.com…”命令直接失败。
快速检索发现这个已开启3年以上的讨论帖 – https://github.com/orgs/community/discussions/10539
快速解决方法是使用https://nat64.net/提供的DNS服务器之一。另有人专门为GitHub运行反向代理，例如https://danwin1210.de/github-ipv6-proxy.php。
(理想情况下应由ISP提供NAT64服务，特别是当VPS供应商仅提供v6地址时，但实际中极少有供应商支持…)
你运气不错，GitHub正在迁移至Azure平台！
如今非ChatGPT莫属。
相比被困在运营商NAT64设备后，采用公共IPv4地址的双栈方案显然是更优的v4互联网接入方式。
完全理解运营商为何倾向IPv6核心网络并淘汰v4。但对终端用户而言，双栈方案显然更简便。
运营商可在核心网采用纯v6架构，同时继续为用户提供公共v4地址。若经济允许，可采用SIIT方案为每位用户分配公共IP；若资源紧张，则可采用MAP-T方案。
更正：应是CLAT/464XLAT方案，而非SIIT方案。
有意思。我终于找到IPv6的实际应用场景，已撰文详述：https://martinalderson.com/posts/i-finally-found-a-use-for-i…
但说实话，Docker的问题实在太严重，绕行方案极其痛苦。除了Docker之外一切运行良好——它存在诸多问题，尤其无法妥善处理IPv6入站而仅支持IPv4出站(至少我观察到的情况如此！)
我之前在爱尔兰的光纤服务商是Virgin，据我所知其网络完全支持IPv6。我网络中的每台设备都获得了公共地址，在家自建服务就像在DNS主机上设置A记录那样简单。无需折腾端口转发、代理、NAT之类的破事。记忆有些模糊，但可能需要在Virgin提供的路由器上配置防火墙。
我必须让家庭网络至少对外支持IPv6，因为我的ISP最近部署了CG-NAT，导致原本可正常使用的SSH服务器现在无法从局域网外部访问。
你可以使用tailscale这类NAT穿透VPN来解决这个问题。
我的ISP几年前就支持IPv6了，我自己也用6。
无NAT网络真的很酷，我可以直接从局域网内的任何设备提供内容。
我们真的该告别IPv4了。
好奇能否在家庭IPv6地址后运行自有邮件服务器。
多数家庭IPv4网络都封锁了25号端口的入站连接。或许在IPv6领域会宽松些。
为实现互联网P2P通信而依赖的各种变通方案实在令人遗憾…我们需要Turn、Stun、WebRTC等技术，才能让两台计算机在无需专属端口转发或公共IPv4地址的情况下通信。
IPv6是优雅的协议(虽非完美，但设计精妙)，具备诸多优势。但IPv4的惯性实在太过强大。
真是个烂摊子……没有好的解决方案。我尝试关闭IPv4后，GitHub(真丢人)就无法使用了。但我们该怎么办？让政府强制所有人转换吗？(哦等等，美国政府网站有一半只支持IPv4)
这都是我们自找的……
AWS不为IPv6地址提供PTR记录，导致Gmail将我的邮件服务器IPv6地址列入黑名单。由于缺少PTR记录，我不得不禁用IPv6。
在AWS无法搭建垃圾邮件服务器是其设计特性。
这并非垃圾邮件服务器。我自建邮件系统仅用于个人及非营销业务。别把所有自建邮件系统的人都当成垃圾邮件发送者。
IPv6实在令人失望。这分明是典型的“委员会设计的马”。
我怀疑最终实施的只会是规范的核心子集。
尘埃落定后，且看哪些部分能幸存下来。
IPv6规范看似冗长，实则整合了IPv4中独立的协议(如DHCP/SLAAC、NDP，部分文档还包含ICMPv6，对应DHCP/ARP/ICMP/NetBIOS等)，以及IPv4中分散于不同RFC的多播/单播/网络类/子网等寻址方案。
至于实现层面：几乎所有性能强于ESP32的设备都已完整实现并运行该协议。
只要应用程序的SDK能简化操作，问题就不大。目前我尚未看到太多相关案例。
此言何意？正因如此，iOS和macOS应用早已完美支持v6。Linux通过统一地址族为netfilter和网络套接字抽象了底层细节。各类编程语言也完善了标准库数据结构与函数等。
你的计算机，以及地球上所有计算机，早已支持完整的IPv6规范。不存在子集这种说法。
我此刻正用运行Android系统的电脑打字，这意味着它不支持DHCPv6。我认为这属于支持IPv6功能子集的情况。
这或许令人困扰，但技术上而言，DHCPv6本就不属于IPv6规范范畴——正如原始DHCP从未包含在原始TCP/IP规范中。
我们还需观察所有“中间环节”的功能实现。其中涉及大量内容，需要无数层路由器、交换机、缓存、防火墙等设备来实现。
以蓝牙或TIFF为例。
我曾为求知欲打印过蓝牙规范，足有2000多页(双面打印)。
我还尝试过编写完全兼容的TIFF阅读器，结果并不理想。
这些设备同样支持IPv6。它们本质是相同的计算机，数十年来始终兼容IPv6。而IPv6规范远比蓝牙或TIFF规范简洁得多。
物理层和链路层支持并不意味着应用层也会支持。
蓝牙芯片也是同样道理。
兄弟，我可是亲眼见过这种情况…
苹果要求应用商店内所有iOS应用必须能在纯IPv6网络环境下运行(多家大型移动运营商采用此模式)，而应用层的运行完全没有问题。
咦。我信这个，但此前并不知情(我为苹果设备开发应用)。我做过底层网络开发，那绝对会遇到问题，不过那是十多年前的事了。如今我只依赖协议栈的上层。
我确实该尝试作者那样的实践。我并非反对IPv6，但仍存疑虑。虽然别无选择终将被迫采用，但这绝非发自内心的赞同。
我的运营商(日本NTT docomo)仅向终端设备提供IPv6服务。访问IPv4服务器需通过DNS64/NAT64机制：其DNS服务器会将所有包含IPv4地址的响应重写为[64:ff9b::(原始IPv4地址)]，再由CGNAT网关进行处理。因此通过DNS查询服务器并建立连接时一切正常，但硬编码的IPv4地址则无法使用。
我推测苹果的这一要求是为了确保所有应用能在这类运营商网络中运行。
我遇到问题的唯一情况是：使用网络共享时忘记无法ping通IPv4地址，或是尝试共享网络给任天堂Switch(该设备不支持IPv6)。
若底层网络代码(此处应指BSD套接字)设计正确，本无需区分v4或v6协议。BSD套接字API的设计理念是将地址封装在不透明数据结构中，开发者只需传递该结构即可。
早年我确实做过BSD套接字相关工作，但如今基本不碰底层实现。
你说得对，这正是我的计划。
不过我听说不少人在IPv6规范制定过程中插手干预。我见过这种流程，最终结果往往……不太理想……
我试过，但我的HN瘾终结了这一切。
HN现在支持IPv6了。
要是Reddit也能完成IPv6部署，我几乎所有浏览都会用上IPv6。
总有人说IPv6能更轻松地托管服务，但你依然得兼容IPv4。
试着在酒店WiFi上连接纯IPv6服务——通常连不上。
很遗憾，IPv6对家庭用户根本解决不了问题。这话出自亲自在家部署过IPv6的人之口。
> 遗憾的是，IPv6对家庭用户根本解决不了问题。
这主要归咎于CG-NAT及严格的NAT机制。新型ISP常强制用户使用CG-NAT，而我的游戏主机多年来始终受困于各类NAT问题。ISP路由器往往使用户无法解决这些问题，甚至让问题变得不可见。
我并不认为IPv6是万能解药，但它确实解决了IPv4遗留的问题，并消除了IPv4长期存在的诸多困扰。
它确实简化了操作。IPv6针孔技术比端口转发更简单。我的IPv4地址非静态，但IPv6前缀是静态的，因此无需动态DNS。我未配置任何IPv4端口转发，仅在VPS上运行snid来支持传统互联网客户端，就此打住。
https://github.com/AGWA/snid
所以你的方案是：先配置云服务器和带通配符记录的域名，再通过IPv6转发IPv4流量？
这某种程度上印证了我的观点：IPv6对自建服务帮助有限。你仍需某种可用的IPv4配置。你用IPv6替代了反向代理或类似tailscale的方案，这或许更便捷些。
每隔几年我都会查看维珍媒体距离提供IPv6还有多远。刚又查了下…还是不行！
https://www.havevirginmediaenabledipv6yet.co.uk/
我明确禁用IPv6的原因在于“这玩意儿根本不靠谱”(目前如此，未来可能改变)
– 随机性延迟
– 糟糕的路由
– 更大的数据包开销
– 被众多互联网运营者厌恶
– 被提供DDoS防护的公司厌恶
– 折磨我廉价路由器的TCAM缓存
– 在机架式路由器中支持IPv6成本极高
然而我认为存在解决方案：将ISP切换为纯IPv6服务，除非存在IPv6路由否则直接转发至IPv4。这能解决诸多问题：当所有ISP都支持IPv6后，即可直接弃用IPv4转为纯IPv6，无需分割TCAM资源。其原理在于IPv6可内嵌IPv4地址。
鉴于该观点仍引发讨论，我补充说明：
– 此结论源于与业内技术人员交流及持有ASN的实践经验
– T1级ISP永远不会投入资源简化IPv6迁移流程
犀利观点：IPv4在技术层面或许更差，但在“政治层面”(经典意义上的)更优。
IPv6本质上为每个设备赋予“通用互联网ID”，这虽能简化诸多流程，却会催生大量监控/权力失衡问题——而IPv4的冗余设计恰恰在无意中构筑了防护屏障。
我年岁尚长，还记得当年ISP曾试图按每户设备数量收费的时代。
这种情况已消失数十年，如今所有操作系统默认随机生成地址后64位，并定期轮换新地址。除非用户主动配置，否则IPv6地址不会与设备绑定。
由于网络段(前64位)如同IPv4地址般固定，而主机段随机且持续变化，IPv6地址的唯一性识别能力完全等同于昔日的IPv4地址。
据我所知，至少Fedora默认禁用了隐私扩展功能。
> 我年纪够大，还记得当年ISP曾试图按每户设备数量收费。
这种情况不太可能重演，即便出现也能像NAT4那样部署NAT66。
你我当然能做到。
但网络效应才是关键。
若ISP真想对IPv6设备收费，NAT66路由器就会变成现成商品。直接卖个黑匣子就能解决问题。
但更根本的是，时代变迁已使按设备收费模式不再可行。
什么网络效应？正如前文评论所言，隐私地址已是所有消费级操作系统的标配功能。