Network Working Group S. Weiler
Request for Comments: 3755 SPARTA, Inc.
Updates: 3658, 2535 May 2004
Category: Standards Track
Network Working Group S. Weiler
Request for Comments: 3755 SPARTA, Inc.
Updates: 3658, 2535 May 2004
Category: Standards Track
Legacy Resolver Compatibility for Delegation Signer (DS)
委派签名者（DS）的旧解析程序兼容性
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions.
随着DNS安全（DNSSEC）规范的发展，DNSSEC资源记录（RRs）的语法和语义也发生了变化。许多部署的名称服务器理解这些语义的变体。当理解这些语义的早期版本的冲突解决程序查询理解新委托签名者语义的权威服务器时，可能会发生危险的交互，包括至少一种会导致不安全区域无法解决的故障场景。本文档更改了DNSSEC RRs（SIG、KEY和NXT）的类型代码和助记符，以避免这些交互。
The DNSSEC protocol has been through many iterations whose syntax and semantics are not completely compatible. This has occurred as part of the ordinary process of proposing a protocol, implementing it, testing it in the increasingly complex and diverse environment of the Internet, and refining the definitions of the initial Proposed Standard. In the case of DNSSEC, the process has been complicated by DNS's criticality and wide deployment and the need to add security while minimizing daily operational complexity.
DNSSEC协议经过多次迭代，其语法和语义并不完全兼容。这是提出协议、实施协议、在日益复杂和多样化的互联网环境中测试协议以及完善最初提出的标准定义的正常过程的一部分。在DNSSEC的案例中，DNS的关键性和广泛部署以及在最小化日常操作复杂性的同时增加安全性的需要使流程变得复杂。
A weak area for previous DNS specifications has been lack of detail in specifying resolver behavior, leaving implementors largely on their own to determine many details of resolver function. This, combined with the number of iterations the DNSSEC specifications have been through, has resulted in fielded code with a wide variety of
以前的DNS规范的一个薄弱环节是在指定解析器行为方面缺乏细节，使得实现人员在很大程度上自行决定解析器功能的许多细节。这与DNSSEC规范经过的迭代次数相结合，产生了具有多种多样性的现场代码
behaviors. This variety makes it difficult to predict how a protocol change will be handled by all deployed resolvers. The risk that a change will cause unacceptable or even catastrophic failures makes it difficult to design and deploy a protocol change. One strategy for managing that risk is to structure protocol changes so that existing resolvers can completely ignore input that might confuse them or trigger undesirable failure modes.
行为。这种多样性使得很难预测所有部署的解析器将如何处理协议更改。更改将导致不可接受甚至灾难性故障的风险使得设计和部署协议更改变得困难。管理这种风险的一种策略是构造协议更改，以便现有的解析器可以完全忽略可能会混淆它们或触发不希望的故障模式的输入。
This document addresses a specific problem caused by Delegation Signer's (DS) [RFC3658] introduction of new semantics for the NXT RR that are incompatible with the semantics in [RFC2535]. Answers provided by DS-aware servers can trigger an unacceptable failure mode in some resolvers that implement RFC 2535, which provides a great disincentive to sign zones with DS. The changes defined in this document allow for the incremental deployment of DS.
本文档解决了委托签署人（DS）[RFC3658]为NXT RR引入的新语义（与[RFC2535]中的语义不兼容）所导致的特定问题。DS感知服务器提供的答案可能会在一些实现RFC 2535的解析程序中触发不可接受的故障模式，这会极大地抑制使用DS签署区域。本文档中定义的更改允许增量部署DS。
In this document, the term "unsecure delegation" means any delegation for which no DS record appears at the parent. An "unsecure referral" is an answer from the parent containing an NS RRset and a proof that no DS record exists for that name.
在本文件中，术语“不安全的委托”是指在父级上没有DS记录的任何委托。“不安全引用”是来自父级的答案，其中包含NS RRset，并证明该名称不存在DS记录。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Delegation Signer (DS) introduces new semantics for the NXT RR that are incompatible with the semantics in RFC 2535. In RFC 2535, NXT records were only required to be returned as part of a non-existence proof. With DS, an unsecure referral returns, in addition to the NS, a proof of non-existence of a DS RR in the form of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was to interpret a response with RCODE=0, AA=0, and both an NS and an NXT in the authority section. Some widely deployed 2535-aware resolvers interpret any answer with an NXT as a proof of non-existence of the requested record. This results in unsecure delegations being invisible to 2535-aware resolvers and violates the basic architectural principle that DNSSEC must do no harm -- the signing of zones must not prevent the resolution of unsecured delegations.
委托签名者（DS）为NXT RR引入了与RFC 2535中的语义不兼容的新语义。在RFC 2535中，NXT记录只需作为不存在证明的一部分返回。对于DS，除了NS之外，不安全的转诊以NXT和SIG（NXT）的形式返回DS RR不存在的证明。RFC2535没有指定解析程序如何解释RCODE=0、AA=0以及authority部分中的NS和NXT的响应。一些广泛部署的2535感知解析器将任何带有NXT的答案解释为请求记录不存在的证明。这导致2535名意识到的解决者看不到不安全的授权，并违反了DNSSEC不得造成伤害的基本架构原则——区域的签署不得阻止不安全授权的解决。
This section presents several solutions that were considered. Section 3 describes the one selected.
本节介绍了考虑过的几种解决方案。第3节描述了所选的一个。
To avoid the problem described above, legacy (RFC2535-aware) resolvers need to be kept from seeing unsecure referrals that include NXT records in the authority section. The simplest way to do that is to change the type codes for SIG, KEY, and NXT.
为了避免上述问题，需要防止遗留（RFC2535感知）解析程序看到不安全的引用，这些引用包括授权部分中的NXT记录。最简单的方法是更改SIG、KEY和NXT的类型代码。
The obvious drawback to this is that new resolvers will not be able to validate zones signed with the old RRs. This problem already exists, however, because of the changes made by DS, and resolvers that understand the old RRs (and have compatibility issues with DS) are far more prevalent than 2535-signed zones.
这样做的明显缺点是，新的解析器将无法验证使用旧RRs签名的区域。但是，由于DS所做的更改，这个问题已经存在，并且理解旧RRs（并且与DS存在兼容性问题）的解析程序远比2535个签名区域普遍。
The observed problem with unsecure referrals could be addressed by changing only the NXT type code or another subset of the type codes that includes NXT. This has the virtue of apparent simplicity, but it risks introducing new problems or not going far enough. It's quite possible that more incompatibilities exist between DS and earlier semantics. Legacy resolvers may also be confused by seeing records they recognize (SIG and KEY) while being unable to find NXTs. Although it may seem unnecessary to fix that which is not obviously broken, it's far cleaner to change all of the type codes at once. This will leave legacy resolvers and tools completely blinded to DNSSEC -- they will see only unknown RRs.
通过仅更改NXT类型代码或包含NXT的其他类型代码子集，可以解决观察到的不安全转介问题。这有着明显的简单性的优点，但它有引入新问题或不够深入的风险。DS和早期语义之间很可能存在更多的不兼容。旧式解析程序在无法找到NXT的情况下看到它们识别的记录（SIG和KEY），也可能会感到困惑。虽然似乎没有必要修复那些没有明显损坏的代码，但一次更改所有类型代码要干净得多。这将使遗留解析程序和工具完全不了解DNSSEC——它们只能看到未知的RRs。
Another way to keep legacy resolvers from ever seeing DNSSEC records with DS semantics is to have authoritative servers only send that data to DS-aware resolvers. It's been proposed that assigning a new EDNS0 flag bit to signal DS-awareness (tentatively called "DA"), and having authoritative servers send DNSSEC data only in response to queries with the DA bit set, would accomplish this. This bit would presumably supplant the DO bit described in [RFC3225].
另一种防止遗留解析程序看到具有DS语义的DNSSEC记录的方法是让权威服务器只将该数据发送给支持DS的解析程序。有人建议，分配一个新的EDNS0标志位来表示DS感知（暂定为“DA”），并让权威服务器仅在响应DA位集的查询时发送DNSSEC数据，这将实现这一点。该位可能会取代[RFC3225]中描述的DO位。
This solution is sufficient only if all 2535-aware resolvers zero out EDNS0 flags that they don't understand. If one passed through the DA bit unchanged, it would still see the new semantics, and it would probably fail to see unsecure delegations. Since it's impractical to know how every DNS implementation handles unknown EDNS0 flags, this is not a universal solution. It could, though, be considered in addition to changing the RR type codes.
只有当所有2535感知的解析器将不理解的EDNS0标志归零时，此解决方案才足够。如果没有改变通过DA位，它仍然可以看到新的语义，并且可能无法看到不安全的委托。因为知道每个DNS实现如何处理未知的EDNS0标志是不切实际的，所以这不是一个通用的解决方案。但是，除了更改RR类型代码外，还可以考虑此问题。
Another possible solution is to increment the EDNS version number as defined in [RFC2671], on the assumption that all existing implementations will reject higher versions than they support, and retain the DO bit as the signal for DNSSEC awareness. This approach has not been tested.
另一种可能的解决方案是增加[RFC2671]中定义的EDNS版本号，前提是所有现有实现将拒绝高于其支持的版本，并保留DO位作为DNSSEC感知的信号。这种方法还没有经过测试。
There is a large deployed base of DNS resolvers that understand DNSSEC as defined by the standards track RFC 2535 and [RFC2065] and, due to under specification in those documents, interpret any answer with an NXT as a non-existence proof. So long as that is the case, zone owners will have a strong incentive to not sign any zones that contain unsecure delegations, lest those delegations be invisible to such a large installed base. This will dramatically slow DNSSEC adoption.
有大量已部署的DNS解析程序，这些解析程序理解RFC 2535和[RFC2065]标准中定义的DNSSEC，并且由于这些文档中的规范不足，将任何带有NXT的答案解释为不存在证明。在这种情况下，区域所有者将有强烈的动机不签署任何包含不安全授权的区域，以免这些授权对如此庞大的安装基数不可见。这将大大减缓DNSSEC的采用。
Unfortunately, without signed zones there's no clear incentive for operators of resolvers to upgrade their software to support the new version of DNSSEC, as defined in RFC 3658. Historical data suggests that resolvers are rarely upgraded, and that old nameserver code never dies.
不幸的是，没有签名区域，解析程序的操作员就没有明确的动机升级其软件以支持RFC 3658中定义的DNSSEC新版本。历史数据表明，解析程序很少升级，旧的名称服务器代码永远不会消亡。
Rather than wait years for resolvers to be upgraded through natural processes before signing zones with unsecure delegations, addressing this problem with a protocol change will immediately remove the disincentive for signing zones and allow widespread deployment of DNSSEC.
在与不安全的授权签署区域之前，不必等待数年通过自然过程升级冲突解决程序，通过协议更改解决此问题将立即消除对签署区域的抑制，并允许广泛部署DNSSEC。
This document changes the type codes of SIG, KEY, and NXT. This approach is the cleanest and safest of those discussed above, largely because the behavior of resolvers that receive unknown type codes is well understood. This approach has also received the most testing.
本文档更改了SIG、KEY和NXT的类型代码。这种方法是上面讨论的方法中最干净、最安全的，这主要是因为接收未知类型代码的解析器的行为已经被很好地理解了。这种方法也得到了最多的测试。
To avoid operational confusion, it's also necessary to change the mnemonics for these RRs. DNSKEY will be the replacement for KEY, with the mnemonic indicating that these keys are not for application use, per [RFC3445]. RRSIG (Resource Record SIGnature) will replace SIG, and NSEC (Next SECure) will replace NXT. These new types completely replace the old types, except that SIG(0) [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
为了避免操作混乱，还需要更改这些RRs的助记符。DNSKEY将代替密钥，根据[RFC3445]，助记符指示这些密钥不供应用程序使用。RRSIG（资源记录签名）将取代SIG，NSEC（下一个安全）将取代NXT。除了SIG（0）[RFC2931]和TKEY[RFC2930]将继续使用SIG和KEY之外，这些新类型完全取代了旧类型。
The new types will have exactly the same syntax and semantics as specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 except for the following:
新类型的语法和语义与RFC 2535和RFC 3658中为SIG、KEY和NXT指定的语法和语义完全相同，但以下情况除外：
1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC RRs MUST NOT be compressed,
1) 与[RFC3597]一致，嵌入在RRSIG和NSEC RRs中的域名不得压缩，
2) Embedded domain names in RRSIG and NSEC RRs are not downcased for purposes of DNSSEC canonical form and ordering nor for equality comparison, and
2) RRSIG和NSEC RRs中的嵌入式域名不会因DNSSEC规范格式和排序或平等性比较而降级，以及
3) An RRSIG with a type-covered field of zero has undefined semantics. The meaning of such a resource record may only be defined by IETF Standards Action.
3) 类型覆盖字段为零的RRSIG具有未定义的语义。此类资源记录的含义只能由IETF标准行动定义。
If a resolver receives the old types, it SHOULD treat them as unknown RRs and SHOULD NOT assign any special meaning to them or give them any special treatment. It MUST NOT use them for DNSSEC validations or other DNS operational decision making. For example, a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone, they MUST NOT receive special treatment. As an example, if a SIG is included in a signed zone, there MUST be an RRSIG for it. Authoritative servers may wish to give error messages when loading zones containing SIG or NXT records (KEY records may be included for SIG(0) or TKEY).
如果解析器接收到旧类型，则应将其视为未知RRs，并且不应赋予它们任何特殊含义或给予任何特殊处理。不得将其用于DNSSEC验证或其他DNS操作决策。例如，解析程序不得使用DNSKEYs验证SIG或使用密钥验证RRSIG。如果SIG、KEY或NXT RRs包含在区域中，则不得对其进行特殊处理。例如，如果一个SIG包含在一个签名区域中，那么它必须有一个RRSIG。权威服务器可能希望在加载包含SIG或NXT记录的区域时发出错误消息（SIG（0）或TKEY可能包含密钥记录）。
As a clarification to previous documents, some positive responses, particularly wildcard proofs and unsecure referrals, will contain NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as negative answers merely because they contain an NSEC.
作为对先前文件的澄清，一些积极回复，特别是通配符证明和不安全的转介，将包含NSEC RRs。解析程序不得仅因为包含NSEC RRs而将具有NSEC RRs的答案视为否定答案。
This document updates the IANA registry for DNS Resource Record Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
本文档通过将类型46、47和48分别分配给RRSIG、NSEC和DNSKEY RRs来更新IANA注册表中的DNS资源记录类型。
Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and TKEY [RFC2930] use only.
类型24和25（SIG和键）仅保留用于SIG（0）[RFC2931]和TKEY[RFC2930]使用。
Type 30 (NXT) should be marked as Obsolete.
类型30（NXT）应标记为已过时。
To allow zone signing (DNSSEC) and transaction security mechanisms (SIG(0) and TKEY) to use different sets of algorithms, the existing "DNS Security Algorithm Numbers" registry is modified to include the applicability of each algorithm. Specifically, two new columns are added to the registry, showing whether each algorithm may be used for zone signing, transaction security mechanisms, or both. Only algorithms usable for zone signing may be used in DNSKEY, RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG may be used in SIG and KEY RRs.
为了允许区域签名（DNSSEC）和事务安全机制（SIG（0）和TKEY）使用不同的算法集，对现有的“DNS安全算法编号”注册表进行了修改，以包括每个算法的适用性。具体来说，将向注册表添加两个新列，显示每个算法是否可用于区域签名、事务安全机制或两者。DNSKEY、RRSIG和DS RRs中只能使用可用于区域签名的算法。SIG和密钥RRs中只能使用可用于SIG（0）和/或TSIG的算法。
All currently defined algorithms except for Indirect (algorithm 252) remain usable for transaction security mechanisms. Only RSA/SHA-1 [RFC3110], DSA/SHA-1 [RFC2536], and private algorithms (types 253 and 254) may be used for zone signing. Note that the registry does not contain the requirement level of each algorithm, only whether or not an algorithm may be used for the given purposes. For example, RSA/MD5, while allowed for transaction security mechanisms, is NOT RECOMMENDED, per [RFC3110].
除间接（算法252）外，所有当前定义的算法都可用于事务安全机制。区域签名只能使用RSA/SHA-1[RFC3110]、DSA/SHA-1[RFC2536]和专用算法（类型253和254）。请注意，注册表不包含每个算法的需求级别，只包含算法是否可用于给定目的。例如，根据[RFC3110]，虽然允许使用事务安全机制，但不建议使用RSA/MD5。
Additionally, the presentation format algorithm mnemonics from [RFC2535] Section 7 are added to the registry. This document assigns RSA/SHA-1 the mnemonic RSASHA1.
此外，[RFC2535]第7节中的表示格式算法助记符被添加到注册表中。本文档为RSA/SHA-1分配助记符RSASHA1。
As before, assignment of new algorithms in this registry requires IETF Standards Action. Additionally, modification of algorithm mnemonics or applicability requires IETF Standards Action. Documents defining a new algorithm must address the applicability of the algorithm and should assign a presentation mnemonic to the algorithm.
与以前一样，在该注册表中分配新算法需要IETF标准行动。此外，算法助记符或适用性的修改需要IETF标准行动。定义新算法的文档必须说明算法的适用性，并且应该为算法分配一个表示助记符。
Like the KEY resource record, DNSKEY contains a 16-bit flags field. This document creates a new registry for the DNSKEY flags field.
与密钥资源记录一样，DNSKEY包含一个16位标志字段。此文档为DNSKEY标志字段创建一个新注册表。
Initially, this registry only contains an assignment for bit 7 (the ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF Standards Action.
最初，该注册表仅包含位7（区域位）的赋值。比特0-6和8-15可由IETF标准行动分配。
Like the KEY resource record, DNSKEY contains an eight bit protocol field. The only defined value for this field is 3 (DNSSEC). No other values are allowed, hence no IANA registry is needed for this field.
与密钥资源记录一样，DNSKEY包含一个八位协议字段。此字段唯一定义的值为3（DNSSEC）。不允许使用其他值，因此此字段不需要IANA注册表。
The changes introduced here do not materially affect security. The implications of trying to use both new and legacy types together are not well understood, and attempts to do so would probably lead to unintended and dangerous results.
此处介绍的更改不会对安全性产生重大影响。尝试同时使用新类型和旧类型的含义还没有得到很好的理解，尝试这样做可能会导致意外和危险的结果。
Changing type codes will leave code paths in legacy resolvers that are never exercised. Unexercised code paths are a frequent source of security holes, largely because those code paths do not get frequent scrutiny.
更改类型代码将在旧解析程序中留下永远不会执行的代码路径。未经验证的代码路径经常是安全漏洞的来源，这主要是因为这些代码路径没有得到频繁的检查。
Doing nothing, as described in section 2.5, will slow DNSSEC deployment. While this does not decrease security, it also fails to increase it.
如第2.5节所述，不采取任何措施将减缓DNSSEC的部署。虽然这不会降低安全性，但也无法提高安全性。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.
[RFC2536]Eastlake，D.，“域名系统（DNS）中的DSA密钥和SIG”，RFC 25361999年3月。
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930]Eastlake，D.，“DNS密钥建立（TKEY RR）”，RFC 29302000年9月。
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)", RFC 2931, September 2000.
[RFC2931]Eastlake，D.，“DNS请求和事务签名（SIG（0）s）”，RFC 29312000年9月。
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001.
[RFC3110]Eastlake，D.，“域名系统（DNS）中的RSA/SHA-1 SIGs和RSA密钥”，RFC 3110，2001年5月。
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003.
[RFC3658]Gudmundsson，O.“委托签署人（DS）资源记录（RR）”，RFC3658，2003年12月。
[RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[RFC2065]Eastlake，3rd，D.和C.Kaufman，“域名系统安全扩展”，RFC2065，1997年1月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
[RFC3225]Conrad，D.“指示DNSSEC的分解器支持”，RFC 3225，2001年12月。
[RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
[RFC3445]Massey，D.和S.Rose，“限制关键资源记录（RR）的范围”，RFC 34452002年12月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]Gustafsson，A.，“未知DNS资源记录（RR）类型的处理”，RFC3597，2003年9月。
The changes introduced here and the analysis of alternatives had many contributors. With apologies to anyone overlooked, those include: Michael Graff, Johan Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis, Bill Manning, Paul Vixie, and Suzanne Woolf.
这里介绍的变化和对备选方案的分析有许多贡献者。向任何被忽视的人道歉，包括：迈克尔·格拉夫、约翰·伊伦、奥拉夫·科尔克曼、马克·科斯特斯、埃德·刘易斯、比尔·曼宁、保罗·维克西和苏珊娜·伍尔夫。
Thanks to Jakob Schlyter and Mark Andrews for identifying the incompatibility described in section 1.2.
感谢Jakob Schlyter和Mark Andrews确定了第1.2节所述的不兼容性。
In addition to the above, the author would like to thank Scott Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive comments.
除上述内容外，作者还要感谢Scott Rose、Olafur Gudmundsson和Sandra Murphy的实质性评论。
Samuel Weiler SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 USA
塞缪尔·韦勒·斯巴达公司，美国马里兰州哥伦比亚塞缪尔·莫尔斯大道7075号，邮编：21046
EMail: weiler@tislabs.com
EMail: weiler@tislabs.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编辑功能的资金目前由互联网协会提供。