更正一下，“以后的浏览器都要原生支持的”不准确。谷歌的这个认证是同属于 FIDO2 协议的，但更类似于 Windows Hello 这种平台相关的虚拟密钥（和原来就有的蓝牙物理密钥反而关系不大）。这样看来别的浏览器应该没法支持。

这个是 FIDO2 WebAuthn 认证，是新的 Web 标准里东西。相应的物理密钥设备本身就包含 usb, nfc 和蓝牙三种形式，同时还支持非物理密钥比如 Windows Hello，以后的浏览器都要原生支持的。

根本不是什么 js 直接读蓝牙。

@sasalemma 这个和 iptables 没什么关系，ipv6 默认纯路由模式不经过 NAT，是不涉及 iptables 的（当然，如果有防火墙的话还是要用到 iptables ）。涉及到的是 DHCPv6 Server 的工作逻辑，对于 PD 请求是“创建新的 VLAN”，还是和 NA 请求一视同仁直接从 LAN 里挖。这两种在路由表上都是很容易实现的。就看 DHCPv6 软件的开发者的选择了。

@cwbsw 这个是我阅读 odhcpd 的源码和查询相关资料得出的结论。OpenWRT 在处理 PD 请求的时候似乎是从已经配置到 LAN 的前缀上挖出一块向下分发的，而不是从闲置地址里分发。

比如说一级路由使用 Mikrotik RouterOS 的话，这种情况就是可以下发前缀的

@sasalemma
改正上个回帖里的一处错误：“如果一级路由器是 OpenWRT，是可以实现这种下发操作的”
现在的 OpenWRT 确实不支持这种下发。但是其它路由器不一定不支持。

我之前也见过一种光猫，获取 /60 的前缀后可以给二级路由 PD /64 的前缀，但可能路由表的建立有 BUG，导致二级路由后的设备获取了地址也上不了网......

@sasalemma 你这里对一些概念的理解有些问题。

是这样的，首先各个 /64 的意义是不一样的，通过 SLAAC 获得的只是一个地址，里面的“前缀长度”字段（值为“/64”）只是相当于 ipv4 的子网掩码的含义，只是提示了同一网段（ WAN 侧）的地址范围，同前缀的其它地址是不属于你的。所以说当路由器仅获取 WAN 地址时（无论是通过 SLAAC 还是 DHCPv6 IA_NA，前者只支持 /64，后者支持任意的前缀长度，注意这两种方式获取到的都是“地址”而不是“前缀”），LAN 端设备是无法直接获得 IPv6 全球单播地址（就是 2 开头的公网地址）的。

然后还有另外一种操作是 DHCPv6 IA_PD，这种操作可以向上级网络请求一个 IPv6 的前缀，一般家宽运营商给出的前缀长度都是 /56 或者 /60 的，也有极少情况是 /64 的。通过这种方式获取到的是“前缀”而不是“地址”，也就是说同前缀的 2^(128-PREFIX_LEN)个地址都是属于你的。这就是 DHCPv6 IA_PD 和其它地址获取方式（ SLAAC 和 DHCPv6 IA_NA ）的本质不同之处。

家宽单层路由器（包括光猫自带路由，以及光猫桥接路由拨号两种情况）的一般工作方式：首先路由器（路由模式光猫）建立 PPPoE 链路，然后通过 SLAAC 获取 WAN 侧地址（一般情况下前缀长度为 /64 ），然后通过 DHCPv6 IA_PD 向 ISP 请求一个地址段，比如楼主拿到的是一个 /56 的地址段，这些地址都是临时属于你的（ ISP 端在获取地址的那一刻就已经建立好了正确的路由）。然后重要的来了：路由器（路由模式光猫）从这 /56 的地址端中只取了一个 /64 的地址段作为前缀配置到了 LAN 接口上（包括本地路由器的路由表，自身 LAN 口地址，和负责分配地址的 RA 服务，有时候可能还有本地的 DHCPv6 服务），这样 LAN 侧的设备就可以通过相应的协议获取临时属于自己的公网地址了。至于为什么只取一个 /64 而不是整个 /56，是为了兼容 SLAAC 。

