Network Working Group                                          G. Huston
Request for Comments: 3849                                       Telstra
Category: Informational                                          A. Lord
                                                                   APNIC
                                                                P. Smith
                                                                   Cisco
                                                               July 2004
        
Network Working Group                                          G. Huston
Request for Comments: 3849                                       Telstra
Category: Informational                                          A. Lord
                                                                   APNIC
                                                                P. Smith
                                                                   Cisco
                                                               July 2004
        

IPv6 Address Prefix Reserved for Documentation

IPv6地址前缀保留供文档使用

Status of this Memo

本备忘录的状况

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2004).

版权所有(C)互联网协会(2004年)。

Abstract

摘要

To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation.

为了减少将记录的示例与已部署的系统关联时发生冲突和混淆的可能性,保留IPv6单播地址前缀,以便在RFC、书籍、文档等中的示例中使用。由于站点本地和链路本地单播地址在IPv6中具有特殊意义,因此在许多示例情况下无法使用这些地址。本文档介绍了IPv6地址前缀2001:DB8::/32作为保留前缀在文档中的使用。

1. Introduction
1. 介绍

The address architecture for IPv6 [1] does not specifically allocate an IPv6 address prefix for use for documentation purposes. Documentation material is currently using address prefixes drawn from address blocks already allocated or assigned to existing organizations or to well known ISPs, or drawn from the currently unallocated address pool. Such use conflicts with existing or future allocations or assignments of IPv6 address space.

IPv6[1]的地址体系结构没有专门分配IPv6地址前缀用于文档编制。文档资料当前使用的地址前缀来自已分配或分配给现有组织或知名ISP的地址块,或来自当前未分配的地址池。这种使用与IPv6地址空间的现有或未来分配或分配冲突。

The problems such conflicts may cause have already been encountered with IPv4 where literal use of documented examples in a production environment causes address and routing conflicts with existing services. In making an explicit allocation of a documentation address prefix, it is intended that such operational problems may be avoided for IPv6.

这些冲突可能导致的问题在IPv4中已经遇到,在生产环境中使用文档化示例会导致地址和路由与现有服务发生冲突。在对文档地址前缀进行显式分配时,旨在避免IPv6出现此类操作问题。

Similar, but different, discussion also applies to top level domain names and some have been reserved for similar purposes [2].

类似但不同的讨论也适用于顶级域名,有些域名已保留用于类似目的[2]。

2. Documentation IPv6 Address Prefix
2. 文档IPv6地址前缀

To allow documentation to accurately describe deployment examples, the use of site local or link local addresses is inappropriate, and a unicast address block is required. All IPv6 unicast address space is currently marked as reserved, unassigned or has been assigned to the Internet Assigned Numbers Authority (IANA) for further redistribution to the Regional Internet Registries (RIRs) [1], but no unicast address space has been specifically nominated for the purposes of use in documented examples.

为了使文档能够准确描述部署示例,使用站点本地地址或链接本地地址是不合适的,并且需要单播地址块。所有IPv6单播地址空间目前都标记为保留、未分配或已分配给互联网分配号码管理局(IANA),以便进一步重新分配给区域互联网注册中心(RIR)[1],但没有专门指定单播地址空间用于有文件记录的示例中。

Following acceptance within the Asia Pacific regional addressing community of a proposal for a block of IPv6 address space to be reserved for documentation purposes, the Asia Pacific Network Information Centre (APNIC) allocated a unicast address prefix for documentation purposes. The address block is within the range of a conventional allocation size, so that documentation can accurately match deployment scenarios.

亚太区域寻址社区内部接受了一项建议,即保留一块IPv6地址空间用于文档编制,亚太网络信息中心(APNIC)分配了一个单播地址前缀用于文档编制。地址块在常规分配大小的范围内,因此文档可以准确地匹配部署场景。

The documentation prefix described in this memo can also be used to generate multicast addresses for documentation, using the Unicast prefix-based proposal [3]. Representing other kinds of multicast addresses in documentation is outside the scope of this memo.

本备忘录中描述的文档前缀也可用于使用基于单播前缀的方案[3]生成文档的多播地址。在文档中表示其他类型的多播地址超出了本备忘录的范围。

   The prefix allocated for documentation purposes is 2001:DB8::/32
        
   The prefix allocated for documentation purposes is 2001:DB8::/32
        
3. Operational Implications
3. 业务影响

This assignment implies that IPv6 network operators should add this address prefix to the list of non-routeable IPv6 address space, and if packet filters are deployed, then this address prefix should be added to packet filters.

此分配意味着IPv6网络运营商应将此地址前缀添加到不可路由的IPv6地址空间列表中,如果部署了数据包筛选器,则应将此地址前缀添加到数据包筛选器中。

This is not a local-use address prefix, and the filters may be used in both local and public contexts.

这不是本地使用地址前缀,筛选器可以在本地和公共上下文中使用。

4. IANA Considerations
4. IANA考虑

IANA is to record the allocation of the IPv6 global unicast address prefix 2001:DB8::/32 as a documentation-only prefix in the IPv6 address registry. No end party is to be assigned this address.

IANA将IPv6全局单播地址前缀2001:DB8::/32的分配记录为IPv6地址注册表中的仅文档前缀。不得向任何终端方分配此地址。

5. Security Considerations
5. 安全考虑

IPv6 addressing documents do not have any direct impact on Internet infrastructure security.

IPv6寻址文档对Internet基础设施安全没有任何直接影响。

6. Acknowledgements
6. 致谢

The authors acknowledge the work of Marc Blanchet, assisted by Alain Durand, Robert Elz, Bob Fink, and Dave Thaler, in authoring a previous proposal for a V6 documentation prefix.

作者感谢Marc Blanchet在Alain Durand、Robert Elz、Bob Fink和Dave Thaler的协助下为V6文档前缀编写了先前的提案。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.

[1] Hinden,R.和S.Deering,“互联网协议版本6(IPv6)寻址体系结构”,RFC 3513,2003年4月。

7.2. Informative References
7.2. 资料性引用

[2] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.

[2] Eastlake 3rd,D.和A.Panitz,“保留顶级域名”,BCP 32,RFC 26061999年6月。

[3] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.

[3] Haberman,B.和D.Thaler,“基于单播前缀的IPv6多播地址”,RFC3306,2002年8月。

Authors' Addresses

作者地址

Geoff Huston Telstra

杰夫休斯顿电信

   EMail: gih@apnic.net
        
   EMail: gih@apnic.net
        

Anne Lord Asia Pacific Network Information Centre

安妮洛德亚太网络信息中心

   EMail: anne@apnic.net
        
   EMail: anne@apnic.net
        

Philip Smith Cisco Systems

菲利普史密斯思科系统公司

   EMail: pfs@cisco.com
        
   EMail: pfs@cisco.com
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

版权所有(C)互联网协会(2004年)。本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件及其包含的信息是按“原样”提供的,贡献者、他/她所代表或赞助的组织(如有)、互联网协会和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。