Internet Engineering Task Force (IETF)                          R. Droms
Request for Comments: 7346                                         Cisco
Updates: 4007, 4291                                          August 2014
Category: Standards Track
ISSN: 2070-1721
        
Internet Engineering Task Force (IETF)                          R. Droms
Request for Comments: 7346                                         Cisco
Updates: 4007, 4291                                          August 2014
Category: Standards Track
ISSN: 2070-1721
        

IPv6 Multicast Address Scopes

IPv6多播地址作用域

Abstract

摘要

This document updates the definitions of IPv6 multicast scopes and therefore updates RFCs 4007 and 4291.

本文档更新了IPv6多播作用域的定义,因此更新了RFCs 4007和4291。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7346.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc7346.

Copyright Notice

版权公告

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2014 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下,不得在IETF标准流程之外修改本文件,也不得在IETF标准流程之外创建其衍生作品,除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。

1. Introduction
1. 介绍

RFC 4291 [RFC4291] defines "scop" as "a 4-bit multicast scope value used to limit the scope of the multicast group" and defines "scop 3" as "reserved". The multicast protocol specification in [MPL] desires to use multicast scop 3 to transport multicast traffic scoped to a network of nodes connected in a mesh. This scop value is used to accommodate a multicast scope that is greater than Link-Local but is also automatically determined by the network architecture.

RFC 4291[RFC4291]将“scop”定义为“用于限制多播组范围的4位多播作用域值”,并将“scop 3”定义为“保留”。[MPL]中的多播协议规范希望使用多播scop 3将多播通信量传输到连接在网状网中的节点网络。此scop值用于容纳大于本地链路的多播范围,但也由网络体系结构自动确定。

2. Definition of IPv6 Multicast Address Scopes (Updates RFC 4291)
2. IPv6多播地址范围的定义(更新RFC 4291)

The following table updates the definitions in [RFC4291]:

下表更新了[RFC4291]中的定义:

      +------+--------------------------+-------------------------+
      | scop | NAME                     | REFERENCE               |
      +------+--------------------------+-------------------------+
      |  0   | Reserved                 | [RFC4291], RFC 7346     |
      |  1   | Interface-Local scope    | [RFC4291], RFC 7346     |
      |  2   | Link-Local scope         | [RFC4291], RFC 7346     |
      |  3   | Realm-Local scope        | [RFC4291], RFC 7346     |
      |  4   | Admin-Local scope        | [RFC4291], RFC 7346     |
      |  5   | Site-Local scope         | [RFC4291], RFC 7346     |
      |  6   | Unassigned               |                         |
      |  7   | Unassigned               |                         |
      |  8   | Organization-Local scope | [RFC4291], RFC 7346     |
      |  9   | Unassigned               |                         |
      |  A   | Unassigned               |                         |
      |  B   | Unassigned               |                         |
      |  C   | Unassigned               |                         |
      |  D   | Unassigned               |                         |
      |  E   | Global scope             | [RFC4291], RFC 7346     |
      |  F   | Reserved                 | [RFC4291], RFC 7346     |
      +------+--------------------------+-------------------------+
        
      +------+--------------------------+-------------------------+
      | scop | NAME                     | REFERENCE               |
      +------+--------------------------+-------------------------+
      |  0   | Reserved                 | [RFC4291], RFC 7346     |
      |  1   | Interface-Local scope    | [RFC4291], RFC 7346     |
      |  2   | Link-Local scope         | [RFC4291], RFC 7346     |
      |  3   | Realm-Local scope        | [RFC4291], RFC 7346     |
      |  4   | Admin-Local scope        | [RFC4291], RFC 7346     |
      |  5   | Site-Local scope         | [RFC4291], RFC 7346     |
      |  6   | Unassigned               |                         |
      |  7   | Unassigned               |                         |
      |  8   | Organization-Local scope | [RFC4291], RFC 7346     |
      |  9   | Unassigned               |                         |
      |  A   | Unassigned               |                         |
      |  B   | Unassigned               |                         |
      |  C   | Unassigned               |                         |
      |  D   | Unassigned               |                         |
      |  E   | Global scope             | [RFC4291], RFC 7346     |
      |  F   | Reserved                 | [RFC4291], RFC 7346     |
      +------+--------------------------+-------------------------+
        

