作者 Tim Crofts,译者 大愚若智
泉源 :infoq
为庆贺 一年一度的天下 IPv6日(始于2011年6月6日),LinkedIn盼望 用一种别具寄义 的方式怀念 这一天。已往 多个月以来 ,我们忙于在本身 的数据中心 内启用IPv6,为此我们计划 了全新的体系布局 ,并在网络、体系 、工具等方面做好充实 的预备 ,终极 于6月6日在一个过渡(Staging)环境 中乐成 启用了IPv6。此番办法 是在全部 数据中心 内实现全功能IPv4/IPv6双堆栈的一个紧张 里程碑,在顺遂 实现这一目标 后,下一步将彻底弃用IPv4 。
在这一系列文章中 ,我们将先容 从IPv4迁徙 至IPv6必要 思量 的题目 ,尤其是诸如LinkedIn如许 的大型企业在迁徙 过程中大概 碰到 的各种挑衅 。但起首 我们想先容 一些有关IPv4和IPv6的根本 信息,以及迁徙 过程中必要 思量 的根本 原则。
IPv6简史
IPv6的整个发展史与IPv4的发展密不可分 。IPv4于1981年被互联网工程任务 组(IETF)正式建立 ,1992年,互联网社区发起 对IPv4寻址方案举行 扩展。IETF为此创建了一个工作组;1996年,一系列名为哀求 注解(RFC)的文档正式建立 了IPv6(每个文档名称以RFC开头 ,后跟用于区分差别 文档的编号)。
与此同时为了缓解IPv4地点 空间即将耗尽的题目 ,他们为内部私有网络保存 了三个公用IPv4地点 段(RFC1597) 。大部分 构造 只必要 将少量服务袒露 到互联网,因此对公用IP空间的需求着实 并不大。通过在构造 内部利用 私有IPv4地点 段,进而将对公用IP空间的需求降至最低 ,即可镌汰 所需IPv4地点 的数量 。业界通过这种方式将公用IPv4地点 空间耗尽的那一天推迟了多年 。
1996年,IETF正式颁布了RFC1918文档,该文档是对RFC1597的改进 ,此中 谈到了利用 私有或公用地点 空间的装备 相互通讯 的差别 需求。三年后,1999年发布的RFC2633中提出的网络地点 转换(NAT)技能 可以主动 对来自私有网络的互联网数据包举行 转换,将其转发至公用互联网 ,并将从公用互联网收到的相应 转换到私有网络。内部装备 可以借助NAT与公用网络中的装备 通讯 ,但无法实现反向通讯 。但是NAT造成了一些新题目 。比方 当两家公司归并 时,由于在归并 前利用 了雷同 的私有IPv4地点 段 ,偶然 大概 必要 办理 内部路由辩论 题目 。全部 私有IPv4流量偶然 间 看起来都像是来自同一个公用IPv4地点 ,因此作为公用服务供应商,假如 制止 某个IPv4地点 的通讯 ,大概 会影响到数千个装备 或用户。
1995年底发布的RFC1883意味着IPv6期间 正式开始 。IPv6最初只摆设 在实行 室内某些操纵 体系 和路由器中,随后以此为底子 构建了一些公用的实行 性网络。随着更多RFC连续 发布,办理 了越来越多的实现和其他题目 后,IPv6网络渐渐 到达 生产环境 中利用 的质量要求 ,但直到2008年2月,互联网编号分配机构(IANA)将IPv6地点 参加 域名体系 (DNS)的根地区 后IPv6才算正式登场,随后IETF在同年三月的集会 会议 中举行 了一次IPv4停用实行 。在大概一小时的实行 过程中 ,工程师测试了在不利用 IPv4的环境 下可以在互联网上实行 的操纵 。此次实行 后,很多 软件都发布了相应的补丁。
2011年6月6日,Internet Society发起了“天下 IPv6日”活动 ,很多 大公司在24小时的活动 期间测试了本身 网站在IPv6(作为对IPv4的增补 )环境 下的表现 。此次活动 一年后的同一天被称作“IPv6发布日 ”,很多 公司在这一天里将本身 的网站切换至IPv6并不停 相沿 至今 。LinkedIn的网站在2014年开始正式可以通过IPv6访问。
本日 ,IPv6流量已经占到环球 互联网流量的10%以上 ,一些国家的占比更高,比方 美国已经到达 30%以上,比利时高出 了50%。一些移动网络已经以IPv6为主 ,占到流量总数80%以上 。Apple也已公布 全部 移动应用必须可以或许 支持纯IPv6网络,并利用 NAT64(与NAT雷同 ,但用途是将IPv6数据包转换为IPv4格式)访问互联网上依然利用 IPv4的部分 。Facebook 、Akamai以及LinkedIn还分别发如今 IPv6环境 下端到端利用 应用程序(尤其是移动应用程序)的速率 也有了很大提拔 。
IPv4和IPv6的重要 差别
IPv4地点 包罗 32位,IPv6地点 包罗 128位 。由于地点 更“大” ,IPv6标头也更大,但其长度是固定的,IPv4标头封包长度是可变的。更紧张 的是IPv6不再必要 校验 ,一样平常 来说校验工作是在硬件层面或上层实现的。这种计划 有助于低落 路由器的负载。末了 ,在IPv6中路由器不必要 拆分数据包,假如 必要 转达 的数据包太大 ,路由器会向发送方发出一个ICMPv6 Packet Too Big(PTB)信息,让发送方以得当 的巨细 重新发送该数据包 。这些改进低落 了路由器处理 惩罚 每个数据包时的负荷,进而进步 了路由器工作服从 。
IPv6的体系布局 确保了装备 无需会合 化服务 ,即可通过无状态地点 主动 设置 (Stateless Address AutoConfiguration,SLAAC)技能 得到 本身 的IPv6地点 。IPv6有两种重要 范例 :链路范围(Link scope)和环球 范围(Global scope) 。本地 IPv6地点 只能在当前网段内利用 ,环球 地点 通常来自路由器所宣告的网络 ,并会连合 接口的MAC地点 。IPv6中也存在一种会合 化的服务:DHCPv6,该服务基于动态主机设置 协议(DHCP),但为了与SLAAC共存举行 了少量改动。
迁徙 至IPv6
迁徙 至IPv6的过程中产生了一种风趣 的“22条军规(Catch-22)”:为了顺遂 迁徙 必须将最盛行 的网站迁徙 至IPv6,但通常来说小规模网站迁徙 至IPv6的过程要比大型网站的迁徙 轻易 得多 。IPv6网络上一台服务器可手工设置 并快速完成 ,但大型网站通常包罗 很多 面向IPv4的路由器、负载均衡 器、防火墙 、监控工具,以及各种装备 和软件,这些东西必要 举行 相应的变化 才华 用于IPv6。
通过顺遂 迁徙 大型网站通常必要 的各种特别 装备 和软件 ,天下 IPv6日和天下 IPv6发布日资助 互联网社区办理 了很多 题目 。路由器、负载均衡 器,以及防火墙渐渐 应用了各种修复程序,地理位置的分部也渐渐 美满 。支持IPv6的Web缓存服务越来越多 ,Packet too big(PTB)信息已经可以由安全筛选器处理 惩罚 ,启用IPv6的DNS底子 布局 可以实现更快速的相应 ,除此之外尚有 很多 其他改进。
然而将内部网络转换为IPv6则是一个截然差别 的故事:这一过程必要 很多 其他组件相互配归并 必要 可以或许 伸缩。对于大规模摆设 ,就算RFC1918空间也不敷 以对全部 内部网络需求举行 寻址 。每个国家的办公室都必要 有本身 的网络,云平台也必要 大量盘算 机,因此对于大型网络来说 ,就算10.0.0.0/8也显得不敷 大,地点 空间的重叠也会成为一个贫苦 事。利用 诸如NAT等办理 方案对地点 空间举行 转换可以缓解此类题目 ,但这种办理 方案也会产生一系列新题目 ,比方 应用程序内嵌入的IP地点 ,通过伸缩处理 惩罚 更大数量 的转换,以及由于引入“NAT防火墙 ”造成的各种安全题目 。
在实际 环境 中,可以直接关闭路由器的IPv4功能并启用IPv6 ,但大部分 环境 下这种做法并不可行。我们以为 内部网络举行 过渡的最佳战略 是起首 迁徙 至双堆栈环境 ,并通过妥善订定 的“镌汰 ”战略 彻底弃用IPv4 。如许 各人 可以有更多时间认识 IPv6,并将本身 的工具、软件 ,以及流程渐渐 迁徙 至IPv6,颠末 如许 的步调 ,只有很少一部分 流量必要 通过IPv4处理 惩罚 。然而这种方式最大的不敷 在于 ,为双堆栈环境 提供支持不但 更复杂,而且维持两个网络的大量运维工作会拖累新服务的摆设 速率 ,假如 两种协议未能同步还大概 造成新的题目 。IP地点 的管理也会变成 一种复杂的任务 ,由于 IPv4和IPv6地点 空间的映射通常还必要 很多 其他功能,比方 ACL的实现 、路由汇总、负载均衡 器等 。
因此有须要 面向将来 做好预备 并尽快动手 IPv6的迁徙 ,随后即可按部就班将越来越多的流量顺遂 迁徙 至IPv6。由于为两个网络栈提供支持会导致工作复杂度提拔 将近 一倍,一旦迁徙 至IPv6还必要 尽快彻底弃用IPv4。
LinkedIn的IPv6迁徙
双堆栈环境 可以资助 你循规蹈矩 地将服务器迁徙 至IPv6 。一些应用程序的迁徙 难度大概 略低 ,比方 某些核心 UNIX服务的迁徙 就是一种唾手可得的工作。
6月6日,我们决定开始迁徙 本身 的某个过渡环境 ,尤其是LinkedIn用于在发布“新”服务前举行 测试利用 的过渡环境 。我们筹划 为该环境 中全部 体系 添加一个环球 IPv6地点 ,并对尽大概 多的核心 服务举行 迁徙 ,借此进步 IPv6网络流量的比例 。
我们必要 确保此番迁徙 不会粉碎 尚未测试的服务,为了实现须要 的控制 ,我们利用 了IP双堆栈环境 的一些根本 特性。比方 ,我们的大部分 软件是通过Java开辟 的,默认环境 下Java应用程序在运行时必要 通过一个声明(Declaration)宣告本身 在利用 IPv6。因此我们无需担心软件忽然 发现IPv6并自行开始利用 该环境 。我们还决定不为任何利用 环球 IPv6地点 的盘算 机的主机名添加AAAA DNS记录 ,如许 利用 其他语言发起的毗连 就不会通过IPv6运行。借此可以确保其他软件、工具,以及实用程序可以像从前 一样继承 通过IPv4运行,整个环境 不受任何关 扰。
从那天下战书 开始 ,我们在几分钟内为高出 1500个体系 添加了静态的环球 IPv6地点 。对于任何此种规模的体系 ,主动 化机制都非常紧张 ,可以资助 我们快速将变动 摆设 给整个体系 。在确认通过IPv6正常运行没碰到 任何错误后,我们为这些主机增长 了AAAA记录 ,借此这些操纵 体系 将首选利用 IPv6而非IPv4。全部 这些工作完成后,开始将某些核心 底子 布局 服务(DNS 、syslog、SMTP、NTP 、会合 身份验证等)的流量从IPv4迁徙 至IPv6。在大概一个小时内,我们通过受控的方式将底子 布局 内的多个此类服务切换至IPv6网络中 。将来 几个月里 ,还将继承 将更多底子 布局 服务迁徙 至IPv6,同时也将积极 让Rest.li等自行开辟 的软件框架优先选择利用 IPv6而非IPv4。
除了上述工作,为了向成员提供服务 ,我们如今 还在建立 一个全新数据中心 。这个数据中心 在计划 伊始就充实 思量 了IPv4和IPv6双堆栈,别的 还包罗 其他很多 先辈 技能 。这个数据中心 在LinkedIn内部被称之为Project Altair,之前的很多 博客文章中曾经举行 过先容 。
借助启用IPv6的过渡环境 和生产环境 ,我们可以将越来越多的内部流量迁徙 至IPv6。在6月6日的首轮工作乐成 实现后,对于将其他内部环境 迁徙 至IPv6我们也更加自大 。
一旦顺应 IPv6流量后,该开始思量 弃用IPv4并让数据中心 运行在纯IPv6环境 下。这个目标 并不迢遥 ,我们筹划 在2017年内全面实现。同时为IPv4和IPv6提供支持意味着必要 付出将近 两倍的工作量,因此一旦决定采取 IPv6,必要 确保过渡过程尽大概 短 。然而很多 供应商和软件产物 如今 并不能全面支持IPv6,为了实现我们终极 的迁徙 目标 ,还必要 针对这种环境 采取 须要 的步伐 。
LinkedIn内部创建 了由“IPv4处理 惩罚 专家 ”构成 的“AAAA团队”。这是一个很赞的技能 项目,我们也盼望 能有更多雷同 我们如许 的构造 将本身 的数据中心 迁徙 至IPv6,只有通过这种团体 相助 的方式才华 顺遂 办理 妨碍数据中心 和云环境 全面采取 IPv6的遗留题目 。请参加 我们一起为终极 目标 贡献本身 的力气 。
在这一系列文章的第1篇中(以上内容) ,我们先容 了将内部网络迁徙 至IPv6的缘故起因 。领英(LinkedIn)网站从2014年起即可通过IPv6公开访问,而我们的员工在这之前早已可以通过IPv6访问公众互联网。固然 很早从前 我们网络中的大部分 组件就已支持IPv6,但直到近来 内部数据中心 依然运行在IPv4下 。本文我们将从网络运维的角度先容 为什么必要 创建同时包罗 IPv4和IPv6的环球 网络 ,以及开始在本身 的数据中心 内启用双堆栈环境 ,并等待 着有朝一日能彻底弃用IPv4的过程中所面对 的挑衅 。
网络计划 :回到将来
除了链路本地 (Link-local)地点 和现已废除的站点本地 (Site-Local)地点 等例外 环境 ,全部 IPv6地点 均已环球 可路由。通过IPv4 RFC1918空间我们已经知道利用 这种地点 的私有网络是不会“泄漏 ”到互联网的 。然而在IPv6网络中这一点还无法保障 ,由于 全部 全局IPv6空间都是环球 可路由的。如今 计划 数据中心 时必要 实行 更妥当 的安全战略 ,由于 流量大概 同时源自内部和外部。如今 已无法通过某些简单 的战略 只答应 或只拒绝RFC1918地点 。
当全部 地点 都环球 可路由时,数据包大概 会通过差别 路径到达同一个目标 地。假如 转发路径(Forward path)的计划 不敷 审慎 ,大概 导致数据包通过一个防火墙出站,通过另一个防火墙返回的环境 。防火墙是有状态的,这意味着它们会记取 内部盘算 机与外部盘算 机之间的毗连 状态,如许 才华 主动 答应 返回的流量通过防火墙 。但是跨防火墙分享状态这种做法很难实现 ,而且 大概 不敷 安全。更紧张 的是,路径中的某些部分 大概 会通过安全性不那么高的公众互联网传输,而非通过内部网络举行 。
利用 IPv6时无法轻易 通过查察 目标 IP地点 是否包罗 在RFC1918空间来确定流量是内部还是 外部的。内部和外部流量哪怕是假造 的 ,也依然必要 隔离 。为了实现这种隔离,必须重新相沿 NAT技能 诞生前的网络计划 思绪 。换句话说,我们“回到将来 ”了。
NAT使得深藏于数据中心 内的盘算 机可以直接访问互联网 ,从本质上来说这必要 创建 一对一的NAT毗连 。我们决定在本身 的数据中心 内设置一块不公告到互联网的IPv6地点 段,这也意味着全部 位于这个地点 段内的盘算 机必须通过DMZ中设置的一系列署理 或网关访问互联网。为确保整个体系布局 尽大概 简单 ,我们不盼望 内部盘算 机在无法通过IPv6直接访问互联网的环境 下可以通过IPv4直接访问。由于筹划 实行 双堆栈 ,必要 禁用IPv4上的全部 NAT 。如许 内部的全部 盘算 机无论利用 IPv4或IPv6,都必须成为多宿主(Multi-homed)盘算 机。
通过利用 边界 网关协议(Border Gateway Protocol,BGP) ,可以将一个路由器所知道的IPv4和IPv6路由通过IPv4或IPv6毗连 公告给四周 其他路由器。由于领英的终极 目标 是彻底弃用IPv4,我们决定不让公告超过 网络堆栈,我们的IPv6路由公告都将只通过基于IPv6的BGP会话对外公告 。
增长 新的网络堆栈要求安全性至少要与本来 的IPv4环境 相称 。此时一种方法是利用 筛选器拒绝全部 IPv6流量并从这里入手。然而一旦装备 可以感知IPv6,当它无法通过IPv6到达目标 地 ,而且 应用程序无法“优雅”回退至IPv4,或无法及时 实现回退时服务大概 会停止 。因此我们选择了另一种方法。
另一种方法是将现有的访问控制列表(ACL)直接从IPv4转换为IPv6。这种方法的结果 到底有多大差别 ?举例来说,将ICMP筛选器转换为ICMPv6筛选器即可让Ping数据包直接到达目标 盘算 机 ,但正如这一系列文章的第1篇中提到的,ICMPv6的Packet Too Big(PTB)信息是IPv6独有的,这种信息对通过封装隧道(Encapsulating tunnel)举行 的 ,或利用 了巨型帧的通讯 至关紧张 。以太网IP数据包通常最大只能到达 1,500字节,但隧道技能 会将一个数据包封装到另一个数据包内(比方 NAT64),而为了通过高速链路实现更快速的传输 ,大概 必要 利用 巨型帧(高出 1,500字节)数据包 。为克制 碰到 难以诊断的网络毗连 题目 ,必须确保可以或许 顺遂 天生 、吸取 和处理 惩罚 PTB信息。由于IPv4(以及其他雷同 环境 )没有PTB的概念,因此不能直接将现有ACL转换为IPv6版本 ,否则将无法提供对PTB信息举行 授权的规则。
终极 我们乐成 实现了通过访问控制列表(ACL)为环境 、盘算 机等提供掩护 这一目标 。在IPv6网络上启用两个装备 并创建双堆栈之前,假如 不创建与IPv4规则等价的IPv6 ACL规则,装备 间的通讯 大概 会停止 。
别的 我们还利用 假造 IP(VIP)将客户端通过一个IP地点 毗连 到多个服务器。IPv4和IPv6网络中这些VIP的设置 略有差别 。比方 为了精确 发送到终极 的目标 服务器,一些处理 惩罚 VIP的负载均衡 器被设置 为重写数据包的以太网部分 。无论IPv4或IPv6 ,这个服务器必须能用本身 的原生协议处理 惩罚 数据包。因此假如 某个VIP是双堆栈的,这意味着该VIP代表的全部 盘算 机都必须是双堆栈的 。在负载均衡 器的设置 中,IPv4和IPv6的VIP设置 是两个差别 的设置 选项 ,但我们不盼望 在DNS中为VIP设置差别 名称。同理为了克制 产生其他技能 债,由于终极 目标 是完全利用 纯IPv6环境 ,我们也不盼望 利用 诸如vipname-v6如许 的主机名。因此在DNS端 ,当服务器可以开始处理 惩罚 IPv6流量后,会给VIP名称增长 一条AAAA记录 。
通过上述题目 我们意识到,为装备 创建IPv6地点 架构可以资助 我们在并非全部 盘算 机的主机名都有DNS AAAA记录 (或反向DNS记录 ,假如 必要 的话)时实现很多 目标 ,比方 根据差别 呆板 之间的互访需求界说 IP规则。
为装备 提供怎样的IPv6地点 ?
我们不想为主机名添加DNS AAAA记录 ,由于 在添加该记录 后 ,到这些服务器的毗连 将首选利用 IPv6。我们必须起首 确定全部 软件都支持IPv6,随后才华 启用双堆栈服务器。
别的 我们也不盼望 将IPv4地点 嵌入IPv6地点 (比方 :2620:abcd:efef::192.168.1.1),缘故起因 在于:
上述例子中的地点 在接口大将 被表现 为2620:abcd:efef::c0a8:0101;
IPv4地点 空间枯竭的题目 还没有乐成 办理 ;
弃用IPv4将造成技能 债 。
为了轻松地将IPv4 ACL转换为IPv6 ACL,我们依然必要 能在没有为主机名添加AAAA记录 的条件 下 ,通过盘算 机的IPv4地点 知道它的IPv6地点 。(ACL决定了哪些盘算 机得到 了授权,可以访问某一特定盘算 机。)
对于这个题目 ,我们的办理 方案是将每个IPv4网络与IPv6网络配对 ,并利用 IPv4地点 末了 两个位组(Octest)的十六进制格式作为IPv6地点 的末了 一个Quibble(IPv6地点 用Quibble表现 ,每个Quibble为4字节/16比特,用冒号分隔) 。选择利用 末了 2个位组的缘故起因 在于 ,如许 的话我们一些最小规模的IPv4网络就可以与利用 /23掩码的IPv6网络配对(为了放入同一个机柜中,大部分 此类网络都是/24或/25规模的)。我们利用 了与IP地点 管理体系 (IPAM)中雷同 的子网配对选项。通过这种方式,即可针对特定VLAN当前分配的IPv4子网得到 IPv6子网 。
为了简化ACL、路由聚合 ,以及表里 部网络边界 等题目 ,我们决定为如今 和将来 的全部 数据中心 利用 一个充足 大的IPv6网络。如许 做也可以简化内部IPv6流量的辨认 工作,由于 只必要 查察 地点 的泉源 块(Block)就够了。
为了进一步简化这一系列过程 ,我们还决定为全部 与服务器毗连 的路由器接口设置fe80::1作为链路本地 IPv6地点 。在领英的全部 数据中心 内,服务器始终会利用 eth0接口访问默认网关,因此默认网关始终可通过eth0接口的fe80::1地点 ,即“fe80::1%eth0”的方式访问。不必要 利用 路由器公告信息即可创建 默认网关。我们的全部 IPv6地点 都是静态的(由于 动态IPv6地点 必要 在DNS中维护) ,因此客户端总能找到要毗连 的服务器 。由于服务器数量 浩繁 ,全天时间内会发生多次重要 为静态情势 的服务器更新。通过将FE80::1作为网关,利用 特别 脚本或工具分析 路由表即可知道任何网段均已不必要 默认网关。对于IPv6地点 或默认网关来说 ,任何动态架构都必须通过连续 广播有关网络的信息让体系 保持动态的状态。但利用 静态状态后,无须确保必须及时 将信息广播给服务器和装备 就可以让它们维持本身 的网络状态 。我们的服务器IP就利用 了如许 的架构。我们的网络装备 利用 了更传统的架构,此中 点对点链路通过更大的地点 块构成 了一个独特网络 ,而环回(Loopback)地点 则来自专用的IPv6地点 空间。
对于服务器,我们利用 了静态的IPv4和IPv6 IP地点 。我们会利用 上文提到的IPAM工具记录 全部 网络和主机名。如许 在供应装备 时就可以知道每台主机位于哪个机柜,利用 哪个端口毗连 。IPAM信息会纳入DNS中 ,如许 就不必要 利用 动态DNS将IP与主机名映射 。别的 我们的应用程序堆栈会通过发现服务将服务映射为主机名。思量 到这些因素,利用 静态IP地点 的做法更公道 ,确保了我们可以控制IP的分配不会改变 ,而且 应用程序堆栈也可以利用 连续 稳固 的名称和IP地点 对应关系。
与IPv4战略 的差别 之处在于,无须利用 NAT66为署理 和其他DMZ功能提供支持,即可通过IPv6访问互联网 。DMZ中全部 主机将利用 多宿主毗连 在数据中心 提供内部IPv6毗连 ,并通过防火墙提供到互联网的外部IPv6毗连 。
为了支持领英实现纯IPv6数据中心 这一终极 目标 ,我们必要 确保终端访问控制器访问控制体系 (Terminal Access Controller Access Control System,TACACS) 、网络时间协议(NTP)、体系 日记 (Syslog)、简单 网络管理协议(SNMP),以及sFlow等其他服务均可支持IPv6源地点 ,并在功能方面能与IPv4看齐。也就是说应用程序层必要 支持IPv6,用于管理全部 这些装备 的工具也必要 支持IPv6 。终极 全部 装备 必要 能通过纯IPv6网络供应。面对 IPv6,零打仗 供应(Zero Touch Provisioning ,ZTP)技能 依然有待美满 ,由于 此中 还用到大量遗留组件。我们将在这一系列文章的第3篇从较高角度先容 怎样 让软件或应用程序可以或许 在IPv6网络中正常运转。
致谢
本文撰写过程中得到了AAAA团队下列成员的巨大资助 :
Zaid Ali 、Sriram Akella、Andrey Bibik、Donaldo Carvalho 、Bo Feng、David Fontaine、Prakash Gopinadham 、David Hoa、Sanaldas KB、Henry Ku 、Prasanth Kumar、Vikas Kumar、Tommy Lee、Leigh Maddock 、Navneet Nagori、Marijana Novakovic、Ved Prakash Pathak 、Stephanie Schuller、Chintan Shah、Harish Shetty 、Andrew Stracner、Veerabahu Subramanian、Shawn Zandi 、Andreas Zaugg、David Paul Zimmerman、Paul Zugnoni 。
作者:Tim Crofts,阅读英文原文:IPv6 at LinkedIn Part I, "ChippIn'" Away at IPv4
感谢陈兴璐对本文的审校。