将 IPv6 照进现实，我们需要做些什么？
|
这个消息就包含了重要的 Prefix 字段，这是基于 IPv6 stateless Autonomous Address-Configuration(SLACC) 的实现，从后续的数据流可以看到，手机收到了这个64位的前缀后补充了后面的64位组合成完整的128位IPv6地址作为源地址进行正常的业务访问。不过稍微有一点疑问的是这后面的64位地址是怎么生成的，从多次测试来看每次后64位都是变化的，由于在手机上构造包需要 root，所以后续条件具备情况下会进行通过构造不同后64位的数据报文来进行测试，看看网络是不是仅靠前64位来识别用户的。 接着就面临到了最后一个问题，即这个地址有玄机吗?128位的地址一方面让人很难记，另一方面也给地址扫描造成了巨大的难度，如果这些地址都是完全随机的，那么对于那些依赖地址信息的后端业务来说将是巨大的灾难。不过运营商帮我们在一定程度上解决了这个问题，但他们的出发点是为了更好的监管，也就是在文章片头的那句世界上的每一粒沙子都有一个地址后面要加上世界上每一粒沙子都是可被追踪的。 根据工信部2014年发布的《YD/T 2682-2014 IPv6接入地址编址编码技术要求》，其中对用户设备接入地址结构的指导性意见为：
其中：
国内三大运营商都基于此技术要求做了进一步的细化，这里不再描述细节，但从地址大段上来看中国移动使用的2409:8000::/20IPv6地址，中国联通使用的2408:8000::/20 IPv6地址，中国电信则有240E::/24、240E::/20、2001:0C68 ::/32、2001:07FA:0010::/48、2402:8800::/32 五块地址。 不过这里需要说明的是目前双栈仅在 4G 下开启，也就是说回到 2G 会变成 IPv4 only，这又该客户端对于当前网络环境判断增加了变数;还有就是由于目前地址具有了一定的位置属性，那么跨区县移动场景下的地址分配怎么处理还暂不明确。 Happy EyeBall 问题 在手机，网络和服务端全链路支持双栈的场景下，手机首先要面对的就是一个选择问题，即一个域名会解析出来 A 和 AAAA 记录，简化来说就是两个地址，同时返回两个地址，怎么选择?一个快，一个慢怎么选择?一个出问题怎么选择?地址选择好了才能有后续的建连，才会有业务发生，所以这个选择策略很重要。如果从体验角度出发，谁快连谁这是最简单的逻辑，但在当前 v4 网络好于 v6 的大环境下这样的逻辑只会让 v6 的普及变得更为艰难，因此针对这个问题，IET F先起了一个名字叫 Happy Eyeball，接着发布了两份 RFC 来描述推荐的处理逻辑，最新的是 RFC8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency，有兴趣的可以去阅读下，这里只摘抄出最重要的一段： The algorithm proceeds as follows: if a positive AAAA response (a responsewith at least one valid AAAA record) is received first, the first IPv6connection attempt is immediately started. If a positive A response is receivedfirst due to reordering, the client SHOULD wait a short time for the AAAAresponse to ensure that preference is given to IPv6 (it is common for the AAAAresponse to follow the A response by a few milliseconds). This delay will bereferred to as the "Resolution Delay". The recommended value for theResolution Delay is 50 milliseconds. If a positive AAAA response is receivedwithin the Resolution Delay period, the client immediately starts the IPv6connection attempt. 简单来说就是 RFC 建议优选 IPv6，且给 AAAA 记录的返回留50毫秒的容忍期。 由于系统的限制，这样选择逻辑的落地是客户端网络库无关的，基于网络材料来看目前各系统的具体实现： 苹果 iOS：在 v4 和 v6 双协议栈的情况下，从 ios9 开始苹果会发出 A 和 AAAA 记录的 DNS 请求，如果首先收到了 DNS 的 AAAA 记录返回，那么苹果会马上发出v6 的 syn，如果首先收到了 A 记录的返回，会有一个 25ms 的定时器，如果超时了就会发送 v4 syn，如果在这个定时器内收到 AAAA 就会发送 v6 的 syn。这个机制和 Happy Eyeball 基本一致，只是等待时长不同，苹果会不会修改到 RFC 建议值未知。 Android：优选 v6，但等待时长未知。 这样的机制从理论上就会出现由于这个等待时长造成业务体验的下降。 还有 NAT 吗，会有 PAT 吗，还有防火墙吗? 在移动网只有 IPv4 的场景下，手机用户访问服务端的整个链路中必不可少的一个中间设备就是运营商的防火墙，一方面为了应对 v4 地址稀缺的问题，设备会做公私网的地址翻译，为了更进一步的复用地址，还会做端口翻译，另一方面为了安全性考虑，设备会做一些类似 ACL 的安全策略，通常只会允许出方向的访问，同时为了降低对于设备的负荷，还会做一些超时的设置，断开那些空闲较长的连接。而这样的限制对于服务端某些过度依赖地址的应用，对于端口转换不友好的应用，对于需要长期保活的应用都会产生一定的影响，那么在 IPv4v6 双栈的场景下如何呢，我做了如下的测试：在一台有公网 IPv6 地址的服务器上简单用 python 写了一个开启80端口的服务端： Server start at:2400:3200:1000:xx:::80 wait for connection... 在手机上执行busybox telnet 2400:3200:1000:xx:: 80 命令 这是服务端打出的日志 Connected by('2409:8928:84e:995:xxxx:xxxx:xxxx:xxxx', 34102, 0, 0) （编辑：宁德站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