The following change is applied to Section 2.7 of [RFC4291].

以下变更适用于[RFC4291]第2.7节。

OLD:

旧的:

Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non-multicast-related configuration.

Admin Local scope是必须进行管理配置的最小范围,即不能自动从物理连接或其他与多播无关的配置派生。

NEW:

新的:

Interface-Local, Link-Local, and Realm-Local scope boundaries are automatically derived from physical connectivity or other non-multicast-related configurations. Global scope has no boundary. The boundaries of all other non-reserved scopes of Admin-Local or larger are administratively configured. For reserved scopes, the way of configuring their boundaries will be defined when the semantics of the scope are defined.

接口本地、链路本地和领域本地作用域边界自动从物理连接或其他与多播无关的配置派生。全局范围没有边界。Admin Local或更大的所有其他非保留作用域的边界都是以管理方式配置的。对于保留范围,将在定义范围的语义时定义其边界的配置方式。

According to RFC 4007 [RFC4007], the zone of a Realm-Local scope must fall within zones of larger scope. Because the zone of a Realm-Local scope is configured automatically while the zones of larger scopes are configured manually, care must be taken in the

根据RFC 4007[RFC4007],领域本地范围的区域必须位于范围更大的区域内。由于域本地作用域的区域是自动配置的,而较大作用域的区域是手动配置的,因此在配置时必须小心

definition of those larger scopes to ensure that the inclusion constraint is met.

定义那些更大的范围,以确保满足包含约束。

Realm-Local scopes created by different network technologies are considered to be independent and will have different zone indices (see Section 6 of [RFC4007]). A router with interfaces on links using different network technologies does not forward traffic between the Realm-Local multicast scopes defined by those technologies.

由不同网络技术创建的领域本地范围被认为是独立的,并且具有不同的区域索引(参见[RFC4007]第6节)。在使用不同网络技术的链路上具有接口的路由器不会在这些技术定义的领域本地多播作用域之间转发流量。

3. Definition of Realm-Local Scopes
3. 领域局部作用域的定义

The definition of any Realm-Local scope for a particular network technology should be published in an RFC. For example, such a scope definition would be appropriate for publication in an "IPv6-over-foo" RFC.

特定网络技术的任何领域本地范围的定义应在RFC中公布。例如,这样的范围定义适合在“IPv6 over foo”RFC中发布。

Any RFCs that include the definition of a Realm-Local scope will be added to the IANA "IPv6 Multicast Address Scopes" registry under the Realm-Local scope entry, and those specifications must include such a request in their IANA Considerations.

任何包含领域本地作用域定义的RFC都将添加到IANA“IPv6多播地址作用域”注册表中的领域本地作用域条目下,这些规范必须在IANA注意事项中包含此类请求。

Section 5 of this document gives the definition of scop 3 for IEEE 802.15.4 [IEEE802.15.4] networks.

本文件第5节给出了IEEE 802.15.4[IEEE802.15.4]网络scop 3的定义。

4. Definition of Automatic and Administratively Configured Scopes (Updates RFC 4007)

4. 自动和管理配置范围的定义(更新RFC 4007)

Section 5 of RFC 4007 [RFC4007] and Section 2.7 of RFC 4291 [RFC4291] disagree on the way in which multicast scop 3 is configured. To resolve that disagreement, the last bullet in the list in Section 5 of [RFC4007] is updated as follows:

RFC 4007[RFC4007]第5节和RFC 4291[RFC4291]第2.7节对多播scop 3的配置方式存在分歧。为解决该分歧,[RFC4007]第5节列表中的最后一个项目符号更新如下:

OLD:

旧的:

o The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators.

o 网络管理员必须定义和配置除接口本地、链路本地和全局之外的作用域的区域边界。

NEW:

新的:

o The boundaries of zones of a scope are defined by the IPv6 addressing architecture [RFC4291] and updated by RFC 7346.

o 作用域的区域边界由IPv6寻址体系结构[RFC4291]定义,并由RFC 7346更新。

5. Definition of Realm-Local Scope for IEEE 802.15.4
5. IEEE 802.15.4领域本地范围的定义

