Network Working Group S. Miyakawa
Request for Comments: 3769 NTT Communications Corporation
Category: Informational R. Droms
Cisco
June 2004
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）互联网协会（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）以及客户将被分配一个/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) +
+---------------+ +--------+\ /------\
\ / \
+ |
\ /
\------/
/------\
/ \
+ |
/ \ /
+---------------+ +--------+/ \------/
|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.
前缀委派机制必须提供对要分配前缀的客户身份的可靠身份验证，并且必须提供委派前缀到客户的可靠、安全传输。
The prefix delegation should provide for reliable authentication of the identity of the service provider's edge router.
前缀委托应提供服务提供商边缘路由器身份的可靠认证。
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节规定了前缀委派机制的安全要求。对于点对点链接，其中信任中间没有人，或者信任一层二认证，认证可能是不必要的。
A rogue PE can issue bogus prefixes to a requesting router. This may cause denial of service due to unreachability.
流氓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.
流氓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项目的人员，特别是山崎骏和白崎康弘的原始讨论和建议。
[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[1] Deering，S.和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，“IAB/IESG关于IPv6地址的建议”，RFC3177，2001年9月。
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[3] Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
Shin Miyakawa NTT Communications Corporation Tokyo Japan
日本东京新三川NTT通信公司
Phone: +81-3-6800-3262
EMail: miyakawa@nttv6.jp
Phone: +81-3-6800-3262
EMail: miyakawa@nttv6.jp
Ralph Droms Cisco 1414 Massachusetts Avenue Boxborough, MA 01719 USA
美国马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
Phone: +1 978.936.1674
EMail: rdroms@cisco.com
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）互联网协会（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编辑功能的资金目前由互联网协会提供。