RFC 3364: Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) 中文翻译

URL : https://datatracker.ietf.org/doc/html/rfc3364
标题 : RFC 3364
翻译类型 : 自动生成

Network Working Group                                         R. Austein
Request for Comments: 3364                           Bourgeois Dilettant
Updates: 2673, 2874                                          August 2002
Category: Informational

Network Working Group                                         R. Austein
Request for Comments: 3364                           Bourgeois Dilettant
Updates: 2673, 2874                                          August 2002
Category: Informational

Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)

Internet协议版本6（IPv6）的域名系统（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

摘要

The IETF has two different proposals on the table for how to do DNS support for IPv6, and has thus far failed to reach a clear consensus on which approach is better. This note attempts to examine the pros and cons of each approach, in the hope of clarifying the debate so that we can reach closure and move on.

IETF就如何为IPv6提供DNS支持提出了两个不同的建议，但迄今为止未能就哪种方法更好达成明确共识。本说明试图研究每种方法的利弊，希望澄清这场辩论，以便我们能够达成结论并继续前进。

Introduction

介绍

RFC 1886 [RFC1886] specified straightforward mechanisms to support IPv6 addresses in the DNS. These mechanisms closely resemble the mechanisms used to support IPv4, with a minor improvement to the reverse mapping mechanism based on experience with CIDR. RFC 1886 is currently listed as a Proposed Standard.

RFC 1886[RFC1886]指定了直接的机制来支持DNS中的IPv6地址。这些机制与用于支持IPv4的机制非常相似，只是根据CIDR的经验对反向映射机制进行了一些小的改进。RFC 1886目前被列为拟定标准。

RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6 addresses in the DNS. These mechanisms provide new features that make it possible for an IPv6 address stored in the DNS to be broken up into multiple DNS resource records in ways that can reflect the network topology underlying the address, thus making it possible for the data stored in the DNS to reflect certain kinds of network topology changes or routing architectures that are either impossible or more difficult to represent without these mechanisms. RFC 2874 is also currently listed as a Proposed Standard.

RFC 2874[RFC2874]指定了增强机制以支持DNS中的IPv6地址。这些机制提供了新的功能，使存储在DNS中的IPv6地址能够以能够反映该地址下的网络拓扑的方式分解为多个DNS资源记录，因此，使存储在DNS中的数据能够反映某些类型的网络拓扑变化或路由架构，如果没有这些机制，这些网络拓扑变化或路由架构是不可能或更难以表示的。RFC 2874目前也被列为拟议标准。

Both of these Proposed Standards were the output of the IPNG Working Group. Both have been implemented, although implementation of [RFC1886] is more widespread, both because it was specified earlier and because it's simpler to implement.

这两项拟议标准都是IPNG工作组的成果。虽然[RFC1886]的实现更为广泛，但这两种方法都已经实现了，这既因为它是较早指定的，也因为它更易于实现。

There's little question that the mechanisms proposed in [RFC2874] are more general than the mechanisms proposed in [RFC1886], and that these enhanced mechanisms might be valuable if IPv6's evolution goes in certain directions. The questions are whether we really need the more general mechanism, what new usage problems might come along with the enhanced mechanisms, and what effect all this will have on IPv6 deployment.

毫无疑问，[RFC2874]中提出的机制比[RFC1886]中提出的机制更具普遍性，如果IPv6朝着特定方向发展，这些增强机制可能是有价值的。问题是我们是否真的需要更通用的机制，增强的机制可能会带来哪些新的使用问题，以及所有这些都会对IPv6部署产生什么影响。

The one thing on which there does seem to be widespread agreement is that we should make up our minds about all this Real Soon Now.

有一件事似乎得到了广泛的认同，那就是我们现在应该很快对这一切下定决心。

Main Advantages of Going with A6

使用A6的主要优势

While the A6 RR proposed in [RFC2874] is very general and provides a superset of the functionality provided by the AAAA RR in [RFC1886], many of the features of A6 can also be implemented with AAAA RRs via preprocessing during zone file generation.

虽然[RFC2874]中提出的A6 RR非常通用，并提供了[RFC1886]中AAAA RR提供的功能的超集，但A6的许多功能也可以通过区域文件生成期间的预处理使用AAAA RR实现。

