PDFIPv6 部署的成功策略。 真的。
知道从哪里开始就成功了一半。
Thomas A. Limoncelli，谷歌，引言作者 Vinton Cerf
引言
TCP/IP 的设计始于 1973 年，当时 Robert Kahn 和我开始探索互连不同类型分组交换网络的后果。我们在 1974 年 5 月发表了一篇概念论文2，并在 1974 年 12 月发表了 TCP 的相当完整的规范1。到 1975 年底，已经完成了几个实现，并发现了许多问题。迭代开始了，到 1977 年，结论是 TCP（当时称为传输控制协议）应该分成两个协议：一个简单的互联网协议，它通过网关将数据报端到端地传输通过分组网络互连；以及一个 TCP，它管理在假想互联网上的主机之间交换的数据包的流和排序。这种拆分允许实时但可能是有损和无序的数据包交付，以支持数据包语音、视频、雷达和其他实时流。
到 1977 年，我担任 DARPA（美国国防高级研究计划局）当时称为互联网研究计划的项目经理，并面临一个问题：“互联网需要多少地址空间？” 假定每个网络上的每个主机都需要一个地址，该地址由“网络部分”和“主机部分”组成，可以唯一地标识特定网络上的特定计算机。连接互联网网络的网关将理解这些地址，并且会知道如何将互联网数据包从一个网络路由到另一个网络，直到它们到达目标网络，届时最终网关会将互联网数据包定向到该网络上的正确主机。
关于互联网的工程师和科学家之间进行了近一年的辩论，但没有得出确定的结论。有些人建议使用 32 位地址（8 位网络，24 位主机），有些人说 128 位，还有一些人想要可变长度的地址。程序员们拒绝了最后一个选择，因为他们不想费力寻找互联网数据包的字段。对于一个最初只涉及几个网络的实验来说，128 位的选择似乎过多了。到那时，研究工作已经进行了第四次迭代（IP 层协议称为 IPv4），作为项目经理，我觉得有必要继续进行 TCP 和 IP 的实时测试和最终设计。在没有达成共识的情况下，我选择了 32 位地址。我认为 43 亿个潜在地址足以进行实验以证明这项技术。如果它有效，那么我们可以回头设计生产版本。当然，现在是 2011 年，实验从未真正结束。
ICANN（互联网名称与数字地址分配机构）接替 Jonathan Postel 成为当时和现在仍然称为 IANA（互联网地址分配机构）的运营商。IANA 历史上向最终用户分配了大量地址空间，或者在互联网商业化之后，向 ISP（互联网服务提供商）分配了大量地址空间。随着区域互联网注册管理机构（用于互联网地址）的创建，IANA 通常向五个区域注册管理机构之一分配 IP 地址空间的 24 位子集（足够容纳 1600 万台主机），而这些区域注册管理机构又将空间分配给 ISP，或者在某些情况下，分配给非常大的最终用户。在撰写本文时，ICANN 宣布它刚刚分配了最后五个大型 24 位空间块。
IETF（互联网工程任务组）在 1990 年代初期认识到，互联网的快速增长极有可能导致地址空间耗尽，并且经过多年的辩论和分析，设计了一种名为 IPv6 的新的扩展地址格式。（IPv5 是流应用程序的实验，该实验无法扩展并被放弃。）IPv6 具有少量新功能和旨在加速处理的格式，但其主要优势是源和目标主机地址各 128 位。这足以容纳 340 万亿万亿万亿个地址——足够在可预见的未来使用。
IPv6 格式与 IPv4 不向后兼容，因为仅支持 IPv4 的主机没有引用仅支持 IPv6 的目标所需的 128 位地址空间。因此，有必要实施双栈设计，允许主机在两种协议都在使用的时期内使用任一协议进行通信。最终，将没有可用于额外 IPv4 主机的地址空间，并且仅支持 IPv6 的主机将成为必需。希望 ISP 能够在 IPv4 地址实际耗尽之前实施 IPv6 支持，但在未来几年内有必要允许双模式运行。
世界 IPv6 日计划于 2011 年 6 月 8 日举行，届时尽可能多的愿意且有能力的 ISP 将启用其 IPv6 支持，以便最终用户和服务器在全球范围内测试新协议一天。迁移到 IPv6 是自 1970 年代末和 1980 年代初互联网标准化以来，互联网架构最重大的变化之一。这将需要许多人付出专门的努力，以确保用户、服务器以及互联网服务和接入提供商能够妥善管理新旧协议的并发运行。
本文的其余部分考虑了可以采取哪些步骤来实现此目标。 ——Vinton Cerf
迁移到 IPv6 的策略
总有一天，美国的三位数字电话区号将用完，将被迫增加一位数字。正如 Vint Cerf 在引言中解释的那样，互联网也面临着地址结构方面的类似情况。这个问题经常被预测，但长期以来一直被忽视，现在已经成为现实。我们已经用完了 32 位 IP 地址 (IPv4)，并且正在转向 IPv6 的 128 位地址格式。本节着眼于一些正在进行过渡的组织的策略。有效的策略往往是那些专注于特定应用程序或网站，而不是试图转换整个组织的策略。
对于许多组织来说，最大的决定仅仅是知道从哪里开始。在本文中，我们考虑三种可能的策略。
我们提出的第一个场景是一个警示故事，告诫您可能的第一反应。虽然是虚构的，但我们已经看到这个故事以各种形式上演。其他两个例子已被证明是更成功的方法。知道了这一点，我们会为正在考虑过渡到 IPv6 的企业提供以下建议：从一个小型、定义明确的项目开始，该项目对企业具有明显的价值。
故事 1：“升级一切！”
虽然制定升级一切的宏伟计划是崇高且善意的，但认为这是一个好的首要实验是错误的。它很少有明显的价值（惹恼管理层），它可能会超出您的能力范围（惹恼您），并且错误会影响您每天在自助餐厅必须见到的人（惹恼同事）。
这种策略通常会像这样发生：有人冲进老板的办公室说：“救命！救命！我们必须将所有东西都转换为 IPv6。” 这意味着转换网络设备、DNS（域名系统）、DHCP（动态主机配置协议）系统、应用程序、客户端、桌面、服务器。这是一个庞大的项目，将涉及网络上的每个设备。
这些人听起来像小鸡 Little 声称天空要塌下来了。
这些人被老板办公室赶了出去。
更好的方法是去找老板说：“我想用 IPv6 做一件具体的事情。这就是它将如何帮助公司。”
这些人听起来专注而坚定。他们通常会获得资金。
老板很少意识到这个“具体的事情”需要涉及许多依赖项。这些包括网络设备、DNS、DHCP 等等——是的，与小鸡 Little 喋喋不休的清单相同。
不同之处在于这些人获得了这样做的许可。 这将我们引向...
故事 2：由外而内工作。
从根本上讲，第二种策略是从您组织的外部 Web 存在开始。通常，外部 Web 服务器隐藏在称为负载均衡器的硬件设备后面。当 Web 浏览器连接到您的网站时，它们实际上是连接到负载均衡器。它将连接（作为“中间人”）中继到实际的 Web 服务器。在这样做时，它执行许多功能——最重要的是，它在两个或多个冗余 Web 服务器之间负载分担传入的 Web 流量。
在这种策略中，目标很简单：将从您的 ISP 到您的负载均衡器路径上的每个组件升级到 IPv6，并让负载均衡器为您转换为 IPv4。现代负载均衡器可以在“前端”接收 IPv6 连接，并在“后端”将 IPv4 连接发送到您的 Web 服务器。也就是说，您的负载均衡器可以是一个转换器，允许您提供 IPv6 服务，而无需您更改 Web 服务器。这些升级可以是第二阶段。
这是一个可实现的、一口大小的项目。它具有真正的有形价值，您可以向管理层解释，而无需过于技术化：“即将到来的仅支持 IPv6 的用户浪潮将更快地访问我们的网站。如果没有此升级，这些用户将因 ISP 设置为临时措施的 IPv4/v6 转换器而更慢地访问我们的网站。” 这是一个非技术主管可以理解的解释。
管理层可能不相信会有仅支持 IPv6 的用户。难道不是每个人都像之前描述的那样是“双栈”吗？大多数是，但 LTE (“4G”) 手机和无数其他配备 LTE 的移动设备最终将仅支持 IPv6。ARIN（美国互联网号码注册管理机构）告知 LTE 提供商，IPv4 耗尽迫在眉睫，LTE 提供商已为新 LTE 用户将仅支持 IPv6 的一天做好了准备。10 显然，这波新的仅支持 IPv6 的用户将希望访问仅支持 IPv4 的站点，因此运营商正在建立大型服务器场来进行转换。4
这有两个问题。首先，转换预计会很慢。3 其次，地理位置定位会错误地将用户识别为服务器场所在的位置。这意味着如果您的网站依赖于地理定向的广告，则广告将适用于服务器场的位置，而不是用户的位置。由于 LTE 主要用于移动设备，因此这一点尤为紧迫。因此，如果您的公司希望确保接下来的大约一百万新用户能够快速访问您的网站9，或者如果收入依赖于广告，那么管理层应该关注。
大多数 CEO 都能理解简单、非技术性的价值陈述，例如“仅支持 IPv6 的新用户浪潮访问网站将更快”或“这是确保高收入、地理定向广告继续正常工作的必要条件。”
这样的项目只需要进行适度的更改：一些路由器、一些 DNS 记录等等。这也是进行更改的安全场所，因为您的外部 Web 存在为在测试环境中进行更改制定了良好、可靠的测试方案，该方案会把关 QA 环境，然后再进入生产环境。对吧？
一旦从 ISP 到负载均衡器启用了 IPv6，并且负载均衡器正在接受 IPv6 连接，但向 Web 服务器场发送 IPv4 连接，新的机会就会出现。随着每个 Web 服务器都准备好支持 IPv6，负载均衡器不再需要为该主机进行转换。最终，您的整个 Web 服务器场都将是双栈的。这种技术提供了一个节流阀来控制更改的节奏。您可以一次进行小的更改，并在整个过程中进行测试。
在这样做时，您将升级路由器、DNS 服务器和其他组件。虽然如果要求您更改网络堆栈的每一层，您的老板会尖叫，但您实际上已经这样做了。
当然，一旦您完成了这项工作并表明世界末日没有到来，开发人员将更愿意在 IPv6 下测试他们的代码。您可能需要在通往 QA 实验室的路径上启用 IPv6。那是另一个一口大小的项目。将请求另一条路径。然后又一条。然后是开发人员使用的 LAN。然后在任何地方都这样做是有意义的。您现在已经实现了故事 1 中人员的目标，但您已获得管理层的批准。
在谷歌的 IPv6 工作中，我们了解到这种策略非常有效。最重要的是，我们了解到它比预期的更容易且成本更低。8
故事 3：“一件事情”
这个故事涉及一种战略方法，其中组织选择了一个应用程序——它的“一件事情”——并集中精力将其迁移到 IPv6。 同样，专注对管理层很有吸引力，并且仍然触及了我们的小鸡 Little 请求的许多升级。
康卡斯特在 2008 年谷歌 IPv6 研讨会上展示了一个成功案例6，演示了它如何选择一件战略要事来升级：机顶盒管理基础设施。每个机顶盒都需要一个 IP 地址，以便管理系统可以访问它。这比康卡斯特可以合理分配到的 IPv4 地址要多得多。相反，它使用了 IPv6。如果您从康卡斯特获得互联网服务，则您电视机上的机顶盒是 IPv6，即使它旁边的电缆调制解调器提供 IPv4 互联网服务也是如此。7 康卡斯特必须让 IPv6 能够用于任何涉及管理其网络的事物：配置、测试、监控、计费。等等，计费？嗯，如果您接触计费系统，您基本上会接触到很多东西。哦，闪亮的依赖项。（这就是为什么我们用引号将“一件事情”括起来的原因。）故事 1 中的人一定很嫉妒。
在同一次研讨会上，诺基亚也展示了一个成功案例，该案例也涉及找到“一件事情”，结果证明是功耗。你说功耗？是的。它的手机通过发送 ping 来保持 NAT（网络地址转换）会话处于活动状态，从而浪费电池电量。通过切换到 IPv6，诺基亚不需要发送 ping——没有 NAT，无需保持 NAT 会话处于活动状态。它的手机可以关闭天线，直到它们有数据要发送为止。这样可以节省电量。在一个电池寿命至关重要的行业中，任何高管都能看到其价值。（谷歌 IPv6 峰会的视频详细介绍了诺基亚的成功案例5。）
从长远来看，我们应该关注将我们所有的网络和设备转换为 IPv6。然而，我们看到的模式是，成功的项目都选择了一件具体的事情来转换，并让所有的依赖项都随之而来。
总结
IPv4 地址空间已耗尽。多年来一直忽略 IPv6 的人们需要开始关注了。它是真实的——而且非常重要。IPv6 部署项目似乎揭示了两种成功的模式和一种不成功的模式。不成功的模式是尖叫天空要塌下来了，并请求许可升级“一切”。
我们学到的教训
1. 升级一切的提议听起来很疯狂，并且会被拒绝。目前，进行此类转换没有明显的商业价值。
2. 由外而内工作。执行 IPv6 到 IPv4 转换的负载均衡器将让您现在为外部客户提供 IPv6，为您提供“快速胜利”，这将支持未来的项目，并提供节流阀来控制更改的节奏。
3. 提出使用 IPv6 的高价值理由（即您的“一件事情”）最有可能获得管理层的批准。没有简单的解决方案，但有简单的解释。转换“一件事情”，并不断重复获得项目批准的价值陈述，以便每个人都理解您为什么要这样做。您在这里的成功将为其他项目铺平道路。
长期以来，IPv6 可以安全地忽略，因为它是一个“未来要求”。现在 IPv4 地址空间已耗尽，是时候认真对待这个问题了。是的，真的。
问
参考文献
1. Cerf, V., Dalal, Y., Sunshine, C. 1974. RFC 675。互联网传输控制程序规范。
2. Cerf, V., Kahn, R. E. 1974。分组网络互连协议。IEEE 通信汇刊 22(5): 637-648。
3. Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A., Ganti, V. 2010。评估 NAT444 对网络应用程序的影响。IETF 互联网草案； http://tools.ietf.org/html/draft-donley-nat444-impacts-01。
4. Doyle, J. 2009。理解运营商级 NAT； http://www.networkworld.com/community/node/44989。
5. 2008 年谷歌 IPv6 会议：IPv6、诺基亚和谷歌； http://www.youtube.com/watch?v=o5RbyK0m5OY。
6. 谷歌 IPv6 实施者会议； http://sites.google.com/site/ipv6implementors/2010/agenda。
7. Kuhne, M. 2009。IPv6 监视器：对 Alain Durand 的采访； https://labs.ripe.net/Members/mirjam/content-ipv6-monitor。
8. Marsan, C. D. 2009。谷歌：IPv6 很简单，不贵； http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html。
9. Miller, R. 2009。价值十亿美元的 HTML 标签； http://www.datacenterknowledge.com/archives/2009/06/24/the-billion-dollar-html-tag/。
10. Morr, D. 2010。T-Mobile 正在大力推进 IPv6； http://www.personal.psu.edu/dvm105/blogs/ipv6/2010/06/t-mobile-is-pushing-ipv6-hard.html。
喜欢它，讨厌它？ 让我们知道
Vinton G. Cerf 是谷歌的副总裁兼首席互联网布道师。作为“互联网之父”之一，Cerf 是互联网 TCP/IP 协议和架构的共同设计者。他拥有斯坦福大学数学学士学位和加州大学洛杉矶分校计算机科学硕士和博士学位。
Thomas A. Limoncelli 是一位作家、演讲者和系统管理员。他的著作包括系统和网络管理实践（Addison-Wesley，2007 年）和系统管理员的时间管理（O'Reilly，2005 年）。他在纽约市的谷歌工作，并在 http://EverythingSysadmin.com 上撰写博客。
© 2011 1542-7730/11/0300 $10.00
最初发表于 Queue 第 9 卷，第 3 期——
在 数字图书馆 中评论本文
更多相关文章
David Collier-Brown - 关于带宽，你一窍不通
当您的员工或客户说他们的互联网性能很差时，带宽可能不是问题所在。一旦他们拥有 50 到 100 Mbps 范围内的带宽，问题就是延迟，即 ISP 的路由器处理其流量所需的时间。如果您是 ISP 并且所有客户都讨厌您，请振作起来。这现在是一个可以解决的问题，这要归功于一群专门的人员，他们找到了这个问题，消灭了它，然后在家庭路由器中证明了他们的解决方案。
Geoffrey H. Cooper - 使用 FDO 和不受信任的安装程序模型的设备入职
设备的自动入职是处理正在安装的越来越多的“边缘”和 IoT 设备的重要技术。设备的入职与大多数设备管理功能不同，因为设备的信任从工厂和供应链转移到目标应用程序。为了加快自动入职流程，必须在设备中正式化供应链中的信任关系，以实现自动化过渡。
Brian Eaton, Jeff Stewart, Jon Tedesco, N. Cihan Tas - 通过关键路径跟踪进行分布式延迟分析
低延迟是许多谷歌应用程序（如搜索）的重要功能，延迟分析工具在维持大规模低延迟方面发挥着关键作用。对于包括功能和数据不断发展的服务的复杂分布式系统，将整体延迟保持在最低水平是一项具有挑战性的任务。在大型、真实世界的分布式系统中，现有的工具（如 RPC 遥测、CPU 性能分析和分布式跟踪）对于理解整体系统的子组件很有价值，但在实践中不足以执行端到端延迟分析。
David Crawshaw - 一切 VPN 焕然一新
VPN（虚拟专用网络）已有 24 年的历史。这个概念是为与我们今天所知的互联网截然不同的互联网而创建的。随着互联网的增长和变化，VPN 用户和应用程序也在增长和变化。在 2000 年代的互联网中，VPN 经历了尴尬的青春期，与其他广泛流行的抽象概念交互不良。在过去的十年中，互联网再次发生了变化，这个新的互联网为 VPN 提供了新的用途。一种全新的协议 WireGuard 的开发提供了一种构建这些新 VPN 的技术。
© 保留所有权利。