logo资料库

RFC6434(中文) 对IPv6节点的要求(废除了RFC4294).pdf

发布时间：2022-06-17 发布人：admin 分类：说明书 资料大小：0.37M 资料格式：pdf 举报 版权申诉
第1页 / 共18页
第2页 / 共18页
第3页 / 共18页
第4页 / 共18页
第5页 / 共18页
第6页 / 共18页
第7页 / 共18页
第8页 / 共18页
资料共18页，剩余部分请下载后查看
    本文翻译者：weicq2000(weicq2000@sina.com，2013-1-2) Internet Engineering Task Force (IETF) E. Jankiewicz Request for Comments: 6434 SRI International, Inc. Obsoletes: 4294 J. Loughney Category: Informational Nokia ISSN: 2070-1721 T. Narten IBM Corporation December 2011 IPv6 节点要求 摘要 本文档定义对 IPv6 节点的要求。本文档预期 IPv6 在大量设备上和大范围场景中部署。 规定对 IPv6 节点的要求可使 IPv6 能够更好地运行，以及在大批量应用和部署中实现互操作。 本文档替代 RFC4294。 本备忘录状态 本备忘录不是 Internet Standards Track 标准；颁布其仅用于提供信息。 本文档是 Internet Engineering Task Force (IETF)的产品。它代表 IETF 社区的一致意见。 它已经经过公众审查，已经由 Internet Engineering Steering Group (IESG)批准颁布。IESG 批 准的文档不一定都作为某个 Internet Standard 等级的候选文档；请参阅 RFC5741 第 2 章。 有 关 本 文 档 目 前 状 态 、 勘 误 表 和 如 何 提 供 本 文 档 反 馈 的 信 息 可 以 在 http://www.rfc-editor.org/info/rfc6434 上获得。 版权声明 版权所有(c)2011 IETF Trust 和本文档撰写者(们)。保留所有权利。 本文档遵从本文档颁布日有效的 BCP 78 和 IETF Trust 的 Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info)规定。请仔细查阅这些文档，因为这些文档 解释了对于本文档来说，您享有的权利和受到的限制。如 Trust Legal Provisions 第 4.e 节所 述，取自本文档的 Code Components 必须包括 Simplified BSD License 文本，如 Simplified BSD License 所述，提供的 Code Components 没有担保。 本文档可能包括在 2008 年 11 月 10 日之前出版的或可公开获得的、来自 IETF Documents 或 IETF Contributions 的材料。材料的某些部分的版权控制人(们)可能没有授权 IETF Trust 可以超出 IETF Standards Process 以外修改该材料。没有获得这些材料的版权控制人(们)的适 当许可，在 IETF Standards Process 以外可能不能修改本文档，在 IETF Standards Process 以 外可能不能创建本文档的衍生作品，但是可以将本文档作为 RFC 出版或将其翻译为英文以 外的语言。 目录 第1章 序言 1-1 本文档范围 1-2 IPv6节点描述 第2章 语言要求
    第3章 本文档使用的缩写词 第4章 IP下层 第5章 IP层 5-1 互联网协议版本6 - RFC 2460 5-2 IPv6邻居发现 - RFC 4861 5-3 默认路由器首选和更具体的路由 - RFC 4191 5-4 安全的邻居发现(SEND) - RFC 3971 5-5 IPv6路由器通告标记选项 - RFC 5175 5-6 路径MTU发现和分组大小 5-6-1 路径MTU发现 - RFC 1981 5-7 IPv6超长报文 - RFC 2675 5-8 IPv6 ICMP - RFC 4443 5-9 寻址 5-9-1 IPv6的寻址架构 - RFC 4291 5-9-2 IPv6无状态地址自动配置 - RFC 4862 5-9-3 IPv6中地址配置的隐私扩展 - RFC 4941 5-9-4 IPv6默认地址选择 - RFC 3484 5-9-5 有状态地址自动配置(DHCPv6) - RFC 3315 5-10 IPv6的多播监听者发现(MLD) 第6章 主机配置采用DHCP还是采用路由器通告选项 第 7 章 DNS 和 DHCP 7-1 DNS 7-2 IPv6动态主机配置协议(DHCPv6) - RFC 3315 7-2-1 其他配置信息 7-2-2 在受管理环境中使用路由器通告 7-3 DNS配置的IPv6路由器通告选项 - RFC 6106 第8章 IPv4支持和转换 8-1 转换机制 8-1-1 IPv6主机和路由器的基本转换机制 - RFC 4213 第9章 应用支持 9-1 IPv6地址的文本表示法 - RFC 5952 9-2 应用程序接口(APIs) 第10章 移动性 第11章 安全 11-1 要求 11-2 转换和算法 第12章 路由器特定功能 12-1 IPv6路由器报警选项 - RFC 2711 12-2 IPv6邻居发现 - RFC 4861 12-3 有状态地址自动配置(DHCPv6) - RFC 3315 第13章 网络管理 13-1 管理信息库(MIB)模块 13-1-1 IP转发表MIB 13-1-2 IP协议的MIB
    第14章 安全考虑 第15章 撰写者和致谢 15-1 撰写者和致谢(目前文档) 15-2 RFC 4279的撰写者和致谢 第16章 附录：对RFC 4294的改变 第17章 参考文献 17-1 标准类参考文献 17-2 信息类参考文献 第 1 章 序言 本文档定义 IPv6 主机和路由器需要的通用功能。许多 IPv6 节点执行可选的或附加的功 能，然而本文档将来自其他已颁布 Standards Track 文档中提出的要求汇集到一起。 本文档试图避免讨论协议细节，并为此目的而参考了大量 RFCs。本文档打算作为应用 陈述，对一般情况下应当执行哪些 IPv6 标准以及对特定部署场景哪些标准值得考虑提供指 导。本文档没有更新任何个别协议 RFCs 文档。 虽然本文档指出不同标准，应当注意在许多情况特定要求的粒度小于单一标准，因为许 多标准定义多个、独立的块，其中一些可能不是强制性的。此外，大多数标准在同一部标准 中既定义客户端行为又定义服务器行为，而许多实现仅关注二者之一。 本文档对提供有用网络互联业务的设备定义了最低需要满足的要求，考虑了很大范围的 设备类型和部署场景。由于部署场景范围巨大，本文档规定的最低要求可能不足以涵盖所有 部署场景。为其他配置文件定义适合专门应用和部署环境的附加或更明确要求是完全合理的 (实际上是预期的)。例如，本文档没有强制要求所有客户端支持 DHCP，但某些部署场景可 能认为制定这样的要求是适当的。例如，在美国，政府结构已经为目标环境中 IPv6 的特定 要求定义了配置文件(参阅[DODv6]和[USGv6])。 因为实施者不是总能够精确了解节点中 IPv6 的应用，对 IPv6 节点最主要的要求是节点 应当坚持 Jon Postel 的稳健性原则：“做时应谨慎，敞开双臂欢迎新思想”[RFC0793]。 1-1 本文档范围 IPv6 涉及许多标准。IPv6 将被尝试部署在许多不同的场景和环境中。因此，改进对 IPv6 节点的要求，确保互操作性是很重要的。 本文档确信所有 IPv6 节点满足这里规定的最低要求。 1-2 IPv6 节点描述 根据 Internet Protocol 版本 6(IPv6)标准[RFC2460]，我们有下述定义： IPv6 节点 - 执行 IPv6 的设备。 IPv6 路由器 - 一个节点，它转发不是明确寻址到自己的 IPv6 分组。 IPv6 主机 - 任何不是路由器的节点。 第 2 章 语言要求 本文档中，关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、 “SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”和“OPTIONAL”的含义 遵从 RFC 2119 [RFC2119]中的规定。 第3章 本文档使用的缩写词
    ATM Asynchronous Transfer Mode AH Authentication Header DAD Duplicate Address Detection ESP Encapsulating Security Payload ICMP Internet Control Message Protocol IKE Internet Key Exchange MIB Management Information Base MLD Multicast Listener Discovery MTU Maximum Transfer Unit NA Neighbor Advertisement NBMA Non-Broadcast Multiple Access ND Neighbor Discovery NS Neighbor Solicitation NUD Neighbor Unreachability Detection PPP Point-to-Point Protocol 第 4 章 IP 下层 IPv6 节点必须支持一个或多个 IPv6 链路层标准。实现应当包括哪些链路层标准取决于 系统安装的硬件支持什么链路层。有可能的是，符合要求的 IPv6 节点的某些接口支持 IPv6， 而其他接口不支持。 当 IPv6 在新的层 2 技术上运行时，一般会发布新的标准。下面，我们列出某些已经开 发了相应 IPv6 标准的层 2 技术。这里的介绍仅为读者提供一些信息，可能不完整。 - 以太网上的 IPv6 分组传输[RFC2464] - ATM 网络上的 IPv6[ RFC2492] - 帧中继网络上的 IPv6 分组传输标准[RFC2590] - IEEE 1394 网络上的 IPv6 分组传输[RFC3146] - 光纤通道上的 IPv6、IPv4 传输和地址解析协议(ARP)分组[RFC4338] - IEEE 802.15.4 网络上的 IPv6 分组传输[RFC4944] - 通过 IEEE 802.16 网络上的 IPv6 汇聚子层传输 IPv6[RFC5121] - PPP 上的 IPv6[RFC5072] 除了传统的物理链路层以外，也可能采用其他协议上的隧道 IPv6。例如： - Teredo：通过网络地址转换(NATs)的 UDP 上的隧道化 IPv6[RFC4380] - “IPv6 主机和路由器的基本转换机制”[RFC4213]第 3 章 第 5 章 IP 层 5-1 互联网协议版本 6 - RFC 2460 互联网协议版本 6(IPv6)由[RFC2460]规定。必须支持这个标准。 任何不能识别的扩展首部或选项必须按照 RFC2460 中的规定处理。 节点必须遵循 RFC2460 中的分组传送规则。 节点必须随时能够发送、接收和处理分段首部。所有适当的 IPv6 实现必须能够发送和 接收 IPv6 分组；可以支持转发功能。叠加分段必须按[RFC5722]中的规定处理。 RFC2460 规定了扩展首部和对这些首部的处理。 IPv6 节点必须能够处理这些首部。但是 Routing Header 类型 0(RH0)是例外，由于安全
    上的考虑它被[RFC5095]废弃，必须将其作为不能识别的路由类型对待。 所有节点应当支持在 IPv6 Flow Label 标准[RFC6437]中定义的 IPv6 Flow Label 字段的 设置和使用。诸如路由器和负载分发器这样的转发节点不能仅依赖均匀分发的 Flow Label 值。建议源主机通过为所有给定流的分组设置 Flow Label 字段为相同值来支持流标签，该 相同值选自离散均匀分布的近似值。 5-2 IPv6 邻居发现 – RFC 4861 Neighbor Discovery(ND)在[RFC4861]中定义；该定义已由[RFC5942]更新。应当支持 Neighbor Discovery。RFC 4861 指出： 除非另有规定(在论述特定链路类型上运行 IP 的文档中)，否则本文档适用所有链 路类型。然而，因为 ND 对它的一些业务使用链路层多播，有可能在某些链路类型 上(例如， Non-Broadcast Multi-Access (NBMA)链路)，规定实现这些业务的替代协 议或机制(在论述特定链路类型上运行 IP 的适当文档中)。在本文档中介绍的、不 直接依赖于多播的业务，诸如 Redirects、下一跳确定、Neighbor Unreachability Detection 等，预期将会被提供，正如本文档规定的。如何在 NBMA 链路上使用 ND 的细节在[RFC2491]中介绍。 ND 的一些细节分析如下： Router Discovery 是指主机如何找到驻留在主机附着链路上的路由器。主机必须支持 Router Discovery 功能。 Prefix Discovery 是指主机如何发现地址前缀集合，这些地址前缀定义哪些目的地是主 机附着链路的 on-link。主机必须支持 Prefix Discovery。 对于主机和相邻节点间的所有路径，主机也必须执行 Neighbor Unreachability Detection (NUD)。路由器间的路径不要求 NUD。然而，所有节点必须响应单播 Neighbor Solicitation (NS) 消息。 主机必须支持 Router Solicitations 发送和 Router Advertisements 接收。理解个别 Router Advertisement 选项的能力取决于使用该特定选项支持的功能。 所有节点必须支持 Neighbor Solicitation (NS)和 Neighbor Advertisement (NA)消息的发送 和接收。NS 和 NA 消息是 Duplicate Address Detection (DAD)要求的。 主机应当支持 Redirect 功能。路由器必须支持 Redirects 发送，尽管不必针对每个分组(例 如，由于速率限制)。Redirects 仅用在支持主机的网络上。在由路由器主导的核心网络中， 一般关闭 Redirects。在骨干网路由器上应当默认关闭 Redirects 发送。在边缘网络打算支持 主机的路由器上可以默认开启 Redirects。 “IPv6 Host-to-Router Load Sharing”[RFC4311]包括如何从一组可用路由器中选择路由 器的补充建议。应当支持[RFC4311]。 5-3 默认路由器首选和更具体的路由 - RFC 4191 “Default Router Preferences and More-Specific Routes”[RFC4191]支持附着在多个(不同) 网络上的节点，每个网络提供一些路由器，这些路由器通过 Router Advertisements 通告它们 自己为默认路由器。在某些场景，一个路由器可能提供到多个目的地的连接(其他路由器不 提供到这些目的地的连接)，选择“错误的”默认路由器会导致可达性错误。在这类情况， RFC 4191 能够提供帮助。 由遵守[RFC6204]的路由器支持的 Small Office/Home Office (SOHO)部署使用 RFC 4191 通告到某些本地目的地的路由。因此，在 SOHO 环境中部署的节点应当执行 RFC 4191。
    5-4 安全的邻居发现(SEND) - RFC 3971 SEND [RFC3971]和加密生成地址(Cryptographically Generated Address, CGA) [RFC3972] 提供安全实现 Neighbor Discovery 消息交换的方法。SEND 是新技术，它没有 IPv4 对等技术， 它在应对某些类型欺骗攻击方面颇具潜力。虽然已经有某些 SEND 使用，到目前为止使用 该技术的部署经验还非常有限。此外，IETF 工作组 Cga & Send maIntenance (csi)目前正在做 进一步的充实，以便吸引人们部署 SEND。 目前，SEND 是可选项，IPv6 节点可以提供 SEND 功能。 5-5 IPv6 路由器通告标记选项 - RFC 5175 Router Advertisements 包括一个 8 位字段，该 8 位字段代表 6 个 Router Advertisement 标记，除“Prf”标记外，其余每个 Router Advertisement 标记占用 1 位。Router Advertisement Flags Option 将可用标记位数量扩展到 48 位。截止撰写本文档时，原始 8 个 1 位标记中的 6 个已经派上用场，其余 2 个保留将来分配。没有定义这些标记用于新的选项，因此，严格讲， 今天没有要求执行该选项。然而，能够传递不能识别选项到较高层实体，该实体或许能够理 解这些选项(例如，使用“原始套接字”功能的用户层处理)，的实现可以设法处理预期在将 来使用的该选项。 5-6 路径 MTU 发现和分组大小 5-6-1 路径 MTU 发现 - RFC 1981 应当支持“Path MTU Discovery for IP version 6”[RFC1981]。摘录[RFC2460]： 强烈建议 IPv6 节点执行 Path MTU Discovery [RFC1981]，以便发现和利用大于 1280 字节的 路径 MTUs。然而，最低要求 IPv6 实现(例如，在引导 ROM 中)可以简单限制自身发送不大 于 1280 字节的分组，并忽略 Path MTU Discovery 执行。 分组的分段和重组必须遵循[RFC2460]和[RFC5722]中的规则。 当防火墙阻塞 ICMP Packet Too Big 消息时，一个与 Path MTU Discovery 有关的运行问 题 出 现 。 Path MTU Discovery 依 靠 这 样 的 消 息 确 定 能 够 成 功 发 送 多 大 尺 寸 的 消 息。 “Packetization Layer Path MTU Discovery”[RFC4821]避免依赖 Packet Too Big 消息。 5-7 IPv6 超长报文 - RFC 2675 IPv6 Jumbograms [RFC2675]是可选扩展，它允许发送大于 65,535 字节的 IP 数据报。IPv6 Jumbograms 使用 IPv6 逐跳(hop-by-hop)选项并且仅适用于每一跳和每一链路都能支持 Jumbograms 的路径(例如，校园或数据中心内部)。迄今为止，仅有少数应用，基本上没有应 用经验报告。 因此，IPv6 Jumbograms [RFC2675]目前仍然作为可选项。 5-8 IPv6 ICMP- RFC 4443 必须支持 ICMPv6 [RFC4443]。可以支持“Extended ICMP to Support Multi-Part Messages” [RFC4884]。 5-9 寻址 5-9-1 IPv6 的寻址架构 - RFC 4291 必须支持 IPv6 Addressing Architecture [RFC4291]。
    5-9-2 IPv6 无状态地址自动配置 - RFC 4862 主机必须支持在[RFC4862]中定义的 IPv6 Stateless Address Autoconfiguration。也可以支 持静态地址配置。 作为路由器的节点必须能够生成链路本地地址，如[RFC4862]中描述的。 摘录 RFC 4862： 本文档规定的自动配置处理方法仅适用主机，不适用路由器。因为主机自动配置使 用由路由器通告的信息，配置路由器需要采用其他方法。然而，可以预期路由器将 使用本文档描述的机制，生成链路本地地址。此外，路由器被预期在所有地址被分 配到接口前，在所有地址上成功通过本文档描述的 Duplicate Address Detection 程序。 所有节点必须执行 Duplicate Address Detection。摘录 RFC 4862 第 5-4 节： Duplicate Address Detection 必须在所有单播地址上执行，是在这些地址被分配到接 口前执行，无论这些地址是通过无状态自动配置、DHCPv6 或手工配置获得的，但 有下述例外[在此指出例外]。 “Optimistic Duplicate Address Detection (DAD) for IPv6”[RFC4429]规定了一种机制， 该机制能够减小与经由 Stateless Address Autoconfiguration [RFC4862]生成地址有关的延时。 RFC 4429 与 Mobile IPv6 一起开发，为了减小设备从一个网络快速移动到另一个网络时捕获 和配置地址需要的时间。如果要尽量减小转换延时，RFC 4429 是理想选择。对于一般用途 设备，RFC 4429 目前仍然是可选项。 5-9-3 IPv6 中地址配置的隐私扩展 - RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration [RFC4941]处理涉及客户端设 备的特有问题，该客户端设备用户的活动或被跟踪位置受到关注。问题在于静态客户端和定 期改变其附着互联网的点的客户端。当使用 Stateless Address Autoconfiguration [RFC4862] 时，形成地址的 Interface Identifier 部分保持不变并且全球唯一。于是，如果节点改变它的附 着点，尽管节点的全球 IPv6 地址将改变，这些地址的 Interface Identifier 部分保持相同，这 能够让服务器跟踪个别设备的位置，如果该设备呆在一个地方，但走来走去或变动它的活动 方式。这或许出现在[RFC4862]中描述的隐私担忧。 在这类情况，应当执行 RFC 4941。在其他情况，诸如数据中心的专用服务器，RFC 4941 作用有限或没有意义。 RFC 4941 的实施者应当意识到某些地址是保留地址，不应当将其选用为临时地址。更 多细节请参阅“Reserved IPv6 Interface Identifiers”[RFC5453]。 5-9-4 IPv6 默认地址选择 - RFC 3484 必须执行在 Default Address Selection for IPv6 [RFC3484]中介绍的规则。IPv6 节点需要 处理同时配置的多个地址。 5-9-5 有状态地址自动配置(DHCPv6) - RFC 3315 DHCPv6 [RFC3315] 可 用 于 获 得 地 址 和 配 置 地 址 。 一 般 讲 ， 网 络 可 以 通 过 Router Advertisements、DHCPv6 或二者，提供地址配置。有各种各样的 IPv6 部署模式，在地址分 配要求上存在差异，其中一些可能要求用 DHCPv6 进行地址分配。因此，所有主机应当通 过 DHCPv6 执行地址配置。 在没有路由器的场景，使用 DHCP 进行地址分配的 IPv6 节点可以发起 DHCP，以便获 得 IPv6 地址和其他配置信息，如[RFC4862]第 5-5-2 节所述。
    5-10 IPv6 的多播监听者发现(MLD) 需要加入多播组的节点必须支持 MLDv1[RFC2710]。预期接收和处理多播流量的任何节 点需要 MLDv1。注意，Neighbor Discovery(当在大多数链路类型上使用，参阅第 5-2 节)依 靠多播，并且要求节点加入 Solicited Node 多播地址。 MLDv2 [RFC3810]通过支持 Source-Specific Multicast，扩展了 MLDv1 的功能。支持 Source-Specific Multicast [RFC4607]的原始 MLDv2 协议[RFC3810]支持两类“过滤器模式”。 使用 INCLUDE 过滤器，节点指出与该组发送者列表一起的多播组，节点希望从那个组接收 流量。使用 EXCLUDE 过滤器，节点指出与发送者列表一起的多播组，节点希望不从那个 组接收流量。在实践中，很少使用 EXCLUDE 模式阻塞源的操作，但是对 MLDv2 增加了很 大实现难度。轻型 MLDv2 [RFC5790]是原始 MLDv2 标准的简化子集，它省略了指定不想要 源的 EXCLUDE 过滤器模式。 节点应当或者执行 MLDv2 [RFC3810]，或者执行 Lightweight MLDv2 [RFC5790]。具体 来说，支持使用 Source-Specific Multicast 应用(该应用预期要用到 MLDv2 的 EXCLUDE 功 能[RFC3810])的节点必须支持在[RFC3810]、[RFC4604]和[RFC4607]中定义的 MLDv2。如果 节点支持预期仅需要用到 MLDv2 的 INCLUDE 功能以及 Any-Source Multicast 的应用，那么 支持在[RFC5790]中定义的 MLDv2 足矣。 如果节点仅支持使用 Any-Source Multicast 的应用(即，这些应用不使用 Source-Specific Multicast)，执行 MLDv1 [RFC2710]足矣。然而，在所有情况，强烈鼓励节点执行 MLDv2 或 Lightweight MLDv2 而不是 MLDv1，如果链路存在单个 MLDv1，那么要求该链路上所有 其他节点运行版本 1 兼容模式。 当使用 MLDv1 时，必须遵守 Multicast Listener Discovery (MLD) Protocol [RFC3590]的 Source Address Selection 中的规则。 第 6 章 主机配置采用 DHCP 还是采用路由器通告选项 在 IPv6 中，向主机传播配置信息主要有两个协议机制：Router Advertisements (RAs)和 DHCP。过去，RA 选项一直被限制在认为是对基本网络运行必不可少的选项上，对于这样 的选项用精确相同信息配置所有节点。例如 Prefix Information 选项、MTU 选项，等等。另 一方面，DHCP 通常偏重用于更一般参数的配置，以及偏重可能是客户端特有的参数。也就 是说，划出特定选项应当通过 DHCP 配置还是应当通过 RA 选项配置的分界线有时并不容 易。然而，一般讲，对于配置给定的选项希望仅定义一种机制，不希望定义配置相同信息的 多种(不同)方法。 用多种方法配置相同信息带来的问题是互操作性受损，如果主机选择一种机制而网络运 营商选择另一种机制。对于“紧密的”应用环境，那里网络运营商对什么设备连接到网上以 及这些设备支持什么配置机制有很大影响力，运营商能够确保所有连接上网的主机支持特定 机制。然而，在更开放的环境，那里可能连接任意设备(例如，WIFI 热点)，会出现问题。 为了最大限度提高这样环境的互操作性，主机需要执行多种配置机制，以便确保互操作性。 最初，在 IPv6 中，关于 DNS 服务器的配置信息只能通过 DHCP 执行。2007 年，定义 了 RA 选 项 ， 然 而 ， 是 作 为 Experimental [RFC5006] 颁 布 的 。 2010 年 ，“ IPv6 Router Advertisement Options for DNS Configuration”[RFC6106]作为 Standards Track 文档颁布。因 此，现在 DNS 配置信息能够或者通过 DHCP 或者通过 RAs 获得。主机需要决定应当执行哪 种(或者是两种)机制。关于 DNS 服务器发现的具体指导请参阅第 7 章的讨论。 第 7 章 DNS 和 DHCP
    分享到：
    赞 收藏

    相关推荐

    资料库

    网络技术

    共收录2367份资料，累计7个分类，关注成员有19位，主要包括：综合布线,网管软件,网络监控,网络设备,其它,系统集成,网络基础

    热门标签

    综合布线 网管软件 网络监控 网络设备 其它 系统集成 网络基础

    最新资料