There is one specific area where A6 RRs provide something that cannot be provided using AAAA RRs: A6 RRs can represent addresses in which a prefix portion of the address can change without any action (or perhaps even knowledge) by the parties controlling the DNS zone containing the terminal portion (least significant bits) of the address. This includes both so-called "rapid renumbering" scenarios (where an entire network's prefix may change very quickly) and routing architectures such as the former "GSE" proposal [GSE] (where the "routing goop" portion of an address may be subject to change without warning). A6 RRs do not completely remove the need to update leaf zones during all renumbering events (for example, changing ISPs would usually require a change to the upward delegation pointer), but careful use of A6 RRs could keep the number of RRs that need to change during such an event to a minimum.

有一个特定区域，A6 RRs提供使用AAAA RRs无法提供的内容：A6 RRs可以表示地址的前缀部分可以在控制包含地址终端部分（最低有效位）的DNS区域的各方不采取任何行动（甚至可能不知道）的情况下更改的地址。这包括所谓的“快速重新编号”场景（其中整个网络的前缀可能会很快改变）和路由架构，如前一个“GSE”方案[GSE]（其中地址的“路由阻塞”部分可能会在没有警告的情况下改变）。A6 RRs并不能完全消除在所有重新编号事件期间更新叶区的需要（例如，更改ISP通常需要更改向上的委派指针），但谨慎使用A6 RRs可以将在此类事件期间需要更改的RRs数量保持在最低限度。

Note that constructing AAAA RRs via preprocessing during zone file generation requires exactly the sort of information that A6 RRs store in the DNS. This begs the question of where the hypothetical preprocessor obtains that information if it's not getting it from the DNS.

请注意，在区域文件生成期间通过预处理构建AAAA RRs需要的信息与A6 RRs存储在DNS中的信息完全相同。这就引出了这样一个问题：如果假设的预处理器没有从DNS获取信息，那么它将从何处获取该信息。

Note also that the A6 RR, when restricted to its zero-length-prefix form ("A6 0"), is semantically equivalent to an AAAA RR (with one "wasted" octet in the wire representation), so anything that can be done with an AAAA RR can also be done with an A6 RR.

还要注意的是，当A6 RR限制为其零长度前缀形式（“A6 0”）时，它在语义上等同于AAAA RR（线表示中有一个“浪费”的八位字节），因此任何可以用AAAA RR完成的事情也可以用A6 RR完成。

Main Advantages of Going with AAAA

使用AAAA的主要优势

The AAAA RR proposed in [RFC1886], while providing only a subset of the functionality provided by the A6 RR proposed in [RFC2874], has two main points to recommend it:

[RFC1886]中提出的AAAA RR虽然只提供了[RFC2874]中提出的A6 RR所提供功能的一个子集，但有两个主要建议：

- AAAA RRs are essentially identical (other than their length) to IPv4's A RRs, so we have more than 15 years of experience to help us predict the usage patterns, failure scenarios and so forth associated with AAAA RRs.

- AAAA RRs本质上与IPv4的A RRs相同（长度不同），因此我们有超过15年的经验来帮助我们预测与AAAA RRs相关的使用模式、故障场景等。

- The AAAA RR is "optimized for read", in the sense that, by storing a complete address rather than making the resolver fetch the address in pieces, it minimizes the effort involved in fetching addresses from the DNS (at the expense of increasing the effort involved in injecting new data into the DNS).

- AAAA RR“针对读取进行了优化”，即通过存储完整的地址而不是让解析程序逐段获取地址，它将从DNS获取地址所需的工作量降至最低（以增加向DNS注入新数据所需的工作量为代价）。

Less Compelling Arguments in Favor of A6

支持A6的不那么令人信服的论据

Since the A6 RR allows a zone administrator to write zone files whose description of addresses maps to the underlying network topology, A6 RRs can be construed as a "better" way of representing addresses than AAAA. This may well be a useful capability, but in and of itself it's more of an argument for better tools for zone administrators to use when constructing zone files than a justification for changing the resolution protocol used on the wire.

由于A6 RR允许区域管理员写入区域文件，其地址描述映射到底层网络拓扑，因此A6 RRs可以解释为比AAAA更好的地址表示方式。这很可能是一种有用的功能，但就其本身而言，它更多的是一个论点，即区域管理员在构建区域文件时需要使用更好的工具，而不是更改在线上使用的解析协议的理由。

Less Compelling Arguments in Favor of AAAA

支持AAAA的不那么令人信服的论点

Some of the pressure to go with AAAA instead of A6 appears to be based on the wider deployment of AAAA. Since it is possible to construct transition tools (see discussion of AAAA synthesis, later in this note), this does not appear to be a compelling argument if A6 provides features that we really need.

使用AAAA而不是A6的一些压力似乎是基于AAAA的更广泛部署。由于可以构造转换工具（参见本说明后面的AAAA合成讨论），如果A6提供了我们真正需要的功能，这似乎不是一个令人信服的论点。

Another argument in favor of AAAA RRs over A6 RRs appears to be that the A6 RR's advanced capabilities increase the number of ways in which a zone administrator could build a non-working configuration. While operational issues are certainly important, this is more of argument that we need better tools for zone administrators than it is a justification for turning away from A6 if A6 provides features that we really need.

支持AAAA RRs而非A6 RRs的另一个论点似乎是A6 RR的高级功能增加了区域管理员构建非工作配置的方式。虽然操作问题当然很重要，但这更多的是我们需要为区域管理员提供更好的工具，而不是如果A6提供了我们真正需要的功能，那么就放弃A6的理由。

Potential Problems with A6

A6的潜在问题

The enhanced capabilities of the A6 RR, while interesting, are not in themselves justification for choosing A6 if we don't really need those capabilities. The A6 RR is "optimized for write", in the sense that, by making it possible to store fragmented IPv6 addresses in the DNS, it makes it possible to reduce the effort that it takes to inject new data into the DNS (at the expense of increasing the effort involved in fetching data from the DNS). This may be justified if we expect the effort involved in maintaining AAAA-style DNS entries to be prohibitive, but in general, we expect the DNS data to be read more frequently than it is written, so we need to evaluate this particular tradeoff very carefully.

A6 RR的增强功能虽然令人感兴趣，但如果我们真的不需要这些功能，其本身并不是选择A6的理由。A6 RR“针对写入进行了优化”，也就是说，通过在DNS中存储分段IPv6地址，可以减少向DNS中注入新数据所需的工作量（代价是增加从DNS获取数据所需的工作量）。如果我们认为维护AAAA样式的DNS条目所涉及的工作是禁止的，那么这可能是合理的，但一般来说，我们希望DNS数据的读取频率比写入频率更高，因此我们需要非常仔细地评估这一特定的权衡。

There are also several potential issues with A6 RRs that stem directly from the feature that makes them different from AAAA RRs: the ability to build up address via chaining.

A6 RRs还存在几个潜在问题，这些问题直接源于使其不同于AAAA RRs的功能：通过链接建立地址的能力。

Resolving a chain of A6 RRs involves resolving a series of what are almost independent queries, but not quite. Each of these sub-queries takes some non-zero amount of time, unless the answer happens to be in the resolver's local cache already. Assuming that resolving an AAAA RR takes time T as a baseline, we can guess that, on the average, it will take something approaching time N*T to resolve an N-link chain of A6 RRs, although we would expect to see a fairly good caching factor for the A6 fragments representing the more significant bits of an address. This leaves us with two choices, neither of which is very good: we can decrease the amount of time that the resolver is willing to wait for each fragment, or we can increase the amount of time that a resolver is willing to wait before returning failure to a client. What little data we have on this subject suggests that users are already impatient with the length of time it takes to resolve A RRs in the IPv4 Internet, which suggests that they are not likely to be patient with significantly longer delays in the IPv6 Internet. At the same time, terminating queries prematurely is both a waste of resources and another source of user frustration. Thus, we are forced to conclude that indiscriminate use of long A6 chains is likely to lead to problems.

解析A6 RRs链涉及解析一系列几乎是独立的查询，但不是完全独立的查询。每个子查询都需要一些非零的时间，除非答案恰好已经在解析器的本地缓存中。假设解析AAAA RR需要时间T作为基线，我们可以猜测，平均而言，解析A6 RR的N-link链需要接近时间N*T的时间，尽管我们希望看到代表地址更重要位的A6片段有一个相当好的缓存因子。这就给我们留下了两个选择，这两个选择都不是很好：我们可以减少冲突解决程序愿意等待每个片段的时间，或者我们可以增加冲突解决程序在将故障返回给客户端之前愿意等待的时间。我们在这个问题上的少量数据表明，用户已经对IPv4互联网上解决RRs所需的时间感到不耐烦，这表明他们不太可能对IPv6互联网上明显更长的延迟感到耐烦。同时，过早终止查询既浪费资源，又会让用户感到沮丧。因此，我们不得不得出结论，不加选择地使用长A6链可能会导致问题。

To make matters worse, the places where A6 RRs are likely to be most critical for rapid renumbering or GSE-like routing are situations where the prefix name field in the A6 RR points to a target that is not only outside the DNS zone containing the A6 RR, but is administered by a different organization (for example, in the case of an end user's site, the prefix name will most likely point to a name belonging to an ISP that provides connectivity for the site). While pointers out of zone are not a problem per se, pointers to other organizations are somewhat more difficult to maintain and less

更糟糕的是，A6 RR对于快速重新编号或类似GSE的路由可能最为关键的位置是A6 RR中的前缀名称字段指向的目标不仅位于包含A6 RR的DNS区域之外，而且由其他组织管理（例如，对于最终用户的站点，前缀名称最有可能指向属于为站点提供连接的ISP的名称）。虽然分区外的指针本身不是问题，但指向其他组织的指针更难维护，也更少

susceptible to automation than pointers within a single organization would be. Experience both with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that many zone administrators do not really understand how to set up and maintain these pointers properly, and we have no particular reason to believe that these zone administrators will do a better job with A6 chains than they do today. To be fair, however, the alternative case of building AAAA RRs via preprocessing before loading zones has many of the same problems; at best, one can claim that using AAAA RRs for this purpose would allow DNS clients to get the wrong answer somewhat more efficiently than with A6 RRs.

比单个组织中的指针更容易受到自动化的影响。在in-ADDR.ARPA树中使用glue RRs和PTR RRs的经验表明，许多区域管理员并不真正了解如何正确设置和维护这些指针，我们没有特别的理由相信这些区域管理员使用A6链的工作会比现在做得更好。然而，公平地说，在装载区之前通过预处理构建AAAA RRs的替代方案也存在许多相同的问题；充其量，人们可以声称，使用AAAA RRs进行此用途将允许DNS客户端比使用A6 RRs更高效地获得错误答案。

Finally, assuming near total ignorance of how likely a query is to fail, the probability of failure with an N-link A6 chain would appear to be roughly proportional to N, since each of the queries involved in resolving an A6 chain would have the same probability of failure as a single AAAA query. Note again that this comment applies to failures in the the process of resolving a query, not to the data obtained via that process. Arguably, in an ideal world, A6 RRs would increase the probability of the answer a client (finally) gets being right, assuming that nothing goes wrong in the query process, but we have no real idea how to quantify that assumption at this point even to the hand-wavey extent used elsewhere in this note.

最后，假设几乎完全不知道查询失败的可能性有多大，那么N-link A6链的失败概率似乎与N大致成正比，因为解析A6链所涉及的每个查询的失败概率都与单个AAAA查询相同。请再次注意，此注释适用于解析查询过程中的失败，而不适用于通过该过程获得的数据。可以说，在理想情况下，假设查询过程中没有出错，A6 RRs将增加客户（最终）得到正确答案的概率，但我们不知道如何在这一点上量化该假设，即使到了本说明其他地方使用的摇摆程度。

One potential problem that has been raised in the past regarding A6 RRs turns out not to be a serious issue. The A6 design includes the possibility of there being more than one A6 RR matching the prefix name portion of a leaf A6 RR. That is, an A6 chain may not be a simple linked list, it may in fact be a tree, where each branch represents a possible prefix. Some critics of A6 have been concerned that this will lead to a wild expansion of queries, but this turns out not to be a problem if a resolver simply follows the "bounded work per query" rule described in RFC 1034 (page 35). That rule applies to all work resulting from attempts to process a query, regardless of whether it's a simple query, a CNAME chain, an A6 tree, or an infinite loop. The client may not get back a useful answer in cases where the zone has been configured badly, but a proper implementation should not produce a query explosion as a result of processing even the most perverse A6 tree, chain, or loop.

过去提出的关于A6 RRs的一个潜在问题不是一个严重的问题。A6设计包括可能有多个A6 RR与叶A6 RR的前缀名称部分匹配。也就是说，A6链可能不是简单的链表，它实际上可能是一棵树，其中每个分支代表一个可能的前缀。A6的一些批评者担心这会导致查询的大量扩展，但如果解析器只是遵循RFC 1034（第35页）中描述的“每个查询的有界工作”规则，这就不是问题了。该规则适用于处理查询尝试产生的所有工作，而不管它是简单查询、CNAME链、A6树还是无限循环。在区域配置不好的情况下，客户机可能无法得到有用的答案，但正确的实现不应该因为处理最不正常的A6树、链或循环而导致查询爆炸。

Interactions with DNSSEC

与DNSSEC的相互作用

One of the areas where AAAA and A6 RRs differ is in the precise details of how they interact with DNSSEC. The following comments apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are semantically equivalent to AAAA RRs).

AAAA和A6 RRs的一个不同之处在于它们如何与DNSSEC互动的精确细节。以下注释仅适用于非零前缀A6 RRs（A6 0 RRs在语义上再次等同于AAAA RRs）。

Other things being equal, the time it takes to re-sign all of the addresses in a zone after a renumbering event is longer with AAAA RRs than with A6 RRs (because each address record has to be re-signed rather than just signing a common prefix A6 RR and a few A6 0 RRs associated with the zone's name servers). Note, however, that in general this does not present a serious scaling problem, because the re-signing is performed in the leaf zones.

在其他条件相同的情况下，使用AAAA RRs比使用A6 RRs对区域中的所有地址重新签名所需的时间更长（因为每个地址记录都必须重新签名，而不仅仅是对一个公共前缀A6 RR和几个与区域名称服务器相关联的A6 0 RRs进行签名）。但是，请注意，通常这并不存在严重的缩放问题，因为重新签名是在叶区域中执行的。

Other things being equal, there's more work involved in verifying the signatures received back for A6 RRs, because each address fragment has a separate associated signature. Similarly, a DNS message containing a set of A6 address fragments and their associated signatures will be larger than the equivalent packet with a single AAAA (or A6 0) and a single associated signature.

在其他条件相同的情况下，验证A6 RRs收到的签名需要做更多的工作，因为每个地址片段都有一个单独的关联签名。类似地，包含一组A6地址片段及其相关签名的DNS消息将大于具有单个AAAA（或A6 0）和单个相关签名的等效数据包。

Since AAAA RRs cannot really represent rapid renumbering or GSE-style routing scenarios very well, it should not be surprising that DNSSEC signatures of AAAA RRs are also somewhat problematic. In cases where the AAAA RRs would have to be changing very quickly to keep up with prefix changes, the time required to re-sign the AAAA RRs may be prohibitive.

由于AAAA RRs不能很好地表示快速重新编号或GSE样式的路由方案，因此AAAA RRs的DNSSEC签名也存在一些问题也就不足为奇了。如果AAAA RRs必须快速更改以跟上前缀更改，则重新签署AAAA RRs所需的时间可能会被禁止。

Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that 333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the BIND-9 dnssec-signzone program under NetBSD can generate roughly 40 1024-bit RSA signatures per second. Extrapolating from this, assuming one A RR, one AAAA RR, and one NXT RR per host, this suggests that it would take this laptop a few hours to sign a zone listing 10**5 hosts, or about a day to sign a zone listing 10**6 hosts using AAAA RRs.

Bill Sommerfeld[Sommerfeld]的实证测试表明，在NetBSD下运行BIND-9 dnssec signzone程序的333MHz赛扬笔记本电脑具有128KB二级缓存和64MB RAM，每秒可以生成大约40 1024位RSA签名。由此推断，假设每个主机有一个A RR、一个AAAA RR和一个NXT RR，这表明该笔记本电脑需要几个小时才能签署一个列出10**5台主机的区域，或者大约需要一天才能使用AAAA RR签署一个列出10**6台主机的区域。

This suggests that the additional effort of re-signing a large zone full of AAAA RRs during a re-numbering event, while noticeable, is only likely to be prohibitive in the rapid renumbering case where AAAA RRs don't work well anyway.

这表明，在重新编号活动期间，重新签署一个装满AAAA RRs的大区域的额外努力虽然很明显，但仅在AAAA RRs无论如何都不能正常工作的快速重新编号情况下才可能是禁止的。

Interactions with Dynamic Update

与动态更新的交互

DNS dynamic update appears to work equally well for AAAA or A6 RRs, with one minor exception: with A6 RRs, the dynamic update client needs to know the prefix length and prefix name. At present, no mechanism exists to inform a dynamic update client of these values, but presumably such a mechanism could be provided via an extension to DHCP, or some other equivalent could be devised.

DNS动态更新似乎同样适用于AAAA或A6 RRs，但有一个小的例外：对于A6 RRs，动态更新客户端需要知道前缀长度和前缀名称。目前，不存在将这些值通知动态更新客户机的机制，但可以通过DHCP的扩展提供这种机制，或者可以设计其他等效机制。

Transition from AAAA to A6 Via AAAA Synthesis

通过AAAA合成从AAAA到A6的转变

While AAAA is at present more widely deployed than A6, it is possible to transition from AAAA-aware DNS software to A6-aware DNS software. A rough plan for this was presented at IETF-50 in Minneapolis and has been discussed on the ipng mailing list. So if the IETF concludes that A6's enhanced capabilities are necessary, it should be possible to transition from AAAA to A6.

虽然AAAA目前比A6部署得更广泛，但有可能从AAAA感知DNS软件过渡到A6感知DNS软件。在明尼阿波利斯的IETF-50会议上提出了这方面的粗略计划，并在ipng邮件列表中进行了讨论。因此，如果IETF认为A6的增强能力是必要的，那么从AAAA过渡到A6应该是可能的。

The details of this transition have been left to a separate document, but the general idea is that the resolver that is performing iterative resolution on behalf of a DNS client program could synthesize AAAA RRs representing the result of performing the equivalent A6 queries. Note that in this case it is not possible to generate an equivalent DNSSEC signature for the AAAA RR, so clients that care about performing DNSSEC validation for themselves would have to issue A6 queries directly rather than relying on AAAA synthesis.

此转换的详细信息已留给单独的文档，但总体思路是，代表DNS客户端程序执行迭代解析的解析程序可以合成表示执行等效A6查询结果的AAAA RRs。请注意，在这种情况下，不可能为AAAA RR生成等效的DNSSEC签名，因此关心自己执行DNSSEC验证的客户机必须直接发出A6查询，而不是依赖AAAA合成。

Bitlabels

位标签

While the differences between AAAA and A6 RRs have generated most of the discussion to date, there are also two proposed mechanisms for building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-ADDR.ARPA tree).

虽然AAAA和A6 RRs之间的差异引起了迄今为止的大部分讨论，但也有两种建议的机制用于构建反向映射树（IPv6相当于IPv4的IN-ADDR.ARPA树）。

[RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA mechanism used for IPv4 addresses: the RR name is the hexadecimal representation of the IPv6 address, reversed and concatenated with a well-known suffix, broken up with a dot between each hexadecimal digit. The resulting DNS names are somewhat tedious for humans to type, but are very easy for programs to generate. Making each hexadecimal digit a separate label means that delegation on arbitrary bit boundaries will result in a maximum of 16 NS RRsets per label level; again, the mechanism is somewhat tedious for humans, but is very easy to program. As with IPv4's IN-ADDR.ARPA tree, the one place where this scheme is weak is in handling delegations in the least significant label; however, since there appears to be no real need to delegate the least significant four bits of an IPv6 address, this does not appear to be a serious restriction.

[RFC1886]提出了一种与IPv4地址使用的IN-ADDR.ARPA机制非常类似的机制：RR名称是IPv6地址的十六进制表示形式，用一个众所周知的后缀反转并连接，每个十六进制数字之间用一个点分隔。由此产生的DNS名称对于人类来说有点单调乏味，但对于程序来说非常容易生成。使每个十六进制数字成为单独的标签意味着在任意位边界上的委托将导致每个标签级别最多16个RRNS集；同样，该机制对人类来说有些乏味，但很容易编程。与IPv4的IN-ADDR.ARPA树一样，该方案的薄弱之处在于处理最低有效标签中的委托；但是，由于似乎没有实际需要委派IPv6地址的最低有效四位，因此这似乎不是一个严重的限制。

[RFC2874] proposed a radically different way of naming entries in the reverse mapping tree: rather than using textual representations of addresses, it proposes to use a new kind of DNS label (a "bit label") to represent binary addresses directly in the DNS. This has the advantage of being significantly more compact than the textual representation, and arguably might have been a better solution for DNS to use for this purpose if it had been designed into the protocol

[RFC2874]提出了一种完全不同的命名反向映射树中条目的方法：它不使用地址的文本表示，而是建议使用一种新的DNS标签（“位标签”）直接在DNS中表示二进制地址。这具有比文本表示更紧凑的优势，而且如果DNS被设计到协议中，它可能是用于此目的的更好的解决方案

from the outset. Unfortunately, experience to date suggests that deploying a new DNS label type is very hard: all of the DNS name servers that are authoritative for any portion of the name in question must be upgraded before the new label type can be used, as must any resolvers involved in the resolution process. Any name server that has not been upgraded to understand the new label type will reject the query as being malformed.

从一开始。不幸的是，迄今为止的经验表明，部署新的DNS标签类型是非常困难的：对于所讨论的名称的任何部分具有权威性的所有DNS名称服务器必须在使用新标签类型之前升级，解析过程中涉及的任何解析程序也必须升级。任何尚未升级以理解新标签类型的名称服务器都将拒绝该查询，因为该查询的格式不正确。

Since the main benefit of the bit label approach appears to be an ability that we don't really need (delegation in the least significant four bits of an IPv6 address), and since the upgrade problem is likely to render bit labels unusable until a significant portion of the DNS code base has been upgraded, it is difficult to escape the conclusion that the textual solution is good enough.

由于位标签方法的主要优点似乎是我们并不真正需要的功能（在IPv6地址的最低有效四位中进行委派），并且由于升级问题可能会导致位标签不可用，直到DNS代码库的大部分已升级，很难不得出这样的结论：文本解决方案足够好了。

DNAME RRs

[RFC2874] also proposes using DNAME RRs as a way of providing the equivalent of A6's fragmented addresses in the reverse mapping tree. That is, by using DNAME RRs, one can write zone files for the reverse mapping tree that have the same ability to cope with rapid renumbering or GSE-style routing that the A6 RR offers in the main portion of the DNS tree. Consequently, the need to use DNAME in the reverse mapping tree appears to be closely tied to the need to use fragmented A6 in the main tree: if one is necessary, so is the other, and if one isn't necessary, the other isn't either.

[RFC2874]还建议使用DNAME RRs作为在反向映射树中提供A6片段地址的等效方法。也就是说，通过使用DNAME RRs，可以为反向映射树编写区域文件，这些文件具有与A6 RR在DNS树的主要部分中提供的快速重新编号或GSE样式路由相同的能力。因此，在反向映射树中使用DNAME的需求似乎与在主树中使用片段A6的需求密切相关：如果一个是必需的，那么另一个也是必需的，如果一个不是必需的，那么另一个也不是必需的。

Other uses have also been proposed for the DNAME RR, but since they are outside the scope of the IPv6 address discussion, they will not be addressed here.

DNAME RR还提出了其他用途，但由于它们不在IPv6地址讨论的范围内，因此此处不讨论它们。

Recommendation

正式建议

Distilling the above feature comparisons down to their key elements, the important questions appear to be:

将上述功能比较提取到其关键要素，重要的问题似乎是：

(a) Is IPv6 going to do rapid renumbering or GSE-like routing?

(a) IPv6将进行快速重新编号还是类似于GSE的路由？

(b) Is the reverse mapping tree for IPv6 going to require delegation in the least significant four bits of the address?

(b) IPv6的反向映射树是否需要在地址的最低有效四位中进行委派？

Question (a) appears to be the key to the debate. This is really a decision for the IPv6 community to make, not the DNS community.

问题（a）似乎是辩论的关键。这实际上是IPv6社区的决定，而不是DNS社区的决定。

Question (b) is also for the IPv6 community to make, but it seems fairly obvious that the answer is "no".

问题（b）也是IPv6社区应该提出的，但答案似乎是“不”。

Recommendations based on these questions:

基于这些问题的建议：

(1) If the IPv6 working groups seriously intend to specify and deploy rapid renumbering or GSE-like routing, we should transition to using the A6 RR in the main tree and to using DNAME RRs as necessary in the reverse tree.

(1) 如果IPv6工作组认真打算指定和部署快速重新编号或类似GSE的路由，我们应该在主目录树中使用A6 RR，并在反向目录树中根据需要使用DNAME RRs。

(2) Otherwise, we should keep the simpler AAAA solution in the main tree and should not use DNAME RRs in the reverse tree.

(2) 否则，我们应该在主目录树中保留更简单的AAAA解决方案，而不应该在反向目录树中使用DNAME RRs。

(3) In either case, the reverse tree should use the textual representation described in [RFC1886] rather than the bit label representation described in [RFC2874].

(3) 在任何一种情况下，反向树都应该使用[RFC1886]中描述的文本表示，而不是[RFC2874]中描述的位标签表示。

(4) If we do go to using A6 RRs in the main tree and to using DNAME RRs in the reverse tree, we should write applicability statements and implementation guidelines designed to discourage excessively complex uses of these features; in general, any network that can be described adequately using A6 0 RRs and without using DNAME RRs should be described that way, and the enhanced features should be used only when absolutely necessary, at least until we have much more experience with them and have a better understanding of their failure modes.

(4) 如果我们真的在主树中使用A6 RRs，在反向树中使用DNAME RRs，我们应该编写适用性声明和实施指南，旨在阻止这些功能的过度复杂使用；一般来说，任何可以使用A6 0 RRs和不使用DNAME RRs进行充分描述的网络都应该这样描述，并且只有在绝对必要时才应该使用增强功能，至少在我们有更多的经验并更好地了解它们的故障模式之前。

Security Considerations

安全考虑

This note compares two mechanisms with similar security characteristics, but there are a few security implications to the choice between these two mechanisms:

本说明比较了具有相似安全特性的两种机制，但这两种机制之间的选择存在一些安全问题：

(1) The two mechanisms have similar but not identical interactions with DNSSEC. Please see the section entitled "Interactions with DNSSEC" (above) for a discussion of these issues.

(1) 这两种机制与DNSSEC具有相似但不完全相同的相互作用。有关这些问题的讨论，请参见题为“与DNSSEC的互动”的章节（上文）。

(2) To the extent that operational complexity is the enemy of security, the tradeoffs in operational complexity discussed throughout this note have an impact on security.

(2) 由于操作复杂性是安全性的敌人，本说明中讨论的操作复杂性权衡对安全性有影响。

(3) To the extent that protocol complexity is the enemy of security, the additional protocol complexity of [RFC2874] as compared to [RFC1886] has some impact on security.

(3) 由于协议复杂性是安全性的敌人，与[RFC1886]相比[RFC2874]的额外协议复杂性对安全性有一定影响。

IANA Considerations

IANA考虑

None, since all of these RR types have already been allocated.

无，因为所有这些RR类型都已分配。

Acknowledgments

致谢

This note is based on a number of discussions both public and private over a period of (at least) eight years, but particular thanks go to Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush, and Sue Thomson, none of whom are responsible for what the author did with their ideas.

本说明基于（至少）八年的公开和私下讨论，但特别感谢阿兰·杜兰德、比尔·索末菲、克里斯蒂安·惠特马、伊藤俊一郎·哈吉诺、马克·安德鲁斯、马特·克劳福德、奥拉富·古德蒙德森、兰迪·布什和苏·汤姆森，没有人对作者的想法负责。

References

工具书类

[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995.

[RFC1886]Thomson，S.和C.Huitema，“支持IP版本6的DNS扩展”，RFC 18861995年12月。

[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.

[RFC2874]Crawford，M.和C.Huitema，“支持IPv6地址聚合和重新编号的DNS扩展”，RFC 28742000年7月。

[Sommerfeld] Private message to the author from Bill Sommerfeld dated 21 March 2001, summarizing the result of experiments he performed on a copy of the MIT.EDU zone.

[Sommerfeld]Bill Sommerfeld于2001年3月21日给作者的私人信息，总结了他在MIT.EDU zone副本上进行的实验结果。

[GSE] "GSE" was an evolution of the so-called "8+8" proposal discussed by the IPng working group in 1996 and 1997. The GSE proposal itself was written up as an Internet-Draft, which has long since expired. Readers interested in the details and history of GSE should review the IPng working group's mailing list archives and minutes from that period.

[GSE]“GSE”是知识产权工作组在1996年和1997年讨论的所谓“8+8”提案的演变。GSE提案本身被写成了一份互联网草案，已经过期很久了。对GSE的详细信息和历史感兴趣的读者应查阅IPng工作组的邮件列表档案以及该时期的会议记录。

Author's Address

作者地址

Rob Austein

罗伯·奥斯汀

   EMail: sra@hactrn.net

   EMail: sra@hactrn.net

Full Copyright Statement

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。