Network Working Group M. Bagnulo
Request for Comments: 4982 UC3M
Updates: 3972 J. Arkko
Category: Standards Track Ericsson
July 2007
Network Working Group M. Bagnulo
Request for Comments: 4982 UC3M
Updates: 3972 J. Arkko
Category: Standards Track Ericsson
July 2007
Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)
在加密生成的地址（CGA）中支持多个哈希算法
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms.
本文档分析了最近针对加密生成地址（CGA）上常用哈希函数的攻击的含义，并更新了CGA规范以支持多种哈希算法。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Impact of Collision Attacks in CGAs . . . . . . . . . . . . . . 2
4. Options for Multiple Hash Algorithm Support in CGAs . . . . . . 3
4.1. Where to Encode the Hash Function? . . . . . . . . . . . . 4
5. CGA Generation Procedure . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Impact of Collision Attacks in CGAs . . . . . . . . . . . . . . 2
4. Options for Multiple Hash Algorithm Support in CGAs . . . . . . 3
4.1. Where to Encode the Hash Function? . . . . . . . . . . . . 4
5. CGA Generation Procedure . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Recent attacks to currently used hash functions have motivated a considerable amount of concern in the Internet community. The recommended approach [6] [10] to deal with this issue is first to analyze the impact of these attacks on the different Internet protocols that use hash functions and second to make sure that the different Internet protocols that use hash functions are capable of migrating to an alternative (more secure) hash function without a major disruption in the Internet operation.
最近对当前使用的哈希函数的攻击引起了互联网社区的极大关注。处理此问题的推荐方法[6][10]首先是分析这些攻击对使用哈希函数的不同Internet协议的影响，其次是确保使用哈希函数的不同Internet协议能够迁移到另一种（更安全的）协议哈希函数，不会对Internet操作造成重大中断。
This document performs such analysis for the Cryptographically Generated Addresses (CGAs) defined in [2]. The first conclusion of the analysis is that the security of the protocols using CGAs is not affected by the recently available attacks against hash functions. The second conclusion of the analysis is that the hash function used is hard coded in the CGA specification. This document updates the CGA specification [2] to enable the support of alternative hash functions. In order to do so, this document creates a new registry managed by IANA to register the different hash algorithms used in CGAs.
本文件对[2]中定义的加密生成地址（CGA）进行此类分析。分析的第一个结论是，使用CGA的协议的安全性不受最近针对哈希函数的攻击的影响。分析的第二个结论是，所使用的哈希函数在CGA规范中是硬编码的。本文档更新了CGA规范[2]，以支持替代哈希函数。为此，本文创建了一个由IANA管理的新注册表，以注册CGA中使用的不同哈希算法。
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 RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
Recent advances in cryptography have resulted in simplified attacks against the collision-free property of certain commonly used hash functions [6] [10], including SHA-1 that is the hash function used by CGAs [2]. The result is that it is possible to obtain two messages, M1 and M2, that have the same hash value with much less than 2^(L/2) attempts. We will next analyze the impact of such attacks in the currently proposed usages of CGAs.
密码学的最新进展简化了对某些常用散列函数[6][10]无冲突属性的攻击，包括CGAs使用的散列函数SHA-1[2]。结果是，可以获得两条消息M1和M2，它们具有相同的散列值，并且尝试次数远远少于2^（L/2）。接下来，我们将分析此类攻击在当前提出的CGA使用中的影响。
As we understand it, the attacks against the collision-free property of a hash function mostly challenge the application of such hash functions, for the provision of non-repudiation capabilities. This is because an attacker would be capable to create two different messages that result in the same hash value and it can then present any of the messages interchangeably (for example after one of them has been signed by the other party involved in the transaction). However, it must be noted that both messages must be generated by the same party.
据我们所知，针对散列函数的无冲突属性的攻击主要是对此类散列函数的应用提出挑战，以提供不可否认能力。这是因为攻击者能够创建两条不同的消息，从而产生相同的哈希值，然后可以互换地呈现任何消息（例如，在其中一条消息已由事务中涉及的另一方签名之后）。但是，必须注意，两条消息必须由同一方生成。
As far as we understand, current usages of CGAs does not include the provision of non-repudiation capabilities, so attacks against the collision-free property of the hash function do not enable any useful attack against CGA-based protocols.
据我们所知，CGA的当前用途不包括提供不可否认性功能，因此针对哈希函数的无冲突属性的攻击无法对基于CGA的协议进行任何有用的攻击。
Current usages of the CGAs are basically oriented to prove the ownership of a CGA and then bind it to alternative addresses that can be used to reach the original CGA. This type of application of the CGA include:
CGA的当前用途基本上是为了证明CGA的所有权，然后将其绑定到可用于到达原始CGA的替代地址。CGA的此类应用包括：
o The application of CGAs to protect the shim6 protocol [7]. In this case, CGAs are used as identifiers for the established communications. CGA features are used to prove that the owner of the identifier is the one that is providing the alternative addresses that can be used to reach the initial identifier. This is achieved by signing the list of alternative addresses available in the multihomed host with the private key of the CGA.
o CGAs在保护shim6协议中的应用[7]。在这种情况下，cga被用作所建立的通信的标识符。CGA特征用于证明标识符的所有者是提供可用于访问初始标识符的替代地址的所有者。这是通过使用CGA的私钥对多宿主机中可用的备选地址列表进行签名来实现的。
o The application of CGAs to secure the IPv6 mobility support protocol [8] as proposed in [9]. In this case, the CGAs are used as Home Addresses and they are used to prove that the owner of the Home Address is the one creating the binding with the new Care-off Address. Similarly to the previous case, this is achieved by signing the Binding Update message carrying the Care-off Address with the private key of the CGA.
o 应用CGA保护IPv6移动支持协议[8]，如[9]所述。在这种情况下，CGA用作家庭地址，用于证明家庭地址的所有者是创建与新转交地址绑定的人。与前一种情况类似，这是通过使用CGA的私钥对携带转交地址的绑定更新消息进行签名来实现的。
o The application of CGA to Secure Neighbour Discovery [4]. In this case, the CGA features are used to prove the address ownership, so that it is possible to verify that the owner of the IP address is the one that is providing the layer 2 address information. This is achieved by signing the layer 2 address information with the private key of the CGA.
o CGA在安全邻居发现中的应用[4]。在这种情况下，CGA特征用于证明地址所有权，因此可以验证IP地址的所有者是提供第2层地址信息的所有者。这是通过使用CGA的私钥对第2层地址信息进行签名来实现的。
Essentially, all the current applications of CGAs rely on CGAs to protect a communication between two peers from third party attacks and not to provide protection from the peer itself. Attacks against the collision-free property of the hash functions suppose that one of the parties is generating two messages with the same hash value in order to launch an attack against its communicating peer. Since CGAs are not currently used to providing this type of protection, it is then natural that no additional attacks are enabled by a weaker collision resistance of the hash function.
本质上，CGA的所有当前应用都依赖CGA来保护两个对等方之间的通信免受第三方攻击，而不是提供对等方本身的保护。攻击散列函数的无冲突属性假设其中一方正在生成具有相同散列值的两条消息，以便对其通信对等方发起攻击。由于CGA目前不用于提供这种类型的保护，因此哈希函数的抗冲突性较弱自然不会导致额外的攻击。
CGAs, as currently defined in [2], are intrinsically bound to the SHA-1 hash algorithm and no other hash function is supported.
目前在[2]中定义的CGA本质上绑定到SHA-1哈希算法，不支持其他哈希函数。
Even though the attacks against the collision-free property of the hash functions do not result in new vulnerabilities in the current applications of CGAs, it seems wise to enable multiple hash function support in CGAs. This is mainly for two reasons: first, potential future applications of the CGA technology may be susceptible to attacks against the collision-free property of SHA-1. Supporting alternative hash functions would allow applications that have stricter requirements on the collision-free property to use CGAs. Second, one lesson learned from the recent attacks against hash functions is that it is possible that one day we need to start using alternative hash functions because of successful attacks against other properties of the commonly used hash functions. Therefore, it seems wise to modify protocols in general and the CGAs in particular to support this transition to alternative hash functions as easy as possible.
尽管针对哈希函数无冲突属性的攻击不会在当前CGA应用程序中导致新的漏洞，但在CGA中启用多个哈希函数支持似乎是明智的。这主要有两个原因：第一，CGA技术的潜在未来应用可能会受到针对SHA-1无碰撞性能的攻击。支持替代哈希函数将允许对无冲突属性有更严格要求的应用程序使用CGA。其次，从最近针对散列函数的攻击中得到的一个教训是，有一天我们可能需要开始使用替代的散列函数，因为成功地攻击了常用散列函数的其他属性。因此，修改协议（尤其是CGA）以尽可能容易地支持向可选哈希函数的转换似乎是明智的。
The next question we need to answer is where to encode the hash function that is being used. There are several options that can be considered:
我们需要回答的下一个问题是在哪里对正在使用的哈希函数进行编码。可以考虑以下几种选择：
One option would be to include the hash function used as an input to the hash function. This basically means to create an extension to the CGA Parameter Data Structure, as defined in [3], that codifies the hash function used. The problem is that this approach is vulnerable to bidding down attacks or downgrading attacks as defined in [10]. This means that even if a strong hash function is used, an attacker could find a CGA Parameter Data Structure that uses a weaker function but results in an equal hash value. This happens when the original hash function H1 and CGA Parameters Data Structure indicating H1 result in value X, and another hash function H2 and CGA Parameters Data Structure indicating H2 also result in the same value X.
一种选择是将哈希函数作为哈希函数的输入。这基本上意味着创建CGA参数数据结构的扩展，如[3]中所定义，该扩展对所使用的哈希函数进行编码。问题在于，这种方法容易受到[10]中定义的降价攻击或降级攻击的攻击。这意味着，即使使用了强散列函数，攻击者也可以找到使用较弱函数但导致相同散列值的CGA参数数据结构。当指示H1的原始哈希函数H1和CGA参数数据结构产生值X时，会发生这种情况，而指示H2的另一个哈希函数H2和CGA参数数据结构也产生相同的值X。
In other words, the downgrading attack would work as follows: suppose that Alice generates a CGA CGA_A using the strong hash function HashStrong and using a CGA Parameter Data Structure CGA_PDS_A. The selected hash function HashStrong is encoded as an extension field in the CGA_PDS_A. Suppose that by using a brute force attack, an attacker X finds an alternative CGA Parameter Data Structure CGA_PDS_X whose hash value, by using a weaker hash function, is CGA_A. At this point, the attacker can pretend to be the owner of CGA_A and the stronger hash function has not provided additional protection.
换句话说，降级攻击的工作原理如下：假设Alice使用强哈希函数HashStrong和CGA参数数据结构CGA_PDS_a生成CGA CGA CGA_a。所选哈希函数HashStrong被编码为CGA_PDS_a中的扩展字段。假设通过使用暴力攻击，攻击者X通过使用较弱的散列函数找到另一个CGA参数数据结构CGA_PDS_X，其散列值为CGA_a。此时，攻击者可以假装是CGA_a的所有者，而较强的散列函数没有提供额外的保护。
The conclusion from the previous analysis is that the hash function used in the CGA generation must be encoded in the address itself.
从前面的分析得出的结论是，CGA生成中使用的哈希函数必须在地址本身中进行编码。
Since we want to support several hash functions, we will likely need at least 2 or 3 bits for this.
由于我们希望支持多个哈希函数，因此可能需要至少2或3位。
One option would be to use more bits from the hash bits of the interface identifier. However, the problem with this approach is that the resulting CGA is weaker because less hash information is encoded in the address. In addition, since those bits are currently used as hash bits, it is impossible to make this approach backward compatible with existent implementations.
一种选择是使用接口标识符散列位中的更多位。然而，这种方法的问题是，由于地址中编码的哈希信息较少，因此生成的CGA较弱。此外，由于这些位当前用作散列位，因此不可能使此方法与现有实现向后兼容。
Another option would be to use the "u" and the "g" bits to encode this information, but this is probably not such a good idea since those bits have been honoured so far in all interface identifier generation mechanisms, which allow them to be used for the original purpose (for instance we can still create a global registry for unique interface identifiers). Finally, another option is to encode the hash value used in the Sec bits. The Sec bits are used to artificially introduce additional difficulty in the CGA generation process in order to provide additional protection against brute force attacks. The Sec bits have been designed in a way that the lifetime of CGAs are extended, when it is feasible to attack 59-bits long hash values. However, this is not the case today, so in general CGA will have a Sec value of 000. The proposal is to encode in the Sec bits, not only information about brute force attack protection but also to encode the hash function used to generate the hash. So for instance, the Sec value 000 would mean that the hash function used is SHA-1 and the 0 bits of hash2 (as defined in RFC 3972) must be 0. Sec value of 001 could be that the hash function used is SHA-1 and the 16 bits of hash2 (as defined in RFC 3972) must be zero. However, the other values of Sec could mean that an alternative hash function needs to be used and that a certain amount of bits of hash2 must be zero. The proposal is not to define any concrete hash function to be used for other Sec values, since it is not yet clear that we need to do so nor is it clear which hash function should be selected.
另一种选择是使用“u”和“g”位对该信息进行编码，但这可能不是一个好主意，因为到目前为止，所有接口标识符生成机制都采用了这些位，允许它们用于原始目的（例如，我们仍然可以为唯一的接口标识符创建一个全局注册表）最后，另一种选择是对Sec位中使用的哈希值进行编码。Sec位用于人为地在CGA生成过程中引入额外的困难，以提供额外的保护，防止暴力攻击。Sec位的设计方式是，在可行的情况下，延长CGA的寿命o攻击59位长的散列值。然而，今天的情况并非如此，因此通常CGA的秒值为000。建议使用秒位编码，不仅包括暴力攻击保护信息，还包括用于生成散列的散列函数的编码。例如，秒值000意味着散列函数使用的离子为SHA-1，哈希2的0位（如RFC 3972中所定义）必须为0。001的秒值可以是使用的哈希函数为SHA-1，哈希2的16位（如RFC 3972中所定义）必须为零。但是，Sec的其他值可能意味着需要使用替代哈希函数，并且哈希2的某些位必须为零。建议不定义任何用于其他Sec值的具体哈希函数，因为我们还不清楚是否需要这样做，也不清楚应该使用哪个哈希函数e被选中。
Note that since there are only 8 Sec values, it may be necessary to reuse Sec values when we run out of unused Sec values. The scenario where such an approach makes sense is where there are some Sec values that are no longer being used because the resulting security has become weak. In this case, where the usage of the Sec value has long been abandoned, it would be possible to reassign the Sec values. However, this must be a last resource option, since it may affect interoperability. This is because two implementations using different meanings of a given Sec value would not be able to interoperate properly (i.e., if an old implementation receives a CGA generated with the new meaning of the Sec value, it will fail and the same for a new implementation receiving a CGA generated with the old meaning of the Sec value). In case the approach of reassigning a Sec
请注意，由于只有8个秒值，因此在用完未使用的秒值时，可能需要重用秒值。这种方法有意义的场景是，由于产生的安全性变弱，一些Sec值不再被使用。在这种情况下，如果长期放弃使用Sec值，则可以重新分配Sec值。但是，这必须是最后一个资源选项，因为它可能会影响互操作性。这是因为使用给定Sec值的不同含义的两个实现将无法正常互操作（即，如果旧实现接收到使用Sec值的新含义生成的CGA，它将失败，对于接收到使用Sec值的旧含义生成的CGA的新实现也是如此）。如果重新分配Sec
value is followed, a long time is required between the deprecation of the old value and the reassignment in order to prevent misinterpretation of the value by old implementations.
值之后，旧值的弃用和重新分配之间需要很长时间，以防止旧实现对值的错误解释。
An erroneous interpretation of a reused Sec value, both on the CGA owner's side and the CGA verifier's side, would have the following result, CGA verification would fail in the worst case and both nodes would have to revert to unprotected IPv6 addresses. This can happen only with obsolete CGA parameter sets, which would be considered insecure anyway. In any case, an implementation must not simultaneously support two different meanings of a Sec value.
CGA所有者和CGA验证者对重用的Sec值的错误解释将产生以下结果，CGA验证在最坏的情况下将失败，两个节点都必须恢复到未受保护的IPv6地址。这只能发生在过时的CGA参数集上，这将被认为是不安全的。在任何情况下，实现都不能同时支持Sec值的两种不同含义。
The SEC registry defined in the IANA considerations section of this document contains entries for the different Sec values. Each of these entries points to an RFC that defines the CGA generation procedure that MUST be used when generating CGAs with the associated Sec value.
本文档IANA注意事项部分中定义的SEC注册表包含不同SEC值的条目。每个条目都指向一个RFC，该RFC定义了生成具有关联Sec值的CGA时必须使用的CGA生成过程。
It should be noted that the CGA generation procedure may be changed by the new procedure not only in terms of the hash function used but also in other aspects, e.g., longer Modifier values may be required if the number of 0s required in hash2 exceed the currently defined bound of 112 bits. The new procedure (which potentially involves a longer Modifier value) would be described in the RFC pointed to by the corresponding Sec registry entry.
应当注意，CGA生成过程不仅可以根据所使用的散列函数，而且还可以在其他方面通过新过程来改变，例如，如果散列2中所需的0的数量超过当前定义的112位的界限，则可能需要更长的修饰符值。新程序（可能涉及更长的修饰符值）将在相应Sec注册表项指向的RFC中描述。
In addition, the RFC that defines the CGA generation procedure for a Sec value MUST explicitly define the minimum key length acceptable for CGAs with that Sec value. This is to provide a coherent protection both in the hash and the public key techniques.
此外，为Sec值定义CGA生成过程的RFC必须明确定义具有该Sec值的CGA可接受的最小密钥长度。这是为了在散列和公钥技术中提供一致的保护。
This document defines a new registry entitled "CGA SEC" for the Sec field defined in RFC 3972 [2] that has been created and is maintained by IANA. The values in this name space are 3-bit unsigned integers.
本文件为RFC 3972[2]中定义的SEC字段定义了一个名为“CGA SEC”的新注册表，该字段由IANA创建并维护。此名称空间中的值是3位无符号整数。
Initial values for the CGA Extension Type field are given below; future assignments are to be made through Standards Action [5]. Assignments consist of a name, the value, and the RFC number where the CGA generation procedure is defined.
CGA扩展类型字段的初始值如下所示；未来的任务将通过标准行动[5]完成。赋值由定义CGA生成过程的名称、值和RFC编号组成。
The following initial values are assigned in this document:
本文件中指定了以下初始值：
Name | Value | RFCs
-------------------+-------+------------
SHA-1_0hash2bits | 000 | 3972, 4982
SHA-1_16hash2bits | 001 | 3972, 4982
SHA-1_32hash2bits | 010 | 3972, 4982
Name | Value | RFCs
-------------------+-------+------------
SHA-1_0hash2bits | 000 | 3972, 4982
SHA-1_16hash2bits | 001 | 3972, 4982
SHA-1_32hash2bits | 010 | 3972, 4982
This document is about security issues and, in particular, about protection against potential attacks against hash functions.
本文档涉及安全问题，特别是针对哈希函数的潜在攻击的保护。
Russ Housley, James Kempf, Christian Vogt, Pekka Nikander, and Henrik Levkowetz reviewed and provided comments about this document.
Russ Housley、James Kempf、Christian Vogt、Pekka Nikander和Henrik Levkowetz对本文件进行了审查并提供了意见。
Marcelo Bagnulo worked on this document while visiting Ericsson Research Laboratory Nomadiclab.
Marcelo Bagnulo在访问爱立信研究实验室Nomadiclab时编写了此文档。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[2] Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[3] Bagnulo, M. and J. Arkko, "Cryptographically Generated Addresses (CGA) Extension Field Format", RFC 4581, October 2006.
[3] Bagnulo，M.和J.Arkko，“加密生成地址（CGA）扩展字段格式”，RFC 4581，2006年10月。
[4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[4] Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[6] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[6] Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 42702005年11月。
[7] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", Work in Progress, July 2005.
[7] Nordmark，E.和M.Bagnulo，“多归宿L3垫片法”，正在进行的工作，2005年7月。
[8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[8] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[9] Arkko, J., "Applying Cryptographically Generated Addresses and Credit-Based Authorization to Mobile IPv6", Work in Progress, June 2006.
[9] Arkko，J.“将加密生成的地址和基于信用的授权应用于移动IPv6”，正在进行的工作，2006年6月。
[10] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", NDSS '06, February 2006.
[10] Bellovin，S.和E.Rescorla，“部署新的哈希算法”，NDSS'06，2006年2月。
Authors' Addresses
作者地址
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN
马德里卡洛斯三世大学。西班牙马德里勒加内斯30大学28911
Phone: 34 91 6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Phone: 34 91 6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Jari Arkko Ericsson Jorvas 02420 Finland
雅丽爱立信芬兰公司02420
EMail: jari.arkko@ericsson.com
EMail: jari.arkko@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。