When used in an IP-over-IEEE802.15.4 network, scop 3 is defined to include all interfaces sharing a Personal Area Network Identifier (PAN ID).

当在IP-over-IEEE802.15.4网络中使用时,scop 3定义为包括共享个人区域网络标识符(PAN ID)的所有接口。

6. IANA Considerations
6. IANA考虑

IANA has established a sub-registry titled "IPv6 Multicast Address Scopes" in the existing "IPv6 Multicast Address Space Registry". The new registry has been populated with the scop values given in Section 2. New definitions for scop values will be made following the "IETF Review" policy [RFC5226].

IANA在现有的“IPv6多播地址空间注册表”中建立了一个名为“IPv6多播地址范围”的子注册表。已使用第2节中给出的scop值填充新注册表。scop值的新定义将遵循“IETF审查”政策[RFC5226]。

For each future RFC that defines a Realm-Local scope for new network technologies (scop 3), IANA will add a reference to the defining document in the "IPv6 Multicast Address Scopes" registry. Such RFCs are expected to make an explicit request to IANA for inclusion in the registry.

对于未来定义新网络技术领域本地范围(scop 3)的每个RFC,IANA将在“IPv6多播地址范围”注册表中添加对定义文档的引用。预计此类RFC将向IANA提出明确请求,要求将其纳入注册中心。

IANA has included a note on the top of the "IPv6 Multicast Address Scopes" registry:

IANA在“IPv6多播地址范围”注册表的顶部包含了一个注释:

The definition of any Realm-Local scope for a particular network technology should be published in an RFC. For example, such a scope definition would be appropriate for publication in an 'IPv6- over-foo' RFC.

特定网络技术的任何领域本地范围的定义应在RFC中公布。例如,这样的范围定义适合在“IPv6-over-foo”RFC中发布。

Any RFCs that define a Realm-Local scope will be listed in this registry as an additional reference in the Realm-Local scope entry. Such RFCs are expected to make an explicit request to IANA for inclusion in this registry.

任何定义领域本地范围的RFC都将在此注册表中作为领域本地范围条目中的附加引用列出。预计此类RFC将向IANA发出明确请求,要求将其纳入本注册中心。

7. Acknowledgments
7. 致谢

Robert Cragie, Kerry Lynn, Jinmei Tatuya, Dave Thaler, and Stig Venaas all contributed text and/or review to ensure that the updates to RFC 4007 and RFC 4291 are correct.

Robert Cragie、Kerry Lynn、Jinmei Tatuya、Dave Thaler和Stig Venaas都提供了文本和/或审查,以确保RFC 4007和RFC 4291的更新是正确的。

8. Security Considerations
8. 安全考虑

This document has no security considerations beyond those in RFC 4007 [RFC4007] and RFC 4291 [RFC4291].

除RFC 4007[RFC4007]和RFC 4291[RFC4291]中的安全注意事项外,本文件没有其他安全注意事项。

9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.

[RFC4007]Deering,S.,Haberman,B.,Jinmei,T.,Nordmark,E.,和B.Zill,“IPv6作用域地址体系结构”,RFC 4007,2005年3月。

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[RFC4291]Hinden,R.和S.Deering,“IP版本6寻址体系结构”,RFC 42912006年2月。

9.2. Informative References
9.2. 资料性引用

[IEEE802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2006", October 2006.

[IEEE802.15.4]IEEE计算机协会,“IEEE标准802.15.4-2006”,2006年10月。

[MPL] Hui, J. and R. Kelsey, "Multicast Protocol for Low power and Lossy Networks (MPL)", Work in Progress, April 2014.

[MPL]Hui,J.和R.Kelsey,“低功耗和有损网络的多播协议(MPL)”,正在进行的工作,2014年4月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226]Narten,T.和H.Alvestrand,“在RFCs中编写IANA注意事项部分的指南”,BCP 26,RFC 5226,2008年5月。

Author's Address

作者地址

Ralph Droms Cisco 1414 Massachusetts Avenue Boxborough, MA 01719 USA

美国马萨诸塞州伯斯堡马萨诸塞大道1414号,邮编01719

   Phone: +1 978 936 1674
   EMail: rdroms.ietf@gmail.com
        
   Phone: +1 978 936 1674
   EMail: rdroms.ietf@gmail.com