本文来自微信技术架构部的原创技术分享。
1、前言
普及IPV6喊了多少年了，连苹果的APP上架App Store也早已强制IPV6的支持，然并卵，因为历史遗留问题，即使在IPV4地址如果饥荒的情况下，所谓的普及还是遥遥无期。但不可否认的是，IPV6肯定是未来趋势，做为网络通信领域的程序员来说，详细学习和了解IPV6是很有必要的，所谓厚积薄发，谁知道哪天IPV6真的普及了呢？那么，我们开始看正文吧。
学习交流：
- 即时通讯开发交流3群：185926912[推荐]
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
（本文同步发布于：http://www.52im.net/thread-1605-1-1.html）
2、系列文章
文章太长，分为两篇来讲，本文是2篇文章中的第1篇：
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》（本文）
《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》
本文是系列文章中的上篇，主要讲解IPV6的基本概念。
3、正文引言
2017年11月26日，中共中央办公厅和国务院办公厅印发了《推荐互联网协议第六版（IPv6）规模部署行动计划》，并发出通知，要求各地区各部门结合实际认真贯彻落实。这条新闻传达了一个很重要的信息：这个是推进中国IPv6发展的战略总动员令。
本文将会从以下几个方面进一步介绍IPv6，包括有：
1）IPv6的基本概念；
2）IPv6在Linux操作系统下的实现；
3）IPv6的实验；
4）IPv6的过渡技术介绍；
5）IPv6在Linux平台下socket编程应该注意的问题；
6）实现简易版TGW支持IPv6雏形demo。
值得说的是，目前我们接触得比较多的主流操作系统内核，已经很好地支持IPv6协议栈，例如：
Windows： windows 7、windows 8.x、windows 10，默认开启IPv6；
Linux： 内核2.6.x、内核3.x、内核4.x 已经支持IPv6（需要手动开启）；
iOS：IOS9开始已经支持IPv6 Only，2016年苹果已经强制要求app必须支持IPv6。
本系列文章提到的IPv6节点，没有特殊说明，一般指的是纯IPv6节点（IPv6 Only），也就是只支持IPv6协议栈。IPv4节点，是指纯IPv4的节点，也就是只支持IPv4协议栈。如果节点支持IPv6和IPv4双栈，会指明是双栈节点。
本文是系列文章中的上篇，主要讲解IPV6的基本概念，其它内容将在下篇《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》中详细讲解。
众所周知，32位的IPv4地址已经耗竭，IPv6采用128位的地址长度拥有更大的地址空间。首先我们先来认识一下IPv6到底长成什么样子。
4、初识IPv6
▲ 图1：IPv6数据报文
上图是我们最熟悉的ping的IPv6版本ICMPv6，可以看到，IPv6数据报文和IPv4有很大的差别：
1）数据链路层（L2）的type字段标识为 0x86dd，表示承载的上层协议是IPv6（IPv4对比：type字段为0x0800）；
2）IPv6的头部字段，和IPv4差别巨大（可以猜测到，IPv6和IPv4无法兼容）。
IPv6的报文头部格式如下：
▲ 图2：IPv6报文头部
IPv6报文头部更精简了，字段更少了，对比起IPv4，有以下几个地方值得注意：
1）IPv6报文头部是定长（固定为40字节），IPv4报文头部是变长的。这个意味着，写代码处理IPv6数据报文的效率会提高很多：）；
2）IPv6中Hop Limit字段含义类似IPv4的TTL；
3）IPv6中的Traffic Class字段含义类似IPv4中的TOS（Type Of Service）；
4）IPv6的报文头部取消了校验和字段：取消这个字段也是对IPv4协议的一个改进。当IPv4报文在网路间传输，每经过一个路由器转发就是修改TTL字段，就需要重新计算校验和，而由于数据链路层L2和传输层L4的校验已经足够强壮，因此IPv6取消这个字段会提高路由器的转发效率。值得一提的是，在IPv6协议下，传输层L4协议UDP、TCP是强制需要进行校验和的（IPv4是可选的）；
5）IPv6报文头部中的Next Header字段表示“承载上一层的协议类型”或者“扩展头部类型”。
这里的含义与IPv4有很大的差别，需要加以解释：
当IPv6数据报文承载的是上层协议ICMPv6、TCP、UDP等的时候，Next Header的值分别为58、6、17，这个时候和IPv4报文头部中的Protocol字段很类似;
当不是以上3种协议类型的时候，IPv6报文头部紧接的是扩展头部。扩展头部是IPv6引入的一个新的概念，每个IPv6的数据报文可以承载0个或多个扩展头部，扩展头部通过链表的形式组织起来。当IPv6数据报文承载着扩展头部的时候，Next Header的数值为扩展头部的类型值。
为什么要引入扩展头部这个概念，这里也是IPv6对IPv4改进的一个方面，用扩展头部取代了IPv4的可选项信息，精简了IPv6的头部，增强了IPv6的扩展性。有同学会不会有疑问，IPv6的分片数据报文怎么处理？其实就是使用了IPv6扩展头部。我们来抓一个UDP分片报文来看看。
▲ 图3：IPv6分片报文
当发送一个分片IPv6数据报文的时候，IPv6使用的是扩展头部的形式组织各个分片的信息，如图IPv6报文头部Next Header字段值为44表示存在扩展头部，扩展头部是IPv6分片数据信息。
对比IPv4，分片信息是记录在IPv4报文头部的分片字段中。
IPv6的扩展头部类型有很多种，除了上述的分片头部，还有路由头部、逐跳可选头部等，具体的可以参考RFC2460。
本章主要介绍了IPv6的一些很直观的认识，下面逐渐介绍IPv6上的基本知识和概念。
5、IPv6的地址语法
一个IPv6的地址使用冒号十六进制表示方法：128位的地址每16位分成一段，每个16位的段用十六进制表示并用冒号分隔开，例如：
一个普通公网IPv6地址：2001:0D12:0000:0000:02AA:0987:FE29:9871
IPv6地址支持压缩前导零的表示方法，例如上面的地址可以压缩表示为：
2001 12:0:0:2AA:987:FE29:9871
为了进一步精简IPv6地址，当冒号十六进制格式中出现连续几段数值0的位段时，这些段可以压缩为双冒号的表示，例如上面的地址还可以进一步精简表示为：
2001 12::2AA:987:FE29:9871
又例如IPv6的地址FF80:0:0:0:FF:3BA:891:67C2可以进一步精简表示为：
FE80::FF:3BA:891:67C2
这里值得注意的是：双冒号只能出现一次。
6、IPv6地址的号段划分和前缀表示法
IPv6拥有128位巨大的地址空间，对于那么大的空间，也不是随意的划分，而是使用按照bit位进行号段划分（与鹅厂内部一些的64位uin改造放号的zone划分算法）。
IPv6的地址结构如下图：
▲ 图4：IPv6地址结构
例如RFC4291中定义了n=48, m=16，也就是子网和接口ID与各占64位。
IPv6支持子网前缀标识方法，类似于IPv4的无分类域间路由CIDR机制（注意：IPv6没有子网掩码mask的概念）。
使用“IPv6地址/前缀长度”表示方法，例如：
2001:C3:0:2C6A::/64表示一个子网；
而2001:C3:0:2C6A:C9B4:FF12:48BC:1A22/64表示该子网下的一个节点地址。
可以看到，一个IPv6的地址有子网前缀+接口ID构成，子网前缀由地址分配和管理机构定义和分配，而接口ID可以由各操作系统实现生成，生成算法后面的章节会介绍。
7、IPv6的地址类型
IPv6地址分三种类型：
1）单播，对应于IPv4的普通公网和私网地址；
2）组播，对应于IPv4的组播（多播）地址；
3）任播，IPv6新增的地址概念类型。
IPv6没有广播地址，用组播地址实现广播的功能。实际上我们工作和生活最可能最多接触的就是单播地址，接下来本文重点会讲解单播地址的种类。组播和任播地址有兴趣的同学自行查阅相关RFC和文献。
8、IPv6单播地址
注意：大家如果在网上搜索IPv6的地址，可能都是千篇一律的把所有“出现过”的单播地址介绍出来，其实有一些单播地址类型已经在相关的RFC中被废除或者不建议使用，而本节会指出这类地址。同时，在介绍单播地址的时候，尽量与IPv4中对应的或者相类似的概念做对比，加深理解。
IPv6单播地址有以下几种。
8.1 全球单播地址
▲ 图5：IPv6全球单播地址结构
前缀2000::/3，相当于IPv4的公网地址（IPv6的诞生根本上就是为了解决IPv4公网地址耗尽的问题）。这种地址在全球的路由器间可以路由。
8.2 链路本地地址
▲ 图6：链路本地地址结构
前缀FE80::/10，顾名思义，此类地址用于同一链路上的节点间的通信，主要用于自动配置地址和邻居节点发现过程。Windows和Linux支持或开启IPv6后，默认会给网卡接口自动配置一个链路本地地址。也就是说，一个接口一定有一个链路本地地址。
如下图：
▲ 图7：Linux下查看链路本地地址
▲ 图8：Windows下查看链路本地地址
值得说的是：每个接口必须至少有一个链路本地地址；每个接口可以配置1个以上的单播地址，例如一个接口可以配置一个链路本地地址，同时也可以配置一个全球单播地址。
注意：很容易会把链路本地地址和IPv4的私网/内网地址对应起来，其实链路本地地址对应于IPv4的APIPA地址，也就是169.254开头的地址（典型场景就是windows开启自动获取地址而获取失败后自动分配一个169.254的地址）。而IPv4私网对应于IPv6的什么地址，后面会介绍。
特别地：在IPv6 socket编程中，可以使用链路本地地址编程通信，但是需要增加一些额外的参数（这是一个小坑），在后面介绍编程的章节会介绍。
8.3 唯一本地地址
▲ 图9：唯一本地地址结构
前缀FC00::/7，相当于IPv4的私网地址（10.0.0.0、172.16.0.0、192.168.0.0），在RFC4193中新定义的一种解决私网需求的单播地址类型，用来代替废弃使用的站点本地地址。
可能看到这里，有同学会跳出来说：IPv6不是为了解决IPv4地址耗尽的问题吗，既然IPv6的地址空间那么大，可以为每一个网络节点分配公网IPv6的节点，那为什么IPv6还需要支持私网？这里需要谈谈对IPv6下私网支持的认识。
在IPv4中，利用NAT技术私网内的网络节点可以使用统一的公网出口访问互联网资源，大大节省了IPv4公网地址的消耗（IPv6推进缓慢的原因之一）。另一方面，由于默认情况下私网内节点与外界通信的发起是单向的，网络访问仅仅能从私网内发起，外部发起的请求会被统一网关或者防火墙阻隔掉，这样的网络架构很好的保护了私网内的节点安全性和私密性。可以设想一下，如果鹅厂内部每台办公电脑都配置了IPv6的公网地址上网，是多么可怕的事情，每台办公电脑都会面临被黑客入侵的威胁（肉鸡真多）。
因此，在安全性和私密性要求下，IPv6中同样需要支持私网，并且也需要支持NAT。在Linux内核3.7版本开始加入对IPv6 NAT的支持，实现的方式和IPv4下的差别不大（Linux内核代码中变量和函数的命名几乎就是ctrl+c和ctrl+v过来的-_-||）。
8.4 站点本地地址
前缀FEC9::/48，以前是用来部署私网的，但RFC3879中已经不建议使用这类地址，建议使用唯一本地地址。大家知道有这么一回事就可以了。网上还有很多文章还提到这种地址，但是没有说明这种地址已经不再使用。
8.5 特殊地址：回环地址
0:0:0:0:0:0:0:1或::1，等同于IPv4的127.0.0.1
8.6过渡地址：内嵌IPv4地址的IPv6地址
就是在IPv6的某一些十六进制段内嵌这IPv4的地址，例如IPv6地址中64:ff9b::10.10.10.10，此IPv6地址最后4个字节内嵌一个IPv4的地址，这类地址主要用于IPv6/IPv4的过渡技术中。
9、IPv4兼容地址
0:0:0:0:0:0:w.x.y.z或::w.x.y.z（其中w.x.y.z是点分十进制的IPv4地址）。但在RFC4291中已经不推荐使用这类地址，大家知道有这么一回事就可以了。
过渡地址：IPv4映射地址
0:0:0:0:0:FFFF:w.x.y.z或::FFFF:w.x.y.z（其中w.x.y.z是点分十进制的IPv4地址），用于IPv6地址表示IPv4地址。主要用于某些场景下IPv6节点与IPv4节点通信，Linux内核对这类地址很好地支持，在后面编程和内核分析的章节会分析使用过程。
过渡地址：特定过渡技术地址
6to4地址、ISATAP地址、Teredo地址主要用于对应的过渡技术的地址，在后面介绍过渡技术的时候会介绍。
10、IPv6接口ID生成算法
从前面的介绍中可以看出，IPv6单播地址是由前缀（64位）+接口ID（64位）组成。
接口ID的生成算法主要有以下几种：
1）根据RFC4291定义，接口ID可以从EUI-64地址生成：详细算法可以查看regli同学的PPT第14页；
2）为了可以具备某种程度的匿名信，接口ID可以使用一个随机分配的，windows操作系统默认就是使用这种生成算法，Linux下也是默认开启这个算法；
3）使用状态化的自动配置技术分配，例如DHCPv6分配；
4）手工配置。
11、IPv6地址配置
前面对IPv6的地址、前缀、接口等等做了介绍，接下来就是要介绍一个接口如何配置IPv6地址。IPv6一个比IPv4更厉害的方面，就是可以自动配置地址，甚至这个配置过程不需要DHCPv6（在IPv4中是DHCPv4）这样的地址配置协议。最典型的例子就是，只要开启了IPv6协议栈的操作系统，每个接口就能自动配置了链路本地地址，这个是和IPv4最重要的区别之一。
IPv6的地址配置有以下几种：
1）只要开启了IPv6协议栈，接口自动分配链路本地地址；
2）无状态自动配置地址（RFC2462），后面会有实验演示；
3）有状态自动配置地址，例如DHCPv6。
4）手动配置。
12、IPv6的域名解析
由于IPv6的地址扩展为128位，比IPv4的更难书写和记忆，因此IPv6下的DNS变得尤为重要。IPv6的的DNS资源记录类型为AAAA（又称作4A），用于解析指向IPv6地址的完全有效域名。
下面是一个示例：
Hostipv6.example.wechat.com IN AAAA 2001:db8:1::1
IPv6下的域名解析可以认为是IPv4的扩展，详细可以查看RFC3596.
（—— 本文未完，下篇待续 ——）
附录：更多相关文章
[1] 更多网络编程基础资料：
《TCP/IP详解 - 第11章·UDP：用户数据报协议》
《TCP/IP详解 - 第17章·TCP：传输控制协议》
《TCP/IP详解 - 第18章·TCP连接的建立与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《技术往事：改变世界的TCP/IP协议（珍贵多图、手机慎点）》
《通俗易懂-深入理解TCP协议（上）：理论基础》
《通俗易懂-深入理解TCP协议（下）：RTT、滑动窗口、拥塞处理》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《UDP中一个包的大小最大能多大？》
《P2P技术详解(一)：NAT详解——详细原理、P2P简介》
《P2P技术详解(二)：P2P中的NAT穿越(打洞)方案详解》
《P2P技术详解(三)：P2P技术之STUN、TURN、ICE详解》
《通俗易懂：快速理解P2P技术中的NAT穿透原理》
《高性能网络编程(一)：单台服务器并发TCP连接数到底可以有多少》
《高性能网络编程(二)：上一个10年，著名的C10K并发连接问题》
《高性能网络编程(三)：下一个10年，是时候考虑C10M并发问题了》
《高性能网络编程(四)：从C10K到C10M高性能网络应用的理论探索》
《不为人知的网络编程(一)：浅析TCP协议中的疑难杂症(上篇)》
《不为人知的网络编程(二)：浅析TCP协议中的疑难杂症(下篇)》
《不为人知的网络编程(三)：关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT》
《不为人知的网络编程(四)：深入研究分析TCP的异常关闭》
《不为人知的网络编程(五)：UDP的连接性和负载均衡》
《不为人知的网络编程(六)：深入地理解UDP协议并用好它》
《不为人知的网络编程(七)：如何让不可靠的UDP变的可靠？》
《网络编程懒人入门(一)：快速理解网络通信协议（上篇）》
《网络编程懒人入门(二)：快速理解网络通信协议（下篇）》
《网络编程懒人入门(三)：快速理解TCP协议一篇就够》
《网络编程懒人入门(四)：快速理解TCP和UDP的差异》
《网络编程懒人入门(五)：快速理解为什么说UDP有时比TCP更有优势》
《技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解》
《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《聊聊iOS中网络编程长连接的那些事》
《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
>> 更多同类文章 ……
[2] QQ、微信团队分享的其它技术文章：
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《微信团队分享：微信移动端的全文检索多音字问题解决方案》
《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》
《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》
《微信团队原创分享：iOS版微信的内存监控系统技术实践》
《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》
《iOS后台唤醒实战：微信收款到账语音提醒技术总结》
《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》
《微信团队分享：视频图像的超分辨率技术原理和应用场景》
《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯团队分享：手机QQ中的人脸识别酷炫动画效果实现详解》
《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《微信手机端的本地数据全文检索优化之路》
《企业微信客户端中组织架构数据的同步更新方案优化实战》
《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》
《QQ 18年：解密8亿月活的QQ后台服务接口隔离技术》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《以手机QQ为例探讨移动端IM中的“轻应用”》
《一篇文章get微信开源移动端数据库组件WCDB的一切！》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《微信Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术试验及分析（论文全文）》
《一份微信后台技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信升级iOS9遇到的各种“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《Android版微信安装包“减肥”实战记录》
《iOS版微信安装包“减肥”实战记录》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难题》
《移动端IM实践：iOS版微信小视频功能技术方案实录》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》
《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-1605-1-1.html）
