Network Working Group G. Huston
Request for Comments: 5158 APNIC
Category: Informational March 2008
Network Working Group G. Huston
Request for Comments: 5158 APNIC
Category: Informational March 2008
6to4 Reverse DNS Delegation Specification
6to4反向DNS委派规范
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file. The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain. In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested 6to4 delegation address block.
此备忘录描述了将提供6to4 IPv6地址反向查找的DNS服务器委托输入6to4反向区域文件的服务机制。该机制基于传统的DNS委派服务接口，允许服务客户端为委派域输入多个DNS服务器的详细信息。在6to4反向委托的上下文中，客户机主要通过委托请求中使用的源地址进行身份验证，如果其IPv6地址前缀对应于请求的6to4委托地址块中的地址，则客户机有权使用该功能。
6to4 [RFC3056] defines a mechanism for allowing isolated IPv6 sites to communicate using IPv6 over the public IPv4 Internet. This is achieved through the use of a dedicated IPv6 global unicast address prefix. A 6to4 'router' can use its IPv4 address value in conjunction with this global prefix to create a local IPv6 site prefix. Local IPv6 hosts use this site prefix to form their local IPv6 address.
6to4[RFC3056]定义了一种机制，允许独立的IPv6站点通过公共IPv4 Internet使用IPv6进行通信。这是通过使用专用的IPv6全局单播地址前缀实现的。6to4“路由器”可以将其IPv4地址值与此全局前缀结合使用，以创建本地IPv6站点前缀。本地IPv6主机使用此站点前缀形成其本地IPv6地址。
This address structure allows any site that is connected to the IPv4 Internet the ability to use IPv6 via automatically created IPv6 over IPv4 tunnels. The advantage of this approach is that it allows the piecemeal deployment of IPv6 using tunnels to traverse IPv4 network segments. A local site can connect to an IPv6 network without necessarily obtaining IPv6 services from its adjacent upstream network provider.
此地址结构允许连接到IPv4 Internet的任何站点能够通过IPv4隧道上自动创建的IPv6使用IPv6。这种方法的优点是，它允许使用隧道逐段部署IPv6以穿越IPv4网段。本地站点可以连接到IPv6网络，而无需从其相邻的上游网络提供商处获得IPv6服务。
As noted in [6to4-dns], the advantage of this approach is that: "it decouples deployment of IPv6 by the core of the network (e.g. Internet Service Providers or ISPs) from deployment of IPv6 at the edges (e.g. customer sites), allowing each site or ISP to deploy IPv6 support in its own time frame according to its own priorities. With 6to4, the edges may communicate with one another using IPv6 even if one or more of their ISPs do not yet provide native IPv6 service."
如[6to4 dns]中所述，这种方法的优点是：“它将网络核心（如互联网服务提供商或ISP）部署IPv6与边缘（如客户站点）部署IPv6分离。”，允许每个站点或ISP根据自己的优先级在自己的时间范围内部署IPv6支持。使用6to4，即使其一个或多个ISP尚未提供本机IPv6服务，边缘也可以使用IPv6相互通信。”
The particular question here is the task of setting up a set of delegations that allows "reverse lookups" for this address space.
这里的特殊问题是建立一组允许对此地址空间进行“反向查找”的委托。
"[This] requires that there be a delegation path for the IP address being queried, from the DNS root to the servers for the [DNS] zone which provides the PTR records for that IP address. For ordinary IPv6 addresses, the necessary DNS servers and records for IPv6 reverse lookups would be maintained by the each organization to which an address block is delegated; the delegation path of DNS records reflects the delegation of address blocks themselves. However, for IPv6 addresses beginning with the 6to4 address prefix, the DNS records would need to reflect IPv4 address delegation. Since the entire motivation of 6to4 is to decouple site deployment of IPv6 from infrastructure deployment of IPv6, such records cannot be expected to be present for a site using 6to4 - especially for a site whose ISP did not yet support IPv6 in any form." [6to4-dns]
“[这]要求要查询的IP地址有一个从DNS根目录到[DNS]服务器的委派路径。”为该IP地址提供PTR记录的区域。对于普通IPv6地址，IPv6反向查找所需的DNS服务器和记录将由被委派地址块的每个组织维护；DNS记录的委派路径反映了地址块本身的委派。但是，对于IPv6地址从6to4地址前缀开始，DNS记录需要反映IPv4地址委派。由于6to4的全部动机是将IPv6的站点部署与IPv6的基础设施部署分离，因此对于使用6to4的站点，不可能出现此类记录，尤其是对于ISP尚未支持IPv6 i的站点n任何形式。”[6to4 dns]
The desired characteristics of a reverse lookup delegation mechanism are that it:
反向查找委派机制的预期特征是：
* is deployable with minimal overhead or tool development
* 可以以最小的开销或工具开发进行部署
* has no impact on existing DNS software and existing DNS operations
* 对现有DNS软件和现有DNS操作没有影响
* performs name lookup efficiently
* 有效地执行名称查找
* does not compromise any DNS security functions
* 不会损害任何DNS安全功能
There are a number of approaches to this problem, ranging from a conventional explicit delegation structure to various forms of modified server behaviors that attempt to guess the location of non-delegated servers for fragments of this address space. These approaches have been explored in some detail in terms of their advantages and drawbacks in [6to4-dns], so only a summary of these approaches will be provided here.
有很多方法可以解决这个问题，从传统的显式委托结构到各种形式的修改过的服务器行为，这些修改过的服务器行为试图猜测此地址空间片段的非委托服务器的位置。这些方法在[6to4 dns]中的优缺点已被详细探讨，因此这里仅提供这些方法的摘要。
The problem with this form of delegation is the anticipated piecemeal deployment of 6to4 sites. The reason why an end site would use 6to4 is commonly that the upstream Internet Service Provider does not support an IPv6 transit service and the end site is using 6to4 to tunnel through to IPv6 connectivity. A conventional end site environment of this form would have the end site using provider-based IPv4 addresses, where the end site's IPv4 address is a more specific address block drawn from the upstream provider's address block, and the end site would have an entry in the upstream provider's reverse DNS zone file, or it would have authoritative local name servers that are delegated from the upstream provider's DNS zone. In the case of the 6to4 mapped IPv6 space, the upstream may not be providing any IPv6-based services at all, and therefore would not be expected to have a 6to4 reverse DNS delegation for its IPv4 address block. The general observation is that 6to4 IPv6 reverse DNS delegations cannot necessarily always precisely match the corresponding IPv4 reverse DNS delegations.
这种委托形式的问题在于，预计会零碎地部署6to4站点。终端站点使用6to4的原因通常是上游Internet服务提供商不支持IPv6传输服务，并且终端站点使用6to4通过隧道连接到IPv6连接。这种形式的传统终端站点环境将使终端站点使用基于提供商的IPv4地址，其中终端站点的IPv4地址是从上游提供商的地址块中提取的更具体的地址块，并且终端站点将在上游提供商的反向DNS区域文件中有一个条目，或者，它将拥有从上游提供商的DNS区域委派的权威本地名称服务器。在6to4映射的IPv6空间的情况下，上游可能根本不提供任何基于IPv6的服务，因此不希望其IPv4地址块具有6to4反向DNS委托。一般的观察结果是，6to4 IPv6反向DNS委派不一定总是与相应的IPv4反向DNS委派精确匹配。
Sub-delegations of IPv4 provider address space are not consistently recorded, and any 6to4 reverse zone operator would be required to undertake reverse zone delegations in the absence of reliable current address assignment information, undertaking a "hop over" of the upstream provider's address block. Similarly, a delegated entity may need to support the same "hop over" when undertaking further delegations in their reverse zone.
IPv4提供程序地址空间的子委派没有一致的记录，任何6to4反向区域运营商都需要在没有可靠的当前地址分配信息的情况下进行反向区域委派，从而对上游提供程序的地址块进行“跳转”。同样，当在其反向区域进行进一步授权时，被授权实体可能需要支持相同的“跳过”。
One way to avoid such unreliable delegations is to alter server behavior for reverse servers in this zone. Where no explicit delegation information exists in the zone file, the server could look up the in-addr.arpa domain for the servers for the equivalent IPv4 address root used in the 6to4 address. These servers could then be queried for the IPv6 PTR query.
避免这种不可靠委托的一种方法是改变此区域中反向服务器的服务器行为。如果区域文件中不存在明确的委派信息，服务器可以在in-addr.arpa域中查找服务器的6to4地址中使用的等效IPv4地址根。然后可以针对IPv6 PTR查询查询这些服务器。
The issues with fielding altered server behaviors for this domain are not to be taken lightly, and the delegation chain for IPv4 will not be the same for 6to4 in any case. An isolated 6to4 site uses a single IPv4 /32 address, and it is improbable that a single address would have explicit in-addr.arpa delegation. In other words, it is not likely that the delegation for IPv4 would parallel that of 6to4.
不能轻视为该域部署已更改的服务器行为的问题，IPv4的委派链在任何情况下都不会与6to4相同。孤立的6to4站点使用单个IPv4/32地址，单个地址不可能有显式的in-addr.arpa委托。换句话说，IPv4的授权不太可能与6to4的授权并行。
Another approach uses an altered server to resolve non-delegated 6to4 reverse queries. The 6to4 query is decoded to recover the original 6to4 IP address. The site-specific part of the address is rewritten to a constant value, and this value is used as the target of a lookup query. This requires that a 6to4 site should reserve local addresses, and configure reverse servers on these addresses. Again, this is a weak approach in that getting the DNS to query non-delegated addresses is a case of generation of spurious traffic.
另一种方法是使用经过修改的服务器来解决非委托的6to4反向查询。对6to4查询进行解码以恢复原始6to4 IP地址。地址中特定于站点的部分将重写为常量值，该值将用作查找查询的目标。这要求6to4站点应保留本地地址，并在这些地址上配置反向服务器。同样，这是一种很弱的方法，因为让DNS查询非委托地址是一种产生虚假流量的情况。
The final approach considered here is to synthesize an answer when no explicit delegation exists. This approach would construct a pseudo host name using the IPv6 query address as the seed. Given that the host name has no valid forward DNS mapping, then this becomes a case of transforming one invalid DNS object into another.
这里考虑的最后一种方法是在不存在明确授权的情况下综合一个答案。这种方法将使用IPv6查询地址作为种子来构造一个伪主机名。假定主机名没有有效的前向DNS映射，则这将成为将一个无效DNS对象转换为另一个的情况。
It would appear that the most reasonable approach from this set of potential candidates is to support a model of conventional standard delegation. The consequent task is to reduce the administrative overheads in managing the zone, supporting delegation of reverse zone files on a basis of providing a delegation capability directly to each 6to4 site.
这组潜在候选人的最合理方法似乎是支持传统标准授权模式。随后的任务是减少管理区域的管理开销，支持反向区域文件的委派，前提是直接向每个6to4站点提供委派功能。
A 6to4 client network is an isolated IPv6 network composed as a set of IPv6 hosts and a dual stack (IPv4 and IPv6) local router connected to the local IPv6 network and the external IPv4 network.
6to4客户端网络是一个独立的IPv6网络，由一组IPv6主机和一个连接到本地IPv6网络和外部IPv4网络的双栈（IPv4和IPv6）本地路由器组成。
An example of a 6to4 network is as follows:
6to4网络的示例如下所示：
+-------------+
IPv6-in-IPv4 packets (A)| | IPv6 packets
------------------------| 6to4router |--------------------------
| | | | | | |
+-------------+ local IPv6 clients
+-------------+
IPv6-in-IPv4 packets (A)| | IPv6 packets
------------------------| 6to4router |--------------------------
| | | | | | |
+-------------+ local IPv6 clients
IPv4 network IPv6 network
IPv4网络IPv6网络
Figure 1
图1
The IPv4 address used as part of the generation of 6to4 addresses for the local IPv6 network is that of the external IPv4 network interface address (labelled '(A)' in the above diagram). For example, if the interface (A) has the IPv4 address 192.0.2.1, then the local IPv6 clients will use a common IPv6 address prefix of the form 2002: {192.0.2.1}::/48 (or (2002:C000:201::/48 in hex notation). All the local IPv6 clients share this common /48 address prefix, irrespective of any local IPv4 address that such host may use if they are operating in a dual stack mode.
作为本地IPv6网络6to4地址生成的一部分使用的IPv4地址是外部IPv4网络接口地址的地址（上图中标记为“（A）”。例如，如果接口（A）具有IPv4地址192.0.2.1，则本地IPv6客户端将使用格式为2002:{192.0.2.1}:：/48（或十六进制表示法中的（2002:C000:201:：/48）的公共IPv6地址前缀。所有本地IPv6客户端共享此公用/48地址前缀，而不考虑该主机在双堆栈模式下运行时可能使用的任何本地IPv4地址。
An example of a 6to4 network with addressing:
具有寻址功能的6to4网络示例：
+-------------+
IPv4 network (A)| | IPv6 network
-------------------| 6to4router |-------------
192.0.2.1| | | | | interface identifier
+-------------+ 1A | | local IPv6 address
2002:C000:201::1A
| |
1B |
2002:C000:201::1B
|
1C
2002:C000:201::1C
+-------------+
IPv4 network (A)| | IPv6 network
-------------------| 6to4router |-------------
192.0.2.1| | | | | interface identifier
+-------------+ 1A | | local IPv6 address
2002:C000:201::1A
| |
1B |
2002:C000:201::1B
|
1C
2002:C000:201::1C
Figure 2
图2
This specification uses a single delegation level in the 2.0.0.2.ip6.arpa zone (the ip6.arpa zone is specified in [RFC3596]), delegating zones only at the 48th bit position. This corresponds with individual delegations related to a single /32 IPv4 address, or the equivalent of a single 6to4 local site.
本规范在2.0.0.2.ip6.arpa区域中使用单一委派级别（ip6.arpa区域在[RFC3596]中规定），仅在第48位位置委派区域。这对应于与单个/32 IPv4地址或等效于单个6to4本地站点相关的单个委派。
The zone files containing the end site delegations are to be operated with a low TTL (configured to be a time value in the scale of hours rather than days or weeks), and updates for delegation requests in the 2.0.0.2.ipv6.arpa zone are to be made using dynamic DNS updates [RFC2136].
包含终端站点委派的区域文件将以较低的TTL（配置为以小时为单位的时间值，而不是以天或周为单位）进行操作，并使用动态DNS更新[RFC2136]对2.0.0.2.ipv6.arpa区域中的委派请求进行更新。
The delegation system is to be self-driven by clients residing within 6to4 networks. The 6to4 reverse DNS delegation function is to be accessible only by clients using 6to4 IPv6 source addresses, and the only delegation that can be managed is that corresponding to the /48 prefix of the IPv6 source address of the client.
委派系统由驻留在6to4网络内的客户机自行驱动。只有使用6to4 IPv6源地址的客户端才能访问6to4反向DNS委派功能，并且可以管理的唯一委派是与客户端IPv6源地址的/48前缀相对应的委派。
This service is to operate the delegation management service using web-based server access using Transport Layer Security (TLS) [RFC4346] (accessible via a "https:" URL). This is intended to ensure that the source address-driven delegation selection function cannot be disrupted through proxy caching of the web server's responses, and also to ensure that the delegation service cannot be readily mimicked.
此服务使用基于web的服务器访问（使用传输层安全性（TLS）[RFC4346]（可通过“https:”URL访问）来操作委派管理服务。这是为了确保源地址驱动的委派选择功能不会因web服务器响应的代理缓存而中断，同时也为了确保委派服务不会被轻易模仿。
The service is to be found at https://6to4.nro.net
The service is to be found at https://6to4.nro.net
This service is implemented by web servers that are operated on a dual-stack IPv4 / IPv6 server, accessible via SSL. The web server's actions will be determined by the source address of the client. If the client uses a 6to4 source address, the server will present a delegation interface for the corresponding 6to4 reverse zone. Otherwise, the server will provide a description of the delegation process.
此服务由在双栈IPv4/IPv6服务器上运行的web服务器实现，可通过SSL访问。web服务器的操作将由客户端的源地址决定。如果客户端使用6to4源地址，服务器将为相应的6to4反向区域提供一个委派接口。否则，服务器将提供委托过程的描述。
When accessed by a 6to4 source address, the interface presented by the delegation service is a conventional DNS delegation interface, allowing the client to enter the details of a number of DNS servers for the corresponding reverse domain. The targets of the DNS delegation are checked by the delegation manager using IPv4 and IPv6, according to the addresses of the targets, to ensure that they are responding, that they are configured consistently, and are authoritative for the delegated domain. If these conditions are met, the delegation details are entered into the zone at the primary master. In order to avoid the server being used as a denial of service platform, the server should throttle the number of DNS delegation requests made to any single IP address, and also throttle the number of redelegation requests for any single 6to4 zone.
当通过6to4源地址访问时，委派服务提供的接口是传统的DNS委派接口，允许客户端为相应的反向域输入多个DNS服务器的详细信息。DNS委派的目标由委派管理器使用IPv4和IPv6根据目标的地址进行检查，以确保它们正在响应、配置一致，并且对委派的域具有权威性。如果满足这些条件，则委派详细信息将输入到主控台的区域中。为了避免服务器被用作拒绝服务平台，服务器应限制向任何单个IP地址发出的DNS委派请求的数量，并限制任何单个6to4区域的重新委派请求的数量。
In other cases the system provides diagnostic information to the client.
在其他情况下，系统向客户端提供诊断信息。
The benefits of this structure include a fully automated mode of operation. The service delivery is on demand and the system only permits self-operation of the delegation function.
这种结构的优点包括完全自动化的操作模式。服务交付是按需提供的，系统仅允许委托功能的自行操作。
The potential issues with this structure include:
这种结构的潜在问题包括：
o Clients inside a 6to4 site could alter the delegation details without the knowledge of the site administrator. It is noted that this is intended for small-scale sites. Where there are potential issues of unauthorized access to this delegation function, the local site administrator could take appropriate access control measures.
o 6to4站点内的客户端可以在站点管理员不知情的情况下更改委派详细信息。值得注意的是，这是针对小型场地的。如果存在未经授权访问此委派功能的潜在问题，本地站点管理员可以采取适当的访问控制措施。
o IPv4 DHCP-based 6to4 sites, or any 6to4 site that uses dynamically-assigned external IPv4 interface addresses, could inherit nonsense reverse entries created by previous users of the dynamically assigned address. In this case, the client site could request delegation of the reverse zone as required. More generally, given the potentially for inheritance of 'stale' reverse DNS information in this context, in those cases where the issues of potential inheritance of 'stale' reverse DNS information is a concern, it is recommended that a 6to4 site either use a static IPv4 address in preference to a dynamically-assigned
o 基于IPv4 DHCP的6to4站点，或使用动态分配的外部IPv4接口地址的任何6to4站点，都可以继承动态分配地址的以前用户创建的无意义反向项。在这种情况下，客户站点可以根据需要请求反向区域的委派。更一般地说，考虑到在这种情况下可能继承“过时”反向DNS信息，在“过时”反向DNS信息的潜在继承问题令人担忧的情况下，建议6to4站点使用静态IPv4地址，而不是动态分配的IPv4地址
address, or ensure that the reverse delegation information is updated using the service mechanism described here upon each dynamic address assignment event.
地址，或确保在每次动态地址分配事件时使用此处描述的服务机制更新反向委派信息。
o The approach does not scale efficiently, as there is the potential that the flat zone file may grow considerably. However, it is noted that 6to4 is intended to be a transition mechanism useful for a limited period of time in a limited context of an isolated network where other forms of a tunnelled connection is not feasible. It is envisaged that at some point the density of IPv6 adoption in stub network would provide adequate drivers for widespread adoption of native IPv6 services, obviating the need for continued scaling of 6to4 support services. An estimate of the upper bound of the size of the 6to4 reverse delegation zone would be of the order of millions of entries. It is also noted that the value of a reverse delegation is a questionable proposition and many deployment environments have no form of reverse delegation.
o 该方法无法有效扩展，因为平面区域文件可能会大幅增长。然而，需要注意的是，6to4旨在成为在隔离网络的有限上下文中的有限时间段内有用的过渡机制，其中其他形式的隧道连接是不可行的。据设想，在某种程度上，存根网络中IPv6采用的密度将为广泛采用本机IPv6服务提供足够的驱动力，从而避免继续扩展6to4支持服务的需要。6to4反向授权区域大小上限的估计值大约为数百万个条目。还需要注意的是，反向委托的价值是一个值得怀疑的命题，许多部署环境都没有反向委托的形式。
o It is also conceivable that an enterprise network could decide to use 6to4 internally in some form of private context, with the hosts only visible in internal DNS servers. In this mechanism the reverse delegation, if desired, would need to be implemented in an internal private (non-delegated) corresponding zone of the 6to4 reverse domain space.
o 还可以想象，企业网络可以决定在某种形式的私有上下文中在内部使用6to4，主机仅在内部DNS服务器中可见。在这种机制中，如果需要，需要在6to4反向域空间的内部私有（非委托）对应区域中实现反向委托。
There may be circumstances where an IPv4 address controller wishes to "block" the ability for users of these addresses to use this 6to4 scheme. Scenarios that would motivate this concern would include situations when the IPv4 provider is also offering an IPv6 service, and native IPv6 should be deployed instead of 6to4. In such circumstances the 6to4 reverse zone operator should allow for such a 6to4 reverse delegation blocking function upon application to the delegation zone operator.
可能存在IPv4地址控制器希望“阻止”这些地址的用户使用此6to4方案的情况。引发这种担忧的场景包括IPv4提供商也提供IPv6服务，并且应该部署本机IPv6而不是6to4。在这种情况下，6to4反向区域运营商应在向授权区域运营商申请时允许这种6to4反向授权阻止功能。
For a delegation to be undertaken the following conditions should hold:
要进行授权，应具备以下条件：
o The 6to4 site must have configured a minimum of one primary and one secondary server for the 6to4 IPv6 reverse address zone.
o 6to4站点必须至少为6to4 IPv6反向地址区域配置了一台主服务器和一台辅助服务器。
o At the time of the delegation request, the primary and secondary servers must be online, reachable, correctly configured, and in a mutually consistent state with respect to the 6to4 reverse zone. In this context, "mutually consistent" implies the same SOA RR and identical NS RRSets.
o 在发出委派请求时，主服务器和辅助服务器必须联机、可访问、配置正确，并且与6to4反向区域处于相互一致的状态。在此上下文中，“相互一致”意味着相同的SOA RR和相同的NS RRSET。
o The 6to4 reverse delegation service will only accept delegation requests associated with the 6to4 source address of the requesting client.
o 6to4反向委派服务将仅接受与请求客户端的6to4源地址相关联的委派请求。
The approach described here, of a fully automated system driven by the site administrators of the 6to4 client networks, appears to represent an appropriate match of the operational requirements of managing reverse DNS domains for 6to4 addresses.
这里描述的由6to4客户端网络的站点管理员驱动的全自动系统的方法，似乎与管理6to4地址的反向DNS域的操作要求相匹配。
For maintenance of the reverse delegation zones the service maintains an email contact point for each active delegation, derived from the zone's SOA contact address (SOA RNAME), or explicitly entered in the delegation interface. This contact point would be informed upon any subsequent change of delegation details.
对于反向委派区域的维护，该服务为每个活动委派维护一个电子邮件联系点，该联系点来自该区域的SOA联系地址（SOA RNAME），或者显式地输入到委派接口中。代表团详细资料如有任何后续变更，将通知该联络点。
The 6to4 reverse DNS management system also undertakes a periodic sweep of all active delegations, so that each delegation is checked every 30 days. If the delegation fails this integrity check the email contact point is informed of the problem, and a further check is scheduled for 14 days later. If this second check fails, the delegation is automatically removed, and a further notice is issued to the contact point.
6to4反向DNS管理系统还定期扫描所有活动授权，以便每30天检查一次每个授权。如果委派未能通过此完整性检查，将通知电子邮件联系人问题，并计划在14天后进行进一步检查。如果第二次检查失败，委托将自动删除，并向联系人发出进一步通知。
This system offers a rudimentary level of assurance in attempting to ensure that delegation requests from a 6to4 site can only direct the delegation of the corresponding 6to4 reverse DNS domain and no other.
该系统在尝试确保来自6to4站点的委托请求只能指导相应6to4反向DNS域的委托而不能指导其他域的委托时提供了基本的保证。
Address-based authentication is not a very robust method from a security perspective, as addresses can be readily spoofed. Accordingly, reverse delegation information does not provide reliable information in either validating a domain name or in validating an IP address, and no conclusions should be drawn from the presence or otherwise of a reverse DNS mapping for any IP address.
从安全角度来看，基于地址的身份验证不是一种非常健壮的方法，因为地址很容易被伪造。因此，反向委托信息在验证域名或验证IP地址时都不能提供可靠的信息，并且不应从任何IP地址的反向DNS映射的存在或其他方面得出任何结论。
The service management interface allows a 6to4 client to insert any server name as a DNS server, potentially directing the delegation test system to make a DNS query to any nominated system. The server throttles the number of requests made to any single IP address to mitigate the attendant risk of a high volume of bogus DNS queries being generated by the server. For similar reasons, the server also throttles the number of redelegation requests for any single 6to4 zone.
服务管理接口允许6to4客户端插入任何服务器名称作为DNS服务器，从而潜在地指导委派测试系统对任何指定系统进行DNS查询。服务器限制对任何单个IP地址的请求数量，以降低服务器生成大量虚假DNS查询的伴随风险。出于类似的原因，服务器还限制任何单个6to4区域的重新委派请求数。
For a general threat analysis of 6to4, especially the additional risk of address spoofing in 2002::/16, see [RFC3964].
有关6to4的一般威胁分析，特别是2002年地址欺骗的额外风险：：/16，请参阅[RFC3964]。
Section 4 notes that the local site administrator could take appropriate access control measures to prevent clients inside a 6to4 site performing unauthorized changes to the delegation details. This may be in the form of a firewall configuration, regarding control of access to the service from the interior of a 6to4 site, or a similar mechanism that enforces local access policies.
第4节指出，本地站点管理员可以采取适当的访问控制措施，防止6to4站点内的客户端对委派详细信息进行未经授权的更改。这可以是防火墙配置的形式，关于从6to4站点内部访问服务的控制，或者是实施本地访问策略的类似机制。
The IANA has delegated the 2.0.0.2.ip6.arpa domain according to delegation instructions provided by the Internet Architecture Board.
IANA已根据互联网体系结构委员会提供的授权说明授权2.0.0.2.ip6.arpa域。
The author acknowledges the prior work of Keith Moore in preparing a document that enumerated a number of possible approaches to undertake the delegation and discovery of reverse zones. The author acknowledges the assistance of George Michaelson and Andrei Robachevsky in preparing this document, and Peter Koch, Pekka Savola, Jun-ichiro Itojun Hagino, and Catherine Meadows for their helpful review comments.
作者承认Keith Moore之前在准备一份文件时所做的工作，该文件列举了一些可能的方法来进行反向区的授权和发现。作者感谢乔治·迈克尔森（George Michaelson）和安德烈·罗巴切夫斯基（Andrei Robachevsky）在编写本文件过程中提供的协助，以及彼得·科赫（Peter Koch）、佩卡·萨沃拉（Pekka Savola）、伊藤俊一郎·哈吉诺（Jun ichiro Itojun Hagino）和凯瑟琳·梅多斯（Catherine Mead。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[6to4-dns] Moore, K., "6to4 and DNS", Work in Progress, April 2003.
[6to4 dns]Moore，K.，“6to4和dns”，正在进行的工作，2003年4月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964]Savola，P.和C.Patel，“6to4的安全考虑”，RFC 3964，2004年12月。
Author's Address
作者地址
Geoff Huston APNIC
杰夫·休斯顿呼吸暂停
EMail: gih@apnic.net
URI: http://www.apnic.net
EMail: gih@apnic.net
URI: http://www.apnic.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.
本文件受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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.