[要約] RFC 3849は、IPv6アドレスプレフィックスのドキュメンテーション用に予約されたRFCです。その目的は、ネットワークドキュメンテーションやテスト目的で使用するための特定のIPv6アドレスプレフィックスを提供することです。
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）The Internet Society（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、書籍、ドキュメントなどの例で使用するために予約されています。Site-LocalおよびLink-Local UnicastアドレスはIPv6で特別な意味を持っているため、これらのアドレスは多くの例では使用できません。このドキュメントでは、IPv6アドレスプレフィックス2001：DB8 ::/32の使用について、ドキュメントで使用するための予約されたプレフィックスとして説明しています。
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]。
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ユニキャストアドレススペースは現在、予約されている、未割り当てとしてマークされている、または地域のインターネットレジストリ（RIRS）へのさらなる再分配のためにインターネットに割り当てられた数字当局（IANA）に割り当てられています[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.
Asia Pacific Regionalの受け入れ後、IPv6アドレススペースのブロックがドキュメント目的で予約される提案のコミュニティに住所を迎えた後、Asia Pacific Network Information Center（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
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.
これはローカル使用アドレスのプレフィックスではなく、フィルターはローカルコンテキストとパブリックコンテキストの両方で使用できます。
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アドレスアドレスレジストリのドキュメントのみのプレフィックスとしての割り当てを記録します。このアドレスを割り当てられるエンドパーティーはありません。
IPv6 addressing documents do not have any direct impact on Internet infrastructure security.
IPv6アドレス指定ドキュメントは、インターネットインフラストラクチャのセキュリティに直接影響を与えません。
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.
著者は、V6ドキュメンテーションプレフィックスの以前の提案を作成する際に、Alain Durand、Robert Elz、Bob Fink、およびDave Thalerの支援を受けたMarc Blanchetの作品を認めています。
[1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[1] Hinden、R。and S. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[2] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[2] Eastlake 3rd、D。およびA. Panitz、「予約済みのトップレベルDNS名」、BCP 32、RFC 2606、1999年6月。
[3] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[3] Haberman、B。およびD. Thaler、「Unicast-PrefixベースのIPv6マルチキャストアドレス」、RFC 3306、2002年8月。
Authors' Addresses
著者のアドレス
Geoff Huston Telstra
ジェフ・ヒューストン・テルストラ
EMail: gih@apnic.net
Anne Lord Asia Pacific Network Information Centre
アンロードアジア太平洋ネットワーク情報センター
EMail: anne@apnic.net
Philip Smith Cisco Systems
フィリップ・スミス・シスコ・システム
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）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。