[要約] RFC 3769は、IPv6プレフィックスデリゲーションの要件を定義しています。その目的は、ISPが顧客にIPv6アドレスを効率的に割り当てるためのガイドラインを提供することです。
Network Working Group S. Miyakawa
Request for Comments: 3769 NTT Communications Corporation
Category: Informational R. Droms
Cisco
June 2004
Requirements for IPv6 Prefix Delegation
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
概要
This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or "site").
このドキュメントでは、IPv6アドレスのプレフィックスをIPv6サブスクライバーのネットワーク（または「サイト」）に委任する方法の要件について説明します。
With the deployment of IPv6 [1], several Internet Service Providers are ready to offer IPv6 access to the public. In conjunction with widely deployed "always on" media such as ADSL and the expectation that customers will be assigned a /48 IPv6 unicast address prefix (see RFC 3513 [3] and section 3 of RFC 3177 [2]), an efficient mechanism for delegating address prefixes to the customer's sites is needed. The delegation mechanism will be intended to automate the process of informing the customer's networking equipment of the prefixes to be used at the customer's site.
IPv6 [1]の展開により、いくつかのインターネットサービスプロバイダーがIPv6アクセスを一般に提供する準備ができています。ADSLなどの広く展開された「常に」メディアに並んで、顧客にA /48 IPv6ユニキャストアドレスプレフィックスが割り当てられるという期待（RFC 3513 [3]およびRFC 3177 [2]のセクション3を参照）、効率的なメカニズムのための効率的なメカニズムアドレスのプレフィックスを顧客のサイトに委任する必要があります。委任メカニズムは、顧客のサイトで使用するプレフィックスの顧客のネットワーキング機器に通知するプロセスを自動化することを目的としています。
This document clarifies the requirements for IPv6 address prefix delegation from the ISP to the site.
このドキュメントでは、ISPからサイトへのIPv6アドレスプレフィックス委任の要件を明確にします。
The following figure illustrates a likely example for the organization of a network providing subscription IPv6 service:
次の図は、サブスクリプションIPv6サービスを提供するネットワークの組織の可能性のある例を示しています。
/------\
/ \
+ |
/ \ /
+---------------+ +--------+/ \------/
|ISP Edge Router|Point-to-point|Customer+
| +--------------+ Router | Customer networks
| (PE) | link | (CPE) +
+---------------+ +--------+\ /------\
\ / \
+ |
\ /
\------/
Figure 1: Illustration of ISP-customer network architecture
図1：ISPカスタマーネットワークアーキテクチャの図
Terminology:
用語：
PE: Provider edge device; the device connected to the service provider's network infrastructure at which the link to the customer site is terminated
PE：プロバイダーエッジデバイス。顧客サイトへのリンクが終了するサービスプロバイダーのネットワークインフラストラクチャに接続されたデバイス
CPE: Customer premises equipment; the device at the customer site at which the link to the ISP is terminated
CPE：顧客施設機器。ISPへのリンクが終了する顧客サイトのデバイス
The purpose of the prefix delegation mechanism is to delegate and manage prefixes to the CPE automatically.
プレフィックス委任メカニズムの目的は、CPEにプレフィックスを自動的に委任および管理することです。
The prefix delegation mechanism should allow for delegation of prefixes of lengths between /48 and /64, inclusively. Other lengths should also be supported. The mechanism should allow for delegation of more than one prefix to the customer.
接頭辞委任メカニズムは、 /48と /64の間の長さのプレフィックスの委任を包括的に可能にする必要があります。他の長さもサポートする必要があります。メカニズムにより、顧客への複数のプレフィックスの委任が可能になります。
The prefix delegation mechanism must not prohibit or inhibit the assignment of longer prefixes, created from the delegated prefixes, to links within the customer network. The prefix delegation mechanism is not required to report any prefix delegations within the customer's network back to the ISP.
接頭辞委任メカニズムは、委任されたプレフィックスから作成された長いプレフィックスの割り当てを顧客ネットワーク内のリンクに禁止または阻害してはなりません。プレフィックス委任メカニズムは、顧客のネットワーク内のプレフィックス委任をISPに報告するために必要ではありません。
The prefix delegation mechanism should allow for long-lived static pre-assignment of prefixes and for automated, possibly short-lived, on-demand, dynamic assignment of prefixes to a customer.
接頭辞委任メカニズムは、プレフィックスの長期的な静的事前割り当て、および自動化された、おそらく短命のオンデマンドで、プレフィックスの顧客への動的な割り当てを可能にする必要があります。
The prefix delegation mechanism should allow for the use of policy in assigning prefixes to a customer. For example, the customer's identity and type of subscribed service may be used to determine the address block from which the customer's prefix is selected, and the length of the prefix assigned to the customer.
接頭辞委任メカニズムは、プレフィックスを顧客に割り当てる際にポリシーを使用できるようにする必要があります。たとえば、顧客の身元とサブスクライブサービスの種類を使用して、顧客のプレフィックスが選択されているアドレスブロックと、顧客に割り当てられたプレフィックスの長さを決定することができます。
The CPE must be able to express requirements or preferences in its request to the PE. For example, the CPE should be able to express a preference for a prefix length.
CPEは、PEへの要求において要件または好みを表現できる必要があります。たとえば、CPEはプレフィックスの長さの好みを表すことができるはずです。
The prefix delegation mechanism must provide for reliable authentication of the identity of the customer to which the prefixes are to be assigned, and must provide for reliable, secure transmission of the delegated prefixes to the customer.
プレフィックス委任メカニズムは、接頭辞を割り当てる顧客のIDの信頼できる認証を提供する必要があり、委任されたプレフィックスを顧客に信頼できる安全な送信を提供する必要があります。
The prefix delegation should provide for reliable authentication of the identity of the service provider's edge router.
プレフィックス委任は、サービスプロバイダーのEdgeルーターのIDの信頼できる認証を提供する必要があります。
The prefix delegation mechanism must allow for the ISP to obtain accounting information about delegated prefixes from the PE.
接頭辞委任メカニズムは、ISPがPEから委任されたプレフィックスに関する会計情報を取得することを許可する必要があります。
The prefix delegation mechanism should work on any hardware link technology between the PE and the CPE and should be hardware technology independent. The mechanism must work on shared links.
プレフィックス委任メカニズムは、PEとCPEの間のハードウェアリンクテクノロジーで機能する必要があり、ハードウェアテクノロジーに依存する必要があります。メカニズムは、共有リンクで動作する必要があります。
The mechanism should work with all hardware technologies with either an authentication mechanism or without, but ISPs would like to take advantage of the hardware technology's authentication mechanism if it exists.
このメカニズムは、認証メカニズムまたはなしですべてのハードウェアテクノロジーで動作する必要がありますが、ISPは、ハードウェアテクノロジーの認証メカニズムが存在する場合は利用したいと考えています。
Section 3.6 specifies security requirements for the prefix delegation mechanism. For point to point links, where one trusts that there is no man in the middle, or one trusts layer two authentication, authentication may not be necessary.
セクション3.6は、プレフィックス委任メカニズムのセキュリティ要件を指定します。ポイントツーポイントリンクの場合、真ん中に人がいないと信頼している場合、または1人が2つの認証をレイヤーに信頼すると、認証は必要ない場合があります。
A rogue PE can issue bogus prefixes to a requesting router. This may cause denial of service due to unreachability.
Rogue PEは、リクエストルーターに偽の接頭辞を発行できます。これは、到達不能のためにサービスの拒否を引き起こす可能性があります。
A rogue CPE may be able to mount a denial of service attack by repeated requests for delegated prefixes that exhaust the PE's available prefixes.
Rogue CPEは、PEの使用可能なプレフィックスを排出する委任されたプレフィックスの繰り返しリクエストにより、サービス拒否攻撃を取り付けることができる場合があります。
The authors would like to express thanks to Randy Bush, Thomas Narten, Micheal Py, Pekka Savola, Dave Thaler, as well as other members of the IPv6 working group and the IESG for their review and constructive comments. The authors would also like to thank the people in the IPv6 operation group of the Internet Association of Japan and NTT Communications IPv6 project, especially Toshi Yamasaki and Yasuhiro Shirasaki for their original discussion and suggestions.
著者は、Randy Bush、Thomas Narten、Micheal Py、Pekka Savola、Dave Thaler、およびIPv6ワーキンググループの他のメンバーとIESGのレビューと建設的なコメントに感謝します。著者はまた、日本インターネット協会のIPv6オペレーショングループとNTT通信IPv6プロジェクト、特にヤマサキとYasuhiro Shirasakiの元の議論と提案に感謝したいと思います。
[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[1] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[2] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address", RFC 3177, September 2001.
[2] IABおよびIESG、「IPv6アドレスに関するIAB/IESG推奨」、RFC 3177、2001年9月。
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[3] Hinden、R。and S. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
Shin Miyakawa NTT Communications Corporation Tokyo Japan
Shin Miyakawa NTT Communications Corporation東京日本
Phone: +81-3-6800-3262
EMail: miyakawa@nttv6.jp
Ralph Droms Cisco 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Ralph Droms Cisco 1414 Massachusetts Avenue Boxborough、MA 01719 USA
Phone: +1 978.936.1674
EMail: rdroms@cisco.com
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エディター機能の資金は現在、インターネット協会によって提供されています。