而且可以注意到，路由器 LAN 侧和 WAN 侧不是同一个网段，这也是 IP 协议的最基本要求（想想 v4 时代是怎么配置地址的）

这种情况下，还有 255 个 /64 全球可路由的地址段（或者也可以理解成 15 个 /64 地址段和 15 个 /60 地址段）是处于闲置状态的，理论上来说，一级路由器也可以响应 LAN 侧接入的下级路由器的 DHCPv6 IA_PD 请求，给下级路由器分配前缀（下级路由 WAN 侧通过 SLAAC 拿一级路由 LAN 侧的**一个**地址，LAN 侧拿一级路由从 ISP 得到且闲置的**一段**前缀，在这个过程中会自动配置好本地的路由表等参数），然后下级路由 LAN 侧连接的设备就也可以获得公网地址了。此时如果把 /56 改成 /60，也只是少一些可用地址段而已（只有 15 个 /64 地址段闲置），影响不大。如果一级路由器是 OpenWRT，是可以实现这种下发操作的。

所以说实际存在的问题并不是所谓的“/60 下发只有 /64 不能再下发”（实际上不存在这种说法），而是光猫自带路由根本不会正确响应下级路由器的 IA_PD 请求。
（我也见到过一些光猫，能够响应 IA_PD 请求，但是可能固件里有 bug 不能正确配置本地的路由表，导致二级路由后的设备能获取 ipv6 地址但不能上网）

@systemcall Surface 系列装 Linux 都会有硬件不兼容的问题（比如自带键盘不能用等等），需要装魔改版内核，非常不方便。而且这个 SB2 还是有独显热插拔的，估计兼容性问题会更大，装 Ubuntu 估计体验不好。

IPv6 DDNS 一般都不用软件，直接用脚本，要绑域名的服务器（不是路由器）上定时运行即可。

dynv6 这个 ddns 可以只解析 ipv6

大多数 Linux 发行版一般都可以直接迁移（除了自己编译、裁剪内核的情况）
Windows 10 这样做则会蓝屏，需要强制关机数次唤起启动修复提示，然后进一次安全模式，以后才能正常开机。

@DaRenCC 因为 VLAN 可以起到单线复用的作用，把 IPTV，上网等原本需要单独布线的变成走一条网线

网件高端型号一般都是博通系的，都不太好刷 openwrt，一般买网件的要么用官方固件图个稳定，要么刷梅林（可玩性强但稳定性较差）

要玩 openwrt 建议软路由或者捡 MT7621 的垃圾

其实这个不是 Compilation finished 特有的。IDEA 的所有弹窗，只要 IDEA 在前台，就是程序内弹窗，如果其它程序在前台，就是系统通知。所以你只在编译的时候看见这种弹窗，是因为你划水...

关掉上面那个 Enable system notifications

@namaketa pac 不是唯一方案，还可以选择用 SwitchyOmega

访问手机卡，有可能是运营商禁止传入连接
访问家庭宽带，OpenWRT 上防火墙设置里要新建转发规则开放相应端口

总的来说就是，第三方库跨版本，可能会有 API 或 ABI 兼容问题

如果不考虑第三方库版本的问题，那么 C 语言一般不会有 ABI 不兼容（虽然 C 语言没有官方规定的 ABI，但是作为操作系统基础语言，事实上具有较强的兼容性），但 C++可能会有 ABI 不兼容（确实存在不兼容的情况）

C++的话有一个要注意，gcc 的 C++库有两种 ABI，一种是 gcc4.x 版本普遍使用的旧 ABI，还有一种是 gcc5.0 版本引入的 C++11 ABI （主要是为了符合 C++11 规范，STL 中 string 和 list 的实现有修改；但是新版 GCC 也可能会使用旧版 ABI，要看具体发行版的情况），如果 C++ ABI 不兼容的库被链接在一起，编译出来的程序运行以后会 crash 。

另外也有的发行版启用了 dual ABI，默认是 C++11 ABI，如果有需要的话，可以用-D_GLIBCXX_USE_CXX11_ABI=0 就可以让编译出来的程序使用旧版 ABI 。

@hongshaorou666 现在新款的 TP 路由基本都支持 IPv6 了，包括 Native 模式和穿透模式（固件里称为 IPv6 桥模式），应该适合几乎所有网络环境。