IPv6-精要第三版-全-

IPv6 精要第三版（全）

原文：zh.annas-archive.org/md5/d6349a4e0ffccdffdb13994c44ca5a3e

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

文特·瑟夫

互联网先驱，伍德赫斯特，2014 年 2 月

毫不夸张地说，互联网已经成为全球近三十亿人生活中不可或缺的一部分。更重要的是，互联网通过交易、信息交换和其他基于互联网的应用程序所产生的间接影响，几乎触及了每一个人。最初的互联网协议支持最多 43 亿个终端标识符（地址）。这一限制通过一种叫做网络地址转换（NAT）的机制得以扩展，该机制允许多个方使用私人地址空间，这些地址不会暴露在公共互联网中，而是转换为一个共享的、公开可路由的 IPv4 地址。IPv4 地址空间在 2011 年 2 月被互联网名称与数字地址分配机构（ICANN）用尽，留下了区域互联网注册机构来处理剩余地址空间的分配。IPv6 在 1990 年代中期被开发出来，并由互联网工程任务组（IETF）标准化。它为 340 万亿万亿个地址提供了支持。尽管其实施进展缓慢，但有两个里程碑正在推动 IPv6 的采用率加快。一个是 IPv4 地址空间的耗尽，另一个是对分配互联网地址给移动设备、机顶盒、汽车以及数十亿其他可编程设备的需求不断增长。这就是所谓的物联网。

除了满足将成为对地址空间的无尽需求外，IPv6 还具有改善互联网协议格式的特点，使处理更加简便，并且在配置便利性和流量管理等方面提供了额外的功能，以及其他一些有用的特性。读者会发现本书是一本易于接近的 IPv6 实施指南。IPv6 必须与 IPv4 在一段不确定的时间内共存，这是一个不争的事实，因此特别关注所谓的双栈实现。然而，IPv6 的彻底实施必须证明它不仅能够在混合的 IPv4/IPv6 环境中运行，还能够在纯 IPv6 环境中正常工作。

像许多指数型现象一样，IPv6 可能会让我们感到惊讶。尽管它的发展已有多年，但有迹象表明，IPv6 正在占据互联网流量的 3%。虽然这个比例看起来很小，但如果历史能提供借鉴，它将迅速增长，前提是对更大地址空间需求的增长会继续加速。

任何认真考虑在互联网相关应用和服务领域发展职业的人，都会明智地熟悉这一新协议及其功能和能力。你可以通过 Silvia Hagen 的作品抓住这个机会。

序言

本书讲述的是下一代互联网协议。我们已经熟悉了 IPv4 的优缺点；我们知道如何设计和配置它，也学会了如何排除故障。现在我们还要学习一个新协议吗？从头开始吗？其实不需要。IPv6 的设计者们从超过 15 年的 IPv4 经验中汲取了大量教训，并自 1990 年代初开始着手研发新协议。他们保留了 IPv4 的优点，将地址空间从 32 位扩展到 128 位，并添加了 IPv4 中缺失的功能。他们还开发了过渡机制，使得 IPv4 和 IPv6 能够和平共存，并确保协议间的平稳过渡。事实上，这是新协议版本开发的一个重要要求。

所以你不需要忘记你对 IPv4 的了解；许多东西在 IPv6 中会显得很熟悉。当你开始使用时，你会发现一些新特性和功能，这些将大大简化你的生活。IPv6 拥有一些 IPv4 所没有的特性，这些特性是你未来网络中所需要的。

IPv6 中的一个酷炫功能是无状态自动配置功能。我们不是一直在为 IP 地址分配而苦恼吗？DHCP 的出现让我们的生活变得更简单，但现在我们需要维护和排除 DHCP 服务器的故障。而当我们的冰箱、游泳池、暖气系统以及智能手机和电视都需要拥有 IP 地址时，我们还需要家里有 DHCP 服务器吗？不需要，使用无状态自动配置就能解决。如果你有一台支持 IPv6 的主机，你可以将它插入到网络中，它会自动配置一个有效的 IPv6 地址。ICMP（互联网控制报文协议），作为网络工程师的好帮手，随着 IPv6 变得更加强大。IPv6 的许多新特性，如无状态自动配置、优化的组播路由和组播组管理、邻居发现、路径 MTU 发现和移动 IPv6，都是基于 ICMPv6 的。

我希望这本书能帮助你熟悉这个协议，并为你提供一个易于理解的切入点，带你探索这一新领域。

读者

本书涵盖了关于 IPv6 的广泛信息，是任何希望理解或实施该协议的人的优秀资源。它对于开发应用程序的人来说也是一本不错的读物。IPv6 提供了我们在 IPv4 中没有的功能，因此可能为应用程序打开新的可能性。无论你是公司的所有者或经理，还是 IT 部门的负责人；无论你是系统或网络管理员、工程师或网络设计师；或是对 IPv6 带来的重要变化感兴趣的人，本书都会讨论经济和战略方面的内容，以及技术细节。我描述了确保 IPv6 平稳引入的互操作机制和场景。如果你是公司所有者或经理，你会对第七章和第九章最感兴趣。如果你需要规划企业网络战略，第一章、第四章、第五章、第七章和第九章将是你最关注的内容。如果你管理公司的基础设施，你尤其会对第四章和第五章感兴趣，这些章节涵盖了 ICMPv6、第二层问题和路由，还包括第七章和第九章，这些章节涉及过渡机制、互操作性和规划。如果你是系统或网络管理员，那么本书的所有章节都与您相关：它为 IPv6 的实施和与 IPv4 的集成提供了基础。

关于本书

本书详细介绍了 IPv6，解释了所有新的特性和功能。它将展示如何在当前的 IPv4 基础设施中规划、设计和集成 IPv6。

本书假定你对网络问题有较好的理解，并熟悉 IPv4。书中不涉及详细讨论 IPv4 的概念。必要时我会提到它们，但如果你想深入了解 IPv4，市场上有许多优秀的资源可供参考。你可以在附录 B 中找到书单。

本书旨在通过解释 IPv6 的所有高级功能，激发你重新思考未来的网络和服务概念，并为真正的下一代网络奠定基础。

组织结构

本书的组织方式是，熟悉 IPv4 的读者可以通过阅读第二章到第七章，轻松了解 IPv6 中的新特性。这些章节涵盖了你需要了解的内容，包括寻址、新的 IPv6 头部、ICMPv6、第二层、路由协议、DNS 和 DHCPv6、安全性、服务质量（QoS），以及使 IPv6 与 IPv4 在不同过渡阶段协同工作的过渡机制。移动 IPv6 将在第八章中讨论。第九章涉及规划过程和需要考虑的事项，并将所有技术要素整合在一起。以下是本书的章节分解：

  • 第一章，为什么选择 IPv6？，简要说明了 IPv6 的历史，并概述了新功能。它勾画了互联网和服务演进的宏大图景，展示了 IPv6 的大地址空间和先进功能在不同方面的需求。接着讨论了阻碍人们探索和集成该协议的最常见误解。最后，解释了何时是启动 IPv6 项目并推动集成的合适时机。

  • 第二章，IPv6 寻址，解释了你需要了解的关于新地址架构、地址格式、地址表示法、地址类型、国际注册服务和前缀分配的所有内容。

  • 第三章，IPv6 协议的结构，描述了新的 IPv6 头部格式，并讨论了每个字段以及跟踪文件示例。还介绍了扩展头部是什么、已定义的扩展头部类型以及如何使用它们。

  • 第四章，ICMPv6，描述了新的 ICMPv6 消息格式、ICMPv6 错误消息和信息消息，以及跟踪文件中的 ICMPv6 头部。本章还讨论了基于 ICMPv6 的扩展功能，如邻居发现、自动配置、路径 MTU 发现和多播侦听器发现（MLD）。你将学习 ICMPv6 如何使管理员的工作变得更加轻松。

  • 第五章，网络，涵盖了多个与网络相关的方面和服务，例如 IPv6 的第二层支持、上层协议和校验和、所有多播相关主题的概述、路由协议概述、服务质量（QoS）、DHCPv6 和 DNS。

  • 第六章，IPv6 安全性，从简要讨论基本安全概念和需求开始。然后介绍 IPsec 框架、IPv6 中可用于身份验证和加密的安全元素，以及如何使用它们。我们的未来网络将需要新的安全架构。本章提供了在定义 IPv6 安全概念时需要考虑的事项概述。

  • 第七章，过渡技术，讨论了已定义的不同过渡机制，如双栈操作和不同的隧道及翻译技术。它还展示了如何使用和组合这些技术，以确保和平共存和平稳过渡。这是你规划高效且节省成本的过渡工具包。

  • 第八章，移动 IPv6，介绍了移动 IPv6。本章解释了为什么这项技术可能成为新一代移动服务的基础。它还展示了 IPv6 的扩展头部支持如何提供 IPv4 无法实现的功能。

  • 第九章，IPv6 规划，将所有内容汇总成一个大局面。它讨论了规划过程、成功标准、集成场景、最佳实践，并根据我长期的咨询经验总结了该做与不该做的事项。

  • 附录 A，包括对 RFC 过程和相关机构的简短介绍，并提供了与 IPv6 相关的 RFC 列表。

  • 附录 B，提供了我推荐的书籍列表。

注意

一些重要的主题和信息在书中出现多次。这不是因为我想让你感到无聊，而是因为我假设大多数读者不会从第一页读到最后一页，而是根据兴趣选择章节和部分。因此，如果信息在不同部分和上下文中都很重要，我可能会再次提到它。

本书中使用的约定

本书中使用了以下排版约定：

斜体

表示新术语、网址、电子邮件地址、文件名和文件扩展名。

常量宽度

用于程序列表展示，以及在段落中引用程序元素，如变量名、函数名、数据库、数据类型、环境变量、语句和关键字。

常量宽度粗体

显示用户应按字面输入的命令或其他文本。

常量宽度斜体

显示应由用户提供的值或由上下文决定的值所替换的文本。

提示

该元素表示一个提示或建议。

注意

该元素表示一般性说明。

警告

该元素表示警告或注意事项。

Safari® 在线图书

注意

Safari Books Online 是一个按需数字图书馆，提供来自世界顶尖技术和商业作者的专家 内容，包括书籍和视频形式。

技术专业人员、软件开发人员、网页设计师以及商业和创意专业人士使用 Safari Books Online 作为他们进行研究、解决问题、学习和认证培训的主要资源。

Safari Books Online 提供多种 产品组合 和定价方案，适用于 组织、政府机构 和 个人。订阅者可以访问成千上万本书籍、培训视频和预发布手稿，这些内容来自如 O’Reilly Media、Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que、Peachpit Press、Focal Press、Cisco Press、John Wiley & Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones & Bartlett、Course Technology 等出版商的数据库，并且这个数据库完全可以搜索。有关 Safari Books Online 的更多信息，请访问我们的网站 在线。

联系我们方式

请将有关本书的评论和问题发送给出版商：

O'Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
800-998-9938（美国或加拿大）
707-829-0515（国际或本地）
707-829-0104（传真）

本书有一个网页，我们在此列出了勘误表、示例以及任何其他信息。您可以通过以下链接访问该页面 bit.ly/ipv6-3e。

如果您对本书有评论或技术问题，请发送电子邮件至 bookquestions@oreilly.com。

有关我们的书籍、课程、会议和新闻的更多信息，请访问我们的网站 www.oreilly.com。

在 Facebook 上找到我们：facebook.com/oreilly

在 Twitter 上关注我们：twitter.com/oreillymedia

在 YouTube 上观看我们：www.youtube.com/oreillymedia

致谢

世界各地有许多人为本书做出了贡献。没有他们的帮助和意见，这本书不会变成现在的样子。

对于第一版，特别感谢 Anja Spittler（Maggy）。在 IPv6 的早期，她在我们的实验室里花费了数小时、数天和数周的时间，设置 SuSE Linux，调试 BIND 和其他服务，并编写了第一版第九章和第十二章的部分内容。我还要感谢技术编辑们，正是他们宝贵的评论、修正和澄清使得这本书变得更加完善。当我在某个话题上遇到困难并需要一些答案时，他们是我宝贵的资源。第一版的技术审阅者是 Patrick Grossetete，他曾在 Cisco 的互联网技术部门（ITD）担任产品经理；还有 Neil Cashell，他是 Novell（现为 SuSE）的一位出色的 TCP/IP 专家。同时也感谢 Brian McGehee，他多年来一直从事 IPv6 的工作，并编写了大量关于 IPv6 的课程。他为第一版进行了最终的技术编辑，并添加了许多有用的信息。我还要感谢 Cisco 瑞士分公司，特别是 René Räber，既为我们提供了更新的路由器和技术资源的访问权限，也为我在 IPv6 方面的工作提供了支持。感谢 SuSE 的伙伴们提供软件并支持我们准备好 IPv6 的 SuSE 主机；感谢微软提供软件和关于其实现的信息；感谢 Network General 提供 Sniffer Pro 软件用于跟踪文件；感谢 Bob Fink 运营 6Bone 网站；感谢 Cricket Liu 解答我的 DNS 问题；感谢 Peter Bieringer 运营一个很棒的互联网资源网站，并以闪电般的速度回答我的问题。

第二版有许多额外的支持者、作者和审阅者，他们包括：来自惠普的 Jim Bound，IPv6 论坛的首席技术官以及 NAv6TF 的主席；IPv6 论坛主席 Latif Ladid；南安普顿大学电子与计算机科学系的 Tim Chown；以及来自 McAfee 的 Vijayabhaskar。来自 Seattle 的 Native6 公司，Yurie Rich、John Spence 和 Mike Owen 对第二版的第一章、第五章、第六章和第十章提供了重要意见。Robin Shepherd 集团的 Gene Cronk 对第五章和第十章提供了重要建议，北美 IPv6 工作组和中大西洋 IPv6 工作组主席 John Jason Brzozowski 对第一章和第九章做出了重要贡献。感谢 SRI 国际的 David B. Green，感谢他授权引用他在第五章中展示的《企业安全模型》演示文稿，并审阅了书中的不同部分。感谢 Double Shot Security 的首席网络安全架构师 Merike Kaeo 对第五章提出的所有意见和评论。感谢微软的 Chris Engdahl 审阅第十章。感谢 Sunny Connection 的 Jimmy Ott 研究并撰写了第十二章的所有更新内容。伴随书籍《IPv6 网络管理》的作者 David Malone 审阅了整本书——感谢你，David，提供的宝贵且具有启发性的评论。非常感谢所有愿意与我分享经验并提供案例研究的人们，他们分别是：来自波尔图大学的 Paolo Vieira，来自斯特拉斯堡大学的 Pierre David，来自 NTT Communications 的 Cody Christman，以及来自苏黎世 Cyberlink AG 的 Flavio Curti 和 Ueli Heuer。来自 IABG 德国的 Wolfgang Fritsche 和来自爱立信 AB 的 Karim El-Malki 审阅并提供了关于移动性的第八章的意见。感谢 Checkpoint 的工作人员提供信息和联系，特别是 Patrik Honegger 和 Yoni Appel；也感谢 Juniper 的 Jean-Marc Uzé提供的信息和联系。我还要感谢所有国际工作组中的人员和开发者，没有他们的远见卓识、热情和不懈努力，我们就无法实现 IPv6 的准备工作。

我想特别纪念Jim Bound，他在第二版的致谢中有提到。他多年来是 IPv6 的关键开发者和推动者。他曾是国际 IPv6 论坛的首席技术官（CTO）以及 IETF（互联网工程任务组）IP 下一代委员会的成员。如果没有他的推动、知识和热情，IPv6 也不会有今天的成就。不幸的是，Jim 在 2009 年以 58 岁的年龄过早离世。为了纪念 Jim，国际 IPv6 论坛创建了Jim Bound 奖，该奖项授予在 IPv6 部署方面具有世界领导力的国家。我有幸获得了第一个 Jim Bound 奖，代表瑞士 IPv6 委员会，瑞士是世界上第一个在 2013 年 4 月达到双位数 IPv6 用户渗透率的国家。

对于这第三版，我很高兴能有许多伟大且知识渊博的帮助者。

首先，我要感谢我的三位主要审阅者，他们审阅了所有章节。他们是 Ed Horley、David Malone 和 Niall Murphy。感谢你们的宝贵意见、思考和启发，也感谢你们抽出时间来做这些工作并回答我的问题。Ed Horley 还是《Microsoft 管理员实用 IPv6》的作者，这本书是所有处理 Microsoft 操作系统的人的必读书籍。我还要感谢 Mark Townsley、Cameron Byrne 和 Jan Zorz，他们审阅并为第七章和第九章提供了重要意见，Chip Popoviciu 撰写了 MPLS 部分，Gerd Pflüger 撰写了 LISP 部分，Eric Vyncke 提供了他的意见并审阅了 第六章。我还要感谢我的网络分析大师和 IPv6 培训师 Jasper Bongertz，他帮助改善了 Wireshark 的界面，Uwe Lenz，我的第二位 IPv6 教练。他为我的动手实验课创建了一个很棒的实验室，并用它为本书制作了各种跟踪文件。感谢 Andrew Yourtchenko 和 Gert Döring 回答我提出的许多问题，以及 Jeff Carrell 就 SLAAC 的内部工作机制和我们在跟踪文件中看到的细微差别与我展开了许多有趣的讨论。我还要感谢 Bea Leonhardt，在我写书时管理我的办公室并帮助更新 RFC 列表。还要感谢 Robin Huber，他是一个热情的 IT 人员，帮助我解决基础设施问题，处理我的电脑问题，负责我们 IPv6 会议的后勤工作，并且时刻更新我关于最新游戏设备的信息。最后但同样重要的是，感谢 Latif Ladid，感谢他为 IPv6 社区所做的一切持续贡献，感谢他在我周末工作时给我鼓励，感谢他让 Vint Cerf 为本书的前言提供支持。

还有所有在 O'Reilly 的伟大人物：对于第一版，特别感谢吉姆·萨姆瑟（Jim Sumser）、迈克·卢基德斯（Mike Loukides）和塔蒂安娜·阿潘迪（Tatiana Apandi）。吉姆·萨姆瑟以极大的热情、耐心和经验引导我完成了第一版的整个写作过程。谢谢你，吉姆，感谢你在我已经在挣扎时依然陪伴在我身边，感谢你从未催促我。你真的起到了关键作用！迈克和塔蒂安娜是我在第二版中合作的伙伴，他们在整个过程中也给予了我很大的支持。我还想感谢所有在 O'Reilly 为这本书做出贡献的其他人，特别是蒂姆·欧赖利（Tim O'Reilly），是他让这一切成为可能。对于第三版，我主要是与梅根·布兰切特（Meghan Blanchette）一起合作。梅根，感谢你所做的所有出色工作，感谢你的支持、幽默和在我疯狂的日程安排下对我的耐心。每当我向你求助时，你总是及时出现，帮助我保持进度。

另一个特别的感谢送给汉斯彼得·比特勒（Hanspeter Bütler），他曾是我在学校时的老师，感谢他教我古希腊语言的美妙。他那富有洞察力和敏感的方式引导我理解并感受古老语言的丰富性，为我对语言的一般理解、对不同文化的认识以及不同视角如何通过语言表达的理解奠定了基础。我或许可以部分归功于他，才使我成为了一名作家。语言是用来沟通的，越精确地使用我们的语言，我们就越能理解和被理解。没有沟通，就没有理解。在另一个层面上，TCP/IP 是网络中实现沟通的协议，从而为互联网通信奠定了基础。而互联网为全球沟通创造了物理基础。它为跨越所有文化进行全球交流、分享和理解提供了一个伟大的机会。这就是我们应该如何使用它。

第一章：为什么选择 IPv6？

当前在网络和互联网中使用的 IP 版本是 IPv4（IP 版本 4）。IPv4 于 70 年代初期开发，目的是促进美国政府研究人员和学者之间的通信与信息共享。当时，该系统是封闭的，访问点数量有限，因此开发人员并未考虑安全性或服务质量等需求。值得称赞的是，IPv4 已经存在了 30 多年，并且成为了互联网革命的核心部分。但即便是最巧妙设计的系统也会随着时间的推移逐渐过时，IPv4 也不例外。如今的网络需求远远超出了支持网页和电子邮件的范围。网络设备多样性和移动通信的爆炸性增长，以及网络技术、新服务和社交网络的全球普及，已经压垮了 IPv4，促使了下一代互联网协议的发展。

IPv6 的开发基于我们在开发和使用 IPv4 中的丰富经验。已经验证并建立的机制得以保留，已知的局限性被舍弃，扩展性和灵活性得到了增强。IPv6 是一个旨在应对互联网增长速度、满足服务、移动性和端到端安全性等严格要求的协议。

当互联网在 1983 年一天之内从使用网络控制协议（NCP）切换到互联网协议（IP）时，IP 并不是我们今天所熟悉的成熟协议。许多广为人知且常用的扩展是在随后的几年里为了满足互联网日益增长的需求而开发的。相比之下，硬件厂商和操作系统供应商自 1995 年 IPv6 成为草案标准以来就已经支持 IPv6。在此后的十年里，这些实现已经成熟，IPv6 的支持不仅限于基础网络设施，还将继续扩展。

对组织来说，尽早关注 IPv6 的引入非常重要，因为从长远来看，IPv6 的使用是不可避免的。如果将 IPv6 纳入战略规划；如果组织提前考虑可能的整合场景；如果在投资 IT 资本支出时考虑到其引入，组织就能节省可观的成本，并能在需要时更高效地启用 IPv6。

关于互联网历史的有趣且幽默的概述可以在 RFC 2235《霍布斯互联网时间线》中找到。该记载从 1957 年开始，讲述了苏联发射斯普特尼克卫星和美国国防部（DoD）成立高级研究计划局（ARPA）的事件。RFC 中还列出了互联网主机、网络和域名注册的年度增长率。

以下是来自 RFC 的一些摘录：

  • 1969 年：史蒂夫·克罗克（Steve Crocker）提出了第一个《评论请求》（RFC 1）：“主机软件”。

  • 1970 年：ARPANET 主机开始使用网络控制协议（NCP）。

  • 1971 年：23 台主机连接到 ARPANET（UCLA、SRI、UCSB、犹他大学、BBN、MIT、RAND、SDC、哈佛、林肯实验室、斯坦福、UIU©、CWRU、CMU、NASA/Ames）。

  • 1972 年：成立了互联网工作组（INWG），由文顿·瑟夫（Vinton Cerf）担任主席，旨在解决制定统一协议的需求。Telnet 规范（RFC 318）发布。

  • 1973 年：与 ARPANET 的首次国际连接在伦敦大学（英国）和皇家雷达研究所（挪威）完成。鲍勃·梅特卡夫（Bob Metcalfe）的哈佛博士论文概述了以太网的构想。文件传输规范（RFC 454）发布。

  • 1976 年：伊丽莎白二世女王发送了一封电子邮件。

  • 1981 年：法国电信公司在法国部署了 Minitel（Teletel）。

  • 1983 年：1 月 1 日，从 NCP 到 TCP/IP 的切换完成。

  • 1984 年：主机数量突破 1,000。

  • 1987 年：使用 CSNET 协议在德国和中国之间建立了电子邮件连接，第一封来自中国的邮件于 9 月 20 日发送。第 1000 号 RFC 发布。主机数量突破 10,000。

  • 1988 年：一只互联网蠕虫通过网络传播，影响了 60,000 台主机中的 10%。

  • 1989 年：主机数量突破 100,000。克利福德·斯托尔（Clifford Stoll）写下了《布谷鸟的蛋》一书，讲述了一群德国黑客渗透美国多个设施的真实故事。

  • 1991 年：万维网（WWW）由蒂姆·伯纳斯-李（Tim Berners-Lee）开发，并由 CERN 发布。

  • 1992 年：主机数量突破 1,000,000。世界银行上线。

  • 1993 年：白宫在比尔·克林顿总统任期内上线。新型蠕虫开始在网络中传播——WWW 蠕虫（W4）与蜘蛛、流浪者、爬虫和蛇一起登场。

  • 1994 年：互联网购物被引入；第一封垃圾邮件被发送；必胜客上线。

  • 1995 年：梵蒂冈上线。域名注册不再免费。

  • 1996 年：9,272 个组织因未支付域名费用，被 InterNIC 取消了其名称服务，结果未能列入名单。

  • 1997 年：第 2,000 号 RFC 发布。

RFC 的历史发展到此为止。但历史仍在继续。根据www.internetworldstats.com/emarketing.htm，全球在线用户在 2000 年达到了 3.61 亿（渗透率为 5.8%），2002 年达到了 5.87 亿。2003 年，美国国防部宣布将于 2008 年前将国防部网络迁移到 IPv6，并启动了Moonv6 项目（现已结束）。2005 年，谷歌注册了一个/32 的 IPv6 前缀，互联网之父 Vint Cerf 加入了谷歌。到那时，互联网用户数量已达 10.8 亿。到 2014 年写作时，全球互联网用户数量约为 24 亿，渗透率为 34%。

因此，尽管这些数字反映了所有互联网用户，无论 IP 协议版本如何，但现在我们开始看到 IPv6 互联网的增长。它仍处于初期阶段，但根据过去两年的增长数据，我们预计增长将呈指数级，并且可能比我们当中的热衷者预期的还要快。IPv6 互联网的增长可以在Google IPv6 采纳统计数据中看到，2014 年春季的统计数据如图 1-1 所示。

统计数据显示，在 2011 年初（当 IANA 的 IPv4 池用尽时），原生 IPv6 互联网用户的比例约为 0.2%。统计数据显示，非原生 IPv6 的用户（例如 6to4 或 Teredo，红线）的比例已降至几乎为零，并且从那时起变得微不足道。在一年内，IPv6 互联网用户的数量翻了一番，达到了 0.4%——虽然是一个小数字，但仍然是增长。到 2013 年 1 月，IPv6 互联网的用户已经突破了 1%的大关，我们进入了 2014 年，IPv6 互联网用户接近 3%，大约为 7200 万用户。在交付本章时，即 2014 年 4 月，我们达到了 3.5%。目前，IPv6 互联网用户的数量大约每九个月翻一番。

这些只是互联网历史中的一些精选事件和里程碑。继续关注，更多的历史将继续展开。我们大家都在共同创造这段历史。

2014 年春季 Google 全球 IPv6 采纳统计数据图 1-1. 2014 年春季 Google 全球 IPv6 采纳统计数据

IPv6 的历史

互联网工程任务组（IETF）在 1990 年代初开始着手开发 IPv4 的继任协议。为了解决预见到的地址空间限制并提供额外的功能，多个平行的努力同时展开。IETF 于 1993 年启动了互联网协议下一代（或IPng）领域，旨在研究不同的提案并为进一步的程序提供建议。

IETF 的 IPng 领域负责人在 1994 年的多伦多 IETF 会议上推荐创建 IPv6。他们的建议在 RFC 1752 中有所规定，“IP 下一代协议的推荐”。这些负责人组建了一个地址生命周期期望（ALE）工作组，旨在确定 IPv4 的预期生命周期是否足够支持开发具有新功能的协议，或者剩余时间是否仅足以开发一个地址空间解决方案。1994 年，ALE 工作组预计，根据现有统计数据，IPv4 地址耗尽将发生在 2005 年至 2011 年之间。

对于那些对不同提案感兴趣的人，这里有一些关于过程的更多信息（来自 RFC 1752）。主要有四个提案：CNAT、IP Encaps、Nimrod 和 Simple CLNP。随后又有三个提案：P Internet Protocol (PIP)、Simple Internet Protocol (SIP) 和 TP/IX。1992 年 3 月的圣地亚哥 IETF 会议后，Simple CLNP 发展成了带有更大地址的 TCP 和 UDP（TUBA），而 IP Encaps 变成了 IP 地址封装（IPAE）。IPAE 与 PIP 和 SIP 合并，并自称为 Simple Internet Protocol Plus (SIPP)。TP/IX 工作组更名为互联网通用架构（CATNIP）。现在的主要提案是 CATNIP、TUBA 和 SIPP。关于这些提案的简短讨论，请参阅 RFC 1752。

注意

CATNIP 在 RFC 1707 中有规范；TUBA 在 RFC 1347、1526 和 1561 中有规范；SIPP 在 RFC 1710 中有规范。

互联网工程指导小组（IESG）于 1994 年 11 月 17 日批准了 IPv6 的建议，并草拟了一个提议标准。RFC 1883，《互联网协议，第六版（IPv6）规范》，于 1995 年发布。IPv6 的核心协议集于 1998 年 8 月 10 日成为 IETF 草案标准。此标准包括 RFC 2460，废除了 RFC 1883。

注意

为什么新协议不叫 IPv5？版本号 5 无法使用，因为它已经被分配给了实验流协议。

IPv6 的一个重大挑战，同时也是主要机遇之一，就是我们可以重新设计网络以适应未来。这是企业在规划 IPv6 集成时应最关注的，确保他们不仅仅是将旧有的概念复制到新协议上。我们必须重新思考我们的架构。这一千载难逢的机会可以用来摆脱许多遗留问题。一份有趣的 RFC 有助于在这一过程中看到全局，那就是 RFC 6250，《IP 模型的演变》。它展示了在多年运营网络的过程中，这一模型发生了多大的变化。因此，它有助于解放我们的思维，以便从新的角度思考。以下是一个有趣的小引述，能体现我所说的内容。

在这份 RFC 中提到了第一个 IP 模型和寻址架构，并引用了 RFC 791，该文档定义了 IPv4 和 IPv4 地址：

地址长度固定为四个字节（32 位）。地址以一个字节的网络号开始，后跟三个字节的本地地址。这个三字节字段被称为“剩余”字段。

这就是我们走到的地步。现在，考虑到 IPv6 广阔的地址空间，将这一点展望到未来。如何有意义地利用新的地址架构和巨大的空间，将书写 IP 模型演变的下一个篇章。

注意

这里是 Vint Cerf 的一句引述：

广阔的 IPv6 地址空间为重新审视地址的概念提供了巨大机会。IETF 仅为当前使用分配了 IPv6 地址空间的 1/8。剩余的 7/8 地址空间仍待分配。因此，我们可能能够以不同于拓扑端点的方式解释 IP 地址空间的新段。这正是当前互联网发展过程中，关注 IPv6 未来的重要原因。

IPv6 有什么新特点？

IPv6 是 IPv4 的演进。该协议作为软件升级在大多数设备和操作系统中安装。如果你购买的是最新的硬件和操作系统，IPv6 通常会得到支持，只需激活或配置。在许多情况下，它默认是激活的。目前可用的过渡机制允许逐步引入 IPv6，而不会危及当前的 IPv4 基础设施。

以下是主要变化的概述：

扩展的地址空间

地址格式从 32 位扩展到 128 位。这为地球上每一粒沙子提供了多个 IP 地址。此外，它还允许在地址空间中进行层次化结构，从而优化全球路由。

自动配置

也许 IPv6 最吸引人的新特性是其无状态地址自动配置（SLAAC）机制。当一个设备在 IPv6 环境中启动并请求其网络前缀时，它可以从其连接上的 IPv6 路由器获取一个或多个网络前缀。通过这些前缀信息，设备可以使用其 MAC 标识符或一个私有随机数来自动配置一个或多个有效的全球 IP 地址，从而构建一个唯一的 IP 地址。在 IPv4 环境中，我们必须为每个设备分配唯一的 IP 地址，通常是通过手动配置或使用 DHCP。SLAAC 应当能简化网络管理员的工作，并大幅节省维护 IP 网络的成本。此外，假设将来在家中需要 IP 地址的设备数量不断增加，这一特性将变得不可或缺。想象一下，当你购买一台新电视时，必须重新配置家里的 DHCP 服务器！无状态地址自动配置还使得移动设备（例如智能手机）在切换到外国网络时能够轻松连接。

头部格式简化

IPv6 头部比 IPv4 头部简单得多，其固定长度为 40 字节。这允许更快的处理。它基本上包含了两组 16 字节的源地址和目标地址，并且只有 8 字节用于一般的头部信息。

增强的选项和扩展支持

IPv4 将在基本头部中集成选项，而 IPv6 则在所谓的扩展头部中携带选项，只有在需要时才插入这些选项。再次，这允许更快地处理数据包。基本规范描述了一组六个扩展头部，包括路由、服务质量和安全头部。

为什么我们需要 IPv6？

出于历史原因，美国的组织和政府机构使用了大部分可分配的 IPv4 地址空间。世界其他地区必须共享剩余的部分。有些组织曾拥有比整个亚洲还多的 IPv4 地址空间（亚洲拥有超过 50%世界人口）。这也解释了为什么 IPv6 在亚洲的部署比在欧洲和美国要普遍得多。

注意

一个有趣的统计资源网站可以通过以下链接访问：www.internetworldstats.com/stats.htm。

IPv4 地址空间的理论上限为 43 亿个地址。然而，早期的分配方法效率低下。结果，一些组织获得了远超其需求的地址块，而本可以在其他地方使用的地址如今已不可用。如果可以重新分配 IPv4 地址空间，它将能更有效地使用，但这一过程是不可行的，全球重新分配和重新编号也是不现实的。除此之外，这样做也没多大意义，因为即使是 43 亿个地址，在当前的增长速度下也很快就不够用了。我们必须考虑到未来我们将需要为数十亿的设备分配 IP 地址。各行各业的厂商都在开发基于 IP 的监控、控制和管理系统。

正如前一节所示，IPv6 工作组做的远不止扩展地址空间。对于当今及未来的许多复杂网络，以及各种类型 IP 设备的数量，IPv6 的自动配置功能将成为必要。传统的地址分配方法无法管理这些服务，无状态地址自动配置也将帮助减少组织的管理成本。

扩展的地址空间以及恢复互联网原始的端到端模型，使得可以消除网络地址转换（NAT）。在 NAT 中，一个或少数几个公共 IPv4 地址用于通过将内部地址映射到公共地址，连接大量使用私有地址的用户到互联网。NAT 是作为解决 IPv4 地址空间限制的短期修复方案引入的，因为 IPv6 当时尚未准备好（参见 RFC 1631；原始的 NAT 规范在 2001 年被 RFC 3022 废止）。NAT 在 IPv4 网络中变得非常常见，但它们在管理和操作中带来了严重的缺点：为了进行地址映射，NAT 会修改 IP 头中的终端节点地址。通常，应用层网关（ALG）会与 NAT 一起使用，以提供应用层透明性。有一长串协议和应用程序在 NAT 环境中使用时会出现问题，IPsec 和对等应用程序就是两个著名的例子。NAT 的另一个已知问题是在合并网络时私有地址空间的重叠，这需要对其中一个网络进行重新编号或创建复杂的地址映射方案。NAT 的主要优点——扩大有限的地址空间，在 IPv6 中不再需要，因此设计上不予支持。

通过引入更灵活的头部结构（扩展头部），该协议被设计为开放且可扩展的。未来，可以轻松地定义并集成新的扩展到协议集中。基于 IPv4 已经使用近 30 年的事实，IPv6 的开发是基于对 IPv4 的经验，并着重于创建一个可扩展的基础；你可以期待它能够持续很长时间。

许多国家的宽带普及率继续加速，在某些情况下，已达到 65%或更高。这种“始终在线”且带宽容量可观的连接方式意味着设备连接的机会更大。而且许多消费电子产品制造商已经抓住了这一机会。在线游戏不再是 PC 游戏的专利。游戏主机，如索尼的 PlayStation 4、Xbox One 或任天堂 Wii U，都已经增加了在线功能。许多电信运营商也在其 IP 网络上提供电视类服务（电影、音频内容等）。甚至家电产品，如冰箱、炉子、热水器和浴缸等，也开始联网。虽然将浴缸联网看起来有些荒谬，但许多此类设备被联网的目的是为了实现电力管理、远程控制、故障排除，以及远程监控/监测等功能。我们正步入智能建筑和智能城市的时代。这个网络化过程的最终结果是需要进行寻址的设备数量大增，其中许多设备将不具备标准的用户界面。在这些情况下，IPv6 地址空间结合邻居发现、无状态自动配置和移动 IPv6 等特性，将帮助迎来家庭计算机化的新时代，但希望能够避免当前协议部署所带来的巨大头痛。

无线行业（包括蜂窝网络和无线网络）的增长可谓是现象级的。在越来越多的国家，手机数量实际上超过了人口数量。在这个持续可达、随时能够获取信息的世界中，终端用户对移动性的需求变得尤为重要。从运营商的角度来看，特别是那些支持多种媒体接入类型（例如 3G、WiMax、LTE）的运营商，利用 IP 作为传输和路由数据包的方式是有道理的。智能手机上网、与其他用户玩游戏、打电话，甚至播放视频内容。与其使用不同的传输协议支持所有这些功能并创建中介应用来促进通信，不如更高效地利用现有的互联网和公司网络基础设施。我们稍后会看到，从技术角度来看，移动 IPv6 的设计非常优雅，能够高效地支持移动用户，并提供覆盖机制，使用户在不同网络之间移动时保持连接，即使这些网络使用的媒体接入类型不同。

关于 IPv6 对企业的价值仍然存在一些疑问，值得承认的是，每个组织都需要评估 IPv6 对其内部使用的好处和最佳时机。在许多情况下，组织可以找到巧妙的方法，利用 IPv6 解决“痛点”问题，而不必迁移整个网络。采用可以逐步进行，制定一个最小化集成难题的计划，并确保当需要“切换开关”时，一切都已准备就绪。正如许多案例研究所示，经过精心规划的引入成本比预期要低得多；节省成本的主要因素是提前规划使你能够使用所有的更新周期，从而最大限度地减少成本。逐步引入使你能够边学边做，从而节省大量资金和麻烦，并且可以在不影响现有 IPv4 基础设施的情况下进行。

但在考虑了所有这些思考和顾虑后，我们也不能忘记 IPv6 最根本的优势。通过其新的结构和扩展，IPv6 为新一代服务提供了基础。未来市场上将会出现一些无法用 IPv4 开发的设备和服务。这为厂商和服务提供商带来了新的市场和商业机会。先行者的机会是巨大的，延长当前产品生命周期的机会也同样可观，因为可以通过将技术与 IPv6 结合来刷新产品。另一方面，这意味着组织和用户在中期将需要此类服务。因此，建议通过逐步而非破坏性的方式小心地集成新协议，为这些新服务做好基础设施准备。这可以避免在没有充分规划的情况下，以不合理的高成本引入基于 IPv6 的业务关键应用。

常见误解

考虑到所有这些优势，或许应该问的是：“为什么不选择 IPv6？”与客户交流时，我们经常发现他们有一套类似的误解，阻止他们考虑 IPv6。以下是最常见的误解：

“引入 IPv6 会使我们现有的 IP 基础设施——我们的网络和服务——面临风险。”

这种担忧没有依据。IPv6 发展的一个主要焦点是创建允许两种协议和平共存的集成机制。你可以将 IPv6 与 IPv4 一起使用，也可以独立使用 IPv6。可以在引入 IPv6 的同时使用它来访问新的服务，同时保留 IPv4 来访问传统服务。这不仅确保了不间断地访问 IPv4 服务，而且还允许逐步引入 IPv6。我在第七章中讨论了这些机制。你最大的风险是不利用 IPv6 所提供的所有机会。只有在有时间的情况下进行规划，你才能利用这些机会。

“IPv6 协议还不成熟，尚未证明它能够经得起时间的考验，或者它是否能够满足需求。”

这是 2006 年我们发布本书第二版时，许多人关心的问题。而到了 2014 年，这种说法已不再成立。许多 ISP 和组织正在部署 IPv6，厂商也在加快步伐，工作组已经开发并优化了有助于集成的机制。没有技术上的理由不使用 IPv6。

“引入 IPv6 的成本太高。”

采用 IPv6 肯定会有一些成本。在许多情况下，较新的网络会发现它们现有基础设施中对 IPv6 的支持实际上已经很高。不管怎样，过渡过程中将需要一些硬件和软件的投入。组织需要创建新的设计，审查当前的概念，培训 IT 人员，可能还需要寻求外部专家的帮助，以便充分利用 IPv6。

然而，IPv6 带来的成本节约已经变得越来越容易定义。基于 IPv4 的网络变得越来越复杂。新的 IT 服务，如 VoIP、即时消息、视频会议、IPTV 和统一通信，增加了中间件层和复杂性。正在合并的组织或进行 B2B 交易的公司正在实施具有高管理成本且难以排查故障的 NAT 重叠解决方案。而且，日益增长的移动设备和网络设备市场需要强大的访问模型，而这些模型在 IPv4 环境中既昂贵又难以实现。在所有这些情况下，IPv6 从长远来看提供了比 IPv4 更简洁且具有成本效益的模型。事实上，投资 IPv4 就是投资一个即将淘汰的技术，而投资 IPv6 则是在投资未来的技术。

“通过无状态地址自动配置（Stateless Address Autoconfiguration），我们将无法控制或监控网络访问。”

虽然对于广泛使用无状态地址自动配置的网络，这种说法通常是正确的，但管理员将有选择其控制级别的权利。根据 RFC 3315 定义的 DHCPv6 已经扩展以支持两种常见的操作模式：有状态和无状态。有状态模式是当前使用 DHCP（用于 IPv4）的用户熟悉的模式，其中一个节点（DHCP 客户端）动态地从 DHCP 服务器请求 IP 地址和配置选项。DHCPv6 还提供了无状态模式，在这种模式下，DHCPv6 客户端只是从 DHCPv6 服务器请求配置选项，并通过其他方式，如无状态地址自动配置，来获取 IPv6 地址。

“我们的互联网服务提供商（ISP）不提供 IPv6 服务，因此我们无法使用它。”

你不必等待你的 ISP 在公司或私人网络中启用 IPv6。如果你想连接到全球 IPv6 网络，可以使用过渡机制之一，通过 ISP 的 IPv4 基础设施传输你的 IPv6 数据包。这对于较小的组织来说是可行的。另一方面，在 2014 年写作时，你可以期望大型 ISP 面向企业客户时会支持 IPv6。这应该成为你在任何合同续签和服务水平协议（SLA）中的标准要求。如果你的 ISP 不提供 IPv6 服务，考虑更换服务提供商。

“升级我们的骨干网络将会太昂贵且复杂。”

过渡机制使得在适当的情况下可以使用 IPv6，而无需规定升级顺序。通常对于骨干网络，建议等待常规生命周期，当硬件需要更换时再进行升级。确保选择支持性能 IPv6 路由的硬件。与此同时，你可以通过 IPv4 骨干网络隧道传输你的 IPv6 数据包。使用 MPLS 的网络可以轻松地通过其 IPv4 MPLS 骨干网络隧道传输 IPv6 数据包。你可以在第七章中了解更多内容。越来越多的组织开始考虑在下一个更新或重新设计周期中将其骨干网和数据中心迁移到仅支持 IPv6，因为这能显著降低运营成本。在这种情况下，我们将开始通过 IPv6 骨干网隧道传输 IPv4 数据包。IPv4 作为一种服务是新的关键词。

“将所有应用程序迁移到 IPv6 会太复杂且成本过高。”

将应用程序迁移到 IPv6 上运行所需的工作量通常远低于预期。如果应用程序编写得很好，它可能只需通过 IPv6 就能正常运行，而无需修改。不要假设它无法工作，测试一下就知道了。对于需要修改但尚不可用的应用程序，或者对于那些迁移没有意义的应用程序，有可用的机制可以支持 IPv4 应用程序在 IPv6 网络中运行，或者支持 IPv6 应用程序在 IPv4 网络中运行。另一种选择是运行双栈网络，在这种网络中，你可以使用 IPv4 访问 IPv4 应用程序，使用 IPv6 访问 IPv6 应用程序。无论如何，建议企业客户尽早开始规划，并为应用团队提供良好的实验环境，让他们在没有时间压力的情况下测试应用程序。

“我们有足够的 IPv4 地址；我们不需要 IPv6。”

这是真的——如果你有足够的 IPv4 地址，今天可能没有迫切需要集成 IPv6。但出于这个原因忽略 IPv6 是一种假设，认为你的网络完全与外界隔离，包括你的供应商、合作伙伴和客户。IPv6 在亚洲和欧洲的普及进展比在美国更快，因此，即使你在丹佛的运营有足够的地址空间，与你在东京的合作伙伴组织互联时，如果你不支持 IPv6，最终可能会变得复杂。此外，认为 IPv6 仅仅是关于地址空间的假设，并没有考虑到 IPv6 所带来的先进功能。

什么时候是切换到 IPv6 的时机？

2014 年的答案是现在！如果世界其他地方都迁移到 IPv6，而你仍坚持使用 IPv4，那么你将把自己排除在全球通信和可达性之外。等待太久的风险包括失去潜在客户、无法进入新市场以及无法使用基于 IPv6 的新业务应用。

IT 领域有一条黄金法则：“永远不要触碰一个正在运行的系统。”只要你的 IPv4 基础设施运行良好并满足你的需求，就没有理由更改任何东西。但从现在起，每当你投资于基础设施时，应该考虑 IPv6。对新技术的投资将使其拥有更长的生命周期，并保持网络的最前沿。

以下是一些主要的指标，表明你可能需要考虑切换或集成 IPv6：

  • 你需要扩展或修复你的 IPv4 网络或 NAT 实现。

  • 你已用尽地址空间。

  • 你想为基于 IPv6 高级功能的应用程序准备网络。

  • 你需要为大量用户提供端到端的安全性，但你没有足够的地址空间，或者你在 NAT 实现上遇到了困难。

  • 你需要更换那些已经进入生命周期末期的硬件或应用程序。确保购买支持 IPv6 的产品，即使你暂时不启用它。

  • 你希望在没有时间压力的情况下引入 IPv6。

为了充分准备 IPv6，可以采取以下措施：

  • 构建内部知识，培训 IT 员工，并创建测试网络。

  • 将 IPv6 纳入你的 IT 战略。

  • 在你有时间的情况下，设计未来-proof 的网络、安全和服务概念。

  • 根据你的网络和需求创建集成场景。

  • 在所有硬件和软件采购指南中增加对 IPv6 的支持要求。具体说明必须支持哪些特性（RFC）。不要忘记在外包和服务合同以及 SLA 中添加 IPv6 要求。

  • 强迫你的供应商为他们的产品添加 IPv6 支持。

如果你这么做，你可以决定在你的网络中引入 IPv6 的最佳时机。你也可以评估是否继续投资 IPv4 基础设施更有意义，或者引入 IPv6 会是一个更好的选择。

IPv6 不会像 1983 年从 NCP 转向 IPv4 时那样有一个“切换日”。可能也不会有杀手级应用程序，所以不要指望出现一个。或者正如一些人喜欢说的，IPv6 的杀手级应用程序就是互联网。IPv6 将逐步融入我们的网络和互联网中。根据您的需求，采取逐步实施 IPv6 的方法可能是最具成本效益的整合方式。这种方法不会使您的当前基础设施面临风险，也不会强迫您在准备好之前更换硬件或软件，它允许您熟悉该协议，进行实验，学习，并将所学整合到您的策略中。

注意

您可能希望首先在公共服务中启用 IPv6。由于 IPv4 地址的匮乏，想要扩展客户基础的 ISP（谁不想这么做呢？）使用 NAT 类型的机制来扩展其 IPv4 地址空间。这包括 CGN（运营商级 NAT），即多个客户共享一个公共 IPv4 地址，并且位于多个 NAT 层后面。

这些用户可能在访问您的 IPv4 网站时体验不佳，对于电子商务或其他更复杂的服务，甚至可能完全无法访问。用户并不知道是提供商的 CGN 导致了问题，而会把责任归咎于您的网站。如果您为网站提供双栈，这些用户可以通过 IPv6 访问您的网站，绕过 IPv4 的 NAT。

注意

在第七章的“通过 NAT 扩展 IPv4 地址空间”部分中可以找到更多关于 CGN 的信息。

IPv6 状态和供应商支持

如前所述，IPv6 已在大多数最新版本的路由和操作系统中实现。对于标准应用程序，假设 IPv6 支持已经添加或将在下一个主要版本中添加。要为您的企业网络创建 IPv6 集成计划，您需要单独评估每个供应商的 IPv6 支持状态和程度。许多供应商都有一个信息网站，通常可以在 http://www..com/ipv6 找到。

可以说，IPv6 至网络层的支持已经成熟、经过测试并得到了优化。这包括路由、过渡机制、DNS 和 DHCPv6。

在安全性、过渡机制、IPv4/IPv6 MIB 集成和移动 IPv6 等领域的开发最为活跃。在网络管理和防火墙方面仍需要更多的工作。思科（Cisco）、检查点（Checkpoint）、瞻博（Juniper）等众多供应商都在这些领域开展工作。应用领域持续发展，新的应用程序将出现在市场上，利用 IPv6 的先进功能。得益于过渡机制，您仍然可以在 IPv6 网络中使用 IPv4 应用程序。

注意

在第九章中可以找到更多关于规划过程的信息。

现在你知道为什么你应该关心 IPv6 了。书中的以下章节旨在让你愉快地学习 IPv6。所以请继续阅读。

参考文献

这是本章中提到的最重要的 RFC 列表。有时我还会包括一些额外的与主题相关的 RFC，供你进一步个人学习。

RFCs

  • RFC 1, “主机软件，”1969 年

  • RFC 791, “互联网协议，”1981 年

  • RFC 1347, “具有更大地址的 TCP 和 UDP（TUBA），”1992 年

  • RFC 1526, “TUBA/CLNP 主机的系统标识符分配，”1993 年

  • RFC 1561, “在 TUBA 环境中使用 ISO CLNP，”1993 年

  • RFC 1631, “IP 网络地址转换器（NAT），”1994 年

  • RFC 1707, “CATNIP：互联网的通用架构，”1994 年

  • RFC 1710, “简单互联网协议加白皮书，”1994 年

  • RFC 1752, “下一代 IP 协议的推荐，”1995 年

  • RFC 1883, “互联网协议，第 6 版（IPv6）规范，”1995 年

  • RFC 2235, “霍布斯互联网时间线，”1997 年

  • RFC 2324, “超文本咖啡壶控制协议（HTCPCP/1.0），”1998 年 4 月 1 日

  • RFC 2460, “互联网协议，第 6 版（IPv6）规范，”1998 年

  • RFC 2555, “30 年的 RFC，”1999 年

  • RFC 2663, “IP 网络地址转换器（NAT）术语和考虑因素，”1999 年

  • RFC 3022, “传统 IP 网络地址转换器（传统 NAT），”2001 年

  • RFC 3027, “IP 网络地址转换器的协议复杂性，”2001 年

  • RFC 4677, “IETF 的道：互联网工程任务组新手指南，”2006 年

  • RFC 5902, “IAB 关于 IPv6 网络地址转换的思考，”2010 年

  • RFC 6250, “IP 模型的演变，”2011 年

  • RFC 6269, “IP 地址共享问题，”2011 年

  • RFC 6921, “超光速（FTL）通信的设计考虑，”2013 年 4 月 1 日

  • RFC 7168, “茶叶流出设备的超文本咖啡壶控制协议（HTCPCP-TEA），”2014 年 4 月 1 日

第二章：IPv6 地址

一个 IPv4 地址有 32 位，外观看起来很熟悉。一个 IPv6 地址有 128 位，乍一看显得非常复杂。扩展地址空间是开发 IPv6 的主要原因之一，同时还包括优化路由表，尤其是在互联网上。本章将帮助你熟悉扩展的地址空间，并解释 IPv6 地址是如何工作的，以及为什么它被设计成现在这个样子。理解的不仅仅是 128 位的地址，地址架构已经得到扩展，庞大的地址空间为新的地址设计提供了机会。所以，在你开始制定 IPv6 地址规划之前，务必要深入了解这一点。IPv6 地址架构在 RFC 4291 中进行了定义。

IPv6 地址空间

IPv4 地址空间的 32 个位提供了理论上最大值为 2³²的地址，即大约 42.9 亿个地址。目前全球人口超过 70 亿。因此，即使能够完全使用 IPv4 地址空间，我们也无法为地球上的每个人分配一个 IP 地址。事实上，这个地址空间中只有很小一部分是可以使用的。在 IP 的早期阶段，没有人预见到今天我们所知的互联网的存在。因此，大量的地址块被分配时并没有考虑到全球路由和地址节约的问题。这些地址范围不能轻易回收，因此有很多未使用的地址无法分配。

注

你是否知道今天（2014 年）只有大约 24 亿人能够上网？这大约占全球人口的 34%。

关于 IPv4 地址池耗尽的激烈讨论在 2011 年 2 月 3 日当 IANA（互联网号码分配局）宣布免费池已空时画上了句号。这发生在 IPv4 地址消耗在 2010 年翻了一番之后。过去 10 年，全球平均每年消耗大约 10 个/8 地址块。到 2010 年 1 月时，仍有 24 个/8 地址块可用。所以按理说这些地址应该还能用超过两年。然而，仅仅一年后，在 2011 年 1 月，地址池就空了。这表明互联网增长的速度是多么之快。而且互联网将继续以这样的速度增长，甚至可能更快。现在，由于 IPv4 池已经耗尽，互联网的增长将在很大程度上通过 IPv6 来实现。

互联网及其服务的演进表明，在未来，我们不仅需要为用户和计算机分配地址，还需要为各种需要永久连接互联网的设备分配越来越多的地址，例如智能手机、平板电脑、网络摄像头、冰箱、汽车、输液泵、水表、电表等许多设备。以汽车制造商为例，它们正在设计未来的联网汽车，每辆车需要多个 IP 地址。我们有多少辆车呢？根据howmanyarethere.net的数据显示，2011 年全球约有 10 亿辆汽车。那么，假设每辆车需要 50 个 IP 地址……结果就出来了！这些地址将用于监控和维护，也用于访问天气、交通等服务信息。在上个十年初，曾有一款原型车，配备了集成的思科路由器和内置的移动 IPv6 实现。大多数大型汽车制造商都有类似的计划和原型。

IPv6 地址空间使用 128 位地址，这意味着我们最多可以拥有 2¹²⁸个可用地址。想知道这个数字有多大吗？它等于 340,282,366,920,938,463,463,374,607,431,768,211,456，或者换句话说，每平方米地球表面上大约有 6.65 × 10²³个地址。这个数字可以读作 340 无尽亿个地址。对于像我这样无法想象这个数字的人来说，这个数量可以比作为地球上每一粒沙子分配多个 IP 地址。IPv4 地址空间，按最初定义的地址类别（A、B、C、D、E）允许最多有 2,113,389 个网络 ID。在引入无类别域间路由（CIDR）后，这个数字稍有增加。让我们将其与 IPv6 进行比较。目前，全球单播地址（前缀为二进制 001）地址空间允许使用/48 前缀的 2⁴⁵个网络 ID，即 35,184,372,088,832 个网络。每个网络还可以利用剩余的 16 位前缀进一步划分为 65,536 个子网。

稍后，当我们深入讨论这一章并讲解地址格式时，我将给你展示一个新的对比，帮助你更好地理解这个地址空间究竟有多大。

地址类型

IPv4 支持单播、广播和组播地址。而在 IPv6 中，广播地址不再使用，取而代之的是组播地址。这是个好消息，因为广播在大多数网络中都存在问题。任播地址是一种通过 RFC 1546 引入的地址类型，虽然在 IPv4 中已经有使用，但预计在 IPv6 中会更加广泛使用。

单播、组播和任播地址

IPv6 地址可以分为三类：

单播

单播地址唯一标识一个 IPv6 节点的接口。发送到单播地址的数据包会被传送到该地址所标识的接口。

组播

多播地址用于标识一组 IPv6 接口。发送到多播地址的数据包将由多播组中的所有成员处理。

任播

任播地址分配给多个接口（通常位于多个节点上）。发送到任播地址的数据包只会送达其中一个接口，通常是最近的那个接口。

一些通用规则

IPv6 地址分配给接口的方式与 IPv4 类似，而不是像 OSI 中那样分配给节点，因此每个节点的每个接口至少需要一个单播地址。一个接口也可以分配多个类型的 IPv6 地址（单播、多播和任播）。因此，节点可以通过其任何接口的地址来标识自己。出于负载共享的原因，也可以将一个单播地址分配给多个接口，但如果这样做，需要确保硬件和驱动程序支持此功能。

注意

在 IPv6 中，所有的零和一都是合法的地址字段值。

IPv6 支持不同作用域的地址。存在全局作用域和非全局作用域（例如链路本地）。在操作上，使用非全局地址的概念通过使用私有范围内的 IP 地址或管理作用域的多播地址引入了 IPv4。IPv6 的设计在基础架构中包含了地址作用域。除了未指定地址外的每个 IPv6 地址都有一个特定的作用域，作用域是地址可以作为接口或接口组唯一标识符使用的拓扑范围。地址的作用域作为地址的一部分进行编码。你可以在多播地址章节找到关于作用域的描述，并参考 RFC 4007《IPv6 作用域地址架构》以了解作用域的解释。

地址表示法

IPv6 地址有 128 位，或 16 字节。该地址被划分为 8 个 16 位的十六进制块，由冒号分隔。例如：

2001:0db8:0000:0000:0202:b3ff:fe1e:8329

为了简化生活，可以使用一些缩写。例如，16 位块中的前导零可以省略。此时，示例地址看起来如下：

2001:db8:0:0:202:b3ff:fe1e:8329

双冒号可以替代地址中的连续零或前导零或尾随零。如果我们应用此规则，地址看起来如下所示：

2001:db8::202:b3ff:fe1e:8329

请注意，在一个地址中，双冒号只能出现一次。这个规则的原因是计算机始终使用地址的完整 128 位二进制表示，即使显示的地址已经简化。当计算机遇到双冒号时，它会用所需数量的零来扩展地址以达到 128 位。如果一个地址有两个双冒号，计算机就无法确定每个冒号应该添加多少零。因此，IPv6 地址2001:db8:0000:0000:0056:abcd:0000:1234可以通过以下方式表示（注意双冒号的两个可能位置）：

2001:db8:0000:0000:0056:abcd:0000:1234
2001:db8:0:0:56:abcd:0:1234
2001:db8::56:abcd:0:1234
2001:db8:0:0:56:abcd::1234

有很多种不同的方式来写和缩写 IPv6 地址，这可能会导致操作上的问题。如果你要在数据库或电子表格中进行查找，必须确保每个人都使用相同的格式来存储地址；否则，你将无法判断某个地址是否已经在列表中。为了这个目的，最好的选择可能是使用完整的格式，因为它是唯一不含歧义的格式。还要注意，有些系统对大小写敏感，因此需要定义是否使用大写字母。

为了简化管理，写了一份 RFC 来规范 IPv6 地址的表示方法。它还讨论了在将 IPv6 地址存储在数据库和电子表格中以供查找时可能出现的问题。你需要有明确的地址表示规则，才能找到地址。对于这些情况，最好使用完整的地址表示方法，因为它是唯一不含歧义的表示方式。对于所有其他情况，RFC 5952 建议使用以下规则：

  • 必须省略前导零。

  • 单个 16 位的 0000 字段必须表示为 0，并且不应被双冒号替代。

  • 尽可能简化表示。尽量使用双冒号。

  • 总是缩短最大数量的零。

  • 如果两个零区块长度相同，应该缩短第一个。

  • 对于 a、b、c、d、e、f 使用小写字母。

在 IPv4 和 IPv6 节点混合的环境中，另一种方便的 IPv6 地址表示方式是将 IPv4 地址的值放入地址的四个低位字节中。IPv4 地址192.168.0.2可以表示为x:x:x:x:x:x:192.168.0.2，而0:0:0:0:0:0:192.168.0.2可以写作::192.168.0.2。如果你愿意，也可以写成::c0a8:2。这是 192.168.0.2 的十六进制表示法。

对于带有端口号的 IPv6 地址表示，最好的方法是将 IPv6 地址放在方括号中，后跟冒号和端口号。因此，它可能看起来像这样：[2001:db8::1]:80。

注意

这些建议完全符合 RFC 4291 的要求。但 RFC 4291 还提供了更多的选择。IPv6 的实现必须始终能够处理任何 RFC 4291 规定的格式表示的地址。

前缀表示法

前缀的表示法也在 RFC 4291 中进行了规定。全局路由前缀是用于标识子网或特定类型地址的 IP 地址的高位字节（参见表 2-2）。它在早期的 RFC 中被称为格式前缀。前缀表示法与 IPv4 地址在 CIDR（无类域间路由）表示法中的写法非常相似，它也常用于子网划分的 IPv4 地址。该表示法在前缀后附加前缀长度，前缀长度作为以斜杠分隔的比特数表示，形成以下格式：

      *`IPv6 address/prefix length`*

前缀长度指定了地址中有多少最左边的位表示前缀。这是标记子网掩码的另一种方式。记住，子网掩码指定了 IPv4 地址中属于网络 ID 的位。前缀用于识别一个接口所属的子网，并由路由器用于转发。以下示例解释了如何理解前缀。考虑 IPv6 前缀表示法2001:db8:1200::/40。为了理解这个地址，我们将十六进制转换为二进制，如表 2-1 所示。

表 2-1. 理解前缀表示法

十六进制表示 二进制表示 位数
2001 0010 0000 0000 0001 16
0db8 0000 1101 1011 1000 16
1200 0001 0010 8
总计：40

压缩表示法（用双冒号替换一连串的零）同样适用于前缀表示。尽管如此，它应谨慎使用，因为一个地址中通常会有两个或更多的零范围，且只能压缩其中一个。RFC 5952 中的规则定义了如何进行压缩，但如前所述，IPv6 接口仍然必须能够处理不符合 RFC 5952 的地址。

全球路由前缀

表 2-2 概述了当前保留前缀和特殊地址的分配情况，例如链路本地地址或多播地址。大部分地址空间（超过 80%）是未分配的，只有少数特殊情况，如下所述。这为未来的分配留出了空间。

表 2-2. 分配的前缀列表

分配 前缀二进制 前缀十六进制 地址空间占比
全球单播 001 2000::/3 1/8
链路本地单播 1111 1110 10 fe80::/10 1/1024
唯一本地 IPv6 地址 1111 110 fc00::/7
多播 1111 1111 ff00::/8 1/256

所有未列在表 2-2 中的地址范围目前都是保留的或未分配的（以下列出了几个例外）。互联网号码分配局（IANA）目前仅从以 001 开头的二进制范围中分配地址。

注意

更新的地址分配列表可以在以下链接找到：www.iana.org/assignments/ipv6-address-space。你还可以在这里找到更新的 IANA 特殊用途前缀列表：bit.ly/1pDkTzo。

一些特殊地址是从保留地址空间中分配的，具有二进制前缀0000 0000。这些包括未指定地址、回环地址和嵌入 IPv4 地址的 IPv6 地址，后面章节中我会详细讨论这些地址。

单播地址可以通过其前缀与多播地址区分开。全局唯一的单播地址的高阶字节以001开头。一个高阶字节为1111 1111（即十六进制的ff）的 IPv6 地址始终是多播地址。有关多播地址的更多信息，请参阅 Multicast Address 部分。

Anycast 地址来自单播地址空间，因此仅通过查看前缀无法识别它们是 Anycast 地址。如果你将相同的单播地址分配给多个接口，从而使其成为 Anycast 地址，你必须配置这些接口，使它们都知道该地址是 Anycast 地址。有关 Anycast 地址的更多信息，请参阅 Anycast Address 部分。

全局单播地址

全局单播地址通过二进制前缀001进行标识，如表 2-2 中所示。RFC 4291 定义了全局单播地址格式，如图 2-1 所示。

全局单播地址格式图 2-1. 全局单播地址格式

全局路由前缀标识分配给站点的地址范围。该部分地址由国际注册服务和互联网服务提供商（ISPs）分配，并具有层级结构。子网 ID标识站点内的一个链路。一个链路可以分配多个子网 ID。站点的本地管理员分配该部分地址。接口 ID标识子网中的一个接口，并且在该子网内必须唯一。接口 ID 始终为 64 位，因此 IPv6 子网始终为/64 子网。IPv6 不再存在子网掩码问题。

国际注册服务和当前地址分配

IPv6 地址的国际分配已经委托给多个区域注册服务：ARIN（美国互联网号码注册中心）负责北美和撒哈拉以南非洲；RIPE NCC（欧洲 IP 网络协调中心）负责欧洲、中东、中亚和北非；APNIC（亚太网络信息中心）负责亚太地区；LACNIC（拉丁美洲和加勒比互联网地址注册中心）负责拉丁美洲。AfriNIC（非洲网络信息中心）于 2005 年开始运营，未来将覆盖非洲地区。

每个注册机构的网站上都有关于地址分配问题、当前实践和程序的信息。

已经进行了多个分配，如表 2-3 所列。

表 2-3. 当前分配

前缀 分配 RFC
0100::/64 丢弃专用地址块 RFC 6666
64:ff9b::/96 IPv4-IPv6 转换器 RFC 6052
2000::/3 全球单播地址空间 从2000::/3空间分配的地址可以在bit.ly/ipv6-add查看 RFC 4291
2001::/32 Teredo RFC 4380
2001:db8::/32 仅用于文档目的，不可路由 RFC 3849
2002::/16 6to4 RFC 3056
fc00::/7 唯一本地地址（ULA） RFC 4193
fe80::/10 链路范围单播 RFC 4291

注意

www.iana.org/numbers是全球 IP 地址服务、IPv4 和 IPv6 当前地址分配以及如何请求 IPv6 地址服务的重要入口。你还可以在此找到更新的 IANA 特殊用途前缀列表：bit.ly/1pDkTzo。

6Bone 操作的地址空间（3ffe::/16）在 2006 年 6 月被逐步淘汰，前缀被返回到未分配的地址池中。这个地址空间的创建是为了在 IPv6 地址分配尚未标准化时，允许进行全球范围的 IPv6 测试。由于 IPv6 地址分配已被定义，6Bone 主机已迁移到官方的 IPv6 地址空间。

注意

关于如何获取 IPv6 地址空间，请参考第九章中的规划内容。

那么，这个地址空间到底有多大呢？

在本章的引言部分，当我们讨论 IPv6 提供了多少个地址时，我曾承诺稍后会做一个例子。现在，我来提供这个例子。

如果 ISP 获得了/32 前缀，这意味着前缀中有 32 位可以由 ISP 或其客户进行管理。

注意

想象一下：一个单一的/32 地址块比我们在 IPv4 中曾经拥有的地址空间还要大，因为在 IPv4 中，地址的 32 位包括主机 ID，而在 IPv6 中，每个/64 子网有 64 位用于接口 ID。

这算多吗？显然，比我们在 IPv4 中拥有的要多得多。但我们仍然不知道它到底有多大。

让我们看看 IANA 的 IPv6 地址池。到 2014 年 3 月为止，已经分配了 138,786 个/32 块。如果我们考虑到其中一个块比我们在 IPv4 中曾经拥有的地址空间还要大，那么这个数字看起来相当可观。

注意

如果我们计算当前可用的总 IPv6 地址空间（2000::/3）中有多少，结果是占 0.026%。

使用 138,786 个/32 块，可以为超过 90 亿个客户分配/48 地址，每个客户可以创建 65,536 个/64 子网。

在www.bgpexpert.com/addrspace-ipv6.php上，你可以找到关于 IPv6 分配的最新数据。

因此，我恳请你在开始工作时，将这些数字作为你每天的座右铭。当我们进行 IPv6 地址规划时，其中一个最大挑战就是摆脱那些深深植入我们细胞中的地址节约规则。即使某些做法看起来非常浪费，实际上也许并不是。如果我们必须意识到我们过于浪费了，因为我们在 20 年内使用完了2000::/3，我们依然有 7 倍更多的空间可以利用。所以，2000::/3仅仅是二进制 001 块，它目前用于全球唯一的单播 IPv6 地址。

接口标识符

前缀范围001到111之间的地址应使用遵循 EUI-64（扩展唯一标识符）格式的 64 位接口标识符（多播地址前缀为1111 1111的地址除外）。EUI-64是由电气和电子工程师协会（IEEE）定义的唯一标识符。RFC 4291 的附录 A 解释了如何创建 EUI-64 标识符，更多细节可以在特定的 RFC 中找到，如“IPv6 over Ethernet”或“IPv6 over FDDI”。第五章包含了简短的讨论和这些 RFC 的列表。

在无状态地址自动配置期间，接口使用遵循 EUI-64 格式的标识符。例如，当一个接口通过其 MAC 地址在以太网接口上自动配置链路本地地址时，必须从 48 位（6 字节）以太网 MAC 地址创建 64 位接口标识符。首先，将十六进制数字0xff-fe插入到 MAC 地址的第三个字节和第四个字节之间。然后，MAC 地址的第一个字节0x00中的第二个低位（universal/local 位）被补充。0x00的第二个低位是0，补充后变为1；因此，MAC 地址的第一个字节变为0x02。

因此，IPv6 接口标识符对应于以太网 MAC 地址00-02-b3-1e-83-29的是02-02-b3-ff-fe-1e-83-29。此示例仅讨论了 EUI-64 创建过程。在无状态地址自动配置期间，还会发生许多其他步骤。

注意

要了解 IPv6 无状态地址自动配置如何工作，请参阅第四章。

接口的链路本地地址是前缀fe80::/64和一个以 IPv6 冒号十六进制表示的 64 位接口标识符的组合。因此，前述示例接口的基于 MAC 的链路本地地址，具有前缀fe80::/64和接口标识符02-02-b3-ff-fe-1e-83-29，为fe80::202:b3ff:fe1e:8329。此过程如图 2-2 所示，并在 RFC 2464《IPv6 数据包在以太网网络上传输》中有所描述。

MAC 地址如何转换为接口标识符图 2-2. MAC 地址如何转换为接口标识符

图中展示了该接口标识符如何与链路本地前缀结合。如图所示，它可以与接收到的任何其他前缀结合。（更多内容请参见第四章，关于邻居发现。）在撰写时，关于是否使用基于硬件信息的接口标识符，存在讨论。更多信息请见下文。

地址隐私

使用接口标识符的自动配置 IPv6 地址隐私性是 IPv6 初期在 IETF 中讨论的问题。如果 IPv6 地址是使用 MAC 标识符构建的，那么即使跨网络，你的互联网访问也可能被追踪，因为这个标识符是唯一的，与你的接口相关。需要理解的是，IPv6 节点可以基于接口标识符拥有一个地址，但这并不是必须的。作为替代，IPv6 设备可以拥有类似当前 IPv4 地址的地址，这些地址可以是静态手动配置的，也可以是由 DHCP 服务器动态分配的。RFC 4941《IPv6 无状态地址自动配置的隐私扩展》引入了另一种仅在 IPv6 中使用的地址类型，其中包含一个随机数字，代替硬件地址。这个接口 ID 也可以随着时间的推移而变化。有时它也被称为临时地址。它是在 EUI-64 接口 ID 之外生成的。临时地址用于外发通信，而基于 EUI-64 的地址用于服务器功能和传入连接。

作为 IP 通信目标的互联网设备——例如，Web 或 FTP 服务器——需要一个唯一且稳定的 IP 地址。但运行浏览器或 FTP 客户端的主机则不需要每次连接互联网时都使用相同的地址。一些 DHCPv6 实现支持根据 RFC 4941 生成随机接口标识符。通过这种方式，它们使用 DHCPv6 管理地址空间，但防止任何人进行拓扑映射或追踪其节点。

在 IPv6 的地址架构中，你可以选择两种类型的地址：

唯一稳定的 IP 地址

通过手动配置、DHCP 服务器或使用 EUI-64 接口标识符的无状态地址自动配置分配，或者使用永久 IID 创建的其他地址类型（见下文）。

临时过渡性 IP 地址

使用定期变化的随机数字分配，并可以作为稳定接口标识符的替代。

虽然临时隐私地址通过增加窃听者和其他信息收集者（例如日志文件、头部信息）关联主机活动的难度提供了一些安全性，但它们在其他领域可能会带来挑战。从网络管理的角度来看，临时地址增加了事件日志记录、故障排除、访问控制和服务质量的复杂性。因此，一些组织即使牺牲了隐私，也禁用了临时地址的使用。为了确保地址稳定且不频繁变化（如隐私地址所做的那样），RFC 7217 中定义了稳定隐私地址，《一种生成语义不透明接口标识符的 IPv6 无状态地址自动配置方法》。其目标是使 IPv6 地址在子网内稳定，但在主机从一个网络迁移到另一个网络时会发生变化，并且不基于任何硬件标识符。此方法适用于主机可能使用的所有前缀，如链路本地、全局或唯一本地地址。

与此同时，目前（截至 2014 年初）有一份名为《稳定 IPv6 接口标识符建议》（draft-ietf-6man-default-iids-00）的草案正在讨论。该草案建议使用不基于硬件标识符的稳定 SLAAC 地址。如前所述，已经有人提出将硬件信息嵌入 IPv6 地址中会带来安全和隐私风险。草案《IPv6 地址生成机制的隐私考虑》（draft-ietf-6man-ipv6-address-generation-privacy-01.txt）对每种接口 ID 生成选项的利弊进行了很好的讨论。

注意

请注意，在考虑所有这些因素时，接口 ID 并不是唯一用于追踪用户的方法。DNS 名称、Cookie、浏览器指纹和应用层用户名都可以用来将主机的活动关联在一起。

特殊地址

我们需要讨论一些特殊地址。IPv6 地址空间的第一部分以0000 0000为前缀，该部分被保留。在这个前缀中，已经定义了一些特殊地址：

未指定地址

未指定地址的值为0:0:0:0:0:0:0:0，因此也称为全零地址。它与 IPv4 中的0.0.0.0类似。它表示缺少有效地址，例如，在启动过程中，主机在发送地址配置请求时，可以使用该地址作为源地址。如果应用本章前面讨论的记法规范，未指定地址也可以简写为::。它永远不应静态或动态分配给接口，且不应出现在目标 IP 地址或 IPv6 路由头中。有时它在软件配置文件中被使用，告诉程序使用接口上配置的任何 IPv6 地址。

回环地址

127.0.0.1这个 IPv4 回环地址你可能很熟悉。它在故障排除和测试 IP 协议栈时非常有用，因为可以用来将数据包发送到协议栈，而无需将其发送到子网。对于 IPv6，回环地址的作用相同，表示为0:0:0:0:0:0:0:1，简写为::1。它不应被静态或动态地分配给接口。

接下来的部分将描述为与不同过渡机制一起使用而被指定的不同类型的地址，这些地址可以在向 IPv6 迁移的过程中使用。这些虚拟接口通常称为伪接口。

注意

有关过渡机制的描述可以在第七章中找到。

带有嵌入 IPv4 地址的 IPv6 地址

由于向 IPv6 的过渡将是渐进的，因此为与 IPv4 兼容而定义了两种特殊类型的地址。两者均在 RFC 4291 中有所描述：

IPv4 兼容的 IPv6 地址（已弃用）

这种类型的地址用于通过 IPv4 路由基础设施动态隧道 IPv6 数据包。使用这种技术的 IPv6 节点会被分配一个特殊的 IPv6 单播地址，其中低位 32 位包含一个 IPv4 地址。到目前为止，这种地址类型很少被使用，并且在 RFC 4291 中已被弃用。新的或更新的实现将不再需要支持这种类型的地址。

IPv4 映射的 IPv6 地址

这种类型的地址用于将 IPv4-only 节点的地址表示为 IPv6 地址。IPv6 节点可以使用该地址将数据包发送到 IPv4-only 节点。该地址还在地址的低位 32 位中携带 IPv4 地址。

图 2-3 显示了这两种地址的格式。

带有嵌入 IPv4 地址的 IPv6 地址的格式图 2-3. 带有嵌入 IPv4 地址的 IPv6 地址的格式

这两种地址几乎相同，唯一的区别是中间的 16 位。当它们设置为 0 时，该地址为 IPv4 兼容的 IPv6 地址；如果这些位设置为 1，则为 IPv4 映射的 IPv6 地址。

6to4 地址

IANA 已经永久分配了一个 13 位的 TLA 标识符，用于 6to4 操作，属于全球单播地址范围（001）。6to4 是定义的一种机制，用于让 IPv6 主机或网络通过仅支持 IPv4 的基础设施进行通信。我在第七章中描述了 6to4，并且它在 RFC 3056 中有所规定。6to4 的 TLA 标识符是0x0002。地址格式见图 2-4。

6to4 地址的格式图 2-4. 6to4 地址的格式

前缀的总长度为 48 位。前缀中的 IPv4 地址必须是一个公共的 IPv4 地址，并以十六进制表示。例如，如果你为 6to4 配置一个接口，并且该接口的 IPv4 地址为 62.2.84.115，则 6to4 前缀为 2002:3e02:5473::/48。通过这个接口，所有在该链路上的 IPv6 主机都可以通过 IPv4 基础设施隧道传输它们的包。

注意

6to4 规范是在全球单播地址格式根据 RFC 2374 为当前时，编写的，因此它使用了旧的术语和格式（格式前缀、TLA、SLA）。

6rd 地址

2010 年发布了一项名为 6rd（IPv6 快速部署）的规范。它在 第七章中进行了描述，并在 RFC 5969 中进行了规范。地址格式基于 6to4，并显示在 图 2-5 中。

6rd 地址格式图 2-5. 6rd 地址格式

地址的主要区别在于，6rd 不使用像 6to4 那样的特殊前缀，也没有像 /48 这样的固定边界。前缀的总长度为 64 位，并分为 ISP 前缀和站点的 IPv4 地址。如图所示，这两部分的长度是可变的。如果提供商使用他的 /32 前缀并添加站点的完整 IPv4 地址，他最终会为客户分配 /64 子网。在大多数情况下，不推荐这样做。即使是家庭站点，未来也需要多个子网。根据 ISP 的环境、地址架构和客户结构，设计 6rd 地址有很多种方式。一个选择是，如果 ISP 有 /28 前缀，他可以添加 32 位的 IPv4 地址，并向客户分配 /60 前缀。或者，如果他的 IPv4 地址规划允许在一个 /8 前缀（客户的 IPv4 地址）中聚合客户，则 6rd 前缀的大小将是以下之一：

  • 如果提供商有 /28 前缀（28 + 24 用于聚合客户 IPv4 块），则为 /52。

  • 如果提供商有 /32 前缀（32 + 24 用于聚合客户 IPv4 块），则为 /56。

在多个地区，如 RIPE 和 ARIN，正在进行讨论，旨在通过向 ISP 分配更大的 6rd 前缀来简化这一过程。

注意

这里的重点是分配前缀给家庭用户，以便他们可以拥有多个子网。有关区域注册表政策和家庭网络的描述，请参阅 第九章。

ISATAP 地址

站内自动隧道地址协议（ISATAP）是一种自动隧道机制，在 RFC 5214 中进行了规范。它为通过仅支持 IPv4 的基础设施分隔的双栈节点设计。它将 IPv4 网络视为一个大型链路层网络，并允许这些双栈节点使用任何形式的 IPv4 地址自动在彼此之间隧道传输。ISATAP 使用0xFE的类型标识符来指定带有嵌入 IPv4 地址的 IPv6 地址。ISATAP 地址的格式如图 2-6 所示。

ISATAP 地址格式图 2-6. ISATAP 地址格式

前 64 位遵循全局单播地址的格式。IANA 拥有 IEEE 组织唯一标识符（OUI）00-00-5E，并在该 OUI 内指定了 EUI-48 格式的接口标识符分配。在前 16 位中，一个类型标识符表示 IPv4 地址是来自私有范围（0000）还是全局唯一地址（0200）。接下来的 8 位包含一个类型标识符，用于表明这是一个带有嵌入式 IPv4 地址的 IPv6 地址。该类型标识符是0xFE。最后 32 位包含嵌入的 IPv4 地址，该地址可以用点分十进制表示法或十六进制表示法写出。

假设我们有一个 IPv4 地址为192.168.0.1的主机，并且该主机被分配了一个 64 位前缀2001:db8:510:200::/64。该主机的 ISATAP 地址为2001:db8:510:200:0:5efe:192.168.0.1。或者，你也可以使用 IPv4 地址的十六进制表示形式，此时地址写作2001:db8:510:200:0:5efe:c0a8:1。该主机的链路本地地址为fe80::5efe:192.168.0.1。

Teredo 地址

Teredo是一种旨在为位于一个或多个 NAT 后面的主机提供 IPv6 连接性的机制。其通过在 UDP 中隧道传输 IPv6 数据包来实现。该机制包括 Teredo 客户端、服务器和中继。Teredo 中继是位于 Teredo 服务和本地 IPv6 网络之间的 IPv6 路由器。Teredo 在 RFC 4380 中进行了规范。原本预期这一服务会广泛应用，直到 ISP 升级到本地 IPv6 服务。但当前的互联网统计数据显示，情况并非如此。你可以参考Google 统计，查看代表 6to4 和 Teredo 流量的红线如何下降到几乎为零。

一个 Teredo 地址的格式如图 2-7 所示。

Teredo 地址格式图 2-7. Teredo 地址格式

该前缀的长度为 32 位。全球 Teredo IPv6 服务前缀是2001:0000:/32。服务器 IPv4 地址字段的长度为 32 位，包含 Teredo 服务器的 IPv4 地址。标志字段长度为 16 位，指定所使用的地址类型和 NAT 类型。16 位端口字段包含 Teredo 服务在客户端的映射 UDP 端口，客户端 IPv4 地址字段包含客户端的映射 IPv4 地址。在这种格式中，客户端的映射 UDP 端口和映射 IPv4 地址都会被混淆：地址和端口号中的每一位都会被反转。

注意

要了解 IPv6 和 IPv4 如何通过这些地址共存，请参考第七章。

加密生成地址

为了增加邻居发现（ND）的安全性，RFC 3972 定义了加密生成地址（CGA）。RFC 3972 已经被 RFC 4581 和 4982 更新。CGA 包含了公共密钥的加密哈希，作为接口 ID 的一部分。相应的私钥可以用来签署从该地址发送的消息。这可以防止攻击者接管一个 IPv6 地址，并可在没有公钥基础设施（PKI）的环境中使用。

链路本地地址和唯一本地 IPv6 地址

在 IPv4 中，组织通常使用 RFC 1918 定义的私有地址范围中的 IP 地址。保留用于私有用途的地址永远不应通过互联网路由器转发，而应限制在组织的网络内部。为了连接到互联网，网络地址转换（NAT）将内部私有地址映射到公开注册的 IPv4 地址。

最初的 IPv6 规范为链路本地和站点本地用途分配了两个独立的地址空间（作用域），并通过它们的前缀来标识。这些站点本地地址的前缀是fec0::/10。

注意

站点本地地址已在 RFC 3879 中被弃用。由于该地址在应用过程中出现了过多潜在问题，因此被替换为唯一本地 IPv6 地址，也叫做 ULA（见下文）。

链路本地地址用于单一链路，并且不应被路由。它不需要全球前缀，可以用于自动配置机制、邻居发现以及没有路由器的网络，因此它对于创建临时网络非常有用。假设你在会议室遇到你的朋友，并且你想要分享计算机中的文件。你可以通过无线网络或在以太网接口之间使用交叉电缆连接计算机，利用链路本地地址共享文件，而无需任何特殊配置。

站点本地地址的替代方案称为唯一本地 IPv6 单播地址(ULA)，简称本地 IPv6 地址。该地址在 RFC 4193 中有详细说明。这些地址是全球唯一的，但不应路由到全球互联网。它们旨在用于公司站点或有限的网络集内。

唯一本地 IPv6 单播地址的特点如下：

  • 拥有一个唯一的全球前缀，允许在网络边界进行过滤

  • 允许网络之间的私密连接，而不必担心地址冲突和重新编号其中一个站点的后果

  • 与 ISP 无关

  • 可以在没有互联网连接的情况下用于内部通信

  • 可以像常规全球单播地址一样供应用程序使用

这些地址的格式见图 2-8.

链路和站点本地地址格式图 2-8. 链路和站点本地地址格式

在十六进制表示法中，链路本地地址由前缀fe80::/10标识。对于唯一本地 IPv6 地址，RFC 4193 指定了fc00::/7的前缀。第 8 位目前设置为1，表示该前缀由本地管理。将第 8 位设置为0可能在未来用于中心化管理的地址。目前，已决定只标准化本地分配的版本。如果未来确实有强烈需求，可能会定义中心化分配的形式。

注意

与此同时，你可以使用Sixxs 非官方注册网站进行查询。你还可以在那里找到其他有用的 IPv6 信息和工具。

对于本地管理地址，目前我们使用的十六进制前缀是fd00::/8。它后面跟着 40 位的全球 ID，该 ID 是随机生成的，以确保具有较高的唯一性；16 位用于子网 ID；64 位用于接口标识符。如果你使用的是较旧的实现，仍然可能会看到已弃用的站点本地地址，其前缀为fec0::/10，但新实现或部署应避免使用此地址，而应替换为全球单播地址或 ULA。

确保你的全球 ID 是使用 RFC 4193 中定义的伪随机全球 ID 算法生成的。此算法包括时间、硬件标识符以及其他系统特定的值等。这是为了确保你的前缀是唯一的，并且在将你的网络与任何其他 ULA 网络合并时，不会发生 ULA 冲突。

如前所述，这些本地地址不应路由到互联网上。边界路由器应配置为过滤这些前缀。本地地址不应出现在全球 DNS 服务器中。它们可以在你自己的内部私有 DNS 服务器上使用。

链路本地地址 (fe80::/10) 默认通过自动配置分配。ULA 必须通过在路由器上配置本地前缀（路由器广告）或通过 DHCPv6 进行分配。

注意

如果你对弃用站点本地地址的原因感兴趣，请参考 RFC 3879. 在第九章中找到关于是否以及何时使用 ULA 的讨论。

Anycast 地址

Anycast 地址旨在提供冗余和负载均衡，适用于多个主机或路由器提供相同服务的情况。Anycast 并非为 IPv6 设计；它在 1993 年由 RFC 1546 定义，为 IPv4 提供了一种实验性规范。该 RFC 为 Anycast 分配了一个特殊前缀，使得 Anycast 地址可以根据前缀被识别出来。Anycast 主要用于 DNS 和 HTTP 等服务。该 RFC 讨论了针对这些不具有全球唯一性的地址可能对 TCP 进行的修改。

实际上，Anycast 并没有按预期那样实现。通常会选择一种叫做共享单播地址的方法。这种方法通过将一个常规单播地址分配给多个接口，并在路由表中创建多个条目来实现。在这种情况下，网络层和传输层假定它是一个全球唯一的 IP 地址。如果它不是，处理歧义地址的机制需要集成到应用程序中。这个规则的一个例外是如果应用程序使用独立的无状态请求/应答事务——例如，DNS over UDP。互联网中的根 DNS 服务器是通过共享单播地址设置的。由于该过程不需要网络层的任何支持，因此它也可以与 IPv6 一起使用。

从一开始，IPv6 开发者就考虑将 Anycast 纳入网络层，按照 RFC 1546 的定义。没有分配特殊前缀。IPv6 Anycast 地址与全局单播地址处于相同的地址范围内，并且每个参与的接口都必须配置有 Anycast 地址。在包含相同 Anycast 地址的接口所在的区域内，每个主机必须作为路由表中的一个单独条目进行广告。

在一个网络中，如果一组路由器可以提供访问共同的路由域，它们可以分配一个单一的地址。当客户端将数据包发送到此地址时，它将被转发到下一个可用的路由器。一个例子是 RFC 3068 中指定的 6to4 中继 Anycast 地址，并在第七章中进行了描述。移动 IPv6 规范也使用 Anycast 地址。

使用任何播送地址时，我们必须意识到发送者无法控制数据包将被送达哪个接口。这个决定是在路由协议层面做出的。当发送者向任何播送地址发送多个数据包时，由于路由表的不稳定或在请求期间发生的变化，数据包可能到达不同的目的地。如果存在一系列的请求和应答，或者数据包必须被分段，这可能会导致问题。

子网路由器任何播送地址，定义在 RFC 4291 中，并在图 2-9 中展示，是一个必需的任何播送地址。

子网路由器任何播送地址的格式图 2-9. 子网路由器任何播送地址的格式

基本上，这个地址看起来像是一个常规的单播地址，前缀指定了子网，标识符设置为全零。发送到该地址的数据包将被送达该子网上的一个路由器。所有路由器都需要支持子网路由器任何播送地址，才能支持它们有接口的子网。

保留的子网任何播送地址可以有两种格式，如图 2-10 所示。

任何播送地址的一般格式图 2-10. 任何播送地址的一般格式

RFC 2526 规定，在每个子网内，最高的 128 个接口标识符值保留作为子网任何播送地址分配。目前，已预留的任何播送 ID 列表请参见表 2-4。

表 2-4. 保留的任何播送 ID

十进制 十六进制 描述
127 7F 保留
126 7E 移动 IPv6 主代理的任何播送
0–125 00–7D 保留

这种使用任何播送的形式与共享单播地址的主要区别在于，后者需要应用程序支持任何播送，而前者则尽量避免这种支持。如果需要，应该提供如何使用此方式的指南，并对现有的有状态传输协议进行修改。

注意

如果你对任何播送（anycast）有兴趣，想了解更多信息和背景，参考 RFC 7094，"IP Anycast 的架构考虑"。它提供了任何播送的历史概述，讨论了不同的架构模型和原理，并涵盖了 IPv6 中的任何播送及部署注意事项。

组播地址

本节介绍了组播地址格式。有关组播和组播监听发现（MLD）的描述，参见第四章。有关组播主题的一般概述和总结，请参见第五章.

组播地址是一个标识符，用于标识一组节点，这些节点的高字节为ff，即二进制表示为1111 1111（参见本章前面的表 2-2）。组播前缀为ff00::/8。一个节点可以属于多个组播组。当数据包发送到组播地址时，组播组的所有成员都将处理该数据包。IPv4 中也存在组播，但 IPv6 中的组播经过重新定义和改进。组播地址格式如图 2-11 所示。

组播地址格式图 2-11. 组播地址格式

第一个字节标识该地址为组播地址。接下来的四位用于标识标志位，定义如下：标志字段的第一个比特必须为零，保留供未来使用。第二个比特表示该组播地址是否包含会合点。会合点是组播网络中某一特定组播流的分发点（参见 RFC 3956）。第三个比特表示该组播地址是否包含前缀信息（本章稍后讨论；另见 RFC 3306）。标志字段的最后一位表示该地址是否为永久分配——即由 IANA 分配的知名组播地址，或临时组播地址。最后一位为零时定义为知名地址，为一时则表示临时地址。作用域字段用于限制组播地址的范围。可能的值请参见表 2-5。

表 2-5. 作用域字段的值

值 描述
0 保留
1 接口本地范围（在早期规范中曾称为节点本地范围）
2 链路本地范围
3 保留
4 管理本地范围
5 站点本地范围
6, 7 未分配
8 组织本地范围
9, A, B, C, D 未分配
E 全局范围
F 保留

范围的边界（除接口本地、链路本地和全局之外）必须由网络管理员定义和配置。保留的范围不应使用。RFC 4007《IPv6 作用域地址架构》定义了不同作用域 IPv6 地址的架构特性、预期行为、文本表示和使用方法。

知名组播地址

根据 RFC 4291，地址的最后 112 位携带组播组 ID。RFC 3307《IPv6 组播地址分配指南》参考了一个 32 位的组 ID。

RFC 2375 定义了永久分配的 IPv6 组播地址的初始分配。某些分配是为固定作用域做的，而某些分配则在所有作用域上有效。 表 2-6 给出了为固定作用域分配的地址的概览。请注意，在紧随 ff（第一个字节）之后的字节中列出的作用域值，这些值列在 表 2-5 中。

表 2-6. 知名组播地址

地址 描述
接口-local 作用域
ff01::1 所有节点地址
ff01::2 所有路由器地址
ff01::fb mDNSv6
链路-local 作用域
ff02::1 所有节点地址
ff02::2 所有路由器地址
ff02::4 DVMRP 路由器
ff02::5 OSPFIGP
ff02::6 OSPFIGP 指定路由器
ff02::7 ST 路由器
ff02::8 ST 主机
ff02::9 RIP 路由器
ff02::a EIGRP 路由器
ff02::b 移动代理
ff02::d 所有 PIM 路由器
ff02::e RSVP 封装
ff02::16 所有支持 MLDv2 的路由器
ff02::6a 所有嗅探器
ff02::fb mDNSv6
ff02::1:1 链路名称
ff02::1:2 所有 DHCP 代理
ff02::1:3 链路-local 多播名称解析 (LLMNR)
ff02::1:4 DTCP 公告
ff02::1:ffXX:XXXX 请求节点地址
ff02::2:ff00::/104 节点信息查询
站点-local 作用域
ff05::2 所有路由器地址
ff05::fb mDNSv6
ff05::1:3 所有 DHCP 服务器
ff05::1:1000 到 ff05::1:13ff 服务位置 (SLP) 版本 2

来自 RFC 2375 的术语 node-local scope 已更改为 interface-local scope，因此你可能会遇到这两个术语。与作用域无关的永久分配组播地址的列表较长，并且可以在 附录 B 和 RFC 2375 中找到。所有这些地址的开头都是 ff0X，X 是一个可变作用域值的占位符。

IPv4 广播地址被链路-local 所有节点多播地址 ff02::1 替代。

注意

在此查看最新的组播地址分配列表: www.iana.org/assignments/ipv6-multicast-addresses。

举个例子，我们来看 RFC 2373 中描述的一个例子。为所有 NTP 服务器定义了一个组播组 ID。该组播组 ID 为 0x101。这个组 ID 可以与不同的作用域值一起使用，如下所示：

ff01::101

发送方所在节点的所有 NTP 服务器。

ff02::101

发送方所在链路的所有 NTP 服务器。

ff05::101

发送方所在站点的所有 NTP 服务器。

ff0e::101

互联网上的所有 NTP 服务器。

临时分配的组播地址仅在定义的作用域内有意义。

注意

多播地址不应作为 IPv6 数据包中的源地址使用，也不应出现在任何路由头中。

在多播管理方面，IPv6 使用基于 ICMPv6 的多播监听器发现（MLD）。

注意

要了解多播地址的管理方式，请参考第四章中的多播监听器发现。若要获得关于多播的概述和总结，请参考第五章.

请求节点多播地址

请求节点多播地址是每个节点必须为其分配的每个单播和任何播地址加入的多播地址。它用于邻居发现，详细内容见第四章。RFC 4291 规定了请求节点多播地址。

在 IPv4 网络中，ARP 请求（用于确定接口的 MAC 地址）会发送到 MAC 层广播地址，因此会被链路上的每个接口检查。而在 IPv6 网络中，接口的 MAC 地址解析是通过发送邻居请求消息（在第四章中讨论）到请求节点多播地址来完成的，而不是发送到链路本地所有节点的多播地址。这样，只有注册到该多播地址的节点才会检查该数据包。

这个地址是通过取一个 IPv6 地址的低 24 位（主机 ID 的最后一部分），并将这些位附加到已知前缀 ff02:0:0:0:0:1:ff00::/104 后形成的。因此，请求节点多播地址的范围从 ff02:0:0:0:0:1:ff00:0000 到 ff02:0:0:0:0:1:ffff:ffff。

例如，我们的主机 Marvin 拥有 IPv6 地址 fe80::202:b3ff:fe1e:8329。对应的请求节点多播地址是 ff02::1:ff1e:8329。如果该主机还有其他 IPv6 单播或任何播地址，每个地址都会有一个对应的请求节点多播地址，主机必须注册该地址。

将多播地址映射到 MAC 地址

当一个数据包发送到一个 IPv6 多播地址时，必须将该 IPv6 地址映射到链路层的 MAC 地址。以太网 MAC 多播地址的格式在 RFC 2464 中有规定。IPv6 MAC 多播地址的前两个字节是 0x3333。接下来的四个字节对应于 IPv6 多播地址的最后四个字节。

图 2-12 展示了多播地址如何映射到 MAC 地址。

IPv6 多播地址的 MAC 表示图 2-12. IPv6 多播地址的 MAC 表示

ff02::1:3 的链路本地作用域多播地址映射到 MAC 地址 33:33:00:01:00:03。其他媒体类型的映射在单独的 RFC 中进行了说明。您可以在 第五章 中找到有关其他媒体类型的更多信息，或通过搜索 RFC 数据库。

多播地址的动态分配

多播地址架构在 RFC 3306 中得到了扩展。它包含允许基于单播前缀地址和源特定多播地址分配的定义。它基于一种修改过的多播地址格式，其中包含前缀信息。此规范的目标是减少分配多播地址所需的协议数量。

图 2-13 显示了扩展多播地址的格式。

扩展多播地址的格式图 2-13. 扩展多播地址的格式

在原始规范中，标志字段仅使用最后一位（T）来指定多播地址是已知地址还是临时地址。这里显示的扩展格式使用倒数第二位（P）来指示多播地址分配是否基于网络前缀（值为 1）或不是（值为 0）。P 设置为 1 表示这是一个遵循扩展格式的多播地址。作用域字段的使用没有变化。如果 P 标志设置为 1，则作用域字段后的八位被保留并设置为 0。接下来的八位（PLen）指定前缀字段中的前缀长度。如果前缀长度小于 64 位，则前缀字段中的未使用位应设置为 0。组 ID 使用 32 位。注意，当 P 设置为 1（扩展多播地址）时，T 标志也应设置为 1（临时多播地址）。

多播监听者发现（MLD）用于多播管理。它有两个版本，MLDv1 和 MLDv2。MLDv2 支持源特定多播。有关源特定多播的概述，请参阅 RFC 3569。在传统的多播模型中，称为任意源多播（ASM），多播监听者无法控制它想接收的数据源。而在源特定多播（SSM）中，一个接口可以注册一个多播组，并指定数据的源(s)。SSM 可以通过 MLDv2 和扩展的多播地址格式实现。

对于源特定多播地址，T 和 P 标志都设置为 1。前缀长度和网络前缀都设置为 0。这将导致一个多播前缀 ff3x:/32，其中 x 是作用域值。IPv6 头中的源地址标识多播地址的所有者。所有 SSM 地址的格式为 ff3X::/96。

注

有关更多信息，请参阅 RFC 3307，“IPv6 多播地址分配指南”。

RFC 4489《链路范围组播地址格式》定义了 IPv6 协议的组播寻址架构的扩展。该扩展允许使用接口标识符来分配链路本地范围的组播地址。在这个组播地址中，标志字段被设置为二进制 0011；作用域字段被设置为 2，表示链路本地作用域；pLen 字段被设置为 ff（全是 1 的二进制）；网络 ID 字段的 64 位用于接口标识符。组 ID 生成以指示组播应用，并且只需在该主机上唯一。它设计用于使用链路本地范围组播地址的环境。

必需的地址

标准规定，每个主机必须分配以下地址来标识自己：

  • 每个接口的链路本地地址

  • 所有分配的单播和任何播地址

  • 回环地址

  • 所有节点的组播地址

  • 为其分配的每个单播和任何播地址的请求节点组播地址

  • 主机所属的所有其他组的组播地址

路由器需要识别所有上述地址，并且还需要识别以下地址：

  • 配置为在每个链路上作为路由器工作的接口的子网路由器任何播地址

  • 路由器已配置的所有任何播地址

  • 所有路由器的组播地址

  • 路由器所属的所有其他组的组播地址

默认地址选择

IPv6 的架构允许一个接口拥有多个地址。这些地址可能在作用域（链路本地、全球）或状态（首选、过时）上有所不同；它们可能是移动性（家庭地址、临时地址）或多宿主情况的一部分；也可能是永久的公共地址或虚拟隧道接口。双栈主机具有 IPv6 和 IPv4 地址。结果是，IPv6 实现需要发起连接时，通常面临从多个源地址和目的地址中做出选择的情况。

假设有这样一种情况，一个客户端发出对外部服务的 DNS 请求，并接收到一个全球 IPv6 地址和一个公共 IPv4 地址。如果该客户端有一个私有 IPv4 地址和一个全球 IPv6 地址，那么使用 IPv6 访问该外部服务是有意义的。但如果该客户端有一个隧道化的 IPv6 地址和一个公共 IPv4 地址，则应选择 IPv4 地址来连接服务。这些是在未来混合网络环境中需要处理的情况和选择，一些是仅支持 IPv4 的，另一些是仅支持 IPv6 的，还有一些是双栈的。如何处理这些情况取决于具体的实现。应用程序开发人员需要意识到这一点，并尽力提供能够使应用程序在每种可能的环境中都能表现最佳的机制。

RFC 6724, “IPv6 的默认地址选择”定义了两个通用算法，一个用于源地址选择，另一个用于目标地址选择。所有 IPv6 节点（主机和路由器）都必须实现 RFC 6724。该算法指定了 IPv6 节点的默认行为。该算法不覆盖应用程序、上层协议或其他策略做出的选择。该 RFC 包含一个策略表，类似于路由表，是一个最长匹配前缀查找表。为每个列出的前缀分配一个优先级和一个标签。优先级用于对目标地址进行排序；标签值用于定义将特定源地址与给定目标地址关联的策略。

下面是最重要规则的总结：

  • 相同作用域或类型（链路本地、全球）的地址对优先。

  • 目标地址的作用域越小越优先（使用最小的作用域）。

  • 优先选择首选（非弃用）地址。

  • 如果有原生 IPv6 地址可用，则不使用过渡地址（例如 ISATAP 或 6to4 地址）。

  • 如果所有标准相似，则优先选择具有最长公共前缀的地址对。

  • 优先选择外向接口。

  • 优先选择由下一跳广告的前缀中的地址。

  • 优先匹配标签。

  • 对于源地址，临时地址优先于公共地址。

  • 使用最长匹配前缀。

  • 在移动 IP 环境中，家庭地址优先于照看地址。

简而言之，默认表格优先选择原生 IPv6 地址，其次是原生 IPv4 地址，再次是 NAT 转换后的 IPv4 地址，最后是 6to4 和其他隧道。

注意

RFC 6724 中的规则在没有其他规定时应被使用。实现应提供机制，以覆盖默认策略，并根据网络的具体情况单独配置地址选择。RFC 7078 定义了一个 DHCP 选项，允许管理员分发覆盖 RFC 6724 默认策略的地址选择策略。

现在你已经熟悉了扩展的地址空间和 IPv6 地址类型，下一章将讨论 IPv6 头部和扩展头部。

参考文献

以下是本章中提到的最重要的 RFC 和草案的列表。有时我还会为你个人的进一步学习，加入一些与主题相关的附加 RFC。

RFC 文档

  • RFC 1546, “主机任播服务”，1993 年

  • RFC 1918, “私人互联网地址分配”，1996 年

  • RFC 2101, “今天的 IPv4 地址行为”，1997 年

  • RFC 2365, “管理员作用域的 IP 多播”，1998 年

  • RFC 2464, “IPv6 数据包通过以太网网络的传输”，1998 年

  • RFC 2471, “IPv6 测试地址分配（6Bone）”，1998 年

  • RFC 2526, “保留的 IPv6 子网任播地址”，1999 年

  • RFC 2710, “IPv6 的多播监听发现（MLD）”，1999 年

  • RFC 2908, “互联网多播地址分配架构”，2000 年

  • RFC 3056, “通过 IPv4 云连接 IPv6 域”（6to4），2001 年

  • RFC 3068，“用于 6to4 转发路由器的任何播前缀”，2001 年

  • RFC 3306，“基于单播前缀的 IPv6 多播”，2002 年

  • RFC 3307，“IPv6 多播地址的分配指南”，2002 年

  • RFC 3569，“源特定多播（SSM）概述”，2003 年

  • RFC 3587，“IPv6 全球单播地址格式”，2003 年

  • RFC 3590，“多播监听器发现（MLD）协议的源地址选择”，2003 年

  • RFC 3810，“IPv6 多播监听器发现版本 2（MLDv2）”，2004 年

  • RFC 3849，“IPv6 文档地址”，2004 年

  • RFC 3879，“弃用站点本地地址”，2004 年

  • RFC 3956，“在 IPv6 多播地址中嵌入会合点（RP）地址”，2004 年

  • RFC 3972，“加密生成地址（CGA）”，2005 年

  • RFC 4007，“IPv6 范围地址架构”，2005 年

  • RFC 4192，“无需标志日的 IPv6 网络重新编号程序”，2005 年

  • RFC 4193，“唯一本地 IPv6 单播地址”，2005 年

  • RFC 4291，“IPv6 地址架构”，2006 年

  • RFC 4380，“Teredo：通过网络地址转换（NAT）在 UDP 上隧道 IPv6”，2006 年

  • RFC 4489，“生成链路范围 IPv6 多播地址的方法”，2006 年

  • RFC 4581，“加密生成地址（CGA）扩展字段格式”，2006 年

  • RFC 4795，“链路本地多播名称解析（LLMNR）”，2007 年

  • RFC 4941，“IPv6 无状态地址自动配置的隐私扩展”，2007 年

  • RFC 4982，“加密生成地址（CGA）中对多种哈希算法的支持”，2007 年

  • RFC 5156，“特殊用途 IPv6 地址”，2008 年

  • RFC 5214，“站内自动隧道地址协议（ISATAP）”，2008 年

  • RFC 5375，“IPv6 单播地址分配注意事项”，2008 年

  • RFC 5453，“保留的 IPv6 接口标识符”，2009 年

  • RFC 5569，“IPv6 在 IPv4 基础设施上的快速部署（6rd）”，2010 年

  • RFC 5952，“IPv6 地址文本表示的建议”，2010 年

  • RFC 5991，“Teredo 安全更新”，2010 年

  • RFC 6052，“IPv4/IPv6 转换器的 IPv6 地址分配”，2010 年

  • RFC 6081，“Teredo 扩展”，2011 年

  • RFC 6085，“以太网上的 IPv6 多播数据包地址映射”，2011 年

  • RFC 6164，“在路由器间链路上使用 127 位 IPv6 前缀”，2011 年

  • RFC 6177，“IPv6 地址分配给最终站点”，2011 年

  • RFC 6724，“IPv6 默认地址选择”，2012 年

  • RFC 7078，“通过 DHCPv6 分发地址选择策略”，2014 年

  • RFC 7094，“IP Anycast 的架构考虑”，2014 年

  • RFC 7108，“L-Root 部署的各种机制总结，用于识别任何播节点”，2014 年

  • RFC 7136，“IPv6 接口标识符的重要性”，2014 年

  • RFC 7217，“使用 IPv6 无状态地址自动配置（SLAAC）生成语义不透明的接口标识符的方法”，2014 年

草案

草案可以在www.ietf.org/ID.html找到。要查找草案的最新版本，请参考datatracker.ietf.org/public/pidtracker.cgi。你可以输入草案名称而不需要版本号，系统会自动显示最新版本。如果草案没有显示出来，可能是它已经被删除。如果草案已发布为 RFC，RFC 编号会显示出来。tools.ietf.org/wg也是一个非常有用的网站。关于标准化过程、RFC 和草案的更多信息，可以在附录 A 中找到。

这里是我在本章中参考的一些草案列表，以及与本章主题相关的有趣草案：

“IPv6 地址生成机制的隐私考虑”

draft-ietf-6man-ipv6-address-generation-privacy-01

“稳定的 IPv6 接口标识符建议”

draft-ietf-6man-default-iids-00

第三章：IPv6 协议的结构

本章解释了 IPv6 头部的结构，并将其与 IPv4 头部进行了比较。还讨论了 IPv6 中新引入的扩展头部。

理解协议头部的结构以及其中包含的信息类型，是理解协议工作原理的最佳基础。这种理解有助于你识别如何最优配置协议以及有哪些选项。同时，它也帮助你在故障排除时识别潜在的问题和问题源。

IPv6 数据包的头部结构在 RFC 2460 中有详细说明。头部的长度是固定的，为 40 字节。源地址和目的地址各占 16 字节（128 位），因此一般头部信息只剩下 8 字节。因此，基础的 IPv6 头部比 IPv4 头部要简单得多，处理起来也更高效，正如我们稍后所看到的，它在扩展协议以满足未来需求时也更加灵活。

一般头部结构

在 IPv6 中，IPv4 头部的五个字段被移除了：

  • 头部长度

  • 标识符

  • 标志

  • 分段偏移

  • 头部校验和

头部长度字段被移除，因为在一个固定长度的头部中不需要它。在 IPv4 中，最小的头部长度是 20 字节，但如果添加选项，它可以每次增加 4 字节，最多扩展到 60 字节。因此，在 IPv4 中，关于头部总长度的信息是很重要的。在 IPv6 中，选项定义在扩展头部中（在本章后面会讲到）。

标识符、标志和分段偏移字段是 IPv4 头部中用于数据包分段的字段。分段发生在当一个大的数据包必须通过只支持较小数据包大小的网络发送时。在这种情况下，IPv4 路由器会将数据包分割成更小的部分并转发多个数据包。目标主机会收集这些数据包并将它们重新组装。如果只有一个数据包丢失或出现错误，则整个传输必须重新进行；这非常低效。在 IPv6 中，主机通过一种叫做路径 MTU 发现的程序来学习路径最大传输单元（MTU）大小，该程序在 RFC 1981 中定义。在 IPv4 中，不分段位（DF 位）用于路径 MTU 发现。如果路由器由于数据包大小无法转发，并且由于 DF 位被设置而无法进行分段，它会向源节点发送 ICMP“数据包过大”消息。如果发送方的 IPv6 主机希望对数据包进行分段，它将使用扩展头部来实现。IPv6 路由器在数据包的路径上不会像 IPv4 那样提供分段服务。因此，路由器总是向源节点发送“数据包过大”消息。这就是为什么标识符、标志和分段偏移字段被从 IPv6 头部中移除的原因，如果需要，它们将由源主机插入到扩展头部中。我将在本章后面解释扩展头部。

注意

路径 MTU 发现过程将在第四章中进行解释。

头部校验和字段被移除以提高处理速度。如果路由器不需要检查和更新校验和，处理速度将大大提高。在 IPv4 开发时期，媒体接入层的校验和检查并不常见，因此 IPv4 头部中的校验和字段是合理的。今天，未被检测到的错误和错误路由的数据包的风险已经非常低。传输层（UDP 和 TCP）中也有校验和字段。对于 IPv4，UDP 校验和是可选的；而在 IPv6 中，UDP 校验和是必须的。由于 IP 是一个尽力而为的传输协议，因此确保数据完整性的责任属于上层协议。

流量类字段取代了 IPv4 中的“服务类型”字段。IPv6 有不同的机制来处理优先级。IPv4 中的协议类型字段已更名为下一个头部字段，生存时间（TTL）字段已更名为跳数限制字段。还新增了流标签字段。

IPv6 头部字段

通过熟悉 IPv6 头部字段，你将更好地理解 IPv6 的工作原理。

图 3-1 概述了 IPv6 头部。接下来的列表中将详细讨论各个字段。

IPv6 头部字段图 3-1. IPv6 头部字段

图 3-1 显示，即使头部的总大小为 40 字节，是默认 IPv4 头部的两倍长，但实际上它已经进行了精简，因为大部分头部空间被两个 16 字节的 IPv6 地址占据。这样，只有 8 字节的空间用于其他头部信息。

版本（4 位）

这个 4 位字段包含了协议的版本号。在 IPv6 中，该数字为 6。版本号 5 不能使用，因为它已经被分配给了实验性流协议（RFC 1819）。

流量类（1 字节）

该字段取代了 IPv4 中的服务类型字段。它有助于处理实时数据以及任何其他需要特殊处理的数据，发送节点和转发路由器可以利用该字段识别并区分不同类别或优先级的 IPv6 数据包。

RFC 2474《IPv4 和 IPv6 头部中的区分服务字段（DS 字段）定义》解释了如何使用 IPv6 中的流量类字段。RFC 2474 使用DS 字段一词来指代 IPv4 头部中的服务类型字段以及 IPv6 头部中的流量类字段。

注意

有关流量类字段使用的更多信息，请参见第五章.

流标签（20 位）

该字段区分了需要相同处理的数据包，以便促进实时流量的处理。发送主机可以为一系列数据包标记一组选项。路由器跟踪流，并可以更高效地处理属于同一流的数据包，因为它们不需要重新处理每个数据包的头部。流标签和源节点的地址唯一标识该流。不支持流标签字段功能的节点在转发数据包时必须保持该字段不变，在接收数据包时忽略该字段。所有属于同一流的数据包必须具有相同的源和目的 IP 地址。

注意

流标签字段的使用是实验性的，且在写作时仍在 IETF 讨论中。有关更多信息，请参见 第五章.

Payload 长度（2 字节）

该字段指定 负载——即 IP 头部之后携带的数据长度。IPv6 中的计算与 IPv4 中的不同。IPv4 中的长度字段包含 IPv4 头部的长度，而 IPv6 中的 Payload Length 字段仅包含 IPv6 头部之后的数据。扩展头被视为负载的一部分，因此也包含在计算中。

Payload Length 字段有 2 字节，限制了最大数据包负载大小为 64 KB。IPv6 有一个 Jumbogram 选项，在需要时可以支持更大的数据包大小。Jumbogram 选项携带在跳跃-跳跃选项头中（将在本章后面讨论）。只有当 IPv6 节点连接到具有大于 64 KB 的链路 MTU 的链路时，Jumbogram 才是相关的；它们在 RFC 2675 中进行了规范。

下一头（1 字节）

在 IPv4 中，该字段称为协议类型字段，但在 IPv6 中更名，以反映 IP 数据包的新组织结构。如果下一个头部是 UDP 或 TCP，则此字段将包含与 IPv4 中相同的协议编号——例如，TCP 的协议编号是 6，UDP 的协议编号是 17。但如果在 IPv6 中使用了扩展头，则此字段包含下一个扩展头的类型。扩展头位于 IP 头和 TCP 或 UDP 头之间。表 3-1 列出了下一头字段中的可能值。新的 IPv6 相关头部为加粗显示。

表 3-1. 下一头字段中的值

值 描述
0 在 IPv4 头部中：保留并未使用 在 IPv6 头部中：跳跃-跳跃选项头跟随
1 网络控制消息协议（ICMPv4）—IPv4 支持
2 网络组管理协议（IGMPv4）—IPv4 支持
4 IPv4
5 流协议（RFC 1819）
6 TCP
8 外部网关协议（EGP）
9 IGP—任何私有内部网关（由 Cisco 用于其 IGRP）
17 UDP
41 IPv6
43 路由头
44 分片头
45 跨域路由协议（IDRP）
46 资源预留协议（RSVP）
47 通用路由封装（GRE）
50 封装安全负载头
51 身份验证头
58 ICMPv6
59 无下一个头部用于 IPv6
60 目标选项头
88 EIGRP
89103 OSPFPIM
108 IP Payload Compression Protocol
115 第 2 层隧道协议（L2TP）
132 流控制传输协议（SCTP）
135 移动头（移动 IPv6）
140 Shim6（RFC 5533）
143–252 未分配
253, 254 用于实验和测试（RFC 3692）
255 保留

头部类型编号来源于与协议类型编号相同的编号范围，因此不应与其冲突。

注意

请访问www.iana.org/assignments/protocol-numbers查看当前列表。

跳数限制（1 字节）

该字段类似于 IPv4 中的 TTL 字段。最初，IPv4 中的 TTL 字段包含一个秒数，表示数据包在被销毁之前可以在网络中停留的时间。实际上，IPv4 路由器在每次转发时都会将该值减一。为了反映其目的，这个字段在 IPv6 中被更名为跳数限制。该字段中的值表示跳数。每个转发节点将该数字减一。如果路由器接收到一个跳数限制为 1 的数据包，它会将其减为 0，丢弃该数据包，并向发送方发送 ICMPv6 消息“跳数限制在传输中被超越”。

源地址（16 字节）

该字段包含数据包发起者的 IP 地址。

目标地址（16 字节）

该字段包含数据包预期接收者的 IP 地址。这可以是最终目标地址，或者如果例如存在路由头部，则为下一跳路由器的地址。

图 3-2 显示了在跟踪文件中的 IPv6 头部。

IPv6 头部在跟踪文件中的显示图 3-2. IPv6 头部在跟踪文件中的显示

该跟踪文件显示了所有讨论过的头部字段以及它们如何在跟踪文件中呈现。版本字段设置为 6，表示 IPv6。流量类（优先级）和流标签字段在该数据包中未使用，设置为 0。负载长度为 40，下一头部值设置为 58，表示 ICMPv6。跳数限制设置为 128，源地址和目标地址包含我的 IPv6 节点的链路本地地址。详细信息窗口中的第一行显示Ethertype 0x86DD。该值表示这是一个 IPv6 数据包。对于 IPv4，该值将是0x0800。此字段可用于为所有本地 IPv6 数据包设置分析器过滤器。

注意

分析工具可以以不同的方式解码数据包。如果你使用的是另一个版本或其他类型的分析器，解码结果可能会稍有不同。差异不在于数据包本身，而是在分析器界面中数据包的展示方式。

扩展头

IPv4 头可以从最小的 20 字节扩展到最大 60 字节，以指定诸如安全选项、源路由或时间戳等选项。由于会影响性能，这种扩展很少被使用。例如，IPv4 硬件转发实现必须将包含选项的数据包传递给主处理器（由软件处理）。

数据包头越简单，处理速度越快。IPv6 采用了一种新的处理选项的方式，显著提高了处理效率：它通过额外的头（称为 扩展头）来处理选项。只有在需要选项时，扩展头才会被插入到数据包中。而且在大多数情况下，扩展头只会由最终目标处理，而不是由中间设备处理。

当前的 IPv6 规范定义了六个扩展头，这些扩展头必须被所有 IPv6 节点支持：

  • 逐跳选项头

  • 路由头

  • 分片头

  • 目标选项头

  • 认证头

  • 封装安全载荷头

在一个 IPv6 数据包中，可以有零个、一个或多个扩展头。扩展头被放置在 IPv6 头和上层协议头之间。每个扩展头由前一个头中的 Next Header 字段来标识。扩展头只有在 IPv6 头的目标地址字段中标识的节点处才会被检查或处理。如果目标地址字段中的地址是一个组播地址，那么所有属于该组播组的节点都将检查并处理扩展头。扩展头必须严格按照它们在数据包头中出现的顺序进行处理。

关于只有目标节点会处理扩展头的规则，有一个例外。如果扩展头是逐跳选项头，则携带的信息必须由沿着数据包路径的每个节点检查和处理。逐跳选项头（如果存在）必须紧跟在 IPv6 头之后。它通过 IPv6 头中的 Next Header 字段值 0 来指示（参见本章前面的 表 3-1）。

注意

前四个扩展头在 RFC 2460 中有所描述。认证头在 RFC 4302 中有所描述，封装安全载荷头在 RFC 4303 中有所描述。未来扩展头格式的更新已在 RFC 6564 中定义。

该架构非常灵活，可以根据需要开发额外的扩展头以供未来使用。可以定义并使用新的扩展头，而无需更改 IPv6 头部。一个很好的例子是为移动 IPv6（RFC 6275）定义的移动性头，在第八章中讨论。

图 3-3 展示了扩展头的使用方式。

扩展头的使用图 3-3. 扩展头的使用

每个扩展头的长度是八个字节的倍数，以确保后续头可以始终对齐。如果一个节点需要处理下一个头部，但无法识别“下一个头部”字段中的值，则该节点必须丢弃数据包，并向数据包的源发送一个 ICMPv6 参数问题消息。

注释

有关 ICMPv6 消息的详细信息，请参见第四章。

如果在一个数据包中使用了多个扩展头，则应使用以下头部顺序（RFC 2460）：

  1. IPv6 头

  2. 路由逐跳选项头

  3. 目的地选项头（用于由 IPv6 目的地地址字段中的第一个目的地以及路由头中列出的后续目的地处理的选项）

  4. 路由头

  5. 分段头

  6. 认证头

  7. 封装安全有效载荷头

  8. 目的地选项头（仅用于由数据包最终目的地处理的选项）

  9. 上层头

RFC 2460 为解释留出了一些空间。尽管这是推荐的顺序，但 IPv6 节点必须尝试以任何顺序处理扩展头。但仍强烈建议，除非有新的规范修订，否则 IPv6 数据包的源应使用推荐的顺序。

在 IPv6 封装在 IPv4 中的情况下，上层头可以是另一个 IPv6 头，并且可以包含必须遵循相同规则的扩展头。

路由逐跳选项头

路由逐跳选项头携带必须由沿途每个节点检查的可选信息。它必须紧跟在 IPv6 头之后，并由“下一个头部”值为 0 表示。例如，路由器警报（RFC 2711）使用路由逐跳选项头处理像资源预留协议（RSVP）、组播监听器发现（MLD）消息或 Jumbo 数据报选项等协议。对于 IPv4，路由器判断是否需要检查数据报的唯一方法是至少部分解析所有数据报的上层数据。这一过程会显著减缓路由过程。而在 IPv6 中，在没有路由逐跳选项头的情况下，路由器知道不需要处理特定于路由器的信息，可以立即将数据包路由到最终目的地。如果存在路由逐跳选项头，路由器只需检查该头，而无需进一步查看数据包的其他部分。

逐跳选项头的格式见图 3-4。

逐跳选项头的格式图 3-4. 逐跳选项头的格式

以下列表描述了每个字段：

下一个头（1 字节）

下一个头字段标识逐跳选项头之后的头类型。下一个头字段使用表 3-1 中列出的值，如本章前面所示。

扩展头长度（1 字节）

此字段标识逐跳选项头的长度，以八字节为单位。长度计算不包括前八个字节。因此，如果头部小于八字节，则该字段的值为 0。

选项（可变大小）

可以有一个或多个选项。选项的长度是可变的，并由头扩展长度字段决定。

选项类型字段，即选项字段的第一个字节，包含有关在处理节点无法识别选项时应如何处理该选项的信息。前两位的值指定应采取的操作：

  • 00: 跳过并继续处理。

  • 01: 丢弃数据包。

  • 10: 丢弃数据包并向数据包的源地址发送 ICMP 参数问题消息，指向未识别的选项类型。

  • 11: 丢弃数据包并仅向数据包的源地址发送 ICMP 参数问题消息，代码为 2，前提是目标地址不是多播地址。

选项类型字段的第三位指定选项信息是否可以在路由过程中更改（值为 1）或不会更改（值为 0）。

选项类型 Jumbogram

此逐跳选项类型支持 IPv6 Jumbogram 的发送。IPv6 负载长度字段支持最大 65,535 字节的数据包大小。Jumbo Payload 选项（RFC 2675）允许发送更大的数据包。

在带有 Jumbo Payload 选项的数据包的 IPv6 头中，负载长度字段设置为 0。下一个头字段包含值 0，表示这是一个逐跳选项头。选项类型值 194 表示 Jumbo Payload 选项。Jumbo Payload 长度字段有 32 位，因此支持传输大小在 65,536 到 4,294,967,295 字节之间的数据包。RFC 2675 还定义了 UDP 和 TCP 的扩展，这些扩展必须在需要支持发送 Jumbogram 的数据包的主机上实现。路径上的所有设备必须支持此选项。

选项路由器警报

此选项类型指示路由器数据包包含在转发时需要处理的重要信息。该选项目前主要用于 MLD（多播监听发现）和 RSVP（资源预留协议）。它在 RFC 2711 中进行了说明，并已被 RFC 6398 更新。

RSVP 使用控制数据包，包含需要路由器沿路径进行解读或更新的信息。这些控制数据包使用逐跳选项头，因此只有路由器会处理该数据包。常规数据包没有这个扩展头，因此会立即被转发，无需路由器进一步检查。

选项类型字段的前三位设置为 0。一个不认识该选项的路由器会忽略它并转发数据包。在第一个字节的剩余五位中，指定了选项类型 5。选项数据长度字段包含值 2，表示接下来的值字段的长度为两字节（参见图 3-4）。

注意

路由器警告值的列表可以在以下链接找到：www.iana.org/assignments/ipv6-routeralert-values。

图 3-5 展示了跟踪文件中的逐跳选项头。

逐跳选项头在跟踪文件中的展示图 3-5。逐跳选项头在跟踪文件中的展示

截图展示了数据包编号 10 的详细信息。它是一个 MLDv2 多播监听报告消息。如前所述，这些多播注册消息始终具有逐跳选项头（下一头部值为零），因为这是一个路由器不需要转发，但必须处理的信息包。你可以看到 MLD 消息的跳数限制被设置为 1；ff02::16是 MLDv2 路由器的多播地址；逐跳选项头包含下一头部字段，值为 58，表示 ICMPv6；长度字段和路由器警告选项类型为 5，值字段为零，表示 MLD。

路由头

路由头用于提供一个或多个中间节点的列表，这些节点应在数据包到达目标的路径上依次访问。在 IPv4 中，这称为松散源路由选项。路由头通过前一头部中的下一头部值 43 来标识。图 3-6 展示了路由头的格式。

路由头格式图 3-6。路由头格式

以下列表描述了每个字段：

下一头部（1 字节）

下一头部字段标识紧随路由头之后的头部类型。它使用与 IPv4 协议类型字段相同的值（请参见本章前面的表 3-1）。

扩展头长度（1 字节）

该字段标识路由头的长度，单位为 8 字节。长度计算不包括前 8 字节。

路由类型（1 字节）

该字段标识路由头的类型。RFC 2460 描述了路由类型 0，但由于安全原因，该类型已被 RFC 5095 弃用。移动 IPv6 规范定义了路由类型 2。（此规范在第八章中讨论。）在撰写本文时，已有一些草案正在进行中，定义了一种新的段路由架构和一种新的路由头类型，称为段路由头。可以在本章末尾的草案部分找到这些草案的链接。你阅读这些文字时，可能已经知道这个规范是否会被采纳。

剩余段数（1 字节）

该字段标识在数据包到达最终目的地之前，还有多少节点需要访问。

类型特定数据（可变长度）

该字段的长度取决于路由类型。完整的头部总是 8 字节的倍数。

如果处理路由头的节点无法识别路由类型值，则采取的操作取决于“剩余段数”字段的内容。如果“剩余段数”字段不包含任何需要访问的节点，则该节点必须忽略路由头并处理数据包中的下一个头部，该头部由“下一个头部”字段的值决定。如果“剩余段数”字段不为零，则该节点必须丢弃数据包，并向数据包的源地址发送一个 ICMP 参数问题代码 0 消息，指向未识别的路由类型。如果转发节点由于下一个链路的最大传输单元（MTU）大小过小而无法处理数据包，它会丢弃数据包并向数据包源发送 ICMP 数据包过大消息。

图 3-7 显示了跟踪文件中的类型 2 路由头。

跟踪文件中的路由头类型 2图 3-7. 路由头类型 2 在跟踪文件中的显示

要显示类型 2 路由头，我们必须获取一个移动 IPv6 跟踪文件，这是定义该路由头类型的规范。IPv6 头中的“下一个头部”字段显示路由头的值为 43。路由头包含本节前面讨论的字段。下一个头部是一个移动性头部，路由头中的“下一个头部”值为 135。头部长度包含两个 8 字节单元，总长度为 16 字节（一个地址）。剩余段数字段包含值 1，因为在选项字段中有一个地址条目。最后，选项字段列出了家庭地址选项和家庭地址。

注意

请参阅第八章了解路由头如何用于移动性。

有关新的路由头选项的示例，请参阅 RFC 6554，《用于低功耗和低丢包网络（RPL）的源路由 IPv6 路由头》。在低功耗和低丢包网络（LLNs）中，路由器通常内存非常有限，只允许少量默认路由，没有其他目标。该 RFC 定义了源路由头（SRH），严格用于 RPL 路由器之间。

片段头

一个希望发送数据包到 IPv6 目标的 IPv6 主机使用路径 MTU 发现来确定到该目标路径上可以使用的最大数据包大小。如果要发送的数据包大于支持的 MTU，源主机会对数据包进行分片。与 IPv4 不同，在 IPv6 中，路径上的路由器不会对数据包进行分片。分片只发生在发送数据包的源主机处。目标主机负责重组。片段头通过前一个头部中的下一个头部值 44 来识别。片段头的格式如图 3-8 所示。

片段头格式图 3-8. 片段头格式

以下列表描述了每个字段：

下一个头部 (1 字节)

下一个头部字段标识紧跟在片段头之后的头部类型。它使用与 IPv4 协议类型字段相同的值。（参见表 3-1。）

保留字段 (1 字节)

未使用；设置为 0。

片段偏移量 (13 位)

该数据包中的数据相对于原始数据包数据起始位置的 8 字节单位偏移量。

保留字段 (2 位)

未使用；设置为 0。

M 标志 (1 位)

值 1 表示更多片段；值 0 表示最后一个片段。

标识符 (4 字节)

由源主机生成，用以识别属于原始数据包的所有数据包。该字段通常实现为一个计数器，每个需要源主机分片的数据包计数增加 1。

注意

片段头不包含像 IPv4 中的“不分片”字段。因为路由器在 IPv6 中不再进行分片，所以不再需要该字段。只有源主机可以对数据包进行分片。

初始未分片的数据包称为原始数据包。它具有一个不可分片部分，包括 IPv6 头部及任何必须由沿路径到目标节点的节点处理的扩展头（即逐跳选项头）。原始数据包的可分片部分包括任何只需要由最终目标处理的扩展头，以及上层头部和任何数据。图 3-9（RFC 2460）说明了分片过程。

IPv6 片段化图 3-9. IPv6 片段化

原始数据包的不可分段部分出现在每个片段中，接着是片段头部，然后是可分段数据。原始数据包的 IPv6 头部必须稍作修改。长度字段反映的是片段的长度（不包括 IPv6 头部），而不是原始数据包的长度。

目标节点收集所有片段并重新组装它们。片段必须具有相同的源地址和目标地址，并且相同的标识值才能重新组装。如果所有片段在第一个片段之后的 60 秒内没有到达目标，目标将丢弃所有数据包。如果目标已经收到第一个片段（偏移量 = 0），它会向源发送一个 ICMPv6 片段重组超时消息。

图 3-10 显示了一个片段头部。

跟踪文件中的片段头部图 3-10. 跟踪文件中的片段头部

整个片段集由两个数据包组成，第一个数据包如图 3-10 所示。在 IPv6 头部，负载长度字段的值为 1,456，这是片段头部和该单个片段的长度，而不是整个原始数据包的长度。下一个头部字段指定值 44，这是片段头部的值。该字段后面是跳数限制字段、源地址和目标地址。片段头部的第一个字段是下一个头部字段。因为这是一个 ping 请求，它包含 ICMPv6 的值 58。由于这是片段集中的第一个数据包，偏移量字段的值为 0，M 标志设置为 1，表示还有更多片段将到来。标识字段设置为 1，并且在属于该片段集的所有数据包中必须相同。图 3-11 显示了片段集中的第二个数据包。

片段集中的最后一个数据包图 3-11. 片段集中的最后一个数据包

该片段集中的第二个和最后一个数据包的偏移量值为 0x00b5，转换为十进制为 181，即第一个片段的长度。M 标志设置为 0，表示这是最后一个数据包，并通知接收主机开始重组片段。标识字段在两个数据包中都设置为 1。

RFC 2460 中的规范允许重叠片段，这会造成安全问题。RFC 5722《IPv6 重叠片段的处理》解释了这一安全问题，并更新了 RFC 2460，禁止重叠片段。RFC 6980 描述了 IPv6 片段化如何成为安全问题，通过消除 RA Guard 等安全机制的有效性，禁止在传统邻居发现消息中使用 IPv6 片段化。

注意

参见第四章了解邻居发现的描述，参见第六章讨论 RA Guard 及其对片段头部的安全影响。

目的地选项头部

目的地选项头部携带仅由目的地节点（IPv6 头部中的目的地地址）检查的可选信息。一个值为 60 的下一头部标识这种类型的头部。如前所述，目的地选项头部可以在 IPv6 数据包中出现两次。当它插入在路由头部之前时，它包含供路由器处理的信息，这些路由器在路由头部中列出。当它插入在上层协议头部之前时，它包含供数据包最终目的地处理的信息。图 3-12 显示了目的地选项头部的格式。

目的地选项头部的格式图 3-12. 目的地选项头部的格式

如您所见，格式类似于“跳跃选项”头部的格式。以下列表描述了每个字段：

下一头部（1 字节）

下一头部字段标识紧随目的地选项头部的头部类型。它使用表 3-1 中列出的相同值，该表在本章前面已经展示过。

扩展头部长度（1 字节）

该字段标识目的地选项头部的长度，单位为 8 字节。长度计算不包括前 8 个字节。

选项（可变大小）

可以有一个或多个选项。选项的长度是可变的，并由头部扩展长度字段确定。

选项字段的使用方式与“跳跃选项”头部相似，我在本章之前讨论过这个头部。目的地选项头部的一个使用示例是移动 IPv6。您可以在第八章找到有关移动 IPv6 的详细描述。另一个定义的目的地选项头部选项是 RFC 2473 中的隧道封装限制选项，该选项用于限制数据包被进一步封装的次数。

注意

在www.iana.org/assignments/ipv6-parameters/查找最新的路由和目标选项头的定义选项列表。

图 3-13 显示了跟踪文件中的目标选项头。

跟踪文件中的目标选项头图 3-13. 跟踪文件中的目标选项头

为了展示目标选项头，我们再次参考移动 IPv6 跟踪。这是一个绑定更新消息。它在 IP 头的下一个头字段中使用值 60 的目标选项头。目标选项头的下一个头字段值为 135，表示移动 IPv6 消息，并包含家庭地址选项和移动节点的家庭地址。

注意

请参阅第八章，了解目标选项头如何用于移动性。

新扩展头格式

除了逐跳和路由头外，扩展头通常仅由数据包的最终目的地处理。实际上，数据包路径中的设备，如路由器和防火墙，能够以线速解析或忽略扩展头。为了适应现实世界中的实现并优化扩展头的处理和检查，RFC 6564 中定义了一种新的扩展头格式，标题为《IPv6 扩展头的统一格式》。图 3-14 显示了新的格式。

新扩展头格式图 3-14. 新的扩展头格式

以下列表描述了每个字段：

下一个头（1 字节）

下一个头字段标识扩展头之后的头类型。它使用表 3-1 中列出的相同值，表 3-1 在本章前面已经展示。

扩展头长度（1 字节）

该字段标识扩展头的长度，单位为 8 字节。长度计算不包括前 8 个字节。

选项（可变大小）

选项的长度是可变的，并在扩展头长度字段中确定。

本章描述的基本扩展头格式不会改变。但是，如果未来定义新的扩展头，它们必须遵循此格式。这意味着任何处理扩展头的设备，如防火墙，必须能够正确处理基本扩展头，同时也能处理使用新格式的扩展头。

RFC 6564 中定义了几条规则，并在下面总结：

  • 如果可能，应该避免定义新的扩展头，而是为目标选项头定义新的选项。只有在无法做到这一点时，才能定义新的扩展头。

  • 不得创建新的逐跳行为头，并且只有在有限情况下，才应为现有的逐跳选项头创建新选项。

扩展头与头链长度的处理

RFC 2460 中的基础规范规定，扩展头仅由终端节点处理（逐跳选项头除外）。该架构的目标是，新的扩展头可以被引入，并且只有终端节点需要更新。这个过程对路径中的转发节点是透明的。实践表明，这并非总是适用。一些路由器和多种中间设备，如防火墙、负载均衡器和数据包分类器，也被称为中间件，可能会检查超出 IPv6 基础头的 IP 头的其他部分。通常，如果它们不识别某个扩展头，它们会直接丢弃包，这会导致连接失败。此外，逐跳扩展头通常不会被高速路由器处理，或者是在慢路径上处理。

RFC 7045《扩展头的传输与处理》讨论了这些问题。根据基础规范，终端节点应丢弃它们不识别的扩展头，但路径中的转发设备不应这样做。否则，这些转发设备可能会丢弃那些它们尚未识别的带有新定义扩展头的包。RFC 规定，这些设备应该有一个可以单独配置的策略。默认配置应允许所有标准扩展头。对于防火墙，RFC 规定，特别是含有标准扩展头的包，只有在经过故意配置的策略下才会被丢弃。对于逐跳扩展头，要求所有转发设备都应处理它，但实现者需要意识到，这通常发生在慢路径上。

另一个问题是，没有一个单一的地方可以找到所有的扩展头，而且随着新规范的发布，扩展头的数量可能会定期增加。因此，厂商很难确定他们在实现中需要支持哪些扩展头。因此，RFC 定义必须在 IANA（互联网号码分配局）IPv6 参数部分新增一个区域，以列出所有 IPv6 扩展头类型。

注意

新的 IANA 注册表部分可以在 IPv6 扩展头 中找到，链接地址为 bit.ly/1na7H1Q。

关于头链（包括 IPv6 头、任何扩展头和上层协议头），请注意以下事项：在 IPv4 中，我们对 IPv4 数据包中所有 IPv4 选项的大小有固定的上限。在 IPv6 基础规范中，数据包中扩展头的数量没有限制。因此，当数据包被分段时，头链可能会跨越多个片段。这会导致问题，特别是当防火墙无法对片段应用规则时，因为它们需要的信息在第一个片段中缺失。RFC 7112, “超大 IPv6 头链的影响”，描述了这个问题，并更新了 RFC 2460，要求分段数据报的第一个片段必须包含完整的 IPv6 头链。

现在，您已经熟悉了 IPv6 头和扩展头，下一章将介绍 ICMPv6 的高级功能，这些功能提供了 ICMPv4 中没有的管理功能。

参考文献

以下是本章中提到的最重要的 RFC 和草案列表。有时我还会包括一些附加的与主题相关的 RFC，供您个人进一步学习。

RFCs

  • RFC 791, “互联网协议”，1981

  • RFC 1812, “IP 版本 4 路由器要求”，1995

  • RFC 1819, “互联网流协议版本 2”，1995

  • RFC 1981, “IP 版本 6 的路径 MTU 发现”，1996

  • RFC 2460, “互联网协议，第 6 版（IPv6）规范”，1998

  • RFC 2473, “IPv6 中通用数据包隧道化规范”，1998

  • RFC 2474, “区分服务字段（DS 字段）的定义”，1998

  • RFC 2475, “区分服务架构”，1998

  • RFC 2507, “IP 头压缩”，1999

  • RFC 2675, “IPv6 大数据包”，1999

  • RFC 2711, “IPv6 路由器警报选项”，1999

  • RFC 3168, “显式拥塞通知（ECN）添加到 IP 中”，2001

  • RFC 3175, “IPv4 和 IPv6 预留的 RSVP 聚合”，2001

  • RFC 3514, “IPv4 头中的安全标志”，2003 年 4 月 1 日

  • RFC 4301, “互联网协议的安全架构”，2005

  • RFC 4302, “IP 认证头”，2005

  • RFC 4303, “IP 封装安全负载（ESP）”，2005

  • RFC 4305, “封装安全负载（ESP）和认证头（AH）的加密算法实现要求”，2005

  • RFC 4727, “IPv4、IPv6、ICMPv4、ICMPv6、UDP 和 TCP 头中的实验值”，2006

  • RFC 5095, “IPv6 中类型 0 路由头的废弃”，2007

  • RFC 5350, “IPv4 和 IPv6 路由器警报选项的 IANA 考虑”，2008

  • RFC 5722, “重叠 IPv6 片段的处理”，2009

  • RFC 5871, “IPv6 路由头的 IANA 分配指南”，2010

  • RFC 6105, “IPv6 路由器广告保护”，2011

  • RFC 6275, “IPv6 中的移动性支持”，2011

  • RFC 6398, “IP 路由器警报的考虑和使用”，2011

  • RFC 6434, “IPv6 节点要求”，2011

  • RFC 6437, “IPv6 流标签规范”，2011

  • RFC 6553, “低功耗和丢包网络（RPL）协议中用于承载 RPL 信息的数据平面数据报选项”，2012

  • RFC 6554, “用于源路由的 IPv6 路由头，结合低功耗和丢包网络（RPL）协议”，2012

  • RFC 6564, “IPv6 扩展头的统一格式”，2012

  • RFC 6621, “简化的多播转发”，2012

  • RFC 6946, “IPv6 ‘原子’分片的处理”，2013

  • RFC 6980, “IPv6 分片与 IPv6 邻居发现的安全影响”，2013

  • RFC 7045, “IPv6 扩展头的传输和处理”，2014

  • RFC 7112, “超大 IPv6 头链的影响”，2014

  • RFC 7113, “IPv6 路由器广告保护（RA Guard）实施建议”，2014

  • RFC 7136, “IPv6 接口标识符的重要性”，2014

草案

草案可以在 www.ietf.org/ID.html 上找到。要查找草案的最新版本，请参考 datatracker.ietf.org/public/pidtracker.cgi。您可以输入草案名称，不带版本号，最新版本会自动显示。如果草案未显示，可能已经被删除。如果它已发布为 RFC，则会显示 RFC 编号。tools.ietf.org/wg 也是一个非常有用的网站。关于标准化过程、RFC 和草案的更多信息可以在 附录 A 中找到。

这是我在本章中参考的草案列表，以及与本章主题相关的一些有趣草案：

“分段路由架构”

draft-filsfils-spring-segment-routing-02

“分段路由使用案例”

draft-filsfils-spring-segment-routing-use-cases-00

“IPv6 分段路由头（SRH）”

draft-previdi-6man-segment-routing-header-00

第四章：ICMPv6

如果你熟悉 IPv4，互联网控制消息协议（ICMP）对于 IPv4 可能是你的好朋友：它提供有关网络健康的重要信息。ICMPv6 是与 IPv6 配合使用的版本。如果数据包无法正确处理，ICMPv6 会报告错误，并发送有关网络状态的信息消息。例如，如果路由器无法转发数据包，因为数据包太大无法通过另一网络发送，它会发送 ICMP 消息回源主机。源主机可以使用这个 ICMP 消息来确定更好的数据包大小，然后重新发送数据。ICMP 还执行诊断功能，例如著名的 ping，它使用 ICMP 回显请求和回显应答消息来测试节点的可用性。

ICMPv6 比 ICMPv4 更强大，包含新的功能，如本章所述。例如，管理 IPv4 多播组成员的互联网组管理协议（IGMP）功能已被纳入 ICMPv6。同样，IPv4 中用于将链路层地址映射到 IP 地址（反之亦然）的 ARP/RARP（地址解析协议/反向地址解析协议）功能也被纳入其中。引入了邻居发现（ND），它使用 ICMPv6 消息来确定附加到同一链路的邻居的链路层地址，查找路由器，跟踪哪些邻居是可达的，并检测链路层地址的变化。定义了新的消息类型，简化了网络重新编号和主机与路由器之间地址信息更新。ICMPv6 还支持移动 IPv6，详见第八章。ICMPv6 是 IPv6 的一部分，必须由每个 IPv6 节点完全实现。该协议在 RFC 4443 中定义。邻居发现定义在 RFC 4861 中。

一般消息格式

所有 ICMPv6 消息都有相同的一般头部结构，如图 4-1 所示。

一般 ICMPv6 头部格式图 4-1. 一般 ICMPv6 头部格式

类型（1 字节）

该字段指定消息的类型，决定了消息其余部分的格式。表 4-1 和 4-2 列出了 ICMPv6 的消息类型和编号。

代码（1 字节）

代码字段依赖于消息类型，并在某些情况下提供更详细的信息。有关详细列表，请参考表 4-1 和 4-2。

校验和（2 字节）

校验和字段用于检测 ICMPv6 头部和部分 IPv6 头部中的数据损坏。为了计算校验和，节点必须确定 IPv6 头部中的源地址和目标地址。校验和计算中包括一个伪头部，这是 ICMPv6 新增的内容。第五章讨论了校验和和伪头部。

消息体（可变大小）

根据类型和代码，消息体将包含不同的数据。对于错误消息，为了帮助故障排除，它将尽可能包含触发该消息的数据包。ICMPv6 数据包的总大小不应超过最小 IPv6 MTU，即 1280 字节。表 4-1 和表 4-2 提供了不同消息类型的概述，以及取决于消息类型的附加代码信息。

ICMP 消息分为两类：

ICMP 错误消息

错误消息在其消息类型字段的高阶位上有一个 0。因此，ICMP 错误消息类型的范围为 0 到 127。

ICMP 信息性消息

信息性消息在其消息类型字段的高阶位上有一个 1。因此，ICMP 信息性消息类型的范围为 128 到 255。

每个 ICMPv6 消息前面都有一个 IPv6 头部和零个或多个扩展头部。紧接 ICMP 头部之前的头部的“下一个头部”值为 58。这个值与 ICMPv4 的值不同（ICMPv4 的值为 1）。

注意

下一个头部字段的值在第三章中有讨论。

以下消息类型在 RFC 4443 中有描述：

ICMPv6 错误消息

  • 目标不可达（消息类型 1）

  • 数据包过大（消息类型 2）

  • 时间超限（消息类型 3）

  • 参数问题（消息类型 4）

ICMPv6 信息性消息

  • 回显请求（消息类型 128）

  • 回显应答（消息类型 129）

注意

对于最新的 ICMPv6 消息类型列表，请参考互联网分配号码管理局（IANA）网站：www.iana.org/assignments/icmpv6-parameters。所有 IPv4 ICMP 参数可在www.iana.org/assignments/icmp-parameters找到。

表 4-1. ICMPv6 错误消息和代码类型

消息编号 消息类型 代码字段
1 目标不可达 0 = 无路由到目标1 = 与目标的通信被管理禁止2 = 超出源地址范围3 = 地址不可达4 = 端口不可达5 = 源地址未通过入口/出口策略6 = 拒绝路由到目标7 = 源路由头部出错
2 数据包过大 代码字段由发送方设置为 0，接收方忽略
3 超时 0 = 路由跳数限制超出1 = 分片重组时间超出
4 参数问题 0 = 遇到错误的头字段1 = 遇到无法识别的下一个头类型2 = 遇到无法识别的 IPv6 选项。指针字段标识调用数据包中发现错误的字节偏移位置。如果错误字段超出了 ICMPv6 错误消息最大大小的范围，指针将指向超出 ICMPv6 包末尾的位置。
100 和 101 私有实验 RFC 4443
127 保留用于扩展 ICMPv6 错误消息 RFC 4443

请注意，消息编号和类型相比于 ICMPv4 有了显著变化。ICMP for IPv6 是一个不同的协议，两个版本的 ICMP 不兼容。您的分析工具，如 Wireshark，应该能够正确解码所有这些信息，因此您不必担心记住它们。

表 4-2。ICMPv6 信息消息

消息编号 消息类型 描述
128 回显请求 RFC 4443。用于 ping 命令。
129 回显回复
130 多播监听器查询 RFC 2710。用于多播组管理。
131 多播监听器报告
132 多播监听器完成
133 路由器请求 RFC 4861。用于邻居发现和自动配置。
134 路由器通告
135 邻居请求
136 邻居通告
137 重定向消息
138 路由器重编号 RFC 2894。代码：0 = 路由器重编号命令1 = 路由器重编号结果255 = 序列号重置
139 ICMP 节点信息查询 RFC 4620
140 ICMP 节点信息响应
141 反向 ND 请求 RFC 3122
142 反向 ND 通告消息 RFC 3122
143 版本 2 多播监听器报告 RFC 3810
144 ICMP 主机代理地址发现请求消息 RFC 6275，“移动 IPv6 的 ICMPv6 消息”
145 ICMP 主机代理地址发现回复消息
146 ICMP 移动前缀请求消息
147 ICMP 移动前缀通告消息
148 认证路径请求消息 RFC 3971 “安全邻居发现的 ICMPv6 消息”
149 认证路径通告消息
151 多播路由器通告 RFC 4286
152 多播路由器请求
153 多播路由器终止
154 快速移动 IPv6 消息 RFC 5568
155 低功耗网络消息的路由协议 RFC 6550
156 ILNPv6 定位器更新消息 RFC 6743
157 重复地址请求 RFC 6775（6LoWPANs）
158 重复地址确认
200 和 201 私有实验 RFC 4443
255 保留用于扩展 ICMPv6 信息消息 RFC 4443

除了路由器重新编号消息（138）外，ICMPv6 信息消息不使用 Code 字段。因此，该字段被设置为零。

正如你将在接下来的段落中学习到的，ICMPv6 非常强大，广泛应用于许多对于 IPv6 正常工作至关重要的过程，例如路径 MTU 发现。因此，像许多 IPv4 网络中那样完全过滤所有 ICMP 消息的做法并不明智。在 ICMPv6 中，你必须仔细评估哪些 ICMPv6 消息是重要的。RFC 4890《防火墙中 ICMPv6 消息过滤的建议》讨论了这一点，并提出了建议。

ICMP 错误消息

每个 ICMP 消息的头部可能略有不同，具体取决于它所携带的错误报告或信息类型。以下部分概述了每种 ICMPv6 消息类型的结构。

目标不可达

如果 IP 数据报无法送达，将生成一个目标不可达消息。Type 字段的值为 1，用于标识此消息。ICMP 消息会发送到发起数据包的源地址。目标不可达消息的格式如图 4-2 所示。

目标不可达消息的格式图 4-2. 目标不可达消息的格式

Type 字段被设置为 1，这是目标不可达消息的值。Code 字段提供了更多有关数据报未送达原因的信息。可能的代码列在表 4-3 中。ICMP 消息的数据部分包含尽可能多的原始消息内容，以适应 ICMP 消息的大小。

表 4-3. 目标不可达消息（类型 1）的代码值

Code 描述
0 “没有到目的地的路由。”如果路由器无法转发数据包，因为它的路由表中没有目标网络的路由，则使用此代码。这种情况只有在路由器没有默认路由条目时才会发生。
1 “与目标的通信被管理员禁止。”例如，如果防火墙无法将数据包转发到防火墙内部的主机，因为有数据包过滤器，则可能会发送此类型的消息。如果某个节点配置为不接受未经认证的 Echo 请求，也可能会发送此消息。
2 “超出源地址的范围。”如果目标地址超出了源地址的范围，例如，数据包的源地址是链路本地地址，目标地址是全局地址，则使用此代码。
3 “地址不可达。”如果目标地址无法解析为相应的网络地址，或者由于数据链路层问题导致节点无法到达目标网络，则使用此代码。
4 “端口不可达。”如果传输协议（例如 UDP）没有监听器，并且没有其他方式通知发送方，则使用此代码。例如，如果向主机发送域名系统（DNS）查询，而 DNS 服务器未运行，则会生成此类型的消息。
5 “源地址未通过入口/出口策略。”如果由于入口或出口过滤策略，某个数据包的源地址不被允许，则使用此代码。
6 “拒绝到目标的路由。”如果到目标的路由是拒绝路由，则使用此代码。

如果由于拥塞导致目标不可达，则不会生成 ICMP 消息。收到 Destination Unreachable 消息的主机必须通知上层进程。

Packet Too Big

如果路由器无法转发数据包，因为它大于出站链路的 MTU，它将生成一个 Packet Too Big 消息（如图 4-3 所示）。此 ICMPv6 消息类型作为路径 MTU 发现过程的一部分，我将在本章后续部分中讨论。ICMP 消息将发送到发起数据包的源地址。

Packet Too Big 消息的格式图 4-3. Packet Too Big 消息的格式

Type 字段的值为 2，表示 Packet Too Big 消息。在这种情况下，Code 字段不被使用，设置为 0\。该类型消息的重要信息是 MTU 字段，它包含下一跳链路的 MTU 大小。

RFC 4443 规定，对于具有 IPv6 多播目的地址、链路层多播地址或链路层广播地址的数据包，不应生成 ICMPv6 消息作为响应。Packet Too Big 消息是这一规则的例外。因为 ICMP 消息包含下一跳链路的支持 MTU，源主机可以确定它应该用于进一步通信的 MTU。接收到 Packet Too Big 消息的主机必须通知上层进程。

Time Exceeded

当路由器转发数据包时，它会将跳数限制减 1。跳数限制确保数据包不会在网络中无休止地传播。如果路由器收到一个跳数限制为 1 的数据包，并将跳数限制减至 0，它会丢弃该数据包，生成一个代码值为 0 的 Time Exceeded 消息，并将该消息发送回源主机。此错误可能表明存在路由环路，或者发送方的初始跳数限制过低。它还可以告诉你某人使用了traceroute工具，该工具将在本章后续部分中描述。图 4-4 展示了 Time Exceeded 消息的格式。

Time Exceeded 消息的格式图 4-4. Time Exceeded 消息的格式

Type 字段的值为 3，指定 Time Exceeded 消息。Code 字段可以设置为 0，表示跃限在传输过程中超出，或者设置为 1，表示片段重组超时。ICMP 消息的数据部分包含尽可能多的原始消息内容，具体取决于使用的 MTU。

一个传入的 Time Exceeded 消息必须传递给上层进程。表 4-4 显示了 Time Exceeded 消息的 Code 字段。

表 4-4. Time Exceeded 消息（类型 3）的代码值

代码 描述
0 “跃限超出传输。”可能的原因：初始跃限值过低；存在路由循环；或使用了 traceroute 工具。
1 “片段重组超时。”如果使用片段头发送了一个分片数据包（更多细节参见 第二章），且接收主机未能在规定时间内完成重组所有数据包，它会通过发出此 ICMP 消息通知发送方。

“跃限超出传输”消息类型通常用于执行 traceroute 功能。Traceroute 有助于确定数据包在网络中传输的路径。为了实现这一点，首先发送一个跃限为 1 的数据包。路径中的第一个路由器将跃限减至 0，丢弃数据包，并返回 ICMP 类型 3，代码 0 的消息。源主机现在知道了第一个跃点路由器的地址。接下来，它发送第二个跃限为 2 的数据包。该数据包由第一个路由器转发，路由器将跃限减至 1。路径中的第二个路由器将跃限减至 0，丢弃数据包，并返回 ICMP 类型 3，代码 0 的消息。现在源主机知道了路径中的第二个路由器。通过增加跃限（每发送一个数据包直到到达最终目的地），继续这一过程。每个到达最终目的地的路由器都会向源主机发送 ICMP 消息，提供其 IP 地址。需要注意的是，如果存在冗余的路径到达目的地，traceroute 不一定会为所有测试显示相同的路径，因为它可能会选择不同的路径。

参数问题

如果 IPv6 节点因无法识别 IPv6 头或扩展头中的某个字段而无法完成数据包处理，它必须丢弃该数据包，并应向问题数据包的源发送 ICMP 参数问题消息。这种类型的消息通常在遇到无法归类为其他类型的错误时使用。此 ICMP 消息的格式如 图 4-5 所示。

参数问题消息格式图 4-5. 参数问题消息格式

Type 字段的值为 4，指定为参数问题消息。Code 字段可以包含 表 4-5 中描述的三种值中的任何一种。Pointer 字段标识在原始数据包中检测到错误的字节位置。ICMP 消息包括尽可能多的原始数据，直到最小的 IPv6 MTU。指针可能指向 ICMPv6 消息之外的地方。如果发生这种情况，说明错误字段超出了 ICMPv6 错误消息的最大大小能够容纳的范围。

表 4-5 显示了参数问题消息的代码字段。

表 4-5. 参数问题的代码值（类型 4）

代码 描述
0 遇到错误的头部字段
1 遇到无法识别的下一个头部类型
2 遇到无法识别的 IPv6 选项

例如，一个类型为 4、代码值为 1、指针设置为 40 的 ICMPv6 消息表示在 IPv6 头部后的头部中的下一个头部类型未被识别。

一个传入的参数问题消息必须传递给上层进程。

ICMP 信息性消息

在 RFC 4443 中，定义了两种类型的信息性消息：回显请求和回显应答消息。其他 ICMP 信息性消息用于路径 MTU 探测和邻居发现。这些消息将在本章末尾讨论，并在 RFC 4861《IPv6 邻居发现》和 RFC 1981《IPv6 路径 MTU 探测》中定义。

回显请求和回显应答消息用于最常见的 TCP/IP 工具之一：网络探测器（ping）。Ping 用于确定指定的主机是否在网络上可用，并准备好进行通信。源主机向指定的目的地发送回显请求消息。如果目标主机可用，它将以回显应答消息进行响应。图 4-8 和 4-9（在本章后面）展示了 ping 在跟踪文件中的表现。

回显请求消息

回显请求消息的格式显示在 图 4-6 中。

回显请求消息格式图 4-6. 回显请求消息格式

Type 字段被设置为 128，这是 Echo Request 的值。Code 字段在此消息中未使用，因此设置为 0。Identifier 和 Sequence Number 字段用于匹配请求和回复。回复必须始终包含与请求相同的数字。是否使用标识符和序列号，以及 Echo Request 中包含何种任意数据，取决于你使用的 TCP/IP 栈。当你分析包含 Echo Request 和 Echo Reply 消息的跟踪文件，并且熟悉某些栈时，你可以通过查看任意数据来确定发送方的 TCP/IP 栈。

Echo Reply

Echo Reply 消息的格式与 Echo Request 非常相似，如 图 4-7 所示。

Echo Reply 消息的格式图 4-7. Echo Reply 消息的格式

Type 字段包含 129 的值，表示 Echo Reply。Code 字段未使用，设置为 0。Identifier 和 Sequence Number 字段必须与请求中的字段匹配。Echo Request 消息的数据必须完全且未修改地复制到回复中。如果是上层进程发起了 Echo Request，则回复必须传递给该进程。如果 Echo Request 消息发送到了单播地址，则 Echo Reply 消息的 Source 地址必须与 Echo Request 消息的 Destination 地址相同。如果 Echo Request 是发送到 IPv6 多播地址，则 Echo Reply 的 Source 地址必须是接收到多播 Echo Request 的接口的单播地址。

根据规范，ICMPv6 Echo Request 和 Reply 消息可以通过 IPv6 认证头进行认证。这意味着节点可以配置为忽略未认证的 ICMPv6 Ping，并提供保护以防范各种 ICMPv6 攻击。不过，我并不知道有哪个实现支持这个功能。

处理规则

有若干规则规范 ICMP 数据包的处理。这些规则可以在 RFC 4443 中找到，概要如下：

  • 如果节点收到类型未知的 ICMPv6 错误消息，则必须将其传递给上层。

  • 如果节点收到类型未知的 ICMPv6 信息消息，则必须静默丢弃。

  • 尽可能多的导致 ICMP 错误消息的数据将包含在 ICMP 消息体中。ICMP 数据包不应超过最小的 IPv6 MTU。

  • 如果错误消息必须传递给上层协议，则协议类型通过从原始数据包中提取（位于 ICMPv6 错误消息的正文中）来确定。如果无法在 ICMPv6 消息的正文中找到协议类型（因为原始数据包中存在太多扩展头，并且包含上层协议类型的部分头被截断），则 ICMPv6 消息会被静默丢弃。

在以下情况下不得发送 ICMPv6 错误消息：

  • 由于收到 ICMPv6 错误消息。

  • 由于收到 ICMPv6 重定向消息。

  • 由于发送到 IPv6 多播地址的数据包。此规则有两个例外：用于路径 MTU 探测的“数据包过大”消息，以及具有代码值 2 的未识别 IPv6 选项的参数问题。

  • 由于作为链路层组播发送的数据包（前面描述的例外情况适用）。

  • 由于作为链路层广播发送的数据包（前面描述的例外情况适用）。

  • 由于源地址不能唯一标识单个节点的数据包。这可能是一个 IPv6 未指定地址、IPv6 多播地址或已知为单播地址的 IPv6 地址。

每个 IPv6 节点必须实现速率限制功能，限制其发送 ICMPv6 消息的速率，并且应该是可配置的。如果该功能得当实施，可以防止拒绝服务攻击。

跟踪文件中的 ICMPv6 头部

阅读完所有这些枯燥的信息后，你值得看到一些不同的内容。以下屏幕截图（图 4-8）展示了 ping 在跟踪文件中的样子，并提供了迄今为止讨论的许多字段的详细信息。

跟踪文件中的 Echo Request图 4-8. 跟踪文件中的 Echo Request

如第三章所示，IPv6 头部提供以下信息：版本字段设置为 6，表示这是一个 IPv6 数据包。优先级和流标签未配置，设置为零。有效负载长度字段设置为 40 字节。下一个头部字段的值为 58，表示 ICMPv6 的值。跳数限制设置为 64。我们还可以看到源和目的地 IP 地址。前缀 fe80: 表示这两个地址是链路本地地址。

请注意 ICMPv6 头部的前三个字段。它们是每个 ICMPv6 消息共有的字段：类型、代码和校验和字段。类型字段的值为 128，表示 Echo Request。标识符和序列号字段是 Echo Request 和 Echo Reply 消息特有的。标识符在此情况下未使用，发送方将序列号设置为 38。在以下屏幕截图中，匹配的回复中的序列号必须相同。数据字段包含任意数据，不需要对任何人有意义。

哦，我差点忘了，我之前承诺在 Echo Request 消息中显示供应商堆栈相关数据。你在这里看到的——字母表直到字母“w”——是微软使用的内容。每当你在跟踪文件中看到这一点时，表示是微软的堆栈在发送请求。图 4-9 详细展示了 Echo Reply。

跟踪文件中的回显回复图 4-9. 跟踪文件中的回显回复

同样，IPv6 头部显示 IP 版本值为 6，ICMPv6 的下一个头部值为 58。前一帧的目标地址现在是源地址，前源地址现在是目标地址。ICMPv6 头部中的类型字段显示值 129，这是回显回复的值。标识符和序列号字段，以及数据字段，与回显请求中的值相匹配。

邻居发现

邻居发现（ND）在 RFC 4861 中进行了规范。该 RFC 中的规范与 IPv4 中已知的不同协议和过程相关，这些协议和过程已被修改和改进。还增加了新功能。它将地址解析协议（ARP）和 ICMP 路由器发现与重定向结合在一起。IPv4 中没有办法检测邻居是否可达。通过邻居发现协议，定义了邻居不可达检测（NUD）机制。重复 IP 地址检测（DAD）也已实现。IPv6 节点使用邻居发现进行以下操作：

  • 用于 IPv6 地址的无状态自动配置

  • 用于确定网络前缀、路由和其他配置信息

  • 用于重复 IP 地址检测（DAD）

  • 用于确定同一链路上节点的二层地址

  • 查找能够转发其数据包的邻近路由器

  • 跟踪哪些邻居可达，哪些不可达（NUD）

  • 检测链路层地址的变化

可以注意到，IPv4 协议集相比有以下改进：

  • 路由器发现现在是基础协议集的一部分。使用 IPv4 时，机制需要从路由表或 DHCP 获取信息。

  • 路由器广告包包含路由器的链路层地址。接收路由器广告的节点无需像 IPv4 节点那样发送额外的 ARP 请求来获取路由器接口的链路层地址。ICMPv6 重定向消息也是如此；它们包含新下一跳路由器接口的链路层地址。

  • 路由器广告包包含链路的前缀（子网信息）。不再需要配置子网掩码；可以从路由器广告中学习这些信息。

  • 邻居发现（ND）提供了更轻松重新编号网络的机制。可以引入新的前缀和地址，同时旧的前缀和地址仍在使用，旧的可以逐步弃用和移除。

  • 路由器广告启用无状态地址自动配置，并能告知主机何时使用有状态地址配置（例如，DHCP）。

  • 路由器可以广告链路上要使用的最大传输单元（MTU）。

  • 一个链路可以分配多个前缀。默认情况下，主机从路由器学习所有前缀，但路由器可以配置为不通告某些或所有前缀。在这种情况下，主机会假设未通告的前缀目标是远程的，并将数据包发送到路由器。路由器随后可以根据需要发送 ICMP 重定向消息。

  • 邻居不可达检测（NUD）是基础协议的一部分。在路由器故障或链路接口更改其链路层地址的情况下，它显著提高了数据包传递的可靠性。它解决了过时的 ARP 缓存问题。NUD 能够检测到连接失败，数据流量不会发送到不可达的邻居。邻居不可达检测还可以检测到故障的路由器，并切换到正常工作的路由器。

  • 路由器通告和 ICMP 重定向使用链路本地地址来标识路由器。这使得主机即使在重新编号或使用新的全局前缀的情况下，仍能保持与路由器的关联。

  • 邻居发现消息的跃点限制值为 255，跃点限制较低的请求将不会得到响应。这使得邻居发现能够抵御试图潜入链路的远程主机，因为它们的数据包跃点限制已被递减，从而被忽略。

  • 标准的 IP 认证和安全机制可以应用于邻居发现。

本总结概述了该部分规范的预期内容。接下来，我们将详细讨论不同的过程。邻居发现协议包括五种 ICMP 消息：一对路由器请求/路由器通告消息、一对邻居请求/邻居通告消息，以及一条 ICMP 重定向消息（有关 ICMP 信息性消息类型的摘要，请参考本章前面的表 4-2）。

总结来说，邻居发现协议（NDP）规范同时由主机和路由器使用。其功能包括邻居发现（ND）、路由器发现（RD）、无状态地址自动配置（SLAAC）、地址解析、邻居不可达检测（NUD）、重复地址检测（DAD）和重定向。

邻居发现存在操作性问题，在网络扫描时可能导致漏洞。RFC 6583《操作性邻居发现问题》描述了这些问题，并提出了可能的缓解技术。

路由器请求和路由器通告

路由器定期发送路由器通告消息。主机可以通过发送路由器请求消息来请求路由器通告。这会触发路由器立即发送路由器通告，跳过常规的时间间隔。格式如图 4-10 所示。

路由器请求消息图 4-10. 路由器请求消息

在路由器请求消息的 IP 头中，你通常会看到ff02::2的所有路由器多播地址作为目的地址。跳数限制设置为 255。ICMP 类型字段设置为 133，这是路由器请求消息的值。代码字段未使用，设置为 0。接下来的两个字节用于校验和。接下来的四个字节未使用，并且保留以供将来使用。发送方将它们设置为 0，接收方忽略这些字段。对于路由器请求消息，一个有效的选项是发送主机的链路层地址，如果已知发送主机的地址。如果 IP 层的源地址是未指定（全零）地址，则此字段不使用。未来版本的 ND 可能会定义更多选项。如果主机无法识别某个选项，它应忽略该选项并处理数据包。

接收到此请求消息的路由器会回复路由器广告消息。路由器还会定期发送这些消息。路由器广告消息的格式如图 4-11 所示。

路由器广告消息图 4-11. 路由器广告消息

通过检查路由器广告消息的 IP 头，你可以判断此路由器广告是周期性发送的，还是作为对请求消息的回复。周期性广告的目的地址将是所有节点的多播地址ff02::1。请求广告的目的地址将是发起请求消息的接口地址。再次说明，跳数限制设置为 255。

ICMP 类型字段设置为 134，这是路由器广告消息的值；代码字段未使用，设置为 0。当前跳数限制字段可用于为链路上的所有节点配置默认跳数限制。此字段中输入的值将作为所有链路上节点在传出数据包中的默认跳数限制值。如果此字段中的值为 0，则表示此路由器未指定此选项——在这种情况下，源主机的默认跳数限制值将被使用。

接下来的 1 位字段，M 标志，指定是否使用有状态配置。有状态配置指的是 DHCPv6。如果此位为 0，则链路上的节点使用无状态地址自动配置（SLAAC）。如果该位设置为 1，则指定使用有状态自动配置（DHCPv6）。O 标志配置链路上的节点是否使用 DHCPv6 来获取 IP 地址以外的信息。值为 1 表示链路上的节点使用 DHCPv6 来获取与地址无关的信息。在这种情况下，DHCPv6 客户端会发送 DHCPv6 信息请求消息，以获取额外的配置选项。移动 IPv6 规范（RFC 6275）定义了第三个位，即主地址标志（H-Flag）。当路由器将 H 标志设置为 1 时，表示它是该链路的主机代理。

请注意，DHCPv6 RFC 留有解释空间。不同操作系统可能会对这两个标志作出稍有不同的响应行为。有一份名为“DHCPv6/SLAAC 地址配置交互问题陈述”的草案，描述了这些问题，并讨论了在实验室中对多个桌面操作系统进行测试的结果。

注释

有关移动 IPv6 和主机代理的讨论，请参考第八章。

接下来的两个比特由路由器通告消息的可选扩展使用，该扩展允许路由器通告偏好和更具体的路由。这样，主机就可以在接收到多个路由器通告时选择最佳路由器。这对于多宿主路由器尤为重要，随着 IPv6 网络的发展，多宿主路由器将变得越来越重要。该扩展使用路由器通告中的 H-Flag 后面的两个比特作为偏好标志，并定义了路由信息选项。该扩展在 RFC 4191 中有详细说明。本字节的剩余三个比特保留供将来使用，必须设置为 0。

Router Lifetime 字段仅在此路由器作为链路上节点的默认路由器时才重要。值为 0 表示该路由器不是默认路由器，因此不会出现在接收节点的默认路由器列表中。该字段的其他任何值表示此路由器作为默认路由器的生存时间（以秒为单位）。最大值为 18.2 小时。

Reachable Time 字段表示主机在接收到可达性确认后，认为邻居可达的时间。值为 0 表示未指定。邻居不可达性检测算法使用此字段。

Retrans Timer 字段由地址解析和邻居不可达性检测机制使用；它表示重传邻居请求消息之间的时间（以毫秒为单位）。值为 0 表示此路由器未配置重传定时器。

对于选项字段，目前有三种可能的值：

  • 源链路层地址。

  • 用于具有可变 MTU 大小的链路（例如令牌环）的 MTU 大小。

  • 前缀信息，对于无状态地址自动配置至关重要。路由器插入它在链路上需要通知节点的所有前缀。

在 ND 的未来版本中，可能会定义更多选项。本章稍后的跟踪文件显示了这些选项的样子。

注释

路由器通告欺骗是一种安全隐患，也称为恶意 RA。相关问题和缓解技术在邻居发现问题部分以及第六章中的安全内容中进行了讨论。

邻居请求和邻居通告

这对消息履行了两个功能：链路层地址解析，这是 IPv4 中 ARP 处理的内容，以及邻居不可达性检测机制。如果目标地址是多播地址（通常是请求节点多播地址），则源正在解析链路层地址。如果源正在验证邻居的可达性，则目标地址是单播地址。此消息类型也用于重复 IP 地址检测（DAD）。

邻居请求消息的格式如 图 4-12 所示。

邻居请求消息的格式图 4-12. 邻居请求消息的格式

在此消息类型的 IP 头中，源地址可以是发起主机的接口地址，或者在 SLAAC 和 DAD 的情况下，未指定的（全零）地址。跳数限制设置为 255。ICMP 头中的 Type 字段设置为 135，Code 字段未使用，设置为 0。两个校验和字节之后，保留了四个未使用的字节，必须设置为 0。目标地址用于邻居广告和重定向消息。它不能是多播地址。

Options 字段可以包含链路层源地址，但只有当它不是从全零地址发送时才会如此。在无状态地址自动配置过程中，如果消息使用未指定地址作为源地址，则 Options 字段设置为 0。链路层选项必须在多播请求（链路层地址检测）中使用，也可以在单播请求（不可达性检测）中使用。

邻居广告消息作为对邻居请求消息的回复发送，或快速传播新信息。消息的格式如 图 4-13 所示。

邻居广告消息的格式图 4-13. 邻居广告消息的格式

IP 头中的地址类型指示该消息是对请求的回答还是非请求消息。对于请求的广告，目标 IP 地址是发送请求的接口的源地址。如果消息是对来自未指定源地址的 DAD 消息的回复，则回复将发送到 ff02::1 的所有节点多播地址。所有非请求的周期性广告也是如此。

ICMP 头中的 Type 字段被设置为 136，这是邻居广告消息的值。Code 字段未使用，设置为 0。当 Router 标志被设置时，发送者是路由器。

当设置了“请求标志”（Solicited flag）时，消息是响应邻居请求（Neighbor Solicitation）发送的。例如，如果主机确认其可达性以响应不可达性检测消息，则设置 S 位。在多播广告中，S 位不会被设置。Override 标志表示广告消息中的信息应覆盖现有的邻居缓存条目，并更新任何缓存的链路层地址。如果未设置 O 位，广告将不会更新缓存的链路层地址，但会更新没有链路层地址的现有邻居缓存条目。O 位不应在任何播地址的广告中设置。稍后我会在本章中讨论缓存条目。剩余的 29 位保留供将来使用，设置为 0。

在请求广告中，目标地址包含发送请求的接口的地址。在无请求广告中，该字段包含链路层地址已更改的接口的地址。选项字段的一个可能选项是目标链路层地址。

表 4-6 帮助你识别所看到的内容，并总结了不同的处理过程。

表 4-6. ND 消息识别

源地址 目标地址 消息类型
全零（::） 全路由器多播 Solicited 节点多播 SLAACDAD
单播 请求节点多播单播 解析链路层地址不可达性检测

ICMP 重定向消息

路由器发送 ICMP 重定向消息，告知节点更好的第一跳节点以到达给定目标。重定向消息还可以告知节点，所用目标实际上是同一链路上的邻居，而不是远程子网中的节点。ICMPv6 重定向消息的格式见图 4-14。

ICMP 重定向消息格式图 4-14. ICMP 重定向消息的格式

IP 头中的源地址必须是发送消息的接口的链路本地地址。IP 头中的目标地址是触发重定向消息的数据包的源地址。跳数限制设置为 255。

目标地址字段包含该接口的链路本地地址，该接口是为给定目标地址选择的更好的下一跳。目标地址字段包含被重定向的目的地址。如果目标地址字段中的地址与目的地址字段中的地址相同，则目标是邻居而非远程节点。选项字段包含目标（最佳下一跳路由器）的链路层地址（如果已知）。这是对 IPv4 版本的改进，在 IPv4 中，主机需要发出单独的 ARP 请求以确定下一跳路由器的链路层地址。选项字段中的其余位包含尽可能多的重定向头部，直到适应最小的 IPv6 MTU（1,280 字节）。

逆邻居发现

逆邻居发现（IND）是对邻居发现（ND）的扩展。它最初为帧中继网络设计，但也可以用于具有类似需求的其他网络。IND 在 RFC 3122 中进行了规范。它由两条消息组成：IND 请求消息和 IND 广告消息。这些消息用于确定已知链路层地址的主机的 IPv6 地址。IND 对应于 IPv4 中使用的反向地址解析协议（RARP）。这些消息的格式与 ND 消息相同。IND 请求消息的消息类型为 141，IND 广告消息的消息类型为 142。代码字段始终设置为 0。

选项字段的格式与 ND 消息中的格式相同，并包含相同的选项。定义了两个新的 IND 特定选项。选项类型 9 定义了源地址列表；选项类型 10 定义了目标地址列表（参见表 4-7 中的概述）。

源地址列表——选项类型 9

一个或多个接口的 IPv6 地址列表，该列表在源链路层地址选项中指定。

目标地址列表——选项类型 10

接口的所有 IPv6 地址列表，该列表在目标链路层地址列表中指定。

当主机想要确定已知链路层地址的接口的 IPv6 地址时，它会向全节点组播地址发送 IND 请求消息。在链路层，该消息会直接发送到相关接口。目标接口会回复一条 IND 广告消息，包含目标地址列表。如果接口具有比单个广告消息能容纳更多的 IPv6 地址，则必须发送多个 IND 广告消息。与所有其他 ND 消息一样，跳数限制被设置为 255，跳数限制低于 255 的消息必须被忽略。

邻居发现选项

邻居发现消息包含一个可变大小的选项字段，其格式如图 4-15 所示。

选项字段格式图 4-15. 选项字段格式

类型字段表示后续的选项类型。表 4-7 显示了不同选项的概览以及它们使用的消息类型。

长度字段表示选项的长度。此字段的值为 0 时无效，带有此值的数据包必须被丢弃。长度的计算包括类型字段和长度字段。

表 4-7. ND 选项概览

选项类型 RFC 使用场景
类型 1 源链路层地址 RFC 4861 邻居请求路由器请求路由器广告 IND 请求/广告
类型 2 目标链路层地址 RFC 4861 邻居广告 重定向 IND 请求/广告
类型 3 前缀 RFC 4861 路由器广告
类型 4 重定向头 RFC 4861 重定向
类型 5 MTU RFC 4861 路由器广告 IND 请求/广告
类型 7 广告间隔 RFC 6275 路由器广告（移动 IPv6）
类型 8 主机代理信息 RFC 6275 路由器广告（移动 IPv6）
类型 9 源地址列表 RFC 3122 IND 请求
类型 10 目标地址列表 RFC 3122 IND 广告

其他规格中定义了更多选项，例如用于安全邻居发现（见下文）的 CGA 选项。

注意

欲了解所有可用选项的完整列表，请参见bit.ly/1na84cG。

安全邻居发现

ND 可以用于多种攻击，因此应当加以保护。拒绝服务攻击的一个例子是，当链路上的一个节点既能将自己作为默认路由器进行广告，又能发送“伪造”的路由器广告消息，立即使所有其他默认路由器和链路上的前缀超时。

第一种保护是，来自链路外的数据包（跳数限制小于 255）必须被忽略。此外，原始的 ND 规范建议使用 IPsec 来保护 ND 消息。然而，这需要手动设置安全关联或使用密钥管理协议。为了保护 ND 所需配置的安全关联数可能非常大，因此这种方法可能不切实际。

安全邻居发现（SEND）工作组的任务是定义保护 ND 所需的协议支持。概述了三种不同的信任模型，大致对应于受保护的企业内网、公共无线接入网络和纯粹的临时网络。讨论了与这些信任模型相关的若干潜在威胁。更多细节请参见 RFC 3756。

SEND 协议在 RFC 3971 中定义（由 RFC 6494、RFC 6495、RFC 6980 更新），旨在应对 ND 的威胁。SEND 可用于物理安全性不保证的链路环境（例如无线网络），并且对 ND 攻击构成担忧。RFC 3971 中指定了以下组件：

  • 路由器的权限必须经过认证，才能作为默认路由器使用。主机必须配置信任锚点，路由器有一个认证路径。认证路径请求和广告消息用于发现到信任锚点的认证路径。

  • 加密生成地址（Cryptographically Generated Addresses，CGA）用于确保邻居发现消息的发送者是声明地址的所有者。在所有节点能够声明地址之前，必须生成公私密钥对。新的 ND 选项——CGA 选项，用于携带公钥和相关参数。

  • 另一种新的 ND 选项是RSA 签名选项，用于保护所有与邻居和路由器发现相关的消息。

  • 引入了两个新的 ND 选项，时间戳和随机数选项，以防止重放攻击。

SEND 协议使用加密生成地址（Cryptographically Generated Addresses）。目前，SEND 不支持保护为静态地址或通过 IPv6 无状态地址自动配置机制配置的节点的 ND 消息。所有新的选项类型和消息在 RFC 3971 中进行了说明。

加密生成地址（Cryptographically Generated Addresses，CGA）在 RFC 3972 中进行了说明（由 RFC 4581 和 RFC 4982 更新），它定义了一种方法，通过公共签名密钥将其绑定到 SEND 协议中的 IPv6 地址。CGA 是生成的 IPv6 地址，其中接口标识符是通过从公共密钥和辅助参数计算加密单向哈希函数得到的。

由于供应商缺乏实现，我们预计 SEND 不会被广泛使用。在双栈环境下没有意义，因为 IPv4 本身也没有安全性。SEND 只有在 IPv6-only 网络中才有意义。

跟踪文件中的路由器广告

现在，你们都值得休息一下。以下的跟踪文件展示了实际环境中的 ND，并说明了我们一直在讨论的内容。

图 4-16 中的截图展示了一个带有三个选项字段的路由器广告的详细信息。除了初始化 IPv6 栈并为前缀进行配置外，我们没有更改路由器上的任何默认配置参数。此时使用的选项是选项 1（源链路层地址）、选项 5（MTU 大小）和选项 3（前缀信息）。

Type 字段设置为 134，这是路由器广告的值。当前跳数限制为 64。此链路上的所有节点将使用该值作为它们的跳数字段。M-Flag 设置为 0，表示该接口不会使用 DHCPv6 服务器来接收 IPv6 地址。O-Flag 也设置为 0，表示该接口不会发送 DHCP 信息请求以查找其他 DHCP 信息（如 DNS 或 NTP 服务器）。路由器生命周期设置为 1,800，表示该路由器是默认路由器。列出的第一个选项是类型 1。详细屏幕中的链路层地址包含路由器接口的链路层地址。第二个选项是类型 5，可以用于将 MTU 大小从默认的 1,500 字节更改（在某些隧道场景中可以防止隧道数据包的分片）。第三个选项是类型 3，表示前缀信息。注意前缀可以提供的所有附加信息。前缀长度字段指定前缀的有效位数（即子网掩码的长度）。L-Bit 是链路标志。如果设置，表示该前缀可以用于链路判断。如果未设置，则广告没有声明，该前缀可以用于链上和链下配置。A-Bit 是自动地址配置标志。如果设置，表示该前缀可以用于自动地址配置。在这种情况下，主机会通过将接口标识符添加到前缀中生成一个地址，或者如果使用隐私选项，则通过添加一个随机数作为接口 ID。有效生命周期字段指定该前缀的有效时长（以毫秒为单位）。优选生命周期字段指定使用此前缀配置的地址可以保持在优选状态的时间（以毫秒为单位）。最后一个字段显示由该路由器广告的前缀 2001:db8: cafe:b0::。

跟踪文件中的路由器广告图 4-16. 跟踪文件中的路由器广告

Draft-ietf-v6ops-dhcpv6-slaac-problem-00 描述了不同操作系统对 M-、O- 和 A- 标志的略微不同的解释。这种模糊性的原因在于，规范并没有将这些标志定义为强制性要求，而是作为建议。因此，不同的操作系统采用不同的方法来解释这些标志。该 RFC 回顾了这些标志的标准定义，并提供了几个主要桌面操作系统行为的测试结果。

链路层地址解析

链路层地址解析是当节点想要确定一个已知 IP 地址的接口的链路层地址时发生的过程。在 IPv4 中，这是 ARP 的功能。链路层地址解析仅在已知与节点处于同一链路上的邻居之间进行，从不为多播地址执行。

在 IPv6 中，这是通过 ND 消息实现的功能。一个节点如果需要解析链路层地址，会向邻居的目标多播地址发送邻居请求消息。该请求消息在 ND 选项字段中包含发送方的链路层地址。如果目标可达，邻居会回复一条邻居通告消息，包含其链路层地址。如果解析节点在预设的尝试次数内没有收到回复，地址解析失败。

邻居不可达性检测

如果节点最近收到确认消息，表明发送到邻居的数据包已被其 IP 层接收，那么该邻居被认为是可达的。这个确认可以通过两种方式得到：可以是对邻居请求的邻居通告，或者是一个上层进程指示成功连接（例如，活跃的 TCP 连接）。在这种情况下，收到的 TCP 确认意味着邻居可达。

为了跟踪活动和可达的连接，IPv6 节点使用不同的表格。与 ND 相关的两个重要表格是邻居缓存和目标缓存，我将在下一节中讨论这两个表格。

邻居缓存和目标缓存

IPv6 节点需要维护不同的信息表格。在这些表格中，邻居缓存和目标缓存尤为重要。根据你使用的 IPv6 协议栈，具体实现和故障排除工具会有所不同。但这些信息必须在每个 IPv6 节点上可用。

邻居缓存

邻居缓存维护了最近发送过流量的邻居列表。它们按单播 IP 地址列出，每个条目包含关于邻居链路层地址的信息，以及一个标志，指示该邻居是路由器还是主机。这可以与 IPv4 节点中的 ARP 缓存进行对比。条目中还包含关于是否有数据包排队等待发送到该目标的信息，邻居的可达性信息，以及下次邻居不可达性检测事件的预定时间。

目标缓存

该表格维护了关于最近发送流量的目的地信息，包括本地和远程目的地。邻居缓存可以看作是目的地缓存信息的一个子集。在远程目的地的情况下，条目列出了下一跳路由器的链路层地址。目的地缓存会随着通过 ICMP 重定向消息接收到的信息而更新。它还可能包含关于 MTU 大小和往返时延的额外信息。

已提到邻居缓存和目的地缓存，它们涉及在邻居广告消息中可以设置的覆盖标志。如果设置了覆盖标志，广告消息中的信息应覆盖现有的邻居缓存条目，并更新接收广告的主机缓存中的任何链路层地址。如果未设置 O 位，广告将不会更新缓存的链路层地址，但会更新现有的没有链路层地址的邻居缓存条目。

图 4-17 中的屏幕截图显示了我们路由器的邻居缓存条目。截图拍摄时，链路上有两台主机。

路由器上的邻居缓存条目图 4-17. 路由器上的邻居缓存条目

根据 RFC 4861，邻居缓存条目可以处于五种状态之一。这五种状态在表 4-8 中进行了说明。

表 4-8. 邻居缓存条目的状态

状态 描述
不完整 地址解析正在进行中，等待响应或超时。具体来说，已经向目标的请求节点组播地址发送了邻居请求，但尚未收到相应的邻居广告。
可达 该邻居当前是可达的，这意味着在过去的ReachableTime毫秒内已收到确认，表明该邻居正常工作。
陈旧 自从收到最后一次确认正向路径正常工作以来，已经过去了超过ReachableTime毫秒的时间。直到发送数据包之前，关于此邻居不会采取任何操作。
延迟 该邻居的可达时间已过期，并且在过去的DelayFirstProbeTime秒内发送了数据包。如果在DelayFirstProbeTime秒内未收到确认，则发送邻居请求并将邻居状态更改为探测状态。使用Delay为上层协议提供了额外的时间来确认可达性。没有这个额外时间，可能会生成冗余流量。
探测 正在通过每RetransTimer毫秒发送邻居请求来主动尝试确认可达性，直到确认邻居可达。

如果你对定时器、默认值和配置选项的详细信息感兴趣，请参考 RFC 4861。

邻居发现与分片

如第六章中关于安全性部分所讨论的，通过实施RA Guard可以减轻基于邻居发现（ND）的攻击。通过 RA Guard，你可以基于第二层源地址和过滤规则过滤 ND 消息。已发现邻居发现消息的分片可能带来安全风险，因为分片头可能导致第二层设备无法正确过滤 ND 消息。RFC 6980《IPv6 邻居发现的 IPv6 分片的安全性影响》解释了这个问题，并规定所有 ND 和 SEND 消息不得使用分片。

注意

有关 RA Guard 和首跳安全性的更多信息，请参见第六章。

无状态地址自动配置（SLAAC）

IPv6 的自动配置能力为网络管理员节省了大量工作。它的设计确保了在将主机连接到网络之前无需手动配置主机。即使是拥有多个网络和路由器的大型站点，也不需要 DHCP 服务器来配置主机。IPv6 的自动配置特性将成为协议的一个关键功能，尤其是在各种设备（如电视、冰箱、DVD 播放器和手机）都需要使用 IP 地址的情况下。你不希望依赖 DHCP 服务器来使用家庭设备。在公共临时网络中，它也有助于减少管理工作。在企业场景中，我们更倾向于使用 DHCPv6，主要出于可追溯性的考虑。

注意

DHCPv6 在第五章中讨论。

IPv6 支持无状态和有状态地址自动配置。有状态地址自动配置是 DHCPv6。IPv6 的真正新颖之处在于，主机可以在没有任何手动配置的情况下自动配置其 IPv6 地址。某些配置可能会在路由器上完成，但这一配置机制不需要 DHCP 服务器。为了生成其 IP 地址，主机会结合本地信息（如基于 MAC 地址的接口 ID 或随机选择的接口 ID）以及从路由器接收到的信息。路由器可以通告一个或多个前缀，主机根据这些通告来确定前缀信息。这也使得站点重新编号变得更加简单：只需要更改路由器上的前缀信息。例如，如果你更换了 ISP，并且新 ISP 分配了新的 IPv6 前缀，你可以配置路由器来通告这个新前缀，同时保留使用旧前缀时的子网 ID。所有连接到这些路由器的主机将通过自动配置机制自行重新编号。关于网络重新编号的更多信息，你可以在本章后面找到。如果没有路由器存在，主机只能生成一个具有 fe80 前缀的链路本地地址。只有在链路上的节点才能通过此地址进行通信。

无状态和有状态地址自动配置也可以结合使用。例如，主机可以使用无状态地址自动配置生成一个 IPv6 地址，然后使用 DHCPv6 来获取额外的参数。为了配置使用 SLAAC 的主机以获取附加信息（例如，DNS 服务器），已指定无状态 DHCP 服务器。

IPv6 地址会被分配给节点，并具有一定的生命周期。当生命周期到期时，地址将变得无效。为了确保地址在链路上是唯一的，节点会执行重复地址检测（DAD）过程。DAD 算法在 RFC 4862 中定义。IPv6 地址可以有不同的状态：

临时地址

这是一个尚未分配的地址。在分配之前的状态，就是在进行唯一性验证（即 DAD 过程）时的状态。节点不能使用临时地址在网络中进行通信。只有与自动配置过程相关的 ND 消息可以使用临时地址进行处理。

首选地址

这是一个已经分配给接口的地址，并且可以在分配的生命周期内无任何限制地使用。

弃用地址

这种地址的使用虽然不被鼓励，但并不被禁止。一个被弃用的地址可能是即将过期的地址。它仍然可以用来继续一个如果地址变化将中断服务的通信，但不再用于新建立的通信的源地址。

有效地址

该术语用于表示首选地址和弃用地址。

无效地址

无效地址不会分配给接口。有效地址在其生命周期到期后变为无效。

乐观地址

在 DAD 过程尚未完成时，分配给接口并可供使用的地址，受某些限制。这种地址状态在 RFC 4429 中引入，标题为“Optimistic Duplicate Address Detection (DAD) for IPv6”。乐观重复地址检测（Optimistic DAD）是现有的 ND 和 SLAAC 过程的修改，目的是在成功的情况下最小化地址配置延迟，并尽可能减少失败情况下的中断。

注意

RFC 4862 中定义的自动配置仅适用于主机，而不适用于路由器。路由器应以不同的方式进行配置。路由器可以使用无状态自动配置（Stateless Autoconfiguration）来生成其链路本地地址，并且必须对每个地址使用 DAD 过程。

当节点进行自动配置时，将执行以下步骤：

  1. 链路本地地址是通过使用fe80链路本地前缀并附加接口标识符生成的。此地址为暂定地址。

  2. 节点加入以下多播组：所有节点多播组（ff02::1）以及暂定地址的请求节点多播组（来自步骤 1）。

  3. 发送邻居请求（Neighbor Solicitation）消息，目标地址为暂定地址。该消息的 IP 源地址为全零地址；IP 目的地址为请求节点多播地址。这是 DAD（重复地址检测）过程，用于检测链路上是否已经有其他节点使用该地址。如果存在这样的节点，它将以邻居广告（Neighbor Advertisement）消息进行回复。如果接口 ID 是 EUI-64 标识符，自动配置机制将停止。如果接口 ID 是随机数，则会测试新的组合。具体实现方式取决于所使用的操作系统。如果过程停止，则需要手动重新配置主机。如果没有收到邻居请求的回复，则可以安全地使用该地址；该地址将被分配给接口，并且地址状态变更为首选。此时，本地链路上的 IP 连接已建立。到目前为止，该过程对于主机和路由器是相同的，但只有主机会执行下一步。

  4. 为了确定是否存在 IPv6 路由器、查找默认网关，以及是否有前缀可用于 SLAAC，主机将向ff02::2的所有路由器多播组发送路由器请求（Router Solicitation）消息。

  5. 所有链路上的路由器都将以路由器广告（Router Advertisement）作出回应。对于每个在路由器广告中设置了自配置标志（Autonomous Configuration flag）的前缀，节点将生成一个地址，将前缀与接口标识符结合起来。这些地址会被添加到接口的分配地址列表中。

所有地址在分配之前必须通过邻居请求消息（DAD）进行验证。如果链路本地地址是通过自动配置机制使用接口标识符生成的，则在第 3 步中已经验证了其唯一性，对于使用相同接口标识符的其他地址可能不需要重复验证。所有其他手动配置或通过有状态配置的地址需要单独验证。多宿主主机需要为每个接口执行自动配置。

因此，我们根据接口 ID 的生成方式，有两种类型的地址：

永久 IPv6 地址

这是一个全局单播或 ULA 地址，分配给接口，可能是通过自动配置（SLAAC 或 DHCPv6）或手动配置的。只要接口启用并处于活动状态，它就不会变化。

临时 IPv6 地址

这是一个全局单播或 ULA 地址，分配给接口，使用一个随机的接口 ID，该 ID 具有有限的生命周期，并在定期且可配置的间隔内发生变化。

注意

所有在这些描述中提到的不同地址类型，都在第二章中进行了讨论。

在图 4-18 的截图中显示的跟踪是在我们 Windows 8 主机的自动配置过程中获取的。该图显示了之前讨论的一些过程和消息类型，跟踪的讨论总结了本节的概念。

跟踪文件中的自动配置图 4-18. 跟踪文件中的自动配置

只要启动主机没有有效的 IPv6 地址，它将从其未指定的全零地址发送所有数据包，该地址在跟踪文件中表示为::。

数据包 1

在这个第一个数据包中，启动主机（接口）从全零地址向请求节点地址发送邻居请求（Neighbor Solicitation），以执行 DAD。ICMPv6 头部的目标地址字段包含fe80::d4e4:d1e6:c310:aef的链路本地地址。如果链路上的另一个节点已经使用了该地址，它将回复一个邻居通告（Neighbor Advertisement）消息。

数据包 2

使用第二个数据包，它向所有路由器多播地址ff02::2发送路由器请求消息（消息类型 133）。

数据包 3

在这个数据包中，主机为ff02::1:ff10:aef的请求节点多播地址进行注册。该数据包包含一个带有类型 5 选项的跳逐跳选项头（Hop-by-Hop Options header），用于 MLD 消息。跳数限制设置为 1。

数据包 4

路由器将路由器通告（RA）发送到所有节点的多播地址ff02::1，因为主机尚未拥有有效的首选 IPv6 地址。通过此 RA，路由器将自己通告为默认网关（路由器生命周期设置为 1800 秒）。此 RA 的 M 位和 O 位被设置为零（无 DHCPv6），并且自动地址配置标志设置为 1。前缀选项包含前缀2001:db8:cafe:b0::/64。此 RA 的详细信息可以在图 4-16 中看到。

数据包 5

通过此数据包，主机为请求节点多播地址ff02::1:ff1c:4c99注册。数据包包含一个 Hop-by-Hop 选项头部，其中选项类型为 5，用于 MLD 消息。跳数限制设置为 1。

数据包 6 和 7

主机对通过将路由器通告（数据包四）中接收到的全局前缀与两个接口 ID 组合形成的地址执行 DAD 测试。接口 ID 以aef结尾的地址是永久地址。接口 ID 以4c99结尾的地址是使用隐私选项的地址，或者微软所称的临时地址。数据包从全零地址发送到相应的请求节点多播地址。IPv6 地址可以在数据包 6 和 7 的汇总行中看到。

数据包 8

通过此数据包，主机为其两个请求节点多播地址注册。数据包包含 Hop-by-Hop 选项头部，其中选项类型为 5，用于 MLD 消息。

数据包 9、10 和 11

通过这三个数据包，主机在链路上为以下地址发布自己：链路本地地址fe80::d4e4:d1e6:c310:aef，全局地址2001:db8:cafe:b0:d4e4:d1e6:c310:aef，以及具有临时 IID 的全局地址2001:db8:cafe:b0:a43d:d55b:d1c:4c99。所有三个数据包都设置了覆盖标志，这告诉接收方更新其邻居缓存。对于向互联网发出的通信，该节点应使用以4c99结尾的临时全局地址。

当你获取自己的跟踪数据来分析启动过程，并使用不同的操作系统时，你也会在跟踪文件中发现该过程的不同之处。这些差异来源于 RFC 中为标准的解释留下了余地，不同厂商可能会略有不同地实现这些标准。只要遵循 RFC 中的“必须”（MUST）规则，合规性就不成问题。请注意“应当”（should）；这就是当发生故障时，你的跟踪文件分析技能能发挥作用的地方。差异的另一个原因是，实施行为取决于标准化的实施程度和状态。如果某个操作系统实现了隐私选项，那么该堆栈显然会与未实现隐私选项的堆栈有所不同。因此，在分析特定操作系统的过程时，要从厂商那里获得足够的信息，了解哪些 RFC 已被实施。如果厂商声明它实现了某些功能，你可以利用你的跟踪文件来验证该堆栈是否按预期工作。

例如，关于 DAD 和微软如何实现它，Windows 会跳过临时地址的 DAD 过程，因为接口 ID 是随机生成的。它会立即开始使用临时地址，并在稍后执行 DAD 过程以确认该地址未被使用。这就是前面提到的机会性 DAD过程。还要注意，在微软操作系统中，客户端操作系统（如 Windows 7 或 8）和服务器操作系统（如 Windows 2008 或更高版本）默认行为不同。服务器操作系统默认不会启用临时地址。有关更多信息，请参考微软的文档。

直到最近，SLAAC 的接口 ID 选择要么是基于硬件（EUI-64），要么是随机的临时地址（隐私地址）。RFC 7217《生成语义上不透明的接口标识符的 IPv6 无状态地址自动配置（SLAAC）方法》定义了稳定的随机接口 ID。顾名思义，它们是稳定的，但不基于 Layer 2 地址。

注意

对于那些使用和管理微软操作系统的朋友们，我强烈推荐一本书。它是由 Ed Horley 编写的，能为你节省许多失眠的夜晚和故障排除的时间。书名是《Windows 管理员实用 IPv6》（Apress）。

网络重编号

重编号网络意味着用新的前缀替换旧的前缀。这可能由于多种原因变得必要，常见的原因之一是更换服务提供商，这通常意味着需要更换前缀。从 IPv4 世界过渡到 IPv6 世界，前缀和地址变得越来越灵活，且不再唯一标识网络或主机。IPv6 地址架构引入了接口可以拥有多个地址的概念。这促使我们开发新的寻址概念。

在 ICMPv6 提供的机制下，未来在 IPv6 环境中重新编号网络可能会变得更加容易。这是一个在创建 IPv6 地址计划时应考虑的过程。目前，相关的操作经验不多。

重新编号网络可能包括以下步骤：

  1. 在开始此过程之前，网络中的每个链路必须从新前缀分配一个子前缀。这对于整体过程非常重要，以确保所有相关设备和服务（如路由器、交换机、接口、DNS、DHCP 等）能够正确配置。

  2. 必须更新 DNS 数据库，以包含新前缀接口的地址，并删除旧前缀接口的地址。显然，DNS 的更改必须与分配给接口的地址更改进行协调。此新信息的传播可以通过如 DNS 记录的生存时间（TTL）和主从 DNS 服务器之间的更新间隔等参数进行控制。

  3. 开关和路由器为新前缀做好准备。新前缀的所有必要路由基础设施更改与旧前缀并行添加，而旧前缀仍用于数据报服务。这不仅包括路由器和交换机，还包括防火墙、入口和出口过滤器以及所有其他过滤功能。为了将子网前缀信息传播到路由器，可以使用 DHCPv6 的 IPv6 前缀选项（RFC 3633）。在主机使用无状态地址自动配置的情况下，路由器尚未配置为通告自动配置前缀（这意味着未设置自主地址配置标志）。一旦新前缀的稳定路由得到验证，便会进行此操作。

  4. 所有访问控制列表、路由映射和其他使用 IP 地址的网络配置选项（例如，除了 DNS 以外的名称服务）应进行检查，确保使用新前缀的主机和服务能够像使用旧前缀时一样正常工作。

  5. 测试和验证新前缀的网络基础设施和路由。

  6. 将新前缀通告到公司网络之外。相应地配置所有边界防御系统，以保护新前缀免受外部攻击。

  7. 为主机上的接口分配新前缀的地址，同时仍保留旧前缀的地址。如果使用无状态自动配置，则会为新前缀设置自主 地址配置标志，因此主机会为新前缀配置地址，并保留旧地址。如果使用 DHCP，则会从两个前缀中分配地址。新信息可以通过使用 DHCP 重新配置消息来传播，这将导致每个 DHCP 客户端联系 DHCP 服务器。直到新前缀的地址插入到 DNS 中之前，它们不会被使用。

  8. 当新前缀已完全集成到网络基础设施中并经过稳定性测试后，主机、交换机和路由器可以开始使用新前缀。过渡完成后，旧前缀将不再在网络中使用，并可以逐步从 DNS 中移除。

必须特别注意那些没有从 DHCP 或 DNS 获取 IP 地址，或缓存或本地存储 IP 地址信息的应用程序和设备。

这是一个高层次的重新编号过程视图，显然——正如所有网络管理员都清楚的那样——有许多细节和可能的陷阱需要考虑。对这个过程的全面和仔细规划是必须的。RFC 4192 描述了这个过程。RFC 7010《IPv6 站点重新编号差距分析》提供了对 RFC 4192 的良好概述和更新，讨论了当前可用的支持重新编号的机制和组件，并分析了应该开发的差距和机制，以使重新编号过程更加简便。

有一个 IPv6 到 IPv6 网络前缀转换（NPTv6，RFC 6296）的规范，也可以用于因 ISP 更改而导致前缀更改的场景。这种方式引入了 IPv6 的 NAT，尽管没有端口转换的问题，因为在 IPv6 中，这将是一个从地址角度的一对一映射。

注意

请参考第七章了解关于 NPTv6 的讨论。

路径 MTU 发现

在 IPv4 中，每个路由器都可以根据需要对数据包进行分片。如果路由器无法转发数据包，因为下一链路的 MTU 小于它必须发送的数据包，路由器会对数据包进行分片。它将数据包切割成适应较小 MTU 的片段，并作为一组片段发送出去。数据包随后在最终目的地重新组装。根据网络设计，IPv4 数据包在穿越网络时可能会被分片多次。

在 IPv6 中，路由器不再进行分片；发送方负责处理分片。路径 MTU 发现试图确保数据包在某一特定路径上使用最大可能的支持大小。路径 MTU 是源和目的地之间所有链路中最小的链路 MTU。路径 MTU 的发现过程在 RFC 1981 中有描述。

发现过程是这样的。首先，主机假定路径 MTU 与第一跳链路的 MTU 相同，并使用该大小。如果数据包对路径中某个路由器来说太大，无法将数据包传递到下一个链路，该路由器会丢弃数据包并发送一个 ICMPv6 “数据包过大”消息。请回想一下，这种消息类型包含了下一跳链路的 MTU 大小。此时，主机将使用该 MTU 来发送进一步的数据包到同一目的地。然而，主机永远不会使用低于 IPv6 最小 MTU 大小 1280 字节的值。接收“数据包过大”消息并减少数据包大小的过程可能会发生多次，直到数据包到达目的地。该发现过程在数据包到达最终目的地时结束。

注意

请注意，不应阻塞 ICMPv6 “数据包过大”消息，因为这会导致分片失败。

从给定源到给定目的地的路径可能会发生变化，路径 MTU 也会随之变化。通过获取“数据包过大”消息，发现较小的 MTU 大小。IPv6 主机会不时尝试增大 MTU 大小，以便能够检测到更大的路径 MTU。路径 MTU 发现也支持多播目的地。如果目的地是多播地址，则数据包的副本可能通过多条路径传输，每条路径可能具有不同的路径 MTU。就像单播目的地一样，将会生成“数据包过大”消息，发送方使用的数据包大小是所有目的地中最小的路径 MTU。

多播监听者发现

自 1988 年以来，多播一直在 IPv4 中可用，并用于同时向一组特定的主机发送数据包。与广播（不可路由且必须由子网内的每个节点处理）不同，多播数据包被定向到 Class D 地址范围内的多播组地址。只有该多播组成员的主机才会处理该数据包。多播消息可以通过路由器转发。为了使这种路由高效，多播组管理协议确保路由器仅通过接口将多播数据包转发到包含多播组成员的链路上。

在 IPv6 中，多播是协议的一个重要组成部分，并且在所有 IPv6 节点上都可用。一个新的多播地址格式已被定义，其前缀为ff，并通过使用作用域（除了组地址外）增加了功能。例如，一个多播组地址可以位于链路本地作用域（ff02）、站点本地作用域（ff05）或全局作用域（ff0e）中。

注意

有关多播地址格式的解释及作用域标识符的列表，请参考第二章。

IPv4 中的多播组管理是通过互联网组管理协议（IGMP）完成的。IGMP 版本 2 在 RFC 2236 中定义。IPv6 使用 ICMPv6 消息来实现相同的功能；最初的开发基于 IGMPv2 规范。现在称为 多播接收者发现（MLD）。MLD 的版本 1 在 RFC 2710 中定义（由 RFC 3590 和 RFC 3810 更新）。2004 年，定义了 MLD 版本 2。它扩展了 MLD 版本 1，以支持源特定多播（SSM）的使用。它基于 IGMPv3（RFC 3376），并在 RFC 3810 和 RFC 4604 中进行了规范。MLDv2 与 MLD 版本 1 兼容。

MLD 是一种协议，允许多播接收者注册他们希望使用的多播地址，以确保高效的路由。因此，需要一个路由机制来管理多播消息的转发。PIM（协议独立多播，RFC 4601）可以与 IPv6 一起使用，且只需做最小的更改。

注意

要查找有关 PIM 状态的信息，请访问 IETF 工作组的 www.ietf.org/html.charters/pim-charter.html。

MLD 是一种非对称协议。接收者（即希望接收发送到特定多播组的消息的节点）的行为与路由器的行为不同。对于路由器是接收者的多播地址，它使用协议的两个部分。路由器使用 MLD 来发现哪些多播地址在它们的每个链路上有接收者。对于每个附加的链路，路由器会保留一个接收者地址列表。它不会跟踪有多少成员在监听某个地址。只要链路上至少有一个成员，某个多播地址就会被列出。接收者会为其多播地址发送成员报告。通过这些消息，它会在链路上向路由器注册，以接收发送到相应多播组的消息。如果该多播地址不在路由器的链路列表中，路由器会将该地址添加到需要通过该接口转发的多播地址列表中。接收者通过发送“Done”消息注销某个多播地址。当某个组的最后一个成员注销某个多播地址时，路由器会从该链路的地址列表中移除该地址。

所有 MLD 消息都使用链路本地 IPv6 源地址并设置跳数限制为 1，以确保它们保持在本地链路上。数据包具有带有路由器警告标志的跳逐跳选项头。因此，即使路由器没有监听相关的多播组地址，它也不会忽略该数据包。有关扩展头的更多信息，请参见 第二章。

MLDv1

以下是为 MLDv1（RFC 2710）指定的消息类型：

多播接收者查询—类型 130

用于 IPv6 路由器查询链路上的多播地址。查询有两种类型：用于确定链路上是否有监听器的多播地址的通用查询（在通用查询中，多播地址字段设置为零），以及用于查找链路上是否有特定多播地址成员的地址特定查询（多播地址字段设置为进行查询的多播地址）。

多播监听器报告——类型 131

用于监听器注册多播组。这可以是一个无请求的注册，或者是对路由器发送的多播监听器查询的回答。

多播监听器完成——类型 132

由监听器发送以注销多播地址。当路由器收到来自多播地址最后一个成员的多播监听器完成消息时，它会将该多播地址从其需要通过此接口转发的多播地址列表中删除。

MLDv1 的三种消息类型具有相同的格式，如图 4-19 所示。

MLDv1 消息格式图 4-19. MLDv1 消息格式

类型字段对于多播监听器查询为 130，对于多播监听器报告为 131，对于多播监听器完成消息为 132。代码字段由发送方设置为 0，接收方忽略该字段。最大响应延迟字段仅在查询消息中使用。此字段表示如果节点有监听器，则必须在此最大延迟（以毫秒为单位）内发送报告。在所有其他消息中，该字段设置为 0。通用查询中的多播地址字段设置为 0。在地址特定查询中，它包含要查询的多播组地址。在报告和完成消息中，该字段包含监听成员的多播组（报告消息）或它正在离开的组（完成消息）。

路由器将通用查询发送到链路本地范围的所有节点多播地址ff02::1。任何希望响应查询并发送报告的站点，在接收到查询后都会启动一个定时器，并在发送报告之前等待一段随机延迟。最大延迟是查询中“最大响应延迟”字段所指定的值。如果站点在此延迟内看到另一个站点发送报告，它将停止该过程。因此，可以避免为同一地址发送多个报告。组成员加入报告和终止报告将发送到相关地址。

链路本地范围的所有节点地址（ff02::1）是一个特殊地址。它从不发送成员报告或完成消息。如果一个地址的范围是 1（接口本地），则不会发送 MLD 消息。表 4-9 总结了消息类型及其目标地址。

表 4-9. 消息类型及其目标地址

消息类型 IPv6 目的地址
一般查询 链路本地范围的所有节点（ff02::1）
多播地址特定查询 正在查询的多播地址
报告 正在报告的多播地址
完成 链路本地范围的所有路由器（ff02::2）

RFC 2710 包含了许多有趣且详细的信息，讨论了节点可能经历的各种状态，并包括状态转换图。还详细介绍了定时器：它们是如何使用的，默认值是什么，以及如何配置它们。

MLDv2

MLD 版本 2 已在 RFC 3810 和 RFC 4604 中规范化。它基于 IGMPv3（RFC 3376）。MLDv2 增加了节点进行 源过滤 的能力，即仅从特定源地址或从除特定源地址外的所有源地址接收具有特定多播地址的包。这也被称为源特定多播（SSM），与基于 IGMPv2（MLDv1）的任何源多播（ASM）相对。

支持 SSM 的过滤模式可以是 INCLUDE 或 EXCLUDE。在 INCLUDE 模式下，仅启用从源地址列表中列出的源地址接收发送到指定多播地址的包。在 EXCLUDE 模式下，启用从除源地址列表中列出的源地址外的所有源地址接收发送到指定多播地址的包。

MLDv2 有两种消息类型：

  • 多播监听查询—类型 130

  • 版本 2 多播监听报告—类型 143（RFC 3810）

为了与 MLDv1 兼容，MLDv2 实现也需要支持版本 1 多播监听报告（类型 131）和版本 1 多播监听完成（类型 132）消息。

对于 MLDv2 查询消息，MLD 头部通过以下字段进行扩展，这些字段在多播地址字段之后附加，如 图 4-19 所示：

保留字段—4 位

必须设置为零。

S-标志（抑制路由器端处理）—1 位

当设置为 1 时，S-标志指示任何接收的多播路由器，它们必须抑制在接收到查询时执行的正常定时器更新。

QRV（查询者的鲁棒性变量）—3 位

如果非零，QRV 字段包含查询者使用的鲁棒性变量值。该值会影响定时器和重试次数。包含在查询中，以便同步所有连接到相同链路的 MLDv2 路由器。

QQIC（查询者的查询间隔代码）—8 位

查询者的查询间隔代码字段指定查询者使用的查询间隔。包含在查询中，以便同步所有连接到相同链路的 MLDv2 路由器。

源数量—16 位

源数量（N）字段指定查询中存在多少个源地址。在通用查询或多播地址特定查询中，此数字为零，而在多播地址和源特定查询中，此数字为非零。

源地址—可变长度

包含源地址。长度由 N 字段中指定的地址数量定义。

可以发送三种不同类型的查询：

通用查询

由查询者发送，用于了解哪些多播地址在附加的链路上有监听者。在通用查询中，多播地址字段和源数量字段都设置为零。

多播地址特定查询

由查询者发送，用于了解特定多播地址是否在附加链路上有监听者。在多播地址特定查询中，多播地址字段包含感兴趣的多播地址，而源数量字段设置为零。

多播地址和源特定查询

由查询者发送，用于了解是否有任何来自指定列表中的源对于特定的多播地址，在附加链路上有监听者。在多播地址和源特定查询中，多播地址字段包含感兴趣的多播地址，而源地址字段包含感兴趣的源地址。

并且图 4-20 显示了这些字段在追踪文件中的样子。

MLDv2 查询 图 4-20. MLDv2 查询

这是一个多播地址特定查询，因为它在多播地址字段中包含要检查的多播地址（ff02::1:3）。源数量字段设置为零。你在这张截图中看不见的是，消息有一个跳跃选项头部，并包含路由器警告选项。

MLDv2 监听者报告消息具有以下格式：

  • 类型字段—1 字节，设置为 143

  • 保留—1 字节

  • 校验和—2 字节

  • 保留—2 字节

  • M-字段（多播地址记录数量）—2 字节

  • 多播地址记录—可变长度，取决于地址数量

图 4-21 显示了追踪文件中的 MLDv2 监听者报告。

追踪文件中的 MLDv2 监听者报告 图 4-21. 追踪文件中的 MLDv2 监听者报告

在这种情况下，只有一个多播地址记录，因此值设置为 1。每个多播地址记录是一个字段块，包含有关 MLD 发送者在发送报告的接口上监听单个多播地址的信息。它包括一个字段，指定源的数量以及该多播地址的源列表。记录类型字段指定接下来描述的多播地址记录的类型。

一个接收到接口查询的节点，会通过一个当前状态记录（Current State Record）来报告接口关于特定组播地址的状态。当前状态记录可以有两种值：

值 1—模式为包含（MODE_IS_INCLUDE）

表示该接口对于指定的组播地址采用包含（INCLUDE）过滤模式。

值 2—模式为排除（MODE_IS_EXCLUDE）

表示该接口对于指定的组播地址采用排除（EXCLUDE）过滤模式。

如果过滤模式发生变化，节点会发送一个过滤模式变化记录（Filter Mode Change Record）。该记录会包含在从发生变化的接口发送的报告中。过滤模式变化记录可以有两种值：

值 3—更改为包含模式（CHANGE_TO_INCLUDE_MODE）

表示接口已经更改为指定组播地址的包含过滤模式。此组播地址记录中的源地址字段包含接口的新源列表（如果它非空）。

值 4—更改为排除模式（CHANGE_TO_EXCLUDE_MODE）

表示接口已经更改为指定组播地址的排除过滤模式。此组播地址记录中的源地址字段包含接口的新源列表（如果它非空）。

如果源列表发生变化，节点会在从发生变化的接口发送的报告中包含一个源列表变化记录（Source List Change Record）。源列表变化记录可以有两种值：

值 5—允许新源（ALLOW_NEW_SOURCES）

表示此组播地址记录中的源地址字段包含一列节点希望接收的附加源地址，这些地址是发送到指定组播地址的数据包的源地址。如果更改的是包含源列表，这些地址是添加到列表中的；如果更改的是排除源列表，这些地址是从列表中删除的。

值 6—阻止旧源（BLOCK_OLD_SOURCES）

表示此组播地址记录中的源地址字段包含一列节点不再希望接收的源地址，这些地址是发送到指定组播地址的数据包的源地址。如果更改的是包含源列表，这些地址是从列表中删除的；如果更改的是排除源列表，这些地址是添加到列表中的。

版本 2 的组播监听报告（MLDv2）会发送到 IP 目标地址ff02::16。所有支持 MLDv2 的组播路由器都会监听此地址。

注意

有关组播和任播组成员资格的更多信息，请参考 IETF Magma 小组的bit.ly/1rIgD3q。

组播路由器发现（Multicast Router Discovery）

组播路由器发现（Multicast Router Discovery，MRD）是一种通用机制，允许发现组播路由器。它不依赖于特定的组播路由协议。它在 RFC 4286 中被指定，并引入了三种新的消息类型：

组播路由器广告（Multicast Router Advertisement，消息类型 151）

该消息由路由器发送，用于宣布启用 IP 多播转发功能。它是从链路本地源地址发送到所有监听器的多播地址（ff02::6a）。

多播路由器请求（消息类型 152）

该消息由设备发送，用于向多播路由器请求广告消息。它是从链路本地源地址发送到所有路由器的多播地址（ff02::2）。

多播路由器终止（消息类型 153）

该消息由路由器发送，用于宣布它在某接口上停止 IP 多播路由功能。它是从链路本地源地址发送到所有监听器的多播地址（ff02::6a）。

所有 MRD 消息都是以 IPv6 跳数限制为 1 且包含路由器警告选项发送的。

现在你已经了解了 IPv6 所有酷炫功能的工作原理，下一章将讨论网络方面的内容，例如第 2 层、路由、多播、QoS、DHCPv6 和 DNS。接着阅读吧。

参考文献

下面是本章中提到的最重要的 RFC 和草案列表。有时，我还会为你个人进一步学习包含一些额外的相关 RFC。

RFC 文档

  • RFC 1191, “路径 MTU 发现,” 1991

  • RFC 1981, “IP 版本 6 的路径 MTU 发现,” 1996

  • RFC 2236, “互联网组管理协议，第 2 版,” 1997

  • RFC 2362, “协议独立多播—稀疏模式（PIM-SM）：协议规范,” 1998

  • RFC 2365, “管理范围的 IP 多播,” 1998

  • RFC 2463, “互联网控制消息协议（ICMPv6）,” 1998

  • RFC 2710, “IPv6 的多播监听器发现（MLD）,” 1999

  • RFC 2715, “多播路由协议的互操作性规则,” 1999

  • RFC 2894, “IPv6 路由器重编号,” 2000

  • RFC 3041, “IPv6 无状态地址自动配置的隐私扩展,” 2001

  • RFC 3122, “IPv6 邻居发现的反向发现扩展规范,” 2001

  • RFC 3168, “显式拥塞通知（ECN）添加到 IP 中,” 2001

  • RFC 3306, “基于单播前缀的 IPv6 多播地址,” 2002

  • RFC 3353, “MPLS 环境中 IP 多播概述,” 2002

  • RFC 3376, “互联网组管理协议，第 3 版,” 2002

  • RFC 3569, “源特定多播（SSM）概述,” 2003

  • RFC 3590, “多播监听器发现（MLD）协议的源地址选择,” 2003

  • RFC 3756, “IPv6 邻居发现（ND）信任模型与威胁,” 2004

  • RFC 3810, “IPv6 的多播监听器发现版本 2（MLDv2）,” 2004

  • RFC 3971, “安全邻居发现,” 2005

  • RFC 3972, “密码生成地址（CGA）,” 2005

  • RFC 3973, “协议独立多播—密集模式（PIM-DM）：协议规范（修订版）, ” 2005

  • RFC 4065, “Seamoby 和实验性移动协议 IANA 分配的指令,” 2005

  • RFC 4191, “默认路由器优先级和更具体的路由,” 2005

  • RFC 4192, “无停机日的 IPv6 网络重编号程序,” 2005

  • RFC 4213, “IPv6 主机和路由器的基本过渡机制,” 2005

  • RFC 4286，“组播路由器发现（MRD）”，2005 年

  • RFC 4429，“IPv6 的乐观重复地址检测（DAD）”，2006 年

  • RFC 4443，“互联网控制消息协议（ICMPv6）用于互联网协议第 6 版（IPv6）规范”，2006 年

  • RFC 4581，“加密生成地址（CGA）扩展字段格式”，2006 年

  • RFC 4604，“使用 MLDv2 进行特定源组播”，2006 年

  • RFC 4620，“IPv6 节点信息查询”，2006 年

  • RFC 4861，“IPv6 版本的邻居发现”，2007 年

  • RFC 4862，“IPv6 无状态地址自动配置”，2007 年

  • RFC 4884，“扩展 ICMP 以支持多部分消息”，2007 年

  • RFC 4890，“防火墙中过滤 ICMPv6 消息的建议”，2007 年

  • RFC 4982，“支持在加密生成地址（CGA）中使用多种哈希算法”，2007 年

  • RFC 5059，“协议独立组播（PIM）引导路由器（BSR）机制”，2008 年

  • RFC 5722，“IPv6 碎片重叠处理”，2009 年

  • RFC 5796，“PIM-SM 链路本地消息中的身份验证和保密性”，2010 年

  • RFC 5871，“IPv6 路由头的 IANA 分配指南”，2010 年

  • RFC 5887，“重新编号仍需改进”，2010 年

  • RFC 5942，“IPv6 子网模型：链接与子网前缀之间的关系”，2012 年

  • RFC 6104，“恶意 IPv6 路由器广告问题陈述”，2011 年

  • RFC 6105，“IPv6 路由器广告保护”，2011 年

  • RFC 6226，“PIM 组到汇聚点映射”，2011 年

  • RFC 6275，“IPv6 中的移动性支持”，2011 年

  • RFC 6434，“IPv6 节点要求”，2011 年

  • RFC 6494，“SEcure 邻居发现（SEND）证书简介和证书管理”，2012 年

  • RFC 6495，“主体密钥标识符（SKI）SEcure 邻居发现（SEND）名称类型字段”，2012 年

  • RFC 6553，“低功耗和丢包网络路由协议（RPL）用于在数据平面数据报中携带 RPL 信息的选项”，2012 年

  • RFC 6554，“低功耗和丢包网络路由协议（RPL）源路由 IPv6 路由头”，2012 年

  • RFC 6564，“IPv6 扩展头的统一格式”，2012 年

  • RFC 6583，“操作性邻居发现问题”，2012 年

  • RFC 6603，“基于 DHCPv6 的前缀委派的前缀排除选项”，2012 年

  • RFC 6724，“IPv6（互联网协议第 6 版）默认地址选择”，2012 年

  • RFC 6775，“针对低功耗无线个人区域网络（6LoWPANs）的 IPv6 邻居发现优化”，2012 年

  • RFC 6791，“ICMPv6 数据包的无状态源地址映射”，2012 年

  • RFC 6866，“在企业网络中重新编号具有静态地址的 IPv6 主机的问题陈述”，2013 年

  • RFC 6946，“处理 IPv6‘原子’碎片”，2013 年

  • RFC 6980，“IPv6 碎片化对 IPv6 邻居发现的安全影响”，2013 年

  • RFC 7048，“邻居不可达检测过于急躁”，2014 年

  • RFC 7010，“IPv6 站点重新编号间隙分析”，2013 年

  • RFC 7113，“IPv6 路由器广告保护（RA 保护）实施建议”，2014 年

  • RFC 7136，“IPv6 接口标识符的重要性”，2014 年

  • RFC 7217，《通过 IPv6 无状态地址自动配置（SLAAC）生成语义模糊的接口标识符方法》，2014 年

  • RFC 7279，《新 ICMP 类型和代码的可接受使用政策》，2014 年

草案

草案可以在www.ietf.org/ID.html找到。要查找草案的最新版本，请参考datatracker.ietf.org/public/pidtracker.cgi。你可以输入草案名称（无需版本号），系统将显示最新版本。如果草案没有显示，可能是已删除。如果它已发布为 RFC，RFC 编号将会显示。tools.ietf.org/wg也是一个非常有用的网站。关于标准化过程、RFC 和草案的更多信息可以在附录 A 找到。

这是我在本章中引用的草案列表，以及与本章主题相关的一些有趣草案：

《DHCPv6/SLAAC 地址配置交互问题声明》

draft-ietf-v6ops-dhcpv6-slaac-problem-00

《减少 IPv6 邻居发现中的组播》

draft-yourtchenko-colitti-nd-reduce-multicast-00

《基于 DHCPv6 和 RA 的主机配置比较》

draft-yourtchenko-ra-dhcpv6-comparison-00

第五章：网络

如果你已经阅读了前几章，你现在应该了解了 IPv6 的基础知识、新的地址架构、头部格式和扩展头部架构，以及基于 ICMPv6 的新过程，如邻居发现（ND）、无状态地址自动配置（SLAAC）、路径 MTU 发现和多播监听器发现（MLD）。

在我们深入探讨 IPv6 的过渡机制及其与 IPv4 网络的集成之前，本章涵盖了一些在网络中非常重要的主题，例如 IPv6 的第二层支持、校验和、多播以及它如何扩展到 IPv6、可用的路由协议和服务质量。最后但同样重要的是，我还讨论了 DHCPv6 和 DNS。尽管 IPv6 支持 SLAAC，我们预期 DHCPv6 会在企业网络中得到应用，主要是因为组织希望能够记录地址使用情况，而如果使用 SLAAC，这一点很难做到。随着 IPv6 地址空间的引入，并且仍然使用 IPv4，DNS 变得比以前更加重要。

IPv6 的第二层支持

IP 位于数据链路层和传输层之间。IPv6 开发的目标之一是能够支持尽可能多的不同物理网络，并且不需要在传输层进行更改。这种方法被称为“IP over Everything”。为了使 IP 尽可能独立于数据链路层，它需要与该层的接口，这可以是以太网、ATM、令牌环或任何其他媒介。该接口需要具有灵活性，必须能够适应不同的要求。为此，路径 MTU 发现和分片等特性已被优化。对于 UDP 和 TCP，是否使用 IPv4 或 IPv6 应该没有区别。显然，由于地址格式的不同，每当使用 IP 地址时，都会需要更改。所有这些需求导致了 IP 层本身的变化。本节讨论了与数据链路层的接口。

在讨论数据链路层时，使用了不同的术语。TCP/IP 模型有四层，其中第一层被称为链路层。OSI 模型有七层，它将 TCP/IP 模型的链路层细分为两层：物理层和数据链路层。因此，术语 IPv6 的第二层支持 指的是 OSI 模型中的第二层。

IPv6 独立于物理网络介质是非常重要的。当数据包从一个网络发送到另一个网络时，我们通常无法预先知道数据包将通过哪些物理网络。IP 只关心目标地址，并寻找到达该地址的方式，而不管所使用的网络硬件是什么。然后，IP 将数据包传递给数据链路层。在 802 网络中，数据链路层的接口驱动程序会给数据报添加一个媒体访问控制（MAC）头，并将其发送到物理网络。接口驱动程序需要了解传输的物理要求。每种网络的硬件技术定义了特定的寻址机制。邻居发现（如第四章所述）用于映射 IPv6 地址和 MAC 地址之间的关系。

IPv6 数据报文的传输规则和数据包大小因链路层技术的不同而有所区别。每种技术都有相应的 RFC 文档详细说明。本章总结了需要考虑的主要事项；RFC 文档的清单可以在附录 B 中找到。

在前一版中，我们对一些 RFC 进行了更详细的讲解，包括一些今天已经不太常用的技术，例如令牌环。我已更改本章的格式。仍然会详细介绍以太网，因为它可能是最常用的技术，并且可以作为一个例子。其他技术我会简要总结，以便你可以作为参考。

以太网（RFC 2464）

以太网是一种广泛使用的局域网技术，最早由施乐公司于 1970 年代初期开发。有很多不同的变种在使用：在早期，常用的有双绞线以太网（也称为 10Base-T，速率为 10 Mbps）和快速以太网（也称为 100Base-T，速率为 100 Mbps）；如今，千兆以太网（也称为 1,000Base-T，速率为 1 Gbps）和 10 千兆以太网（也称为 10GE，速率为 10 Gbps）已经很常见。现在，甚至出现了 40 千兆和即将出现的 100 千兆以太网。这个竞争还在继续。电气和电子工程师协会（IEEE）与一些 IT 和电信公司一起定义了一个新的标准，称为“千米以太网”（EFM，IEEE 802.3ah），它可以将以太网标准应用于到家庭和公司之间的“第一英里”连接。

RFC 2464 描述了通过以太网传输 IPv6 数据报的格式以及链路本地和无状态自动配置地址的形成方式。它废除了 RFC 1972，并支持所有以太网变种和 VLAN 技术，如 802.1Q 和思科的交换机链路（ISL）。WiFi 在较高层次看起来与以太网非常相似，因此并没有专门的 RFC 来覆盖它。

以太网硬件地址使用 48 位寻址方案。以太网硬件制造商被分配一块以太网地址块，称为OUI或公司 ID。没有两个以太网硬件接口的地址是相同的，因为每个厂商在其地址块内按顺序分配地址。以太网帧的大小是可变的，但不得小于 64 字节，且不得大于 1,518 字节（包括头部、数据和 CRC）。以太网的数据包的默认最大传输单元（MTU）是 1,500 字节，尽管许多设备支持更大的帧，最大可达 9,000 字节。可以通过包含 MTU 选项的路由器广告或通过手动配置每个设备来配置较小的 MTU。如果路由器广告的 MTU 大于 1,500 字节或大于手动配置的 MTU，则该路由器广告必须被忽略。

以太网头部包含源地址和目标地址以及以太网类型代码。IPv6 的以太网类型代码是0x86DD。图 5-1 显示了 IPv6 数据报的以太网头部。

IPv6 数据报的以太网头部图 5-1. IPv6 数据报的以太网头部

目标地址和源地址字段各自有六个字节，以太网类型字段占两个字节，包含 IPv6 的值0x86DD。

对于无状态地址自动配置（SLAAC），可以使用 MAC 地址来构建 IPv6 接口 ID。第二章解释了这一过程是如何工作的。如果 IPv6 头部中的目标地址是多播地址，则 MAC 地址的前两个字节设置为3333，最后四个字节为 IPv6 目标多播地址的最后四个字节。图 5-2 显示了该格式。

IPv6 多播地址与以太网 MAC 地址的关系图 5-2. IPv6 多播地址与以太网 MAC 地址的关系

图 5-3 展示了在跟踪文件中该如何显示。

IPv6 多播目标地址的 MAC 头部图 5-3. IPv6 多播目标地址的 MAC 头部

在图形顶部的摘要行中，您可以看到 IPv6 源地址，它是我的路由器的地址。目标地址是所有节点的组播地址。以太网目标前缀显示3333，这表明该 MAC 地址是一个组播地址，剩余的四个字节包含 IPv6 目标地址的最后四个字节——在本例中是00-00-00-01。以太网源地址包含路由器的 MAC 地址，Ethertype 的值为 IPv6，即0x86DD。

RFC 2464 有一个更新版本，是我读过的最短的 RFC 之一；它是 RFC 6085，标题为“以太网上 IPv6 组播数据包的地址映射”。它允许在明确只有一个地址相关时，将组播地址映射到以太网链路层单播地址。

注意

关于以太网的有用信息，请参考Charles E. Spurgeon 的站点。他也是Ethernet: The Definitive Guide（O'Reilly）的作者。

点对点协议（RFC 5072）

点对点协议（PPP）是一种通过串行链路运行 IP 及其他网络协议的机制。它支持同步和异步线路。RFC 5072 描述了如何通过 PPP 传输 IPv6 数据包以及 IPv6 链路本地地址如何在 PPP 链路上形成。RFC 5172 定义了用于 IPv6 数据报压缩的压缩参数。

PPP 的 IPv6 控制协议 IPV6CP 负责在 PPP 上建立和配置 IPv6 通信。一个 IPv6 数据包可以被封装在 PPP 数据链路层帧中，协议字段被设置为0x0057，表示 IPv6。如果 PPP 链路要支持 IPv6，MTU 大小必须配置为 IPv6 的最小 MTU 大小，即 1,280 字节。推荐使用更高的值（1,500 字节）。

IPV6CP 有一组独特的选项用于协商 IPv6 参数。目前，IPV6CP 唯一定义的选项是接口标识符（Interface-Identifier）和 IPv6 压缩协议（IPv6-Compression Protocol）。PPP 接口没有 MAC 地址。接口标识符选项提供了一种协商 64 位接口标识符的方法，该标识符在 PPP 链路中必须唯一。IPv6 压缩选项用于协商一个特定的数据包压缩协议，仅适用于通过 PPP 链路传输的 IPv6 数据包。此选项默认情况下是禁用的。

IPv6 地址协商与 IPv4 不同。它是通过 ICMPv6 邻居发现协议完成的，而不是像 IPv4 那样通过 PPP 来进行。对于互联网服务提供商（ISP）来说，PPP 与 IPv6 结合提供了许多优势。例如，分配静态地址给客户不再是问题，因为 IPv6 地址空间足够大。而在 IPv4 中，由于地址紧缺，ISP 通常需要使用动态地址。IPv6 的地址自动配置功能支持低成本、简便的管理和客户配置。可以通过路由器发现（Router Discovery）或通过 DHCPv6 的 IPv6 前缀选项（RFC 3633）来为客户站点分配前缀。为了在 ADSL 上使用 IPv6，ISP 需要选择符合其需求的封装方式，例如基于 ATM 的 PPP（PPPoA）或基于以太网的 PPP（PPPoE）。IPv6 也影响身份验证、授权和计费（AAA）过程。使用 IPV6CP 时，地址分配发生在身份验证之后。ISP 应注意，Radius 必须支持 IPv6 属性。

IEEE 802.15.4（RFC 4944）

该标准定义了低速无线个人局域网（LR-WPANs）的物理层和媒体访问控制。它旨在提供低成本、低速率的通信支持，以便不同类型的设备之间进行通信。该标准不定义更高层次的协议。诸如 6LoWPAN、ZigBee 等规范是基于此标准的。

6LoWPAN 是 IPv6 在低功耗无线个人局域网 上的缩写。有一个 IEEE 工作组，RFC 6282 定义了 IPv6 数据报在 IEEE 802.15.4 网络上传输的压缩格式。RFC 6775 定义了对邻居发现协议的优化（参见 第四章），以便在低功耗和丢包网络中工作。

ZigBee 是一种用于小型、低功耗无线电的通信协议规范。ZigBee 允许形成自组网。其应用包括灯光开关、电表、交通管理系统以及任何需要低速率短程无线数据传输的系统。与 6LoWPAN 不同，ZigBee 并未专门为 IPv6 进行优化。

这种技术将成为许多未来服务的基础，主要是基于传感器的通信类型。它们可以应用于任何领域：工业、安全（地震检测）、健康、娱乐等。通常这些设备的资源非常有限；这就是为什么它们需要精简且优化的技术栈。

ATM（RFC 2492）

异步传输模式（ATM）是一种面向连接的高速网络技术，广泛应用于局域网（LAN）和广域网（WAN）。它通过光纤传输，利用专用的硬件和软件机制，能够达到千兆位的传输速度。

RFC 2492 描述了通过 ATM 网络传输 IPv6 数据包的规范，这是 RFC 2491 文档“IPv6 在非广播多址接入（NBMA）网络中的应用”中的补充文档。

帧中继（RFC 2590）

帧中继是一种面向连接的高速网络技术，广泛用于广域网（WAN）。它是在 1980 年代末由贝尔实验室作为 ISDN 规范的一部分开发的。该标准在 1990 年代初期得到了改进。通过使用一个简短的两字节头，帧中继在转发数据包时非常高效。

RFC 2590 规定了 IPv6 数据包如何通过帧中继链路传输，IPv6 链路本地地址如何形成，以及 IPv6 地址如何映射到帧中继地址。

下一章概述了路由和路由协议。你将需要做出若干选择，我们将讨论可用的选项。

上层协议

IPv6 对上层协议的影响是最小的，因为数据报服务没有发生实质性变化。本章讨论了 IPv6 上的 UDP 和 TCP，并描述了上层协议（如 DNS、DHCP、SLP、FTP、Telnet 和 HTTP）在使用 IPv6 时的变化。最重要的变化通常发生在使用 IP 地址的地方。任何使用 IP 地址的进程或应用程序都需要更新，以能够处理扩展的 128 位地址格式。使用硬编码 32 位 IPv4 地址的应用程序应该更新为使用 DNS 名称，这样 DNS 可以返回 IPv4 或 IPv6 地址，使 IP 协议完全透明。

UDP/TCP 和校验和

校验和在不同层上计算。记住在第三章中提到，IPv6 头部没有校验和。但在传输层上校验和是非常重要的，它有助于确定数据包的传递问题。其他上层协议也可能使用校验和。所有在计算中包含 IP 地址的校验和计算必须进行修改，以适应新的 128 位地址。

传输协议如 UDP 和 TCP 会将校验和附加到它们的数据包中。校验和是通过使用伪头部生成的。IPv6 的 TCP 和 UDP 伪头部包含源地址、目标地址、负载长度和下一个头部值（RFC 2460）等字段。如果 IPv6 数据包包含路由头部，伪头部中使用的目标地址将是最终目标的地址。如果源地址或目标地址在传输过程中发生了变化，那么目的地的伪头部值将与初始数据包的值不匹配，这会导致校验和计算失败并产生错误报告。

由于 IPv6 地址比 IPv4 地址长得多，IPv6 规范中包含了伪头部的新版本。IPv6 伪头部规范考虑到可能在 UDP 或 TCP 层之前存在不确定数量的扩展头部，这在计算伪头部的负载长度时至关重要。接收到校验和字段值为 0 的 UDP 数据包的 IPv6 节点应该丢弃该数据包并记录错误。

注意

在 IPv4 中，UDP 头部中的校验和是可选的。而在 IPv6 中，UDP 的校验和计算是强制性的。

源节点计算并存储校验和，目的节点则进行验证。图 5-4 展示了用于计算 TCP 和 UDP 校验和的伪头部的格式。

伪头部的格式图 5-4. 伪头部的格式

以下列表描述了每个字段：

源地址（16 字节）

IPv6 数据包的源地址。

目的地址（16 字节）

IPv6 数据包的目的地址。如果数据包中包含路由头，则使用最终目的地的地址进行校验和计算。在第一个节点中，该地址是路由头列表中的最后一个地址。在最终目的地，这个地址是 IPv6 头部中的目的地址。

上层协议数据长度（4 字节）

该字段包含上层协议头部加数据的长度。

下一头部（1 字节）

下一头部字段通过使用表 3-1 中列出的值来标识头部的类型，该表在第三章中介绍。

与 IPv4 使用相同的算法来计算 IPv6 的校验和。16 位的校验和是在整个伪头部上计算的。通过将源地址和目的地址包含在校验和计算中，可以检测到在传输过程中地址的任何更改。

多播

多播在本书的不同章节中有讨论。多播地址在第二章中有所描述，而所有基于多播的邻居发现功能则在第四章中进行了讨论。本节旨在将这些内容整合，并强调多播在 IPv6 网络中的重要性。

多播是一种高效的数据传输方式，适用于单个源将相同数据分发给多个接收者的情况。这可以是视频或音频流、会议、金融信息的分发、体育赛事、软件更新、电子学习等。通过多播，数据包不必单独发送给每个接收者。一个多播数据包可以到达所有接收者，因此大大减少了数据包的数量，尤其是在接收者数量众多的情况下。每个多播数据流由其源地址（IPv6 单播地址）和其组或多播 IPv6 地址唯一标识。多播路由确保数据包从发送者传递到所有接收者。在发送者和接收者之间的所有路由器上必须启用多播功能。路由器在接收接口接收到多播数据包后，将通过所有其他接口转发到已注册的接收者。

IPv4 多播最初并不是 IPv4 规范的一部分。它是在后期引入的，并根据经验和操作实践进行了优化。IPv6 多播规范建立在这些经验基础上，并具有一些先进的功能，使其更加高效和可扩展。多播在 IPv6 中广泛应用，执行基本功能，例如邻居发现。

注意

查找有关多播如何用于邻居发现的信息，请参见第四章。

多播寻址

多播地址的格式利用了更大的寻址空间。多播地址的官方前缀是ff00::/8。与 IPv4 多播最重要的区别在于，IPv6 多播地址有 4 个位用于标识作用域。作用域决定了多播的传播范围。作用域为 2（ff02）是链路本地作用域，仅在链路上分发。作用域为 5（ff05）是站点本地作用域，会被路由到站点边界。全局多播作用域是 E（ff0e）。其他作用域可以由网络管理员定义和配置。

注意

查找关于多播地址、标志和作用域字段的所有详细信息，请参见第二章。

组成员管理

为了接收定向到多播组的数据，节点必须为该多播组注册。这是通过使用多播管理协议来实现的。在 IPv4 中，这是 IGMP（互联网组管理协议）。在 IPv6 中，它称为MLD（多播监听发现），基于 ICMP 消息。MLDv1（对应 IGMPv2 的功能）和 MLDv2（对应 IGMPv3 的功能）。在大多数情况下，使用的是 MLDv2。MLDv2 的主要区别在于，它支持源特定的多播。在源特定的多播中，节点不仅可以为一个组注册，还可以指定其希望接收数据的来源（或指定不希望接收数据的特定来源）。

定义的 ICMPv6 消息包括：

  • 多播监听查询

  • 多播监听报告

  • 多播监听完毕

注意

您可以在第四章中找到 MLDv1 和 MLDv2 消息的详细描述。

注册或注销多播组的多播消息仅与下一个跳路由器相关，因此它们具有链路本地作用域（ff02）。路由器需要知道每个接口上正在监听的多播组。为此，路由器保持每个多播组的注册接收者列表，或者在更精细的注册情况下，保持每个数据流（发送者/组）的列表。只有当组在其多播列表中时，路由器才会通过接口转发多播数据。一旦该组的最后一个成员离开该组，路由器将停止通过该接口转发该组的数据。

多播链路层协议

使用第二层多播管理协议时，交换机可以具备多播意识，这样就不需要向所有接口泛洪多播消息。MLD 嗅探，即 IGMP 嗅探的 IPv6 版本，可用。通过 MLD 嗅探，交换机会仅将多播消息转发到具有该多播组接收者的端口，因为 IPv6 多播数据会有选择地转发到需要接收数据的端口列表，而不是向 VLAN 中的所有端口泛洪。这个列表通过嗅探 IPv6 多播控制数据包动态构建。需要注意的是，多播对于 IPv6 的基本功能至关重要。因此，请确保交换机能够识别节点需要监听的所有组。

多播路由

使用 MLD 时，路由器会了解直接连接到其接口的接收者。为了为源到接收者的多播流量构建最佳路径，路由器必须相互交换关于接收者的信息。

为此目的，使用MDT（多播分发树）。树的分支通向接收者。随着接收者的加入和退出，分支会被添加或删除。树的根位于流量源，称为SPT（最短路径树）。SPT 由源地址和多播组地址标识。所有参与该树的路由器必须为其维护状态。当多个源共享同一组地址时，ST（共享树）的根位于一个管理员选择的路由器上，称为汇聚点。一个汇聚点可以处理多个组。

控制消息总是从接收端向树的根发送。找到上游邻居的过程称为RPF（反向路径转发）计算。因此，单播路由关注数据包的去向，而多播路由关注数据包的来源。对于每个多播数据流，每个路由器上只能有一个接收接口。如果通过多个接口接收数据流，将会发生数据包复制。

协议无关多播

多播路由是构建 MDT 的过程。拓扑信息保存在TIB（树信息库）中。为支持这一过程，开发了多种协议。根据部署经验，选择了几种PIM（协议无关多播）的变种。对于 IPv6，已采用三种多播路由协议：

PIM-SM（PIM 稀疏模式）

当多个源向同一组发送时使用（如视频会议、对等游戏）。

PIM-SSM（PIM 源特定多播）

PIM-SM 的子集。在单一源向多个组传输时使用（如视频或音频等内容传输）。

PIM-Bidir（双向 PIM）

当组中的所有成员既可以是接收者也可以是源时使用。

注意

关于多播和多播路由的更多信息，请参阅Ciprian Popoviciu、Patrick Grossetete 和 Eric Levy-Abegnoli 合著的《Deploying IPv6 Networks》 (Cisco Press)。

路由协议

要将一个 IPv6 数据报转发到一个直接连接的子网之外，需要使用路由器。路由器查看数据报的目标 IPv6 地址，并在其本地路由表中查找匹配的前缀。对于路由器来说，确保路由表中包含所有相关的目标非常重要。那么这些目标是如何进入路由表的呢？我们可以手动将其输入到所有路由器中，这叫做静态路由，但这并不经济。通过部署路由协议，可以实现更高效的自动化方法。路由协议定义了同步路由表的交换程序，使路由器之间能够动态更新（这叫做动态路由）。因此，使用路由协议的显著优势在于，它们能在不需要管理员干预的情况下，自动调整路由表以应对网络中的变化。

路由信息需要在自治系统（AS）内或自治系统之间进行分发。自治系统被定义为由单一管理机构控制的一组网络。将信息分发到 AS 内的路由协议被称为内部网关协议（IGP）。IPv6 的 OSPF 版本 3、RIPng、IS-IS 集成的 IPv6 支持和 EIGRP for IPv6 都属于这一类别。将信息分发到自治系统之间的路由协议被称为外部网关协议（EGP）。BGP-4 及其针对 IPv6 的扩展就属于这种协议。

本节简要概述了常见的路由协议，如 RIPng、IPv6 的 OSPF、IS-IS、EIGRPv6 和 IPv6 的 BGP-4 支持。它们是当前使用的最重要的路由协议。我不会详细描述这些协议，而是简单提及提供 IPv6 支持的最重要特性。接着，最后总结一下你在未来的 IPv6 网络环境中需要做出的路由协议选择。

本书前几版的这一章节详细讨论了 OSPFv3 和 IS-IS。写作第三版时，市场上已经有许多优秀的书籍专注于路由协议（而在 2005 年时并非如此）。因此，我决定缩短这一章节，因为我认为路由已经不再是IPv6 基础的一部分。

这里提到的大多数路由协议仅用于交换 IPv6 路由信息。如果 IPv4 和 IPv6 在同一网络中部署，则必须实现独立的路由协议：一个用于 IPv4，一个用于 IPv6——例如，IPv4 路由使用 OSPFv2，IPv6 路由使用 OSPFv3。目前，例外的是路由协议 BGP-4 和 IS-IS。它们可以在同一实例中交换两个 IP 协议的路由信息。未来，OSPFv3 也将支持在一个进程中同时处理两个地址族（RFC 5838，“OSPFv3 的地址族支持”）。

注意

本书中的路由器一词指的是任何能够进行 IPv6 数据包转发和/或处理相关路由协议的设备。

路由表

每个路由器都为其配置的每个协议维护一个路由表（也称为转发表）。因此，双栈路由器通常会有两个路由表，一个是 IPv4 路由表，一个是 IPv6 路由表。IPv6 路由表与 IPv4 路由表没有太大区别。IPv6 地址的结构较为简单，前 64 位是网络信息，后 64 位是接口 ID。

在本节中，当我们提到路由表时，通常指的是 IPv6 路由表。IPv6 路由表中的每个条目表示一个 IPv6 目标地址，从现在开始称为 IPv6 路由。表中的每个 IPv6 路由都以 IPv6 地址前缀及其长度的形式存储。对于每个 IPv6 路由，路由表中还会存储附加信息。例如，下一跳信息告诉路由器将数据包转发到该特定 IPv6 路由的哪个位置。另一种信息可能是 IPv6 路由的度量值，允许路由器在有多个条目的情况下选择最佳路径（最小度量值）以到达每个 IPv6 路由。

路由表查找和内容

对于每个进入的 IPv6 数据包，路由器会检查目标地址，并在路由表中查找该地址。对于路由表中的每个 IPv6 路由，路由器将前缀长度应用于目标地址，以计算目标地址前缀。如果计算出的前缀与 IPv6 路由的前缀匹配，则表示找到了匹配项。为了优化查找，搜索算法会根据前缀长度按从最长前缀开始的顺序查找条目。如果找到了匹配项，剩余的路由表可以被忽略，因为最长匹配的前缀总是首选的 IPv6 路由。当然，这是查找过程的简化表示。实际的算法背后非常复杂，并且经过高度优化。

一旦路由器找到匹配条目，数据报将根据与此条目关联的下一跳信息转发。此外，数据报 IPv6 头部中的跳数限制值会减少 1。如果在路由表中未找到匹配项，可能会有默认路由（见下文），或者如果没有默认路由或者跳数限制值已达到零，则数据报将被丢弃。图 5-5 展示了这样的路由表示例。

一个 IPv6 路由表图 5-5. 一个 IPv6 路由表

对于每条路由，路由器会在路由表中保留以下条目：

IPv6 前缀和前缀长度

前缀长度定义了 IPv6 前缀的相关位数。通常在路由表中，非相关位被设置为零。前缀长度还用于确定传入数据报的目标地址是否与此路由匹配。

下一跳地址

路径中第一个路由器的 IPv6 地址（通常是链路本地地址）。如果该路由直接通过本地接口连接到路由器，则无需提供下一跳地址。

下一跳接口

路由器用于到达下一跳地址的本地接口。

度量

一个表示到目标的总距离的数字。此度量值取决于将此条目放入路由表的路由协议。不同路由协议的度量计算不能互相比较。如果相同的路由被不同的路由协议知晓，路由器必须优先选择其中一个路由协议。这是通过为每个路由协议分配一个优先级值来完成的（例如，Cisco 系统将此优先级称为管理距离）。直接连接的路由总是具有最佳优先级，并且分配给下一跳接口的度量值（通常设置为零）。

定时器

距离路由信息最后更新时间的时长。

路由源，也称为协议

提供此条目信息的实体。例如，这可以是静态条目、直接连接的路由，或由路由协议提供的路由，如 RIPng、OSPF for IPv6、BGP 等。

默认路由

默认路由表示所有未在路由表中明确列出的目标地址的路由。当路由器不需要了解所有目标地址时，可以使用默认路由——例如，连接远程分支办公室到主站点的路由器。它不需要了解整个自治系统的所有路由，只需知道远程办公室的本地路由；所有其他路由只能通过连接到主站点的路由访问，因此使用默认路由。

默认路由必须像其他路由一样被输入到路由表中。默认路由的下一跳地址也称为默认路由器或默认网关。所有未知路由的数据流量都将发送到默认路由器。假定默认路由器知道所有路由或本身有一个默认路由器。是否以及如何实现这种默认路由器链条，由网络设计师自行决定。此类链条的顶端路由器通常是通向另一个网络区域或自治系统的边界路由器。正是在这里，默认路由静态地输入并通过路由协议分发到相应的网络区域。分发默认路由的优势在于减少需要分发到整个网络区域的路由更新数量。默认路由不应传播得超过预期的范围——即不应离开网络区域或自治系统。默认路由在其源处分配一个度量值，以在多个默认路由器之间建立优先级。默认路由和分发必须谨慎规划和实施，以避免路由不一致。

任何长度为零的前缀都被视为默认路由，但通常会使用 IPv6 前缀0:0:0:0:0:0:0:0（或简写为::）且前缀长度为零。传入数据报的目的地址将始终匹配默认路由，因为进行比较的相关位数为零。然而，默认路由始终是路由表中的最后一条路由，因此只有在路由表中的其他路由无法匹配时，才会找到匹配项。

注意

默认路由最常见的用途是在附加到网络的终端系统上，如 PC、服务器、打印机等。每个系统必须有一个默认网关，以将流量发送到本地子网以外的目的地。与 IPv4 不同，IPv6 中没有针对默认网关的 DHCPv6 选项。IPv6 节点通过路由器公告来学习默认路由。

RIPng

历史正在重演。就像在 IPv4 中一样，第一个进入生产环境的动态路由协议是 RIP，在这里它被称为RIPng。RIPng 是一个基于距离矢量算法的路由协议，这种算法被称为 Bellman-Ford 算法。RIPng 的大多数概念来自于 RIPv1 和 RIPv2，这两个协议已经为 IPv4 实现了相当长一段时间。RIPv1 在 RFC 1058 中定义；RIPv2 在 RFC 2453 中定义。RIPng 在 RFC 2080（1997 年 1 月）中定义。由于下面将解释的原因，它很少被使用。

RIPng 的距离矢量算法

RIPng 使用一种简单的机制来确定路由的度量值（成本）。它基本上计算到目的地的路由器数目（跳数）。每个路由器算作一个跳数。度量值大于或等于 16 的路由被认为是无法到达的。路由器定期通过 RIPng 响应消息将其路由信息分发给直接连接的邻居。收到邻居的 RIPng 响应消息后，路由器将邻居与自己之间的距离（通常是 1，即一个跳数）加到每个接收到的路由的度量值上。然后，路由器使用贝尔曼-福特算法处理新接收到的路由条目。

当路由器第一次初始化时，它们只知道直接连接的路由。这些信息会传递给所有邻居，经过处理后再分发给他们的邻居。最终，所有 IPv6 路由都被所有路由器知晓。路由器定期发送响应消息，以防止有效路由过期。所有路由器学习新路由所需的时间被称为收敛时间。

协议的限制

RIPng，像早期版本的 RIP 一样，主要设计用于中等规模网络中的 IGP。RIP 版本 1 和 2 的限制同样适用于 RIPng。这些限制在下面的列表中描述：

RIPng 的直径是有限制的。

通过 RIPng 传播的任何 IPv6 路由的最长路径的度量值被限制为 15。通常，这意味着路径上最多有 15 个跳数。该协议允许为任何链路分配更大的成本，从而进一步限制跳数。度量值为 16 或更大的路由被认为是不可达的。

路由环路可能导致较高的收敛时间。

当 IPv6 路由在环路环境中不再有效时，RIPng 会持续将度量值增加 1。这些路由将被无限传播（“计数到无穷大”）。限制度量值为 16 的机制可以防止这种情况发生。路由将循环，直到达到最大度量值，并最终被淘汰。

度量值不反映线路速度。

RIPng 使用一个固定的度量值，通常设置为每跨越一个链路就为 1。路由不能根据带宽或实时参数（如测量的延迟、负载或可靠性）来选择。

拓扑变化和防止不稳定性

当拓扑发生变化时，路由被新添加或下线。新添加的路由将在与该路由有直接连接的路由器发送的下一条响应消息中进行通告。它的邻居处理该路由并将其传递给他们的邻居。最终，所有路由器都知道新添加的路由。

如果一条路由下线或路由器崩溃会发生什么？这些路由最终会超时，因为它们不再被通告。问题是这个过程需要多长时间，以及这个时间对网络是否可接受。

在某些场景下，RIP 存在严重的限制。为克服这些限制，定义了两个过程：通过分割地平线，路由器从不通过其下一跳接口广告路由。另一种选项是分割地平线与毒性反转。使用该选项时，路由器总是通过其下一跳接口广告路由，且度量为 16。尽管 RIPng 支持 IPv6，但我们不推荐使用它。

OSPF for IPv6（OSPFv3）

OSPF for IPv6 修改了现有的 OSPF for IPv4，以支持 IPv6。OSPF for IPv4 的基本原理保持不变。为了适应 IPv6 地址大小的增加和 IPv4 与 IPv6 之间协议语义的变化，做出了一些必要的修改。OSPF for IPv6 定义在 RFC 5340 中，强调了 OSPF for IPv4 和 OSPF for IPv6 之间的差异。它包含大量对 OSPF for IPv4 文档的引用，这使得它难以阅读。

OSPF for IPv6 概述

OSPF for IPv4（OSPFv2）在 RFC 2328 中进行了标准化。除了该文档外，还定义了若干 OSPF 扩展。RFC 1584 描述了 OSPF 的 IPv4 多播扩展。RFC 3101 为 OSPF 添加了“非完全骨干区域”（NSSA）。RFC 5340 修改了 OSPF 以支持 IPv6 的路由信息交换。OSPF for IPv6 有一个新的版本号：版本 3。

OSPF 被分类为内部网关协议（IGP），用于自治系统内部。它的设计旨在克服 RIP 引入的一些限制，例如小直径、长收敛时间和无法反映网络特征的度量。此外，OSPF 能够处理更大的路由表，以适应大量的路由。

OSPF for IPv4 和 OSPF for IPv6 的区别

大部分 OSPF for IPv4 的概念被保留；以下是一些变化的简要概述：

协议处理按链路进行，而非按子网进行

IPv6 将接口连接到链路。可以将多个 IP 子网分配到单个链路上，即使两个节点不共享相同的 IP 子网，它们也可以通过单个链路直接通信。OSPF for IPv6 按链路进行，而非按子网进行。在 OSPF for IPv4 中使用的术语网络和子网应替换为链路，即 OSPF 接口现在连接到链路而非 IP 子网。

移除地址语义

IPv6 地址不再出现在 OSPF 数据包头部。它们仅允许作为有效载荷信息存在。

路由器-LSA 和网络-LSA 不包含 IPv6 地址。OSPF 路由器 ID、区域 ID 和链路状态 ID 仍为 32 位，因此不能取 IPv6 地址的值。指定路由器（DR）和备份指定路由器（BDR）现在总是通过其路由器 ID 进行标识，而不是其 IP 地址。

泛洪范围

每种 LSA 类型都包含一个明确的代码，用于指定其泛洪范围。该代码嵌入在 LS 类型字段中。已引入三种泛洪范围：链路-local、区域和自治系统（AS）。

明确支持每个链路的多个实例

现在多个 OSPF 协议实例可以在单一链路上运行。这允许不同的自治系统（每个系统都运行 OSPF）共享同一链路。该功能的另一个用途是使单一链路属于多个区域。

链路本地地址的使用

OSPF 假定每个接口都已分配链路本地单播地址。所有 OSPF 数据包都使用链路本地地址作为源地址。路由器学习到所有邻居的链路本地地址，并将这些地址用作下一跳地址。然而，在虚拟链路上发送的数据包必须使用全局或本地 IP 地址作为 OSPF 数据包的源地址。

身份验证

由于 OSPF for IPv6 运行在 IPv6 上，它依赖于 IP 身份验证头（IP Authentication Header）和 IP 封装安全有效负载（IP Encapsulating Security Payload）来确保路由交换的完整性和身份验证。IPv4 版本的 OSPF 身份验证已被移除。唯一的完整性检查仍然存在，形式为对整个 OSPF 数据包进行计算的校验和。

OSPF 数据包格式变更

参见章节 IP 数据报中的封装。

LSA 格式变更

类型 3（汇总链路）已更名为区域间前缀 LSA（Inter-Area-Prefix-LSA）。

类型 4（AS 汇总链路）已更名为区域间路由器 LSA（Inter-Area-Router-LSA）。

两种新的 LSA 承载 IPv6 前缀信息。链路 LSA（类型 8）承载本地链路的 IPv6 地址信息，区域内前缀 LSA（类型 9）承载路由器和网络链路的 IPv6 前缀。

有关其他变化，例如链路状态 ID 和选项字段，请参见章节 “链路状态数据库”。

处理未知 LSA 类型

OSPF for IPv6 引入了一种更灵活的方式来处理未知 LSA 类型，而不是简单地丢弃它们。新的 LSA 处理位已被添加到 LS 类型字段中，以允许洪泛未知的 LSA 类型。

Stub 区域支持

OSPF 在 IPv6 中保留了 Stub 区域的概念。新增的规则指定了在 Stub 区域内洪泛未知 LSA。

IP 数据报中的封装

路由器使用 OSPF 数据包交换 LSA 信息，并建立和维护邻居关系（邻接）。OSPF 数据包直接封装在 IPv6 中，通过 IPv6 头部的 Next Header 字段中的协议号 89 指定。这意味着 OSPF 并不通过 TCP 或 UDP 运行。

OSPF 不使用分片，因此当发送大于 MTU 的数据包时，完全依赖 IP 分片。应尽量避免分片。潜在的大型 OSPF 数据包，如数据库描述包或链路状态更新包，可以轻松由 OSPF 自身拆分成多个数据包。

OSPF 消息通常使用出接口的链路本地 IPv6 地址作为源地址。例外情况是通过虚拟链路发送的消息，它们使用虚拟链路的本地或全局单播地址作为源地址。根据情况，OSPF 消息可以作为单播发送到特定邻居，也可以作为组播发送到多个邻居。以下两个组播地址专门用于此目的：

AllSPFRouters（ff02::5）

所有运行 OSPF 的路由器必须监听此组播地址。Hello 数据包总是发送到该地址，除非是不可广播的网络。此地址在 LSA 泛洪过程中也用于一些数据包。

AllDRouters（ff02::6）

在多访问介质上，DR 和 BDR 必须监听这个组播地址。此地址在 LSA 泛洪过程中用于一些数据包。

发送到组播地址的 OSPF 数据包具有链路本地作用域，并且它们的 IPv6 跳数限制设置为 1。它们永远不会跨越多个跳数发送。

支持多个地址族

在原始的 OSPFv3 规范中，不支持 IPv4。这意味着在双栈网络中，你必须为 IPv4 运行 OSPFv2，为 IPv6 运行 OSPFv3。OSPFv2 存在一些限制，特别是对于移动操作。OSPFv3 可以克服其中的一些限制。RFC 5838，“OSPFv3 中的地址族支持”，为 OSPFv3 增加了多协议支持。实现该 RFC 后，你可以运行两个 OSPFv3 实例，一个用于 IPv4，一个用于 IPv6。每个 OSPFv3 实例维护自己的邻接关系、链路状态数据库和最短路径计算。通过在数据包头中使用实例 ID 字段来区分这些协议。启用地址族的路由器可以基于 IPv6 链路本地地址建立对等关系，并通告 IPv4 路由。通过这种方式，位于不同子网的 IPv4 路由器可以通过 IPv6 网络与彼此建立对等关系。

这一选择的替代方案是使用 IS-IS（接下来会描述），它也支持多地址族。一些大型组织选择将他们的 OSPFv2 环境迁移到 IS-IS，原因是希望使用一种协议来管理他们的过渡双栈网络。

使用 IS-IS 路由 IPv6

IPv6 支持与 IS-IS 在 RFC 5308 中定义。本文档基于 RFC 1195 中定义的集成 IS-IS 规范。没有深入了解集成 IS-IS 的知识，无法理解 IPv6 扩展。

IS-IS 最初定义了 中间系统（IS，亦称为路由器）之间交换路由信息，适用于 OSI 网络层协议 CLNP（无连接网络协议）和 CONP（面向连接网络协议）。其他协议使用不同的路由协议。每个网络层有独立的路由协议，有时被称为“夜空中的船只”。每个路由协议使用自己的资源，如 CPU 和内存，因此它们是相互独立的。

集成 IS-IS 是一种基于链路状态更新的内部路由协议。OSPF 和 IS-IS 有许多相似之处：如果你掌握了其中一个，另一个也容易理解。OSPF 在 AS 内部运行，而 IS-IS 在路由域内部运行。

集成 IS-IS 支持在所有 IS-IS 数据包（Hello、LSP 和 SNP）中包含可变长度字段（类型、长度、值字段，或 TLV）。相关的寻址信息存储在 TLV 字段中。Hello 数据包和 LSP 数据包携带一个字段，指定网络层协议。每个支持的网络层协议通过其 NLPID 来指定，NLPID 由 ISO 分配。IPv6 的 NLPID 值为 142（0x8E）。

RFC 定义了两个新的 IPv6 TLV。它们在下面的列表中描述。

IPv6 可达性 TLV（类型 236）

定义在 L1-LSP 和 L2-LSP 中广告的 IPv6 前缀。在 L2-LSP 中，它还可以通过在控制字段中设置外部位来用于广告路由域外的 IPv6 前缀。以下字段构成该 TLV：前缀长度、IPv6 前缀、度量（4 字节）和控制字段。

IPv6 接口地址 TLV（类型 232）

定义路由器一个或多个接口的 IPv6 地址。它在 Hello 数据包、L1-LSP 和 L2-LSP 中进行广告。在 Hello 数据包中，必须包含分配给发送 Hello 数据包的接口的链路本地 IPv6 地址。在 LSP 中，必须包含分配给路由器的全局/唯一本地地址。

EIGRP for IPv6

增强型内部网关协议（EIGRP）是思科系统公司开发的内部路由协议（IGP）。它在一个自治系统中运行，称为 EIGRP 域。EIGRP 的主要目标是消除距离矢量路由协议的局限性（参见本节前面关于 RIP 的讨论），而不需要开发另一个基于链路状态的协议。链路状态协议由于其复杂性和数据库需求，要求路由器更高的 CPU 性能和更多的内存。因此，EIGRP 作为一种混合协议开发，结合了两者的优点。它使用所谓的扩散更新算法（DUAL）来计算路由。它允许快速收敛，并确保在每一时刻的路由计算中保持无环操作。只有受变化影响的路由器参与其中。

EIGRP 一直支持不同的网络层协议。对于每个网络层协议，EIGRP 以“夜间航行”的方式运行一个独立的实例。它有 IPv4、IPX、Appletalk 模块，现在也支持 IPv6。所有协议的基本功能是相同的。不同协议的语义通过协议相关的 TLV（类型、长度、值）字段实现。

思科正在开放 EIGRP 作为一个开放栈。本文撰写时它处于草案状态。是否会标准化，以及是否有其他厂商支持，仍有待观察。

BGP-4 对 IPv6 的支持

对 IPv6 来说没有实际的 BGP。IPv6 的支持来源于 BGP-4 能够交换除 IPv4 之外的其他网络层协议的信息。BGP-4 的这些多协议扩展定义在 RFC 4760 中。定义 BGP-4 的基础 RFC 是 RFC 4271。BGP-4 是互联网中使用的主要域间路由协议。

BGP-4 概述

每个自治系统（AS）运行其内部路由协议（RIP、OSPF 等），以分发所有的路由信息。BGP 是一种外部路由协议，其主要功能是交换自治系统之间关于网络可达性的信息。每个自治系统都会收到由编号管理机构（如 IANA 和 RIRs，例如 ARIN、RIPE NCC 等）分配的唯一 AS 编号。

BGP 消息通过 TCP 连接传输，TCP 连接可以通过 IPv4 或 IPv6 建立。数据报文的源地址和目的地址取决于对等方配置，它们始终是单播的。BGP 连接使用著名的 TCP 端口 179。请记住，两个对等路由器之间只会建立一个 TCP 连接。

BGP 多协议扩展用于 IPv6

BGP-4 仅携带三项真正与 IPv4 特定相关的信息：

  • UPDATE 消息中的 NLRI（可达和撤销）包含一个 IPv4 前缀。

  • UPDATE 消息中的 NEXT_HOP 路径属性包含一个 IPv4 地址。

  • BGP 标识符位于 OPEN 消息和 AGGREGATOR 属性中。

为了使 BGP-4 能支持其他网络层协议，必须添加多协议 NLRI 及其下一跳信息。RFC 4760 扩展了 BGP，支持多种网络层协议。IPv6 是其中一个受支持的协议，这一点在单独的文档中有强调（RFC 2545）。为了适应多协议支持的新需求，BGP-4 添加了两个新属性，用于广告和撤销多协议 NLRI。BGP 标识符保持不变。因此，具有 IPv6 扩展的 BGP-4 路由器仍然需要一个本地的 IPv4 地址。为了建立交换 IPv6 前缀的 BGP 连接，对等路由器需要广告可选参数 BGP 能力以指示对 IPv6 的支持。BGP 连接和路由选择保持不变。每个实现者需要扩展 RIB 以适应 IPv6 路由。策略需要考虑 IPv6 NLRI 和下一跳信息以进行路由选择。

一个只广告 IPv6 NLRI 的 UPDATE 消息将不可达路由长度字段设置为 0，并且不携带任何 IPv4 NLRI。所有广告或撤销的 IPv6 路由都通过 MP_REACH_NLRI 和 MP_UNREACH_NLRI 承载。UPDATE 必须携带路径属性 ORIGIN 和 AS_PATH；在 IBGP 连接中，它还必须携带 LOCAL_PREF。NEXT_HOP 属性不应被携带。如果 UPDATE 消息包含 NEXT_HOP 属性，接收方必须忽略它。所有其他属性可以携带并且是可识别的。

UPDATE 消息可以同时通告 IPv6 NLRI 和 IPv4 NLRI，它们具有相同的路径属性。在这种情况下，所有字段都可以使用。然而，对于 IPv6 NLRI，NEXT_HOP 属性应被忽略。IPv4 和 IPv6 NLRI 在相应的 RIB 中是分开的。

IPv6 网络设计的路由协议选择

在为未来的网络设计包括 IPv6 时，你需要做出许多选择。花时间分析并理解 IPv6 的新特性，因为只有这样你才能发掘它的潜力。如果你仅仅试图将 IPv4 设计镜像到 IPv6 世界中，你将失去创造不仅能够支持类似网络服务，而且能够扩展以支持未来应用和服务的网络的机会。

一般来说，IPv6 网络中的路由原则并没有不同。我们有一些特性应当优化路由效率，例如固定长度的 IPv6 头部、仅在需要选项时才插入的扩展头部，以及 IPv6 路由器不再进行分片的事实。我们最终可以使用流标签来优化数据流（当社区就共同实践达成一致时）。

IPv6 的最初计划是不会分配提供者独立（PI）地址。IPv6 的早期设计目标不仅要解决地址问题，还要解决互联网路由表溢出的难题。因此，IPv6 地址空间根据地理位置分配给 RIR（区域互联网注册机构），以保持根路由表尽可能小。然而，事实证明，零 PI 空间在现实世界中并不是一个可持续的政策。所以我们回到了有 PI 地址空间的状态，这在一定程度上打破了基于地理的分层模型，从而导致全球路由表中条目的增加。此外，IPv6 路由表不包含 32 位地址条目，而是 128 位地址条目。在双栈网络的过渡期间，路由器将维护两个路由表，一个用于 IPv4，另一个用于 IPv6。厂商必须确保转发是高效的，且在硬件中完成，同时路由器能够高效利用资源，以便路由表使用最小的内存。

为了总结不同路由协议的信息，我们提供了以下概述。

对于 IPv6 网络，以下是可用的 IGP（内部网关协议）：

RIPng（RFC 2080）

RIP 是一种距离矢量协议。它使用贝尔曼-福特算法。它是一个易于使用的协议，但效率远不如 OSPF 和 IS-IS。它具有 RIPv4 一直存在的所有限制，比如有限的直径、路由环路可能导致长时间的收敛，以及度量值并不代表线路速度，因为它们是基于跳数的。它不是企业网络推荐的路由协议。

OSPFv3（RFC 5340）

OSPFv3 是一种基于链路状态的协议。它使用 Dijkstra 算法计算最短路径树（SPF）。它使用链路本地地址交换路由信息（在重新编号时非常有帮助），并且 OSPFv2 身份验证已被移除，因为现在使用标准的 IPv6 身份验证。按照 RFC 5340 的定义，OSPFv3 作为一个独立的进程运行。你仍然需要 OSPFv2 来管理 IPv4 网络，每个版本都维护独立的路由表。RFC 5838 定义了支持 OSPFv3 多地址族的扩展。撰写时，供应商支持有限。请咨询供应商的路线图。

IS-IS (RFC 5308)

IS（中间系统）是 OSI 对路由器的术语。IS-IS 是一种链路状态协议，同样使用 Dijkstra 算法。它是 ISO 协议，不依赖 IP 来交换路由信息。它与 OSPF 相似，但许多管理员认为它更容易配置和管理。IPv6 已完全集成，并不像当前版本的 OSPF 那样作为独立进程运行。多年来，它主要用于服务提供商网络，在美国不太常见。近几年，它变得越来越常见，并且在企业领域的使用也越来越多。

EIGRP for IPv6

EIGRP 是由思科系统公司开发的。它是一种混合协议，结合了距离向量和链路状态两种协议的优点，基于扩散更新算法（DUAL）。它作为独立进程运行，因此要管理 IPv4 和 IPv6，必须使用两个实例。对于较大的环境，我们建议使用 OSPF 或 IS-IS。除了更具可扩展性，EIGRPv6 目前仅在思科设备上受支持，这会造成供应商锁定，并且在需要更新时可能会造成延迟，而在竞争激烈的多供应商支持的标准中，更新通常更快。思科正在开放 EIGRP，并且它处于标准化草案状态。是否会被其他供应商采纳还有待观察。

对于未来的双栈网络，选择最有可能的是 OSPFv2 和 OSPFv3 与 IS-IS 相比。RIPng 在企业网络中无法扩展，而 EIGRP 目前是一个专有解决方案，带有供应商锁定。

OSPF 与 IS-IS 之间可能没有明显的技术优缺点。一些公司决定同时运行两种 OSPF 版本，并且没有遇到问题。随着 OSPFv3 对多家庭支持的到来，这可能成为另一种选择。其他公司则倾向于将 OSPFv2 迁移到 IS-IS，以便未来只使用一个实例。我们预计 IS-IS 在企业多协议环境中将越来越受欢迎。拥有单一实例也意味着 IPv4 和 IPv6 的命运将紧密相连。如果你有明确的需求，要求 IPv4 和 IPv6 的路由相互独立，那么使用两个 OSPF 实例可能是你的选择。路由协议的决策还会受到其他因素的影响，比如如果你希望整合 IS-IS 而且之前使用的是 OSPF，那么你需要学习新的技术。你还需要了解 OSPFv3，但与 OSPFv2 的差别并不大。决定还取决于公司文化和市场因素，比如市场上可用的技术和资源。

服务质量

一开始，互联网被设计为一个简单的通信平台，主要用于支持文件传输和电子邮件。在过去的 25 年里，它发展成了一个极其复杂的全球通信基础设施，拥有众多的应用和服务。IPv4 基于一个简单的分组交换模型，以最佳努力的方式传递数据包，并没有交付保证。TCP 提供了可靠的交付，但没有控制延迟、抖动等参数的选项，也没有带宽分配的功能。

多媒体服务（如 VoIP 和视频会议）可能会有显著的带宽需求，并且通常对及时交付非常敏感。IPv4 头部中的服务类型字节（ToS）旨在为某些流量提供优先处理。然而，它从未得到广泛实施，原因之一是它的使用会延迟路由器转发数据包。由于当时几乎没有实时服务，因此没有太大的压力去寻找更好的解决方案。

IPv6 的发展，加上对实时服务日益增长的需求——因此，也包括对服务质量（QoS）特性的需求——为寻找其他解决方案提供了机会。尽管已经有了几种不同的方法，QoS 话题仍然是一个研究领域，许多新的思路正在开发中。

让我先说，使用 IPv6 实现 QoS 并不比使用 IPv4 实现 QoS 更为复杂。本节旨在为不熟悉概念的读者简要介绍 QoS，并讨论支持 QoS 的 IPv6 特性。

QoS 基础

默认的 IP 模型对所有数据包一视同仁。它们都按照 先到先得 的原则，以最佳努力的方式转发。数据包在网络中选择的路径取决于可用的路由器、路由表以及整个网络的负载情况。

QoS 协议的任务是为不同的数据流提供优先级，并保证诸如带宽和延迟时间等质量。目前有两种主要架构：集成服务（IntServ）和区分服务（DiffServ）。这两种架构都使用流量策略，并可以结合使用，以在局域网（LAN）和广域网（WAN）中实现 QoS。

流量策略可用于根据特定标准使数据传输成为可能——例如，是否有足够的资源来根据数据的 QoS 要求转发数据。流量策略还可以监控数据流，并在必要时进行调整或限制。除了确保延迟敏感流量的 QoS 要求外，它们还可以用于商业目的，如根据不同服务级别控制成本。

集成服务

集成服务架构（IntServ）基于每个流在端到端的基础上预留带宽和所有相关资源的范式。这要求路由器存储关于流的信息，并分析每个数据包以确定其是否属于特定流，从而根据该特定流的标准转发数据包。

RSVP（资源预留协议，RFC 2205）是 IntServ 架构的一部分。RFC 2210，“RSVP 与 IETF 集成服务的使用”，描述了 RSVP 与 IntServ 的结合使用。RSVP 是一个信令协议，用于在 IP 网络中预留带宽和其他 QoS 资源。IntServ 结合 RSVP 的实现可能较为复杂，且由于其有限的可扩展性，不足以为全球互联网提供通用的 QoS 解决方案。

注意

若要查看更新的 IntServ 服务和参数名称及其关联值，请访问bit.ly/1na8Lmh。

如果您有兴趣进一步阅读关于 RSVP 和其他 QoS 信令协议的内容，请参阅信息性 RFC 4094，“现有服务质量信令协议分析”。

区分服务

尽管 IntServ 提供了为不同流分配带宽的能力，但区分服务（DiffServ）架构的设计目标是实现较不精细的类别区分，以增加其在大型网络和互联网中的可扩展性和可用性。

区分服务在 RFC 2474 和 2475 中进行了规范。RFC 2474，“IPv4 和 IPv6 头部中区分服务字段（DS 字段）的定义”，规范了 DS 字段。这在 IPv4 头部的 ToS 字段和 IPv6 头部的流量类别字段中得以实现。DiffServ 路由器使用 DS 字段来确定数据包的 QoS 转发要求。通信节点可以通过所谓的每跳行为（PHB）来分类其通信。基于 PHB，数据包在 DiffServ 路由器上将获得特定的处理。

一个DiffServ (DS)域是一个连续的 DS 路由器组，它们在所有路由器上实现了相同的服务策略。DS 域由 DS 边界路由器定义。边界路由器对传入的数据流进行分类，并确保所有经过该域的包都被适当地标记，并使用该域可用的 Per-Hop Behavior (PHB)集合中的一个行为。域内的路由器根据包中的 DiffServ 值选择转发规则，将其映射到相应的 PHB。区分服务代码点（DSCP；参见后文的图 5-6）值可以使用默认映射（DSCP=0）或为该域单独配置的映射。一个 DS 域通常由一个网络或一组网络组成，这些网络构成了一个管理单元。

一个DS 区域是由一组连续的 DS 域组成。DS 区域可以确保跨域路径的 DS 服务。单个域内部可以使用各自的 PHB 定义和 PHB 代码点映射。在区域内的域之间，流量调节器负责提供不同 PHB 和映射的正确转换。如果区域内所有域中的策略、PHB 组和代码点映射都相同，则不需要流量调节器。

包分类器根据包头中的信息和预定义规则从数据流中选择包。分类器有两种类型：行为聚合分类器（BA）根据 DS 字段对包进行分类，多个字段分类器（MF）根据不同的头字段或头字段的组合（如源地址、目的地址、DS 字段、协议号、源或目的端口，或如入接口等信息）对包进行分类。

IPv6 协议中的 QoS

IPv6 的设计者们并未专注于要求特定的 QoS 机制，而是尽可能提供更多的灵活性以支持不同的 QoS 机制。本节描述了 IPv6 头部和扩展头部中可用于 QoS 服务的元素。

IPv6 头部

IPv6 头部中有两个字段可以用于 QoS：流量类和流标签字段。

流量类

1 字节流量类字段的使用在 RFC 2474 中进行了规定。如前所述，该 RFC 为流量类字段引入了DS 字段的术语。该规范的目标是，DiffServ 路由器拥有一套已知的 DS 例程，这些例程由 DS 字段中的值决定。这些 DSCP 值映射到 Per-Hop Behaviors (PHB)，并且可以是基于性能的或基于类别的。图 5-6 展示了 DS 字段。

DS 字段的格式图 5-6。DS 字段的格式

DS 字段中的 DSCP 字段（DS 字段的六个最重要的位）用于代码点，指定 PHB。通过这个字段，可以指定 64 个不同的代码点。这个代码点池已被分为三部分，以控制 PHB 的分配。表 5-1 显示了 DSCP 池的划分。

表 5-1. 代码点池

池 代码点空间 分配政策
1 xxxxx0 标准使用
2 xxxx11 实验/本地使用
3 xxxx01 实验/本地使用；未来可能用于标准化

通过正式标准化分配了 32 个推荐的代码点池（池 1）；另外 16 个代码点池（池 2）保留用于实验或本地使用；最后的 16 个代码点池（池 3）最初用于实验或本地使用，但如果池 1 用完，应作为溢出池使用。

PHB 指定了数据包应该如何被转发。任何 DS 路由器必须提供一个由全零 DS 代码点表示的默认 PHB。默认 PHB 描述了现有路由器中可用的普通最优转发行为。这类数据包在转发时不遵循任何优先级策略；换句话说，网络将尽可能尽快地交付这些数据包，基于现有资源，如内存或处理能力。收到未定义代码点的数据包也应按照默认行为转发。

DS 字段不指定 PHB；它指定的是代码点。代码点的数量限制为 64 个，而 PHB 的数量没有限制。已经推荐了代码点到 PHB 的映射。这些映射可以在管理域内单独定义，从而使得 PHB 的数量没有限制。PHB ID 的编码规则在 RFC 3140《每跳行为标识码》规范中进行了说明。

RFC 2597 定义了一个名为Assured Forwarding (AF)的 PHB 组。Assured Forwarding PHB 组是提供商 DS 域为来自客户 DS 域的 IP 数据包提供不同级别的转发保证的一种方式。定义了四个 AF 类，每个 AF 类在每个 DS 节点中分配了一定数量的转发资源（缓冲空间和带宽）。希望使用 AF PHB 组提供的服务的 IP 数据包，按客户或提供商 DS 域将其分配到这些 AF 类中的一个或多个，具体取决于客户订阅的服务。RFC 3246 定义了一个名为Expedited Forwarding (EF)的 PHB。EF PHB 的目的是为低丢包、低延迟和低抖动服务提供构建模块。

注意

推荐的代码点和 PHB ID 由 IANA 分配。代码点的列表可以在 www.iana.org/assignments/dscp-registry 找到，PHB ID 的列表可以在 www.iana.org/assignments/phbid-codes 找到。

图 5-7 显示了跟踪文件中的 DS 字段。

跟踪文件中的 DS 字段图 5-7. 跟踪文件中的 DS 字段

这是来自我们路由器的 RIPng（RIP 下一代）响应。它被发送到 RIP 路由器组播地址 ff02::9。DS 字段被设置为 0xE0（十进制表示为 224，二进制表示为 1110 0000）。

DS 字段的其余两个比特（见 图 5-6）根据 RFC 2474 没有被使用，并且在 RFC 3168 中进行了说明，“将显式拥塞通知（ECN）添加到 IP 中”。它们提供了四个可能的代码点（00 到 11），用于拥塞通知。传统上，路由器的过载只能通过数据包丢失来确定。使用这些拥塞通知代码点后，路由器可以在数据包丢失之前就发出过载信号。这种方法类似于帧中继使用的 BECN 和 FECN（分别为向后和向前显式拥塞通知）。

这两个比特的使用方式如下：

  • 00：数据包未使用 ECN。

  • 01/10：发送方和接收方启用了 ECN。

  • 11：路由器信号表示拥塞。

应该提到的是，越来越多的廉价交换机也能够解释 DSCP 值，并因此将数据包放入不同的队列。

流标签

IPv6 头中的 20 位流标签字段可以由源节点用来标记数据包，要求 IPv6 路由器进行特殊处理，例如非默认 QoS 或实时服务。流标签由流的源节点分配。在发送方和接收方之间，可以并行存在多个流，同时交换没有 QoS 要求的数据包。新的流标签必须在 00001 到 FFFFF 范围内随机选择。随机分配的目的是使流标签字段中的任意比特组合都适合作为哈希键，由路由器查找与该流相关联的状态。

不支持流标签字段功能的主机或路由器（今天大多数应用程序不会修改以使用流标签，或不需要 QoS 处理）在发送数据包时需要将该字段设置为全零，在转发数据包时将字段内容保持不变，接收数据包时忽略该字段内容。

所有属于同一流的包必须使用相同的 IP 源地址、IP 目标地址、相同的源端口和目标端口，以及非零的流标签。如果这些包中有任何一个包含了“逐跳选项头”（Hop-By-Hop Options header），它们必须都具有相同的逐跳选项头内容（不包括逐跳选项头中的下一头字段，该字段可以不同）。如果任何包中包含路由扩展头（Routing Extension header），那么它们必须在所有扩展头中，直到包括路由扩展头，都具有相同的内容（同样，不包括路由扩展头中的下一头字段）。路由器或接收方可以验证这些条件是否得到满足。如果发现这些一致性规则被违反，将返回相应的错误消息，指出规则违反的确切位置。

路由器上对流标签的处理是高效的，且当使用 IPsec 时，它始终可用，因为 IPv6 头部不会被 ESP 加密或通过 AH 进行身份验证（在传输模式下）。这意味着 IPsec 无法保证 DS 字段中信息的完整性。

RFC 6437《IPv6 流标签规范》是对流标签的新规范。流被定义为从发送方到特定的单播、任何播或多播地址的包序列，这些包由发送方标记为一个流。流不一定与传输连接相关联。运行多个会话的主机应能够为每个会话分配不同的流标签。原始规范基于五个标准定义了流，而新规范则基于三个标准（源和目标地址以及流标签）定义流。原因是这三个字段始终可以被路由器检查，而源端口和目标端口号则可能被 ESP 隐藏。

流标签的使用

流标签是 IPv6 头部中唯一的新增字段。保留了 20 位，但实际上并未使用。在 IETF 中，关于如何最佳使用此标签曾有过很多争论，部分原因是这些不确定性以及其他更为紧迫的优先事项，导致大多数厂商忽视了它。RFC 6294《IPv6 流标签提案使用案例调查》讨论了已发布的各种提案，以及它们是否与现有标准兼容。

与此同时，发布了两项规范，提供了替代用途。RFC 7098《使用 IPv6 流标签进行服务器集群的负载均衡》描述了如何使用流标签进行负载均衡，以及它如何增强第 3 层/第 4 层负载均衡器。RFC 6438《在隧道中使用 IPv6 流标签进行等成本多路径路由和链路聚合》描述了如何通过等成本多路径路由和链路聚合来使用流标签进行负载均衡，特别是针对 IPv6 隧道流量的 IP-in-IPv6。 |

IPv6 扩展头部 |

Hop-By-Hop Options 头部可用于每个 IP 数据包传输最多一个路由器警告信号消息（RFC 2711），发送给 QoS 敏感流量路径上的每个路由器，指示每个路由器应特别处理该 IP 数据包。使用 Hop-By-Hop Options 头部使得路由器能够快速处理数据包，因为不需要分析更高层的协议头。无法识别路由器警告选项类型的路由器应忽略该选项并继续处理头部。此外，路由器在数据包传输过程中不得更改该选项。至今已定义的路由器警告类型列在表 5-2 中。 |

表 5-2：当前已定义的路由器类型 |

值 描述
0 IP 数据包包含多播监听器发现消息。
1 IP 数据包包含 RSVP 消息。
2 IP 数据包包含活动网络消息——发送方正在尝试将程序加载到路由器中，以执行定制的功能。
3–35 IP 数据包包含聚合预留嵌套级别（RFC 3175，RSVP）。
36–65,535 保留给 IANA 用于未来使用。

注意 |

这些头部的详细描述可以在第三章中找到。有关路由器警告类型的最新列表，可以在www.iana.org/assignments/ipv6-routeralert-values查看。 |

配置 |

在操作 IP 网络时，有两项主要的网络服务是必不可少的，分别是用于系统地址分配的 DHCPv6 和用于定位服务的 DNS。我预计 DHCPv6 将在 IPv6 企业网络中得到广泛应用，尽管 IPv6 提供了 SLAAC。原因在于，大多数组织希望能够记录和计算地址的使用情况，而使用 SLAAC 时这一点并不容易实现。而且，在运行具有长地址的 IPv6 网络，尤其是在操作双栈网络并期望跨两个协议版本运行的应用能够供所有用户访问时，DNS 的重要性比以往任何时候都更为突出。 |

DHCP |

DHCP 被广泛用于为主机配置其 IPv4 地址和附加信息。如果你拥有一个 IPv6 网络，则无需 DHCP 来配置主机的地址信息。无状态地址自动配置机制（SLAAC）将自动为主机配置其 IPv6 地址，而无需设置 DHCP 服务器。你所需要做的只是为启用 IPv6 的路由器配置与其附加链接的前缀信息。但在许多情况下，你仍然可能选择使用 DHCP 服务器。通过 DHCP 分配 IPv6 地址的主机配置称为有状态地址自动配置或有状态 DHCPv6。也许你有一个特定的 IPv6 地址分配方案；或者你需要动态分配 DNS 服务器；或者你希望实现 DNS 动态更新（RFC 2136）；或者你需要为使用的 IP 地址提供可追溯性报告功能。在这些情况下，你可以使用 DHCP 进行地址配置。你还可以通过使用 SLAAC 配置 IPv6 地址，并使用 DHCP 服务器提供附加的配置信息（包括 DNS 服务器 IP 地址、DNS 域名或其他 DHCPv6 选项）来结合使用 SLAAC 和 DHCPv6 配置。

RFC 3736 提供了一个额外的配置选项。它定义了一个无状态 DHCP 服务用于 IPv6。无状态 DHCP 服务器可以为已经拥有 IP 地址的主机配置附加信息，如 DNS 或 SIP 服务器，但无法进行地址分配。无状态 DHCP 在本章稍后会解释，紧接着有状态 DHCPv6 部分之后。

DHCPv6 和 DHCPv4 是独立的。如果你想在双栈网络中使用 DHCP 配置主机，目前需要运行两个独立的 DHCP 服务，每个协议一个。在这种情况下，你还必须注意配置冲突。在 DHCPv4 环境中，客户端被配置为知道是否使用 DHCP。在 DHCPv6 环境中，路由器广告有选项通知客户端是否使用 DHCP。来自不同来源的配置信息可能会到达客户端，或者一个节点可能有多个接口，例如一个仅为 IPv4，另一个为双栈。DHCPv6 使用唯一标识符（DUID），而 DHCPv4 中没有该标识符。在 DHCPv4 中，MAC 地址和客户端 ID 类似于 DHCPv6 中的 DUID，但并不完全相同。RFC 4361 提供了一个使 DUID 在 DHCPv4 中可用的方案。

在 RFC 4477 中，DHCP 工作组进一步评估了需求并评估了解决方案，这将允许双栈主机通过一个或多个 DHCP 服务器为两种协议进行配置。该 RFC 描述了双 IP 版本 DHCP 交互中识别到的问题。最重要的方面是如何处理客户端处理从 DHCPv4 和 DHCPv6 服务器接收到的配置信息时可能出现的问题。它包括一个可能的解决方案，即为 DHCPv6 服务器指定 IPv4 选项，以便在双栈环境中运行 DHCPv6 服务器，并让它也为双栈客户端配置 IPv4 选项。在这种情况下，拥有 DHCPv4 的 DUID 会很有帮助。

DHCPv6 在 RFC 3315 中进行了规范。本章中的所有引用都与 DHCPv6 相关。为了开发 DHCPv6，最初定义了以下指南：

  • 必须能够结合使用 DHCP 和 SLAAC。

  • DHCP 的配置及其与其他机制（例如 SLAAC）的交互是管理员的责任。

  • 客户端不需要手动配置。

  • DHCP 必须能够为每个接口配置多个地址。

  • 在每个子网中并不需要一个 DHCP 服务器。中继代理必须能够转发 DHCP 数据包。

  • 客户端必须能够处理来自不同 DHCP 服务器的多个 DHCP 回复。

  • 必须能够拥有仅部分客户端通过 DHCP 配置的子网。

  • DHCP 必须能够进行动态 DNS 更新，以便将分配的地址注册到 DNS 中。管理员可以决定手动更新 DNS。

  • DHCP 必须支持并简化网络的重新编号。

DHCPv6 规范包括对 DHCPv6 消息的认证，必须在 DHCPv6 客户端和服务器上支持。请参阅本章中关于 DHCPv6 认证的相关章节。

DHCP 术语

让我们定义一些用于 DHCPv6 的常见术语：

DHCP 客户端

DHCP 客户端向 DHCP 服务器发送请求以获取配置信息。

DHCP 服务器

DHCP 服务器预先配置以响应客户端请求。它知道每个客户端的配置。当它接收到客户端请求时，它将信息发送回客户端。DHCP 服务器可能位于与客户端相同的链路上，也可能不在。

DHCP 中继代理

如果客户端链路上没有 DHCP 服务器，则必须在客户端链路上配置中继代理。中继代理接收客户端请求并将其转发到另一个子网中的一个或多个 DHCP 服务器。当中继代理从 DHCP 服务器收到回答时，它会将其转发给客户端。

DHCP 唯一标识符 (DUID)

每个 DHCP 客户端和服务器都有一个 DUID。DHCP 服务器使用 DUID 来识别客户端，以便选择配置参数并将 IA（见下文）与客户端关联。DHCP 客户端在需要识别服务器的消息中使用 DUID 来标识服务器。

身份关联 (IA)

分配给客户端的一组地址。每个 IA 有一个与之关联的身份关联标识符（IAID），由客户端分配。客户端可以有多个 IA——例如，每个接口一个 IA。

身份关联标识符（IAID）

客户端选择的 IA 标识符。每个 IA 都有一个 IAID，IAID 被选择为在该客户端的所有 IA 中唯一。

事务 ID

用于匹配请求和回复的值。

DHCP 使用以下多播地址：

所有 DHCP 中继代理和服务器 (ff02::1:2)

所有 DHCP 代理（服务器和中继）都是该多播组的成员。DHCP 客户端使用这个链接范围的多播地址来联系它们的链接上的 DHCP 代理。因此，客户端不需要知道代理的链路本地地址。

所有 DHCP 服务器地址 (ff05::1:3)

站点内的所有 DHCP 服务器都是该多播组的成员。这个站点范围的地址由 DHCP 中继用来联系站点内的所有 DHCP 服务器。它们要么不知道服务器的单播地址，要么希望联系站点内的所有 DHCP 服务器。

以下 UDP 端口用于 DHCPv6：

UDP 端口 546—客户端端口

客户端监听端口 546 以接收 DHCP 消息。DHCP 服务器和中继使用该端口作为目标端口来联系 DHCP 客户端。

UDP 端口 547—服务器/代理端口

DHCP 服务器和中继监听端口 547 以接收 DHCP 消息。DHCP 客户端使用该端口作为目标端口来联系 DHCP 服务器和中继代理。DHCP 中继使用该端口作为目标端口来联系 DHCP 服务器。

如表 5-3 所示的消息类型已经在 RFC 3315 中定义。

表 5-3. DHCPv6 消息类型

消息类型 描述
SOLICIT (1) 客户端用来查找 DHCP 服务器。
ADVERTISE (2) 服务器对 Solicit 消息的响应。
REQUEST (3) 客户端用来从服务器获取信息。
CONFIRM (4) 客户端用来验证其地址和配置参数是否仍然有效。
RENEW (5) 客户端用来延长其 IP 地址的有效期并与原 DHCP 服务器续订其配置参数，尤其是在租约即将到期时。
REBIND (6) 客户端用来在租约即将到期且未收到 Renew 消息回复时，延长地址的有效期并与任何 DHCP 服务器续订其配置参数。
REPLY (7) DHCP 服务器用来回应 Solicit 消息（带有快速提交选项），以及回应 Request、Renew 和 Rebind 消息。回应信息请求消息时仅包含配置参数，但不包括 IP 地址。回应确认消息时，包含客户端 IP 地址是否仍然有效的确认信息（或拒绝信息）。服务器向 Release 或 Decline 消息发送回应以确认。
RELEASE (8) 由客户端用于释放其 IP 地址。该消息发送到客户端接收地址的服务器。
DECLINE (9) 由客户端用于向服务器指示其分配的一个或多个地址在链路上已被占用。客户端通过重复地址检测（DAD）来确定这一点。
RECONFIGURE (10) 由 DHCP 服务器用于通知客户端服务器有新的或更新的配置信息。客户端必须启动续租或信息请求消息，以获取更新的信息。
INFORMATION REQUEST (11) 由客户端发送，要求额外的配置参数（不包括 IP 地址信息）。
RELAY-FORW (12) 由 DHCP 中继用于将客户端消息转发到服务器。中继将客户端消息封装在中继转发消息的一个选项中。该消息可以直接发送到 DHCP 服务器，或者通过其他中继代理发送。如果 DHCP 消息被多次中继，则会多次封装。
RELAY-REPL (13) 由 DHCP 服务器通过中继向客户端发送消息。客户端消息作为选项封装在中继回复消息中。中继解封装消息并将其转发给客户端。中继回复消息沿着中继转发消息的路径返回，因此，如果路径上有多个中继代理，它也可能被多次封装。

由 DHCP 服务器发起的配置交换是一个非常好的新特性。例如，当 DHCP 域中的链路需要重新编号，或当新增服务或应用程序需要在客户端配置时，可以使用该功能。当服务或应用程序需要在客户端配置时，DHCP 服务器会向每个客户端的单播地址发送一个重新配置消息（类型 10）。接收到该消息的客户端必须发起续租或信息请求消息交换，以获取更新的信息。我们不是一直在等待这个吗？这是 IPv6 的实现特性，解决了我们在 DHCPv4 中遇到的一个长期存在的问题。尽管在 DHCPv4 中也可以做到这一点，但它很少被实现。IPv4 实现方式在 RFC 3203 中有定义。DHCPv4 服务器发送一个 DHCPforcerenew 消息，触发客户端进入续租状态，在该状态下客户端尝试续租其租约。

DHCPv6 头部格式

一般的 DHCPv6 头部格式比 DHCPv4 使用的格式简单得多。接下来我将描述它。

客户端-服务器消息

所有客户端与服务器之间交换的 DHCP 消息都具有固定头部，选项部分则是可变的。

图 5-8 显示了头部格式。

DHCP 头部格式图 5-8. DHCP 头部格式

消息类型字段定义了消息的类型。你可以在表 5-3 中看到消息类型的列表。对于每个请求，客户端会生成一个新的事务 ID，并将其写入事务 ID 字段。它用于与该特定请求相关的所有消息。在排查 DHCP 问题时，检查事务 ID 并确保将对应的请求和回复关联起来是非常重要的。

选项用于提供配置信息和参数。选项字段具有相同的基础格式，如图 5-9 所示。

DHCP 选项字段图 5-9. DHCP 选项字段

选项代码字段定义了选项的类型。可以在表 5-4 中找到可用选项类型的概览。选项长度字段指示选项的字节长度。选项数据字段最终包含为该选项配置的信息。其格式和长度根据选项类型的不同而变化。

RFC 3315 中定义的选项是一个基础选项集。未来将定义并在单独的 RFC 中指定额外的选项。表 5-4 显示了一个概览。

表 5-4. DHCP 选项

选项 值 描述
客户端标识符 1 用于客户端的 DUID。DUID 是一个唯一标识符（在本章稍后描述）。
服务器标识符 2 用于服务器的 DUID。
非临时地址身份关联（IA_NA） 3 用于指示 IA_NA、其参数及与之关联的非临时地址。
临时地址身份关联（IA_TA） 4 用于指示 IA_TA、其相关参数及临时地址。此选项中包含的所有地址都被客户端用作临时地址（根据 RFC 3041《无状态地址自动配置的隐私扩展》）。
IA 地址 5 用于指示与 IA_NA 或 IA_TA 关联的地址。
选项请求 6 用于客户端与服务器之间的消息，以标识一组选项列表。可以包含在请求、续约、重绑定、确认或信息请求消息中。服务器可以在重配置消息中使用此选项来指示哪些选项已更改或添加。
优先级 7 由服务器发送，用于影响客户端选择 DHCP 服务器。
经过时间 8 包含客户端启动 DHCP 事务的时间。以百分之一秒为单位。在客户端发送的第一条消息中，设置为 0。可以被第二级 DHCP 服务器用于检测主服务器是否及时响应。
中继消息 9 包含中继转发或中继回复消息中的原始消息（请记住，原始消息已封装在中继转发或回复消息中）。
认证 11 包含用于验证 DHCP 消息的身份和内容的信息。
服务器单播 12 服务器向客户端发送此选项，以指示可以使用单播进行通信。该选项包含 DHCP 服务器的 IP 地址，客户端将使用该地址。

注意

你可以在bit.ly/1na92Wj找到所有已定义的 DHCPv6 选项的更新列表。有关一般的 DHCP 信息，请参考 DHCP 工作组的页面：www.ietf.org/html.charters/dhc-charter.html。

中继代理—服务器消息格式

如果客户端和服务器不在同一链路上，中继代理将转发客户端和服务器消息。一个 DHCP 消息可以被多个中继代理转发给一个或多个服务器。服务器的回复必须遵循原始请求的返回路径，并且必须由相同的中继代理转发。图 5-10 显示了中继代理和服务器消息中的头字段。

中继代理和服务器消息中的头字段图 5-10. 中继代理和服务器消息中的头字段

中继转发和中继回复消息具有相同的格式，并通过消息类型字段中的值来标识。类型 12 是中继转发消息，类型 13 是中继回复消息。

中继转发消息中的跳数字段显示消息已被多少个中继转发。每个转发的中继都会将值增加 1。中继可以预配置跳数限制，以限制转发消息的中继数量。当中继收到的消息中跳数已经达到配置的跳数限制时，它会丢弃该消息。跳数限制的默认值为 32。在中继回复消息中，跳数字段的值取自相应的中继转发消息中的跳数字段。

链路地址字段包含一个全局 IPv6 地址。基于中继转发消息中的这个字段，服务器可以识别请求客户端所在的链路。RFC 还提到，站点本地地址作为该字段的可能值，因为 DHCPv6 RFC 在站点本地地址被弃用之前就已发布。在中继回复消息中，该字段的值取自相应的中继转发消息。

对端地址字段包含接收消息的客户端或中继的地址。该字段从中继转发消息复制到中继回复消息中的相应字段。

可变大小的选项字段包含一个中继消息选项（选项类型 9）。在中继转发消息中，它包含客户端请求；在中继回复消息中，它包含服务器回复。

该字段还可以包含中继代理上预先配置的附加信息，且它们在转发消息时插入这些信息。这在 RFC 6422 中有说明，“中继提供的 DHCP 选项”。此内容在中继代理通信部分进行了描述。

DHCP 唯一标识符（DUID）

每个 DHCP 客户端和服务器都有一个 DHCP 唯一标识符（DUID），用于彼此识别。服务器使用客户端的 DUID 选择要发送的相应客户端配置。DUID 必须在所有服务器和客户端中是唯一的，且在初始分配后不应更改。RFC 3315 定义了三种不同类型的 DUID，未来可能会定义其他类型。DUID 包含一个 2 字节类型代码，后跟一个可变长度的字节序列，表示标识符。目前指定的三种类型如下：

  • 链路层地址加时间（DUID-LLT）

  • 基于企业编号的供应商唯一 ID（DUID-EN）

  • 链路层地址（DUID-LL）

身份关联

身份关联（IA）是客户端和服务器用于标识和管理一组地址的对象。每个 IA 都有一个相应的 IAID 并包含单独的配置信息。每个客户端在每个接口上至少有一个 IA，由 DHCP 服务器进行配置。客户端通过 IA 从服务器获取适合该接口的配置。每个 IA 只能与一个接口关联。IAID 由客户端选择，并且在该客户端的所有 IA 中必须是唯一的。IA 的配置信息包含一个或多个 IPv6 地址以及 T1/T2 定时器（续租和重新绑定定时器，详见续租/重新绑定）。

DHCP 服务器根据管理员定义的地址分配策略选择 IA 的配置信息。它根据以下标准选择配置：

  • 客户端连接的链路

  • 客户端的 DUID

  • 客户端提供的其他信息来自选项

  • 其他信息来自选项，这些选项已由中继代理添加

DHCP 通信

DHCP 通信中有不同的过程。包括客户端-服务器交互和通过中继代理转发消息。以下各节将更详细地描述这些过程。许多过程与 DHCPv4 相似，仅在 IPv6 相关的适配上有所不同。其他过程是新的，例如消息通过中继代理转发的方式。

客户端与服务器的通信

客户端使用多播 Solicit 消息来查找 DHCP 服务器。如果客户端希望联系特定的 DHCP 服务器，它使用服务器 DUID 在 Server Identifier 选项（选项类型 2）中指定。所有 DHCP 服务器都会接收到该消息，但只有由 DUID 指定的服务器会作出回复。在某些情况下，客户端可以使用单播地址与特定服务器建立联系。只有当服务器被配置为发送 Server Unicast 选项（选项类型 12），并指示可以进行单播通信及要使用的 IP 地址时，这才可能。在这种情况下，必须注意，这些单播消息不会通过中继代理转发，因此在中继代理上进行的任何额外配置都不会插入到单播 DHCP 消息中。如果 DHCP 服务器收到来自客户端的单播消息，而该客户端未收到单播选项，它将回复一个包含状态码“使用多播”（选项 13，代码 5）的 Reply 消息。

客户端收到一个或多个 Advertise 消息作为对其 Solicit 消息的答复。如果收到多个，它会应用以下标准来选择 DHCP 服务器：

  • 首选具有最高服务器首选值的消息。

  • 如果有多个具有相同服务器首选值的消息，它将选择具有优选配置的消息。

  • 如果包含更合适的配置参数，客户端也可能选择首选服务器偏好值较低的消息。

服务器列表及其对应的首选项值存储在客户端。如果客户端没有从其首选的 DHCP 服务器收到回复，它将选择列表中的下一个服务器。如果客户端在一定时间内没有收到 DHCP 服务器的答复，它要么通过发送另一个 Solicit 消息来启动新的发现过程，要么结束配置并生成错误消息。

在回复 Advertise 消息时，客户端向其中一个 DHCP 服务器发送 Request 消息，包括其 IA 选项、客户端 DUID 和 Option Request 选项，其中包含所需的 DHCP 选项。服务器以包含请求选项的 Reply 消息作出回复。如果服务器收到通过中继代理转发的 Request 消息（在 Relay Forward 消息中），它将通过与传入 Request 消息相同的中继代理转发一个 Relay Reply 消息。服务器会将 Reply 消息中分配的地址标记为已分配。如果客户端收到多个 Reply，它会选择最合适的一个，并使用这些地址。其他服务器通过其 Advertise 消息分配的地址仍然保持分配状态，但不会被使用。当这些地址的有效期过期后，它们将由 DHCP 服务器重新使用。

客户端必须对每个由 DHCP 服务器分配的地址执行重复地址检测（DAD）。

注意

有关 DAD 的解释，请参阅邻居发现（Neighbor Discovery）部分，见第四章。

执行状态地址自动配置的客户端进行的典型 DHCP 通信如下所示：

  1. 客户端发送请求（Solicit）消息。

  2. 服务器(s)以广告（Advertise）消息回复。

  3. 客户端向一个服务器发送请求（Request）消息。

  4. 服务器以回复（Reply）消息进行回应。

通过快速提交（Rapid Commit）选项，该通信可以缩短为仅包含两条消息。在这种情况下，客户端发送一条包含快速提交选项的请求消息。服务器回复一条包含快速提交选项的回复消息。如果客户端发送了一条包含快速提交选项的请求消息，它将忽略任何不包含快速提交选项的回复。如果客户端没有收到包含快速提交选项的回复，它可以接受传入的广告消息并继续常规配置过程。如果服务器收到一条包含快速提交选项的请求消息，并且没有配置使用该选项，它将以常规的广告消息回复。虽然快速提交通过仅使用两条消息提供了更高效的地址分配方法，但根据配置和 DHCP 服务器的数量，它可能导致地址空间浪费或多个 DHCPv6 服务器认为自己为请求的客户端分配了地址。一旦 DHCP 服务器在带有快速提交选项的回复消息中分配了一个地址，它必须将该 IP 地址提交给客户端。显然，由于/64 的广阔地址空间，这可能不是一个大问题。

客户端根据需要使用请求（Request）、续租（Renew）、重新绑定（Rebind）、释放（Release）和拒绝（Decline）消息，来管理其由服务器分配的地址的生命周期。如果客户端切换链路或子网（例如，在无线网络中或从睡眠模式中唤醒后），它必须启动确认/回复交换。它通过发送其 IA（接口标识符）以及相应的地址和选项来完成此操作。如果客户端没有收到确认消息的答复，它应该继续使用先前分配的地址。

为了释放一个或多个地址，客户端发送释放（Release）消息，该消息包含 IA 及相应的地址和选项。服务器以回复消息进行回应。如果客户端没有收到回复，它会发送另一条释放消息。这并非在所有情况下都可能发生——例如，当客户端关闭时。如果 DHCP 服务器未收到释放消息，它将在地址的生命周期过期后重新使用这些地址。

如果客户端注意到一个分配的地址已经在使用（例如，通过 DAD 检测），它会向服务器发送拒绝（Decline）消息。此消息包含事务 ID、客户端标识符、服务器标识符以及地址。

续租/重新绑定

如果客户端想要刷新其有效和首选地址的生存时间，它会发送一个续租（Renew，类型 5）消息，消息中包含 IA 地址选项以及与此 IA 相对应的地址。服务器会识别相应的生存时间并向客户端发送一个应答消息。这样做也可能通过将旧地址的生存时间设置为 0 来添加新地址或删除旧地址。

如果服务器收到一个续租消息，但该 IA 没有对应的条目，它会回复一个应答消息，并将状态码设置为“无绑定”（option 13，code 3）。如果客户端想续租一个不再有效的地址，服务器会发送一个应答消息，将地址的生存时间设置为 0。

服务器通过预配置的定时器 T1 和 T2 来控制客户端续租地址的间隔，这些定时器与每个 IA 相关联。当客户端达到 T1 所指示的时间时，它必须开始续租过程。当客户端达到 T2 所指示的时间时，表示其续租消息未得到应答。在这种情况下，它会向所有 DHCP 服务器发送重绑定（Rebind）消息。重绑定消息包含一个 IA 选项，包含当前分配的地址，以及一个选项请求（Option Request）选项，包含所有所需的 DHCP 选项。

当服务器接收到重绑定（Rebind）消息并找到相应的 IA（接口地址）时，它会回复一个应答（Reply）消息。如果这些地址不再对该链路有效，服务器会将生存时间（lifetime）设置为 0。如果客户端没有收到重绑定消息的应答，它将无法继续使用该地址。在这种情况下，客户端有两个选项：

  • 通过发送一个请求消息来重新启动地址配置，以寻找一个 DHCP 服务器。

  • 如果客户端有其他有效的 IA，它可以忽略过期的 IA 并使用其他地址。

信息请求（Information Request）

如果客户端已经拥有 IP 地址，但希望获取其他 DHCP 信息，它会发送一个信息请求消息。此消息包含一个选项请求（Option Request）选项，以指示所需的 DHCP 选项。例如，如果客户端通过无状态地址自动配置（Stateless Address Autoconfiguration）进行配置，并且路由器配置为在路由器通告中设置（“O-Flag”）O-Flag（其他有状态配置），这将导致客户端发送信息请求消息以获取附加信息，如 DNS、NTP 或 SIP 服务器配置。客户端还会在收到服务器的重新配置（Reconfigure）消息时发送信息请求消息。

重新配置过程

服务器发送一个重新配置（Reconfigure）消息，触发客户端发送一个续约（Renew）或信息请求（Information Request）消息。当服务器更新了新的或修改过的信息时，这非常有用，确保新信息能够尽快传播。在重新配置消息中，事务 ID（Transaction ID）被设置为 0，并包含一个服务器标识符（Server Identifier）选项，其中包括服务器的 DUID 和一个客户端标识符（Client Identifier）选项，包含客户端的 DUID。此外，还可以发送一个选项请求（Option Request）选项，以指示客户端哪些选项已被更改或添加。如果客户端需要重新配置其 IP 地址，选项请求中将包含 IA 地址（IA Address）选项（类型 5）。通过重新配置消息选项（类型 19），服务器指示客户端是否需要发送续约或信息请求消息。

由于存在 DoS 攻击的风险，重新配置消息中必须使用安全机制，这意味着服务器必须使用 DHCP 认证。服务器将重新配置消息发送到每个客户端的单播 IPv6 地址。如果它不知道客户端的单播地址，它会将消息作为中继回复（Relay Reply）消息发送给中继代理（Relay Agent）。当客户端处于重新配置过程中时，不接受进一步的重新配置消息。只有在初始过程完成后，才能启动新的过程。

中继代理通信

中继代理通过 DHCPv6 转发 DHCP 消息的方式与 DHCPv4 有很大不同。以下部分将详细描述中继代理通信。

中继代理使用 All_DHCP_Servers 组播地址（ff05::1:3）将消息转发给 DHCP 服务器。它也可以配置为使用单播地址。中继代理接收来自客户端的消息，并构建一个中继转发（Relay Forward）消息。图 5-10 显示了此消息的头部。在链接地址（Link Address）字段中，它设置了其全局 IPv6 地址，该地址具有客户端所在链接的前缀。通过这个地址，DHCP 服务器可以确定它需要为哪个前缀分配地址。跳数（Hop Count）被设置为 1。来自原始地址（即客户端 IP 地址）的源地址被复制到中继转发消息的对等地址（Peer Address）字段中。原始的 DHCP 消息被复制到中继消息选项（Relay Message Option）字段中。中继代理现在可以添加管理员预配置的其他信息。

当一个中继代理从另一个中继代理接收到转发消息，且跳数字段的值达到预配置的跳数限制时，它会忽略该消息。通过跳数限制，可以限制转发 DHCP 消息的中继代理数目。如果跳数小于跳数限制，消息将被转发。它将数据包封装到另一个转发消息头中，将跳数加 1，并将上一个中继代理的源地址复制到对等地址字段。链路地址字段设置为 0。接收到的消息会被复制到转发消息选项中。

如前所述，转发回复消息必须通过与转发消息相同的中继代理进行转发。通过刚才描述的过程，每个中继代理将接收到的消息封装到一个新的转发消息头中，这使得 DHCP 服务器能够追踪回程。在最后一个转发消息选项中，服务器找到了来自客户端的原始请求。它对此作出回复，并将答案复制到转发回复消息的转发消息选项中。它将此回复封装为与转发消息收到的中继代理数目相同的转发回复头。因此，转发回复将沿着相同的路径通过相同的中继代理返回。路径上的每个中继代理都会去掉外部头并将消息转发给下一个中继代理。路径上的最后一个中继代理收到一个转发回复消息，其中包含了服务器回复的转发消息选项字段。它移除转发回复头，并将服务器的回复转发给客户端。

表 5-5 展示了一个经过两个中继（中继 A 和中继 B）转发的数据包头部字段条目。

表 5-5. 转发和回复消息中的头部

头部字段 数据包 2 数据包 3 数据包 4 数据包 5
中继 A 到中继 B 中继 B 到服务器 服务器到中继 B 中继 B 到中继 A
消息类型 转发消息（类型 12） 转发消息（类型 12） 回复消息（类型 13） 回复消息（类型 13）
跳数 1 2 2 1
链路地址 中继 A 0 0 中继 A
对等地址 客户端 C 中继 A 中继 A 客户端 C
转发消息选项 客户端请求 数据包 2 数据包 5 DHCP 回复

通信过程如下所示：

  1. 客户端 C 发送了一个 DHCP 请求（数据包 1，在表 5-5 中未显示）。

  2. 中继代理 A 将客户端请求（类型 12 的转发消息）转发给中继代理 B（数据包 2）。它将自己的地址复制到链路地址字段。客户端请求被复制到转发消息选项中。

  3. 中继代理 B 将消息转发给 DHCP 服务器（数据包 3）。它将链路地址字段设置为 0，并将中继代理 A 的地址复制到对等地址字段。中继代理 A 收到的数据包 2 被复制到中继消息选项中。

  4. DHCP 服务器向中继代理 B 发送中继回复（类型 13）（数据包 4）。跳数、链路地址和对等地址字段从中继转发消息中复制。中继消息选项包含数据包，该数据包需要从中继代理 B 发送到中继代理 A（数据包 5）。

  5. 中继代理 B 解封装数据包 5，并将其转发给中继代理 A。

  6. 中继代理 A 从中继消息选项中获取服务器回复并将其转发给客户端 C。

如前所述，中继代理可能拥有客户端的信息，但它无法将这些信息发送给客户端。RFC 6422 规定了中继提供的选项选项（RSOO，选项代码 66）。中继将这些附加选项封装在 RSOO 中。然后，DHCP 服务器可以将这些选项添加到发送给客户端的 DHCP 回复中。这些选项必须被特别定义为启用了 RSOO 的选项，并参照 RFC 6422。RFC 6422 发布之前定义的选项不是启用了 RSOO 的选项。

注意

启用 RSOO 的选项列表可以在 bit.ly/1na9bZQ（滚动到页面底部）找到。

跟踪文件中的 DHCPv6 通信

在这一部分，我想向你展示一个 DHCPv6 跟踪文件，该文件是在课堂上捕获的。

如 第四章 所述，客户端通过路由广告（RA）得知它需要使用 DHCPv6 以获取 IPv6 地址。图 5-11 显示了路由广告的样子。

路由广告中的 DHCPv6 标志图 5-11. 路由广告中的 DHCPv6 标志

在启动过程中，客户端发送路由请求。如果存在一个 IPv6 路由器并且已正确配置（“O-Flag”），客户端将收到一个路由广告，其中一个或两个 DHCPv6 标志被设置为 1，管理配置标志（M-Flag）和其他状态配置标志（O-Flag）。当客户端收到此消息时，它将启动 DHCP 请求。

图 5-12 显示了通信。

跟踪文件中的 DHCPv6 通信图 5-12. 跟踪文件中的 DHCPv6 通信

如图最上方所示，我在 Wireshark 中设置了一个过滤器，只显示 DHCPv6 通信。因此，汇总行显示了之前描述的四个 DHCPv6 数据包：Solicit、Advertise、Request 和 Reply。数据包编号 47 被标记，并在图的下方显示了该回复数据包的详细信息。

让我简要描述一下在截图中看不到详细信息的三个数据包：

  • 在数据包编号 40 中，我们看到了 Solicit 消息。源地址是客户端的链路本地地址，目的地址是 All_DHCP_Relay_Agents_and_Servers 的著名多播地址（ff02::1:2）。UDP 源端口是 546，UDP 目标端口是 547。

  • 数据包编号 44 是 DHCP 服务器的 Advertise 消息。源地址是 DHCP 服务器的地址，数据包发送到客户端的链路本地地址。

  • 在数据包 46 中，客户端将其 DHCPv6 请求发送到多播地址ff02::1:2。

数据包编号 47 是 DHCP 服务器的 Reply 消息，这是截图中可以看到详细信息的数据包。它从 DHCP 服务器的地址发送到客户端的链路本地地址。UDP 源端口是 547（服务器端口），UDP 目标端口是 546（客户端端口）。DHCPv6 头部的第一个字段显示消息类型（Reply 为 7，参考表 5-4 获取所有选项类型编号）。下一个字段包含事务 ID。对于给定的 DHCP 通信，事务 ID 必须相同（在故障排除时非常重要）。Reply 消息包含服务器标识符（选项 2）、客户端标识符（选项类型 1）、身份关联（选项类型 3），包括两个定时器 T1 和 T2，IA 地址选项（选项类型 5），包括 IPv6 地址和生命周期参数，域名搜索列表（选项类型 24），DNS 递归名称服务器（选项类型 23）以及完全限定域名（FQDN，选项类型 39）。

无状态 DHCP

在使用无状态地址自动配置来获取 IP 地址信息的环境中，客户端无法配置额外的信息，如 DNS 信息或其他选项。讨论了几种解决方案，其中一种是将此类选项添加到路由器广告中。最终，RFC 3736 指定了一种新的服务，称为 IPv6 的无状态 DHCP 服务。无状态 DHCP 服务器仅实现 DHCPv6 规范的一个子集。其使用要求主机已配置 IPv6 地址。

无状态 DHCP 服务器对包含选项请求选项（选项类型 6）的信息请求消息（消息类型 11）做出回复，并发送 Reply 消息（消息类型 7）。无状态 DHCP 服务器还可以充当中继代理。这使得通过 SLAAC 配置链路上一部分客户端时，可以从无状态 DHCP 服务器获取额外信息。同时，其他客户端使用有状态地址自动配置，它们的 DHCP 消息由充当中继代理的无状态 DHCP 服务器转发。

最后，这两个选项都已实现。无状态 DHCPv6 被开发出来，RFC 6106 定义了“用于递归 DNS 服务器和 DNS 搜索列表的路由器广告选项”。为了使其生效，必须在路由器和客户端侧都实现。目前，微软在 Windows 上不支持该功能。对于临时网络等场景，这可以作为一个不需要有状态或无状态 DHCPv6 服务器的客户端配置的良好选项。在企业环境中，大多数情况下会选择 DHCPv6 服务器，因为它能够提供可追溯性，并且可以配置其他附加选项。

前缀委派

RFC 3633《IPv6 前缀选项》定义了可以用来从委派路由器或 DHCPv6 服务器向具有 DHCPv6 客户端功能的请求路由器发送前缀信息的选项。这在委派路由器无法了解与请求路由器相连网络拓扑的环境中非常有用。ISP 网络中的委派路由器或 DHCPv6 服务器使用此选项为客户网络中的路由器配置其前缀。例如，委派路由器可以为客户网络中的边界路由器分配一个 /48 前缀。边界路由器可以将 /48 前缀划分为 /64 子网，并通过路由器广告广播这些前缀。DHCP 前缀委派（DHCP-PD）独立于 DHCP 地址分配，但这两者可以结合使用。

RFC 6603《基于 DHCPv6 的前缀委派的前缀排除选项》更新了 RFC 3633。前缀排除机制适用于使用基于 DHCPv6 的前缀委派的部署场景，其中单一的汇总路由/前缀必须代表一个客户，而不是使用一个前缀来连接委派路由器和请求路由器之间的链路，另一个前缀用于客户网络。该机制允许委派路由器在与请求路由器交换 DHCPv6 消息的链路上，使用委派前缀集中的一个前缀。此机制适用于每个请求路由器都处于其自身的第二层域的网络。

安全性考虑

基于 DHCP 功能的攻击在 IPv4 世界和 IPv6 世界中都可能发生。需要关注的攻击点是相同的：

  • 外部未知的 DHCP 服务器向 DHCP 客户端分配虚假的地址

  • 内网中存在故障或恶意的 DHCP 服务器，它们向 DHCP 客户端分配虚假的地址或其他虚假的配置信息。

  • 连接到公司网络的未知外部客户端并获得内部地址

  • 恶意客户端故意耗尽 IP 地址，导致有效客户端无法获取有效的 IP 地址和/或配置信息

  • 恶意客户端通过发送大量请求使 DHCP 服务器无法响应有效请求

为了防止来自公司外部的 DHCP 服务器攻击网络，可以通过防火墙关闭 DHCP 端口来提供有效的保护。保护内网免受内部 DHCP 服务器的攻击同样重要。甚至不需要是恶意攻击，很多问题都来自于配置不当的测试服务器。恶意的 DHCP 服务器可能会通过伪造信息攻击客户端。例如，可能配置错误的 DNS 或 NTP 服务器，或者可能配置为无法再与本地网络通信。为了防范此类攻击，应使用认证机制（见下文）。另一种保护方式是使用 DHCP Guard，详细内容可参见 第六章中 首次跳跃安全 部分的描述。

对于 DHCPv4，防止此类攻击的方式有限。防火墙仅能防御外部攻击。除了 DHCPv4 外，只有通过厂商解决方案的形式才能使用 DHCP 通信的认证功能。

DHCPv6 的规范包括一个认证机制，该机制基于 DHCPv4 的认证（RFC 3118）。新的主机必须在接收来自 DHCP 服务器的配置信息之前获得授权和认证，消息的发送者必须经过认证，并且消息的内容必须得到保护。

以下部分概述了 RFC 3315 中指定的认证机制。如果你不熟悉安全概念和术语，请首先参考 第六章。

中继代理与 DHCP 服务器之间消息的安全

为了确保中继代理与 DHCP 服务器之间的安全消息交换，使用 IPsec（传输模式和 ESP）。在每个中继代理与其通信对等方之间，必须建立独立的双向信任关系。如果消息内容不被认为是机密的，则不需要加密（无加密）。由于中继代理和 DHCP 服务器位于企业内部网络中，因此可以使用私钥。

除此之外，DHCP 服务器和中继代理会配置可信通信对等方的地址。因此，未知的 DHCP 服务器或中继代理无法侵入通信。

DHCP 认证

DHCP 消息的认证可以通过使用认证选项（选项 11）来实现。认证选项中携带的认证信息可以用来可靠地识别 DHCP 消息的来源，并确认 DHCP 消息的内容没有被篡改。

图 5-13 显示了认证选项的格式。

认证选项的格式图 5-13。认证选项的格式

可以使用多种认证协议与认证选项一起使用。RFC 3315 中规定了两种此类协议：延迟认证协议和重新配置密钥认证协议（RFC 3315 第二十一部分）。如果选择延迟认证协议，则使用协议号 2。如果选择重新配置密钥认证协议，则使用协议号 3。未来可能会通过独立的 RFC 指定其他协议。

不幸的是，DHCPv6 认证的支持有限。具体来说，Microsoft 在 Windows 上不支持此功能。

进一步发展

IP 地址管理是高效网络管理的重要方面。IETF DHCP 工作组正在进行大量工作，以优化 DHCP。DHCP 工作组是获取关于 DHCP（IPv4 和 IPv6）当前状态以及可能的未来发展信息的最佳场所。

注意

DHCP 工作组可以在datatracker.ietf.org/wg/dhc找到。

特别关注的是如何管理双栈网络或仅 IPv6 网络。目前，IPv4 接口的配置使用 DHCPv4，而 IPv6 接口的配置使用 DHCPv6。因此，在双栈网络中，我们需要同时配置 DHCPv4 和 DHCPv6 服务器。需要特别注意，避免两个 DHCP 服务器之间出现重叠和矛盾的配置。RFC 4477《动态主机配置协议（DHCP）：IPv4 和 IPv6 双栈问题》讨论了这些挑战。另一个越来越重要的场景是仅 IPv6 网络。即使在这些情况下，IPv4 可能作为 IPv6-only 网络中的一种服务，主机仍然可能需要一些 IPv4 配置的信息。

当前，工作组正在研究草案，这些草案将提供通过 IPv6 传输或封装在 DHCPv6 消息中的 DHCPv4 信息。一份草案描述了为 DHCPv6 服务器定义 IPv4 选项。这份名为《通过仅 IPv6 网络配置 IPv4 信息》的草案提供了使用案例的概述，并对可能的解决方案进行了总结和讨论。有关当前草案的详细信息，请参阅本章末尾的草案参考列表。

动态更新 DNS

随着 DHCP 和自动配置在动态 IP 地址配置中的广泛应用，DNS 动态更新的需求也随之产生，用于记录的添加和删除。RFC 2136 引入了名为动态 DNS（DDNS）机制。BIND 8 和 9 版本以及许多流行的 DNS 实现均支持此机制。更新功能通常由 DHCP 等应用程序使用，但也可以在主机上实现。对于 IPv6，动态地址通常通过无状态地址自动配置（SLAAC）进行分配，这意味着网络中可能没有 DHCP 服务器。因此，每个主机上都需要一个 DNS 更新机制来更新其 DNS 记录。进行 DDNS 更新时，需要考虑重要的安全方面。必须控制哪些节点被授权修改 DNS 记录。必须实现更新策略，并应使用事务签名（TSIG；参见 RFC 2845）或域名系统安全扩展（DNSSEC；参见 RFC 3007、4033、4034 和 4035）机制。RFC 4339《IPv6 主机配置 DNS 服务器信息方法》讨论了 IPv6 主机的一些通用 DNS 方面。

对于通过 DHCPv6 配置的主机，RFC 4704 定义了一种客户端 FQDN（完全限定域名）选项，可以将其添加到 Solicit、Request、Renew 或 Rebind 消息中。这允许 DHCPv6 客户端或服务器相应地更新 DNS。

对于使用 SLAAC 配置的主机，即将定义一种类似的机制。目前正在进行一项草案，名为“使用 DHCPv6 在 DNS 中注册自生成的 IPv6 地址”。该草案定义了一种新的 DHCPv6 消息类型，客户端可以使用该类型请求 DHCPv6 服务器动态地将 FQDN 选项添加到 DNS 中。

DNS

在 IPv4 世界中，DNS 用于进行名称到地址的映射，反之亦然。IPv6 世界中这一点没有变化。实际上，由于 IPv6 地址的长度，DNS 的需求更大。混合 IPv4/IPv6 环境需要在 DNS 中有多个主机条目。与两种 TCP/IP 协议版本通信的主机需要至少两个 DNS 条目——一个是其 IPv4 地址，另一个是其 IPv6 地址。为 IPv6 主机定义了一种新的 DNS 记录类型。RFC 3596 定义了 AAAA 类型记录（称为 Quad-A）。RFC 2874 定义了 A6 类型记录，该记录旨在使网络重新编号和前缀变更的管理更加简便。A6 已被移至实验状态，并且不再使用。其他 DNS 记录类型（NS 和 PTR 记录）保持不变，仅调整以支持 IPv6 地址格式。

AAAA 记录和 IP6.ARPA

RFC 3596 描述了基于 AAAA 记录的 IPv6 实现的 DNS 扩展。该记录类型可以存储 128 位的 IPv6 地址，且此类型记录的 DNS 值为 28（十进制表示）。一个具有多个 IPv6 地址的主机会为每个地址创建一个 AAAA 记录。相应的反向查找域是 IP6.ARPA。反向查找记录是类型为 12 的 PTR 记录。

一个 AAAA 类型的记录可以如下所示：

moon.universe.com.   IN   AAAA   2001:db8:1:2:3:4:567:89ab

对于反向查询，每个 IP6.ARPA 下的子域级别表示 128 位地址的 4 位。最低有效位出现在域名的最左侧。在这种情况下，不允许省略前导零，因此前面示例的 PTR 记录如下所示：

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA.
IN  PTR   moon.universe.com.

请注意，在 DNS 中表示反向 IPv6 地址的方式有多种。这取决于具体的实现，因此请参考您的供应商文档以了解预期的格式。

注意

最初，反向域名被称为 IP6.INT。它已经被弃用（RFC 4159），并由 IP6.ARPA 替代。

DNS 服务器

BIND 在版本 8.4 及更高版本和版本 9 中实现了 IPv6 DNS。

基于这些版本的 BIND 实现支持 IPv6。一个好的 BIND 参考网站是互联网系统联盟主页。该网站还列出了基于 BIND 的供应商实现，并提供了适用于不同版本微软操作系统的 BIND 版本的链接。

在 Unix 上配置名称服务器最重要的文件是/etc/named.conf。该文件本身包含了如何配置的详细信息。为了使名称解析在 IPv6 上工作，您需要添加一个重要的条目：listen-on-v6 { any }。此条目告诉名称服务器监听 IPv6 查询。然后，使用所有 IPv6 主机的条目更新 /var/named。

我们的区域记录文件中的条目如图 5-14 所示。

区域记录文件图 5-14. 区域记录文件

注意

有关 BIND 和 DNS 配置的详细解释，请参考 Cricket Liu 的《DNS 和 BIND 在 IPv6 上》（O'Reilly）。

DNS 解析器和 DNS 设计

解析器是 DNS 通信中的客户端部分。解析器向 DNS 服务器发送关于 IP 地址的 DNS 请求。它可以是操作系统的一部分，也可以是一个应用程序。DNS 服务器也实现了一个解析器，用于向其他 DNS 服务器发送 DNS 请求。

当一个双栈主机向 DNS 服务器查询服务名称时，例如在浏览器中输入 URL，客户端将发送两个 DNS 请求，一个用于 A 记录，另一个用于 AAAA 记录。DNS 服务器可以根据其配置返回 A 记录、AAAA 记录或两者都返回。如果客户端接收到两个地址，它将根据默认地址选择规则（RFC 6724），优先选择原生 IPv6 地址而非 IPv4 地址。

注意

默认地址选择在第二章中讨论。

解析 DNS 名称时使用的传输协议与实际使用的连接是独立的。例如，Windows XP 无法通过 IPv6 解析 DNS 名称。Windows XP 客户端始终需要一个可以通过 IPv4 访问的 DNS 服务器。但当客户端支持双栈并且 DNS 服务器返回 AAAA 记录时，Windows XP 客户端可以通过 IPv6 发起会话。

如果客户端获取到 AAAA 记录，但没有 IPv6 连接或仅有非常差的连接，就会出现问题。IPv6 协议栈通常默认配置为优先使用 IPv6 而不是 IPv4，因此客户端会尝试通过 IPv6 进行连接。但是，由于它没有连接，客户端会长时间等待，直到最终切换回使用 IPv4（如果它为同一服务获取到了 A 记录）。在大多数情况下，用户无法理解为什么访问该网站如此缓慢，并且可能会把责任归咎于网站所有者。

这就是为什么在早期（在 2012 年 6 月 6 日的 IPv6 世界发布日之前），像 Google 和 Facebook 这样的大型双栈网站没有为其主域名提供 AAAA 记录的原因。如果你想在那个时期通过 IPv6 访问 Google 或 Facebook，你必须使用一个特定于 IPv6 的域名，例如 ipv6.google.com。这些大型网站不希望因用户从 IPv6 网络连接质量差的网络中访问而导致性能下降。如果用户在访问 Google 时遇到长时间的超时，用户会认为 Google 性能差，但实际上超时是由于无法通过 IPv6 连接，并且正在等待通过 IPv4 连接。这些网站通常会为具有良好 IPv6 性能的 ISP 使用 DNS 白名单，在这种情况下，它们可以确定来自该 ISP 的用户能够无问题地通过 IPv6 访问网站。因此，只有当你连接到这样的提供商时，才会为 www.google.com 获取到 AAAA 记录。2012 年 6 月 6 日的世界 IPv6 发布日表明，只有极少数用户遇到了问题。从那时起，许多这些网站已经永久启用了主域名的 AAAA 记录。欲了解更多关于世界 IPv6 发布日的信息，请访问 www.worldipv6launch.org。该网站展示了参与者和测量的相关信息。

注意

如果你想了解当前全球 IPv6 部署的最新情况，有两个网站可以参考：Google 统计数据 和 Cisco 统计数据。

Happy Eyeballs

为了改善双栈互联网中的用户体验，定义了一项规范，称为 Happy Eyeballs。它在 RFC 6555 中进行了定义。

当客户端获取到两个地址用于某个服务时，一个是 IPv4 地址，一个是本地 IPv6 地址，默认情况下，它会通过发起 TCP 握手连接到 IPv6 地址。如果请求没有得到响应，客户端将在长时间超时后，改为使用 IPv4。若客户端到服务的 IPv6 路径中断或非常慢，就可能发生这种情况。通过实现 Happy Eyeballs 机制，客户端将同时尝试两种协议，并选择较快的协议进行连接。实现这一功能有几种方法。图 5-15 展示了这种算法。

IPv6 连接中断的 Happy Eyeballs图 5-15. IPv6 连接中断的 Happy Eyeballs

在这种情况下，客户端向 DNS 服务器发送两个请求，分别是http://www.example.com的 A 请求和 AAAA 请求。该服务是双栈的，因此 DNS 返回了两个地址，一个 IPv4 地址和一个 IPv6 地址。接下来，客户端发出了两个 TCP 同步请求（TCP 握手中的第一个数据包），一个通过 IPv6，一个通过 IPv4。在这种情况下，IPv6 连接中断，因此客户端仅收到来自 IPv4 的响应（SYN+ACK）。在下一个数据包中，客户端通过 TCP 确认握手，现在与服务的通信将通过 IPv4 进行。

不同的操作系统和浏览器对 Happy Eyeballs 有不同的实现方式。RFC 6555 描述了 Google Chrome 和 Firefox 的实现方式，如下所示：

  1. 调用getaddrinfo()，该函数返回一个按主机地址优先级排序的 IP 地址列表。

  2. 用列表中的第一个地址（例如 IPv6）发起连接尝试。

  3. 如果该连接在短时间内未完成（Firefox 和 Chrome 使用 300 毫秒），则使用属于另一个地址族的第一个地址（例如 IPv4）发起连接尝试。

  4. 首个建立的连接将被使用，其他连接会被丢弃。

微软在 Internet Explorer 中未实现 Happy Eyeballs，但它有一个类似的机制，根据协议性能优化连接建立。苹果也有一个与 Happy Eyeballs 类似的操作系统特定实现。

名称空间分割

关于 DNS 设计，有一个重要的点需要注意：名称空间分割。当解析器尝试解析一个名称时，它将从根开始，并跟随转发信息，直到到达该名称的权威名称服务器。如果解析器恰好到达一个只能通过解析器无法使用的协议访问的名称服务器，则该名称无法被解析，DNS 查询失败。

因此，当 IPv6 在互联网中得到越来越多部署时，名称空间可能会被碎片化，因为可能会有只能通过 IPv4 到达的名称服务器，同时会有越来越多只能通过 IPv6 到达的名称服务器。因此，我们必须找到机制，以避免解析过程中有两个名称服务器使用不同的协议（IP 版本），从而导致解析链断裂的情况。

下面是为避免这种情况而推荐的 DNS 指导方针（引用自 RFC 3901）。为了保持名称空间的连续性，建议采取以下管理策略：

  • 每个递归名称服务器应仅支持 IPv4 或双栈。

    这排除了仅支持 IPv6 的递归服务器。然而，可能会设计配置，让一串仅支持 IPv6 的名称服务器将查询转发给一组执行递归查询的双栈递归名称服务器。

  • 每个 DNS 区域应至少由一个可通过 IPv4 到达的权威名称服务器提供服务。

    这排除了仅由 IPv6-only 权威名称服务器提供服务的 DNS 区域。

注意：区域验证过程应确保每个子委托区域的名称服务器至少有一个 IPv4 地址记录。

对于 IPv6 的集成，规划双栈 DNS 服务可能是一个好主意，因为这是防止碎片化的最佳且最灵活的方式。使用 BIND9，您还可以配置一个双栈服务器。当一个递归名称服务器需要查找仅由不支持相同协议的名称服务器提供服务的区域的数据时，它可以将递归查询转发到双栈服务器。

确保仅在服务完全通过 IPv6 可达时配置 AAAA 记录，否则您的客户端可能会经历长时间的超时，甚至完全无法访问服务。我们还必须避免仅在 DNS 中输入主机名。一台主机可能是双栈的（并且有两个 DNS 条目），而该主机上运行的某些服务可能是 IPv4 服务或 IPv6 服务。在大型企业中，出于管理原因，可能建议不要在双栈主机上混合 IPv4 和 IPv6 服务，而是将 IPv4 服务放在 IPv4 主机上，将 IPv6 服务放在 IPv6 主机上。同时，您必须确保所有获取 AAAA 记录的客户端能够通过 IPv6 连接到该服务所在的网络。如果服务在两种协议上都可用，请确保 IPv6 服务优先于 IPv4 服务，这样您的流量就可以随着时间的推移逐步转向更多地使用 IPv6，只要它可用。

跟踪文件中的 DNS 通信

图 5-16 显示了跟踪文件中的 DNS 查询和应答。

跟踪文件中的 DNS 通信图 5-16. 跟踪文件中的 DNS 通信

客户端向 DNS 服务器发出对 nsv6.ipv6class.com 的 DNS 请求。在第 5 包中，客户端请求一个 A 记录，并在第 6 包中收到没有答案记录的回复。请求的服务是仅支持 IPv6 的服务，因此没有 A 记录。在第 7 包中，客户端请求一个 AAAA 记录，并在第 8 包中收到答案记录。第 8 包的详细信息显示在图的下半部分。DNS 事务 ID 是 099c2（在请求和回复中均相同）。标志位被设置为响应、权威服务器、期望递归和可用递归。在其下方，你可以看到查询和对应的答案记录，包含生存时间和 IPv6 地址。

在这种情况下，整个 DNS 通信都通过 IPv6 进行。如前所述，也可以先通过 IPv4 进行 DNS 解析，然后通过 IPv6 连接到仅支持 IPv6 的服务。

下一章讨论了 IPv6 的安全性。

参考文献

以下是本章中提到的最重要的 RFC 和草案的列表。有时，我会列出一些额外的与主题相关的 RFC 供你个人进一步学习。

RFC 文档

  • RFC 1195，“在 TCP/IP 和双重环境中使用 OSI IS-IS 路由”，1990 年

  • RFC 1321，“MD5 消息摘要算法”，1992 年

  • RFC 2080，“IPv6 的 RIPng”，1997 年

  • RFC 2104，“HMAC：消息认证的密钥散列”，1997 年

  • RFC 2136，“域名系统中的动态更新”，1997 年

  • RFC 2149，“基于 MARS 的 ATM 组播的多播服务器架构”，1997 年

  • RFC 2205，“资源保留协议（RSVP）——版本 1 功能规范”，1997 年

  • RFC 2210，“RSVP 在 IETF 综合服务中的应用”，1997 年

  • RFC 2324，“超文本咖啡壶控制协议（HTCPCP/1.0）”，1998 年

  • RFC 2328，“OSPF 第 2 版”，1998 年

  • RFC 2362，“协议无关组播——稀疏模式（PIM-SM）：协议规范”，1998 年

  • RFC 2365，“管理作用域的 IP 组播”，1998 年

  • RFC 2430，“差异化服务和流量工程（PASTE）的提供者架构”，1998 年

  • RFC 2453，“RIP 第 2 版”，1998 年

  • RFC 2464，“IPv6 数据包在以太网网络上传输”，1998 年

  • RFC 2467，“IPv6 数据包在 FDDI 网络上传输”，1998 年

  • RFC 2474，“IPv4 和 IPv6 头部中的差异化服务字段（DS 字段）定义”，1998 年

  • RFC 2475，“差异化服务架构”，1998 年

  • RFC 2491，“IPv6 在非广播多址接入（NBMA）网络上的应用”，1999 年

  • RFC 2492，“IPv6 在 ATM 网络上的应用”，1999 年

  • RFC 2597，“有保证转发 PHB 组”，1999 年

  • RFC 2590，“IPv6 数据包在帧中继网络上传输规范”，1999 年

  • RFC 2710，“IPv6 的多播监听发现（MLD）”，1999 年

  • RFC 2715，“多播路由协议的互操作性规则”，1999 年

  • RFC 2845，“DNS 的密钥事务认证（TSIG）”，2000 年

  • RFC 2884，“IP 网络中显式拥塞通知（ECN）的性能评估”，2000 年

  • RFC 2894，“IPv6 路由器重新编号”，2000 年

  • RFC 2914，“拥塞控制原则”，2000 年

  • RFC 2963, “区分服务的速率自适应整形器”，2000

  • RFC 2983, “区分服务与隧道”，2000

  • RFC 2998, “基于区分服务网络的集成服务操作框架”，2000

  • RFC 3006, “在可压缩流的存在下集成服务”，2000

  • RFC 3007, “安全域名系统（DNS）动态更新”，2000

  • RFC 3008, “域名系统安全（DNSSEC）签名授权”，2000

  • RFC 3086, “每域区分服务行为定义及其规范规则”，2001

  • RFC 3118, “DHCP 消息的认证”，2001

  • RFC 3124, “拥塞管理器”，2001

  • RFC 3140, “每跳行为标识码”，2001

  • RFC 3162, “Radius 与 IPv6”，2001

  • RFC 3168, “IP 中显式拥塞通知（ECN）的加入”，2001

  • RFC 3246, “加速转发 PHB”，2002

  • RFC 3247, “新的 EF PHB（加速转发每跳行为）定义的补充信息”，2002

  • RFC 3260, “区分服务的新术语和澄清”，2002

  • RFC 3289, “区分服务架构的管理信息库”，2002

  • RFC 3290, “区分服务路由器的非正式管理模型”，2002

  • RFC 3306, “基于单播前缀的 IPv6 组播地址”，2002

  • RFC 3307, “IPv6 组播地址分配指南”，2002

  • RFC 3315, “IPv6 动态主机配置协议（DHCPv6）”，2003

  • RFC 3317, “区分服务服务质量政策信息库”，2003

  • RFC 3353, “多协议标签交换（MPLS）环境下的 IP 组播概述”，2002

  • RFC 3569, “源特定组播（SSM）概述”，2003

  • RFC 3590, “组播监听发现（MLD）协议的源地址选择”，2003

  • RFC 3596, “支持 IP 版本 6 的 DNS 扩展”，2003

  • RFC 3633, “IPv6 前缀选项用于动态主机配置协议（DHCP）版本 6”，2003

  • RFC 3646, “IPv6（DHCPv6）动态主机配置协议的 DNS 配置选项”，2003

  • RFC 3717, “光网络上的 IP：框架”，2004

  • RFC 3736, “无状态动态主机配置协议（DHCP）服务用于 IPv6”，2004

  • RFC 3810, “IPv6 的组播监听发现版本 2（MLDv2）”，2004

  • RFC 3901, “DNS IPv6 传输操作指南”，2004

  • RFC 3956, “在 IPv6 组播地址中嵌入会面点（RP）地址”，2004

  • RFC 3971, “安全邻居发现（SEND）”，2005

  • RFC 3972, “加密生成地址（CGA）”，2005

  • RFC 3973, “协议独立的组播—密集模式（PIM-DM）：协议规范（修订版）”，2005

  • RFC 4033, “DNS 安全简介和要求”，2005

  • RFC 4034, “DNS 安全扩展的资源记录”，2005

  • RFC 4035, “DNS 安全扩展的协议修改”，2005

  • RFC 4074, “针对 IPv6 地址的 DNS 查询常见不当行为”，2005

  • RFC 4076, “IPv6 无状态动态主机配置协议（DHCPv6）重新编号要求”，2005

  • RFC 4094, “现有服务质量信令协议的分析”，2005

  • RFC 4135, “检测 IPv6 网络附加的目标”，2005

  • RFC 4159, “废弃 “ip6.int””，2005

  • RFC 4192, “没有标志日的 IPv6 网络重新编号程序”，2005

  • RFC 4243, “动态主机配置协议（DHCP）中继代理选项的供应商特定信息子选项”，2005

  • RFC 4271, “边界网关协议 4（BGP-4）”，2006

  • RFC 4282, “网络接入标识符”，2005

  • RFC 4286, “多播路由器发现（MRD）”，2005

  • RFC 4338, “通过光纤通道传输 IPv6、IPv4 和地址解析协议（ARP）数据包”，2006

  • RFC 4339, “IPv6 主机配置 DNS 服务器信息的方法”，2006

  • RFC 4361, “DHCPv4 的节点特定客户端标识符”，2006

  • RFC 4472, “IPv6 DNS 的操作考虑与问题”，2006

  • RFC 4477, “动态主机配置协议（DHCP）：IPv4 和 IPv6 双栈问题”，2006

  • RFC 4489, “生成链路范围 IPv6 多播地址的方法”，2006

  • RFC 4601, “协议独立多播—稀疏模式（PIM-SM）：协议规范（修订版）”，2006

  • RFC 4604, “使用 MLDv2 进行源特定多播”，2006

  • RFC 4703, “解决动态主机配置协议（DHCP）客户端之间的完全限定域名（FQDN）冲突”，2006

  • RFC 4704, “IPv6 动态主机配置协议（DHCPv6）客户端完全限定域名（FQDN）选项”，2006

  • RFC 4760, “BGP-4 的多协议扩展”，2007

  • RFC 4944, “在 IEEE 802.15.4 网络上传输 IPv6 数据包”，2007

  • RFC 4957, “用于检测网络附加的链路层事件通知”，2007

  • RFC 5015, “双向协议独立多播（BIDIR-PIM）”，2007

  • RFC 5072, “通过 PPP 的 IPv6”，2007

  • RFC 5172, “使用 IPv6 控制协议的 IPv6 数据报压缩协商”，2008

  • RFC 5308, “使用 IS-IS 路由 IPv6”，2008

  • RFC 5340, “OSPF 用于 IPv6”，2008

  • RFC 5796, “PIM-SM 链路本地消息的认证与机密性”，2010

  • RFC 5838, “OSPFv3 中的地址族支持”，2010

  • RFC 5887, “重新编号仍需改进”，2010

  • RFC 5942, “IPv6 子网模型：链路与子网前缀之间的关系”，2012

  • RFC 6085, “以太网中 IPv6 多播数据包的地址映射”，2011

  • RFC 6104, “IPv6 路由器广告问题陈述”，2011

  • RFC 6105, “IPv6 路由器广告保护”，2011

  • RFC 6106, “IPv6 路由器广告 DNS 配置选项”，2010

  • RFC 6119, “IS-IS 中的 IPv6 流量工程”，2011

  • RFC 6221, “轻量级 DHCPv6 中继代理”，2011

  • RFC 6226, “PIM 组到 rendezvous 点映射”，2011

  • RFC 6282, “基于 IEEE 802.15.4 网络的 IPv6 数据报压缩格式”，2011

  • RFC 6294, “IPv6 流标签提议的使用案例调查”，2011

  • RFC 6308, “互联网多播地址分配架构”，2011

  • RFC 6326, “大量链路的透明互联（TRILL）使用 IS-IS”，2011

  • RFC 6334, “IPv6 动态主机配置协议（DHCPv6）双栈精简版选项”，2011

  • RFC 6398, “IP 路由器警报考虑事项和使用”，2011

  • RFC 6422, “中继提供的 DHCP 选项”，2011

  • RFC 6434, “IPv6 节点要求”，2011

  • RFC 6436, “更新 IPv6 流标签规范的理由”，2011

  • RFC 6437, “IPv6 流标签规范”，2011

  • RFC 6438, “在隧道中使用 IPv6 流标签进行等成本多路径路由和链路聚合”，2011

  • RFC 6553, “低功耗和丢包网络（RPL）中携带 RPL 信息的数据平面数据报的 RPL 选项”，2012

  • RFC 6554, “低功耗和丢包网络（RPL）中的源路由的 IPv6 路由头”，2012

  • RFC 6555, “快乐眼球：双栈主机的成功经验”，2012

  • RFC 6556, “测试眼球幸福度”，2012

  • RFC 6603, “基于 DHCPv6 的前缀委派的前缀排除选项”，2012

  • RFC 6724, “互联网协议版本 6（IPv6）的默认地址选择”，2012

  • RFC 6775, “面向低功耗无线个人区域网络（6LoWPANs）优化的 IPv6 邻居发现”，2012

  • RFC 6822, “IS-IS 多实例”，2012

  • RFC 6845, “OSPF 混合广播和点对多点接口类型”，2013

  • RFC 6853, “DHCPv6 冗余部署考虑事项”，2013

  • RFC 6895, “域名系统（DNS）IANA 考虑事项”，2013

  • RFC 6939, “DHCPv6 中的客户端链路层地址选项”，2013

  • RFC 6977, “触发 DHCPv6 中继代理重新配置”，2013

  • RFC 6992, “IPv4 嵌入式 IPv6 数据包的路由”，2013

  • RFC 7031, “DHCPv6 故障转移要求”，2013

  • RFC 7037, “DHCPv6 中继代理的 Radius 选项”，2013

  • RFC 7078, “使用 DHCPv6 分发地址选择策略”，2014

  • RFC 7084, “IPv6 客户端边缘路由器的基本要求”，2013

  • RFC 7098, “在服务器群集中的负载均衡中使用 IPv6 流标签”，2013

草案

草案可以在 www.ietf.org/ID.html 找到。要定位草案的最新版本，请参考 datatracker.ietf.org/public/pidtracker.cgi。你可以输入草案名称而不加版本号，系统将显示最新版本。如果草案未显示，可能已被删除。如果它已作为 RFC 发布，RFC 编号将显示。tools.ietf.org/wg 也是一个非常有用的站点。关于标准化过程、RFC 和草案的更多信息可以在 附录 A 中找到。

这是我在本章中引用的一些草案列表，以及与本章主题相关的一些有趣草案：

“通过蓝牙低能耗（BLUETOOTH Low Energy）传输 IPv6 数据包”

draft-ietf-6lo-btle-01

“通过 IEEE 802.11p 网络传输 IPv6 数据包”

draft-petrescu-ipv6-over-80211p-01

“通过 DHCPv6 在 DNS 中注册自生成的 IPv6 地址”

draft-ietf-dhc-addr-registration-04

“在仅有 IPv6 网络上提供 IPv4 配置”

draft-ietf-dhc-v4configuration-05

“通过 DHCPv6 传输的 DHCPv4”

draft-ietf-dhc-dhcpv4-over-dhcpv6-08

“通过 IPv6 传输的 DHCPv4”

draft-ietf-dhc-dhcpv4-over-ipv6-09

“DHCPv6 故障转移设计”

draft-ietf-dhc-dhcpv6-failover-design-04

“DHCPv6 的 DHC 负载均衡算法”

draft-ietf-dhc-dhcpv6-load-balancing-01

“为 DHCP 委托前缀填充 DNS 反向树”

draft-ietf-dhc-dns-pd-01

“DHCPv6/SLAAC 地址配置交互问题陈述”

draft-ietf-v6ops-dhcpv6-slaac-problem-00

“DHCPv6/SLAAC 交互操作指导”

draft-liu-v6ops-dhcpv6-slaac-guidance-01

“减少 IPv6 邻居发现中的组播”

draft-yourtchenko-colitti-nd-reduce-multicast-00

“DHCPv6 与基于 RA 的主机配置比较”

draft-yourtchenko-ra-dhcpv6-comparison-00

第六章：IPv6 的安全性

IPv4 的开发者并没有过多考虑安全性。早期的“互联网”仅连接了一些可信的网络，这些网络由一些有远见的研究人员控制。这些网络的控制者以及被允许使用网络资源的个人，默认被信任不会进行恶意或破坏性的行为。这也是原始 IP 架构没有包含一个可以供所有应用程序使用的安全框架的原因。如果需要安全性，通常只包括初步的身份验证/授权，并且这些安全功能是嵌入在应用程序代码中的（例如，Telnet 和 FTP 的密码）。许多年后，IPsec 在 IPv4 已经广泛部署后才被引入。因此，IPsec 需要被后期集成到现有的部署中。由于互操作性和性能问题，以及它是后期开发的，IPsec 并不像它在许多 IPv4 场景中应该有的那样广泛部署。与此不同的是，IPv6 从一开始就意识到，必须将基本的安全功能纳入基础协议中，以便在任何互联网平台上使用。在 IPv6 的早期，符合标准的 IPv6 实现必须包括 IPsec，以便在适当配置后实现更加安全的通信。这个严格的规定最近有所放宽，但稍后我们会详细讨论。在深入技术细节之前，我想先谈一些通用的安全概念和实践。

一般安全概念

为了保护数据，必须意识到可能的威胁。人们通常仅关注来自外部网络的恶意攻击。一个全面的安全概念需要考虑许多其他方面。以下是一些可能的弱点：

  • 不足或不存在的 IT 安全概念及相应的规定

  • 不遵守或不足够控制 IT 安全规定

  • 权限篡夺（密码盗窃，特权升级）

  • 错误使用或故障管理 IT 系统

  • 权限滥用

  • 软件中的弱点（例如，运行在超级用户权限下的应用程序中的缓冲区/堆溢出，跨站脚本攻击）

  • IT 设备、软件或数据的篡改、盗窃或破坏（物理安全）

  • 网络窃听（监听有线或无线网络）或消息重放

  • 木马、病毒和蠕虫

  • 安全攻击，如伪装、IP 欺骗、拒绝服务（DoS）攻击、中间人攻击或 DNS 中毒

  • 路由滥用

许多统计数据显示，外部的恶意攻击仅占所有可能风险的一小部分。许多威胁来自内部网络，而且在很多情况下与人为失误或管理不当有关。这些风险中的许多无法通过技术机制控制。本章不是一个整体安全概念的指南；它讨论的是与 IPv6 安全相关的技术方面。

一般安全实践

标准的安全实践包括两个“思维三元组”，即 CIA 和 AAA。CIA 三元组包括：

机密性

存储或传输的信息不能被未授权方读取或篡改。

完整性

任何对传输或存储信息的篡改都可以被检测到。

可用性

相关信息随时可以供授权用户访问。

AAA 三元组包括：

身份验证

确保某个人或群体确实是他们所声称的身份。明确声明身份的行为。常见的身份验证方式包括用户名和密码或 ATM 卡/密码组合。

授权

确保经过身份验证的用户或群体拥有访问其尝试访问的信息的适当权限。常见的实现方式包括访问控制列表（ACL）。

审计

收集资源使用信息的行为。HTTP 服务器的日志是常见的审计形式。

不可否认性 不包括在 CIA/AAA 三元组中。不可否认性意味着任何涉及的方都不能否认特定的行为，如发送、接收或删除信息。

这些安全要求需要由两个基本的安全元素提供：加密（提供机密性）和安全校验和或哈希（提供完整性）。这两种元素的适当组合可以用于提供更复杂的服务，如真实性和不可否认性。

常用的加密方式有两种。第一种称为 秘密密钥密码学，也叫 对称密钥加密，它要求发送者和接收者达成一致，使用共享的秘密（即密钥或密码）来加密和解密交换的信息。常见的对称密钥算法有 AES、DES、3DES、IDEA 和 RC-4。

第二种叫做公钥密码学，也称为非对称加密。非对称加密算法使用一对密钥，包括已知并分发的公钥和个人私钥。当消息使用公钥加密后，接收方使用相应的私钥解密时，只有预定的接收者才能看到加密的消息。这种加密形式可以用于建立机密数据交换。如果此外，消息还使用发送者的私钥加密，并由接收者用相应的公钥解密，则增加了数据源认证和不可否认性安全服务。常见的非对称密钥算法有 RSA、ElGamal 和椭圆曲线密码学（ECC）。

安全的校验和或哈希函数通常提供数据完整性。哈希函数接受任意长度的输入并输出固定长度的代码。该固定长度输出称为信息摘要，或哈希，即原始输入消息的摘要。这些哈希是唯一的，从而提供了消息的完整性。常见的单向哈希函数有 SHA-1 和 MD-5。

IPsec 标准结合了基于对称加密和非对称加密的算法选择，以及单向哈希函数。本章描述了 IPsec 框架和 IPv6 中的安全元素，并讨论了在保护 IPv6 网络时需要注意的特殊问题。

IPsec 基础知识

IPsec，描述于 RFC 4301，定义了 IPv4 和 IPv6 两个版本的 IP 的安全架构。

以下元素是 IPsec 框架的一部分：

  • 网络层的安全要求和机制的一般描述

  • 用于加密的协议（封装安全负载，或 ESP）

  • 用于身份验证的协议（身份验证头，或 AH）

  • 用于加密和身份验证的密码学算法的定义

  • 定义通信对等体之间的安全策略和安全关联

  • 密钥管理

IPsec 的配置在受保护区域和非受保护区域之间创建了一个边界。这个边界可以围绕单个主机或一个网络。管理员指定的访问控制规则决定了跨越边界的数据包的处理方式。安全要求由安全策略数据库（SPD）定义。通常，根据选择器确定的适用 SPD 策略，每个数据包要么通过 IPsec 安全服务保护，要么被丢弃，或者允许绕过 IPsec 保护。选择器是管理员定义的特定流量匹配标准——例如，从子网传输到特定终端主机的特定应用程序。

安全关联

安全关联（SA）是通信对等体之间的协议。协议包含三个元素：一个密钥、一个加密或认证机制以及算法的其他参数。SA 是单向的，每个单独的安全服务都需要一个 SA。这意味着，两个希望加密和认证双向通信的通信对等体需要四个 SA（一个加密对和一个认证对）。双向应用流量——例如，双向 Telnet 连接——也需要在每个通信对等体上配置四个 SA。对等体 A 必须保护其发起的流量和来自对等体 B 的回传流量。它还需要两个额外的 SA，以确保如果对等体 B 发起 Telnet 会话，则该会话及其回传流量也能得到保护。

IPsec 区分了两种传输模式：

传输模式

SA 是在两个端节点之间建立的，并定义了该连接所有 IP 数据包有效载荷的加密或认证方式。IP 头部不会被加密。

隧道模式

SA 通常在两个安全网关（通常是防火墙）之间建立。整个数据包，包括原始 IP 头部，都会通过封装在新头部中进行加密或认证。这是虚拟私人网络（VPN）的基础。

密钥管理

IPsec 提供的大多数安全机制都要求使用加密密钥。为将密钥放置到位，已经定义了一组单独的机制。必须支持手动和自动密钥分发。RFC 4301 指定了 IKEv2（稍后会在本节中描述）作为一种自动化的密钥分发机制。也可以使用其他机制。实际上，IKEv1 已被官方弃用，并将由 IKEv2 替代，但由于 IKEv1 目前仍被广泛使用，因此本书中同时描述了这两个版本。

为了建立安全关联（SA），通信对等体必须就加密算法达成一致并协商密钥。SA 的协商通常通过不安全的路径进行。互联网密钥交换（IKE）定义了一种协议，用于交换和协商 SA 参数。

IKEv1

IKEv1 在 RFC 2409 中定义，并在 RFC 4109 中更新。它由来自三种不同协议的选定功能组成：

ISAKMP（互联网安全关联与密钥管理协议）

ISAKMP 定义了一个用于管理 SA 和密钥交换的框架，但没有详细描述具体过程。因此，它支持不同的密钥交换机制。它在 RFC 5996 中有详细规范。

Oakley 密钥确定协议

Oakley 密钥确定协议用于密钥交换，并在 RFC 2412 中进行了规范。它是 Diffie-Hellman 算法的扩展，仅使用 Oakley 协议的一部分功能。

SKEME（适用于互联网的多功能安全密钥交换机制）

SKEME 是一种快速的密钥交换技术，描述于 IEEE 1996 年网络与分布式系统安全研讨会论文集 中的《SKEME: A Versatile Secure Key Exchange Mechanism for the Internet》，作者 H. Krawczyk。IKE 只使用了 SKEME 协议中定义的一个子集功能。

IKEv1 使用 UDP 端口 500 或 4500，并经历两个阶段。

在第一阶段，ISAKMP 通信对等体协商一个安全的、经过认证的通信通道，称为 ISAKMP 安全关联。请注意，一些实现使用术语 “IKE SA”，该术语与 ISAKMP SA 同义。第一阶段的交换基于 Diffie-Hellman 算法和加密的身份令牌。认证可以通过预共享密钥、使用发送者私钥加密的 RSA 校验和，或使用接收者公钥和其 X.509 证书进行认证提供。

在第二阶段，其他协议（例如 ESP 和/或 AH）的加密算法和密钥可以通过第一阶段建立的安全通信通道进行交换。IKE 第二阶段的结果是生成一个 IPsec SA。这些 IPsec SA 定义了用于保护传输中的流量的安全服务。可以通过第一阶段建立的安全通道协商多个 IPsec SA。这允许协商更细粒度且更灵活的安全服务。IPsec SA 和 ISAKMP SA 都会定期生成新的加密密钥，以提供更高的安全性。通常，IPsec SA 的密钥更新速率高于 ISAKMP SA。

RFC 4109 更新了原始规范。更改旨在确保建议和要求的算法能够反映当前的市场情况。这些更改计划应用于所有 IKEv1 实现。

注意

你可以在 www.iana.org/assignments/ipsec-registry 查找所有 IKEv1 相关和更新的数字及代码。

IKEv2

IKEv2 在 RFC 5996 中进行了规范，合并并因此废弃了以下 RFC：RFC 4306，“Internet Key Exchange (IKEv2) 协议”，RFC 2407，“Internet IP 安全域解释 ISAKMP”，RFC 2408，“Internet 安全关联与密钥管理协议 (ISAKMP)”，以及 RFC 2409，“Internet 密钥交换协议 (IKE)”。IKEv2 带来了诸多改进，尤其是在结合 NAT 穿越使用 IPsec、可扩展认证以及远程地址获取方面。

IKEv2 在 UDP 端口 500 和 4500 上运行，运行 IKEv2 的主机必须接受来自任何端口的数据包并响应这些相同的端口。

初始交换（在 IKEv1 术语中称为第一阶段）通常由两对消息组成。第一对消息协商加密算法，交换一次性密钥（防止重放攻击的数字），并进行 Diffie-Hellman 交换。第二对消息对前面的消息进行认证，交换身份和证书，并建立第一个CHILD_SA。

在 IKEv1 中，SA 生命周期是通过协商的。在 IKEv2 中，SA 的每一端负责执行自己的生命周期策略，并在必要时重新协商 SA。生命周期较短的一端将在生命周期策略不同的情况下请求重新协商。IKE 版本之间的另一个不同之处在于，IKEv2 允许在相同的流量选择器之间使用并行的 SA。这种差异以及其他因素支持在 SAs 之间具有不同服务质量（QoS）要求的流量。因此，与 IKEv1 不同，端点和流量选择器的组合可能无法唯一标识这两个端点之间的 SA。因此，在 IKEv2 中，不能仅通过重复的流量选择器来删除 SA。

通过 NAT 打开 IPsec 连接会带来一些特殊问题。IP 地址的变化会改变校验和，因此它们会失败，且无法被 NAT 修正，因为它们是经过加密保护的。IKEv2 通过协商 UDP 封装 IKE 和 ESP 包来改进对此类情况的支持。端口 4500 保留用于 UDP 封装的 ESP 和 IKE。由于 NAT 通常会转换 TCP 和 UDP 端口号，IPsec 包必须接受来自任何端口的流量，并将其发送回相同的端口。好消息是，我们在 IPv6 网络中不再构建 NAT，因此这个问题不再存在。

注意

你可以在www.iana.org/assignments/ikev2-parameters找到所有相关的、更新的 IKEv2 编号和代码。

IKEv2 的变更摘要可以参考 RFC 5996。以下是一些主要内容（完整列表请参考 RFC）：

  • 在单个文档中定义整个 IKE 协议，取代 RFC 2407、2408 和 2409，并整合后续的变更以支持 NAT 穿越、可扩展认证和远程地址获取。

  • 通过将八种不同的初始交换替换为一个四消息交换，简化 IKE。

  • 通过将初始交换限制为两轮往返（四条消息），并允许在该交换中附带CHILD_SA的设置，从而减少 IKE 的延迟。它还增加了初始交换的拒绝服务抗性。

  • 通过使协议可靠，减少可能的错误状态。这是通过要求所有消息都被确认并按顺序排列来实现的。这使得CREATE_CHILD_SA交换从三条消息缩短为两条消息。

  • 尽可能保持现有语法和魔法数字，以使得 IKEv1 的实现能够通过最小的努力增强以支持 IKEv2。

要求在 RFC 4307《用于互联网密钥交换版本 2（IKEv2）的加密算法》中实施的一组算法被指定为必需。这是为了确保不同实现之间的互操作性。

注意

有关相关安全 RFC 和草案的详细概述，请访问 IETF 安全工作组的页面。

IPv6 安全元素

IPsec 描述了可以与 IPv6 和 IPv4 协议一起使用的一般安全机制。这意味着 IPv6 并不比 IPv4 更加安全。

在 IPv6 早期，要求每个 IPv6 堆栈都必须实现 IPsec，并推荐使用 IKE 进行密钥管理。随着 RFC 6434《IPv6 节点要求》的发布，这一严格要求已被降级为“SHOULD”。现在，由厂商决定是否要求他们的 IPv6 产品支持 IPsec（或者由客户要求）。这样做的主要原因是，要求所有类型的特殊设备（例如资源非常有限的传感器，或者具有特殊应用的设备，可能有基于应用的安全方法）都实现完整的 IPsec 实现，似乎不切实际。

另一方面，同一 RFC 声明，实施 IPsec 的节点比以前有更严格的要求。现在，支持 RFC 4301《互联网协议安全架构》是强制性的，其中包括使用 IKEv2 进行自动密钥管理，并要求支持最小集的加密算法，从而使得 IPsec 在不同厂商的实现之间具有更好的互操作性。

IPsec 规范定义了身份验证头（AH）和封装安全负载头（ESP）的协议。在 IPv6 中，这些头部被作为扩展头部包含。IPsec 实现必须支持 ESP，并可以支持 AH。在较早的规范中，要求同时支持这两个协议。现在，由于 ESP 可以提供完整性保护，而在大多数情况下已证明其足够，因此不再强制要求支持 AH。

注意

要了解扩展头部和下一个头部值，请参见第三章。

身份验证头

身份验证头（AH）为在 IP 数据包中传输的所有端到端数据提供完整性和认证（无机密性）。它支持不同的认证机制。它在 RFC 4302 中进行了规范，并通过前导头中的下一个头部值 51 来标识。

AH 位于 IPv6 头部和上层头部之间（例如，TCP、UDP、ICMP）。如果存在扩展头部，它必须放置在逐跳、路由和分片扩展头部之后。

AH 的格式如图 6-1 所示。

身份验证头格式图 6-1. 身份验证头格式

每个字段的说明如下：

下一个头部 (1 字节)

下一个头部字段标识紧随身份验证头后的头部类型。它使用表 3-1 中列出的值。

有效载荷长度 (1 字节)

描述头部的长度，单位为四字节，不包括前八个字节的计算。此长度指示是必要的，因为 AH 中的身份验证数据的长度可能会根据使用的算法不同而有所不同。

保留 (2 字节)

未使用；设为 0。

安全参数索引 (SPI) (4 字节)

任意 32 位值。接收方使用该值来标识传入数据包所属的安全关联 (SA)。SPI 字段是必需的，并且所有 AH 实现都必须支持将传入流量映射到单播 SA 的机制。如果 IPsec 实现支持多播，则必须额外支持使用为此目的指定的去复用算法将传入的 IPsec 数据报映射到多播 SA。范围为 1 到 255 的 SPI 值由互联网号码分配局 (IANA) 保留以供将来使用。SPI 值为 0 保留供本地实现特定用途，且不得在网络上传输。

序列号 (4 字节)

这个 32 位的序列号是单调递增的计数器值。它必须由发送方设置，但是否使用该值由接收方决定。它确保相同数据的包不会被重复发送，从而防止在单播或单发送方的 SA 中发生重放攻击。对于多发送方 SA，AH 不支持反重放功能，因为 AH 没有机制在多个发送方之间同步数据包计数器。在建立 SA 时，发送方和接收方的值都设置为 0。第一个数据包的值总是 1，每发送一个连续的数据包，值增加 1。当值达到 232 时，计数器会重置为 0。

完整性检查值 (可变长度)

此字段包含数据包的校验和（完整性检查值，或 ICV）。长度取决于在建立 SA 时选择的算法。其长度总是四字节的倍数。

RFC 4302 中的 AH 规范定义了一个新的扩展（64 位）序列号（ESN）。由于只有扩展序列号的低 32 位被传输，因此在图 6-1 中看不到。扩展序列号的高 32 位由发送方和接收方共同维护，作为序列号计数器的一部分，并包含在 ICV 计算中。64 位序列号是一项旨在支持高速 IPsec 实现的新选项。扩展序列号的使用在 SA 建立时协商。IKEv2 的默认值是 ESN，除非显式协商为 32 位。

校验和是根据以下字段计算的：

  • 所有不在传输过程中改变或在到达目标时可以预测其值的 IP 头或扩展头字段。例如，如果存在路由扩展头，则会使用路由扩展头中的最后一个地址进行计算。流量类字段、流标签和跳数限制不包含在计算中。

  • 认证头的所有字段。

  • 其他存在的扩展头和有效载荷。

  • 如果使用了 ESN，则计算 ESN 的高位部分（如果使用了）以及完整性算法要求的任何隐式填充。

以下算法被认为适用于 IPsec：

  • 基于对称加密算法的消息认证码（MACs）。

  • 单向哈希函数（例如，MD5、SHA-1、SHA-256）。

可以协商其他算法。RFC 4305《封装安全有效载荷（ESP）和认证头（AH）的加密算法实现要求》列出了以下认证头的实现规则：

  • 必须使用 HMAC-SHA1-96（RFC 2404）

  • 应该使用 AES-XCBC-MAC-96（RFC 3566）

  • 可以使用 HMAC-MD5-96（RFC 2403）

MD5 中已经显现出一些弱点；然而，这些弱点不应影响 MD5 与 HMAC 的使用。

认证头可以在传输模式和隧道模式下使用，如图 6-2 所示。

传输模式和隧道模式中的认证头图 6-2. 传输模式和隧道模式中的认证头

在传输模式下，整个有效载荷，包括在传输过程中不变的 IPv6 头字段，都会被保护。在隧道模式下，内部数据包包含发送者和接收者的 IP 地址，外部 IP 头包含隧道端点的 IP 地址。在这种情况下，整个原始数据包，包括在传输过程中不变的外部头字段，都将被保护。

封装安全有效载荷头

封装安全载荷（ESP）头部提供完整性、机密性、数据源认证、反重放服务和有限的流量流动机密性，适用于通过 IP 数据包传输的所有端到端数据。这些服务的集合在建立 SA 时协商。ESP 定义在 RFC 4303 中，并通过前面的头部中的 Next Header 值 50 来指示。

ESP 头部位于传输（例如 UDP 或 TCP）、网络控制（例如 ICMP）或路由（例如 OSPF）协议头部之前。

ESP 的格式如图 6-3 所示。

封装安全载荷头部格式图 6-3. 封装安全载荷头部格式

安全参数索引（SPI）（4 字节）

任意的 32 位值。接收方用它来识别一个传入数据包所属的 SA。SPI 字段是强制性的，所有 ESP 实现必须支持该机制，以便将传入流量映射到单播 SA。如果 IPsec 实现支持多播，它还必须支持使用为此目的指定的解复用算法来映射传入的 IPsec 数据报到多播 SA。IANA 为未来使用保留了 1 到 255 范围内的 SPI 值。SPI 值 0 保留供本地实现特定使用，且不得在网络上传输。

序列号（4 字节）

这个 32 位序列号是一个单调递增的计数器值。它必须由发送方设置，但是否根据该值采取行动由接收方决定。它确保相同数据的分组不会被重复发送，从而防止在单播或单发送方 SA 中的重放攻击。在多发送方 SA 中，由于 ESP 没有机制在多个发送方之间同步分组计数器，因此无法使用反重放功能。在建立 SA 时，该值在发送方和接收方均设置为 0。第一个分组的序列号始终为 1，之后每个连续的分组序列号加 1。当达到 2³²时，计数器会重新初始化为 0。

有效载荷数据（可变长度）

包含加密数据以及加密初始化向量（IV），如果加密机制需要的话。

填充（0 到 255 字节）

用于将数据包对齐到 4 字节的倍数，并在加密机制要求最小数据包大小时达到最小数据包尺寸。

填充长度（1 字节）

指示前面填充的字节数。

下一个头部（1 字节）

标识紧随 ESP 头之后的头的类型。它使用表 3-1 中列出的值。为了促进快速生成和丢弃填充流量以支持流量保密性，协议值 59（无下一个头）表示虚拟数据包。虚拟数据包的接收方必须丢弃它，而不生成错误消息。

完整性检查值（可变长度）

完整性检查值（ICV）是一个可变长度的字段，包含对 ESP 头、负载和 ESP 尾字段进行校验和计算后的值。ICV 字段是可选的，只有在选择完整性服务时才会出现，它由单独的完整性算法或使用 ICV 的组合模式算法提供。该字段的长度由所选的完整性算法和与 SA 关联的算法指定。

填充、填充长度和下一个头字段是 ESP 尾的一部分。加密算法要么手动指定并包含在数据包流的 SA 中，要么通过密钥交换协议动态协商。

RFC 4303 中的 ESP 规范定义了扩展（64 位）序列号（ESN）。在图 5-3 中无法看到它，因为只有扩展序列号的低 32 位被传输。高 32 位由发送方和接收方作为序列号计数器的一部分维护，并包含在 ICV 的计算中。64 位序列号是为支持高速 IPsec 实现而设计的新选项。扩展序列号的使用在 SA 建立时协商。IKEv2 的默认值是 ESN，除非明确协商为 32 位。

RFC 4835，“封装安全负载（ESP）和认证头（AH）的密码算法实现要求”，列出了 ESP 的实现规则。

组合模式算法同时提供机密性和认证服务。预计它们将在吞吐量和效率上提供显著的优势。AES-CM（高级加密标准计数模式），已被采纳为 IEEE 802.11i 中的首选安全模式，定义在 RFC 5084 和 RFC 6655 中。

由于 ESP 认证和加密都是可选的，因此必须为两者都提供对 NULL 算法的支持。请注意，每次只能将其中一个设置为 NULL。

ESP 可以在传输模式和隧道模式中使用，如图 6-4 所示。

传输模式和隧道模式中的封装安全负载头图 6-4. 传输模式和隧道模式中的封装安全负载头

在传输模式中，IP 头部及其后续的扩展头部不会被加密；否则数据包将无法转发。如果必须对完整数据包进行加密，则应使用隧道模式。与隧道模式中的 AH 一样，内部数据包包含发送方和接收方的 IP 地址，而外部 IP 头部则包含隧道端点的 IP 地址。

ESP 头部可以与 NULL 加密选项一起使用，该选项在 RFC 2410 中进行了定义。使用 NULL 加密时，仅使用 ESP 的认证选项，并且数据包不进行加密。

AH 和 ESP 的组合

这两个头部也可以结合使用。在这种情况下，AH 必须先于 ESP 头部，以便在数据包解密之前验证其真实性和完整性。ESP 头部中已包含认证选项，以便仅通过一个头部对加密数据包进行认证。

如果在隧道模式中使用 AH 头部，则第一个 IP 头部会包含在认证中。如果使用 ESP 头部，则仅对 ESP 头部之后的部分数据包进行认证。如果需要对 IP 地址进行加密和完整性保护，则必须同时使用这两个头部。如果同时使用这两个头部，显然不需要在 ESP 头部中使用认证。另一方面，如果给定的认证足够，可以使用 NULL 加密的 ESP 头部。

IPsec 与 IPv6 元素的交互

在 IPv6 中使用 IPsec 提供的安全性与在 IPv4 中使用 IPsec 的安全性相同。但在某些领域，IPsec 很难与其他服务结合使用：

  • 隧道技术是 IPsec 和多种过渡机制的基础元素，它为位于内部网络边缘的现有防火墙和安全网关带来了困难。通过防火墙建立的加密 IPsec 隧道为两端主机提供端到端安全，防止防火墙检测到危险或未授权的内容。解决此问题的一种方式是定义安全网关之间的安全关联，而不是定义端节点之间的安全关联。另一个问题是，内部数据包可能包含对内部网络构成威胁的信息。这些信息可能是路由信息或网络控制消息（例如，ICMP 重定向）。

  • 具有不断变化 IP 地址的扩展移动性选项可能导致在 IPsec 环境中难以管理和控制的情况。动态地址，例如隐私地址（RFC 4941），如果用于 IKE 身份验证检查，可能会造成困难。

IPv6 安全“陷阱”

IPv6 网络中的安全性与 IPv4 网络中的安全性没有本质区别。许多现有的 IPv4 攻击也可以在 IPv6 中进行，因此我们保护数据的方式是相似的。

就像在 IPv4 世界中一样，总会有不道德的黑客找到新的方法来突破我们的网络。安全设计师和整个计算机安全社区必须保持警觉，持续寻找机制以跟上黑客的步伐，并找到保护网络免受新攻击的方法。

注意

如果网络中同时使用 IPv4 和 IPv6 协议，每个协议都需要有自己独立的安全概念和措施，并且这些措施需要进行协调。

在双栈网络中拥有一个强大且经过深思熟虑的安全设计是必须的。但即使在部署 IPv6 之前，你也必须迈出第一步来保护网络。IPv6 已经包含在大多数操作系统中，通常配置相对简单，且常常默认启用。甚至隧道机制通常也是默认启用的。IPv4 网络管理员可能认为自己不需要担心 IPv6，但他们没有意识到，网络中可能已经存在 IPv6 流量。IPv6 黑客正是利用这一点侵入 IPv4 网络。

注意

通过过滤你的追踪文件中的0x86DD MAC 头部或 IPv4 协议类型字段中的协议 41 来查找你网络中的 IPv6 流量。你可能会发现大量的邻居发现消息——这是你网络中存在活跃 IPv6 节点的良好指示。

作为保护的第一步，在尚未部署 IPv6 时，请确保过滤所有进出你网络的 IPv6 流量。这包括原生 IPv6 流量和隧道流量。除此之外，监控和审计 IPv6 流量，特别是如路由器或邻居广告等 ND 消息，这些消息可能被用来错误配置你的客户端，可能是明智的做法。

注意

RFC 7123，《IPv6 对 IPv4 网络的安全影响》，提供了有关如何保护这种“未管理”IPv6 企业网络的有用建议。

虽然 IPsec 是一个很好的安全机制，但它并不是安全的万能解。大多数安全专家都同意，没有银弹可以防止网络受到内部或外部攻击。最佳实践和用户培训的结合可以最大限度地减少风险。如果你打算在不久的将来部署 IPv6，以下是一些需要解决的安全问题。请注意，这不是一个完整的清单，因为关于这个主题可以写出大量的资料。

原生 IPv6

当本地连接到 IPv6 时，以下章节将讨论一些需要考虑的安全问题。

公钥基础设施（PKI）

虽然 RFC 4301 指定了 IPv6 协议中对 IPSec 的要求，但它并未涵盖密钥如何交换。你可以手动设置预共享密钥，但在大型企业中，这项任务会变得繁琐且耗时。在这种环境下，使用集中式证书服务器是理想的选择。对于 IPv6，直到最近才有这样的集中式证书服务器。在 IKEv2 协议的基础上，服务器已经改变，这一协议在 RFC 5996 中进行了规范。IKEv2 的优势在于它可以同时支持 IPv4 和 IPv6，并且实现更为简便。它与 IKE 的第一个版本不兼容，但两个版本的报文头格式相似，可以通过相同的 UDP 端口无歧义地运行。

防火墙和入侵检测/防御系统

尽管端到端 IPsec 被认为是 IPv6 的主要优势之一，但如果在启用加密的情况下使用 ESP，它也会引入现有防火墙和 IDS/IPsec 的新问题。如果数据包从端到端加密，中间的设备如何在不解密数据包的情况下进行检查？将所有加密密钥存储在中央位置既是单点故障的风险，也是黑客攻击的目标，黑客可以入侵并窃取网络中的所有加密密钥。目前 IPv4 IDS/IPS 系统的问题包括无法检测隧道化的 IPv6 协议，以及缺乏针对基于 IPv6 的攻击的攻击特征，尽管随着 IPv6 在更多网络中的普及，这些问题最终应该会得到解决。

支持 IPv6 的防火墙已包含在大多数主要操作系统中，但在旧版实现中，保持连接状态的防火墙（stateful firewalls）并不可用。思科、CheckPoint 和 Netscreen（Juniper）等公司提供对 IPv6 数据包的状态检查。防火墙产品必须经过仔细评估，并根据特定的 RFC 要求进行测试。有关更多信息，请参见第九章。尽管大多数实现都提供了一些基本功能，但在 IPv6 网络中仍然缺少许多关键功能。

草案《IPv6 企业防火墙的要求》（draft-gont-opsec-ipv6-firewall-reqs-01）规定了一套 IPv6 防火墙的要求，以便在 RFP（请求提案）中确定可以预期和应要求的功能。

实现问题

许多 IPv6 实现相对较新，这带来了另外两个可能的安全问题。第一个问题是缺乏 IPv6 评估工具。在信息安全领域，通常做法是使用知名的安全审计工具审计自己的网络，然后通过这些工具修补发现的漏洞。这些流行的工具中的许多正在移植以审计 IPv6 网络，因此你需要检查你最喜欢的工具的成熟度。第二个问题是 IPv6 实现中未经测试的代码（这也与缺乏测试这些实现的工具有关）。未经充分测试的代码可能会比那些在生产环境中运行已久的代码存在更多的安全漏洞。厂商必须等待市场反馈和事件报告才能修复他们的实现。在规划中，你需要为测试协议栈和安全实现留出足够的时间，在进入生产环境之前，并且要建立一个流程来快速解决出现的安全实现风险和漏洞。

注意

另一方面，我们必须理解，在许多情况下，传输层安全性被过度强调，而诸如网络钓鱼、特洛伊木马等更有效的措施却被低估。

邻居发现问题

IPv4 中的 ARP 已经被 IPv6 中的 ICMP 消息取代。然而，如果没有使用 IPsec AH 或 SEND，NDP（邻居发现协议）就会存在许多 IPv4 中 ARP 所面临的安全问题，例如重定向攻击（恶意节点将数据包重定向至非合法接收者）、拒绝服务（DoS）攻击，以及泛洪攻击（将其他主机的流量重定向到受害节点，制造大量伪造流量）。重复地址检测和路由器通告也可能遭到滥用。这些攻击类似于 IPv4 中的 ARP/DHCP 攻击。RFC 4862（IPv6 无状态自动配置）中的一段话指出：

如果一个节点确定其临时的链路本地地址不是唯一的，自动配置将停止，需要手动配置该接口。

这可能会导致拒绝服务攻击（Denial of Service），因为多个 IPv6 地址可以分配给单个接口。恶意工作站可能会分配几千个地址，从而使其他工作站无法获取链路本地地址。甚至更简单的，可能会构建一个软件响应器，总是回应“地址正在使用”之类的信息，像黑客选择（The Hacker’s Choice）发布的新 IPv6 工具。

另一个问题是，链路本地地址可以在没有预配置的情况下获取。攻击者可以在没有进一步了解网络的情况下访问该链路。这一特性使得恶意节点有机会对任何连接到该链路的其他节点发起攻击。保护此类攻击的可能方法包括链路层认证（网络访问控制）或使用加密生成地址（见下文）。

第一跳安全性

路由器广告欺骗是另一个安全问题，也被称为恶意 RA。由于单个接口上允许多个地址，因此也允许多个路由。一个启动节点向所有路由器的链路本地多播地址（ff02::2）发送路由器请求。链路上的每个路由器都会回复一个路由器广告，其中包含客户端的配置信息。这就为通过不应发送流量的路由器发送流量提供了可能性（允许在恶意路由器上嗅探流量，进而可能发起中间人攻击）。攻击者可以利用 RA 中的其他选项误导客户端，例如配置错误的 DNS 服务器信息（如果客户端堆栈支持），为链路上的所有节点配置非常小的 MTU 值，或者为所有节点设置跳数限制为 1。显然，这种类型的攻击在 IPv4 环境中也会发生；其区别仅在于所使用的机制。使用 IPsec 的 AH 组件、安全邻居发现（SEND）或 RA Guard 等方法可以缓解这一风险。

RA Guard（路由器广告保护）在 RFC 6105 中定义。RA Guard 的目的是在 Layer 2 层过滤路由器广告，基于一组标准，在它们到达目标之前进行过滤。标准可以是允许来自一组定义源的 RA，在给定接口上禁止 RA，允许来自认证源的 RA 等。它可以在有状态或无状态模式下运行。该规范还定义了一个路由器授权代理的概念，代理会根据定义的标准代表客户端检查 RA。然后只发送来自已被批准为合法源的链路的 RA。

RA Guard 的效率取决于 Layer 2 设备检测路由器广告消息的能力。实践表明，在某些实现中，可以通过扩展头部，特别是分段头部，绕过该能力。当数据包被分段成多个片段时，Layer 2 设备可能无法找到执行数据包过滤所需的所有信息。RFC 6980，“IPv6 分段与 IPv6 邻居发现的安全隐患”，更新了 RFC 4861，禁止在传统邻居发现中使用 IPv6 分段头。RFC 7113，“IPv6 路由器广告保护（RA Guard）实施建议”描述了相关问题，并提出了过滤规则。它是 RFC 6105 关于 RA Guard 的更新。

NDP 规范建议使用 IPsec 来防范攻击，但没有提供如何做到这一点的详细信息。在许多情况下，特别是在公共和无线网络中，IPsec 使用的密钥管理过于复杂且不切实际。

注意

概述 NDP 可能面临的威胁并提供指导的参考文献是 RFC 3756，“IPv6 邻居发现（ND）信任模型与威胁”。

RFC 6946 讨论了 原子分片 问题。原子分片是一个包含分片头部，但实际上没有分片的包。如果主机收到一个 ICMPv6 “数据包太大”消息，并且下一跳的 MTU 小于 1280 字节，就可能发生这种情况。分片头部包含“分片偏移”和“M 位”设置为零。这样可以导致主机对数据包进行分片，然后发起基于分片的攻击。许多实现将这些原子分片视为普通分片，这可能被用来发起攻击。最好将它们当作普通数据包处理，无需排队等待更多分片。

注意

分片头部在第三章中进行了描述，邻居发现则在第四章中进行了描述。

SEcure Neighbor Discovery (SEND) 在 RFC 3971 中定义，目的是在不使用 IPsec 的情况下保护 NDP。此方法使用新的 NDP 选项来承载基于公钥的签名。通过零配置机制，显示各个节点的地址所有权；路由器通过信任锚认证。SEND 是 IPv6 第二层相邻节点之间的协议建立信任，但它在 Windows 或 Mac OS X 等通用主机中缺乏实现，且仅有少数路由器实现了该功能。这使得 SEND 成为一种普遍不可用的解决方案。

注意

你可以在第四章中找到关于 SEND 和加密生成地址（CGA）的描述。

作为 首跳安全 策略的一部分，你还将配置 ICMP 嗅探、DHCPv6 防护 和 IPv6 目的地防护 等机制。请参考供应商的配置指南，了解如何配置这些功能。

分片

正如 ND 和首跳安全部分所示，有几个情况表明扩展头部，特别是分片头部，可能会引发安全问题。RFC 6980《IPv6 分片与 IPv6 邻居发现的安全影响》描述了这些问题，并禁止在邻居发现中使用分片。该 RFC 指定节点不得使用 IPv6 分片发送以下任何邻居发现和安全邻居发现消息：

  • 邻居请求

  • 邻居广告

  • 路由器请求

  • 路由器广告

  • 重定向

  • 认证路径请求

注意

如果一个 IPv6 主机收到带有分片的 ND 消息，应该将该消息静默丢弃。所以这是对原始 ND 规范 RFC 4861 的更新。如果你注意到 ND 消息被丢弃，请验证分片是否是原因，并查找它的来源。

地址和端口扫描

地址扫描变得更加复杂，甚至可以说不再实际。IPv6 中的接口标识符有 64 位。RFC 4846《IPv6 本地网络保护》指出，“攻击者必须发送一个几乎不可能实现的 ping 数量来映射网络，而且病毒/蠕虫传播将在过程中被阻止。在 40 Gbps 的满速率下（是典型 100 Mbps 局域网的 400 倍，是典型 DSL/电缆接入链接的 13,000 倍），扫描单个 64 位地址空间需要超过 5,000 年。”这很难想象！如果使用自动配置而没有隐私选项，某些部分的地址（例如，厂商 ID）可能被猜测到，但它仍然是一个庞大的地址空间。一种简单有效的保护方法是避免使用容易猜测的地址方案，例如不使用BEEF、F00D、CAFE、1234、ABCD等词作为 IPv6 地址的一部分，也不要为关键基础设施设备（如路由器）使用顺序编号或容易猜测的地址（例如x::1）。

另一方面，获取一个容易记住的地址，如x::1作为路由器地址，可以使网络操作更简便，从而提高可靠性，也增强了安全性。因此，网络运营商需要平衡使用可预测地址的风险与收益。

注意

RFC 5157《IPv6 对网络扫描的影响》讨论了这个话题，并解释了攻击者可能使用的替代方法。它还提出了在设计中如何解决这些问题的建议。

由于 IPv6 网络无法进行扫描，这也使得网络清单管理变得更加复杂，了解谁在使用你的网络，当然也是一个重要的安全因素。Netflow 或 SNMP 定期扫描 NDP 缓存可以帮助管理网络清单。你还可以使用 IPAM（IP 地址管理）或 DDI（DNS、DHCP、IP 地址管理）工具来获取关于网络的信息。

另一方面，端口扫描通常指的是扫描特定 IP 地址上的 TCP 和 UDP 端口空间，以确定哪些服务正在运行。由于 IPv6 没有改变其现有的 16 位 TCP 或 UDP 端口空间，因此端口扫描依然构成威胁。

多播问题

IPv6 支持站点范围的多播地址，如果使用不当，可能会使攻击者识别出站点上的某些重要资源。特定的例子包括所有路由器（ff05::2）和所有 DHCP 服务器（ff05::1:3）地址。能够将目标为这些地址的消息渗透到站点的攻击者，可能会收到返回的信息，识别站点上的关键资源。这些信息可以被用来进行定向攻击，从简单的洪水攻击到更具体的旨在颠覆设备的机制。通过确保所有防火墙和站点边界路由器配置为丢弃具有站点范围目标地址的数据包，可以将风险最小化。此外，节点不应加入站点上没有合法用途的多播组，站点路由器应配置为丢弃定向到这些未使用地址的数据包。

过渡与隧道机制

IPv4 预计不会很快消失。很可能在未来的很多年里，网络上会有 IPv4 节点。IPv4 主机在没有某种过渡或隧道机制的情况下，无法与 IPv6 主机进行通信，这可能会增加现有网络拓扑结构和网络协议栈底层代码的复杂性。过渡和隧道机制还可以作为进入通常仅支持 IPv4 的网络的后门。

使用 IPv6 作为进入 IPv4 网络的后门从 2002 年开始就已经是一种已知的做法。2002 年 12 月 17 日，HoneyNet 项目的一个 Solaris 8 服务器（www.honeynet.org）遭到入侵。这次攻击与之前的不同之处在于，攻击者设置了一个 IPv6 隧道连接到另一个国家，并通过该隧道窃取数据。这绕过了当时的许多入侵检测系统，今天可能依然有效。随着基于 UDP 的隧道机制的出现，这种做法变得更加容易，这些机制旨在允许 IPv6 通过 NAT（在这些机制出现之前，这几乎是不可能的）。Teredo 和隧道设置协议（TSP）就是这样的两种机制。

通常，使用隧道时，必须确保通过隧道进入网络的数据包无法绕过进入的数据包过滤器。例如，来自互联网的攻击者可能会向隧道端点（即网络的入口点）发送一个 IPv4 数据包，该数据包包含一个 IPv6 数据包，并且 IPv6 源地址来自你内部网络的地址范围。隧道端点解封装数据包后，将 IPv6 数据包转发到内部网络。接收方会认为这个数据包来自内部网络中的一台主机。在这方面，自动隧道更危险，因为它们必须接受来自任何来源的数据包。因此，部分保护措施可以是配置隧道端点只接受来自配置的隧道入口点的数据包，或仅使用手动配置的隧道。但是，攻击者仍然可以伪造该地址。必须在隧道端点实现额外的过滤机制。它必须像其他任何进入你网络的入口点一样进行处理。RFC 4891《使用 IPsec 保护 IPv6-in-IPv4 隧道》详细说明了如何使用 IPsec 保护手动配置的 IPv6-in-IPv4 隧道。

6to4 隧道是一个广为人知的过渡机制，用于当前没有本地 IPv6 连接的网络。它通过使用一个具有可路由 IPv4 地址的双栈边界路由器来实现。

注意

请参考第七章，了解 6to4 的详细讨论。

在 6to4 场景中，有一些特殊的考虑事项，在 RFC 3964 中进行了讨论，“6to4 的安全考虑”。这里的问题是：a) 所有 6to4 路由器必须接收并解封装来自其他 6to4 路由器和 6to4 中继的 IPv4 数据包；b) 所有 6to4 中继路由器必须接受来自任何本地 IPv6 节点的流量。需要分析的路由场景如下：

  • 从 6to4 到 6to4

  • 从本地 IPv6 到 6to4

  • 从 6to4 到本地 IPv6

请参阅 RFC 以获取有关场景和最佳实践的详细讨论，以保护您的网络。如果遵循我们的通用设计指南，您无论如何都不会在生产网络中部署 6to4。

6to4 路由器可以用于通过一个名为4to6DDoS的工具发起分布式拒绝服务（DDoS）攻击。4to6DDoS 工具不要求在攻击主机或受害主机上安装 IPv6 协议栈。它直接从 v4 到 v4 发送 IPv6 封装在 IPv4 数据包中的流量。用于 6to4 隧道的路由器也可以通过简单地使用私有 IPv4 地址多次连接到路由器进行 DoS 攻击。这些路由器必须接收并解封装 IPv4 数据包，即使它们是伪造的。它们还必须接受来自任何本地 IPv6 节点的流量。6to4 还不保证对称路由，这意味着流量在前往目的地时可能走一条路由路径，而返回时则走完全不同的路径。从安全性和性能的角度来看，这种情况可能并不理想。

自动隧道可能会创建另一种漏洞。如果一个数据包通过隧道进入，而目标 IPv6 地址与 IPv6 网络中的有效接口不匹配，它可能会在隧道中反复进出，直到跳数限制被超越。这适用于所有自动隧道，如 6to4、ISATAP 和 6rd（所有协议 41 隧道）。它可以被滥用作为流量放大的工具，促使 DoS 攻击。RFC 6324 描述了这些问题以及缓解措施，例如端点存在验证、目标和源地址检查，以及操作性措施。

注意

一个关于安全问题的很好的参考是 RFC 4942，“IPv6 过渡/共存安全考虑事项”。

企业 IPv6 安全模型

由于 IPv4 地址短缺，需要引入 NAT（网络地址转换），许多 IPv4 网络已经失去了端到端的透明性和安全性。IPv6 可以恢复这种透明性。然而，一些人已经习惯通过使用 NAT 和私有地址方案来隐藏网络拓扑，从而为企业网络提供安全性。这些人可能会将 IPv6 的透明性视为对其网络的威胁，甚至可能仅仅因为这个原因就计划部署使用私有本地地址方案和转换器的 IPv6 网络。

IPv6 的目标是通过利用丰富的地址空间恢复端到端连接。为了保障 IPv6 网络的安全，必须创建一个安全概念，并实施安全机制。IPv6 不应再使用 NAT。如果需要隐藏外部网络拓扑，应使用其他机制，如无状态地址自动配置（RFC 4941）的隐私扩展、唯一本地地址（ULAs，RFC 4193）或 RFC 4864 中描述的不可追踪的 IPv6 地址，即“IPv6 本地网络保护”。

新模型

在 IPv4 网络中，常见的安全模型是使用外围防火墙并集成 NAT。将这种相同的策略应用于 IPv6 网络可能是一个好的起点，但从长远来看是有限的。在 IPv6 网络中，应该致力于设计一个改进的安全模型，不仅能提高网络的整体安全性，还能促进端到端通信。IPv6 在每个节点上提供了 IPsec 功能。仅依赖一个外围防火墙是危险的。攻击者如果突破了防火墙，通常会发现一个开放且不安全的区域。IPv6 网络的最佳安全概念可能是“深度防御”，即集中的安全策略仓库与分发机制相结合，通过与可信主机配合使用，允许网络管理员更多依赖端点的安全机制，并允许端点影响外围防火墙的行为。外围防火墙将负责保护网络免受常规攻击，而终端节点将负责保护自己免受节点相关的攻击。IPv6/IPsec 网络的新安全政策模型必须是基于身份的模型，以便将安全政策与网络 ID 分离。这对于希望实现自动化、自动配置和移动性而不妥协安全性的网络至关重要。这种新的分布式安全模型正在逐步形成，一些所需的技术仍在开发中，包括允许端节点控制和通知防火墙的协议。初期的 IPv6 部署可能会使用与当前 IPv4 网络相似的防火墙和入侵检测技术（除 NAT 外，IPv6 网络中不应使用 NAT）。但引入一种新型的分布式安全概念的最终目标应始终铭记，并应密切关注这些技术的发展。

使用目录服务来控制访问

在 IPv6 的地址架构下，我们必须学会将身份与 IP 地址分离。一个 IPv6 接口通常有多个 IPv6 地址，并且可能会频繁变化（取决于地址规划）。因此，基于 IPv6 地址的安全规则和访问控制列表（ACL）可能不容易管理。而且，用户（身份）通常会通过不同的设备访问系统。解决这个问题的一种方法是使用两个不同的前缀，一个用于访问外部网络，我们希望接口 ID 能变化，这样就不能轻易地在互联网上被追踪；另一个用于访问内部系统，我们使用固定的接口 ID，这样可以追踪用户身份。这个内部前缀可以是 ULA 前缀，或者是专门为内部使用划分的公共前缀的一部分。

一种新的方法是将规则定义基于目录服务中的身份。毕竟，我们希望根据特定的群体、特定的机器，或者根据用户所在的机器来控制访问。使用基于 IP 的访问规则，在双栈或 IPv6 环境中会变得非常复杂。因此，如果我们改为基于身份分配规则，控制访问会更加简便，而且安全设备可以通过查询目录服务来解析规则。

市场似乎正在朝这个方向发展。领先的防火墙供应商，包括 Checkpoint 和 Cisco，正在开发目前称为基于身份的防火墙。这将防火墙与目录服务（通常是 Active Directory）连接，并匹配用户和机器身份。它可以显示与用户或机器名称相关的 IP 地址，并让你基于这些属性定义规则。你可以为特定用户定义防火墙规则，当他们从特定的机器发送流量时，或者为特定用户定义防火墙规则，无论他们从哪台机器发送流量。

所以，在设计未来的网络时，允许自己从新的角度思考。目录服务是一个很好的例子，利用现有的强大工具可以改变环境的操作范式。特别是随着 IPv6 的引入，连接方式变得更加多样。例如，使用目录服务和精心设计的身份管理实现，你可以集中管理 DMZ 的访问控制，让合作伙伴、客户和员工根据身份访问某些服务并显示内容。

IPv6 防火墙过滤规则

当你处于一个双栈网络中时，你将拥有两个安全概念：一个是 IPv4 网络的，另一个是 IPv6 网络的。这两个概念应该是相互一致的，但需要遵循各自协议的要求。因此，例如，在 IPv4 网络中管理员通常选择完全阻止 ICMP 流量，但在 IPv6 中这样做是不可能的，因为这可能会破坏一些 IPv6 特性，如路径 MTU 发现。

虽然不能提供一份完整的安全和防火墙指南，但以下是一些应考虑的 IPv6 安全措施和防火墙过滤建议：

  • 在外围防火墙上为内部使用的地址配置入口过滤，以防止欺骗攻击。

  • 在外围防火墙上过滤不需要的服务。

  • 部署主机级防火墙以实现深度防御。

  • 关键系统应具有静态且不易猜测的（随机生成的）IPv6 地址，即使这意味着更复杂的操作。考虑为关键系统使用静态邻居条目（而不是让它们参与 ND）。

  • 用于移动 IPv6 操作的主机应是独立的系统（通过不同的规则进行保护）。

  • 确保终端节点不转发带有路由扩展类型 0 头部的数据包。

  • 第 3 层防火墙绝不应转发链路本地地址的数据包。

  • 防火墙应支持基于源地址和目标地址、IPv6 扩展头部以及上层协议信息的过滤。

  • 检查网络中未通过主要外围防火墙进入的外部数据包，以此作为后门连接或隐蔽隧道的迹象。

在 IPv6 网络中，ICMPv6 发挥着基础性作用并提供了强大的功能。ICMP 消息的无控制转发也会带来安全风险。RFC 4890《防火墙中 ICMPv6 消息过滤的建议》提供了 ICMPv6 防火墙过滤规则配置的建议（特别是允许转发对网络运行至关重要的消息，并丢弃可能存在安全风险的消息）。

另一份草案正在制定中，名为“IPv6 企业防火墙的要求”（draft-gont-opsec-ipv6-firewall-reqs-01）。在撰写时，它仍处于早期阶段。其目标是启动关于 IPv6 防火墙需求的更深入讨论。这个草案不仅针对需要编写提案请求的网络运营商，还针对防火墙厂商，帮助他们识别需要实现的重要选项。如果你是防火墙的运营、购买、部署或管理人员，或者是防火墙厂商，我强烈建议你仔细查看该草案中的需求列表。我猜测它将在不久的将来成为 RFC 标准。

对于从事安全工作的人员，你将希望深入了解比一般 IPv6 书籍中的安全章节更多的内容。我能给出的最佳建议是，花时间规划你的 IPv6 安全概念，并通过实验室进行深入探讨并测试所有内容。到今天为止（2014 年），大多数厂商已有某种形式的安全实现，但由于现实世界的实现仍处于早期阶段，目前市场反馈不足。因此，大多数实现尚未成熟。

注意事项

一本关于 IPv6 安全的好书是由两位著名行业专家 Scott Hogg 和 Eric Vyncke（思科出版社）编写的《IPv6 安全》。这本书已经出版一段时间了，我期待着它的第二版，但我认为它是 IPv6 安全人员必读的书籍。

下一章描述了集成和过渡机制以及允许 IPv6 平稳、逐步引入网络的场景。它还涵盖了规划和设计过程中的重要方面，以及那些已经进行过规划的组织的经验教训。

参考文献

下面是本章中提到的最重要的 RFC 和草案列表。有时我会包括一些额外的与主题相关的 RFC 供你个人进一步学习。

RFC

  • RFC 1828, “使用键控 MD5 的 IP 身份验证”，1995 年

  • RFC 1829, “ESP DES-CBC 变换”，1995 年

  • RFC 1918, “私有互联网地址分配”，1996 年

  • RFC 2085, “HMAC-MD5 IP 身份验证与重放防止”，1997 年

  • RFC 2403, “在 ESP 和 AH 中使用 HMAC-MD5-96”，1998 年

  • RFC 2404, “在 ESP 和 AH 中使用 HMAC-SHA-1-96”，1998 年

  • RFC 2405, “带显式 IV 的 ESP DES-CBC 加密算法”，1998 年

  • RFC 2407, “ISAKMP 的互联网 IP 安全域解释”，1998 年

  • RFC 2408, “互联网安全关联和密钥管理协议（ISAKMP）”，1998 年

  • RFC 2409, “互联网密钥交换（IKE）”，1998 年

  • RFC 2410, “NULL 加密算法及其在 IPsec 中的使用”，1998 年

  • RFC 2412, “OAKLEY 密钥确定协议”，1998 年

  • RFC 2451, “ESP CBC 模式加密算法”，1998 年

  • RFC 2474, “IPv4 和 IPv6 标头中区分服务字段（DS 字段）的定义”，1998 年

  • RFC 3056, “通过 IPv4 云连接 IPv6 域”，2001 年

  • RFC 3068, “用于 6to4 中继路由器的任播前缀”，2001 年

  • RFC 3168, “向 IP 添加显式拥塞通知（ECN）”，2001 年

  • RFC 3260, “DiffServ 新术语和澄清”，2002 年

  • RFC 3493, “IPv6 的基本套接字接口扩展”，2003 年

  • RFC 3526, “用于互联网密钥交换（IKE）的更多模块化指数（MODP）Diffie-Hellman 组”，2003 年

  • RFC 3602, “AES-CBC 加密算法及其在 IPsec 中的使用”，2003 年

  • RFC 3631, “互联网的安全机制”，2003 年

  • RFC 3715, “IPsec-网络地址转换（NAT）兼容性要求”，2004 年

  • RFC 3739, “互联网 X.509 公共密钥基础设施：合格证书配置文件”，2004 年

  • RFC 3740, “多播组安全架构”，2004 年

  • RFC 3748, “可扩展认证协议（EAP）”，2004 年

  • RFC 3754, “区分服务（DS）网络中的 IP 多播”，2004 年

  • RFC 3756, “IPv6 邻居发现（ND）信任模型与威胁”，2004 年

  • RFC 3765, “边界网关协议（BGP）路由范围控制的 NOPEER 社区”，2004 年

  • RFC 3947, “IKE 中 NAT 穿越协商”，2005 年

  • RFC 3948, “IPsec ESP 数据包的 UDP 封装”，2005 年

  • RFC 3964, “6to4 的安全考虑”，2004 年

  • RFC 3971, “安全邻居发现”，2005 年

  • RFC 3972, “加密生成地址（CGA），”2005

  • RFC 4033, “DNS 安全性介绍和要求，”2005

  • RFC 4035, “DNS 安全扩展的协议修改，”2005

  • RFC 4106, “在 IPsec 封装安全负载（ESP）中使用 Galois/计数模式（GCM），”2005

  • RFC 4107, “加密密钥管理指南，”2005

  • RFC 4109, “互联网密钥交换版本 1（IKEv1）的算法，”2005

  • RFC 4285, “移动 IPv6 的认证协议，”2005

  • RFC 4301, “互联网协议的安全架构，”2005

  • RFC 4302, “IP 认证头，”2005

  • RFC 4303, “IP 封装安全负载（ESP），”2005

  • RFC 4307, “在互联网密钥交换版本 2（IKEv2）中使用的加密算法，”2005

  • RFC 4308, “IPsec 的加密套件，”2005

  • RFC 4309, “在 IPsec 封装安全负载（ESP）中使用高级加密标准（AES）CCM 模式，”2005

  • RFC 4359, “在封装安全负载（ESP）和认证头（AH）中使用 RSA/SHA-1 签名，”2006

  • RFC 4380, “Teredo：通过网络地址转换（NAT）隧道化 IPv6 至 UDP，”2006

  • RFC 4581, “加密生成地址（CGA）扩展字段格式，”2006

  • RFC 4835, “封装安全负载（ESP）和认证头（AH）中的加密算法实现要求，”2007

  • RFC 4862, “IPv6 无状态地址自动配置，”2007

  • RFC 4864, “IPv6 的本地网络保护，”2007

  • RFC 4890, “防火墙中过滤 ICMPv6 消息的建议，”2007

  • RFC 4891, “使用 IPsec 保护 IPv6 内 IPv4 隧道，”2007

  • RFC 4941, “IPv6 无状态地址自动配置的隐私扩展，”2007

  • RFC 4942, “IPv6 过渡/共存的安全性考虑，”2007

  • RFC 4982, “在加密生成地址（CGAs）中支持多种哈希算法，”2007

  • RFC 5084, “在加密消息语法（CMS）中使用 AES-CCM 和 AES-GCM 认证加密，”2007

  • RFC 5095, “IPv6 中类型 0 路由头的弃用，”2007

  • RFC 5157, “IPv6 对网络扫描的影响，”2008

  • RFC 5247, “可扩展认证协议（EAP）密钥管理框架，”2008

  • RFC 5722, “重叠 IPv6 分片的处理，”2009

  • RFC 5739, “互联网密钥交换协议版本 2（IKEv2）中的 IPv6 配置，”2010

  • RFC 5909, “邻居发现代理安全性：问题陈述，”2010

  • RFC 5991, “Teredo 安全更新，”2010

  • RFC 5996, “互联网密钥交换协议版本 2（IKEv2），”2010

  • RFC 6014, “DNSSEC 的加密算法标识符分配，”2010

  • RFC 6040, “显式拥塞通知的隧道化，”2010

  • RFC 6071, “IP 安全（IPsec）和互联网密钥交换（IKE）文档路线图，”2011

  • RFC 6081, “Teredo 扩展，”2011

  • RFC 6092, “为提供住宅 IPv6 互联网服务的客户前设备（CPE）推荐的简单安全功能，”2011

  • RFC 6104, “恶意 IPv6 路由器广告问题陈述，”2011

  • RFC 6105，《IPv6 路由器广告防护》，2011 年

  • RFC 6151，《MD5 消息摘要和 HMAC-MD5 算法的更新安全考虑》，2011 年

  • RFC 6169，《IP 隧道的安全问题》，2011 年

  • RFC 6273，《安全邻居发现（SEND）哈希威胁分析》，2011 年

  • RFC 6324，《利用 IPv6 自动隧道的路由环攻击》，2011 年

  • RFC 6434，《IPv6 节点要求》，2011 年

  • RFC 6494，《安全邻居发现（SEND）的证书配置文件与证书管理》，2012 年

  • RFC 6495，《主题密钥标识符（SKI）安全邻居发现（SEND）名称类型字段》，2012 年

  • RFC 6620，《FCFS SAVI：针对本地分配 IPv6 地址的先进先出源地址验证改进》，2012 年

  • RFC 6655，《用于传输层安全（TLS）的 AES-CCM 密码套件》，2012 年

  • RFC 6946，《处理 IPv6“原子”片段》，2013 年

  • RFC 6959，《源地址验证改进（SAVI）威胁范围》，2013 年

  • RFC 6980，《IPv6 片段化与 IPv6 邻居发现的安全影响》，2013 年

  • RFC 7039，《源地址验证改进（SAVI）框架》，2013 年

  • RFC 7112，《超大 IPv6 头部链的影响》，2014 年

  • RFC 7113，《IPv6 路由器广告防护（RA-Guard）的实施建议》，2014 年

  • RFC 7123，《IPv6 对 IPv4 网络的安全影响》，2014 年

  • RFC 7219，《安全邻居发现（SEND）源地址验证改进（SAVI）》，2014 年

草案

草案可以在www.ietf.org/ID.html找到。要查找草案的最新版本，请参阅datatracker.ietf.org/public/pidtracker.cgi。您可以输入草案名称而不带版本号，系统将显示最新版本。如果草案没有显示，可能是已被删除。如果已发布为 RFC，则会显示 RFC 编号。tools.ietf.org/wg也是一个非常有用的网站。有关标准化过程、RFC 和草案的更多信息，请参阅附录 A。

这是我在本章中引用的草案列表，以及与本章主题相关的有趣草案：

《DHCP 的 SAVI 解决方案》

draft-ietf-savi-dhcp-25，用于 DHCP 分配地址的绑定表

《混合地址分配方法场景的 SAVI》

draft-ietf-savi-mix-06，用于共存的 ND、DHCP 和 SEND 地址的绑定表

《IPv6 企业防火墙的要求》

draft-gont-opsec-ipv6-firewall-reqs-01

第七章：过渡技术

本章概述了各种可用的过渡机制。IPv6 和 IPv4 将在未来多年共存，并且有多种技术使得共存成为可能，并提供了一个简单的过渡过程。选择正确的方案并找到最佳的迁移路径非常重要。没有一种“一刀切”的简单策略。迁移路径必须根据每个组织和网络的个别需求进行调整。

支持过渡的可用技术被分为三大类：

双栈技术

允许 IPv4 和 IPv6 在相同的设备和网络中共存

隧道技术

允许在现有的 IPv4 基础设施上传输 IPv6 流量

转换技术

允许仅支持 IPv6 的节点与仅支持 IPv4 的节点进行通信

这些技术可以并且很可能会相互结合使用。IPv6 的迁移可以一步步进行，从单个主机或子网开始。你可以在 ISP 仍然只运行 IPv4 的情况下迁移你的企业网络或其部分网络，或者在 ISP 升级到 IPv6 的同时，企业网络仍然运行 IPv4。本节描述了当前每一类技术的可用方案。RFC 4213，《IPv6 主机和路由器的基本过渡机制》描述了双栈技术和配置隧道。这个领域发生了很大的变化；曾经是关键技术的过渡机制（如 6to4）已被更新的机制所替代，例如在 6to4 的情况下，6rd 就是一种替代方案。新的技术不断被定义，并且更多的新技术即将到来。这实现了 IETF 承诺的目标，即在需求变得明显时，为企业开发新的和调整过的过渡机制，提供解决方案。

双栈

一个双栈节点完全支持两个协议版本。此类节点通常被称为IPv6/IPv4 节点。在与 IPv6 节点通信时，这种节点表现得像一个仅支持 IPv6 的节点；在与 IPv4 节点通信时，它表现得像一个仅支持 IPv4 的节点。实现中可能允许你启用或禁用其中一个栈，因此这种节点类型有三种操作模式。当启用 IPv4 栈而禁用 IPv6 栈时，该节点表现得像一个仅支持 IPv4 的节点。当启用 IPv6 栈而禁用 IPv4 栈时，它表现得像一个仅支持 IPv6 的节点。当 IPv4 和 IPv6 栈都启用时，节点可以使用这两种协议。一个 IPv6/IPv4 节点为每个启用的协议版本至少有一个地址。它使用 IPv4 机制配置 IPv4 地址（静态配置或 DHCP），并使用 IPv6 机制配置 IPv6 地址（静态配置、SLAAC 或 DHCPv6）。

DNS 在两个协议版本中都用于解析名称和 IP 地址。一个 IPv6/IPv4 节点需要一个能够解析两种类型 DNS 地址记录的 DNS 解析器。DNS A 记录表示 IPv4 地址，DNS AAAA（称为四 A 记录）表示 IPv6 地址。

根据服务的可达方式（通过 IPv4、IPv6 或两者），DNS 可能仅返回 IPv4 地址或仅返回 IPv6 地址，或者同时返回两者。默认地址选择机制和配置文件必须确保在任何情况下都能有效地建立连接。希望客户端上的 DNS 解析器和使用 DNS 的应用程序都能够提供配置选项，让我们指定如何使用地址的顺序或过滤器（即首选协议设置）。Happy Eyeballs是一项旨在优化双栈世界中连接设置的规范。请注意，DNS 解析器可能通过 IPv4 或 IPv6 网络运行，以解析任何类型的地址记录。

注意

有关 IPv6 DNS 和Happy Eyeballs的详细讨论，请参见第五章.

双栈网络是一种基础设施，其中路由器启用了 IPv4 和 IPv6 转发。双栈的优势在于你可以原生运行这两种协议。一旦基础设施支持双栈，你就可以开始将应用程序从 IPv4 迁移到 IPv6，并且流量会平稳地从 IPv4 切换到 IPv6。整个过程中不涉及隧道和转换。这是性能、可扩展性和效率的最佳选择。同时也不需要设计、测试和部署临时的过渡机制，这些机制以后还需要移除。

对于这种技术，你必须进行全面的网络升级，以运行两个独立的协议栈。所有表格（例如路由表）都需要同时保留，并为两个协议配置路由协议。出于安全考虑，你需要两个概念，一个用于 IPv4，另一个用于 IPv6，因为你有两条通向网络的入口。对于网络管理，在某些操作系统中，可能仍然需要根据协议使用不同的命令（例如，ping用于 IPv4，ping6用于 IPv6），这会占用更多的内存和 CPU 资源。但在现代硬件上，这应该不会成为问题，双栈的优势远远大于其劣势。

注意

双栈是 IPv6 部署的一个好方法。但它要求所有主机都有 IPv4 地址。如果没有 IPv4 地址，则必须使用 IPv6 单一方案，如 NAT64、DS-Lite、MAP 或 464XLAT。这些方法将边缘网络的增长与 IPv4 的可用性解耦。它们将在本章后面讨论。

另一个需要记住的方面是，双栈使故障排除变得更加复杂。例如，出现 IPv6 问题的应用程序是否尝试通过 IPv4 而不是 IPv6 进行连接并失败？你需要如何调整故障排除方法来测试并找出原因？你的帮助台和 IT 支持人员也需要理解如何使用特定的工具来处理 IPv4 和 IPv6，以便能够排除其中一个协议的问题。因此，从操作和支持的角度来看，运行双栈网络可能需要更多成本。这也是越来越多企业考虑尽快迁移到 IPv6-only 基础设施的主要原因之一。有关更多信息，请参见第九章。

隧道技术

隧道机制可以用于部署 IPv6 转发基础设施，而整体 IPv4 基础设施仍然是基础，并且不应或不能被修改或升级。

隧道也称为封装。通过封装，一个协议（在我们的例子中是 IPv6）被封装在另一个协议（在我们的例子中是 IPv4）的头部，并通过第二个协议（IPv4）的基础设施转发。封装过程有三个组成部分：

  • 隧道入口点的封装

  • 隧道出口点的解封装

  • 隧道管理

所以，隧道技术可以通过将 IPv6 流量封装在 IPv4 数据包中，并通过 IPv4 路由基础设施传输来承载 IPv6 流量。例如，如果你的服务提供商仍然只有 IPv4 基础设施，隧道可以让你拥有一个企业 IPv6 网络，并通过 ISP 的 IPv4 网络隧道传输到其他 IPv6 主机或网络。或者，你可以在企业网络中部署 IPv6 岛屿，而主干网络仍然是 IPv4。IPv6 数据包从一个 IPv6 岛屿到另一个 IPv6 岛屿可以通过主干网络以 IPv4 数据包封装的方式传输。通用的隧道技术和 IPv6 数据包在 IPv4 数据包中的封装已在多个 RFC 中定义，例如 RFC 2473《IPv6 中的通用数据包隧道规范》和 RFC 4213《IPv6 主机和路由器的基本过渡机制》。我们区分两种常见的隧道类型：

手动配置的 IPv6-over-IPv4 隧道

IPv6 数据包被封装在 IPv4 数据包中，通过 IPv4 路由基础设施传输。这些是点对点隧道，需要手动配置。

自动的 IPv6-over-IPv4 隧道

IPv6 节点可以使用不同类型的地址，例如 6to4、6rd 或 ISATAP 地址，来动态地通过 IPv4 路由基础设施隧道 IPv6 数据包。这些特殊的 IPv6 单播地址在 IPv6 地址字段的某些部分携带 IPv4 地址，可用于确定目标或隧道端点的 IPv4 地址。

隧道是如何工作的

本节讨论的概念适用于隧道技术的一般情况。接下来的两段将讨论配置隧道和自动隧道之间的区别。图 7-1 展示了通过一个仅支持 IPv4 的网络连接的两个 IPv6 网络。

封装与隧道图 7-1. 封装与隧道

主机 Marvin 在一个 IPv6 网络中，并希望将 IPv6 数据包发送到另一个 IPv6 网络中的主机 Ford。路由器 R1 和路由器 R2 之间的网络是一个仅支持 IPv4 的网络。路由器 R1 是 隧道入口点。Marvin 将 IPv6 数据包发送到路由器 R1（如图 7-1 中的步骤 1）。当路由器 R1 接收到发送给 Ford 的数据包时，它将数据包封装在 IPv4 头部中并转发到路由器 R2（如图 7-1 中的步骤 2），后者是 隧道出口点。路由器 R2 解封装数据包并将其转发到最终目的地（如图 7-1 中的步骤 3）。在 R1 和 R2 之间，可能会有任意数量的 IPv4 路由器。

隧道有两个端点：隧道入口点和隧道出口点。在图 7-1 的场景中，隧道端点是两台路由器，但隧道可以以不同方式配置。它可以设置为路由器到路由器、主机到路由器、主机到主机，或路由器到主机。根据所使用的场景，隧道的入口点和出口点可以是主机或路由器。

IPv6 数据包封装的步骤如下：

  1. 隧道的入口点将 IPv6 跳数限制减一，将数据包封装在 IPv4 头部中，并通过隧道传输封装后的数据包。如果需要，IPv4 数据包会被分片。

  2. 隧道的出口点接收封装后的数据包。它会检查数据包的源（隧道入口点）是否是可接受的源（根据其配置）。如果数据包被分片，出口点会重新组装它。然后，出口点移除 IPv4 头部，并将 IPv6 数据包处理到原始目的地。

图 7-2 展示了一个 IPv6 数据包在 IPv4 数据包中的封装过程。

封装图 7-2. 封装

IPv4 头中的以下字段值得注意：IPv4 头中的总长度字段包含 IPv4 头的长度加上 IPv6 数据包的长度，而 IPv6 数据包被视为有效负载。如果封装的数据包需要被分段，则标志和分段偏移字段将包含相应的值。生存时间（TTL）字段的值取决于使用的实现。协议号设置为 41，这是分配给 IPv6 的值。因此，如果你想分析隧道中的 IPv6 流量，可以在分析器中设置过滤器，以显示协议号字段中包含值 41 的数据包。IPv4 源地址是隧道入口点的出接口地址。在自动地址选择可能随时间变化产生不同结果（多个地址/接口）的情况下，应该能够进行配置。IPv4 目标地址是隧道出口点的 IPv4 地址。IPv6-over-IPv4 隧道被视为单跳。因此，IPv6 头中的跳数限制（Hop Limit）字段将减少 1。这隐藏了隧道的存在，最终用户无法检测到，且无法通过诸如traceroute之类的常见工具检测到。图 7-3 显示了跟踪文件中的一个封装的 IPv6 数据包。

封装在跟踪文件中图 7-3. 封装在跟踪文件中

Ethertype 设置为 0800，这是 IPv4 的值。IPv4 头中的 TTL 设置为 128。协议字段显示值 41，表示该数据包是一个封装的数据包。源地址62.2.84.115是隧道入口点的 IPv4 地址。目标地址是 Internet 中一个 6to4 中继路由器的 IPv4 地址（本章稍后将解释），即隧道出口点。该路由器可以将 IPv6 数据包转发到 IPv6 网络。将这些 IPv4 地址与 IPv6 源和目标地址进行比较（可以在详细屏幕上方的高亮汇总行中看到）。使用 Windows 计算器可以发现 IPv6 源和目标地址具有2002的 6to4 前缀，并且低 32 位包含 IPv4 地址的十六进制表示。这是一个主机到主机的自动隧道示例，因为我们实际上是在 ping 6to4 路由器。

如果隧道内的一个 IPv4 路由器生成了一个 ICMPv4 错误消息，该路由器会将消息发送到隧道入口点，因为该主机是该数据包的源。如果数据包包含足够的关于原始封装的 IPv6 数据包的信息，隧道入口点可能会向数据包的原始源发送一个 ICMPv6 消息。

当隧道出口点接收到协议值为 41 的 IPv4 数据报时，它知道该数据包已经被封装。在转发解封装后的 IPv6 数据包之前，隧道终点必须验证隧道源地址是否可接受。这样可以避免网络中的不合法入口。如果隧道是双向配置的，则通过将封装数据包的源地址与隧道另一端配置的地址进行比较来进行此检查。对于单向配置的隧道，隧道必须配置一份可接受的源 IPv4 地址前缀列表。默认情况下，这个列表是空的，这意味着隧道终点必须明确配置，才能允许转发解封装后的数据包。在分片的情况下，隧道出口点会重新组装数据包并移除 IPv4 头。在将 IPv6 数据包交付给最终目的地之前，它会检查 IPv6 源地址是否有效。以下源地址被认为是无效的：

  • 所有多播地址（ff00::/8）

  • 回环地址（::1）

  • 所有 IPv4 兼容的 IPv6 地址（::/96），不包括用于重复地址检测的未指定地址（::/128）

  • 所有 IPv4 映射的 IPv6 地址（::ffff:0:0/96）

两个隧道终点都需要具有链路本地 IPv6 地址。该接口的 IPv4 地址可以作为 IPv6 地址的接口标识符。例如，一个 IPv4 地址为192.168.0.2的主机可能具有fe80::192.168.0.2/64的链路本地地址。

该规范包含了一些规则，这些规则在隧道源地址验证和入口过滤（RFC 2827 和 3704）应用到数据包之前，通常适用于数据包的解封装。如果需要进一步的安全机制，可以使用带身份验证的隧道方案——例如，IPsec（更为推荐）或带预配置密钥的通用路由封装（GRE）（RFC 2890）。由于配置的隧道是手动设置的，因此设置密钥材料不是问题。

自动隧道

自动隧道允许 IPv6/IPv4 节点通过 IPv4 基础设施进行通信，而无需预先配置隧道目标。隧道配置信息从嵌入在 IPv6 地址中的 IPv4 地址中提取。在之前的规范（RFC 2893，已被 RFC 4213 废弃）中，隧道终端地址由 IPv4 兼容的目标地址决定。RFC 4213 去除了自动隧道和 IPv4 兼容地址的描述，并转向 6to4（本章稍后讨论），它不使用 IPv4 兼容的 IPv6 地址。6to4 有自己的 IPv6 地址格式，包含了隧道终点的 IPv4 地址作为前缀，从而实现自动隧道。如今，6to4 已经不再推荐作为隧道机制，它被 6rd 所替代。但关于这点将在本章后面的 6to4 和 6rd 部分进一步讨论。

配置隧道（RFC 4213）

配置隧道是指 IPv6-over-IPv4 隧道，其中 IPv4 隧道端点地址由隧道端点的配置信息决定。所有隧道假定是双向的。隧道通过使用配置的 IPv4 地址作为下层端点地址，为 IPv6 层提供一个虚拟的点对点链接。管理配置隧道的工作比自动隧道更复杂，但出于安全原因，这可能是可取的，因为它提供了更多控制 IPv6 数据包转发路径的可能性。

RFC 4213 讨论了配置和需要注意的问题，例如有效隧道端点地址的确定（入口过滤）、如何处理 ICMPv4 或 ICMPv6 消息、如何优化隧道 MTU 大小、分片、头部字段、隧道中的邻居发现（ND）以及安全考虑事项。

连接到没有 IPv6 路由器的网络段的 IPv6/IPv4 主机，可以配置静态路由到 Internet 中位于 IPv4 隧道另一端的 IPv6 路由器；这使得与远程 IPv6 网络的通信成为可能。在这种情况下，隧道另一端 IPv6/IPv4 路由器的 IPv6 地址会作为默认路由添加到路由表中。现在，所有 IPv6 目标地址都匹配该路由，并可以通过 IPv4 基础设施进行隧道传输。此默认路由的掩码为零，只有在没有更具体匹配掩码的其他路由时才会使用。

IPv6 封装（RFC 2473）

RFC 2473 指定了 IPv6 封装的模型和通用机制。关于 IPv4 隧道的本章大部分规则同样适用于 IPv6 隧道。主要的区别在于，在 IPv6 隧道中，数据包被封装在 IPv6 头部中，并通过 IPv6 网络发送。被封装的数据包可以是 IPv4 数据包、IPv6 数据包或任何其他协议。隧道入口点会在原始数据包头部前面加上 IPv6 头部，并在需要时，可能会加上一组扩展头部。无论隧道入口点添加的内容叫什么，都被称为隧道 IPv6 头部。图 7-4 展示了数据包视图中的隧道 IPv6 头部。

从数据包视图看隧道 IPv6 头部图 7-4. 从数据包视图看隧道 IPv6 头部

在隧道入口点应用的 IPv6 头部中，源地址是隧道入口点节点的地址，目标地址是隧道出口点节点的地址。原始数据包的源节点可以与隧道入口点相同。原始数据包（包括其头部）成为封装数据包的有效载荷。原始数据包的头部将根据标准转发规则进行处理。如果头部是 IPv4 头部，则 TTL 字段减一。如果是 IPv6 头部，则 Hop Limit 字段减一。隧道入口点和隧道出口点之间的网络因此实际上只算作一次跳跃，无论中间有多少实际跳跃。

隧道 IPv6 头部根据 IPv6 协议规则进行处理。如果添加了扩展头部，则按标准 IPv6 数据包的处理方式进行处理。例如，Hop-by-Hop 选项头将由列在 Hop-by-Hop 选项字段中的每个节点处理。目的地选项头将由目标主机处理，即隧道出口点。所有这些选项都在隧道入口点进行配置。一个使用目的地选项头的例子是隧道封装限制选项的配置（RFC 2473）。当隧道嵌套时，可以使用此选项。隧道的一跳可以是另一个隧道的入口点。在这种情况下，我们有嵌套隧道。第一个隧道称为外部隧道，第二个隧道称为内部隧道。内部隧道入口点将从外部隧道接收到的整个数据包视为原始数据包，并按照图 7-6 中所示的规则进行处理。嵌套隧道的自然限制是最大 IPv6 数据包大小。每次封装都会增加隧道 IPv6 头部的大小。这将允许大约 1,600 层嵌套隧道，但这并不现实。此外，考虑到数据包必须分片的情况。如果由于额外的隧道 IPv6 头部增加了数据包大小而需要再次分片，则分片的数量会加倍。因此，需要一种机制来限制嵌套隧道的数量。它在 RFC 2473 中有所规定，称为隧道封装限制选项。此选项通过目的地选项头进行传输，格式如图 7-5 所示。

隧道封装限制选项的格式图 7-5. 隧道封装限制选项的格式

Option Type 字段占 1 字节，十进制值为 4，指定了隧道封装限制选项（Tunnel Encapsulation Limit Option）。Option Data Length 字段的十进制值为 1，指定了后续 Option 字段的长度。在这种情况下，Option 字段的大小为 1 字节，包含隧道封装限制选项的实际值。该字段中的值指定了允许的进一步封装级别数量。如果值为零，则数据包会被丢弃，并返回 ICMP 参数问题消息给源节点（即之前隧道的入口点）。如果值为非零，数据包会被封装并转发。在这种情况下，必须应用一个新的隧道封装限制选项，且其值应比接收到的数据包中的限制小 1。如果接收到的数据包没有隧道封装限制，但该隧道入口点已配置了一个限制，隧道入口点必须应用目标选项头，并包含配置的值。

回环封装应当避免。回环封装发生在一个节点将来自自身且目标为自身的数据包进行封装时。IPv6 实现应该通过检查并拒绝配置两端都属于同一主机的隧道配置来防止这种情况。另一个不希望出现的情况是路由环路嵌套封装。这种情况发生在来自内层隧道的数据包重新进入外层隧道，而该数据包还未从外层隧道退出。这种情况只能通过原始数据包的跳数限制和隧道封装限制的配置相结合来控制。

我们来更仔细地看看图 7-6 中的隧道 IPv6 头部。

隧道 IPv6 头部图 7-6. 隧道 IPv6 头部

标准 IPv6 头部的各字段在第三章中进行了讨论。这里有一些有趣的值：流量类别、流标签和跳数限制的值可以在隧道入口点预配置。有效负载长度的值为原始数据包的包长加上隧道入口点前置的任何扩展头部的大小。隧道 IPv6 头部的源地址和目的地址分别包含隧道入口和出口点的 IPv6 地址。请注意，配置为隧道入口点的主机必须支持它封装的数据包的分段。如果封装的数据包超过了隧道的路径 MTU，隧道入口点作为封装数据包的源，必须在需要时对其进行分段。隧道出口点节点将重新组装数据包。如果原始数据包是带有不分段位的 IPv4 数据包，隧道入口点会丢弃该数据包，并向数据包的源发送一个 ICMP 目标不可达消息，代码为“需要分段且 DF 设置”。

隧道机制

接下来的章节描述了目前可用的一系列隧道机制。它们应被视为你 IPv6 工具箱中的一组工具。分析你的环境和需求，以找到最适合你的目标的工具或工具组合。

6to4

RFC 3056《通过 IPv4 云连接 IPv6 域》指定了一种机制，使 IPv6 站点能够通过 IPv4 网络彼此通信，而无需显式设置隧道。这个机制叫做6to4，是自动隧道机制之一。广域 IPv4 网络被视为单播点对点链路层，原生 IPv6 域通过 6to4 路由器通信，也称为 6to4 网关。请注意，只有 6to4 路由器需要支持 6to4。6to4 网络中的主机无需做任何更改。

这本来是作为 IPv4 和 IPv6 共存期间使用的过渡机制。它不会作为永久解决方案使用。6to4 也不会成为战略性隧道机制之一。设计中有一些缺点将在本节后面讨论。我们仍然讨论这个机制，因为它没有被弃用，因为有一种基于 6to4 的新机制叫做6rd，并且已经在生产网络中实现。6rd 解决了 6to4 的一些缺点，后面章节也会讨论。所以回到 6to4。

IPv6 数据包在 6to4 网关处被封装到 IPv4 中。此配置至少需要一个全球唯一的 IPv4 单播地址。IANA 为 6to4 方案分配了一个特殊的前缀：2002::/16。图 7-7 详细显示了 6to4 前缀的格式。

6to4 前缀格式图 7-7. 6to4 前缀格式

前缀 2002::/16 后的 32 位是网关的 IPv4 地址的十六进制表示。这为你的内部网络提供了 80 位的地址空间。16 位用于本地网络寻址，因此你可以创建 65,536 个网络！剩余的 64 位用于网络上节点的接口标识符；也就是说，每个子网可以有 2⁶⁴ 个节点。看起来，熟悉扩展地址空间有一些优势。现在，网络中的所有主机都可以与互联网上的其他 6to4 主机进行通信。

注意

在图 7-7 中，有一些术语，比如 FP（格式前缀）、TLA（顶级聚合器）和 SLA（站点级聚合器）。它们来自较早的 IPv6 地址架构规范（RFC 2374）。在指定 6to4 时，RFC 2374 仍然有效。

当 6to4 网络中的节点想要与另一个 6to4 网络中的节点通信时，不需要配置隧道（自动隧道）。隧道入口点通过目标 IPv6 地址中的 IPv4 地址来确定隧道出口点。要与远程 IPv6 网络中的 IPv6 节点（该节点不是 6to4 网络的一部分）进行通信，你需要一个6to4 中继路由器。中继路由器是配置了 6to4 和 IPv6 的路由器，它将你的 6to4 网络与原生 IPv6 网络连接起来，并将 2002::/16 的 6to4 前缀广播到原生 IPv6 网络中。

图 7-8 展示了 6to4 组件以及它们如何协同工作。

6to4 组件图 7-8. 6to4 组件

图中展示了不同的通信路径。在站点 1 内，主机 A 和 B 可以使用 IPv6 进行通信。要与站点 2 中的主机 C（另一个 6to4 网络）通信，数据包会被发送到站点 1 的路由器 R1。路由器 R1 将其封装在 IPv4 中并转发给站点 2 的路由器 R2。路由器 R1 从目标 IPv6 地址中学习到路由器 R2 的 IPv4 地址。路由器 R2 解封装数据包并将原始的 IPv6 数据包转发给主机 C。要与互联网上的 IPv6-only 主机通信，主机 A 或 B 会将其 IPv6 数据包发送到路由器 R1。路由器 R1 将其封装在 IPv4 中并转发给中继路由器 R3。路由器 R3 解封装数据包，并通过 IPv6 路由基础设施将原始的 IPv6 数据包转发给主机 D。

路由器 R1 会在其路由器通告中内部广播 6to4 前缀（如果已配置）。站点 1 中的 IPv6 主机可以利用路由器通告（RA）进行无状态地址自动配置（Stateless Address Autoconfiguration），以获取其 IPv6 地址。广播的前缀格式为 2002:IPv4-address-R1:subnet-ID::/64。

要将 6to4 网络与 IPv6 互联网连接，可以评估并手动配置一个便捷的 6to4 中继。手动配置的优点是能够控制使用的中继，但会增加更多的管理工作。如果预配置的中继不可用，则需要配置另一个中继。

RFC 3068 定义了一个 6to4 中继路由器的任何播送地址，以简化需要默认路由来查找 6to4 中继路由器的 6to4 网关的配置。IANA 为 IPv4 6to4 中继分配了一个任何播送前缀192.88.99.0/24。分配的任何播送地址对应于该前缀中的第一个节点，例如192.88.99.1。6to4 路由器必须配置默认路由，指向此任何播送地址。使用该地址意味着 6to4 数据包会自动路由到最近的可用 6to4 中继路由器。如果一个 6to4 中继出现故障，你无需重新配置 6to4 网关；数据包会自动重新路由到下一个可用的中继。

如前所述，6to4 存在一些问题。部署实践表明，在某些情况下，通信可能会失败。这些故障可能导致用户在尝试访问服务时出现长时间的重试延迟，或完全无法通信。用户通常并不意识到他们正在使用 6to4，而是将故障归咎于应用程序和服务。曾有人讨论将 6to4 置于历史状态，但这并不能消除市场上大量的实现方式。作为早期主要的过渡技术之一，6to4 已被广泛实施。RFC 6343《6to4 部署建议指南》描述了观察到的问题，并提供了 6to4 部署的建议。实际上，许多主机和消费级路由器上的实现现在会降低或消除 6to4 的优先级，以至于启用原生 IPv6 的网站在实际中几乎看不到 6to4 流量。你可以在Google 统计中看到这一点，其中 6to4 和 Teredo 流量显示在红色曲线中，自 2011 年以来几乎已经降到零。不断上升的绿色曲线则代表了原生 IPv6 流量。

IPv6 快速部署——6rd

在我们深入探讨 6rd 的工作原理之前，先给你介绍一下 6rd 背后的背景。我一直在强调，提供商和供应商不应等到客户要求 IPv6 时才行动，因为客户通常不会关注传输协议，而是关注服务。那么，为什么他们会要求 IPv6 呢？然而，法国发生了一个例外。早在 2007 年，Free（属于 Iliad 集团的法国 ISP）的客户在 Remi Despres 的推动下向 Free 提出了请求。超过 20,000 人签署了一份请愿书，表示愿意每月多支付一欧元，以获得 IPv6 服务。在短短的五周时间内，Free 为 150 万用户提供了 IPv6 互联网接入。他们从零开始，并做了以下工作：

  1. 从其区域互联网注册机构（RIR）获得了一个/32 的 IPv6 前缀

  2. 向他们的 Freebox 家庭网关软件添加了 6rd 支持（基于广泛使用的 6to4 代码）

  3. 为 PC 兼容平台提供了 6to4 网关软件

  4. 将其修改为支持 6rd

  5. 使用多个操作系统和应用程序测试了 IPv6 的操作

  6. 通过提供可下载的软件到 Freebox，实现了操作部署

  7. 宣布为所有希望激活 IPv6 的客户提供 IPv6 互联网连接，且不收取额外费用

2007 年 12 月，IPv6 的可用性仅限于每个客户站点一个 IPv6 链路（/64 站点前缀分配）。几个月后，在 Free 向其区域互联网注册机构（RIR）详细介绍了其成就和计划后，并从其获得了/26 前缀，每个客户最多可拥有 16 个 IPv6 链路（/60 站点前缀分配）。在 2011 年 IPv6 世界大会上，Free 宣布他们将为所有新用户启用 IPv6，随后为所有用户启用 IPv6。这是一个非常重要的宣布，因为它是首批不仅为请求 IPv6 的用户提供 IPv6，而且为所有用户无条件提供 IPv6 的 ISP 之一。

长期以来，法国在 IPv6 启用的互联网用户比例上处于领先地位，这要归功于此。2013 年，瑞士跃升为第一，成为第一个 IPv6 启用用户渗透率达到两位数（超过 10%）的国家。这主要得益于瑞士电信公司 Swisscom，该公司也部署了 6rd。但我们还是先继续讲 Free 的故事。

那么为什么 Free 不直接使用 6to4 呢？如前面 6to4 部分所提到的，6to4 存在一些限制，阻止了 ISP 使用它。第一个原因是通信问题。来自 6to4 网络的包可以轻松到达其他 6to4 网络或 IPv6 互联网中的节点。但来自 IPv6 网络的包并不总是能够到达 6to4 站点。原因在于，这些数据包在其路径中的某些地方必须经过一个 6to4 中继路由器。而且并没有保证或控制，从任何地方到这些中继路由器的路由都存在，并且所有这些中继都会将数据包转发到完整的 IPv4 互联网。另外，即使 ISP 运营一个或多个 6to4 中继，并让它们向 IPv6 互联网宣布 6to4 前缀2002::/16，它也可能接收到目标为未知数量的其他 6to4 ISP 的数据包。此外，ISP 更愿意从其公共 ISP 范围内为客户分配地址，而不是使用 6to4 前缀。因此，Free 对 6to4 进行了略微修改，并做出了以下改动，以改善这种情况：

  1. 用属于 ISP 分配地址空间的 IPv6 前缀替换了标准的 6to4 前缀

  2. 他们选择将 6to4 任播地址替换为 ISP 选择的另一个任播地址

  3. ISP 在其 IPv4 基础设施与 IPv6 互联网之间的边界上运营一个或多个 6rd 网关（这些是升级版的 6to4 路由器）。

  4. CPE（客户驻地设备）在客户侧支持 IPv6，在提供商侧支持 6rd（即升级版的 6to4 功能）。

这一创新高效的部署已经在 RFC 5569 中有所描述，如果您有兴趣了解更多细节。不过，正如您可以猜到的，这并不是故事的结尾。

IETF 关注到了这一快速部署，今天 6rd 已成为 RFC 5969 中定义的官方协议规范。它已经得到快速采用，现有许多实现，并且越来越多的服务提供商开始在生产环境中使用它（例如瑞士的 Swisscom），或者正在考虑采用它。需要明确的是，这是一种自动隧道机制，服务提供商可以在其骨干网尚未原生支持 IPv6 时使用它。如果 ISP 不想等待骨干网升级，可以选择使用 6rd 来通过其基于 IPv4 的骨干网隧道化客户的 IPv6 流量。但这应当是一个临时解决方案，最终目标是实现端到端的原生 IPv6。

让我们仔细看看 6rd 的设计工作原理。请记住，许多过程与 6to4 类似，因此我们在这里描述了变化之处。

首先让我们定义 RFC 中以及本节中使用的术语：

6rd 前缀

由服务提供商选择的 IPv6 前缀。每个 6rd 域仅有一个 6rd 前缀。一个服务提供商可以使用一个或多个 6rd 域来部署 6rd。

6rd 客户边缘（CE）

在 6rd 部署中的客户边缘路由器。有时也被称为客户驻地设备（CPE）。通常有一个 WAN 侧接口，一个或多个 LAN 侧接口，以及一个 6rd 虚拟接口。

6rd 委托前缀

由 CE 计算出的用于客户网络中的 IPv6 前缀。它通过将 6rd 前缀与 CE 收到的 IPv4 地址（通过 IPv4 配置方法获取）结合来构建。这等同于 RFC 3633 中描述的 DHCPv6 委托前缀，也可以在 第五章中找到。

6rd 域

一组连接到相同虚拟 6rd 链接的 6rd CE 和 BR。每个 6rd 域需要一个独立的 6rd 前缀。

CE LAN 侧

该接口服务于 CE 的面向客户的侧，并且完全支持 IPv6。

CE WAN 侧

该接口服务于 CE 的 WAN 侧，并且仅支持 IPv4。

6rd 边界中继（BR）

一个由服务提供商管理的 6rd 启用路由器，位于服务提供商的 IPv4 网络与原生 IPv6 互联网（或其他 IPv6 网络）之间的边界。它至少有一个面向服务提供商网络的 IPv4 启用接口，一个充当 6rd 隧道终端的 6rd 虚拟接口，以及一个连接到原生 IPv6 网络的 IPv6 接口。

6rd 虚拟接口

一个内部隧道接口，用于封装和解封装 IPv6 数据包。典型的 CE 或 BR 仅需要一个 6rd 虚拟接口，但每个 6rd 域最多只需要一个。

最显著的变化之一是，6rd 不使用 6to4 前缀（2002::/16）。它使用服务提供商的 IPv6 前缀。这样，操作域就限制在 SP 的网络内，并且 SP 可以直接控制该网络。RFC 指出，从客户角度和 IPv6 互联网的角度来看，6rd 可以视为等同于原生 IPv6。6rd 委托的前缀分配的地址在默认地址选择规则（RFC 6724）中被视为原生 IPv6。

图 7-9 显示了 6rd 网络的布局。

6rd 网络图 7-9. 6rd 网络

一个 6rd 域由 6rd 客户边缘路由器（CE）和一个或多个 6rd 边界中继（BR）组成。6rd 数据包被封装在 IPv4 头中，因此它们在 SP 的 IPv4 网络中遵循 IPv4 路由。当数据包的目标是来自 SP 网络外部的网络时，必须经过 BR。6rd 是无状态工作的，因此，类似于 6to4，BR 可以使用任播进行故障转移。在这种情况下，BR 的 IPv4 地址可以是 6rd 域内共享的任播地址。BR 将在转发到 CE 的数据包中使用该地址作为源地址。由于 6rd 使用服务提供商地址空间，因此不需要为 6rd 的运行在外部宣传特定的路由。

让我们来看看前缀委托是如何工作的。

6rd 前缀是通过将 SP 定义的 IPv6 前缀与 CE 的 IPv4 地址的全部或部分组合来创建的。通过这两个元素，CE 自动配置 6rd 委托的前缀，并像通过 DHCPv6 前缀委托获取的前缀一样使用。

注意

有关 DHCPv6 和前缀委托的详细信息，请参阅第五章.

在 6to4 中，我们有一个众所周知的/16 前缀（2002::/16），后面跟着一个位于前缀固定位置的 32 位 IPv4 地址。6to4 的前缀是/48 前缀。而在 6rd 中，IPv6 前缀以及 IPv4 地址的位置和位数可以变化。使用 6rd 时，服务提供商（SP）可以调整 6rd 前缀的大小。他可以选择 6rd 机制使用多少位，以及有多少位留给客户站点。为了支持无状态地址自动配置，分配给客户站点的前缀应该至少是/64。为了使客户能够进一步对子网进行划分，最好分配一个更短的前缀，如/60，甚至是/56。

图 7-10 显示了 6rd 地址的格式。

6rd 地址格式图 7-10. 6rd 地址格式

委派的 6rd 前缀长度是 6rd 前缀位数（n）与 IPv4 地址位数（o）之和。如果服务提供商使用他的 /32 提供商前缀和 CE 的完整 IPv4 地址（32 位），客户将获得一个 /64 前缀。如果服务提供商希望委派较短的前缀，例如 /60 或 /56，他可以调整前缀的位数。如果可以为 6rd 域提供一块可聚合的 IPv4 地址块（取决于 ISP 的 IPv4 地址计划），则可以使用少于 32 位的 IPv4 地址。因此，举个例子，如果 IPv4 地址可以聚合为 10.1.0.0/8，那么 6rd 的前缀将是 /56（32 + 24 = 56）。在这种情况下，客户网络有 8 位可供子网划分（64 − 56 = 8）。

注意

由于 6rd 委派的前缀是从 IPv4 地址通过算法选择的，改变 IPv4 地址也会改变 IPv6 前缀，这可能会对客户网络产生干扰。因此，建议在 CE 上使用静态 IPv4 地址或分配长期有效的 IPv4 地址。

尽管 6rd 协议机制允许在较小的地址分配中使用，但从操作上来说，支持将完整的 32 位 IPv4 地址映射到 6rd 前缀中要简单得多。这也是运营商通常更倾向于使用的方法。担心的是，运营商可能会使用 /32 地址并只为客户分配 /64 前缀，这对于任何具有多个子网的家庭网络来说是非常有问题的。我们预计未来家庭网络需要多个子网，例如，为客用和家庭 Wi-Fi 提供支持，并管理智能建筑组件和多媒体设备。

这就是开发人员投入大量精力更改分配策略的原因。在 RIPE 区域，作为 ISP，您目前可以获得一个 /29 地址，这允许您为 6rd 客户分配一个 /30 地址。ARIN 当前有一项特殊政策，允许进行 /24 的“单独分配”，并附带一些特别规定。其他区域可能有不同的规则。这项工作和讨论仍在进行中，因此请与当地注册机构核实当前规则。

6rd CEs 和 BRs 必须配置以下元素：

IPv4 子网掩码长度

在 6rd 域内，所有 CE IPv4 地址中相同的高阶位的数量。例如，如果没有相同的位，则 IPv4 子网掩码长度为零，整个 CE IPv4 地址都用于 6rd 前缀（32 位）。如果有 8 个相同的位，则 IPv4 子网掩码长度为 8，并且在构建 6rd 委派前缀之前会去掉 IPv4 地址中的 8 个高阶位。

6rd 前缀

给定 6rd 域的 6rd 前缀。

6rd 前缀长度

给定 6rd 域的 6rd IPv6 前缀长度。

6rd BR IPv4 地址

给定 6rd 域的 6rd BR 的 IPv4 地址。

有一个 6rd DHCPv4 选项，选项代码为 212，格式如 图 7-11 所示。

6rd DHCPv4 选项格式图 7-11. 6rd DHCPv4 选项格式

6rd 选项代码设置为 212。选项长度字段显示 DHCP 选项的长度（以八位字节为单位，22 字节，其中包含一个 BR IPv4 地址）。IPv4 掩码长度字段显示在给定的 6rd 域内所有 CE IPv4 地址相同的高位比特数。该值可以在 0 和 32 之间。6rd 前缀长度字段显示 SP 的 6rd 前缀的 IPv6 前缀长度（以比特为单位）。6rd BR IPv4 地址字段包含给定 6rd 域的一个或多个 6rd 边界中继的 IPv4 地址。最后，6rd 前缀字段包含 6rd 前缀，作为一个 16 字节的 IPv6 地址。在 6rd 前缀长度字段指定的比特数之后，前缀中的比特必须由发送方设置为零，并由接收方忽略。

当启用 6rd 时，典型的 CE 路由器将创建一个默认路由指向 BR，一个针对 6rd 委派前缀的黑洞路由，以及用于任何 LAN 侧分配和通告前缀的路由。

ISATAP

站点内自动隧道地址协议（ISATAP）旨在通过基于 IPv4 的网络为双栈节点提供 IPv6 连接。它将 IPv4 网络视为一个大的链路层网络，允许这些双栈节点之间自动建立隧道。无论您是否拥有全球或私有 IPv4 地址，都可以使用这一自动隧道机制。ISATAP 地址在 EUI-64 接口标识符中嵌入了一个 IPv4 地址。请注意，ISATAP 网络中的所有节点都需要支持 ISATAP。ISATAP 在 RFC 5214 中进行了规定。

图 7-12 显示了 ISATAP 地址的格式。

ISATAP 地址格式图 7-12. ISATAP 地址格式

ISATAP 地址具有一个标准的 64 位前缀，可以是链路本地、站点本地、6to4 前缀，或者属于全局单播范围。接口标识符是使用 IANA OUI 00-00-5E 构建的，紧跟前缀。接下来的字节是类型字段，值 fe 表示该地址包含一个嵌入的 IPv4 地址。最后四个字节包含 IPv4 地址，可以用点分十进制表示。因此，地址的格式可以总结为 64bitPrefix:5efe:IPv4address。例如，如果您分配的前缀是 2001:db8:510::/64，而 IPv4 地址是 62.2.84.115，那么您的 ISATAP 地址为 2001:db8:510::200:5efe:3e02:5473。或者，您可以写成 2001:db8:510::200:5efe:62.2.84.115。对应的链路本地地址将是 fe80::200:5efe:62.2.84.115。

ISATAP 接口通过其 IPv4 地址形成 ISATAP 接口标识符，并使用这些标识符来创建链路本地 ISATAP 地址。使用 RFC 4861 中指定的邻居发现机制（路由器和前缀发现）。

ISATAP 路由器是一个 IPv6 路由器，同时也可以通过 IPv4 访问，并执行以下操作：

  • 广播地址前缀以标识 ISATAP 主机所在的逻辑 ISATAP 子网。

  • 在逻辑 ISATAP 子网中的 ISATAP 主机与其他子网（IPv4 子网或 IPv6 子网）中的 IPv6 主机之间转发数据包。

  • 作为 ISATAP 主机的默认路由器。

  • 配置逻辑子网中的主机，通过路由器广告进行配置。

使用 ISATAP，IPv4 内部网络中的 IPv6 主机可以相互通信。如果它们想与互联网中的 IPv6 主机通信，则必须配置边界路由器；该路由器可以是 ISATAP 路由器或 6to4 网关。内部网络中主机的 IPv4 地址不需要是公共的，它们被嵌入到标准前缀的地址中，因此是唯一且可路由的。大量的 ISATAP 主机可以分配到一个 ISATAP 前缀下。如果你在公司网络的某个段上部署 IPv6，你可以将一个本地 IPv6 节点配置为 ISATAP 接口，它将充当本地 IPv6 段和 IPv4 段中 ISATAP 主机之间的路由器。

ISATAP 是一种易于部署的机制，如果你想快速测试和使用并且仅有一个 IPv4 路由的网络，它会非常方便。它也可以轻松为 IPv4 网络中的多个 IPv6 用户提供 IPv6 互联网访问。但不建议在生产网络中使用。

注意

在一个无管理的 IPv6 网络中，出于安全原因，你应确保在所有主机上禁用 ISATAP，并在边界上阻止 IPv6 流量。

Teredo

6to4 使得 IPv6 可以通过 IPv4 基础设施使用公共 IPv4 地址进行通信。ISATAP 使得在 IPv4 网络中可以部署 IPv6 主机，无论是否使用公共或私有 IPv4 地址。Teredo 旨在通过在一个或多个 NAT 层级之间隧道传输数据包，利用 UDP 使 IPv6 可用。它在 RFC 4380 中有所规定。RFC 6081 中定义了支持更多类型 NAT 的扩展，RFC 5991 则包含了针对 Teredo 的安全扩展。

许多互联网用户，特别是许多家庭用户，只能通过 NAT（网络地址转换）访问互联网。NAT 在通过 IPv4 基础设施隧道 IPv6 时会产生问题，主要有两个原因：首先，NAT 用户使用私有 IPv4 地址；其次，许多 NAT 配置了入口过滤，不允许许多类型的载荷通过。使用隧道时，IPv6 数据包是 IPv4 的载荷。像 6to4 这样的机制在这些环境中通常会失败，因为它们需要公共 IPv4 地址。如果 6to4 路由器与 NAT 在同一设备上运行，则可以在 NAT 环境中使用 6to4。在所有其他情况下，必须选择其他机制。在我们未来的 IPv6 世界中，我们将不再需要 NAT，但在过渡时期，我们必须处理它们。因此，IPv6 开发人员正在研究允许位于 NAT 后面的用户通过 UDP 隧道 IPv6 数据包访问 IPv6 世界的机制。其中一种机制就是 Teredo。

以下术语与 Teredo 一起使用：

Teredo 服务

通过 UDP 传输 IPv6 数据包。

Teredo 客户端

一个可以访问 IPv4 互联网并需要访问 IPv6 互联网的节点。

Teredo 服务器

一个可以通过公共 IPv4 地址访问 IPv4 互联网的节点，用于为 Teredo 客户端提供 IPv6 连接。

Teredo 中继

一个 IPv6 路由器，可以接收目标为 Teredo 客户端的流量，并使用 Teredo 服务将其转发。

Teredo IPv6 服务前缀

用于构造 Teredo 客户端 IPv6 地址的 IPv6 地址前缀。IANA 分配的全局 Teredo 前缀是2001:0000::/32。

Teredo UDP 端口

Teredo 服务器等待数据包的 UDP 端口号。该端口的默认值是 3544。

Teredo 气泡

一个最小的 IPv6 数据包，由 IPv6 头部和空载荷组成（载荷类型设置为 59，即无下一个头部）。Teredo 客户端和中继使用气泡在 NAT 中创建映射。

Teredo 服务端口

Teredo 客户端发送 Teredo 数据包的端口。此端口附加在客户端的 IPv4 地址之一上。

Teredo 服务器地址

Teredo 服务器的 IPv4 地址。

Teredo 映射地址和 Teredo 映射端口

由一个或多个 NAT 转换的客户端 Teredo 服务端口的 IPv4 地址和 UDP 端口构成的全局 IPv4 地址和 UDP 端口。客户端通过 Teredo 协议学习这些值。

Teredo IPv6 客户端前缀

由 Teredo IPv6 服务前缀和 Teredo 服务器地址组成的全局 IPv6 前缀。

Teredo 节点标识符

一个 64 位标识符，包含客户端可以通过 Teredo 服务访问的 UDP 端口和 IPv4 地址。一个标志指示客户端通过哪个类型的 NAT 访问 IPv4 互联网。

Teredo IPv6 地址

通过将 Teredo IPv6 客户端前缀和 Teredo 节点标识符结合获得的 Teredo IPv6 地址。

Teredo 刷新间隔

在没有“刷新”流量的情况下，Teredo IPv6 地址预期保持有效的时间间隔。该时间间隔取决于到达 Teredo 服务器路径中本地 NAT 配置的参数。默认情况下，客户端假定该时间间隔为 30 秒。

Teredo 第二端口

用于发送或接收数据包以确定刷新间隔的适当值的 UDP 端口，但不用于承载任何 Teredo 流量。

Teredo IPv6 发现地址

用于在 IPv4 子网中发现其他 Teredo 客户端的 IPv4 多播地址。多播地址是 224.0.0.253。

Teredo 服务将 IPv6 数据包作为 UDP 的有效负载进行传输。

Teredo 设计旨在为 IPv6 网络提供可靠的访问。此设计带来了一些开销。只有在没有其他更直接访问方式的情况下，才应使用 Teredo。例如，如果可以在 NAT 上实现 6to4 或甚至 6rd 网关，这是更优的解决方案。

Teredo 地址的格式如 图 7-13 所示。

Teredo 地址格式图 7-13. Teredo 地址格式

Teredo 服务前缀有 32 位，值为 2001:0000::/32。服务器 IPv4 字段长度为 32 位，包含 Teredo 服务器的 IPv4 地址。标志字段有 16 位，定义了地址和使用的 NAT 类型。16 位的端口字段包含客户端 Teredo 服务的映射 UDP 端口；客户端 IPv4 字段包含客户端的映射 IPv4 地址。端口和客户端地址字段中的所有位都被混淆。地址和端口号中的每一位都被反转。

图 7-14 显示了 Teredo 通信。

Teredo 通信图 7-14. Teredo 通信

Teredo 客户端必须预先配置其 Teredo 服务器的 IPv4 地址。启动时，它从其链路本地 IPv6 地址向所有路由器多播地址发送路由器请求。路由器请求通过 UDP 发送到 Teredo 服务器的 IPv4 地址。来自 Teredo 服务器的路由器广告包含 Teredo IPv6 服务前缀。客户端通过将前缀与地址和端口的反转值组合，构建其 Teredo IPv6 地址。

当 Teredo 服务器转发来自 Teredo 客户端的数据包时，它将 IPv6 数据包封装在 UDP 数据包中。它根据目标 IPv6 地址构建 IPv4 地址和 UDP 端口。它使用自身的 IPv4 地址作为源地址，并使用 Teredo UDP 端口（3544）作为源端口。Teredo 服务器的任务是通过 UDP 将来自 Teredo 客户端的数据包转发到正确的目标地址，并将来自外部的数据包转发给内部的正确客户端。

Teredo 中继是一个 IPv6 路由器，使用常规 IPv6 路由机制向外界广播 Teredo 服务前缀。

Teredo 是早期的过渡机制之一，像 6to4 一样被广泛实现。不推荐在生产网络中使用 Teredo。你的 Microsoft Windows 客户端通常默认启用 Teredo（具体取决于操作系统版本和补丁级别）。无论你使用什么操作系统，请确保确认 Teredo 已被关闭。

注意

在一个未管理的 IPv6 网络中，出于安全考虑，你应该确保在所有主机上禁用 Teredo，并在边界处阻止 IPv6 流量。

隧道代理

隧道代理可以被视为虚拟的 IPv6 提供商，为已经通过 IPv4 连接到互联网的用户提供 IPv6 互联网连接。隧道代理在 RFC 3053 中有所规定。

图 7-15 展示了隧道代理的工作原理。

隧道代理如何工作图 7-15. 隧道代理如何工作

需要 IPv6 连接的用户向隧道代理注册。隧道代理代表用户管理隧道的建立、维护和删除。隧道代理可以将数据负载分摊到多个隧道服务器。隧道代理在需要建立、变更或删除隧道时，会将配置信息发送给隧道服务器。隧道代理还会在配置了该功能的情况下，在 DNS 中注册地址。隧道代理必须能够通过 IPv4 地址访问。它也可以拥有一个 IPv6 地址，但这不是必须的。隧道代理与隧道服务器之间的通信可以通过 IPv4 或 IPv6 进行。

隧道服务器是一个双栈路由器，连接到全球互联网。当它接收到隧道代理的配置信息时，它会建立、变更或删除隧道的服务器部分。

客户端是一个双栈主机或路由器，通过 IPv4 连接到互联网。当它希望向隧道代理注册 IPv6 连接时，应该使用标准程序（例如，RADIUS）进行身份验证。通过这种方式，可以避免隧道服务的未授权使用。因此，隧道代理提供隧道服务的访问控制。一旦客户端获得授权，它将提供其 IPv4 地址、一个用于在 DNS 中注册其 IPv6 地址的名称，以及一个指示其是主机还是路由器的信息。如果客户端是路由器，它还应发送关于其希望获取的 IPv6 地址数量的额外信息。隧道代理需要这些信息以便为客户端分配合适的前缀。

隧道代理履行以下任务：

  • 选择隧道服务器作为隧道出口点。如果有多个选项，它会根据预配置的负载共享标准来选择。

  • 为客户端选择一个前缀。前缀可以是任意长度。最常见的值是/48（站点前缀）、/64（子网前缀）或/128（单一主机）。

  • 为隧道定义生命周期。

  • 在 DNS 中注册它分配的全局 IPv6 地址。

  • 配置隧道服务器。

  • 将配置信息发送回客户端。此信息包括隧道参数和 DNS 名称。

这就完成了隧道配置。客户端现在可以访问隧道服务器可以访问的所有 IPv6 网络。

有很多互联网服务提供商（ISP）提供隧道代理服务。通常，用户可以通过浏览器注册，填写表单并接收显示或通过电子邮件发送的配置信息。客户端现在可以手动配置其隧道入口点，或者使用提供商的脚本文件自动化配置过程。

注意

在互联网上有不同的列表可以找到合适的隧道代理。两个著名的提供商是Hurricane Electrics和SixXS。维基百科有一个隧道代理列表。

隧道代理模型适用于较小且隔离的 IPv6 网络，尤其是单个、孤立的 IPv6 主机。它仅适用于公共 IPv4 地址。如果使用私有地址，则必须使用其他机制，例如协议 41 转发。

通过使用 VLAN 实现 IPv4/IPv6 共存

VLAN（虚拟局域网）在企业网络中非常常见，可用于在尚未具备 IPv6 路由器和交换机设备的情况下部署 IPv6。VLAN 标准允许将多个局域网部署在同一个桥接的局域网中。它使用虚拟局域网标记或成员信息，并将其插入以太网帧中。因此，要在这种环境中引入 IPv6，可以部署一个并行的 IPv6 路由基础设施，并通过 VLAN 技术将 IPv6 链路叠加到 IPv4 基础设施上。此设置不需要对 IPv4 环境进行任何更改。有关该场景的详细描述和可能的配置，请参阅 RFC 4554《在企业网络中使用 VLAN 实现 IPv4 和 IPv6 共存》。

IPv6 在 MPLS 网络中的应用

MPLS（多协议标签交换）技术最初是为了提升服务提供商网络核心的转发性能。它本质上是一种隧道机制，数据转发是基于附加到 IP 数据包上的本地相关标签逐跳进行的。这意味着更短的查找时间和更简单的硬件实现。然而，自从 MPLS 问世以来，路由平台在以线速转发 IP 数据包方面的能力已经大大增强。此时，MPLS 的价值不再仅仅体现在转发性能的提升上，更在于它在网络核心中实现流量的分段（基于 MPLS 的 VPN）和组织（流量工程）的能力。这些能力也使得 MPLS 对部署自有网络骨干的大型企业具有吸引力。

MPLS 的操作依赖于存在一个 IGP（内部网关协议），确保 IP 路由在骨干网中正确设置，并且依赖标签交换协议。标签交换协议使 P（提供商）路由器和 PE（提供商边缘）路由器能够为每个数据包从 MPLS 核心的一端到另一端的每个跳点定义一个标签。当 IP 数据包进入 MPLS 核心时，它会被赋予一个本地相关的标签，告知下一个跳点数据包的去向。下一个跳点路由器（有时也称为 MPLS 交换机）会将标签交换为与下一个跳点相关的标签，依此类推，直到目标 PE。目标 PE 前的 P 路由器将去掉标签，并将进入 MPLS 核心的 IP 数据包交给 PE 路由器。PE 路由器则会将数据包进一步进行 IP 路由，直到其最终目的地。

MPLS 是一种通用的隧道机制。因此，无论控制平面实现（IGP 加标签交换）如何，它都可以像转发 IPv4 数据包一样轻松转发 IPv6 数据包。然而，当 MPLS 标签与特定于 MPLS 核心边缘功能的标签相结合时，IPv4 MPLS 核心上承载 IPv6 的选项变得特别容易扩展。换句话说，附加标签可以告知目标 PE 此数据包是什么类型的 IP 数据包，或者数据包应放置在哪种路由上下文中。

目前大多数 MPLS 部署利用 MP-iBGP（多协议内部 BGP；RFC 3107）来增强功能。与各种协议（如 IPv4 和 IPv6）以及不同功能（如 VPN、组播等）相关的地址族可以在 PE 路由器上定义，并将相关流量标记上特定标签。MP-iBGP 在 PE 路由器之间交换这些标签，使它们能够识别并正确处理这些标记的数据包。这些协议或功能标签堆叠在 MPLS 标签之上。将这一功能扩展到 IPv6 非常容易。必须识别 IPv6 地址族，并将类似于 IPv4 的功能（VPN、组播等）与 IPv6 地址族关联。例如：

  • IPv6 的地址族标识符（AFI）= 2

  • 用于在 MPLS 上传输 IPv6 流量的后续地址族标识符 = 4

  • 用于在 MPLS 上传输 VPN IPv6 流量的后续地址族标识符 = 128

因此，IPv6 可以轻松且高效地通过现有的 MPLS 骨干网传输。一般来说，IPv6 通过 MPLS 基础设施的传输可以通过三种方式完成：

IPv6 通过 IPv6/MPLS 核心

MPLS 核心可以直接启用 IPv6，这意味着它原生支持 IPv6。它使用 IPv6 IGP，并在 IPv6 上交换标签。在这种情况下，IPv6 通过 IPv6 MPLS 核心的方式与 IPv4 通过 IPv4 MPLS 核心的方式相同。IPv4 也可以通过这种基于 IPv6 的基础设施进行隧道传输。

通过 MPLS 进行第二层隧道传输

可以在 MPLS 核心上建立第二层隧道。这些隧道简化了使用 MPLS 骨干网进行连接的组织的网络架构。它们将承载任何第 3 层协议，包括 PE 端点之间的 IPv6。

IPv6 通过 IPv4/MPLS 核心

这种方法基于使用 MP-iBGP4 通过 IPv4 在边缘标签交换路由器之间分发 IPv6 前缀（以及相应的标签）。下一跳由 IPv4 地址标识，数据包根据目标 PE 路由器的 IPv4 地址的标签在 MPLS 核心上传输（RFC 4798）。Cisco 将其实现该机制的方式称为 6PE（IPv6 提供商边缘路由器）。相同的概念用于在 IPv4 MPLS 核心上启用 IPv6 VPN（RFC 4659）。

需要特别注意的是，通过 IPv4 MPLS 核心传输 IPv6 是一种非常有效的过渡机制。所需的变化仅仅是 PE 路由器的配置调整（假设功能已得到支持）。在这种部署类型中，IPv6 可以充分利用 MPLS 基础设施提供的所有价值，从线路速率转发到流量工程。

6PE

6PE 的概念基于 MPLS 的层次路由结构，如图 7-16 所示。这里我并不打算讨论一般的 MPLS 技术，目的是展示 MPLS 如何支持 IPv6 的简便引入。

MPLS 路由层次结构图 7-16. MPLS 路由层次结构

在 MPLS 网络的核心是提供商路由器（P）。它们转发 MPLS 数据包，这意味着它们不会处理第 3 层的头部。在核心网络的边缘是提供商边缘路由器（PE）。它们从客户边缘路由器（CE）接收常规的 IP 数据包，应用 MPLS 标签，并将其转发给提供商路由器。MPLS 数据包仅在提供商边缘路由器和提供商路由器之间传输，具体参见图 7-16。

在此环境中，路由工作方式如下：

  • PE 和 CE 路由器使用常见的路由协议（RIP、OSPF、BGP 或静态路由）。PE 路由器通过这些路由协议学习它能够通过 CE 路由器到达的前缀。

  • 每个 PE 路由器通过 MP-iBGP 将从其 CE 路由器学到的前缀通告给其他 PE 路由器，并将其自己作为这些前缀的下一跳。如果在 MPLS 核心中为 IPv6（6PE）建立了全局路由域，那么 MP-iBGP 将使用 SAFI 4 来交换前缀。与前缀一起，PE 还会通告应该在发送到这些前缀的数据包上使用的标签。

  • MPLS 核心使用 IGP，通常是 IS-IS 或 OSPF，来建立 PE 之间的可达性。结合标签交换协议，PE 之间可以建立标签交换路径（LSP）。

IPv6 流量的转发过程如下：

  • 在入口和出口 PE 之间已经存在一个 LSP（标签交换路径；可以理解为隧道），该路径由 MPLS 核心中的基于 IPv4 的控制平面建立。

  • MP-iBGP 已经通知了入口 PE（PE1）下一个跳的 PE 是哪个（通过 IPv4 地址标识的 PE4），并且告诉它应该使用哪个标签来标记 IPv6 目标前缀。

  • 目标地址前缀（CE3）的标签首先由 PE1 附加到从 CE1 接收到的进入 IPv6 流量上。入口 PE1 还会在前面附加出口 PE4 的 IPv4 地址的标签，并将数据包发送到下一跳 P 路由器。

  • P1 路由器交换掉顶部标签（即与出口 PE4 的 IPv4 地址相关的标签），并将数据包转发到下一个 P 路由器。

  • 该过程会继续进行，直到数据包到达与出口路由器相连的 P 路由器。P 路由器移除顶部标签，并将数据包转发到 PE 路由器。

  • 出口 PE4 接收到的数据包只有一个标签；然而，基于该标签，它将知道该如何处理这个数据包。如果这是一个 6PE 部署，它会丢弃该标签，并将 IPv6 数据包交给全局 IPv6 转发过程。

  • 然后，IPv6 数据包会被原生转发到 CE3，再继续转发到目标。

如果你熟悉 MPLS-VPN 的概念，可以将 6PE 视为一个全球性的 VPN，专门用于在所有启用了 IPv6 的 PE 之间传输 IPv6。

6VPE

一旦我们理解了 6PE 的工作原理，并且熟悉 MPLS-VPN，那么 6VPE 将显得是一个非常自然的扩展。对于那些不熟悉 MPLS-VPN 的人，关键概念是虚拟路由与转发（VRF）实例。在 MPLS 骨干网中，如果我们定义了不应该共享或看到彼此流量的域，我们就定义了虚拟私人网络（VPN）。PE 路由器必须维持这种分离，以便每个 VPN 流量在 PE 上被路由和转发时使用的是专门的表，这些表由各自的 VRF（虚拟路由与转发）维护。

在 6VPE 的情况下，我们为 IPv6 专门创建 MPLS-VPN，或者对现有的 VPN 进行双栈配置。控制平面与 6PE 非常相似。MP-iBGP 将交换标签（使用 SAFI 128），这些标签不仅与 IPv6 前缀相关，还与该 IPv6 前缀所属的 VRF 相关。在 PE 设备上，IPv6 接口与 VRF 绑定，因此 IPv6 流量被保持在定义的 VPN 内。转发方式也类似于 6PE，IPv6 数据包会被添加一个顶级标签（通过标签交换协议交换），用于在 MPLS 核心内部进行切换，以及第二个标签（通过 MP-iBGP 交换），用来指示接收 PE 数据包应当进入哪个 VRF。

参考图 7-12，与 6PE 场景中所有 CE 都属于同一全局路由域的情况不同，CE1 和 CE3 属于红色 VRF，而 CE2 属于蓝色 VRF。PE1 将为 CE1 和 CE2 分别维护独立的路由和转发实例。此外，PE1 会为每个 VRF 中的 IPv6 前缀交换标签。转发方式类似于 6PE：

  • 当 CE1 将数据包发送到 CE3 时，数据包通过与红色 VRF 关联的接口进入 PE1。

  • 数据包被添加了用于 CE3 目标 IPv6 前缀的标签（也位于红色 VRF 中），并且附加了用于 MPLS 转发的标签。

  • PE1 将带标签的数据包发送给 P1，P1 交换顶层标签，然后将数据包转发给 P2。

  • P2 去掉顶层标签并将数据包发送给 PE4。

  • PE4 接收带标签的数据包，并根据标签，PE4 知道该数据包属于哪个 VRF，甚至知道该将数据包发送到 VRF 中的哪个位置。

  • PE4 去掉最后的标签，让典型的 IP 路由和转发功能在红色 VRF 内执行，将数据包传送至 CE3。

使用 6PE 或 6VPE 取决于 IPv6 流量支持的服务。如果你只是想为所有 CE 提供访问互联网的 IPv6 连接，那么 6PE 将是一个快速而简便的解决方案。如果你在 MPLS 骨干网络上有多个客户或组织，并且它们被分隔在不同的 VPN 中，那么 6VPE 是 IPv6 使能这些 VPN 的正确解决方案。

MPLS 可以用于通过 IPv4 传输 IPv6 数据包并不意味着你应该为此目的实现 MPLS。如果你没有现成的 MPLS 基础设施，其他隧道机制可能更适合实现你的目标。但如果你已经拥有 MPLS，那么它是一个很好的基础。

注意

如果你想深入了解这一点，可以参考 Ciprian Popoviciu、Patrick Grossetete 和 Eric Levy-Abegnoli（Cisco Press）合著的《部署 IPv6 网络》一书。它是一本关于 IPv6 概念、服务实现及与 IPv4 互操作性的实用指南。

定位符 ID 分离协议（LISP）

LISP（定位符标识符分离协议）是一种新颖的架构，虽然它并非完全为了支持 IPv6 而设计，但它具备了注册 IPv6 地址并使用 IPv4 作为传输工具的能力，使得 LISP 成为 IPv4 上运输 IPv6、连接 IPv6 岛屿或将 IPv6 网络元素直接连接到 IPv6 互联网的非常有用的工具。

当前 IP 地址结构的许多挑战源于这样一个事实：一个 IP 地址（IPv4 和 IPv6）包含了两种不同类型的信息。一种是关于设备位置的信息（在子网信息中，前缀部分），另一种是关于设备身份的信息（主机 ID 和接口 ID）。每次启动笔记本时，你可能会得到不同的 IP 地址；前缀会根据你所在的网络而变化，主机 ID 也可能会发生变化（取决于配置）。LISP 通过将 IP 地址分为两个命名空间来实现这种“间接性”——端点标识符（EID）和路由定位符（RLOCs），这些标识符被分配给路由器，称为隧道路由器。

LISP 创建了一个覆盖网络，带来了以下好处：

  • 多宿主与入口流量工程

  • 地址族独立性（IPv4 和 IPv6；MAC 地址注册在规划中）

  • 高规模虚拟化和多租户支持

  • 数据中心的移动性，包括在移动事件中的会话持久性

LISP 是一个由 IETF 定义的标准，规定在 RFC 6830 至 6836 以及 RFC 7052 中。LISP 仍在持续开发中，相关文档已记录在多个草案中。

图 7-17 展示了 LISP 的基本架构元素。

EID（端点标识符）空间是主机/服务器标识符的 IP 地址空间。它可以是 IPv4 或 IPv6。对于主机/服务器，或者分支、校园或数据中心网络，没有特殊的变化。EID 是主机的身份标识。

RLOC（路由定位符）空间是传输的 IP 地址空间（标识位置）。它可以是 IPv4 或 IPv6。传输网络没有特殊变化，可以是互联网、服务提供商网络或私有 WAN。

由于 LISP 是一个纯网络基础的解决方案，唯一了解 LISP 的设备是隧道路由器（xTR），它有两种类型：入口隧道路由器（iTR）和出口隧道路由器（eTR）。iTR 从分支、校园或数据中心接收一个 IP 数据包，并将原始数据包封装成一个 IPv4/IPv6 UDP 数据包，其中包含两个目标端口（UDP 4341 用于数据，UDP 4342 用于控制）。这个封装数据包的源地址和目标地址由 iTR 和 eTR 的 RLOC（xTR 的传输 IP 地址）定义。eTR 会接收到封装的数据包并进行解封装。xTR 的基本配置是最小的，LISP 对控制平面的负担非常轻（LISP 是数据驱动的，并遵循拉取模型）。

LISP 架构网络元素图 7-17. LISP 架构网络元素

映射数据库由两个功能组成：映射解析器（MR）和映射服务器（MS）。eTR 将通过 map-register 消息，将 EID（可以是 IPv4 或 IPv6）和其 RLOC 地址（可以是 IPv4 或 IPv6）注册到映射服务器。iTR 在处理任何 EID 流量时会询问 MR，哪个目的地 RLOC 应当用于目标 EID（map-request 消息）。MR 将 map-request 转发给 MS，MS 检查其数据库并将 map-request 转发给 eTR，后者将向 iTR 提供更为详细的回答（map-reply 消息）。MR/MS 可以配置在 xTR 上，也可以是独立的路由器或服务器（例如 BGP 路由反射器）。映射数据库具有很高的可扩展性，可以与 DNS 在可扩展性和性能方面进行比较。

为了使 LISP 能够逐步部署，存在一种特殊的 xTR，称为代理隧道路由器（PxTR）。代理入口隧道路由器（PiTR）将 EID 空间宣布到互联网或非 LISP 的 WAN 和校园网络中，而代理出口隧道路由器（PeTR）则用于将封装流量发送到非 LISP 世界。使用 PeTR 的触发条件是来自 MR 的负 map-reply 消息。

LISP 带来了许多优势：

  • 将路由优化从推送转换为拉取

  • 作为一种覆盖技术工作

  • 使用无状态 UDP 封装进行优化传输

  • 计算源 UDP LISP 端口来自原始 IP 数据包，并帮助实现 RLOC 空间中的 ECMP（等成本多路径）负载均衡

  • 使得部署变得非常简便，因为它只涉及网络边缘的设备

这些优势除了在入口处进行真实负载均衡的多宿主使用场景外，还支持 VRF 传输的虚拟化和独特的移动性特性。

但在此背景下，最重要的部分是能够使用 IPv4 作为 IPv6 的传输。LISP 可以用来通过 IPv4 网络连接 IPv6 岛屿，或提供一种可扩展且轻量的解决方案来连接 IPv6 互联网。

图 7-18 展示了 IPv6 通过 IPv4 传输的概念。

LISP IPv6 通过 IPv4图 7-18. LISP IPv6 通过 IPv4

左侧的 LISP 路由器将向 LISP 映射数据库（此处未显示）发送 map-register。它将使用 LISP 路由器的 IPv4 RLOC（互联网 IP 地址）注册 IPv6 服务的 IPv6 地址（IPv6 EID）。

代理隧道路由器（PxTR；右侧的 LISP 路由器）连接到 IPv4 和 IPv6 Internet。PiTR 会将 IPv6 EID 宣布到 IPv6 Internet，以吸引 IPv6 服务的流量。当 IPv6 服务的数据包到达 PiTR 时，它会为该 IPv6 EID 发出映射请求。左侧的 LISP 路由器（eTR）会从 MR/MS 接收到映射请求，并会返回其 IPv4 RLOC。PiTR 现在会创建一个包含 IPv6 EID 和下一跳 IPv4 RLOC 的映射缓存。现在，从 IPv6 Internet 来的包会被封装为 IPv4，并通过 IPv4 Internet 转发。eTR 然后会解封装该数据包，并将其作为原生 IPv6 数据包传递给 IPv6 服务。

从 IPv6 EID 返回到 IPv6 Internet 的流量处理方式类似。iTR 获取 IPv6 数据包，根据配置，它会发出映射请求，或者直接将数据包发送到 PeTR（静态映射缓存）。如果是映射请求，它会从 MR 接收到带有 PeTR IPv4 RLOC 的负面映射回复消息。iTR 现在可以使用其源 IPv4 RLOC 和 PeTR 的 IPv4 RLOC 将 IPv6 数据包封装为 IPv4 数据包。PeTR 获取封装的 LISP 数据包，剥去 IPv4 传输头部，并原生地转发 IPv6 数据包。

这些示例展示了 LISP 在 IPv4 传输上实现 IPv6 的简便性。你可以使用 LISP 控制平面，或者将其配置为静态映射缓存。因此，如果你想通过 LISP 启用 IPv6 over IPv4，只需执行以下步骤：为 xTR 打开 LISP，配置你的控制平面信息（MR 和 MS），并定义需要通过 IPv4 传输的 IPv6 前缀。此外，你还可以向 iTR 添加静态映射条目。

LISP 可在所有 Cisco 路由器上使用，包括 Catalyst 6500/6800 和 Nexus7000。德国 CPE 厂商 AVM 在其 Fritz!Box 中实现了 LISP 用于 IPv6 传输，此外，还有一些开源版本（OpenLISP 或 LISPmob）。其他厂商也计划很快采用 LISP。

图 7-18 中的解决方案可以与其他 LISP 使用案例结合，创建一个实际的网络架构，例如为传输不同 VRF 添加虚拟化，或者通过多宿主提高可用性和负载均衡。

注意

欲了解更多关于 LISP 的信息，请访问 www.lisp4.net 或 www.lisp6.net（此链接仅在您的 IPv6 连接正常时有效）。

LISP 工作组可以在 www.tools.ietf.org/wg/lisp 查找。

通用路由封装

另一个可用的隧道机制是通用路由封装（GRE）。GRE 在 RFC 2784 中进行了规范，旨在将任何协议封装在另一个协议中。被封装的协议——在我们的例子中是 IPv6——被称为乘客协议。用于封装的协议——在我们的例子中是 IPv4——被称为承载协议。

GRE 隧道的配置是手动的。在两个隧道端点（GRE 路由器）上，隧道对端的 IPv4 地址是预配置的。因此，对于每条需要隧道传输 IPv6 的路由，必须单独配置一个隧道。在更复杂的网络中，这可能会导致较高的初始配置工作量。GRE 隧道不能穿越 NAT。它在需要通过同一隧道传输多种协议时非常有用。

软件隧道集线器与辐射部署框架

该框架使用第二层隧道协议版本 2（L2TPv2），本质上是 L2TP 隧道技术。这在已经部署 PPP 的 ISP 中效果良好。在“集线器与辐射”解决方案中，建立了一个软件隧道，通过仅支持 IPv6 的接入网络为家庭网络提供 IPv4 连接，或者通过仅支持 IPv4 的接入网络提供 IPv6 连接。软件隧道是在软件隧道端点之间通过控制协议设置建立的隧道，这些端点具有共享的点对点或多点到点状态。

就像任何隧道机制一样，它可以一直使用，直到其他基础设施能够更新以支持原生 IPv6。许多 ISP 已经部署了它，因为它允许他们利用大量现有的基础设施。它在 RFC 5571 中有所定义。

协议 41 转发

一些 NAT 实现允许从私有局域网内部配置 IPv6 隧道到互联网中的路由器或隧道服务器。这是一种简单且有帮助的方式，可以为位于 NAT 后的 IPv6 节点和 IPv6 网络提供访问 IPv6 互联网的能力。只有在无法使用其他机制（如 6to4 或原生 IPv6）时，才应使用此方法。

具有私有 IPv4 地址并通过仅支持 IPv4 的 NAT 设备连接到互联网的隧道客户端（主机或路由器）可以使用隧道代理或 IPv6 路由器创建 IPv6 隧道。许多 NAT 设备可以配置为根据 IPv4 头部中的协议值 41（用于 IPv6）转发数据包。这为快速部署大量 IPv6 节点和网络提供了机会。

目前，大多数过渡到 IPv6 的解决方案依赖于隧道，假设客户端端点是支持 IPv6 的路由器。然而，现在仅支持 IPv4 的 NAT 设备/路由器的安装基础仍然相当庞大，而大多数客户端操作系统已经支持 IPv6。

SSH（安全外壳）隧道

你不会发现 SSH 隧道作为官方的 IPv6 过渡机制，但它们在不同情况下非常实用，并能提供有效的解决方案。本节将描述它们是什么，以及如何在 IPv6 环境中使用它们。

两个项目的目标，商业版 OpenSSH 和 闭源版 SSH，是为了消除使用 Telnet、rlogin 和 rsh 等未加密协议。 本节并不是 SSH 的完整概述，而是展示了如何将 SSH 隧道作为 IPv4 到 IPv6 及其反向过渡的简易机制。

注意

如果想要更深入了解 SSH，我们推荐阅读《SSH——安全外壳，权威指南》，第二版，由 Daniel J. Barrett 等人编写（O'Reilly 出版）。

这两个项目都支持一种叫做端口转发的实践，它本质上允许在机器之间转发 TCP 端口。它也被称为穷人的 VPN。在图 7-19 所示的场景中，我们有一个仅支持 IPv4 的客户端连接到运行双栈主机的 SSH 版本（这两个版本的 SSH 都支持 IPv6）。

IPv4 客户端通过双栈 SSH 主机连接到仅支持 IPv6 的服务器图 7-19。IPv4 客户端通过双栈 SSH 主机连接到仅支持 IPv6 的服务器

IPv4 客户端希望通过仅支持 IPv6 的服务器发送邮件。通过 SSH 的灵活性，可以通过两种方式实现这一目标，接下来将进行描述。以下示例展示了如何使用两个厂商提供的命令行 SSH 客户端来实现这一点，但也可以使用 GUI 工具轻松实现（请查阅您厂商的文档了解 GUI 工具的使用）。

将 TCP 端口 25 转发回客户端

在 SSH 服务器上输入以下命令允许单一 IPv4 客户端访问 IPv6 邮件服务器：ssh -L 25:[2001:db8::11]:25 user@192.168.1.101。输入密码后，该命令将从 IPv6 服务器将 TCP 端口 25 转发回仅支持 IPv4 的客户端。在客户端，输入简单的telnet 127.0.0.1 25命令可以看到数据实际上是在本地主机上发起的，然后通过 SSH 服务器转发到仅支持 IPv6 的 SMTP 服务器。这可能听起来有点复杂，但它运行得非常好。

将 TCP 端口 25 转发到 SSH 服务器并允许客户端连接到 SSH 服务器上的端口 25

尽管这种方法在初始设置时稍显复杂，但可以简化管理问题；连接只需要初始化一次，然后每个客户端都可以连接到 SSH 服务器。以下命令需要在 SSH 服务器上输入：ssh -g -L 25:[2001:db8::11]:25 user@127.0.0.1。在服务器上输入并登录后，你应该能够输入telnet 127.0.0.1 25并得到 IPv6-only SMTP 服务器的 SMTP 提示符。这里的区别在于 SSH 命令中的-g选项，它允许启用网关模式。在网关模式下，除本地主机外的客户端也可以连接到该端口。在 IPv4-only 工作站上输入命令telnet 192.168.1.101 25，允许该客户端连接到双栈 SSH 服务器的 IPv4 端，并将数据转发到仅支持 IPv6 的 SMTP 服务器。

SSH 隧道的灵活性允许多种其他组合，包括客户端能够转发端口并使用预生成的密钥以简化管理（无需登录）。使用 SSH 作为过渡机制的缺点包括仅能转发 TCP 连接，并且在使用同一台机器转发多个端口时可能会产生较高的处理开销。

通过 IPv6 实现 IPv4 残余部署（4rd）

4rd 是一种无状态的自动隧道机制，用于在 IPv6 网络上透明地隧道传输 IPv4 数据包。它是 6rd 的逆向机制。由于 IPv6 头部过长，无法映射到 IPv4 头部，因此 6rd 需要将完整的 IPv6 数据包封装到 IPv4 数据包中，而 IPv4 头部可以反向转换为 IPv6 头部，确保在 IPv6 域中传输时，具有校验和的 UDP 数据包和 TCP 数据包是有效的 IPv6 数据包。

4rd 在撰写时处于草案状态。该草案名为“通过 IPv6 实现 IPv4 残余部署——无状态解决方案（4rd）”(draft-ietf-softwire-4rd-08)。

网络地址和协议转换

NAT（网络地址转换）和协议转换是 IPv6 部署场景中争议最多的领域。本节讨论了为了解决 IPv4 地址枯竭问题而提供的不同形式的 NAT，以及 IPv6 的整合。

网络地址和协议转换技术提供了除双栈和隧道技术之外的过渡机制。其目标是为 IPv6 网络中的节点与 IPv4 网络中的节点之间的通信提供透明的路由，并支持双向通信。

注意

与隧道技术不同，原始的 IPv6 数据包保持不变，仅被封装在 IPv4 头部中，然后在隧道端点解封装；而翻译数据包则在翻译器处根据所定义的规则进行修改，这些规则被称为无状态 IP/ICMP 转换算法（SIIT；RFC 6145）。

在 IPv4 环境中，网络地址和端口转换（NAPT，通常简称为 NAT）早在许多年前就被定义，用于将网络内部的私有地址映射到面向外部世界的公共地址，以解决公共 IPv4 地址池的持续枯竭问题。这是一种有状态的技术，因为网关需要维护状态以正确地路由返回数据包。在我们当前的双栈环境中，这种类型的 NAT 通常被称为NAT44。为了为众多设备提供始终在线的连接，NAT 不仅仅是映射设备和地址，还为每个地址使用端口，将多个私有地址映射到一个公共地址上。UDP 和 TCP 每种协议都有 65,636 个端口号可用，其中许多端口未被使用。因此，NAT 实际上是将内部的私有地址和端口号映射到外部的公共地址和端口号上。这样，它就可以为每个公共地址映射大量的会话。这个 NAT 通常位于客户边缘，并运行在 CPE（客户驻地设备）上。

我们已经拖延了 IPv6 的部署，并且现在 IPv4 地址空间即将耗尽，这将迫使我们使用这种过渡技术来应对互联网的指数级增长。问题在于，如果新的互联网用户仅获得 IPv6 地址，他们将无法访问目前仍以 IPv4 为主的网络内容。因此，IETF 工作组决定定义标准的翻译方法，以防止行业开发出不可控的非标准方法。

在我们讨论今天可用的不同类型的 NAT 之前，先来看看 IP 和 ICMP 翻译的规范。

无状态 IP/ICMP 翻译

在 IPv4-only 主机希望与 IPv6-only 主机通信，或反之的情况下，RFC 6145 定义了协议翻译器如何翻译 IP 和 ICMP 头，以使双方能够理解对方。例如，你可能有一个新的网络段，并希望推出本地 IPv6 主机。通过实现协议翻译器，可以内部设置新的 IPv6-only 网络，并让这些 IPv6-only 客户端访问标准的 IPv4 互联网或任何其他 IPv4-only 节点。

在讨论中，我们需要引入一些术语。它们在 RFC 6052《IPv4/IPv6 翻译器的 IPv6 地址分配》中有所定义，这是关于 IPv4/IPv6 翻译系列文档的一部分。该文档规定了在使用算法映射时，如何将单个 IPv6 地址转换为 IPv4 地址，反之亦然。

地址翻译器

一种从 IPv6 地址派生 IPv4 地址或反向操作的设备。这适用于进行 IPv4/IPv6 翻译的设备，也适用于其他操作地址的设备，如名称解析代理（例如稍后描述的 DNS64）以及其他类型的应用层网关（ALG）。

IPv4 转换 IPv6 地址

用于表示 IPv6 网络中 IPv4 节点的 IPv6 地址。它是 IPv4 嵌入式 IPv6 地址的一种变体。

IPv4 嵌入式 IPv6 地址

一种 IPv6 地址，其中 32 位表示一个 IPv4 地址。

IPv4/IPv6 翻译器

一种将 IPv4 数据包转换为 IPv6 数据包，反之亦然的设备。翻译可以是无状态（不需要每个流的状态）或有状态（当接收到流中的第一个数据包时，会创建每个流的状态）。

IPv4 可转换 IPv6 地址

分配给 IPv6 节点用于无状态翻译的 IPv6 地址。它是 IPv4 嵌入式 IPv6 地址的一种变体。

网络特定前缀

由组织分配的用于算法映射的 IPv6 前缀。

著名前缀

用于算法映射的著名前缀是64:ff9b::/96。

所有嵌入 IPv4 的地址都遵循 RFC 6052 中表格描述的相同格式。该表格包含一个可变长度的前缀、嵌入的 IPv4 地址和一个可变长度的后缀（后缀的长度取决于前缀的总长度，前缀的长度可以从 32 位到 96 位不等）。RFC 中的表格列出了所有可能的选项。

前缀可以是网络特定的前缀或是著名的翻译前缀。对于无状态翻译，应使用网络特定前缀。对于有状态翻译，组织可以在网络特定前缀和著名前缀之间选择。著名前缀应在大多数情况下使用，除非出于管理和操作原因，或在 IPv6 网络连接到 IPv4 网络的场景中，认为使用其他前缀更合适。

伴随的 RFC 6144 《IPv4/IPv6 翻译框架》描述了八种不同的场景，并概述了有状态和无状态翻译的要求和规则。它们列在 NAT64 场景一节中。

TCP 和 UDP 头部通常不需要由翻译器修改。一个例外是需要为 IPv6 提供校验和的 UDP 头部，因为 IPv6 需要 UDP 校验和。ICMPv4 消息同样需要为 ICMPv6 提供校验和。此外，ICMP 错误消息的有效负载中包含原始数据包的 IP 头部，需要由翻译器修改；否则，接收节点无法理解该数据包。IPv4 选项、IPv6 路由头、逐跳选项头和目的选项头不进行翻译。此外，翻译技术不能用于多播流量，因为 IPv4 多播地址无法映射到 IPv6 多播地址，反之亦然。

就像在双栈节点中一样，运行 IP/ICMP 翻译的节点上的应用程序需要一种机制来确定与对等节点通信时使用哪个协议版本。

将 IPv4 翻译为 IPv6

一个 IPv4 到 IPv6 的翻译器接收到一个 IPv4 数据报。因为它已经配置为知道代表内部 IPv6 节点的 IPv4 地址池，翻译器知道该数据包需要翻译。它移除 IPv4 头部，并通过将 IPv4 头部的所有信息翻译到 IPv6 头部，来替换为 IPv6 头部。

路径 MTU 探测在 IPv4 中是可选的，但在 IPv6 中是强制性的。如果 IPv4 主机通过在头部设置不分片位来进行路径 MTU 探测，那么即使通过翻译器，路径 MTU 探测也能正常工作。发送方可能会从 IPv4 和 IPv6 路由器接收到“数据包过大”消息。如果在 IPv4 数据包中未设置不分片位，则 IPv6 翻译器必须确保该数据包可以安全地通过 IPv6 网络。它通过必要时对 IPv4 数据包进行分片来实现这一点，使用 IPv6 的最小 MTU 1,280 字节。IPv6 保证 1,280 字节的数据包可以顺利传输，无需进一步分片。在这种情况下，翻译器始终包括一个分片头，以表明发送方允许分片。如果该数据包通过 IPv6 到 IPv4 的翻译器，翻译器知道它可以对该数据包进行分片。

对于一个校验和为零的 UDP 数据包，翻译器必须计算一个有效的 IPv6 校验和。如果翻译器接收到一个分片的 UDP 数据包的第一个分片，且其校验和为零，它应丢弃该数据包并生成一个系统消息，指定 IP 地址和端口号。后续分片应被静默丢弃。

将 ICMPv4 转换为 ICMPv6 及反向转换

对于所有 ICMPv4 消息，翻译器必须计算一个有效的校验和，因为 ICMPv6 要求校验和。此外，还需要转换类型值，对于错误消息，还需要转换其中包含的 IP 头。互联网组管理协议（IGMP）消息是单跳消息，不应通过路由器转发。因此，它们不需要转换，并会被静默丢弃。

同样的翻译规则适用于 ICMPv6 消息到 ICMPv4 消息的转换，只是顺序相反。

将 IPv6 转换为 IPv4

这个过程与之前讨论的翻译过程没有太大区别。在这种情况下，翻译器知道它必须根据 IPv4 映射的目标地址将 IPv6 转换为 IPv4。它移除 IPv6 头并用 IPv4 头替换。IPv4 的最小 MTU 为 576 字节，IPv6 的最小 MTU 为 1,280 字节。如果翻译器收到一个用于 IPv4 网络的较小 MTU 的数据包，它将在翻译后创建 1,280 字节的数据包并进行分片。

使用 NAT 扩展 IPv4 地址空间

本节实际上并不是关于 IPv6 过渡的内容。它解释了 NAT 如何被用于扩展 IPv4 地址空间（这也是 NAT 最初的设计目的）。这些机制将被全球的 ISP 使用，因为我们等待得太久，IPv4 地址空间已经耗尽。这些机制对用户访问 IPv4 网站的方式产生了重大影响。

运营商级 NAT

随着提供商用完 IPv4 地址且无法用 IPv4 满足互联网增长的需求，他们必须部署 IPv6。但用户希望实现双栈（dual-stack），因为他们希望能够访问互联网上的 IPv4 内容。那么，为什么不对互联网连接的 IPv4 部分进行 NAT 转换呢？这样用户可以通过 IPv6 访问 IPv6 内容，但仍能通过其 NAT 转换的 IPv4 连接访问 IPv4 内容。

这可以通过我们所称的运营商级 NAT（CGN，也叫大规模 NAT（LSN））来实现，或者称为NAT444。这意味着我们通过在 ISP 网络内增加一个 NAT44 层，将 NAT44 与运营商级 NAT（CGN）相结合。传统的 NAT44 位于客户网络和 ISP 网络之间。而 CGN 则位于客户网络和 ISP 网络之间，允许 ISP 为客户分配私有 IPv4 地址，而不是公共地址。换句话说，传统的客户端 NAT 现在将私有 IPv4 地址从内部转换为私有 IPv4 地址到外部。图 7-20 以图示方式展示了这一点。

运营商级 NAT图 7-20. 运营商级 NAT

在底部，我们看到传统的 NAT 通过 NAT 将客户的私有地址网络连接到提供商网络。在这个 NAT444 场景中，地址转换是从私有 IPv4 到私有 IPv4。这允许 ISP 通过外部的单一公共 IPv4 地址连接多个客户。

让我们跟踪一个数据包。它从客户站点内部发起，地址从私有内部地址转换为 CGN 内部的私有地址。当离开 ISP 网络时，它会获得分配给 CGN 外部接口的公共地址。该数据包经过两次地址转换和端口映射。这个机制被称为 NAT444，因为它只将 IPv4 转换为 IPv4，目的是扩展地址空间。其优点是大多数情况下可以通过现有设备和实现来完成。

经验将显示这一方案在大量用户中如何扩展。对于大量用户的所有翻译和映射所需的处理能力将有其极限，而这些极限尚未确定。如果一个组织在内部使用与提供商在 CGN 中相同的地址范围，可能还会出现重叠私有空间的问题。如果连接到同一 CGN 的客户想要互相发送流量，可能也会出现问题。它们的数据包可能必须路由到外部，再返回时使用公共 IPv4 源地址；否则，可能会被基于其私有源地址的传统访问控制列表（ACL）过滤掉。

与传统的 NAT 不同，在传统的 NAT 中，一个站点的用户共享一个公共 IPv4 地址，而在 CGN 中，多个客户共享一个公共 IPv4 地址。这可能会引发一些关键问题。例如，如果有人成功攻击了该公共 IPv4 地址，不仅是一个客户，所有使用该 CGN IPv4 地址的客户都可能受到影响。如果其中一个客户是恶意用户并被列入黑名单，那么所有共享相同地址的客户都将受到影响。

另一个问题是，所有这些客户共享一个固定的端口池，因此每个客户可用的端口数量有限，而客户的数量可能会增加。当用户运行需要大量多个同时会话的应用程序时，比如 Google Maps 或 iTunes 等，CGN 网关可能会耗尽端口号和会话。事实上，今天的应用程序对并行会话的需求不断增加。这导致应用程序或服务可能无法正常运行，甚至失败。对于一个位于 CGN 后面的用户来说，这通常是无法追踪的。用户会认为该网站没有运行或存在问题。

注释

从内容提供者的角度来看，你希望提供双栈公共服务，以绕过 CGN，并确保客户在访问你的网站时有良好的体验。如果你的内容是双栈的，那么使用 IPv4 CGN 访问的互联网用户可以通过原生 IPv6 访问你的网站（前提是他们的服务提供商提供 IPv6 互联网接入）。

有一篇有趣的 RFC，RFC 7021《评估运营商级 NAT 对网络应用的影响》，它总结了 CableLabs、时代华纳有线电视公司和罗杰斯通信公司对 CGN 的测试。他们独立测试了 NAT444 对许多流行互联网服务的影响，使用了多种测试场景、网络拓扑和供应商设备。该 RFC 指出，增加第二层 NAT 会破坏常见互联网应用的通信通道。

NAT464

解决这个问题的另一种方式是，在客户边缘和服务提供商网络之间部署仅 IPv6。这需要在客户边缘进行 IPv4 到 IPv6 的转换，并在 CGN 处进行 IPv6 到 IPv4 的转换。这减少了服务提供商端对 IPv4 地址的需求。因为跨协议的转换（从 IPv4 到 IPv6）比同一协议族内的地址转换更为复杂，转换变得更加困难。另外，NAT444 被广泛实现并可用，而 NAT464 的实现目前还没有那么普及。图 7-21 展示了 NAT464 网络。

NAT464图 7-21. NAT464

在这种情况下，服务提供商通过使用仅 IPv6 的网络，并通过 NAT46 将客户的 IPv4 流量转换为 IPv6，再通过 CGN 使用 NAT64 将其转换回 IPv4，从而节省了 IPv4 地址空间，而不是为客户的 CPE 分配私有 IPv4 地址。在这两种情况下，通过 CGN 和 NAT464，多个客户共享一个公共 IPv4 地址。

这种类型的转换的一大缺点是，除了 NAT 设备始终是瓶颈之外，当你必须将 IPv6 转换为 IPv4 时，你会失去 IPv6 的所有高级功能，因为它们无法转换为 IPv4。例如，如果数据包具有扩展头部，并非所有信息都能转换为 IPv4 选项。但是，在这个场景中，由于应用程序是 IPv4 并且隧道用于从一个 IPv4 网络到另一个 IPv4 网络，可能不会丢失任何高级的 IPv6 功能。

DS-Lite

DS-Lite 是另一种机制，允许客户站点与 CGN 之间仅使用 IPv6 连接。与 NAT464 中的 IPv4 到 IPv6 和 IPv6 到 IPv4 的双向转换不同，IPv4 数据包被封装在 IPv6 中传输到 CGN。也就是说，去除了一个从 IPv4 到 IPv6 和 IPv6 到 IPv4 的转换层，如同 NAT464 中那样。DS-Lite 在 RFC 6333 中进行了规范。该规范中的新术语包括：

DS-Lite 基本桥接宽带元素 (B4)

B4 是在支持双栈的节点上实现的一个功能。该节点可以是直接连接的节点，也可以是创建到 AFTR（下文定义）的隧道的 CPE（客户驻地设备）。

DS-Lite 地址族过渡路由器 (AFTR)

AFTR 是 IPv4-in-IPv6 隧道端点和同一节点上实现的 IPv4-IPv4 NAT 的组合。AFTR 可以配置不同的 NAT 池，并为不同的客户群提供不同的地址池。

DS-Lite 如图 7-22 所示。

DS-Lite图 7-22. DS-Lite

该图显示，私有客户网络通过 IPv6 隧道连接到 ISP 私有网络。NAT 将 IPv6 源地址、IPv4 源地址加端口的组合映射到外部 IPv4 地址加端口。多个客户共享一个公共 IPv4 地址。所有在 IPv6 隧道中的 IPv4 数据流都在 AFTR 结束。当客户使用 IPv6 通信时，不需要隧道，AFTR 被绕过，流量直接出去。这里的关键是确保源地址是唯一的。如果多个客户使用私有 RFC 1918 地址连接，其源地址将不再可区分。DS-Lite 通过将 IPv4 源地址与用于隧道的唯一 IPv6 地址关联，解决了这个问题。

通常，CPE 具有 DHCPv4 功能，向家庭网络中的主机分配私有 IPv4 地址空间。它还会自我广播为 DNS 服务器，并应运行 DNS 代理，将来自 IPv4 主机的 DNS 查询通过 IPv6 网络转发至服务提供商的 DNS 服务器。为了建立与 AFTR 的隧道，B4 元件通过手动配置或 DHCPv6 配置 AFTR 的 IPv6 地址。RFC 6334 定义了一个 DHCPv6 DS-Lite 选项。IANA 已定义了一个众所周知的 IPv4 子网地址来表示 B4 元件。该范围为 192.0.0.0/29。192.0.0.1 被保留给 AFTR 元件，192.0.0.2 被保留给 B4 元件。

相比于 NAT444 或 NAT464，DS-Lite 移除了一个 NAT 层级。其缺点是单个用户不再能通过 IP 地址来识别。目前，DS-Lite 仅在 IPv6 隧道中指定 IPv4。未来可能会定义其他类型的封装。例如，RFC 6619《具有每接口绑定的地址转换器的可扩展操作》定义了一种解决方案，允许在向 IPv6 迁移的过程中使用协议转换，以一种支持大规模用户基础的方式部署这些机制，而无需相应的大 IPv4 地址块。

RFC 6908《DS-Lite 部署考虑事项》提到了 RFC 6333 附录中提到的 DS-Lite 场景，并描述了在部署 DS-Lite 时可能出现的问题以及如何缓解这些问题。该 RFC 中的信息和建议基于现实世界的经验，对运营商具有参考价值。

DS-Lite 正在进行扩展（在写作时为草稿状态），称为 Lightweight 4over6（LW46）。它将网络地址和端口转换（NAPT）功能从集中式的 DS-Lite 隧道集中器移至位于 CPE 的隧道客户端。这消除了隧道集中器中对运营商级 NAT 功能的需求，并将必须保持的集中式状态减少到每个用户级别。

NAT 作为 IPv6 翻译机制

在早期的 IPv6 发展中，RFC 2766《NAT-PT，网络地址转换—协议转换》中定义了一个主要的翻译机制。由于其过于复杂，它在 RFC 4966 中被移至历史性标准。SIIT（无状态 IP/ICMP 翻译）RFC 仍然有效，并且该规范在新型的翻译器中得到了使用，例如在 NAT64 中。

以下章节描述了多种不同的翻译技术，其中一些仍处于草稿状态。根据您阅读本书的时间，它们可能会作为 RFC 发布。

注意

预计将会出现更多种类和形式的翻译机制。但请注意，主要的建议是，如果可能的话，不要使用这些机制，而是尽量使用原生 IPv6，尤其是在企业网络中。服务提供商可能需要使用翻译机制，主要是由于 IPv4 地址短缺。作为互联网用户，你需要了解你的服务提供商从 IPv4 和 IPv6 角度提供的接入类型。

无状态 NAT64

无状态 NAT64 提供了一种翻译机制，它将 IPv6 头部翻译为 IPv4 头部，反之亦然。它基于 RFC 6144，该 RFC 定义了 IPv4/IPv6 翻译的框架，并提供了所有可能场景的概述和讨论。由于其无状态特性，该机制非常高效。它支持端到端透明性，并且具有比有状态翻译更好的可扩展性。多个翻译器可以并行部署，而无需在它们之间同步状态。

对于无状态机制，翻译信息携带在地址本身中。要执行无状态翻译，必须有一个规则来定义如何将 IPv6 地址翻译为相应的 IPv4 地址，反之亦然。一个特定的 IPv6 地址范围代表了 IPv6 世界中的 IPv4 系统。这个范围在 NAT 设备上手动配置。在 IPv4 世界中，所有的 IPv6 系统都拥有直接关联的 IPv4 地址，可以映射到服务提供商的 IPv4 地址子集。IPv6 主机通过手动配置或 DHCPv6 分配 IPv6 地址。嵌入 IPv4 的 IPv6 地址格式在 RFC 6052 的第 2.2 节中进行了描述。用于算法映射的知名前缀是64:ff9b::/96。常见的实现通常允许你从你的 IPv6 地址范围中配置自己的前缀。

使用无状态 NAT64，能够从双方发起会话，即从 IPv4 到 IPv6，反之亦然。其缺点是每个需要翻译的 IPv6 设备都会消耗一个 IPv4 地址。因此，它不是解决 IPv4 地址枯竭问题的方案。它可以用于为公共服务器提供支持两种协议的 IP 地址。但为了将多个 IPv6 用户聚合到一个 IPv4 地址上，必须使用有状态 NAT64。无状态 NAT64 的另一个限制是，只有 IPv4 选项中在 IPv6 中有直接对应项的才会被翻译，并且它不翻译 IPv6 扩展头部，除了分片头部。无状态 NAT64 的最佳使用案例可能是为 IPv4 客户端提供访问 IPv6 服务器的功能。

有状态 NAT64 和 DNS64

该场景用于仅拥有 IPv6 地址的用户需要连接到 IPv4 网络及 IPv4 互联网的情况。一个或多个公共 IPv4 地址被分配给翻译器，由 IPv6 客户端共享。当使用 DNS64 配合有状态 NAT64 时，通常不需要在 IPv6 客户端或 IPv4 服务器中做出任何更改。要支持 DNS64，请使用 BIND 9.8.0。RFC 6146 规定了有状态 NAT64，RFC 6147 规定了 DNS64。

图 7-23 显示了这一工作原理。

有状态 NAT64 和 DNS64图 7-23. 有状态 NAT64 和 DNS64

IPv6 客户端向 DNS64 服务器发送 DNS AAAA 请求以查询某个域名。如果该域名服务器有 AAAA 记录，它会传递相关信息，客户端将通过 IPv6 连接。如果 DNS64 服务器没有 AAAA 记录，因为它是仅支持 IPv4 的服务，它会找到相应的 A 记录并创建合成记录。域名服务器使用 64:ff9b::/96 的知名前缀，或为此目的选择并配置的特定前缀，将从 A 记录中获取的 IPv4 地址插入到 IPv6 地址的低 32 位。因此，如果 A 记录是 203.10.100.2，IPv6 地址将是 64:ff9b::203.10.100.2。

当客户端初始化连接到此地址时，它将通过 NAT64 网关进行路由，NAT64 网关将使用其池中的一个 IPv4 地址及相关端口号，创建这两个地址的映射条目。然后，它将使用 RFC 6145 中描述的翻译机制，将 IPv6 头部翻译为 IPv4 头部，并将其发送到从 IPv6 地址中获取的目标 IPv4 地址。

有状态 NAT64 仅支持由 IPv6 发起的连接，因此适用于提供 IPv4 主机访问的 IPv6 单栈主机。其优势在于，许多 IPv6 单栈主机可以通过一个公共 IPv4 地址连接到 IPv4 互联网。如果 IPv4 设备需要与 IPv6 单栈设备通信，必须手动配置翻译。

经过测试，这种方法在一般的互联网访问中运行良好。但当 IPv4 地址嵌入应用程序中或使用 IPv4 字面量时，会出现问题。RFC 7050 定义了一种方法，说明客户端如果无法查询 DNS64 服务器时，如何发现 NAT64 前缀。应用程序开发人员应坚持在应用程序中使用 FQDN（完全限定域名）而非 IP 地址。一些厂商已实现有状态 NAT64，许多大型移动提供商正在进行试验。在移动世界中，这种机制可能更受欢迎，因为它比双栈客户端消耗更少的移动客户端电池。

NAT64 场景

如 RFC 6144 中所列，NAT64 可以翻译八种不同的场景。下列清单显示了哪些类型的 NAT64 支持翻译：

IPv6 网络到 IPv4 互联网

无状态和有状态 NAT64 都可以支持此场景。

IPv4 互联网到 IPv6 网络

要使该场景与有状态 NAT64 配合工作，必须使用 DNS 应用层网关（ALG）。此功能已在 RFC 4966 中弃用。可以使用无状态 NAT64 来支持该场景，因为它支持由 IPv4 节点发起的连接。

IPv6 互联网到 IPv4 网络

无状态 NAT64 不适用于此场景，因为无状态 NAT64 仅支持 1:1 地址转换。IPv4 地址空间只能支持 IPv6 地址空间的一小部分。但通过有状态 NAT64，可以支持 IPv6 发起的连接。一个网络特定的前缀将分配给转换器，用于为主机分配已转换为 IPv6 的 IPv4 地址。可以将静态 AAAA 记录放入 DNS 中，表示这些仅支持 IPv4 的主机。

IPv4 网络到 IPv6 互联网

为了使该场景与有状态 NAT64 配合工作，必须使用 DNS 应用层网关（ALG）。此功能已在 RFC 4966 中弃用。此场景被认为不可行，因为这些需求只会出现在 IPv6 互联网的后期部署阶段。对于该场景，应考虑其他技术。

IPv6 网络到 IPv4 网络

对于此场景，两个网络位于同一组织内。从转换的角度来看，该场景与场景一相同。因此，可以使用无状态和有状态转换。

IPv4 网络到 IPv6 网络

对于此场景，两个网络位于同一组织内。从转换的角度来看，该场景与场景二相同。因此，适用相同的规则。

IPv6 互联网到 IPv4 互联网，反之亦然

由于两个地址空间之间存在巨大的大小差异，目前没有可行的转换技术可以处理无限制的 IPv6 地址转换。

如果您对 NAT64 与 CGN 或作为服务器前端（FE）机制的操作经验感兴趣，请参阅 RFC xxxx（draft-ietf-v6ops-nat64-experience-10.txt）。该报告记录了在 IPv6 仅移动网络与更大的 IPv4 互联网之间部署和测试 NAT64 服务的操作经验，以及在 IDC 环境中部署的 NAT64 服务。此测试包括 NAT64 CGN 和 NAT64 FE 的使用；它与更传统的 NAT44 的共存；可靠性、可用性和可维护性问题；源地址的透明性或缺失；体验质量；MTU 问题；以及与 ULA 相关的问题。

RFC 6889《有状态 64 翻译分析》分析了有状态 NAT64 如何解决导致 NAT-PT（RFC 2766）被弃用的问题。

464XLAT

464XLAT 不是一个独立的过渡机制。RFC 6877 描述了一个架构，该架构将核心网络中的有状态转换与网络边缘的无状态转换相结合。这为 IPv4 仅应用程序提供了跨 IPv6 仅网络的 IPv4 连接。

为了讨论 464XLAT，我们必须引入两个术语：

PLAT

PLAT 是一种提供者端翻译器（XLAT），遵循 RFC 6146 中关于有状态 NAT64 的规范。它将 N:1 的全局 IPv6 地址转换为全局 IPv4 地址，反之亦然。

CLAT

CLAT 是客户侧翻译器（XLAT）。它遵循 RFC 6145 中关于 IP/ICMP 翻译算法的规范。它将 1:1 的私有 IPv4 地址转换为全局 IPv6 地址，反之亦然。CLAT 可以运行在路由器上或终端设备上，例如手机。它执行 IP 路由，转发数据包通过无状态翻译。

464XLAT 提供易于使用的过渡服务，因为它不需要新的协议。它鼓励部署 IPv6-only 网络，这些网络比双栈网络的运营成本更低。当 IPv4 地址不再可用，但 IPv6-only 主机仍需访问 IPv4 应用程序时，它也非常必要。因此，它将网络边缘的增长与 IPv4 地址的可用性解耦。

图 7-24 展示了 464XLAT 架构。

464XLAT 架构 图 7-24. 464XLAT 架构

在图的左侧，您可以看到三种不同类型的客户端：一个 IPv6-only 主机，一个具有私有 IPv4 地址的双栈主机，以及一个 IPv4-only 主机，也具有私有 IPv4 地址。IPv6 主机可以直接访问 IPv6 网络，而无需翻译。IPv6 主机可以通过 PLAT（NAT64）访问全球 IPv4 主机。IPv4 主机可以通过 CLAT 上的无状态翻译和 PLAT 上的有状态翻译访问全球 IPv4 主机。

464XLAT 地址格式遵循 RFC 6052 中第 2.2 节表格所描述的 IPv4 嵌入式 IPv6 地址格式，标题为“IPv4/IPv6 翻译器的 IPv6 地址分配”。CLAT 需要一个用于上行接口的 /64 IPv6 前缀，一个用于每个下行接口的 /64 前缀，以及一个专用的 /64 前缀，用于发送和接收无状态翻译的数据包。

想要发现 NAT64 前缀的 IPv6-only 主机会向其 DNS 服务器发送一个查询请求，查询域名 ipv4only.arpa 的 AAAA 记录（RFC 7050）。如果存在 NAT64 前缀，主机会收到一个 DNS 响应，其中包含合成的 AAAA 记录。这个 AAAA 记录包含了 IPv6 前缀和 ipv4only.arpa 的 32 位 IPv4 地址。CLAT 使用该前缀将数据包发送给翻译器。

该架构支持客户端-服务器模型中的 IPv4。它并不设计用于 IPv4 点对点通信或入站 IPv4 连接。它基于 IPv6 传输，并支持原生的 IPv6 通信。其优点在于，它同样适用于包含字面值的 IPv4 应用程序，因为仅 IP 头部会被翻译，数据包的有效负载则被封装在翻译后的头部中。

MAP

开发了一种新机制，称为MAP。它有两种版本，都指定了将 IPv4 映射到 IPv6 的机制。草案“draft-ietf-softwire-map”，即 MAP-E，指定了 IPv4 数据包在 IPv6 中的封装，包括 IPv6 和 IPv4 地址之间的地址映射，且两者之间相互独立。另一个草案“draft-ietf-softwire-map-t”指定了 MAP-T 机制，它使用相同的地址和端口映射算法，并提供与 MAP-E 相同的功能，但采用的是转换而不是封装。两种机制的目的是在仅支持 IPv6 的基础设施中提供 IPv4 服务，这种情况和需求在未来将会变得越来越普遍。

与 CGN、NAT464 和 DS-Lite 相比，MAP 的最大优势在于它不需要在服务提供商网络中部署中央有状态转换器。这使得提供商可以部署原生 IPv6，并以更少的开销共享稀缺的 IPv4 地址资源。

MAP 如图 7-25 所示。

MAP图 7-25. MAP

如图所示，转换被移到了 CPE 端。通过服务提供商网络的所有流量现在都是 IPv6-only。这消除了对有状态 CGN 的需求；IPv6 流量由边界路由器（BR）转发。BR 处理来自特定 MAP 域的流量，并且可以通过 Anycast 访问。

MAP 使用 IPv6 地址到 IPv4 地址的映射以及端口映射算法。IPv6 地址空间中的特定位被用于表示 IPv4 地址和端口。在 MAP-T 中，IP 头部被转换；在 MAP-E 中，IPv4 数据报被封装在 IPv6 头部中。与传统 NAT44 相比，MAP 所使用的 NAT44 略有不同，它允许为每个共享相同公共 IPv4 地址的 CPE 分配一个端口范围。然后，将该地址和端口组合转换为 MAP CPE 上的 IPv6 地址空间。这种 IPv4 和 IPv6 地址之间的无状态映射消除了在服务提供商网络中使用大型有状态转换器的需求。

MAP 域中的所有节点必须配置一组参数，用于实现 MAP 功能。这些参数可以手动配置或通过 DHCP 进行配置。这里有三条规则，分别是基本映射规则（BMR）、默认映射规则（DMR）和转发映射规则（FMR）。这些映射规则定义了 MAP 域的转发行为，并组成了映射规则表（MRT），它作为 BR 和 CE 的路由表。

MAP-E 将成为标准化的 RFC，而 MAP-T 将成为信息性或实验性的 RFC。还有一个草案指定了用于地址映射的 DHCPv6 选项，以便 DHCP 服务器可以提供地址映射算法所需的信息（draft-ietf-softwire-map-dhcp-07）。

NPTv6 和 NAT66

一个常见的问题是，IPv6 是否存在或将来是否会出现类似于 NAT（在这种情况下，通常指的是我们所称的 NAT44）的方法。鉴于 NAT 最初是作为 IPv4 地址耗尽问题的临时解决方案设计的，你可能会期待一个简单的答案：不会，因为 IPv6 是解决地址耗尽问题的长期解决方案。而且，IPv6 的开发者在设计时考虑的正是没有 NAT 的端到端 IPv6 网络。

然而，不幸的是，人们普遍已经习惯了 NAT，并且在某些使用场景中，一些形式的 IPv6 NAT 可能是有用的。所以我们不得不讨论 IPv6 的 NAT。让我们更仔细地看看 NPTv6。

IPv6 到 IPv6 前缀转换（NPTv6）

在 RFC 6296《IPv6 到 IPv6 网络前缀转换》的引言中，IETF 明确表示他们不推荐在 IPv6 中使用 NAT 技术。那么，为什么他们还要发布一个规范呢？其中一个原因是他们从 IPv4 NAT 的经验中吸取了教训。他们没有发布 NAT44 规范，原因也是一样：他们认为这不是一个好主意。这导致厂商开始实现他们各自版本的 NAT44，这又导致了今天我们面临的情况，即出现了多种不同版本的 NAT44。这大大增加了复杂性。因此，IETF 决定，尽管他们不想在 IPv6 网络中鼓励使用 NAT，但最好还是有一个规范，以便至少所有使用它的人都采用相同的机制。

NPTv6 是一种无状态的 IPv6 到 IPv6 网络前缀转换机制。它为网络提供了地址独立性。地址独立性意味着，如果全局前缀发生变化（例如，由于服务提供商更换），本地网络内部使用的地址无需重新编号。会话可以从两端发起（内部或外部）。你还可以连接多个 NPTv6 转换器，并在多宿主场景中使用它们。RFC 6296 第二部分描述了一些使用案例。

NPTv6 和 NAT44 之间存在一个主要区别，源于 NPTv6 并不是为了节省地址而设计的。因此，地址映射是 1:1 映射，不需要修改端口号或重写传输层头部。在这方面，NPTv6 比传统的 NAT44 更简单，但仍然存在一些问题。例如，它无法与 IPsec 身份验证头（Authentication Header）一起工作，该头部为 IP 头部提供保护。传输 IP 地址的应用程序也可能会遇到问题。部署 NPTv6 可能还需要配置拆分 DNS，因为内部主机希望将内部服务的名称解析为内部地址，而外部节点需要获取服务的外部地址。由于 NAT44 允许隐藏内部拓扑，一些人认为它是一种安全功能。NPTv6 并不隐藏你的拓扑，因为地址映射是 1:1。只有前缀被翻译，并且它必须是相同大小的前缀。所以，如果你想在内部翻译一个 /48 的地址，你也需要一个外部的 /48 地址。但你可以选择只翻译前缀的一个子集，比如从 /48 中的一个或几个 /64（例如，需要访问互联网的客户端子网）。

另一个使地址空间独立的选择是申请提供商独立（PI）地址空间。但并不是所有组织都符合资格接收 PI 分配。如果你符合资格，你必须确保你的 ISP(s) 愿意为你的前缀安装特定的路由。如果你在不同的地理区域有多个位置，这可能会特别困难或麻烦。如果你获得了 RIPE（欧洲地区）分配的 PI 前缀，无法保证你会得到美国 ISP 的路由支持。

NAT66

NAT66 相当于 NAT44。与 NPTv6 的区别在于，NAT66 是有状态的翻译器。一个接口上的 IPv6 地址被翻译为路由器或防火墙的另一个接口上的新 IPv6 地址。返回流量必须沿相同路径返回，因为设备会保持所有翻译的状态表。在 NAT66 中，内部和外部前缀不需要大小相同。是否这样做是你的选择。大多数人可能会选择处理相同大小的前缀，出于简化的考虑。市场上有来自不同供应商的实现。NAT66 与 NAT44 存在相同的问题，许多应用程序仍然需要通过各种解决方法才能正常工作。回到我们的设计建议，这意味着需要仔细评估你是否真的需要并希望这样做，只有在没有更简单的解决方案时才采取此措施。

其他翻译技术

这里我将描述一些额外的翻译机制。

主机中的碰撞（Bump-in-the-Host）

主机内翻译（BIH）是一种基于主机的 IPv4 到 IPv6 协议翻译机制，它允许通过 NAT 工作的 IPv4-only 应用程序与 IPv6-only 对等体通信。它在 RFC 6535 中定义。应用程序运行的主机可能连接到 IPv6-only 或双栈接入网络。BIH 隐藏了 IPv6，使 IPv4-only 应用程序通过本地合成 IPv4 地址认为它们正在与 IPv4 对等体通信。本文件废除了 RFC 2767（Bump-in-the-Stack）和 RFC 3338（Bump-in-the-API）。

传输中继翻译器

传输中继翻译器（TRT；参见 RFC 3142）是一种在 IPv6-only 网络中用于传输层的翻译机制。它位于 IPv6 网络中，允许 IPv6 节点和 IPv4 节点之间进行通信。每次 IPv6 客户端与 IPv4 应用程序通信时，都需要通过中继翻译器。如果是 TCP 连接，中继器会终止与客户端的连接，并在另一端与 IPv4 应用程序建立新的 TCP 连接。在内部，翻译器在这两个会话之间进行转换。如果是 UDP 连接，中继器只需翻译并转发数据包。

所有翻译技术应仅在没有其他选择时使用。本章的概述旨在展示各种机制，以便实现共存和顺利过渡。开发人员最重要的目标是提供机制，使客户能够尽快过渡到 IPv6 网络。网络越早转向 IPv6 越好，因为维护单一协议总是比维护两个协议更具成本效益。

负载均衡

如果你有 IPv4 服务器和应用程序，并且希望为 IPv6 用户提供访问，或者反过来，有两种潜在的选项可以涵盖这种情况：

  • 使用无状态 NAT64（或 NAT46）

  • 使用负载均衡器

无状态 NAT 易于实现，且不需要太多资源。负载均衡器选择是常见的且是一个很好的短期解决方案，因为负载均衡器在数据中心的前端几乎是必需的设备。不同的负载均衡器供应商提供高性能负载均衡器，支持多种机制，且可以用于大多数场景。但请确保在负载和双栈模式下测试你具体的计划场景的性能，如果需要使用双栈模式的话。

比较

现在你已经了解了可用的技术概述，我将通过列出优缺点来总结它们。这一总结应该能帮助你确定选择哪种方案以及哪些组合适合使用。

双栈

这种技术易于使用且灵活，是你最佳的选择。主机可以使用 IPv4 与 IPv4 主机通信，或者使用 IPv6 与 IPv6 主机通信。当一切都升级为 IPv6 时，IPv4 栈可以简单地禁用或移除。只要条件允许，部署双栈主机和路由器可以提供最大的灵活性，以应对仅有 IPv4 的应用、设备和网络孤岛。双栈也是其他过渡机制的基础。隧道需要双栈端点，转换器需要双栈网关。

这种技术的缺点包括以下几点：你需要运行两个独立的协议栈，因此主机需要额外的 CPU 能力和内存。所有的表格都会被保留两次：每个协议栈一个。通常，所有运行在双栈主机上的应用程序必须能够确定该主机是在与 IPv4 还是 IPv6 对等体通信。在双栈网络中，你需要为每个版本的 IP 配置路由协议。如果你使用双栈技术，请确保你有防火墙来保护不仅是你的 IPv4 网络，还有你的 IPv6 网络，并且记住你需要为每个协议制定独立的安全策略和防火墙规则。

它也让故障排除变得更加复杂。例如，某个与 IPv6 相关的问题的应用程序是否尝试通过 IPv4 而非 IPv6 连接并失败？你需要如何调整你的故障排除方法来测试并找出原因？你的帮助台和 IT 支持人员还需要了解如何使用特定工具来处理 IPv4 和 IPv6，以便能够区分这两种协议。所以从运维和支持的角度来看，运行双栈网络可能会花费更多。这也是许多企业考虑尽快迁移到仅支持 IPv6 的基础设施的主要原因之一。

隧道技术

隧道技术允许你按照自己的方式迁移到 IPv6。没有必须遵循的特定升级顺序。你甚至可以升级公司网络中的单一主机或子网，通过隧道连接分离的 IPv6 云。你不需要你的 ISP 支持 IPv6 来访问远程的 IPv6 网络，因为你可以通过他们的 IPv4 基础设施建立隧道。而且你不需要首先升级你的骨干网络。只要你的骨干网络是 IPv4 的，你就可以通过隧道将 IPv6 数据包传输到骨干网络上。如果你有 MPLS 基础设施，只要不打算将骨干路由器升级为原生支持 IPv6，你就有最好的基础来使用它进行 IPv6 数据包的隧道传输。

缺点来自过去使用的其他隧道技术。路由器承受额外负担。一般来说，推荐使用无状态隧道而不是有状态隧道。隧道的入口和出口点需要时间和 CPU 资源来进行数据包的封装和解封装。它们也代表着单点故障。故障排除变得更加复杂，因为可能会遇到跳数或 MTU 大小问题，以及碎片化问题。由于封装，封装流量的管理（例如，每协议的计费）也变得更加困难。隧道还提供了安全攻击的点。有关安全问题的更多信息，请参见第六章。

注意

RFC 7059，《IPv6-over-IPv4 隧道机制比较》，提供了当前可用隧道机制的简要概述，包括选择合适隧道机制时需要考虑的因素。

翻译

翻译只应在没有其他技术可用时使用，并应视为临时解决方案，直到可以实施其他技术之一。其缺点是 IPv4 与 IPv6 之间的翻译不支持 IPv6 的高级特性，如扩展头和端到端安全性。它对设计拓扑结构提出了限制，因为回复必须通过相同的 NAT 路由器返回。NAT 路由器是单点故障，并且不能使用灵活的路由机制。所有在数据包有效载荷中包含 IP 地址的应用都会遇到问题。这种方法的优点是，它允许 IPv6 主机直接与 IPv4 主机通信，反之亦然。在某些情况下，NAT 可能有助于在早期阶段部署仅 IPv6 的网络。需要考虑利弊，但这可能是一个可行的解决方案。

现在你已经掌握了 IPv6 的基础知识和集成选项，是时候将它们付诸实践，开始规划你的过渡过程。请参考第九章，了解如何将所有要素结合起来并理解规划过程。该章节还包含一些有关 IPv6 地址概念的指导原则。

注意

你还可以参考我的伴侣书籍，《IPv6 规划》（O'Reilly），以获取有关规划和设计考虑因素的更多细节。

参考文献

下面是本章中提到的最重要的 RFC 和草案列表。有时我还会包含一些额外的相关 RFC，供你个人进一步学习。

RFCs

  • RFC 2185，《IPv6 过渡的路由方面》，1997 年

  • RFC 2473，《IPv6 中通用数据包隧道规范》，1998 年

  • RFC 2529，《在没有显式隧道的 IPv4 域上传输 IPv6》，1999 年

  • RFC 2553，《IPv6 的基本套接字接口扩展》，1999 年 3 月

  • RFC 2663，《IP 网络地址转换器（NAT）术语和注意事项》，1999 年

  • RFC 2784，《通用路由封装（GRE）》，2000 年

  • RFC 3022, “传统 IP 网络地址转换器（传统 NAT）”，2001

  • RFC 3053, “IPv6 隧道代理”，2001

  • RFC 3056, “通过 IPv4 云连接 IPv6 域”，2001

  • RFC 3068, “用于 6to4 中继路由器的 Anycast 前缀”，2001

  • RFC 3107, “在 BGP-4 中携带标签信息”，2001

  • RFC 3142, “IPv6 到 IPv4 传输中继翻译器”，2001

  • RFC 3162, “RADIUS 与 IPv6”，2001

  • RFC 3484, “IPv6（互联网协议版本 6）默认地址选择”，2003

  • RFC 3489, “STUN—用户数据报协议（UDP）通过网络地址转换（NAT）穿越的简单方法”，2003

  • RFC 3493, “IPv6 基本套接字接口扩展”，2003

  • RFC 3542, “IPv6 的高级套接字应用程序接口（API）”，2003

  • RFC 3582, “IPv6 站点多宿架构的目标”，2003

  • RFC 3715, “IPsec-网络地址转换（NAT）兼容性要求”，2004

  • RFC 3901, “DNS IPv6 传输操作指南”，2004

  • RFC 3964, “6to4 安全性考虑”，2004

  • RFC 3971, “安全邻居发现”，2005

  • RFC 3972, “密码生成地址（CGA）”，2005

  • RFC 4007, “IPv6 范围地址架构”，2005

  • RFC 4029, “将 IPv6 引入 ISP 网络的场景与分析”，2005

  • RFC 4038, “IPv6 过渡的应用方面”，2005

  • RFC 4057, “IPv6 企业网络场景”，2005

  • RFC 4159, “‘ip6.int’的弃用”，2005

  • RFC 4177, “IPv6 多宿的架构方法”，2005

  • RFC 4191, “默认路由器偏好和更具体的路由”，2005

  • RFC 4192, “无需标志日的 IPv6 网络重新编号程序”，2005

  • RFC 4213, “IPv6 主机和路由器的基本过渡机制”，2005

  • RFC 4215, “第三代合作伙伴计划（3GPP）网络中 IPv6 过渡的分析”，2005

  • RFC 4218, “与 IPv6 多宿解决方案相关的威胁”，2005

  • RFC 4219, “IPv6 中的多宿（MULTI6）开发人员应该考虑的事项”，2005

  • RFC 4241, “IPv6/IPv4 双栈互联网接入服务模型”，2005

  • RFC 4282, “网络接入标识符”，2005

  • RFC 4380, “Teredo：通过网络地址转换（NAT）使用 UDP 隧道 IPv6”，2006

  • RFC 4554, “企业网络中 IPv4-IPv6 共存的 VLAN 使用”，2006

  • RFC 4659, “IPv6 VPN 的 BGP-MPLS IP 虚拟专用网络（VPN）扩展”，2006

  • RFC 4779, “宽带接入网络中的 ISP IPv6 部署场景”，2007

  • RFC 4787, “单播 UDP 的网络地址转换（NAT）行为要求”，2007

  • RFC 4798, “通过 IPv4 MPLS 使用 IPv6 提供者边缘路由器（6PE）连接 IPv6 域”，2007

  • RFC 4852, “IPv6 企业网络分析—IP 层 3 重点”，2007

  • RFC 4966, “将网络地址转换器—协议转换器（NAT-PT）移至历史状态的原因”，2007

  • RFC 5157, “IPv6 对网络扫描的影响”，2008

  • RFC 5181, “802.16 网络中的 IPv6 部署场景”，2008

  • RFC 5214, “站点内自动隧道地址协议（ISATAP）”，2008

  • RFC 5220, “多前缀环境中默认地址选择的问题陈述，” 2008

  • RFC 5375, “IPv6 单播地址分配注意事项，” 2008

  • RFC 5569, “IPv6 在 IPv4 基础设施上的快速部署（6rd），” 2010

  • RFC 5571, “带 L2 隧道协议版本 2（L2TPv2）的软线中心和辐射部署框架，” 2009

  • RFC 5572, “带隧道设置协议的 IPv6 隧道代理，” 2010

  • RFC 5902, “IAB 对 IPv6 网络地址转换的看法，” 2010

  • RFC 5969, “IPv6 在 IPv4 基础设施上的快速部署（6rd）—协议规范，” 2010

  • RFC 5991, “Teredo 安全更新，” 2010

  • RFC 6036, “IPv6 部署的服务提供商新兴场景，” 2010

  • RFC 6052, “IPv6 对 IPv4/IPv6 转换器的地址分配，” 2010

  • RFC 6081, “Teredo 扩展，” 2011

  • RFC 6144, “IPv4/IPv6 转换框架，” 2011

  • RFC 6145, “无状态 IP/ICMP 转换，” 2011

  • RFC 6146, “有状态 NAT64：从 IPv6 客户端到 IPv4 服务器的网络地址与协议转换，” 2011

  • RFC 6147, “DNS64：从 IPv6 客户端到 IPv4 服务器的网络地址转换的 DNS 扩展，” 2011

  • RFC 6164, “在路由器之间的链路上使用 127 位 IPv6 前缀，” 2011

  • RFC 6177, “IPv6 地址分配给最终站点，” 2011

  • RFC 6180, “在 IPv6 部署过程中使用 IPv6 过渡机制的指南，” 2011

  • RFC 6250, “IP 模型的演进，” 2011

  • RFC 6269, “IP 地址共享问题，” 2011

  • RFC 6296, “IPv6 到 IPv6 网络前缀转换，” 2011

  • RFC 6302, “面向互联网的服务器日志记录建议，” 2011

  • RFC 6333, “IPv4 耗尽后的双栈 Lite 宽带部署，” 2011

  • RFC 6334, “IPv6 的动态主机配置协议（DHCPv6）选项，用于双栈 Lite，” 2011

  • RFC 6343, “6to4 部署的建议指南，” 2011

  • RFC 6434, “IPv6 节点要求，” 2011

  • RFC 6459, “IPv6 在 3GPP 演进分组系统（EPS）中的应用，” 2012

  • RFC 6535, “使用‘Bump-in-the-Host’（BIH）的双栈主机，” 2012

  • RFC 6540, “所有支持 IP 的节点必须支持 IPv6，” 2012

  • RFC 6586, “来自 IPv6-only 网络的经验，” 2012

  • RFC 6619, “具有每接口绑定的地址转换器的可扩展操作，” 2012

  • RFC 6791, “ICMPv6 数据包的无状态源地址映射，” 2012

  • RFC 6830, “定位符/标识符分离协议（LISP），” 2013

  • RFC 6831, “定位符/标识符分离协议（LISP）在多播环境中的应用，” 2013

  • RFC 6832, “定位符/标识符分离协议（LISP）与非 LISP 站点之间的互联互通，” 2013

  • RFC 6833, “定位符/标识符分离协议（LISP）映射服务器接口，” 2013

  • RFC 6834, “定位符/标识符分离协议（LISP）映射版本控制，” 2013

  • RFC 6835, “定位符/标识符分离协议互联网探测器（LIG），” 2013

  • RFC 6836, “定位符/标识符分离协议替代逻辑拓扑（LISP+ALT），” 2013

  • RFC 6866, “企业网络中带静态地址的 IPv6 主机重编号问题陈述，” 2013

  • RFC 6877, “464XLAT：有状态与无状态转换的结合，” 2013

  • RFC 6879, “IPv6 企业网络重新编号场景、考虑事项和方法，”2013 年

  • RFC 6883, “面向互联网内容提供商和应用服务提供商的 IPv6 指南，”2013 年

  • RFC 6886, “NAT 端口映射协议（NAT-PMP），”2013 年

  • RFC 6888, “运营商级 NAT（CGN）的常见要求，”2013 年

  • RFC 6889, “有状态 64 翻译分析，”2013 年

  • RFC 6908, “双栈 Lite 部署考虑，”2013 年

  • RFC 6911, “IPv6 访问网络的 RADIUS 属性，”2013 年

  • RFC 6921, “超光速（FTL）通信的设计考虑，”2013 年 4 月 1 日

  • RFC 7021, “评估运营商级 NAT 对网络应用程序的影响，”2013 年

  • RFC 7040, “IPv4-over-IPv6 公共接入网络，”2013 年

  • RFC 7050, “用于 IPv6 地址合成的 IPv6 前缀发现，”2013 年

  • RFC 7051, “主机学习 NAT64 前缀的解决方案提案分析，”2013 年

  • RFC 7059, “IPv6-over-IPv4 隧道机制比较，”2013 年

  • RFC 7084, “IPv6 客户端边缘路由器的基本要求，”2013 年

  • RFC 7157, “无网络地址转换的 IPv6 多宿主（Multihoming），”2014 年

  • RFC 7225, “通过端口控制协议（PCP）发现 NAT64 IPv6 前缀，”2014 年

草案

草案可以在www.ietf.org/ID.html找到。要查找草案的最新版本，请参考datatracker.ietf.org/public/pidtracker.cgi。您可以输入草案名称而不带版本号，最新版本将会显示。如果草案未显示，可能已被删除。如果已发布为 RFC，将显示 RFC 编号。tools.ietf.org/wg也是一个非常有用的网站。有关标准化过程、RFC 和草案的更多信息，请参见附录 A。

这里列出了我在本章中参考的草案，以及与本章主题相关的有趣草案：

“地址和端口的映射与封装（MAP）”

draft-ietf-softwire-map-10

“使用翻译的地址和端口映射（MAP-T）”

draft-ietf-softwire-map-t-05

“用于配置软线地址和端口映射客户端的 DHCPv6 选项”

draft-ietf-softwire-map-dhcp-07

“轻量级 4over6：对 DS-Lite 架构的扩展”

draft-ietf-softwire-lw4over6-08

“通过 IPv6 进行 IPv4 残留部署 - 一种无状态解决方案（4rd）”

draft-ietf-softwire-4rd-08

“NAT64 部署选项和经验”

draft-ietf-v6ops-nat64-experience-10

第八章：移动 IPv6

过去，我们习惯于在家中或办公室打电话。公共电话亭使我们能够在外出时打电话。今天，使用手机已经变得非常普遍，我们几乎可以在任何地方、任何生活场景下拨打电话。笔记本电脑、无线网络和便携设备的使用不断增加，我们可以想象，无论身处何地，都能使用智能设备。如果这些设备要使用 IP 作为传输协议，我们需要移动 IP 来使其工作。我们希望设备在移动时保持连接，并能在更换接入网络的地点时不中断连接，就像今天我们习惯于在手机上从一个基站漫游到另一个基站一样。例如，假设你有一台配备 802.11（无线）接口和 UMTS（通用移动通信系统）接口的平板电脑。在酒店房间里，你通过无线接口连接到网络；当你离开房间走到街上时，你会自动切换到 UMTS，而不会丢失连接。所有的应用程序，例如正在运行的 Skype 会话或语音通话，都不会中断。是不是很酷？这一节关于移动 IP 的内容探讨了实现这一目标所需的机制，并展示了 IPv6 如何为这一挑战做好准备。

无论是 IPv4 还是 IPv6，前缀（子网地址）都会根据我们所连接的网络发生变化。当移动节点改变其接入网络的方式时，它需要获取一个新的 IP 地址，这会中断其 TCP 或 UDP 连接。RFC 5944《IPv4 的 IP 移动性支持》描述了 IPv4 的移动 IP 概念和规范。然而，使用 IPv4 的移动 IP 存在一些局限性，使其不适用于全球网络中的需求。一个原因是地址空间的有限性。如果我们仅仅想象智能手机需要一个 IP 地址，那么全球所需的地址数量将远远超过可用的 IPv4 地址空间。另一个原因是 IPv6 及其扩展头的使用为移动世界中的路由优化提供了可能，这在讨论大量设备的移动性时尤为重要。IPv6 使用邻居发现（而非像 IPv4 那样使用 ARP）使其更加独立于链路层。移动 IPv6 借鉴了移动 IPv4 的经验，并利用了 IPv6 的先进特性。

本章描述了移动 IPv6 如何工作以及它如何为未来的移动服务提供基础。首先，我将解释本章中将使用的最重要术语，然后提供功能概述，之后深入探讨协议的技术细节：新的头部、消息、选项、过程和通信。所以，深呼吸一下，继续阅读。

概述

移动 IPv6 是一种协议，允许移动节点在不同网络之间切换而不丢失连接。它在 RFC 6275 中有所规定。

大多数互联网流量使用 TCP 连接。TCP 连接由通信双方端点的 IP 地址和端口号的组合来定义。如果这四个数字中的任何一个发生变化，通信就会中断并需要重新建立。如果一个移动节点连接到不同的网络，它需要一个新的 IP 地址。移动 IP 解决了在不更改 IP 地址的情况下将节点移动到不同连接点的挑战，通过为移动节点的接口分配一个新的附加 IP 地址。此时，移动节点仍然知道它的主地址，这个地址是静态的并且不会改变，因此用于标识 TCP 连接。新的 IP 地址被称为Care-of 地址。它根据节点当前附着的网络而变化。因此，这在同质网络中有效（如果节点从一个以太网段移动到另一个以太网段），也适用于异质网络（如果节点从一个以太网段移动到无线局域网或 UMTS）。

在无线网络中，我们熟悉切换，即设备从一个接入点移动到另一个接入点的事件。这是在链路层的切换。移动 IPv6 解决了网络层的切换问题，并在设备更改其临时 IP 地址时保持与应用程序和服务的连接。

移动 IPv6 术语

以下是本章中使用的一些术语的定义。

主地址

分配给移动节点的全局单播地址。它作为该节点的永久地址，并位于移动节点的主链路内。常规路由机制将数据包传送到移动节点的主地址。

主子网前缀

对应移动节点主地址的 IP 子网前缀。

主链路

定义移动节点主子网前缀的链路。

移动节点

一种可以在不同链路间切换附着点的节点，同时仍可以通过其主地址进行访问。

通信节点

与移动节点进行通信的对等节点。通信节点可以是移动的也可以是静态的。

外部子网前缀

除移动节点主子网前缀外的任何 IP 子网前缀。

外部链路

除移动节点主链路以外的任何链路。

Care-of 地址

移动节点在外部网络（远离主网络）中的全局单播地址。Care-of 地址的子网前缀为外部子网前缀。一个移动节点可能有多个 Care-of 地址。注册到其主代理的 Care-of 地址是主要 Care-of 地址。

主代理

移动节点家庭链路上的一台路由器，移动节点已将其当前的 Care-of 地址注册到该路由器。当移动节点不在家时，家庭代理会拦截发往该移动节点家庭地址的数据包，封装它们（IPv6 封装），并通过隧道传送到移动节点的注册 Care-of 地址。

绑定

移动节点的家庭地址与该移动节点的 Care-of 地址之间的关联，以及该关联的剩余生命周期。

注册

移动节点将绑定更新发送给其家庭代理或通信节点，从而使得该移动节点的绑定被注册。与通信节点的注册称为通信节点注册（Correspondent Registration）。

绑定授权

需要通过通信节点进行注册授权，以便接收方确保发送方有权指定新的绑定。

返回可达性过程

通过加密令牌交换授权注册的过程。

密钥生成令牌

由通信节点在返回可达性过程（Return Routability Procedure）中提供的一个编号，用于使移动节点计算必要的绑定管理密钥，以授权绑定更新（Binding Update）。

随机数

在创建与返回可达性过程相关的密钥生成令牌时，通信节点内部使用的随机数。这些随机数并不特定于某个移动节点，并且保密存储在通信节点内。

随机数索引

用于指示在创建密钥生成令牌（keygen token）值时已使用哪些随机数，而不暴露这些随机数本身。

移动 IPv6 的工作原理

图 8-1 展示了移动 IPv6 的组成部分及其如何相互作用。

移动 IPv6 概述图 8-1. 移动 IPv6 概述

家庭地址是一个位于移动节点（MN）的家庭链路前缀内的 IPv6 地址。只要移动节点处于家庭网络中，它通过常规的 IP 路由机制接收数据包，表现得就像任何其他普通 IP 主机一样。当移动节点处于外部网络（外链路）时，它会有一个额外的暂时地址（Care-of 地址）。它通过常规 IPv6 机制，如 SLAAC（无状态地址自动配置）或 DHCPv6，在连接到新的链路时获取 Care-of 地址。

家庭地址与 Care-of 地址之间的关联称为绑定。当移动节点离家时，它会将自己的 Care-of 地址注册到家庭链路上的一台路由器，即其家庭代理（HA）。为了注册 Care-of 地址，移动节点向家庭代理发送绑定更新消息。家庭代理回应一个绑定确认。与移动节点通信的每个节点称为通信节点（CN）。移动节点也可以直接向通信节点发送注册消息（称为通信节点注册）。通信节点也可以是一个移动节点。

有两种通信方式供通信节点和移动节点使用：

双向隧道

来自通信节点的数据包被发送到主机代理，主机代理将它们封装成 IPv6 格式并发送到移动节点的 Care-of 地址。来自移动节点的数据包通过反向隧道发送到主机代理，主机代理通过常规路由机制将其转发到通信节点。这种模式不要求通信节点支持任何移动 IPv6，并且在不需要通信节点注册的情况下也能工作。

路由优化

使用路由优化后，移动节点与通信节点之间可以直接通信，而无需经过主机代理。这是移动 IPv6 相对于移动 IPv4 的主要优势之一，因为在移动 IPv4 中，路由优化是不可能的。路由优化要求移动节点将其 Care-of 地址注册到通信节点（称为通信节点注册），并且该绑定通过返回可达性过程（在本章后面“返回可达性过程”一节中讨论）获得授权。通信节点在直接向移动节点发送数据包时使用特殊的路由头（类型 2）。移动节点在向通信节点发送数据包时使用主机地址选项（为移动 IPv6 定义）。整个过程将在本章稍后部分进行更详细的描述。

路由优化的优点是，通信节点与移动节点之间可以使用最短的路径。数据包无需经过主机代理。这不仅确保了更短的通信路径，还减少了主机代理和主机链接的负载。当我们讨论大量移动节点不断移动时，特别是在 VoIP（语音 IP）场景中，或使用智能手机时，这一点尤为重要。

移动 IPv6 还支持多个主机代理的选项，移动节点可以通过动态主机代理地址发现（Dynamic Home Agent Address Discovery）得知其主机链接的重新配置或主机代理 IP 地址的变化。如果其主机链接的前缀发生变化，移动节点则使用移动前缀发现机制来获取新前缀。

以下各节将更详细地描述协议和新的消息、选项以及标志。之后，我将深入介绍刚才概述的通信流程。有些人喜欢这样学习；而另一些人则喜欢先了解过程和流程，然后再学习技术细节。请按照最适合您偏好的顺序阅读各节内容。

移动 IPv6 协议

本节描述了移动 IPv6 的组件、消息和选项。

移动头和移动消息

移动性头部（MH）已为移动 IPv6 定义。它是一个扩展头部，供移动节点、对应节点和家庭代理使用。它用于所有与建立和维护绑定相关的消息。

移动性头部由前一个头部中的下一个头部值 135 指定，其格式如图 8-2 所示。

移动性头部格式图 8-2. 移动性头部格式

负载协议字段对应于下一个头部字段，并标识下一个头部。因此，它可以包含与下一个头部字段相同的值。当前规范将此字段的值设置为 59（十进制），表示“无下一个头部”。它旨在用于未来的扩展。头部长度字段包含移动性头部的长度，单位为 8 字节。前 8 字节不计算在内。移动性头部的长度始终是 8 字节的倍数。校验和字段包含移动性头部的校验和。它是基于伪头部计算的，并遵循 RFC 2460 中定义的规则。伪头部中使用的地址是 IPv6 头部中的源地址和目标地址。如果移动性消息包含家庭地址目标选项，则使用家庭地址来计算校验和。MH 类型字段标识移动性消息的类型。已定义的消息列在表 8-1 中。数据字段是可变的，取决于消息类型。

表 8-1 是移动性消息的概述。

表 8-1. 移动性消息类型

值 消息类型 描述 RFC
0 绑定刷新请求 由 CN 发送，请求 MN 更新其绑定。 RFC 6275
1 家庭测试初始化 由 MN 发送以启动返回可达性过程并向 CN 请求家庭密钥生成令牌。通过隧道经过 HA 发送给 CN。 RFC 6275
2 外部地址测试初始化 由 MN 发送以启动返回可达性过程并向 CN 请求密钥生成令牌。直接发送给 CN。 RFC 6275
3 家庭测试消息 响应家庭测试初始化消息（类型 1）。由 CN 发送给 MN。包含一个 cookie 和一个家庭密钥生成令牌，用于返回可达性过程中的授权。通过 HA 隧道发送。 RFC 6275
4 外部地址测试消息 响应外部地址测试初始化消息（类型 2）。由 CN 发送给 MN。包含 cookie 和一个外部地址密钥生成令牌，用于返回可达性过程中的授权。直接发送给 MN。 RFC 6275
5 绑定更新 由 MN 发送以通知其外部地址的变化。此消息将在本章稍后详细解释。 RFC 6275
6 绑定确认 作为确认接收到绑定更新消息的响应发送。该消息将在本章后面详细解释。 RFC 6275
7 绑定错误 由 CN 发送，用于指示与移动性相关的错误，例如在没有现有绑定的情况下，尝试使用 Home Address Destination 选项。状态字段可以具有以下值：1 = Home Address Destination 选项的未知绑定；2 = 未识别的 MH 类型值 RFC 6275
8 快速绑定更新 与绑定更新消息相同，仅具有稍微不同的处理规则。 RFC 5568
9 快速绑定确认 作为确认接收到快速绑定更新消息的响应发送。 RFC 5568
10 快速邻居广告 已弃用。 RFC 5568
11 实验性移动头 为测试新消息类型而定义，不会与标准化的值发生冲突。 RFC 5096
12 主机代理切换 从 HA 发送到 MN，强制 MN 配置新的 HA。 RFC 5142
13 心跳 由 MAC 和 LMA 发送，以验证可达性的状态（代理移动 IPv6）。 RFC 5847
14 切换初始化 在接入路由器之间发送，用于初始化移动节点的切换过程。 RFC 5568
15 切换确认 由接入路由器发送，用于确认接收到切换初始化消息。 RFC 5568
16 绑定撤销 由移动节点发送以终止绑定：1 = 绑定撤销指示；2 = 绑定撤销确认 RFC 5846
17 本地路由初始化 由 LMA 或 MAG 发送，用于初始化本地路由（代理移动 IPv6）。 RFC 6705
18 本地路由确认 由 LMA 或 MAG 作为对本地路由初始化的响应发送。 RFC 6705

为帮助你理解绑定，下一节将更详细地探讨绑定更新和绑定确认消息。

注

你可以在www.iana.org/assignments/mobility-parameters找到所有消息和选项类型以及状态代码。

绑定更新消息

绑定更新消息用于移动节点通知主机代理或对应节点一个新的 Care-of 地址。该消息还用于扩展现有绑定的生命周期。

绑定更新消息是 MH 类型 5，格式如图 8-3 所示。

绑定更新消息的格式图 8-3. 绑定更新消息的格式

序列号由接收节点用于对 Binding Updates 进行排序。发送节点使用它来验证接收到的 Binding Acknowledgments 是否与其 Binding Updates 对应。如果移动节点期望对其 Binding Update 的响应，Acknowledge 位（A-Bit）会被设置。Home Registration 位（H-Bit）由移动节点设置，表示请求接收方充当该节点的家庭代理。只有当接收方位于移动节点的家庭链路上时，这才是可能的。Link-Local 地址兼容性位（L-Bit）如果家庭地址具有与移动节点的链路-local 地址相同的接口标识符，则设置该位。密钥管理移动能力位（K-Bit）仅在发送到家庭代理的 Binding Updates 中有效。如果 IPsec 安全关联应在移动节点移动到另一个网络后继续有效，则 K-Bit 被设置。如果不可能，则 K-Bit 被设置为 0。通信节点忽略 K-Bit。生命周期字段表示 Care-of 地址的绑定有效期（以四秒为单位）。如果生命周期设置为 0，则接收方必须删除其 Binding 缓存中的条目。在这种情况下，移动节点必须处于其家庭链路上，并且 Care-of 地址与家庭地址相同。

在图 8-3 中显示的 M-Bit 被额外创建用来识别发送到本地家庭代理的本地 Binding Update，该代理称为移动锚点（MAP）。这个新节点用于改善移动 IPv6 切换性能，以便在同一地理区域内获得移动节点与通信节点之间的高效路由，并实现位置隐私。该机制在 RFC 4140《分层移动 IPv6》中定义，并在本章末尾有更详细的解释。当 M-Bit 被设置时，H-Bit 不能被设置，反之亦然。

Binding Update 可以包含以下选项：

  • Binding 授权数据选项（此选项在发送到通信节点的 Binding Updates 中是必需的）

  • Nonce 索引选项

  • 替代的 Care-of 地址选项

Binding Acknowledgment

Binding Acknowledgment 用于确认接收到 Binding Update。如果 Binding Update 中的 A-Bit 被设置，则必须发送 Binding Acknowledgment。如果 A-Bit 没有被设置（这意味着 Binding Update 的发送方不要求确认），则只有在 Binding Update 出现问题时才会发送 Binding Acknowledgment。如果接收方接受 Binding Update 并且 A-Bit 没有设置，则不发送确认。

Binding Acknowledgment 属于 MH 类型 6，其格式如图 8-4 所示。

Binding Acknowledgment 格式图 8-4. Binding Acknowledgment 格式

状态字段表示绑定更新的状态。表 8-2 显示了状态值。值范围为 0 到 127 表示绑定更新已被接受。值大于 128 表示绑定更新未被接受。

表 8-2. 绑定确认中的状态值

值 描述
0 绑定更新已接受
1 已接受，但需要前缀发现
128 原因未指定
129 行政禁止
130 资源不足
131 不支持家庭注册
132 非家庭子网
133 不是该移动节点的家庭代理
134 地址重复检测失败
135 序列号超出窗口
136 已过期的家庭随机数索引
137 已过期的 Care-of 随机数索引
138 已过期的随机数
139 禁止注册类型更改

这些是 RFC 6275 中定义的状态值。还有更多来自其他规范的状态值，如 NEMO 或代理移动 IPv6（在 NEMO 和代理移动 IPv6 部分中讨论）。

注意

查找完整的状态码列表，访问 www.iana.org/assignments/mobility-parameters。

K 位是密钥管理移动性能力位（请参阅之前在绑定更新消息部分中的描述）。该位仅在移动节点和家庭代理之间的绑定中重要。通信节点会忽略此位。绑定确认中的序列号是从绑定更新中的序列号字段复制的。它用于移动节点将此绑定确认与未完成的绑定更新进行匹配。生命周期以 4 秒为单位，表示 Care-of 地址绑定的有效时间。在此期间，家庭代理或通信节点会将该绑定条目保存在其绑定缓存中。在表示绑定未被接受的绑定确认中（值为 128 或更高），不会指定生命周期。

一个绑定确认可以包含以下选项：

  • 绑定授权数据选项（此选项在由通信节点发送的绑定确认中是强制性的）

  • 绑定刷新建议选项

绑定撤销

在某些情况下，可能需要通知 MN 其无法再接收主机地址的移动 IPv6 服务。为此，RFC 5846 定义了绑定撤销机制。它使用一个新的移动性头（类型 16；参见 表 8-1）。该撤销机制可用于移动 IPv6 以及代理移动 IPv6（RFC 5213；在 代理移动 IPv6 部分中描述）。

在本规范中定义了以下新术语：

发起方

启动绑定撤销过程的移动性节点。它向其对等节点（例如，主机代理、本地移动锚点或移动接入网关）发送绑定撤销消息。

响应方

接收绑定撤销消息并响应绑定撤销确认的移动性节点（例如，移动节点、移动接入网关或本地移动锚点）。

为了撤销绑定，HA 向 MN 发送 绑定撤销指示（BRI）消息。为了指示绑定，HA 将主机地址包含在消息中（在类型 2 路由头中）。在双栈移动 IP（DSMIPv6）的情况下，也可以包括 IPv4 主机地址选项。如果 MN 注册了多个 Care-of 地址，HA 会在撤销消息中包含绑定标识符（BID）选项，以标识哪个绑定被撤销。当 MN 收到包含其主机地址的类型 2 路由头的绑定撤销指示消息时，它会响应绑定撤销确认消息。

类似地，在代理移动 IPv6 的情况下，本地移动锚点向移动接入网关发送撤销消息。在这种情况下，本地移动锚点包括移动节点主机网络前缀选项和移动节点标识符选项。

移动性选项

移动性消息可以包含零个、一个或多个选项。这些选项被包含在移动性头的可变数据字段中。该架构非常灵活，因为选项只有在需要时才插入，并且未来可以轻松定义额外的选项。

选项的存在通过移动性头中的头部长度字段指示。它们采用已知的 TLV 格式（类型 1 字节，长度 1 字节，值可变）。

表 8-3 包含当前定义的移动性消息选项概览。

表 8-3. 移动性选项

值长度 名称 描述
类型 0 Pad1 用于插入一个填充字节。此选项具有特殊格式；它仅包含类型字段，没有长度和数据字段。
类型 1 PadN 用于插入两个或更多填充字节。
类型 2 长度 2 绑定刷新建议 指示 MN 应该发送新的主机注册到 HA 的剩余时间。仅在 HA 对主机注册响应时发送的绑定确认中有效。该间隔必须小于绑定确认中的 Lifetime 值。时间单位为四秒。
类型 3 长度 16 备用 Care-of 地址 包含用于作为绑定的 Care-of 地址的地址，而不是使用数据包的源地址作为 Care-of 地址。仅在绑定更新消息中有效。
类型 4 长度 4 随机数索引 除了类型和长度字段外，还包含两个附加字段。Home Nonce Index 字段告诉 CN 在生成 Home Keygen Token 时使用哪个随机数值。Care-of Nonce 字段指示用于生成 Care-of Keygen Token 的值。仅在发送到 CN 的绑定更新消息中有效，并且只有与绑定授权数据选项一起出现时有效。
类型 5 长度 可变 绑定授权数据 包含一个加密值，用于确定该消息来自正确的授权机构。计算此值的规则取决于所使用的授权程序。必须始终是 MH 中的最后一个选项。仅在绑定更新和绑定确认中有效。用于返回可达性过程。在这种情况下，Authenticator 值的计算基于 MN 的 Care-of 地址、CN 的 IPv6 地址和来自 MH 的数据。
类型 201 长度 16 主机地址 包含 MN 的主机地址。当 MN 离家时，发送给接收方以指示其主机地址。通过目标选项头传输。必须插入在路由头之后，分片头、AH 或 ESP 头（如果存在）之前。

除了绑定授权数据选项外，这些选项可以以任意顺序出现。主机地址选项是一个例外，因为它通过目标选项头传输，而不是通过移动性头（MH）。

注意

再次强调，可以在 bit.ly/1nabH2o 查阅包括其他规范中选项的完整移动选项列表。

RFC 4283，“Mobile IPv6（MIPv6）的移动节点标识符选项”扩展了原始规范，允许 MIPv6 节点（HA、CN、MN）使用除 IP 地址以外的标识符。它定义了一个具有子类型编号的选项，用于指定标识符类型。标识符类型可以是网络接入标识符（NAI；见 RFC 4282）、国际移动台标识符（IMSI）或特定应用/部署的不可见标识符。将来将指定更多标识符类型。

路由头类型 2

移动 IPv6 定义了一个新的路由头。这个扩展头允许在不通过家庭代理路由的情况下，移动节点的临时地址与对应节点之间的数据交换。换句话说，当在成功执行返回可路由性过程后使用路由优化进行通信时，就会使用此扩展头。

RFC 6275 定义了类型 2 路由头。它允许对防火墙中的移动 IPv6 数据包配置特定规则，除此之外还有其他功能。

当一个对应节点使用路由优化向移动节点发送 IPv6 数据报时，IPv6 头部中的目标地址字段包含了移动节点的临时地址。插入的路由头类型 2 包含了移动节点的家庭地址。路由头类型 2 只能包含一个单播地址。处理这些路由头的 IPv6 节点必须验证其中包含的 IPv6 地址是否与移动节点的家庭地址相对应。

路由头类型 2 的格式见第三章（图 3-6 和 3-7）。头部扩展长度字段的值为 2；此头部没有可变长度，因为它仅包含一个地址。在路由类型字段中，值为 2，并且“剩余段数”字段设置为 1，表示只有一个地址。家庭地址字段携带了移动节点的家庭地址。该路由头类型 2 的使用和处理方式将在本章后续部分描述。

ICMPv6 与移动 IPv6

本节描述了两种新的 ICMPv6 消息对以及为支持移动 IPv6 所做的一些邻居发现（ND）修改。

家庭代理地址发现

移动节点使用家庭代理地址发现机制来确定其家庭链路上家庭代理的地址。为此，移动节点使用两种新的 ICMPv6 消息对和家庭代理列表，后者是由每个家庭代理维护的列表。

ICMPv6 家庭代理地址发现消息

这一消息对包括家庭代理地址发现请求和回复消息。顾名思义，移动节点使用这些消息动态查找其家庭链路上的家庭代理。通常，移动节点会静态配置一个家庭代理地址。如果家庭代理地址发生重新编号或代理发生故障并被具有不同 IP 地址的新家庭代理替代，则动态发现家庭代理地址可能是一种有用的机制。

移动节点将发现消息发送到其家庭链路上的家庭代理任播地址（任播 ID 十进制 126，十六进制0x7E；见第二章）。IPv6 头部中的源地址字段携带了移动节点的临时地址。

配置为家庭代理任播地址的家庭链路上的家庭代理通过家庭代理地址发现回复消息进行响应。

发现消息的类型值为 144；回复消息的类型值为 145。代码字段始终设置为 0。标识符字段由移动节点插入，并由家庭代理在回复中复制。这可以用来识别对应的消息。回复携带一个家庭地址字段，该字段可以包含一个或多个家庭代理地址。这个地址或地址列表是根据家庭代理列表生成的（如下一节所述）。

注意

有关 ICMPv6 消息头字段的详细描述，请参考第四章。

家庭代理列表

每个家庭代理需要维护一个家庭代理列表。在该列表中，必须列出与同一链路连接并提供家庭代理服务的每个路由器。路由器通过在路由器通告中设置 H 位，向外宣告自己作为一个家庭代理。每个路由器为其作为家庭代理的每个链路维护一个家庭代理列表。该列表通过路由器通告进行更新，包含以下信息：

  • 链路上家庭代理的链路本地地址。该地址从 IPv6 头部中设置了 H 位（家庭代理位）的路由器通告的源地址字段中学习得到。

  • 一个或多个这些家庭代理的全球 IPv6 单播地址。这些地址是从路由器通告中的前缀选项（Prefix option）学习得到的。

  • 此家庭代理（HA）条目的剩余生存时间。当生存时间到期时，必须将该家庭代理从列表中删除。

  • 该家庭代理的优先级。较高的值表示较高的优先级。此值从路由器通告中的家庭代理信息选项（Home Agent Information）中的家庭代理优先级字段学习得来（如果存在）。如果不存在，则此值设置为 0。家庭代理使用此优先级在发送家庭代理地址发现回复消息时对家庭代理列表进行排序。

发送家庭代理地址发现回复（Home Agent Address Discovery Reply）时，必须列出链路上的所有家庭代理，并按优先级排序。回复消息中的家庭代理地址字段仅包含家庭代理的全球 IPv6 单播地址。回复的大小不得超过 1,280 字节。按优先级排序确保具有较高优先级的家庭代理会在此数据包中列出。

移动前缀请求

移动前缀请求（Mobile Prefix Solicitation）消息由离开家庭的移动节点发送，用于确定其家庭链路的前缀配置变化（即家庭网络重新编号）。家庭代理通过前缀通告（Prefix Advertisement）回答请求消息。根据此回复，移动节点可以调整其家庭地址。

移动节点向其 HA 发送 ICMPv6 移动前缀请求消息。IPv6 头部将原地址作为源地址，插入家庭地址目标选项。支持 IPsec 头，并应使用。移动前缀请求可以携带必须遵循第四章（RFC 4861）中描述的格式的选项。目前，没有定义具体的选项。移动前缀请求消息的类型值字段设置为 146；代码字段设置为 0。

HA 向移动节点的原地址发送 ICMPv6 移动前缀广告消息。HA 还可以定期发送非请求式广告。广告携带类型为 2 的路由头。回复消息发送到请求消息的源地址。如果是非请求式广告，则发送到已注册移动节点的原地址。广告的类型值设置为 147。如果是对请求的回应，标识符将从请求消息中复制。广告包含在第四章中描述的前缀选项。它携带所有应该由移动节点用来配置其家庭地址的前缀。

邻居发现（ND）中的变化

在 ND 中定义了一些变化和新选项，以便与移动 IPv6 一起使用。

修改后的路由器广告格式

如在第四章中已提到，路由器广告中新增了一个标志。M 标志和 O 标志后面跟着 H 标志，该标志允许路由器在此链路上广告其作为主机代理的角色。

修改后的前缀选项

为了基于路由器广告构建更新后的 HA 列表，移动节点必须知道路由器的全局单播地址。常规的路由器广告只列出了路由器的链路本地地址。为此，前缀选项已经进行了修改。前缀选项现在携带一个额外的标志——R 标志（路由器地址）。当设置该标志时，表示前缀选项字段不包含前缀，而是包含路由器的全局 IPv6 单播地址。

新的广告间隔选项

广告间隔选项用于路由器广告中。它表示路由器发送非请求式多播路由器广告的间隔时间。该选项采用 TLV 格式（时间、长度、值），类型值为 7。广告间隔字段占 4 字节，表示路由器广告之间的毫秒时间间隔。移动节点在其移动检测算法中使用此信息（该算法将在本章后续部分介绍）。

邻居发现规范为无请求的多播路由器广告设置了最小间隔为三秒。移动节点依赖于尽可能快速地学习，当移动到新网络时，相应地创建新的临时地址并发送绑定更新。它们通过来自尚未认识的路由器的路由器广告来检测自己是否移动到新网络。因此，支持移动 IPv6 的路由器必须能够配置为更短的路由器广告间隔。或者，可以使用来自更低层（即第二层）的移动信息来帮助移动节点更快地检测移动。

新的主机代理信息选项

主机代理信息选项用于路由器广告，并遵循 TLV 格式。类型值为 8。

HA 优先级字段的长度为 2 字节。在路由器广告中，HA 可以使用此字段指示应与其关联的优先级级别。较高的值表示较高的优先级。当此选项未设置时，HA 的优先级为 0。该字段可由 HA 用于动态调整以应对不同情况，例如当前连接的移动节点数量或可用资源多少来服务更多的移动节点。或者，优先级可以手动配置。

主机代理生命周期字段的长度也为 2 字节。它表示此 HA 的生命周期，单位为秒。默认值对应于基本路由器广告头中的值。最大可能值为 18.2 小时。值为 0 不被接受。HA 生命周期字段仅与此路由器的 HA 服务相关，因此仅能出现在 H 位（主机代理）设置的路由器广告中。

移动 IPv6 通信

本节讨论了移动 IPv6 术语，并深入探讨了通信过程的细节。

绑定缓存

每个通信节点和主机代理都会为其每个全局 IPv6 地址维护一个绑定缓存。它列出所有拥有绑定的移动节点。如果它想将数据发送到某个目的地，它会首先在其绑定缓存中查找，然后在目标缓存中查找地址。

绑定缓存条目携带以下信息：

  • 用于该条目的移动节点的主机地址。此字段用于在发送数据包时确定目标地址。

  • 由主机地址字段指示的移动节点的临时地址，位于此绑定缓存条目中。

  • 绑定的生命周期值。

  • 一个标志，指示此条目是否为主机注册条目。仅出现在充当主机代理的节点上。

  • 针对此主机地址接收到的所有先前绑定更新的序列号字段的最大值。

  • 此条目的使用信息。

绑定更新列表

每个移动节点维护一个绑定更新列表。该列表包含移动节点发送给其家乡代理和通信节点的每个绑定更新条目，前提是其生命周期尚未过期。如果它发送了多个绑定更新，则只列出具有最高序列号的最后一条消息。

绑定更新列表包含以下信息：

  • 绑定更新已发送的节点的 IPv6 地址

  • 绑定更新已发送的家乡地址

  • 该绑定更新中指示的外部地址

  • 绑定更新中指示的生命周期

  • 绑定的剩余生命周期

  • 该绑定的最高使用序列号

  • 绑定更新发送的时间

  • 需要重传的状态

  • 一个标志，指示是否需要向该目标发送进一步的绑定更新

返回可路由性程序

返回可路由性程序的设计目的是让通信节点检测移动节点是否可以在其外部地址和家乡地址上都能被访问。只有当这一点成功验证后，路由优化（即通信节点与移动节点之间的直接通信）才可使用。移动节点能在两个地址上被访问，表明它确实在外部链路上，并且已为家乡地址进行了有效注册。这降低了（但并不消除）该绑定更新为安全攻击的风险。只有在成功通过返回可路由性测试后，通信节点才会接受来自移动节点的绑定更新，并直接向移动节点的外部地址发送数据报文。

返回可路由性程序的消息流程包括以下步骤（关于 MH 类型，请参见表 8-1）：

  1. 移动节点通过家乡代理向通信节点发送“家乡测试初始化”消息（MH 类型 1）。该消息携带家乡初始化 Cookie。通过这种方式，通信节点得知了移动节点的家乡地址。

  2. 移动节点发送“外部地址测试初始化”消息（MH 类型 2）给通信节点。该消息携带外部初始化 Cookie，并直接发送给通信节点（而非通过家乡代理）。通过这种方式，通信节点得知了移动节点的外部地址。

  3. 通信节点对“家乡测试初始化”消息进行回复，并通过家乡代理发送“家乡测试”消息（MH 类型 3）。该消息携带家乡初始化 Cookie、家乡密钥生成令牌和家乡随机数索引。移动节点现在可以生成家乡密钥生成令牌。

  4. 通信节点对“外部地址测试初始化”消息进行回复，并发送到移动节点的外部地址，回复为“外部地址测试”消息（MH 类型 4）。该消息包含外部初始化 Cookie、外部密钥生成令牌和外部随机数索引。移动节点现在可以生成外部密钥生成令牌。

一旦移动节点接收到家庭测试和 Care-of 测试消息，返回可达性过程就完成了。移动节点将这两个令牌哈希，并创建一个 20 字节的管理密钥，显然该密钥也为最初生成这两个令牌的对应节点所知。此密钥将由移动节点用于保护绑定更新到对应节点。经过安全检查成功后，对应节点可以接受绑定更新，因为移动节点已经证明它在绑定更新中包含的家庭地址和 Care-of 地址是可达的。

RFC 4225《移动 IP 版本 6 路由优化安全设计背景》概述了在定义返回可达性过程时所做的安全性考虑和选择。该信息性文档的目的是帮助 MIPv6 实现者理解设计选择，并帮助设计多宿主解决方案的人员避免一些常见的安全陷阱。详细讨论了安全问题和可能的对策。

家庭代理操作

当移动节点离开家庭时，HA 必须拦截所有发送到移动节点的数据包，并将其隧道到移动节点的 Care-of 地址。它通过代理邻居发现来实现这一点。

代理邻居发现

为了拦截发送到家庭链路上移动节点的数据包，HA 必须假装成移动节点。HA 向所有节点组播地址发送邻居广告，提供它自己的链路层地址作为移动节点家庭地址的链路层地址。ND 消息包含以下信息：

  • 邻居广告中的 IPv6 头部的源地址是 HA 的地址。

  • ND 消息中的目标地址字段携带移动节点的 IPv6 地址。

  • ND 广告包含一个目标链路层地址选项，携带 HA 的链路层地址。

  • 路由器标志（R-Flag）必须设置为 0。

  • 必须设置覆盖标志（O-Flag）。链路上的所有节点将更新其邻居缓存，并存储链路层地址。

现在，HA 接收到所有发送到移动节点 IPv6 地址的链路上的数据包。HA 充当移动节点的代理。它必须检查所有收到的邻居请求，并验证目标地址字段是否与其绑定缓存中的家庭注册条目对应。如果是，它会通过邻居广告回复，指出它自己的链路层地址作为移动节点的链路层地址。此过程还保护了移动节点的家庭地址，防止其他家庭链路节点试图配置该地址（即，重复地址检测）。

注

有关邻居发现以及提到的 ND 消息和过程格式的更多详细信息，请参阅第四章。

双向隧道

为了转发发送到移动节点家庭地址的数据包，HA 使用 IPv6 隧道。它插入一个额外的 IPv6 头，称为隧道头。隧道头中的源地址是 HA 的 IPv6 地址，目标地址是移动节点的主要 Care-of 地址。移动节点处理隧道头并将解封装后的数据包转发到上层协议和应用程序。

为了在离家时接收组播数据包，移动节点必须注册这些组成员资格。有两种方式可以实现：

  • 移动节点可以使用其 Care-of 地址向主链路上的本地路由器注册。在这种情况下，它可以直接接收组播数据包。如果移动节点移动到另一个外部网络，这些成员资格将失效。

  • 移动节点可以通过向其 HA 发送 MLD 注册请求，在其主链路上注册组播组成员资格，HA 会通过隧道将组播数据包转发到移动节点。这无论移动节点更换网络多少次，始终有效。

以下数据包不会转发到移动节点：

  • 发送到移动节点链路层地址的数据包。这些数据包将以 ICMPv6 目标不可达消息响应。

  • 发送到移动节点站点本地地址的数据包。（站点本地地址在发布移动 IPv6 规范后已被弃用；此项将在未来版本的 RFC 中删除。）

  • 发送到链路本地、站点本地或组织本地范围的组播数据包。

通过反向隧道从移动节点发送到 HA 的数据包会被 HA 解封装，并通过常规路由机制转发到目标。

当 HA 本身向移动节点发送数据时，它的行为像一个普通的对应节点，这意味着它不使用隧道，而是插入一个路由头类型 2，携带移动节点的家庭地址。

移动节点操作

只要移动节点在家庭网络中，就不需要使用移动 IPv6 机制。如果移动节点离家，它同时使用家庭地址和 Care-of 地址。对于每次通信，它必须选择使用哪个地址。IP 层之上的应用和进程通常使用移动节点的家庭地址进行通信。

如果通信需要在移动节点迁移到另一个网络后继续进行，必须使用家庭地址。一旦移动节点与一个有绑定的对应节点建立通信，通信就可以直接路由。如果没有绑定，所有数据都将通过家庭代理隧道传输。对于某些特定的、新的通信，移动节点也可以选择使用其 Care-of 地址，而不依赖于移动 IPv6 功能，就像普通的单播地址一样。当移动节点与外部网络中的本地节点进行通信时，例如进行邻居发现时，它应直接通信，而不使用家庭地址目标选项。

最佳通信路径和相应地址的选择取决于应用程序的要求，这就是决策必须做出的地方。这个定义并不是移动 IPv6 规范的一部分。

路由优化详细信息

当一个不在家庭网络中的移动节点与其有绑定的通讯节点进行通信时，它会使用称为路由优化的过程。

移动节点执行以下步骤：它检查其绑定更新列表，查找此通讯节点的家庭地址条目。这样可以验证通讯节点是否能够处理家庭地址目标选项。然后，它检查绑定更新列表中的以下内容：

  • 检查它想要使用的源地址是否与条目中的家庭地址相对应。

  • 检查它想要使用的目标地址是否与条目中通讯节点的地址相对应。

  • 检查其当前的暂时地址（Care-of address）是否列为该条目的暂时地址。

  • 检查绑定是否有效，并且生命周期是否大于零。

如果满足所有这些要求，移动节点就知道通讯节点拥有一个有效的绑定缓存条目。从移动节点发送到该通讯节点的数据包包含以下信息：

  • IPv6 头中的源地址字段包含暂时地址。

  • 数据包携带一个目标选项头，内含一个家庭地址选项，包含移动节点的家庭地址。

接收此数据包的通讯节点将从目标选项头中复制家庭地址到 IPv6 头的源地址字段，然后再将数据包传递给上层协议和应用程序。对于上层协议和应用程序来看，数据包似乎是从移动节点的家庭地址发送的。当通讯节点想要向一个移动节点（MN）发送数据时，它会检查其绑定缓存中是否有该目标的条目。如果存在该条目，它会插入一个路由头类型 2。

当通讯节点回复时，地址的使用方式如下：

  • IPv6 头中的目标地址包含移动节点的暂时地址。

  • 数据包包含一个路由头类型 2。路由头中的地址字段包含移动节点的家庭地址。

  • 移动节点将 IPv6 头中的目标地址字段中的地址与从路由头中复制的家庭地址交换，减少路由头中的剩余段字段（Segments Left）值，将其设置为零，并将数据包传递给上层协议和应用程序。对于上层协议来看，数据包似乎是已发送到移动节点的家庭地址。

图 8-5 展示了移动节点（MN）与通讯节点（CN）之间的通信，以及与路由优化相关的具体头信息。

带路由优化的头部信息图 8-5. 带路由优化的头部信息

此图说明了前面描述的过程。移动 IPv6 的主要目标是让 MN 在从一个网络移动到另一个网络时，保持对服务和应用的连接。路由优化的目标是允许 MN 和对应节点之间进行直接路由。通过使用目标选项和路由类型 2 头部，两个节点可以像直接与 MN 在其主机链路上通信一样，在内部处理数据包。因此，对于应用程序来说，看起来就像移动节点仍然在其主机链路上。

这解释了为什么 IPv6 移动性更具可扩展性，并且更适合广泛的移动性应用。扩展头部架构支持路由优化。试想成千上万的移动节点通过其主机代理与对应节点通信。如果所有流量都通过主机代理，主机代理将成为瓶颈、单点故障，并且主机链路将不必要地过载。在许多情况下，从移动节点到对应节点的路由要比经过主机代理的路由短得多。

双向隧道通信

如果 MN 想与没有绑定的对应节点通信，它将使用反向隧道机制。在这种情况下，数据包通过主机代理的隧道发送。原始数据包中的源地址携带 MN 的主机地址，而对应节点的地址作为目标地址。该数据包被封装在另一个 IPv6 头部中，源地址字段携带 MN 的 Care-of 地址，目标地址字段携带主机代理的 IPv6 地址。主机代理处理第一个头部并将原始数据包转发给对应节点。图 8-6 说明了头部信息。

带双向隧道的头部信息图 8-6. 带双向隧道的头部信息

移动检测

移动节点（MN）如何检测自己已经移动到另一个网络？移动检测基于邻居不可达检测（NUD；详见第四章）。通过使用 NUD，MN 可以检测到其默认路由器不再可用。在这种情况下，MN 会尝试寻找新的默认路由器。它会对其链路本地地址进行重复地址检测（DAD），根据路由器广告选择新的默认路由器，并基于路由器前缀构建新的 Care-of 地址。当新的地址初始化时，它首先与主机代理执行绑定更新，然后与所有有绑定的对应节点进行更新。

新路由器通告新前缀的事实并不一定是移动节点处于新网络的标志。可能是当前网络中的新路由器或前缀发生了变化。必须定义程序，以防止移动节点在未移动到其他网络时不必要地更新所有绑定。到目前为止，已定义以下程序：

  • 如果移动节点收到来自新路由器的带有新前缀的路由公告，但其默认路由器仍然可达，它将不会执行任何绑定更新。它使用邻居可达性检测（NUD）来检测默认路由器是否仍然可用。

  • 路由公告（RAs）可以携带广告间隔选项。这允许移动节点根据不同路由公告中的间隔比较来检测此路由器是否仍然可用。

  • 如果默认路由器未响应邻居请求（Neighbor Solicitation），移动节点应执行多播路由请求（Multicast Router Solicitation）。

RFC 5568，"移动 IPv6 快速切换"，描述了对移动 IPv6 规范的更新，以减少切换延迟。为此目的定义了新的 ND 消息类型。

返回家园

当移动节点检测到自己已经回到家乡链接时，它向家乡代理发送绑定更新，通知其已回到家中，并且家乡代理不再需要通过隧道转发数据包。这被称为注销绑定更新，只有在注销之后，移动节点才能使用其家庭地址发送和接收数据包。

该家庭注册如下所示：

  • 必须设置 A 位（确认）和 H 位（家庭注册）。

  • Lifetime 字段设置为 0。

  • Care-of 地址必须与家庭地址相同。

  • IPv6 头部中的源地址必须是移动节点的家庭地址。

安全

如果家乡代理和移动节点之间的数据流未加密，则可能面临许多攻击的可能性，例如中间人攻击、劫持或拒绝服务攻击。

为了保护家乡代理和移动节点之间的隧道，配置了 IPsec 隧道。移动 IPv6 消息需要 IPsec ESP。移动 IPv6 规范对此进行了详细说明。

以下数据流必须进行保护：

  • 移动节点（MN）和家乡代理（HA）之间的绑定更新和绑定确认

  • 在返回可路由性过程（Return Routability Procedure）期间，通过家乡代理发送的家庭测试初始化和家庭测试消息

  • 用于前缀发现的移动节点（MN）和家乡代理（HA）之间的 ICMPv6 消息

移动节点和家乡代理之间的所有控制消息都需要认证、完整性、正确的顺序和防重放保护。此保护需要家乡代理和移动节点之间的安全关联（SA）。IPsec 不提供任何控制消息顺序的手段。正确的顺序由绑定更新和确认消息中的序列号提供。仅当使用互联网密钥交换（IKE）时，才能提供更强的重放攻击保护。

注意

有关安全术语和概念的描述，请参见第六章。

移动节点与对应节点之间的绑定更新通过在返回路由能力过程（Return Routability Procedure）中建立的安全关联（SA）进行保护。移动节点与对应节点之间的绑定更新还必须通过绑定授权数据选项进行保护。此选项包括一个绑定管理密钥，该密钥是在返回路由能力过程中生成的。

关于移动 IPv6 的安全性方面及机制的更详细讨论，可以参见 RFC 6275（《IPv6 中的移动支持》）、RFC 3776（《使用 IPsec 保护移动节点与家庭代理之间的移动 IPv6 信令》）、RFC 4877（《使用 IKEv2 和修订版 IPsec 架构的移动 IPv6 操作》），以及一般的安全性 RFC。

RFC 4285，《移动 IPv6 认证协议》为 3GPP2 网络中的 MIPv6 消息提供了一种安全机制。它是一个信息性 RFC，没有经过 IETF 的审查，包含一个专为 MIPv6 设计的移动性消息认证选项，可添加到 MIPv6 信令消息中。

移动 IPv6 扩展

为了使移动 IPv6 更加灵活和可扩展，已定义了若干扩展。以下部分将对这些扩展进行描述。

NEMO

移动 IPv6 的扩展——网络移动（NEMO）已在 RFC 3963 中定义。NEMO 基本支持协议使得移动网络可以连接到互联网上的不同节点。它使得移动网络中的每个节点在移动路由器改变其附着点时，仍能保持会话连续性。它还允许移动网络中的每个节点在移动时仍然可达。该解决方案支持既支持移动性的移动节点，也支持在移动网络中不支持移动性的主机。

该过程和消息与移动 IPv6 基本相同，不同之处在于，此时移动节点是一个移动路由器。在当前的 NEMO 规范中，移动网络中的节点与对应节点之间的通信始终通过家庭代理进行。路由优化尚未定义。从理论上讲，可以配置嵌套的移动性，其中一个移动路由器允许另一个移动路由器连接到其移动网络。这为许多高移动性的场景打开了新的可能性。一个应用案例可能是车载通信，车中的路由器可以作为移动路由器。未来我们将看到如何使用这些技术，过去几年中的发展表明，有时意想不到的应用会在一夜之间出现并广泛使用。

分层移动 IPv6

随着 RFC 5380《分层移动 IPv6》的发布，移动 IPv6 的可扩展性得到了进一步扩展。该设计旨在显著提升移动 IPv6 的性能，并减少移动节点在链路上传输更新其与家庭代理和对应节点绑定的消息的次数。它还允许移动节点在使用路由优化时，隐藏其位置，避免暴露给对应节点和家庭代理。

分层移动 IPv6 引入了一种新的节点类型——移动锚点（MAP）。MAP 可以位于分层网络中的任何路由器位置。它本质上是移动节点所在地理区域的本地家庭代理。移动节点现在将绑定更新消息发送到本地 MAP，而不是家庭代理和通信节点。通过向 MAP 发送一次绑定更新消息，所有来自家庭代理和通信节点的后续流量将被重新路由到移动节点的新位置。家庭代理和通信节点的操作不会受到影响，因此无需进行任何更改。图 8-7 说明了这一概念。

分层移动 IPv6图 8-7. 分层移动 IPv6

当移动节点进入 MAP 域时，它会接收到包含一个或多个本地 MAP 信息的路由器广告（MAP 选项）。MAP 的区域关怀地址（RCoA）对应于基础 MIPv6 规范中的关怀地址。在与 MAP 注册后，移动节点将其 RCoA 注册到其家庭代理，并最终注册到当前的通信节点。RCoA 现在被用作移动节点的关怀地址。它是家庭代理和通信节点用于与远离家庭的移动节点通信的地址。当移动节点在 MAP 域内从一个网络移动到另一个网络时，它会将新的链路本地关怀地址（LCoA）注册到 MAP。MAP 作为本地家庭代理，代表移动节点接收所有数据包，并将其封装并转发到移动节点的当前地址。图 8-7 中的接入路由器（AR1 和 AR2）定义了 MAP 域的边界。这显著提高了移动 IPv6 的性能，因为每次移动节点在 MAP 域内切换到另一个网络时，绑定更新不必再发送到家庭代理和通信节点。

如绑定更新消息部分所述，绑定更新消息中新增了一个位——M 位，用于指示这是一个 MAP 注册，而非与家庭代理的绑定更新。此外，邻居发现协议也进行了扩展，以包括 MAP 的全局 IPv6 地址。

MAP 可以存在于分层网络中的任何位置。多个 MAP 可以独立地位于同一域内。此外，允许并推荐重叠的 MAP 域。支持静态和动态层级结构。

代理移动 IPv6

代理移动 IPv6 是一种基于网络的移动性管理协议。它在 RFC 5213 中进行了定义，并在网络层提供移动性管理，这意味着网络组件接管了处理移动性消息的工作。

这些元素包括本地移动锚点（LMA）和移动接入网关（MAG）。LMA 负责管理 MN 及其家庭前缀的可达性。LMA 具有 MN 的拓扑锚点功能。MAG 管理 MN 的移动性。MAG 位于 MN 的接入网络上，负责 MN 的移动以及与 LMA 的绑定消息的发起。在一个移动 IPv6 域中可以有多个 LMA，每个 LMA 可以管理不同的 MN 组。

或者，可以使用本地路由（RFC 6705）允许连接到 MAG 的节点通过使用本地转发或网关之间的直接隧道直接交换流量。

多个 Care-of 地址注册

如果 MN 具有多个活动接口，它只能将其中一个 Care-of 地址与其家庭地址绑定。RFC 5648 中的规范定义了支持将多个 Care-of 地址与家庭地址绑定的扩展。每个 MN 创建的绑定都会生成一个新的绑定标识号（BID），并将其包含在绑定更新中。HA 为每个 BID 创建一个单独的绑定，并相应地将其存储在绑定缓存中。相同的机制也适用于与 CN 的绑定消息。

流绑定

上述多个 Care-of 地址注册允许将多个 CoA 与家庭地址进行绑定。通过 RFC 6089 中的流绑定规范，可以为每个绑定关联不同的策略。这也适用于与 CN 或 MAP 的绑定。

快速切换

在 RFC 5568 中，指定了一种协议，用于减少移动节点从一个网络移动到另一个网络时的切换延迟。它被称为“移动 IPv6 的快速切换”。切换操作包括移动检测、地址配置和地址更新。综合切换延迟通常足以影响实时应用（例如 VoIP）。此规范描述了一组协议和程序，以显著减少切换延迟。所有对吞吐量敏感的应用都能从快速切换中受益。

RFC 4260《802.11 网络的移动 IPv6 快速切换》讨论并给出了一些关于在 802.11 网络上实施移动 IPv6 快速切换的例子。

支持双栈主机和路由器

原始的移动 IPv6 和 NEMO 规范仅描述了使用 IPv6 进行移动性。RFC 5555 扩展了这一点，允许 IPv4 地址和前缀的注册，并且还允许 IPv4 和 IPv6 数据包通过隧道传输到 HA。MN 可以从 IPv4 网络移动到 IPv6 网络，反之亦然，即使 MN 与 HA 之间的路径中存在 NAT。

现在你已经阅读完本书中的技术章节。第九章将所有内容整合在一起，解释了规划和设计未来网络的关键。它整合了超过 10 年的经验、教育和咨询，结合了许多基于最佳实践的建议。

参考文献

以下是本章提到的最重要的 RFC 和草案列表。有时我还会提供一些与主题相关的额外 RFC，供你个人进一步学习。

RFCs

  • RFC 2710, “IPv6 的多播监听发现（MLD）”，1999

  • RFC 3776, “使用 IPsec 保护移动节点与主代理之间的移动 IPv6 信令”，2004

  • RFC 3963, “网络移动性（NEMO）基本支持协议”，2005

  • RFC 4065, “Seamoby 和实验性移动协议 IANA 分配的说明”，2005

  • RFC 4140, “分层移动 IPv6”，2005

  • RFC 4225, “移动 IPv6 路由优化安全设计背景”，2005

  • RFC 4260, “802.11 网络上的移动 IPv6 快速切换”，2005

  • RFC 4282, “网络接入标识符”，2005

  • RFC 4283, “移动 IPv6（MIPv6）的移动节点标识符选项”，2005

  • RFC 4285, “移动 IPv6 的认证协议”，2006

  • RFC 4303, “IP 封装安全负载（ESP）”，2005

  • RFC 4306, “互联网密钥交换（IKEv2）”，2005

  • RFC 4449, “使用静态共享密钥保护移动 IPv6 路由优化”，2006

  • RFC 4487, “移动 IPv6 与防火墙：问题陈述”，2006

  • RFC 4555, “IKEv2 移动性和多宿主协议（MOBIKE）”，2006

  • RFC 4584, “移动 IPv6 的套接字 API 扩展”，2006

  • RFC 4621, “IKEv2 移动性和多宿主（MOBIKE）协议设计”，2006

  • RFC 4831, “基于网络的本地化移动性管理（NETLMM）目标”，2007

  • RFC 4866, “移动 IPv6 的增强路由优化”，2007

  • RFC 4877, “与 IKEv2 和修订后的 IPsec 架构一起操作的移动 IPv6”，2007

  • RFC 4885, “网络移动性支持术语”，2007

  • RFC 4887, “网络移动性家庭网络模型”，2007

  • RFC 4908, “使用移动 IP 和 NEMO 的小规模固定网络多宿主”，2007

  • RFC 5094, “移动 IPv6 厂商特定选项”，2007

  • RFC 5096, “移动 IPv6 实验消息”，2007

  • RFC 5142, “移动性头主代理切换消息”，2008

  • RFC 5149, “移动 IPv6 服务选择”，2008

  • RFC 5164, “移动性服务传输：问题陈述”，2008

  • RFC 5213, “代理移动 IPv6”，2008

  • RFC 5270, “IEEE 802.16e 网络上的移动 IPv6 快速切换”，2008

  • RFC 5271, “3G CDMA 网络上的移动 IPv6 快速切换”，2008

  • RFC 5380, “分层移动 IPv6（HMIPv6）移动性管理”，2008

  • RFC 5555, “移动 IPv6 对双栈主机和路由器的支持”，2009

  • RFC 5568, “移动 IPv6 快速切换”，2009

  • RFC 5637, “移动 IPv6 的认证、授权和计费（AAA）目标”，2009

  • RFC 5648, “多个 Care-of 地址注册”，2009

  • RFC 5844, “IPv4 支持代理移动 IPv6”，2010

  • RFC 5846, “IPv6 移动性绑定撤销”，2010 年

  • RFC 5847, “代理移动 IPv6 的心跳机制”，2010 年

  • RFC 5944, “IPv4 的 IP 移动性支持”，2010 年

  • RFC 6089, “移动 IPv6 和网络移动性（NEMO）基本支持中的流绑定”，2011 年

  • RFC 6275, “IPv6 中的移动性支持”，2011 年

  • RFC 6279, “代理移动 IPv6（PIMPv6）本地化路由问题陈述”，2011 年

  • RFC 6463, “代理移动 IPv6 的运行时本地移动锚点（LMA）分配支持”，2012 年

  • RFC 6543, “代理移动 IPv6 的保留 IPv6 接口标识符”，2012 年

  • RFC 6572, “代理移动 IPv6 的 RADIUS 支持”，2012 年

  • RFC 6610, “移动 IPv6（MIPv6）中的主信息发现的 DHCP 选项”，2012 年

  • RFC 6611, “移动 IPv6（MIPv6）集成场景的引导过程”，2012 年

  • RFC 6618, “使用传输层安全性（TLS）进行移动节点与主代理之间通信的移动 IPv6 安全框架”，2012 年

  • RFC 6705, “代理移动 IPv6 的本地化路由”，2012 年

  • RFC 6909, “代理移动 IPv6 的 IPv4 流量卸载选择器选项”，2013 年

  • RFC 7077, “代理移动 IPv6 的更新通知”，2013 年

  • RFC 7109, “由主代理发起的移动 IPv6 流绑定”，2014 年

  • RFC 7148, “代理移动 IPv6 的前缀委派支持”，2014 年

  • RFC 7156, “Diameter 对代理移动 IPv6 本地化路由的支持”，2014 年

  • RFC 7161, “通过 LMA（SIAL）获取订阅信息的代理移动 IPv6（PMIPv6）组播切换优化”，2014 年

  • RFC 7222, “代理移动 IPv6 的服务质量选项”，2014 年

第九章：IPv6 规划

在前面几章从技术角度描述了 IPv6 的特点之后，本章将所有内容汇总起来。

它总结了我在学习、工作、娱乐、教学和为 IPv6 提供咨询的 10 多年里所学到的一切。它为您提供了所有相关的内容，帮助您理解规划 IPv6 集成所需的知识。它也是我在与客户交流时，回答最常见问题的总结。希望能让您对 IPv6 所带来的机会感到一些兴奋。所以，我祝您阅读愉快，并在学习和规划 IPv6 时收获乐趣。

虽然在较大网络中进行集成确实会遇到一些挑战，并且需要大量时间和仔细规划，但不需要惊慌，也不用认为这无法掌握。每一个掌握了 DHCP、VPN 和 NAT 引入的合格工程师，也能掌握 IPv6 的引入。主要的不同点在于 IPv6 作为传输协议几乎涉及到网络中的每一个组件，因此复杂性来自于考虑不同网络组件、服务和部门之间的所有交互。挑战主要体现在组织层面、未来架构的设计，以及所有团队和网络、应用程序各部分之间的相互依赖关系。

但这个过程可以分解为单个可执行的步骤，并且如果足够提前开始，完全不需要在三个月内完成。本章提供了一个大纲，帮助您确定如何进行。

何时选择 IPv6？

一条黄金法则是“永远不要触碰一个正在运行的系统。”这条规则同样适用于您的 IPv4 网络。只要它们能正常工作，就让它们继续运行。但是，当 IPv4 网络因某些原因达到限制，或者当需要进行升级时，选择 IPv6。IPv6 已经足够成熟，可以在企业和商业网络中使用，正如全球许多案例研究和部署所展示的那样。如果可能，应该避免在新的 IPv4 设置、修复或复杂的 IPv4 配置（特别是 NAT）上进行高额投资，因为它们是在一个将被逐步淘汰的技术上进行的投资，而这个技术实际上已经进入了生命周期末期。提前熟悉新协议，在真正需要它之前花一些时间进行实验，并提前规划，将为您节省大量成本、时间和麻烦。

注意

无论您在 IPv6 上的投资如何，它都是对未来技术的投资。而在 IPv4 上的投资则是对一个即将结束生命周期的技术的投资。

如同在第一章中提到的，这里列出了可能是您考虑集成 IPv6 的一些指示：

  • 您的 IPv4 网络或 NAT 实现需要修复或扩展。

  • 计划中的重大硬件升级或重新设计。为 IPv6 重新设计，并根据需要支持 IPv4。

  • 您的地址空间即将用尽。

  • 你想为可能突然需要 IPv6 支持的收购做好网络准备。

  • 你想为基于 IPv6 高级特性的应用程序准备网络。

  • 你需要为大量用户提供端到端安全性，但没有足够的地址空间，或者在 NAT 实现上遇到困难。

  • 你的硬件（骨干网、DMZ、数据中心等）或应用程序已经到达生命周期的尽头，必须更换。确保你购买支持 IPv6 的产品，即使你不会立即启用它。为了确定你的产品需要的支持水平，你需要有一个 IPv6 战略。

集成场景

正如本章对不同技术的讨论所示，存在许多机制支持逐步引入 IPv6。没有一种机制可以覆盖所有需求，或者在所有场景中都最优。在大多数情况下，会选择不同机制的组合。最佳组合和顺序取决于当前环境的基础设施以及过渡/集成的目标和要求。在 IETF 中，基础协议的工作已经完成。他们现在专注于为不同类型的环境开发实际场景，结果已发布。我们在此提供一个总结，目的是提供思路，供你根据自己的需求加以应用，而非为你的环境提供操作手册。

注意

如果你想了解 IPv6 运维工作组的最新动态，可以参考 www.ietf.org/html.charters/v6ops-charter.html 和 www.ietf.org/html.charters/6man-charter.html。

组织

将单一主机或小型网络与 IPv6 Internet 连接并不是一个大挑战，可以通过原生支持（如果你的 Internet 提供商提供此服务）或者使用前面描述的某些隧道机制来实现。大多数操作系统都可以轻松实现此连接。

如果你需要隧道，拥有公共 IPv4 地址，并且想要访问 IPv6 Internet，可以使用 6rd 或 Tunnel Broker。如果你已启用 NAT 并使用私有 IPv4 地址，你可以选择使用 Proto 41 转发，只要 NAT 设备支持此功能。那些有幸得到提供商提供原生 IPv6 连接的组织可以拥有双栈互联网连接。如果你的设备和操作系统支持 IPv6（如果它们是最新版本，肯定支持），那么双栈通常是最简单的方式。

许多组织有多个 IPv4 虚拟局域网（VLAN）。在这种情况下，IPv6 路由器可以将一个单一的 IPv6 前缀通告到所有支持双栈通信的 VLAN 中。然而，这仅建议作为过渡期使用。在这些 VLAN 中的所有 IPv6 节点可以通过 IPv6 路由器通告的前缀进行自动配置 IPv6 地址。

隧道机制不仅支持通过 IPv4 互联网传输 IPv6，还支持在 IPv4 骨干网上内部传输 IPv6。骨干网升级并不是你每年都会选择做的事情；你可能希望等到骨干路由器生命周期结束后再进行改动。这并不妨碍在网络边缘推广 IPv6。只要骨干网基于 IPv4，IPv6 数据包就会被隧道化到另一端的 IPv6 岛屿。

如果你希望将 IPv6 集成到一个更复杂的 DMZ 中，用于你的公共服务和/或内部网络，包括多个位置、可能有多个数据中心，以及整个网络中使用的不同类型的应用程序和服务，你需要定义一个企业过渡战略。有关更多细节，请参见规划 IPv6 章节。

RFC 4057《IPv6 企业网络场景》可以帮助你迈出第一步。它描述了 IPv6 在企业网络中的不同部署场景，并提供了如何着手这一任务的指导和检查表。该 RFC 中涵盖了以下场景：

  • 在 IPv4 的配合下部署 IPv6。

  • 因为一组特定的应用需要通过 IPv6 网络使用，所以部署 IPv6。

  • 构建一个新的网络或重组现有的网络，并在企业内部以 IPv6 作为主要协议与 IPv4 共存。

文档接着回顾了企业中常见的几种网络基础设施组件，这些组件必须进行分析。

RFC 4852《IPv6 企业网络分析——IP 层 3 重点》基于 RFC 4057，分析了企业网络向 IPv6 过渡的情况，重点讨论了 RFC 4057 中给出的场景中的第 3 层。文中有一个表格，概述了不同的场景，然后在文中讨论了如何应对每个场景以及可能的过渡机制。请注意，这份 RFC 写于 2007 年。在某些章节中提到了 ISATAP、6to4 和 Teredo 等机制。我们强烈建议你不要在生产环境中使用这些机制，而是用更新的技术来替代它们。

ISPs

IPv6 的设计旨在帮助互联网服务提供商（ISPs）应对互联网的指数级增长挑战，使其能够为客户提供新的服务。在未来几年内，设备数量将激增，而这一挑战只能通过 IPv6 的地址空间来解决。电缆、DSL、无线以及其他始终在线的技术也可以从 IPv6 的地址空间中受益。IPv6 的其他优势包括增强端到端安全性和移动通信的能力，以及减轻系统管理负担。举例来说，包括无需 NAT 穿越问题的点对点通信、能够安全地在家里访问工作中的设备和应用程序或反之亦然、增强的 IP 移动性等。

因此，ISP 必须评估 IPv6 能否满足这些需求。一些国家在这一领域处于领先地位，从测试和评估阶段转向了 IPv6 在宽带领域的实际部署。日本就是一个典型例子，此外还有其他国家正在考虑向大规模生产部署 IPv6 迈进。自 2011 年 IPv4 地址池耗尽以来，许多欧洲和美国的大型服务提供商也已开始部署 IPv6。

注意

在全球范围内，IPv6 中继 AS（自治系统）的数量大幅增加。截至 2014 年，全球前 300 名中继 AS 中有超过 80% 支持 IPv6。

在未来几年，ISP 将不得不同时提供 IPv4 和 IPv6 服务。在第一阶段，为客户提供 IPv6 网络接入（只要其骨干仍为 IPv4）时，可以使用隧道机制。许多大型 ISP 选择使用 6rd，这是一种基于 6to4 的机制，但提供了更多或更少的原生性能（参见 第七章 中的 6rd 部分）。这是一种更简单、更经济的方式来开始提供 IPv6 服务。根据客户的需求和要求，原生 IPv6 部署选项可能具有更好的可扩展性，并提供更好的服务性能。你可能可以利用下一个骨干升级周期并引入双栈。所有其他服务，如网页托管、电子邮件和 FTP，最好同时支持这两种协议（IPv4 和 IPv6）。迁移步骤应当精心规划，选择并实施有效的机制组合。ISP 的主要目标是通过这两种协议提供所有服务：这是覆盖整个市场的唯一途径。尤其对于 ISP 来说，引入 IPv6 提供了创造商业机会和新服务的可能性。作为客户，你在购买互联网服务时希望得到双栈支持，因为只有双栈才能让你成为两个互联网（IPv4 和 IPv6）的完整成员。

RFC 4029，《将 IPv6 引入 ISP 网络的场景与分析》，分析了 ISP 面临的挑战和机遇，并讨论了不同的集成和过渡场景，内容分为骨干过渡行动、客户连接过渡行动以及网络和服务运营行动。RFC 4779，《宽带接入网络中的 ISP IPv6 部署场景》，介绍了在宽带服务提供商网络接入部分部署 IPv6 服务的可选方案，即电缆/HFC、宽带以太网、xDSL、WLAN 和 PLC/BPL。它简要讨论了提供商网络的其他元素，并为每种先前提到的宽带技术提供了不同的可行的 IPv6 部署与集成技术和模型。RFC 5181，《802.16 网络中的 IPv6 部署场景》，扩展了讨论，并深入探讨了无线宽带接入网络的部署场景。

一些互联网服务提供商（ISP）回避部署 IPv6，希望通过扩展其 NAT 和实施 CGN 来应付。思科委托进行的一项 IDC 研究分析了一个拥有 500 万家庭用户的 ISP 在 5 年内的资本支出（capex），并比较了仅部署 CGN 的情境与同时部署 6rd 和 CGN 的情境。研究表明，同时引入 IPv6 和 CGN 的商业案例要好得多。原因在于原生 IPv6 能够减轻 CGN 的流量负担。随着 IPv6 支持的网站数量增加，6rd 的部署将大大减轻 CGN 的流量负担，从而减少 CGN 端的维护工作。

注意

比较结果表明，在 5 年内，选择正确的 IPv6 战略可以使 ISP 节省多达 69%的资本支出投资。如果您对这项研究《现在提供 IPv6 服务的商业案例》感兴趣，可以通过bit.ly/1nac2SH找到它。

移动网络

长期以来，移动网络中的 IPv6 部署并未发生。早期的智能手机，如曾经流行的索尼爱立信 P900，配备了支持 IPv6 的 Symbian 协议栈。但当时没有任何移动运营商愿意部署 IPv6。

过去两年中，这一状况发生了变化。T-Mobile 美国和 Verizon 无线是两个知名的、经常讨论的 IPv6 部署案例。T-Mobile 在 2014 年就已有数百万 IPv6 用户。其他运营商，如中国移动以及一些欧洲运营商，也已经部署了 IPv6。随着 Android 4.3 及更高版本中 464XLAT 的实现，为移动运营商提供 IPv6-only 服务变得更具吸引力。演示表明，使用 464XLAT 时，IPv4 应用程序可以在 IPv6-only 设备上良好运行。其他智能手机厂商希望尽快加入这一行列。

注意

有关 464XLAT 的更多细节，请参见第七章。

RFC 3574 讨论了 3GPP 网络的过渡情境。RFC 4215 则更详细地描述了 3GPP 网络，并且是 RFC 3574 的补充文档。RFC 6459《IPv6 在 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)中的应用》描述了不同 3GPP 架构中的 IPv6 支持，RFC 7066《第三代合作伙伴项目（3GPP）蜂窝设备的 IPv6 要求》描述了超出标准 IPv6 节点要求（RFC 6434）的蜂窝设备需求，因为蜂窝链路在带宽、成本和延迟方面的特点对 IPv6 的使用提出了特殊要求。RFC draft-ietf-v6ops-mobile-device-profile-07定义了一个 IPv6 配置文件，许多运营商推荐该配置文件以将 3GPP 移动设备连接到 IPv6-only 或双栈无线网络（包括 3GPP 蜂窝网络和 IEEE 802.11 网络）。该配置文件不同于 RFC 7066 中定义的用于连接 IPv6 蜂窝网络的一般配置文件，特别是，它还描述了如何通过 IPv6-only 传输提供 IPv4 连接服务的功能。

家庭网络

在互联网的早期，家庭“网络”由一台配有拨号调制解调器的 PC 组成。连接只有一个单一的 IP 地址。今天，这一场景发生了巨大的变化，随着设备数量和类型的增加，以及内部路由的增多，面临的挑战也在增加。现在，我们将 IPv6 引入其中，这再次增加了复杂性，并需要新的设计、新的地址原则和新的操作措施。

IPv4 和 IPv6 地址架构之间的一个重大区别是，在 IPv6 中，接口可以并且通常会拥有多个地址。它们至少有一个链路本地地址，此外，它们还拥有一个或多个全局单播地址（GUAs），甚至可能有一个唯一本地地址（ULA）。如果一个 homenet 有多个 ISP，该家庭网络可能会通过不同的渠道从每个 ISP 获取 IPv6 前缀（例如，从一个 ISP 获得 6rd /60 前缀，另一个通过 DHCP 前缀委派获得/48 前缀，等等）。因此，网络中的所有设备可能最终会拥有两个 GUAs，每个前缀一个。而家庭网络通常会有多个子网。

有几个新的方面需要考虑。IETF 有一个 homenet 工作组，该小组正在为未来更复杂的家庭网络开发新的架构。homenet 小组正在定义基于 IPv6 的家庭网络的通用架构，并描述相关的原则、考虑因素和要求。他们讨论了引入 IPv6 对家庭网络的具体影响，描述了架构的各个元素，并建议如何在家庭网络中使用标准的 IPv6 机制和地址。该小组在其首份文件《IPv6 家庭网络架构原则》中开发的架构，描述了某些附加功能所需的特定协议扩展。假设 IPv6 家庭网络没有进行主动管理，并且作为 IPv6 仅或双栈网络运行。如果你是 ISP，并且需要设计家庭网络，这个小组的文档无疑是一个良好的资源。

注意

你可以在bit.ly/1nac5Om找到 homenet 小组。

IPv6 规划

2011 年 2 月，全球 IPv4 地址池耗尽。从 2011 年 4 月开始，APNIC 开始使用最后一个/8 块地址。从 2012 年 9 月开始，RipeNCC 也开始使用最后一个/8 块地址。这一事件成为整个行业的警钟。从那时起，许多大型企业启动了不同程度的 IPv6 项目。许多项目仍处于规划阶段。正如你将在接下来的章节中看到的，对于大型企业，规划和部署可能需要三到五年的时间。

大多数企业已经克服了商业案例的讨论。实施 IPv6 有很多理由，并且应该立即开始。这里的“立即”指的是您必须现在开始规划。一旦您了解了部署 IPv6 所需的工作量、在不同网络和服务区域的时间安排，以及如何设计您的地址计划和安全概念，您可以将这些计划搁置，直到需要启用 IPv6 的那一天。但如果您没有提前规划，等到那一天来临时，您将无法在时间压力下创造出合格且具备操作性的重要设计。

规划和设计 IPv6 在您网络中的集成为您提供了一个独特的机会，可以为您的下一代 IT 环境奠定新的基础。

注意

IPv6 提供了一个机会，可以清理现有的不一致，推动标准化，并实施新的架构和操作模式。

启动 IPv6 项目的企业最常见的原因是：

  • 业务连续性

  • 可达性（来自外部）

  • 生命周期管理

  • 投资保护

  • 教育和积累经验的时间

提前规划有哪些优势？提前规划可以节省很多成本，并且可以充分利用 IPv6 集成所提供的机会。以下是一些优势：

  • 利用产品生命周期、更新周期和其他 IT 项目。

  • 通过为购买新设备、工具和应用程序，以及谈判外包合同和 SLA 制定明确的 IPv6 要求来保护投资。所有这些都必须进行调整，以便适当覆盖 IPv6 的需求。

  • 集成 IPv6 将需要三年或更长时间（主要是为了利用更新周期）。如果您不提前规划，当需要时您将没有准备好。尤其是地址和安全的设计和概念需要大量时间，并应谨慎完成。它们需要更新，以便利用新的地址架构，通常需要进行深入讨论和多次迭代，直到所有 IT 部门都能认同它。通常，安全人员面临最大的挑战，需要时间学习 IPv6 并调整他们的概念。但这也是一个巨大的机会，可以清理并重新设计基于 IPv4 的安全概念。

  • 您需要时间来教育所有 IPv6 团队成员和 IT 员工。

  • 您想要利用 IPv6 所提供的所有机会！

  • 您需要足够的时间进行实验室测试、测试和试点。

  • 您需要时间与供应商修复 bug（早期堆栈）。

当您运营一个更大规模甚至是全球性的网络时，大多数 IT 决策者会想知道从哪里开始，以及如何进行。

注意

由于 IPv6 的引入涉及到您网络中的每一个方面和设备，这使得这个 IT 项目的规模远远超过了其他任何 IT 项目。

让我为您提供一个快速的 IPv6 规划入门。

注意

规划过程的更详细讨论可以在我的配套书籍《IPv6 规划》（O'Reilly）中找到。

从哪里开始

成功的关键因素之一是 IPv6 项目需要管理层关注，并且需要一位企业级 IPv6 项目经理。网络中的所有设备、服务和各个方面都会受到影响，因此必须拥有全局视角，并意识到接口和依赖关系（无论是组织层面的还是技术层面的）。

第一步：

  • 获取管理层的关注。

注意

指定一个 IPv6 项目经理，并建立一个 IPv6 过渡办公室。

  • 教育参与过程的所有团队。

  • 获取整体视角。

  • 涉及所有团队。

  • 包括业务愿景、业务战略和 IT 战略，并在此基础上制定 IPv6 战略，使其具有可持续性。

  • 您的 IPv6 战略应支持业务。

  • 制定一个针对 IPv6 项目的沟通和内部营销战略。

以下步骤建议：

创建您当前状况的布局

在第一步中，分析您的业务愿景、业务战略和 IT 战略，以及您的 IT 基础设施、IT 服务和项目、硬件和软件的生命周期、工具，以及合同和服务协议。创建流程、政策和标准的概览，并评估 IPv6 集成对所有这些方面的影响。

定义您的 IPv6 战略

在第二步中，定义您的目标架构、总体 IPv6 战略，包括高级地址规划和高级安全概念（两者必须相互一致）。接下来，定义路线图，并将其与其他 IT 项目和更新周期对齐。清晰地了解采用计划、里程碑和依赖关系。基于您的 IPv6 设计，为所有类型的设备和应用程序创建 RFC 要求。评估您的 供应商战略，并检查它是否需要为 IPv6 做出调整。不要假设为 IPv4 表现优秀的供应商也一定适合 IPv6。

评估当前环境

根据 RFC 要求，评估您当前的基础设施、硬件和软件、操作系统、应用程序、服务和合同的 IPv6 准备情况。只有现在，您才能根据评估结果确定部署 IPv6 的成本。根据评估中的发现，您可能还需要调整设计或路线图，或两者都需要调整。利用这个机会，在团队中积累 IPv6 经验。

创建详细的概念和部署计划

对网络中的所有不同领域，必须创建详细的设计和部署计划，并在实验室和试点中进行测试。所有这些过程可能需要多个迭代。需要为测试、修复漏洞和供应商评估分配足够的时间。同时，不要忘记调整所有相关流程，例如升级测试、所有支持级别、变更管理、安全流程、监控、地址管理等。

部署并文档化

如前所述，企业网络中 IPv6 的部署可能需要长达三年甚至五年的时间。你不会一次性在所有领域部署，而是会有一个路线图，并在与其他项目或生命周期对接的特定领域进行部署。因此，最后的步骤，如详细设计、部署计划以及最终部署，通常是针对特定领域执行的。最后，确保所有内容都有良好的文档记录。

关于应用程序的一些说明

启用 IPv6 网络是可行的。但只要应用程序没有在 IPv6 上运行，启用 IPv6 的网络也没有太大意义。所以你需要在启用网络的同时，尽早开始处理应用程序。

第三方应用程序通常应在当前版本中启用 IPv6，如果没有，IPv6 支持应在清晰的路线图中列出。与你的供应商沟通，必要时评估替代方案。然而，自主开发的应用程序情况不同。这里你需要区分两种情况：a) 该应用程序仅在内部使用，b) 该应用程序是市场应用程序。在 a)情况下，你可以控制用户如何使用这些应用程序。为市场开发的应用程序应该能够在 IPv4 网络、IPv6 网络以及双栈网络中运行，因为供应商无法控制用户如何访问应用程序。

如果你为市场开发应用程序，重要的是要提前规划，因为这些应用程序通常有很长的生命周期。如果开发人员不了解 IPv6 的影响，应用程序可能根本无法运行，或者无法针对 IPv6 网络进行优化。因此，无论你是自行开发应用程序还是与合作伙伴共同开发，都要确保开发团队接受充分的 IPv6 教育，重点是如何为双栈网络开发，并更新应用程序设计规范以支持未来的 IPv6 网络。如果你购买市场上的定制开发应用程序，你必须特别更新你的 RFC 要求。

本节不是应用程序移植的指南。这里的目的是让你了解你将面临的情况以及需要注意的事项。

你将遇到以下情况：

  • 在双栈节点上的 IPv4 应用程序

  • 在双栈节点上的 IPv6 应用程序

  • 在双栈节点上，支持 IPv4 和 IPv6 的应用程序

  • 在仅支持 IPv4 的节点上，支持 IPv4 和 IPv6 的应用程序

  • 在仅支持 IPv6 的节点上，支持 IPv4 和 IPv6 的应用程序

开发人员面临的挑战是为市场开发在各种情况下都能良好运作的应用程序。每当需要调用服务时，应该使用 DNS 名称。但是，DNS 回复并不是选择使用哪个协议的可靠指示。例如，一台主机可能是双栈的，并且在 DNS 中有一个带 IPv4 地址的 A 记录和一个带 IPv6 地址的 AAAA 记录。但在这台主机上，可能存在仅支持 IPv4 的应用程序。因此，即使解析主机名返回一个 IPv6 地址，应用程序也无法通过 IPv6 访问。因此，你需要在 DNS 中输入服务名称，并为每个服务配置相应的记录类型（IPv4 服务使用 A 记录，IPv6 服务使用 AAAA 记录）。但如何由 DNS 管理员处理这些问题取决于操作实践，因此不能完全依赖。DNS 请求也可能返回一个 AAAA 记录，但主机可能没有 IPv6 路径连接到它。解析 DNS 名称并获得多个地址的节点应该尝试所有地址，并具备选择最佳性能连接的机制。

注意

Happy Eyeballs 是一种旨在帮助解决这一问题的机制，已在不同操作系统和浏览器中实现。有关更多信息，请参阅 第五章 中的 DNS 部分。

以下列表展示了应用程序中最重要的 IP 依赖：

  • IP 地址的格式（32 位点分十进制或 128 位带冒号的十六进制）

  • 用于建立连接和数据交换的 API 函数

  • DNS，用于将主机名解析为 IP 地址，反之亦然

  • IP 地址选择，地址的缓存/存储

  • 多播应用程序，根据情况；IPv4 和 IPv6 多播地址的对应关系以及正确的套接字配置选项选择

  • 一些应用程序将许可控制基于 IPv4 地址

最好的做法是使应用程序与 IP 版本无关。这意味着源代码不应有任何 IP 依赖。通信库应提供没有 IP 依赖的 API。

注意

在 RFC 4038《IPv6 过渡的应用方面》中可以找到这些问题的更详细讨论。

东京大学和横河电机公司于 1998 年启动了 TAHI 项目。他们开发了可以供 IPv6 开发者使用的测试工具，用于测试其实现是否符合标准并具备互操作性。这些测试可以免费使用。这是他们为 IPv6 高效开发和部署做出的贡献。测试结果也免费提供给开发者社区。在 TAHI 网站 上，所有测试均已列出并记录。TAHI 项目已于 2012 年 12 月结束，因为他们认为它已经完成了“通过质量支持 IPv6 开发者，推动高度互操作的 IPv6 世界”的使命。信息和测试工具仍然存在（在撰写本文时）。

TAHI 项目与其他知名项目紧密合作：WIDE 项目、KAME 项目，该项目也已经结束（但跳舞的 Kame 仍然存在），以及已结束的 USAGI 项目。找到一些有趣的链接以及关于 IPv6 早期演进的一些历史。

应做和不应做的事项

基于多年的大型企业咨询经验，这里有一些我不断看到的观点和看法，我想总结给你们。有些是成功的，而有些则属于你应该避免的范畴。无论如何，它们都试图为你提供如何开展项目的指导方针。

IPv6 就像 IPv4 吗？

通常，尚未开始使用 IPv6 的人有两种观点。第一组认为 IPv6 是显而易见的；毕竟，它与 IPv4 没有太大区别，适应现有的 IPv4 概念并使其运作应该很容易。因此，他们通常认为自己不需要外部帮助，内部人员就能完成，或者他们选择那些拥有良好 IPv4 背景但没有 IPv6 经验的顾问，并假设他们能够完成工作。另一组则认为 IPv6 是一个“杀手”，它过于复杂且难以掌握，认为自己永远无法正确地集成它。因此，他们回避这个项目，并尽可能地避免它，希望问题能自行解决。

这两种观点都比较极端，事实的真相在于它们之间。第一组最好至少让具有良好 IPv6 经验的人来审查他们的 IPv6 策略、地址规划和安全概念。这就像在进行关键治疗前从医生那里获得第二意见。提前修正一些问题远比部署后再去修改或不得不与它共存多年要容易得多。如果审查确认一切正常，那也是一个很好的背景。第二组则只部分正确。虽然 IPv6 是 IPv4 的演进，许多方面是相同的，但在架构上有许多优势和新特性，例如地址架构。因此，建议不要回避，而是在所有团队深入进行网络设计、地址规划和安全概念的设计之前，花时间进行全面的教育。如果你拖延太久，并且在时间压力下完成这一切，你将没有时间去利用 IPv6 集成的机会。

无法避免的 bug 以及为何通用评估不太有用

IPv6 协议栈比大多数 IPv4 协议栈要年轻。虽然我们仍然在修复 IPv4 协议栈中的一些漏洞或寻找安全漏洞，但我们可以预期，在 IPv6 协议栈中这类问题会更为常见，因为我们没有多年操作经验以及多年的测试和修复积累。这导致了两个需要注意的事项。

其中之一是，你需要在规划中为与供应商修复 bug 留出足够的时间。一旦你开始实验室测试和试点项目，你将会发现这些 bug，供应商需要一些时间来提供解决方案。但我在许多 IPv6 战略讨论中听到的另一种说法是，人们会说：“哦，我们不使用这项技术，它不起作用，我们在实验室中测试过了。”

注意

不建议将你的设计和目标架构基于当前堆栈中的 bug。设计你的网络和应用程序，以最佳方式适应你的业务和需求，并期待你的供应商修复 bug。

与此密切相关的是，许多组织在没有 IPv6 战略的情况下，进行当前环境的 IPv6 能力评估（例如，“我能否启用 IPv6？”）。这意味着他们会根据功能可用性来设计，而不是先有一个支持业务的清晰战略，再确保有支持该战略的设备和应用程序。如果你希望一个支持你业务的目标架构，你就无法绕过先定义战略、创建详细的 RFC 要求，然后在采购要求中使用这些要求。

供应商战略与 RFC 要求

如前所述，如果你有提供出色 IPv4 服务的供应商（无论是产品、互联网接入、数据中心托管、外包服务，还是咨询服务），不要假设他们在 IPv6 方面也同样是最优秀的。你需要更详细地验证这一点。一些客户选择将 IPv6 集成作为重新评估未来几年供应商战略的一个契机。

以下几点应当考虑：

  • 你的供应商面临的挑战和你一样。只是他们应该走在前面，但现实是，他们中的许多人并没有。所以不要假设他们做到了，要亲自核实！

  • 一些客户认为他们的供应商知道该做什么，并且可以信任供应商的建议。大多数情况下，这种想法并不成立。你将面对这样的现实：你的采购团队（可能并不太懂技术，且对 IPv6 了解不多）将与供应商的销售人员坐在一起，而这些销售人员甚至不懂怎么拼写 IPv6。所以，除非你提出非常具体且有信息支持的想法和 RFC 要求，否则不能指望供应商能满足你的需求。

  • 在规划项目的初期，向你的战略供应商发送意向书，让他们知道你在可预见的未来需要专业的 IPv6 服务。供应商收到的这种意向书越多，他们就越快加速实施。毕竟，他们缺乏实施或功能丰富的主要借口是因为客户没有要求 IPv6。

  • 别忘了评估外包合同和 SLA 以考虑 IPv6 的需求和要求。

在评估供应商时，你应该关注以下几点：

  • 根据 RFC 列表检查技术特性。获取厂商提供的已实现 RFC 列表，与你的要求进行对比，然后在实验室中测试那些对你计划至关重要的功能是否按预期工作。记住，RFC 要求必须是针对设备的。IPAM 解决方案与防火墙有不同的要求。

  • 检查他们员工的 IPv6 知识水平。是否有一个人知道如何操作 IPv6？如果有的话，作为客户，他们的支持可能不足以满足你。确保他们在所有渠道（销售、工程、支持）都有足够的专业人员。

  • 确保他们在所有流程中也已经实现了 IPv6（升级流程以确保未来更新的一致性、事件管理等）。

  • 不要相信宣传册和事实表。请在实验室中进行测试。

如果没有这些步骤，你可能最终购买到不支持你的 IPv6 策略的产品，或者在部署过程中陷入困境，因为你突然发现所需的关键功能不被支持。正如你可能从其他 IT 项目中知道的那样，这会花费大量的时间和金钱，尤其是当关键的业务服务或其他 IT 项目依赖于此时。

注意

为了建立你的 RFC 要求列表，请使用 RFC 6434，“IPv6 节点要求。”除此之外，还有两个有用的模板可供参考：RIPE554 和 USGv6 by NIST。将其作为基础，并根据你的 IPv6 策略进行调整。

还有其他可能有用的文档，如 RFC 7084，“IPv6 客户边缘路由器的基本要求。”2014 年 4 月，关于更新 RIPE554 的讨论开始进行。所以，当你开始使用这些文档时，确保你使用的是最新版本。

一般设计指南

每个环境和业务都是不同的，因此 IPv6 策略也会有所不同。无法提供一种适用于每个组织的方案。然而，仍然有一些在大多数环境中都有效的通用策略，以下是一些建议：

  • 尽可能使用原生 IPv6，双栈仅在必要时使用（这可能需要很多年）。

  • 尽可能部署新的内部服务仅支持 IPv6。

  • 仅在必要时使用隧道，并且仅作为临时解决方案。有时建议稍等片刻，从一开始就直接使用原生 IPv6。

  • 如果你需要使用隧道，优先选择无状态隧道而非有状态隧道。

  • 不要使用 NAT，不要进行转换（除非被迫）。

  • 如果必须进行转换，还是优先选择无状态隧道而非有状态隧道。

  • 未来的网络是端到端的。

  • 扩展的地址架构允许新的安全概念（你可以考虑将服务信息嵌入地址中，以简化访问规则和操作）。

  • 根据新的地址架构调整并对齐你的安全概念。

  • 考虑新服务（监控、传感器、健康护理、车与车之间通信……根据行业不同而异）。许多新服务对地址的需求更高，并且有更强的移动性要求。

注意

越来越多的客户正在考虑尽快将其基础设施迁移到仅支持 IPv6，并将 IPv4 视为一种服务。这种以 IPv6 为中心的策略的主要优势是可以最大限度地降低成本。运营一个仅支持 IPv6 的网络比在双栈网络中并行维护两个协议的成本要低。

地址规划

一个好的地址规划是成功部署 IPv6 的基石，并能大大帮助简化网络运营和故障排除。但地址规划对大多数人来说都是一个挑战。我们都经过了很好的地址节约训练，这种训练高效到让它深入我们的身体细胞。在我们为 128 位地址创建有用的 IPv6 地址概念之前，我们必须克服这一反射动作。那么，规则是什么？如何为 IPv6 设计地址概念？这些是本节要讨论的主题，以提供一些指导。

在我们开始之前，我想回顾一下在第二章中提到的关于地址的一些内容，这些内容可能帮助你逐渐克服节约地址的本能反应，解放你的思维，摆脱有限的 IPv4 思维。请在你进行地址概念工作时，将其作为你每天的座右铭：

在第二章中，我展示了通常一个 ISP 会为其客户分配/32 的地址块，并且一个单独的/32 实际上比整个 IPv4 地址空间还要多（因为它有 32 位来定义子网，而每个/64 子网有 64 位用于接口 ID）。到 2013 年为止，全球大约已经分配了 13 万个/32 地址块，这意味着比整个 IPv4 互联网多出 13 万个地址空间。尽管这听起来极其庞大，但这仅占当前可用公共 IPv6 地址池（2000::/3）的 0.025%。因此，在设计 IPv6 地址规划时，我们可以稍微宽松一些。

引用 Vint Cerf 的话：

广阔的 IPv6 地址空间为重新审视“地址”这一概念提供了重要机会。IETF 只为当前使用分配了 IPv6 地址空间的 1/8，其余的 7/8 地址空间仍待分配。因此，我们可能可以以不同于拓扑端点的方式来解释 IP 地址空间的新片段。这正是目前在互联网发展过程中，集中关注 IPv6 未来的重要性。

好了，现在动动脑细胞，继续阅读吧。顺便提一句，本节大部分内容取自我的配套书籍，IPv6 规划（O’Reilly）。我在这里重复这些内容，是因为人们总是会问很多关于 IPv6 地址规划的问题。因此，我决定在本书的这一部分也涵盖地址规划的内容。有关规划的更多细节，请参阅配套书籍。

注意

本节假设您已经熟悉第二章中描述的 IPv6 地址架构的技术细节。

实践表明，在许多情况下，客户选择按逻辑分组地址范围，目的是：

  • 允许前缀聚合。

  • 简化访问列表和防火墙规则的配置、操作和处理。

  • 使地址具有可追溯性，以包含地址使用类型或使用地点的信息。

  • 使其具有可扩展性；为扩展（更多服务）和增长（更多位置和用户）创造足够的空间。

  • 允许高效的网络管理并简化操作。

有什么新变化？

在设计 IPv6 地址规划时，需要考虑三个主要差异：

  • 最明显的区别之一（除了地址长度）是我们不再需要可变长度子网掩码（VLSM）。IPv6 地址的前缀或网络部分应该始终是 64 位（/64）。即使是点对点连接呢？是的，即使是点对点连接（有些人选择更改这一规则——您将需要自己决定）。因此，从这个角度看，IPv6 地址更简单。不再需要猜测或错误配置子网掩码。VLSM 为管理 IPv4 地址空间增加了很多复杂性。

  • 前面的规则还与以下内容相关：我们不再需要根据子网中的设备数量来调整子网的大小（换句话说，不再需要进行地址节省的操作）。每个子网都可能拥有 2⁶⁴个设备。每个子网中的设备数量将由交换机的容量决定，因此请咨询您的供应商以了解可能的容量。

  • 在 IPv6 中，地址被分配给接口。因此，IPv6 地址标识的是接口，而不是主机。而且，在许多情况下，接口会有多个地址，并根据策略或默认地址选择规则选择地址来发起连接。

请抵制为子网使用更大掩码（如/96）的诱惑，以便节省地址空间。虽然标准并不禁止这样做，但遵循/64 边界可以使您的地址规划面向未来。更改此掩码可能会在未来引发许多问题，因为所有开发都是基于/64 掩码的。例如，SLAAC（无状态地址自动配置）在非/64 掩码下无法正常工作。可能还有许多其他流程或服务在非标准子网掩码下会失败。IPv6 为您提供了足够的地址空间！优化它以实现高效管理。

一旦熟悉了 IPv6 地址架构，请列出您如果可以从头开始设计，想要更改的 IPv4 地址规划事项，然后开始设计您的 IPv6 地址方案。

组成部分如下：

  • 回顾您当前的 IPv4 地址规划及其运营经验教训。

  • 识别当前 IPv4 规划中的约束和不一致之处。

  • 根据目标架构识别您的需求。

  • 创建不同的地址规划场景以解决这些问题。

  • 与所有 IT 团队进行内部评审和讨论。

  • 将最佳选项带入实验室，包括您的配置工具，并测试常见的操作场景。

当定义场景时，您需要在以下两个选择之间找到一个良好的平衡：

专注于路由聚合

通过将高位分配给拓扑结构（区域、站点）来强调路由聚合，从而减少核心路由表中的路由数量。

专注于策略聚合

通过将高位分配给与服务或安全相关的信息（服务、区域）来强调策略聚合，这减少了策略的数量，最小化了用户错误的风险，并简化了管理。

一般来说，将最常见和最重要的信息优先放在高位，并为当前和预见中的选项分配足够的空间。这些选项可以是新站点、新服务、新用户等。

为了构建一个有用的地址规划，请考虑以下几点：

  • 基于拓扑结构的前缀聚合。

  • 基于您的服务和安全概念的策略聚合。

  • 子网一致性（不要包括地址节省机制；关注操作简便性）。

  • 使用地址类型（仅全球地址或全球地址加唯一本地地址）。

  • 始终为子网和点对点链路分配一个/64 前缀；无需进行主机规划。

  • 如果您有多个位置，并且它们有本地互联网接入，建议为每个位置分配至少一个/48 的前缀。

  • 如果您是一个全球性组织，考虑为风险缓解目的使用区域地址分配（RIPE、APNIC、ARIN 等）。

  • 尽可能遵守四位字节边界（一个四位字节是 4 个二进制位）。

  • 使用配置机制和工具（DHCPv6、SLAAC、IPAM/DDI）。

  • 不要仅仅为了结构而创建结构；只有真正相关的信息才应该被嵌入。

  • 避免直接映射您的 IPv4 地址规划，因为这会延续遗留问题，并限制利用 IPv6 地址空间资源的能力。

  • 安全方面。

  • 增长（网络、用户、服务）。

  • 新服务带来的地址需求增加（监控、传感器、管理等）。

您的地址规划上限是您已获得的范围（根据公司规模是/48 或/32）。您的下限是您必须分配给子网的/64。所以，在这个空间内，您可以定义自己的结构。首先识别您当前的地址库存和对可预见未来的清晰需求，然后使用剩余的位来支持增长。

注意

不要忘记定义 IPv6 地址空间分配的清晰流程和规则。

图 9-1 展示了这样一个高级场景的示例。

高级地址规划示例图 9-1. 高级地址规划示例

在这个例子中，选择了基于服务和基于拓扑的设计组合。第一个四位（前 4 位）被用来区分 16 种服务类型，然后可以在高级别上为其分配特殊规则。接下来的四位用于区分每种服务类型下的 16 个应用程序。第三个四位用于区分 16 个超级区域，每个超级区域可以有 4,096 个位置（12 位）。每个位置都会分配一个 /56 前缀，并且仍然可以创建 256 个子网。这个地址规划是否合适完全取决于网络、服务目录和组织的安全概念。它只是一个示例，旨在激发你的思考。服务级别方法的主要目标是使安全策略设计和操作更简单。

在各个方面，你需要整合非常庞大的 IPv6 地址空间。这一点再强调也不为过。因此，例如，在子网一致性方面，完全没有必要节省地址空间。

注意

为了操作方便和简化管理，保持同一类型位置的子网大小一致，无论那里有多少用户。虽然这是最佳做法，但一开始可能会感到不适应。如果你为未来的扩展留出地址空间，同样也适用这个规则。一个好的规则是：如果你的单元没有痛苦，那么你的规划还不够大。

全局地址与 ULA

如前所述，IPv6 接口通常可以拥有多个地址。你的地址设计的一部分是决定使用哪些地址类型。具体来说，你有两个选择：一般使用全局 IPv6 地址（GUA），或在内部使用唯一本地地址（ULA）。ULA 在 RFC 4193 中有定义，前缀为 fd00::/8。它们类似于 IPv4 中的 RFC 1918 私有地址，这意味着它们是可路由的，但应仅限于内部使用，绝不应路由到互联网。例如，它们可以用于内部部署或在尚未分配全局 IPv6 地址空间时构建实验室。

RFC 1918 概念与当前如何使用这些私有 ULA 地址之间有一个很大的区别。使用 ULA 并不意味着你需要 NAT（网络地址转换）来访问互联网。因为 IPv6 接口设计时就支持多种地址类型，所以需要互联网连接的接口将简单地获取一个全球 IPv6 地址，除了 ULA 地址。当连接到内部服务器时，接口将使用其 ULA 地址；当连接到互联网时，则使用全球 IPv6 地址。RFC 6724 定义了默认的地址选择规则来处理这个问题。在较大的网络中，你将拥有关于源地址和目标地址选择规则的政策。所以，采用这种设计时，应该无法从外部访问的内部服务器和数据库只会配置 ULA 地址。如果你想在内部仅使用 ULA 地址，也可以使用 NPTv6（网络前缀转换），该技术在第七章的 NAT 部分中有描述。

注意

不需要像 IPv4 中使用私有地址时那样将 ULA 地址与 NAT 结合使用。在 IPv4 中，NAT 需要将多个地址映射到一个或少数几个地址。而在 IPv6 中，需要访问内部服务和互联网的主机只需获取两个地址，一个是 ULA 地址，另一个是 GUA（全球地址）。

在选择是否使用 ULA 或选择全球地址时，这两种方法都有优缺点，并且围绕它们有很多讨论。由于部署较早，目前可供参考的运营经验不多。从技术角度来看，你可以做出任意选择——你需要自己决定。

以下是一些考虑事项：

  • ULA 使你在内部网络中独立于全球前缀，如果需要重新编号网络，这将非常有利。在这种情况下，你的所有内部系统和通信都不会受到影响。如果你拥有 PI（提供商独立）地址空间，这也不是问题。

  • ULA 为你的内部基础设施增加了一层安全性，因为带有关键数据的服务器和数据库无法从外部访问。显然，你仍然需要防火墙来保护系统，但 ULA 提供了额外的保护。有些组织通过保留一部分全球前缀并将其作为仅限内部使用的前缀来实现相同的目标，在边界两侧进行屏蔽。

  • 知道你的一些全球地址的攻击者无法推导出内部系统的地址。

  • 不应将 ULA（唯一本地地址）与 NAT（网络地址转换）一起使用，因此 NAT 不是一个问题。需要访问互联网的系统可以获得一个全球 IPv6 地址，除此之外还可以使用 ULA 地址。这就是 IPv6 每个接口多个地址架构的优势。

现在，是否使用 ULA（独立的本地地址）取决于你。它们可能在孤立的领域中非常有用，比如制造生产线或数据中心之间的备份流量。许多人决定，在无限的 IPv6 地址空间下，既然他们终于可以为所有系统分配全球地址，他们希望选择这个简单的选项——通过防火墙保护内部系统，并且享有仅需管理一个前缀的优势。对于那些决定同时使用全球地址和 ULA 的人，我希望 IPAM（IP 地址管理）供应商能够足够聪明，开发出能够管理多个前缀的系统，并将子网设计导入 IPAM 解决方案中以便于管理。无论如何，你可能会为这两个前缀选择相同的地址规划。而你的第三个选择是，你可以选择从全球前缀中选一个特定的前缀，仅分配给内部系统，并阻止该前缀与外界的通信。即使使用 ULA，你也需要在边界上专门阻止它们，因为它们不应被路由到互联网。

一般考虑

每当你将某些内容从 IPv4 地址计划转换到 IPv6 地址计划时，请确保不要将 IPv4 中的限制复制到新的概念中。你是在为未来的原生 IPv6 网络创建一个地址概念，而双栈网络只是一个过渡状态——尽管它可能会存在几年。但一旦你开始运行原生的 IPv6-only 网络，你将希望享有几乎无限的地址空间自由，而无需重新编号网络。

长期以来，建议互联网服务提供商（ISP）从其 RIR（区域互联网注册机构）获取一个/32 前缀，而组织和终端站点从其提供商处获取一个/48 前缀，或者将/48 作为 PI 空间。RFC 6177 将终端站点推荐的前缀大小改为不再统一为/48。它指出，“一个适用于所有情况的/48 推荐前缀对于广泛的终端站点范围来说过于简单，不再建议作为单一默认选项。”该 RFC 声明，确定终端站点最佳前缀大小的责任在于运营社区。这引入了一些新的考虑因素。当默认前缀为/48 时，换服务提供商或来自不同提供商的分配总是有相同的前缀边界。而在新的政策下，终端站点可能需要从更大的前缀迁移到更小的前缀，这意味着需要合并子网。如果你有一个/48 并且首先使用低位的位（如果网络大小允许的话），你可以为此做好准备。似乎许多提供商通常为较小站点分配/56 或/52 的前缀。这条规则不适用于大企业；它们将始终获得/48 或更大的前缀。根据 RFC 6177，即使是家庭用户也应获得比/64 子网更大的地址空间。市场上服务的发展表明，未来的家庭网络将有多个子网（智能建筑）。

关于子网大小，规范中并没有禁止你改变/64 边界。但我不推荐这样做，因为这样做会破坏 IPv6 的许多其他功能，应用程序和进程默认假设/64 子网大小。这包括邻居发现（ND）、安全邻居发现（SEND）、隐私扩展、部分移动 IPv6 规范、独立协议的稀疏模式多播（PIM-SM）与嵌入式 RP、通过 IPv6 中介进行的站点多宿（SHIM6）等机制。而且，未来可能还会有更多假设/64 边界的功能。如果你改变了这一点，所有这些功能都会受到影响。

注意

创建比/64 更长的前缀的唯一好处是节省地址空间。请记住我们的原则：我们不再需要节省空间。相比管理非标准子网前缀的麻烦，节省空间的好处是微不足道的。

尽管如此，你仍然可以选择使用来自接口 ID 部分的高位来表示特定的系统、服务或网络，以便更容易识别这些 ID。

在分组位时，一个良好且有帮助的实践是始终在 4 位边界上进行分组（nibble）。这样，解析地址时会更加容易，因为 4 个位表示一个十六进制数字。

让我们通过一些例子来激活大脑。你可以按位置对子网进行分组，然后再按服务或使用类型进行分组，或者反过来（先按服务类型，再按位置）。

例如，对于前缀2001:db8:1::/48，你有 16 位可用于子网划分。你可以按以下方式进行子网划分（L=位置，S=服务，F=空闲）：

Location first:       2001:db8:1:LLLLSSSS FFFFFFFF::/64
Service type first:   2001:db8:1:SSSSLLLL FFFFFFFF::/64

你选择的选项取决于你的主要目的是否是优化路由，如果是的话，你应该首先选择位置标识符；或者你是否希望优化安全规则和访问控制列表（ACL，通常基于特定服务的过滤器），如果是的话，你应首先选择服务标识符。在某些情况下，组织只为某个位置分配子网，而该位置进一步管理前缀并创建自己的地址规划。在这种情况下，你也应该首先选择位置标识符。

或者，你可能希望将这两种选项结合使用。你可能有一些特定的服务需要在较高层次上进行过滤，因此你会将这些服务的标识符放在子网范围的最高位，接下来是位置位，以优化网络内的路由，最后是识别更多服务的位。

在这个示例中，使用 4 个比特位表示位置和服务类型，你可以创建 16 个位置和服务（2⁴）。你需要根据你想要表示的位置和服务的数量来调整这个方案（并为未来的扩展预留足够的空间）。有时组织会在 VLAN 编号方案中包含位置或服务描述。你也可以在 IPv6 地址规划中反映这一点，将 12 位的 VLAN ID 包含在前缀中。你可以使用十进制表示法（省略 A-F）或将其转换为十六进制表示法。

这些都是关于你创意规划的一般性思路。花时间仔细设计你未来的地址规划，反复讨论所有可能的选项，让许多人，包括外部顾问，审阅你的地址概念提案，以挑战你的计划，并反复检查，直到感觉合适为止。地址设计是下一代网络的基础。如果没有做好，并且在部署项目期间不得不进行更改，这将增加成本并延迟项目进度。从长远来看，如果你使用了一个次优的地址设计，运营成本可能会不必要地高。

接口 ID 的配置

接口 ID 的定义取决于你选择的 IP 地址管理过程。你可以选择无状态地址自动配置（SLAAC），其中接口根据 MAC 地址生成接口 ID（RFC 4291 定义的 EUI-64 格式），或者选择隐私选项（如 RFC 4941 所定义），其中接口 ID 是随机生成并定期更改的。在较新的操作系统中，微软使用通过随机标识符创建的稳定接口 ID。你可以使用 DHCPv6，并像在 IPv4 中一样分配地址。通过 DHCPv6，该服务可能提供定义接口 ID 的不同选项。为了最佳地保护你的主机，你可能不希望从低的接口 ID 开始并按顺序编号接口。相反，你可能希望使用随机的接口 ID，因为你的接口 ID 越随机和分散，就越难以扫描。

如果你有一个全球 IPv6 前缀并且在内部使用 ULA 前缀，你可能希望为全球前缀使用隐私选项。这样，访问互联网的用户就不容易被追踪，因为他们的接口 ID 会定期更改。对于 ULA 前缀（或在边界处过滤的全球前缀的内部部分），最好分配固定的地址，以便于管理、故障排除、安全性和日志记录。同样，这也取决于供应商是否会提供帮助处理这一问题的 IP 地址管理解决方案。

注意

有建议不要使用基于硬件的接口 ID。微软已经使用一个通过随机标识符创建的稳定接口 ID。RFC 7217 定义了一个不基于硬件标识符的稳定接口 ID。有关更多信息，请参阅无状态地址自动配置（SLAAC）章节。

你从哪里获得地址空间？

IANA（互联网号码分配局）负责全球 IP 地址系统的协调工作，以及用于路由互联网流量的 ASN（自治系统号）。

RIR（区域互联网注册机构）从 IANA 获取其 IP 地址空间。全球有多个 RIR 来分配它们区域内的地址空间。图 9-2 展示了全球层级结构、RIR 和它们所服务的区域。

区域互联网注册机构图 9-2. 区域互联网注册机构

RIR 还为 LIR（本地互联网注册机构）、NIR（国家互联网注册机构）、ISP（互联网服务提供商）提供地址空间，在某些情况下还直接为最终客户提供地址空间。

不同地区的地址政策略有不同。ISP 和客户必须从他们的 RIR 获取所在地区的政策信息。每个 RIR 都有一个网站，提供关于地址空间和政策的所有信息。

注意

所有 RIR 的链接可以在IANA 的网站上找到。

客户有几种申请 IPv6 地址空间的选项。

目前有PA 空间（提供商聚合）和PI 空间（提供商独立）。PA 空间面向 ISP，提供互联网连接给多个最终客户。为了获得 PA 空间，通常需要成为 RIR 的会员，并支付年费。标准分配大小通常在 /29 到 /32 范围内。然后，提供商将网络分配给他们的客户，通常在 /48 或 /56 范围内。ISP 分配给客户的 PA 空间不能转移到另一个 ISP，因此在更换 ISP 时，需要重新编号（或者使用 NPTv6 前缀转换）。有关分配建议，请参阅 RFC 6177，下面的章节中有描述。

PI 空间面向那些不能或不愿使用其提供商 PA 空间的最终用户。这不需要会员身份，但每个前缀需要支付年费。PI 空间归最终用户所有，并且可以带到下一个 ISP。每一个使用 PI 前缀的互联网地址都会出现在全球路由表中，影响全球所有的路由器。最初，在 IPv6 的早期阶段，计划是不分配 PI 空间，以保持路由表的小巧。但事实证明，这一政策在实践中无法维持。

因此，作为最终客户，你有以下几种选择：

  • 来自本地提供商的 PA 空间

  • 来自 RIR 的 PA 空间（需要会员资格）

  • 来自 RIR 的 PI 空间（年费）

注意

你可以从RIPE获取有关其 IPv6 地址分配和分配政策的官方信息。

再次提醒，本文件编号有效期至 2014 年 3 月。之后你可能需要查看是否有更新版本。

你将获得多少空间？

地址分配规则仍在进行中，可能会有所变化。如何使用地址空间的最新更新内容请参考 RFC 6177，《IPv6 地址分配给终端站点》。它包含了如何进一步划分地址空间的建议。它软化了先前版本中的规则（即 RFC 3177），其中家庭网络以及小型和大型企业应获得一个/48 地址块。如前所述，在新版本中，这些规则已经调整，因为前缀大小的具体分配应由操作社区来决定。

RFC 进一步指出：“IPv6 的一个重要目标是显著改变默认和最小的终端站点分配，从‘单个地址’到‘多个网络’，并确保终端站点可以轻松获得地址空间。”

如果你负责分配地址或为你的网络请求地址，那么可以使用 RFC 6177 中关于地址分配的以下规则：

  • 地址管理的一个关键原则是，终端站点必须始终能够为其实际和计划的使用获得合理数量的地址空间，并且是按年而非按月的时间范围。实际上，这意味着至少需要一个/64 地址块，在大多数情况下需要更多。必须避免的一个特定情况是，终端站点由于无法获得足够的地址空间而被迫使用 IPv6 到 IPv6 的网络地址转换（NAT）或其他繁琐的地址节省技术。

  • 终端站点应能够轻松获得足够的地址空间来编号多个子网（即大于单个/64 的地址块），并支持长期（例如十年或更长时间）合理的增长预测。

  • 默认分配大小应考虑到终端站点未来可能需要多个子网的可能性，并避免 IPv4 实践中频繁且持续的申请额外小块地址空间的情况。

  • 尽管一个/64 地址块（理论上）可以为几乎无限数量的设备提供地址，但站点应分配足够的地址空间，以便能够适当划分子网，而不是被迫使用地址节省技术，如使用桥接。

  • 将一个较长的前缀分配给一个终端站点，相较于该终端站点已分配的现有前缀，可能会增加终端站点的运营成本和复杂性，且对任何人都没有足够的好处。

  • 管理和委派 ip6.arpa 下的反向 DNS 树时，应充分考虑在 nibble 边界与非 nibble 边界之间的操作性问题。

  • 家庭网络用户应当接收到多个子网。

一个获得/48 前缀的站点有 16 位用于子网划分，这允许创建 65,536 个子网（默认的 IPv6 子网大小为/64）。在特殊情况下，一个非常大的企业可以申请更短的前缀。

注意

你的 IPv6 地址规划是你未来网络的基石，应当支持多年的增长，具有可持续性，并且不应当是支离破碎的。所以，不可能绕过这一点，必须坐下来做作业，弄清楚你到底需要多少空间。然后去申请它。

我与来自不同规模的许多客户进行了交谈，从中小型企业到大型企业都有。我不断听到类似这样的说法：“哦，这就是我们拥有的[某种前缀大小]。我们会看看如何适应它。”请不要这么做。现在你可能认为这比你以前使用 IPv4 时拥有的更多，所以你可能能以某种方式适应它。但再说一遍，请不要这么做；你（或者将来需要运营你网络的人）可能会对这个感到非常不满，并且在头痛和运营上的劣势上付出很大的代价。

通过按照本节所描述的方式定义地址规划，你将能够知道自己究竟需要多少地址。有些标准分配可以很容易获得，不需要太多文档。但你不知道这些分配是否足够支持你的目标架构。如果你做好功课，提出一个可持续且良好的规划，发现你需要更多的地址，你可以获得它；这只需要稍微多一点的工作。但这只是开始时的额外工作。如果你回避这点，基于过小的分配来规划地址，你将在未来为此付出代价。因为重新设计和重做会比一开始就做好规划花费更多的精力。

使用 IPv6 的多宿主连接

多宿主连接是指一个主机或站点可以通过不同的 IP 地址访问。一个多宿主连接的主机有多个全局 IP 地址。这些地址可以来自一个或多个不同的提供商，并且它们可以分配给主机上的一个或多个接口。一个多宿主连接的站点通过来自一个或多个不同提供商的多个全局 IP 地址连接到互联网。

配置多宿主连接的主要原因如下：

冗余

当链路失败时，连接可以通过备用链路继续保持。

负载均衡

提供更高的吞吐量，因为流量在两个或更多链路之间进行负载均衡。

成本

可能希望使用多个提供商——例如，某个提供商可能在某些类型的服务上提供更好的选择。

IPv6 的自动配置功能支持更容易地维护多宿主连接场景，因为设备在识别网络前缀时更为灵活，并且可以根据路由器广告配置多个 IPv6 地址。

在常见的 IPv4 多宿主接入方法中，站点的本地前缀作为独立的路由前缀宣布到域间路由系统中，并传播到路由系统的顶层层次结构。如果站点的地址空间与提供商无关，这种方法工作得很好。但即使这种方法覆盖了多宿主接入的多数需求，它也不具备可扩展性。

因此，多宿主接入是工作组中一个活跃讨论的话题。目标是找到能够提供多宿主接入，而不涉及可扩展性和传输问题的解决方案。一种思路是将节点的标识与位置分开。目前，一个 IP 地址包含了两部分信息，前缀标识位置，IID 标识节点。对此的一个方法是 LISP，详见第七章。在我们等待并希望能找到一种优雅的多宿主接入架构时，目前 IPv6 的多宿主接入与 IPv4 采用相同的方式进行。

引入成本

有些人认为引入 IPv6 的成本过高，因此他们甚至没有开始考虑这个问题。另一些人则只关心它会花费多少成本。下一节将介绍需要考虑的方面以及关于 IPv6 商业案例的一些思考。

注意事项

Gartner 表示，IPv6 的集成大约占年度 IT 预算的 6%，并按迁移年数分摊。在我们从高层次视角仔细审视这一点的几个案例中，这一估算非常准确。完成迁移后的持续成本估计约为 IT 预算的 1%。

硬件和操作系统

在为 IPv6 进行规划并利用更新周期时，硬件升级的成本并不高昂。在许多情况下，IPv6 并不是硬件的一部分，可以作为操作系统的一部分或软件升级来安装。大多数操作系统和应用程序都包含 IPv6，且无需额外费用。如果 IP 功能完全通过硬件实现，或者系统软件无法升级，那么必须更换硬件以支持 IPv6。然而，如果您提前进行规划，这通常可以通过下一次常规生命周期的升级来完成，因此不会产生额外的成本。正如我们的案例研究所示，这一点得到了已经部署 IPv6 的组织的确认。

软件

我们在应用开发中的 IPv6 章节中介绍了 IPv6。如今，许多常见的应用程序已经支持 IPv6，或者将在下一个重大版本升级中支持 IPv6。在这种情况下，您可以通过提前规划并利用应用程序的常规生命周期来限制软件的成本。对于专有和自开发的应用程序，情况需要逐一分析。

简单地迁移一个应用程序，确保它能在 IPv6 传输下同样运行良好。创造性的迁移应用程序可能包括使用 IPv6 的高级特性，从而扩展应用程序的灵活性和功能性。这甚至可以被视为引入基于新技术的先进下一代服务的成本，而不仅仅是引入 IPv6 的成本。

教育

每一次技术升级都需要教育：对于开发人员、供应商、服务提供商以及组织中的基础设施和系统运营商来说，都是如此。对于家庭用户来说，应该由他们的 ISP 来简化过渡过程。

根据工作职责进行精心规划的教育项目是必不可少的，并能大大促进 IPv6 的顺利引入。对于系统管理员来说，学习所需的时间和精力与维持 IPv4 基础设施的成本是相当的。我们习惯于不断整合新技术以保持网络的先进性。过去，我们必须引入 DHCP、NAT 和 VPN，并且成功掌握了这些技术。一些人曾在双栈网络中工作，掌握了 IPX（Novell）与 TCP/IP 的共存。现在我们将引入 IPv6，而这项挑战并不比以前更大。并且，这值得投入精力、时间和资金，因为从长远来看，维护 IPv6 网络的成本将低于维护 IPv4 网络的成本。那些对 IP 有深入理解并且掌握了上述技术的人，将不会有任何问题掌握 IPv6。

在进行详细设计并进入生产阶段之前，花足够的时间了解 IPv6 是非常值得的。IPv6 中有许多新概念和新可能性，我们需要一些时间来熟悉这些内容，学习如何最好地利用它们，并将我们所学的知识整合到规划中。如果你按照推荐的方式早早开始做实验和实践测试，你将在实际工作中建立自己的理解和经验。

注意事项

当我与已经设计和部署了 IPv6 的组织交流时，我问：“最大的风险是什么？”，他们的回答通常是“缺乏教育”。早期且全面的教育让你能够充分利用 IPv6 所提供的机会。

规划

集成的最重要方面是规划。这里同样适用这个规则。扩展基础设施以保持其最先进的状态总是需要规划，并应被视为一种投资。我们不再规划 IPv4 的下一次扩展，而是将规划 IPv6 的集成。

规划需要网络架构师和系统工程师，他们必须对 IPv4 和网络概念有良好的理解。他们首先需要的是深入的 IPv6 教育和一个 IPv6 测试环境。规划的重点不应该是如何在 IPv6 上提供相同的服务。它应该包括理解 IPv6 的新特性，并利用这些特性来创建新的架构、安全性、移动性和管理概念。特别是在 IPv6 地址设计和 IPv6 安全设计方面，组织最好花费足够的时间，因为这两者将为你的网络奠定多年的基础。拥有良好的地址和安全设计将节省大量的成本和麻烦。事实上，IPv6 集成的机会就在这里。

注意

正如实践所示，要克服 IPv4 思维并学会利用 IPv6 的优势需要一些时间。

提前规划 IPv6 的引入会更加顺利且便宜。逐步集成是最佳方案，因为它可以给你时间在实践中学习并逐步整合。逐步集成之所以可行，是因为有许多可用的过渡机制。

其他成本

最高的成本往往出现在你等待的时间过长时。你等待的时间越长，投入到维护和扩展 IPv4 基础设施中的投资就越多。这些钱和精力实际上是你在一个即将淘汰的技术上投入的。你可能需要为 IPv4 构建应急方案（例如，NAT），这些方案日后会使 IPv6 的引入更加复杂。

没有理由拆除一个已经能够满足所有需求的高效网络，但一旦你需要投入资金修复或扩展 IPv4 基础设施时，你应该停下来思考一下 IPv6 是否可以作为替代方案。如前所述，将 IPv6 作为评估标准列入所有 IT 采购清单，特别是对于那些生命周期超过两年的产品，是一个明智的选择。你可能明天不打算启用 IPv6，但或许明年你会考虑启用。如果你的设备和软件已经准备好，那么当时机来临时，你可以无额外成本地启用它。未来在部署新服务时，考虑从一开始就只部署 IPv6。为什么要在 IPv4 上测试并使其工作，如果你迟早还得迁移到 IPv6 呢？显然，这需要一个双栈基础设施。

另一个成本因素是，如果出现基于 IPv6 高级功能的业务关键应用。如果你的基础设施已经准备好支持 IPv6，你可以以适中的成本引入该应用。如果同时你还需要处理过渡到 IPv6 的过程，这可能会带来显著的成本，并使你当前的基础设施面临风险（此外还可能带来一些头痛和失眠的夜晚）。

你已经读完了本书。现在你对 IPv6 规范的要点有所了解，并且掌握了一些过渡机制和规划过程的指南。接下来你需要通过建立实验室和测试，并亲自使用它，来积累经验。祝你玩得开心！

参考文献

下面是本章提到的最重要的 RFC 和草案的列表。有时我还会为你提供一些额外的相关 RFC，供你个人进一步学习。

RFCs

  • RFC 2185，《IPv6 过渡的路由方面》，1997 年

  • RFC 2529，《在没有显式隧道的情况下通过 IPv4 域传输 IPv6》，1999 年

  • RFC 2663，《IP 网络地址转换（NAT）术语和考虑事项》，1999 年

  • RFC 3022，《传统 IP 网络地址转换器（传统 NAT）》，2001 年

  • RFC 3053，《IPv6 隧道代理》，2001 年

  • RFC 3056，《通过 IPv4 云连接 IPv6 域》，2001 年

  • RFC 3493，《IPv6 的基础套接字接口扩展》，2003 年

  • RFC 3542，《IPv6 的高级套接字应用程序接口（API）》，2003 年

  • RFC 3582，《IPv6 站点多宿架构的目标》，2003 年

  • RFC 3715，《IPsec 网络地址转换（NAT）兼容性要求》，2004 年

  • RFC 3789，《当前部署的 IETF 标准轨道和实验文档中的 IPv4 地址调查简介》，2004 年

  • RFC 3790，《当前部署的 IETF 互联网领域标准轨道和实验文档中的 IPv4 地址调查》，2004 年

  • RFC 3791，《当前部署的 IETF 路由领域标准轨道和实验文档中的 IPv4 地址调查》，2004 年

  • RFC 3792，《当前部署的 IETF 安全领域标准轨道和实验文档中的 IPv4 地址调查》，2004 年

  • RFC 3793，《当前部署的 IETF 子 IP 领域标准轨道和实验文档中的 IPv4 地址调查》，2004 年

  • RFC 3794，《当前部署的 IETF 传输领域标准轨道和实验文档中的 IPv4 地址调查》，2004 年

  • RFC 3795，《当前部署的 IETF 应用领域标准轨道和实验文档中的 IPv4 地址调查》，2004 年

  • RFC 3796，《当前部署的 IETF 操作与管理领域标准轨道和实验文档中的 IPv4 地址调查》，2004 年

  • RFC 3901，《DNS IPv6 传输操作指南》，2004 年

  • RFC 4029，《在 ISP 网络中引入 IPv6 的场景和分析》，2005 年

  • RFC 4038，《IPv6 过渡的应用方面》，2005 年

  • RFC 4057，《IPv6 企业网络场景》，2005 年

  • RFC 4177，《IPv6 多宿的架构方法》，2005 年

  • RFC 4192，《没有“标志日”的 IPv6 网络重新编号程序》，2005 年

  • RFC 4213，《IPv6 主机和路由器的基本过渡机制》，2005 年

  • RFC 4215，《第三代合作伙伴计划（3GPP）网络中的 IPv6 过渡分析》，2005 年

  • RFC 4218，《与 IPv6 多宿解决方案相关的威胁》，2005 年

  • RFC 4219，《IPv6 多宿(MULTI6)开发者应考虑的事项》，2005 年

  • RFC 4241，《IPv6/IPv4 双栈互联网接入服务模型》，2005 年

  • RFC 4472, “IPv6 DNS 的操作考虑事项与问题”，2006 年

  • RFC 4554, “在企业网络中使用 VLAN 进行 IPv4-IPv6 共存”，2006 年

  • RFC 4659, “IPv6 VPN 的 BGP-MPLS IP 虚拟专用网络（VPN）扩展”，2006 年

  • RFC 4779, “宽带接入网络中的 ISP IPv6 部署情景”，2007 年

  • RFC 4787, “单播 UDP 的网络地址转换（NAT）行为要求”，2007 年

  • RFC 4798, “通过 IPv6 提供商边缘路由器（6PE）使用 IPv4 MPLS 连接 IPv6 岛屿”，2007 年

  • RFC 4852, “IPv6 企业网络分析——IP 层 3 重点”，2007 年

  • RFC 5181, “在 802.16 网络中的 IPv6 部署情景”，2008 年

  • RFC 5375, “IPv6 单播地址分配考虑”，2008 年

  • RFC 5569, “在 IPv4 基础设施上快速部署 IPv6（6rd）”，2010 年

  • RFC 5902, “IAB 关于 IPv6 网络地址转换的思考”，2010 年

  • RFC 6036, “IPv6 部署的新兴服务提供商情景”，2010 年

  • RFC 6052, “IPv4/IPv6 转换器的 IPv6 地址分配”，2010 年

  • RFC 6144, “IPv4/IPv6 转换框架”，2011 年

  • RFC 6146, “有状态 NAT64：从 IPv6 客户端到 IPv4 服务器的网络地址与协议转换”，2011 年

  • RFC 6147, “DNS64：从 IPv6 客户端到 IPv4 服务器的网络地址转换 DNS 扩展”，2011 年

  • RFC 6164, “在路由器间链路上使用 127 位 IPv6 前缀”，2011 年

  • RFC 6177, “IPv6 地址分配到终端站点”，2011 年

  • RFC 6180, “IPv6 部署期间使用 IPv6 过渡机制的指南”，2011 年

  • RFC 6250, “IP 模型的演变”，2011 年

  • RFC 6269, “IP 地址共享的问题”，2011 年

  • RFC 6296, “IPv6 到 IPv6 网络前缀转换”，2011 年

  • RFC 6302, “面向互联网服务器的日志记录建议”，2011 年

  • RFC 6434, “IPv6 节点要求”，2011 年

  • RFC 6459, “IPv6 在第 3 代合作伙伴项目（3GPP）演进分组系统（EPS）中的应用”，2012 年

  • RFC 6540, “所有支持 IP 的节点必须支持 IPv6”，2012 年

  • RFC 6586, “来自 IPv6-only 网络的经验”，2012 年

  • RFC 6724, “互联网协议版本 6（IPv6）的默认地址选择”，2012 年

  • RFC 6866, “企业网络中静态地址 IPv6 主机重新编号的问题声明”，2013 年

  • RFC 6879, “IPv6 企业网络重新编号情景、考虑因素及方法”，2013 年

  • RFC 6883, “面向互联网内容提供商和应用服务提供商的 IPv6 指南”，2013 年

  • RFC 6921, “超光速（FTL）通信的设计考虑”，2013 年 4 月 1 日

  • RFC 7021, “评估载波级 NAT 对网络应用的影响”，2013 年

  • RFC 7050, “IPv6 地址合成中使用的 IPv6 前缀发现”，2013 年

  • RFC 7059, “IPv6-over-IPv4 隧道机制的比较”，2013 年

  • RFC 7066, “第三代合作伙伴项目（3GPP）蜂窝主机的 IPv6 应用”，2013 年

  • RFC 7084, “IPv6 客户边缘路由器的基本要求”，2013 年

  • RFC 7094, “IP 任播的架构考虑”，2014 年

  • RFC 7098, “在服务器集群中使用 IPv6 流标签进行负载均衡”，2013 年

  • RFC 7123, “IPv6 对 IPv4 网络的安全影响”，2014 年

  • RFC 7136，“IPv6 接口标识符的重要性，”2014 年

  • RFC 7157，“没有网络地址转换的 IPv6 多宿主，”2014 年

  • RFC 7168，“茶漏设备的超文本咖啡壶控制协议（HTCPCP-TEA）”，2014 年 4 月 1 日

  • RFC 7217，“一种使用 IPv6 无状态地址自动配置（SLAAC）生成语义上不透明的接口标识符的方法，”2014 年

草案

草案可以在 www.ietf.org/ID.html 找到。要定位草案的最新版本，请参考 datatracker.ietf.org/public/pidtracker.cgi。你可以输入草案名称（不需要版本号），系统将显示最新版本。如果草案没有显示，可能已经被删除。如果它已经发布为 RFC，RFC 编号将会显示。tools.ietf.org/wg 也是一个非常有用的网站。有关标准化过程、RFC 和草案的更多信息，请参见 附录 A。

这里列出了我在本章中引用的草案，以及与本章主题相关的有趣草案：

“使用唯一本地地址的建议”

draft-ietf-v6ops-ula-usage-recommendations-02

“地址和端口映射与封装（MAP）”

draft-ietf-softwire-map-10

“使用转换的地址和端口映射（MAP-T）”

draft-ietf-softwire-map-t-05

“DHCPv6 配置软线地址和端口映射客户端的选项”

draft-ietf-softwire-map-dhcp-07

“轻量级 4over6：DS-Lite 架构的扩展”

draft-ietf-softwire-lw4over6-08

“通过 IPv6 实现 IPv4 残余部署——一种无状态解决方案（4rd）”

draft-ietf-softwire-4rd-08

“3GPP 移动设备的 IPv6 配置文件”

draft-ietf-v6ops-mobile-device-profile-07

“NAT64 部署选项和经验”

draft-ietf-v6ops-nat64-experience-10

“IPv6 数据中心操作指南”

draft-ietf-v6ops-dc-ipv6-01

“DHCPv6/SLAAC 交互操作指南”

draft-liu-v6ops-dhcpv6-slaac-guidance-01

“IPv6 家庭网络架构原则”

draft-ietf-homenet-arch-13

附录 A：RFCs

如果你想了解更多关于 IPv6 或任何其他标准化协议的内容，必须阅读 RFC。它们是最准确的信息来源——但是，我同意，它们的阅读并不总是有趣的（除非你读的是 4 月 1 日发布的那些）。本附录提供了标准和 RFC 过程的简短概述，还包括了本书中提到的与 IPv6 相关的 RFC 列表。

一般 RFC 信息

互联网工程任务组（IETF）和互联网工程指导组（IESG）是定义互联网协议套件官方规范文件的组织。这些文件作为标准化的请求评论（RFC）进行记录和发布。如果你想了解 IETF 的作用和标准化过程，或者需要一份涉及该过程的所有组织及其职能的列表，或者想参加 IETF 会议，有一篇有趣且幽默的 RFC 描述了背景、过程和规则：RFC 4677，标题为《IETF 的道——互联网工程任务组新手指南》。

RFC 是描述有关 TCP/IP 及互联网的架构、协议和历史的报告。互联网上有许多站点可以电子访问 RFC。这些站点差异较大，但大多数都支持某种形式的搜索机制。请选择最适合你需求的站点。

一个好的起点是 www.rfc-editor.org。这里曾有一篇纪念乔恩·波斯特尔（Jon Postel）的文章，他是互联网的奠基人之一，并于 1998 年 10 月去世。他是 RFC 编辑。除了这些信息，网站上还有关于 RFC 系列及其过程的概述。

在本网站的搜索与检索页面上，有多种方式可以访问丰富的信息。RFC 可以按编号或索引查看；可以按时间顺序或倒序排列；还可以按作者、标题、编号或关键词进行搜索。当然，也有指向其他 RFC 仓库的链接。

注意

RFC 2555 是对 RFC 历史三十年的有趣概述，并对乔恩·波斯特尔为互联网社区做出的贡献进行了很好的描述。有关乔恩·波斯特尔的更多信息可以在 www.postel.org/postel.html 找到。

第一篇 RFC，RFC 0001，由 Steve Crocker 于 1969 年 4 月 7 日发布。今天，RFC 的数量仍在快速增长，已超过 7000 篇。RFC 可能有不同的状态，如标准、信息性、实验性和历史性。关于不同状态和当前标准化水平的好概述可以在 www.rfc-editor.org 找到。

曾几何时，RFC 编辑器发布了“互联网官方协议标准”的快照。这些文档被称为 xx00 文档，其中最后一份在 2008 年 5 月发布。这些快照已被网页所取代，因此 RFC 编辑器将不再将这些快照发布为 RFC。因此，RFC 编辑器将把未发布的 RFC xx00 号（直到 7000）归类为“从未发布”。从 RFC 号 7100 开始，xx00 号将可供分配。此内容已在 RFC 7101《互联网官方协议标准列表：已被网页取代》中发布。

草稿

本书中我经常提到草稿。草稿的名称中总是包含版本号，这个版本号在整个过程中经常增加。所以让我们更详细地看一下草稿过程。

在标准化过程中，草稿会发布到互联网上。草稿最终可能成为 RFC。在IETF 网站上，点击互联网草稿可以找到所有文档。要使用搜索引擎查找任何文档的最新状态，请参考datatracker.ietf.org/public/pidtracker.cgi。你也可以点击“IETF 工作组”以根据领域（应用、操作、路由、安全等）查找所有工作组。在各个工作组中，你会找到所有相关的 RFC 和草稿。这是了解正在排队的内容和各组正在处理的事项的最佳地点。这个过程的目标是使正在开发中的规范能为广大受众所接触，以便获取评论和反馈。另一个很好的链接是tools.ietf.org，它提供了关于特定工作组的 RFC 和活跃草稿的概览。

所以让我们来了解草稿版本号。如你所注意到的，它可能会经常变动。当你在搜索引擎中输入草稿名称时，它将始终显示最新的版本。草稿版本号的规则如下。

每次更新草稿时，它都会获得一个新的版本号。某个时刻，草稿可能会被发布为 RFC 然后从草稿目录中移除。一个特定版本号的草稿最多有六个月的生命周期。之后，如果它没有被更新或成为 RFC，它将被移除出草稿目录。由于本书将会有一段时间上市，所以这里提到的一些草稿在你尝试查找时可能不再有效。它们可能已经被移除或发布为 RFC。RFC 7221《IETF 工作组对互联网草稿的处理》是有关草稿、文档和流程的最新更新。

草案不是标准，不应在商业产品中实现，因为一旦它们成为 RFC，它们肯定会发生变化。这也可能导致兼容性问题，比如当供应商在不同的开发成熟度级别实现草案，或者一个实现基于草案，另一个基于 RFC 时。在实践中，您会在商业产品中找到草案实现，但现在您知道在使用它们时需要小心。

IPv6 的 RFC 索引

这是截至 2014 年 4 月发布的所有与 IPv6 相关的 RFC 和相关技术的 RFC 列表。按 RFC 编号排序。

  • RFC 1, “主机软件”，1969 年

  • RFC 318, “Telnet 协议”，1972 年

  • RFC 791, “互联网协议”，1981 年

  • RFC 854, “TELNET 协议规范”，1983 年

  • RFC 855, “TELNET 选项规范”，1983 年

  • RFC 959, “文件传输协议（FTP）”，1985 年

  • RFC 1058, “路由信息协议”，1988 年

  • RFC 1191, “路径 MTU 发现”，1991 年

  • RFC 1195, “在 TCP/IP 和双环境中使用 OSI IS-IS 进行路由”，1990 年

  • RFC 1321, “MD5 消息摘要算法”，1992 年

  • RFC 1546, “主机任播服务”，1993 年

  • RFC 1700, “分配号码”，1994 年

  • RFC 1707, “CATNIP：互联网的通用架构”，1994 年

  • RFC 1710, “简单互联网协议加白皮书”，1994 年

  • RFC 1745, “BGP4/IDRP 与 IP-OSPF 交互”，1994 年

  • RFC 1752, “IP 下一代协议的建议”，1995 年

  • RFC 1771, “边界网关协议 4（BGP-4）”，1995 年

  • RFC 1793, “扩展 OSPF 以支持需求电路”，1995 年

  • RFC 1812, “IP 版本 4 路由器要求”，1995 年

  • RFC 1819, “互联网流协议版本 2”，1995 年

  • RFC 1828, “使用键控 MD5 的 IP 认证”，1995 年

  • RFC 1829, “ESP DES-CBC 变换”，1995 年

  • RFC 1883, “互联网协议，版本 6（IPv6）规范”，1995 年

  • RFC 1918, “私有互联网地址分配”，1996 年

  • RFC 1981, “IP 版本 6 的路径 MTU 发现”，1996 年

  • RFC 1997, “BGP 社区属性”，1996 年

  • RFC 2003, “IP 内 IP 封装”（1996 年 10 月）

  • RFC 2080, “IPv6 的 RIPng”，1997 年

  • RFC 2085, “HMAC-MD5 IP 认证与重放预防”，1997 年

  • RFC 2101, “IPv4 地址行为现状”，1997 年

  • RFC 2104, “HMAC：消息认证的键控哈希”，1997 年

  • RFC 2136, “域名系统中的动态更新”，1997 年

  • RFC 2149, “基于 MARS 的 ATM 多播的多播服务器架构”，1997 年

  • RFC 2185, “IPv6 过渡的路由方面”，1997 年

  • RFC 2205, “资源预留协议（RSVP）—版本 1 功能规格”，1997 年

  • RFC 2207, “RSVP 扩展用于 IPSEC 数据流”，1997 年

  • RFC 2210, “RSVP 与 IETF 集成服务的使用”，1997 年

  • RFC 2233, “使用 SMIv2 的接口组 MIB”，1997 年

  • RFC 2235, “霍布斯互联网时间线”，1997 年

  • RFC 2324, “超文本咖啡壶控制协议（HTCPCP/1.0）”，1998 年

  • RFC 2328, “OSPF 版本 2”，1998 年

  • RFC 2362, “协议独立多播-稀疏模式（PIM-SM）：协议规范”，1998 年

  • RFC 2365, “管理范围的 IP 多播”，1998 年

  • RFC 2375，“IPv6 多播地址分配”，1998 年

  • RFC 2403，“在 ESP 和 AH 中使用 HMAC-MD5-96”，1998 年

  • RFC 2404，“在 ESP 和 AH 中使用 HMAC-SHA-1-96”，1998 年

  • RFC 2405，“ESP DES-CBC 加密算法与显式 IV”，1998 年

  • RFC 2410，“NULL 加密算法及其在 IPsec 中的使用”，1998 年

  • RFC 2412，“OAKLEY 密钥确定协议”，1998 年

  • RFC 2428，“针对 IPv6 和 NAT 的 FTP 扩展”，1998 年

  • RFC 2430，“区分服务和流量工程的提供商架构（PASTE）”，1998 年

  • RFC 2450，“提出的 TLA 和 NLA 分配规则”，1998 年

  • RFC 2451，“ESP CBC 模式加密算法”，1998 年

  • RFC 2453，“RIP 第 2 版”，1998 年

  • RFC 2460，“互联网协议，第 6 版（IPv6）规范”，1998 年

  • RFC 2464，“通过以太网网络传输 IPv6 数据包”，1998 年

  • RFC 2467，“通过 FDDI 网络传输 IPv6 数据包”，1998 年

  • RFC 2465，“IP 版本 6 的管理信息库：文本约定和通用组”，1998 年

  • RFC 2466，“IP 版本 6 的管理信息库：ICMPv6 组”，1998 年

  • RFC 2471，“IPv6 测试地址分配”（6Bone），1998 年

  • RFC 2473，“IPv6 中的通用数据包隧道规范”，1998 年

  • RFC 2474，“IPv4 和 IPv6 头中的区分服务字段（DS 字段）定义”，1998 年

  • RFC 2475，“区分服务架构”，1998 年

  • RFC 2491，“通过非广播多址（NBMA）网络传输 IPv6”，1999 年

  • RFC 2492，“通过 ATM 网络传输 IPv6”，1999 年 1 月

  • RFC 2507，“IP 头压缩”，1999 年

  • RFC 2526，“保留的 IPv6 子网任播地址”，1999 年

  • RFC 2529，“IPv6 在没有显式隧道的 IPv4 域中的传输”，1999 年

  • RFC 2545，“BGP-4 多协议扩展在 IPv6 跨域路由中的使用”，1999 年

  • RFC 2555，“RFC 发布 30 周年”，1999 年

  • RFC 2590，“通过帧中继网络传输 IPv6 数据包的规范”，1999 年

  • RFC 2597，“保证转发 PHB 组”，1999 年

  • RFC 2608，“服务位置协议，第 2 版”，1999 年

  • RFC 2663，“IP 网络地址转换（NAT）术语与考虑因素”，1999 年

  • RFC 2675，“IPv6 大数据包”，1999 年

  • RFC 2710，“IPv6 的多播监听者发现（MLD）”，1999 年

  • RFC 2711，“IPv6 路由器警告选项”，1999 年

  • RFC 2715，“多播路由协议的互操作性规则”，1999 年

  • RFC 2784，“通用路由封装（GRE）”，2000 年

  • RFC 2845，“DNS 的秘密密钥事务身份验证（TSIG）”，2000 年

  • RFC 2884，“在 IP 网络中显式拥塞通知（ECN）性能评估”，2000 年

  • RFC 2894，“IPv6 路由器重编号”，2000 年

  • RFC 2914，“拥塞控制原则”，2000 年

  • RFC 2921，“6BONE pTLA 和 pNLA 格式（pTLA）”，2000 年

  • RFC 2925，“远程 Ping、Traceroute 和查找操作的管理对象定义”，2000 年

  • RFC 2928，“初始 IPv6 子 TLA ID 分配”，2000 年

  • RFC 2963，“针对区分服务的速率自适应整形器”，2000 年

  • RFC 2983，“区分服务与隧道”，2000 年

  • RFC 2993，“NAT 的架构影响”，2000 年

  • RFC 2998, “在 Diffserv 网络上操作的集成服务框架，”2000

  • RFC 3006, “压缩流存在下的集成服务，”2000

  • RFC 3007, “安全域名系统（DNS）动态更新，”2000

  • RFC 3019, “IP 版本 6 管理信息库用于多播监听者发现协议，”2001

  • RFC 3022, “传统 IP 网络地址转换器（传统 NAT），”2001

  • RFC 3027, “IP 网络地址转换器中的协议复杂性，”2001

  • RFC 3041, “IPv6 中无状态地址自动配置的隐私扩展，”2001

  • RFC 3053, “IPv6 隧道代理，”2001

  • RFC 3056, “通过 IPv4 云连接 IPv6 域，”2001

  • RFC 3068, “6to4 中继路由器的任播前缀，”2001

  • RFC 3086, “每域差异化服务行为的定义及其规范规则，”2001

  • RFC 3101, “OSPF NSSA 选项，”2003

  • RFC 3107, “在 BGP-4 中携带标签信息，”2001

  • RFC 3111, “IPv6 的服务位置协议修改，”2001

  • RFC 3118, “DHCP 消息的认证，”2001

  • RFC 3122, “IPv6 邻居发现的扩展，用于逆向发现规范，”2001

  • RFC 3124, “拥塞管理器，”2001

  • RFC 3140, “每跳行为标识码，”2001

  • RFC 3142, “IPv6 到 IPv4 传输中继转换器，”2001

  • RFC 3146, “IPv6 数据包在 IEEE 1394 网络上的传输，”2001

  • RFC 3162, “RADIUS 和 IPv6，”2001

  • RFC 3168, “在 IP 中添加显式拥塞通知（ECN），”2001

  • RFC 3175, “IPv4 和 IPv6 预留的 RSVP 聚合，”2001

  • RFC 3178, “IPv6 多宿主支持于站点出口路由器，”2001

  • RFC 3226, “DNSSEC 和 IPv6 A6 感知服务器/解析器消息大小要求，”2001

  • RFC 3232, “分配的号码：RFC 1700 由在线数据库取代，”2002

  • RFC 3246, “加急转发 PHB，”2002

  • RFC 3247, “新定义的 EF PHB（加急转发每跳行为）补充信息，”2002

  • RFC 3260, “Diffserv 的新术语和澄清，”2002

  • RFC 3289, “差异化服务架构的管理信息库，”2002

  • RFC 3290, “Diffserv 路由器的非正式管理模型，”2002

  • RFC 3306, “基于单播前缀的 IPv6 组播，”2002

  • RFC 3307, “IPv6 组播地址分配指南，”2002

  • RFC 3315, “IPv6 动态主机配置协议（DHCPv6），”2003

  • RFC 3317, “差异化服务质量服务策略信息库，”2003

  • RFC 3319, “会话发起协议（SIP）服务器的动态主机配置协议（DHCPv6）选项，”2003

  • RFC 3353, “多协议标签交换（MPLS）环境中 IP 组播概述，”2002

  • RFC 3376, “互联网组管理协议，第 3 版，”2002

  • RFC 3493, “IPv6 的基本套接字接口扩展，”2003

  • RFC 3514, “IPv4 头中的安全标志，”2003 年 4 月 1 日

  • RFC 3526, “用于互联网密钥交换（IKE）的更多模块化指数（MODP）Diffie-Hellman 组，”2003

  • RFC 3542，《IPv6 的高级套接字应用程序接口（API）》，2003 年

  • RFC 3569，《源特定多播（SSM）概述》，2003 年

  • RFC 3582，《IPv6 网站多宿主架构的目标》，2003 年

  • RFC 3587，《IPv6 全球单播地址格式》，2003 年

  • RFC 3590，《多播监听器发现（MLD）协议的源地址选择》，2003 年

  • RFC 3596，《支持 IP 版本 6 的 DNS 扩展》，2003 年

  • RFC 3602，《AES-CBC 密码算法及其与 IPsec 的应用》，2003 年

  • RFC 3631，《互联网的安全机制》，2003 年

  • RFC 3633，《IPv6 前缀选项用于动态主机配置协议（DHCP）版本 6》，2003 年

  • RFC 3646，《动态主机配置协议 IPv6（DHCPv6）的 DNS 配置选项》，2003 年

  • RFC 3701，《6bone（IPv6 测试地址分配）- 阶段性淘汰》，2004 年

  • RFC 3715，《IPsec-网络地址转换（NAT）兼容性要求》，2004 年

  • RFC 3717，《光网络中的 IP：框架》，2004 年

  • RFC 3736，《IPv6 的无状态动态主机配置协议（DHCP）服务》，2004 年

  • RFC 3739，《互联网 X.509 公钥基础设施：合格证书配置文件》，2004 年

  • RFC 3740，《多播组安全架构》，2004 年

  • RFC 3748，《可扩展认证协议（EAP）》，2004 年

  • RFC 3754，《差异化服务（DS）网络中的 IP 多播》，2004 年

  • RFC 3756，《IPv6 邻居发现（ND）信任模型与威胁》，2004 年

  • RFC 3765，《用于边界网关协议（BGP）路由范围控制的 NOPEER 社区》，2004 年

  • RFC 3769，《IPv6 前缀委派的要求》，2004 年

  • RFC 3776，《使用 IPsec 保护移动 IPv6 信令，跨移动节点与本地代理之间的通信》，2004 年

  • RFC 3789，《目前已部署的 IETF 标准轨道和实验性文档中 IPv4 地址调查简介》，2004 年

  • RFC 3790，《目前已部署的 IETF 互联网区域标准轨道和实验性文档中 IPv4 地址调查》，2004 年

  • RFC 3791，《目前已部署的 IETF 路由区域标准轨道和实验性文档中 IPv4 地址调查》，2004 年

  • RFC 3792，《目前已部署的 IETF 安全区域标准轨道和实验性文档中 IPv4 地址调查》，2004 年

  • RFC 3793，《目前已部署的 IETF 子 IP 区域标准轨道和实验性文档中 IPv4 地址调查》，2004 年

  • RFC 3794，《目前已部署的 IETF 传输区域标准轨道和实验性文档中 IPv4 地址调查》，2004 年

  • RFC 3795，《目前已部署的 IETF 应用区域标准轨道和实验性文档中 IPv4 地址调查》，2004 年

  • RFC 3796，《目前已部署的 IETF 操作与管理区域标准轨道和实验性文档中 IPv4 地址调查》，2004 年

  • RFC 3810，《IPv6 的多播监听器发现版本 2（MLDv2）》，2004 年

  • RFC 3849，《IPv6 文档地址》，2004 年

  • RFC 3879，《弃用站点本地地址》，2004 年

  • RFC 3898，《动态主机配置协议 IPv6（DHCPv6）中的网络信息服务（NIS）配置选项》，2004 年

  • RFC 3901, “DNS IPv6 传输操作指南，” 2004

  • RFC 3936, “修改资源预留协议 (RSVP) 的程序，” 2004

  • RFC 3947, “IKE 中 NAT 穿越的协商，” 2005

  • RFC 3948, “IPsec ESP 数据包的 UDP 封装，” 2005

  • RFC 3956, “在 IPv6 多播地址中嵌入会合点 (RP) 地址，” 2004

  • RFC 3963, " 网络移动性 (NEMO) 基本支持协议，” 2005

  • RFC 3964, “6to4 的安全性考虑，” 2004

  • RFC 3971, “安全邻居发现，” 2005

  • RFC 3972, “加密生成地址 (CGA)，” 2005

  • RFC 3973, “协议独立的组播，密集模式 (PIM-DM)：协议规范（修订版），” 2005

  • RFC 3986, “统一资源标识符 (URI)：通用语法，” 2005

  • RFC 4007, “IPv6 范围地址架构，” 2005

  • RFC 4029, “将 IPv6 引入 ISP 网络的场景与分析，” 2005

  • RFC 4033, “DNS 安全性介绍及需求，” 2005

  • RFC 4034, “DNS 安全扩展的资源记录，” 2005

  • RFC 4035, “DNS 安全扩展的协议修改，” 2005

  • RFC 4038, “IPv6 过渡的应用方面，” 2005

  • RFC 4057, “IPv6 企业网络场景，” 2005

  • RFC 4065, “Seamoby 和实验性移动协议 IANA 分配的说明，” 2005

  • RFC 4074, “针对 IPv6 地址的 DNS 查询的常见错误行为，” 2005

  • RFC 4075, “DHCPv6 的简单网络时间协议 (SNTP) 配置选项，” 2005

  • RFC 4076, “无状态动态主机配置协议 IPv6 (DHCPv6) 的重新编号要求，” 2005

  • RFC 4094, “现有服务质量信令协议分析，” 2005

  • RFC 4106, “在 IPsec 封装安全有效载荷 (ESP) 中使用 Galois/Counter 模式 (GCM)，” 2005

  • RFC 4107, “密码学密钥管理指南，” 2005

  • RFC 4109, “互联网密钥交换版本 1 (IKEv1) 的算法，” 2005

  • RFC 4113, “用户数据报协议的管理信息库，” 2005

  • RFC 4135, “检测 IPv6 网络附着目标的目标，” 2005

  • RFC 4140, “层次化移动 IPv6，” 2005

  • RFC 4159, “‘ip6.int’ 的弃用，” 2005

  • RFC 4177, “IPv6 多宿主架构方法，” 2005

  • RFC 4191, “默认路由器优先级和更具体的路由，” 2005

  • RFC 4192, “无‘标志日’的 IPv6 网络重新编号程序，” 2005

  • RFC 4193, “唯一本地 IPv6 单播地址，” 2005

  • RFC 4213, “IPv6 主机和路由器的基本过渡机制，” 2005

  • RFC 4215, “第三代合作伙伴项目 (3GPP) 网络中 IPv6 过渡的分析，” 2005

  • RFC 4218, “与 IPv6 多宿主解决方案相关的威胁，” 2005

  • RFC 4219, “IPv6 中多宿主（MULTI6）开发人员应考虑的事项，” 2005

  • RFC 4225, “移动 IP 版本 6 路由优化安全设计背景，” 2005

  • RFC 4241, “IPv6/IPv4 双栈互联网接入服务模型，” 2005

  • RFC 4242, “IPv6 动态主机配置协议 (DHCPv6) 的信息刷新时间选项，” 2005

  • RFC 4243, “动态主机配置协议（DHCP）中转代理选项的厂商特定信息子选项”，2005

  • RFC 4260, “移动 IPv6 快速切换用于 802.11 网络”，2005

  • RFC 4280, “广播和组播控制服务器的动态主机配置协议（DHCP）选项”，2005

  • RFC 4282, “网络接入标识符”，2005

  • RFC 4283, “移动 IPv6（MIPv6）的移动节点标识符选项”，2005

  • RFC 4285, “移动 IPv6 的认证协议”，2006

  • RFC 4286, “组播路由器发现（MRD）”，2005

  • RFC 4291, “IP 版本 6 地址架构”，2006

  • RFC 4301, “互联网协议安全架构”，2005

  • RFC 4302, “IP 身份验证头”，2005

  • RFC 4303, “IP 封装安全负载（ESP）”，2005

  • RFC 4305, “封装安全负载（ESP）和身份验证头（AH）的加密算法实现要求”，2005

  • RFC 4306, “互联网密钥交换（IKEv2）协议”，2005

  • RFC 4307, “用于互联网密钥交换版本 2（IKEv2）的加密算法”，2005

  • RFC 4308, “IPsec 的加密套件”，2005

  • RFC 4309, “使用高级加密标准（AES）CCM 模式与 IPsec 封装安全负载（ESP）”，2005

  • RFC 4338, “通过光纤通道传输 IPv6、IPv4 和地址解析协议（ARP）数据包”，2006

  • RFC 4339, “IPv6 主机配置 DNS 服务器信息方法”，2006

  • RFC 4359, “在封装安全负载（ESP）和身份验证头（AH）中使用 RSA/SHA-1 签名”，2006

  • RFC 4380, “Teredo：通过网络地址转换（NAT）隧道化 IPv6 通过 UDP”，2006

  • RFC 4429, “IPv6 的乐观重复地址检测（DAD）”，2006

  • RFC 4443, “互联网控制消息协议（ICMPv6）用于互联网协议版本 6（IPv6）规范”，2006

  • RFC 4449, “使用静态共享密钥保护移动 IPv6 路由优化”，2006

  • RFC 4456, “BGP 路由反射”，2006

  • RFC 4472, “IPv6 DNS 的操作考虑和问题”，2006

  • RFC 4477, “动态主机配置协议（DHCP）：IPv4 和 IPv6 双栈问题”，2006

  • RFC 4487, “移动 IPv6 与防火墙：问题声明”，2006

  • RFC 4489, “生成链路范围 IPv6 组播地址的方法”，2006

  • RFC 4554, “在企业网络中使用 VLAN 实现 IPv4-IPv6 共存”，2006

  • RFC 4555, “IKEv2 移动性和多宿协议（MOBIKE）”，2006

  • RFC 4581, “加密生成地址（CGA）扩展字段格式”，2006

  • RFC 4584, “为移动 IPv6 扩展的套接字 API”，2006

  • RFC 4601, “互联网组管理协议，第 2 版”，2006

  • RFC 4604, “使用 MLDv2 进行源特定组播”，2006

  • RFC 4620, “IPv6 节点信息查询”，2006

  • RFC 4621, “IKEv2 移动性和多宿协议（MOBIKE）设计”，2006

  • RFC 4659, “BGP-MPLS IP 虚拟专用网络（VPN）扩展用于 IPv6 VPN”，2006

  • RFC 4677, “IETF 的道：互联网工程任务组新手指南”，2006

  • RFC 4703，“动态主机配置协议（DHCP）客户端之间完全限定域名（FQDN）冲突的解决”，2006

  • RFC 4727，“IPv4、IPv6、ICMPv4、ICMPv6、UDP 和 TCP 头中的实验性值”，2006

  • RFC 4760，“BGP-4 的多协议扩展”，2007

  • RFC 4779，“宽带接入网络中的 ISP IPv6 部署场景”，2007

  • RFC 4787，“单播 UDP 的网络地址转换（NAT）行为要求”，2007

  • RFC 4795，“链路本地组播名称解析（LLMNR）”，2007

  • RFC 4798，“通过 IPv6 提供商边缘路由器（6PE）在 IPv4 MPLS 上连接 IPv6 网络岛”，2007

  • RFC 4822，“RIPv2 加密认证”，2007

  • RFC 4831，“基于网络的局部化移动性管理（NETLMM）目标”，2007

  • RFC 4835，“封装安全载荷（ESP）和认证头（AH）的加密算法实现要求”，2007

  • RFC 4852，“IPv6 企业网络分析—IP 层 3 聚焦”，2007

  • RFC 4861，“IP 版本 6 邻居发现”，2007

  • RFC 4862，“IPv6 无状态地址自动配置”，2007

  • RFC 4864，“IPv6 的本地网络保护”，2007

  • RFC 4866，“移动 IPv6 的增强路由优化”，2007

  • RFC 4877，“使用 IKEv2 和修订版 IPsec 架构的移动 IPv6 操作”，2007

  • RFC 4884，“扩展 ICMP 支持多部分消息”，2007

  • RFC 4885，“网络移动性支持术语”，2007

  • RFC 4887，“网络移动性家庭网络模型”，2007

  • RFC 4890，“防火墙中过滤 ICMPv6 消息的建议”，2007

  • RFC 4891，“使用 IPsec 保护 IPv6-in-IPv4 隧道”，2007

  • RFC 4908，“使用移动 IP 和 NEMO 的小规模固定网络的多宿主连接”，2007

  • RFC 4941，“IPv6 无状态地址自动配置的隐私扩展”，2007

  • RFC 4942，“IPv6 过渡/共存安全性考虑”，2007

  • RFC 4944，“通过 IEEE 802.15.4 网络传输 IPv6 数据包”，2007

  • RFC 4957，“用于检测网络附着的链路层事件通知”，2007

  • RFC 4966，“将网络地址转换器 - 协议转换器（NAT-PT）移至历史状态的原因”，2007

  • RFC 4982，“支持加密生成地址（CGA）中的多种哈希算法”，2007

  • RFC 5015，“双向协议独立组播（BIDIR-PIM）”，2007

  • RFC 5059，“协议独立组播（PIM）的引导路由器（BSR）机制”，2008

  • RFC 5065，“BGP 的自治系统联合体”，2007

  • RFC 5072，“PPP 上的 IP 版本 6”，2007

  • RFC 5084，“在加密消息语法（CMS）中使用 AES-CCM 和 AES-GCM 认证加密”，2007

  • RFC 5094，“移动 IPv6 厂商特定选项”，2007

  • RFC 5095，“IPv6 中类型 0 路由头的弃用”，2007

  • RFC 5096，“移动 IPv6 实验性消息”，2007

  • RFC 5120，“M-ISIS：中间系统到中间系统（IS-IS）中的多拓扑（MT）路由”，2008

  • RFC 5142，“移动头家庭代理切换消息”，2008

  • RFC 5149，“移动 IPv6 的服务选择”，2008

  • RFC 5156，《特殊用途 IPv6 地址》，2008 年

  • RFC 5157，《IPv6 对网络扫描的影响》，2008 年

  • RFC 5164，《移动服务传输：问题陈述》，2008 年

  • RFC 5172，《使用 IPv6 控制协议的 IPv6 数据报压缩协商》，2008 年

  • RFC 5181，《802.16 网络中的 IPv6 部署场景》，2008 年

  • RFC 5213，《代理移动 IPv6》，2008 年

  • RFC 5214，《站点内自动隧道地址协议（ISATAP）》，2008 年

  • RFC 5220，《多前缀环境中默认地址选择的问题陈述》，2008 年

  • RFC 5247，《可扩展认证协议（EAP）密钥管理框架》，2008 年

  • RFC 5268，《移动 IPv6 快速切换》，2008 年

  • RFC 5270，《通过 IEEE 802.16e 网络进行移动 IPv6 快速切换》，2008 年

  • RFC 5271，《3G CDMA 网络的移动 IPv6 快速切换》，2008 年

  • RFC 5308，《通过 IS-IS 路由 IPv6》，2008 年

  • RFC 5340，《IPv6 的 OSPF（OSPFv3）》，2008 年

  • RFC 5350，《IPv4 和 IPv6 路由器警报选项的 IANA 考虑事项》，2008 年

  • RFC 5375，《IPv6 单播地址分配考虑因素》，2008 年

  • RFC 5380，《分层移动 IPv6（HMIPv6）移动性管理》，2008 年

  • RFC 5453，《保留的 IPv6 接口标识符》，2009 年

  • RFC 5492，《通过 BGP-4 广告功能》，2009 年

  • RFC 5555，《移动 IPv6 对双栈主机和路由器的支持》，2009 年

  • RFC 5568，《移动 IPv6 快速切换》，2009 年

  • RFC 5569，《在 IPv4 基础设施上快速部署 IPv6（6rd）》，2010 年

  • RFC 5571，《带有第二层隧道协议版本 2（L2TPv2）的软路由中心-辐射部署框架》，2009 年

  • RFC 5572，《带隧道设置协议的 IPv6 隧道代理》，2010 年

  • RFC 5637，《移动 IPv6 的认证、授权和计费（AAA）目标》，2009 年

  • RFC 5648，《多个 Care-of 地址注册》，2009 年

  • RFC 5722，《重叠 IPv6 片段的处理》，2009 年

  • RFC 5739，《在互联网密钥交换协议版本 2（IKEv2）中的 IPv6 配置》，2010 年

  • RFC 5796，《协议无关组播稀疏模式（PIM-SM）链路本地消息中的认证与机密性》，2010 年

  • RFC 5838，《OSPFv3 中地址族的支持》，2010 年

  • RFC 5844，《IPv4 对代理移动 IPv6 的支持》，2010 年

  • RFC 5846，《IPv6 移动性的绑定撤销》，2010 年

  • RFC 5847，《代理移动 IPv6 的心跳机制》，2010 年

  • RFC 5871，《IANA 对 IPv6 路由标头的分配指南》，2010 年

  • RFC 5887，《重新编号仍需改进》，2010 年

  • RFC 5902，《IAB 对 IPv6 网络地址转换的看法》，2010 年

  • RFC 5909，《保护邻居发现代理：问题陈述》，2010 年

  • RFC 5942，《IPv6 子网模型：链路与子网前缀之间的关系》，2010 年

  • RFC 5944，《IPv4 的 IP 移动性支持》，2010 年

  • RFC 5952，《IPv6 地址文本表示的建议》，2010 年

  • RFC 5969，《在 IPv4 基础设施上快速部署 IPv6（6rd）—协议规范》，2010 年

  • RFC 5991，《Teredo 安全更新》，2010 年

  • RFC 5996，《互联网密钥交换协议版本 2（IKEv2）》，2010 年

  • RFC 6014，《DNSSEC 的加密算法标识符分配》，2010 年

  • RFC 6036, “IPv6 部署中的新兴服务提供商场景”，2010

  • RFC 6040, “显式拥塞通知的隧道传输”，2010

  • RFC 6052, “IPv4/IPv6 翻译器的 IPv6 地址分配”，2010

  • RFC 6071, “IP 安全性（IPsec）和互联网密钥交换（IKE）文档路线图”，2011

  • RFC 6081, “Teredo 扩展”，2011

  • RFC 6085, “以太网中 IPv6 多播数据包的地址映射”，2011

  • RFC 6089, “移动 IPv6 和网络移动性（NEMO）基本支持中的流绑定”，2011

  • RFC 6092, “为提供住宅 IPv6 网络服务的客户终端设备（CPE）推荐的简单安全功能”，2011

  • RFC 6104, “恶意 IPv6 路由器通告问题陈述”，2011

  • RFC 6105, “IPv6 路由器通告保护”，2011

  • RFC 6106, “IPv6 路由器通告选项用于 DNS 配置”，2010

  • RFC 6119, “IS-IS 中的 IPv6 流量工程”，2011

  • RFC 6144, “IPv4/IPv6 转换框架”，2011

  • RFC 6145, “无状态 IP/ICMP 转换”，2011

  • RFC 6146, “有状态 NAT64：IPv6 客户端到 IPv4 服务器的网络地址和协议转换”，2011

  • RFC 6147, “DNS64：IPv6 客户端到 IPv4 服务器的网络地址转换的 DNS 扩展”，2011

  • RFC 6151, “更新 MD5 消息摘要算法和 HMAC-MD5 算法的安全性考虑”，2011

  • RFC 6164, “在路由器间链路上使用 127 位 IPv6 前缀”，2011

  • RFC 6169, “IP 隧道的安全性问题”，2011

  • RFC 6177, “IPv6 地址分配给终端站点”，2011

  • RFC 6180, “在 IPv6 部署过程中使用 IPv6 过渡机制的指南”，2011

  • RFC 6221, “轻量级 DHCPv6 转发代理”，2011

  • RFC 6226, “PIM 组到 rendezvous 点映射”，2011

  • RFC 6250, “IP 模型的演进”，2011

  • RFC 6269, “IP 地址共享问题”，2011

  • RFC 6273, “安全邻居发现（SEND）哈希威胁分析”，2011

  • RFC 6275, “IPv6 中的移动性支持”，2011

  • RFC 6279, “代理移动 IPv6 (PIMPv6) 局部路由问题陈述”，2011

  • RFC 6282, “基于 IEEE 802.15.4 网络的 IPv6 数据报压缩格式”，2011

  • RFC 6294, “对 IPv6 流标签提议的使用案例调查”，2011

  • RFC 6296, “IPv6 到 IPv6 网络前缀转换”，2011

  • RFC 6302, “面向互联网的服务器的日志记录建议”，2011

  • RFC 6308, “互联网多播地址分配架构”，2011

  • RFC 6324, “使用 IPv6 自动隧道的路由环路攻击”，2011

  • RFC 6326, “大量链路的透明互连（TRILL）在 IS-IS 中的应用”，2011

  • RFC 6333, “IPv4 地址耗尽后的双栈轻型宽带部署”，2011

  • RFC 6334, “双栈轻型的 IPv6（DHCPv6）选项的动态主机配置协议”，2011

  • RFC 6343, “6to4 部署的建议指南”，2011

  • RFC 6398, “IP 路由器警报考虑事项和使用”，2011

  • RFC 6422, “转发器提供的 DHCP 选项”，2011

  • RFC 6434, “IPv6 节点要求”，2011

  • RFC 6436, “更新 IPv6 流标签规范的理由”，2011

  • RFC 6437, “IPv6 流标签规范”，2011

  • RFC 6438, “在隧道中使用 IPv6 流标签进行等成本多路径路由和链路聚合，”2011 年

  • RFC 6459, “3GPP 演进分组系统（EPS）中的 IPv6 支持，”2012 年

  • RFC 6494, “SEcure 邻居发现（SEND）的证书配置文件和证书管理，”2012 年

  • RFC 6495, “主题密钥标识符（SKI）SEcure 邻居发现（SEND）名称类型字段，”2012 年

  • RFC 6535, “使用‘主机内的碰撞’技术（BIHS）的双栈主机，”2012 年

  • RFC 6540, “所有 IP 支持的节点都需要 IPv6 支持，”2012 年

  • RFC 6543, “代理移动 IPv6 的保留 IPv6 接口标识符，”2012 年

  • RFC 6553, “低功耗和丢包网络（RPL）数据平面数据报中携带 RPL 信息的路由协议选项，”2012 年

  • RFC 6554, “带有低功耗和丢包网络（RPL）路由协议的 IPv6 源路由路由头，”2012 年

  • RFC 6555, “幸福眼球：双栈主机的成功，”2012 年

  • RFC 6556, “测试眼球幸福度，”2012 年

  • RFC 6564, “IPv6 扩展头的统一格式，”2012 年

  • RFC 6572, “RADIUS 支持代理移动 IPv6，”2012 年

  • RFC 6583, “操作中的邻居发现问题，”2012 年

  • RFC 6586, “来自仅 IPv6 网络的经验，”2012 年

  • RFC 6603, “用于基于 DHCPv6 的前缀委派的前缀排除选项，”2012 年

  • RFC 6610, “移动 IPv6（MIPv6）中的家庭信息发现的 DHCP 选项，”2012 年

  • RFC 6611, “集成场景下的移动 IPv6（MIPv6）引导过程，”2012 年

  • RFC 6618, “使用传输层安全协议实现移动节点与主代理之间通信的移动 IPv6 安全框架，”2012 年

  • RFC 6619, “具有每接口绑定的地址转换器的可扩展操作，”2012 年

  • RFC 6620, “FCFS SAVI：先到先得源地址验证改进，适用于本地分配的 IPv6 地址，”2012 年

  • RFC 6621, “简化的多播转发，”2012 年

  • RFC 6655, “传输层安全协议（TLS）中的 AES-CCM 密码套件，”2012 年

  • RFC 6705, “代理移动 IPv6 的本地化路由，”2012 年

  • RFC 6724, “互联网协议版本 6（IPv6）默认地址选择，”2012 年

  • RFC 6775, “针对低功耗无线个人区域网络（6LoWPAN）的 IPv6 邻居发现优化，”2012 年

  • RFC 6791, “ICMPv6 数据包的无状态源地址映射，”2012 年

  • RFC 6822, “IS-IS 多实例，”2012 年

  • RFC 6830, “定位符/标识符分离协议（LISP），”2013 年

  • RFC 6831, “定位符/标识符分离协议（LISP）在多播环境中的应用，”2013 年

  • RFC 6832, “定位符/标识符分离协议（LISP）与非 LISP 站点之间的互联互通，”2013 年

  • RFC 6833, “定位符/标识符分离协议（LISP）地图服务器接口，”2013 年

  • RFC 6834, “定位符/标识符分离协议（LISP）地图版本控制，”2013 年

  • RFC 6835, “定位符/标识符分离协议互联网探测器（LIG），”2013 年

  • RFC 6836, “定位符/标识符分离协议（LISP）备用逻辑拓扑（LISP+ALT），”2013 年

  • RFC 6845, “OSPF 混合广播和点对多点接口类型，”2013 年

  • RFC 6853, “DHCPv6 冗余部署考虑因素”，2013 年

  • RFC 6860, “在 OSPF 中隐藏仅传输网络”，2013 年

  • RFC 6866, “关于在企业网络中重新编号具有静态地址的 IPv6 主机的问题陈述”，2013 年

  • RFC 6874, “在地址文字和统一资源标识符中表示 IPv6 区域标识符”，2013 年

  • RFC 6877, “464XLAT：有状态和无状态翻译的结合”，2013 年

  • RFC 6879, “IPv6 企业网络重新编号场景、考虑因素和方法”，2013 年

  • RFC 6883, “互联网内容提供商和应用服务提供商的 IPv6 指导”，2013 年

  • RFC 6886, “NAT 端口映射协议（NAT-PMP）”，2013 年

  • RFC 6888, “运营商级 NAT（CGN）的常见要求”，2013 年

  • RFC 6889, “有状态 64 翻译分析”，2013 年

  • RFC 6895, “域名系统（DNS）IANA 考虑事项”，2013 年

  • RFC 6908, “双栈精简版的部署考虑”，2013 年

  • RFC 6909, “用于代理移动 IPv6 的 IPv4 流量卸载选择器选项”，2013 年

  • RFC 6911, “IPv6 接入网络的 RADIUS 属性”，2013 年

  • RFC 6921, “超光速（FTL）通信的设计考虑”，2013 年 4 月 1 日

  • RFC 6939, “DHCPv6 中的客户端链路层地址选项”，2013 年

  • RFC 6946, “IPv6 ‘原子’片段处理”，2013 年

  • RFC 6959, “源地址验证改进（SAVI）威胁范围”，2013 年

  • RFC 6977, “通过中继代理触发 DHCPv6 重新配置”，2013 年

  • RFC 6980, “IPv6 片段化与 IPv6 邻居发现的安全影响”，2013 年

  • RFC 6992, “为 IPv4 嵌入 IPv6 数据包进行路由”，2013 年

  • RFC 7010, “IPv6 站点重新编号差距分析”，2013 年

  • RFC 7021, “评估运营商级 NAT 对网络应用的影响”，2013 年

  • RFC 7031, “DHCPv6 故障转移要求”，2013 年

  • RFC 7039, “源地址验证改进（SAVI）框架”，2013 年

  • RFC 7040, “公共 IPv4 通过 IPv6 访问网络”，2013 年

  • RFC 7045, “IPv6 扩展头的传输和处理”，2014 年

  • RFC 7048, “邻居不可达检测过于急躁”，2014 年

  • RFC 7050, “用于 IPv6 地址合成的 IPv6 前缀发现”，2013 年

  • RFC 7051, “主机学习 NAT64 前缀的解决方案提案分析”，2013 年

  • RFC 7059, “IPv6-over-IPv4 隧道机制的比较”，2013 年

  • RFC 7066, “面向第三代合作伙伴计划（3GPP）蜂窝主机的 IPv6”，2013 年

  • RFC 7077, “代理移动 IPv6 的更新通知”，2013 年

  • RFC 7078, “使用 DHCPv6 分发地址选择策略”，2014 年

  • RFC 7084, “IPv6 客户边缘路由器的基本要求”，2013 年

  • RFC 7094, “IP Anycast 的架构考虑”，2014 年

  • RFC 7098, “在服务器集群中使用 IPv6 流标签进行负载均衡”，2013 年

  • RFC 7101, “互联网官方协议标准列表：由网页替代”，2013 年

  • RFC 7108, “L-Root 上部署的各种机制总结，用于标识 Anycast 节点”，2014 年

  • RFC 7109, “移动 IPv6 中由家庭代理发起的流绑定”，2014 年

  • RFC 7112, “超大 IPv6 头链的影响”，2014 年

  • RFC 7113, “IPv6 路由器通告防护（RA Guard）实现建议，” 2014

  • RFC 7123, “IPv6 对 IPv4 网络的安全影响，” 2014

  • RFC 7136, “IPv6 接口标识符的意义，” 2014

  • RFC 7148, “代理移动 IPv6 的前缀委派支持，” 2014

  • RFC 7156, “代理移动 IPv6 本地路由的 Diameter 支持，” 2014

  • RFC 7157, “没有网络地址转换的 IPv6 多宿，” 2014

  • RFC 7161, “通过 LMA 获取订阅信息（SIAL）进行代理移动 IPv6（PMIPv6）多播切换优化，” 2014

  • RFC 7168, “茶水流量设备的超文本咖啡壶控制协议（HTCPCP-TEA），” 2014 年 4 月 1 日

  • RFC 7217, “通过 IPv6 无状态地址自动配置（SLAAC）生成语义不透明的接口标识符的方法，” 2014

  • RFC 7219, “安全邻居发现（SEND）源地址验证改进（SAVI），” 2014

  • RFC 7221, “IETF 工作组对互联网草案的处理，” 2014

  • RFC 7222, “代理移动 IPv6 的服务质量选项，” 2014

  • RFC 7225, “使用端口控制协议（PCP）发现 NAT64 IPv6 前缀，” 2014

  • RFC 7279, “新 ICMP 类型和代码的可接受使用政策，” 2014

附录 B：推荐阅读

本附录提供了我推荐的一些书籍：

  • IPv6 规划，作者：Silvia Hagen（O’Reilly，2011 年）

  • Windows 管理员的实用 IPv6，作者：Ed Horley（Apress，2013 年）

  • IPv6 安全，作者：Scott Hogg 和 Eric Vyncke（Cisco Press，2009 年）

  • IPv6 上的 DNS 和 BIND，作者：Cricket Liu（O’Reilly，2011 年）

  • 全球 IPv6 战略，作者：Patrick Grossetete、Ciprian Popoviciu 和 Fred Wettling（Cisco Press，2008 年）

  • OSPF 和 IS-IS：为大规模网络选择 IGP，作者：Jeff Doyle（Addison-Wesley，2005 年）

  • 路由 TCP/IP，卷 1（第二版），作者：Jeff Doyle（Cisco Press，2005 年）

  • 部署 IPv6 网络，作者：Ciprian Popoviciu、Eric Levy-Abegnoli 和 Patrick Grossetete（Cisco Press，2006 年）

  • 企业网络中的 IPv6，作者：Shannon McFarland、Muninder Sambi、Nikhil Sharma 和 Sanjay Hooda（Cisco Press，2011 年）

  • 移动 IPv6，作者：Hesham Soliman（Addison-Wesley，2004 年）

  • IPv6 网络管理，作者：David Malone 和 Niall Richard Murphy（O’Reilly，2005 年）

  • 超越生物学：人类精神的蓝图，作者：Joseph Chilton Pearce（Park Street Press，2004 年）

  • 来自宇宙中心的视角，作者：Joel R. Primack 和 Nancy Ellen Abrams（Riverhead Books，2007 年）

posted @ 2025-11-14 20:41  绝不原创的飞龙  阅读(25)  评论(0)    收藏  举报