Network Working Group Y. Shirasaki
Request for Comments: 4241 S. Miyakawa
Category: Informational T. Yamasaki
NTT Communications
A. Takenouchi
NTT
December 2005
Network Working Group Y. Shirasaki
Request for Comments: 4241 S. Miyakawa
Category: Informational T. Yamasaki
NTT Communications
A. Takenouchi
NTT
December 2005
A Model of IPv6/IPv4 Dual Stack Internet Access Service
IPv6/IPv4双栈Internet接入服务模型
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 (2005).
版权所有（C）互联网协会（2005年）。
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。IETF不承认任何关于本RFC适用于任何目的的知识，并指出，除了IESG审查与IETF工作的冲突外，发布决定并非基于IETF审查。RFC编辑已自行决定发布本文件。有关更多信息，请参阅RFC 3932。
Abstract
摘要
This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide a IPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically.
本备忘录是NTT Communications双栈ADSL接入服务的用户网络接口规范摘要，该服务为家庭用户提供IPv6/IPv4双栈服务。为了简化用户设置，这些服务具有自动配置IPv6特定参数的机制。备忘录重点关注两个基本参数：分配给用户的前缀和IPv6 DNS服务器的地址，并指定了自动将这些参数传递给客户场所设备（CPE）的方法。
This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide IPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically.
本备忘录是NTT Communications双栈ADSL接入服务的用户网络接口规范摘要，该服务为家庭用户提供IPv6/IPv4双栈服务。为了简化用户设置，这些服务具有自动配置IPv6特定参数的机制。备忘录重点关注两个基本参数：分配给用户的前缀和IPv6 DNS服务器的地址，并指定了自动将这些参数传递给客户场所设备（CPE）的方法。
This memo covers two topics: an architecture for IPv6/IPv4 dual stack access service and an automatic configuration function for IPv6- specific parameters.
本备忘录涵盖两个主题：IPv6/IPv4双栈访问服务的体系结构和IPv6特定参数的自动配置功能。
The architecture is mainly targeted at a leased-line ADSL service for home users. It assumes that there is a Point-to-Point Protocol (PPP) logical link between Customer Premises Equipment (CPE) and Provider Edge (PE) equipment. In order to exclude factors that are specific to access lines, this architecture only specifies PPP and its upper layers. To satisfy [RFC3177], the prefix length that is delegated to the CPE is /48, but /64 is also a possible option.
该架构主要针对家庭用户的专线ADSL服务。它假设在客户场所设备（CPE）和提供商边缘（PE）设备之间存在点对点协议（PPP）逻辑链路。为了排除特定于接入线的因素，该体系结构仅指定PPP及其上层。为了满足[RFC3177]，委托给CPE的前缀长度为/48，但/64也是一个可能的选项。
In this architecture, IPv6/IPv4 dual stack service is specified as follows.
在此体系结构中，IPv6/IPv4双栈服务的指定如下。
o IPv6 and IPv4 connectivities are provided over a single PPP logical link.
o IPv6和IPv4连接通过单个PPP逻辑链路提供。
o IPv6 connectivity is independent of IPv4 connectivity. IPV6CP and IPCP work independently over a single PPP logical link.
o IPv6连接独立于IPv4连接。IPV6CP和IPCP在单个PPP逻辑链路上独立工作。
Figure 1 shows an outline of the service architecture. NTT Communications has been providing a commercial service based on this architecture since the Summer 2002.
图1显示了服务体系结构的概要。自2002年夏天以来，NTT Communications一直在提供基于此架构的商业服务。
| _____________
[HOST]-+ +-----------+ +----------+ / \
| | Customer | ADSL line | Provider | | ISP core and |
+-+ Premises +---------------+ Edge |--| The internet |
| | Equipment | to subscriber +-----+----+ \_____________/
[HOST]-+ +-----------+ | | |
| +-----+------+ | +-+----------+
| AAA server | | | DNS server |
+------------+ | +------------+
+-+--------------+
| NTP server etc.|
Figure 1: Dual Stack Access Service Architecture +----------------+
| _____________
[HOST]-+ +-----------+ +----------+ / \
| | Customer | ADSL line | Provider | | ISP core and |
+-+ Premises +---------------+ Edge |--| The internet |
| | Equipment | to subscriber +-----+----+ \_____________/
[HOST]-+ +-----------+ | | |
| +-----+------+ | +-+----------+
| AAA server | | | DNS server |
+------------+ | +------------+
+-+--------------+
| NTP server etc.|
Figure 1: Dual Stack Access Service Architecture +----------------+
The automatic configuration function aims at simplification of user setup. Usually, users have to configure at least two IPv6-specific parameters: prefix(es) assigned to them [RFC3769] and IPv6 DNS servers' addresses. The function is composed of two sub-functions:
自动配置功能旨在简化用户设置。通常，用户必须配置至少两个特定于IPv6的参数：分配给他们的前缀[RFC3769]和IPv6 DNS服务器的地址。该功能由两个子功能组成：
o Delegation of prefix(es) to be used in the user site.
o 要在用户站点中使用的前缀的委派。
o Notification of IPv6 DNS server addresses and/or other server addresses.
o IPv6 DNS服务器地址和/或其他服务器地址的通知。
Section 2 of this memo details the user/network interface. Section 3 describes an example connection sequence.
本备忘录第2节详细介绍了用户/网络接口。第3节描述了一个示例连接序列。
This section describes details of the user/network interface specification. Only PPP over Ethernet (PPPoE) and its upper layers are mentioned; the other layers, such as Ethernet and lower layers, are out of scope. IPv4-related parameter configuration is also out of scope.
本节介绍用户/网络接口规范的详细信息。仅提及以太网PPP（PPPoE）及其上层；其他层，如以太网和较低层，超出范围。IPv4相关参数配置也超出范围。
The service uses PPP connection and Challenge Handshake Authentication Protocol (CHAP) authentication to identify each CPE. The CPE and PE handle both the PPP Internet Protocol Control Protocol (IPCP) [RFC1332] and the Internet Protocol V6 Control Protocol (IPV6CP) [RFC2472] identically and simultaneously over a single PPP connection. This means either the CPE or the PE can open/close any Network Control Protocol (NCP) session at any time without any side-effect for the other. It is intended that users can choose among three services: IPv4 only, IPv6 only, and IPv4/IPv6 dual stack. A CPE connected to an ADSL line discovers a PE with the PPPoE mechanism [RFC2516].
该服务使用PPP连接和质询握手身份验证协议（CHAP）身份验证来识别每个CPE。CPE和PE在单个PPP连接上以相同方式同时处理PPP互联网协议控制协议（IPCP）[RFC1332]和互联网协议V6控制协议（IPV6CP）[RFC2472]。这意味着CPE或PE可以随时打开/关闭任何网络控制协议（NCP）会话，而不会对另一方产生任何副作用。用户可以在三种服务中进行选择：仅IPv4、仅IPv6和IPv4/IPv6双栈。连接到ADSL线路的CPE发现具有PPPoE机制的PE[RFC2516]。
Note that, because CPE and PE can negotiate only their interface identifiers with IPV6CP, PE and CPE can use only link-local-scope addresses before the prefix delegation mechanism described below is run.
注意，由于CPE和PE只能与IPV6CP协商其接口标识符，因此在运行下面描述的前缀委派机制之前，PE和CPE只能使用链路本地作用域地址。
After IPV6CP negotiation, the CPE initiates a prefix delegation request. The PE chooses a global-scope prefix for the CPE with information from an Authentication, Authorization, and Accounting (AAA) server or local prefix pools, and it delegates the prefix to the CPE. Once the prefix is delegated, the prefix is subnetted and assigned to the local interfaces of the CPE. The CPE begins sending
在IPV6CP协商之后，CPE发起前缀委派请求。PE使用来自身份验证、授权和计费（AAA）服务器或本地前缀池的信息为CPE选择全局作用域前缀，并将前缀委托给CPE。一旦该前缀被委派，该前缀将被子网化并分配给CPE的本地接口。CPE开始发送消息
router advertisements for the prefixes on each link. Eventually, hosts can acquire global-scope prefixes through conventional IPv6 stateless [RFC2462] or stateful auto-configuration mechanisms ([RFC3315], etc.) and begin to communicate using global-scope addresses.
每个链路上前缀的路由器广告。最终，主机可以通过传统的IPv6无状态[RFC2462]或有状态自动配置机制（[RFC3315]等）获取全局作用域前缀，并开始使用全局作用域地址进行通信。
The PE delegates prefixes to CPE using Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] with the prefix delegation options [RFC3633]. The sequence for prefix delegation is as follows:
PE使用IPv6动态主机配置协议（DHCPv6）[RFC3315]和前缀委派选项[RFC3633]将前缀委派给CPE。前缀委派的顺序如下所示：
o The CPE requests prefix(es) from a PE by sending a DHCPv6 Solicit message that has a link-local source address negotiated by IPV6CP, mentioned in the previous section, and includes an IA_PD option.
o CPE通过发送DHCPv6请求消息从PE请求前缀，DHCPv6请求消息具有由IPV6CP协商的链路本地源地址，如前一节所述，并包括IA_PD选项。
o An AAA server provides prefix(es) to the PE or the PE chooses prefix(es) from its local pool, and the PE returns an Advertise message that contains an IA_PD option and IA_PD Prefix options. The prefix-length in the IA_PD Prefix option is 48.
o AAA服务器向PE提供前缀或PE从其本地池中选择前缀，PE返回包含IA_PD选项和IA_PD前缀选项的播发消息。IA_PD prefix选项中的前缀长度为48。
IA_PD option and IA_PD Prefix options for the chosen prefix(es) back to the PE.
IA_PD选项和所选前缀的IA_PD前缀选项返回PE。
o The PE confirms the prefix(es) in the Request message in a Reply message.
o PE在回复消息中确认请求消息中的前缀。
If IPV6CP is terminated or restarted by any reason, CPE must initiate a Rebind/Reply message exchange as described in [RFC3633].
如果IPV6CP因任何原因终止或重新启动，CPE必须按照[RFC3633]中的说明启动重新绑定/回复消息交换。
The CPE assigns global-scope /64 prefixes, subnetted from the delegated prefix, to its downstream interfaces. When the delegated prefix has an infinite lifetime, the preferred and valid lifetimes of assigned /64 prefixes should be the default values in [RFC2461].
CPE将全局作用域/64前缀分配给其下游接口，该前缀从委托前缀中分为子网。当委派前缀具有无限生存期时，分配的/64前缀的首选和有效生存期应为[RFC2461]中的默认值。
Because a link-local address is already assigned to the CPE's upstream interface, global-scope address assignment for that interface is optional.
由于链路本地地址已分配给CPE的上游接口，因此该接口的全局作用域地址分配是可选的。
The CPE and PE use static routing between them, and no routing protocol traffic is necessary.
CPE和PE之间使用静态路由，不需要路由协议流量。
The CPE configures its PPPoE logical interface or the link-local address of PE as the IPv6 default gateway, automatically after the prefix delegation exchange.
CPE在前缀委派交换后自动将其PPPoE逻辑接口或PE的链路本地地址配置为IPv6默认网关。
When the CPE receives packets that are destined for the addresses in the delegated /48 prefix, the CPE must not forward the packets to a PE. The CPE should return ICMPv6 Destination Unreachable message to a source address or silently discard the packets, when the original packet is destined for the unassigned prefix in the delegated prefix. (For example, the CPE should install a reject route or null interface as next hop for the delegated prefix.)
当CPE接收到以委派/48前缀中的地址为目的地的数据包时，CPE不得将数据包转发给PE。CPE应将ICMPv6 Destination Unreachable message返回到源地址，或在原始数据包以委托前缀中的未分配前缀为目的地时以静默方式丢弃数据包。（例如，CPE应安装拒绝路由或空接口作为委托前缀的下一跳。）
The service provides IPv6 recursive DNS servers in the ISP site. The PE notifies the global unicast addresses of these servers with the Domain Name Server option that is described in [RFC3646], in Advertise/Reply messages on the prefix delegation message exchange.
该服务在ISP站点中提供IPv6递归DNS服务器。PE使用[RFC3646]中所述的域名服务器选项通知这些服务器的全局单播地址，在前缀委派消息交换的播发/回复消息中。
Devices connected to user network may learn a recursive DNS server address with the mechanism described in [RFC3736].
连接到用户网络的设备可以使用[RFC3736]中描述的机制学习递归DNS服务器地址。
The CPE may serve as a local DNS proxy server and include its address in the DNS server address list. This is easy to implement, because it is analogous to IPv4 SOHO router (192.168.0.1 is a DNS proxy server and a default router in most sites).
CPE可以用作本地DNS代理服务器，并将其地址包括在DNS服务器地址列表中。这很容易实现，因为它类似于IPv4 SOHO路由器（192.168.0.1是DNS代理服务器，在大多数站点中是默认路由器）。
The PE may notify other IPv6-enabled server addresses, such as Network Time Protocol servers [RFC4075], SIP servers [RFC3319], etc., in an Advertise/Reply message on the prefix delegation message exchange, if those are available.
PE可以在前缀委派消息交换上的播发/回复消息中通知其他启用IPv6的服务器地址，如网络时间协议服务器[RFC4075]、SIP服务器[RFC3319]等（如果这些地址可用）。
ICMPv6 Echo Request will be sent to the user network for connectivity monitoring in the service. The CPE must return a single IPv6 Echo Reply packet when it receives an ICMPv6 Echo Request packet. The health-check packets are addressed to a subnet-router anycast address for the delegated prefix.
ICMPv6回显请求将发送到用户网络，以便在服务中进行连接监控。CPE在收到ICMPv6回显请求数据包时必须返回单个IPv6回显回复数据包。健康检查数据包被发送到代理前缀的子网路由器选播地址。
The old document of APNIC IPv6 address assignment policy required that APNIC could ping the subnet anycast address to check address usage.
APNIC IPv6地址分配策略的旧文档要求APNIC可以ping子网选播地址以检查地址使用情况。
To achieve this requirement, for example, once the prefix 2001:db8:ffff::/48 is delegated, the CPE must reply to the ICMPv6 Echo Request destined for 2001:db8:ffff:: any time that IPV6CP and DHCPv6-PD are up for the upstream direction. Because some implementations couldn't reply when 2001:db8:ffff::/64 was assigned to its downstream physical interface and the interface was down, such an implementation should assign 2001:db8:ffff::/64 for the loopback interface, which is always up, and 2001:db8:ffff:1::/64, 2001:db8:ffff:2::/64, etc., to physical interfaces.
为实现此要求，例如，一旦委派前缀2001:db8:ffff:：/48，则CPE必须在IPV6CP和DHCPv6 PD向上游方向运行的任何时间回复发送至2001:db8:ffff:：的ICMPv6回显请求。由于某些实现在将2001:db8:ffff:：/64分配给其下游物理接口且接口关闭时无法响应，因此此类实现应将2001:db8:ffff:：/64分配给始终处于打开状态的环回接口，并将2001:db8:ffff:1:：/64、2001:db8:ffff:2:：/64等分配给物理接口。
CPE PE
| |
|----------PADI-------->| \
|<---------PADO---------| | PPPoE
|----------PADR-------->| | Discovery Stage
|<---------PADS---------| /
| |
|---Configure-Request-->| \
|<--Configure-Request---| | PPP Link Establishment Phase
|<----Configure-Ack-----| | (LCP)
|-----Configure-Ack---->| /
| |
|<------Challenge-------| \
|-------Response------->| | PPP Authentication Phase (CHAP)
|<-------Success--------| /
| |
|---Configure-Request-->| \
|<--Configure-Request---| |
|<----Configure-Nak-----| | PPP Network Layer Protocol Phase
|<----Configure-Ack-----| | (IPCP)
|---Configure-Request-->| |
|<----Configure-Ack-----| /
| |
|---Configure-Request-->| \
|<--Configure-Request---| | PPP Network Layer Protocol Phase
|<----Configure-Ack-----| | (IPV6CP)
|-----Configure-Ack---->| /
| |
|--------Solicit------->| \
|<------Advertise-------| | DHCPv6
|--------Request------->| |
|<--------Reply---------| /
| |
CPE PE
| |
|----------PADI-------->| \
|<---------PADO---------| | PPPoE
|----------PADR-------->| | Discovery Stage
|<---------PADS---------| /
| |
|---Configure-Request-->| \
|<--Configure-Request---| | PPP Link Establishment Phase
|<----Configure-Ack-----| | (LCP)
|-----Configure-Ack---->| /
| |
|<------Challenge-------| \
|-------Response------->| | PPP Authentication Phase (CHAP)
|<-------Success--------| /
| |
|---Configure-Request-->| \
|<--Configure-Request---| |
|<----Configure-Nak-----| | PPP Network Layer Protocol Phase
|<----Configure-Ack-----| | (IPCP)
|---Configure-Request-->| |
|<----Configure-Ack-----| /
| |
|---Configure-Request-->| \
|<--Configure-Request---| | PPP Network Layer Protocol Phase
|<----Configure-Ack-----| | (IPV6CP)
|-----Configure-Ack---->| /
| |
|--------Solicit------->| \
|<------Advertise-------| | DHCPv6
|--------Request------->| |
|<--------Reply---------| /
| |
Figure 2: Example of Connection Sequence
图2：连接顺序示例
Figure 2 is an example of a normal link-up sequence, from start of PPPoE to start of IPv6/IPv4 communications. IPv4 communication becomes available after IPCP negotiation. IPv6 communication with link-local scope addresses becomes possible after IPV6CP negotiation. IPv6 communication with global-scope addresses becomes possible after prefix delegation and conventional IPv6 address configuration mechanism. IPCP is independent of IPV6CP and prefix delegation.
图2是从PPPoE开始到IPv6/IPv4通信开始的正常连接顺序的示例。IPCP协商后IPv4通信可用。IPV6CP协商后，可以使用链路本地作用域地址进行IPv6通信。在前缀委派和传统IPv6地址配置机制之后，与全局作用域地址的IPv6通信成为可能。IPCP独立于IPV6CP和前缀委托。
In this architecture, the PE and CPE trust the point-to-point link between them; they trust that there is no man-in-the-middle and they trust PPPoE authentication. Because of this, DHCP authentication is not considered necessary and is not used.
在此架构中，PE和CPE信任它们之间的点对点链路；他们相信中间没有人，他们相信PPPoE认证。因此，DHCP身份验证不被认为是必要的，也不被使用。
The service provides an always-on global-scope prefix for users. Each device connected to user network has global-scope addresses. Without any packet filters, devices might be accessible from outside the user network in that case. The CPE and each device involved in the service should have functionality to protect against unauthorized accesses, such as a stateful inspection packet filter. The relationship between CPE and devices connected to the user network for this problem should be considered in the future.
该服务为用户提供始终处于全局作用域前缀。连接到用户网络的每个设备都有全局作用域地址。在这种情况下，如果没有任何数据包过滤器，设备可以从用户网络外部访问。CPE和服务中涉及的每个设备应具有防止未经授权访问的功能，如有状态检查包过滤器。未来应考虑CPE与连接到该问题的用户网络的设备之间的关系。
Thanks are given for the input and review by Tatsuya Sato, Hideki Mouri, Koichiro Fujimoto, Hiroki Ishibashi, Ralph Droms, Ole Troan, Pekka Savola, and IPv6-ops-IAJapan members.
感谢佐藤达夫、茂井秀树、藤本光一郎、石桥广基、拉尔夫·卓姆斯、奥特隆、佩卡·萨沃拉和日本成员的投入和评论。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177]IAB和IESG，“IAB/IESG对站点IPv6地址分配的建议”，RFC3177，2001年9月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC1332，1992年5月。
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[RFC2472]Haskin，D.和E.Allen，“PPP上的IP版本6”，RFC 24721998年12月。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2516]Mamakos，L.，Lidl，K.，Evarts，J.，Carrel，D.，Simone，D.，和R.Wheeler，“通过以太网传输PPP（PPPoE）的方法”，RFC 2516，1999年2月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。RFC3633，2003年12月。
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646]Droms，R.，“IPv6动态主机配置协议（DHCPv6）的DNS配置选项”，RFC 36462003年12月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6", RFC 4075, May 2005.
[RFC4075]Kalusialingam，V.，“DHCPv6的简单网络时间协议（SNTP）配置选项”，RFC 4075，2005年5月。
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.
[RFC3319]Schulzrinne，H.和B.Volz，“会话启动协议（SIP）服务器的动态主机配置协议（DHCPv6）选项”，RFC 3319，2003年7月。
[RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, June 2004.
[RFC3769]Miyakawa，S.和R.Droms，“IPv6前缀委托的要求”，RFC 3769，2004年6月。
Authors' Addresses
作者地址
Yasuhiro Shirasaki NTT Communications Corporation Tokyo Opera City Tower 21F 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan
日本新宿市西新宿市东京歌剧城21楼3-20-2号，东京新宿市，邮编163-1421
EMail: yasuhiro@nttv6.jp
EMail: yasuhiro@nttv6.jp
Shin Miyakawa, Ph. D NTT Communications Corporation Tokyo Opera City Tower 21F 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan
新三川，博士，NTT通信公司东京歌剧城21楼3-20-2西新宿，新宿东京163-1421
EMail: miyakawa@nttv6.jp
EMail: miyakawa@nttv6.jp
Toshiyuki Yamasaki NTT Communications Corporation 1-1-6 Uchisaiwaicho, Chiyoda-ku Tokyo 100-8019, Japan
日本东京千代田区内石湾1-1-6号山崎俊之NTT通信公司，东京100-8019
EMail: t.yamasaki@ntt.com
EMail: t.yamasaki@ntt.com
Ayako Takenouchi NTT Cyber Solutions Laboratories, NTT Corporation 3-9-11 Midori-Cho, Musashino-Shi Tokyo 180-8585, Japan
Ayako Takenouchi NTT网络解决方案实验室，NTT公司3-9-11 Midori Cho，武藏县，东京180-8585
EMail: takenouchi.ayako@lab.ntt.co.jp
EMail: takenouchi.ayako@lab.ntt.co.jp
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org/copyright.html中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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编辑功能的资金目前由互联网协会提供。